A „devops hogyan valósítható meg” kérdés már évek óta fennáll, de nincs sok jó anyag. Néha áldozatául esik a nem túl okos tanácsadók hirdetéseinek, akiknek el kell adniuk idejüket, bárhogyan is. Néha ezek homályos, rendkívül általános szavak arról, hogy a megavállalatok hajói hogyan szántják fel az univerzum kiterjedését. Felmerül a kérdés: mit számít ez nekünk? Kedves szerző! Meg tudod fogalmazni egy listában egyértelműen az elképzeléseidet?
Mindez abból fakad, hogy nem sok valós gyakorlat és megértés halmozódott fel a vállalati kultúra átalakulásának kimeneteléről. A kultúra változásai hosszú távú dolgok, amelyeknek nem egy hét vagy egy hónap múlva lesz az eredménye. Szükségünk van valakire, aki elég idős ahhoz, hogy lássa, hogyan épültek fel és dőltek el a cégek az évek során.
John Willis - a DevOps egyik atyja. John több évtizedes tapasztalattal rendelkezik számos vállalatnál. John nemrégiben kezdett észrevenni bizonyos mintákat, amelyek mindegyikükkel való munka során fellépnek. John ezeket az archetípusokat felhasználva vezeti a vállalatokat a DevOps átalakulásának valódi útján. Tudjon meg többet ezekről az archetípusokról a DevOops 2018 konferenciáról készült jelentésének fordításában.
Az előadóról:
Több mint 35 év IT menedzsmentben, részt vett az OpenCloud elődjének létrehozásában a Canonicalnál, 10 startupban vett részt, amelyek közül kettőt eladtak a Dellnek és a Dockernek. Jelenleg az SJ Technologies DevOps-ért és digitális gyakorlatokért felelős alelnöke.
A következő a történet John szemszögéből.
A nevem John Willis, és a legkönnyebben a Twitteren találhat meg. . Ugyanaz az álnevem a Gmailben és a GitHubon. A riportjaimról videófelvételeket és a nekik szóló előadásokat találhat.
Sok találkozóm van különböző nagyvállalatok informatikai igazgatóival. Nagyon gyakran panaszkodnak, hogy nem értik, mi az a DevOps, és mindenki másról beszél, aki megpróbálja elmagyarázni nekik. Egy másik gyakori panasz az, hogy a DevOps nem működik, bár úgy tűnik, hogy a rendezők mindent úgy csinálnak, ahogyan elmagyarázták nekik. Több mint száz éves nagyvállalatokról beszélünk. A velük való beszélgetés után arra a következtetésre jutottam, hogy sok problémára nem a csúcstechnológia a legalkalmasabb, hanem a viszonylag alacsony technológiájú megoldások. Hetekig csak beszélgettem különböző részlegekről származó emberekkel. Amit a poszt legelső képén látsz, az az utolsó projektem, három nap munka után így nézett ki a szoba.
Mi az a DevOps?
Valóban, ha 10 különböző embert kérdezel meg, 10 különböző választ adnak. De itt az érdekes: mind a tíz válasz helyes lesz. Itt nincs rossz válasz. Körülbelül 10 évig nagyon mélyen jártam a DevOps-ban, és az első amerikai voltam az első DevOpsDay-n. Nem mondom, hogy okosabb vagyok mindenkinél, aki részt vesz a DevOps-ban, de alig van valaki, aki ennyi erőfeszítést fordított volna rá. Úgy gondolom, hogy a DevOps akkor jön létre, amikor a humán tőke és a technológia találkozik. Gyakran megfeledkezünk az emberi dimenzióról, pedig rengeteget beszélünk mindenféle kultúráról.
Most rengeteg adatunk van, öt év tudományos kutatás, elméletek tesztelése ipari méretekben. Ezek a tanulmányok azt mondják nekünk, hogy ha egyesítünk bizonyos viselkedési mintákat egy szervezeti kultúrában, akkor 2000-szeres gyorsulást érhetünk el. Ez a gyorsulás a stabilitás azonos javulásával párosul. Ez a DevOps által bármely vállalat számára nyújtott előnyök mennyiségi mérése. Pár éve a DevOps-ról beszélgettem egy Fortune 5000-es cég vezérigazgatójával, amikor a bemutatóra készültem, nagyon izgultam, mert 5 percben össze kellett foglalnom a több éves tapasztalatomat.
Végül a következőket adtam A DevOps definíciója: Olyan gyakorlatok és minták összessége, amelyek lehetővé teszik a humán tőke átalakulását nagy teljesítményű szervezeti tőkévé. Példa erre a Toyota működése az elmúlt 50 vagy 60 évben.
(A továbbiakban az ilyen diagramok nem referenciaanyagként, hanem illusztrációként szolgálnak. Tartalmuk új cégenként eltérő lesz. A kép azonban külön is megtekinthető és nagyítható
Az egyik legsikeresebb ilyen gyakorlat az értékáramlás feltérképezése. Erről több jó könyv is született, ezek közül a legsikeresebbek Karen Martiné. De az elmúlt évben arra a következtetésre jutottam, hogy még ez a megközelítés is túl high-tech. Természetesen sok előnye van, és sokat használtam is. Ám amikor a vezérigazgató megkérdezi, miért nem tud új sínekre váltani a cége, túl korai még értékfolyam-feltérképezésről beszélni. Sok sokkal alapvetőbb kérdés van, amelyekre először meg kell válaszolni.
Azt hiszem, sok kollégám azt a hibát követi el, hogy egyszerűen adnak a cégnek egy ötpontos útmutatót, majd hat hónappal később visszajönnek, és megnézik, mi történt. Még egy olyan jó sémának is, mint az értékfolyam-leképezés, vannak, mondjuk, vakfoltok. Különböző cégek igazgatóival készült több száz interjút követően kialakítottam egy bizonyos mintát, amely lehetővé teszi számunkra, hogy a problémát összetevőire bontsuk, és most ezeket az összetevőket sorban tárgyaljuk. Mielőtt bármilyen technológiai megoldást alkalmaznék, ezt a mintát használom, és ennek eredményeként minden falamat diagramok borítják. Nemrég egy befektetési alapnál dolgoztam, és 100-150 ilyen konstrukcióval kötöttem ki.
A rossz kultúra jó ételeket fogyaszt reggelire
A fő gondolat a következő: semmiféle Lean, Agile, SAFE és DevOps nem segít, ha maga a szervezet kultúrája rossz. Olyan ez, mint a mélybe merülni búvárfelszerelés nélkül, vagy röntgen nélkül dolgozni. Más szóval, Druckert és Deminget átfogalmazva: a rossz szervezeti kultúra minden jó rendszert elnyel anélkül, hogy megfulladna tőle.
A fő probléma megoldásához a következő lépéseket kell tennie:
- Minden munka láthatóvá tétele: láthatóvá kell tennie az összes munkát. Nem abban az értelemben, hogy szükségszerűen meg kell jelennie valamilyen képernyőn, hanem abban az értelemben, hogy megfigyelhetőnek kell lennie.
- Összevont munkairányítási rendszerek: az irányítási rendszereket konszolidálni kell. A „törzsi” tudás és az intézményi tudás problémájában 9-ből 10 esetben az emberek jelentik a szűk keresztmetszetet. A könyvben a probléma egyetlen személlyel, Brenttel volt, aki miatt a projekt három évet késett. És mindenhol összefutok ezekkel a „Brentekkel”. E szűk keresztmetszetek feloldására a listánk következő két elemét használom.
- A korlátok elméletének módszertana: a kényszer elmélete.
- Együttműködési hackek: együttműködési hackek.
- Toyota Kata (): A Toyota Katáról nem sokat beszélek. Ha érdekel, a githubon szinte mindegyik témában.
- Piacorientált szervezet: piacorientált szervezet.
- Balra váltó könyvvizsgálók: audit a ciklus korai szakaszában.
Nagyon egyszerűen elkezdek dolgozni egy szervezettel: bemegyek a céghez, és beszélgetek az alkalmazottakkal. Mint látható, nincs csúcstechnológia. Csak valamire van szüksége, amire írhat. Több csapatot gyűjtök össze egy helyiségben, és elemzem, mit mondanak nekem a 7 archetípusom szemszögéből. Aztán adok nekik maguknak egy jelzőt, és megkérem őket, hogy írjanak fel mindent a táblára, amit eddig hangosan mondtak. Általában az ilyen típusú megbeszéléseken van egy ember, aki mindent leír, és legfeljebb a megbeszélés 10%-át tudja leírni. Az én módszeremmel ez a szám körülbelül 40%-ra emelhető.
(Ez az ábra külön is megtekinthető )
Megközelítésem William Schneider munkásságán alapul. ). A megközelítés azon az elgondoláson alapul, hogy bármely szervezet négy négyzetre osztható. Ez a séma számomra általában annak a több száz egyéb sémának az eredménye, amelyek egy szervezet elemzésekor merülnek fel. Tegyük fel, hogy van egy szervezetünk magas szintű ellenőrzéssel, de alacsony kompetenciával. Ez egy rendkívül nemkívánatos lehetőség: amikor mindenki szegődik, de senki sem tudja, mit tegyen.
Valamivel jobb megoldás az, amelyik magas szintű ellenőrzéssel és kompetenciával rendelkezik. Ha egy ilyen cég nyereséges, akkor talán nincs szüksége DevOps-ra. A legérdekesebb olyan céggel dolgozni, amely magas szintű kontrollal, alacsony kompetenciával és kooperációval rendelkezik, de ugyanakkor magas a kultúra (művelés) szintje. Ez azt jelenti, hogy a cégnek nagyon sok embere van, aki szeretne ott dolgozni, és alacsony a munkaerő fluktuációja.
(Ez az ábra külön is megtekinthető )
Számomra úgy tűnik, hogy a merev irányelveket tartalmazó módszerek végül az igazság elérésének útjába állnak. Különösen az értékfolyam-leképezésben sok szabály létezik arra vonatkozóan, hogyan kell az információkat strukturálni. A munka kezdeti szakaszában, amelyről most beszélek, senkinek nincs szüksége ezekre a szabályokra. Ha egy személy markerrel a kezében leírja a táblán a vállalat valós helyzetét, ez a legjobb módja annak, hogy megértsük a dolgok állását. Az ilyen információk nem jutnak el az igazgatókhoz. Ebben a pillanatban hülyeség félbeszakítani az illetőt, és azt mondani, hogy valami nyilat rosszul rajzolt. Ebben a szakaszban jobb egyszerű szabályokat használni, például: többszintű absztrakciót egyszerűen többszínű markerek használatával lehet létrehozni.
Ismétlem, nincs csúcstechnológia. A fekete marker az objektív valóságot ábrázolja, hogyan működik minden. Piros jelzővel jelölik az emberek, hogy mi nem tetszik nekik a dolgok jelenlegi állásában. Fontos, hogy ezt ők írják, ne én. Amikor egy értekezlet után a CIO-hoz megyek, nem ajánlok fel 10 javítandó dolgot tartalmazó listát. Arra törekszem, hogy összefüggéseket találjak a cégben dolgozók által elmondottak és a meglévő bevált minták között. Végül egy kék marker a probléma lehetséges megoldásait javasolja.
(Ez az ábra külön is megtekinthető )
Erre a megközelítésre a fentiekben egy példát mutatunk be. Ez év elején egy bankkal dolgoztam. Az ottani biztonsági emberek meg voltak győződve arról, hogy nem szabad eljönniük a tervezés és a követelmények felülvizsgálatára.
(Ez az ábra külön is megtekinthető )
Aztán beszélgettünk más részlegekről érkezőkkel, és kiderült, hogy körülbelül 8 évvel ezelőtt a szoftverfejlesztők elbocsátottak biztonsági dolgozókat, mert lassították a munkát. Aztán kitiltás lett belőle, ami természetesnek számított. Bár a valóságban nem volt tiltás.
Találkozásunk rendkívül zavaros módon zajlott: körülbelül három órán keresztül öt különböző csapat nem tudta elmagyarázni nekem, mi történik a kód és az összeállítás között. És ez tűnik a legegyszerűbbnek. A legtöbb DevOps tanácsadó előre feltételezi, hogy ezt már mindenki tudja.
Aztán a négy órája hallgatag informatikai kormányzásért felelős személy hirtelen életre kelt, amikor a témájához értünk, és nagyon sokáig foglalkoztatott bennünket. A végén megkérdeztem, mit gondol a találkozóról, és soha nem felejtem el a válaszát. Azt mondta: „Korábban azt hittem, hogy a bankunknak csak két módja van a szoftverek szállítására, de most már tudom, hogy öt van, háromról pedig nem is tudtam.”
(Ez az ábra külön is megtekinthető )
A legutóbbi találkozó ennél a banknál a befektetési szoftver csapattal volt. Vele derült ki, hogy a diagramokat jelölővel egy papírlapra írni jobb, mint egy táblára, és még jobb, mint egy smartboardra.
A látható fotók azt mutatják, hogyan nézett ki a szálloda konferenciaterme találkozónk negyedik napján. És ezekkel a sémákkal kerestük a mintákat, vagyis az archetípusokat.
Tehát kérdéseket teszek fel a dolgozóknak, ők három színű (fekete, piros és kék) markerekkel írják le a válaszokat. Válaszaikat archetípusokra elemzem. Most beszéljük meg az összes archetípust sorban.
1. Minden munka láthatóvá tétele: A munka láthatóvá tétele
A legtöbb cégnél, amellyel dolgozom, nagyon magas az ismeretlen munka aránya. Például ilyenkor az egyik alkalmazott odajön a másikhoz, és egyszerűen csak kér valamit. Nagy szervezetekben előfordulhat, hogy 60%-a nem tervezett munka. És a munka legfeljebb 40%-át semmilyen módon nem dokumentálják. Ha Boeing lenne, soha életemben nem szállnék fel újra a gépükre. Ha a munkának csak a fele van dokumentálva, akkor nem tudni, hogy ezt a munkát megfelelően végzik-e vagy sem. Minden más módszer haszontalannak bizonyul - nincs értelme bármit is automatizálni, mert az ismert 50% lehet a munka legkoherensebb és legtisztább része, amelynek automatizálása nem hoz nagy eredményt, és a legrosszabb a dolgok a láthatatlan felében vannak. Dokumentáció hiányában lehetetlen mindenféle hack-et és rejtett munkát találni, nem találni szűk keresztmetszeteket, pont azokat a „Brenteket”, amelyekről már beszéltem. Van egy csodálatos könyv Dominica DeGrandistól . Elárulja öt különböző "időszivárgás" (időtolvajok):
- Túl sok munka folyamatban (WIP)
- Ismeretlen függőségek
- Nem tervezett munka
- Ellentmondó prioritások
- Elhanyagolt munka
Ez nagyon értékes elemzés, és a könyv nagyszerű, de ez a tanács hiábavaló, ha az adatoknak csak 50%-a látható. A Dominika által javasolt módszerek 90% feletti pontosság elérése esetén használhatók. Olyan helyzetekről beszélek, amikor egy főnök 15 perces feladatot ad egy beosztottnak, de ez három napig tart; de a főnök nem igazán tudja, hogy ez a beosztott négy-öt másik embertől függ.
A Phoenix Project egy csodálatos történet egy projektről, amely három évet késett. Az egyik szereplőt emiatt elbocsátják, és találkozik egy másik szereplővel, akit Szókratészként mutatnak be. Segít kitalálni, hogy pontosan mi hibázott. Kiderült, hogy a cégnek van egy rendszergazdája, akinek a neve Brent, és minden munka valahogy rajta keresztül megy. Az egyik megbeszélésen megkérdezik az egyik beosztottat: miért tart minden félórás feladat egy hetet? A válasz a sorbanálláselmélet és a Little-törvény nagyon leegyszerűsített bemutatása, és ebből az előadásból kiderül, hogy 90%-os kihasználtság mellett minden munkaóra 9 órát vesz igénybe. Minden feladatot el kell küldeni hét másik személynek, így az óra 63 óra lesz, 7-szer 9. Azt akarom mondani, hogy a Kis Törvény vagy bármilyen összetett sor-elmélet használatához legalább adatokkal kell rendelkeznie.
Tehát amikor a láthatóságról beszélek, akkor nem arra gondolok, hogy minden a képernyőn van, hanem arra, hogy legalább vannak adatok. Amikor megteszik, gyakran kiderül, hogy nagyon sok nem tervezett munka van, amelyet valahogy a Brenthez küldenek, amikor nincs rá szükség. Brent pedig nagyszerű srác, soha nem mond nemet, de senkinek sem mondja el, hogyan végzi a munkáját.
Amikor látható a munka, szépen besorolhatók az adatok (ezt csinálja Dominika a fotón), alkalmazható az öt időszivárgás absztrakciója, és alkalmazható az automatizálás.
2. Munkairányítási rendszerek konszolidálása: Feladatkezelés
Az archetípusok, amelyekről beszélek, egyfajta piramis. Ha az elsőt jól csináltuk, akkor a második már egyfajta kiegészítő. Ezek közül sok nem működik induló vállalkozásoknál, ezeket szem előtt kell tartani a nagyobb cégeknél, mint például a Fortune 5000. Az utolsó cég, ahol dolgoztam, 10 jegyrendszerrel rendelkezett. Az egyik csapatnak volt Remedy, a másik valamiféle saját rendszert írt, a harmadik Jira-t használt, és néhányan megelégedtek az e-mailekkel. Ugyanez a probléma akkor is felmerül, ha a cégnek 30 különböző csővezetéke van, de nincs időm minden ilyen esetet megbeszélni.
Megbeszélem az emberekkel, hogy pontosan hogyan jönnek létre a jegyek, mi történik velük ezután, és hogyan kerülik ki őket. A legérdekesebb az, hogy az emberek a találkozóinkon egészen őszintén beszélnek. Megkérdeztem, hányan helyezik el a „kisebb/nincs hatást” kifejezést olyan jegyekre, amelyeknek ténylegesen „nagy hatást” kellene tulajdonítaniuk. Kiderült, hogy szinte mindenki ezt csinálja. Nem veszek részt feljelentésben, és minden lehetséges módon igyekszem nem azonosítani az embereket. Amikor őszintén bevallnak valamit nekem, nem adom ki az illetőt. De amikor szinte mindenki megkerüli a rendszert, az azt jelenti, hogy minden biztonság alapvetően kirakatrendezés. Ezért ennek a rendszernek az adataiból nem lehet következtetéseket levonni.
A jegyprobléma megoldásához ki kell választania egy fő rendszert. Ha Jira-t használ, tartsa meg Jira-t. Ha van alternatíva, az legyen az egyetlen. A lényeg az, hogy a jegyeket a fejlesztési folyamat egy újabb lépésének kell tekinteni. Minden műveletnek jegyet kell kapnia, aminek át kell haladnia a fejlesztési munkafolyamaton. A jegyeket elküldik a csapatnak, amely felteszi azokat a storyboardra, majd felelősséget vállal értük.
Ez minden részlegre vonatkozik, beleértve az infrastruktúrát és az üzemeltetést is. Ebben az esetben legalább néhány elfogadható elképzelést lehet alkotni a dolgok állásáról. Amint ez a folyamat létrejött, hirtelen könnyűvé válik az egyes alkalmazásokért felelős személyek azonosítása. Mert most az új szolgáltatások nem 50%-át, hanem 98%-át kapjuk. Ha ez az alapfolyamat működik, akkor javul a pontosság az egész rendszerben.
Szolgáltatási csővezeték
Ez megint csak a nagyvállalatokra vonatkozik. Ha Ön egy új cég egy új területen, feltűrje az ingujját, és dolgozzon a Travis CI-vel vagy a CircleCI-vel. Ami a Fortune 5000-es cégeket illeti, egy példa, amely abban a bankban történt, ahol dolgoztam. A Google megkereste őket, és megmutatták nekik a régi IBM rendszerek diagramjait. A Google srácai zavartan kérdezték – hol van ennek a forráskódja? De nincs forráskód, még GUI sem. Ez a valóság, amellyel a nagy szervezeteknek meg kell küzdeniük: 40 éves banki nyilvántartások egy ősi nagyszámítógépen. Az egyik ügyfelem Kubernetes konténereket használ Circuit Breaker mintákkal, plusz Chaos Monkey-t, mindezt a KeyBank alkalmazáshoz. De ezek a tárolók végül egy COBOL alkalmazáshoz csatlakoznak.
A Google srácai teljesen biztosak voltak abban, hogy megoldják az ügyfelem összes problémáját, majd elkezdtek kérdezősködni: mi az az IBM adatcső? Azt mondják nekik: ez egy csatlakozó. Mihez kapcsolódik? A Sperry rendszerhez. És mi az? Stb. Első pillantásra úgy tűnik: milyen DevOp-ok lehetnek? De valójában ez lehetséges. Vannak olyan kézbesítési rendszerek, amelyek lehetővé teszik a munkafolyamat átadását a kézbesítő csapatoknak.
3. A korlátok elmélete: a korlátok elmélete
Térjünk át a harmadik archetípusra: intézményes/"törzsi" tudásra. Általános szabály, hogy minden szervezetben több ember van, aki mindent tud és mindent irányít. Ők azok, akik a leghosszabb ideig vannak a szervezetben, és ismerik az összes lehetséges megoldást.
Amikor ez előkerül a diagramon, az ilyen embereket konkrétan bekarikázom egy jelzővel: például kiderül, hogy egy bizonyos Lou minden találkozón jelen van. És számomra egyértelmű: ez a helyi Brent. Amikor az informatikai igazgató választ a pólós és tornacipős köztem és az öltönyös IBM-es srác között, engem választanak, mert olyan dolgokat mondhatok el a rendezőnek, amiket a másik srác nem mond el, és amit a rendező nem szívesen hallana. . Mondom nekik, hogy a cégük szűk keresztmetszete egy Fred és egy Lou. Ezt a szűk keresztmetszetet fel kell oldani, tudásukat így vagy úgy tőlük kell megszerezni.
Az ilyen jellegű problémák megoldására például a Slack használatát javasolhatom. Egy okos rendező megkérdezi – miért? Jellemzően ilyenkor a DevOps tanácsadók azt válaszolják: mert mindenki ezt csinálja. Ha tényleg okos a rendező, azt mondja: na mi van. És itt véget is ér a párbeszéd. Erre pedig a válaszom: mert négy szűk keresztmetszet van a társaságban, Fred, Lou, Susie és Jane. Tudásuk intézményesítéséhez először be kell vezetni a Slacket. Az összes wikid teljes hülyeség, mert senki sem tud a létezésükről. Ha a mérnöki csapat részt vesz a front-end és back-end fejlesztésben, és mindenkinek tudnia kell, hogy kérdéseivel fordulhat a front-end fejlesztőcsapathoz vagy az infrastruktúra csapatához. Ekkor valószínűleg Lounak vagy Frednek lesz ideje csatlakozni a wikihez. És akkor a Slackben valaki megkérdezheti, hogy mondjuk miért nem működik az 5. lépés, majd Lou vagy Fred kijavítja az utasításokat a wikin. Ha létrehozza ezt a folyamatot, akkor sok minden magától a helyére kerül.
Ez a lényeg: ahhoz, hogy bármilyen csúcstechnológiát ajánlani tudjunk, először rendbe kell tenni az alapot, ez pedig az imént leírt low-tech megoldásokkal tehető meg. Ha a csúcstechnológiákkal kezdi, és nem magyarázza el, miért van rájuk szükség, akkor ennek általában nincs jó vége. Egyik ügyfelünk az Azure ML-t használja, amely egy nagyon olcsó és egyszerű megoldás. Kérdéseik mintegy 30%-ára maga az öntanuló gép adott választ. És ezt a dolgot olyan operátorok írták, akik nem foglalkoztak adattudományokkal, statisztikákkal vagy matematikával. Ez jelentős. Egy ilyen megoldás költsége minimális.
4. Együttműködési hackek: Együttműködési hackek
A negyedik archetípus az elszigeteltség elleni küzdelem szükségessége. A legtöbben már tudják: az elszigeteltség ellenségeskedést szül. Ha minden osztály a saját emeletén van, és az emberek semmilyen módon nem keresztezik egymást, kivéve a liftben, akkor nagyon könnyen támad köztük az ellenségeskedés. De ha éppen ellenkezőleg, az emberek egy szobában vannak egymással, azonnal elmegy. Amikor valaki kidob valami általános vádat, például soha nem működik ilyen-olyan felület, mi sem egyszerűbb egy ilyen vádat dekonstruálni. A felületet készítő programozóknak csak el kell kezdeniük konkrét kérdéseket feltenni, és hamarosan kiderül, hogy például a felhasználó egyszerűen nem megfelelően használta az eszközt.
Az elszigeteltség leküzdésének számos módja van. Egyszer felkértek, hogy konzultáljak egy bankkal Ausztráliában, de nem voltam hajlandó megtenni, mert van két gyermekem és egy feleségem. A segítségükre csak grafikus történetmesélést tudtam ajánlani. Ez olyan dolog, ami bizonyítottan működik. Egy másik érdekes módszer a karcsú kávés találkozók. Nagy szervezetben ez kiváló lehetőség az ismeretterjesztésre. Ezenkívül lebonyolíthat belső devopsday-eket, hackathonokat és így tovább.
5. Edző Kata
Ahogy a legelején figyelmeztettem, erről ma nem beszélek. Ha érdekel, megnézheted .
Ebben a témában is van egy jó beszéd Mike Rothertől:
6. Piacorientált: piacorientált szervezet
Itt különböző problémák vannak. Például "I" emberek, "T" emberek és "E" emberek. Az „én” emberek azok, akik csak egy dolgot csinálnak. Jellemzően elszigetelt részlegekkel rendelkező szervezetekben léteznek. "T" az, amikor egy személy jó egy dologban, de jó néhány másban is. Az "E" vagy akár a "fésű" az, amikor egy személy sok képességgel rendelkezik.
Conway törvénye itt működik (), ami a legegyszerűbben a következőképpen fogalmazható meg: ha három csapat dolgozik a fordítón, akkor az eredmény egy három részből álló fordító lesz. Ezért, ha egy szervezeten belül nagy az elszigeteltség, akkor még a Kubernetes, a Circuit Breaker, az API bővíthetőség és más divatos dolgok is ugyanúgy el lesznek rendezve ebben a szervezetben, mint maga a szervezet. Szigorúan Conway szerint, és minden fiatal geek ellenére.
A probléma megoldását sokszor leírták. Vannak például Fernando Fernandez által leírt szervezeti archetípusok. Az a problémás architektúra, amelyről az imént beszéltem, elszigetelten, egy funkció-orientált architektúra. A második típus a legrosszabb, mátrix architektúra, a másik kettő rendetlensége. A harmadik az, ami a legtöbb startupnál látható, és ehhez a típushoz a nagy cégek is igyekeznek megfelelni. Ez egy piacorientált szervezet. Itt úgy optimalizálunk, hogy a lehető leggyorsabban válaszoljunk az ügyfelek kéréseire. Ezt néha lapos szervezetnek nevezik.
Sokan különbözőképpen írják le ezt a szerkezetet, nekem tetszik a megfogalmazás csapatokat építeni/futtatni, az Amazonnál úgy hívják két pizzacsapat. Ebben a struktúrában minden „I” típusú ember egy szolgáltatás köré csoportosul, és fokozatosan közelebb kerül a „T” típushoz, és megfelelő menedzsment esetén akár „E” is lehet. Az első ellenérv itt az, hogy egy ilyen szerkezetnek vannak szükségtelen elemei. Miért van szükség minden osztályra egy tesztelőre, ha lehet egy speciális tesztelői osztály? Amire azt válaszolom: a többletköltség ebben az esetben az az ára, 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, az architektúrát, a tervezést stb. Ennek eredményeként a szervezet minden résztvevője teljesen tisztában van mindennel, ami a szervezetben történik. Ha tudni szeretné, hogyan működik ez a rendszer az iparban, olvassa el .
7. Műszakos bal oldali auditorok: audit a ciklus korai szakaszában. A kiállított biztonsági szabályok betartása
Ilyenkor a tetteid úgymond nem felelnek meg a szagpróbán. Azok az emberek, akik neked dolgoznak, nem hülyék. Ha a fenti példához hasonlóan mindenhol kisebb/nincs hatást állítottak be, ez három évig tartott, és senki nem vett észre semmit, akkor mindenki jól tudja, hogy a rendszer nem működik. Vagy egy másik példa – egy változási tanácsadó testület, ahol minden, mondjuk szerdán, jelentést kell benyújtani. Dolgozik ott egy embercsoport (egyébként nem túl jól fizetett), akiknek elméletileg tudniuk kellene a rendszer egészének működését. Az elmúlt öt évben pedig valószínűleg észrevette, hogy rendszereink hihetetlenül összetettek. Öt-hat embernek pedig döntést kell hoznia egy olyan változásról, amelyet nem hajtott végre, és amelyről semmit sem tud.
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 érte felelnie. Ellenkező esetben paradox helyzet áll elő, amikor egy menedzser, aki soha életében nem írt kódot, megmondja a programozónak, hogy mennyi ideig kell kódot írni. Az egyik cégnek, amellyel dolgoztam, 7 különböző táblája volt, amelyek minden változást felülvizsgáltak, beleértve az építészeti táblát, a terméktáblát stb. Volt még kötelező várakozási idő is, bár az egyik alkalmazott azt mondta nekem, hogy tíz év munkavégzés alatt még soha senki nem utasította el a személy által ebben a kötelező időszakban végrehajtott változtatást.
A könyvvizsgálókat meg kell hívni, hogy csatlakozzanak hozzánk, és nem szabad megválni tőlük. Mondd meg nekik, hogy megváltoztathatatlan bináris konténereket írsz, amelyek ha minden teszten megfelelnek, örökre megváltoztathatatlanok maradnak. Mondja el nekik, hogy van egy csővezeték kódja, és magyarázza el, hogy ez mit jelent. Mutassa meg nekik a következő sémát: egy megváltoztathatatlan, csak olvasható bináris fájl egy tárolóban, amely minden sebezhetőségi teszten megfelel; és akkor nem csak senki nem nyúl hozzá, de még csak nem is érinti a csővezetéket létrehozó rendszert, hiszen az is dinamikusan jön létre. Vannak ügyfeleim, a Capital One, akik a Vault segítségével hoznak létre valami blokklánchoz hasonlót. Az auditornak nem kell bemutatnia a Chef-től származó „recepteket”, elég a blokkláncot megmutatni, amelyből kiderül, mi történt a gyártásban lévő Jira jeggyel, és ki a felelős érte.
Szerint , amelyet 2018-ban hozott létre a Sonatype, 2017-ben 87 milliárd OSS-letöltési kérelem érkezett.
A sérülékenységek miatt keletkezett veszteségek túl magasak. Ezenkívül a fent látható számadatok nem tartalmazzák az alternatív költségeket. Mi az a DevSecOps dióhéjban? Hadd mondjam el rögtön, hogy nem érdekel, hogy arról beszéljek, mennyire sikeres ez a név. A lényeg az, hogy mivel a DevOps annyira sikeres volt, meg kell próbálnunk biztonságot adni ennek a folyamatnak.
Példa erre a sorozatra:
Ez nem konkrét termékekre vonatkozó ajánlás, bár mindegyiket szeretem. Példaként hoztam fel őket annak bemutatására, hogy a DevOps, amely kezdetben az ipar szervezeti paradigmáján alapult, lehetővé teszi a terméken végzett munka minden szakaszának automatizálását.
És nincs semmi ok, amiért ne tudnánk ugyanazt a megközelítést alkalmazni a biztonság terén.
Teljes
Befejezésül adok néhány tippet a DevSecOps-hoz. Be kell vonnia az auditorokat a rendszerek létrehozásának folyamatába, és időt kell fordítania a képzésükre. Együtt kell működnie a könyvvizsgálókkal. Ezután teljesen kíméletlen harcot kell vívnia a hamis pozitív eredmények ellen. Még a legdrágább sebezhetőség-ellenőrző eszközzel is rendkívül rossz szokásokat alakíthat ki fejlesztői körében, ha nem tudja, mennyi a jel-zaj arány. A fejlesztőket túlterhelik az események, és egyszerűen törölni fogják őket. Ha hallott az Equifax történetről, nagyjából ez történt ott, ahol a legmagasabb riasztási szintet figyelmen kívül hagyták. Ezen túlmenően a sebezhetőségeket úgy kell elmagyarázni, hogy egyértelmű legyen, milyen hatással vannak az üzletre. Például azt mondhatjuk, hogy ez ugyanaz a sebezhetőség, mint az Equifax történetében. A biztonsági réseket ugyanúgy kell kezelni, mint a többi szoftverproblémát, vagyis be kell őket vonni a teljes DevOps folyamatba. Együtt kell dolgozni velük Jira, Kanban stb. A fejlesztőknek nem szabad azt gondolniuk, hogy ezt valaki más fogja megtenni – éppen ellenkezőleg, mindenkinek ezt kell tennie. Végül energiát kell fordítania az emberek képzésére.
Hasznos Linkek
Íme néhány előadás a DevOops konferenciáról, amelyeket hasznosnak találhat:
- Szergej Berdnyikov, Artyom Kalicskin – Sikertörténet, vagy „Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonyid Igolnik - DevOps egy skálán: görög tragédia három felvonásban (, )
- Alekszandr Titov, Kirill Tolkacsov -
- Timothy Lister -
Belenéz DevOops 2020 Moszkva — sok érdekesség is van ott.
Forrás: will.com