DEV Community: rafaelbonilha

Conhecendo o LLM Claude

rafaelbonilha — Mon, 16 Mar 2026 18:21:38 +0000

Um dos principais modelos de LLM (Linguagem de Grande Escala), o Claude foi desenvolvido pela Anthropic seguindo princípios de ética e segurança em IA. Apoiada por diversos nomes de destaque da TI como o Google, ele possui diversos recursos semelhantes a outras ferramentas como o Gemini e o ChatGPT.

Seu foco é em segurança em AI e desempenho, sendo que a atual versão, a Claude 3.5 se saí melhor que o ChatGPT-4 e o Gemini nos testes de desempenho. Fornecendo recursos como colaboração com usuários, o Claude inicialmente foi liberado como uma ferramenta Alpha para um número limitado de usuários selecionados em 2023.

Em julho do mesmo ano a ferramenta foi lançada publicamente já como Claude 2. Em março de 2024 foi lançado o Claude 3 com correções em relação a versão anterior, permitindo que tivesse desempenho superior ao Claude 2 e a versão 4 do ChatGPT.

Características

O Claude possui diversos recursos, sendo destacados os seguintes.:

Capacidade de geração.: É possível editar, resumir e delinear conteúdos com o Claude, além de ele ser capaz de escrever código de programação usando diversas linguagens ( importante revisar após a escrita).
Análise de Imagens.: Ao submeter imagens, o Claude pode descrever o conteúdo das imagens, além de interpretar para transcrição de notas ou extrair informações de imagens.

Conclusões

Claude possui diversos recursos e tem obtido bons desempenhos nos testes, mas por outro lado é uma ferramenta de IA nova no mercado, onde não possui tanta robutez e recursos para atender uma gama grande de tópicos em comparação com seus rivais mais velhos com o Copilot, ChatGPT e Gemini.
Claude LLM apresenta perspectivas promissoras para o futuro na área de pesquisa e desenvolvimento de IA. À medida que a tecnologia de IA avança, Claude pode ser ainda mais refinado e aprimorado para oferecer respostas ainda mais poderosas e precisas.

Referências.:

https://textcortex.com/pt/post/how-to-use-claude-3
https://aipure.ai/br/articles/how-to-use-claude-ai-unlock-advanced-ai-capabilities
https://support.claude.com/pt/

Os 4 Sinais Dourados da Google

rafaelbonilha — Mon, 16 Feb 2026 15:58:05 +0000

Neste artigo iremos abordar um dos maiores marcos para consolidar o SRE que são os 4 sinais dourados do Google, resultado da experiência em manter e escalar um dos ambientes mais desafiadores do mundo.
Estes sinais fornecem insumos para monitoramento que se tornaram padrão na indústria e é amplamente estudado e utilizado para mensurar métricas de ambientes desafiadores em TI.

Surgido da necessidade prática de monitorar vários serviços diferentes executando em escala global, o time de SRE do Google identificou que não importasse a complexidade do sistema, havia 4 métricas fundamentais
que se monitoradas de forma adequada, forneciam uma visão do status do sistema do ponto de vista do usuário.

Isso é absurdamente simples e poderoso.: focando em apenas 4 métricas que são importantes para o usuário, o time garante que está concentrado no que importa e diminui a complexidade, evitando gastar tempo e recursos com o monitoramento de várias métricas de forma desordenada ou sem uma estratégia definida.

Resumindo da seguinte forma a abordagem dos 4 Goldens Signals.: se você só pode monitorar algumas métricas do sistema, concentre-se nas 4 voltadas ao usuário. Garantindo assim que o time está verificando aquilo que realmente impacta o usuário.

Os 4 Sinais Dourados (Golden Signals)

Vamos agora abordar de forma mais detalhada os 4 Golden Signals para poder dessa forma ter o entendimento do porque essas métricas são importantes para a saúde do sistema.

1. Latência.:
A latência mede o tempo que o sistema leva para atender um pedido/requisição e é a métrica mais facilmente notada pelos usuários. Mas para poder ter uma monitoração eficaz, é necessário entender
os detalhes que podem ser ignorados, gerando uma métrica imcompleta em uma abordagem simples.
Um exemplo.: deve-se verificar a diferença entre latência de requisições bem-sucedidas e a latência de requisições que falharam. Isto deve ser considerado pois podem ocorrer casos onde falhas são enviadas rapidamente como um erro http 500 de resposta de um servidor quase que imediatamente.
Se você usar apenas a média de latência de todas as requisições, problemas de latência em solicitações bem-sucedidas podem ficar ocultas ou mascaradas.

Lembrando que o tempo deve ser sempre considerado pois o usuário ficará mais incomodado com a demora em receber uma mensagem de erro do que receber a mensagem de erro imediatamente após fazer a solicitação.
Usar percentis de 95 ou 99 da latência normalmente fornecem uma visão mais realista da experiência que a maioria dos usuários está tendo.

2. Tráfego.:
O tráfego é uma métrica que mede quanta demanda está sendo suportada pelo sistema e normalmente
é medida em dados específicos de cada sistema, por exemplo em um sistema web, usa-se solicitações http por segundo, divididas por seu tipo. Monitorar o tráfego pode trazer informações importantes sobre possíveis problemas que estão começando, como ataques DDoS ou uma instabilidade pode indicar um problema de upstream, impedindo os usuários de usarem o serviço.
O segredo aqui para medir de forma eficaz o tráfego do seu sistema é escolher a métrica que melhor representa a carga que os usuários estão colocando sobre o sistema.

3. Erros.:
Erros é comumente uma das métricas mais importantes e medidas, mas normalmente a métrica de erro se baseia na quantidade de requisições que falham. Mas o ponto de atenção aqui é justamente o que é a
definição de falha aplicada no sistema que está sendo monitorado. Vamos entender melhor isso.: falha pode ser tanto algo facilmente percebível como um erro http 502 ou algo mais sutil, como uma resposta http 200
mas com o conteúdo errado ou mesmo uma falha definida por base em políticas de desempenho como um erro http 429 de rate limit, onde excedeu o limite de conexões acordado.

Erros explícitos, como código de status http são mais fáceis de mensurar por fornecerem informações claras do que está acontecendo de errado. Erros implícitos requerem mais cuidado por serem mais difíceis de detectar, tornando a experiência de uso do usuário ruim. Um caso comum de erro implícito é o serviço retornar um código http 200 mas com dados corrompidos ou faltando, gerando a necessidade de investigar de forma mais detalhada.

Erros definidos com base em políticas são reflexos do que foi acordado via SLA ou outros tipos de acordos, por exemplo, se foi definido um tempo x de resposta para uma solicitação e o sistem leva mais do que esse tempo para responder, mesmo sendo uma resposta bem-sucedida, é considerado um erro por não estar cumprindo o tempo determinado pelo acordo/requisito.

4. Saturação.:
A saturação é a métrica que verifica o quanto o sistema está carregado, detalhando os recursos mais utilizados, é a métrica mais complexa de ser implementada por que necessita de um entendimento profundo
dos ofensores do sistema. Em muitos sistemas, a performance começa a cair antes de atingir o 100% de uso de um determinado recurso. Por exemplo, um servidor pode começar a apresentar lentidão com o consumo de 75% da memória, muito antes de atingir os 100%. Então ter alvos de utilização definidos de forma apropriada é de suma importância para uma correta definição da métrica de saturação.

Sistemas complexos a saturação deve vir acompanhada de métricas de carga de nível superior, onde perguntas sobre níveis de sobrecarga que o sistema pode suportar antes de começar a perder performance ajudam a
fornecer insumos sobre o quanto o sistema aguenta picos de utilização.
Adicionar previsões de saturação é uma forma de monitorar de maneira proativa o sistema, garantindo aos times tempo para tomar ações para mitigar problemas antes que eles comecem de fato. Um exemplo.: métricas de alerta de consumo de espaço em disco ajudam a tomar medidas preventivas antes que os discos fiquem de fato cheios.

Considerações e Limitações dos 4 Golden Signals

Os 4 sinais dourados (Golden Signals) são um excelente ponto de partida para construir uma base sólida e confiável de observabilidade de um sistema com sua simplicidade, foco no usuário e que são úteis para a grande maioria dos sistemas. Isso permite que sejam implementados por times com diversos níveis de experiência em monitoramento.
Contudo, os 4 Golden Signals tem seus limites, por ter o foco no usuário, eles podem não ser adequados para sistemas de infraestrutura ou de processamento em lotes (batch).
Também é altamente recomendável que sejam usados com métricas mais específicas e detalhadas para os sistemas, especialmente os complexos.
Tenha em mente que eles são o início, não devendo ser considerados como as únicas métricas que devem ser implementadas e monitoradas.
Os 4 Sinais Dourados tem também sua importância na consolidação da disciplina de SRE dentro das empresas pelo seu impacto na Observabilidade e Monitoramento.

Referências.:

https://www.thetrueengineer.com/p/the-four-golden-signals-what-google
https://www.solarwinds.com/sre-best-practices/golden-signals
https://sre.google/sre-book/introduction/
https://www.opservices.com.br/4-sinais-de-ouro-do-sre/
https://github.com/cirolini/prometheus-curso-monitoring/blob/main/09_conclusion/01_modelos_de_monitoracao.md
E-book Ós Métodos Red, Use e os 4 Golden Signals para Observabilidade - Jeferson Fernando - LinuxTips

ActivityPub: Protocolo para Redes Descentralizadas

rafaelbonilha — Sat, 17 Jan 2026 20:14:02 +0000

Para começar o ano, vamos falar sobre um importante protocolo utilizado em redes descentralizadas, o ActivityPub.
Ele é um componente importante do chamado Fediverso, conjunto de recursos 'federados' (descentralizados) para compartilhar informações e recursos entre os usuários.

O ActivityPub é um protocolo criado em 2018 pelo World Wide Web Consortium (W3C), consórcio internacional responsável pelos padrões de criação e interpretação de interfaces na internet.
Isso foi feito para permitir a comunicação entre as redes sociais abertas e descentralizadas sem que uma grande empresa controle o sistema de forma centralizada e única.

Do que é feito o ActivityPub?
O ActivityPub possui dois componentes: Caixa de Entrada e Caixa de Saída, que são endpoints de API que podem ser acessados usando o protocolo HTTP/HTTPS.

Para garantir a privacidade, a localização de ambas as caixas só podem ser recuperadas através do uso do protocolo WebFinger. E para testar os recursos do ActivityPub, basta usar a ferramenta ActivityPub Explorer.

Aplicações para o ActivityPub
Apesar de ser usado em redes sociais, o ActivityPub tem compatibilidade com diversas aplicações que usam seu protocolo, como por exemplo plataformas de gerenciamento de conteúdo, assim como também ferramentas de colaboração como ferramentas de desenvolvimento colaborativo de software.

Considerações

O ActivityPub é um protocolo que já tem mais de 20 milhões de usuários e todo o suporte do W3C, trazendo respaldo para o seu contínuo desenvolvimento. Apesar de ainda possuir problemas técnicos e de design, seu nível de maturidade e desenvolvimento faz com que os problemas existentes sejam possíveis de contornar e com amplo apoio da comunidade.

Além disso, o ActivityPub possui uma moderação consolidada e funcional, problema comum em outros protocolos utilizados em redes descentralizadas.
Várias redes usam o ActivityPub como o Mastodon, o Organica entre outros, mas o mais importante é o fato do ActivityPub ser desde o começo um protocolo aberto e mantido pela comunidade, o que o torna uma das iniciativas mais interessantes existentes hoje para tornar as redes sociais melhores.

Referências.:

https://activitypub.rocks/
https://pt.wikipedia.org/wiki/ActivityPub
https://elysiatools.com/pt/samples/activitypub
https://canaltech.com.br/redes-sociais/o-que-e-activitypub/
https://medium.com/@campos.felps/construindo-um-servidor-activitypub-minimalista-em-python-695cde9a9965

Método USE.: O que é e Como Usar

rafaelbonilha — Fri, 12 Dec 2025 13:31:44 +0000

Desenvolvido por Brendan Gregg, o método USE (Utilização, Saturação e Erros) para auxiliar na resolução de problemas de performance em sistemas críticos e complexos. Ele foi pensado para auxiliar profissionais de TI a solucionar problemas comuns de desempenho de forma rápida, sem deixar de lado áreas importantes, sendo construída para ser simples, direta, completa e rápida. Segundo Brendan, o método USE pode ser resumido em.: Para cada recurso, verifique utilização, saturação e erros.

OS TRÊS PILARES DO MÉTODO USE

A aplicação do método USE de forma efetiva começa com a criação de uma lista para o ambiente do sistema a ser verificado, onde nesta lista deve conter cada recurso considerado importante e as métricas específicas e ferramentas que serão usadas para medir a utilização, saturação e erros deste recurso. O uso de diagrams de blocos funcionais também é recomendado para mostrar os componentes físicos e suas conexões, auxiliando na análise do sistema em busca de falhas ou gargalos. Estes 3 pilares.: Utilização, Saturação e Erros são a base do método USE para análise de problemas de performance em sistemas.

Utilização (Utilization)

Utilização é para medir o tempo médio que um recurso é utilizado para atender uma solicitação. Isso permite identificar o tamanho da utilização do recurso num determinado período de tempo. Não é um problema, pois diversos sistemas são projetados para usar o máximo dos
recursos de forma a ganhar a eficiência. Mas utilização de 100% pode indicar de forma geral um gargalo, utilizações superiores a 70% por
períodos longos podem indicar problemas em alguns recursos como discos e CPUs, onde podem ocorrer picos pequenos de 100% de utilização.

Saturação (Saturation)

aturação mede o grau que um recurso tem trabalho extra que não pode atender, medida normalmente em uma fila. Ela indica quando um sistema
está perto de usar toda a sua capacidade ou mesmo excedendo essa capacidade para processar de forma eficiente. Ela é mais sensível em
identificar problemas do que a utilização. Pois mesmo recurso tendo utilização moderada, pode apresentar saturação por carga indevidas
de trabalho ou processamento incorreto de solicitações. A saturação é medida de formas diferentes de acordo com o tipo de recurso,
como por exemplo fila de i/o para discos, fila de execução ou latência para cpus ou paginação e swap para memória.

Erros (Errors)

Em USE, erros são eventos de erros relacionados a hardware ou sistema operacional. Exemplos de erros em USE são setores defeituosos,
timeouts de I/O, erros de rede, erros de memória e erros de CPU. Esses erros são importantes pois devem ser monitorados pelo seu impacto
na performance do sistema mesmo em caso de falhas pequenas, mas que gera degradação do sistema em atender solicitações ou executar operações.

USE exige uma lista de recursos para examinar, em caso de servidores por exemplo uma lista inclui os seguintes recursos.:

CPUs
Memória
Interfaces de Rede
Discos
Controladores
Interconexões

Considerações para o uso do método USE

Ele oferece diversos benefícios, onde permite que recursos importantes não deixem de ser analisados durante uma análise de performance.
USE é muito eficaz em identificar gargalos de recursos que não são óbvios ou estão escondidos em algumas métricas do sistema. Também o USE
é extremamente útil em análise de causa raiz em problemas de performance que podem ter relação com recursos. E por fim, USE tem uma
abordagem comum para discussão de problemas entre os times de diferentes áreas para melhoria de performance de sistemas.
Por outro lado, USE tem foco em recursos de sistema, não podendo capturar problemas específicos de performance da aplicação, ela exige
conhecimento significativo da arquitetura do sistema para ser aplicada de forma eficiente. Em alguns ambientes, algumas métricas de USE
podem não ser obtidas ou dificilmente obtidas, isso particularmente em ambientes de nuvem com acesso restrito a métricas do hardware usado.

Referências.:

E-book Os Métodos RED e USE e os 4 Golden Signals para Observabilidade - Jeferson Fernando
https://www.brendangregg.com/usemethod.html

Comandos Kubectl para Resolução de Problemas

rafaelbonilha — Fri, 21 Nov 2025 14:42:56 +0000

Vamos falar neste artigo de comandos que podem te ajudar a solucionar problemas no Kubernetes. Estamos considerando um cenário de falha em deploys de uma aplicação. Um cenário comum no dia a dia de um profissional DevOps/SRE/Engenheiro de Plataformas.
Antes é necessário conhecer o que compõe um deployment no Kubernetes, para facilitar o entendimento do que será abordado logo mais.

Componentes Do Deployment

Pod.: Menor unidade gerenciada no Kubernetes, onde carrega os containeres com a aplicação.
Deployments.: Controlador responsável por gerenciar o pod ou pods da aplicação.
Services.: É a camada de abstração para definir políticas de exposição de um conjunto lógico de Pods.
ConfigMaps e Secrets.: São os locais onde ficam os dados de configuração e segurança da aplicação. Vamos agora aos problemas relacionados a Deploys no Kubernetes.

Pods Não Iniciam

Por alguma razão, o pod não consegue ficar disponível, para entender o que está acontecendo, o ideal é identificar
o que está acontecendo com ele.:

Status do Pod.: Valide o status do Pod usando o comando kubectl get pods, atenção aos que estiverem com o status CrashLoopBackOff ou Pending.
Veja os logs do seu Pod.: Sim, os Pods registram as ações que são executadas neles, para isso use o comando kubectl describe pod nomedopod para identificar possíveis mensagens de erro ou eventos que podem ajudar na identificação do problema.

Erro de Pull Image

Tem casos que simplesmente não é possível puxar a imagem do container de forma correta, para este cenário vale a pena verificar os possíveis casos abaixo.:

Nome da Imagem.: Valide se o nome da imagem está correto no seu arquivo dockerfile ou no deployment.
Registro da Imagem.: Importante garantir que a imagem esteja no local correto e que seus nós estão com acesso a ela. Teste as rotas entre seus nós e o registro da imagem para verificar possíveis problemas de bloqueio por regra de firewall também deve ser considerado.

Erros de Configuração

Este tópico normalmente costuma nos trazer algumas dores de cabeça para descobrir que faltou alguma config ou deixamos de passar o valor de uma variável. Para ajudar a identificar as causas de problemas, comece olhando com atenção aos itens abaixo.:

✔ConfigMaps e Secrets.: Analise se ambos estão corretamente configurados. Para isso, o Kubernetes possui deixamos comandos que são úteis para estes casos.
✔Verificando Configmaps.: Execute o kubectl describe configmap nomedoconfigmap.
✔Verificando Secres.: Use o comando kubectl desccribe secret nomedasecret.
✔Variáveis de Ambiente (ENVs).: Valide se as variáveis de ambiente estão com os valores corretos no manifesto do deployment.

Comandos Úteis

A seguir uma lista de comandos que ajudam a diagnosticar e identificar problemas.:

kubectl get namespaces.: valida os namespaces do cluster.

kubectl get deployment -n namespace.: verifique o status dos deployments de um namespace especifíco.

kubectl get pods -n namespace.: mostra todos os pods do namespace e seus status.

kubectl logs.: esse comando permite acessar logs do seus recursos no kubernetes, por exemplo.:
kubectl logs nomedopod
kubectl logs -f -l app=aplicacao -n namespace-prd --all-containers=true -> para verificar os logs de uma aplicação específica

kubectl get events.: para ver os eventos do cluster.

kubectl describe.: mostramos bastante esse comando no nosso artigo, ele detalha as informações de um recurso,
permitindo verificar uma possível configuração incorreta ou problemas.

kubectl exec.: este comando permite acessar um pod em execução para executar comandos dentro dele para diagnóstico.
ou solução de problemas. Por exemplo.: kubectl exec -it nomedopod /bin/bash (para usar comandos shells no pod).

kubectl get nodes.: retorna as informações sobre os nós do cluster, você pode usar ele com o argumento --wide ou -w para retornar informações adicionais.

Referências

https://kubernetes.io/docs/tasks/debug/debug-cluster/kubectl-node-debug/
https://kubernetes.io/docs/tasks/debug/debug-application/determine-reason-pod-failure/
https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/
https://medium.com/totvsdevelopers/comandos-uteis-e-mais-usados-no-kubernetes-cc764f1a9450
Ebook Resiliência No Kubernetes na Veia - Jeferson Fernando - https://linuxtips.io/ebooks/

O que é o Método RED para Observabilidade

rafaelbonilha — Sun, 05 Oct 2025 22:14:28 +0000

Surgido das experiências adquiridas enquanto trabalhava no Google, Tom Wilkie desenvolveu o método RED (rate, errors
and duration), derivada das práticas adotadas pelo time de SRE da Google. O foco do RED é no que os usuários estão tendo de experiência com a aplicação, focando nos serviços individuais dentro de uma arquitetura distribuída.
Isso se deve ao fato que o método USE atende bem hardware, rede e discos, mas ele não atende bem os cenários de serviços de software, exigindo uma filosofia especifíca para software em microsserviços.

RED busca garantir que os serviços de software funcionem adequadamente para os usuários, onde as principais métricas dão nome ao método.: Taxa (Red), Erros (Errors) e Duração (Duration). A seguir iremos falar um pouco de cada uma delas.:

✔ Taxa (Rate).: Taxa é utilizada para medir o número de solicitações por segundo que um serviço está processando.
Ela permite entender o comportamento da demanda em cada serviço individual e identificar padrões que podem tanto gerar oportunidades como problemas de otimização.
Medir taxas de solicitações por segundo pode ser útil para a maioria dos serviços de software, mas alguns casos que possuem padrões indefinidos de demanda, olhar médias ao longo de determinados períodos de tempo pode ser mais indicado.
Além disso, a taxa pode ser uma métrica de contexto útil para entender o comportamento de outras métricas em um ambiente complexo e distribuído.

✔ Erros (Errors).: Dentro da filosofia do método RED, erros são os números de solicitações que tiveram problemas.
É uma métrica importante por que ela analisa algo que impacta diretamente os usuários, pois serviços com erros são percebidos pelos usuários. Solicitações que demoram mais que um tempo limite determinado podem ser considera das erros mesmo que retornem mensagem de sucesso.
Lembrando que é importante não apenas contar a quantidade de erros, mas considerar a taxa de erros como uma % do tráfego. Por exemplo.: taxas de erros de 1% para um serviço pode ser considerada aceitável, mas inaceitável para outro, classificar os tipos de erros é importante e ajuda na criação de alertas mais eficientes e na priorização
de atendimento em caso de incidente.

✔ Duração (Duration).: duração é a métrica que irá medir o tempo que as solicitações são atendidas. É a mais facilmente percebida pelos usuários, quando um serviço fica lento, os usuários logo percebem a lentidão.
Para medir essa métrica, é necessário atenção especial as distribuições para evitar usar apenas média. Médias podem trazer resultados enganosos por causa da influência de determinadas quantidades de solicitações. Trabalhar com porcentagens como P95 por exemplo podem trazer uma foto mais realista do que a maioria dos usuários estão tendo de comportamento do serviço.
Separar o que é a duração de solicitações com sucesso de solicitações com falha é importante pois cada uma gera diferentes impactos para os usuários e para o diagnóstico de problemas.

Benefícios do Método RED

RED fornece diversas vantagens para aplicações construídas em arquitetura de microsserviços. Além de reduzir a carga de trabalho através de uma visão de como cada serviço está agindo, possibilitando a rápida identificação de serviços com problemas ou instáveis.
RED também permite identificar como anda a experiência do usuário, possibilitando ações para manter os usuários satisfeitos com os serviços. Na arquitetura de microsserviços, a metodologia RED permite abstrair de forma eficiente o que está de errado com um serviço, permitindo ações mais eficientes e rápidas de correção.
Finalmente, RED permite a automação de tarefas e alertas, gerando aos times alertas e dashboards padronizados, o que torna os times mais efetivos.

Limitações e Considerações Finais

Apesar de ser muito bom para a arquitetura de microsserviços, RED tem algumas limitações que devem ser levadas em conta. Ele é muito bom para serviços orientados a solicitações, serviços que usam processamento em lotes ou streaming ele pode não ser tão efetivo. Outro ponto.: ele foca em solicitações síncronas, podendo não ser muito adequado para serviços assíncronos ou orientados a eventos.

Outra limitação é que RED não possui insights para problemas em recursos específicos, por exemplo.: um aumento no tempo de resposta de solicitação de forma ligeira pode ocorrer e você não ter as métricas internas do serviço para determinar as causas.
Em cenários de serviços que fazem muitas solicitações de downstream, RED pode ter suas métricas influenciadas por dependências, o que torna difícil identificar problemas no serviço.

O próprio criador do método, Tom Wikie recomenda que RED deva ser usada em conjunto com outras métricas, pois RED não foi pensada para cobrir todos os pontos da monitoração, o que faz com que ela seja possível de usar junto com outros métodos como o USE, fornecendo aos times uma cobertura de forma abrangente do monitoramento de uma aplicação.

Referências.:
https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/
https://gist.github.com/lpsm-dev/af6acc8bf6581614e3f88485d87d27e4
https://www.opservices.com.br/o-metodo-red-uma-nova-estrategia-para-monitorar-microsservicos/
https://medium.com/@valentin.marlier/monitoring-made-simple-understanding-red-and-use-methodologies-608aec056ae9
https://www.sentinelone.com/blog/red-and-monitoring-three-key-metrics-and-why-they-matter/
https://thenewstack.io/monitoring-methodologies-red-and-use/
E-book Os Métodos RED e USE e os 4 Golden Signals para Observabilidade - Jeferson Fernando - LinuxTips.

ComunicaOps Parte 2.: Desafios de ter um time coeso e motivado de DevOps/SRE/Eng. de Plataformas

rafaelbonilha — Wed, 10 Sep 2025 15:24:23 +0000

Um dos grandes problemas para garantir que o time de DevOps/SRE/Engenharia de Plataformas atue de forma coesa e
eficiente é conduzir as pessoas do time para que tenham uma visão compartilhada, seja ela estratégica ou técnica.
Ter todos alinhados quanto a visão do time e objetivos é essencial para manter o foco e garantir que os esforços
sejam direcionados para os resultados a serem atingidos.
Por serem geralmente times que lidam com diversas áreas na organização, é fundamental que o time de DevOps/SRE/
Engenharia de Plataformas tenha bem definido seus objetivos e visão, mas para isso é necessário que esses objetivos
e visão sejam bem definidos.

Visão

Ter uma visão clara e bem definida é o começo para motivar e inspirar a equipe. Ela deve descrever o futuro
do time desejado e a direção que o mesmo deve seguir. Para isso, é necessário que a visão da equipe seja
alinhada aos valores e missão da organização, destacando a importância do trabalho do time e como contribui
para alcançar um objetivo maior e o impacto positivo que pode gerar.
É importante também que a visão seja clara e desafiadora o suficiente para orientar as ações do time e inspiradora o
suficiente para que a equipe tenha motivação para alcançá-la.

Objetivos

Se temos uma visão definida, com ela é possível criar objetivos ou metas que sejam claras e possíveis de serem
mensuradas. Uma maneira de alcançar isso é usando a metodologia SMART (Specific, Measurable, Achievable, Relevant,
Time-bound), isto é, determinar objetivos que sejam específicos, mensuráveis, atingíveis, relevantes e temporal,
isto é, com prazos realistas e alinhados com o time.
E onde entra a comunicação, você deve se perguntar?

Comunicação.: Ponte para definir a visão e os objetivos do time

Comunicação é fundamental não só para definir a visão e os objetivos com a equipe, ela ajuda a manter a clareza
e a motivação das pessoas no dia a dia para que o time de DevOps/SRE/Engenharia de Plataformas façam seu trabalho
de forma eficiente e coesa, entregando soluções ou ecossistemas eficientes e robustos para a organização.
Pensando nisso, a comunicação deve ter algumas das iniciativas abaixo.:

Compartilhe.: Comunicar-se exige compartilhar não somente a visão e os objetivos, mas tudo aquilo que seja
importante ou que traga benefícios para o time. Fazer bate papos regularmente com a equipe sobre a visão
e os objetivos, trazendo o progresso e próximos passos e o impacto no contexto da organização ajuda a manter
o time focado e ciente do que é necessário e importante a ser feito.
Motive a Participação e o Diálogo.: Motivar e encorajar as pessoas da equipe a expor suas ideias e opiniões
ajuda a criar e aumentar a sinergia entre os membros como também ajuda a criar um ambiente onde as pessoas
se sentem ouvidas e motivadas. Uma maneira de alcançar uma colaboração maior entre o time é ter objetivos
colaborativos, de curta duração por exemplo, para incentivar o trabalho em equipe e reforçar laços.
Revise Processos.: Estabelecer uma revisão de práticas junto com o time ajuda a evitar desperdício de energia
e tempo em processos que não fazem mais sentido ou que tenham pouco valor. Ouvir as sugestões da equipe ajuda
os membros a se sentirem mais envolvidos e motivados, além de colaborar para identificar gargalos nas atividades
e a criação de novas rotinas para tornar o time mais dinâmico e produtivo.
Mantenha sempre o valor no coletivo.: Por mais que um time seja formado por pessoas de diferentes níveis de
conhecimento técnico, é importante buscar distribuir as tarefas de forma uniforme sempre que possível e
promover uma cultura onde todos se sintam valorizados e importantes dentro da equipe.
Forneça feedbacks e reconhecimento.: Manter feedbacks construtivos de forma regular ajuda a manter a orientação
dos membros da equipe, assim como seu desenvolvimento de forma contínua. Reconhecer o progresso e conquistas
individuais e coletivas reforça o senso de pertencimento do time e sua motivação para alcançar os objetivos.

Conclusão

Ter uma visão e objetivos claros aliados a uma comunicação eficaz possibilita o desenvolvimento de um time motivado
e com clareza para buscar o sucesso na organização. Lembrando que a visão e os objetivos devem ser revisados com a
equipe de forma regular para adaptá-los as mudanças de forma a garantir que as entregas reflitam as demandas atuais.
E com a comunicação clara e aberta, juntos é possível criar um ambiente positivo e estimulante para que os membros
se desenvolvam e cresçam.

Referências.:

https://stackspot.com/pt/blog/time-de-engenharia-de-plataforma/
https://portaldalecarnegie.com.br/criando-uma-visao-e-proposito-de-equipe/
https://medium.com/@petrusje/descobrindo-o-prop%C3%B3sito-do-time-a-import%C3%A2ncia-da-conversa-de-prop%C3%B3sito-6f32e7401d30
https://www.flowup.me/blog/planejamento-tatico/

ComunicaOps: Criando Alicerces para Construção de Plataformas

rafaelbonilha — Fri, 15 Aug 2025 19:38:42 +0000

A comunicação é muito importante dentro das práticas de DevOps e Engenharia de Plataformas, sendo um elemento
crítico para o sucesso dos times poderem projetar, operar e evoluir infraestrutura de forma coordenada.
Em resumo, a construção de uma plataforma que seja robusta, confiável e fácil de usar é um desafio tanto social
quanto técnico.
A tecnologia define o que a plataforma pode fazer, mas a comunicação determina se ela será usada e se agregará
valor.

Entendendo o Rolê.: Saber o que o negócio ou o cliente espera de uma entrega

Talvez em última análise, a comunicação seja o fator de construir pontes entre os times de DevOps/SRE/Engenharia
de Plataformas e seus clientes, sejam eles outras áreas de TI, da empresa, negócio ou externo.
E a solidez dessas pontes não depende apenas de tão qualificado seja o time, mas da qualidade da comunicação.
Sabemos o que acontece quando não temos uma boa comunicação.: Silos entre times e áreas, cultura de culpar o outro
e prejuízos para pessoas e o negócio.
Isso leva a um cenário de conflito entre áreas e pessoas, gerando atrasos, crises e frustrações que atrasam a
entrega e gerando prejuízos.

Comunicação garante um alicerce para que plataformas sejam bem pensadas e construídas, evitando a chamada
estrada para lugar nenhum. Alinhamento de expectativas, objetivos e plano de ação via ciclo de feedbacks
garante o que a plataforma a ser construída irá oferecer e quando. Lembrando que a plataforma é um produto
em evolução, sendo necessário tratar o seu roadmap como algo mutável, não estático.

O que precisamos.: Empatia e Soft Skills

Ter uma escuta ativa e empatia é fundamental para entender perspectivas diferentes, ajudando a reduzir ruídos
na comunicação e acelerando a resolução de possíveis conflitos, importante em contextos de grande pressão
e prazos curtos. Aliadas a feedbacks bem feitos e rápidos, fluxos visualmente claros e aprendizado contínuo
garantem a fluidez da comunicação, ajudando a obter as melhores respostas para as questões que surgirem
no desenvolvimento da plataforma.
São essas ferramentas que permitirão aos times alcançarem a sinergia, isto é, falarem a mesma língua e irem
na mesma direção.

Conclusão.: Plataformas São Feitas para Pessoas

Alinhando expectativa, técnicas de comunicação claras, transparência, colaboração, visibilidade aliada a cultura
de que erros são oportunidade de aprendizado, não de punição entre os times pode garantir aos times de
DevOps/SRE/Engenharia de Plataformas que estão construindo não apenas ferramentas, mas ecossistemas robustos e
confiáveis para acelerar a inovação e a capacitação de todos dentro da organização.

Referências.:

https://youtu.be/HwMN_ohz__8?si=NywFvaUhlFFSpM1V
https://www.youtube.com/live/nvINtvy_8eI?si=KAt_zKJ0AgA-MoKL
https://youtu.be/fKv5g-U6C0E?si=FnwCAT7N_bvExix4
The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win - https://a.co/d/5F4V2yP

Usando o Amazon WorkSpaces Core para migrações de VDI

rafaelbonilha — Sat, 12 Jul 2025 05:50:48 +0000

O Amazon WorkSpaces fornece um serviço de infraestrutura para área de trabalho virtual VDI gerenciado fornecendo
as organizações acesso a aplicações e dados, otimizando custos e maximizando a produtividade. Sendo flexível ao
ponto de permitir as organizações escolher áreas de trabalho virtuais para os usuários que necessitam acessar
ambientes consistentes e personalizados.
Sendo gerenciado pela mesma interface do Amazon WorkSpaces Pools no Console de Gerenciamento da AWS.

Alguns dos benefícios do WorkSpaces para cenários onde a VDI é uma opção mais benéfica.:

✔ Fornece acesso confiável e seguro a aplicações e dados.: O WorkSpaces fornece aos usuários acesso a aplicações e
dados armazenados na AWS, ajudando a maximizar a produtividade e a continuidade dos negócios com um SLA apoiado
financeiramente. Os serviços do WorkSpaces são criados na AWS, que foi projetada para estar entre os ambientes de
computação em nuvem mais seguros atualmente disponíveis.

✔ Flexibilidade para levar suas aplicações Microsoft 365.: O WorkSpaces oferece a
flexibilidade de fazer com que as licenças de aplicações do Microsoft 365 para empresas sejam executadas nos
serviços do WorkSpaces.

✔ Gerenciamento de VDI.: Com o WorkSpaces, você pode gerenciar uma combinação de áreas de trabalho virtuais do
WorkSpaces Personal e do WorkSpaces Pools usando o mesmo conjunto de aplicações para todos os usuários, resultando
em uma experiência unificada para administradores e usuários finais. A ferramenta de integração no Console de
Gerenciamento da AWS recomenda uma configuração adequada do WorkSpaces com base no seu caso de uso, reduzindo ainda
mais a carga administrativa.

✔ Escale sua infraestrutura com preços flexíveis.: O WorkSpaces oferece um modelo de preços flexível e econômico com
opções de cobrança mensal e por hora. Com o faturamento por hora, você paga apenas pelos recursos que usa,
facilitando a escalar sua infraestrutura de área de trabalho virtual à medida que as necessidades de sua empresa
mudam. Essa abordagem de pagamento conforme o uso elimina a necessidade de grandes investimentos iniciais e ajuda
você a ajustar seus gastos com áreas de trabalho virtuais.

Essas abordagens permite que em alguns cenários, o tempo de implantação de uma VDI seja reduzido em até 90%, o que
permite as organizações ganhar tempo para seus usuários, principalmente para cenários de usuários remotos.
Para cenários de usuários remotos e temporários, VDI são fundamentais e o Amazon WorkSpaces torna-se uma opção
interessante para estes cenários.

O Amazon WorkSpaces permite escolher entre WorkSpaces Personal ou WorkSpaces Pools de acordo com a necessidade.

WorkSpaces Personal.: Escolha WorkSpaces Personal se precisar de desktops virtuais persistentes que sejam Adaptado
para usuários que precisam de uma área de trabalho altamente personalizada provisionada para seu uso exclusivo.
Isso é semelhante a um computador desktop físico atribuído a um indivíduo.
WorkSpaces Pools.: Escolha o pool do WorkSpaces para áreas de trabalho virtuais não persistentes personalizadas
para os usuários que precisam de acesso a ambientes de desktop altamente selecionados hospedados em infraestrutura
efêmera.

É possível conectar aos WorkSpaces usando um aplicativo cliente por meio de um navegador Web compatível,
para PCs são recomendados os navegadores Firefox e Chrome.

Referências.:
https://docs.aws.amazon.com/workspaces/latest/adminguide/connect-client.html
https://aws.amazon.com/pt/workspaces-family/workspaces/
https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html

Conhecendo o Azure SRE Agent

rafaelbonilha — Fri, 20 Jun 2025 20:38:18 +0000

Anunciado como uma das maiores novidades do Microsof Build 2025, principal evento de tecnologia da empresa. Construído para usar recursos de IA juntamente com LLM, o objetivo do Azure SRE Agent é trazer respostas ágeis e proativas para manutenção de ambientes cloud. Apoiando na resposta de incidentes, a ferramenta tem como premissa reduzir a carga de trabalho de gerenciamento de ambientes cloud produtivos.

Usando LLMs para analisar os logs e métricas para uma análise efetiva e rápida da causa raiz de um problema e sua solução. Em cenários de crescimento da complexidade de ambientes clouds, o correto uso da engenharia de confiabilidade do site, SRE, apresenta-se como uma prioridade para os times responsáveis por manter funcionais, efetivos e confiáveis ambientes cloud em produção.

Integrado aos recursos de observabilidade e gerenciamento de incidentes como o Agentic DevOps no GitHub Copilot de forma que ele possa monitorar e aprender a integridade dos recursos, lidando com alertas de forma a resolver problemas mais rapidamente.

Principais Recursos
Com o objetivo de ajudar a tornar o ambiente mais confiável, escalável e seguro, o Azure SRE Agent conta com os seguintes recursos.:

✔ Avaliando tendências de uso e desempenho.: avaliando o ambiente de forma contínua, executando em segundo plano 24 horas por dia, 7 dias por semana, o SRE Agent auxilia os times através de respostas a perguntas via prompt para identificação rápida de inconsistências.

✔ Detecção e correção proativas de vulnerabilidades de Segurança.: Fazendo auditorias frequentes, o SRE Agent verifica uso de versões TLS com suporte por exemplo, assim como executar as operações necessárias para atualizar os recursos com sua aprovação para deixar os mesmos em conformidade.

✔ Resposta automatizada a incidentes e análise mais rápida da causa raiz.: Executando em conjunto com o Azure Monitor e o PagerDuty por exemplo, o SRE Agent pode atuar na resposta a incidentes, reduzindo o tempo de resposta e auxiliando os times na resolução de incidentes em um tempo menor que os métodos tradicionais.

✔ Mitigação de Incidentes.: Para normalizar uma aplicação ao seu estado operacional, o SRE Agent pode fazer ações em nome e com aprovação do usuário. Essas açoes podem ser escalar recursos, reiniciar aplicativos e executar rollbacks de aplicativo de forma normalizar uma aplicação de forma mais rápida possível.

✔ Feche o ciclo com os desenvolvedores.: Após a finalização da investigação, o SRE Agent cria um problema no GitHub, gerando os detalhes da investigação, ajudando os desenvolvedores a corrigir o código-fonte e evitar recorrências subsequentes de um incidente.

O Azure SRE Agent é um dos recursos novos mais aguardados para estarem disponíveis no Azure para os próximos meses para apoiar os times na gestão de ambientes cloud produtivos e complexos.

Referências.:
https://learn.microsoft.com/pt-br/azure/app-service/sre-agent-overview
https://azure.microsoft.com/en-us/blog/all-the-azure-news-you-dont-want-to-miss-from-microsoft-build-2025/
https://build.microsoft.com/en-US/sessions/DEM550
https://techcommunity.microsoft.com/blog/azurepaasblog/introducing-azure-sre-agent/4414569

CryptoRave, BSides, DevOpsDays e o impacto de participar de eventos de Tecnologia

rafaelbonilha — Tue, 20 May 2025 20:04:33 +0000

Este Post vai ser um pouco diferente do normal, nele vou abordar a experiência adquirida ao participar de eventos de Tecnologia e como isso é importante para ajudar a conhecer iniciativas, tecnologias e de estar mais próximo da comunidade.

É complicado estar presente em eventos presenciais: exige recursos, planejamento, tempo disponível e tem também a questão de em vários casos fazer a escolha de deixar alguma coisa de lado para poder estar presente no evento escolhido.

Nos dias 16, 17 e 18/05 agora eu participei de dois eventos.: CryptoRave e BSides SP, ambos na cidade de São Paulo. Cada um com suas particularidades e grades de programação vasta, diversa e com muitas possibilidades de interação com a comunidade de tecnologia.

CryptoRave 2025

Na CryptoRave tive a feliz oportunidade de ser novamente voluntário, é um evento que participo desde as primeiras edições por ter um foco importante em ações para grupos minoritários e as classes sociais mais vulneráveis economicamente. E como bônus eu pude palestrar no evento, numa programação vasta e de elevado nível técnico, poder compartilhar um pouco do que eu sei ao lado de pessoas que admiro foi uma das experiências que mais me marcaram nestes anos todos de participação em eventos.
É um evento gratuito, totalmente financiado pela comunidade e que recomendo demais a participação, ele ocorre anualmente e tem sido realizado nos últimos anos na Biblioteca Municipal Mário de Andrade, o que traz um charme a mais para o evento.
E como o nome diz, após o evento em si, tem a tradicional festa para finalizar com chave de ouro as 24 horas de palestras, intervenções e atividades.

BSides SP

A BSides SP é um evento com foco em segurança, organizado pela comunidade e que tem uma quantidade significativa de ingressos gratuitos e que é realizada sempre em 2 dias, um dia focado em cursos e o outro dia focado em palestras, intervenções e atividades para a comunidade.
É um evento muito disputado por já ser realizado à 20 anos, sendo que esta foi a 20° edição do mesmo. Foi muito bacana acompanhar as palestras e atividades com o foco em segurança, onde teve diversas iniciativas da comunidade para levar as boas práticas de segurança para o maior número de pessoas possível.

DevOpsDays

Este é um evento que eu tenho um carinho muito grande, pois foi o primeiro evento que eu consegui participar após a pandemia e que me trouxe a noção do que a comunidade é capaz de fazer quando se une em prol de um objetivo comum.
Felizmente ele tem se expandido, sendo realizado em várias cidades no país, o que tem ajudado mais pessoas a participarem e conhecerem essa comunidade íncrivel. Tendo sido inicialmente criado em Ghent, na Bélgica, hoje o DevOpsDays é realizado em várias cidades do mundo.

É isso pessoal, espero que possam ter essa experiência e que ajudem a espalhar o conhecimento.
Até o próximo post =)!

Kagent: Agents de IA em clusters Kubernetes

rafaelbonilha — Sat, 12 Apr 2025 04:04:41 +0000

Hoje vamos abordar um projeto que está em seu início, mas que traz uma ideia bem interessante: usar agentes de IA em clusters Kubernetes para automatização, solução de problemas e desafios na nuvem, criado especificamente para os times de DevOps/Engenharia de Plataformas. Esta ideia é o que está por trás do Kagent.

Isso é feito usando os recursos de raciocínio e planejamento iterativo transformando insights de IA em ações, apoiando os times em desafios operacionais comuns ou complexos como degradação de desempenho de uma aplicação, automação de alertas, gerenciamento de implementações, entre outros.

Componentes Principais

O Kagent possui 4 componentes principais:

✔ Controller.: O controller é o controlador do Kubernetes para monitorar os recursos personalizados do Kagent e cria os recursos necessários para executar os agentes.
✔ UI.: O UI é a interface web fácil de usar para gerenciar os agentes e ferramentas.
✔ Engine.: O engine é formado por uma aplicação Python que executa os agentes e ferramentas. O engine é construído usando o Autogen.
✔ CLI.: A preferida dos usuários, o CLI é a ferramenta de linha de comando que permite gerenciar os agentes e as ferramentas de forma otimizada e flexível.

Agora que conhecemos a arquitetura do Kagent, vamos conhecer os conceitos principais por trás dele.

Conceitos Principais

O Kagent utiliza-se de 2 conceitos: Agentes e Ferramentas, ambos são recursos personalizados do Kubernetes, tornando os fáceis de gerenciar e modificar.

Agentes.: São o principal componente do Kagent, sendo um conjunto de ferramentas, uma configuração de modelo e um prompt do sistema.
Ferramentas.: São quaisquer ferramenta externa que pode ser usada em um agente. Definidas como recurso personalizado do Kubernetes, ela pode ser usada por vários agentes.

Além dos conceitos, o Kagent tem os seguintes príncipios:

✔ Kubernetes Nativo.: Criado para ser fácil de entender e usar, fornecendo uma maneira flexível e poderosa para criação e gerenciamento de agentes de IA.

✔ Flexível.: O Kagent é criado para ser flexível, adaptativo para qualquer caso de uso de agente de IA.

✔ Extensível.: Permite que o usuário adicione suas próprias ferramentas e agentes.

✔ Observável.: Projetado para que seja fácil de monitorar os agentes e ferramentas usando as estruturas de monitoramento mais comuns, o Kagent facilita o trabalho dos times para monitorar o uso das cargas de trabalho dos agentes em clusters Kubernetes.

✔ Declarativo.: O Kagent foi desenvolvido para ser declarativo, permitindo que as definições dos agentes e das ferramentas possam ser feitas em um arquivo YAML.

✔ Testável.: Este ponto é importante para os agentes de IA e aplicações baseadas, pois o Kagent foi criado para ser testado e depurado de forma rápida e fácil, dando aos times agilidade na identificação e solução de problemas.

Por ser um projeto novo, o Kagent segue em constante evolução e estão previstas melhorias em observabilidade, testes, tempo de execução e ferramentas.
Vale a pena ficar de olho neste projeto que promete trazer muitos benefícios para os times de DevOps/Engenharia de Plataformas.