Implementando un proceso de on-call con éxito

He participado de manera activa en 3 empresas diferentes para crear el proceso de on-call, dos han salido bastante bien y otra regular. Así que quiero compartir las cosas que han hecho que en esas dos empresas funcione bien, especialmente en la última, Tinybird.

Antes de introducir el on-call, ¿cómo estábamos?

Teníamos alertas automatizadas, un buen sistema de monitorización pero no teníamos ningún responsable de on-call ni rotación, es decir dependíamos de que la gente estuviera atenta de forma proactiva o configurara notificaciones en el móvil para alguno de los canales de alertas. Es decir, nada organizado ni estructurado. De hecho, teníamos varios canales de alertas, muchas alertas que no eran accionables, mucho ruido constante, etc. Vamos lo típico en la mayoría de empresas. 

Obviamente esta situación no escala ni es apropiada para dar un buen servicio, así que era obvio que necesitábamos implementar on-call, pero, ¿cómo lo haces para garantizar que es un proceso que ayuda a tus clientes y no destroza al equipo?

Nos basamos en estos principios:

• No queríamos que fuera obligatorio. Hay muchas personas que por diferentes motivos no quieren o pueden hacer guardias y es algo que queríamos respetar.

• Hacer “Page” debería ser el último recurso. Es decir, llamar a alguien fuera del horario laboral debe ser completamente necesario para ayudar a nuestros clientes. Además, cada vez que ocurre un incidente se deben poner medidas para que no se repita en la medida de lo posible.

• Tenemos un servicio 24/7 lo que significa que tenemos que ser capaces de proporcionar el servicio todo el tiempo, al menos mantener nuestros SLAs. 

• El ruido debe ser mínimo o de lo contrario el estrés será constante, si encima las alertas no son accionables, ese estrés se convertirá en burnout.

• Queremos que el on-call no sea una cosa del equipo de SRE, sino que todos los equipos formen parte de él. Esto fomenta el ownership en todos los miembros del equipos, fomenta que todo el mundo sea más consciente de las alertas que se crean (que sean accionables, que no tengan ruido, etc). 

• Cada alerta debe tener un Runbook (una pequeña guía de qué gráfica mirar, dónde mirar, cómo resolverla, etc). Esto además puede ayudar a entender cómo automatizar la solución.

• Cada persona no debe estar en on-call más de una semana de cada 6. Esto es más una meta aspiracional que un principio ya que dependemos del número de personas.

• Queremos tener on-call y backup. Es decir, dos niveles de on-call.

• Estar en on-call se compensa económicamente.

¿Cuál fue el proceso para implantar on-call?

Uno de los motivos por los que la gente no quiere hacer on-call es debido al miedo/respeto que se le tiene, en muchas ocasiones es lógico ya que sus pasadas experiencias han sido muy malas. Así que una de las cosas en las que más pusimos énfasis fue en reducir esa fricción, ¿cómo?

1. Mejorar el sistema actual. 

   • Hicimos una lista con todas las alertas que existían, por cada una de ellas revisamos que tenían sentido y que eran accionables. 

   • En la medida de lo posible cambiamos a tener alertas que fueran metricables y de hecho la propia alerta apuntaba a la gráfica en grafana. 

   • Todas esas alertas se migraron a un único canal. 

   • Para cada una de ellas se creó un runbook. 

   • Durante unos dos meses cada lunes nos reuníamos el equipo de plataforma, el CTO y yo para revisar cada alerta que había salido con estos objetivos:

     • Si la alerta era real, la analizaríamos para resolverla a largo plazo y darle la prioridad necesaria. 

     • Si la alerta no era accionable o era un falso positivo, corregirla o eliminarla.

2. Empezamos a revisar cada incident report de manera conjunta todo el equipo de ingeniería. Hasta ese momento hacíamos IRs y se compartían, pero en estas reviews vamos más allá. Se presenta cada IR a todo el equipo de ingeniería, bueno a cualquiera que quiera asistir. El objetivo es entender que ha ocurrido, que todos sean conscientes de los problemas del sistema actual, de cómo se resolvió, de cómo afectó y es necesario sacar action points para evitar que ocurra (por ejemplo, añadir/mejorar alertas, cambiar sistemas, arquitectura, quitar single point of failure, etc)
   Esto también es muy útil para aumentar el ownership y en general el conocimiento de cómo nuestro código afecta al sistema y cómo se opera.

3. Empezamos un sistema de on-call reducido con solo tres personas (el equipo inicial de plataforma y el CTO). Sabiendo que esto era un infierno para ellos pero con el claro objetivo de que fuera temporal. Para implementarlo usamos Pagerduty.

4. Implementamos un on-call en horas de trabajo obligatorio. Es decir, estar en on-call durante la jornada laboral es algo que a toda ingeniera de Tinybird le va a tocar hacer. Los motivos son varios:

   • Ownership. Todo el mundo debe saber operar su código, debe pensar en cómo monitorizarlo, qué alertas tiene sentido, etc.

   • Compartir conocimiento y reducir fricción. Estás en on-call pero no solo, ya que la gente del on-call principal y bueno toda la empresa estaban allí para ayudar. Conseguimos que se viera que no era tan complejo ni tan ruidoso. Además esto nos ayudó a identificar alertas cuyos runbooks no estaban tan claros, mejorar alertas, etc.

5. Todas las semanas cuando cambia el turno de on-call revisamos cómo ha sido el último turno. Lo usamos como en el punto 1 pero además nos sirve para compartir conocimiento, trucos, identificar iniciativas transversales que son necesarias para mejorar el sistema en su conjunto, etc.

Han pasado 6 meses desde que empezamos con este proceso y actualmente tenemos a 9 personas en el on-call principal (24/7) y 6 en el on-call en horas de trabajo

Algo que no he mencionado hasta ahora y que es clave para tener éxito, es contratar a gente que tiene un fuerte sentido de ownership y de compromiso, especialmente con mejorar los sistemas y ayudar a los compañeros.