Los SREs ponen ORDEN(R) en el CAOS

Una clasificación de los desafíos y responsabilidades de tu persona de confianza: el ingeniero de confiabilidad del sitio (SRE).

Por Keith McDuffee, embajador de Snyk, especialista en DevSecOps y fundador de StackRef.com.

«¿Cuál es la diferencia entre un ingeniero de DevOps y un ingeniero de confiabilidad del sitio?»

Es una pregunta que escucho todo el tiempo, y que he escuchado (y a veces hecho) en entrevistas de trabajo. Pero ¿hay una respuesta correcta? Todo depende de a quién le preguntes. Creo que sí hay una diferencia, pero es tan difusa que tendrías que entrecerrar los ojos para verla.

Por ahora, hablemos de los SRE. ¿Cuáles son sus responsabilidades? ¿Qué hacen? ¿Qué desafíos enfrentan día a día?

Voy a intentar ser ingenioso y agrupar sus responsabilidades en lo que llamo ORDERR y sus desafíos como CHAOS.

CHAOS

¿Qué cosas mantienen alerta a los SRE y no los dejan dormir por la noche? Podemos clasificarlas así:

Falla de componentes críticos

Los componentes subyacentes de un sistema informático son muchos, pero no hablamos solo del hardware. El hardware, junto con sus redundancias, puede fallar, pero también hay que tener en cuenta los servicios y las aplicaciones. Las aplicaciones se bloquean, los servicios se sobrecargan y el hardware simplemente deja de funcionar.

Intervención humana

La falta de una automatización eficaz es como despertar a un SRE para que escriba 4, 8, 15, 16, 23 y 42 en un teclado a las 2:00 a. m. todas las noches. Depender de una persona de carne y hueso para hacer tareas que un programa podría realizar fácilmente es buscarse la frustración, el agotamiento y los errores al escribir código. Además, cuando esos sistemas automatizados fallan —y pueden fallar—, no tener una forma rápida y sencilla de replicar el proceso se convierte en otro problema.

Errores en el código de las aplicaciones

Hay un límite para lo que puede hacer un SRE. Algunos saben programar y conocen una aplicación de principio a fin, pero ese no suele ser el motivo por el que los contratan. Sin embargo, un SRE puede ayudar a identificar a los responsables y poner a los ingenieros adecuados a trabajar en el problema. Los SRE también deberían tener algo de clarividencia gracias a sus herramientas de observabilidad, porque sin ellas hay una bomba de tiempo que espera para despertarlos. Otra vez.

Problemas de código abierto

A veces, los desarrolladores no tienen toda la culpa de que el código falle o sea inseguro (aunque, idealmente, deberían saberlo). Muchas aplicaciones se construyen sobre dependencias de código abierto, algunas de las cuales se acercan a ser cajas negras de magia y complejidad que ningún equipo interno de desarrollo de software podría comprender por completo. Un módulo que se importa a un proyecto para habilitar una sola función podría introducir otros mil componentes innecesarios, lo que puede generar vulnerabilidades aún no descubiertas y problemas de rendimiento.

Las dependencias de código abierto no son las únicas posibles culpables. También pueden tener la culpa los componentes de terceros de pago, lo que a veces puede ser peor: ahora dependes de las prioridades de esa empresa, no de las de una comunidad más amplia (¿alguien dijo log4j?).

Incidentes de seguridad

La verdadera pesadilla de un SRE. Si ocurre, puede que no se pueda solucionar de inmediato ni fácilmente, o que pase desapercibido más tiempo del que quisieras admitir. Aquí se incluyen los ataques de denegación de servicio (DoS), que son algo que se puede mitigar, pero una presencia hostil y activa en tus sistemas es otra cosa. La situación solo se considera «resuelta» cuando el incidente activo está bajo control y ha disminuido, y tratas todo lo que pudo haberse comprometido como si fueran residuos nucleares.

ORDERR

Lo intenté —de verdad lo intenté—: quería reducirlo a solo ORDER, pero simplemente no puedes ignorar ni separar las dos últimas R de la lista.

Observabilidad

¿De qué sirve intentar lidiar con el CAOS si no puedes verlo? La observabilidad consiste simplemente en hacer seguimiento de todo: disponibilidad, rendimiento y actividad.

Pero no se trata solo de tener visibilidad de esta información. Debe haber alertas confiables que permitan tomar medidas cuando un evento requiera atención. En este caso, «que permitan tomar medidas» y «confiables» van de la mano. Si despiertan a un SRE por una falsa alarma durante la noche —y las falsas alarmas siguen—, es probable que se fatigue y que termine en una situación de «ahí viene el lobo», en la que una alerta que parecía falsa en realidad indica algo preocupante.

Aunque las alertas oportunas y relevantes son importantes, un SRE no puede depender solo de ellas. Tener visibilidad del monitoreo, para que los SRE puedan comprobar continuamente el estado de lo que está en ejecución, es el primer paso para configurar esas alertas. Algunos equipos de SRE usan herramientas de terceros, mientras que otros crean las suyas. Todo depende del presupuesto y de si existe una solución que se adapte a tu situación particular.

Hay demasiadas herramientas para enumerarlas todas en esta categoría, pero aquí tienes algunas: Datadog, New Relic, ELK Stack (se puede usar y alojar gratis), SolarWinds y Splunk.

Confiabilidad

Este es un tema amplio. Muchas cosas pueden afectar la confiabilidad de los sistemas y las aplicaciones. Desde los cimientos hasta arriba —¡y más allá!—, todo el stack influye: geolocalización, instalaciones de alojamiento, servidores y hardware, redes, sistema operativo, servicios, código de las aplicaciones y la forma en que se entregan los servicios que proporcionas. ¿Ya te cansaste? Los SRE sí.

Habría agregado una «A» por disponibilidad, pero creo que están lo bastante relacionadas como para significar lo mismo. Asegurarte de contar con lo necesario para que tus sistemas estén disponibles —redundancia, métodos de conmutación por error automatizados o manuales, seguridad y gestión de incidentes de denegación de servicio— forma parte del tema de la confiabilidad.

Salvo por el código de las aplicaciones, los SRE son los únicos responsables de cuidar y mantener lo que hace confiables los sistemas de una organización. En el caso del código de las aplicaciones, muchas veces los SRE solo proporcionan observabilidad a los desarrolladores de software que lo crearon, no son quienes reparan lo que está roto. Esto se logra en parte con herramientas de análisis estático del código que señalan los problemas cuando se detectan, o mediante el monitoreo y el registro implementados. Una vez detectados, es responsabilidad del SRE asegurarse de que los problemas se deriven a los equipos correspondientes y se atiendan rápidamente.

Entre las herramientas que ofrece Snyk para esta categoría están las siguientes.

Respuesta ante desastres

«Desastre» es un término amplio para los SRE. Puede referirse a cualquier cosa, desde una falla de infraestructura crítica hasta (Dios no lo quiera) un accidente aéreo en el que viaje el ingeniero de software principal. Por supuesto, también abarca todo lo relacionado con la seguridad.

Contar con un método funcional para responder a estos desastres es fundamental entre las responsabilidades de un SRE. Por eso es clave tener manuales de procedimientos disponibles y actualizados (lo veremos en la E más adelante), ya que no siempre se puede confiar solo en la memoria. Puede ser difícil encontrar tiempo para los simulacros de mesa y las pruebas periódicas de recuperación ante desastres, pero, en general, son fundamentales para garantizar respuestas más rápidas y organizadas ante situaciones catastróficas.

Algunas herramientas de pago (y con opciones limitadas o gratuitas) para esta categoría son Mattermost y PagerDuty.

Una respuesta eficaz también implica…

Comunicación eficaz

Hay muchos métodos de comunicación, sobre todo cuando los equipos trabajan de forma remota y en distintas zonas horarias. Es indispensable contar con un método bien establecido para comunicarse durante cualquier problema, no solo en cuanto a dónde, sino también a cómo y cuándo.

Los medios de comunicación adecuados no solo ayudan a los SRE a mantener la observabilidad de determinadas situaciones, sino que también permiten garantizar que se gestionen correctamente y a tiempo, y que no se dupliquen esfuerzos.

También hay que comunicarse con las partes interesadas internas y externas. Si se detecta algo anormal, la comunicación comienza con los equipos internos antes de informar a los clientes externos sobre los problemas que afectan el uso de tus servicios. Los SRE son el punto de partida para decidir si habrá comunicación externa, cuándo y cómo se llevará a cabo.

Aquí tienes algunas herramientas de comunicación conocidas que seguramente conoces: Slack, Microsoft Teams y Atlassian StatusPage.

Recuperación

Todo lo anterior conduce al objetivo final (además de evitar que algo salga mal): recuperar todo hasta alcanzar un estado estable y seguro. Todos los elementos mencionados determinarán qué tan rápido se puede lograr.

• Observa lo que está pasando.

• Cuenta con un método confiable de conmutación por error y redundancia.

• Asegúrate de seguir tu plan de acción de respuesta ante desastres.

• Pon en práctica una comunicación eficaz.

Los SRE son responsables de cumplir un MTR (tiempo medio de recuperación), y no se puede lograr por pura suerte. Una vez que te recuperaste, toca volver a la comunicación eficaz para calmar las alarmas de las partes interesadas. Pero para el SRE, todavía no termina. Ahora viene…

Retrospectiva

Cuando todo se haya calmado, los SRE pueden tomarse un respiro bien merecido, pero no por mucho tiempo. Ocurrió algo malo. Y, si no se corrige, es probable que vuelva a ocurrir.

Esto nos lleva de nuevo a la comunicación eficaz. Tenemos que entender cuándo, qué, dónde, por qué y cómo, además de qué vamos a hacer para evitar que vuelva a ocurrir.

Hay que documentar las lecciones aprendidas junto con el incidente, y elaborar un plan de acción que no se esfume en el aire. Quizás haya que ajustar cualquiera de los elementos anteriores: mejorar la observabilidad, reforzar los sistemas y la seguridad, agregar capas de confiabilidad o incluso mejorar la comunicación. Después, hay que establecer plazos razonables para asegurarse de que esas medidas se lleven a cabo, y los SRE deben hacer seguimiento con las personas responsables para que se atiendan.

DevOps vs. SRE

Entonces, ¿qué hacen las personas de DevOps si no también son SRE? No entraré en todos los detalles, pero, en relación con los SRE, DevOps ayuda a que todo eso ocurra entre los SRE y los desarrolladores: permite que ambas partes hagan lo que necesitan sin tener que lanzarse demasiadas cosas por encima del muro. DevOps brinda todo el ORDERR del que dependen los SRE para manejar el CHAOS y permite que quienes no son SRE participen tanto como sea necesario.

¡Mucha suerte!…

- K