DevOps Glossary

Willkommen beim DevOps Glossary

Beschreibung und Bild

Hier erhalten Sie das vollständige DevOps Poster.

Agile Development


Ein cross-funktionales Team hat alle notwendigen Skills, um ein Produkt zu designen, zu bauen, zu testen, auszuliefern und zu betreiben.

Ein Software-Produkt muss über die Zeit gehegt und gepflegt werden.
Code wird unter Beibehaltung der Funktionalität neu strukturiert, um die Wartbarkeit zu erhöhen (Lesbarkeit, Testbarkeit, Übersichtlichkeit, ...).
Diese Tätigkeit sollte bei Bedarf immer durchgeführt werden und nicht nur als einmaliges Event.

Änderungen werden immer von 2 Personen (4 Augen) durchgeführt, um frühzeitig Fehler erkennen zu können und Wissen aufzubauen. Dies kann entweder durch gemeinsame Erstellung oder als nachgelagerter Verifikation Schritt umgesetzt werden.

Die Umsetzung des Vieraugenprinzips durch zwei Entwickler an einem Arbeitsplatz (eine Tastatur und Monitor).

Vorgehen, um technische Design-Entscheidungen in fachlichen Kontexten (sog. Domänen) zu treffen. Dazu kann eine formalisierte Sprache verwendet werden.

Neue Anforderungen werden erst mal in der möglichst einfachen Version umgesetzt, um schnell Feedback von Nutzer zu erhalten.

Ein Software-/Produktdesign entsteht im Zuge der Entwicklung durch das Team, nur Rahmenbedingung/Leitplanken sind vorgegeben.

Der technische Aufbau eines Produktes besteht aus vielen vernetzten kleinen Elementen, die miteinander und untereinander interagieren.

Bei TDD wird zuerst ein ausführbarer Test und im Anschluss die eigentliche Funktion implementiert und damit gleich der Test getestet.

Technik, um Anforderungen in Szenarien in der Form Given (Kontext), When (Aktion), Then (Folge) zu beschreiben (Gherkin Syntax).
Beispiel:
Gegeben ist ein Manager im Mitarbeitergespräch
Wenn er auf einen DevOps Begriff angesprochen wird,
Dann betrachtet er das KEGON DevOps Poster an der Wand und kann den Begriff sofort einordnen.
 

Verwende ein standardisiertes Vorgehen/Struktur (Schablone) für die Entwicklung neue Funktionalitäten.

Verwende erprobte Programmierrichtlinien (KISS, YAGNI, WET, DRY, Gute Lesbarkeit) für die Entwicklung.

Die Entwicklungsartefakte werden nur in einem gemeinsamen Arbeitsbereich von allen verwaltet.

Nonfunctional Requirements (NFRs) definieren Systemattribute wie z.B. Leistungsfähigkeit, Skalierbarkeit und Nutzbarkeit für Produkte.

Continious Integration

Die CI-Pipeline ist eine Sammlung von Tools, um nach der Codeerstellung automatisiert ein neues Software-Release zu erzeugen und zu testen.

Um eine schnelle Auslieferung eines neuen Softwareprodukts in guter Qualität sicherzustellen, werden funktionale und nicht-funktionale Anforderungen automatisiert getestet und das Ergebnis zugreifbar bereitgestellt.

Continious Deployment

Die CD-Pipeline sorgt dafür, dass ein beliebiger Softwarestand eines Produkts automatisch auf eine beliebige Umgebung installiert und konfiguriert wird und damit lauffähig bereitgestellt ist.

Um eine schnelle Auslieferung eines neuen Softwareprodukts in guter Qualität sicherzustellen, werden funktionale und nicht-funktionale Anforderungen automatisiert getestet und das Ergebnis automatisch bereitgestellt.

Nutzung von fertig bereitgestellten komplexen Software-Produkten mit laufendem Support. Nützlich für schnelle Verwendung in Test und Integrationsumgebungen.

Erstellung neuer Umgebungen inklusive aller notwenigen Komponenten/Systeme anhand von automatisierten Skripten (Code).

Entwickler können neue Umgebungen eigenständig über eine einfache Oberfläche erstellen bzw. löschen, eine Softwareversion deployen oder einen Datenbestand laden lassen.

Analog dem Managen der Softwareversion/-funktionalitäten müssen auch die Testdaten gemanagt werden. Versionen, Kompatibilität zur genutzten Softwareversion, anonymisierte Produktionsdaten, Lasttestdaten Erzeugung, ... .

Release on Click / Release by Business

Release on click by Business ist das Aktivieren einer in Produktion zunächst deaktivierten Funktionalität. Im besten Fall sollte dies durch einem Vertreter des Business ohne Beteiligung der IT erfolgen.

Das Management Dashboard überwacht technische sowie geschäftliche Parameter aller aktiven Anwendungen.

Fehlerhafte Softwareinstallationen werden mit den gleichen Routinen wie einer reguläre Softwareversion korrigiert. Hierzu wird entweder eine korrigierte oder wenn möglich auch eine vorherige Version genutzt.

Das Konzept zur Bereitstellung produktionsfertiger Features ohne, dass diese für die Allgemeinheit erreichbar/nutzbar sind.

Variante von Dark Releases, bei welchem die neuen Features erst für einem Teil der Nutzer bereitgestellt wird.
Herkunft: Kanarienvogel in einem Kohlebergwerke zur Prüfung der Luftqualität.

Eine Technik um Feature während der Laufzeit per Konfiguration zu aktivieren/deaktivieren.

Nutzer einer bestimmten Region/Land/Kontinent werden auf die neue Funktionalität weitergeleitet, alle andere sehen noch einen älteren Stand.

Nutzer einer bestimmten Nutzergruppe bzw. mit speziellen Eigenschaften/Rechten werden auf die neue Funktionalität weitergeleitet, alle andere sehen noch einen älteren Stand.

Methode zum Vergleich des  Erfolgs zweier Version der gleichen Grundfunktionalität anhand gemessener Nutzungsdaten.

Vorhalten zweier identischer Produktiv-Infrastrukturen, eine aktive und eine zweite, auf der ein Update oder neue Version vorbereitet wird und die dann per Umschalter zu einem Termin gewechselt werden, womit grün zu blau und blau zum neuen grün wird...

Operation / Betrieb

Um ein gemeinsames Mindset zwischen Entwicklern und Betriebspersonal zu ermöglichen wird ein cross-functionales DevOps-Teams etabliert, welches sowohl die Entwicklung als auch Aufgaben des Betriebs eines Produkts übernimmt.

Gemäß dieses Mottos wird der Betrieb von den Entwicklern sichergestellt, welche eine Anwendung oder ein System auch entwickelt haben.

Oftmals werden bei Systemen nur technische Parameter, wie Verfügbarkeit oder Geschwindigkeit überwacht, um die volle Funktion zu überwachen, müssen hier auch geschäftliche Parameter integriert werden.

Alle administrativen Änderungen werden auf der Produktion automatisiert protokoliert. Hierzu werden entweder Log-Dateien erstellt bzw. Änderungen sind an Konfigurationsdateien über die Versionsverwaltung erkennbar.

ITIL-Prozess zur Verfolgung von Störungen und Fragen für die Nutzer sowie deren Lösung und der Kommunikation der Lösung. 

Einteilung durch welche Einheit eine Supportanfrage gelöst werden kann. Typischerweise werden hier 3 Level unterschieden.

  1. Klassifizieren und ggf. Nacherfassen von Tickets. Mitteilen von bekannten Lösungen und ad-hoc Antworten.
  2. Fachliche Spezialisten mit erweiterten Rechten und Befugnisse. 
  3. Techn. Spezialisten (oftmals Entwickler) analysieren aufwändig die Tickets und antworten, was manchmal zu neuen Softwareversionen führt. 

Überwachen des System bzgl. kritischer Systemverhalten und automatisierte Anwendung von Schritten um dies zu beheben. Z.B Isolieren von Nodes mit ungewöhnlicher CPU Nutzung, Terminieren von langlaufenden Datenbank-Anfragen, ... .

Ein von Google erstelltes Zusammenarbeitsmodell für Entwicklung und Betrieb mit großen Gemeinsamkeiten zu den DevOps Prinzipien.

Vereinbarung / Vertrag bzgl. der Leistungsqualität einer technischen Lösung  (Qualität, Verfügbarkeit , Verantwortlichkeiten) verbunden ggf. mit Strafzahlungen.

Nicht genehmigte oder externe Systeme, die produktiv verwendet werden, aber nicht den internen Regularien bzw. Prozessen entsprechen und perspektivisch abgebaut werden sollten.