La cultura de guardias on-call que construyó GitHub
(github.blog)GitHub era un gran sistema monolítico construido con Ruby on Rails.
La parte más difícil de la estructura de guardias on-call del monolito
-
Como incluía productos y funcionalidades grandes y numerosos, la mayoría de los ingenieros no sentían confianza en que entendían lo suficiente la base de código como para responder a incidentes durante la guardia. Cuando los llamaban, terminaban escalando a otros equipos y se sentían más como operadores de enlace que como ingenieros.
-
El intervalo entre guardias era largo y cada guardia duraba 24 horas. Los ingenieros hacían guardia no más de 4 veces al año y no lograban obtener suficiente contexto durante ese tiempo.
-
El monitoreo y el sistema de alertas estaban distribuidos entre varios equipos, y como la experiencia de guardia se limitaba a 24 horas, el monitoreo y la documentación para on-call no se mantenían bien.
-
Como la mayoría de los ingenieros no se sentían seguros con la guardia del monolito, entre 5 y 10 personas que conocían bien todo el sistema terminaban participando en todos los incidentes de producción, lo que generaba un desequilibrio en la responsabilidad de on-call.
Nueva cultura on-call
Obstáculos organizacionales del trabajo
-
Crearon un catálogo de servicios para dejar clara la propiedad de los archivos, mapeando archivos a servicios y luego servicios a equipos.
-
Como el monitoreo y las alertas estaban configurados para todo el monolito, hicieron que cada equipo construyera el monitoreo del área de la que era responsable.
-
Como había muchos equipos que debían hacer este trabajo, crearon issues en GitHub para cada equipo y les dieron una checklist.
Obstáculos culturales y educativos
-
La pandemia tuvo un efecto negativo en las personas, así que tuvieron que adoptar un enfoque más centrado en la empatía de lo que habían pensado inicialmente.
-
La mayoría de los ingenieros no tenía experiencia en guardias on-call, aunque sí bastante experiencia operativa, por lo que crearon y ofrecieron capacitación. Establecieron horarios con expertos en on-call, prepararon suficientes herramientas y documentación, y crearon un canal de Slack donde se podía pedir ayuda.
-
A muchos ingenieros les preocupaba cuánto afectaría la guardia a su vida. Si no se tiene mucha experiencia, puede ser difícil ajustar el tiempo de la vida diaria mientras se está de guardia. Para esto recopilaron tips y trucos de expertos en on-call e implementaron medidas para que otra persona pudiera cubrir si alguien perdía una llamada. Como esto es un problema de falta de costumbre, más que con entrenamiento, la comodidad llegará con el tiempo y tras pasar varias veces por la experiencia de estar de guardia.
-
Como había mucha preocupación por no responder bien durante la guardia, están tratando de dar tranquilidad dejando claro que cometer errores está bien y que, por bien que se haga el trabajo, los incidentes inevitablemente ocurrirán.
-
Como cada producto tiene distintos niveles de severidad, algunos equipos deben responder en menos de 5 minutos, mientras que otros pueden atenderlo al día siguiente. Algunas personas dicen que esto es injusto, pero en realidad solo refleja que cada ingeniero tiene intereses distintos.
-
Al aplicar estos cambios, cada equipo no puede dedicar mucho tiempo a mejorar la experiencia de guardia. Cuando la guardia no funciona correctamente, hay que mejorar el proceso de on-call. Les comunicaron a los equipos que deberían usar ~20% de su tiempo para pagar deuda técnica y ~20% para mejorar la experiencia de guardia, y que para eso se necesita una visión de largo plazo por parte del liderazgo.
4 comentarios
No sé más o menos qué es eso de estar de guardia... ¿será una solicitud de soporte? No parece que se trate de atender llamadas por teléfono como aquí.
En nuestra empresa, normalmente llamamos on-call a estar disponible alrededor de una semana cada dos meses para responder en tiempo real a fallas del sistema fuera del horario laboral. Se usa mucho una app llamada PagerDuty; cuando ocurre una incidencia con severidad alta —por ejemplo, que se genere un dead letter o que la tasa de fallas de la API supere cierto nivel...— llega de inmediato una alerta al celular, y uno se conecta desde la laptop de la empresa para revisar los logs y tomar las medidas necesarias.
Creo que pueden pensarlo como estar de guardia.
Da la impresión de ser algo así como un turno o una guardia semanal. Ir rotando la respuesta ante incidentes...