5-Infraestrutura de TI

A observação de requisitos de infraestrutura começa bem antes de se chegar ao SEI, propriamente dito.

Energia e geradores de energia para o Datacenter, por exemplo, são pontos de atenção: Uma interrupção de fornecimento pela companhia fornecedora pode resultar em danos físicos na base de dados, e o órgão precisa ser capaz de se recuperar desses incidentes. Outro ponto comum que deve ser levado em consideração seriam possíveis desastres naturais, como incêndios ou inundações, que afetem a integridade do Datacenter.

A equipe de infraestrutura deve ser suficientemente capacitada e ter a sua disposição ferramentas adequadas para a correta sustentação do serviço ao longo dos anos. Não basta “subir o sistema”, deve-se levantar todo o aparato necessário para a sua sustentação a médio e longo prazo.

O arquiteto deve ter em mente que todos os colaboradores do órgão irão acessar o sistema para criar e alterar documentos administrativos constantemente.

O arquiteto deverá também se familiarizar com aspectos de negócio do órgão, para definir valores como: quantidade de documentos administrativos acessados/alterados por minuto. Que tipos de documentos serão guardados no sistema e o seu tamanho médio? É possível, por exemplo, que algum órgão necessite guardar vídeos, reportagens ou áudios em seus processos. Nestes casos, a quantidade de storage necessária será um ponto de atenção a ser monitorado, visto que esse tipo de informação ocupa muito espaço.

Já outros órgãos irão focar em cadastrar no sistema documentos em PDF “OCR-izados” e pequenos, optando por gerar a maior parte de sua massa documental como documentos internos no SEI. Documentos internos são armazenados em formato html direto no banco de dados, economizando storage, mas gerando aumento do tamanho das tabelas que guardam o conteúdo dos documentos.

Temos à disposição um projeto com o teste de cargas em jMeter para o SEI. Desta forma é possível calibrar a execução do teste para escalar atividades paralelas simulando centenas de usuários em diversos cenários de uso do sistema.

Modelo de Implantação Centralizado

Nesse modelo, um provedor de serviço, devidamente credenciado no MGI - Ministério da Gestão e Inovação, proverá a infraestrutura adequada ao órgão.

Cada órgão estará virtualmente isolado do outro não havendo nenhum tipo de compartilhamento de dados entre as instâncias. A empresa disponibilizará os recursos necessários para o correto provimento da solução.

Após a contratação do serviço, toda a parte de gerenciamento da infraestrutura, disponibilidade 24x7, backup e monitoramento fica a cargo da empresa provedora.

O modelo seria um Saas – Software as a service, porém o órgão solicitante terá acesso aos elementos básicos para atender ao negócio e também a sua TI interna. O órgão terá acesso ao backup de suas bases, logs de acesso a aplicação e poderá fornecer o acesso ao AD do órgão para que a autenticação ocorra de acordo com a política interna de senhas do órgão.

Modelo de Implantação Descentralizado

Nesse modelo, o próprio órgão será responsável por manter sua infraestrutura ao longo dos anos. Esse modelo, de acordo com a nossa experiência, tende a ser mais passível de falhas, uma vez que os órgãos sofrem mutações em sua composição e eventualmente as equipes de TI, orçamento e priorizações mudam ao longo do tempo.

Além disso cada órgão possui, por exemplo, know-how em determinado SO diferente do RedHat, versão de banco e virtualizadora. O SEI vai funcionar adequadamente, porém não raro aparecem particularidades nesses componentes que não estão catalogadas, necessitando troubleshoot ou adequações depois do sistema estar no ar, gerando necessidade de análise e suporte para sanar tais problemas.

Fique Esperto!

O principal risco relacionado ao sistema SEI é a perda de informação.

Para garantir a perda zero de informação - aqui não estamos falando de backup apenas -, o órgão precisa suprir redundância em localidades geograficamente distintas. Isso é um limitador que, se ignorado, poderá causar estrago. Às vezes o negócio suporta determinada janela de perda, mas, outras vezes, isso não é aceitável ou impraticável. Por isso, esse requisito deverá ser analisado em conjunto com o negócio do órgão para definir as políticas de Disaster Recovery adequadas.

Outros pontos que são importantes:

• Disponibilidade
• Tempo de resposta
• Segurança

Os itens acima devem ser tratados com importância alta, visto que, ainda que o ambiente esteja imune a perda de informações, se os colaboradores não conseguirem acessá-lo para trabalhar em seus processos e documentos, há perda negocial de igual maneira.

Caso não se tenha mecanismos de gerenciamento ou pessoas habilitadas, o custo de se manter a infraestrutura própria cresce.  O crescimento do número de soluções impede, também, a adoção de novas soluções em tempo adequado. Ter que monitorar e manter novas soluções é um custo que deve ser observado.

Alternativa de infraestrutura

No modelo centralizado de distribuição (ver maiores detalhes acima), que é o mais recomendado, o PEN dispõe de parceria estabelecida com a Dataprev.

Toda a infraestrutura, neste caso, é provisionada por processos automatizados e existe um cuidado na parte de redundância/backup dos dados.  

A distribuição também é transparente aos órgãos, uma vez que os dados pertencem ao órgão e este poderá solicitar a cópia dos seus dados sempre que necessário, bem como dos acessos que aconteceram na plataforma.

Links importantes

• Repositório do SEI, de acesso restrito - https://github.com/pengovbr/sei/
  
• Container para ambientes de treinamento e de desenvolvimento, podendo ser usado pelo time de arquitetura pra maior esclarecimento dos componentes do sistema - https://github.com/spbgovbr/sei-docker 

Atenção! Não use este projeto em produção, uma vez que ele não foi desenhado para tal finalidade e não oferece garantia de integridade dos componentes.

• Base de Dados do Poder executivo - https://github.com/spbgovbr/sei-db-ref-executivo
  
• Testes de carga para o SEI - https://github.com/pengovbr/super-loadtests
  
• Manuais do PEN - https://manuais.processoeletronico.gov.br/
  
• Formulário de custo de implantação do SEI (clique e acesse)
  

Elementos necessários para a implantação das soluções do PEN

O time de arquitetura deverá entender o manual de instalação.

Será trabalho dele entender a finalidade de cada componente da infra (Banco, Balanceador, Aplicação, Cache, Solr) bem como elaborar, de acordo com a capacidade do órgão, uma estratégia de infraestrutura para o SEI capaz de suportar as necessidades do órgão.

Cada componente poderá ser utilizado de forma isolada ou em cluster com crescimento horizontal. A necessidade de cluster para cada componente deverá ser estabelecida pelo arquiteto responsável, de acordo com a necessidade do órgão.

Na maioria das instalações, os componentes rodam em instância única, com exceção da Aplicação que é escalável horizontalmente. Para o banco de dados é obrigatório a presença de um DBA capacitado para tunning e Disaster Recovery dos dados.

A equipe de infra também deve ser capaz de instanciar e suportar, no dia a dia, os demais componentes e resolver eventuais conflitos que possam ocorrer durante o uso dos mesmos.

Além dos requisitos explícitos dos componentes, o time deve levar em consideração os demais ativos para que o serviço se mantenha no ar ao longo dos anos, bem como seus contratos e licenças necessárias.

Segue lista não exaustiva destes componentes:

- links de internet
- storage
- virtualizadora
- rede / switchs / roteadores  
- filtros de conteúdo
- firewall
- Certificados A1
- ferramentas de backup
- cofre de armazenamento
- ferramentas de monitoramento
- serviços de Autenticação: AD / Ldap
- Scanners
- Tokens de Assinatura
- Suporte a Sistemas Operacionais (RedHat, por ex)

Itens Obrigatórios:
Os itens abaixo devem ser observados à risca. A sua inobservância poderá levar a perda dos dados gerando prejuízos incalculáveis à Administração Pública.

Réplica da base de dados do SEI1:

    > Réplica 1: montada na mesma rede ou rede mais próxima a aplicação, deve ter a menor latência possível;

    > Réplica 2: montada em infra separada para garantir os dados em caso de incêndio ou inundação, por exemplo.

Tanto o banco quanto suas réplicas devem ter a capacidade de, a partir de um backup prévio, serem capazes de remontar a linha de base gradativamente até data/hora desejada no passado (conceito dos logs binários no MySQL)

A ferramenta de monitoramento deve sinalizar falta grave caso as réplicas não estejam acontecendo.

O arquiteto poderá usar artifícios de sua infra, como replicação automática direto na virtualizadora ou storage, desde que garanta a completa recuperação dos dados em caso de necessidade, de acordo com o elucidado acima.  

Backup:

> Política de backup deve ser montada baseada nas necessidades do órgão;
> a guarda do backup deve garantir desastres graves: incêndio, por exemplo;
> a ferramenta de monitoramento deve sinalizar falta grave caso a política de backup não esteja sendo seguida;
> a janela do backup deve estar em acordo com as necessidades aceitas pelo negócio.
    
Segurança:
    
> Atributos que a equipe deverá levar em consideração referentes a segurança. Segue lista não exaustiva:
> guarda do proxy
> firewall
> filtro de conteúdo
> controle, prevenção e mapeamento de ataques externos
> administração das senhas no AD/Ldap

Quem fez, fez como?

Via de regra, a recomendação é seguir as orientações no manual de instalação original. Todo o sistema é testado e construído pensando na arquitetura atual do TRF4. Essa seria a referência inicial. Porém, alguns órgãos utilizam tecnologias diferentes das utilizadas pelo TRF4 com sucesso.

Existem, em produção, órgãos utilizando diversas tecnologias com sucesso:

• Nuvem;
• Kubernetes;
• Cattle;
• Debian (SO de aplicação, porém menos utilizado, sendo recomendado RedHat ou CentOS);
• Outros balanceadores, que não o Apache, como o Nginx, o Hapoxy ou o F5;
• Ambientes virtualizados em Vmware ou Nutanix