Machine Learning in Operation – Datakvalitet

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 artiklarna (Machine Learning, Kultur, Processer) har vi tittat på Artificiell Intelligens (AI) och Maskininlärning (ML) inom IT operation. Vi har tittat på vad AI/ML är. Vilka utmaningar man kan få för att använda det inom proaktiv drift och hur dessa larm/event relaterar till de vanligaste ITIL processerna.

När det kommer till data och datakvalitet finns det två olika aspekter. Det ena är det data man föder sin maskininlärning med. Det andra är det Meta-data man behöver för att bedöma om det man hittar är riktiga larm eller så kallade false-possitives, larm som kommer av misstag. Till exempel om man gör en förändring i ett system eller larm som kommer från test eller utvecklingsmiljöer på grund av att man ofta förändra hur man använder dessa system.

Jag kommer att utgå från ett ML verktyg som heter Predictive Insight från IBM då det är vad jag har mest erfarenhet av men mycket av nedanstående är applicerbart på ML som företeelse.

Meta-Data

Med Meta-data menas den information du har i ditt CMDB, ditt asset register, SLA-databas eller bara i en excel-lista. Huvudsaken är att det är information vi kan använda för att ge systemet eller din driftorganisation en större förståelse för vad som larmar. Vilken roll detta objekt har i din verksamhet, om det är produktionsutrustning eller om det pågår en ändring just nu.

Som vi tittat på tidigare är konsten att bli proaktiv att kunna agera baserat på vad som är viktigt. Inte om larmet är reaktivt eller proaktivt.
När ditt ML system hittar onormala mönster bland alla mätvärden som du har försett den med blir nästa steg att applicera detta Meta-data som en kontext till larmet för att kunna göra den sista filtreringen. Detta är inget som ett ML-system kan av sig själv då varje mätvärde i sig självt inte har någon prioritet eller kunskap om sin roll i din miljö.

Detta är inget som är unikt för just ML baserade larm utan en naturlig del av ett Event-Management system.
Det blir dock ännu viktigare nu när du börjar arbeta med proaktiv drift då det är av stor vikt att förtroendet för larmen generellt och ML systemet specifikt hålls högt.
Om varje proaktiv situation skall överprövas och ifrågasättas kommer det bli svårt att nå effektivitet i den proaktiva driften.

En typisk konfiguration av dessa filter bör se ut som något liknande.

• Är det larmande objektet under pågående förändring/change?
  – Undertryck larmet
• Är det larmade objektet i produktion eller test/deplyment?
  – Om det är test, prioritera ned larmet
• Hur viktigt är det system som det larmande objektet är den del av?
  – Sätt prioritet utifrån affärs kontext
• Finns det redundans till det larmande systemet?
  – Prioritera ned larmet om det finns redundans
• Vilken nivå av SLA har vi på det system som det larmande objektet är en del av?
  – Prioritera larmet utifrån Service kontext

Det andra som man behöver se över när det kommer till ML är förändringfönster.
Som vi tittade på i första inlägget i denna serie så fortsätter de flesta ML lösningar att lära sig, justera sina algoritmer baserat på det data som kommer in. Om du då genomför en större förändring i ett system, speciellt om det sker över en längre tid så kommer ML-systemet att se detta tillstånd som sitt nya normalläge.
För att undvika detta kan man ge systemet tidsperioder som den skall undanta från sin lärande process.

Här får man lära sig av erfarenheten. Ju stabilare och viktigare det övervakade systemet är desto viktigare blir det att undanta onormala situationer. För mer rörliga system eller när kortare förändringar sker kan man låta bli detta och endast låta ”filtret” undertrycka larmen under dessa.

In-Data

Förutom Meta-data är det viktigt att man är medveten om vilket data man föder systemet med.  Man kan bli lockad att skicka allt data man har till sitt ML-system. Visst går det men problemet man får är att man inte förstår vad den hittar. Detta skapar inte förtroende för systemet utan snarast misstänksamhet och det blir svårt att nå något reellt värde.

Börja enkelt och bygg på med mer data och fler källor vart efter förtroendet ökar, era processer och kultur mognar.

Steg 1:

Samla data, se till att din monitorering samlar in statistik och kan göra den tillgänglig för ditt ML system.
Predictive Insight, som vi på Compose IT jobbar med, har som exempel många färdiga moduler för olika monitoreringslösningar men även generella interface.

Fokusera först på några tydliga scenarion där du förstår både vad som samlas in och systemet det berör. Målet med detta är att bygga förtroende och kompetens.

Använd ML i din normala drift-process för att minska tiden att identifiera probable-cause.

Steg 2:

Börja använda de proaktiva larmen. Agera på varningar och motverka avbrott samtidigt som det du gjort i steg 1 hjälper dig att snabbare avhjälpa dom som sker.

Steg 3:

Använd ML för att identifiera prestandaproblem och korrelera data för att identifiera och åtgärda underliggande flaskhalsar. Det är här du börjar bli proaktiv på riktigt.

Under hela tiden gör ni utvärderingar av både vilka larm som genereras och hur väl dessa leder till proaktiva åtgärder. Utvärdera om ni samlar rätt data. Saknas något? Är något onödigt?
Om det blir för mycket information och den inte används för att generera nytta så backa ett steg och låt organisationen och processerna hinna ikapp.

Nu när vi tagit oss igenom data-kvalitet både för in- och ut-data så avslutar vi den här serien men att titta på verktyg och ett exempel….

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