Prakse eksploatacije koje biznis vidi: u šta ulagati najpre
Spiskovi „najvažnijih ITIL praksi“ rukovodstvu obično malo daju: napisani su jezikom procesa, a rukovodilac pita nešto drugo - šta će dati sledeći kvartal rada tima i gde će se to videti. Postoji dosta slučajeva kada praksa, ispravna po knjizi, godinama nije davala biznisu ništa primetno. I obrnuto: dosadna disciplina, kao što je praćenje sistema posle ažuriranja, menjala je sliku za nekoliko nedelja.
Zato rangiranje ispod nije napravljeno po udžbeniku, nego po ciljevima zbog kojih kompanija uopšte drži eksploataciju. Prvo - četiri takva cilja. Zatim dvanaest ITIL 4 praksi po povraćaju uloženog truda. Zatim isti spisak očima klijenta. Na kraju - redosled uvođenja, pokazatelji za merenje efekta i tipične zamke. Sam redosled je naš, iz iskustva u eksploataciji: ITIL 4 opisuje 34 prakse, ali ih ne rangira.
1. Četiri cilja zbog kojih se plaća eksploatacija
Eksploatacija retko donosi novi prihod - ona štiti onaj koji već postoji. To vredi reći otvoreno, inače svaki razgovor sa biznisom počinje odbranom. Ciljeva je četiri, i svaku praksu treba proveriti pitanjem: za koji od njih radi.
Sačuvati prihod koji već postoji
Zastoj ključne usluge nije „tehnički incident“, nego sati kada kompanija ne prodaje, ne isporučuje i ne uslužuje, a zaposleni čekaju. Ovde je doprinos eksploatacije direktan, i najlakše ga je pokazati u satima.
Delovati pouzdano za klijenta
Klijent ne sudi po procentu dostupnosti, nego po svom iskustvu: da li je primetio kvar pre vas, da li je dobio jasan status, da li se to ponovilo nedelju dana kasnije. Odatle rastu produženja ugovora i preporuke.
Dobiti pristup tržištu
Tenderi, ugovori sa garancijama nivoa usluge, granske provere traže dokaze: procesi su opisani, dnevnici se vode, rokovi se poštuju. Ponekad - sertifikat po međunarodnom standardu upravljanja IT uslugama ISO/IEC 20000. Bez toga je deo tržišta zatvoren, koliko god tehnika bila dobra.
Osloboditi vreme tima
Biznis ovaj cilj primećuje poslednji, ali od njega zavisi da li kompanija ima snage za razvoj. Tim koji stalno gasi požare ne radi projekte - on ih obećava.
Praksa koja ne radi ni za jedan od četiri cilja može biti korisna unutar službe, ali budžet za nju nećete moći da odbranite - i to je normalno. Problem počinje kada su takve prakse većina u planu.
2. Rangiranje praksi po povraćaju
Redosled je po povraćaju uloženog truda, uz korekciju za brzinu: praksa koja daje isti efekat za mesec dana stoji iznad one koja ga daje za godinu. Rangiranje je za tipičnu kompaniju sa izgrađenom infrastrukturom i bez posebnog tima za procese. Kod startapa u oblaku ili industrijskog preduzeća redosled će se pomeriti, a kolona „Šta daje biznisu“ pomaže da ga prilagodite sebi. Nazivi praksi su po ITIL 4.
| Br. | Praksa | Šta daje biznisu | Šta vidi klijent | Odakle početi |
|---|---|---|---|---|
| 1 | Upravljanje incidentimaIncident Management | Smanjuje vreme zastoja. Uklanja pauze koje su često duže od same popravke: traženje odgovornog, čekanje pristupa, usaglašavanje odluke | Kvar se brzo završava; klijent dobija jasan status, a ne tišinu | Razložiti pet najdužih incidenata po fazama: otkrivanje, dodela, popravka |
| 2 | Upravljanje problemimaProblem Management | Smanjuje broj kvarova. Po ITIL-u to je praksa koja traži i uklanja uzroke ponovljenih kvarova, a ne pojedinačne slučajeve | „Kod vas je prestalo da se kvari jedno te isto“ - najjači signal poverenja | Otvoriti karticu problema za tri najčešća ponovljena kvara, sa vlasnikom i rokom |
| 3 | Monitoring i upravljanje događajimaMonitoring and Event Management | Za kvar saznaje sistem, a ne klijent. Menja samu tačku od koje se računa zastoj | Kompanija prva javlja o kvaru. To je primetnije od razlike od pola sata u oporavku | Izračunati udeo incidenata o kojima ste saznali od klijenata i pokriti najčešće monitoringom |
| 4 | Upravljanje izmenamaChange Enablement | Zatvara najveći upravljivi izvor kvarova: prema podacima Google-a, oko 70% kvarova izazvano je izmenama u sistemu koji radi | Ažuriranja prestaju da budu lutrija; radovi idu u najavljenom prozoru | Uvesti period praćenja posle ažuriranja i unapred zapisan uslov vraćanja |
| 5 | Upravljanje nivoom uslugeService Level Management | Pretvara rad službe u obećanje koje se može proveriti. Bez toga razgovor o kvalitetu ostaje sukob mišljenja | Jasno je šta je obećano i da li se ispunjava; izveštaj se može pokazati sopstvenom rukovodstvu | Opisati 3-5 ključnih usluga jezikom biznisa i dogovoriti ciljni nivo za svaku |
| 6 | Upravljanje znanjem i baza poznatih grešakaKnowledge Management; baza poznatih grešaka je deo upravljanja problemima | Uklanja zavisnost od „nezamenljivih“ ljudi: poznat kvar se popravlja po uputstvu, a ne po sećanju jednog inženjera | Brzina odgovora ne zavisi od toga ko je danas u smeni | Opisati deset najčešćih kvarova: znaci, zaobilazno rešenje, status trajnog |
| 7 | Upravljanje kapacitetom i performansamaCapacity and Performance Management | Pretvara deo kvarova u planirane radove: prostor, memorija i propusni opseg se troše predvidljivo | Servis „ne usporava krajem meseca“; vršni periodi prolaze ravnomerno | Uzeti tri resursa koji rastu ka granici i izračunati datum kada će je dostići |
| 8 | Upravljanje kontinuitetom uslugaService Continuity Management | Radi sa retkim događajima, ali upravo oni određuju najgori scenario godine: gubitak lokacije, ransomware, katastrofa | Vidi se samo u trenutku velikog kvara - ali tada se vidi ceo | Sprovesti jednu vežbu: vratiti ključnu bazu iz rezervne kopije i zapisati stvarno vreme |
| 9 | Upravljanje dobavljačimaSupplier Management | Primetan deo zastoja dolazi spolja: kanali, oblak, platni gejtveji. Time se može upravljati samo ugovorom i procedurom | Klijentu je svejedno čiji je kvar. On ocenjuje kako se vi s njim nosite | Za svakog dobavljača sakupiti kontakt, rokove i postupak eskalacije - jedna strana za dežurnog |
| 10 | Upravljanje konfiguracijama i IT imovinomService Configuration Management, IT Asset Management | Osnova za povezivanje događaja, analizu uticaja i planiranje. Sama po sebi biznisu skoro nevidljiva | Ne vidi se - pokazuje se kroz brzinu ostalih praksi | Ne praviti potpunu evidenciju. Opisati zavisnosti samo za ključne usluge |
| 11 | Kontinuirano unapređenjeContinual Improvement | Čuva postignuto: bez redovne revizije rezultati ostalih praksi postepeno blede | Stabilnost na dugom horizontu, a ne događaj | Jednom u kvartalu: jedna analiza podataka, tri odluke, provera za kvartal |
| 12 | Upravljanje zahtevima za usluguService Request Management | Skida sa tima rutinu - pristupe, lozinke, tipične molbe - i oslobađa vreme za inženjerski rad | Zaposleni to primećuju više nego spoljni klijenti | Prebaciti na samoposluživanje tri najmasovnija tipična zahteva |
Napomena bez koje se rangiranje lako pogrešno pročita: ovo je redosled povraćaja uloženog truda, a ne važnosti. Donji redovi nisu „nevažni“: bez evidencije konfiguracija ne mogu se povezati događaji, bez kontinuiranog unapređenja gornji redovi se vremenom vraćaju unazad. Radi se samo o tome odakle početi kada resursa nema dovoljno. A njih skoro uvek nema dovoljno.
3. Zašto su prve tri baš takve
Tri gornja reda pokrivaju tri dela istog puta: kvar se desio → primećen je → otklonjen je → ne ponavlja se. Zato ne zamenjuju jedna drugu, i bolje ih je uvoditi zajedno, a ne redom.
- Monitoring pomera početak. Dok za kvarove saznajete od klijenata, sve ostalo već kasni. Ova praksa ne ubrzava popravku - pomera trenutak od kog popravka počinje.
- Upravljanje incidentima sabija sredinu. U analizama dugih incidenata veći deo vremena često ne odlazi na akcije, nego na pauze: traženje odgovornog, čekanje pristupa, utvrđivanje ko sme da odluči. To se leči načinom predaje i eskalacije, a ne zapošljavanjem jačih inženjera.
- Upravljanje problemima uklanja ponavljanja. Prve dve prakse rade sa svakim slučajem posebno, ova - sa njihovim brojem. Povraćaj je najsporiji, ali najdugotrajniji: uklonjen uzrok se ne vraća sledećeg kvartala.
Odatle praktičan zaključak: ako birate jednu od tri, pogledajte svoje podatke za pola godine. Mnogo kratkih ponovljenih kvarova uz prihvatljivo vreme popravke - ulažite u upravljanje problemima. Kvarova je malo, ali se svaki vuče satima - ulažite u upravljanje incidentima i eskalaciju.
4. Šta klijent zaista ocenjuje
Služba eksploatacije meri sebe dostupnošću i vremenom oporavka. Klijent meri nečim drugim, i razlika između ova dva spiska objašnjava situaciju „pokazatelji su zeleni, a klijent nezadovoljan“. Ispod je ono što, po našem iskustvu, klijenti sami navode, i praksa koja je za to odgovorna.
| Šta je važno klijentu | Zašto baš to | Koja praksa je odgovorna |
|---|---|---|
| Predvidljivost je važnija od brzine | Klijent planira svoj rad. Kvar od dva sata sa jasnim rokom podnosi se lakše nego kvar od četrdeset minuta u potpunoj neizvesnosti | Upravljanje nivoom usluge, poruke o toku radova |
| Saznati od vas, a ne primetiti sam | Ako je klijent prvi otkrio kvar, poverenje trpi više nego od samog trajanja | Monitoring i upravljanje događajima |
| Da se ne ponavlja | Jedan veliki kvar se doživljava kao loša sreća. Treći isti kvar u mesecu - kao osobina dobavljača | Upravljanje problemima, baza poznatih grešaka |
| Jedan ulaz i jedan odgovorni | Prepričavati problem trećoj osobi najviše nervira, kakav god bio ishod. U ITIL-u se to zove jedinstvena tačka kontakta | Upravljanje incidentima, služba podrške |
| Radovi - u najavljenom prozoru | Nedostupnost o kojoj niko nije upozorio za klijenta se ničim ne razlikuje od kvara | Upravljanje izmenama, kalendar radova |
| Stvaran rok umesto optimističnog | Probijen rok košta više od dugog roka rečenog odmah. Posle drugog puta klijent ne veruje nijednom roku | Upravljanje incidentima, disciplina poruka |
Primetite zajedničku crtu: nijedan od šest redova nije o tehnici. Pet od šest se rešava disciplinom, a ne novcem - dobra vest za kompaniju sa ograničenim budžetom. Ocenu klijenta možete podići primetno ranije nego dostupnost.
5. Redosled uvođenja
Prakse su povezane, i neke od njih nema smisla graditi pre drugih. Redosled ispod je napravljen tako da se svaki korak oslanja na prethodni, a biznis vidi promene pre nego što mu ponestane strpljenja.
- Srediti zapise. Jedan dnevnik incidenata, obavezna polja: vreme početka i kraja, objekat, ishod. Bez toga nema čime da se meri efekat ostalih koraka, i za pola godine spor o rezultatu biće spor mišljenja.
- Očistiti upozorenja i popraviti eskalaciju. Ko saznaje, za koliko, ko je sledeći po tajmeru. Vidljiv rezultat - za nekoliko nedelja.
- Uvesti period praćenja posle izmena i uslov vraćanja. Najjeftiniji korak sa najbržim povraćajem: ne trebaju ni novi sistemi ni novi ljudi.
- Pokrenuti upravljanje problemima na tri najčešća kvara. Ne na sve - baš na tri. Praksa započeta široko obično utihne već u prvom kvartalu.
- Opisati ključne usluge i dogovoriti ciljne nivoe. Sada postoji čime da se potvrde obećanja: dnevnik se vodi, eskalacija radi, ponavljanja je manje.
- Dalje - po podacima. Kapacitet, kontinuitet, dobavljači, evidencija konfiguracija uključuju se redom koji predlaže analiza vaših sopstvenih incidenata, a ne opšti spisak.
Česta greška u redosledu je početi od potpune evidencije konfiguracija. Ona izgleda kao temelj, ali traje mnogo meseci i za to vreme biznisu ne daje nijedan vidljiv rezultat. Po našem iskustvu, projekti eksploatacije češće se zatvaraju ne zato što su pogrešni, nego zato što predugo ništa ne pokazuju.
6. Kako meriti efekat
Šest pokazatelja ispod je razumljivo bez pripreme, pet od njih se računa iz dnevnika incidenata. Svi su izraženi u udelima i satima: takav razgovor je lakše braniti nego razgovor o uslovnom novcu, koji sagovornik uvek može da ospori.
- Udeo ponovljenih incidenata: koliko procenata kvarova ponavlja već viđeni. Direktna ocena upravljanja problemima.
- Udeo neuspešnih izmena: koliko ažuriranja je zahtevalo hitnu intervenciju - vraćanje ili hitnu ispravku. To je jedan od DORA pokazatelja, opšteprihvaćenog skupa metrika isporuke izmena. Ocena upravljanja izmenama.
- Udeo kvarova otkrivenih pre klijenta: glavni pokazatelj monitoringa i ujedno ono što klijent oseća direktno.
- Vreme do početka rada naspram vremena popravke: dva dela jednog intervala. U DevOps-u se prvi deo meri prosečnim vremenom potvrde (MTTA), a celina prosečnim vremenom oporavka (MTTR). Razlika pokazuje gde ulagati: u način predaje ili u kvalifikaciju.
- Koncentracija zastoja: koji udeo sistema daje glavni deo izgubljenog vremena. Pokazuje gde uopšte ima smisla ulagati trud.
- Udeo vremena tima na havarijski i rutinski rad: računa se ne iz dnevnika, nego iz evidencije vremena. Smernica Google SRE je da bude ispod 50%. Upravo ovaj pokazatelj objašnjava biznisu zašto projekti ne napreduju.
Pravilo merenja je jednostavno: uzeti početni nivo pre početka radova i ponoviti merenje za kvartal na isti način. Bez početnog nivoa svaki rezultat ostaje tvrdnja, a prvo skeptično pitanje na sastanku će ga poništiti.
7. Pet zamki
- Uvoditi praksu u celini po knjizi. ITIL je skup preporuka, a ne obavezan program. Minimum koji radi skoro je uvek manji od opisanog, i od njega treba početi.
- Meriti tim brojem zatvorenih prijava. Pokazatelj brzo raste i ništa ne znači: nagrađuje usitnjavanje zadataka i formalno zatvaranje umesto rada sa uzrocima.
- Postaviti vreme zatvaranja kao cilj. Incidenti počinju da se zatvaraju pre nego što je sve vraćeno, a onda se otvaraju novi za isto. Podaci se kvare, a sa njima i mogućnost bilo kakve analize.
- Smatrati praksu uvedenom kada je procedura napisana. Znak uvođenja je promenjeno ponašanje dežurnog u tri ujutru, a ne potpisan dokument.
- Graditi sve odjednom. Tri prakse dovedene do kraja daju više od dvanaest započetih. To je česta greška jakih timova: imaju snage da počnu sve.
Kratak zaključak. Prakse treba birati ne po spisku „ispravnog“, nego po dva pitanja: za koji cilj biznisa radi rezultat i kada će se videti. Kod većine kompanija vrh spiska je isti - incidenti, problemi, monitoring, izmene - jer je tu glavni deo upravljivog zastoja. Ali redosled unutar te četvorke je kod svakog drugačiji, i ne određuje ga mišljenje, nego sopstveni podaci za poslednjih pola godine.
Želite da shvatite odakle da počnete baš vi - pošaljite izvoz incidenata: vratićemo analizu: gde se koncentriše zastoj, koliko brzo se popravlja i koji kvarovi povlače druge. Brz način da procenite nivo rečima - test zrelosti u botu, oko 5 minuta. Šta raditi sa svakim nalazom, opisano je posebno - u „Šta dalje“.
Razgovarajte o planu za kvartal sa inženjerom eksploatacije - .