Twa yn in doaze (as jo kinne) en elkenien yn dokumintaasje (altyd).
Yn in IT-kontekst ferwiist "twa yn in doaze" nei twa servers as komponinten dy't binne ûntworpen om gear te wurkjen om oerstalligens en ferhege betrouberens te leverjen. Dizze opset kin derfoar soargje dat as ien komponint mislearret, de oare syn operaasjes oernimme sil, sadat de kontinuïteit fan tsjinst behâldt. It doel fan "twa yn in doaze" is om hege beskikberens en rampherstel te leverjen. Dat jildt ek foar minsklike rollen yn in organisaasje; lykwols, it wurdt komselden útfierd.
Litte wy nei in relevant Analytics-foarbyld sjen. Wy kenne allegear wierskynlik in persoan yn ús bedriuw of organisaasje by namme dy't de "go-to" persoan is foar Analytics. It binne dejingen dy't rapporten as dashboards hawwe neamd nei har - Mike's Report of Jane's Dashboard. Wis, d'r binne oare minsken dy't analytyk kenne, mar dit binne de wiere kampioenen dy't lykje te witten hoe't se de hurdste dingen kinne krije en oer deadlines kinne oerhelje. It probleem is dat dizze minsken allinich stean. Yn in protte gefallen ûnder druk wurkje se net mei ien, om't se har fertrage kinne en dit is wêr't it probleem begjint. Wy tinke noait dat wy dizze persoan sille ferlieze. Ik sil my ûnthâlde fan it typyske "litte wy sizze dat se troch in bus rekke wurde" of in foarbyld brûke dy't de hjoeddeistige kânsen op 'e arbeidsmerk brûke en wat posityfs sizze lykas "se hawwe de lotterij wûn!", om't wy allegear ús diel moatte dwaan om posityf te wêzen dizze dagen.
It ferhaal
Moandeitemoarn komt, en ús analytyske ekspert en kampioen MJ hat har ûntslach yntsjinne. MJ wûn de lotterij en hat it lân al ferlitten sûnder soarch yn 'e wrâld. It team en minsken dy't MJ kenne binne entûsjast en jaloersk, dochs moat it wurk gean. No is it wannear't de wearde en realiteit fan wat MJ dien hat te begripen. MJ wie ferantwurdlik foar de definitive publikaasje en falidaasje fan 'e analytics. Se liken altyd effisjinsje te ferbetterjen of dy lestige feroaring te meitsjen foardat se de analytiken oan elkenien levere. Nimmen soarge echt foar hoe't it dien waard en wie feilich yn it feit dat it krekt barde, en MJ wie in Analytics yndividu Rock Star, sadat in nivo fan autonomy waard jûn. No't it team begjint de stikken op te heljen, de oanfragen, de deistige problemen, de oanfragen foar modifikaasje, binne se op in ferlies en begjinne te scramble. Rapporten / Dashboards wurde fûn yn ûnbekende steaten; guon aktiva net bywurke yn it wykein, en wy witte net wêrom; minsken freegje wat der bart en wannear't dingen sille wurde reparearre, bewurkings dy't MJ sei wiene dien, binne net te sjen en wy hawwe gjin idee wêrom. It team sjocht der min út. It is in ramp en no haatsje wy allegear MJ.
De lessen
D'r binne wat maklike en foar de hân lizzende take-aways.
- Lit in yndividu noait allinich wurkje. Klinkt goed, mar yn lytsere agile teams hawwe wy gjin tiid of de minsken om dit barre te meitsjen. Minsken komme en gean, taken binne in protte, dus it is ferdiele en feroverje yn 'e namme fan produktiviteit.
- Elkenien moat har kennis diele. Klinkt ek goed, mar diele wy mei de juste persoan of minsken? Hâld der rekken mei dat in protte lotterijwinners kollega's binne. It dwaan fan kennisdielen sesjes nimt ek tiid fuort fan taken en de measte minsken ynvestearje allinich yn feardigens en kennis krekt op 'e tiid as it nedich is.
Dus, wat binne wat echte oplossingen dy't elkenien kin kinne ymplementearje en efter komme?
Litte wy begjinne mei konfiguraasjebehear. Wy sille dit brûke as de oerkoepeljende term foar ferskate ferlykbere ûnderwerpen.
- Feroaringsbehear: It proses fan planning, ymplemintaasje en kontrolearjen fan feroaringen oan softwaresystemen op in strukturearre en systematyske manier. Dit proses hat as doel om te soargjen dat feroarings wurde makke op in kontrolearre en effisjinte manier (mei de mooglikheid om werom), mei minimale fersteuring fan it besteande systeem en maksimaal foardiel foar de organisaasje.
- Projektbehear: De planning, organisaasje en kontrôle fan projekten foar softwareûntwikkeling om te soargjen dat se op tiid, binnen budzjet en nei de winske kwaliteitsnormen binne foltôge. It omfettet de koördinaasje fan boarnen, aktiviteiten en taken yn 'e heule libbenssyklus fan softwareûntwikkeling om de projektdoelen te berikken en it softwareprodukt op skema te leverjen.
- Trochrinnende yntegraasje en trochgeande levering (CI / CD): It proses fan it automatisearjen fan it bouwen, testen en ynset fan software. Trochrinnende yntegraasje fereasket it regelmjittich gearfoegjen fan koadewizigingen yn in dielde repository en it útfieren fan automatisearre tests om flaters betiid yn it ûntwikkelingsproses te ûntdekken. Trochrinnende levering / ynset omfettet it automatysk frijlitten fan testen en falidearre koadewizigingen yn produksje, wêrtroch rappe en faak frijlitten fan nije funksjes en ferbetterings mooglik binne.
- Ferzje kontrôle: It proses fan it behearen fan feroaringen oan boarnekoade en oare software-artefakten oer de tiid mei help fan spesjalisearre software-ark. It lit ûntwikkelders gearwurkje oan in koadebase, in folsleine skiednis fan feroaringen behâlde en eksperimintearje mei nije funksjes sûnder de haadkoadebase te beynfloedzjen.
Al it boppesteande ferwize nei goede praktiken foar softwareûntwikkeling. Analytics dy't it bedriuw driuwt en rint, fertsjinje net minder, om't se missy kritysk binne foar beslútfoarming. Alle analytyske aktiva (ETL-taken, semantyske definysjes, metrike-definysjes, rapporten, dashboards, ferhalen ... ensfh) binne gewoan koadefragmenten mei in fisuele ynterface foar ûntwerpen en skynber lytse feroarings kinne ferneatigje op operaasjes.
It brûken fan konfiguraasjebehear beslacht ús om yn in goede steat te rinnen. Assets binne ferzjes, sadat wy kinne sjen wat der bard is yn har libbenspan, wy witte wa't wurket oan wat tegearre mei de makke foarútgong en tiidlinen, en wy witte dat de produksje sil trochgean. Wat net wurdt bedekt troch in suver proses is it oerdragen fan kennis en it begryp fan wêrom't dingen binne sa't se binne.
Elk systeem, database, en analytysk ark hawwe har eigen eigenaardichheden. Dingen dy't har fluch of stadich meitsje, items dy't har op in bepaalde manier gedrage of in winske resultaat produsearje. Dit kinne ynstellings wêze op in systeem of globaal nivo of dingen binnen it asset-ûntwerp dy't meitsje dat se rinne krekt sa't se moatte. It probleem is dat de measte fan dizze dingen yn 'e rin fan' e tiid leard wurde en d'r is net altyd in plak om se te dokumintearjen. Sels as wy ferhúzje nei Cloud-systemen wêr't wy net mear kontrolearje hoe't de applikaasje útfiert en wy fertrouwe op 'e leveransier om it sa rap mooglik te meitsjen, bliuwt de tweaking fan definysjes binnen ús aktiva om krekt te ûntsluten wat wy sykje. Dizze kennis is wat moat wurde fêstlein en dield troch it beskikber te stellen foar oaren. Dizze kennis moat ferplicht wurde as ûnderdiel fan 'e dokumintaasje fan aktiva en makke in yntegraal diel fan' e ferzjekontrôle & CI/CD check-in en goedkarringproses en yn guon gefallen sels as diel fan in checklist foarôfgeand oan publikaasje fan dingen om te dwaan en net dwaan.
D'r binne gjin magyske antwurden of AI om te dekken foar fluchtoetsen yn ús analytyske prosessen of gebrek dêr oan. Nettsjinsteande de grutte fan it team dat hâldt de gegevens en analytics flowing in ynvestearring yn in systeem te folgjen feroarings, ferzje alle aktiva en help te dokumintearjen de ûntwikkeling proses en fêstlizze kennis is in must. Ynvestearje yn prosessen en tiid foarôf sille in ton fergriemde tiid besparje letter dingen út te finen om in sûne steat fan ús analytiken te behâlden. Dingen barre en it is it bêste om in fersekeringsbelied te hawwen foar MJ's en oare lotterijwinners.
