Escrito por Benjamin Lutch

Editado por Betsy Beyer

Li este livro com enorme orgulho. Desde o momento em que comecei a trabalhar na Excite no início dos anos 90, onde meu grupo era uma espécie de grupo SRE (Site Reliability Engineering) neandertal chamado “Operações de Software”, passei minha carreira tentando construir sistemas. À luz das minhas experiências ao longo dos anos na indústria de tecnologia, é incrível ver como a ideia de SRE se enraizou no Google e evoluiu tão rapidamente. O SRE cresceu de algumas centenas de engenheiros quando entrei no Google em 2006 para mais de 1.000 pessoas hoje, espalhadas por uma dúzia de locais e executando o que considero a infraestrutura de computação mais interessante do planeta.

Então, o que permitiu à organização SRE do Google evoluir ao longo da última década para manter essa infraestrutura massiva de maneira inteligente, eficiente e escalável? Acredito que a chave para o sucesso avassalador do SRE está na natureza dos princípios pelos quais opera.

As equipes de SRE são construídas para que nossos engenheiros dividam seu tempo entre dois tipos igualmente importantes de trabalho. Os SREs trabalham em turnos de plantão, que envolvem colocar as mãos nos sistemas, observar onde e como esses sistemas falham e entender desafios como a melhor forma de dimensioná-los. Mas também temos tempo para refletir e decidir o que construir para tornar esses sistemas mais fáceis de gerenciar. Em essência, temos o prazer de desempenhar os papéis de piloto e engenheiro/designer. Nossas experiências em operar uma infraestrutura de computação massiva são codificadas em código real e depois empacotadas como um produto discreto.

Essas soluções são então facilmente utilizáveis por outras equipes de SRE e, em última instância, por qualquer pessoa no Google (ou mesmo fora do Google… pense no Google Cloud!) que queira usar ou aprimorar a experiência que acumulamos e os sistemas que construímos.

Ao abordar a construção de uma equipe ou sistema, idealmente sua base deve ser um conjunto de regras ou axiomas que sejam suficientemente gerais para serem imediatamente úteis, mas que permaneçam relevantes no futuro. Muito do que Ben Treynor Sloss delineou na introdução deste livro representa exatamente isso: um conjunto flexível, em grande parte à prova de futuro, de responsabilidades que permanecem pertinentes 10 anos após sua concepção, apesar das mudanças e do crescimento da infraestrutura do Google e da equipe SRE.

À medida que o SRE cresceu, observamos algumas dinâmicas diferentes em jogo. A primeira é a natureza consistente das responsabilidades e preocupações primárias do SRE ao longo do tempo: nossos sistemas podem ser mil vezes maiores ou mais rápidos, mas, em última instância, precisam permanecer confiáveis, flexíveis, fáceis de gerenciar em uma emergência, bem monitorados e planejados em termos de capacidade. Ao mesmo tempo, as atividades típicas realizadas pelos SRE evoluem por necessidade à medida que os serviços do Google e as competências do SRE amadurecem. Por exemplo, o que era inicialmente um objetivo de “criar um painel para 20 máquinas” pode agora ser “automatizar a descoberta, construção de painéis e alertas em uma frota de dezenas de milhares de máquinas”.

Para aqueles que não estiveram nas trincheiras do SRE na última década, uma analogia entre como o SRE pensa em sistemas complexos e como a indústria aeronáutica abordou o voo de aviões é útil para conceituar como o SRE evoluiu e amadureceu ao longo do tempo. Embora os riscos de falha entre as duas indústrias sejam muito diferentes, certas semelhanças fundamentais permanecem verdadeiras.

Imagine que você quisesse voar entre duas cidades há cem anos. Seu avião provavelmente tinha um único motor (dois, se você tivesse sorte), algumas bolsas de carga e um piloto. O piloto também desempenhava o papel de mecânico e, possivelmente, atuava adicionalmente como carregador e descarregador de carga. A cabine tinha espaço para o piloto e, se você tivesse sorte, um co-piloto/navegador. Seu pequeno avião decolaria de uma pista em bom tempo e, se tudo corresse bem, você subiria lentamente pelos céus e eventualmente pousaria em outra cidade, talvez a algumas centenas de milhas de distância. A falha de qualquer sistema do avião era catastrófica, e não era incomum um piloto ter que sair da cabine para fazer reparos em pleno voo! Os sistemas que alimentavam a cabine eram essenciais, simples e frágeis, e provavelmente não eram redundantes.

Avance cem anos até um enorme 747 parado na pista. Centenas de passageiros estão embarcando em ambos os andares, enquanto toneladas de carga são simultaneamente carregadas no porão. O avião está cheio de sistemas confiáveis e redundantes. É um modelo de segurança e confiabilidade; na verdade, você está mais seguro no ar do que no solo em um carro. Seu avião decolará de uma linha pontilhada em uma pista em um continente e pousará facilmente em outra linha pontilhada em outra pista a 6.000 milhas de distância, exatamente no horário – dentro de minutos do horário previsto de chegada. Mas dê uma olhada na cabine e o que você encontra? Apenas dois pilotos novamente!

Como todos os outros elementos da experiência de voo – segurança, capacidade, velocidade e confiabilidade – escalaram tão bem, enquanto ainda há apenas dois pilotos? A resposta a essa pergunta é um ótimo paralelo com a forma como o Google aborda os enormes e fantásticos sistemas complexos que o SRE administra. As interfaces dos sistemas operacionais do avião são bem pensadas e acessíveis o suficiente para que aprender a pilotá-las em condições normais não seja uma tarefa impossível. No entanto, essas interfaces também fornecem flexibilidade suficiente, e as pessoas que as operam são suficientemente treinadas, para que as respostas a emergências sejam robustas e rápidas. A cabine foi projetada por pessoas que entendem sistemas complexos e como apresentá-los aos humanos de maneira consumível e escalável. Os sistemas subjacentes à cabine têm todas as mesmas propriedades discutidas neste livro: disponibilidade, otimização de desempenho, gerenciamento de mudanças, monitoramento e alerta, planejamento de capacidade e resposta a emergências.

Em última análise, o objetivo do SRE é seguir um curso semelhante. Uma equipe de SRE deve ser o mais compacta possível e operar em um alto nível de abstração, contando com muitos sistemas de backup como proteções e APIs bem pensadas para se comunicar com os sistemas. Ao mesmo tempo, a equipe de SRE também deve ter conhecimento abrangente dos sistemas – como eles operam, como falham e como responder às falhas – que vem de operá-los dia após dia.