Библиотека девопса | DevOps, SRE, Sysadmin

🧵 Чеклист перед выкладкой инфраструктурного кода в прод

Инфраструктура как код — мощная штука. Но даже один криво закоммиченный main.tf может повалить пол-продакшена. Вот мини-чеклист, который стоит прогонять перед мержем в main.


✅ 1. План применён?
terraform plan или pulumi preview должен быть свежим и понятным. Никаких сюрпризов в духе «удаляется продовая БД».

✅ 2. Есть backend?
Убедись, что состояние хранится не локально. Используй S3, GCS или аналог — иначе в один день ты потеряешь всё.

✅ 3. -target не попал в CI/CD
Временно использовать -target ок, но не коммить это в pipeline. Это костыль, а не стратегия.

✅ 4. Защищён ли state?
Шифрование включено? Доступ только у нужных людей? terraform state show — часто недооценённый источник чувствительных данных.

✅ 5. Модули не обновились «магически»?
Проверь, что версии всех модулей и провайдеров зафиксированы. Плавающие версии — путь к хаосу.

✅ 6. Документация и комментарии есть?
Ты можешь помнить, зачем это поле у S3, но через месяц ты же сам себе не поверишь. Пиши сразу.

✅ 7. Прогонен tflint / checkov / terraform validate?
Линтеры и валидация — это как spellcheck, но для продакшена. Лишними не будут.

✅ 8. Обратная совместимость учтена?
Изменения в ресурсах типа ALB, IAM policy или security group могут незаметно порушить весь трафик.

✅ 9. Всё в Git?
Terraform code без Git — это как сервер без мониторинга. Безответственно.

✅ 10. Apply сначала в staging!
Если у тебя нет stage-среды — ты и есть stage. Надеюсь, у тебя хорошая страховка.


🛠 Ты можешь автоматизировать почти всё из этого списка. Но думать всё равно придётся. Хотя бы пока.


Подпишись 👉@devopslib

👍6

www.tgoop.com/devopslib/41

2.22K viewsApr 5 at 09:08

🧵 Чеклист перед выкладкой инфраструктурного кода в прод

Инфраструктура как код — мощная штука. Но даже один криво закоммиченный main.tf может повалить пол-продакшена. Вот мини-чеклист, который стоит прогонять перед мержем в main.


✅ 1. План применён?
terraform plan или pulumi preview должен быть свежим и понятным. Никаких сюрпризов в духе «удаляется продовая БД».

✅ 2. Есть backend?
Убедись, что состояние хранится не локально. Используй S3, GCS или аналог — иначе в один день ты потеряешь всё.

✅ 3. -target не попал в CI/CD
Временно использовать -target ок, но не коммить это в pipeline. Это костыль, а не стратегия.

✅ 4. Защищён ли state?
Шифрование включено? Доступ только у нужных людей? terraform state show — часто недооценённый источник чувствительных данных.

✅ 5. Модули не обновились «магически»?
Проверь, что версии всех модулей и провайдеров зафиксированы. Плавающие версии — путь к хаосу.

✅ 6. Документация и комментарии есть?
Ты можешь помнить, зачем это поле у S3, но через месяц ты же сам себе не поверишь. Пиши сразу.

✅ 7. Прогонен tflint / checkov / terraform validate?
Линтеры и валидация — это как spellcheck, но для продакшена. Лишними не будут.

✅ 8. Обратная совместимость учтена?
Изменения в ресурсах типа ALB, IAM policy или security group могут незаметно порушить весь трафик.

✅ 9. Всё в Git?
Terraform code без Git — это как сервер без мониторинга. Безответственно.

✅ 10. Apply сначала в staging!
Если у тебя нет stage-среды — ты и есть stage. Надеюсь, у тебя хорошая страховка.


🛠 Ты можешь автоматизировать почти всё из этого списка. Но думать всё равно придётся. Хотя бы пока.


Подпишись 👉@devopslib

BY Библиотека девопса | DevOps, SRE, Sysadmin