Dva u kutiji – upravljanje konfiguracijom

by April 11, 2023BI/Analitika0 komentari

Dva u kutiji (ako možete) i svi u dokumentaciji (uvijek).

U IT kontekstu, „dva u kutiji“ se odnosi na dva servera ili komponente koje su dizajnirane da rade zajedno kako bi osigurale redundantnost i povećanu pouzdanost. Ovo podešavanje može osigurati da će, ako jedna komponenta pokvari, druga preuzeti njene operacije, čime se održava kontinuitet usluge. Cilj „dva u kutiji“ je da se obezbedi visoka dostupnost i oporavak od katastrofe. Ovo se takođe odnosi na ljudske uloge u organizaciji; međutim, rijetko se primjenjuje.

Pogledajmo relevantan primjer analitike. Vjerovatno svi poznajemo osobu u našoj kompaniji ili organizaciji po imenu koja je osoba koja se bavi analitikom. Oni su ti koji imaju izvještaje ili kontrolne table nazvane po njima – Mike's Report ili Jane's Dashboard. Naravno, postoje i drugi ljudi koji poznaju analitiku, ali ovo su pravi šampioni koji izgleda znaju kako da urade najteže stvari i prestignu rokove. Problem je što ti ljudi stoje sami. U mnogim slučajevima pod pritiskom, ne rade ni sa kim jer bi ih to moglo usporiti i tu počinje problem. Nikada ne mislimo da ćemo izgubiti ovu osobu. Uzdržat ću se od tipičnog "recimo da ih udari autobus" ili koristeći primjer kojim se iskorištavaju trenutne prilike na tržištu rada i reći nešto pozitivno poput "osvojili su na lutriji!", jer svi bismo trebali dati svoj dio posla da budemo pozitivni ovih dana.

Priča
Dolazi ponedjeljak ujutro, a naš stručnjak za analitiku i šampion MJ podnio je ostavku. MJ je dobio na lutriji i već je napustio zemlju bez brige u svijetu. Tim i ljudi koji poznaju MJ su oduševljeni i ljubomorni, ali posao mora ići. Sada će se shvatiti vrijednost i realnost onoga što je MJ radio. MJ je bio odgovoran za konačno objavljivanje i validaciju analitike. Uvek se činilo da su u stanju da poboljšaju efikasnost ili da naprave tešku promenu pre nego što svima daju analitiku. Nikoga nije baš bilo briga kako je to urađeno i bio je siguran u činjenicu da se to upravo dogodilo, a MJ je bio Rock Star pojedinac iz Analitike, tako da je dat određeni nivo autonomije. Sada kada tim počinje da skuplja dijelove, zahtjeve, dnevne probleme, zahtjeve za modifikacijom, oni su na gubitku i počinju da se koprcaju. Izvještaji/kontrolne ploče se nalaze u nepoznatim stanjima; neka sredstva nisu ažurirana tokom vikenda, a mi ne znamo zašto; ljudi pitaju šta se dešava i kada će stvari biti popravljene, izmene za koje je MJ rekao da su urađene se ne pojavljuju i nemamo pojma zašto. Tim izgleda loše. To je katastrofa i sada svi mrzimo MJ.

Lekcije
Postoje neki laki i očigledni zahvati.

  1. Nikada nemojte dozvoliti pojedincu da radi sam. Zvuči dobro, ali u manjim agilnim timovima, nemamo vremena niti ljudi da to ostvarimo. Ljudi dolaze i odlaze, zadataka je mnogo, tako da je zavadi pa vladaj u ime produktivnosti.
  2. Svako mora podijeliti svoje znanje. Također zvuči dobro, ali dijelimo li to sa pravom osobom ili ljudima? Imajte na umu da su mnogi dobitnici na lutriji kolege. Obavljanje sesija razmjene znanja također oduzima vrijeme od zadataka i većina ljudi ulaže u vještine i znanje samo na vrijeme kada je to potrebno.

Dakle, koja su neka stvarna rješenja koja svako može biti u stanju implementirati i izaći iza njih?
Počnimo sa upravljanjem konfiguracijom. Koristit ćemo ovo kao krovni izraz za nekoliko sličnih tema.

  1. Upravljanje promjenama: Proces planiranja, implementacije i kontrole promjena softverskih sistema na strukturiran i sistematičan način. Ovaj proces ima za cilj da osigura da se promene vrše na kontrolisan i efikasan način (sa mogućnošću vraćanja), uz minimalne poremećaje u postojećem sistemu i maksimalnu korist za organizaciju.
  2. Upravljanje projektima: Planiranje, organizacija i kontrola projekata razvoja softvera kako bi se osiguralo da su završeni na vrijeme, u okviru budžeta i prema željenim standardima kvaliteta. To uključuje koordinaciju resursa, aktivnosti i zadataka tokom životnog ciklusa razvoja softvera kako bi se postigli projektni ciljevi i isporučio softverski proizvod prema rasporedu.
  3. Kontinuirana integracija i kontinuirana isporuka (CI/CD): Proces automatizacije izgradnje, testiranja i implementacije softvera. Kontinuirana integracija zahtijeva redovno spajanje promjena koda u zajedničko spremište i pokretanje automatiziranih testova kako bi se otkrile greške u ranoj fazi razvoja. Kontinuirana isporuka/primjena uključuje automatsko puštanje testiranih i potvrđenih promjena koda u proizvodnju, omogućavajući brzo i često objavljivanje novih funkcija i poboljšanja.
  4. Kontrola verzije: Proces upravljanja promjenama izvornog koda i drugih softverskih artefakata tokom vremena pomoću specijaliziranih softverskih alata. Omogućava programerima da sarađuju na bazi koda, održavaju kompletnu istoriju promena i eksperimentišu sa novim funkcijama bez uticaja na glavnu kodnu bazu.

Sve navedeno se odnosi na dobre prakse razvoja softvera. Analitike koje pokreću i vode poslovanje ne zaslužuju ništa manje jer su ključne za donošenje odluka. Sva analitička sredstva (ETL poslovi, semantičke definicije, metričke definicije, izvještaji, kontrolne table, priče…itd) su samo isječci koda sa vizuelnim interfejsom za dizajniranje i naizgled manje promene mogu da zaudare na haos u operacijama.

Korištenje upravljanja konfiguracijom pokriva nas da nastavimo raditi u dobrom stanju. Sredstva su verzionirana tako da možemo vidjeti šta se dogodilo u njihovom životnom vijeku, znamo ko na čemu radi zajedno sa postignutim napretkom i rokovima, i znamo da će se produkcija nastaviti. Ono što nije obuhvaćeno nijednim čistim procesom je prenošenje znanja i razumijevanje zašto su stvari takve kakve jesu.

Svaki sistem, baza podataka i alat za analizu imaju svoje osobine. Stvari zbog kojih idu brzo ili sporo, stvari koje ih tjeraju da se ponašaju na određeni način ili daju željeni rezultat. To mogu biti postavke na sistemskom ili globalnom nivou ili stvari unutar dizajna sredstava zbog kojih oni rade baš onako kako bi trebali. Problem je u tome što se većina ovih stvari nauči tokom vremena i ne postoji uvijek mjesto za dokumentiranje. Čak i dok prelazimo na Cloud sisteme gdje više ne kontroliramo kako se aplikacija izvršava i oslanjamo se na dobavljača da to učini što je brže moguće, podešavanje definicija se nastavlja unutar naših sredstava kako bismo otključali upravo ono što tražimo. Ovo znanje je ono što treba uhvatiti i podijeliti tako da bude dostupno drugima. Ovo znanje se mora zahtijevati kao dio dokumentacije imovine i činiti sastavni dio kontrole verzija i procesa provjere i odobravanja CI/CD-a, a u nekim slučajevima čak i kao dio kontrolne liste prije objavljivanja stvari koje treba učiniti, a ne uradi.

Ne postoje magični odgovori ili AI koji bi prikrili prečice u našim analitičkim procesima ili njihov nedostatak. Bez obzira na veličinu tima koji održava protok podataka i analitike, ulaganje u sistem za praćenje promjena, verzija svih sredstava i pomoć u dokumentovanju procesa razvoja i prikupljanje znanja je neophodna. Ulaganje u procese i vrijeme unaprijed će uštedjeti gomilu izgubljenog vremena kasnije smišljanja stvari kako bismo održali zdravo stanje naše analitike. Stvari se dešavaju i najbolje je imati polisu osiguranja za MJ i druge dobitnike na lutriji.