Зачем системному администратору становиться программистом?

С начала 2021 года в Банке «Санкт-Петербург» начали активно развивать тему Devops. Подвижки и эпизодические успехи были и до этого, но каждая команда разработчиков выбирала свой путь по внедрению современного инструментария. Теперь вопрос стоит комплексно и системно. Но, чтобы достичь желаемого результата, нужны изменения. Мы к этому уже пришли и готовы поделиться опытом.

Начнем с базиса. Как я вижу DevOps: Development Operations — это синергия двух противоположностей — разработчики разрабатывают что-то новенькое, а операторы дрожат, чтобы это новенькое программное обеспечение нормально работало. Парадигма DevOps «починила» классическую схему, когда разработчик написал программу, тестировщик отправил багрепорты, программисты вернулись и всё поправили, а затем скинули весь труд по внедрению на эксплуатацию и побежали дальше заниматься новым проектом. С DevOps жизненный цикл приложения не делится на до и после — мосты по внедрению нового ПО наводятся в процессе разработки совместной работой команд девелоперов и системных администраторов. Объединенная команда продолжает заниматься этим приложением с точки зрения его улучшения и нормальной работы, мощности и стабильности до самого конца.

Чтобы избежать конфликта интересов Dev и Ops, IT пришло к тому, что айтишники могут программировать там, где раньше было нельзя. Инфраструктура доросла до того, что ее можно собрать программно из кода, хранящегося в репозитории. Так, на сцену выходят подходы IaaS (инфраструктура как сервис) и IaC (инфраструктура как код).

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

Грубо говоря, когда Ops начал программировать, он перешел на «темную» сторону силы, но вместе с этим начинается движение в правильном направлении. Админы не лезут руками на продуктовый контур. Если там возникают какие-то проблемы, то они обращаются к своему репозиторию, который является зеркалом продуктового контура. Исправляют ошибку, которая приводит к проблеме и заново деплоят на прод. Ручная работа уходит, а вместе с ней устраняется и человеческий фактор, ведь человек не может повторить все действия со 100% точностью в отличии от программы.

С виртуализацией повышается и скорость доставки ценностей до клиента — заметно сокращается Time To Market. Потому что уходят простои: не нужно ждать, пока придет запрошенный сервер.

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

Сейчас у нас в Банке слой виртуализации не доработан на 100% . Но есть успешные кейсы. Например, команда CRM научилась программным способом переливать тестовые зоны. У нас после установки очередного обновления на продуктивный контур нужно снять копию и сделать тестовую зону аналогичную продуктивной. Раньше это без преувеличения могло занять неделю, потому что администраторам нужно было сесть и скопировать 100500 хостов этого СRM на тестовую зону, а затем ещё переконфигурировать в соответствии с особенностями тестового контура. Теперь же все происходит буквально на глазах: отливаются зоны, появляются виртуальные машины, выполняются программы, запускаются и конфигурируются. Процесс заканчивался. Можно зайти в CRM и убедиться, что он работает. Он появляется на том адресе, где его ждут и начинается работа. Это действительно эффективно и быстро!

Но основное применение DevOps-практик в нашем банке происходит в ДД. Инженеры успешно работают над облаками (https://clck.ru/YicoV) — создание Private Cloud. По нашему плану, как говорили ранее (https://clck.ru/Yicgr), мы организуем private cloud, чтобы инженеры из любой точки могли виртуально «заказывать» серверы с необходимым ПО и мощностями. Так мы сможем приблизится к главной цели — стать более гибкими и уменьшить Time To Market.

Сейчас не всё программное обеспечение Банка готово к облачности, к работе в формате Lean-конвейера, но мы идём в наработку практик: DevOps, IaaS, IaC. Однако ПО — не единственный вызов, с которым мы столкнулись при внедрении практик.

Чтобы реализовать все задуманное, мышки должны стать ежиками — администраторы, люди, которые привыкли мышкой решать свои задачи, должны стать программистами. Это тяжёлое «переобувание», но у нас — в Банке «Санкт-Петербург» — запланирован большой апгрейд команды в плане обучения, в результате которого темпы перехода на IaaS и IaC будут существенно быстрые.

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