Milyen problémát old meg az AIOps a DevOps-ban, amikor a kódból végrehajtott változtatások gyorsabban haladnak, mint ahogy az emberi felülvizsgálat lépést tud tartani velük?
Ez a megfelelő kiindulópont, mert a modern szállítási folyamatok kis, rejtett módokon is megbukhatnak. Egy új könyvtárverzió, egy hibás konfigurációs fájl vagy egy gyenge függőség átcsúszhat a normál ellenőrzéseken, és később lassú fordításként, sérült kiadásaként vagy biztonsági réseként jelentkezhet.
Az AIOps gépi tanulást visz be ebbe a folyamatba. Figyeli azokat a jeleket, amelyeket a folyamat már létrehoz, összehasonlítja őket a múltbeli mintázatokkal, és jelzi, mi tűnik szokatlasznak, mielőtt a probléma elterjedne.
Miért van szüksége a DevOps-nak egy okosabb monitorra
A DevOps csapatok már használják a teszteket, naplókat, riasztásokat és telepítési szkripteket. A probléma a mennyiség. Több szolgáltatás, több kódpálya, több változás és több jel van, mint amennyit egy ember kézileg jól átnézne.
Itt illeszkedik be az AIOps. Nem helyettesíti a folyamatot. Helyette nagy méretben olvassa a folyamatot, és olyan mintázatokat keres, amelyek nehezen láthatók egy zajos irányítópultban.
Az AIOps észrevehet hiányzó kódot, furcsa kódot, gyenge függőségeket, rossz konfigurációt és egyéb hibákat, amelyeket az alapautomatizálás figyelmen kívül hagyhat. Azt is jelölheti a nem szükséges kódot vagy azt, amely kockázatot növelő módon íródott.
Az érték a detektálás sebessége. Minél korábban találják meg egy problémát, annál kevesebb ideje van arra, hogy érintse a termelési rendszereket, a naplókat, a ügyfeleket vagy a biztonsági szabályozásokat.
Hogyan működik a mintázat
A mintázat alakja egyszerű, még ha a szoftvereszközök bonyolultak is.
A kód forrástárolóban él. A fordítások és tesztek egy CI/CD folyamaton futnak keresztül. A naplók és események útközben gyűlnek össze. Az AIOps eszközök tanulmányozzák ezt az adatfolyamot, és megtanulják, hogyan néz ki a normális állapot.
Ezután összehasonlítják az új változtatásokat a régebbi viselkedéssel. Ha egy commit gyanús módon változtatja meg a kódszerkezetet, a futási viselkedést vagy a telepítési mintázatokat, a rendszer figyelmeztetést adhat ki vagy cselekvést indíthat.
Ezért olyan fontos az adat. Az AIOps hasznos múltra támaszkodik. Forráskódból, folyamat-eseményekből, teszt-kimenetekből, telepítési naplókból és korábbi incidensekből tanul. Enélkül az adatnál alig van mit összehasonlítania.
Ennek a mintázatnak az üzleti verziója vezérlést is igényel. A csapatoknak hozzáféréssel kell rendelkezniük a tárolóhoz, egy adattárral a modellképzéshez, és olyan folyamatokkal, amelyek képesek meghívni az AI-ellenőrzéseket a megfelelő szakaszban. A cél nem egy ügyes mellékes eszköz. A cél egy olyan folyamat, amely az AI-t a normál áramlás részeként használja.
Egy kis példa
Képzeljünk el egy kiadást, amely hozzáad egy új fizetési szolgáltatást és frissít egy konténerek képét. A kód jónak tűnik a felülvizsgálat során, és az egységtesztek sikeresek. De az új szolgáltatás egy váratlan függőséget használ, és egy konfigurációs érték megváltoztatja a konténer indulási módját.
Az AIOps néhány módon észreveheti ezt a eltérést. Észreveheti a függőségi hézagot. Láthatja, hogy az indulási viselkedés már nem illeszkedik a ismert mintázathoz. Jelölheti a változást, mert a hasonló kód a múltban hibát okozott tesztelés vagy pródaüzem során.
Ez a figyelmeztetés lehetőséget ad a csapatnak arra, hogy megnézze a dolgot, mielőtt a kiadás elérné a termelést. A javítás lehet kicsi, például egy hiányzó csomag visszaállítása vagy egy konfigurációs fájl javítása. A fontos rész az, hogy a probléma korán megjelenjen, miközben a változtatás még olcsón javítható.
A biztonságos javítások ugyanazt a folyamat-diszciplínát igénylik
Az AIOps-ről gyakran beszélnek műveleti eszközként, de a biztonság ugyanannak a történetnek a része. Egy gyenge könyvtár, egy kockázatos kódmintázat vagy egy rossz telepítési beállítás gyorsan biztonsági problémává válhat.
Néhány eszköz a kód-felülvizsgálatra fókuszál. Mások a futási viselkedést vizsgálják. Vannak olyanok, amelyek úgy épültek fel, hogy a infrastruktúra egészségét figyeljék naplók és metrikák segítségével. Együtt ezek segítik a csapatokat abban, hogy mind hibákat, mind sebezhetőségeket észrevegyenek.
A gyakorlatban ez azt jelenti, hogy a folyamat kockázatsűrűvé válik. A felülvizsgálati lépés jelölhetetlen veszélyes kódmintázatokat. A futási lépés észreveheti a hatékonyság hiányát vagy a szokatlan viselkedést. Az infrastruktúra lépés érzékelhet anomáliákat az olyan rendszerekben, amelyek a felszínen egészségesnek tűnnek, de rossz irányba térnek el.
Ez egy gyakorlati nyereség azoknak a csapatoknak, amelyek gyakran mozognak. A gyors kiadási ciklusok nem hagynak sok helyet a lassú, utólagos emberi ellenőrzésnek.
Amit az AIOps megváltoztat az üzleti szállításban
Az AIOps akkor működik a legjobban, ha a stack többi része erre kész. A felhő-native rendszerek segítenek, mert a konténerek és a Kubernetes könnyebbé teszi modellek tesztelését, csomagolását és telepítését az alkalmazás többi áramlásával együtt.
Ez megváltoztatja azt is, ahogyan a csapatok az adatokról gondolnak. A naplók, tesztek és telepítési rekordok nem maradnak hátra. Képzési anyagokká és üzemeltetési bizonyítékká válnak. Ha az adatok silókra vannak osztva, vagy rosszul kategorizálva, a modellnek kevesebb tanuló anyaga és kevésbé megbízható adata van.
Ezért számít az üzleti készenlét. Az adatcsapatoknak, a DevOps mérnököknek és az alkalmazástulajdonosoknak mind van szerepük. Az egyik csoport tudja, hol vannak a jelek. A másik tudja, hogyan viselkedik a folyamat. A harmadik tudja, hogyan néz ki egy valódi hiba.
Az üzlet szolgáltatási oldala is megváltozik. Az incidens- és változásmenedzsment csapatoknak meg kell érteniük, miért kapcsolt fel egy riasztás, és milyen típusú automatikus válasz engedélyezett. Itt veszélyes a biztos illúziója. A lényeg a jobb átláthatóság és a gyorsabb felülvizsgálat, nem a vak bizalom egy modellben.
A gyakorlati tanulság
Az AIOps akkor hozza a legjobb eredményt, ha a DevOps rendszer részeként kezelik, nem pedig külön rétegként. A tároló-adatból, folyamat-eseményekből, naplókból és régi incidensekből tanul. Ellenőrzi a hiányzó kódot, a rossz konfigurációt, a gyenge függőségeket és a szokatlan viselkedést. Ezután segíthet a csapatoknak hamarabb áttérni a detektálásról a javításra.
Az EuroOp LLC ezt egy alkalmazott K+F mintázatnak tekinti egyértelmű üzleti formával: tegye okosabbá a folyamatot ott, ahol a munka már történik. Ez az a fajta mérnöki diszciplína, amelyet az EuroOp Insights tükrözni hivatott, egyetlen gyakorlati tanulsággal az EuroOp termékei mögötti folyamatból.