DevOps und ITIL - ein Erfahrungsbericht

1.904 Aufrufe

Veröffentlicht am

http://www.opitz-consulting.com/go/3-4-11

Organisationen entwickeln sich weiter. Einige haben einen stark formalisierten Aufbau und wünschen sich mehr Agilität; andere wiederum wollen Standardisierung.Gerade im Managed Services Bereich ist ITIL weit verbreitet oder soll eingeführt werden. Gleichzeitig gibt es Bestrebungen agile und DevOps Prinzipien in Betriebsorganisationen zu etablieren.

Unser Senior Solution Architect Richard Attermeyer zeigte in seinem Vortrag bei der Jax 2015, wie OPITZ CONSULTING beide Ansätze in einem Managed Services Bereich miteinander verbindet und welche Erfahrungen unsere Experten sammeln konnten.

--
Ü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
0 Kommentare
4 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.904
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
42
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
4
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

DevOps und ITIL - ein Erfahrungsbericht

  1. 1. DevOps und ITIL Ein Erfahrungsbericht Richard Attermeyer
  2. 2. Richard Attermeyer  Solution Architekt und Entwickler Schwerpunkte  Softwarearchitektur  Java Technologien  Continuous Delivery und DevOps Richard.Attermeyer@opitz-consulting.com @rattermeyer github.com/rattermeyer xing.to/rat
  3. 3. © OPITZ CONSULTING GmbH 2015 Seite 4DevOps und ITIL: Ein Erfahrungsbericht Agenda 1. Motivation / Historie 2. Managed Services und MSA 3. DevOps 4. ITIL + DevOps 5. Fazit
  4. 4. Motivation
  5. 5. Entwicklung Agilität Software Craftsmanship Partner- schaftlich
  6. 6. … und dann?
  7. 7. Vertretung neue Projekte… … keine Ressourcen SLAs
  8. 8. Managed Services und MSA
  9. 9. Managed Services MSI Betriebssystem Datenbanken / Middleware MSA-Team Applikationen
  10. 10. Managed Services MSI Betriebssystem Datenbanken / Middleware MSA-Team Applikationen Änderungen Korrekturen Weiter- entwicklung Optimierung MSA Fachkonzeptverändert Fachkonzeptunverändert Nachbesserungen Verbesserungen Wartungsteams SLAs
  11. 11. Ein Kollege: mehrere Kunden / Projekte Viele Kunden / Projekte Standardisierung: Synergien Warum ITIL
  12. 12. DevOps
  13. 13. DevOps Prinzipien Culture Lean Automation Measurement Sharing
  14. 14. Zusammenarbeit Fokus auf das ganze System definiert die Ziele Automatisiere was sinnvoll ist Measure / Monitor: Transparenz für Kunden und Kollegen Wenn etwas wehtut, mache es öfter DevOps Prinzipien
  15. 15. ITIL: Unsere Prozesse
  16. 16. Unsere Prozesse  OC|MSA® und ITIL
  17. 17. OC|MSA® und ITIL Unsere Prozesse Incident Management Problem Management Request Fulfillment Change Management Release & Deployment Management Test Management Wartung
  18. 18. ITIL und DevOps
  19. 19. Knowledge Management Release & Deployment Management Change Management Incident Management Continual Service Improvement Service Asset und Configuration Management ITIL Prozesse
  20. 20. Bereitstellen von Wissen und Informationen innerhalb der Organisation Knowledge Management - Definition
  21. 21. Knowledge Management Bereitstellen von Wissen und Informationen innerhalb der Organisation ITIL DevOps  Face-2-Face  Mitarbeit von MSA- Kollegen im Projekt  Wiki  Ermögliche Kooperation  Erleichtere Zugang zu Dokumenten  Ermutige Änderung von Dokumenten
  22. 22. Knowledge Management: Probleme MS-Team Betriebssystem Datenbanken / Middleware Applikationen Wunsch Realität 3rd Party Betriebssystem Datenbanken / Middleware MSA-Team Applikationen
  23. 23. Knowledge Management: Fragen / Ideen  Immer mehr Firmen setzen auf SaaS  Warum nicht bei eigenen Applikationen?  SaaS: Produktteam in der Firma  SaaS: Produktteam als Managed Service  Abrechnungsmodell verhindert Kooperation  Verhinderung von Kollaboration: Jeder Anruf kostet  Unterschiedliche Kennzahlen: Stabilität vs. Anzahl Features  Besser: Orientierung am gesamten Business-Value  Enabler: Private Enterprise Cloud ?  Software-defined Infrastructure  Hosting Provider: Run the Cloud, Infrastructure Services  Application Provider: My Code, my libraries, my package manager, my OS
  24. 24. Wartung Incident Management Problem Management Request Fulfillment Change Management Release & Deployment Management Test Management ITIL: Wartung
  25. 25. Knowledge Management Release & Deployment Management Change Management Incident Management Continual Service Improvement Service Asset und Configuration Management ITIL Prozesse
  26. 26. Plan und Kontrolle für Release-Rollout Schützen der Integrität der Live-Umgebung Release & Deployment Management - Definition (ITIL)
  27. 27. 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
  28. 28. Release & Deployment Mgmt: - Reproduzierbares, automatisches Release
  29. 29. Release & Deployment Mgmt: - Application Container Build Ship Run
  30. 30. Roll-Forward statt Backward Wer tested Roll-Backward vor Release? Release & Deployment Mgmt: Roll-Forward statt Roll-Backward
  31. 31. Release & Deployment Mgmt: - Status bei OC Pratiken Status Beurteilung CI Alle Projekte CD / Build Pipeline MSA nicht komplett automatisiert Einige Entwicklungsprojekte 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 Gute Unterstützung durch CD Praktiken
  32. 32. Knowledge Management Release & Deployment Management Change Management Incident Management Continual Service Improvement Service Asset und Configuration Management ITIL Prozesse
  33. 33. steuert den Lebenszyklus aller Changes nutzbringende Changes zu ermöglichen negative Auswirkungen vermeiden Change Management - Definition
  34. 34. Change Management: Geringeres Risiko durch kleine Änderungen Umgesetzte Features Zeit (Monate) 3 6
  35. 35. Change Management: Geringeres Risiko durch kleine Änderungen Umgesetzte Features Zeit (Monate) 3 6 häufige Releases, kleine Änderungen, geringes Risiko
  36. 36. Change Management Build 1 2 3 Iterationen Entwicklung Integration & Testing QA Release & Operation Betrieb
  37. 37. Change Management - Continuous Delivery Kontinuierlicher Fluss von Features in Richtung Produktion Wenn etwas weh tut, mache es öfter!
  38. 38. Standard Changes Normal Changes Change Management
  39. 39. Kostet Überzeugungsarbeit Arbeit an Akzeptanz und Definition Changeklassen Problem (MSA): Häufig Übergabepunkte Erfahrung
  40. 40. Knowledge Management Release & Deployment Management Change Management Incident Management Continual Service Improvement Service Asset und Configuration Management ITIL Prozesse
  41. 41. verwaltet alle Incidents über ihren gesamten Lebenszyklus Schnelle Wiederherstellung des Services Incident Management - Definition
  42. 42. DevOps fokussiert auf MTTR Alle relevanten Informationen für alle verfügbar Sammle Daten über Incidents und verbessere den Prozess Incident Management - DevOps Perspektive
  43. 43. Bewusstsein für Qualitätsattribute schaffen Investitionsbereitschaft erweitertes Monitoringtools Teilweise internes IT Thema Problem (MSA): Unterschiedliche Dienstleister Erfahrung
  44. 44. Knowledge Management Release & Deployment Management Incident Management Change Management Continual Service Improvement Service Asset und Configuration Management ITIL Prozesse
  45. 45. Aus Erfolgen und Misserfolgen lernen Kontinuierliche Verbesserung der IT-Prozesse Continual Service Improvement (CSI) - Definition
  46. 46. Retrospektiven Reicht aber nicht Continual Service Improvement (CSI)
  47. 47. CSI: Service Measurement - Information Radiation Wie bekommen wir die richtigen Informationen aus den relevanten Systemen in die richtigen Köpfe
  48. 48. Business relevante KPIs definieren Betriebsnahes Monitoring reicht nicht Log Management / APM wichtig Automatisierte Aggregation, Visualisierung und Auswertung (SLA Reporting) Schnelle Reaktion auf Metrikänderungen – Feedback für Entwickler und Administratoren CSI: Service Measurement - richtige Informationen
  49. 49. CSI: Service Measurement - Lösungsansätze und Werkzeuge Bereich Werkzeuge OC Einsatz / Beurteilung Logs Logstash/Kibana/ Elasticsearch (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, wo möglich Visualisierung Graphite nein Gute Unterstützung durch Werkzeuge Bewusstsein schaffen schwierig
  50. 50. Knowledge Management Release & Deployment Management Incident Management Change Management Continual Service Improvement Service Asset und Configuration Management ITIL Prozesse
  51. 51. Informationen zu Configuration Items …und ihrer Beziehungen untereinander Service Asset und Configuration Mgmt - Definition
  52. 52. Änderungen an Umgebungen nur automatisch Idealfall: Immutable Infrastructure Service Asset und Configuration Mgmt - Devops: Infrastructure-as-Code
  53. 53. 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
  54. 54. MSI: ja, aber noch nicht durchgehend MSA: teilweise für Entwicklungs- und Testsysteme MSA Problem: häufig anderer Dienstleister Service Asset und Config Mgmt - Erfahrung @OC
  55. 55. Fazit
  56. 56. DevOps Praktiken passen gut mit ITIL Prozessen zusammen Für Softwarewartung, -pflege und –betrieb müssen ITIL Prozesse z.T. angepasst werden DevOps orientierter Ansatz fördert Akzeptanz bei Entwicklern Wir müssen reden Organisatorische Schranken: größtes Hindernis
  57. 57. Bildquelle / URL Fragen?
  58. 58. 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 youtube.com/opitzconsulting @OC_WIRE slideshare.net/opitzconsulting xing.com/net/opitzconsulting

×