Buenas Prácticas de Solución de Problemas en Producción

Hábitos de prevención que reducen la duración de los incidentes para plataformas Go: SLOs, dashboards, runbooks y respuestas ensayadas.

Aplícalo como una rúbrica de revisión de diseño e higiene trimestral de la plataforma, no solo después de las interrupciones.

Cómo Usar Esta Lista

• Marca los elementos como estándares establecidos de la plataforma, no como notas aspiracionales para el futuro.
• Úsalo en PRs de plantillas de servicio y listas de verificación de lanzamiento para nuevos binarios de Go.
• Combínalo con game days; los runbooks no probados son ficción.
• Vincula las reglas de casilla de verificación a alertas o puertas de CI siempre que sea posible.
• Revisa después de cada post-mortem de SEV-1; agrega una nueva barrera de seguridad por cada clase de incidente.

A - Observabilidad antes de los incidentes

• Expón métricas RED por plantilla de ruta. Las tasas, errores y histogramas de duración potencian el triaje en el primer minuto.
• Exporta sql.DB.Stats() como Prometheus gauges. WaitCount alerta sobre el agotamiento del pool antes de la detención total.
• Rastrea el recuento de goroutines y los percentiles de pausa de GC. El aumento de goroutines y el tiempo de STW preceden a muchos incidentes de memoria.
• Logs estructurados con request_id y trace_id. La correlación reduce el tiempo de búsqueda de logs durante SEV-1.
• Incrusta el SHA de compilación y la versión de Go en /healthz. Correlación de despliegue sin necesidad de buscar en CI.

B - Diagnósticos en tiempo de ejecución listos desde el primer día

• Monta pprof solo en localhost o en puertos de administración autenticados. Nunca expongas /debug/pprof públicamente.
• Documenta los pasos de port-forward y token en el runbook. El personal de guardia no debería descubrir la autenticación durante las alertas.
• Guarda los comandos de captura de perfiles en el script del bundle de incidentes. CPU, heap y goroutines en un solo lugar.
• Ensaya la captura de perfiles bajo carga en staging trimestralmente. Los perfiles inactivos entrenan malos hábitos.
• Evalúa el experimento de perfil de fugas de Go 1.26 en CI de staging. Señal opcional para regresiones en el crecimiento de goroutines.

C - Capacidad y configuración en tiempo de ejecución

• Establece MaxOpenConns a partir de la fórmula de límite de DB / recuento de réplicas. Documenta la aritmética en el README del servicio.
• Alinea GOMEMLIMIT a ~90% del límite de memoria del contenedor. Reduce OOMKilled antes de aumentar ciegamente los límites.
• Establece GOMAXPROCS para que coincida con la cuota de CPU (o usa automaxprocs). La latencia de la cola de ejecución muestra desajustes en los traces.
• Usa QueryContext con deadlines en cada llamada a la base de datos. Las esperas del pool no deben superar los tiempos de espera del cliente.
• Propaga context.Context a todas las goroutines en segundo plano. Reduce la clase de fugas que sobreviven a los reinicios.

D - Disciplina de despliegue y mitigación

• Mantén un comando de reversión a SHA conocido y bueno anterior. Los binarios de Go hacen que la reversión sea rápida cuando existen los artefactos.
• Despliegues Canary en servicios que cambian el estado. Observa p99 y la espera del pool, no solo la tasa de error.
• Congela despliegues arriesgados durante la quema del presupuesto de error. La política supera la heroicidad.
• Feature flags para endpoints pesados. Reduce la carga sin un despliegue de emergencia.
• Apagado elegante con tiempo de espera de Server.Shutdown por debajo del período de gracia de K8s. Evita falsos 5xx durante los despliegues.

E - Proceso y aprendizaje

• Define los niveles de SEV y la escalada por escrito. Todos siguen el mismo playbook.
• Post-mortem sin culpas dentro de los 5 días hábiles para SEV-1/2. La plantilla incluye una tabla de instantáneas del tiempo de ejecución de Go.
• Lista de verificación de traspaso de guardia en cada cambio de turno. Señales específicas de Go, no solo la cola de tickets.
• Game day anual: OOM, agotamiento del pool, despliegue erróneo. La memoria muscular supera la documentación por sí sola.
• Rastrea las acciones del post-mortem hasta su cierre en el mismo sistema de sprints. Las acciones abiertas garantizan la recurrencia.

Cuando Termines

Los niveles A y B deben ser verdaderos antes de cualquier lanzamiento de producción.

Los niveles C a E maduran a lo largo de los trimestres; prioriza los elementos que quemaron presupuesto de error en los últimos dos incidentes.

Si todos los niveles pasan la revisión y el game day tiene éxito, pospón nuevas herramientas hasta la próxima brecha medida.

Preguntas Frecuentes

Relacionados

• Respuesta a Incidentes para Servicios Go - modelo mental de triaje
• Lista de Verificación de Traspaso de Guardia para Plataformas Go - transiciones de turno
• Plantilla de Post-Mortem para Incidentes Go - documento RCA
• Fundamentos de Solución de Problemas en Producción - ejemplos prácticos
• Buenas Prácticas de Observabilidad - base de señales
• Buenas Prácticas de Rendimiento - disciplina de perfilado

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