Realización de ajustes continuos para reducir las alertas sin sentido
En esta unidad, obtendrá información sobre los procesos que puede implementar para supervisar la fiabilidad del sitio. También obtendrá información sobre los ajustes continuos de las alertas para reducir las que no tienen sentido.
Supervisión y alertas
La supervisión y las alertas permiten que un sistema indique a los usuarios cuándo se ha producido una interrupción o qué se va a interrumpir. Si alguien necesita investigar el problema, la alerta debe proporcionar información relevante para que la persona sepa por dónde empezar.
Cuando revise las alertas existentes o escriba reglas de alerta nuevas, tenga en cuenta estas directrices para mantener la relevancia de las alertas y al usuario de la rotación en llamada más contento:
- Las alertas que desencadenan la atención de una persona deben ser urgentes, importantes, orientadas a la acción y reales.
- Las alertas deben representar problemas continuos o inminentes con el servicio.
- Quitar alertas ruidosas. La supervisión excesiva es un problema más difícil de resolver que la falta de supervisión.
- Clasificar el problema en una de estas categorías:
- Disponibilidad y función básica.
- Latency.
- Corrección.
- Problemas específicos de características.
- Los síntomas son una mejor manera de capturar problemas de forma completa y sólida con menos esfuerzo.
- Incluir información basada en causas en las páginas basadas en síntomas o en los paneles, pero evitar que las alertas se produzcan directamente en las causas.
- Cuanto mayor sea su pila de servicios, más problemas distintos se detectarán en una sola regla. Pero no vaya hasta el punto en el que no pueda distinguir con claridad lo que está ocurriendo.
- Si quiere una rotación en llamada silenciosa, tenga un sistema para tratar con las incidencias que requieren una respuesta puntual, pero que no son críticas de forma inminente.
Supervisión de los usuarios
La supervisión para los usuarios también se denomina supervisión basada en síntomas. Esto contrasta con la supervisión basada en causas. Los usuarios no tienen cuidado si se produce un error en la inserción de datos, es decir, si sus resultados están actualizados.
En general, a los usuarios les importa lo siguiente:
- Disponibilidad y exactitud básicas.: cualquier cosa que interrumpa el servicio principal de alguna manera debe clasificarse como de no disponibilidad.
- Latencia: las páginas deben cargarse con rapidez.
- Integridad, actualización y durabilidad: los datos de los usuarios deben ser seguros, deben volver rápidamente y los índices de búsqueda deben estar actualizados.
- Tiempo de actividad: incluso si el servicio no está disponible temporalmente, los usuarios deben tener confianza plena en que pronto se hará una copia de seguridad del servicio.
- Características: los usuarios se preocupan de que todas las características del servicio funcionen. Supervise cualquier elemento que sea un aspecto importante del servicio, incluso si no es una función básica.
Hay una diferencia sutil, pero importante, entre los servidores de bases de datos que no están disponibles y los datos del usuario que no están disponibles. Lo primero es una causa inmediata, mientras que lo segundo es un síntoma.
Las alertas basadas en causas tienen su lugar
A veces no hay ningún síntoma sobre el que enviar una alerta, pero aun así necesita recibir una alerta sobre una situación. Un ejemplo es quedarse sin memoria. Quiere que las reglas le notifiquen las incidencias que podrían convertirse en un problema antes de que se produzca un síntoma. En este caso, puede escribir una regla para enviar una alerta sobre esta condición,
pero no debe escribir reglas basadas en causas que se desencadenen en alertas en llamada para aquellos síntomas que pueda detectar de otro modo.
Vales, informes y correo electrónico
Las alertas que requieren una pronta atención, pero no inmediata, son alertas subcríticas. A continuación se muestran algunas sugerencias a fin de registrar alertas subcríticas para hacer el seguimiento más adelante:
- Los sistemas de seguimiento de errores o vales pueden ser útiles para este tipo de alerta: una alerta puede abrir un error, siempre y cuando la misma alerta se coloque correctamente en un solo vale o error. Después, estos errores pueden pasar por un proceso de evaluación de prioridades que se va a asignar a alguien para que realice un seguimiento. Es importante que se solucionen estos tipos de incidencias antes de que resulten críticos. Tenga en cuenta la cantidad de tiempo de los miembros del equipo que se puede dedicar a corregir el error.
- Un informe diario (o con más frecuencia) puede resultar útil: escriba alertas subcríticas de larga duración, por ejemplo, si la base de datos está por encima del 90 % de su capacidad, en un informe en el que se muestren todas las alertas activas. Asigne a alguien la evaluación de prioridades de este informe a diario.
- Se debe realizar un seguimiento de todas las alertas a través de un sistema de flujo de trabajo: esto garantiza que se están viendo y solucionando.
En general, cree un sistema que fomente la responsabilidad de la capacidad de respuesta, pero que no tenga el costo elevado de la intervención humana inmediata.
Playbooks
Los cuadernos de estrategias, que a veces se denominan runbooks, son una parte importante de un sistema de alertas. Tenga una entrada en el cuaderno de estrategias que explique qué hacer para cada alerta o familia de alertas que detecten un síntoma.
Seguimiento y responsabilidad
Si alguien recibe una alerta y determina que no hay nada erróneo, es un signo de que debe quitar la regla, degradarla o recopilar datos de otra manera. Las alertas con una precisión inferior al 50 % se consideran interrumpidas. Incluso las que desencadenan falsos positivos el 10 % del tiempo merecen una reevaluación.
Tener una revisión semanal de todas las alertas desencadenadas en llamada y analizar las estadísticas de alertas cada trimestre puede ayudarle a detectar los patrones que se pierden al centrarse en alertas individuales.
¿Cuándo se debe buscar la excepción de la regla?
Estos son algunos de los motivos por los que podría interrumpir las instrucciones anteriores:
Tiene una causa conocida que, en realidad, se encuentra por debajo del ruido en sus síntomas.: por ejemplo, si su servicio tiene una disponibilidad del 99,99 %, pero tiene un evento común que hace que el 0,001 % de las solicitudes generen un error, no se puede enviar una alerta en relación con esto como síntoma porque se encuentra en el ruido, pero puede capturar el evento causante.
No se puede supervisar en el punto de entrada porque se pierde la resolución de datos: por ejemplo, tolera que algunos puntos de conexión sean lentos, como la validación de tarjetas de crédito. En los equilibradores de carga, es posible que se pierda esta distinción. Tendrá que desplazarse por la pila y alertar desde el lugar más alto donde tenga la distinción.
Los síntomas no aparecen hasta que es demasiado tarde: por ejemplo, se ha quedado sin cuota. Debe alertar a alguien antes de que sea demasiado tarde y, a veces, esto significa encontrar una causa sobre la que enviar una alerta. Por ejemplo, la utilización es superior al 80 % y, a la tasa de crecimiento de la última hora, se agotará en menos de cuatro horas.
Pero también debería ser capaz de encontrar una causa similar que sea menos urgente. Por ejemplo, la cuota es superior al 90 % y, a la tasa de crecimiento del último día, se agotará en menos de cuatro días. Este conjunto de circunstancias se detectará en la mayoría de los casos. Después, puede tratar el problema como un vale o una alerta de correo electrónico, o un informe de problemas diarios, en lugar de la escalación de último recurso que representa una alerta.
La configuración de alertas es más compleja que los problemas que intenta detectar: el objetivo debe ser avanzar hacia sistemas sencillos, sólidos y de autoprotección.