Есть простой вопрос, который стоит задать на любом разборе аварии: чей это сервис. Если в ответ звучит «ну, вообще-то общий» или пауза с переглядыванием — вы уже нашли главную причину, независимо от технической.
Владение — это не про собственность и не про «только он имеет право трогать». Это про то, у кого болит, когда система работает плохо.
Почему «отвечают все» не работает
Общая ответственность выглядит справедливо и звучит зрело. На практике она даёт предсказуемый набор симптомов:
- ошибки в журналах никто не смотрит — все считают, что смотрит кто-то другой;
- обновление зависимостей откладывается годами: это ничья работа;
- при аварии первые двадцать минут уходят на выяснение, кто вообще в контексте;
- решения об этой системе не принимаются, а дрейфуют.
Причина не в лени. Когда ответственность размазана, никакое конкретное действие не является ничьей обязанностью — и не выполняется никем. Это верно про любую команду и не лечится призывами.
Что значит «владеть системой»
Полезно договориться о содержании явно, иначе владение вырождается в строчку в таблице.
Владелец сервиса:
- знает, зачем сервис нужен бизнесу и что ломается, когда он лежит;
- отвечает за его здоровье: алерты приходят ему, ошибки в журналах разбирает он;
- принимает технические решения внутри сервиса и записывает существенные в ADR;
- платит по его счетам: зависимости, технический долг, наблюдаемость;
- представляет сервис снаружи: к нему приходят соседние команды с вопросами и запросами на изменение контракта.
Чего владение не означает: монополии на правки. Другие меняют код спокойно — через обычное ревью, где владелец один из ревьюеров. Владелец, который блокирует чужие изменения по вкусу, превращает владение в узкое место; тут работают обычные нормы ревью.
Второй важный момент: у каждой системы владелец один. Не два, не «команда», а конкретный человек — с явно названным дублёром на время отпуска. Двое владельцев — это ноль владельцев с дополнительным шагом согласования.
Как раздать владение
Практика, которая занимает один вечер и меняет много.
Шаг 1. Выписать всё, что у команды есть. Сервисы, задачи по расписанию, потребители очередей, панели мониторинга, конвейеры сборки. Список почти всегда длиннее, чем помнят — и половина пунктов оказывается сюрпризом.
Шаг 2. Напротив каждого — имя. Не «команда», а человек. Пустые строки — самые ценные: это ничейные системы, которые до этого дня жили без присмотра.
Шаг 3. Разобраться с ничейными. Варианта три: назначить владельца, честно признать систему замороженной (никто не трогает, чиним только аварии) или выключить. Худший вариант — оставить как есть и считать, что она чья-то.
Шаг 4. Проверить перекос. Если у одного человека семь систем, а у трёх других по одной — это не структура, а будущая точка отказа. Перекос обычно исторический: человек всё это писал. Разгружать его придётся постепенно, через передачу с сопровождением.
Шаг 5. Повесить список на видное место и пересматривать раз в квартал. Владение устаревает: люди уходят, системы появляются.
Как резать команды: по продукту, а не по слою
Когда команда вырастает и её делят, соблазн — резать по технологиям: команда бэкенда, команда фронтенда, команда базы. Это кажется логичным: одинаковые люди, одинаковые инструменты, легко нанимать.
Проблема в том, что работа приходит поперёк такого деления. Любая пользовательская задача трогает все три слоя, а значит требует согласования трёх команд, трёх приоритетов и трёх очередей. Время задачи определяется не сложностью, а числом стыков.
Деление по продукту — команда вокруг части продукта, со всеми нужными компетенциями внутри — даёт обратное: большинство задач делается внутри одной команды, без внешних согласований. Это и есть главный критерий при выборе структуры: какая доля задач требует выхода за границу команды. Если больше половины — граница проведена неправильно.
Тот же вопрос решается и при нарезке системы на сервисы: границы сервисов и границы команд лучше держать согласованными, иначе один сервис меняют три команды и никто не отвечает за его целостность.
Размер и связность
Два наблюдения, которые стоит держать в голове.
Размер команды. Примерно до восьми человек лид успевает знать контекст каждого и держать поток задач. Дальше растут накладные расходы: встреч больше, контекста меньше, а лид превращается в диспетчера. Команда из пятнадцати обычно уже неявно распалась на две — и лучше признать это явно, чем делать вид, что она одна.
Число связей. Каждая пара людей — это канал связи, и их число растёт быстрее, чем число людей: пять человек — десять пар, десять человек — сорок пять. Отсюда практический вывод, который часто удивляет: добавление людей в отстающую команду сначала замедляет её, потому что новичков нужно вводить в контекст те же люди, что делают работу.
Из этого же следует, почему структура важнее героизма: сильный инженер, который держит в голове всю систему, — это временное решение, работающее до его выгорания или ухода. Владение, записанное и распределённое, переживает и то и другое.
Коротко
- «Отвечают все» на практике означает «не отвечает никто»: ошибки не смотрят, зависимости не обновляют, аварию начинают с поиска ответственного.
- Владелец знает, зачем система бизнесу, отвечает за её здоровье, принимает решения, платит по счетам и представляет её снаружи. Монополии на правки владение не даёт.
- У системы один владелец и явный дублёр; двое владельцев — это ноль.
- Раздача владения: выписать всё, поставить имена, разобраться с ничейными (назначить, заморозить или выключить), убрать перекос, пересматривать раз в квартал.
- Команды режут по продукту, а не по слою; критерий проверки — доля задач, требующих выхода за границу команды.
- До восьми человек лид держит контекст; связей между людьми растёт быстрее, чем людей, поэтому новые люди сначала замедляют команду.
Что почитать дальше
- Как разбить систему на сервисы: карта маркетплейса — границы сервисов, которые полезно согласовать с границами команд.
- Делегирование, встречи один на один и рост инженеров — как передавать зоны ответственности вместе с правом решать.
- Постмортем и дежурства — что происходит, когда у системы нет владельца.