http://www.opitz-consulting.com/go/3-4-11
Viele Betriebe haben in den letzten Jahren ihren Anwendungsbetrieb an ITIL ausgerichtet. Jetzt kommt mit DevOps eine neue Philosophie daher, die vielfach aus der Entwicklung getrieben wird. Das Misstrauen auf beiden Seiten ist groß. Unsere Application-Management-Experten Richard Attermeyer und Ines Möckel zeigten in einem Vortrag bei der OOP 2015, dass ITIL und DevOps eine gute Kombination sein können, von der alle Projektbeteiligte profitieren.
DevOps findet schnell Anklang in SMBs. Organisationen, die bisher auch eine nicht sehr formalisierte Trennung zwischen Entwicklung und Betrieb hatten und häufig auch noch nicht über formalisierte Prozesse verfügen. Viele andere Betriebe haben dann in den letzten Jahren angefangen ITIL / ITSM einzuführen, eine Initiative, die eher aus dem Betrieb getrieben wurde und auf Entwicklungsbereiche häufig als Behinderung betrachtet werden.
DevOps auf der anderen Seite ist eine Philosophie, die häufig aus den Entwicklungsabteilungen getrieben wird und auf Skepsis in den Betriebsabteilungen trifft (die wollen uns überflüssig machen, funktioniert nicht mit SOX). Häufig liegt das an falsch verstandenen Ideen der beiden Methoden / Philosophien. Im Vortrag zeigen wir am Beispiel der Einführung von ITIL für Managed Services, wie DevOps Prinzipien bei der Umsetzung von ITIL unterstützen können.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
16. Knowledge Management
Service Asset and Configuration Management
Change Management und Evaluation
Release und Deployment Management
Service Validation and Test Management
Service Transition
24. Digitalisierung und Cyber-Physical Systems
Schnell neue Geschäftsideen ausprobieren
Schritt halten mit Modeerscheinungen,
Marktveränderungen und Gelegenheiten
DevOps Treiber: Business
28. Zusammenarbeit von Entwicklung und Betrieb
Personen vor Werkzeugen und Prozesse
Übernahme von agilen und Lean Praktiken
DevOps: Kulturwandel
29. Zusammenarbeit von Entwicklung und Betrieb
Personen vor Werkzeugen und Prozesse
Übernahme von agilen und Lean Praktiken
System-orientierte Sichtweise
DevOps: Kulturwandel
30. Zusammenarbeit von Entwicklung und Betrieb
Personen vor Werkzeugen und Prozesse
Übernahme von agilen und Lean Praktiken
System-orientierte Sichtweise
Fokus auf schnelle IT Service Erbringung
DevOps: Kulturwandel
31. DevOps schließt die Lücke
Business
Anforderung
Wasserfall und isolierte agile
Projekte und Praktiken können
Lücke nicht überwinden
12+ Monate
6-11
Monate
3-5
Monate
1-2
Monate
1-3
Wochen
Tage
DevOps Praktiken für
schnelle Lieferung
mit geringem Risiko
für Misserfolge
notwendig
Golet de l'Agneau, Pascal Blachier
Delivery Cycle Time
32. Fokus auf das ganze System definiert die Ziele
DevOps Prinzipien
33. Fokus auf das ganze System definiert die Ziele
Zusammenarbeit
DevOps Prinzipien
34. Fokus auf das ganze System definiert die Ziele
Zusammenarbeit
Automatisiere was sinnvoll ist
DevOps Prinzipien
35. Fokus auf das ganze System definiert die Ziele
Zusammenarbeit
Automatisiere was sinnvoll ist
Measure / Monitor: Transparenz für Kunden und
Kollegen
DevOps Prinzipien
36. Fokus auf das ganze System definiert die Ziele
Zusammenarbeit
Automatisiere was sinnvoll ist
Measure / Monitor: Transparenz für Kunden und
Kollegen
Wenn etwas wehtut, mache es öfter
DevOps Prinzipien
37. Entwicklungsteam mit Ops Beteiligung
Ops Team mit Entwicklerbeteiligung
DevOps Prinzipien: Zusammenarbeit
38. Entwicklungsteam mit Ops Beteiligung
Ops Team mit Entwicklerbeteiligung
„You build it, you run it“
DevOps Prinzipien: Zusammenarbeit
46. Knowledge Management
Release & Deployment Management
Incident Management
Service Asset & Configuration Management
Continual Service Improvement
47. „Wissend ist, wer weiß, wo er findet, was er noch nicht
weiß.“
Georg Simmel (1858 – 1918) dt. Soziologe und Philosoph
Knowledge Management
48. Bereitstellen von Wissen und Informationen
innerhalb der Organisation
Knowledge Management
- Definition
49. Dokumentation ist wichtig: Face-2-Face
effektiver
Mitarbeit von MSA-Kollegen in Projektphase
Aber: Betriebsmitarbeiter nicht im Team?
Knowledge Management: DevOps
50. Häufig MSA und MSI getrennt
Unterschiedliche Interessen durch
unterschiedliche Firmen
Kulturwandel und / oder Abrechnungsmodell
ändern
Knowledge Management
60. Reproduzierbares, automatisches Release
Application Container
Alles unter Versionskontrolle
(Infrastruktur, Code, Datenbankschemata)
Geringeres Risiko durch kleine Änderungen
Release & Deployment Management
- DevOps Praktiken
61. Fehlerhaftes Deployment Änderung (schnell)
Kleine Änderung: Option Roll-Forward statt
Backward
Release & Deployment Mgmt:
Geringeres Risiko durch kleine Änderungen
62. Release & Deployment Mgmt:
- Status bei OC
Pratiken Status Beurteilung
CI Alle Projekte
CD / Build Pipeline MSA nicht komplett
automatisiert
Häufig Übergabepunkte
an andere Dienstleister
Versionskontrolle Code und
Datenbankschemata: ja
Infrastruktur: vereinzelt
Weiterer Roll-Out für
Infrastruktur geplant
Container Einzelne Projekte im
Consultinggeschäft
MSA / MSI: weiterer
Ausbau geplant.
Viele Legacy Projekte
63. steuert den Lebenszyklus aller Changes
nutzbringende Changes zu ermöglichen
negative Auswirkungen vermeiden
Change Management
- Definition
67. Häufige Releases, kleine Änderungen, geringes
Risiko
Standard Changes vs Normal Changes
Change Management
- DevOps Perspektive
68. Häufige Releases, kleine Änderungen, geringes
Risiko
Standard Changes vs Normal Changes
Mehr Standard Changes. Vertrau der Pipeline
Change Management
- DevOps Perspektive
69. verwaltet alle Incidents über ihren gesamten
Lebenszyklus
Schnelle Wiederherstellung des Services
Incident Management
- Definition
70. DevOps fokussiert auf MTTR
Alle relevanten Informationen für alle verfügbar
Sammle Daten über Incidents und verbessere
den Prozess
Incident Management
- DevOps Perspektive
71. Aus Erfolgen und Misserfolgen lernen
Kontinuierliche Verbesserung der IT-Prozesse
Continual Service Improvement (CSI)
- Definition
75. Business relevante KPIs definieren
Betriebsnahes Monitoring reicht nicht
CSI: Service Measurement
- richtige Informationen
76. Business relevante KPIs definieren
Betriebsnahes Monitoring reicht nicht
Log Management wichtig
CSI: Service Measurement
- richtige Informationen
77. Business relevante KPIs definieren
Betriebsnahes Monitoring reicht nicht
Log Management wichtig
Automatisierte Aggregation, Visualisierung und
Auswertung (SLA Reporting)
CSI: Service Measurement
- richtige Informationen
78. Business relevante KPIs definieren
Betriebsnahes Monitoring reicht nicht
Log Management wichtig
Automatisierte Aggregation, Visualisierung und
Auswertung (SLA Reporting)
Schnelle Reaktion auf Metrikänderungen –
Feedback für Entwickler und Administratoren
CSI: Service Measurement
- richtige Informationen
79. CSI: Service Measurement
- Lösungsansätze und Werkzeuge
Bereich Werkzeuge OC Einsatz / Beurteilung
Logs Logstash/Kibana/Elasticsear
ch (ELK), Splunk, Greylog2
Einsatz in einigen
Consultingprojekten
MSA: häufig
unterschiedliche
Verantwortlichkeiten
Notwendig bei mehr
Containern / Cloud
Events check_mk, Nagios, Icinga Ja
APM Dynatrace, Flopsar,
AppDynamics, NewRelic
Consulting: Ja
MSA: Ja, wenn gewünscht
Wertbereitstellung JMX, Jolokia, Metrics Ja
Visualisierung Graphite nein
80. Informationen zu Configuration Items
…und ihrer Beziehungen untereinander
Service Asset und Configuration Mgmt
- Definition
81. Änderungen an Umgebungen nur automatisch
Idealfall: Immutable Infrastructure
Service Asset und Configuration Mgmt
- Devops: Infrastructure-as-Code
82. Service Asset und Configuration Mgmt
- DevOps: Infrastructure-as-Code
Transparenz
Systemdefinition an zentraler Stelle
Systemdefinition ist klar strukturiert und verständlich
Reporting über Änderungen
Automatisierung
Systemaufbau „auf Knopfdruck“
Nicht nur initial, sondern über den ganzen Lifecycle
Reproduzierbarkeit
Systemaufbau ist durch Definitionsdatei zuverlässig reproduzierbar
Konfigurationsänderungen sind sichtbar und bei Bedarf revidierbar
Änderungen sind versionierbar
Tools: Ansible, Puppet, Chef, SaltStack
83. MSI: ja, aber noch nicht durchgehend
MSA: häufig anderer Dienstleister
Service Asset und Config Mgmt
- Status @OC
86. • Vereinfachtes Change-Management (Mehr
Standardchanges)
• Vereinfachtes Release- und Deployment-Management
Automatische, häufige und
reproduzierbare Releases
• Continuous Service Improvement
• Problem Management
Retrospektiven und mehr
Transparenz über die Services
• Knowledge Management
• Incident Management
Zusammenarbeit von
Entwicklung und Betrieb
• Beurteilung von Changes (Change-Management)
MTTR wichtiger als MTBF
• Request Fulfillment
Self Service Operations
• Service Validation und Test ManagementMehr automatisierte Tests
(System, Kapazitäts und
Security Tests) als Teil von CD
87. DevOps Praktiken passen gut mit ITIL
Prozessen zusammen
Für Softwarewartung, -pflege und –betrieb
müssen ITIL Prozesse z.T. angepasst werden