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

1. DevOps und ITIL
Waffenbrüder oder Feinde?
Richard Attermeyer
Ines Möckel

2. © OPITZ CONSULTING GmbH 2012 Seite 2<Präsentationstitel – bitte im Folienmaster ändern>
Mission
Wir entwickeln gemeinsam mit allen
Branchen Lösungen, die dazu führen, dass
sich diese Organisationen besser entwickeln
als ihr Wettbewerb.
Unsere Dienstleistung erfolgt
partnerschaftlich und ist auf eine langjährige
Zusammenarbeit angelegt.
Leistungsangebot
Application Lifecycle Management
IT-Beratung
Business-Lösungen
Managed Services
Training und Coaching
IT-Trends
Märkte
Branchenübergreifend
Über 600 Kunden
29%
Industrie / Versorger /
Telekommunikation
29%
Handel / Logistik /
Dienstleistungen
42%
Öffentliche Auftraggeber / Banken und
Versicherungen / Vereine und Verbände
Eckdaten
Gründung 1990
400 Mitarbeiter
9 Standorte

3. © OPITZ CONSULTING GmbH 2012 Seite 3<Präsentationstitel – bitte im Folienmaster ändern>
Agenda
1. Motivation
2. MSA
3. DevOps
4. ITIL + DevOps
5. Fazit

4. Motivation

5. Entwicklung
Agilität
Software
Craftsmanship
Partner-
schaftlich

6. Projektentwicklung…
… und dann?

7. Vertretung
neue Projekte…
… keine Ressourcen
SLAs

8. MSA

9. Wartung von Applikation
Wartungsteams
SLA
Managed Service Applications

10. Wartung
korrektive präventive
adaptive perfektionierend
Wartung

11. Ein Kollege  mehrer Kunden / Projekte
Viele Kunden / Projekte
Standardisierung  Synergieen
Warum ITIL

12. Entwicklung: Agil
Betrieb / Weiterentwicklung: ?
Herausforderungen

13. ITIL: Unsere Prozesse

14. Incident Management
Problem Management
Request Fulfilment
Service Operation

15. Service Transition

16. Knowledge Management
Service Asset and Configuration Management
Change Management und Evaluation
Release und Deployment Management
Service Validation and Test Management
Service Transition

17. Continual Service Improvement

18.  OC|MSA® und ITIL

19. DevOps

20. Kundige und anspruchsvolle Kunden
DevOps Treiber: Kundensicht

21. Kundige und anspruchsvolle Kunden
Höhere Erwartungen an Software
DevOps Treiber: Kundensicht

22. Digitalisierung und Cyber-Physical Systems
DevOps Treiber: Business

23. Digitalisierung und Cyber-Physical Systems
Schnell neue Geschäftsideen ausprobieren
DevOps Treiber: Business

24. Digitalisierung und Cyber-Physical Systems
Schnell neue Geschäftsideen ausprobieren
Schritt halten mit Modeerscheinungen,
Marktveränderungen und Gelegenheiten
DevOps Treiber: Business

25. Systems
of Innovation
Systems
of Differentiation
Systems
of Record
DevOps
Traditional
Source: Gartner (September 2014)
Change
+
-
Governance
+
-

26. Zusammenarbeit von Entwicklung und Betrieb
DevOps: Kulturwandel

27. Zusammenarbeit von Entwicklung und Betrieb
Personen vor Werkzeugen und Prozesse
DevOps: Kulturwandel

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

39. Continuous Delivery Pipeline
DevOps Prinzipien: Automatisiere was sinnvoll
ist

40. Continuous Delivery Pipeline
Mehr Tests (z.B. Kapazitäts-, Securitytests)
DevOps Prinzipien: Automatisiere was sinnvoll
ist

41. Continuous Delivery Pipeline
Mehr Tests (z.B. Kapazitäts-, Securitytests)
Installation / Bereitstellung QA Systeme
DevOps Prinzipien: Automatisiere was sinnvoll
ist

42. Continuous Delivery Pipeline
Mehr Tests (z.B. Kapazitäts-, Securitytests)
Installation / Bereitstellung QA Systeme
Self-Service Operations (c.f. rundeck)
DevOps Prinzipien: Automatisiere was sinnvoll
ist

43. Continuous Delivery Pipeline
Mehr Tests (z.B. Kapazitäts-, Securitytests)
Installation / Bereitstellung QA Systeme
Self-Service Operations (c.f. rundeck)
Produktionsdeployment
DevOps Prinzipien: Automatisiere was sinnvoll
ist

44. Von Continuous Delivery hin zu Continuous
Deployment
DevOps Prinzipien: Wenn etwas wehtut …

45. ITIL und DevOps

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

51. Wartung
Incident
Management
Problem
Management
Request
Fulfillment
Change
Management
Release &
Deployment
Management
Test
Management
Wartung

52. Plan und Kontrolle für Release-Rollout
Schützen der Integrität der Live-Umgebung
Release & Deployment Management
- Definition

53. Reproduzierbares, automatisches Release
Release & Deployment Management
- DevOps Praktiken

54. Release & Deployment Mgmt:
- Reproduzierbares, automatisches Release

55. Beispiel Release / Kanban

56. Reproduzierbares, automatisches Release
Application Container
Release & Deployment Management
- DevOps Praktiken

57. Release & Deployment Mgmt:
- Application Container
Build Ship Run

58. Reproduzierbares, automatisches Release
Application Container
Alles unter Versionskontrolle
(Infrastruktur, Code, Datenbankschemata)
Release & Deployment Management
- DevOps Praktiken

59. Release & Deployment Mgmt
- Alles unter Versionskontrolle
Versions-
kontrolle
Infrastruktur
(Ansible, Chef, Puppet)
Source Code
Datenbank Schemata
(Orcas, Liquibase,
Flyway)
Reprodu-
zierbare
Builds
Source
• git
• svn
Binary
• Artifactory
• Nexus
• RPM / Deb
Repository

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

64. Häufige Releases, kleine Änderungen, geringes
Risiko
Change Management
- DevOps Perspektive

65. Change Management:
Geringeres Risiko durch kleine Änderungen
Umgesetzte
Features
Zeit (Monate)
3 6

66. Change Management:
Geringeres Risiko durch kleine Änderungen
Umgesetzte
Features
Zeit (Monate)
3 6

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

72. Retrospektiven
Reicht aber nicht
Continual Service Improvement (CSI)

73. CSI: Service Measurement
- Information Radiation
Wie bekommen wir die richtigen Informationen
aus den relevanten Systemen
in die richtigen Köpfe

74. Business relevante KPIs definieren
CSI: Service Measurement
- richtige Informationen

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

84. Fazit

85. DevOps Praktiken passen gut mit ITIL
Prozessen zusammen

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

88. Bildquelle / URL
Fragen?

89. Ansprechpartner bei OPITZ CONSULTING
Richard Attermeyer, Senior Solution Architect
OPITZ CONSULTING Deutschland GmbH
richard.attermeyer@opitz-consulting.de
Telefon +49 2261 60 01-1713
Mobil +49 173 727 9004
Ines Möckel, Project Manager
OPITZ CONSULTING Deutschland GmbH
ines.moeckel@opitz-consulting.com
Telefon +49 2261 60 01-1472
Mobil +49 173 727 6099
youtube.com/opitzconsulting
@OC_WIRE
slideshare.net/opitzconsulting
xing.com/net/opitzconsulting

90. „Mind the Gap, Royal Gorge Bridge”, by SidewaysSarah
licensed under CC BY 2.0