Поймите, что Вернер Фогельс имел в виду под «You Build It, You Run It» и как это применить: владение сервисом, дежурства, SLO, реакция на инциденты и безопасные релизы.
«Вы построили — вы поддерживаете» — одна из тех фраз, которые остаются в памяти своей прямолинейностью. Речь не о мотивационных постерах или «стать более DevOps». Это чёткое заявление об ответственности: команда, которая выпускает сервис, также несёт ответственность за то, как этот сервис ведёт себя в продакшене.
На практике это значит, что та же продуктовая команда, которая проектирует фичи и пишет код, также:
Это не значит, что все внезапно становятся экспертами по инфраструктуре. Это значит, что обратная связь реальна: если вы выпустили что-то, что увеличивает число аутеджей, шум от пейджеров или боль для клиентов, ваша команда почувствует это напрямую — и быстро научится.
Философия легко произносится и трудно внедряется, если вы не проявите её как операционную модель с явными ожиданиями. «Run it» обычно включает дежурства (в одной из форм), ответственность за инциденты, написание ранбуков, поддержку дашбордов и постоянное улучшение сервиса.
Это также подразумевает ограничения: нельзя требовать от команд «run it», не дав им инструментов, доступа и полномочий всё исправлять — и времени в роадмапе на эту работу.
До «You Build It, You Run It» многие компании работали как эстафета: разработчики писали код, затем «передавали через стену» операционной команде, которая деплоила и держала систему в живых.
Такая передача решала краткосрочную проблему — кто-то опытный смотрит за продакшеном — но создавала более серьёзные: медленную обратную связь и смытую ответственность.
Когда отдельная ops-команда владеет продакшеном, разработчики часто узнают о проблемах поздно (или не узнают вовсе). Баг может прийти в виде неопределённого тикета через несколько дней: «сервис медленный» или «CPU высокий». Контекста уже нет, логи прокручены, а люди, которые сделали изменение, уже переключились на другое.
Передачи также размывают ответственность. При аутейдже разработчики могут думать «ops разберётся», а ops — «dev выпустил что-то рискованное». Результат предсказуем: дольше решаются инциденты, повторяются те же ошибки, и культура оптимизирует локально, а не для пользовательского опыта.
«You Build It, You Run It» сужает цикл обратной связи. Та же команда, что выпускает изменение, отвечает за то, как оно ведёт себя в проде. Это ведёт к практическим улучшениям «вверх по потоку»: понятнее алерты, безопасные раскатки, лучшие дашборды и код, который проще эксплуатировать.
Парадоксально, но это часто ускоряет доставку. Когда команды доверяют процессу релиза и понимают поведение в продакшене, они могут выпускать меньшие изменения чаще — уменьшая радиус поражения ошибок и облегчая диагностику.
Не у всех организаций одинаковый штат, требования соответствия или наследуемые системы. Эта философия — направление, а не рубильник. Многие команды внедряют её постепенно: начинают с совместных дежурств, лучшей наблюдаемости и чётких границ сервисов, а затем переходят к полному end-to-end владению.
Вернер Фогельс, CTO Amazon, популяризовал фразу «You build it, you run it», описывая, как Amazon (а затем и AWS) хотел, чтобы команды думали о ПО: не как о проекте, который передают, а как о сервисе, которым оперируют.
Ключевой сдвиг был психологическим не меньше, чем техническим. Когда команда знает, что её будут пейджить при сбоях, решения в дизайне меняются. Вы заботитесь о разумных дефолтах, понятных алертах, грациозном дегрейде и путях деплоя, которые можно откатить. Иными словами, разработка включает в себя планирование «грязных» частей реальной жизни.
Эра AWS сделала надёжность и скорость обязательными. Клиенты облака ожидают доступных API 24/7 и непрерывных улучшений — не только большие релизы раз в квартал.
Это стимулировало:
Философия пересекается с движением DevOps: сократить разрыв между «dev» и «ops», уменьшить передачи и сделать исходы (доступность, латентность, нагрузка на поддержку) частью разработки. Это также соответствует идее мелких автономных команд, которые могут выпускать изменения независимо.
Соблазнительно брать подход Amazon как шаблон. Но «You Build It, You Run It» — скорее направление, чем строгое орг-устройство. Размер команды, регуляторные ограничения, зрелость продукта и требования аптайма могут потребовать адаптаций — совместные ротации, поддержка платформы или поэтапное внедрение.
Если нужен практический план перевода мышления в действие, переходите к /blog/how-to-adopt-you-build-it-you-run-it-step-by-step.
«You Build It, You Run It» — прежде всего заявление об ответственности. Если команда выпускает сервис, она отвечает за то, как сервис ведёт себя в реальном мире — не только за прохождение тестов в день релиза.
Эксплуатация сервиса означает заботу о результатах end-to-end:
В обычную неделю «run it» — это не героические подвиги, а рутинная эксплуатация:
Модель работает только если ответственность означает «мы исправим», а не «мы ищем виновного». Когда что-то ломается, цель — понять, что в системе допустило это (отсутствие алертов, неясные лимиты, рискованные деплои) и улучшить эти условия.
Владение становится хаотичным, когда сервисы размыты. Определите границы сервиса (что он делает, от чего зависит, что обещает) и назначьте именованную команду-владельца. Это снижает число передач, ускоряет реагирование на инциденты и делает приоритеты понятными, когда надёжность и фичи конкурируют.
Дежурства центральны для «You Build It, You Run It», потому что они замыкают цикл обратной связи. Когда та же команда, что выпускает изменения, также чувствует их операционные последствия (скачки латентности, неудачные деплои, жалобы клиентов), приоритеты становятся яснее: работа над надёжностью перестаёт быть «чужой проблемой», и самый быстрый путь к более частым релизам — сделать систему спокойнее.
Здоровое дежурство прежде всего про предсказуемость и поддержку.
Определите уровни серьёзности, чтобы система не будила по каждой мелочи.
Простое правило: если пробуждение человека ничего не изменит — это тикет, а не пейдж.
Дежурства — не наказание; это сигнал. Каждый шумный алерт, повторяющаяся ошибка или ручной фикс должны превращаться в инженерную задачу: лучше алерты, автоматизация, безопасные релизы и изменение системы, которое устранит необходимость пейджить вовсе.
Если «вы run it» реально, командам нужен общий язык для обсуждения надёжности без превращения каждой дискуссии в мнения. Именно это дают SLI, SLO и error budget: чёткие цели и справедливый баланс между скоростью и стабильностью.
Полезная памятка: SLI = метрика, SLO = цель, SLA = внешнее обязательство.
Хорошие SLI специфичны и связаны с UX, например:
Error budget — это количество «плохого времени», которое вы можете потратить и всё ещё соответствовать SLO (например, при SLO 99.9% ваш месячный error budget — 0.1% простоя).
Когда сервис «в пределах» бюджета, команды могут брать больше рисков (фичи, эксперименты). Когда бюджет «сгорает» слишком быстро — приоритет на надёжность.
SLO превращают надёжность в входной параметр планирования. Если бюджет мал, следующий спринт может быть посвящён rate limiting, безопасным раскаткам или фиксу флейковых зависимостей — потому что пропуск SLO имеет явную цену. Если бюджет в запасе, можно уверенно приоритизировать продуктовые задачи.
Модель работает, только когда деплой в продакшен рутинен, а не событие с высокими ставками. Цель — снизить неопределённость перед запуском и ограничить радиус поражения после него.
Перед тем как считать сервис «готовым», командам обычно нужны базовые операционные вещи:
Вместо релиза для всех сразу, progressive delivery ограничивает влияние:
Если вы стандартизируете откат — относитесь к нему как к первоклассной возможности: чем быстрее вы сможете безопасно вернуть состояние, тем более реалистичной становится модель «вы run it».
Два типа тестов снижают «неизвестное неизвестное»:
Держите его лёгким: одностраничный чек-лист в репозитории или шаблоне тикета (например, «Observability», «On-call readiness», «Защита данных», «План отката», «Тесты ёмкости», «Ссылки на ранбуки»). Статус «не готов» нормален — лучше, чем учиться в продакшене.
Инциденты — момент истины для «you run it»: сервис деградирует, клиенты замечают, команда должна быстро и ясно реагировать. Цель — не героизм, а воспроизводимый workflow, который уменьшает вред и даёт улучшения.
Большинство команд сходятся на похожих фазах:
Если нужен практический шаблон, держите лёгкий чек-лист под рукой (см. /blog/incident-response-checklist).
Безвиновный постмортем не значит «никто не ошибался». Это значит, что фокус на том, как система и процессы позволили ошибке дойти до продакшена, а не на поиске виновных. Именно это побуждает людей делиться информацией быстро и открыто.
Документируйте:
Хорошие постмортемы заканчиваются конкретными, оформленными задачами, обычно в четырёх категориях: инструменты (лучшие алерты/дашборды), тесты (регрессии и крайние случаи), автоматизация (безопасные деплои/откат, гардрейлы) и документация (ранбуки, понятные операционные шаги). Назначьте владельца и срок — иначе обучение останется теорией.
Инструменты — это рычаг, делающий «You Build It, You Run It» устойчивым, но они не заменят реального владения. Если команда считает операционку «чьей-то чужой проблемой», самая навороченная панель лишь задокументирует хаос. Хорошие инструменты снижают трение: они делают правильное действие (наблюдаемость, реагирование, обучение) проще, чем неправильное (угадывать, винить, игнорировать).
Командам-владельцам нужен единый способ видеть поведение софта в продакшене и быстро действовать, если что-то не так:
Если история мониторинга фрагментирована, команды тратят время на охоту вместо фикса. Единый подход к наблюдаемости помогает; см. /product/observability.
При росте организации вопрос «кто владеет этим?» сам по себе становится риском. Каталог сервисов (или внутренний developer portal) решает это, храня оперативный контекст в одном месте: имя команды, ротация on-call, путь эскалации, ранбуки, зависимости и ссылки на дашборды.
Ключ — актуальные метаданные владения. Сделайте это частью workflow: новые сервисы не идут в прод без владельца, а смены владения проходят как изменения кода (review, аудит).
Лучшие решения подталкивают команды к здоровому поведению: шаблоны ранбуков, автоматические алерты, связанные с SLO, дашборды, которые за секунды отвечают на вопрос «насколько пользователи пострадали?». Но человеческая система остаётся важнее — командам нужно время поддерживать эти инструменты, чистить алерты и улучшать эксплуатацию сервиса.
Платформенные команды упрощают жизнь и делают «You Build It, You Run It» более приемлемым. Их задача — не запускать продакшен за все команды, а дать хорошо освещённую дорожку, чтобы продуктовые команды могли владеть сервисами без изобретения операционки каждый спринт.
Хорошая платформа даёт безопасные дефолты, которые трудно испортить и просто принять:
Гардрейлы должны предотвращать риск без блокировки релиза. Думайте «secure by default», а не «открывай тикет и жди».
Платформа может запускать общие сервисы — не забирая при этом владение продуктовыми сервисами.
Граница проста: платформа владеет аптаймом платформы; продуктовые команды владеют тем, как они используют платформу.
Когда команды не обязаны становиться экспертами в CI/CD, auth или секретах с первого дня, они могут сосредоточиться на поведении сервиса и влиянии на пользователя.
Примеры, снижающие рутину:
Результат: быстрее доставка и меньше «операционных снежинок», при сохранении основной идеи: команда, что строит сервис, его и поддерживает.
Модель может повысить надёжность и скорость — но лишь при условии, что организация меняет условия вокруг команды. Частые провалы выглядят так, будто лозунг приняли, а привычки нет.
Типичные шаблоны:
Некоторым средам нужна адаптация:
Философия рушится, когда операционную работу считают «дополнительной». Руководство должно явно выделять ресурсы на:
Без этой защиты дежурство превращается в налог, а не в обратную связь, улучшающую систему.
Лучше всего вводить это фазами, а не объявлением на весь офис. Начните с малого, сделайте владение видимым и постепенно масштабируйте.
Выберите один ограниченный сервис (лучше с чёткими пользователями и управляемым риском).
Определите:
Ключ: команда, выпускающая изменения, также владеет операционными результатами сервиса.
Прежде чем расширять практику, убедитесь, что пилотная команда может эксплуатировать сервис без героизма:
Небольшой набор индикаторов покажет, улучшается ли владение:
Если вы внедряете «you build it, you run it» и одновременно хотите ускорить доставку, узким местом часто остаётся путь от идеи до продакшен-готового сервиса с ясным владением и историей отката.
Koder.ai — платформа vibe-coding, которая помогает командам строить веб-, бэкенд- и мобильные приложения через чат-интерфейс (React на фронте, Go + PostgreSQL на бэкенде, Flutter для мобильных).
Для команд, которые хотят взять на себя владение сервисами, несколько возможностей Koder.ai прямо соответствуют операционной модели:
Выберите пилотный сервис на этой неделе и запланируйте 60‑минутный kickoff для установки первого SLO, ротации on-call и владельцев ранбуков. Если вы оцениваете инструменты для поддержки этого процесса (доставка, откат и рабочие процессы владения), посмотрите /pricing для планов Koder.ai (free, pro, business, enterprise) и опции хостинга, деплоя и кастомных доменов.
Это значит, что команда, которая проектирует, создаёт и деплоит сервис, также отвечает за то, что происходит с ним после выхода в продакшен: мониторинг, дежурства, разбор инцидентов и улучшение надёжности.
Это модель ответственности (чёткое владение), а не выбор инструмента или смена должностей.
Это не означает, что каждый инженер должен стать специалистом по инфраструктуре на полный рабочий день.
Это значит:
При отдельной ops-команде обратная связь приходит поздно, а ответственность размывается: разработчики меньше ощущают последствия в продакшене, а операционные инженеры не всегда знают контекст последних изменений.
Владение end-to-end обычно улучшает:
«Run it» обычно включает в себя:
Начните с гуманных установок:
Хорошая система дежурств ставит целью сократить число страниц в следующем месяце, а не нормализовать героизм.
Правило простое: если поднятие человека посреди ночи не изменит исход — это тикет, а не page.
Практически:
Они дают единый язык надёжности:
Если бюджет быстро сгорает — приоритет на надёжность; если бюджет в порядке — можно рисковать функциональными изменениями.
Практики, которые снижают неопределённость и радиус поражения:
Ведите инцидент как воспроизводимый workflow:
Затем делайте безвиновные постмортемы (blameless), где фокус — на том, как система и процессы позволили ошибке дойти до продакшена. Действия по результатам должны быть конкретными, с владельцем и сроком.
Платформа должна дать «павированные дорожки» (paved roads): шаблоны, CI/CD, защитные барьеры и общие сервисы, при этом не забирая на себя ответственность за продуктовые сервисы.
Практический раздел ответственности:
