Qual é a diferença entre o tradicional Modelo de Desenvolvimento e Operações e a Engenharia de Confiabilidade do Local?

15

"SRE é o que acontece quando você pede a um engenheiro de software para projetar uma equipe de operações." - Engenharia de confiabilidade do local

Desde o lançamento do Livro de engenharia de confiabilidade do site do Google , em mais de uma ocasião me disseram que o SRE é uma extensão do modelo existente de Suporte a operações ou aplicativos.

Tivemos algumas perguntas que definiram diferenças entre o Sys. Administradores, engenheiros de DevOps e engenheiros de confiabilidade do site:

No entanto, nenhuma dessas perguntas ou suas respostas descrevem as diferenças entre um administrador de sistemas e um engenheiro de confiabilidade do site .

Em termos mais amplos: quais são as principais diferenças entre a prática do Google de Engenharia de Confiabilidade do Site e as funções tradicionais de Desenvolvimento e Operações separadas em uma empresa.

Richard Slater
fonte

Respostas:

7

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 .

Boicote SE para Monica Cellio
fonte
Mais algumas partes interessantes da leitura (com as quais não concordo necessariamente): charity.wtf/2016/06/30/… , charity.wtf/2016/05/31/wtf-is-operations-serverless , susanjfowler. com / blog / 2016/10/13 / os-ops-identidade-crise
Boicote SE para Monica Cellio