Wie wir es gemacht haben: 600+ Anwendungen, eine Regionalverwaltung und Continuity, die sich von selbst bezahlt

Mit diesem Artikel eröffnen wir „Wie wir es gemacht haben“: eine Serie, in der wir ein reales Projekt nehmen und so erzählen, wie es gelaufen ist — ohne Namen, aus Vertraulichkeit, aber mit den echten Zahlen und Entscheidungen. Wir beginnen mit einem der anspruchsvollsten: dem mehrjährigen Management, der Weiterentwicklung und der Betriebskontinuität der Technologie-Infrastrukturen einer großen italienischen Regionalverwaltung.

Wir haben aktiv an Entwurf, Implementierung und Betrieb eines vollständigen IT-Service-Management-Modells für ein sich schnell entwickelndes Informationssystem mitgewirkt, mit einem Multi-Standort-Rechenzentrum von hoher technologischer Komplexität. Der Auftrag umfasste das Management und die Weiterentwicklung der Infrastrukturen für mehr als 650 Anwendungen, verteilt auf drei Technologiestränge, im Dienst von Tausenden internen und externen Nutzern, mit einem dedizierten Team spezialisierter Fachleute.

Das Projekt führte stark innovative Elemente ein: ein integriertes System der operativen Governance, eine Business-Continuity- und Disaster-Recovery-Lösung auf Basis eines both-active-Modells und einen methodischen Ansatz auf Grundlage der ITIL-Best-Practices — bei voller Konformität mit dem italienischen Gesetzesdekret 235/2010 (Art. 50-bis des Kodex der digitalen Verwaltung) und den Richtlinien der Digitalen Agenda.

Der Kontext und die Herausforderungen

Die Verwaltung stand vor einer tiefgreifenden Transformation ihres Informationssystems. Von einer Mid-Range-IT-Infrastruktur, die für die internen Bedürfnisse der Verwaltung ausgelegt war, war man schrittweise zu einem Rechenzentrum mit einer besonders komplexen Technologie-Infrastruktur in den Bereichen Netzwerk, Storage und Server übergegangen — im Dienst nicht nur der Verwaltung selbst, sondern auch zahlreicher Kommunen, Branchenverbände, privater Unternehmen und Bürgerinnen und Bürger des Gebiets.

Der Prozess des regionalen Föderalismus hatte den Umfang des Informationssystems qualitativ wie quantitativ wesentlich verändert und ein erhebliches Wachstum der zu verwaltenden Volumina, Systeme und Anwendungen mit sich gebracht: Die Zahl der veröffentlichten Anwendungen war in nur zwei Jahren um 15% gewachsen, über die drei Technologiestränge hinweg.

Die identifizierten Schwachstellen

Die Analyse des Ist-Zustands hatte Probleme aufgezeigt, die jeder, der in der öffentlichen Verwaltung arbeitet, auf Anhieb wiedererkennt:

• fragmentierte Monitoring-Werkzeuge: viele verschiedene Tools (Trouble-Ticketing, Monitoring, CMDB, Projektmanagement) mit unkorrelierten Daten und ohne integrierte Sicht auf die IT-Dienste;
• Kluft zwischen Entwicklung und Betrieb: die fehlende „Verschweißung“ zwischen dem Lebenszyklus des Softwareprojekts und dem Lebenszyklus des Dienstes war das schwächste Glied der Kontrollkette;
• kein strukturierter Business-Continuity- und Disaster-Recovery-Plan, entgegen den mit dem Gesetzesdekret 235/2010 eingeführten regulatorischen Pflichten;
• Storage ohne Klassifizierung nach Tier-Logik (Performance, Kapazität, Zuverlässigkeit), mit entsprechenden betrieblichen Ineffizienzen;
• Single Points of Failure bei Internetanbindung und Perimeterschutz;
• Bandsicherung mit Zeitfenstern, die für die kritischen Dienste nicht ausreichten;
• kein integriertes Dashboard für operative Governance und Leistungsnachweis der Dienste.

Die strategischen Ziele

Die Verwaltung hatte klare Ziele definiert — und keines davon lautete „Technologie kaufen“:

1. eine prozessorientierte Methodik für das Management der IT-Dienste einführen, mit der von den Nutzern wahrgenommenen Qualität als Dreh- und Angelpunkt;
2. sich einen Business-Continuity- und Disaster-Recovery-Plan geben, der den geltenden Vorschriften entspricht;
3. eine integrierte Governance-Plattform für die End-to-End-Kontrolle der IT-Dienste implementieren;
4. die Betriebskontinuität während der Transition unterbrechungsfrei gewährleisten;
5. die volle Messbarkeit und Transparenz der erbrachten Dienste durch objektive SLAs und KPIs sicherstellen.

Organisationsmodell und Governance

Wir entwarfen daher ein schlankes, flexibles Organisationsmodell mit klaren Entscheidungsrollen, strukturiert auf drei Governance-Ebenen:

• Strategische Ebene — IT Steering Group: ein Exekutivkomitee aus Vertretern der Verwaltung, zuständig für die Ausrichtung an den strategischen Zielen sowie die Bewertung der nötigen Investitionen und des Entwicklungspfads der IT-Infrastruktur;
• Taktische Ebene — Kontrollkomitee der IT-Dienste: das operative Gremium für Planung und Koordination der Umsetzungsmaßnahmen, mit dem Technical Manager als Hauptschnittstelle für die täglichen Kontroll-, Management- und Entwurfsaktivitäten;
• Operative Ebene — drei integrierte Teams, beschrieben in der folgenden Tabelle.

Die Area Change: Integration der Lebenszyklen von Software und Dienst

Eines der innovativsten Elemente der Lösung war die Schaffung der Area Change, einer teamübergreifenden Organisationseinheit, die der „Übernahme“ der produzierten Software und ihrer anschließenden „Transformation“ in einen Dienst für die Nutzer gewidmet ist — dasselbe Prinzip, das wir heute über den gesamten Service-Lebenszyklus hinweg anwenden. Die Area Change gewährleistete:

• die Integration zwischen der Entwurfs- und Entwicklungsphase der Anwendung (Service Design) und der Phase der Diensterbringung (Service Operation);
• hohe Aufmerksamkeit für die Test- und Validierungsphasen des Dienstes (Service Transition);
• die Planung der Release-Aktivitäten für jeden neuen Dienst / jedes neue Produkt;
• die Identifikation und den Vorschlag von Strategien und Innovationspfaden im Lebenszyklus der Dienste;
• die Koordination der Ressourcen, die der Definition und Kontrolle von Standards und Leitlinien gewidmet sind.

Die Area Audit und Verbesserung

Um eine konstante, objektive Bewertung der Servicequalität zu gewährleisten, richteten wir die Area Audit und Verbesserung ein, mit folgenden Verantwortlichkeiten:

• kontinuierliches Monitoring der vordefinierten Qualitätsparameter (KPIs und SLAs);
• Planung von Verbesserungsmaßnahmen auch bei bereits zufriedenstellenden Werten;
• Unterstützung bei der Erstellung einer IKT-Service-Charta, um den „Servicepakt“ zwischen der IT-Abteilung und den nutzenden Generaldirektionen zu formalisieren;
• Management des Prozesses der Kundenzufriedenheit;
• Erhebung der statistischen Indikatoren für den periodischen Leistungsnachweis.

Das System der operativen Governance: ein einziges Dashboard, fast alles Open Source

Auf die Fragmentierung der Werkzeuge antworteten wir mit der Mitwirkung an der Implementierung einer vollständigen, integrierten Plattform zur Unterstützung der IT-Funktionen und -Prozesse — dem Herzstück dessen, was wir IT-Governance nennen — strukturiert in drei Hauptbereiche und großteils auf Open-Source-Komponenten aufgebaut.

Governance der Dienste

• integriertes Management von Incidents, Problemen, Changes und Konfiguration über CMDBuild;
• Trouble-Ticketing-Werkzeug ( RT) zur Verfolgung von Serviceanfragen und Incidents;
• Interaktion mit den Lastverteilungssystemen ( LBL LoadBalancer) für das Capacity Management;
• Wissensbasis auf Grundlage von Alfresco für das zentralisierte Dokumentenmanagement.

Governance der Infrastruktur

• Storage Management: Datenverwaltung, Backup und Wiederherstellung;
• System Fault & Performance Management: Echtzeit-Monitoring über Zabbix mit zentralisierter Konsole, Filterung und Korrelation der Ereignisse;
• Application Performance Management: Kontrolle der Dienste aus Nutzersicht mit Beispieltransaktionen;
• Historisierung der Daten in einem Open-Source-Data-Warehouse, SpagoBI, für Analysen und Reporting.

Wissensmanagement

• zentralisiertes Dokumenten-Repository auf Grundlage von Alfresco;
• Organisation, Persistenz und Nutzung des im Rahmen der Diensterbringung produzierten Wissens;
• Unterstützung der Schulungs- und Trainingsaktivitäten.

Das Governance-Monitor-Dashboard

Über allem das Monitor-Dashboard auf SpagoBI-Technologie. Für eine öffentliche Verwaltung ist das kein kosmetisches Detail: Es ist der Unterschied zwischen dem Behaupten von Servicequalität und der Fähigkeit, sie Zahl für Zahl zu belegen. Das Dashboard bot:

• eine „Ampel“-Gesamtsicht auf den globalen Zustand der Dienste;
• die Navigation durch die KPIs jedes erbrachten Dienstes;
• Vertiefungen nach Dimensionen und Zeiträumen (Echtzeit, Tag, Woche, Monat);
• Reports, OLAP, Data Mining und QBE;
• ein Logbuch: Gesamtsicht auf alle Ereignisse der Diensterbringung, filterbar nach Zeitpunkt, Dienst, System, auslösendem Ereignis und Typologie;
• ein Kostenumlage-Modul mit Zuordnung der Kosten zu den nutzenden Direktionen;
• die Verwaltung von Anwesenheiten und Schichten des technischen Personals;
• Site Activity zur Nachverfolgung, „wer was tut“;
• die Projektaktivierung mit Fortschrittsverfolgung über Redmine.

Die ITIL-Kernprozesse

Anschließend wurde ein vollständiges Set von Kernprozessen (PF) auf Basis von ITIL v3 implementiert, zugeschnitten auf die spezifischen Bedürfnisse der Verwaltung:

Change Management und IMaaS

Für das Management der Infrastrukturänderungen führten wir das Konzept „Infrastructure Model as a Service“ (IMaaS) ein: Das Team Projektentwicklung liefert Infrastrukturmodelle, die nach ihrer Genehmigung in operative IT-Architekturen überführt werden. Der Change-Prozess gliedert sich wie folgt:

1. Request For Change und Machbarkeitsanalyse;
2. Service Design nach den 4 P von ITIL (People, Products, Processes, Partners);
3. Auslieferung des Service Design Package (SDP) mit Anforderungen, technischen Spezifikationen, Testplänen, Transition-Plan und Operation-Plan;
4. Genehmigung durch die Verwaltung;
5. Transition: Aufbau der Test- und Abnahmeumgebungen;
6. Produktivsetzung mit Unterstützung des Teams Betriebsmanagement;
7. CSI (Continual Service Improvement) quer durch alle Phasen.

Zusätzlich wurde ein virtuelles Labor (IaaS) zur Simulation der Transition-Phasen vorgeschlagen — mit dem Ziel, die Einführung und das Management von Änderungen zu vereinfachen, die Transition-Aktivitäten zu standardisieren, die Integrität der Konfigurationen der Produktionsinfrastruktur zu sichern und Probleme und Incidents in der Produktion zu reduzieren.

Business Continuity und Disaster Recovery: Continuity, die sich von selbst bezahlt

Das innovativste Kapitel ist die Business Continuity. Die Lösung wurde in voller Übereinstimmung entworfen mit:

• dem italienischen Gesetzesdekret Nr. 235 vom 30. Dezember 2010, Art. 50-bis (Betriebskontinuität);
• den DigitPA-Richtlinien (heute AgID) für die technischen Machbarkeitsstudien;
• den Normen ISO 22301 / BS 25999 für das Business Continuity Management;
• dem ITIL-Framework — Prozess des IT Service Continuity Management (ITSCM);
• der Methodik M_o_R (Management of Risk) für Risikoanalyse und Risikomanagement.

Multi-Standort-Architektur

Der klassische Ansatz sieht einen Sekundärstandort vor, der Geld kostet, Strom verbraucht und ausgeschaltet auf den Notfall wartet. Hier haben wir das Gegenteil getan und die Architektur auf mehreren Ebenen aufgebaut.

Business Continuity Site (BCS) — innerhalb des Campus der Verwaltung:

• both-active-Modell: Der BCS ist kein passiver Kostenfaktor, sondern beteiligt sich in Echtzeit aktiv an der Diensterbringung;
• asynchrone Replikation auf Storage-Ebene (Tier 4) für die kritischen Dienste, über IBM-SVC-Virtualisierer und Global-Mirror-/FlashCopy-Systeme;
• Replikation über Agenten/Snapshots (Tier 3) für Dienste geringerer Kritikalität, über VMware Site Recovery Manager und vSphere Replication;
• 10-Gbit-Ethernet-Backbone und erweitertes Storage Area Network mit doppelter Glasfaser-Fabric;
• autonome Internetanbindung und dedizierte Perimeterschutzsysteme.

Disaster Recovery Site (DRS) — bei einem externen Anbieter in über 80 km Entfernung:

• native architektonische Vorbereitung für die Aktivierung im Notfall;
• Anbindung über DWDM-Technologien (Dense Wavelength Division Multiplexing) für Entfernungen über 100 km;
• überwiegend virtualisierte Infrastruktur mit der Möglichkeit des Bare-Metal-Restore.

Ein Continuity-Standort, der ausgeschaltet bleibt, ist ein Kostenfaktor, der auf ein Desaster wartet. Einer, der jeden Tag arbeitet, ist produktive Kapazität — und bezahlt sich von selbst.

LBL Surface Cluster: Orchestrierung und Split-Brain-Prävention

Das heimtückischste technische Risiko einer Architektur mit zwei aktiven Standorten ist das Split Brain: Beide Standorte halten sich für den „echten“ — mit logischer Datenkorruption als Folge. Um die Failover-/Failback-Prozeduren zu steuern und dieses Szenario zu verhindern, führten wir dank der Zusammenarbeit mit unserem Partner Oplon die Suite LBL Surface Cluster (Decision Engine und WorkFlow) ein, mit folgenden Funktionen:

• der Algorithmus „Split Brain Assassin“: Prävention der logischen Datenkorruption bei paralleler Speisung der Datenbanken;
• Decision Engine: 3 geclusterte Instanzen pro Standort, für die ständige Überprüfung der kritischen Dienste und die Entscheidungsfindung;
• WorkFlow: koordinierte Ausführung der Aktivitätssequenzen (Skripte, Neustarts, Abschaltungen) über RWC-Fernbefehle (Remote Workflow Command);
• Selbstdokumentation der Failover- und Failback-Prozeduren;
• eine intuitive Web-Konsole zur Reaktivierung der Dienste auch durch nicht spezialisiertes Personal — denn im echten Notfall ist der Spezialist vielleicht nicht da.

Schutzstufen (Tiers)

Nicht alle Dienste sind gleich viel wert, und die Business Impact Analysis übersetzte das in differenzierte Schutzstufen — dasselbe Prinzip, das wir in „Backup allein genügt nicht“ erzählen: RTO und RPO werden pro Dienst definiert, nicht für die gesamte Organisation.

Die Pläne: BCP, DRP, BIA und Risikoanalyse

Anschließend wurde ein vollständiger Dokumentationskorpus erstellt und über die Zeit gepflegt:

• der Business Continuity Plan (BCP): Identifikation der Exposition gegenüber internen und externen Gefahren, der Hardware-/Software-Assets und der Prozesse zur Prävention von Ausfällen und zur Wiederherstellung der Dienste;
• der Disaster Recovery Plan (DRP): operative Schritt-für-Schritt-Prozeduren, Checklisten und technische Schemata für die reaktiven Phasen Response und Recovery;
• die Business Impact Analysis (BIA): Quantifizierung der Auswirkung einer Unterbrechung der IT-Dienste auf das Geschäft;
• Risk Analysis und Risk Management: Identifikation der Bedrohungen, Bewertung ihrer Eintrittswahrscheinlichkeit und Definition der Gegenmaßnahmen.

Das Management des Anwendungsdienstes

Der — ad hoc geschaffene — Prozess, der das gesamte Leben einer Anwendung im Betrieb steuert, von der Entstehung bis zur Stilllegung.

Übernahme und Anlauf

Der Übernahmeprozess eines neuen Anwendungsdienstes sah vor:

1. Prüfung der Vollständigkeit und Angemessenheit der Dokumentation;
2. Impact-Analyse und Change-Management (CAB);
3. Einrichtung der Produktionsumgebung (Basissoftware, Anwendung, Datenbank);
4. Einrichtung der Monitoring-Umgebung (Sonden und spezifische Regeln);
5. Einrichtung der Verwaltungsumgebung (Parametrisierung und Übergabe);
6. Registrierung der Configuration Items in der CMDB;
7. Abnahme der gesamten Infrastruktur;
8. Schulung des Teams Betriebsmanagement.

Weiterentwicklung des Dienstes

Für Weiterentwicklungen (neue Funktionen, Konfigurationsänderungen) sah der Prozess die Identifikation der Änderungen und die Impact-Analyse vor, die Ausführung des Regressionstests vor der Produktivsetzung sowie die Aktualisierung der CMDB und der Betriebsdokumentation.

Beendigung des Dienstes

Für die Stilllegung eines Dienstes: Prüfung der Auswirkung auf die übrigen Dienste, Sicherung der Archive, Deinstallation der Anwendungskomponente, Aktualisierung der CMDB und Neuzuweisung der Ressourcen über das Capacity Management.

Schulung, Wissensmanagement und Know-how-Transfer

Ein mehrjähriger Auftrag wird auch daran gemessen, wie er endet: Das Wissen muss am Ende bei denen bleiben, die es ausüben müssen.

Schulung des Personals

Es wurde ein Prozess des kontinuierlichen Knowledge Sharing implementiert, mit:

• einer angemessenen Zahl jährlicher Schulungstage für jede Ressource;
• ITIL-Zertifizierungspfaden (Foundation, Service Strategy, Service Design, Service Operation, CSI) für die Bereichsverantwortlichen;
• Kursen an der internen IKT-Hochschule für Weiterbildung;
• Fernunterricht und Präsenzseminaren;
• Selbststudium mit Produkthandbüchern und Dokumentationsressourcen.

Wissensmanagement

Der Wissensmanagement-Prozess gliederte sich in zwei rekursive Phasen: die Organisation des Wissens (Identifikation der Bedarfe, Recherche, Katalogisierung in einem nach Serviceprozessen klassifizierten Repository) und die Valorisierung des Wissens (Verteilung, Nutzung und kontinuierliche Aktualisierung des gesammelten Know-hows).

Know-how-Transfer am Ende des Auftrags

Der Exit-Management-Plan sah vor:

• Schritt 1 — Programmierung: Vorbereitung der Dokumentation, vorbereitende Sitzungen, Organisation von Seminaren, Prüfung des Systemzustands anhand von Checklisten;
• Schritt 2 — Begleitung: Präsenz-Lernsitzungen, eigenständige Ausführung spezifischer Aufgaben, Bewertung und Selbstbewertung, Training on the Job;
• zwei Monate On-Demand-Unterstützung nach Auftragsende (E-Mail, Telefon, Online-Kommunikation).

Ressourcen und Kompetenzen

Das Team Zentralisierter Systemsupport arbeitete mit 24/7-Abdeckung in sechs vertikalen Bereichen:

1. Infrastruktur (IBM-/HP-Blade-Server, Netzwerk, VMware-/Citrix-Virtualisierung);
2. Middleware (WebSphere, JBoss, IIS, Apache, Tomcat);
3. Datenbanken (Oracle, SQL Server, PostgreSQL, MySQL, DB2);
4. Kartografie (GIS- und Territorialsysteme);
5. Open Source (Linux, Red Hat, FOSS-Lösungen);
6. SAP (ERP-, BW-, CRM-Umgebungen).

Das Ganze gestützt auf ein System von Zertifizierungen und Partnerschaften:

ISO 9001ISO 14001ISO/IEC 27001CMMI Stufe 3ITIL v3PMPPRINCE2

Ergebnisse und Nutzen

Infrastruktureller Nutzen

• Zuverlässigkeit: eine von den Herstellern zertifizierte und durch vergleichbare Implementierungen validierte Lösung;
• Elastizität: Hardware- und Softwarekomponenten, die Infrastrukturänderungen mit minimalem Aufwand abfedern;
• Standardisierung: ständiger Abgleich mit ISO-Normen, dem ITIL-Framework und den Branchenvorschriften;
• Resilienz: korrekte Dimensionierung der Infrastrukturen und wohlüberlegte Technologiewahl;
• Kontrolle: globales Management aller Standorte über zentralisierte Werkzeuge.

Wirtschaftlicher Nutzen

• Skaleneffekte: Der aktive BCS erhöhte insgesamt die erbrachten Dienste;
• Virtualisierung: Senkung der Gesamtbetriebskosten (TCO) der Infrastruktur;
• Storage-Optimierung: Rationalisierung durch Multi-Tier-Technologie (EasyTier), mit SSD-Platten für kritische Daten und Kapazitätsplatten für den Rest;
• Wiederverwendung vorhandener Assets: Begrenzung des Neukaufs von Hardware durch Umverteilung von Ressourcen, die die Verwaltung bereits besaß.

Organisatorischer Nutzen

• Überwindung des Konflikts Entwicklung/Betrieb dank der Area Change;
• kontinuierliche Verbesserung, institutionalisiert durch die Area Audit und den CSI-Prozess;
• Transparenz in der Zusammenarbeit zwischen Verwaltung und Dienstleister;
• die IKT-Service-Charta als Formalisierung des Servicepakts;
• Leistungsnachweis und Kostenumlage auf die nutzenden Direktionen.

Die Innovationselemente

Fazit

Das realisierte Projekt steht für einen Exzellenzfall im integrierten Management von Technologie-Infrastrukturen für die öffentliche Verwaltung. Die Kombination aus Spezialkompetenzen, ITIL-Methodik, Open-Source-Governance-Werkzeugen und innovativen Business-Continuity-Lösungen ermöglichte es der Verwaltung:

• die Betriebskontinuität ihrer IT-Dienste in Übereinstimmung mit den geltenden Vorschriften zu gewährleisten;
• eine integrierte, transparente Sicht auf die gesamte Technologie-Infrastruktur zu gewinnen;
• die operativen und Desaster- Risiken um 50% zu senken;
• die Kosten zu optimieren — durch Virtualisierung, Asset-Wiederverwendung und das aktive BCS-Modell;
• die Qualität der erbrachten Dienste durch strukturierte Audit- und CSI-Prozesse kontinuierlich zu verbessern;
• das Wissenskapital zu bewahren — durch einen strukturierten Plan für Wissensmanagement und Know-how-Transfer.

Die Lösung erwies sich als skalierbar, tragfähig und voll in den organisatorischen und technologischen Kontext der Verwaltung integriert: ein Modell, das sich auf andere öffentliche Verwaltungen vergleichbarer Größe und Komplexität übertragen lässt — wir sprechen darüber auf unserer Seite zur lokalen Verwaltung, während unser Ansatz aus Messen, Analysieren und kontinuierlichem Verbessern in unserer Methode erzählt wird. Wenn Ihre Organisation vor einer ähnlichen Transition steht — eine Governance, die aufzubauen ist, eine Continuity, die normgerecht werden muss, Dienste, die schneller wachsen als die Kapazität, sie zu verwalten — sprechen wir darüber.

Aus Vertraulichkeit nennen wir die Verwaltung nicht; Daten und Indikatoren beziehen sich auf den Zeitraum der Leistungserbringung.