Regeln är enkel och obekväm: rör aldrig routern.
Ska något ändras uppdaterar man filen som beskriver hur routern ska se ut, och kör om. Filen är sanningen. Enheten är bara en kopia av den, och en kopia som avviker är per definition fel — oavsett hur bra skäl den som ändrade hade.
Det är samma princip jag skrev om i vintras för inventarium och övervakning. Det här handlar om vad som händer när man tar den hela vägen ut till nätverksutrustningen.
En fil per enhet, hela tillståndet
Varje router har en fil som beskriver allt: namn, gränssnitt, adresser, vilka tjänster som får svara, tunnlar till andra platser, routningsgrannar. Inte skillnaden mot förra veckan — hela det önskade tillståndet.
Den som lägger till en ny tunnel kompletterar filen. Playbooken är idempotent och lägger till det som saknas, utan att röra resten. Kör man den två gånger händer ingenting andra gången, vilket är hela poängen med att våga köra den ofta.
Vinsten märks först vid tredje enheten. Med fem routrar går det att hålla i huvudet. Med tjugo gör det inte det, och då är frågan ”vad är egentligen konfigurerat på den där?” antingen en filsökning på två sekunder eller en halvtimmes arkeologi i en levande enhet.
Men den verkligt intressanta frågan är inte tjugo. Den är tusen.
Varför modellen håller när antalet växer
De flesta sätt att hantera nätverkskonfiguration fungerar utmärkt upp till ungefär det antal enheter en person orkar bry sig om, och kollapsar strax därefter. Fyra egenskaper avgör var den gränsen går.
Tillståndet är per enhet, inte globalt. Det finns ingen central konfigurationsfil som växer med flottan och som alla ändringar måste samsas i. Att lägga till enhet nummer 1001 rör inte de tusen andra — inga sammanslagningskonflikter, inget koordinerat utrullningsfönster, ingen som väntar på någon annan. Antalet filer växer linjärt och komplexiteten per fil gör det inte.
Arbetet är en kö, inte en runda. Varje enhet blir ett jobb. Går det för långsamt startar man fler arbetare — kapaciteten är en siffra i en konfiguration, inte en omskrivning. Köerna kan dessutom hållas lokalt per plats, så att trafiken mot enheterna aldrig behöver gå över långsamma förbindelser bara för att styrningen står någon annanstans. Det är skillnaden mellan att skala ut och att skala upp, och bara det ena tar en till tusen.
Jämförelsen är läsande. Eftersom avdriftskontrollen bara läser kan den köras kontinuerligt över hela flottan utan risk. Det gör ”vad är tillståndet på våra tusen enheter?” till en fråga med ett svar i stället för ett projekt. Delvis genomförda körningar är dessutom ofarliga — nästa varv tar det som blev över.
Identiteten är per enhet. Det här är den som faktiskt sätter taket, och det är därför jag ägnar den ett eget avsnitt längre ner. Delade administratörsuppgifter fungerar i ett labb. På tusen enheter betyder en enda otakt att någon måste åka dit — och ”åka dit” är inte en strategi som skalar.
Att jämföra och att ändra är två olika verb
Med ett facit på plats blir en ny funktion möjlig: kör samma beskrivning i torrläge och rapportera skillnaderna i stället för att åtgärda dem. En avdriftskontroll.
Det låter som att man bara skickar med en flagga. I praktiken visade det sig att vissa steg inte går att torrköra alls. Att lägga upp ett certifikat på en enhet kräver att en temporär fil skapas — och i torrläge skapas ingen temporär fil, så steget kraschade och tog hela kontrollen med sig.
Rätt svar var inte att laga temporärfilen utan att inse att provisionering inte är en jämförelse. Att lägga dit ett certifikat är en handling, inte ett tillstånd att kontrollera. De stegen är nu uttryckligen undantagna från torrläget.
Skillnaden mellan ”det här ska se ut så här” och ”det här ska göras” är värd att göra explicit i vilken automatisering som helst. Blandar man ihop dem får man antingen avdrift man inte kan åtgärda eller åtgärder som utförs när man bara tänkte titta.
Pricken som inte kunde bli röd
Det bästa felet i hela projektet var ett gränssnittsfel.
En användare körde en avdriftskontroll. Överst i vyn tändes en varning: kritiskt. I listan under lyste enheten som orsakat varningen grön. Rimlig fråga: är det meningen?
Nej. De två indikatorerna mätte helt olika saker. Varningen överst räknade misslyckade och onåbara kontroller den senaste timmen — en äkta signal. Den gröna pricken bredvid enheten betydde bara att enheten hade en konfigurationsfil.
Alltså: pricken kunde aldrig bli röd. Den var grön från det ögonblick enheten lades in och skulle förbli grön om enheten brann upp.
Det är värre än att sakna indikator. En tom plats får en att leta vidare. En grön prick får en att sluta leta. En indikator som bara kan ha ett värde är inte neutral — den ljuger aktivt, i lugnande riktning.
Nu speglar färgen den senaste körningens utfall: rött för misslyckad eller onåbar, gult för verklig avdrift, grönt för överensstämmelse, grått för enheter utan beskrivning. Fyra tillstånd i stället för ett, och alla fyra går att nå.
Lösenordet som låste ut oss
Länge kopplade automatiken upp med samma administratörskonto som människor använder. Det fungerar tills någon byter lösenordet på enheten, eller tills automatiken byter det. Då står man utanför sin egen router.
Lösningen blev ett eget konto per enhet, som bara automatiken använder. Men det flyttar bara problemet ett steg: vad händer när det lösenordet hamnar i otakt?
Svaret är den del jag är mest nöjd med. Misslyckas inloggningen med automatikens konto faller den tillbaka på administratörskontot, sätter om sitt eget lösenord till det den förväntar sig, och nästa körning fungerar. Systemet reparerar sin egen åtkomst.
Det gör två saker möjliga som annars aldrig blir av. Övergången från delade uppgifter till egna kan göras utan en manuell runda på varje enhet. Och rotation blir ofarlig — det finns en väg tillbaka om något går snett mitt i.
Det är därför lösenord sällan roteras i verkligheten: inte för att någon tycker det är onödigt, utan för att alla vet vad som händer om det går fel klockan halv fem på en fredag. Bygg återhämtningen först, så blir rutinen möjlig.
På flottnivå är det här skillnaden mellan en policy och en powerpoint. Rotation sker inom ett tidsfönster i stället för samtidigt, så att tusen enheter inte byter uppgifter i samma sekund — och varje enhet som ändå hamnar snett reparerar sig själv vid nästa körning i stället för att bli ett ärende. En säkerhetsrutin som kräver mänsklig handpåläggning per enhet är i praktiken avstängd så fort enheterna blir fler än en eftermiddag.
Det som inte gick att bygga blint
Ursprungsplanen var certifikat eller nycklar i stället för lösenord. Det blev ett unikt lösenord per enhet ändå.
Skälet är värt att erkänna: syntaxen för certifikatbaserad inloggning på en av plattformarna var för invecklad för att skriva utan att sitta framför en riktig enhet och prova. Att bygga den blint hade gett kod som ser rimlig ut och låser ute mig.
Ett unikt lösenord per enhet är sämre än ett certifikat och oändligt mycket bättre än ett delat administratörskonto. Att ta åttio procent nu och resten när man kan verifiera på riktigt är ofta rätt beslut — särskilt när felet i alternativet är att förlora åtkomsten till infrastrukturen.
Vad labbet bevisar, och vad det inte gör
Ärlighet är på sin plats: min egen uppsättning är en handfull virtuella routrar plus en enhet från en annan tillverkare. Den bevisar att modellen fungerar och att den är korrekt — inte att den håller vid tusen.
Det som återstår att visa i den storleken är mätbart och odramatiskt: hur lång tid en fullständig jämförelse över hela flottan tar, hur djup kön blir vid en bred förändring, och hur mycket historik per enhet som är värd att spara. Alla tre är kapacitetsfrågor med siffror som svar.
Och så det som folk underskattar: vid tusen enheter är antalet sällan det svåra. Antalet dialekter är det. Varje tillverkare har sin egen syntax, sina egna egenheter kring vad som går att ändra utan omstart, och sina egna sätt att svara oväntat. Tusen enheter av samma modell är ett skript. Tusen enheter av tolv modeller är ett produktarbete — och det är där kostnaden faktiskt ligger.
Så vet du att det funkar
Ändra något direkt på en enhet, med flit. Kör sedan avdriftskontrollen. Syns ändringen som gul, fungerar facitet. Syns den inte kontrollerar du inte det du tror.
Kör om samma beskrivning två gånger. Andra körningen ska rapportera noll ändringar. Gör den inte det är beskrivningen inte idempotent, och då kan den inte köras ofta — och det som inte körs ofta körs aldrig.
Sabotera åtkomsten. Ändra automatikens lösenord på enheten och kör igen. Reparerar den sig själv är rotationen ofarlig. Gör den inte det kommer ingen att våga rotera, och funktionen är i praktiken avstängd.
Vad jag tar med mig
Ett facit är billigt att införa och dyrt att införa halvvägs. Halvvägs betyder att vissa ändringar går genom filen och andra direkt på enheten, och då blir filen ett dokument som beskriver hur det såg ut ungefär — vilket är värre än inget, eftersom man litar på det.
Och den bredare läxan, som gäller varje instrumentpanel jag byggt sedan dess: fråga alltid vilka värden en indikator kan anta. Kan den bara bli grön är den inte en indikator. Den är en dekoration som ser ut som ett besked.