Convertirse en SRE

Capítulo 1. Lo primero es lo primero

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

¡Bienvenido al libro! Pongámonos a nivel sobre qué es la ingeniería de la fiabilidad de los sitios web (SRE) y de dónde viene.

¿Qué es la ESR?

En encontrarás numerosas definiciones de ingeniería de la fiabilidad de las obras. Aquí tienes la mejor que he podido elaborar a lo largo de los años:

La ingeniería de la fiabilidad de las instalaciones es una disciplina de la ingeniería dedicada a ayudar a las organizaciones a alcanzar de forma sostenible el nivel adecuado de fiabilidad en sus sistemas, servicios y productos.

Si estoy presentando esta definición a un público, suelo decir que hay al menos tres palabras en esa definición cuya presencia, si se entiende correctamente, te llevará a una comprensión decente de la ESR. Si tengo la oportunidad, preguntaré a ese público: "¿Qué tres palabras creéis que son las más importantes de esta definición?". Por favor, siéntete libre de hacer una pausa aquí y releer la definición anterior y responder a esa pregunta por ti mismo antes de seguir leyendo.

Hago esta pregunta no sólo porque me gusta la interacción con el público, sino también porque ofrece una visión diagnóstica de la propia multitud. En el Capítulo 4, profundizaré en lo que puedes aprender de este diagnóstico. Pero mientras tanto, veamos las tres palabras que yo elegiría en primer lugar si me hicieran esta pregunta.

Fiabilidad

Una primera suposición bastante fácil, ¿verdad? La fiabilidad es fundamental en todo lo que hacemos en SRE (diablos, está justo en el nombre). Una forma de subrayar la importancia de la fiabilidad es señalar que una organización puede gastar millones en la moneda local para crear el mejor software con las funciones más sofisticadas, contratar a un gran equipo de ventas para venderlo, dotar de personal a un equipo de soporte técnico de primera para prestarle asistencia, etc., pero si el software no funciona cuando un cliente intenta utilizarlo, todo ese dinero y esfuerzo se van a la basura (o por el retrete, según la metáfora que te resulte más llamativa).

Cuando tienes problemas de fiabilidad, tu organización puede sufrir una pérdida de:

Ingresos

Esto es especialmente cierto si el sistema que está averiado es fundamental para ganar dinero.

Tiempo

Los empleados se enfrentan a una interrupción en lugar de al trabajo planificado.

Reputación

La gente no querrá utilizar un servicio que le parezca deficiente y se cambiará gustosamente a un competidor.

Salud

Si tu entorno está constantemente en llamas, si las personas de guardia son despertadas regularmente, si tu personal siempre tiene que dedicar su tiempo al trabajo en lugar de a sus amigos o familia, puede haber graves repercusiones en la salud.

Contratación

La gente de este sector habla entre sí. Si se difunde que tu lugar de trabajo es un gran "incendio de neumáticos", será muy difícil contratar a gente nueva.

Adecuado

Creo que una idea clave que la ESR introdujo o destacó en el debate sobre las operaciones es la noción de que sólo en las situaciones más raras el 100% de fiabilidad es un objetivo deseable o incluso posible. No es posible en muchos casos porque, en este mundo interconectado, hay muchas probabilidades de que tus dependencias no sean fiables al 100%. A veces se puede conseguir ser más fiable que tus dependencias mediante una planificación y codificación inteligentes, pero no siempre.

En cambio, la SRE se centra en prácticas como los indicadores de nivel de servicio/objetivos de nivel de servicio (SLIs/SLOs),¹ para ayudarte a determinar, comunicar y trabajar para conseguir un nivel adecuado de fiabilidad en tus sistemas.

Sostenible

Esta palabra entró en la definición más tarde que el resto, cuando quedó claro que para que una práctica de operaciones tuviera éxito, tenía que ser sostenible. La sostenibilidad se remonta a la cuestión de la "pérdida de salud" con la fiabilidad. Los sistemas fiables los construyen las personas. Si las personas de tu organización están quemadas, agotadas, incapaces de conectar con las personas de su vida fuera del trabajo o de dedicarse al autocuidado, no podrán construir sistemas fiables. Muchas personas aprenden esto por las malas; por favor, no seas una de ellas si puedes evitarlo.

(Otras palabras)

Hay algunas otras palabras de esta definición que sólo mencionaré aquí para prefigurar nuestro próximo debate en el Capítulo 4: ingeniería, disciplina, ayuda y organización. ¡Nos vemos pronto en ese capítulo!

Historia del origen

Aunque creo que es útil conocer el origen de la SRE y cómo surgió en Google (más o menos en la época de 2003), esa no es mi historia. Ben Treynor Sloss, el progenitor de la SRE, ofrece su versión oficial en Site Reliability Engineering (también conocido como ellibro SRE), editado por Betsy Beyer et al. (O'Reilly, 2016).

En su lugar, me gustaría hablarte de la primera vez que empecé a comprender realmente el tema, porque puede que a ti también te ayude. Conecta con la historia del origen de Google porque coincidió con el momento en que Treynor Sloss explicó su forma de entender la ESR en la primera reunión pública dedicada al tema. Creo firmemente que las historias que nos contamos a nosotros mismos son cruciales para comprender nuestra identidad, así que fue un momento muy importante.

El 31 de mayo de 2014, en Santa Clara (California), vi a Treynor Sloss pronunciar el discurso de apertura titulado "Claves de la SRE" en la primera SREcon.² Te recomiendo que tú también lo veas.

En aquella charla mostró una única diapositiva que hizo que empezara a entender la ESR. La Figura 1-1 muestra una instantánea de la diapositiva.

Figura 1-1. Diapositiva del discurso de Ben Treynor Sloss en la SREcon14, utilizada con permiso.

La Figura 1-1 es la lista con la que empecé y sigue siendo un buen punto de partida para cualquiera.

Al volver a ver esta diapositiva ahora, nueve años después de escribir esto, me sorprende cuántos de estos puntos se han mantenido a lo largo del tiempo y qué cosas parecen depender del contexto de Google en el que nacieron. Desde que se dio esta charla, se han añadido bastantes matices (se podría decir que al menos el valor de tres libros; véanse los recursos de SRE en el Apéndice C), lo que quizá sea una muy buena razón para que tú también estés leyendo este libro.

SRE y su relación con DevOps

Siempre que hablo con personas que intentan entender la ingeniería de la fiabilidad de los sitios web, casi puedo garantizar que, en algún momento, la conversación desembocará en preguntas como éstas: ¿Cómo se comparan DevOps y SRE? ¿Qué relación tienen? ¿Y sería razonable tener ambas cosas en la misma empresa? Son preguntas no triviales para las que he pasado años intentando encontrar respuestas satisfactorias. Por eso decidí hacer un crowdsourcing del Capítulo 12 de Seeking SRE sobre este tema. No tenía una gran respuesta en ese momento, y realmente esperaba que alguien más la tuviera.³

Con la ayuda de las respuestas de ese capítulo y algunas búsquedas e investigaciones posteriores, finalmente llegué a una respuesta que me gustó. Una vez que me di cuenta de que iba a hacer falta más de un enfoque para responder realmente a estas preguntas, pude construir una explicación en varias partes que a mí me funciona. Espero que te sirva a ti también. Permíteme que exponga las tres partes con un pequeño comentario sobre cada una de ellas.

Parte 1: La SRE implanta DevOps de clase

Esto procede del Capítulo 1 de The Site Reliability Workbook (O'Reilly, 2018) y de la mensajería posterior de Google. Para los no programadores que lean esto, quiere decir que la SRE es una aplicación⁴ de la filosofía general DevOps. No es mi comparación favorita por varias razones:

• Los no programadores no acaban de entender las frases ni los matices.

• No creo que conozca otra implementación de DevOps más allá de la "predeterminada" que evolucionó con el tiempo y la práctica en la naturaleza, por lo que parece un poco sospechoso.

• Implica una conexión histórica en la noche de los tiempos en el origen de la ESR (o al menos un doble descubrimiento) que no he visto que demuestre.

• Aún no estoy seguro de si me lo creo.

La razón por la que mantengo esta idea sobre SRE y DevOps (además de que viene de gente más inteligente que yo) es que capta las similitudes, o al menos las frecuencias resonantes, que comparten las dos prácticas modernas de operaciones.

Parte 2: La SRE es a la fiabilidad lo que DevOps es a la entrega

No sé tú, pero yo tengo periódicamente una crisis de fe en torno a DevOps. Esta vez en concreto me había dado cuenta de que no podía encontrar una descripción de DevOps o de las prácticas DevOps que me ayudara a distinguirla inmediatamente de otras prácticas de operaciones del mundo. Quería palabras que lo diferenciaran inmediatamente de cualquier otra cosa, de modo que pudiera elegirlo inequívocamente de una alineación ("¡3, eso es DevOps! ¡Lo reconocería en cualquier sitio!"). Consulté todos mis recursos y mi colección de acrónimos de DevOps, pero no lo conseguí.

En el caso de la SRE, podría decir: "La SRE se centra en la fiabilidad". Si alguien preguntara: "¿Cuál es la práctica de operaciones que se centra en la fiabilidad?", la respuesta fácil sería SRE. Esto me llevó a preguntar a las luminarias de DevOps: "Si SRE trata de la fiabilidad, ¿cuál es la única palabra para DevOps?".

Fui de lumbrera en lumbrera (todas ellas muy amables), llevando mi linterna, hasta que por fin recibí una respuesta de Donovan Brown que me sentó bien. Para él, DevOps era todo entrega. Entregar valor a los clientes, entregar software, etc. Por fin tenía la palabra que buscaba.

SRE es a la fiabilidad, lo que DevOps es a la entrega.

Puedo vivir con ello.

Parte 3: Todo depende de la dirección de la atención

Esta última pieza del rompecabezas procede de mi amigo Tom Limoncelli, que tuvo la amabilidad de enviar esto como respuesta a mi convocatoria de propuestas para el capítulo de crowdsourcing Seeking SRE que he mencionado antes. La Figura 1-2 es una imagen de ese capítulo (modificada del original a petición suya).

Figura 1-2. El modelo Limoncelli de estrategias SRE, DevOps y Agile. Modificado del original en Seeking SRE (O'Reilly, 2018).

En cierto modo, me gusta más este modelo porque explica una serie de solapamientos en la práctica entre DevOps y SRE que parecen no solaparse en actitud o intención. Daré ejemplos de esto dentro de un momento, pero éste es mi mejor resumen de la teoría de Tom:

1. La historia de DevOps comienza con un desarrollador que teclea código en un portátil. DevOps se ocupa (entre otras cosas) de lo que va a costar entregar ese código a producción para que los clientes puedan obtener el máximo valor de él. La dirección de la atención es del portátil a la producción.⁵ Podrías suponer que ésta es una de las razones por las que los sistemas de integración continua y entrega continua (CI/CD) ocupan un lugar tan destacado en el conjunto de herramientas, habilidades y presencia de DevOps en los anuncios de contratación.

2. La SRE empieza en un lugar diferente. Empieza (y, de hecho, el espacio mental de la SRE reside) en producción. ¿Qué tiene que hacer un SRE para crear un entorno de producción fiable? Responder a esa pregunta implica una mirada que mira "hacia atrás" desde la producción, planteándose esta pregunta paso a paso, hasta llegar al portátil del desarrollador.

3. La dirección de la atención es diferente. Puede que se utilicen las mismas herramientas (por ejemplo, un conducto CI/CD), pero por un motivo distinto. Tanto DevOps como SRE se implicarán mucho en la creación de un sistema de monitoreo, pero puede que lo hagan por un motivo distinto.⁶

Y esto nos lleva a la respuesta a la pregunta anterior: ¿Pueden/deben cohabitar SRE y DevOps en la misma organización? Para mí, la respuesta es sí.⁷ Aunque puede haber cierto solapamiento en las herramientas y a veces en las habilidades, se centran en cosas distintas y aportan beneficios diferentes a una organización.

Hacia los fundamentos de la SRE

Ahora, si alguien te pregunta: "¿Qué es la ESR?", ya tienes los elementos básicos para contárselo. Tendré mucho más que decir sobre esto en el Capítulo 4. Pero ahora que hemos hablado un poco sobre las definiciones y la historia de la ESR, pasemos a algunos fundamentos reales de la ESR que serán fundamentales para nuestra comprensión del tema y del resto de este libro.

¹ Te recomiendo encarecidamente que busques el libro de Alex Hidalgo Implementing Service Level Objectives: A Practical Guide to SLIs, SLOs, and Error Budgets (O'Reilly, 2020) sobre el tema.

² Revelación total: soy uno de los cofundadores de la SREcon.

³ Una de mis respuestas favoritas fue la de Michael Doherty, que dijo: "Ingeniería de Fiabilidad del Sitio: no sabemos lo que es DevOps, pero sabemos que somos algo ligeramente diferente". No es una de las respuestas oficiales anteriores, pero no puedo discutirla.

⁴ En particular, es prescriptiva, ya que DevOps se ha esforzado, en muchos sentidos, por evitar dictar una metodología o unas herramientas específicas. Si lo ha conseguido o no puede ser otra conversación divertida.

⁵ Con paradas en el camino para almacenarlo en un repositorio, y pruebas para asegurarnos de que es seguro desplegarlo para que los clientes puedan empezar a obtener valor de él.

⁶ Nunca he visto que se estudie esto, pero mi instinto me sugiere que, como resultado, se monitorearían cosas diferentes. Sería divertido investigarlo.

⁷ Bien, dadas las condiciones adecuadas, como el tamaño de la organización (una nueva startup puede no necesitar ambas cosas), la cultura de la empresa (si la ESR encaja; ver más adelante en este libro), y la necesidad (contrata para lo que necesites, no para coleccionarlos a todos).