Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevOps Prinzipien im Zusammenspiel mit Kubernetes

146 views

Published on

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/Service-Mesh-Poster-2019.php

(Dokument bitte herunterladen für bessere Lesbarkeit)

Published in: Data & Analytics
  • Be the first to comment

  • Be the first to like this

DevOps Prinzipien im Zusammenspiel mit Kubernetes

  1. 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. ! ?

×