Die Frage „Wie implementiert man Entwickler?“ beschäftigt sich schon seit Jahren, aber es gibt nicht viele gute Materialien. Manchmal werden Sie Opfer der Werbung von nicht so klugen Beratern, die ihre Zeit verkaufen müssen, egal wie. Manchmal sind das vage, äußerst allgemeine Worte darüber, wie die Schiffe von Megakonzernen die Weiten des Universums durchpflügen. Es stellt sich die Frage: Was geht uns das an? Lieber Autor, können Sie Ihre Ideen in einer Liste klar formulieren?
All dies ist auf die Tatsache zurückzuführen, dass sich nicht viel wirkliche Praxis und Verständnis für die Ergebnisse von Transformationen der Unternehmenskultur angesammelt haben. Kulturelle Veränderungen sind langfristige Dinge, deren Ergebnisse nicht in einer Woche oder einem Monat sichtbar werden. Wir brauchen jemanden, der alt genug ist, um zu sehen, wie Unternehmen im Laufe der Jahre aufgebaut und gescheitert sind.
John Willis – einer der Väter von DevOps. John verfügt über jahrzehntelange Erfahrung in der Zusammenarbeit mit einer Vielzahl von Unternehmen. Vor kurzem bemerkte John bestimmte Muster, die bei der Arbeit mit jedem von ihnen auftraten. Mithilfe dieser Archetypen führt John Unternehmen auf dem wahren Weg der DevOps-Transformation. Lesen Sie mehr über diese Archetypen in der Übersetzung seines Berichts von der DevOops-Konferenz 2018.
Über den Sprecher:
Mehr als 35 Jahre im IT-Management, an der Gründung des Vorgängers von OpenCloud bei Canonical beteiligt, an 10 Startups beteiligt, von denen zwei an Dell und Docker verkauft wurden. Derzeit ist er Vizepräsident für DevOps und digitale Praktiken bei SJ Technologies.
Als nächstes folgt die Geschichte aus Johns Sicht.
Mein Name ist John Willis und der einfachste Ort, mich zu finden, ist auf Twitter. . Ich habe den gleichen Alias auf Gmail und GitHub. A Hier finden Sie Videoaufzeichnungen meiner Berichte und Präsentationen dazu.
Ich habe viele Treffen mit CIOs verschiedener großer Unternehmen. Sie beschweren sich sehr oft darüber, dass sie nicht verstehen, was DevOps ist, und dass jeder, der versucht, es ihnen zu erklären, über etwas anderes spricht. Eine weitere häufige Beschwerde ist, dass DevOps nicht funktioniert, obwohl die Direktoren anscheinend alles so machen, wie es ihnen erklärt wurde. Wir sprechen von großen Unternehmen, die mehr als hundert Jahre alt sind. Nach Gesprächen mit ihnen bin ich zu dem Schluss gekommen, dass für viele Probleme nicht High-Tech am besten geeignet ist, sondern relativ Low-Tech-Lösungen. Wochenlang habe ich einfach mit Leuten aus verschiedenen Abteilungen gesprochen. Was Sie auf dem allerersten Bild im Beitrag sehen, ist mein letztes Projekt, so sah der Raum nach drei Tagen Arbeit aus.
Was ist DevOps?
Wenn Sie 10 verschiedene Personen fragen, werden sie tatsächlich 10 verschiedene Antworten geben. Aber hier ist das Interessante: Alle zehn dieser Antworten werden richtig sein. Hier gibt es keine falsche Antwort. Ich war ungefähr zehn Jahre lang ziemlich tief in DevOps vertieft und war der erste Amerikaner beim ersten DevOpsDay. Ich werde nicht sagen, dass ich schlauer bin als alle, die mit DevOps zu tun haben, aber es gibt kaum jemanden, der sich so viel Mühe gegeben hat. Ich glaube, dass DevOps entsteht, wenn Humankapital und Technologie zusammenkommen. Wir vergessen oft die menschliche Dimension, obwohl wir viel über alle möglichen Kulturen sprechen.
Jetzt haben wir viele Daten, fünf Jahre akademische Forschung und die Überprüfung von Theorien im industriellen Maßstab. Aus diesen Studien geht hervor, dass die Kombination bestimmter Verhaltensmuster in einer Unternehmenskultur zu einer 2000-fachen Beschleunigung führen kann. Mit dieser Beschleunigung geht eine entsprechende Verbesserung der Stabilität einher. Dies ist eine quantitative Messung des Nutzens, den DevOps jedem Unternehmen bringen kann. Vor ein paar Jahren sprach ich mit dem CEO eines Fortune-5000-Unternehmens über DevOps. Als ich mich auf die Präsentation vorbereitete, war ich sehr nervös, weil ich meine jahrelange Erfahrung in 5 Minuten zusammenfassen musste.
Am Ende habe ich Folgendes gegeben DevOps-Definition: Es handelt sich um eine Reihe von Praktiken und Mustern, die die Umwandlung von Humankapital in leistungsstarkes Organisationskapital ermöglichen. Ein Beispiel ist die Art und Weise, wie Toyota in den letzten 50 oder 60 Jahren operiert hat.
(Im Folgenden werden solche Diagramme nicht als Referenzmaterial, sondern als Illustrationen bereitgestellt. Ihr Inhalt wird für jedes neue Unternehmen unterschiedlich sein. Das Bild kann jedoch separat betrachtet und vergrößert werden
Eine der erfolgreichsten Praktiken dieser Art ist Wertstromanalyse. Darüber wurden mehrere gute Bücher geschrieben, das erfolgreichste davon stammt von Karen Martin. Aber im Laufe des letzten Jahres bin ich zu dem Schluss gekommen, dass selbst dieser Ansatz zu hochtechnologisch ist. Es hat sicherlich viele Vorteile und ich habe es oft genutzt. Wenn der CEO Sie jedoch fragt, warum sein Unternehmen nicht auf neue Schienen umsteigen kann, ist es noch zu früh, um über die Abbildung von Wertströmen zu sprechen. Es gibt viele, viel grundlegendere Fragen, die zunächst beantwortet werden müssen.
Ich denke, der Fehler, den viele meiner Kollegen machen, besteht darin, dass sie dem Unternehmen einfach einen Fünf-Punkte-Leitfaden geben und dann sechs Monate später zurückkommen und sehen, was passiert ist. Sogar ein gutes Schema wie die Wertstromanalyse weist, sagen wir mal, blinde Flecken auf. Nach Hunderten von Interviews mit Direktoren verschiedener Unternehmen habe ich ein bestimmtes Muster entwickelt, das es uns ermöglicht, das Problem in seine Komponenten zu zerlegen, und nun werden wir jede dieser Komponenten der Reihe nach diskutieren. Bevor ich irgendwelche technologischen Lösungen anwende, verwende ich dieses Muster und als Ergebnis sind alle meine Wände mit Diagrammen bedeckt. Kürzlich arbeitete ich mit einem Investmentfonds zusammen und hatte am Ende 100 bis 150 solcher Programme.
Schlechte Kultur frisst gute Ansätze zum Frühstück
Die Grundidee ist folgende: Lean, Agile, SAFE und DevOps helfen nicht, wenn die Unternehmenskultur selbst schlecht ist. Es ist, als würde man ohne Tauchausrüstung in die Tiefe tauchen oder ohne Röntgenaufnahme operieren. Mit anderen Worten, um Drucker und Deming zu paraphrasieren: Eine schlechte Organisationskultur wird jedes gute System verschlingen, ohne daran zu ersticken.
Um dieses Hauptproblem zu lösen, müssen Sie die folgenden Schritte ausführen:
- Machen Sie alle Arbeiten sichtbar: Sie müssen die gesamte Arbeit sichtbar machen. Nicht in dem Sinne, dass es unbedingt auf einem Bildschirm angezeigt werden muss, sondern in dem Sinne, dass es beobachtbar sein muss.
- Konsolidierte Arbeitsmanagementsysteme: Managementsysteme müssen konsolidiert werden. Beim Problem des „Stammeswissens“ und des institutionellen Wissens sind in neun von zehn Fällen die Menschen der Engpass. Im Buch Das Problem lag bei einer einzigen Person, Brent, die dafür sorgte, dass das Projekt drei Jahre hinter dem Zeitplan zurückblieb. Und diese „Brents“ treffe ich überall. Um diese Engpässe zu beheben, verwende ich die nächsten beiden Punkte auf unserer Liste.
- Methodik der Constrainttheorie: Theorie der Beschränkungen.
- Hacks zur Zusammenarbeit: Hacks für die Zusammenarbeit.
- Toyota Kata (): Ich werde nicht viel über den Toyota Kata sprechen. Bei Interesse auf meinem Github zu fast jedem dieser Themen.
- Marktorientierte Organisation: marktorientierte Organisation.
- Shift-Left-Prüfer: Prüfung in frühen Phasen des Zyklus.
Die Zusammenarbeit mit einer Organisation beginne ich ganz einfach: Ich gehe zur Firma und rede mit den Mitarbeitern. Wie Sie sehen, keine Hochtechnologie. Alles, was Sie brauchen, ist etwas zum Schreiben. Ich versammle mehrere Teams in einem Raum und analysiere, was sie mir aus der Perspektive meiner 7 Archetypen sagen. Und dann gebe ich ihnen selbst einen Stift und bitte sie, alles, was sie bisher laut gesagt haben, an die Tafel zu schreiben. Normalerweise gibt es bei solchen Meetings eine Person, die alles aufschreibt, und bestenfalls kann er 10 % der Diskussion aufschreiben. Mit meiner Methode lässt sich dieser Wert auf ca. 40 % steigern.
(Diese Abbildung kann separat betrachtet werden )
Mein Ansatz basiert auf der Arbeit von William Schneider. ). Der Ansatz basiert auf der Idee, dass jede Organisation in vier Quadrate unterteilt werden kann. Für mich ist dieses Schema normalerweise das Ergebnis der Arbeit mit Hunderten anderer Schemata, die bei der Analyse einer Organisation auftauchen. Angenommen, wir haben eine Organisation mit einem hohen Maß an Kontrolle, aber geringer Kompetenz. Dies ist eine äußerst unerwünschte Option: Wenn sich alle an die Regeln halten, aber niemand weiß, was zu tun ist.
Eine etwas bessere Option ist eine mit einem hohen Maß an Kontrolle und Kompetenz. Wenn ein solches Unternehmen profitabel ist, braucht es DevOps vielleicht nicht. Am interessantesten ist es, mit einem Unternehmen zusammenzuarbeiten, das über ein hohes Maß an Kontrolle, geringe Kompetenz und Zusammenarbeit, aber gleichzeitig über ein hohes Maß an Kultur (Kultivierung) verfügt. Das bedeutet, dass das Unternehmen viele Leute hat, die gerne dort arbeiten, und die Fluktuation gering ist.
(Diese Abbildung kann separat betrachtet werden )
Es scheint mir, dass Methoden mit starren Richtlinien am Ende der Erreichung der Wahrheit im Weg stehen. Gerade bei der Wertstromanalyse gibt es viele Regeln, wie Informationen strukturiert sein sollten. In den frühen Phasen der Arbeit, von denen ich jetzt spreche, braucht niemand diese Regeln. Wenn jemand mit einem Marker in der Hand an der Tafel die reale Situation im Unternehmen beschreibt, ist dies der beste Weg, den Sachverhalt zu verstehen. Solche Informationen gelangen nicht an die Direktoren. In diesem Moment ist 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 durch die Verwendung mehrfarbiger Markierungen erstellt werden.
Ich wiederhole, keine Hochtechnologie. Der schwarze Marker stellt die objektive Realität dar, wie alles funktioniert. Mit einem roten Marker markieren Menschen, was ihnen am aktuellen Stand der Dinge nicht gefällt. Es ist wichtig, dass sie das schreiben, nicht ich. Wenn ich nach einem Meeting zum CIO gehe, biete ich ihm keine Liste mit 10 Dingen an, die behoben werden müssen. Ich bemühe mich, Zusammenhänge zwischen dem, was die Leute im Unternehmen sagen, und bestehenden bewährten Mustern zu finden. Abschließend schlägt ein blauer Marker mögliche Lösungen für das Problem vor.
(Diese Abbildung kann separat betrachtet werden )
Ein Beispiel für diesen Ansatz ist nun oben dargestellt. Anfang dieses Jahres habe ich mit einer Bank zusammengearbeitet. Die Sicherheitsleute dort waren davon überzeugt, dass sie nicht zu Design- und Anforderungsüberprüfungen kommen sollten.
(Diese Abbildung kann separat betrachtet werden )
Und dann sprachen wir mit Leuten aus anderen Abteilungen und es stellte sich heraus, dass Softwareentwickler vor etwa acht Jahren Sicherheitskräfte entlassen hatten, weil sie die Arbeit verlangsamten. Und dann wurde daraus ein Verbot, das als selbstverständlich angesehen wurde. Obwohl es in Wirklichkeit kein Verbot gab.
Unser Treffen verlief äußerst verwirrend: Etwa drei Stunden lang konnten mir fünf verschiedene Teams nicht erklären, was zwischen dem Code und der Assembly passierte. Und das scheint die einfachste Sache zu sein. Die meisten DevOps-Berater gehen von vornherein davon aus, dass dies bereits jeder weiß.
Dann wurde der IT-Governance-Verantwortliche, der vier Stunden lang geschwiegen hatte, plötzlich lebendig, als wir zu seinem Thema kamen, und beschäftigte uns sehr lange. Am Ende fragte ich ihn, was er von dem Treffen halte, und ich werde seine Antwort nie vergessen. Er sagte: „Früher dachte ich, unsere Bank hätte nur zwei Möglichkeiten, Software bereitzustellen, aber jetzt weiß ich, dass es fünf davon gibt, und von drei wusste ich nicht einmal.“
(Diese Abbildung kann separat betrachtet werden )
Das letzte Treffen bei dieser Bank fand mit dem Investmentsoftware-Team statt. Bei ihr stellte sich heraus, dass das Schreiben von Diagrammen mit einem Marker auf einem Blatt Papier besser ist 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 wir nutzten diese Schemata, um nach Mustern, also Archetypen, zu suchen.
Also stelle ich den Arbeitern Fragen, sie schreiben die Antworten mit dreifarbigen Markern (schwarz, rot und blau) auf. Ich analysiere ihre Antworten auf Archetypen. Lassen Sie uns nun alle Archetypen der Reihe nach besprechen.
1. Alle Arbeiten sichtbar machen: Machen Sie die Arbeit sichtbar
Die meisten Unternehmen, mit denen ich zusammenarbeite, haben einen sehr hohen Anteil unbekannter Arbeiten. Das ist zum Beispiel der Fall, wenn ein Mitarbeiter zu einem anderen kommt und ihn einfach darum bittet, etwas zu tun. In großen Organisationen kann es zu 60 % ungeplanter Arbeit kommen. Und bis zu 40 % der Arbeiten werden in keiner Weise dokumentiert. Wenn es Boeing wäre, würde ich nie wieder in ihrem Leben in ihr Flugzeug steigen. Wenn nur die Hälfte der Arbeiten dokumentiert ist, ist nicht bekannt, ob diese Arbeiten korrekt ausgeführt werden oder nicht. Alle anderen Methoden erweisen sich als nutzlos – es hat keinen Sinn, etwas zu automatisieren, da die bekannten 50 % möglicherweise der kohärenteste und klarste Teil der Arbeit sind, dessen Automatisierung keine großartigen Ergebnisse liefert, und das Schlimmste Die Dinge liegen in der unsichtbaren Hälfte. Ohne Dokumentation ist es unmöglich, alle möglichen Hacks und versteckten Arbeiten zu finden, ganz zu schweigen von den Engpässen, genau diesen „Brents“, über die ich bereits gesprochen habe. Es gibt ein wunderbares Buch von Dominica DeGrandis . Sie verrät fünf verschiedene „Zeitlecks“ (Diebe der Zeit):
- Zu viel Arbeit in Arbeit (WIP)
- Unbekannte Abhängigkeiten
- Ungeplante Arbeit
- Widersprüchliche Prioritäten
- Vernachlässigte Arbeit
Das ist eine sehr wertvolle Analyse und das Buch ist großartig, aber all diese Ratschläge sind nutzlos, wenn nur 50 % der Daten sichtbar sind. Die von Dominica vorgeschlagenen Methoden können eingesetzt werden, wenn eine Genauigkeit von über 90 % erreicht wird. Ich spreche von Situationen, in denen ein Chef einem Untergebenen eine 15-minütige Aufgabe gibt, dieser dafür aber drei Tage braucht; Aber der Chef weiß nicht wirklich, dass dieser Untergebene von vier oder fünf anderen Personen abhängig ist.
Das Phoenix-Projekt ist eine wundervolle Geschichte über ein Projekt, das drei Jahre zu spät kam. Einem der Charaktere droht aus diesem Grund die Entlassung, und er trifft auf 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 alle Arbeiten laufen irgendwie über ihn. Bei einem der Treffen wird einer der Untergebenen gefragt: Warum dauert jede halbstündige Aufgabe eine Woche? Die Antwort ist eine sehr vereinfachte Darstellung der Warteschlangentheorie und des Little-Gesetzes, und in dieser Darstellung stellt sich heraus, dass bei einer Auslastung von 90 % jede Arbeitsstunde 9 Stunden dauert. Jede Aufgabe muss an sieben andere Personen gesendet werden, sodass diese Stunde 63 Stunden beträgt, 7 mal 9. Der Punkt, den ich ansprechen möchte, ist, dass man zur Anwendung des Little'schen Gesetzes oder einer anderen komplexen Warteschlangentheorie zumindest über Daten verfügen muss.
Wenn ich also von Sichtbarkeit spreche, meine ich nicht, dass alles auf dem Bildschirm ist, sondern dass man zumindest über Daten verfügt. Dabei stellt sich oft heraus, dass eine große Menge ungeplanter Arbeit irgendwie an Brent weitergeleitet wird, obwohl kein Bedarf dafür besteht. Und Brent ist ein toller Kerl, er wird nie nein sagen, aber er erzählt niemandem, wie er seinen Job macht.
Wenn die Arbeit sichtbar ist, können die Daten sauber klassifiziert werden (das macht Dominika auf dem Foto), die Abstraktion der fünf Zeitlecks kann angewendet werden und die Automatisierung kann angewendet werden.
2. Konsolidieren Sie Arbeitsmanagementsysteme: Aufgabenverwaltung
Die Archetypen, von denen ich spreche, sind eine Art Pyramide. Wenn das erste richtig gemacht ist, ist das zweite bereits eine Art Add-on. Viele davon funktionieren nicht für Startups, sie müssen bei größeren Unternehmen wie den Fortune 5000 im Auge behalten werden. Das letzte Unternehmen, für das ich gearbeitet habe, hatte 10 Ticketsysteme. Ein Team hatte Remedy, ein anderes schrieb eine Art eigenes System, ein drittes nutzte Jira und einige begnügten sich mit E-Mail. Das gleiche Problem entsteht, wenn das Unternehmen über 30 verschiedene Pipelines verfügt, ich aber keine Zeit habe, alle derartigen Fälle zu besprechen.
Ich bespreche mit den Leuten genau, wie Tickets entstehen, was als nächstes mit ihnen passiert und wie sie umgangen werden. Das Interessanteste ist, dass die Leute bei unseren Treffen ganz aufrichtig sprechen. Ich habe gefragt, wie viele Leute „geringe/keine Auswirkung“ auf Tickets setzen, denen eigentlich „große Auswirkung“ zugeschrieben werden sollte. Es stellte sich heraus, dass dies fast jeder tut. Ich betreibe keine Denunziation und versuche auf jede erdenkliche Weise, Menschen nicht zu identifizieren. Wenn sie mir etwas aufrichtig gestehen, verrate ich die Person nicht. Aber wenn fast jeder das System umgeht, bedeutet das, dass alle Sicherheitsmaßnahmen im Wesentlichen nur Augenwischerei sind. Daher können aus den Daten dieses Systems keine Schlussfolgerungen gezogen werden.
Um das Ticketproblem zu lösen, müssen Sie ein Hauptsystem auswählen. Wenn Sie Jira verwenden, behalten Sie es bei Jira. Wenn es eine Alternative gibt, lass es die einzige sein. Im Endeffekt sollten Tickets als ein weiterer Schritt im Entwicklungsprozess betrachtet werden. Für jede Aktion muss ein Ticket vorhanden sein, das den Entwicklungsworkflow durchlaufen muss. Tickets werden an das Team gesendet, das sie auf dem Storyboard veröffentlicht und dann die Verantwortung dafür übernimmt.
Dies gilt für alle Abteilungen, einschließlich Infrastruktur und Betrieb. In diesem Fall ist es möglich, sich zumindest eine plausible Vorstellung von der Sachlage zu machen. Sobald dieser Prozess etabliert ist, lässt sich plötzlich leicht erkennen, wer für die einzelnen Anwendungen verantwortlich ist. Denn jetzt erhalten wir nicht 50 %, sondern 98 % der neuen Leistungen. Wenn dieser Kernprozess funktioniert, verbessert sich die Genauigkeit im gesamten System.
Dienstleistungspipeline
Dies gilt wiederum nur für Großkonzerne. Wenn Sie ein neues Unternehmen in einem neuen Bereich sind, krempeln Sie die Ärmel hoch und arbeiten Sie mit Ihrem Travis CI oder CircleCI. Wenn es um Fortune-5000-Unternehmen geht, passierte ein typisches Beispiel bei der Bank, bei der ich gearbeitet habe. Google kam zu ihnen und ihnen wurden Diagramme alter IBM-Systeme gezeigt. Die Jungs von Google fragten verwirrt: Wo ist der Quellcode dafür? Aber es gibt keinen Quellcode, nicht einmal eine GUI. Dies ist die Realität, mit der sich große Unternehmen auseinandersetzen müssen: 40 Jahre alte Bankunterlagen auf einem alten Großrechner. Einer meiner Kunden verwendet Kubernetes-Container mit Circuit Breaker-Mustern sowie Chaos Monkey, alles für die KeyBank-Anwendung. Aber diese Container stellen letztendlich eine Verbindung zu einer COBOL-Anwendung her.
Die Leute von Google waren völlig zuversichtlich, dass sie alle Probleme meines Kunden lösen würden, und dann begannen sie, Fragen zu stellen: Was ist IBM Datapipe? Ihnen wird gesagt: Das ist ein Stecker. Womit verbindet es sich? Zum Sperry-System. Und was ist das? Usw. Auf den ersten Blick scheint es: Was für DevOps kann es geben? Aber tatsächlich ist es möglich. Es gibt Liefersysteme, die es Ihnen ermöglichen, den Workflow an die Lieferteams zu übergeben.
3. Theorie der Beschränkungen: Theorie der Beschränkungen
Kommen wir zum dritten Archetyp: institutionelles/stammesbezogenes Wissen. In jeder Organisation gibt es in der Regel mehrere Personen, die alles wissen und alles verwalten. Dies sind diejenigen, die am längsten in der Organisation sind und alle Problemumgehungen kennen.
Wenn das auf dem Diagramm auftaucht, umkreise ich solche Personen gezielt mit einem Marker: Es stellt sich beispielsweise heraus, dass bei allen Besprechungen eine bestimmte Lou anwesend ist. Und für mich ist klar: Das ist heimischer Brent. Wenn der CIO zwischen mir im T-Shirt und Turnschuhen und dem Mann von IBM im Anzug wählt, werde ich ausgewählt, weil ich dem Direktor Dinge erzählen kann, die der andere nicht sagen würde und die der Direktor vielleicht nicht gerne hören würde . Ich erzähle ihnen, dass der Engpass in ihrem Unternehmen jemand namens Fred und jemand namens Lou sind. Dieser Engpass muss behoben werden, ihr Wissen muss auf die eine oder andere Weise von ihnen erworben werden.
Um ein solches Problem zu lösen, kann ich beispielsweise die Verwendung von Slack vorschlagen. Ein kluger Regisseur wird fragen: Warum? Typischerweise antworten DevOps-Berater in solchen Fällen: Weil es jeder tut. Wenn der Regisseur wirklich schlau ist, wird er sagen: Na und. Und hier endet der Dialog. Und meine Antwort darauf lautet: Weil es im Unternehmen vier Engpässe gibt, Fred, Lou, Susie und Jane. Um ihr Wissen zu institutionalisieren, muss man zunächst Slack einführen. Alle Ihre Wikis sind völliger Unsinn, weil niemand etwas über ihre Existenz weiß. Wenn das Engineering-Team an der Front-End- und Back-End-Entwicklung beteiligt ist und jeder wissen muss, dass er sich bei Fragen an das Front-End-Entwicklungsteam oder das Infrastrukturteam wenden kann. Dann werden Lou oder Fred wahrscheinlich Zeit haben, dem Wiki beizutreten. Und dann könnte jemand in Slack fragen, warum beispielsweise Schritt 5 nicht funktioniert. Und dann korrigieren Lou oder Fred die Anweisungen im Wiki. Wenn Sie diesen Prozess etablieren, wird sich vieles von selbst ergeben.
Das ist mein Hauptpunkt: Um Hochtechnologien empfehlen zu können, muss man zunächst die Grundlagen dafür schaffen, und das kann mit den gerade beschriebenen Low-Tech-Lösungen erreicht werden. Wenn man mit Hochtechnologien beginnt und nicht erklärt, warum sie benötigt werden, dann endet das in der Regel nicht gut. Einer unserer Kunden nutzt Azure ML, eine sehr günstige und einfache Lösung. Etwa 30 % ihrer Fragen wurden von der selbstlernenden Maschine selbst beantwortet. Und dieses Ding wurde von Betreibern geschrieben, die sich nicht mit Datenwissenschaft, Statistik oder Mathematik beschäftigten. Das ist bedeutsam. Die Kosten einer solchen Lösung sind minimal.
4. Hacks zur Zusammenarbeit: Hacks zur Zusammenarbeit
Der vierte Archetyp ist die Notwendigkeit, die Isolation zu bekämpfen. Die meisten Menschen wissen es bereits: Isolation erzeugt Feindseligkeit. Wenn sich jede Abteilung auf einer eigenen Etage befindet und sich die Menschen außer im Aufzug in keiner Weise kreuzen, kommt es sehr leicht zu Feindseligkeiten zwischen ihnen. Befinden sich hingegen Menschen im selben Raum, geht sie sofort weg. Wenn jemand einen allgemeinen Vorwurf erhebt, zum Beispiel, dass diese oder jene Schnittstelle nie funktioniert, gibt es nichts einfacheres, einen solchen Vorwurf zu dekonstruieren. Die Programmierer, die die Schnittstelle geschrieben haben, müssen nur anfangen, konkrete Fragen zu stellen, und schon wird klar, dass beispielsweise der Benutzer das Tool einfach falsch verwendet hat.
Es gibt viele Möglichkeiten, die Isolation zu überwinden. Einmal wurde ich gebeten, eine Bank in Australien zu beraten, aber ich weigerte mich, dies zu tun, weil ich zwei Kinder und eine Frau habe. Alles, was ich tun konnte, um ihnen zu helfen, war, grafisches Geschichtenerzählen zu empfehlen. Dies funktioniert nachweislich. Eine weitere interessante Möglichkeit sind Lean-Coffee-Meetings. In einer großen Organisation ist dies eine hervorragende Möglichkeit, Wissen zu verbreiten. Darüber hinaus können Sie interne Devopsdays, Hackathons usw. durchführen.
5. Coaching-Kata
Wie ich gleich zu Beginn gewarnt habe, werde ich heute nicht darüber sprechen. Wenn Sie Interesse haben, können Sie einen Blick darauf werfen .
Zu diesem Thema gibt es auch einen guten Vortrag von Mike Rother:
6. Marktorientiert: marktorientierte Organisation
Hier gibt es unterschiedliche Probleme. Zum Beispiel „I“-Personen, „T“-Personen und „E“-Personen. „Ich“-Menschen sind diejenigen, die nur eine Sache tun. Typischerweise gibt es sie in Organisationen mit isolierten Abteilungen. „T“ ist, wenn eine Person in einer Sache gut ist, aber auch in anderen Dingen gut. „E“ oder auch „Kamm“ bedeutet, dass eine Person über viele Fähigkeiten verfügt.
Hier gilt Conways Gesetz (), was in der einfachsten Form wie folgt ausgedrückt werden kann: Wenn drei Teams am Compiler arbeiten, dann ist das Ergebnis ein Compiler aus drei Teilen. Wenn also innerhalb einer Organisation ein hohes Maß an Isolation herrscht, werden sogar Kubernetes, Leistungsschalter, API-Erweiterbarkeit und andere ausgefallene Dinge in dieser Organisation auf die gleiche Weise angeordnet wie die Organisation selbst. Streng nach Conway und zum Ärger aller jungen Geeks.
Die Lösung dieses Problems wurde schon oft beschrieben. Es gibt beispielsweise Organisationsarchetypen, die von Fernando Fernandez beschrieben wurden. Die problematische Architektur, über die ich gerade mit der Isolation gesprochen habe, ist eine funktionsorientierte Architektur. Der zweite Typ ist der schlimmste, die Matrixarchitektur, ein Durcheinander der beiden anderen. Der dritte Typ ist bei den meisten Start-ups zu beobachten, und auch große Unternehmen versuchen, diesem Typus zu entsprechen. Es handelt sich um eine marktorientierte Organisation. Hier optimieren wir, um die schnellste Reaktion auf Kundenanfragen zu erreichen. Dies wird manchmal als flache Organisation bezeichnet.
Viele Leute beschreiben diese Struktur auf unterschiedliche Weise, mir gefällt die Formulierung Teams aufbauen/leiten, bei Amazon nennt man es zwei Pizzateams. In dieser Struktur sind alle Personen vom Typ „I“ um einen Dienst gruppiert, und nach und nach nähern sie sich dem Typ „T“ an, und wenn das richtige Management vorhanden ist, können sie sogar zu „E“ werden. Das erste Gegenargument hier ist, dass eine solche Struktur unnötige Elemente enthält. Warum brauchen Sie in jeder Abteilung einen Tester, wenn Sie eine spezielle Testerabteilung haben können? Darauf antworte ich: Die Mehrkosten sind in diesem Fall der Preis dafür, dass die gesamte Organisation in Zukunft zum Typ „E“ wird. In dieser Struktur lernt der Tester nach und nach etwas über Netzwerke, Architektur, Design usw. Dadurch ist sich jeder Teilnehmer der Organisation über alles im Klaren, was in der Organisation geschieht. Wenn Sie wissen möchten, wie dieses Schema in der Industrie funktioniert, lesen Sie .
7. Shift-Left-Auditoren: Auditieren früh im Zyklus. Die Einhaltung der Sicherheitsvorschriften wird angezeigt
Dies ist der Fall, wenn Ihre Handlungen sozusagen den Geruchstest nicht bestehen. Die Leute, die für Sie arbeiten, sind nicht dumm. Wenn sie, wie im obigen Beispiel, überall geringe/keine Auswirkungen setzen, dies drei Jahre dauerte und niemand etwas bemerkte, dann weiß jeder ganz genau, dass das System nicht funktioniert. Oder ein anderes Beispiel – ein Change Advisory Board, bei dem beispielsweise jeden Mittwoch Berichte eingereicht werden müssen. Dort arbeitet eine Gruppe von Leuten (übrigens nicht sehr gut bezahlt), die theoretisch wissen sollten, wie das System als Ganzes funktioniert. Und in den letzten fünf Jahren ist Ihnen wahrscheinlich aufgefallen, dass unsere Systeme unglaublich komplex sind. Und fünf oder sechs Leute müssen eine Entscheidung über eine Veränderung treffen, 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, denn das Team muss dafür verantwortlich sein. Andernfalls entsteht eine paradoxe Situation, wenn ein Manager, der noch nie in seinem Leben Code geschrieben hat, dem Programmierer sagt, wie lange das Schreiben von Code dauern soll. Ein Unternehmen, mit dem ich zusammengearbeitet habe, hatte sieben verschiedene Gremien, die jede Änderung überprüften, darunter ein Architektur-Board, ein Produkt-Board usw. Es gab sogar eine obligatorische Wartefrist, obwohl mir ein Mitarbeiter erzählte, dass in zehn Jahren Arbeit noch nie jemand eine von dieser Person während dieser obligatorischen Zeit vorgenommene Änderung abgelehnt habe.
Prüfer müssen eingeladen werden, sich uns anzuschließen, und nicht, sie loszuwerden. Sagen Sie ihnen, dass Sie unveränderliche Binärcontainer schreiben, die, wenn sie alle Tests bestehen, für immer unveränderlich bleiben. Sagen Sie ihnen, dass Sie eine Pipeline als Code haben, und erklären Sie, was das bedeutet. Zeigen Sie ihnen das folgende Schema: eine unveränderliche schreibgeschützte Binärdatei in einem Container, die alle Schwachstellentests besteht; Und dann berührt es nicht nur niemand, sondern auch nicht das System, das die Pipeline erstellt, da diese auch dynamisch erstellt wird. Ich habe Kunden, Capital One, die Vault verwenden, um so etwas wie eine Blockchain zu erstellen. Der Prüfer muss keine „Rezepte“ von Chef vorlegen; es reicht aus, die Blockchain zu zeigen, aus der klar hervorgeht, was mit dem Jira-Ticket in der Produktion passiert ist und wer dafür verantwortlich ist.
Согласно , erstellt im Jahr 2018 von Sonatype, gab es im Jahr 2017 87 Milliarden OSS-Downloadanfragen.
Die durch Schwachstellen verursachten Verluste sind unerschwinglich. Darüber hinaus beinhalten die Zahlen, die Sie jetzt oben sehen, keine Opportunitätskosten. Was ist DevSecOps in Kürze? Lassen Sie mich gleich sagen, dass ich nicht daran interessiert bin, darüber zu sprechen, wie erfolgreich dieser Name ist. Da DevOps so erfolgreich ist, sollten wir versuchen, dieser Pipeline mehr Sicherheit zu verleihen.
Ein Beispiel für diese Sequenz:
Dies ist keine Empfehlung für bestimmte Produkte, obwohl mir alle gefallen. Ich habe sie als Beispiel angeführt, um zu zeigen, dass DevOps, das ursprünglich auf dem Organisationsparadigma der Industrie basierte, es ermöglicht, jede Phase der Arbeit an einem Produkt zu automatisieren.
Und es gibt keinen Grund, warum wir bei der Sicherheit nicht den gleichen Ansatz verfolgen könnten.
Ergebnis
Abschließend gebe ich noch einige Tipps für DevSecOps. Sie müssen Auditoren in den Prozess der Erstellung Ihrer Systeme einbeziehen und Zeit für deren Schulung aufwenden. Sie müssen mit Wirtschaftsprüfern zusammenarbeiten. Als nächstes müssen Sie einen absolut rücksichtslosen Kampf gegen Fehlalarme führen. Selbst mit dem teuersten Schwachstellen-Scan-Tool können Sie bei Ihren Entwicklern extrem schlechte Angewohnheiten entwickeln, wenn Sie nicht wissen, wie hoch Ihr Signal-Rausch-Verhältnis ist. Entwickler werden mit Ereignissen überhäuft und löschen sie einfach. Wenn Sie von der Equifax-Geschichte gehört haben, ist das in etwa das, was dort passiert ist, wo die höchste Alarmstufe ignoriert wurde. Darüber hinaus müssen Schwachstellen so erläutert werden, dass deutlich wird, welche Auswirkungen sie auf das Unternehmen haben. Man könnte zum Beispiel sagen, dass es sich hierbei um dieselbe Schwachstelle wie in der Equifax-Geschichte handelt. Sicherheitslücken sollten genauso behandelt werden wie andere Softwareprobleme, das heißt, sie sollten in den gesamten DevOps-Prozess einbezogen werden. Sie müssen über Jira, Kanban usw. mit ihnen zusammenarbeiten. Entwickler sollten nicht glauben, dass jemand anderes dies tun wird – im Gegenteil, jeder sollte dies tun. Schließlich müssen Sie Energie in die Ausbildung von Menschen investieren.
Nützliche Links
Hier sind einige Vorträge von der DevOops-Konferenz, die für Sie nützlich sein könnten:
- Sergey Berdnikov, Artyom Kalichkin – Erfolgsgeschichte oder „Dev+DevOps+Ops“ (, )
- Baruch Sadogursky, Leonid Igolnik – DevOps im Maßstab: eine griechische Tragödie in drei Akten (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Einblick in DevOops 2020 Moskau - Es gibt auch viele interessante Dinge.
Source: habr.com