Har adskilt alle driftshemmeligheder pr. vært

Situation. Platformen var bygget til én vært og skulle snart have to. Flere driftshemmeligheder var skrevet som enkeltværdier ud fra den antagelse: ét sikkerhedskopilager, én adgangssætning, én alarmswitch. At udvide dem til en ekstra vært ved at dele dem er den letteste vej, og den er forkert på to forskellige måder, som begge fejler i al stilhed.

Opgave. Hver hemmelighed skulle gøres til en tabel med værten som nøgle, og begrundelsen skulle skrives ned, for den delte udgave ser korrekt ud og koster intet indtil den dag, det betyder noget.

Handling. To argumenter afgjorde sagen, og begge er noteret ved siden af konfigurationen. En dead man’s switch, som to værter deler, alarmerer mindre end to switches, ikke mere: så længe bare den ene vært stadig pinger, forbliver tjekket grønt, mens den anden er død, så at føje en vært til en delt switch reducerer ligefrem dækningen af den, der allerede var der. Og en streng, der angiver et sikkerhedskopilager, er kun en placering — adgangssætningen er hele krypteringen, så to værter, der deler en adgangssætning, er ikke to lagre med en fælles hemmelighed, men ét lager med to mapper. Hver værdi blev gjort til en tabel med værtsnavnet fra inventaret som nøgle og slås op pr. vært af en fælles opgavefil, som både den rigtige kørsel og preflight kører. Derefter blev den eksisterende vært ført op i alle fire tabeller med sit lager og begge switches tomme, og det er den sandfærdige tilstand og holder de to åbne initiativer ærlige om, at det, de mangler, er operatørens halvdel af arbejdet og ikke koden.

Resultat. Hemmelighederne er pr. vært i kraft af selve opbygningen, og de to fejltilstande, der ville være fulgt af at dele dem, er skrevet ned der, hvor den næste person redigerer filen. De tomme poster er den del, der er værd at beholde: de siger, at koblingen findes, men værdien ikke gør, og det er et andet og mere nyttigt udsagn end en manglende nøgle.