Ingeniero SRE - Pasante
Primero, permítanme presentarme. Soy @ tristan.read , un ingeniero front-end en el grupo Monitor :: Health de GitLab. La semana pasada, tuve el honor de ser pasante con uno de nuestros ingenieros de SRE en servicio. El objetivo era monitorear diariamente cómo responde el asistente a los incidentes y obtener experiencia laboral real. Nos gustaría que nuestros ingenieros comprendan mejor las necesidades de los usuarios de las funciones Monitor :: Health.
Tuve que seguir al ingeniero de SRE a todas partes durante una semana. Es decir, asistí al turno de servicio, miré los mismos canales de notificación y respondí a los incidentes, siempre y cuando ocurrieran.
Incidentes
Durante la semana ocurrieron 2 incidentes.
1. Cryptominer
El miércoles, GitLab.com vio un salto en su uso de GitLab Runner , causado por los intentos de usar minutos de corredor para extraer criptomonedas. Nos ocupamos del incidente utilizando nuestra propia herramienta para neutralizar las infracciones, lo que detiene las tareas del corredor y elimina el proyecto y la cuenta asociada.
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 violación. Se creó una tarea de incidente, pero la información se cerró.
2. Degradación del rendimiento de las aplicaciones Canarias y Principales.
El incidente fue desencadenado por ralentizaciones y una mayor tasa de error en las aplicaciones web principales y canarias en Gitlab.com. Se han violado varios valores de Apdex.
Tarea de incidente abierto: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442
Resultados clave
Aquí hay algunos puntos que aprendí durante la semana de servicio.
1. Las alertas son más útiles cuando se detectan anormalidades.
Las alertas se pueden dividir en varios tipos:
- Se produjeron alertas basadas en un valor umbral específico como "10 errores 5xx por segundo".
- Alertas en las que el umbral es un valor porcentual del tipo "frecuencia de errores 5xx por 10% del volumen total de solicitudes en un momento dado".
- Alertas basadas en el promedio histórico del tipo "errores 5xx en el percentil 90".
En términos generales, los tipos segundo y tercero son más útiles para los SRE de servicio, ya que revelan desviaciones de la norma en el proceso.
2. Muchas alertas nunca se convierten en incidentes.
Los ingenieros de SR están lidiando con un flujo constante de alertas, muchas de las cuales no son realmente críticas.
Entonces, ¿por qué no limitar las alertas a las realmente importantes? Sin embargo, con este enfoque, uno no puede reconocer los primeros síntomas de lo que crecerá, como una bola de nieve, en un problema real, que amenaza con un daño mayor.
El deber del SRE de turno es determinar qué alertas realmente hablan de algo serio, y si necesitan ser escaladas y comenzar a comprender. Sospecho que esto también es causado por la inflexibilidad de las alertas: sería mejor si se introdujeran varios niveles o formas "inteligentes" de establecer alertas de acuerdo con la situación descrita anteriormente.
Sugerencia de características: https://gitlab.com/gitlab-org/gitlab/issues/42633
3. Nuestros asistentes de SRE usan muchas herramientas.
Interno:
- Proyecto de infraestructura de GitLab: Runbooks en vivo aquí, turnos / semana, tareas de respuesta a incidentes.
- Problemas de GitLab: la investigación, el análisis y el mantenimiento también se rastrean en las tareas.
- Etiquetas de GitLab: las tareas de automatización se lanzan de acuerdo con ciertas etiquetas, mediante las cuales los bots rastrean la actividad de las tareas.
Externo:
- PagerDuty: Alerts
- Slack: el flujo de mensajes PagerDuty / AlertManager va aquí. 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 enfoque en tendencias a largo plazo.
- Kibana: ofrece una visualización / búsqueda en la revista, la capacidad de profundizar en ciertos eventos.
- Zoom: Hay una "sala de discusión" en constante funcionamiento en Zoom. Esto permite a los ingenieros de SRE discutir rápidamente eventos sin perder tiempo valioso creando espacio y enlaces para los participantes.
Y mucho, mucho más.
Si se produce una interrupción importante del servicio en GitLab.com, no queremos que esto afecte nuestra capacidad para resolver el problema. Se puede detener ejecutando la segunda instancia de GitLab para instalar GitLab.com. De hecho, esto ya funciona para nosotros: https://ops.gitlab.net/ .
5. Algunas características a tener en cuenta al agregar a GitLab
- Edición de tareas multiusuario similar a Google Docs. Esto ayudaría con las tareas de incidentes durante el evento, así como las tareas de análisis. En ambos casos, varios participantes pueden necesitar 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 capacidad de habilitar la notificación en PagerDuty a través de un comando de barra diagonal en la tarea GitLab.
Conclusión
Los ingenieros de SRE tienen dificultades con muchas dificultades. Sería genial ver más productos de GitLab para resolver estos problemas. Ya estamos trabajando en algunas adiciones de productos que facilitarán los flujos de trabajo mencionados anteriormente. Los detalles están disponibles en la sección Visión del producto de Ops .
En 2020, estamos ampliando el equipo para reunir todas estas excelentes características. Si está interesado, lea las vacantes y no dude en ponerse en contacto con alguien de nuestro equipo para cualquier pregunta.