Details

<p>Über die Autorin 9</p> <p>Vorwort 11</p> <p><b>Einleitung</b> <b>25</b></p> <p>Über dieses Buch 25</p> <p>Törichte Annahmen über den Leser 25</p> <p>Symbole in diesem Buch 26</p> <p>Wie geht es weiter? 26</p> <p><b>Teil I: DevOps entmystifizieren 27</b></p> <p><b>Kapitel 1 Einführung in DevOps</b> <b>29</b></p> <p>Was ist DevOps? 29</p> <p>DevOps hat sich aus Agile entwickelt 30</p> <p>DevOps stellt Menschen in den Mittelpunkt 30</p> <p>Unternehmenskultur ist die Grundlage von DevOps 30</p> <p>Sie lernen, indem Sie den Prozess überwachen und Daten sammeln 31</p> <p>Überzeugungskraft ist der Schlüssel zur Umsetzung von DevOps 31</p> <p>Kleine, inkrementelle Änderungen sind unbezahlbar 32</p> <p>Von DevOps profitieren 32</p> <p>Das CALMS-Modell 33</p> <p>Das Problem der Interessenskonflikte lösen 35</p> <p><b>Kapitel 2 Gestalten Sie Ihre Organisation</b> <b>37</b></p> <p>Die Gesundheit Ihrer Unternehmenskultur bewerten 38</p> <p>DevOps integrieren 39</p> <p>Die DevOps-Werte im Einzelnen 40</p> <p>Teamwork fördern 40</p> <p>Silos reduzieren 41</p> <p>Denken Sie systemorientiert 41</p> <p>Fehlschläge akzeptieren 41</p> <p>Kommunizieren, kommunizieren, kommunizieren 42</p> <p>Rückmeldungen entgegennehmen 42</p> <p>Abläufe automatisieren (falls sinnvoll) 43</p> <p>Die Unternehmenskultur formen 43</p> <p>Die schlimmsten Fehler der Technologiekultur vermeiden 45</p> <p>Eine Vision entwerfen 46</p> <p>Auf ein gemeinsames Ziel hinarbeiten 47</p> <p>Beurteilungen 48</p> <p>Prämien 49</p> <p><b>Kapitel 3 Überflüssiges erkennen</b> <b>51</b></p> <p>Die sieben Arten von Verschwendung 52</p> <p>Unnötige Abläufe 52</p> <p>Wartezeiten 52</p> <p>Bewegung 53</p> <p>Kosten für Fehler 53</p> <p>Überproduktion 53</p> <p>Transport 53</p> <p>Lagerbestand 54</p> <p>Verschwendung in DevOps verstehen 54</p> <p>Verschwendung vermeiden 56</p> <p>Flaschenhälse erkennen 56</p> <p>Auf die Auswirkungen konzentrieren 59</p> <p><b>Kapitel 4 Die Kollegen überzeugen, es mit DevOps zu probieren</b> <b>61</b></p> <p>Angst vor Veränderungen 61</p> <p>Die Leute um Sie herum vom Wechsel zu DevOps überzeugen 63</p> <p>Unterstützung von Führungskräften erhalten 65</p> <p>Eine Dünung im Entwicklungsteam aufbauen 66</p> <p>Die mittleren Manager managen 67</p> <p>Die Sturköpfe überzeugen 68</p> <p>Die Adaptionskurve verstehen 69</p> <p>Den Wandel vorantreiben 71</p> <p>Auf Gegenwind reagieren 72</p> <p>Den Abgrund überqueren 72</p> <p>Fragen Sie »warum« 73</p> <p><b>Kapitel 5 Ihr Unternehmen beurteilen 75</b></p> <p>DevOps quantifizieren 77</p> <p>Menschen 77</p> <p>Abläufe 78</p> <p>Technologie 79</p> <p>Die Daten erheben 80</p> <p>Interne Fallstudien entwickeln 80</p> <p>Eine qualitative Fallstudie: Konzentrieren Sie sich auf Ihre Mitarbeiter 81</p> <p>Eine quantitative Fallstudie: Konzentrieren Sie sich auf Deployments 83</p> <p><b>Teil II: Eine Pipeline einrichten 85</b></p> <p><b>Kapitel 6 Den neuen Entwicklungslebenszyklus übernehmen</b> <b>87</b></p> <p>Alle an einen Tisch bitten 87</p> <p>Prozesse umwandeln: Von der Linie zum Kreis 88</p> <p>Administrative Aufgaben »nach links« schieben: über Infrastruktur nachdenken 92</p> <p>Auch Deployments nach links verschieben 93</p> <p>Simulation der Produktion durch Staging 93</p> <p><b>Kapitel 7 Vorausplanen</b> <b>95</b></p> <p>Über das Agile-Modell hinausgehen 95</p> <p>Herausforderungen vorhersehen 97</p> <p>Herausforderungen und Einschränkungen bei Projekten identifizieren 98</p> <p>Zeitplan 98</p> <p>Budget 99</p> <p>Anforderungen bestimmen 99</p> <p>Ein MVP entwickeln 100</p> <p>Herausfinden, welches Problem Ihr MVP lösen muss 101</p> <p>Herausfinden, wer Ihre Kunden sind 102</p> <p>Die Konkurrenz unter die Lupe nehmen 102</p> <p>Funktionen priorisieren 103</p> <p>Die Benutzererfahrung gestalten 104</p> <p>Ihre Hypothese überprüfen 105</p> <p>Beta-Release, ja oder nein? 106</p> <p>Personas entwerfen, um Ihre Kunden besser kennenzulernen 106</p> <p>Was ist eine Persona? 107</p> <p>Eine Persona ausarbeiten 107</p> <p><b>Kapitel 8 Aus der DevOps-Perspektive designen</b> <b>109</b></p> <p>Ihr Design konstruieren 110</p> <p>Für DevOps gestalten 112</p> <p>Softwareentwicklung für den Wandel 112</p> <p>Software kontinuierlich verbessern 113</p> <p>Ihre Software dokumentieren 114</p> <p>Codearchitektur für die sechs Leistungsmerkmale von DevOps 115</p> <p>Wartungsfreundlichkeit 116</p> <p>Skalierbarkeit 116</p> <p>Sicherheit 118</p> <p>Benutzerfreundlichkeit 119</p> <p>Zuverlässigkeit 120</p> <p>Flexibilität 120</p> <p>Designentscheidungen dokumentieren 121</p> <p>Fallstricke bei der Architektur vermeiden 122</p> <p><b>Kapitel 9 Code entwickeln</b> <b>125</b></p> <p>Kommunikation rund um den Code 125</p> <p>Für den Fehlerfall entwickeln 128</p> <p>Wartungsfreundlichen Code schreiben 128</p> <p>Code testen 129</p> <p>Code debuggen 129</p> <p>Code protokollieren 130</p> <p>Unveränderbaren Code schreiben 130</p> <p>Lesbaren Code erstellen 131</p> <p>Programmiermuster 131</p> <p>Objektorientierte Programmierung 131</p> <p>Funktionale Programmierung 132</p> <p>Eine Programmiersprache wählen 132</p> <p>Anti-Patterns vermeiden 133</p> <p>Nach DevOps-Prinzipien entwickeln 134</p> <p>Sauberen Code schreiben 135</p> <p>Das Geschäft verstehen 135</p> <p>Anderen zuhören 135</p> <p>Die richtigen Schwerpunkte setzen 136</p> <p>Die Komfortzone verlassen 136</p> <p>Gute Vorgehensweisen etablieren 137</p> <p>Ordnung im Quellcode halten 137</p> <p>Tests schreiben 137</p> <p>Features dokumentieren 138</p> <p>Legen Sie den Kollegen Ihren Code zur Kontrolle vor 139</p> <p><b>Kapitel 10 Tests vor der Veröffentlichung</b> <b>141</b></p> <p>Warum Tests? 141</p> <p>Automatisierte Tests sind nicht optional 142</p> <p>Testen in verschiedenen Umgebungen 143</p> <p>Lokale Umgebung 144</p> <p>Entwicklungsumgebung 144</p> <p>Testumgebung 145</p> <p>Staging-Umgebung 146</p> <p>Produktionsumgebung 146</p> <p>Über den Komponententest hinaus 147</p> <p>Komponententests: Es lebt! 147</p> <p>Integrationstests: Spielen alle Teile zusammen? 148</p> <p>Regressionstests: Verhält sich der Code nach</p> <p>Änderungen noch genauso? 148</p> <p>Visuelle Tests: Sieht alles noch genauso aus? 148</p> <p>Performance-Tests 149</p> <p>Kontinuierliches Testen 149</p> <p><b>Kapitel 11 Ein Produkt deployen 151</b></p> <p>Code freigeben 151</p> <p>Kontinuierliche Integration und Auslieferung 152</p> <p>Von CI/CD profitieren 152</p> <p>CI/CD implementieren 153</p> <p>Kontinuierliche Integration 153</p> <p>Kontinuierliche Bereitstellung 154</p> <p>Kontinuierliches Deployment 154</p> <p>Deployments managen 155</p> <p>Richtig automatisieren 155</p> <p>Versionierung 156</p> <p>Fehler abmildern 158</p> <p>Rollbacks 158</p> <p>Flucht nach vorne 159</p> <p>Deployments demokratisieren 159</p> <p>Einen Deployment-Stil wählen 160</p> <p>Blue-Green-Deployment 160</p> <p>Schrödingers Kanarienvogel: Der Deploy ist tot (oder doch nicht?) 162</p> <p>Rolling Release 163</p> <p>Feature-Flags 165</p> <p>Ihre Systeme überwachen 165</p> <p>Telemetrie verstehen 166</p> <p>Verhalten aufzeichnen 166</p> <p>SLAs, SLIs und SLOs 167</p> <p><b>Teil III: Den Kreis schließen 169</b></p> <p><b>Kapitel 12 Rapid Iteration implementieren 171</b></p> <p>Wichtige Aufgaben zuerst 172</p> <p>Wichtig und dringend 173</p> <p>Wichtig, nicht dringend 173</p> <p>Dringend, nicht wichtig 175</p> <p>Weder wichtig noch dringend 176</p> <p>Schneller werden 177</p> <p>Die Performance verbessern 180</p> <p>Unvollkommenheit akzeptieren 181</p> <p>Kleine Teams gestalten 181</p> <p>Ihre Arbeit nachverfolgen 182</p> <p>Reibung verringern 183</p> <p>Warnmeldungen menschlicher gestalten 183</p> <p><b>Kapitel 13 Feedback-Schleifen rund um den Kunden einrichten</b> <b>185</b></p> <p>Einen Kundenrückmeldungsprozess erstellen 186</p> <p>Eine Feedback-Schleife erstellen 187</p> <p>Empfangen 187</p> <p>Analysieren 188</p> <p>Kommunizieren 188</p> <p>Verändern 189</p> <p>Feedback sammeln 190</p> <p>Umfragen zur Zufriedenheit 190</p> <p>Fallstudien 191</p> <p>Dogfooding: Selbstanwendung 191</p> <p>Um kontinuierliche Rückmeldung bitten 193</p> <p>Promotorenüberhang: Net Promoter Score (NPS) 194</p> <p>Einen Rhythmus finden 194</p> <p><b>Kapitel 14 DevOps-Teams zusammenstellen</b> <b>197</b></p> <p>DevOps-Teams formen 197</p> <p>So funktionieren funktionale Teams 198</p> <p>Ein spezielles DevOps-Team bereitstellen 199</p> <p>Funktionsübergreifende Produktteams bilden 200</p> <p>Schnell zum Vorstellungsgespräch (aber nicht zu schnell) 202</p> <p>Eine Stellenbezeichnung wählen 203</p> <p>Die Personalbeschaffung endet nie 205</p> <p>Die richtigen Leute finden 206</p> <p>Hervorragende Kandidaten weiterreichen 206</p> <p>Technische Fähigkeiten bewerten 207</p> <p>Überarbeitetes Whiteboarding 207</p> <p>Hausaufgaben 208</p> <p>Code-Reviews 209</p> <p>Schnell feuern 209</p> <p>Das Ekel 210</p> <p>Der Märtyrer 211</p> <p>Der Underperformer 211</p> <p><b>Kapitel 15 Eigenverantwortung für die Entwickler</b> <b>213</b></p> <p>Entwicklungsteams mit DevOps skalieren 213</p> <p>Drei Phasen eines Unternehmens 214</p> <p>Start-up 215</p> <p>Etabliertes Start-up oder mittelständisches Unternehmen 215</p> <p>Großunternehmen 216</p> <p>Die Mühen der Ebene 218</p> <p>Die Motivation ergründen 219</p> <p>Motivation für Entwickler 220</p> <p>Abhängigkeit von extrinsischen Belohnungen vermeiden 220</p> <p>Autonomie 221</p> <p>Meisterschaft 221</p> <p>Sinnhaftigkeit 222</p> <p>Arbeit zum Vergnügen machen 222</p> <p>Den Leuten die Möglichkeit geben, ihre Teams auszuwählen 223</p> <p>Motivation messen 223</p> <p><b>Teil IV: Kaizen: die Kunst der kontinuierlichen Verbesserung 225</b></p> <p><b>Kapitel 16 Erfolgreich mit Fehlschlägen umgehen</b> <b>227</b></p> <p>Schnelles Scheitern im Tech-Bereich 227</p> <p>Sicheres Scheitern 228</p> <p>Fehlerausbreitung einschränken 228</p> <p>Menschliches Versagen akzeptieren – und keine Schuldzuweisungen! 229</p> <p>Gut scheitern 230</p> <p>Wachstumsmentalität 230</p> <p>Die Freiheit zum Scheitern schaffen 231</p> <p><b>Kapitel 17 Auf Zwischenfälle vorbereitet sein</b> <b>235</b></p> <p>Mit Automatisierung gegen »menschliches Versagen« ankämpfen 236</p> <p>Fokussierung auf Systeme: realistische Automatisierung 237</p> <p>Mit Automatisierungstools Probleme bei der</p> <p>Codeintegration vermeiden 238</p> <p>Deployments und Infrastruktur managen 240</p> <p>Overengineering eingrenzen 240</p> <p>Bereitschaftsdienste menschlicher gestalten 242</p> <p>Wenn Bereitschaftsdienste unmenschlich werden 242</p> <p>Humane Erwartungen an den Bereitschaftsdienst 243</p> <p>Notfallmanagement 245</p> <p>Beständigkeit zum Ziel machen 246</p> <p>Standardverfahren einführen 247</p> <p>Ein realistisches Budget ansetzen 248</p> <p>Reaktion auf Vorfälle vereinfachen 248</p> <p>Auf eine ungeplante Unterbrechung reagieren 249</p> <p>Fortschritt empirisch messen 253</p> <p>MTTR: Mean Time to Repair 253</p> <p>MTBF: Mean Time between Failures 254</p> <p>CPI: Cost per Incident 254</p> <p><b>Kapitel 18 Vorfälle nachträglich untersuchen</b> <b>255</b></p> <p>Über die Analyse der Grundursache hinaus 255</p> <p>Die einzelnen Phasen eines Vorfalls durchgehen 257</p> <p>Vorfälle erfolgreich nachbereiten 258</p> <p>Das Treffen sofort anberaumen 258</p> <p>Alle miteinbeziehen 258</p> <p>Schuldzuweisungen vermeiden 258</p> <p>Den zeitlichen Ablauf betrachten 259</p> <p>Schwierige Fragen stellen 260</p> <p>Im Nachhinein sind Sie immer schlauer 261</p> <p>Gesprächsprotokolle anfertigen 262</p> <p>Einen Plan erstellen 262</p> <p><b>Teil V: Werkzeuge für Ihre DevOps-Praxis 263</b></p> <p><b>Kapitel 19 Neue Tools 265</b></p> <p>Integration von Open-Source-Software 265</p> <p>Open Computing als Innovationstreiber 266</p> <p>Open-Source-Lizenzierung 267</p> <p>Entscheidung für Open Source 268</p> <p>Auf neue Sprachen umstellen 270</p> <p>Compiler- und Interpretersprachen 270</p> <p>Parallelisierung und Multithreading 271</p> <p>Funktionale Programmierung 272</p> <p>Speicherverwaltung 273</p> <p>Sprachen sinnvoll auswählen 273</p> <p><b>Kapitel 20 Verteilte Systeme</b> <b>277</b></p> <p>Monolithen und Microservices 278</p> <p>Zuerst eine monolithische Architektur wählen 279</p> <p>Umstieg auf Microservices 280</p> <p>Großartige APIs entwickeln 281</p> <p>Was ist eine API? 282</p> <p>Auf einheitliches Design achten 282</p> <p>Container: Viel mehr als virtuelle Maschinen 285</p> <p>Container und Images verstehen 286</p> <p>Microservices in Containern deployen 286</p> <p>Orchestrierer vergleichen: Die Harmonisierung des Schwarms 288</p> <p>Container konfigurieren 290</p> <p>Container überwachen: Halten Sie sie am Leben, bis Sie sie töten 291</p> <p>Container absichern: Diese Kisten brauchen ein Schloss 292</p> <p><b>Kapitel 21 Migration in die Cloud</b> <b>295</b></p> <p>DevOps in der Cloud 295</p> <p>Ihre DevOps-Kultur in die Cloud bringen 296</p> <p>Lernen durch Übernahme 296</p> <p>Von Cloud-Diensten profitieren 297</p> <p>Arten von Clouds 298</p> <p>Public Cloud 298</p> <p>Private Cloud 299</p> <p>Hybrid Cloud 299</p> <p>Cloud as a Service 299</p> <p>Infrastructure as a Service 300</p> <p>Platform as a Service 300</p> <p>Software as a Service 301</p> <p>Den besten Cloud-Anbieter wählen 301</p> <p>Amazon Web Services (AWS) 302</p> <p>Microsoft Azure 302</p> <p>Google Cloud Platform (GCP) 303</p> <p>Tools und Services in der Cloud finden 303</p> <p><b>Teil VI: Der Top-Ten-Teil 307</b></p> <p><b>Kapitel 22 (Mehr als) 10 wichtige Gründe für DevOps</b> <b>309</b></p> <p>Beständigen Wandel akzeptieren 309</p> <p>Die Cloud nutzen 310</p> <p>Die Besten einstellen 310</p> <p>Wettbewerbsfähig bleiben 311</p> <p>Menschliche Probleme lösen 311</p> <p>Mitarbeiter fordern 312</p> <p>Brücken schlagen 312</p> <p>Gut scheitern 312</p> <p>Kontinuierliche Verbesserung 313</p> <p>Mühsame Arbeiten automatisieren 314</p> <p>Auslieferung beschleunigen 314</p> <p><b>Kapitel 23 Die zehn größten DevOps-Fallstricke 315</b></p> <p>Kultur vernachlässigen 315</p> <p>Nicht alle mitnehmen 316</p> <p>Anreize schlecht aufeinander abstimmen 316</p> <p>Stillschweigen 317</p> <p>Vergessen zu messen 318</p> <p>Micromanaging 318</p> <p>Zu schnell zu viel verändern 319</p> <p>Schlechte Werkzeugauswahl 319</p> <p>Angst vor Misserfolgen 320</p> <p>Zu hart sein 320</p> <p>Stichwortverzeichnis 323</p>

Emily Freeman ist Technologieexpertin, Geschichtenerzählerin und Unternehmensberaterin in einer Person. Sie ist Senior Cloud Advocate bei Microsoft und eine gefragte Referentin und Keynote-Speakerin bei DevOps-Veranstaltungen auf der ganzen Welt.

DE