El proceso de revisión - AWS Well-Architected Framework

El proceso de revisión

La revisión de las arquitecturas debe realizarse de manera consistente, con un enfoque sin culpa que fomente la inmersión profunda. Debe ser un proceso rápido (de horas, no días), es decir, una conversación y no una auditoría. El propósito de revisar una arquitectura consiste en identificar cualquier problema crítico que deba abordarse o áreas que podrían mejorarse. El resultado de la revisión es un conjunto de acciones que deberían mejorar la experiencia de un cliente que utiliza la carga de trabajo.

Como se debatió en la sección «Arquitectura local», querrá que cada miembro del equipo asuma la responsabilidad de la calidad de su arquitectura. Recomendamos que los miembros del equipo que construyen una arquitectura usen el Marco de Buena Arquitectura para comprobar continuamente su arquitectura, en lugar de realizar una reunión de revisión formal. Un enfoque continuo permite a los miembros de su equipo actualizar las respuestas a medida que evoluciona la arquitectura y mejorar la arquitectura a medida que ofrece funciones.

AWS Well-Architected Framework se corresponde con la forma en que AWS revisa los sistemas y servicios internamente. Se basa en un conjunto de principios de diseño que influyen en el enfoque arquitectónico y en cuestiones que aseguran que las personas no descuiden las áreas que suelen aparecer en el análisis de causa raíz (RCA). Siempre que haya un problema importante con un sistema interno, un servicio de AWS o un cliente, observamos el RCA para comprobar si podemos mejorar los procesos de revisión que utilizamos.

Las revisiones deben aplicarse a hitos clave en el ciclo de vida del producto, al principio de la fase de diseño, para evitar caminos de un solo sentido difíciles de cambiar, y justo antes de la fecha de lanzamiento. (Muchas decisiones son reversibles, son caminos bidireccionales. Estas decisiones pueden basarse en un proceso superficial. Las caminos unidireccionales son difíciles o imposibles de revertir y requieren más inspección antes de iniciarlos). Tras entrar en producción, su carga de trabajo continuará evolucionando a medida que añada nuevas funciones y cambie las implementaciones de tecnología. La arquitectura de una carga de trabajo cambia con el tiempo. Deberá seguir buenas prácticas de higiene para evitar que sus características arquitectónicas se degraden a medida que evoluciona. Si realiza cambios significativos en la arquitectura, debe seguir un conjunto de procesos de higiene, incluida una revisión Well-Architected.

Si desea utilizar la revisión como una instantánea única o una medición independiente, querrá asegurarse de incluir a todas las personas adecuadas en la reunión. A menudo, descubrimos que las revisiones representan la primera vez que un equipo realmente comprende lo que ha implementado. Un enfoque que funciona bien cuando se revisa la carga de trabajo de otro equipo consiste en organizar una serie de reuniones informales sobre su arquitectura, donde pueda obtener respuestas a la mayoría de las preguntas. Puede realizar un seguimiento con una o dos reuniones para aclarar o profundizar en áreas de ambigüedad o riesgo percibido.

A continuación, se presentan algunos elementos sugeridos para facilitar sus reuniones:

  • Una sala de reuniones con pizarras blancas

  • Impresión de diagramas o notas de diseño

  • Lista de acciones de preguntas que requieren una investigación innovadora para responder (por ejemplo, ¿habilitamos el cifrado o no?)

Tras haber realizado una revisión, debe tener una lista de problemas que puede priorizar según el contexto de su negocio. También querrá tener en cuenta el impacto de dichos problemas en el trabajo diario de su equipo. Si aborda estos problemas con antelación, podría dedicarle más tiempo a trabajar en la creación de valor empresarial en lugar de resolver problemas recurrentes. A medida que aborde los problemas, puede actualizar su revisión para ver cómo mejora la arquitectura.

Dado que el valor de una revisión es claro tras completarla, es posible que, al principio, un nuevo equipo sea reticente. Aquí hay algunas objeciones que se pueden manejar formando al equipo sobre los beneficios de una revisión:

  • «¡Estamos demasiado ocupados!» (Se suele decir cuando el equipo se está preparando para un gran lanzamiento).

    • Si se está preparando para un gran lanzamiento, deseará que vaya perfectamente. La revisión le permitirá detectar cualquier problema que pueda haber pasado por alto.

    • Recomendamos que realice revisiones al principio del ciclo de vida del producto para descubrir riesgos y desarrollar un plan de mitigación conforme a la hoja de ruta de entrega de características.

  • «¡No tenemos tiempo para tener en cuenta los resultados!» (Se suele decir cuando el objetivo es un evento inamovible, como la Super Bowl).

    • Estos eventos no se pueden mover. ¿Realmente quiere entrar sin conocer los riesgos para su arquitectura? Incluso si no aborda todos estos problemas, puede tener manuales de estrategias para encargarse de ellos si se materializan.

  • «¡No queremos que otros conozcan los secretos de la implementación de nuestra solución!»

    • Si muestra al equipo las preguntas en Well-Architected Framework, verá que ninguna de las preguntas revela información de propiedad comercial ni técnica.

A medida que realiza múltiples revisiones con los equipos de su organización, puede identificar problemas temáticos. Por ejemplo, es posible que descubra que un grupo de equipos tiene problemas en un pilar o tema en particular. Querrá ver todas sus revisiones de manera integral e identificar cualquier mecanismo, formación o charla de ingeniería que puedan ayudar a abordar esas cuestiones temáticas.