Ce ne poate învăța arhitectura despre sistemele de autovindecare

Republicat de Platon

Urmaritori: 0

Echipele DevOps și inginerii de fiabilitate a site-ului (SRE) se ocupă zilnic de cod. Făcând acest lucru, îi învață să-și cerceteze lumea, să facă observații inteligente și să creeze conexiuni neașteptate. La urma urmei, deși de natură extrem de logică și matematică, dezvoltarea de software este, cel puțin parțial, o formă de artă.

Neconvins de acea afirmație? Luați în considerare paralelele dintre cele mai remarcabile fapte arhitecturale ale istoriei și ingineria software modernă. Este o comparație potrivită: la fel ca ingineria software, arhitectura folosește calcule matematice complexe pentru a crea ceva frumos. Și în ambele discipline, o ușoară greșeală de calcul poate duce la consecințe semnificative. În mod fascinant, multe greșeli arhitecturale celebre sunt analoge cu problemele pe care le găsim în cod.

Amintiți-vă, inspirația este peste tot – atâta timp cât știți unde să căutați. Iată câteva lecții pe care inginerii de software le pot învăța din epifaniile arhitecturale de-a lungul secolelor, în special în ceea ce privește viitorul sistemelor de auto-vindecare.

Lecția 1: cazurile Edge vor exploata întotdeauna vulnerabilitățile sistemului

Turnul Citicorp – numit acum 601 Lexington – a terminat construcția în New York City în 1977, moment în care era a șaptea cea mai înaltă clădire din lume. Designul de ultimă generație al zgârie-norilor includea trei stilturi de peste 100 de picioare. A fost o minune la finalizare. Cu toate acestea, un student de licență a descoperit curând ceva șocant: vânturi puternice ar putea pune în pericol integritatea clădirii. Mai exact, dacă vânturile puternice de sferturi loveau colțurile Turnului Citicorp, structura a fost supusă prăbușirii - un literal carcasă de margine.

Turnul avea o șansă de una din 16 să se prăbușească în fiecare an. Aceste șanse pot atrage pe cineva care stă la o masă de jocuri de noroc, dar perspectiva era sumbră pentru arhitecții și inginerii structurali din spatele Turnului Citicorp. Din fericire, tehnicienii au reușit să consolideze îmbinările cu șuruburi ale clădirii. Dezastrul a fost evitat.

Inginerii structurali știau că Turnul Citicorp se va confrunta în cele din urmă cu un vânt suficient de puternic pentru a-și compromite rulmenții. În mod similar, inginerii de software experimentați știu că monitorizarea performanței aplicațiilor (APM) și gestionarea evenimentelor nu sunt suficiente pentru a proteja un sistem de inevitabile cazuri de margine. Asta pentru că sistemele statice fără învățare automată (ML) capabilitățile nu pot face față unor situații noi neașteptate și neplanificate, cum ar fi vânturile încadrate. Când se bazează exclusiv pe instrumente de monitorizare, un administrator uman trebuie să descifreze erorile și să escaladeze procesul de gestionare a incidentelor.

Pentru a reduce timpul mediu de recuperare (MTTR)/timpul mediu de detectare (MTTD), echipele DevOps trebuie să accepte probabilitatea mare de cazuri marginale și să lucreze pentru a implementa soluții de auto-învățare în mod preventiv. Această lecție merge mult, deoarece previziunea este esențială în inginerie.

Lecția 2: „Construirea avionului în timp ce zboară” creează un ciclu fără sfârșit

Evenimentele tragice au produs câteva dintre ele cele mai importante lecții din istoria aviației. Când un avion a suferit o decompresie imensă în timpul zborului și s-a prăbușit în 1954, inginerii au constatat că ferestrele pătrate pentru pasageri erau un punct de stres inutil. De acum inainte, avioanele erau dotate cu ferestre rotunjite. Incendiile la bord au dus la noi aranjamente ale scaunelor care acordau prioritate ușurinței evacuării. Aceste schimbări au salvat nenumărate vieți.

În multe industrii – inclusiv aviația – nu există nicio modalitate de a testa în mod exhaustiv un produs. După cum am menționat mai devreme, cazurile marginale sunt inevitabile. Cea mai mare concluzie aici este că inginerii de software trebuie să țină seama de vulnerabilitățile sistemului lor atunci când se prezintă. De acolo, trebuie să le abordeze în mod oportun. Pentru a face acest lucru necesită două lucruri: (1) identificarea și urmărirea indicatorilor cheie de performanță (KPI) potriviți și (2) investirea timpului și a resurselor în îmbunătățirea sistemelor pe baza unor metrici relevante.

Echipa de inginerie obișnuită investește în 16 până la 40 de instrumente de monitorizare, dar deseori ratează obiectivul pe care metricile demonstrează succesul. Mai puțin de 15% dintre echipe urmăresc MTTD, așa că pierd 66% din ciclul de viață al incidentului. Și un sfert din echipe raportează lipsesc acordurile de nivel de servicii (SLA) în ciuda investițiilor semnificative în urmărirea disponibilității. Acest lucru ne spune că colectarea datelor necesită o analiză amănunțită și sistematică pentru a reduce problema, soluțiile punctuale nu mai sunt suficiente.

Inginerii de software, echipele DevOps și SRE trebuie să prioritizeze procesele și instrumentele care extrag valoare din cantități copleșitoare de informații despre disponibilitate. În loc să observe pur și simplu o eroare critică, ei trebuie să ia o pagină din cartea unui inginer de aviație și să ia rapid decizii critice. Secretul pentru a face acest lucru constă în AI.

Lecția 3: AI este un element fundamental pentru sistemele de auto-vindecare

Un sistem de auto-vindecare complet autonom, perfect funcțional, este ideal pentru orice inginer software. Sistemele care se corectează sunt bune pentru satisfacția clienților, deoarece elimină timpul de nefuncționare costisitor pentru consumatori. În plus, acestea sunt incredibil de benefice pentru funcțiile de management al serviciilor IT (ITSM), deoarece reduc semnificativ nevoia de gestionare plictisitoare a biletelor. Construirea unui astfel de sistem necesită mai multe componente, dintre care multe sunt momentan inaccesibile. Dar suntem mai aproape de o realitate de auto-vindecare decât ar putea realiza unii.

Lipsa adoptării pe scară largă a AI rămâne cel mai mare obstacol cu care se confruntă sistemele de auto-vindecare astăzi. Deși multe companii au adoptat instrumente rudimentare bazate pe AI sau ML, integritatea acestor instrumente este îndoielnică. Adică, mulți ingineri se ocupă inteligență artificială pentru operațiuni IT (AIOps) tehnologii care urmează logica de automatizare bazată pe reguli în loc de algoritmi AI autonomi. Distincția poate părea mică, dar, în practică, este diferența dintre ore de productivitate pierdută și milioane de pierderi posibile.

Chestia este că instrumentele AIOps bazate pe reguli analizează interacțiunile dintre soluțiile punctuale disparate și pot identifica probabil erorile comune de date. Dar sistemele bazate pe automatizare nu pot procesa evoluția erorilor complet noi în timp și nici nu pot prezice noi defecțiuni ale datelor. Asta pentru că administratorii umani care codifică aceste funcții cer sistemului să urmeze un dacă aceasta, atunci aceea model logic. Instrumentele AIOps cu adevărat eficiente atenuează erorile care apar la toate cele patru puncte de telemetrie clasice – de la detectare la rezoluție – prin clasificarea tiparelor noi și problematice înainte ca tehnicienii umani să fie conștienți de existența lor.

În timp ce așteptăm al treilea val iminent de IA, această versiune de AIOps este cea mai apropiată pe care o avem de sistemele de auto-vindecare. Va fi interesant de urmărit modul în care aplicațiile AIOps actuale intră în viitorul AI, care va include automatizare pe deplin realizată și posibilități independente de gândire. Poate că atunci și inginerii structurali vor culege roadele unui sistem de auto-vindecare bazat pe inteligență artificială.