Service Ownership

«У нас всё в SRE team» — один из ответов, который я регулярно слышу на вопрос «кто owner этого сервиса?». Это не ownership. Это размазанная ответственность, и она перестаёт работать на первом же инциденте: никто не помнит, кто принимает решения, runbook не обновляется, sunset невозможен. Service ownership — это конкретный человек или конкретная команда как accountable owner, зафиксированный в catalog и связанный с deploy, on-call, dashboards и SLO. Практика базовая, внутри L1 IT Management, и без неё сыпется всё, что опирается на owner: SLO Review, ротация дежурств, change governance.

Что должен уметь

Главный навык на уровне L5 — превратить catalog из странички для чтения глазами в то, что реально крутит автоматизацию. Я регулярно вижу каталоги, которые не читает ни одна система, только люди. Такой каталог устаревает за полгода: запись завели один раз и больше не трогали, через два года половина в нём — про выключенные сервисы. Он оживает, когда из него собираются ротация дежурств, дашборды и список того, что вообще разрешено катить. Пока он только для людей, его никто не поддерживает.

Знает структуру владения сервисами своей команды; находит owner любого боевого сервиса за минуту.
Обновляет запись в service catalog после смены owner / on-call / runbook.

Ведёт service catalog для своих сервисов: owner, on-call rotation, SLO, runbook, зависимости, текущий статус (production / deprecated / sunset).
Пересчитывает белые пятна: сервисы без владельца, без runbook, без SLO; собирает список и назначает, кто его закрывает.

Внедряет service catalog как единый источник истины; систематически вытесняет дублирующие записи (wiki, spreadsheet, устные договорённости).
Связывает catalog с автоматизацией: deploy pipeline / on-call rotation / dashboards / SLO-метрики читают данные из catalog, а не из дублей.
Проводит передачу владения при реорганизациях — выключение сервиса, миграция, смена владельца — с явным дедлайном и проверкой, что она дошла до конца.

L6+

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

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 11 «Being On-Call». Раздел о связи дежурства с владением — основа всей модели.
Matthew Skelton, Manuel Pais — Team Topologies (IT Revolution, 1-е изд. 2019, 2-е изд. 2025). Глава про границы владения и когнитивную нагрузку: почему общая ответственность работает хуже, чем кажется на бумаге.

Статьи

Backstage Software Catalog documentation — практический справочник по модели записи о сервисе (kind, owner, lifecycle, depends-on). Подходит как стартовая точка для собственной структуры.

Инструменты

Backstage — open-source платформа для service catalog от Spotify. По моим наблюдениям, канонический выбор для тех, кто перерос markdown, особенно если поверх каталога хочется сделать портал для разработчиков.
Markdown в репозитории команды — самый простой формат на старте: один сервис — одна запись (services/<slug>.md) с фронт-маттером owner / on-call / SLO / dependencies. Ревью через pull request, история git как журнал аудита.
CODEOWNERS (GitHub) — частичная проекция ownership на уровень кода. Не заменяет catalog, но синхронизировать с ним обязательно.

Best practices

Короткие правила:

Service owner — конкретный человек или команда, никогда «общая инфра». Запись «Owner: SRE team» без имени команды или лида через год превращается в загадку: в инциденте никто не помнит, кто принимает решения, обновления откладываются, sunset невозможен.
Sunset — явный статус с дедлайном. «Сервис вроде не используется» — это будущий зомби с уязвимостями и счётом от облака. Sunset = запись в catalog со статусом, ответственным и датой выключения.

Catalog работает, только когда он единственный источник истины, а не один из. Метаданные расползаются охотно: часть в wiki, часть в Confluence, часть в чьей-то личной таблице, часть в устной договорённости с человеком, который уже уволился, и никто не помнит, какая из четырёх версий записывалась последней. Через полгода спор «где правда» решается голосованием. Лечение одно. Остальные места ссылаются на catalog, а не копируют из него.

Подробнее:

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

Регулярная ревизия и чистка. Запись попадает в каталог один раз и живёт там вечно. Через два года половина каталога описывает то, что давно выключено, а реальный прод живёт где-то рядом и мимо. Помогает скучная дисциплина: цикл пересмотра раз в квартал или полгода и живой человек, который проходит по записям, спрашивает владельцев «это ещё работает?» и проставляет sunset тем, кто не ответил. Иначе каталог превращается в археологию.

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

Связанные листья

SLO / Budget Review — owner — это тот, кто принимает решения о бюджете; без чёткого ownership ревью не имеет адресата.
Runbooks — owner отвечает за актуальность runbook своего сервиса; catalog связывает service ↔ runbook URL.
Dev Team Partnership — контракт взаимодействия предполагает явного владельца; без него партнёрство сползает в «SRE решает всё».
Incident Response — incident commander смотрит в catalog, чтобы узнать owner и эскалационный путь.
Backup & Restore — каталог содержит метаданные о бэкапах сервиса; без catalog на момент disaster инженеры ищут backup вслепую.
Cloud Cost Control — каталог хранит и деньги: текущие затраты, бюджет, динамику. За расходы отвечает тот же, кто владеет сервисом.
Vendor Reliability — каталог хранит зависимости сервиса от внешних поставщиков; playbook на аварию у поставщика привязан к владельцу.
Change Governance — каталог хранит состояние PRR: пройден, не пройден, в работе. Это и есть ответ на вопрос «есть ли владелец и готов ли сервис к проду».
Team Topologies — владение — прямое следствие топологии: stream-aligned team владеет сервисом целиком, платформенная — инфраструктурой. Без явной топологии каталог получается дырявым.
DR Policy & Stakeholders — каталог хранит класс каждого сервиса (1/2/3) с целевыми RTO/RPO и выбранной стратегией. Политика задаёт рамку классификации, каталог показывает, как она разложена по сервисам.

Открытые вопросы

Под L1 IT Management остаются нераскрытые темы. Самая заметная — Production Access Audit: у кого есть доступ к боевым машинам и как это выглядит с точки зрения compliance. Cost, Vendor и Change Governance уже выделены в отдельные листья, а этот кусок пока висит.

Отдельно меня смущает граница со Methods & Tools. Catalog как инструмент частично живёт и там, и тут. Договорённость сейчас такая: здесь владение как практика, там выбор инструментов. Насколько эта граница выдержит рост обоих листьев, я не знаю.