Знаешь, я прочитал ту статью про инфраструктурные релизы, идентичность и консистентность. Красиво написано, складно. Прямо как в душноватом учебнике[1]. И даже местами правильно.
Но пока я читал, у меня в голове крутилась мысль (помимо той что очень много букав): «Где я это видел в реальности?» А нигде. За последний год я сменил четыре работы — банк, крупный онлайн-ритейлер, классическую аутсорс-разработку и бигтех. И в каждом месте подход к средам и релизам был настолько разным, что, если бы я попытался применить ту самую «консистентность» из статьи, меня бы либо уволили, либо засмеяли.
Это не попытка сказать «у всех всё плохо». Наоборот — в каждом случае система работала. Просто она работала в угоду бизнесу. А бизнес везде разный. Так что давайте без методичек, просто на примерах.
Банк. Там всё закручено так, что даже Jira потеет
Я — в банке. Первое, что вижу — доска в кабинете, на ней нарисована цепочка сред: dev, функциональный тест, интеграшка, нагрузка, препродакшн, продакшн, и ещё «реплика для аудита». Шесть штук, ёлки-палки. Перемещение кода из dev в следующий контур требует одобрений и заполнения Change Request с визами начальника отдела, архитектора и того парня, который сидит на этаже с безопасным пропуском.
У нас была чёткая ролевая модель: разработчик пишет код, тестировщик проверяет, DBA правит базу, сетевик открывает порты, SRE наблюдает за графиками [2], DevOps-инженер описывает плейбуки. И никто не лезет в чужую зону. Если разработчику нужно поменять переменную окружения, он заводит тикет в инфраструктурную команду. Ответ приходит через три дня.
Релизы — строго по расписанию. Всё заморожено, откатано, проверено регрессом. И да, это работает — стабильность на уровне «никаких сюрпризов». Но боже, как это медленно! Чтобы поправить критический баг, который валит функциональность, нужно собрать экстренную комиссию-коммитет, обосновать, убедить, проголосовать — и только после этого начинается движение.
И знаешь, я не могу назвать это плохим подходом. Просто бизнес-заказчики — это крупные юрлица, для которых downtime — это не потерянные деньги, а потерянное доверие. Им важнее предсказуемость, чем скорость. Поэтому тестовые контуры там идентичны проду практически до железа. Но эту идентичность оплачивают ожиданием.
E‑commerce. Тестируем в проде, потому что стейджинг сломался во вторник
Следующий проект — маркетплейс с миллионом заказов в сутки. Тут всё с ног на голову. У нас было два супермена-инженера SRE на всю компанию и 5 их подносчиков патронов. Они же разрабатывали платформу, они же дежурили по ночам, они же настраивали мониторинг. Остальной батальон человек в 500 — разработчики, которые сами катают свои сервисы в прод через GitLab CI [3].
Среды: у каждого разработчика локальный docker-compose. Есть один общий стейджинг, не выделенный в общей инфре никаким образом. И продакшн. Нагрузочное тестирование? Не слышали — просто выкатываем canary-версию [4] на 1% трафика и смотрим на графики в Grafana.
Релизы — десятки в день. Любой разработчик + его руководитель может задеплоить свою фичу с помощью фича-флага [5]. Если что-то пошло не так — вызов супермена и откат за 30 секунд, и только полетят логи. Ошибки ловили на продовых метриках, потому что стейджинг всё равно не давал реальной картины.
Каждую ночь — окно, в это окно можно было несильно что-нибудь уронить, но потом обычно алертило до утра. Но это позволяло компании двигаться быстрее конкурентов. Если ты первым добавил скидку на корзину или новый фильтр — ты уже заработал. Идентичность сред там была не нужна — нужна была наблюдаемость и быстрый откат. И да, нагрузочный стенд там никто не строил, потому что это дорого и медленно.
Аутсорс-галера. Гребём до берега, бросаем сторожа и берём новый остров
Третий опыт — компания, которая берёт проекты «под ключ». За год я успел поучаствовать в трёх. Везде была разная степень зрелости, но всё сводилось к тому, что каждый проект начинали с нуля, делали MVP, отдавали клиенту и бежали дальше.
Среды здесь — это чаще всего просто прод и одна тестовая виртуалка, на которой всё ломается. Дев-среды были на ноутбуках, потому что денег на облако не выделяли. Релизы — только под сдачу этапа. Мы на скилах гребли до очередной демки: доделывали фичи, закрывали баги, деплоили в продакшн клиента. Как только этап сдан — оставляем одного «сторожа» на полставки, который отвечает на звонки, а сами переключаемся на новый контракт. Если клиент через пару месяцев просыпается и просит доработки — снова бросаем все силы и гребём к новому берегу.
Там, конечно, идентичность сред — это была фантастика. Кто-то пользовался Ubuntu 18.04, кто-то CentOS 7, у кого-то был Kubernetes, у кого-то просто скрипты на rsync. Но это позволяло выживать бизнесу: заказная разработка не может себе позволить содержать дорогую инфраструктурную команду, которая год вылизывает CI/CD. Заказчик платит за функционал, а не за архитектурные шедевры. И если ты быстро «сделал» и «сдал» — ты молодец.
Бигтех. Ты владелец — ты и чини в три ночи
И напоследок — продуктовая компания с миллиардами запросов, тысячами микросервисов и огромной платформой. Здесь я увидел тот самый «инфраструктурный релиз», но в очень человеческом исполнении.
У каждого сервиса своя стратегия деплоя: кто-то использует канареечный, кто-то A/B-тестирование, кто-то просто фича-флаги и катит в прод по десять раз в час. Нет единого релизного календаря. Каждый инженер — владелец своего сервиса. Он пишет код, он настраивает мониторинг, он отвечает за алерты. И если его сервис упал в три ночи — ему звонят не в SRE-команду, а ему лично, потому что ротация — это его собственный номер телефона.
При этом есть жёсткая культура постмортемов [6]: если что-то сломалось, ты пишешь отчёт о корневой причине, и это разбирается на ретро. Без обвинений, но с очень внимательным анализом. Это дисциплинирует.
И баланс там получается удивительный: ты можешь катить всё, что хочешь, но ты же и будешь отвечать за последствия. Поэтому каждый сам решает, когда выкатывать, но перед этим прогоняет кучу автотестов, смотрит на канареечные метрики и просит коллегу взглянуть на код. Всё это без формальных Change Management, но с высокой личной ответственностью.
И что из этого следует?
А следует то, что универсального подхода не существует. Каждый раз ответ на вопрос «как управлять средами» упирается в три простые вещи:
-
Каков ваш бизнес? Консервативный, быстрый, проектный или продуктовый?
-
Какова цена ошибки? Если простой в час стоит 10 миллионов — тебе нужны все эти контуры. Если ты теряешь клиентов от того, что опаздываешь с фичей — забей на идентичность и кати в прод.
-
Кто принимает решение? Один инженер или комитет? От этого зависит, насколько ты можешь доверять автоматизации.
Поэтому, когда я читаю умные статьи про «консистентность сред», я не говорю «это неправильно». Я говорю «это один из инструментов». И как любой инструмент, его надо применять по месту. В банке — да, в e‑commerce — нет, в аутсорсе — смешно, а в бигтехе — только если ты сам готов за это ответить.
Так что, если ты сейчас сидишь в своей компании и думаешь «у нас всё криво» — возможно, так и надо. Пока бизнес жив и сервисы не падают, твой способ управления средами — правильный.
А если падают — ну, ты знаешь, что делать.
P.S. про ИИ почитать можно вдругом месте — тут не про него
Источники и дополнительное чтение
Если вы хотите глубже разобраться в упомянутых концепциях, вот проверенные материалы (все ссылки рабочие на момент публикации):
-
ITIL 4 — официальный сайт Axelos:
https://www.axelos.com/best-practice-solutions/itil -
Site Reliability Engineering (SRE) — книга от Google с открытым доступом:
https://sre.google/ -
Continuous Delivery — классика от Jez Humble и Dave Farley:
https://continuousdelivery.com/ -
Canary Releases — статья Мартина Фаулера:
https://martinfowler.com/bliki/CanaryRelease.html -
Feature Toggles (Feature Flags) — подробный разбор от Фаулера:
https://martinfowler.com/articles/feature-toggles.html -
Postmortem Culture — глава из SRE-книги Google о том, как проводить разборы инцидентов без поиска виноватых:
https://sre.google/sre-book/postmortem-culture/ -
Infrastructure as Code — принципы и инструменты (Terraform, Ansible):
https://www.terraform.io/intro
и классическая статья:
https://martinfowler.com/bliki/InfrastructureAsCode.html -
The Phoenix Project — книга-роман про DevOps, которая помогает понять культурные аспекты (рекомендую, если ещё не читали).
-
Accelerate — исследование DORA, которое показывает, что высокие показатели производительности и стабильности достигаются именно через автоматизацию и культуру, а не через длинные процессы:
https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling
ссылка на оригинал статьи https://habr.com/ru/articles/1070324/