Toil (ручной труд): враг номер один¶

или почему ваши лучшие инженеры хотят уволиться¶

Представьте талантливого инженера, которого вы наняли проектировать мосты. А вместо этого он каждый день, месяц за месяцем, часами стоит под недостроенным мостом и вручную, домкратом, поднимает просевшую опору и возит на тачке песок, чтобы высыпать его под эту опроу. Интеллект, креативность, опыт - всё это ржавеет в рутине. Это и есть toil.

В мире SRE toil (рутина, ручной труд) это не просто скучная работа. Это системный враг номер один, который методично уничтожает ценность команды, выжигает специалистов и блокирует развитие систем. Это злокачественная опухоль, которую нужно не просто заметить, а радикально иссечь.

Что такое Toil?¶

Toil — это ручная, операционная, тактическая работа, которая: 1. Повторяется. 2. Не приносит никакой долгосрочной ценности. 3. Масштабируется линейно с ростом системы (чем больше сервисов, тем больше toil). 4. Часто может и должна быть автоматизирована.

Toil это не работа, которую делать неприятно. Toil это работа, которую бессмысленно делать вручную. Это ключевая разница.

Примеры Toil в дикой природе:¶

Ручное развертывание (деплой): запуск 150 команд по SSH на 50 серверах в 3 часа ночи по инструкции в Confluence. Я лично своими глазами видел, как релизится продукт, который используется всеми федеральными и муниципальными органами власти одним инженером по текстовому чеклисту-инструкции на листа три А4 формата десятым кеглем (Витя, привет!! Надеюсь, у тебя сейчас все хорошо). И после этого "релиза" его последствия еще две недели устраняются, как раз до следующего релиза.
Ручное масштабирование: просмотр дашбордов и вручную увеличение количества виртуальных машин в облаке из-за роста нагрузки.
Ручная обработка алертов: реагирование на однотипные алерты "Диск заполнен на 85%" путем ручного подключения и очистки логов.
Ручное создание учетных записей/доступов для новых сотрудников. И каждый раз по 45 заявок.
Ручное переключение трафика при отказе одного датацентра по инструкции из 40 шагов.

Чем Toil НЕ является:¶

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

Toil это горящий бизнес-центр, который вы тушите ведром. Инженерная работа это проектирование и установка спринклерной системы.

Токсичное воздействие Toil: Пять стадий выгорания системы¶

1. Уничтожение инновационного потенциала. Время - самый ценный и невосполнимый ресурс команды. Каждый час, потраченный на рутину - это час, украденный у проектирования, автоматизации, улучшения платформы. Команда, погрязшая в toil, не развивает систему, а лишь поддерживает её на плаву. Как хомяк бегает в колесе весь день, вроде пробежал километр, но так и остался на месте.

2. Деградация и выгорание инженеров. Талантливые люди приходят в инженерию решать сложные задачи. Этих талантливых людей адски сложно найти. И, когда ты его все-таки нашел, заставлять его годами выполнять работу скрипта - он чувствует профессиональную деградацию. Это прямой путь к апатии, цинизму и увольнению. Самые лучшие уходят первыми.

3. Прямая угроза надёжности. Ручная работа это источник человеческих ошибок. Уставший и не спавший сутки инженер в 4 утра может пропустить строку в инструкции, сделать опечатку в команде, перепутать сервер или окружение. Toil прямо увеличивает MTTR (время восстановления) и создаёт новые инциденты. Автоматизация работает одинаково хоть в 3:00, хоть в 15:00.

4. Непредсказуемость и неспособность к масштабированию. Если для поддержки 10 сервисов нужен 1 инженер на полставки, то для 100 сервисов по этой логике нужно 5 инженеров. Это линейное масштабирование боли. Бизнес не может расти, потому что рост нагрузки на команду эксплуатации растёт ещё быстрее. Автоматизированные системы масштабируются нелинейно, почти бесплатно.

5. Блокировка бизнеса. Когда все силы команды уходят на борьбу с операционными пожарами, у неё нет ресурсов на стратегические инициативы бизнеса: запуск в новый регион, создание можели здоровья продукта, внедрение нового стека технологий. Команда становится тормозом, а не ускорителем.

Мантра SRE: "50%"¶

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

Это не пожелание, а инженерный KPI. Если процент toil превышает 50%, это признак системной болезни, и требуются срочные меры: 1. Наём дополнительных людей (временная мера). 2. Жёсткий приоритет по автоматизации именно этого toil. 3. Пересмотр процессов и границ ответственности с разработкой.

Тактика борьбы с toil¶

Обнаружение и учёт. Заведите страничку в Confluence. Каждый раз, когда инженер ловит себя на мысли "опять это делать" - попросите его записать в эту табличку: что, сколько раз в неделю/месяц, сколько времени занимает. - Задача: "Чистка дисков от логов на 20 серверах". Частота: 2 раза в неделю. Время: 30 минут. Годовые затраты: 20 серверов * 30 мин * 100 раз ≈ 100 человеко-часов.

Приоритизация. Посчитайте стоимость toil. 100 человеко-часов в год - это почти 3 рабочие недели senior-инженера. Стоит ли эта рутина 3 недель времени редкого и дорогого инженера? Гарантирую, что единственный правильный ответ - "нет".

Ликвидация. - Автоматизация: можно ли написать скрипт, который будет чистить логи по расписанию? Идеальный вариант. - Делегирование/создание инструмента: можно ли дать эту возможность самим разработчикам через self-service портал? ("Нажми кнопку — получи очищенный диск"). - Ликвидация причины: а почему диски вообще заполняются? Можно ли настроить ротацию логов на уровне ОС? Или может кто-то пишет никому не нужный debug? Можно ли уменьшить уровень логирования? Устранили коренную причину - и toil исчез навсегда.

Аллегория последней стадии: борьба с toil - это не про то, чтобы нанять больше людей вычерпывать воду из протекающей лодки. Это про то, чтобы найти и залатать дырку в днище, а потом построить систему автоматической откачки на будущее.

Наличие toil в системе это не "неизбежные издержки эксплуатации". Это признак плохого дизайна процессов и инструментов. Мириться с toil - значит делать осознанный выбор в пользу: - Медленного развития. - Постоянного стресса. - Потери лучших кадров. - Хрупкой и дорогой системы.

Всё, как мы любим.

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