Практики DevOps уже не являются чем-то новым и революционным. Польза от их применения давно подтверждена, и сейчас практически в каждой компании c in-house разработкой или там, где внедряются какие-то информационные системы, обязательно есть DevOps-специалисты. Это подтверждается стабильно растущим спросом на специалистов и сохраняющимся дефицитом кадров.

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

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

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

1.     Подход 1 – творческий беспорядок

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

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

Поначалу возникло ощущение, что локальная команда DevOps постоянно экспериментирует с технологиями, в какой-то момент это плавно становится prod-ом, а дальше уже поздно что-то менять – приходится все это эксплуатировать. 

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

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

Еще интересный факт: во время аудита мы обнаружили, что все узлы HA-кластера RabbitMQ оказались на одном физическом сервере. А клиент был уверен, что в случае отказа сервера данные сохранятся на резервном.

Были у нас вопросы и к СУБД. Разбег используемых версий PostgreSQL – от 9 до 13, все настроены по-разному. На один кластер размещали до 5 баз данных, которые могли относиться к разным проектам. Была ситуация, когда начали поступать жалобы на низкую производительность трех разных нагруженных приложений и частые ошибки 504. При изучении проблемы выяснилось, что все три базы данных располагались на одном кластере PostgreSQL 9 с дефолтными настройками. К тому же еще и на медленных HDD-дисках.

Почему так получилось? Общаясь с командой, мы поняли: инженеры просто не успевали за ростом запросов. Каждый новый проект требовал инфраструктуры "еще вчера", планировать, оценивать риски и делать проверки не было времени. К тому же не всегда хватало нужных компетенций — что-то новое изучалось на ходу, в процессе решения текущих задач.

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

Для хранения данных наш клиент использует сервис WebDAV. Каждый проект создавал там собственные папки с иерархией по принципу «имя_ГГММДД-ЧЧММ». И директории стали наполняться огромным количеством мелких файлов (до 15 миллионов на проект). В результате простейшие команды вроде ls зависали и завершались OOM killer’ом из-за нехватки памяти. Это делало невозможным мониторинг и контроль за ростом файлов. В результате вся работа команды DevOps сводилась к регулярному добавлению дискового пространства, чтобы временно решить проблему переполнения.

Еще пример. Один кластер ELK использовался для работы с логами одновременно DEV и PROD-контуров, и переполнение логами с одного контура могло полностью блокировать возможность мониторинга и анализа логов с другого контура. Так и случилось – в какой-то момент резко возросло количество логов с DEV-контура, Elastic решил, что он находится в критическом состоянии и перестал принимать вообще любые логи. Они стали копиться в Kafka – она начала быстро расти в размерах и переполняться. Проблему довольно быстро заметили, почистили лишнее, добавили еще пространства, и система снова начала работать. Хорошо, что за это время не случилось никаких инцидентов в проде, и логи не потребовались для их расследования.

Со стороны многие процессы и технические решения выглядят неоптимальными и даже иногда ошибочными. Но есть важный нюанс — при всем этом "хаосе" решается главная задача: бизнес работает стабильно, разработчики получают нужные им ресурсы, релизы выходят в срок. Иногда важнее быстро получить нужные ресурсы или запустить сервисы, чем потратить месяцы на построение идеально продуманного решения. Минимум препятствий, минимальный time to market – это тоже стратегия, которая может быть оправдана на определенном этапе развития компании. 

Усиление ИТ-команды нашего клиента инженерами iCore дало свежий взгляд на привычные вещи и позволило начать планомерное движение в сторону более надежных и оптимальных решений. Мы не пришли с готовыми рецептами "как cделать правильно". Мы попытали��ь сначала понять логику существующих решений, структурировать накопленные знания, а только потом предлагать изменения. 

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

Проводя аудит, мы действовали как археологи: по крупицам собирали ценные знания, которые хранились в головах людей и набросанных "на коленке" схемах. Часть информации удалось собрать спокойно — в долгих встречах с локальными командами DevOps. А часть пришлось добывать "в бою", решая возникающие проблемы и параллельно раскапывая, как устроена та или иная система.

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

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

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