D'Fro "wéi devops ëmzesetzen" ass zënter Joere ronderëm, awer et ginn net vill gutt Materialien. Heiansdo fällt Dir Affer vu Reklammen vun net sou schlau Beroder, déi hir Zäit musse verkafen, egal wéi. Heiansdo sinn dës vague, extrem allgemeng Wierder iwwer wéi d'Schëffer vu Megakorporatiounen d'Ausdehnen vum Universum ploen. D'Fro stellt sech: Wat ass eis dat wichteg? Léif Auteur, kënnt Dir Är Iddien kloer an enger Lëscht formuléieren?
All dëst staamt aus der Tatsaach, datt net vill richteg Praxis a Verständnis vum Resultat vun Transformatiounen vun der Gesellschaftskultur accumuléiert sinn. Ännerungen an der Kultur sinn laangfristeg Saachen, d'Resultater vun deenen net an enger Woch oder engem Mount erschéngen. Mir brauchen een al genuch fir ze gesinn wéi Firmen iwwer d'Jore gebaut a gescheitert sinn.
John Willis - ee vun de Pappen vun DevOps. John huet Joerzéngte Erfahrung mat enger grousser Zuel vu Firmen ze schaffen. Viru kuerzem huet de John ugefaang spezifesch Musteren ze bemierken déi stattfannen wann se mat jidderengem vun hinnen schaffen. Mat dësen Archetypen guidéiert de John Firmen op de richtege Wee vun der DevOps Transformatioun. Liest méi iwwer dës Archetypen an der Iwwersetzung vu sengem Bericht vun der DevOops 2018 Konferenz.
Iwwert de Spriecher:
Méi wéi 35 Joer am IT-Gestioun, deelgeholl un der Schafung vum Virgänger vun OpenCloud bei Canonical, huet un 10 Startups deelgeholl, vun deenen zwee un Dell an Docker verkaaft goufen. De Moment ass hien Vizepresident vun DevOps an Digital Practices bei SJ Technologies.
Als nächst ass d'Geschicht aus dem John senger Siicht.
Mäin Numm ass John Willis an déi einfachst Plaz fir mech ze fannen ass op Twitter, . Ech hunn deeselwechten Alias op Gmail a GitHub. A Dir fannt Videoopname vu menge Berichter a Presentatiounen fir si.
Ech hu vill Reuniounen mat CIOs vu verschiddene grousse Firmen. Si beschwéieren ganz dacks datt se net verstinn wat DevOps ass, a jidderee dee probéiert et hinnen z'erklären schwätzt iwwer eppes anescht. Eng aner gemeinsam Plainte ass datt DevOps net funktionnéiert, obwuel et schéngt datt d'Direkteuren alles maachen wéi se hinnen erkläert hunn. Mir schwätzen iwwer grouss Entreprisen, déi méi wéi honnert Joer al sinn. Nodeem ech mat hinne geschwat hunn, sinn ech zur Conclusioun komm, datt fir vill Problemer net héich Technologie am Beschten gëeegent ass, mee relativ low-tech Léisungen. Woche laang hunn ech just mat Leit aus verschiddenen Departementer geschwat. Wat Dir op der alleréischter Foto am Post gesitt ass mäi leschte Projet, sou huet de Raum no dräi Deeg Aarbecht ausgesinn.
Wat ass DevOps?
Tatsächlech, wann Dir 10 verschidde Leit freet, ginn se 10 verschidden Äntwerten. Awer hei ass déi interessant Saach: all zéng vun dësen Äntwerten wäerte richteg sinn. Et gëtt keng falsch Äntwert hei. Ech war zimlech déif an DevOps, fir ongeféier 10 Joer, a war den éischten Amerikaner um éischten DevOpsDay. Ech wäert net soen datt ech méi clever sinn wéi jiddereen, deen un DevOps involvéiert ass, awer et gëtt kaum een deen esou vill Efforte verbruecht huet. Ech gleewen datt DevOps geschitt wann mënschlecht Kapital an Technologie zesummekommen. Mir vergiessen dacks iwwer déi mënschlech Dimensioun, obwuel mir vill iwwer all Zorte vu Kulturen schwätzen.
Elo hu mir vill Daten, fënnef Joer akademesch Fuerschung, Testen vun Theorien op industrieller Skala. Wat dës Studien eis soen ass datt wann Dir e puer Verhalensmuster an enger Organisatiounskultur kombinéiert, kënnt Dir eng 2000x Geschwindegkeet erreechen. Dës Beschleunegung gëtt mat enger gläicher Verbesserung vun der Stabilitéit ugepasst. Dëst ass eng quantitativ Messung vum Virdeel deen DevOps fir all Firma bréngt. Virun e puer Joer hunn ech mam CEO vun enger Firma Fortune 5000 iwwer DevOps geschwat.Wéi ech mech op d'Presentatioun virbereet hunn, war ech ganz nervös, well ech meng Joeren Erfahrung a 5 Minutten hu misse resuméieren.
Zum Schluss hunn ech folgendes ginn Definitioun vun DevOps: Et ass eng Rei vu Praktiken a Musteren déi d'Transformatioun vum mënschleche Kapital an héich performant organisatoresch Kapital erméiglechen. E Beispill ass de Wee wéi Toyota déi lescht 50 oder 60 Joer operéiert huet.
(Déi Diagrammer ginn duerno net als Referenzmaterial, mee als Illustratiounen zur Verfügung gestallt. Hiren Inhalt wäert sech fir all nei Firma ënnerscheeden. Allerdéngs kann d'Bild separat gekuckt a vergréissert ginn
Ee vun den erfollegräichste sou Praktiken ass Wäerter verëffentlechen. Et sinn e puer gutt Bicher doriwwer geschriwwen, déi erfollegräichst vun deene si vum Karen Martin. Awer am leschte Joer sinn ech zur Conclusioun komm, datt och dës Approche ze héich-Tech ass. Et huet sécherlech vill Virdeeler an ech hunn et vill benotzt. Awer wann de CEO Iech freet firwat seng Firma net op nei Schinne ka wiesselen, ass et ze fréi iwwer Wäertstroummapping ze schwätzen. Et gi vill méi fundamental Froen déi als éischt musse beäntwert ginn.
Ech denken, datt de Feeler vill vu menge Kollege maachen ass datt se der Firma einfach e fënnef-Punkte Guide ginn an dann sechs Méint méi spéit zréckkommen a kucken wat geschitt ass. Och e gudde Schema wéi Wäertstroummapping huet, loosst eis soen, blann Flecken. No Honnerte vun Interviewe mat Direktere vu verschiddene Firmen, hunn ech e gewësse Muster entwéckelt, deen eis erlaabt de Problem a seng Komponenten opzedeelen, an elo wäerte mir all eenzel vun dëse Komponenten an Uerdnung diskutéieren. Ier Dir all technologesch Léisunge benotzt, benotzen ech dëst Muster, an als Resultat sinn all meng Maueren mat Diagrammer bedeckt. Viru kuerzem hunn ech mat engem géigesäitege Fong geschafft an ech hunn 100-150 esou Schemaen opgehalen.
Schlecht Kultur ësst gutt Approche fir Frühstück
D'Haaptidee ass dëst: kee Betrag vu Lean, Agile, SAFE an DevOps hëlleft wann d'Kultur vun der Organisatioun selwer schlecht ass. Et ass wéi Tauchen an Déiften ouni Scuba-Ausrüstung oder ouni Röntgen ze bedreiwen. An anere Wierder, fir Drucker an Deming ze paraphraséieren: eng schlecht Organisatiounskultur wäert all gudde System schlucken ouni drun ze erstécken.
Fir dësen Haaptproblem ze léisen, musst Dir déi folgend Schrëtt huelen:
- Maacht all Aarbecht siichtbar: Dir musst all Aarbecht siichtbar maachen. Net am Sënn datt et onbedéngt op engem Écran muss ugewise ginn, mee am Sënn datt et observéierbar muss sinn.
- Consolidated Work Management Systems: Management Systemer musse konsolidéiert ginn. Am Problem vum "Stam-Wëssen" an dem institutionelle Wëssen sinn an 9 Fäll vun 10 de Fläschenhals Leit. Am Buch de Problem war mat enger eenzeger Persoun, Brent, deen de Projet dräi Joer hannert dem Zäitplang verursaacht huet. An ech lafen iwwerall op dës "Brents". Fir dës Flaschenhals ze léisen, benotzen ech déi nächst zwee Elementer op eiser Lëscht.
- Theory of Constraints Methodologie: Theorie vun Aschränkungen.
- Zesummenaarbecht Hacks: Zesummenaarbecht Hacks.
- Toyota Kata (): Ech wäert net vill iwwer Toyota Kata schwätzen. Wann interesséiert, op mengem Github op bal all eenzel vun dësen Themen.
- Maartorientéiert Organisatioun: Maart-orientéiert Organisatioun.
- Verréckelung lénks Auditeuren: Audit an de fréie Stadien vum Zyklus.
Ech fänken un mat enger Organisatioun ganz einfach ze schaffen: Ech ginn an d'Firma a schwätze mat de Mataarbechter. Wéi Dir kënnt gesinn, keng héich Technologie. Alles wat Dir braucht ass eppes fir ze schreiwen. Ech sammelen e puer Teams an engem Zëmmer an analyséieren wat se mir soen aus der Perspektiv vu menge 7 Archetypen. An da ginn ech hinnen e Marker selwer a froen hinnen alles op de Tafel ze schreiwen wat se bis elo haart gesot hunn. Normalerweis gëtt et bei esou Versammlungen eng Persoun déi alles opschreift, an am beschten kann hien 10% vun der Diskussioun opschreiwen. Mat menger Method kann dës Figur op ongeféier 40% eropgesat ginn.
(Dës Illustratioun kann separat gekuckt ginn )
Meng Approche baséiert op der Aarbecht vum William Schneider. ). D'Approche baséiert op der Iddi datt all Organisatioun a véier Quadrat opgedeelt ka ginn. Dëse Schema fir mech ass normalerweis d'Resultat vun der Aarbecht mat deenen Honnerte vun anere Schemaen déi entstinn wann Dir eng Organisatioun analyséiert. Ugeholl, mir hunn eng Organisatioun mat engem héije Kontrollniveau, awer mat enger gerénger Kompetenz. Dëst ass eng extrem ongewollte Optioun: wann jiddereen op d'Linn geet, awer kee weess wat ze maachen.
Eng e bësse besser Optioun ass eng mat engem héije Niveau vu Kontroll a Kompetenz. Wann esou eng Firma rentabel ass, da brauch se vläicht net DevOps. Et ass am meeschten interessant mat enger Firma ze schaffen, déi en héije Niveau vu Kontroll, niddereg Kompetenz a Kooperatioun huet, awer gläichzäiteg en héije Kulturniveau (Kultivatioun). Dat heescht, datt d'Firma vill Leit huet, déi gär do schaffen an den Ëmsaz vun Aarbechtsmaart ass niddereg.
(Dës Illustratioun kann separat gekuckt ginn )
Et schéngt mir datt Methode mat steife Richtlinnen am Wee kommen fir d'Wourecht z'erreechen. Besonnesch a Wäertstroummapping ginn et vill Reegelen iwwer wéi d'Informatioun soll strukturéiert ginn. An de fréie Stadien vun der Aarbecht, iwwer déi ech elo schwätzen, brauch keen dës Regelen. Wann eng Persoun mat engem Markéierer an den Hänn déi richteg Situatioun an der Firma um Bord beschreift, ass dat de beschte Wee fir den Zoustand vun Affären ze verstoen. Esou Informatioun erreecht net Direktere. Zu dësem Moment ass et domm fir d'Persoun z'ënnerbriechen an ze soen datt hien eng Aart Pfeil falsch gezeechent huet. Op dëser Etapp ass et besser einfach Reegelen ze benotzen, zum Beispill: Multi-Level Abstraktioun kann einfach erstallt ginn andeems Dir Multi-faarweg Marker benotzt.
Ech widderhuelen, keng héich Technologie. De schwaarze Marker weist déi objektiv Realitéit wéi alles funktionnéiert. Mat engem roude Markéierer markéieren d'Leit wat se net gär hunn iwwer den aktuellen Zoustand. Et ass wichteg datt se dat schreiwen, net ech. Wann ech no enger Versammlung bei den CIO ginn, bidden ech keng Lëscht vun 10 Saachen un, déi musse fixéiert ginn. Ech striewen Verbindungen ze fannen tëscht deem wat d'Leit an der Firma soen an existent bewisen Musteren. Schlussendlech proposéiert e bloe Marker méiglech Léisunge fir de Problem.
(Dës Illustratioun kann separat gekuckt ginn )
E Beispill vun dëser Approche ass elo uewen duergestallt. Am Ufank vun dësem Joer hunn ech mat enger Bank geschafft. D'Sécherheetsleit do waren iwwerzeegt datt se net sollten op Design a Fuerderungsbewäertunge kommen.
(Dës Illustratioun kann separat gekuckt ginn )
An dunn hu mir mat Leit aus aneren Departementer geschwat an et huet sech erausgestallt, datt virun ongeféier 8 Joer Software-Entwéckler Sécherheetsaarbechter entlooss hunn, well se d'Aarbecht verlangsamen. An dunn gouf et zu engem Verbuet, dee selbstverständlech geholl gouf. Och wann et an der Realitéit kee Verbuet gouf.
Eis Versammlung ass extrem konfus verlaf: ongeféier dräi Stonne laang konnte fënnef verschidden Teams mir net erklären wat tëscht dem Code an der Assemblée geschitt ass. An dëst schéngt déi einfachst Saach ze sinn. Déi meescht DevOps Beroder huelen un datt jidderee dëst scho weess.
Dunn ass de Responsabele vun der IT-Governance, dee 4 Stonne roueg war, op eemol op d'Liewe komm, wéi mir op säin Thema ukomm sinn, an huet eis ganz laang besat. Um Enn hunn ech him gefrot wat hien iwwer d'Versammlung denkt, an ech wäert seng Äntwert ni vergiessen. Hien huet gesot: "Ech hu fréier geduecht datt eis Bank nëmmen zwee Weeër fir Software ze liwweren, awer elo weess ech datt et fënnef vun hinnen sinn, an ech wousst net emol iwwer dräi."
(Dës Illustratioun kann separat gekuckt ginn )
Déi lescht Versammlung bei dëser Bank war mat der Investitiounssoftware Team. Et war mat hir datt et erausgestallt huet datt d'Schreiwen vun Diagrammer mat engem Marker op engem Blat Pabeier besser ass wéi op engem Board, an och besser wéi op engem Smartboard.
D'Fotoen, déi Dir gesitt, sinn wéi den Hotelkonferenzraum de véierten Dag vun eiser Versammlung ausgesinn huet. A mir hunn dës Schemaen benotzt fir no Musteren ze sichen, dat heescht Archetypen.
Also, ech stellen d'Aarbechter Froen, si schreiwen d'Äntwerten mat Markéierer vun dräi Faarwen (schwaarz, rout a blo). Ech analyséieren hir Äntwerten fir Archetypen. Loosst eis elo all d'Archetypen an Uerdnung diskutéieren.
1. Maachen All Aarbecht siichtbar: Maachen Aarbecht siichtbar
Déi meescht Firmen mat deenen ech schaffen hunn e ganz héije Prozentsaz vun onbekannter Aarbecht. Zum Beispill, wann een Employé bei en aneren kënnt an einfach freet eppes ze maachen. A groussen Organisatiounen kann et 60% ongeplangt Aarbecht sinn. A bis zu 40% vun der Aarbecht ass op keng Manéier dokumentéiert. Wann et Boeing wier, géif ech a mengem Liewen ni méi op hirem Fliger klammen. Wann nëmmen d'Halschent vun der Aarbecht dokumentéiert ass, ass et net gewosst ob dës Aarbecht richteg gemaach gëtt oder net. All aner Methoden ginn nëtzlos - et ass kee Sënn fir eppes ze automatiséieren, well déi bekannt 50% kënnen dee kohärentsten a kloersten Deel vun der Aarbecht sinn, d'Automatiséierung vun deenen net super Resultater gëtt, an dat Schlëmmst. Saachen sinn an der onsichtbarer Halschent. An der Verontreiung vun Dokumentatioun ass et onméiglech all Zorte vu Hacks a verstoppt Aarbecht ze fannen, net Flaschenhals ze fannen, déi ganz "Brents", déi ech scho geschwat hunn. Et gëtt e wonnerschéint Buch vum Dominica DeGrandis . Si verréid fënnef verschidde "Zäitlecks" (Zäitdéif):
- Ze vill Aarbecht am Prozess (WIP)
- Onbekannt Ofhängegkeeten
- Onplangt Aarbecht
- Konflikt Prioritéiten
- Vernoléissegt Aarbecht
Dëst ass ganz wäertvoll Analyse an d'Buch ass super, awer all dës Berodung ass nëtzlos wann nëmmen 50% vun den Daten sichtbar sinn. D'Methoden proposéiert vun Dominica kënne benotzt ginn wann eng Genauegkeet vun iwwer 90% erreecht gëtt. Ech schwätzen iwwer Situatiounen, wou e Chef engem Ënneruerdnung eng 15-Minutt Aufgab gëtt, mä et dauert him dräi Deeg; mä de Patron weess net wierklech datt dës Ënneruerdnung vu véier oder fënnef anere Leit ofhängeg ass.
De Phoenix Project ass eng wonnerbar Geschicht iwwer e Projet deen dräi Joer ze spéit war. Ee vun de Personnagen konfrontéiert Entloossung dowéinst, an hie begéint en anere Charakter, deen als eng Zort Sokrates presentéiert gëtt. Hien hëlleft erauszefannen wat genee falsch gaang ass. Et stellt sech eraus datt d'Firma ee Systemadministrator huet, deem säin Numm Brent ass, an all Aarbecht geet iergendwéi duerch hien. Op enger vun de Reunioune gëtt ee vun den Ënneruertere gefrot: Firwat dauert all hallef Stonn Aufgab eng Woch? D'Äntwert ass eng ganz vereinfacht Presentatioun vun der Schlaangtheorie an dem Little säi Gesetz, an an dëser Presentatioun stellt sech eraus datt bei 90% Besetzung all Stonn Aarbecht 9 Stonnen dauert. All Aufgab muss siwen aner Leit geschéckt ginn, sou datt Stonn gëtt 63 Stonnen, 7 Mol 9. De Punkt ech maachen ass, datt fir Little's Law oder all komplex Schlaangen Theorie ze benotzen, Dir musst op d'mannst Daten hunn.
Also wann ech iwwer Visibilitéit schwätzen, mengen ech net datt alles um Bildschierm ass, mee datt Dir op d'mannst Daten hutt. Wann se et maachen, stellt sech dacks eraus datt et eng ganz grouss Quantitéit un ongeplangten Aarbecht ass, déi iergendwéi op Brent geschéckt gëtt wann et net néideg ass. An de Brent ass e super Guy, hie wäert ni nee soen, awer hie seet kee wéi hien seng Aarbecht mécht.
Wann d'Aarbecht sichtbar ass, kënnen d'Donnéeën ordentlech klasséiert ginn (dat ass wat d'Dominika op der Foto mécht), d'Abstraktioun vun de fënnef Zäitleck kann applizéiert ginn, an d'Automatisatioun kann ugewannt ginn.
2. Consolidéieren Aarbecht Management Systemer: Aufgab Management
D'Archetypen, vun deenen ech schwätzen, sinn eng Zort Pyramid. Wann déi éischt richteg gemaach ass, dann ass déi zweet schonn eng Zort Add-on. Vill vun dësen funktionnéieren net fir Startups, si mussen am Kapp behalen ginn fir gréisser Firmen wéi de Fortune 5000. Déi lescht Firma, fir déi ech geschafft hunn, hat 10 Ticketsystemer. Een Team hat Remedy, en anert huet eng Aart vu sengem eegene System geschriwwen, en Drëttel huet Jira benotzt, an e puer hu sech mat E-Mail gemaach. Dee selwechte Problem entsteet wann d'Firma 30 verschidde Pipelines huet, awer ech hu keng Zäit fir all esou Fäll ze diskutéieren.
Ech diskutéiere mat de Leit genee wéi Tickete geschaf ginn, wat mat hinnen geschitt a wéi se ëmgoen. Déi interessantst Saach ass datt d'Leit op eise Versammlungen ganz oprecht schwätzen. Ech hu gefrot wéivill Leit "Kleng / keen Impakt" op Ticketen setzen, déi eigentlech "grouss Impakt" solle kréien. Et huet sech erausgestallt datt bal jiddereen dëst mécht. Ech engagéieren net an Dénonciatioun a probéieren op all méiglech Manéier Leit net ze identifizéieren. Wann se mir éierlech eppes zouginn, ginn ech der Persoun net ewech. Awer wann bal jiddereen de System ëmgeet, heescht et datt all Sécherheet am Wesentlechen Fënsterkleedung ass. Dofir kënne keng Conclusiounen aus den Daten vun dësem System gezunn ginn.
Fir e léisen der Ticket Problem, Dir musst eent Haaptrei System wielen. Wann Dir Jira benotzt, halen et Jira. Wann et eng Alternativ ass, loosst et déi eenzeg sinn. Déi ënnescht Linn ass datt d'Tickete sollten als en anere Schrëtt am Entwécklungsprozess ugesi ginn. All Aktioun muss en Ticket hunn, deen duerch den Entwécklungsworkflow muss fléissen. D'Tickete ginn un d'Equipe geschéckt, déi se op de Storyboard posten an dann d'Verantwortung dofir iwwerhëlt.
Dëst gëllt fir all Departementer, dorënner Infrastruktur an Operatiounen. An dësem Fall ass et méiglech op d'mannst eng plausibel Iddi vum Zoustand vun Affären ze bilden. Wann dëse Prozess etabléiert ass, gëtt et op eemol einfach ze identifizéieren wien fir all Applikatioun verantwortlech ass. Well mir kréien elo net 50%, mä 98% vun neie Servicer. Wann dëse Kärprozess funktionnéiert, da verbessert d'Genauegkeet am ganze System.
Servicer Pipeline
Dëst gëllt erëm nëmme fir grouss Konzerner. Wann Dir eng nei Firma an engem neie Beräich sidd, rullt Är Ärmelen op a schafft mat Ärem Travis CI oder CircleCI. Wann et ëm Fortune 5000 Firmen kënnt, e Fall deen op der Bank geschitt ass wou ech geschafft hunn. Google ass bei hinnen komm a si goufen Diagrammer vun alen IBM Systemer gewisen. D'Leit vu Google hunn duerchernee gefrot - wou ass de Quellcode fir dëst? Awer et gëtt kee Quellcode, net emol e GUI. Dëst ass d'Realitéit mat där grouss Organisatiounen ze dinn hunn: 40 Joer al Bankrecords op engem antike Mainframe. Ee vun mengen Clienten benotzt Kubernetes Container mat Circuit Breaker Musteren, plus Chaos Monkey, alles fir d'KeyBank Applikatioun. Awer dës Container verbannen schlussendlech mat enger COBOL Applikatioun.
D'Jongen vu Google ware ganz zouversiichtlech datt se all d'Problemer vu mengem Client léisen, an dunn hunn se ugefaang Froen ze stellen: wat ass IBM Datapipe? Si ginn gesot: dëst ass e Stecker. Mat wat verbënnt et? An de Sperry System. A wat ass dat? A sou weider. Op den éischte Bléck schéngt et: wéi eng Zort DevOps kann et sinn? Awer tatsächlech ass et méiglech. Et gi Liwwersystemer déi Iech erlaben de Workflow un d'Liwwerteams ze iwwerginn.
3. Theorie vun Constraints: Theorie vun Constraints
Komme mer op den drëtten Archetyp: institutionell/"Stammekenntnisser". Als Regel, an all Organisatioun ginn et e puer Leit, déi alles wëssen an alles verwalten. Dëst sinn déi, déi am längsten an der Organisatioun waren an déi all d'Léisungen kennen.
Wann dat op den Diagramm kënnt, kreien ech esou Leit speziell mat engem Marker: et stellt sech zum Beispill eraus datt e gewësse Lou op all Versammlungen dobäi ass. An et ass fir mech kloer: dëst ass de lokale Brent. Wann den CIO tëscht mir an engem T-Shirt an Turnschueder an dem Typ vun IBM an engem Kostüm wielt, ginn ech gewielt well ech dem Direkter Saachen soen kann déi deen aneren net erzielt an déi den Direkter vläicht net gären héieren . Ech soen hinnen, datt de Flaschenhals an hirer Firma een ass, deen de Fred an de Lou genannt gëtt. Dëse Flaschenhals muss ofgeschaaft ginn, hiert Wësse muss op déi eng oder aner Manéier vun hinne kritt ginn.
Fir dës Zort vu Problem ze léisen, kann ech zum Beispill proposéieren Slack ze benotzen. E Smart Regisseur wäert froen - firwat? Typesch, an esou Fäll, äntweren DevOps Consultants: well jidderee mécht et. Wann de Regisseur wierklech schlau ass, seet hien: Also wat. An do hält den Dialog op. A meng Äntwert op dëst ass: well et véier Flaschenhals an der Firma sinn, Fred, Lou, Susie a Jane. Fir hiert Wëssen ze institutionaliséieren, muss een als éischt Slack aféieren. All Är Wikien si komplett Blödsinn, well kee weess iwwer hir Existenz. Wann d'Ingenieurteam an der Front-End- a Back-End Entwécklung involvéiert ass a jidderee muss wëssen datt se d'Front-End Entwécklungsteam oder d'Infrastrukturteam mat Froen kontaktéiere kënnen. Da wäerten de Lou oder de Fred wuel Zäit hunn fir op d'Wiki ze kommen. An dann am Slack kéint ee froen, firwat, zum Beispill, de Schrëtt 5 net funktionnéiert.An da korrigéieren de Lou oder de Fred d'Instruktiounen op der Wiki. Wann Dir dëse Prozess feststellt, da falen vill Saachen op hir eegen Plaz.
Dëst ass mäin Haaptpunkt: fir all High-Technologien ze recommandéieren, musst Dir fir d'éischt d'Fundament fir se an Uerdnung setzen, an dëst kann mat de just beschriwwene Low-Tech-Léisungen gemaach ginn. Wann Dir mat héijer Technologien unzefänken an net erkläre firwat se gebraucht ginn, dann ass et normalerweis net gutt. Ee vun eise Clienten benotzt Azure ML, eng ganz bëlleg an einfach Léisung. Ongeféier 30% vun hire Froen goufe vun der Selbstléiermaschinn selwer geäntwert. An dës Saach gouf vun Opérateuren geschriwwen, déi net an der Datewëssenschaft, Statistik oder Mathematik involvéiert waren. Dëst ass bedeitend. D'Käschte vun esou enger Léisung ass minimal.
4. Zesummenaarbecht Hacks: Zesummenaarbecht Hacks
De véierten Archetyp ass de Besoin fir Isolatioun ze bekämpfen. Déi meescht Leit wëssen dat schonn: Isolatioun bréngt Feindlechkeet. Wann all Departement op sengem eegene Stack ass, an d'Leit sech op keng Manéier matenee kräizen, ausser am Lift, da entsteet d'Feindlechkeet tëscht hinnen ganz einfach. Awer wann, am Géigendeel, d'Leit am selwechte Raum matenee sinn, da geet se direkt. Wann een eng allgemeng Uklo erausgeet, zum Beispill, esou an esou en Interface funktionnéiert ni, gëtt et näischt méi einfach fir esou eng Uklo ze dekonstruéieren. D'Programméierer, déi d'Interface geschriwwen hunn, musse just ufänken spezifesch Froen ze stellen, an et wäert séier kloer ginn datt zum Beispill de Benotzer einfach d'Tool falsch benotzt huet.
Et gi vill Weeër fir Isolatioun ze iwwerwannen. Ech war eemol gefrot fir eng Bank an Australien ze consultéieren, mee ech refuséiert et ze maachen well ech zwee Kanner an eng Fra hunn. Alles wat ech maache konnt fir hinnen ze hëllefen war grafesch Erzielung ze recommandéieren. Dëst ass eppes wat bewisen ass ze schaffen. Eng aner interessant Manéier ass schlank Kaffi Reuniounen. An enger grousser Organisatioun ass dëst eng exzellent Optioun fir Wëssen ze verbreeden. Zousätzlech kënnt Dir intern Devopsdays, Hackathons, asw.
5. Coaching Kata
Wéi ech am Ufank gewarnt hunn, wäert ech haut net doriwwer schwätzen. Wann Dir interesséiert sidd, kënnt Dir kucken .
Et gëtt och e gutt Gespréich iwwer dëst Thema vum Mike Rother:
6. Maart orientéiert: Maart-konzentréiert Organisatioun
Et gi verschidde Problemer hei. Zum Beispill, "I" Leit, "T" Leit an "E" Leit. "Ech" Leit sinn déi, déi nëmmen eng Saach maachen. Typesch existéieren se an Organisatiounen mat isoléierten Departementer. "T" ass wann eng Persoun gutt ass an enger Saach awer och gutt an e puer aner Saachen. "E" oder souguer "comb" ass wann eng Persoun vill Fäegkeeten huet.
Dem Conway säi Gesetz funktionnéiert hei (), déi an der vereinfachtster Form wéi follegt kann uginn: Wann dräi Teams um Compiler schaffen, da gëtt d'Resultat e Compiler vun dräi Deeler. Dofir, wann et en héijen Niveau vun Isolatioun bannent enger Organisatioun ass, da ginn och Kubernetes, Circuit Breaker, API Extensibilitéit an aner flott Saachen an dëser Organisatioun op déiselwecht Manéier arrangéiert wéi d'Organisatioun selwer. Streng no Conway an trotz all dir jonk Geeks.
D'Léisung fir dëse Problem ass vill Mol beschriwwe ginn. Et ginn zum Beispill organisatoresch Archetypen beschriwwen vum Fernando Fernandez. Déi problematesch Architektur, iwwer déi ech grad geschwat hunn, mat Isolatioun, ass eng Funktiounsorientéiert Architektur. Déi zweet Zort ass déi schlëmmst, Matrixarchitektur, e Chaos vun deenen aneren zwee. Déi drëtt ass wat an de meeschte Startups gesi gëtt, a grouss Firme probéieren och dës Zort ze passen. Et ass eng Maartorientéiert Organisatioun. Hei optiméiere mir fir déi schnellsten Äntwert op Clientsufroen z'erreechen. Dëst gëtt heiansdo eng flaach Organisatioun genannt.
Vill Leit beschreiwen dës Struktur op verschidde Manéieren, ech hunn d'Formuléierung gär bauen / lafen Équipen, bei Amazon nennen se et zwou Pizza-Equipen. An dëser Struktur sinn all Typ "I" Leit ronderëm ee Service gruppéiert, a lues a lues ginn se méi no un den Typ "T", a wann déi richteg Gestioun op der Plaz ass, kënne se souguer "E" ginn. Dat éischt Géigeargument hei ass datt esou eng Struktur onnéideg Elementer huet. Firwat braucht Dir en Tester an all Departement wann Dir e speziellen Departement vun Tester hutt? Op déi ech äntweren: déi extra Käschten an dësem Fall sinn de Präis fir déi ganz Organisatioun fir an Zukunft Typ "E" ze ginn. An dëser Struktur léiert den Tester lues a lues iwwer Netzwierker, Architektur, Design, asw. Als Resultat ass all Participant an der Organisatioun ganz bewosst iwwer alles wat an der Organisatioun geschitt. Wann Dir wësse wëllt wéi dëst Schema an der Industrie funktionnéiert, liest .
7. Verréckelung-lénks Auditeuren: Audit fréi am Zyklus. Konformitéit mat Sécherheetsregelen um Display
Dëst ass wann Är Handlungen de Gerochtest net passéieren, souzesoen. Déi Leit, déi fir Iech schaffen, sinn net domm. Wa se, wéi am Beispill hei uewen, iwwerall klengen/keng Impakt setzen, dat huet dräi Joer gedauert, a keen huet eppes gemierkt, da weess jidderee ganz gutt, datt de System net funktionnéiert. Oder en anert Beispill - e Changement Advisory Board, wou Rapporte mussen all, soen, Mëttwoch, agereecht ginn. Do schafft eng Grupp vu Leit (iwwregens net ganz gutt bezuelt), déi an der Theorie solle wëssen, wéi de System als Ganzt funktionéiert. An an de leschte fënnef Joer hutt Dir wahrscheinlech gemierkt datt eis Systemer onheemlech komplex sinn. A fënnef oder sechs Leit mussen eng Decisioun huelen iwwer eng Ännerung, déi se net gemaach hunn an iwwer déi se näischt wëssen.
Natierlech funktionnéiert dës Approche net. Ech muss esou Saachen lass ginn, well dës Leit de System net schützen. D'Decisioun muss vun der Equipe selwer getraff ginn, well d'Equipe muss dofir verantwortlech sinn. Soss entsteet eng paradoxal Situatioun, wann e Manager, deen nach ni a sengem Liewen Code geschriwwen huet, dem Programméierer seet wéi laang et dauert fir Code ze schreiwen. Eng Firma, mat där ech geschafft hunn, hat 7 verschidde Brieder, déi all Ännerung iwwerpréift hunn, dorënner eng Architekturplat, e Produktbrett, asw. Et gouf souguer eng obligatoresch Waardezäit, obwuel een Employé mir gesot huet, datt an zéng Joer Aarbecht ni eng Ännerung vun dëser Persoun während dëser obligatorescher Period refuséiert huet.
Auditeure mussen invitéiert ginn fir matzemaachen, an net vun hinnen lass ze ginn. Sot hinnen datt Dir onverännerbar binär Behälter schreift déi, wa se all Tester passéieren, fir ëmmer onverännerbar bleiwen. Sot hinnen datt Dir eng Pipeline als Code hutt an erklärt wat dat heescht. Weist hinnen de folgende Schema: eng onverännerbar Lies-nëmme Binär an engem Container deen all Schwachstelle Tester passéiert; an dann net nëmme kee beréiert et, si beréieren net emol de System deen d'Pipeline erstellt, well se och dynamesch erstallt gëtt. Ech hu Clienten, Capital One, déi Vault benotze fir eppes wéi e Blockchain ze kreéieren. Den Auditeur brauch net "Rezepter" vum Chef ze weisen; et ass genuch fir de Blockchain ze weisen, aus deem et kloer ass wat mam Jira Ticket an der Produktioun geschitt ass a wien dofir verantwortlech ass.
Nëmmen , erstallt am 2018 vum Sonatype, goufen et 2017 Milliarden OSS Download-Ufroen am Joer 87.
D'Verloschter, déi duerch Schwachstelle entstinn, sinn verbueden. Ausserdeem enthalen d'Zuelen, déi Dir elo hei uewen gesitt, keng Opportunitéitskäschte. Wat ass DevSecOps an enger Nossschuel? Loosst mech direkt soen datt ech net interesséiert sinn ze schwätzen iwwer wéi erfollegräich dësen Numm ass. De Punkt ass datt zënter datt DevOps sou erfollegräich war, sollte mir probéieren d'Sécherheet un dës Pipeline ze addéieren.
E Beispill vun dëser Sequenz:
Dëst ass keng Empfehlung fir spezifesch Produkter, obwuel ech se all gär hunn. Ech hunn se als Beispill zitéiert fir ze weisen datt DevOps, deen am Ufank op dem organisatoresche Paradigma an der Industrie baséiert, erlaabt Iech all Etapp vun der Aarbecht op engem Produkt ze automatiséieren.
An et gëtt kee Grond firwat mir net déi selwecht Approche fir Sécherheet kéinte huelen.
D 'Resultat
Als Conclusioun ginn ech e puer Tipps fir DevSecOps. Dir musst Auditeuren am Prozess vun der Schafung vun Äre Systemer enthalen an Zäit verbréngen fir se ze educéieren. Dir musst mat Auditeuren kooperéieren. Als nächst musst Dir en absolut ruthless Kampf géint falsch Positiver féieren. Och mam deierste Schwachstelle Scannen Tool, kënnt Dir schlussendlech extrem schlecht Gewunnechten ënner Ären Entwéckler kreéieren wann Dir net wësst wat Äre Signal-to-Geräusche Verhältnis ass. D'Entwéckler wäerte mat Eventer iwwerwältegt ginn a se einfach läschen. Wann Dir iwwer d'Equifax Geschicht héieren hutt, ass dat zimlech wat do geschitt ass, wou den héchsten Alarmniveau ignoréiert gouf. Zousätzlech musse Schwachstelle op eng Manéier erkläert ginn, déi kloer mécht wéi se d'Geschäft beaflossen. Zum Beispill kënnt Dir soen datt dëst déiselwecht Schwachstelle ass wéi an der Equifax Geschicht. Sécherheetsschwieregkeeten sollten d'selwecht behandelt ginn wéi aner Softwareprobleemer, dat heescht, se sollten am Gesamt DevOps Prozess abegraff sinn. Dir musst mat hinnen duerch Jira, Kanban, etc. D'Entwéckler sollen net denken datt een aneren dëst wäert maachen - am Géigendeel, jidderee soll dat maachen. Endlech musst Dir Energie verbréngen fir Leit ze trainéieren.
Nëtzlech Adressen
Hei sinn e puer Gespréicher vun der DevOops Konferenz déi Dir nëtzlech fannt:
- Sergey Berdnikov, Artyom Kalichkin - Erfollegsgeschicht, oder "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps op enger Skala: eng griichesch Tragedie an dräi Akten (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Kuck an DevOops 2020 Moskau - do sinn och vill interessant Saachen.
Source: will.com