Manual de Instalação - CITBot



Introdução

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.

CITBot

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.

Diagrama da Plataforma

Document image


Clientes

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.

Recurso externos

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

Positus

Broker que permite enviar e receber mensagens via WhatsApp.

Watson Assistant

Sistema de detecção de intenções do usuário. Isso é oferecido como alternativa à NLU interna da plataforma

Microsoft Teams

Broker da Microsoft que permite enviar e receber mensagens via Teams.

CITStmart

Exemplo de aplicação externa com a qual é possível interagir por meio de API

Recursos Internos

Redis

Servidor para cache e arquivamento temporário de registros.

PostgreSQL

Solução de banco de dados para armazenamento definitivo de dados transacionais e logs.

CITBot NLU - Wanderson

O CITBot NLU (Natural Language Understanding) é uma solução de entendimento de linguagem oferecida pela Central IT oferecida como alternativa ao Watson Assistant.

Arquivos

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.

Ponto de entrada

Back-end

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.

Front-end

Componente de servidor que, combinado ao navegador de internet, fornece a interface gráfica que é experienciada pelo usuário final.

Requisitos técnicos

Docker

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.

Compose-file

Por padrão, disponibilizamos um compose-file contendo uma instalação funcional mínima da solução.

Outros ambientes

A configuração da aplicação para outros orquestradores pode ser feita a partir da tradução do compose-file para a respectiva plataforma.

Balanceamento de carga

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.

Requisitos de Hardware

Document image


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

Monitoraçã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

6. Plano de backup

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.