Dva v škatli – upravljanje konfiguracije

by April 11, 2023BI/Analitika0 komentarji

Dva v škatli (če lahko) in vsi v dokumentaciji (vedno).

V kontekstu IT se "dva v škatli" nanaša na dva strežnika ali komponenti, ki sta zasnovani tako, da delujeta skupaj in zagotavljata redundanco in večjo zanesljivost. Ta nastavitev lahko zagotovi, da če ena komponenta odpove, druga prevzame njeno delovanje, s čimer se ohrani kontinuiteta storitve. Cilj "dva v škatli" je zagotoviti visoko razpoložljivost in obnovitev po katastrofi. To velja tudi za človeške vloge v organizaciji; vendar se redko izvaja.

Oglejmo si ustrezen primer Analytics. Verjetno vsi po imenu poznamo osebo v našem podjetju ali organizaciji, ki je »najpogostejša« oseba za Analytics. Oni so tisti, ki imajo poročila ali nadzorne plošče, poimenovane po njih – Mikeovo poročilo ali Janeina nadzorna plošča. Seveda obstajajo drugi ljudje, ki poznajo analitiko, vendar so ti pravi šampioni, za katere se zdi, da vedo, kako narediti najtežje stvari in prehitevati roke. Težava je v tem, da so ti ljudje sami. V mnogih primerih pod pritiskom ne sodelujejo z nikomer, saj bi jih to lahko upočasnilo in tu se začne težava. Nikoli ne pomislimo, da bomo to osebo izgubili. Vzdržal se bom tipičnega "recimo, da jih zbije avtobus" ali uporabe primera, ki izkorišča trenutne priložnosti na trgu dela, in rekel nekaj pozitivnega, kot je "zadeli so na loteriji!", ker bi morali vsi prispevati k temu, da smo pozitivni teh dneh.

Zgodba
Pride ponedeljek zjutraj in naš strokovnjak za analitiko in prvak MJ je podal odstopno izjavo. MJ je zadel na loteriji in že zapustil državo brez skrbi na svetu. Ekipa in ljudje, ki poznajo MJ-ja, so navdušeni in ljubosumni, vendar je treba delati. Zdaj bo treba razumeti vrednost in resničnost tega, kar je MJ počel. MJ je bil odgovoren za končno objavo in validacijo analitike. Vedno se je zdelo, da so lahko izboljšali učinkovitost ali izvedli tako težko spremembo, preden so vsem zagotovili analitiko. Nikogar ni zares zanimalo, kako se je to izvedlo, in bil je varen v dejstvu, da se je pravkar zgodilo, MJ pa je bil Rock Star posameznik Analytics, zato je bila podeljena določena stopnja avtonomije. Zdaj, ko ekipa začne zbirati delčke, zahteve, dnevne težave, zahteve po spremembah, so na izgubi in se začnejo prerivati. Poročila/nadzorne plošče so najdene v neznanih stanjih; nekatera sredstva se čez vikend niso posodobila in ne vemo zakaj; ljudje sprašujejo, kaj se dogaja in kdaj bodo stvari popravljene, urejanja, za katera je MJ rekel, da so opravljena, se ne prikažejo in nimamo pojma, zakaj. Ekipa izgleda slabo. To je katastrofa in zdaj vsi sovražimo MJ-ja.

Lekcije
Obstaja nekaj preprostih in očitnih zaključkov.

  1. Nikoli ne dovolite posamezniku, da dela sam. Sliši se dobro, vendar v manjših agilnih ekipah nimamo časa ali ljudi, da bi to uresničili. Ljudje pridejo in odidejo, nalog je veliko, zato velja razdeli in vladaj v imenu produktivnosti.
  2. Vsak mora deliti svoje znanje. Tudi sliši se dobro, toda ali delimo s pravo osebo ali ljudmi? Ne pozabite, da je veliko zmagovalcev na loteriji sodelavcev. Delitev znanja tudi vzame čas za naloge in večina ljudi vlaga v spretnosti in znanje le ob pravem času, ko je to potrebno.

Katere so torej resnične rešitve, ki jih lahko vsak uvede in zaostane?
Začnimo z upravljanjem konfiguracije. To bomo uporabili kot krovni izraz za več podobnih tem.

  1. Upravljanje sprememb: Proces načrtovanja, izvajanja in nadzora sprememb sistemov programske opreme na strukturiran in sistematičen način. Namen tega procesa je zagotoviti, da se spremembe izvedejo na nadzorovan in učinkovit način (z možnostjo povrnitve), z minimalnimi motnjami v obstoječem sistemu in največjo koristjo za organizacijo.
  2. Vodenje projektov: Načrtovanje, organizacija in nadzor projektov razvoja programske opreme, da se zagotovi, da so dokončani pravočasno, v okviru proračuna in v skladu z želenimi standardi kakovosti. Vključuje usklajevanje virov, dejavnosti in nalog v celotnem življenjskem ciklu razvoja programske opreme za doseganje projektnih ciljev in dostavo programskega izdelka po načrtu.
  3. Neprekinjena integracija in neprekinjena dostava (CI/CD): Postopek avtomatizacije gradnje, testiranja in uvajanja programske opreme. Nenehna integracija zahteva redno združevanje sprememb kode v skupni repozitorij in izvajanje samodejnih testov za odkrivanje napak zgodaj v razvojnem procesu. Nenehna dostava/uvajanje vključuje samodejno izdajanje preizkušenih in potrjenih sprememb kode v produkcijo, kar omogoča hitre in pogoste izdaje novih funkcij in izboljšav.
  4. Nadzor različic: Postopek upravljanja sprememb izvorne kode in drugih programskih artefaktov skozi čas z uporabo specializiranih programskih orodij. Razvijalcem omogoča sodelovanje na kodni bazi, vzdrževanje popolne zgodovine sprememb in eksperimentiranje z novimi funkcijami, ne da bi to vplivalo na glavno kodno bazo.

Vse zgoraj navedeno se nanaša na dobre prakse razvoja programske opreme. Analitike, ki poganjajo in vodijo podjetje, si ne zaslužijo nič manj, saj so ključnega pomena za sprejemanje odločitev. Vsa sredstva analitike (ETL delovna mesta, semantične definicije, definicije metrik, poročila, nadzorne plošče, zgodbe ... itd.) so samo delčki kode z vizualnim vmesnikom za načrtovanje in navidezno manjše spremembe lahko opustošijo delovanje.

Uporaba upravljanja konfiguracije nam omogoča, da še naprej delujemo v dobrem stanju. Sredstva imajo različice, tako da lahko vidimo, kaj se je zgodilo v njihovi življenjski dobi, vemo, kdo dela na čem, skupaj z doseženim napredkom in časovnimi okviri, in vemo, da se bo proizvodnja nadaljevala. Kar ni zajeto v nobenem čistem procesu, je prenos znanja in razumevanje, zakaj so stvari takšne, kot so.

Vsak sistem, baza podatkov in analitično orodje ima svoje posebnosti. Stvari, zaradi katerih gredo hitro ali počasi, predmete, zaradi katerih se obnašajo na določen način ali povzročijo želeni rezultat. To so lahko nastavitve na sistemski ali globalni ravni ali stvari znotraj zasnove sredstev, zaradi katerih delujejo, kot bi moralo. Težava je v tem, da se večine teh stvari naučimo sčasoma in jih ni vedno kje dokumentirati. Tudi ko se preselimo v sisteme v oblaku, kjer ne nadziramo več, kako se aplikacija izvaja, in se zanašamo na dobavitelja, da jo naredi čim hitrejšo, se prilagajanje definicij nadaljuje v okviru naših sredstev, da odklenemo točno tisto, kar iščemo. To znanje je tisto, kar je treba zajeti in deliti tako, da je na voljo drugim. To znanje je treba zahtevati kot del dokumentacije o sredstvih in mora biti sestavni del postopka preverjanja in odobritve nadzora različic in CI/CD ter v nekaterih primerih celo kot del kontrolnega seznama pred objavo stvari, ki jih je treba narediti in ne narediti.

Ni čarobnih odgovorov ali umetne inteligence, ki bi prikrili bližnjice v naših analitičnih procesih ali njihovo pomanjkanje. Ne glede na velikost ekipe, ki skrbi za pretok podatkov in analitiko, je naložba v sistem za sledenje spremembam, različico vseh sredstev in pomoč pri dokumentiranju razvojnega procesa ter zajemanju znanja nujna. Vnaprejšnja naložba v postopke in čas bo prihranila kup zapravljenega časa pri kasnejšem ugotavljanju stvari, da bi ohranili zdravo stanje naše analitike. Stvari se dogajajo in najbolje je imeti zavarovalno polico za MJ in druge dobitnike loterije.