Disponibilidade de sistemas, alertas e responsabilidade de ação

Quando é que um assunto deve ser tratado como uma urgência? Quando é a hora de trabalhar em melhoria? Monitorar sempre, e o atuar?

Todo sistema em produção deveria ter uma estrutura de medição de disponibilidade. E o primeiro problema começa quando se pensa na medição da disponibilidade.

Esse índice deve ser construído através do acesso na parte relevante de serviços.

O que não fazer? É bastante comum encontrar o teste de disponibilidade de um serviço através de um arquivo html em uma pasta e validar se vem código 200 depois de uma requisição HTTP do tipo GET. 😛

Medir disponibilidade envolve olhar a parte relevante de serviços. Os recursos que fazem este serviço operar.

Queremos ficar a menor quantidade de tempo fora do ar. E quando acontece de violarmos este combinado?

É a hora de garantir que temos espaço para atuar. O que aconteceu que impediu serviços de retornarem mais rapidamente? O incidente que aconteceu pode se tornar um problema? Foi algo pontual?

E quando acontece fora do horário de trabalho da equipe? Quem atua? E chama quem se precisar de ajuda?

Estas combinações são importantes, pois quem está “on call” precisa garantir que possui conectividade e acesso rápido aos equipamentos caso seja necessário entrar em ação.

Você pode ter quantos monitoramentos forem importantes. Agora, é mais importante ainda organizar quais dos itens monitorados precisam gerar alertas caso alcancem um determinado valor.

É ideal que os alertas permitam uma ação de atenção, que dê tempo de ação humana antes da situação sair de controle. E depois uma indicação de problema antes de virar algo crítico, onde normalmente estaremos atuando em modo reação e não prevenção.

Garanta que você tem responsabilidade clara sobre ação em casos de incidentes e principalmente que existe uma estrutura de melhoria contínua disponível para poder fazer um post mortem (blameless) garantindo que sua equipe vai atuar e vai evitar que este incidente aconteça novamente. Agora, caso aconteça de acontecer novamente, pois a resolução completa não era possível, que o impacto seja menor.

— Daniel Wildt

Extra: Fiz uma conversa com Guilherme Lacerda no youtube da Wildtech, chamada: “Voltando para as raízes do Desenvolvimento Ágil“.

Extra 2: Seu time quer ser devops? Conversa disponível no meu youtube.

Extra 3: Olha o material de SRE do Google e o conceito de Error Budget.

Acompanhe minha jornada de conteúdo, participando da comunidade e das entregas no projeto de crowdfunding “A filosofia da tranquilidade”, lá no apoia.se/dwildt.

Publicado por dwildt

Empreendedor / Desenvolvedor de Software / Mentor / Agilista / Escritor.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s

%d bloggers like this: