Kodėl prastovos vis dar stebina IT komandas

Prastova jau turėtų būti nuspėjama. Dėl pažangių stebėjimo sistemų, debesų infrastruktūros ir dirbtinio intelekto pagrįstos analizės IT komandos yra geriau nei bet kada anksčiau. Tačiau gedimai vis tiek įvyksta be įspėjimo, o kai įvyksta, jie sutrikdo veiklą, pažeidžia klientų pasitikėjimą ir kainuoja tikrus pinigus.

Taigi, kas negerai?

Tiesa ta, kad prastovos paprastai nesukelia vienos gedimo. Tai paslėptų spragų, besikaupiančių sistemose, įrankiuose ir procesuose, rezultatas. Išpakuosime, kodėl IT komandos vis dar užklumpamos netikėtai.

Visiško matomumo iliuzija

Dauguma organizacijų tiki, kad turi visišką savo sistemų matomumą. Prietaisų skydeliai veikia, įspėjimai sukonfigūruoti, o žurnalai fiksuojami realiuoju laiku.

Tačiau matomumas ne visada reiškia aiškumą.

Komandos dažnai remiasi izoliuota procesoriaus naudojimo, atminties apkrovos, delsos šuolio metrika. Šie signalai, nors ir naudingi, nepasako visos istorijos. Be konteksto jie tampa triukšmu, o ne įžvalga.

Štai kur atsiranda spraga:

• Metrika stebima individualiai, o ne kolektyviai
• Įspėjimai suveikia prasidėjus smūgiui, o ne prieš
• Pagrindinės priežasties analizė tampa reaktyvi, o ne aktyvi

Tai iš tikrųjų reiškia paprasta: komandos mato duomenis, bet ne visada juos supranta laiku.

Augantis sudėtingumas, susitraukimo kontrolė

Šiuolaikinės IT aplinkos nebėra paprastos. Programos platinamos mikropaslaugose, konteineriuose ir trečiųjų šalių API. Kiekvienas komponentas turi savo priklausomybę ir riziką.

Dėl šio sudėtingumo kyla svarbus iššūkis – kontrolė nebėra centralizuota.

Pagrindinės šiuolaikinės infrastruktūros realybės:

• Viena vartotojo užklausa gali būti perduodama per kelias paslaugas
• Vieno komponento gedimai gali plisti visoje sistemoje
• Priklausomybės dažnai yra už tiesioginės kontrolės ribų

Sistemoms tobulėjant, tampa vis sunkiau nustatyti tikslų gedimo šaltinį. Kai kas nors sugenda, tai jaučiasi staiga, bet iš tikrųjų tai yra tarpusavyje susijusių silpnybių rezultatas.

Įrankio perkrova sukuria akląsias vietas

Ironiška, bet turint daugiau įrankių komandos gali būti mažiau efektyvios.

Organizacijos dažnai diegia kelias stebėjimo, registravimo, našumo stebėjimo ir debesų valdymo platformas. Nors kiekvienas įrankis tarnauja tam tikram tikslui, jie retai integruojami sklandžiai.

Tai veda prie:

• Suskaidyti duomenys įvairiose platformose
• Trūksta vieningo sistemos vaizdo
• Lėtesnė incidento diagnostika

Užuot paspartinusios raišką, komandos praleidžia brangų laiką keisdamos įrankius ir rinkdamos informaciją. Kol paaiškės aiškumas, prastovos jau padaugėjo.

Įspėjamasis nuovargis kenkia atsakui

Įspėjimai yra skirti padėti, tačiau per daug įspėjimų veikia priešingai.

Kai inžinieriai bombarduojami nuolatiniais pranešimais, jie pradeda juos filtruoti mintyse. Žemo prioriteto arba klaidingi įspėjimai sumažina kritinių įspėjimų svarbą.

Pasekmės rimtos:

• Svarbūs įspėjimai nepaisomi
• Reagavimo laikas didėja
• Ankstyvieji nesėkmės signalai nepastebimi

Laikui bėgant komandos nustoja pasitikėti įspėjimais. Ir kai iškyla tikra problema, ji negauna reikiamo dėmesio, kol nevėlu.

Reaktyvus mąstymas, o ne iniciatyvi strategija

Daugelis IT komandų vis dar veikia reaktyviuoju režimu. Sistemos yra stebimos, bet nėra aktyviai ginčijamos.

Gedimai dažnai įvyksta netikėtais scenarijais – srauto padidėjimu, retomis klaidomis ar trečiųjų šalių trikdžiais. Be aktyvaus testavimo šios sąlygos lieka neištirtos, kol jos nepasireiškia gamyboje.

Įprastos spragos apima:

• Ribotas apkrovos testavimo arba chaoso inžinerijos naudojimas
• Per didelis pasitikėjimas testavimu prieš įdiegimą
• Realaus pasaulio streso sąlygų modeliavimo trūkumas

Tai rodo gilesnę problemą: daroma prielaida, kad stabilumas nėra nuolat patvirtinamas.

Priklausomybės rizika dažnai yra nematoma

Šiandieninės programos labai priklauso nuo išorinių paslaugų mokėjimo šliuzų, API, debesų platformų. Nors šios integracijos leidžia keisti mastelį, jos taip pat kelia riziką.

Problema ta, kad šios priklausomybės dažnai yra nepakankamai stebimos.

Pagrindiniai iššūkiai:

• Ribotas trečiųjų šalių našumo matomumas
• Nekontroliuoja išorinių gedimų
• Uždelstas prieš srovę susijusių problemų aptikimas

Kai priklausomybė sugenda, ji nedelsiant paveikia jūsų sistemą. Tačiau kadangi problema kyla kitur, ją sunkiau aptikti ir greitai išspręsti.

Silpni reagavimo į incidentus sistemos

Net jei problemos aptinkamos anksti, atsakymas gali nepavykti.

Aukšto slėgio situacijose neapibrėžtumas tampa didžiausia kliūtimi. Komandos gali neturėti aiškiai apibrėžtų vaidmenų, eskalavimo kelių ar atkūrimo strategijų.

Tai lemia:

• Sumišimas kritinėmis akimirkomis
• Pavėluotas sprendimų priėmimas
• Ilgas prastovos laikas

Reagavimas į incidentus yra ne tik priemonės, bet ir pasiruošimas. Be reguliarių pratybų ir aiškių protokolų, net kvalifikuotos komandos kovoja su spaudimu.

Per didelis pasitikėjimas automatika

Automatizavimas pakeitė IT operacijas, tačiau tai nėra apsaugos tinklas viskam.

Automatinis mastelio keitimas, perjungimo mechanizmai ir savaiminio gydymo sistemos sumažina rankines pastangas, tačiau jie taip pat gali užmaskuoti pagrindines problemas.

Kai automatizavimas nepavyksta:

• Problemos eskaluojamos greičiau nei tikėtasi
• Sunkiau nustatyti pagrindines priežastis
• Sistemos elgiasi nenuspėjamai

Kai kuriais atvejais automatizavimas gali net pabloginti gedimus, netinkamai reaguodamas į neįprastas sąlygas.

Komandų komunikacijos sutrikimai

Prastovos retai apsiriboja viena komanda. Tai dažnai apima plėtrą, operacijas, infrastruktūrą ir palaikymą.

Kai bendravimas nėra sklandus, raiška sulėtėja.

Dažni bendravimo iššūkiai:

• Savarankiškai dirbančios komandos
• Uždelstas dalijimasis informacija
• Netinkami prioritetai incidentų metu

Efektyvus bendravimas yra toks pat svarbus kaip ir techninės žinios. Be jo net mažos problemos gali virsti dideliais gedimais.

Postmortems be veiksmo

Po kiekvieno gedimo paprastai būna peržiūra. Nustatomos pagrindinės priežastys, o pamokos yra dokumentuojamos.

Tačiau vien dokumentacija neapsaugo nuo gedimų ateityje.

Tikroji problema yra čia:

• Veiksmo elementai neįgyvendinti
• Proceso patobulinimai vėluoja
• Sistemoje išlieka ta pati rizika

Dėl to panašūs gedimai kartojasi – netikėti, tačiau išvengiami.

Ką reikia keisti?

Kad išvengtumėte netikėtų prastovų, tai nereiškia, kad reikia pridėti daugiau įrankių, o pakeisti sistemų valdymą.

Didelio poveikio patobulinimai apima:

• Perėjimas nuo reaktyvių įspėjimų prie nuspėjamosios žvalgybos
• Vieningas stebėjimas, skirtas visam sistemos vaizdui
• Nuolat tikrinami gedimų scenarijai
• Aktyviai stebėti išorines priklausomybes
• Reagavimo į incidentus stiprinimas reguliariais pratimais
• Pomirtinių įžvalgų pavertimas tikrais veiksmais

Galutinė perspektyva

Prastova retai būna staigus įvykis. Tai lėtas nepastebėtų signalų, atjungtų sistemų ir neišspręstų pavojų kaupimasis.

Tai, kas atrodo netikėta, dažnai yra praleistų ryšių rezultatas.

IT komandos, kurios peržengia stebėjimą paviršiaus lygmeniu ir sutelkia dėmesį į gilesnį sistemos supratimą, bus tos, kurios išliks priekyje. Nes iš tikrųjų tikslas yra ne tik reaguoti į prastovą, bet ir pamatyti, kad ji ateis anksčiau nei tai įvyksta.