Engenharia de Confiabilidade do Google by Novatec Editora

Editado por Betsy Beyer, Chris Jones, Jennifer Petoff e Niall Richard Murphy

Novatec

Authorized Portuguese translation of the English edition of Site Reliability Engineering, ISBN 9781491929124 © 2016 Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy. This translation is published and sold by permission of O'Reilly Media, Inc., the owner of all rights to publish and sell the same. Tradução em português autorizada da edição em inglês da obra Site Reliability Engineering, ISBN 9781491929124 © 2016 Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy. Esta tradução é publicada e vendida com a permissão da O'Reilly Media, Inc., detentora de todos os direitos para publicação e venda desta obra. © Novatec Editora Ltda. 2016. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates MP20160801 Tradução: Lúcia A. Kinoshita Revisão gramatical: Sandro Andretta Assistente editorial: Priscila A. Yoshimatsu Editoração eletrônica: Carolina Kuwabata ISBN: 978-85-7522-517-2 Histórico de impressões: Agosto/2016

Primeira edição

Novatec Editora Ltda. Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 Email: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

capítulo 1

Introdução

Escrito por Benjamin Treynor Sloss1 Editado por Betsy Beyer Esperança não é uma estratégia. — Ditado tradicional de SRE

É uma verdade universalmente aceita que os sistemas não se operam por si sós. Então, como um sistema – particularmente, um sistema computacional complexo que opera em larga escala – deveria ser executado?

A abordagem com administradores de sistemas para gerenciamento de serviços Historicamente, as empresas têm empregado administradores de sistemas para operar sistemas computacionais complexos. Essa abordagem com administradores de sistemas (ou sysadmins) envolve reunir componentes de software existentes e implantá-los para que funcionem em conjunto de modo a gerar um serviço. Aos administradores de sistema, então, é atribuída a tarefa de operar o serviço e responder a eventos e a atualizações quando ocorrerem. À medida que a complexidade e o volume de tráfego do sistema aumentam, gerando um aumento correspondente de eventos e de atualizações, a equipe de administração de sistemas cresce para absorver o trabalho adicional. Como o papel de administrador de sistema exige um conjunto específico de habilidades em comparação com aquele exigido dos desenvolvedores de um produto, os desenvolvedores e os administradores de sistema são divididos em equipes distintas: “desenvolvimento” e “operações” ou “ops”. 1 Vice-presidente, Engenheiro do Google, fundador do Google SRE.

Capítulo 1 ■ Introdução

O modelo com administradores de sistema para gerenciamento de serviços tem diversas vantagens. Para as empresas que estão decidindo como operar um serviço e montar uma equipe para isso, essa abordagem é relativamente fácil de implementar: por ser um paradigma conhecido no mercado, há muitos exemplos com os quais aprender e que podemos emular. Um grupo relevante de talentos já está amplamente disponível. Um conjunto de ferramentas, componentes de software (de prateleira ou não) e empresas de integração já estão disponíveis para ajudar a operar os sistemas montados, portanto uma equipe iniciante de administradores de sistema não precisará reinventar a roda nem fazer o design de um sistema do zero. A abordagem com administradores de sistema e a separação entre desenvolvimento/ops que a acompanha apresentam algumas desvantagens e armadilhas. De modo geral, elas se enquadram em duas categorias: custos diretos e custos indiretos. Os custos diretos não são nem sutis nem ambíguos. Operar um serviço com uma equipe que dependa de intervenção manual tanto para administrar mudanças quanto para tratar eventos se torna custoso à medida que o serviço e/ou o tráfego para o serviço aumentam, pois o tamanho da equipe é necessariamente escalado de acordo com a carga gerada pelo sistema. Os custos indiretos da divisão desenvolvimento/ops podem ser sutis, mas frequentemente são mais altos para a empresa do que os custos diretos. Esses custos surgem do fato de as duas equipes terem experiências anteriores, conjunto de habilidades e pagamento de incentivos bem diferentes. Elas usam um vocabulário diferente para descrever as situações, além de fazerem pressuposições diferentes sobre risco e possibilidades de soluções técnicas e sobre o nível visado para a estabilidade do produto. A separação entre os grupos pode facilmente passar a ser não só em relação a pagamentos de incentivos, mas também a comunicação, metas e, após um tempo, até mesmo em confiança e respeito. O resultado é uma patologia. Desse modo, equipes tradicionais de operações e suas contrapartidas em desenvolvimento de produtos com frequência acabam em conflito, em que o mais visível diz respeito à rapidez com que o software pode ser disponibilizado para produção. Em sua essência, as equipes de desenvolvimento querem lançar novas funcionalidades e vê-las adotadas pelos usuários. As equipes de operações, em sua essência, querem garantir que o serviço não falhe enquanto estiverem de posse do pager. Como a maioria das interrupções de serviço é causada por algum tipo de mudança – uma nova configuração, o lançamento de uma nova funcionalidade ou um novo tipo de tráfego de usuário –, as metas das duas equipes entram fundamentalmente em conflito.

Engenharia de Confiabilidade do Google

Os dois grupos entendem que é inaceitável definir seus interesses nos termos mais francos possíveis (“Queremos lançar tudo, a qualquer momento, sem impedimentos” versus “Não queremos jamais mudar nada no sistema depois que ele estiver funcionando”). Como seu vocabulário e as pressuposições quanto aos riscos diferem, os dois grupos muitas vezes recorrem a uma forma familiar de guerra de trincheiras para fazer seus interesses prevalecerem. A equipe de operações tenta proteger o sistema em execução contra o risco de mudanças introduzindo pontos de verificação (gates) para lançamentos e mudanças. Por exemplo, revisões para lançamento podem conter uma verificação explícita de todos os problemas que alguma vez já causaram uma interrupção de serviço no passado – pode ser uma lista arbitrariamente longa, em que nem todos os elementos têm o mesmo valor. A equipe de desenvolvimento rapidamente aprende a responder. Essas equipes fazem menos “lançamentos” e criam mais “flags de ativação”, fazem “atualizações incrementais” ou “cherry-picks”2. Adotam táticas como dividir o produto em partes para que menos funcionalidades estejam sujeitas à revisão de lançamento.

A abordagem do Google para o gerenciamento de serviços: Site Reliability Engineering O conflito não é uma parte inevitável no oferecimento de um serviço de software. No Google optamos por operar nossos sistemas usando uma abordagem diferente: nossas equipes de Site Reliability Engineering (Engenharia de Confiabilidade de Sites) se concentram em contratar engenheiros de software para operar nossos produtos e criar sistemas para realizar o trabalho que, de outro modo, seria realizado por administradores de sistemas, com frequência, manualmente. O que é exatamente Site Reliability Engineering, conforme passou a ser definido pelo Google? Minha explicação é simples: SRE é o que acontece quando você pede a um engenheiro de software para projetar uma equipe de operações. Quando me juntei ao Google em 2003 e me foi atribuída a responsabilidade de operar uma “Equipe de Produção” com sete engenheiros, minha vida toda até então havia sido em engenharia de software. Portanto, projetei e administrei o grupo do modo como eu gostaria que ele funcionasse se eu mesmo trabalhasse como um SRE. Esse grupo, desde então, amadureceu até se tornar a equipe de SRE do Google como é hoje, que permanece fiel às suas origens conforme a visão de um engenheiro de software de longa data. 2 N.T.: Levar apenas alguns commits específicos de um branch para outro.

Capítulo 1 ■ Introdução

Um bloco de construção principal da abordagem do Google ao gerenciamento de serviços é a composição de cada equipe de SRE. Como um todo, a SRE pode ser dividida em duas categorias principais. De 50 a 60% são Engenheiros de Software do Google (Google Software Engineers) ou, mais precisamente, pessoas que foram contratadas por meio do procedimento-padrão para Engenheiros de Software do Google. Os outros 40 a 50% são candidatos que ficaram muito próximos das qualificações de Engenheiros de Software do Google (isto é, com 85 a 99% do conjunto de habilidades exigido) e que, além disso, tinham um conjunto de habilidades técnicas úteis à SRE, mas raro na maioria dos engenheiros de software. De longe, expertise no funcionamento interno do sistema Unix e em redes (Camadas 1 a 3) são os dois tipos mais comuns de habilidades técnicas alternativas que procuramos. Comum a todos os SREs é a crença e a aptidão para desenvolver sistemas de software a fim de resolver problemas complexos. Na SRE monitoramos o progresso na carreira de ambos os grupos bem de perto e, até agora, não percebemos nenhuma diferença prática de desempenho entre os engenheiros dos dois lados. Com efeito, a experiência prévia, de certo modo, diferente, da equipe de SRE com frequência resulta em sistemas de alta qualidade e inteligentes, que são claramente o produto da síntese de vários conjuntos de habilidades. O resultado de nossa abordagem na contratação de SREs é que acabamos com uma equipe de pessoas que (a) ficará rapidamente entediada realizando tarefas manualmente e (b) tem o conjunto de habilidades necessário para escrever um software de modo a substituir seu trabalho anteriormente manual, mesmo quando a solução for complicada. Os SREs também acabam compartilhando experiências acadêmicas e intelectuais anteriores com o restante da equipe de desenvolvimento. Desse modo, a SRE consiste essencialmente em fazer o trabalho que, historicamente, era feito por uma equipe de operações, porém usando engenheiros com expertise em software, e contando com o fato de que esses engenheiros, de forma inerente, são predispostos e têm a habilidade para fazer o design e implementar automações com um software para substituir o trabalho humano. Por design, é fundamental que as equipes de SRE estejam focadas em engenharia. Sem uma engenharia constante, a carga das operações aumenta e as equipes precisarão de mais pessoas somente para acompanhar esse aumento da carga de trabalho. Em algum momento no futuro, um grupo tradicional focado em operações escalará linearmente conforme o volume do serviço: se os produtos aos quais o serviço dá suporte forem bem-sucedidos, a carga operacional aumentará com o tráfego. Isso significa contratar mais pessoas para fazer as mesmas tarefas repetidamente.

Engenharia de Confiabilidade do Google

Para evitar esse destino, a equipe responsável pelo gerenciamento de um serviço deve escrever código; do contrário, ficará sobrecarregada. Desse modo, o Google coloca um limite de 50% no trabalho agregado de “ops” para todos os SREs – tickets, plantão, tarefas manuais etc. Esse limite garante que a equipe de SRE tenha tempo suficiente em seus cronogramas para deixar o serviço estável e operacional. Esse é um limite superior; com o tempo, se deixados por conta própria, a equipe de SRE deverá acabar com pouca carga operacional e se envolverá quase totalmente em tarefas de desenvolvimento, pois o serviço basicamente opera e se corrige sozinho: queremos sistemas que sejam automáticos, e não apenas automatizados. Na prática, a escala e novas funcionalidades sustentam os SREs. A regra geral do Google é que uma equipe de SRE deve gastar os outros 50% de seu tempo fazendo desenvolvimento. Então, como garantimos o cumprimento desse limite? Em primeiro lugar, precisamos mensurar como o tempo dos SREs é gasto. Com esse dado em mãos, garantimos que as equipes que estejam gastando menos de 50% de seu tempo, de forma consistente, em trabalhos de desenvolvimento mudem suas práticas. Com frequência, isso quer dizer passar parte da carga de operações de volta à equipe de desenvolvimento ou aumentar a equipe sem lhe atribuir novas responsabilidades operacionais. Manter esse equilíbrio entre tarefas de ops e de desenvolvimento de forma consciente nos permite garantir que os SREs tenham tempo para se envolver em uma engenharia criativa e autônoma, ao mesmo tempo que preservam a sabedoria adquirida do lado das operações de um serviço. Descobrimos que a abordagem de SRE do Google para operar sistemas de larga escala tem muitas vantagens. Como os SREs modificam diretamente o código em sua busca por fazer com que os sistemas do Google executem sozinhos, as equipes de SRE têm como características tanto a inovação rápida quanto um alto grau de aceitação de mudanças. Essas equipes têm custo relativamente baixo – dar suporte ao mesmo serviço com uma equipe orientada a operações exigiria um número significativamente maior de pessoas. Em vez disso, o número de SREs necessário para operar, manter e melhorar um sistema escala de forma proporcionalmente menor ao tamanho do sistema. Por fim, a SRE não só contorna a falta de funcionalidade da divisão dev/ops, como também essa estrutura melhora nossas equipes de desenvolvimento de produtos: transferências fáceis entre as equipes de desenvolvimento de produtos e de SRE possibilitam um treinamento cruzado de todo o grupo e melhoram as habilidades dos desenvolvedores que, de outro modo, poderiam ter dificuldades em aprender a construir um sistema distribuído de um milhão de núcleos de CPU (cores).

Capítulo 1 ■ Introdução

Apesar desses ganhos líquidos, o modelo de SRE é caracterizado pelo seu próprio conjunto distinto de desafios. Um desafio contínuo que o Google enfrenta é contratar os SREs: o SRE não só concorre com os mesmos candidatos do processo de contratação da equipe de desenvolvimento de produtos, como também o fato de definirmos a qualificação para contratação em um nível muito alto no que diz respeito às habilidades tanto de programação quanto de engenharia de sistemas implica que nossas opções de candidatos à contratação são necessariamente reduzidas. Como nossa área é relativamente nova e única, não há muitas informações no mercado sobre como montar e administrar uma equipe de SRE (espero, porém, que este livro dê alguns passos nessa direção!). Depois que uma equipe de SRE estiver montada, suas abordagens possivelmente não ortodoxas à administração de serviços exigem um forte apoio da gerência. Por exemplo, a decisão de interromper os lançamentos de novas versões pelo restante do trimestre depois que uma provisão para erros (error budget) tenha sido consumida pode não ser aceita por uma equipe de desenvolvimento de produto, a menos que seja imposta pela gerência.

DevOps ou SRE? O termo “DevOps” surgiu no mercado no final de 2008 e, na época desta publicação (início de 2016), continuava em mudança. Seus princípios essenciais – envolvimento da função de TI em cada fase do design e do desenvolvimento de um sistema, alta dependência de automação em comparação com esforços humanos, aplicação de práticas e ferramentas de engenharia em tarefas de operação – são consistentes com muitas das práticas e dos princípios de SRE. Poderíamos ver o DevOps como uma generalização de vários princípios essenciais de SRE para uma variedade maior de organizações, estruturas gerenciais e recursos humanos. Do mesmo modo, poderíamos ver a SRE como uma implementação específica de DevOps, com algumas extensões idiossincráticas.

Princípios da SRE Embora as nuances de fluxos de trabalho, prioridades e operações cotidianas variem de equipe de SRE para equipe de SRE, todas compartilham um conjunto básico de responsabilidades para o(s) serviço(s) ao(s) qual(is) dão suporte e respeitam os mesmos princípios essenciais. Em geral, uma equipe de SRE é

Engenharia de Confiabilidade do Google

responsável pela disponibilidade, latência, desempenho, eficiência, gerenciamento de mudanças, monitoração, respostas a emergências e planejamento da capacidade de seu(s) serviço(s). Definimos regras de envolvimento e princípios para o modo como as equipes de SRE interagem com seus ambientes – não só com o ambiente de produção, mas também com as equipes de desenvolvimento de produtos, as equipes de testes, os usuários, e assim por diante. Essas regras e práticas de trabalho nos ajudam a manter o foco em tarefas de engenharia, em oposição a mantê-lo em tarefas de operação. A próxima seção discute cada um desses princípios essenciais da SRE do Google.

Garantindo um foco durável em engenharia Como já discutimos, o Google limita as tarefas operacionais dos SREs em 50% de seu tempo. O tempo restante deve ser gasto usando suas habilidades de programação em tarefas de projeto. Na prática, isso é feito monitorando a quantidade de tarefas operacionais feitas pelos SREs e redirecionando o excesso dessas tarefas para as equipes de desenvolvimento de produtos: atribuindo bugs e tickets de volta aos gerentes de desenvolvimento, (re)integrando os desenvolvedores nas escalas de plantão com pagers, e assim por diante. O redirecionamento termina quando a carga operacional reduzir para 50% ou menos novamente. Isso também proporciona um sistema eficiente de feedback, orientando os desenvolvedores a criar sistemas que não precisem de intervenções manuais. Essa abordagem funciona bem quando toda a empresa – as equipes de SRE e de desenvolvimento, igualmente – entende por que o sistema de válvula de segurança existe e dá suporte à meta de não ter eventos de transbordamento (overflow) porque o produto não gera carga operacional suficiente para exigi-la. Quando se concentram em tarefas de operação, em média, os SREs devem receber um máximo de dois eventos em um turno de 8 a 12 horas de plantão. Esse volume visado dá tempo suficiente a um engenheiro de plantão para tratar o evento de forma rápida e precisa, limpar e restaurar os serviços de volta ao normal e então conduzir um postmortem. Se houver mais de dois eventos regularmente por turno de plantão, os problemas não poderão ser investigados de forma completa e os engenheiros estarão sobrecarregados a ponto de não poderem aprender com esses eventos. Um cenário com muitas solicitações de pager também não melhorará com um aumento da equipe. Por outro lado, se os SREs de plantão receberem menos de um evento por turno de forma consistente, mantê-los assim será um desperdício de seu tempo.

Capítulo 1 ■ Introdução

Os postmortems devem ser escritos para todos os incidentes significativos, não importa se houve um acionamento de pager; os postmortems que não acionaram um pager são mais valiosos ainda, pois é provável que apontem para lacunas claras na monitoração. Essa investigação deve definir o que aconteceu em detalhes, identificar todas as causas-raízes do evento e atribuir ações para corrigir o problema ou melhorar o modo como será abordado da próxima vez. O Google opera com uma cultura de postmortem sem acusações, com o objetivo de expor falhas e aplicar engenharia para corrigi-las, em vez de evitá-las ou minimizá-las.

Buscando a máxima rapidez nas mudanças sem violar o SLO de um serviço As equipes de desenvolvimento de produtos e de SRE podem desfrutar de um relacionamento profissional produtivo se eliminarem os conflitos estruturais em suas respectivas metas. O conflito estrutural se encontra entre o ritmo da inovação e a estabilidade do produto e, conforme descrito antes, muitas vezes é expresso de forma indireta. Em SRE trazemos esse conflito para o primeiro plano e então o resolvemos com a introdução de uma provisão para erros (error budget). A provisão para erros originou-se da observação de que 100% é a meta de confiabilidade incorreta para basicamente tudo (marca-passos e freios ABS são exceções relevantes). Em geral, para qualquer serviço ou sistema de software, 100% não é a meta correta de confiabilidade porque nenhum usuário poderá dizer qual é a diferença entre um sistema 100% disponível ou 99,999% disponível. Há muitos outros sistemas no caminho entre o usuário e o serviço (seu notebook, o WiFi doméstico, o ISP, a rede de energia elétrica etc.), e esses sistemas em conjunto têm disponibilidade bem menor que 99,999%. Assim, a diferença marginal entre 99,999% e 100% é perdida nos ruídos provocados por outras faltas de disponibilidade, e o usuário não terá nenhuma vantagem do enorme esforço exigido para acrescentar aquele último 0,001% de disponibilidade. Se 100% é a meta de confiabilidade incorreta para um sistema, então qual é a meta correta? Essa, na verdade, não é uma pergunta técnica – é uma pergunta relacionada ao produto e que deve levar em consideração as seguintes questões: • Qual é o nível de disponibilidade que deixará os usuários satisfeitos, dado o modo como eles usam o produto? • Quais alternativas estão disponíveis aos usuários que não estiverem satisfeitos com a disponibilidade do produto? • O que acontece com a utilização do produto pelos usuários em diferentes níveis de disponibilidade?

Engenharia de Confiabilidade do Google

O negócio ou o produto devem definir a meta de disponibilidade do sistema. Depois que essa meta for definida, a provisão para erros será um menos a meta de disponibilidade. Um serviço que esteja 99,99% disponível estará 0,01% indisponível. Esse 0,01% permitido de indisponibilidade é a provisão para erros (error budget) do serviço. Podemos gastar a provisão no que quisermos, desde que não gastemos mais que o seu valor. Então, como queremos gastar a provisão para erros? A equipe de desenvolvimento quer lançar funcionalidades e atrair novos usuários. O ideal seria gastarmos toda a nossa provisão para erros assumindo riscos com o que lançarmos para fazer o lançamento rapidamente. Essa premissa básica descreve o modelo completo das provisões para erros. Assim que as atividades de SRE são conceituadas nesse modelo, usar a provisão de erros com táticas como rollouts em fases e experimentos de 1% pode otimizar o processo para permitir lançamentos mais rápidos. O uso de uma provisão para erros resolve o conflito estrutural de pagamento de incentivos entre desenvolvimento e SRE. A meta de SRE deixa de ser “nenhuma interrupção de serviço”; em vez disso, os SREs e os desenvolvedores de produto têm como objetivo gastar a provisão de erros para obter o máximo de rapidez no lançamento de funcionalidades. Essa mudança faz toda a diferença. Uma interrupção de serviço deixa de ser algo “ruim” – é uma parte esperada do processo de inovação, e uma ocorrência que as equipes tanto de desenvolvimento quanto de SRE devem administrar, em vez de temer.

Monitoração A monitoração é um dos principais meios pelos quais os proprietários de serviços controlam a saúde e a disponibilidade de um sistema. Desse modo, uma estratégia de monitoração deve ser criada de modo bem planejado. Uma abordagem clássica e comum para a monitoração consiste em observar um valor ou uma condição específicos e, então, enviar um email de alerta quando esse valor for excedido ou a condição ocorrer. No entanto, esse tipo de alerta por email não é uma solução eficaz: um sistema que exija uma pessoa para ler um email e decidir se algum tipo de ação deve ser executado em resposta tem uma falha fundamental. A monitoração jamais deve exigir um ser humano para interpretar qualquer parte do domínio do alerta. Em vez disso, um software deve fazer a interpretação e os seres humanos devem ser notificados somente quando houver a necessidade de tomar uma atitude.

Capítulo 1 ■ Introdução

Há três tipos de saídas válidas para a monitoração: Alertas Significam que um ser humano deve tomar uma atitude imediata em resposta a algo que esteja acontecendo ou que está prestes a ocorrer, para que a situação melhore. Tickets Significam que um ser humano deve tomar uma atitude, mas não de imediato. O sistema não é capaz de tratar a situação de modo automático, mas se um ser humano tomar uma atitude em alguns dias, não haverá nenhum dano resultante. Logging Ninguém precisa ver essa informação, mas ela será registrada para diagnóstico e investigação forense. A expectativa é que ninguém leia os logs, a menos que outro fato exija que isso seja feito.

Resposta a emergências A confiabilidade é uma função do MTTF (Mean Time To Failure, ou Tempo Médio para Falhas) e do MTTR (Mean Time To Repair, ou Tempo Médio para Correção) [Sch15]. A métrica mais relevante na avaliação da eficiência da resposta a emergências é a rapidez com que a equipe de resposta é capaz de deixar o sistema novamente saudável, isto é, o MTTR. Seres humanos acrescentam latência. Mesmo que um dado sistema tenha mais falhas propriamente ditas, um sistema capaz de evitar emergências que exijam intervenção humana terá mais disponibilidade que um sistema que exija uma intervenção manual. Quando há necessidade da intervenção de seres humanos, percebemos que pensar nas melhores práticas e registrá-las com antecedência em um “manual de regras” resulta em uma melhoria de aproximadamente três vezes no MTTR se comparada à estratégia de “improvisar”. O engenheiro herói de plantão, “pau pra toda obra”, faz o serviço, porém o engenheiro de plantão treinado, de posse de um manual de regras, faz um trabalho bem melhor. Embora nenhum manual de regras, independentemente de sua abrangência, seja um substituto para engenheiros inteligentes, capazes de raciocinar diante da situação, passos e dicas claros e completos para resolver problemas são valiosos para responder a uma chamada de importância crítica ou em que o tempo seja crucial. Desse modo, a

Engenharia de Confiabilidade do Google

SRE do Google conta com manuais de regras para os que estão de plantão, além de exercícios como “Wheel of Misfortune” (Roda do Azar)3 para preparar os engenheiros a reagirem a eventos quando estiverem de plantão.

Gerenciamento de mudanças A SRE descobriu que, em geral, 70% das interrupções de serviço se devem a mudanças em um sistema ativo. As melhores práticas nesse domínio utilizam automação para fazer o seguinte: • implementar rollouts progressivos; • detectar problemas de forma rápida e precisa; • fazer rollback das mudanças de modo seguro quando surgirem problemas. Esse trio de práticas minimiza de forma eficiente o número total de usuários e operações expostos a mudanças ruins. Ao remover os seres humanos do circuito, essas práticas evitam os problemas comuns de cansaço, familiaridade/menosprezo e falta de atenção a tarefas altamente repetitivas. Como resultado, há um aumento tanto da velocidade na disponibilização de uma nova versão quanto da segurança.

Previsão de demanda e planejamento de capacidade Previsão de demanda e planejamento de capacidade podem ser vistos como um meio de garantir que haja capacidade suficiente e redundância para servir a uma demanda futura projetada, com a disponibilidade necessária. Não há nada particularmente especial nesses conceitos, exceto que um número surpreendente de serviços e equipes não executa os passos necessários para garantir que a capacidade exigida esteja implantada na ocasião em que se tornar necessária. O planejamento de capacidade deve levar em consideração tanto o crescimento orgânico (proveniente da adoção natural do produto e do uso pelos clientes) quanto o crescimento inorgânico (que resulta de eventos como lançamentos de funcionalidades, campanhas de marketing ou outras mudanças orientadas ao negócio). Vários passos são obrigatórios no planejamento de capacidade: • uma previsão exata da demanda orgânica, que se estenda para além do tempo de antecedência exigido para aquisição de capacidade; • uma incorporação precisa das fontes de demanda inorgânica na previsão de demanda; 3 Veja a seção “Interpretando papéis em situações de desastre”, na página 507.

Capítulo 1 ■ Introdução

• testes regulares de carga do sistema para correlacionar a capacidade bruta (servidores, discos e assim por diante) com a capacidade do serviço. Como a capacidade é crítica para a disponibilidade, a implicação natural é que a equipe de SRE deve ser responsável pelo planejamento de capacidade, o que significa que ela também deve ser responsável pelo provisionamento.

Provisionamento O provisionamento combina tanto o gerenciamento de mudanças quanto o planejamento de capacidade. Em nossa experiência, o provisionamento deve ser conduzido de forma rápida e somente quando necessário, pois a capacidade tem custo alto. Esse exercício também deve ser feito de forma correta; caso contrário, a capacidade não estará operacional quando for necessária. Acrescentar mais capacidade com frequência envolve ativar uma nova instância ou localização, fazer modificações significativas em sistemas existentes (arquivos de configuração, distribuidores de carga, rede) e validar se a nova capacidade está operacional e fornece os resultados corretos. Desse modo, é uma operação de mais risco que a transferência de carga, que com frequência é feita várias vezes por hora, e deve ser tratada com um grau extra de cuidado correspondente.

Eficiência e desempenho O uso eficiente de recursos é importante sempre que um serviço se preocupa com dinheiro. Como a SRE, em última instância, controla o provisionamento, ela também deve se envolver em qualquer tarefa relacionada à utilização, pois a utilização é uma função de como um dado serviço opera e como é provisionado. Isso implica que prestar bastante atenção na estratégia de provisionamento de um serviço e, desse modo, em sua utilização, proporciona uma grande vantagem nos custos totais do serviço. O uso de recursos é uma função da demanda (carga), da capacidade e da eficiência do software. Os SREs preveem a demanda, fazem provisionamento da capacidade e podem modificar o software. Esses três fatores representam uma grande parte (mas não a totalidade) da eficiência de um serviço. Os sistemas de software se tornam mais lentos à medida que sua carga aumenta. Um serviço mais lento é equivalente a uma perda de capacidade. Em algum momento, um sistema que se tornou mais lento para de servir, o que corresponde a uma lentidão infinita. Os SREs fazem um provisionamento para atender a uma

Engenharia de Confiabilidade do Google

meta de capacidade a uma velocidade específica de resposta e, desse modo, estão profundamente interessados no desempenho de um serviço. Os SREs e os desenvolvedores de produto vão (e devem) monitorar e modificar um serviço a fim de melhorar o seu desempenho, aumentando assim a capacidade e melhorando a eficiência.4

O fim do começo A Site Reliability Engineering representa uma ruptura significativa das melhores práticas de mercado existentes para administrar serviços grandes e complicados. Motivada originalmente pela familiaridade – “como engenheiro de software, é assim que eu gostaria de investir o meu tempo para realizar um conjunto de tarefas repetitivas” –, ela se tornou muito mais: um conjunto de princípios, práticas e incentivos, e um campo de empreendimento dentro da disciplina mais ampla de engenharia de software. O restante do livro explora o Modo SRE em detalhes.

4 Para outras discussões sobre como essa colaboração pode funcionar na prática, consulte a seção “Comunicações: reuniões de produção”, na página 535.