Importante: o texto a seguir é fruto de um exercício de criação de um time de SRE, onde os times de desenvolvedores seriam os responsáveis por criar e manter a infraestrutura e aplicações.
Não existe um modelo certo ou errado, nem considere esse texto como uma verdade absoluta.
Boa parte desse material foi baseado nos livros: The Site Reliability Workbook e Site Reliability Engineering. Você poderá encontrar frases ou partes do livros, nesse texto e nos outros.
Nos posts anteriores abordei um pouco sobre os:
- Compromissos de um SRE com um grupo de trabalho
- Modelos de engajamentos de um SRE com um grupo de trabalho
- Confiabilidade: um dos recursos mais importantes de um sistema
Nesse post vamos ver como as contribuições de uma equipe de SRE, podem acontecer em várias fases do ciclo de vida de um serviço.
Fase 1: Arquitetura e Design
Como o SRE pode influenciar a arquitetura e o design de um sistema:
- Criação de práticas recomendadas, como resiliência a vários pontos únicos de falha
- Documentar prós e contras de um determinado sistema/infra, para que os desenvolvedores possam escolher com sabedoria
- Apoio a discussões para escolha de arquiteturas e design ajuda na validação de suposições e PoC
- Atuar junto com a equipe de desenvolvimento, participando do trabalho de desenvolvimento
- Co-projetando parte do serviço
O envolvimento precoce do SRE pode ajudar a evitar reformulações dispendiosas.
Fase 2: Desenvolvimento Ativo
Nessa fase começa a produtização do serviço, para que possa ser liberado para produção. A produtização normalmente inclui:
- Planejamento de capacidade
- Configuração de recursos extras para redundância
- Implementação de infraestrutura extra
- Planejamento para picos e sobrecargas
- Implementação de monitoramentos e alertas
Fase 3: Disponibilidade limitada
Nessa fase o SRE pode ajudar a:
- Medir e avaliar a confiabilidade.
- Dimensionar o sistema criando um modelo de capacidade
- Garantir uma cobertura de monitoramento adequada
- Ajudar a criar alertas que correspondam idealmente aos próximos SLOs de serviço.
Recomendável que sejam definidos os SLOs nesse ponto, para que se tenha uma medida objetiva de quão confiável é o serviço.
A equipe de produto ainda tem a opção de retirar um produto que não pode atingir sua confiabilidade alvo.
Fase 4: Disponibilidade geral
Nessa fase o serviço já passou pelo PRR (Revisão de Prontidão da Produção) ou deverá passar.
Os objetivos da PRR são os seguintes:
- Verifica se um serviço atende aos padrões aceitos de configuração de produção e prontidão operacional
- Melhorar a confiabilidade do serviço de forma que minimize o número e a gravidade dos incidentes que podem ser esperados
A equipe de desenvolvedores deve continuar colocando em campo uma pequena parte de todo o trabalho operacional e de resposta a incidentes para que eles não percam a perspectiva sobre esses aspectos do serviço.
Fase 5: Fim de suporte
Não há mais usuários e o serviço foi desligado. O SRE pode ajudar a excluir referências ao serviço nas configurações de produção e na documentação, caso exista algum bloqueio.
Top comments (0)