Aplicación del marco - Recomendaciones de AWS

Aplicación del marco

La mejor manera de aplicar el marco de análisis de la resiliencia es empezar con un conjunto estándar de preguntas, organizadas por categoría de error, que debe formular sobre cada componente de la historia de usuario que analiza. Si algunas preguntas no se aplican a todos los componentes de su carga de trabajo, utilice las preguntas que sean más pertinentes.

Puede abordar la forma de pensar en los modos de error desde dos perspectivas:

  • ¿Cómo afecta el error a la capacidad del componente para respaldar la historia de usuario?

  • ¿Cómo afecta el error a las interacciones del componente con los demás componentes?

Por ejemplo, si tenemos en cuenta los almacenes de datos y la carga excesiva, puede pensar en los modos de error en los que la base de datos se somete a una carga excesiva y se agota el tiempo de espera de las consultas. También podría pensar en cómo su cliente de base de datos podría sobrecargar la base de datos con reintentos o no cerrar las conexiones de la base de datos, lo que agota el conjunto de conexiones. Otro ejemplo es un proceso de autenticación, que puede constar de varios pasos. Debe pensar en cómo el error de una aplicación de autenticación multifactor (MFA) o de un proveedor de identidades (IdP) externo podría afectar a la historia de un usuario en este sistema de autenticación.

Al responder a las siguientes preguntas, debe tener en cuenta el origen del error. Por ejemplo, ¿la sobrecarga se debió a un aumento de clientes o a un operador humano que puso demasiados nodos fuera de servicio durante una actividad de mantenimiento? Es posible que pueda identificar varios orígenes de error en cada pregunta, lo que podría requerir distintas mitigaciones. Al formular las preguntas, mantenga un registro de los posibles modos de error que detecte, a qué componentes se aplican y el origen de cada error.

Únicos puntos de error

  • ¿El componente está diseñado para ser redundante?

  • ¿Qué ocurre si se produce un error en el componente?

  • ¿Su aplicación es capaz de tolerar la pérdida parcial o total de una única zona de disponibilidad?

Latencia excesiva

  • ¿Qué ocurre si este componente experimenta un aumento de la latencia o si un componente con el que interactúa tiene un aumento de la latencia (o si se producen interrupciones de la red, como un restablecimiento del TCP)?

  • ¿Configuró adecuadamente los tiempos de espera con una estrategia de reintentos?

  • ¿Responde rápido o despacio a los errores? ¿Existen efectos en cascada, como el envío involuntario de todo el tráfico a un recurso con una avería porque responde rápido a los errores?

  • ¿Cuáles son las solicitudes más caras que se hacen a este componente?

Carga excesiva

  • ¿Qué puede agotar los recursos de este componente? ¿Cómo puede este componente agotar los recursos de otros componentes?

  • ¿Cómo puede evitar desperdiciar recursos en un trabajo que nunca se completará correctamente?

  • ¿Tiene un disyuntor configurado para el componente?

  • ¿Puede algo crear un registro de tareas pendientes insuperable?

  • ¿Dónde puede este componente tener un comportamiento bimodal?

  • ¿Qué límites o cuotas de servicio se pueden superar (incluida la capacidad de almacenamiento)?

  • ¿Cómo se escala el componente cuando está bajo carga?

Configuraciones incorrectas y errores

  • ¿Cómo se evita que las configuraciones incorrectas y los errores se implementen en producción?

  • ¿Se puede revertir automáticamente una implementación incorrecta o desviar el tráfico del contenedor de errores en el que se implementó la actualización o el cambio?

  • ¿Qué barreras de protección tiene instaladas para evitar errores de los operadores?

  • ¿Qué elementos (como credenciales o certificados) pueden caducar?

Destino compartido

  • ¿Cuáles son sus límites de aislamiento de errores?

  • ¿Los cambios en las unidades de implementación son al menos tan pequeños como los límites de aislamiento de errores previstos, pero idealmente son más pequeños, como un entorno único (una única instancia dentro del límite de aislamiento de errores)?

  • ¿Este componente se comparte entre las historias de usuario u otras cargas de trabajo?

  • ¿Qué otros componentes tienen un acoplamiento ajustado con este componente?

  • ¿Qué ocurre si este componente o sus dependencias sufren un error parcial o gris?

Después de hacer estas preguntas, también puede utilizar SEEMS para desarrollar otras preguntas específicas para su carga de trabajo y para cada componente. La mejor forma de utilizar SEEMS es como una forma estructurada de pensar en los modos de error como fuente de inspiración al realizar un análisis de la resiliencia. No es una taxonomía rígida. No pierda tiempo preocupándose por la categoría a la que pertenece un modo de error en particular; no es importante. Lo importante es que haya pensado en el error y lo haya anotado. No hay respuestas equivocadas; ser creativo y pensar de forma innovadora es beneficioso. Además, no dé por sentado que un modo de error ya se ha mitigado; incluya todos los posibles modos de error que se le ocurran.

Es poco probable que anticipe todos los posibles modos de error en el primer ejercicio. Las distintas iteraciones del marco lo ayudan a generar un modelo más completo, por lo que no tiene que intentar resolverlo todo a la primera. Puede ejecutar el análisis con una cadencia regular, semanal o quincenal. En cada sesión, céntrese en un modo o componente de error específico. Esto puede ayudar a lograr un progreso constante e incremental en la mejora de la resiliencia de su carga de trabajo. Tras recopilar una lista de posibles modos de error para una historia de usuario, podrá decidir qué hacer al respecto.