Como evitar uma queda não planejada por upgrade
Migrar os sistemas do seu negócio para a nuvem traz inúmeros benefícios. Uma das principais vantagens de adotar um serviço gerenciado é eliminar a necessidade de manter o serviço sobre a infraestrutura própria, com recursos técnicos internos e processos operacionais já consolidados. Em troca de uma taxa, você aproveita o conhecimento e a experiência coletivos do provedor. Há vários pontos positivos em usar um serviço gerenciado de banco de dados, como segurança, alocação de recursos e integração de funcionalidades.
Este artigo trata de um recurso disponível em vários serviços de provedores de nuvem que, à primeira vista, parece um ganho fácil para a manutenção rotineira. Só que ele tem um custo capaz de causar estragos no seu negócio: uma queda crítica e um cenário de desastre para o qual ninguém está preparado, justamente porque os recursos técnicos e o conhecimento de uma implementação self-hosted anterior não existem mais.
Esse recurso é a atualização automática de versões minor.
Por que upgrades de produto são importantes?
Cada organização tem processos e controles próprios, construídos ao longo de anos de experiência, com produtos e ferramentas internas únicas para a sua operação. Esses processos podem ser muito robustos, razoáveis ou frágeis. Usar um serviço gerenciado pode passar uma sensação de estabilidade e maior capacidade operacional, mas isso não elimina a necessidade de testes. A nuvem, os serviços gerenciados, a automação, o IaC e os frameworks não eliminam a necessidade de uma boa gestão de processos.
O banco de dados é um componente crítico em todo negócio. Não é o único componente vital, mas, em muitas organizações, ficar sem um banco funcionando representa um risco com impacto enorme na capacidade de operar.
Com o tempo, todo produto passa por descontinuação de funcionalidades e sintaxes, avisos de fim de vida e patches de segurança. Essas mudanças exigem manutenção contínua da infraestrutura que sustenta as suas aplicações. As atualizações chegam na forma de upgrades minor e atualizações major. Trate os dois tipos como equivalentes em termos de risco para o negócio.
Um upgrade minor sem testes pode derrubar o seu sistema em produção.
O método padrão de upgrade dos serviços gerenciados
Muitos serviços de diferentes provedores de nuvem oferecem ferramentas e automação para tarefas repetitivas e rotineiras, incluindo upgrades de versões minor.
O exemplo a seguir é com o AWS RDS. Ao criar um novo banco pelo AWS Console, você se depara com várias dezenas de opções de configuração, mas não com todas. Selecione "Additional Configuration" no fim da página para visualizar todas as opções de setup disponíveis.
É preciso rolar até o fim dessa página adicional para encontrar a seção Maintenance, em que a opção "Enable auto minor version upgrade" vem ativada por padrão.
Os problemas dessa abordagem do serviço gerenciado
Há vários problemas fundamentais ao usar essa configuração padrão:
- Os upgrades minor são aplicados na janela de manutenção semanal, a critério da AWS. Isso pode não acontecer automaticamente na próxima janela e levar várias semanas para ocorrer.
- A AWS não distingue ambiente de teste de ambiente de produção. Se você tem vários ambientes configurados para upgrade automático, todos podem ser atualizados na mesma semana — ou apenas alguns.
- A AWS não prioriza versões com suporte de longo prazo (LTS) em relação aos upgrades minor. A própria documentação do AWS RDS afirma: "We recommend that you don't set the AutoMinorVersionUpgrade parameter to true for LTS versions. Doing so could lead to your DB cluster being upgraded to a non-LTS version".
- Quando um upgrade minor acontece, o AWS RDS não cria um ponto de recuperação para você fazer rollback caso algum problema apareça depois. Dá para usar a restauração para um ponto no tempo, mas isso não reverte a versão atualizada que está em execução para a versão anterior ao upgrade.
- As janelas de manutenção costumam ser planejadas para horários de baixo uso e, em geral, coincidem com a menor disponibilidade de recursos técnicos. O horário de execução da janela em um upgrade não planejado provavelmente vai aumentar o tempo adicional de indisponibilidade.
Versões minor não são aplicadas automaticamente na próxima janela de manutenção.
Um upgrade de versão minor é tão importante quanto o lançamento de uma nova versão de um produto interno. Quando a maior parte do seu time técnico está fora do ar, você implantaria automaticamente uma nova versão interna sem testes em produção?
A boa prática para upgrades de versões minor
É bem simples: teste e valide.
Apesar de "Enable auto minor version upgrade" ser um recurso interessante, que reduz a dependência da manutenção regular, ele acaba alimentando o desconhecimento sobre o controle da execução e das opções de recuperação. O banco de dados costuma ser um componente crítico do stack tecnológico. Ele exige monitoramento constante, gerenciamento e manutenção contínua, como qualquer outro componente crítico do sistema.
O rollout de uma nova versão minor em qualquer ambiente deve seguir um processo controlado e documentado. Isso inclui avançar pelos diferentes ambientes até chegar à produção — por exemplo, dev, test, stage e prod. Um upgrade deve ser executado com automação e acompanhado por uma pessoa, mesmo quando há centenas ou milhares de servidores de banco de dados. E deve rodar quando os recursos estão disponíveis online, incluindo o time de operações que cuida da infraestrutura e o time de engenharia, que pode ser acionado caso uma operação inesperada ou não testada gere um incidente.
As etapas específicas do processo de upgrade variam conforme a organização. Esse processo deve sempre incluir um snapshot "pré"-upgrade. Em geral, releases de versões em produção só devem acontecer depois de um tempo razoável — algumas semanas, por exemplo — após o lançamento e a validação em outros ambientes.
Um banco em produção nunca deve estar em uma versão mais nova do que qualquer banco usado no ciclo de testes de release.
Não é recomendável operar o seu banco de dados na versão de release mais antiga. Isso transforma o upgrade minor em um item de caminho crítico, e a AWS não fornece um cronograma de descontinuação e remoção. De modo geral, também não vale operar com a versão de release mais recente. A comunidade pode ainda não ter identificado problemas introduzidos no último release, e os recursos online para ajudar na triagem podem ser escassos.
Como boa prática, aplique cada release em um momento adequado para o negócio e não combine várias versões minor em um mesmo upgrade. Um rollout para a versão mais recente pode ser necessário por causa de uma correção de bug conhecido em uma nova versão — nesse caso, não tem jeito: é preciso testar, validar e fazer o upgrade fora de uma política de negócio conhecida e documentada.
Em resumo, seja SEMPRE proativo.
Identificando upgrades de versões minor
Nos últimos meses, a AWS lançou um novo recurso que expõe recomendações da AWS via AWS CLI e Console. Antes, descobrir a disponibilidade de novas versões exigia um processo mais trabalhoso, como revisar Release Notes, acompanhar o lançamento de novas versões ou monitorar eventos de outros ambientes em que esse recurso estivesse ativado.
Agora dá para obter essa informação com o comando describe-db-recommendations. OBS: ele ficou disponível na versão 2.15.3 da CLI. É preciso ler o changelog linha por linha para identificar essa atualização recente. Se você não atualiza a CLI com frequência, vai precisar de uma versão mais nova para rodar o comando.
Saída do describe-db-recommendations
$ aws rds describe-db-recommendations
{
"RecommendationId": "",
"TypeId": "config_recommendation::old_minor_version",
"Severity": "informational",
"ResourceArn": "arn:aws:rds:region:123456789:cluster:mydb",
"Status": "active",
"Detection": "**[resource-name]** is not running the latest minor DB engine version",
"Recommendation": "Upgrade to latest engine version",
"Description": "Your database resources aren't running the latest minor DB engine version. The latest minor version contains the latest security fixes and other improvements.",
"RecommendedActions": [\
{\
"ActionId": "",\
"Operation": "modifyDbCluster",\
"Parameters": [\
{\
"Key": "EngineVersion",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "DBClusterIdentifier",\
"Value": "mydb"\
}\
],\
"ApplyModes": [\
"immediately",\
"next-maintenance-window"\
],\
"Status": "ready",\
"ContextAttributes": [\
{\
"Key": "Recommended value",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "Current engine version",\
"Value": "8.0.mysql_aurora.3.04.1"\
}\
]\
}\
```\
### Saída no AWS Console\
Usando o AWS Console com o serviço RDS, você verá Recommendations em destaque no menu lateral esquerdo. Por exemplo:\
\
### **Lista de recomendações do RDS**\
Na lista de recomendações, você verá os servidores com o aviso "is not running the latest monitor DB engine version".\
\
### Mais informações sobre uma recomendação específica\
Você também pode acessar mais detalhes da recomendação para examinar a configuração completa do recurso e as referências à documentação aplicável.\
\
Considerações finais\
Aliar esse conhecimento a um job agendado periodicamente para capturar e compartilhar essas notificações vai permitir que você se prepare para um upgrade de versão minor recomendado. Validações adicionais e passos de recuperação ajustados aos requisitos e recursos do seu negócio aumentam muito a confiança de que não haverá impacto em produção durante upgrades de versões minor.\