DevOps Flashcards
(26 cards)
Was ist DevOps?
○ Zusammenschluss aus Development und Operations
○ Ermöglicht Koordination und Zusammenarbeit zwischen zuvor getrennten Rollen wie Entwicklung, IT-Betrieb, QS und Sicherheit
○ Ermöglicht schnellere und bessere Reaktion auf Anforderungen
Was sind mögliche Probleme durch fehlendes DevOps?
○ Umsetzung von Änderungen bis zum Deployment in Produktivumgebung dauert sehr lang (Wochen, Monate)
○ Deployments in Produktivumgebung sind nicht Routine -> Fehleranfällig, Feuerlöschen chronisch und kann nur von wenigen Mitarbeitern durchgeführt werden
○ Konflikte zwischen Development und Operations durch konkurrierende Ziele
○ z. B. Schnelle Reaktion auf Veränderungen der Wettbewerbssituation vs. Stabile, zuverlässige, sichere Services für den Kunden
Was passiert in den drei Phasen der Abwärtsspirale durch fehlende DevOps?
- Phase:
○ Aufgabe des IT-Betriebs: Anwendungen & Infrastruktur betreiben
○ Vielfach Probleme in der täglichen Arbeit durch fragile, schlecht dokumentierte und instabile Anwendungen & Infrastruktur
○ Anhäufung technischer Schulden, die nie behoben werden
○ Unternehmenskritische Bestandteile haben oft höchsten Änderungsbedarf und sind am fragilsten - Phase:
○ Versprechen von Unternehmen & Führungskräften nur durch überhastete Umsetzung von Projekten mit umfangreichen Änderungen an SW- & HW-Infrastruktur zu schaffen
○ Keine Zeit für ausreichende Prüfungen und Tests
○ Weitere Anhäufung technischer Schulden - Phase:
○ Großteil der Arbeit wird in Krisenbewältigung investiert
○ Viele Arbeitsschritte werden unterbrochen -> Arbeit dauert länger
○ Kommunikation wird verlangsamt
○ Schlüsselpersonen werden Bottleneck
○ Kleine Änderungen führen bereits zu Problemen durch fehlende Überprüfungszeit und fragiles System
○ Mitarbeiter werden unsicher, Vereinbarung weiterer Prüfschritte, Erhöhung der Arbeitslast
○ Bewältigung verschiedener Aufgaben immer mehr verknüpft
○ Qualität wird immer schlechter
Welche Stufen der Collaboration gibt es?
○ Agile (Plan, Code, Build)
○ Continuous Integration (Agile + Test) -> Steigerung Software-Qualität, automatisierte Tests, Metriken
○ Continuous Delivery (Continuous Integration + Release) -> Automatisierte Produktionsübergabe
○ DevOps (Continuous Delivery + Deploy & Operate)
Auf welchen Prinzipien basiert DevOps?
○ Lean-Bewegung: Wertstromanalyse, Kanban, kurze Durchlaufzeiten mit kleinen Arbeitseinheiten
○ Agile Manifest & Infrastruktur: Regelmäßige Auslieferung funktionierender Software, je öfter desto besser, kleine selbst motivierte Teams, Vertrauen
○ Continuous Delivery: Deployment Pipeline
○ Toyota Kata: Entwicklung von Lernroutinen
Was ist die Wertkette in der Technologie und wie funktioniert diese?
○ Prozess der Umwandlung von Geschäftshypothese zu technologiegestütztem Service mit Mehrwert
○ Idee -> User Stories -> Dev -> QA -> Produktion
○ Eingangsdaten: Geschäftsziel, Konzept, Hypothese
○ Nach Annahme durch Entwicklung: Idee zum Backlog hinzugefügt
○ Umwandlung der Idee in User Stories/Feature Spezialisierung, anschließend in Code
○ Einchecken in Repo, mit Softwaresystem testen
○ Wert entsteht durch produktive Nutzung des Services (schnelles, störungsfreies Deployment ohne Ausfälle, Sicherheits- oder Compliance-Probleme)
Welche Aspekte sind bei einer Fokussierung auf das Deployment zu beachten?
○ Wertkette beginnt mit einchecken Änderungswunsch und endet mit produktivgehen der Änderung beim Kunden
○ Design und Entwicklung: 1. Phase, kreativ, unterschiedliche Prozesse
○ Test und Operations: 2. Phase, möglichst mechanisch, minimale Variabilität, kurze und zuverlässige Durchlaufzeiten
○ Phasen laufen parallel für schnellen Flow und hohe Qualität
○ Kleine Batches, Qualität sicherstellen in jedem Teil der Wertkette
Welche Bedeutung haben Durchlauf- und Verarbeitungszeit?
○ Kennzahlen der Lean-Community
○ Durchlaufzeit für Kunden relevant
○ Verhältnis Durchlauf zu Verarbeitung Kennzahl für Effizienz
○ Minimierung Wartezeiten vor nächster Bearbeitung für kurze Durchlaufzeiten
○ Klassische IT-Deployment-Durchlaufzeit kann Monate umfassen durch komplexe Integrations-Testumgebungen, hohen manuellen Testaufwand und Bestätigungsprozesse
○ Lange Deploymentketten erfordern an vielen Stellen Spezialisten für zeitintensive Problemlösungen
Welche Vorteile haben kurze Durchlaufzeiten (Minuten) und wie kann dies erreicht werden?
○ Vorteil: Direktes Feedback an Entwickler durch DevOps-Prozesse
○ Erfordert Modulare Architektur, saubere Kapselung, lose Kopplung
○ Erfordert Automatische Unit-Tests beim Commit, automatische Integrations-, Acceptance- und Systemtests -> schnelle Rückmeldung, schnelle Problemlösung (auch durch kleinere Pakete)
Was sind die drei Wege als Prinzipien zur Erklärung von DevOps?
- Weg: Die Beschleunigung des Workflows vom Development zu Operations beim Kunden (Dev -> Ops)
- Weg: Erkennung & Behebung von Problemen, aus Fehlern lernen, Wissen verfügbar machen (Dev <-> Ops)
- Weg: Langfristige Einrichtung von DevOps durch generative, vertrauensvolle Kultur des Lernens
Welche Grundprinzipien sind Teil des ersten Wegs?
○ Workflow beschleunigen
○ Arbeit sichtbar machen (z. B. Kanban-Board), sonst können Behinderungen des Flows nicht direkt erkannt werden
○ WIP beschränken & Batchgröße reduzieren
○ Qualität sicherstellen, keine Weiterleitung fehlerhafter Software an Folgeschritte
○ Kontinuierliche Optimierung, globale Ziele sicherstellen
○ Verringert automatisch Durchlaufzeit, erforderliche Features schneller beim Kunden mit höherer Qualität
○ Praktiken: Continuous Build, Integration, Test & Deployment, Erstellung von Umgebungen nach Anforderungen, WIP reduzieren, änderbare Systeme aufbauen
Wie kann die WIP beschränkt und warum sollte die Batchgröße reduziert werden?
○ WIP beschränken:
○ Herstellung: Tägliche Arbeit durch Produktionszeitplan vorgegeben (Kundenbestellungen, Liefertermine, verfügbare Teile)
○ Technologie: Dynamische Erfüllung der Anforderungen der Stakeholder (Mails, Anrufe, Chats, Ausfallbenachrichtigungen, Management-Eskalationen)
○ Reduzierung möglicher Arbeitsabläufe pro Station, Reduzierung Queue-Größe
○ Bei Leerlauf: Kollegen mit Überlast helfen
○ Batchgröße reduzieren:
○ Klassisch (vor Lean): große Batchgrößen um hohe Rüstkosten auf viele Fertigungsteile zu verteilen
○ Aber: Erhöht jedoch WIP und führt zu stark variierendem Flow -> Längere Durchlaufzeiten, schlechtere Qualität
○ Vorteil kleiner Batchgrößen: Fehler im Flow fallen sofort auf, Anzahl fehlerhafter Produkte wird minimiert, weniger WIP, schnellerer Durchlauf, bessere Qualität, weniger Ausschuss
○ Entwickler: Batchgröße ist Menge Features die zusammengefasst bearbeitet werden
Warum sollte die Anzahl der Übergaben reduziert werden und wie kann dies erreicht werden?
○ Hunderte Schritte in Technologiekette zwischen Versionsverwaltung in Produktivumgebung
○ Mehrere Teams oder Abteilungen beteiligt
○ Jede Übergabe zwischen Teams benötigt Kommunikation sowie Managementsysteme, technische Spezifikationen, Meetings, Datenaustausch…
○ Jeder Schritt eine Queue, permanente Eskalation
○ Gefahr des Kontextverlusts bei jeder Übergabe
○ Anzahl Übergänge minimieren durch Automatisierung einzelner Schritte oder Reorganisation
○ Queuezeit verringern, direkter Bezug des Teams zu Kundenanliegen, Unabhängigkeit von anderen
○ Flow erhöht, wertlose Arbeit verringert
Welche Bedeutung haben Engpässe in der Wertkette, welche Engpässe können bei Deployments auftreten und wie könne diese gelöst werden?
○ In jeder Wertkette nur eine Fließrichtung und nur ein Flaschenhals
○ Jede Verbesserung die nicht am Flaschenhals stattfindet ist wertlos
○ Engpässe bei Deployments und Lösungen:
○ Umgebungserstellung -> Self Services
○ Code-Deployments -> Self Services
○ Testeinrichtung und -durchführung -> Automatisierung und Parallelisierung
○ Strikte, gekoppelte Architektur -> entkoppeln
Was sind mögliche Ursachen für Schwierigkeiten und Verschwendung in der Wertkette?
○ Verschwendung: Verzögerungen ohne Beitrag zum Ergebnis
○ Unvollständige Arbeit (verliert an Wert, kostet Zeit)
○ Zusätzliche Prozesse (Ungenutzte Dokumentation, Reviews, Genehmigungen)
○ Zusätzliche Features (Nicht benötigte Softwareteile, erhöht Komplexität)
○ Aufgabenwechsel durch Mitarbeiter in mehreren Projekten (Koordinationsaufwand, Mehraufwand)
○ Warten (Verzögerung durch nicht verfügbare Ressourcen)
○ Bewegung/viel Kommunikation zwischen entfernten Mitarbeitern (Übergang zwischen Arbeitsstationen von Infos, Materialien)
○ Fehler (falsche/fehlende Informationen, Materialien, Produkte, Aufwand durch Problembehebung, größer je länger her)
○ Manuelle/nicht standardisierte Arbeit
○ Heldentaten (Unvernünftige aber zur Zielerreichung nötige Schritte, Patches in Produktivumgebung, Fehler durch Releases)
○ Ziel: Kontinuierliches Lernen um Schwierigkeiten und mühsame Arbeit zu verringern
Welche Komponenten müssen für Continuous Delivery wiederholbar und planbar wiederhergestellt werden können?
○ Alle Komponenten des Softwaresystems (alle Produktivservices):
○ Anwendungscode + Abhängigkeiten + statische Inhalte
○ Skripte zur Erstellung DB-Schemata + Stammdaten
○ Tools und Artefakte zur Umgebungserstellung
○ Konfigurationsdateien zur Containererstellung (Docker-Definitions)
○ Skripte für automatische + manuelle Tests
○ Skripte für Code-Packaging, Deployment, DB-Migration, Umgebungsausstattung
○ Projektartefakte (Anforderungsdokumentation, Deployment-Prozeduren, Releasehinweise)
○ Cloud-Konfigurationsdateien
○ Weitere Skripte/Konfigurationsdateien für Umgebungsaufbau und zur Verfügungstellung von Services
Warum sollte die Infrastruktur neu gebaut werden anstatt diese zu reparieren?
○ Durchgeführte Änderungen gehen bei Wiederaufsetzen verloren
○ Reproduzierbares System ermöglicht Erhöhung von Kapazitäten
○ Verhinderung katastrophaler Fehler durch Abstürze durch undokumentierte und manuelle Änderungen
○ Alle Änderungen müssen an allen Servern durchgeführt werden (Test, QA, Produktiv)
○ Alle Änderungen über Versionsverwaltung, so dass nach Wiederaufbau enthalten (Immutable Infrastructure)
○ Verhinderung unkontrollierter Konfigurationsabweichungen durch Deaktivierung Remote-Logins oder routinemäßiges Ersetzen von Produktinstanzen
Was ist Teil einer Definition of Done bei DevOps?
○ Nach Sicherstellung der automatischen Umgebungserstellung nach Anforderung: Sicherstellung erwartungsgemäßes Anwendungsverhalten in produktivähnlicher Umgebung
○ Demonstration am Ende jedes Entwicklungsintervalls für potenziell auslieferbaren Code
○ Entwicklerarbeit nur als Done akzeptiert, wenn erfolgreich gebaut und deployt vor Sprintende
○ Verhinderung von Abnahmen fertigen Codes auf Basis einer Testumgebung
○ Arbeit in produktivähnlicher Umgebung: Integration Tagesgeschäft, nicht erst bei Release-Ende, alle Tools bekannt
Was sind die wichtigsten Punkte des ersten Wegs (Zusammenfassung)?
○ Arbeit sichtbar machen, Batchgrößen reduzieren
○ Weiterleitung fehlerhafter Software verhindern
○ Anzahl Übergaben reduzieren
○ Engpässe kontinuierlich reduzieren
○ Verschwendung eliminieren
○ Durchgängige Nutzung Versionsverwaltung
○ Automatischer Systemaufbau
○ Deployment-Pipeline
○ Definition of Done
○ Lose Kopplung, Reduktion von Seiteneffekten
Wie funktioniert die Feedback-Schleife des zweiten Wegs?
○ Kontinuierlicher und schneller Feedback-Fluss in allen Schritten der Wertkette von rechts nach links
○ Sicherstellung, dass kein Problem erneut auftritt -> Erhöhung Qualität
○ Wissen und Qualitätsbewusstsein and erforderlichen Stellen
○ Arbeitsplätze und -systeme zur Erkennung und Behebung von Problemen vor Fehlerfällen
○ Ununterbrochene Bearbeitung von Fehlern bis Gegenmaßnahmen aktiv sind -> Beschleunigung Feedback-Schleifen, Geist der Qualitätsverbesserung, Organisation lernfähiger
○ Ausfälle & Unfälle: Gelegenheit zum Lernen, keine Schuldzuweisungen
Was sind Herausforderungen in der sicheren Arbeit mit komplexen Systemen?
○ Systeme nicht vollständig von einer einzelnen Person überschaubar
○ Wissen über Funktionsweisen des Systems sehr verteilt
○ Komplexe Wechselwirkungen zwischen Teilsystemen, unzuverlässige Vorhersagen, Checklisten & Best Practices unzureichend
○ Erneute Ausführung führt nicht unbedingt zum gleichen Ergebnis, Fehler unvermeidbar -> Fehlererkennung essenziell um Katastrophen zu verhindern
○ Vollkommen sichere Systeme nicht möglich, aber Sicherheit kann maximiert werden durch Einhaltung von Bedingungen
Was sind die Kernaspekte des zweiten Wegs (Zusammenfassung)?
○ Probleme sofort erkennen
○ Probleme direkt lösen
○ Probleme dürfen maximal einmal auftreten
○ Lokales Wissen allen verfügbar machen
○ Fehler sind Gelegenheit zu lernen, Fehlerprozeduren müssen vorbereitet und getestet sein
○ Prüfungen und Entscheidungen am Produkt in Wertkette etablieren
○ Dokumentation nutzen
○ Telemetriedaten für OPS (Logs, Events, Metriken)
○ Transparente Wertkette
○ DEV Bereitschaft bei OPS, DEV führt ersten Betrieb bei OPS durch
○ Experimente mit A/B-Tests -> unnötige Features aus Code entfernen
Auf welchen Prinzipien basiert der dritte Weg?
○ Langfristige Umsetzung von DevOps erfordert generative, vertrauensvolle Kultur:
○ Ermöglichung eines dynamischen, disziplinierten und wissenschaftlichen Ansatzes
○ Zum Experimentieren, Eingehen von Risiken, Firmenweiten Lernen
○ Fehlschläge keine Niederlage, Erfolge und Misserfolge gehören zusammen
○ Positive Wirkung der kontinuierlichen Beschleunigung der Feedbackschleifen -> sicherere Arbeitssysteme
○ Dadurch wird es leichter zu experimentieren und Risiken einzugehen um schneller als Konkurrenz zu lernen und am Markt zu operieren
○ Arbeitssysteme basieren auf gewonnener Erfahrung, unterstützen Vervielfältigung des Wissens, lokale Entdeckung in globale Verbesserung umwandeln
○ Gesammelte kollektive Erfahrung der Firma wird an jedem Arbeitsplatz genutzt
Wie können Fehler als Chance genutzt werden?
○ Vorbereitet sein auf Ausfälle
○ Ggf. Leistung für Nutzer/Kunden einschränken um Gesamtservice nicht zu beeinträchtigen
○ Simulation von Störungen um Ernstfall zu proben und Verhalten des Systems kennenzulernen
○ Erkenntnisse nutzen um das System robuster zu machen und automatische Wiederherstellbarkeit nach Störung zu erreichen
