Очень часто в вакансиях пишут «DevOps Engineer». Что это за роль? И роль ли это? Что такое вообще DevOps? Какие она в себя включает практики? Почему название позиции DevOps инженер звучит некорректно? Этим вопросам и посвящена статья.
Любая компания, связанная с разработкой или внедрением программного обеспечения, стремится двигаться быстрее и быть как можно гибче. Для этого требуется максимальная вовлеченность разработчиков во все стадии жизненного цикла процесса разработки ПО. Давайте задумаемся, с чего начинается и чем заканчивается этот цикл программного обеспечения. Начинается с планирования — это знают практически все. Но чем он заканчивается? Деплойментом? А куда и как мы деплоимся? Когда заканчивается вовлеченность разработчика в процесс? Стоит ли ему вовлекаться в принципе? И вообще, важно ли то, на какой платформе будет размещаться написанное тобою ПО. Важны ли ресурсы, которые вы под него отведете? Как быстро вы будете обновлять его? Давайте проследим эволюцию процесса.
Как было раньше
Когда только начиналась промышленная разработка программного обеспечения, каждый разработчик был сам себе бизнес-аналитик, архитектор, верстальщик, девелопер, тестировщик, девопс и поддержка 24/7 в одном флаконе. Какие это таило в себе недостатки? Иногда получались достаточно корявые и не понятные для стороннего пользователя продукты. Трудно было представить, что творилось в голове того или иного индивида. И еще один минус — сосредоточение всех сакральных знаний в одной светлой голове, которая могла заболеть, уйти к конкурентам, да и просто уехать отдыхать на Гоа. Однако в этом были и плюсы. Инженер сразу задумывался о полном цикле жизни своего продукта. Тут не было надежды на всемогущего админа, который придет и все решит за тебя. За любой косяк приходилось расплачиваться самому и это не заставляло себя долго ждать.
Потом произошло то, что всегда происходит при переходе к массовому производству, — отраслевое разделение. Появились админы, которые управляли инфраструктурой приложения, и разработчики, которые это приложение разрабатывали. Я не говорю о верстальщиках, инженерах по качеству, бизнес-аналитиках и других, нисколько не умаляя их заслуг в процессе разработки. Так вот, после разделения для многих девелоперов цикл жизни программного обеспечения стал заканчиваться командой «git push», при закрытии последнего бага. Также на ситуацию повлияла специфика бизнеса — аутсорс стал доминировать. Многие доставляли код, как сырье, не задумываясь о конечном результате, о том, как и где все это будет размещаться. Это могло продолжаться вечно, если бы не несколько факторов.
Причины появления культуры и зачем Devops нужен?
Первым фактором стало появление ряда продуктовых контор, в которых задумались не только о том, как локально решить ту или иную проблему, а о глобальных решениях. Тут не пройдет локальный костыль, с которым потом придется разбираться другим. Надо осознавать, что дальше придется жить с этим костылем, а поэтому нужно решать что-то на уровне инфраструктуры. Приходится начинать разрабатывать, опираясь на то, где будет размещаться конечный продукт.
Если первый фактор еще может показаться достаточно спорным, то второй — более однозначный. Это широкое развитие облачных сервисов, которые освещают курсы devops, отказ от хостинга на своих серверах и поддержки своей инфраструктуры как таковой. Выбранная инфраструктура начала определять архитектуру приложения. AWS, Azure, Heroku, DigitalOcean начали делать за вас вашу работу. Теперь не надо без особой потребности придумывать 1001 вариант написания балансера или шардинга — это все доступно из коробки. Это снизило количество велосипедов на квадратный метр, но этот подход, в свою очередь, требует знания инфраструктуры сервисов и адаптации своих продуктов под них.
Кроме того, микросервисная архитектура внесла свою лепту в переосмысление девелоперами инфраструктуры приложения. Теперь недостаточно «наструячить» очередной модуль и залить его в репозиторий, предоставив деплоймент-инженерам угадывать переменные конфига. Нет, теперь надо думать, как это все будет взаимодействовать друг с другом, потому что эта конфигурация может не взлететь даже в вашей песочнице, а отправлять непроверенный код — это как-то уж совсем чересчур.
Платформы начали определять реализацию приложений, поэтому разработчик не может написать хорошее приложение без знаний о платформах. Разработчиков стали привлекать к операционной работе. Появилась культура DevOps. Почему не роль? Потому что DevOps-практик и девопс инженер - это те, о ком речь пойдет ниже, должны внедряться на уровне компании, а не на уровне отдела или группы. Люди в компании должны знать и о разработке программного обеспечения, и тонкости использования инфраструктуры.
DevOps-культура, по-моему, — это следующая ступень эволюции FullStack-парадигмы, в которой команды реализуют не отдельные части приложения, а решают всю задачу. Одному человеку охватить эти задачи достаточно сложно, и такой процесс надо вести во всей компании или группе. Причем первое, что надо сделать, убрать роль DevOps-инженера как таковую.
Практики и что должен знать Devops?
Теперь давайте поговорим о практиках DevOps. Они достаточно неплохо описаны в книге «DevSecOps The Road to Faster, Better and Stronger Software». Давайте рассмотрим главные из них.
- «Automate everything» — автоматизируй все, что можно. Уменьшай количество «ручной» операционной работы. Делаешь, что-то два раза — придумай, как это автоматизировать. Это ускорит все процессы и сведет количество ошибок к минимуму. Работать должен робот, человек должен отдыхать и заниматься мыслительным процессом!
- «Configuration management». Docker приходит к нам на помощь в конфигурации, сохранении и менеджменте всего, что нам нужно для успешной работы приложения. Оркестрация контейнеров может осуществляться при помощи таких тулов, как Kubernetes или Docker Swarm.
- «Infrastructure as Code». Подразумевается, что подход к конфигурированию приложений должен быть таким же, как и к коду. Если раньше в конфигурации системы через консоль не было ничего зазорного, то сегодня стало уже плохим тоном не использовать для этих целей инструменты автоматизации, такие как Terraform, Chef, Puppet и т. д. Эта практика позволяет оптимизировать ресурсы, а также значительно ускорить время поставки.
- «Continuous Deployment». Автоматическое выкатывание готовых фич на рабочее окружение. И если раньше CD-системы были игрушкой только для разработчиков, то теперь они активно используются для автоматизации накатки изменений в конфигурациях. Эта практика позволяет оптимизировать ресурсы, а также сводит участие человека в процессе поставки к минимуму.
- «Application monitoring». Если раньше системы мониторинга представляли из себя различные способы «скирдования» логов, то теперь это мощный инструмент для мониторинга состояния вашего приложения. На анализ логов не надо тратить дни и недели, вы можете настроиться на ту или иную метрику и смотреть за изменениями в режиме реального времени. Кроме сугубо технических моментов, например количества запросов, перформанса, загрузки CPU, вы с помощью таких систем, как Prometheus, можете собирать и внутренние характеристики приложения, значимые для вашего бизнеса.
Это далеко не все практики, которые составляют культуру DevOps. Однако, как мы можем заметить, они представляют из себя набор методов и инструментов, при использовании которых можно решить проблему быстрой и качественной поставки ПО конечному потребителю, а также как можно быстрее получить от него обратную связь в качестве метрик.
Выводы
DevOps культура — это то, что должно культивироваться на уровне компании. Команды должны не только уметь реализовать фичу, но и организовать процесс тестирования, доставки и обратной связи с конечным потребителем. DevOps практики призваны облегчить жизнь всем — разработчикам, операционистам и системным администраторам , бизнесу, потому что именно они являются тонкими ниточками между, на первый взгляд несовместимыми отраслями.
