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