Когда команда начинает разрабатывать приложение, всё обычно выглядит довольно просто. Репозиторий, сервер, база данных, иногда Docker, деплой через SSH — и вроде всё работает. На этом этапе почти никто не думает про DevOps, SRE, платформы разработки и прочие страшные слова.

Проблемы начинаются позже. Когда появляется staging, несколько сервисов, несколько разработчиков, релизы, миграции базы, мониторинг, логи, бэкапы, сертификаты, очереди, CDN, Kubernetes, облака. В какой-то момент оказывается, что инфраструктура стала сложнее, чем само приложение, и разработчики тратят время не на продукт, а на поддержку всего этого хозяйства.

И вот в этот момент компании начинают говорить про DevOps и SRE.

DevOps — это не про серверы

Есть распространённое заблуждение, что DevOps — это человек, который настраивает Kubernetes. На самом деле DevOps — это про скорость и стабильность разработки.

Есть очень известное исследование DevOps Research and Assessment (DORA) — это ежегодные отчёты Google, в которых анализируют тысячи компаний и команд разработки по всему миру. Они много лет изучают, почему одни команды выпускают изменения быстро и стабильно, а другие медленно и с постоянными авариями. (Google Research)

Самое интересное в этих исследованиях — вывод очень простой: производительность разработки определяется не количеством разработчиков и не технологиями, а процессом доставки изменений в production.

В DORA даже есть набор метрик, по которым можно понять зрелость разработки: как часто команда выкатывает изменения, сколько времени проходит от commit до production, как часто релизы ломаются и как быстро система восстанавливается после инцидента. (Splunk)

И это очень важная мысль для менеджмента: скорость разработки — это не скорость написания кода, а скорость доставки изменений пользователю.

Что реально ускоряет разработку

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

Самая важная — автоматические сборки и деплой (CI/CD). Когда код автоматически собирается, тестируется и выкатывается, релиз перестаёт быть событием. Он становится обычным процессом. Команда начинает выпускать маленькие изменения постоянно, а не большие релизы раз в месяц. Это снижает риск и ускоряет развитие продукта.

Вторая вещь — нормальные окружения. Когда есть dev, staging и production, и они похожи друг на друга, резко уменьшается количество ситуаций «у меня работало». Это экономит огромное количество времени.

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

И ещё одна недооценённая вещь — инфраструктура как код. Когда инфраструктура описана в коде, можно быстро создавать новые окружения, тестовые стенды, копии production. Это сильно ускоряет разработку новых сервисов и эксперименты.

Интересно, что исследования DevOps показывают: команды с автоматизацией релизов и инфраструктуры выпускают изменения чаще и восстанавливаются после сбоев быстрее, а это напрямую связано с успехом продукта и бизнеса. (Atlassian)

Инфраструктура разработки как платформа

В какой-то момент зрелые команды перестают воспринимать инфраструктуру как набор серверов. Они начинают воспринимать её как платформу разработки.

То есть разработчик не думает: куда задеплоить, как собрать контейнер, как настроить nginx, как сделать бэкап, как откатить релиз, как посмотреть логи.

Он просто пишет код, делает merge — и дальше всё происходит автоматически. Сборка, тесты, деплой, метрики, логи, алерты, rollback — всё уже настроено.

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

Что мы можем предложить

Я не большая аутсорс компания и не продаю «цифровую трансформацию». Я инженер, который много лет занимается инфраструктурой, CI/CD, Kubernetes, мониторингом и эксплуатацией систем, и могу помочь команде выстроить нормальный процесс разработки.

Обычно работа выглядит так: мы смотрим на текущую инфраструктуру и процесс разработки, после чего постепенно приводим всё к более зрелой модели. Появляются автоматические сборки и деплои, staging окружение, мониторинг, логирование, бэкапы, нормальный процесс релизов. После этого команда начинает выпускать изменения быстрее и с меньшим количеством проблем.

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

В обоих случаях цель одна и та же: сделать процесс разработки быстрым, предсказуемым и стабильным.

Главное

Самое важное, что стоит понять: DevOps и SRE — это не про Kubernetes, Terraform и Grafana.

Это про то, чтобы:

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

И когда это сделано правильно, компания начинает двигаться гораздо быстрее, даже если количество разработчиков не меняется.