Pirms dažiem gadiem daudzas organizācijas uzskatīja DevOps par daudzsološu eksperimentu, nevis par galveno pieeju programmatūras izstrādei. DevOps tagad ir pārbaudīts un spēcīgs izstrādes un ieviešanas prakses un rīku komplekts, kas var paātrināt jaunu produktu izlaišanu un palielināt produktivitāti. Vēl svarīgāk ir tas, ka DevOps ietekme uz vispārējo biznesa izaugsmi un palielinātu rentabilitāti.
Komanda tulkots interesantākais no , ko apkopojuši DevOps Research & Assessment (DORA) eksperti. Pētījumā piedalījās 31 000 speciālistu no visas pasaules. Apskatīsim, kas 2019. gadā mainījās nozarē un kā uzņēmumi var uzlabot programmatūras piegādes efektivitāti.
Kā nozare un uzņēmuma lielums ietekmē DevOps stāvokli
Pētījumā netika atklāta korelācija starp DevOps veiktspēju un organizācijas nozari, izņemot mazumtirdzniecību, kuras darbība bija nedaudz labāka. Tas jo īpaši ir saistīts ar faktu, ka mazumtirgotājiem ātri jāreaģē uz pieprasījuma svārstībām un klientu vajadzībām. Saskaņā ar pētījumu jebkurš uzņēmums var sasniegt augstu DevOps līmeni, tostarp finanšu sektorā un publiskajā sektorā.
DevOps veiktspēja uzņēmumos ar vairāk nekā 5000 darbiniekiem bija zemāka nekā uzņēmumos ar mazāk nekā 5000 darbiniekiem. Visticamāk, tas ir saistīts ar to, ka lielajās organizācijās ir lielāki procesi, stingrāka kontrole un sarežģītāka IT sistēmu arhitektūra, kas ievieš aizkavēšanos koda izstrādes un ieviešanas procesā. Tajā pašā laikā eksperti uzskata, ka uzņēmuma mērogs netraucē veiksmi DevOps veidošanā, tikai dažos gadījumos tas var prasīt vairāk pūļu.
Kā novērtēt DevOps līmeni uzņēmumā
Eksperti salīdzināja DevOps procesus ar etalonu, sadalot aptaujas respondentus četrās grupās ar labākajiem, labiem, vidējiem un sliktiem rezultātiem.
Pārskatam mēs izmantojām četrus galvenos rādītājus, lai novērtētu DevOps efektivitāti: laiks, lai pabeigtu izmaiņas programmatūras izstrādē, izvietošanas biežums, kļūmju līmenis un atkopšanas laiks.
Četri DevOps līmeņi — novērtējiet, kur atrodas jūsu uzņēmums:
Metrika programmatūras piegādes efektivitātes novērtēšanai uzņēmuma galvenajiem pakalpojumiem un lietojumprogrammām
Komandas ar labākajiem rekordiem
Komandas ar labu sniegumu
Vidējās komandas
Zemas veiktspējas komandas
Izvietošanas biežums
Cik bieži uzņēmums izvieto kodu ražošanā vai izlaiž to galalietotājiem.
Pēc pieprasījuma vairākas izvietošanas dienā
No vienas reizes dienā līdz reizei nedēļā
No vienas reizes nedēļā līdz reizei mēnesī
Reizi mēnesī/vairākos mēnešos
Mainiet izpildes laiku
Cik ilgs laiks nepieciešams, lai pārietu no testa uz programmatūru, kas veiksmīgi darbojas ražošanā?
Mazāk nekā dienā
No vienas dienas līdz nedēļai
No vienas nedēļas līdz mēnesim
No mēneša līdz sešiem mēnešiem
Pakalpojuma atjaunošanas laiks
Cik ilgs laiks nepieciešams, lai atjaunotu pakalpojumu pēc incidenta vai kļūdas, kas ietekmē lietotājus.
Mazāk par stundu
Dienas laikā
Pēc nedēļas
No nedēļas līdz mēnesim
Mainiet neveiksmju līmeni
Cik procentuālo daļu atjauninājumu vai jaunu laidienu tiek pasliktināts pakalpojums un ir nepieciešami labojumi?
0-15%
0-15%
0-15%
46-60%
Pētījums atklāja šādu tendenci: augsti produktīvo komandu skaits gandrīz trīskāršojās, palielinoties no 7% no visiem respondentiem 2018. gadā līdz 20% 2019. gadā.
Attīstības komandu sadalījums pēc veiktspējas līmeņa.
Salīdzinot ar komandām grupā ar zemu veiktspēju, DevOps komandas ar augstu veiktspēju:
- Veikts 208 reizes vairāk koda izvietošanas.
- Koda izvietošanai pavadīja 106 reizes mazāk laika.
- Ar neveiksmēm saskārāmies 7 reizes retāk.
- Programmatūra pēc kļūmēm tika atjaunota 2,604 reizes ātrāk.
Turklāt augstas veiktspējas DevOps komandām ir divreiz lielāka iespēja sasniegt vai pārsniegt savus organizācijas veiktspējas rādītājus nekā komandām ar zemu veiktspēju.
Daudzi eksperti uzskata, ka nav iespējams panākt visu rādītāju pieaugumu vienlaikus; Tādējādi daži uzskata, ka izlaišanas ātruma palielināšana var negatīvi ietekmēt programmatūras piegādes procesa uzticamību un pakalpojumu sniegšanu. Tomēr pētījumi ir parādījuši, ka rezultātu ātrums un konsekvence neizslēdz viens otru.
Es neredzu neko pārsteidzošu DevOps komandu skaita pieaugumā, tas ir dabiski: DevOps filozofija tagad ir populāra, un jaunuzņēmumu skaits pieaug.
Bet, manuprāt, eksperti DevOps efektivitātes novērtēšanai izvēlējās ne gluži pareizus parametrus.
Novērtēt to, pamatojoties uz koda izlaišanas ātrumu, ir, maigi izsakoties, dīvaini. Tas attiecas tikai uz jaunizveidotiem uzņēmumiem, kur galvenais parametrs būs produkta ieviešanas tirgū ātrums, un bieži vien produkts tiek laists klajā neapstrādātā veidā. Šādos apstākļos ļoti svarīgi ir mehānismi, kas paātrina izstrādi un piegādi ražošanā. Taču izveidotai programmatūrai, piemēram, finanšu vai medicīnas programmatūrai, kļūmju līmeņa parametrs var nebūt — kļūmes var būt nepieņemamas.
Tas pats attiecas uz pakalpojumu atkopšanas laiku: jebkuram izstrādātam pakalpojumam tas jāaprēķina sekundēs, bet daudziem pakalpojumiem dīkstāves nav pieņemamas šim nolūkam, tika izgudrotas viengabalainas ieviešanas tehnoloģijas (piemēram, zaļā/zilā).
Tāpat nevajadzētu koncentrēties uz koda izvietošanas reižu skaitu – tas ir atkarīgs no izstrādes komandas vajadzībām un kompetencēm. Ja izvietošana ietver jaunas funkcionalitātes pievienošanu, tā ir viena lieta, bet, ja tā ietver iepriekšējo izvietošanas laikā pieļauto kļūdu labošanu, tas ir pavisam kas cits.
Deniss Romaņenko, Mail.ru Cloud Solutions ārštata eksperts
Kā uzlabot DevOps procesus
Ziņojumā ir izklāstītas divas jomas, kas palīdzēs uzlabot DevOps: palielināt programmatūras izstrādes un piegādes efektivitāti un uzlabot darbinieku produktivitāti.
Katra no jomām ietver savas sastāvdaļas, kuras pilnveidojot var sasniegt vēlamo mērķi.
Saskaņā ar ziņojumu digitālās transformācijas atslēga ir korporatīvā kultūra. Augstas veiktspējas DevOps komandām ir nepieciešama uzticības kultūra un psiholoģiskā drošība, veiktspējas sajūta un skaidri mērķi. Šī vide ļauj komandas locekļiem pieņemt pārdomātus lēmumus, paust savu viedokli un būt radošākiem.
Mākoņtehnoloģijas, nepārtraukta piegāde, avārijas atkopšanas testēšana un izmaiņu pārvaldība arī palīdzēs uzlabot programmatūras izstrādes un piegādes efektivitāti. Produktivitāti var palielināt, ieguldot viegli lietojamos rīkos, samazinot tehniskos parādus, tas ir, samazinot neefektīva koda un novecojušo tehnoloģiju procentuālo daļu, organizējot korporatīvo zināšanu bāzi un piekļuvi ārējiem risinājumiem.
Es domāju, ka DevOps metodoloģija un ideoloģija ir tieši tāda, ka šie procesi nav atkarīgi no ārējiem apstākļiem, piemēram, mākoņa vai jūsu pašu aparatūras. Pats mākonis ir nekas vairāk kā instruments dažviet tas palīdzēs, citās traucēs vai nebūs pieprasīts.
Deniss Romaņenko, Mail.ru Cloud Solutions ārštata eksperts
Tālāk apskatīsim dažus DevOps komandu efektivitātes uzlabošanas komponentus.
Mākoņu tehnoloģijas nodrošina DevOps panākumus
2019. gadā arvien vairāk organizāciju izvēlas mākoņrisinājumus, kas būtiski palielina DevOps komandu produktivitāti.
Kādas infrastruktūras izmanto DevOps komandas?
DORA konstatēja, ka 80% aptaujāto vietu . Tomēr tikai 29% respondentu ir ieviesuši visus piecus Nacionālā standartu un tehnoloģiju institūta galvenos mākoņdatošanas parametrus — vissvarīgāko standartu mākoņa vērtības novērtēšanai DevOps ietvaros.
Raksturošana
Lietotāju procentuālā daļa
Pašapkalpošanās pēc pieprasījuma
Patērētāji var automātiski nodrošināt skaitļošanas resursus
pēc vajadzības, bez pakalpojumu sniedzēja līdzdalības.
57%
(+ 11% kopš 2018. gada)
Plaša piekļuve tīklam
Mākoņa iespējas ir pieejamas dažādās platformās,
piemēram, mobilie tālruņi, planšetdatori, klēpjdatori un darbstacijas.
60%
(+ 14% kopš 2018. gada)
Resursu kopa
Pakalpojumu sniedzēja resursi tiek apvienoti vairāku nomnieku modelī, kur pēc pieprasījuma tiek dinamiski piešķirti fiziskie un virtuālie resursi.
58%
(+ 15% kopš 2018. gada)
Mērogojamība un elastība
Resursi tiek mērogoti horizontāli vai vertikāli pēc pieprasījuma, tie ir praktiski neierobežoti un var tikt izsniegti jebkurā daudzumā jebkurā laikā.
58%
(+135 kopš 2018. gada)
Caurspīdīgums
Mākoņsistēmas automātiski uzrauga, optimizē un ziņo par resursu izmantošanu atkarībā no pakalpojuma veida: datu uzglabāšanas un apstrādes, trafika apjoma,
aktīvi lietotāju konti.
62%
(+ 14% kopš 2018. gada)
Platforma kā pakalpojums (PaaS) arvien vairāk virzās uz izvietošanas modeli, kura centrā ir konteineri. Mākoņu platformas atvieglo programmatūras izvietošanu, tāpēc komandām jāuztraucas tikai par paša lietojumprogrammas koda palaišanu. Pakalpojumu sniedzējiem tiek nodota arī mērogošana, resursu plānošana, administrēšana un infrastruktūras uzturēšana.
Mākoņpakalpojumu sniedzējiem par universālu standartu kļūst dažādu pakalpojumu sniegšana: virtuālo mašīnu tīklošana, identitātes un piekļuves pārvaldība (IAM), krātuve un datu bāzes, mašīnmācīšanās, lietu internets (IoT), konteineru risinājumi, drošības risinājumi un citi. .
Mākoņpakalpojumu sniedzēju klienti maksā tikai par izmantotajiem resursiem, kas nodrošina izmaksu caurspīdīgumu atšķirībā no tradicionālajiem datu centriem, kur informāciju par izstrādes izmaksām iegūt ir grūti vai neiespējami. Respondenti no uzņēmumiem, kas atbilst iepriekš uzskaitītajiem mākoņa raksturlielumiem, 2,6 reizes biežāk precīzi novērtē programmatūras palaišanas izmaksas, 2 reizes biežāk sapratīs, kurām lietojumprogrammām ir nepieciešams vairāk resursu, un 1,65 reizes lielāka iespēja palikt sava IT budžeta ietvaros.
Dažreiz izrādās, ka kompetenta speciālista nolīgšana un piešķirtās jaudas iegūšana datu centrā ir izdevīgāk nekā maksāt par mākoni. Kurš variants ir labāks, ir atkarīgs no uzņēmuma profila un mēroga, tā IT speciālistu personāla pieejamības un zināšanām. Piemēram, mākonis ir ērti lietojams, uzsākot uzņēmējdarbību vai ja uzņēmumam nav sava IT nodaļas. Mērogojot, var būt rentablāk uzturēt visu infrastruktūru vai tās daļu uz vietas.
Deniss Romaņenko, Mail.ru Cloud Solutions ārštata eksperts
DevOps tehniskā prakse
Daudzas organizācijas, kas vēlas ieviest DevOps, meklē vadlīniju vai paraugprakses kopumu. Tomēr nav divu vienādu uzņēmumu, tāpēc izvēlētās prakses ir atkarīgas no pašreizējā biznesa stāvokļa un tā mērķiem.
Tomēr ir vispārīgas jomas, kas var palīdzēt uzlabot DevOps veiktspēju: dažas ir izstrādātas komandas līmenī, bet citas prasa organizācijas līmeņa pūles.
Kādas izaugsmes jomas tiek izceltas DevOps komandām 2019. gadā:
Organizatoriskā līmenī
- brīvi savienota arhitektūra
- izmaiņu ieviešana
- koda atbalsts
Komandas līmenī
- nepārtraukta integrācija
- testa automatizācija
- izvietošanas automatizācija
- uzraudzību
- attīstības cauruļvads
Komandas un organizācijas līmenī
- mākoņpakalpojumu izmantošana
- avārijas seku testēšana
Pētījums apstiprināja brīvi savienotas arhitektūras pozitīvo ietekmi uz DevOps veiktspēju.
Brīvi savienota arhitektūra ir vieta, kur komandas var neatkarīgi pārbaudīt, izvietot un mainīt sistēmas pēc pieprasījuma neatkarīgi no citām komandām, bez papildu atbalsta, resursiem, apstiprinājuma un ar mazākām atsauksmēm. Tas ļauj strādāt efektīvāk, bet prasa augstu organizācijas un vadības līmeni.
Šī pieeja ir iespējama tikai jaunizveidotiem uzņēmumiem un ar dažām atrunām. Citos uzņēmumos situācija var būt atšķirīga. Labs piemērs: banku/fintech. Tur var izmantot tikai patentētus risinājumus, taču tiks piemērota DevOps prakse.
Deniss Romaņenko, Mail.ru Cloud Solutions ārštata eksperts
Veiksmīgas DevOps komandas visu automatizē
ļauj izlaist pakalpojumus un lietojumprogrammas ražošanā ar zemākām izmaksām un riskiem, kā arī atbalstīt izlaidumus atbilstoši organizācijas mērķiem.
Veiksmīga CI/CD nozīmē arī to, ka komandas var veikt izmaiņas ražošanā pēc pieprasījuma, saņemt tūlītēju atgriezenisko saiti par izvietošanas kvalitāti un ātri rīkoties, lai uzlabotu nākamo izvietošanas ciklu.
Pārskats parāda, ka veiksmīgas DevOps komandas iegulda plašā atbalsta procesu, prakses un rīku klāstā:
- 92% izmanto automatizētus montāžas rīkus;
- 87% izmanto automatizētus vienību testus;
- 57% paplašina automatizāciju līdz pieņemšanas pārbaudei;
- 72% automatizē izvietošanu testa vidēs, 69% dara to pašu attiecībā uz izvietošanu ražošanā;
- 69% integrē tērzēšanas robotus izvietošanas procesā;
- 57% ir integrēti ar uzraudzības rīkiem.
Ir svarīgi izvēlēties pareizos rīkus un tehnoloģijas
Veidojot sarežģītas sistēmas un pārvaldot biznesam kritiskās infrastruktūras, ir svarīgi izvēlēties tehnoloģijas:
- kuras ir viegli izmantot gan pirmajam savienojumam, gan nepārtrauktai lietošanai;
- kas palīdz sasniegt savus mērķus.
Ziņojumā tika pārbaudīti rīki, kas tika izmantoti, izvietojot programmatūru, izmantojot CI/CD, un testēšanas automatizācijas rīki — šīs ir tehnoloģijas, kas ir DevOps pamatā.
Kādas tehnoloģijas izmanto DevOps komandas:
Tehnoloģija
Zemas veiktspējas komandas
Vidējās komandas
Komandas ar labu sniegumu
Augstas veiktspējas komandas
Patentētu, atvērtā pirmkoda un komerciālu iepakotu produktu kombinācija
30%
34%
32%
33%
Galvenokārt atvērtā koda un ļoti pielāgoti pakotnes risinājumi
17%
8%
7%
10%
Pārsvarā atvērtā koda un pakotnes risinājumi ar nelielu pielāgošanu
14%
21%
18%
20%
Galvenokārt iepakoti komerciālie risinājumi
8%
12%
8%
4%
Uzņēmuma iekšējā attīstība un patentēti risinājumi
20%
6%
5%
6%
Galvenokārt atvērtā koda ar spēcīgu pielāgošanu
6%
7%
5%
12%
Galvenokārt atvērtā koda ar nelielu pielāgošanu
5%
12%
24%
15%
Rīka lietojamība būtiski ietekmē komandas spēju maksimāli palielināt izvēlētās tehnoloģiju kopas vērtību: inženieriem ar viegli lietojamām tehnoloģijām ir 1,5 reizes lielāka iespēja piederēt komandām ar augstu veiktspēju.
Manuprāt, šī tabula rada sajūtu, ka, lai būtu veiksmīga DevOps komanda, ir jāseko modei, nevis tehniskai problēmai.
Kompetents speciālists izvēlas rīkus uzdevumam, nevis otrādi. Jebkuras problēmas risināšanai vienmēr ir vairāki rīki un pieejas. Konkrētu rīku nosaka: uzdevuma specifika; cik darbinieki pārzina šo rīku (cik augsts ir ieejas slieksnis, ja rīks ir jauns); finanšu komponents, ja tāds ir.
Deniss Romaņenko, Mail.ru Cloud Solutions ārštata eksperts
Katastrofu seku likvidēšana
Katrai organizācijai, kuras darbība ir atkarīga no programmatūras darbības, jābūt . Ziņojums parāda, kādus katastrofu noturības testēšanas veidus izmanto dažādi uzņēmumi.
Kādus testēšanas veidus uzņēmumi izmanto avārijas seku novēršanai?
Pārbaudes veids
Zemas veiktspējas komandas
Vidējās komandas
Komandas ar labu sniegumu
Augstas veiktspējas komandas
Vidēji
Testi, kas neietekmē reālās sistēmas
35%
26%
27%
30%
28%
Infrastruktūras kļūmjpārlēce (tostarp datu centri)
27%
43%
34%
38%
38%
Lietojumprogrammas atteices pārbaude
25%
46%
41%
49%
43%
Negadījumu simulācija, kas saistīti ar testa sistēmu darbības traucējumiem
18%
22%
23%
29%
23%
Negadījumu simulācija, kas saistīti ar darba sistēmu traucējumiem
18%
11%
12%
13%
12%
Automatizācijas un sistēmu izveide, kas traucē
ražošanas sistēmas regulāri, nepārtraukti
9%
8%
7%
9%
8%
Tikai 40% respondentu katru gadu veic avārijas seku testus, izmantojot vienu vai vairākas no uzskaitītajām metodēm. Tajā pašā laikā uzņēmumiem, kas veic avārijas seku testus, ir augstāks pakalpojumu pieejamības līmenis. Ziņojums liecina, ka augstas veiktspējas DevOps komandas 1.4 reizes biežāk iekļaus avārijas atkopšanas testa datus savos programmatūras izstrādes un izvietošanas procesos.
Ir svarīgi nodrošināt DevOps komandām piekļuvi informācijai
Vienkārša informācijas atrašana problēmu risināšanai var palīdzēt uzturēt DevOps komandas produktīvas. Īpaši tas attiecas uz mūsdienu tehnoloģiju vidi, kas sastāv no sarežģītām sistēmām.
Šādas informācijas avotus var iedalīt divās grupās:
- Iekšējie avoti: uzņēmuma dokumentācija par koda izveidi un uzturēšanu, korporatīvās zināšanu bāzes, krātuves un daudz kas cits. DevOps komandas, kas izmantoja iekšējos zināšanu avotus, bija 1,73 reizes produktīvākas.
- Ārējie avoti: meklētājprogrammas un steku pabeigšana. Ārpakalpojuma DevOps komandas bija 1,67 reizes produktīvākas. Ārējās tehnoloģijas sniedz lielas priekšrocības mācībām un izaugsmei, jo īpaši publisko mākoņu un atvērtā pirmkoda rīku izmantošana.
Uzņēmumiem ir svarīgi samazināt tehnisko parādu
Tehniskais parāds ietver kodu vai sistēmas ar zināmām, bet neizlabotām kļūdām; nepietiekams testa pārklājums; zemas kvalitātes kods vai dizains; artefakti, kas netiek izmantoti, bet nav dzēsti; ieviešanas, kuras komanda nevar efektīvi atbalstīt; novecojušas tehnoloģijas; nepilnīga vai novecojusi dokumentācija.
Eksperti ir atklājuši, ka tehniskais parāds negatīvi ietekmē DevOps veiktspēju. Komandas ar lielu tehnisko parādu bija 1,6 reizes mazāk rezultatīvas. Komandām ar augstu veiktspēju bija 1,4 reizes lielāka iespējamība, ka tām būs zems tehniskais parāds.
Galvenie atklājumi no DevOps stāvokļa pētījuma
- DevOps komandu procentuālā daļa ar augstu veiktspēju ir gandrīz trīskāršojusies līdz 20%. Tas nozīmē, ka uzņēmumi saprot programmatūras izstrādes un piegādes uzlabošanas prakses solījumu, un uzņēmumi aktīvāk ievieš DevOps savos IT departamentos.
- Ātra lietojumprogrammu un pakalpojumu piegāde ir tehnoloģiju un organizatoriskās transformācijas pamatā. Izlaidumu ātrums un konsekvence palielina peļņu un klientu apmierinātību.
- Mākoņtehnoloģijas joprojām ir atslēga DevOps komandu izcilības sasniegšanai. Mākoņu izmantošana ļauj organizēt programmatūras piegādi vajadzīgajā ātrumā, nodrošina infrastruktūras pieejamību, mērogojamību un veiktspēju.
- DevOps komandu efektivitāti var uzlabot, pievēršot uzmanību komandas dalībnieku produktivitātei, nodrošinot komfortablu psiholoģisko atmosfēru un izmantojot ērtus rīkus.
- Laidienu izlaišanas ātruma palielināšana, izmantojot pareizo pieeju, neietekmē uzņēmuma pakalpojumu un lietojumprogrammu stabilitāti.
Avots: www.habr.com
