Felizmente, desde que a Engenharia de confiabilidade do site se desenvolveu internamente no Google e apenas recentemente começou a entrar na comunidade em geral, ela é bem definida. O que não é , no entanto, são operações da Web (ou "administração de sistemas" - como exemplo da falta de clareza, você usa os dois na sua pergunta). É difícil discutir as diferenças entre duas coisas quando você não tem certeza do que é uma delas.
Mas sou um sujeito aventureiro, então vou tentar.
Em lojas muito tradicionais, desenvolvedores e administradores de sistemas são muito isolados um do outro. Os desenvolvedores criam um aplicativo e consideram o trabalho concluído assim que o código é confirmado. Os administradores de sistema pegam os artefatos de construção (que podem ser apenas o código, se for uma linguagem interpretada) e os implementam nos servidores de produção. O trabalho dos administradores de sistemas é manter o aplicativo funcionando sem problemas e, em geral, gerenciar o ambiente de produção. No entanto, frequentemente os problemas de desempenho vêm de problemas de arquitetura no aplicativo; os administradores de sistemas não têm o conhecimento de programação para saber o que o aplicativo está fazendo, e os desenvolvedores não sabem como o aplicativo atua na topologia de produção com tráfego de produção; portanto, ninguém está equipado sozinho para resolver o problema.
Além disso, os desenvolvedores geralmente são julgados pela rapidez com que podem produzir novos recursos, enquanto os administradores de sistemas são julgados pela frequência com que o aplicativo é interrompido na produção. Como a mudança é uma das principais causas de quebra, isso coloca os dois departamentos em desacordo entre si - uma antiga rivalidade que prejudica os negócios e as pessoas envolvidas.
Em algum momento, algumas empresas centradas no desenvolvedor ficaram tão irritadas com isso que começaram a praticar "NoOps" - elas eliminaram seus departamentos de operações e os obstáculos percebidos que vieram com elas. Na realidade, isso significava que os desenvolvedores assumiam funções operacionais, mas mantinham seus títulos antigos.
Em uma discussão sobre o NoOps , John Allspaw, vice-presidente de operações técnicas da Etsy e editor do respeitado livro de operações da Web , definiu funções na Etsy da seguinte maneira:
A Etsy Operations é responsável por:
- Respondendo a interrupções, leva de plantão
- Sistemas de alerta de limiar, design
- Projeto e revisão de arquitetura
- Coleta de métricas de construção
- Configuração da aplicação
- Desenvolvimento / gerenciamento de infraestrutura
A Etsy Development é responsável por:
- Respondendo a interrupções, leva de plantão
- Sistemas de alerta de limiar, design
- Projeto e revisão de arquitetura
- Coleta de métricas de construção
- Configuração da aplicação
- Código de envio público
Nenhuma dessas listas é abrangente, tenho certeza de que estou perdendo alguma coisa lá. Enquanto o Etsy Ops fez alterações nos aplicativos voltados para a produção, eles são poucos, mas reais (e às vezes bastante profundos). Enquanto o Etsy Dev faz alterações no Chef, elas são poucas, mas reais. Se há tanta sobreposição de responsabilidades, por que a diferença, você pode perguntar? Experiência e experiência em domínio. Muitos desenvolvedores não têm conhecimento profundo de como o início lento do TCP funciona, mas o Ops funciona. Poucas Ops têm um conhecimento abrangente de algoritmos de classificação ou relevância, mas o Dev possui. A Ops tem anos de experiência em prever o uso de recursos rapidamente com precisão aceitável, o Dev não. O desenvolvedor pode não estar ciente dos prós e contras da distribuição de opções de carga de trabalho em todas as camadas1-7, talvez apenas aos 7 anos, Ops sabe. A modelagem de relacionamento entre entidades pode se tornar natural para um desenvolvedor, mas não para operações. No final, os dois descobrem soluções para várias formas de cenários de falhas bizantinas e padrões de resiliência, em todos os níveis e camadas.
Em seu mundo, desenvolvedores e engenheiros de operações tinham habilidades e responsabilidades de alto nível muito semelhantes; onde eles diferiam era em seus conhecimentos. Suas diferentes especialidades os incentivaram a trabalhar juntos para resolver problemas, e suas habilidades comuns de nível básico deram a eles um idioma para fazer isso.
Geralmente, essa é a definição de operações da Web nas quais aterro na maioria dos casos. Então é com isso que vamos continuar.
Então, o que é a Engenharia de Confiabilidade do Site?
O livro do Google SRE é aberto com uma definição de SRE ... e depois outro ... e depois passa um capítulo continuando a definir a função e um livro inteiro cobrindo os detalhes. Mesmo quando desenvolvido em uma organização, parece difícil condensar o trabalho em uma única definição acordada.
Para começar, precisamos voltar a 2003, quando Ben Traynor ingressou no Google e fundou o que veio a ser a primeira equipe de Engenharia de confiabilidade do site. Lembre-se de que alguns parágrafos atrás estávamos no início de 2010; mas em 2003, o setor ainda estava bastante definido na divisão sysadmin / developer como a maneira natural das coisas. Então, quando Ben diz que o SRE seria o que aconteceria se um engenheiro de software criasse uma equipe de operações, essa era uma fusão muito mais radical dos dois mundos do que parece agora.
A definição dada no prefácio enfatiza cada uma das três palavras individualmente:
- Engenharia - o uso de ciência da computação e conceitos de engenharia para resolver problemas
- Confiabilidade - foco em tornar os sistemas mais escaláveis, mais confiáveis e mais eficientes
- Serviço - a evolução posterior do "site", enfatizando que os SREs são responsáveis pelos serviços em rede
O capítulo de introdução lista os princípios da Engenharia de confiabilidade do site como:
- Garantir um foco duradouro na engenharia - tomar medidas preventivas para evitar páginas frequentes e outras "labutas"
- Perseguir a velocidade máxima de alteração sem violar o SLO de um serviço - um assunto que pode facilmente ter sua própria resposta de várias centenas de palavras, mas resumido em detalhes como ajudando os desenvolvedores a fazer alterações, desde que não causem muitos problemas
- Monitoramento - alertas automáticos quando algo der errado
- Resposta de emergência - consertando coisas quando estão quebradas
- Mudar a gestão
- Planejamento de capacidade
- Provisioning
- Eficiência e desempenho - garantindo que um serviço seja executado no nível esperado - o gargalo prejudica os usuários, mas o excesso de capacidade custa dinheiro
Eu categorizaria a Engenharia de confiabilidade do site como um subconjunto especializado das operações modernas da Web. Uma organização SRE se concentra fortemente na automatização de tudo , em um grau que é apenas rentável em empresas razoavelmente grandes. Idéias como orçamentos de erro só podem funcionar quando seu serviço tiver muitas solicitações; caso contrário, você perde granularidade (para um serviço menor, um erro específico pode afetar de 0 a 20% das solicitações, dependendo do minuto). Áreas relacionadas, como segurança, estão ausentes da definição de SRE porque as empresas grandes o suficiente para ter equipes de SRE verdadeiras têm equipes dedicadas à segurança.
O programa SRE, conforme definido pelo Google, é uma operação da web desenvolvida para as necessidades específicas do Google, e não necessariamente aplicável a outros lugares.
No entanto, a Engenharia de Confiabilidade do Site vem expandindo recentemente o uso mais amplo da indústria. Meu cargo atual é um SRE, embora eu trabalhe em uma empresa muito menor e a descrição do meu trabalho se encaixa muito bem com a definição de Etsy de operações da web de 2012 de John Allspaw. Minha teoria é que estamos progredindo nos títulos como uma abreviação para defender a evolução de um único campo:
- Começamos como administradores de sistemas .
- Então, à medida que os sites se tornaram mais uma "coisa", as ofertas de emprego começaram a se referir aos engenheiros de operações da web para distinguir administradores de sistemas que se especializavam na web daqueles que também cuidavam de TI em escritórios gerais.
- O DevOps deveria separar aqueles que se sentiam à vontade usando a programação para reduzir a carga de trabalho das operações da web.
- Mas, como o DevOps ficou confuso com a falta de uma definição clara , adotamos a Engenharia de Confiabilidade do Site para especificar que estamos procurando pessoas que estejam de plantão para oferecer serviços de produção.
Então, qual é a diferença entre um administrador de sistemas e um SRE? O ano em que eles receberam seu título. Qual é a diferença entre operações tradicionais e engenharia de confiabilidade do site? O SRE é apenas a encarnação atual das operações, usando novas ferramentas (olá, contêineres!) E, à medida que os programas em rede continuam se tornando maiores e mais importantes, um foco maior nas práticas que permitem que um engenheiro faça mais .