¿Cuál es la causa de la notificación? Un mensaje a Servicio de notificación simple de Amazon tema.
¿Qué envió el mensaje? A CloudWatch alarma. Amazon CloudWatch permite definir una alarma y una acción a ejecutar cuando se activa una alarma, como publicar un mensaje SNS.
El número de errores HTTP 500 por hora es una métrica disponible para varios servicios de AWS, como API Gateway. Se puede configurar una alarma para que se dispare si esta métrica es distinta de cero.
Excepciones
¿Qué causó que la tubería de procesamiento de solicitudes devolviera el código de estado 500? Podría haber varias razones, pero todas ellas dan lugar a una excepción no gestionada o, en algunos casos, a un bloqueo del procesador de solicitudes.
Los frameworks de servicios HTTP tienen un gestor de errores por defecto que genera respuestas 500 si se produce una excepción que no es gestionada por el procesador de peticiones. Por lo tanto, si se produce una excepción que no es gestionada explícitamente por el procesador de peticiones, el usuario ve un error interno del servidor.
Otra posibilidad es que el procesador de solicitudes se haya bloqueado y no se haya ejecutado el gestor de errores predeterminado. En este caso, API Gateway devuelve 502.
Las causas pueden ser desde mundanas hasta esotéricas. Veamos algunas de ellas.
Una común son las excepciones de referencia nula - usar una referencia de objeto sin validar que no es nula.
Un tipo similar de error es no validar los parámetros de la API. Por ejemplo, el uso de una cadena proporcionada por el usuario como nombre de un bucket de S3 sin validación podría hacer que la operación de creación de un bucket fallara y lanzara una excepción.
Lo que nos lleva al siguiente tipo de error: no validar las respuestas de otros servicios. La creación de un bucket de S3 puede fallar por una multitud de razones - nombre inválido u otros parámetros, nombre ya en uso, falta de permisos, o una interrupción del servicio. El procesador de peticiones debe estar preparado para hacer frente a este tipo de errores.
Mitigación
Mantener los buscapersonas en silencio por la noche requiere múltiples capas de defensa. Se puede hacer mucho antes de que se libere un servicio (o una actualización), pero también es imperativo prepararse para circunstancias imprevistas.
Mitigación previa al lanzamiento
Diseño
Comienza en el momento del diseño: ¿cómo gestionará el servicio un mal estado? Considera qué dependencias tendrá el servicio y cómo pueden fallar. ¿Qué se necesita para que el fallo se limite a una sola solicitud o a un solo usuario? ¿Cómo afectará al usuario? ¿Cómo puede recuperarse?
Los impactos en la seguridad merecen consideraciones aparte: ¿cómo puede un usuario malintencionado hacer un mal uso de las funciones previstas? ¿Cómo debe protegerse el servicio contra ellos?
Pruebas unitarias
Durante la implementación, las pruebas unitarias son la primera línea de defensa. Además, cree pruebas unitarias que reproduzcan escenarios específicos identificados durante el diseño.
Las pruebas unitarias son baratas de ejecutar y las más rápidas en proporcionar información.
Pruebas de integración
Lo siguiente son las pruebas de integración para verificar el comportamiento del servicio de extremo a extremo.
Una vez que existan, haz que formen parte del proceso de compilación: rechaza los cambios que no superen las pruebas de integración. Esto garantiza que la calidad del código no se deteriore.
Mitigación posterior al lanzamiento
Incluso con nuestros mejores esfuerzos, surgen situaciones imprevistas que pueden causar errores en el servicio. Equipe a los ingenieros de fiabilidad del sitio con herramientas para recuperarse de los errores de forma eficaz. Estas herramientas son las pruebas canarias, los libros de ejecución y la API de operaciones.
Pruebas canarias
Una vez que el servicio está en marcha, pueden utilizarse pruebas canarias para confirmar que funciona con normalidad. Las pruebas canarias son pruebas de integración que se ejecutan periódicamente contra despliegues de producción. Su fallo es una advertencia temprana de que los usuarios se verán afectados.
Las métricas y alarmas deben derivarse de los resultados de las pruebas canarias para garantizar que éstas se ejecutan y se superan.
Runbooks
Los Runbooks documentan los procesos para recuperar los datos y servicios de los usuarios a un buen estado. Incluyen pasos para investigar errores y recuperar datos de usuarios o servicios.
API de operaciones
La API de operaciones ayuda a automatizar pasos comunes o complicados. Por ejemplo, una API útil sería restaurar datos de usuario a partir de copias de seguridad o eliminar en bloque datos obsoletos o erróneos.
Deben estar restringidas a usuarios específicos y, dependiendo de la gravedad, incluir un paso de aprobación como parte de su flujo de trabajo.
Días de juego
Es imposible prever en el momento del diseño los distintos modos de fallo de un servicio en la nube. Los Game Days son un proceso para observar cómo responde el servicio a los errores. Son como recreaciones de la guerra civil: el equipo elabora una lista de escenarios de error, idea un proceso para inducirlos y, a continuación, provoca los errores y se ocupa de ellos como si fueran reales.
Por ejemplo, ¿qué ocurre si el servicio S3 no está disponible? ¿Cómo se comporta el servicio? ¿Cómo responde la organización? ¿Se activan las alarmas correctas? ¿Se notifica a las personas adecuadas? ¿Disponen de las herramientas para mitigar el problema y comunicarlo a todas las partes interesadas?
Construir la excelencia operativa
Desde el punto de vista de la implementación, las herramientas operativas como los libros de ejecución, los días de juego y la API de operaciones se basan en dos cosas: los indicadores de características y la capacidad de observación.
Indicadores de características
Los indicadores de características pueden aplicarse de varias maneras:
Una forma de implementar la simulación de cortes de servicio para los días de juego,
Una forma de desactivar funciones para clientes o para todo el servicio en caso de errores transitorios.
Observabilidad
La observabilidad es un término genérico que engloba prácticas y técnicas que permiten comprender el estado interno de un servicio mediante salidas externas. En la práctica, significa garantizar que el servicio genera métricas, registros y trazas suficientes para darse cuenta de que algo ha ido mal y comprender cómo ha sucedido.
Por ejemplo, si el procesamiento de una solicitud falla debido a un error del servicio S3, ¿se registra el error de S3? ¿Qué ocurre con los parámetros de solicitud de S3? Basándose en los registros de servicio, ¿puede el ingeniero de guardia entender por qué la gestión de esta solicitud requería esta llamada a S3 en este momento concreto?
Tener una alta cobertura de observabilidad hace que sea fácil determinar la causa raíz de un error y ayuda a escribir pruebas unitarias, de integración o canarias para asegurar que el escenario de error se maneje mejor en el futuro.
Para consultores de software
Los errores internos del servidor indican una brecha crítica en la comprensión de su producto por parte del equipo de servicio. La gravedad de su impacto puede variar enormemente. Su aparición puede desencadenar procesos correctivos que consumen tiempo e ingresos. Por tanto, es imperativo que nuestros productos no sean la fuente de estos errores y que proporcionemos a nuestros clientes las herramientas y los conocimientos necesarios para evitarlos, detectarlos y gestionar sus consecuencias.
Póngase en contacto con Improving para mejorar sus servicios de API REST con sólidas estrategias de gestión de errores y prácticas de excelencia operativa.
