DevOps Glossary

A cross-functional team has all the necessary skills to design, build, test, deliver and operate a product.

A software product must be cherished and maintained over time.
Code is restructured while maintaining functionality to increase maintainability (readability, testability, clarity, ...).
This activity should always be performed when needed and not just as a one-time 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 nachgelagerte Verifikation umgesetzt werden.

Die Umsetzung des Vieraugenprinzips durch zwei Entwickler, die an einem Arbeitsplatz (eine Tastatur, ein Monitor) gemeinsam arbeiten.

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 (Services), 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.
 

Standardisiertes Vorgehen/Struktur (Schablone) für die Entwicklung neuer Funktionalitäten, um guten Code zu erzeugen.

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

Die Entwicklungsartefakte werden in nur einem gemeinsamen Arbeitsbereich von allen verwaltet, es gibt keine lokalen Versionen (Branches) mehr.

Non-Functional Requirements (NFRs) defi nieren Systemattribute wie z. B. Leistungsfähigkeit, Skalierbarkeit und Nutzbarkeit für Produkte. Diese werden (leider) oft bei den Anforderungen ver ges sen.

Die Continuous Integration-Pipeline ist eine Sammlung von Tools, mit deren Hilfe nach der Codeerstellung automatisiert ein neues Software-Release  erzeugt und getestet wird.

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.

Um eine gute Nachhaltigkeit des neu entwickelten Codes zu gewährleisten, werden sog. „Coding Standards“ (Entwicklungsrichtlinen) umgesetzt, die bei der Erstellung automatisiert überprüft werden.

Statische Codeanalysen für unterschiedliche Themenstellungen (Check for architecture guideline, Check for security, Check for compliance) werden automatisch angewendet.

Die finale Produktabnahme (durch das Business) erfolgt aufgrund vorher defi nierter und automatisierter Test-Szenarien.

Konzept zur Beschleunigung der Testdurchführung, bei dem unfertige, aufwändige oder schlecht verfügbare Systemteile simuliert werden.

Ansatz für jeden neu aufgetretenen Fehler einen Test zu erstellen und diesen zukünftig immer durchzuführen, um erneutes Auftreten zu verhindern.

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 schnelle Entwicklungen und Integrationen sowie Tests zu ermöglichen, müssen zusätzliche Umgebungen schnell bereitgestellt und auch wieder entfernt werden können.

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 für Umgebungen gemanagt werden.
Versionen, Kompatibilität zur genutzten Softwareversion, anonymisierte Produktionsdaten, Lasttestdaten Erzeugung, ... .

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 in verschiedenen Umgebungen.

Fehlerhafte Softwareinstallationen werden mit den gleichen Mechanismen wie beim Installieren einer regulären Softwareversion korrigiert. Hierzu wird entweder eine neue korrigierte oder auch eine vorherige Version genutzt.

Konzept zur Bereitstellung produktionsfertiger Features, ohne dass diese für alle Nutzer erreichbar/ nutzbar sind.

Variante von Dark Releases, bei der die neuen Features erst für einen kleinen und speziellen Teil der Nutzer vorab bereitgestellt werden.
Herkunft: Kanarienvogel in einem Kohlebergwerke zur Prüfung der Luftqualität.

Eine Technik, um Features für alle Nutzer während der Laufzeit per Konfi guration zu aktivieren/deaktivieren.

Nutzer einer/s bestimmten Region/Land/Kontinent werden zu einer neuen Funktionalität weitergeleitet, alle Anderen sehen und verwenden noch einen älteren Stand.

Nutzer einer bestimmten Gruppe oder solche mit speziellen Eigenschaften/Rechten werden zu einer neuen Funktionalität weitergeleitet, alle Anderen sehen noch einen älteren Stand.

Methode zum Vergleich des Erfolgs zweier Versionen der gleichen Grundfunktionalität, aber unterschiedlicher Ausgestaltung anhand gemessener Nutzungsdaten.

Vorhalten zweier identischer Produktiv-Infrastrukturen, einer Aktiven (blauen) und einer Zweiten (grünen), auf der ein Update oder eine 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 ...

Gemäß diesem Motto werden der Betrieb und die Wartung von den Entwicklern sichergestellt, die eine Anwendung oder ein System auch entwickelt haben.

Um ein gemeinsames Mindset von Entwicklern und Betriebspersonal zu ermöglichen, wird ein cross-funktionales DevOps-Teams etabliert, das sowohl die Entwicklung als auch Betriebsaufgaben für ein Produkt übernimmt.

Oftmals werden bei Systemen nur technische Parameter, wie Verfügbarkeit oder Geschwindigkeit, überwacht. Um die volle Funktion zu überwachen, müssen auch geschäftliche Parameter (z. B. Verkaufsabschlüsse) einbezogen werden.

Einteilung, durch welche Einheit eine Supportanfrage gelöst werden kann. Typischerweise werden hier 3 Level unterschieden.
Level 1: Klassifi zieren und ggf. Nacherfassen von Tickets. Mitteilen von bekannten Lösungen und ad-hoc Antworten.

Level 2: Fachliche Spezialisten mit erweiterten Rechten und Befugnissen.

Level 3: Technische Spezialisten (oftmals Entwickler) analysieren aufwändig die Tickets und antworten, was manchmal zu neuen Softwareversionen führt.

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

Alle administrativen Änderungen in der Produktion werden automatisiert protokolliert. Hierzu werden entweder Log-Dateien erstellt oder Änderungen sind an den Konfigurationsdateien über die Versionsverwaltung erkennbar.

Überwachen des Systems bzgl. kritischen Systemverhaltens und automatisiertes Anwenden 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, das große Gemeinsamkeiten mit den DevOps-Prinzipien hat.

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.