Toil Reduction

Что такое toil

У Google SRE определение точное: toil — работа по обслуживанию production-сервиса, которая ручная, повторяющаяся, автоматизируемая, реактивная, лишённая долгосрочной ценности и растущая линейно с ростом сервиса. Любая рутинная задача в эту категорию не попадает. Написание постмортема тоже рутина, но у него есть долгосрочная ценность. А вот ручной рестарт сервиса каждый вторник утром, потому что он течёт по памяти, — toil в чистом виде.

Простой тест отличает toil от полезной операционной работы: если через год задача выглядит так же и требует столько же времени, это toil. Если задача исчезает после вложений в автоматизацию или починки корневой причины, это был инженерный проект, замаскированный под рутину.

Правило 50%

У Google для SRE-команд явный бюджет: не больше 50% рабочего времени инженера на операционную работу вместе с toil. Оставшиеся 50% — инженерные проекты: автоматизация, улучшение инфраструктуры, инструменты, которые снизят toil завтра. Если toil зашкаливает за половину, команда обязана эскалировать это как проблему и получить время на инженерные проекты.

Правило звучит жёстко, и на практике соблюдается с трудом. Toil разрастается незаметно. В январе на ручные операции уходит 20% времени. В феврале добавляется новый сервис с ручным деплоем. В марте ещё один. К лету выясняется, что 70% времени уходит на работу, которая систему лучше не делает. Поэтому измерение — критический шаг.

Как измерять toil

Google советует раз в месяц или раз в квартал оценивать, сколько времени команда тратит на разные категории работы. Способы:

Дневник времени. Каждый инженер две недели записывает, на что уходит время, с разбивкой по категориям: toil, инженерные проекты, код-ревью, встречи, обучение. Метод грубый, но даёт первую картину. Часто инженеры удивляются — субъективное «я весь день занимался ерундой» превращается в конкретные двенадцать часов в неделю на ручное обновление конфигов.

Тикеты. Если операционная работа трекается в Jira или аналоге, можно посчитать время на тикеты определённых типов. Минус — не вся toil попадает в трекер. Быстрый ssh, ручной рестарт, ответ в чате на типовой вопрос — всё это происходит между делом.

On-call данные. Инциденты, обработанные дежурным, и время на их устранение — прямой показатель реактивной операционной работы. PagerDuty и аналоги дают эту статистику из коробки. Качественная observability помогает отличить реальные инциденты от шума и точнее оценить объём toil.

Точность измерения тут вторична. Важен сам факт измерения. Даже приблизительная оценка «40% времени — toil» даёт основание для разговора с менеджментом о выделении времени на автоматизацию.

Автоматизация: когда и что

Автоматизировать всё подряд — плохая стратегия. ROI зависит от частоты задачи, времени на ручное выполнение и стоимости самой автоматизации. Задача на пять минут раз в квартал — три дня скрипта на неё не окупятся никогда. Задача на тридцать минут каждый день — три дня окупятся за неделю.

Порядок приоритизации такой.

Частые задачи с высоким временем выполнения. Ежедневный ручной деплой, который занимает час? Сначала. Окупаемость — дни.

Редкие задачи с высоким риском ошибки. Ежемесячная ротация секретов руками — двадцать минут, но цена ошибки — аутейдж. Автоматизация снижает и toil, и риск.

Задачи, которые прерывают работу. Даже двухминутная задача, которая прилетает в чат три раза в день, выдёргивает инженера из контекста — и в сумме это час потерянной продуктивности на одних только переключениях.

Практические техники

Self-service вместо тикетов. Разработчик пишет тикет «дайте доступ к staging-базе», ops-инженер руками выполняет пять команд. Альтернатива — self-service: кнопка в Backstage или CLI-команда, которая проверяет права и выдаёт доступ автоматически. Каждое такое self-service-окно убирает toil с обеих сторон: разработчик не ждёт, ops-инженер не отвлекается.

Runbooks превращаются в скрипты. Если есть runbook с пошаговой инструкцией «зайди на сервер, выполни команду A, проверь результат, выполни команду B» — это готовая спецификация для скрипта. Первый шаг: обернуть последовательность команд в bash-скрипт. Второй: добавить проверки и обработку ошибок. Третий: интегрировать в систему реагирования на инциденты.

Elimination вместо автоматизации. Иногда лучший способ убрать toil — устранить корневую причину. Каждую неделю рестарт сервиса из-за memory leak? Автоматический рестарт по расписанию — это автоматизация toil. Починка memory leak — elimination. Elimination предпочтительнее.

Toil и DX

Toil влияет на Developer Experience прямо. Инженер, который 60% времени тратит на ручную операционную работу, не пишет код, не проектирует системы, не растёт профессионально. Через полгода такой работы он либо выгорает, либо уходит в компанию, где инженеры занимаются инженерной работой.

Google Cloud Blog в статье о трекинге toil предлагает простую рекомендацию: визуализировать toil-бюджет команды. Показать, сколько процентов времени уходит на операционную работу, и сделать снижение этого процента явным OKR. Когда toil reduction становится измеримой целью, а не абстрактным пожеланием, команды находят время на автоматизацию.

Признак здоровой организации — когда инженеры сами предлагают автоматизировать toil, потому что видят, что менеджмент поддерживает такие инициативы и выделяет на них время. Признак больной — когда инженеры молча тратят 80% времени на ручную работу, потому что «нет времени автоматизировать» и «менеджмент не считает это приоритетом».