Machine Learning in Operation – Processer

Seriens inlägg enligt nedan:

• Del 1, Introduktion till Maskininlärning och proaktiv drift
• Del 2, Kultur, förhållningsätt
• Del 3, Processer, arbetssätt
• Del 4, Data, både in och ut-data
• Del 5, Verktyg och exempel

I de tidigare inläggen( MachineLearning och ML – kultur) har vi gjort en introduktion till Artificiell Intelligens (AI) och Maskininlärning (ML) och hur detta kan relatera till den driftkultur du har. I detta inlägg fokuserar vi på hur man kan tänka på proaktiva larm (Event) i förhållande till de vanligaste operativa processerna inom ITIL.

För att vara tydlig så stödjer redan ramverket ITIL ett proaktivt arbetssätt. Många mognas analyser innehåller redan detta som ett tydligt mål.
Här tittar vi inte på hela ITIL utan på vilka processer som rent praktiskt bör ses över då vi utgår från att de flesta har en reaktiv implementation och i bästa fall jobbar proaktivt i Problem processen med analys av ofta förekommande incidenter. Vilket i detta perspektiv väl snarast är att betrakta som reaktivt då det baserar sig på fel som redan har inträffat.

När jag skriver ITIL tänker jag inte bli för detaljerad eller följa ITILs dokumentation till punkt och pricka. Är det något jag sett så är det att alla organisationer har sin egen vinkling av ITIL.

Några frågor man bör ställa sig när det kommer till Proaktiv information från ML är:

• Vilken Process äger intresset av proaktiv operation?
• Är något som inte hänt än, en incident?
• Hur relaterar detta till proaktiv Problem Management?
• Change Management integration
• Hur bedriver man Capacity Management om ingen är påverkad?

Jag påstår att den process som är drivande, eller borde vara det, bakom inte bara proaktiv drift utan i princip alla processer inom drift är Availability Management.
Att jobba för att tillgänglighet upprätthålls på bästa sätt.

Varför kan detta vara viktigt?

Då Incident processen oftast är fokuserad på att återställa funktion när avbrott inträffar kan det vara svårt att få uppmärksamhet och framdrift för händelser som kanske resulterar i avbrott. Att då rapportera till en annan process kan ge balans och medvetenhet.
Det kanske enklaste och snabbaste vägen till denna relation är att säkerställa att rapporter för alla proaktiva åtgärder tas med i Availability rapporteringen. Precis som tidigare när vi pratade om att ändra kultur är det avgörande även i processarbetet att både följa upp och synliggöra det proaktiva arbetet.

Den kanske mest praktiska frågan i förhållandet mellan proaktiv operation och ITIL är:
Är en varning, en ’Early Warning’ om ett eventuellt avbrott en Incident?
Här har jag, något förenklat, stött på två olika förhållningssätt. Antingen är en Incident att betrakta som arbetsorder. Någon blir tilldelad en, ofta akut, uppgift. Eller så har man en mer stringent tolkning. Incidenter gäller bara saker som inte längre fungerar som avsett.

I vilket fall som helst behöver Ni bestämma vad som gäller hos just Er. Hur tilldelar vi en resurs att lösa, mitigera, situationen innan den riskerar att skapa störningar för kunden eller användarna.

Några alternativ:

• (A) Ingen skillnad, för varningar som incidenter
  Viktigt att komma ihåg är att du fortfarande vill kunna separera på reaktiva och proaktiva incidenter i din rapportering.
• (B) Om ditt ServiceDesk verktyg tillåter det. Skapa en egen klass av incidenter.
  Detta borde göra att du tydligt kan rapportera och följa upp både reaktiva och proaktiva Incidenter.
• (C) Lägg varningar som Request istället för Incidenter.
  Här kan utmaningen vara att Request ofta har betydligt längre åtgärdstider än Incidenter. Säkerställ att mottagande organisation förstår och agerar enligt överenskommelse.
• (D) Detta kanske är det som ITIL kommer närmast i sin beskrivning men precis som med Requests finns det stor risk att den befintliga Problem processen är för långsam och fokuserad på Incident analys.

Om möjligheten finns förespråkar vi det andra alternativet, B). Anledningen är att då kommer de proaktiva larmen/varningarna att hamna i samma processflöde som de reaktiva. Som vi beskrev i tidigare inlägg är det avgörande att inte separera dessa flöden då bägge behöver belysas och följas upp på likvärdigt sätt.

Change Processen

Det ligger i Maskininlärningens natur att historiken bestämmer hur framtiden tolkas. För att få bästa möjliga resultat är det viktigt att din ML lösning inte lär sig att tolka framtiden baserat på onormala omständigheter. Till exempel som när du gör en uppdatering eller större förändring i din miljö.
Här blir det avgörande att förse ditt system med kunskap om de Change som utförs på miljön. Att automatiskt koppla ihop systemet så att medans ett system är i Mantanence sker två saker.
Det ena är att de larm, om de onormala beteendena, inte blir incidenter och det andra är att undanta den data som kommer in till ML-systemet under denna tid inte används för att förändra dina algoritmer genom inlärning.
Det effektivaste är du kan automatisera detta via Change Management men ett alternativ är att se till att åtminstone din underhållskalender undantas från inlärning.

Capacity Management

Beroende på vilken mognadsnivå man har nått kring kapacitetsplanering (Capacity Management) kommer ditt ML system att påverka eller påverkas av denna process.
Det är vanligt att denna process är driven med ganska låg frekvens. Kanske en gång i månaden men å andra sidan finns ofta kopplingen till investeringar och ökande av kapacitet på plats.

Då ML larm ofta handlar om kapacitet, nya beteenden i dina system driver behovet av ytterligare kapacitet för att upprätthålla prestanda så behöver ett beslut tas om det är denna process som skall ha mandat om utökad kapacitet eller om de är mottagare av information om de åtgärder som är utförda inom ramen för till exempel Incident processen.

Oavsett vilken väg ni går så säkerställ att det finns förankring mellan tjänsteägare, processer och drift om att vara proaktiv kan betyda att investeringar kan behöva göras utan att kunden har märkt av problemen.

Utan tvekan är det här den största utmaningen ligger efter kulturförändringen som vi tittade på i föregående artikel.

Det är här som Ni eller kanske främst tjänsteägarna behöver sätta upp krav på sin egen tjänst. Att ikläda sig kundens perspektiv och sätta vilka egna krav man har för att säkerställa att den proaktiva driften åtgärdar vad som är viktigt men samtidigt inte går för långt.

Vilket leder oss in på nästa område, data-kvalitet …

Slutligen, tveka inte att höra av dig om du vill veta mer!