Reduciendo MTTR

Una vez detectada una avería, el resto del MTTR tiempo se destinará a la reparación real o a la mitigación del impacto. Para reparar o mitigar un error, hay que saber qué es lo que está mal. Hay dos grupos clave de métricas que proporcionan información durante esta fase: 1/las métricas de evaluación del impacto y 2/las métricas del estado operativo. El primer grupo indica el alcance del impacto durante un error y mide el volumen o el porcentaje de clientes, recursos o cargas de trabajo afectados. El segundo grupo ayuda a identificar por qué se produce un impacto. Una vez identificado el motivo, los operadores y sistemas de automatización pueden responder al error y solucionarlo. Consulte el apéndice 1 MTTD y las métricas MTTR críticas para obtener más información sobre estas métricas.

Regla 9

La observabilidad y la instrumentación son fundamentales para reducir MTTD y. MTTR

Cómo sortear los errores

El enfoque más rápido para mitigar el impacto es mediante subsistemas que responden rápido a los errores y los sortean. Este enfoque utiliza la redundancia para reducir MTTR al transferir rápidamente el trabajo de un subsistema defectuoso a uno de repuesto. La redundancia puede abarcar desde procesos de software hasta EC2 instancias, múltiples o múltiples AZs regiones.

Los subsistemas de repuesto pueden MTTR reducirla prácticamente a cero. El tiempo de recuperación es lo único que se necesita para redirigir el trabajo al equipo de reserva o de repuesto. Esto suele ocurrir con una latencia mínima y permite que el trabajo se complete dentro de lo definidoSLA, manteniendo la disponibilidad del sistema. Esto produce MTTRs que se experimenten como retrasos leves, quizás incluso imperceptibles, en lugar de períodos prolongados de falta de disponibilidad.

Por ejemplo, si su servicio utiliza EC2 instancias detrás de un Application Load Balancer ALB (), puede configurar las comprobaciones de estado en un intervalo de tan solo cinco segundos y requerir solo dos comprobaciones de estado fallidas antes de que un objetivo se marque como en mal estado. Esto significa que, en 10 segundos, se puede detectar un error y dejar de enviar tráfico al host en mal estado. En este caso, MTTR es prácticamente el mismo que el anterior, MTTD ya que tan pronto como se detecta el error, también se mitiga.

Esto es lo que intentan lograr las cargas de trabajo de alta disponibilidad o disponibilidad continua. Queremos sortear rápidamente los errores en la carga de trabajo mediante la detección rápida de los subsistemas con errores, los marcamos como tal, dejamos de enviarles tráfico y, en su lugar, lo enviamos a un subsistema redundante.

Tenga en cuenta que el uso de este tipo de mecanismos que responden rápido a los errores hace que la carga de trabajo sea muy sensible a los errores transitorios. En el ejemplo que mostramos, asegúrese de que las comprobaciones de estado del equilibrador de carga se realicen de forma superficial o de manera dinámica y local para solamente la instancia, y de que las pruebas no se lleven a cabo para dependencias y flujos de trabajo (a menudo denominadas comprobaciones de estado exhaustivas). Esto ayudará a evitar la sustitución innecesaria de instancias durante errores transitorios que afecten a la carga de trabajo.

La observabilidad y la capacidad de detectar errores en los subsistemas son fundamentales para evitarlos de manera satisfactoria. Hay que conocer el alcance del impacto para que los recursos afectados puedan marcarse como en mal estado o con errores, y que queden fuera de servicio para poder sortearlos. Por ejemplo, si una única AZ sufre una interrupción parcial del servicio, su instrumentación deberá poder identificar que existe un problema localizado en la AZ para poder distribuir todos los recursos de esa AZ hasta que se recupere el servicio.

Ser capaz de sortear un error también puede requerir herramientas adicionales en función del entorno. Si utilizamos el ejemplo anterior con EC2 instancias detrás de una zona de ALB disponibilidad, imagine que las instancias de una zona de disponibilidad podrían estar pasando las comprobaciones de estado locales, pero que un fallo de zona de disponibilidad aislado hace que no puedan conectarse a su base de datos en una zona de disponibilidad diferente. En este caso, las comprobaciones de estado del equilibrio de carga no dejarán esas instancias fuera de servicio. Se necesitaría un mecanismo automatizado diferente para eliminar la AZ del equilibrador de carga o forzar que las instancias no superen las comprobaciones de estado, lo que depende de haber identificado que el alcance del impacto es una AZ. En el caso de las cargas de trabajo que no utilizan un equilibrador de carga, se necesitaría un método similar para evitar que los recursos de una AZ específica acepten unidades de trabajo o eliminen completamente la capacidad de la zona.

En algunos casos, el traslado del trabajo a un subsistema redundante no se puede automatizar, como la conmutación por error de una base de datos principal a una secundaria, en la que la tecnología no elige a su propio líder. Este es un escenario común en las arquitecturas de varias regiones de AWS. Dado que estos tipos de conmutación por error requieren cierto tiempo de inactividad, no se pueden revertir de forma inmediata y dejan la carga de trabajo sin redundancia durante un período de tiempo, es importante contar con una persona que participe en el proceso de toma de decisiones.

Las cargas de trabajo que pueden adoptar un modelo de coherencia menos estricto pueden acortarse si utilizan la automatización de la conmutación MTTRs por error multirregional para evitar los errores. Características como la replicación entre regiones de Amazon S3 o las tablas globales de Amazon DynamoDB brindan prestaciones de varias regiones a través de una replicación eventualmente coherente. Además, usar un modelo de consistencia relajada es beneficioso si tenemos en cuenta el teorema. CAP Cuando se producen errores de red que afectan a la conectividad con los subsistemas activos, si la carga de trabajo elige la disponibilidad en lugar de la coherencia, puede seguir proporcionando respuestas sin errores, lo que supone otra forma de sortear los errores.

Los errores pueden sortearse con dos estrategias diferentes. La primera estrategia consiste en implementar la estabilidad estática mediante el aprovisionamiento previo de recursos suficientes para gestionar toda la carga del subsistema con errores. Puede ser una EC2 instancia única o puede ser una capacidad completa de AZ. Si se intenta aprovisionar nuevos recursos durante un error, se incrementa el plano de control de la ruta de recuperación MTTR y se añade una dependencia al mismo. Sin embargo, conlleva un costo adicional.

La segunda estrategia consiste en enrutar parte del tráfico del subsistema con errores a otros y desbordar la carga con el exceso de tráfico que no pueda ser gestionado por la capacidad restante. Durante este período de degradación, se pueden escalar verticalmente nuevos recursos para sustituir la capacidad fallida. Este enfoque es más prolongado MTTR y crea una dependencia de un plano de control, pero cuesta menos si se trata de capacidad de reserva y sobrante.

Vuelta a un estado válido conocido

Otro enfoque habitual de mitigación durante la reparación consiste en devolver la carga de trabajo a un estado válido conocido anterior. Si un cambio reciente pudo haber provocado el error, revertir ese cambio es una forma de volver al estado anterior.

El error también podría deberse a condiciones transitorias, en cuyo caso, reiniciar la carga de trabajo podría mitigar el impacto. Vamos a analizar ambos escenarios.

Durante una implementación, se minimiza MTTD y MTTR se basa en la observabilidad y la automatización. El proceso de implementación debe vigilar continuamente la carga de trabajo para detectar la introducción de un aumento en los índices de error, un aumento de la latencia o la aparición de anomalías. Una vez se detectan estos problemas, el proceso de implementación debería interrumpirse.

Existen varias estrategias de implementación, como las implementaciones locales, las implementaciones azules/verdes o las implementaciones continuas. Cada una de ellas puede utilizar un mecanismo diferente para volver a un estado válido conocido. Puede restaurar automáticamente el estado anterior, devolver el tráfico al entorno azul o requerir una intervención manual.

CloudFormation ofrece la capacidad de revertirse automáticamente como parte de sus operaciones de creación y actualización de pilas, al igual que lo hace. AWS CodeDeploy CodeDeploy también es compatible con despliegues azul/verde y continuos.

Para aprovechar estas capacidades y minimizar las suyasMTTR, considere la posibilidad de automatizar todas las implementaciones de código e infraestructura a través de estos servicios. En los casos en los que no pueda utilizar estos servicios, considere la posibilidad de implementar el patrón Saga AWS Step Functions para revertir las implementaciones fallidas.

A la hora de plantearse el reinicio, existen varios enfoques diferentes. Estos van desde reiniciar un servidor (la tarea más larga) hasta reiniciar un subproceso (la tarea más corta). Esta tabla define algunos de los métodos de reinicio y los tiempos aproximados para completarlos (representativos de diferencias de órdenes de magnitud; no son exactos).

Mecanismo de recuperación de errores	Estimación MTTR
Iniciar y configurar un servidor virtual nuevo	15 minutos
Reimplementar el software	10 minutos
Reiniciar el servidor	5 minutos
Reiniciar o iniciar el contenedor	2 segundos
Invocar una nueva función sin servidor	100 ms
Reiniciar el proceso	10 ms
Reiniciar el subproceso	10 μs

Si revisamos la tabla, podemos ver algunos beneficios evidentes del uso MTTR de contenedores y funciones sin servidor (por ejemplo AWS Lambda). MTTRSon órdenes de magnitud más rápidas que reiniciar una máquina virtual o lanzar una nueva. Sin embargo, utilizar el aislamiento de errores mediante la modularidad del software también conlleva una serie de ventajas. Si puede contener un error en un solo proceso o subproceso, recuperarse de ese error es mucho más rápido que reiniciar un contenedor o un servidor.

Como enfoque general para la recuperación, puede ir de abajo a arriba: 1/Reiniciar un componente, 2/Reiniciar el sistema completo, 3/Recrear la imagen/reimplementar y 4/Reemplazar. Sin embargo, una vez completado el proceso de reinicio del sistema completo, la solución al error suele ser más rápida (normalmente tarda entre 3 y 4 minutos como máximo). Por lo tanto, para mitigar el impacto de la forma más rápida posible tras un intento de reinicio, sortee el error y, en segundo plano, continúe con el proceso de recuperación para recuperar la capacidad de la carga de trabajo.

Regla 10

Concéntrese en la mitigación del impacto, no en la solución del problema. Recupere el funcionamiento normal por la vía más rápida.

Diagnóstico de errores

Parte del proceso de reparación después de la detección es el período de diagnóstico. Es el período de tiempo en el que los operadores tratan de determinar qué es lo que está mal. Este proceso puede implicar consultar registros, revisar métricas del estado operativo o iniciar sesión en los hosts para solucionar problemas. Todas estas acciones requieren tiempo, por lo que crear herramientas y manuales para agilizarlas también puede ayudar a reducirlas. MTTR

Manuales de procedimientos y automatización

Del mismo modo, después de determinar qué es lo que está mal y qué medidas tomar para reparar la carga de trabajo, los operadores suelen tener que realizar una serie de pasos para completar el proceso. Por ejemplo, después de un error, la forma más rápida de reparar la carga de trabajo puede ser reiniciarla, lo que puede implicar varios pasos ordenados. El uso de un manual de procedimientos que automatice estos pasos o proporcione instrucciones específicas al operador agilizará el proceso y ayudará a reducir el riesgo de que se tomen medidas involuntarias.