Как мы оцениваем production-инфраструктуру

Нас интересует не формальное “есть / нет”, а поведение инфраструктуры при нагрузке, сбое или релизе.

По Kubernetes смотрим: состояние кластера, распределение ресурсов, сеть, хранилища, RBAC и секреты, актуальность обновлений, работоспособность backup и наблюдаемость. По DevOps-аудиту — весь релизный процесс: CI/CD-пайплайны, права на deploy, ручные шаги, предрелизные проверки, post-release smoke и порядок отката.

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

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

Для нас риск — это не абстрактная “плохая настройка”. Мы фиксируем его, когда можем ответить на четыре вопроса: что может сломаться, при каких условиях, как это ударит по сервису и чем подтвердить проблему.

Например, фраза “бэкапы есть” не закрывает риск. Важно: когда последний раз проверяли восстановление, кто имеет доступ к резервным копиям, где они хранятся и сколько времени займёт возврат сервиса.

То же с CI/CD: нас интересует не только файл pipeline, но и кто запускает deploy, какие проверки блокируют выкладку, как устроен откат и что команда делает, если smoke после релиза не прошёл.

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

Чинить production без фактов — значит добавлять новые риски. Поэтому первый этап — только сбор данных: конфигурации, метрики, логи, CI/CD, доступы, документация и история инцидентов. Никаких изменений в боевом контуре.

Такой подход даёт основу для разговора не на ощущениях, а на фактах: не “кажется, тут плохо”, а “вот место, где нет проверки восстановления / слишком широкие права / нет понятного отката”.

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

Read-only доступ — не формальность. Это способ собрать факты без влияния на сервис и сначала договориться о том, что именно нужно менять.

Итог аудита — не список замечаний “на полку”, а карта рисков с приоритетами.

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

План 30/60/90 помогает команде не утонуть в задачах. В первые 30 дней обычно закрывают критичные риски: резервное копирование, доступы, сценарий отката, критичные алерты и ручные шаги в релизах.

На горизонте 60–90 дней можно спокойно заниматься устойчивостью, автоматизацией, SRE-практиками и снижением операционной нагрузки.

План 30/60/90 — это не про красивый отчёт. Это про то, что чинить сейчас, что поставить в ближайший спринт, а что не трогать без необходимости.

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

• Карта рисков с приоритетами: причина, влияние, подтверждение, рекомендуемое действие и следующий шаг.
• План работ на 30/60/90: задачи с владельцами и ожидаемым эффектом.
• Список критичных доступов и избыточных прав.
• Рекомендации по резервному копированию и восстановлению.
• Чек-лист релиза и post-release smoke.
• Сценарий отката для критичных изменений.
• Рекомендации по алертам, дашбордам и первым действиям при инциденте.

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

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

В таких случаях SRE-поддержка идёт после аудита: регулярные проверки, помощь с инцидентами, сопровождение изменений, настройка мониторинга, проверка резервного копирования и поддержка релизного процесса.

Это не замена внутренней команде, а внешний инженерный слой, который помогает держать production под контролем и не оставлять риски “на потом”.

Мы опираемся на проверяемые факты: конфигурацию, логи, метрики, пайплайны, события, права доступа и результаты тестов восстановления.

Начинаем с read-only и не трогаем production, пока не понятны зависимости, цель изменения и сценарий отката.

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

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

Если риск можно снизить небольшим изменением, предлагаем именно его, без лишних усложнений.

• Карта рисков с приоритетами: причина, влияние, подтверждение, рекомендуемое действие и следующий шаг.
• План работ на 30/60/90: задачи с владельцами и ожидаемым эффектом.
• Список критичных доступов и избыточных прав.
• Рекомендации по резервному копированию и восстановлению.
• Чек-лист релиза и post-release smoke.
• Сценарий отката для критичных изменений.
• Рекомендации по алертам, дашбордам и первым действиям при инциденте.
• Список задач для внутренней команды или внешней поддержки.

Если часть рисков нельзя закрыть сразу, они не теряются: попадают в план с понятным владельцем, причиной и ожидаемым эффектом.