Två i en låda (om du kan) och alla i dokumentation (alltid).
I IT-sammanhang avser "två i en låda" två servrar eller komponenter som är designade för att samverka för att ge redundans och ökad tillförlitlighet. Den här inställningen kan säkerställa att om en komponent misslyckas, kommer den andra att ta över dess verksamhet, och därmed upprätthålla kontinuiteten i tjänsten. Målet med att ha "två i en låda" är att ge hög tillgänglighet och katastrofåterställning. Det gäller även mänskliga roller i en organisation; det är dock sällan implementerat.
Låt oss titta på ett relevant Analytics-exempel. Vi känner sannolikt alla en person i vårt företag eller vår organisation vid namn som är "go-to"-personen för Analytics. Det är de som har rapporter eller instrumentpaneler uppkallade efter sig – Mike's Report eller Jane's Dashboard. Visst, det finns andra människor som kan analyser, men dessa är de sanna mästarna som verkar veta hur man får de svåraste sakerna gjorda och överträffar deadlines. Problemet är att dessa människor står ensamma. I många fall under press, arbetar de inte med någon eftersom det kan sakta ner dem och det är här problemet börjar. Vi tror aldrig att vi kommer att förlora den här personen. Jag ska avstå från det typiska "låt oss säga att de blir påkörda av en buss" eller att använda ett exempel som utnyttjar de nuvarande möjligheterna på arbetsmarknaden och säga något positivt som "de vann på lotteriet!", eftersom vi alla borde göra vår del för att vara positiva dessa dagar.
Om Snusifer
Måndag morgon kommer, och vår analysexpert och mästare MJ har lämnat in sin avskedsansökan. MJ vann på lotteriet och har redan lämnat landet utan vård i världen. Teamet och människor som känner MJ är glada och avundsjuka, men arbetet måste sluta. Nu är det när värdet och verkligheten av vad MJ gjorde är på väg att förstås. MJ ansvarade för den slutliga publiceringen och valideringen av analysen. De verkade alltid kunna förbättra effektiviteten eller göra den där svåra förändringen innan de levererade analysen till alla. Ingen brydde sig riktigt om hur det gjordes och var säker på att det precis hände, och MJ var en Analytics-individ som rockstjärna så en nivå av självständighet gavs. Nu när teamet börjar plocka upp bitarna, förfrågningarna, de dagliga frågorna, modifieringsförfrågningarna är de på förlust och börjar klättra. Rapporter / Dashboards finns i okända tillstånd; vissa tillgångar uppdaterades inte under helgen, och vi vet inte varför; folk frågar vad som händer och när saker och ting kommer att fixas, redigeringar som MJ sa var gjorda dyker inte upp och vi har ingen aning om varför. Laget ser dåligt ut. Det är en katastrof och nu hatar vi alla MJ.
Lektionerna
Det finns några enkla och självklara take-aways.
- Tillåt aldrig en individ att arbeta ensam. Låter bra men i mindre agila team har vi varken tid eller folk för att få det här att hända. Människor kommer och går, uppgifterna är många, så det är dela och härska i produktivitetens namn.
- Alla måste dela med sig av sin kunskap. Låter också bra men delar vi med rätt person eller personer? Tänk på att många lotterivinnare är medarbetare. Att göra kunskapsdelningssessioner tar också tid från uppgifterna och de flesta investerar bara i färdigheter och kunskap precis i tid när det behövs.
Så, vilka är några riktiga lösningar som alla kan implementera och stå bakom?
Låt oss börja med Configuration Management. Vi kommer att använda detta som paraplyterm för flera liknande ämnen.
- Change Management: Processen att planera, implementera och kontrollera förändringar av mjukvarusystem på ett strukturerat och systematiskt sätt. Denna process syftar till att säkerställa att förändringar görs på ett kontrollerat och effektivt sätt (med möjlighet att återgå), med minsta möjliga avbrott i det befintliga systemet och maximal nytta för organisationen.
- Projektledning: Planering, organisation och kontroll av mjukvaruutvecklingsprojekt för att säkerställa att de slutförs i tid, inom budget och till önskade kvalitetsstandarder. Det involverar koordinering av resurser, aktiviteter och uppgifter under hela mjukvaruutvecklingens livscykel för att uppnå projektmålen och leverera mjukvaruprodukten enligt tidtabell.
- Kontinuerlig integration och kontinuerlig leverans (CI/CD): Processen att automatisera byggnad, testning och distribution av programvara. Kontinuerlig integration kräver att kodändringar regelbundet slås samman till ett delat arkiv och köra automatiserade tester för att upptäcka fel tidigt i utvecklingsprocessen. Kontinuerlig leverans/distribution innebär att testade och validerade kodändringar automatiskt släpps i produktion, vilket möjliggör snabba och frekventa releaser av nya funktioner och förbättringar.
- Versionskontroll: Processen att hantera ändringar av källkod och andra programvaruartefakter över tid med hjälp av specialiserade programvaruverktyg. Det tillåter utvecklare att samarbeta på en kodbas, upprätthålla en komplett historik över förändringar och experimentera med nya funktioner utan att påverka huvudkodbasen.
Allt ovan hänvisar till god praxis för mjukvaruutveckling. Analyser som driver och driver verksamheten förtjänar inte mindre eftersom de är affärskritiska för beslutsfattande. Alla analystillgångar (ETL-jobb, semantiska definitioner, mätvärdesdefinitioner, rapporter, instrumentpaneler, berättelser...etc) är bara kodavsnitt med ett visuellt gränssnitt för design och till synes mindre förändringar kan föröda verksamheten.
Att använda Configuration Management täcker oss för att fortsätta köra i ett bra skick. Tillgångar är versionerade så att vi kan se vad som har hänt under deras livslängd, vi vet vem som arbetar med vad tillsammans med framstegen och tidslinjer, och vi vet att produktionen kommer att fortsätta. Det som inte omfattas av någon ren process är kunskapsöverföringen och förståelsen av varför saker och ting är som de är.
Varje system, databas och analysverktyg har sina egna egenskaper. Saker som får dem att gå fort eller långsamt, föremål som får dem att bete sig på ett visst sätt eller ger ett önskat resultat. Det kan vara inställningar på systemnivå eller global nivå eller saker inom tillgångsdesignen som gör att de fungerar precis som de ska. Problemet är att de flesta av dessa saker lärs ut över tid och det finns inte alltid en plats att dokumentera dem. Även när vi går över till molnsystem där vi inte längre kontrollerar hur applikationen körs och vi förlitar oss på att leverantören gör det så snabbt som möjligt, fortsätter justeringen av definitioner inom våra tillgångar för att låsa upp exakt det vi letar efter. Denna kunskap är vad som behöver fångas och delas genom att göra den tillgänglig för andra. Denna kunskap måste krävas som en del av dokumentationen av tillgångar och göras till en integrerad del av versionskontroll & CI/CD incheckning och godkännandeprocess och i vissa fall även som en del av en checklista innan publicering av saker att göra och inte do.
Det finns inga magiska svar eller AI att täcka upp för genvägar i våra analysprocesser eller brist på det. Oavsett storleken på teamet som håller data och analyser flytande är en investering i ett system för att spåra förändringar, version av alla tillgångar och hjälp med att dokumentera utvecklingsprocessen och fånga kunskap ett måste. Investeringar i processer och tid i förväg kommer att spara massor av slöseri med att senare ta reda på saker för att upprätthålla ett sunt tillstånd för vår analys. Det händer saker och det är bäst att ha en försäkring för MJs och andra lotterivinnare.
