DevOps, vai attīstība ir jāēd un jāuztur?

Devops Is Development Eat

Autors:Metjū Skeltons

Šis raksts ir reproducēts no DevOps Times kopienas vidusskolas

Lielākajā daļā komandu pastāv virkne konfliktu un spēļu starp attīstību un ekspluatāciju un uzturēšanu.

Daži cilvēki saka, ka, parādoties DevOps, attīstība, darbība un uzturēšana vairs nemīl viens otru. Kopš tā laika viņi ir sadevušies rokās un labprāt kodē un ķer kļūdas.

Bet daži cilvēki saka, ka DevOps ir jāizstrādā, lai ēst un uzturēt.

Vai tas tā ir, kā dažādas komandas struktūras ietekmēs DevOps attīstību?

Lūdzu, skatiet zemāk, jums būs sava atbilde.

ievads

Visu ar DevOps saistīto darbību uzsākšanas organizācijā galvenais mērķis ir uzlabot vērtības piegādi klientiem un biznesam, nevis samazināt izmaksas, palielināt automatizāciju vai kaut ko darīt no konfigurācijas pārvaldības, tas nozīmē, ka dažādām organizācijām var būt nepieciešama atšķirīga komandas struktūra. efektīvai sadarbībai izstrādes, ekspluatācijas un apkopes jomā.

Kopsavilkums

Kura DevOps komandas struktūra vai topoloģija ir piemērota organizācijai, ir atkarīga no dažām lietām:

• Organizācijas produktu portfelis: mazāk produktu atvieglo sadarbību, jo saskaņā ar Conway likumu šajā gadījumā ir mazāk neatkarīgu komandu.

• Tehniskās vadības apjoms, stiprums un efektivitāte neatkarīgi no tā, vai Dev un Ops ir kopīgi mērķi.

• Vai organizācijai ir nepieciešamība vai iespējas mainīt IT darbības un uzturēšanas nodaļu no “aparatūras plaukta” un “konfigurācijas servera” uz faktisko atbilstību vērtību straumei un vai programmatūras pētniecības un attīstības komanda nopietni uztver darbības un uzturēšanas prasības .

• Vai organizācijai ir spējas vai prasmes uzņemties vadību pašreizējo O & M problēmu risināšanā.

Protams, šeit aprakstītās tēmas ir dažādas topoloģijas, un veidi tiek izmantoti kā atsauces ceļvedis vai iedvesma, lai palīdzētu jums novērtēt, kuri režīmi var būt piemēroti. Faktiski tas bieži ir labākais veids, kā pārveidot vairākus modeļus vai vienu modeli citā.

Tātad, kā attīstās DevOps komandas struktūra? Acīmredzot katrai organizācijai nav ideālas struktūras vai komandas topoloģijas. Tomēr attiecībā uz komandu struktūrām ir lietderīgi atsaukties uz dažiem dažādiem modeļiem, no kuriem daži ir vairāk piemēroti noteiktām organizācijām. Izpētot šo komandas struktūru (vai “topoloģiju”) priekšrocības un trūkumus un ņemot vērā Konveja likumu, mēs varam noteikt komandas struktūru, kas varētu būt visefektīvākā DevOps praksei mūsu pašu organizācijā.

Lielākā daļa šo DevOps topoloģiju ir aprakstītas it īpaši citur, Lawrence Sweeney no CollabNet runāja par B tipa anti (neatkarīga DevOps komanda), kuru es šeit aprakstīju komentārā Ben Kepes emuāram

3. tips (ekspluatācija un uzturēšana kā infrastruktūras pakalpojumi) un 1. tips (sadarbība izstrādes, ekspluatācijas un apkopes jomā). DevOpsGuys uzskaita divpadsmit DevOps anti-modeļus, un Jez Humble, Gene Kim, Damon Edwards (un daudzi citi) ir teikuši līdzīgas lietas. Es šeit esmu pievienojis vēl trīs “topoloģijas”, un es neesmu redzējis vai dzirdējis dažas ar to saistītas diskusijas (kopīgas darbības, DevOps-as-a-Service un pagaidu DevOps komanda).

DevOps anti-type

Aplūkojot dažas sliktas prakses, mēs varam tos saukt par “antitipiem” (teiksim, pēc tam, kad visuresošie “anti-modeļi” kļuva populāri).
A: Dev un Ops atdalīšana B: Atsevišķa DevOps komanda C: Izstrādei nav nepieciešama darbība un apkope D: Rīku komanda E: Sistēmas administrators F: Izstrāde ietver darbību un uzturēšanu G: Izstrādes un DBA atdalīšana

A tipa anti: Dev un Ops atdalīšana

Šis ir klasiskais Dev un Ops dalīšanas stils. Tas nozīmē, ka pieprasījuma punktu var iegūt agrīnā stadijā (DONE nozīmē “pilnīga funkcija”, bet to nevar izmantot ražošanā), un programmatūras darbība un uzturēšana ir traucēta, jo izstrādātājam nav ar darbību saistītas konteksta informācijas un uzturēšana. Apkopes personālam nav laika vai motivācijas piedalīties izstrādātājā un atrisināt problēmu, pirms programmatūra nonāk tiešsaistē.

Mēs visi zinām, ka šāda veida topoloģija nav laba, bet es domāju, ka ir daudz līdzīgu topoloģisko struktūru, kas ir slikti, vismaz mēs zinām, ka anti-A tips (izstrādes un ekspluatācijas un uzturēšanas nodalīšana) ir problēma.

Anti-B tips: Atsevišķa DevOps komanda

Atsevišķa DevOps komanda (anti-B tips) parasti nāk no menedžera vai izpilddirektora, nolemj, ka viņiem “vajag mazliet šīs DevOps lietas”, un izveido “DevOps komandu” (iespējams, kādu sauc par “DevOp”). DevOps komandas dalībnieki ātri izveidoja citu grupu, padarot Dev un Ops atšķirīgākus nekā jebkad agrāk, jo viņiem ir jāaizstāv savas lomas, prasmes un rīku komplekti, lai neļautu sevi iznīcināt “nezinošajiem Deviem” un “dinozauriem līdzīgajiem Opsiem”.

Vienīgā situācija, kad atsevišķai DevOps komandai patiešām ir jēga, ir tad, kad komanda ir īslaicīga, piemēram, ilgst mazāk nekā 12 vai 18 mēnešus, un tās nepārprotamais mērķis ir tuvināt Dev un Ops un būt skaidri saprotamam, autorizējot šo periodu. ir pagājis laiks, šī komanda ir lieka. To es saucu par 5. tipa DevOps topoloģiju.

C tipa anti: izstrādei nav nepieciešama darbība un apkope

Šī topoloģija ir nevainīguma un augstprātības apvienojums starp izstrādātājiem un attīstības vadītājiem, īpaši jaunu projektu vai sistēmu sākumā. Pieņemot, ka Ops tagad ir novecojis (“Mums tagad ir mākonis, vai ne?”), Izstrādātāji ļoti nenovērtēja O & M prasmju un aktivitāšu sarežģītību un nozīmi un uzskatīja, ka viņiem, iespējams, nav vajadzīgi O & M, vai brīvajā laikā. var darīt to, ko dara O & M.

Šai anti-tipa DevOps topoloģijai galu galā var būt nepieciešama 3. tipa (Ops kā IaaS) vai 4. tipa (DevOps-as-a-Service) topoloģija. Kad viņu programmatūra kļūst arvien padziļināta un sarežģītāka, O & M sāk pieprasīt izstrādes darbu “(pazīstams arī kā kodēšana)”. Ja šāda komanda atzīst O & M par svarīgu un vērtīgu disciplīnu un atzīst tās nozīmi programmatūras izstrādē, viņi varēs izvairīties no daudzām sāpīgām un nevajadzīgām (un diezgan pamata) O & M kļūdām.

D tipa anti: DevOps kā rīku komanda

Neietekmējot pašreizējās izstrādes komandas ātrumu (lietotāju stāstu ieviešana), ir izveidota DevOps komanda, kas ir atbildīga par cauruļvadu izvietošanu, konfigurācijas pārvaldību, vides pārvaldību un citiem nepieciešamajiem rīkiem. Tajā pašā laikā cilvēki Ops turpina strādāt izolēti, un Dev komanda turpina 'likt savas lietojumprogrammas pie sienas'.

Lai gan šīs īpašās komandas rezultāti var būt noderīgi, lai uzlabotu rīku ķēdi, tās ietekme ir ierobežota. Lietojumprogrammu izstrādes dzīves ciklā joprojām pastāv galvenā problēma, jo nav agrīnas darbības un līdzdalības uzturēšanā, kā arī sadarbība.

E tipa anti: slēpts SysAdmin

Šis inversijas veids ir raksturīgs organizācijām ar zemu inženierijas briedumu. Viņi vēlas uzlabot savu praksi un samazināt izmaksas, taču viņi nevar uzskatīt IT par sava biznesa galveno virzītājspēku. Tā kā DevOps nozares panākumi tagad ir acīmredzami, viņi vēlas arī “darīt DevOps”. Diemžēl viņi neatspoguļoja pašreizējo struktūru un attiecību trūkumus, bet nolīga “DevOps inženierus” savai Ops komandai.

DevOps ir tikai lomas, ko sauc par SysAdmin, atkārtota izgudrošana, reālas kultūras / organizatoriskas izmaiņas nav notikušas. Šāda veida inversija kļūst arvien plašāka, jo viduvēji vervētāji meklē tikai kandidātus ar automatizācijas un instrumentu iemaņām. Diemžēl starppersonu komunikācijas prasmes patiešām var likt DevOps uzplaukt organizācijā.

F tipa anti: O & M iegultā izstrādes komanda

Organizācija nevēlas neatkarīgu ekspluatācijas un apkopes komandu, tāpēc izstrādes komanda ir atbildīga par infrastruktūru, pārvaldības vidi un uzraudzību. Tomēr šī uz projektiem vai produktiem orientētā pieeja nozīmē, ka šie projekti ir ierobežoti resursu dēļ, un prioritāšu rezultātā ir sliktākas darbības metodes un pusfabrikāti risinājumi.

Šajā antitipā organizācijai trūkst izpratnes par to, cik svarīgas un prasmes nepieciešamas efektīvai IT darbībai.

Anti-G tips: Dev un DBA izolācija

Šī ir A tipa anti (izstrādes, ekspluatācijas un uzturēšanas nodalīšana) forma, kas ir pamanāma vidējos un lielos uzņēmumos, kur vairākas mantotās sistēmas balstās uz vienu un to pašu pamatdatu kopu. Tā kā šīm datu bāzēm ir izšķiroša nozīme uzņēmējdarbībā, īpaša DBA komanda biznesa jomā bieži ir atbildīga par uzturēšanu, veiktspējas pielāgošanu un katastrofu seku novēršanu. Tas ir saprotams, bet problēma ir tāda, ka tad, kad šī komanda kļūst par jebkuru datu bāzes izmaiņu portālu, tā faktiski kļūst par šķērsli nelielām un biežām izvietošanai (DevOps pamatprincips un nepārtraukta piegāde).

Turklāt, tāpat kā darbība un apkope anti-tipa A gadījumā, arī DBA komanda neiesaistījās lietojumprogrammu izstrādes sākumā, tāpēc datu problēmas (migrācija, veiktspēja utt.) Tika atklātas piegādes cikla beigās. Kopā ar vairāku lietojumprogrammu datu bāzu atbalsta pārslodzi galarezultāts tiek turpināts “ugunsdzēsības” un izvietošanas spiediena dēļ.

DevOps komandas topoloģija

Stāvot pretī anti-tipam, mēs aplūkojam dažas DevOps piemērotas topoloģijas.

1: Izstrāde un O & M sadarbība 2: Dalīta O & M 3: O & M kā infrastruktūras pakalpojumi 4: DevOps-as-a-Service 5: Pagaidu DevOps komanda 6: DevOps evaņģēlistu komanda 7: SRE komanda 8: Konteineru draiveris 9 : Datu bāzes iespējas

1. tips: Izstrāde un sadarbība ar operācijām un apkopi

Šī ir DevOps “prieka zeme”: raita sadarbība starp izstrādes komandu un operāciju komandu, kur ikvienam galvenajam ir nepieciešama palīdzība, taču tā ir arī jādala. Var būt daudzas neatkarīgas izstrādes komandas, kuras katra strādā pie atsevišķa vai daļēji neatkarīga produktu kaudzes.

Es domāju, ka šim 1. tipa modelim ir nepieciešamas ievērojamas organizatoriskas izmaiņas, un tas ir ļoti konkurētspējīgs tehniskās vadības komandā. Izstrādātājiem un operāciju departamentiem jābūt skaidrai izteiksmei un skaidram un saprātīgam kopējam mērķim (“augstas kvalitātes piegāde, pārmaiņu pieņemšana vai citi”). Ekspluatācijas un tehniskās apkopes personālam ir jāsavieno pārī ar Devs, jāapgūst testējamas kodēšanas prasmes un Git rīki, un izstrādei nopietni jāpievēršas ekspluatācijas un apkopes funkciju prasībām un jāatrod ekspluatācijas un tehniskās apkopes personāls, kas pievienojas žurnālam, lai sasniegtu. Sākot no pašreizējās situācijas līdz šai valstij, tas viss prasa ievērojamas kultūras izmaiņas.

1. tipa pielāgošanās spēja: uz tehnoloģijām balstīta organizācija.
Efektīvais potenciāls: augsts

2. tips: pilnībā sadalīti O & M pienākumi

Gadījumā, ja ekspluatācijas un tehniskās apkopes personāls ir integrēts produktu izstrādes komandā, mēs redzam 2. tipa topoloģiju. Dev un Ops ir ļoti maz nošķirti, un visi piešķir lielu nozīmi kopīgam mērķim, tas ir 1. tipa veids (sadarbība izstrādes, ekspluatācijas un apkopes jomā), taču tam ir dažas īpašas funkcijas.

Tādas organizācijas kā Netflix un Facebook ir efektīvi ieviesušas tīmekļa produktu, kas ir ieviesis šo 2. tipa topoloģiju, bet es domāju, ka tīri no produkta viedokļa tas var nebūt ļoti piemērojams budžeta ierobežojumu un vairāku iemeslu dēļ. produktu līnijas, kas var piespiest Dev un Ops turpināt nodalīt (piemēram, atgriezties pie 1. tipa modeļa). Šo topoloģiju var saukt arī par “NoOps”, jo nav acīmredzamas vai redzamas operāciju un apkopes komandas (lai gan Netflix NoOps var būt arī 3. tips (Ops kā IaaS)).

2. tipa pielāgojamība: organizācijai ir tikai vienkāršs tīmekļa produkts vai pakalpojums.
Efektīvais potenciāls: augsts

3. tips: ekspluatācija un uzturēšana kā infrastruktūras pakalpojumi

Organizācijām, kas ir ļoti tradicionālas IT operāciju un uzturēšanas nodaļās, tās ātri nepieņem vai nespēj (pietiekami) pieņemt pārmaiņas. Organizācijām, kas visas lietojumprogrammas darbojas publiskā mākonī (Amazon EC2, Rackspace, Azure utt.), Tā var izmantot operācijas un uzturēšanu kā elastīgas infrastruktūras komandu, kurai jānodrošina tikai lietojumprogrammu izvietošana un darbības iespējas. Tāpēc iekšējo operāciju komanda ir tieši līdzvērtīga Amazon EC2 vai infrastruktūrai kā pakalpojumam.

Dev komanda (iespējams, virtuāla komanda) kalpos kā ekspertu avots darbības un uzturēšanas funkcijās, indikatoros, uzraudzībā, servera konfigurācijā utt., Un visvairāk var sazināties ar IaaS komandu. Tomēr šī komanda joprojām ir izstrādes komanda, ievērojot tādas standarta prakses kā TDD, CI, iteratīvā izstrāde un personāla vadība.

IaaS topoloģijai ir zināma potenciāla efektivitāte (tieša sadarbība ar Ops personālu), lai atvieglotu tās ieviešanu, un tā var iegūt vērtību ātrāk, nekā mēģinot vēlāk mēģināt 1. tipa (izstrādes un operatīvās sadarbības) mēģinājumus.

3. tipa pielāgošanās spējas: organizācijas ar dažādiem produktiem un pakalpojumiem, tradicionālās ekspluatācijas un apkopes nodaļas vai to lietojumprogrammas, kas darbojas pilnībā publiskajā mākonī.
Efektīvais potenciāls: vidējs

4. tips: DevOps kā ārējs pakalpojums

Dažām organizācijām, īpaši mazākām, var nebūt līdzekļu, pieredzes vai personāla, lai vadītu savas programmatūras darbības. Izstrādes komanda var sazināties ar pakalpojumu sniedzējiem, piemēram, Rackspace, lai palīdzētu viņiem izveidot testa vidi un automatizēt infrastruktūru un uzraudzību, kā arī sniegt padomus par dažādām programmatūras izstrādes cikla laikā ieviestajām darbības funkcijām. To, ko var saukt par DevOps-as-a-Serviced, var būt maza organizācija vai komanda, kas saprot automatizācijas, uzraudzības un konfigurācijas pārvaldības mērķi un ieviešanu, un pēc tam var pāriet uz 3. kategoriju, attīstoties biznesam un vairāk darbiniekiem (Kā IaaS operācija) vai pat pirmā tipa (izstrādes, ekspluatācijas un apkopes sadarbības) režīms.

4. tipa pielāgošanās spējas: mazas komandas vai organizācijas ar nelielu darbības pieredzi.
Efektīvais potenciāls: vidējs

5. tips: DevOps komanda ar derīguma termiņu

DevOps komanda (5. tips) ar derīguma termiņu izskatās kā B tipa anti (DevOps Team Silo), taču tās nodoms un dzīves ilgums ir pilnīgi atšķirīgs. Šīs pagaidu komandas uzdevums ir tuvināt Dev un Ops. Ideāls mērķis ir stāties pretī 1. tipa (izstrāde un operatīvā sadarbība) vai 2. tipa (pilnībā koplietojama Ops atbildība) modelim un galu galā padarīt to novecojušu. Ad hoc grupas locekļi 'tulko' starp Dev-speak un Ops-talk, ieviesīs trakas idejas, piemēram, pastāvīgas sanāksmes un Kanban Ops komandai, un apsvērs 'netīras' detaļas, piemēram, slodzes līdzsvarotājus, vadības NIC un izkraut SSL Dev komanda. Ja pietiekami daudz cilvēku sāk redzēt Dev un Ops apvienošanas vērtību, pagaidu komandai ir reāla iespēja sasniegt savus mērķus, ir svarīgi, lai atbildība par izvietošanas un ražošanas vides ilgtermiņa analīzi un diagnostiku netiktu nodota pagaidu komanda, pretējā gadījumā tā var kļūt par DevOps komandas izolāciju (anti-B tips).

5. tipa pielāgošanās spējas: mazas komandas vai organizācijas ar nelielu darbības pieredzi.
Efektīvais potenciāls: zems vai vidējs

6. tips: DevOps 'evaņģēlista' komanda

Organizācijās, kur starp Dev un Ops ir milzīga plaisa (vai liela plaisu tendence), ir efektīvi izveidot DevOps komandu, kas uzturētu komunikāciju starp Dev un Ops. Šī ir 5. tipa (DevOps komanda ar derīguma termiņu) versija, taču DevOps komandai ir īpaši pienākumi pastāvīgi veicināt sadarbību un sadarbību starp Dev un Ops komandām. Šīs komandas locekļus dažreiz dēvē par “DevOps sludinātājiem”, jo tie palīdz izplatīt izpratni par DevOps praksi.

DevOps komandas mērķim jābūt realizēt savu biznesu, iespējojot pārējo organizāciju. - Twitter: EricMinick

6. tipa pielāgojamība: organizācijas ar izkaisītām Dev un Ops tendencēm. Esiet piesardzīgs attiecībā uz B tipa bīstamību.
Efektīvais potenciāls: vidējs vai augsts

7. tips: SRE komanda (Google modelis)

DevOps bieži iesaka Dev komandām regulāri apmeklēt dežūras sanāksmēs, taču tas nav nepieciešams. Patiesībā dažas organizācijas (tostarp Google) vada citu modeli, sākot no izstrādes līdz komandai, kas vada programmatūras (Site Reliability Engineering (SRE)) komandas nepārprotamo “slēdzi”. Šajā modelī izstrādes komandai SRE komandai jāsniedz testa pierādījumi (žurnāli, rādītāji utt.), Norādot, ka viņu programmatūrai ir pietiekami standarti un to atbalsta SRE komanda.

Vissvarīgākais ir tas, ka SRE komanda var noraidīt programmatūru, kas ekspluatācijā un uzturēšanā ir standartiem neatbilstoša, un pieprasīt, lai izstrādātāji uzlabo kodu pirms tā ieviešanas ražošanā. Dev un SRE sadarbība notiek attiecībā uz ekspluatācijas un uzturēšanas standartiem, taču, kad SRE komanda ir apmierināta ar kodu, viņi (nevis izstrādes komanda) atbalsta to ražošanā.

7. tipa pielāgošanās spēja: 7. tips ir piemērots tikai organizācijām ar augstu inženierijas un organizatorisko briedumu. Ja SRE / Ops komanda tiek informēta par “JFDI” izvietošanu, lūdzu, esiet piesardzīgs, lai atgrieztu A tipa anti.
Efektīvais potenciāls: zems vai augsts

8. tips: sadarbība ar konteineriem

Iesaiņojot lietojumprogrammu izvietošanas un izpildlaika prasības konteinerā, konteineram vairs nav nepieciešama zināma Dev un Ops sadarbība. Tādā veidā konteiners ir atbildības robeža par izstrādi, ekspluatāciju un apkopi. Ar labu inženierzinātņu kultūru konteineru virzītais sadarbības modelis darbojas labi, taču, ja izstrādātāji sāk ignorēt dažas lietas, kas O & M jāņem vērā, šo modeli var pārveidot par cīņu pret “mēs un viņi”.

8. tipa pielāgošanās spēja: konteineri var darboties ļoti labi, taču pievērsiet uzmanību anti-tipa A, Ops komandai, iespējams, būs viss, ko izdevis Dev.
Efektīvais potenciāls: vidējs vai augsts

9. tips: Izstrāde un DBA sadarbība

Lai novērstu Dev-DBA plaisu, dažas organizācijas ir izmēģinājušas datu bāzu funkcijas, kas līdzīgas 9. tipam, un DBA komandas datu bāzes funkcija ir samērīga ar Dev komandas datu bāzes funkciju (vai profesionālu). Šķiet, ka tas palīdz pārveidot datu bāzes skatu uz attīstību (virtuālu pastāvīgu krātuvi, kas būtībā ir lietojumprogramma) un DBA centrētu datu bāzes skatu (gudrs, bagātīgs biznesa vērtības avots).

9. tipa pielāgojamība: Attiecas uz organizācijām ar vairākām lietojumprogrammām, kas savienotas vienā vai vairākās lielās centrālajās datu bāzēs.
Efektīvais potenciāls: vidējs

Lūdzu atceries: Nevienai organizācijai nav “pareizas” komandas topoloģijas, taču ir vairākas “sliktas” topoloģijas.

Mākoņdatošanas bezmaksas kurss deg , 5 dienu ekspluatācijas un tehniskās apkopes klasiskie kursi, kurus var brīvi apgūt, galu galā, kāda veida tehnoloģiju mākoņu darbības un uzturēšanas talantiem jāapgūst, kādas ir nākotnes attīstības perspektīvas? Sekojiet nozares līderiem, lai uzzinātu,Noklikšķiniet raksta beigās'Lasīt oriģinālo tekstu'vaiIlgi nospiediet zemāk redzamo QR koduTikkoReģistrējieties bezmaksas kursam！Izmantojiet bezmaksas mācību un pretuzbrukuma iespēju 2019 ~~

PS: Atcerieties pārbaudīt bezmaksas dāvanu paketi, kuru redaktors nosūtīja ~

Ieguvumi | Vairāk nekā 10 000 PPT veidņu gaida, kad jūs saņemsit bez maksas! Beznosacījumu kolekcija!

Bezmaksas sūtīt | Vairāk nekā 1000 atsākšanas veidņu komplektu ir pieejami bez maksas, iekļaujot atsākšanas sagatavošanas pamācības!

Bezmaksas apkakle | 'Shell script 100 cases' e-grāmatas var bez maksas iegādāties, nepieciešamās sausās preces darbībai un uzturēšanai

Noklikšķiniet 【Izlasiet oriģinālu], 5 dienu bezmaksas ekspluatācijas un apkopes kurss,Atvērsies drīzumā!