Go away or I will replace you with a little shell script

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 Einﬂüsse: Marktreife und Prozeßreife5

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

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

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

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

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

13. Wirtschaftliche Einﬂü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 Einﬂü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 Ofﬁce, 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-ﬂickr

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-ﬂickr 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-ﬂickr 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-ﬂickr 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-ﬂickr 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-ﬂickr 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-ﬂickr 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 ﬁx it? 26

46. “Booking Rules”   #1 If you break it, will you even notice?  #2 If you break it, can you ﬁx 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 ﬁx 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-MiniTrafﬁcLight-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 ﬁnd 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 ﬁne.

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 notiﬁcation 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 notiﬁcation engine.« 52 Bingo!

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

83. If you break it, can you ﬁx it?54

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

85. 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 ?