Treća konferencija održana je 7. prosinca , u organizaciji moskovske DevOps zajednice uz podršku Mail.ru Cloud Solutions. Uz prezentacije vodećih DevOps praktičara, sudionici su mogli prisustvovati kratkim motivirajućim Lightning Talkovima, radionicama i komunicirati na otvorenim prostorima.
Prikupili smo važne uvide iz šest govora i obavili intervjue s nekoliko govornika kako bismo saznali što je ostalo iza izvješća.
Iznutra:
- Baruch Sadogursky, JFrog: “Neka softver teče od dobavljača do korisnika poput tekućine”
- Pavel Selivanov, Southbridge: “Dev i Ops imaju jedan zajednički zadatak - napraviti proizvod koji radi”
- Vladimir Utratenko, X5 Retail Group: “DevOps u Enterpriseu je razvoj bez boli i požara”
- Sergey Puzyrev, Facebook: “Inženjer proizvodnje brine o usluzi u cjelini: kako bi se i korisnici i programeri dobro zabavili”
- Mikhail Chinkov, AMBOSS: “Jedan odjel ne može slijediti DevOps put, cijela tvrtka ga mora slijediti”
- DevOps entuzijasti Rosbanka: “1000 dana za implementaciju DevOpsa u krvavom poduzeću”
1. Baruch Sadogursky, JFrog: “Neka softver teče od dobavljača do korisnika poput tekućine”
Neuspjesi ažuriranja softvera događaju se svakog sata i kod svih. Evo samo jedne horor priče iz govora: Knight Capital izgubio je 440 milijuna dolara u sat vremena nakon neuspješnog ažuriranja.
Baruch je govorio o DevOps obrascima kontinuiranog ažuriranja koji će pomoći u izbjegavanju kvarova i mržnje korisnika:
Lokalno vraćanje — zadržite prethodnu verziju softvera na svom uređaju za vraćanje ako se nešto dogodi. To će vas zaštititi ako stvari postanu toliko loše da ne možete poslati zakrpu eterom.
Otvorena ažuriranja - bolje kontinuirano. Inače će biti kao s programerima Jaguara: zbog greške u kočionom sustavu, koja se nije mogla ažurirati bežično, automobili su morali biti povučeni iz prodaje. Bilo je bolno i skupo.
Stalna ažuriranja — neprestano ažurirajte softver čim nova značajka bude spremna. Kod rijetkih ažuriranja značajke su grupirane; kritična ažuriranja mogu čekati nekritična. Kao i u Tesli, ažuriranje koje je trebalo popraviti slučajno kočenje čekalo je ažuriranje igre šaha.
Automatizirano postavljanje - zamijenite ljude strojevima, budući da su ljudi loši u obavljanju rutinskih radnji.
Česta ažuriranja - pomoći vam da razvijete naviku i riješite se straha. Rijetka ažuriranja pretvaraju se u hitne slučajeve.
Poznavanje stanja uređaja — testirajte ažuriranja, a ne instalaciju od nule. Ovo je važno jer se ažuriranja mogu ponašati drugačije ovisno o stanju uređaja.
Canary izdaje — uvesti ažuriranja malom broju korisnika i promatrati. Time se smanjuje šteta ako nešto pođe po zlu.
Ažuriranja bez nedostupnosti — dopustite korisnicima da primijete samo nove značajke, a ne da ostanete bez usluge nekoliko tjedana dok izbacujete ažuriranje.
Razgovarali smo s Baruchom Sadogurskyjem o tome koliko se pogled na DevOps razlikuje u ruskom i zapadnom IT-ju, hoće li Cloud uskoro raditi sve za nas i hoće li svi softverski servisi kliznuti u aaS shemu - pogledajte intervju:
2. Pavel Selivanov, Southbridge: “Dev i Ops imaju jedan zajednički zadatak - napraviti proizvod koji radi”
Implementacija Kubernetesa neće pomoći u postizanju DevOpsa, naprotiv, može sve pokvariti. Pavel je objasnio zašto tehnologija (čak i najcool) ne može riješiti sve vaše probleme:
Složenost projekta prešla je okvir koda. Prethodno je postojala složena aplikacija: interakcija unutar projekta i složen razvoj, ali jednostavna struktura - administrator ju je postavio, sve radi. Prešli smo na mikroservise: svaka usluga je jednostavna aplikacija, komunikacija pomoću standardnih protokola i brz razvoj, ali je struktura projekta postala složenija. Složenost projekta s mikroservisnom arhitekturom nije nestala - pomaknula se dalje od koda. Sada je za to odgovoran DevOps inženjer.
Programeri ne žele promjene nakon implementacije DevOps-a. Kao rezultat toga, tijek rada s Kubernetesom i dalje izgleda kao bacanje zadataka od Dev do Ops preko zida, samo ne metaforički - Git postaje takav zid. Programer tamo stavi kod i radi kao i prije, a admini imaju Kubernetes, CI/CD i sve ostalo.
Međutim, programeri moraju prihvatiti promjene. Situacija u kojoj programeri ne znaju što administratori rade, a administratori ne znaju što se događa s programerima, stvara probleme.
Ako se za programere ništa nije promijenilo, oni ne shvaćaju da je rad aplikacije njihova odgovornost - razni tehnički trikovi neće uspjeti.
Dolaskom DevOpsa i Kubernetesa puno toga će se promijeniti u razvoju. Programeri moraju biti kompetentni u operacijama i obrnuto. Ovi stručnjaci imaju svoje specifične vještine, ali moraju biti svjesni rada jedni drugih. Dev i Ops moraju biti prijatelji prije implementacije Kubernetesa, inače ćete slomiti ono što imate.
Pavel Selivanov govorio je o tome što će se dogoditi s Kubernetesom za 5 godina i na čemu bi moderni startup trebao graditi tehnološki stack - pogledajte intervju:
3. Vladimir Utratenko, X5 Retail Group: “DevOps in Enterprise je razvoj bez boli i požara”
Tvrtke dolaze u DevOps transformaciju kada shvate da je razvoj prespor i ne odgovara realnostima, imaju želju za boljim razvojem i bržim razvojem.
Vladimir je objasnio kako se to događa i u čemu je caka:
- Prvo, tvrtke zapošljavaju DevOps inženjera. Ovo je Senior System Administrator, on je uključen u implementaciju izdanja u proizvodnju, standardizaciju razvojnog okruženja, postavljanje infrastrukture, otkrivanje i popravljanje raznih problema, automatizaciju procesa i druge tehničke zadatke.
- Tada jedan DevOps inženjer više nije dovoljan i tvrtka zapošljava DevOps tim. Ovo je centar kompetencija koji organizira napore različitih inženjera i omogućuje njihovu koncentraciju u jednom smjeru.
- Zapravo, DevOps inženjer i DevOps timovi su anti-obrasci DevOps transformacije. Budući da se DevOps bavi praksama i kulturom, osim toga, postoje implementacije DevOpsa u tehnološkim tvrtkama (SRE, proizvodno inženjerstvo).
Što uraditi? Unajmite privremeni DevOps tim koji će pomoći u implementaciji DevOps transformacije, provoditi prakse, njegovati razvojnu i tehnološku kulturu.
Kada posao uđe u igru i investira u DevOps, moguće je nekoliko scenarija: sve će se raspasti u startu; ostat će kao SRE/proizvodno inženjerstvo ili ugrađene operacije; će se preseliti u BizOps, kada se procesi budu temeljili na poslovnoj metrici.
Vladimir Utratenko ispričao nam je koliko je zapravo DevOps u poduzeću “krvav” i kako se prakse implementiraju unutar velike maloprodaje - pogledajte intervju:
4. Sergey Puzyrev, Facebook: “Inženjer proizvodnje brine o usluzi u cjelini: kako bi se i korisnici i programeri dobro zabavili”
Facebook je ogromna kompanija, s velikim brojem komponenti, servera, ljudi i podatkovnih centara. Unatoč ogromnoj veličini, vrlo je brz - programeri mogu uvesti usluge više puta dnevno. Također, Facebook ubrzano raste, a ne raste samo broj korisnika i poslužitelja, povećava se i broj programera, što procese čini složenijima.
Sergej je ispričao što inženjer proizvodnje radi na Facebooku:
- Inženjer proizvodnje puno kodira, mora imati znanja o sustavima: operativni sustavi, datotečni sustavi, baze podataka, mreže i slično. Mora imati iskustvo u radu s distribuiranim sustavima i inženjeringom pouzdanosti, odnosno podržavanjem pouzdanosti proizvoda. Mora biti dežurna, odnosno dostupna za poziv u bilo kojem trenutku.
- Proizvodni inženjer se razlikuje od softverskog inženjera po tome što ima napredne vještine u radu, ali je zapravo podvrsta softverskog inženjera. Softverski inženjeri mogu imati dodatne vještine vezane, na primjer, za obradu podataka. Na Facebooku takvi stručnjaci također moraju biti dežurni, što je za mnoge neugodno iznenađenje.
- Piramida potreba inženjera proizvodnje u poduzeću počinje praćenjem servera i njihovog životnog ciklusa, odnosno nabavom novog hardvera, postavljanjem, puštanjem u rad. Sljedeća razina je ista na razini usluge: praćenje usluga i njihovog životnog ciklusa. Zatim dolazi besprijekorno skaliranje i napredni nadzor. Prebacuju se na automatsko skaliranje nakon što je životni ciklus usluge automatiziran. I na kraju, potrebno je napraviti tuning kako bi skaliranje bilo učinkovito, a tvrtka uštedjela novac i resurse.
5. Mikhail Chinkov, AMBOSS: “Jedan odjel ne može slijediti DevOps put, cijela tvrtka ga mora slijediti”
Mikhail vjeruje da je DevOps kontinuirani razvoj. Ne možete uvesti neke alate i tu stati. Koji problemi sprječavaju tvrtke da postanu DevOps i kako implementirati praksu?
Razlika u razumijevanju DevOps-a. Kanonski devops, kako ga vide evanđelisti, počiva na 5 stupova:
- kultura - fokus na ljude i suradnju;
- automatizacija - delegiranje rutine u tijek rada;
- lean - naglasak na isporuci vrijednosti korisniku;
- dijeljenje - kontinuirana razmjena znanja;
- metrike i primanje povratnih informacija pomoću njih.
Tvrtke se obično fokusiraju samo na automatizaciju i isporuku vrijednosti korisniku. Ali kultura, dijeljenje znanja i metrika DevOps za praćenje razvoja nestaju u pozadini.
Izazovi standardizacije DevOps-a. Ciljevi proizvoda različiti su za sve tvrtke i ne mogu se standardizirati. Stanje DevOps-a u tvrtki ovisi o samoj tvrtki, ali mnogi to ne razumiju i smatraju da je dovoljno zaposliti DevOps inženjera.
Zašto još nismo DevOps? Dva su ključna problema. U poduzeću postoji spor razvoj organizacije, poteškoće s promjenom vektora u glavama tisuća zaposlenika. Kod startupova postoji nedostatak izvora znanja i problem raspodjele resursa za transformaciju.
Faze razvoja DevOps-a u poduzeću:
- prvi je infrastruktura u oblaku, ali nitko ne zna kako to funkcionira osim jednog ili dva administratora;
- drugo, infrastruktura je transparentna i razumljiva svim inženjerima, ali procesi nisu pojednostavljeni;
- treće - inženjeri samostalno pokreću i popravljaju žive usluge;
- četvrto - inženjeri će po želji pridonijeti temeljnoj infrastrukturi, transparentan kod u oblaku, implementacija pomoću gumba.
Idealna shema je da svi imaju isti pristup infrastrukturi, svi inženjeri imaju pristup proizvodu i razumiju što rade.
Nakon zatvaranja svih kulturnih i tehničkih gestalta, DevOps transformacija tvrtke uzet će u obzir povratne informacije iz poslovnih i platformskih metrika.
6. DevOps entuzijasti Rosbanka: “1000 dana za implementaciju DevOpsa u krvavom poduzeću”
Yuri Bulich, Dina Maltseva, Evgeny Pankov iz Rosbanka ispričali su kako su u tri godine došli do DevOpsa. Postojala su dva cilja: riješiti specifične probleme u određenim timovima i implementirati centralizirane alate.
Evo postignutih rezultata:
Rezultati za timove proizvoda: 30 puta brža montaža, 6 puta brža montaža, do 30% uštede na cijelom ciklusu. Sada imamo mogućnost da pritiskom na gumb prijeđemo na produktivnost
Rezultati za naredbe platforme: 10 puta brža montaža i instalacija, 87% povećan broj instalacija, 46% pokrivenost autotestom. Integracijski tim više nije usko grlo
Dakle, kako implementirati DevOps praksu u krvavo poduzeće?
Prvo provesti pilot projekt: Odaberite timove, odlučite kako implementirati arhitekturu i odaberite alate. Odabrali smo alate s otvorenom licencom, s instalacijom u banci i stručnošću u radu s njima. Rosbank je istovremeno implementirao privatni oblak zajedno s DevOps platformom i to je pomoglo na početku. U oblaku je prije bilo moguće dobiti potrebne resurse pritiskom na gumb za 15 minuta, a takav je proces mogao trajati tjedan dana.
U bankama i drugim poduzećima potrebno je unaprijed s timom za informacijsku sigurnost razraditi ograničenja i pronaći rješenje koje će omogućiti provedbu promjena.
Nakon pilota potrebno je povećati uspješno rješenje.
- Važno je "ispraviti" cjevovod što je više moguće, eliminirajući iz njega nepotrebne veze, ističući pružatelje vrijednosti i uklanjajući preostale komponente. Intermedijeri su antiuzorci. Na primjer, u Rosbanku, određeni broj timova nije razvio unutarnji razvoj, ostavljajući samo vanjski razvoj. To je dovelo do pojave posvećenog DevOps tima, koji je osigurao prijenos koda od vanjskih do internih programera. Problem je riješen integracijom eksternog razvoja u CI/CD, kako ne bi samo prenijeli kod od sebe u banku, već bi bili i odgovorni za njegov uspjeh.
- Model zrelosti uključivao je elemente DevOps praksi, navedene alate i uzeo u obzir značajke rada s vanjskim dobavljačima - u budućnosti je to pomoglo u brzom smanjenju zaostataka zadataka prilikom njihove implementacije u novim timovima.
- Trebamo upravljanje u obliku meke kontrole i preporuka. DevOps priručnik koji dobro funkcionira skup je organizacijskih i alatnih karakteristika koje pomažu timovima da ispravno koriste platformu.
- Treba odmah obratiti pozornost na kulturu, tada će se mnoge promjene dogoditi brže i lakše. Razvijajte svoju internu zajednicu, održavajte sastanke, tehničke radionice, treninge i zabavne aktivnosti. To donosi plodove: ljudi dijele prakse, vide tko je što napravio, znaju kome se obratiti, postoji pompa i zdrava konkurencija unutar tvrtke.
- Nema smisla raditi s onima koji nisu uključeni u proces, s timovima koji nisu sazreli, bolje je ulagati u zainteresirane timove i lojalne ljude.
- Odabrano rješenje mora biti pogodno za one inženjere koji ga koriste.
- Vanjski razvoj nije blokada, tu se također mogu implementirati prakse, glavno je da sam tim ima želju.
Još malo koristi
Popis knjiga koje vrijedi pročitati za one u DevOps-u, Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Volja i samokontrola."
- Daniel Kahneman "Razmišljanje, brzo i sporo".
- Barbara Oakley "Um za brojke".
- Maxim Dorofeev "Jedi tehnike".
- Viktor Frankl "Čovjekova potraga za smislom".
Stay tuned
Volimo i DevOps. Pratite najave serije i @Kubernetes, kao i druge događaje Mail.ru Cloud Solutions, na našem Telegram kanalu:
Izvor: www.habr.com
