gyakorlati út a DevOps érettségéhez

bármilyen agilis módszertan hiábavaló valódi DevOps gyakorlatok nélkül. A buzzwordot sok szervezetben visszaélték. Ha azt mondod, hogy érett agilis csapataid vannak, és van egy DevOps mérnök vagy DevOps csapatod, akik valószínűleg nem a helyes irányba haladnak. A DevOps inkább kultúra, mint csapatnév vagy megnevezés. A CMM-től (Capability Maturity Model) ez a kísérlet arra szolgál, hogy segítse a szervezetet abban, hogy tudja, hol áll a DevOps utazásában és az előre vezető úton. A fejlesztés és az Ops csapatok közötti némi ötleteléssel ez kibővíthető és testre szabható a szervezet igényeihez.

egyetlen szám sem rossz, mivel segíti az egyén vagy szervezet növekedését.

boldog ügyfél

a CMM-től eltérően ez nem olyan modell, amelyet be kell bizonyítania bármely tanúsító szervezetnek. Az egyetlen tanúsítvány, amelyet boldog ügyfeleitől vagy üzleti partnereitől kap. Ez egy modell az önreflexióra és az üzleti növekedés elősegítésére. Minden informatikai csapat célja, hogy értéket teremtsen fenntartható, kiszámítható, minőségi teljesítéssel.

ez egy egyszerű modell, amely a fejlesztőtől a CxO-ig képes megérteni és összekapcsolni.

mielőtt a modellről beszélnék. Meg kell értenünk, hogy szükség van erre a modellre. Sok évvel ezelőtt, Melvin Conway az ő papír “hogyan bizottságok kitalálni?”jött a dolgozat, amely híressé vált, mint Conway törvénye.

bármely szervezet, amely egy rendszert tervez (tágan definiálva), olyan tervet készít, amelynek szerkezete a szervezet kommunikációs struktúrájának másolata.

a törvény azon az érvelésen alapul, hogy a szoftvermodulok működéséhez több embernek gyakran kell kommunikálnia egymással. Ezért a rendszer szoftveres interfészszerkezete tükrözi az azt előállító szervezet(ek) társadalmi határait, amelyeken keresztül a kommunikáció nehezebb.

nézzük meg, hogyan működik ez a szoftverfejlesztés egy valós forgatókönyv. Radha egy elülső képernyőt épít, amely a termék részletes tulajdonságait mutatja. Tegyük fel, hogy ez a termék mobiltelefon. Kevés közös termék részletek szín, ár, méretek, értékelés stb. Új rendelet jött a kézibeszélő SAR értékének megjelenítésére. Az általa tervezett képernyő a micro service call szolgáltatással működik. Beszélt Sunillal, aki az adatcsapatban dolgozik. Azt mondta, hogy csak lapos fájlban tudnak adatokat küldeni. Két modul között egyértelmű leválasztás van. Ez egy olyan forgatókönyv, amellyel minden informatikai csapat találkozik, ha nem az összes 100% – os alkalommal, de a legtöbb alkalommal. Ez csak egy tervezési kérdés. A probléma szélesebb. Mi van, ha a másik csapat prioritásai nagyon különböznek attól, amit a csapat csinál? Az Ön igényei lehetnek a legalacsonyabb prioritások számukra, miközben az érdekelt felek mögötted futnak.

a DevOps sikeres megvalósításának első lépése a szervezeti változások nyitottsága.

szervezeti változások

hadd beszéljem meg az érettség 5 szintjét:

  1. kezdeti: ebben a szakaszban a csapatok silókban dolgoznak, és csak szükség van az együttműködésre. Az összes csapattal való találkozón, ha megkérdezi, hogy ki a “termék” tulajdonosa, akkor nem lesz keze. A piacra jutási idő általában hosszabb, hónapokig, néha évekig tart. A prioritásokat a csapat szintjén határozzák meg, de nem a termék szintjén. Ez azt eredményezi, hogy minden csapatnak megvan a saját prioritása. Mivel nincs meghatározott folyamat, minden kísérlet Olyan, mint a kerék újrafeltalálása. Ez minőségi problémákhoz és hosszabb határidőkhöz vezet. A csapat többnyire kézi telepítéseket és kézi beavatkozásokat végez. Nos.. ez nem rossz állapot. Így kezdődik a fejlesztés nagy része.

2. Megismételhető: a csapatok továbbra is silókban dolgoznak. A csapaton belül van valamilyen szintű automatizálás. Amikor egy válság eléri, a csapat meghatározza a saját folyamatát, és követi a válság végéig. Csak jó hír, hogy ezek közül néhány megismételhető folyamatokká válhat, amikor a válság ismét beüt.

3. Definiált: ez egy jó kiindulási pont a DevOps kultúra magjának egy központosított csapattal. Ez a csapat megérti a különböző technológiákat, amelyeket a Dev csapatok használnak, és a szerszámok a jelenlegi igényeken alapulnak. Központosított csapat lévén nem könnyű nyomon követni, hogy az egyes csapatok mit csinálnak, ezért néhány döntést a csapatokra bízunk kísérletezni. A központi csapat általában szakértőkből áll, és a dev csapatok néhány alapvető megértéssel és tudással rendelkeznek.

4. Menedzselt: mivel a központi DevOps csapat megérti a szervezeti szerszámozási környezetet, több környezetet és eszközt tesztelnek. A következetes és megismételhető folyamatokat több csapat követi. A szerszámláncot a használati esetek, nem pedig a személyes döntések alapján választják ki. Az összes folyamat felügyeleti eszközeit a csapatok vezetik be és használják a döntések meghozatalához.

5. Optimalizált:

a jó vezető sikerét az határozza meg, hogy nincs követője, hanem az a képesség, hogy nagyszerű vezetőket hozzon létre.

a DevOps érettségének utolsó szakasza a DevOps csapat eltűnése. Ez úgy néz ki, mint számláló intuitív. Ebben a szakaszban a DevOps a termékfejlesztő csapat része, nem pedig különálló egység. Infrastruktúra használata kódként, konténerként, hangszerelésként stb. zero touch telepítés érhető el. Most, ha felhívsz mindenkit, aki egy terméken dolgozik, és megkérdezed, hogy ki birtokolja a terméket, akkor magabiztos kezek lesznek, habozás nélkül. A felügyeleti eszközökből származó adatokat új eszközök kiválasztására használják (beleértve az infrastruktúrát, a programozási nyelveket, a technikákat). A döntések személyes preferenciák helyett adatokon alapulnak. A termékcsapat készen áll a kód telepítésére bármely nap és bármikor. Szeretik az “üzleti értéket”, és háziállatként kezelik. Minden mást szarvasmarhaként kezelnek.

DevOps Érettségi Modell.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.