DevOps - Was ist das?

Eine kurze Einführung

Der Name DevOps setzt sich aus den ersten Silben der englischen Bezeichnungen “Development” und “Operations”, d.h. Entwicklung und Betrieb zusammen.

DevOps umfasst eine Reihe von Best Practices, die die Kollaboration und Kommunikation von IT-Experten (Entwicklern, Anwendern und Support-Mitarbeitern) im Lebenszyklus von IT-Anwendungen und IT-Services stärken und dadurch folgende Ergebnisse erzielen:

  • Continuous Integration (kontinuierliche Integration): alle entwickelten Arbeitskopien werden mehrmals täglich in einer gemeinsamen Mainline-Version zusammengeführt
  • Continuous Deployment (kontinuierliche Bereitstellung): neue Releases erfolgen kontinuierlich oder so oft wie möglich
  • Continuous Feedback (kontinuierliches Feedback): Einholen des Feedbacks der Beteiligten in allen Phasen des Lebenszyklus

Das Grundprinzip von DevOps lautet “Die Drei Wege”:

  • Der Erste Weg ermöglicht einen schnelleren Flow der Arbeit von links nach rechts, von der Entwicklung über den Betrieb zum Kunden.
  • Der Zweite Weg ermöglicht schnelles und kontinuierliches Feedback von rechts nach links, von allen Beteiligten zurück in den Wertstrom.
  • Der Dritte Weg schafft eine generative, vertrauensvolle Kultur, die Experimentieren und das Eingehen von Risiken unterstützt und so Lernen ermöglicht.

    Zudem deckt DevOps die entscheidenden Themen der Sicherheit in allen Phasen ab und sorgt für die Einhaltung der Anforderungen bei Änderungen.

A/B-Testen
Der A/B-Test ist eine Testmethode zur Bewertung zweier Varianten eines Systems, bei der die Originalversion gegen eine leicht veränderte Version getestet wird.
Akzeptanztests = User Acceptance Tests (UAT)
Ein Akzeptanztest (oder Abnahmetest) ist die Überprüfung, ob eine Software aus Sicht des Benutzers wie beabsichtigt funktioniert und dieser die Software akzeptiert.
agile Infrastruktur
Anwenden von Agile-Prinzipien auf Infrastruktur (statt auf Anwendungscode), z. Bsp. Vereinfachung der Infrastruktur, Virtualisierung, Cloud, Microsservices..
Andon-Cord
In seinem Ursprung handelte es sich bei Andon um ein einfaches visuelles Signal, eine kleine Leuchte an einer Maschine, die auf Probleme oder Stopps aufmerksam machen soll.  Hier: Hebel oder Druckknopf, der benutzt wird, wenn in der Produktion ein Fehler auftritt.
Antifragility
Antifragilität ist eine Eigenschaft von Systemen, die aufgrund von Stressoren, Schocks, Flüchtigkeit, Rauschen, Fehlern, Fehlern, Angriffen oder Ausfällen ihre Fähigkeit, Belastbarkeit oder Robustheit zu erhöhen.
automatisierte Tests
Die Durchführung von Softwaretest wird automatisiert, um Wartezeiten zu vermeiden.
Änderungskategorien
Standard Änderung – geringes Risiko/ Normale Veränderung – durchschnittliches Risiko/ Große Veränderung – hohes Risiko
Abwärtsspirale
Aus dem Konflikt von IT-Betrieb und SW-Entwicklung ergibt sich die Abwärtsspirale bei der Time to Market für neue Produkte und Features und der Qualität. 3 Stufen: 1. SoR sind gefährdet, technische Schulden steigern, 2. Aufsetzen von neuen, dringenden Projekten auf Grund Marktversprechen, 3. Zeitprobleme, unfertige Arbeit. s. Tabelle C-1
Aus (Um-)schwärmen
Kollegen schwärmen aus, um bei Ziehen der Andon-Cord zu helfen.
Agile Manifesto
Dokument über die Werte und Prinzipien agiler Softwarentwicklung aus dem Jahre 2001.
Ansprechpartner im Betrieb (Ops-Liaison)
Wenn ein Ops-Techniker nicht für ein Service-Team zur Verfügung steht, geht man eine Ops-Liaison ein. Er ist dann Ansprechpartner für das Team, aber nicht Teil des Teams.
Die Anzahl der Übergaben reduzieren
Bei Übergaben von Arbeit entsteht unproduktive Zeit, weil bei der Kommunikation Fehler passieren oder das Produkt einfach liegen bleibt. Eine Verminderung der Übergaben löst diese Probleme.
Arbeitsstation
Ein Arbeitsstation besteht aus Maschinen, Menschen, Methoden und Maßnahmen.
Anomalie-Erkennungstechniken (Anomaly detection techniques)
Definiert als »Suche nach Elementen oder Ereignissen, die nicht zu einem erwarteten Muster passen« Techniken sind Glätten, die schnelle Fourier-Transformation, der Kolmogorow-Smirnow-Test
Bad Apple Theory (faule Äpfel-Theorie)
Vorgehensweise zum Ausmerzen von Fehlern: es werden die Personen entfernt, die den Fehler begangen haben
Bad Paths
Spezielle Bezeichnung beim Sad Path: sicherheitsspezifische Bedingungen
Blameless post mortem
Post-Mortem-Meeting ohne Schuldzuweisung: Besondere Form des Meetings, um Fehler zu untersuchen
Blue-Green-Deployment-Muster
Methode zum Deployment: neue Software wird erst inaktiv deployed (blue) und später auf aktiv (green) geschaltet.
Branching-Strategie
(Branch = Zweig) Zwei unterschiedliche Möglichkeiten bei der Programmierung: auf individuelle Produktivität hin optimiert und auf Teamproduktivität hin optimiert
Brownfield
Kategorisierung von Software-Services oder -Produkte häufig als Greenfield oder Brownfield. Greenfield: neues SW-Projekt ohne Vorbelastung, Brownfield: Projekt basierend auf vorhandener SW inkl. der Vorbelastungen. Dabei entstehen Probleme, die bei neu entwickelter Software auftreten, welche sich in ein bestehendes Software- und Architekturkonzept eingliedern müssen. Im Gegensatz zur vollständigen Neuentwicklung (auch Greenfield-Entwicklung genannt) muss sich die Weiterentwicklung strukturellen Rahmenbedingungen beugen.
Betrieb (IT-Operations)
Abteilung eines Unternehmens/ Organisation, die für den Betrieb der EDV/ IT-Anlage zuständig ist.
Branch
Ein Branch (dt. Zweig) ist eine Verzweigung von einer anderen Version, so dass unterschiedliche Versionen parallel im selben Projekt weiterentwickelt werden können. Oft wird der Hauptentwicklungszweig als Trunk bezeichnet. Branches können zum Beispiel für neue Hauptversionen einer Software erstellt werden oder für Entwicklungszweige für unterschiedliche Betriebssysteme oder aber auch, um experimentelle Versionen zu haben. Wird ein Zweig in einer neuen, unabhängigen Versionsverwaltung erstellt, spricht man von einem Fork.
Canary-Release-Muster
Automatisierung des Release-Prozess des Transports in immer größere und kritischere Umgebungen, wenn der Code sich wie erwartet verhält.
Change-Zeitplan
Auflistung des zeitlichen Ablaufs eines Veränderungsprozesses
Cloud-Konfigurationsdateien
Beschreibungsdatei für die Bereitstellung von Servern in der Cloud
Cluster-Immune-System-Release-Muster
wie Canary-Release-Muster inkl. automatisiertem Rollback von Code
Code-Branch (Code-Zweig)
Einzelne Code-Branches (einzeln programmierte SW-Zweige) werden in der Versionsverwaltung in den Trunk integriert.
Code einchecken (codecommit)
Als Commit bezeichnet man bei der Verwendung von Versionsverwaltungssystemen den Vorgang des Einspielens von neuem oder geändertem Quelltext bzw. anderen Dateien in das Versionsverwaltungssystem. Dabei wird eine neue Version der Software den anderen an der Softwareentwicklung beteiligten Entwicklern zur Verfügung gestellt.
Compliance-Prüfung
Überprüfung von SW-Produkten auf Gesetzeskonformität
Compliance Officer
Funktion/ Rolle innerhalb einer Organisation/ Unternehmen, der für die Einhaltung von Gesetzen und Verordnungen zuständig ist
Container
Ein Container fungiert als Behälter von Anwendungen, einschließlich benötigter Komponenten wie Frameworks oder Bibliotheken.  Der Container ist von anderen Containern unabhängig und überall einsetzbar.
Continuous Delivery (kontinuierliche Lieferung)
Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung
Conways Gesetz
Das Design von Systemen entspricht der Kommunikationsstruktur der Organisation/ Unternehmens; wobei gilt, je größer das Unternehmen desto starrer werden die Strukturen.
Chaos Monkey
Verallgemeinerung des Begriffs Chaos Gorilla als Teil der Netflix Simian Army: Simuliert den Ausfall einer ganzen AWS Availability
Code review forms (Code-Überprüfungsformulare)
Formalisierung von Code-Reviews um einen gleiches Prüfniveau zu erreichen
Definition of Done (DoD, Definition von ‘Fertiggestellt’)
Gemeinsames Verständnis von Erwartungen, die Software erfüllen muss, um in die Produktion überführt werden zu können. Verwaltet vom Entwicklungsteam (Definition aus Scrum), erweitert: die SW muss  in einer produktionsähnlichen Umgebung demonstriert werden
Durchlaufzeit (Lead Time)
Länge der Zeit seit ein Ticket angelegt wurde bis die Arbeit abgeschlossen ist.
Die drei Wege
Grundprinzip von DevOps. Die drei Wege heißen:  Flow, Feedback, Kontinuierliches Lernen und Experimentieren
Entwicklungsrituale (dev rituals)
automatisierte Rituale, um technische Schulden zu bezahlen
Entwicklung (Development)
Prozess der Entstehung von Software
E-Mail-Weitergabe (e-mail pass-around)
Eine Form des Code-Reviews: Ein Quellcode-Verwaltungssystem schickt Code automatisch per E-Mail an Reviewer, nachdem er eingecheckt wurde.
Formen von Code-Reviews
Pair Programming, »Über die Schulter«, E-Mail-Weitergabe, Tool-unterstützte Code-Reviews
Fehler-Tracking (defect tracking)
Systematisches Ausmerzen von Fehler inkl. Sicherheitsproblemen; sollte in einem Trackingsystem erfolgen
Feature-Schalter
Begriff aus der Dark-Launch-Technik: Code wird in die Produktivumgebung geliefert und mit dem Feature-Schalter deployed. Ermöglicht Test unter Reallast, die für die Nutzer unsichtbar sind
Feedback
2. Weg der “Drei Wege”; sich verstärkende Rückmeldungen
Feedforward
Anmerkungen zu kommenden Aufgaben und Arbeiten
Firmen-Typisierungsmodell
Modell wie Firmen Informationen verarbeiten: pathologisch, bürokratisch und generativ
Geschäftswert (Business value)
über den substanziellen Wert hinausgehender Mehrwert eines Unternehmens, der auf Verhältnissen wie Lage, Kundenstamm, Ruf, Erfolgsaussichten beruht
Gauß-Verteilung
auch Normal- oder Glockenkurve; wird zur Untersuchung von Standardabweichungen benutzt
Greenfield
neues SW-Projekt ohne Vorbelastung (s. Brownfield)
gemeinsame Versionskontrolle (shared version control)
erfolgt über Versionsververwaltung um immer einen Green Build gewährleisten zu können
gemeinsame Ziele
Alle am SW-Entwicklungs- und Einsatzprozess beteiligten sollen die gleichen Ziele haben bzw. transparent die Ziele der Anderen erkennen und als die eigenen anerkennen
Hand-off Readiness Review (HRR)
Launch Readiness Review und Hand-off Readiness Review (LRR und HRR): HRR wird durchgeführt, wenn der fertige Service durch Ops betreut werden soll
Happy Path
Testverfahren, dass auf die Korrektheit von Funktionalität prüft
Information Radiators
generischer Begriff für eine beliebige Anzahl von handgeschriebenen, gezeichneten, ausgedruckten oder digital angezeigten Informationen, die vom Team an einer prominenten Stelle präsentiert werden, sodass alle Teammitglieder, aber auch Vorübergehende  Blick die neuesten Daten sehenauf einen
Infosec
Abkürzung von Information Security: Informationssicherheit, hier eine Abteilung im Unternehmen
Infrastruktur als Code
Als Infrastructure as Code (IAC) wird eine spezielle IT-Infrastruktur bezeichnet, die von Ops verwaltet wird. Dabei werden jedoch keine manuellen Verfahren verwendet, die Codes werden automatisch bereitgestellt und verwaltet. Infrastructure as Code wird auch als programmierbare Infrastruktur bezeichnet.
Integrationstest
Tests um die Integration von einzelnen Code in eine Gesamtumgebung zu prüfen
“I-förmig”, “T-förmig”, “E-förmig”
Modell über den Wissenstand eines Mitarbeiters: I= tiefes Verständnis in einem Bereich; T= tiefes Verständnis in einem Bereich, dazu allgemeines Wissen in mehreren Bereichen; E= tiefes Verständnis in vielen Bereichen
(nicht) ideale Test-Pyramide
Unterschiedliche Konzepte des automatisierten Testens. Ideal ist, das manuelle Testen ganz am Ende durchzuführen und damit sehr klein zu halten.
nichtfunktionale Anforderungen
NFR, Non-Functional Requirements: z. Bsp. Wartbarkeit, Verwaltbarkeit, Skalierbarkeit, Zuverlässigkeit, Testbarkeit, Deploybarkeit und Sicherheit
Kaizen Blitz (oder Improvement Blitz)
Der Kaizen Blitz ist ein fokussiertes, kurzfristiges Projekt zur Verbesserung eines Prozesses.  Hier: Spontanmeetings, in denen sich Techniker und Entwickler selbst in Teams zusammenfinden, um an von ihnen ausgewählten Problemen zu arbeiten.
Kanban
Methode, bei der die Anzahl paralleler Arbeiten (WiP) begrenzt und somit kürzere Durchlaufzeiten erreicht und Probleme – insbesondere Engpässe – schnell sichtbar gemacht werden können.
Kata
eine kleine, abgeschlossene Übung
kodifiziert
1. (Rechtssprache) Gesetze, Rechtsnormen in einem Gesetzeswerk zusammenfassen/ 2. in einem Kodex festlegen
Latente Fehler
Fehler, die zeitlich und räumlich weit entfernt von der Unfallentstehung auftauchen. Gegenteil: aktive Fehler
Launch-Richtlinien
Vorgaben für SW Launches: Anzahl und Schwere von Fehlern, Art und Häufigkeit von Warnungen, Monitoring-Abdeckung, Systemarchitektur, Deployment-Prozess oder Produktivhygiene
Launch Readiness Review (LRR)
Launch Readiness Review und Hand-off Readiness Review (LRR und HRR): LRR wird durchgeführt bevor ein neuer Service für Kunden verfügbar ist und Produktiv-Traffic generiert
Lernkultur
die Gesamtheit der für eine bestimmten Zeit typischen Lernformen und Lehrstile; hier: sichere Lernkultur durch Post-Mortem-Meetings, ohne Schuldzuweisung
Logging-Level
Einteilung von Telemetriedaten nach ihrer Wichtigkeit: Debug-, Info-, Warn-, Error-, Fatal-Level
lose gekoppelte Architektur
Lose Kopplung bezeichnet einen geringen Grad der Abhängigkeit mehrerer Hard- oder Software-Komponenten untereinander. Bei loser Kopplung eines Systems lassen sich Änderungen einzelner Komponenten oftmals einfacher durchführen, da die Änderung nur eine lokale Auswirkung hat.
Lean-Bewegung
Bewegung der 1980er Jahre, um das Toyota Production System zu kodifizieren. Wichtigster Glaube: Durchlaufzeiten und kleine Batchgrößen
Microservices
Microservices sind ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus unabhängigen Prozessen komponiert wird, die untereinander mit sprachunabhängigen Programmierschnittstellen kommunizieren. Die Dienste sind weitgehend entkoppelt und erledigen eine kleine Aufgabe. So ermöglichen sie einen modularen Aufbau von Anwendungssoftware./ Gehört zu den Architektonischen Prototypen; Gegenteil Monolith
Monitoring-Framework
Vorschriften um Telemetriedaten von Servern, Containern, Anwendungen und Netzwerkgeräten aufzuzeichnen und darzustellen
monolithisch
Gehört zu den Architektonischen Prototypen; Gegenteil Microservices
MTTR (Mean Time To Recover = mittlere Reparaturzeit)
Zeitangabe um Störungen zu beseitigen. Um geringere MTTR zu erhalten wird der Einsatz einer Versionsverwaltung in Operations sowie die Verwendung von Telemetriedaten und ein proaktives Monitoring in der Produktivumgebung empfohlen.
nichtfunktionale Anforderungen (NFR=Non-Functional Requirements)
(manchmal auch als »ilities« bezeichnet), Beispiele:  Wartbarkeit, Verwaltbarkeit, Skalierbarkeit, Zuverlässigkeit, Testbarkeit, Deploybarkeit, Sicherheit
Non-functional requirement (NFR) testing
Testen der nichtfunktionalen Anforderungen
Organisatorische Archetypen
Im Zusammenhang mit Conways Gesetz gibt es drei Arten von Organisationsstruktur: Funktion, Matrix und Markt
OPS liaison (Ops-Liaison-Modell)
zwei Typen von Ops-Liaisons: den Business Relationship Manager und den dedizierten Release Engineer
Over-the-shoulder (Über die Schulter)
Verfahren beim Code-Review: Ein Entwickler schaut dem anderen über die Schulter, während dieser den Code beschreibt.
Post-Mortem-Meeting ohne Schuldzuweisung
Meeting nach einem Zwischenfall zur Problemfindung und -lösung
Pakete
Ein Programmpaket, Programmsystem, Softwarepaket, eine Software-Suite oder ein Anwendungspaket, ist die Zusammenstellung von (logisch) zusammengehörenden Dateien und Anwendungsprogrammen. Erweiterung: Container
Pair Programming
Verfahren beim Code-Review: Programmierer arbeiten paarweise zusammen.
Peer Review
Ein  Peer-Review (englisch von Peer, Gleichrangiger und Review, Gutachten) ist ein Verfahren zur Qualitätssicherung einer Arbeit. Hier: Überprüfung von Code durch Kollegen
Post-Mortem-Analysen
Methode um Fehler in der Zukunft zu vermeiden
Product Owner
Hier: Die interne Business-Vertretung, die das nächste Funktionalitätspaket für den Service definiert.
Pull-Request-Prozess
Prozessbeschreibung wie mit Programmieränderungen um zu gehen ist
Qualitätssicherung (QS) = quality assurance (QA)
Abteilung, die für die Qualitätssicherung während des Produktionsprozesses zuständig ist
Reduzieren der Batchgröße
Grundprinzip der Lean-Bewegung. Die Batchgröße (also das gerade bearbeitet (Teil-)produkt) soll möglichst klein sein, um einen gleichmäßigen Wertfluss zu ermöglichen. Es kommt zu weniger Wartezeit vor Arbeitsstationen.
Release-Branch
Version des Codes, der ausgeliefert werden soll
Release-Manager
Zuständig für das Verwalten und Koordinieren des Produktiv-Deployments und der Release-Prozesse
Release-Muster
Durchführungsform von Releases: Umgebungsbasierte Release-Muster wie Blue-Green-Deployment oder Canary Releases und Anwendungsbasierte Release-Muster wie Dark Launch
Reduzieren von Verschwendung
Verminderung von Einsatz von Materialien oder Ressourcen die über das hinaus, was der Kunde benötigt oder wofür er zu zahlen bereit ist
schnelles Feedback
Feedback schnell zu bekommen gehört zu den Grundlagen von DevOps. Es sichert den Lernprozess.
Sad Path
Gegenteil von Happy Path. Hier werden Funktionalitäten geprüft, die nicht funktionieren sollen.
Sicherheitsbedingungen
Bündel von Sicherheitsvorschriften
Sicherheitstests
Tests, die die Einhaltung der Sicherheitsbedingungen prüft
Self-Service-Fähigkeit (self service capability)
Die Fähigkeit in der Deployment-Wertkette auf Selbstbedienungsfunktionalitäten wie das Einrichten von Umgebungen, das Durchführen von Test zu zugreifen.
Shared Operations Team (SOT)
Team, dass aus mehreren Rollen besteht und sich um die Deployments kümmert
Single Repository (of Truth)
Versionsverwaltung mit allen Quell- und Konfigurationsdateien der Anwendung, Produktionsartefakte, alle Tools und Artefakte zum Erstellen von Umgebungen etc
Smoke Test
eil der automatisierten Test: Unit-, Akzeptanz-, Integrationstest. Hier: ein umfassender Satz an Akzeptanztests, die gegen die gesamte Anwendung laufen
Standardabweichung
einfachste statistische Techniken zum Analysieren einer Produktivmetrik
statische Analyse
Berechnung von Mittelwert und Standardabweichung
System of Engagement (SoE)
Systeme mit hoher Änderungsgeschwindigkeit wie Webshops
System of Records (SoR)
Systeme bei denen die Richtigkeit der Daten und Transaktionen von größter Bedeutung ist wie ERP
Simian Army: Chaos Gorilla, Chaos Kong, Latency Monkey, Conformity Monkey, Doctor Monkey, Janitor Monkey, Security Monkey
Tests um die Resilienz des Systems zu stärken
Single Piece Flow
An jeder Arbeitsstation sollte nur ein Werkstück/ Feature warten.
Shared goals (geteilte Ziele)
Ziele, die nicht nur einzelne Abteilungen (Dev, Ops) oder einzelne Menschen haben, sondern die gemeinsam gelten
Techniken zur Anomalie-Erkennung
Definiert als »Suche nach Elementen oder Ereignissen, die nicht zu einem erwarteten Muster passen« Techniken sind Glätten, die schnelle Fourier-Transformation, der Kolmogorow-Smirnow-Test
technische Schulden
Unter der technischen Schuld versteht man den zusätzlichen Aufwand, den man für Änderungen und Erweiterungen an schlecht geschriebener Software im Vergleich zu gut geschriebener Software einplanen muss.
Technologie-Adoptionskurve
Verhaltensweisen bezüglich der Akzeptanz neuer Ideen (Grafik wie eine Gauss-Kurve)
technologische Führungskräfte
Führungskräfte aus den Technologieabteilungen eines Unternehmens
Test-Driven Development
Programmiermethode bei der erst die Test und dann der Code geschrieben wird, der die Test bestehen muss.
Theory of Constraints (Theorie der Beschränkungen)
Die Theory of Constraints (TOC), auch Engpasstheorie oder Durchsatz-Management, bezeichnet die Gesamtheit der Denkprozesse und Methoden zur Verbesserung der Leistungsfähigkeit (Durchsatz) von Systemen basierend auf den Ideen Eliyahu M. Goldratts./ Die Engpasstheorie geht von der Erkenntnis der Systemtheorie aus, dass der Durchsatz eines Systems ausschließlich von einem begrenzenden Faktor (dem Engpass oder englisch: Constraint) bestimmt wird. Eine Verbesserung des Durchsatzes kann nur erfolgen, wenn das Gesamtsystem, ausgehend vom begrenzenden Faktor, übergreifend optimiert wird./ Basierend auf den Denkprozessen der Engpasstheorie sind erfolgreiche praxistaugliche Methodologien zu Produktionssteuerung (Drum-Buffer-Rope), für Marketing und Vertrieb, für den Handel, für das Supply-Chain-Management, für Finanzen und Controlling, zur Strategieentwicklung und vor allem für das Projektmanagement (Critical-Chain-Projektmanagement) entstanden.
toolgestützte Review (tool-unterstütztes Code-Review)
Code-Review Methode: Autoren und Reviewer nutzen spezialisierte Tools zum Peer-Code-Review oder Features, die das Quellcode-Repository anbietet
Toyota Kata
anderer Begriff: Verbesserungs-Kata: Verbesserungsarbeit zur Gewohnheit machen und in die tägliche Arbeit aller in der Firma einbinden
Transformationsteam
Team, dass DevOps einführt
Trunk
Hauptentwicklungszweig des Projektes bei mehreren Branches
Test-Pyramide
Modell des Aufbaus von Tests
“Über die Schulter”
Methode des Code-Reviews: Ein Entwickler schaut dem anderen über die Schulter, während dieser den Code beschreibt.
Wertstrom
Der Wertstrom, engl. Value Stream, umfasst alle Aktivitäten (alle wertschöpfenden und nicht-wertschöpfenden Geschäftsprozesse), die notwendig sind, um ein Produkt/ Dienstleistung herzustellen und anzubieten./ Das Wertstrom-Konzept kann mit der „Wertkette“ (Value Chain), einem Konzept von Michael E. Porter, verglichen werden./ Die Wertstromanalyse ist eine Methode, um den Ist-Zustand eines Prozesses übersichtlich darzustellen. Sie ist die Basis, auf der durch Verringern von Verschwendung ein Prozess optimiert wird. Es wird der Wertstrom eines Produktes oder Services dargestellt.
virtuelle Umgebung
nicht-physikalische Server (-landschaft)
Virtualisierung
Virtualisierung bezeichnet die Nachbildung eines Hard- oder Software-Objekts durch ein ähnliches Objekt vom selben Typ mit Hilfe eines Abstraktions-Layers. Dadurch lassen sich virtuelle (d. h. nicht-physische) Geräte oder Dienste wie emulierte Hardware, Betriebssysteme, Datenspeicher oder Netzwerkressourcen erzeugen. Dies erlaubt es, Computer-Ressourcen (insbesondere im Server-Bereich) transparent zusammenzufassen oder aufzuteilen, oder ein Betriebssystem innerhalb eines anderen auszuführen.
Verschwendung
Waste
Work in Process / Progress (WiP)
Arbeit, die in den Entwicklungsprozess eingetreten ist, aber noch nicht abgeschlossen ist und einem Kunden oder Benutzer zur Verfügung steht./ Bezieht sich auf alle Vermögenswerte oder Arbeitsprodukte eines Produkts oder einer Dienstleistung, die gerade bearbeitet werden oder in einer Warteschlange warten, an der gearbeitet wird./ Deutsch: in Arbeit
Work in Process (WiP) Beschränkung
Maximale Anzahl von WIP
Vier (4) Arten von Arbeit
Die vier Arten von Arbeiten lauten: Businessprojekte, interne Projekte, Änderungen und ungeplante Arbeit
Verarbeitungszeit (process time)
Zeitspanne vom Beginn der Arbeit bis zum Abschluss der Zeit (vgl. Durchlaufzeit)

Aktuelle Blogeinträge

Work in Progress

DevOps-Lexikon: WIP

Der WIP ist häufig in zwei unterschiedlichen Ausschreibungen geführt. Work in Process Work in Progress Work in Process Als Übernahme des englischen Begriffes „Work in

Weiterlesen »