Por Jens Dose

Devido ao risco de não ser capaz de escalar e inovar adequadamente, nem de fornecer uma base para acomodar novas plataformas ou linguagens de programação, em meados de 2019, a seguradora Allianz tomou a decisão de migrar todo o Allianz Business System (ABS) – as principais aplicações de TI, incluindo a sua base de dados na Alemanha – para servidores x86 normalizados com sistemas operativos Linux. O projeto, denominado ABS Goes Linux, foi o primeiro no setor dos seguros.

Com esta mudança, a equipa de TI esperava eliminar os problemas de ligação das aplicações nativas da cloud e desenvolvê-las de forma ágil, bem como ser menos dependente dos fornecedores e mais capaz tecnicamente. “Não usamos o mainframe desde a Páscoa de 2022”, diz Axel Schell, CTO da Allianz Technology, que fornece serviços de TI em todo o mundo para o Grupo Allianz. “Foi um dos projetos mais arriscados e mais difíceis da minha carreira.

A nova infraestrutura armazena dados em tempo real sobre a disponibilidade das bases de dados, por exemplo, e a estabilidade das aplicações e dos pedidos de seguro processados. Ao mesmo tempo, tudo é apresentado num painel de controlo. “É assim que a transparência funciona atualmente”, diz Schell. “Todos estão sempre atualizados, o que simplifica a organização.

Além disso, a configuração garante a confiança entre os clientes internos, acrescenta Sebastian Pongratz, um executivo sénior da equipa de Schell e responsável pela implementação do projeto. “Todos os utilizadores das áreas de negócio, e não apenas os de TI, podem aceder ao painel de controlo e verificar o seu funcionamento. Com o mainframe, podíamos beneficiar dos ciclos de inovação dos fabricantes, mas também estávamos dependentes deles”, acrescenta, apontando uma das razões para a mudança para o Linux.

Aplicações de base que estavam anteriormente no mainframe

O ABS inclui todas as aplicações de negócio essenciais das empresas do grupo alemão, bem como de todas as holdings da região. “É a plataforma central do cliente, onde são geridos mais de 30 milhões de contratos”, afirma Pongratz. “É o núcleo do ecossistema de TI alemão. Inclui todas as interfaces de processamento e os portais de clientes e de vendas.” Se o ABS não funcionasse, as vendas, os corretores, o back office e os serviços Web também não funcionariam. Isto aplica-se a todas as linhas de negócio com seguros de saúde, propriedade e vida.

À medida que o planeamento avançava, Pongratz e a sua equipa exploraram opções para migrar o sistema para a nova plataforma por partes. Mas a peça central, uma das maiores bases de dados DB2 baseadas em Linux disponíveis, só poderia ser migrada como um todo. Para se preparar, a Allianz Technology optou por uma abordagem iterativa.

Eles conheciam os KPI alvo para o novo ambiente, e que o desempenho e os processos automatizados do mainframe também precisavam estar disponíveis no Linux. “Também tínhamos um problema de volume”, diz Pongratz. “Tudo tinha de funcionar como antes. E, ao mesmo tempo, tinha de haver espaço para crescimento nos próximos anos.”

A equipa definiu vários conjuntos de requisitos, como a arquitetura alvo, os requisitos para os produtos utilizados, os KPI de desempenho operacional, as quotas de desempenho e automação e as normas de segurança subjacentes. “A partir daí, passámos por várias iterações para aumentar gradualmente o nível de maturidade e trabalhámos com os fornecedores para adaptar os seus produtos aos nossos requisitos”, explica Pongratz. A base de dados, com vários petabytes de tamanho, oferecia uma capacidade de processamento de cinco dígitos MIPS (milhões de instruções por segundo) no mainframe. Até agora, nada parecido havia sido portado para o DB2 no Linux.

Migração gradual de aplicações antigas

Na primeira fase, foi necessário convencer as partes interessadas das vantagens do projeto para a empresa. A partir daí, o departamento de TI deu os primeiros passos no novo ambiente. “Testámos como fazer com que as partes básicas do ABS funcionassem com o Linux e como se comportavam sob carga”, explica Pongratz. Começámos com as aplicações e continuámos com a integração da base de dados até componentes específicos, como o grande lote para a renovação mensal.

Seguiu-se uma validação inicial, com perguntas como se os KPI desejados são tidos em conta, se as operações podem ser simuladas para testes antes do arranque, se as capacidades e as velocidades de desempenho dos sistemas de servidor e de armazenamento adquiridos são suficientes. A resposta foi negativa.

Contratempos e ajustamentos

Cerca de 14 meses antes da transição, Pongratz apercebeu-se de que a infraestrutura instalada e colocada em funcionamento não era compatível com o sistema de destino, pelo que o ambiente teve de ser ajustado. O departamento de TI mudou para uma infraestrutura mais potente e reviu todo o conceito de armazenamento. “Trabalhámos em estreita colaboração com os fornecedores externos e os seus laboratórios e enviámos-lhes pedidos de funcionalidades, não só para funcionalidades, mas também para situações durante o funcionamento”, explica. Por exemplo, em caso de problemas, deve ser possível encerrar e reiniciar vários milhares de processos na cache da base de dados em menos de 10 minutos sem que o utilizador se aperceba de nada.

Os produtos de segurança no ambiente cliente-servidor também atingiram os seus limites. Os volumes de processos a proteger eram 10 vezes superiores àqueles para os quais as soluções foram originalmente concebidas. “Tivemos de convencer os fornecedores a envolverem-se e a adaptarem o seu software ao nosso ambiente”, diz Schell. “Agora também podem oferecer estas funcionalidades a outros clientes de dimensão semelhante. Fizemos o trabalho pioneiro em conjunto com eles.

O mainframe como referência

A referência para estes KPI foi o mainframe. “O facto de o novo ambiente oferecer um desempenho semelhante ao antigo é crucial para a aceitação do cliente interno”, afirma Schell. As novas funcionalidades foram testadas, ajustadas e alargadas em várias iterações.

A equipa de TI também testou a escalabilidade da nova plataforma. “Precisamos de ser capazes de migrar mais carteiras e captar novos clientes”, acrescenta Schell. “Por isso, também testámos se era possível processar volumes adicionais.” Utilizando simulações de crescimento, as TI testaram se o sistema permaneceria funcional mesmo com grandes alterações de versão ou migrações futuras.

“Por exemplo, medimos a utilização dos canais online, utilizámos os horários de pico de acesso como referência e verificámos se o novo sistema também funcionaria de forma fiável com mais 1000 funcionários simulados”, diz Pongratz.

Os processos em lote também foram testados desta forma, por exemplo, em relação a picos de carga em negócios sazonais. Os KPI para isto foram os acessos DB2 por segundo, que foram simulados na base de dados Linux, e as medições foram efetuadas todos os dias do mês para cobrir todos os cenários. Paralelamente, foi introduzido o modelo operacional alvo do novo ambiente. A Allianz IT criou equipas de peritos na Alemanha, Índia e Hungria para operar o novo ABS.

A fase de arranque

Cerca de quatro meses antes da data prevista para a migração, a equipa interrompeu o desenvolvimento do produto. As versões desenvolvidas até à data foram preparadas para a mudança e apenas ajustadas com correções individuais. Nesta base, a simulação do funcionamento contínuo começou nas últimas semanas antes do prazo.

Nesta fase, por exemplo, foi revisto o conceito de reorganização da base de dados, incluindo cópias de segurança durante os períodos de descanso noturno. “Não foi tão rápido como planeado”, diz Pongratz. “Por isso, tivemos de o ajustar oito semanas antes de entrarmos em funcionamento.

A migração em si foi deliberadamente agendada para o fim-de-semana da Páscoa de 2022. Todo o inventário do mainframe tinha de ser convertido, tecnicamente revisto, limpo e migrado para Linux. “Tínhamos quatro dias para resolver qualquer problema”, diz ele. “No final, foram necessárias 48 horas para transferir todo o conjunto de dados.”

Para estar preparado para os problemas, a logística e a comunicação também tiveram de ser preparadas. “Para o pior cenário, em que todas as nossas salvaguardas pré-implementadas falharam, preparámo-nos para voltar ao sistema antigo”, diz Pongratz. Schell acrescenta: “Tivemos 1.000 empregados a testar em todas as áreas, incluindo agências e corretores”. Para além disso, a autoridade alemã de supervisão bancária, Bafin, foi informada.

A equipa central do projeto era constituída por cerca de 500 funcionários, enquanto cerca de 3000 pessoas trabalhavam em várias fases, e o orçamento era baixo, na ordem dos três dígitos dos milhões de euros.

Esforço e ROI

A equipa principal do projeto era composta por cerca de 500 funcionários, enquanto cerca de 3000 pessoas trabalhavam em várias fases, e o orçamento era baixo, na ordem dos três dígitos dos milhões de euros. Assim sendo, o plano é que o projeto se pague a si próprio dentro de três a quatro anos. “Estamos a utilizar a plataforma há um ano e podemos ver exatamente como se compara com os custos do mainframe”, diz Schell. “Economizamos uma quantia de dois dígitos na operação.”

De acordo com o CTO, a confiança empresarial foi alcançada através da medição de todas as transações relevantes de um utilizador num departamento, antes e depois. “No teste de pré-início, demonstrámos que os novos processos têm um desempenho elevado nas áreas pretendidas”, afirma Schell. E num curto espaço de tempo, todas as transações na nova plataforma eram claramente mais rápidas do que no mainframe.

De acordo com Pongratz, a arquitetura moderna e o acesso às ferramentas mais recentes aumentam a capacidade de inovação da empresa. Os recursos podem agora ser utilizados de forma mais dinâmica e atribuídos mais facilmente. E os programadores já não têm de esperar pelos trabalhos em lote.

O projeto contribui igualmente para a estratégia global de TI, uma vez que a Schell pretende consolidar as aplicações fora da ABS e retirar os sistemas antigos da linha de produção. “É a fase preliminar para a cloudificação do ambiente”, diz ele. “Conseguimos operações muito estáveis e estamos agora a considerar se e como as vamos migrar para a cloud.” Mas os hiperescaladores de cloud comuns teriam primeiro de desenvolver soluções adequadas que correspondessem aos requisitos de desempenho do sistema.

Avaliar os desafios

Para além do aspeto técnico, a gestão do elemento humano foi também um grande desafio. No mundo do mainframe, a Allianz tinha acumulado muitos conhecimentos sobre aplicações que continuariam a ser essenciais para a nova plataforma de destino, pelo que tinham de ser preservados.

A equipa existente foi complementada com especialistas e os colegas do “velho mundo” receberam formação adicional para transferirem os seus conhecimentos para o ambiente Linux. Mas havia receio entre os funcionários que tinham trabalhado no mainframe durante décadas.

“A gestão da mudança foi um grande desafio”, diz Schell. “Se não for bem gerida, pode arruinar um projeto.” Foi por isso que o pessoal se envolveu no projeto desde o início. “Conseguimos que toda a organização se comprometesse com um objetivo e deixámos claro que cada pessoa seria importante para o novo mundo”, diz Pongratz. Os colegas receberam formação em cursos ou em conjunto com especialistas internos e externos.

Nas fases do projeto, houve também um pouco de nervosismo. “É preciso ter cuidado para não copiar o mainframe no Linux”, diz Pongratz. Alguns mecanismos tinham de ser transferidos para o novo mundo, mas funcionavam de forma diferente. É por isso que era importante, por exemplo, na garantia de qualidade, verificar se as aplicações eram construídas nativamente para Linux com vista à cloud e não de acordo com os princípios antigos.

Além disso, os executivos, como os chefes de departamento e de equipa, foram responsabilizados por subprojetos. E, na sua totalidade, o projeto afetou toda a gente na Allianz na Alemanha, porque todos trabalham com o ABS, que é um sistema com 300 interfaces. “Trabalharam de acordo com o lema: ‘Tu constróis, tu geres'”, diz Pongratz. “É bom envolver os empregados.