Toil Tracking

«Мы все ужасно заняты дежурством» — эту фразу я слышу регулярно. Без данных она не значит ничего. Пока toil не посчитан, его нельзя ни ограничить (toil budget), ни автоматизировать прицельно — руки тянутся не к тому, что съедает время, а к тому, что интереснее написать, — ни превратить в аргумент для найма. Toil — техническая категория с конкретным определением из SRE Book: ручная, повторяющаяся, автоматизируемая, тактическая работа без долговременной ценности, объём которой растёт линейно с сервисом. Это не «всё, что бесит». Этот лист — про измерение такой работы. Соседние практики под тем же L1: Toil Automation — про как устранять, Personal SRE Toolkit — уровень одного инженера, ChatOps — командная автоматизация через чат.

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

Главный навык на уровне L5 — держать toil budget команды в реальности, а не на бумаге. Договорённость из SRE Book — не больше половины времени инженера. На практике в командах, которые я наблюдаю, это либо игнорируется, и норма уезжает к четырём пятым, либо превращается в показатель без обратной связи. Бюджет работает только тогда, когда выход за него автоматически поднимает автоматизацию выше новых фич в приоритетах. Иначе это просто число в вики.

Понимает каноническое определение toil (шесть признаков: ручная, повторяющаяся, автоматизируемая, тактическая, не создающая долговременной ценности работа, объём которой растёт линейно с сервисом); отличает toil от проектной работы и не сваливает в него всё нелюбимое.
Фиксирует свой toil еженедельно (что / сколько времени / категория); делает это в момент работы, не «вспомню в пятницу».

Проводит инвентаризацию: список повторяющихся операционных задач, кто их делает, как часто, сколько занимает в среднем. Это и есть точка отсчёта.
Раскладывает toil по каноническим категориям: реакция на алерты, операции выкатки, нехватка ресурсов, заведение доступов, шум вокруг сборок и релизов, вынужденные переключения на тушение пожара.

Превращает учёт в командный ритуал: понятный ритм, простой инструмент (таблица, форма, бот в Slack), сведение в дашборд; точка отсчёта — минимум за квартал.
Использует эти данные для приоритетов автоматизации: что чаще, что дольше и что сильнее выматывает — то и устраняется первым.
Устанавливает бюджет команды: договорённость о предельной доле времени на toil у одного инженера (в SRE Book — не больше половины); вышли за бюджет — автоматизация идёт вперёд фич.

L6+

Заводит общие дашборды: сводные метрики по сервисам и командам, чтобы видеть закономерности на уровне организации.
Связывает toil с планированием мощностей и наймом: высокий и растущий объём означает либо автоматизировать, либо нанимать. Toil — это скрытый потолок пропускной способности команды.

Материалы

Книги

Vivek Rau (ред. Beyer) — Site Reliability Engineering (O’Reilly, 2016), глава 5 «Eliminating Toil». Каноническое определение через шесть признаков, правило «не больше половины времени» и тезис о том, что toil растёт линейно с сервисом, а инженерная работа — медленнее.
David Challoner et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 6 «Eliminating Toil». Таксономия источников, стратегии управления и два подробных разбора из практики Google.

Статьи и фреймворки

Twelve-Factor App косвенно связан: соблюдение его принципов — одноразовые процессы, одинаковые окружения — снижает целый класс рутины вокруг выкаток и эксплуатации.

Инструменты

Таблица, форма или база в Notion — базовый формат: колонки дата / инженер / категория / минуты / заметка. Стоит копейки на старте и закрывает потребность команды из пяти-десяти человек.
Метка в трекере задач — Jira, Linear или GitHub Issues с тегом toil: каждая операционная задача заводится как issue с меткой, а сводки строятся штатными дашбордами трекера. По моим наблюдениям, это работает лучше отдельной книги учёта: рутина видна в общей очереди задач.
Короткий еженедельный опрос на полминуты: сколько часов ушло на рутину, какая категория главная, что раздражало больше всего. Поверх таблицы это даёт качественный сигнал, которого в цифрах нет.
Ретро как место разбора — последний пункт повестки: какая рутина доминировала и что автоматизируем в следующем спринте. Не отдельная встреча, а часть существующей.

Best practices

Первое правило простое: считай, а не предполагай. Без данных приоритеты автоматизации спорят на эмоциях, бюджет ставится по ощущениям, а запрос на найм отбивается фразой «у вас же всё работает». Минимальный учёт лучше отсутствующего. Неделя честно заполненной таблицы даёт больше, чем месяц разговоров «мы и так знаем, где рутина».

Второе — держаться определения, а не ощущения «меня это бесит». Сложное ревью кода — не toil, оно требует суждения, которое ничем не заменишь. А копирование конфигов руками между окружениями — toil по всем признакам: повторяется, автоматизируется, растёт линейно с числом сервисов. Стоит отпустить границу, и учёт превращается в книгу жалоб, из которой не выводится ни одного решения.

Не больше половины времени инженера — договорённость из SRE Book. Когда рутина занимает четыре пятых, инженер не делает проектную работу, не учится и не автоматизирует, а значит, ничего не меняет в системе, которая этот toil производит, — и она спокойно самоподдерживается в том же режиме год за годом. Круг замыкается. Если половина недостижима, это тоже решение, только принимать его надо явно: нанимать или резать объём работ.

Автоматизируй самое дорогое (частота × длительность), а не самое интересное. Отдача считается по этим двум числам, и они обычно указывают на скучную ежедневную мелочь. Я регулярно вижу обратное: команда берёт редкий хитрый случай, потому что его приятнее писать. Учёт тут работает как холодный душ — он выдаёт упорядоченный список, с которым спорить трудно.

Разбор живёт внутри существующего ритуала. Учёт заводят один раз, через месяц в него никто не смотрит, ещё через квартал он превращается в кладбище данных. Лечится это дёшево: отдельный пункт в ретро или в разборе SLO, где на данные смотрят и по ним принимают решение. Сбор без разбора бессмыслен.

Сначала убрать, потом автоматизировать. Прежде чем писать скрипт, стоит задать вопрос: а можно ли убрать эту работу вообще, поменяв систему или контракт? Вместо автоматизации копирования конфигов — централизация в IaC. Вместо скрипта, который меняет боевые пароли по письму, — автоматическая ротация через Vault. Скрипт — не всегда ответ. Дешевле и живёт дольше, чем любая ловкая автоматизация, ровно потому, что убранная работа не требует ни поддержки, ни владельца, ни строчки в дашборде. По моим наблюдениям, заметную часть задач, которые команды собираются автоматизировать, можно просто убрать — но это разговор о процессе, а не про «написать скрипт».

И про границу. Учёт не работает там, где числа могут обернуться против того, кто их сдаёт: стоит руководителю один раз использовать долю рутины как оценку человека, и в таблице появятся удобные цифры вместо честных. В команде из двух-трёх человек отдельный ритуал тоже избыточен — там достаточно списка на одной странице и разговора раз в месяц. Практика начинает окупаться, когда людей больше, чем помещается в одну голову, и когда есть кому предъявить результат: приоритет автоматизации, заявку на найм, отказ от куска работы.

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

Service Ownership — каталог сервисов связывает каждый сервис с его уровнем рутины; владельцам видно, кто из них ест непропорционально много времени.
Runbooks — хороший runbook рутину сокращает, плохой — увеличивает.
Progressive Delivery — операции выкатки — крупный класс рутины; канареечная выкатка, feature flags и автоматический откат убирают ручные шаги.
Infrastructure as Code — описание инфраструктуры кодом убирает рутину вокруг конфигураций — один из самых окупаемых шагов.
Alert Fatigue Management — усталость от алертов — отдельный класс рутины; алерты от SLO с высоким отношением сигнала к шуму плюс runbook сокращают её сильнее любой другой техники.
Incident Response — переключение на тушение пожара — самый тяжёлый класс toil; уменьшается зрелым incident response.
Toil Automation — пара к этому листу: учёт даёт упорядоченный список самого дорогого, автоматизация его разбирает. Здесь про что, там про как.
Personal SRE Toolkit — самый дешёвый уровень борьбы с рутиной — алиасы, утилиты, шаблоны — для задач одного человека.
ChatOps — командная автоматизация из чата; снимает часть операционных запросов через бота.

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

Автоматизация отсюда уже выделена в отдельный лист (см. «Связанные листья»). Что осталось нерешённым у меня самого — связка рутины, мощностей команды и найма: интуитивно понятно, что растущий toil упирается в потолок, но внятной методики перевода часов в заявку на найм я не встречал. Туда же расчёт отдачи от автоматизации: сэкономленные часы, умноженные на стоимость часа, минус стоимость разработки и минус сопровождение. Формула выглядит очевидной ровно до момента, когда последнее слагаемое надо честно оценить.