Definice DevOps je velmi složitá, takže diskusi o tom musíme pokaždé začít znovu. Jen o Habrém existuje na toto téma tisíc publikací. Ale pokud to čtete, pravděpodobně víte, co je DevOps. Protože nejsem. Ahoj jmenuji se Alexander Titov (@), a budeme mluvit jen o DevOps a já se podělím o své zkušenosti.
Dlouho jsem přemýšlel, jak udělat svůj příběh užitečným, takže tady bude spousta otázek - těch, které si kladu já, i těch, které se ptám klientů naší společnosti. Odpovědí na tyto otázky se porozumění stává lepším. Řeknu vám, proč je DevOps z mého pohledu potřeba, co to je, opět z mého pohledu, a jak pochopit, že z mého pohledu opět směřujete k DevOps. Poslední bod bude prostřednictvím otázek. Tím, že si na ně odpovíte sami, můžete pochopit, zda se vaše společnost posouvá směrem k DevOps nebo zda existují nějaké problémy.
Svého času jsem se vezl na vlnách fúzí a akvizic. Nejprve jsem pracoval pro malý startup jménem Qik, pak ho koupila o něco větší společnost Skype, kterou pak koupila o něco větší společnost Microsoft. V tu chvíli jsem začal vidět, jak se myšlenka DevOps transformuje ve společnostech různých velikostí. Poté jsem se začal zajímat o pohled na DevOps z pohledu trhu a s kolegy jsme založili společnost Express 42. Již 6 let se pohybujeme na vlnách trhu.
Mimo jiné jsem jedním z organizátorů komunity DevOps Moskva a organizátorem DevOps-Days 2017, ale 2018 jsem neorganizoval. Express 42 spolupracuje s mnoha společnostmi. Rozvíjíme tam DevOps, sledujeme, jak se to děje, vyvozujeme závěry, analyzujeme, sdělujeme své závěry všem a školíme lidi v postupech DevOps. Obecně se v tomto ohledu snažíme zvyšovat naše zkušenosti a odbornost.
Proč DevOps
První otázka, která pronásleduje každého a vždy, je – proč? Mnoho lidí si myslí, že DevOps je jen automatizace nebo podobná věc, kterou už měla každá firma.
— Měli jsme kontinuální integraci – to znamená, že jsme již měli DevOps a proč jsou všechny tyto věci potřeba? V zahraničí se baví, ale nám brání v práci!
Za 9 let vývoje komunity a metodiky se již ukázalo, že se stále nejedná o marketingový třpyt, ale stále není zcela jasné, proč je potřeba. Jako každý nástroj a proces má DevOps specifické cíle, kterých nakonec dosáhne.
To vše je dáno tím, že se svět mění. Odchází od podnikového přístupu, kdy firmy jdou přímo za snem, jak zpíval náš petrohradský klasik, z bodu A do bodu B podle určité strategie, s určitou strukturou k tomu postavenou.
V zásadě by vše v IT mělo být postaveno podle tohoto přístupu. Zde se IT používá výhradně k automatizaci procesů.
Automatizace se často nemění, protože když se společnost dostane do zajetých kolejí, co se má změnit? Funguje to - nesahejte na to. Nyní se přístupy ve světě mění a ten nazvaný Agile naznačuje, že koncový bod B není okamžitě viditelný.
Když firma prochází trhem, spolupracuje s klientem, neustále zkoumá trh a mění koncový bod B. Navíc čím častěji firma mění svůj směr, tím je nakonec úspěšnější, protože si více vybírá trh výklenky.
Strategii předvádí zajímavá společnost, o které jsem se nedávno dozvěděl. One Box Shave je předplatná služba doručování holicích strojků a příslušenství na holení v krabici. Vědí, jak přizpůsobit svůj „box“ různým klientům. K tomu slouží určitý software, který pak objednávku odešle do korejské továrny, která daný produkt vyrábí.
Tento produkt koupil Unilever za 1 miliardu dolarů. Nyní konkuruje Gillette a na americkém trhu sebral významný podíl spotřebitelů. One Box Shave říká:
— 4 čepele? to myslíš vážně? Proč to potřebujete - nezlepší to kvalitu oholení. Speciálně vybraný krém, vůně a kvalitní holicí strojek se dvěma břity řeší mnohem více problémů než ty stupidní 4 břity Gillette! Dostaneme se brzy na 10?
Takhle se mění svět. Unilever tvrdí, že má skvělý IT systém, který vám to umožňuje. Nakonec to vypadá jako koncept Čas nakupovat, o kterém už nikdo nemluvil.
Smyslem Time-to-market není to, jak často nasazujeme. Často můžete nasadit, ale cykly vydání budou dlouhé. Pokud se tříměsíční cykly vydávání překryjí a posunou o týden, vypadá to, že společnost nasazuje jednou týdně. A od nápadu po finální realizaci to trvá 3 měsíce.
Time-to-market je o minimalizaci času od nápadu po konečnou realizaci.
V tomto případě software interaguje s trhem. Web One Box Shave takto komunikuje s klientem. Nemají prodejce – jen web, na který návštěvníci klikají a zanechávají přání. V souladu s tím musí být na webu neustále zveřejňováno něco nového a aktualizováno podle přání. Třeba v Jižní Koreji se holí jinak než v Rusku a mají rádi vůni ne borovice, ale třeba mrkve a vanilky.
Vzhledem k tomu, že je nutné rychle měnit obsah stránek, vývoj softwaru se velmi mění. Prostřednictvím softwaru musíme zjistit, co klient chce. Dříve jsme se to učili okružními cestami, například prostřednictvím obchodního managementu. Pak jsme to navrhli, dali požadavky do IT systému a všechno bylo v pohodě. Nyní je to jiné – software navrhují všichni, kdo jsou zapojeni do procesu, včetně inženýrů, protože prostřednictvím technických specifikací se učí, jak funguje trh, a také sdílejí své poznatky s firmou.
Například v Qik jsme se najednou dozvěděli, že lidem se opravdu líbí nahrávání seznamů kontaktů na server, a dodali nám aplikaci. Zpočátku jsme o tom nepřemýšleli. V klasické společnosti by každý usoudil, že se jedná o chybu, protože specifikace neříkala, že by měla fungovat skvěle a byla obecně implementována na koleni, tuto funkci by vypnuli a řekli: „Tohle nikdo nepotřebuje, nejdůležitější je, aby fungovala hlavní funkce.“ . A technologická společnost to vidí jako příležitost a v souladu s tím začíná měnit software.
V roce 1968 zformuloval vizionář Melvin Conway následující myšlenku.
Organizace, která vytváří systém, je omezena návrhem, který replikuje komunikační strukturu této organizace.
Podrobněji, abyste mohli vyrábět systémy jiného typu, musíte mít také komunikační strukturu v rámci společnosti jiného typu. Pokud je vaše komunikační struktura top-hierarchická, pak vám to neumožní vytvářet systémy, které mohou poskytovat velmi vysoký ukazatel Time-to-Market.
číst jeden může . Je to důležité pro pochopení kultury nebo filozofie DevOps, protože jediné, co se v DevOps zásadně mění, je struktura komunikace mezi týmy.
Z procesního hlediska byly před DevOps všechny fáze: analytika, vývoj, testování, provoz lineární.
V případě DevOps probíhají všechny tyto procesy současně.
Time-to-market je jediný způsob, jak toho dosáhnout. Pro lidi, kteří pracovali ve starém procesu, to vypadá poněkud vesmírně a obecně tak-tak.
Proč tedy potřebujete DevOps?
Pro vývoj digitálních produktů. Pokud vaše společnost nemá digitální produkt, DevOps není potřeba – je to velmi důležité.
DevOps překonává rychlostní omezení sekvenční výroby softwaru. V něm všechny procesy probíhají současně.
Obtížnost se zvyšuje. Když vám evangelisté DevOps říkají, že vám to usnadní vydávání softwaru, je to nesmysl.
S DevOps se věci jen zkomplikují.
Na konferenci na stánku Avito jste se mohli podívat, jaké to bylo s nasazením kontejneru Docker – nereálný úkol. Složitost se stává neúnosnou, musíte žonglovat s mnoha míčky současně.
DevOps zcela mění proces a organizaci ve firmě — přesněji řečeno, nemění se DevOps, ale digitální produkt. Abyste se dostali do DevOps, musíte tento proces ještě úplně změnit.
Otázky pro odborníka
Co máš? Otázky, které si můžete klást při práci ve společnosti a rozvoji jako specialista.
Máte strategii pro vytvoření digitálního produktu? Pokud existuje, je to již dobré. To znamená, že vaše společnost směřuje k DevOps.
Vytváří již vaše společnost digitální produkt? To znamená, že můžete postoupit o další úroveň výše a dělat věci zajímavěji – opět z pohledu DevOps. Mluvím jen z tohoto úhlu pohledu.
Je vaše společnost jedním z lídrů na trhu v oblasti digitálních produktů? Spotify, Yandex, Uber jsou společnosti, které jsou nyní na vrcholu technologického pokroku.
Zeptejte se sami sebe na tyto otázky, a pokud jsou všechny odpovědi ne, pak byste možná neměli dělat DevOps v této společnosti. Pokud je pro vás téma DevOps opravdu zajímavé, možná... byste měli přejít k jiné společnosti? Pokud chce vaše společnost vstoupit do DevOps, ale na všechny otázky jste odpověděli „Ne“, pak je to jako ten krásný nosorožec, který se nikdy nezmění.
Organizace
Jak jsem řekl, podle Conwayova zákona se organizace společnosti mění. Začnu tím, co brání DevOps proniknout dovnitř společnosti z organizačního hlediska.
Problém "studny"
Anglické slovo „Silo“ je zde přeloženo do ruštiny jako „well“. Podstatou tohoto problému je to nedochází k výměně informací mezi týmy. Každý tým se ponoří hluboko do svých odborných znalostí, aniž by vytvořil společnou mapu pro navigaci.
V některých ohledech mi to připomíná člověka, který právě přijel do Moskvy a ještě neví, jak se orientovat na mapě metra. Moskvané obvykle velmi dobře znají svou oblast a po celé Moskvě se mohou orientovat pomocí mapy metra. Když přijedete do Moskvy poprvé, nemáte tuto dovednost a jste jen dezorientovaní.
DevOps navrhuje překonat tento okamžik dezorientace a všechna oddělení spolupracovat na vytvoření společné mapy interakcí.
Tomu brání dva faktory.
Důsledek systému řízení podniku. Je postaven v samostatných hierarchických „studnách“. Například ve společnostech, které tento systém podporují, existují určité KPI. Na druhou stranu mozek člověka, který jen těžko překračuje hranice své odbornosti a orientuje se v celém systému, překáží. Je to prostě nepříjemné. Představte si, že jste na letišti v Bangkoku – rychle se tam nezorientujete. DevOps se také obtížně orientuje, a proto lidé říkají, že musíte najít průvodce, abyste se tam dostali.
Ale nejdůležitější je, že problém „studen“ pro inženýra, který je prodchnutý duchem DevOps, četl Fowlera a spoustu dalších knih, je vyjádřen ve skutečnosti „studny“ vám neumožňují dělat „samozřejmé“ věci. Často se po DevOps Moskva scházíme, mluvíme spolu a lidé si stěžují:
— Chtěli jsme jen spustit CI, ale ukázalo se, že vedení to nepotřebuje.
To se děje právě proto CI и Průběžný proces dodání jsou na hranici mnoha vyšetření. Jednoduše bez překonání problému „studen“ na organizační úrovni se nebudete moci posunout vpřed, ať děláte cokoli a jakkoli je to smutné.
Každý účastník procesu ve firmě: vývojáři backendu a frontendu, testování, DBA, provoz, síť, kope svým směrem a nikdo nemá společnou mapu kromě manažera, který je nějak sleduje a spravuje pomocí „rozdělení a dobývat“ metodu.
Lidé bojují o nějaké hvězdy nebo vlajky, každý razí svou odbornost.
Ve výsledku, když vyvstane úkol toto vše propojit a vybudovat společný plynovod a už není třeba bojovat o hvězdy a vlajky, vyvstává otázka – co vlastně dělat? Musíme se nějak dohodnout, ale ve škole nás to nikdo neučil. Od školy nás učili: osmá třída - wow! - ve srovnání se sedmou třídou! Tady je to stejné.
Je to tak i ve vaší firmě?
Chcete-li to zkontrolovat, můžete si položit následující otázky.
Používají týmy společné nástroje a přispívají ke změnám těchto společných nástrojů?
Jak často se týmy reorganizují – někteří specialisté z jednoho týmu přecházejí do jiného týmu? V prostředí DevOps se to stává normální, protože někdy člověk prostě nemůže pochopit, co dělá jiná oblast odbornosti. Přechází na jiné oddělení, pracuje tam dva týdny, aby si vytvořil mapu orientace a interakce s tímto oddělením.
Je možné sestavit výbor pro změnu a věci změnit? Nebo to vyžaduje pevnou ruku nejvyššího vedení a vedení? Nedávno jsem na Facebooku psal, jak jedna málo známá banka implementuje nástroje prostřednictvím objednávek: napíšeme objednávku, rok ji implementujeme a uvidíme, co se stane. To je samozřejmě dlouhé a smutné.
Jak důležité je, aby manažeři dostávali osobní úspěchy bez ohledu na úspěchy společnosti?
Pokud si na tyto otázky odpovíte sami, bude jasnější, zda takový problém ve vaší firmě máte.
Infrastruktura jako kód
Po překonání tohoto problému je první důležitá praxe, bez které je těžké v DevOps postoupit dále infrastruktura jako kód.
Nejčastěji je infrastruktura jako kód vnímána takto:
— Zautomatizujme vše v bash, zakryjme se skripty, aby měli admini méně manuální práce!
Ale to není pravda.
Infrastruktura jako kód znamená, že popíšete IT systém, se kterým pracujete, formou kódu, abyste neustále rozuměli jeho stavu.
Společně s ostatními týmy vytváříte mapu ve formě kódu, kterému každý rozumí a umí se v něm orientovat a orientovat. Nezáleží na tom, na čem se to dělá – Chef, Ansible, Salt nebo použití souborů YAML v Kubernetes – není v tom žádný rozdíl.
Na konferenci kolega z 2GIS vyprávěl, jak pro Kubernetes vyrobili vlastní interní věc, která popisuje strukturu jednotlivých systémů. K popisu 500 systémů potřebovali samostatný nástroj, který tento popis generuje. Když je tam tento popis, každý si může vzájemně kontrolovat, sledovat změny, jak to změnit a vylepšit, co chybí.
Souhlasíte, jednotlivé bash skripty obvykle neposkytují toto porozumění. V jedné z firem, kde jsem pracoval, byl dokonce název pro „write only“ skript – kdy je scénář napsaný, ale už jej nelze přečíst. Myslím, že je vám to také známé.
Infrastruktura jako kód kód, který popisuje aktuální stav infrastruktury. Na tomto kódu spolupracuje mnoho produktových, infrastrukturních a servisních týmů, a co je nejdůležitější, všichni potřebují pochopit, jak tento kód skutečně funguje.
Kód je udržován v souladu s osvědčenými postupy pro kódování: společný vývoj, kontrola kódu, programování XP, testování, požadavky na stahování, CI pro infrastruktury kódu - to vše je vhodné a lze to použít.
Kód se stává společným jazykem pro všechny inženýry.
Změna infrastruktury v kódu nezabere mnoho času. Ano, i kód infrastruktury může mít technický dluh. Obvykle se s tím týmy setkávají rok a půl poté, co začaly implementovat „infrastrukturu jako kód“ ve formě hromady skriptů nebo dokonce Ansible, které píší jako špagetový kód, a navíc do toho házejí bash skripty!
Je to důležité,: Pokud jste to ještě nezkoušeli, pamatujte si to Ansible není bash! Přečtěte si pozorně dokumentaci, prostudujte si, co o ní píší.
Infrastruktura jako kód je oddělení kódu infrastruktury do samostatných vrstev.
U nás ve firmě rozlišujeme 3 základní vrstvy, které jsou velmi přehledné a jednoduché, ale může jich být více. Můžete se podívat na váš kód infrastruktury a zjistit, zda máte tento stav nebo ne. Pokud nejsou zvýrazněny žádné vrstvy, musíte chvíli trvat a trochu refaktorovat.
základní vrstva - takto se konfiguruje OS, zálohy a další nízkoúrovňové věci, například jak se na základní úrovni nasazuje Kubernetes.
Úroveň služby - jedná se o služby, které poskytujete vývojáři: logování jako služba, monitorování jako služba, databáze jako služba, balancer jako služba, fronta jako služba, Continuous Delivery jako služba - hromada služeb, které jednotlivé týmy může poskytnout rozvoji. To vše musí být popsáno v samostatných modulech ve vašem systému správy konfigurace.
Vrstva, kde se vytvářejí aplikace a popisuje, jak se rozvinou na horní straně předchozích dvou vrstev.
Kontrolní otázky
Má vaše společnost společné úložiště infrastruktury? Spravujete technický dluh ve své infrastruktuře? Používáte vývojové postupy v úložišti infrastruktury? Je vaše infrastruktura rozdělena do vrstev? Můžete zkontrolovat diagram Base-service-APP. Jak těžké je udělat změnu?
Pokud máte zkušenost, že provedení změn trvalo den a půl, znamená to, že máte technický dluh a potřebujete s ním pracovat. Právě jste narazili na technický dluh ve vašem kódu infrastruktury. Pamatuji si mnoho takových příběhů, kdy pro změnu nějakého CCTL bylo potřeba přepsat polovinu kódu infrastruktury, protože kreativita a touha vše automatizovat vedly k tomu, že je všude všechno zkorodované, všechny kliky byly odstraněny a je nutné refaktorovat.
Nepřetržité doručování
Srovnejme debet s kreditem. Nejprve přichází na řadu popis infrastruktury, který může být zcela základní. Nemusíte vše popisovat do detailu, ale je potřeba nějaký základní popis, abyste s ním mohli pracovat. Jinak není jasné, co dál s nepřetržitým doručováním. Všechny tyto postupy se rozvinou současně, když přijdete do DevOps, ale začíná to pochopením toho, co máte a jak to spravovat. To je přesně praxe infrastruktury jako kódu.
Jakmile bude jasné, že ho máte a jak ho spravovat, začnete vymýšlet, jak co nejrychleji poslat vývojářský kód do výroby. Myslím spolu s vývojářem - pamatujeme si na problém „studen“, to znamená, že s tím nepřicházejí jednotlivci, ale tým.
Když jsme s Váňa Jevtuchovičová viděl první knihu Jez Humble a skupiny autorů "Nepřetržité doručování", který vyšel v roce 2009, jsme dlouho přemýšleli, jak jeho název přeložit do ruštiny. Chtěli to přeložit jako „Neustále doručovat“, ale bohužel to bylo přeloženo jako „Nepřetržité doručování“. Zdá se mi, že v našem názvu je něco ruského, s tlakem.
Neustále dodávající prostředky
Kód, který je v úložišti produktu, lze vždy stáhnout do produkce. Nemusí být vyfouknutý, ale je na to vždy připraven. V souladu s tím vždy píšete kód s těžko vysvětlitelným pocitem určité úzkosti pod kostrou. Často se objeví, když zavedete kód infrastruktury. Tento pocit určité úzkosti by měl být přítomen – spouští mozkové procesy, které umožňují psát kód trochu jinak. To by mělo být zaznamenáno v pravidlech v rámci vývoje.
Chcete-li konzistentně dodávat, potřebujete formát artefaktu, který běží napříč platformou infrastruktury. Pokud přes infrastrukturní platformu hodíte „životní odpad“ různých formátů, stane se unifikovaná, obtížně se udržuje a vzniká problém technického dluhu. Formát artefaktu je třeba sladit – to je také společný úkol: všichni se musíme sejít, zašustit mozky a vymyslet tento formát.
Artefakt je neustále vylepšován a mění se tak, aby vyhovoval produkčnímu prostředí, jak se pohybuje doručovacím potrubím. Když se artefakt pohybuje po potrubí, neustále naráží na nějaké pro něj nepohodlné věci, které jsou podobné tomu, na co naráží artefakt, který dáte do výroby. Pokud to v klasickém vývoji dělá správce systému, který dělá rollout, tak v procesu DevOps se to děje pořád: tady to testovali nějakými testy, tady to hodili do clusteru Kubernetes, který je víceméně podobný do výroby, pak najednou začali zátěžové testování .
Trochu to připomíná hru Pac-Man – artefakt prochází jakýmsi příběhem. Zároveň je důležité kontrolovat, zda kód skutečně prochází příběhem a zda nějak souvisí s vaší produkcí. Příběhy z výroby lze přetáhnout do procesu nepřetržitého doručování: bylo to takhle, když něco spadlo, nyní jen naprogramujte tento scénář v systému. Pokaždé, když kód projde i tímto scénářem, a příště už se s tímto problémem nesetkáte. Dozvíte se o něm mnohem dříve, než se dostane ke klientovi.
Různé strategie nasazení. Například používáte testování AB nebo nasazení canary k testování kódu na různých klientech odlišně, získáváte informace o tom, jak kód funguje, a to mnohem dříve, než když je zaveden pro 100 milionů uživatelů.
„Důsledně dodávat“ vypadá takto.
Proces doručení Dev, CI, Test, PreProd, Prod není samostatné prostředí, jedná se o stupně nebo stanice s ohnivzdornými součty, kterými prochází váš artefakt.
Pokud máte kód infrastruktury, který je popsán jako Base Service APP, pak to pomůže nezapomeňte na všechny skriptya zapište je jako kód pro tento artefakt, propagovat artefakt a měnit to za pochodu.
Samotestovací otázky
Doba od popisu funkce po vydání do výroby je v 95 % případů méně než týden? Zlepšuje se kvalita artefaktu v každé fázi potrubí? Existuje nějaký příběh, kterým to prochází? Používáte různé strategie nasazení?
Pokud jsou všechny odpovědi ano, pak jste neuvěřitelně cool! Své odpovědi pište do komentářů - budu rád).
Kontaktujte nás
Toto je nejtěžší cvičení ze všech. Na konferenci DevOpsConf byl kolega z Infobipu, který o tom hovořil, ve svých slovech trochu zmatený, protože to je opravdu velmi komplexní praxe o tom, že je potřeba vše sledovat!
Například kdysi dávno, když jsem pracoval v Qiku a uvědomili jsme si, že musíme všechno sledovat. Udělali jsme to a nyní máme v Zabbixu 150 000 položek, které jsou neustále monitorovány. Bylo to děsivé, technický ředitel si zkroutil prst na spánku:
- Kluci, proč znásilňujete server něčím nejasným?
Pak ale došlo k incidentu, který ukázal, že je to opravdu velmi cool strategie.
Jedna ze služeb začala neustále padat. Zpočátku nepadal, což je zajímavé, kód se tam nepřidával, protože se jednalo o základního brokera, který neměl prakticky žádnou obchodní funkcionalitu - prostě posílal zprávy mezi jednotlivými službami. Služba se 4 měsíce nezměnila a najednou začala padat s chybou „Segmentation fault“.
Byli jsme v šoku, otevřeli jsme si grafy v Zabbixu a ukázalo se, že před týdnem a půl se velmi změnilo chování požadavků ve službě API, kterou tento broker používá. Dále jsme viděli, že se změnila frekvence odesílání určitého typu zpráv. Později jsme zjistili, že se jedná o android klienty. Ptali jsme se:
— Kluci, co se vám stalo před týdnem a půl?
V reakci na to jsme slyšeli zajímavý příběh o tom, jak přepracovali uživatelské rozhraní. Je nepravděpodobné, že by někdo okamžitě řekl, že změnil knihovnu HTTP. Pro klienty Android je to jako výměna mýdla v koupelně – prostě si to nepamatují. V důsledku toho jsme po 40 minutách rozhovoru zjistili, že změnili knihovnu HTTP a změnilo se její výchozí časování. To vedlo ke změně chování provozu na serveru API, což vedlo k situaci, která způsobila závod uvnitř brokera a ten začal padat.
Bez hlubokého monitorování je obecně nemožné toto otevřít. Pokud má organizace stále problém se „studnami“, kdy na sebe všichni hází peníze, může to přežít roky. Jednoduše restartujete server, protože problém nelze vyřešit. Když monitorujete, sledujete, sledujete všechny události, které máte, a používáte monitorování jako testování - napište kód a okamžitě naznačte, jak jej monitorovat, také ve formě kódu (už máme infrastrukturu jako kód), vše bude jasné, jak na dlani. I takto složité problémy lze snadno sledovat.
Shromážděte všechny informace o tom, co se stane s artefaktem v každé fázi procesu dodání – ne ve výrobě.
Nahrajte monitoring do CI a některé základní věci tam již budou vidět. Později je uvidíte v Testu, PredProd a zátěžovém testování. Sbírejte informace ve všech fázích, nejen metriky, statistiky, ale také protokoly: jak se aplikace spustila, anomálie – sbírejte vše.
Jinak bude těžké na to přijít. Už jsem řekl, že DevOps je složitější. Abyste se s touto složitostí vyrovnali, musíte mít normální analytiku.
Otázky pro sebeovládání
Je pro vás vaše sledování a protokolování vývojovým nástrojem? Přemýšlejí vaši vývojáři včetně vás při psaní kódu o tom, jak jej sledovat?
Slyšíte o problémech od zákazníků? Rozumíte klientovi lépe z monitorování a logování? Rozumíte systému lépe z monitorování a logování? Měníte systém jednoduše proto, že jste viděli, že trend v systému roste a chápete, že za další 3 týdny všechno umře?
Jakmile budete mít tyto tři komponenty, můžete přemýšlet o tom, jakou platformu infrastruktury ve vaší společnosti máte.
Infrastrukturní platforma
Nejde o to, že by šlo o soubor nesourodých nástrojů, které má každá společnost.
Smyslem platformy infrastruktury je, že všechny týmy používají tyto nástroje a vyvíjejí je společně.
Je zřejmé, že existují samostatné týmy, které jsou zodpovědné za vývoj jednotlivých částí platformy infrastruktury. Ale zároveň každý inženýr nese odpovědnost za vývoj, výkon a propagaci platformy infrastruktury. Na vnitřní úrovni se stává běžným nástrojem.
Všechny týmy vyvíjejí platformu infrastruktury a zacházejí s ní opatrně jako se svým vlastním IDE. Do vašeho IDE instalujete různé pluginy, aby bylo vše hezké a rychlé, a konfigurujete klávesové zkratky. Když otevřete Sublime, Atom nebo Visual Studio Code, hrnou se na vás chyby v kódu a vy si uvědomíte, že to vůbec nejde, okamžitě je vám smutno a běžíte opravit své IDE.
Zacházejte s vaší infrastrukturní platformou stejným způsobem. Pokud chápete, že s tím není něco v pořádku, zanechte žádost, pokud to nemůžete opravit sami. Pokud je něco jednoduchého, upravte si to sami, pošlete žádost o stažení, kluci to zváží a doplní. Jde o trochu jiný přístup k inženýrským nástrojům v hlavě vývojáře.
Infrastrukturní platforma zajišťuje přenos artefaktu z vývoje ke klientovi s neustálým zlepšováním kvality. IP je naprogramováno pomocí sady příběhů, které se dějí s kódem ve výrobě. Za léta vývoje je těchto příběhů spousta, některé jsou jedinečné a týkají se pouze vás – nelze je vygooglit.
V tomto okamžiku se platforma infrastruktury stává vaší konkurenční výhodou, protože má v sobě zabudované něco, co není v nástroji konkurence. Čím hlubší je vaše IP, tím větší je vaše konkurenční výhoda z hlediska doby uvedení na trh. Objeví se zde problém se zámkem dodavatele: Můžete si vzít platformu někoho jiného, ale s využitím zkušeností někoho jiného nepochopíte, jak je pro vás relevantní. Ano, ne každá společnost dokáže vybudovat platformu jako Amazon. Toto je obtížná linie, kde jsou zkušenosti společnosti relevantní pro její pozici na trhu a nemůžete tam použít zámek dodavatele. Na to je také důležité myslet.
systém
Toto je základní schéma platformy infrastruktury, které vám pomůže nastavit všechny postupy a procesy ve společnosti DevOps.
Podívejme se, z čeho se skládá.
Systém orchestrace zdrojů, která poskytuje CPU, paměť, disk aplikacím a dalším službám. Na vrcholu tohohle - služby nízké úrovně: monitorování, protokolování, CI/CD Engine, úložiště artefaktů, infrastruktura jako systémový kód.
Služby vyšší úrovně: databáze jako služba, fronty jako služba, Load Balance jako služba, změna velikosti obrázku jako služba, Big Data factory jako služba. Na vrcholu tohohle - kanál, který vašemu klientovi dodává neustále upravovaný kód.
Získáváte informace o tom, jak váš software funguje pro klienta, měníte jej, dodáváte tento kód znovu, dostáváte informace – a tak neustále vyvíjíte jak platformu infrastruktury, tak svůj software.
V diagramu se zásobovací potrubí skládá z mnoha fází. Ale toto je schematický diagram, který je uveden jako příklad - není třeba jej opakovat jeden po druhém. Stupně interagují se službami, jako by to byly služby – každá cihla platformy nese svůj vlastní příběh: jak jsou zdroje alokovány, jak se aplikace spouští, jak pracuje se zdroji, je monitorována a mění se.
Je důležité pochopit, že každá část platformy nese příběh, a zeptejte se sami sebe, jaký příběh tato cihla nese, možná by měla být vyhozena a nahrazena službou třetí strany. Je například možné nainstalovat Okmeter místo cihly? Možná už kluci rozvinuli tuto odbornost mnohem více než my. Ale možná ne – možná máme jedinečné odborné znalosti, musíme nainstalovat Prometheus a dále jej rozvíjet.
Vytvoření platformy
Jedná se o složitý komunikační proces. Když máte základní postupy, zahájíte komunikaci mezi různými inženýry a specialisty, kteří vyvíjejí požadavky a normy, a neustále je mění na různé nástroje a přístupy. Kultura, kterou v DevOps máme, je zde důležitá.
S kulturou je všechno velmi jednoduché - je to o spolupráci a komunikaci, tedy touha pracovat na společném poli mezi sebou, touha společně vládnout jedním nástrojem. Není zde žádná raketová věda - vše je velmi jednoduché, banální. Například všichni bydlíme ve vchodu a udržujeme ho v čistotě - taková úroveň kultury.
Co máš?
Opět otázky, které si můžete položit.
Je platforma infrastruktury vyhrazená? Kdo je zodpovědný za jeho vývoj? Rozumíte konkurenčním výhodám vaší infrastruktury?
Tyto otázky si musíte neustále klást. Pokud lze něco převést na služby třetích stran, mělo by se to převést, pokud vám pohyb začne blokovat služba třetí strany, musíte si v sobě vybudovat systém.
Takže DevOps...
... je to složitý systém, musí mít:
- Digitální produkt.
- Obchodní moduly, které vyvíjejí tento digitální produkt.
- Produktové týmy, které píší kód.
- Postupy průběžného doručování.
- Platformy jako služba.
- Infrastruktura jako služba.
- Infrastruktura jako kód.
- Samostatné postupy pro zachování spolehlivosti zabudované do DevOps.
- Zpětná vazba, která to všechno popisuje.
Tento diagram můžete použít a zvýraznit v něm to, co již ve vaší společnosti v nějaké formě máte: vyvinulo se to nebo je ještě potřeba vyvinout.
Za pár týdnů to skončí . jako součást RIT++. Přijďte na konferenci, kde najdete spoustu skvělých zpráv o průběžném doručování, infrastruktuře jako kódu a transformaci DevOps. , poslední uzávěrka cen je 20. května
Zdroj: www.habr.com