DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG

Die Seite wird erstellt Merlin Becker
 
WEITER LESEN
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
DevOps Professional
Trainer: Michael Taube, Deutsche DevOps Akademie
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
EINFÜHRUNG

     NORMATIVE ETHIK

§   Was ist DevOps?
     §   Vorschriften zum richtigen Handeln
     §   Best Practice
     §   10 Jahre alt
     §   (scheinbar) nur für große Unternehmen geeignet
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
EINFÜHRUNG

     SOFTWAREENTWICKLUNGSPROZESS

Anforderungs-                                                Betrieb
                          SW-Entwicklung   SW-Auslieferung
management

                  Scrum                             DevOps
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
EINFÜHRUNG

     DIE DEPLOYMENT-PIPELINE

Scrum                               DevOps
Done

 In die           Auto-         In Trunk     Automatisiertes   Sammeln
 Versions-        matisiertes   liefern      + manuelles       von Daten
 verwaltung       Testing                    Testing
 eingecheckt

 Erweitertes
 Done
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
EINFÜHRUNG

PRINZIPIEN DER FABRIKHALLE IN DIE IT BRINGEN

§   Ausgangslage

    § Viele Machinen und
      Menschen
    § arbeiten Arbeitsschritte
    § an Arbeitsstationen ab
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
EINFÜHRUNG

PRINZIPIEN DER FABRIKHALLE IN DIE IT BRINGEN

§   Ziel

    §   effektiv und
    §   effizient arbeiten
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
EINFÜHRUNG

PRINZIPIEN DER FABRIKHALLE IN DIE IT BRINGEN

§   Status Quo
    §   viele Aufträge,
    §   wenig Auslieferung
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
EINFÜHRUNG

     DER ZENTRALE CHRONISCHE KONFLIKT

§   In IT-Organisation gibt es einen inhärenten Konflikt zwischen Entwicklung und IT
    Betrieb
     §   Entwicklung muss auf die sehr schnell verändernde Wettbewerbssituation
         reagieren
     §   IT Betrieb muss stabile, zuverlässige und sichere Services für den Kunden bieten
§   Technische Schulden
§   Abwärtsspirale bei der Time to Market
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
Die drei Wege

      HISTORIE

§   Die Lean-Bewegung
§   Das Agile Manifesto
§   Agile Infrastructure und
    Velocity-Bewegung
§   Die Continuous-Delivery-Bewegung
§   Toyota Kata

                                       ©https://de.m.wikipedia.org/wiki/Datei:August_Faller_KG_Historie.jpg
DEVOPS PROFESSIONAL TRAINER: MICHAEL TAUBE, DEUTSCHE DEVOPS AKADEMIE - VDI BERLIN-BRANDENBURG
Die drei Wege

      DER ERSTE WEG: DIE PRINZIPIEN DES FLOW

§   Arbeitsfluss von links nach rechts
§   Maximierung des Flow
§   Reduzierung der Batch-Größen
§   Arbeit sichtbar machen
§   Qualität einbauen
Die drei Wege

    WORK IN PROGRESS (WIP) BESCHRÄNKEN
§      Arbeit, die in den Entwicklungsprozess
       eingetreten ist,
       § aber noch nicht abgeschlossen ist und
       § noch nicht dem Kunden oder Nutzer
         zur Verfügung steht
§      Vermögenswerte/ Arbeitsprodukte eines
       Produkts/ Dienstleistung,
       § die gerade bearbeitet werden oder       5   2   4
       § in einer Warteschlange vor einer
         Arbeitsstation warten
§      deutsch: in Arbeit
Die drei Wege
    DIE BATCHGRÖßEN REDUZIEREN

§   Batchgrößen reduzieren
§   Große Batches = Massenproduktion
    § Gleiche Pressformen werden mehrfach
      gestanzt
    § Lagerplatz + -kosten
    § WIP steigt
§   Ziel: Single-Piece Flow
    § Beispiel Briefumschlag
Die drei Wege

        FLASCHENHÄLSE IDENTIFIZIEREN UND REDUZIEREN
§   Definition der 5 fokussierenden         Identifizieren
                                                              •Flaschenhals
                                                               im System
    Schritte                                                   identifizieren

    §   Den Flaschenhals im System
        identifizieren                                                           •Entscheiden,
                                                                                  wie er
                                                             Entscheiden          aufgebohrt
    §   Entscheiden, wie er aufgebohrt                                            werden kann
        werden kann
                                                                                                 •Alles andere
    §   Alles andere diesen                                                                       diesem
        Entscheidungen unterordnen                                              Unterordnen       Entscheidung
                                                                                                  en
                                                                                                  unterordnen
    §   Den Flaschenhals des Systems
        beheben                                                                                                   • Den
                                                                                                                    Flaschenhal
    §   Wenn durch diese Schritte ein                                                            Beheben            s des
                                                                                                                    Systems
        Flaschenhals aufgehoben wurde,                                                                              beheben
        gehe zurück zu Schritt 1, erlaube
                                                                                                                                  •Wenn
        aber nicht, dass der Flaschenhals                                                                           Neuen          Flaschenhals
        durch Trägheit zurückkehrt                                                                               Flschenhals       aufgehoben,
                                                                                                                                   zurück zu
                                                                                                                 bearbeiten        Schritt 1
Die drei Wege

     DER ZWEITE WEG: DIE PRINZIPIEN DES FEEDBACK

§   Fluss von Feedback von rechts
    nach links
§   Verstärkung des Feedback, um
    Probleme zu vermeiden
§   Qualität an der Quelle erzeugen
§   Wissen generieren oder
    einbetten, wo es gebraucht wird
§   Schaffung immer sichererer
    Arbeitssysteme
Die drei Wege

     MIT KOMPLEXEN SYSTEMEN SICHER ARBEITEN (II)

§   In komplexen technischen Systemen werden Fehler erst beim Eintritt einer Katastrophe
    erkannt
     § Massiver Produktionsausfall
     § Hackerangriff

§   Arbeitssysteme werden sicherer durch
     § Regelmäßigen qualitativ hochwertigen Informationsfluss
     § Feedback- und Feedforward-Schleifen
     § Lernen ohne Schuldzuweisung und Bestrafung
Die drei Wege

        PROBLEME UMSCHWÄRMEN UND GEMEINSAM
        LÖSEN

§   Lösung: (Toyota)-Andon-Cord
    §    Andon= japanisch für „zur
         Lampe gehen“                © Mark Graban
    §    Cord= englisch für Kabel
Die drei Wege
     DER DRITTE WEG: DIE PRINZIPIEN DES KONTINUIERLICHEN
     LERNENS UND EXPERIMENTIERENS

§   Institutionalisierung von
    Verbesserungen bei der täglichen
    Arbeit
§   Kontinuierliche Verkürzung und
    Verstärkung des Feedback-Loops
§   Effekte des neuen Wissens
    multiplizieren
§   Lokale Entdeckungen in globale
    Verbesserungen umwandeln
Die drei Wege
     LOKALE ENTDECKUNGEN IN GLOBALE
     VERBESSERUNGEN

§   kumuliertes und kollektives Wissen schaffen in der gesamten Organisation durch
    Dokumentation
     § Umwandlung von implizierten Wissen
     § Dokumentierte Prozeduren, standardisierter Arbeit und die Pflicht zu Meldungen bei
       jeder Abweichung von den Prozeduren oder normalen Vorgehensweisen
     § Post-Mortem-Berichte
     § Gemeinsam genutzte Quellcode-Repositories enthalten Code, Bibliotheken und
       Konfigurationen
Die drei Wege

        RESILIENZMUSTER IN UNSERE TÄGLICHE ARBEIT
        EINBRINGEN

§   Antifragility = Anwenden von Stress zur Erhöhung der Resilienz
    §    Deployment-Durchlaufzeiten reduzieren
    §    Testabdeckung zu erhöhen
    §    Test-Durchführungszeiten verringern
    §    Architektur anpassen, wenn dadurch die Produktivität der Entwickler oder die
         Zuverlässigkeit steigt
    §    Game-Day-Übungen
    §    Einschmuggeln noch größere Fehler in die Produktivumgebung
Die drei Wege

     FÜHRUNGSKRÄFTE UNTERSTÜTZEN EINE KULTUR
     DES LERNENS

§   Wissenschaftliches Experimentieren durch Mitarbeiter
    § Wir definieren explizit, welches Problem wir lösen wollen
    § Wie die Hypothese zum Lösen dazu aussieht
    § Wie unsere Methoden zum Testen dieser Hypothese lauten
    § Wie wir die Ergebnisse interpretieren
    § Wie wir mit den Erkenntnissen die nächste Iteration einleiten wollen

§   Ergebnis: wissenschaftliche Ansatz und die iterative Methode wird auf alle internen
    Verbesserungsprozesse angewandt
Der Dritte Weg: Die technischen Praktiken des fortlaufenden Lernens und Experimentierens

        FÜHREN EINE POST-MORTEM MEETINGS OHNE
        SCHULDZUWEISUNG

§   Die Ziele einer Post-Mortem-Überprüfung sind sehr einfach
    §    Dinge identifizieren, die Sie richtig gemacht wurden
    §    Dinge zu beachten, die anders gemacht werden sollten, damit Sie unsere Techniken
         in der Zukunft verfeinern können
    §    Dinge beachten, die Sie falsch gemacht wurden, um alternative Ansätze oder
         Sicherheitsmaßnahmen vorzuschlagen, die beim nächsten Mal mit einem ähnlichen
         Problem benutzt werden sollten
Der Dritte Weg: Die technischen Praktiken des fortlaufenden Lernens und Experimentierens
        DIE SIMIAN ARMY
§   Chaos Gorilla
    §    Simuliert den Ausfall einer gesamten AWS Availability Zone

§   Chaos Kong
    §    Simuliert Ausfall ganzer AWS-Regionen wie Nordamerika

§   Latency Monkey
    §    Verursacht künstliche Verzögerungen oder Ausfallzeiten in ihrer RESTful Client-
         Server-Kommunikationsschicht, um die Dienst Verschlechterung zu simulieren und
         sicherzustellen, dass abhängige Dienste entsprechend reagieren

§   Conformity Monkey

§   Ermittelt und beendet AWS-Instanzen, die sich nicht an Best Practices halten
Der Dritte Weg: Die technischen Praktiken des fortlaufenden Lernens und Experimentierens

        DIE SIMIAN ARMY
§   Doctor Monkey
    §    Tippt auf Integritätsprüfungen, die auf jeder Instanz ausgeführt werden, und findet
         fehlerhafte Instanzen und schließt Sie proaktiv ab, wenn Besitzer die Ursache nicht
         in der Zeit beheben

§   Janitor (Hausmeister) Monkey
    §    Sorgt dafür, dass Ihre Cloud-Umgebung läuft frei von Unordnung und
         Verschwendung; sucht nach nicht verwendeten Ressourcen und entsorgt diese

§   Security Monkey
    §    Eine Erweiterung der Konformität-Affen; sucht und beendet Instanzen mit
         Sicherheitsverletzungen oder Schwachstellen, z. b. nicht ordnungsgemäß
         konfigurierte AWS-Sicherheitsgruppen
ENDE

§ Deutsche Projekt Akademie
§ Michael Taube
§ Emdener Str. 25, 10551 Berlin

§ Michael.Taube@Deutsche-Projekt-Akademie.de
§ 0177 8282338
Sie können auch lesen