Escaladas. Escenarios típicos

Publicado: Alex Shashenko 2014-06-12 all articles | Glossary | FAQ

Me despertó un SMS a las tres de la madrugada.
Mi sitio se cayó durante tres minutos y volvió a levantarse solo.
Pero no pude volver a dormirme.

Historia real

Como muchos saben, HostTracker es un sistema de monitorización de la eficiencia de los sitios. Una de sus principales funciones es notificar al usuario de cualquier problema con prontitud. La eficiencia de las notificaciones y el nivel aceptable de “detalización” son importantes. Si envía alertas en cada “estornudo”, la persona no encontrará la información importante en este flujo.

Hemos previsto varios mecanismos que ayudarán a las personas adecuadas a recibir las notificaciones necesarias:

  • Separación de las notificaciones en varios grupos según su criticidad;
  • Ausencia de notificaciones en los fallos a corto plazo;
  • Notificar el problema al gestor con prontitud;
  • Notificar un fallo prolongado a la administración;
  • Utilice primero las alertas gratuitas - correo electrónico, gtalk, y después las de pago - SMS o llamada telefónica;
  • A nivel de contacto - establecer el horario de trabajo en el que este contacto debe recibir las alertas.

Hay tres tipos de notificaciones:

  • El sitio web ha "caído";
  • El sitio web sigue "caído";
  • El sitio web "subió

Las notificaciones "cayó" y "subió" son claras. Las notificaciones "el sitio sigue caído" se envían en cada fallo de prueba, pero sólo en las caídas confirmadas. El algoritmo de confirmación de fallos se describió en el artículo "Exclusión de falsas alertas"

Para cada par sitio-contacto puede activar o desactivar el tipo de notificación apropiado. La configuración se puede encontrar en las propiedades del contacto, así como en la "matriz" general en la página "Suscripción de notificaciones".

Escalado y nivel de detalle de las notificaciones.

Supongamos que dos personas son responsables del sitio:

  • Administrador
  • Administrador

Intentemos implementar el siguiente escenario:

  • En caso de "caída", queremos enviar inmediatamente un mensaje de correo electrónico al administrador;
  • Si el sitio no se levanta en 15 minutos, enviamos un SMS al administrador;
  • Si el sitio está "caído" durante más de una hora, enviamos un SMS al administrador.
  • Añadir los contactos para los usuarios. Al añadirlos, llama la atención sobre la ventana "Retraso de notificación".

Parece que tenemos tres contactos con los siguientes retrasos:

  • Administrador (correo electrónico) - sin retraso;
  • Administrador (SMS) - 15 minutos de retraso;
  • Administrador (SMS) - 1 hora de retraso.

Según esta configuración el administrador recibirá todas las notificaciones de fallos al correo electrónico, pero las notificaciones por SMS se enviarán sólo si el sitio está "caído" durante más de 15 minutos. El administrador sólo recibirá SMS sobre fallos importantes que duren más de una hora. Configuración del horario de trabajo de los contactos

Supongamos que un administrador no da abasto y contratamos a otro más. El primero trabaja durante la primera mitad de la semana, el segundo trabaja durante la segunda mitad. En consecuencia las notificaciones deben ser enviadas al administrador "de guardia" Para establecer este escenario se utiliza la ventana "Establecer el horario de trabajo del contacto" en la configuración del contacto.

En este caso el primer administrador recibirá las notificaciones SMS de lunes a jueves inclusive. Además, puede dividir la notificación para diferentes empleados según la hora del día, por ejemplo, designando administradores diurnos y nocturnos.

Conclusiones: con la ayuda de mecanismos relativamente sencillos podemos cubrir la mayoría de los escenarios de usuario de las notificaciones.


Sobre el autor

Oleksii Shashenko
Director de Comunicaciones y Tecnología de HostTracker. Alex forma parte del equipo desde los inicios de la empresa. Su trabajo se centra en la elaboración de informes empresariales, el análisis de estadísticas de bases de datos y la administración de sistemas. Alex también se encarga de la comunicación con el equipo de desarrollo y los clientes.
Loading...