Du dėžutėje (jei galite) ir visi dokumentuose (visada).
IT kontekste „du dėžutėje“ reiškia du serverius arba komponentus, kurie yra skirti veikti kartu, kad būtų užtikrintas perteklius ir didesnis patikimumas. Ši sąranka gali užtikrinti, kad vienam komponentui sugedus, jo veiklą perims kitas, taip išlaikydamas paslaugos tęstinumą. „Du dėžutėje“ tikslas yra užtikrinti aukštą pasiekiamumą ir atkūrimą po nelaimių. Tai taip pat taikoma žmogaus vaidmenims organizacijoje; tačiau jis įgyvendinamas retai.
Pažvelkime į atitinkamą „Analytics“ pavyzdį. Tikriausiai visi savo įmonėje ar organizacijoje žinome asmenį, kuris yra pagrindinis „Analytics“ asmuo. Jie turi ataskaitas arba prietaisų skydelius, pavadintus jų vardu – Mike's Report arba Jane's Dashboard. Žinoma, yra ir kitų žmonių, kurie išmano analizę, bet tai yra tikri čempionai, kurie, atrodo, žino, kaip atlikti sunkiausius dalykus ir peržengti terminus. Problema ta, kad šie žmonės yra vieni. Daugeliu atvejų, patiriant spaudimą, jie su niekuo nedirba, nes tai gali juos sulėtinti, ir čia prasideda problema. Niekada negalvojame, kad prarasime šį žmogų. Susilaikysiu nuo tipinio „tarkime, kad juos partrenks autobusas“ arba naudosiu pavyzdį, išnaudojantį dabartines darbo rinkos galimybes, ir pasakysiu ką nors teigiamo, pavyzdžiui, „jie laimėjo loteriją!“, nes visi turėtume daryti viską, kad būtume pozityvūs. šiomis dienomis.
Istorija
Ateina pirmadienio rytas, o mūsų analitikos ekspertas ir čempionas MJ pateikė atsistatydinimo pareiškimą. MJ laimėjo loteriją ir jau paliko šalį be rūpesčių pasaulyje. Komanda ir žmonės, kurie pažįsta MJ, yra sujaudinti ir pavydūs, tačiau darbas turi eiti. Dabar bus suprantama to, ką darė MJ, vertė ir tikrovė. MJ buvo atsakingas už galutinį analizės paskelbimą ir patvirtinimą. Atrodė, kad jie visada sugebėjo pagerinti efektyvumą arba atlikti šį sudėtingą pakeitimą prieš visiems pateikdami analizę. Niekam nerūpėjo, kaip tai buvo padaryta, ir buvo užtikrinta, kad tai tiesiog įvyko, o MJ buvo „Analytics“ roko žvaigždė, todėl buvo suteiktas tam tikras savarankiškumo lygis. Dabar, kai komanda pradeda rinkti gabalus, užklausas, kasdienes problemas, modifikavimo užklausas, jie patiria nuostolių ir pradeda maišytis. Ataskaitos / prietaisų skydeliai randami nežinomose būsenose; kai kurie ištekliai nebuvo atnaujinti per savaitgalį ir nežinome kodėl; žmonės klausia, kas vyksta ir kada viskas bus pataisyta, nerodomi pakeitimai, kurie, pasak MJ, buvo atlikti, ir mes neįsivaizduojame, kodėl. Komanda atrodo prastai. Tai nelaimė ir dabar mes visi nekenčiame MJ.
Pamokos
Yra keletas paprastų ir akivaizdžių paėmimų.
- Niekada neleiskite asmeniui dirbti vienam. Skamba gerai, bet mažesnėse judriose komandose neturime nei laiko, nei žmonių tai padaryti. Žmonės ateina ir išeina, užduočių daug, todėl vardan produktyvumo skaldyk ir valdyk.
- Kiekvienas turi dalintis savo žiniomis. Taip pat skamba gerai, bet ar dalinamės su tinkamu asmeniu ar žmonėmis? Atminkite, kad daugelis loterijos laimėtojų yra bendradarbiai. Dalijimosi žiniomis sesijos taip pat atima laiko nuo užduočių ir dauguma žmonių investuoja į įgūdžius ir žinias tik tada, kai to reikia.
Taigi, kokie yra realūs sprendimai, kuriuos kiekvienas gali įgyvendinti ir atsilikti?
Pradėkime nuo konfigūracijos valdymo. Naudosime tai kaip bendrą terminą kelioms panašioms temoms.
- Pakeitimų valdymas: Programinės įrangos sistemų pakeitimų struktūrizuoto ir sistemingo planavimo, diegimo ir valdymo procesas. Šiuo procesu siekiama užtikrinti, kad pakeitimai būtų atliekami kontroliuojamai ir efektyviai (su galimybe sugrįžti), kuo mažiau trikdant esamą sistemą ir duodant maksimalią naudą organizacijai.
- Projekto valdymas: Programinės įrangos kūrimo projektų planavimas, organizavimas ir kontrolė, siekiant užtikrinti, kad jie būtų baigti laiku, neviršijant biudžeto ir pagal norimus kokybės standartus. Tai apima išteklių, veiklos ir užduočių koordinavimą per visą programinės įrangos kūrimo gyvavimo ciklą, kad būtų pasiekti projekto tikslai ir programinės įrangos produktas būtų pristatytas laiku.
- Nuolatinis integravimas ir nenutrūkstamas pristatymas (CI/CD): Programinės įrangos kūrimo, testavimo ir diegimo automatizavimo procesas. Nuolatinis integravimas reikalauja reguliariai sujungti kodo pakeitimus į bendrą saugyklą ir vykdyti automatinius testus, kad būtų aptiktos klaidos ankstyvame kūrimo proceso etape. Nuolatinis pristatymas / diegimas apima automatinį patikrintų ir patvirtintų kodo pakeitimų išleidimą į gamybinę versiją, leidžiančią greitai ir dažnai išleisti naujas funkcijas ir patobulinimus.
- Versijų valdymas: Šaltinio kodo ir kitų programinės įrangos artefaktų pakeitimų valdymo procesas laikui bėgant naudojant specializuotus programinės įrangos įrankius. Tai leidžia kūrėjams bendradarbiauti kuriant kodų bazę, išlaikyti visą pakeitimų istoriją ir eksperimentuoti su naujomis funkcijomis nepažeidžiant pagrindinės kodų bazės.
Visa tai, kas išdėstyta pirmiau, nurodo gerą programinės įrangos kūrimo praktiką. Analitika, kuri skatina ir valdo verslą, nusipelno ne mažiau, nes jos yra labai svarbios priimant sprendimus. Visas analizės turtas (ETL užduotys, semantiniai apibrėžimai, metrikos apibrėžimai, ataskaitos, prietaisų skydeliai, istorijos ir t. t.) yra tik kodo fragmentai su vaizdine sąsaja projektavimui, o iš pažiūros nedideli pakeitimai gali pakenkti operacijoms.
Naudodami konfigūracijos valdymą galime ir toliau veikti geros būklės. Ištekliai yra versijos, kad galėtume matyti, kas nutiko per visą jų gyvavimo laikotarpį, žinome, kas ką dirba, taip pat pasiektą pažangą ir terminus, ir žinome, kad gamyba bus tęsiama. Tai, ko neapima joks grynas procesas, yra žinių perdavimas ir supratimas, kodėl viskas yra taip, kaip yra.
Kiekviena sistema, duomenų bazė ir analizės įrankis turi savų keistenybių. Dalykai, dėl kurių jie vyksta greitai arba lėtai, dalykai, dėl kurių jie elgiasi tam tikru būdu arba duoda norimą rezultatą. Tai gali būti nustatymai sistemos arba pasauliniu lygiu arba elementai, esantys ištekliaus projekte, dėl kurių jie veikia taip, kaip turėtų. Problema ta, kad dauguma šių dalykų išmokstami laikui bėgant ir ne visada yra kur juos dokumentuoti. Net ir pereinant prie debesų sistemų, kuriose nebekontroliuojame, kaip programa veikia, ir pasikliaujame tiekėju, kad tai būtų kuo greičiau, apibrėžimai ir toliau keičiami mūsų ištekliais, kad būtų atrakinta būtent tai, ko ieškome. Šios žinios yra tai, ką reikia užfiksuoti ir dalytis, suteikiant jas kitiems. Šių žinių turi būti reikalaujama kaip turto dokumentacijos dalis ir jos turi būti įtrauktos į versijų kontrolės ir CI/CD tikrinimo ir patvirtinimo procesą, o kai kuriais atvejais netgi kaip kontrolinio sąrašo dalis prieš paskelbiant dalykus, kuriuos reikia atlikti ir ko nedaryti. daryti.
Nėra stebuklingų atsakymų ar dirbtinio intelekto, kurie galėtų nuslėpti mūsų analizės procesų sparčiuosius klavišus arba jų trūkumą. Nepriklausomai nuo komandos, kuri saugo duomenis ir analizę, dydžio, būtina investuoti į sistemą, kad būtų galima sekti pokyčius, versti visą turtą ir padėti dokumentuoti kūrimo procesą bei surinkti žinias. Iš anksto investuodami į procesus ir laiką, sutaupysite daug laiko, sugaišto vėliau sprendžiant dalykus, kad išlaikytume sveiką mūsų analizės būklę. Nutinka dalykų ir geriausia turėti MJ ir kitų loterijos laimėtojų draudimo polisą.
