Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Softwareentwicklung hat das mit dem Kinderkriegen gemeinsam: Die Wehen vor der Geburt sind schmerzhaft und schwierig, aber die Wehennach der Geburt sind die Zeit, in der du dich am meisten anstrengst. Dennoch wird in der Softwareentwicklung viel mehr Zeit damit verbracht, über die erste Phase zu sprechen als über die zweite, obwohl Schätzungen zufolge 40-90% der Gesamtkosten eines Systems nach der Geburt anfallen.1 Das gängige Industriemodell, das davon ausgeht, dass die eingesetzte Software in der Produktion "stabilisiert" wird und daher viel weniger Aufmerksamkeit von Softwareentwicklern benötigt, ist falsch. Wenn sich die Softwareentwicklung auf die Entwicklung und den Aufbau von Softwaresystemen konzentriert, muss es eine andere Disziplin geben, die sich auf den gesamten Lebenszyklus von Softwareobjekten konzentriert - von der Entwicklung über den Einsatz und den Betrieb bis hin zur Verbesserung und schließlich der friedlichen Stilllegung. Diese Disziplin nutzt - und muss - eine breite Palette von Fähigkeiten nutzen, hat aber andere Anliegen als andere Arten von Ingenieuren. Heute ist unsere Antwort die Disziplin, die Google Site Reliability Engineering nennt.

Was genau ist also Site Reliability Engineering (SRE)? Wir geben zu, dass es kein besonders klarer Name für das ist, was wir tun - so ziemlich jeder Site Reliability Engineer bei Google wird regelmäßig gefragt, was genau das ist und was er eigentlich macht.

Wenn man den Begriff ein wenig auspackt, sind SREs in erster LinieIngenieure. Wir wenden die Prinzipien der Informatik und des Ingenieurwesens auf die Gestaltung und Entwicklung von Computersystemen an, in der Regel großen, verteilten Systemen. Manchmal besteht unsere Aufgabe darin, gemeinsam mit unseren Kollegen aus der Produktentwicklung die Software für diese Systeme zu schreiben; manchmal ist es unsere Aufgabe, all die zusätzlichen Komponenten zu entwickeln, die diese Systeme benötigen, wie z. B. Backups oder Lastausgleich, die im Idealfall systemübergreifend wiederverwendet werden können; und manchmal ist es unsere Aufgabe, herauszufinden, wie man bestehende Lösungen auf neue Probleme anwenden kann.

Als Nächstes konzentrieren wir uns auf die Systemzuverlässigkeit. Ben Treynor Sloss, Googles VP für 24/7 Operations und Erfinder des Begriffs SRE, behauptet, dass Zuverlässigkeit die grundlegendste Eigenschaft eines jeden Produkts ist: Ein System ist nicht sehr nützlich, wenn niemand es benutzen kann! Weil Zuverlässigkeit2 so wichtig ist, konzentrieren sich SREs darauf, das Design und den Betrieb von Systemen zu verbessern, um sie skalierbarer, zuverlässiger und effizienter zu machen. Wir investieren unsere Bemühungen in diese Richtung jedoch nur bis zu einem gewissen Punkt: Wenn die Systeme "zuverlässig genug" sind, investieren wir unsere Anstrengungen stattdessen in zusätzliche Funktionen oder den Bau neuer Produkte.3

Und schließlich konzentrieren sich die SREs auf den Betrieb von Diensten, die auf unseren verteilten Computersystemen aufbauen, egal ob es sich dabei um die Speicherung von Daten im Weltmaßstab, E-Mail für Hunderte von Millionen Nutzern oder die Websuche handelt, mit der Google begann. Das "Site" in unserem Namen bezog sich ursprünglich auf die Aufgabe von SRE, die Website google.com am Laufen zu halten. Inzwischen betreiben wir jedoch viele weitere Dienste, von denen viele keine Websites sind - von der internen Infrastruktur wie Bigtable bis hin zu Produkten für externe Entwickler wie der Google Cloud Platform.

Obwohl wir SRE als eine breit gefächerte Disziplin dargestellt haben, ist es keine Überraschung, dass sie in der schnelllebigen Welt der Webdienste entstanden ist und vielleicht auch etwas mit den Besonderheiten unserer Infrastruktur zu tun hat. Es ist auch keine Überraschung, dass von allen Merkmalen der Software, denen wir nach der Bereitstellung besondere Aufmerksamkeit widmen können, die Zuverlässigkeit für uns an erster Stelle steht.4 Die Domäne der Webservices ist eine natürliche Plattform für unseren Ansatz, weil der Prozess der Verbesserung und Änderung von serverseitiger Software vergleichsweise begrenzt ist und weil die Verwaltung von Änderungen selbst so eng mit Fehlern aller Art verbunden ist.

Obwohl sie bei Google und in der Web-Community im Allgemeinen entstanden ist, sind wir der Meinung, dass diese Disziplin auch auf andere Communities und Organisationen übertragbar ist. In diesem Buch versuchen wir zu erklären, wie wir vorgehen, damit andere Organisationen von unseren Erfahrungen profitieren können und damit wir unsere Rolle und die Bedeutung des Begriffs besser definieren können. Zu diesem Zweck haben wir das Buch so gegliedert, dass allgemeine Grundsätze und spezifischere Praktiken nach Möglichkeit voneinander getrennt sind. Und wo es angebracht ist, ein bestimmtes Thema mit Google-spezifischen Informationen zu erörtern, vertrauen wir darauf, dass der Leser uns das nachsehen wird und sich nicht scheut, nützliche Schlussfolgerungen für sein eigenes Umfeld zu ziehen.

Wir haben auch einige Orientierungshilfen zur Verfügung gestellt - eine Beschreibung der Produktionsumgebung von Google und eine Zuordnung zwischen unserer internen Software und öffentlich verfügbarer Software -, die helfen sollen, das Gesagte in den richtigen Kontext zu stellen und es direkter nutzbar zu machen.

Letztendlich ist eine stärker auf Zuverlässigkeit ausgerichtete Softwareentwicklung und Systemtechnik natürlich von Natur aus gut. Wir sind uns jedoch bewusst, dass sich kleinere Unternehmen fragen, wie sie die hier dargestellten Erfahrungen am besten nutzen können: Ähnlich wie bei der Sicherheit gilt: Je früher du dich um Zuverlässigkeit kümmerst, desto besser. Das bedeutet: Auch wenn ein kleines Unternehmen viele dringende Probleme hat und die Software-Entscheidungen, die du triffst, sich von denen unterscheiden, die Google getroffen hat, lohnt es sich, frühzeitig eine leichtgewichtige Zuverlässigkeitsunterstützung einzurichten, denn es ist weniger kostspielig, eine Struktur später zu erweitern, als eine nicht vorhandene einzuführen. Teil IV enthält eine Reihe bewährter Methoden für Schulungen, Kommunikation und Besprechungen, die sich bei uns bewährt haben und von denen viele auch in deinem Unternehmen sofort anwendbar sein sollten.

Aber in Größenordnungen zwischen einem Startup und einem multinationalen Unternehmen gibt es wahrscheinlich schon jemanden in deinem Unternehmen, der SRE-Arbeit leistet, ohne dass es unbedingt so genannt oder als solches anerkannt wird. Eine andere Möglichkeit, die Zuverlässigkeit deines Unternehmens zu verbessern, besteht darin, diese Arbeit offiziell anzuerkennen oder diese Leute ausfindig zu machen und das, was sie tun, zu fördern und zu belohnen. Es sind Menschen, die an der Schwelle zwischen einer Weltanschauung und einer anderen stehen: wie Newton, der manchmal nicht der erste Physiker, sondern der letzte Alchemist der Welt genannt wird.

Und wenn man die Geschichte betrachtet, wer könnte dann rückblickend der erste SRE sein?

Wir denken gerne, dass Margaret Hamilton, die als Leihgabe des MIT am Apollo-Programm arbeitete, alle wichtigen Eigenschaften der ersten SRE hatte.5 In ihren eigenen Worten: "Teil der Kultur war es, von jedem und allem zu lernen, auch von dem, was man am wenigsten erwarten würde.

Ein Beispiel dafür war, als ihre kleine Tochter Lauren eines Tages mit ihr zur Arbeit kam, während einige aus dem Team Missionsszenarien auf dem Hybrid-Simulationscomputer durchspielten. Wie es kleine Kinder nun mal tun, ging Lauren auf Entdeckungsreise und brachte eine "Mission" zum Absturz, indem sie die DSKY-Tasten auf unerwartete Weise auswählte und das Team darauf aufmerksam machte, was passieren würde, wenn ein echter Astronaut während einer echten Mission versehentlich das Vorstartprogramm P01 auswählt. (Ein versehentlicher Start von P01 bei einer echten Mission wäre ein großes Problem, da es die Navigationsdaten löscht und der Computer nicht in der Lage war, das Raumschiff ohne Navigationsdaten zu steuern).

Mit dem Instinkt einer SRE reichte Margaret einen Antrag auf Programmänderung ein, um einen speziellen Fehlerprüfungscode in die Flugsoftware einzufügen, falls ein Astronaut während des Fluges versehentlich P01 auswählen sollte. Die höheren Stellen bei der NASA hielten diesen Schritt jedoch für unnötig: Das konnte natürlich nie passieren! Anstatt also einen Fehlerprüfungscode hinzuzufügen, aktualisierte Margaret die Dokumentation der Missionsspezifikationen und sagte: "Wähle nicht P01 während des Fluges." (Offenbar fanden viele Projektmitarbeiter die Aktualisierung amüsant, denn ihnen war immer wieder gesagt worden, dass Astronauten keine Fehler machen würden - schließlich waren sie darauf trainiert, perfekt zu sein.)

Die von Margaret vorgeschlagene Schutzmaßnahme wurde erst bei der nächsten Mission, Apollo 8, nur wenige Tage nach der Aktualisierung der Spezifikationen, als unnötig angesehen. Während des Midcourse am vierten Flugtag mit den Astronauten Jim Lovell, William Anders und Frank Borman an Bord wählte Jim Lovell versehentlich P01 aus - zufälligerweise am ersten Weihnachtstag - und verursachte damit großes Chaos für alle Beteiligten. Das war ein kritisches Problem, denn ohne einen Workaround bedeutete das Fehlen von Navigationsdaten, dass die Astronauten niemals nach Hause kommen würden. Glücklicherweise wurde in der aktualisierten Dokumentation ausdrücklich auf diese Möglichkeit hingewiesen, und es war von unschätzbarem Wert, dass wir herausfinden konnten, wie wir brauchbare Daten hochladen und die Mission wiederherstellen konnten, ohne viel Zeit zu verlieren.

Wie Margaret sagt, "reichte ein gründliches Verständnis der Bedienung der Systeme nicht aus, um menschliche Fehler zu vermeiden", und der Änderungsantrag zur Aufnahme von Software zur Fehlererkennung und -behebung in das Vorstartprogramm P01 wurde kurz darauf genehmigt.

Obwohl der Apollo-8-Zwischenfall schon Jahrzehnte zurückliegt, gibt es vieles in den vorangegangenen Abschnitten, das für das Leben von Ingenieurinnen und Ingenieuren heute direkt relevant ist, und vieles, das auch in Zukunft direkt relevant sein wird. Für die Systeme, um die du dich kümmerst, für die Gruppen, in denen du arbeitest, oder für die Organisationen, die du aufbaust, solltest du dir den SRE-Weg vor Augen halten: Gründlichkeit und Hingabe, der Glaube an den Wert von Vorbereitung und Dokumentation und ein Bewusstsein dafür, was schiefgehen könnte, gepaart mit dem starken Wunsch, es zu verhindern. Willkommen in unserem aufstrebenden Beruf!

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Constant width bold

Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

Tipp

Dieses Element steht für einen Tipp oder eine Anregung.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Warnung

Dieses Element weist auf eine Warnung oder einen Warnhinweis hin.

Code-Beispiele verwenden

Ergänzendes Material findest du unter https://g.co/SREBook.

Dieses Buch soll dir helfen, deine Arbeit zu erledigen. Wenn in diesem Buch Beispielcode angeboten wird, darfst du ihn in deinen Programmen und deiner Dokumentation verwenden. Du musst uns nicht um Erlaubnis fragen, es sei denn, du reproduzierst einen großen Teil des Codes. Wenn du zum Beispiel ein Programm schreibst, das mehrere Teile des Codes aus diesem Buch verwendet, brauchst du keine Erlaubnis. Wenn du eine CD-ROM mit Beispielen aus den O'Reilly-Büchern verkaufst oder verteilst, ist eine Genehmigung erforderlich. Die Beantwortung einer Frage mit einem Zitat aus diesem Buch und einem Beispielcode erfordert keine Genehmigung. Wenn du einen großen Teil des Beispielcodes aus diesem Buch in die Dokumentation deines Produkts aufnimmst, ist eine Erlaubnis erforderlich.

Wir schätzen die Namensnennung, verlangen sie aber nicht. Eine Quellenangabe umfasst normalerweise den Titel, den Autor, den Verlag und die ISBN. Ein Beispiel: "Site Reliability Engineering, herausgegeben von Betsy Beyer, Chris Jones, Jennifer Petoff und Niall Richard Murphy (O'Reilly). Copyright 2016 Google, Inc., 978-1-491-92912-4."

Wenn du der Meinung bist, dass die Verwendung von Code-Beispielen nicht unter die Fair-Use-Regelung oder die oben genannte Erlaubnis fällt, kannst du uns gerne unter kontaktieren

O'Reilly Safari

Hinweis

Safari (ehemals Safari Books Online) ist eine mitgliedschaftsbasierte Schulungs- und Nachschlageplattform für Unternehmen, Behörden, Lehrkräfte und Einzelpersonen.

Mitglieder haben Zugang zu Tausenden von Büchern, Schulungsvideos, Lernpfaden, interaktiven Tutorials und kuratierten Playlists von über 250 Verlagen, darunter O'Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett und Course Technology, um nur einige zu nennen.

Weitere Informationen erhältst du unter http://oreilly.com/safari.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

  • O'Reilly Media, Inc.
  • 1005 Gravenstein Highway Nord
  • Sebastopol, CA 95472
  • 800-998-9938 (in den Vereinigten Staaten oder Kanada)
  • 707-829-0515 (international oder lokal)
  • 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter http://bit.ly/site-reliability-engineering aufrufen .

Wenn du Kommentare oder technische Fragen zu diesem Buch stellen möchtest, sende eine E-Mail an

Weitere Informationen zu unseren Büchern, Kursen, Konferenzen und Neuigkeiten findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia

Danksagungen

Dieses Buch wäre ohne den unermüdlichen Einsatz unserer Autoren und technischen Redakteure nicht möglich gewesen. Wir möchten uns auch bei den folgenden internen Prüfern für ihr besonders wertvolles Feedback bedanken: Alex Matey, Dermot Duffy, JC van Winkel, John T. Reese, Michael O'Reilly, Steve Carstensen und Todd Underwood. Ben Lutch und Ben Treynor Sloss waren die Sponsoren dieses Buches bei Google. Ihr Glaube an dieses Projekt und ihre Bereitschaft, unsere Erkenntnisse über den Betrieb großer Dienste mit uns zu teilen, waren entscheidend für die Entstehung dieses Buches.

Unser besonderer Dank gilt Rik Farrow, dem Herausgeber von ;login:, für die Zusammenarbeit mit uns bei einer Reihe von Beiträgen zur Vorveröffentlichung über USENIX.

Auch wenn die Autoren in jedem Kapitel namentlich genannt werden, möchten wir uns die Zeit nehmen, um diejenigen zu würdigen, die mit ihren Beiträgen, Diskussionen und Rezensionen zu jedem Kapitel beigetragen haben.

Kapitel 3: Abe Rahey, Ben Treynor Sloss, Brian Stoler, Dave O'Connor, David Besbris, Jill Alvidrez, Mike Curtis, Nancy Chang, Tammy Capistrant, Tom Limoncelli

Kapitel 5: Cody Smith, George Sadlier, Laurence Berland, Marc Alvidrez, Patrick Stahlberg, Peter Duff, Pim van Pelt, Ryan Anderson, Sabrina Farmer, Seth Hettich

Kapitel 6: Mike Curtis, Jamie Wilkinson, Seth Hettich

Kapitel 8: David Schnur, JT Goldstone, Marc Alvidrez, Marcus Lara-Reinhold, Noah Maxwell, Peter Dinges, Sumitran Raghunathan, Yutong Cho

Kapitel 9: Ryan Anderson

Kapitel 10: Jules Anderson, Max Luebbe, Mikel Mcdaniel, Raul Vera, Seth Hettich

Kapitel 11: Andrew Stribblehill, Richard Woodbury

Kapitel 12: Charles Stephen Gunn, John Hedditch, Peter Nuttall, Rob Ewaschuk, Sam Greenfield

Kapitel 13: Jelena Oertel, Kripa Krishnan, Sergio Salvi, Tim Craig

Kapitel 14: Amy Zhou, Carla Geisser, Grainne Sheerin, Hildo Biersma, Jelena Oertel, Perry Lorier, Rune Kristian Viken

Kapitel 15: Dan Wu, Heather Sherman, Jared Brick, Mike Louer, Štěpán Davidovič, Tim Craig

Kapitel 16: Andrew Stribblehill, Richard Woodbury

Kapitel 17: Isaac Clerencia, Marc Alvidrez

Kapitel 18: Ulric Longyear

Kapitel 19: Debashish Chatterjee, Perry Lorier

Kapitel 20 und 21: Adam Fletcher, Christoph Pfisterer, Lukáš Ježek, Manjot Pahwa, Micha Riser, Noah Fiedel, Pavel Herrmann, Paweł Zuzelski, Perry Lorier, Ralf Wildenhues, Tudor-Ioan Salomie, Witold Baryluk

Kapitel 22: Mike Curtis, Ryan Anderson

Kapitel 23: Ananth Shrinivas, Mike Burrows

Kapitel 24: Ben Fried, Derek Jackson, Gabe Krabbe, Laura Nolan, Seth Hettich

Kapitel 25: Abdulrahman Salem, Alex Perry, Arnar Mar Hrafnkelsson, Dieter Pearcey, Dylan Curley, Eivind Eklund, Eric Veach, Graham Poulter, Ingvar Mattsson, John Looney, Ken Grant, Michelle Duffy, Mike Hochberg, Will Robinson

Kapitel 26: Corey Vickrey, Dan Ardelean, Disney Luangsisongkham, Gordon Prioreschi, Kristina Bennett, Liang Lin, Michael Kelly, Sergey Ivanyuk

Kapitel 27: Vivek Rau

Kapitel 28: Melissa Binde, Perry Lorier, Preston Yoshioka

Kapitel 29: Ben Lutch, Carla Geisser, Dzevad Trumic, John Turek, Matt Brown

Kapitel 30: Charles Stephen Gunn, Chris Heiser, Max Luebbe, Sam Greenfield

Kapitel 31: Alex Kehlenbeck, Jeromy Carriere, Joel Becker, Sowmya Vijayaraghavan, Trevor Mattson-Hamilton

Kapitel 32: Seth Hettich

Kapitel 33: Adrian Hilton, Brad Kratochvil, Charles Ballowe, Dan Sheridan, Eddie Kennedy, Erik Gross, Gus Hartmann, Jackson Stone, Jeff Stevenson, John Li, Kevin Greer, Matt Toia, Michael Haynie, Mike Doherty, Peter Dahl, Ron Heiby

Wir danken auch den folgenden Personen, die entweder wichtiges Material zur Verfügung gestellt haben, hervorragende Arbeit bei der Durchsicht geleistet haben, sich zu Interviews bereit erklärt haben, wichtiges Fachwissen oder Ressourcen zur Verfügung gestellt haben oder auf andere Weise einen hervorragenden Einfluss auf diese Arbeit hatten:

Abe Hassan, Adam Rogoyski, Alex Hidalgo, Amaya Booker, Andrew Fikes, Andrew Hurst, Ariel Goh, Ashleigh Rentz, Ayman Hourieh, Barclay Osborn, Ben Appleton, Ben Love, Ben Winslow, Bernhard Beck, Bill Duane, Bill Patry, Blair Zajac, Bob Gruber, Brian Gustafson, Bruce Murphy, Buck Clay, Cedric Cellier, Chiho Saito, Chris Carlon, Christopher Hahn, Chris Kennelly, Chris Taylor, Ciara Kamahele-Sanfratello, Colin Phipps, Colm Buckley, Craig Paterson, Daniel Eisenbud, Daniel V. Klein, Daniel Spoonhower, Dan Watson, Dave Phillips, David Hixson, Dina Betser, Doron Meyer, Dmitry Fedoruk, Eric Grosse, Eric Schrock, Filip Zyzniewski, Francis Tang, Gary Arneson, Georgina Wilcox, Gretta Bartels, Gustavo Franco, Harald Wagener, Healfdene Goguen, Hugo Santos, Hyrum Wright, Ian Gulliver, Jakub Turski, James Chivers, James O'Kane, James Youngman, Jan Monsch, Jason Parker-Burlingham, Jason Petsod, Jeffry McNeil, Jeff Dean, Jeff Peck, Jennifer Mace, Jerry Cen, Jess Frame, John Brady, John Gunderman, John Kochmar, John Tobin, Jordyn Buchanan, Joseph Bironas, Julio Merino, Julius Plenz, Kate Ward, Kathy Polizzi, Katrina Sostek, Kenn Hamm, Kirk Russell, Kripa Krishnan, Larry Greenfield, Lea Oliveira, Luca Cittadini, Lucas Pereira, Magnus Ringman, Mahesh Palekar, Marco Paganini, Mario Bonilla, Mathew Mills, Mathew Monroe, Matt D. Brown, Matt Proud, Max Saltonstall, Michal Jaszczyk, Mihai Bivol, Misha Brukman, Olivier Oansaldi, Patrick Bernier, Pierre Palatin, Rob Shanley, Robert van Gent, Rory Ward, Rui Zhang-Shen, Salim Virji, Sanjay Ghemawat, Sarah Coty, Sean Dorward, Sean Quinlan, Sean Sechrist, Shari Trumbo-McHenry, Shawn Morrissey, Shun-Tak Leung, Stan Jedrus, Stefano Lattarini, Steven Schirripa, Tanya Reilly, Terry Bolt, Tim Chaplin, Toby Weingartner, Tom Black, Udi Meiri, Victor Terron, Vlad Grama, Wes Hertlein, und Zoltan Egyed.

Wir sind sehr dankbar für das aufmerksame und ausführliche Feedback, das wir von externen Gutachtern erhalten haben: Andrew Fong, Björn Rabenstein, Charles Border, David Blank-Edelman, Frossie Economou, James Meickle, Josh Ryder, Mark Burgess und Russ Allbery.

Unser besonderer Dank gilt Cian Synnott, dem ursprünglichen Mitglied des Buchteams und Mitverschwörer, der Google vor der Fertigstellung dieses Projekts verlassen hat, aber einen großen Einfluss auf das Projekt hatte, sowie Margaret Hamilton, die uns freundlicherweise erlaubt hat, ihre Geschichte in unserem Vorwort zu erwähnen. Außerdem möchten wir uns bei Shylaja Nukala bedanken, die großzügig die Zeit ihrer technischen Redakteure zur Verfügung gestellt hat und deren notwendige und geschätzte Arbeit von ganzem Herzen unterstützt hat.

Die Redakteure möchten sich auch persönlich bei den folgenden Personen bedanken:

Betsy Beyer: An meine Großmutter (meine persönliche Heldin), die mich mit endlosen Telefongesprächen und Popcorn aufgemuntert hat, und an Riba, die mich mit den Jogginghosen versorgt hat, die ich für mehrere lange Nächte brauchte. Das alles natürlich zusätzlich zu den SRE-Allstars, die wirklich wunderbare Mitarbeiter waren.

Chris Jones: An Michelle, weil sie mich vor einem kriminellen Leben auf hoher See bewahrt hat und für ihre unheimliche Fähigkeit, Manzanas an unerwarteten Orten zu finden, und an alle, die mich im Laufe der Jahre über Technik unterrichtet haben.

Jennifer Petoff: Meinem Mann Scott, der mich während des zweijährigen Prozesses, dieses Buch zu schreiben, unglaublich unterstützt hat und die Redakteure auf unserer "Dessertinsel" mit reichlich Zucker versorgt hat.

Niall Murphy: An Léan, Oisín und Fiachra, die jahrelang wesentlich geduldiger waren, als ich es von einem wesentlich schusseligeren Vater und Ehemann als gewöhnlich erwarten durfte. An Dermot für das Versetzungsangebot.

1 Allein die Tatsache, dass diese Schätzungen so stark voneinander abweichen, sagt schon etwas über die Softwareentwicklung als Disziplin aus, aber siehe z. B. [Gla02] für weitere Details.

2 Für unsere Zwecke ist Zuverlässigkeit "die Wahrscheinlichkeit, dass [ein System] eine geforderte Funktion unter festgelegten Bedingungen für eine festgelegte Zeitspanne ohne Ausfall erfüllt", in Anlehnung an die Definition in [Oco12].

3 Bei den Softwaresystemen, mit denen wir uns befassen, handelt es sich größtenteils um Websites und ähnliche Dienste; wir erörtern nicht die Zuverlässigkeitsprobleme von Software, die für Kernkraftwerke, Flugzeuge, medizinische Geräte oder andere sicherheitskritische Systeme bestimmt ist. Allerdings vergleichen wir in Kapitel 33 unsere Ansätze mit denen anderer Branchen.

4 Darin unterscheiden wir uns von dem Branchenbegriff DevOps, denn obwohl wir die Infrastruktur definitiv als Code betrachten, liegt unser Hauptaugenmerk auf der Zuverlässigkeit. Außerdem sind wir stark darauf ausgerichtet, die Notwendigkeit von Operationen zu beseitigen - siehe Kapitel 7 für weitere Details.

5 Neben dieser großartigen Geschichte hat sie auch einen großen Anteil daran, dass der Begriff "Softwareentwicklung" populär wurde.

Get Site Reliability Engineering now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial