SRE – práticas

A maior parte do tempo de vida de um software se dá após subida em produção, quando entra em uso, e não no design ou desenvolvimento. Então, por que insistimos que os engenheiros de software devam se concentrar principalmente nas fases de design e implementação dos sistemas?

Por isso o Google desenvolveu o termo SRE Site Reliability Engineering. É um time dedicado composto por engenheiros de software que operam os produtos e criam sistemas para realizar o trabalho que seria realizado por adminstradores de sistemas geralmente de forma manual.

Agora vamos as Práticas do SRE:

• abraçar o risco;
• ter objetivos do nível de serviço;
• eliminar trabalho desnecessário;
• monitorar sistemas distribuídos;
• automatizar processos;
• ter engenharia de lançamentos;
• buscar a simplicidade.

Abraçar o risco:

Na maioria das vezes os softwares não precisam ser totalmente perfeitos, a menos que seja algum software para aviação ou médico. Os softwares podem tolerar falhas dado um determinado nível de risco estabelecido.

Ter objetivos do nível de serviço:

Os objetivos de nível de serviço (Service Level Objectives) estabelecem indicadores do que o seu software precisa cumprir para estar dentro do nível de risco. Esses SLO (Service Level Objectives) podem ser acompanhados diariamente ou semanalmente. 

Se esse indicador estiver indo bem, o time pode continuar mudando as funcionalidades e construindo novas. Por outro lado se o time está adicionando novas features e o time de SRE percebe que quanto mais eles adicionam, mais o SLO vai chegando perto do máximo que poderia ser, identifica-se o momento de parar o desenvolvimento, e requisitar que o time resolva débitos técnicos ou bugs e não deixar que mandem features novas enquanto não resolverem a estabilidade do sistema.

Eliminar trabalho desnecessário:

Significa eliminar aquele serviço manual, repetitivo, e facilmente que pode ser automatizado. A ideia é sempre que possível ir diminuindo o problema.

Monitorar sistemas distribuídos;

Sobre o monitoramento é importante ter um membro da equipe dedicado para acompanhar métricas, lembrando sempre de manter simples e que realmente importam para a perenidade da operação.

Automatizar processos:

Esse é um dos princípios mais importante do SRE que suscita uma questão polêmica: Vale a pena automatizar um processo que hoje é executado manualmente e tem custo muito baixo? Na visão do SRE, sempre vale a pena!

• Quando você automatiza desacopla da pessoa que tem conhecimento dessa tarefa, qualquer um vai poder executar dali pra frente.
• Automatizar um processo, faz com que ele fique registrado no código. Muitas vezes procedimentos manuais estão em arquivos de texto, e que não tem gestão de configuração adequada e podem levar a um erro de execução (por exemplo, executar um procedimento antigo). Quando o processo está em código, ele faz parte do sistema e pode ser analisado, otimizado e garantindo que temos a última versão válida.
• Automatizar uma tarefa manual é bom, mas ter um sistema autônomo é melhor ainda. Um sistema que já saiba o que ele tem que fazer sem intervenção nenhuma e sempre de alguém escrever uma ferramenta para controlá-lo.

Ter engenharia de lançamentos:

No livro, é citado que no Google existem times responsáveis por fazer ferramentas de build e release, e os times de desenvolvimento em vez de se preocupar em como eles irão enviar o software, eles só se preocupam escrever software usando as ferramentas e os padrões do time de release, e só decidem a freqüência com que irão enviar alterações.

Buscar a simplicidade:

No SRE, é estimulado a simplicidade do código e manter o ambiente “clean”. Ou seja, sempre você não pode medo de remover código não necessário para a aplicação. Ao em vez de comentar código, ou fazer uma uma flag é indicado que esse código seja removido e caso necessário, recuperar o código através da ferramenta de gestão de controle de versão.

Conclusão:

A equipe de Site Reliability Engineering trabalha olhando para o sistema e corrigindo as falhas, além de, automatizar para ser possível prever indisponibilidade do sistema antes de chegar ao cliente final. Agora o desenvolvedor que esta trabalhando em novos produtos não precisa parar a tarefa para corrigir bugs no produto em execução.

Fonte: Livro Engenharia de Confiabilidade do Google e https://gerencianet.com.br/blog/site-reliability-engineering-sre-qual-a-funcao-em-uma-empresa/ e https://medium.com/@fabio.delgado2/sre-bf4ca0cdb82c