Ingeniero SRE - becario
Para empezar, déjame presentarme. I - , ingeniero de front-end en el grupo GitLab. La semana pasada, tuve el privilegio de ser pasante con uno de nuestros ingenieros SRE en servicio. El objetivo era observar diariamente cómo responde el oficial de servicio a los incidentes y adquirir experiencia laboral real. Nos gustaría que nuestros ingenieros comprendieran mejor las necesidades de los usuarios. Monitorear::Salud.
Tuve que seguir a la SRE durante una semana. Es decir, estuve presente en la transferencia del deber, observé los mismos canales de alerta y respondí a los incidentes, si ocurrieron y cuando ocurrieron.
Incidentes
Hubo 2 incidentes en una semana.
1. Criptominero
GitLab.com registró un salto en el uso el miércoles 'a, causado por intentos de usar los minutos del corredor para la minería de criptomonedas. El incidente se resolvió mediante una herramienta de mitigación personalizada que detiene las tareas del corredor y elimina el proyecto y la cuenta asociados con él.
Si este evento no se hubiera notado, una herramienta automatizada lo habría detectado, pero en este caso, el ingeniero de SRE fue el primero en notar la infracción. Se creó una tarea de incidente, pero la información sobre ella está cerrada.
2. Degradación del rendimiento de las aplicaciones Canary y Main
El incidente fue provocado por la ralentización y el aumento de las tasas de error en las aplicaciones web Canary y principales en Gitlab.com. Se violaron varios valores de Apdex.
Tarea abierta por incidente:
Hallazgos clave
Aquí hay algunos puntos que aprendí durante la semana de servicio.
1. Las alertas son más útiles cuando se detectan desviaciones de la norma.
Las notificaciones se pueden dividir en varios tipos:
- Alertas basadas en un determinado umbral, como "10 errores 5xx por segundo".
- Alertas donde el umbral es un valor porcentual como "tasa de error 5xx por 10% del total de solicitudes en un momento dado".
- Alertas basadas en un promedio histórico como "5xx errores en el percentil 90".
En términos generales, los tipos 2 y 3 son más útiles para los SRE en servicio, ya que revelan anomalías en el proceso.
2. Muchas alertas nunca escalan a incidentes
Los ingenieros de SR se ocupan de un flujo constante de alertas, muchas de las cuales no son realmente críticas.
Entonces, ¿por qué no limitar las alertas solo a las realmente importantes? Con este enfoque, sin embargo, se pueden pasar por alto los primeros síntomas de lo que se convertirá en un problema real que amenaza con causar daños importantes.
La tarea de la SRE de turno es determinar qué alertas realmente significan algo grave y si es necesario escalarlas y comenzar a resolverlas. Sospecho que esto también se debe a la rigidez de las alertas: sería mejor que introdujeran varios niveles o formas "inteligentes" de personalizar las alertas según la situación descrita anteriormente.
Sugerencia de función:
3. Nuestros SRE utilizan muchas herramientas
Interno:
- Proyecto de infraestructura de GitLab: Runbooks en vivo aquí, traspasos de turnos/semanas, tareas de respuesta a incidentes.
- Problemas de GitLab: la investigación, el informe y el mantenimiento también se rastrean en los problemas.
- Etiquetas de GitLab: las tareas de automatización se activan mediante etiquetas específicas que los bots usan para rastrear la actividad de la tarea.
Externo:
- Alertas de servicio de buscapersonas
- Slack: aquí es donde va el flujo de mensajes de PagerDuty/AlertManager. Integración con comandos de barra para realizar una variedad de tareas, como cerrar una alerta o escalar a un incidente.
- Grafana: visualización de métricas con foco en tendencias a largo plazo.
- Kibana: brinda visualización/búsqueda de registros, la capacidad de profundizar en ciertos eventos.
- Zoom: Hay una "sala de descanso" permanente en Zoom. Esto permite a los SRE discutir eventos rápidamente sin perder un tiempo precioso creando una sala y vinculando a los miembros.
Y mucho, mucho más.
4. Monitorear GitLab.com con GitLab es un único punto de falla
Si GitLab.com experimenta una interrupción importante del servicio, no queremos que afecte nuestra capacidad para resolver el problema. Se puede detener ejecutando una segunda instancia de GitLab para administrar GitLab.com. De hecho, esto ya nos funciona: .
5. Algunas características para considerar agregar a GitLab
- , similar a Documentos de Google. Esto ayudaría en las tareas de incidentes durante el evento, así como en las tareas de debriefing. En ambos casos, es posible que varios participantes necesiten agregar algo en tiempo real a la vez.
- Más webhooks para tareas. La capacidad de ejecutar varios pasos de flujo de trabajo de GitLab desde dentro ayudará a reducir su dependencia de las integraciones de Slack. Por ejemplo, la capacidad de habilitar una alerta en PagerDuty a través de un comando de barra diagonal en un problema de GitLab.
Conclusión
Los ingenieros de SRE tienen dificultades con muchas complejidades. Sería genial ver más productos de GitLab que aborden estos problemas. Ya estamos trabajando en algunas adiciones al producto que facilitarán los flujos de trabajo mencionados anteriormente. Las piezas están disponibles en .
En 2020, estamos ampliando el equipo para reunir todas estas excelentes funciones. Si está interesado, consulte , y no dude en ponerse en contacto con alguien de nuestro equipo si tiene alguna pregunta.
Fuente: habr.com