Blog de Amazon Web Services (AWS)

¿Cómo realizar una revisión de Well-Architected Framework? – Parte 2

Por Lechu Matias Siri y Edwin Romero

Existen tres fases para llevar a cabo con éxito un Well-Architected Framework Review (WA Review): preparar, revisar y mejorar. En la primera parte de esta serie de blogs, hablamos de la fase de preparación. En esta parte, profundizaremos en las mejores prácticas de la segunda fase, la revisión propiamente dicha.

Figura 1 - Fases del Well-Architected Framework Review

Asumiendo que siguió las recomendaciones de la fase de preparación, en este punto debería haber identificado la carga de trabajo que quiere revisar, identificado a los patrocinadores, decidido los pilares a revisar y su prioridad, decidido qué enfoque utilizar (si lo hay) y el formato de la sesión de revisión. También debería haber recopilado los datos necesarios sobre su carga de trabajo para responder a las preguntas de la revisión.

El objetivo del WAFR

Antes de profundizar en algunas recomendaciones para un WA Review satisfactorio, es importante recordar que el objetivo último de la revisión es mejorar las arquitecturas de los sistemas para que estos puedan dar un mejor soporte a las necesidades de la empresa. El proceso de mejora de la arquitectura comienza con la revisión de la arquitectura actual y su comparación con las mejores prácticas. Esto se hace respondiendo a las preguntas de revisión. Hay un conjunto de preguntas para cada pilar. Basándonos en las respuestas, identificamos las áreas que deben mejorarse, también denominados Problemas de Alto Riesgo (HRI) y Problemas de Riesgo Medio (MRI). A continuación, trabajamos en la creación de un plan de tratamiento para remediar estos riesgos utilizando un enfoque basado en prioridades.

Buenas prácticas del WAFR

1- Establecer expectativas. El WA Review supone un gran compromiso para todos los participantes. Tómese el tiempo necesario para mantener esta conversación con las principales partes interesadas con antelación, para que tengan claras las expectativas y sus funciones antes, durante y después de la revisión. Asegúrese de contar con su apoyo.

2- Conversaciones y no una auditoría. Los mejores resultados que vemos en las sesiones de WA Review es cuando las partes interesadas las consideran conversaciones, no listas de comprobación ni ejercicios de puntuación. Esto animará a todos los miembros del equipo a hablar abiertamente sobre sus sistemas, siempre y cuando no se les culpe por omitir algunas de las mejores prácticas. Esto también ayudará a descubrir los riesgos arquitectónicos.

3- Deporte de equipo, todos los miembros del equipo deben desempeñar un rol. Por ejemplo, el patrocinador de un pilar debe asegurarse de que todas las preguntas del pilar se responden correctamente. A continuación, el patrocinador debe encargarse del plan de mejora de los riesgos identificados durante la revisión. Esto adquiere mayor importancia cuando hablamos de la fase de Mejora de la revisión, en la que los distintos equipos deben participar en la creación de prioridades y la búsqueda de soluciones para los riesgos identificados. Esto se trata en la parte 3 de esta serie de blogs.

4- Revisión continua, y no un esfuerzo puntual, las cosas siempre cambian y deben mantenerse bajo control. Recomendamos la creación de una práctica dentro de la organización para llevar a cabo WA Review (o una versión personalizada de la misma) sobre una base regular, o después de grandes hitos en el ciclo de vida de la carga de trabajo, tales como ir de la prueba a la producción.

5- Antes es mejor, porque es más fácil influir en las decisiones e impulsar cambios mientras las cosas están todavía en la fase de diseño y no en producción.

6- Utilice la herramienta AWS Well-Architected Tool (AWS WA Tool)

Las preguntas del WA Review están disponibles como documento técnico. Sin embargo, le recomendamos que utilice el AWS WA Tool para la revisión. El uso de la herramienta le permitirá realizar un seguimiento de las preguntas, tomar notas, crear diferentes hitos, comprender el contexto de la pregunta, entender la práctica recomendada que se está validando y explorar recursos adicionales para la práctica recomendada en cuestión en blogs, charlas de re:Invent o documentación.

El uso del AWS WA Tool también le ayuda a crear un enfoque personalizado. Con los enfoques personalizados, puede crear su propio pilar, preguntas y prácticas recomendadas. Puede adaptar las preguntas de un enfoque personalizado para que sean específicas de una tecnología concreta, lo que le ayudará a satisfacer las necesidades de gobierno de su organización.

Revise estos ejemplos:

Durante la fase de revisión, es importante tomar las notas necesarias para explicar si una determinada buena práctica está implementada o no. Si está implementada, marca su casilla en la pregunta. Si no, anótelo en la zona de notas para explicar por qué no se ha implantado. ¿Está en la mapa de ruta? ¿Entra en conflicto con otros requisitos? ¿Se ha pasado por alto? La respuesta a estas preguntas ayudará al equipo más adelante a crear un plan de mejora. También ayudará a otros revisores, ya que los equipos y los propietarios pueden cambiar.

Hitos es otra característica que recomiendo utilizar. Un hito registra el estado de una carga de trabajo en un momento determinado. Cuando lleve a cabo varias sesiones, o cuando trabaje en puntos de mejora, puede guardar un hito para medir el progreso a medida que avanza.

7- Maximizar el tiempo

El WA Review debe ser breve y completarse en horas, no en días. Para que el proceso de revisión sea conciso, es importante mantener un equilibrio entre hacer preguntas de seguimiento para validar las mejores prácticas y mantenerse dentro del contexto de la pregunta sin dedicar demasiado tiempo a discusiones técnicas profundas.

Por ejemplo, la supervisión es un tema que abordamos en los seis pilares. Sin embargo, el contexto variará según el pilar. En el pilar de la excelencia operativa, la supervisión tiene que ver con la capacidad de observación y la comprensión del estado de la carga de trabajo mediante el establecimiento de métricas y KPI. En el pilar de la seguridad, el contexto de la supervisión cambiará para centrarse más en la auditoría de entornos, el rastreo de actividades maliciosas, la subestimación de comportamientos no autorizados, etcétera.

Otro aspecto a tener en cuenta es evitar profundizar en discusiones técnicas durante la revisión. Por ejemplo, entrar en detalles de configuración de un servicio. Asimismo, evite entrar de lleno en la parte de la solución, ya que es probable que durante la revisión no disponga del tiempo suficiente ni de los detalles necesarios para recomendar la solución adecuada en el acto. En su lugar, tome notas y continúe con este tema como parte de la fase de mejora, como veremos en la parte 3.

8- Quizás es No

En algunos casos, el equipo no estará seguro de si una buena práctica se aplica o no. En este caso, debe considerar las mejores prácticas no implementadas y documentarlo en las notas del AWS WA Tool. De esta forma, puede incluir la solución (o más validación) como seguimiento como parte de la fase de mejora.

9- Escalar y automatizar según sea necesario

Para grandes organizaciones con muchas cargas de trabajo, considere la creación de procesos automatizados y escalables para revisar las cargas de trabajo, identificar riesgos y remediarlos.

He aquí algunos ejemplos de cómo integrar WAFR en sus organizaciones creados por mis colegas. Puede ajustar y reutilizar estas soluciones según convenga a sus organizaciones.

Resumen

En esta entrada del blog, compartimos algunas de las lecciones aprendidas de la realización de muchas Revisiones del Well-Architected Framework con clientes de diferentes industrias. El objetivo final de WA Review es identificar los riesgos de arquitectura y abordarlos. Para conseguirlo, primero debe revisar la arquitectura de su carga de trabajo y compararla con las prácticas recomendadas de AWS. Hay algunas recomendaciones a seguir y antipatrones a evitar cuando se ejecuta WA Review. La revisión debe ser conversacional, honesta, documentada y finalizada en días, no en semanas. Si ejecuta revisiones para múltiples cargas de trabajo, necesita automatizar y escalar el proceso según las mejores prácticas de su organización. Hemos compartido algunos de los recursos de nuestros SA y clientes para mostrarle ejemplos de cómo hacerlo. En el siguiente paso, una vez identificados los riesgos, hay que crear un plan de mejora para abordarlos. Esto se tratará en la parte 3.

Acerca de los autores

Edwin Arturo Romero González es un Solutions Architect quien ama ayudar a los clientes, compartir las mejores prácticas y capacitarlos en la arquitectura e implementación de soluciones. Fuera del trabajo, le encanta pasar tiempo con su novia y aprender sobre diferentes culturas.

 

 

 

Matias “Lechu” Siri es un Well-Architected Solutions Architect que colabora con socios y clientes de diversas industrias para diseñar e implementar cargas de trabajo seguras, resilientes y costo-eficientes basadas en las mejores prácticas del AWS Well-Architected Framework.