DevOps / SRE-аудит
Найду слабые места в инфраструктуре
до того, как они станут инцидентом.
За 10 дней проверяю CI/CD, мониторинг, доступы, стоимость, инциденты и документацию. Где
вы теряете деньги, рискуете релизами и зависите от одного человека — и что чинить первым.
На выходе — карта, список рисков и план на 30/60/90 дней с приоритетами и трудозатратами.
$ kubectl get pods --watch
- api-gateway Running
- payment-service Running
- search-indexer Degraded
- ci-pipeline Deploying
- legacy-worker CrashLoop
Дмитриев Сергей
SRE/DevOps-инженер. 4 года на высоконагруженных сервисах: Wildberries (геосервисы), VK (SRE поиска,
~5000 серверов). 15 лет в инфраструктуре.
Резюме → 01 · Кому подходит
Продуктовая команда, которая выросла из одного сервера
Аудит полезен, если у вас 3–15 разработчиков, инфраструктура уже сложная, а отдельного
SRE/DevOps либо нет — либо он один и постоянно тушит пожары.
Подходит
- Релизы держатся на одном-двух людях, и это всех напрягает.
- CI/CD работает, но к нему боятся прикоснуться.
- Мониторинг есть, но алерты давно превратились в шум.
- Облачный счёт растёт, а внятно его никто не объяснит.
- Документация устарела или живёт в голове у одного инженера.
Не подходит
- Нужен подрядчик «на постоянный ночной on-call».
- Нужен встроенный DevOps в штат, а не точечный аудит.
- Инфраструктуры ещё нет — её только предстоит построить.
- Команда меньше 3 человек и один-два сервиса без роста.
- Деплои ломаются в последний момент, а откат — это лотерея.
- Алерты летят круглосуточно, и команда давно перестала на них реагировать.
-
Непонятно, сколько реально стоит инфраструктура и сколько из этого — оплата
простоя.
- Новый инженер вникает неделями, потому что критическое знание живёт в голове
у одного человека.
- CI/CD — набор скриптов, к которому боятся прикоснуться.
-
Всё работает — пока не вырастет нагрузка или не уйдёт человек, который всё это собирал.
Два и более пунктов — значит, система держится на удаче и паре человек. Аудит показывает,
где именно.
03 · Что вы получаете
Результат, которым пользуются
На выходе не отчёт на 50 страниц. Конкретные артефакты, с которыми команда работает сама —
открывает, читает, выполняет по пунктам.
01
Карта инфраструктуры
Что есть, как связано, где слабые места. Визуальная схема и текстовое описание
зависимостей.
02
Чеклист надёжности
По 6 направлениям: CI/CD, мониторинг, секреты, стоимость, инциденты, документация.
03
Ранжированный план улучшений
Три уровня — критично / важно / приятно иметь. У каждого пункта оценка трудозатрат в
инженеро-днях.
04
План на 30/60/90 дней
Что делать в первую очередь, чтобы результат был виден за недели, а не месяцы.
05
90-минутный разбор
С командой: находки, ответы на вопросы, фиксация приоритетов.
проблема → рекомендация
уровень · трудозатраты · эффект
По такой схеме расписан каждый пункт плана. Открываешь и видишь, что делать.
Как это выглядит на практике
Проблема Откат после неудачного релиза занимает ~40 минут и требует ручных команд.
Риск При сбое команда теряет окно восстановления — простой растёт на десятки минут.
Рекомендация Версионированные артефакты + автоматический rollback job в CI по кнопке.
Критично 2–3 инж.-дня MTTR отката: ~40 мин → ~2 мин
Таких строк в отчёте — от 15 до 40, каждая с приоритетом и оценкой трудозатрат. Это не
абстрактный документ, а список дел, по которому команда работает сама.
04 · Методология
Что проверяю
Аудит идёт по чеклисту из 6 направлений. Ниже — что именно входит в каждое. Это и есть
каркас, по которому проверяется ваша инфраструктура.
01
CI/CD
- Время и надёжность пути от коммита до прода, наличие и скорость rollback.
- Повторяемость сборок, версионирование артефактов, кэширование.
- Автотесты и quality-gate в пайплайне, ручные шаги.
- Стратегии выкатки, возможность деплоить в нерабочее время.
02
Мониторинг и алертинг
- Покрытие сервисов метриками, наличие SLI/SLO и error budget.
- Сигнал/шум: сколько алертов в день и сколько требует действия.
- On-call: расписание, эскалация, усталость от алертов.
- Дашборды: читаются ли за 30 секунд, покрывают ли бизнес-метрики.
03
Секреты и доступы
- Где живут секреты, доступ к коду, ротация ключей и паролей.
- RBAC и principle of least privilege, привилегированный доступ.
- Доступ подрядчиков, отзыв прав уволенных.
04
Стоимость
- Idle и oversized ресурсы, пустой пробег забытых сред.
- Лишние лицензии, egress-трафик, оркестрация под нагрузкой.
- Сколько из счёта за облако реально нужно.
05
Инцидент-менеджмент
- Процесс от алерта до решения: runbooks, эскалация, MTTR.
- Postmortem-культура, накопление знаний после инцидентов.
- Разделение боевой и продуктовой работы.
06
Документация и bus factor
- Актуальность runbooks и архитектурных документов.
- Где критическое знает один человек — знание в голове, а не в репозитории.
- Скорость ввода новичка, готовность к уходу ключевого сотрудника.
05 · Что обычно находят
Категории типовых находок
Не выдуманные кейсы, а то, что регулярно всплывает на реальных инфраструктурах. Чтобы было
понятно, какие находки ждать и где искать первыми.
CI/CD Пайплайн собирается только на одной машине
- Ручные шаги внутри «автоматической» выкатки, откат непредсказуем.
- Сборка не воспроизводится — захардкожены пути, версии, локальные пакеты.
- Quality-gate зелёный не потому, что всё ок, а потому что так принято.
Monitoring Сотни алертов в день, и ни одного действия
- Основная масса уведомлений — шум, на который давно перестали смотреть.
- Нет SLI/SLO — непонятно, что вообще считать здоровьем сервиса.
- Дашборды есть, но на вопрос «сервису плохо?» они не отвечают.
Secrets Токены лежат в общих чатах
- Секреты в коде, в CI-переменных, в Telegram-переписке. Ротации нет.
- Широкий доступ «на всякий случай», права уволенных отзываются с опозданием.
- Подрядчики с доступом, который им давно не нужен.
Cost Платите за то, что никто не использует
- Забытые среды и ресурсы, которые крутятся месяцами и стоят денег.
- Инстансы, загруженные на 10% от заявленного.
- Egress-трафик и лицензии, которые никто не пересматривал.
Incidents Один и тот же инцидент разбирают с нуля
- Runbooks нет — каждый раз начинают заново.
- Скорость восстановления зависит от того, кто дежурит.
- После инцидента выводы не зафиксированы и не помогают в следующий раз.
Bus factor Уход одного человека остановит релизы
- Критическое знает один инженер — без него всё встаёт.
- Документация устарела или отсутствует, новичок вникает неделями.
- Зависимость от ключевого сотрудника — реальный риск для бизнеса.
Анонимизированный пример из практики
Laravel-продукт, 5 серверов в гибриде, 3 разработчика без DevOps
B2B SaaS на Laravel, Yandex Cloud + Hetzner, GitLab без CI/CD. Команда пришла с запросом
«работает, но страшно трогать релизы».
- Критично Нет бэкапов — нигде. Отказ диска или случайный
DROP = полная потеря данных продукта.
- Критично Нет мониторинга. О том, что «сервису плохо», узнавали от пользователей, а не от алертов.
- Важно Знания об инфре — у одного человека. Документации и runbook'ов нет, релизы держатся на памяти старшего разработчика.
Что рекомендовал и план на 30/60/90 дней —
в полном разборе кейса →
06 · Почему внешний аудит
Если у вас есть своя команда
Главный контраргумент — отвечаю прямо.
У команды нет на это недели
Аудит — это сфокусированная работа, которой у инженеров в боевой ротации физически нет. Я прихожу и делаю её за них.
Со стороны виднее слепые зоны
Команда, построившая систему, к ней привыкла — то, что кажется нормой, часто оказывается проблемой. Свежий взгляд это ловит.
Моя цель — сделать себя ненужным
Выдаю ранжированный план, по которому команда работает сама. Я нужен, чтобы найти и расставить приоритеты, а не остаться в штате.
07 · Почему я
Опыт и подход
15 лет в инфраструктуре, из них 4 — SRE/DevOps под высокой
нагрузкой: Wildberries (геосервисы, Kubernetes/VictoriaMetrics), VK (SRE поиска,
~5000 baremetal-серверов), Rambler (балансировщики трафика). До этого — CI/CD и sysadmin в
продуктовых командах.
Аудит за 10 рабочих дней
Результат, заметный команде через две недели, а не через квартал. Срок фиксируем на старте.
Трудозатраты на каждое действие
В плане у каждой рекомендации — оценка в инженеро-днях. Вы заранее видите, что даст быстрый эффект, а что потребует квартал.
Прагматизм над модой
Kubernetes ради Kubernetes — это технический долг. Подбираю решение под ваш масштаб, а не под хайп.
Я не внедряю «SRE по гугловому букварю». Я нахожу конкретные слабые места и показываю, что
с ними делать.
Что я НЕ делаю
Чтобы не было ложных ожиданий — честно о границах. Моя задача — найти слабые места,
объяснить риски и дать команде понятный план действий.
✕
Не прихожу «чинить всё руками»
Аудит — это диагностика и план, не внедрение. Внедрение можно обсудить отдельно, но оно не превращается в бесконечное сопровождение.
✕
Не беру ночной on-call
Я не дежурю вместо вашей команды. Настройка on-call-процесса может быть рекомендацией, но роль дежурного — на стороне клиента.
✕
Не делаю security-pentest
Аудит доступов и секретов входит, но глубокий этичный взлом и пентест — отдельная специализация. Подскажу, к кому обратиться.
✕
Не обещаю «внедрить SRE по книге»
Google SRE — это референс, не шаблон для всех. Подбираю практики под ваш масштаб, а не копирую чужой playbook.
08 · Как проходит
10 рабочих дней
| Этап | Что | Длительность |
| Kick-off | 1 час: боли, доступы, контекст | день 1 |
| Сбор данных | код, инфраструктура, мониторинг, процессы | дни 2–5 |
| Анализ | прогон по чеклисту из 6 направлений | дни 5–8 |
| Отчёт + разбор | документ + 90 минут с командой | дни 9–10 |
Срок и доступы фиксируем на старте, дальше я работаю сам.
09 · Стоимость
Сколько это стоит
Сокращённый
Малые команды, 3–5 человек, простая инфраструктура
от 50 000 ₽
5 рабочих дней
- Карта инфраструктуры
- Чеклист надёжности по 6 направлениям
- Ранжированный план улучшений
Полный
Растущие команды, сложная или гибридная инфраструктура
80 000 – 150 000 ₽
10 рабочих дней
- Всё из сокращённого, глубже
- План на 30/60/90 дней
- 90-минутный разбор с командой
Точную цифру называю после 30-минутного звонка: вы рассказываете контекст, я говорю, смогу ли
помочь и какой формат подходит. Звонок ни к чему не обязывает.
Когда аудит окупается
Если один день простоя, ручных релизов или лишнего облака обходится вам дороже 100 000 ₽ —
аудит имеет смысл. Чаще всего он окупается на первой же найденной утечке бюджета или
предотвращённом инциденте.
10 · Гарантии и условия
Как защищён заказчик
Работа по договору
Официальный договор, закрывающие документы. Самозанятый.
NDA по умолчанию
Подписываю до начала работ.
Доступы read-only
Не вношу изменений в боевую инфру без явного запроса.
Предоплата 50%
Остаток — после передачи отчёта.
Честно о результате
Если критических находок нет — так и говорю. Мне дороже репутация, чем лишний контракт.
Нужно ли давать полный доступ к продакшену?
Нет. Достаточно read-only к коду, инфре и мониторингу. Сами секреты показывать не нужно — достаточно понимать, как они хранятся и ротируются.
А если у нас нет Kubernetes — аудит ещё работает?
Да. Методология привязана к направлениям, а не к стеку. Baremetal, виртуалки, контейнеры, serverless — проверяю одинаково.
У нас маленькая команда, 3–5 человек. Подойдёт?
Подойдёт. Для небольших инфраструктур есть сокращённый формат — 5 рабочих дней.
А вы останетесь потом сопровождать?
Если захотите — по договорённости. Но это не самоцель: план рассчитан на то, чтобы ваша команда выполнила его сама, без меня.
А с чего вы знаете, как лучше?
Четыре года SRE/DevOps на высоконагруженных сервисах в Wildberries и VK, до этого — системная эксплуатация. Видел инфру на тысячах серверов и на трёх виртуалках. Реальный опыт, а не конспект чужих презентаций.
Похоже на вашу ситуацию?
Разберём вашу инфраструктуру за 30 минут звонка и поймём, есть ли смысл в аудите. Без
обязательств и продажи сопровождения.
Бесплатная диагностика, 30 минут