Bom, vamos falar um pouco mais agora sobre o ORR. A Amazon criou o Operational Readiness Review, ORR, para resumir os aprendizados dos incidentes operacionais da AWS em perguntas selecionadas com orientação de práticas recomendadas. Bom, pegando uma frase do Jeff Bezos aqui, que é o fundador da AWS, ele basicamente fala que boas intenções nunca funcionam, que você deve ter bons mecanismos para fazer com que as coisas aconteçam. Então, com base nisso, a gente tem mais esse processo dentro do framework, pegando o pilar de excelência operacional do WAF, desenvolvido pela AWS, essa questão do RR, que o objetivo é ajudar na construção de sistemas altamente disponíveis e resilientes sem comprometer a agilidade e velocidade do desenvolvimento. O RR utiliza uma abordagem baseada em dados para identificar e mitigar riscos operacionais, complementando as revisões do framework WAF da AWS. Então, é mais uma coisa que a gente também pode trazer para dentro da Ops Meeting. Então, uma das coisas que a gente pode analisar quando a gente estiver fazendo uma Ops Meeting é justamente quando foi aplicado o RR e o backlog que ficou desse RR, como que está, se a gente já endereçou, se não endereçou, se já tem sei lá, seis meses, um ano que a gente aplicou o último RR, a gente sabe que com a evolução da tecnologia, em seis meses, um ano, pode ser que muita coisa tenha mudado, então de repente já faz sentido a gente aplicar um RR? Pegando aqui diversos pilares principais, a gente pode citar aqui o primeiro como disponibilidade, escalabilidade e algumas perguntas chaves que a gente pode utilizar dentro desse pilar. Esse aqui é só um exemplo não exaustivo, mas a ideia é que essas perguntas sejam até, vamos dizer assim, traduzidas conforme as necessidades internas de cada um dos sistemas, de cada um dos ambientes também. Então, falando de disponibilidade e escalabilidade, a gente tem aqui, por exemplo, disponibilidade e escalabilidade, a gente tem aqui, por exemplo, como você garante a disponibilidade dos seus serviços, quais são os mecanismos de escalabilidade automática que foram implementados, quais medidas foram adotadas para lidar com os picos de tráfego inesperados. Falando de resiliência e recuperação, quais são os procedimentos de recuperação de desastres? Como você gerencia backups e replicação de dados? Quais são os seus planos de failover em caso de falhas, certo? De uma região específica. Para monitoramento e alarme, quais métricas são monitoradas para detectar problemas de desempenho? Como você define alertas para eventos críticos? Quais ações são tomadas em resposta a um alerta? Mais um pilar super crítico, segurança. Quais são as suas práticas de gerenciamento de identidade, de identidade e acesso, IAM? Como que você faz o seu Alt-N, Alt-Z? Como você protege seus dados em trânsito e em repouso? Quais são os controles de segurança implementados para proteger contra ataques externos e internos, e por fim, gerenciamento de mudança. Então, como você gerencia e implementa alterações em sua infraestrutura e aplicações, quais são os processos para revisão e aprovação dessas alterações, quais são os processos para revisão e aprovação dessas alterações e como você lida com reversões e rollouts de alterações problemáticas. Então percebam, com 3, 6, 9, 12, 15 perguntas, olha a quantidade de coisas, de insights que a gente pode tirar desse tipo de abordagem. Eu tenho certeza que se a gente tiver uma boa resposta para cada uma dessas alternativas, a gente vai ter um sistema que, do ponto de vista de confiabilidade, vai estar bem preparado. Óbvio, pode acontecer algum tipo de problema e é normal que isso aconteça, problema e é normal que isso aconteça, mas a gente já consegue ter uma segurança muito maior de que o nosso ambiente está preparado para diversos tipos de situações. E quando a gente fala também aqui do RR em tempo de SDLC, percebam, se a gente for pegar lá o SDLC, percebam, se a gente for pegar o SDLC, a gente tem aqui caixinhas com cada uma das etapas e a gente pode ter o RR já na etapa de design, então diversas perguntas que eu fiz ali, diversas perguntas que eu fiz ali quando a gente estiver criando requisito, quando a gente estiver fazendo as definições de como vão funcionar o nosso sistema o nosso produto, a gente já consegue encaixar diversas daquelas perguntas no mindset para a gente endereçar aqueles pontos, a gente também tem uma etapa intermediária onde a gente também consegue ter a aplicação do RR em tempo de desenvolvimento e teste, com esse mesmo mindset, e a gente também consegue ter um RR na implementação. Então, uma vez que esse software for implementado, a gente fazer todas aquelas perguntas, tirar mais perguntas até com base em pós-mortens que a gente teve, em problemas que a gente já enfrentou dentro da corporação se a gente está preparado, se a gente está protegido para que esses problemas conhecidos e não conhecidos que a gente já tenha mapeado se nosso sistema está preparado. E beleza, uma vez que esse sistema esteja em produção, a gente pode também ali ter o RR recursivo. Então, a cada seis meses, a cada um ano, a gente tem um RR para cada um dos nossos produtos, a fim de a gente fazer a revisão. A gente sabe que hoje os sistemas são totalmente organismos vivos e totalmente mutáveis, então faz sentido a gente ter essa recursão do RR para a gente de repente capturar algum gap que possa ter aparecido no meio do caminho.