1.
1

2.
Go away or I will
replace you with a very
small Shell script
Kristian Köhntopp
Alter Sack
kris@syseleven.de
Ein paar Gedanken
zum Thema DevOps

3.
3
$FCE2

4.
„Alter Sack.“
3

5.
– Rajat Bhargava, http://devops.com/features/devops_and-enterprises/
„DevOps and Enterprises:
It's a culture thing.“
4

6.
– Rajat Bhargava, http://devops.com/features/devops_and-enterprises/
„DevOps and Enterprises:
It's a culture thing.“
4
Einflüsse

7.
Wirtschaftliche Einflüsse: Marktreife und Prozeßreife5

8.
Wirtschaftliche Einflüsse: Marktreife und Prozeßreife5
Pre-Dotcom:
Kein Business-
Modell

9.
Wirtschaftliche Einflüsse: Marktreife und Prozeßreife5
Pre-Dotcom:
Kein Business-
Modell
KeineBestPractices

10.
Wirtschaftliche Einflüsse: Marktreife und Prozeßreife5
Pre-Dotcom:
Kein Business-
Modell
KeineBestPractices
QualitativeBestPractices

11.
Wirtschaftliche Einflüsse: Marktreife und Prozeßreife5
Pre-Dotcom:
Kein Business-
Modell
KeineBestPractices
QualitativeBestPractices
Metriken,KVP

12.
Wirtschaftliche Einflüsse: Marktreife und Prozeßreife5
Pre-Dotcom:
Kein Business-
Modell
KeineBestPractices
QualitativeBestPractices
Metriken,KVP
Outsourcing
möglich
Unklar,
was gekauft/
verkauft wordenist

13.
Wirtschaftliche Einflüsse: Marktreife und Prozeßreife5
Pre-Dotcom:
Kein Business-
Modell
KeineBestPractices
QualitativeBestPractices
Metriken,KVP
Outsourcing
möglich
Unklar,
was gekauft/
verkauft wordenist
Wiederholung
Veränderung

14.
Technische Einflüsse:
Scale-Up
vs.
Scale-Out
6

15.
Erkenntnis um 2002:
“Scale Up” funktioniert nicht.

16.
“Scale Out” tut super.
Resultat: Moar Boxes!!1!eins!!elf!!!

17.
–Kris, zu jedem der es nicht hören will.
„Wenn Du eine ssh benutzt, kannst Du
gleich ein Ticket aufmachen.“
9

18.
Automatisierte Systemadministration10
Branch Release
Fix
Merge

19.
„Reproduzierbar.
Parallelisierbar.
Orchestrierbar.“
11

20.
Und die Kultur drumrum?
12

21.
de.alt.sysadmin.recovery
Cat-5-O-Nine-Tails und Kekse von Antje Bendrich, Dezember 2008

22.
Canossa 1999
http://www.42.org/~sec/Berichte/199907Canossa/bild09.jpg

23.
Pre-DevOps (First Edition: 2001)
via http://geek-whisperers.com/wp-content/uploads/2014/11/thomas-limoncelli.jpg

24.
DevOps: Patrick Debois (2008, Belgien)
Währenddessen in Amsterdam…
Booking.com Office, 2008

25.
ITIL vs. DevOps?
Noch so ein
Scale-Up vs. Scale-Out Ding…
17

26.
Grundidee: Die Mauer muß weg.
Brandenburger Tor, 1989 - Foto: Thomas 'tlr' Roessler

27.
19 DevOps
https://twitter.com/jezhumble/status/259368948859023362

28.
Kennzeichen einer modernen Entwicklungsumgebung20
• Automated Infrastructure
• Shared Version Control
• One Step Build and Deploy
• Feature Flags, Graceful Degradation
• Test and Measure all the things
• Instant Communication
nach John Allspaw (2009), http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

29.
Kennzeichen einer modernen Entwicklungsumgebung20
• Automated Infrastructure
• Shared Version Control
• One Step Build and Deploy
• Feature Flags, Graceful Degradation
• Test and Measure all the things
• Instant Communication
nach John Allspaw (2009), http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
Systems

30.
Kennzeichen einer modernen Entwicklungsumgebung20
• Automated Infrastructure
• Shared Version Control
• One Step Build and Deploy
• Feature Flags, Graceful Degradation
• Test and Measure all the things
• Instant Communication
nach John Allspaw (2009), http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
Systems
Code

31.
Kennzeichen einer modernen Entwicklungsumgebung20
• Automated Infrastructure
• Shared Version Control
• One Step Build and Deploy
• Feature Flags, Graceful Degradation
• Test and Measure all the things
• Instant Communication
nach John Allspaw (2009), http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
Systems
Code
Deploy

32.
Kennzeichen einer modernen Entwicklungsumgebung20
• Automated Infrastructure
• Shared Version Control
• One Step Build and Deploy
• Feature Flags, Graceful Degradation
• Test and Measure all the things
• Instant Communication
nach John Allspaw (2009), http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
Systems
Code
Deploy
Activation

33.
Kennzeichen einer modernen Entwicklungsumgebung20
• Automated Infrastructure
• Shared Version Control
• One Step Build and Deploy
• Feature Flags, Graceful Degradation
• Test and Measure all the things
• Instant Communication
nach John Allspaw (2009), http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
Systems
Code
Deploy
Activation
Failuredetection

34.
Kennzeichen einer modernen Entwicklungsumgebung20
• Automated Infrastructure
• Shared Version Control
• One Step Build and Deploy
• Feature Flags, Graceful Degradation
• Test and Measure all the things
• Instant Communication
nach John Allspaw (2009), http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
Systems
Code
Deploy
Activation
FailuredetectionFixing

35.
Technische und kulturelle Konvergenz21

36.
Technische und kulturelle Konvergenz21
• "Script all the things", "Centralize all monitoring", etc. pp.

37.
Technische und kulturelle Konvergenz21
• "Script all the things", "Centralize all monitoring", etc. pp.
• "System administration built in at development stage."

38.
Technische und kulturelle Konvergenz21
• "Script all the things", "Centralize all monitoring", etc. pp.
• "System administration built in at development stage."
• Entwickler und Admins verwenden dieselben Tools

39.
Technische und kulturelle Konvergenz21
• "Script all the things", "Centralize all monitoring", etc. pp.
• "System administration built in at development stage."
• Entwickler und Admins verwenden dieselben Tools
• "Dann kann man die beiden auch zusammenlegen."

40.
Technische und kulturelle Konvergenz21
• "Script all the things", "Centralize all monitoring", etc. pp.
• "System administration built in at development stage."
• Entwickler und Admins verwenden dieselben Tools
• "Dann kann man die beiden auch zusammenlegen."
➡ DevOps

41.
Wieso gibt es dann Reibereien?
22

42.
Unterschiedliche Erfolgsmetrik für Operations Infrastruktur

43.
Feature-Entwicklung

44.
Infrastruktur-Entwicklung

45.
“Booking Rules”
#1 If you break it, will you even notice?
#2 If you break it, can you fix it?
26

46.
“Booking Rules”
#1 If you break it, will you even notice?
#2 If you break it, can you fix it?
Die Regeln reden über Failure!
26

47.
“Booking Rules”
#1 If you break it, will you even notice?
#2 If you break it, can you fix it?
Die Regeln reden über Failure!
26
Hack!

48.
How did your patch change the worst case?
http://www.instructables.com/id/Storing-garden-tools-with-style-aka-Zombiewall/

49.
Fuck you, Nvidia!
http://www.reddit.com/r/technology/comments/v5n9t/linus_to_nvidia_fuck_you/c51kp48

50.
Infrastrukturdenkweise ist schwer zu vermitteln.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0bc65729070b9cbdbb53ff042984a3c545a0e34

51.
Wer von Euch war dabei? Wer erinnert sich noch?
http://www.computerwoche.de/a/defekter-emc-speicher-legt-strato-lahm,520152

52.
Wer von Euch war dabei? Wer erinnert sich noch?
http://www.computerwoche.de/a/defekter-emc-speicher-legt-strato-lahm,520152
14 Jahre her!

53.
Wir haben alle solche Geschichten.
http://www.golem.de/0505/38057.html
10 Jahre her!

54.
vs. "Never change a running system".

55.
Not changing has costs.

56.
Managing change…
• Aus einer Booking.com Präsentation:
»Some companies are creating elaborate change
management processes in order to deal with change.
That's not solving the change problem at all, it's just
making change harder.«
34

57.
Budgeting downtime
•We have a budget for
downtime.
•A foreign concept,
outside of Booking.

58.
Budgeting downtime
• "Validated corporate learning."
• So we spend a number of € by not
earning them.
• What is the takeaway we got from that?
• “Blameless Postmortem”

59.
Careful Carelessness

60.
Careful Carelessness
• Skydiving:
• Jumping out of an open plane door,
because fun.
• That's the visible part.
• That's the "carelessness" part.

61.
Careful Carelessness
• Training
• Team you can trust
• Main, packed by you, checked by others
• Reserve, packed by others, checked by
you

62.
In a way, that is
what we do.

63.
Careful Carelessness
• If anything is wrong, at all:
Don't jump!

64.
Careful Carelessness
• The goal is to survive a 4000 Meter
drop rollout.

65.
Careful Carelessness
• The goal is to survive a 4000 Meter
drop rollout.
• Every time. Every day. 50 times a day.

66.
Survivability
• Building systems in a way that
failure is survivable.

67.
Survivability
• Building systems in a way that
failure is survivable.
• Because you can learn from failure,
yours and those of others,

68.
Survivability
• Building systems in a way that
failure is survivable.
• Because you can learn from failure,
yours and those of others,
• only if you manage to walk away from
these failures,

69.
Survivability
• Building systems in a way that
failure is survivable.
• Because you can learn from failure,
yours and those of others,
• only if you manage to walk away from
these failures,
• and tell others the story.

70.
Weil wir aus Fehlern lernen.

71.
Managing change…
• Fokus auf Tests
• je nach Grad der Kontrolle
• live (bevorzugt) oder
• in Testsystemen.
45
Foto: Charly Kuehnast, Ampel: http://www.cleware-shop.de/USB-MiniTrafficLight-EN

72.
Echt jetzt?

73.
System Administration by Force…
• Always shut systems down by pulling the plug…
• … and even destroy production systems randomly.
47

74.
System Administration by Force…
• Always shut systems down by pulling the plug…
• … and even destroy production systems randomly.
• Always test in production…
• … and find methods to do so safely.
47

75.
Aber was ist mit den Kätzchen?

76.
–via Martin Seeger (NetUSE AG)
„Nobody wants Backup.
Everybody needs Restore.“
49

77.
–via Martin Seeger (NetUSE AG)
„Nobody wants Backup.
Everybody needs Restore.“
49
Rebuild is just fine.

78.
Wieso gibt es dann Reibereien?
50

79.
Monasca

80.
How to win at Hipsterbingo…
• »Monasca is an open-source multi-tenant, highly
scalable, performant, fault-tolerant monitoring-as-a-
service solution that integrates with OpenStack.
It uses a REST API for high-speed metrics processing and
querying and has a streaming alarm engine and
notification engine.«
52

81.
How to win at Hipsterbingo…
• »Monasca is an open-source multi-tenant, highly
scalable, performant, fault-tolerant monitoring-as-a-
service solution that integrates with OpenStack.
It uses a REST API for high-speed metrics processing and
querying and has a streaming alarm engine and
notification engine.«
52
Bingo!

82.
If you break it, can you fix it?
• »Uses a number of underlying technologies:
Apache Kafka, Apache Storm, Zookeeper, MySQL,
Vagrant, Dropwizard, InfluxDB, Vertica.«
53

83.
If you break it, can you fix it?54

84.
If you break it, can you fix it?54
Infrastruktur-Erfolgsmetrik:
Verhalten bei Versagen.

85.
Containerism…55

86.
Containerism…55

87.
Containerism…55

88.
Containerism…55

89.
Works On My System…56

90.
Works On My System…56
Getestet mit Devstack
in Vagrant
und VMware Fusion
auf einem MacBook Air
bei einem Cappucino
im St. Oberholz?

91.
Cargo Culting…57
https://twitter.com/Manz/status/580160845587574784

92.
„Informatik ist die Wissenschaft
von den Nullen und Einsen.
Komplizierter wird es nicht mehr.“
58

93.
Wieso ist es dann so schwer?
• Kein anderes Fach stapelt mehr Abstraktionen
übereinander und nebeneinander.
59

94.
Wieso ist es dann so schwer?
• Kein anderes Fach stapelt mehr Abstraktionen
übereinander und nebeneinander.
• Epsilon-Delta über 3 Dutzend Ebenen,
59

95.
Wieso ist es dann so schwer?
• Kein anderes Fach stapelt mehr Abstraktionen
übereinander und nebeneinander.
• Epsilon-Delta über 3 Dutzend Ebenen,
• in nichtlinearen Systemen,
59

96.
Wieso ist es dann so schwer?
• Kein anderes Fach stapelt mehr Abstraktionen
übereinander und nebeneinander.
• Epsilon-Delta über 3 Dutzend Ebenen,
• in nichtlinearen Systemen,
• mit kaskadierenden Abhängigkeiten.
59

97.
– "Epigrams in Programming", Alan J. Perlis, Sep 1982, ACM SIGPLAN
„55. A LISP programmer
knows the value of everything,
but the cost of nothing.“
60

98.
–Ralf Ertzinger (sinngemäß zitiert)
„Haha. Virtualisiert mal schön.
Aber irgendjemand wird Eure
Matroshka-Netzwerke auch einmal
debuggen müssen.“
61

99.
• Architect
• Infrastructure Developer
• System Administrator
• Operator
62

100.
• Architect
• Infrastructure Developer
• System Administrator
• Operator
62

101.
63
?