ITSM EN1

Datenschutzgesetz: Regelt die Handhabung von Personenbezogenen Daten

OR: Regelt wie und wie lang Daten aufbewahrt werden müssen

Verordnung zur Aufbewahrung von Geschäftsdaten: Regelt die Aufbewahrung der Geschäftsdaten und der Verfügbarkeit (Bilanz/Buchungen)

- Modellierung: Wie muss das Archiv modelliert werden

- Speicherung: Welches Speichermedium ist zukunftssicher

- Backup / Restore: Wie werden die Daten für einen Krisenfall gesichert

- Verfügbarkeit: Wie werden die Daten verfügbar gemacht

- Entsorgung: Wie kann eine Entsorgung der Daten aussehen

- Modellierung (Datenmodell, Attribute)

- Datenquelle (Wo kommen die Daten her)

- Automatisierte Datenerfassung (WMI / Syslog / SNMT)

- Manuelle Datenerfassung

- Datenvalidierung

- Datenaktualisierung (Automatisch)

IaC bietet die Möglichkeit anhand eines Template komplette Infrastrukturen bereitzustellen. Moderne IaC-Lösungen sind in der Lage Compute-, Storage- und Netzwerkressourcen automatisiert zu provisionieren.

In der Regel wird dazu ein Provisioning Workflow erstellt. Der User kann über ein WebGUI die einzelnen Ressourcen auswählen und anschliessend provisionieren. Im ersten Schritt werden die zu konfigurierenden Ressourcen in der CMDB inventarisiert. Anschliessend wird des Template benutzt, um die Konfiguration der Elemente durchzuführen.

Grundsätzlich kann gesagt werden, dass in der CMDB die SOLL-Informationen gespeichert sind. Dadurch wird es möglich ungewünschte Konfigurationsänderungen in der Infrastruktur (IST) zu detektieren und ein automatisiertes «Config Enforcement» durchzusetzen. Im Markt gibt es entsprechende Lösungen, die das bereits heute unterstützen. Dazu zählen zum Beispiel Puppet, Chef oder Ansible

Durch das zentrale Halten der Assetdaten könenn auch zentral die Ausfälle erfasst werden und daraus Schlüsse über die Verfügbarkeit und Performance angegeben werden.

Die KPI können zentral erfasst und überprüft werden.

Beispiel:

Vor zwei Jahren wurde geplant, dass die neuen Züge der Firma Bombardier auf den Fahrplanwechsel in Einsatz kommen. Zu diesem Zeitpunkt können aber, nach heutigem Stand, nicht die ganze Flotte in Betrieb genommen werden. Dies hat den Grung, dass wir bei unseren umfassenden Qualitäts- und Sicherheitskontrollen zu unserem Bedauern feststellen mussten, dass die Züge nicht den Ansprüchen der SBB gerecht werden. Wir arbeiten sehr eng mit dem Hersteller Bombadier zusammen, damit die Züge ins SBB-Netz aufgenommen werden können. Die Züge sollen alle innerhalb von 3-4 Jahren integriert sein.

- Höhere Anforderungen an die IT-Abteilungen durch Fachabteilungen und Unternehmensführung (bei Wunsch nach hoher Effizienz und Effektivität)
- Historisch gewachsene IT-Landschaften, steigende Komplexität der eingesetzten IT-Technologien
- Steigende Benutzerzahlen, die IT-Support benötigen
- Modularisierung der Software und Nutzung von Standards (umfangreiches Angebot an Standardsoftware)
- Extrem hohe Fluktuation bei den im IT-Bereich Beschäftigten
- Zunehmende Anzahl kritischer IT-Anwendungen (immer mehr „mission- critical“-Applikationen)
- Zahlreiche Einflussfaktoren und Vorgaben für Rahmenbedingungen der IT-Nutzung (Gesetze, Verordnungen etc.)
- Sinkende oder gleichbleibende IT-Budgets/Budgetdruck der Kunden 

- Risiko- und Compliance-Management, IT Security
- Kundenorientierung und Beziehungsmanagement (SLA etc)
- Systemmanagementaufgaben vereinbaren
- Verantwortlichkeiten für Systeme zuordnen
- Richtlinien der IT-Systemnutzung
- Monitoring der IT-Systemleistungen
- Systemerwaltung (IT Asset Management)
- Strategische IT-Systemplanung (Beobachtung der Architekturvorgaben)
- Prozessorientierung (Identifikation, Prozesssteuerung)

- Das System muss klar abgegrenzt und beschrieben sein
- Es muss einen internen oder externen "Kunden" geben
- Die Anforderungen bezüglich Funktionalität, erfügbarkeit, Sicherheit etc müssen definiert sein
- Es muss einen Verantwortlichen und klar dokumentierte Abläufe (Prozesse) geben
- Die bemnötigten Fähigkeiten müssen vorhanden und erhalten bleiben
- Das Systemverhalten muss überwacht und zyklisch ausgewertet werden
- Veränderungen am System müssen koordiniert und dokumentiert werden

- Formeller Beschrieb der Anforderungen sowie der angebotenen Services (Servicekatalog)
  - Ein Service kann diverse Systeme enthalten
  - Prozessmodell
  - Trigger
  - Ein Service Level Agreement
  - Performance-Indikatoren
  - Serviceüberwachung
  - Fähigkeiten
  - Ressourcen

- Leichte / automatisierte Erhebbarkeit
- Interpretierbarkeit
- Kombinierbarkeit
- Aussagekraft
- Verantwortlichkeit
- Vergleichbarkeit

Der Begriff Service-Level-Agreement (SLA) oder Dienstgütevereinbarung (DGV) bezeichnet einen Vertrag resp. die Schnittstelle zwischen Auftraggeber und Dienstleister für wiederkehrende Dienstleistungen. Ziel ist es, die Kontrollmöglichkeiten für den Auftraggeber transparent zu machen, indem zugesicherte Leistungseigenschaften wie etwa Leistungsumfang, Reaktionszeit und Schnelligkeit der Bearbeitung genau beschrieben werden. Wichtiger Bestandteil ist hierbei die Dienstgüte (Servicelevel), die die vereinbarte Leistungsqualität beschreibt.

Charakteristisch für ein SLA ist, dass der Dienstleister jeden relevanten Dienstleistungsparameter unaufgefordert in verschiedenen Gütestufen (Service Levels) anbietet, aus welchen der Auftraggeber unter betriebswirtschaftlichen Gesichtspunkten auswählen kann. Bei einem herkömmlichen Dienstleistungsvertrag offeriert der Dienstleister diese Vertragsgestaltungsmöglichkeiten nicht.

MTBF ist die Abkürzung für die mittlere Betriebsdauer zwischen Ausfällen (engl. Mean Time Between Failures) für Einheiten, die instandgesetzt werden. Betriebsdauer ist die Betriebszeit zwischen zwei aufeinanderfolgenden Ausfällen einer Instand zusetzenden Einheit.

Berechnung: MTBF = sum(downtime - uptime) / n

Die mittlere Zeit zwischen Ausfällen ist nicht genügend. Wie beurteile ich die Dienstqualität, wenn ich den Service gerade nicht brauche bzw. wenn ich ihn gerade dringend brauche? ==> MTTR

Mean Time To Recover (MTTR) ist als die mittlere Zeit zur Wiederherstellung nach einem Ausfall eines Systems definiert. Sie ist somit ein wichtiger Parameter für die Systemverfügbarkeit, jedoch nicht für die Zuverlässigkeit (dort eher MTBF). • MTTR umfasst die Zeit für die Problemerkennung, Diagnose, Reparatur, Test und Freigabe.

Ein Operational Level Agreement (OLA) ist ein Zusatzvertrag, der üblicherweise innerhalb eines Unternehmens zwischen unterschiedlichen Abteilungen getroffen wird und der Absicherung eines übergeordneten Service Level Agreements (SLA) des Unternehmens gegenüber einem Endkunden dient. Das SLA ist eine vertragliche Vereinbarung zum Endkunden und das OLA eine unternehmensinterne Vereinbarung.

Dabei ist das Ziel des Vertrages immer die Absicherung einer höherwertigen Vereinbarung und enthält Absprachen über die Erbringung von definierten Services.

Weil ein OLA eine unternehmens- bzw. konzerninterne Vereinbarung ist, entspricht ein OLA in der Regel keinem Vertrag im juristischen Sinne, sondern einer Dienstleistungsvereinbarung. Der OLA spezifiziert Liefer- und Leistungsbeziehungen zwischen den beiden Parteien.

Zum Beispiel sichert ein Service Level Agreement eine hohe Verfügbarkeit einer Webanwendung gegenüber einem Endkunden.

Damit diese Vereinbarung im Ernstfall eingehalten werden kann, schliesst die gegenüber dem Endkunden garantierende Stelle, die Service Abteilung, ein OLA mit einem weiteren internen Dienstleister, z.B. der Technischen Abteilung, damit innerhalb eines definierten Zeitraumes nach einer Störungsmeldung ein Techniker eingesetzt wird.

- Name des Service

- Freigabeinformation (Service Level Manager, Interner Service Provider)

- Kontaktpersonen (Name des Service Provider, Name des Serviceempfänger, Verantwortliche Personen)

- Vertragsdauer (Start und Enddatum, Change Management-Regeln)

- Servicebeschreibung (Kurzbeschrieb, Benutzer auf Kundenseite, Aufteilung in Servicegruppen mit individuellen Anforderungen: Availability / Performance / Maintenance)

- Verhältnis zu anderen IT Services

- Vorgehen zum Beantragen des Service

- Zuständigkeiten (Serviceempfänger sowie IT-Sec, Zuständigkeiten und Haftung von Seiten des Service Provider)

- Qualitätssicherung und Service Level Reporting (Messverfahren)

- OLA Reviews (Review-Intervalle)

- Service Accounting (Kosten, Buchhaltungsmethode, Rechnungsintervalle)

Key Performance Indicators bezeichnet Kennzahlen anhand derer der Fortschritt oder der Erfüllungsgrad hinsichtlich wichtiger Zielsetzungen oder kritischer Erfolgsfaktoren innerhalb einer Organisation gemessen bzw. ermittelt werden kann.

- Marktanteile

- Kundenzufriefenheit

- Kosten/Nutzen-Entwicklung

- Innovationsrate

- Gesamtzahl der Störungen

- Durchschnittliche Lösungszeit mit Bezug auf SLA

- Prozentsatz der vom First Level Support behobenen Störungen (Lösung in erster Instanz, ohne Weiterleitung)

- Durchschnittliche Supportkosten pro Störung

- Behobene Störungen

- pro Workstation, pro ServiceDesk Mitarbeiter, …

- Anzahl der Störungen, die anfänglich falsch klassifiziert wurden

- Anzahl der Störungen, die falsch weitergeleitet wurden 

- Sensoren (Logfiles, Events, Trouble Tickets usw.)

- Filterung (Relevanz, Sensitivität, …)

- Normalisierung (Datum/Uhrzeit, Datenformate etc.)

- Speicherung (Listen / Excel, Datenbanken, Management-Konsolen)

- Beobachtung / „keep alive“
- Eskalation / Alarmierung
- Trend / Prognose
- Leistungsbeurteilung von Mitarbeitern / Abteilungen
- Beweis der Wirksamkeit getätigter Massnahmen gegenüber Kunden & Management
- Argumente für die Notwendigkeit weiterer Massnahmen (und Mittel)

Zielgruppe – wem zeige ich es?

Zweck – warum zeige ich es?

Periodizität – wie oft zeige ich es?

Aufmerksamkeitsspanne – ist es relevant?

Aussagekraft – Werden die Daten korrekt interpretiert?

1. Client

2. Lokales Netzwerk

3. Router (Provider)

4. Provider Netzwerk (Internet)

5. Firewall Google

6. Proxy Server Google

7. Web Server Google

8. Backend Services 

- Servicename

- Beschreibung

- Zuständigkeit

- Menge

- Preis

- Standardisierte Prozesse

- Klare Zuständigkeiten in der Support Organisation

- Transparenz

- Erstellen und Definieren Anforderungen
- Evaluation eines passenden Systems
- Implementieren System
- Migration
- Durchführung von Tests / Accaptance
- Betrieb

Ziel: Möglichst lang das System in der Betriebsphase zu betreiben,

- Kostendruck

- Steigende Komplexität

- Integration von Cloud Services

Das IT-Service Management definiert die Verwaltung von kompletten IT-Services. Ein IT-Service besteht in der Regel aus mehreren Assets (Systemen). Das System Management definiert die Verwaltung von einzelnen Systemen und bildet die Basis des IT-Service Managements. 

- CPU-Auslastung
- Memory-Auslastung (freier Speicher, benutzter Speicher)
- Disk-Auslastung (freier Speicher, benutzter Speicher)
- Memory Swapping / Seitenfehler
- Netzwerk (Dropped Packets / Bandbreite in/out)
- Temperatur CPU und Mainboard
- Laufende Prozesse (Anzahl)
- Anzahl Benutzer

RPO=0
Durch den Einsatz von synchroner Mirror Technologie kann ein Datenverlust verhindert werden. Das Storage System garantiert, dass alle write Operationen synchron zwischen zwei System repliziert werden.

RTO <5min
Definiert die Zeit, bis das Backup System den Betrieb wieder aufnimmt. Aktuell sind auf dem Markt keine Storage Systeme vorhanden, die eine RTO von 0 besitzen. Eine RTO kann nur durch den Einsatz von Applikationsredundanzen implementiert werden.

- Jahresabschluss (Erfolgsrechnung, Bilanz)
- Hauptbuch inklusive Buchungen und Belge
- Revisionsbericht

Die Daten müssen in einem lesbaren und nicht veränderbaren Format gespeichert werden (z.B. PDF).

Klassifikation der Daten ist zentral
Abhängig von der Klassifizierung der Daten kann anschliessend ein Schutzkonzept erarbeitet werden.

Compliance
Rechtlich verbindlich – Vorgaben müssen zwingend eingehalten werden.

Governance
Interne Vorgaben oder Vorgaben von einer Branche – Einhaltung ist nicht rechtsverbindlich