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)
Was ist eine Configuration Management Database (CMDB)?
- Datenbank zur Verwaltung von Configuration Items
Wie ist die Vorgehensweise bei der Erstellung einer CMDB?
- Datenquellen identifizieren und bewerten
- Master festlegen (welche Daten aus welchen Quellen)
- Daten aufbereiten (Deduplizierung, Korrekturen)
- Datenextraktion
- Importmethode und -häufigkeit festlegen
- Validierungsregeln festlegen
- Daten konsolidieren/abgleichen
- Anforderungen für Synchronisation festlegen
- regelmäßig externe Daten mit Master aktualisieren
- regelmäßig Änderungen importieren und abgleichen
- Kontrollen definieren
Welche Probleme gibt es beim Erstellen einer CMDB?
- zu viele configuration items getracked bzw. zu allgemein gehalten
- schlechte Datenqualität (Fehler, Duplikate)
- zu komplizierte Datenmodelle (zu viele Klassen oder Beziehungstypen)
- zu viele getrennte Datenquellen mit unterschiedlicher Qualität
Aus welchen Schritten besteht der Configuration Management Prozess nach ITIL?
- Planung (Zweck, Scope, Ziele, Prozeduren)
- Identifikation (Konfigurationsstruktur mit Beziehungen, Besitzern etc.)
- Steuerung (nur genehmigte CIs akzeptiert)
- Statusreport (Bericht über aktuelle und historische Daten pro CI)
- Verifizierung und Audit (Existiert das CI noch?)
Was bedeutet Reconciliation und wozu braucht man es?
- Vereinbaren/Vereinigen von mehreren Datensätzen
- viele verschiedene Informationsquellen
- Diskrepanzen zwischen neu aufgenommenen Daten und Bestandsdaten
- automatisch identifizierte Datensätze mit zusätzlichen Daten ersetzen
- WICHTIG: Master-Datensatz bestimmen!
Welche typischen Fehler gibt es bei der Auswahl von Hardware/Software?
- Überspezifikation
- Technologie wird nur ausgewählt, weil “Trend”
- nicht auf mögliche Peak-Nutzung achten
- Equipment nicht upgradebar
- nicht auf mögliches schnelles Wachstum achten
Woraus besteht ein typischer Procurement-/Beschaffungsprozess?
- Kaufbedarf feststellen
- technisches und finanzielles Genehmigungsverfahren
- Kauf beim Lieferanten
- Lieferung
- Inventarisierung
- Abgleichen der Rechnung
Was sind die Ziele des Procurement-/Beschaffungsprozess?
- Lieferanten nach Leistungsindikatoren bewerten (Preis, Schnelligkeit, Qualität)
- Aushandeln von besonderen Konditionen
- Anzahl von nichtvertraglichen (“auf eigene Faust”) Käufen minimieren, reduziert Geschäftsrisiko
- Automatisieren und Routinieren von Kaufvorgängen
Was sind die Ziele des Inventory Managements?
- kostspielige Neuanschaffung von bereits vorhandenen Assets verhindern
- zurückgegebenes Inventar neu einsetzen, bevor es obsolet wird
- Lagerkosten minimieren
- Ort und Zustand von geschäftskritischem Inventar ausfindig machen
- ausreichendes Lager an Konsumwaren und oft angefragten Ersatzteilen (Patronen)
- Gebrauch von Assets planen und vorhersagen