Приходиш у новий проект — і перше, що бачиш: Jenkins на застарілій віртуалці, Ansible-плейбуки без ідемпотентності, terraform.tfstate лежить локально в одного інженера, і ніхто не знає, що станеться, якщо запустити terraform apply прямо зараз. Інфраструктура працює, але як — незрозуміло. Документації немає, моніторинг є, але алерти тонуть у шумі. Така ситуація знайома кожному, хто хоч раз влився в успадкований проект.
Аудит — це не про те, щоб видати звіт з галочками. Це про те, щоб зрозуміти реальний стан: що тримається на чесному слові, де одна невдала зміна покладе прод, і що можна полагодити за тиждень. Наша команда провела вже понад 100 аудитів і знає, де найчастіше ховаються проблеми.
Які проблеми ми вирішуємо?
Найболючіша зона — управління станом інфраструктури. Якщо Terraform State зберігається локально або в S3-бакеті без state locking через DynamoDB, будь-які паралельні запуски terraform apply гарантовано зламають стейт. Remote backend з блокуванням у 5 разів надійніший за локальне зберігання — це підтверджено практикою. Бачили таке на проекті з 40+ модулями: два інженери запустили apply одночасно, стейт роз'їхався, і відновлення зайняло дві доби.
Другий шар — pipeline security. Перевіряємо, де зберігаються секрети: у змінних CI/CD у відкритому вигляді, захардкожені в .gitlab-ci.yml, чи все-таки інтегровані з HashiCorp Vault або AWS Secrets Manager. Hardcoded credentials у репозиторії — це не гіпотетичний ризик, це реальний інцидент, який трапляється регулярно.
Далі дивимось на observability: чи є у вас SLI/SLO, чи налаштований alertmanager з правильними routing rules, чи всі алерти летять в один канал і тонуть у шумі. Prometheus з 200+ алертами без групування та inhibit rules — це майже те саме, що відсутність моніторингу. Добре налаштований алертменеджер дозволяє знизити MTTR в середньому на 40%.
Типові проблеми, які ми знаходимо
- Відсутність тестів для Ansible-ролей (Molecule) — зміни вносяться наосліп.
- Helm charts без version pinning — непередбачувані оновлення.
- Відсутність PodDisruptionBudget для критичних сервісів — втрата доступності під час rollouts.
- Секрети в CI/CD змінних без шифрування.
- Немає процедури відновлення etcd для Kubernetes.
Чому важливо проводити аудит регулярно?
Інфраструктура змінюється: додаються нові сервіси, оновлюються версії, змінюються команди. Без регулярної перевірки накопичується технічний борг, який рано чи пізно призводить до інцидентів. За даними звіту Puppet State of DevOps, компанії, що проводять аудит інфраструктури раз на квартал, скорочують кількість інцидентів у 2 рази. Аудит раз на квартал дозволяє тримати руку на пульсі та запобігати збоям.
Що входить в аудит
Інфраструктура як код:
- стан Terraform modules, remote backend, workspace isolation
- Ansible inventory та структура ролей, наявність тестів (Molecule)
- Helm charts: values.yaml overrides, використання Secrets vs ConfigMaps
CI/CD пайплайни:
- покриття стадій: lint → test → build → scan → deploy
- час збірки та наявність кешування залежностей
- політики доступу до раннерів, ізоляція середовищ
Kubernetes-кластери (якщо є):
- RBAC-конфігурація, network policies
- resource requests/limits на всіх workloads
- наявність PodDisruptionBudget для критичних сервісів
- стан etcd backup та процедура відновлення
Observability:
- покриття метриками, логами, трейсами
- SLO definitions та error budget tracking
- процедура on-call та час MTTR з останніх інцидентів
Безпека:
- сканування образів (Trivy, Grype) у pipeline
- політики Falco або OPA/Gatekeeper у кластері
- ротація credentials та audit log
Як проходить робота
Починаємо з kick-off дзвінка: з'ясовуємо, що болить прямо зараз, які інциденти були за останні три місяці, де інженери бояться щось чіпати. Це дає фокус — не переглядати все підряд, а почати з зон ризику.
- Kick-off: узгоджуємо обсяг і доступи.
- Збір даних: read-only доступ до репозиторіїв, CI/CD, хмари, кластеру.
- Аналіз: виявлення проблем, пріоритизація.
- Підготовка звіту: конкретні рекомендації з прикладами.
- Фінал: презентація результатів, відповіді на запитання.
Аналіз займає 3-5 днів залежно від масштабу. На виході — не PDF із загальними рекомендаціями, а конкретний список проблем із пріоритетами та прикладами фіксу. Для кожної критичної проблеми — зрозумілий шлях до вирішення.
Як змінюється зрілість після аудиту
| Область | До аудиту | Після аудиту |
|---|---|---|
| Управління стейтом | Локальний файл, немає блокувань | Remote backend з state locking |
| Безпека секретів | Hardcode в репозиторії | Інтеграція з Vault/Secrets Manager |
| Моніторинг | 200+ алертів в один канал | SLO-based alerting з роутингом |
| CI/CD | Ручний деплой | GitOps з автоматичним розгортанням |
Що отримуєте в підсумку
Документ з розбивкою за пріоритетами: що треба виправити негайно (security issues, ризик втрати даних), що — в найближчий спринт, що — в рамках технічного боргу. Для кожного пункту — конкретний опис проблеми, її наслідки та рекомендоване рішення.
Окремо — оцінка зрілості за ключовими практиками: IaC, CI/CD, observability, security, incident management. Це дає орієнтир для подальшої DevOps-трансформації.
Як аудит впливає на вартість володіння?
Після впровадження рекомендацій середня економія на хмарних ресурсах становить до 30% за рахунок оптимізації requests/limits, вибору spot instances та видалення невикористовуваних ресурсів. Додатково знижуються операційні витрати за рахунок автоматизації рутинних операцій.
Коли варто замовити аудит?
Якщо ви помічаєте, що розгортання займає більше години, інженери бояться міняти конфіги, а моніторинг видає 100+ алертів на день — пора. Зв'яжіться з нами, щоб записатися на аудит. Отримайте консультацію — ми оперативно оцінимо вашу інфраструктуру.
| Масштаб проекту | Орієнтовні терміни |
|---|---|
| Стартап, 1-3 сервіси, один кластер | 3 дні |
| Середня компанія, 5-15 сервісів | 4-5 днів |
| Enterprise, мікросервіси, multi-cloud | від 1 тижня |
Remote backend: чому він критичний?
Remote backend з підтримкою state locking (наприклад, S3 + DynamoDB) гарантує, що тільки один запуск terraform apply може працювати зі станом у кожен момент часу. Це виключає конфлікти та втрату даних при паралельній роботі команди. Саме таку практику ми впроваджуємо в першу чергу.
Як перевірити безпеку пайплайнів?
Починаємо з аудиту секретів: використовуємо truffleHog та git-secrets для пошуку захардкожених credentials. Потім впроваджуємо інтеграцію із зовнішнім secret store (Vault, AWS Secrets Manager) та налаштовуємо ротацію через pipeline. Результат — зниження ризику витоку даних у декілька разів.
