Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
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
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
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
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
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
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.