Servisní okna a zmrazení: kdy se smí sahat do produkce

Je čtvrtek odpoledne a manažer změn dostane k posouzení změnu na databázovém clusteru. Termín vypadá rozumně. Jenže nikdo si nevšimne, že na stejnou noc je naplánovaná aktualizace storage pod tímtéž clusterem, že zasažená aplikace má servisní okno jen v neděli ráno a že na konci měsíce běží uzávěrka, během níž se do produkce sahat nemá. Všechno to někde zapsané je. Jen ne na jednom místě.

Výsledek znají všichni, kdo dělají provoz: ranní telefonát, nervózní vlastník služby a tým, který místo plánované práce vysvětluje, proč se dvě změny potkaly. Nejde přitom o lajdáctví. Jde o to, že pravidla, kdy se smí do produkce sahat, nejsou pro lidi, kteří změny plánují, dost viditelná.

Proč tabulky a dobrá vůle nestačí

V praxi často vidíme, že servisní okna jsou uvedená ve smlouvách nebo v dokumentaci služby, zmrazení oznamuje e-mail a kolize hlídá zkušený kolega, který „ví, co se kde děje“. Takový model funguje, dokud je změn málo a ten kolega není na dovolené.

Slabá místa jsou předvídatelná:

• servisní okno patří službě, ale změna se plánuje na server, takže vazbu musí člověk dohledat sám,
• zmrazení se oznámí, ale nikde se nevynucuje,
• kolize dvou změn na sdílené infrastruktuře se odhalí až při pohledu do kalendáře, pokud vůbec,
• velké změny na mnoha položkách se provádějí naráz, protože postupné provedení je těžké naplánovat.

Jak k tomu přistupovat

Základní myšlenka je jednoduchá: pravidla mají být data, ne znalost. Servisní okno patří ke službě a musí být dohledatelné z každé položky, na které služba stojí. Zmrazení je časové období, ve kterém systém termín změny prostě nepřijme. Kolize se nemají hledat očima, ale vyhodnocovat při plánování.

Stejně důležité je přiznat, že ne každá situace se vejde do přísných pravidel. Při zavádění nového procesu nebo v organizaci, kde servisní okna zatím nikdo nedefinoval, je lepší mít vědomou a dohledatelnou výjimku než pravidla, která všichni obcházejí. Výjimka ale musí mít jméno, důvod a konec, jinak se z ní nenápadně stane nový standard.

Jak to řeší Eywo Stratum

V Eywo Stratum je změna navázaná na položky CMDB a přes mapu závislostí i na služby, které na nich stojí. Ještě před odesláním změny ke schválení systém vypočítá dopad: které služby a aplikace budou mimo provoz nebo degradované.

Na tento výpočet navazují pravidla pro termín:

• servisní okna – termín změny lze zvolit jen v oknech zasažených služeb,
• změnová zmrazení – v období zmrazení se změna naplánovat nedá,
• kolize – systém upozorní na jiné změny, které se s plánovanou změnou časově a věcně potkávají,
• postupné provádění (rolling) – změnu lze provést postupně po jednotlivých položkách, takže služba s redundancí nemusí jít celá mimo provoz.

Všechny změny jsou vidět v kalendáři změn, kde manažer změn i vlastníci služeb vidí, co se kdy chystá. Odstávku schvaluje vlastník zasažené služby, podle change modelu také manažer změn nebo CAB. Standardní předschválené změny projdou rychle, normální a nouzové mají vlastní kroky a lead time.

Pro období zavádění nabízí Eywo Stratum model „změna bez servisního okna“. Organizace tak může začít evidovat a schvalovat změny dřív, než má servisní okna všech služeb nadefinovaná. Výjimka je viditelná a dohledatelná, a jakmile okna existují, přejde se na standardní modely.

Klid místo improvizace

Servisní okna a zmrazení nejsou byrokracie. Jsou to dohody mezi provozem a těmi, kdo službu používají. Když je hlídá systém, manažer změn se může věnovat obsahu změny místo hledání v kalendářích a technici jdou do noční práce s vědomím, že nikdo jiný jim pod rukama nesahá na stejnou infrastrukturu. A všichni mohou jít domů s klidnější hlavou.

Servisní okna, zmrazení, kontrola kolizí a kalendář změn jsou součástí edice Standard.