SlideShare ist ein Scribd-Unternehmen logo
OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
Probleme & Symptome
Die DevOps-Bewegung
Lösungsansätze
Kritik & Ausblick
Probleme & Symptome
Die DevOps-Bewegung
Lösungsansätze
Kritik & Ausblick
Des Pudels Kern
Des Pudels Kern
Silo-isierung
Silo-isierung
Release-Termine
Cloud-Computing
und Virtualisierung
Monitoring
Release-Prozess
Zusammenarbeit beim
Problem Management
Infrastruktur-Architektur
                                                 A"n"w"e"n"d"u"n"g"e"n"
    Infrastruktur5Komponenten"         1"   2"        3"       4"         5"   6"

                                  1"
                                  2"

                                                                                    vertikale
                                  3"
                                  4"
                                  5"
                                  6"
                                  7"
                                  8"
                                  9"
                                 10"

                                                                                    vs.
                                               A"n"w"e"n"d"u"n"g"e"n"
                                       1"   2"      3"       4"       5"       6"

                                  1"
                                                                                    horizontale
 Komponenten"
 Infrastruktur6"




                                  2"
                                  3"
                                  4"




                                                                                    Optimierung
Entwickler-Freiheiten
Truck-Faktor und
10ter-Stock-Test
Probleme & Symptome
Die DevOps-Bewegung
Lösungsansätze
Kritik & Ausblick
Ursprung/Historie
                                           2009: DevOps
Lean Thinking


     Continuous                                     Kanban
      Delivery


Dev2Ops                                     Agile Sysadmin

 Agile Service
 Management
                                             Agile Infrastructure

                 2005 (bei Thoughtworks)
                                                   Bild von Tobias Geberth unter CC-BY Lizenz
Konferenz DevOpsDays
                             2009:	

 Genf
                             2010:	

 Sydney
                             	

      Mountain View
                             	

      Hamburg
                             	

      Sao Paulo
                             	

      Göteburg
                             2011:	

 Boston
                             	

      Mountain View
                             	

      Melbourne
http://www.devopsdays.org/   	

      Bangalore
Community
Links:
 •   http://agilesysadmin.net/
 •   http://dev2ops.org/
 •   http://www.jedi.be/blog/
 •   http://www.agileweboperations.com/devops-series
 •   http://devopscafe.org/
 •   http://www.linkedin.com/groups?gid=2825397
 •   http://www.infrastructures.org/
Der Hofnarr

     http://twitter.com/#!/DEVOPS_BORAT
Hype(r)-Hype(r)!




Siehe auch Umfrage von HP und Replay Solutions (April 2011): http://replaysolutions.com/2011-DevOpsSurveyResults
Probleme & Symptome
Die DevOps-Bewegung
Lösungsansätze
Kritik & Ausblick
Vier Bereiche

• Culture
• Automation
• Measurement
• Sharing
Gegenseitige Ziele
kennen und achten
Beispiel:
    Release-Frequenz

                         Seltene&Releases&
Anwendungs4Funk'onen)




                         Häufige&Releases&
 Produk'v)verfügbare))




                                             Zeit)
Beispiel:
Geschäftsrelevantes Monitoring
Zusammenarbeit
und Kommunikation
Collective Ownership
                             Howto
                   (siehe auch “Natural Planning”)

     ✤   Zweck und Grundsätze festlegen
     ✤   Überragendes Ergebnis ausdenken
     ✤   Brainstorming des Lösungsweges
     ✤   Strukturieren und Organisieren
     ✤   Nächste Schritte bestimmen


http://www.agileweboperations.com/the-implications-of-infrastructure-as-code
Prozesse erkennen
und anpassen
Agile#Entwicklungsmethoden#         IT#Service#Management#

       So*ware.
      Entwicklung'      DevOps#         IT.Betrieb'




                        Business'
KnowHow verteilen
Infrastructure as Code


import "apache"                                template "/tmp/somefile" do
                                                 mode "0644"
node server1 {                                   source "somefile.erb"
    apache {                                     notifies :reload, "service[apache]"
        version => 1,                          end
        conf => "/nfs/configs/server1.conf",    
        user => "www-data",                    service "apache" do
        group => "www-data",                     supports :restart => true, :reload => true
    }                                            action :enable
}                                              end




              Puppet                               Opscode Chef
         http://puppetlabs.com/                   http://www.opscode.com/chef/
Release-Automatisierung
Weitere Werkzeuge und Tools

•   Defect Tracking (z.B. JIRA, Quality Center)
•   Automated Issue Resolution
    (z.B. BMC AppSight, ReplayDirector)
•   Requirements Management (z.B.VersionOne)
•   Source Code Control
    (z.B. Subversion, GiT, Team Foundation Server)
•   Help Desk / Ticket Tools (z.B. Remedy,
    CA Service Desk, HP Service Manager)
•   App Performance Monitoring
    (z.B. Introscope, NewRelic, DynaTrace)
Software-Lifecycle

Agile#Entwicklungsmethoden#         IT#Service#Management#

       So*ware.
      Entwicklung'      DevOps#         IT.Betrieb'




                        Business'
Software-Lifecycle
                             DevOps'


Agile#Entwicklungsmethoden#                  IT#Service#Management#




                        g$



                                         Be
                     run
     So*ware.




                                            re
                                                          IT.Betrieb'
       So*ware.




                                           itst
    Entwicklung'
                       ie
      Entwicklung'alis       DevOps#                 IT.Betrieb'




                                               ellu
               Re




                                                   ng
                                                      $
                           Business'
                        Idee$  Nutzung$

                             Business'
Das Versprechen ans Business

    ✓ Time-to-Market reduzieren
    ✓ Aufwand und Kosten für
      Produktivnahme, Betrieb und
      Betreuung reduzieren
    ✓ Proaktiv vor Betriebs-
      Störungen schützen und diese
      schnell beheben können
    ✓ Cloud-Computing effektiv
      nutzen können
Probleme & Symptome
Die DevOps-Bewegung
Lösungsansätze
Kritik & Ausblick
Alles nix neues...?
Reines Technik-Thema?

      DevOps
       Tool-Suite
               3.0
       NOW
       De vOps
       ce rtified
                        Pu
                     De re
                       vO
                    ins ps
                       ide
Ein weiteres Silo...?
Brücken bauen?

We don't need to build
more bridges [between disciplines],
we need to lower the sea of ignorance.

                           Dr. Ian Hacking
Danke
sagt:




           Udo Pracht
           Freier IT-Berater und Mediator
E-Mail: mail@udo-pracht.de
Web: http://www.pracht-mediation.de
        http://www.udo-pracht.de
Blog: http://menschenundit.wordpress.com

Weitere ähnliche Inhalte

Was ist angesagt?

Devops ohne root
Devops ohne rootDevops ohne root
Devops ohne root
cusy GmbH
 
VSHN DevOps Workshop at topsoft 2019
VSHN DevOps Workshop at topsoft 2019VSHN DevOps Workshop at topsoft 2019
VSHN DevOps Workshop at topsoft 2019
Markus Speth
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
Johann-Peter Hartmann
 
DevOps day - feature teams
DevOps day  - feature teamsDevOps day  - feature teams
DevOps day - feature teams
Walter Strametz
 
Migration von Applikationen in die Cloud
Migration von Applikationen in die CloudMigration von Applikationen in die Cloud
Migration von Applikationen in die Cloud
Aarno Aukia
 
Infrastruktur agil bauen - der DBA im SAFe-Umfeld
Infrastruktur agil bauen - der DBA im SAFe-UmfeldInfrastruktur agil bauen - der DBA im SAFe-Umfeld
Infrastruktur agil bauen - der DBA im SAFe-Umfeld
Daniel Steiger
 
Realisierung des Application Lifecycle Management im OWB
Realisierung des Application Lifecycle Management im OWBRealisierung des Application Lifecycle Management im OWB
Realisierung des Application Lifecycle Management im OWB
Minerva SoftCare GmbH
 
Large Scale Scrum (LeSS) als Organisations-Design-Framework
Large Scale Scrum (LeSS) als Organisations-Design-FrameworkLarge Scale Scrum (LeSS) als Organisations-Design-Framework
Large Scale Scrum (LeSS) als Organisations-Design-Framework
Josef Scherer
 
Continuous Everything
Continuous EverythingContinuous Everything
Continuous Everything
cusy GmbH
 
OOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger eweOOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger ewe
Markus Theilen
 
Objektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWBObjektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWB
Minerva SoftCare GmbH
 
Murcs
MurcsMurcs
Murcs
Ulf Mewe
 
TFS Release Management Deep Dive
TFS Release Management Deep DiveTFS Release Management Deep Dive
TFS Release Management Deep Dive
Nico Orschel
 
Continuous delivery ist keine Technologie
Continuous delivery ist keine TechnologieContinuous delivery ist keine Technologie
Continuous delivery ist keine Technologie
Jörg Müller
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
OPITZ CONSULTING Deutschland
 
Vortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development EnvironmentsVortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development Environments
Thorsten Kamann
 
Feature teams
Feature teamsFeature teams
Feature teams
Walter Strametz
 
agilean@home - Produktivität und Energieflow in Zeiten von Corona
agilean@home - Produktivität und Energieflow in Zeiten von Coronaagilean@home - Produktivität und Energieflow in Zeiten von Corona
agilean@home - Produktivität und Energieflow in Zeiten von Corona
Heinz Erretkamps
 
Lean development 04
Lean development 04Lean development 04
Lean development 04
SuperB2
 
Zeebe - Eine neue Workflow Engine für eine neue Zeit - BPM Con 2017
Zeebe - Eine neue Workflow Engine für eine  neue Zeit - BPM Con 2017Zeebe - Eine neue Workflow Engine für eine  neue Zeit - BPM Con 2017
Zeebe - Eine neue Workflow Engine für eine neue Zeit - BPM Con 2017
Zeebe
 

Was ist angesagt? (20)

Devops ohne root
Devops ohne rootDevops ohne root
Devops ohne root
 
VSHN DevOps Workshop at topsoft 2019
VSHN DevOps Workshop at topsoft 2019VSHN DevOps Workshop at topsoft 2019
VSHN DevOps Workshop at topsoft 2019
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
 
DevOps day - feature teams
DevOps day  - feature teamsDevOps day  - feature teams
DevOps day - feature teams
 
Migration von Applikationen in die Cloud
Migration von Applikationen in die CloudMigration von Applikationen in die Cloud
Migration von Applikationen in die Cloud
 
Infrastruktur agil bauen - der DBA im SAFe-Umfeld
Infrastruktur agil bauen - der DBA im SAFe-UmfeldInfrastruktur agil bauen - der DBA im SAFe-Umfeld
Infrastruktur agil bauen - der DBA im SAFe-Umfeld
 
Realisierung des Application Lifecycle Management im OWB
Realisierung des Application Lifecycle Management im OWBRealisierung des Application Lifecycle Management im OWB
Realisierung des Application Lifecycle Management im OWB
 
Large Scale Scrum (LeSS) als Organisations-Design-Framework
Large Scale Scrum (LeSS) als Organisations-Design-FrameworkLarge Scale Scrum (LeSS) als Organisations-Design-Framework
Large Scale Scrum (LeSS) als Organisations-Design-Framework
 
Continuous Everything
Continuous EverythingContinuous Everything
Continuous Everything
 
OOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger eweOOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger ewe
 
Objektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWBObjektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWB
 
Murcs
MurcsMurcs
Murcs
 
TFS Release Management Deep Dive
TFS Release Management Deep DiveTFS Release Management Deep Dive
TFS Release Management Deep Dive
 
Continuous delivery ist keine Technologie
Continuous delivery ist keine TechnologieContinuous delivery ist keine Technologie
Continuous delivery ist keine Technologie
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
 
Vortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development EnvironmentsVortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development Environments
 
Feature teams
Feature teamsFeature teams
Feature teams
 
agilean@home - Produktivität und Energieflow in Zeiten von Corona
agilean@home - Produktivität und Energieflow in Zeiten von Coronaagilean@home - Produktivität und Energieflow in Zeiten von Corona
agilean@home - Produktivität und Energieflow in Zeiten von Corona
 
Lean development 04
Lean development 04Lean development 04
Lean development 04
 
Zeebe - Eine neue Workflow Engine für eine neue Zeit - BPM Con 2017
Zeebe - Eine neue Workflow Engine für eine  neue Zeit - BPM Con 2017Zeebe - Eine neue Workflow Engine für eine  neue Zeit - BPM Con 2017
Zeebe - Eine neue Workflow Engine für eine neue Zeit - BPM Con 2017
 

Andere mochten auch

Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbH
Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbHDocker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbH
Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbH
agilemethoden
 
Using Rancher and Docker with RightScale at Industrie IT
Using Rancher and Docker with RightScale at Industrie IT Using Rancher and Docker with RightScale at Industrie IT
Using Rancher and Docker with RightScale at Industrie IT
RightScale
 
DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?
OPITZ CONSULTING Deutschland
 
Docker - Containervirtualisierung leichtgemacht
Docker - Containervirtualisierung leichtgemachtDocker - Containervirtualisierung leichtgemacht
Docker - Containervirtualisierung leichtgemacht
B1 Systems GmbH
 
Continuous Deployment: The Dirty Details
Continuous Deployment: The Dirty DetailsContinuous Deployment: The Dirty Details
Continuous Deployment: The Dirty Details
Mike Brittain
 
Continuous integration eine Einführung für Unkundige
Continuous integration   eine Einführung für UnkundigeContinuous integration   eine Einführung für Unkundige
Continuous integration eine Einführung für Unkundige
abuwipp
 
Preparing your dockerised application for production deployment
Preparing your dockerised application for production deploymentPreparing your dockerised application for production deployment
Preparing your dockerised application for production deployment
Dave Ward
 
Telekom Techtalk - Practical DevOps
Telekom Techtalk - Practical DevOpsTelekom Techtalk - Practical DevOps
Telekom Techtalk - Practical DevOps
Schlomo Schapiro
 
Docker Einführung @GPN15
Docker Einführung @GPN15Docker Einführung @GPN15
Docker Einführung @GPN15
m1no
 
Einblick in die Intranet Transformation bei Swisscom AG
Einblick in die Intranet Transformation bei Swisscom AGEinblick in die Intranet Transformation bei Swisscom AG
Einblick in die Intranet Transformation bei Swisscom AG
Thomas Maeder
 
Container Tag – Nie mehr warten auf die IT! - Tag Management Lösung
Container Tag – Nie mehr warten auf die IT! - Tag Management LösungContainer Tag – Nie mehr warten auf die IT! - Tag Management Lösung
Container Tag – Nie mehr warten auf die IT! - Tag Management Lösung
Connected-Blog
 
Principles and Practices in Continuous Deployment at Etsy
Principles and Practices in Continuous Deployment at EtsyPrinciples and Practices in Continuous Deployment at Etsy
Principles and Practices in Continuous Deployment at Etsy
Mike Brittain
 

Andere mochten auch (12)

Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbH
Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbHDocker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbH
Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbH
 
Using Rancher and Docker with RightScale at Industrie IT
Using Rancher and Docker with RightScale at Industrie IT Using Rancher and Docker with RightScale at Industrie IT
Using Rancher and Docker with RightScale at Industrie IT
 
DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?
 
Docker - Containervirtualisierung leichtgemacht
Docker - Containervirtualisierung leichtgemachtDocker - Containervirtualisierung leichtgemacht
Docker - Containervirtualisierung leichtgemacht
 
Continuous Deployment: The Dirty Details
Continuous Deployment: The Dirty DetailsContinuous Deployment: The Dirty Details
Continuous Deployment: The Dirty Details
 
Continuous integration eine Einführung für Unkundige
Continuous integration   eine Einführung für UnkundigeContinuous integration   eine Einführung für Unkundige
Continuous integration eine Einführung für Unkundige
 
Preparing your dockerised application for production deployment
Preparing your dockerised application for production deploymentPreparing your dockerised application for production deployment
Preparing your dockerised application for production deployment
 
Telekom Techtalk - Practical DevOps
Telekom Techtalk - Practical DevOpsTelekom Techtalk - Practical DevOps
Telekom Techtalk - Practical DevOps
 
Docker Einführung @GPN15
Docker Einführung @GPN15Docker Einführung @GPN15
Docker Einführung @GPN15
 
Einblick in die Intranet Transformation bei Swisscom AG
Einblick in die Intranet Transformation bei Swisscom AGEinblick in die Intranet Transformation bei Swisscom AG
Einblick in die Intranet Transformation bei Swisscom AG
 
Container Tag – Nie mehr warten auf die IT! - Tag Management Lösung
Container Tag – Nie mehr warten auf die IT! - Tag Management LösungContainer Tag – Nie mehr warten auf die IT! - Tag Management Lösung
Container Tag – Nie mehr warten auf die IT! - Tag Management Lösung
 
Principles and Practices in Continuous Deployment at Etsy
Principles and Practices in Continuous Deployment at EtsyPrinciples and Practices in Continuous Deployment at Etsy
Principles and Practices in Continuous Deployment at Etsy
 

Ähnlich wie OOP 2012 - Udo Pracht - DevOps Einführung und Überblick

Quo vadis-devops-nuernberg
Quo vadis-devops-nuernbergQuo vadis-devops-nuernberg
Quo vadis-devops-nuernberg
cusy GmbH
 
Day CQ 5.3 WCM - Was ist neu
Day CQ 5.3 WCM - Was ist neuDay CQ 5.3 WCM - Was ist neu
Day CQ 5.3 WCM - Was ist neu
Cédric Hüsler
 
Agile Softwareentwicklung mit Rails
Agile Softwareentwicklung mit RailsAgile Softwareentwicklung mit Rails
Agile Softwareentwicklung mit Rails
Hussein Morsy
 
DevOps: Automatisierte Deployments mit TFS & Octopus Deploy
DevOps: Automatisierte Deployments mit TFS & Octopus DeployDevOps: Automatisierte Deployments mit TFS & Octopus Deploy
DevOps: Automatisierte Deployments mit TFS & Octopus Deploy
Mark Lechtermann
 
HTML5 Offline - Fallstricke für mobile Webseiten und WebApps
HTML5 Offline - Fallstricke für mobile Webseiten und WebAppsHTML5 Offline - Fallstricke für mobile Webseiten und WebApps
HTML5 Offline - Fallstricke für mobile Webseiten und WebApps
Ulrich Schmidt
 
DevOps - ab auf die Reise
DevOps - ab auf die ReiseDevOps - ab auf die Reise
DevOps - ab auf die Reise
Alex Lichtenberger
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
ChristinaLerch1
 
Nefos: Nefos Mobile iPad App
Nefos: Nefos Mobile iPad AppNefos: Nefos Mobile iPad App
Nefos: Nefos Mobile iPad App
Salesforce Deutschland
 
Agents of D.E.V.O.P.S
Agents of D.E.V.O.P.SAgents of D.E.V.O.P.S
1. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.20231. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.2023
Johannes Kleinlercher
 
RSP GmbH Präsentation, CIO-TREFF 24.05.2011, Mobilität mit SAP
RSP GmbH Präsentation, CIO-TREFF 24.05.2011, Mobilität mit SAPRSP GmbH Präsentation, CIO-TREFF 24.05.2011, Mobilität mit SAP
RSP GmbH Präsentation, CIO-TREFF 24.05.2011, Mobilität mit SAP
NETFOX AG
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
Dennis Wilson
 
Templates, Code & Tools
Templates, Code & ToolsTemplates, Code & Tools
Templates, Code & Tools
Ulrich Krause
 
2005 - NRW Conf: Design, Entwicklung und Tests
2005 - NRW Conf: Design, Entwicklung und Tests2005 - NRW Conf: Design, Entwicklung und Tests
2005 - NRW Conf: Design, Entwicklung und Tests
Daniel Fisher
 
BASTA Spring 2016: Test- und Releaseumgebungen der nächsten Generation mit TF...
BASTA Spring 2016: Test- und Releaseumgebungen der nächsten Generation mit TF...BASTA Spring 2016: Test- und Releaseumgebungen der nächsten Generation mit TF...
BASTA Spring 2016: Test- und Releaseumgebungen der nächsten Generation mit TF...
Marc Müller
 

Ähnlich wie OOP 2012 - Udo Pracht - DevOps Einführung und Überblick (20)

20110406 activiti mai
20110406 activiti mai20110406 activiti mai
20110406 activiti mai
 
Quo vadis-devops-nuernberg
Quo vadis-devops-nuernbergQuo vadis-devops-nuernberg
Quo vadis-devops-nuernberg
 
20110321 activiti märz
20110321 activiti märz20110321 activiti märz
20110321 activiti märz
 
Day CQ 5.3 WCM - Was ist neu
Day CQ 5.3 WCM - Was ist neuDay CQ 5.3 WCM - Was ist neu
Day CQ 5.3 WCM - Was ist neu
 
20110406 activiti april
20110406 activiti april20110406 activiti april
20110406 activiti april
 
Agile Softwareentwicklung mit Rails
Agile Softwareentwicklung mit RailsAgile Softwareentwicklung mit Rails
Agile Softwareentwicklung mit Rails
 
20110223 activiti
20110223 activiti20110223 activiti
20110223 activiti
 
2011 05-05 activiti
2011 05-05 activiti2011 05-05 activiti
2011 05-05 activiti
 
DevOps: Automatisierte Deployments mit TFS & Octopus Deploy
DevOps: Automatisierte Deployments mit TFS & Octopus DeployDevOps: Automatisierte Deployments mit TFS & Octopus Deploy
DevOps: Automatisierte Deployments mit TFS & Octopus Deploy
 
HTML5 Offline - Fallstricke für mobile Webseiten und WebApps
HTML5 Offline - Fallstricke für mobile Webseiten und WebAppsHTML5 Offline - Fallstricke für mobile Webseiten und WebApps
HTML5 Offline - Fallstricke für mobile Webseiten und WebApps
 
DevOps - ab auf die Reise
DevOps - ab auf die ReiseDevOps - ab auf die Reise
DevOps - ab auf die Reise
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
 
Nefos: Nefos Mobile iPad App
Nefos: Nefos Mobile iPad AppNefos: Nefos Mobile iPad App
Nefos: Nefos Mobile iPad App
 
Agents of D.E.V.O.P.S
Agents of D.E.V.O.P.SAgents of D.E.V.O.P.S
Agents of D.E.V.O.P.S
 
1. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.20231. Cloud Native Meetup Innsbruck, 23.11.2023
1. Cloud Native Meetup Innsbruck, 23.11.2023
 
RSP GmbH Präsentation, CIO-TREFF 24.05.2011, Mobilität mit SAP
RSP GmbH Präsentation, CIO-TREFF 24.05.2011, Mobilität mit SAPRSP GmbH Präsentation, CIO-TREFF 24.05.2011, Mobilität mit SAP
RSP GmbH Präsentation, CIO-TREFF 24.05.2011, Mobilität mit SAP
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
 
Templates, Code & Tools
Templates, Code & ToolsTemplates, Code & Tools
Templates, Code & Tools
 
2005 - NRW Conf: Design, Entwicklung und Tests
2005 - NRW Conf: Design, Entwicklung und Tests2005 - NRW Conf: Design, Entwicklung und Tests
2005 - NRW Conf: Design, Entwicklung und Tests
 
BASTA Spring 2016: Test- und Releaseumgebungen der nächsten Generation mit TF...
BASTA Spring 2016: Test- und Releaseumgebungen der nächsten Generation mit TF...BASTA Spring 2016: Test- und Releaseumgebungen der nächsten Generation mit TF...
BASTA Spring 2016: Test- und Releaseumgebungen der nächsten Generation mit TF...
 

OOP 2012 - Udo Pracht - DevOps Einführung und Überblick

Hinweis der Redaktion

  1. ... ich hätte mit mehr spitzen Schreien gerechnet...\n... da gibt es viele Entwickler, die in ITIL nur unnötige Formalismen und Behinderung sehen ...\nUnd das ist schon der Einstieg ins Thema: Bei DevOps geht’s um Software-Entwicklung (Dev) und IT-Betrieb (Ops)! Und um das jeweils eigene und das gegenseitige Verständnis.\nIch kenne beide “Lager” ganz gut und bin sehr erfreut, dass mit DevOps genau diese schwierige Schnittstelle zwischen den beiden beleuchtet wird.\n
  2. Was passiert jetzt hier?\nSie können die verschränkten Arme lösen und die Geldbeutel loslassen, ich will Ihnen nichts verkaufen oder Sie von etwas überzeugen. Ich werde Ihnen einen Gesamtüberblick über das Thema geben, damit Sie einschätzen können ob und wo DevOps für Ihre Arbeit interessant bzw. relevant ist.\nFreuen würde ich mich, wenn als kleiner Nebeneffekt Ihnen die Idee kommt (oder bleibt), dass der IT-Betrieb nicht ausschließlich zur Behinderung der Software-Entwicklung da ist ;-)\nAgenda\n\n
  3. \n
  4. Das was ich Ihnen nun sage, ist die grundlegende Erkenntnis des Themas DevOps.\nWenn Ihnen das hier bewusst ist und bleibt, dann leitet sich alles folgende daraus ab. \n
  5. Das ist ein Thema für DevOps...\n
  6. Weiteres Symptom: Die Vorstellung bzgl. der Release-Frequenz zwischen Business, Entwicklung und IT-Betrieb liegen weit auseinander.\n\nIch kenne ein großes Versicherungs-Unternehmen, welches 2011 lediglich drei (!) Releases durchgeführt hat und die Frequenz noch weiter senken möchte. \n
  7. Cloud-Computing und Virtualisierung bieten die Chance, Rechen- und Speicher- kapazitäten dynamisch und bedarfsgenau zu nutzen und einzukaufen. \nSind die für das Unternehmen geltenden Compliance-Anforderungen erfüllt beziehungsweise erfüllbar, müssen sich Entwicklung und Betrieb auf neue Technik, andere Schnittstellen und eine veränderte Administration einstellen und ihr Vorgehen unter anderem beim Release anpassen. Nicht überall können diese Hürden erfolgreich genommen werden und es bleibt nur das diffuse Fazit: Cloud-Computing ist nichts für uns.\n
  8. Ein Kern-Element eines professionell geführten IT-Betriebes ist das Monitoring. Der Status der Systeme wird automatisch überwacht und ein Alarm ausgelöst, wenn definierte Fehler-Situationen eintreten. Wie oft kommt es dennoch vor, dass geschäftsrelevante Anwendungs-Probleme trotzdem erst von den Anwendern gemeldet werden? Häufig ist es doch so, dass zwar technische Kennzahlen und die grundsätzliche Verfügbarkeit von Anwendungen im Monitoring beachtet werden, nicht aber die Verfügbarkeit und Fehlerfreiheit einzelner Funktionen, die aber letztendlich erst den Nutzen des Systems für die Anwender darstellen.\n
  9. Wie ein Release-Prozess aussehen kann oder soll, wird von verschiedenen Konzepten beschrieben, sowohl in ITIL, in den Agilen Methoden als auch in den einschlägigen Projektmanagement-Lehren. Leider sind diese Beschreibungen und die zugehörigen Anforderungen nicht komplett deckungsgleich. Sofern eines der Vorgehen in einem Unternehmen eine stärkere Lobby hat und ohne Rücksicht auf ein Gesamtziel durchgesetzt wird oder aber erst gar kein klarer Weg gewählt wird, kann dies zu folgenden Symptomen führen: unstabile und pflege-intensive Anwendungen in der Produktion oder untragbar lange Zeiten, bis geschäftliche Anforderungen tatsächlich produktiv verfügbar sind.\n
  10. Im Problem Management geht es darum, die Ursachen von Fehlerserien oder schwerwiegenden Fehlern zu ermitteln und zu beseitigen. Liegen die Ursachen im Umfeld von selbst entwickelten Anwendungen, muss der Betrieb zur Behebung mit den betreffenden Projekt-Teams zusammen arbeiten. Die Entwickler sind jedoch ohnehin schon voll ausgelastet und Fehlerbehebung ist meist nicht gerade deren Lieblingstätigkeit. Bevor also der Help-Desk oder der Second-Level-Support nicht ganz klar bewiesen hat, dass es sich um einen Programmfehler handelt, gibt es keine Hilfe. \nDurch das Hin- und Herschieben der Verantwortung und andere Verzögerungen in der Zusammenarbeit verlängert sich die Zeit bis zur Behebung der Fehlerursache, mit negativen Auswirkungen auf die eigentliche Geschäftstätigkeit.\n
  11. Wer bestimmte die Infrastruktur-Architektur, die Software-Entwicklung oder der IT- Betrieb? Beide beanspruchen dieses Vorrecht für sich, mit jeweils durchaus validen Begründungen. Auch hier gilt: Wird dies einseitig, ohne Rücksicht und Beteiligung entschieden oder kein klarer Weg gewählt, entstehen aus gesamtgeschäftlicher Sicht Probleme: entweder organisch gewachsene, undurchschaubare und nur schwer wartbare Systemlandschaften oder aber unflexible, veraltete Umgebungen in die moderne, für das Geschäft benötigte Technik nur schwer Einzug findet.\n
  12. Ein weiterer Diskussionspunkt zwischen Entwicklung und Betrieb ist die Frage, welche Freiheiten Entwickler auf ihren Arbeitsgeräten oder auf den Entwicklungs-Systemen haben. Wenn eine Anwendung auf dem Entwickler-Rechner oder in der Entwicklungs-Umgebung fehlerlos läuft aber keiner mehr weiß, was dafür alles installiert und konfiguriert wurde, dann ist was schief gelaufen. Ein anderes extremes Symptom sind Entwickler, die ihre Zeit überwiegend damit verbringen müssen, Anträge zur Installation von Software zu stellen, die sie für ihre Arbeit benötigen oder die darauf warten, dass ihre beantragten Konfigurations-Änderungen auf dem Entwicklungs-Server durchgeführt werden.\n
  13. Zum Abschluss noch zwei - provokante - Fragen, die als Anregung zur Reflektion dienen können:\nTruck-Faktor\nWie viele Teammitglieder könnten von einem Truck überfahren werden, bevor das Projekt beziehungsweise der Betrieb ernsthafte Schwierigkeiten hat?\n10ter-Stock-Test\nKönnen Sie eine beliebige Komponente aus der Infrastruktur heraus nehmen, sie aus dem 10ten Stock werfen und die Infrastruktur innerhalb von maximal 10 Minuten wieder herstellen?\n\n
  14. Die hier genannten Symptome und die Erfahrungen in derartigen Umgebungen waren es, die einigen Systemadministratoren, Entwicklern und Projektleitern den Antrieb gaben, daran etwas verbessern zu wollen.\n
  15. Grassroots-Movement, kein Manifest (bisher)\nkein abstraktes, theorieüberladenes Framework um (wieder mal) alles abzudecken. \nkeine neue Anforderung, die es aus Compliance-Gründen oder um irgendwo dabei sein zu dürfen zu erfüllen gilt\n2005 ThoughtWorks => "Continuous Delivery" (Buchtitel) von Dan North, Jez Humble, Chris Read, David Farley und Julian Simpson \nHintergrund der Bewegung: Erkenntnisse des agilen Vorgehens. Das, was die Software-Entwicklung dadurch in der Zusammenarbeit mit den Kunden beziehungsweise den Fachbereichen erreicht und verbessert hat, will man nun in den Betriebsbereich bringen. \nBlogs, Büchern und Konferenzen \nAnsätze und Ideen aus Lean Thinking und Kanban\n
  16. \n
  17. Blogs\nPodcasts\nDiskussion\nPraxis-Tipps\n
  18. Der Hofnarr soll unterhalten, darf aber dabei (z.B. durch Spott, Übertreibung und Parodie) auch handfeste Kritik am Herrschenden äußern.\n
  19. HP hat zusammen mit Replay Solutions eine frei verfügbare Umfrage zum Stand von DevOps veröffentlicht. Aus unterschiedlichen Unternehmens-Größen haben über 1.100 englischsprachige IT-Mitarbeiter teilgenommen. Wichtige Erkenntnisse aus den Antworten sind: \n - fast 50% der Befragten integrieren bereits die DevOps-Idee\n - die Behebung von in der Produktion auftretenden Fehlern läuft deutlich schneller bei denen, die DevOps einsetzen\n - der Prozentsatz der Fehler, die erst in der Produktion entdeckt werden, ist deutlich geringer bei denen, die DevOps einsetzen\n\n
  20. ... keine detaillierte Vorstellung, so dass Sie anschließend alles umsetzen können ...\n\nAnsätze aufzeigen\n
  21. \n
  22. Wie im bekannten Harvard-Verhandlungskonzept geht es auch hier darum, dass alle die eigenen Interessen und die der "Gegenseite" kennenlernen und ihre Berechtigung akzeptieren. Die Entwickler lernen, warum manche restriktiven Anforderungen den Administratoren wichtig sind und Produktions-Fehler schnell behoben werden müssen. Administratoren erkennen hingegen, warum die Entwickler Releases schnell produktiv nehmen möchten, bestimmte Zugriffs- oder Konfigurations-Rechte brauchen oder eine bestimmte Architektur präferieren. Das bedeutet nicht, dass man Forderungen widerstandslos erfüllt sondern im ersten Schritt nur: gegenseitiges Verständnis. Dies soll die Grundlage bilden für eine Veränderung der Zusammenarbeit: Weg vom "Fingerzeigen", hin zum "An-einem-Strang-ziehen". \nDevOps beschreibt eine Kultur beziehungsweise die Veränderung zu dieser.\n
  23. Beispiel 1 für gegenseitiges Verständnis\nEin zentrales Anliegen – aus Business-Sicht und passend zur agilen Software-Entwicklung – sind häufige Releases. Der Entwicklung rät DevOps, die Sorgen ernst zu nehmen und zusammen mit dem Betrieb geeignete Mitigation-Maßnahmen sowie Vorteile einer höheren Release-Frequenz auch für den Betrieb zu erarbeiten. \nAls Argumentationshilfe weißt DevOps darauf hin, dass bei häufigeren kleineren Releases...\ndas Risiko und der Aufwand eines einzelnen Releases sinkt.\n(üblicherweise) die Differenz zum Fallback-Szenario kleiner wird.\nder Betrieb mehr Übung im Umgang mit Releases bekommt.\nConfig-Switches eine gut praktikable Lösung für das Problem bei zeitlich versetzten Releases zwischen verbundenen Systemen darstellen.\n\n
  24. Beispiel 1 für gegenseitiges Verständnis\nGeschäfts-, Technik-, Prozess-Metriken\nITIL: Availability Management und Event Management\nBeispiel: Integrationsmöglichkeit für Cucumber in Nagios\n
  25. Wie lässt sich die Kommunikation verbessern? \nDas ist schon oft beantwortet und DevOps erfindet nicht das Rad neu. \nVorschläge: \n"Collective Ownership" (kommt gleich noch)\nRegelmäßige persönliche Treffen, anfangs gegebenenfalls häufiger und dann seltener werdend\nGemeinsamer Einsatz von Kanban\nAktiver, strukturierter Wissens-Austausch\ngemeinsames Lösen von Problemen und Klären von Fragen (zum Beispiel zur Infrastruktur-Architektur)\nRetrospektiven und Post-Mortems\n
  26. Stephen Nelson-Smith hat einen Begriff aus der agilen Entwicklung genommen, ihn ein wenig abgewandelt und mit Elementen aus David Allens Natural Planning kombiniert. Mit "Collective Ownership" möchte er erreichen, dass zusammen arbeitende Entwickler und Administratoren jeweils das ganze Thema kennen und sich dafür verantwortlich sehen.\nStephen Nelson-Smith empfiehlt fünf Schritte für die Zusammenarbeit:\nIn einem Workshop die Grundlagen, Prinzipien und Erfolgsindikatoren für die gemeinsame Arbeit finden sowie die Frage nach dem Warum klären, bis hinunter zu den letztendlich darunter liegenden geschäftlichen Anforderungen.\nWie würde ein außergewöhnlich großer Erfolg der Zusammenarbeit aussehen? Was wäre anders und wie?\nBrainstorming zum Thema: Wie kommen wir zu dem gerade skizzierten Ergebnis unter Berücksichtigung der festgelegten Grundsätze?\nAntworten aus dem Brainstorming thematisch sortieren (clustern), zum Beispiel nach: Technologie, Ideen, mögliche Probleme, zu klärendes, benötigte Ressourcen, hinzuzuziehende Personen und so weiter.\nEine Liste mit Aufgaben erstellen und für die als nächstes anzugehenden, Zuständigkeiten und Termine festlegen. Diese Schritte sollen dann – wann immer möglich – jeweils ein Entwickler und ein Administrator gemeinsam durchführen, ähnlich dem Pair Programming.\n
  27. Sind die Prozesse allen klar und bekannt? Auch die “der anderen”? Auch warum diese oder jene Vorgabe gewählt wurde? => gegenseitiges Verständnis!\n\nWenn das erreicht => prüfen, ob die vorgeschriebenen Prozesse eine andere Zusammenarbeit erlauben\n\nggf. Prozesse müssen Prozesse gemeinsam angepasst werden (Beispiel: Release-Frequenz und ITIL Change Management mit CAB?)\n\nWelche Betriebs-Prozesse von der Bekenntnis zum DevOps-Gedanken berührt werden, ist sicherlich von Unternehmen zu Unternehmen unterschiedlich. Betrachten sollte man zumindest die kompletten Service Support Prozesse nach ITIL v2 beziehungsweise Service Operation und Teile aus Service Transition nach ITIL v3. \n
  28. Dies ist eine Maßnahme die direkt auf den Truck-Faktor zielt: KnowHow verteilen!\n\nEs soll sicher nicht Ziel sein, dass jeder alles kann und macht\nsondern, dass es möglichst wenig Kopfmonopole und daraus resultierende (potentielle) Engpässe gibt\n\nDas richtige Gleichgewicht muss jedes Unternehmen individuell finden aber das Thema sollte überall oben auf der Agenda stehen!\n
  29. So, jetzt gibt’s - nach dem Monitoring - nochmal etwas Technik:\nZentrales Konzept der Bewegung: "Treat Infrastructure as Code"\nTheoretisches Maximal-Ziel: Infrastruktur nur aus Blech und verlegten Kabeln sowie einem Repository aufbauen zu können (von den Switches bis hin zum SAN)\n\nAlso: Automatisierung und Scripten, was das Zeug hält...\n\nInfrastructure Management meist aber Configuration Management Tools \nDiverse Open-Source-Projekte und kommerzielle Anbieter, "Puppet" und "Opscode Chef" momentan am verbreitetsten\n
  30. Ein Schritt auf dem Weg zu diesem Maximal-Ziel: Continuous Build and Deployment\nAlle Veränderungen während eines Releases laufen skriptgesteuert \nsogenannte One-Click-Installationen\n\nDas ist:\nzum einen = Grundlage für hohe Release-Frequenz\nzum anderen, gepaart mit der Unterstützung von Virtualisierungs-Techniken = Voraussetzung, um die Möglichkeiten und Chancen von Cloud-Computing voll nutzen zu können \nEin großer Teil des Engagements für DevOps kommt aus Unternehmen und Projekten, die Cloud-Technologie nutzende Anwendungen erstellen und betreiben.\n\n\n\n
  31. Neben Infrastruktur-Management und Monitoring gibt es weitere das Thema DevOps berührende Bereiche, in denen Tools Optimierung versprechen.\n\nDies sind alles keine Anwendungen, die aus der DevOps-Bewegung heraus initiiert wurden, die aber deren Ziele unterstützen können und die zudem zunehmend von der Idee befruchtet und verändert werden.\n
  32. Ja nun, mag mancher nun sagen, was soll das? Cloud-Computing ist für meinen Fall überhaupt nicht passend und nur um die Zusammenarbeit zwischen zwei Bereichen innerhalb der IT zu verbessern, mach’ ich doch nicht so ein Fass auf!\n \nEs sind jedoch nicht irgendwelche Bereiche in der IT! Betrachtet man, wie eine Anwendung von der Idee zur Nutzung kommt, dann ist erkennbar, dass DevOps einen wesentlichen Schritt auf genau diesem Weg adressiert: den Übergang von der Realisierung zur Bereitstellung. \n\nMehrwert für das Unternehmen entsteht ja nicht, wenn die Entwicklung sagt: “Fertig” \nsondern erst dann, wenn das auch produktiv verfügbar ist!\n\nBeispiel von agilen Projekten im Konzern-Umfeld, die mit Sprints arbeiten, deren Ergebnisse aber nur alle vier oder fünf Monate ins Produktiv-System einfließen...\n
  33. Patrick Peschlow (Javamagazin 1.2012): “Es muss sich lohnen...!”\n\nAll diese Lösungsansätze sollen letztendlich einen für das Unternehmen sinnvollen wirtschaftlichen Nutzen erbringen und der lässt sich aus diesen hier genannten Aspekten ableiten! \n\n
  34. \n
  35. Das ist doch von Scrum, ITIL, PMBOK oder irgend einem anderen Konzept schon längst adressiert, längst gelöst und muss nur entsprechend und konsequent umgesetzt werden.\nWenn die eingangs geschilderten Symptome und Probleme nicht auftreten, gibt es auch keinen Grund, sich mit DevOps zu beschäftigen. PUNKT!\n\nFalls aber doch, ist wahrscheinlich genau diese Überzeugung "Ich weiß, wie ihr zu arbeiten habt!" der Grund dafür \nund DevOps bietet dann durchaus eine neue Perspektive.\n
  36. Ich zeige Ihnen nun etwas ganz geheimes: \nEin neues Tool, mit dem Sie komplett DevOps-compliant werden!!! Kommt nächsten Monat raus!\n\nScherz beiseite! Weiterer Kritik-Punkt: DevOps ist ein rein technisches Thema, das Hersteller als Vehikel nutzen, um neue Software-Werkzeuge und Funktionen zu verkaufen. \n\nDies mag tatsächlich eine drohende Gefahr für das Thema sein aber das Engagement, mit dem die DevOps-Community gerade die kulturellen Aspekte angeht und vorantreibt, lässt hoffen, dass die Bewegung ihr Ziel nicht verliert. \n
  37. Was kann noch passieren? DevOps kann ein weiteres Silo bzw. ein separater Job werden...\nMöglicherweise sogar mit der Idee, dass man dabei ja auch ein paar Leute einsparen kann, wenn man Entwickler hat, die auch Admins sind bzw. umgekehrt...\n\nStellen-Anzeigen! \nMeine Interpretation: Es werden Leute gesucht, die den DevOps-Ansatz kennen und unterstützen.\n
  38. DevOps bietet jetzt die Chance die Vorteile und den Schwung der agilen Methoden in den IT-Betrieb zu bringen und sich dadurch eine Vorreiter-Position bei der Bereitstellung von Anwendungen und IT-Services zu verschaffen. \n\nEin häufig zitiertes, prominentes Beispiel für eine hohe DevOps-Durchdringung ist die Foto-Plattform Flickr. Auf deren Seiten findet man eine stetig aktualisierte Information in folgender Form: "Flickr was last deployed 31 hours ago, including 5 changes by 3 people. In the last week there were 86 deploys of 669 changes by 19 people." Diese hohe Release-Frequenz geht einher mit einer Spitzenposition im Social Media Bereich, was die Verfügbarkeit beziehungsweise Uptime angeht.\nDurchsucht man die einschlägigen sozialen Netzwerke, stellt man fest, dass es auch im deutschsprachigen Raum schon einige große Unternehmen gibt, deren Mitarbeiter sich engagiert mit dem Thema beschäftigen: Deutsche Post, Axel Springer AG, Nokia ImmobilienScout24, 1&1 Internet AG, DuMont, und die Deutsche Flugsicherung sind Beispiele dafür. Dr. Johannes Mainusch, Vice President Operations bei der XING AG, schreibt auf Anfrage des Autors: "Besonders wichtig wird [DevOps] für Organisationen, die den Übergang vom Startup-Zeitalter zu einer stabilen und professionellen Organisation geschafft haben und sich nun der Herausforderung immer stärkerer Spezialisierung der Fachbereiche stellen müssen. Dabei geht häufig der gemeinsame Blick aufs Ganze verloren." Die XING AG setzt auf DevOps und schafft intern ein wachsendes Bewusstsein dafür. Dr. Mainusch: "Ich habe seit langer Zeit endlich wieder Experten euphorisch gesehen."\n\n
  39. \n