Ingeniero SRE - pasante
Para empezar, permítanme presentarme. Yo soy , ingeniero frontend en el grupo de GitLab. La semana pasada tuve el honor de ser pasante de uno de nuestros ingenieros SRE de guardia. El objetivo era observar diariamente cómo el ingeniero de guardia responde a incidentes y obtener experiencia real de trabajo. Nos gustaría que nuestros ingenieros entendieran mejor las necesidades de los usuarios Monitor::Health.
Tuve que seguir al ingeniero SRE todo el tiempo durante una semana. Es decir, estuve presente en la transferencia de guardia, observé los mismos canales de alerta y respondí a incidentes si y cuando ocurrieron.
Incidentes
Durante la semana se produjeron 2 incidentes.
1. Minero de criptomonedas
El miércoles se registró un aumento en el uso de GitLab.com ‘s, causado por intentos de utilizar minutos del runner para minar criptomonedas. El incidente se resolvió con nuestra propia herramienta de neutralización de violaciones, que detiene las tareas del runner y elimina el proyecto y la cuenta relacionados.
Si este evento no se hubiera detectado, lo habría atrapado una herramienta automatizada, pero en este caso, el ingeniero SRE fue el primero en notar la violación. Se creó una tarea para el incidente, pero la información está cerrada.
2. Degradación del rendimiento de las aplicaciones Canary y Main
El incidente fue provocado por temporizaciones lentas y un aumento en la frecuencia de errores en las aplicaciones web canary y main en GitLab.com. Se interrumpieron varios valores de Apdex.
Tarea abierta sobre el incidente:
Conclusiones clave
Aquí hay algunos puntos que comprendí durante la semana de guardia.
1. Las alertas son más útiles cuando detectan desviaciones de la norma.
Las alertas se pueden clasificar en varios tipos:
- Alertas basadas en un valor umbral, como ‘se produjeron 10 errores 5xx por segundo.’
- Alertas en las que el umbral es un valor porcentual, como ‘la frecuencia de errores 5xx es del 10% del volumen total de solicitudes en un periodo determinado.’
- Alertas basadas en el promedio histórico, como ‘errores 5xx en el percentil 90.’
En general, los tipos 2 y 3 son más útiles para los SRE de guardia, ya que revelan desviaciones de la norma en el proceso.
2. Muchas alertas no se escalan a incidentes
Los ingenieros de SRE manejan un flujo constante de alertas, muchas de las cuales en realidad no son críticas.
Entonces, ¿por qué no limitar las alertas solo a las realmente importantes? Sin embargo, con este enfoque, podría no ser posible reconocer los primeros síntomas de lo que podría convertirse en un gran problema, potencialmente devastador.
La tarea del SRE de guardia es determinar cuáles alertas realmente indican algo serio y si deben escalarse y abordarse. Sospecho que esto también se debe a la inflexibilidad de las alertas: sería mejor si se introdujeran varios niveles o formas "inteligentes" de configurar alertas de acuerdo con la situación descrita anteriormente.
Propuesta de función:
3. Nuestros SRE de guardia usan muchas herramientas
Internas:
- Proyecto de infraestructura de GitLab: aquí residen los runbooks, las transferencias de guardia por turno/semana, y las tareas relacionadas con la respuesta a incidentes.
- Problemas de GitLab: la investigación, los análisis y el mantenimiento también se rastrean en las tareas.
- Etiquetas de GitLab: las tareas de automatización se inician según ciertas etiquetas que los bots usan para rastrear la actividad de las tareas.
Externas:
- PagerDuty: alertas
- Slack: aquí se dirige el flujo de mensajes de PagerDuty/AlertManager. Integración con comandos de barra para realizar diversas tareas, como cerrar alertas o escalar a incidentes.
- Grafana: visualización de métricas con un enfoque en tendencias a largo plazo.
- Kibana: proporciona visualización/búsqueda en registros, con la posibilidad de profundizar en eventos específicos.
- Zoom: hay una "sala de discusión" en Zoom que está siempre activa. Esto permite a los ingenieros SRE discutir eventos rápidamente, sin perder tiempo valioso creando la sala y enviando enlaces a los participantes.
Y mucho, mucho más.
4. Monitoreo de GitLab.com usando GitLab — este es un único punto de falla
Si ocurre una gran falla de servicios en GitLab.com, no querríamos que afectara nuestra capacidad para resolver el problema. Se puede mitigar ejecutando una segunda instancia de GitLab para gestionar GitLab.com. De hecho, esto ya está funcionando para nosotros: .
5. Varias funciones que deberían considerarse para agregar a GitLab
- , similar to Google Docs. Esto ayudaría en las tareas de incidentes durante un evento, así como en las tareas de análisis. En ambos casos, a varios participantes les podría ser necesario agregar algo en tiempo real.
- Más webhooks para tareas. La capacidad de ejecutar varios pasos del flujo de trabajo de GitLab desde adentro ayudará a reducir la dependencia de las integraciones de Slack. Por ejemplo, la posibilidad de permitir alertas en PagerDuty a través de un comando de barra en la tarea de GitLab.
Conclusión
Los ingenieros SRE enfrentan muchas complejidades. Sería genial ver más productos de GitLab abordando estos problemas. Ya estamos trabajando en algunas adiciones al producto que facilitarán los flujos de trabajo mencionados anteriormente. Los detalles están disponibles en .
En 2020, estamos ampliando el equipo para reunir todas estas funciones asombrosas. Si estás interesado, por favor revisa las , y no dudes en contactar a alguno de los miembros de nuestro equipo para cualquier pregunta.
Fuente: habr.com
