Алексей Приймак

Всё стремиться от маленького к большему, это касается как окружающего нас мира, так и... нашей деятельности. К чему это я: практически любая компания (за редким исключением) начинается с чего-то маленького, постепенно набирая обороты, наращивая состав сотрудников, объём бухгалтерии, совершенствуя бюрократические отношения и состав ИТ технологий. Вот о последнем и идёт речь.

Сам в своё время начинал из админа в одном из общежитий КПИ, где под чутким надзором "скинувшихся на апгрэйд" прокладывал первые метры витой пары вместо коаксиала, цеплял простенькие Surecom-овские свичи и откровенно радовался "поднявшимся" 1-2МБ/с вместо традиционных 150-300КБ/с при работе в сегменте.

Я давно не админ сети, но с тех пор серверное хозяйство завелось магистральной оптикой, несколькими мощными файловыми и медиа серверами, беспроводной сетью и прочими вкусностями современной ИТ инфраструктуры.

Возвращаясь к современным компаниям, с ИТ инфраструктурой происходят в чём-то аналогичные превращения, только вместо двух-трёх серверов и неуправляемых комутаторов у них существует несколько десятков сервисов, некоторая система защиты, мониторинга, возможно, даже система резервного копирования и парк самой разнообразной ИТ техники разных поколений и типов. И если, скажем, в студенческом общежитии возможно отключение сервера-маршрутизатора, или медиа-сервера на время для планового ремонта, чистки или полной замены, то очень часто в современной компании это сделать или возможно в узком диапазоне времени, или вообще невозможно.

Развитие ИТ инфраструктуры может проходить по нескольким сценариям:

1. Построение  сервисов "по требованию", т.е. существующая структура продолжает функционировать, под новые сервисы закупаются сервера/лицензии, выделяются коммуникационные порты и производится интеграция сервиса в ИТ среду

2. Разработка ИТ стратегии: отталкиваясь от планируемых бизнес-услуг, разрабатывается план развития (или модернизации) ИТ среды на некоторый период вперёд и выполняется постепенная реализация данного плана

3. Переход на аутсорсинг/SaaS/Collocation: возможно в ряде случаев после оценки экономической эффективности обслуживания (владения) собственной ИТ структурой и принятием решения по переводу мощностей на обслуживание другой компанией.

Из перечисленных трёх направлений в моей практике подавляющее большинство проектов, к сожалению, могу отнести к первому типу. Почему именно "к сожалению"? Не секрет, что новые технологии и сервисы в отдельной компании зачастую внедряются компаниями-интеграторами, т.к. есть у самостоятельной компании риск и в переоценке собственных ресурсов, и в отсутствии опыта, а также необходимость отрыва локальных администраторов от их собственных "будней".

Опасность такого подхода также кроется в том, что если компания-интегратор впервые работает с заказчиком, у неё чаще всего нет полного представления о текущем функционировании ИТ среды, особенностях процесов и взаимодействий сервисов. Хотя, чего таить, мне приходилось общаться с представителями заказчика, которые сами до конца не представляли общей ИТ структуры компании, из-за того что только были переведены на данную должность "для поднятия ИТ". Хуже, когда после проведения опроса, на практике инженеры на местах обнаруживали совсем другую картину.

В чём заключается, на мой взгляд, проблема данного подхода - это зачастую отсутствие именно детализации современного состояния ИТ среды. Привлечение интегратора сводится к выполнению отдельно стоящей задачи, и в лучшем случае интегратор проводит некоторое предварительное интервьюирование, а по его результатам - готовит эскизный проект решения. Но это  - удлинение сроков выполнения проекта, и, возможно, изменение состава решения вследствие недостаточного для внедрения первоначального решения состояния современной ИТ инфраструктуры заказчика.

На практике интегратор уже должен предоставить некоторое виденье решения ещё на этапе конкурса, а в ряде случаев - предоставить смету на оборудование, программное обеспечение, стоимость и длительность работ по всему проекту. С одной стороны опыт интегратора в таком случае и заключается в умении "предвидеть" возможные риски и заложить деньги/сроки на преодоление рисков. С другой стороны - такие "риски" не могут быть большими, т.к. в таком случае можно вообще оказаться за бортом проекта. Вот тогда и приходиться баллансировать на на грани разумного, адаптируемого решения, предоставляемого те функции, которые необходимы, и при этом по возможности учитывая проблемные факторы среды заказчика в денежно-временном эквиваленте.

А казалось бы, дело за малым - проведение отдельного, предваряющего процесс проектирования, детального аудита существующей ИТ инфраструктуры. Да, это стоит и денег, и времени. Но на самом деле выполнение данного этапа гораздо шире, чем просто узнать, что находится "в закромах у Родины". Результат, полученный на данном этапе, позволяет не только освежить, систематизировать информацию об собственной ИТ инфраструктуре, но и получить незаангажированную оценку состояния, акцентировать внимание на проблемах, с которыми сталкиваются ИТ администраторы и которые отнимают у тех рабочее время. Более того, данный результат может быть использован для перехода ко второму или третьему из вышеперечисленных направлений, т.е. вообще отказ от "лоскутного" внедрения технологий и сервисов.

Хотя, перефразируя высказывание, чем больше узнаёшь, тем лучше понимаешь, что нужно ещё много чего сделать. В современных кризисных условиях отдельное проведение аудита - занятие достаточно затратное, а разработка стратегии и планирование затрат на модернизацию - и вовсе для некоторых пока что несвоевременная роскошь. И поэтому приходится уже на этапе внедрения сервиса "создавать" некоторые комбинированные решения для структурной связи старого и нового, вот только иногда уже при адаптации такого решения становиться понятно, что такая связка будет тяжела для дальнейшей модернизации, и данное решение становиться похожим на Франкенштейна: вроде бы рабочее, но глаз не радует.