A engenharia de confiabilidade de sites (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ência, que podem, de outra forma, ser executadas manualmente pelos administradores do sistema (sysadmins). 

O princípio por trás da 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 intervenção manual, especialmente à medida que esses sistemas se estendem ou migram para a cloud.

A SRE também pode reduzir ou remover grande parte da dificuldade natural entre equipes de desenvolvimento que desejam liberar continuamente software novo ou atualizado para produção, e equipes de operações que não desejam liberar qualquer tipo de software novo ou atualizado sem ter certeza de que ele não irá causar interrupções ou outros problemas de operações. Como resultado, embora não seja estritamente necessário para o DevOps, a SRE se alinha estreitamente com os princípios de DevOps e pode desempenhar um papel importante  no sucesso do DevOps.

O conceito da SRE é creditado a Ben Treynor Sloss, VP of Engineering do Google, que, notoriamente, escreveu que "a SRE é o que acontece quando você pede a um engenheiro de software para projetar uma equipe de operações".

Um engenheiro de confiabilidade do site é um desenvolvedor de software com experiência em operações de TI, sendo alguém que sabe como codificar e que também entende como "manter as luzes acesas" em um ambiente de TI de grande escala. 

Os engenheiros de confiabilidade do site passam mais do que metade de seu tempo executando operações de TI manuais e tarefas de administração do sistema, como analisando logs, ajustando desempenho, aplicando correções, testando ambientes de produção, respondendo a incidentes, conduzindo postmortems (autópsias), e passam o resto do seu tempo desenvolvendo código que automatiza essas tarefas. O objetivo deles é passar muito menos tempo no primeiro e muito mais tempo no último ao longo do tempo.

Em um nível mais elevado, a equipe de SRE atua como uma ponte entre as equipes de desenvolvimento e as equipes de operações, possibilitando que a equipe de desenvolvimento traga novo software ou novos recursos para produção o mais rapidamente possível, ao mesmo tempo que também garantindo um nível aceitável de desempenho de operações de TI e risco de erro acordado, em linha com os acordos de nível de serviço (SLAs) que a organização possui junto a seus clientes. Com base em sua experiência e riqueza de dados de operações, a equipe de SRE ajuda o desenvolvimento e as equipes de operações estabelecem

• 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 de medir os indicadores de nível de serviço
  
  
• Orçamentos de erro: a quantidade máxima de tempo que um sistema pode falhar ou ter um desempenho abaixo do esperado sem violar os termos contratuais do SLA. Mais do que uma métrica, o orçamento de erro é a ferramenta que a equipe de engenharia de confiabilidade do site utiliza para reconciliar 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 utiliza para reconciliar automaticamente a confiabilidade do serviço de uma empresa com o 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 de erro mensal, ou seja, a quantidade total de tempo de inatividade permissível sem consequência contratual para qualquer mês, é cerca de 4 minutos e 23 segundos.

Agora, digamos que a equipe de desenvolvimento deseja apresentar alguns novos recursos ou melhorias no sistema. Se o sistema estiver funcionando sob o orçamento de erro, a equipe pode entregar os novos recursos. Caso contrário, a equipe não poderá entregar os novo recursos até que ela trabalhe com a equipe de operações para diminuir esses erros ou indisponibilidades a um nível aceitável.

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

• Melhorar a estabilidade e o desempenho dos serviços
  
  
• Tomar decisões acionadas por dados sobre a implementação de novos recursos ou aplicativos
  
  
• Maximizar a inovação correndo riscos dentro de limites aceitáveis

O DevOps é uma maneira moderna de entregar aplicativos de maior qualidade mais rapidamente, automatizando o ciclo de vida da entrega de software e dando às equipes de desenvolvimento e de operações mais responsabilidade compartilhada e mais contribuição no trabalho de cada uma. 

Assim como a SRE, o DevOps torna os negócios mais ágeis ao equilibrar a necessidade de entregar mais aplicativos e mudanças mais rapidamente com a necessidade de evitar "quebrar" o ambiente de produção. E como a SRE, o DevOps visa alcançar esse equilíbrio ao estabelecer um risco aceitável de erros. De fato, a SRE e o DevOps são tão semelhantes que alguns especialistas dizem que são a mesma coisa, mas a maioria considera as práticas da SRE como excelentes maneiras de implementar os princípios de DevOps. Por exemplo:

Princípios de DevOps: reduzir silos organizacionais, utilizar conjunto de ferramentas e automação

Prática de SRE: usar o mesmo conjunto de ferramentas para automatizar e melhorar operações que os desenvolvedores usam desenvolver e melhorar software

Princípios de DevOps: aceitar falha como normal e implementar mudanças graduais

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

Princípio de DevOps: medir tudo

Prática de SRE: basear decisões para liberar novo software nas métricas do  SLA

Para saber mais sobre DevOps, assista a este vídeo (5:58):

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

• Obtenha maior visibilidade sobre o funcionamento dos serviços ao monitorar métricas, logs e rastreios em todos os serviços da organização, e ao fornecer contexto para identificar as causas raízes no evento de um incidente.
  
  
• Quantifique o custo do tempo de inatividade  ao ajudar as equipes de desenvolvimento e de operações a entender o custo das violações de SLA, e ao ajudar a gestão 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  ao desenvolver um processo eficiente de plantão e aperfeiçoando os fluxos de trabalho de alertas.
  
  
• Desenvolva um centro moderno de operações de rede  ao combinar o entendimento profundo das operações de TI com machine learning e automação, para enviar alertas diretamente para a pessoa responsável pelo problema.

A migração da TI tradicional e de data centers no local para ambientes da cloud híbrida é uma das principais razões pelas quais a empresa média gera duas a três vezes mais dados de operações a cada ano. Cada vez mais, a SRE é vista como essencial para promover estes dados para automatizar a administração de sistemas, as operações e a resposta a incidentes, assim como para melhorar a confiabilidade corporativa mesmo à medida que o ambiente de TI se torna mais complexo.

Uma abordagem de desenvolvimento nativa de cloud, especialmente, desenvolvendo aplicativos 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 de cloud 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 de cloud e garantir ou melhorar a confiabilidade do sistema, sem colocar pressão adicional de operações nas equipes de DevOps.