Observabilidade e Monitoramento, por que?
Published: 2024-03-12 14:00:00


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kx6jijn535sawyjc9fka.png)



Observabilidade e Monitoramento, o que é ? Imagine que você está dirigindo um carro em uma estrada. O carro representa sua aplicação de software, e o painel de instrumentos é o sistema de observabilidade/monitoramento.

Assim como o painel de um carro exibe informações vitais, como velocidade, rotações por minuto (RPM), temperatura do motor e nível de combustível, o sistema de observabilidade monitora métricas importantes, como tempo de resposta, utilização de recursos (CPU, memória, disco), taxa de erro, entre outros.

Talves você seja o tipo de pessoal que decobre que o carro tava sem oleo quando o motor está fundido, e a mesma pessoal que descobre que aplicação ta com problema por chamados. 

Para não deixa o motor quebrar com você na estrada, leia esse curto texto.

Na era moderna do desenvolvimento de software, a observabilidade tornou-se um aspecto crucial para garantir o desempenho, a confiabilidade e a eficiência das aplicações em produção,

As **métricas** oferecem uma visão quantitativa do desempenho de uma aplicação PHP. Elas podem incluir informações sobre o uso de recursos, tempos de resposta, taxas de erro e muito mais. Implementar a instrumentação adequada em sua aplicação PHP para coletar métricas é crucial para entender e otimizar seu desempenho. Ferramentas como Prometheus são amplamente utilizadas para coletar, armazenar e visualizar métricas em tempo real.

Imagine-se neste cenário: é uma sexta-feira agitada e um analista de monitoramento de sistemas relata um log suspeito no **Datadog**. Suspeita-se que possa ser um testcase não previsto ou um erro no domínio da aplicação. Um dos desenvolvedores rapidamente puxa a demanda e sobe um hotfix para resolver o problema. Este é o cenário ideal, onde a equipe de desenvolvimento tem visão rapida do problema, e consegue ir na veia correta aplicar a medicação.

Agora, vamos considerar o oposto: em vez do analista descobrir o bug no **Datadog**, é um cliente frustrado com o sistema que encontra o problema. O cliente abre um chamado e, na segunda-feira, você se depara com esse problema. Agora, não só você precisa resolver o bug, mas também entender o caminho que o cliente seguiu para encontrá-lo. Essa jornada pode ser simples, mas também pode ser incrivelmente complexa. Até mesmo antes de o desenvolvedor localizar o problema, o cliente já pode ter registrado uma reclamação.

Neste caso, além de resolver o bug, você vai precisa da uma de Sherlock Holmes e investigar a origem do problema. Isso pode envolver até mesmo comunicação direta com o cliente para entender exatamente o que aconteceu. É uma situação desafiadora, pois além de lidar com a questão técnica, é necessário gerenciar as expectativas e a satisfação do cliente.

Em resumo, este cenário destaca a necessidade de uma robusta estratégia de monitoramento e observabilidade para identificar problemas antes que eles afetem os usuários finais. Ao antecipar e abordar esses problemas de forma rápida e eficaz, podemos minimizar o impacto nos clientes e garantir uma experiência positiva com o sistema.

## Ter teste não garante nada

Ter teste é **FUNDAMENTAL ** , uma cobertura de testes por si só não é suficiente se você não consegue registrar e acompanhar os problemas que surgem durante a execução da aplicação. Da mesma forma, apenas registrar os problemas não resolve a situação, a menos que sejam tratados de maneira eficaz.

Não estou dizendo, não tenha testes, e sim que ele por si só não é suficiente.

> "O código que não é testado está quebrado por definição"

Robert C. Martin 

É imporante estabelecer um processo robusto para lidar com problemas detectados na aplicação. Isso inclui a discussão aberta e colaborativa com a equipe para entender a natureza dos problemas e suas possíveis soluções. Além disso, é importante envolver os Product Owners (PO) ou Product Managers (PM) para avaliar o impacto desses problemas e priorizá-los adequadamente em relação ao backlog de desenvolvimento.

Problemas identificados devem ser tratados como débito técnico e incorporados ao planejamento da sprint, garantindo que sejam resolvidos de forma oportuna e eficiente. Ao abordar os problemas de maneira proativa e transparente, a equipe pode manter a qualidade do produto e garantir a satisfação do cliente a longo prazo.