Bygde selskapets egen infrastruktur som 19 Ansible‑playbooks og 34 roller på 12 065 linjer YAML, som konvergerer en vert i drift mot en deklarert tilstand der hver play er idempotent.

Situasjon. Engineer ApS driver sitt eget driftsmiljø — en tilstedeværelse på nettet, en git‑forge, en database, sikkerhetskopier, e‑posttransport og DNS — og det fantes ingen å overlate driften til. Et selskap med én person har de samme feilmodusene som et stort selskap og ingenting av redundansen, noe som gjør det vanlige svaret, en person som husker hvordan verten ble satt opp, til det minst tilgjengelige alternativet som finnes.

Oppgave. Hele driftsmiljøet måtte beskrives i et repo i stedet for i et hode, og beskrives i en form som konvergerer en ekte vert i stedet for å dokumentere den.

Handling. Ut av dette vokste det frem 19 playbooks og 34 roller fordelt på 12 065 linjer YAML. Formen betyr mer enn størrelsen. Sammensetning er data i stedet for flagg: en vert ligger i en nivågruppe der variablene deklarerer hvilke roller den kjører, slik at klargjøring uten argumenter konvergerer hver vert til sin deklarerte tilstand. Idempotens er en kontrakt og ikke et ønske — en konvergert vert rapporterer null endringer, og en play som ikke kan si det, er ikke ferdig. Fire kommandonavnerom holder løftene fra hverandre: en kvalitetsport som ikke berører noen vert, rapporter som leser én og aldri endrer den, klargjøring som endrer en vert slik at den samsvarer med repoet, og verifisering som endrer en vert med vilje og returnerer en dom.

Resultat. Driftsmiljøet kan gjenskapes fra repoet, og de delene av det som bare var sanne fordi noen husket dem, er nå påstander som får en kjøring til å feile. Kostnaden er reell: hver endring tar lengre tid å gjøre enn det ville tatt å redigere en fil på serveren, og en konvergering som bare blir halvveis gjennomført, er verre enn en som nekter, og det er derfor en preflight‑play senere ble lagt inn foran den. Den avveiningen ble gjort bevisst, og den har holdt.