To i en boks (hvis du kan) og alle i dokumentasjon (alltid).
I en IT-sammenheng refererer "to i en boks" til to servere eller komponenter som er designet for å fungere sammen for å gi redundans og økt pålitelighet. Dette oppsettet kan sikre at hvis en komponent svikter, vil den andre ta over driften, og dermed opprettholde kontinuiteten i tjenesten. Målet med å ha "to i en boks" er å gi høy tilgjengelighet og katastrofegjenoppretting. Dette gjelder også menneskeroller i en organisasjon; det er imidlertid sjelden implementert.
La oss se på et relevant Analytics-eksempel. Vi kjenner sannsynligvis alle en person i selskapet eller organisasjonen vår ved navn som er "go-to"-personen for Analytics. Det er de som har rapporter eller dashboard oppkalt etter seg – Mike's Report eller Jane's Dashboard. Jada, det er andre mennesker som kan analyser, men dette er de sanne mesterne som ser ut til å vite hvordan de skal få de vanskeligste tingene gjort og overopprette på tidsfrister. Problemet er at disse menneskene står alene. I mange tilfeller under press, jobber de ikke med noen, da det kan bremse dem, og det er her problemet begynner. Vi tror aldri at vi kommer til å miste denne personen. Jeg vil avstå fra det typiske "la oss si at de blir påkjørt av en buss" eller bruke et eksempel som utnytter de nåværende jobbmarkedsmulighetene og si noe positivt som "de vant i lotto!", fordi vi alle bør gjøre vårt for å være positive disse dager.
Historien
Mandag morgen kommer, og vår analyseekspert og mester MJ har sendt inn sin oppsigelse. MJ vant i lotto og har allerede forlatt landet uten omsorg i verden. Teamet og folk som kjenner MJ er begeistret og sjalu, men arbeidet må gå. Det er nå verdien og virkeligheten av det MJ gjorde er i ferd med å bli forstått. MJ var ansvarlig for den endelige publiseringen og valideringen av analysene. De så alltid ut til å være i stand til å forbedre effektiviteten eller gjøre den vanskelige endringen før de leverte analysene til alle. Ingen brydde seg egentlig om hvordan det ble gjort og var trygg på det faktum at det nettopp skjedde, og MJ var en Analytics individuell Rock Star, så et nivå av autonomi ble gitt. Nå som teamet begynner å plukke opp brikkene, forespørslene, de daglige problemene, endringsforespørslene, er de på tap og begynner å rykke. Rapporter / Dashboards finnes i ukjente tilstander; noen eiendeler ble ikke oppdatert i løpet av helgen, og vi vet ikke hvorfor; folk spør hva som skjer og når ting vil bli fikset, redigeringer som MJ sa ble gjort dukker ikke opp, og vi har ingen anelse om hvorfor. Laget ser dårlig ut. Det er en katastrofe, og nå hater vi alle MJ.
Leksjonene
Det er noen enkle og åpenbare take-aways.
- La aldri en person jobbe alene. Høres bra ut, men i mindre smidige team har vi verken tid eller folk til å få dette til. Folk kommer og går, oppgavene er mange, så det er del og hersk i produktivitetens navn.
- Alle må dele sin kunnskap. Høres også bra ut, men deler vi med rett person eller personer? Husk at mange lotterivinnere er kolleger. Å gjennomføre økter med kunnskapsdeling tar også tid unna oppgavene, og de fleste investerer kun i ferdigheter og kunnskap akkurat i tide når det trengs.
Så, hva er noen reelle løsninger som alle kan være i stand til å implementere og stå bak?
La oss starte med Configuration Management. Vi vil bruke dette som paraplybegrepet for flere lignende emner.
- Endringsledelse: Prosessen med å planlegge, implementere og kontrollere endringer i programvaresystemer på en strukturert og systematisk måte. Denne prosessen tar sikte på å sikre at endringer gjøres på en kontrollert og effektiv måte (med mulighet til å gå tilbake), med minimal forstyrrelse av det eksisterende systemet og maksimal nytte for organisasjonen.
- Prosjektledelse: Planlegging, organisering og kontroll av programvareutviklingsprosjekter for å sikre at de fullføres i tide, innenfor budsjett og til ønsket kvalitetsstandard. Det innebærer koordinering av ressurser, aktiviteter og oppgaver gjennom hele programvareutviklingens livssyklus for å nå prosjektmålene og levere programvareproduktet i tide.
- Kontinuerlig integrasjon og kontinuerlig levering (CI/CD): Prosessen med å automatisere bygging, testing og distribusjon av programvare. Kontinuerlig integrasjon krever regelmessig sammenslåing av kodeendringer til et delt depot og kjøring av automatiserte tester for å oppdage feil tidlig i utviklingsprosessen. Kontinuerlig levering/distribusjon innebærer automatisk utgivelse av testede og validerte kodeendringer i produksjon, noe som gir mulighet for raske og hyppige utgivelser av nye funksjoner og forbedringer.
- Versjonskontroll: Prosessen med å administrere endringer i kildekode og andre programvareartefakter over tid ved hjelp av spesialiserte programvareverktøy. Det lar utviklere samarbeide om en kodebase, opprettholde en fullstendig historikk med endringer og eksperimentere med nye funksjoner uten å påvirke hovedkodebasen.
Alt det ovennevnte refererer til god programvareutviklingspraksis. Analyser som driver og driver virksomheten fortjener ikke mindre ettersom de er forretningskritiske for beslutningstaking. Alle analytiske eiendeler (ETL-jobber, semantiske definisjoner, metrikkdefinisjoner, rapporter, dashbord, historier ... osv.) er bare kodebiter med et visuelt grensesnitt for utforming, og tilsynelatende mindre endringer kan ødelegge driften.
Bruk av Configuration Management dekker oss for å fortsette å kjøre i god stand. Eiendeler er versjonert slik at vi kan se hva som har skjedd i deres levetid, vi vet hvem som jobber med hva sammen med fremdriften og tidslinjer, og vi vet at produksjonen vil fortsette. Det som ikke dekkes av noen ren prosess er overføring av kunnskap og forståelse av hvorfor ting er som de er.
Hvert system, database og analyseverktøy har sine egne særheter. Ting som får dem til å gå fort eller sakte, ting som får dem til å oppføre seg på en bestemt måte eller produsere et ønsket resultat. Dette kan være innstillinger på system- eller globalt nivå eller ting innenfor aktivadesignet som gjør at de kjører akkurat som de skal. Problemet er at de fleste av disse tingene læres over tid, og det er ikke alltid et sted å dokumentere dem. Selv når vi går over til skysystemer der vi ikke lenger kontrollerer hvordan applikasjonen kjører, og vi er avhengige av at leverandøren gjør det så raskt som mulig, fortsetter tilpasningen av definisjoner innenfor våre eiendeler for å låse opp akkurat det vi leter etter. Denne kunnskapen er det som må fanges opp og deles ved å gjøre den tilgjengelig for andre. Denne kunnskapen må kreves som en del av dokumentasjonen av eiendeler og gjøres til en integrert del av versjonskontroll og CI/CD-innsjekking og godkjenningsprosessen og i noen tilfeller til og med som en del av en sjekkliste før publisering av ting som skal gjøres og ikke gjøre.
Det er ingen magiske svar eller AI å dekke opp for snarveier i analyseprosessene våre eller mangel på det. Uavhengig av størrelsen på teamet som holder dataene og analysene flytende, er en investering i et system for å spore endringer, versjon av alle eiendeler og hjelp til å dokumentere utviklingsprosessen og fange kunnskap et must. Investering i prosesser og tid i forkant vil spare massevis av bortkastet tid på senere å finne ut av ting for å opprettholde en sunn tilstand av analysene våre. Ting skjer, og det er best å ha en forsikring for MJs og andre lotterivinnere.
