Kaks kasti (kui saate) ja kõik dokumentatsioonis (alati).
IT-kontekstis tähendab „kaks kastis” kahte serverit või komponenti, mis on loodud koos töötama, et tagada koondamine ja suurem töökindlus. See seadistus võib tagada, et kui üks komponent ebaõnnestub, võtab teine selle toimingud üle, säilitades nii teenuse järjepidevuse. "Kaks kastis" eesmärk on tagada kõrge kättesaadavus ja avariitaaste. See kehtib ka inimrollide kohta organisatsioonis; seda rakendatakse aga harva.
Vaatame asjakohast Analyticsi näidet. Tõenäoliselt tunneme kõik oma ettevõttes või organisatsioonis nime järgi inimest, kes on Analyticsi jaoks sobiv inimene. Just neil on aruanded või armatuurlauad nende järgi nimetatud – Mike’i aruanne või Jane’i armatuurlaud. Muidugi on ka teisi inimesi, kes tunnevad analüütikat, kuid need on tõelised meistrid, kes näivad teadvat, kuidas kõige raskemad asjad ära teha ja tähtaegadest üle saada. Probleem on selles, et need inimesed on üksi. Paljudel juhtudel ei tööta nad surve all kellegagi, kuna see võib nende tegevust aeglustada ja probleem algabki siit. Me ei arva kunagi, et kaotame selle inimese. Ma hoidun tüüpilisest "oletame, et nad jäävad bussilt löögi" või praeguste tööturu võimaluste ärakasutamise näitest ja ütlen midagi positiivset, näiteks "nad võitsid loterii!", sest me kõik peaksime andma oma panuse, et olla positiivsed. neil päevil.
Lugu
Esmaspäeva hommik on käes ning meie analüütikaekspert ja meister MJ on esitanud lahkumisavalduse. MJ võitis loterii ja on juba riigist ilma hoolitsuseta lahkunud. Meeskond ja inimesed, kes tunnevad MJ-d, on elevil ja kadedad, kuid töö peab minema. Nüüd on MJ tegemiste väärtus ja tegelikkus mõistetav. MJ vastutas analüütika lõpliku avaldamise ja valideerimise eest. Tundub, et nad suudavad alati tõhusust parandada või raske muudatuse teha, enne kui analüütika kõigile kättesaadavaks tehti. Kedagi ei huvitanud tegelikult, kuidas see tehtud sai, ja oli kindel, et see just juhtus, ja MJ oli Analyticsi individuaalne rokistaar, nii et talle anti teatud tase autonoomiat. Nüüd, kui meeskond hakkab tükke, taotlusi, igapäevaseid probleeme ja muutmistaotlusi kokku korjama, on nad kahjumis ja hakkavad rüselema. Aruanded / armatuurlauad leitakse tundmatus olekus; mõnda vara ei värskendatud nädalavahetusel ja me ei tea, miks; inimesed küsivad, mis toimub ja millal asjad parandatakse, muudatusi, mis MJ sõnul tehti, ei kuvata ja meil pole aimugi, miks. Meeskond näeb halb välja. See on katastroof ja nüüd me kõik vihkame MJ-d.
Tunnid
Seal on mõned lihtsad ja ilmsed äravõtmised.
- Ärge kunagi lubage inimesel üksi töötada. Kõlab hästi, kuid väiksemates agarates meeskondades pole meil aega ega inimesi selle elluviimiseks. Inimesed tulevad ja lähevad, ülesandeid on palju, nii et tootlikkuse nimel on jaga ja valluta.
- Kõik peavad oma teadmisi jagama. Kõlab ka hästi, aga kas jagame õige inimese või inimestega? Pidage meeles, et paljud loterii võitjad on töökaaslased. Teadmiste jagamise seansside läbiviimine võtab ka ülesannetelt aega ning enamik inimesi investeerib oskustesse ja teadmistesse just siis, kui seda vaja läheb.
Millised on reaalsed lahendused, mida igaüks saab rakendada ja mille taga on?
Alustame konfiguratsioonihaldusega. Kasutame seda mitme sarnase teema katusterminina.
- Muutuste juhtimine: Tarkvarasüsteemide muudatuste kavandamise, juurutamise ja kontrollimise protsess struktureeritud ja süstemaatilisel viisil. Selle protsessi eesmärk on tagada, et muudatusi tehakse kontrollitud ja tõhusal viisil (tagastamise võimalusega), olemasolevat süsteemi minimaalselt häirides ja organisatsioonile maksimaalset kasu.
- Projekti juht: Tarkvaraarendusprojektide planeerimine, korraldamine ja kontroll tagamaks, et need valmivad õigeaegselt, eelarve piires ja soovitud kvaliteedistandardite kohaselt. See hõlmab ressursside, tegevuste ja ülesannete koordineerimist kogu tarkvaraarenduse elutsükli jooksul, et saavutada projekti eesmärgid ja tarnida tarkvaratoote ajakava järgi.
- Pidev integreerimine ja pidev kohaletoimetamine (CI/CD): Tarkvara loomise, testimise ja juurutamise automatiseerimise protsess. Pidev integreerimine nõuab korrapäraselt koodimuudatuste liitmist jagatud hoidlasse ja automatiseeritud testide käivitamist, et tuvastada vead arendusprotsessi varajases staadiumis. Pidev tarnimine/juurutamine hõlmab testitud ja kinnitatud koodimuudatuste automaatset vabastamist tootmisse, võimaldades uute funktsioonide ja täiustuste kiiret ja sagedast väljalaskmist.
- Versioonihaldus: Lähtekoodi ja muude tarkvaraartefaktide aja jooksul tehtud muudatuste haldamise protsess spetsiaalsete tarkvaratööriistade abil. See võimaldab arendajatel teha koodibaasi kallal koostööd, säilitada täielikku muudatuste ajalugu ja katsetada uusi funktsioone ilma põhikoodibaasi mõjutamata.
Kõik eelnev viitab headele tarkvaraarenduse tavadele. Analüütikud, mis juhivad ja juhivad ettevõtet, ei vääri vähematki, kuna need on otsuste tegemisel kriitilise tähtsusega. Kõik analüütikavarad (ETL-i töökohad, semantilised määratlused, mõõdikute määratlused, aruanded, armatuurlauad, lood jne) on vaid koodilõigud koos visuaalse liidesega kujundamiseks ja näiliselt väikesed muudatused võivad toiminguid häirida.
Konfiguratsioonihalduse kasutamine võimaldab meil jätkuvalt heas seisukorras töötada. Varad on versioonistatud, et näeksime, mis nende eluea jooksul on juhtunud, teame, kes mille kallal koos tehtud edusammude ja ajakavadega töötab, ning teame, et tootmine jätkub. Mida ükski puhas protsess ei hõlma, on teadmiste edasiandmine ja arusaamine, miks asjad on nii, nagu nad on.
Igal süsteemil, andmebaasil ja analüüsitööriistal on oma eripärad. Asjad, mis panevad nad kiiresti või aeglaselt minema, asjad, mis panevad nad teatud viisil käituma või annavad soovitud tulemuse. Need võivad olla süsteemi või globaalse taseme sätted või varakujunduses olevad asjad, mis panevad need töötama täpselt nii, nagu peaks. Probleem on selles, et enamik neist asjadest õpitakse aja jooksul ja alati pole kohta, kus neid dokumenteerida. Isegi kui liigume pilvesüsteemidele, kus me ei kontrolli enam, kuidas rakendus töötab, ja me toetume tarnijale, et see oleks võimalikult kiire, jätkub meie varade definitsioonide kohandamine, et avada täpselt see, mida otsime. Need teadmised on see, mida tuleb püüda ja jagada, tehes need teistele kättesaadavaks. Need teadmised peavad olema osa varade dokumenteerimisest ning olema versioonikontrolli ja CI/CD sisse- ja kinnitamisprotsessi lahutamatu osa ning mõnel juhul isegi osana kontrollnimekirjast enne asjade avaldamist, mida teha ja mitte. teha.
Meie analüüsiprotsesside otseteede või nende puudumise varjamiseks pole maagilisi vastuseid ega tehisintellekti. Olenemata andmete ja analüüside liikumisest hoidva meeskonna suurusest on süsteemi investeering muudatuste jälgimiseks, kõigi varade versioonimine ning arendusprotsessi dokumenteerimise ja teadmiste kogumine kohustuslik. Protsessidesse ja algusesse investeerimine säästab palju raisatud aega, mis kulub hiljem asjade väljamõtlemisele, et säilitada meie analüütika tervislik seisund. Asju juhtub ja parim on omada MJ-de ja teiste loteriivõitjate jaoks kindlustuspoliisi.
