RiskNow: arquitetura de Lakehouse e monitoramento de portfólio

Contexto

Monitoramento de portfólio é um produto de dados com um problema de operações acoplado: a análise vale o que vale o pipeline atrás dela, e o pipeline vale o que vale o processo de implantação e suporte ao redor.

Problema

Produto, arquitetura de dados e operações eram decididos em separado, que é como um release vira incidente: uma mudança de schema entra, o ELT degrada em silêncio e o suporte descobre antes do roadmap.

Abordagem

Liderei o produto de monitoramento de portfólio e todas as operações de implantação e manutenção em torno dele. Isso significou desenhar a arquitetura de Data Lake, Warehouse e Lakehouse que alimentava o produto, os modelos de rollout pelos quais um release chegava ao cliente e a melhoria contínua dos processos de ELT e de suporte como um único ciclo, e não como três backlogs.

Decisões não-óbvias

• Separar lake, warehouse e lakehouse pela forma como o dado é lido, e não pela forma como ele chega. O formato de ingestão é a coisa menos estável do sistema e o pior princípio organizador disponível.
• Desenhar rollout como modelo, não como data. Liberar em etapas por segmento de cliente, com caminho de rollback, é o que permite um produto mudar sem gerar um incidente por release.
• Alimentar o roadmap diretamente com as falhas de suporte e de implantação. O volume delas é o sinal de produto mais honesto disponível e não custa nada para coletar.

Resultado

O produto de monitoramento de portfólio rodou sobre uma arquitetura desenhada para como ele era lido, foi liberado por modelos de rollout em etapas com caminho de rollback e evoluiu continuamente a partir dos modos de falha que o próprio ELT e o suporte expunham.