У сервиса подготовки договоров в каталоге указана команда-владелец. Но настройку выпуска знает сотрудник, который уже перешёл в другое подразделение, доступ к базе остался у подрядчика, а ночные ошибки приходят в общий канал. Формально бесхозных систем нет. Практически любое изменение начинается с поиска нужных людей.
Service Ownership — договорённость о том, кто способен и обязан поддерживать конкретную возможность продукта. Её нельзя завершить назначением названия команды. Вместе с ответственностью нужны полномочия, знания, время и понятные отношения с теми, кто зависит от сервиса.
Сначала определить, что именно находится у владельца
Название репозитория не описывает весь объём работы. Для договоров важны шаблоны, правила формирования, хранилище результатов, очередь и способ передать готовый документ пользователю. Часть инфраструктуры может обслуживать платформа, но клиенту нужен результат всей операции.
Владелец сервиса должен знать границу своего обязательства: что считается успешной подготовкой, какие зависимости необходимы, какие данные сохраняются и какие ограничения оговорены. Ответ «наш HTTP-запрос прошёл» бесполезен, если документ потерялся на следующем шаге и никто не продолжает разбор.
В модели каталога Backstage владелец — ответственная сторона, обычно команда, с возможностью развивать и поддерживать компонент. При этом поле владельца предназначено для описания ответственности, а не автоматической выдачи рабочих прав. Заполненный каталог и доступ к эксплуатации надо проверять отдельно.
Одной команде может принадлежать несколько сервисов. Число компонентов само по себе не определяет посильную нагрузку: важны сложность изменений, срочность сбоев и объём обслуживания. Назначать отдельную команду каждому небольшому сервису необязательно, но скрывать перегрузку за общей строкой владельца тоже нельзя.
За обещанием должны стоять решения и ресурсы
Команде нужно понимать, какие изменения она принимает самостоятельно, кто согласует изменение бизнес-правил и где получить решение о дополнительных расходах. Если исправить известный риск можно только после неопределённого общего согласования, ответственность за этот риск распределена шире, чем строка владельца.
Не каждый сервис требует круглосуточного дежурства. Режим зависит от обязательств продукта: подготовка договора для завтрашней встречи и остановка круглосуточной продажи имеют разную срочность. Но обещанный режим должен обеспечиваться людьми, доступами и порядком замещения, а не постоянной доступностью одного автора.
Время на сопровождение нельзя одновременно считать полностью свободным для новых функций. Дежурства, обновления, разбор повторяющихся сбоев и восстановление данных конкурируют за ту же командную мощность. Google SRE разбирает устойчивость дежурной нагрузки; копировать численные нормативы другой компании необязательно, а учитывать саму нагрузку необходимо.
Полезно отдельно договориться о риске, который команда пока не может устранить. Кто принимает временное ограничение, как оно влияет на потребителей и когда вернутся к решению? Назначение владельца не превращает хронический недостаток ресурсов в личную недоработку инженеров.
Во время аварии нужны несколько ролей
Пусть формирование договоров остановилось из-за общей очереди. Платформенная команда восстанавливает транспорт, команда договоров выясняет судьбу принятых заданий, поддержка сообщает пользователям, какие документы задержаны. Ответственность за компонент не должна становиться причиной передавать обращение по кругу.
Для серьёзного инцидента полезно отделять координацию от технического исправления и общения с потребителями. Такой подход описан в руководстве Google SRE по реагированию. Руководитель инцидента не обязан быть постоянным владельцем каждого затронутого сервиса.
Завершение аварии тоже стоит определить заранее. Запущенная очередь ещё не означает, что все договоры сформированы. Нужно найти зависшие задания, безопасно продолжить работу и проверить результат. После этого остаются причины повторения и конкретные действия по их устранению, а не только закрытое уведомление.
Другим командам нужен путь изменения, а не монополия
Владелец отвечает за совместимость интерфейса и последствия выпуска, но не обязан лично писать каждую строку. Соседняя команда может предложить изменение по понятным правилам: проверки, ревью, поддерживаемые версии и согласование новых обязательств.
Если сервис общий, потребителям требуется механизм приоритизации. Команда договоров не может бесконечно выбирать между срочными просьбами продаж и юридического подразделения без права решить конфликт. Нужен бизнес-владелец приоритетов или заранее согласованный порядок, а не скрытое соревнование за внимание разработчиков.
При изменении контракта стоит проверить, кто действительно им пользуется. Документация и уведомление полезны, но они не доказывают, что потребители успели перейти. Дату завершения старого режима связывают с наблюдаемым использованием и отдельной договорённостью о рисках оставшихся интеграций.
Передача сервиса должна закончиться проверкой
После реорганизации новая команда получает не только репозиторий. Ей нужны доступы, порядок выпуска, диагностика, известные ограничения, потребители, расходы и задачи сопровождения. Должен быть момент, когда она явно принимает этот объём, а прежняя сторона знает срок своей помощи.
В описании передачи сервиса Google SRE подготовка включает обучение, практические упражнения и постепенную передачу обязанностей. Для небольшой компании форма может быть проще. Смысл сохраняется: читать инструкцию и уметь выполнить восстановление — разные состояния.
Попросите принимающую команду самостоятельно выпустить безопасное изменение и разобрать контролируемый сбой. Если для каждого шага нужно звонить прежнему автору, передача не закончена. Обновите контакты, маршруты оповещений и права; старая запись в каталоге не должна пережить реальную смену ответственности.
Владение продолжается до выключения
Редко используемый сервис тоже требует решения. Перед остановкой найдите потребителей, периодические задания и данные, которые ещё нужны компании. Тишина в обычную неделю не исключает квартальный расчёт или ручное восстановление. После перехода следует убрать ненужные доступы, ресурсы и оповещения, сохранив необходимую историю.
Для договоров результат выглядит конкретно: известно, кто отвечает за готовый документ, кого вызвать при задержке, кто может изменить правила и как передать эту работу другой команде. Небольшому продукту для этого может хватить короткой страницы. Сложный каталог полезен только тогда, когда содержащиеся в нём договорённости действительно выполняются.