Patchning utan produktionsstopp

På ett kontor är patchning en schemafråga. Man väljer en natt, servrarna startar om och på morgonen är allt som vanligt. I en fabrik fungerar det inte så. Servrarna i fabrikens datacenter kör system som styr, övervakar och spårar produktionen, och en omstart vid fel tillfälle kan betyda en linje som står still, en batch som måste kasseras eller en leveranstid som inte hålls.

Samtidigt är det inget alternativ att låta bli. Opatchade hypervisorer, gammal firmware och backupprogramvara som ligger flera versioner efter är precis det som gör en OT-miljö sårbar. Uppgiften är alltså inte att välja mellan säkerhet och produktion, utan att planera så att man får båda.

Bestäm vilka versioner ni ska till – och vilka ni hoppar över

Det första beslutet är inte när man patchar, utan vad. I en IT-miljö med internetåtkomst är det rimligt att ligga nära senaste version. I ett hårt segmenterat fabriksnät ser kalkylen annorlunda ut: varje uppgradering är ett riskfönster, och nätets isolering ger ett skydd som gör att man inte alltid måste vara först.

Jag arbetar därför med en uttalad versionsstrategi för hypervisor, vCenter och backup. Den svarar på tre frågor:

• Behöver vi det som den nya versionen ger? En säkerhetsrättning som rör en exponerad komponent väger tungt. En ny funktion vi inte använder väger lätt.
• Hänger versionerna ihop? Hypervisor, vCenter, backupprogram och serverfirmware har kompatibilitetsmatriser. Att uppgradera en del utan att kontrollera de andra är det vanligaste sättet att skapa ett nytt problem medan man löser ett gammalt.
• Vem mer påverkas? Om backupen replikeras till ett annat datacenter som någon annan äger, måste versionerna ligga i linje med deras plan också.

Färre, väl valda uppgraderingar är bättre än många små. Varje hoppad version är ett riskfönster som aldrig öppnades.

Servicefönstret ägs av produktionen

I fabriken är det produktionen som bestämmer när något får stängas av. Det låter självklart, men det får konsekvenser för hela planeringen:

• Fönstren ligger ofta på helger eller vid planerade underhållsstopp, och de flyttas när orderläget ändras. Planen måste tåla att datumet byts med kort varsel.
• Det räcker inte att fråga IT-ansvarig på siten. Man behöver någon som förstår vilka system som faktiskt påverkas när en viss server startar om, och vad det betyder på golvet.
• När flera fabriker i olika länder ska uppgraderas blir tidszoner, lokala helgdagar och språk en del av projektet, inte en fotnot.

Den svåraste delen är sällan tekniken. Det är samordningen: med produktionen, med de som äger nätet utanför fabriken och med kollegorna som gör jobbet på plats eller på distans.

Låt klustret bära lasten

Den viktigaste tekniska förutsättningen för patchning utan stopp är att arkitekturen tillåter det. Ett virtualiseringskluster med tillräcklig marginal kan ta en värd i taget ur drift, flytta de virtuella maskinerna med vMotion, patcha och sätta tillbaka värden, utan att applikationerna märker något.

Det kräver att man har räknat på det i förväg. Klarar klustret att en nod är borta medan resten bär full last? Finns det lagringspolicyer som kräver ett visst antal noder för att data ska vara skyddat? I ett litet kluster med tre noder är marginalen tunn, och det är bättre att veta det före servicefönstret än under det.

Det som inte kan flyttas, till exempel enskilda fysiska servrar eller system med licensbindning till hårdvara, behöver en egen plan och oftast ett riktigt stopp. Hitta dem tidigt.

Firmware är också patchning

Det är lätt att fokusera på operativsystem och hypervisor och glömma serverns egen mjukvara: BIOS, nätverkskort, lagringskontroller och fjärrhanteringskort. Tillverkarna ger ut samlade paket med testade kombinationer, och det är dem man ska använda, inte enskilda uppdateringar som någon har hittat.

I isolerade nät utan internetåtkomst kommer paketen inte in av sig själva. De måste distribueras på ett kontrollerat sätt, med kontrollsumma och spårbarhet, genom samma säkra åtkomstväg som allt annat. Det tar tid att förbereda, men det är just den isoleringen som gör miljön värd att skydda.

En återgångsplan som går att genomföra

"Vi rullar tillbaka om det går fel" är ingen plan. En plan svarar på:

• Vad är kontrollpunkten där vi bestämmer oss? Till exempel: om värden inte är tillbaka i klustret inom en viss tid.
• Hur återställer vi konkret: snapshot, backup, en ominstallation med sparad konfiguration?
• Har backupen av vCenter och kritiska system tagits före fönstret, och är den kontrollerad?
• Vem fattar beslutet, och vem informerar produktionen?

Skriv ner det, för nästa gång

Varje uppgradering lär en något. Vilken värd tog längst tid, vilket steg i instruktionen var oklart, vilken kontroll saknades? Om det inte skrivs ner gör nästa person samma misstag. Jag skriver en kort genomgång efter varje kampanj och uppdaterar instruktionen, så att nästa omgång blir lite lugnare än den förra.