Asignar errores a equipos y actualizar el estado de error

Asignar el error al equipo correcto

Desde la página Error group summary , puede asignar el grupo de error al equipo correcto.

Asignar un error a una persona o equipo elimina posibles errores de comunicación. La información que le ayudó a resolver el error se entrega directamente al propietario del código, lo que le permite continuar donde lo dejó.

Luego, la tarea se entrega al equipo por correo electrónico:

Marcar el estado del error

Una vez asignado, puede actualizar el estado de un error.

Esta funcionalidad tiene algunos beneficios diferentes:

• Si se espera un grupo de errores, puede marcar el error como

  Ignored

  . Los errores esperados son conocidos por usted y el equipo; pueden ser errores no críticos o pueden ser errores asociados con el usuario final (como alguien que usa una contraseña incorrecta).

• Sin embargo, recomendamos resolver el error esperado tanto como sea posible. Ignorar un grupo de errores no impide que New Relic informe el error en el futuro, lo que contribuye a la ingesta de datos.

• New Relic rastrea el estado de un error a lo largo del tiempo. Por ejemplo, si marca un grupo de error como

  Resolved

  pero aparece en un momento posterior con un nuevo despliegue, New Relic marcará ese error como

  Regression

  .

Investigar la causa raíz

Ya sea que esté reduciendo errores comunes o reaccionando a una interrupción crítica, está siguiendo datos que lo llevan a la causa directa de un error. Es posible que haya reparado la tubería con fugas que inundó su jardín, pero no ha descubierto qué causó la grieta en primer lugar.

Cuando asigna grupos de errores a equipos, es más fácil realizar retrospectivas en las que todos identifiquen qué procesos llevaron a una interrupción. Para volver a su tubería rota: se reúne con un plomero y le dice que los árboles en su jardín están creciendo en todas sus tuberías. Las retrospectivas en las que todos pueden ver los mismos datos conducen naturalmente a mejoras en el flujo de trabajo general de su equipo.

Estas son algunas de las causas fundamentales comunes de las interrupciones del servicio:

• Pruebas de aseguramiento inadecuadas en pre-entorno de producción.

• No probar cada función o método dentro de una base de código para garantizar que los resultados sean los esperados.

• No entender los requisitos de dependencia ascendente, la capacidad o sus limitaciones. Por ejemplo, si una consulta de la base de datos funciona muy bien en preproducción con cargas más pequeñas, pero bajo estrés comienza a ralentizarse.

• Falta de planificación de capacidad. Tal vez su código pase todas sus pruebas habituales bajo cargas normales, pero cuando la demanda alcanza su punto máximo, no funciona.

  La causa raíz puede ser tan variable como la cantidad de equipos que existen. Sin embargo, la conclusión es seguir los datos, comunicarse y profundizar más allá de la causa directa.