Toil в работе SRE. Измерять, или "мы и так знаем что работы дофига“?

Привет, киты 🐳. Поразмышляем.

Коротко про базу, чтобы синхронизировать понятия.

Что такое Toil?
По определению Google SRE, toil - это операционная работа, которая:
- ручная и повторяющаяся
- автоматизируемая
- реактивная, а не стратегическая
- не создает долгосрочной ценности
- масштабируется линейно с ростом сервиса

Toil и технический долг - одно и то же? Нет. Технический долг - это компромиссы в архитектуре/коде, которые усложняют будущие изменения. Toil - это операционные затраты на поддержку системы. Часто техдолг генерирует toil, но это разные категории. Погашение долга - engineering work, ручное обслуживание последствий - toil.

Плановые задачи vs задачи дежурства. Что из этого toil?
Не инструмент и не источник задачи определяют суть, а её характер:
- "Раз в неделю вручную чистить логи на 50 нодах" из беклога - toil.
- "Написать оператор для авто-очистки" - engineering.
- "Дайте доступ", "Почему не деплоится", "Перезапустите под" из дежурства - классический toil, особенно если повторяется.

Как понять, что пора автоматизировать?
1. Замерить. Без цифр всё субъективно.
2. Оценить ROI: время на разработку автоматизации vs время, которое она сэкономит.
3. Начать с простого: структурированный запрос -> бот -> подсказка или маршрутизация.
Именно так мы сейчас делаем: бот отвечает на частые вопросы разработчиков и зовет нужного специалиста (DevOps/SRE/DBA) в зависимости от контекста. Это классический первый шаг который предлагает Google.

Целевой toil ratio для SRE-команды по гайдлайнам Google - не более 50%. Остальное инженерная работа - проекты, которые уменьшают будущую рутину и повышают надежность.

🥸 Измеряете toil ratio у себя? Если нет - что мешает начать: отсутствие метрик, времени или просто неочевидна ценность?

#SRE #Toil #Автоматизация #ИнцидентМенеджмент #ЛетитКит #SLO