CAB

1. Einführung (Um was geht es)
2. Nutzenargumentation (Qualitative Begründung)
3. Annahmen und Methoden (von welchem Kostenmodel geht man aus)
4. Betriebswirtschaftliche Auswirkung (Quantitative Begründung - Nutzen/Vorteil, NPV)
5. (optional) Risikoanalyse
6. Fazit

Allgemein: Die Kapitalwertmethode dient der Wertbestimmung einer Investition die heute getätigt würde.
Dabei werden dem investierten Kapital Alle Ausgaben und Erträge  gegenüber gestellt. Man geht immer davon aus, das man das "investierte" Kapital intern fest verzinsen könnte.

Es geht immer darum, das man zukünftige Cash Flows auf den heutigen Wert zurückrechnet.

Beispiel: Wir müssen heute 100 Fr investieren und in einem Jahr nochmals 100.
Die 100Fr die in einem Jahr fällig sind, sind heute 96.15Fr Wert bei 4% Zins. Also benötigen wir Total für die Investition 196.15 Fr.
Auf der anderen Seite erhalten wir nach 3 Jahren 105 + 110 Fr aus der Investition. Wenn man das wieder zurückrechnet (negativ 4%) sind das 194 Fr. Also 2Fr weniger als die Initiale Investition -  das Geschäft lohnt sich nicht.

• Verfügbarkeit: 5x9h oder 7x24h
• Ansprechpartner / Support Telefon
• Verantwortliche Personen (Auf Kunde und Anbieter Seite)
• RPO (Recovery Point Objective)
• RTO (Recovery Time Objective)
• Beschreibung des Services
• Performance Angaben
• Preis

On Demand Self Service:

Der Benutzer kann sich selber Services und Resourcen aus dem Cloudangebot zuweisen (je nach Bedarf)

Scalability:

Funktionen und Kapazitäten skalieren schnell und automatisch je nach Bedarf. Für den Kunde sehen die Ressourcen fast "unlimitiert" aus.

Broad Network Access:

Die Services sind über das Internet (global) zugänglich auf allen möglichen Geräten (PC/Mobile).

Resource Pooling:

Die Resourcen für die Services sind virtualisiert gebündelt und werden dynamisch zugeteilt (Software Defined Everything).

Measured Services:

Die Services werden überwacht um auf ausfälle oder Qualitätseinbussen sofort reagieren zu können.

• IaaS
  • Infrastructure as a Service
  • Anwender: Application Owner
• PaaS
  • Platform as a Service
  • Applikationsentwickler
• SaaS
  • Software as a Service
  • Endnutzer
• FaaS
  • Function as a Service
  • Programmierer

Public Cloud:
Cloud für alle, z.B. Dropbox

Community Cloud:
Cloud für eine Gruppe, Interessengemeinschaft. Z.B. Switch

Private Cloud:
Nur von einer Organisation genutzt.
Gibt Subkategorieren

Hybrid Cloud:
Kombination aus Public/Private (Z.B. OneDrive HSLU)

• Intern
  • Wird von interner IT Betrieben, im eigenen RZ
• Outsourced
  • Wird von externer IT Betrieben, im eigenen RZ
• Hosted
  • Wird von externer IT Betrieben, im RZ Extern
• Virtual
  • Analog Hosted, aber Software Defined X

• Aufteilung der Software in Layers (Vertikale Skalierung)
• Verteilung der Software auf mehrere Rechner (Horizontale Skalierung)
• Ausbau der Rechner (RAM, CPU)
• Aufbau der Software (Multithreaded, Multiprocessing)

Layering: Aufteilung der Software in Tiers (Präsentation, Logik, Daten)

Runtimekomponenten: Aufteilung in seperat startende Runtimekomponenten

Verteilung auf Rechner: Verteilung der Runtimekomponenten auf mehrere Rechner

Multiprozess/User Fähigkeit der SW: Die Software soll mehrmals gestartet werden können.

Public Cloud

• Viele User
• Verarbeiten von vielen Daten
• Weniger Funktionalität

Private Cloud

• Standardisierte Plattform
• Viele Funktion
• Erfüllt individuelle Kundenanforderung
• für weniger User gedacht

• Facility
  • Buildung Blocks:
  • Gebäude, Energie, Kühlung, Racks, Monitoring, Administration, Internet, Sicherheit, Zutritt...
• Hardware
  • Server, Storage, Network
• Virtualisierung
  • Server, Stprage, Network (Software Defined)
• Service
  • Cloudservice: Computing, Storage, Networking...
  • Operation Support: Monitoring, Asset Mgmt, Event Mgmt (ITIL)
  • Business Support: Bustomer & Billing Mgmt
• Orchestration
  • Zentralisierte und Stark Automatisierte Verwalten der gesamten Infrastruktur
• Access & Client
  • Verbindung zum Kunde (oder wie der Kunde auf Cloud zugreifft)

Viel Arbeit erspart man sich mit der Automatisierung über die Web-APIs.Cloud-Automation Tools bringen leistungsfähige Web-APIs mit, welche zur Automatisierung beitragen.

OpenStack ist ein Softwareprojekt, das eine freie Architektur
für Cloud-Computing zur Verfügung stellt.

Komponenten
 

• Compute
• Image
• Object Storage
• Network
• Zentral: Identity

vRealize Suite:

Verwaltungsplatform zur Entwicklung VM oder Container basierter Apps.

vRealize Lifecycle Manager

Installation, Konfiguration, Upgrade von vRealize produkten.

vRealize Operations:

Automatisiertes IT Operation Management. Gibt  dem Op Team guten Einblick in Performance und Auslastung der Umgebung.

vSphere

Verwaltung und Bereitstellung von VMs via vCenter oder ESXi

vRealize Automation

Self Service Policy basierte Bereitstellungskomponente

Dienstverwaltung: Portfolio und Service Management

Physischer Layer: Hardware (Compute, Storage, Network)

Virtualisierter Layer: Hypervisor, Ressource Pools, Verwaltung (für Provider)

Cloud Verwaltungslayer: Dienstkatalog, Self Service Portal, Orchestrierung (für Kunde)

Daneben gibt es noch die 2 Blöcke:

Kontinuität: Für Redundanz, Backup & Restore
Sicherheit: Kontrolle, Risiko,

Business Continuity Management bezieht sich auf die gesamte Organisation. Es definiert Policies und Prozesse zum vorgehen bei Krisen.

• Definition der kritischen Geschäftsfunktionen und Prozesse (Assets). Funktionen die bei einer Krise aufrechterhalten werden müssen oder schnell wiederhergestellt werden müssen
• BCM Besteht aus Planung (Initial), Umsetzung (Währen Krise) und Controlling (Kontinuierliche Anpassung auf neue Gefahren, Review nach Krise
• Deckt den gesamten Betrieb ab

1. Umfang BCM definieren
2. Verankerung des BCM im Unternehmen
3. Schaffung einer Governance Governance Struktur (kümmert sich um BCM und ist in Charge während Krise)
4. BCM Rollen und Verantwortlichkeiten definieren
5. Definition von Krisenszenarien (mehrere Use Cases und Vorgehenspläne)
6. Identifikation der Geschäftskritischen Ressourcen und Prozesse (Asset Identification) - Business Impact Analyse
7. Business Continuity Strategie - Verhalten während Krise
8. Business Continuity Pläne - Wiederherstellungspläne für verschiedene Krisen
9. Business Continuity Reviews - Ablauf muss geübt werden!
10. Berichterstattung, Schulung, Training.

Ein weitreichendes Schadensereignis für die Unternehmung, welches mit den normalen Unternehmensstrukturen nicht  zu bewältigen ist (Krisenstab benötigt)

Krisen

• Datenverlust
• Grosser Systemausfall
• Stromausfall > 4 Tag

Störung

• Alles was "schnell" behoben ist

ITSCM - IT-Service Continuity Management ist ein Bestandteil vom BCM und unterstütz dieses.

• Es beschäftigt sich mit Krisen im IT Bereich. Dabei gilt es
• Risiken zu definieren
• Vorsorge (Mitigation) Pläne zu erstellen
• Notfall (Krisen) Pläne zu erstellen

Ausserdem wird ein minimum ein Services definiert, welche auch im Krisenfall verfügbar sind.
Und es werden Pläne/Services erstellt, welche helfen die ausgefallenen Services innert einer vordefinierten Zeit wiederherzustellen.

Phase 1 - Initiierung

Definiert den Umfang des ITSCM anhand des BCM

Phase 2 - Anforderungen & Strategie

• Business Impact Analysis
  • Identifikation der geschäftskritischen prozesse und Zuordnung der entsprechenden Services
  • Beschreibung der Auswirkungen eines Ausfalls der Services
• Risk Assessment
  • Risiken definieren (Eintrittswkeit x Schadensausmass)
• IT-Service Continuity Strategie
  • Definiert die Recovery Optionen der einzelnen Services anhand ihrer Kritikalität
  • Sehr schnell: Zweites RZ auf Stand-By
  • Langsam: Restore von Tapes

Phase 3 - Implementierung

Geplante Massnahmen werden implementiert

• Mitigationen (Risikoverminderungen)
• Notfall Pläne etablieren
• Recovery Pläne

Phase 4 - Operativer Betrieb

Kontinuierliche Überprüfung, Testung und Verbesserung der Recovery Pläne

Implement: Durchführung von Ausbildungen

Plan: Regelmässige Reviews

Evaluation: Periodische Tests von Recovery Plänen

Maintenance: Neue Gegebenheiten/Services sollen auch ins ITSCM fliesen

Rolle: "IT Services Continuity Manager"

• Implementierung der ITSCM Prozesse
• Risk Mgmt
• Business Impact Analysises
• Continuity Strategy
• Review & Continous Improvement der Prozesse

KPIs

• Planmässigkeit der durchgeführten Tests (hat alles funktioniert?)
• Anzahl festgestellte Mängel während Tests

Einleitung: Allgemeine Informationen, Ziel des Dokuments

Sofortmassnahmen

Krisenmanagement

• Rollen
• Meldeweg
• Kristenstab etc

Wiederherstellung

Vorgehen zum Restore von Arbeitsplätzen, Infrastruktur, IT

Geschäftsfortführung

• Definition von Organisationseinheiten
• Plan um zurück zum Normalbetrieb zu kommen

Anhang

Wichtige Telefonnummern etc.

Eine technische  Grundlage, auf welcher wir unsere Services bauen.

• Normierte und Standardisierte Produkte
• Produktionsprozess im Zentrum
• Arbeitsteilung (Spezifizierung)
• Keine Generalisten mehr - mehr Spezialisten

In der IT sind damit ebenfalls standardisierte Prozesse und Software gemeint, sowie die spezialisierung auf gewissen Gebieten.
Ausserdem ist Automatisierung auch ein grosser Teil.

• Hardware, OS
• Schnitstellen: Netzwerk, Management, Security
• Vorgaben: Standardisierte Installations&Betriebsprozesse
• Werkzeuge und Prozesse

Oder anders gesagt:

• Die 4 Layers einer Standardplattform
• Und Werkzeuge + Prozesse

Es geht darum einen Standardisierten Katalog für folgende Elemente zu erstellen (nur wenige Produkte anbieten, z.B. nur 2 Betriebssysteme..)

Layer 0: Physische Hardware, Hypervisor
Layer 1: Betriebssysteme und Ecosysteme
Layer 2: Optionale Komponenten
Layer 3: Applikation/Nutzlast

• Die Infrastrukturplattform soll als eigenes, eigenständige Element gesehen und betrieben werden (Komponenten).
• Es soll nicht für jede Applikation eine eigene, individuelle Infrastuktur  bereitgestellt werden.
• Mit einer Infrastukturplattform soll eine ganze Klasse von Applikationen bedient werden können.

• Es gibt einen Service Verantwortlichen: "Plattform Owner"
• Es gibt einen Lebens/Release Zyklus
• Plattformen werden kontinuierlich verbessert
• Müssen auf die Bedürfnisse der Nutzer ausgelegt werden
• Die Verwendung muss in der Organisation durchgesetzt werden (keine Eigenen Infrastrukturen pro Abteilung)

• Ein Plattform Release kann natürlich auch dieselben Komponenten wie ein Vorgänger Release haben.
• Ausserdem können Komponenten Versionen auch übersprungen werden ( V1, V3)

Gewisse Applikationen sind nur auf einer (der ältesten) Platform unterstützt - Wird diese aufgelöst, gäbe es die Applikation nicht mehr (schlecht).

Eine Plattform hat grundsätzlich eine vordefinierte Lebensdauer welche eingehalten werden muss.
Zwischen Plattform Release 1,2,x gibt es immer überschneidungen, meistens sind mehrere Plattformen am laufen.

• Phase Engineering: Die Plattform wird gebaut
• Phase Nutzung: Die Plattform wird aktiv genutzt, neue Applikationen sollen für diese Plattform entwickelt werden.
• Phase Phase Out: Applikationen müssen Ihre Migration vorbereiten - optimalerweise auf die aktuellste, sprich übernächste Plattform.

Es sollen maximal x Releases parallel Betrieben werden. Dafür ist ein Release Management mit entsprechenden Phasen nötig.

• Langfristige Planung -  Abstimmung Zwischen Plattformen und Applikationan (Hauptaufgabe)
• Maximale Isolierung zwischen Infrastruktur und Applikation. Migrationen auf neue Plattformen so einfach wie möglich machen!
• Temporäre Lösungen: Verlängerung einer Plattform Lebenszeit