O processo de revisão
A revisão das arquiteturas precisa ser feita de maneira consistente, com uma abordagem sem culpa que incentive o aprofundamento. Ela deve ser um processo leve (com duração de horas, e não dias) e semelhante a uma conversa, e não uma auditoria. O objetivo de revisar uma arquitetura é identificar quaisquer problemas críticos que possam precisar ser abordados ou áreas que possam ser melhoradas. O resultado da revisão é um conjunto de ações que devem melhorar a experiência de um cliente usando a workload.
Conforme discutido na seção "Sobre arquitetura", cada membro da equipe deve assumir a responsabilidade pela qualidade da própria arquitetura. Recomendamos que os membros da equipe que criam uma arquitetura usem o Well-Architected Framework para analisar continuamente sua arquitetura, em vez de realizar uma reunião formal de análise. Uma abordagem quase contínua permite que os membros da equipe atualizem as respostas à medida que a arquitetura evolui e melhorem a arquitetura à medida que você fornece recursos.
O AWS Well-Architected Framework está alinhado à forma como a AWS analisa sistemas e serviços internamente. Ele tem como premissa um conjunto de princípios do projeto que influenciam a abordagem arquitetônica e perguntas que verifica se as pessoas não negligenciam áreas que aparecem com frequência na análise de causa-raiz (RCA). Sempre que houver um problema significativo com um sistema interno, um serviço da AWS ou um cliente, examinaremos a RCA para ver se podemos melhorar os processos de análise que usamos.
As revisões devem ser aplicadas nos principais marcos do ciclo de vida do produto, logo no início da fase de projeto para evitar portas só de entrada que são difíceis de trocar e, em seguida, antes da data de entrada em operação. (Muitas decisões são reversíveis, de mão dupla. Essas decisões podem usar um processo leve. As portas só de entrada são difíceis ou impossíveis de reverter e exigem mais inspeção antes de serem fabricadas.) Depois que entrar em produção, sua workload continuará evoluindo à medida que você adicionar novos recursos e altera implementações de tecnologias. A arquitetura de uma workload muda com o tempo. É necessário seguir boas práticas de higiene para impedir as características arquitetônicas de se degradarem à medida que evoluírem. Ao fazer alterações significativas na arquitetura, você deve seguir um conjunto de processos de higiene, incluindo uma análise do Well-Architected.
Se você quiser usar a revisão como um snapshot único ou uma medida independente, precisará garantir que todas as pessoas certas participem da conversa. Muitas vezes, descobrimos que as revisões constituem a primeira vez em que a equipe realmente compreende o que implementou. Uma abordagem que funciona bem ao analisar a workload de outra equipe é ter uma série de conversas informais sobre sua arquitetura, nas quais se pode ter as respostas para a maioria das perguntas. Em seguida, você pode continuar com uma ou duas reuniões para tirar dúvidas ou se aprofundar nas áreas de ambiguidade ou risco percebidas.
Aqui estão alguns itens sugeridos para facilitar suas reuniões:
-
Uma sala de reuniões com quadros brancos
-
Impressões diagramas ou notas de projeto
-
Lista de ações de perguntas que exigem pesquisas fora de banda para responder (por exemplo, "ativamos ou não a criptografia?")
Após concluir uma revisão, você deverá ter uma lista de problemas que podem ser priorizados com base no contexto da sua empresa. Você também deverá considerar o impacto desses problemas no trabalho diário de sua equipe. Se você resolver esses problemas com antecedência, poderá disponibilizar mais tempo para trabalhar na criação de valor empresarial, em vez de resolver problemas recorrentes. Ao abordar os problemas, é possível atualizar a análise para ver como a arquitetura está melhorando.
Embora o valor de uma análise seja claro após sua realização, você pode descobrir que uma nova equipe pode ser resistente a princípio. Aqui estão algumas objeções que podem ser tratadas por meio da instrução da equipe sobre os benefícios de uma análise:
-
"Estamos muito ocupados!" (Geralmente dito quando a equipe está se preparando para um lançamento importante.)
-
Se você está se preparando para um grande lançamento, provavelmente deseja que ele ocorra sem problemas. A revisão permitirá que você entenda os problemas que pode ter perdido.
-
Recomendamos fazer revisões no início do ciclo de vida do produto para descobrir riscos e desenvolver um plano de mitigação alinhado ao roteiro de entrega de recursos.
-
-
"Não temos tempo para fazer nada com os resultados!" (Geralmente, quando há um evento que não pode ser adiado, como o Super Bowl, no qual estão focados.)
-
Esses eventos não podem ser adiados. Deseja realmente entrar nele sem conhecer os riscos em sua arquitetura? Mesmo se você não abordar todos esses problemas, ainda poderá ter playbooks para lidar com eles, caso ocorram.
-
-
"Não queremos que outras pessoas saibam os segredos da implementação da nossa solução!"
-
Se você apresentar as perguntas do Well-Architected Framework aos membros da equipe, eles verão que nenhuma das perguntas revela qualquer informação de propriedade comercial ou técnica.
-
Ao realizar várias análises com as equipes da sua organização, é possível identificar problemas temáticos. Por exemplo, você pode ver que um grupo de equipes tem grupos de problemas em um pilar ou tópico específico. Veja todas as análises de maneira holística e identifique quaisquer mecanismos, treinamento ou palestras de engenharia que possam ajudar a resolver esses problemas temáticos.
