Kaj nas lahko nauči arhitektura o samozdravilnih sistemih

Ponovno objavil Platon

Spremljevalci: 0

Ekipe DevOps in inženirji za zanesljivost spletnega mesta (SRE) se dnevno ukvarjajo s kodo. S tem se naučijo natančno preučiti svoj svet, bistroumno opazovati in narisati nepričakovane povezave. Navsezadnje je razvoj programske opreme, čeprav je po naravi zelo logičen in matematičen, vsaj deloma oblika umetnosti.

Vas ta izjava ni prepričala? Razmislite o vzporednicah med najimenitnejšimi arhitekturnimi podvigi zgodovine in sodobnim programskim inženiringom. To je primerna primerjava: tako kot programsko inženirstvo tudi arhitektura uporablja zapletene matematične izračune, da ustvari nekaj čudovitega. In v obeh disciplinah lahko rahla napačna ocena povzroči pomembne posledice. Fascinantno je, da so številne znane arhitekturne napake podobne težavam, ki jih najdemo v kodi.

Ne pozabite, da je navdih povsod – dokler veste, kje iskati. Tukaj je nekaj lekcij, ki se jih programski inženirji lahko naučijo iz arhitekturnih epifanij skozi stoletja, zlasti glede prihodnosti samozdravilnih sistemov.

Lekcija 1: robni primeri bodo vedno izkoriščali sistemske ranljivosti

Citicorp Tower – zdaj imenovan 601 Lexington – je bil v New Yorku dokončan leta 1977 in je bil takrat sedma najvišja stavba na svetu. Najsodobnejša zasnova nebotičnika je vključevala tri več kot 100-metrske podstavke. To je bil čudež ob zaključku. Vendar je dodiplomski študent kmalu odkril nekaj motečega: močan veter lahko ogrozijo celovitost zgradbe. Natančneje, če bi močni četrtinski vetrovi zadeli vogale Citicorpovega stolpa, bi se struktura zrušila – dobesedno robni kovček.

Možnost, da se stolp vsako leto zruši, je bila ena proti 16. Te možnosti lahko privabijo nekoga, ki sedi za igralno mizo, vendar so bili obeti za arhitekte in gradbene inženirje za Citicorp Tower mračni. K sreči je tehnikom uspelo okrepiti vijačne spoje stavbe. Katastrofi so se izognili.

Gradbeni inženirji so vedeli, da se bo Citicorp Tower sčasoma soočil z dovolj močnim vetrom, da bi ogrozil njegove ležaje. Podobno izkušeni inženirji programske opreme vedo, da robustno spremljanje delovanja aplikacij (APM) in upravljanje dogodkov nista dovolj za zaščito sistema pred neizogibnimi robnimi primeri. To je zato, ker statični sistemi brez strojno učenje (ML) zmogljivosti ne morejo obvladati nepričakovanih in nenačrtovanih novih situacij, kot je četrtinski veter. Ko se zanaša samo na orodja za spremljanje, mora človeški skrbnik dešifrirati napake in stopnjevati postopek upravljanja incidentov.

Da bi skrajšali srednji čas za obnovitev (MTTR)/srednji čas za odkrivanje (MTTD), morajo ekipe DevOps sprejeti visoko verjetnost robnih primerov in si prizadevati za preventivno uvajanje samoučečih se rešitev. Ta lekcija je zelo pomembna, saj je v inženirstvu ključnega pomena predvidevanje.

2. lekcija: »Sestavljanje letala med letenjem« ustvarja neskončen cikel

Tragični dogodki so prinesli več najpomembnejše lekcije v zgodovini letalstva. Ko je letalo leta 1954 med letom utrpelo ogromno dekompresijo in strmoglavilo, so inženirji ugotovili, da so kvadratna potniška okna nepotrebna točka stresa. odslej letala so bila opremljena z zaobljenimi okni. Požari na krovu so privedli do nove razporeditve sedežev, ki daje prednost enostavni evakuaciji. Te spremembe so rešile nešteto življenj.

V mnogih panogah – vključno z letalstvom – ni možnosti za izčrpen stresni test izdelka. Kot smo že omenili, so robni primeri neizogibni. Največji zaključek pri tem je, da morajo programski inženirji upoštevati ranljivosti svojega sistema, ko se predstavijo. Od tam jih morajo obravnavati smotrno. Za to sta potrebni dve stvari: (1) prepoznavanje in sledenje pravim ključnim indikatorjem uspešnosti (KPI) in (2) vlaganje časa in virov v izboljšanje sistemov na podlagi ustreznih meritev.

Povprečna ekipa inženirjev investira v 16 do 40 orodij za spremljanje, vendar pogosto zgrešijo cilj, na katerem meritve kažejo uspeh. Manj kot 15 % ekip sledi MTTD, tako da zamudijo 66 % življenjskega cikla incidenta. In poroča ena četrtina ekip manjkajo njihovi sporazumi o ravni storitev (SLA) kljub znatnim naložbam v sledenje razpoložljivosti. To nam pove, da zbiranje podatkov potrebuje temeljito, sistematično analizo, da bi ga zmanjšali – točkovne rešitve niso več dovolj.

Programski inženirji, ekipe DevOps in SRE morajo dati prednost procesom in orodjem, ki pridobijo vrednost iz ogromne količine informacij o razpoložljivosti. Namesto da preprosto opazujejo kritično napako, morajo vzeti stran iz knjige letalskega inženirja in hitro sprejeti kritične odločitve. Skrivnost tega je v AI.

Lekcija 3: AI je temeljni gradnik sistemov samozdravljenja

Popolnoma avtonomen, brezhibno delujoč sistem, ki se sam obnavlja, je idealen za vsakega inženirja programske opreme. Sistemi, ki se popravljajo sami, so dobri za zadovoljstvo strank, saj odpravljajo drage izpade, s katerimi se soočajo uporabniki. Poleg tega so izjemno koristni za funkcije upravljanja storitev IT (ITSM), saj znatno zmanjšajo potrebo po dolgočasnem upravljanju vstopnic. Gradnja takega sistema zahteva več komponent, od katerih so mnoge trenutno nedosegljive. Vendar smo bližje resničnosti samozdravljenja, kot se nekateri morda zavedajo.

Pomanjkanje široke uporabe umetne inteligence ostaja največja ovira, s katero se sistemi za samozdravljenje danes soočajo. Čeprav je veliko podjetij sprejelo osnovna orodja, ki temeljijo na AI ali ML, je celovitost teh orodij vprašljiva. Se pravi, s čimer se ukvarja veliko inženirjev umetna inteligenca za IT operacije (AIOps) tehnologije, ki sledijo avtomatizacijski logiki, ki temelji na pravilih, namesto avtonomnih algoritmov AI. Razlika se morda zdi majhna, vendar je v praksi razlika med urami izgubljene produktivnosti in milijoni možnih izgub.

Dejstvo je, da orodja AIOps, ki temeljijo na pravilih, analizirajo interakcije med rešitvami različnih točk in lahko verjetno prepoznajo običajne podatkovne napake. Toda sistemi, ki temeljijo na avtomatizaciji, ne morejo obdelati razvoja povsem novih napak skozi čas, niti ne morejo predvideti novih napak v podatkih. To je zato, ker človeški skrbniki, ki kodirajo te funkcije, od sistema zahtevajo, da sledi če to, potem ono logični vzorec. Resnično učinkovita orodja AIOps ublažijo napake, ki se pojavijo na vseh štirih klasičnih telemetričnih točkah – od zaznavanja do razrešitve – tako, da razvrstijo nove in problematične vzorce, še preden se človeški tehniki sploh zavedajo njihovega obstoja.

Medtem ko čakamo na skorajšnji tretji val umetne inteligence, je ta različica AIOps najbližje samopopravljivim sistemom. Zanimivo bo spremljati, kako trenutne aplikacije AIOps prehajajo v prihodnost umetne inteligence, ki bo vključevala popolnoma realizirano avtomatizacijo in neodvisne možnosti razmišljanja. Morda bodo takrat tudi gradbeni inženirji izkoristili prednosti samozdravilnega sistema, ki temelji na AI.