DBAs, um sacerdócio não mais

Nota: Este post de engenharia foi escrito por nossa DBA, Silvia Botros e apareceu originalmente no Sysadvent Blog em dezembro de 2016.

As empresas têm e precisam de Administradores de Banco de Dados há anos. Os dados são um dos ativos mais importantes de uma empresa. Isso significa que muitas empresas, uma vez que crescem a ponto de serem capazes de escalar rapidamente, precisam de alguém para garantir que o ativo seja bem gerenciado, com desempenho para as necessidades do produto e disponível para restauração em caso de desastres.

Em um sentido tradicional, o trabalho do DBA significa que ele é a única pessoa com acesso aos servidores que hospedam os dados, a pessoa para criar um novo cluster de banco de dados para novos recursos, a pessoa para projetar novos esquemas e a única pessoa a ser contatada quando qualquer coisa relacionada ao banco de dados quebrar em um ambiente de produção.

Como os DBAs tradicionalmente têm funções tão exclusivas, seu tempo é precioso, torna-se mais difícil pensar em uma visão geral quando as tarefas do dia-a-dia sobrecarregam. É típico recorrer a ferramentas frágeis como o bash para todos os tipos de tarefas operacionais na área de DBA. Precisa de uma nova configuração de banco de dados de uma instalação limpa do sistema operacional? Fazer, validar ou restaurar backups? Girar partições ou dados obsoletos? Quando a ferramenta mais usada é o script bash, tudo parece um prego. Tenho certeza de que muitos leitores estão preparando tweets para me dizer o quão poderoso é o bash, mas, por favor, segure seu comentário até depois de avaliar meu raciocínio.

Tudo isso soa como a descrição do seu trabalho como DBA? A descrição do trabalho fala em detalhes sobre atualização de servidores, criação e teste de backups e monitoramento? A maioria das postagens de trabalho de DBA típicas garantirá que você tenha que configurar e configurar 'vários' servidores de banco de dados (porque a expectativa é que os DBAs os criem manualmente) e automatizar tarefas de gerenciamento de banco de dados com scripts (feitos à mão).

Essa é realmente uma abordagem escalável para o que geralmente é uma equipe de um em uma organização em crescimento e em ritmo acelerado?

Estou aqui para argumentar que seu trabalho não é realizar e gerenciar backups, criar e gerenciar bancos de dados ou otimizar consultas. Você fará todas essas coisas durante o seu trabalho, mas o objetivo principal é tornar os dados da sua empresa acessíveis e escaláveis. Isso não serve apenas para a empresa executar o produto atual, mas também para criar novos recursos e fornecer valor aos clientes.

Por que

Você pode querer perguntar, por que eu faria tudo isso? Há um argumento para continuar a executar o papel de DBA tradicionalmente: segurança no trabalho, certo? Muitas organizações de tecnologia hoje em dia fazem um ou mais dos seguintes:

• Eles são formados por muitas equipes menores
• Eles fornecem recursos criando muitos microsserviços no lugar de um ou alguns serviços maiores
• Eles adotam metodologias ágeis para acelerar a entrega de recursos
• Eles combinam operações e engenharia sob uma liderança
• Eles incorporam engenheiros de operações aos desenvolvedores o mais cedo possível no processo de design
• Um silo de DBA dentro das operações significa que a equipe de operações tem menos poder para ajudar a depurar problemas de produção em sua própria pilha, às vezes é incapaz de responder e corrigir problemas sem assistência e, francamente, menos confiável em exigir colaborações mais próximas e anteriores com as equipes de engenharia, se forem não praticando o que eles pregam dentro da Tech Ops.

Então, o que pode ser feito para quebrar esse silo e facilitar a depuração de outras pessoas, ajudar a dimensionar a camada de banco de dados e capacitar os engenheiros a projetar serviços que possam ser dimensionados? A maioria das lojas emergentes tem no máximo um DBA interno. O único DBA pode estar 'presente' em todas as reuniões de projeto, aprovar todas as mudanças de esquema e estar de prontidão para uma base de dados cada vez maior e extensa?

DBAs não podem mais ser gatekeepers ou mágicos. Um DBA pode e deve ser uma fonte de conhecimento e experiência para engenheiros em uma organização. Ela deve ajudar as equipes de entrega não apenas a entregar recursos, mas a entregar produtos que escaláveis ​​e capacitá-los a não temer o banco de dados. Mas como um DBA pode conseguir isso enquanto faz o trabalho diário de gerenciar a camada de dados? Existem várias maneiras de você, o DBA, se preparar para a excelência.

Gerenciamento de configurações

Este é um muito importante. Os DBAs tendem a preferir ferramentas antigas como o bash para configuração de banco de dados. Eu aludi a isso anteriormente e não tenho nada contra o uso do próprio bash. Eu uso muito, na verdade. Mas não é a ferramenta certa para configuração de cluster. Especialmente se o resto das operações NÃO estiver usando o Bash para gerenciar o resto da arquitetura. É verdade que os engenheiros de operações também conhecem o Bash, mas se eles estão gerenciando o resto da infraestrutura com uma ferramenta como Chef ou Puppet e os bancos de dados são gerenciados principalmente por scripts feitos à mão escritos pelo DBA, você está impondo uma obstrução para eles fornecerem ajuda quando uma mudança urgente é necessária.

Mais ainda, torna-se mais difícil ajudar as equipes de engenharia a se auto-atender e a criar os novos clusters necessários para o novo recurso 'foo'. Você se torna o 'bloqueador' para concluir o trabalho. Familiarizar-se com o gerenciamento de configuração em sua empresa também é um benefício de mão dupla. À medida que você se familiariza com a forma como a infraestrutura é gerenciada, você conhece os padrões da equipe, fica mais familiarizado com a pilha e pode colaborar em mudanças que afetam a escala do produto.

Um DBA que está sintonizado com o produto e a infraestrutura da organização de engenharia como um todo é inestimável.

Runbooks

Este é tecnicamente um subconjunto da documentação que você precisa escrever, mas na minha experiência provou ser muito mais útil que eu sinto que deve ser apontado separadamente. Quando digo runbooks, estou dizendo especificamente um documento escrito para um público que NÃO é um DBA. Há muitos problemas de banco de dados de produção que podemos encontrar como DBAs que são simples de depurar e resolver. Nós tendemos a subestimar essa memória muscular e caímos no padrão de 'apenas me mande a página' e 'cuidamos das coisas'.

Se sua equipe de operações é como a minha, onde você é o único DBA, provavelmente significa que outra pessoa da equipe é a primeira linha de defesa quando um evento relacionado a um banco de dados é paginado. Alguma documentação simples sobre como fazer a depuração inicial, a coleta de dados, pode ajudar bastante o restante da equipe de operações a se sentir confortável com a camada de banco de dados e mais familiarizada com a forma como a monitoramos e depuramos. Mesmo que esse evento ainda resulte na paginação do DBA, lenta mas seguramente, o runbook se torna um lugar para que todos possam adicionar o conhecimento adquirido.

Além disso, adiciono um link para a seção de runbook relacionada (use âncoras!) às descrições de página que vão para o pager. Isso é incrivelmente útil para alguém que está sendo chamado por um host de banco de dados às 3 da manhã para encontrar um ponto de partida. Essas coisas podem parecer pequenas, mas, na minha experiência, elas percorreram um longo caminho para quebrar as barreiras mentais para minha equipe de operações que trabalha na camada de banco de dados quando necessário.

Como preferência pessoal, eu os escrevo como documentos de remarcação dentro dos meus repositórios de livros de receitas do chef. Isso se enquadra perfeitamente em um padrão de solicitação pull, revisão e mesclagem, e se torna parte integrante do padrão de livros de receitas dos bancos de dados. À medida que as equipes de engenharia começam a criar seus próprios, os runbooks se tornam um modelo familiar à medida que novos clusters de banco de dados surgem em todos os lugares.

Visibilidade

Nós gostamos de nossas telas de terminal. Nós os amamos. As ferramentas mais populares na terra do MySQL ainda são ferramentas de terminal que vivem diretamente nos hosts db e que precisam de conhecimento prévio sobre eles e como usá-los. Estou falando de coisas como innotop e o shell do MySQL. Estes são bons e ainda úteis, mas são criados para DBAs. Se você não quer ser o guardião de perguntas como “há atraso de replicação agora?” você precisa ter ferramentas melhores para tornar a integridade de qualquer cluster, agora e historicamente, disponível e fácil de digerir para todos os membros da equipe. Tenho alguns exemplos nesta arena:

Orquestrador

Usamos réplicas de leitura para distribuir essa carga para longe do primário, o que significa que quando o atraso atinge um determinado limite, ele se torna um evento de suporte ao cliente. É importante tornar mais fácil para qualquer pessoa na empresa saber a qualquer momento se algum cluster está com atraso, quais servidores estão nesse cluster e se algum dos hosts está inativo. O Orchestrator é uma ótima ferramenta nesse sentido, pois faz a visualização de clusters e sua integridade a uma janela do navegador de distância.

Grafana/Grafite

As métricas da camada de banco de dados precisam estar no mesmo local em que as métricas do restante da infraestrutura estão. É importante que a equipe consiga justapor essas métricas lado a lado. E é importante ter uma maneira fácil de ver as métricas históricas de qualquer cluster de banco de dados. Embora você possa ter uma preferência pessoal por cactos ou munin, ou modelos artesanais que você escreveu ao longo dos anos, se as métricas que você usa para investigar problemas não estiverem no mesmo lugar que o restante das métricas de infraestrutura, isso cria uma barreira para outros engenheiros ocupados – e eles estarão menos inclinados a usar suas ferramentas do que aquelas que estão em uso em outro lugar. O Graphite é amplamente utilizado para ingestão de métricas em equipes de infraestrutura modernas, e o Grafana é um front-end de painel amplamente usado para métricas e análises.

Desempenho da consulta

Usamos o VividCortex para rastrear nossas consultas em clusters críticos e, embora este artigo não pretenda ser um anúncio de um serviço pago, direi que você precisa verificar o efeito de implantações e alterações de código na execução de consultas e desempenho de consulta algo que não precisa de acesso especial aos logs e processá-los manualmente. Se o VividCortex não for uma possibilidade (embora, sério, eles sejam incríveis!), existem outros produtos e ferramentas de código aberto que podem capturar apenas o log lento e colocá-lo em uma página da Web fácil de ler para não-DBAs inspecionarem e veja o efeito de seu código. O ponto importante aqui é que, se você fornecer os meios para ver os dados, os engenheiros usarão esses dados e farão o possível para manter as coisas eficientes. Mas faz parte do seu trabalho disponibilizar esse acesso e não um truque especial do DBA.

Combata a fadiga do pager

Muitas organizações não incluem o dimensionamento da camada de banco de dados como um imperativo inicial em seu design de pilha – e não deveriam. Nos primórdios de uma empresa, você não deve se preocupar em como irá limitar as chamadas de API se ninguém estiver usando a API ainda. Mas é apropriado considerar alguns anos depois, quando o produto ganhou força, e aquela chamada de API que estava atingindo uma tabela de alguns milhares de linhas por um punhado de clientes agora é uma tabela de vários milhões de linhas e alguns clientes construíram cron jobs que inundam essa API todas as manhãs às 6 da manhã no seu fuso horário.

É preciso muito trabalho para alterar a camada de aplicativo de qualquer produto para proteger a infraestrutura e, nesse ínterim, permitir que atividades espúrias do banco de dados causem fadiga do pager é um grande perigo para você e para o restante da organização de operações. Familiarize-se com ferramentas como pt-kill, que podem ser usadas rapidamente para evitar que um host de banco de dados tenha um grande tempo de inatividade devido ao volume não planejado. Divulgue o uso dessa ferramenta e comunique a ação e seu efeito à equipe de engenharia da participação, mas não é saudável tentar absorver a dor de algo que você não pode mudar diretamente e, em última análise, não será benéfico ajudar as equipes de engenharia ' aprenda a lidar com as dores do crescimento.

Há muitas maneiras pelas quais o trabalho de um DBA é exclusivo para seu papel em comparação com o resto da equipe de operações, mas isso não significa que tem que ser um sacerdócio mágico que ninguém pode se aproximar. Essas etapas ajudam bastante a tornar seu trabalho transparente, mas o mais importante é abordar seu trabalho não como um guardião de um jardim dourado de host de banco de dados, mas como um especialista no assunto que pode fornecer conselhos e ajudar a desenvolver os engenheiros com quem você trabalha e fornecer mais valor para os negócios do que os backups e o ajuste de consultas (mas também são divertidos!).

Agradecimentos especiais à maravilhosa equipe de operações da Sendgrid, que continua a me ensinar muitas coisas, e aos Charity Majors por cunhar o título deste post. E confira mais posts sobre DBAs aqui.