El proceso de revisión

La revisión de las arquitecturas debe hacerse 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 Well-Architected para comprobar continuamente su arquitectura, en lugar de llevar a cabo una reunión de revisión formal. Un enfoque casi continuo permite a los miembros del equipo actualizar las respuestas a medida que evoluciona la arquitectura y mejorar la arquitectura a medida que ofrece funciones.

El Marco de AWS Well-Architected 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 garantizan 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 en los hitos clave del ciclo de vida del producto, al principio de la fase de diseño para evitar caminos sin retorno que sean difíciles de cambiar y, luego, antes de la fecha de puesta en funcionamiento. (Muchas decisiones son caminos reversibles de doble sentido. Para tomar esas decisiones se puede recurrir a un proceso ligero. Los caminos sin retorno son difíciles o imposibles de invertir y requieren una inspección más exhaustiva antes de crearlos). Tras entrar en producción, su carga de trabajo continuará evolucionando a medida que agregue nuevas funciones y cambie las implementaciones de tecnología. La arquitectura de una carga de trabajo cambia con el tiempo. Debe seguir unas buenas prácticas de higiene para evitar que las características arquitectónicas se degraden a medida que evoluciona. Si hace 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, le recomendamos que se asegure de incluir a todas las personas relevantes en la reunión. A menudo, descubrimos que las revisiones son la primera vez que un equipo comprende realmente 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 hacer 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 preguntas para la toma de medidas que requieren una investigación fuera de banda para responderlas (por ejemplo, “¿hemos activado el cifrado o no?”)

Tras la revisión, debe disponer de 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 queda claro tras completarla, es posible que, al principio, los equipos nuevos sean reticentes. Aquí hay algunas objeciones que se pueden tratar mediante la formación del equipo en los beneficios de las revisiones:

• “¡Estamos demasiado ocupados!”. (A menudo se dice cuando el equipo se está preparando para un lanzamiento importante).

  • 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 haga 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 hacer nada con los resultados!”. (A menudo se dice que cuando hay un evento inamovible, como la Super Bowl, en el que participar).

  • Estos eventos no se pueden mover. ¿Realmente quiere participar sin conocer los riesgos para su arquitectura? Aunque no aborde todos estos problemas, todavía puede tener manuales de estrategias para afrontarlos si se materializan.

• “No queremos que otras personas conozcan los secretos de la implementación de nuestra solución”.

  • Si señala al equipo las preguntas del Marco de Well-Architected, verá que ninguna de las preguntas revela información comercial ni técnica.

A medida que lleva a cabo 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.