Теперь, когда мы поговорили о том, к чему пришел DevOps в наши дни, самое время написать о том, что полезного (помимо уже сказанного) он нам принес.

Компании стали применять DevOps по-разному. Те, кто уже использовал популярные framework’и Agile, например Scrum, поставили инженеров в “продуктовые” команды. То есть у вас есть команда - разработчики, тестировщики, инженеры. Поскольку Scrum подразумевает кросс-функциональные команды, на выходе мы имеем разрабов, которые немножко сисадмины, и сисадминов, которые немножко разрабы.

В целом неплохо, и такая модель хорошо работает, правда у нее есть и свои недостатки. Например, когда у вас продуктовая команда как вещь-в-себе, она пилит проект так, как ей удобно. Платформа, ОС, язык программирования, DevOps tools - все выбирается самой командой и строго под ее нужды. Если у вас много продуктовых команд, то вы получаете потрясающий бардак и зоопарк, где команда А уже сидит в Кубере с этими вашим докером, а команда Б все еще делает golden AMI в AWS во время релиза новой версии приложения. Сравнить KPI (а топы очень любят KPI) таких команд тяжело, поэтому проверить эффективность той или иной команды становится тем еще приключением.

Другие конторы, чаще всего крупный сектор с headcount в 5000+ человек и миллиардным оборотом, стали делать отделы - отдел FrontEnd разработки (их может быть много), Baсkend разработки (тоже может быть много), отдел инфраструктуры и, простите, отдел DevOps.
Вроде silo - все сидят в своих уголках и что-то там делают. Взаимодействие уже не такое шустрое, люди могут сидеть в разных офисах, если не городах или странах - сложно просто подойти и поговорить ртом. Но и такой подход имеет право на жизнь, и вот почему.

Когда вы инженер в DevOps отделе, вы “поддерживаете” разработчиков. В ваших интересах, чтобы разрабы спокойно и без лишних проблем выкатывали новый код в production, а вы, если что, быстро его откатите обратно. Если вы инженер инфраструктурного отдела (допустим у вас в 2018-ом до сих пор свой ЦОД), то вам нужно, чтобы серверы и сеть работали без перебоев.
Такие потребности позволяют создать сервисно-ориентированные команды. Infra-команда не предоставляет железо - она предоставляет сервис, где каждый может “заказать” себе виртуалку. DevOps команда не предоставляет тулзы - она предоставляет сервис для управления приложениями.

Поскольку такие команды обладают бОльшей экспертизой в инструментарии, нежели сами разработчики, то они дают им один инструмент под определенную задачу, например, Puppet/Ansible/Chef для управления серверами, Terraform/Cloudformation для создания новых ресурсов, Jenkins/Teamcity для CI/CD, Github/Gitlab/GitUNameIt для хранения исходников, ну и всякие Linter’ы и прочие финтифлюшки. У разрабов особо нет выбора, и они пишут приложения, придерживаясь каких-то общих, зачастую навязанных административным ресурсом, стандартов.

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

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