Machine Learning in Operation – Kultur

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

Artificiell Intelligens (AI) och Maskininlärning (ML) är omfattande områden. Här fokuserar vi på hur man kommer igång med detta inom drift eller mer specifikt IT Operation.

Vi på Compose IT har hunnit samla på oss en del erfarenhet kring detta och tillsammans med våra år med driftorganisationer och verktyg ser vi några exempel på hur man kan få en lyckad implementation och framför allt få ut ett värde av investerad tid och resurser.

Så, hur gör man då?

Är det bara att köpa ett nytt verktyg eller maskininlärlingslicens till det jag verktyg jag redan har? Och sen är saken klar?

Tyvärr möter vi den inställningen från många av verktygsmakarna.
–Det är bara att slå på AI eller ML och sedan kör du ’AIOps’, Hepp!

Ja, man önskar att det vore så enkelt. Som jag nämnde i föregående inlägg (Läs här) finns det en del utmaningar man behöver adressera för att lyckas få ut nyttan av ML. Utmaningen är inte tekniken, även om man ska vara medveten även i valet av lösning så är det främst förtroende för den information som ett ML systemet ger samt förändringen av processer och kultur som vi sett som de största utmaningarna för ett lyckat projekt.

Att förändra sin driftorganisation till att prioritera proaktivt arbete lika mycket som traditionell incidenthantering betyder att både sättet man jobbar och inställningen hos de som jobbar där behöver förändras.

De områden som du behöver vara uppmärksam på för att lyckas är de klassiska, människor, processer och verktyg med tillägget data-kvalitet.

Nej, nej, sluta inte läsa här. Det är inte ett oändligt data-kvalitets-projekt som behövs men en viss medvetenhet om att det data man stoppar in kommer få en konsekvens i vad man kan få ut behövs. Det finns flera lösningar på detta och ambitionsnivån kan bara Du sätta.
Vi kommer tillbaka till det lite senare.

Det viktigaste först, kultur. Om ingen agerar på den information som ML ger spelar det ingen roll vad du investerar i.
I senare inlägg tittar vi på Processer, främst i förhållande till ITIL, datakvalitet och avslutar med verktyg!

Kultur (Människor)

Låt mig beskriva ett scenario för att kunna beskriva vad jag menar med kultur, vilken utmaning det ger och hur man kan lösa det.

– Ni får in två olika larm i ert Operation Center.

• (A) En Server larmar om att minnesutnyttjandet är högre än det brukar.
  Servern tillhör ett viktigt system och är i produktion. Inga pågående Change finns dokumenterade på detta CI. Så det är ett riktigt larm.
• (B) En Server larmar om att disken är helt full och följdfel visar att den är i princip obrukbar.
  Servern är en del av ett system och är i produktion. Inga Change finns dokumenterade på detta CI. Detta är också ett riktigt larm.

Vilket larm ska driften hantera?

Det givna svaret är att prioritera det som är trasigt, B) Den fulla disken.
Medan detta håller på att åtgärdas kommer det in att annat larm. En Switch har gått ner, sedan en Databas som låst sig och sedan en Server som inte är nåbar och så vidare.

Efter några timmar ringer plötsligt försäljningschefen och är upprörd, han har fått höra att hans favoritkund inte kunde lägga en order för att er portal var så seg att han gick till en konkurrent!

Det visar sig att minnet i Server A) inte längre räckte för att det skulle vara bra svarstider i portalen. Ni hade informationen om detta för flera timmar sedan.
Så var det rätt val?

Scenariot ovan är både tillspetsat och förenklat men faktum kvarstår. Hur prioriterar du mellan något som inte har hänt än och kanske inte händer och något som redan har hänt?

Svaret är: Det gör du inte, du prioriterar vad som är viktigt över det som är mindre viktigt.

I exemplet vet vi att det första systemet är viktigt medan det andra är det inte.
Missade du det? Jag beskrev det något otydligt men det står i beskrivningen av de två olika larmen.
Detta är något vi ser ofta i verkligheten. Att information om hur viktigt ett system är eller om det finns något relaterat SLA:er ofta inte finns tillgängligt vid prioritering av larm. Att berika dina larm med denna information blir än viktigare i en proaktiv drift för att kunna prioritera viktigt mot mindre viktigt. Inte avbrott mot allt annat.
Vi kunde alltså undvika avbrott i det viktiga systemet på bekostnad av en något längre nedtid i det mindre viktiga systemet. Enkelt?

Ok, så vad är utmaningen?

Uppmärksamhet!

Man vill inte att någon ska ringa och vara arg. Samtidigt vill man vara hjälte. Att hjälpa någon som har ett problem ger i de flesta fall positiv uppmärksamhet.

Om vi fixade minnesproblemet så kommer inte någon att veta att vi gjort något. Ingen märkte något och allt funkade som det brukar. Men de som fick vänta på hjälp hann både ringa Dig och din chef för att skälla.

Kulturen på alla driftorganisationer jag jobbat med är i stora drag densamma. Den som skriker mest blir prioriterad. Ofta kan till och med stora störningar i slutändan vara positiva för driftorganisationen. Man får visa hur duktig man är och hur man ställer upp på kvällar och helger.

Omedvetet kommer man alltså att prioritera de situationer som undviker negativ uppmärksamhet och välja de som ger positiv dito.

Det handlar inte om att lyckas bli en proaktiv drift genom att sluta vara reaktiv. Det handlar om att bli bägge. Att det ges lika mycket uppmärksamhet, både positiv och negativ för de proaktiva åtgärderna som de reaktiva.
Det vi sett är att det inte räcker med att säga det eller skriva något i en processkarta. Det gäller att ändra hur man förhåller sig till uppmärksamheten kring drift. Ända från CIO till tekniker. Det gäller att förändra kulturen.

Några grundläggande förslag:

• Ge förutsättningar. Avdela resurser att fokusera på den proaktiva informationen. Kanske några personer i taget eller en del av dagen. Se till att rotera ansvaret så att alla i teamet får känsla för den information som ditt ML system ger, det bygger kompetens och kanske framför allt förtroende för informationen.
• Följ upp. Mät hur många proaktiva åtgärder Ni gjort. Mät även hur många reaktiva situationer som hade kunnat undvikas om proaktiva åtgärder vidtagits.
  Hur vet ni om att ni blir mer proaktiva om ni inte mäter?
• Säkerställ att Du kan rapportera på hur många proaktiva åtgärder som hanterats. Koppla det till vad som skulle kunnat hända. Rapportera detta och ge de personer som löst situationen äran.
  – Tipsa försäljningschefen om att han borde bjuda driften på tårta!
• Förbättringsarbete. Avsätt tid för analys och förslag. Hade vi kunnat upptäcka detta innan det påverkade kunden? Vilket data saknar vi? Vilket larm missade vi?
  Visa att det är viktigt.

Men det är ju inte bara känslan och kulturen som avgör hur man jobbar. Att titta på hur dessa proaktiva larm eller information ska passa in i Era befintliga processer borgar för ett strukturerat förhållningssätt i längden.

Proaktiv Drift – Processer/ITIL

Om du lägger proaktiva larm sist i kön kommer de att bli reaktiva och då kommer de aldrig att komma först.

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