Por onde começar os estudos em Observabilidade?

Você não está só! Este artigo é uma orientação baseada em minha jornada para quem vem começando.

PASSO 1: Observabilidade não começa pela ferramenta

Sim, a meta é quebrar sua expectativa! Apesar de empresas já terem focos definidos, isso vem depois. Na maioria delas a ferramenta com o tempo também muda. Mas como buscar a informação e o que fazer com ela, é o que você precisa consolidar e praticar por ser cultural.

Cultural? (Você deve ter se perguntado) Sim, processos são culturais, regras de segurança e novas aplicações seguindo as regras de negócio. é em cima disso que o Devops, SRE, Dev, suporte atuam com observabilidade e se criam os meios de coletar, autenticar, liberar e correlacionar.

Outro ponto que você deve saber(!), apesar de observabilidade possuir cargos de analista e afins. É uma especialidade pertencente a todos os cargos e deve ser uma responsabilidade compartilhada. A diferença é o referencial que cada um vai ter dentro do seu quadrado. Otimização de código? Disponibilidade? Qualidade de implantações? Controle e segurança?

SRE e DevOps lideram mais a complexidade quando se tornam especialistas porque eles direcionam a comunicação assim como a maioria das soluções construindo automações e melhorias na infraestrutura com um olhar macro.

Mas, é uma cultura crescente de todos os cargos pois todos precisam falar a mesma lingua para evoluir os processos (ou pelo menos deveriam).

Ferramentas ≠ observabilidade

Tenho alguns artigos aqui eu aprofundam essa diferença, principalemnte relacionada ao negócio.

PASSO 2: O erro clássico: começar coletando tudo

Sugestão? Você precisa entender a cultura e moldar a observabilidade ás necessidades fazendo alguns levantamentos iniciais pra abrir as suas possibilidades de atuação.

1. O que significa “funcionar bem” ou o que é “crítico” nesse sistema?

Liste os pontos que precisam ou não tem visibilidade, partindo desse ponto focal você conseguirá entender e puxar o restante da cadeia envolvida.

2. Como o problema aparece para quem usa?

Nem todo erro vira exceção ou tela vermelha.

3. Quem precisa agir quando algo dá errado?

  • É o desenvolvedor?

  • É o time de infraestrutura?

  • É o suporte?

  • É alguém do negócio?

Uma ordem saudável para quem está começando:

  1. Fundamentos e Telemetria (A Base): Quais formas de monitorar itens ou melhor método? Legado ou atual?

  2. Entender como sistemas funcionam: Entender as funcionalidades para analisar qual o melhor método de coleta

  3. Aprender a pensar em falhas e comportamento: quais alertas criar, quem deve receber, se estão gerando MTTR. Levantar SLIs, SLOs e SLAs.

  4. Estudar métricas, logs e traces conceitualmente: Como dar contexto nas instrumentações, PII, filtrar logs, criar pipelines, mascarar dados sensíveis, estratégias de autenticação e fazer uma coleta limpa.

  5. Só então escolher ferramentas para praticar: Qual ferramenta resolveria maior parte das suas necessidades e o custo disso?

Quando você chegar na ferramenta, ela vai fazer sentido.

PASSO 3: Referências que te ajudarão a apronfundar a cultura:

  1. “Observability Engineering” (Charity Majors, Liz Fong-Jones e George Miranda): É o livro mais atual e definitivo sobre o tema. Foca muito em cultura e em como lidar com sistemas complexos.

  2. “Site Reliability Engineering (SRE)” (Google): Onde os “Golden Signals” foram popularizados. Essencial para entender a parte operacional.

  3. “Distributed Systems Observability” (Cindy Sridharan): Um guia excelente (e curto) sobre como os três pilares se conectam na prática.

PASSO 4: E assim vem aí os 5 mandamentos da Observabilidade (hahaha)

  1. Não adorarás apenas os dashboards: Um gráfico bonito sem uma ação clara é apenas arte. Observabilidade deve gerar resposta.

  2. Instrumentarás desde o dia zero: A observabilidade não é um “puxadinho” para colocar depois que o código está pronto; ela nasce com o código.

  3. Honrarás a cardinalidade: Não adicione labels infinitos às suas métricas, ou a conta da nuvem será seu maior pesadelo.

  4. Não matarás a equipe com alertas inúteis: Se um alerta dispara e ninguém precisa acordar para resolver, ele deveria ser apenas um log.

  5. A observabilidade é para todos: Do desenvolvedor ao PO, todos devem conseguir ler e entender a saúde do produto.