Patchování bez měsíčního vyjednávání

Výrobci vydají opravy, bezpečnostní tým připomene termíny a provoz začne obepisovat vlastníky služeb. Kdy se smí restartovat aplikační servery? Může se patchovat v úterý v noci, nebo až o víkendu? A co ten jeden systém, u kterého minule restart trval déle, než se čekalo? Odpovědi chodí pozdě, některé vůbec. Část serverů se nakonec opraví, část se odloží „na příští měsíc“.

Takové kolo se opakuje každý měsíc a stojí spoustu energie na obou stranách. Správci jsou frustrovaní, že nemohou udělat práci, kterou udělat mají. Vlastníci služeb mají pocit, že je provoz neustále o něco žádá. A bezpečnost vidí, jak se odložené opravy hromadí.

Proč se stejná otázka klade pořád dokola

V praxi často vidíme, že patchování je řízené jako sled jednorázových událostí. Každý měsíc vznikne nový seznam serverů, nová sada žádostí o odstávku a nové schvalování. Přitom se většina odpovědí mezi měsíci nemění: služba má pořád stejné provozní hodiny, stejnou redundanci a stejného vlastníka.

Problém tedy není v tom, že by se lidé nechtěli dohodnout. Problém je, že se dohoda nikam nezapíše a příští měsíc se začíná znovu. K tomu se přidávají další slabiny:

• není jasné, kdo za službu rozhoduje, a žádost putuje mezi několika lidmi,
• servery se patchují po jednom podle seznamu, ne podle služeb a jejich závislostí,
• redundantní uzly se občas restartují současně, protože o redundanci ví jen pár lidí,
• kritická oprava čeká na stejný proces jako běžná měsíční aktualizace.

Jak k tomu přistupovat

Místo měsíčního vyjednávání je lepší uzavřít s vlastníkem služby jednu dohodu, která platí, dokud ji někdo vědomě nezmění. Dohoda řekne, kdy se smí patchovat, zda je patchování v tomto okně předem schválené a jak postupovat u redundantních uzlů. Měsíční plánování pak už není otázkou „smíme?“, ale jen „co je na řadě?“.

Druhým principem je oddělit běžný režim od naléhavého. Kritická zranitelnost nesmí čekat na příští stálé okno, ale ani nesmí obejít vlastníka služby úplně. I zrychlená cesta má být domluvená předem, aby se v naléhavé chvíli nevyjednávalo od nuly.

Jak to řeší Eywo Stratum

Eywo Stratum zavádí dohodu o patchování mezi provozem a vlastníkem služby. Obsahuje:

• stálé okno – pravidelný čas, kdy se služba smí patchovat,
• předschválené patchování v okně – změny v rámci dohody nemusí každý měsíc znovu procházet schvalováním odstávky,
• postupné patchování redundantních uzlů – uzly v redundantní skupině se patchují po jednom, aby služba zůstala dostupná,
• zrychlený režim pro kritické chyby – pro závažné zranitelnosti platí kratší cesta, na kterou se strany dohodly předem.

Návrh dohody o patchování přichází vlastníkovi služby do jedné fronty „Ke schválení“, stejně jako odstávky ve změnách nebo požadavky. Platí jedno pravidlo, kdo je vlastník; pokud služba vlastníka nemá, rozhoduje manažer změn. Zamítnutí je vždy se zdůvodněním, takže provoz ví, co upravit.

Na dohody navazuje plán patchování ve vlnách. Servery se rozdělí do vln podle služeb a jejich oken a z plánu se jedním krokem vytvoří změny. Ty procházejí stejnou kontrolou jako ostatní změny v systému: výpočtem dopadu na služby, servisními okny, zmrazeními a kolizemi. Dashboard zranitelností a nápravy pak ukazuje, jak oprava postupuje.

Dohoda jednou, klid každý měsíc

Patchování nemusí být měsíční vyjednávání. Když je jednou dohodnuté, kdy a jak se služba opravuje, správci mohou pracovat podle plánu, vlastníci služeb vědí, co je čeká, a bezpečnost vidí, že se opravy skutečně dostávají do produkce. Rozhovor s vlastníkem služby se pak vede jednou za čas a o tom podstatném, ne každý měsíc o tom samém.

Dohody o patchování, plán patchování ve vlnách a dashboard nápravy jsou součástí edice Business.