DevOps / SRE-аудит

Найду слабые места в инфраструктуре
до того, как они станут инцидентом.

За 10 дней проверяю CI/CD, мониторинг, доступы, стоимость, инциденты и документацию. Где вы теряете деньги, рискуете релизами и зависите от одного человека — и что чинить первым. На выходе — карта, список рисков и план на 30/60/90 дней с приоритетами и трудозатратами.

Бесплатная диагностика, 30 минут

Разберём вашу ситуацию и поймём, есть ли смысл в аудите. Без обязательств.

Дмитриев Сергей SRE/DevOps-инженер. 4 года на высоконагруженных сервисах: Wildberries (геосервисы), VK (SRE поиска, ~5000 серверов). 15 лет в инфраструктуре. Резюме →

01 · Кому подходит

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

Аудит полезен, если у вас 3–15 разработчиков, инфраструктура уже сложная, а отдельного SRE/DevOps либо нет — либо он один и постоянно тушит пожары.

Подходит

  • Релизы держатся на одном-двух людях, и это всех напрягает.
  • CI/CD работает, но к нему боятся прикоснуться.
  • Мониторинг есть, но алерты давно превратились в шум.
  • Облачный счёт растёт, а внятно его никто не объяснит.
  • Документация устарела или живёт в голове у одного инженера.

Не подходит

  • Нужен подрядчик «на постоянный ночной on-call».
  • Нужен встроенный DevOps в штат, а не точечный аудит.
  • Инфраструктуры ещё нет — её только предстоит построить.
  • Команда меньше 3 человек и один-два сервиса без роста.

02 · Боль

Знакомо?

Два и более пунктов — значит, система держится на удаче и паре человек. Аудит показывает, где именно.

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 направлениям
  • Ранжированный план улучшений

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

Когда аудит окупается

Если один день простоя, ручных релизов или лишнего облака обходится вам дороже 100 000 ₽ — аудит имеет смысл. Чаще всего он окупается на первой же найденной утечке бюджета или предотвращённом инциденте.

Бесплатная диагностика

10 · Гарантии и условия

Как защищён заказчик

Работа по договору

Официальный договор, закрывающие документы. Самозанятый.

NDA по умолчанию

Подписываю до начала работ.

Доступы read-only

Не вношу изменений в боевую инфру без явного запроса.

Предоплата 50%

Остаток — после передачи отчёта.

Честно о результате

Если критических находок нет — так и говорю. Мне дороже репутация, чем лишний контракт.

11 · FAQ

Частые вопросы

Нужно ли давать полный доступ к продакшену?

Нет. Достаточно read-only к коду, инфре и мониторингу. Сами секреты показывать не нужно — достаточно понимать, как они хранятся и ротируются.

А если у нас нет Kubernetes — аудит ещё работает?

Да. Методология привязана к направлениям, а не к стеку. Baremetal, виртуалки, контейнеры, serverless — проверяю одинаково.

У нас маленькая команда, 3–5 человек. Подойдёт?

Подойдёт. Для небольших инфраструктур есть сокращённый формат — 5 рабочих дней.

А вы останетесь потом сопровождать?

Если захотите — по договорённости. Но это не самоцель: план рассчитан на то, чтобы ваша команда выполнила его сама, без меня.

А с чего вы знаете, как лучше?

Четыре года SRE/DevOps на высоконагруженных сервисах в Wildberries и VK, до этого — системная эксплуатация. Видел инфру на тысячах серверов и на трёх виртуалках. Реальный опыт, а не конспект чужих презентаций.

Похоже на вашу ситуацию?

Разберём вашу инфраструктуру за 30 минут звонка и поймём, есть ли смысл в аудите. Без обязательств и продажи сопровождения.

Бесплатная диагностика, 30 минут

12 · Заявка

Расскажите, что болит

Три поля — остальное выясняю на 30-минутном звонке. Отвечу в течение дня и предложу время.

Размер команды, число сервисов и бюджет обсудим на звонке. Форму этим не перегружаю.

Не любите формы — пишите напрямую: Telegram @graywrk · graywrk@gmail.com.

Бесплатная диагностика →