A kérdés, hogy "hogyan vezessük be a DevOps-ot az üzletünkben", már évek óta aktualitását veszti, de jó anyagokból nincs túl sok. Néha áldozatává válik az ember a nem túl okos tanácsadók reklámainak, akik csak az idejüket akarják eladni, mindegy, hogyan. Néha ezek homályos, rendkívül általános szavak arról, hogyan vitorláznak megakorporációk hajói az univerzumban. Felmerül a kérdés: de nekünk mi hasznunk ebből? Tisztelt szerző, kérem, világosan foglalja össze az ötleteit egy listában!
Mindez abból fakad, hogy valójában nem sok tapasztalat és a vállalati kultúra átalakulásának kimenetele iránti megértés halmozódott fel. A kulturális változások hosszú távú folyamatok, amelyek eredményei nem egy héten belül, és nem egy hónapon belül fognak megjelenni. Azt akarjuk, hogy legyen valaki, aki eléggé tapasztalt, aki látta, ahogy a cégek évtizedeken át jöttek létre és dőltek össze.
John Willis — a DevOps egyik atyja. John mögött évtizedes tapasztalat áll, rengeteg céggel dolgozott együtt. Az utóbbi időben John észlelte a különböző mintázatokat, amelyek minden egyes cégnél megfigyelhetők. Ezeknek az archetipusoknak a felhasználásával John a valódi DevOps-transzformáció felé tereli a cégeket. További részletek ezekről az archetipusokról a DevOops 2018 konferencián elhangzott előadása fordításában találhatók.
A szónokról:
Több mint 35 éve dolgozik az IT-menedzsment területén, részt vett az OpenCloud elődjének létrehozásában a Canonical-nál, 10 startupban dolgozott, kettőt értékesített a Dellnek és a Dockernek. Jelenleg a SJ Technologies DevOps és Digitális Gyakorlatokért felelős alelnöke.
Következik John narrációja.
A nevem John Willis, és a Twitteren a legegyszerűbb megtalálni: . Ugyanazzal a névvel vagyok jelen a Gmail-en és a GitHub-on. A videofelvételeimet és a prezentációimat pedig itt találhatja. вы можете найти видеозаписи моих докладов и презентации к ним.
Számos megbeszélésem van különböző nagyvállalatok CIO-jaival. Gyakran panaszkodnak, hogy nem értik, mi az a DevOps, és mindenki, aki megpróbálja elmagyarázni nekik, a saját nézőpontjáról beszél. Egy másik gyakori panasz, hogy a DevOps nem működik, pedig a vezetők mindent úgy csinálnak, ahogyan azt elmondták nekik. Olyan nagy cégekről van szó, amelyek több mint száz éve működnek. Az interakcióim után arra a következtetésre jutottam, hogy sok problémára a magas technológia helyett inkább viszonylag alacsony technológiájú megoldások a legjobbak. Hetekig csak beszélgettem különböző osztályok embereivel. Amit az első képen látsz a posztban — a legutolsó projektem, a szoba így nézett ki három nap munka után.
Mi az a DevOps?
Valóban, ha megkérdezel 10 különböző embert, 10 különböző választ fognak adni. De ami érdekes: mindez a tíz válasz helyes. Itt nincs rossz válasz. Körülbelül 10 éve mélyen foglalkozom a DevOps-szal, én voltam az első amerikai az első DevOpsDay-en. Nem mondom, hogy okosabb vagyok, mint mindenki, aki a DevOps-t csinálja, de aligha van valaki, aki ennyi energiát fektetett bele. Úgy vélem, a DevOps akkor jön létre, amikor az emberi tőke és a technológia találkozik. Gyakran elfelejtjük az emberi dimenziót, pedig sokat beszélünk a különféle kultúrákról.
Jelenleg sok adatunk van, öt évnyi akadémiai kutatás, a elméleteket ipari méretekben ellenőriztük. Ezek a kutatások a következőt mondják: ha a szervezeti kultúrában bizonyos viselkedési mintákat összekapcsolunk, akár 2000-szeres gyorsulást is elérhetünk. Ehhez a gyorsuláshoz hasonló mértékű stabilitásnövekedés is társul. Ez a DevOps által bármely cég számára nyújtott előny mennyiségi mérése. Két évvel ezelőtt beszéltem a DevOps-ról egy Fortune 5000 listás cég vezérigazgatójának. Amikor a prezentációra készültem, nagyon ideges voltam, mert öt perc alatt kellett összefoglalnom több éves tapasztalatomat.
Végül a következő meghatározást adtam a DevOps-ra: ez egy olyan gyakorlatok és minták összessége, amelyek képesek az emberi tőkét magas teljesítményű szervezeti tőkévé alakítani. Példa: így működik a Toyota az utolsó 50 vagy 60 évben.
(A továbbiakban ezek a sémák nem tájékoztató anyagként, hanem illusztrációként szerepelnek. A tartalmuk minden új cég esetében eltérő lesz. Ennek ellenére a képet külön meg lehet nézni és nagyítani)
Az egyik legsikeresebb ilyen gyakorlat — value stream mapping. Erről több jó könyv is született, a legjobbak egyike — Karen Martin. Az utolsó egy év tapasztalatai alapján azonban arra a követkesztetésre jutottam, hogy ez a megközelítés túlságosan technológiai jellegű. Annak ellenére, hogy számos előnye van, amit sokáig használtam. De amikor a vezérigazgató tőlem kérdezi, hogy miért nem tud a cége új irányba váltani, akkor a value stream mappingről való beszélgés korai. Számos alapvető kérdés van, amire előtte válaszokat kell találni.
Úgy gondolom, sok kollégám hibája abban rejlik, hogy csak öt pontból álló útmutatót adnak a cégnek, majd hat hónap múlva visszatérnek, hogy megnézzék, mi történt. Még egy jó séma, mint a value stream mapping is rendelkezik, mondjuk így, halott zónákkal (blind spots). Számos különböző cég vezetőivel folytatott interjú után kialakítottam egy bizonyos mintát, amely lehetővé teszi, hogy a problémát elemekre bontsuk, és most sorra át fogjuk beszélni mindegyik elemet. Mielőtt bármilyen technológiai megoldást alkalmaznék, ezt a mintát használom, és ennek eredményeként minden falam tele van sémákkal. Nemrég egy kölcsönös alapban dolgoztam, és végül 100-150 ilyen sémám lett.
A rossz kultúra reggelire megeszi a jó megközelítéseket
A fő gondolat az, hogy semmilyen Lean, Agile, SAFE és DevOps nem segít, ha a szervezet kultúrája gyenge. Olyan, mintha mélybe merülnél légzőkészülék nélkül, vagy operálnál röntgenfelvétel nélkül. Más szavakkal, Peter Druckert és W. Edwards Deminget parafrazálva: a gyenge vállalati kultúra elnyeli bármilyen jó rendszert és nem fojtja meg.
A fő probléma megoldásához a következő lépéseket szükséges megtenni:
- Minden munka láthatóvá tétele: a munkát láthatóvá kell tenni. Nem úgy, hogy minden képernyőn megjelenjen, hanem úgy, hogy megfigyelhető legyen.
- A munka kezelésének rendszereit egyesíteni: a menedzsment rendszerek konszolidálására van szükség. A „törzsi” tudás és az intézményi tudás problémájában 9 esetből 10-ben az emberek jelentik a szűk keresztmetszetet. A könyvben a probléma egyetlen emberben gyökerezett, Brentben, ami miatt a projekt három évet csúszott. Az ilyen „Brentek” mindenhol előfordulnak. Ezeknek a szűk keresztmetszeteknek a feloldásához a következő két pontot használom a listánkban.
- A Korlátozások Elmélete Módszertan: a korlátozások elmélete.
- Együttműködési hackek: együttműködési hackek.
- Toyota Kata (): a Toyota Katáról nem fogok sokat beszélni. Ha érdekel, a GitHubomon majdnem mindegyik témáról.
- Piacorientált Szervezet: piacorientált szervezet.
- Shift-left auditors: korai fázisú audit.
A munkát az organizációval nagyon egyszerűen kezdem: elmegyek a céghez és beszélgetek az alkalmazottakkal. Amint látjuk, semmilyen csúcstechnológia nem szükséges. Csupán annyira van szükség, hogy legyen mivel írni. Összegyúrok néhány csapatot egy szobában, és elemzem, amit mondanak, a magam 7 archetipusának szempontjából. Aztán adok nekik egy filcet, és kérem, hogy írják le a táblára mindazt, amit eddig hangosan mondtak. Általában egy ilyen találkozón van egy ember, aki mindent feljegyez, és a legjobb esetben is csupán a vita 10%-át tudja rögzíteni. Az én módszeremmel ez a szám körülbelül 40%-ra emelhető.
(Ezt az illusztrációt külön lehet )
A megközelítésem William Schneider ( ) munkáján alapul. A megközelítés lényege, hogy bármely szervezet felbontható négy négyzetre. Ez a séma általában a sok más séma eredménye, amelyek az organizáció elemzése során merülnek fel. Tegyük fel, hogy van egy szervezet, amelynek magas a kontrollszintje, de alacsony a kompetenciája. Ez rendkívül nemkívánatos állapot: amikor mindenki követi a szabályokat, de senki sem tudja, mit kell tenni.
Egy kicsit jobb lehetőség, magas szintű irányítással és kompetenciával. Ha egy ilyen cég nyereséges, lehet, hogy a DevOps-ra nincs is szüksége. A legérdekesebb a céggel dolgozni, ahol magas a kontroll, alacsony a kompetencia és az együttműködés, de emellett magas a kultúra szintje. Ez azt jelenti, hogy a cégnél sok olyan ember dolgozik, aki szívesen van ott, és alacsony a fluktuáció.
(Ezt az illusztrációt külön lehet )
Úgy gondolom, hogy a szigorú iránymutatásokkal rendelkező módszerek végső soron akadályozzák az igazság elérését. Különösen a value stream mapping esetében sok szabály van arról, hogyan kell felépíteni az információt. A munka korai szakaszaiban, amelyekről most beszélek, ezek a szabályok senkinek sem szükségesek. Ha valaki egy markert a kezében tartva leírja a táblára a cég valós helyzetét - ez a legjobb módja annak, hogy megértsük a helyzetet. Az ilyen információk nem jutnak el a vezetőkhöz. Ebben a pillanatban butaság lenne megszakítani az embert, és azt mondani, hogy valamit rosszul rajzolt. Ebben a szakaszban jobban tennénk, ha egyszerű szabályokat alkalmaznánk, például: többszintű elvont fogalmakat lehet létrehozni csak színes markerek használatával.
Ismétlem, semmi magas technológia. A fekete marker az objektív valóságot ábrázolja, ahogyan minden működik. A piros markerrel az emberek jelzik, hogy mi az, amit a meglévő helyzetben nem szeretnek. Fontos, hogy ezt ők írják, és ne én. Amikor a megbeszélés után elmegyek az informatikai igazgatóhoz, nem ajánlok egy listát a 10 dologról, amit javítani kell. Arra törekszem, hogy kapcsolatokat találjak a cégtől érkező emberek mondásai és a létező jól bevált minták között. Végül, a kék markerrel javasolt megoldások kerülnek elő.
(Ezt az illusztrációt külön lehet )
Egy példa erre a megközelítésre most látható fent. Az év elején egy bankkal dolgoztam. Az ottani biztonsági osztály munkatársai meg voltak győződve arról, hogy nem szabad részt venniük a követelmények és tervezés (design and requirement reviews) ellenőrzésén.
(Ezt az illusztrációt külön lehet )
Aztán beszélgettünk más osztályok embereivel, és kiderült, hogy körülbelül 8 évvel ezelőtt a szoftverfejlesztők miatt kiutasították a biztonsági munkatársakat, mert lassították a munkát. Aztán ez egy olyan tilalommá változott, amelyet adott dolognak tekintettek. Pedig valójában nem volt semmilyen tilalom.
A találkozónk rendkívül zűrzavarosan alakult: körülbelül három órán keresztül öt különböző csapat nem tudta megmagyarázni, hogy mi történik a kód és a build között. Pedig ez látszólag a legegyszerűbb dolog. A legtöbb DevOps tanácsadó feltételezi, hogy ez már mindenkinek egyértelmű.
Aztán az IT igazgatásért felelős személy, aki négy órán keresztül csendben volt, hirtelen felélénkült, amikor a témájához értünk, és még hosszú ideig elvitte a szót. A végén megkérdeztem tőle, mit gondol a találkozóról, és soha nem fogom elfelejteni a válaszát. Azt mondta: „Korábban azt hittem, hogy a bankunkban csak két módszer van a szoftverek szállítására, most pedig már tudom, hogy összesen öt van, és háromról még csak nem is sejtettem.”
(Ezt az illusztrációt külön lehet )
Az utolsó találkozó a bankban a befektetésekkel foglalkozó csapattal volt. Velük derült ki, hogy sokkal jobb a terveket markerrel egy papírra írni, mint táblára, sőt, még egy smartboardra is.
A képek, amiket látsz, azt mutatják, hogyan nézett ki a szálloda konferenciaterme a találkozónk negyedik napján. Ezeket a terveket használtuk a minták, azaz archetipusok keresésére.
Tehát kérdéseket teszek fel a munkatársaknak, ők három színű filctollal (fekete, piros és kék) jegyzik fel a válaszaikat. Azokat az archetipusok szempontjából elemzem. Most nézzük át az összes archetipust sorrendben.
1. Make All Work Visible: Tedd láthatóvá a munkát
A legtöbb cégnél, ahol dolgozom, nagyon magas az ismeretlen munka aránya. Például, amikor egy munkatárs megkeres egy másikat, és egyszerűen kér valamit. A nagyobb szervezetekben ez akár 60%-ot is elérhet a tervezett munka hiányában. És akár 40%-a a munkának nincs dokumentálva. Ha ez a Boeing lenne, soha többé nem ülnék fel a repülőgépükre. Ha csak a munka felét dokumentálják, akkor nem tudható, hogy helyesen hajtják-e végre a feladatokat. Az összes többi módszer haszontalan — nincs értelme bármit is automatizálni, mert a jól ismert 50% lehet, hogy a munka legjobban összehangolt és pontos része, amelynek automatizálása nem hoz nagy eredményeket, míg a legrosszabb dolgok a láthatatlan felében rejlenek. Dokumentáció hiányában nem lehet észlelni a különböző trükköket és rejtett munkát, nem találhatóak meg a szűk keresztmetszetek, azok a „Brentek”, akikről már beszéltem. Van egy remek könyv Dominika De Grandistól . Az feltárja az öt különböző „időeltulajdonítót” (thieves of time):
- Túl sok folyamatban lévő munka (WIP)
- Ismeretlen függőségek
- Tervezetlen munka
- Ütköző prioritások
- Elhanyagolt munka
Ez egy nagyon értékes elemzés, és a könyv csodálatos, de mindezek a tanácsok haszontalanok, ha csak az adatok 50%-a látható. Dominika által javasolt módszereket csak akkor lehet alkalmazni, ha a pontosság 90% fölött van. Olyan helyzetekről beszélek, amikor a vezető egy 15 perces feladatot ad a beosztottjának, de az három napig tart; de a vezető valójában nem tudja, hogy a beosztottja négy vagy öt másik embertől is függ.
A Phoenix Project — egy csodálatos történet egy projektről, amely három évet késett. Az egyik hősének emiatt kirúgás fenyegetése áll, és találkozik egy másik szereplővel, aki egyfajta Szokratészként van bemutatva. Ő segít kideríteni, hogy mi is ment félre. Kiderül, hogy a cégnél van egy rendszergazda, akit Brentnek hívnak, és minden munka áthalad rajta valamilyen módon. Az egyik megbeszélésen az egyik beosztott megkérdezi: miért tart egy félórás feladat egy hétig? A válasz egy nagyon leegyszerűsített sorban állási elmélet és a Little-törvény ismertetése, amelyben kiderül, hogy 90%-os kihasználtság mellett minden egyes órányi munka 9 órát vesz igénybe. Minden feladatot hét másik embernek kell elküldeni, így ez az óra 63 órává, 7-szer 9-re alakul. Ezt azért mondom, mert ahhoz, hogy használni tudjuk a Little-törvényt vagy bármilyen összetettebb sorban állási elméletet, legalább adatokra van szükség.
Ezért, amikor a láthatóságról beszélek, nem arra gondolok, hogy minden látható legyen a képernyőn, hanem hogy legalább legyenek adatok. Amikor ezek megvannak, gyakran kiderül, hogy nagyon nagy mennyiségű tervezetlen munka van, amely valamiért Brenthez irányul, bár nincs rá szükség. Brent egy remek fickó, soha nem mondja, hogy „nem”, de azt sem osztja meg senkivel, hogyan végzi el a munkáját.
Amikor a munka látható, pontosan lehet osztályozni az adatokat (ezt csinálja Dominika a képen), alkalmazhatjuk az öt időveszteségi absztrakciót és automatizálhatjuk.
2. Munka Menedzsment Rendszerek Összevonása: Feladatkezelés
Az archetipusok, amelyekről beszélek, egyfajta piramist alkotnak. Ha az elsőt helyesen hajtják végre, akkor a második már egyfajta föléépítmény. Sok közülük nem működik startupok számára, ezeket figyelembe kell venni nagyobb cégek esetén, például amelyek a Fortune 5000 listájára kerülnek. Az utolsó cégnél, ahol dolgoztam, 10 hibakövető rendszer (ticketing system) volt. Az egyik csapat a Remedy-t használta, a másik egy saját rendszert írt, a harmadik pedig a Jirával dolgozott, valaki pedig teljesen az e-mailt használta. Ugyanez a probléma merül fel, ha a cégnek 30 különböző folyamatlánca van, de nincs időm arra, hogy mindezekről beszélgessünk.
Beszélek az emberekkel arról, hogy pontosan hogyan készülnek a jegyek, mi történik velük ezután és hogyan kerülik meg őket. A legérdekesebb, hogy az emberek meglehetősen őszintén beszélnek a találkozóinkon. Megkérdeztem, hány ember állít ki „kisebb / nincs hatás” jelölést olyan jegyek számára, amelyeket valójában „nagy hatásúra” kellett volna minősíteni. Kiderült, hogy majdnem mindenki így tesz. Én nem foglalkozom besúgással, és mindent megteszek, hogy ne leplezzem le az embereket. Amikor valami őszintén elmondanak nekem, nem árulom el az illetőt. De amikor gyakorlatilag mindenki kijátssza a rendszert, az azt jelenti, hogy az összes biztonság lényegében dekoráció. Ezért az ezen rendszer adatai alapján nem lehet következtetéseket levonni.
A jegyek problémájának megoldásához ki kell választani egy fő rendszert. Ha Jira-t használsz, csak a Jira legyen. Ha van valamilyen alternatíva, akkor legyen csak az. A lényeg az, hogy a jegyeket a fejlesztési folyamat egy újabb szakaszaként kell kezelni. Minden tevékenységnek rendelkeznie kell egy jeggyel, amely át kell hogy menjen a fejlesztési munkafolyamaton. A jegyek a csapat felé kerülnek, akik kiteszik őket a storyboardra, és ezután felelősséget vállalnak értük.
Ez minden részlegre vonatkozik, beleértve az infrastruktúra és az operációs részleget is. Ebben az esetben bármenyire hihető képet lehet alkotni a helyzetről. Amikor ez a folyamat be van állítva, hirtelen kiderül, hogy könnyen meg lehet állapítani, ki felelős minden alkalmazásért. Mert most már nem 50%-ot, hanem 98%-ot kapunk az új szolgáltatásokból. Ha ez az alapvető folyamat működik, akkor a pontosabbá válik az egész rendszer.
Szolgáltatási pipeline
Ez ismét csak a nagyvállalatokra vonatkozik. Ha ön egy új cég egy új területen — akkor roll up your sleeves és dolgozzon a Travis CI-jével vagy a CircleCI-jával. Ami a Fortune 5000 cégeket illeti, egy eset, ami megmutatja a helyzetet, az az, amikor egy bankhoz dolgoztam. A Google-ról jöttek, és megmutatták nekik a régi IBM rendszerekről készült diagramokat. A Google srácai értetlenkedve kérdezték — hol van ehhez a forráskód? Hát nincs forráskód, még GUI sem. Ez az a valóság, amivel a nagy szervezeteknek dolgozniuk kell: 40 éves banki nyilvántartások egy ősi mainframe-en. Az egyik ügyfelem Kubernetes konténereket használ Circuit Breaker minták mellett, plusz Chaos Monkey-t, mindezt a KeyBank alkalmazásához. De ezek a konténerek végül egy COBOL-alkalmazáshoz csatlakoznak.
A Google srácai teljesen biztosak voltak benne, hogy megoldják az ügyfelem összes problémáját, majd elkezdtek kérdezni: mi az IBM datapipe? A válasz: ez egy csatlakozó. Mihez csatlakozik? A Sperry rendszerhez. És ez mi? És így tovább. Első pillantásra úgy tűnik: hol itt a DevOps? De valójában, ez lehetséges. Vannak olyan szállítórendszerek, amelyek lehetővé teszik, hogy a munkafolyamatokat a szállítással foglalkozó csapatoknak adják át.
3. Korlátok Elmélete: A Korlátok Elmélete
Térjünk át a harmadik archetipusra: intézményi / „törzsi” tudás. Általában bármely szervezetben van néhány ember, aki mindent tud, és mindenki vezeti. Ők azok, akik a leghosszabb ideje dolgoznak a szervezetnél, és akik tudják az összes kiskaput.
Amikor ez megjelenik a diagramon, én szándékosan pirossal keretezem az ilyen embereket: például kiderül, hogy egy bizonyos Lou minden találkozón ott van. És számomra világos: ő a helyi Brent. Amikor az IT igazgató köztem, egy pólóban és edzőcipőben, és egy öltönyös IBM-es srác között választ, engem választanak, mert tudok mondani neki olyan dolgokat, amiket az a másik srác nem fog, és amiről lehet, hogy kellemetlen hallania. Azt mondom nekik, hogy a cégükben van egy szűk keresztmetszet, az valaki, akit Frednek hívnak, és valaki, akit Lou-nak hívnak. Ezt a szűk keresztmetszetet ki kell nyitni, és a tudásukat valahogy ki kell nyerni tőlük.
Egy ilyen probléma megoldásához például javasolhatom a Slack használatát. A ravasz igazgató megkérdezi – miért? Ilyen esetekben a DevOps tanácsadók általában azt válaszolják: mert mindenki ezt csinálja. Ha az igazgató tényleg ravasz, azt mondja: és mi van ezzel? Ezzel a párbeszéd véget ér. Erre azt válaszolom: mert a vállalatnál négy szűk keresztmetszet van, Fred, Lu, Szuzi és Jane. Ahhoz, hogy tudásukat intézményesítsük, először be kell vezetni a Slacket. Az összes wiki önmagában teljes zagyvaság, mert senki sem tud a létezéséről. Ha a mérnökcsapat külső és belső fejlesztéssel foglalkozik, mindenkinek tudnia kell, hogy a külső fejlesztőcsapathoz vagy az infrastruktúrával foglalkozó csapathoz fordulhat kérdésekkel. Akkor valószínű, hogy Lunak vagy Frednek lesz ideje csatlakozni a wikiről. Aztán a Slacken valaki megkérdezheti, miért nem működik például az 5. lépés. Akkor Lu vagy Fred kijavítja az utasítást a wikin. Ha ezt a folyamatot beállítjuk, akkor sok minden magától helyére kerül.
Ez az alapvető gondolatom: ahhoz, hogy valamilyen fejlett technológiát javasoljunk, először rendbe kell tenni az alapokat, és ezt alacsony technológiájú megoldásokkal lehet elérni, amelyeket éppen most írtam le. Ha a fejlett technológiákra építünk, és nem magyarázzuk el, hogy miért van szükség rájuk, az általában nem vezet semmi jóra. Az egyik ügyfelünk az Azure ML-t használja, ami egy nagyon olcsó és egyszerű megoldás. A kérdéseik körülbelül 30%-ára már a gépi tanulás válaszolt. Ezt olyan operátorok írták, akik nem foglalkoztak adatfeldolgozással, statisztikával vagy matematikával. Ez figyelemre méltó. Az ilyen megoldás költsége minimális.
4. Együttműködési hackek: Az együttműködés trükkjei
A negyedik archetip abban rejlik, hogy küzdeni kell az elszigeteltség ellen. Sok ember már tud erről: az elszigeteltség ellenségeskedést szül. Ha minden osztály a saját szintjén van, és az emberek sosem találkoznak, kivéve a liftben, akkor az ellenségeskedés könnyen kialakul. Ha viszont az emberek egy helyiségben vannak, az ellenségeskedés azonnal eltűnik. Amikor valaki általános vádat emel, például, hogy egy bizonyos interfész sosem működik – semmi sem egyszerűbb, mint ezt a vádat dekonstruálni. Az interfészt létrehozó programozóknak elég konkrét kérdéseket feltenniük, és hamar kiderül, hogy például a felhasználó egyszerűen rosszul használta az eszközt.
Sokféle módja van az elszigeteltség leküzdésének. Egyszer megkértek, hogy tanácsot adjak egy ausztrál banknak, de ezt visszautasítottam, mert két gyermekem és a feleségem van. Amit segíteni tudtam nekik, az a grafikus történetmesélés ajánlása volt. Ez egy olyan dolog, ami bizonyítottan működik. Egy másik érdekes módszer a lean coffee formátumú találkozók. Nagy szervezetekben ez nagyszerű lehetőség a tudás átadására. Ezen kívül belső devopsdays rendezvényeket, hackathonokat és így tovább is lehet tartani.
5. Coaching Kata
Ahogy már az elején figyelmeztettem, ma erről nem fogok beszélni. Ha érdekes, nézd meg .
Van egy jó előadás erről Mike Rothertól is:
6. Piacorientált: a piacra orientált szervezet
Itt különböző problémák léteznek. Például az „I” emberek, a „T” emberek és az „E” emberek. Az „I” emberek azok, akik csak egy dologgal foglalkoznak. Általában elszigetelt osztályokkal rendelkező szervezetekben élnek. A „T”-s emberek jól ismernek egy dolgot, de más területeken is sikeresek. Az „E” vagy akár a „fésű” olyan embereket jelöl, akik sok készséggel rendelkeznek.
Itt érvényes Conway törvénye (), amely leegyszerűsített formában így írható le: ha három csapat egy fordítón dolgozik, a végén egy három részből álló fordítót kapunk. Ezért, ha a szervezeten belül magas az elszigeteltség szintje, akkor még a Kubernetes, a Circuit breaker, az API extensibility és egyéb divatos dolgok is olyan módon lesznek kialakítva, mint maga a szervezet. Szigorúan Conway szerint és mindenki számára, fiatal geekek.
A probléma megoldását már sokszor leírták. Például vannak szervezeti archetípusok, amelyeket Fernando Fernandez írt le. Az a problémás architektúra, amiről az előbb beszéltem, a funkcionálisan orientált architektúra. A második típus a legrosszabb, a mátrix architektúra, ahol a másik kettő keveredik. A harmadik pedig az, ami a legtöbb startupnál megfigyelhető, és a nagy cégek is próbálnak ehhez a típushoz igazodni. Ez a piacorientált szervezet. Itt az optimalizálás a lehető leggyorsabb válaszok érdekében történik az ügyfélkérésekre. Ezt néha lapos szervezetnek hívják.
Ezt a struktúrát sokan különböző módon írják le, nekem tetszik a megfogalmazás build/run teams, az Amazonnál ezt hívják two pizza teams. Ebben a struktúrában minden "I" típusú ember egy szolgáltatás körül csoportosul, és fokozatosan közelebb kerülnek a "T" típushoz, ha jól van megszervezve a vezetés, akár "E" is válhat belőlük. Az első ellenvélemény itt az, hogy ilyen struktúrában felesleges elemek vannak. Miért van szükség tesztelőre minden részlegben, ha lehet egy külön tesztelő részleg? Erre azt válaszolom: a felesleges kiadások ebben az esetben az ár, hogy a jövőben az egész szervezet "E" típusúvá váljon. Ebben a struktúrában a tesztelő fokozatosan megismeri a hálózatokat, architektúrát, tervezést stb. Végül minden szervezeti tag teljesen tisztában van minden dologgal, ami a szervezetben történik. Ha szeretné megérteni, hogyan működik ez a rendszer az iparban, olvassa el .
7. Shift-left auditors: audit a folyamat korai szakaszaiban. A biztonsági előírások betartása érdekében
Ez az, amikor a tetteid nem mennek át, úgy mond, az illatvizsgálaton. Azok az emberek, akik nálad dolgoznak, nem buták. Ha ők, ahogy fentebb említettek, mindenütt a minor/no impact státuszt állították be, ez három évig tartott, és senki sem vette észre, akkor mindenki tudja, hogy a rendszer nem működik. Vagy egy másik példa — a változtatási tanácsadó testület, ahová minden szerdán be kell nyújtani a jelentéseket. Ott egy olyan emberekből álló csoport dolgozik (mellesleg nem túl jól fizetve), akik elvileg tudniuk kellene, hogyan működik a rendszer egésze. Az utolsó öt évben biztosan észrevetted, hogy a rendszereink őrült módon összetettek. És öt-hat embernek kell döntenie egy olyan változtatásról, amelyet nem ők javasoltak, és amelyről semmit sem tudnak.
Természetesen ez a megközelítés nem működik. Meg kell szabadulnom az ilyen dolgoktól, mert ezek az emberek nem védik a rendszert. A döntést magának a csapatnak kell meghoznia, mert a csapatnak kell felelősséget vállalnia érte. Ellenkező esetben paradox helyzet áll elő, amikor a menedzser, aki életében soha nem írt kódot, közli a programozóval, mennyi ideig kellene tartania a kód megírásának. Az egyik cégnél, ahol dolgoztam, 7 különböző tanács vizsgálta meg az egyes változtatásokat, köztük az architekturális, termék- és egyéb tanácsokat. Volt egy kötelező várakozási idő is, bár egy kolléga elmondta nekem, hogy tíz év alatt senki soha nem utasított el egy változtatást a kötelező várakozási idő alatt, amelyet ez a személy javasolt.
Az auditorokat magunkhoz kell hívni, nem pedig megszabadulni tőlük. Mesélj nekik arról, hogy változatlan bináris konténereket írsz, amelyek, ha minden teszten átmennek, örökre változatlanok maradnak. Mondd el nekik, hogy van pipeline as code, és magyarázd el, mit jelent ez. Mutasd meg nekik a következő diagramot: változatlan bináris konténer, amely csak olvasható, és áthalad az összes sebezhetőségi teszten; és senki sem nyúl hozzá — még a rendszerhez sem, amely létrehozza a pipeline-t, mivel ez is dinamikusan készül. Vannak ügyfeleim, például a Capital One, akik Vault segítségével valami blokklánc-szerűt hoznak létre. Az auditoroknak nem kell megmutatni a Chef „recepteit”, elegendő, ha megmutatjuk a blokkláncot, amely világosan mutatja, hogy mi történt a Jira jeggyel a termelésben és ki a felelős érte.
A következő szerint , amelyet 2018-ban alapítottak, 2017-ben 87 milliárd letöltési kérés volt az OSS-re.
A sebezhetőségek miatt elszenvedett veszteségek elképesztően magasnak bizonyulnak. Ráadásul az a szám, amit most látsz fent, nem tartalmazza az alternatív költségeket. Röviden a DevSecOps-ról. Azonnal szeretném elmondani, hogy nem érdekelnek a beszélgetések arról, mennyire sikeres ez a név. A lényeg az, hogy mivel a DevOps rendkívül sikeres volt, érdemes megpróbálni biztonságot hozzáadni ehhez a pipeline-hoz.
Egy példa az ilyen sorrendre:
Ez nem ajánlás konkrét termékekre, bár mindet szeretem. Példaként hoztam őket, hogy megmutassam, a DevOps, ami eredetileg az ipari szerveződés paradigmáján alapul, lehetővé teszi a termék fejlesztésének minden szakaszának automatizálását.
Nincs semmi ok, amiért ne alkalmazhatnánk ugyanazt a megközelítést a biztonságra.
Result
A következő hónapokban néhány tanácsot szeretnék adni a DevSecOps számára. Be kell vonni az auditorokat a rendszereik kialakítási folyamatába, és időt kell fordítani az oktatásukra. Együttműködni kell az auditorokkal. Továbbá, könyörtelenül fel kell lépni a hamis riasztások ellen. Még a legdrágább sebezhetőségi szkennerrel is rendkívül káros szokásokat alakíthatunk ki a fejlesztőkben, ha nem tudjuk, mi a jel/zaj arány. A fejlesztők túlterheltté válnak az események sorozatától, és egyszerűen csak törölni fogják őket. Ha hallott addig az Equifax esetről, akkor nagyjából ez történhetett – az ottani legmagasabb szintű veszélyjelzést figyelmen kívül hagyták. Emellett a sebezhetőségeket úgy kell magyarázni, hogy világosan érthető legyen, hogyan befolyásolják az üzletet. Például mondhatjuk, hogy ez ugyanaz a sebezhetőség, mint az Equifax esetében. A biztonsági sebezhetőségeket ugyanolyan problémakezelésként kell kezelni, mint a többi szoftverproblémát, azaz be kell őket vonni a DevOps általános folyamatába. A Jira, Kanban stb. rendszeren keresztül kell velük dolgozni. A fejlesztőknek nem szabad azt hinniük, hogy ezt más fogja megoldani – ehelyett mindenkinek ezzel kell foglalkoznia. Végül energiát kell fordítani az emberek képzésére.
Hasznos linkek
Íme néhány előadás a DevOops konferenciáról, amelyek hasznosnak tűnhetnek számunkra:
- Szergej Berdnyikov, Artyom Kalichkin – Sikertörténet, azaz "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnyik – DevOps nagy léptékben: görög tragédia három felvonásban (, )
- Alexander Titov, Kirill Tolkacsev –
- Timothy Lister –
Nézze meg a DevOops 2020 Moscow – ott is sok érdekes dolog van.
Forrás: habr.com
