Twee in 'n boks (as jy kan) en almal in dokumentasie (altyd).
In 'n IT-konteks verwys "twee in 'n boks" na twee bedieners of komponente wat ontwerp is om saam te werk om oortolligheid en verhoogde betroubaarheid te verskaf. Hierdie opstelling kan verseker dat indien een komponent misluk, die ander sy bedrywighede sal oorneem en sodoende die kontinuïteit van diens behou. Die doel om "twee in 'n boks" te hê, is om hoë beskikbaarheid en rampherstel te verskaf. Dit geld ook vir menslike rolle in 'n organisasie; dit word egter selde geïmplementeer.
Kom ons kyk na 'n relevante Analytics-voorbeeld. Ons ken almal waarskynlik 'n persoon in ons maatskappy of organisasie by die naam wat die "go-to"-persoon vir Analytics is. Dit is diegene wat verslae of dashboards na hulle vernoem het – Mike's Report of Jane's Dashboard. Sekerlik, daar is ander mense wat analise ken, maar dit is die ware kampioene wat blykbaar weet hoe om die moeilikste dinge gedoen te kry en op sperdatums te oorpresteer. Die probleem is dat hierdie mense alleen staan. In baie gevalle onder druk werk hulle met niemand nie, want dit kan hulle vertraag en dit is waar die probleem begin. Ons dink nooit dat ons hierdie persoon gaan verloor nie. Ek sal my weerhou van die tipiese "kom ons sê hulle word deur 'n bus getref" of gebruik 'n voorbeeld wat die huidige arbeidsmarkgeleenthede benut en iets positiefs sê soos "hulle het die lotto gewen!", want ons moet almal ons deel doen om positief te wees deesdae.
Die storie
Maandagoggend kom, en ons ontledingskenner en kampioen MJ het hul bedanking ingedien. MJ het die lotto gewen en het reeds die land sonder sorg in die wêreld verlaat. Die span en mense wat MJ ken is opgewonde en jaloers, maar werk moet gaan. Dit is nou wanneer die waarde en realiteit van wat MJ gedoen het, op die punt is om verstaan te word. MJ was verantwoordelik vir die finale publikasie en validering van die ontleding. Dit het gelyk of hulle altyd doeltreffendheid kon verbeter of daardie moeilike verandering kon maak voordat hulle die ontledings aan almal verskaf het. Niemand het regtig omgegee hoe dit gedoen word nie en was veilig in die feit dat dit net gebeur het, en MJ was 'n Analytics-individuele Rock Star, so 'n vlak van outonomie is verleen. Noudat die span begin om die stukke, die versoeke, die daaglikse kwessies, die wysigingsversoeke op te tel, is hulle raadop en begin hulle deurmekaar krap. Verslae / Dashboards word in onbekende state gevind; sommige bates het nie die naweek opgedateer nie, en ons weet nie hoekom nie; mense vra wat aangaan en wanneer dinge reggestel sal word, wysigings wat volgens MJ gedoen is, verskyn nie en ons het geen idee hoekom nie. Die span lyk sleg. Dit is 'n ramp en nou haat ons almal MJ.
Die lesse
Daar is 'n paar maklike en ooglopende wegneemetes.
- Moet nooit 'n individu toelaat om alleen te werk nie. Klink goed, maar in kleiner ratse spanne het ons nie tyd of die mense om dit te laat gebeur nie. Mense kom en gaan, take is baie, so dit is verdeel en heers in die naam van produktiwiteit.
- Almal moet hul kennis deel. Klink ook goed, maar deel ons met die regte persoon of mense? Hou in gedagte dat baie loterywenners kollegas is. Om kennisdelingsessies te doen neem ook tyd weg van take en die meeste mense belê net in vaardighede en kennis net betyds wanneer dit nodig is.
So, wat is 'n paar werklike oplossings wat almal in staat kan wees om te implementeer en agter te kom?
Kom ons begin met Configuration Management. Ons sal dit as die sambreelterm vir verskeie soortgelyke onderwerpe gebruik.
- Veranderings bestuur: Die proses van beplanning, implementering en beheer van veranderinge aan sagtewarestelsels op 'n gestruktureerde en sistematiese wyse. Hierdie proses het ten doel om te verseker dat veranderinge op 'n beheerde en doeltreffende wyse aangebring word (met die vermoë om terug te keer), met minimum ontwrigting van die bestaande stelsel en maksimum voordeel vir die organisasie.
- Projekbestuur: Die beplanning, organisasie en beheer van sagteware-ontwikkelingsprojekte om te verseker dat dit betyds, binne begroting en volgens die verlangde kwaliteitstandaarde voltooi word. Dit behels die koördinering van hulpbronne, aktiwiteite en take regdeur die sagteware-ontwikkelingslewensiklus om die projekdoelwitte te bereik en die sagtewareproduk op skedule te lewer.
- Deurlopende integrasie en deurlopende aflewering (CI/CD): Die proses van outomatisering van die bou, toetsing en ontplooiing van sagteware. Deurlopende integrasie vereis dat kodeveranderings gereeld in 'n gedeelde bewaarplek saamgevoeg word en outomatiese toetse uitgevoer word om foute vroeg in die ontwikkelingsproses op te spoor. Deurlopende aflewering/ontplooiing behels die outomatiese vrystelling van getoetste en gevalideerde kodeveranderings in produksie, wat vinnige en gereelde vrystellings van nuwe kenmerke en verbeterings moontlik maak.
- Weergawe beheer: Die proses om veranderinge aan bronkode en ander sagteware-artefakte oor tyd te bestuur deur gespesialiseerde sagteware-nutsmiddels te gebruik. Dit stel ontwikkelaars in staat om aan 'n kodebasis saam te werk, 'n volledige geskiedenis van veranderinge te handhaaf en met nuwe kenmerke te eksperimenteer sonder om die hoofkodebasis te beïnvloed.
Al die bogenoemde verwys na goeie sagteware-ontwikkelingspraktyke. Ontledings wat die besigheid dryf en bestuur, verdien niks minder nie, aangesien dit missiekrities is vir besluitneming. Al die analitiese bates (ETL-take, semantiese definisies, statistieke-definisies, verslae, dashboards, stories ... ens.) is net kodebrokkies met 'n visuele koppelvlak vir ontwerp en oënskynlik geringe veranderinge kan verwoesting op bedrywighede veroorsaak.
Die gebruik van konfigurasiebestuur dek ons om in 'n goeie toestand aan te hou hardloop. Bates is versier sodat ons kan sien wat in hul lewensduur gebeur het, ons weet wie aan wat werk saam met die vordering wat gemaak is en tydlyne, en ons weet dat die produksie sal voortgaan. Wat nie deur enige suiwer proses gedek word nie, is die oordrag van kennis en die begrip van hoekom dinge is soos dit is.
Elke stelsel, databasis en analise-instrument het hul eie eienaardighede. Dinge wat hulle vinnig of stadig laat gaan, items wat hulle op 'n sekere manier laat optree of 'n gewenste resultaat lewer. Dit kan instellings op 'n stelsel- of globale vlak of dinge binne die bate-ontwerp wees wat hulle laat loop net soos hulle moet. Die probleem is dat die meeste van hierdie dinge mettertyd aangeleer word en daar is nie altyd 'n plek om dit te dokumenteer nie. Selfs al beweeg ons na Wolkstelsels waar ons nie meer beheer hoe die toepassing uitgevoer word nie en ons staatmaak op die verskaffer om dit so vinnig as moontlik te maak, gaan die aanpassing van definisies voort binne ons bates om presies te ontsluit waarna ons soek. Hierdie kennis is wat vasgelê en gedeel moet word deur dit aan ander beskikbaar te stel. Hierdie kennis moet vereis word as deel van die dokumentasie van bates en 'n integrale deel gemaak word van die weergawebeheer & CI/CD-aanmelding en goedkeuringsproses en in sommige gevalle selfs as deel van 'n kontrolelys voor publikasie van dinge om te doen en nie doen.
Daar is geen magiese antwoorde of KI om te bedek vir kortpaaie in ons ontledingsprosesse of gebrek daaraan nie. Ongeag die grootte van die span wat die data en ontledings laat vloei, is 'n belegging in 'n stelsel om veranderinge op te spoor, weergawe van alle bates en help om die ontwikkelingsproses te dokumenteer en kennis vas te lê. Belegging in prosesse en tyd vooraf sal 'n ton vermorsde tyd bespaar om later dinge uit te vind om 'n gesonde toestand van ons analise te handhaaf. Dinge gebeur en dit is die beste om 'n versekeringspolis vir MJ's en ander loterywenners te hê.
