Lista de verificación de traspaso de guardia para plataformas Go

Los ingenieros de guardia salientes documentan el estado de la plataforma para que el ingeniero de guardia entrante comience con contexto, no con un buscapersonas en blanco.

Utilice esta lista de verificación en cada cambio de turno para microservicios, workers y niveles gRPC de Go.

Cómo usar esta lista de verificación

• Complete dentro de los 30 minutos posteriores al final del turno; el ingeniero entrante acusa recibo por escrito.
• Enlace a paneles y tickets; no dependa de la transferencia solo verbal.
• Marque N/A para turnos tranquilos, pero aún así confirme el enrutamiento de alertas y el estado de la congelación de implementaciones.
• Almacene la nota de traspaso en el canal del equipo o en la plantilla de ticket para que sea buscable.
• Escalar incidentes abiertos SEV-1/2 con un puente en vivo, no solo con notas asíncronas.

Resumen del estado de la plataforma

1. Incidentes activos: Enumere SEV, estado, mitigación actual, próxima hora de verificación.
   • Abierto: enlace al canal del incidente y al comandante.
   • Ninguno: indique explícitamente "no hay SEV-1/2 activos".
2. Implementaciones recientes (últimas 24 horas): Servicio, SHA, estado del canary, regresiones conocidas.
   • Incluya la etiqueta de imagen de Go y cualquier cambio en las variables de entorno GOMEMLIMIT / GOGC.
3. Presupuesto de errores / quema de SLO: Qué servicios están en amarillo o rojo.
   • Tenga en cuenta si la quema solo de latencia sin un pico de errores (sospechosos de GC/pool).
4. Estado de las dependencias: Fallo de failover de la base de datos, inestabilidad de la caché, interrupciones de upstream.
   • Separe los problemas de la plataforma compartida del ruido de un solo servicio.

Tiempo de ejecución y capacidad de Go

5. Memoria y OOM: Cualquier pod OOMKilled en el último turno; límites vs GOMEMLIMIT.
   • Enlace a los paneles de heap/goroutine.
6. GC / anomalías de latencia: Aumentos inexplicables en p99; gráficos de pausa de GC.
   • Tenga en cuenta los canaries de actualización de Go 1.26 si corresponde.
7. Tendencias de Goroutine: Servicios con líneas base de goroutines en aumento.
   • Enlace a tickets abiertos para investigaciones de fugas.
8. Grupos de conexiones: Métricas de espera de sql.DB elevadas en cualquier nivel.
   • Documente los experimentos de MaxOpenConns en curso.
9. Cambios de HPA / réplicas: Eventos de escalado automático durante picos o incidentes.
   • Advierte si la duplicación de réplicas afecta las matemáticas de las conexiones de la base de datos.

Acceso a herramientas

10. pprof / acceso de administración: Fechas de rotación de tokens, enlaces a runbooks de reenvío de puertos.
    • Confirme que el ingeniero entrante tenga acceso a VPN/k8s a los puertos de administración.
11. Sistemas de registro y rastreo: Consultas guardadas para los principales servicios.
    • Incluya ejemplos de búsqueda de request_id.
12. Palancas de reversión: Quién puede aprobar la reversión de producción; último SHA exitoso por servicio.
    • Enlace a la consola de feature flag para interruptores de apagado.
13. Rutas de escalada: Secundarios, EM, contactos de proveedores para base de datos/nube.
    • Zonas horarias de los mantenedores upstream.

Trabajo abierto y riesgos

14. Mitigaciones en curso: Ajuste de GC de Canary, redimensionamiento de pool, flag al 50%.
    • Finalización esperada y criterios de éxito.
15. Mantenimiento programado: Migraciones, renovaciones de certificados, game days.
    • ¿Conflicto con la cobertura de guardia?
16. Alertas inestables: Alertas silenciadas o con umbrales ajustados temporalmente.
    • Hora de vencimiento del silencio; propietario para arreglar la alerta raíz.
17. Deuda técnica conocida: Servicios sin GOMEMLIMIT, riesgo de pprof público, falta de exportación de WaitCount.
    • Rango de riesgo para la concienciación del entrante.
18. Acciones de post-mortem pendientes: P0/P1 abiertos de incidentes anteriores.
    • Propietario si está vencido.

Reconocimiento del ingeniero entrante

19. Nombre del ingeniero entrante y hora de inicio: <nombre, UTC>.
20. Preguntas aclaradas: Enumere cualquier ambigüedad resuelta en vivo.
21. Estado del puente: Permanezca en el puente si hay un SEV-1 activo; de lo contrario, está bien de forma asíncrona.

Aplicación de la lista de verificación en orden

• Elementos 1-4: Primero la imagen del cliente y del SLO: el ingeniero entrante necesita contexto de impacto.
• Elementos 5-9: Señales específicas de Go que los traspasos de infraestructura genéricos omiten.
• Elementos 10-13: Acceso y palancas: verifique antes de que el saliente cierre sesión.
• Elementos 14-18: Riesgo prospectivo para que el próximo turno no se sorprenda.
• Elementos 19-21: Cierre el ciclo con el reconocimiento explícito.

Preguntas frecuentes

Relacionado

• Respuesta a incidentes para servicios Go - descripción general de la clasificación
• Plantilla de Post-Mortem para Incidentes Go - estructura de RCA
• Conceptos básicos de solución de problemas de producción - herramientas de primer paso
• Mejores prácticas de solución de problemas de producción - hábitos de prevención
• Sondas de salud, preparación y vivacidad - comportamiento de las sondas
• Métricas de Prometheus y paneles RED-USE - paneles

Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado Green Tea GC, go fix modernizers - verificar parche en la compilación), chi (última versión - verificar en la compilación), gin (última versión - verificar en la compilación), echo (última versión - verificar en la compilación), google.golang.org/grpc (última versión - verificar en la compilación), sigs.k8s.io/controller-runtime (última versión - verificar en la compilación), kubebuilder (última versión - verificar en la compilación), tinygo (última versión - verificar objetivos de placa en la compilación), wazero (última versión - verificar en la compilación) y golangci-lint (última versión - verificar conjunto de linters en la compilación).