Vamos falar um pouco mais agora sobre TOIL, ou melhor, redução de TOIL. Bom, TOILs são atividades manuais, repetitivas e que consomem tempo. Como resolver problemas de rotina, executar tarefas de manutenção simples e responder a solicitações comuns. Essas tarefas consomem recursos preciosos das equipes de engenharia de confiabilidade e podem afetar negativamente sua eficiência e motivação. O objetivo é identificar e eliminar por meio de automação e simplificação de processos, liberando tempo e recursos para atividades mais estratégicas e de maior valor. maior valor. Bom, algumas características de TOIL, tá? Atividades manuais, né? Então, atividades manuais como limpeza de file system, por exemplo, né? Fazer limpeza de arquivo que cresceu, que está cheio, não está tendo rotatividade, é um tipo de atividade que a gente pode estar falando claramente de TOEIL. Atividades repetitivas, então, putz, beleza, né? A gente não tem uma rotação configurada em algum arquivo de log ali, consequentemente, a gente vai lá de forma manual ajusta e dali um tempo vai acontecer a mesma coisa a gente vai ter que voltar ali então é uma atividade que acaba não tendo nenhum tipo de valor atividades que são automatizáveis né então humboldt playbooks a ideia que a gente óbvio tem atividade que a gente vai ter que acabar tendo tem coisa nem tudo faz sentido se automatizável mas nesse situação por exemplo de limpeza de arquivo a gente pode facilmente fazer uma configuração ali uma automação para que a gente me tive de vez esse tipo de cenário. Atividades também não táticas e reativas, por exemplo, o recebimento de alertas, falsos positivos, alertas de disco cheio, isso acaba tomando mais tempo dos engenheiros e não é algo que acaba agregando tanto valor. Falta de valor perene, então você resolve um problema ali que traz uma satisfação por um tempo, que resolve o problema por um tempo, mas que não é perene, aquilo vai acabar voltando a dar problema novamente. E crescer tão rápido quanto a sua origem, o que é isso? Imagina que a gente tem um trabalho operacional que tende a crescer conforme cresce a infraestrutura. Então, nesse caso em específico, sei lá, a gente tem uma atividade manual para configuração de bootstrap de servidor. A gente não tem nenhuma automação para fazer ali toda a parte de configuração, provisionamento, o que vai acontecer? Conforme a gente tem uma necessidade maior de subir mais servidores, a gente vai tendo cada vez mais atividades ali de ter que fazer essas configurações de forma manual também. Então, mais uma característica bem explícita de atividades relacionadas a TOIL. Características do TOEFL. Então, a gente pode entender que uma atividade manual pode ser considerada TOEFL, atividades repetitivas, atividades que têm uma alta propensão a serem automatizáveis, tem uma alta propensão a serem automatizáveis atividades não táticas e reativas nesse caso aqui a gente pode estar falando de falso positivo por exemplo, atividades que acabam tomando tempo e desviando a atenção dos SREs falta de valor perene então bate um pouco ali na questão do manual repetitivo a gente pode ter alguma atividade como limpar um arquivo, um file system alguma coisa nesse sentido de forma manual se a gente não tem uma automação esse problema vai voltar a acontecer novamente e consequentemente, isso não é algo que traz um valor a longo prazo. A gente vai conseguir resolver o incidente, vai ter uma satisfação temporária, mas a gente não vai conseguir trazer valor de fato. E também atividades que crescem de forma significativa. Então, nesse caso, por exemplo, se a gente não tiver nenhuma automação e a gente tiver mais servidores sendo provisionados, a gente vai acabar tendo mais problema, mais problema, mais problema. Então, a gente acaba nunca conseguindo sair desse ciclo vicioso de atividades relacionadas a TOEI. Bom, e falando de atividades ofensoras para a geração de TOEI, podemos citar processos. Então, tanto processos relacionados a gerenciamento de recurso computacional, quanto também a questão de tickets internos, certo? Interrupções em produção, então a gente pode estar se planejando para executar diversas atividades durante um sprint, mas por conta de interrupções, problemas que a gente está tendo em produção, vai acabar gerando uma série de distrações e muitas vezes a gente acaba não conseguindo entregar o que foi planejado. Release Chapline, então aqui a gente está falando de manutenção nas pipelines, por exemplo. Então mesmo a gente tendo bastante automação, se a gente vier a ter qualquer tipo de problema, né, ou solicitação de rollback, ou qualquer problema nas próprias ferramentas que fazem ali todo esse CSD, a gente também acaba aí tendo geração de TOEI. Migrações de ambiente, né, então, mesma coisa, vai acabar desviando o esforço FinOps e Capacity Planning, mais uma atividade que vai acabar desviando a atenção do time de SRE e resolução de problemas em arquiteturas frágeis. Então, muitas vezes a gente tem arquiteturas que não são bem montadas, ou já vi acontecendo bastante também ambientes ou softwares que não deveriam estar rodando em cloud, rodando em cloud, e aí a gente acaba tentando encaixar ali um quadrado num círculo e a gente acaba tendo mais problemas e mais desvio de atenção do que propriamente conseguindo resolver problemas de forma perene. Beleza, e o que a gente pode fazer para reduzir TOIL de forma geral? Então a primeira coisa é a gente conseguir identificar e mensurar a fonte do TOIL, isso seria o ideal, fazendo com que a gente consiga atacar eles especificamente. Bom, engenharia, desenvolvimento para eliminar o TOEI do sistema. Então, se a gente tem algum software com problema, não adianta a gente querer resolver problema de software com infraestrutura nem problema de infraestrutura com software. A gente precisa atacar a causa raiz do que está acontecendo. Então se for um problema de software, a gente utilizar aí dos desenvolvedores, dos engenheiros de software para poder atacar e caso seja algum problema de infraestrutura, a mesma coisa. Bom, rejeitar o TOE toio então tem tarefas que a gente sabe que é toio vê que é toio e acaba aceitando então faz parte ali da cultura de SRE a gente também tem mais poder para recusar esse tipo de atividade usar os os SLOs, né, então, putz, se a gente consegue ter os SLOs, os SLOs são o coração aí da operação e os SREs são guiados fortemente pelos SLOs, vamos utilizar também essas métricas para entender onde pode estar tendo mais toio, né, e priorizar esse esse tipo de ambiente. Automações parciais, então aqui a gente tá falando muitas vezes de fazer uma automação gradativa, então para a gente ter um processo 100% automatizado muitas vezes acaba levando muito tempo, mas tem uma atividade em específico ali que se a gente conseguir fazer automação já consegue resolver um grande problema. Então, são uma das técnicas que a gente consegue utilizar aí também. Autoatendimento, então, acho que aqui bate bastante também no ponto de automação. Então, quanto mais autoatendimento a gente tiver, quanto mais automação a gente tiver, quanto menos dependência outras áreas tiverem dos SREs, melhor tanto para essas áreas, que vai ter experiência melhorada, quanto também para os SREs, que vão conseguir focar em atividades de maior valor. Promover a redução do TOEI como uma característica. Então, aqui a gente está falando de ter essa redução de TOEI como um objetivo, um objetivo para toda a organização, então acho que isso bate tanto no envolvimento da equipe de negócios, quanto nos desenvolvedores de software também, para que todo mundo consiga se ajudar. Aumentar a uniformidade, então aqui a gente está falando basicamente do conceito de tratar os servidores, os ambientes, como o gado e não como o gato. Então, a gente muitas vezes dava nome para os servidores, a gente setava hostname e tudo mais. E é um conceito que acabou ficando para trás. e é um conceito que acabou ficando para trás, então agora a gente fala muito de infraestrutura imutável, infra como código, então bate bastante nesse pilar aqui também, a gente tratar as coisas ali de uma forma muito mais efêmera, e avaliar os riscos na automação, então a gente reduzir o trabalho humano, consequentemente vai fazer com que a gente tenha menos problemas, erros operacionais, por exemplo. Automatizar a resposta autóica, então aqui é basicamente a gente fazer a automação dessas tarefas, que a gente fez a identificação ali para permitir que a gente torne o fluxo de trabalho 100% automatizado, sem a necessidade de intervenção humana. Usar ferramentas de código aberto e de terceiros, então aqui muitas vezes a gente está falando de se aproveitar de coisas que já funcionam bem, que já foram amplamente testadas. Então, ao invés de a gente tentar desenvolver alguma coisa que vai acabar dando mais tempo, depois a gente vai ter que manter todo esse código. que vai acabar dando mais tempo, depois a gente vai ter que manter todo esse código. Se já estiver alguma coisa pronta, já tem alguma coisa open source, por exemplo, que a gente consiga utilizar, melhor ainda. E a gente acaba também conseguindo economizar tempo. E usar feedback para melhorar. Então aqui é buscar feedback ativamente de usuários, métricas de eficácia, para que a gente consiga aprimorar continuamente as automações e ferramentas de gerenciamento de TOEFL.