Um dos grandes problemas das atualizações de sistemas é o tempo de parada dos mesmos para o usuário final. Principalmente quando essa ação ocorre no Banco de Dados. Quanto maior o volume de dados e quantidade de alterações, mais tempo o sistema irá permanecer offline.
Foi essa necessidade de diminuir esse tempo que uma empresa a qual presto consultoria de BD me trouxe. Precisávamos bolar uma estratégia de atualização de seus sistemas de modo que o usuário final ficasse o mínimo de tempo sem sistema, ou que o negócio sofresse o mínimo de impacto.
O grande problema disso é fazer com que a versão do software corresponda a mesma estrutura do banco de dados. Claro, quando essa atualização implica em alterações de estrutura de banco como criação de tabelas, colunas, etc. Em uma atualização a quente, com os usuários utilizando o sistema, você pode até realizar as alterações necessárias no banco, dependendo também do SGBD utilizado, mas vai chegar um determinado momento, em alguma tela, que ocorrerão erros devido a estrutura divergente.
Pensando nisso sugeri uma alteração no processo de expedição de scripts e executáveis do sistema. Mesmo sua estrutura de dados não ter sido concebida no início para ser modularizado, pensei em uma maneira de tentar modularizar a atualização, afetando apenas algumas áreas da empresa por vez. Desse modo a equipe de TI da empresa que utiliza o sistema também pode programar a parada do mesmo por módulos.
Por exemplo, se ela tem uma área de recepção, uma área de estoque de produtos, uma área de faturamento e uma área de pesquisa e desenvolvimento eles podem planegar paradas por áreas de acordo com menor impacto ao negócio. Atualizando os módulos de recepção em um horário onde existe menor ocorrência de atendimentos, os módulos de estoque em um horário de menor movimentação de produtos, etc.
O processo de certa forma é simples. Irá existir uma entrada que será a requisição de atualização. Nessa requisição serão preparados os scripts e executáveis correspondentes. Ai vem a mudança principal. Esses scripts tem que ser modularizados conforme os executáveis que utilizam aquela estrutura. Vai existir um conjunto de tabelas Core, que são comuns a diversos módulos. Essas precisam sofrerem o mínimo de alterações possíveis. Ao redor dessas tabelas Cores devem existir as tabelas que são utilizadas por cada módulo. Como estoque deve possuir tabelas específicas para armazenar informações relacionadas apenas a esse módulo e assim por diante. A saída desse processo serão os Logs de atualização e o produto (e base) atualizados.
Fizemos uma atualização piloto em um dos clientes dessa empresa e, apesar de alguns pequenos problemas e ajustes iniciais, tudo correu dentro do planejado e o feedback que tivemos foi bastante positivo. Agora é amadurecer e manter o novo processo de expedição para expandir às próximas atualizações. E meu trabalho aqui está terminado!
Nenhum comentário:
Postar um comentário