Get best of the week

Sieben DevOps-Transformations-Archetypen

Die Frage "wie man einen Devopae implementiert" ist nicht das erste Jahr, aber es gibt nicht so viele gute Materialien. Manchmal werden Sie Opfer von Werbung, nicht sehr kluge Berater, die ihre Zeit verkaufen müssen, egal wie. Manchmal sind dies trübe, äußerst allgemeine Worte darüber, wie Schiffe von Megakonzernen die Weiten des Universums pflügen. Es stellt sich die Frage: Was ist mit uns? Lieber Autor, können Sie Ihre Ideen mit einer Liste klar formulieren?

All dies ergibt sich aus der Tatsache, dass es nicht viel akkumulierte reale Praxis und Verständnis für das Ergebnis der Transformationen der Unternehmenskultur gibt. Veränderungen in der Kultur sind langwierige Dinge, deren Ergebnisse nicht in einer Woche und nicht in einem Monat erscheinen werden. Wir brauchen jemanden, der alt genug ist, um zu sehen, wie Unternehmen im Laufe der Jahre gegründet wurden und zusammenbrachen.



John Willis- Einer der Väter von DevOps. Hinter John - Dutzende Jahre Arbeit mit einer Vielzahl von Unternehmen. Vor kurzem bemerkte John für sich bestimmte Muster, die bei der Arbeit mit jedem von ihnen auftreten. Mit diesen Archetypen führt John Unternehmen auf den wahren Weg der DevOps-Transformation. Lesen Sie mehr über diese Archetypen in der Übersetzung seines Berichts von der DevOops 2018-Konferenz.



Über den Redner:

Über 35 Jahre im IT-Management, beteiligt an der Entwicklung des Vorgängers von OpenCloud in Canonical, nahmen an 10 Startups teil, von denen zwei von Dell und Docker verkauft wurden. Derzeit ist er Vice President für DevOps und Digital Practices bei SJ Technologies.

Als nächstes folgt die Erzählung im Namen von John.

Mein Name ist John Willis und der einfachste Weg, mich auf Twitter zu finden, ist @botchagalupe . Ich habe den gleichen Alias ​​für Google Mail und GitHub. Und unter diesem Link finden Sie Videos meiner Berichte und Präsentationen.

Ich habe viele Treffen mit CIOs verschiedener großer Unternehmen. Sie beschweren sich sehr oft, dass sie nicht verstehen, was DevOps ist, und jeder, der versucht, es ihnen zu erklären, spricht über etwas anderes. Eine weitere häufige Beschwerde ist, dass DevOps nicht funktioniert, obwohl die Direktoren anscheinend alles tun, was ihnen erklärt wurde. Wir sprechen von großen Unternehmen, die über hundert Jahre alt sind. Nachdem ich mit ihnen gesprochen hatte, kam ich zu dem Schluss, dass für viele Probleme keine Hochtechnologien, sondern relativ Low-Tech-Lösungen am besten geeignet sind. Wochenlang habe ich mich nur mit Leuten aus verschiedenen Abteilungen unterhalten. Was Sie auf dem ersten Bild in der Post sehen, ist mein letztes Projekt. Der Raum sah nach drei Arbeitstagen so aus.

Was ist DevOps?


Wenn Sie 10 verschiedene Personen fragen, geben diese 10 verschiedene Antworten. Aber was interessant ist: Alle diese zehn Antworten werden richtig sein. Hier gibt es keine falsche Antwort. Ich habe DevOps ziemlich gründlich studiert, ungefähr 10 Jahre lang war ich der erste Amerikaner am ersten DevOpsDay. Ich werde nicht sagen, dass ich schlauer bin als alle, die an DevOps beteiligt sind, aber es gibt kaum jemanden, der sich so viel Mühe gegeben hat. Ich glaube, dass DevOps entsteht, wenn Humankapital und Technologie kombiniert werden. Wir vergessen oft die menschliche Dimension, obwohl wir viel über alle Arten von Kulturen sprechen.



Jetzt haben wir viele Daten, fünf Jahre akademische Forschung, die Überprüfung von Theorien wurde im industriellen Maßstab etabliert. Diese Studien sagen uns Folgendes: Wenn Sie einige Verhaltensmuster in einer Organisationskultur kombinieren, können Sie eine 2000-fache Beschleunigung erzielen. Diese Beschleunigung entspricht der gleichen Verbesserung der Stabilität. Dies ist eine quantitative Messung der Vorteile, die DevOps jedem Unternehmen bringen kann. Vor ein paar Jahren sprach ich mit einem Fortune 5000-CEO über DevOps. Als ich mich auf die Präsentation vorbereitete, war ich sehr nervös, weil ich meine langjährige Erfahrung in 5 Minuten darlegen musste.

Am Ende gab ich die folgende Definition von DevOps: Dies ist eine Reihe von Praktiken und Mustern, die es ermöglichen, Humankapital in hochproduktives Organisationskapital umzuwandeln. Ein Beispiel ist, wie Toyota in den letzten 50 oder 60 Jahren gearbeitet hat.



(Im Folgenden werden solche Schemata nicht als Referenzmaterial, sondern zur Veranschaulichung dargestellt. Ihre Inhalte unterscheiden sich für jedes neue Unternehmen. Dennoch kann das Bild über diesen Link separat angezeigt und vergrößert werden.)

Eine der erfolgreichsten derartigen Praktiken ist der Wertstrom Kartierung. Darüber wurden mehrere gute Bücher geschrieben, die Autorin der erfolgreichsten ist Karen Martin. Aber im vergangenen Jahr bin ich zu dem Schluss gekommen, dass selbst dieser Ansatz zu hochtechnologisch ist. Er hat sicherlich viele Vorteile, ich habe ihn oft benutzt. Wenn der CEO Sie jedoch fragt, warum sein Unternehmen nicht zu neuen Tracks wechseln kann, ist es zu früh, um über die Zuordnung von Wertströmen zu sprechen. Es gibt viele viel grundlegendere Fragen, die zuerst beantwortet werden müssen.

Es scheint mir, dass der Fehler vieler meiner Kollegen darin besteht, dass sie dem Unternehmen einfach einen Fünf-Punkte-Leitfaden geben und dann sechs Monate später zurückkommen und sich ansehen, was passiert ist. Sogar eine gute Schaltung wie das Wertstrom-Mapping hat zum Beispiel blinde Flecken. Nach Hunderten von Interviews mit Direktoren verschiedener Unternehmen habe ich ein bestimmtes Muster ausgearbeitet, mit dem wir das Problem in Komponenten zerlegen können. Jetzt werden wir jede dieser Komponenten der Reihe nach diskutieren. Bevor ich technologische Lösungen anwende, verwende ich dieses Muster und habe daher alle Wände mit Mustern aufgehängt. Ich habe kürzlich mit einem Investmentfonds zusammengearbeitet und am Ende 100-150 dieser Programme abgeschlossen.

Schlechte Kultur isst gute Frühstücksansätze


Die Hauptidee ist folgende: Kein Lean, Agile, SAFE und DevOps helfen, wenn die Organisationskultur schlecht ist. Es ist dasselbe wie in die Tiefe zu tauchen, ohne Tauchausrüstung oder ohne Röntgen. Mit anderen Worten, um Drucker und Deming zu paraphrasieren: Eine schlechte Organisationskultur wird jedes gute System verschlucken und nicht ersticken.

Um dieses Hauptproblem zu lösen, müssen Sie die folgenden Schritte ausführen:

  1. Alle Arbeiten sichtbar machen: Alle Arbeiten sichtbar machen. Nicht in dem Sinne, dass es auf einem Bildschirm angezeigt werden muss, sondern in dem Sinne, dass es beobachtbar sein muss.
  2. Consolidate Work Management Systems: . «» 9 10 . «Phoenix Project» - , , - . «» . c .
  3. Theory of Constraints Methodology: .
  4. Collaboration hacks: .
  5. Toyota Kata (Coaching Kata): Toyota Kata . , .
  6. Market Oriented Organization: .
  7. Shift-left auditors: .




Ich beginne sehr einfach mit der Arbeit in der Organisation: Ich gehe in die Firma und spreche mit den Mitarbeitern. Wie Sie sehen können, keine Hochtechnologie. Alles was benötigt wird ist weiter zu schreiben. Ich sammle mehrere Teams in einem Raum und analysiere, was sie mir aus der Sicht meiner 7 Archetypen sagen. Und dann gebe ich ihnen selbst den Marker und bitte sie, alles, was sie bisher laut gesagt haben, schriftlich an die Tafel zu schreiben. Normalerweise gibt es bei solchen Treffen eine Person, die alles aufschreibt, und im besten Fall kann sie 10% der Diskussion aufzeichnen. Mit meiner Methode kann diese Zahl auf etwa 40% angehoben werden.



(Eine separate Abbildung finden Sie unter dem Link. )

Mein Ansatz basiert auf der Arbeit von William Schneider, The Reengineering Alternative) Der Ansatz basiert auf der Idee, dass jede Organisation in vier Quadrate zerlegt werden kann. Dieses Schema ist für mich normalerweise das Ergebnis der Arbeit mit Hunderten anderer Schemata, die bei der Analyse einer Organisation auftreten. Angenommen, wir haben eine Organisation mit einem hohen Maß an Kontrolle, aber mit geringer Kompetenz. Dies ist eine äußerst unerwünschte Option: Wenn alle entlang der Linie gehen, aber niemand weiß, was zu tun ist.

Eine etwas bessere Option mit einem hohen Maß an Kontrolle und Kompetenz. Wenn ein solches Unternehmen einen Gewinn erzielt, benötigt es möglicherweise keine DevOps. Es ist am interessantesten, mit einem Unternehmen zusammenzuarbeiten, das ein hohes Maß an Kontrolle, geringer Kompetenz und Zusammenarbeit bei gleichzeitig hohem Kulturniveau (Kultivierung) aufweist. Dies bedeutet, dass das Unternehmen viele Menschen hat, die gerne dort arbeiten, die Fluktuation ist gering.



(Sie können diese Abbildung separat vom Link sehen. )

Es scheint mir, dass Methoden mit fest codierten Empfehlungen letztendlich das Erreichen der Wahrheit beeinträchtigen. Insbesondere für die Wertstromzuordnung gelten viele Regeln für die Strukturierung von Informationen. In den frühen Phasen der Arbeit, über die ich jetzt spreche, braucht niemand diese Regeln. Wenn eine Person mit einem Marker in der Hand die tatsächliche Situation im Unternehmen an der Tafel beschreibt, ist dies der beste Weg, um die Situation zu verstehen. Solche Informationen erreichen die Direktoren nicht. In diesem Moment ist es dumm, eine Person abzuschneiden und zu sagen, dass sie einen falschen Pfeil gezeichnet hat. In dieser Phase ist es besser, einfache Regeln zu verwenden, zum Beispiel: Eine mehrstufige Abstraktion kann einfach mit mehrfarbigen Markierungen erstellt werden.

Ich wiederhole, keine Hochtechnologie. Ein schwarzer Marker zeigt die objektive Realität, wie alles funktioniert. Menschen markieren mit einer roten Markierung, was genau sie im aktuellen Stand der Dinge nicht mögen. Es ist wichtig, dass sie es schreiben, nicht ich. Wenn ich nach dem Treffen zum Direktor für Informationstechnologie gehe, schlage ich keine Liste mit 10 Dingen vor, die behoben werden müssen. Ich bemühe mich, eine Verbindung zwischen dem, was die Leute im Unternehmen sagen, und bestehenden, bewährten Mustern zu finden. Schließlich schlägt eine blaue Markierung mögliche Lösungen für das Problem vor.



(Diese Abbildung kann separat unter dem Link eingesehen werden. )

Ein Beispiel für diesen Ansatz ist oben dargestellt. Anfang dieses Jahres habe ich bei einer Bank gearbeitet. Die Mitarbeiter der dortigen Sicherheitsabteilung waren überzeugt, dass sie nicht kommen sollten, um die Anforderungen und das Design (Design und Anforderungsüberprüfungen) zu überprüfen.



(Sie können diese Abbildung separat vom Link sehen. )

Und dann haben wir mit Leuten aus anderen Abteilungen gesprochen, und es stellte sich heraus, dass Softwareentwickler vor etwa 8 Jahren Sicherheitsmitarbeiter entlassen haben, weil sie langsamer wurden. Und dann wurde daraus ein Verbot, das für selbstverständlich gehalten wurde. Obwohl es tatsächlich kein Verbot gab.

Unser Treffen war äußerst verwirrend: Etwa drei Stunden lang konnten mir fünf verschiedene Teams nicht erklären, was zwischen dem Code und der Versammlung vor sich ging. Und das scheint das Einfachste zu sein. Die meisten DevOps-Berater gehen im Voraus davon aus, dass dies bereits jeder weiß.

Dann wurde der Verantwortliche für die IT-Governance, der vier Stunden lang still war, plötzlich lebendig, als wir zu seinem Thema kamen und uns sehr lange beschäftigten. Am Ende fragte ich ihn, was er von dem Treffen halte, und ich werde seine Antwort nie vergessen. Er sagte: "Früher dachte ich, dass es in unserer Bank nur zwei Möglichkeiten gibt, Software zu liefern, und jetzt weiß ich, dass es fünf davon gibt, und ich habe nicht einmal drei vermutet."



(Diese Abbildung kann separat unter dem Link eingesehen werden. )

Das letzte Treffen bei dieser Bank war mit dem Investment-Software-Team. Bei ihr stellte sich heraus, dass das Schreiben von Markierungsschaltungen mit einem Marker auf einem Blatt besser ist als das Schreiben auf eine Tafel und sogar besser als das Schreiben auf einem Smartboard.



Die Fotos, die Sie sehen, zeigen, wie der Konferenzraum des Hotels am vierten Tag unseres Meetings aussah. Und wir haben diese Muster verwendet, um nach Mustern zu suchen, dh nach Archetypen.

Also stelle ich den Mitarbeitern Fragen, sie schreiben Antworten mit dreifarbigen Markierungen (schwarz, rot und blau) auf. Ich analysiere ihre Antworten auf Archetypen. Lassen Sie uns nun alle Archetypen der Reihe nach diskutieren.

1. Alle Arbeiten sichtbar machen: Machen Sie die Arbeiten sichtbar.


Die meisten Unternehmen, mit denen ich zusammenarbeite, haben einen sehr hohen Prozentsatz unbekannter Jobs. Dies ist beispielsweise der Fall, wenn ein Mitarbeiter zu einem anderen kommt und nur darum bittet, etwas zu tun. In großen Organisationen können 60% der ungeplanten Arbeiten ausgeführt werden. Und bis zu 40% der Arbeit sind in keiner Weise dokumentiert. Wenn es eine Boeing wäre, wäre ich in meinem Leben nie wieder in ihr Flugzeug gestiegen. Wenn nur die Hälfte der Arbeit dokumentiert ist, ist nicht bekannt, ob diese Arbeit korrekt ausgeführt wurde oder nicht. Alle anderen Methoden erweisen sich als nutzlos - es macht keinen Sinn, etwas zu automatisieren, da die bekannten 50% möglicherweise nur der kohärenteste und klarste Teil der Arbeit sind, dessen Automatisierung keine großartigen Ergebnisse liefert, und der schrecklichste - in der unsichtbaren Hälfte. Ohne Dokumentation ist es unmöglich, alle Arten von Hacks und versteckten Arbeiten zu finden, keine Engpässe zu finden.die gleichen "Brents", über die ich bereits gesprochen habe. Es gibt ein schönes Buch von Dominica De Grandis (Dominica DeGrandis)"Arbeit sichtbar machen . " Es identifiziert fünf verschiedene " Diebe der Zeit":

  • Zu viel Ware in Arbeit (WIP)
  • Unbekannte Abhängigkeiten
  • Ungeplante Arbeit
  • Widersprüchliche Prioritäten
  • Vernachlässigte Arbeit


Dies ist eine sehr wertvolle Analyse, und das Buch ist wunderbar, aber all diese Tipps sind nutzlos, wenn nur 50% der Daten sichtbar sind. Sie können die von Dominica vorgeschlagenen Methoden anwenden, wenn die Genauigkeit über 90% liegt. Ich spreche von Situationen, in denen der Chef dem Untergebenen eine 15-minütige Aufgabe gibt und er drei Tage braucht. aber der Chef weiß nicht wirklich, dass dieser Untergebene von vier oder fünf anderen Personen abhängt.



Das Phoenix-Projekt ist eine großartige Geschichte über ein Projekt, das drei Jahre zu spät ist. Einer der Helden droht aus diesem Grund mit Entlassung, und er trifft einen anderen Charakter, der als eine Art Sokrates dargestellt wird. Er hilft herauszufinden, was genau schief gelaufen ist. Es stellt sich heraus, dass das Unternehmen einen Systemadministrator hat, dessen Name Brent ist, und die ganze Arbeit geht irgendwie durch. Bei einem der Treffen wird einer der Untergebenen gefragt: Warum dauert jede halbstündige Aufgabe eine Woche? Als Reaktion darauf folgt eine sehr vereinfachte Darstellung der Warteschlangentheorie und des Littleschen Gesetzes, und in dieser Darstellung stellt sich heraus, dass bei 90% Beschäftigung jede Arbeitsstunde 9 Stunden dauert. Jede Aufgabe muss an sieben andere Personen gesendet werden, daher wird diese Stunde zu 63 Stunden, 7 mal 9. Ich sage dies:Um das Little'sche Gesetz oder eine komplizierte Warteschlangentheorie zu verwenden, müssen Sie mindestens über Daten verfügen.

Wenn ich über Sichtbarkeit spreche, meine ich daher nicht, dass alles auf dem Bildschirm angezeigt wurde, sondern dass zumindest Daten erforderlich sind. Wenn dies der Fall ist, stellt sich häufig heraus, dass eine sehr große Menge ungeplanter Arbeiten vorhanden ist, die aus irgendeinem Grund an Brent gesendet werden, obwohl dies nicht erforderlich ist. Und Brent ist ein großartiger Kerl, er wird niemals nein sagen, aber er sagt niemandem, wie er seinen Job macht.



Wenn die Arbeit sichtbar ist, können Sie die Daten genau klassifizieren (das macht Dominika auf dem Foto), Sie können die Abstraktion von fünf Zeitlecks anwenden und sie automatisieren.

2. Arbeitsverwaltungssysteme konsolidieren: Aufgabenverwaltung


Die Archetypen, von denen ich spreche, sind eine Art Pyramide. Wenn das erste richtig gemacht wird, ist das zweite bereits eine Art Add-On. Viele von ihnen arbeiten nicht für Startups, sie müssen bei großen Unternehmen berücksichtigt werden, beispielsweise bei Unternehmen, die auf der Fortune 5000-Liste stehen. Das letzte Unternehmen, in dem ich gearbeitet habe, hatte 10 Ticketingsysteme. Abhilfe schaffte es in einem Team, ein anderes schrieb ein eigenes System, ein dritter benutzte Jira und jemand anderes kam per E-Mail aus. Das gleiche Problem tritt auf, wenn das Unternehmen über 30 verschiedene Pipelines verfügt, ich jedoch keine Zeit habe, alle derartigen Fälle zu erörtern.

Ich diskutiere mit den Leuten genau, wie Tickets erstellt werden, was als nächstes mit ihnen passiert, wie sie umgangen werden. Das Interessanteste ist, dass die Leute bei unseren Treffen ganz aufrichtig sprechen. Ich habe gefragt, wie viele Personen "geringe / keine Auswirkungen" für Tickets eingerichtet haben, denen eigentlich "große Auswirkungen" zugewiesen werden sollten. Es stellte sich heraus, dass fast jeder es tut. Ich mache keine Denunziationen und versuche in jeder Hinsicht, keine Menschen zu identifizieren. Wenn sie mir aufrichtig etwas eingestehen, verrate ich keine Person. Wenn jedoch fast jeder das System umgeht, bedeutet dies, dass jede Sicherheit im Wesentlichen eine Dekoration ist. Daher können aus den Daten dieses Systems keine Schlussfolgerungen gezogen werden.

Um das Problem mit Tickets zu lösen, müssen Sie ein Hauptsystem auswählen. Wenn Sie Jira verwenden, lassen Sie es nur Jira sein. Wenn es eine Alternative gibt, lass es nur das sein. Das Fazit ist, dass Tickets als ein weiterer Schritt im Entwicklungsprozess betrachtet werden müssen. Jede Aktion muss über ein Ticket verfügen, das den Entwicklungsworkflow durchlaufen muss. Tickets werden an das Team gesendet, das sie in das Storyboard einfügt und dann für sie verantwortlich ist.

Dies gilt für alle Abteilungen, einschließlich Infrastruktur und Betrieb. In diesem Fall können Sie sich zumindest eine plausible Vorstellung vom Stand der Dinge machen. Wenn dieser Prozess eingerichtet ist, stellt sich plötzlich heraus, dass Sie leicht feststellen können, wer für jede Anwendung verantwortlich ist. Denn jetzt bekommen wir nicht 50%, sondern 98% der neuen Dienstleistungen. Wenn dieser grundlegende Prozess funktioniert, verbessert sich die Genauigkeit im gesamten System.

Pipeline-Dienste


Dies gilt wiederum nur für große Unternehmen. Wenn Sie ein neues Unternehmen in einem neuen Bereich sind, krempeln Sie die Ärmel hoch und arbeiten Sie mit Ihrem Travis CI oder CircleCI. Bei den Fortune 5000-Unternehmen war der Fall bei der Bank, bei der ich gearbeitet habe, bezeichnend. Sie kamen von Google zu ihnen und es wurden Diagramme mit alten IBM-Systemen angezeigt. Die Jungs von Google fragten mit einem Missverständnis - wo ist der Quellcode dafür? Und es gibt keinen Quellcode, nicht einmal eine GUI. Dies ist die Realität, mit der große Unternehmen arbeiten müssen: 40 Jahre alte Bankunterlagen auf einem alten Mainframe. Einer meiner Kunden verwendet Kubernetes-Container mit Leistungsschaltermustern sowie Chaos Monkey für KeyBank. Diese Container stellen jedoch schließlich eine Verbindung zur COBOL-Anwendung her.

Die Jungs von Google waren völlig zuversichtlich, dass sie alle Probleme meines Kunden lösen würden, und stellten dann Fragen: Was ist das IBM-Datenrohr? Sie werden beantwortet: Dies ist ein Konnektor. Womit verbindet es sich? Zum Sperry-System. Und was ist das? Usw. Auf den ersten Blick scheint es: Was für ein DevOps kann es sein? Aber tatsächlich ist es möglich. Es gibt Liefersysteme, mit denen Sie den Workflow an Lieferteams übertragen können.

3. Theorie der Einschränkungen: Theorie der Einschränkungen


Kommen wir zum dritten Archetyp: dem institutionellen / "Stammes" -Wissen. In der Regel gibt es in jeder Organisation mehrere Personen, die alles wissen und alles verwalten. Dies sind diejenigen, die am längsten in der Organisation arbeiten und alle Problemumgehungen kennen.



Wenn dies auf dem Diagramm zu sehen ist, zeichne ich speziell einen Marker um solche Personen: Es stellt sich beispielsweise heraus, dass bei allen Besprechungen ein bestimmter Lou anwesend ist. Und für mich ist klar: Dies ist der lokale Brent. Wenn der CIO zwischen mir in einem T-Shirt und Turnschuhen und einem Mann in einem Anzug von IBM wählt, wählen sie mich aus, weil ich dem Regisseur von Dingen erzählen kann, von denen der andere Mann nichts erzählt und von denen der Regisseur möglicherweise nicht gerne hört. Ich sage ihnen, dass es in ihrer Firma einen Engpass gibt, es ist jemand namens Fred und jemand namens Lu. Dieser Engpass muss gelöst werden, ihr Wissen muss auf die eine oder andere Weise von ihnen erhalten werden.

Um diese Art von Problem zu lösen, kann ich beispielsweise die Verwendung von Slack vorschlagen. Ein kluger Regisseur fragt warum? In solchen Fällen antworten die DevOps-Berater in der Regel: Weil es jeder tut. Wenn der Regisseur wirklich schlau ist, wird er sagen: na und. Und hier endet der Dialog. Und ich antworte darauf: Weil das Unternehmen vier Engpässe hat, Fred, Lou, Susie und Jane. Um ihr Wissen zu institutionalisieren, müssen Sie zuerst Slack einführen. Alle deine Wikis sind völliger Unsinn, weil niemand von ihrer Existenz weiß. Wenn das Ingenieurteam mit der externen und internen Entwicklung befasst ist und jeder wissen sollte, dass Sie sich bei Fragen an das externe Entwicklungsteam oder das Infrastrukturteam wenden können. In diesem Moment haben Lou oder Fred wahrscheinlich Zeit, sich mit dem Wiki zu verbinden. Und dann könnte bei Slack jemand fragenWarum funktioniert es nicht, sagen wir, Schritt 5. Und dann korrigieren Lou oder Fred die Anweisungen im Wiki. Wenn Sie diesen Prozess etablieren, wird viel an seinen Platz fallen.

Dies ist meine Hauptidee: Um einige Hochtechnologien zu empfehlen, müssen Sie zuerst die Grundlage dafür schaffen, und Sie können dies mit den gerade beschriebenen Low-Tech-Lösungen tun. Wenn Sie mit Hochtechnologie beginnen und nicht erklären, warum sie benötigt werden, endet dies in der Regel nicht mit etwas Gutem. Einer unserer Kunden verwendet Azure ML, eine sehr kostengünstige und einfache Lösung. Irgendwo wurden 30% der Fragen von der selbstlernenden Maschine selbst beantwortet. Und Betreiber, die sich nicht mit Datenwissenschaft, Statistik oder Mathematik befassten, haben dieses Ding geschrieben. Dies ist indikativ. Die Kosten einer solchen Lösung sind minimal.

4. Collaboration-Hacks: Collaboration-Hacks


Der vierte Archetyp ist die Notwendigkeit, die Isolation zu bekämpfen. Die meisten Menschen wissen bereits davon: Isolation erzeugt Feindschaft. Wenn sich jede Abteilung auf einer eigenen Etage befindet und sich die Menschen in keiner Weise überschneiden, außer im Aufzug, kommt es sehr leicht zu Feindseligkeiten zwischen ihnen. Und wenn sich im Gegenteil Menschen im selben Raum befinden, geht sie sofort. Wenn jemand zum Beispiel eine allgemeine Anschuldigung erhebt, funktioniert eine solche und eine solche Schnittstelle nie - es gibt nichts Einfacheres, eine solche Anschuldigung zu dekonstruieren. Es reicht für die Programmierer, die die Benutzeroberfläche geschrieben haben, aus, bestimmte Fragen zu stellen, und es wird schnell klar, dass beispielsweise der Benutzer das Tool einfach falsch verwendet hat.

Es gibt viele Möglichkeiten, die Isolation zu überwinden. Ich wurde einmal gebeten, eine Bank in Australien zu beraten. Ich lehnte dies ab, weil ich zwei Kinder und eine Frau habe. Ich konnte ihnen nur helfen, indem ich ihnen grafisches Geschichtenerzählen empfehle. Dies ist eine Sache, die nachweislich funktioniert. Ein weiterer interessanter Weg sind Meetings im Lean-Coffee-Format. In einer großen Organisation ist dies eine großartige Möglichkeit, Wissen zu verbreiten. Darüber hinaus können Sie interne Devopsdays, Hackathons usw. abhalten.

5. Coaching Kata


Wie ich bereits zu Beginn gewarnt habe, werde ich heute nicht darüber sprechen. Bei Interesse können Sie einige meiner Präsentationen sehen .

Zu diesem Thema gibt es auch einen guten Bericht von Mike Rother:



6. Marktorientiert: Eine marktorientierte Organisation


Hier gibt es verschiedene Probleme. Zum Beispiel Menschen "Ich", Menschen "T" und Menschen "E". Menschen "Ich" sind diejenigen, die sich nur mit einer Sache beschäftigen. Normalerweise existieren sie in Organisationen mit isolierten Einheiten. "T" ist, wenn eine Person eine Sache gut weiß, sich aber auch in einigen anderen Dingen auszeichnet. Ein "E" oder sogar ein "Kamm" ist, wenn eine Person viele Fähigkeiten hat.



Hier gilt das Conway-Gesetz , das in der einfachsten Form wie folgt ausgedrückt werden kann: Wenn die drei Teams am Compiler beteiligt sind, ist das Ergebnis ein dreiteiliger Compiler. Wenn die Organisation ein hohes Maß an Isolation aufweist, werden daher auch Kubernetes, Leistungsschalter, API-Erweiterbarkeit und andere modische Dinge in dieser Organisation auf die gleiche Weise wie die Organisation selbst organisiert. Genau nach Conway und trotz euch allen, junge Geeks.

Die Lösung für dieses Problem wurde oft beschrieben. Es gibt zum Beispiel organisatorische Archetypen, die von Fernando Fernandez beschrieben werden. Die Problemarchitektur, über die ich gerade mit Isolation gesprochen habe, ist eine funktionsorientierte Architektur. Der zweite Typ ist die schlechteste Matrixarchitektur, es gibt ein Durcheinander der beiden anderen. Das dritte ist das, was in den meisten Startups zu sehen ist, und große Unternehmen versuchen ebenfalls, diesem Typ zu entsprechen. Es ist eine marktorientierte Organisation. Hier finden Sie eine Optimierung, um die schnellste Antwort auf Kundenanfragen zu erhalten. Dies wird manchmal als flache Organisation bezeichnet.

Viele Leute beschreiben diese Struktur auf unterschiedliche Weise, ich mag den Wortlaut von Build / Run-Teams , in Amazon nennen sie es zwei Pizzateams. In dieser Struktur sind alle Personen vom Typ „I“ um einen Dienst gruppiert und nähern sich allmählich dem Typ „T“ an. Wenn das richtige Management eingerichtet ist, kann sogar „E“ werden. Das erste Gegenargument hier ist, dass eine solche Struktur zusätzliche Elemente enthält. Warum brauchen wir in jeder Abteilung einen Tester, wenn Sie eine spezielle Abteilung von Testern haben können? Worauf ich antworte: Mehrkosten sind in diesem Fall der Preis, um sicherzustellen, dass in Zukunft die gesamte Organisation vom Typ „E“ wird. In dieser Struktur lernt der Tester allmählich etwas über Netzwerke, Architektur, Design usw. Infolgedessen ist jedem Mitglied der Organisation alles bewusst, was in der Organisation geschieht. Wenn Sie wissen möchten, wie diese Schaltung in der Industrie funktioniert, schauen Sie sich Mike Rother, Toyota Kata, an .

7. Auditoren nach links verschieben: Audit in den frühen Phasen eines Zyklus. Einhaltung der Sicherheitsbestimmungen


Dies ist, wenn Ihre Handlungen sozusagen keinen Geruchstest bestehen. Die Leute, die für Sie arbeiten, sind nicht dumm. Wenn sie, wie im obigen Beispiel, überall geringfügige / keine Auswirkungen zeigten, dauerte dies drei Jahre, und niemand bemerkte etwas, dann weiß jeder, dass das System nicht funktioniert. Oder ein anderes Beispiel ist der Change Advisory Board, in dem beispielsweise jede Umgebung gemeldet werden muss. Dort arbeitet eine Gruppe von Menschen (übrigens nicht zu gut bezahlt), die theoretisch wissen sollten, wie das System als Ganzes funktioniert. Und in den letzten fünf Jahren haben Sie wahrscheinlich bemerkt, dass unsere Systeme wahnsinnig komplex sind. Und fünf oder sechs Personen müssen sich für eine Änderung entscheiden, die sie nicht vorgenommen haben und von der sie nichts wissen.

Natürlich funktioniert dieser Ansatz nicht. Ich muss solche Dinge loswerden, weil diese Leute das System nicht schützen. Die Entscheidung muss vom Team selbst getroffen werden, da das Team dafür verantwortlich sein muss. Andernfalls entsteht eine paradoxe Situation, wenn der Manager, der noch nie in seinem Leben Code geschrieben hat, dem Programmierer mitteilt, wie lange das Schreiben des Codes dauert. In einem Unternehmen, mit dem ich zusammengearbeitet habe, gab es 7 verschiedene Tipps, die sich mit jeder Änderung befassten, einschließlich einer Architektur, eines Produkts usw. Es gab sogar eine obligatorische Wartezeit, obwohl mir ein Mitarbeiter sagte, dass in zehn Jahren Arbeit niemand in dieser obligatorischen Frist die von dieser Person vorgenommenen Änderungen jemals abgelehnt hatte.

Auditoren sollten zu sich selbst gerufen werden und sie nicht loswerden. Sagen Sie ihnen, dass Sie unveränderliche Binärcontainer schreiben, die, wenn alle Tests erfolgreich sind, für immer unverändert bleiben. Sagen Sie ihnen, dass Sie Pipeline als Code haben, und erklären Sie, was das bedeutet. Zeigen Sie ihnen das folgende Diagramm: unveränderliche schreibgeschützte Binärdatei in einem Container, der alle Schwachstellentests besteht; und dann berührt es nicht nur niemand - sie berühren nicht einmal das System, das die Pipeline erstellt, da es auch dynamisch erstellt wird. Ich habe Kunden, Capital One, die Vault verwenden, um so etwas wie eine Blockchain zu erstellen. Sie können dem Auditor nicht die „Rezepte“ vom Chef zeigen, sondern nur die Blockchain, aus der hervorgeht, was mit dem Jira-Ticket in der Produktion passiert ist und wer dafür verantwortlich ist.



Laut dem BerichtVon Sonatype im Jahr 2018 erstellt, gab es im Jahr 2017 87 Milliarden OSS-Download-Anfragen.



Die entstandenen Sicherheitslücken sind unerschwinglich. Darüber hinaus enthalten die oben angezeigten Zahlen keine Opportunitätskosten. Kurz gesagt, was ist DevSecOps? Ich möchte sofort sagen, dass ich nicht daran interessiert bin, darüber zu sprechen, wie erfolgreich dieser Name ist. Der Punkt ist, dass Sie versuchen müssen, dieser Pipeline Sicherheit zu verleihen, da DevOps sehr erfolgreich war.

Ein Beispiel für eine solche Sequenz:


Dies ist keine Empfehlung für bestimmte Produkte, obwohl ich sie alle mag. Ich habe sie als Beispiel angeführt, um zu zeigen, dass DevOps, das ursprünglich auf dem Organisationsparadigma in der Industrie basiert, es Ihnen ermöglicht, jede Phase der Arbeit an einem Produkt zu automatisieren.



Und es gibt keinen Grund, warum wir nicht den gleichen Sicherheitsansatz verfolgen könnten.

Gesamt


Abschließend werde ich einige Tipps für DevSecOps geben. Sie müssen Auditoren in den Prozess der Erstellung Ihrer Systeme einbeziehen und Zeit für deren Schulung aufwenden. Es ist notwendig, mit Wirtschaftsprüfern zusammenzuarbeiten. Darüber hinaus ist es notwendig, einen absolut rücksichtslosen Kampf gegen Fehlalarme zu führen. Selbst mit dem teuersten Tool zum Scannen von Sicherheitslücken können Ihre Entwickler äußerst schlechte Gewohnheiten entwickeln, wenn Sie nicht wissen, wie hoch das Signal-Rausch-Verhältnis ist. Entwickler werden mit Ereignissen überladen und löschen sie einfach. Wenn Sie von der Geschichte mit Equifax gehört haben, dann ist dort das Signal der höchsten Gefahrenstufe ignoriert worden. Darüber hinaus müssen Schwachstellen erklärt werden, damit klar ist, wie sie sich auf das Geschäft auswirken. Zum Beispiel können wir sagen, dass dies dieselbe Sicherheitsanfälligkeit ist wie in der Equifax-Geschichte. SicherheitslückenSie müssen die gleichen Probleme wie andere Probleme mit der Software berücksichtigen, dh sie müssen in den gesamten DevOps-Prozess einbezogen werden. Sie müssen mit ihnen über Jira, Kanban usw. arbeiten. Entwickler sollten nicht glauben, dass dies jemand anderes tun wird, im Gegenteil, jeder sollte es tun. Schließlich müssen Sie Energie für die Aufklärung der Menschen aufwenden.

Nützliche Links


Hier sind einige Vorträge von der DevOops-Konferenz, die Sie möglicherweise hilfreich finden:



Schauen Sie sich das DevOops 2020 Moskau- Programm an - dort gibt es auch viele interessante Dinge.

More articles:


All Articles