De uma forma simplificada, os SREs executam serviços – um conjunto de sistemas relacionados, operados para usuários, que podem ser internos ou externos – e são os responsáveis finais pela saúde desses serviços. A operação bem-sucedida de um serviço envolve uma ampla gama de atividades: desenvolvimento de sistemas de monitoramento, capacidade de planejamento, resposta a incidentes, garantia de que as causas das interrupções sejam tratadas e assim por diante. Esta seção aborda a teoria e a prática da atividade diária de um SRE: construção e operação de grandes sistemas de computação distribuídos.

Podemos caracterizar a saúde de um serviço – da mesma forma que Abraham Maslow categorizou as necessidades humanas em seu livro “A Theory of Human Motivation” – desde os requisitos mais básicos necessários para um sistema funcionar como um serviço até os níveis mais elevados de função – permitindo a atualização e controle ativo da direção do serviço, em vez de combater incêndios de forma reativa. Esse entendimento é tão fundamental para a forma como avaliamos os serviços do Google que não foi explicitamente desenvolvido até que vários SREs do Google, incluindo nosso ex-colega Mikey Dickerson – que deixou o Google no verão de 2014 para tornar-se o primeiro administrador do US Digital Service, agência destinada, em parte, a trazer os princípios e práticas do SRE para os sistemas de TI do governo dos EUA –  juntaram-se temporariamente à cultura radicalmente diferente do governo dos Estados Unidos para ajudar no lançamento de health.gov no final de 2013 e início de 2014: eles precisavam de uma forma maneira de explicar como aumentar a confiabilidade dos sistemas.

Usaremos essa hierarquia, ilustrada na figura abaixo, para examinar os elementos que fazem um serviço confiável, do mais básico ao mais avançado.

Service Reliability Hierarchy.

 

Hierarquia da Confiabilidade de Serviços

Monitoramento

Sem monitoramento, você não tem como saber se o serviço está funcionando; sem uma infraestrutura de monitoramento cuidadosamente projetada, você está voando às cegas. Talvez todos que tentam usar o site recebam um erro, talvez não – mas você deseja estar ciente dos problemas antes que seus usuários os percebam. Discutimos ferramentas e filosofia em alertas práticos de dados de séries temporais.

Resposta a Incidentes

SREs não ficam de plantão apenas por causa disso: em vez disso, o suporte de plantão é uma ferramenta que usamos para cumprir nossa missão maior e permanecer em contato com como os sistemas de computação distribuídos realmente funcionam (e falham!). Se pudéssemos encontrar uma maneira de nos livrar de carregar um pager, nós o faríamos. Em “Estar de plantão” (Capítulo 11), explicamos como equilibramos os deveres de plantão com nossas outras responsabilidades.

Depois de saber que há um problema, como você o elimina? Isso não significa necessariamente consertá-lo de uma vez por todas – talvez você possa parar o sangramento reduzindo a precisão do sistema ou desligando alguns recursos temporariamente, permitindo que ele seja degradado normalmente, ou talvez você possa direcionar o tráfego para outra instância do serviço que está trabalhando corretamente. Os detalhes da solução que você escolhe implementar são necessariamente específicos para seu serviço e sua organização. Responder de forma eficaz a incidentes, no entanto, é algo aplicável a todas as equipes.

Descobrir o que há de errado é o primeiro passo; oferecemos uma abordagem estruturada em “Resolução eficaz de problemas” (Capítulo 12).

Durante um incidente, muitas vezes é tentador ceder à adrenalina e começar a responder ad hoc. Aconselhamos contra essa tentação em “Resposta a Emergências” (Capítulo 13) e em “Gerenciamento de Incidentes” (Capítulo 14), onde explicamos que o gerenciamento eficaz de incidentes deve reduzir seu impacto e limitar a ansiedade induzida por interrupções.

Postmortem e Análise de Causa-Raiz

Pretendemos ser alertados e resolver manualmente apenas os problemas novos e interessantes apresentados pelo nosso serviço; é terrivelmente enfadonho “consertar” o mesmo problema indefinidamente. Na verdade, essa mentalidade é um dos principais diferenciadores entre a filosofia SRE e alguns ambientes mais tradicionais com foco em operações. Este tema é explorado em dois capítulos.

Construir uma cultura de Postmortem sem culpa é o primeiro passo para entender o que deu errado (e o que deu certo!), Conforme descrito em “Cultura Postmortem: Aprendendo com o fracasso” (Capítulo 15).

Relacionado a essa discussão, em “Rastreamento de interrupções” (Capítulo 16), descrevemos resumidamente uma ferramenta interna, o rastreador de interrupção, que permite que as equipes de SRE acompanhem os incidentes de produção recentes, suas causas e as ações tomadas em resposta a eles.

Testes

Depois de entender o que tende a dar errado, nosso próximo passo é tentar evitá-lo, porque um grama de prevenção vale um quilo de cura. Os conjuntos de teste oferecem alguma garantia de que nosso software não está cometendo certas classes de erros antes de ser lançado para produção; falamos sobre a melhor forma de usá-los em “Testes de Confiabilidade” (Capítulo 17).

Planejamento de Capacidade

Em “Engenharia de Software no SRE” (Capítulo 18), oferecemos um estudo de caso de Engenharia de Software no SRE com o Auxon, uma ferramenta para automatizar o planejamento de capacidade.

Seguindo naturalmente o planejamento de capacidade, o balanceamento de carga garante que estamos usando adequadamente a capacidade que construímos. Discutimos como as solicitações para nossos serviços são enviadas para datacenters em “Balanceamento de carga no front-end” (Capítulo 19). Em seguida, continuamos a discussão em “Balanceamento de carga no Datacenter” (Capítulo 20) e em “Manipulação de sobrecarga” (Capítulo 21), que são essenciais para garantir a confiabilidade do serviço.

Finalmente, em “Endereçamento de falhas em cascata” (Capítulo 22), oferecemos conselhos sobre como lidar com falhas em cascata, tanto no projeto do sistema quanto no caso de seu serviço ser pego em uma falha em cascata.

Desenvolvimento

Um dos principais aspectos da abordagem do Google à Engenharia de confiabilidade do site é que fazemos um projeto de sistema em grande escala e um trabalho de engenharia de software significativo dentro da organização.

Em “Gerenciando estado crítico: consenso distribuído para Confiabilidade” (Capítulo 23), explicamos o consenso distribuído, que (disfarçado de Paxos) está no centro de muitos sistemas distribuídos do Google, incluindo nosso sistema Cron distribuído globalmente. Em “Programação Periódica Distribuída com Cron” (Capítulo 24), traçamos um sistema que pode ser escalado para datacenters inteiros e além, o que não é uma tarefa fácil.

Em “Pipelines de processamento de dados” (Capítulo 25), discutimos as várias formas que os pipelines de processamento de dados podem assumir: de trabalhos de MapReduce únicos executados periodicamente a sistemas que operam quase em tempo real. Diferentes arquiteturas podem levar a desafios surpreendentes e contra-intuitivos.

Certificar-se de que os dados armazenados ainda estão lá quando você deseja lê-los é o cerne da integridade dos dados; em Integridade de dados: o que você lê é o que você escreveu, explicamos como manter os dados protegidos.

Produto

Finalmente, tendo subido na pirâmide da confiabilidade, chegamos ao ponto de ter um produto viável. Em “Lançamentos de produtos confiáveis em escala” (Capítulo 27), escrevemos sobre como o Google faz lançamentos de produtos confiáveis em grande escala para tentar oferecer aos usuários a melhor experiência possível a partir do dia zero.

Leitura complementar do Google SRE

Conforme discutido anteriormente, o teste é sutil e sua execução inadequada pode ter grandes efeitos na estabilidade geral. Em um artigo da Association for Computing Machinery (ACM), explicamos como o Google realiza testes de resiliência em toda a corporação para garantir que somos capazes de resistir ao inesperado caso um apocalipse zumbi ou outro desastre aconteça.

Embora muitas vezes seja visto como uma arte negra, cheia de planilhas misteriosas que adivinham o futuro, o planejamento de capacidade é vital e, como mostram David Hixson e Kavita Guliani em “Capacity Planning, você não precisa realmente de uma bola de cristal para fazer isso direito.

Finalmente, uma abordagem nova e interessante para segurança de rede corporativa é detalhada em “BeyondCorp: A New Approach to Enterprise Security“, de Rory Ward e Betsy, uma iniciativa para substituir intranets privilegiadas por dispositivos e credenciais de usuário. Impulsionado por SREs no nível de infraestrutura, esta é definitivamente uma abordagem a se ter em mente ao criar sua próxima rede.

Fonte: 
Google SRE Book

Links

Follow Us

Email: contact@elven.works

en_US