Princípios da jornada de SRE

O que faz um SRE? 

E, de uma forma bem alto nível são somente dois: Medir e Garantir. E para isso existe uma série de princípios que devem ser compreendidos. Além de auxiliar no ciclo de vida do produto.

Principios para SRE

    * Aceitando os riscos

    * Níveis de serviço (SLx)

    * Eliminando Toil

    * Monitoração

    * Automação

    * Engenharia de Release

    * Simplicidade

    * Design de Sistema (Grandes) Não Abstrato (NALSD)

Aceitando os riscos

Aceitar o risco significa estabelecer um nível aceitável de confiabilidade, que pese os custos do que está sendo assumido em relação ao risco. E para aceitar o risco a filosofia de usar error budget precisa estar bem establecida para que funcione.

Níveis de serviço (SLx)

Coração da engenharia de confiabilidade, os SLOs, SLIs e SLAs e Error Budgets. o SLA, a promessa feita para o cliente, é o mínimo disposto em contrato, os SLOs são os objetivos que você quer atingir além desse contrato, e os SLI são os indicadores que você vai utilizar pra acompanhar como estão o andamento desses objetivos.

Eliminando Toil

Reduzir as tarefas repetitivas para gastar energia em coisas urgentes com automação e um meta importante para o SRE. Simplesmente se estamos querendo reduzir nosso TOIL precisamos automatizar coisas, mas com o devido planejamento porque algo automatizado erradamente gera ainda mais pŕobelamas. O objetivo de qualificar algo como TOIL justamente indica para onde o esforço com automação deve ir, ou seja, problemas no fluxo de valor não devem ser, a priori, qualificados como TOIL.

Monitoração

que seu serviço produz as métricas de que você precisa. Alguns padores como 4 golden signals, RED E LEV podem fornecer o template inicial para algumas métricas.

Automação

Automatize tudo que possa ser automatizado, mas certifique-se de garantir, como qualquer outro código, a qualidade/confiabilidade por meio de testes.

Engenharia de Release

Tenha padrões de lançamento. Monitore as estatísticas sobre seus lançamentos. Entenda bem como continuous integration (CI), continuous delivery(CD) e continuous deployment (CD) funcionam de verdade.

Simplicidade

Sistemas simples tendem a ser confiáveis ​​e fáceis de operar, porem, medir a complexidade dos sistemas não será uma tarefa fácil. Saber com quanto tempo alguém leva para fazer mudanças, ou o tempo que alguém leva pra ter uma visão abrangente de alto nível do serviço pode ajudar.

Design de Sistema (Grandes) Não Abstrato (NALSD)

to de manutenção dos sistemas que projetam. Pratique a capacidade de aferir, projetar e avaliar (grandes) sistemas, não deixe nada "abstrato" antes de implementar algo. Deixar de construir um plano de falha para alguma ponta solta pode custar caro, isso não significa implementar, mas sim que evite ser pego de surpresa se algo falhar. Na fase de concepção use perguntas como:

• É possível?
• Isso é viável?
• É resiliente?
• Podemos fazer melhor?

Desta forma estaremos mais perto de construir sistemas saudáveis e duradouros.