A engenharia de confiabilidade do site (SRE) usa engenharia de software para automatizar tarefas de operações de TI – por exemplo, gerenciamento de sistema de produção, gerenciamento de mudanças, resposta a incidentes e até mesmo resposta a emergências – que de outra forma seriam executadas manualmente por administradores de sistemas (administradores de sistemas). 

O princípio por trás do SRE é que usar código de software para automatizar a supervisão de grandes sistemas de software é uma estratégia mais escalável e sustentável do que a intervenção manual - especialmente à medida que esses sistemas se estendem ou migram para a nuvem.

O SRE também pode reduzir ou eliminar grande parte do atrito natural entre as equipes de desenvolvimento, que desejam lançar continuamente softwares novos ou atualizados em produção, e as equipes de operações, que não querem lançar nenhum tipo de atualização ou software novo sem ter certeza absoluta de que não causará interrupções ou outros problemas operacionais. Como resultado, embora não seja estritamente necessário para DevOps, o SRE alinha de perto com os princípios do DevOps e pode desempenhar um papel importante no sucesso do DevOps.

O conceito de SRE é creditado a Ben Treynor Sloss, vice-presidente de engenharia do Google, que escreveu que "SRE é o que acontece quando você pede a um engenheiro de software que projete uma equipe de operações."

Um engenheiro de confiabilidade de sites é um desenvolvedor de software com experiência em operações de TI — alguém que sabe programar e que entende como “manter as luzes acesas” em um ambiente de TI de grande escala. 

Os engenheiros de confiabilidade do local gastam metade de seu tempo executando operações manuais de TI e tarefas de administração do sistema — analisando logs, ajuste de desempenho, aplicando patches, testando ambientes de produção, respondendo a incidentes, realizando post-mortems. No resto do tempo, eles desenvolvem código que automatiza essas tarefas. O objetivo deles é passar menos tempo no primeiro e mais tempo no segundo.

Em um nível superior, a equipe de SRE serve como uma ponte entre as equipes de desenvolvimento e as equipes de operações, permitindo que a equipe de desenvolvimento traga novos softwares ou novos recursos para a produção o mais rápido possível. Eles fazem isso ao mesmo tempo em que garantem um nível aceitável acordado de desempenho de operações de TI e risco de erro, de acordo com os acordos de nível de serviço (SLAs) que a organização tem em vigor com seus clientes. Com base em sua experiência e uma riqueza de dados operacionais, a equipe de SRE ajuda as equipes de desenvolvimento e operações a estabelecer

• Indicadores de nível de serviço (SLIs): medições do nível de serviço fornecido pelos sistemas - métricas como disponibilidade (tempo de atividade) ou latência.
  
  
• Objetivos de nível de serviço (SLOs): meios acordados para medir indicadores de nível de serviço.
  
  
• Orçamentos de erro: o período máximo de tempo que um sistema pode falhar ou apresentar desempenho inferior sem violar os termos contratuais do SLA. Mais do que uma métrica, o orçamento de erros é a ferramenta que uma equipe de engenharia de confiabilidade de site usa para conciliar automaticamente o ritmo de inovação de uma empresa com a confiabilidade de seu serviço. 

O orçamento de erro é a ferramenta que uma equipe de SRE usa para reconciliar automaticamente a confiabilidade do serviço de uma empresa com seu ritmo de desenvolvimento e inovação de software. 

Suponha que o SLA de uma empresa prometa 99,99% de tempo de atividade (uma meta de disponibilidade comum) por ano. Isso significa que o orçamento mensal de erros, a quantidade total de tempo de inatividade permitida sem consequência contratual para um determinado mês, é de cerca de 4 minutos e 23 segundos.

Agora, digamos que a equipe de desenvolvimento queira lançar alguns novos recursos ou melhorias no sistema. Se o sistema estiver funcionando abaixo do orçamento de erro, a equipe poderá entregar os novos recursos. Caso contrário, a equipe não poderá entregar os novos recursos até que trabalhe com a equipe de operações para reduzir esses erros ou interrupções a um nível aceitável.

Dessa forma, os orçamentos de erro ajudam as equipes de desenvolvimento e equipes de operações a

• Melhore a estabilidade e o desempenho dos serviços.
  
  
• Tome decisões baseadas em dados sobre a implementação de novos recursos ou aplicativos.
  
  
• Maximize a inovação assumindo riscos dentro de limites aceitáveis.

O DevOps é uma maneira moderna de fornecer aplicativos de maior qualidade com mais rapidez, automatizando o ciclo de vida da entrega de software e dando às equipes de desenvolvimento e operações mais responsabilidade compartilhada e mais informações sobre o trabalho de cada uma. 

Assim como o SRE, o DevOps torna os negócios mais ágeis ao equilibrar a necessidade de entregar mais aplicações e mudanças mais rapidamente com a necessidade de evitar a “quebra” do ambiente de produção. E assim como o SRE, o DevOps visa alcançar esse equilíbrio estabelecendo um risco aceitável de erros. Na verdade, SRE e DevOps parecem tão semelhantes que alguns especialistas dizem que são a mesma coisa, mas a maioria vê as práticas de SRE como excelentes formas de implementar os princípios de DevOps. Por exemplo:

Princípios de DevOps: reduza os silos organizacionais, aproveite as ferramentas e a automação.

Prática de SRE: use as mesmas ferramentas para automatizar e melhorar as operações que os desenvolvedores usam para desenvolver e melhorar o software.

Princípios de DevOps: aceite a falha como normal, implemente mudanças graduais.

Prática de SRE: use orçamentos de erro para implementar continuamente novos recursos e funcionalidades dentro de níveis aceitáveis.

Princípio do DevOps: meça tudo.

Prática de SRE: basear as decisões de liberação de novos softwares em métricas de SLA.

Além de apoiar o sucesso do DevOps, a engenharia de confiabilidade do site pode ajudar uma empresa

• Obtenha maior visibilidade sobre a integridade do serviço rastreando métricas, logs e rastreamentos em todos os serviços da organização e fornecendo contexto para identificar as causas raiz no caso de um incidente.
  
  
• Quantifique o custo do tempo de inatividade ajudando as equipes de desenvolvimento e operações a entender o custo das violações de SLA e ajudando a gerência a quantificar o impacto da confiabilidade do sistema na produção, vendas, marketing, atendimento ao cliente e outras funções de negócios.
  
  
• Otimize a resposta a incidentes criando processos de plantão eficientes e simplificando fluxos de trabalho de alerta.
  
  
• Crie um moderno centro de operações de rede combinando conhecimento profundo das operações de TI com aprendizado de máquina e automação, para enviar alertas diretamente à pessoa responsável por resolver o problema.

A migração de TI tradicional e data centers locais para ambientes de nuvem híbrida é uma das principais razões pelas quais a média das empresas gera duas a três vezes mais dados de operações a cada ano. Cada vez mais, o SRE é visto como fundamental para aproveitar esses dados para automatizar a administração de sistemas, operações e resposta a incidentes, e para melhorar a confiabilidade da empresa, mesmo quando o ambiente de TI se torna mais complexo.

Uma abordagem de desenvolvimento nativa da nuvem, especificamente, criando aplicações como microsserviços e implementando-os em contêineres, pode simplificar o desenvolvimento, a implementação e a escalabilidade de aplicativos. Mas o desenvolvimento nativo em nuvem também cria um ambiente cada vez mais distribuído que complica a administração, as operações e o gerenciamento. Uma equipe de SRE pode suportar o ritmo acelerado da inovação possibilitada por uma abordagem nativa da nuvem e garantir ou melhorar a confiabilidade do sistema, sem colocar mais pressão de operações nas equipes de DevOps.