Qué debe significar la decisión

Un servidor puede estar sano mientras el trabajo del cliente queda bloqueado. Observe el resultado esperado además de errores técnicos. Para cada flujo importante, defina inicio, estados intermedios persistentes y prueba de finalización. La distancia entre ellos puede explicar lo que no muestra un contador de errores.

Roles y alternativas

Empiece por señales accionables. Disponibilidad y respuesta describen la aplicación; antigüedad del trabajo pendiente, fallos de finalización y ausencia anormal de eventos describen el proceso. Google SRE distingue síntomas y causas. Use síntomas visibles para priorizar y detalle técnico para investigar, sin alertar por cada registro aislado.

Recorrer el cambio

En un proceso ficticio de presupuesto, el formulario guarda la solicitud y encola un aviso. La web responde bien, pero el trabajador de correo se detiene. Observe la edad del aviso pendiente más antiguo. La alerta identifica la cola, indica inspección segura y cuándo reintentar. La recuperación exige entregar lo pendiente sin perder ni duplicar la solicitud.

Comprobar los fallos

Un panel tranquilo puede significar falta de demanda, recolector roto o entrada bloqueada. Distíngalos. Evite alertas sin responsable o acción útil, y no incluya mensajes personales. Pause un trabajador local o simule dependencia fallida para comprobar alerta y recuperación.

Dar una respuesta práctica a cada alerta

Para avisos, describa trabajo retrasado, no solo nombre de proceso. Incluya cola, edad del elemento más antiguo, hora de observación y ruta segura de inspección. Excluya mensajes personales. Quien responde debe distinguir trabajador detenido y dependencia de correo fallida sin recibir datos de todos los clientes.

Defina acciones seguras. La guía revisa salud, último error saneado y si el trabajo está reservado o completo. Explique cuándo reintentar, reclamar una reserva vencida o escalar. Repetir todo puede duplicar una acción externa terminada cuya respuesta se perdió. Si no hay certeza, registre y concilie, sin inventar éxito.

Pruebe todo en ambiente controlado: pare el trabajador, cree petición ficticia y observe pendientes. Verifique alerta al destinatario local, reactive y compruebe finalización y recuperación. Pruebe también el recolector; silencio no debe parecer cola vacía sana. Tras incidente, quite ruido duplicado, ajuste responsable y mejore la primera inspección. No suprima síntomas por costumbre. Busque la acción correcta sobre el trabajo correcto.

Lista de revisión operativa

PreguntaPrueba útil
¿Distinguimos sin trabajo y sin medición?La última observación correcta aparece separada de la cantidad pendiente.
¿La alerta tiene responsable?Un rol conoce tiempo de respuesta, inspección y escalado.
¿La recuperación terminó?El trabajo alcanza el estado de negocio; reiniciar proceso no cierra por sí solo el incidente.
¿Reintentar repite efectos?Se revisa evidencia de finalización y resultados externos ambiguos se concilian, no se consideran fallos automáticos.

Acordar estas reglas

¿Qué significa éxito? ¿Cuánto puede esperar el trabajo antes de intervenir? ¿Quién recibe la alerta y qué puede hacer de forma segura? La revisión debe producir un mapa operativo breve, no métricas que nadie utiliza.

Fuentes y otras lecturas

  1. Google SRE — Monitoring distributed systems
Servicios

Software a medida

Software que sigue la forma de trabajar de tu negocio.

Hablemos de este servicio