Fachposter, 2020: Erstellt von QAware in Zusammenarbeit mit Prof. Dr. Kratzke, Technische Hochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM). Bestellbar unter https://www.sigs-datacom.de/order/poster/DevOps_Prinzipien-Kubernetes.php (Dokument bitte herunterladen für bessere Lesbarkeit)

1. IT-Probleme lösen. Digitale Zukunft gestalten.
DevOps Prinzipien im Zusammenspiel mit Kubernetes Inhaltliche Entwicklung: Prof. Dr. Nane Kratzke, Technische Hochschule Lübeck, Mönkhofer Weg 239, 23562 Lübeck
Inhaltliche Mitwirkung: Dr. Josef Adersberger, QAware GmbH
Continuous Release
• Feature Rollout
• Release Patterns ausführen
(siehe Grafiken rechts)
Continuous Deployment
• Deployment in Production Stage
• Post-Deployment Checks
• Kompatibilitäts-Tests
...
Build + Test + Package + Deploy
Wertschöpfungsketten-bezogene KPI
DevOps Performance Metrics [2]
• Change Lead Time: Code commited to change released to end-users
• Deployment Frequency: Deployments to production
• Change Fail Rate: Percentages of deployments resulting in degraded service
• Time to Restore (MTTR)
Flow Metrics [3]
• Velocity: Items completed over a given period of time
• Efficiency: Item in active state vs. in waiting state from start to completion
• Time: Average time between start and completion of an item
• Load: Number of items currently in progress
• Distribution: Distribution of items of features, defects, risks (SecComp), debt
Ergebnis-bezogene KPI
• Qualitätsschulden-Analysen und automatisierte Tests [1]
• Net Promotor Score [4]
• Hypothesen-Tests [5]
• User Feedback
• Business KPI!
[1] https://martinfowler.com/articles/is-quality-worth-cost.html
[2] DORA: 2019 Accelerate State of DevOps Report
https://cloud.google.com/devops/state-of-devops
[3] https://go.tasktop.com/Flow-Metrics-Ebook-Ungated.html
[4] https://hbr.org/2003/12/the-one-number-you-need-to-grow
[5] David J. Bland, Alex Osterwalder, Testing Business Ideas
i Überblick gebräuchlicher Key Performance Indicators (KPI) i Kubernetes
Kubernetes ist ein Open-Source-System zur
Automatisierung der Bereitstellung, Skalie-
rung und Verwaltung von Container-Anwen-
dungen. Es zielt darauf ab, eine „Plattform
für das automatisierte Bespielen, Skalieren
und Warten von Anwendungscontainern auf
verteilten Hosts“ zu liefern. Es kann so Fla-
schenhälse im DevOps Cycle minimieren und
Infrastructure as Code für Test- und Produk-
tivumgebungen ermöglichen, sowie die au-
tomatisierte Erhebung von Telemetriedaten
mittels Service Meshs vereinfachen.
Code
Repository
API/CLI
horizontal skalierbar
Image
Registry
z. B.. Quay.io,
JFrog Artifactory
DockerHib, …
Service Meshs
z.B.. Linkerd,
Istio …
Deployed Services
Container Orchestrator
z.B.. Kubernetes, Docker Swarm, Normand, …
z. B.. Prometheus, Grafana,
ELK-Stack, etc,
Telemetriedaten erheben
Eine zentrale Telemetrie-Infrastruktur aufbauen
Geschäftslogik und Infrastruktur erzeugen verteilte
Events, Logs und Metriken, die in einem zentralen
Service konsolidiert werden.
Anwendungen systematisch loggen
Anwendungen müssen ausreichend Telemetrie-
daten erzeugen und an die Telemetrie-Infrastruktur
angebunden werden. Jedes entwickelte Feature
sollte auch geeignet instrumentalisiert werden.
Self-Service Zugriff auf Telemetriedaten
Damit jeder Probleme auch finden und beheben
kann, muss auch jeder Metriken erstellen, generie-
ren, anzeigen und analysieren lassen können.
Code
Code
Code
Code
Code
Architektur
Eine DevOps-konforme Architektur sollte risikoarme
Releases ermöglichen und sich evolutionär von Release
zu Release weiterentwickeln lassen.
Eine Architektur sollte aus lose gekoppelten autonomen
Komponenten bestehen, die von autarken Teams betreut
und betrieben werden können und kleine Batches von
Entwicklungen zulassen.
Automatisierte Tests
Eine Deployment-Pipeline stellt sicher,
dass jeglicher Code der in die Versions-
verwaltung eingecheckt wird, automatisch
gebaut und in einer produktivähnlichen
Umgebung mittels automatisierter Unit-,
Akzeptanz-, Integrationstests und Post-
Deployment-Checks getestet wird. So lassen
sich Build-, Test- oder Integrati- onsfehler
bereits beim Einführen einer Änderung
erkennen und beheben. Resul- tierender
Code ist immer in einem auslie- ferbaren
Zustand.
Releaserisiken reduzieren
Umgebungsbasierte Release-Strategien: Beim Blue/Green Deployment
hat man zwei Produktiv-Releases. Doch nur eines bedient Kunden. Funk-
tioniert ein Release nicht, kann notfalls auf das funktionierende Release
zurückgeschaltet werden. Canary-Releases funktionieren ähnlich,
nur werden Features erst wenigen, und dann sukzessive immer mehr
Nutzern bereitgestellt. Sollten Probleme auftreten, wird wieder zurück
gerollt. Bei Rolling-Updates werden Deployment Units inkrementell
aktualisiert.
Anwendungsbasierte Releases: Feature Schalter ermöglichen das
selektive ein-/ausschalten von Features abhängig von Last oder sons-
tigen Erwägungen. Features können notfalls auch wieder abgeschaltet
werden, wenn diese sich nicht bewähren.
DevOps Prinzipien des Feedback
i Continuous-Begriffe
Continuous Delivery
• Deployment in QA Stage
• Akzeptanztests
• Performance-Tests
...
Feature schafft
Mehrwert für
Nutzer
Continuous Integration
Shift Left QS (frühes Testen):
• statische Analyse
• Unit Tests
• Kompatibilitätstests
• License Checks
• Vulnerability Analysis
…
Code-Änderung
API/CLI
t
t
FLASCHENHÄLSEMINIMIEREN
Flaschenhälse folgen häufig diesen Mustern:
• Langwieriges (manuelles) Erstellung von Test- und Produktiv-
Umgebungen => Erstellung von Umgebungen im Self-Service auf
Anforderung.
• Langwieriges (manuelles) Code-Deployment => Automatisiertes
Deployment mittels Deployment Pipelines.
• Langwieriges (manuelles) Einrichten und Durchführen von Tests =>
Automatisiertes und parallelisiertes Testen, so dass die Testrate mit
der Code-Entwicklungsrate mithält.
• Zu stark gekoppelte Architekur (lokale Änderungen müssen mit
vielen abgestimmt werden) => Lose gekoppelte Architektur (z.B.
Microservices) um Änderungen sicherer und mit mehr Autonomie
durchführen zu können.
WORKINPROCESSBESCHRÄNKEN
Unterbrechungen sind bei der Herstellung physischer Güter sehr
kostenintensiv, denn häufig muss die aktuelle Arbeit abgebrochen,
ggf. entsorgt und Maschinen umgerüstet werden.
Das Unterbrechen von Technologiemitarbeitern ist ebenfalls teuer,
allerdings wesentlich einfacher (ein Anruf, eine Mail, eine Nachricht,
etc.). Studien haben gezeigt, dass sich die Zeit zum Erledigen selbst
einfacher Aufgaben (wie dem Sortieren geometrischer Formen)
beim Multitasking deutlich verlängert.
Multitasking sollte daher reduziert werden, indem man Obergrenzen
für Kanban-Spalten (Arbeitsstationen) festlegt und die Anzahl an
Spalten (Übergaben) möglichst klein hält, um zu vermeiden, dass
zwischen zu vielen Schritten und Kontexten hin und her gesprungen
wird.
DevOps Prinzipien des Flow
ARBEITSICHTBARMACHEN
Bei Technologiearbeit (anders als in der Produktion) kann Arbeit
häufig mit einem „Mausklick“ bewegt werden. Weil das so einfach
ist, werden manche Arbeitspakete zwischen Teams wie Pingpong
hin und her bewegt, ohne das nennenswerter Wert erzeugt wird oder
dies im Arbeitsalltag unmittelbar auffällt.
Um zu erkennen, wo Arbeit gut fließt und wo nicht, kann man auf
visuelle Arbeitsboards (z.B.. Kanban-Boards) zurückgreifen. Ein
Kanban-Board sollte immer die gesamte Wertkette umfassen, d.h.
bis ein Feature in einer Anwendung erfolgreich produktiv läuft.
Telemetriedaten erheben
Je länger Entwickler isoliert in Branches arbeiten, desto
(exponentiell) schwieriger wird es, alle Änderungen
wieder zusammenzuführen.
Continuous Integration hat daher zum Ziel, die Entwick-
lungsbranches einzelner Entwickler mittels Trunk-
basierter Entwicklungspraktiken und kleinen Batch-
größen idealerweise täglich zusammenzuführen.
Commits, die sich dabei nicht automatisiert deployen
lassen, sollten auch nicht in die Versionsverwaltung
eingecheckt werden können.
Continuous Integration
A/B-Tests
sind eine Testmethode zur Bewertung von Varianten eines Systems, bei der
die Originalversion gegen leicht veränderte Versionen getestet werden. Ziel
ist Nutzerreaktionen mit einer Kontrollgruppe zu vergleichen.
A/B-Tests in Feature-Testing integrieren
In modernen UX-Praktiken werden häufig Besuchern einer Website eine von
zwei Versionen einer Seite angezeigt. Mittels einer statischen Analyse des
Folgeverhaltens (Conversion Rates) kann objektiv geprüft werden, ob eine
Änderungen einen Effekt im Nutzerverhalten gebracht hat, oder nicht. Mit Hilfe
von Feature-Schaltern lässt sich genau steuern wie groß der Anteil von Kun-
den ist, die eine Testversion eines Experiments erhalten.
Hypothesengetrieben entwickeln
Mit Statistik potenzielle Probleme erkennen
Probleme können bei normalverteilten Ereignissen mit einfachen aber be-
währten statistischen Verfahren (wie Mittelwert und Standardabweichung)
identifiziert werden. Unterliegen Ereignisse keiner Normalverteilung kann
man auf glättende Verfahren (gleitende Durchschnitte), periodische/saisonale
Verfahren (Kolmogorow-Smirnow, etc.) zurückgreifen.
Nur bei signifikanten Ereignissen automatisiert warnen
Entfernen sich Metriken statistisch signifikant von ihren Normalwerten, so
sollten automatisierte Warnungen ausgelöst werden, da dies Vorboten eines
Produktivzwischenfalls sein können. Hierfür ist solides statistisches Wissen
über die Verteilung entsprechender Ereignisse erforderlich.
Telemetriedaten analysieren
Telemetriedaten erhebenTelemetriedaten erheben
A B
Telemetry
Service
Rolling Upgrade
1. 2. 3.
Canary Releases
traffic
traffic
Capacity
Production
traffic
t
Blue/Green
Deoloyment
traffic
Hot Standby
1. AVB Testing
2. Rolling Upgrade
3. Blue/Green
DevOps ist die Kultur, die Entwicklung (Dev) und
den Betrieb (Ops) von Anwendungen besser mitei-
nander zu integrieren, um kurze Release-Zyklen,
zuverlässige Inbetriebnahmen und eine hohe Ver-
fügbarkeit zu erreichen. Dies wird durch eine ver-
besserte Kooperation und einen höheren Automa-
tisierungsgrad erreicht.
i DevOps
Release Patterns
PROBLEMESOFORTLÖSEN
Werden Probleme im Produktivsystem erkannt, sollte die Problemlö-
sung höhere Priorität als die weitere Entwicklung von Features be-
kommen. Die Entwicklungspipeline sollte gestoppt werden. Probleme
sollten nie umgangen werden oder deren Lösung verschoben werden,
um zu vermeiden, dass sich ein Problem fortsetzt und zu exponentiell
steigendem Aufwand für dessen Behebung zu einem späteren Zeit-
punkt führt.
Damit dies funktioniert ist eine fehlerverzeihende Kultur erforderlich,
die die Lösung des Problems in den Mittelpunkt stellt und nicht den
Verursacher zur Rechenschaft zieht.
PROBLEMEFRÜHERKENNEN
Komplexe Systeme sind nicht vollständig von einer einzelnen Person
überschau- und verstehbar, da sie aus einer Vielzahl eng miteinan-
der verbundener Komponenten bestehen, deren Wechselwirkungen
nicht immer vorhersehbar sind. Daher sollten Annahmen, die beim
Design getroffen wurden, kontinuierlich geprüft werden. Z.B.. durch
Experimentieren mit einem Softwaresystem in der Produktion (Chaos
Engineering), um Vertrauen in die Fähigkeit des Systems aufzubauen,
turbulenten und unerwarteten Bedingungen standzuhalten. Ferner
benötigt man für Feedback-Schleifen im Produktivsystem kontinuier-
lich und automatisiert erhobene Telemetriedaten.
PROBLEMEPROFESSIONELL
VERANTWORTEN
Erstaunlicherweise erhöht in komplexen Systemen das Hinzufügen
zusätzlicher Kontrollschritte und Genehmigungsprozesse die Wahr-
scheinlichkeit für zukünftige Fehler, da Entscheidungen von Personen
getroffen werden müssen, die weit weg vom Problemraum sind.
Besser ist es, wenn Entwickler Verantwortung auch für den operati-
ven Betrieb haben (you build it, you run it). Dadurch liegt die Verant-
wortung für Qualität, Zuverlässigkeit sowie die Entscheidungsbefug-
nis dort, wo auch die Arbeit erledigt wird und die meiste technische
Expertise vorhanden ist. Durch dieses direkte Feedback aus Ops wird
das Lernen im Devs beschleunigt und zukünftige Probleme sind bes-
ser abschätzbar und konstruktiv vermeidbar.
!
?