Mida arhitektuur meile isetervendavate süsteemide kohta õpetab?

DevOpsi meeskonnad ja saidi töökindluse insenerid (SRE) tegelevad koodiga iga päev. See õpetab neid oma maailma hoolikalt uurima, teravaid tähelepanekuid tegema ja ootamatuid seoseid looma. Lõppude lõpuks, kuigi tarkvaraarendus on oma olemuselt väga loogiline ja matemaatiline, on see vähemalt osaliselt kunstivorm. 

Kas see väide ei veena? Mõelge paralleelidele ajaloo kõige tähelepanuväärsemate arhitektuuriliste saavutuste ja kaasaegse tarkvaratehnika vahel. See on tabav võrdlus: nagu tarkvaratehnika, kasutab arhitektuur keerukaid matemaatilisi arvutusi, et luua midagi ilusat. Ja mõlemal erialal võib kerge valearvestus kaasa tuua olulisi tagajärgi. Põnev on see, et paljud kuulsad arhitektuurivead on analoogsed koodist leitud probleemidega.

Pidage meeles, et inspiratsiooni on kõikjal – seni, kuni teate, kust otsida. Siin on mõned õppetunnid, mida tarkvarainsenerid saavad sajandite jooksul läbiviidud arhitektuurilistest epifaaniatest õppida, eriti mis puudutab isetervenevate süsteemide tulevikku.

1. õppetund: Edge-juhtumid kasutavad alati ära süsteemi turvaauke

Citicorp Tower (praegu nimega 601 Lexington) lõpetas ehituse New Yorgis 1977. aastal, mil see oli maailma kõrguselt seitsmes hoone. Pilvelõhkuja tipptasemel disain sisaldas kolme 100+ jala kõrgust vaia. See oli valmimise ime. Üks bakalaureuseõppe üliõpilane avastas aga peagi midagi jahmatavat: tugevad tuuled võib kahjustada hoone terviklikkust. Täpsemalt, kui Citicorp Toweri nurgad tabasid võimsad veerandtuuled, siis konstruktsioon varises kokku – see on sõna otseses mõttes. servakott.

Tornil oli igal aastal kokkuvarisemise võimalus üks 16-st. Need koefitsiendid võivad meelitada kedagi hasartmängulaua taga istuma, kuid Citicorp Toweri taga asuvate arhitektide ja ehitusinseneride jaoks oli väljavaade sünge. Õnneks suutsid tehnikud hoone poltühendusi tugevdada. Katastroof õnnestus ära hoida.

Konstruktsiooniinsenerid teadsid, et Citicorp Tower puutub lõpuks vastu piisavalt tugeva tuulega, et kahjustada selle laagreid. Samamoodi teavad kogenud tarkvarainsenerid, et rakenduste jõudluse jälgimisest (APM) ja sündmuste haldamisest ei piisa süsteemi kaitsmiseks vältimatute servajuhtumite eest. Seda seetõttu, et staatilised süsteemid ilma masinõpe (ML) võimed ei suuda toime tulla ootamatute ja planeerimata uute olukordadega, näiteks tuultega. Ainult jälgimistööriistadele tuginedes peab inimadministraator vead dešifreerima ja intsidentide haldamise protsessi eskaleerima.

Keskmise taastumisaja (MTTR)/keskmise tuvastamisaja (MTTD) vähendamiseks peavad DevOpsi meeskonnad leppima äärejuhtumite suure tõenäosusega ja töötama iseõppivate lahenduste ennetava juurutamise nimel. See õppetund läheb kaugele, kuna ettenägelikkus on inseneritöös kriitilise tähtsusega.

2. õppetund: "Lennuki ehitamine lendamisel" loob lõputu tsükli

Traagilised sündmused on toonud kaasa mitmeid lennuajaloo olulisemad õppetunnid. Kui lennuk kannatas 1954. aastal lennu keskel tohutu dekompressiooni all ja kukkus alla, leidsid insenerid, et reisijate ruudukujulised aknad on tarbetu stressipunkt. edaspidi lennukid olid varustatud ümarate akendega. Tulekahjud pardal tõid kaasa uued istekohad, mis seadsid esikohale evakueerimise lihtsuse. Need muudatused on päästnud lugematu arv elusid.

Paljudes tööstusharudes, sealhulgas lennunduses, ei ole võimalik toodet ammendavalt stressitestida. Nagu varem mainitud, on servajuhtumid vältimatud. Siin on kõige olulisem see, et tarkvarainsenerid peavad end tutvustades arvestama oma süsteemi haavatavustega. Sealt edasi peavad nad nendega otstarbekalt tegelema. Selleks on vaja kahte asja: (1) õigete peamiste tulemusnäitajate (KPI) tuvastamine ja jälgimine ning (2) aja ja ressursside investeerimine asjakohastel mõõdikutel põhinevate süsteemide täiustamisse.

Keskmine insenerimeeskond investeerib 16–40 seirevahendisse, kuid neil jääb sageli märkamata, mille põhjal mõõdikud edu näitavad. Vähem kui 15% meeskondadest jälgib MTTD-d, seega jäävad nad vahele 66% juhtude elutsüklist. Ja üks neljandik meeskondadest teatab puuduvad oma teenusetaseme lepingud (SLA-d) hoolimata märkimisväärsetest investeeringutest saadavuse jälgimisse. See ütleb meile, et andmete kogumine vajab selle kärpimiseks põhjalikku ja süstemaatilist analüüsi – punktilahendustest enam ei piisa.

Tarkvarainsenerid, DevOpsi meeskonnad ja SRE-d peavad seadma prioriteediks protsessid ja tööriistad, mis eraldavad väärtust tohutul hulgal saadavuse kohta saadavast teabest. Selle asemel, et lihtsalt kriitilist viga jälgida, peavad nad võtma lehekülje lennuinseneri raamatust ja tegema kiiresti kriitilisi otsuseid. Selle tegemise saladus peitub AI-s.

3. õppetund: AI on isetervenevate süsteemide põhiline ehitusplokk

Täiesti autonoomne, täiuslikult toimiv iseparanev süsteem sobib ideaalselt igale tarkvarainsenerile. Süsteemid, mis parandavad end ise, on klientide rahulolu jaoks head, kuna need välistavad kuluka tarbija seisaku. Lisaks on need IT-teenuste halduse (ITSM) funktsioonide jaoks uskumatult kasulikud, kuna need vähendavad oluliselt vajadust tüütu piletihalduse järele. Sellise süsteemi loomiseks on vaja mitut komponenti, millest paljud on praegu kättesaamatud. Kuid me oleme isetervenevale reaalsusele lähemal, kui mõned võivad mõista.

AI laialdase kasutuselevõtu puudumine on endiselt suurim takistus, millega isetervenevad süsteemid praegu silmitsi seisavad. Kuigi paljud ettevõtted on kasutusele võtnud algelised AI- või ML-põhised tööriistad, on nende tööriistade terviklikkus küsitav. See tähendab, et paljud insenerid tegelevad tehisintellekt IT-toimingute jaoks (AIOps) tehnoloogiad, mis järgivad autonoomsete AI-algoritmide asemel reeglipõhist automatiseerimisloogikat. Erinevus võib tunduda väike, kuid praktikas on see erinevus kaotatud tootlikkuse tundide ja miljonite võimalike kahjude vahel.

Asi on selles, et reeglipõhised AIOps-i tööriistad analüüsivad erinevate punktilahenduste vahelisi koostoimeid ja võivad tõenäoliselt tuvastada levinud andmevead. Kuid automatiseerimisel põhinevad süsteemid ei suuda töödelda täiesti uute vigade arengut aja jooksul ega ennustada uudseid rikkeid andmetes. Seda seetõttu, et neid funktsioone kodeerivad inimadministraatorid paluvad süsteemil järgida kui see, siis see loogiline muster. Tõeliselt tõhusad AIOps-tööriistad leevendavad vigu, mis tekivad kõigis neljas klassikalises telemeetriapunktis – tuvastamisest kuni lahendamiseni –, klassifitseerides uued ja probleemsed mustrid enne, kui inimtehnikud nende olemasolust üldse teadlikud on. 

Kuni me ootame lähenev tehisintellekti kolmas laine, on see AIOps-i versioon kõige lähemal enesetervendamissüsteemidele. Huvitav on jälgida, kuidas praegused AIOps-i rakendused sulanduvad tehisintellekti tulevikku, mis hõlmab täielikult realiseeritud automatiseerimist ja sõltumatuid mõtlemisvõimalusi. Võib-olla lõikavad ka ehitusinsenerid tehisintellektil põhineva iseterveneva süsteemi hüvesid.

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• Platoblockchain. Web3 metaversiooni intelligentsus. Täiustatud teadmised. Juurdepääs siia.
• Allikas: https://www.dataversity.net/what-architecture-can-teach-us-about-self-healing-systems/