Анонимизированный кейс · DevOps/SRE-аудит
Laravel-продукт на гибридном облаке:
аудит инфраструктуры
B2B SaaS на Laravel, 5 серверов в Yandex Cloud и Hetzner, команда из 3 разработчиков без выделенного DevOps. Команда обратилась с запросом: «инфра работает, но каждый релиз — риск, хочется понять, где слабые места и за что браться в первую очередь».
Скачать PDF-версию кейса →01 · Контекст
Что за инфраструктура
- Продукт
- B2B SaaS на Laravel (PHP)
- Инфраструктура
- 5 серверов: 3 в Yandex Cloud, 2 в Hetzner
- База данных
- MySQL (на отдельной ВМ в Yandex)
- Команда
- 3 разработчика, DevOps не выделен
- Окружения
- dev, prod (без staging)
- Git
- GitLab (self-hosted в Hetzner)
- Деплой
- ручной, по «инструкции» в голове у старшего разработчика
02 · Что нашёл аудит
10 находок по 6 направлениям
-
Критично 1. Нет бэкапов — нигде
База данных, код приложений, конфигурации — ничего не резервируется. Отказ диска на ВМ с MySQL или случайный
DROP TABLE= полная потеря данных продукта и клиентов. Восстановление невозможно в принципе.Риск: Катастрофический. Потеря бизнеса при одном отказе диска.
-
Критично 2. Нет мониторинга
Сбор метрик отсутствует. Дежурных нет, алертов нет. О том, что «сервису плохо», команда узнаёт от пользователей — через саппорт или отток.
Риск: Инциденты длятся часами и обнаруживаются снаружи. MTTR не измеряется, потому что нечего измерять.
-
Критично 3. Нет CI/CD при наличии GitLab
Деплой — ручной скрипт + SSH на сервера + шаги «по памяти» у одного человека. Отката нет: откат = «поднять старую версию и молиться». Воспроизводимости нет — сборка работает у одного и падает у других.
Риск: Каждый релиз — лотерея. Уход старшего разработчика = остановка релизов.
-
Важно 4. Гибрид без единой сетевой модели
Трафик между Yandex и Hetzner идёт через интернет, без VPN. Latency и стоимость egress не контролируются. Граница доверия не определена — где прод, где dev, кто может ходить между ними.
Риск: Перерасход на egress, рост latency, неявная attack surface.
-
Важно 5. dev/prod без паритета
dev — одна ВМ «всё-в-одном», prod — пять. Версии PHP, расширения, настройки различаются. Баг, который не воспроизводится в dev, ловится только в проде.
Риск: Ложное чувство безопасности от «у нас есть dev».
-
Важно 6. Секреты в
.env, распространяются вручнуюКлючи от платёжек, SMTP, сторонних API лежат в
.envи копируются по чату/почте. Ротации нет. Кто имеет доступ к секретам прод-окружения — неизвестно, список не ведётся.Риск: Утечка при уходе сотрудника или компрометации чата.
-
Важно 7. Знания об инфре — у одного человека
Как что связано, как деплоить, где что лежит, как чинить инцидент — знает только старший разработчик. Документации нет, runbook'ов нет.
Риск: Bus factor = 1. Болезнь или уход — остановка.
-
Приятно иметь 8–10. Окружения, зависимости, тесты бэкапов
Нет staging-окружения (релизы идут напрямую в прод). Версии PHP и Composer-зависимости не обновляются, security-патчи игнорируются,
composer auditне запущен. Бэкап-тестов нет — потому что нет бэкапов.
03 · Топ-5 рекомендаций
С трудозатратами и ожидаемым эффектом
| № | Проблема | Рекомендация | Трудозатраты | Ожидаемый эффект |
|---|---|---|---|---|
| 1 | Нет бэкапов | Автоматические бэкапы БД (ежечасно + ежедневный full), выгрузка в S3 в другой регион. Регламент restore-test раз в месяц. | 2–3 инж.-дня | Устраняет риск полной потери данных |
| 2 | Нет мониторинга | Базовый стек: VictoriaMetrics/Prometheus + Grafana + 5–7 критичных алертов (БД, диск, HTTP 5xx, latency p99). | 4–6 инж.-дней | Инциденты видны за минуты, а не часы |
| 3 | Нет CI/CD | Пайплайн в GitLab CI: линт → тесты → сборка артефакта → деплой по кнопке. Версионированные артефакты, откат одним кликом. | 5–8 инж.-дней | Релизы предсказуемы, откат = секунды |
| 4 | Секреты в .env | Перенос в GitLab CI/CD Variables или Vault. Отзыв доступа при offboarding. | 2 инж.-дня | Сокращение attack surface, аудит доступа |
| 5 | Знания у одного | Документация инфры + 3 ключевых runbook'а (релиз, откат, инцидент). Схема зависимостей. | 3 инж.-дня | bus factor растёт, онбординг быстрее |
04 · План на 30 / 60 / 90 дней
Что делать и в каком порядке
Первые 30 дней — критичное и быстрые победы
Бэкапы + восстановление (#1), базовый мониторинг с алертами (#2), перенос секретов (#4). После этого инфра перестаёт быть «чёрным ящиком», который может исчезнуть.
30–60 дней — важное
CI/CD (#3): повторяемые релизы, кнопочный откат. Документация и runbook'и (#5): знания выходят из головы в репозиторий.
60–90 дней — фундамент
Staging-окружение (#8), приведение dev к паритету с prod (#5), регулярные restore-тесты бэкапов, обновление зависимостей (#9).
Честно о границах
Это анонимизированный пример того, что аудит находит и рекомендует на типичном профиле (Laravel, гибрид, команда без DevOps). Здесь нет пост-имплементационных метрик вида «латентность упала на X%» — их неоткуда взять, пока рекомендации не внедрены. Эффекты в таблице — ожидаемые, основанные на практике работы с такими инфраструктурами, а не обещание конкретных цифр.
Если вам обещают «сократим косты на 40%» до того, как увидели ваш счёт за облако — это маркетинг, не аудит.
Похоже на вашу ситуацию?
Узнайте, где риски в вашей инфраструктуре. Аудит за 10 дней — карта, чеклист надёжности и ранжированный план действий.
80–150 тыс. ₽ · 10 рабочих дней · read-only · NDA