Рутина и автоматизация: что автоматизировать, а что убрать

В команде из шести человек есть операция: раз в две недели кто-то заходит на сервер, продлевает TLS-сертификат, раскладывает его по трём узлам и перезапускает балансировщик. Полтора часа. Все знают, что это глупо. Все знают, что есть cert-manager, ACME и десяток других способов. И всё равно продлевают руками — уже третий год.

Спросите почему, и услышите: «руки не доходят». Это неправда. Руки не доходят до задач, у которых нет числа. У этой оно есть: 1,5 часа × 26 раз = 39 часов в год, при полной стоимости инженера в 120 000 USD в год это примерно 2 500 USD — за операцию, которую разово автоматизируют за три дня. Никто не считал, поэтому задача проиграла конкуренцию за внимание любой фиче, у которой число было.

Эта глава — про то, как перевести рутину из категории «неприятно» в категорию «столько-то часов и столько-то денег», и про то, что делать дальше. Дальше — не всегда «автоматизировать». Довольно часто правильный ответ: убрать саму задачу, а иногда — оставить руками сознательно, потому что автоматика здесь опаснее человека.

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

Что такое рутина и что ею не является

Термин toil закрепился за конкретным понятием, и определение стоит взять целиком — оно неплохое (глава «Eliminating Toil» книги Google SRE, sre.google/sre-book/eliminating-toil).

Рутина — это операционная работа, которая одновременно: выполняется вручную, повторяется, поддаётся автоматизации, реактивна, не оставляет после себя улучшения и растёт линейно с размером сервиса.

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

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

Чем рутина не является

Рутина ≠ вся операционная работа. Это самая частая и самая вредная подмена. Расследование странного поведения системы, разбор инцидента, ревью чужого дизайна на предмет отказов, чтение метрик перед пиковым сезоном — операционная работа, но не рутина: она оставляет знание. Команда, которая объявила рутиной всё операционное, довольно быстро автоматизирует то, что автоматизировать нельзя, и разучится смотреть на систему.

Рутина ≠ скучная работа. Ручное подтверждение платежей может быть смертельно скучным и при этом обязательным по регуляторике. Написание постмортема скучно многим — а это самая ценная работа недели («Постмортемы»).

Рутина ≠ работа, которую вы не любите. Соблазн подвести под определение всё, что раздражает, огромен. Проверка: приложите шесть признаков и честно ответьте по каждому.

Не рутина, но такая же дорогая: совещания, ожидание согласований, переключение между задачами. Их эта глава не лечит — про них «Коммуникационная нагрузка».

Как измерить: журнал рутины

Всё, что не измерено, обсуждается ощущениями, а в споре ощущений выигрывает тот, кто громче. Поэтому первое действие — не автоматизация, а четыре недели журнала.

Правила журнала простые и должны оставаться простыми, иначе его ведение само станет рутиной:

• строка = операция, а не задача. «Перезапустил воркер» — строка. «Разбирался с платежами» — нет;
• поля: дата, операция, минуты, кто, было ли это прерыванием;
• заводится по факту, не по памяти. Память занижает рутину в два-три раза: короткие частые операции не запоминаются вовсе;
• четыре недели, потому что месячная сезонность реальна: конец месяца, релизный цикл, закрытие квартала.

Вот как выглядит результат для условной команды из шести человек. Числа правдоподобные, специально не героические.

Теперь арифметика, ради которой всё затевалось.

Недельный бюджет команды:  6 человек × 40 ч = 240 нормо-часов
Доля рутины:               35,43 / 240 = 14,8 %
За год (46 рабочих недель): 35,43 × 46 = 1 630 ч
В ставках:                 1 630 / 1 840 = 0,89 FTE
В деньгах при 120 000 USD полной стоимости: 0,89 × 120 000 ≈ 107 000 USD в год

Почти целый инженер, которого нет в штатном расписании. Это число и есть предмет разговора с руководителем — не «нам тяжело», а «мы ежегодно тратим 107 000 USD на работу, часть которой стоит 40 часов разработки».

К прямым часам добавляется налог на прерывания. В исследованиях группы Глории Марк среднее время возврата к прерванной задаче — около 23 минут (Mark, González, Harris, CHI 2005); последующая работа той же группы показала, что прерванную задачу люди доделывают быстрее, но ценой стресса и ошибок (CHI 2008). Не будем брать верхнюю оценку — возьмём консервативные 10 минут испорченного контекста:

35 прерываний в неделю × 10 мин = 350 мин = 5,83 ч
Итого с налогом: 35,43 + 5,83 = 41,3 ч/нед = 17,2 % бюджета

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

Порог, за которым команда останавливается

Признак «растёт линейно» позволяет предсказать дату катастрофы. Пусть рутина занимает долю r бюджета и растёт вместе с сервисом на g в месяц, а команда растёт на h в месяц.

r = 0,148 (текущая доля)
g = 4 % в месяц (рост числа сервисов и трафика)
h = 0 (найма нет)

Через t месяцев: r(t) = 0,148 × 1,04^t
r(t) = 0,50  →  1,04^t = 3,378  →  t = ln(3,378)/ln(1,04) = 1,217/0,0392 ≈ 31 месяц
r(t) = 1,00  →  1,04^t = 6,757  →  t = 1,911/0,0392 ≈ 49 месяцев

Через два с половиной года команда тратит на рутину половину времени, через четыре — всё. Точность этих чисел иллюзорна, а порядок величины — нет: при линейном росте рутины и отсутствии найма горизонт измеряется годами, а не десятилетиями. Это тот же механизм, что и в «Ёмкости и нагрузке», только исчерпывается не CPU, а люди.

Лестница: убрать, упростить, автоматизировать

Главная ошибка главы «про автоматизацию» — считать, что автоматизация является ответом. Она четвёртая по силе из шести, и перед ней стоят более дешёвые варианты.

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

Ступень 0 стоит отдельного абзаца, потому что её почти никогда не пробуют. Практика, которая работает: раз в квартал берите три самые дорогие строки журнала и задавайте вопрос буквально — «что сломается, если мы перестанем это делать в понедельник?». В трети случаев выясняется, что квартальный отчёт по доступности читал один человек, который уволился в позапрошлом году, а еженедельная проверка бэкапов дублирует автоматическую, добавленную полгода назад и всеми забытую.

Ступень 1 — про то, что автоматизация умеет консервировать дефекты. Скрипт, который перезапускает подвисший воркер, не чинит утечку памяти — он делает её невидимой, и через год никто уже не помнит, что воркер вообще подвисает. Это классический архетип «подмена проблемы симптоматическим решением» («Архетипы систем»): симптоматическое лечение снимает давление, из-за которого кто-то мог бы заняться причиной, и способность заняться причиной атрофируется.

Арифметика окупаемости

Когда лестница довела вас до ступени 4 или 5, наступает время посчитать. Формула честная и включает то, что обычно забывают, — сопровождение.

t_р   — время ручного выполнения, ч
t_а   — время при автоматизации (не ноль: запуск, наблюдение, разбор сбоев), ч
f     — частота в год
C     — стоимость разработки, ч
M     — сопровождение, ч/год
L     — сколько лет операция ещё будет нужна

Экономия за год = (t_р − t_а) × f − M
Срок окупаемости = C / Экономия за год        [лет]

Если «Экономия за год» ≤ 0 — не окупится никогда, каким бы дешёвым ни было C.
Если «Срок окупаемости» > L — не окупится в этой жизни сервиса.

Прогоним через неё строки журнала.

Проверим одну строку целиком, чтобы формула не осталась абстракцией:

Выкатка релиза:
  (0,92 − 0,08) × 368 = 0,84 × 368 = 309,1 ч/год валового выигрыша
  309,1 − 20 (сопровождение) = 289,1 ч/год чистого
  120 / 289,1 = 0,415 года ≈ 5 месяцев
За два года: 289,1 × 2 − 120 = 458 ч сэкономлено ≈ 0,27 человеко-года

Практическое правило для чтения последней колонки:

• меньше 6 месяцев — делайте, обсуждать нечего;
• 6–18 месяцев — зависит от L: доживёт ли операция, не выводится ли сервис, не меняется ли платформа;
• больше 18 месяцев — почти всегда нет. Вернитесь на лестницу и попробуйте ступень выше.

Две ловушки в этой таблице, направленные в разные стороны

Ловушка первая: лучший ROI указывает на неверное действие. Перезапуск воркера окупается за месяц — формально лучшая инвестиция в таблице. И это ловушка: 1012 подвисаний в год означают дефект. Автоматический перезапуск — ступень 5 для задачи, которая решается на ступени 1. Арифметика окупаемости отвечает на вопрос «стоит ли автоматизировать», но не на вопрос «нужно ли вообще это делать». Сначала лестница, потом калькулятор.

Ловушка вторая: формула не считает риск. Проверка восстановления из бэкапа окупается за шесть лет — по часам она не проходит. Но автоматизация здесь покупает не часы, а регулярность: ручная проверка раз в неделю на практике превращается в проверку раз в квартал, потом никогда, и обнаруживается это в день, когда бэкап нужен по-настоящему. Ровно это случилось с GitLab 31 января 2017 года: пять механизмов резервного копирования, и ни один не работал — выяснилось в момент, когда инженер удалил каталог данных на боевом узле вместо реплики (разбор GitLab).

Когда автоматизация покупает не часы, а снижение вероятности катастрофы, считайте по-другому: вероятность × ущерб. Если непроверенный бэкап даёт 3 % годовой вероятности потери суток данных, а сутки данных стоят 400 000 USD, ожидаемый ущерб — 12 000 USD в год против 100 часов разработки. Считать так труднее и спорить о числах будут дольше — но это честнее, чем прятать риск в колонку «часы».

Про xkcd

Таблицу «стоит ли тратить время на автоматизацию» из xkcd 1205 знают все, и она полезна как первое приближение. У неё два дефекта: она не учитывает сопровождение и молчаливо предполагает, что автоматизация работает. Второй дефект автор сам же и высмеял в xkcd 1319: график «времени на задачу» после автоматизации уходит вверх. Держите в голове обе картинки.

Что с чем делать: карта решений

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

Верхний левый квадрант — самый интересный и самый спорный. Переключение на резервный регион делается раз в год, стоит дорого и ошибка необратима. Полная автоматизация здесь соблазнительна и опасна: код, который выполняется раз в год, ломается тихо, а проверить его можно только тем самым переключением. Рабочий компромисс — автоматизировать шаги, но не решение: автоматика умеет всё сделать одной командой, но команду даёт человек, и на репетициях это проверяется («Проверка отказом»).

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

Уровни зрелости операции

Между «делаем руками» и «система не требует операции» шесть ступеней, и полезно знать, на какой вы находитесь по каждой строке журнала.

Три вещи, которые видно на диаграмме и не видно в разговорах об автоматизации.

Переходы бывают вниз. Рунбук, который не обновляли год, хуже отсутствия рунбука: дежурный выполняет по нему команды, которые уже не работают, и тратит время на диагностику собственных действий. Уровень зрелости — не достижение, а состояние, которое надо поддерживать.

L4 не всегда лучше L3. Замкнутая петля выигрывает время реакции — секунды вместо минут — и проигрывает в способности остановиться, когда ситуация не та, для которой её писали. Правило простое: необратимое действие в L4 не выносится. Убрать узел из балансировки — обратимо, можно L4. Удалить том, применить миграцию, отправить деньги — L3 и только L3.

L5 достижим чаще, чем кажется. Чистка диска исчезает, когда логи ротируются по размеру и уезжают в хранилище. Ручная выдача доступов исчезает, когда права привязаны к группе, а группа — к роли в кадровой системе («Авторизация»). Это не автоматизация операции, а исчезновение операции — и сопровождать после этого нечего.

Автоматика масштабирует ошибку

Здесь начинается вторая половина главы, и она про цену. Автоматизация не убирает риск, она меняет его форму: вероятность ошибки падает, а радиус поражения одной ошибки растёт.

Человек, удаляющий серверы вручную, удалит два и заметит. Скрипт удалит четыреста за восемь секунд и напишет «done». 28 февраля 2017 года инженер Amazon по утверждённому рунбуку выполнил команду для вывода небольшого числа серверов подсистемы биллинга S3; один из входных параметров был введён неверно, и выведено было существенно больше, чем предполагалось, включая серверы двух подсистем, критичных для работы всего региона (разбор AWS). Восстановление заняло часы, потому что эти подсистемы не перезапускались полностью много лет.

В том же разборе Amazon называет и правку — она стоит того, чтобы выписать её отдельно:

Инструмент был изменён так, чтобы удалять мощность медленнее и блокировать удаление, если оно опускает уровень ниже минимально допустимого.

Обратите внимание на форму правки. Не «обучили инженера», не «добавили подтверждение», а проверка постусловия внутри инструмента: не «сколько удалить», а «сколько останется». Это переносится дословно почти на любую автоматику.

Другие поучительные случаи:

• AWS EBS, 21 апреля 2011. Ошибка при изменении сети привела к тому, что автоматика зеркалирования томов начала массово искать свободное место; поиск сам съел ресурс, и получился шторм, который система не могла погасить самостоятельно (разбор AWS). Автоматика восстановления стала причиной каскада — тот же механизм усиливающей петли, что разобран в «Как ломаются распределённые системы» и в «Петлях обратной связи».
• Knight Capital, 1 августа 2012. Развёртывание выполнялось вручную на восемь серверов, на одном старый код остался. За 45 минут компания потеряла около 440 млн USD и фактически перестала существовать (материалы SEC). Здесь наоборот: недостаток автоматизации выкатки, помноженный на отсутствие проверки, что на всех узлах одна версия.
• Meta, 4 октября 2021. Команда, отданная в ходе плановых работ, отключила магистральные соединения дата-центров; инструмент аудита, который должен был такую команду не пропустить, содержал дефект (разбор Meta). Отдельная неприятность: из-за отказа отвалились и системы, через которые чинят, — включая физический доступ в здания.

Последний пункт стоит запомнить как отдельное правило: автоматика не должна зависеть от того, что она чинит. Иначе в момент, когда она нужна, её нет.

Ограничители: что должно быть в любой автоматике, трогающей прод

Обязательный набор, который стоит требовать на ревью любой автоматики:

Строка «журнал намерения» экономит часы в постмортеме. Запись удалил 12 подов бесполезна. Запись p99 = 4,2 с при пороге 2,0 с, гипотеза: перегрев узла node-17, действие: снять 12 подов из 80, разрешённый лимит 16 позволяет через месяц понять, ошиблась автоматика в наблюдении или в решении.

Ирония автоматизации

Самое неудобное свойство хорошей автоматики описано в 1983 году, задолго до всякого SRE — Лизанной Бейнбридж в статье «Ironies of Automation» (Automatica, 19(6), 775–779). Статья про авиацию и промышленные установки, но переносится дословно.

Ирония первая. Проектировщик автоматизирует то, что умеет формализовать, и оставляет человеку остаток. Остаток — это ровно те случаи, которые формализовать не удалось: редкие, странные, неоднозначные. То есть автоматика забирает лёгкую работу и оставляет человеку только трудную.

Ирония вторая. Чтобы человек мог вмешаться, когда автоматика не справилась, он должен быть в форме. Но навык поддерживается практикой, а практику у него забрала автоматика.

Дальше складывается усиливающая петля, и её полезно нарисовать в голове так, как это делают в «Петлях обратной связи»:

надёжнее автоматика
   → реже человек вмешивается
      → хуже навык и слабее модель системы в голове
         → дольше и хуже разбор редкого отказа
            → «надо автоматизировать ещё больше»
               → надёжнее автоматика …

Петля усиливающая, с задержкой: деградация навыка не видна, пока не случится редкий отказ, а редкий отказ на то и редкий, чтобы случиться через полтора года. Про такие задержки — «Задержки».

Что с этим делают на практике:

• Ручной прогон по расписанию. Раз в квартал типовая операция выполняется руками по рунбуку, даже если автоматика работает. Дорого — 2–3 часа. Дешевле, чем три часа тыканья вслепую в момент реального отказа.
• Учения и game day. Автоматику выключают и смотрят, справится ли команда («Проверка отказом»).
• Автоматика объясняет себя. Каждое действие сопровождается человекочитаемым «почему» — так модель системы у дежурного не разваливается.
• Рунбук не удаляют после автоматизации. Он становится описанием того, что делает автоматика, и инструкцией на случай, когда её нет.
• Новичок проходит операции руками. Один раз, под присмотром. Это часть онбординга, а не пустая трата времени («Онбординг»).

Прерывания и тикеты: рутина, которая не выглядит рутиной

В журнале выше самая дорогая строка после релизов — «ответы на однотипные вопросы в чате»: 5,25 часа прямых плюс около 5,8 часа налога на прерывания. Это не автоматизируется скриптом, поэтому обычно вообще не рассматривается как рутина. Зря: по всем шести признакам подходит.

Механики, которые работают:

Роль «дежурного по прерываниям». Один человек в неделю принимает на себя все вопросы, остальные не отвлекаются. Число прерываний не меняется, но они собираются в одного человека, и пятеро остальных получают целые дни. Роль совмещается с дежурством по инцидентам только в маленькой команде и только осознанно — иначе человек не делает ни того, ни другого («Дежурство»).

Один вход вместо чата. Вопрос, заданный в личку, невидим, не считается и не превращается в задачу. Тот же вопрос в общем канале с тегом виден, считается и через месяц оказывается в топе списка «что автоматизировать».

Классификация раз в месяц. Пятнадцать минут: разложить вопросы недели по категориям. Обычно 60–70 % приходятся на три-четыре типа, и каждый лечится либо документацией, либо самообслуживанием, либо более понятным сообщением об ошибке. Самая недооценённая правка — третья: «почему упал мой пайплайн» перестают спрашивать, когда пайплайн пишет, почему он упал.

Самообслуживание как основной ответ. Тридцать пять вопросов в неделю — это не проблема коммуникации, это проблема доступа: люди спрашивают, потому что не могут сделать сами. Платформенный подход разбирается в «Топологиях команд», инструментальная часть — в треке DevOps.

Где инженерное упирается в организационное

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

Последняя строка — ловушка, знакомая всем: рутина съедает время, которое требуется на устранение рутины. Это тот же архетип «подмены проблемы», только с обратным знаком, и он не разрывается изнутри. Разрывается он одним способом: временем, выделенным заранее и защищённым, а это решение уже не ваше.

Вторая строка стоит отдельного комментария, потому что она про доброту, которая вредит. Когда ваша команда автоматизирует и чинит чужую рутину, вы субсидируете чужое поведение: у владельца сервиса исчезает стимул что-либо менять, и объём субсидии растёт. Переносить работу к источнику неприятно и правильно; смежная тема со стороны руководителя — «Делегирование» и «Дежурства и инциденты».

Как защитить время на устранение рутины

Знаменитое правило «не более 50 % времени SRE на операционную работу» — из книги Google. У него есть предпосылка, которую обычно не цитируют: должна существовать вторая половина и человек, чья работа — следить за пропорцией. В команде, где SRE и разработчик — один и тот же человек, а продуктовые сроки давят с другой стороны, правило не защищается ничем.

Что работает вместо него в командах обычного размера:

Квота, а не доля. Не «50 % времени», а «один день в неделю» или «15 % ёмкости спринта». Квота видна в планировании, доля — нет. День, вписанный в календарь, отменить труднее, чем абстрактный процент.

Правило трёх. Сделали операцию руками третий раз — заводите задачу. Не автоматизируйте с первого раза: вы ещё не знаете, как задача выглядит на самом деле, и автоматизируете первую версию своего непонимания. Тот же принцип, что за DRY.

Один инцидент — одна правка рутины. В список действий постмортема добавляется ровно один пункт про устранение ручной операции, всплывшей во время инцидента. Механизм работает, потому что после инцидента внимание к теме максимально («Постмортемы»).

Связка с бюджетом ошибок. Если бюджет сожжён, релизы притормаживают, а высвободившееся время идёт в надёжность — и устранение рутины является работой по надёжности, а не «улучшайзингом» («Бюджет ошибок»). Это единственная известная мне конструкция, которая приносит время на рутину автоматически, без ежеквартального выпрашивания.

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

Полезная привычка: каждую квартальную сводку по рутине заканчивать одной строкой в деньгах. Не «мы сократили рутину на 23 %», а «мы вернули в разработку 0,69 ставки, это около 83 000 USD в год, при затратах 260 часов». Такую строку понимают за пределами инженерии; смежная арифметика — в «Юнит-экономике» и «Стоимости облака».

Что не автоматизировать

Отдельный список, потому что «автоматизируй всё» — самая дорогая из популярных установок.

• Редкое и необратимое. Раз в год, ошибка невосстановима — оставляйте человека в петле. Код, который не выполняется, гниёт незаметно.
• То, что меняется каждый раз. Если из десяти выполнений восемь разные, вы автоматизируете не операцию, а её частный случай, и получите скрипт с двенадцатью флагами, который никто не понимает.
• То, что скоро исчезнет. Сервис выводится через полгода, платформа мигрирует, формат отчёта пересматривается — L в формуле окупаемости меньше срока окупаемости.
• Решения, а не действия. «Откатывать ли релиз», «объявлять ли инцидент», «переключать ли регион» — автоматика может подготовить, посчитать и предложить; выбирать в неоднозначной ситуации она не умеет, а её уверенность вводит в заблуждение.
• То, где стоимость ошибки автоматики выше экономии. Считается прямо: вероятность отказа автоматики × средний ущерб против годовой экономии. Если первое больше — не надо.
• Чужую рутину без спроса. Автоматика без владельца превращается в оранжевую линию с картинки выше.
• То, что автоматизируется ради интереса. Здесь помогает только честность: вам хочется написать оператор Kubernetes, а задача решается строчкой в systemd-юните.

Типичные ошибки

Автоматизировали до того, как поняли. Скрипт зафиксировал случайный порядок шагов, который сложился исторически. Через год никто не помнит, зачем шаг четвёртый, но трогать боятся.

Автоматика без наблюдаемости. Она работает, о ней забыли, полгода назад она перестала делать половину работы, и никто не заметил. Правило: у автоматики есть метрика «сколько раз сработала» и алерт на её отсутствие. Ноль срабатываний за неделю — это либо победа, либо поломка, и различить их надо автоматически («Мониторинг»).

Автоматизация как замена разговору. Команда обходит организационное препятствие скриптом. Скрипт живёт, препятствие тоже, а сложность растёт с обеих сторон.

Скрипт вместо сервиса. Файл deploy.sh в домашнем каталоге одного человека — не автоматизация, а концентрация риска. Признаки настоящей автоматизации: лежит в репозитории, проходит ревью, покрыт тестами, запускается всеми, имеет владельца («Автоматизация в Git», «Стратегия автоматизации»).

Забыли про сопровождение в оценке. Обещали «40 часов», забыли про 20 часов в год на поддержку и три инцидента, вызванных самой автоматикой. Кладите M в оценку сразу — это делает разговор честным.

Перепутали удаление рутины с удалением понимания. Автоматизировали операцию, выкинули рунбук, через год отказ автоматики, и никто не знает, что она вообще делала. Рунбук остаётся.

Считают рутиной то, чем она не является. Расследование, дизайн-ревью, разбор инцидента — не рутина. Команда, которая «оптимизировала» их, экономит на единственной работе, которая уменьшает будущие инциденты.

Что переносится из практики Google, а что нет

Глава «Eliminating Toil» в книге Google SRE и её продолжение в SRE Workbook полезны — но написаны про компанию с отдельными SRE-командами, платформенными сервисами и возможностью выделить квартал на устранение рутины. Разделим.

Переносится почти без изменений:

• само определение и шесть признаков — они не зависят от масштаба;
• журнал рутины: четыре недели наблюдения работают в команде любого размера;
• арифметика окупаемости с сопровождением;
• лестница «удалить — убрать причину — самообслуживание — упростить — человек в петле — петля»;
• ограничители радиуса поражения; проверка постусловия из разбора S3 переносится дословно;
• принцип «третий раз руками — заводим задачу»;
• ирония автоматизации и ручные прогоны по расписанию — они вообще не из Google, а из авиации.

Не переносится:

• правило 50 % — оно предполагает существование выделенной роли и человека, который следит за пропорцией. Измеряйте долю всё равно: это аргумент в разговоре о найме;
• отдельные проекты по устранению рутины на квартал — в команде из пяти человек рутина устраняется квотой в один день в неделю, а не выделенным проектом;
• своя платформа самообслуживания — на масштабе Google дешевле написать, у вас почти всегда дешевле взять готовое: managed-сервисы, cert-manager, GitOps («Terraform и IaC», «Конфигурация»);
• право SRE вернуть сервис команде разработки — организационный рычаг, которого у вас, скорее всего, нет; вместо него работают переговоры и видимые числа;
• сложная автоматика восстановления — на масштабе Google отказ узла рутинен и обязан лечиться без человека. Если у вас двенадцать узлов и отказ раз в квартал, замкнутая петля обойдётся дороже, чем разбуженный дежурный, и будет опаснее.

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

Мини-итог

• Рутина — шесть признаков сразу, а не «скучная работа». Признак «растёт линейно с сервисом» превращает её из неудобства в срок годности команды.
• Не измерено — не существует. Четыре недели журнала дают число в часах, ставках и деньгах; в нашем примере 35,4 ч/нед, 0,89 ставки, около 107 000 USD в год.
• Автоматизация — четвёртый по силе ответ. Выше стоят: удалить задачу, убрать причину, отдать в самообслуживание, упростить и описать.
• Окупаемость считается с сопровождением: (t_р − t_а) × f − M, срок C / экономия. Меньше 6 месяцев — делайте, больше 18 — почти наверняка нет.
• Формула считает часы и не считает риск. Там, где автоматизация покупает регулярность и снижает вероятность катастрофы, считайте вероятность × ущерб.
• Лучший ROI в таблице часто указывает на дефект: тысяча перезапусков в год — это баг, а не задача на автоматизацию.
• Автоматика уменьшает вероятность ошибки и увеличивает её радиус. Обязательны: идемпотентность, проверка постусловия, лимит на партию, скорость, стоп-кран, сухой прогон, однократность, владелец, журнал намерения.
• Автоматика не должна зависеть от того, что она чинит.
• L4 не всегда лучше L3: необратимое действие в замкнутую петлю не выносится.
• Ирония автоматизации реальна: надёжная автоматика забирает практику у человека, и это лечится ручными прогонами и учениями, а не увеличением автоматизации.
• Прерывания — тоже рутина, самая незаметная. Лечится не терпением, а одним входом, ролью дежурного по вопросам и самообслуживанием.
• Значительная часть рутины держится на организационных причинах. Называйте их вслух: инженерная работа не устранит политику доступа.

Источники

• Google SRE Book, глава «Eliminating Toil» — sre.google/sre-book/eliminating-toil
• Google SRE Workbook, глава «Eliminating Toil» — sre.google/workbook/eliminating-toil
• Lisanne Bainbridge, «Ironies of Automation», Automatica 19(6), 1983 — sciencedirect.com
• Mark, González, Harris, «No Task Left Behind? Examining the Nature of Fragmented Work», CHI 2005 — ics.uci.edu
• Mark, Gudith, Klocke, «The Cost of Interrupted Work: More Speed and Stress», CHI 2008 — ics.uci.edu
• Разбор отказа Amazon S3, 28 февраля 2017 — aws.amazon.com/message/41926
• Разбор отказа Amazon EBS, 21 апреля 2011 — aws.amazon.com/message/65648
• Постмортем GitLab, 31 января 2017 — about.gitlab.com
• Материалы SEC по делу Knight Capital, 2013 — sec.gov
• Разбор отказа Meta, 4 октября 2021 — engineering.fb.com
• xkcd 1205 «Is It Worth the Time?» — xkcd.com/1205 и xkcd 1319 «Automation» — xkcd.com/1319

Что дальше

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

SRE в небольшой команде: что переносится, а что нет