EAPn - Contribuições do usuário [pt-br]

Conceitos Chave - BPM, BPMS, Bonita, Tomcat, Git, Metabase e EPM

2026-09-28T21:44:18Z

150.162.57.24:

==Processo==

Processo é uma agregação de atividades e comportamentos
executados por humanos ou máquinas para alcançar um ou mais
resultados. (ABPMP BPM CBOK V3.0)

==BPM==

Sigla para Gerenciamento de Processos de Negócio (Business Process Management), é uma estratégia de gerenciamento de operações organizacionais através de processos. Tem como base a visualização das operações de negócio como processos, que, na prática gerecial do BPM, passam por planejamento, análise, design e modelagem, implementação, monitoramento e controle e por último, refino, com o intuito de trazer benefícios ao funcionamento da organização. Também tem como fator chave a visão sistêmica, a partir da compreensão acerca do relacionamento entre os processos, assim como a integração entre as diversas áreas e departamentos da organização.

Ver mais em [[Conceitos Aprofundados - BPM, BPMS, EPM]].

==BPMS==
Sigla para Sistemas de Gerenciamento de Processos de Negócio (Business Process Management Systems), são as ferramentas/softwares usadas principalmente para dois tipos de propósitos: criar descrições de processos (em termos de suas atividades constituintes), que podem ser usadas para apoiar a análise de processos, simulação e esforços de projeto; e gerar código executável que suporte o desempenho de um processo, automatizando determinadas etapas do processo, integrando sistemas e bancos de dados utilizados pelo processo e gerenciando o fluxo de trabalho de documentos e outros formulários que passam pelo processo.

Ver mais em [[Conceitos Aprofundados - BPM, BPMS, EPM]].

==Bonita==
O Bonita é uma plataforma open-source de gerenciamento de processos de negócios e desenvolvimento Low-code criada em 2001. A tecnologia Bonita foi desenvolvida originalmente em 2001 por Miguel Valdés Faura, no Instituto Francês de Pesquisa em Ciência da Computação e Automação , e posteriormente transferida para o Groupe Bull . Em 2009, o Diretor da divisão BPM, Miguel Valdes Faura, fundou a Bonitasoft, que é uma fornecedora francesa de software de código aberto. E também o principal software usado neste laboratório.
 
O Bonita possui 3 ambientes, o Bonita Studio, o Bonita Portal e o UI Designer, sendo cada um deles caracterizados por:

* O Bonita Studio é o ambiente principal de desenvolvimento do BPMS Bonita. Nele são criados os diagramas com suas regras de negócio e objetos de dados.
* O Bonita Portal é o ambiente em que o usuário final tem acesso, podendo executar os processos automatizados.
* O UI Designer é o ambiente de desenvolvimento das interfaces com o usuário, geralmente no formato de formulários, que serão utilizados pelo usuário final na execução dos processos automatizados.

==Tomcat==

O software Tomcat, desenvolvido pela Fundação Apache, permite a execução de aplicações para web. Sua principal característica técnica é estar centrada na linguagem de programação Java, mais especificamente nas tecnologias de Servlets e de Java Server Pages (JSP). Ele prove um ambiente HTTP web server de "Java puro", no qual pode ser rodado código Java.

o Tomcat é disponibilizado gratuitamente e possui código aberto.

==Git==

É um sistema de controle de versões distribuído, que pode ser utilizado para registrar o histórico de edições de qualquer tipo de arquivo, sendo mais comumente usado no desenvolvimento de Software. Diversos websites provêm hospedagem gratuita de repositórios Git, como o GitHub, GitLab, Bitbucket...

==Metabase==
O Metabase é uma solução open-source de B.I (Business Intelligence) que atua no mesmo servidor de processos da UFSC, e utiliza as bases de dados gerados neste servidor, para construir, explorar, analisar gráficos e dashboards. Com esta visualização produzida pelo Metabase, conseguimos elaborar os melhores caminhos a serem tomados para a evolução dos processos que estão rodando, além de embasar e fortificar o trabalho que está sendo feito no EAPn.

==EPM==
O gerenciamento de desempenho empresarial (EPM) é o conjunto de práticas, processos e ferramentas de negócios que permitem às organizações planejar e avaliar melhor seus objetivos estratégicos e sua execução tática para acompanhar o desempenho e o sucesso da organização.

==Zabbix==

O Zabbix é um software que monitora vários parâmetros da rede, dos servidores e da saúde dos serviços. Utiliza-se de um mecanismo flexível de notificação que permite configurar alertas por e-mail para praticamente qualquer evento. Esse mecanismo é utilizado para notificação do script de backup do servidor. As notificações permitem que se reaja rapidamente à problemas no ambiente. O Zabbix oferece excelentes recursos de relatórios e visualização de dados armazenados. Isso faz com que o Zabbix seja a ferramenta ideal para planejamento de capacidade.

Arquitetura do Sistema de Backup

2026-09-28T18:45:08Z

150.162.57.24:

Esta página visa documentar a arquitetura, componentes, interface e fluxo de dados do *servidor de backup*, de forma a garantir que o sistema atenda os requerimentos especificados. Tal documentação atua como um guia para os desenvolvedores, testers e stakeholder durante todo o ciclo de vida do sistema. É importante destacar que certos termos foram mantidos em inglês devido a dificuldade de achar uma tradução adequada, bem como a maior facilidade de busca por tais conceitos utilizando-se de seus nomes em inglês.

== Visão geral e Objetivo ==

O laboratório, onde o EAPn se hospeda, abriga um servidor de backup, responsável por garantir a integridade dos dados do servidor de produção. Sua janela de execução ocorre todos os dias às 08:00 da manhã, via script.

==Topologia e Arquitetura==

===Fluxo de Dados===

O fluxo de dados segue 3 etapas: Servidor de Produção -> Dev2 -> Servidor de Backup

#O servidor de produção faz a extração de seus banco de dados, compacta os arquivos em LZMA e os envia para o servidor intermediário.
#O servidor dev2 atua como zona de transferência, recebendo os arquivos e armazenando temporariamente num diretório compartilhado. Arquitetado dessa forma, o processo de leitura dos backup's não consome poder de processamento do servidor de produção.
#Todo dia, às 8h da manhã, o servidor de backup liga sozinho, conecta-se ao dev2, via mapeamento de rede, utilizando-se do protocolo NFS(/nfs/backup), extraindo os dados para si. Os arquivos são gravados no sistema ZFS, espelhando os dados em 3 discos simultaneamente.

===Camadas de Rede e Protocolos===
'''Transporte Local:''' Montagem de diretório via rede usando NFS + AutoFS(montagem sob demanda)

'''Sincronização:''' Rsync da parte do servidor de backup

'''Gerenciamento:''' Acesso remoto via SSH

'''Monitoramento:''' Monitoramento dos scripts de backup via Zabbix e Monitoramento do servidor de produção via StatusCake

==Armazenamento==

'''Tecnologia:''' ZFS (Zettabyte File System)

'''Nome da pool:''' "dados"

'''Topologia:''' Espelhamento triplo (mirror-0). O ZFS grava o mesmo arquivo simultaneamente em 3 HD's. Se um ou dois discos queimarem, os dados permanecem intactos.

==Lógica de Automação==

A automação de backup ocorre via Shell Script.

'''Srcipt:''' /home/eapn/syncwithdev2.sh (também disponível na página do códigos UFSC, tanto com automação zabbix, quanto a versão antiga, sem automação)

'''

==Comandos Úteis ao Administrador==

É possível encontrar informações relacionadas a como realizar a manutenção do servidor na [[Runbook de Manutenção e Troubleshooting do Servidor de Backup com Zabbix]]

Arquitetura do Sistema de Backup

2026-09-28T18:34:44Z

150.162.57.24:

Esta página visa documentar a arquitetura, componentes, interface e fluxo de dados do *servidor de backup*, de forma a garantir que o sistema atenda os requerimentos especificados. Tal documentação atua como um guia para os desenvolvedores, testers e stakeholder durante todo o ciclo de vida do sistema. É importante destacar que certos termos foram mantidos em inglês devido a dificuldade de achar uma tradução adequada, bem como a maior facilidade de busca por tais conceitos utilizando-se de seus nomes em inglês.

== Visão geral e Objetivo ==

O laboratório, onde o EAPn se hospeda, abriga um servidor de backup, responsável por garantir a integridade dos dados do servidor de produção. Sua janela de execução ocorre todos os dias às 08:00 da manhã, via script.

==Topologia e Arquitetura==

===Fluxo de Dados===

O fluxo de dados segue 3 etapas: Servidor de Produção -> Dev2 -> Servidor de Backup

#O servidor de produção faz a extração de seus banco de dados, compacta os arquivos em LZMA e os envia para o servidor intermediário.
#O servidor dev2 atua como zona de transferência, recebendo os arquivos e armazenando temporariamente num diretório compartilhado. Arquitetado dessa forma, o processo de leitura dos backup's não consome poder de processamento do servidor de produção.
#Todo dia, às 8h da manhã, o servidor de backup liga sozinho, conecta-se ao dev2, via mapeamento de rede, utilizando-se do protocolo NFS(/nfs/backup), extraindo os dados para si. Os arquivos são gravados no sistema ZFS, espelhando os dados em 3 discos simultaneamente.

===Camadas de Rede e Protocolos===
'''Transporte Local:''' Montagem de diretório via rede usando NFS + AutoFS(montagem sob demanda)

'''Sincronização:''' Rsync da parte do servidor de backup

'''Gerenciamento:''' Acesso remoto via SSH

'''Monitoramento:''' Monitoramento dos scripts de backup via Zabbix

==Armazenamento==

'''Tecnologia:''' ZFS (Zettabyte File System)

'''Nome da pool:''' "dados"

'''Topologia:''' Espelhamento triplo (mirror-0). O ZFS grava o mesmo arquivo simultaneamente em 3 HD's. Se um ou dois discos queimarem, os dados permanecem intactos.

==Lógica de Automação==

A automação de backup ocorre via Shell Script.

'''Srcipt:''' /home/eapn/syncwithdev2.sh (também disponível na página do códigos UFSC, tanto com automação zabbix, quanto a versão antiga, sem automação)

'''

==Comandos Úteis ao Administrador==

É possível encontrar informações relacionadas a como realizar a manutenção do servidor na [[Runbook de Manutenção e Troubleshooting do Servidor de Backup com Zabbix]]

Arquitetura do Sistema de Backup

2026-09-28T18:33:49Z

150.162.57.24:

Esta página visa documentar a arquitetura, componentes, interface e fluxo de dados do *servidor de backup*, de forma a garantir que o sistema atenda os requerimentos especificados. Tal documentação atua como um guia para os desenvolvedores, testers e stakeholder durante todo o ciclo de vida do sistema. É importante destacar que certos termos foram mantidos em inglês devido a dificuldade de achar uma tradução adequada, bem como a maior facilidade de busca por tais conceitos utilizando-se de seus nomes em inglês.

== Visão geral e Objetivo ==

O laboratório, onde o EAPn se hospeda, abriga um servidor de backup, responsável por garantir a integridade dos dados do servidor de produção. Sua janela de execução ocorre todos os dias às 08:00 da manhã, via script.

==Topologia e Arquitetura==

===Fluxo de Dados===

O fluxo de dados segue 3 etapas: Servidor de Produção -> Dev2 -> Servidor de Backup

#O servidor de produção faz a extração de seus banco de dados, compacta os arquivos em LZMA e os envia para o servidor intermediário.
#O servidor dev2 atua como zona de transferência, recebendo os arquivos e armazenando temporariamente num diretório compartilhado. Arquitetado dessa forma, o processo de leitura dos backup's não consome poder de processamento do servidor de produção.
#Todo dia, às 8h da manhã, o servidor de backup liga sozinho, conecta-se ao dev2, via mapeamento de rede, utilizando-se do protocolo NFS(/nfs/backup), extraindo os dados para si. Os arquivos são gravados no sistema ZFS, espelhando os dados em 3 discos simultaneamente.

===Camadas de Rede e Protocolos===
'''Transporte Local:''' Montagem de diretório via rede usando NFS + AutoFS(montagem sob demanda)

'''Sincronização:''' Rsync da parte do servidor de backup

'''Gerenciamento:''' Acesso remoto via SSH

'''Monitoramento:''' Monitoramento dos scripts de backup via Zabbix

==Armazenamento==

'''Tecnologia:''' ZFS (Zettabyte File System)

'''Nome da pool:''' "dados"

'''Topologia:''' Espelhamento triplo (mirror-0). O ZFS grava o mesmo arquivo simultaneamente em 3 HD's. Se um ou dois discos queimarem, os dados permanecem intactos.

==Lógica de Automação==

A automação de backup ocorre via Shell Script.

'''Srcipt:''' /home/eapn/syncwithdev2.sh (também disponível na página do códigos UFSC)

'''

==Comandos Úteis ao Administrador==

É possível encontrar informações relacionadas a como realizar a manutenção do servidor na [[Runbook de Manutenção e Troubleshooting do Servidor de Backup com Zabbix]]

Arquitetura do Sistema de Backup

2026-09-04T17:45:31Z

150.162.57.24:

Esta página visa documentar a arquitetura, componentes, interface e fluxo de dados do *servidor de backup*, de forma a garantir que o sistema atenda os requerimentos especificados. Tal documentação atua como um guia para os desenvolvedores, testers e stakeholder durante todo o ciclo de vida do sistema. É importante destacar que certos termos foram mantidos em inglês devido a dificuldade de achar uma tradução adequada, bem como a maior facilidade de busca por tais conceitos utilizando-se de seus nomes em inglês.

== Visão geral e Objetivo ==

O laboratório, onde o EAPn se hospeda, abriga um servidor de backup, responsável por garantir a integridade dos dados do servidor de produção. Sua janela de execução ocorre todos os dias às 08:00 da manhã, via script.

==Topologia e Arquitetura==

===Fluxo de Dados===

O fluxo de dados segue 3 etapas: Servidor de Produção -> Dev2 -> Servidor de Backup

(ver como citar o NFS)
#O servidor de produção faz a extração de seus banco de dados, compacta os arquivos em LZMA e os envia para o servidor intermediário.
#O servidor dev2 atua como zona de transferência, recebendo os arquivos e armazenando temporariamente num diretório compartilhado. Arquitetado dessa forma, o processo de leitura dos backup's não consome poder de processamento do servidor de produção.
#Todo dia, às 8h da manhã, o servidor de backup liga sozinho, conecta-se ao dev2, via mapeamento de rede, utilizando-se do protocolo NFS(/nfs/backup), extraindo os dados para si. Os arquivos são gravados no sistema ZFS, espelhando os dados em 3 discos simultaneamente.

===Camadas de Rede e Protocolos===
'''Transporte Local:''' Montagem de diretório via rede usando NFS + AutoFS(montagem sob demanda)

'''Sincronização:''' Rsync da parte do servidor de backup

'''Gerenciamento:''' Acesso remoto via SSH

==Armazenamento==

'''Tecnologia:''' ZFS (Zettabyte File System)

'''Nome da pool:''' "dados"

'''Topologia:''' Espelhamento triplo (mirror-0). O ZFS grava o mesmo arquivo simultaneamente em 3 HD's. Se um ou dois discos queimarem, os dados permanecem intactos.

==Lógica de Automação==

A automação de backup ocorre via Shell Script.

'''Srcipt:''' /home/eapn/syncwithdev2.sh (também disponível na página do códigos UFSC)

'''

==Comandos Úteis ao Administrador==

É possível encontrar informações relacionadas a como realizar a manutenção do servidor na [[Runbook de Manutenção e Troubleshooting do Servidor de Backup|página de runbook da wiki.]]

Arquitetura do Sistema de Backup

2026-08-27T17:16:31Z

150.162.57.24:

Esta página visa documentar a arquitetura, componentes, interface e fluxo de dados do *servidor de backup*, de forma a garantir que o sistema atenda os requerimentos especificados. Tal documentação atua como um guia para os desenvolvedores, testers e stakeholder durante todo o ciclo de vida do sistema. É importante destacar que certos termos foram mantidos em inglês devido a dificuldade de achar uma tradução adequada, bem como a maior facilidade de busca por tais conceitos utilizando-se de seus nomes em inglês.

== Visão geral e Objetivo ==

O laboratório, onde o EAPn se hospeda, abriga um servidor de backup, responsável por garantir a integridade dos dados do servidor de produção. Sua janela de execução ocorre todos os dias às 08:00 da manhã, via script.

==Topologia e Arquitetura==

===Fluxo de Dados===

O fluxo de dados segue 3 etapas: Servidor de Produção -> Dev2 -> Servidor de Backup (fazer um diagrama depois)

(ver como citar o NFS)
#O servidor de produção faz a extração de seus banco de dados, compacta os arquivos em LZMA e os envia para o servidor intermediário.
#O servidor dev2 atua como zona de transferência, recebendo os arquivos e armazenando temporariamente num diretório compartilhado. Arquitetado dessa forma, o processo de leitura dos backup's não consome poder de processamento do servidor de produção.
#Todo dia, às 8h da manhã, o servidor de backup liga sozinho, conecta-se ao dev2, via mapeamento de rede, utilizando-se do protocolo NFS(/nfs/backup), extraindo os dados para si. Os arquivos são gravados no sistema ZFS, espelhando os dados em 3 discos simultaneamente e protegendo contra bit-roting.

===Camadas de Rede e Protocolos===
'''Transporte Local:''' Montagem de diretório via rede usando NFS + AutoFS(montagem sob demanda)

'''Sincronização:''' Rsync da parte do servidor de backup(?)

'''Gerenciamento:''' Acesso remoto via SSH

==Armazenamento==

'''Tecnologia:''' ZFS (Zettabyte File System)

'''Nome da pool:''' "dados"

'''Topologia:''' Espelhamento triplo (mirror-0). O ZFS grava o mesmo arquivo simultaneamente em 3 HD's. Se um ou dois discos queimarem, os dados permanecem intactos.

==Lógica de Automação==

A automação de backup ocorre via Shell Script.

'''Srcipt:''' /home/eapn/syncwithdev2.sh (também disponível na página do códigos UFSC)

'''

==Comandos Úteis ao Administrador==

Acesso ao Servidor:
<pre>$ ssh eapn@150.162.57.10</pre>

Como não há comando fsck(comando no linux para verificar e reparar inconsistências nos arquivos) para o ZFS, precisamos utilizar o scrub. Esse subcomando é um verificador de consistência dinâmica. Ele roda de plano de fundo em um mounted live filesystem.

Sintaxe para conferência da integridade de dados("dados" é o nome da pool do nosso sistema de backups):
<pre>$ zpool scrub nome_da_pool</pre>

Confira o andamento do comando anterior e a saúde do sistema:
<pre>$ zpool status -v nome_da_pool</pre>

Conferência do log diário do servidor:
<pre>$ tail -n 15 /home/eapn/syncwithdev2.log</pre>

Listagem das datas em que o script rodou (É possivel alterar a quantidade de dias ao mudar o número após "-n"):
<pre>$ grep "starting script" /home/eapn/syncwithdev2.log | tail -n 10</pre>

Conferência de erros:
<pre>$ grep -iE "error|failed|denied" /home/eapn/syncwithdev2.log | tail -n 10</pre>

Backup manual (espelha os dados da rede para o disco local):
<pre>$rsync -auv /nfs/backup/ /dados/backup</pre>