¿Te encanta el DevOps? Espera a descubrir la SRE

¿Qué diablos es la SRE?

Ben Treynor, el genio de Google que está detrás de la SRE, todavía no ha publicado una definición del concepto en una sola frase, pero sí describe la fiabilidad del sitio como “lo que sucede cuando a un ingeniero de software se le encarga lo que solía llamarse 'operaciones'”.

El problema subyacente es este: los equipos de desarrollo quieren lanzar nuevas funciones increíbles a las masas y ver cómo despegan a lo grande. Los equipos de operaciones quieren asegurarse de que esas funciones no rompan nada. Históricamente, esto ha generado una gran lucha de poder, en la que los equipos de operaciones tratan de frenar tantos lanzamientos como puedan y, por su parte, los de desarrollo buscan formas innovadoras de burlar los procesos que les ponen trabas (apuesto a que esta situación te resulta familiar).

La SRE elimina las conjeturas y el debate en torno a lo que se puede lanzar y cuándo hacerlo. Introduce una fórmula matemática para dar luz verde o roja a los lanzamientos, y dedica un equipo específico de personas con competencias en operaciones (con el apropiado nombre de “ingenieros de fiabilidad del sitio” o SRE) para supervisar continuamente la fiabilidad del producto. Tal y como explica Andrew Widdowson, miembro del propio SRE de Google, “Nuestro trabajo es como formar parte del equipo de boxes más intenso del mundo. Cambiamos los neumáticos de un coche de carreras mientras circula a toda pastilla”.

¿Aún no te parece revolucionario? Buena parte de la magia reside en el funcionamiento. Estos son algunos de los principios básicos, que también constituyen algunas de las mayores desviaciones con respecto a las operaciones de TI tradicionales.

En primer lugar, a los nuevos lanzamientos se les da luz verde en función del rendimiento actual del producto.

La mayoría de las aplicaciones no alcanzan el 100 % del tiempo de actividad. Por lo tanto, en cada servicio, el equipo de SRE establece un acuerdo de nivel de servicio (SLA) en el que se define lo fiable que tiene que ser el sistema para los usuarios finales. Si el equipo acepta un SLA del 99,9 %, esto les aporta un presupuesto de errores del 0,1 %. Un presupuesto de errores es justo lo que su nombre indica: el umbral máximo permitido para errores e interrupciones del servicio.

Consejo de experto: Puedes convertir fácilmente los SLA en “minutos de tiempo de inactividad” con esta estupenda chuleta de tiempo de inactividad.

Este es el factor decisivo: el equipo de desarrollo puede “gastar” este presupuesto de errores como prefiera. Si el producto funciona a la perfección, con pocos errores o con ninguno, el equipo podrá lanzar lo que quiera y cuando quiera. Por el contrario, si el equipo ha llegado al tope o superado el presupuesto de errores, y funciona conforme al SLA definido o por debajo de este, se interrumpirán todos los lanzamientos hasta que este número de errores se reduzca a un nivel que permita que estos lanzamientos puedan continuar.

¿Cuál es la genialidad de todo esto? Que tanto los SRE como los desarrolladores tienen un fuerte incentivo para colaborar a fin de minimizar el número de errores.

Los SRE también pueden programar

En el modelo anterior, enfrentas al personal a un problema de fiabilidad y sigues insistiendo (a veces durante un año o más) hasta que el problema desaparece o te explota en la cara.

Eso no sucede en la SRE. Tanto el equipo de desarrollo como el de SRE comparten un único grupo de selección de personal, por lo que cada SRE contratado es un desarrollador menos (y viceversa). Con esto se pone fin a la interminable batalla de personal entre desarrollo y operaciones, y se crea un sistema de autocontrol en el que a los desarrolladores se les recompensa con más compañeros de equipo por haber programado un código más eficiente (es decir, un código que requiere menos soporte por parte de menos SRE).

Los desarrolladores también se ensucian las manos

En Google, Ben Treynor tuvo que luchar por esta cláusula, y se alegra de haberlo hecho. De hecho, en su magnífica ponencia sobre la SRE en SREcon14, recalcó que debería ser obligatorio conseguir este compromiso por parte de la ejecutiva antes de lanzar la SRE.

Básicamente, el equipo de desarrollo gestiona el 5 % de toda la carga de trabajo de operaciones (gestión de tickets, prestación de soporte de guardia, etc.). De este modo, pueden conservar un vínculo estrecho con su producto, ver cómo funciona y tomar decisiones de programación y publicación más acertadas.

Además, cada vez que la carga de operaciones supera la capacidad del equipo de SRE, el desbordamiento siempre se le asigna a los desarrolladores. Cuando el sistema funciona bien, los desarrolladores también comienzan a autorregularse, programando un código eficaz y lanzándolo cuidadosamente para prevenir incidencias futuras.

Los SRE son agentes libres (y se les puede sacar si es necesario)

Para garantizar que los equipos conserven su buen estado y su satisfacción, Treynor recomienda permitir a los SRE que puedan pasarse a otros proyectos según estimen oportuno, o incluso a otra organización. La SRE fomenta un trabajo en equipo muy motivado, especializado y eficaz, por lo que a ningún miembro del equipo debería impedírsele que trate de conseguir sus propios objetivos personales.

Si, simplemente, los miembros de todo el equipo de SRE y de desarrolladores no se soportan y generan más problemas que código fiable, existe una medida drástica definitiva que puedes tomar: sacar del proyecto a todo el equipo de SRE y asignarle toda la carga de trabajo de operaciones directamente al equipo de desarrollo. Treynor solo ha hecho esto un par de veces en toda su carrera, y esta amenaza suele bastar para llevar a ambos equipos hacia una relación laboral más positiva.

La SRE ofrece muchas más ventajas de las que puedo tratar en un solo artículo (como, por mencionar tan solo un par de ejemplos, la forma en que la SRE previene los incidentes de producción, y la forma de seleccionar el personal de los equipos de soporte de guardia y las reglas que estos siguen en cada turno).

Nuestro enfoque

La TI está llena de palabras de moda y tendencias, y eso es algo indudable. En un momento determinado es la nube, poco después es DevOps y luego la experiencia del cliente o la ludificación. La SRE tiene todas las papeletas para ir mucho más allá, principalmente porque versa mucho más sobre las personas y el proceso que sobre la tecnología subyacente. Si bien es cierto que la tecnología puede adaptarse al concepto a medida que este madure y más equipos la adopten (y, probablemente, así sea), no necesitas nuevas herramientas para alinear a tus organizaciones de desarrollo y operaciones en torno a los principios de la ingeniería de fiabilidad del sitio.

En futuros artículos, examinaremos precisamente eso: medidas prácticas para avanzar hacia la SRE y el papel que puede desempeñar la tecnología.