DevOps und ITIL: Waffenbrüder oder Feinde?

1.664 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
1 Kommentar
1 Gefällt mir
Statistik
Notizen
Keine Downloads
Aufrufe
Aufrufe insgesamt
1.664
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
18
Aktionen
Geteilt
0
Downloads
0
Kommentare
1
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

DevOps und ITIL: Waffenbrüder oder Feinde?

  1. 1. DevOps und ITIL Waffenbrüder oder Feinde? Richard Attermeyer Ines Möckel
  2. 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. 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. 4. Motivation
  5. 5. Entwicklung Agilität Software Craftsmanship Partner- schaftlich
  6. 6. Projektentwicklung… … und dann?
  7. 7. Vertretung neue Projekte… … keine Ressourcen SLAs
  8. 8. MSA
  9. 9. Wartung von Applikation Wartungsteams SLA Managed Service Applications
  10. 10. Wartung korrektive präventive adaptive perfektionierend Wartung
  11. 11. Ein Kollege  mehrer Kunden / Projekte Viele Kunden / Projekte Standardisierung  Synergieen Warum ITIL
  12. 12. Entwicklung: Agil Betrieb / Weiterentwicklung: ? Herausforderungen
  13. 13. ITIL: Unsere Prozesse
  14. 14. Incident Management Problem Management Request Fulfilment Service Operation
  15. 15. Service Transition
  16. 16. Knowledge Management Service Asset and Configuration Management Change Management und Evaluation Release und Deployment Management Service Validation and Test Management Service Transition
  17. 17. Continual Service Improvement
  18. 18.  OC|MSA® und ITIL
  19. 19. DevOps
  20. 20. Kundige und anspruchsvolle Kunden DevOps Treiber: Kundensicht
  21. 21. Kundige und anspruchsvolle Kunden Höhere Erwartungen an Software DevOps Treiber: Kundensicht
  22. 22. Digitalisierung und Cyber-Physical Systems DevOps Treiber: Business
  23. 23. Digitalisierung und Cyber-Physical Systems Schnell neue Geschäftsideen ausprobieren DevOps Treiber: Business
  24. 24. Digitalisierung und Cyber-Physical Systems Schnell neue Geschäftsideen ausprobieren Schritt halten mit Modeerscheinungen, Marktveränderungen und Gelegenheiten DevOps Treiber: Business
  25. 25. Systems of Innovation Systems of Differentiation Systems of Record DevOps Traditional Source: Gartner (September 2014) Change + - Governance + -
  26. 26. Zusammenarbeit von Entwicklung und Betrieb DevOps: Kulturwandel
  27. 27. Zusammenarbeit von Entwicklung und Betrieb Personen vor Werkzeugen und Prozesse DevOps: Kulturwandel
  28. 28. Zusammenarbeit von Entwicklung und Betrieb Personen vor Werkzeugen und Prozesse Übernahme von agilen und Lean Praktiken DevOps: Kulturwandel
  29. 29. Zusammenarbeit von Entwicklung und Betrieb Personen vor Werkzeugen und Prozesse Übernahme von agilen und Lean Praktiken System-orientierte Sichtweise DevOps: Kulturwandel
  30. 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. 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. 32. Fokus auf das ganze System definiert die Ziele DevOps Prinzipien
  33. 33. Fokus auf das ganze System definiert die Ziele Zusammenarbeit DevOps Prinzipien
  34. 34. Fokus auf das ganze System definiert die Ziele Zusammenarbeit Automatisiere was sinnvoll ist DevOps Prinzipien
  35. 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. 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. 37. Entwicklungsteam mit Ops Beteiligung Ops Team mit Entwicklerbeteiligung DevOps Prinzipien: Zusammenarbeit
  38. 38. Entwicklungsteam mit Ops Beteiligung Ops Team mit Entwicklerbeteiligung „You build it, you run it“ DevOps Prinzipien: Zusammenarbeit
  39. 39. Continuous Delivery Pipeline DevOps Prinzipien: Automatisiere was sinnvoll ist
  40. 40. Continuous Delivery Pipeline Mehr Tests (z.B. Kapazitäts-, Securitytests) DevOps Prinzipien: Automatisiere was sinnvoll ist
  41. 41. Continuous Delivery Pipeline Mehr Tests (z.B. Kapazitäts-, Securitytests) Installation / Bereitstellung QA Systeme DevOps Prinzipien: Automatisiere was sinnvoll ist
  42. 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. 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. 44. Von Continuous Delivery hin zu Continuous Deployment DevOps Prinzipien: Wenn etwas wehtut …
  45. 45. ITIL und DevOps
  46. 46. Knowledge Management Release & Deployment Management Incident Management Service Asset & Configuration Management Continual Service Improvement
  47. 47. „Wissend ist, wer weiß, wo er findet, was er noch nicht weiß.“ Georg Simmel (1858 – 1918) dt. Soziologe und Philosoph Knowledge Management
  48. 48. Bereitstellen von Wissen und Informationen innerhalb der Organisation Knowledge Management - Definition
  49. 49. Dokumentation ist wichtig: Face-2-Face effektiver Mitarbeit von MSA-Kollegen in Projektphase Aber: Betriebsmitarbeiter nicht im Team? Knowledge Management: DevOps
  50. 50. Häufig MSA und MSI getrennt Unterschiedliche Interessen durch unterschiedliche Firmen Kulturwandel und / oder Abrechnungsmodell ändern Knowledge Management
  51. 51. Wartung Incident Management Problem Management Request Fulfillment Change Management Release & Deployment Management Test Management Wartung
  52. 52. Plan und Kontrolle für Release-Rollout Schützen der Integrität der Live-Umgebung Release & Deployment Management - Definition
  53. 53. Reproduzierbares, automatisches Release Release & Deployment Management - DevOps Praktiken
  54. 54. Release & Deployment Mgmt: - Reproduzierbares, automatisches Release
  55. 55. Beispiel Release / Kanban
  56. 56. Reproduzierbares, automatisches Release Application Container Release & Deployment Management - DevOps Praktiken
  57. 57. Release & Deployment Mgmt: - Application Container Build Ship Run
  58. 58. Reproduzierbares, automatisches Release Application Container Alles unter Versionskontrolle (Infrastruktur, Code, Datenbankschemata) Release & Deployment Management - DevOps Praktiken
  59. 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. 60. Reproduzierbares, automatisches Release Application Container Alles unter Versionskontrolle (Infrastruktur, Code, Datenbankschemata) Geringeres Risiko durch kleine Änderungen Release & Deployment Management - DevOps Praktiken
  61. 61. Fehlerhaftes Deployment  Änderung (schnell) Kleine Änderung: Option Roll-Forward statt Backward Release & Deployment Mgmt: Geringeres Risiko durch kleine Änderungen
  62. 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. 63. steuert den Lebenszyklus aller Changes nutzbringende Changes zu ermöglichen negative Auswirkungen vermeiden Change Management - Definition
  64. 64. Häufige Releases, kleine Änderungen, geringes Risiko Change Management - DevOps Perspektive
  65. 65. Change Management: Geringeres Risiko durch kleine Änderungen Umgesetzte Features Zeit (Monate) 3 6
  66. 66. Change Management: Geringeres Risiko durch kleine Änderungen Umgesetzte Features Zeit (Monate) 3 6
  67. 67. Häufige Releases, kleine Änderungen, geringes Risiko Standard Changes vs Normal Changes Change Management - DevOps Perspektive
  68. 68. Häufige Releases, kleine Änderungen, geringes Risiko Standard Changes vs Normal Changes Mehr Standard Changes. Vertrau der Pipeline Change Management - DevOps Perspektive
  69. 69. verwaltet alle Incidents über ihren gesamten Lebenszyklus Schnelle Wiederherstellung des Services Incident Management - Definition
  70. 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. 71. Aus Erfolgen und Misserfolgen lernen Kontinuierliche Verbesserung der IT-Prozesse Continual Service Improvement (CSI) - Definition
  72. 72. Retrospektiven Reicht aber nicht Continual Service Improvement (CSI)
  73. 73. CSI: Service Measurement - Information Radiation Wie bekommen wir die richtigen Informationen aus den relevanten Systemen in die richtigen Köpfe
  74. 74. Business relevante KPIs definieren CSI: Service Measurement - richtige Informationen
  75. 75. Business relevante KPIs definieren Betriebsnahes Monitoring reicht nicht CSI: Service Measurement - richtige Informationen
  76. 76. Business relevante KPIs definieren Betriebsnahes Monitoring reicht nicht Log Management wichtig CSI: Service Measurement - richtige Informationen
  77. 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. 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. 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. 80. Informationen zu Configuration Items …und ihrer Beziehungen untereinander Service Asset und Configuration Mgmt - Definition
  81. 81. Änderungen an Umgebungen nur automatisch Idealfall: Immutable Infrastructure Service Asset und Configuration Mgmt - Devops: Infrastructure-as-Code
  82. 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. 83. MSI: ja, aber noch nicht durchgehend MSA: häufig anderer Dienstleister Service Asset und Config Mgmt - Status @OC
  84. 84. Fazit
  85. 85. DevOps Praktiken passen gut mit ITIL Prozessen zusammen
  86. 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. 87. DevOps Praktiken passen gut mit ITIL Prozessen zusammen Für Softwarewartung, -pflege und –betrieb müssen ITIL Prozesse z.T. angepasst werden
  88. 88. Bildquelle / URL Fragen?
  89. 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. 90. „Mind the Gap, Royal Gorge Bridge”, by SidewaysSarah licensed under CC BY 2.0

×