book

Das DevOps-Handbuch

by Jez Humble, John Willis, Gene Kim, Patrick Debois

August 2017

Intermediate to advanced

432 pages

12h 27m

German

dpunkt

Read now

Unlock full access

Die Wertkette in der HerstellungDie Technologie-WertketteDie Drei Wege: Die Prinzipien als Basis von DevOpsZusammenfassung
Wir machen unsere Arbeit sichtbarDie Work in Process (WIP) beschränkenDie Batchgrößen reduzierenDie Anzahl der Übergaben reduzierenUnsere Flaschenhälse kontinuierlich identifizieren und reduzierenSchwierigkeiten und Verschwendung in der Wertkette eliminierenZusammenfassung

Mit komplexen Systemen sicher arbeitenProbleme bei ihrem Auftreten erkennenProbleme umschwärmen und lösen, um neues Wissen zu schaffenDie Qualität näher zur Quelle bringenFür folgende Arbeitsstationen optimierenZusammenfassung
Firmenweites Lernen und eine Sicherheitskultur ermöglichenInstitutionalisieren Sie die Verbesserungen bei der täglichen ArbeitLokale Entdeckungen in globale Verbesserungen umwandelnResilienzmuster in unsere tägliche Arbeit einbringenFührungskräfte unterstützen eine Kultur des LernensZusammenfassungZusammenfassung Teil I
Greenfield- vs. Brownfield-ServicesSystems of Record und Systems of Engagement berücksichtigenBeginnen Sie mit den wohlgesonnensten und innovativsten GruppenDevOps in unserer Firma verbreitenZusammenfassung
Die Teams identifizieren, die unsere Wertkette unterstützenEine Value Stream Map erstellen, um die Arbeit sichtbar zu machenEin dediziertes Transformationsteam aufstellenTools einsetzen, um das gewünschte Verhalten zu unterstützenZusammenfassung
Organisatorische ArchetypenProbleme, die häufig durch eine zu starke Funktionsorientierung verursacht werden (»Auf Kosten optimiert«)Marktorientierte Teams anstreben (»Auf Geschwindigkeit optimieren«)Funktionsorientierung nutzenTests, Operations und Sicherheit als Aufgaben für jedermann an jedem TagJedes Teammitglied zu einem Generalisten machenNicht Projekte finanzieren, sondern Services und ProdukteTeamgrenzen anhand von Conways Gesetz festlegenLose gekoppelte Architektur nutzen, damit Entwickler produktiv und sicher arbeiten könnenZusammenfassung
Mit gemeinsam genutzten Services die Produktivität der Entwickler erhöhenOps-Techniker in unsere Serviceteams integrierenJedem Serviceteam eine Ops-Liaison verschaffenOps in die Dev-Rituale integrierenZusammenfassungZusammenfassung Teil II
Dev-, Test- und Produktivumgebungen auf Anforderung erstellen könnenEin Single Repository of Truth für das gesamte System schaffenInfrastruktur einfacher neu bauen, statt zu reparierenDie Definition des Entwicklungs-»Done« so anpassen, dass der Code in produktivähnlichen Umgebungen läuftZusammenfassung
Continuous Build, Test und Integration von Code und UmgebungenEine schnelle und zuverlässige automatisierte Validierungstest-Suite aufbauenUnsere Andon-Cord ziehen, wenn die Deployment-Pipeline unterbrochen wirdZusammenfassung
Entwicklung in kleinen Batchgrößen und was passiert, wenn wir zu selten Code in den Trunk committenTrunk-basierte Entwicklungspraktiken übernehmenZusammenfassung
Unseren Deployment-Prozess automatisierenDeployments von Releases entkoppelnÜbersicht über Continuous Delivery und Continuous Deployment in der PraxisZusammenfassung
Architektonische Prototypen: Monolith vs. MicroservicesMit dem Strangler-Application-Muster die Firmenarchitektur sicher weiterentwickelnZusammenfassungZusammenfassung Teil III
Unsere zentrale Telemetrie-Infrastruktur aufbauenAnwendungs-Logging-Telemetriedaten erzeugen, die in der Produktivumgebung helfenMit Telemetriedaten beim Lösen von Problemen helfenProduktivmetriken als Teil der täglichen Arbeit ermöglichenSelf-Service-Zugriff auf Telemetriedaten und Information Radiators schaffenTelemetrielücken finden und füllenZusammenfassung
Mit Mittelwert und Standardabweichung potenzielle Probleme erkennenUnerwünschte Ergebnisse instrumentieren und davor warnenProbleme, die entstehen, wenn die Telemetriedaten keine Gauß-Verteilung aufweisenTechniken zur Anomalie-Erkennung einsetzenZusammenfassung
Deployments mit Telemetriedaten sicherer machenDev nimmt am Bereitschaftsdienst von Ops teilEntwickler ermutigen, ihre Arbeit in der Wertkette zu beobachtenEntwickler ihren Produktivservice initial selbst betreuen lassenZusammenfassung
Eine kurze Geschichte des A/B-TestensA/B-Tests in unser Feature-Testing integrierenA/B-Tests in unser Release einbindenA/B-Tests in unsere Feature-Planung integrierenZusammenfassung
Die Gefahren von Change-Approval-ProzessenPotenzielle Gefahren von »zu sehr kontrollierten Änderungen«Koordination und Planung von Änderungen ermöglichenPeer Review für Änderungen einführenPotenzielle Gefahren durch mehr manuelle Tests und ÄnderungssperrenDurch Pair Programming all unsere Änderungen verbessernBürokratische Prozesse unerschrocken stoppenZusammenfassungZusammenfassung Teil IV
Eine Just Culture und eine Kultur des Lernens umsetzenPost-Mortem-Meetings ohne Schuldzuweisung nach dem Eintreten von UnfällenUnsere Post-Mortem-Analysen so weit wie möglich verbreitenDie Toleranz gegenüber Vorfällen weiter absenken, um immer schwächere Fehlersignale zu erkennenFehler neu definieren und das Eingehen kalkulierter Risiken unterstützenFehler in die Produktivumgebung einbringen, um Resilienz und Lernen zu ermöglichenGame Days einführen, um Zwischenfälle zu übenZusammenfassung
Mit Chatrooms und Chat Bots firmenweites Wissen automatisieren und einfangenStandardisierte Prozesse zur Wiederverwendung in Software automatisierenEin einzelnes, gemeinsam genutztes Quellcode-Repository für die gesamte Firma nutzenWissen durch automatisierte Tests als Dokumentation und Community of Practice verbreitenDurch kodifizierte nicht funktionale Anforderungen für Operations designenWiederverwendbare Operations User Stories in die Entwicklung integrierenSicherstellen, dass technologische Entscheidungen dabei helfen, die Firmenziele zu erreichenZusammenfassung
Rituale institutionalisieren, um technische Schulden zu bezahlenLehren und Lernen für jeden ermöglichenTeilen Sie Ihre auf DevOps-Konferenzen Ihre ErfahrungenInternes Consulting und Coaches zum Verbreiten von Praktiken aufbauenZusammenfassungZusammenfassung Teil V
Infosec in die Präsentationen der Entwicklungsiterationen einbindenInfosec in das Fehler-Tracking und in Post-Mortem-Analysen einbindenPräventive Sicherheitsmaßnahmen in die gemeinsam genutzten Quellcode-Repositories und Services integrierenInfosec in unsere Deployment-Pipeline einbindenFür die Sicherheit der Anwendung sorgenDie Sicherheit unserer Software-Lieferkette sicherstellenDie Sicherheit der Umgebung gewährleistenInfosec in die Produktiv-Telemetriedaten integrierenSicherheits-Telemetriedaten in unseren Anwendungen erstellenSicherheits-Telemetriedaten in unserer Umgebung erstellenUnsere Deployment-Pipeline schützenZusammenfassung
Sicherheit und Compliance in den Prozess zur Änderungsgenehmigung integrierenDen Großteil unserer Änderungen mit geringem Risiko als Standardänderungen neu kategorisierenWas zu tun ist, wenn Änderungen als normale Änderungen eingestuft werdenDas Vertrauen in die Segregation of Duty reduzierenFür Dokumentation und Belege für Auditoren und Compliance Officer sorgenZusammenfassungZusammenfassung Teil VI

Content preview from Das DevOps-Handbuch

KAPITEL 21

Zeit für das firmenweite Lernen und für Verbesserungen reservieren

Eine der Praktiken, die das Toyota Production System bilden, nennt sich Improvement Blitz (oder manchmal auch Kaizen Blitz genannt).¹ Sie ist definiert als dedizierter und konzentrierter Zeitraum, in dem ein bestimmtes Problem angegangen wird – häufig über mehrere Tage hinweg. Dr. Spear schreibt: »… Blitze werden häufig in dieser Form durchgeführt: Eine Gruppe findet sich zusammen, um sich konzentriert einem Prozess mit Problemen zuzuwenden … Der Blitz dauert ein paar Tage und hat das Ziel, den Prozess zu verbessern. Dabei werden bewusst Personen von außerhalb dieses Prozesses eingesetzt, um diejenigen zu beraten, die sich normalerweise innerhalb des Prozesses befinden.« ...