Release, Asset Lifecycle, Configuration, Procurement, Inventory Flashcards
Was sind Probleme des Release Management?
- fehlende Sichtbarkeit aller geplanten oder gerade durchgeführten Änderungen
- ungenügend detaillierte Änderungstasks (verhindert Synergien)
- unklare Berichtswege/Hierarchie
- unzureichende Prozessdefinition
- schlechte Paketverwaltung (keine Anleitungen, fehlende Dateien)
- Änderungen in letzter Minute (bei Auslieferung)
- Release macht sich durch zu späte Auslieferung selbst obsolet
Welche Arten von Releases gibt es?
- geplante Wartungsreleases (Releasezyklen, Planung erleichert es dem Kunden)
- ad-hoc-/projektbasierte Releases (ungeplant aufgrund von Ereignissen)
- inkrementelle Releases (organisches Wachstum, kein Endzustand)
- zusammenfassende Releases (setzen Standard für vorher abweichende Versionen)
Wie lautet die Checkliste für die Abnahme?
- Abnahmekriterien klar formuliert?
- Mitglieder des Abnahmeteams geschult genug, um Urteil fällen zu können?
- Alle Kombinationen von Betriebssystemen beachtet?
- Änderung verhält sich wie beschrieben/geplant?
- Installationsanleitung richtig?
- Release-Team mit Roll-out zufrieden?
Welche Pre-Release-Aktivitäten gibt es?
- Bestimmung von Voraussetzungen (HW, SW, Nutzerfähigkeiten)
- Baseline Leveling (alle auf einer Ebene vor dem Roll-out)
- Training des Support-Teams
- mise-en-place (alle Ressourcen gut logistisch verteilt)
- für den Release werben (Überraschungen vermeiden)
Welche In-Release-Aktivitäten gibt es?
- Fortschritt überwachen
- Exception Handling (Ersatz für heruntergefahrene Geräte)
- Performance und Motivation des Release-Teams (Statusmeldungen, Kommunikation)
Wann sollte eine einzelne Änderung als Release betrachtet werden?
- wenn sie lang dauert
- wenn viele Assets betroffen sind
- wenn die Änderung komplex ist
Wie sollte der Inhalt eines Releases ausgewählt werden?
- formelle Anfrage (Request)
- als Entscheidung des Release Managers
- Änderung ist mit anderer verwandt oder von ihr abhängig
Muss ein Release immer abgeschlossen sein?
- viele werden nie abgeschlossen
- künstliche Fortschritte/Meilensteine nützlich (zu 95% fertig)
Was sind die Ziele des Asset Lifecycle & Configuration Management?
- für jedes Asset maximalen Ertrag aus minimalen Kosten erzielen
- Lebensdauer erhöhen
- Beziehungen und Abhängigkeiten zwischen Assets erkennen (Risiken minimieren)
- Zuverlässigkeit und Verfügbarkeit verbessern (Analyse von Ausfalltrends Prävention)
Was sind die Probleme des Asset Lifecycle & Configuration Management?
- Tracking (wo ist das Asset?)
- Diebstahl/Verlust, inoffizielles Inventar
- ungeplante und nicht genehmigte Änderungen
- zu wenig Information, die eine konforme Reparatur/Ersatz möglich machen würden
- zu viele Möglichkeiten bei der Konfiguration
- Inkonsistenzen bei der Datenerhebung und in Berichten
Wie sieht der Lebenszyklus eines Assets aus?
- Kauf
- Installation
- Lagerung
- Auslieferung
- Routinenutzung
- Inspektion
- Prüfung der Effektivität
- Modernisierung/Upgrade
- Neuzuweisung
- Entsorgung
Was sind mögliche Metriken beim Asset Lifecycle & Configuration Management?
- Anzahl der Einheiten pro Typ, Hersteller, Einsatzort, Modell, Abteilung, etc.
- Anteil der Assets, die nicht der Standardkonfiguration entsprechen
Was ist die Definition eines Configuration Item (CI)?
- jegliches Element eines Rechensystems oder der unterliegenden Infrastruktur
- physische oder logische Elemente, die zur Erfüllung eines Dienstes dienen
- IT-Betriebsmittel
Was sind typische Eigenschaften eines Assets?
- Klassifikation (was ist es?)
- Beschreibung (welchen Typs ist es?)
- Eindeutige Identifizierung (was zeichnet es - und nur dieses – aus?)
- Status (wie ist seine Situation?)
- Meilensteine (wann passierte etwas wichtiges damit?)
- Primärer Zweck/Rolle (wozu dient es?)
- Dimensionen (wie groß ist es?)
- Kapazität (wie viele Dinge kann es – auf einmal – bearbeiten?)
- Konfiguration
- Standards/Support (welche Protokolle unterstützt es?)
- Version
- Kosten
Welche Beziehungen gibt es zwischen Configuration Items?
- technisch/physisch
- logisch (Prozesse, Systeme, Anwendungen)
- Performance (Verfügbarkeit innerhalb eines SLAs)
- zu Personen (Nutzer/Besitzer)
- zu anderen Dingen (Ort, Komponenten, Verträge, Organisationen)
- indirekt (Zuordnung zu Team)