Gabriel
Philippi.

O processo de atualização exigia edição manual de configurações e execução de comandos por ambiente, com 30 a 45 minutos de atuação operacional por atualização.

• Reestruturação do Puppet Server para configuração de aplicações e versões por node.
• Versionamento da configuração e execução de atualizações a partir de alterações no Git.
• Descoberta dos servidores de destino com Puppet Bolt e suporte a múltiplos ambientes.
• Criptografia de segredos com hiera-eyaml e rotação das credenciais abrangidas.

Fluxo de autoatendimento utilizado em mais de 180 PRs de atualização fechados no período documentado, retirando a execução manual de comandos da rotina de atualização.

O provisionamento completo envolvia tarefas em dois provedores e levava de 1h a 1h45 por ambiente, incluindo coleta e transferência manual de informações.

• Automação de registros DNS e validação de certificados entre Route 53 e Azure Front Door.
• Coleta de endpoints e preparação de credenciais em um painel Python.
• Renovação de certificados e suporte à substituição de registros durante migrações.
• Permissões restritas às operações necessárias. Criação de Terraform e inclusão no GitOps mantidas como etapas separadas.

Economia de pelo menos 45 minutos por ambiente, com utilização registrada em 10 a 20 ambientes.

Uma migração apresentava arquivos inacessíveis e mensagens de erro de autenticação, embora o bloqueio estivesse relacionado à classe de armazenamento na origem.

• Análise dos logs de transferência e identificação do comportamento da cópia server-to-server.
• Validação da política de lifecycle e do estado de restauração dos objetos.
• Cruzamento do inventário completo para verificar a relação entre tamanho e classe de armazenamento.
• Documentação do procedimento de restauração em lote e retomada da transferência.

Mais de 200 mil objetos identificados como ausentes no destino. Causa validada em um inventário superior a 1 milhão de objetos, com procedimento de recuperação documentado.

Incidentes em aplicações e hosts exigiam análise além das métricas tradicionais de CPU e memória. Parte das investigações ocorreu após o encerramento dos processos afetados.

• Desenvolvimento de coletor de métricas de cgroup para acompanhar o uso de recursos por container.
• Correlação de logs do systemd, séries do sar e métricas históricas para diagnóstico de pressão de memória.
• Scripts Bash para capturar stacks de workers PHP e chamadas de sistema com timestamps.
• Uso de phpspy, strace e gdb para investigar bloqueios e loops em aplicações.

O coletor acumulou mais de 1 milhão de amostras e apoiou a análise de um incidente em cerca de 30 ambientes de homologação. Em outra investigação, a causa de falhas intermitentes recorrentes havia mais de seis meses foi confirmada em quatro dias.