Divi kastē (ja varat) un visi dokumentācijā (vienmēr).
IT kontekstā “divi kastē” attiecas uz diviem serveriem vai komponentiem, kas paredzēti darbam kopā, lai nodrošinātu dublēšanu un paaugstinātu uzticamību. Šī iestatīšana var nodrošināt, ka, ja viens komponents neizdodas, otrs pārņems tā darbību, tādējādi saglabājot pakalpojuma nepārtrauktību. “Divi vienā kastē” mērķis ir nodrošināt augstu pieejamību un atkopšanu pēc avārijas. Tas attiecas arī uz cilvēku lomām organizācijā; tomēr tas tiek īstenots reti.
Apskatīsim atbilstošu Analytics piemēru. Mēs visi, visticamāk, zinām kādu personu savā uzņēmumā vai organizācijā, kura ir Analytics vajadzīgā persona. Viņi ir tie, kuru vārdā ir nosaukti pārskati vai informācijas paneļi — Maika ziņojums vai Džeinas informācijas panelis. Protams, ir arī citi cilvēki, kas zina analīzi, taču šie ir īstie čempioni, kuri, šķiet, zina, kā paveikt grūtākās lietas un pārspēt noteiktos termiņus. Problēma ir tāda, ka šie cilvēki ir vieni. Daudzos gadījumos zem spiediena viņi nesadarbojas ar nevienu, jo tas var viņus palēnināt, un šeit sākas problēma. Mēs nekad nedomājam, ka pazaudēsim šo cilvēku. Es atturēšos no tipiskā “pieņemsim, ka viņus notrieca autobuss” vai izmantošu piemēru, izmantojot pašreizējās darba tirgus iespējas, un teikšu kaut ko pozitīvu, piemēram, “viņi uzvarēja loterijā!”, jo mums visiem būtu jādara savs darbs, lai būtu pozitīvi. šajās dienās.
CUBE Furnit stāsts
Pienāk pirmdienas rīts, un mūsu analītikas eksperts un čempions MJ ir iesniedzis atlūgumu. MJ uzvarēja loterijā un jau ir atstājis valsti bez aprūpes pasaulē. Komanda un cilvēki, kas pazīst MJ, ir sajūsmā un greizsirdīgi, tomēr darbam ir jāiet. Tagad ir pienācis laiks saprast MJ darīšanas vērtību un realitāti. MJ bija atbildīgs par analītikas galīgo publicēšanu un apstiprināšanu. Viņi vienmēr šķita, ka spēj uzlabot efektivitāti vai veikt šīs sarežģītās izmaiņas, pirms visiem sniedza analīzi. Nevienu īsti neinteresēja, kā tas tika paveikts, un viņš bija drošs, ka tas tikko notika, un MJ bija Analytics individuālais rokzvaigzne, tāpēc tika piešķirta zināma autonomija. Tagad, kad komanda sāk vākt gabalus, pieprasījumus, ikdienas problēmas, modifikācijas pieprasījumus, viņi ir zaudējuši un sāk lauzties. Pārskati / informācijas paneļi ir atrodami nezināmos stāvokļos; daži līdzekļi netika atjaunināti nedēļas nogalē, un mēs nezinām, kāpēc; cilvēki jautā, kas notiek un kad lietas tiks labotas, neparādās labojumi, par kuriem MJ teica, ka ir izdarīti, un mums nav ne jausmas, kāpēc. Komanda izskatās slikti. Tā ir katastrofa, un tagad mēs visi ienīstam MJ.
Nodarbības
Ir dažas vienkāršas un acīmredzamas izņemšanas iespējas.
- Nekad neļaujiet personai strādāt vienatnē. Izklausās labi, bet mazākās veiklās komandās mums nav ne laika, ne cilvēku, lai tas notiktu. Cilvēki nāk un iet, uzdevumu ir daudz, tāpēc produktivitātes vārdā ir šķirties un valdīt.
- Ikvienam ir jādalās savās zināšanās. Arī izklausās labi, bet vai mēs dalāmies ar pareizo personu vai cilvēkiem? Ņemiet vērā, ka daudzi loterijas uzvarētāji ir kolēģi. Zināšanu apmaiņas sesijas arī atņem laiku no uzdevumiem, un lielākā daļa cilvēku iegulda prasmēs un zināšanās tikai tad, kad tas ir nepieciešams.
Tātad, kādi ir daži reāli risinājumi, kurus ikviens var īstenot un aizmirst?
Sāksim ar konfigurācijas pārvaldību. Mēs to izmantosim kā vispārīgu terminu vairākām līdzīgām tēmām.
- Pārmaiņu vadība: Programmatūras sistēmu izmaiņu plānošanas, ieviešanas un kontroles process strukturētā un sistemātiskā veidā. Šī procesa mērķis ir nodrošināt, ka izmaiņas tiek veiktas kontrolēti un efektīvi (ar iespēju atgriezties), minimāli traucējot esošo sistēmu un sniedzot maksimālu labumu organizācijai.
- Projektu vadība: Programmatūras izstrādes projektu plānošana, organizēšana un kontrole, lai nodrošinātu, ka tie tiek pabeigti laikā, budžeta ietvaros un atbilstoši vēlamajiem kvalitātes standartiem. Tas ietver resursu, darbību un uzdevumu koordinēšanu visā programmatūras izstrādes dzīves ciklā, lai sasniegtu projekta mērķus un piegādātu programmatūras produktu pēc grafika.
- Nepārtraukta integrācija un nepārtraukta piegāde (CI/CD): Programmatūras izveides, testēšanas un izvietošanas automatizācijas process. Lai nodrošinātu nepārtrauktu integrāciju, regulāri jāapvieno koda izmaiņas koplietotā repozitorijā un jāveic automatizēti testi, lai izstrādes procesa sākumā atklātu kļūdas. Nepārtraukta piegāde/izvietošana ietver pārbaudītu un apstiprinātu koda izmaiņu automātisku izlaišanu ražošanā, ļaujot ātri un bieži izlaist jaunas funkcijas un uzlabojumus.
- Versijas kontrole: Avota koda un citu programmatūras artefaktu izmaiņu pārvaldības process laika gaitā, izmantojot specializētus programmatūras rīkus. Tas ļauj izstrādātājiem sadarboties kodu bāzē, saglabāt pilnīgu izmaiņu vēsturi un eksperimentēt ar jaunām funkcijām, neietekmējot galveno kodu bāzi.
Viss iepriekš minētais attiecas uz labu programmatūras izstrādes praksi. Analīzes, kas virza un vada biznesu, ir pelnījušas ne mazāk, jo tām ir izšķiroša nozīme lēmumu pieņemšanā. Visi analītikas līdzekļi (ETL darbi, semantiskās definīcijas, metrikas definīcijas, atskaites, informācijas paneļi, stāsti utt.) ir tikai koda fragmenti ar vizuālu saskarni projektēšanai, un šķietami nelielas izmaiņas var radīt postījumus operācijām.
Izmantojot konfigurācijas pārvaldību, mēs varam turpināt darboties labā stāvoklī. Līdzekļu versijas ir paredzētas, lai mēs varētu redzēt, kas ir noticis to dzīves laikā, mēs zinām, kas pie kā strādā, kā arī panākto progresu un laika grafikus, un mēs zinām, ka ražošana turpināsies. Tas, ko neaptver neviens tīrs process, ir zināšanu nodošana un izpratne par to, kāpēc lietas ir tā, kā tās ir.
Katrai sistēmai, datubāzei un analīzes rīkam ir savas īpatnības. Lietas, kas liek tiem iet ātri vai lēni, priekšmeti, kas liek tiem uzvesties noteiktā veidā vai rada vēlamo rezultātu. Tie var būt iestatījumi sistēmas vai globālā līmenī vai lietas līdzekļu dizainā, kas liek tiem darboties tieši tā, kā vajadzētu. Problēma ir tā, ka lielākā daļa no šīm lietām tiek apgūtas laika gaitā, un ne vienmēr ir vieta, kur tās dokumentēt. Pat tad, kad mēs pārejam uz mākoņsistēmām, kur mēs vairs nekontrolējam lietojumprogrammas izpildi, un mēs paļaujamies uz piegādātāju, lai tas būtu pēc iespējas ātrāks, definīciju pielāgošana mūsu resursos turpinās, lai atklātu tieši to, ko meklējam. Šīs zināšanas ir jāapgūst un jādalās, padarot tās pieejamas citiem. Šīs zināšanas ir jāpieprasa kā daļu no aktīvu dokumentācijas un jāiekļauj versiju kontroles un CI/CD reģistrēšanās un apstiprināšanas procesā, un dažos gadījumos pat kā daļa no kontrolsaraksta pirms publicēšanas par lietām, kas jādara un kuras nav jādara. darīt.
Nav maģisku atbilžu vai AI, kas slēptu saīsnes mūsu analītikas procesos vai to trūkumu. Neatkarīgi no komandas lieluma, kas nodrošina datu un analītikas plūsmu, ir nepieciešams ieguldījums sistēmā, lai izsekotu izmaiņām, versētu visus līdzekļus un palīdzētu dokumentēt izstrādes procesu un iegūt zināšanas. Ieguldījumi procesos un laikā ietaupīs daudz laika, kas vēlāk jāizdomā, lai saglabātu veselīgu mūsu analītikas stāvokli. Lietas notiek, un vislabāk ir iegūt apdrošināšanas polisi MJ un citiem loterijas uzvarētājiem.
