Definícia DevOps je veľmi zložitá, takže diskusiu o nej musíme zakaždým začať odznova. Len o Habrém existuje na túto tému tisíc publikácií. Ale ak to čítate, pravdepodobne viete, čo je DevOps. Pretože nie som. Ahoj volám sa Alexander Titov (@), a budeme hovoriť len o DevOps a podelím sa o svoje skúsenosti.
Dlho som premýšľal nad tým, ako urobiť môj príbeh užitočným, takže tu bude veľa otázok – tých, ktoré sa pýtam ja, aj tých, ktoré sa pýtam klientov našej spoločnosti. Odpovedaním na tieto otázky sa lepšie porozumie. Poviem vám, prečo je DevOps z môjho pohľadu potrebný, čo to je, opäť z môjho pohľadu, a ako pochopiť, že z môjho pohľadu opäť smerujete k DevOps. Posledný bod bude cez otázky. Ak si na ne odpoviete sami, môžete pochopiť, či sa vaša spoločnosť uberá smerom k DevOps alebo či existujú nejaké problémy.
Svojho času som sa viezol na vlnách fúzií a akvizícií. Najprv som pracoval pre malý startup s názvom Qik, potom ho kúpila o niečo väčšia spoločnosť Skype, ktorú potom kúpila o niečo väčšia spoločnosť Microsoft. V tej chvíli som začal vidieť, ako sa myšlienka DevOps transformuje v rôznych veľkých spoločnostiach. Potom ma zaujal pohľad na DevOps z pohľadu trhu a s kolegami sme založili spoločnosť Express 42. Už 6 rokov sa pohybujeme na vlnách trhu.
Okrem iného som jedným z organizátorov komunity DevOps Moscow a organizátorom DevOps-Days 2017, ale 2018 som neorganizoval. Express 42 spolupracuje s mnohými spoločnosťami. Pestujeme tam DevOps, sledujeme, ako sa to deje, robíme závery, analyzujeme, hovoríme o našich záveroch všetkým a školíme ľudí v postupoch DevOps. Vo všeobecnosti robíme všetko, čo je v našich silách, aby sme zvýšili naše skúsenosti a odbornosť v tomto smere.
Prečo DevOps
Prvá otázka, ktorá prenasleduje každého a vždy je – prečo? Mnoho ľudí si myslí, že DevOps je len automatizácia alebo podobná vec, ktorú už mala každá firma.
— Mali sme nepretržitú integráciu – to znamená, že sme už mali DevOps a prečo sú všetky tieto veci potrebné? V zahraničí sa zabávajú, ale nám bránia v práci!
Za 9 rokov vývoja komunity a metodiky sa už ukázalo, že to stále nie je marketingový lesk, no stále nie je celkom jasné, prečo je to potrebné. Ako každý nástroj a proces, aj DevOps má špecifické ciele, ktoré v konečnom dôsledku dosahuje.
To všetko je spôsobené tým, že svet sa mení. Odchádza od podnikového prístupu, keď firmy idú priamo k snu, ako spieval náš petrohradský klasik, z bodu A do bodu B podľa určitej stratégie, s určitou štruktúrou na to vybudovanú.
Podľa tohto prístupu by malo byť v zásade všetko v IT postavené. Tu sa IT používa výlučne na automatizáciu procesov.
Automatizácia sa často nemení, pretože keď sa spoločnosť dostane do zabehnutých koľají, čo treba zmeniť? Funguje to - nedotýkajte sa toho. Teraz sa prístupy vo svete menia a ten s názvom Agile naznačuje, že koncový bod B nie je okamžite viditeľný.
Keď firma prechádza trhom, spolupracuje s klientom, neustále skúma trh a mení koncový bod B. Navyše, čím častejšie firma mení svoje smerovanie, tým je v konečnom dôsledku úspešnejšia, pretože si viac vyberá trh výklenky.
Stratégiu predvádza zaujímavá spoločnosť, o ktorej som sa nedávno dozvedel. One Box Shave je predplatená služba doručovania holiacich strojčekov a príslušenstva na holenie v krabici. Vedia prispôsobiť svoj „box“ rôznym klientom. Robí to určitý softvér, ktorý následne odošle objednávku do kórejskej továrne, ktorá tovar vyrába.
Tento produkt kúpil Unilever za 1 miliardu dolárov. Teraz konkuruje Gillette a na americkom trhu odobrala značný podiel spotrebiteľov. One Box Shave hovorí:
- 4 čepele? Vážne? Prečo to potrebujete - nezlepšuje to kvalitu oholenia. Špeciálne vybraný krém, vôňa a kvalitný holiaci strojček s dvoma čepieľkami rieši oveľa viac problémov ako tie hlúpe 4 čepieľky Gillette! Dostaneme sa čoskoro na 10?
Takto sa mení svet. Unilever tvrdí, že má skvelý IT systém, ktorý vám to umožňuje. Nakoniec to vyzerá ako koncept Doba uvedenia na trh, o ktorej už nikto nehovoril.
Pointa Time-to-market nie je v tom, ako často nasadzujeme. Často môžete nasadiť, ale cykly vydávania budú dlhé. Ak sa trojmesačné cykly vydávania navrstvia na seba a posunú ich o týždeň, zdá sa, že spoločnosť nasadzujú raz týždenne. A od nápadu po finálnu realizáciu to trvá 3 mesiace.
Time-to-market je o minimalizácii času od nápadu po konečnú realizáciu.
V tomto prípade softvér interaguje s trhom. Webová stránka One Box Shave takto komunikuje s klientom. Nemajú predajcov – iba web, na ktorý návštevníci klikajú a zanechávajú priania. V súlade s tým musí byť na stránke neustále zverejňované niečo nové a aktualizované podľa želaní. Napríklad v Južnej Kórei sa holia inak ako v Rusku a majú radi vôňu nie borovice, ale napríklad mrkvy a vanilky.
Keďže je potrebné rýchlo meniť obsah stránky, vývoj softvéru sa veľmi mení. Prostredníctvom softvéru musíme zistiť, čo klient chce. Predtým sme sa to naučili nejakým kruhovým objazdom, napríklad cez obchodný manažment. Potom sme to navrhli, dali požiadavky do IT systému a všetko bolo v pohode. Teraz je to iné – softvér navrhuje každý, kto je zapojený do procesu, vrátane inžinierov, pretože prostredníctvom technických špecifikácií sa učia, ako funguje trh, a tiež zdieľajú svoje poznatky s podnikom.
Napríklad v Qik sme sa zrazu dozvedeli, že ľuďom sa veľmi páčilo nahrávanie zoznamov kontaktov na server a dodali nám aplikáciu. Spočiatku sme o tom neuvažovali. V klasickej spoločnosti by sa každý rozhodol, že ide o chybu, keďže špecifikácia nehovorila, že by mala fungovať skvele a bola vo všeobecnosti implementovaná na kolene, túto funkciu by vypli a povedali: „Toto nikto nepotrebuje, najdôležitejšie je, aby fungovala hlavná funkcionalita.“ . A technologická spoločnosť to vidí ako príležitosť a v súlade s tým začína meniť softvér.
V roku 1968 sformuloval vizionár Melvin Conway nasledujúcu myšlienku.
Organizácia, ktorá vytvára systém, je obmedzená dizajnom, ktorý kopíruje komunikačnú štruktúru organizácie.
Podrobnejšie, aby ste mohli vyrábať systémy iného typu, musíte mať aj komunikačnú štruktúru v rámci spoločnosti iného typu. Ak je vaša komunikačná štruktúra top-hierarchická, potom vám to neumožní vytvoriť systémy, ktoré môžu poskytnúť veľmi vysoký ukazovateľ Time-to-Market.
Čítať jeden môže . Je to dôležité pre pochopenie kultúry alebo filozofie DevOps, pretože jediné, čo sa v DevOps zásadne mení, je štruktúra komunikácie medzi tímami.
Z procesného hľadiska boli pred DevOps všetky fázy: analytika, vývoj, testovanie, prevádzka lineárne.
V prípade DevOps sa všetky tieto procesy vyskytujú súčasne.
Čas uvedenia na trh je jediný spôsob, ako to dosiahnuť. Pre ľudí, ktorí pracovali v starom procese, to vyzerá trochu kozmicky a vo všeobecnosti tak.
Prečo teda potrebujete DevOps?
Pre digitálny vývoj produktov. Ak vaša spoločnosť nemá digitálny produkt, DevOps nie je potrebný – je to veľmi dôležité.
DevOps prekonáva rýchlostné obmedzenia sekvenčnej výroby softvéru. V ňom prebiehajú všetky procesy súčasne.
Náročnosť sa zvyšuje. Keď vám evanjelisti DevOps hovoria, že vám to uľahčí vydávanie softvéru, je to nezmysel.
S DevOps sa veci len skomplikujú.
Na konferencii v stánku Avito ste mohli vidieť, aké to bolo nasadiť kontajner Docker – nereálna úloha. Zložitosť sa stáva neúmernou; musíte žonglovať s mnohými loptičkami súčasne.
DevOps úplne mení proces a organizáciu vo firme — presnejšie, nie DevOps sa mení, ale digitálny produkt. Aby ste sa dostali do DevOps, stále musíte tento proces úplne zmeniť.
Otázky pre odborníka
Čo máš? Otázky, ktoré si môžete položiť pri práci vo firme a pri rozvoji ako špecialista.
Máte stratégiu na vytvorenie digitálneho produktu? Ak existuje, je to už dobré. To znamená, že vaša spoločnosť smeruje k DevOps.
Vytvára už vaša spoločnosť digitálny produkt? To znamená, že môžete postúpiť o ďalšiu úroveň vyššie a robiť veci zaujímavejšie – opäť z pohľadu DevOps. Hovorím len z tohto pohľadu.
Je vaša spoločnosť jedným z lídrov na trhu v oblasti digitálnych produktov? Spotify, Yandex, Uber sú spoločnosti, ktoré sú teraz na vrchole technologického pokroku.
Položte si tieto otázky a ak sú všetky odpovede nie, možno by ste v tejto spoločnosti nemali robiť DevOps. Ak je pre vás téma DevOps skutočne zaujímavá, možno... by ste sa mali presunúť do inej spoločnosti? Ak vaša spoločnosť chce ísť do DevOps, ale na všetky otázky ste odpovedali „Nie“, potom je to ako ten krásny nosorožec, ktorý sa nikdy nezmení.
Organizácia
Ako som povedal, podľa Conwayovho zákona sa organizácia spoločnosti mení. Začnem tým, čo bráni DevOps preniknúť do spoločnosti z organizačného hľadiska.
Problém "studní"
Anglické slovo "Silo" je tu preložené do ruštiny ako "dobre". Pointa tohto problému je v tom nedochádza k výmene informácií medzi tímami. Každý tím sa ponorí hlboko do svojich odborných znalostí bez toho, aby vytvoril spoločnú mapu na navigáciu.
V niektorých ohľadoch mi to pripomína človeka, ktorý práve prišiel do Moskvy a ešte nevie, ako sa orientovať na mape metra. Moskovčania zvyčajne veľmi dobre poznajú svoju oblasť a po celej Moskve sa vedia orientovať pomocou mapy metra. Keď prídete do Moskvy prvýkrát, nemáte túto zručnosť a ste jednoducho dezorientovaní.
DevOps navrhuje prekonať tento moment dezorientácie a všetky oddelenia spolupracovať na vytvorení spoločnej mapy interakcií.
Bránia tomu dva faktory.
Dôsledok systému riadenia podniku. Je postavená v samostatných hierarchických „studniach“. Napríklad v spoločnostiach, ktoré podporujú tento systém, existujú určité KPI. Na druhej strane, mozog človeka, ktorý len ťažko prekračuje hranice svojej odbornosti a orientuje sa v celom systéme, prekáža. Je to len nepríjemné. Predstavte si, že ste na letisku v Bangkoku – rýchlo sa tam nezorientujete. DevOps je tiež náročný na navigáciu, a preto ľudia hovoria, že musíte nájsť sprievodcu, aby ste sa tam dostali.
Najdôležitejšie však je, že problém „studní“ pre inžiniera, ktorý je preniknutý duchom DevOps, čítal Fowlera a množstvo ďalších kníh, je vyjadrený v tom, že „studne“ vám neumožňujú robiť „samozrejmé“ veci. Po DevOps Moskva sa často stretávame, rozprávame sa a ľudia sa sťažujú:
— Chceli sme len spustiť CI, ale ukázalo sa, že manažment to nepotrebuje.
To sa deje práve preto CI и Nepretržitý proces doručenia sú na hranici mnohých vyšetrení. Jednoducho bez prekonania problému „studní“ na organizačnej úrovni sa nepohnete vpred, bez ohľadu na to, čo robíte a akokoľvek je to smutné.
Každý účastník procesu vo firme: vývojári backendu a frontendu, testovanie, DBA, prevádzka, sieť, kope vlastným smerom a nikto nemá spoločnú mapu okrem manažéra, ktorý ich nejakým spôsobom sleduje a riadi pomocou „rozdelenia“. a dobývať“ metódu.
Ľudia bojujú o nejaké hviezdy alebo vlajky, každý razí svoju odbornosť.
Výsledkom je, že keď sa objaví úloha spojiť toto všetko dohromady a vybudovať spoločný plynovod a už nie je potrebné bojovať o hviezdy a vlajky, vyvstáva otázka - čo robiť? Musíme sa nejako dohodnúť, ale v škole nás to nikto neučil. Od školy nás učili: ôsma trieda - wow! - v porovnaní so siedmou triedou! Tu je to rovnaké.
Je to tak aj vo vašej firme?
Ak si to chcete overiť, môžete si položiť nasledujúce otázky.
Používajú tímy spoločné nástroje a prispievajú k zmenám týchto spoločných nástrojov?
Ako často sa tímy reorganizujú – niektorí špecialisti z jedného tímu prechádzajú do iného tímu? V prostredí DevOps sa to stáva normálnym, pretože niekedy človek jednoducho nedokáže pochopiť, čo robí iná oblasť odbornosti. Presťahuje sa na iné oddelenie, pracuje tam dva týždne, aby si vytvoril mapu orientácie a interakcie s týmto oddelením.
Je možné zostaviť komisiu pre zmenu a zmeniť veci? Alebo si to vyžaduje pevnú ruku najvyššieho vedenia a smerovania? Nedávno som na Facebooku písal, ako jedna málo známa banka implementuje nástroje cez príkazy: napíšeme príkaz, rok ho implementujeme a uvidíme, čo sa stane. Toto je, samozrejme, dlhé a smutné.
Aké dôležité je, aby manažéri získavali osobné úspechy bez toho, aby zohľadňovali úspechy spoločnosti?
Ak si na tieto otázky odpoviete sami, bude jasnejšie, či takýto problém vo vašej firme máte.
Infraštruktúra ako kód
Po prejdení tohto problému je prvou dôležitou praxou, bez ktorej je ťažké napredovať v DevOps ďalej infraštruktúru ako kód.
Infraštruktúra ako kód je najčastejšie vnímaná takto:
— Zautomatizujme všetko v bash, pokryjme sa skriptami, aby mali admini menej manuálnej práce!
Ale to nie je pravda.
Infraštruktúra ako kód znamená, že popíšete IT systém, s ktorým pracujete, vo forme kódu, aby ste neustále rozumeli jeho stavu.
Spolu s ostatnými tímami vytvárate mapu vo forme kódu, ktorej každý rozumie a vie sa v nej orientovať a orientovať. Nezáleží na tom, na čom sa to robí – Chef, Ansible, Salt alebo používanie súborov YAML v Kubernetes – nie je žiadny rozdiel.
Na konferencii kolega z 2GIS porozprával, ako pre Kubernetes vyrobili vlastnú internú vec, ktorá popisuje štruktúru jednotlivých systémov. Na popis 500 systémov potrebovali samostatný nástroj, ktorý tento popis generuje. Keď je tam tento popis, každý si môže navzájom kontrolovať, sledovať zmeny, ako to zmeniť a vylepšiť, čo tam chýba.
Súhlasíte, jednotlivé bash skripty zvyčajne neposkytujú toto pochopenie. V jednej z firiem, kde som pracoval, bol dokonca názov pre „write only“ skript – keď je scenár napísaný, ale už sa nedá prečítať. Myslím, že toto je známe aj vám.
Infraštruktúra ako kód kód, ktorý popisuje aktuálny stav infraštruktúry. Na tomto kóde spolupracuje mnoho produktových, infraštruktúrnych a servisných tímov a čo je najdôležitejšie, všetci musia pochopiť, ako tento kód vlastne funguje.
Kód je udržiavaný podľa osvedčených postupov kódovania: spoločný vývoj, kontrola kódu, programovanie XP, testovanie, požiadavky na stiahnutie, CI pre infraštruktúry kódu – to všetko je vhodné a možno to použiť.
Kód sa stáva spoločným jazykom pre všetkých inžinierov.
Zmena infraštruktúry v kóde nezaberie veľa času. Áno, aj kód infraštruktúry môže mať technický dlh. Obyčajne sa s tým tímy stretávajú rok a pol po tom, čo začali implementovať „infraštruktúru ako kód“ vo forme hromady skriptov alebo dokonca Ansible, ktoré píšu ako špagetový kód a do mixu prihadzujú aj bash skripty!
Je to dôležité,: Ak ste to ešte neskúšali, zapamätajte si to Ansible nie je bash! Pozorne si prečítajte dokumentáciu, preštudujte si, čo o nej píšu.
Infraštruktúra ako kód je oddelenie kódu infraštruktúry do samostatných vrstiev.
V našej spoločnosti rozlišujeme 3 základné vrstvy, ktoré sú veľmi prehľadné a jednoduché, no môže ich byť viac. Môžete sa pozrieť na váš kód infraštruktúry a povedať, či máte tento stav alebo nie. Ak nie sú zvýraznené žiadne vrstvy, musíte chvíľu trvať a trochu zrefaktorovať.
Základná vrstva - takto sa konfiguruje OS, zálohy a iné veci na nízkej úrovni, napríklad ako je na základnej úrovni nasadený Kubernetes.
Úroveň služieb - toto sú služby, ktoré poskytujete vývojárovi: logovanie ako služba, monitorovanie ako služba, databáza ako služba, balancer ako služba, fronta ako služba, Continuous Delivery ako služba - kopa služieb, ktoré jednotlivé tímy môže poskytnúť rozvoju. Toto všetko musí byť popísané v samostatných moduloch vo vašom systéme riadenia konfigurácie.
Vrstva, kde sa vytvárajú aplikácie a opisuje, ako sa rozvinú na vrchu predchádzajúcich dvoch vrstiev.
Kontrolné otázky
Má vaša spoločnosť spoločné úložisko infraštruktúry? Spravujete technický dlh vo svojej infraštruktúre? Používate vývojové postupy v úložisku infraštruktúry? Je vaša infraštruktúra rozdelená na vrstvy? Môžete skontrolovať schému Base-service-APP. Aké ťažké je urobiť zmenu?
Ak máte skúsenosť, že vykonanie zmien trvalo jeden a pol dňa, znamená to, že máte technický dlh a potrebujete s ním pracovať. Práve ste natrafili na technický dlh vo vašom kóde infraštruktúry. Pamätám si veľa takých príbehov, keď na zmenu nejakého CCTL potrebujete prepísať polovicu kódu infraštruktúry, pretože kreativita a túžba všetko automatizovať viedli k tomu, že všetko je všade skorodované, všetky kľučky sú odstránené a je potrebné refaktorovať.
Nepretržité doručovanie
Porovnajme debet s kreditom. Najprv príde na rad popis infraštruktúry, ktorý môže byť celkom základný. Nemusíte všetko podrobne popisovať, ale je potrebný nejaký základný popis, aby ste s ním mohli pracovať. V opačnom prípade nie je jasné, čo ďalej s nepretržitým doručovaním. Všetky tieto postupy sa odvíjajú súčasne, keď prídete do DevOps, ale začína to pochopením toho, čo máte a ako to spravovať. Toto je presne prax infraštruktúry ako kódu.
Keď bude jasné, že ho máte a ako ho spravovať, začnete vymýšľať, ako čo najrýchlejšie poslať vývojársky kód do výroby. Myslím spolu s vývojárom - pamätáme si na problém „studní“, to znamená, že s tým neprichádzajú jednotlivci, ale tím.
Keď sme s Vanya Evtukhovič videl prvú knihu Jez Humble a skupiny autorov "Nepretržité doručovanie", ktorý vyšiel v roku 2009, sme dlho rozmýšľali, ako jeho názov preložiť do ruštiny. Chceli to preložiť ako „Neustále doručovať“, ale, žiaľ, bolo to preložené ako „Nepretržité doručovanie“. Zdá sa mi, že v našom názve je niečo ruské, s tlakom.
Neustále dodávanie prostriedkov
Kód, ktorý je v produktovom úložisku, je možné vždy stiahnuť do produkcie. Nemusí byť vyfúknutý, ale vždy je na to pripravený. Preto vždy píšete kód s ťažko vysvetliteľným pocitom úzkosti pod kostrou. Často sa objavuje, keď zavádzate kód infraštruktúry. Tento pocit určitej úzkosti by mal byť prítomný – spúšťa mozgové procesy, ktoré vám umožňujú písať kód trochu inak. Toto by malo byť zaznamenané v pravidlách v rámci vývoja.
Na konzistentné poskytovanie potrebujete formát artefaktov, ktorý beží na platforme infraštruktúry. Ak hodíte „životný odpad“ rôznych formátov na platformu infraštruktúry, potom sa zjednotí, je ťažké ju udržiavať a vzniká problém technického dlhu. Formát artefaktu musí byť zarovnaný - to je tiež kolektívna úloha: všetci sa musíme spojiť, zašušťať si mozgy a prísť s týmto formátom.
Artefakt je neustále vylepšovaný a mení sa tak, aby vyhovoval produkčnému prostrediu, keď sa pohybuje cez doručovacie potrubie. Keď sa artefakt pohybuje po potrubí, neustále sa stretáva s nejakými pre neho nepohodlnými vecami, ktoré sú podobné tým, s ktorými sa stretáva artefakt, ktorý vkladáte do výroby. Ak to pri klasickom vývoji robí správca systému, ktorý robí rollout, tak v procese DevOps sa to deje stále: tu to testovali nejakými testami, tu to hodili do klastra Kubernetes, ktorý je viac-menej podobný do výroby, potom zrazu začali testovať záťaž .
Trochu to pripomína hru Pac-Man – artefakt prechádza nejakým príbehom. Zároveň je dôležité kontrolovať, či kód skutočne prechádza príbehom a či nejako súvisí s vašou produkciou. Príbehy z výroby je možné pretiahnuť do procesu nepretržitého doručovania: bolo to takto, keď niečo spadlo, teraz len naprogramujte tento scenár v systéme. Zakaždým, keď kód prejde aj týmto scenárom, a nabudúce sa s týmto problémom nestretnete. Dozviete sa o ňom oveľa skôr, ako sa dostane k vášmu klientovi.
Rôzne stratégie nasadenia. Napríklad používate testovanie AB alebo nasadenia canary na testovanie kódu na rôznych klientoch odlišne, získavate informácie o tom, ako kód funguje, a to oveľa skôr, ako keď je spustený pre 100 miliónov používateľov.
„Konzistentne doručovať“ vyzerá takto.
Proces doručenia Dev, CI, Test, PreProd, Prod nie je samostatné prostredie, sú to stupne alebo stanice s ohňovzdornými sumami, ktorými prechádza váš artefakt.
Ak máte kód infraštruktúry, ktorý je opísaný ako Base Service APP, pomôže vám to nezabudnite na všetky skriptya zapíšte si ich ako kód pre tento artefakt, propagovať artefakt a meniť to za pochodu.
Samotestovacie otázky
Čas od popisu funkcie po uvoľnenie do produkcie je v 95% prípadov menej ako týždeň? Zlepšuje sa kvalita artefaktu v každej fáze potrubia? Je nejaký príbeh, ktorým to prechádza? Používate rôzne stratégie nasadenia?
Ak sú všetky odpovede áno, potom ste neuveriteľne cool! Odpovede píšte do komentárov - budem rád).
spätná väzba
Toto je najťažšia prax zo všetkých. Na konferencii DevOpsConf bol kolega z Infobipu, ktorý o tom hovoril, vo svojich slovách trochu zmätený, pretože toto je naozaj veľmi komplexná prax o tom, že treba všetko sledovať!
Napríklad kedysi dávno, keď som pracoval v Qiku a uvedomili sme si, že musíme všetko sledovať. Urobili sme to a teraz máme v Zabbixe 150 000 položiek, ktoré sú neustále monitorované. Bolo to desivé, technický riaditeľ si krútil prstom na spánku:
- Chlapci, prečo znásilňujete server niečím nejasným?
Potom však došlo k incidentu, ktorý ukázal, že toto je naozaj veľmi cool stratégia.
Jedna zo služieb začala neustále padať. Spočiatku nepadal, čo je zaujímavé, kód tam nebol pridaný, pretože išlo o základného brokera, ktorý nemal prakticky žiadnu obchodnú funkcionalitu - jednoducho posielal správy medzi jednotlivými službami. Služba sa 4 mesiace nezmenila a zrazu začala padať s chybou „Chyba segmentácie“.
Boli sme šokovaní, otvorili sme grafy v Zabbixe a ukázalo sa, že pred týždňom a pol sa veľmi zmenilo správanie požiadaviek v službe API, ktorú tento broker používa. Ďalej sme videli, že sa zmenila frekvencia odosielania určitého typu správ. Neskôr sme zistili, že ide o androidových klientov. Opýtali sme sa:
— Chlapci, čo sa vám stalo pred týždňom a pol?
V reakcii na to sme počuli zaujímavý príbeh o tom, ako prepracovali používateľské rozhranie. Je nepravdepodobné, že niekto okamžite povie, že zmenil knižnicu HTTP. Pre klientov so systémom Android je to ako výmena mydla v kúpeľni – jednoducho si to nepamätajú. V dôsledku toho sme po 40 minútach rozhovoru zistili, že zmenili knižnicu HTTP a zmenili sa jej predvolené načasovanie. To viedlo k zmene dopravného správania na serveri API, čo viedlo k situácii, ktorá spôsobila preteky v rámci brokera a ten začal padať.
Bez hlbokého monitorovania to vo všeobecnosti nie je možné otvoriť. Ak má organizácia stále problém so „studňami“, keď na seba všetci hádžu peniaze, môže to prežiť roky. Jednoducho reštartujete server, pretože problém nie je možné vyriešiť. Keď monitorujete, sledujete, sledujete všetky udalosti, ktoré máte, a používate monitorovanie ako testovanie - napíšte kód a okamžite uveďte, ako ho monitorovať, aj vo forme kódu (už máme infraštruktúru ako kód), všetko bude jasné, ako na dlani. Aj takéto zložité problémy sa dajú ľahko sledovať.
Zhromaždite všetky informácie o tom, čo sa stane s artefaktom v každej fáze procesu dodávky – nie vo výrobe.
Nahrajte monitoring do CI a tam už budú viditeľné niektoré základné veci. Neskôr ich uvidíte v testoch, PredProd a záťažovom testovaní. Zbierajte informácie vo všetkých fázach, nielen metriky, štatistiky, ale aj protokoly: ako sa aplikácia spustila, anomálie – zbierajte všetko.
Inak to bude ťažké zistiť. Už som povedal, že DevOps je zložitejší. Aby ste sa vyrovnali s touto zložitosťou, musíte mať normálnu analytiku.
Otázky na sebaovládanie
Je pre vás vaše monitorovanie a protokolovanie vývojovým nástrojom? Myslia vaši vývojári vrátane vás pri písaní kódu na to, ako ho monitorovať?
Počuli ste o problémoch od zákazníkov? Rozumiete klientovi lepšie z monitorovania a logovania? Chápete systém lepšie z monitorovania a logovania? Zmenili ste systém len preto, že ste videli, že trend v systéme rastie a chápete, že o ďalšie 3 týždne všetko umrie?
Keď budete mať tieto tri komponenty, môžete premýšľať o tom, akú platformu infraštruktúry máte vo svojej spoločnosti.
Platforma infraštruktúry
Nejde o to, že ide o súbor rôznorodých nástrojov, ktoré má každá firma.
Zmyslom platformy infraštruktúry je, že všetky tímy používajú tieto nástroje a vyvíjajú ich spoločne.
Je zrejmé, že existujú samostatné tímy, ktoré sú zodpovedné za vývoj jednotlivých častí platformy infraštruktúry. Ale zároveň každý inžinier nesie zodpovednosť za vývoj, výkon a propagáciu platformy infraštruktúry. Na vnútornej úrovni sa stáva bežným nástrojom.
Všetky tímy vyvíjajú platformu infraštruktúry a zaobchádzajú s ňou opatrne ako so svojím vlastným IDE. Vo svojom IDE nainštalujete rôzne doplnky, aby bolo všetko pekné a rýchle, a nakonfigurujete klávesové skratky. Keď otvoríte Sublime, Atom alebo Visual Studio Code, vrhajú sa na vás chyby v kóde a vy si uvedomíte, že sa to nedá vôbec fungovať, hneď je vám smutno a bežíte opraviť svoje IDE.
Zaobchádzajte so svojou platformou infraštruktúry rovnakým spôsobom. Ak chápete, že s tým nie je niečo v poriadku, zanechajte žiadosť, ak to nemôžete opraviť sami. Ak je niečo jednoduché, upravte si to sami, pošlite žiadosť o stiahnutie, chlapci to zvážia a pridajú. Ide o trochu iný prístup k inžinierskym nástrojom v hlave vývojára.
Infraštruktúrna platforma zabezpečuje prenos artefaktu z vývoja ku klientovi s neustálym zlepšovaním kvality. IP je naprogramovaná sériou príbehov, ktoré sa dejú s kódom vo výrobe. Za roky vývoja je týchto príbehov veľa, niektoré sú jedinečné a týkajú sa len vás – nedajú sa vygoogliť.
V tomto bode sa platforma infraštruktúry stáva vašou konkurenčnou výhodou, pretože má v sebe zabudované niečo, čo nie je v nástroji konkurencie. Čím hlbšia je vaša IP, tým väčšia je vaša konkurenčná výhoda, pokiaľ ide o čas uvedenia na trh. Zobrazuje sa tu problém so zámkom predajcu: Môžete si vziať platformu niekoho iného, ale pomocou skúseností niekoho iného nebudete chápať, nakoľko je to pre vás relevantné. Áno, nie každá spoločnosť dokáže vybudovať platformu ako Amazon. Toto je zložitá línia, kde sú skúsenosti spoločnosti relevantné pre jej postavenie na trhu a nemôžete tam použiť zámok predajcu. Aj na toto je dôležité myslieť.
Schéma
Toto je základná schéma platformy infraštruktúry, ktorá vám pomôže nastaviť všetky postupy a procesy v spoločnosti DevOps.
Pozrime sa, z čoho pozostáva.
Systém orchestrácie zdrojov, ktorá poskytuje CPU, pamäť, disk aplikáciám a ďalším službám. A navyše - služby nízkej úrovne: monitorovanie, protokolovanie, CI/CD Engine, ukladanie artefaktov, infraštruktúra ako systémový kód.
Služby vyššej úrovne: databáza ako služba, fronty ako služba, Load Balance ako služba, zmena veľkosti obrázka ako služba, Big Data factory ako služba. A navyše - kanál, ktorý vášmu klientovi dodáva neustále upravovaný kód.
Dostávate informácie o tom, ako váš softvér funguje pre klienta, meníte ho, dodávate tento kód znova, dostávate informácie – a tak neustále vyvíjate platformu infraštruktúry aj váš softvér.
V diagrame sa dodávacie potrubie skladá z mnohých etáp. Ale toto je schematický diagram, ktorý je uvedený ako príklad - nie je potrebné ho opakovať jeden po druhom. Fázy interagujú so službami, ako keby to boli služby – každá tehla platformy nesie svoj vlastný príbeh: ako sa prideľujú zdroje, ako sa spúšťa aplikácia, ako pracuje so zdrojmi, ako sa monitoruje a ako sa mení.
Je dôležité pochopiť, že každá časť platformy nesie príbeh a položte si otázku, aký príbeh nesie táto tehla, možno by ste ju mali vyhodiť a nahradiť službou tretej strany. Je napríklad možné nainštalovať Okmeter namiesto tehly? Možno už chalani rozvinuli túto odbornosť oveľa viac ako my. Ale možno nie – možno máme jedinečné odborné znalosti, musíme nainštalovať Prometheus a ďalej ho rozvíjať.
Vytvorenie platformy
Ide o zložitý komunikačný proces. Keď máte základné postupy, začnete komunikovať medzi rôznymi inžiniermi a špecialistami, ktorí vyvíjajú požiadavky a normy a neustále ich menia na rôzne nástroje a prístupy. Kultúra, ktorú máme v DevOps, je tu dôležitá.
S kultúrou je všetko veľmi jednoduché - je to o spolupráci a komunikácii, teda túžbu pracovať na spoločnom poli medzi sebou, túžbu spoločne ovládať jeden nástroj. Nie je tu žiadna raketová veda - všetko je veľmi jednoduché, banálne. Napríklad všetci bývame vo vchode a udržiavame v ňom čistotu – taká kultúrna úroveň.
Čo máš?
Opäť otázky, ktoré si môžete položiť.
Je platforma infraštruktúry vyhradená? Kto je zodpovedný za jeho vývoj? Rozumiete konkurenčným výhodám vašej infraštruktúry?
Tieto otázky si musíte neustále klásť. Ak je možné niečo preniesť do služieb tretích strán, malo by sa to preniesť; ak vám služba tretej strany začne blokovať pohyb, musíte si v sebe vybudovať systém.
Takže DevOps...
... je to zložitý systém, musí mať:
- Digitálny produkt.
- Obchodné moduly, ktoré vyvíjajú tento digitálny produkt.
- Produktové tímy, ktoré píšu kód.
- Postupy nepretržitého doručovania.
- Platformy ako služba.
- Infraštruktúra ako služba.
- Infraštruktúra ako kód.
- Samostatné postupy na udržanie spoľahlivosti zabudované do DevOps.
- Prax spätnej väzby, ktorá to všetko popisuje.
Môžete použiť tento diagram a zvýrazniť v ňom to, čo už vo vašej spoločnosti v nejakej forme máte: vyvinulo sa to alebo ešte treba dopracovať.
O pár týždňov bude koniec . ako súčasť RIT++. Príďte na konferenciu, kde nájdete množstvo skvelých správ o nepretržitom doručovaní, infraštruktúre ako kóde a transformácii DevOps. , posledný cenový termín je 20. mája
Zdroj: hab.com