SRE em contexto

• 10 minutos

Antes de explorarmos algumas práticas associadas à SRE, seria bom pôr em prática algumas das ideias que aprendemos na unidade anterior em contexto. Nesta pequena unidade, aprendemos um pouco da história por trás do SRE e como ele se relaciona com outras práticas de operações com as quais você pode estar familiarizado. Este conhecimento prepara-nos para um maior sucesso mais tarde, porque essas práticas fazem mais sentido no contexto. Além disso, quando seus amigos perguntam "Como SRE é diferente de ..." você tem uma resposta pronta.

Histórico

A história muito resumida da SRE remonta às suas origens no Google em 2003. Ben Treynor, agora Treynor Sloss, assumiu a liderança da "Equipe de Produção" do Google (então apenas sete engenheiros de software). Treynor criou a ideia e a descreveu como "o que acontece quando você pede a um engenheiro de software para projetar uma função de operações". É útil entender essa história porque ajuda a explicar por que a SRE pode parecer muito "engenharia de software" para as pessoas de operações que a conhecem pela primeira vez. Adotou os valores e as ferramentas dessa área, como a importância da codificação e dos sistemas de controlo do código fonte como uma ferramenta fundamental. A implementação inicial e atual da SRE do Google está bem documentada nos dois livros publicados por O’Reilly (veja a unidade Introdução).

À medida que alguns funcionários iam saindo da Google (e que os funcionários da empresa falavam mais sobre as suas práticas publicamente), a SRE começou a propagar-se a mais organizações do setor. Com a propagação da SRE a novas organizações, estas adotaram e adaptaram os princípios e as práticas da SRE à sua cultura local. Este processo de expansão rendeu muitas implementações diferentes de SRE no campo.

DevOps e SRE

A indústria num sentido mais amplo enfrentou os mesmos desafios relativamente ao dimensionamento, velocidade de desenvolvimento versus estabilidade operacional e outros problemas de entrega de software que geraram o movimento de engenharia de fiabilidade de sites (SRE). Os esforços paralelos para resolvê-los fora da Google (e algumas empresas maiores naquela altura) geraram o DevOps.

Para obter muitas informações boas sobre DevOps, consulte o centro de recursos de DevOps.

Como SRE e DevOps diferem é um assunto ainda sob considerável discussão no campo. Existem algumas diferenças com amplo consenso, incluindo:

• SRE é uma disciplina de engenharia que se concentra na confiabilidade. O DevOps é um movimento cultural que surgiu do desejo de quebrar os silos normalmente associados a organizações separadas de Desenvolvimento e Operações.
• Ao contrário do DevOps, SRE pode ser o nome de uma função como em “Eu sou um engenheiro de fiabilidade de site (SRE)”. Ninguém, na realidade, diz que é um “DevOps”.
• O SRE tende a ser mais prescritivo, mas o DevOps intencionalmente não é assim. A adoção quase universal da integração contínua/entrega contínua e os princípios do Agile são os aspetos mais semelhantes.

As duas práticas operacionais, o DevOps e a SRE, partilham um amor mútuo pela monitorização/observabilidade e automatização (talvez por motivos diferentes). Essa confluência é uma das razões pelas quais muitas vezes pode ser mais fácil importar práticas e princípios SRE para uma organização com uma prática de DevOps existente. Esse processo tem de ser feito com cuidado e propósito. Também pode e deve ser implementado gradualmente. Não é preciso fazer uma mudança repentina.

Conclusão

Esta breve unidade procurou facultar algum contexto no quer diz respeito a SRE e DevOps. SRE e DevOps são melhor pensados como escolas adjacentes de pensamento em práticas operacionais.

Agora que analisamos brevemente alguns dos antecedentes por trás do SRE, vamos direto a alguns de seus princípios fundamentais.

Verifique o seu conhecimento