Ütemezett biztonsági mentések futtatása, sikerességük ellenőrzése és az eltérések jelzése: ez az egyik olyan feladat, amelynél a válasz elég közel jár az "igen"-hez. Nem azért, mert jelentéktelen munkáról van szó, hanem éppen azért, mert a munka annyira szigorúan meghatározott, hogy egy rendszer követni tudja a folyamatot anélkül, hogy útközben bármit is ki kellene találnia.
Egy biztonsági mentés ütemezés szerint fut, sikert vagy hibát jelez, és ennek a jelzésnek rögzített formája van. Ez magas fokú strukturáltságot eredményez: van egyértelmű kiváltó esemény, egyértelmű elvárt eredmény és egyértelmű kimenet, ha valami elromlik. Nincs szükség ügyfélkapcsolatra, fizikai beavatkozásra vagy kreatív hozzájárulásra — ez tisztán egy folyamat követéséről és egy eredmény felismeréséről szól. Egy backup-ágens felügyelheti az ütemtervet, kiolvashatja a naplókat, értelmezheti a státuszkódokat, és hiba esetén automatikusan továbbíthatja a jelzést a megfelelő személyhez vagy rendszerhez, hasonlóan ahhoz, ahogyan a rendszerteljesítmény monitorozása már nagyrészt automatizáltan zajlik.
A mennyiség szintén kedvező: egy átlagos IT-környezetben naponta vagy hetente tucatnyitól akár több százig terjedő biztonsági mentési feladat fut, szerverek, adatbázisok és munkaállomások között elosztva. Ez pontosan az a fajta ismétlődés, amelynél egy automatizált rendszer megmutatja az értékét — nem azért, mert okosabb egy rendszergazdánál, hanem mert soha nem hagy ki egy ellenőrzést időnyomás vagy fáradtság miatt.
Az oka annak, hogy ez nem egyértelmű "igen, teljesen automatikus", a hibaköltségekben rejlik. Egy elmulasztott vagy észrevétlen sikertelen biztonsági mentés csak akkor válik problémává, amikor adat vész el és helyreállításra van szükség — és akkor a kár gyakran már nem visszafordítható. Ez más nagyságrendű kockázat, mint egy tévesen besorolt e-mail vagy egy hibásan kitöltött mező a törzsadatokban. Ezért ehhez a feladathoz olyan feltétel tartozik, amely nem opcionális: automatizált monitorozás riasztással, és egy eszkalációs protokoll, amely rögzíti, ki és mennyi időn belül vizsgálja meg a hibajelzést. Az AI végezheti az ellenőrzést és a jelzést; de az ember felelős marad azért, ami akkor történik, amikor valami elromlik.
Ugyanezen okból alacsony a mérlegelési tér és a megfelelési pontszám. Egy éles adatbázis sikertelen biztonsági mentésénél kevés tér marad az értelmezésre — ez egy olyan üzemzavar, amelyet meg kell oldani, nem pedig olyan helyzet, amelyben egy rendszer maga döntheti el, mennyire súlyos a probléma. És olyan ágazatokban, ahol megőrzési kötelezettség vagy auditkötelezettség van érvényben, mint például a pénzügyi módosítások auditnaplójának vezetésénél, az is számít, hogy maga a biztonsági mentési szabályzat is részét képezheti egy ellenőrzési követelménynek. Ez nem változtat azon, amit az AI technikailag el tud végezni, de meghatározza, hogy végső soron ki áll jót a megfelelésért.
Egy olyan szervezetnél, amelynek néhány fájlszervere és áttekinthető biztonsági mentési ütemterve van, a feladat gyakorlatilag teljesen automatizálható: az ágens naponta ellenőrzi a státuszkódokat, összefoglalót küld, és csak hiba esetén eszkalál. A rendszergazda ekkor már nem fordít erre állandó időt, kivéve egy tényleges jelzés esetén.
Egy olyan szervezetnél, ahol sok különböző rendszer van, folyamatban lévő migrációk zajlanak, vagy ahol a biztonsági mentési szabályzat ügyfelenként eltér — mint például egy több megbízónak dolgozó IT-szolgáltatónál —, ez másképp alakul. Ott több értelmezésre van szükség arra vonatkozóan, hogy mit jelent pontosan egy "sikeres" biztonsági mentés az adott ügyfélszerződés szerint, és a feladat közelebb tolódik az emberi jóváhagyással történő felügyelethez.
Ami most változik, nem az, hogy a biztonsági mentéseket most ellenőrzik először — ez mindig is megtörtént. A különbség az, hogy az ellenőrzés már nem attól függ, hogy valaki reggel átolvassa-e a naplófájlt. A monitorozás folyamatosan fut, a jelzés magától érkezik, és a rendszergazda akkor kerül képbe, amikor valóban dönteni kell valamiről. Ezt a mintát — egy rendszer, amely felügyeli a rendszeres folyamatot, és egy ember, akit csak eltérés esetén vonnak be — viszontlátjuk a hibák felhasználók felé történő kommunikálásánál és az elsővonalas IT-incidensek megoldásánál is. Azoknál a vállalatoknál, ahol az IT-környezet egyszerű és stabil, ez az elmozdulás már messzemenően megvalósult. Azoknál a vállalatoknál, ahol összetett, összetett elemekből álló környezetek vannak — vagy az IT-n kívül, mint például az építőiparban, ahol a rendszerek és folyamatok kevésbé szabványosítottak —, ez lassabban megy, egyszerűen azért, mert még nincs meg az a struktúra, amelyre egy rendszernek szüksége van az ellenőrzéshez.
Ez nem létszámkérdés és nem állítás a munkakörökről. Itt kizárólag a feladatról van szó: a biztonsági mentések futtatásáról és ellenőrzéséről, függetlenül attól, hogy jelenleg ki végzi ezt a feladatot, vagy mennyi időt vesz igénybe egy adott szervezetben.
Hogy ez a feladat az Ön saját környezetében valóban nagyrészt átvehető-e, az a rendszerek számától, adatai hibaérzékenységétől és attól függ, hogy már van-e automatizált monitorozás és eszkalációs protokoll. Ahhoz, hogy erről első benyomást kapjon anélkül, hogy azonnal egy kiterjedt vizsgálatba kezdene, kitöltheti az ingyenes gyorstesztet: tizenkét kérdés, fiók nélkül, egy jelzéssel arról, hogy ebben a munkaprofilban az órák mekkora része vehető át már ma az AI által. A teljes munkafelmérés, amely vállalata munkáját feladatról feladatra térképezi fel, 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.