Інфраструктуру як код зазвичай продають красивими словами: повторюваність, версійність, ревʼю. Усе правда. Але справжню цінність IaC ти розумієш не в спокійний день, а тоді, коли щось велике падає й треба відновитись швидко, без паніки й без здогадок.
У мене був випадок, коли ми втратили цілий регіон у хмарі. Не окрему машину — весь регіон став недоступним. Роками ми знали б це як катастрофу на кілька діб. Але вся інфраструктура жила в Terraform: мережі, бази, черги, ролі, політики доступу. Ми взяли той самий код, змінили один параметр регіону й почали піднімати все з нуля в іншому місці. Це не було миттєво й не було зовсім без болю, але це було відтворювано.
Різниця ось у чому. Коли інфраструктура зібрана руками через консоль, відновлення — це археологія. Хтось намагається згадати, які саме security groups були відкриті, який розмір диска стояв, чому саме ця версія бази. Кожна така згадка — це шанс на нову помилку під час і без того стресового відновлення. Код цю археологію прибирає. Стан описаний явно, його видно в diff, його можна перечитати спокійно.
Але IaC дає стійкість лише тоді, коли ти йому довіряєш. Якщо половину змін роблять руками повз Terraform, а половину — кодом, ти отримуєш найгірше з двох світів: і drift, і фальшиве відчуття, що все під контролем. Тому в мене жорстке правило: жодних ручних змін у продакшн-інфраструктурі. Треба щось поправити — правиться в коді, проходить plan, проходить ревʼю, застосовується. Навіть якщо це «на пʼять хвилин».
Поганий день настане обовʼязково — регіон, провайдер, помилковий delete, атака. Питання лише в тому, чим ти зустрінеш його: панічним відновленням з памʼяті чи спокійним terraform apply у новому місці. Я обираю друге. Стійкість інфраструктури — це не те, що вона ніколи не падає. Це те, як швидко й передбачувано вона встає назад.
– Sergey Shinder
