Por Heron Brito — Audaz Tecnologia

O contexto

Cliente do setor de serviços para condomínios. Operação corporativa sustentada em Active Directory: autenticação, governança de acesso, aplicação de políticas, ERP Alterdata como sistema central de gestão. Ambiente Windows tradicional, múltiplos Domain Controllers — o tipo de infraestrutura que sustenta milhares de empresas brasileiras hoje.

Essa semana, durante uma operação de manutenção considerada rotineira — promoção de um novo Domain Controller — algo silencioso aconteceu. Por muitos dias, a empresa operou em estado degradado, com políticas de TI desaplicadas em toda a base de estações. Sem alerta crítico. Sem tela vermelha. Sem nada que parasse o negócio de cara.

O risco que não acende vermelho

Plano de continuidade geralmente é desenhado pra cenários binários: o sistema está no ar ou fora do ar. Mas existe uma classe de incidente que escapa desse modelo: a degradação silenciosa. Sistema responde. Usuário loga. Aparentemente, tudo certo. Mas uma camada de governança — invisível pro usuário final — parou de funcionar. Políticas de segurança não estão sendo aplicadas. Restrições de software caíram. Configurações padronizadas viraram caos individual.

Foi exatamente o que aconteceu. Um detalhe técnico durante a promoção do novo DC fez com que o subsistema responsável por replicar as políticas começasse a propagar conteúdo vazio como se fosse a versão correta. Em horas, todos os controladores estavam “saudáveis” do ponto de vista de monitoramento básico, operando sem a base de governança que sustentava o ambiente.

Por que isso importa pra um CTO

Superfície de risco invisível. Toda empresa que depende de AD pra governança tem essa exposição. Enquanto o monitoramento olhar só pra “o serviço respondeu?”, esse tipo de incidente continua passando.

O custo real é maior que o tempo de indisponibilidade. Muitos dias com políticas desaplicadas significam restrições de software desligadas, políticas de auditoria sem efeito, janela aberta pra movimentação lateral, compliance descumprido sem registro. Pra empresa em mercado regulado, isso é exposição material.

Recuperação correta de AD não é tutorial de internet. Boa parte do material disponível ensina procedimento errado pra ambiente moderno, e aplicar errado piora o cenário — pode virar crise de semanas, não de dias. Empresa que opera AD em produção precisa ter, internamente ou via parceiro, quem conhece o subsistema em profundidade.

Como recuperamos

A operação seguiu três fases, com forte uso de IA e automação nas fases de planejamento e validação:

1. Diagnóstico estruturado. Antes de tocar em qualquer DC, mapeamos o estado real do ambiente via automação. IA entrou pra correlacionar eventos em volume, isolar a sequência real do incidente e ranquear hipóteses. Em vez de varrer log na mão, conseguimos reconstrução cronológica em minutos.

2. Restauração cirúrgica. Restore autoritativo do conteúdo de governança a partir do controlador íntegro, orquestrado via PowerShell pra eliminar erro humano em operação de alto impacto. Scripts revisados com apoio de IA antes de rodar em produção — busca por edge cases e riscos que escapariam de revisão humana sob pressão.

3. Validação ponta a ponta. Conferência de que toda a base de estações voltou a aplicar as políticas corretamente. IA usada novamente pra comparar comportamento pós-restore com baseline esperado e identificar qualquer divergência sutil.

O hardening que veio depois

Recuperar é metade do trabalho. Garantir que não acontece de novo é a outra metade:

• Procedimento padronizado e automatizado pra promoção de DC, com validação via PowerShell antes e depois de cada operação
• Monitoramento ativo com Zabbix em subsistemas críticos pra detectar inconsistência antes que se propague
• Visibilidade de segurança com Wazuh client nos DCs — Zabbix te avisa que algo quebrou, Wazuh te diz o que mudou e quem mudou
• Backup com retenção compatível com janela de descoberta tardia
• Validação contínua com apoio de IA comparando comportamento atual com baseline — pega o “monitoramento tá verde, mas tem algo estranho” que escapa de threshold tradicional
• Segregação de função pra operações críticas, com janela formal e aprovação

A leitura estratégica

Mas enquanto a reescrita não chega, a operação atual depende da infraestrutura atual. AD, GPO, replicação — essa camada sustenta o negócio hoje. E geralmente é tratada como “o que sempre funcionou”, até o dia que para de funcionar.

The post O risco escondido na sua infraestrutura de identidade: o que um caso real de recuperação de AD ensina sobre maturidade operacional appeared first on Audaz Tecnologia.

“A maioria dos CTOs pensa que upgrade de infraestrutura é fácil — até uma API ficar depreciada e ser necessário refazer várias esteiras de CI/CD.”

Esse início de 2026 está provando o ponto. O Kubernetes está empurrando a depreciação do Ingress NGINX, a obrigatoriedade de cgroups v2, mudanças de sintaxe em manifests que rodavam há anos sem ninguém mexer. Costumo dizer na minha roda de amigos que “todo software vai ser reescrito” — e o que parecia provocação virou rotina. Está acontecendo agora, em silêncio, em janelas de madrugada, em centenas de componentes internos na cloud que não podem cair.

Ontem terminamos uma dessas operações: o upgrade do cluster Kubernetes de um cliente do setor de saúde corporativa, da versão 1.31 para a 1.35 no OKE (Oracle Kubernetes Engine). Quatro saltos de versão, ambiente em produção, janela total de 3 horas fora do horário comercial. Esse artigo é o relato técnico — e estratégico — dessa operação.

O contexto: saúde corporativa rodando em containers

O cliente em questão opera serviços de saúde dentro de prédios de grandes empresas — atendimento ocupacional, agendamento de exames, ergonomia, prontuário. Toda a camada de software que sustenta essa operação (sistemas de atendimento e agendamento de pacientes) foi desenvolvida pela Audaz e roda em Kubernetes na Oracle Cloud Infrastructure.

Na prática: se o cluster cai, o atendimento de saúde para. E quando o cliente final do nosso cliente é uma multinacional com SLA contratual, “ficar fora do ar pra atualizar” não é decisão técnica — é decisão comercial.

Por que sair da 1.31 era inadiável

A 1.31 ainda funcionava. Mas funcionar não é critério em ambiente crítico. Os fatos que pesaram na decisão:

1. Janela de suporte do OKE é curta. O OKE geralmente mantém só três versões minor de Kubernetes ativas para novos clusters. Quando uma nova entra, a mais antiga sai. Ficar pra trás significa rodar um cluster sem patches de segurança — inaceitável para uma operação que lida com dados de saúde.

2. A 1.35 é uma quebra estrutural, não cosmética. A versão 1.35, apelidada de “Timbernetes” (The World Tree Release), exige cgroups v2 — ou seja, na prática, worker nodes têm que rodar Oracle Linux 8 ou superior. Não dá pra fazer upgrade in-place do sistema operacional dos nodes. Quem só descobre isso na hora do upgrade descobre tarde demais.

3. NGINX Ingress está em fim de vida. A comunidade Kubernetes anunciou que o Ingress NGINX deixa de receber manutenção em março de 2026 — sem mais releases, sem correções de bug, sem patch de segurança. Quem não planejou migração pra Gateway API ou alternativa suportada vai descobrir o problema do pior jeito possível: em produção, com vulnerabilidade conhecida e sem patch.

4. Ganhos operacionais reais. A 1.35 traz in-place Pod resource updates — dá pra ajustar requests e limits de CPU e memória sem reiniciar pods. Pra workloads stateful como sistemas de agendamento, isso reduz disrupção e acelera tuning de performance.

O desafio que não estava no roteiro: sintaxe

Quando se planeja um upgrade de Kubernetes, geralmente o pessoal foca nas peças óbvias — control plane, node pools, CNI, storage. O que mais consumiu engenharia nessa operação foi outra coisa: mudanças de sintaxe nos manifests.

Entre a 1.31 e a 1.35, vários campos de API mudaram de comportamento ou foram movidos. Declarações de imagem de container, especificações de recursos, configurações que rodavam há anos sem ninguém tocar — tudo precisou ser revisitado. Não é uma reescrita conceitual; é reescrita mesmo, manifest por manifest, pipeline por pipeline.

E é aqui que a frase do começo do artigo cobra seu preço:

“…é necessário refazer várias esteiras de CI/CD.”

É geralmente o que acontece. Cada pipeline que constrói imagem, cada chart Helm, cada template de deploy precisou ser validado contra a nova sintaxe. Não tem atalho. Não tem IA que faça isso de forma confiável sem revisão humana de quem entende o ambiente.

Como executamos: a engenharia por trás do “deu tudo certo”

Quando o cliente final só percebe o upgrade pelo grupo de WhatsApp, é porque a engenharia foi feita certo. O roteiro real:

1. Inventário e leitura de campo

Antes de qualquer kubectl, mapeamos cada node: imagem base, versão de kubelet, dependências de CNI, workloads stateful, jobs cron, integrações externas. Identificamos os pontos de risco — em especial qualquer node em OL7, que precisava sair antes da 1.35 chegar perto.

2. Skew policy respeitada, sem atalho

Kubernetes não permite saltos arbitrários entre versões. A partir da 1.28, worker nodes podem ficar até três versões atrás do control plane, mas não podem ir além disso, nem rodar versão mais nova que o control plane. Sair da 1.31 pra 1.35 é, na prática, uma sequência coreografada: control plane sobe, valida, worker nodes acompanham, valida, repete.

3. Migração de OS antes de tocar na 1.35

Como não dá pra fazer upgrade in-place do sistema operacional dos nodes, criamos node pools novos com imagem OKE OL8 (com cgroups v2 ativo), migramos workloads via cordon e drain, e só então retiramos os pools antigos. Esse trabalho preliminar é o que separa um upgrade tranquilo de um upgrade que vira incidente.

4. Refatoração de manifests e pipelines

Sintaxe nova, validação manifest por manifest, ajuste das esteiras de CI/CD que constroem e publicam as imagens. Sem isso, o cluster sobe — mas os deploys depois quebram.

5. Janela de 3 horas, fora do horário, com plano de rollback

A operação levou 3 horas porque o trabalho preliminar foi feito antes. Sem o inventário, sem a migração de OS prévia, sem a refatoração dos manifests testada em ambiente espelhado, essa mesma operação seria uma madrugada inteira — ou pior, um rollback às pressas com sistema de agendamento fora do ar no dia seguinte.

A reflexão estratégica: o ciclo não vai parar

O que aconteceu nessa operação vai acontecer em todo cluster Kubernetes em produção no Brasil nos próximos 12 meses. Quem está em 1.30, 1.31, 1.32 vai precisar mover. Quem usa NGINX Ingress vai precisar migrar. Quem ainda tem workers em OL7 vai precisar trocar a frota.

E essa é só a parte visível. Por baixo, tem uma fila de componentes internos da cloud que estão sendo reescritos em silêncio — operadores, CRDs, controllers, plugins de CNI, integrações de observabilidade. É por isso que insisto com meus pares: todo software vai ser reescrito. Costumo brincar que até o Notepad vai ser reescrito — e quando você olha pro Notepad do Windows hoje (abas, autosave, integração com IA), percebe que a piada já não é mais piada. Não é metáfora futurista; é o que está rolando geralmente, nos bastidores da infraestrutura cloud-native.

A pergunta pro CIO ou CTO não é se o upgrade vai ser necessário. É:

• Quem vai mapear o impacto de cada depreciação no nosso ambiente?
• Quem vai refatorar as pipelines quando a sintaxe mudar?
• Quem vai garantir que a janela seja de 3 horas e não de 3 dias?
• Quem vai sustentar essa cadência de upgrades — três por ano, pra sempre?

Empresas com time interno robusto fazem isso por dentro. Empresas que dependem de poucos especialistas, ou cujo time de TI já está sobrecarregado com a operação do dia a dia, acumulam dívida técnica em silêncio até o dia em que a dívida vence de uma vez só.

Como nossos clientes se beneficiam disso

Pros clientes da Audaz, esse ciclo não é problema. É rotina operacional.

Não dependem de um único especialista. Quem entende de Kubernetes, OKE, OL8, cgroups v2 e refatoração de manifests é um time — não uma pessoa que pode pedir demissão na semana errada.

Não pagam o custo de aprender errando. A primeira vez que uma equipe interna faz upgrade de Kubernetes em produção, ela aprende caro. Nossos clientes herdam o aprendizado de operações como essa, em ambientes financeiros e de saúde, sem absorver o custo da curva.

Janela curta, plano de rollback, zero surpresa. A operação descrita levou 3 horas porque o trabalho de preparação — inventário, migração de OS, refatoração de pipelines, ambiente espelhado — foi feito antes. É geralmente esse o padrão que entregamos.

Visão completa do stack. Rede, segurança, pipeline, aplicação. Não é o time de Kubernetes apontando pro time de rede que aponta pro time de aplicação. É um único parceiro técnico, responsável de ponta a ponta.

Onde está o seu cluster?

Se sua empresa roda Kubernetes em produção e você não tem certeza absoluta de em qual versão está, quando expira o suporte dela, ou se as suas pipelines vão sobreviver à próxima depreciação — esse é o momento de olhar com calma, antes de virar urgência.

A Audaz oferece avaliação de maturidade DevOps e Cloud Native: um diagnóstico técnico do seu ambiente Kubernetes, das suas pipelines e do seu plano de upgrades, com um roadmap concreto de modernização e mitigação de risco.

Se faz sentido conversar, fala com a gente.

Audaz Tecnologia — engenharia de precisão para infraestrutura crítica. DevOps, segurança e Cloud Native em ambientes que não podem parar.

The post Da 1.31 à 1.35 sem drama: o que aprendemos atualizando Kubernetes em produção no OKE appeared first on Audaz Tecnologia.

O que é DevOps?

Em primeiro lugar, trata-se de uma cultura, conjunto de práticas e filosofia de trabalho que visa alinhar as equipes de desenvolvimento de software e operações, que tradicionalmente atuavam de forma separada e com objetivos distintos. Nesse sentido, a principal ideia por trás do DevOps é promover a comunicação e colaboração entre essas equipes, buscando uma entrega mais rápida, confiável e contínua do software.

Afinal, como funciona o DevOps?

Ele se baseia em alguns pilares essenciais:

1. Colaboração e Comunicação: estabelecendo uma cultura de colaboração e comunicação entre as equipes de desenvolvimento, operações e outros departamentos relevantes. A comunicação fluida entre essas áreas é a base para o sucesso do DevOps.
2. Automação: A automação é uma peça-chave no DevOps. Ao automatizar tarefas repetitivas, como implantação, testes e monitoramento, é possível reduzir erros humanos, economizar tempo e acelerar o processo de entrega.
3. Entrega Contínua: O conceito de entrega contínua é um dos pontos mais importantes dessa cultura. A ideia é tornar o processo de implantação de software mais agil e acertivo, garantindo que novas funcionalidades possam ser entregues ao usuário final de forma incremental e constante.
4. Monitoramento e Feedback: O DevOps enfatiza a importância do monitoramento contínuo do software em produção. Isso permite identificar problemas rapidamente, fornecer feedback aos desenvolvedores e realizar melhorias constantes.

Além disso, Implementação do DevOps pode trazer diversos benefícios para a empresa, incluindo:

• Redução do tempo de lançamento de novas funcionalidades;
• Maior confiabilidade das implantações;
• Menor taxa de falhas e bugs em produção;
• Melhoria na colaboração e satisfação das equipes;
• Maior eficiência operacional e redução de custos;
• Respostas mais ágeis às mudanças de mercado e às necessidades dos clientes.

Conclusão:

Como resultado, o DevOps é uma abordagem que se mostra indispensável para empresas que desejam se destacar no mercado atual. Pois, ao integrar desenvolvimento e operações, essa metodologia permite alcançar níveis mais elevados de eficiência, qualidade e satisfação do cliente. Da mesma forma, com a cultura de colaboração, a automação e a entrega contínua como pilares, o DevOps torna-se uma poderosa ferramenta para a transformação digital das organizações. Portanto, investir em DevOps é a melhor opção para impulsionar o sucesso e o crescimento da sua empresa na era da tecnologia, conte com a Audaz Tecnologia para com sua empresa.

The post DevOps: Uma Abordagem Transformadora para o Desenvolvimento de Software appeared first on Audaz Tecnologia.

Em primeiro lugar, o cenário da tecnologia evolui rapidamente, e novas soluções surgem para atender às demandas cada vez maiores das aplicações modernas. Uma dessas soluções, que merece destaque, é o Kubernetes. Aliás, o Kubernetes é uma plataforma de orquestração de contêineres que revolucionou o modo como as aplicações são implantadas e gerenciadas.

O Kubernetes open source e é o componente fundamental da Cloud Native Computing Foundation (CNCF) . Esta intituição concentra projetos de computação nativa em nuvem e neutra em relação a fornecedores.

Nesse sentido, Neste artigo, vamos explorar o que é o Kubernetes, como ele funciona e quais benefícios pode oferecer às empresas.

O que é o Kubernetes?

O Kubernetes, também conhecido como K8s, é uma plataforma de orquestração de contêineres de código aberto desenvolvida pelo Google. Sua principal função é facilitar o gerenciamento de aplicações baseadas em contêineres, como Docker, permitindo escalabilidade, resiliência e automatização das operações.

Como funciona essa ferramenta?

O Kubernetes adota uma arquitetura de mestre/nó. Em outras palavras, um ou mais nós mestres são responsáveis por gerenciar um conjunto de nós de trabalho, também conhecidos como nós de cluster (nodes). Assim, os nodes armazenam os contêineres, que encapsulam as aplicações e suas dependências. O K8s garante que os contêineres estejam em execução, escalando-os automaticamente com base nas necessidades de carga de trabalho, garantindo a resiliência e a disponibilidade das aplicações.

Principais conceitos do Kubernetes:

– Pods: O Kubernetes organiza os contêineres em pods, que são a menor unidade de implantação em um cluster. Além disso um pod pode conter um ou mais contêineres intimamente relacionados e compartilhar recursos e rede.

– Deployment: Esses recursos permitem que você defina e gerencie o número desejado de réplicas de um pod em execução, garantindo a escalabilidade e a disponibilidade da aplicação.

– Services: Os serviços fornecem uma abstração para expor as aplicações executadas em pods e permitem a comunicação entre eles dentro do cluster.

– Volumes: O Kubernetes oferece volumes para o armazenamento persistente de dados, permitindo que os contêineres compartilhem e acessem arquivos.

Benefícios do Kubernetes:

1. Escalabilidade: Em primeiro lugar, o Kubernetes permite dimensionar automaticamente as aplicações, adicionando ou removendo pods com base nas demandas da carga de trabalho, garantindo a utilização eficiente de recursos.

2. Resiliência: Além disso, com recursos como a replicação automática de pods e a detecção de falhas. Certamente, o Kubernetes garante a disponibilidade contínua das aplicações, minimizando o impacto de possíveis interrupções.

3. Portabilidade: Em terceiro lugar, o Kubernetes é uma plataforma flexível e portátil, permitindo que as aplicações sejam implantadas em diferentes ambientes, como data centers locais, nuvem pública ou ambientes híbridos.

4. Automação: O Kubernetes simplifica a implantação e o gerenciamento de aplicações por meio de recursos automatizados, como atualizações de versão, dimensionamento automático e provisionamento dinâmico de recursos.

Conclusão:

Em conclusão, o Kubernetes é uma solução poderosa para a orquestração de contêineres, permitindo que as empresas gerenciem de forma eficiente e escalável suas aplicações modernas. Com seus recursos avançados de escalabilidade, resiliência e automação, essa tecnologia simplifica a implantação e o gerenciamento de contêineres, aumentando a produtividade e a confiabilidade das equipes de desenvolvimento e operações.

Ao adotar o Kubernetes, as empresas podem enfrentar os desafios de escalabilidade e gerenciamento de aplicações distribuídas, possibilitando um ambiente ágil e dinâmico. Se você busca agilidade, escalabilidade e confiabilidade para suas aplicações, uma infraestrutura nativa de nuvem pode ser a resposta que você estava procurando.

A Audaz Tecnologia, com sua experiência em consultoria de TI e serviços de infraestrutura, está pronta para ajudar sua empresa a aproveitar estes benefícios.Portanto, agente uma reunião e descubra como podemos impulsionar sua transformação digital através dessa poderosa plataforma de orquestração de contêineres.

The post Desmistificando o Kubernetes: Uma visão abrangente sobre a orquestração de contêineres appeared first on Audaz Tecnologia.