System övervaka på tillgänglighet och snabbhet, och avvikelser signalera innan användare drabbas av dem, är en uppgift som till stor del kan tas över. Inte för att AI plötsligt förstår infrastruktur, utan för att uppgiften själv sedan länge är uppbyggd kring mätvärden, tröskelvärden och upprepning. Det är en annan slutsats än vid uppgifter där bedömning eller förhandling utgör kärnan.
Tre axlar avgör här: volym, strukturering och felkostnader.
Volymen är hög. Övervakning pågår kontinuerligt, dag och natt, över hundratals eller tusentals mätpunkter. En människa som skulle hålla koll på det manuellt tittar med intervaller på dashboards och missar vad som händer däremellan. Ett system som mäter varje sekund och jämför med ett tröskelvärde missar inte det.
Struktureringen är hög. Uppgiften består av: mäta, jämföra med en norm, och vid avvikelse ge en signal. Det är en fast procedur, inget öppet frågeställning. Jämför det med att besvara en användarfråga om programvara, där frågan varje gång formuleras annorlunda och behöver kontext.
Felkostnaderna är låga till medelhöga. Ett missat eller för sent larm är besvärligt, men vanligtvis reparerbart: systemet skickar en ny varning så snart avvikelsen kvarstår, och de flesta tröskelvärden är inställda med marginal. Det skiljer sig från en uppgift där ett missat steg direkt resulterar i en användare utan fungerande applikation, som vid lösning av en förstalinjens IT-incident.
Två axlar bromsar bilden: bedömningsutrymme och kreativitet ligger på respektive 2 och 1.
Att signalera en avvikelse är något annat än att förstå vad den avvikelsen betyder för organisationen. En topp i minnesanvändning kan vara harmlös, eller början på ett problem som slår ut webbutiken om två timmar. Att avgöra den betydelsen, och beslutet att eskalera till en ingenjör som griper in, är fortfarande människors arbete. AI signalerar avvikelsen; en person med kunskap om miljön bedömer vad den avvikelsen är värd.
Det är också precis varför denna uppgift inte står för sig själv. Signalen som ett övervakningsverktyg avger måste hamna någonstans: som en registrerad incident med rätt urgens. Hur det går vidare beskrivs på IT-incidenter registrera och prioritera, en uppgift som är något mindre fast förankrad än övervakningen själv.
Bedömningen är: en agent. Inte ett löst skript som kontrollerar ett enda tröskelvärde, utan ett system som kontinuerligt mäter, kombinerar flera signaler, och själv avgör om ett mönster är värt ett larm innan en människa ser det. Det är ett steg längre än ren larmning, och ett steg tillbaka från full autonomi: agenten signalerar och kategoriserar, en administratör beslutar vad som ska göras med signalen.
Två randvillkor avgör om det fungerar. Det måste finnas inrättade tröskelvärden, anpassade till vad som är normalt för just dessa system: ett tröskelvärde som är tillräckligt strikt för en applikation kan för en annan slå falskt larm ständigt. Och det måste finnas automatiserad larmning som verkligen levererar signalen till någon. Utan dessa två finns ingenting att ta över: ingen norm att jämföra med, ingen kanal att vidarebefordra det genom.
Hos ett företag med ett par servrar och fasta kontorstider är övervakning ofta fortfarande en fråga om att titta till nu och då. Volymvinsten av automatisering är där begränsad, helt enkelt eftersom volymen är låg. Hos ett företag med många system, kunder som förväntar sig åtkomst dygnet runt, och en historia av incidenter som uppstått nattetid, ser bilden annorlunda ut: där ökar snabbt den fte-kapacitet som frigörs med kontinuerlig automatiserad bevakning, eftersom alternativet är en människa som permanent måste stå redo.
Även felkostnadsaxeln förskjuts per företag. Hos en intern testmiljö är ett missat larm utan konsekvenser. Hos ett system som direkt berör betalningstrafik eller medicinska uppgifter ligger compliance-ribban högre, och det trycker axeln compliance, som redan ligger på 4 här, ännu längre i riktning mot obligatorisk dokumentation och påvisbar uppföljning.
Detta är inget uttalande om personal. Om och hur en organisation använder den frigjorda kapaciteten hos en systemadministratör på annat sätt är ett val som arbetsgivaren gör, med egna lagstadgade krav där det berör beslut om funktioner. Denna sida beskriver enbart arbetet, inte de personer som utför det idag.
Övervakning är sällan en isolerad uppgift. Den hänger samman med utföra och kontrollera säkerhetskopior, med incidenthantering, och med planeringen av vem som ska vara tillgänglig för uppföljning och när. Den som vill ha en bredare bild av vad AI kan ta över inom IT-funktionen som helhet hittar en utgångspunkt på sidan om arbete och planering.
Denna sida ger en bedömning utifrån uppgiften i allmän form. Hur mycket detta betyder för ett specifikt företag beror på antalet system, de inrättade tröskelvärdena och konsekvenserna av ett missat larm. En indikation för den egna situationen kan fås med den kostnadsfria snabbanalysen: tolv frågor, utan konto, med en indikation om vilken andel av timmarna inom denna profil som idag kan tas över av AI. Den fullständiga arbetsanalysen, som bryter ner arbetet i ett helt företag i uppgifter, är fortfarande under uppbyggnad.
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.