Manual de Instalação - CITBot
O documento a seguir tem por finalidade orientar os responsáveis sobre os procedimentos de instalação do CITBot , de acordo com a necessidade de cada cliente e sua aplicação dentro do ambiente em que está em operação. Foram descritas as suas principais características, aplicabilidades, recomendações de uso e pontos de atenção técnica, para que a sua melhor performance seja alcançada.
O CITBot é composta por chatbots criados e geridos por programas de computador desenvolvidos para simular uma conversa humana utilizando linguagem natural ou coloquial por meio de chats automatizados, sites e outras plataformas digitais. O CITBot pode responder utiliza diretrizes pré-programadas (fluxos) ou inteligência artificial, estando disponível em tempo integral (24x7).
O CITBot é um sistema de atendimento via chat, automatizado e humano, que utiliza tecnologias avançadas de processamento de linguagem natural (NLU) e scripts personalizados. Isso permite uma integração de alto nível com sistemas externos.

São entendidos como clientes as aplicações terceiras que irão consumir o CITBot por meio de requisições no protocolo http. O pré-requisito para que elas funcionem é o acesso direto ao ponto de entrada ou o acesso indireto, por meio de uma aplicação de proxy devidamente configurada.
Todos os recursos externos listados abaixo podem ser configurados diretamente na interface gráfica do CITBot combinada ao painel de controle da respectiva solução.
Os pré-requisitos técnicos para que as mesmas possam ser utilizadas são:
- Conexão com a internet para entrada e saída
- Credenciais, licenças, APIs, tokens, dentre outros
Broker que permite enviar e receber mensagens via WhatsApp.
Sistema de detecção de intenções do usuário. Isso é oferecido como alternativa à NLU interna da plataforma
Broker da Microsoft que permite enviar e receber mensagens via Teams.
Exemplo de aplicação externa com a qual é possível interagir por meio de API
Servidor para cache e arquivamento temporário de registros.
Solução de banco de dados para armazenamento definitivo de dados transacionais e logs.
O CITBot NLU (Natural Language Understanding) é uma solução de entendimento de linguagem oferecida pela Central IT oferecida como alternativa ao Watson Assistant.
Sistema de arquivos do sistema operacional:
Tal sistema é utilizado para o armazenamento de uploads dos usuários finais, bem como para o armazenamento de scripts de integração.
Webservice escrito em NestJS,que centraliza a chamada aos recursos internos e externos da aplicação, oferecendo a abstração utilizada na implementação do Front-end, bem como o fornecimento de APIs para clientes externos.
Componente de servidor que, combinado ao navegador de internet, fornece a interface gráfica que é experienciada pelo usuário final.
A solução foi concebida para ser distribuída em imagens do tipo Docker. Tais imagens estão preparadas para serem totalmente configuradas por variáveis de ambiente, permitindo que haja várias estratégias de implantação.
Por padrão, disponibilizamos um compose-file contendo uma instalação funcional mínima da solução.
A configuração da aplicação para outros orquestradores pode ser feita a partir da tradução do compose-file para a respectiva plataforma.
O CITBot está preparada para balanceamento de carga. Para tal finalidade, é importante que seja configurada alguma forma de afinidade entre a sessão do usuário e o respectivo contêiner.

Na tabela abaixo, são apresentados os requisitos mínimos de hardware para cada uma das imagens Docker que compõem a solução.
| Back-end | Front-end | CITBot NLU | Postgre SQL | Redis |
---|---|---|---|---|---|
memória | 1G | 1G | 1G | 4G | 4G |
núcleos de processador | 1 | 1 | 1 | 4 | 4 |
réplicas | 4 | 4 | 1 | 1 | 1 |
espaço | 10G | n/a | 1G | 8G | n/a |
IOPs | 100k iops | n/a | indiferente | 100k iops | n/a |
latência | 10 us | n/a | indiferente | 10 us | n/a |
acesso à internet | sim | não | não | não | não |
exposição à internet | sim | sim | não | não | não |
Recomenda-se o monitoramento dos itens abaixo:
- Saúde dos contêineres (UP ou DOWN)
- Uso de memória dos contêineres (90% alta / 98% desastre)
- Uso de processador dos contêineres
- Uso máximo diário de memória nos contêineres
- Uso médio do processador dos contêineres agregados por hora
- Tempo máximo diário de execução de consultas SQL
- Tempo máximo de execução de consultas SQL agregadas por hora
- Erros no log da aplicação
- Requisições http com status diferente de 200
Em caso de desastre, será necessário recuperar a aplicação a partir do seu backup. Para tal, é preciso que exista um backup e que ele seja periodicamente testado.
O backup deve ser feito da seguinte forma:
- Dump completo do banco de dados PostgreSQL
- É recomendada a compactação do arquivo com bzip2, uma vez que boa parte dos dados é composta por texto
- Cópia incremental da pasta que contém os arquivos dos uploads dos usuários
- Cópia completa da pasta que contém os arquivos de scripts da aplicação
Recomenda-se que o procedimento de backup seja feito de forma automática e que o resultado do script de back-up seja monitorado.