en praktisk vej til DevOps modenhed

enhver agil metode er forgæves uden ægte DevOps praksis. Ordet blev misbrugt i mange organisationer. Hvis du siger, at du har modnet agile teams, og du har en DevOps engineer eller DevOps team, som sandsynligvis ikke går i den rigtige retning. DevOps er en kultur snarere end et holdnavn eller betegnelse. Tager en cue fra CMM (Capability Maturity Model) dette forsøg er at hjælpe en organisation til at vide, hvor de står i en DevOps rejse og vej frem. Med en vis brainstorm mellem udviklings-og Ops-teams kan dette udvides og tilpasses organisationens behov.

intet tal er dårligt, da det hjælper en person eller organisation med at vokse.

glad kunde

i modsætning til CMM er dette ikke en model, som du skal bevise for nogen certificeringsorganisation. Det eneste certifikat, Du får, er fra dine glade kunder eller forretningspartnere. Det er en model til selv at reflektere og hjælpe virksomheden med at vokse. Selve formålet med ethvert IT-team er at skabe værdi ved at gøre bæredygtig, forudsigelig levering med kvalitet.

dette er en simpel model, der fra udvikler til CCO kan forstå og relatere.

før jeg diskuterer om modellen. Vi er nødt til at forstå behovet for denne model. For mange år siden kom Melvin i sit papir “hvordan opfinder udvalg?”kom op med afhandling, der blev berømt som convey lov.

enhver organisation, der designer et system (defineret bredt), vil producere et design, hvis struktur er en kopi af organisationens kommunikationsstruktur.

loven er baseret på den begrundelse, at for at programmodulerne skal fungere, skal flere personer kommunikere ofte med hinanden. Derfor vil et systems programgrænsefladestruktur afspejle de sociale grænser for den eller de organisationer, der producerede det, på tværs af hvilken kommunikation er vanskeligere.

lad os se på, hvordan dette virker i programmel udvikling med en reel scenario. Radha bygger en frontend-skærm, der viser detaljerede attributter for et produkt. Sig, at dette produkt er en mobiltelefon. Få almindelige produktdetaljer er farve, pris, dimensioner, vurderinger osv. En ny regulering kom til at vise SAR-værdien af håndsættet. Skærmen, som hun designet arbejder med micro service call. Hun talte med Sunil, der arbejder i data team. Han sagde, at de kun kan sende data i flad fil. Der er en klar afbrydelse mellem to moduler. Dette er et scenarie, som hvert IT-team støder på, hvis ikke alle 100% gange, men de fleste gange. Det er bare et designproblem. Problemet er bredere. Hvad hvis det andet holds prioriteter er meget forskellige fra, hvad dit team laver? Dine krav kan være lavest prioriteret for dem, mens dine interessenter kører bag dig.

det første skridt til en vellykket implementering af DevOps er at være åben med organisationsændringer.

organisationsændringer

lad mig diskutere 5 niveauer af modenhed:

  1. Indledende: i denne fase arbejder teams i siloer, og der er kun behov for baseret samarbejde. I et møde med alle holdene sammen, hvis du spørger, hvem der ejer “produktet”, vil du ikke have nogen hænder at hæve. Tid til markedet er typisk længere, går til måneder og nogle gange år. Prioriteringer er fastsat på teamniveau, men ikke på produktniveau. Dette vil føre til, at hvert hold har deres egne prioriteter. Da der ikke er nogen defineret proces, er ethvert forsøg som at genopfinde hjulet. Dette vil føre til kvalitetsproblemer og længere tidslinjer. Team gør for det meste manuelle implementeringer og manuelle indgreb. Godt.. dette er ikke en dårlig tilstand. Sådan ville det meste af udviklingen starte.

2. Gentagelig: hold arbejder stadig i siloer. Der er en vis grad af automatisering i teamet. Når en krise rammer, definerer teamet deres egen proces og følger, indtil krisen slutter. Kun gode nyheder er, at nogle af disse kan blive gentagelige processer, når krisen rammer igen.

3. Defineret: dette er et godt udgangspunkt for frø DevOps kultur med et centraliseret team. Dette team forstår forskellige teknologier, som Dev-teams bruger, og værktøj er baseret på det aktuelle behov. At være et centraliseret team, det er ikke let at overvåge, hvad hvert hold laver, og derfor overlades nogle beslutninger til holdene at eksperimentere. Central team består typisk af eksperter og dev teams vil have nogle mennesker med grundlæggende forståelse og viden.

4. Administreret: da det centrale DevOps-team forstår organisationsværktøjslandskab, testes flere miljøer og værktøjer. Konsistente og gentagelige processer følges af flere teams. Værktøjskæde vælges ud fra brugssager snarere end personlige valg. Overvågningsværktøjer til alle processer introduceres og bruges stærkt af teams til at træffe beslutninger.

5. Optimeret:

succes for en god leder defineres ved ikke at have tilhængere, men ved evnen til at skabe store ledere.

sidste fase af DevOps modenhed er at få DevOps-holdet til at forsvinde. Dette kan se ud som counter intuitiv. På dette stadium er DevOps en del af produktudviklingsteam snarere end en separat enhed. Brug af infrastruktur som kode, containere, orkestrering osv. nul touch implementering er opnået. Nu, hvis du ringer til alle, der arbejder på et produkt og spørger, hvem der ejer produktet, vil du have nogle sikre hænder, der rejser uden tøven. Data fra overvågningsværktøjer bruges til at vælge nyt sæt værktøjer (herunder infrastruktur, programmeringssprog, teknikker). Beslutninger er baseret på data snarere end personlige præferencer. Produkt team er klar til at implementere kode enhver dag og når som helst. De elsker “forretningsværdien” og behandler det som et kæledyr. Alt andet behandles som kvæg.

DevOps Modenhed Model.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.