DevOps je kultura, a ne uloga!

Softver je posvuda. U današnjem svijetu svaka je velika tvrtka / organizacija povezana s razvojem softvera i treba se ponašati kao jedno. Postoji veći pritisak nego ikad prije da se brže krenete i da budete okretniji bez da žrtvujete sigurnost ili pouzdanost. Taj se pritisak često očituje otkazivanjem ili stavljanjem na čekanje projekta. Ovo je situacija u kojoj se DevOps nastoji pozabaviti: kako navesti razvojne, operativne i druge grupe unutar organizacije da surađuju oko skupa zajedničkih ciljeva, brže i pouzdanije isporučuju softver kupcima i krajnjim korisnicima? Ključne tehničke prakse koje podržavaju DevOps inicijativu uključuju dobivanje dev i ops timova za standardizaciju na zajedničkom skupu okretnih procesa i alata za isporuku softvera. Oni često uključuju:

  • Automatizirano upravljanje konfiguracijom, testiranje i implementacija aplikacija;
  • Nadzor verzije aplikacije i infrastrukturnog koda radi suradnje i povratnih pogrešaka;
  • CI (kontinuirana integracija) za automatizaciju stvaranja koda i omogućavanje bržih povratnih informacija i ponavljanja putem češćih izdanja s nižim rizikom.

DevOps je kulturološka perspektiva na koji način svi trebaju biti uključeni u pravilan rad. U softverski definiranom svijetu pojavljuje se gomila pitanja.

Kako brzo ući u nešto i kad je već u proizvodnji? Kako znamo da smo došli do najboljeg rješenja? Kako brzo možemo primijeniti poboljšanja i ažuriranja?

DevOps želi uključiti sve koji imaju udjela u igri uključivanjem rano u kolaborativni postupak. Postizanje tog uspjeha s DevOpsom započinje s razumijevanjem ključnih poslovnih prednosti. Organizacije se mogu brže kretati uz manje zastoja i manje sigurnosnih problema.

Mike Dilworth, voditelj transformacije Agile i DevOps, nedavno je rekao:

DevOps je kultura, a ne uloga! Cijela tvrtka treba raditi DevOps da bi mogla djelovati.

Treba podržati više rukovodstvo, ali i uključiti sve koji imaju udjela u konačnom proizvodu, a ne samo odjele za razvoj i poslovanje.

Puppet sam čitao bijeli papir o tome kako možemo izraditi IT-tim visokih performansi. I odjeljak A imao je gomilu zanimljivih teorija i praksi koje bih htio podijeliti s vama.

DevOps seže duboko i široko kroz industrije, veličine poduzeća i tehnološka okruženja. Unatoč tome, zajedničko je suzdržavanje od IT menadžera koji vode uspješne DevOps transformacije u svojim organizacijama. DevOps radi o stalnom učenju i usavršavanju, a ne o krajnjem stanju.

Izgradite poslovni slučaj

Kao i mnogi IT vođe, od vas se traži da ne samo isporučujete više proizvoda i usluga nego ikad prije, već to postižete većom brzinom i kvalitetom - bez postizanja pogotka pouzdanosti ili sigurnosti. Čini se da će DevOps zaista pomoći! Ali ... imate sumnjičav svoj tim prije nego što ste ikada započeli.

Kako napraviti jasan, uvjerljiv slučaj za DevOps koji smanjuje strah i pretvara skeptici u prvaka?

Početak s gornjim pitanjem zapravo je sjajan početak. Izgradnja poslovnog slučaja ključni je dio uspješne DevOps transformacije (posebno u velikim organizacijama). U čuvenom TED razgovoru, Simon Sinek primjećuje zajednički nazivnik sjajnih vođa i katalizatora za pozitivne promjene:

Ljudi ne kupuju ono što ti vođe rade, ali zašto to rade.

Ista ideja vrijedi i za izgradnju organizacijskog buy-ina za DevOps transformaciju. Jednostavno, izjavljivanjem "radimo DevOps" neće se ljudi povesti. Umjesto toga, potreban vam je uvjerljiv odgovor na pitanja „Zašto? A zašto sada? ". Svi naši kupci žele se kretati brže, a da pri tome ne narušavaju pouzdanost i stabilnost svojih sustava - ciljevi koji se izravno međusobno sukobljavaju u tradicionalnim organizacijama. Razvojni programeri imaju zadatak što prije uvesti nove značajke u proizvodnju. U međuvremenu, operativni momci mjere se radnim vremenom i performansama sustava. Tako ove momčadi postaju protivnici umjesto saveznika. Kao rezultat toga, raspoređivanje u proizvodnju muči se s kašnjenjima i greškama, a one se događaju daleko rjeđe nego što posao stvarno treba.

Dobijanje Deva na brodu s DevOpsom

Brže implementacije i petlje za povratne informacije dobivaju u srcu ono što programeri žele: kôd dolazi s njihovih prijenosnih računala u ruke korisnika mnogo brže, a kontinuirana isporuka omogućuje brzo ponavljanje i poboljšanje. Pravo poboljšanje vašeg vremena promjene tijekom ranih pilota dobro je mjesto za početak:

  1. Koliko brzo se kod može prebaciti s vraga prijenosnog računala na proizvodnju?
  2. Kako se to podudara s vašim prethodnim vremenima? (Jeste li automatizirali više postupka izrade? Jeste li smanjili broj karata potrebnih za implementaciju?)
  3. Koliko često se tada raspoređujete?
  4. Da li raspoređivanje postaje lakše i brže?

Dobijanje Opsa na brodu s DevOpsom

Ops koristi: kada programeri usko surađuju s njima. Može biti korisno za početak dogovorom o zajedničkom lancu alata i da dvije skupine rade zajedno na usvajanju istih alata koji se koriste u razvoju za integriranje, testiranje i raspoređivanje infrastrukturnog koda. To programerima aktivnije uključuje implementaciju i rješavanje problema, dodatno rušeći stare barijere istovremeno poboljšavajući brzinu i pouzdanost. Praćenje nekoliko mjernih podataka do kojih je Ops stalo, podcrtavat će pobjede za cijeli tim - uključujući Dev i QA:

  • Vrijeme rada / prekida rada: Da li možete bolje ispuniti svoje zahtjeve na razini usluge? Je li se stanka smanjila?
  • Promjena stope otkaza: Jesu li se kvarovi smanjili?
  • Srednje vrijeme za oporavak: jeste li skratili vrijeme potrebno da se vratite u svoje posljednje poznato dobro stanje kada dođe do kvara?

Započnite s malim i rastu od ranih uspjeha.

Pa kako početi mjeriti ove DevOps učinke i pojačati svoj poslovni slučaj? Počnite s malim s određenim zadacima i projektima. Ovaj se pristup pokazao vrlo učinkovitim za Terri Potts (kolega inženjer i tehnički direktor softvera u Raytheonu)

Ne možete promijeniti cijeli program, ali možete započeti s prebacivanjem nekoliko sub-timova u pravom smjeru. Može biti korisno dovesti nekoga izvana kako bi automatizirao nekoliko testova ili sastavljanja i dao timu nekoliko primjera za nadogradnju.

Raytheon je omogućio jednom od svojih timova da se prebaci s dva postupka integracije mjesečno na njih 27 u jednoj noći zbog automatizacije svojih sastava. To je velika pobjeda u jednoj inicijativi, i ona je postala dio Potcsovog šireg slučaja za rastući DevOps unutar organizacije.

Krenite i s kulturološkim pomakom - nemojte očekivati ​​da će DevOps prodati svima odjednom. Zapravo, pobjedom nad manjim skupinama s određenim projektima stvorit ćete ambasadore koji će pomoći promociji DevOps-a drugdje u organizaciji, stvarajući učinak multiplikatora. Tijekom izgradnje poslovnog slučaja trebali biste također imati na umu potencijalne prepreke dugoročnom uspjehu DevOps-a.