Любая компания, связанная с разработкой или внедрением программного обеспечения, стремится двигаться быстрее и быть как можно гибче. Для этого требуется максимальная вовлеченность разработчиков во все стадии жизненного цикла процесса разработки ПО. Давайте задумаемся, с чего начинается и чем заканчивается этот цикл программного обеспечения. Начинается с планирования — это знают практически все. Но чем он заканчивается? Деплойментом? А куда и как мы деплоимся? Когда заканчивается вовлеченность разработчика в процесс? Стоит ли ему вовлекаться в принципе? И вообще, важно ли то, на какой платформе будет размещаться написанное тобою ПО. Важны ли ресурсы, которые вы под него отведете? Как быстро вы будете обновлять его? Давайте проследим эволюцию процесса.
Как было раньше
Когда только начиналась промышленная разработка программного обеспечения, каждый разработчик был сам себе бизнес-аналитик, архитектор, верстальщик, девелопер, тестировщик, девопс и поддержка 24/7 в одном флаконе. Какие это таило в себе недостатки? Иногда получались достаточно корявые и не понятные для стороннего пользователя продукты. Трудно было представить, что творилось в голове того или иного индивида. И еще один минус — сосредоточение всех сакральных знаний в одной светлой голове, которая могла заболеть, уйти к конкурентам, да и просто уехать отдыхать на Гоа. Однако в этом были и плюсы. Инженер сразу задумывался о полном цикле жизни своего продукта. Тут не было надежды на всемогущего админа, который придет и все порешает за тебя. За любой косяк приходилось выгребать самому и расплата не заставляла себя долго ждать.
Потом произошло, то что всегда происходит при переходе к массовому производству, — отраслевое разделение. Появились админы, которые управляли инфраструктурой приложения, и разработчики, которые, собственно, это приложение разрабатывали. Я не говорю о верстальщиках, инженерах по качеству, бизнес-аналитиках и других, нисколько не умаляя их заслуг в процессе разработки. Так вот, после разделения для многих девелоперов цикл жизни программного обеспечения стал заканчиваться командой «git push», при закрытии последнего бага. Также на ситуацию повлияла специфика бизнеса — аутсорс стал доминировать. Многие доставляли код, как сырье, не задумываясь о конечном результате, о том, как и где все это будет размещаться. Это могло продолжаться вечно, если бы не несколько факторов.
Почему появилась культура 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 практики призваны облегчить жизнь всем — разработчикам, операционистам, бизнесу, потому что именно они являются тонкими ниточками между, казалось бы, на первый взгляд несовместимыми отраслями.
Эта статья — нулевая в цикле материалов по DevOps практикам. В течение месяца я буду писать по одной статье, которая будет давать введение в культуру DevOps. Цикл будет включать такие темы:
- Тестирование, все что вы хотели спросить, но стеснялись. Новый взгляд на TDD.
- Bash. Знай друга в лицо.
- Инфраструктура web-приложения в AWS на примере Node.js.
- Docker. Контейнеры. Оркестрация. Docker Swarm. ECS. Kubernetes.
- CI. Jenkins. Зачем напрягать роботов, или Когда разработчики глубоко спят.
- IaC. Terraform, или Почему не надо менеджить инфраструктуру руками.
- Application monitoring. AWS Cloud watch. Prometheus.
О культуре DevOps советую почитать:
- Quora: What is a DevOps role?
- Bash scripting — видео
- Docker: Get Started, Part 1: Orientation and setup
- What are the best Docker orchestration tools?
- Terraform from Hashicorp
- Jenkins getting started