Varför vi startar om servrar

En fråga som dyker upp ganska regelbundet är huruvida servrar bör startas om rutinmässigt, till exempel en gång i veckan, eller om de bör tillåtas köra så länge som möjligt för att uppnå maximal “uptid”. För mig är svaret enkelt – med sällsynta undantag är regelbundna omstarter det lämpligaste valet för servrar.

Som med alla regler finns det fall då den inte gäller. Till exempel har vissa företag som kör kritiska system inget utrymme för driftstopp och måste vara tillgängliga dygnet runt. Uppenbarligen kan system av det här slaget inte bara startas om på ett rutinmässigt sätt. Om ett system dock är så kritiskt att det aldrig får gå ner, bör denna situation utlösa en varningsflagga om att systemet utgör en felpunkt, och man bör kanske börja överväga hur man ska hantera driftstopp, vare sig det är planerat eller oplanerat.

Ett annat undantag är att vissa AIX-system behöver betydande uptid, mer än några veckor, för att uppnå maximal effektivitet eftersom systemet är självjusterande och behöver tid för att samla in användningsinformation och anpassa sig därefter. Detta tenderar att vara begränsat till stora, sällan föränderliga databasservrar och liknande användningsscenarier som är mindre vanliga än andra plattformar.

Inom IT dyrkar vi ofta begreppet “uptid” – hur länge ett system kan köra utan att behöva startas om. Men “uptid” är inte ett begrepp som tillför värde för verksamheten, och IT måste hela tiden ha verksamhetens behov i åtanke snarare än att fokusera på konstgjorda mätvärden. Verksamheten bryr sig inte om hur länge en server har lyckats förbli online utan att startas om – den bryr sig bara om att servern är tillgänglig och redo när den behövs för affärsbearbetning. Detta är väldigt olika begrepp.

För i stort sett alla normala verksamhetsservrar finns det ett fönster när servern behöver vara tillgänglig för affärsändamål och ett fönster när den inte behövs. Dessa fönster kan vara dagliga, veckovisa eller månadsvisa, men det är en sällsynt server som faktiskt används dygnet runt utan undantag.

Jag hör ofta folk säga att de inte längre behöver starta om eftersom de kör operativsystem X i stället för Y, men detta är helt enkelt inte sant. Det finns två huvudsakliga skäl att starta om regelbundet: att verifiera serverns förmåga att starta om framgångsrikt och att tillämpa patchar som inte kan tillämpas utan omstart.

Att tillämpa patchar är anledningen till att de flesta företag startar om. Nästan alla operativsystem får regelbundna uppdateringar som kräver omstart för att träda i kraft. Eftersom de flesta patchar släpps av säkerhets- och stabilitetsskäl, särskilt de som kräver en omstart, är vikten av att tillämpa dem ganska hög. Att göra en server onödigt sårbar bara för att upprätthålla uptid är inte klokt.

Att testa en servers kapacitet att starta om framgångsrikt är det som ofta förbises. De flesta servrar får ändringar tillämpade på sig regelbundet. Ändringar kan vara patchar, nya applikationer, konfigurationsändringar, uppdateringar eller liknande. Varje ändring medför risk. Bara för att en server är frisk omedelbart efter att en ändring tillämpats betyder det inte att servern eller applikationerna som körs på den kommer att starta som förväntat vid omstart.

Om servern aldrig startas om vet vi aldrig om den kan startas om framgångsrikt. Med tiden kommer antalet ändringar som tillämpats sedan den senaste omstarten att öka. Detta är mycket farligt. Det vi fruktar är att ett stort antal ändringar har gjorts, möjligen många av dem odokumenterade, och att en omstart sedan misslyckas. Vid den tidpunkten kan det vara en oöverstiglig process att identifiera vilken ändring som får systemet att fallera. Ingen enskild ändring att rulla tillbaka, ingen känd väg till återställning. Det är då paniken slår till. En maskin som aldrig startas om avsiktligt är förstås mer benägen att starta om oavsiktligt – vilket innebär att chansen för en misslyckad omstart är både mer sannolik att inträffa och mer sannolik att inträffa under aktiv användning.

Även om regelbundna omstarter inte är avsedda att minska frekvensen av misslyckade omstarter, utan faktiskt ökar förekomsten av fel, är syftet att göra dessa fel lätthanterliga ur ett “känd ändring”-perspektiv och, ännu viktigare, att kontrollera när dessa omstarter sker för att säkerställa att de inträffar vid en tidpunkt då servern är utsedd som tillgänglig för underhåll och är avsedd att belastas så att problem upptäcks vid en tidpunkt då de kan åtgärdas utan affärspåverkan.

Jag har hört många systemadministratörer säga att de undviker helgomstarter eftersom de inte vill bli fast med att arbeta på söndagar på grund av att servrar inte kommer tillbaka efter omstart. Jag har själv blivit personsökt många söndagsmorgnar på grund av en misslyckad omstart, men varje gång jag får det samtalet känner jag en känsla av lättnad. Jag vet att vi just fångade ett problem vid en tidpunkt då verksamheten inte påverkas ekonomiskt. Hade den servern inte startats om under icke-kontorstid, kanske den inte hade upptäckts vara “ostartbar” förrän den hade fallerat under aktiv arbetstid och orsakat en intäktsförlust.

Tack vare regelbundna helgomstarter kan vi fånga annalkande katastrofer på ett säkert sätt och, tack vare vetskapen om att vi bara har en veckas ändringar att undersöka, kan vi rutinmässigt åtgärda problemen i regel med liten ansträngning och stor tillförsikt om att vi förstår vilka ändringar som gjorts före felet.

Regelbundna omstarter handlar om att skydda verksamheten från avbrott och driftstopp som kan åtgärdas genom mycket enkla och tillförlitliga processer.