Cómo construir una cultura de On-Call saludable

• Consejos de SoundCloud sobre el "on-call", en el que se asigna a un ingeniero para recibir llamados (paging) y resolver problemas que surjan fuera del horario laboral

1. El trabajo de on-call es opcional (Optional, solo para quienes se postulan)

2. Como es trabajo fuera del horario regular, se paga una compensación por hora, y cuando se responde a un paging se paga un adicional por hora

3. Los ingenieros de on-call se organizan en varias rotaciones

4. Cada rotación

→ está compuesta por un grupo de ingenieros que representan a uno o varios equipos

→ siempre hay 1 ingeniero de guardia responsable del soporte de primer nivel para los problemas de todos los equipos dentro de la rotación

→ los demás ingenieros quedan disponibles para brindar soporte de segundo nivel para problemas relacionados con los servicios de sus propios equipos

→ el soporte de segundo nivel funciona sobre una base de best-efforts: pueden recibir un paging en cualquier momento y harán su mejor esfuerzo para atenderlo si es posible, pero no es obligatorio responder si no pueden

¿Por qué el trabajo de on-call es bueno para los ingenieros?

• Incluir en el on-call a distintos tipos de ingenieros, además de DevOps y SRE (Site Reliability Engineers), es bueno tanto para la empresa como para los propios ingenieros

• Reduce la carga de los ingenieros de operaciones, que suelen tener mucho trabajo fuera de horario

• Motiva a los ingenieros a construir sistemas estables y bien documentados

→ ver directamente los problemas cuando ocurren les da ideas sobre cómo mejorar y fortalecer el sistema

• Dar soporte tanto a sus propios sistemas como a los de otros es una gran oportunidad de aprendizaje para los ingenieros

Buenas prácticas de proceso: aunque todas las organizaciones son distintas, este es el proceso óptimo que encontró SoundCloud

• Cada rotación tiene un ciclo de relevo distinto, pero en la mayoría de los casos el cambio ocurre cada 1 o 2 días

• Lo óptimo es entrar en on-call unos 3 días al mes. Más que eso provoca burnout; menos que eso reduce la eficiencia.

→ Es decir, el tamaño ideal de una rotación es de 8 a 12 personas. Con 10 es perfecto.

• Dentro de la rotación se elige a un administrador formal o informal para gestionar la rotación, incluyendo el calendario de turnos y los cambios de personal

→ Ej.) ajustes del calendario de guardias durante períodos festivos

Los equipos de rotación y las organizaciones

• La organización de SoundCloud ha evolucionado con el tiempo, con fusiones, divisiones, creación de nuevos equipos y traslados entre áreas

• Pero los equipos de rotación de on-call no evolucionaron al mismo ritmo que la organización de ingeniería

• Actualmente, muchas rotaciones incluso parecen grupos aleatorios de equipos sin relación entre sí

• Sin embargo, eso no ha sido un problema, y los intentos de cambiarlo se detuvieron porque los ingenieros se opusieron

Buenas prácticas culturales: para beneficiar tanto a los ingenieros de on-call como a toda la empresa, se deben fomentar normas y actitudes como las siguientes

• Quienes están de on-call quieren estarlo. Un ingeniero que asume esa responsabilidad por voluntad propia (y recibe compensación) está más motivado al responder a incidentes

• Temas como el ciclo de turnos se deciden mediante acuerdo entre los ingenieros de cada rotación. La empresa no define un procedimiento estándar para el patrón de turnos, la hora del relevo ni la transferencia de turno entre personas

• Los ingenieros de on-call a menudo dedican tiempo dentro del horario laboral regular a investigar estos problemas para evitar que empeoren o que haya que hacer paging a otra persona fuera de horario

• Durante la respuesta a incidentes, los ingenieros pueden llamar a otros ingenieros para pedir ayuda. A nadie le gusta recibir una llamada de soporte de segundo nivel en plena noche, pero si es posible, responder y ayudar permite enseñar para que en el futuro esa misma situación pueda resolverse en solitario

• Después de un tiempo razonable, el trabajo puede pasarse libremente a otra persona. En incidentes graves o prolongados, si los ingenieros están demasiado cansados para seguir trabajando con eficacia, es mejor hacer el relevo después de 4 horas o incluso antes

• Lo más importante es "fomentar una cultura de aprendizaje, no una cultura de culpa". No importa cuántas veces se repita: nunca será demasiado

→ los errores son una parte inevitable de la respuesta a incidentes, y aprender de ellos permite construir una organización de ingeniería más fuerte y técnicamente más capaz

→ si se castiga a las personas por cometer errores, los ingenieros tendrán miedo de actuar ante situaciones nuevas, de pedir ayuda y de ser transparentes

→ al final, en una cultura de culpa, la gente deja la rotación de on-call o se va de la empresa

Cuando ocurre un gran incidente

• Responder a una caída total del sitio o a un incidente grave es estresante para todos

• También es una prueba de estrés para la cultura de on-call de la empresa

• Que los ingenieros trabajen juntos y confíen entre sí es más importante que cualquier otra cosa

• Si pueden admitir lo que no saben, pedir ayuda, hablar con honestidad sobre sus errores y decir que están demasiado cansados para continuar, entonces los problemas pueden resolverse más rápido

• Fomentar este tipo de comportamiento debe hacerse antes de que ocurra un gran incidente. Los ingenieros aprenden por experiencia al responder a incidentes pequeños y colaborar con sus colegas.

→ los incidentes pequeños son práctica para los grandes

[xguru]

• La cultura de guardias on-call que construyó GitHub https://es.news.hada.io/topic?id=3551

• Runbooks de on-call de GitLab https://es.news.hada.io/topic?id=966

Como en las startups no hay suficiente gente, da la impresión de que siempre hay que estar on-call, pero...

Cuando la organización empieza a crecer un poco, solo algunas personas terminan quedándose siempre on-call, y se les puede ver agotarse resolviendo problemas incluso por las noches y los fines de semana.

Creo que, ante todo, hay que construir bien la cultura alrededor de esto (de hecho, yo tampoco lo hice muy bien y lo estoy reflexionando...)