Engenharia de Confiabilidade do Site: Livro Google SRE

Quem se interessa por Site Reliability Engineering certamente já ouviu falar do “livro do Google”, ou Google SRE. Disponível sob a licença Creative Commons, o “Google SRE Bookconta a jornada da gigante da tecnologia que, desde 2004, trata operações (Ops) como um problema de software. E busca soluções inovadoras para seus inúmeros serviços públicos através da chamada “Engenharia de Confiabilidade” com um olhar especial para 4 princípios fundamentais: Capacidade, Desempenho, Disponibilidade e Latência.
Este é o primeiro de uma série de posts em que iremos abordar em detalhes cada capítulo do livro.

História de sucesso

Todos conhecemos a história de sucesso do Google. Lançado em meados de 1998 no Vale do Silício como um simples buscador, o Google foi uma das primeiras empresas a definir o que significa, na prática, o alinhamento entre negócios e TI. Em pouco tempo, passou a difundir o conceito de DevOps a uma comunidade de desenvolvedores mais ampla e diversificada, resultando no conglomerado que conhecemos hoje – forte e poderoso tanto em tecnologia como nos negócios. Talvez por essa razão o livro seja tão valioso de conhecimento agregado em SRE, mas também por ter sido escrito com a colaboração de um amplo grupo de especialistas que tornaram toda a mágica possível, ao longo de mais de duas décadas de uma jornada fascinante. 

O Google cresceu em uma época em que a função do administrador de sistema (vulgo sysadmin) estava sendo profundamente transformada. Havia um certo questionamento da função no ar, algo como não ser mais possível se dar ao luxo de manter a tradição do papel dos sysadmin como autoridade. E havia também uma certa urgência em “pensar o novo” x “pensar diferente” onde o tempo era escasso demais para esperar que todos estivessem na mesma sintonia.

Na introdução de Principles of Network and System Administration, lançado nos anos 2000, Mark Burgess afirmava que a Administração de Sistemas era uma espécie de “engenharia humano-computador”. Algo que foi fortemente rejeitado por alguns especialistas da área, que na época afirmavam: “ainda não estamos no estágio em que podemos chamar isso de engenharia“.

Burgess conta que se sentiu um tanto decepcionado, imaginando que área havia se perdido, presa em sua própria cultura, e sem conseguir vislumbrar uma direção a seguir. Foi então que o Google em cena no Vale do Silício norte-americano, ainda nos seus primórdios, forjando um novo caminho a seguir. A função, revisada, foi chamada de SRE, ou “Site Reliability Engineer”. Alguns dos amigos de Burgess estavam entre os primeiros da “nova geração” de engenheiros – que “formalizaram” a função a partir do uso de software e automação combinados. Inicialmente, eles pareciam extremamente secretos; com o tempo, no entanto, e com tantos produtos ao gosto do público na indústria da tecnologia, informações e métodos passaram a fluir em ambas as direções. É o que iremos abordar neste série de posts sobre Google SRE.

Como nascem os produtos

A engenharia de software tem algo em comum com ter filhos: o trabalho antes do parto é doloroso e difícil, mas é só depois do parto que se investe a maior parte do tempo e esforços. No entanto, a Engenharia de Software, como uma disciplina, passa muito mais tempo falando sobre o primeiro trabalho em oposição ao segundo. E isso, apesar das estimativas apontarem que entre 40%-90% dos custos totais de um sistema são aferidos após o seu nascimento. (O próprio fato de haver uma variação tão grande nessas estimativas diz algo sobre a engenharia de software como disciplina).

O modelo popular da indústria que concebe a implantação do software operacional sendo “estabilizado” na produção e, portanto, necessitando de muito menos atenção por parte dos engenheiros de software, está errado. Através dessa lente, podemos observar que, se a engenharia de software tende a se concentrar em projetar e construir sistemas de software, deve haver outra disciplina que cuide de todo o ciclo de vida dos objetos de software, desde o início, passando pela implantação, operação e refinamento, até uma eventual e pacífica desativação. Essa disciplina usa – e precisa usar – um amplo leque de habilidades, mas contempla interesses distintos de outros tipos de engenheiros. Hoje, essa resposta é a disciplina que o Google chama de “Engenharia de Confiabilidade do Site”.

Definição(s) de SREs

E o que vem a ser exatamente o Site Reliability Engineering (SRE), do termo original em inglês? Bem, já começa que não é um nome particularmente claro para o que fazem os “engenheiros de confiabilidade de sites”. Os engenheiros do próprio Google são questionados sobre o que exatamente vem a ser o SRE, ou ainda o que fazem diariamente.

SREs são, antes de tudo, Engenheiros. Profissionais de diferentes áreas da TI que aplicam os princípios da ciência da computação e da engenharia ao desenvolvimento de sistemas. Em geral, são grandes sistemas distribuídos. Por vezes, o desafio é escrever o software para esses grandes sistemas para que funcionem juntamente com as outras partes de desenvolvimento do produto. Em outras ocasiões, porém, a tarefa passa a ser construir todas as peças adicionais de que esses sistemas precisam, como backups ou balanceamento de carga, para que possam ser reutilizadas em todos os sistemas. De maneira geral, pode-se dizer que a tarefa dos SREs é descobrir como aplicar soluções existentes a novos problemas.

Em seguida, temos a questão fundamental da confiabilidade do sistema. Ben Treynor Sloss, VP de Engenharia do Google , foi quem criou o termo SRE. Ben afirma que a Confiabilidade é o recurso mais essencial de qualquer Produto. Afinal, um sistema não é muito útil se ninguém puder usá-lo, não é mesmo? Para o propósito destes posts (e do livro SRE do Google), a confiabilidade vem a ser “a probabilidade de que [um sistema] execute uma função exigida, sem falha, nas condições estabelecidas por um determinado período de tempo”. Assim como os sistemas de software com os quais estamos preocupados aqui são, em grande parte, sites e serviços semelhantes; não estamos discutimos as preocupações de confiabilidade enfrentadas por softwares destinados a usinas nucleares, aeronaves, equipamentos médicos ou outros sistemas críticos em termos de segurança.

Como a confiabilidade é algo tão crucial, os SREs se concentram em encontrar maneiras de melhorar o projeto e a operação dos sistemas para torná-los mais escaláveis, confiáveis e eficientes. No entanto, eles despendem esforços nessa direção apenas até certo ponto: quando os sistemas são “confiáveis o suficiente“, eles investem seus esforços na adição de recursos ou na construção de novos produtos.

Finalmente, os SREs concentram seus esforços em operar Serviços construídos sobre sistemas de computação distribuídos, sejam esses serviços de armazenamento em escala planetária (tendo um amplo escalonamento em mente, por exemplo), distribuição de e-mail para centenas de milhões de usuários ou, onde o próprio Google começou, oferecer pesquisa na web  partir de uma base gigantesca. O “Site” do SRE originalmente se referia à função do SRE em manter o ‘google.com’ funcionando a todo vapor, como um mecanismo de busca. Agora, pouco mais de 20 anos depois, o Google executa muito mais serviços, e muitos deles não são mais sites. É o caso do Bigtable, de gerenciamento de infraestrutura interna, e do Google Cloud Platform, de produtos para desenvolvedores externos.

Embora a SRE seja representada como uma disciplina ampla, não é nenhuma surpresa que tenha surgido no mundo em rápida evolução dos serviços web e, talvez, também na origem, deva algo às peculiaridades da infraestrutura do Google. Também não é surpresa constatar que, de todas as características pós-deploy para devotar atenção especial, a Confiabilidade é como principal. Nesse sentido, a SRE difere do termo DevOps porque, embora o Google considere a infraestrutura como código, o foco principal é a confiabilidade – além do fato da empresa estar fortemente orientada a eliminar a necessidade do Ops.

Apesar de ter surgido no Google, e se expandido na comunidade da web em geral, a disciplina tem lições aplicáveis a outras comunidades e outras organizações. O livro Google SRE é uma tentativa de explicar como são feitas as coisas: tanto para que outras organizações possam fazer uso do que o próprio Google aprendeu e aplica na prática, como para que seja possível definir melhor o papel e o que o termo SRE significa.

Em última análise, software e engenharia de sistemas mais orientados à Confiabilidade são inerentemente bons. Mesmo no caso de organizações menores, quanto mais cedo houver uma preocupação com a Confiabilidade, melhor. Senão, vejamos: embora uma pequena organização tenha muitas preocupações urgentes e as escolhas de software que faz possam ser diferentes das que o Google fez, ainda assim vale a pena colocar um suporte de Confiabilidade leve no local desde o início, porque é menos caro expandir uma estrutura mais tarde do que apresentar uma que simplesmente não está presente.


E quem pode ter sido o primeiro SRE?

O primeiro SRE foi, na verdade, uma mulher. Acredita-se que Margaret Hamilton, que trabalhou no programa espacial Apollo pelo MIT, tenha todos os traços significativos que compõe o perfil do primeiro SRE da história. Em suas próprias palavras, “parte da cultura era aprender de tudo e de todos, inclusive de o que menos se esperaria“. Além de sua grandiosa história, a ela também é creditada boa parte dos esforços de se popularizar o termo “engenharia de software”.

Um dia, sua filha Lauren veio trabalhar com ela, enquanto alguns membros da equipe estavam ocupados executando cenários de missões no computador de simulação híbrida. Como era de se esperar, Lauren foi mexer onde não devia e causou um crash em uma “missão” ao selecionar as chaves DSKY de forma inesperada. O alerta levou a equipe a se dar conta do que aconteceria se o programa de pré-lançamento, P01, fosse inadvertidamente acionado por um astronauta real durante uma missão real, e com a missão em curso. (Lançar P01 inadvertidamente em uma missão real seria um grande problema, porque eliminaria os dados de navegação e o computador não estava equipado para pilotar a nave sem os dados de navegação). oh-oh. “Houston, we have a problem!

Mas não. Com os instintos de um SRE, Margaret simplesmente enviou uma solicitação de alteração no programa para adicionar um código de verificação de erro especial no software de vôo a bordo, caso um astronauta, por acidente, selecionasse P01 durante o vôo. Mas esse movimento foi considerado desnecessário pelos “chefões” da NASA: “claro que isso nunca iria acontecer!” Portanto, em vez de adicionar um código de verificação de erro, Margaret atualizou a documentação de especificações da missão para dizer o equivalente a “Não selecione P01 durante o vôo.” (Aparentemente, a atualização foi divertida para muitos no projeto, que ouviram muitas vezes que os astronautas não cometeriam erros – afinal, eles foram treinados para serem perfeitos.)

Bem, a proteção sugerida por Margaret só foi considerada desnecessária até a missão seguinte, a memorável Apollo 8, poucos dias após a atualização das especificações. Durante o curso do quarto dia de vôo com os astronautas Jim Lovell, William Anders e Frank Borman a bordo, Jim Lovell selecionou P01 por engano – por acaso, bem no dia de Natal – criando, é claro, um completo caos para todos os envolvidos. Esse era um problema crítico porque, na ausência de uma solução alternativa, nenhum dado de navegação significava que os astronautas nunca voltariam para casa. Felizmente, a atualização da documentação feita por Margaret revelou explicitamente essa possibilidade e foi inestimável para descobrir como fazer upload de dados utilizáveis e recuperar a missão, sem muito tempo a perder.

Como disse Margaret, “um entendimento completo de como operar os sistemas não foi suficiente para evitar erros humanos“. E assim, a solicitação inicial de alteração para adicionar software de detecção e recuperação de erros ao programa de pré-lançamento P01 foi aprovada logo em seguida.

Embora o incidente da Apollo 8 tenha ocorrido décadas atrás, há muito nos parágrafos anteriores que acaba sendo diretamente relevante para a vida dos engenheiros hoje em dia, e muito que continuará a ser diretamente relevante no futuro. Assim, para os sistemas que você cuida, para os grupos em que trabalha ou para as organizações que está construindo, tenha em mente o “jeito SRE de pensar”: rigor e dedicação, crença no valor da preparação e da documentação e uma consciência de tudo o que poderia dar errado, juntamente com um forte desejo de evitá-lo. Bem-vindo à nova profissão do futuro!

Mark Burgess, que escreveu o prefácio do livro, é também autor de Search of Certainty.

Links

Follow Us

Email: contact@elven.works

en_US