Bom, e vamos falar um pouquinho mais também sobre o Correction of Errors. O Correction of Errors é um processo criado pela AWS para melhorar a qualidade da operação dos produtos documentando e resolvendo problemas. O COI visa definir uma maneira padronizada de documentar as causas básicas críticas e garantir que elas sejam revisadas e abordadas, garantir que elas sejam revisadas e abordadas, ajudando os times a entender as RCA's, serem revisadas de forma consistente e endereçar os pontos de ação corretamente. Então se vocês forem reparar aqui pessoal, o Correction of Errors é um processo muito parecido com o que a gente acabou de mostrar no pós-mortem. Então é um framework ali que é utilizado pela própria AWS, onde eles utilizam os RCA dentro desse processo do correction of errors na mesma linha, para a gente conseguir ter uma boa documentação, a gente conseguir ter algumas reflexões em cima dos problemas que foram capturados, a gente tem um compartilhamento de conhecimento da operação com toda a corporação. E qual que é a estrutura de um correction of errors, de um COI, de um correction of errors? A gente vai basicamente ter ali um mapeamento do que aconteceu, qual foi o impacto nos clientes e no negócio, qual foi a causa raiz, que dados você tem para apoiar essa decisão. Então, uma vez que você tenha identificado a causa raiz, a segunda pergunta seria quais são os dados que a gente tem para justificar isso. Quais são os dados que a gente tem para justificar isso? Então, se apoiando especialmente em métricas e gráficos. Quais foram as implicações críticas nos pilares do UAF, especialmente segurança? Então, ao criar arquiteturas, você faz concessões entre os pilares com base no contexto do seu negócio. Essas decisões de negócio podem orientar suas prioridades de engenharia e você pode ter uma otimização para redução de custo em detrimento da confiabilidade do ambiente ou também você pode ter soluções de missão crítica que vai acabar otimizando mais a confiabilidade com custos um pouco maiores. O mais importante é ter em mente que segurança é sempre prioridade zero. Então, isso a gente vai acabar sempre priorizando por conta de questões de LGPD e outros, em vazamento de dados, né? Então, segurança é algo que a gente nunca vai abrir mão, né? Então, se a gente tiver, por exemplo, nessa identificação aqui, nessa análise, a gente identificar qualquer tipo de desvio que seja diferente disso, é algo que, com certeza, a gente também tem que levantar a mão e colocar no trilho. Quais foram as lições aprendidas? Que ações corretivas você está tomando? Então, os itens da ação, quais foram os itens relacionados, os tickets de problemas. E por fim, revisão. Então, devemos fazer revisões dos COIS com os times a fim de compartilhar conhecimento e COIs de alto impacto devem ser revisados durante a OPS Meeting. Na próxima aula a gente vai falar sobre o que é o OPS Meeting, mas percebam, o mais importante aqui é que a gente tem alguns pontos chaves quando a gente vai fazendo um pós-mortem ou quando a gente vai fazendo um COE. Então, primeiro identificar o que aconteceu, o que levou a gente a ter aquele problema, qual foi a causa raiz, a gente ter bem mapeado quais foram as lições aprendidas e quais as ações que a gente vai tomar para que a gente não torne a ter esse problema novamente e o compartilhamento de conhecimento, para que a gente consiga ter todos os desenvolvedores, todos os engenheiros com esse mindset de resiliência, esse mindset de resolução de problemas aqui espalhados, disseminados por toda a corporação.