To i en boks (hvis du kan) og alle i dokumentation (altid).
I en IT-sammenhæng refererer "to i en boks" til to servere eller komponenter, der er designet til at arbejde sammen for at give redundans og øget pålidelighed. Denne opsætning kan sikre, at hvis en komponent fejler, vil den anden overtage dens drift og dermed opretholde kontinuiteten i tjenesten. Målet med at have "to i en boks" er at give høj tilgængelighed og genopretning efter katastrofer. Det gælder også for menneskelige roller i en organisation; det er dog sjældent implementeret.
Lad os se på et relevant Analytics-eksempel. Vi kender sandsynligvis alle en person i vores virksomhed eller organisation ved navn, som er "go-to"-personen for Analytics. Det er dem, der har rapporter eller dashboards opkaldt efter sig – Mike's Report eller Jane's Dashboard. Sikker på, der er andre mennesker, der kender til analyse, men disse er de sande mestre, der ser ud til at vide, hvordan man får de sværeste ting gjort og overresultater på deadlines. Problemet er, at disse mennesker står alene. I mange tilfælde under pres arbejder de ikke med nogen, da det kan bremse dem, og det er her problemet begynder. Vi tror aldrig, at vi kommer til at miste denne person. Jeg vil afholde mig fra det typiske "lad os sige, at de bliver ramt af en bus" eller bruge et eksempel, der udnytter de nuværende muligheder på jobmarkedet og sige noget positivt som "de vandt i lotteriet!", fordi vi alle bør gøre vores del for at være positive disse dage.
Historien
Mandag morgen kommer, og vores analyseekspert og mester MJ har afgivet deres opsigelse. MJ vandt i lotteriet og har allerede forladt landet uden omsorg i verden. Holdet og folk, der kender MJ, er begejstrede og jaloux, men arbejdet skal gå. Nu er værdien og virkeligheden af det, MJ gjorde, ved at blive forstået. MJ var ansvarlig for den endelige publicering og validering af analyserne. De så altid ud til at være i stand til at forbedre effektiviteten eller foretage den svære ændring, før de leverede analyserne til alle. Ingen var rigtig ligeglad med, hvordan det blev gjort, og var sikker på, at det lige skete, og MJ var en individuel Analytics-rockstjerne, så et niveau af autonomi blev givet. Nu hvor holdet begynder at samle brikkerne, anmodningerne, de daglige problemer, anmodningerne om modifikationer, er de på et tab og begynder at krybe. Rapporter / Dashboards findes i ukendte tilstande; nogle aktiver blev ikke opdateret i løbet af weekenden, og vi ved ikke hvorfor; folk spørger, hvad der sker, og hvornår tingene vil blive rettet, redigeringer, som MJ sagde blev udført, dukker ikke op, og vi har ingen idé om hvorfor. Holdet ser dårligt ud. Det er en katastrofe, og nu hader vi alle MJ.
Lektionerne
Der er nogle nemme og oplagte take-aways.
- Tillad aldrig en person at arbejde alene. Det lyder godt, men i mindre agile teams har vi hverken tid eller folk til at få det til at ske. Folk kommer og går, opgaverne er mange, så det er del og hersk i produktivitetens navn.
- Alle skal dele deres viden. Det lyder også godt, men deler vi med den eller de rigtige personer? Husk, at mange lotterivindere er kolleger. At lave videndelingssessioner tager også tid fra opgaverne, og de fleste investerer kun i færdigheder og viden lige i tide, når det er nødvendigt.
Så hvad er nogle rigtige løsninger, som alle kan være i stand til at implementere og stå bag?
Lad os starte med Configuration Management. Vi vil bruge dette som paraplybetegnelse for flere lignende emner.
- Forandringsledelse: Processen med at planlægge, implementere og kontrollere ændringer i softwaresystemer på en struktureret og systematisk måde. Denne proces har til formål at sikre, at ændringer foretages på en kontrolleret og effektiv måde (med mulighed for at vende tilbage), med minimal afbrydelse af det eksisterende system og maksimal fordel for organisationen.
- Projektledelse: Planlægning, organisering og kontrol af softwareudviklingsprojekter for at sikre, at de afsluttes til tiden, inden for budgettet og til de ønskede kvalitetsstandarder. Det involverer koordinering af ressourcer, aktiviteter og opgaver gennem hele softwareudviklingens livscyklus for at nå projektmålene og levere softwareproduktet til tiden.
- Kontinuerlig integration og kontinuerlig levering (CI/CD): Processen med at automatisere bygning, test og implementering af software. Kontinuerlig integration kræver regelmæssig sammenlægning af kodeændringer til et delt lager og kørsel af automatiserede tests for at opdage fejl tidligt i udviklingsprocessen. Kontinuerlig levering/implementering involverer automatisk frigivelse af testede og validerede kodeændringer i produktionen, hvilket muliggør hurtige og hyppige udgivelser af nye funktioner og forbedringer.
- Versionskontrol: Processen med at styre ændringer af kildekode og andre softwareartefakter over tid ved hjælp af specialiserede softwareværktøjer. Det giver udviklere mulighed for at samarbejde om en kodebase, opretholde en komplet historik over ændringer og eksperimentere med nye funktioner uden at påvirke hovedkodebasen.
Alt ovenstående refererer til god praksis for softwareudvikling. Analyser, der driver og driver virksomheden, fortjener intet mindre, da de er missionskritiske for beslutningstagning. Alle analyseaktiver (ETL-job, semantiske definitioner, metrikdefinitioner, rapporter, dashboards, historier ... osv.) er blot kodestykker med en visuel grænseflade til design, og tilsyneladende mindre ændringer kan ødelægge driften.
Brug af Configuration Management dækker os til at fortsætte med at køre i en god tilstand. Aktiver er versioneret, så vi kan se, hvad der er sket i deres levetid, vi ved, hvem der arbejder på hvad sammen med de opnåede fremskridt og tidslinjer, og vi ved, at produktionen vil fortsætte. Det, der ikke er omfattet af nogen ren proces, er overførsel af viden og forståelsen af, hvorfor tingene er, som de er.
Hvert system, database og analyseværktøj har deres egne særheder. Ting der får dem til at gå hurtigt eller langsomt, ting der får dem til at opføre sig på en bestemt måde eller producere et ønsket resultat. Det kan være indstillinger på system- eller globalt niveau eller ting inden for aktivdesignet, der får dem til at køre, som de skal. Problemet er, at de fleste af disse ting læres over tid, og der er ikke altid et sted at dokumentere dem. Selvom vi flytter til skysystemer, hvor vi ikke længere kontrollerer, hvordan applikationen kører, og vi stoler på, at leverandøren gør det så hurtigt som muligt, fortsætter tilpasningen af definitioner inden for vores aktiver for at låse op for præcis det, vi leder efter. Denne viden er det, der skal fanges og deles ved at gøre den tilgængelig for andre. Denne viden skal kræves som en del af dokumentationen af aktiver og gøres til en integreret del af versionskontrol & CI/CD check-in og godkendelsesprocessen og i nogle tilfælde endda som en del af en tjekliste før offentliggørelse af ting, der skal gøres og ikke gør.
Der er ingen magiske svar eller AI at dække over for genveje i vores analyseprocesser eller mangel på. Uanset størrelsen på det team, der holder data og analyser flydende, er en investering i et system til at spore ændringer, version af alle aktiver og hjælp til at dokumentere udviklingsprocessen og indfange viden et must. Investering i processer og tid på forhånd vil spare et væld af spildtid på senere at finde ud af ting for at opretholde en sund tilstand af vores analyser. Ting sker, og det er bedst at have en forsikring for MJ'er og andre lotterivindere.
