Mit taníthat nekünk az építészet az öngyógyító rendszerekről?

Újra kiadta Platón

Követő: 0

A DevOps csapatai és a webhely megbízhatósági mérnökei (SRE) naponta foglalkoznak a kóddal. Ez megtanítja őket arra, hogy alaposan megvizsgálják világukat, okos megfigyeléseket végezzenek, és váratlan összefüggéseket vonjanak le. Végül is, bár rendkívül logikus és matematikai jellegű, a szoftverfejlesztés, legalábbis részben, művészeti forma.

Nem győzi meg ez a kijelentés? Fontolja meg a párhuzamot a történelem legfigyelemreméltóbb építészeti bravúrjai és a modern szoftverfejlesztés között. Találó összehasonlítás: a szoftverfejlesztéshez hasonlóan az építészet is összetett matematikai számításokat alkalmaz, hogy valami szépet hozzon létre. És mindkét tudományágban egy kis tévedés jelentős következményekkel járhat. Lenyűgöző módon sok híres építészeti hiba analóg a kódban talált problémákkal.

Ne feledje, az ihlet mindenhol ott van – mindaddig, amíg tudja, hol keresse. Íme néhány lecke, amelyet a szoftvermérnökök megtanulhatnak az évszázadok során átívelő építészeti epifániákból, különös tekintettel az öngyógyító rendszerek jövőjére.

1. lecke: Az Edge esetek mindig kihasználják a rendszer sebezhetőségeit

A Citicorp Tower – mai nevén 601 Lexington – építését 1977-ben fejezték be New Yorkban, és ekkor a világ hetedik legmagasabb épülete volt. A felhőkarcoló legmodernebb kialakítása három több mint 100 láb magas gólyalábat tartalmazott. Csoda volt a befejezése. Egy egyetemi hallgató azonban hamarosan felfedezett valami borzasztót: Erős szél veszélyeztetheti az épület épségét. Konkrétan, ha erős szelek csapnak be a Citicorp Tower sarkaiba, az építmény összeomlott – szó szerint éltok.

A toronynak minden évben egy a 16-hoz volt az esélye, hogy összedőljön. Ezek az esélyek csalogathatnak valakit, aki egy játékasztalnál ül, de a kilátások komorak voltak a Citicorp Tower mögött álló építészek és szerkezetmérnökök számára. Szerencsére a szakemberek meg tudták erősíteni az épület csavarkötéseit. A katasztrófát elkerülték.

A szerkezetmérnökök tudták, hogy a Citicorp Tower-nek végül elég erős széllel kell szembenéznie ahhoz, hogy veszélybe sodorja a csapágyait. Hasonlóképpen, a tapasztalt szoftvermérnökök tudják, hogy a robusztus alkalmazásteljesítmény-figyelés (APM) és az eseménykezelés nem elegendő ahhoz, hogy megvédje a rendszert az elkerülhetetlen szélsőséges esetektől. Ez azért van, mert statikus rendszerek nélkül gépi tanulás (ML) A képességek nem képesek kezelni a váratlan és nem tervezett új helyzeteket, mint például a negyedszelek. Ha kizárólag a megfigyelő eszközökre támaszkodik, az emberi adminisztrátornak meg kell fejtenie a hibákat, és fokoznia kell az incidenskezelési folyamatot.

Az átlagos helyreállítási idő (MTTR)/átlagos észlelési idő (MTTD) csökkentése érdekében a DevOps csapatoknak el kell fogadniuk a szélső esetek nagy valószínűségét, és az öntanuló megoldások megelőző bevezetésén kell dolgozniuk. Ez a lecke messzire vezet, mivel az előrelátás kritikus fontosságú a mérnöki munkában.

2. lecke: „A repülőgép megépítése repülés közben” egy véget nem érő körforgást hoz létre

A tragikus események több ilyet hoztak a repüléstörténet legfontosabb tanulságai. Amikor 1954-ben egy repülőgép repülés közben hatalmas dekompressziós nyomást szenvedett, és lezuhant, a mérnökök megállapították, hogy a négyzet alakú utasablak szükségtelen stresszpontot jelent. Ezentúl, a repülőket lekerekített ablakokkal szerelték fel. A fedélzeti tüzek új üléselrendezésekhez vezettek, amelyek a könnyebb evakuálást helyezték előtérbe. Ezek a változások számtalan életet mentettek meg.

Sok iparágban – beleértve a repülést is – nincs mód egy termék teljes körű stressztesztjére. Mint korábban említettük, az éles esetek elkerülhetetlenek. A legnagyobb előny itt az, hogy a szoftvermérnököknek figyelniük kell rendszerük sebezhetőségére, amikor bemutatják magukat. Innentől kezdve célszerűen meg kell szólítaniuk őket. Ehhez két dologra van szükség: (1) a megfelelő kulcsfontosságú teljesítménymutatók (KPI-k) azonosítása és követése, valamint (2) idő és erőforrások befektetése a rendszerek megfelelő mérőszámok alapján történő fejlesztésébe.

Az átlagos mérnökcsapat 16-40 megfigyelőeszközbe fektet be, ennek ellenére gyakran elmulasztják azt a határt, amelyen a mérőszámok sikert mutatnak. A csapatok kevesebb mint 15%-a követi nyomon az MTTD-t, így az incidensek életciklusának 66%-át kihagyják. És a csapatok egynegyede számol be hiányzik a szolgáltatási szintre vonatkozó szerződése (SLA) a rendelkezésre állás nyomon követésére fordított jelentős beruházás ellenére. Ez azt jelzi, hogy az adatgyűjtés alapos, szisztematikus elemzést igényel annak csökkentéséhez – a pontszerű megoldások már nem elegendőek.

A szoftvermérnököknek, a DevOps-csapatoknak és az SRE-knek előnyben kell részesíteniük azokat a folyamatokat és eszközöket, amelyek értéket vonnak ki a rendelkezésre állásra vonatkozó hatalmas mennyiségű információból. Ahelyett, hogy egyszerűen csak megfigyelnének egy kritikus hibát, elő kell venniük egy oldalt egy repülőmérnök könyvéből, és gyorsan kritikus döntéseket kell hozniuk. Ennek titka az AI-ban rejlik.

3. lecke: A mesterséges intelligencia az öngyógyító rendszerek alapvető építőköve

Egy teljesen autonóm, tökéletesen működő, öngyógyító rendszer ideális minden szoftvermérnök számára. Az önmagukat javító rendszerek jót tesznek a vevői elégedettségnek, mivel kiküszöbölik a költséges, fogyasztói állásidőt. Sőt, hihetetlenül előnyösek az IT-szolgáltatásmenedzsment (ITSM) funkciókhoz, mivel jelentősen csökkentik az unalmas jegykezelés szükségességét. Egy ilyen rendszer felépítéséhez több összetevőre van szükség, amelyek közül sok jelenleg elérhetetlen. De közelebb vagyunk az öngyógyító valósághoz, mint azt egyesek gondolnák.

A mesterséges intelligencia széles körű elterjedésének hiánya továbbra is az öngyógyító rendszerek legnagyobb akadálya. Bár sok vállalkozás kezdetleges AI- vagy ML-alapú eszközöket alkalmazott, ezeknek az eszközöknek a sértetlensége megkérdőjelezhető. Vagyis sok mérnök foglalkozik mesterséges intelligencia az informatikai műveletekhez (AIOps) technológiák, amelyek szabályalapú automatizálási logikát követnek az autonóm AI-algoritmusok helyett. A különbségtétel aprónak tűnhet, de a gyakorlatban ez a különbség a termelékenységkiesés órák és a lehetséges veszteségek milliói között.

A helyzet az, hogy a szabályokon alapuló AIOps eszközök elemzik a különböző pontmegoldások közötti interakciókat, és valószínűleg azonosítani tudják a gyakori adathibákat. Az automatizáláson alapuló rendszerek azonban nem tudják feldolgozni a teljesen új hibák időbeli alakulását, és nem tudják előre jelezni az adatok újszerű működési zavarait sem. Ennek az az oka, hogy az ezeket a funkciókat kódoló emberi rendszergazdák arra kérik a rendszert, hogy kövesse a ha ez, akkor az logikai minta. A valóban hatékony AIOps eszközök csökkentik a mind a négy klasszikus telemetriai ponton – az észleléstől a felbontásig – előforduló hibákat azáltal, hogy osztályozzák az új és problémás mintákat, még mielőtt a technikusok tudomást szereznének létezésükről.

Amíg várunk a a mesterséges intelligencia közelgő harmadik hulláma, az AIOps ezen verziója áll a legközelebb az öngyógyító rendszerekhez. Érdekes lesz nyomon követni, hogy a jelenlegi AIOps-alkalmazások hogyan válnak bele a mesterséges intelligencia jövőjébe, amely magában foglalja a teljesen megvalósított automatizálást és a független gondolkodási lehetőségeket. Talán akkor a szerkezetmérnökök is learatják az AI-alapú, öngyógyító rendszer jutalmát.