3. ¿Así que quiere formar un equipo de SRE?

Luke Stone, Google

Este capítulo está dirigido a los líderes de organizaciones que no practican la Ingeniería de Fiabilidad del Sitio (SRE). Es para los directores de TI que se enfrentan a la disrupción de la nube. Es para los directores de operaciones que se enfrentan cada día a una mayor complejidad. Es para los directores de tecnología que están creando nuevas capacidades técnicas. Puede que esté pensando en crear un equipo de SRE. ¿Es una buena opción para su organización? Quiero ayudarte a decidir.

Desde 2014, he trabajado en Google Cloud Platform, y he conocido al menos a un centenar de líderes en esta situación. Mi primer trabajo en Google fue antes de que existiera la SRE, y hoy trabajo con clientes de la nube que están aplicando la SRE en sus organizaciones. He visto equipos de SRE crecer a partir de semillas en muchos entornos. También he visto equipos que luchaban por encontrar energía y nutrición.

Así pues, supongamos que desea crear un equipo de SRE. ¿Por qué? He escuchado algunos temas que surgen una y otra vez. Estas citas inventadas ilustran los temas:

• “Mis amigos creen que la SRE es genial y quedaría muy bien en mi currículum”.

• “Me gritaron la última vez que tuvimos un apagón”.

• “Mi organización quiere una fiabilidad más predecible y está dispuesta a pagar por ello”.

Son destilaciones descaradas de situaciones más matizadas, pero puede que te suenen. Cada una señala varias oportunidades y escollos. Comprenderlas le ayudará a averiguar cómo encajaría la SRE en su organización. Veamos el significado real de cada una de ellas.

“Mis amigos creen que SRE es genial y quedaría muy bien en mi currículum”.

El primer punto se refiere a evitar conceptos erróneos: su organización debe entender la SRE a un nivel más profundo.

Si la SRE le parece cool, ¡enhorabuena por su excelente gusto! Es bastante cool tomar algo tan teórico como un presupuesto de errores y aplicarlo a un problema del mundo real… y ver resultados. Es ciencia. Es ingeniería.

Sin embargo, a largo plazo, la SRE no va a prosperar en su organización basándose únicamente en su popularidad actual. Cada interrupción será una prueba de la capacidad del equipo para ofrecer un valor real. La mala noticia es que se necesita mucho trabajo para generar confianza en torno a un equipo que es muy visible cuando las cosas van desastrosamente mal. La buena noticia es que la SRE está bien diseñada, detallada y probada en el mundo real. Puede ser la columna vertebral de su plan para lograr la fiabilidad que necesita.

Por lo tanto, no puedes contar con que la frescura te lleve muy lejos. Un equipo de SRE que funciona bien tiene una cultura que se desarrolla con el tiempo, y va a ser un proyecto a largo plazo y de alto esfuerzo para iniciar un equipo en su organización. Estamos hablando de meses a años. Si esta no es su idea de diversión, todavía puede obtener algunos resultados rápidos mediante la adopción de algunas prácticas de SRE. Por ejemplo, puede practicar la redacción sistemática de postmortems y su revisión con su equipo. Esto puede ser útil, pero no espere que tenga el mismo impacto que adoptar el conjunto completo de principios de SRE.

Del mismo modo, no espere que su equipo de SRE tenga impacto si no está practicando el enfoque de SRE a la ingeniería de producción todo el día, todos los días. Es tentador poner la etiqueta SRE en un equipo existente, cambiar algunos títulos de trabajo y afirmar que se han dado los primeros pasos. Probablemente pueda adivinar que es poco probable que esto tenga éxito porque en realidad no cambia nada de los propios sistemas. Un equipo de SRE es fundamentalmente un equipo de ingenieros de software que apuntan al problema de la fiabilidad, así que si su organización no cuenta con ingenieros de software, no es adecuada para la SRE. Si tienes ingenieros de software pero no puedes centrar su energía en un enfoque de SRE para la fiabilidad de la producción, tendrás otro sabor de “SRE sólo de nombre”.

Un equipo de SRE eficaz requiere un entorno determinado. Debe haber apoyo desde la base, también desde los lados y desde arriba. Tendrá que conseguir el apoyo de los propios miembros del equipo de SRE, de sus compañeros (equipos de desarrollo y otros equipos de SRE) y de la dirección. El equipo no prosperará aislado. Debe integrarse en el núcleo técnico de la empresa. La facilidad de comunicación es importante, así que considere la colocación física con los equipos de desarrollo o la inversión en videoconferencias de alta calidad. La SRE debe participar en la toma de decisiones de alto nivel sobre las necesidades de fiabilidad y los niveles de inversión en personal e infraestructura redundante.

Los miembros del equipo deben ser dedicados y dignos de confianza entre sí. Deben ser expertos en automatización y resolución de problemas técnicos. Deben poseer la generosidad necesaria para apoyarse unos a otros continuamente, porque la SRE es realmente un esfuerzo de equipo y hay un dicho: “No hay héroes”. Evite los equipos que se han formado a partir de individuos lejanos. Puede que sea mejor reutilizar un equipo que funcione bien para poner en marcha su equipo de SRE.

Los equipos de SRE interactúan con otros equipos, en particular con los de desarrollo, por lo que estos también deben participar. Por ejemplo, es difícil crear una cultura postmortem libre de culpa si los desarrolladores o los directivos señalan con el dedo. Cuando se combina con un equipo de SRE, un equipo de desarrollo debe aportar algo de valor a la asociación. He aquí algunos ejemplos:

• Financiar al equipo

• Aceptar algunos turnos de guardia

• Dar a SRE un mecanismo para priorizar las necesidades de SRE

• Dedicar los mejores ingenieros de software al equipo de SRE

He aquí una receta para el desastre: cuando el equipo de desarrollo espera que el equipo de SRE “simplemente lo arregle”. El equipo de SRE debería estar facultado para garantizar que el software pueda funcionar de forma fiable, y el equipo de desarrollo debería estar interesado en colaborar para lograr ese objetivo. Debe esperarse que los desarrolladores participen activamente en las operaciones de producción, por ejemplo, formando parejas con los SRE o asumiendo una pequeña parte de las tareas operativas del equipo SRE. Esto les hará conscientes del valor del equipo SRE y también les dará algunos datos de primera mano sobre cómo es operar el sistema. También es muy importante para la continuidad del negocio en caso de que el equipo de SRE tenga que “ entregar el localizador” y dejar de dar soporte al sistema. Si los desarrolladores no pueden o no quieren responsabilizarse de alguna parte de las tareas de ingeniería de producción, la SRE no va a funcionar.

La SRE prospera en un entorno de comunicación abierta y eficaz. Será muy difícil si el equipo de SRE está excluido de las conversaciones sobre el futuro del producto o servicio. Puede tratarse de una fricción involuntaria, por ejemplo si el equipo de SRE se encuentra en una ubicación remota, trabaja en una zona horaria diferente o utiliza otro idioma (hablado o de programación, claro). Es aún peor si el equipo de SRE es local pero está excluido de la planificación o de los eventos sociales.

Pero espera, ¡yo pensaba que la SRE era obviamente cool! Quiero decir, mira cómo crece la asistencia a la SREcon cada año, y el libro de SRE es un best-seller. En Google, los SRE llevan unas chaquetas impresionantes y tienen un logo con un dragón. Es genial.

Si quiere que la SRE tenga éxito en su organización, sin duda ayuda a que sea cool. Eso no significa que tenga que ser elitista o excluyente. Habrá una tendencia a que otros equipos rechacen la SRE si no la entienden, por lo que es muy importante conseguir que todos los líderes técnicos introduzcan los conceptos y las personas en sus equipos. Podrías estar dispuesto a probar un programa de rotación entre dev y SRE, o una política por la que la gente pueda transferirse libremente entre los equipos dev y SRE. Se trata de construir relaciones personales y tratar a los SRE como iguales.

En un nivel superior, la dirección ejecutiva debe estar dispuesta a respaldar al equipo de SRE cuando actúe de acuerdo con sus principios, incluso cuando el mundo parezca estar en llamas. La dirección debe delegar en los SRE que están gestionando un incidente en directo. Deben estar dispuestos a aprobar los Objetivos de Nivel de Servicio (SLO), lo que significa que asumen la responsabilidad de defender cierta cantidad de tiempo de inactividad como aceptable. Deben estar dispuestos a hacer cumplir los presupuestos de errores, lo que significa aplicar consecuencias como la congelación de funciones cuando se superan los presupuestos.

“Me gritaron la última vez que tuvimos un apagón”.

Este punto trata de reconocer que una organización es compatible con la SRE sólo si está impulsada por hechos y datos.

Mi abuelo no era un SRE. Era camionero y empresario. En un momento dado, en los años 50, invirtió en un artilugio novedoso: un despertador que se apagaba cuando el usuario gritaba. Muy eficaz para levantarse por las mañanas. Es la única máquina que he visto que hace lo correcto cuando le gritas.

Si su organización reacciona a los problemas de ingeniería aplicando la emoción, no está preparada para la SRE. La gente tendrá que mantener la cabeza fría para llegar al fondo de problemas de fiabilidad cada vez más difíciles. Cuando las personas se sienten amenazadas, están motivadas para ocultar información, y la SRE requiere un ambiente abierto y de colaboración. Por ejemplo, algunos equipos dan premios, no castigos, a las personas que asumen la responsabilidad de causar una interrupción del servicio, si responden adecuadamente al incidente y realizan un postmortem.

Esté atento a los signos de madurez, como la concentración en los beneficios a largo plazo, las mejoras graduales y el reconocimiento de los problemas existentes. Si las personas pueden enfrentarse a los problemas, puede arraigar una cultura postmortem libre de culpa. Si quieren medir el ritmo de mejora, funcionarán los SLO y los presupuestos de errores. Si están dispuestos a invertir, la automatización prosperará y el trabajo pesado desaparecerá.

Una buena señal es el uso de métricas objetivas para dirigir los debates empresariales. La gente se pone de acuerdo de antemano sobre los resultados deseados y medibles, y luego las revisiones periódicas comprueban los números y se ajustan según sea necesario. Si ha visto un escenario en el que la revisión de alguien estaba llena de malas noticias, y la reacción del grupo fue ofrecer ayuda, puede que la cultura sea la adecuada para la SRE.

Otro buen signo de madurez es cuando la organización puede recompensar los “aterrizajes” (por ejemplo, la automatización en la producción que proporciona ahorros medibles) en lugar de los “lanzamientos” (como una herramienta nueva y brillante). ¿Recompensa las limpiezas significativas y el trabajo sucio que mejora la mantenibilidad y la eficacia operativa?

La SRE se basa en hechos, como las ciencias exactas. Puede llevar tiempo obtener datos difíciles, como la causa de una interrupción o un análisis de cuándo será insuficiente la capacidad actual. Es muy importante que estos hechos reciban el respeto que merecen. Busque personas que sean pacientes a la hora de recopilar datos. Busque personas que cuestionen las suposiciones y exijan pruebas contundentes. Evite a las personas que no tengan la concentración o el interés necesarios para llegar al fondo de una situación técnica compleja.

Las personas de su organización tendrán que confiar en el proceso de SRE como herramienta elegida para gestionar la fiabilidad. Tendrán que atenerse al proceso y vivir con los objetivos de fiabilidad que acordaron en un principio. Un SLO y un presupuesto de errores son como un contrato con objetivos de rendimiento y consecuencias. Cumplir este contrato en caso de incidente exige mantener la cabeza fría. Tiene que ser aceptable para el SRE decir: “los errores aumentaron, pero se mantuvieron dentro del SLO, así que esto no es una emergencia”.

“Mi organización quiere una fiabilidad más predecible y está dispuesta a pagar por ello”.

Esto nos lleva al último punto: su organización debe estar dispuesta a invertir la atención y los recursos necesarios para mantener un equipo de SRE.

La SRE puede ser cara. Usted querrá estar seguro de lo que está obteniendo de ella. Un equipo de SRE sostenible necesita suficientes personas para cubrir las tareas de guardia sin agotarse, y suficientes personas para tener ciclos de automatización, herramientas y otros proyectos de ingeniería de producción. También necesitarán suficientes personas para responder a las innumerables necesidades operativas del servicio que vayan surgiendo. Si el equipo se queda corto de personal, aunque sea un poco, las personas con más talento se marcharán y no conseguirá su objetivo. Existe un tamaño mínimo de equipo necesario para asumir las responsabilidades de SRE de un sistema. Esto no tiene sentido para los sistemas más pequeños, por lo que algunas cosas estarán fuera del alcance del equipo de SRE. No se espera que resuelvan los problemas de todo el mundo.

Mucha gente piensa que la SRE consiste en aumentar continuamente la fiabilidad, para siempre, acercándose asintóticamente al 100%. Ese podría ser su objetivo, pero en algún momento, obtendrá rendimientos decrecientes de sus recursos. En realidad, la SRE consiste en gestionar la fiabilidad para que no se interponga en el camino de otros objetivos empresariales. La organización debe ser capaz de aceptar una fiabilidad inferior al 100%, porque ningún sistema es perfecto. Hay que prever, aceptar e incluso aceptar cierto tiempo de inactividad. La reticencia a enfrentarse a esta realidad es el obstáculo más importante para adoptar la SRE.

¿Qué objetivos serían más importantes que la fiabilidad? Cuando la tecnología es un elemento diferenciador para la empresa. Cuando la innovación es importante. En estos casos, es posible que desee un equipo de desarrollo de productos que vaya lo más rápido posible, y valdría la pena contar con un equipo de SRE que proporcione algunos guardarraíles de fiabilidad. Por ejemplo, SRE podría proporcionar un sistema de despliegue con servidores canary y rollbacks sencillos.

La SRE puede encajar en su organización si tiene la disciplina suficiente para confiar en el proceso. Al principio, parece que la SRE establece otra serie de restricciones. Pero, en realidad, las personas ganan libertad cuando adoptan prácticas como los SLO y los postmortems sin culpa. Un SLO es una codificación de expectativas claras. Permite optimizaciones locales y capacita a las personas para razonar sobre el impacto de sus decisiones en la fiabilidad. Un postmortem sin culpa es un permiso explícito para señalar las cosas que han ido mal. Permite empezar a abordar la causa raíz de los problemas de fiabilidad. Son herramientas poderosas. Como todas las buenas herramientas, requieren formación y mantenimiento. Y, por supuesto, deben utilizarse de acuerdo con su diseño y su mejor propósito.

Espero que este capítulo le haya dado alguna perspectiva sobre si la SRE es una buena opción para su organización. Los pasos para poner en marcha el equipo pueden tratarse en otro capítulo, ¡o quizás en otro libro! Si todavía no está seguro de si la SRE es adecuada para usted, aquí tiene algunas ideas para reunir más información:

• Encuentre algunas personas influyentes en su organización (líderes y veteranos, por ejemplo) y pídales que lean los primeros capítulos del libro original de SRE. ¿Resuenan las ideas? ¿Parece realista la SRE?

• Haga una lluvia de ideas sobre algunos SLO para su servicio. Póngalos a prueba con las personas responsables de la experiencia del usuario. Juegue al “qué pasaría si” con algunos escenarios, como interrupciones imprevistas de diversa duración, mantenimiento planificado de una función y degradación del servicio.

• Intenta pensar en un sistema maduro e importante por el que empezar. ¿Existen parámetros de fiabilidad claros? ¿Está claro quién decidirá sobre los SLO y el presupuesto de errores?

• Imagine que ha creado un equipo de SRE. ¿Cómo sabe si está funcionando bien? ¿Más fiabilidad con menos gente? ¿A mayor velocidad de lanzamiento? Algo que se pueda medir.

Ahora está bien armado con preguntas que le ayudarán a evaluar la posibilidad de SRE en su organización. Asegúrese de incluir a sus colegas y a las partes interesadas mientras recopila datos y delibera. Esta decisión es demasiado importante para que la tome una sola persona. Si trabajan juntos, podrán tomar una sabia decisión sobre la puesta en marcha de su equipo de SRE. Buena suerte.

Luke Stone se incorporó a Google en 2002 como el primer ingeniero de asistencia técnica para AdSense. Fue testigo del impacto de la SRE en Google desde el principio y se unió a Google SRE como miembro fundador del equipo de Ingeniería de Fiabilidad del Cliente. Antes de trabajar en Google, Luke fue administrador de sistemas y desarrollador en organizaciones académicas y sin ánimo de lucro, y estudió Informática en Stanford.

Volver al índice