Побудувала власну інфраструктуру компанії як 19 плейбуків Ansible і 34 ролі на 12 065 рядках YAML, що зводять живий хост до оголошеного стану, де кожен play ідемпотентний.

Ситуація. Engineer ApS керує власним господарством — вебприсутність, git‑форджа, база даних, резервні копії, поштовий транспорт і DNS, — і не було нікого, кому передати експлуатацію. Компанія з однієї людини має ті самі режими відмови, що й велика, і жодного резерву, через що звична відповідь — людина, яка пам’ятає, як налаштовано хост, — є найменш доступним варіантом.

Завдання. Усе господарство мало бути описане в репозиторії, а не в голові, і описане у формі, що зводить реальний хост до заданого стану, а не документує його.

Дія. З цього виросли 19 плейбуків і 34 ролі на 12 065 рядках YAML. Форма важить більше за розмір. Композиція є даними, а не прапорцями: хост належить до групи рівня, чиї змінні оголошують, які ролі він виконує, тож розгортання без жодних аргументів зводить кожен хост до оголошеного стану. Ідемпотентність є контрактом, а не прагненням — зведений хост звітує про нуль змін, і п’єса, яка не може цього сказати, не завершена. Чотири простори імен команд тримають обіцянки нарізно: перевірка, що не торкається жодного хоста, звіти, які читають хост і ніколи його не змінюють, розгортання, що змінює хост до відповідності репозиторію, і верифікація, що змінює хост навмисно й повертає вердикт.

Результат. Господарство відтворюється з репозиторію, а ті його частини, які були істинними лише тому, що хтось їх пам’ятав, тепер є твердженнями, що валять прогін. Ціна реальна: кожна зміна повільніша, ніж редагування файлу на сервері, а зведення, застосоване наполовину, гірше за те, що відмовляється, — саме тому попереду згодом додано попередню перевірочну п’єсу. Цей обмін зроблено свідомо, і він себе виправдав.