Toil Reduction

Что такое toil

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

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

Правило 50%

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

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

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

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

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

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

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

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

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

Не каждую toil-задачу стоит автоматизировать. ROI автоматизации зависит от частоты задачи, времени на ручное выполнение и стоимости автоматизации. Если задача занимает 5 минут раз в квартал, писать на неё скрипт три дня — плохая инвестиция. Если задача занимает 30 минут каждый день, три дня на автоматизацию окупятся за неделю.

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

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

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

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

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

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

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

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

Toil и DX

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

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

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