Дмитрий Бессольцев

Уже больше года мы видим явное подтверждение того, что призыв «сверху» к цифровой трансформации экономики накладывается на взрывную тенденцию по созданию собственного ПО, идущую «снизу». Более половины компаний из ретейла, медицины и финансового сектора стали в три раза чаще, чем год назад, запускать микропроекты по цифровой трансформации, основанные на непрерывной адаптивной внутренней разработке ПО, организованной по принципам (а зачастую и методикам) Agile и DevOps.

Особенность такого ПО – глубокое отражение отраслевой специфики, насыщенность собственными ноу-хау компании и прямая связь между функциями приложений и конкурентными преимуществами компании. Кроме того, идут постоянные эксперименты: если компания верит в какую-то новую идею, но новые «фишки» не сработали, их тут же переделывают (иногда не по одному разу), добиваясь в конце концов задуманного результата.

Это принципиально отличается от стандартной практики неторопливого создания универсального корпоративного ПО, которое при каждом внедрении должны подолгу настраивать консультанты и которое развивается в направлении, на которое компания не может даже влиять, не говоря уже о том, чтобы его контролировать. Например, сети медицинских лабораторий начали активно дорабатывать личные кабинеты, добавляя нужные пациентам онлайн-сервисы. Торговые сети заговорили о работах над «умными» терминалами, умеющими узнавать постоянных покупателей по лицу и голосу, чтобы предложить им именно те кроссовки и футболки, которые они почти наверняка купят.

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

Революция без жертв: смешанные команды в проектах Agile+DevOps

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

Жизнь подтвердила, что эта схема работает, а недоверие к ней быстро снижается. И вот уже медицинские компании, финансовые консультанты и торговые сети все чаще запускают собственные небольшие системы на базе микросервисной архитектуры. Создаются продвинутые личные кабинеты, где новые сервисы появляются раз неделю, а иногда и в два-три дня. Появляются терминалы заказа фастфуда, определяющие средний чек и любимые блюда постоянного покупателя. Отлично зная свой рынок, такие компании самостоятельно определяют цели, задачи, координируют производственный процесс. А agile-команды стерли казавшийся непреодолимым барьер непонимания, десятилетиями разделявший разработчиков, стремящихся жить в «башнях из слоновой кости» и заказчиками.

Очевидно, сегодня далеко не все компании хотя бы идейно готовы так работать – без заседаний всевозможных комитетов, бесконечных процессов согласования и утверждения ТЗ, но это новый долгосрочный тренд. И новый перспективный рынок для смешанных ИТ-команд, объединяющих разработчиков, экспертов из сервисных компаний, специалистов по ИБ. Этот рынок возник ради большей гибкости и адаптивности прикладных решений, которые (наконец-то!) действительно способны поддержать постоянные изменения и внутри компании, и снаружи – в ужесточившейся конкурентной среде и меняющемся технологическом ландшафте.

Самостоятельная разработка и поддержка микросервисов: что и как

В таких проектах господствует agile-подобная разработка. Есть заказчики, от которых идут задачи, есть координаторы проектов и аналоги спринтов Scrum. Под проекты оперативно выделяются «компактные», но достаточные бюджеты. И, главное – на таких проектах работают смешанные трансграничные команды. Строго внутри организации остаются стратегия и целеполагание (бизнес-лидеры), тактика разработки (технические лидеры), «ядро» разработки и информационная безопасность. Снаружи – написание мобильных версий основных ИТ-сервисов, интеграция и обмен новых систем с внешними сервисами, эксплуатация систем.

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

Как этого добиться? Здесь только один путь – необходимо с самого начала включать в состав DevOps-команд специалистов по ИТ-инфраструктуре и эксплуатации готовых решений, хорошо знающих принципы, особенности и практики эксплуатации облачных бизнес-приложений, постоянно или время от времени работающих в высоконагруженном режиме. Они определят, что именно в данном проекте (с учетом специфики существующего ИТ-ландшафта и особенностей создаваемого ПО) надо сделать, чтобы готовое решение действительно смогло поддержать отказоустойчивость и горизонтальное масштабирование, чтобы оно справлялось с пиковыми нагрузками, не создавая раздражающих задержек. Именно для этих специалистов такая работа – профильная, в отличие от разработчиков.

ИТ-инфраструктурщики на DevOps-проектах: чем полезны

Быстро создают и развертывают сразу несколько разных сред

Разработчикам в таких проектах нужно три среды – помимо продуктивной, еще тестовая среда и среда разработки. Они сильно отличаются из-за различия решаемых задач, но между ними должно быть определенное подобие, чтобы результаты тестирования можно было спокойно переносить в продуктив. Соответственно, эти среды должны быть правильно спроектированы, созданы, настроены. В то же время для программистов важно сосредоточиться на оперативной доработке функционала – ведь изменения и комментарии к тому, что сделано, идут постоянно. Поэтому здесь специалисты по ИТ-инфраструктуре, умеющие работать со свободным ПО (Ansible, Kubernetes и др.), незаменимы. Они должны быстро и правильно спроектировать и создать нужные среды и целые ИТ-инфраструктуры для разработки бизнес-приложений.

Кроме того, есть множество задач, которые разработчики могут передать «системным администраторам 2.0», работающим на стыке программирования и администрирования. Это позволит не отвлекаться от главного – работы над функционалом решения, и сократить издержки на разработку и сопровождение. Ведь если у «инфраструктурщиков» на своем поле есть набор готовых решений, то приложение и обойдется компании дешевле, и будет готово быстрее, а качество разработки при этом не пострадает. Среди таких задач, например, централизованное управление средами. Оно нужно для того, чтобы разработчики испробовали все гипотезы, а новые системы и приложения, выйдя в продуктивную эксплуатацию, гарантированно заработали бы без сбоев. При этом затраты разработчиков на хостинг тестовых сред не должны быть очень большими. «Cисадмины 2.0» помогают и с этим.

Помогают выбрать площадку для сервисов и рассчитать ресурсы под проект

В DevOps-проекте инженеры сервисной компании очень часто помогают разработчикам приложений заранее определить, какую вычислительную мощность нужно выделить под сам проект (для каждой из трех сред). Позже их услуги нужны при тиражировании на новые подразделения, ИТ-инфраструктура которых практически всегда имеет особенности, а иногда и принципиальные отличия. Также эти специалисты правильно и эффективно по затратам организуют ИТ-инфраструктуру для работы приложений в облаках (AWS, GCE, Azure), чтобы впоследствии, когда число пользователей и объем задач будут возрастать, не пришлось тратить время и ресурсы на авральный «переезд» на более подходящую площадку.

Развертывают ИТ-инфраструктуру для запуска приложений

ИТ-специалисты заранее готовят и настраивают средства автоматизированного управления конфигурациями(Puppet, Ansible и др.), резко снижающие сложность оперативного развертывания и настройки серверов, снижают количество ошибок и зависимость от квалификации администратора. Такая подготовка сокращает время на развертывание приложений для клиента в 3-10 раз.

Кроме того, инфраструктурщики обеспечивают разработчиков актуальной документацией (инструкции, шаблоны, комментарии) по всем необходимым компонентам ПО, работающим на серверах приложений.

Автоматизируют управление инфраструктурой

«Сисадмины 2.0», опираясь на ИТ-инфраструктуру, с которой можно работать как с ПО, оформляют все рутинные операции по управлению ею (обновление, подготовка нового сервера) в виде задач для систем управления конфигурациями. И уже эти системы устанавливают и настраивают ПО, приводя его в оговоренное целевое состояние и обеспечивая целостность ИТ-решения любой сложности. Это позволяет до предела упростить обслуживание ИТ-инфраструктуры – например, перегрузить «зависший» виртуальный сервер, просто зайдя в консоль и нажав кнопку Reset. Или моментально восстановить информацию, которая, казалось, была потеряна (технология моментальных снимков).

Работают с контейнеризированными приложениями

Также инфраструктурщики автоматизируют установку, масштабирование и управление контейнеризированными приложениями с помощью кластеров Kubernetes. Благодаря их настройке (включая правила доступа к API и правила межсетевого взаимодействия для приложений), разработчики могут сделать свое приложение доступным даже во время пиковых нагрузок. А также в любой момент расширить или сжать кластер – буквально за пару секунд. Это экономит время и силы разработчиков, спасает их от многочисленных сложностей и ошибок.

Выполняют требования к SSO

Зачастую новые системы работают на разных СУБД (PostgreSQL, MySQL), а при разработке приложений используются разные платформы. Естественно, у разработчиков, а потом и у пользователей, должен быть простой и безопасный доступ ко всем нужным им сервисам и инструментам, а также сквозная аутентификация (Single Sign-On, SSO). Кроме того, над проектом работают разные команды – здесь обязательно нужно разделять права доступа к сервисам, инструментам, задачам, делать технически невозможным такое совмещение прав, которое создает высокие риски для бизнеса. К сожалению, об этом функционале думают не всегда.

Отслеживают «здоровье» информационной системы

Тиражируя и масштабируя новые приложения, важно следить за их состоянием, желательно в режиме реального времени. Специалисты по ИТ-инфраструктуре могут предоставить разработчикам приложений доступ к данным, помогающим анализировать возникающие ошибки в работе приложений с помощью инструментов open source (Graylog и Elasticsearch). Они также организуют сбор всех нужных разработчикам метрик с элементов инфраструктуры и приложений, на всех уровнях (Zabbix, Prometheus, TICK Stack). Также «инфраструктурщики» могут настроить удобную визуализацию и умные предупреждения о возможных ИТ-проблемах и авариях, отслеживать и корректировать поведение разных модулей приложения при высоких нагрузках.

Налаживают резервное копирование

Правильное хранение и быстрое восстановление потерянной информации крайне важно для любого бизнеса – это уже давно аксиома. Здесь «сервисники» могут сделать очень многое. Например, провести серию интервью с представителями заказчика и выяснить, какая глубина резервных копий нужна компании, пользующейся новым приложением. Как долго нужно хранить ту или иную информацию, данные за какой отрезок времени можно потерять, и это не окажется смертельным. На основании глубокой аналитики «сервисники» выстроят для разработчиков и их заказчиков правильную систему резервного копирования. Наладят организационно-технический контроль за правильным и своевременным выполнением резервного копирования, гарантирующие сохранность данных и возможность их восстановления в оговоренные сроки. Без этого самая совершенная система легко может стать бомбой замедленного действия.

Подведем итоги

Специалистов по ИТ-инфраструктуре необходимо вводить в новые DevOps-проекты, потому что они способны уберечь разработчиков от дорогостоящих и бьющих по репутации ошибок, связанных с эксплуатацией готовых решений. При этом важны индивидуальные рекомендации, основанные на понимании, куда организация ведет разработку, какие технологии и подходы предполагает применять. «Одна инструкция на все случаи жизни» тут не поможет, тем более, что сегодня очень много направлений разработки: кто-то занят big data, кто-то – искусственным интеллектом, а кто-то – исключительно «традиционными» информационными системами.

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

Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group

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

Разумеется, у ИТ-инфраструктуры есть много других свойств, наличие которых помогает проведению цифровых трансформаций на предприятии (например, система управления ИТ на основе объективных данных), но вышеперечисленные три свойства — это необходимый минимум. Если какого-то из них нет, то цифровую трансформацию начинать нельзя. К сожалению, сегодня именно эта ситуация характерна для подавляющего большинства российских организаций. Первым делом им нужно привести в порядок «технологический фундамент». С чего же начать и что именно сделать, чтобы подготовка прошла легче и быстрее? А сделать нужно немного.

Шаг № 1. Почистить ИТ-организм — провести входной аудит

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

Серия интервью, проведенных в ходе аудита с сотрудниками компании, топ-менеджерами и внутренней ИТ-службой, позволяет выяснить главное: контекст возникновения и «жизни» инцидентов и проблем. И найти оптимальные способы их устранения.

Отличие ИТ-аудита, проходящего как «нулевой этап» цифровой трансформации, от обычного анализа состоит в том, что команда, отвечающая за такой ИТ-аудит, изначально выясняет у бизнеса (генеральных, коммерческих, финансовых директоров, директоров по продажам, производству, логистике), какого эффекта бизнес ждет от намеченных цифровых трансформаций, какие именно информационные системы будут меняться в ходе этого процесса. И на что заказчик возлагает наибольшие надежды на данном этапе. Если, например, на модернизацию системы управления работой с клиентами и партнерами, то как именно он рассчитывает это делать? Если, скажем, на базе этой системы предполагается разработать личный кабинет для пяти-семи тысяч внешних пользователей с гарантированным приростом в 30–40% в течение следующего года, то ИТ-аудиторы будут, помимо прочего, тщательно проверять, выдержит ли ИТ-инфраструктура внедрение и работу такого решения. Правильно ли она спроектирована под него (от архитектуры СУБД до сервера приложений, веб-сервисов и терминальных сервисов)? Сможет ли она быстро и просто масштабироваться, отвечая запланированному притоку пользователей?

Шаг № 2. Обеспечить простую и недорогую масштабируемость ИТ-инфраструктуры: гибридные схемы и сайзинг ресурсов в IaaS

Недорогая и легко масштабируемая ИТ-инфраструктура уже не просто нужна, а жизненно необходима быстро меняющемуся среднему и даже крупному бизнесу. Сегодня самый простой и уже вполне доступный на отечественном ИТ-рынке путь реализации этих возможностей — аренда ресурсов в IaaS. Однако дублирование всей ИТ-инфраструктуры в облаках — дорогое удовольствие, учитывая текущие цены у крупных облачных провайдеров. Часто среднему предприятию дешевле построить собственную ИТ-инфраструктуру и работать на ней лет пять без всяких проблем, чем два года оплачивать ее аренду. Кроме того, как бы ни было удобно облако, с ним тоже случаются проблемы: например, с доступом (очень часто — на уровне местных провайдеров в российских регионах), с надежностью, иногда — с безопасностью. Эти риски становятся особенно значимыми, если ориентация на облачные сервисы приводит к нарушению принципа «не складывать все яйца в одну корзину».

Более выгодным для среднего и даже крупного заказчика способом обеспечить простую и недорогую отказоустойчивость (в режиме «теплого» или «горячего» резерва ресурсов) является «гибридная» ИТ-инфраструктура. Если все нормально, работу предприятия обеспечивает инфраструктура традиционного типа, которая у него уже есть. И только если возникает нештатная ситуация, пользователи до момента ее устранения автоматически переводятся на работу с сервисами из облака. Причем за счет поддерживаемого гибридной инфраструктурой резервирования данных пользователи продолжают прерванную работу. При этом компания платит не за абстрактную надежность и отказоустойчивость (что может ни разу не потребоваться на практике), а за потребление ресурсов облака в периоды конкретных ИТ-инцидентов и «обрушений». И только если они действительно происходят. К тому же, если потребуется докупить у IaaS-провайдера ресурсы (скажем, под крупный проект), то делается это максимально быстро и просто — «в один клик».

Однако тут заказчика подстерегает еще одна проблема. Поставщики ресурсов в IaaS традиционно нацелены на то, чтобы продавать как можно больше (overselling). Это приводит к тому, что покупатели столь же традиционно переплачивают за ресурсы вдвое-втрое, а то и вчетверо. Причем из-за нехватки информации переплачивать приходится за все виртуальные ресурсы (процессоры, память и др.). Наиболее крупные и дорогие IaaS-провайдеры смягчают эту ситуацию, позволяя крупным клиентам отслеживать реальное потребление мощностей. Но для среднего бизнеса такие инструменты слишком дороги, да они и не продаются отдельно от платформ. А привязка к платформе — это тоже риск. Однако эффективные решения есть: например, услуга автоматизированного сайзинга ресурсов позволяет при работе с любыми IaaS-провайдерами точно, без переплат, спланировать потребление ресурсов и платежи за мощности в облаке.

Эти ИТ-сервисы дают возможность собрать и проанализировать объективные данные о том, хватает ли ресурсов. А если уже не хватает или не будет хватать через какое-то время (скажем, через две недели), то каких именно и сколько. Необходимая для этого информация автоматически стекается в сервис в режиме реального времени, а на выходе появляются рекомендации: какие ресурсы и когда надо докупить, а от каких можно безболезненно отказаться. Это позволяет предприятию своевременно и оптимально перераспределять затраты на облако и гарантированно избегать неприятной ситуации, когда ресурсов вдруг не хватило и бизнес начал простаивать. Также можно получить представление о том, когда и на сколько сократить потребление ресурсов, если, скажем, произошел сезонный или внезапный спад деловой активности. Или если часть пользователей либо какие-то сервисы были переброшены в другой ЦОД.

Шаг № 3. Поддержать высокую изменчивость — начать непрерывный ИТ-аудит

Любые технологические изменения порождают если не рост, то почти всегда — перераспределение нагрузки на ИТ-инфраструктуру. Например, компания решила объединить два сервера баз данных в один отказоустойчивый экземпляр и слить в него все базы. Но, сделав это, организация должна быть уверена в том, что ее веб-сервисы и другие ИТ-системы, работающие с этими базами, справляются с нагрузкой и что сервер приложений при этом «чувствует себя» совершенно нормально. Кроме того, предприятию нужно детально знать, как в результате такого изменения поменялась нагрузка на дисковую подсистему, сети, сопутствующие компоненты. Если поменялась, то на каком участке и как именно. От этих знаний зависит сама возможность своевременно выявить «бутылочные горлышки», которые будут ограничивать производительность тех или иных информационных систем и бизнес-приложений, и перегрузка которых почти наверняка будет чревата целой цепочкой ИТ-инцидентов и проблем!

Непрерывный ИТ-аудит призван отслеживать именно такие вещи в режиме реального времени. Это, конечно, не делается вручную. Здесь нужна автоматизация — в данном случае дополнительный аналитический модуль, на оперативность, надежность и компетентность которого организация может положиться.

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

Шаг № 4 (дополнительный). Обеспечить постоянное взаимодействие команд на проектах по цифровой трансформации

Занимаясь приведением в порядок ИТ-инфраструктуры, бизнес должен задуматься едва ли не о самом опасном узком месте цифровой трансформации — о налаживании взаимодействия участвующих в ней независимых команд. Так, служба разработки должна уметь действовать в связке со службой эксплуатации ИТ-инфраструктуры и со службой внедрения (это взаимодействие совершенно необходимо при использовании связки Agile и DevOps). А все они — с подразделениями, отвечающими за информационную безопасность. И конечно — с бизнес-заказчиком. Как правило, ничего этого сейчас нет, но такая ситуация недопустима, когда в организации осуществляется широкая цифровая трансформация.

Сегодня наилучшим способом преодолеть этот давний «камень преткновения» является выстраивание горизонтальных связей между командами в виде системы процессов, дополненной современными средствами коммуникации «для данного случая» (ad hoc). Если организация решает внедрить технологии управления Agile, нужно тщательно выбрать конкретную методику, настроить соответствующие процессы (чемпион здесь — Scrum) и уделить большое внимание компетенциям участников. В любом случае (даже если перехода на Agile нет) помогает формирование небольших рабочих DevOps-групп под проекты (в том числе и по цифровой трансформации). В эти группы входят представители каждой из вышеперечисленных команд. Однако всем им нужна общая информационная среда и доступ к постоянно обновляющейся информации в ней — о состоянии всего проекта и его составных частей. Чтобы каждый мог наблюдать и анализировать одни и те же тренды, осуществлять правильные и своевременные корректирующие действия. И не каждая команда — только по своему участку, а совместно, по общему ходу проекта. DevOps-группы в проектах цифровой трансформации должны стать потребителями объективных данных об информационных системах и инфраструктуре, чтобы своевременно принимать взвешенные и правильные для компании решения.

Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group.

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

Последствия такой недооценки встречаются на каждом шагу. Это всевозможные проблемы с информационными системами – как созревшие эволюционно (например, на фоне роста организации или при масштабировании ее ИТ-инфраструктуры), так и появившиеся вследствие внезапных, «революционных» событий (например, слияний и поглощений компаний, перехода на новые виды ПО и др.).

На первый взгляд, такие сложности кажутся совершенно разными и не связанными друг с другом. Так, рост на 30% в год объема данных, перерабатываемых организацией, и постоянные «зависания» учетной системы страшно далеки от неверного выбора основной информационной системы при слиянии двух крупных торговых сетей. Однако у этих проблем общий «корень» – отсутствие организованного и непрерывного потока компетенций в ИТ.

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

Поток компетенций: что это и зачем он нужен

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

Структура потока компетенций постоянно меняется, отражая изменения организации и ее информационной системы. Если изменения качественные (организация растет, открывает новые направления, наращивает число пользователей системы, в ИТ-службу постоянно приходят заявки на новый функционал), то для поддержки системы нужны квалифицированные системные администраторы, обладающие знаниями по операционной системе, СУБД, сети, виртуализации, оборудованию и пр.

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

Эволюция и революция одинаково опасны

Эволюционные изменения, через которые проходит практически любая ИС, тоже могут обернуться сложностями в ее работе. Например, автоматизированная система коммерческого учета на платформе «1С:Предприятие» может не справиться с объемом 1,3 Тбайт данных, хотя еще вчера с 1 Тбайт справлялась прекрасно. Или СУБД незаметно переходит критичный порог, и нехватка ресурсов становится причиной ее плохой работы. Наконец, у одного из серверов может закончиться память, и система, которая «крутилась» на нем, начинает работать очень плохо и медленно.

Чтобы контролировать, как меняется профиль работы информационной системы во время эволюции, и своевременно «купировать» нежелательные последствия изменений (цепочки сбоев, медленную работу, постоянные вылетания), сервисная компания должна все время «подкармливать» информационную систему заказчиков компетенциями. А служба, которая отвечает за эксплуатацию систем, должна в режиме реального времени отслеживать и контролировать их состояние, точно знать, как система чувствовала себя вчера, месяц и год назад, и понимать, как она должна вести себя завтра.

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

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

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

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

Изменчивость в квадрате

Революционные изменения в информационной системе рождают огромное число вопросов, для ответа на которые требуется непрерывный поток компетенций с разной структурой. Как эксплуатировать систему – и во время внесения изменений, и после завершения модернизации? Сколько людей потребуется для эксплуатации? Какие компетенции организация в силах обеспечить сама, а какие ей надо купить на условиях аутсорсинга? Одни изменения порождают другие, и в ходе внесения изменений требования к системе все время уточняются.

Так, при слиянии двух АБС невозможно написать всеобъемлющее техническое задание, которое будет актуально годы. Многие изменения рождаются уже в ходе проекта. Поменялись законодательство, руководство и политика компании, банки узнали что-то новое о бизнес-процессах друг друга. В результате может оказаться, что неверно выбрана платформа для объединенной системы, нужна другая, иногда совсем новая... Чтобы выстроить работу со всем спектром изменений, правильно провести их и проконтролировать, достигла ли компания запланированных целей, нужны уже совершенно иные компетенции – и с точки зрения проектного подхода, и с точки зрения управления изменениями, и с точки зрения архитектуры и инфраструктуры.

Все эти примеры показывают, что потребность и у стабильных, и у быстро меняющихся информационных систем в потоке компетенций крайне велика.

Как получить поток компетенций

Вариант №1 – инсорсинг. Компетенции накапливаются и поддерживаются внутри компании.

Минусы. Гарантированно получить компетенции по этой схеме очень сложно. Ставя знак равенства между людьми и компетенциями, компания приобретает всего лишь надежду на последние. Должно пройти как минимум полгода, чтобы стало понятно, «попала» она в точку со специалистом или нет. Если компания «не попала» – то насколько? Требуется ли человека уволить или достаточно будет его правильно дообучить? Однако уход обученного сотрудника (и отток компетенций) тоже частая ситуация. Иными словами, инсорсинг – не очень надежный способ приобретения компетенций. Их сложно оценить, получить, дотянуть до нужного уровня и удержать.

Плюсы. Модель не бесполезная: в госкомпаниях, например, есть класс систем (АСУ ТП, обсчет сложных математических моделей и др.), компетенции по которым просто невозможно найти на рынке. Единственный путь – наращивать их самостоятельно, начиная с вузов. Но и перспективной ее назвать трудно.

Вариант №2 – традиционный аутсорсинг. Компетенции привлекаются извне.

Минусы. Грамотного и квалифицированного ИТ-аутсорсера на нынешнем рынке «эквивалентных предложений» выбрать крайне сложно. Особенно если требуется, чтобы он закрывал все нужды корпоративного заказчика или хотя бы значительную их часть. Но и в этом случае клиент вряд ли сможет, сделав выбор, заключить договор и больше не думать о качестве ИТ-обслуживания. Как минимум он должен оценить сервисную компанию после испытательного срока, продумать подбор ИТ-специалистов на замену, если сотрудники аутсорсера вдруг стали уходить, и т.д. Модель опять несет нестабильность.

Плюсы. Найти тех, кто поможет с ИТ, можно, пусть и не без проблем. Однако надо помнить: любые изменения, например, законодательной базы или конъюнктуры рынка (такие как открытие ниши импортозамещения в ИТ), тут же приводят к тому, что нужных компетенций, скажем, по российскому ПО или решениям Open Source и их квалифицированной поддержке, снова нет. Они – пока штучный товар или слишком быстро исчезают с открытого рынка.

Вариант №3 – баланс между внутренним и внешними компетенциями плюс специализированные услуги.

Пресловутый баланс между внутренними и внешними компетенциями не должен существовать сам по себе. Его обязательно стоит дополнять специализированными компетенциями, ювелирно «упакованными» в сервисы: скажем, непрерывного мониторинга «здоровья» информационной системы, постоянного автоматизированного или автоматического сайзинга ресурсов, предотвращения просаживания приложений, самомониторинга систем. Отличительная черта таких услуг – возможность постоянно собирать и накапливать потоки информации, анализировать и сравнивать, как вела себя система вчера, год назад и т. п. А также прогнозировать, что с ней будет – завтра, через год, через три. Такие сервисы нельзя купить в виде «голых» технических инструментов. Они всегда опираются на накопленные и отшлифованные компетенции экспертов и специалистов, на применяемые ими инструменты и методологии. И решают, казалось бы, прежде нерешаемую задачу – например, позволяют практически любой крупной и средней организации очень точно покупать ресурсы в облаке, экономя до 50% бюджета на IaaS. Работа ключевых приложений (решений на базе «1С», CRM, СЭД, почты) при этом мгновенно «выравнивается», и пользователи перестают жаловаться. Машина при расчете не допускает ни недостатка, ни переизбытка ресурсов.

***

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

Автор – Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALPGroup, dmitriy.bessoltsev@alp.ru