Die Frage "Wie implementiere ich DevOps?" stellt sich schon seit einigen Jahren, aber es gibt nicht viele gute Materialien dazu. Manchmal wird man zum Opfer von Werbung durch nicht besonders kluge Berater, die einfach ihre Zeit verkaufen müssen, egal wie. Oft sind es schwammige, sehr allgemeine Aussagen darüber, wie die Schiffe von Megakonzerne durch das Universum segeln. Das wirft die Frage auf: Was haben wir davon? Sehr geehrter Autor, könnten Sie Ihre Ideen klar und übersichtlich in einer Liste formulieren?
All dies geschieht, weil es nicht viele praktische Erfahrungen und ein echtes Verständnis für die Ergebnisse von Kulturtransformationen gibt. Veränderungen in der Unternehmenskultur sind langfristige Prozesse, deren Ergebnisse nicht innerhalb einer Woche oder eines Monats sichtbar werden. Wir brauchen jemanden, der ausreichend erfahren ist und gesehen hat, wie Unternehmen über viele Jahre hinweg geschaffen und zerstört wurden.
John Willis John ist einer der Väter des DevOps. Er blickt auf Jahrzehnte der Zusammenarbeit mit einer Vielzahl von Unternehmen zurück. In letzter Zeit hat John spezifische Muster entdeckt, die in der Arbeit mit jedem von ihnen auftreten. Mit Hilfe dieser Archetypen weist John Unternehmen den wahren Weg der DevOps-Transformation. Mehr über diese Archetypen erfahren Sie in der Übersetzung seines Vortrags von der DevOops 2018-Konferenz.
Über den Redner:
Über 35 Jahre Erfahrung im IT-Management, Mitbegründer des Vorläufers von OpenCloud bei Canonical, beteiligt an 10 Startups, von denen er zwei an Dell und Docker verkauft hat. Derzeit ist er Vice President of DevOps and Digital Practices bei SJ Technologies.
Im Folgenden folgt die Erzählung aus Johns Perspektive.
Mein Name ist John Willis, und am besten erreichen Sie mich auf Twitter, . Das ist auch mein Pseudonym auf Gmail und GitHub. Und finden Sie Videoaufzeichnungen meiner Vorträge und die dazugehörigen Präsentationen.
Ich habe viele Meetings mit CIOs verschiedener großer Unternehmen. Sie klagen oft, dass sie nicht verstehen, was DevOps ist, und dass alle, die versuchen, es ihnen zu erklären, von etwas ganz anderem sprechen. Eine weitere häufige Beschwerde ist: DevOps funktioniert nicht, obwohl die Direktoren angeblich alles so machen, wie es ihnen erklärt wurde. Dabei handelt es sich um große Unternehmen, die seit über einhundert Jahren existieren. Nachdem ich mit ihnen gesprochen habe, bin ich zu dem Schluss gekommen, dass für viele Probleme nicht hochentwickelte Technologien, sondern relativ einfache Lösungen am besten geeignet sind. Wochenlang habe ich einfach nur mit Menschen aus verschiedenen Abteilungen gesprochen. Das, was Sie auf dem allerersten Bild in meinem Beitrag sehen, ist mein letztes Projekt; der Raum sah nach drei Tagen Arbeit so aus.
Was ist DevOps?
In der Tat, wenn man 10 verschiedene Personen fragt, werden sie 10 unterschiedliche Antworten geben. Doch das Interessante ist: Alle diese zehn Antworten sind richtig. Es gibt hier keine falsche Antwort. Ich habe mich ziemlich tief mit DevOps beschäftigt, etwa seit 10 Jahren, und war der erste Amerikaner beim ersten DevOpsDay. Ich will nicht sagen, dass ich der Klügste unter denjenigen bin, die sich mit DevOps beschäftigen, aber wahrscheinlich gibt es niemanden, der so viel Energie darauf verwendet hat. Ich glaube, dass DevOps dann entsteht, wenn menschliches Kapital und Technologie zusammenkommen. Oft vergessen wir das menschliche Element, obwohl wir viel über verschiedene Kulturen sprechen.
Aktuell verfügen wir über eine Fülle von Daten, fünf Jahre akademischer Forschung, und die Prüfung von Theorien erfolgt in industriellem Maßstab. Diese Forschungen zeigen uns Folgendes: Wenn man in der Organisationskultur bestimmte Verhaltensmuster kombiniert, kann man eine 2000-fache Beschleunigung erreichen. Diese Beschleunigung korreliert mit einer ähnlichen Verbesserung der Stabilität. Dies ist eine quantitative Messung des Vorteils, den DevOps jedem Unternehmen bieten kann. Vor ein paar Jahren sprach ich über DevOps mit dem CEO eines Fortune-5000-Unternehmens. Als ich mich auf die Präsentation vorbereitete, war ich sehr nervös, da ich in fünf Minuten meine jahrelange Erfahrung darlegen musste.
Am Ende gab ich folgende Definition von DevOps: Es handelt sich um eine Reihe von Praktiken und Mustern, die es ermöglichen, menschliches Kapital in hochproduktivem organisatorischem Kapital zu verwandeln. Ein Beispiel ist, wie Toyota in den letzten 50 oder 60 Jahren arbeitet.
(Von hier an werden solche Diagramme nicht als Referenzmaterial, sondern als Illustrationen verwendet. Ihr Inhalt wird sich je nach Unternehmen unterscheiden. Dennoch kann das Bild separat betrachtet und vergrößert werden,
Eine der erfolgreichsten Praktiken ist die Wertstromanalyse. Darüber wurden einige gute Bücher geschrieben, das bekannteste von ihnen stammt 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 CEO fragt, warum sein Unternehmen nicht auf neue Gleise umschwenken kann, ist es noch zu früh, über Wertstromanalyse zu sprechen. Es gibt viele viel grundlegendere Fragen, auf die man zuvor Antworten finden muss.
Ich denke, dass der Fehler vieler meiner Kollegen darin liegt, dass sie dem Unternehmen eine Anleitung mit fünf Punkten geben und dann nach sechs Monaten zurückkommen, um zu sehen, was passiert ist. Selbst bei einem guten Ansatz wie dem Value-Stream-Mapping gibt es, sagen wir mal, blinde Flecken. Nach Hunderten von Interviews mit Geschäftsführern verschiedener Unternehmen habe ich ein bestimmtes Muster entwickelt, das es mir ermöglicht, das Problem in seine Teile 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. Neulich arbeitete ich mit einem Investmentfonds und hatte schließlich 100-150 solcher Diagramme.
Schlechte Kultur frisst gute Ansätze zum Frühstück.
Die Hauptaussage lautet: Keine Lean-, Agile-, SAFE- oder DevOps-Methoden helfen, wenn die Kultur der Organisation schlecht ist. Es ist, als würde man ohne Sauerstoffgerät in die Tiefe tauchen oder ohne Röntgenaufnahme operieren. Anders ausgedrückt, um Drucker und Deming umzuformulieren: Eine schlechte Unternehmenskultur wird jedes gute System verschlingen und nicht daran ersticken.
Um dieses Hauptproblem zu lösen, sind folgende Schritte erforderlich:
- Alle Arbeiten sichtbar machen: die gesamte Arbeit muss sichtbar sein. Nicht im Sinne, dass sie unbedingt auf irgendeinem Bildschirm angezeigt werden muss, sondern dass sie beobachtbar sein sollte.
- Arbeitsmanagementsysteme konsolidieren: es ist notwendig, die Managementsysteme zu konsolidieren. Im Problem des "stammesbasierten" Wissens und des institutionellen Wissens sind in 9 von 10 Fällen die Engpässe die Menschen. In dem Buch lag das Problem bei einer einzigen Person, Brent, durch den das Projekt drei Jahre im Rückstand war. Und solchen „Brents“ begegne ich überall. Um diese Engpässe zu lösen, verwende ich die folgenden zwei Punkte in unserer Liste.
- Theorie der Einschränkungen: Theorie der Einschränkungen.
- Kollaborations-Hacks: Kollaborations-Hacks.
- Toyota Kata (): Ich werde nicht viel über Toyota Kata sprechen. Falls es dich interessiert, gibt es auf meinem GitHub zu fast jedem dieser Themen.
- Marktorientierte Organisation: marktorientierte Organisation.
- Shift-left Auditoren: Audits in den frühen Phasen des Zyklus.
Ich beginne die Zusammenarbeit mit einer Organisation ganz einfach: Ich gehe ins Unternehmen und spreche mit den Mitarbeitern. Wie man sieht, sind keine hochmodernen Technologien erforderlich. Alles, was ich brauche, ist ein Ort, an dem ich schreiben kann. Ich versammle mehrere Teams in einem Raum und analysiere, was sie mir aus der Perspektive meiner 7 Archetypen erzählen. Danach gebe ich ihnen einen Marker und bitte sie, alles, was sie bisher laut gesagt haben, schriftlich an die Tafel zu bringen. Normalerweise gibt es bei solchen Treffen eine Person, die alles aufschreibt, und im besten Fall schafft sie es, 10 % der Diskussion festzuhalten. Mit meiner Methode gelingt es, diesen Wert auf etwa 40 % zu steigern.
(Diese Illustration kann separat )
Mein Ansatz basiert auf der Arbeit von William Schneider (William Schneider, ). Die Grundlage dieses Ansatzes besteht darin, dass jede Organisation in vier Quadranten zerlegt werden kann. Dieses Diagramm ist in der Regel das Ergebnis von meine Arbeiten mit den vielen anderen Diagrammen, die bei der Analyse einer Organisation entstehen. Nehmen wir an, wir haben eine Organisation mit hohem Kontrollniveau, aber gleichzeitig mit geringer Kompetenz. Dies ist eine äußerst unerwünschte Variante: Wenn alle nach Vorschrift arbeiten, aber niemand weiß, was zu tun ist.
Etwas besser ist die Variante mit hohem Niveau sowohl an Kontrolle als auch an Kompetenz. Sollte ein solches Unternehmen profitabel sein, braucht es möglicherweise kein DevOps. Am interessantesten ist die Arbeit mit einem Unternehmen, das ein hohes Maß an Kontrolle, geringe Kompetenz und Kooperation aufweist, aber gleichzeitig eine hohe Kultur (cultivation) hat. Das bedeutet, dass es in der Firma viele Menschen gibt, die gerne dort arbeiten, und die Fluktuation der Mitarbeiter niedrig ist.
(Diese Illustration kann separat )
Ich glaube, dass Methoden mit strikten Vorgaben letztendlich dabei hindern, die Wahrheit zu finden. Besonders beim Value Stream Mapping gibt es viele Regeln, wie Informationen strukturiert werden müssen. In den frühen Phasen, von denen ich spreche, sind diese Regeln nicht hilfreich. Wenn jemand mit einem Marker in der Hand eine reale Situation auf einem Board beschreibt, ist das der beste Weg, um sich über die aktuellen Gegebenheiten zu informieren. Solche Informationen erreichen die Führungskräfte nicht. In diesem Moment wäre es unklug, die Person zu unterbrechen und zu sagen, dass sie einen Pfeil falsch gezeichnet hat. In dieser Phase ist es besser, einfache Regeln zu nutzen, wie zum Beispiel: Eine mehrstufige Abstraktion kann einfach durch die Verwendung von farbigen Markern erstellt werden.
Ich wiederhole: keine Hightech. Mit einem schwarzen Marker wird die objektive Realität dargestellt, wie alles funktioniert. Mit einem roten Marker markieren die Leute, was ihnen an der aktuellen Situation nicht gefällt. Wichtig ist, dass sie das schreiben und nicht ich. Wenn ich nach dem Meeting zum IT-Direktor gehe, schlage ich nicht eine Liste von 10 Dingen vor, die geändert werden müssen. Ich versuche, Verbindungen zwischen dem, was die Leute im Unternehmen sagen, und den 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 separat )
Ein Beispiel für diesen Ansatz ist oben dargestellt. Zu Beginn dieses Jahres arbeitete ich mit einer Bank. Die Mitarbeiter der Sicherheitsabteilung waren überzeugt, dass sie nicht zu Überprüfungen von Anforderungen und Design (design and requirement reviews) kommen dürften.
(Diese Illustration kann separat )
Dann sprachen wir mit Menschen aus anderen Abteilungen und fanden heraus, dass etwa vor 8 Jahren Softwareentwickler die Sicherheitsmitarbeiter ausgeschlossen hatten, weil sie die Arbeit verlangsamten. Das führte schließlich zu einem Verbot, das als gegeben angesehen wurde. In Wirklichkeit gab es jedoch kein solches Verbot.
Unser Treffen verlief äußerst verworren: über etwa drei Stunden hinweg konnten fünf verschiedene Teams mir nicht erklären, was zwischen dem Code und dem Build vor sich geht. Und das schien doch die einfachste Sache zu sein. Die meisten DevOps-Berater gehen davon aus, dass dies bereits allen bekannt ist.
Dann erwachte der Mann, der für die IT-Regulierung zuständig war und vier Stunden lang geschwiegen hatte, plötzlich zum Leben, als wir sein Thema ansprachen, und hielt uns noch eine beträchtliche Zeit lang in Anspruch. Am Ende fragte ich ihn, was er über das Treffen denkt, und ich werde seine Antwort nie vergessen. Er sagte: „Früher dachte ich, es gibt in unserer Bank nur zwei Möglichkeiten zur Softwarebereitstellung, und jetzt weiß ich, dass es tatsächlich fünf sind, von denen ich bei dreien nicht einmal wusste.“
(Diese Illustration kann separat )
Das letzte Treffen in dieser Bank fand mit dem Team statt, das sich mit Investment-Software beschäftigt. Dabei stellte sich heraus, dass es besser ist, Diagramme mit einem Marker auf einem Blatt 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 verwendeten wir, um Muster, also Archetypen zu finden.
Ich stelle also Fragen an die Mitarbeiter, die ihre Antworten mit Markern in drei Farben (schwarz, rot und blau) aufschreiben. Ich analysiere ihre Antworten auf Archetypen. Lassen Sie uns jetzt 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 unbekannter Arbeit. Zum Beispiel, wenn ein Mitarbeiter den anderen einfach um etwas bittet. In großen Organisationen kann der Anteil an ungeplanter Arbeit bei 60 % liegen. Bis zu 40 % der Arbeit ist nicht dokumentiert. Wäre das Boeing, würde ich nie wieder in einen ihrer Flugzeuge steigen. Wenn nur die Hälfte der Arbeit dokumentiert wird, ist unklar, ob die Arbeit richtig erledigt wird oder nicht. Alle anderen Methoden erweisen sich als nutzlos — es hat keinen Sinn, irgendetwas zu automatisieren, weil die bekannten 50 % gerade der am besten abgestimmte und klarste Teil der Arbeit sein könnten, dessen Automatisierung keine großen Ergebnisse liefert, während alles Schlimme in der unsichtbaren Hälfte steckt. Ohne Dokumentation ist es unmöglich, allerlei Hacks und versteckte Arbeit zu finden oder Engpässe, die sogenannten "Brent-Points", auf die ich bereits hingewiesen habe. Es gibt ein hervorragendes Buch von Dominica DeGrandis, . Es identifiziert fünf verschiedene "Zeitdiebe" (thieves of time):
- Zu viel Arbeit im Prozess (WIP)
- Unbekannte Abhängigkeiten
- Ungeplante Arbeit
- Konfligierende Prioritäten
- Vernachlässigte Arbeit
Dies ist eine äußerst wertvolle Analyse, und das Buch ist großartig, aber all diese Ratschläge sind nutzlos, wenn nur 50 % der Daten sichtbar sind. Die von Dominik vorgeschlagenen Methoden können angewendet werden, wenn eine Genauigkeit von über 90 % erreicht wird. Ich spreche von Situationen, in denen ein Vorgesetzter seinem Mitarbeiter eine 15-minütige Aufgabe gibt, die jedoch drei Tage benötigt; der Vorgesetzte weiß in Wirklichkeit nicht, dass dieser Mitarbeiter auch von vier oder fünf anderen Personen abhängig ist.
Das Phoenix-Projekt ist eine faszinierende Geschichte über ein Projekt, das drei Jahre zu spät kommt. Einer der Protagonisten steht deshalb vor der Gefahr, entlassen zu werden, und trifft 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 im Unternehmen einen Systemadministrator namens Brent gibt, und die gesamte Arbeit läuft irgendwie über ihn. In einer der Besprechungen fragt einer der Untergebenen: Warum dauert jede halbstündige Aufgabe eine Woche? Als Antwort folgt eine stark vereinfachte Darstellung der Warteschlangentheorie und des Little’schen Gesetzes, und in dieser Darstellung wird klar, dass bei 90% Auslastung jede Arbeitsstunde 9 Stunden kostet. Jede Aufgabe muss an sieben andere Personen gesendet werden, daher verwandelt sich diese Stunde in 63 Stunden, 7 mal 9. Ich sage das, um zu verdeutlichen, dass man, um das Little’sche Gesetz oder eine komplexe Warteschlangentheorie anzuwenden, zumindest über Daten verfügen muss.
Wenn ich also von Sichtbarkeit spreche, meine ich nicht, dass alles auf dem Bildschirm sein muss, sondern dass zumindest Daten verfügbar sein sollten. Wenn sie vorhanden sind, zeigt sich oft, dass es einen sehr großen Umfang an ungeplanten Arbeiten gibt, die aus irgendwelchen Gründen an Brent gehen, obwohl es dafür keinen Bedarf gibt. Und Brent ist ein großartiger Kerl, er würde niemals 'nein' sagen, aber er erzählt auch niemandem, wie er seine Arbeit macht.
Wenn die Arbeit sichtbar ist, können die Daten sorgfältig klassifiziert werden (genau das macht Dominika auf dem Foto), man kann die Abstraktion der fünf Zeitverschwendungen anwenden und automatisieren.
2. Konsolidierung von Arbeitsmanagementsystemen: Aufgabenverwaltung
Die Archetypen, von denen ich spreche, bilden eine Art Pyramide. Wenn das erste richtig umgesetzt wird, ist das zweite gewissermaßen eine Art Erweiterung. Viele dieser Systeme sind nicht für Startups geeignet und sollten in Bezug auf große Unternehmen wie die im Fortune 5000 berücksichtigt werden. In meiner letzten Firma gab es 10 Fehlerverfolgungssysteme (Ticketing-System). In einem Team wurde Remedy verwendet, ein anderes entwickelte ein eigenes System, ein weiteres nutzte Jira, und manche kamen ganz ohne aus und arbeiteten mit E-Mails. Das gleiche Problem tritt auf, wenn eine Firma 30 unterschiedliche Pipelines hat, aber ich habe nicht die Zeit, all diese Fälle zu besprechen.
Ich bespreche mit den Leuten, wie Tickets erstellt werden, was danach mit ihnen passiert und wie sie umgangen werden. Das Interessanteste ist, dass die Menschen bei unseren Treffen ziemlich ehrlich sprechen. Ich habe gefragt, wie viele Leute für Tickets, denen man tatsächlich ‚major impact‘ zuweisen sollte, ‚minor / no impact‘ angeben. Es stellte sich heraus, dass fast jeder das so macht. Ich betreibe keine Denunziation und versuche auf jede erdenkliche Weise, die Personen nicht zu identifizieren. Wenn mir jemand etwas Aufrichtiges anvertraut, gebe ich die Person nicht preis. Aber wenn so gut wie jeder das System umgeht, bedeutet das, dass die gesamte Sicherheit im Grunde genommen eine Fassade ist. Daher können aus den Daten dieses Systems keine Schlussfolgerungen gezogen werden.
Um das Problem mit den Tickets zu lösen, muss ein zentrales System ausgewählt werden. Wenn Sie Jira verwenden, dann nur Jira. Wenn es eine Alternative gibt, dann sollte nur diese verwendet werden. Der Punkt ist, dass Tickets als ein weiterer Schritt im Entwicklungsprozess betrachtet werden müssen. Jede Aktion sollte ein Ticket haben, das durch den Entwicklungsprozess gehen muss. Die Tickets werden an das Team gesendet, das sie auf dem Storyboard platziert und dann die Verantwortung dafür trägt.
Dies betrifft alle Abteilungen, einschließlich der Infrastruktur- und Betriebsabteilung. In diesem Fall kann ein auch nur halbwegs plausibles Bild der Situation erstellt werden. Wenn dieser Prozess einmal etabliert ist, zeigt sich plötzlich, dass es einfach ist, festzustellen, wer für jede Anwendung verantwortlich ist. Denn jetzt erhalten wir nicht 50 %, sondern 98 % neuer Dienstleistungen. Wenn dieser wesentliche Prozess funktioniert, verbessert sich die Genauigkeit im gesamten System.
Service-Pipeline
Das betrifft wiederum 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 Unternehmen der Fortune 5000 betrifft, so ist ein Vorfall, der bei der Bank, in der ich gearbeitet habe, emblematisch. Sie wurden von Google besucht und es wurden Diagramme zu alten IBM-Systemen gezeigt. Die Leute von Google fragten verwundert — und wo ist der Quellcode dafür? Es gibt keinen Quellcode, nicht einmal eine GUI. Das ist die Realität, mit der große Organisationen umgehen müssen: 40 Jahre alte Bankaufzeichnungen auf einem uralten Mainframe. Einer meiner Kunden verwendet Kubernetes-Container mit Circuit-Breaker-Mustern sowie Chaos Monkey, alles für die Anwendung von KeyBank. Aber letztendlich werden diese Container mit einer COBOL-Anwendung verbunden.
Die Leute von Google waren sich sicher, dass sie alle Probleme meines Kunden lösen würden, bis sie Fragen stellten: Was ist IBM datapipe? Die Antwort darauf lautet: Das ist ein Connector. Woran ist er angeschlossen? An das System von Sperry. Und das? Und so weiter. Auf den ersten Blick scheint es so: Wo hat DevOps hier Platz? Aber tatsächlich ist es möglich. Es gibt Liefersysteme, die es ermöglichen, Arbeitsabläufe an die Teams weiterzugeben, die mit der Lieferung beschäftigt sind.
3. Theorie der Einschränkungen: Theorie der Einschränkungen
Kommen wir zum dritten Archetyp: institutionelles / „stammes“ Wissen. In der Regel gibt es in jeder Organisation mehrere Personen, die alles wissen und die Leitung übernehmen. Das sind die, die am längsten in der Organisation sind und die alle Abkürzungen kennen.
Wenn dies in der Grafik sichtbar wird, umkreise ich diese Personen gezielt mit einem Marker: Zum Beispiel stellt sich heraus, dass ein gewisser Lou an allen Meetings teilnimmt. Für mich ist klar: Das ist der lokale Brent. Wenn der IT-Direktor zwischen mir in T-Shirt und Turnschuhen und einem type in Anzug von IBM wählen muss, wähle ich, weil ich dem Direktor Dinge erklären kann, die der andere Typ nicht erklären kann und die für den Direktor unangenehm sein könnten. Ich sage ihnen, dass es in ihrem Unternehmen einen Engpass gibt, und dass es jemanden namens Fred und jemanden namens Lou gibt. Dieser Engpass muss gelöst werden, ihr Wissen muss irgendwie von ihnen erlangt werden.
Um ein solches Problem zu lösen, könnte ich zum Beispiel vorschlagen, Slack zu verwenden. Ein cleverer Geschäftsführer könnte fragen — warum? In solchen Fällen antworten DevOps-Berater oft: weil alle das so machen. Wenn der Geschäftsführer wirklich clever ist, wird er sagen: und was kommt jetzt? Und damit endet der Dialog. Ich antworte darauf: weil es in der Firma vier Engpässe gibt: Fred, Lu, Suzy und Jane. Um ihr Wissen zu institutionalisieren, muss man zunächst Slack einführen. Alle eure Wikis sind völliger Unsinn, weil niemand von ihrer Existenz weiß. Wenn das Ingenieurteam an externen und internen Entwicklungen arbeitet, sollten alle wissen, dass sie die externe Entwicklungs- oder das Infrastrukturteam mit Fragen ansprechen können. Genau dann wird wahrscheinlich Lu oder Fred Zeit finden, sich das Wiki anzusehen. Und dann kann jemand in Slack fragen, warum Schritt 5 nicht funktioniert. Und dann werden Lu oder Fred die Anleitung im Wiki korrigieren. Wenn dieser Prozess eingerichtet wird, wird vieles von selbst seinen Platz finden.
Hier liegt meine wichtigste Überlegung: Um moderne Technologien zu empfehlen, muss zunächst die Grundlage dafür geschaffen werden. Dies kann mit den zuvor beschriebenen, einfacheren Lösungen erreicht werden. Beginnt man jedoch mit High-Tech-Lösungen, ohne zu erklären, warum sie erforderlich sind, endet das normalerweise nicht gut. Einer unserer Kunden nutzt Azure ML, eine sehr kostengünstige und einfache Lösung. Bei etwa 30 % der Fragen wurde bereits durch die selbstlernende Maschine geantwortet. Die Entwickler dieser Lösung waren keine Data-Science-Experten, Statistiker oder Mathematiker. Das ist bemerkenswert. Die Kosten für eine solche Lösung sind minimal.
4. Collaboration hacks: Хаки сотрудничества
Das vierte Archetyp besteht darin, dass Isolation bekämpft werden muss. Die meisten Menschen wissen bereits, dass Isolation Feindschaft hervorruft. Wenn jede Abteilung auf ihrer eigenen Etage ist und die Menschen sich nur im Aufzug begegnen, dann entsteht leicht Feindschaft zwischen ihnen. Wenn die Menschen hingegen im selben Raum sind, verschwindet sie sofort. Wenn jemand eine allgemeine Beschwerde äußert, wie zum Beispiel, dass eine bestimmte Schnittstelle nie funktioniert - es könnte nicht einfacher sein, diese Beschwerde zu dekonstruktivieren. Für die Programmierer, die die Schnittstelle erstellt haben, reicht es aus, spezifische Fragen zu stellen, und bald wird klar, dass der Benutzer beispielsweise das Tool einfach falsch genutzt hat.
Es gibt viele Möglichkeiten, Isolation zu überwinden. Einmal wurde ich gebeten, eine Bank in Australien zu beraten, aber ich habe abgelehnt, da ich zwei Kinder und eine Frau habe. Alles, was ich ihnen anbieten konnte, war, ihnen *graphical storytelling* zu empfehlen. Das hat sich als wirksam erwiesen. Eine weitere interessante Methode sind Lean-Coffee-Meetings. In großen Organisationen ist das eine hervorragende Möglichkeit, Wissen zu verbreiten. Außerdem können interne DevOps-Tage, Hackathons und dergleichen veranstaltet werden.
5. Coaching Kata
Wie ich zu Beginn bereits erwähnt habe, werde ich heute nicht darüber sprechen. Wenn es Sie interessiert, können Sie sich .
Es gibt auch einen guten Vortrag zu diesem Thema von Mike Rother:
6. Marktorientiert: eine marktorientierte Organisation
Hier gibt es verschiedene Probleme. Zum Beispiel Menschen des Typs „I“, Menschen des Typs „T“ und Menschen des Typs „E“. Menschen des Typs „I“ sind diejenigen, die sich nur mit einer Sache beschäftigen. Normalerweise sind sie in Organisationen mit isolierten Abteilungen anzutreffen. „T“ bedeutet, dass eine Person in einem Bereich gut ist, aber auch in anderen Dingen erfolgreich ist. „E“ oder sogar „Kamm“ bedeutet, dass eine Person viele Fähigkeiten hat.
Hier gilt das Conway-Gesetz (), die in maximal vereinfachter Form so zusammengefasst werden kann: Wenn drei Teams an einem Compiler arbeiten, entsteht letztendlich ein Compiler aus drei Teilen. Daher wird, wenn in einer Organisation ein hohes Maß an Isolierung herrscht, selbst Kubernetes, Circuit Breaker, API-Erweiterbarkeit und andere modische Dinge in dieser Organisation so strukturiert sein wie die Organisation selbst. Streng nach Conway und zum Trotz, junge Geeks.
Die Lösung dieses Problems wurde schon oft beschrieben. Es gibt beispielsweise organisatorische Archetypen, die von Fernando Fernandez beschrieben wurden. Die problematische Architektur, von der ich gerade sprach, mit Isolierung — das ist eine funktional orientierte Architektur. Der zweite Typ — der schlechteste, ist die Matrixarchitektur, dort gibt es ein Durcheinander aus den beiden anderen. Der dritte Typ — das ist das, was in den meisten Startups zu beobachten ist, und auch große Unternehmen versuchen, diesem Typ zu entsprechen. Das ist eine marktorientierte Organisation. Hier erfolgt die Optimierung, um die schnellste 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 wird dies genannt zwei Pizza-Teams. In dieser Struktur gruppieren sich alle Personen des Typs „I“ um einen Dienst, und nach und nach kommen sie dem Typ „T“ näher. Wenn das Management gut funktioniert, können sie sogar zu „E“ werden. Das erste Gegenargument ist hier, dass es in einer solchen Struktur überflüssige Elemente gibt. Warum benötigt man einen Tester in jeder Abteilung, wenn es möglich ist, eine spezielle Abteilung für Tester zu haben? Darauf antworte ich: Überflüssige Ausgaben in diesem Fall sind der Preis, den man dafür bezahlt, dass die gesamte Organisation in Zukunft Typ „E“ wird. In einer solchen Struktur erfährt der Tester nach und nach mehr über Netzwerke, Architektur, Design usw. Am Ende ist jeder Teilnehmer der Organisation vollständig über alles informiert, was in der Organisation passiert. Wenn Sie erfahren möchten, wie dieses Schema in der Industrie funktioniert, lesen Sie .
7. Shift-left Auditors: Audits in den frühen Phasen des Zyklus. Einhaltung von Sicherheitsrichtlinien sichtbar
Das ist, wenn Ihre Handlungen sozusagen nicht die Geruchsprüfung bestehen. Die Menschen, die für Sie arbeiten, sind nicht dumm. Wenn sie, wie im obigen Beispiel, überall geringfügige/keine Auswirkungen angeben, und das über drei Jahre hinweg, ohne dass jemand etwas bemerkt, weiß jeder, dass das System nicht funktioniert. Oder ein anderes 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 gemerkt, dass unsere Systeme extrem komplex sind. Und fünf bis sechs Personen müssen eine Entscheidung über eine Änderung treffen, die sie nicht vorgenommen haben und über die sie nichts wissen.
Natürlich funktioniert ein solcher Ansatz nicht. Ich muss mich von solchen Dingen trennen, weil diese Personen das System nicht schützen. Die Entscheidung sollte vom Team selbst getroffen werden, da das Team dafür verantwortlich sein muss. Andernfalls entsteht eine paradoxe Situation, in der ein Manager, der in seinem Leben noch nie Code geschrieben hat, einem Programmierer sagt, wie viel Zeit das Schreiben des Codes in Anspruch nehmen sollte. In einem Unternehmen, in dem ich gearbeitet habe, gab es 7 verschiedene Gremien, die jede Änderung prüften, darunter ein Architektur- und ein Produktgremium usw. Es gab sogar eine verpflichtende Wartezeit, obwohl mir ein Mitarbeiter sagte, dass in zehn Jahren niemand während dieser Wartezeit jemals Änderungen abgelehnt hat, die von dieser Person vorgenommen wurden.
Auditoren sollten zu uns eingeladen werden, anstatt sie loszuwerden. Lassen Sie sie wissen, dass Sie immutable binary containers erstellen, die, wenn sie alle Tests bestehen, für immer unverändert bleiben. Erklären Sie ihnen, dass Sie ein pipeline as code haben, und was das bedeutet. Zeigen Sie ihnen das folgende Diagramm: ein lesbarer immutable Binary in einem Container, der alle Schwachstellentests besteht; und darüber hinaus greift niemand darauf zu – nicht einmal auf das System, das die Pipeline erstellt, da es ebenfalls dynamisch erstellt wird. Ich habe Kunden wie Capital One, die mithilfe von Vault etwas Ähnliches wie Blockchain schaffen. Einem Auditor können Sie die "Rezepte" von Chef vorenthalten; es genügt, die Blockchain zu zeigen, aus der klar hervorgeht, was mit dem Jira-Ticket in der Produktion passiert ist und wer dafür verantwortlich ist.
Laut , das 2018 von Sonatype gegründet wurde, gab es im Jahr 2017 87 Milliarden Downloadanfragen für OSS.
Die durch Sicherheitsanfälligkeiten verursachten Verluste sind übermäßig hoch. Die oben dargestellten Zahlen beinhalten zudem keine alternativen Kosten. Kurz gesagt, was DevSecOps bedeutet: Ich möchte gleich klarstellen, dass mich Diskussionen über die Relevanz des Begriffs nicht interessieren. Der Punkt ist, dass, wenn DevOps schon sehr erfolgreich waren, wir versuchen sollten, Sicherheit in diesen Prozess zu integrieren.
Ein Beispiel für eine solche Sequenz:
Dies ist keine Empfehlung für bestimmte Produkte, obwohl ich sie alle schätze. Ich nenne sie als Beispiele, um zu zeigen, dass DevOps, das ursprünglich auf der Paradigmenorganisation in der Industrie basiert, es ermöglicht, jeden Schritt im Produktentwicklungsprozess zu automatisieren.
Und es gibt keinen Grund, warum wir denselben Ansatz nicht auch auf die Sicherheit anwenden sollten.
Zusammenfassung
Abschließend möchte ich einige Ratschläge für DevSecOps geben. Es ist wichtig, die Auditoren in den Prozess der Entwicklung Ihrer Systeme einzubeziehen und Zeit in ihre Schulung zu investieren. Die Zusammenarbeit mit Auditoren ist entscheidend. Darüber hinaus sollte ein radikaler Ansatz zur Bekämpfung von Fehlalarmen verfolgt werden. Selbst mit dem teuersten Schwachstellenscanner können schädliche Gewohnheiten bei Ihren Entwicklern entstehen, wenn Sie nicht wissen, wie das Verhältnis von Signal zu Rauschen ist. Entwickler werden von Ereignissen überwältigt und könnten sie einfach ignorieren. Wenn Sie von der Geschichte mit Equifax gehört haben, geschah genau das: Ein Signal von höchster Dringlichkeit wurde ignoriert. Außerdem müssen Schwachstellen so erklärt werden, dass klar ist, wie sie das Geschäft beeinflussen. Zum Beispiel kann gesagt werden, dass dies die gleiche Schwachstelle ist wie in der Geschichte mit Equifax. Sicherheitsrelevante Schwachstellen sollten genauso betrachtet werden wie andere Softwareprobleme; sie müssen in den allgemeinen DevOps-Prozess integriert werden. Sie sollten über Jira, Kanban usw. bearbeitet werden. Entwickler sollten nicht denken, dass sich jemand anders darum kümmert – im Gegenteil, das muss von allen angegangen werden. Schließlich sollte auch die Bildung der Menschen gefördert werden.
Nützliche Links
Hier sind einige Berichte von der DevOops-Konferenz, die für Sie nützlich sein könnten:
- Sergei Berdnikov, Artyom Kalichkin — Erfolgsgeschichte oder „Dev+DevOps+Ops“ (, )
- Baruch Sadogursky, Leonid Igolnik — DevOps im großen Maßstab: Griechische Tragödie in drei Akten (, )
- Alexander Titov, Kirill Tolkachyov —
- Timothy Lister —
Schauen Sie in das DevOops 2020 Moskau — auch dort gibt es viele interessante Aspekte.
Quelle: habr.com
