DevOps и SRE просто модно
Всем привет, Хабровчане!
Хочу рассказать про современный мир IT и его подходах. Сегодня каждая компания говорит про DevOps и более чем уверенна, что он у них есть. Читая вакансии на множестве ресурсов, я часто вижу объявления «требуется DevOps инженер» с расписанным стеком тех или иных модных инструментов. Но вот что самое интересное, что больше ничего и не требуется, главное знать как пользоваться теми самими инструментами. То есть «DevOps инженер» — это такой оператор, который знает куда тыкать и где просто нужно описать пайпллайн, не вдаваясь в подробности разработки. Когда эта методология только пришла к нам, порог вхождения был довольно высок, а сегодня пара курсов дают пропуск в этот мир и это грустно.
Ну ладно, к чему я это все, в больших компаниях, а именно «кровавый энтерпрайз» бывают легаси проекты, где нет современных инструментов и переход на них иногда невозможен, или он дороже самой разработки. Вот как раз в этот момент и требуется настоящий подход методологии DevOps, где порой нужно ковыряться как в коде, так и в разработке своих реализаций того, что не предоставляется из коробки. Какими же знаниями и компетенциями должен обладать Ops инженер?
Как мне кажется, ops инженер должен иметь основные знания и представления в области разработки, речь не идет о том что он должен знать полностью ООП. Но уметь понять что написано в программе при ее развертывании и «траблшутинге», а не просто в случае падения бежать к команде разработки со словами — «Все не работает, разбирайтесь и напишите как развертывать». Также помогать команде разработки в принятии архитектурных решений, а не просто выполнять таски в рамках спринта.
Сегодня, пайплайн для CI можно написать вообще без его понимания, роли в ansible также не стоит труда найти на просторах git репозиториев.
Давайте на примере, как-то на одном из проектов был java продукт. Этот сервис время от времени падал, а именно из-за памяти, логи ничего не показывали, мы со стороны SRE команды настроили сброс дампа приложения в случае падения, далее стали разбирать при помощи Eclipse Memory Analyzer (MAT). В итоге, после нашего разбора мы нашли место утечки памяти и посмотрели на отчет потоков, выяснилось что поток замыкался на себе и уходил в вечное ожидание. Суть в том, что мы уже с анализом и указанием места в коде, пришли к команде разработки. Что мы получили вот от таких наших действий? Мы получили быстрый фикс и выкатили это в прод. Мы ускорили процесс! И получили результат. Мы не ждали пока разработчики посмотрят и решат в свободное время проблему и приложение на продакшене будет аффектить клиентов.
Еще из примеров, подхода методологии и концепции. Не так давно я поменял место работы, в новом месте используется TeamCity. Вроде бы ну CI система и что, но вот в компании выкатка происходит в виде релизов, то есть собирается список компонентов, а потом в отведенное время происходит их развертывание на продакшене (continuous delivery) и вот первый релиз, и ребята в UI TeamCity руками тыкают кнопки выбирая ветки и джобы. На один компонент уходило 2/3 минуты, а их было 28, то есть минимум 56 минут. Такой подход меня не устроил, я принял решение написать утилиту для ускорения процесса, а также более простого представления самого релиза. Вот тут можно посмотреть на утилиту https://github.com/sergey-show/teamcity-deploy
Суть утилиты в том, что самописный инструмент покрыл то, чего не было из коробки. Теперь описание релиза хранится в репозитории в виде yml файла, далее утилита сверяет его и применяет в TeamCity посредством API, запуская все джобы одновременно (если нет требований по приоритету).
В итоге релиз из 28 компонентов выкатывается в течении 15 минут с последующей проверкой. Получилось 15 минут вместо 56 минут, на сэкономленное время можно пойти почитать, погулять или отдохнуть. То есть это решение нам позволило ускориться и исключить фактор человеческой ошибки.
Еще один из частых примеров, что доводилось встречать, упаковывать в контейнеры и в k8s все без разбора. Внедрять k8s потому-что модно. А многие ли задаются вопросом — «а вот нужно ли?».
Концепция сборки должна быть такой, сам сервис или код должен собираться так, чтобы его можно было упаковать и развернуть где угодно (со схожей архитектурой конечно-же).
И таких примеров у меня много, инструменты меняются и их можно выучить, а вот подход и мышление в этой методологии это основополагающая.
Всем добра и позитива, развивайтесь, обучайтесь и творите:-)
