Правило звучит просто: SRE тратит на toil меньше половины времени, остальное — на инженерную работу. Дальше в той же главе есть цифра, которую цитируют редко. Квартальные опросы внутри Google показывали средний toil около 33% — организация живёт заметно ниже собственного лимита. 50% там не бюджет, который надо освоить, а граница, за которой начинают разбираться, что сломалось.
И есть третья цифра, самая неудобная.
У потолка есть пол
Дежурство даёт toil, который нельзя автоматизировать, потому что он состоит из присутствия. В книге это посчитано прямо: при ротации из шести человек каждый берёт две недели из шести — primary и secondary, — и нижняя граница toil получается 2/6, около 33%. При восьми — 2/8, 25%.
Из той же формулы следует то, чего в книге нет. Четыре дежурных с тем же устройством смен — 2/4, ровно 50%. Команда стоит на потолке, ещё не открыв тикет-очередь. Три дежурных — 67%, и это уже не проблема автоматизации.
Оговорка существенная: арифметика считает primary плюс secondary. Если вторая линия не выделена и дежурит один человек, граница вдвое ниже — 1/N. Но и 25% при четверых означают, что половина разрешённого бюджета израсходована расписанием.
Вывод для небольшой платформенной команды неприятный: «у нас слишком много рутины» часто описывает размер ротации, а не качество инструментов. Ни один агент не меняет 2/4.
Что агент снимает по-настоящему
Тот же текст ранжирует источники toil. На первом месте — не инциденты, а прерывания: несрочные обращения по сервису, письма и сообщения. Дальше идут срочные ответы по дежурству, и только потом релизы и выкаты.
Первое место — ровно то, что закрывается расследованием без изменений. «Эта версия доехала до прода?», «почему под перезапускается», «что менялось за последний час», «остался ли drift на этом кластере». Ответ существует в кластере, метриках и истории выкатов; человек тратит на него минуты и переключение контекста, а система после этого остаётся в том же состоянии — определение toil выполняется целиком.
Read-only агент здесь уместен: он отвечает, ничего не меняя, и решение остаётся за человеком. Механика такого доступа — отдельный разговор; интересна не она, а бухгалтерия.
Ловушка: «здесь нужно суждение»
Стандартный способ вывести работу из toil-бюджета — сказать, что она требует человеческого суждения. Книга закрывает эту лазейку отдельной сноской: проверять надо, суждение требуется по природе задачи — или потому, что систему плохо спроектировали. Сервис, который несколько раз в день зовёт дежурного на сложный разбор, описан там как плохо спроектированный, а сам разбор остаётся toil, пока редизайн не выкачен.
Отсюда риск, который лучше оценить до внедрения, а не после. Агент, ежедневно выполняющий этот разбор вместо человека, делает плохо спроектированную систему удобной. Toil, посчитанный в человеко-минутах, падает. Причина, из-за которой он возник, остаётся на месте, и давление на редизайн уходит вместе с болью.
Практическое следствие — в том, что считать. Минуты покажут улучшение, потому что минуты и есть то, что забрал агент. Считайте количество расследований: сколько раз за неделю кому-то — человеку или агенту — понадобилось выяснять, почему система в таком состоянии. Эта цифра не двигается от установки агента, зато двигается от исправления причины. Как метрика превращается в цель и перестаёт работать — разбирал отдельно.
Read-only — не синоним безопасного
Одна деталь, на которой ломаются самодельные роли. Встроенный в Kubernetes ClusterRole view намеренно не даёт читать Secrets: доступ к содержимому секрета открывает учётные данные ServiceAccount и возможность обращаться к API от их имени. Документация относит это к эскалации привилегий, а не к чтению.
Роль, собранная вручную как «get, list, watch на всё», секреты включает. Формально она read-only, фактически даёт агенту материал для действий от чужого имени. Прочитанное при этом целиком попадает в контекст модели — логи, переменные окружения, конфиги, — поэтому шумные срабатывания стоит починить до подключения агента, а не после (про режимы срабатывания).
Что с этим делать
Посчитайте свой пол: размер ротации, наличие secondary. Если он близок к 50%, разговор про агентов преждевременный — сначала ростер. Если запас есть, отдайте агенту прерывания: это самый большой источник toil и единственный, где чтение решает задачу целиком. И держите отдельный счётчик расследований, чтобы отличать исправленную причину от красиво спрятанной.