Třetí konference se konala 7. prosince , kterou organizuje moskevská komunita DevOps s podporou Cloud Solutions Mail.ru. Kromě prezentací předních praktiků DevOps se účastníci mohli zúčastnit krátkých motivačních Lightning Talks, workshopů a komunikovat v otevřených prostorách.
Shromáždili jsme důležité poznatky ze šesti projevů a provedli rozhovory s několika řečníky, abychom zjistili, co po zprávách zůstalo.
Uvnitř:
- Baruch Sadogursky, JFrog: „Nechte software proudit od dodavatele k uživateli jako kapalina“
- Pavel Selivanov, Southbridge: „Dev a Ops mají jeden společný úkol – vytvořit produkt, který funguje“
- Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise je vývoj bez bolesti a požárů“
- Sergey Puzyrev, Facebook: „Výrobní inženýr se stará o službu jako celek: aby se uživatelé i vývojáři dobře bavili“
- Michail Chinkov, AMBOSS: „Jedno oddělení nemůže jít cestou DevOps, musí ji následovat celá společnost“
- Nadšenci DevOps z Rosbank: „1000 dní na implementaci DevOps v krvavém podniku“
1. Baruch Sadogursky, JFrog: „Nechte software proudit od dodavatele k uživateli jako kapalina“
K selhání aktualizace softwaru dochází každou hodinu a pro každého. Zde je jen jeden hororový příběh z projevu: Knight Capital ztratil 440 milionů dolarů za hodinu po neúspěšné aktualizaci.
Baruch hovořil o vzorcích DevOps neustálých aktualizací, které pomohou vyhnout se selháním a nenávisti uživatelů:
Místní vrácení zpět — ponechte si předchozí verzi softwaru v zařízení, abyste ji mohli vrátit zpět, pokud se něco stane. To vás ochrání, pokud se věci zhorší tak, že nemůžete poslat náplast vzduchem.
Aktualizace vzduchem - lépe průběžné. Jinak to bude jako s vývojáři Jaguaru: kvůli chybě v brzdovém systému, který nešel aktualizovat vzduchem, musely být vozy staženy z prodeje. Bylo to bolestivé a drahé.
Průběžné aktualizace — průběžně aktualizujte software, jakmile bude připravena nová funkce. U vzácných aktualizací jsou funkce seskupeny; kritická aktualizace může čekat na nekritické. Podobně jako v Tesle čekala na aktualizaci šachové partie aktualizace, která měla opravit náhodné brzdění.
Automatizované nasazení - nahradit lidi stroji, protože lidé jsou špatní v provádění běžných činností.
Астые обновления - pomůže vám vytvořit si návyk a zbavit se strachu. Vzácné aktualizace se promění v nouzové události.
Znalost stavu zařízení — testovací aktualizace, nikoli instalace od začátku. To je důležité, protože aktualizace se mohou chovat odlišně v závislosti na stavu zařízení.
Kanárské výpustky — zavést aktualizace pro malý počet uživatelů a pozorovat. To snižuje poškození, pokud se něco pokazí.
Aktualizace bez nedostupnosti — Umožněte zákazníkům, aby si všimli pouze nových funkcí, a nezůstali bez služby po dobu několika týdnů, než zavedete aktualizaci.
S Baruchem Sadogurským jsme hovořili o tom, jak se liší pohled na DevOps v ruském a západním IT, zda Cloud brzy udělá vše za nás a zda všechny softwarové služby sklouznou do schématu aaS - podívejte se na rozhovor:
2. Pavel Selivanov, Southbridge: „Dev a Ops mají jeden společný úkol – vytvořit produkt, který funguje“
Implementace Kubernetes nepomůže dosáhnout DevOps a naopak může vše rozbít. Pavel vysvětlil, proč technologie (ani ta nejlepší) nemůže vyřešit všechny vaše problémy:
Složitost projektu se posunula nad rámec kódu. Dříve existovala složitá aplikace: interakce v rámci projektu a komplexní vývoj, ale jednoduchá struktura – nasadil ji správce, vše funguje. Přešli jsme na mikroslužby: každá služba je jednoduchá aplikace, komunikace pomocí standardních protokolů a rychlý vývoj, ale struktura projektu se stala složitější. Složitost projektu s architekturou mikroslužeb nezmizela – posunula se za hranice kódu. Nyní je za to zodpovědný inženýr DevOps.
Vývojáři po implementaci DevOps nechtějí změny. Výsledkem je, že pracovní tok s Kubernetes nadále vypadá jako házení úkolů z Dev do Ops přes zeď, pouze ne metaforické - Git se takovou zdí stává. Vývojář tam dá kód a funguje jako předtím a správci mají Kubernetes, CI/CD a vše ostatní.
Vývojáři však musí změny přijmout. Situace, kdy vývojáři nevědí, co správci dělají, a správci nevědí, co se s vývojáři děje, vytváří problémy.
Pokud se pro vývojáře nic nezměnilo, neuvědomují si, že provoz aplikace je jejich odpovědností – různé technické triky nebudou fungovat.
S příchodem DevOps a Kubernetes se toho ve vývoji hodně změní. Vývojáři musí být kompetentní v Ops a naopak. Tito specialisté mají své specifické dovednosti, ale musí si být navzájem vědomi své práce. Před implementací Kubernetes musí být Dev a Ops přátelé, jinak rozbijete to, co máte.
Pavel Selivanov mluvil o tom, co bude s Kubernetes za 5 let a na čem by měl moderní startup stavět technologický stack - podívejte se na rozhovor:
3. Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise je vývoj bez bolesti a požárů“
Společnosti přicházejí do transformace DevOps, když si uvědomí, že vývoj je příliš pomalý a neodpovídá realitě, chtějí se vyvíjet lépe a rychleji.
Vladimír vysvětlil, jak se to děje a v čem je háček:
- Nejprve si společnosti najmou inženýra DevOps. Jedná se o Senior System Administrator, podílí se na nasazování vydání do produkce, standardizaci vývojového prostředí, nastavování infrastruktury, zjišťování a opravování různých problémů, automatizaci procesů a dalších technických úkolů.
- Pak už jeden DevOps inženýr nestačí a společnost si najme tým DevOps. Jedná se o kompetenční centrum, které organizuje úsilí různorodých inženýrů a umožňuje jim soustředit se jedním směrem.
- Ve skutečnosti jsou inženýr DevOps a týmy DevOps proti vzorům transformace DevOps. Jelikož je DevOps o praktikách a kultuře, navíc existují implementace DevOps v technologických společnostech (SRE, Production Engineering).
Co dělat? Najměte si dočasný tým DevOps, který vám pomůže implementovat transformaci DevOps, provádět postupy, pěstovat kulturu vývoje a technologickou kulturu.
Když do hry vstoupí firma a investuje do DevOps, je možných několik scénářů: vše se rozpadne při startu; zůstane jako SRE/Production Engineering nebo Embedded Ops; přejde na BizOps, kdy jsou procesy založeny na obchodních metrikách.
Vladimir Utratenko nám řekl, jak „krvavé“ DevOps v podniku skutečně je a jak se praktiky zavádějí ve velkých maloobchodech – podívejte se na rozhovor:
4. Sergey Puzyrev, Facebook: „Výrobní inženýr se stará o službu jako celek: aby se uživatelé i vývojáři dobře bavili“
Facebook je obrovská společnost s velkým množstvím komponent, serverů, lidí a datových center. I přes svou obrovskou velikost je velmi rychlý – vývojáři mohou nasazovat služby mnohokrát za den. Facebook také rychle roste a neroste jen počet uživatelů a serverů, roste i počet vývojářů, což dělá procesy složitější.
Sergej řekl, co dělá výrobní inženýr na Facebooku:
- Výrobní inženýr hodně kóduje, musí mít systémové znalosti: operační systémy, souborové systémy, databáze, sítě a podobně. Musí mít zkušenosti s prací s distribuovanými systémy a Reliability Engineering, tedy podporou spolehlivosti produktu. Musí být na zavolání, to znamená, že je kdykoli k dispozici pro volání.
- Výrobní inženýr se liší od softwarového inženýra v tom, že má pokročilé dovednosti v provozu, ale ve skutečnosti je poddruhem softwarového inženýra. Softwaroví inženýři více kódují, mohou mít další dovednosti související například se zpracováním dat. Na Facebooku musí být takoví specialisté také v pohotovosti, což je pro mnohé nepříjemné překvapení.
- Pyramida potřeb výrobního inženýra ve firmě začíná sledováním serverů a jejich životního cyklu, tedy pořízením nového hardwaru, jeho nastavením, zprovozněním. Další úroveň je stejná na úrovni služeb: monitorování služeb a jejich životního cyklu. Pak přichází bezproblémové škálování a pokročilé monitorování. Po automatizaci životního cyklu přejdou na automatické škálování. A nakonec je potřeba udělat tuning, aby škálování bylo efektivní a firma ušetřila peníze a prostředky.
5. Michail Chinkov, AMBOSS: „Jedno oddělení nemůže jít cestou DevOps, musí ji následovat celá společnost“
Michail věří, že DevOps je neustálý vývoj. Nemůžete představit některé nástroje a zastavit se tam. Jaké problémy brání společnostem stát se DevOps a jak zavádět postupy?
Rozdíl v porozumění DevOps. Kanonické devops, jak to vidí evangelisté, spočívá na 5 pilířích:
- kultura – zaměření na lidi a spolupráci;
- automatizace - delegování rutiny na workflow;
- lean – důraz na poskytování hodnoty uživateli;
- sdílení – neustálá výměna znalostí;
- metriky a získávání zpětné vazby pomocí nich.
Společnosti se obvykle zaměřují pouze na automatizaci a poskytování hodnoty uživateli. Ale kultura, sdílení znalostí a metriky DevOps pro sledování vývoje ustupují do pozadí.
Výzvy standardizace DevOps. Produktové cíle se u všech společností liší a nelze je standardizovat. Stav DevOps ve společnosti závisí na společnosti samotné, ale mnozí to nechápou a věří, že stačí najmout DevOps inženýra.
Proč ještě nejsme DevOps? Existují dva klíčové problémy. V Enterprise je pomalý rozvoj organizace, potíže se změnou vektoru v myslích tisíců zaměstnanců. Ve startupech je nedostatek zdrojů znalostí a problém s alokací zdrojů na transformaci.
Fáze vývoje DevOps ve společnosti:
- první je infrastruktura v cloudu, ale nikdo kromě jednoho nebo dvou adminů neví, jak to funguje;
- za druhé, infrastruktura je transparentní a srozumitelná všem inženýrům, ale procesy nejsou racionalizované;
- za třetí - inženýři nezávisle spouštějí a opravují živé služby;
- začtvrté – inženýři volitelně přispějí k základní infrastruktuře, transparentní kód v cloudu, nasazení tlačítkem.
Ideální schéma je, že každý má stejný přístup k infrastruktuře, všichni inženýři mají přístup k produktu a rozumí tomu, co dělají.
Po uzavření všech kulturních a technických gestaltů bude transformace společnosti DevOps brát v úvahu zpětnou vazbu z obchodních a platforem.
6. Nadšenci DevOps z Rosbank: „1000 dní na implementaci DevOps v krvavém podniku“
Yuri Bulich, Dina Maltseva, Evgeny Pankov z Rosbank řekli, jak přišli do DevOps za tři roky. Cíle byly dva: řešit konkrétní problémy v konkrétních týmech a implementovat centralizované nástroje.
Zde jsou dosažené výsledky:
Výsledky pro produktové týmy: 30krát rychlejší montáž, 6krát rychlejší instalace, až 30% úspora v celém cyklu. Nyní máme možnost stisknutím tlačítka přejít k produktivitě
Výsledky pro příkazy platformy: 10x rychlejší montáž a instalace, 87% zvýšený počet instalací, 46% pokrytí autotestem. Integrační tým již není úzkým hrdlem
Jak tedy implementovat postupy DevOps v krvavém podniku?
Nejprve implementujte pilotní projekt: Vyberte týmy, rozhodněte se, jak implementovat architekturu, a vyberte nástroje. Vybrali jsme nástroje s otevřenou licencí, s instalací v bance a odborností v práci s nimi. Rosbank současně nasadila privátní cloud spolu s platformou DevOps, což pomohlo na začátku. V cloudu bylo možné získat potřebné zdroje stisknutím tlačítka za 15 minut, dříve takový proces mohl trvat týden.
V bankách a dalších podnicích je nutné omezení předem vypracovat s týmem informační bezpečnosti a najít řešení, které umožní změny implementovat.
Po pilotu je potřeba úspěšné řešení rozšířit.
- Je důležité co nejvíce „narovnat“ potrubí, eliminovat z něj zbytečné odkazy, zvýraznit poskytovatele hodnot a odstranit zbývající komponenty. Meziprodukty jsou antivzory. Například v Rosbank řada týmů nevyvíjela interní vývoj a zůstal pouze externí vývoj. To vedlo ke vzniku dedikovaného týmu DevOps, který zajistil přenos kódu od externích k interním vývojářům. Problém se vyřešil integrací externího vývoje do CI/CD tak, aby nepřenášeli kód jen ze sebe do banky, ale také byli zodpovědní za jeho úspěch.
- Model vyspělosti zahrnoval prvky postupů DevOps, uvedené nástroje a zohledňoval rysy spolupráce s externími dodavateli – v budoucnu to pomohlo rychle snížit nahromadění úkolů při jejich implementaci v nových týmech.
- Potřebujeme vládu ve formě měkké kontroly a doporučení. Příručka DevOps, která dobře funguje, je sada organizačních a nástrojových charakteristik, které pomáhají týmům správně používat platformu.
- Měli byste okamžitě věnovat pozornost kultuře, pak se mnoho změn stane rychleji a snadněji. Rozvíjejte svou interní komunitu, pořádejte setkání, technické workshopy, školení a zábavné aktivity. To přináší ovoce: lidé sdílejí postupy, vidí, kdo co udělal, vědí, kam se obrátit, uvnitř společnosti panuje humbuk a zdravá konkurence.
- Nemá smysl pracovat s těmi, kteří nejsou zapojeni do procesu, s týmy, které nevyzrály, je lepší investovat do zainteresovaných týmů a loajálních lidí.
- Zvolené řešení musí být vhodné pro ty inženýry, kteří jej používají.
- Externí rozvoj není překážkou, dají se tam zavádět i praktiky, hlavní je, že chuť má tým sám.
Trochu větší užitek
Seznam knih, které stojí za přečtení pro ty v DevOps, od Alexandra Chistyakova, vdsina.ru:
- Irina Yakutenko "Vůle a sebeovládání."
- Daniel Kahneman „Myšlení, rychlé a pomalé“.
- Barbara Oakley „Mysl na čísla“.
- Maxim Dorofeev „Jediské techniky“.
- Viktor Frankl „Mužské hledání smyslu“.
Zůstaňte naladěni
Také milujeme DevOps. Sledujte oznámení seriálu a @Kubernetes, stejně jako další události Cloud Solutions Mail.ru, na našem kanálu Telegram:
Zdroj: www.habr.com