Mas leido
Building Stories
Modo Rua: Redefiniendo el desarrollo de aplicaciones mediante iteración centrada en el usuario Ago 23
Building Stories
NuStories: Adaptación de productos para clientes fanáticos en varios países Oct 30
Culture & Values
Cómo los valores y la cultura de Nu dan forma a los productos que creamos Ago 7
Carreras
Reunimos a grandes mentes de diversos orígenes que permiten la discusión y el debate y mejoran la resolución de problemas.
Conoce más sobre nuestras carreras
Entonces, ¿qué es de guardia? De guardia es cuando un ingeniero está disponible para responder inmediatamente a un mal funcionamiento del servicio, en cualquier momento, cualquier día del año. Por lo general, implica algún tipo de sistema de alerta automático, junto con una forma de notificar al ingeniero.
Para el alcance de este artículo, definimos una Alerta como un proceso configurado automáticamente que se activa cuando se alcanza un umbral determinado, como la tasa de error o la memoria disponible.
La alerta generalmente activa una Notificación o Página y llega al ingeniero a través de una notificación de aplicación móvil o una llamada telefónica.
Se espera que el ingeniero de guardia pueda responder; es decir, tienen a la mano las herramientas necesarias, como acceso a internet y una computadora portátil, y están calificados. Hay otros modelos para esto. En particular, en empresas que cuentan con un equipo de personas, generalmente llamado SRE, que están de guardia para todos los sistemas.
¿Cómo definir la calidad de las guardias?
Dos métricas principales pueden rastrear la calidad de una rotación de guardia: Tiempo Medio de Reconocimiento (MTTA) y Tiempo Medio de Resolución (MTTR).
El primero rastrea la rapidez con la que un ingeniero reconoce una página y revela qué tan saludable es una rotación determinada. El otro rastrea la rapidez con la que se resuelve una página reconocida; muestra lo buenas que son las herramientas y la documentación.
Teniendo esto en cuenta, sería natural suponer que el grupo de personas más adecuado para estar de guardia para un conjunto de servicios es el mismo grupo que construye y mantiene esos servicios.
Sin embargo, la mayoría de las veces, los equipos están formados por entre dos y ocho personas, lo que significa que estarían de guardia muchos días al mes, lo que lleva al siguiente punto.
Consulte nuestras oportunidades laborales
Estar de guardia no es una actividad agradable
Imagine el improbable caso de que su empresa produzca software que nunca funcione mal. Aun así, no es divertido estar atrapado en casa, tener que llevar el teléfono del trabajo al baño, no poder tomar un poco de vino, y sabiendo que, en cualquier momento, el sonido espantoso y áspero del localizador podría despertarle.
Me han despertado varias veces en medio de la noche, lleno de adrenalina, y ya estaba alcanzando la computadora portátil. Volver a dormir después es un desafío.
Teniendo en cuenta esto, parece ser un objetivo deseable tener ingenieros de guardia la menor cantidad de veces al mes posible.
¿Pero cómo combinar eso con calidad?
Haciendo compensaciones
Para reducir la cantidad de tiempo de guardia, es necesario tener más personas en la rotación. Además de crear equipos más grandes de lo previsto, la única forma posible es tener varios equipos de guardia para todos los sistemas del grupo, lo que significa que las personas que están de guardia no están necesariamente a cargo de mantener todos los sistemas.
Esta situación puede causar ansiedad: ¿cómo puedo estar de guardia para un sistema que no conozco? Estos son los requisitos previos para que esto sea posible:
Monitoreo y Herramientas
Sin un seguimiento adecuado, es imposible lograr este objetivo. Debe tener paneles de control comprensibles y herramientas de resolución de problemas.
Documentación
No se debe crear ninguna alerta sin un runbook muy completo.
Los runbooks deben crearse y probarse con ingenieros fuera del equipo. Cuando alguien escribe un runbook, sin darse cuenta hará suposiciones sobre el conocimiento del ingeniero que lo leerá. ″Conectarse al servidor de producción″ puede no significar nada para otra persona.
Recuerde que la persona que lee el runbook está sometida a un gran estrés. Están preocupados y agitados. Lo último que necesitan es descubrir que los enlaces del runbook no llevan a ninguna parte.
Un runbook comienza con un enlace al panel correspondiente que muestra los datos que activaron la alerta.
Luego, enumera instrucciones, con IPs, comandos bash, etc., para solucionar problemas y restaurar el servicio.
Absolutamente ninguna alerta extraña
Cuando un equipo está de guardia para sus propios sistemas, sabe que algunas alertas son un poco inestables. ″Este siempre se activa los viernes por la noche y se repara automáticamente en tres minutos″ o ″Este se activa cada vez que hay un despliegue″. Con alegría reconocen la página y vuelven a lo que estaban haciendo.
Este caso no puede ocurrir en absoluto cuando tienen responsabilidades compartidas de guardia. El otro ingeniero no sabrá que este es el caso. Se despertarán, abrirán sus computadoras portátiles y encontrarán que la alerta ya se resolvió; no es una buena manera de hacer amigos.
Configurando la rotación
Días de la semana
Hay muchas configuraciones posibles, siendo muy populares las rotaciones semanales o diarias. Después de muchas iteraciones y retrospectivas, llegamos a la conclusión, como era de esperar, de que las personas se preocupan mucho más por sus fines de semana que por los días laborables.
De acuerdo con esto, nuestra configuración recomendada es de cinco turnos por semana, lo que resulta en la siguiente cantidad de horas de guardia fuera de las 8 horas estándar en la oficina:
Los turnos suelen comenzar a la hora en que la mayoría de los ingenieros están en la oficina, digamos a las 10am, y terminan a las 10am del día siguiente (o a las 2, según el turno).
Eso significa que se necesitan cinco personas diferentes para cubrir todos los turnos durante una semana de guardia.
Dos capas: primaria y mejor esfuerzo
La mayoría de las herramientas proporcionan una forma de tener una rotación de guardia de varios niveles.
Nuestra configuración recomendada es la siguiente:
Con esta configuración, digamos que se llama al ingeniero principal, sigue el runbook, pero no puede restaurar el servicio. Cuando escale la página, notificará a todos los miembros de la rotación secundaria.
El hecho de que la rotación secundaria sea el mejor esfuerzo puede poner nerviosa a la gente. ¿Qué pasa si nadie puede responder?
Ciertamente compartíamos esta preocupación; sin embargo, después de una experimentación real y docenas y docenas de páginas, ni una sola vez tuvimos problemas con la capa secundaria que no respondiera.
Implementándolo
Suponiendo que su empresa ya cuenta con rotaciones de guardia, generalmente una por equipo, mi recomendación es comenzar poco a poco.
Primero, elija dos equipos para fusionarlos y hablen sobre ello. Si los equipos tienen alguna intersección en contexto, podría ser un poco más fácil.
Luego, obtenga algunas estadísticas de alertas: cuántas alertas por mes, cuántas fuera del horario laboral. Si puede, averigüe cuántos se resuelven automáticamente.
Con estos datos en la mano, haga que los dos equipos limpien las alertas: elimine algunas y ajuste otras. Definitivamente escriba runbooks para todos ellos.
Además, este podría ser el momento adecuado para leer o releer Filosofía sobre Alertas de Rob Ewaschuk en Google. Hemos descubierto que la mayoría de los equipos tienen, como máximo, de cuatro a cinco alertas críticas que deberían despertar a las personas en medio de la noche, muchas veces es menos que eso.
En general, las alertas críticas deben señalar síntomas que afectan a los usuarios, no simplemente tasas de error elevadas o retrasos en un servicio determinado.
Con las alertas limpias, es hora de configurar la rotación.
Durante la primera semana o dos, para que la gente tenga un poco más de confianza, aún puedes mantener la rotación obligatoria por equipo, pero tener la ruta de alertas a la rotación fusionada primero.
A medida que los equipos se sientan más cómodos y, con suerte, más contentos con la nueva configuración, puede agregar lentamente otros equipos a la rotación, hasta llegar a todos los ingenieros de la empresa o a una cantidad suficientemente buena. Si tiene veinte personas en la rotación, una persona estaría de guardia solo un turno por mes.
Se recomienda encarecidamente que reserve una retrospectiva mensual con todos los ingenieros de la rotación fusionada, en la que también comparta estadísticas de alertas.
También es importante tener un canal para que todos los ingenieros de la rotación discutan las alertas actuales, pregunten a las personas por los runbooks faltantes, se enojen por la alerta inusual que los despertó la noche anterior y negocien cambios de turnos.
Incorporación de nuevos ingenieros a la rotación
Esta es la forma recomendada de reducir la ansiedad de que una nueva persona se una a la rotación:
Problemas comunes
1. Alertas durante el horario laboral
A pesar de que es posible silenciar las alertas en el Administrador de alertas de Prometheus, es más común que las personas se olviden de hacerlo de forma preventiva.
Resolver esto es sorprendentemente complicado. Aunque las herramientas tienen configuraciones para la hora del día, no cuentan con soporte para el calendario de días festivos locales.
A menos que esté dispuesto a recordar actualizar la configuración manualmente para ellos, podría terminar con alertas que solo dirigen la capa de mejor esfuerzo.
2. Alertas escamosas
Estos son la pesadilla de los guardias compartidos. La gente, como era de esperar y con razón, se enoja cuando suceden. Es fundamental que el líder de cada equipo se tome el tiempo para afinar las alertas inestables lo antes posible, inmediatamente o al día siguiente.
3. Demasiadas alertas para un equipo determinado
Si un equipo genera alertas en una cantidad desproporcionada en comparación con los demás, la gente se enojará. Es posible establecer “cuotas máximas” por equipo, por mes, y si se superan, el equipo vuelve a las funciones de guardia local.
No consideramos que fuera necesario implementar tal política, pero hemos contemplado esta posibilidad en el pasado. Gestionar la moral compartida de las guardias es esencial.
4. Agregando y quitando personas de la rotación
OpsGenie no hace un gran trabajo manteniendo el cronograma existente al agregar o eliminar personas de la rotación. Parece un problema difícil de resolver, dada la naturaleza infinita de los horarios de guardia.
Recuerde anunciar estos cambios en el canal de rotación, para que la gente pueda comprobar si algo ha cambiado.
5. Un equipo en particular tiene demasiados conocimientos específicos.
A veces, un equipo está demasiado lejos en tecnología de los demás, lo que hace que escribir runbooks sea casi imposible.
Al intentar implementar esto, algunos equipos afirmarán que así es. Analice cada situación con cuidado y trabaje con el equipo para comprender si es el momento de realizar cambios fundamentales o no.
En caso contrario, el equipo deberá seguir con su rotación.
Herramientas
Aquí en Nubank, utilizamos Prometheus’ Alert Manager para alertar y OpsGenie para notificar.
Todos nuestros sistemas ya están monitoreados a través de Prometheus, por lo que usar su Administrador de Alertas fue la opción obvia.
Conclusión
Con el tiempo, a medida que evolucionan las rotaciones, hemos observado algunos efectos secundarios beneficiosos además del bienestar personal y la calidad de las guardias:
Y, lo más importante, mejores sistemas que alerten menos y se autocuren en más casos.
Consulte nuestras oportunidades laborales
Descubre las oportunidades