Fala galera!
Nesta série iremos discutir sobre o que um Database Reliability Engineer faz, quais as diferenças dessa função para o DBA tradicional e o papel que ele desempenha dentro de times de engenharia de confiabilidade ou SRE.
Muito do que será discutido aqui tem haver com minha experiencia de mercado e as práticas discutidas nos livros SRE do Google e DBRE, deixarei as referencias no final de cada post.
Práticas SRE
O livro Database Reliability Engineer dos autores Laine Campbell e Charity Majors descreve já no capitulo introdutório certos principios que todo DBRE deveria práticar, esses são:
- Proteção de Dados
- Padrões para Ganho de Escala
- Eliminação de Tarefas Repetitivas (Toil)
- Tratar os servidores de bancos de dados mais como gado e menos como pet
- Aproximação entre Software e Operações (DevOps)
- Operação como Core dentro dos times de engenharia
- Declaração de Prioridades
- Seguro e Funcionando em primeiro lugar, depois vem a Escalabilidade
- Invista no empoderamento dos times e não em Guard Rails
- Observabilidade e Estrumentação
- Auto remediação (Self-Healing ou Self-Actualization como esta no livro)
Vou tentar ser objetivo em cada tópico, resumindo em poucas palavras.
Proteção de Dados
Uma das primeiras coisas que todo DBA em inicio de carreira aprende é como efetuar Backup e Restore de um banco de dados, logo, uma das primeiras coisas que aprendemos é que todo bom ambiente precisa ter uma rotina de backup implementada e ajustada às necessidades de negócio, com RTO e RPO bem definidos. Raro de ver, mas quando vemos um ambiente que efetua Restores constantes é coisa linda de ver.
Outras questões que tocam em proteção são um bom processo de concessão de acessos que de preferencia não permite a criação de usuários nominais no banco de dados, ferramentas que apoiam na concessão de acessos, criando usuários temporários no banco de dados apenas quando necessário. Processos de auditoria implementados são importantes aqui para auxiliar em momentos de troubleshooting junto da área de Sec.
Processo de mudança, controle de configuração e um CMDB bem atualizado e detalhado podem evitar dores de cabeça.
Padrões para Ganho de Escala
No mundo OnPremise automatizar a criação e gestão de infraestrutura pode ser bem complexo dado a característica diversa de hardwares, softwares e afins. Já no mundo Cloud isso não acontece pois as plataformas abstraem a camada de hardware e software e te entregam uma interface facilitada para criação de infra.
Dado este cenário de Cloud, ter padrões pode te ajudar muito no dia a dia, como padrões de nomenclatura, tags, configurações, capacity, ambientes e afins. Quando eu vejo um ambiente bem padronizado fica fácil de identificar os ambientes e até mesmo construir automações e infraestruturas escaláveis dado a facilidade com que identificamos nossa infraestrutura e a entregamos para a camada de sistemas.
Eliminação de Tarefas Repetitivas (Toil)
Se você trabalha em ambientes pequenos, talvez não veja necessidade de automatizar tarefas maçantes, já para quem tem que lidar com dezenas, centenas e até milhares de instancias de bancos de dados, ainda mais em um ambiente que possui escalabilidade horizontal de instancias terá problemas graves se não construir automações.
Essas automações começam ao agendar tarefas administrativas como Reindex e Update Statics\Analyze, passando por extração de dados do ambiente e até a escalabilidade de replicas de leitura para atender a alta demanda das aplicações em determinados momentos do dia.
Creio que todo DBA aprende intrinsecamente a automatizar suas tarefas, dado que certos procedimentos acabam impactando a performance sistêmica das aplicações e precisam ser feitas fora do horário comercial, logo, para não ter que ficar gastando tempo de folga executando rotinas na mão, automatizar este tipo de trabalho é primordial.
Pet vs Catle
Quem nunca quis colocar ou até colocou um nome de Transformers, Vingadores ou Pokemons em seus servidores? Pois é, eu vejo isso até hoje!
Após o nascimento das Clouds e o avanço da virtualização, criar e apagar infraestruturas ficou cada vez mais comum, logo, ter padrões como falamos num tópico anterior é essencial bem como infraestrutura como código, versionada e armazenada em um repositório Git, que é provisionada por uma pipeline tornou-se cada vez mais comum, principalmente para infras distribuídas e que necessitam escalar.
Cada vez mais vemos opções de bancos de dados distribuídos nascendo, seja dentro dos provedores de Cloud ou fora e que oferecem escalabilidade horizontal de verdade, seja sobre Bare Metal, IaaS ou Kubernetes. Dado este cenário, utilizar o conceito de tratar maquinas como gado, que é algo que já acontece com maquinas de aplicação, também poderá ser utilizado para ambientes de bancos de dados.
Vale lembrar que essas novas tecnologias de bancos de dados distribuídos funcionam com replicação de dados em larga escala e com baixa latência, aonde podemos ter mais de um node de um cluster recebendo tanto leitura como escrita e o mesmo resolve conflitos internamente com sucesso. Logo, a aplicação deste conceito para ambientes de bancos de dados será cada vez mais comum onde existir ambientes com apetite por alta escalabilidade com alta disponibilidade.
Aproximação entre Software e Operações (DevOps)
Quanto mais o tempo passa, mais vemos o profissional de T.I. mudando, principalmente o profissional de operações, pois, este, que sempre esteve mais ligado ao hardware, servidores, datacenters e afins viu seu mundo virar código e ser abstraído pelas Clouds. Isso quer dizer que o profissional de operações\infra irá morrer? Claro que não, mas uma coisa é fato: se este profissional não aprender a codificar e se acostumar a transformar sua infraestrutura em código provavelmente irá perder boas oportunidades em boas empresas.
Esse contexto também vale para os DBA’s tradicionais, mas acredito que para este mundo as mudanças não afetarão tanto pois o DBA já tende a estar proximo do desenvolvedor, otimizando sistemas a partir da camada do banco de dados. Todo sistema que armazena dados precisa executar queries, logo, um bom DBA tende a lidar de forma sistêmica e pelo menos com a linguagem SQL, que é o seu core.
O que irá diferenciar os DBA’s tradicionais dos DBRE’s serão as práticas do mundo DevOps, como: Infra As Code, gestão de configuração, observability na camada do banco de dados, coleta de métricas e traceability para rastreabilidade, centralização de logs (Principalmente para ambientes distribuídos), automação além do SQL com linguagens como Python e GO, lidar com ambientes gerencias em Cloud Publica, implementação de Auto Healing, pipelines de infraestrutura e migration, testes, entre outras práticas que vem do mundo de desenvolvimento e DevOps.
Verdade seja dita, mesmo antes do termo DevOps surgir, DBA’s já construíam automações, seja por shell scripts ou PowerShell e até mesmo SQL, principalmente aqueles que precisavam lidar com ambientes médios a grandes. Ter um DBA dentro de uma empresa muitas vezes é visto como luxo, pois são recursos considerados caros e apenas são considerados necessários quando problemas de escala já estão acontecendo, com os DBRE’s não será diferente, logo, saber lidar tanto com o mundo tradicional de operações ao qual o DBA já existia unindo às práticas novas de automação levará a atingir outro patamar na carreira.
Operação como Core dentro dos times de engenharia
No item anterior falei muito sobre o perfil Ops do DBA e como o profissional de operações precisa lidar com o mundo novo e saber codificar, pois bem, o oposto também é verdadeiro.
Acho legal certos termos como: “You Build It, You Run It”. Ou literalmente, você desenvolve, você sustenta. Na teoria parece algo que faz muito sentido, unir desenvolvimento e operações com o intuito de entregar seus produtos de software com a melhor experiencia possível para seus clientes.
Na prática ja vi times de engenharia serem formados com este intuito, os times que deram certo viraram referencia de entrega de software, muito mais robustos, com menos problemas indo para produção, com muito mais agilidade. Mas a realidade é que a maioria dos demais times tiveram dificuldade, por que? Simples, culturalmente o desenvolvedor tende a não se preocupar muito com a infraestrutura ou operações por que entende que há áreas\pessoas especializadas para tal, logo, na maioria dos casos, engenheiros de software terão menos afinidade e menos interesse em desenvolver hard skills de operações.
Quanto mais eu convivo dentro de áreas de SRE mais eu vejo a necessidade de esta função ser muito mais ligada a engenharia de software do que operações em si, porém, se já esta difícil conseguir bons desenvolvedores para entregar apenas software, tão mais difícil será encontrar no mercado engenheiros de confiabilidade com bases fortes nas duas pontas.
Acredito que isso apenas mudará com o investimento pesado das empresas em: primeiro – desenvolver sua própria cultura SRE e segundo – formando seus próprios engenheiros de confiabilidade. Mas aonde o DBA entra nisso tudo? Para um DBA se tornar um DBRE ele terá que ir além da camada de banco de dados, conhecendo mais sobre arquitetura de software, cloud computing, escalabilidade, disponibilidade e práticas DevOps, quanto mais ele estiver próximo de como as aplicações funcionam, mais ele entenderá qual a melhor ferramenta para um determinado cenário serviço ou software.
Declaração de Prioridades
Aqui não irei me prolongar pois é algo obvio: se você entrega ambientes de bancos de dados para sistemas e não se preocupa na entrada com backup, lifecycle dos dados (expurgo), gestão de configuração, monitoração e segurança, logo, seu ambiente esta em risco e consequentemente errado.
Existem certas prioridades no funcionamento de bons ambientes de bancos de dados que não podem ficar para depois, caso isso aconteça provavelmente você terá um problema grande por negligenciar estas atividades, logo, nenhuma prioridade deverá ser maior do que as descritas acima.
Seguro e Funcionando em primeiro lugar, depois vem a Escalabilidade
Distribuir dados? Particionamento de tabelas? Escalabilidade Horizontal? Sharding? Todas essas técnicas podem melhorar muito a disponibilidade e performance das aplicações, mas de adianta ter todas essas coisas se não tivermos um procedimento de backup bem montado com múltiplas copias dos dados, se não fazemos testes de restore, replicar os dados por múltiplas localidades e ter um failover seguro podem diminuir muito a chances de corrupção de dados e aumentar a garantia e consistência destes.
Pensar em escalabilidade no dia 0 pode ser um erro pois muitas vezes não se tem a real visibilidade do quão rápido um sistema ou serviço podem crescer no tempo, por conta disso pense simples: garanta backup, replicação de dados e um ambiente alto disponível.
Invista no empoderamento dos times e não em Guard Rails
A cultura DevOps traz à luz a colaboração entre desenvolvedores e operadores, simples assim, logo, o DBRE deve investir em conhecimento das equipes de desenvolvimento e infraestrutura para que em conjunto possam construir sistemas melhores, com as melhores práticas.
A colaboração leva a perfeição (ou o mais perto dela), trabalhando de forma colaborativa cada vez menos teremos a necessidade de inserir mecanismos de controle como guard-rails para impedir que façam coisas erradas nos ambientes.
Utilizar práticas modernas como a utilização de Infra-as-code auxilia neste processo pois coloca a disponibilização de ambientes de bancos de dados mais próxima do processo de desenvolvimento de software pois torna a infraestrutura em código e possibilita testes e outras boas práticas de desenvolvimento de software.
Observabilidade e Estrumentação
Todo ambiente sistêmico precisa ser monitorado, isso é um fato, mas como podemos ir além da monitoração? Simples, com observability e um bom APM (Application Performance Managament).
Observability te da a capacidade de enxergar uma infinidade de pontos de seus sistemas baseado em diversas métricas, o mais importante aqui é conseguir identificar e criar alertas que te avisem sobre problemas que estão acontecendo e também o comportamento que estão tomando, com isso você ganha a um poder de resposta e predição de problemas, atuando antes que uma degradação ou paralização aconteça, impactando assim a disponibilidade de seu ambiente.
Instrumentalizar seu sistema o auxilia a ter tempestividade para encontrar o RCA (Root Cause Analysis) de um determinado problema que esteja acontecendo. Falamos em tempestividade pois a visibilidade tanto da integração entre os sistemas como da comunicação interna entre os componentes da infraestrutura fica muito mais clara e gráfica, diminuindo muito o tempo de analise e identificação de um problema e aumenta a assertividade nas ações de resolução deste.
A instrumentalização também traz a capacidade de inserir feature flags e outros mecanismos que dão a capacidade de ligar e desligar funcionalidades de seu sistema como a utilização de replicas de leitura de um banco de dados, por exemplo.
Ter uma KB (Knowledge Base) bem construída com procedimentos minimamente bem descritos pode ajudar os times a atuar sem a necessidade de um DBA, como times de operação por exemplo e desta forma o DBRE consegue continuar atuando em melhorias e automações que melhorem ainda mais a disponibilidade dos ambientes de bancos de dados.
Auto remediação
A capacidade de se auto regenerar de um problema é uma capacidade que poucos tem, para sistemas e infraestrutura não é diferente. Construir sistemas que conseguem contornar adversidades de forma automática é uma arte que pouco se vê ainda em tempos atuais e que as grandes de tecnologia procuram incessantemente.
Investir em automação de verdade, indo além do script, trabalhando em conjunto com os sistemas citados anteriormente como APM’s, Observabilidade, CMDB e outros podemos desenvolver mecanismos que aprendem com as mudanças de comportamento constantes que acontecem durante a utilização dos softwares para tomadas de decisão cada vez mais precisas, transformando ambientes de bancos de dados cada vez mais resilientes e robustos.
Chegar até aqui envolve uma grande maturidade e conhecimento do sistema administrado, da stack que esta executando as aplicações, desta forma, o desenvolvimento de uma auto remediação deve ser considerado apenas após a estabilização e experiencia adquiridas no tempo.
Conclusão
Bom gente, chega ao fim aqui este resumo do primeiro capitulo do livro sobre os pontos que estão descritos direta ou indiretamente neste, meu intuito aqui é tentar trazer um pouco do meu dia a dia atuando nesta função que não é muito diferente de um DBA tradicional mas que vejo muitos DBAs não conhecendo muitas dessas práticas descritas acima.
Se você já atua assim mas não se considera um DBRE, não tem problema, é mais uma buzz word neste mundo infinito de jargões tecnológicos. Se ficaram com alguma dúvida ou se gostariam de discutir algum ponto acima, fiquem a vontade de colocar um comentário ou enviar um e-mail que terei o prazer imenso de responder.
Este ano serei muito mais frequente aqui no blog, então fique ligado(a)!
Vlw galera! Até o próximo post!
codedataops.com 