Princípios da SRE: As 7 Regras Fundamentais

Em um de nossos artigos anteriores,discutimos o que é um SRE, o que eles fazem e algumas das responsabilidades comuns que uma SRE típica pode ter, como apoiar operações, lidar com multas de problemas e resposta a incidentes, e monitoramento geral do sistema e observabilidade. Neste artigo, vamos dar um mergulho mais profundo nos vários princípios e diretrizes da SRE que um engenheiro de confiabilidade do site pratica em seu papel. Como o DevOps, esses princípios SRE servem como um guia para impulsionar o alinhamento no que se refere ao alinhamento, reunião e apoio aos objetivos da organização.

O Google foi a primeira empresa a criar, abraçar e colocar suporte por trás do papel de engenharia de confiabilidade do site. Desde então, o papel da SRE evoluiu à medida que a indústria mudou e passou das estruturas monolíticas tradicionais para grandes redes e microsserviços amplamente distribuídos. No entanto, uma coisa permaneceu em grande parte a mesma coisa – os princípios pelos quais as SREs aderem. Esses princípios principais do SRE estão focados em uma coisa: sistema de condução e confiabilidade do serviço. Vamos dar um mergulho mais profundo nesses princípios centrais da SRE.

 

Princípios SRE

 

Abraçando e gerenciando riscos

Abraçar o risco é o primeiro dos princípios da SRE, e por uma boa razão. Para melhorar a confiabilidade de um sistema, é importante medir o impacto das falhas “e se”. Entende-se que nenhum sistema é 100% confiável. Em algum momento, algo vai dar errado. Infelizmente, o usuário ou cliente cotidiano não sabe, ou se importa, ser tão compreensivo. E há um custo inerente associado à garantia da confiabilidade. Se isso significa que é um custo financeiro, custo de tempo ou simplesmente a confiança de um cliente em seus serviços.

Uma responsabilidade dos SREs é se inclinar para o fracasso e o risco, a fim de aprender como eles podem, em última análise, tornar seus serviços e sistemas mais resilientes. No entanto, há tradeoffs que precisam ser considerados. Por exemplo, garantir a máxima confiabilidade pode vir ao custo de ser capaz de implantar mais rapidamente serviços futuros. Ou talvez melhorias adicionais não signifiquem necessariamente um ganho substancial de receita? O objetivo é fazer um sistema confiável, mas não mais do que precisa ser, pois o custo e o tempo associados a fazer isso superam os benefícios potenciais.

 

Objetivos de nível de serviço

O princípio de abraçar o risco está intimamente ligado a objetos de nível de serviço, ou SLOs. Para ir um pouco mais fundo, os SLOs são o conjunto formalizado de objetivos dentro de um contrato de nível de serviço (SLA) que são medidos contra indicadores de nível de serviço, ou SLIs. SLIs são as métricas reais de desempenho de seus serviços. Por exemplo, se o seu SLO afirma que seu tempo de atividade deve ser de 99,9%, o SLI real deve atender ou exceder essa métrica de desempenho para atender a esse SLO específico. Os SLIs são os indicadores que um SRE monitoraria continuamente, de modo que, se ele estiver fora desse limite, as equipes são alertadas e o problema pode ser resolvido rapidamente. Os SLIs estão realmente ligados ao usuário para determinar o que é mais importante para sua experiência no que se refere ao serviço.

 

SLAs vs. SLOs vs. SLIs

  • SLAs. Acordos feitos com seus clientes ou clientes que definem o nível de serviço que será entregue.
  • SLOs. Um acordo dentro do SLA que estabelece métrica específica, como tempo de atividade, tempo de resposta, segurança, resolução de problemas, etc.
  • SLIs. O desempenho real, ou medições, de seus SLOs que determinam o nível de conformidade.

 

Os SLOs utilizados para medir o desempenho real em relação ao SLA, que são os acordos entre um prestador de serviços e o cliente. Mais uma vez, tudo isso remonta à ideia de que é preciso haver um acordo ou compreensão sobre quanto risco, ou tolerância, pode ser permitido para um determinado serviço.

Leia: Saiba mais sobre como gerenciar a conformidade com sla dentro de sua organização.

 

Eliminar o labuta

O trabalho, como é definido com o escopo da função SRE, é a quantidade de trabalho manual que é necessária para garantir que os serviços estejam em execução. Um dos principais objetivos de um SRE é automatizar o máximo de trabalho possível. Isso permite que os SREs abram mais tempo para tarefas mais importantes. E quando você pensa sobre isso, reduzir a labuta deve realmente ser uma parte do trabalho de qualquer um. Quanto menos tempo necessário em tarefas redundantes é garantir melhor produtividade a longo prazo. Sempre que um engenheiro de confiabilidade do local deve se envolver em atividades manuais repetitivas, no que diz respeito à gestão do serviço de produção, isso pode ser descrito como labuta.

Em muitos casos, pode haver ocasiões em que um SRE tem que realizar atividades manuais e demoradas, mas nem todas devem ser definidas como labuta. No entanto, é fundamental definir quais atividades dentro da equipe SRE estão consumindo mais tempo. A partir daí, identifique onde podem ser feitas melhorias para reduzir a quantidade de trabalho para um melhor equilíbrio no trabalho. Quando o Google introduziu pela primeira vez o papel do SRE, eles estabeleceram uma meta de que metade de um tempo de SREs deve ser focado em reduzir o trabalho operacional futuro ou adicionar recursos de serviço. O desenvolvimento de novos recursos se correlaciona com a melhoria de métricas como confiabilidade e desempenho, o que acaba por reduzir o potencial de labuta para baixo da linha.

 

monitorização

No Dotcom-Monitor, trata-se de monitorar soluções para rastrear tempo de atividade, disponibilidade, funcionalidade e desempenho total de servidores, sites, serviços e aplicativos. O monitoramento é um dos princípios mais importantes da SRE dentro do papel. O monitoramento contínuo garante que os serviços estejam funcionando conforme o planejado e pode ajudar a identificar os problemas de momento surgidos para que possam ser corrigidos imediatamente. Como mencionamos na seção anterior, atender a esses SLOs são fundamentais para os SLAs de negócios definidos e, finalmente, os usuários. O monitoramento pode fornecer às SREs e equipes uma tendência histórica de desempenho e pode oferecer insights sobre o que é um problema pontual versus um problema mais amplo e sistêmico. Conforme definido pela iniciativa Google SRE, os quatro sinais dourados de monitoramento incluem as seguintes métricas:

 

  • Latência. Latência é a quantidade de tempo, ou atraso, que um serviço leva para responder a uma solicitação. Claramente, tempos de resposta lentos afetarão a experiência percebida do usuário. O monitoramento pode fornecer uma maneira de diferenciar entre
  • Trânsito. O tráfego refere-se à quantidade de demanda do usuário, ou carga, está no sistema. Isso pode ser medido por solicitações HTTP por segundo ou dependendo do serviço real
  • Erros. Os erros referem-se à taxa em que as solicitações do serviço falham. No entanto, é importante que as equipes da SRE diferenciem entre falhas difíceis, como 500 erros de servidor e falhas suaves, como uma resposta de 200 OK que foi cronometrada porque um limite de desempenho específico foi definido. É importante considerar como monitorar adequadamente esses diferentes cenários como esses.
  • Saturação. Saturação é sobre medir quanto recursos do sistema um determinado serviço tem. Até certo ponto, a maioria dos serviços experimentará degradação de desempenho. Entender onde isso ocorre pode ajudar a definir corretamente objetivos e metas de monitoramento, para que ações corretivas possam ser realizadas.

 

Automação

Automatizar, automatizar, automatizar. Abordamos esse princípio anteriormente quando discutimos a redução da labuta, mas ele não pode ser subestimado. A natureza do papel da SRE é tão diversificada quanto um papel pode ser. A fim de reduzir o potencial de intervenção manual em todas as facetas de suas responsabilidades, automatizar tarefas é a chave para um negócio de sucesso. À medida que os serviços se dimensionam e se tornam mais distribuídos, torna-se muito mais difícil gerenciar. Automatizar tarefas repetitivas em todo o quadro, seja testando, implantação de software, resposta a incidentes ou simplesmente comunicação entre equipes, automatizar fornece benefícios imediatos, eficiências e, o mais importante, consistência. Desde que o papel da SRE foi concebido, houve uma mudança na forma como as equipes de desenvolvimento, QA e Operações colaboram. Para apoiar esses novos ambientes e práticas DevOps, várias plataformas e ferramentas foram desenvolvidas.

Leia: Top 13 Ferramentas de confiabilidade do site (SRE).

 

Engenharia de Lançamento

Liberar engenharia. Parece um assunto complexo, mas na realidade, é apenas uma maneira simples de definir como o software é construído e entregue. Embora a engenharia de lançamento em si seja seu próprio título e papel, dentro do conceito de SRE, isso significa fornecer serviços que sejam estáveis, consistentes e, claro, repetíveis. Isso remonta à seção anterior sobre automação. Se você vai fazer alguma coisa, faça direito e seja capaz de repetir isso novamente, de forma consistente, conforme necessário. Construir um monte de serviços pontuais é demorado e cria labuta imperdoável.

Se voltarmos à história da posição SRE no Google, eles tinham engenheiros de lançamento dedicados que trabalhavam diretamente com SREs. Os engenheiros de versão são normalmente encarregados de definir as melhores práticas no que se refere ao desenvolvimento de serviços de software, implantação de atualizações, testes contínuos e abordagem de problemas de software, além de muitas outras responsabilidades. Esse papel se torna mais crítico quando você pensa em como dimensionar serviços e implantá-los rapidamente. Ter um conjunto de melhores práticas e ferramentas (e aplicá-las) é essencial para poder atender a essas demandas e dar tranquilidade às equipes da SRE uma vez que a construção é colocada em produção.

 

Simplicidade

Com uma posição que aparentemente não tem fim para o número de responsabilidades e expectativas como o papel SRE tem, o último princípio, ironicamente, é a simplicidade. Talvez mais fácil de dizer do que na prática, este princípio se concentra na ideia de desenvolver um sistema ou serviço que seja tão complexo quanto necessário. Embora isso possa parecer contra-intuitivo no início, ele realmente se resume a querer um sistema confiável, consistente e previsível. Isso pode parecer chato, mas para um SRE, esse é um dos objetivos finais finais.

Os SREs se esforçam por um sistema ou serviço que não seja complexo ou difícil de gerenciar. SrEs querem um que simplesmente faça o trabalho que foi projetado para fazer. No entanto, do ponto de vista de um usuário, um serviço que fornece uma série de recursos também pode fornecer uma série de benefícios, mas para um SRE, isso significa apenas mais dores de cabeça potenciais. No entanto, a mudança é sempre inevitável se você quiser adicionar novos recursos a um serviço web, faça-o cuidadosamente. Mudanças menores e incrementais são mais fáceis (e mais simples) de gerenciar do que construir e enviar um monte de recursos ao mesmo tempo. Os SREs também precisam considerar as necessidades e metas do negócio.

 

Princípios da SRE: As 7 Regras Fundamentais – Pensamentos Finais

O papel da SRE se concentra na construção, entrega e manutenção de sistemas e serviços confiáveis em escala. Esses sete princípios fundamentais de ajuda definem as práticas para SREs que ajudam a impulsionar o alinhamento dentro das práticas de DevOps e apoiam os objetivos do negócio. É um papel complexo que busca equilibrar a confiabilidade com lançamentos de recursos, mantendo níveis excepcionais de qualidade.

A plataforma Dotcom-Monitor fornece aos SREs todos os recursos de monitoramento necessários para garantir a continuidade de seus serviços. Desde alertas e relatórios configuráveis até painéis e relatórios em tempo real, a plataforma fornece as ferramentas essenciais necessárias para gerenciar o desempenho de todos os seus serviços a longo prazo. Por exemplo, crie scripts de aplicativos da Web com base no comportamento do usuário, ações e caminhos e configure tarefas de monitoramento sintético para garantir uma experiência consistente ao longo do tempo. Não importa o nível de monitoramento que sua equipe precisa, há uma solução para atender às suas necessidades.

Comece gratuitamente com o Teste de 30 dias do Dotcom-Monitor ou agende uma demonstração com um de nossos engenheiros de desempenho.

 

Latest Web Performance Articles​

Start Dotcom-Monitor for free today​

No Credit Card Required