Tretja konferenca je bila 7. decembra , ki ga je organizirala moskovska skupnost DevOps s podporo Mail.ru Cloud Solutions. Poleg predstavitev vodilnih izvajalcev DevOps so se udeleženci lahko udeležili kratkih motivacijskih Lightning Talks, delavnic in komuniciranja na odprtih prostorih.
Zbrali smo pomembna spoznanja iz šestih govorov in opravili intervjuje z več govorci, da bi ugotovili, kaj je ostalo za poročili.
V notranjosti:
- Baruch Sadogursky, JFrog: »Naj programska oprema teče od prodajalca k uporabniku kot tekočina«
- Pavel Selivanov, Southbridge: "Razvojci in operaterji imajo eno skupno nalogo - narediti izdelek, ki deluje"
- Vladimir Utratenko, X5 Retail Group: »DevOps in Enterprise je razvoj brez bolečin in požarov«
- Sergey Puzyrev, Facebook: “Proizvodni inženir skrbi za storitev kot celoto: da se tako uporabniki kot razvijalci zabavajo.”
- Mikhail Chinkov, AMBOSS: »En oddelek ne more slediti poti DevOps, slediti ji mora celotno podjetje«
- Navdušenci nad DevOps iz Rosbank: "1000 dni za implementacijo DevOps v krvavo podjetje"
1. Baruch Sadogursky, JFrog: »Naj programska oprema teče od prodajalca k uporabniku kot tekočina«
Napake pri posodabljanju programske opreme se zgodijo vsako uro in pri vseh. Tukaj je samo ena grozljiva zgodba iz govora: Knight Capital je izgubil 440 milijonov dolarjev v eni uri po neuspešni posodobitvi.
Baruch je govoril o vzorcih nenehnih posodobitev DevOps, ki bodo pomagali preprečiti napake in sovraštvo uporabnikov:
Lokalno povrnitev nazaj — ohranite prejšnjo različico programske opreme v napravi, da se lahko vrnete nazaj, če se kaj zgodi. To vas bo zaščitilo, če se stvari tako poslabšajo, da ne boste mogli poslati popravka po zraku.
Posodobitve po zraku - bolje neprekinjeno. Sicer bo tako kot pri razvijalcih Jaguarja: zaradi hrošča v zavornem sistemu, ki ga ni bilo mogoče posodobiti po zraku, so morali avtomobile odpoklicati iz prodaje. Bilo je boleče in drago.
Nenehne posodobitve — nenehno posodabljajte programsko opremo, takoj ko je pripravljena nova funkcija. Pri redkih posodobitvah so funkcije združene; kritična posodobitev lahko počaka na nekritične. Tako kot v Tesli je posodobitev, ki naj bi odpravila naključno zaviranje, čakala na posodobitev igre šaha.
Samodejno uvajanje - zamenjajte ljudi s stroji, saj ljudje slabo opravljajo rutinska dejanja.
Časte obnovitve - pomaga razviti navado in se znebiti strahu. Redke posodobitve se spremenijo v nujne dogodke.
Poznavanje stanja naprave — preizkusite posodobitve, ne namestitev iz nič. To je pomembno, ker se lahko posodobitve obnašajo drugače, odvisno od stanja naprave.
Canary sprosti — uvesti posodobitve manjšemu številu uporabnikov in opazovati. To zmanjša škodo, če gre kaj narobe.
Posodobitve brez nedosegljivosti — dovolite strankam, da opazijo samo nove funkcije in ne ostanejo brez storitve več tednov, medtem ko uvajate posodobitev.
Z Baruchom Sadogurskyjem smo se pogovarjali o tem, kako se pogled na DevOps razlikuje v ruskem in zahodnem IT, ali bo Cloud kmalu naredil vse namesto nas in ali bodo vse programske storitve zdrsnile v shemo aaS - oglejte si intervju:
2. Pavel Selivanov, Southbridge: "Razvojci in operaterji imajo eno skupno nalogo - narediti izdelek, ki deluje"
Implementacija Kubernetesa ne bo pomagala doseči DevOps, nasprotno, lahko pokvari vse. Pavel je pojasnil, zakaj tehnologija (tudi najbolj kul) ne more rešiti vseh vaših težav:
Kompleksnost projekta je presegla kodo. Prej je obstajala zapletena aplikacija: interakcija znotraj projekta in zapleten razvoj, vendar preprosta struktura - skrbnik jo je namestil, vse deluje. Prešli smo na mikrostoritve: vsaka storitev je preprosta aplikacija, komunikacija po standardnih protokolih in hiter razvoj, struktura projekta pa je postala kompleksnejša. Kompleksnost projekta z arhitekturo mikrostoritev ni izginila – presegla je kodo. Zdaj je za to odgovoren inženir DevOps.
Razvijalci ne želijo sprememb po implementaciji DevOps. Posledično potek dela s Kubernetesom še naprej izgleda kot metanje nalog od Dev do Ops čez zid, le ne metaforičnega - Git postane takšen zid. Razvijalec postavi kodo tja in dela kot prej, admini pa imajo Kubernetes, CI/CD in vse ostalo.
Vendar morajo razvijalci sprejeti spremembe. Situacija, ko razvijalci ne vedo, kaj počnejo skrbniki, in administratorji ne vedo, kaj se dogaja z razvijalci, ustvarja težave.
Če se za razvijalce ni nič spremenilo, se ne zavedajo, da je delovanje aplikacije njihova odgovornost - razni tehnični triki ne bodo delovali.
S prihodom DevOps in Kubernetes se bo v razvoju marsikaj spremenilo. Razvijalci morajo biti usposobljeni za operacije in obratno. Ti strokovnjaki imajo svoje posebne veščine, vendar se morajo zavedati dela drug drugega. Dev in Ops morata biti prijatelja, preden uvedeta Kubernetes, sicer bosta pokvarila, kar imaš.
Pavel Selivanov je spregovoril o tem, kaj se bo zgodilo s Kubernetesom čez 5 let in na čem naj sodoben startup gradi tehnološki sklad - oglejte si intervju:
3. Vladimir Utratenko, X5 Retail Group: »DevOps in Enterprise je razvoj brez bolečin in požarov«
Podjetja pridejo v DevOps transformacijo, ko ugotovijo, da je razvoj prepočasen in ne ustreza realnostim, imajo željo po boljšem razvoju in hitrejšem razvoju.
Vladimir je pojasnil, kako se to zgodi in v čem je caka:
- Najprej podjetja najamejo DevOps inženirja. To je Senior System Administrator, ukvarja se z uvajanjem izdaje v produkcijo, standardizacijo razvojnega okolja, postavitvijo infrastrukture, odkrivanjem in odpravljanjem različnih težav, avtomatizacijo procesov in drugimi tehničnimi opravili.
- Potem en DevOps inženir ni več dovolj in podjetje najame DevOps ekipo. To je kompetenčni center, ki organizira prizadevanja različnih inženirjev in omogoča njihovo koncentracijo v eno smer.
- Pravzaprav so inženirji DevOps in ekipe DevOps anti-vzorci transformacije DevOps. Ker gre pri DevOps za prakse in kulturo, poleg tega obstajajo implementacije DevOps v tehnoloških podjetjih (SRE, Production Engineering).
Kaj storiti? Najemite začasno DevOps ekipo, ki bo pomagala implementirati DevOps transformacijo, izvajati prakse, gojiti razvojno kulturo in tehnološko kulturo.
Ko pride podjetje v igro in investira v DevOps, je možnih več scenarijev: ob vzletu se bo vse podrlo; bo ostal kot SRE/proizvodni inženiring ali vgrajene operacije; se bodo preselili v BizOps, ko bodo procesi temeljili na poslovnih metrikah.
Vladimir Utratenko nam je povedal, kako "krvav" je v resnici DevOps v podjetju in kako se prakse izvajajo v velikih trgovinah na drobno - oglejte si intervju:
4. Sergey Puzyrev, Facebook: “Proizvodni inženir skrbi za storitev kot celoto: da se tako uporabniki kot razvijalci zabavajo.”
Facebook je ogromno podjetje z velikim številom komponent, strežnikov, ljudi in podatkovnih centrov. Kljub svoji ogromni velikosti je zelo hiter – razvijalci lahko uvedejo storitve večkrat na dan. Tudi Facebook hitro raste in ne raste samo število uporabnikov in strežnikov, povečuje se tudi število razvijalcev, zaradi česar so procesi bolj kompleksni.
Sergej je povedal, kaj počne proizvodni inženir na Facebooku:
- Proizvodni inženir veliko kodira, imeti mora sistemsko znanje: operacijski sistemi, datotečni sistemi, baze podatkov, omrežja in podobno. Imeti mora izkušnje z delom s porazdeljenimi sistemi in Reliability Engineering, to je s podporo zanesljivosti izdelkov. Mora biti dežurna, torej dosegljiva za klic v vsakem trenutku.
- Proizvodni inženir se od programskega inženirja razlikuje po tem, da ima napredne veščine pri delovanju, vendar je v resnici podvrsta programskega inženirja. Programski inženirji kodirajo več; morda imajo dodatna znanja, povezana na primer z obdelavo podatkov. Na Facebooku morajo takšni specialisti tudi dežurati, kar marsikoga neprijetno preseneti.
- Piramida potreb proizvodnega inženirja v podjetju se začne s spremljanjem strežnikov in njihovega življenjskega cikla, torej pridobivanja nove strojne opreme, njene nastavitve, zagona. Naslednja raven je enaka na ravni storitev: spremljanje storitev in njihovega življenjskega cikla. Nato sledi brezhibno skaliranje in napredno spremljanje. Ko je življenjski cikel storitve avtomatiziran, preklopijo na samodejno skaliranje. In na koncu je treba opraviti uglaševanje, tako da je skaliranje učinkovito in podjetje prihrani denar in sredstva.
5. Mikhail Chinkov, AMBOSS: »En oddelek ne more slediti poti DevOps, slediti ji mora celotno podjetje«
Mikhail verjame, da je DevOps stalen razvoj. Ne morete predstaviti nekaterih orodij in se tam ustaviti. Katere težave podjetjem preprečujejo, da bi postala DevOps in kako izvajati prakse?
Razlika v razumevanju DevOps. Kanonični devops, kot ga vidijo evangelisti, sloni na 5 stebrih:
- kultura - osredotočenost na ljudi in sodelovanje;
- avtomatizacija - delegiranje rutine v potek dela;
- vitko - poudarek na zagotavljanju vrednosti uporabniku;
- deljenje - stalna izmenjava znanja;
- metrike in prejemanje povratnih informacij z njihovo uporabo.
Podjetja se običajno osredotočajo le na avtomatizacijo in zagotavljanje vrednosti uporabniku. Toda kultura, izmenjava znanja in meritve DevOps za sledenje razvoju zbledijo v ozadje.
Izzivi standardizacije DevOps. Cilji izdelkov so različni za vsa podjetja in jih ni mogoče standardizirati. Stanje DevOps v podjetju je odvisno od podjetja samega, a mnogi tega ne razumejo in menijo, da je dovolj, da najamejo DevOps inženirja.
Zakaj še nismo DevOps? Obstajata dve ključni težavi. V podjetju je počasen razvoj organizacije, težave s spreminjanjem vektorja v glavah tisočih zaposlenih. V startupih je prisotno pomanjkanje virov znanja in problem alokacije sredstev za transformacijo.
Faze razvoja DevOps v podjetju:
- prvi je infrastruktura v oblaku, vendar nihče ne ve, kako deluje, razen enega ali dveh administratorjev;
- drugič, infrastruktura je pregledna in razumljiva vsem inženirjem, vendar procesi niso racionalizirani;
- tretji - inženirji samostojno zaženejo in popravijo storitve v živo;
- četrti - inženirji bodo opcijsko prispevali k jedrni infrastrukturi, pregledna koda v oblaku, uvajanje z gumbom.
Idealna shema je, da imajo vsi enak dostop do infrastrukture, vsi inženirji imajo dostop do izdelka in razumejo, kaj počnejo.
Po zaključku vseh kulturnih in tehničnih gestaltov bo preoblikovanje podjetja DevOps upoštevalo povratne informacije iz meritev poslovanja in platforme.
6. Navdušenci nad DevOps pri Rosbank: "1000 dni za implementacijo DevOps v prekleto podjetje"
Yuri Bulich, Dina Maltseva, Evgeny Pankov iz Rosbank so povedali, kako so v treh letih prišli do DevOps. Cilja sta bila dva: reševanje specifičnih problemov v določenih ekipah in implementacija centraliziranih orodij.
Tukaj so doseženi rezultati:
Rezultati za skupine izdelkov: 30-krat hitrejša montaža, 6-krat hitrejša montaža, do 30 % prihranka pri celotnem ciklu. Zdaj imamo možnost, da pritisnemo gumb, da preidemo na produktivnost
Rezultati za ukaze platforme: 10-krat hitrejša montaža in namestitev, 87 % povečano število namestitev, 46 % pokritost s samodejnim testiranjem. Integracijska ekipa ni več ozko grlo
Torej, kako implementirati prakse DevOps v prekleto podjetje?
Najprej izvedite pilotni projekt: Izberite ekipe, odločite se, kako implementirati arhitekturo in izberite orodja. Izbrali smo orodja z odprto licenco, z namestitvijo v banki in strokovnim znanjem za delo z njimi. Rosbank je hkrati s platformo DevOps uvedla zasebni oblak in to je pomagalo na začetku. V oblaku je bilo možno z gumbom pridobiti potrebne vire v 15 minutah, prej je tak postopek lahko trajal en teden.
V bankah in drugih podjetjih je treba z ekipo za informacijsko varnost vnaprej določiti omejitve in poiskati rešitev, ki bo omogočila izvedbo sprememb.
Po pilotu je treba uspešno rešitev povečati.
- Pomembno je čim bolj "zravnati" cevovod, odstraniti nepotrebne povezave iz njega, poudariti ponudnike vrednosti in odstraniti preostale komponente. Intermediati so antivzorci. Na primer, v Rosbank številne ekipe niso razvile notranjega razvoja, ampak je ostal samo zunanji razvoj. To je vodilo do nastanka namenske ekipe DevOps, ki je poskrbela za prenos kode od zunanjih k notranjim razvijalcem. Težavo so rešili tako, da so zunanji razvoj integrirali v CI/CD, tako da ne bi samo prenašali kode od sebe na banko, ampak bi bili tudi odgovorni za njen uspeh.
- Model zrelosti je vključeval elemente praks DevOps, naštela orodja in upošteval značilnosti dela z zunanjimi dobavitelji - v prihodnosti je to pripomoglo k hitremu zmanjšanju zaostankov pri izvajanju nalog v novih ekipah.
- Potrebujemo upravljanje v obliki mehkega nadzora in priporočil. Priročnik DevOps, ki dobro deluje, je nabor organizacijskih značilnosti in značilnosti orodij, ki ekipam pomagajo pri pravilni uporabi platforme.
- Takoj morate biti pozorni na kulturo, potem se bodo številne spremembe zgodile hitreje in lažje. Razširite svojo notranjo skupnost, organizirajte srečanja, tehnične delavnice, usposabljanja in zabavne dejavnosti. To obrodi sadove: ljudje si izmenjujejo prakse, vidijo, kdo je kaj naredil, vedo, kam se obrniti, znotraj podjetja vlada hype in zdrava konkurenca.
- Nima smisla delati s tistimi, ki niso vključeni v proces, z ekipami, ki niso dozorele, bolje je vlagati v zainteresirane ekipe in lojalne ljudi.
- Izbrana rešitev mora biti primerna za tiste inženirje, ki jo uporabljajo.
- Zunanji razvoj ni ovira, tam se lahko izvajajo tudi prakse, glavno je, da ima ekipa sama željo.
Malo več koristi
Seznam knjig, ki jih je vredno prebrati tistim v DevOpsu, Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Volja in samokontrola."
- Daniel Kahneman "Razmišljanje, hitro in počasno".
- Barbara Oakley "Um za številke".
- Maxim Dorofeev "Jedi tehnike".
- Viktor Frankl "Človekovo iskanje smisla".
Ostani na vezi
Obožujemo tudi DevOps. Spremljajte napovedi serije in @Kubernetes ter drugi dogodki Mail.ru Cloud Solutions v našem kanalu Telegram:
Vir: www.habr.com