Primeiras aulas do curso
Nos anos 2000, o Google enfrentava o desafio de lidar com bilhões de buscas, o que evidenciava a necessidade de escalabilidade na internet. O crescimento exponencial do Google durante esse período gerou um dilema entre as equipes de desenvolvimento e operações: enquanto uma precisava de velocidade, a outra demandava confiabilidade e estabilidade nas implantações. Esse conflito resultou em falhas nos serviços, levando até mesmo ao surgimento e descontinuação de alguns produtos.
Para ilustrar o cenário, podemos observar o crescimento da receita do Google de 2000 a 2010, que reflete o impacto do aumento de usuários e sistemas criados. Entre 2009 e 2011, dois produtos foram criados e posteriormente descontinuados. Em 2009, surgiu o Google Wave, uma plataforma de conversação integrada a redes sociais e e-mail, que foi descontinuada em agosto de 2010 devido à complexidade das integrações e à baixa adoção pelo público.
Em fevereiro de 2010, o Google já planejava o Google Buzz, uma rede social integrada ao e-mail, que foi descontinuada em 2011 por conta de uma polêmica envolvendo a privacidade de dados. A viabilidade se tornou um pilar primordial, pois, à medida que um produto cresce e integrações aumentam, qualquer risco de segurança ou vazamento de dados pode comprometer a integridade e reputação da aplicação. Hoje, divulgamos amplamente qualquer risco de privacidade envolvido, e, nesse caso, isso levou ao encerramento das atividades da plataforma.
A confiabilidade é, portanto, essencial. Logo após, o Google enfrentou um problema de localização global que afetou a qualidade das buscas. A falha na escalabilidade geográfica resultou em resultados irrelevantes e em idiomas incorretos, afetando milhões de usuários. Diante disso, o Google começou a repensar seu modelo de operação, que até então apresentava conflitos entre as equipes de desenvolvimento e operações, resultando em incidentes constantes e uma postura reativa, ou seja, focada em resolver problemas momentâneos sem investigar suas causas.
Falta de métricas e processos automatizados pode resultar em ausência de visualização e visibilidade do que ocorre no sistema, especialmente do lado do usuário. Quando não há automação, imagine ter que lidar com incidentes por meio de processos manuais repetidos inúmeras vezes. Esse era o cenário antes do surgimento do SRE (Site Reliability Engineering).
O SRE surge para aplicar a engenharia de software nas operações, trazendo automação e reduzindo erros humanos, ou pelo menos diminuindo significativamente sua ocorrência. Ele resolve a falta de métricas e processos automatizados, focando em melhorias contínuas. A melhoria contínua é essencial porque, mesmo com métricas e processos automatizados, é necessário revisá-los conforme o sistema cresce.
Chegamos, então, a um ponto crucial: os pilares do SRE. Quais são eles? SLI, SLO, SLA e o Error Budget. Utilizando a analogia do farol, o SRE está sempre atento ao SLI, que é um indicador de disponibilidade. O SLO representa o objetivo de disponibilidade que desejamos alcançar. O SLA é um acordo formal de prestação de serviço, garantindo que o serviço estará disponível e atingirá o objetivo do SLO. Caso contrário, há penalidades, como multas, por não cumprimento. Esses acordos incluem prazos, como resolver um incidente em quatro horas para garantir que o SLI atinja o SLO.
O Error Budget refere-se ao tempo que o sistema pode ficar indisponível, permitindo investir em inovação e melhorias do produto. Vamos explorar isso mais a fundo.
Do Google para o mundo, o SRE se expande em escala global, com práticas de confiabilidade e estabilidade que se tornaram fundamentais. A confiabilidade é orientada ao usuário, que se torna peça central na visão do SRE. O serviço deve ser confiável e atender às necessidades do usuário, garantindo sua satisfação. A entrega rápida e focada no usuário é essencial.
Cloud DevOps também são pilares que se unem nessa entrega, pois precisamos de infraestrutura e colaboração. A confiabilidade na estrutura é crucial para impulsionar e escalar a tecnologia.
Agora, proponho um exercício: pense como SRE. Escolha um serviço que utiliza diariamente e liste dois riscos de confiabilidade e estabilidade que podem ocorrer. Reflita sobre quais métricas podem ajudar a prever essas falhas.
Na próxima aula, discutiremos o que acontece na rotina de um SRE.
Como prometido, vamos refletir sobre o exercício da aula anterior e entender melhor os papéis do SRE, do DevOps e do Platform Engineering (Engenharia de Plataforma), além de como eles trabalham. Existe uma grande curiosidade e também uma confusão sobre esses termos. Todos falam em DevOps, SRE e Plataforma, mas, na verdade, eles possuem práticas diferentes, embora compartilhem o mesmo objetivo: entregar software de forma rápida e confiável. Nenhum substitui o outro, mas cada um foca em um ponto específico do ciclo.
Muitas pessoas acreditam que DevOps é uma cultura ou um cargo, mas não é bem assim. O SRE não é a evolução da plataforma. Talvez já tenhamos visto o símbolo do infinito do DevOps, que representa várias ferramentas e processos que utilizamos. Vamos entender isso melhor.
O primeiro item do fluxo é o desenvolvimento. A equipe de desenvolvimento cria novas funcionalidades e atualizações. A segunda parte do ciclo são as operações, responsáveis por implementar e manter esses ambientes ao vivo, garantindo que não ocorram quedas ou falhas, mantendo-os estáveis. O terceiro passo é o feedback, que envolve coletar insights e dados dos usuários para saber se tudo está funcionando, quantos estão acessando e o que está acontecendo do lado de lá. Esse ciclo é contínuo, formando um infinito.
Para o desenvolvimento, operações e feedbacks, existem várias ferramentas que auxiliam na prática. O termo DevOps é frequentemente utilizado como um título genérico, o que pode gerar confusão e falta de clareza. Há uma grande confusão entre os times e uma falta de alinhamento sobre as responsabilidades de cada um.
Vamos entender melhor. Se o recurso é o DevOps, qual é o foco dele? O foco está na cultura e na colaboração. A colaboração entre os times é essencial para que eles consigam se comunicar e trabalhar da melhor forma possível para entregar resultados.
Qual é a prática realizada? Se a SDE, a integração contínua e a entrega contínua entre os times, se o SRE vai procurar um foco em confiabilidade e métricas. Desejamos um serviço estável e queremos saber o que está acontecendo nele. Para isso, utilizamos SLIs, SLOs e orçamentos de erro.
Quando falamos de engenharia de plataforma ou platform engineering, temos um foco em ferramentas de automação. Na prática, temos plataformas internas, self-service. Encapsulamos o produto para entregá-lo em larga escala. Essa é a ideia de diferenciação de prática de cada um.
Agora, trazendo uma analogia, o que acontece? No desenvolvimento tradicional de funcionalidades e atualizações, existem muitos SLOs e processos manuais. O DevOps entra para promover a colaboração, quebrando os silos de reatividade entre os times. A culpa não é de um time específico, não é de um microserviço ou de um banco de dados. O DevOps chega para promover a conversa. É uma cultura. Precisamos resolver um problema, precisamos de ajuda, então, vamos dialogar e trazer evidências do que pode ser feito. E integração.
O SRE traz a confiabilidade e as métricas. Depois disso, vem o platform engineering, trazendo ferramentas e automação, e por fim, temos uma engenharia escalável. Como assim? Temos um produto confiável e automatizado para ser entregue. Assim, as equipes não realizam muitos trabalhos manuais e não sofrem com questões de confiabilidade. Ou seja, temos um produto estável, que pode ser distribuído em larga escala e que é monitorado para identificar falhas e resolvê-las.
Por isso, essas três vertentes sempre se comunicam. Agora, mapeando um pouco da nossa realidade, pense em um time no qual já atuou, ou um time atual no qual está atuando, ou então, em qual das três vertentes deseja atuar, das que mencionamos. Quais práticas são mais fortes, ou quais práticas gostaria de desenvolver? Qual falta reforçar? Qual não adotaria? Guarde essas reflexões, pois na próxima aula vamos discutir mais sobre isso.
Agora, vamos discutir um fator importante que sustenta todos os pilares do SRE, do DevOps e do Platform Engineering: a cultura blameless (sem culpabilização). Vamos imaginar uma situação em que, durante uma Black Friday, um microserviço para de funcionar, impactando algumas vendas. O que normalmente acontece nesses incidentes? É aberta uma requisição para não estourar o SLA, e também uma sala de guerra, onde todos os times envolvidos se reúnem com seus gestores. Na maioria das vezes, os times começam a apontar culpados pelo ocorrido. Embora o problema seja resolvido, essa situação se repete.
O que devemos aprender com isso? Parece até uma conversa de psicologia, mas a cultura de colaboração, de integração contínua e de implantação contínua aborda, principalmente, o que fazer quando algo dá errado. É importante lembrar que sistemas complexos falham, sempre. Sistemas complexos possuem microserviços, dependências, necessitam de internet, cloud (nuvem), infraestrutura, e todos têm seus SLIs e disponibilidades. Nenhum deles atinge 100% de disponibilidade, e, portanto, têm probabilidade de falha. Pessoas também falham. A questão é como reagimos a essas falhas do sistema. Culpabilizar as pessoas não resolve os problemas. Montar uma estratégia, identificar o que pode ou não ser revertido, entender por que aconteceu, questionar a origem do problema e tentar resolvê-lo é o melhor caminho.
A cultura blameless foca no sistema quando esses problemas ocorrem, e não nas pessoas. O objetivo é entender como o erro aconteceu e transformar essas falhas em oportunidades de melhoria. Após a solução do problema e o retorno do sistema, todos permanecem na sala para analisar o foco do problema, sua origem e o que pode ser melhorado. Devemos considerar qual processo pode ser incluído, se é uma validação, uma verificação ou uma automação. Documentar isso é importante para os que ingressam posteriormente e para a criação de novas funcionalidades para o sistema. No fim das contas, tudo isso faz sentido.
O conceito de post-mortem é amplamente discutido, pois, ao longo do tempo, as pessoas entram e saem de seus cargos, acumulando experiências e senioridade, enquanto o sistema continua em crescimento. Algumas pessoas permanecem, outras não. O post-mortem é uma ferramenta valiosa para entender falhas, como, por exemplo, um deploy incorreto que derrubou a API de pagamentos. Quantos serviços foram afetados? Quando isso foi implementado? Foi hoje, ontem, ou após um reinício? A reação comum é culpar a pessoa desenvolvedora, pois foi ela quem escreveu o código. No entanto, é essencial que continuemos garantindo a estabilidade do sistema.
Uma abordagem sem culpabilização envolve revisar se o processo está correto, criar um rollback automático para que, caso ocorra um problema, possamos retornar rapidamente sem interferir no SLA ou SLI, e disseminar essa informação entre os times. É importante verificar o melhor horário para realizar essas ações. Tudo isso é discutido e negociável. Adotar essa cultura traz muitos benefícios para os times e vai além de uma discussão meramente tecnológica, envolvendo também aspectos psicológicos. Precisamos encarar os problemas de tecnologia, que sempre existirão, e nos perguntar: o que podemos aprender? Devemos reforçar nossa base em Linux, Docker, melhorar nosso monitoramento, ou incluir uma métrica como SLI? Se houve indisponibilidade e ninguém conseguiu pagar por um produto, isso pode ter afetado um objetivo financeiro da empresa. Portanto, é fundamental questionar e adotar a cultura do "porquê" e do post-mortem, que pode ser muito benéfica.
Agora, considerando isso, que tal refletirmos sobre algum incidente que já ocorreu? Seja como usuário ou como empregado, pense em uma falha que vivenciou. Reescreva esse resumo sem citar nomes, focando apenas no sistema, nas causas e nas melhorias possíveis. O que causou o problema e o que pode ser feito para que não ocorra novamente ou que tenha menos impacto? Este é um excelente exercício para resolver problemas e melhorar a comunicação com os times.
O curso Confiabilidade e SRE: métricas, Error Budget e resiliência possui 80 minutos de vídeos, em um total de 65 atividades. Gostou? Conheça nossos outros cursos de Confiabilidade & SRE em DevOps, ou leia nossos artigos de DevOps.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Todos os cursos, trilhas e certificados para evoluir.
7 dias para cancelar com reembolso
Aprenda mais rápido com IA, idiomas e imersões.
7 dias para cancelar com reembolso
TUDO DO PLUS, MAIS:
Aceleração de carreira: mentoria, vagas e prática guiada.
7 dias para cancelar com reembolso
TUDO DO PRO, MAIS:
