Подход 2 – «семь раз отмерь, один отрежь»

Всем привет! Мы продолжаем серию статей про разные подходы в применении практик DevOps, с которыми нам довелось встретиться в наших аутсорсинговых проектах, и о том, какие у них есть особенности, плюсы и минусы. 

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

Мы – компания iCore, оказываем услуги аутсорсинга DevOps и помогаем нашим клиентам сэкономить ресурсы на поиск и онбординг специалистов, усилить действующую команду и получить необходимые компетенции для решения задач, число которых постоянно растет.

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

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

Благодаря тому, что мы строили все «с нуля», а не взяли на поддержку уже работающую систему, нам удалось заложить в проект требования к приложению, которые существенно упростили его эксплуатацию в дальнейшем. Например, отсутствие персистентных точек монтирования дало больше гибкости. Для хранения данных используются СУБД PostgreSQL и объектные хранилища MinIO. Нет никакой привязки к NFS или блочным хранилищам. Это значительно упрощает и ускоряет масштабирование приложений или восстановление в случае сбоев. 

Интересная ситуация получилась с платформой контейнеризации. Изначально вся инфраструктура была запроектирована на RedHat OpenShift, все было протестировано, одобрено и готово к работе. Однако в один прекрасный момент западные вендоры, включая RedHat, ушли с российского рынка. А обязательным требованием заказчика было наличие действующей поддержки вендора в РФ, чтобы иметь возможность оперативно решать вопросы, связанные с работой ПО. В результате нам пришлось выполнить еще один подход к выбору и тестированию программной платформы, и Openshift заменили отечественным Deckhouse.

В отличие от нашей первой истории, где разработчики влияли на появление тех или иных решений, и могли без каких-либо согласований выкатить новый релиз, возможности dev-команды в этом заказчике очень сильно ограничены. Они могут самостоятельно выполнять сборку и тестирование только в dev-окружении. Для этого используют копию TeamCity, полностью изолированную от «боевого» окружения. А вот в Prod и Pre-prodвесь контроль за сборкой и деплоем находится в руках команды эксплуатации (то есть нас). Так исключается возможность ошибочных действий или нарушений регламентов со стороны разработчиков, и в Prod попадают только проверенные и согласованные релизы. Для тестирования разрабатываемых функций конечно же есть ограниченный набор точек взаимодействия с внутренними системами из Dev-окружения. Это позволяет устранить большинство ошибок до того, как с ними столкнутся пользователи. Так все заинтересованные стороны – и ИТ, и ИБ, и бизнес, гарантированно получают то, что им требуется.

Педантичный подход заказчика к своим приложениям и инфраструктуре можно наблюдать буквально во всем. Заранее подготовленные шаблоны позволяют быстро и удобно реализовывать новые пайплайны CI/CD. СУБД строятся только в кластерных конфигурациях и обеспечивают постоянную доступность данных. Контролируются версии используемого ПО, поддерживается ее актуальность. Изолированное использование ресурсов дает возможность управлять производительностью приложений.

Казалось бы – идеальная картина! Все продумано до мелочей, нет никаких костылей, обслуживать просто, можно масштабироваться, не переживая, что что-то пойдет не так, еще и все полностью задокументировано. Но в таком подходе есть свои сложности.

Самое главное – изменения происходят небыстро. Сначала нужно создать заявку, все согласовать, и только потом, когда ответственный до этой заявки доберется, можно получить то, что требуется.

Избыточное количество ресурсов – плата за надежность и стабильность. Если хочется минимизировать простои и обеспечить доступность 24/7, нужно быть готовым к дополнительным тратам на инфраструктуру и ее поддержку.

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

Продолжение следует!