Стратегия автоматизации: что автоматизировать в первую очередь?¶

Представьте, что вы капитан корабля. У вас течёт трюм, сломан компас и заело штурвал. Что чинить первым? Если начать с компаса, корабль может утонуть, пока вы его настраиваете. Если начать с трюма — вы залатаете течь, но без компаса уплывёте не туда.

Примерно так же выглядит автоматизация в SRE. Всё автоматизировать сразу нельзя, потому что мы живем в реальном мире и на все сразу не хватит ресурсов. Но и автоматизировать «что-нибудь» бессмысленно, если это не решает реальных проблем. Нужна стратегия.

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

Прежде чем говорить, что автоматизировать, давайте решим, что автоматизировать не стоит вообще.

Не автоматизируйте хаос. Если процесс нестабилен и результаты непредсказуемы, автоматизация только ускорит воспроизведение проблем. Сначала сделайте процесс воспроизводимым и предсказуемым, потом автоматизируйте.

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

Не автоматизируйте, не измерив. Если вы не можете ответить на вопрос «стало ли лучше после автоматизации?», то вы не узнаете, сработало ли вложение. Почитайте главу про toil (ручной труд) — там как раз про то, как измерить боль и приоритизировать автоматизацию.

Приоритет: матрица частоты и боли¶

Самый простой и рабочий фреймворк для выбора — матрица из двух осей: как часто операция выполняется и насколько она болезненна.

	Делаем редко	Делаем часто
Больно	Пишем runbook	Автоматизируем в первую очередь
Не больно	Оставляем как есть	Автоматизируем, когда есть время

Больно — значит: - Требует доступа к продовой консоли с риском что-то сломать - Долго делается (часы вместо минут) - Требует вспоминать последовательность из 20 шагов - Без неё простаивает бизнес

Часто — значит: - Несколько раз в неделю или каждый день - Каждое дежурство повторяется

Жирные слоты в правом верхнем углу — ваша цель №1.

Примеры из жизни: - Перезапуск упавшего сервиса — часто и больно → автоматизируем (systemd/supervisor/k8s selfhealing) - Добавление нового пользователя в БД — редко, но больно → пишем runbook - Чтение логов для отладки — часто, но не больно → можно автоматизировать позже - Восстановление с бекапа после катастрофы — редко, ОЧЕНЬ больно → пишем runbook + раз в квартал DRT (disaster recovery test)

Пирамида автоматизации¶

Автоматизация в SRE выстраивается слоями:

         ┌──────────┐
         │ Self-    │  ← Система чинит себя сама
         │ healing  │    (k8s, автоскейлинг, circuit breaker)
         ├──────────┤
         │ CI/CD    │  ← Автоматический деплой и тесты
         │ pipeline │    (GitLab CI, GitHub Actions, ArgoCD)
         ├──────────┤
         │ Scripts  │  ← Скрипты для типовых операций
         │   &      │    (bash, Ansible, Python)
         │ runbooks │
         ├──────────┤
         │ Manual   │  ← Всё руками, но документировано
         │   ops    │    (runbook + checklist)
         └──────────┘

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

Практические советы¶

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

Следом — мониторинг и алертинг. Автоматическая реакция на алерт (например, перезапуск пода при падении healthcheck) убирает самый частый ручной toil.

Потом — бэкапы и восстановление. Скрипт, который делает бекап и проверяет его целостность, стоит потраченного времени.

Самое сложное — управление конфигурацией и доступом. Здесь много исключений, и автоматизация часто ломается о «а дайте этому разработчику доступ вот к этой консоли, но не к этой, а вон к той». Не пытайтесь автоматизировать всё сразу.

Антипаттерны¶

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

«Скрипт вместо runbook» — автоматизация без документации превращается в чёрный ящик. Если скрипт сломался, его никто не починит, потому что никто не знает, что он делает. Runbook должен жить рядом со скриптом.

«Кнопка для всего» — не каждую операцию нужно выносить в веб-интерфейс. Чат-бот, который по команде /deploy запускает пайплайн, иногда полезнее, чем отдельный портал с пятью формами.

Итог¶

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

1. Какая ручная операция отнимает больше всего времени команды?
2. Можно ли её автоматизировать без риска для прода?
3. Что мы выиграем, если это заработает?

Подробнее про принцип автоматизации — в главе «Автоматизация, мониторинг, измерение всего». А про то, как отличать toil от инженерной работы — в главе «Toil: враг номер один».

Автоматизация в SRE — это не соревнование «у кого меньше ручных действий». Это про то, чтобы инженеры занимались инженерией, а не перезапуском сервисов в три часа ночи.