Корпоративная ИТ-инфраструктура зачастую состоит из российских платформ, open source-компонентов, унаследованных систем и облачных сервисов. При этом команды по-прежнему часто отвечают каждая за свой продукт, а не за работу всей системы. Почему такой подход дает сбои и какие навыки потребуются инженерам в ближайшие 3–5 лет, рассказывает Сергей Карпенко, системный архитектор ГК «Умные решения».
Узкой специализации недостаточно
Долгое время инфраструктура строилась вокруг одного крупного вендора по понятной модели «одна система — одна команда — один регламент». Глубокого знания продукта хватало для большинства задач.
Сегодня в типичном ИТ-контуре, как правило, пять-семь производителей разной степени зрелости. У одного отличная документация и обученные интеграторы, у другого — молодой продукт и небольшое сообщество. Объект управления усложнился, при этом модель эксплуатации осталась прежней.
В результате инциденты все чаще возникают на стыке систем. Так, резервное копирование деградирует после изменения сетевой политики, СУБД и СХД рассинхронизируются после миграции. Ответственность за стыки при этом не закреплена, так как каждый специалист видит, что система работает штатно, а причина сбоя не входит в его компетенции или зону ответственности.
Пример. Компания поймала шифровальщика — злоумышленник вошел через уязвимость в веб-интерфейсе системы документооборота, получил права администратора домена, с их помощью отключил антивирус и за одну ночь зашифровал все серверы и рабочие станции. По отдельности все было «в порядке», ведь система создавала копии, антивирус установлен, домен работал. Однако копии лежали на той же СХД и были доступны с теми же учетными данными, что позволило преступнику зашифровать их вместе с остальными системами и данными.
В результате несколько дней компания фактически не работала. Учетную базу подняли из старого слепка, оставшегося после переезда на новый сервер, — потеряли больше двух месяцев данных. Сотрудники сверхурочно переносили данные с бумаги, а просроченная отчетность обернулась штрафами. Ни одна система не «сломалась» сама по себе.
Есть и риск, характерный для части российских продуктов. У производителя может смениться команда или собственник, а продукт — исчезнуть из реестра или уйти с рынка. Заменить поставщика технологии труднее, чем подрядчика по сопровождению.
В таких условиях специализация на конкретном элементе ИТ-инфраструктуры не исчезает, но перестает быть самодостаточной. Глубоко знать конкретную СУБД или СХД по-прежнему нужно, однако без понимания связей между всеми компонентами ИТ-ландшафта этого уже мало.
Кадровый долг
Число технологических связок в корпоративной инфраструктуре значительно выросло. При этом многие сочетания продуктов еще не успели пройти проверку длительной эксплуатацией, а специалистов с соответствующим опытом на рынке мало. Так возникает кадровый долг — компании внедряют новые технологии быстрее, чем готовят инженеров для их поддержки, и со временем этот разрыв увеличивается.
Последствия становятся заметны при сбоях. Поиск причин неполадок занимает больше времени, а уход одного-двух ключевых инженеров может серьезно осложнить поддержку инфраструктуры. Для бизнеса возрастают риски простоев и дополнительных расходов.
Оценить масштаб проблемы непросто. В 2023 году Минцифры опубликовало данные по общему дефициту ИТ-специалистов на уровне в 500–700 тыс. человек, но отдельной оценки для эксплуатационных ролей нет. По данным исследования K2 Cloud и hh.ru за 2024 год, DevOps-инженеров к числу наиболее сложных для найма специалистов отнесли 17% работодателей, инженеров ИТ-инфраструктуры — 14%.
При планировании ИТ-проектов компаниям приходится учитывать затраты на развитие компетенций наряду с расходами на лицензии и внедрение. Найти готового специалиста с опытом работы на конкретном сочетании продуктов сложно. Во многих случаях практичнее нанимать инженеров с хорошей базовой подготовкой и обучать их внутри компании.
Особенно остро проблема стоит в промышленности. В изолированных контурах АСУ ТП технологии обновляются медленно, молодые специалисты неохотно выбирают это направление, а опытные сотрудники постепенно уходят по возрасту. Возможности удаленной поддержки ограничены, поэтому предприятиям приходится привлекать инженеров для постоянной работы на площадках.
Автоматизация поляризует рынок
С развитием автоматизации меняется характер работы инфраструктурных инженеров. Простые операции и инциденты все чаще обрабатываются без участия человека, тогда как специалистам приходится заниматься более сложными и нестандартными задачами. Это позволяет компаниям сокращать численность эксплуатационных команд, одновременно повышая требования к квалификации сотрудников.
Изменения отражаются и на рынке труда. Растет ценность инженеров, способных разрабатывать сценарии автоматизации, поддерживать их работу и разбираться в причинах сбоев, которые выходят за пределы предусмотренных алгоритмов. Спрос на специалистов, выполняющих преимущественно стандартные операции, напротив, снижается. По оценке ЦМАКП, потребность в сотрудниках техподдержки, системных и сетевых инженерах базового уровня сократилась почти вдвое.
Для CIO это означает необходимость пересматривать подход к управлению ИТ-командами. Сокращение штата за счет автоматизации должно сопровождаться развитием компетенций оставшихся сотрудников. Иначе при возникновении нестандартного сбоя у компании может не оказаться специалистов, способных оперативно устранить его последствия.
Дополнительные возможности открывает искусственный интеллект. В ближайшие годы его применение позволит автоматизировать анализ логов, сопоставление событий при расследовании инцидентов, подготовку проектов регламентов и прогнозирование потребности в ресурсах. Однако при сложных авариях инженерам по-прежнему придется принимать решения на основе неполных данных, учитывать взаимосвязи систем и оценивать риски для бизнеса.
Как готовить инженеров к нестандартным сбоям
Инфраструктурные инженеры традиционно набирались опыта в повседневной работе. По мере автоматизации рутинных операций у начинающих специалистов остается все меньше возможностей для такой практики. Ситуацию осложняют изменения на рынке труда. Компании осторожнее нанимают молодых инженеров и предпочитают направлять средства на удержание сотрудников уровня Middle и выше.
В этих условиях практическую подготовку придется организовывать целенаправленно. Один из инструментов — chaos engineering (хаос-инжиниринг), предполагающий намеренное создание управляемых сбоев для проверки устойчивости инфраструктуры и отработки действий команды. Его можно дополнять симуляциями инцидентов, разборами реальных аварий и участием младших инженеров в дежурствах под контролем опытных коллег.
Такую подготовку необходимо включать в повседневную работу эксплуатационных команд. Иначе с расширением автоматизации компании рискуют столкнуться с нехваткой инженеров, способных самостоятельно разбираться в сложных аварийных ситуациях.
Базовый минимум ближайших лет
Одним из основных требований к инфраструктурному инженеру становится умение работать с инфраструктурой как кодом (IaC) и программными интерфейсами (API). Инструменты Terraform и Ansible позволяют воспроизводить конфигурации, сравнивать их с эталонными и откатывать изменения. Это упрощает диагностику сбоев, особенно если их причины связаны с взаимодействием нескольких систем.
Не менее важна наблюдаемость (observability) на уровне всей инфраструктуры. Инженеру необходимо понимать, какие данные собирать и как связывать события из разных систем, чтобы находить первопричину неполадок. Такой подход позволяет сократить время диагностики и избежать последовательной проверки каждого компонента.
В число базовых компетенций также войдет работа с контейнерами и системами оркестрации, программно-определяемыми сетями и хранилищами (SDN/SDS). Эти технологии постепенно становятся столь же привычными, как виртуализация. По мере их распространения сетевым и системным инженерам, а также специалистам по хранению данных приходится все глубже разбираться в смежных областях.
Этим требованиям соответствует T-shaped-профиль, предполагающий глубокую специализацию в одной области и понимание принципов работы смежных систем.
Кадровая реализуемость как часть архитектуры
Способность компании поддерживать архитектуру через три года надо оценивать еще до закупки. Некоторые риски видны уже при выборе продуктов.
При выборе решения на старте нужно выяснять, кто будет эксплуатировать систему и можно ли найти таких людей на рынке. Если архитектуру выбирают только по функциям и цене, эти расходы и риски остаются за скобками. Особенно осторожно стоит относиться к проектам, где больше двух продуктов моложе двух-трех лет и у них нет независимых интеграторов и сообщества.
Не менее важны документация и обучение. Если доступ к ним есть только у производителя, после его ухода знания могут исчезнуть вместе с ним. Эксплуатационная команда должна участвовать в обсуждении архитектуры до подписания контракта. Иначе ей придется исправлять просчеты, на которые уже нельзя повлиять.
Я бы ввел в проектную документацию раздел о кадровой реализуемости. В нем нужно прямо указать, кто будет поддерживать решение через три года, где искать этих специалистов и сколько они будут стоить. Такая оценка должна проводиться наравне с расчетом бюджета и проверкой требований ИБ.
Как изменятся инфраструктурные команды
В небольших компаниях системный администратор нередко совмещает обязанности DevOps-инженера, поскольку содержать отдельных специалистов слишком дорого. Однако зависимость от одного сотрудника создает серьезные риски, особенно если компания использует нестандартный набор технологий. Снизить их помогают подробная документация, совместная работа над критичными задачами и дублирование компетенций внутри команды.
В крупных компаниях появляются возможности для более узкой специализации. При достаточном масштабе инфраструктуры становится экономически оправданным создание платформ самообслуживания и отдельных команд platform engineering, SRE и информационной безопасности.
Здесь широкий опыт работы с различными системами служит основой для дальнейшего профессионального развития. Инженеры могут углублять экспертизу в выбранном направлении, сохраняя понимание смежных областей.
Я бы также предусмотрел в крупных проектах отдельную роль архитектора эксплуатации. Такой специалист должен еще на этапе проектирования оценивать возможности долгосрочной поддержки инфраструктуры. Сейчас эта ответственность часто распределена между архитектором решения и руководителем эксплуатации, которые подключаются к проекту в разное время.
Переобучать, нанимать или отдавать на аутсорс
ИТ-рынок остыл, но опытных специалистов на нем больше не стало. Найм готового эксперта — это по-прежнему долго и дорого. Переобучение своей команды требует времени и временно снижает производительность, но чем специфичнее инфраструктура, тем выгоднее растить экспертизу внутри.
Аутсорс закрывает дефицит рук, но не кадровый долг. Знания остаются у подрядчика, а доступ к критичной инфраструктуре создает риски цепочки поставок. Внешняя поддержка оправдана как временная мера, но опасна как постоянная зависимость.