«You Build It, You Run It»: философия эксплуатации сервисов

Кратко о принципе «You Build It, You Run It»

Фраза «You Build It, You Run It» чаще всего связывается с Вернером Фогельсом (Werner Vogels) — техническим директором Amazon. Он популяризировал этот тезис в контексте построения больших распределённых систем, где скорость изменений и качество сервиса зависят не от отдельного отдела эксплуатации, а от того, насколько команда разработки чувствует последствия своих решений в продакшене.

Что это означает простыми словами

Если команда создаёт сервис, она же отвечает за его работу после релиза: доступность, производительность, ошибки, мониторинг, реагирование на инциденты и постепенное улучшение. Это не про то, что «все становятся админами», а про то, что ответственность не заканчивается мерджем в main.

На практике принцип превращает «сделали фичу и передали дальше» в цикл: спроектировали → внедрили → наблюдаем → исправили → улучшили. Команда начинает принимать решения с учётом реальной эксплуатации: как сервис ведёт себя под нагрузкой, насколько понятны алерты, что будет при сбое зависимости.

Почему идея стала поворотной

Раньше во многих компаниях существовала жёсткая граница между разработкой и эксплуатацией: одни «пишут», другие «держат». Это создавало конфликт целей: скорость релизов против стабильности. «You Build It, You Run It» выравнивает мотивацию — качество становится частью результата, а не «чужой проблемой».

Кому будет полезна эта статья

• Продуктовым ролям — чтобы понимать цену качества и почему «быстрее» без операционной готовности в итоге обходится дороже.
• Инженерным командам — чтобы выстроить владение сервисом, не скатываясь в хаос и героизм.
• Операционным и SRE/DevOps ролям — чтобы настроить правила, инструменты и границы ответственности.

Если вы хотите прийти к предсказуемым релизам и устойчивым сервисам, дальше в статье мы разложим принцип по конкретным практикам — от метрик и SLO до on-call и постмортемов.

Какие проблемы решала философия до её появления

До появления принципа «You Build It, You Run It» во многих компаниях доминировала классическая схема: разработка делала функциональность и «передавала» её отдельной команде эксплуатации. У каждой стороны были свои KPI и своя логика успеха: разработчикам — быстрее выпускать фичи, эксплуатации — удерживать стабильность и снижать изменения.

Модель «разработка отдельно, эксплуатация отдельно»

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

Типичные симптомы разрыва

Когда сервис падал или начинал тормозить, появлялась знакомая «игра в пинг‑понг»:

• на релизах — конфликты из‑за рисков и сроков («нам нужно сейчас» vs «мы не готовы»);
• при инцидентах — перекидывание ответственности между командами («это баг» vs «это инфраструктура»);
• в повседневной работе — слабая обратная связь: проблемы в продакшене не превращались в улучшения кода достаточно быстро.

Почему падала скорость поставки

Скорость часто снижалась не из‑за сложности фич, а из‑за очередей: согласования, ручные проверки, ожидание дежурного инженера, окна релизов. Любой шаг вне команды превращался в зависимость, а зависимость — в задержку.

Риски для клиентов без владельца сервиса

Когда у сервиса нет «хозяина», качество размазывается: никто не отвечает за пользовательский опыт целиком. Это приводит к повторяющимся инцидентам, долгому восстановлению, непредсказуемым релизам и, как следствие, к потерям доверия, денег и репутации.

Ключевая идея: ответственность за результат, а не за задачи

Принцип «You Build It, You Run It» часто ошибочно воспринимают как организационную перестановку: «теперь разработчики дежурят». Но суть глубже — команда отвечает не за набор задач в трекере, а за итоговый результат работы сервиса для пользователей и бизнеса.

Когда ответственность заканчивается на «фича сделана и смёржена», появляется привычная передача эстафеты: дальше «пусть эксплуатация разберётся». В модели Вернера Фогельса команда — единый владелец результата: от идеи и кода до продакшена, метрик качества и реакции на инциденты. Это меняет приоритеты: важными становятся не только скорость доставки, но и предсказуемость, устойчивость и качество.

Почему это ускоряет обратную связь

Самый сильный эффект — быстрый возврат ошибок к тем, кто менял систему. Если команда сама видит последствия релиза (падение доступности, рост задержек, неожиданные ошибки), то учится на реальных сигналах, а не на догадках. Обратная связь становится короткой и конкретной: «вот изменение — вот эффект — вот исправление».

Как снижается «стоимость изменений»

Ответственность за результат неизбежно приводит к дисциплине: автоматизации проверок, аккуратным релизам, понятным откатам, лучшей документации. Команда начинает проектировать изменения так, чтобы их было безопасно выпускать и так же безопасно отменять. Стоимость изменений падает не «магией», а практиками, которые предотвращают пожары.

Фокус на опыте пользователя

Результат измеряется глазами пользователя: сервис должен быть доступным, быстрым и выдавать корректные данные. Это не абстрактные «технические KPI», а простые вопросы:

• Может ли пользователь выполнить ключевое действие прямо сейчас?
• Сколько времени это занимает?
• Насколько результат верен и стабилен?

Именно такой фокус превращает «сделали задачу» в «доставили ценность и удержали качество» — основу «You Build It, You Run It».

Что именно должна «владеть» команда сервиса

Принцип «You Build It, You Run It» работает только тогда, когда у команды есть чёткая зона владения: не «мы написали код и передали дальше», а «мы отвечаем за то, как сервис ведёт себя у пользователей». Владение — это набор обязательств, которые нельзя делегировать полностью, даже если часть работ выполняют другие.

Граница ответственности: что входит в «run»

Минимальный контур «run» обычно включает:

• мониторинг и алерты: команда определяет, что считать проблемой и какой сигнал должен подниматься ночью;
• релизы и откаты: команда управляет выпуском изменений и снижением риска (через фиче‑флаги, канареечные релизы и т. п.);
• инциденты: первичная реакция, диагностика, восстановление, участие в разборе причин;
• эксплуатационная документация: «как понять, что сломалось» и «что делать в первые 10 минут».

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

Интерфейсы между командами: договорённости вместо ожиданий

Чтобы владение не превращалось в хаос, нужны интерфейсы между командами:

• API и контракты (что гарантируем потребителям и при каких условиях);
• понятная документация и каналы поддержки (например, очередь заявок и время реакции);
• правила изменений: как объявляются breaking changes, как мигрируют клиенты.

Фактически, это «социальные SLO»: ожидания по поддержке и качеству взаимодействия.

Роль платформенной команды

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

Когда уместна выделенная эксплуатация

Выделенная эксплуатация бывает оправдана (регуляторика, 24/7 для критичных систем, сложная инфраструктура), но принцип сохраняется, если:

• ownership за SLO, релизы и решения остаётся у команды сервиса;
• эксплуатация работает как партнёр и эскалационный слой, а не как «приёмка проблем»;
• есть общие постмортемы и единый бэклог улучшений надёжности.

Метрики, SLO и ожидания качества сервиса

Если команда не договорилась, что значит «сервис работает хорошо», принцип You Build It, You Run It быстро превращается в бесконечные споры: «у нас всё зелёное» против «клиенты жалуются». Метрики и цели надёжности нужны не ради отчётности, а чтобы у всех — разработки, продукта и поддержки — была общая система координат.

SLI, SLO и SLA: зачем нужны и чем отличаются

• SLI (Service Level Indicator) — измеримый показатель качества: доля успешных запросов, p95 задержки, процент ошибок, время доставки события и т. д.
• SLO (Service Level Objective) — цель по SLI на период: «99,9% успешных запросов за 30 дней» или «p95 < 300 мс». Это внутренняя договорённость, по которой команда управляет рисками.
• SLA (Service Level Agreement) — внешнее обязательство перед клиентом (часто с компенсациями). Обычно SLA мягче, чем SLO, чтобы оставался запас.

Практика: держите SLO как “истину” для инженерных решений, а SLA — как юридически безопасное обещание.

Как выбрать 2–5 ключевых метрик сервиса

Хороший набор — небольшой, но покрывает главное. Часто используют четыре «золотых сигнала»:

• Доступность: доля успешных операций (например, HTTP 2xx/3xx) по ключевым ручкам.
• Задержка: p95/p99 для пользовательских сценариев, а не среднее.
• Ошибки: 5xx, таймауты, ошибки бизнес-валидации отдельно (чтобы не смешивать «плохие данные» и «сломанный сервис»).
• Насыщение (saturation): CPU/пул соединений/очереди/лимиты внешних зависимостей — то, что первым упирается в потолок.

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

Error budget: как он задаёт темп релизов

Error budget — это допустимый «запас ошибок» относительно SLO. Например, при SLO 99,9% на 30 дней бюджет недоступности — около 43 минут.

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

Как связать надёжность с целями продукта и поддержкой

SLO стоит выбирать по критичности сценариев: вход, оплата, поиск, создание заказа — обычно важнее второстепенных функций. Согласуйте:

• с продуктом — какие сбои реально влияют на конверсию/удержание;
• с поддержкой клиентов — какие симптомы они видят и как быстро должны получить сигнал об инциденте;
• с бизнесом — где достаточно “best effort”, а где нужен строгий уровень сервиса.

Хороший признак зрелости: по SLO можно ответить на вопрос «мы сейчас в норме?» быстрее, чем по переписке в чатах.

Наблюдаемость: чтобы «run» был реальным, а не формальным

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

Минимальный набор сигналов

Базовая комплектация почти всегда одинакова: логи, метрики и трассировки.

Критически важно связать их между собой. Практичный минимум — корреляция по request-id: один идентификатор запроса проходит через API, очереди, базы и соседние сервисы. Тогда по алерту можно за минуты перейти от симптома к конкретному участку кода или зависимости.

Алерты: сигнал, а не шум

Хороший алерт — это, в первую очередь, симптом, заметный пользователю: рост ошибок 5xx, увеличение задержки, падение успешных платежей. Алерт на «причину» (например, CPU 95%) чаще должен быть предупреждением и поводом посмотреть тренды.

Добавьте уровни срочности:

• Page — требуется реакция сейчас (нарушение SLO, пользовательский ущерб).
• Ticket/Warning — можно разобрать в рабочее время (дрейф ресурсов, рост очередей, деградация зависимости).

Дашборды для разных аудиторий

Один дашборд не подходит всем. Разработчикам нужны технические детали (ошибки по эндпоинтам, p95/p99, зависимости). Поддержке — «жив ли сервис» и понятные статусы. Менеджерам — влияние на пользователей и прогресс восстановления.

Game day: проверяем до инцидента

Практика game day (контролируемые сбои) помогает убедиться, что метрики снимаются, логи полезны, трассировки не обрезаны, а алерты действительно ведут к диагнозу. Это способ сделать «run» реальной обязанностью, а не формальной строкой в регламенте.

On-call и инциденты: правила, которые защищают команду

On-call — это дежурство, когда команда сервиса берёт на себя первую линию реакции на сбои: алерты, деградации, недоступность, ошибки релизов. В «You Build It, You Run It» on-call — не наказание, а механизм обратной связи: качество инженерных решений становится заметным через реальную эксплуатацию.

Как сделать on-call устойчивым

Устойчивость начинается с понятных правил: график, ротация, эскалации.

• Ротации: короткие смены (например, неделя) и предсказуемый календарь уменьшают стресс.
• Эскалации: заранее определите, кого и когда подключать (вторая линия, дежурный менеджер, смежные команды), чтобы один человек не оставался «один на один».
• Тишина по ночам: поднимайте ночью только то, что реально требует немедленных действий (например, нарушение SLO/критический бизнес‑ущерб).

Runbook/Playbook: что должно быть внутри

Хороший runbook сокращает время до восстановления и снижает когнитивную нагрузку.

Минимум, который стоит описать: симптомы и критерии серьёзности, быстрые проверки, безопасные действия (перезапуск, откат, переключение), ссылки на дашборды и логи, контакты для эскалации, «что не делать».

Постмортем без поиска виноватых

Постмортем пишут, чтобы система стала надёжнее, а не чтобы найти «кто виноват». Структура проста: таймлайн, первопричины и способ обнаружения, что сработало/не сработало, конкретные задачи (владельцы, сроки) и проверка, что улучшения реально снизили риск повторения.

Как измерять нагрузку on-call и снижать её

Считайте: число алертов на смену, долю ложных срабатываний, ночные пейджи, время до реакции/восстановления, повторяемость инцидентов.

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

Релизы без страха: автоматизация и снижение риска изменений

Страх релизов появляется там, где изменения большие, редкие и плохо измеряемые. В модели «You Build It, You Run It» команда сама несёт последствия обновлений, поэтому цель — сделать выпуск изменений рутинной, предсказуемой процедурой, а не событием «на удачу».

CI/CD как фундамент спокойных релизов

CI/CD — это не «конвейер ради конвейера», а набор обязательных страховок. Минимальный базис: автоматические тесты, статические проверки, сборка артефактов, прогон миграций в безопасном режиме и единая политика отката.

Важно заранее договориться, что считается «зелёным» релизом: какие проверки обязательны, кто имеет право нажать deploy и в какой момент релиз считается завершённым (например, после 30–60 минут стабильных метрик).

Feature flags помогают отделить выкладку кода от включения функциональности. Это снижает давление: вы можете доставить изменение, а включить его позже — постепенно и измеримо.

Практичный нюанс: если вы ускоряете разработку через LLM-инструменты или vibe-coding, важно так же ускорять и «операционную часть» — шаблоны SLO, чек‑листы готовности, заготовки runbook’ов. Например, в TakProsto.AI (платформе для vibe-coding на российской инфраструктуре) удобно начинать проект в режиме планирования, а затем сразу получать воспроизводимую структуру приложения (фронтенд на React, бэкенд на Go с PostgreSQL) и использовать снапшоты/rollback как страховку при частых релизах.

Безопасные схемы выкладки: canary и blue/green

Безопасный релиз — это релиз с ограниченным радиусом поражения.

Canary: сначала отправляйте 1–5% трафика на новую версию, следите за ошибками, задержками и бизнес‑метриками, затем расширяйте долю.

Blue/green: держите две среды, переключайте трафик целиком, но с возможностью быстрого возврата. Это удобно для сервисов с простым состоянием или хорошо контролируемыми миграциями.

Поэтапное включение (по регионам, клиентским сегментам, группам пользователей) даёт дополнительный контроль и позволяет остановиться, не «роняя всех».

Релиз как гипотеза: управляйте изменениями через наблюдаемость

Относитесь к релизу как к гипотезе: «после изменения X метрика Y не ухудшится более чем на Z». Для этого заранее подготовьте дашборды и алерты под конкретный релиз: ошибки, p95/p99 задержек, насыщение ресурсов, очереди, а также ключевые продуктовые показатели.

Если метрики «поплыли», действие должно быть заранее определено: откат, выключение флага или заморозка дальнейшего развёртывания.

Как ограничить риск: меньше, чаще, измеримее

Самый надёжный способ снизить риск — уменьшить размер изменений и выпускать их чаще. Небольшие PR легче проверять, проще разбирать в инцидентах и быстрее откатывать.

Успех релиза должен быть выражен числами и временем наблюдения: что именно смотрим и сколько ждём стабильности. Тогда команда перестаёт бояться релизов не потому, что «повезёт», а потому что у неё есть контроль, измерения и понятный план действий.

Операционная готовность: что проверить до выхода в продакшен

Операционная готовность (operational readiness) — это момент, когда команда честно отвечает: «если сервис сломается в 03:00, мы сможем быстро понять, что произошло, ограничить ущерб и восстановиться». Без этого принцип «You Build It, You Run It» превращается в формальное дежурство, а не в управляемую эксплуатацию.

Признаки готовности сервиса

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

Типичные признаки:

• команда может быстро определить: «это инцидент или просто шум»;
• есть понятный путь от алерта к действиям (runbook), а не только графики;
• известны зависимости (БД, очереди, внешние API) и их критичность;
• можно безопасно откатить релиз или отключить проблемную фичу.

Мини‑чек‑лист перед продакшеном

Проверяйте не «вообще», а по категориям — это ускоряет ревью готовности.

Мониторинг и алерты: ключевые метрики (ошибки, задержка, нагрузка), алерты с порогами и подавлением флаппинга, дашборд «для дежурного».

Документация: короткий README «как работает», схема зависимостей, runbook на 3–5 частых аварий, контакты владельцев.

Бэкапы и восстановление: регулярность бэкапов, проверка восстановления (не только наличие), понятные RPO/RTO хотя бы на уровне договорённостей.

Планы восстановления: что делать при недоступности зависимости, деградационный режим (например, read‑only), критерии переключения.

Безопасность и доступы

Эксплуатация невозможна без дисциплины доступа:

• минимальные привилегии (не раздавайте «админов» по умолчанию);
• аудит действий в продакшене и ротация ключей;
• хранение секретов в предназначенном для этого хранилище, без «секретов в конфиге».

Как сделать готовность частью Definition of Done

Чтобы не спорить перед каждым релизом, включите operational readiness в DoD для новых сервисов и значимых изменений:

• «без алертов и runbook — не готово»;
• «без проверенного восстановления — не готово»;
• «без описанных зависимостей и владельцев — не готово».

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

Люди и культура: как внедрять без выгорания

Принцип «You Build It, You Run It» работает только тогда, когда он воспринимается как способ улучшать сервис, а не как наказание. Если команда слышит «теперь вы вечно дежурите», она начнёт защищаться: реже релизить, избегать изменений и «перекладывать» ответственность. Правильный посыл другой: команда получает полномочия и контроль над качеством — и поддержку, чтобы это было устойчиво.

Не «разработчики = on-call 24/7», а понятные правила

Дежурства — часть работы, но в рамках ограничений:

• фиксированная ротация и расписание заранее;
• право «остановить конвейер» (временно заморозить релизы), если качество просело;
• после тяжёлого инцидента — время на восстановление и работу над причинами, а не «догоняйте фичи ночью».

Баланс времени: продукт vs улучшения

Чтобы эксплуатация не пожирала команду, договоритесь о квоте на улучшения: например, 20–40% времени на надёжность, автоматизацию, уменьшение ручных операций. Это не «технический долг ради красоты» — это инвестиция, которая снижает количество инцидентов и ускоряет будущие релизы.

Если команда маленькая

Когда людей мало, классический on-call быстро становится токсичным. Рабочие варианты:

• расширенная ротация с участием соседних команд (второй уровень поддержки);
• «платформенная» помощь: единые инструменты алертинга, шаблоны дашбордов, типовые runbook’и;
• офисные часы поддержки вместо ночных вызовов, если сервис и бизнес позволяют.

Профилактика выгорания: алерты, качество, процессы

Главный враг — шум. Введите лимиты: если алертов слишком много, это дефект системы наблюдения. Улучшайте сигналы, добавляйте подавление повторов, переводите часть уведомлений в «тикеты на разбор». И обязательно проводите постмортемы без поиска виноватых: цель — изменить систему, чтобы следующая ошибка стала менее вероятной и менее болезненной.

Практический план внедрения для команды и компании

Внедрение «You Build It, You Run It» лучше начинать не с реорганизации всей разработки, а с аккуратного пилота: один сервис, одна команда, прозрачные цели и измеримый результат. Так вы быстро увидите узкие места (в метриках, алертах, правах доступа, процессах релизов) и сможете масштабировать подход без хаоса.

С чего начать: пилот и цели

Выберите сервис со стабильной командой и понятной ценностью для бизнеса. Зафиксируйте 2–3 цели на период пилота: например, сократить время обнаружения инцидента, уменьшить число ручных операций при релизе, повысить выполнение SLO. Важно заранее договориться, что «успех» измеряется метриками, а не количеством написанных задач.

Пошаговый план на 4–8 недель

Недели 1–2: метрики → алерты. Определите ключевые пользовательские метрики (доступность, задержки, ошибки), настройте дашборды и минимальный набор алертов, которые действительно требуют действий.

Недели 2–4: runbooks. Для каждого алерта — короткая инструкция: что проверить, как локализовать проблему, как временно стабилизировать сервис, когда эскалировать.

Недели 4–6: on-call. Запустите дежурства сначала в «щадящем» режиме (например, только в рабочие часы) и обязательно обеспечьте ротацию, компенсации и право останавливать опасные релизы.

Недели 6–8: постмортемы. После инцидентов проводите разбор без поиска виноватых, фиксируйте действия по предотвращению повторений и обновляйте runbooks/алерты.

Что стандартизировать на уровне компании

Наиболее полезны единые артефакты: шаблон SLO, стандарт алертов, минимальный набор дашбордов, формат runbook, правила постмортема и чек‑лист «операционной готовности» для новых сервисов. Это ускоряет запуск команд и делает ожидания качества одинаковыми.

Если у вас часть команд делает продукты через быстрые прототипы (включая решения на базе LLM), стандартизация особенно важна: скорость создания не должна опережать скорость «доведения до эксплуатации». В этом смысле помогают платформы вроде TakProsto.AI: вы можете быстрее собрать приложение из чата, развернуть и захостить его, подключить домен, а затем удерживать качество через дисциплину релизов (снапшоты и откат) и понятные критерии готовности.

Где искать полезные материалы

Если вы собираете внутреннюю базу знаний, удобно держать подборку практик и примеров в /blog, а подход к поддержке и опциям сопровождения — на /pricing, чтобы командам было понятно, что можно автоматизировать самостоятельно, а где нужна помощь платформы или SRE.

Итоги и чек‑лист: насколько вы близки к принципу

Сводка: что меняется

«You Build It, You Run It» — это не про то, чтобы «разработчики начали чинить серверы». Суть в другом: команда перестаёт сдавать работу «по задачам» и начинает отвечать за результат сервиса в продакшене.

На практике меняются три слоя одновременно: ответственность (один владелец end‑to‑end), процессы (SLO, инциденты, постмортемы, управление изменениями) и инструменты (наблюдаемость, автоматизация релизов, безопасные переключатели, понятные runbooks).

Чек‑лист: «мы действительно живём по You Build It, You Run It»

Отметьте «да/нет».

• Команда сервиса может ответить: какие SLO, какой error budget и как он влияет на релизы.
• Есть понятная наблюдаемость: метрики, логи и трассировки позволяют быстро найти причину деградации.
• On-call формализован: расписание, правила эскалации, компенсации/выходные, понятные ожидания.
• Инциденты заканчиваются постмортемом без поиска виноватых и конкретными улучшениями (в бэклоге есть техдолг по надёжности).
• Релизы безопасны: автоматизированные проверки, быстрый откат, canary/blue‑green (или другой контролируемый механизм).
• Перед запуском изменений есть минимум операционной готовности: алерты, runbooks, доступы, нагрузочные/хаос‑проверки по необходимости.

Типовые ошибки внедрения — и как исправить

Чаще всего ломает не техника, а перекосы:

1. «Дежурьте, но без полномочий» → дайте команде право менять приоритеты и останавливать релизы при исчерпании error budget.

2. «SLO есть, но ими никто не управляет» → свяжите SLO с решениями: что делаем при нарушениях, кто и когда.

3. «Наблюдаемость формальная» → начните с золотых сигналов (latency/traffic/errors/saturation) и доведите алерты до действия.

Следующий шаг

Если вы отметили «нет» в 3–4 пунктах, выберите один сервис и проведите быструю диагностику: SLO → on-call → наблюдаемость → релизы. Затем зафиксируйте ближайшие 2–3 улучшения как обязательные условия следующего крупного запуска.

Начать можно с малого: одного SLO, одного дежурства «по правилам» и одного runbook, который реально помогает в 3 ночи.