Introdução
Escrito por Benjamin Treynor Sloss
Revisado por Betsy Beyer
Esperança não é uma estratégia.
Ditado popular do SRE
É uma verdade universalmente reconhecida que os sistemas não funcionam sozinhos. Como, então, um sistema – particularmente um sistema de computação complexo que opera em grande escala – deve ser executado?
A Abordagem Sysadmin para Gerenciamento de Serviços
Historicamente, as empresas empregam administradores de sistemas para executar sistemas de computação complexos.
Esta abordagem de administrador de sistemas, ou sysadmin, envolve a montagem de componentes de software existentes, e a implantação deles para trabalharem juntos para produzir um serviço. Os administradores de sistemas são, então, encarregados de executar o serviço e responder a eventos e atualizações à medida que ocorrem. Conforme o sistema cresce em complexidade e volume de tráfego, gerando um aumento correspondente em eventos e atualizações, a equipe de administradores de sistema cresce para absorver o trabalho adicional. Como a função de administrador de sistema requer um conjunto de habilidades marcadamente, diferente do exigido dos desenvolvedores de um produto, os desenvolvedores e administradores de sistema são divididos em equipes distintas: “desenvolvimento” e “operações” ou “ops”.
O modelo sysadmin de gerenciamento de serviços tem várias vantagens. Para empresas que decidem como administrar e contratar um serviço, essa abordagem é relativamente fácil de implementar: como um paradigma familiar do setor, há muitos exemplos para aprender e emular. Um pool de talentos relevante já está amplamente disponível. Uma série de ferramentas existentes, componentes de software (prontos ou não) e empresas de integração, estão disponíveis para ajudar a executar esses sistemas montados para que uma equipe de administrador de sistema novata não tenha que reinventar a roda e projetar um sistema do zero.
A abordagem sysadmin, e a divisão desenvolvimento/ops que a acompanha, tem uma série de desvantagens e armadilhas. Estes se enquadram em duas categorias: custos diretos e custos indiretos.
Os custos diretos não são sutis e nem ambíguos. Executar um serviço com uma equipe que depende de intervenção manual para gerenciamento de mudanças e tratamento de eventos torna-se caro à medida que o serviço e/ou o tráfego para o serviço aumenta, porque o tamanho da equipe necessariamente se dimensiona com a carga gerada pelo sistema.
Os custos indiretos da divisão desenvolvimento/operações podem ser sutis, mas geralmente são mais caros para a organização do que os custos diretos. Esses custos surgem do fato de que as duas equipes são bastante diferentes em termos de formação, conjunto de habilidades e incentivos. Eles usam um vocabulário diferente para descrever situações; carregam diferentes suposições sobre riscos e possibilidades para soluções técnicas; têm diferentes suposições sobre o nível alvo de estabilidade do produto. A divisão entre os grupos pode facilmente se transformar não apenas em incentivos, mas também em comunicação, objetivos e, eventualmente, confiança e respeito. Esse resultado é uma patologia.
As equipes de operações tradicionais e suas contrapartes no desenvolvimento de produtos muitas vezes acabam em conflito, mais visivelmente sobre a rapidez com que o software pode ser lançado para produção. Em sua essência, as equipes de desenvolvimento desejam lançar novos recursos e vê-los adotados pelos usuários. Em sua essência, as equipes de operações querem ter certeza de que o serviço não será interrompido enquanto estiverem segurando o pager. Como a maioria das interrupções é causada por algum tipo de mudança – uma nova configuração, um novo lançamento de recurso ou um novo tipo de tráfego de usuário – os objetivos das duas equipes estão fundamentalmente em tensão.
Ambos os grupos entendem que é inaceitável declarar seus interesses nos termos mais simples possíveis (“Queremos lançar qualquer coisa, a qualquer momento, sem obstáculos” versus “Não queremos mudar nada no sistema depois que ele funcionar”). E porque seu vocabulário e suposições de risco diferem, ambos os grupos frequentemente recorrem a uma forma familiar de guerra de trincheiras para promover seus interesses. A equipe de operações tenta proteger o sistema em execução contra o risco de mudança, introduzindo portas de lançamento e de mudança. Por exemplo, as revisões de lançamento podem conter uma verificação explícita para cada problema que já causou uma interrupção no passado – isso pode ser uma lista arbitrariamente longa, com nem todos os elementos fornecendo o mesmo valor. A equipe de desenvolvimento aprende rapidamente como responder. Eles têm menos “lançamentos” e mais “mudanças de bandeira”, “atualizações incrementais” ou “escolhas aleatórias”. Eles adotam táticas como fragmentar o produto para que menos recursos sejam sujeitos à análise de lançamento.
Abordagem do Google para o gerenciamento de serviços: Engenharia de Confiabilidade
O conflito não é uma parte inevitável da oferta de um serviço de software. O Google optou por executar nossos sistemas com uma abordagem diferente: nossas equipes de engenharia de confiabilidade se concentram na contratação de engenheiros de software para executar nossos produtos e criar sistemas para realizar o trabalho que, de outra forma, seria executado, geralmente manualmente, por administradores de sistemas.
O que exatamente é Engenharia de Confiabilidade, como veio a ser definido no 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 entrei para o Google em 2003 e fui incumbido de dirigir uma “Equipe de Produção” de sete engenheiros, minha vida inteira até aquele ponto tinha sido engenharia de software. Portanto, projetei e gerenciei o grupo da maneira que gostaria que funcionasse se eu próprio trabalhasse como SRE. Desde então, esse grupo amadureceu para se tornar a atual equipe de SRE do Google, que permanece fiel às suas origens, conforme idealizado por um engenheiro de software ao longo da vida.
Um dos principais alicerces da abordagem do Google para o gerenciamento de serviços é a composição de cada equipe SRE. Como um todo, os SREs podem ser divididos em duas categorias principais.
50–60% são engenheiros de software do Google ou, mais precisamente, pessoas que foram contratadas por meio do procedimento padrão para engenheiros de software do Google. Os outros 40–50% são candidatos que estavam muito próximos das qualificações de engenharia de software do Google (ou seja, 85–99% do conjunto de habilidades necessárias) e que, além disso, tinham um conjunto de habilidades técnicas que são úteis para SRE, mas são raras para a maioria dos engenheiros de software. De longe, a experiência interna e de rede do sistema UNIX (Camada 1 a Camada 3) são os dois tipos mais comuns de habilidades técnicas alternativas que buscamos.
Comum a todos os SREs é a crença e aptidão para o desenvolvimento de sistemas de software para resolver problemas complexos. No SRE, acompanhamos de perto o progresso da carreira de ambos os grupos e, até o momento, não encontramos nenhuma diferença prática no desempenho entre os engenheiros das duas áreas. Na verdade, a formação, um tanto diversa da equipe SRE, frequentemente resulta em sistemas inteligentes e de alta qualidade que são claramente o produto da síntese de vários conjuntos de habilidades.
O resultado de nossa abordagem de contratação para SRE é que acabamos com uma equipe de pessoas que, (a) se cansarão rapidamente de realizar tarefas à mão, e (b) terão o conjunto de habilidades necessárias para escrever software para substituir seu manual anterior, mesmo quando a solução é complicada. Os SREs também acabam compartilhando a formação acadêmica e intelectual com o resto da organização de desenvolvimento. Portanto, o SRE está basicamente fazendo um trabalho que tem sido feito, historicamente, por uma equipe de operações, mas usando engenheiros com experiência em software e apostando no fato de que esses engenheiros são inerentemente predispostos e têm a capacidade de projetar e implementar automação com software para substituir o trabalho humano.
Por design, é crucial que as equipes de SRE se concentrem na engenharia. Sem engenharia constante, a carga de operações aumenta e as equipes precisarão de mais pessoas apenas para acompanhar o ritmo da carga de trabalho. Eventualmente, um grupo tradicional focado em operações é escalonado linearmente com o tamanho do serviço: se os produtos suportados pelo serviço forem bem-sucedidos, a carga operacional aumentará com o tráfego. Isso significa contratar mais pessoas para fazer as mesmas tarefas continuamente.
Para evitar esse destino, a equipe encarregada de gerenciar um serviço precisa codificar ou ele irá se afogar. Portanto, o Google estabelece um limite de 50% nas “operações” agregadas para todos os SREs: tíquetes, plantão, tarefas manuais etc. Esse limite garante que a equipe de SRE tenha tempo suficiente em sua programação, para tornar o serviço estável e operável . Este limite é um limite superior, com o tempo, deixada por conta própria, a equipe do SRE deve ficar com muito pouca carga operacional e quase que totalmente envolvida nas tarefas de desenvolvimento, porque o serviço basicamente funciona e se repara sozinho: queremos sistemas que sejam automáticos, não apenas automatizados. Na prática, a escala e os novos recursos mantêm os SREs atentos.
A regra geral do Google é que uma equipe de SRE deve gastar os 50% restantes de seu tempo realmente fazendo o desenvolvimento. Então, como podemos impor esse limite? Em primeiro lugar, temos que medir como o tempo SRE é gasto. Com essa medição em mãos, garantimos que as equipes que gastam consistentemente menos de 50% de seu tempo no trabalho de desenvolvimento mudem suas práticas. Frequentemente, isso significa transferir parte da carga de operações de volta para a equipe de desenvolvimento ou adicionar pessoal à equipe sem atribuir a essa equipe responsabilidades operacionais adicionais. Manter conscientemente esse equilíbrio entre as operações e o trabalho de desenvolvimento nos permite garantir que os SREs tenham largura de banda para se envolver em engenharia autônoma e criativa, ao mesmo tempo em que retém a sabedoria adquirida no lado das operações da execução de um serviço.
Descobrimos que a abordagem do Google SRE para executar sistemas em grande escala tem muitas vantagens. Como os SREs estão modificando diretamente o código em sua busca, por fazer os sistemas do Google funcionarem sozinhos, as equipes de SRE são caracterizadas por uma inovação rápida e uma grande aceitação da mudança. Essas equipes são relativamente baratas – dar suporte ao mesmo serviço com uma equipe orientada para operações exigiria um número significativamente maior de pessoas. Em vez disso, o número de SREs necessários para executar, manter e melhorar um sistema é dimensionado subliminarmente com o tamanho do sistema. Finalmente, o SRE não apenas contorna a disfuncionalidade da divisão dev/ops, mas essa estrutura também melhora nossas equipes de desenvolvimento de produto: transferências fáceis entre o desenvolvimento de produto e as equipes de SRE, treinam todo o grupo e melhoram as habilidades dos desenvolvedores que de outra forma poderiam dificuldade em aprender como construir um sistema distribuído com um milhão de núcleos.
Apesar desses ganhos líquidos, o modelo SRE é caracterizado por seu próprio conjunto distinto de desafios. Um desafio contínuo que o Google enfrenta é a contratação de SREs: não apenas SRE compete pelos mesmos candidatos que o pipeline de contratação de desenvolvimento de produto, mas o fato de definirmos a barreira de contratação tão alta, em termos de habilidades de codificação e engenharia de sistema, significa que nosso pool de contratação é necessariamente pequeno. Como nossa disciplina é relativamente nova e única, não existem muitas informações do setor sobre como construir e gerenciar uma equipe de SRE (embora esperemos que este livro faça avanços nessa direção!). E, uma vez que uma equipe de SRE está instalada, suas abordagens potencialmente heterodoxas para o gerenciamento de serviços exigem um forte suporte de gerenciamento. Por exemplo, a decisão de interromper as liberações para o restante do trimestre, uma vez que um error budget é esgotado, pode não ser adotada por uma equipe de desenvolvimento de produto, a menos que seja mandatado por sua gerência.
DevOps ou SRE?
O termo “DevOps” surgiu na indústria no final de 2008 e, no momento em que este livro foi escrito (início de 2016), ainda está em um estado de mudança. Seus princípios fundamentais – envolvimento da função de TI em cada fase do design e desenvolvimento de um sistema, forte dependência de automação versus esforço humano, a aplicação de práticas de engenharia e ferramentas para tarefas operacionais – são consistentes com muitos dos princípios e práticas de SRE. Pode-se ver o DevOps como uma generalização de vários princípios básicos de SRE para uma gama mais ampla de organizações, estruturas de gerenciamento e pessoal. Pode-se ver, de forma equivalente, o SRE como uma implementação específica de DevOps com algumas extensões idiossincráticas.
Princípios de SRE
Embora as nuances dos fluxos de trabalho, prioridades e operações do dia a dia variem de equipe SRE para equipe SRE, todas compartilham um conjunto de responsabilidades básicas para o(s) serviço(s) que oferecem suporte e aderem aos mesmos princípios básicos. Em geral, uma equipe de SRE é responsável pela disponibilidade, latência, desempenho, eficiência, gerenciamento de mudanças, monitoramento, resposta a emergências e planejamento de capacidade de seu(s) serviço(s). Codificamos regras de engajamento e princípios para como as equipes de SRE interagem com seu ambiente – não apenas o ambiente de produção, mas também as equipes de desenvolvimento de produto, as equipes de teste, os usuários e assim por diante. Essas regras e práticas de trabalho nos ajudam a manter nosso foco no trabalho de engenharia, em oposição ao trabalho de operações.
A seção a seguir discute cada um dos princípios básicos do Google SRE.
Garantindo um Foco Durável na Engenharia
Conforme já discutido, o Google limita o trabalho operacional para SREs em 50% do tempo. O tempo restante deve ser gasto usando suas habilidades de codificação no trabalho do projeto. Na prática, isso é realizado monitorando a quantidade de trabalho operacional que está sendo feito pelos SREs e redirecionando o excesso de trabalho operacional para as equipes de desenvolvimento de produto: reatribuindo bugs e tíquetes aos gerentes de desenvolvimento, [re]integração dos desenvolvedores em rotações de pager de plantão e assim por diante. O redirecionamento termina quando a carga operacional cai para 50% ou menos. Isso também fornece um mecanismo de feedback eficaz, orientando os desenvolvedores a construir sistemas que não precisam de intervenção manual. Esta abordagem funciona bem quando toda a organização – SRE e desenvolvimento – entende por que o mecanismo de válvula de segurança existe e apoia o objetivo de não haver eventos de estouro porque o produto não gera carga operacional suficiente para exigi-lo.
Quando estão focados no trabalho operacional, em média, os SREs devem receber no máximo dois eventos por turno de plantão de 8 a 12 horas. Esse volume de destino dá ao engenheiro de plantão tempo suficiente para lidar com o evento com precisão e rapidez, limpar e restaurar o serviço normal e, em seguida, conduzir uma autópsia. Se mais de dois eventos ocorrem regularmente por turno de plantão, os problemas não podem ser investigados completamente e os engenheiros estão suficientemente sobrecarregados para evitar que aprendam com esses eventos. Um cenário de fadiga do pager também não melhora com a escala. Por outro lado, se os SREs de plantão recebem consistentemente menos de um evento por turno, mantê-los no ponto é uma perda de tempo.
Postmortems devem ser escritos para todos os incidentes significativos, independentemente de terem sido alertados ou não; postmortems que não acionaram um alerta são ainda mais valiosos, pois provavelmente apontam para lacunas de monitoramento claras. Essa investigação deve estabelecer o que aconteceu em detalhes, encontrar todas as causas-raiz do evento e atribuir ações para corrigir o problema ou melhorar a forma como ele será tratado na próxima vez. O Google opera sob uma cultura postmortem livre de culpa, com o objetivo de expor as falhas e aplicar a engenharia para consertá-las, em vez de evitá-las ou minimizá-las.
Buscar velocidade máxima de mudança sem violar o SLO de um serviço
As equipes de desenvolvimento de produtos e SRE podem desfrutar de uma relação de trabalho produtiva, eliminando o conflito estrutural em seus respectivos objetivos. O conflito estrutural é entre o ritmo da inovação e a estabilidade do produto e, conforme descrito anteriormente, esse conflito geralmente é expresso indiretamente. No SRE, trazemos esse conflito à tona e, em seguida, resolvemos com a introdução de um error budget.
O error budget decorre da observação de que 100% é a meta de confiabilidade errada para basicamente tudo (marcapassos e freios antibloqueio são exceções notáveis). Em geral, para qualquer serviço ou sistema de software, 100% não é a meta certa de confiabilidade porque nenhum usuário pode dizer a diferença entre um sistema estar 100% disponível e 99,999% disponível. Existem muitos outros sistemas no caminho entre o usuário e o serviço (seu laptop, seu WiFi doméstico, seu ISP, a rede elétrica …) e esses sistemas coletivamente estão muito menos disponíveis do que 99,999%. Assim, a diferença marginal entre 99,999% e 100% se perde no ruído de outras indisponibilidades, e o usuário não recebe nenhum benefício do enorme esforço necessário para adicionar aquele último 0,001% de disponibilidade.
Se 100% é a meta de confiabilidade errada para um sistema, qual é, então, a meta de confiabilidade certa para o sistema? Na verdade, não se trata de uma questão técnica – é uma questão de produto, que deve levar em consideração as seguintes considerações:
- Com que nível de disponibilidade os usuários ficarão satisfeitos, considerando a forma como usam o produto?
- Quais alternativas estão disponíveis para usuários insatisfeitos com a disponibilidade do produto?
- O que acontece com o uso do produto pelos usuários em diferentes níveis de disponibilidade?
O negócio ou o produto deve estabelecer a meta de disponibilidade do sistema. Depois que essa meta é estabelecida, o error budget é um menos a meta de disponibilidade. Um serviço que está 99,99% disponível está 0,01% indisponível. Essa indisponibilidade permitida de 0,01% é o error budget do serviço. Podemos gastar o orçamento em qualquer coisa que quisermos, desde que não o gastemos demais.
Então, como queremos gastar o error budget? A equipe de desenvolvimento deseja lançar recursos e atrair novos usuários. Idealmente, gastaríamos todo o nosso error budget assumindo riscos com coisas que lançamos para lançá-las rapidamente. Esta premissa básica descreve todo o modelo de error budget. Assim que as atividades de SRE são conceituadas nesta estrutura, liberar o error budget por meio de táticas como implementações em fases e experimentos de 1% pode otimizar para inicializações mais rápidas.
O uso de um orçamento incorreto resolve o conflito estrutural de incentivos entre o desenvolvimento e o SRE. O objetivo do SRE não é mais “zero interrupções”; em vez disso, os SREs e os desenvolvedores de produtos pretendem gastar o error budget para obter a velocidade máxima do recurso. Essa mudança faz toda a diferença. Uma interrupção não é mais uma coisa “ruim” – é uma parte esperada do processo de inovação e uma ocorrência que as equipes de desenvolvimento e SRE gerenciam em vez de temer.
Monitoramento
O monitoramento é um dos principais meios pelos quais os proprietários de serviço controlam a integridade e a disponibilidade de um sistema. Como tal, a estratégia de monitoramento deve ser construída cuidadosamente. Uma abordagem clássica e comum de monitoramento é observar um valor ou condição específica e, em seguida, acionar um alerta por e-mail quando esse valor for excedido ou quando essa condição ocorrer. No entanto, esse tipo de alerta por e-mail não é uma solução eficaz: um sistema que exige que uma pessoa leia um e-mail e decida se algum tipo de ação precisa ser executada em resposta é fundamentalmente falho. O monitoramento nunca deve exigir que um humano interprete qualquer parte do domínio de alerta. Em vez disso, o software deve fazer a interpretação e os humanos devem ser notificados apenas quando precisarem agir.
Existem três tipos de saída de monitoramento válida:
Alertas
Significa que um ser humano precisa agir imediatamente em resposta a algo que está acontecendo ou prestes a acontecer, a fim de melhorar a situação.
Tickets
Significa que um humano precisa agir, mas não imediatamente. O sistema não pode lidar automaticamente com a situação, mas se um humano agir em alguns dias, nenhum dano ocorrerá.
Logs
Ninguém precisa olhar essas informações, mas elas são registradas para fins de diagnóstico ou forense. A expectativa é de que ninguém leia os logs, a menos que outra coisa os solicite a fazer isso.
Resposta a Emergências
A confiabilidade é uma função do tempo médio de falha (MTTF) e do tempo médio de reparo (MTTR). A métrica mais relevante na avaliação da eficácia da resposta a emergências é a rapidez com que a equipe de resposta pode trazer o sistema de volta à integridade, ou seja, o MTTR.
Humanos adicionam latência. Mesmo que um determinado sistema experimente mais falhas reais, um sistema que pode evitar emergências que requerem intervenção humana terá maior disponibilidade do que um sistema que requer intervenção prática. Quando os humanos são necessários, descobrimos que pensar e registrar as melhores práticas com antecedência em um “playbook” produz aproximadamente uma melhoria de 3x no MTTR em comparação com a estratégia de “improvisar”. O engenheiro de plantão herói faz-tudo funciona, mas o engenheiro de plantão experiente armado com um manual funciona muito melhor. Embora nenhum manual, por mais abrangente que seja, seja um substituto para engenheiros inteligentes capazes de pensar em tempo real, dicas e etapas de solução de problemas claras e completas são valiosas ao responder a uma página de alto risco ou que exige tempo. Assim, o Google SRE conta com manuais de plantão, além de exercícios como a “Roda do infortúnio”, para preparar os engenheiros para reagir a eventos de plantão.
Gestão de Mudanças
O SRE descobriu que cerca de 70% das interrupções são devido a mudanças em um sistema ativo. As melhores práticas neste domínio usam automação para realizar o seguinte:
- Implementando lançamentos progressivos
- Detectando problemas com rapidez e precisão
- Reverter alterações com segurança quando surgirem problemas
Este trio de práticas minimiza efetivamente o número agregado de usuários e operações expostos a mudanças ruins. Ao remover humanos do loop, essas práticas evitam os problemas normais de fadiga, familiaridade/desprezo e desatenção a tarefas altamente repetitivas. Como resultado, a velocidade de liberação e a segurança aumentam.
Predição de Demanda e Planejamento de Capacidade
A previsão de demanda e o planejamento de capacidade podem ser vistos como garantia de que haja capacidade e redundância suficientes para atender à demanda futura projetada com a disponibilidade necessária. Não há nada de especial sobre esses conceitos, exceto que um número surpreendente de serviços e equipes não tomam as medidas necessárias para garantir que a capacidade necessária esteja disponível no momento em que for necessária. O planejamento da capacidade deve levar em consideração tanto o crescimento orgânico (que decorre da adoção e uso de produtos naturais pelos clientes) quanto o crescimento inorgânico (que resulta de eventos como lançamentos de recursos, campanhas de marketing ou outras mudanças direcionadas aos negócios).
Várias etapas são obrigatórias no planejamento de capacidade:
- Uma previsão de demanda orgânica precisa, que se estende além do tempo de espera necessário para adquirir capacidade
- Uma incorporação precisa de fontes de demanda inorgânicas na previsão de demanda
- Teste de carga regular do sistema para correlacionar a capacidade bruta (servidores, discos e assim por diante) à capacidade de serviço
Como a capacidade é crítica para a disponibilidade, segue-se naturalmente que a equipe de SRE deve ser responsável pelo planejamento da capacidade, o que significa que eles também devem ser responsáveis pelo provisionamento.
Provisionamento
O provisionamento combina gerenciamento de mudanças e planejamento de capacidade. Em nossa experiência, o provisionamento deve ser conduzido rapidamente e somente quando necessário, pois a capacidade é cara. Este exercício também deve ser feito corretamente ou a capacidade não funcionará quando necessário. Adicionar nova capacidade frequentemente envolve girar uma nova instância ou local, fazer modificações significativas nos sistemas existentes (arquivos de configuração, balanceadores de carga, rede) e validar se a nova capacidade funciona e entrega resultados corretos. Portanto, é uma operação mais arriscada do que o deslocamento de carga, que geralmente é feito várias vezes por hora e deve ser tratada com um grau correspondente de cuidado extra.
Eficiência e Desempenho
O uso eficiente de recursos é importante sempre que um serviço se preocupa com dinheiro. Como o SRE em última instância controla o provisionamento, ele também deve estar envolvido em qualquer trabalho de utilização, já que a utilização é uma função de como um determinado serviço funciona e como é provisionado. Segue-se que prestar muita atenção à estratégia de provisionamento para um serviço e, portanto, sua utilização, fornece uma alavanca muito, muito grande sobre os custos totais do serviço.
O uso de recursos é uma função da demanda (carga), capacidade e eficiência do software. Os SREs prevêem a demanda, a capacidade de provisionamento e podem modificar o software. Esses três fatores são uma grande parte (embora não a totalidade) da eficiência de um serviço.
Os sistemas de software tornam-se mais lentos à medida que a carga é adicionada a eles. Uma desaceleração em um serviço equivale a uma perda de capacidade. Em algum ponto, um sistema de desaceleração para de servir, o que corresponde a uma lentidão infinita. Provisão de SREs para atender a uma meta de capacidade em uma velocidade de resposta específica e, portanto, estão profundamente interessados no desempenho de um serviço. Os SREs e os desenvolvedores de produtos irão (e devem) monitorar e modificar um serviço para melhorar seu desempenho, adicionando capacidade e melhorando a eficiência.
O fim do começo
A Engenharia de Confiabilidade representa uma ruptura significativa com as práticas recomendadas da indústria existentes para o gerenciamento de serviços grandes e complicados. Motivado originalmente pela familiaridade – “como engenheiro de software, é assim que eu gostaria de investir meu tempo para realizar um conjunto de tarefas repetitivas” – tornou-se muito mais: um conjunto de princípios, um conjunto de práticas, um conjunto de incentivos , e um campo de atuação dentro da disciplina maior de engenharia de software. O resto do livro explora o modo SRE em detalhe