Dva tímy naplánujú údržbu rovnakého servera na rovnaký víkend. Sieťová zmena rozbije aplikáciu, ktorú nikto neoznačil ako závislú. Rollout záplaty sa prekryje s naplánovanou migráciou databázy. Tieto kolízie sa dejú preto, že zmeny sa plánujú izolovane — každý tím vidí svoju zmenu, ale nie zmeny ostatných.
Modul riadenia zmien v GLPI to rieši dvoma funkciami: kalendárom zmien a sledovaním dopadu cez prepojené aktíva.
Kalendár zmien
Každá zmena v GLPI má plánovaný dátum začiatku a konca. Kalendár zmien zobrazuje všetky naplánované zmeny na časovej osi, vďaka čomu sú prekryvy okamžite viditeľné. Ak dve zmeny cielia na rovnaké okno údržby, uvidíte to skôr, než ktorákoľvek z nich začne.
Kalendár je filtrovateľný podľa:
- Entity — zobrazenie zmien pre jednu divíziu alebo všetky divízie
- Stavu — len schválené zmeny, alebo vrátane čakajúcich na schválenie
- Kategórie — infraštruktúrne zmeny, aplikačné zmeny, sieťové zmeny
- Priority — oddelené zobrazenie vysokorizikových zmien od rutinných
Pre organizácie s pravidelným stretnutím Change Advisory Board je kalendár filtrovaný na „čakajúce na schválenie" priamo agendou CAB — nie je potrebný žiadny samostatný dokument.
Analýza dopadu cez prepojené aktíva
GLPI umožňuje prepojiť aktíva so záznamom zmeny. Zmena migrácie servera by mala obsahovať každý server, switch a inštanciu aplikácie, ktoré sú dotknuté. Keď to robíte dôsledne, stávajú sa možnými dve veci:
Detekcia kolízií
Ak Zmena A ovplyvňuje server SRV-05 a Zmena B tiež ovplyvňuje SRV-05, a obe sú naplánované na rovnaký týždeň — to je kolízia. Nájdete ju kontrolou, ktoré aktíva sa objavujú vo viacerých aktívnych zmenách. GLPI túto výstrahu (zatiaľ) neautomatizuje, ale jednoduchý databázový dotaz alebo report ju odhalí. Definovanie jasných schvaľovacích úrovní podľa rizika tu tiež pomáha — väčšina kolízií sa deje pri rutinnej práci, ktorá mohla byť vopred schválená ako štandardná zmena.
Korelácia incidentov
Keď nastane incident a používateľ nahlási „aplikácia nefunguje," prvá otázka je: „Zmenilo sa niečo?" Ak majú všetky zmeny prepojené aktíva, môžete vyhľadať nedávne zmeny, ktoré sa dotkli dotknutého servera alebo aplikácie. Namiesto obchádzania kolegov („Menil niekto niečo?") skontrolujete záznam zmien.
Okná údržby
Mnoho organizácií definuje pravidelné okná údržby — sobota 02:00-06:00 pre infraštruktúru, streda 22:00-01:00 pre nasadenie aplikácií. GLPI nemá zabudovaný koncept okna údržby, ale dá sa dosiahnuť pomocou:
- Šablón zmien — predvyplnené formuláre zmien so štandardnými dátumami okna, hodnotením rizík a komunikačným plánom
- Filtrovanie kalendára — kontrola, či plánovaná zmena spadá do schváleného okna
- Výnimky v SLA kalendári — konfigurácia pozastavenia SLA hodín počas plánovanej údržby, aby kontrolovaný výpadok nepočítal ako porušenie
Pre organizácie, ktoré potrebujú podmienené smerovanie schvaľovania viazané na okná údržby — automatické schválenie ak spadá do štandardného okna, eskalácia na CAB inak — Cascade zvláda túto vetvenú logiku.
Zmrazenia a blackout obdobia
Zmrazenia releasov — obdobia, kedy nie sú povolené žiadne zmeny (typicky okolo sviatkov, konca štvrťroka alebo veľkých udalostí) — sa riadia procesom, nie konfiguráciou GLPI. Ale môžete ich podporiť tým, že:
- Nastavíte obchodné pravidlo, ktoré zablokuje schválenie zmeny počas dátumov zmrazenia
- Pridáte upozornenie o zmrazení do šablóny formulára zmeny
- Vyfiltrujete v kalendári zmeny naplánované počas blackoutu a označíte ich na preloženie
Urgentné zmeny počas období zmrazenia sú špeciálny prípad — obchádzajú blackout z definície, ale potrebujú rozšírenú dokumentáciu a povinnú post-implementačnú revíziu. Pozrite náš sprievodca urgentnými zmenami a PIR v GLPI.
Kalendár zmien je najcennejší v organizáciách, kde viacero tímov zdieľa infraštruktúru. Čím viac tímov podáva zmeny nezávisle, tým dôležitejšie je, aby všetci videli rovnakú časovú os.