Ketten egy dobozban (ha lehet) és mindenki a dokumentációban (mindig).
IT-kontextusban a „kettő egy dobozban” két kiszolgálót vagy összetevőt jelent, amelyeket úgy terveztek, hogy együttműködjenek a redundancia és a nagyobb megbízhatóság biztosítása érdekében. Ezzel a beállítással biztosítható, hogy ha az egyik komponens meghibásodik, a másik átvegye annak működését, fenntartva ezzel a szolgáltatás folytonosságát. A „kettő egy dobozban” célja a magas rendelkezésre állás és a katasztrófa utáni helyreállítás biztosítása. Ez vonatkozik a szervezetben betöltött emberi szerepekre is; azonban ritkán valósul meg.
Nézzünk egy releváns Analytics példát. Valószínűleg mindannyian név szerint ismerünk egy olyan személyt a cégünkben vagy szervezetünkben, aki az Analytics „kiadó” személye. Ők azok, akikről jelentéseket vagy irányítópultokat neveztek el – Mike's Report vagy Jane's Dashboard. Persze vannak más emberek, akik ismerik az analitikát, de ők az igazi bajnokok, akik úgy tűnik, tudják, hogyan kell a legnehezebb dolgokat elvégezni és túlteljesíteni a határidőket. A probléma az, hogy ezek az emberek egyedül állnak. Sok esetben nyomás alatt nem dolgoznak együtt senkivel, mert ez lelassíthatja őket, és itt kezdődik a probléma. Soha nem gondoljuk, hogy elveszítjük ezt a személyt. Tartózkodni fogok a tipikus „mondjuk elüti őket egy busz” vagy a jelenlegi munkaerő-piaci lehetőségeket kihasználó példától, és valami pozitívat mondok, például „nyertek a lottón!”, mert mindannyiunknak meg kell tennünk a részünket, hogy pozitívak legyünk. ezek a napok.
A történet
Eljön a hétfő reggel, elemző szakértőnk és bajnokunk, MJ benyújtotta lemondását. MJ nyert a lottón, és máris gond nélkül elhagyta az országot a világban. A csapat és az emberek, akik ismerik MJ-t, izgatottak és féltékenyek, de a munkának mennie kell. Most van az, amikor MJ tevékenységének értéke és valósága hamarosan megérthető. MJ volt felelős az elemzések végleges közzétételéért és validálásáért. Mindig úgy tűnt, hogy képesek javítani a hatékonyságot, vagy végrehajtani ezt a nehéz változtatást, mielőtt mindenkihez eljuttatnák az elemzést. Senkit nem igazán érdekelt, hogy ez hogyan történik, és biztos volt abban, hogy csak úgy megtörtént, MJ pedig az Analytics egyéni rocksztárja volt, így bizonyos szintű autonómiát biztosítottak. Most, ahogy a csapat elkezdi összeszedni a darabokat, a kéréseket, a napi problémákat, a módosítási kéréseket, vesztésre állnak, és elkezdenek tülekedni. A jelentések/irányítópultok ismeretlen állapotúak; egyes elemek nem frissültek a hétvégén, és nem tudjuk miért; az emberek azt kérdezik, hogy mi folyik itt, és mikor javítják a dolgokat, nem jelennek meg azok a szerkesztések, amelyekről MJ azt mondta, hogy elkészültek, és fogalmunk sincs, miért. Rosszul néz ki a csapat. Ez egy katasztrófa, és most mindannyian utáljuk MJ-t.
A leckék
Van néhány egyszerű és nyilvánvaló elvitel.
- Soha ne engedje meg az egyénnek, hogy egyedül dolgozzon. Jól hangzik, de kisebb agilis csapatokban nincs időnk vagy emberek, hogy ezt megvalósítsuk. Az emberek jönnek-mennek, sok a feladat, szóval oszd meg és uralkodj a termelékenység nevében.
- Mindenkinek meg kell osztania tudását. Ez is jól hangzik, de vajon a megfelelő személlyel vagy emberekkel osztjuk meg? Ne feledje, hogy sok lottó nyertes munkatárs. A tudásmegosztó foglalkozások szintén elveszik az időt a feladatoktól, és a legtöbb ember csak akkor fektet be készségekre és tudásra, amikor arra szükség van.
Tehát melyek azok a valódi megoldások, amelyeket mindenki meg tud valósítani és mögötte állni?
Kezdjük a konfigurációkezeléssel. Ezt több hasonló téma gyűjtőfogalmaként fogjuk használni.
- Változáskezelés: A szoftverrendszerek változásainak strukturált és szisztematikus tervezésének, végrehajtásának és ellenőrzésének folyamata. Ennek a folyamatnak az a célja, hogy a változtatások ellenőrzött és hatékony módon történjenek (visszatérés lehetőségével), a meglévő rendszer minimális megzavarásával és a szervezet számára a lehető legnagyobb haszonnal.
- Projektmenedzsment: Szoftverfejlesztési projektek tervezése, szervezése és ellenőrzése annak biztosítása érdekében, hogy azok időben, a költségvetésen belül és a kívánt minőségi előírásoknak megfelelően készüljenek el. Ez magában foglalja az erőforrások, tevékenységek és feladatok koordinálását a szoftverfejlesztési életciklus során a projekt céljainak elérése és a szoftvertermék ütemezett szállítása érdekében.
- Folyamatos integráció és folyamatos szállítás (CI/CD): A szoftverek felépítésének, tesztelésének és telepítésének automatizálási folyamata. A folyamatos integráció megköveteli a kódmódosítások rendszeres összevonását egy megosztott tárolóba, és automatizált tesztek futtatását a hibák észlelése érdekében a fejlesztési folyamat korai szakaszában. A folyamatos kézbesítés/telepítés magában foglalja a tesztelt és ellenőrzött kódmódosítások automatikus kiadását a termelésbe, lehetővé téve az új funkciók és fejlesztések gyors és gyakori kiadását.
- Verziókezelés: A forráskód és más szoftverműtermékek időbeli változásainak kezelési folyamata speciális szoftvereszközök segítségével. Lehetővé teszi a fejlesztők számára, hogy együttműködjenek egy kódbázison, teljes körű változástörténetet tartsanak fenn, és új funkciókkal kísérletezzenek a fő kódbázis befolyásolása nélkül.
A fentiek mindegyike a helyes szoftverfejlesztési gyakorlatra utal. Az üzleti tevékenységet irányító és irányító elemzések nem kevesebbet érdemelnek, mivel a döntéshozatalban kulcsfontosságúak. Az összes elemző eszköz (ETL-feladatok, szemantikai definíciók, metrikadefiníciók, jelentések, irányítópultok, történetek stb.) csak kódrészlet, vizuális felülettel a tervezéshez, és a látszólag apró változtatások pusztítást okozhatnak a műveletekben.
A Configuration Management használatával biztosíthatjuk, hogy továbbra is jó állapotban fusson. Az eszközöket úgy verziózzák, hogy láthassuk, mi történt az élettartamuk során, tudjuk, hogy ki mivel dolgozik, az elért előrehaladással és ütemtervekkel együtt, és tudjuk, hogy a gyártás folytatódik. Amit egyetlen tiszta folyamat sem fed le, az a tudás átadása és annak megértése, hogy a dolgok miért vannak úgy, ahogy vannak.
Minden rendszernek, adatbázisnak és elemzőeszköznek megvannak a maga sajátosságai. Olyan dolgok, amelyek miatt gyorsan vagy lassan haladnak, olyan dolgok, amelyek bizonyos módon viselkednek vagy a kívánt eredményt hozzák. Ezek lehetnek rendszer- vagy globális szintű beállítások, vagy az eszköztervezésen belüli dolgok, amelyek úgy futnak, ahogy kellene. A probléma az, hogy ezeknek a dolgoknak a többségét idővel megtanulják, és nem mindig van hely a dokumentálására. Még akkor is, ha a felhőrendszerekre költözünk, ahol már nem mi irányítjuk az alkalmazás végrehajtását, és a beszállítóra hagyatkozunk, hogy a lehető leggyorsabban dolgozzon, a definíciók módosítása eszközeinken belül folytatódik, hogy pontosan azt kapjuk, amit keresünk. Ezt a tudást kell megragadni és megosztani mások számára elérhetővé téve. Ezt a tudást az eszközök dokumentációjának részeként kell megkövetelni, és a verzióellenőrzési és CI/CD-bejelentkezési és jóváhagyási folyamat szerves részévé kell tenni, és bizonyos esetekben akár egy ellenőrző lista részeként is a közzététel előtt, hogy mit kell tenni és nem. csináld.
Nincsenek mágikus válaszok vagy mesterséges intelligencia, amely elfedné az elemzési folyamatainkban előforduló parancsikonokat vagy azok hiányát. Függetlenül attól, hogy mekkora a csapat az adatok és az elemzések áramlását, egy rendszerbe történő befektetés a változások nyomon követése, az összes eszköz verziószáma, valamint a fejlesztési folyamat dokumentálása és a tudás rögzítése nélkülözhetetlen. A folyamatokba és az előzetesen befektetett idő rengeteg elvesztegetett időt takarít meg a későbbi dolgok kitalálásával, hogy megőrizzük elemzéseink egészséges állapotát. Történnek dolgok, és a legjobb, ha biztosítást kötünk MJ-k és más lottó nyertesek számára.
