praktická cesta k vyspělosti DevOps

jakákoli agilní metodika je bez skutečných postupů DevOps marná. Buzzword byl zneužit v mnoha organizacích. Pokud říkáte, že jste vyzráli agilní týmy a máte DevOps engineer nebo DevOps team, kteří pravděpodobně nejdou správným směrem. DevOps je spíše kultura než název nebo označení týmu. Vezmeme-li tágo z CMM (Capability Maturity Model) tento pokus má pomoci organizaci vědět, kde stojí na cestě DevOps a cestě vpřed. S nějakým brainstormingem mezi vývojovými a Ops týmy to lze rozšířit a přizpůsobit potřebám organizace.

žádné číslo není špatné, protože pomáhá jednotlivci nebo organizaci růst.

Spokojený Zákazník

na Rozdíl od CMM, to není model, který musíte dokázat, aby certifikační organizace. Jediný certifikát, který získáte, je od vašich spokojených zákazníků nebo obchodních partnerů. Je to model, který se odráží a pomáhá podnikání růst. Samotným účelem každého IT týmu je vytvářet hodnotu tím, že dělá udržitelné, předvídatelné dodávky s kvalitou.

Jedná se o jednoduchý model, který od vývojáře po CxO může pochopit a souviset.

než budu diskutovat o modelu. Musíme pochopit potřebu tohoto modelu. Před mnoha lety Melvin Conway ve svém článku “ Jak vymýšlejí výbory?“přišel s tezí, která se proslavila jako Conwayův zákon.

každá organizace, která navrhuje systém (definovaný široce), vytvoří návrh, jehož struktura je kopií komunikační struktury organizace.

zákon je založen na úvaze, že aby softwarové moduly fungovaly, musí mezi sebou často komunikovat více lidí. Struktura softwarového rozhraní systému proto bude odrážet sociální hranice organizace(organizací), které ji vytvořily, přes které je komunikace obtížnější.

umožňuje podívat se na to, jak to funguje ve vývoji softwaru s reálným scénářem. Radha buduje čelní obrazovku, která zobrazuje podrobné atributy produktu. Řekněme, že tento produkt je mobilní telefon. Několik běžných podrobností o produktu je barva, cena, rozměry, hodnocení atd. Nová regulace přišla k zobrazení hodnoty SAR telefonu. Obrazovka, kterou navrhla, pracuje s micro service call. Mluvila se Sunilem, který pracuje v datovém týmu. Řekl, že mohou posílat data pouze v plochém souboru. Mezi dvěma moduly je jasné odpojení. Toto je scénář, se kterým se každý IT tým setká, ne-li všechny 100% časy, ale většinou. To je jen otázka designu. Problém je širší. Co když priority druhého týmu jsou velmi odlišné od toho, co váš tým dělá? Vaše požadavky mohou být pro ně NEJNIŽŠÍ prioritou, zatímco vaše zúčastněné strany běží za Vámi.

prvním krokem k úspěšné implementaci DevOps je otevření se změnami organizace.

Organizace změny

Dovolte mi, abych diskutovat o 5 úrovní vyspělosti:

  1. Původní: V této fázi se týmy práce v silech a tam je pouze, třeba na bázi spolupráce. Při setkání se všemi týmy dohromady, pokud se zeptáte, kdo vlastní „produkt“, nebudete mít žádné ruce. Doba uvedení na trh je obvykle delší, jde o měsíce a někdy i roky. Priority jsou stanoveny na úrovni týmu, ale ne na úrovni produktu. To povede k tomu, že každý tým bude mít své vlastní priority. Protože neexistuje žádný definovaný proces, každý pokus je jako znovuobjevení kola. To povede k problémům s kvalitou a delším časovým osám. Tým většinou provádí ruční nasazení a Ruční zásahy. Dobře.. to není špatný stav. Takto by začala většina vývoje.

2. Opakovatelné: týmy stále pracují v silech. V týmu je určitá úroveň automatizace. Když krize zasáhne, tým definuje svůj vlastní proces a následuje, dokud krize neskončí. Jen dobrá zpráva je, že některé z nich se mohou stát opakovatelnými procesy, až krize znovu zasáhne.

3. Definováno: to je dobrý výchozí bod pro osivo DevOps kultury s centralizovaným týmem. Tento tým chápe různé technologie, které týmy Dev používají, a nástroje jsou založeny na aktuální potřebě. Být centralizovaným týmem, není snadné sledovat, co každý tým dělá, a proto některá rozhodnutí jsou ponechána na týmech, aby experimentovaly. Centrální tým se obvykle skládá z odborníků a Dev týmy budou mít některé lidi se základním porozuměním a znalostmi.

4. Managed: vzhledem k tomu, že tým central DevOps rozumí prostředí nástrojů pro organizaci, testuje se více prostředí a nástrojů. Po konzistentních a opakovatelných procesech následuje více týmů. Řetězec nástrojů je vybrán na základě případů použití, spíše než osobní volby. Monitorovací nástroje pro všechny procesy jsou zavedeny a silně využívány týmy k rozhodování.

5. Optimalizovat:

úspěch dobrého vůdce je definován tím, že nemá následovníky, ale schopností vytvářet velké vůdce.

konečná fáze zralosti DevOps je, aby tým DevOps zmizel. To by mohlo vypadat jako pult intuitivní. V této fázi je DevOps spíše součástí týmu pro vývoj produktů než samostatnou entitou. Použití infrastruktury jako kódu, kontejnerů, orchestrace atd. je dosaženo nulového nasazení dotyku. Nyní, pokud zavoláte každému, kdo pracuje na produktu, a zeptáte se, kdo je vlastníkem produktu, budete mít sebevědomé ruce bez váhání. Data z monitorovacích nástrojů slouží k výběru nové sady nástrojů (včetně infrastruktury, programovacích jazyků, technik). Rozhodnutí jsou založena spíše na datech než na osobních preferencích. Produktový tým je připraven nasadit kód každý den a kdykoliv. Milují „obchodní hodnotu“ a považují ji za domácího mazlíčka. Všechno ostatní je považováno za dobytek.

DevOps Model Zralosti.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.