Каталог сервисов (или каталог услуг, Service Catalog) — это структурированный перечень всех IT- или бизнес-услуг, которые организация предоставляет своим сотрудникам, клиентам или внутренним подразделениям.
Это:
• Единый справочник: собирает все доступные услуги в одном месте, чтобы пользователи знали, что именно можно запросить. • Портал самообслуживания: позволяет клиентам или сотрудникам самостоятельно выбирать и заказывать нужные продукты или поддержку через удобный интерфейс. • Систематизация: упрощает работу Service Desk, так как каждый запрос привязан к конкретной услуге. • Прозрачность: показывает, кто отвечает за сервис, какие у него параметры и т.п.
Если вы когда-нибудь несли дежурство (on-call), вы наверняка задавали каждый из перечисленных ниже вопросов — и, как правило, в самый неподходящий момент:
- Кому принадлежит этот сервис?
- Кому принадлежит этот репозиторий?
- От чего он зависит и что зависит от него?
- Кто является экспертами по предметной области (SME — subject-matter experts)?
- Кто сейчас дежурный по этому сервису?
Ни один из этих вопросов не является по-настоящему сложным и кто-то всегда знает ответ. Проблема заключается в том, что этот «кто-то» обычно спит, находится в отпуске, в другом часовом поясе или уволился из компании восемь месяцев назад.
Большинство из нас переживали ту или иную версию следующего сценария:
Срабатывает алерт по сервису. Дашборды показывают, что частота ошибок растёт, но сам сервис выглядит здоровым — следовательно, проблема, вероятно, кроется в его зависимостях. Вы открываете репозиторий, чтобы выяснить, что это за зависимость. README последний раз обновлялся два года назад и описывает архитектуру, которой больше не существует. В конфигурации по именам хостов упоминаются три других сервиса. Один из них звучит знакомо.
Идете в корпоративную Confluence, но там статья про этот сервис написана пару лет назад.
Тогда вы идёте в ваш рабочий мессенджер. Вы ищете название сервиса и находите тред с прошлой весны, где кто-то назвал команду, которая с тех пор была реорганизована в две другие команды. Вы пинаете дежурного, который, по вашему мнению, является тем, кто нужен. Вам вежливо отвечают, что это не их зона ответственности, но, кажется, Такойто раньше работал над этим. На Такойто сейчас в отпуске и не отвечает.
Спустя двадцать минут вы ещё не начали ничего диагностировать. Вы занимались археологией.
Кому принадлежит этот сервис?
Владение сервисом дрейфует. Команды реорганизуются, сервисы передаются, а человек, который их создал, уходит. Если владение вообще фиксируется, то обычно за конкретным человеком, как раз это единственное, что гарантированно устаревает. Владение должно указывать на команду, и на команду, которая всё ещё существует.
Кому принадлежит этот репозиторий?
Это отдельный вопрос, и ответ часто отличается. Один репозиторий может порождать несколько развёртываемых сервисов, а один сервис может собираться из нескольких репозиториев. Файл CODEOWNERS говорит вам, кто ревьюит изменения; он не говорит вам, кого нужно будить ночью.
От чего он зависит и что зависит от него?
Это вопрос радиуса поражения (blast radius), и отверт нужен вам как во время инцидента («проблема здесь или выше?»), так и перед изменением («если я обновлю эту базу данных или выведу из эксплуатации этот пул нод, что сломается?»). Большинство организаций могут ответить на первую половину, прочитав код. Почти никто не может ответить на вторую половину — кто сломается, если сломается это? — не опрашивая окружающих.
Кто такие SME?
В каждой системе есть один-два человека, которые действительно её понимают. Это те, кого втягивают в каждый инцидент, каждое ревью дизайна, каждый «быстрый вопрос». Это единая точка отказа, только состоящая из людей, а не из железа. Знать, кто они, — первый шаг; распространить их знания — второй.
Кто сейчас дежурный по сервису?
Сопоставление сервиса с его сопровождением обычно не хранится нигде — или только в голове некоторых людей.
Где обычно живут ответы
Поспрашивайте, и вы обнаружите, что ответы разбросаны по:
- племенным знаниям (tribal knowledge), которые уходят вместе с людьми;
- страницам вики, которые были актуальны в день их написания;
- таблице, которую кто-то начал вести в Excel во время последней реорганизации;
- поиску в мессенджере, который находит какой-то чатик, но не дает нужной инфы;
- CODEOWNERS и git blame, которые говорят вам, кто писал код, а не кто его эксплуатирует.
Ни один из этих источников не является местом, которому можно доверять в 2 часа ночи, и ни один из них не обновляется сам, когда что-то меняется.
И это проблема не только инцидентов. Новые инженеры выстраивают одну и ту же ментальную карту, задавая одни и те же вопросы одним и тем же занятым людям. Сиротские сервисы (orphaned services) продолжают работать и продолжать стоить денег, потому что никто не уверен, что их можно безопасно отключить.
Что меняет каталог
Каталог сервисов помещает ответы в одно место, с несколькими свойствами, которых никогда не было у вики и таблиц:
Он живёт вместе с кодом. Каждый сервис описывает себя в небольшом файле в своём собственном репозитории. Изменения проходят то же ревью, что и любое другое изменение, людьми, которые им владеют.
Владение указывает на команду, а не на человека. На странице команды есть состав, канал в мессенджере и ссылки на график дежурств.
Зависимости объявлены, поэтому их можно понять. Каждый сервис перечисляет, от чего он зависит и что зависит от него.
Живой статус на той же странице. Ссылки на здоровье подов, статус деплоя, историю пайплайна, текущего дежурного, ссылку на дашборд. Вы перестаёте переключаться между пятью вкладками браузера, чтобы ответить на один вопрос.
Подвох
Каталог хорош настолько, насколько хороши его данные.
SRE — это те, кто хочет этого больше всего. Мы те, кто занимается археологией в 2 часа ночи. Но мы не те, кто может поддерживать точность и актуальность этого каталога, это могут и должны делать команды — владельцы сервиса. Каталог, который никто не поддерживает — это просто более новая и украшенная LLM-скиллом страница вики, и она такая же неактуальная.
У каждого из перечисленных выше вопросов есть ответ. Стоимость заключается в его поиске, и эта стоимость всегда приходится на худшее время — в середине инцидента или прямо перед изменением, которое вы не можете легко откатить.
Каталог сервисов не делает ни один из этих ответов умнее. Он делает их находимыми — любым человеком или любым ИИ-агентом, помогающим диагностировать инцидент, — за секунды, не будя единственного человека, который знает.
