Revolucionando a Arquitetura de Atendimento: A Nova Solução ETL da MUTANT

Revolucionando a Arquitetura de Atendimento: A Nova Solução ETL da MUTANT

No cenário atual de atendimento ao cliente, a eficiência e a agilidade na gestão de interações tornaram-se fundamentais para o sucesso das empresas. É nesse contexto que surge o Ezfront, produto da MUTANT, uma solução inovadora que revoluciona a forma como as organizações lidam com o suporte ao cliente. Integrando um canal de atendimento pelo WhatsApp, o Ezfront simplifica a comunicação e proporciona uma experiência mais fluida e eficaz tanto para os clientes quanto para os atendentes.

Importante frisar que, neste mundo dinâmico e competitivo dos negócios, a colaboração entre empresas muitas vezes se revela como o caminho mais promissor para a inovação e o progresso. Neste contexto, destaca-se a parceria entre as empresas e duas mentes visionárias: Carlos Rossinoli e Antônio Cantídio, ambos colaboradores da MUTANT. Estes dois indivíduos não apenas compartilharam uma visão comum, mas também se uniram em um esforço conjunto para desenvolver um produto de altíssima qualidade. Sob sua liderança e expertise, empresas parceiras foram guiadas em um processo de criação que resultou em uma solução inovadora e impactante para o mercado.

Este texto explora o funcionamento do Ezfront e o papel crucial desempenhado pelo Telemetry, uma aplicação essencial para a análise e o monitoramento do desempenho do sistema. Além disso, será detalhada a evolução da arquitetura inicial do Telemetry até a solução desenvolvida para superar desafios e garantir um desempenho otimizado e escalável.

Ao longo deste documento, será possível compreender não apenas como o Ezfront simplifica o gerenciamento de atendimentos, mas também como a evolução do Telemetry reflete o compromisso contínuo com a excelência no atendimento ao cliente e na gestão de dados.

Ezfront

O Ezfront da MUTANT é uma solução avançada de gestão de atendimentos que revoluciona a forma como as empresas lidam com o suporte ao cliente. Com um canal de atendimento integrado ao WhatsApp, o Ezfront simplifica a comunicação e oferece uma experiência mais ágil e eficiente. Seus elementos principais são os tickets e os atendentes, que trabalham em conjunto para garantir um fluxo contínuo e organizado de interações.

O processo no Ezfront inicia quando um cliente envia uma mensagem pelo WhatsApp para um número cadastrado no sistema. Nesse momento, o Ezfront cria um ticket e, com base em configurações predefinidas, encaminha esse ticket para um grupo específico. Dentro desse grupo, o ticket entra em uma fila de espera até que seja atendido por um agente disponível. A interação entre atendente e cliente começa então, podendo resultar na transferência do ticket para outro grupo, outro atendente ou no encerramento do atendimento.

Cada interação dentro do Ezfront gera eventos que são essenciais para o cálculo de métricas de atendimento. Esses cálculos e análises de dados são realizados por uma aplicação chamada Telemetry, responsável por garantir insights valiosos para o aprimoramento contínuo do atendimento ao cliente dentro do Ezfront.

Telemetry

O Telemetry, desenvolvido também pela MUTANT, desempenha um papel fundamental dentro do Ezfront, recebendo uma ampla variedade de eventos relacionados aos tickets e às interações entre clientes e atendentes. Esses eventos são cruciais para a análise e o monitoramento do desempenho do sistema, permitindo uma compreensão detalhada de cada etapa do processo de atendimento. Alguns exemplos desses eventos incluem a criação de tickets, transferências entre atendentes, atribuições de tickets e encerramento de tickets, além dos eventos gerados a cada mensagem trocada durante um atendimento.

No contexto do Ezfront, um ticket é gerado sempre que um cliente inicia uma conversa, seja pelo WhatsApp ou pelo webchat integrado. Esse momento de criação de ticket é registrado como um evento importante, fornecendo um ponto de partida para todo o ciclo de atendimento. A atribuição de tickets é um processo dinâmico, podendo ocorrer de diferentes formas: logo após a criação, durante transferências entre atendentes ou quando um agente fica disponível em uma fila de atendimento, cada situação gerando um evento específico que contribui para o rastreamento e a análise do fluxo de trabalho.

Além disso, a transferência de tickets entre grupos de atendimento é registrada como um evento separado, demonstrando a movimentação dos tickets nas diferentes etapas do processo de suporte. Da mesma forma, o encerramento de tickets e as trocas de mensagens entre clientes e atendentes também são eventos essenciais que fornecem insights valiosos para a avaliação da eficiência do sistema e a qualidade do atendimento prestado.

Arquitetura Inicial

A arquitetura anterior foi fundamental para o desenvolvimento inicial do Telemetry, proporcionando uma base sólida para a coleta, transformação, armazenamento e visualização de dados relacionados ao atendimento e interações dos usuários. Ao explorar os componentes e o funcionamento desta arquitetura antiga, poderemos entender melhor a evolução e as melhorias implementadas ao longo do tempo para garantir um desempenho cada vez mais eficiente e escalável do Telemetry.

O TelemetryCollector foi projetado como o primeiro ponto de contato para os eventos recebidos pelo Telemetry no ambiente da AWS. Sendo implantado como um serviço dentro do Amazon ECS Fargate, ele atuava como uma porta de entrada para os eventos, recebendo-os por meio de uma API Restful. Uma vez recebidos, esses eventos eram publicados em uma fila do Amazon SQS, preparando-os para serem processados e analisados posteriormente.

O TelemetryProcessor, também implementado como um serviço no ECS Fargate, desempenhava um papel crucial no processamento e na transformação dos eventos recebidos pelo Telemetry. Com uma arquitetura que permitia a execução de vários processos concorrentes, o TelemetryProcessor era capaz de consumir eventos da fila do SQS em grande volume. Cada processo era responsável por realizar a extração, transformação e carregamento (ETL) dos dados, garantindo a integridade e a qualidade das informações armazenadas no TelemetryDatabase.

Por sua vez, o TelemetryDatabase representava o núcleo do Telemetry, sendo o local onde todas as informações processadas e analisadas eram armazenadas de forma segura e acessível.

O TelemetryReport representava uma peça fundamental na arquitetura anterior do microserviço Telemetry. Implementado como um serviço dedicado no Amazon ECS, sua principal função era a geração de relatórios e análises a partir das informações armazenadas no TelemetryDatabase. Este componente era responsável por consumir os dados processados e transformados pelo TelemetryProcessor.

Problemas Encontrados

O Telemetry enfrentava desafios significativos em sua arquitetura anterior, especialmente no processamento e análise dos eventos recebidos. O TelemetryProcessor, responsável por registrar eventos no TelemetryDatabase e realizar consultas para determinar a etapa de processamento de um ticket, encontrava dificuldades devido à frequência dos acessos ao banco de dados e à falta de processamento em lote (batch). Essa abordagem gerava problemas de escalabilidade e desempenho quando um grande volume de eventos era recebido em curtos períodos.

Durante a análise dos eventos, o TelemetryProcessor precisava atualizar constantemente o banco de dados para refletir o contexto atual e, em seguida, registrar os resultados das análises. No entanto, a escalabilidade desse processo enfrentava dois cenários críticos: o banco atingindo seu limite de processamento e a aplicação não conseguindo consumir eventos rapidamente o suficiente para garantir tempos de resposta aceitáveis. A solução imediata era escalar o número de threads do TelemetryProcessor, mas isso resultava em um aumento da concorrência e, consequentemente, em problemas de inferência de contexto e resultados incorretos.

A concorrência excessiva levava a situações em que eventos gerados em momentos diferentes eram processados simultaneamente, levando o TelemetryProcessor a inferir contextos de processamento incorretos e produzir resultados imprecisos. Esse efeito colateral indesejável se tornava mais pronunciado à medida em que o número de threads aumentava.

O TelemetryReport enfrentava desafios na geração de relatórios devido à necessidade frequente de realizar muitas agregações e junções de dados dispersos em diferentes tabelas, resultando em atrasos significativos e, em alguns casos, timeouts ao tentar gerar relatórios para períodos extensos. Mesmo quando os relatórios eram concluídos, o processo ainda demandava um tempo considerável, destacando a complexidade e a lentidão associadas à obtenção de insights completos e precisos por meio do TelemetryReport no Ezfront.

A gestão da arquitetura estava se tornando complexa e com múltiplos clusters, seus componentes não comportavam grandes fluxos de informações em um curto período de tempo, e, conforme dito anteriormente, o processamento dessas métricas se tornava lento.

Com a chegada de novos clientes e novos relatórios e métricas, viu-se que era necessária a evolução dessa arquitetura de forma a suportar um volume maior de eventos e gerar relatórios de forma mais eficiente, além de resolver os problemas de escalabilidade.

Solução Desenvolvida

A solução atual para os desafios enfrentados pelo Telemetry foi estruturada com base nas etapas fundamentais de um processo de ETL (Extract, Transform e Load). Na fase de Extração dos dados, foram delineados os processos de Consumo, que envolve a captura dos dados de diversas fontes, e Despejo, responsável por armazenar esses dados em um local seguro e acessível. Na etapa de Transformação, destacam-se as atividades de filtragem, limpeza e enriquecimento dos dados, visando garantir a qualidade e a consistência das informações obtidas. Por fim, no Carregamento, houve uma reestruturação da modelagem do banco de dados para melhor atender às necessidades de armazenamento e uma subsequente alimentação desses dados nessa nova modelagem, assegurando uma base sólida e eficiente para análises e relatórios no Ezfront.

Consumo

Diante da diversidade de fontes de eventos hospedadas em diferentes contas na AWS, foi decidido manter o uso do TelemetryCollector como ponto de entrada para os dados no Telemetry. No entanto, houve uma mudança na abordagem de armazenamento e processamento desses eventos: em vez de alimentar uma fila no Amazon SQS como na solução anterior, o TelemetryCollector passou a alimentar um Kinesis Data Stream (KDS). Essa nova estratégia foi adotada visando aumentar a vazão de consumo de dados em comparação com a solução anterior, proporcionando uma capacidade de processamento mais eficiente e escalável para lidar com a variedade e o volume de eventos provenientes de diferentes fontes.

Despejo

Para resolver o desafio de armazenamento dos dados provenientes do Kinesis Data Stream (KDS), foi implementado o uso do Kinesis Data Firehose (KDF) como solução de bufferização. O KDF permite acumular os eventos recebidos do KDS em um buffer até que uma condição pré-definida de tempo ou tamanho seja atingida. Quando essa condição é alcançada, o KDF divide os eventos em arquivos, sendo que cada arquivo contém eventos relacionados a um único “tenant”. Esses arquivos são então armazenados de forma eficiente e acessível no Amazon S3.

Filtragem

Após a criação do arquivo inicial no Amazon S3 como parte do processo de bufferização pelo Kinesis Data Firehose (KDF), um evento é gerado na Amazon SQS para sinalizar sua disponibilidade para processamento. Esse evento é então consumido por uma função Lambda, que inicia uma sequência de operações. A Lambda começa verificando se ela conseguirá processar o arquivo dentro do tempo limite estabelecido. Em caso afirmativo, ela procede com a filtragem dos eventos que serão processados pela solução. Caso contrário, se o processamento dentro do limite de tempo não for viável, a Lambda cria um novo evento no SQS. Esse novo evento é direcionado a um Amazon ECS (Elastic Container Service) que realizará o mesmo trabalho que a Lambda, mas com um tempo limite maior para conclusão. Ao finalizar o processamento, tanto a Lambda quanto o ECS geram diversos arquivos novos no Amazon S3 contendo os eventos filtrados, processados e agrupados por ticket pela solução.

Limpeza

Após o processo de filtragem e agrupamento dos eventos por ticket, o arquivo resultante gera um novo evento no Amazon SQS, indicando sua disponibilidade para o próximo estágio de processamento. Esse evento é consumido por uma função Lambda, que realiza uma primeira análise para determinar se ela será capaz de processar o arquivo dentro do tempo limite estabelecido. Tanto a Lambda quanto o ECS envolvidos nesse processo são responsáveis por pegar cada arquivo contendo os eventos de um único ticket, bem como os arquivos gerados por iterações anteriores relacionados ao mesmo ticket, e realizar a união desses eventos. Após a união e a deduplicação dos possíveis eventos, um novo arquivo final é gerado. Esse novo arquivo contém todos os eventos relacionados a um determinado ticket, consolidando as informações e garantindo a integridade dos dados processados.

Enriquecimento

Após o evento ser gerado na etapa anterior do processo de processamento de dados, outro evento é automaticamente gerado e consumido por uma função Lambda designada para a etapa seguinte. Essa Lambda tem a responsabilidade de realizar os cálculos das métricas associadas a cada ticket, agregando dados e realizando análises para gerar métricas significativas em relação aos atendimentos feitos no Ezfront. Uma vez que todos os cálculos das métricas foram concluídos pela Lambda, um novo evento é inserido no Amazon SNS.

Modelagem e Armazenamento

Para atender às diferentes necessidades de consumo de dados do Telemetry, que incluem a geração de relatórios e o cálculo de métricas do dia atual, foram adotadas duas soluções de armazenamento distintas. Para armazenar as métricas do dia atual, foi escolhido o DynamoDB devido à sua capacidade de gerenciar dados em tempo real e sua escalabilidade eficiente. Por outro lado, para os dados utilizados na geração de relatórios, foi selecionado um RDS (Amazon Relational Database Service) devido à sua capacidade de lidar com consultas complexas e armazenar grandes volumes de dados de forma estruturada.

Os eventos gerados pelo passo anterior do processo são encaminhados para um tópico do Amazon SNS (Simple Notification Service), que por sua vez distribui esses eventos em duas filas distintas, cada uma destinada a um tipo específico de dado (métricas do dia atual e dados de relatório). Cada uma dessas filas atua como um buffer, ajustando a quantidade de eventos com base na capacidade de processamento e armazenamento disponível. Esses eventos, então, são consumidos por uma função Lambda que, utilizando o princípio de inserção em lote, realiza a inserção eficiente de cada evento no banco de dados relacionado, seja no DynamoDB para as métricas do dia atual ou no RDS para os dados de relatório.

Por fim, os dados são consumidos de maneira mais eficiente pelo TelemetryReport. Esse último estágio da cadeia de processamento de dados foi aprimorado com diversas melhorias, visando oferecer uma visão mais detalhada e precisa das métricas e relatórios necessários para a gestão estratégica do Ezfront.

Resultados Obtidos

FinOps: Maximizando Eficiência e Reduzindo Custos

Ao estruturar este projeto com base nos pilares da arquitetura ETL e Event-Driven, conseguimos desenvolver um produto de alta performance, escalável e seguro, ao mesmo tempo em que reduzimos significativamente os custos operacionais.

A adoção de uma plataforma altamente escalável eliminou a necessidade de criar e manter novos clusters, concentrando-se apenas na centralização para a nova arquitetura. Prevemos uma redução nos custos operacionais entre 30% e 50% nos próximos meses, à medida que mais clientes são incorporados à plataforma.

Essas mudanças não só melhoraram a eficiência operacional, mas também forneceram uma base sólida para o crescimento sustentável do projeto, garantindo que possamos atender às demandas futuras sem comprometer a qualidade ou a segurança.

Além de todas as melhorias e vantagens já citadas neste artigo, precisamos destacar a diminuição considerável em relação ao custo da infraestrutura para assegurar o funcionamento correto, que foi na ordem de 20 mil dólares mensais, resultando em uma economia de aproximadamente um milhão de reais anuais.

Reconhecimento dos Profissionais

Este projeto foi realizado com a colaboração dedicada de Caio Viana, da Coupled Tecnologia, e Felipe Endlich, da Verzel. A parceria entre esses profissionais exemplares foi fundamental para o sucesso do desenvolvimento da nova arquitetura, refletindo seu compromisso com a inovação e a excelência.