Fiabilidade e Monitorização

Um ano definido pela monitorização

A certa altura de 2015 as peças encaixaram. Tinha passado dois anos a aprender os ritmos do ambiente: a responder a alertas, a perseguir falhas, a ficar mais rápido no jogo reactivo. Depois, quase sem dar pela mudança, deixei de jogar esse jogo e comecei a desenhar a minha saída dele.

A mudança era simples de descrever e difícil de fazer: deixei de tratar a monitorização como um monte de sinais isolados e passei a tratá-la como um só sistema. Verificações de saúde dos servidores, fluxo de mensagens, replicação do Active Directory, conformidade do antivírus, validação de cópias de segurança, higiene do ActiveSync, monitorização das interfaces PI e SAP, painéis de baseline do SCCM — juntei tudo em algo coerente em vez de apagar fogos em cada um separadamente. Cada alerta, percebi, era uma história. Cada aviso recorrente era um sintoma a apontar para algo por baixo. Cada falso alarme era uma falha de desenho disfarçada. A monitorização deixou de ser ruído e passou a ser o mais perto que eu tinha de ver o sistema nervoso da fábrica inteira de uma só vez.

Um ponto de viragem na maturidade técnica

Depois chegou o Microsoft Premier Risk Assessment Program, e com ele uma forma diferente de ler um ecrã de diagnóstico. Eu andava a tratar as ferramentas como listas de erros. O RAP ensinou-me a tratá-las como indicadores arquitecturais. Porque é que há latência de replicação aqui? Porque é que continuam dispositivos dormentes no AD? Porque é que as filas do Exchange acumulam sempre nos mesmos dias? Porque é que o mesmo punhado de servidores continua a falhar a conformidade de patches?

Aquilo já não eram pedidos de suporte. Eram perguntas com causas raiz, e o RAP obrigou-me a ir à procura das causas em vez de despachar a fila. Algures nessa mudança formou-se-me uma frase na cabeça que nunca mais larguei: a fiabilidade não se atinge a resolver problemas, atinge-se a eliminar as razões pelas quais os problemas existem. Ainda não sabia, mas essa frase foi o primeiro tijolo de uma cabeça de arquitecto.

Construir fiabilidade proactiva

Por isso deixei de esperar. Passei a caçar: servidores com falhas recorrentes de patching, alterações de firewall com raio de impacto escondido, certificados a contar caladamente para a validade, limiares de monitorização inconsistentes, serviços do Exchange mal configurados, permissões que ninguém se lembrava de ter dado, dispositivos ainda a ligar para casa em contas de pessoas que tinham saído da empresa meses antes.

Ninguém me pediu para construir as folhas de controlo e os pequenos scripts que me deixavam andar à frente de tudo isto. Construí-os na mesma, porque nessa altura já percebia o que estava em jogo de uma forma que não percebia ao início: numa fábrica destas, uma falha de TI não é um incómodo. Pode travar planeamento, documentação de segurança, trabalhos de manutenção, acesso de empreiteiros — o ritmo operacional inteiro, por causa de algo que começou como um patch falhado.

Higiene de infra-estrutura

A lista sem glamour é longa: limpeza do AD, análise de bloqueios de conta, monitorização do relay SMTP, validação de DFS, gestão de certificados SSL, afinação de fronteiras e colecções no SCCM, controlo de licenciamento, ciclo de vida das tapes de backup, definições de antivírus, investigações de malware, registos do IIS, baselining de servidores. Nada disto fotografa bem. Tudo isto é a razão pela qual nada de dramático aconteceu: nenhum incidente de segurança, nenhuma perda de dados, nenhuma paragem de autenticação, nenhuma interrupção de mensagens, nenhum desvio de conformidade, nenhum atraso de produção rastreável a algo que devia ter sido apanhado. A previsibilidade não se anuncia. Limita-se caladamente a ser a fundação em que tudo o resto assenta.

Fluência interdisciplinar

Nesse ano também fiquei melhor nos problemas dos outros: SAP Basis, administradores de PI, redes e telecomunicações, suporte aplicacional, segurança e conformidade. Quando o SAP abrandava, aprendi a verificar ligações de subsistema de confiança, contas de AD, DNS, certificados, disputa de recursos e dependências de mensagens antes sequer de alguém perguntar. Quando o PI tinha um problema de ingestão, ia directo aos serviços de recolha, quebras de rede, congestão de disco, patches recentes, histórico de reinícios de serviço.

Nessa altura já não estava a resolver problemas de TI. Estava a aprender como os sistemas se apoiam uns nos outros através das fronteiras de domínio. E essa fluência, mais do que qualquer outra coisa em 2015, assentou a primeira fundação real da forma como viria a pensar como arquitecto.

Comunicação como credibilidade

As competências não técnicas amadureceram ao lado das técnicas, e deixei de as tratar como coisas separadas. Explicar o problema em linguagem simples. Dar conta do progresso antes de alguém ter de perguntar. Dizer porque é que algo importa, não apenas o que está a acontecer. Nomear o risco. Recomendar a solução antes de ser pedida. Assumir o resultado mesmo quando a causa raiz não era minha à partida.

Nada disso era opcional, aprendi. A correcção técnica sozinha não constrói confiança. A clareza e a calma constroem. Essa lição acabou por importar tanto como tudo o que aprendi sobre Exchange ou Active Directory nesse ano.

2015 numa frase

Entrei capaz de resolver as coisas depressa. Saí convencido de que resolver as coisas depressa é um sintoma.