Monitorizarea sistemelor pentru disponibilitate și viteză, și semnalarea abaterilor înainte ca utilizatorii să fie afectați de ele, este o sarcină care poate fi preluată în mare parte. Nu pentru că AI ar avea deodată cunoștințe de infrastructură, ci pentru că sarcina în sine este de ani de zile construită în jurul unor valori de măsurare, praguri și repetiție. Este o concluzie diferită față de sarcinile în care judecata sau negocierea constituie nucleul.
Trei axe sunt decisive aici: volumul, gradul de structurare și costurile erorilor.
Volumul este ridicat. Monitorizarea rulează continuu, zi și noapte, pe sute sau mii de puncte de măsurare. Un om care ar urmări asta manual se uită la intervale la tablourile de bord și ratează ce se întâmplă între timp. Un sistem care măsoară în fiecare secundă și compară cu o valoare de prag nu ratează asta.
Gradul de structurare este ridicat. Sarcina constă în: măsurare, comparare cu o normă, și emiterea unui semnal în caz de abatere. Este o procedură fixă, nu o problemă deschisă. Comparați asta cu răspunsul la o întrebare a utilizatorului despre software, unde întrebarea este formulată diferit de fiecare dată și necesită context.
Costurile erorilor sunt de la scăzute la medii. O notificare ratată sau întârziată este neplăcută, dar de regulă recuperabilă: sistemul trimite o nouă avertizare de îndată ce abaterea persistă, și majoritatea valorilor de prag sunt stabilite cu o marjă. Aceasta este diferit de o sarcină în care un singur pas ratat produce imediat un utilizator fără o aplicație funcțională, cum este cazul la rezolvarea unui incident IT de primă linie.
Două axe frânează imaginea: marja de judecată și creativitatea se situează la 2, respectiv 1.
Semnalarea unei abateri este altceva decât înțelegerea a ceea ce înseamnă acea abatere pentru organizație. Un vârf în utilizarea memoriei poate fi inofensiv, sau poate fi începutul unei probleme care va bloca magazinul online peste două ore. Determinarea acestei semnificații, și decizia de a escalada către un inginer care intervine, rămâne muncă umană. AI semnalează abaterea; o persoană cu cunoștințe despre mediul respectiv evaluează cât de important este semnalul respectiv.
Aceasta este exact motivul pentru care această sarcină nu stă izolată. Semnalul emis de un instrument de monitorizare trebuie să ajungă undeva: ca incident înregistrat, cu urgența corectă. Modul în care continuă acest proces este descris la înregistrarea și prioritizarea incidentelor IT, o sarcină care este puțin mai puțin bine definită decât monitorizarea propriu-zisă.
Estimarea este: un agent. Nu un script separat care verifică o singură valoare de prag, ci un sistem care măsoară continuu, combină mai multe semnale, și decide singur dacă un model merită o notificare înainte ca un om să o vadă. Acesta este un pas mai avansat decât simpla alertare, și un pas înapoi față de autonomia completă: agentul semnalează și categorizează, un administrator decide ce se face cu semnalul.
Două condiții determină dacă acest lucru funcționează. Trebuie să existe valori de prag configurate, adaptate la ceea ce este normal pentru sistemele respective specifice: un prag suficient de strict pentru o aplicație poate declanșa alarme false constante pentru alta. Și trebuie să existe alertare automatizată care să livreze efectiv semnalul cuiva. Fără aceste două elemente, nu există nimic de preluat: nicio normă la care să se raporteze, niciun canal prin care să se transmită.
Într-o companie cu câteva servere și un program fix de birou, monitorizarea este de multe ori încă o chestiune de verificare ocazională. Câștigul de volum al automatizării este atunci limitat, pur și simplu pentru că volumul este scăzut. Într-o companie cu multe sisteme, clienți care se așteaptă la acces în orice moment al zilei, și un istoric de incidente apărute noaptea, imaginea este diferită: acolo, capacitatea în fte care se eliberează prin supravegherea automatizată continuă crește rapid, pentru că alternativa este un om care trebuie să fie permanent în stare de veghe.
Și axa costurilor erorilor variază de la companie la companie. Într-un mediu de testare intern, o notificare ratată nu are consecințe. Într-un sistem care afectează direct plățile sau datele medicale, ștacheta de conformitate este mai ridicată, iar acest lucru împinge axa conformității, care se situează deja la 4 aici, și mai mult în direcția înregistrării obligatorii și a urmăririi demonstrabile.
Acesta nu este un enunț despre personal. Dacă și cum o organizație utilizează în alt mod capacitatea eliberată a unui administrator de sistem este o alegere a angajatorului, cu propriile cerințe legale în măsura în care aceasta afectează deciziile privind funcțiile. Această pagină descrie doar activitatea, nu persoanele care o desfășoară în prezent.
Monitorizarea este rareori o sarcină izolată. Este legată de efectuarea și verificarea copiilor de siguranță, de gestionarea incidentelor, și de planificarea privind cine trebuie să fie disponibil și când pentru urmărire. Cei care doresc o imagine mai amplă despre ce poate prelua AI în funcția IT ca întreg găsesc un punct de plecare la pagina despre muncă și planificare.
Această pagină oferă o estimare pe baza sarcinii în formă generală. Cât înseamnă asta pentru o companie specifică depinde de numărul de sisteme, valorile de prag configurate și consecințele unei notificări ratate. O indicație pentru situația proprie poate fi obținută cu quickscan-ul gratuit: douăsprezece întrebări, fără cont, cu o indicație privind partea din ore din acest profil care poate fi preluată astăzi de AI. Scanul complet al activității, care detaliază munca unei întregi companii pe sarcini, este încă în construcție.
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.