Dy në një kuti - Menaxhimi i konfigurimit

Dy në një kuti (nëse mundeni) dhe të gjithë në dokumentacion (gjithmonë).

Në një kontekst IT, "dy në një kuti" i referohet dy serverëve ose komponentëve që janë krijuar për të punuar së bashku për të ofruar tepricë dhe besueshmëri të shtuar. Ky konfigurim mund të sigurojë që nëse një komponent dështon, tjetri do të marrë përsipër operacionet e tij, duke ruajtur kështu vazhdimësinë e shërbimit. Qëllimi i të pasurit "dy në një kuti" është të sigurojë disponueshmëri të lartë dhe rikuperim nga fatkeqësitë. Kjo vlen edhe për rolet njerëzore në një organizatë; megjithatë, ai zbatohet rrallë.

Le të shohim një shembull përkatës të Analytics. Ne të gjithë ka të ngjarë të njohim një person në kompaninë ose organizatën tonë me emër, i cili është personi "i drejtueshëm" për Analytics. Ata janë ata që kanë raporte ose tabela me emrin e tyre - Raporti i Mike ose Paneli i Jane. Sigurisht, ka njerëz të tjerë që dinë analitikë, por këta janë kampionët e vërtetë që duket se dinë të bëjnë gjërat më të vështira dhe t'i arrijnë afatet. Çështja është se këta njerëz qëndrojnë vetëm. Në shumë raste nën presion, ata nuk punojnë me askënd pasi kjo mund t'i ngadalësojë ata dhe këtu fillon problemi. Asnjëherë nuk mendojmë se do ta humbasim këtë person. Unë do të përmbahem nga tipike "le të themi se ata goditen nga një autobus" ose duke përdorur një shembull duke shfrytëzuar mundësitë aktuale të tregut të punës dhe do të them diçka pozitive si "ata fituan llotarinë!", sepse ne të gjithë duhet të bëjmë pjesën tonë për të qenë pozitiv. keto dite.

Historia
Vjen mëngjesi i së hënës dhe eksperti ynë i analitikës dhe kampioni MJ ka dorëzuar dorëheqjen. MJ fitoi lotarinë dhe tashmë është larguar nga vendi pa kujdes në botë. Ekipi dhe njerëzit që e njohin MJ janë të emocionuar dhe xhelozë, por puna duhet të shkojë. Tani është kur do të kuptohet vlera dhe realiteti i asaj që MJ po bënte. MJ ishte përgjegjës për publikimin përfundimtar dhe vërtetimin e analitikës. Ata gjithmonë dukej se ishin në gjendje të përmirësonin efikasitetin ose të bënin atë ndryshim të vështirë përpara se të furnizonin analitikën për të gjithë. Askush nuk u interesua vërtet se si u realizua dhe ishte i sigurt për faktin se sapo ndodhi, dhe MJ ishte një Rock Star individual i Analytics, kështu që iu dha një nivel autonomie. Tani, ndërsa ekipi fillon të marrë pjesët, kërkesat, problemet e përditshme, kërkesat për modifikim, ata janë në humbje dhe fillojnë të grinden. Raportet / panelet e kontrollit gjenden në gjendje të panjohura; disa asete nuk u përditësuan gjatë fundjavës dhe ne nuk e dimë pse; njerëzit po pyesin se çfarë po ndodh dhe kur gjërat do të rregullohen, redaktimet që MJ tha se ishin kryer nuk po shfaqen dhe ne nuk e dimë pse. Skuadra duket e keqe. Është një fatkeqësi dhe tani ne të gjithë e urrejmë MJ.

Mësimet
Ka disa heqje të lehta dhe të dukshme.

1. Asnjëherë mos lejoni që një individ të punojë vetëm. Tingëllon mirë, por në ekipet më të vogla të shkathët, ne nuk kemi kohë apo njerëz për ta bërë këtë të ndodhë. Njerëzit vijnë e shkojnë, detyrat janë të shumta, ndaj është përça dhe pushto në emër të produktivitetit.
2. Të gjithë duhet të ndajnë njohuritë e tyre. Gjithashtu tingëllon mirë, por a po ndajmë me personin apo njerëzit e duhur? Mbani në mend se shumë fitues të lotarisë janë bashkëpunëtorë. Bërja e seancave të shkëmbimit të njohurive kërkon gjithashtu kohë larg detyrave dhe shumica e njerëzve investojnë vetëm në aftësi dhe njohuri në kohën kur është e nevojshme.

Pra, cilat janë disa zgjidhje reale që të gjithë mund të jenë në gjendje t'i zbatojnë dhe të marrin prapa?
Le të fillojmë me Menaxhimin e Konfigurimit. Ne do ta përdorim këtë si term ombrellë për disa tema të ngjashme.

1. Menaxhimi i ndryshimit: Procesi i planifikimit, zbatimit dhe kontrollit të ndryshimeve në sistemet softuerike në mënyrë të strukturuar dhe sistematike. Ky proces synon të sigurojë që ndryshimet të bëhen në mënyrë të kontrolluar dhe efikase (me aftësinë për t'u rikthyer), me ndërprerje minimale në sistemin ekzistues dhe përfitim maksimal për organizatën.
2. Menaxhimi i projektit: Planifikimi, organizimi dhe kontrolli i projekteve të zhvillimit të softuerit për të siguruar që ato të përfundojnë në kohë, brenda buxhetit dhe sipas standardeve të dëshiruara të cilësisë. Ai përfshin koordinimin e burimeve, aktiviteteve dhe detyrave gjatë gjithë ciklit jetësor të zhvillimit të softuerit për të arritur objektivat e projektit dhe për të ofruar produktin e softuerit sipas planit.
3. Integrimi i vazhdueshëm dhe shpërndarja e vazhdueshme (CI/CD): Procesi i automatizimit të ndërtimit, testimit dhe vendosjes së softuerit. Integrimi i vazhdueshëm kërkon shkrirjen e rregullt të ndryshimeve të kodit në një depo të përbashkët dhe ekzekutimin e testeve të automatizuara për të zbuluar gabimet në fillim të procesit të zhvillimit. Dorëzimi/Shpërndarja e vazhdueshme përfshin lëshimin automatik të ndryshimeve të kodit të testuar dhe të vlefshëm në prodhim, duke lejuar lëshime të shpejta dhe të shpeshta të veçorive dhe përmirësimeve të reja.
4. Kontrolli i versionit: Procesi i menaxhimit të ndryshimeve në kodin burimor dhe objekte të tjera të softuerit me kalimin e kohës duke përdorur mjete të specializuara softuerike. Ai i lejon zhvilluesit të bashkëpunojnë në një bazë kodesh, të mbajnë një histori të plotë ndryshimesh dhe të eksperimentojnë me veçori të reja pa ndikuar në bazën kryesore të kodeve.

Të gjitha sa më sipër i referohen praktikave të mira të zhvillimit të softuerit. Analitikat që drejtojnë dhe drejtojnë biznesin meritojnë jo më pak pasi janë mision kritik për vendimmarrjen. Të gjitha asetet e analitikës (punët ETL, përkufizimet semantike, përkufizimet e metrikës, raportet, tabelat e kontrollit, tregimet...etj) janë vetëm copa kodi me një ndërfaqe vizuale për dizajnim dhe ndryshimet në dukje të vogla mund të shkaktojnë kërdi në operacione.

Përdorimi i Menaxhimit të Konfigurimit na mbulon që të vazhdojmë të funksionojmë në një gjendje të mirë. Asetet janë versionuar kështu që ne mund të shohim se çfarë ka ndodhur në jetëgjatësinë e tyre, ne e dimë se kush po punon për çfarë së bashku me përparimin e bërë dhe afatet kohore, dhe ne e dimë se prodhimi do të vazhdojë. Ajo që nuk mbulohet nga asnjë proces i pastër është transferimi i njohurive dhe të kuptuarit se pse gjërat janë ashtu siç janë.

Çdo sistem, bazë të dhënash dhe mjet analitik ka veçoritë e veta. Gjërat që i bëjnë ata të ecin shpejt ose ngadalë, artikuj që i bëjnë ata të sillen në një mënyrë të caktuar ose të prodhojnë një rezultat të dëshiruar. Këto mund të jenë cilësime në një nivel sistemi ose global ose gjëra brenda dizajnit të aseteve që i bëjnë ato të funksionojnë ashtu siç duhet. Problemi është se shumica e këtyre gjërave mësohen me kalimin e kohës dhe nuk ka gjithmonë një vend për t'i dokumentuar ato. Edhe kur kalojmë në sistemet Cloud ku nuk kontrollojmë më se si ekzekutohet aplikacioni dhe mbështetemi te furnizuesi për ta bërë atë sa më shpejt të jetë e mundur, rregullimi i përkufizimeve vazhdon brenda aseteve tona për të zhbllokuar pikërisht atë që kërkojmë. Kjo njohuri është ajo që duhet të kapet dhe të ndahet duke e vënë në dispozicion të të tjerëve. Kjo njohuri duhet të kërkohet si pjesë e dokumentacionit të aseteve dhe të bëhet pjesë integrale e procesit të kontrollit të versionit dhe kontrollit CI/CD dhe miratimit dhe në disa raste edhe si pjesë e një liste kontrolli përpara se të publikohen gjërat për të bërë dhe jo. bëj.

Nuk ka përgjigje magjike ose AI për të mbuluar shkurtoret në proceset tona analitike ose mungesë të tyre. Pavarësisht nga madhësia e ekipit që mban të dhënat dhe analitikën të rrjedhin një investim në një sistem për të gjurmuar ndryshimet, versioni i të gjitha aseteve dhe ndihma për dokumentimin e procesit të zhvillimit dhe kapjen e njohurive është një domosdoshmëri. Investimi në procese dhe kohë përpara do të kursejë një ton kohë të humbur më vonë për të kuptuar gjërat për të mbajtur një gjendje të shëndetshme të analitikës sonë. Gjërat ndodhin dhe është më mirë të keni një politikë sigurimi për MJ-të dhe fituesit e tjerë të lotarisë.