Жонглирование распределенной инфраструктурой
Автор
Олег Седов
К счастью, поскольку мы выстраивали архитектуру с нуля, то сделали это достаточно хорошо.
С точки зрения строительства ИТ-инфраструктуры, ситуацию в компании «Полюс » можно назвать по-своему уникальной. Дело в том, что восемь лет назад вся инфраструктура создавалась практически с нуля. Однако, несмотря на это, мы в результате получили разрозненный ландшафт приложений и систем. Хотим мы того или нет, но у нас, как у ИТ, существуют свои бизнес-заказчики с определенными требованиями, а потому случается, что ИТ-продукт, удовлетворяющий потребностям заказчика, красиво не ложится на существующую ИТ-инфраструктуру. Тем не менее в ИТ, как и в жизни, существуют некие базовые постулаты, которые нельзя преодолеть, например скорость света, а у нас в отдельные регионы присутствия компании нельзя провести наземные каналы связи, а следовательно, расширить возможности для применения централизованных сервисов. Ну а если и возможно, то затраты на подобное решение будут превышать стоимость золота. Таким образом, наше базовое требование всегда исходило из этих ограничений и предполагало, что система должна работать на очень тонких каналах, а еще лучше в виде распределенного решения и распределенных баз данных. Иными словами, обеспечивать обмен данными с определенной периодичностью. Накопили пакет информации, передали в центр, где она консолидируется. Вот, исходя из этого, и строилась ИТ-архитектрура в части бизнес-приложений.
Однако найти решение под наши, казалось бы, очевидные требования было достаточно тяжело. В начале 2000-х годов все производители популярных ERP-систем почему-то решили, что мир перешел в некую эпоху интернетизации и централизации ресурсов, а значит, ERP работают в режиме единого центра и в централизованной архитектуре. В результате все попытки внедрения, например Oracle eBusiness Suite, разбивались, во-первых, о персонал, который либо отсутствовал на местах, либо не был готов воспринимать такую архитектуру, а во-вторых — о скорость передачи информации по каналам связи, что делало неприемлемым для нас создание единого централизованного решения.
В результате мы пошли по пути выбора и использования решений, которые наилучшим образом отвечали бы потребностям наших заказчиков из бизнес-подразделений и при этом были максимально приспособлены для работы на тонких каналах или работы в рамках конкретного подразделения, с возможностью передачи информации в другие системы. Не могу сказать, что такое решение далось нам просто. Очевидно, что подобный специфичный вариант ИТ-архитектуры заведомо усложняет ИТ-ланшафт предприятия. Но мы обращались за консультацией к экспертам, в частности, Market Visio, эксклюзивного партнера Gartner, для анализа рынка систем, привязанных к золотодобывающим компаниям мира, и получили ответ, что ERP-систем, которые нас полностью могли бы удовлетворить, не существует. Поэтому нам предстояло ориентироваться на то лучшее, что есть на рынке в каждом отдельном сегменте. По сути, это тоже стратегия в ИТ. Таким образом, мы стали рассматривать системы, которые отвечают за решения конкретных задач и наилучшим образом ложатся на наш ИТ-ландшафт нижнего уровня.
К счастью, поскольку мы выстраивали архитектуру с нуля, то сделали это достаточно хорошо. В результате сегодня почти 90% нашей инфраструктуры обслуживает один телеком-провайдер — ему мы и передали на аутсорсинг управление сетью. Некоторых моих коллег из ИТ удивляет, как нам удалось внедрить единый номерной план на всю компанию. Для многих это большая проблема в масштабах территориально разнесенной компании. Но этому вопросу мы уделяли серьезное внимание еще на этапе проектировании и развертывания систем.
Хронология в архитектуре
К 2009 году мы практически закончили строительство единой сети. Подключение любой новой точки у нас занимало не больше трех месяцев с момента подачи заявки в ИТ-службу. Больше всего времени уходило на доставку оборудования на места, а монтаж выполнялся в течение двух-трех дней, включая телефонию, подсоединение к корпоративной сети, электронную почту, портал и пр. Начиная с 2009 года, мы приступили к развертыванию среды бизнес-приложений. До этого примерно два года шло внедрение бухгалтерской и налоговой системы с консолидацией данных из регионов в головной компании, а также управление кадрами. Но с 2009-го по мере того, как появлялись заказчики от бизнеса, началась автоматизация конкретных бизнес-задач, таких как бюджетирование в единой системе, автоматизация автотранспорта, идет внедрение единой логистической системы. К этому времени у нас выстроилась культура управления проектами, работает комиссия по ИТ, где коллегиально принимаются решения о применении той или иной системы. В составе комиссии руководители бизнес-подразделений и два-три ИТ-специалиста. По каждому проекту у нас создается управляющий комитет, в котором непременно присутствует кто-то из топ-менеджента компании. Без участия в проектах людей такого масштаба мы со стороны ИТ стараемся не браться.
Очевидные сложности
Сейчас все сложнее находить решения, которые можно было бы быстро развернуть на местах на базе имеющегося у нас оборудования, и сделать это в течение одного календарного года. А во-вторых, сегодня крайне сложно с кадрами, и даже не столько с нашим ИТ-персоналом. Для себя-то мы специалистов набираем, мотивируем, сохраняем и растим. А вот на стороне провайдеров услуг и системных интеграторов с кадрами - ну просто беда. Очень остро чувствуется недостаток квалификации. Такое впечатление, будто людей, которые что-то умели, перекупают другие компании. Мне приходилось работать с парой команд, мигрирующих от одного интегратора к другому.
В нашей практике существует проверенное правило, что на стадии тендера мы выбираем из множества предложений те, которые нам кажутся наиболее интересными, затем из них оставляем два-три и проводим платный пилотный проект. В этом случае каждому из участников предлагаем автоматизировать какой-то отдельный участок или процесс, а потом оцениваем результат и принимаем решение. Однажды пилот, рассчитанный на три месяца, начинала одна команда, а продолжала другая, так как на середине проекта вся команда уволилась и забрала с собой всю документацию по нашему проекту. Поэтому новым исполнителям пришлось просить провести повторное интервьюирование на местах. И это был тендер, который курировал непосредственно вендор!
Кстати, мы сами практикой переманивания команд или ключевых исполнителей на свою сторону от партнера не занимаемся. Это позиция, продиктованная очень жестким ограничением на численность нашего ИТ-персонала. Изначально мы ориентировались на западные подходы, изучая опыт и практики наших международных конкурентов, где все выверено, обосновано и максимально вынесено на аутсорсинг и инсорсинг. Поэтому в регионах пропорция управленческого, офисного и другого персонала очень строго соблюдается. Если говорить про ИТ, то на четыре тысячи рабочих мест весь ИТ-штат, включая службу поддержки пользователей, которую мы сейчас создаем, не превышает 80 человек. Если бы мы компактно размещались в одном здании, это была бы заурядная задачка, но поскольку мы территориально разнесенная компания, то управление ИТ-инфраструктурой перестает быть чем-то простым и тривиальным.
Однако на местах найти персонал еще сложнее, чем в Москве. Поэтому мы и были вынуждены создать единую службу поддержки. Для этого в Красноярске арендован отдельный офис, в котором сосредоточена поддержка всех бизнес-сервисов, а развитие продуктов на уровне новых функций остается на стороне подрядчиков. В результате наша служба поддержки доводит решения и системы до приемлемого для широкой эксплуатации вида, решает задачи по созданию отчетных форм и исправлению мелких ошибок.
Игра разума
Если перевести диалог об управлении ИТ в термины качества, то для этого есть некие базисные-параметры, которые в идеале должны исходить от бизнес-руководства. Но чаще всего бизнес не может сам сформировать свои требования к SLA. В результате все, что мы строили, нам приходилось делать, исходя из принципов допустимой разумности. Поясню на примере. Если некий сервис, скажем, Интернет в Москве не работает половину дня, то это плохо, но не катастрофа. А если в регионах сервис управления большегрузным транспортом не работает более двух часов — это недопустимо. Исходя из этого, мы строили модели, какое оборудование устанавливать и какие решения применять в рамках выделенного нам бюджета. Это была особая игра разума, и она все еще продолжается. Имея некий бюджет, мы сами себе формулируем задачи в части требований к ИТ инфраструктуре и решаем их. Бизнес уже постфактум оценивает полученный результат.
Но появляются девайсы, и от BYOD (Bring Your Own Device) никуда не деться. Формально мы были довольно неплохо подготовлены к этой концепции. У нас были развернуты специальные технологи удаленного доступа, позволяющие сотрудникам работать с корпоративной средой практически из любого места. И все было у нас хорошо до того момента, пока служба безопасности всерьез не взялась за соответствие требованиям ФЗ 152 (Федерального закона о персональных данных). В результате сейчас многое приходится переделывать. Но у меня есть четкий срок, в течение которого мы должны привести все в соответствие с требованиями ФЗ. При этом формально какого-то бонуса или дополнительной защищенности для бизнеса это не дает.
Но надо сказать, что топ-менеджмент у нас очень ограниченно использует функционал своих мобильных устройств для работы в корпоративной среде. В основном их активность сводится к получению электронной почты и звонков через MS Lync. Удаленный доступ предназначен в первую очередь для наших подрядчиков, которые поддерживают и внедряют у нас свои системы и подключаются к нам в определенных доверенных зонах, где установлены их тестовые серверы. Это позволяет нам небольшой численностью ИТ-персонала выполнять довольно значительный объем работ
Перспективы
Н сегодняшний день у нас в компании виртуализировано примерно 70% серверного оборудования. Мы занялись практикой виртуализации примерно два года назад и делаем это по мере износа старого оборудования, поскольку не видим смысла заниматься заменой всего оборудования ради виртуализации. Это должен быть постепенный процесс, а потому вполне возможно, что без каких-то революций мы со временем переведем часть оборудования и сервисов в облачные среды. В частности, сейчас в Красноярске идет эксперимент по переводу бухгалтерии на «тонких» клиентов. А это своеобразная ступенька к облаку.
Кроме того, решение для части задач мы рассматриваем в условиях публичных облаков. Так, на базе MS Project Server организуется управление проектами. В рамках строительства двух добывающих фабрик идет общение с несколькими десяткам поставщиков и подрядчиками, и все это привязано к жесткому графику. Поэтому мы рассматриваем вариант либо допустить к нашему серверу поставщиков, либо часть информации разместить в облаке, где она может быть доступна партнерам и подрядчикам. Однако всем этим ИТ-хозяйством в новых средах еще предстоит научиться управлять и жить по правилам и в рамках SLA!
Опубликовано 25.02.2013
Похожие статьи
Ольга ПоповаИТ в бизнесе, 06.10.24
Олег ДемченкоКак это сделать, 23.08.24
Иван ПакулинИТ в бизнесе, 23.08.24
Денис ШарафановКак это сделать, 30.07.24