Beleza, vamos falar um pouco sobre o processo de On-Call. On-Call é um sistema em que os engenheiros são designados para estar disponíveis para responder a incidentes ou problemas relacionados aos produtos e serviços que suportam durante o horário comercial e também fora do horário normal de trabalho. Esses engenheiros são constatados automaticamente ou por outros membros da equipe quando ocorre um problema que requer atenção imediata. Podem ser acionados a qualquer momento, incluindo fins de semana e feriados, devem estar prontos para responder e resolver problemas rapidamente para minimizar o impacto para os usuários finais, a fim de manter o não rompimento dos SLOs. para os usuários finais, a fim de manter o não rompimento dos SLOs. Então, on-call nada mais é aqui do que o nosso famoso plantão. E por que a gente tem esse processo de on-call? Basicamente, os principais objetivos. Estar disponível, a gente ter sempre uma pessoa disponível para poder responder por alertas e incidentes de forma rápida e eficiente, a gente conseguir também acelerar a identificação de causa raiz dos incidentes e tomar medidas corretivas para a resposta e restauração desses serviços, minimizar o impacto dos usuários finais durante os incidentes, documentar esses incidentes e lições aprendidas para facilitar futuras resoluções de problemas, trabalhar para melhorar a resiliência do sistema, identificando áreas de fraqueza e implementando medidas proativas. É possível usarmos também algumas ferramentas para nos auxiliar aqui na automação desses acionamentos. Então, a gente tem aí ferramentas como o PagerDuty, eu sei que a Grafana também tem um módulo, que se eu não me engano se chama Grafana On Call, que é pago. O Vitória Ops também é possível a gente ter esse tipo de acionamento, então essas ferramentas auxiliam ali a gente não ter necessariamente uma equipe que vá ficar olhando para esses incidentes ali que tem uma criticidade mais alta, durante um horário não comercial, de madrugada, por exemplo, que você não vai ter um time dedicado ali olhando para os dashboards e painéis métricas de operação. Então, a gente consegue também se auxiliar nessas ferramentas para facilitar ter um processo de automação nesses acionamentos. Um ponto importante também é a gente ter um bom processo para passagem de conhecimento. Então, supondo que a gente tenha diversos times e a gente esteja trabalhando num modelo de Beauty Running, onde a gente tem tanto os SREs quanto os desenvolvedores, os times de produto, fazendo ali também a operação desses produtos, né, e não só a construção e delegando a operação para outros times, é importante que a gente consiga ter um processo bacana de passagem de conhecimento, porque no Oncall a gente vai definir ali alguns engenheiros, né, e sobre alguma periodicidade para a gente conseguir fazer a rotação do plantão então vamos supor que a gente o time trabalha ali com sprints de duas semanas, três semanas talvez dependendo da quantidade de acionamentos isso é muito variável mas talvez seja uma boa métrica para a gente ter uma, duas pessoas ali dedicadas para estar fazendo operações mais relacionadas ao on-call. Consequentemente, elas vão ter que estar documentando, existem diversos processos ali para a gente deixar bem documentado todas as atividades que foram realizadas durante o on-call e ao término desse on-call, a gente também tem um processo de passagem de conhecimento. Então, se duas pessoas estão fazendo, vão entrar duas pessoas novas, como que é feita essa passagem de conhecimento, quais foram as atividades que ainda estão em progresso, não foi possível ser finalizado. Então, e aí tem algumas coisas que vale pontuar. Se a gente parar para analisar friamente, assim, quem está no on-call, a prioridade zero dessa pessoa vai ser fazer o primeiro combate ali a incidentes. Depois fazer um pós-mortem dessa pessoa vai ser fazer o primeiro combate a incidências, depois fazer um pós-mortem, que a gente vai comentar um pouco mais para frente, desse problema, identificar a causa raiz, identificar quais são as ações que vão ter que ser realizadas para a gente ter a resolução completa desse problema. Então, todas essas atividades precisam estar bem documentadas para que os próximos integrantes também consigam entender o que está acontecendo e seguir com a sequência de atividades normalmente. Bom, para que o On Call não se torne uma atividade pesada a ponto de afetar a produtividade psicológica dos engenheiros, é importante que seja estabelecido uma escala onde haverá uma rotação entre os membros do time. Portanto, as equipes de CRE buscam equilíbrio, garantindo que pelo menos 50% do tempo seja dedicado a projetos, permitindo abordar estrategicamente problemas encontrados em produção. Durante o on-call, os membros terão como prioridade realizar o primeiro combate a incidentes, causa raiz, porém, na ausência dessas at atividades devem focar em atividades como redução de TOEI, automação, fast planning, housekeeping e também oportunidades de melhoria, falando de observabilidade, análise de reincidência e tudo mais. Então bate bastante no que eu comentei com vocês, é bem comum. Então em times que talvez estejam com estabilidade um pouco maior, vai ser mais normal que a gente tenha menos TOEI, que a gente tenha menos falso positivo, que a gente já tenha um bom refinamento das métricas, a gente já tenha um bom refinamento dos incidentes, dos alertas que a gente configurou. Na ausência dessas atividades, existem várias outras que a gente consegue puxar e que a gente consegue também adicionar, vamos dizer assim, engenharia nessas atividades, então a gente consegue criar alguma automação, de repente a gente fazer ali uma análise de capacity planning ou de FinOps e a gente entender que a gente tem oportunidade, se a gente estiver trabalhando já de uma forma bacana, a gente vai estar falando ali de infra como código, então a gente vai ter atividade de engenharia para poder fazer todas essas modificações, ou de repente algum recurso que precisa ser removido, a gente também vai estar fazendo alterações a nível de código para poder remover esses recursos. Muitas vezes a gente vai acabar também olhando para análise de reincidência, que é uma coisa super importante. Então, beleza, a gente não está tendo nesse momento uma alta incidência de incidentes, mas pode ser que, sei lá, num qual passado, isso não tenha sido verdade. Então, diante desse cenário, daria muito bem para a gente fazer esse levantamento, entender e fazer uma análise de 80 a 20, quais foram os principais ofensores, e começar a atacar esse tipo de desvio de comportamento no sistema.