Das Oracle Release- und Patch- Management unter ITIL in der Praxis

Transkript

1 Das Oracle Release- und Patch- in der Praxis Kunde: DOAG Ort: Stuttgart Datum: Reiner Wolf, Trivadis AG Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien

2 Agenda Einleitung Einflussfaktoren Release- Das Change-, Configurationund Release- Configuration- Change- 2

3 Einleitung ORACLE Release Nummerierung Bezeichnung X.Y.Z.H (z.b ) X: Major Release Number Y: Revision Number Z: Maintenance Release Number H: Patch Set Number Lifecycles Das Change-, Configurationund Release- 3

4 Das Release Ziel Die Minimierung der Beeinträchtigung der Serviceumgebung durch eine zielgerichtete Planung und Steuerung der Releases > Vorgehensweise Das Change-, Configurationund Release- Die Qualitätssicherung mittels formeller Testund Abnahmeverfahren - sowohl auf der organisatorischen als auch auf der technischen Ebene Sicherstellen, dass alle Veränderungen an allen Configuration Items im Release stets nachvollziehbar, autorisiert und getestet werden

5 Das Release (2) Ziel Sicherstellen, dass nur freigegebene Hard- und Software im DHS (Definitive Hardware Store) bzw. in der DSL (Definitive Software Library) vorhanden sind Die Verfügbarkeit von Masterkopien (DSL) und von benötigter Hardware (DHS) sicherstellen > Vorgehensweise Das Change-, Configurationund Release- Ein effizientes Verfahren für die Durchführung (Planung, Dokumentation, Verteilung und Implementierung) neuer Release-Einheiten sicherstellen Qualitätssicherung und optimierung

6 Das Release (3) Einflussfaktoren Hardware Jährlicher Ausbau (Capacity) 3-jährlicher Wechsel > Vorgehensweise Das Change-, Configurationund Release- Software OS ORACLE Applikationen Organisatorisch Reorganisation intern neue Technologien (Produkt- / Firmensterben) Komplexität ( shared Databases ) applikatorische Abhängigkeiten (Policies) 6

7 Das Release (4) Abhängigkeiten Unterschiedliche Lifecycles (HW, OS, SW) Komplexität durch Einschränkungen der Infrastruktur ( shared databases ) Applikatorische Abhängigkeiten (Monatsabschluss) > Vorgehensweise Das Change-, Configurationund Release- Resourcenprobleme Problemmanagement (Bugs, Inkompatibilitäten) Fremdeinfluss

8 Das Release (5) Implementation > Vorgehensweise Das Change-, Configurationund Release- Maintenance-Windows grüne Wiese <-> gewachsene Infrastruktur Patchzyklen periodische Patches <-> One Off Patch Implementationsdauer Applikationsanforderungen maximale Downtime Knowhow der Business-Prozesse Resourcenplanung Infrastruktur / Applikation Qualitätssicherung Dokumentation 8

9 Der Release - Prozess Release Policy Entwicklungsumgebungen Planung des Releases Design, Entwicklung, Kauf, etc. Konfiguration des Releases (Build) DSL & DHS (verlinkt zur CMDB) Test & Abnahme Rollout- / BackOut-Planung Kommunikation, Schulung Verteilung Test- und Integrationsumgebungen Produktivumgebungen Installation

10 Das Configuration Ziele Die Bereitstellung von aktuellen und historischen Informationen über die verfügbaren IT-Services, die damit verbundenen IT-Infrastruktur-Configuration Items (CI`s) und deren Beziehungen untereinander > Vorgehensweise Das Change-, Configurationund Release- Sicherstellen, dass der Soll-Zustand der in der CMDB hinterlegten CI`s auch dem Ist-Zustand entspricht. Qualitätsgesicherte und vor allem für den jeweiligen Service benötigte Standardisierungen von entsprechenden CI`s sicherstellen. 10

11 Der Configuration - Prozess Identifikation der relevanten CI`s Optimierung des ges. Configuration-MgmT`s Planung und Strukturierung der CMDB Reporting (alle für den Service relvanten KPI`s) Statusüberwachung der CI`s (Life-Cycle-MgmT) Verifizierung und Audit (Soll<->IST) 11

12 Configuration : Theorie und Praxis Configuration Alle servicerelevanten Configuration Items müssen in der Config DB den richtigen Versionsstand zu jedem Zeitpunkt widerspiegeln und die Definitive Software Library muss aktualisiert bzw. ergänzt werden, weswegen die Information über neue Releases für das Configuration absolut notwendig ist. In der Praxis.. Wer pflegt die Daten? Wer kontrolliert die Daten? Was sind die Auswirkungen von falschen Informationen?

13 Das Change Ziele Optimierung des Services über alle Prozesse hinweg durch richtige Entscheidungen über die eingereichten RFC`s (Request For Changes). Wirtschaftliche und termingerechte Durchführung von autorisierten Changes. > Vorgehensweise Das Release- in der Praxis Minimierung der Risiken bei der Durchführung der Changes ( never touch a running System ). Gewährleistung der Nachvollziehbarkeit der durchgeführten Änderungen (IQ, GxP, SOX) 13

14 Das Change > Vorgehensweise Das Release- in der Praxis Aufgaben Entgegennahme, Bearbeitung und Dokumentation aller Changes Prüfung der RFC`s Notwendigkeit, Machbarkeit Wirtschaftlichkeit, Kosten Aufwand, Dauer Risiken, Abhängigkeiten Redundanzen und Paradoxen Autorisierung der Change Requests Planung (FSC), Organisation, Koordination und Abnahme der durchzuführenden Änderungen Zeit Resourcen Überwachung, Kontrolle und Reporting der beauftragen Aktionen 14

15 Der Change - Prozess RFC erfassen RFC akzeptieren Ja RFC klassifizieren Standard RFC? Nein Ja Stellen eines RFC vom Incident-, Problem-, Availibility-, Capacity- oder Service-Level-MgmT (Kunde über SLM). Standard Verfahren Informieren falls nicht im CAB evaluieren Nein Nein Ja Fallback nötig? koordinieren Dringender RFC? Ja Autorisieren durch CM / EC Ja planen Nein Nein Autorisieren durch CAB Ja Nein 15

16 Die Interaktion zwischen Change und Projekt Das Change - Registration & Classification (Erfassen & Klassifizieren) Das Projekt (PRINCE2) Monitoring & Planning (Planung & Machbarkeit prüfen) Approval (Zustimmung & Autorisation) Building (Erstellung) Authorisation & Implementation (Freigabe für die Implementation) Testing (Testen) Evaluation (Postinstallation) (Evaluieren und Abschluss) Implementation (Implementieren) 16

17 Change : Theorie und Praxis Change Ein Release ist im Grunde eine Einheit von einem oder mehreren Changes. Das bedeutet, dass die Entscheidung über Inhalt, Zusammensetzung und Zeitplanung von neuer Hardund Software immer unter Change Control steht. Das Release ist für die Durchführung verantwortlich, das Change für dessen Inhalt und Zeitplanung. In der Praxis. Das Change ist im Service der Infrastruktur integriert. Die betrieblichen Schwierigkeiten liegen in: Wer ist die treibende Kraft (Infrastruktur, Applikation)? Wer genehmigt die Changes? Welche Tools kommen zum Einsatz: Dokumentation Workflow Qualität

18 Danke für Ihre Aufmerksamkeit Reiner Wolf Senior Consultant, Trivadis AG Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien