Das Dokument von Jean-Pierre König behandelt die Herausforderungen und den Fortschritt im Bereich DevOps, einschließlich der Trennung zwischen Softwareentwicklung und Systembetrieb, sowie den Übergang zu agilen Praktiken. Es wird hervorgehoben, dass DevOps eine engere Zusammenarbeit zwischen Entwicklung und Betrieb fördert, was zu häufigeren Releases und einer schnelleren Anpassungsfähigkeit an Veränderungen führt. Zudem werden Werkzeuge und Prinzipien vorgestellt, die Automatisierung und kontinuierliche Verbesserung im DevOps-Prozess unterstützen.

1. Jean-Pierre König @jpkoenig
DEVOPS
PROGRAMMIERST DU NOCH ODER BETREIBST DU SCHON?
14.03.12

2. Agenda
2
• Status Quo – „Wall of Confusion“
• Agile Movement, Software Entwicklung
• DevOps
• DevOps @memonews
14.03.12

3. About me
Jean-Pierre König
Head of Technology,
MeMo News AG
Dipl. Informatiker
Tags: Agile, BigData,
Hadoop
14.03.12

4. Status Quo
WALL OF CONFUSION

5. IT Welt
• Softwareentwicklung & Systembetrieb
organisatorisch klar getrennt
• Auslagerung von Organisationseinheiten in
andere Unternehmen
FOO Inc.
... Finanzen Personal Software Betrieb Verkauf ...
BAR Corp. Outsourcing
Betrieb
14.03.12

6. Gründe
• Skaleneffekt beim Konsolidieren des
Systembetriebs nutzen
• Personalbedarf im Betrieb steigt nicht zwangsläufig
proportional zur Anzahl der zu betreuenden Systeme
Betrieb mehrerer Systeme bündeln und an
ausgewiesene Organisationseinheiten übergeben ist
wirtschaftlich vorteilhaft
• Betriebs- und Administrationsaufgaben erfordern
anderes Mitarbeiterprofil
14.03.12

7. Ergebnis
• Etablierte „Schnittstelledefinition“ zwischen
beiden Welten – Wall of Confusion
• Wie überführt man Software in den Betrieb?
• Wie kann man sicherstellen, dass der Betreib
den Anforderungen der Stakeholder gerecht
wird?
• ...
• Prozesse, Metriken, SLA‘s, Regelungen, ...
Die IT Infrastructure Library (ITIL) ist eine Sammlung von Best Practices bzw. Good Practices in einer Reihe von Publikationen, die eine
mögliche Umsetzung eines IT-Service-Managements (ITSM) beschreiben und inzwischen international als De-facto-Standard hierfür
gelten.
Quelle: http://de.wikipedia.org/wiki/IT_Infrastructure_Library
14.03.12

8. Ergebnis (2)
I want I want
change! stability!
Dev Ops
• automatisiert • formal
Allenfalls eine funktionale Zusammenarbeit, aber wenig effizient
bzw. effektiv.
14.03.12

9. Devs
ZEIT FÜR VERÄNDERUNG

10. Warum?
Bis zur Jahrtausendwende - klassische Software
Entwicklungsmethoden etabliert
Nachteilig:
• Plangetrieben
• Vollständige Erfassung aller Anforderungen nur
mit immensem Aufwand möglich
• „Keine“ Flexibilität bei geschäftlicher,
gesetzlicher oder technischer Veränderung
• ...

11. Klassisch
Releasezyklus
Releasezyklus
zentrale
QA
zentrale
QA
Initialisierung zentrale
QA
Analyse
zentrale
QA
Entwurf
zentrale
QA
Realisierung
Einführung
Nutzung
Zeit
... Dev Ops Ops
+ Anwender
Time to Release
14.03.12

12. Agile, Agile, Agile
Seit ca. 2003 Kanban & Scrum im Aufwand
Ziele:
• Risiko minimieren, an Anforderungen vorbei zu
entwickeln
• Entwicklungskosten einsparen, Time-To-Market
Voraussetzungen:
• Besseres Zusammenspiel zwischen Entwicklern
und Nutzern, Anwender einbinden
• Kürzere Entwicklungszyklen
14.03.12

13. Agile/Iterativ
„Agilisierter Wasserfall“
Releasezyklus
Releasezyklus
zentrale
QA
zentrale
QA
Sprint 1 2 3 4 ... n
Analyse & Analyse & Design
Analyse & Analyse & Design
Design
Design Analyse & Design Einführung
Implementierung
Implementierung
Implementierung
Implementierung Implementierung Nutzung
Test & Demo & Demo
Test & Demo & Demo
Test Test Test & Demo
Zeit
Scrum Team (Dev) Ops Ops
+ Anwender
Time to Release + (Proxy-) Anwender
14.03.12

14. Die Lösung
DEVOPS

15. DevOps
Auch: Continuous Delivery, Continuous Deployment
Releasezyklus
Releasezyklus
Releasezyklus
Releasezyklus
Releasezyklus
Sprint 1 2 3 4 ... n
Analyse & Design Design Design Design
Analyse &
Analyse &
Analyse & Analyse & Design
Implementierung
Implementierung
Implementierung
Implementierung Implementierung
Test & Demo Demo Demo Demo
Test & Test & Test & Test & Demo
Einführung
Einführung
Einführung
Einführung Einführung
Nutzung
Nutzung
Nutzung
Nutzung Nutzung
Delivery Team Zeit
+ (Proxy-) Anwender
Time to Release
14.03.12

16. DevOps steht für ...
• Engere Verbindung von Entwicklungsabteilung
und Systembetrieb unter Zuhilfenahme agiler
Praktiken
• Entsprechende Kultur im Umgang miteinander
• Werkzeuge, mit denen sich Betriebsaufgaben
automatisieren lassen
• Zunahme der Häufigkeit von Änderungen bei
gleichzeitiger Risikominimierung
14.03.12

17. DevOps
... is emerging set of
principles, methods
and practices for
communication, DevOps
collaboration and
integration between Technology
Operations
...
[wikipedia]
Patrick Debois prägte den Begriff 2009 erstmalig auf der
devopsdays.org Konferenz
14.03.12

18. Funktionierts?
• Google (2010): > 20‘000 Experimente führten
zu mehr als 500 Updates verschiedener
Algorithmen – fast 2 mal täglich
• Wordpress (2005-2010):
> 25‘000 Releases – ca. 16 pro Tag
• Etsy, (2010): > 25 Releases/Tag
14.03.12

19. DevOps
PRINCIPLES

20. DevOps Principles
• Reproducible, automated releasing
• Fail fast – fail early – fail often
• Don’t hack under stress – find, fix & start over!
• Everything is under version control
• Don‘t blame others
• It‘s not (mine|yours|theirs ) – it‘s our
• Continuous improvement
14.03.12

21. DevOps
TOOLS

22. Tools (1)
„Infrastructure as Code“
Betriebshandbuch
Dev Ops
• „nicht“ versiert in Shell Programmierung • „keine“ tiefen Kenntnisse über das
• „keine“ fundierte Kenntnisse im Umgang Verhalten von Anwendungen auf dem
mit Unix-Systemen Zielsystem
• „wenig“ Informationen über die Funktionen
einer Anwendungen
• „wenig“ Informationen zur Konfiguration
1. Gemeinsames Vokabular (DSL) definieren
2. Gemeinsames Beschreiben aller notwendigen Schritte
3. Direkte Überführung in ein ausführbares Programm
4. Versionierung des Programms zusammen mit der Software
• Sehr schnelle betriebsfertige Einrichtung mehrerer Systeme aus einer einheitlichen Quelle
14.03.12

23. Tools (2)
Deployment von Anwendung
Betriebshandbuch
Dev Ops
• „keine“ Informationen zu •„wenig“ Informationen zur Installation einer
Installationspfaden und Environment Anwendung auf dem Zielsystem
Variablen
1. Gemeinsames Vokabular (DSL) definieren capistrano
2. Gemeinsames Beschreiben aller notwendigen Schritte Fabric
3. Direkte Überführung in ein ausführbares Programm
4. Versionierung des Programms zusammen mit der Software
• Sehr schnelles Deployment einer lauffähigen Anwendung pro Umgebung
14.03.12

24. DevOps
@MEMO
14.03.12

25. Infrastructure as Code
[Basics] [Basics]
• Open-Source Name=k3‐s14
Networks[]=lan
IPv4forwarding=enabled
Name=memo‐test‐hmaster
IPbase=10.147.55
Fixed=1
Software, YMC AG
VirtualIP=disabled
AdminGroups[]=ymcRootAccessToAnyHost HA[]=disabled
Port=22
cnames[]=disabled
Servers[]=k3‐s14
• Produktiver LVM[]=root
LVM[]=swap cnames[]=disabled
Einsatz: Schweizer
[LVM_root] Admins[]=ymc‐jaou
Size=10G Admins[]=memo‐jeko
Filesystem=ext4 Admins[]=memo‐vaki
Admins[]=memo‐niku
Fernsehen [LVM_swap]
Size=5G
Filesystem=swap
Admins[]=memo‐chgu
LVM[]=disabled
• PHP-basiert,
[Network_lan] Mount[]=disabled
Interfaces[]=1
IP=10.147.213.14 [k3‐s14]
Netmask=255.255.0.0 Number=1
automatisiert Gateway=10.147.89.254
Layout=single
Routes[]=disabled
...
[Interface_lan1]
hwAddr=00:1b:05:93:d5:0e
ConnectedToInfo=r2‐s5
[Monitoring]
CheckGroups[]=ymcClusterNodeDefaultCheckGroup
14.03.12

26. Deployment
[9:33:14] nkuebler:processr git:(master) $ cap unicorn:start
• Web Anwendung triggering start callbacks for `unicorn:start'
* executing `multistage:ensure'
*** Defaulting to `rapid‐test'
* executing `rapid‐test'
• capistrano * executing `unicorn:start'
* executing `unicorn:start_production'
* executing "if [ ‐f /usr/share/memo‐processr/shared/pids/unicorn.pid ]
&& kill ‐0 $(</usr/share/memo‐processr/shared/pids/unicorn.pid)
• Java Anwendung >/dev/null 2>&1; then echo 'unicorn already running'; else echo
'starting unicorn...'; source /usr/local/rvm/environments/ruby‐1.9.2‐
p290; cd /usr/share/memo‐processr/current && /usr/share/memo‐
processr/shared/binstubs/unicorn ‐E production ‐D ‐c /usr/share/memo‐
• Jenkins* processr/current/config/unicorn/production.rb; fi"
servers: ["k3‐s7.ymchq", "k3‐s8.ymchq", "k3‐s9.ymchq", "k3‐
s10.ymchq", "k3‐s19.ymchq", "k3‐s20.ymchq"]
(PostBuildSteps) [k3‐s7.ymchq] executing command
[k3‐s8.ymchq] executing command
[k3‐s9.ymchq] executing command
• capistrano* [k3‐s10.ymchq] executing command
[k3‐s19.ymchq] executing command
[k3‐s20.ymchq] executing command
** [out :: k3‐s19.ymchq] starting unicorn...
** [out :: k3‐s10.ymchq] starting unicorn...
** [out :: k3‐s7.ymchq] starting unicorn...
** [out :: k3‐s20.ymchq] starting unicorn...
** [out :: k3‐s8.ymchq] starting unicorn...
** [out :: k3‐s9.ymchq] starting unicorn...
command finished in 4967ms
* executing `unicorn:start_test'
* executing "if [ ‐f /usr/share/memo‐processr/shared/pids/unicorn.pid ]
&& kill ‐0 $(</usr/share/memo‐processr/shared/pids/unicorn.pid)
>/dev/null 2>&1; then echo 'unicorn already running'; else echo
'starting unicorn...'; source /usr/local/rvm/environments/ruby‐1.9.2‐
p290; cd /usr/share/memo‐processr/current && /usr/share/memo‐
processr/shared/binstubs/unicorn ‐E production ‐D ‐c /usr/share/memo‐
processr/current/config/unicorn/test.rb; fi"
servers: ["k3‐s17.ymchq"]
[k3‐s17.ymchq] executing command
* (noch) nicht in Produktion ** [out :: k3‐s17.ymchq] starting unicorn...
command finished in 3884ms
14.03.12

27. jean-pierre.koenig@menonews.com
DANKE!

28. Quellen & Literatur
http://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing-anyway/
http://devopsdays.org/
http://www.agileweboperations.com/20-devops-guys
http://en.wikipedia.org/wiki/DevOps
http://dev2ops.org/blog/2010/2/22/what-is-devops.html
http://continuousdelivery.com/
Tools:
• http://wiki.opscode.com/display/chef/Home
• http://puppetlabs.com/
• https://github.com/capistrano/capistrano/wiki/Documentation-v2.x
• http://docs.fabfile.org/en/1.4.0/index.html
• http://rundeck.org/
Beispiele:
• Google: http://insidesearch.blogspot.com/2011/11/ten-recent-algorithm-changes.html
• Wordpress: http://toni.org/2010/05/19/
• Etsy: http://codeascraft.etsy.com/2011/02/04/