DevOps nav ne metode, ne rīks, tā ir kultūra

DevOps ir operāciju un izstrādes inženieru prakse, kas kopā piedalās visā kalpošanas ciklā, sākot no projektēšanas līdz izstrādes procesam un beidzot ar ražošanas atbalstu. Veiklības ieviešanu sistēmā var uzskatīt par DevOps kultūru.

Kultūra bieži tiek ignorēta un pārprasta, tomēr tā ir galvenais faktors, kas atbild par uzņēmuma darbību. Ja mēs nepārvaldīsim savu kultūru, mēs galu galā rīkosimies nepareizi, kas galu galā ietekmēs mūsu biznesa mērķus.

Izpratne par organizācijas pašreizējo kultūru

Kultūra stāsta par vērtībām un normām grupā vai uzņēmumā. Tas identificē to, kas ir svarīgi, kā arī to, kā cilvēki tuvojas un strādā viens ar otru.





KULTŪRA = “Kā lietas var gudri paveikt, lai gūtu panākumus”

Ņemsim piemēru no klientu atbalsta komandas. Šīs komandas kultūrai jābūt tādai, lai viņi sasniegtu 97-98% klientu apmierinātības.



Paturot prātā klientu prieku, vispirms viņiem jābūt pieklājīgiem, pat sarežģītās situācijās viņiem jābūt labiem klausītājiem, lai izvairītos no neskaidrībām, viņiem jāpiešķir prioritāte darbam atbilstoši prasībām.

Uz brīdi apstāsimies un uzdosim sev dažus jautājumus:

  • Kāda ir mana uzņēmuma kultūra tagad?
  • Cik labi šī kultūra ir saskaņota ar maniem biznesa mērķiem vai KRA?
  • Kādas problēmas es varu sagaidīt neatbilstības dēļ?

Katrai organizācijai 4C ir svarīga loma



Organizācijas 4C

Apskatīsim programmatūras izstrādes organizācijas kultūru. Vienas programmatūras vienības izveidošanai un uzturēšanai ir iesaistītas daudzas komandas. Visām šīm komandām ir atsevišķi mērķi un atsevišķa kultūra.

Šis process sākas pēc tam, kad klients ir apstiprinājis prasības.

Izstrādātāji ievēro viņu organizācijas noteiktās kodēšanas vadlīnijas, un koda ģenerēšanai tiek izmantoti programmēšanas rīki, piemēram, kompilatori, tulki, atkļūdotāji utt. Kodēšanai tiek izmantotas dažādas augsta līmeņa programmēšanas valodas, piemēram, C, C ++, Pascal, Java un PHP.

Viņi sadala visu paketi mazās mapēs un pēc tam attiecīgi izstrādā mazus kodus.

1. posms : Pēc tam šīs mazās kodu vienības tiek apvienotas, veidojot lielu vienību. Integrējot mazākās mikroshēmas, jāveic projekta līmeņa testēšana, kas pazīstama kā integrācijas testēšana.

2. posms : Pēc veiksmīgas integrācijas tā tiek ievietota manekena sistēmā. Šai manekena sistēmai ir līdzīga konfigurācija kā klienta mašīnai vai mašīnai, kurā šis projekts ir beidzot jāizvieto.

3. posms : Visbeidzot, pēc visu manekena sistēmas funkciju pārbaudīšanas projekts tiek izvietots ražošanas serverī vai klienta mašīnā.

Lai gan šis process, šķiet, ir ļoti raits un viegls vārdos, tehniskā ziņā to ir ļoti grūti panākt.

Apskatīsim, ar kādām problēmām mēs varam saskarties:

1. posms :

Klients vienmēr meklē izmaiņas, lai uzlabotu produkta kvalitāti. Lielāko daļu laika, kad tika veikta pirmā atkārtošana, klients ieteiks dažas izmaiņas. Kad izstrādātāji saņem izmaiņas, viņi sāk tās iekļaut, kas ietekmē integrāciju, kas noved pie salauzta būvējuma.

2. posms:

kas ir pēcdiploma sertifikāts

Pārsvarā testētāji vai citi operācijas puiši nezina par jaunajām veicamajām izmaiņām. Tiklīdz viņi saņem kodu no izstrādātājiem, viņi sāk tos pārbaudīt. Lai gan aizmugurē izstrādātāji joprojām veic izmaiņas.

Tā kā viņiem nav pietiekami daudz laika jaunu izmaiņu ieviešanai, viņi izstrādā neefektīvus kodus, ar kuriem saskaras ar citiem tīkla un datu bāzes jautājumiem, kas atkal aizkavē to piegādes laiku.

Kad viņi beidzot piegādā kodus operāciju komandai, viņiem paliek ļoti minimāls laiks jaunu testu izveidošanai un ieviešanai. Tāpēc viņi izlaiž daudzas pārbaudes lietas, kuras vēlāk saprot, ka tām bija liela prioritāte.

3. posms:

Lai gan praktiski būvējums, šķiet, ir gatavs sākt ražošanu, taču rezultāti ir pilnīgi negaidīti. Veidošana neizdodas, un rodas vairākas kļūdas.

Pēc katras kļūdas viņiem ir jāseko, kāpēc tā notika, kur tā radās, kādas izmaiņas ir jāveic, lai to pārvarētu, vai tiks mainīti citu kodi, lai tas būtu saderīgs ar iepriekšējiem. Visbeidzot, par visām šīm kļūdām ir jāizveido kļūdu ziņojums.

Neveiksme ir saistīta ar sistēmas kļūdām, kas saistītas ar datu bāzes izstrādātāja nezināšanu koda efektivitātē, testētāja nezināšanu testa gadījumu skaitā utt.

Tā kā klients vienmēr stingri ievēro termiņu, darbinieki, kas iesaistīti to sasniegšanā, galīgajā izlaidumā koncentrējas tikai tad, ja viņiem ir jāsamazina vispārējā kvalitāte.

Lai gan šķiet, ka tā ir darba koordinācijas problēma, tā patiesībā ir pieņemtā kultūra.

Tas notiek lielās atkarības dēļ no manuālajiem procesiem. Skriešana turp un atpakaļ vienā komandā, jo trūkst zināšanu par dažādām jomām, piekļuves trūkums vai intereses trūkums palielina mūsu pašu slogu un sāpes.

datu struktūras un algoritmi java

Ir pienācis pēdējais laiks būt daudzpusīgam. Varētu būt grūti apgūt visus sistēmā iesaistītos procesus, taču mēs varam būt visu domkrats, apgūstot vienu no tiem. Tad tikai mēs varam automatizēt savu sistēmu vai padarīt to pietiekami inteliģentu, lai atgūtu, nevis atgrieztos.

Tagad jūs varētu domāt, kāpēc?

Tas ir tāpēc, ka tas, kuru jūs apgūstat, ir ļoti atkarīgs no citiem. Tātad, lai uzzinātu par atkarības punktu, mums ir jāsaprot visa sistēma.

Tāpēc padomāsim par procesu, kā mainīt kultūru. Pirms tam jums ir atbilde uz tālāk norādītajiem jautājumiem?

  • Kur neizdodas jūsu pašreizējā kultūra?
  • Kāpēc jūs vēlaties mainīt procesu?
  • Vai esat skaidri noteikuši visas nepieciešamās izmaiņas?
  • Vai esat saņēmis atsauksmes un dalību no visiem ietekmētajiem ieinteresētajiem dalībniekiem?
  • Vai esat atkārtoti apstiprinājis izmaiņu procesa disciplīnu, datus un mērīšanas sistēmu?

Tātad, tagad, kad mums ir atbilde visiem, mēs domājam par revolūciju mūsu sistēmā. Kā notiks šī revolūcija? To var sasniegt tikai tad, kad mēs nogalinām to, kas esam tagad. Daudz laika tiek tērēts koda migrēšanai komandu starpā. Mums ir jānodrošina process, kurā mēs varam veikt nepārtrauktu integrāciju un nepārtrauktu izvietošanu.

Šis nepārtrauktās integrācijas un izvietošanas process padara to veiklāku. Šīs veiklības panākšana tiek uzskatīta par DevOps kultūru.

DevOps ir prakse, kad operācijas un izstrādes inženieri kopā piedalās visā pakalpojumu dzīves ciklā, sākot no projektēšanas līdz izstrādes procesam un beidzot ar ražošanas atbalstu.

Laika gaitā nav viegli mainīt darba sistēmu. Veiksmīga pāreja ir sistēmas atjaunošana, nevis atjaunošana.

Tagad redzēsim, kā mēs to varam sasniegt. Var būt divi veidi, kā tuvoties.

1) no augšas uz leju

2) Apakšā uz augšu

Iedziļinoties šajās tehnikās, mēs sapratīsim, kas ir vispiemērotākais mūsu organizācijai.

Ja izmantojat pieeju 'no augšas uz leju', mēs varam doties pie augstākas vadības un lūgt viņus veikt izmaiņas visās komandās. Ja vadība ir pārliecināta, tad mēs varam sākt pie tā strādāt.

Bet varbūtība saņemt atbildi kā “NĒ” ir diezgan liela. Tas ir tāpēc, ka sistēmas maiņa var novest pie organizācijas nestabilitātes.

Viņiem jāizpēta organizācijas struktūra, ieņēmumi, klienta interešu līmenis utt. Bet vissvarīgākais faktors, kas viņus attur no vecās sistēmas izkļūšanas, ir tas, ka viņi neredz liels priekšstats par to, ko var sasniegt un cik gludi to var panākt ar jaunāko.

Šajā gadījumā mēs varam meklēt otro pieeju, lai iegūtu šo kopējo ainu.

Apakšā uz augšu pieeja prasa brīvprātīgo. Šeit mums ir jāuzņemas neliela komanda un neliels uzdevums, kas jāizpilda DevOps modelī.

pagriezt un atvienot sql

Apskatot šī modeļa tehnisko pusi, mums ir dažādi sarežģīti rīki, kas padara darbu efektīvāku un ātrāku. Bet tikai rīki nav pietiekami spējīgi, lai izveidotu sadarbības vidi, kas tiek dēvēta par DevOps.

Šādas vides izveide prasa domāt ārpus kastes, piem. novērtēt un pielāgot to, kā cilvēki domā par savu komandu, biznesu un klientiem.

Jauna rīku komplekta apvienošana ir vienkāršāka nekā organizācijas kultūras maiņa. Veicinot antisociālu galveno izstrādātāju attīstību, ļaujot integrēt neefektīvus kodus, izvietojot nepārbaudītus kodus, uzliekot pārmetumus viens otram, operāciju komandas uzskatīšana par stulbu, nav labākā prakse, ko mēs ievērojam, lai bizness būtu iespējams un radīt vērtību mūsu klientiem.

Procesu sarežģī nevis rīki, bet cilvēki, kas tos izmanto. Teikt abstraktā līmenī, nevis apkopot idejas un uzvedību, ja esam viņiem atvērti, mēs vedam uz gaišu ceļu.

Sāksim ar komandu no 6 dalībniekiem un trīs punktu stāsta. Pirmkārt, mums ir jāsadala komanda, kuru mēs saucam par izstrādātājiem, operācijām, testētājiem utt. Mēs tos visus uzskatām par vienu, teiksim “DevOps”. Kad mēs saņemam prasības, mums jāanalizē riska zonas. Paturot prātā dziļākos jūras & hellip posmus .. Sākam kuģot.

Tagad jums jādomā, “kāds ir šīs nepārtrauktās integrācijas un nepārtrauktas izvietošanas x faktors, kas samazina neveiksmes varbūtību”.

Ar uzlaboto redzējumu un procesu mēs varam vērsties pie vadības, izveidojot skaidru priekšstatu par rezultātiem, piemēram, cik gluds bija process, kā tika samazināts neveiksmes risks, kā uzdevums tika izpildīts pirms laika grafika utt.

Tagad mēs varam skaidri vizualizēt, kā viss process tika optimizēts tehniskajā un kultūras jomā, veicot retrospekciju pēc katras iterācijas.

Edureka ir īpaši kūrējusi kas palīdz jums apgūt tādus jēdzienus kā Leļļu, Dženkinsu, Ansible, SaltStack, Šefpavārs.

Vai mums ir jautājums? Pieminiet tos komentāru sadaļā, un mēs ar jums sazināsimies.

Saistītās ziņas: