Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Processus de vérification
L’évaluation 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 (qui dure 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 presque 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.
Le AWS Well-Architected Framework est aligné sur la manière dont les systèmes et services sont AWS examinés en interne. Il repose sur un ensemble de principes de conception qui influencent l'approche architecturale et sur des questions visant à vérifier que les gens ne négligent pas les domaines souvent mentionnés dans Root Cause Analysis ()RCA. Chaque fois qu'un problème important survient avec un système interne, un AWS service ou un client, nous examinons le problème RCA pour voir si nous pouvons améliorer les processus d'évaluation que nous utilisons.
Les évaluations doivent être effectuées à des étapes clés du cycle de vie du produit, dès le début de la phase de conception afin d’éviter les portes à sens unique difficiles à changer, puis avant la date de mise en service. (De nombreuses décisions concernent les portes bidirectionnelles réversibles. Ces décisions peuvent être prises à l’aide d’un processus léger. Les portes unidirectionnelles sont difficiles, voire impossibles, à inverser et nécessitent une inspection plus poussée avant de les fabriquer.) 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 laquelle 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
-
Liste d'actions contenant des questions auxquelles des out-of-band recherches sont nécessaires pour répondre (par exemple, « Avons-nous activé le chiffrement ou non ? »)
Une fois que vous avez effectué une évaluation, vous devez avoir une liste de questions que vous pouvez hiérarchiser en fonction de votre environnement métier. Vous devez également tenir compte de l'impact de ces problèmes sur le day-to-day travail 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 soit 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 déclaré lorsque l’équipe se prépare pour un lancement conséquent.)
-
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 déclaré lorsqu’ils ciblent un événement fixe, comme 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.
