A evolução da gestão de dados não depende apenas de uma mudança de mentalidade. Para sair de uma atuação predominantemente operacional e assumir um papel mais estratégico, o profissional também precisa transformar a forma como trabalha e as tecnologias que utiliza.
Durante muito tempo, administrar um banco de dados significava acompanhar indicadores, responder a alertas e intervir manualmente sempre que algum problema aparecia. Esse modelo pode funcionar em ambientes menores ou menos complexos, mas se torna cada vez mais limitado à medida que sistemas, volumes de dados, integrações e expectativas de disponibilidade crescem.
É nesse contexto que tecnologias como observabilidade, automação, Infraestrutura como Código (IaC) e práticas de Engenharia de Confiabilidade passam a ter um papel importante.
A mudança não acontece de uma única vez. Ela pode ser entendida como uma evolução em três camadas: Suporte, Sustentação e Sustentabilidade. No Suporte, a prioridade é responder ao que está acontecendo. Na Sustentação, o objetivo é tornar a operação mais previsível e confiável. Na Sustentabilidade, o olhar se amplia para decisões que precisam continuar fazendo sentido no longo prazo.
Do monitoramento à observabilidade
Uma das primeiras mudanças acontece na forma de enxergar o ambiente. No nível operacional, o monitoramento é fundamental para identificar situações que exigem atenção. Ele pode responder perguntas como:
- A CPU ultrapassou determinado limite?
- O disco está próximo da capacidade máxima?
- O número de conexões aumentou?
- Existe alguma instância indisponível?
- Uma query está demorando mais do que o esperado?
Esses indicadores são importantes porque ajudam a detectar eventos e reagir rapidamente. O problema é quando essa é a única visão disponível.
A observabilidade amplia essa perspectiva. Em vez de apenas identificar que algo está errado, ela ajuda a investigar por que aquilo está acontecendo e quais impactos o comportamento de um componente provoca no restante do ambiente.
Para isso, métricas, logs e rastreamentos (traces) podem ser analisados em conjunto. O comportamento do PostgreSQL pode ser relacionado, por exemplo, a um autovacuum mal configurado causando lentidão no sistema, ao inchaço inchaço (bloat) de tabelas após uma atualização na aplicação, ou então ao aumento inesperado de memória pela falta de um pooler de conexões, como o PgBouncer.
Ferramentas como Datadog, Prometheus e Grafana podem fazer parte dessa estrutura, mas a observabilidade vai além da adoção de uma ferramenta específica. Trata-se de construir uma visão integrada do ambiente. Essa mudança também aproxima a operação de outras dimensões do negócio. Um aumento de consumo de recursos não é apenas uma questão técnica: dependendo do ambiente, pode representar aumento de custos, impacto na experiência do usuário ou necessidade de rever uma decisão arquitetural.
A pergunta deixa de ser apenas: “O que quebrou?”. E passa a incluir: “Por que isso aconteceu, qual é o impacto e o que podemos aprender com esse comportamento?” Essa mudança de pergunta é fundamental para sair de uma atuação puramente reativa.
Automação e Infraestrutura como Código contra o toil
Outro obstáculo para a evolução do profissional é o excesso de trabalho manual e repetitivo. Na cultura de SRE, o termo toil é utilizado para descrever atividades operacionais manuais, repetitivas e sem valor duradouro, que tendem a crescer conforme o ambiente cresce.
Imagine, por exemplo, um profissional que precisa configurar manualmente um novo ambiente de PostgreSQL sempre que um projeto é criado. Ou que depende de scripts executados individualmente para realizar tarefas recorrentes de manutenção.
Na rotina de quem atua diretamente em um ambiente PostgreSQL, o toil pode ser identificado como: ter que executar reindex ou vacuum full manualmente durante a madrugada ou então ter que aplicar os mesmos ajustes de tuning no postgresql.conf e no pg_hba.conf a cada nova instância provisionada.
Enquanto essas atividades ocupam a maior parte da agenda, sobra pouco espaço para análise, planejamento e melhoria. É aí que entram automação e Infraestrutura como Código (IaC). Em vez de depender exclusivamente de comandos executados manualmente, o ambiente pode ser descrito em código e versionado. Tecnologias como Terraform e Ansible, por exemplo, permitem automatizar diferentes etapas da configuração e operação da infraestrutura. O benefício não está apenas em executar tarefas mais rapidamente.
A automação também contribui para:
- Reduzir intervenções manuais;
- Diminuir a possibilidade de erro humano;
- Padronizar ambientes;
- Facilitar a reprodução de configurações;
- Registrar alterações;
- Tornar processos mais previsíveis;
- Liberar tempo para atividades de maior valor.
A lógica muda de: “Preciso fazer isso novamente.” para: “Como posso fazer com que isso aconteça de forma confiável sem depender de uma nova intervenção manual?” Esse é um dos movimentos que caracterizam a passagem do Suporte para a Sustentação.
Do DBRE ao DSE: quando a engenharia encontra a estratégia
A automação e a observabilidade ajudam a construir uma operação mais confiável. Mas existe outro passo importante: incorporar práticas de engenharia ao gerenciamento dos bancos de dados. É nesse contexto que surge o Database Reliability Engineering (DBRE).
Inspirado pelos princípios de SRE, o DBRE aplica práticas de Engenharia de Confiabilidade aos ambientes de banco de dados. Isso pode envolver automação, observabilidade, testes, versionamento e integração com processos de desenvolvimento e entrega.
O banco deixa de ser tratado como uma caixa preta administrada separadamente e passa a fazer parte de um fluxo de engenharia mais amplo. Configurações podem ser versionadas. Alterações podem passar por revisão. Processos podem ser automatizados. Ambientes podem ser testados antes de chegar à produção. É uma mudança importante porque transforma a confiabilidade em uma característica construída pelo processo, e não apenas em algo que depende da experiência ou da intervenção manual de uma pessoa. Mas a evolução não termina no DBRE.
Quando a confiabilidade encontra o longo prazo
O Data Sustainability Engineer (DSE) parte dessa base tecnológica para ampliar novamente o campo de visão.
O DSE precisa compreender profundamente o banco de dados, mas também precisa considerar aspectos de arquitetura, automação, segurança, conformidade, cloud, custos e necessidades do negócio.
Uma decisão arquitetural, por exemplo, não deve ser analisada apenas pela capacidade de funcionar hoje. É necessário considerar como ela se comportará diante do crescimento esperado, quais recursos serão necessários, quais riscos serão introduzidos e qual será o impacto financeiro ao longo do tempo.
Imagine uma empresa que espera triplicar o volume de acessos nos próximos anos. A pergunta não é somente se o PostgreSQL atual suporta a carga de hoje. É preciso avaliar se a arquitetura escolhida consegue acompanhar esse crescimento, quais mudanças serão necessárias e quanto custará mantê-la. É nesse ponto que a interdisciplinaridade se torna essencial.
Tecnologia como meio para uma atuação mais estratégica
Observabilidade, automação, IaC e práticas de DBRE não existem apenas para modernizar o conjunto de ferramentas utilizado pelo profissional. Elas criam as condições para uma mudança maior: reduzir o tempo gasto reagindo ao presente e aumentar a capacidade de pensar sobre o futuro. A evolução pode ser resumida assim:
| Camada | Principal pergunta | Abordagem |
| Suporte | O que aconteceu? | Monitoramento e intervenção |
| Sustentação | Como evitar que isso volte a acontecer? |
Observabilidade, automação e confiabilidade |
| Sustentabilidade | Como garantir que o ambiente continue adequado no futuro? | Estratégia, arquitetura, eficiência e planejamento |
Isso não significa que uma camada substitui completamente a outra. Um ambiente sustentável continua precisando de monitoramento. Um profissional estratégico continua precisando conhecer profundamente a operação. A diferença está na capacidade de conectar essas dimensões e usar a tecnologia para ampliar sua atuação.
A evolução do DBA para o DSE, portanto, não acontece simplesmente pela adoção de novas ferramentas. Ela acontece quando tecnologia, processos e conhecimento técnico passam a ser utilizados para construir ambientes mais previsíveis, eficientes e preparados para acompanhar a evolução do negócio.
O próximo passo é ampliar o olhar
A tecnologia pode ajudar a tirar o profissional da rotina de intervenções manuais e criar espaço para uma atuação mais estratégica. Mas essa transformação também exige novas perguntas, novas competências e uma compreensão mais ampla sobre o papel dos dados dentro das organizações.
É justamente essa evolução que está por trás do conceito de Data Sustainability Engineer (DSE).
Quer entender como essa mudança se relaciona com a evolução da carreira de DBA e com a construção de ambientes de dados mais sustentáveis?
Leia o White Paper completo e aprofunde-se no conceito de DSE, nos pilares dessa transformação e nos caminhos para uma gestão de dados orientada ao longo prazo.