Dva v krabici (pokud můžete) a všichni v dokumentaci (vždy).
V kontextu IT se „dva v krabici“ týká dvou serverů nebo komponent, které jsou navrženy tak, aby spolupracovaly a poskytovaly redundanci a zvýšenou spolehlivost. Toto nastavení může zajistit, že pokud jedna komponenta selže, druhá převezme její operace, čímž bude zachována kontinuita služby. Cílem „dva v krabici“ je poskytovat vysokou dostupnost a zotavení po havárii. To platí také pro lidské role v organizaci; málokdy je však implementován.
Podívejme se na relevantní příklad služby Analytics. Všichni pravděpodobně známe jménem v naší společnosti nebo organizaci osobu, která je pro službu Analytics „kontaktní“. Jsou to ti, kteří mají zprávy nebo panely pojmenované po nich – Mike's Report nebo Jane's Dashboard. Jistě, existují i další lidé, kteří znají analytiku, ale toto jsou skuteční šampioni, kteří, jak se zdá, vědí, jak udělat ty nejtěžší věci a překročit termíny. Problém je v tom, že tito lidé stojí sami. V mnoha případech pod tlakem s nikým nespolupracují, protože by je to mohlo zpomalit, a tady začíná problém. Nikdy si nemyslíme, že toho člověka ztratíme. Zdržím se typického „řekněme, že je srazí autobus“ nebo použiji příklad využívající současné příležitosti na trhu práce a řeknu něco pozitivního jako „vyhráli v loterii!“, protože všichni bychom měli udělat svou část, abychom byli pozitivní. tyto dny.
Příběh
Přichází pondělí ráno a náš analytik a šampion MJ podal rezignaci. MJ vyhrál v loterii a již opustil zemi bez starostí ve světě. Tým a lidé, kteří MJ znají, jsou nadšení a žárlí, ale práce musí jít. Nyní je třeba porozumět hodnotě a realitě toho, co MJ dělal. MJ byl zodpovědný za konečné zveřejnění a ověření analýzy. Vždy se zdálo, že jsou schopni zlepšit efektivitu nebo provést tuto obtížnou změnu, než poskytnou analýzu všem. Nikoho ve skutečnosti nezajímalo, jak se to udělalo, a byl si jistý tím, že se to právě stalo, a MJ byl jednotlivec v Analytics Rock Star, takže mu byla poskytnuta určitá úroveň autonomie. Nyní, když tým začíná sbírat kousky, požadavky, každodenní záležitosti, požadavky na úpravy, jsou v rozpacích a začínají se míchat. Zprávy / Dashboardy se nacházejí v neznámých stavech; některá aktiva se přes víkend neaktualizovala a my nevíme proč; lidé se ptají, co se děje a kdy budou věci opraveny, úpravy, o kterých MJ řekl, že byly provedeny, se nezobrazují a my netušíme proč. Tým vypadá špatně. Je to katastrofa a teď všichni nenávidíme MJ.
Lekce
Existuje několik jednoduchých a jasných kroků.
- Nikdy nedovolte, aby jednotlivec pracoval sám. Zní to dobře, ale v menších agilních týmech na to nemáme čas ani lidi. Lidé přicházejí a odcházejí, úkolů je mnoho, proto je rozděl a panuj ve jménu produktivity.
- Každý musí sdílet své znalosti. Také to zní dobře, ale sdílíme to se správnou osobou nebo lidmi? Mějte na paměti, že mnoho výherců loterie jsou spolupracovníci. Provádění relací sdílení znalostí také ubírá čas od úkolů a většina lidí investuje do dovedností a znalostí právě včas, když je to potřeba.
Jaká jsou tedy skutečná řešení, která může každý implementovat a překonat?
Začněme Configuration Management. Tento termín budeme používat jako zastřešující termín pro několik podobných témat.
- Správa změn: Proces plánování, implementace a řízení změn v softwarových systémech strukturovaným a systematickým způsobem. Tento proces si klade za cíl zajistit, aby změny byly prováděny kontrolovaným a efektivním způsobem (s možností vrátit se zpět), s minimálním narušením stávajícího systému a maximálním přínosem pro organizaci.
- Projektový management: Plánování, organizace a kontrola projektů vývoje softwaru s cílem zajistit, aby byly dokončeny včas, v rámci rozpočtu a podle požadovaných standardů kvality. Zahrnuje koordinaci zdrojů, činností a úkolů během životního cyklu vývoje softwaru za účelem dosažení cílů projektu a dodání softwarového produktu podle plánu.
- Průběžná integrace a průběžné doručování (CI/CD): Proces automatizace vytváření, testování a nasazení softwaru. Nepřetržitá integrace vyžaduje pravidelné začleňování změn kódu do sdíleného úložiště a spouštění automatických testů k odhalení chyb v rané fázi vývojového procesu. Průběžné dodávání/nasazování zahrnuje automatické uvolňování testovaných a ověřených změn kódu do produkce, což umožňuje rychlé a časté vydávání nových funkcí a vylepšení.
- Řízení verzí: Proces správy změn zdrojového kódu a dalších softwarových artefaktů v průběhu času pomocí specializovaných softwarových nástrojů. Umožňuje vývojářům spolupracovat na kódové základně, udržovat kompletní historii změn a experimentovat s novými funkcemi, aniž by to ovlivnilo hlavní kódovou základnu.
Všechny výše uvedené se týkají osvědčených postupů vývoje softwaru. Analýzy, které řídí a řídí podnikání, si nezaslouží nic méně, protože jsou zásadní pro rozhodování. Všechny analytické prostředky (úlohy ETL, sémantické definice, definice metrik, sestavy, řídicí panely, příběhy atd.) jsou pouze úryvky kódu s vizuálním rozhraním pro navrhování a zdánlivě drobné změny mohou způsobit zmatek v provozu.
Používání Configuration Management nás pokrývá, abychom udrželi běh v dobrém stavu. Díla jsou verzována, takže můžeme vidět, co se stalo během jejich životnosti, víme, kdo na čem pracuje spolu s dosaženým pokrokem a časovými osami, a víme, že výroba bude pokračovat. Co není pokryto žádným čistým procesem, je předávání znalostí a pochopení toho, proč jsou věci takové, jaké jsou.
Každý systém, databáze a analytický nástroj mají své vlastní zvláštnosti. Věci, díky nimž jdou rychle nebo pomalu, věci, díky kterým se chovají určitým způsobem nebo přinášejí požadovaný výsledek. Mohou to být nastavení na systémové nebo globální úrovni nebo věci v rámci návrhu aktiv, díky kterým fungují tak, jak mají. Problém je v tom, že většina z těchto věcí se časem naučí a ne vždy je kde zdokumentovat. I když přecházíme na cloudové systémy, kde již nekontrolujeme, jak se aplikace spouští, a spoléháme se na dodavatele, že to udělá co nejrychleji, ladění definic pokračuje v našich aktivech, abychom odemkli přesně to, co hledáme. Tyto znalosti je třeba zachytit a sdílet tím, že je zpřístupníme ostatním. Tyto znalosti musí být vyžadovány jako součást dokumentace aktiv a musí být nedílnou součástí procesu kontroly verzí a CI/CD check-in a schvalovacího procesu a v některých případech dokonce jako součást kontrolního seznamu před zveřejněním věcí, které je třeba udělat a ne. dělat.
Neexistují žádné magické odpovědi ani umělá inteligence, která by zakryla zkratky v našich analytických procesech nebo je postrádala. Bez ohledu na velikost týmu, který udržuje tok dat a analýz, je investice do systému nezbytná pro sledování změn, verze všech aktiv a pomoc s dokumentací procesu vývoje a získáváním znalostí. Investice do procesů a času předem ušetří spoustu ztraceného času později vymýšlením věcí, abychom udrželi zdravý stav naší analýzy. Věci se dějí a nejlepší je mít pojistku pro MJ a další výherce loterie.
