Prefacio

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

La ingeniería de software tiene esto en común con tener hijos: el parto antes del nacimiento es doloroso y difícil, pero el partodespués del nacimiento es donde realmente dedicas la mayor parte de tu esfuerzo. Sin embargo, la ingeniería de software como disciplina dedica mucho más tiempo a hablar del primer periodo que del segundo, a pesar de que se calcula que entre el 40 y el 90% de los costes totales de un sistema se producen después del nacimiento.1 El modelo popular de la industria que concibe el software desplegado y operativo como algo "estabilizado" en la producción, y que por tanto necesita mucha menos atención por parte de los ingenieros de software, es erróneo. A través de este prisma, vemos que si la ingeniería de software tiende a centrarse en el diseño y la construcción de sistemas de software, debe existir otra disciplina que se centre en todo el ciclo de vida de los objetos de software, desde el inicio, pasando por la implementación y el funcionamiento, el perfeccionamiento y el eventual desmantelamiento pacífico. Esta disciplina utiliza -y necesita utilizar- una amplia gama de competencias, pero tiene preocupaciones distintas de las de otros tipos de ingenieros. Hoy, nuestra respuesta es la disciplina que Google denomina Ingeniería de Fiabilidad del Sitio.

¿Qué es exactamente la Ingeniería de Fiabilidad del Sitio (SRE)? Admitimos que no es un nombre especialmente claro para lo que hacemos: a casi todos los ingenieros de fiabilidad de sitios de Google les preguntan a menudo qué es exactamente y qué hacen en realidad.

Desmenuzando un poco el término, ante todo, los SRE somosingenieros. Aplicamos los principios de la informática y la ingeniería al diseño y desarrollo de sistemas informáticos: generalmente, grandes sistemas distribuidos. A veces, nuestra tarea consiste en escribir el software para esos sistemas junto con nuestros homólogos de desarrollo de productos; a veces, nuestra tarea consiste en construir todas las piezas adicionales que esos sistemas necesitan, como copias de seguridad o equilibrio de carga, idealmente para que puedan reutilizarse en todos los sistemas; y a veces, nuestra tarea consiste en averiguar cómo aplicar las soluciones existentes a nuevos problemas.

A continuación, nos centramos en la fiabilidad del sistema. Ben Treynor Sloss, vicepresidente de Operaciones 24/7 de Google, creador del término SRE, afirma que la fiabilidad es la característica más fundamental de cualquier producto: ¡un sistema no es muy útil si nadie puede utilizarlo! Como la fiabilidad2 es tan crítica, las SRE se centran en encontrar formas de mejorar el diseño y el funcionamiento de los sistemas para hacerlos más escalables, más fiables y más eficientes. Sin embargo, sólo nos esforzamos en este sentido hasta cierto punto: cuando los sistemas son "suficientemente fiables", invertimos nuestros esfuerzos en añadir funciones o crear nuevos productos.3

Por último, los SRE se centran en el funcionamiento de los servicios construidos sobre nuestros sistemas informáticos distribuidos, ya sean servicios de almacenamiento a escala planetaria, de correo electrónico para cientos de millones de usuarios o el punto de partida de Google, la búsqueda web. El "sitio" de nuestro nombre se refería originalmente a la función de los SRE de mantener en funcionamiento el sitio web google.com, aunque ahora gestionamos muchos más servicios, muchos de los cuales no son en sí mismos sitios web, desde infraestructuras internas como Bigtable hasta productos para desarrolladores externos como Google Cloud Platform.

Aunque hemos representado la ESR como una disciplina amplia, no es ninguna sorpresa que surgiera en el vertiginoso mundo de los servicios web, y quizás en su origen deba algo a las peculiaridades de nuestra infraestructura. Tampoco sorprende que, de todas las características del software posteriores a la implementación a las que podríamos dedicar especial atención, la fiabilidad sea la que consideramos primordial.4 El dominio de los servicios web, tanto porque el proceso de mejora y cambio del software del lado del servidor es comparativamente contenido, como porque la gestión del cambio en sí está tan estrechamente unida a fallos de todo tipo, es una plataforma natural de la que podría surgir nuestro enfoque.

A pesar de haber surgido en Google, y en la comunidad web en general, creemos que esta disciplina tiene lecciones aplicables a otras comunidades y otras organizaciones. Este libro es un intento de explicar cómo hacemos las cosas: tanto para que otras organizaciones puedan hacer uso de lo que hemos aprendido, como para que podamos definir mejor la función y lo que significa el término. Para ello, hemos organizado el libro de modo que los principios generales y las prácticas más específicas estén separados siempre que sea posible, y cuando sea apropiado tratar un tema concreto con información específica de Google, confiamos en que el lector nos lo permita y no tenga miedo de sacar conclusiones útiles sobre su propio entorno.

También hemos proporcionado algún material orientativo -una descripción del entorno de producción de Google y un mapa entre parte de nuestro software interno y el software disponible públicamente- que debería ayudar a contextualizar lo que decimos y hacerlo más directamente utilizable.

En última instancia, por supuesto, una ingeniería de software y sistemas más orientada a la fiabilidad es intrínsecamente buena. Sin embargo, reconocemos que las organizaciones más pequeñas pueden preguntarse cómo pueden aprovechar mejor la experiencia aquí representada: al igual que ocurre con la seguridad, cuanto antes te preocupes por la fiabilidad, mejor. Esto implica que, aunque una organización pequeña tenga muchas preocupaciones acuciantes y las elecciones de software que haga puedan diferir de las que hizo Google, sigue mereciendo la pena poner en marcha un apoyo ligero a la fiabilidad desde el principio, porque es menos costoso ampliar una estructura más adelante que introducir una que no está presente. La Parte IV contiene una serie de buenas prácticas para la formación, la comunicación y las reuniones que nos han funcionado bien, muchas de las cuales deberían ser inmediatamente utilizables por tu organización.

Pero para tamaños entre una startup y una multinacional, probablemente ya haya alguien en tu organización que esté haciendo trabajo de SRE, sin que necesariamente se llame así, o se reconozca como tal. Otra forma de iniciar el camino hacia la mejora de la fiabilidad de tu organización es reconocer formalmente ese trabajo, o encontrar a esas personas y fomentar lo que hacen: recompensarlas. Son personas que se sitúan en la cúspide entre una forma de ver el mundo y otra: como Newton, a quien a veces no se llama el primer físico del mundo, sino el último alquimista del mundo.

Y desde un punto de vista histórico, ¿quién podría ser, mirando hacia atrás, la primera ESR?

Nos gusta pensar que Margaret Hamilton, que trabajaba en el programa Apolo cedida por el MIT, tenía todos los rasgos significativos de la primera ESR.5 En sus propias palabras, "parte de la cultura consistía en aprender de todos y de todo, incluso de lo que menos se esperaba".

Un ejemplo de ello fue cuando su hija Lauren vino a trabajar con ella un día, mientras algunos miembros del equipo ejecutaban escenarios de misión en el ordenador de simulación híbrido. Como hacen los niños pequeños, Lauren se puso a explorar, y provocó el fallo de una "misión" seleccionando las teclas DSKY de forma inesperada, alertando al equipo de lo que ocurriría si el programa de prelanzamiento, P01, fuera seleccionado inadvertidamente por un astronauta real durante una misión real, durante el curso medio real. (Lanzar P01 inadvertidamente en una misión real sería un gran problema, porque borra los datos de navegación, y el ordenador no estaba equipado para pilotar la nave sin datos de navegación).

Con los instintos de una SRE, Margaret presentó una solicitud de cambio de programa para añadir un código especial de comprobación de errores en el software de vuelo de a bordo, en caso de que un astronauta, por accidente, seleccionara P01 durante el vuelo. Pero los "altos cargos" de la NASA consideraron innecesaria esta medida: ¡por supuesto, eso nunca podría ocurrir! Así que, en lugar de añadir código de comprobación de errores, Margaret actualizó la documentación de las especificaciones de la misión para que dijera lo equivalente a "No seleccionar P01 durante el vuelo". (Al parecer, la actualización divirtió a muchos en el proyecto, a quienes se les había dicho muchas veces que los astronautas no cometerían errores; después de todo, se les entrenaba para ser perfectos).

Pues bien, la salvaguarda sugerida por Margaret sólo se consideró innecesaria hasta la siguiente misión, en el Apolo 8, sólo unos días después de la actualización de las especificaciones. Durante el curso medio del cuarto día de vuelo, con los astronautas Jim Lovell, William Anders y Frank Borman a bordo, Jim Lovell seleccionó P01 por error -como suele ocurrir, el día de Navidad-, creando muchos estragos para todos los implicados. Se trataba de un problema crítico, porque a falta de una solución, la ausencia de datos de navegación significaba que los astronautas nunca volverían a casa. Afortunadamente, la actualización de la documentación había advertido explícitamente de esta posibilidad, y fue inestimable para averiguar cómo cargar datos utilizables y recuperar la misión, sin mucho tiempo de sobra.

Como dice Margaret, "un conocimiento profundo del funcionamiento de los sistemas no bastaba para evitar los errores humanos", y poco después se aprobó la solicitud de cambio para añadir un software de detección y recuperación de errores al programa de prelanzamiento P01.

Aunque el incidente del Apolo 8 ocurrió hace décadas, hay mucho en los párrafos anteriores directamente relevante para la vida de los ingenieros de hoy, y mucho que seguirá siéndolo en el futuro. En consecuencia, para los sistemas de los que te ocupas, para los grupos en los que trabajas o para las organizaciones que estás construyendo, ten presente el Camino de la ESR: minuciosidad y dedicación, creencia en el valor de la preparación y la documentación, y conciencia de lo que podría ir mal, unida a un fuerte deseo de evitarlo. ¡Bienvenido a nuestra profesión emergente!

Convenciones utilizadas en este libro

En este libro se utilizan las siguientes convenciones tipográficas:

Cursiva

Indica nuevos términos, URL, direcciones de correo electrónico, nombres de archivo y extensiones de archivo.

Constant width

Se utiliza en los listados de programas, así como dentro de los párrafos para referirse a elementos del programa como nombres de variables o funciones, bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave.

Constant width bold

Muestra comandos u otros textos que deben ser tecleados literalmente por el usuario.

Constant width italic

Muestra el texto que debe sustituirse por valores proporcionados por el usuario o por valores determinados por el contexto.

Consejo

Este elemento significa un consejo o sugerencia.

Nota

Este elemento significa una nota general.

Advertencia

Este elemento indica una advertencia o precaución.

Utilizar ejemplos de código

El material complementario está disponible en https://g.co/SREBook.

Este libro está aquí para ayudarte a hacer tu trabajo. En general, si se ofrece código de ejemplo con este libro, puedes utilizarlo en tus programas y documentación. No es necesario que te pongas en contacto con nosotros para pedirnos permiso, a menos que estés reproduciendo una parte importante del código. Por ejemplo, escribir un programa que utilice varios trozos de código de este libro no requiere permiso. Vender o distribuir un CD-ROM de ejemplos de los libros de O'Reilly sí requiere permiso. Responder a una pregunta citando este libro y el código de ejemplo no requiere permiso. Incorporar una cantidad significativa de código de ejemplo de este libro en la documentación de tu producto sí requiere permiso.

Agradecemos, pero no exigimos, la atribución. Una atribución suele incluir el título, el autor, la editorial y el ISBN. Por ejemplo "Site Reliability Engineering, editado por Betsy Beyer, Chris Jones, Jennifer Petoff y Niall Richard Murphy (O'Reilly). Copyright 2016 Google, Inc., 978-1-491-92912-4".

Si crees que el uso que haces de los ejemplos de código no se ajusta al uso legítimo o al permiso concedido anteriormente, no dudes en ponerte en contacto con nosotros en

Safari O'Reilly

Nota

Safari (antes Safari Books Online) es una plataforma de formación y referencia basada en membresías para empresas, administraciones públicas, educadores y particulares.

Los miembros tienen acceso a miles de libros, vídeos de formación, rutas de aprendizaje, tutoriales interactivos y listas de reproducción de más de 250 editoriales, como 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, Jones & Bartlett y Course Technology, entre otras. Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett y Course Technology, entre otras.

Para más información, visita http://oreilly.com/safari.

Cómo contactar con nosotros

Dirige tus comentarios y preguntas sobre este libro a la editorial:

  • O'Reilly Media, Inc.
  • 1005 Gravenstein Highway Norte
  • Sebastopol, CA 95472
  • 800-998-9938 (en Estados Unidos o Canadá)
  • 707-829-0515 (internacional o local)
  • 707-829-0104 (fax)

Tenemos una página web para este libro, donde se enumeran erratas, ejemplos y cualquier información adicional. Puedes acceder a esta página en http://bit.ly/site-reliability-engineering.

Para hacer comentarios o preguntas técnicas sobre este libro, envía un correo electrónico a

Para más información sobre nuestros libros, cursos, conferencias y noticias, consulta nuestro sitio web en http://www.oreilly.com.

Encuéntranos en Facebook: http://facebook.com/oreilly

Síguenos en Twitter: http://twitter.com/oreillymedia

Míranos en YouTube: http://www.youtube.com/oreillymedia

Agradecimientos

Este libro no habría sido posible sin los incansables esfuerzos de nuestros autores y redactores técnicos. También nos gustaría dar las gracias a los siguientes revisores internos por sus comentarios especialmente valiosos: Alex Matey, Dermot Duffy, JC van Winkel, John T. Reese, Michael O'Reilly, Steve Carstensen y Todd Underwood. Ben Lutch y Ben Treynor Sloss fueron los patrocinadores de este libro dentro de Google; su fe en este proyecto y en compartir lo que hemos aprendido sobre la ejecución de servicios a gran escala fue esencial para hacer realidad este libro.

Nos gustaría dar las gracias especialmente a Rik Farrow, editor de ;login:, por colaborar con nosotros en una serie de contribuciones para su prepublicación a través de USENIX.

Aunque en cada capítulo se menciona específicamente a los autores, nos gustaría dedicar un momento a reconocer a quienes han contribuido a cada capítulo con sus reflexivas aportaciones, debates y revisiones.

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

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

Capítulo 6: Mike Curtis, Jamie Wilkinson, Seth Hettich

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

Capítulo 9: Ryan Anderson

Capítulo 10: Jules Anderson, Max Luebbe, Mikel Mcdaniel, Raul Vera, Seth Hettich

Capítulo 11: Andrew Stribblehill, Richard Woodbury

Capítulo 12: Charles Stephen Gunn, John Hedditch, Peter Nuttall, Rob Ewaschuk, Sam Greenfield

Capítulo 13: Jelena Oertel, Kripa Krishnan, Sergio Salvi, Tim Craig

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

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

Capítulo 16: Andrew Stribblehill, Richard Woodbury

Capítulo 17: Isaac Clerencia, Marc Alvídrez

Capítulo 18: Ulric Longyear

Capítulo 19: Debashish Chatterjee, Perry Lorier

Capítulos 20 y 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

Capítulo 22: Mike Curtis, Ryan Anderson

Capítulo 23: Ananth Shrinivas, Mike Burrows

Capítulo 24: Ben Fried, Derek Jackson, Gabe Krabbe, Laura Nolan, Seth Hettich

Capítulo 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

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

Capítulo 27: Vivek Rau

Capítulo 28: Melissa Binde, Perry Lorier, Preston Yoshioka

Capítulo 29: Ben Lutch, Carla Geisser, Dzevad Trumic, John Turek, Matt Brown

Capítulo 30: Charles Stephen Gunn, Chris Heiser, Max Luebbe, Sam Greenfield

Capítulo 31: Alex Kehlenbeck, Jeromy Carriere, Joel Becker, Sowmya Vijayaraghavan, Trevor Mattson-Hamilton

Capítulo 32: Seth Hettich

Capítulo 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

También estamos agradecidos a los siguientes colaboradores, que o bien proporcionaron material significativo, hicieron un excelente trabajo de revisión, accedieron a ser entrevistados, aportaron conocimientos o recursos significativos, o tuvieron algún otro efecto excelente en este trabajo:

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 y Zoltan Egyed.

Agradecemos enormemente los comentarios reflexivos y profundos que recibimos de los revisores externos: Andrew Fong, Björn Rabenstein, Charles Border, David Blank-Edelman, Frossie Economou, James Meickle, Josh Ryder, Mark Burgess y Russ Allbery.

Nos gustaría dar las gracias especialmente a Cian Synnott, miembro original del equipo del libro y co-conspirador, que dejó Google antes de que se completara este proyecto, pero que influyó profundamente en él, y a Margaret Hamilton, que tan amablemente nos permitió hacer referencia a su historia en nuestro prefacio. Además, nos gustaría dar las gracias especialmente a Shylaja Nukala, que generosamente dedicó el tiempo de sus redactores técnicos y apoyó sus necesarios y valiosos esfuerzos de todo corazón.

Los editores también desean dar las gracias personalmente a las siguientes personas:

Betsy Beyer: A la abuela (mi heroína personal), por proporcionarme cantidades interminables de charlas telefónicas y palomitas, y a Riba, por proporcionarme los pantalones de chándal necesarios para alimentar varias noches hasta tarde. Todo ello, por supuesto, además del elenco de estrellas de la ESR, que fueron unos colaboradores encantadores.

Chris Jones: A Michelle, por salvarme de una vida de delincuencia en alta mar y por su asombrosa habilidad para encontrar manzanas en lugares inesperados, y a quienes me han enseñado ingeniería a lo largo de los años.

Jennifer Petoff A mi marido Scott, por apoyarme increíblemente durante los dos años que duró el proceso de escribir este libro y por mantener a los editores abastecidos con abundante azúcar en nuestra "Isla de los Postres".

Niall Murphy: A Léan, Oisín y Fiachra, que fueron considerablemente más pacientes de lo que tenía derecho a esperar con un padre y un marido sustancialmente más rancios de lo habitual, durante años. A Dermot, por la oferta de traslado.

1 El mero hecho de que exista una variación tan grande en estas estimaciones te dice algo sobre la ingeniería de software como disciplina, pero consulta, por ejemplo, [Gla02] para más detalles.

2 A nuestros efectos, la fiabilidad es "La probabilidad de que [un sistema] realice una función requerida sin fallos en las condiciones establecidas durante un periodo de tiempo determinado", siguiendo la definición de [Oco12].

3 Los sistemas de software que nos ocupan son, en gran medida, sitios web y servicios similares; no tratamos los problemas de fiabilidad a los que se enfrenta el software destinado a centrales nucleares, aviones, equipos médicos u otros sistemas críticos para la seguridad. Sin embargo, en el capítulo 33 comparamos nuestros enfoques con los utilizados en otros sectores.

4 En esto, nos diferenciamos del término industrial DevOps, porque aunque definitivamente consideramos la infraestructura como código, tenemos la fiabilidad como nuestro principal objetivo. Además, estamos fuertemente orientados a eliminar la necesidad de operaciones -véase el Capítulo 7 para más detalles-.

5 Además de esta gran historia, también tiene un derecho sustancial a popularizar el término "ingeniería de software".

Get Ingeniería de Fiabilidad del Sitio 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