Definicija DevOps je zelo zapletena, zato moramo o njej vsakič znova začeti razpravo. Samo na Habréju je na to temo tisoč objav. Toda če to berete, verjetno veste, kaj je DevOps. Ker nisem. živijo, ime mi je Aleksander Titov (@), govorili bomo samo o DevOps in delil bom svojo izkušnjo.
Dolgo sem razmišljal, kako narediti svojo zgodbo uporabno, zato bo tukaj veliko vprašanj - tistih, ki jih zastavljam sebi, in tistih, ki jih postavljam strankam našega podjetja. Z odgovorom na ta vprašanja se razumevanje izboljša. Povedal vam bom, zakaj je DevOps potreben z mojega vidika, kaj je, spet z mojega vidika, in kako razumeti, da se z mojega vidika znova premikate proti DevOps. Zadnja točka bo skozi vprašanja. Če nanje odgovorite sami, lahko razumete, ali se vaše podjetje usmerja k DevOps ali pa obstajajo težave na nek način.
Nekoč sem jezdil na valovih združitev in prevzemov. Najprej sem delal za majhno startup podjetje Qik, nato ga je kupilo malo večje podjetje Skype, ki ga je nato kupilo malo večje podjetje Microsoft. V tistem trenutku sem začel opažati, kako se ideja o DevOps spreminja v podjetjih različnih velikosti. Po tem me je začel zanimati pogled na DevOps s tržnega vidika in s sodelavci smo ustanovili podjetje Express 42. Že 6 let se gibljemo po valovih trga.
Med drugim sem eden od organizatorjev skupnosti DevOps Moskva in organizator DevOps-Days 2017, vendar nisem organiziral 2018. Express 42 sodeluje s številnimi podjetji. Tam razvijamo DevOps, opazujemo, kako se dogaja, sklepamo, analiziramo, vsem povemo svoje zaključke in usposabljamo ljudi o praksah DevOps. Na splošno si po svojih najboljših močeh prizadevamo povečati naše izkušnje in strokovno znanje v zvezi s tem.
Zakaj DevOps
Prvo vprašanje, ki preganja vse in vedno je – zakaj? Marsikdo misli, da je DevOps samo avtomatizacija ali podobna stvar, ki jo ima že vsako podjetje.
— Imeli smo stalno integracijo - to pomeni, da smo že imeli DevOps in zakaj so vse te stvari potrebne? V tujini se zabavajo, nam pa onemogočajo delo!
V 9 letih razvoja skupnosti in metodologije je že postalo jasno, da to še vedno ni marketinški blišč, vendar še vedno ni povsem jasno, zakaj je to potrebno. Kot vsako orodje in proces ima tudi DevOps posebne cilje, ki jih na koncu doseže.
Vse to je posledica dejstva, da se svet spreminja. Odmika se od podjetniškega pristopa, ko gredo podjetja naravnost proti sanjam, kot je pel naš peterburški klasik, od točke A do točke B po določeni strategiji, z določeno strukturo, zgrajeno za to.
Načeloma bi moralo biti vse v IT zgrajeno po tem pristopu. Tukaj se IT uporablja izključno za avtomatizacijo procesov.
Avtomatizacija se ne spreminja pogosto, kajti, ko podjetje zaide po utečeni tirnici, kaj se lahko spremeni? Deluje - ne dotikajte se ga. Zdaj se pristopi v svetu spreminjajo in tisti, imenovan Agile, nakazuje, da končna točka B ni takoj vidna.
Ko gre podjetje skozi trg, dela s stranko, nenehno raziskuje trg in spreminja končno točko B. Še več, pogosteje ko podjetje spreminja svojo usmeritev, uspešnejše je na koncu, saj izbere več trga. niše.
Strategijo prikazuje zanimivo podjetje, za katerega sem izvedel pred kratkim. One Box Shave je naročniška storitev dostave britvic in pripomočkov za britje v škatli. Svojo »škatlo« znajo prilagoditi različnim naročnikom. To naredi določena programska oprema, ki nato pošlje naročilo v korejsko tovarno, ki blago proizvaja.
Ta izdelek je kupil Unilever za milijardo dolarjev. Zdaj konkurira Gillette in ji je odvzel pomemben delež potrošnikov na ameriškem trgu. One Box Shave pravi:
— 4 rezila? Ali si resen? Zakaj to potrebujete - ne izboljša kakovosti britja. Posebej izbrana krema, dišava in kakovostna britvica z dvema reziloma rešijo veliko več težav kot tista butasta 4 rezila Gillette! Bomo kmalu prišli do 10?
Tako se spreminja svet. Unilever trdi, da imajo kul IT sistem, ki vam to omogoča. Na koncu je videti kot koncept Čas do trga, o čemer ni še nihče govoril.
Bistvo časa do trga ni v tem, kako pogosto uvajamo. Pogosto lahko uvedete, vendar bodo cikli izdaje dolgi. Če trimesečne cikle izdajanja prekrivamo drug drugega in jih premaknemo za en teden, se izkaže, da podjetje uvaja enkrat na teden. In od ideje do končne izvedbe mine 3 mesece.
Pri času do trga gre za zmanjšanje časa od ideje do končne izvedbe.
V tem primeru programska oprema sodeluje s trgom. Tako spletno mesto One Box Shave komunicira s stranko. Nimajo prodajalcev – samo spletno stran, kjer obiskovalci klikajo in puščajo želje. Zato je treba na strani nenehno objavljati nekaj novega in dopolnjevati v skladu z željami. Na primer, v Južni Koreji se brijejo drugače kot v Rusiji in jim ni všeč vonj po borovcih, ampak na primer po korenju in vaniliji.
Ker je treba hitro spremeniti vsebino strani, se razvoj programske opreme močno spremeni. S pomočjo programske opreme moramo ugotoviti, kaj stranka želi. Prej smo se tega naučili po kakšnih obhodnih poteh, na primer skozi vodenje podjetij. Potem smo ga zasnovali, postavili zahteve v IT sistem in vse je bilo kul. Zdaj je drugače – programsko opremo oblikujejo vsi, ki so vključeni v proces, vključno z inženirji, saj skozi tehnične specifikacije izvedo, kako deluje trg, in svoje vpoglede delijo tudi s podjetjem.
Na primer, pri Qiku smo nenadoma izvedeli, da ljudje zelo radi nalagajo sezname stikov na strežnik, in so nam priskrbeli aplikacijo. Sprva o tem nismo razmišljali. V klasičnem podjetju bi se vsi odločili, da je to hrošč, ker v specifikaciji ni pisalo, da bi moralo delovati odlično in je bilo na splošno implementirano na kolenu, bi to funkcijo izklopili in rekli: »Tega nihče ne potrebuje, najpomembnejše je, da glavna funkcionalnost deluje.” . In tehnološko podjetje to vidi kot priložnost in začne v skladu s tem spreminjati programsko opremo.
Leta 1968 je vizionar Melvin Conway oblikoval naslednjo idejo.
Organizacija, ki ustvarja sistem, je omejena z zasnovo, ki posnema komunikacijsko strukturo te organizacije.
Natančneje, za proizvodnjo sistemov drugačnega tipa morate imeti tudi komunikacijsko strukturo v podjetju drugega tipa. Če je vaša komunikacijska struktura hierarhična na najvišji ravni, vam to ne bo omogočilo ustvarjanja sistemov, ki lahko zagotovijo zelo visok indikator časa do trga.
Preberi eno lahko . Pomembno je za razumevanje kulture ali filozofije DevOps, ker edina stvar, ki se v DevOpsu bistveno spremeni, je struktura komunikacije med ekipami.
S procesnega vidika so bile pred DevOps vse faze: analitika, razvoj, testiranje, delovanje linearne.
V primeru DevOps se vsi ti procesi odvijajo hkrati.
To je edini način, da pridemo na trg. Za ljudi, ki so delali po starem postopku, je to videti nekoliko kozmično in na splošno tako, tako.
Zakaj torej potrebujete DevOps?
Za razvoj digitalnih izdelkov. Če vaše podjetje nima digitalnega izdelka, DevOps ni potreben – je zelo pomemben.
DevOps premaga hitrostne omejitve sekvenčne proizvodnje programske opreme. V njem se vsi procesi odvijajo hkrati.
Težavnost se poveča. Ko vam evangelisti DevOps pravijo, da vam bo olajšalo izdajo programske opreme, je to nesmisel.
Z DevOps bodo stvari le še bolj zapletene.
Na konferenci na Avito stojnici ste lahko videli, kako je bilo postaviti Docker kontejner – nerealna naloga. Kompleksnost postane previsoka; žonglirati morate z več žogicami hkrati.
DevOps popolnoma spremeni proces in organizacijo v podjetju — natančneje, ne spreminja se DevOps, ampak digitalni izdelek. Če želite priti do DevOps, morate še vedno popolnoma spremeniti ta postopek.
Vprašanja za specialista
Kaj imaš? Vprašanja, ki si jih lahko postavite ob delu v podjetju in se razvijate kot specialist.
Ali imate strategijo za ustvarjanje digitalnega izdelka? Če obstaja, je to že dobro. To pomeni, da se vaše podjetje usmerja k DevOps.
Ali vaše podjetje že ustvarja digitalni izdelek? To pomeni, da se lahko povzpnete še eno stopnjo višje in počnete stvari bolj zanimivo – spet z vidika DevOps. Govorim samo s tega vidika.
Je vaše podjetje eno izmed vodilnih na trgu v niši digitalnih izdelkov? Spotify, Yandex, Uber so podjetja, ki so trenutno na vrhuncu tehnološkega napredka.
Zastavite si ta vprašanja in če so vsi odgovori ne, potem morda ne bi smeli izvajati DevOps v tem podjetju. Če vas tema DevOps res zanima, bi se morda morali preseliti v drugo podjetje? Če vaše podjetje želi iti v DevOps, vendar ste na vsa vprašanja odgovorili z "Ne", potem je kot tisti čudoviti nosorog, ki se ne bo nikoli spremenil.
Organizacija
Kot sem rekel, po Conwayevem zakonu se organizacija podjetja spremeni. Začel bom s tem, kaj DevOpsu preprečuje prodor znotraj podjetja z organizacijskega vidika.
Problem "vodnjakov"
Angleška beseda "Silo" je tukaj prevedena v ruščino kot "dobro". Bistvo tega problema je v tem med ekipami ni izmenjave informacij. Vsaka ekipa se poglobi v svoje strokovno znanje, ne da bi zgradila skupni zemljevid za navigacijo.
Na nek način me to spominja na osebo, ki je pravkar prispela v Moskvo in še ne zna krmariti po zemljevidu metroja. Moskovčani običajno zelo dobro poznajo svoje območje in po Moskvi se lahko premikajo po zemljevidu metroja. Ko prideš prvič v Moskvo, nimaš te veščine in si preprosto dezorientiran.
DevOps predlaga, da preživite ta trenutek dezorientacije in da vsi oddelki sodelujejo pri izdelavi skupnega zemljevida interakcij.
Dva dejavnika to ovirata.
Posledica sistema korporativnega upravljanja. Zgrajen je v ločenih hierarhičnih "vodnjakih". Na primer, v podjetjih obstajajo določeni KPI-ji, ki podpirajo ta sistem. Po drugi strani pa so v napoto možgani človeka, ki težko preseže meje svojega znanja in krmari po celotnem sistemu. Samo neprijetno je. Predstavljajte si, da ste na letališču v Bangkoku - ne boste se hitro znašli. Po DevOps je tudi težko krmariti in zato ljudje pravijo, da morate najti vodnika, da pridete tja.
Najpomembneje pa je, da se problem "vodnjakov" za inženirja, ki je prežet z duhom DevOps, je prebral Fowlerja in kup drugih knjig, izraža v tem, da "vodnjaki" ti ne dovoljujejo "očitnih" stvari. Pogosto se dobimo po DevOps Moskva, se pogovarjamo in ljudje se pritožujejo:
— Želeli smo samo lansirati CI, vendar se je izkazalo, da ga vodstvo ne potrebuje.
To se zgodi prav zaradi CI и Neprekinjen postopek dostave so na meji številnih izpitov. Preprosto brez premagovanja problema "vodnjakov" na organizacijski ravni ne boste mogli napredovati, ne glede na to, kaj počnete in ne glede na to, kako žalostno je.
Vsak udeleženec procesa v podjetju: backend in frontend razvijalci, testiranje, DBA, operacija, mreža, koplje v svojo smer in nihče nima skupnega zemljevida razen managerja, ki jih nekako spremlja in upravlja z »divide« in osvoji«.
Ljudje se tepejo za neke zvezdice ali zastavice, vsak koplje svoje znanje.
Posledično, ko se pojavi naloga, da vse to povežemo in zgradimo skupni plinovod in se ni več treba boriti za zvezdice in zastave, se postavlja vprašanje - kaj sploh storiti? Nekako se moramo dogovoriti, a tega nas v šoli ni nihče naučil. Že od šole so nas učili: osmi razred - vau! - v primerjavi s sedmim razredom! Tukaj je enako.
Je tako tudi v vašem podjetju?
Če želite to preveriti, si lahko zastavite naslednja vprašanja.
Ali ekipe uporabljajo skupna orodja in prispevajo k spremembam teh skupnih orodij?
Kako pogosto se ekipe reorganizirajo – nekateri strokovnjaki iz ene ekipe preidejo v drugo ekipo? V okolju DevOps to postane normalno, saj včasih oseba preprosto ne more razumeti, kaj počne drugo strokovno področje. Preseli se na drug oddelek, tam dela dva tedna, da si ustvari zemljevid orientacije in interakcije s tem oddelkom.
Ali je mogoče sestaviti komisijo za spremembe in spremeniti stvari? Ali pa zahteva močno roko najvišjega vodstva in usmerjanja? Pred kratkim sem na Facebooku pisal, kako ena malo znana banka implementira orodja prek naročil: napišemo naročilo, ga izvajamo eno leto in vidimo, kaj se zgodi. To je seveda dolgo in žalostno.
Kako pomembno je za menedžerje prejemanje osebnih dosežkov brez upoštevanja dosežkov podjetja?
Če si sami odgovorite na ta vprašanja, vam bo bolj jasno, ali imate v svojem podjetju tak problem.
Infrastruktura kot koda
Ko je ta težava rešena, je prva pomembna praksa, brez katere je težko napredovati v DevOps infrastruktura kot koda.
Najpogosteje se infrastruktura kot koda dojema na naslednji način:
— Avtomatizirajmo vse v bashu, pokrijmo se s skriptami, da imajo administratorji manj ročnega dela!
Ampak to ni res.
Infrastruktura kot koda pomeni, da IT sistem, s katerim delate, opišete v obliki kode, da bi nenehno razumeli njegovo stanje.
Skupaj z drugimi ekipami ustvarite zemljevid v obliki kode, ki jo vsi razumejo in se znajo premikati in krmariti. Ni pomembno, na čem se izvaja – Chef, Ansible, Salt ali z uporabo datotek YAML v Kubernetesu – ni razlike.
Na konferenci je kolega iz 2GIS povedal, kako so za Kubernetes naredili svojo interno stvar, ki opisuje strukturo posameznih sistemov. Za opis 500 sistemov so potrebovali ločeno orodje, ki generira ta opis. Ko je ta opis, lahko vsi preverjajo drug drugega, spremljajo spremembe, kako to spremeniti in izboljšati, kaj manjka.
Strinjam se, posamezni bash skripti običajno ne zagotavljajo tega razumevanja. V enem od podjetij, kjer sem delal, je obstajalo celo ime za “write only” skripto - ko je skripta napisana, vendar je ni več mogoče brati. Mislim, da je to tudi vam znano.
Infrastruktura kot koda je kodo, ki opisuje trenutno stanje infrastrukture. Številne skupine za izdelke, infrastrukturo in storitve sodelujejo pri tej kodi, in kar je najpomembnejše, vsi morajo razumeti, kako ta koda dejansko deluje.
Koda se vzdržuje v skladu z najboljšimi praksami kodiranja: skupni razvoj, pregled kode, XP-programiranje, testiranje, zahteve po vleku, CI za kodne infrastrukture - vse to je primerno in se lahko uporablja.
Koda postane skupni jezik za vse inženirje.
Spreminjanje infrastrukture v kodi ne vzame veliko časa. Da, infrastrukturna koda ima lahko tudi tehnični dolg. Običajno se ekipe z njim srečajo leto in pol po tem, ko so začele implementirati "infrastrukturo kot kodo" v obliki kopice skript ali celo Ansible, ki jih pišejo kot špageti kodo, v mešanico pa vržejo tudi bash skripte!
Pomembno je,: Če tega še niste poskusili, si zapomnite to Ansible ni bash! Pazljivo preberite dokumentacijo, preučite, kaj pišejo o tem.
Infrastruktura kot koda je ločitev infrastrukturne kode na ločene plasti.
V našem podjetju ločimo 3 osnovne plasti, ki so zelo jasne in enostavne, lahko pa jih je več. Pogledate lahko svojo infrastrukturno kodo in ugotovite, ali imate ta pogoj ali ne. Če nobena plast ni označena, si morate vzeti nekaj časa in malo preoblikovati.
osnovni sloj - tako so konfigurirani OS, varnostne kopije in druge stvari na nizki ravni, na primer, kako je Kubernetes nameščen na osnovni ravni.
Raven storitev - to so storitve, ki jih nudite razvijalcu: beleženje kot storitev, spremljanje kot storitev, baza podatkov kot storitev, balancer kot storitev, čakalna vrsta kot storitev, Continuous Delivery kot storitev - kup storitev, ki jih posamezne ekipe lahko zagotovijo razvoju. Vse to je treba opisati v ločenih modulih v vašem sistemu za upravljanje konfiguracije.
Plast, kjer se izvajajo aplikacije in opisuje, kako se bodo razvili na prejšnjih dveh slojih.
Kontrolna vprašanja
Ali ima vaše podjetje skupen repozitorij infrastrukture? Ali upravljate tehnični dolg v vaši infrastrukturi? Ali uporabljate razvojne prakse v infrastrukturnem repozitoriju? Je vaša infrastruktura razrezana na plasti? Lahko preverite diagram Base-service-APP. Kako težko je narediti spremembo?
Če ste doživeli, da je za izvedbo sprememb potreben dan in pol, to pomeni, da imate tehnični dolg in morate z njim delati. Pravkar ste v svoji infrastrukturni kodi naleteli na tehnično zadolžitev. Spomnim se veliko takšnih zgodb, ko je treba za spremembo nekega CCTL-ja prepisati polovico infrastrukturne kode, ker je kreativnost in želja po avtomatizaciji vsega pripeljala do tega, da je povsod vse razjedeno, vsi ročaji so bili odstranjeni in potrebno je preurediti.
Neprekinjena dostava
Primerjajmo debet s kreditom. Najprej sledi opis infrastrukture, ki je lahko precej osnovna. Ni vam treba vsega podrobno opisati, vendar je potreben osnovni opis, da lahko z njim delate. Sicer ni jasno, kaj z neprekinjeno dostavo naprej. Vse te prakse se odvijajo hkrati, ko pridete v DevOps, vendar se začne z razumevanjem, kaj imate in kako to upravljati. To je ravno praksa infrastrukture kot kode.
Ko postane jasno, da jo imate in kako z njo upravljate, začnete ugotavljati, kako čim hitreje poslati razvijalsko kodo v proizvodnjo. Mislim skupaj z razvijalcem - spominjamo se problema "vodnjakov", to pomeni, da se tega ne domislijo posamezni ljudje, ampak ekipa.
Ko smo z Vanja Evtuhovič videl prvo knjigo Jez Humble in skupine avtorjev "Neprekinjena dostava", ki je izšla leta 2009, smo dolgo razmišljali, kako prevesti njen naslov v ruščino. Želeli so ga prevesti kot »Nenehno dostavljati«, a je bilo na žalost prevedeno kot »Neprekinjena dostava«. Zdi se mi, da je nekaj ruskega v našem imenu, s pritiskom.
Nenehno dovajanje pomeni
Kodo, ki je v repozitoriju izdelkov, je mogoče vedno prenesti v proizvodnjo. Morda ni napihnjen, a je vedno pripravljen na to. Skladno s tem kodo vedno pišete s težko razložljivim občutkom neke tesnobe pod repom. Pogosto se pojavi, ko uvedete infrastrukturno kodo. Ta občutek neke tesnobe bi moral biti prisoten - sproži možganske procese, ki ti omogočajo pisanje kode malo drugače. To je treba zabeležiti v pravilniku v okviru razvoja.
Za dosledno zagotavljanje potrebujete obliko artefakta, ki deluje na infrastrukturni platformi. Če po infrastrukturni platformi vržeš »življenjske odpadke« različnih formatov, postane ta poenotena, težko jo je vzdrževati in nastane problem tehnične zadolženosti. Format artefakta je treba uskladiti – tudi to je kolektivna naloga: vsi moramo stopiti skupaj, si zašuštrati in se domisliti tega formata.
Artefakt se nenehno izboljšuje in spreminja, da ustreza produkcijskemu okolju, ko se premika skozi dostavni cevovod. Ko se artefakt premika po cevovodu, nenehno naleti na nekaj zanj neprijetnih stvari, ki so podobne tistim, na katere naleti artefakt, ki ga daš v proizvodnjo. Če pri klasičnem razvoju to dela sistemski skrbnik, ki dela rollout, se pri procesu DevOps to dogaja ves čas: tukaj so ga preizkusili z nekimi testi, tukaj so ga vrgli v gručo Kubernetes, ki je bolj ali manj podobna. v proizvodnjo, nato pa so nenadoma začeli s testiranjem obremenitve.
To nekoliko spominja na igro Pac-Man - artefakt gre skozi nekakšno zgodbo. Hkrati je pomembno nadzorovati, ali gre koda dejansko skozi zgodbo in ali je kakorkoli povezana z vašo produkcijo. Zgodbe iz produkcije lahko povlečete v proces neprekinjene dostave: tako je bilo, ko je nekaj padlo, zdaj pa programirajte ta scenarij znotraj sistema. Vsakič bo koda šla tudi skozi ta scenarij in naslednjič ne boste naleteli na to težavo. Zanj boste izvedeli veliko prej, kot bo prišlo do vaše stranke.
Različne strategije uvajanja. Na primer, uporabljate testiranje AB ali kanarčkove uvedbe, da različno preizkusite kodo na različnih odjemalcih, pridobite informacije o tem, kako koda deluje, in veliko prej kot takrat, ko je uvedena za 100 milijonov uporabnikov.
"Dosledno zagotavljanje" izgleda takole.
Proces dostave Dev, CI, Test, PreProd, Prod ni ločeno okolje, to so stopnje ali postaje z ognjevarnimi vsotami, skozi katere gre vaš artefakt.
Če imate infrastrukturno kodo, ki je opisana kot Base Service APP, potem pomaga ne pozabite na vse scenarijein jih zapišite kot kodo za ta artefakt, promovirati artefakt in ga spreminjajte sproti.
Vprašanja za samopreverjanje
Čas od opisa funkcije do objave v produkciji je v 95 % primerov krajši od enega tedna? Ali se kakovost artefakta izboljša na vsaki stopnji cevovoda? Ali obstaja zgodba, skozi katero gre? Ali uporabljate različne strategije uvajanja?
Če so vsi odgovori pritrdilni, potem ste neverjetno kul! Napišite svoje odgovore v komentarje - vesel bom).
Povratne informacije
To je najtežja praksa od vseh. Na konferenci DevOpsConf je bil kolega iz Infobipa, ko je govoril o tem, malo zmeden v svojih besedah, ker je to res zelo kompleksna praksa o tem, da je treba spremljati vse!
Na primer, dolgo nazaj, ko sem delal v Qiku in smo ugotovili, da moramo vse spremljati. To nam je uspelo in zdaj imamo v Zabbixu 150 predmetov, ki jih nenehno spremljamo. Bilo je strašljivo, tehnični direktor je zasukal prst na templju:
- Fantje, zakaj posilite strežnik z nečim nejasnim?
Potem pa se je zgodil incident, ki je pokazal, da je to res zelo kul strategija.
Ena od storitev se je začela nenehno sesuvati. Sprva se ni zrušil, kar je zanimivo, koda tam ni bila dodana, ker je šlo za osnovnega brokerja, ki praktično ni imel poslovne funkcionalnosti - preprosto je pošiljal sporočila med posameznimi storitvami. Storitev se ni spremenila 4 mesece in nenadoma se je začela zrušiti z napako »Segmentation fault«.
Bili smo šokirani, odprli naše grafikone v Zabbixu in izkazalo se je, da se je pred tednom in pol obnašanje zahtev v storitvi API, ki jo uporablja ta posrednik, močno spremenilo. Nato smo videli, da se je pogostost pošiljanja določene vrste sporočil spremenila. Kasneje smo ugotovili, da so to androidni odjemalci. Vprašali smo:
— Fantje, kaj se vam je zgodilo pred tednom in pol?
V odgovor smo slišali zanimivo zgodbo o tem, kako so preoblikovali uporabniški vmesnik. Malo verjetno je, da bo kdo takoj rekel, da je spremenil knjižnico HTTP. Za odjemalce Android je to kot menjava mila v kopalnici – preprosto se ne spomnijo. Posledično smo po 40 minutah pogovora ugotovili, da so spremenili knjižnico HTTP in njeni privzeti časi so se spremenili. To je povzročilo spremembo vedenja prometa na strežniku API, kar je privedlo do situacije, ki je povzročila tekmo znotraj posrednika, in začel se je zrušiti.
Brez poglobljenega nadzora je tega na splošno nemogoče odpreti. Če ima organizacija še vedno problem »vodnjakov«, ko vsi mečejo denar drug na drugega, lahko to živi še leta. Preprosto znova zaženete strežnik, ker je nemogoče rešiti težavo. Ko spremljaš, slediš, spremljaš vse dogodke, ki jih imaš, in uporabljaš spremljanje kot testiranje - napišeš kodo in takoj navedeš, kako to spremljati, tudi v obliki kode (infrastrukturo že imamo kot kodo), postane vse jasno, kako na dlani. Celo tako kompleksnim težavam je enostavno slediti.
Zberite vse informacije o tem, kaj se zgodi z artefaktom na vsaki stopnji postopka dostave – ne v proizvodnji.
Naložite spremljanje v CI, pa bodo že tam vidne nekatere osnovne stvari. Kasneje jih boste videli v Testu, PredProd in obremenitvenem testiranju. Zbirajte informacije na vseh stopnjah, ne samo meritve, statistike, ampak tudi dnevnike: kako se je aplikacija uvedla, anomalije – zberite vse.
Sicer bo to težko ugotoviti. Rekel sem že, da je DevOps bolj zapleten. Če želite obvladati to zapletenost, morate imeti normalno analitiko.
Vprašanja za samokontrolo
Je vaše spremljanje in beleženje razvojno orodje za vas? Ali vaši razvijalci, vključno z vami, pri pisanju kode razmišljajo o tem, kako jo spremljati?
Ali od strank slišite o težavah? Ali s spremljanjem in beleženjem bolje razumete stranko? Ali bolje razumete sistem iz spremljanja in beleženja? Spremenite sistem preprosto zato, ker ste videli, da trend v sistemu raste in razumete, da bo v naslednjih 3 tednih vse umrlo?
Ko imate te tri komponente, lahko razmislite o tem, kakšno infrastrukturno platformo imate v svojem podjetju.
Infrastrukturna platforma
Bistvo ni v tem, da gre za nabor različnih orodij, ki jih ima vsako podjetje.
Bistvo infrastrukturne platforme je, da vse ekipe uporabljajo ta orodja in jih skupaj razvijajo.
Jasno je, da obstajajo ločene ekipe, ki so odgovorne za razvoj posameznih delov infrastrukturne platforme. Hkrati pa vsak inženir nosi odgovornost za razvoj, delovanje in promocijo infrastrukturne platforme. Na notranji ravni postane običajno orodje.
Vse ekipe razvijajo infrastrukturno platformo in jo skrbno obravnavajo kot svoj IDE. V vašem IDE namestite različne vtičnike, da bo vse lepo in hitro, in konfigurirate bližnjične tipke. Ko odprete Sublime, Atom ali Visual Studio Code, se vrstijo napake kode in ugotovite, da je sploh nemogoče delati, takoj postanete žalostni in stečete popravljati svoj IDE.
Na enak način ravnajte s svojo infrastrukturno platformo. Če razumete, da je s tem nekaj narobe, pustite zahtevo, če tega ne morete popraviti sami. Če je kaj preprostega, uredite sami, pošljite zahtevo za vlečenje, fantje bodo razmislili in dodali. To je nekoliko drugačen pristop k inženirskim orodjem v glavi razvijalca.
Infrastrukturna platforma zagotavlja prenos artefakta od razvoja do naročnika s stalnim izboljševanjem kakovosti. IP je programiran z nizom zgodb, ki se zgodijo s kodo v proizvodnji. V letih razvoja je teh zgodb veliko, nekatere so unikatne in se nanašajo samo na vas – ne morejo se jih poguglati.
Na tej točki infrastrukturna platforma postane vaša konkurenčna prednost, ker ima vgrajeno nekaj, kar ni v tekmovalčevem orodju. Globlji kot je vaš IP, večja je vaša konkurenčna prednost v smislu časa do trga. Pojavi se tukaj težava z zaklepanjem prodajalca: Lahko vzamete platformo nekoga drugega, vendar z uporabo izkušenj nekoga drugega ne boste razumeli, kako pomembna je za vas. Da, ne more vsako podjetje zgraditi platforme, kot je Amazon. To je težka linija, kjer so izkušnje podjetja pomembne za njegov položaj na trgu, in tam ne morete uporabiti zaklepa prodajalca. Tudi o tem je pomembno razmišljati.
Shema
To je osnovni diagram infrastrukturne platforme, ki vam bo pomagal vzpostaviti vse prakse in procese v podjetju DevOps.
Poglejmo, iz česa je sestavljen.
Sistem orkestracije virov, ki zagotavlja CPU, pomnilnik, disk aplikacijam in drugim storitvam. Poleg tega - storitve na nizki ravni: spremljanje, beleženje, CI/CD Engine, shranjevanje artefaktov, infrastruktura kot sistemska koda.
Storitve na višji ravni: baza podatkov kot storitev, čakalne vrste kot storitev, ravnovesje obremenitve kot storitev, spreminjanje velikosti slike kot storitev, tovarna velikih podatkov kot storitev. Poleg tega - cevovod, ki vašemu odjemalcu dostavlja stalno spremenjeno kodo.
Prejmete informacije o tem, kako vaša programska oprema deluje za odjemalca, jo spremenite, ponovno zagotovite to kodo, prejmete informacije – in tako nenehno razvijate infrastrukturno platformo in svojo programsko opremo.
V diagramu je dostavni cevovod sestavljen iz več stopenj. Toda to je shematski diagram, ki je podan kot primer - ni ga treba ponavljati enega za drugim. Stopnje komunicirajo s storitvami, kot da bi bile storitve – vsaka kocka platforme nosi svojo zgodbo: kako so viri dodeljeni, kako se aplikacija zažene, kako deluje z viri, se spremlja in spreminja.
Pomembno je razumeti, da vsak del platforme nosi zgodbo, in se vprašajte, kakšno zgodbo nosi ta opeka, morda bi jo bilo treba zavreči in nadomestiti s storitvijo tretje osebe. Na primer, ali je mogoče namestiti Okmeter namesto opeke? Morda so fantje to strokovnost razvili že veliko bolj kot mi. Morda pa ne - morda imamo edinstveno strokovno znanje, moramo namestiti Prometheus in ga nadalje razvijati.
Izdelava platforme
To je kompleksen komunikacijski proces. Ko imate osnovne prakse, začnete komunikacijo med različnimi inženirji in strokovnjaki, ki razvijajo zahteve in standarde ter jih nenehno spreminjajo z različnimi orodji in pristopi. Tu je pomembna kultura, ki jo imamo v DevOps.
S kulturo je vse zelo preprosto - gre za sodelovanje in komunikacijo, to je želja po medsebojnem delovanju na skupnem področju, želja po skupnem vihtenju enega instrumenta. Tukaj ni raketne znanosti - vse je zelo preprosto, banalno. Na primer, vsi živimo v vhodu in skrbimo za čistočo - taka raven kulture.
Kaj imaš?
Spet vprašanja, ki si jih lahko zastavite.
Ali je infrastrukturna platforma namenska? Kdo je odgovoren za njegov razvoj? Ali razumete konkurenčne prednosti vaše infrastrukturne platforme?
Ta vprašanja si morate nenehno postavljati. Če je nekaj mogoče prenesti na storitve tretjih oseb, je treba to prenesti; če storitev tretjih oseb začne blokirati vaše gibanje, potem morate zgraditi sistem v sebi.
Torej, DevOps ...
... to je zapleten sistem, mora imeti:
- Digitalni izdelek.
- Poslovni moduli, ki razvijajo ta digitalni izdelek.
- Produktne ekipe, ki pišejo kodo.
- Prakse neprekinjene dostave.
- Platforme kot storitev.
- Infrastruktura kot storitev.
- Infrastruktura kot koda.
- Ločene prakse za ohranjanje zanesljivosti, vgrajene v DevOps.
- Praksa povratnih informacij, ki opisuje vse.
Lahko uporabite ta diagram in v njem poudarite, kaj že imate v vašem podjetju v neki obliki: ali se je razvilo ali ga je treba še razviti.
V nekaj tednih bo konec . kot del RIT++. Pridite na konferenco, kjer boste našli veliko kul poročil o neprekinjenem izvajanju, infrastrukturi kot kodi in transformaciji DevOps. , zadnji rok za ceno je 20. maj
Vir: www.habr.com