Processus de vérification - AWS Well-Architected Framework

Processus de vérification

La vérification des architectures doit être effectuée de manière cohérente, avec une approche sans faute qui invite à étudier la situation en profondeur. Il doit s'agir d'un processus léger (durant des heures et non des jours), car il s'agit d'une conversation et non d'un audit. L'objectif de l'évaluation d'une architecture est d'identifier les problèmes critiques qui doivent être gérés, ou les domaines qui peuvent être améliorés. Le résultat de la révision est un ensemble d'actions ayant pour objectif d'améliorer l'expérience d'un client à l'aide de la charge de travail.

Comme indiqué dans la section « Sur l'architecture », il faut que chaque membre de l'équipe assume la responsabilité de la qualité de son architecture. Nous recommandons que les membres de l'équipe qui construisent une architecture utilisent le cadre Well-Architected pour revoir continuellement leur architecture, au lieu d'organiser une réunion formelle de révision. Une approche continue permet aux membres de votre équipe de mettre à jour des réponses au fur et à mesure que l'architecture évolue, et d'améliorer l'architecture lorsque vous fournissez des fonctions.

AWS Well-Architected Framework est aligné sur la façon dont AWS vérifie les systèmes et les services en interne. Il repose sur un ensemble de principes de conception qui influent sur l'approche architecturale, et les questions qui garantissent que les gens ne négligent pas des zones qui sont souvent présentées dans l'analyse des causes racines. Chaque fois qu'un problème important lié à un système interne, à un service AWS ou à un client survient, nous nous référons à l'analyse des causes racines pour déterminer s'il est possible d'améliorer les processus de vérification que nous utilisons.

Les vérifications doivent être effectuées aux étapes clés du cycle de vie du produit, dès le début de la phase de conception afin d'éviter les portes unidirectionnelles qui sont difficiles à modifier, puis avant la date de mise en ligne. De nombreuses décisions sont des portes bidirectionnelles réversibles. Ces décisions peuvent utiliser un processus léger. Les portes unidirectionnelles sont difficiles voire impossibles à inverser et nécessitent une inspection plus approfondie avant leur création. Après le lancement de la production, votre charge de travail continuera à évoluer à mesure que de nouvelles fonctions seront ajoutées et que les implémentations technologiques seront modifiées. L'architecture d'une charge de travail change au fil du temps. Vous devez suivre les bonnes pratiques d'hygiène pour empêcher ses caractéristiques architecturales de se dégrader au fur et à mesure de son évolution. Lorsque vous apportez des modifications d'architecture significatives, vous devez suivre un ensemble de processus d'hygiène et procéder à une évaluation Well-Architected.

Si vous souhaitez utiliser l'évaluation en tant qu'instantané unique ou mesure indépendante, vous devez vous assurer que vous avez inclus toutes les bonnes personnes dans la conversation. Souvent, nous constatons que c'est lors des évaluations qu'une équipe comprend vraiment, pour la première fois, ce qu'elle a mis en œuvre. Une approche qui fonctionne bien lors de l'évaluation d'une autre charge de travail d'équipe est d'avoir une série de conversations informelles sur leur architecture, durant lesquelles vous pouvez recueillir les réponses à la plupart des questions. Vous pouvez ensuite effectuer un suivi avec une ou deux réunions où vous pouvez gagner en clarté, ou des informations complètes sur les domaines d'ambiguïté ou les risques perçus.

Voici quelques suggestions pour faciliter vos réunions :

  • Une salle de réunion avec des tableaux blancs

  • Des impressions de tous les schémas ou notes de conception

  • Une liste de questions qui exigent une recherche hors-bande pour répondre (par exemple, « Avons-nous activé le chiffrement ou pas ? »)

Une fois que vous avez effectué une vérification, vous devez avoir une liste de questions que vous pouvez hiérarchiser en fonction de votre environnement métier. Vous devrez également tenir compte de l'impact de ces problèmes sur le travail quotidien de votre équipe. Si vous traitez ces problèmes tôt, vous pourrez libérer du temps pour travailler sur la création d'une valeur métier au lieu de résoudre des problèmes récurrents. Au fur et à mesure que vous traitez les problèmes, vous pouvez mettre à jour votre vérification pour voir comment l'architecture s'améliore.

Bien que la valeur ajoutée d'une évaluation d'architecture est claire une fois l'exercice terminé, il est possible que vous rencontriez de la résistance de la part d'une nouvelle équipe au début. Voici quelques objections qui peuvent être traitées grâce à la sensibilisation de l'équipe sur les avantages d'une révision :

  • « Nous sommes trop occupés ! » (Souvent dit lorsque l'équipe se prépare pour un grand lancement.)

    • Si vous préparez un grand lancement, vous voudrez qu'il se passe bien. La révision vous permettra de comprendre les problèmes que vous pourriez avoir manqués.

    • Nous vous recommandons de réaliser des révisions tôt dans le cycle de vie du produit pour découvrir les risques et développer un plan d'atténuation aligné avec la fonctionnalité de route de livraison.

  • « Nous n'avons pas le temps de faire quoi que ce soit avec les résultats ! » (Souvent dit lorsqu'ils ciblent un événement fixe, tel que le Super Bowl.)

    • Ces événements ne peuvent pas être déplacés. Voulez-vous vraiment vous aventurer dans cette entreprise sans connaître les risques liés à votre architecture ? Même si vous ne traitez pas tous ces problèmes, vous pouvez toujours avoir des stratégies en place pour les gérer s'ils se concrétisent.

  • « Nous ne voulons pas que les autres connaissent les secrets de l'implémentation de notre solution ! »

    • Si vous orientez l'équipe vers les questions qui figurent dans l'annexe du livre blanc sur Well-Architected Framework, elle verra qu'aucune des questions ne révèle d'informations propriétaires de nature technique ou commerciale.

Au fur et à mesure que vous effectuez des vérifications avec les équipes au sein de votre entreprise, vous pourrez identifier les problèmes récurrents. Par exemple, vous pourrez voir qu'un groupe d'équipes a rencontré divers problèmes liés à un pilier ou sujet particulier. Il est conseillé d'examiner toutes vos révisions d'une manière globale, et d'identifier tous les mécanismes, formations, ou les discussions d'ingénierie principale qui pourraient aider à traiter ces questions thématiques.