A rendszerek elérhetőségének és sebességének figyelése, és az eltérések jelzése még azelőtt, hogy a felhasználók ezt megtapasztalnák, egy olyan feladat, amely nagyrészt átvehető. Nem azért, mert az AI hirtelen ért az infrastruktúrához, hanem azért, mert a feladat maga már évek óta mérőértékek, küszöbértékek és ismétlődés köré van felépítve. Ez más következtetés, mint azoknál a feladatoknál, amelyeknek a lényege ítélőképesség vagy tárgyalás.
Három tengely a döntő itt: volumen, strukturáltság és hibaköltségek.
A volumen magas. A monitoring folyamatosan zajlik, éjjel-nappal, több száz vagy több ezer mérési ponton keresztül. Egy ember, aki ezt manuálisan követné, időközönként néz rá a dashboardokra, és lemarad arról, ami közben történik. Egy rendszer, amely minden másodpercben mér és összehasonlít egy küszöbértékkel, ezt nem hagyja ki.
A strukturáltság magas. A feladat ebből áll: mérés, összehasonlítás egy normával, és eltérés esetén jelzés leadása. Ez egy állandó eljárás, nem egy nyitott kérdés. Vessük ezt össze egy szoftverrel kapcsolatos felhasználói kérdés megválaszolásával, ahol a kérdés minden alkalommal máshogy van megfogalmazva, és kontextusra van szükség.
A hibaköltségek alacsonyak vagy közepesek. Egy elmulasztott vagy túl késői jelzés kellemetlen, de általában helyrehozható: a rendszer új figyelmeztetést küld, amint az eltérés tartósan fennáll, és a legtöbb küszöbérték biztonsági ráhagyással van beállítva. Ez másképp van egy olyan feladatnál, ahol egyetlen kihagyott lépés azonnal egy működő alkalmazás nélkül maradó felhasználót eredményez, mint például egy elsővonalbeli IT-incidens megoldásánál.
Két tengely fékezi le a képet: az ítélőképesség tere és a kreativitás rendre 2-es és 1-es értéken állnak.
Egy eltérés jelzése más, mint megérteni, mit jelent az eltérés a szervezet számára. A memóriahasználat egy csúcsa lehet ártalmatlan, vagy lehet egy olyan probléma kezdete, amely két óra múlva leállítja a webshopot. Ennek a jelentésnek a meghatározása, és a döntés arról, hogy eszkalálják-e egy beavatkozó mérnökhöz, emberi munka marad. Az AI jelzi az eltérést; egy, a környezetet ismerő személy ítéli meg, mit ér az eltérés.
Ez egyben az oka is annak, hogy ez a feladat nem áll önmagában. Annak a jelzésnek, amelyet egy monitoringeszköz ad ki, valahol le kell csapódnia: rögzített incidensként, a megfelelő sürgősségi szinttel. Hogy ez hogyan zajlik tovább, arról az IT-incidensek regisztrálása és priorizálása oldal ír, egy olyan feladat, amely valamivel kevésbé van szigorúan lezárva, mint a monitorozás maga.
A becslés: egy agent. Nem egy önálló script, amely egyetlen küszöbértéket ellenőriz, hanem egy rendszer, amely folyamatosan mér, több jelzést kombinál, és maga dönti el, hogy egy mintázat megér-e egy jelzést, mielőtt egy ember meglátná azt. Ez egy lépéssel több, mint a puszta riasztás, és egy lépéssel kevesebb, mint a teljes autonómia: az agent jelez és kategorizál, egy üzemeltető dönt arról, mi történjen a jelzéssel.
Két peremfeltétel határozza meg, hogy ez működik-e. Léteznie kell beállított küszöbértékeknek, amelyek illenek ahhoz, ami normális az adott specifikus rendszerek számára: egy küszöbérték, amely egy alkalmazásnál elég szigorú, egy másiknál folyamatosan téves riasztást válthat ki. És kell lennie automatizált riasztásnak, amely a jelzést valóban eljuttatja valakihez. E kettő nélkül nincs mit átvenni: nincs norma, amihez mérni lehetne, nincs csatorna, amin továbbadni lehetne.
Egy néhány szerverrel és fix nyitvatartási idővel dolgozó vállalatnál a monitoring gyakran még az időnkénti ránézés kérdése. Az automatizálás volumen-nyeresége ott korlátozott, egyszerűen azért, mert a volumen alacsony. Egy sok rendszerrel dolgozó vállalatnál, ahol az ügyfelek a nap bármely szakában elérhetőséget várnak, és ahol a múltban éjszaka keletkezett incidensek is előfordultak, más a kép: ott a folyamatos, automatizált felügyelettel felszabaduló fte-kapacitás gyorsan nő, mert az alternatíva egy állandó készenlétben álló ember.
A hibaköltségek tengelye is vállalatonként eltér. Egy belső tesztkörnyezetnél egy elmulasztott jelzésnek nincs következménye. Egy olyan rendszernél, amely közvetlenül fizetési forgalmat vagy egészségügyi adatokat érint, magasabb a megfelelőségi mérce, és ez a compliance tengelyt, amely itt már 4-es értéken áll, még tovább húzza a kötelező dokumentálás és a bizonyítható nyomon követés irányába.
Ez nem egy állítás a személyzetről. Hogy egy szervezet a felszabaduló kapacitást a rendszergazdánál másra fordítja-e, és hogyan, az a munkáltató választása, saját jogi követelményekkel ott, ahol ez a funkciókkal kapcsolatos döntéseket érinti. Ez az oldal csak a munkát írja le, nem azokat az embereket, akik ma azt végzik.
A monitoring ritkán elszigetelt feladat. Összefügg a biztonsági mentések végrehajtásával és ellenőrzésével, az incidenskezeléssel, és annak megtervezésével, hogy ki mikor legyen elérhető a nyomon követéshez. Aki szélesebb képet szeretne arról, mit vehet át az AI az IT-funkció egészében, kiindulópontot talál a munkáról és a tervezésről szóló oldalon.
Ez az oldal a feladat általános formájára épülő becslést ad. Hogy ez mennyit jelent egy konkrét vállalatnál, a rendszerek számától, a beállított küszöbértékektől és egy elmulasztott jelzés következményeitől függ. A saját helyzetre vonatkozó jelzés megszerezhető az ingyenes gyorsteszttel: tizenkét kérdés, fiók nélkül, jelzéssel arra, hogy ebben a profilban ma az órák mekkora része vehető át az AI által. A teljes munkateszt, amely egy egész vállalat munkáját feladatokra bontja szét, még fejlesztés alatt áll.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.