Sieben Archetypen der Transformation nach den Prinzipien von DevOps.

Die Frage, wie man DevOps bei sich selbst implementiert, besteht schon seit Jahren, aber es gibt nicht allzu viele gute Materialien dazu. Manchmal wird man Opfer von Werbung durch weniger kluge Berater, die nur ihre Zeit verkaufen wollen, egal wie. Manchmal handelt es sich um vage und äußerst allgemeine Aussagen darüber, wie die Schiffe von Megakonzernen durch das Universum segeln. Die Frage ist: Was haben wir davon? Sehr geehrter Autor, könnten Sie Ihre Ideen bitte klar in einer Liste formulieren?

Das liegt daran, dass es nicht viel praktische Erfahrung und Verständnis für die Ergebnisse der transformativen Kulturveränderungen gibt. Veränderungen in der Unternehmenskultur sind langfristige Prozesse, deren Ergebnisse nicht in einer Woche oder einem Monat sichtbar werden. Wir benötigen jemanden mit genug Erfahrung, der gesehen hat, wie Unternehmen über viele Jahre hinweg gegründet und wieder zerstört wurden.

John Willis ist einer der Väter von DevOps. John kann auf jahrzehntelange Erfahrung mit einer Vielzahl von Unternehmen zurückblicken. In letzter Zeit hat John spezifische Muster festgestellt, die in der Zusammenarbeit mit jedem einzelnen Unternehmen auftreten. Mit diesen Archetypen leitet John Unternehmen auf den wahren Weg der DevOps-Transformation. Mehr über diese Archetypen finden Sie in der Übersetzung seines Vortrags von der DevOops 2018 Konferenz.

Über den Redner:

Über 35 Jahre Erfahrung im IT-Management, Mitbegründer des Vorgängers von OpenCloud bei Canonical, beteiligte sich an 10 Startups, von denen zwei an Dell und Docker verkauft wurden. Derzeit ist er Vice President of DevOps and Digital Practices bei SJ Technologies.

Nun folgt die Erzählung aus der Perspektive von John.

Mein Name ist John Willis, und man kann mich am einfachsten auf Twitter erreichen, @botchagalupe. Den gleichen Nickname benutze ich bei Gmail und GitHub. Außerdem über diesen Link können Sie Videomitschnitte meiner Vorträge und die entsprechenden Präsentationen dazu finden.

Ich habe viele Meetings mit CIOs verschiedener großer Unternehmen. Sie beschweren sich sehr oft, dass sie nicht verstehen, was DevOps ist, und alle, die es ihnen erklären möchten, sprechen über etwas ganz anderes. Eine weitere häufige Beschwerde ist, dass DevOps nicht funktioniert, obwohl die Direktoren scheinbar alles tun, was ihnen erklärt wurde. Es handelt sich um große Unternehmen, die seit über einhundert Jahren bestehen. Nach Gesprächen mit ihnen kam ich zu dem Schluss, dass für viele Probleme nicht die Hochtechnologien, sondern relativ niedrigtechnologische Lösungen am besten geeignet sind. Wochenlang habe ich einfach mit Menschen aus verschiedenen Abteilungen kommuniziert. Das, was Sie auf dem allerersten Bild im Post sehen — mein letztes Projekt, der Raum sah nach drei Tagen Arbeit so aus.

Was ist DevOps?

Tatsächlich, wenn man 10 verschiedene Personen fragt, werden sie 10 verschiedene Antworten geben. Aber das Interessante ist: Alle zehn Antworten werden richtig sein. Es gibt hier keine falsche Antwort. Ich beschäftige mich schon seit etwa 10 Jahren intensiv mit DevOps, war der erste Amerikaner beim ersten DevOpsDay. Ich will nicht sagen, dass ich klüger bin als all jene, die sich mit DevOps beschäftigen, aber es ist kaum jemand da, der so viel Mühe und Kraft investiert hat. Ich denke, DevOps entsteht, wenn menschliches Kapital und Technologie aufeinandertreffen. Oft vergessen wir die menschliche Dimension, obwohl wir viel über verschiedene Kulturen sprechen.

Heute haben wir viele Daten, fünf Jahre akademische Forschung, und die Überprüfung der Theorien ist im industriellen Maßstab etabliert. Diese Studien zeigen uns Folgendes: Wenn man in der Unternehmenskultur bestimmte Verhaltensmuster kombiniert, kann man eine 2000-fache Beschleunigung erreichen. Diese Beschleunigung entspricht einer ähnlichen Verbesserung in der Stabilität. Dies ist eine quantitative Messung des Vorteils, den DevOps jedem Unternehmen bieten kann. Vor ein paar Jahren erzählte ich einem CEO eines Fortune 5000-Unternehmens von DevOps. Als ich mich auf die Präsentation vorbereitete, war ich sehr nervös, weil ich in 5 Minuten meine jahrelange Erfahrung präsentieren musste.

Am Ende gab ich folgende Definition von DevOps: Es handelt sich um ein Set von Praktiken und Mustern, die es ermöglichen, menschliches Kapital in hoches Organisational kapital zu verwandeln. Ein Beispiel dafür ist, wie Toyota in den letzten 50 oder 60 Jahren arbeitet.

(Diese und weitere Diagramme sind nicht als Referenzmaterial gedacht, sondern zur Veranschaulichung. Ihr Inhalt wird für jedes neue Unternehmen unterschiedlich sein. Dennoch kann das Bild separat betrachtet und vergrößert werden über diesen Link.)

Eine der erfolgreichsten Praktiken ist Value Stream Mapping. Dazu sind mehrere gute Bücher geschrieben worden, das bekannteste von Karen Martin. Doch im letzten Jahr bin ich zu dem Schluss gekommen, dass selbst dieser Ansatz zu technologisch ist. Er hat zweifellos viele Vorteile, die ich oft genutzt habe. Aber wenn der Geschäftsführer fragt, warum sein Unternehmen nicht auf neue Gleise wechseln kann, ist es noch zu früh, über Value Stream Mapping zu sprechen. Es gibt viele viel grundlegendere Fragen, auf die man zuvor Antworten finden muss.

Ich denke, dass der Fehler vieler meiner Kollegen darin besteht, dass sie dem Unternehmen einfach eine Anleitung mit fünf Punkten geben und dann nach sechs Monaten zurückkommen, um zu sehen, was passiert ist. Selbst ein gutes Diagramm wie Value Stream Mapping hat, sagen wir, blinde Flecken. Nach Hunderten von Interviews mit Direktoren verschiedener Unternehmen habe ich ein bestimmtes Muster entwickelt, das es ermöglicht, das Problem in seine Komponenten zu zerlegen, und jetzt werden wir jede dieser Komponenten der Reihe nach besprechen. Bevor ich irgendwelche technologischen Lösungen anwende, benutze ich dieses Muster, und am Ende hängen alle Wände voller Diagramme. Kürzlich habe ich mit einem Investmentfonds gearbeitet, und am Ende hatte ich 100-150 solcher Diagramme.

Eine schlechte Kultur isst gute Ansätze zum Frühstück.

Die Hauptbotschaft ist folgende: Lean, Agile, SAFE und DevOps helfen nicht, wenn die Kultur der Organisation schlecht ist. Es ist so, als würde man in die Tiefe ohne Tauchausrüstung eintauchen oder ohne Röntgenaufnahme operieren. Anders ausgedrückt, um Peter Drucker und W. Edwards Deming umzuformulieren: Eine schlechte Unternehmenskultur wird jedes gute System verschlingen und dabei nicht einmal schlucken.

Um dieses Hauptproblem zu lösen, müssen folgende Schritte unternommen werden:

1. Aller Arbeit Sichtbarkeit verleihen: wir müssen die gesamte Arbeit sichtbar machen. Nicht im Sinne, dass sie unbedingt auf einem Bildschirm angezeigt werden muss, sondern in dem Sinne, dass sie beobachtbar sein sollte.
2. Arbeitsmanagementsysteme konsolidieren: Es ist notwendig, die Managementsysteme zu konsolidieren. Bei dem Problem des „tribalen“ Wissens und des institutionellen Wissens sind in 9 von 10 Fällen die Engpässe die Menschen. In dem Buch „Phoenix Project“ lag das Problem bei genau einer einzigen Person, Brent, der dafür sorgte, dass das Projekt drei Jahre im Verzug war. Und auf solche „Brents“ stoße ich überall. Um diese Engpässe zu lösen, verwende ich die folgenden zwei Punkte aus unserer Liste.
3. Theorie der Einschränkungen Methodologie: Theorie der Einschränkungen.
4. Zusammenarbeits-Hacks: Hacks zur Zusammenarbeit.
5. Toyota Kata (Coaching Kata): über Toyota Kata werde ich nicht viel sagen. Wenn es dich interessiert, gibt es auf meinem GitHub Präsentationen zu fast jedem dieser Themen.
6. Marktorientierte Organisation: marktorientierte Organisation.
7. Shift-left-Prüfer: Prüfungen in frühen Phasen des Zyklus.

Ich beginne meine Arbeit mit der Organisation ganz einfach: Ich gehe ins Unternehmen und spreche mit den Mitarbeitern. Wie wir sehen, sind keine Hochtechnologien erforderlich. Alles, was benötigt wird, ist etwas, um darauf zu schreiben. Ich versammle mehrere Teams in einem Raum und analysiere, was sie mir sagen, aus der Perspektive meiner 7 Archetypen. Dann gebe ich ihnen einen Marker und bitte sie, alles, was sie bis jetzt laut gesagt haben, schriftlich an die Tafel zu bringen. Normalerweise gibt es bei solchen Treffen eine Person, die alles aufschreibt, und im besten Fall kann sie 10 % der Diskussion festhalten. Bei meiner Methode gelingt es, diesen Wert auf etwa 40 % zu steigern.

(Diese Illustration kann unter dem Link)

Mein Ansatz basiert auf der Arbeit von William Schneider (William Schneider, The Reengineering Alternative). Der Ansatz beruht auf der Idee, dass jede Organisation in vier Quadranten zerlegt werden kann. Dieses Schema ist in der Regel das Ergebnis meiner Arbeit mit den hunderten anderen Diagrammen, die bei der Analyse der Organisation entstehen. Nehmen wir an, wir haben eine Organisation mit hohem Kontrollniveau, aber gleichzeitig mit niedriger Kompetenz. Das ist eine äußerst unerwünschte Situation: Wenn alle in einer Reihe gehen, aber niemand weiß, was zu tun ist.

Eine deutlich bessere Variante mit hohem Maß an Kontrolle und Kompetenz. Wenn ein Unternehmen profitabel ist, benötigt es möglicherweise DevOps nicht. Am interessantesten ist die Zusammenarbeit mit einem Unternehmen, das einen hohen Kontrollgrad, niedrige Kompetenz und Kooperation aufweist, aber gleichzeitig eine hohe Kultur (cultivation) pflegt. Das bedeutet, dass es im Unternehmen viele Leute gibt, die gerne dort arbeiten und die Fluktuation gering ist.

(Diese Illustration kann unter dem Link)

Ich denke, dass Methoden mit strengen Vorgaben letztendlich der Wahrheit im Wege stehen. Insbesondere im Value Stream Mapping gibt es viele Regeln, wie Informationen strukturiert werden müssen. In den frühen Phasen der Arbeit, von denen ich spreche, sind diese Regeln niemandem von Nutzen. Wenn eine Person mit einem Marker in der Hand die tatsächliche Situation im Unternehmen an die Tafel beschreibt, ist das der beste Weg, um zu verstehen, wie der Stand der Dinge ist. Solche Informationen erreichen die Direktoren nicht. In diesem Moment wäre es dumm, die Person zu unterbrechen und zu sagen, dass sie einen Pfeil falsch gezeichnet hat. In dieser Phase ist es besser, einfache Regeln zu verwenden, zum Beispiel: Eine mehrstufige Abstraktion kann einfach erstellt werden, indem man verschiedene Marker in unterschiedlichen Farben verwendet.

Ich wiederhole, keine Hochtechnologie. Mit einem schwarzen Marker wird die objektive Realität dargestellt, wie alles funktioniert. Mit einem roten Marker kennzeichnen die Menschen, was ihnen an der bestehenden Situation nicht gefällt. Wichtig ist, dass sie es schreiben und nicht ich. Wenn ich nach dem Meeting zu dem IT-Direktor gehe, biete ich keine Liste mit 10 Dingen an, die verbessert werden müssen. Ich versuche, Verbindungen zwischen dem, was die Menschen im Unternehmen sagen, und bestehenden bewährten Mustern zu finden. Schließlich werden mit einem blauen Marker mögliche Lösungen für das Problem vorgeschlagen.

(Diese Illustration kann unter dem Link)

Ein Beispiel für diesen Ansatz ist oben dargestellt. Zu Beginn dieses Jahres arbeitete ich mit einer Bank. Die Mitarbeiter aus der Sicherheitsabteilung waren überzeugt, dass sie nicht zu den Prüfungen der Anforderungen und des Designs (design and requirement reviews) kommen dürften.

(Diese Illustration kann unter dem Link)

Dann sprachen wir mit Mitarbeitern aus anderen Abteilungen und fanden heraus, dass vor etwa 8 Jahren die Softwareentwickler die Sicherheitsmitarbeiter ausgeschlossen hatten, weil diese die Arbeit verlangsamt hatten. Und dann verwandelte sich dies in ein Verbot, das als gegeben hingenommen wurde. Obwohl es tatsächlich kein Verbot gab.

Unser Treffen nahm einen äußerst verworrenen Verlauf: Über etwa drei Stunden hinweg konnten fünf verschiedene Teams mir nicht erklären, was zwischen dem Code und dem Build geschieht. Und das sollte eigentlich die einfachste Sache sein. Die meisten DevOps-Berater gehen davon aus, dass dies bereits jedem bekannt ist.

Dann bemerkte die Person, die für die IT-Governance zuständig war und die vier Stunden lang geschwiegen hatte, plötzlich, als wir sein Thema erreichten und beschäftigte uns noch längere Zeit. Am Ende fragte ich ihn, was er von dem Treffen hält, und ich werde seine Antwort nie vergessen. Er sagte: „Früher dachte ich, es gäbe in unserer Bank nur zwei Softwarebereitstellungsmethoden, aber jetzt weiß ich, dass es insgesamt fünf sind, von denen ich drei noch nicht einmal geahnt hatte.“

(Diese Illustration kann unter dem Link)

Das letzte Treffen in dieser Bank war mit dem Team, das sich mit Software für Investitionen beschäftigte. Dabei stellte sich heraus, dass es besser ist, Diagramme mit einem Marker auf Papier zu zeichnen als auf einer Tafel und sogar besser als auf einem Smartboard.

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

Also stelle ich Fragen den Mitarbeitern, sie notieren die Antworten mit Markern in drei Farben (schwarz, rot und blau). Ihre Antworten analysiere ich auf Archetypen. Lassen Sie uns nun alle Archetypen der Reihe nach besprechen.

1. Make All Work Visible: Die Arbeit sichtbar machen

In den meisten Unternehmen, mit denen ich arbeite, gibt es einen sehr hohen Anteil an nicht dokumentierter Arbeit. Zum Beispiel, wenn ein Mitarbeiter einen anderen einfach um etwas bittet. In großen Organisationen kann das 60 % ungeplante Arbeit ausmachen. Und bis zu 40 % der Arbeit sind überhaupt nicht dokumentiert. Wenn es Boeing wäre, würde ich niemals wieder in eines ihrer Flugzeuge steigen. Wenn nur die Hälfte der Arbeit dokumentiert wird, ist unklar, ob diese Arbeit richtig ausgeführt wird oder nicht. Alle anderen Methoden sind somit nutzlos — es macht keinen Sinn, irgendetwas zu automatisieren, da die bekannten 50 % gerade der am besten organisierten und präzisesten Teil der Arbeit sein könnten, deren Automatisierung keine großen Ergebnisse liefert, während das Schlimmste in der unsichtbaren Hälfte verborgen ist. Ohne Dokumentation ist es unmöglich, alle möglichen Hacks und verdeckte Arbeiten zu finden, oder Engpässe wie die „Brent’s“, von denen ich bereits gesprochen habe. Es gibt ein hervorragendes Buch von Dominica DeGrandis. „Making Work Visible“. Es analysiert fünf verschiedene „Zeitdiebe“ (thieves of time):

• Zu viel Arbeit im Prozess (WIP)
• Unbekannte Abhängigkeiten
• Ungeplante Arbeit
• Konfligierende Prioritäten
• Vernachlässigte Arbeit

Das ist eine sehr wertvolle Analyse, und das Buch ist bemerkenswert, aber all diese Ratschläge sind nutzlos, wenn nur 50 % der Daten sichtbar sind. Die Methoden, die von Dominica vorgeschlagen werden, können nur angewendet werden, wenn eine Genauigkeit von über 90 % erreicht ist. Ich spreche von Situationen, in denen der Chef dem Mitarbeiter eine 15-minütige Aufgabe gibt, die aber drei Tage in Anspruch nimmt; der Chef weiß jedoch tatsächlich nicht, dass dieser Mitarbeiter auch von vier oder fünf anderen Personen abhängt.

Das Phoenix-Projekt ist eine bemerkenswerte Geschichte über ein Projekt, das drei Jahre zu spät kommt. Einer der Charaktere droht deshalb mit der Entlassung, und er trifft auf einen anderen Charakter, der als eine Art Sokrates dargestellt wird. Dieser hilft ihm zu verstehen, was genau schiefgelaufen ist. Es stellt sich heraus, dass es in der Firma einen Systemadministrator namens Brent gibt, und das gesamte Arbeiten läuft mehr oder weniger über ihn. Bei einem der Meetings wird ein Mitarbeiter gefragt: Warum dauert jede halbstündige Aufgabe eine Woche? Die Antwort ist eine stark vereinfachte Darstellung der Warteschlangentheorie und des Little-Theorems, und dabei wird deutlich, dass bei 90% Auslastung jede Stunde Arbeit 9 Stunden in Anspruch nimmt. Jede Aufgabe muss an sieben andere Personen gesendet werden, sodass diese Stunde zu 63 Stunden wird, 7 mal 9. Ich sage das, weil man, um das Little-Theorem oder eine andere komplexe Warteschlangentheorie anzuwenden, wenigstens Daten haben muss.

Deshalb meine ich, wenn ich von Sichtbarkeit spreche, nicht, dass alles auf dem Bildschirm sein muss, sondern dass man zumindest Daten haben sollte. Wenn sie vorhanden sind, zeigt sich oft, dass es ein sehr großes Volumen an unvorhergesehener Arbeit gibt, die aus unerfindlichen Gründen an Brent geleitet wird, obwohl es dafür keinen Bedarf gibt. Und Brent ist ein großartiger Kerl, er wird niemals „Nein“ sagen, aber er erzählt niemandem, wie er seine Arbeit macht.

Wenn die Arbeit sichtbar ist, können die Daten ordentlich klassifiziert werden (genau das macht Dominika auf dem Foto), man kann die Abstraktion der fünf Zeitverschwendung und Automatisierung anwenden.

2. Konsolidierung von Arbeitsmanagementsystemen: Aufgabenverwaltung

Die Archetypen, von denen ich spreche, stellen eine Art Pyramide dar. Wenn der erste richtig ausgeführt wird, ist der zweite eine Art Aufbaustufe. Viele davon funktionieren nicht für Startups; man sollte sie im Hinterkopf behalten, wenn es um große Unternehmen geht, die auf der Fortune 5000-Liste stehen. In dem letzten Unternehmen, in dem ich gearbeitet habe, gab es 10 Fehlerverfolgungssysteme (Ticketing-System). In einem Team gab es Remedy, ein anderes hat ein eigenes System geschrieben, das dritte Team nutzte Jira, und jemand kam ganz ohne E-Mail aus. Das gleiche Problem tritt auf, wenn es im Unternehmen 30 verschiedene Pipelines gibt, aber ich habe nicht die Zeit, all diese Fälle zu besprechen.

Ich diskutiere mit den Leuten, wie genau Tickets erstellt werden, was danach mit ihnen passiert und wie sie umgangen werden. Das Interessanteste ist, dass die Leute in unseren Treffen ziemlich ehrlich sprechen. Ich habe gefragt, wie viele Leute "minor / no impact" für Tickets angeben, die tatsächlich als "major impact" klassifiziert werden sollten. Es stellte sich heraus, dass das fast alle machen. Ich mache keine Anschuldigungen und versuche nach Kräften, die Identität der Menschen zu schützen. Wenn mir jemand aufrichtig etwas gesteht, gebe ich die Person nicht preis. Aber wenn praktisch alle das System umschiffen, bedeutet das, dass die gesamte Sicherheit im Grunde nur eine Fassade ist. Daher können aus den Daten dieses Systems keine Schlussfolgerungen gezogen werden.

Um das Problem mit Ticketing zu lösen, ist es notwendig, ein Hauptsystem auszuwählen. Wenn Sie Jira verwenden, lassen Sie es nur bei Jira. Wenn es eine Alternative gibt, dann sollte es nur diese sein. Die Idee ist, dass Tickets als einen weiteren Schritt im Entwicklungsprozess betrachtet werden müssen. Jede Handlung sollte ein Ticket haben, das durch den Entwicklungsworkflow gehen muss. Die Tickets werden an das Team gesendet, das sie auf dem Storyboard präsentiert und dann Verantwortung dafür trägt.

Das betrifft alle Abteilungen, einschließlich Infrastruktur und Operations. In diesem Fall kann eine plausibelere Darstellung der Situation erstellt werden. Wenn dieser Prozess eingerichtet ist, ist es plötzlich möglich, leicht zu bestimmen, wer für jede Anwendung verantwortlich ist. Denn nun erhalten wir nicht 50%, sondern 98% neuer Dienstleistungen. Wenn dieser grundlegende Prozess funktioniert, verbessert sich die Genauigkeit im gesamten System.

Pipeline der Services

Das betrifft wieder nur 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. Was die Fortune 5000 Unternehmen angeht, ist ein Fall, der mir bekannt ist, der mit der Bank, in der ich gearbeitet habe. Google kam zu ihnen und zeigte ihnen Diagramme mit alten IBM-Systemen. Die Leute von Google fragten verständnislos – wo ist der Quellcode dazu? Und es gibt keinen Quellcode, nicht einmal ein GUI. Das ist die Realität, mit der große Organisationen umgehen müssen: 40-jährige Bankaufzeichnungen auf einem alten Mainframe. Einer meiner Kunden verwendet Kubernetes-Container mit Circuit Breaker-Mustern, plus Chaos Monkey, alles für die KeyBank-Anwendung. Aber diese Container verbinden sich letztlich mit einer COBOL-Anwendung.

Die Leute von Google waren sich sicher, dass sie alle Probleme meines Kunden lösen würden, und dann begannen sie Fragen zu stellen: Was ist ein IBM datapipe? Die Antwort lautet: Das ist ein Connector. Woran ist er angeschlossen? An das Sperry-System. Und was ist das? Und so weiter. Auf den ersten Blick scheint es, als könnte es hier kein DevOps geben. Aber tatsächlich ist es möglich. Es gibt Liefersysteme, die es ermöglichen, den Arbeitsablauf an die Teams zu übergeben, die für die Lieferung zuständig sind.

3. Theory of Constraints: Theorie der Einschränkungen

Kommen wir zum dritten Archetyp: institutionelles / ‚stammestümliches‘ Wissen. In der Regel gibt es in jeder Organisation ein paar Personen, die alles wissen und das Sagen haben. Das sind die, die am längsten in der Organisation sind und alle Abkürzungen kennen.

Wenn dies in einem Diagramm festgestellt wird, umrahme ich solche Personen gezielt mit einem Marker: Es stellt sich heraus, dass ein gewisser Lou bei allen Meetings anwesend ist. Und für mich ist klar: Das ist der lokale Brent. Wenn der IT-Direktor zwischen mir im T-Shirt und Turnschuhen und einem Anzugträger von IBM wählt, wählt man mich, weil ich dem Direktor Dinge erzählen kann, die der andere Typ ihm nicht erzählen wird und die für den Direktor unangenehm sein könnten. Ich sage ihnen, dass es in ihrem Unternehmen einen Engpass gibt, es gibt jemanden namens Fred und jemanden namens Lou. Dieser Engpass muss gelöst werden, ihr Wissen muss auf die eine oder andere Weise von ihnen erlangt werden.

Um solche Probleme zu lösen, könnte ich beispielsweise vorschlagen, Slack zu verwenden. Ein kluger Direktor würde fragen – warum? In solchen Fällen antworten DevOps-Berater normalerweise: Weil es alle so machen. Wenn der Direktor wirklich klug ist, wird er sagen: Na und? Und damit endet der Dialog. Und ich antworte darauf: Weil es im Unternehmen vier Engpässe gibt: Fred, Lou, Suzy und Jane. Um ihr Wissen zu institutionalieren, muss man zuerst Slack einführen. Alle eure Wikis sind völliger Unsinn, weil niemand von ihrer Existenz weiß. Wenn das Ingenieurteam an der externen und internen Entwicklung arbeitet, sollten alle wissen, dass sie sich an das externe Entwicklungsteam oder das Infrastrukturteam mit Fragen wenden können. Genau dann hat Lou oder Fred wahrscheinlich Zeit, um sich in das Wiki einzulesen. Und dann könnte jemand in Slack fragen, warum Schritt 5 nicht funktioniert. Und dann werden Lou oder Fred die Anleitung im Wiki korrigieren. Wenn man diesen Prozess einrichtet, wird vieles von selbst an seinen Platz fallen.

Das ist meine Hauptbotschaft: Um hochtechnologische Lösungen zu empfehlen, muss man zuerst die Grundlagen dafür in Ordnung bringen, und das kann man nur mit den gerade beschriebenen niederen technologischen Lösungen erreichen. Wenn man hingegen mit Hochtechnologie beginnt und nicht erklärt, wozu sie nötig ist, endet das in der Regel nicht gut. Einer unserer Kunden verwendet Azure ML, eine sehr kostengünstige und einfache Lösung. Bei etwa 30% der Fragen hat bereits die selbstlernende Maschine geantwortet. Und diese Lösung wurde von Betreibern entwickelt, die sich nicht mit Data Science, Statistik oder Mathematik befasst haben. Das ist bemerkenswert. Die Kosten für eine solche Lösung sind minimal.

4. Collaboration Hacks: Kooperations-Hacks

Das vierte Archetyp besteht darin, gegen Isolation zu kämpfen. Die meisten Menschen wissen das bereits: Isolation erzeugt Feindschaft. Wenn jede Abteilung auf ihrer eigenen Etage ist und die Menschen nur im Aufzug miteinander in Kontakt treten, entsteht sehr leicht Feindschaft zwischen ihnen. Wenn die Menschen jedoch im selben Raum sind, verschwindet sie sofort. Wenn jemand eine gemeinsame Beschwerde äußert, zum Beispiel, dass eine bestimmte Schnittstelle nie funktioniert, ist es nicht schwer, diese Beschwerde zu dekonstrukieren. Den Programmierern, die die Schnittstelle geschrieben haben, genügt es, konkrete Fragen zu stellen, und bald wird klar, dass der Benutzer beispielsweise einfach das Werkzeug falsch genutzt hat.

Es gibt viele Möglichkeiten, Isolation zu überwinden. Einmal wurde ich gebeten, eine Bank in Australien zu beraten, ich lehnte ab, weil ich zwei Kinder und eine Frau habe. Alles, was ich ihnen anbieten konnte, war eine Empfehlung für grafisches Geschichtenerzählen. Das ist etwas, das nachweislich funktioniert. Ein weiterer interessanter Ansatz sind Lean-Coffee-Meetings. In einer großen Organisation ist das eine hervorragende Möglichkeit, Wissen zu verbreiten. Darüber hinaus können interne DevOps-Tage, Hackathons usw. veranstaltet werden.

5. Coaching Kata

Wie ich bereits zu Beginn gewarnt habe, werde ich heute nicht darüber sprechen. Wenn es dich interessiert, kannst du dir ansehen einige meiner Präsentationen.

Es gibt auch einen guten Vortrag zu diesem Thema von Mike Rother:

6. Marktgerechte Organisation

Hier gibt es verschiedene Probleme. Zum Beispiel Menschen vom Typ „I“, Leute vom Typ „T“ und Leute vom Typ „E“. Menschen vom Typ „I“ sind diejenigen, die sich nur mit einer Sache beschäftigen. Sie existieren normalerweise genau in Organisationen mit isolierten Abteilungen. „T“ ist, wenn eine Person in einer Sache gut ist, aber auch in einigen anderen Dingen erfolgreich ist. „E“ oder sogar „Kamm“ ist, wenn eine Person viele Fähigkeiten hat.

Hier gilt das Conway-Gesetz (Conway’s law), das in möglichst vereinfachter Form so formuliert werden kann: Wenn drei Teams an einem Compiler arbeiten, wird letztlich ein Compiler aus drei Teilen entstehen. Daher wird, wenn innerhalb einer Organisation ein hohes Maß an Isolation besteht, selbst Kubernetes, Circuit Breaker, API-Erweiterbarkeit und andere angesagte Dinge in dieser Organisation so strukturiert sein wie die Organisation selbst. Strikt nach Conway und zum Trotz, ihr jungen Geeks.

Das Problem wurde schon oft beschrieben. Es gibt beispielsweise die organisatorischen Archetypen, die von Fernando Fernandez definiert wurden. Die problematische Architektur, von der ich gerade gesprochen habe, die Isolation — ist eine funktional orientierte Architektur. Der zweite Typ — der schlechteste, die Matrixarchitektur, ist ein Durcheinander aus den beiden anderen. Der dritte — das, was in den meisten Start-ups beobachtet wird, und auch große Unternehmen versuchen, diesem Typ zu entsprechen. Es handelt sich um eine marktorientierte Organisation. Hier erfolgt die Optimierung, um die schnellstmögliche Reaktion auf Kundenanfragen zu erzielen. Manchmal wird dies als flache Organisation bezeichnet.

Diese Struktur wird von vielen unterschiedlich beschrieben, mir gefällt die Formulierung build/run teams, bei Amazon nennt man es two pizza teams. In dieser Struktur gruppieren sich alle Personen des Typs „I“ um einen Service, und allmählich nähern sie sich dem Typ „T“, und wenn das Management richtig funktioniert, können sie sogar „E“ werden. Das erste Gegenargument hier ist — in einer solchen Struktur gibt es überflüssige Elemente. Warum benötigt man einen Tester in jeder Abteilung, wenn man eine spezielle Testabteilung haben kann? Darauf antworte ich: Überflüssige Kosten sind in diesem Fall der Preis dafür, dass die gesamte Organisation in Zukunft zu einem Typ „E“ wird. In einer solchen Struktur lernt der Tester allmählich etwas über Netzwerke, Architektur, Design usw. Am Ende weiß jeder Teilnehmer der Organisation genau, was in der Organisation passiert. Wenn Sie erfahren möchten, wie dieses Schema in der Industrie funktioniert, lesen Sie Mike Rother, Toyota Kata.

7. Shift-left auditors: Audit in frühen Phasen des Zyklus. Einhaltung von Sicherheitsregeln sichtbar machen.

Es ist, wenn Ihre Aktionen sozusagen die Geruchsprüfung nicht bestehen. Die Menschen, die für Sie arbeiten, sind nicht dumm. Wenn sie, wie im obigen Beispiel, überall nur minor/no impact angeben, und das drei Jahre lang so geht und niemand etwas merkt, dann wissen alle genau, dass das System nicht funktioniert. Oder ein weiteres Beispiel – der Change Advisory Board, wo jeden Mittwoch Berichte eingereicht werden müssen. Dort arbeitet eine Gruppe von Menschen (übrigens nicht besonders gut bezahlt), die theoretisch wissen sollten, wie das System insgesamt funktioniert. Und in den letzten fünf Jahren haben Sie wahrscheinlich bemerkt, dass unsere Systeme unglaublich komplex sind. Fünf oder sechs Personen sollten über eine Änderung entscheiden, die sie nicht eingebracht haben und über die sie nichts wissen.

Natürlich funktioniert dieser Ansatz nicht. Ich muss mich von solchen Dingen trennen, weil diese Menschen das System nicht schützen. Entscheidungen müssen vom Team selbst getroffen werden, denn das Team sollte dafür verantwortlich sein. Andernfalls entsteht eine paradoxe Situation, in der ein Manager, der in seinem Leben noch nie Code geschrieben hat, dem Programmierer sagt, wie lange das Schreiben des Codes dauern sollte. In einem Unternehmen, in dem ich gearbeitet habe, gab es sieben verschiedene Gremien, die jede Änderung prüften, darunter das Architektur- und das Produktgremium usw. Es gab sogar eine vorgeschriebene Wartezeit, obwohl mir ein Mitarbeiter sagte, dass in zehn Jahren niemand in dieser vorgeschriebenen Zeit jemals eine Änderung abgelehnt hat, die von dieser Person eingebracht wurde.

Auditoren sollten zu Ihnen eingeladen werden, anstatt sie loszuwerden. Erklären Sie ihnen, dass Sie immutable Binary-Container schreiben, die, sobald sie alle Tests bestanden haben, für immer unveränderlich bleiben. Sagen Sie ihnen, dass Sie Pipeline as Code haben, und erläutern Sie, was das bedeutet. Zeigen Sie ihnen das folgende Schema: ein immutable Binary, das nur lesezugänglich ist in einem Container, der alle Sicherheitsanfälligkeitstests besteht; und außerdem wird nicht nur dieser nicht berührt — auch das System, das die Pipeline erstellt, wird nicht angefasst, da es ebenfalls dynamisch erstellt wird. Ich habe Kunden, wie Capital One, die mit Vault etwas wie eine Blockchain erstellen. Dem Auditor müssen keine „Rezepte“ aus Chef gezeigt werden, es genügt, die Blockchain zu zeigen, aus der klar hervorgeht, was mit dem Jira-Ticket in der Produktion geschehen ist und wer dafür verantwortlich ist.

Laut Bericht, gegründet 2018, gab es 2017 87 Milliarden Download-Anfragen für OSS.

Die Verluste durch Sicherheitsanfälligkeiten sind überaus hoch. Und die Zahlen, die Sie jetzt oben sehen, enthalten nicht einmal die alternativen Kosten. Kurz gesagt, was DevSecOps ist. Ich möchte gleich klarstellen, dass mich Diskussionen darüber, wie gelungen dieser Begriff ist, nicht interessieren. Es geht darum, dass, da DevOps sehr erfolgreich waren, wir versuchen sollten, die Sicherheit in diese Pipeline einzufügen.

Ein Beispiel für eine solche Abfolge:


Dies ist keine Empfehlung bestimmter Produkte, obwohl ich alle mag. Ich habe sie als Beispiel angeführt, um zu zeigen, dass DevOps, das ursprünglich auf der Paradigmatik der industriellen Organisation basiert, es ermöglicht, jeden Schritt bei der Produktentwicklung zu automatisieren.

Und es gibt keinen Grund, warum wir denselben Ansatz nicht auf die Sicherheit anwenden könnten.

Fazit

Abschließend möchte ich einige Ratschläge für DevSecOps geben. Es ist notwendig, Auditoren in den Prozess der Erstellung Ihrer Systeme einzubeziehen und Zeit in ihre Schulung zu investieren. Man muss mit Auditoren zusammenarbeiten. Außerdem sollte man einen gnadenlosen Kampf gegen falsche Alarme führen. Selbst mit dem teuersten Schwachstellenscanner kann man sehr schädliche Gewohnheiten bei den Entwicklern erzeugen, wenn man nicht weiß, wie das Verhältnis von Signal zu Rauschen ist. Entwickler werden mit Meldungen überflutet und fangen an, diese einfach zu löschen. Wenn Sie von der Geschichte mit Equifax gehört haben, dann ist genau das passiert: Es wurde ein hochriskantes Signal ignoriert. Zudem sollten Schwachstellen so erklärt werden, dass klar ist, wie sie das Geschäft beeinflussen. Man könnte sagen, dass dies die gleiche Schwachstelle ist, wie in der Geschichte mit Equifax. Sicherheitsrelevante Schwachstellen sollten genauso behandelt werden wie andere Softwareprobleme, das heißt, sie müssen in den allgemeinen DevOps-Prozess integriert werden. Man sollte über Jira, Kanban usw. mit ihnen arbeiten. Entwickler sollten nicht denken, dass sich jemand anderes darum kümmert – im Gegenteil, alle sollten sich damit befassen. Schließlich sollte man die Ressourcen darauf verwenden, Menschen zu schulen.

Nützliche Links

Hier sind einige Vorträge von der DevOops-Konferenz, die für Sie nützlich sein könnten:

• Sergej Berdnikow, Artem Kalichkin – Erfolgsgeschichte oder «Dev+DevOps+Ops» (das Video, Vortragsunterlagen)
• Baruch Sadogurski, Leonid Igolnik – DevOps im großen Maßstab: Eine griechische Tragödie in drei Akten (das Video, Vortragsunterlagen)
• Alexander Titov, Kirill Tolkatchev – DevOps, Ingenieure und Community
• Timothy Lister – Charaktere, Community und Kultur: Wichtige Faktoren für den Erfolg

Schauen Sie in Programm DevOops 2020 Moskau – es gibt auch dort viele interessante Informationen.

Quelle: habr.com