Com base na arquitetura apresentada acima detalharemos a implementação para uma possível validação do artefato em questão.
O desenvolvimento do componente foi baseado no padrão MVC (Model-view- controller). É um padrão de arquitetura de software que divide um determinado aplicativo de software em três partes interligadas, de modo a separar as representações internas das informações das formas em que a informação é apresentada ou aceita pelo usuário.
A figura 8 detalha os componentes do MVC:
Figura 8 – Model-View-Controller - MVC
Capítulo 5. PROPOSTA 59
Model (Modelo): Especifica a estrutura lógica dos dados em uma aplicação de software e a classe de alto nível associada a ele. É a representação específica do domínio dos dados que descreve o funcionamento de um aplicativo. Quando um modelo muda seu estado, o domínio notifica suas visualizações associadas para que possam atualizar.
View (Apresentação): O componente de visualização é usado para toda a lógica da UI - User Interface (tudo que é visualmente perceptível levando o usuário a uma interação) (SHNEIDERMAN, 2010) da aplicação são os componentes que exibem a interface do usuário (UI) do aplicativo. Isso torna o modelo em uma forma adequada para interação. Podem existir várias visualizações para um único modelo e diferentes fins.
Controller (Controle): os controladores atuam como uma interface entre os com- ponentes do modelo e da apresentação. Ele processa toda a lógica e solicitações recebidas, manipula dados usando o componente modelo e interage com a apresenta- ção para renderizar a saída final. Ele recebe uma entrada e inicia uma resposta fazendo chamadas em objetos modelos.
Também foi utilizado o framework spring boot baseado na linguagem Java. O Spring Boot (SOFTWARE, 2017) é um projeto que veio para facilitar o processo de configuração e publicação de aplicações rodando o mais rápido possível e sem complicação. Trata-se de mais um framework, mas talvez a melhor denominação seja microframework. Com o objetivo de não trazer novas soluções para problemas que já foram resolvidos, mas sim reaproveitar essas soluções e aumentar a produtividade do desenvolvedor.
Ele consegue isso favorecendo a convenção sobre a configuração. Basta que você diga para ele quais módulos deseja utilizar (WEB, Template, Persistência, Segu- rança, etc.) que ele vai reconhecer e configurar.
Escolhe-se os módulos que deseja através dos starters que inclui no pom.xml ou gradle.xml do seu projeto, sendo o starter gradle (GRADLE, 2017) o adotado no projeto em questão. Os starters, basicamente, são dependências que agrupam outras dependências deixando-as organizadas.
Apesar do Spring Boot facilitar uma pré-configuração, nada impede que você crie as suas customizações caso sejam necessárias. O maior benefício do Spring Boot é que ele nos deixa mais livres para pensarmos nas regras de negócio da nossa aplicação(SOFTWARE, 2017) .
Na figura 7 pode-se detalhar particularidades da implementação das 5 partes conceituais da arquitetura:
Easy Rules é um simples, mas poderoso, motor de regras Java proporcionando as seguintes características: estrutura leve e fácil de aprender; desenvolvimento baseado em POJO; abstrações úteis para definir regras de negócios e aplicá-los facilmente com a capacidade de criar regras primitivas e compostas (HASSIN, 2017) .
Sobre mecanismos de regras, Martin Fowler diz:
“Você pode construir um simples motor de regras sozinho. Tudo que você precisa é criar vários objetos com condições e ações, armazená- los em uma coleção, e executar através de uma avaliação da condição e executar a ação”(Fowler (2017) , tradução do autor)
Isto é exatamente o que é Easy Rules, a classe Rule, fornece, abstração para criar regras com condições e ações. A API RulesEngine é executada através de um conjunto de regras para avaliar as condições e executar ações.
Para a base da dados de histórico das ocorrências de indisponibilidades, na arquitetura foi utilizada a base de dados H2 Database Engine (MUELLER, 2004). É um banco de dados SQL contruído a partir da linguagem de programação Java e tem características como: ser leve; ser opensource; ser baseado na API JDBC; trabalhar de forma embarcado, modo servidor e em memória; e possuir aplicação console baseada em browsers. A função do banco de dados é guardar informações de ocorrência de falhas . Falhas estas registradas em um padrão com uma identificação única para ocorrência, uma descrição do recurso gerenciado e a data e hora da ocorrência.
No agente de interface com o sistema gerenciado foi implementado uma classe(Wrapper) para chamadas em shellscript fazendo o papel de agente execendo a função de sen-
sor(Sensor) e atuador (Effector).
O papel dos sensores é captar informações de um determinado recurso do sistema gerenciado, enquanto o dos atuadores é executar comandos em um determi- nado ambiente. No ambiente onde se hospeda o recurso é instalado um terminal para executar comando shellscript. No ambiente em questão foi utilizado o terminal nativo do sistema operacional Linux.
Na interface de monitoramento com o componente foi desenvolvida uma ca- mada de endpoints onde são disponibilizados interfaces REST(Representational State Transfer ou Transferência de Estado Representacional).
Fielding e Taylor (2002) definem o REST como um estilo arquitetural desen- volvido como um modelo abstrato da arquitetura Web e usado para orientar nosso redesenho e definição do Protocolo de Transferência de Hipertexto e Identificadores de Recursos Uniformes.
Lecheta (2015) reitera que REST basea-se em um conjunto de técnicas de desenvolvimento de webservices fortemente baseado nos métodos do protocolo
Capítulo 5. PROPOSTA 61
HTTP(GET, POST,PUT, DELETE), sendo que webservices construídos com essas técnicas são denominados RESTful (LECHETA, 2015).
Na representação dos dados que trafegam entre essas interfaces foi optado pelo JSON. Json é abreviação de JavaScript Object Notation e é uma maneira de armazenar informações de forma organizada e de fácil acesso. Em poucas palavras, nos dá uma coleção de dados legíveis por humanos que podemos acessar de forma realmente lógica. Com a ascensão dos sites com AJAX é imprecindível carregar dados de forma rápida e assíncrona, ou em segundo plano, sem atrasar a renderização da página (JSON, 2017).
Algumas características JSON(JSON, 2017):
• JSON requer menos tags, pois apenas nomeia a etiqueta uma vez;
• Como JSON é independente do transporte, você pode simplesmente ignorar o objeto XMLHttpRequest para obter seus dados;
• O JavaScript não é apenas dados, você também pode colocar métodos e todos os tipos no formato JSON;
• JSON ajuda nas decisões processuais em seu JavaScript com base em objetos e seus valores (ou métodos);
• Você pode obter dados JSON de qualquer lugar, não apenas de seu próprio domínio;
• JSON é de fácil leitura.
As três interfaces (URL’s RESTFul) de monitoramento são:
element: exibe estado atual do sistema como um todo, detalhando o estado do sistema gerenciado, como a descrição e estado dos recursos do sistema.
Figura 9 – Interface element
resources: exibe o estado atual dos recursos, assim como outras propriedades.
Figura 10 – Interface resources
Fonte: Autor (2017).
log: exibe histórico de ocorrências de indisponibilidades do sistema.
Figura 11 – Interface log
Fonte: Autor (2017).
Na parte de Contingência e Segurança, a cada sequência de três ocorrências , em um determinado tempo, para o mesmo recurso do sistema gerenciado, mas sem sucesso na recuperação, é disparado um e-mail para um contato administrador do sistema. Quanto à segurança, a interação com outro sistema ou usuário foi o ponto crítico avaliado a ser tratado segurança com maior importância, ou seja, na interface agente com o sistema gerenciado e na interface de monitoramento do componente.
Na interface agente com o sistema gerenciado, foi utilizado conexão por VPN (Virtual Private Network).Também foi utilizado SSH(Secure Shell), uso da API SSHJ, com chaves assimétricas. O Secure Shell (SSH) é um protocolo de rede criptográfico para operação de serviços de rede de forma segura (YLONEN, 2006). Já uma comuni- cação baseada em chaves assimétricas, figura 12, consiste num par de chaves: uma chave pública e uma privada. A chave pública pode e deve ser divulgada para a parte remota da comunicação, enquanto a chave privada, como o próprio nome diz deve permanecer guardada. Numa comunicação deste tipo os dados cifrados pela chave pública podem ser apenas decifrados pela sua chave privada (ZOCHIO, 2016).
Capítulo 5. PROPOSTA 63
Figura 12 – Chaves assimétricas
Fonte: Autor (2017).
Na interface de monitoramento foi utilizado o modo Basic Autentication para autenticação de web services REST que tem como função proteger o acesso à web ser- vices de modo que seja necessário login e senha para autorizar um acesso (LECHETA, 2015).
Figura 13 – Diagrama de classe
Fonte: Autor (2017).
Capítulo 5. PROPOSTA 65
de aplicação (BOOTSTRAP, 2017) são disponibilizadas interfaces de monitoramento dos recursos de um sistema de informação, os quais o componente gerencia e também é carregado um motor de regras, com um agendamento pré-definido para verificação de status desses recursos. A cada verificação, período pré-definido em um arquivo de configuração do spring boot, por meio de sensores que são executados através de um agente de interface com o sistema gerenciado, são capturados estados do(s) recurso(s) de um determinado sistema de informação. Os dados capturados através dos sensores são tratados e repassados para verificação no motor de regras que, não atendendo um estado esperado, planeja e executa um atuador para restaurar um determinado recurso ao seu estado normal. Uma quantidade de tentativa(s) de restauração(ões) do estado do recurso é pré-definida e quando ultrapassada é enviado um e-mail (pré-definido no arquivo de configuração) para um administrador do sistema como contingência.
Foram feitos testes no sistema operacional windows usando a ferramenta cygwin (AUTHORS, 2017), simulador de Secure Shell - SSH para plataforma win- dows, como terminal para execução de scripts e monitorando recursos como banco de dados postgresql e o servidor de aplicação Internet Information Service(IIS).
A figura 14 mostra o diagrama de sequência que representa a sequência de processos (mais especificamente, de mensagens passadas entre objetos).
Figura 14 – Diagrama de Sequência
Fonte: Autor (2017).
5.7 Síntese do Capítulo
No capítulo foi apresentada a arquitetura proposta para o desenvolvimento de um componente para autorrecuperação de recursos de sistemas de informação. Foram detalhadas particularidades dividindo-as em 5 (cinco) partes: motor de regras e base da dados; agente de interface com o sistema gerenciado; interface de monitoramento com o componente, contingência e segurança, e ambiente de execução.
Em um segundo momento foi descrito como foi implementado um componente baseado na arquitetura e todas as tecnologias envolvidas.
Neste capítulo foi apresentado todo o processo de desenvolvimento da solu- ção proposta nessa dissertação. Assim, além do embasamento teórico do capítulo 2 e das características apresentadas que apoiaram na construção do componente baseado na arquitetura proposta nesse capítulo, buscou-se validar esses conceitos e características com a avaliação feita no capítulo a seguir.
67
6 AVALIAÇÃO DO ARTEFATO
“Alguns homens vêem as coisas como são, e dizem ‘Por quê?’ Eu sonho com as coisas que nunca foram e digo ‘Por que não?’” (George Bernard Shaw) Este capítulo apresenta, em detalhes, o contexto da avaliação, as avaliações as quais o artefato (componente baseado na arquitetura proposta) foi submetido: observa- cional e analítica, os resultados obtidos, concluindo com uma seção de discussão. 6.1 Contextualização
Realizou-se um estudo de caso em um ambiente de produção, onde foi de- senvolvido, a partir do estudo da propriedade de autocura (computação autônoma), um componente de gerenciamento autônomo para autorrecuperação de recursos de sistemas de informação
Trata-se de órgão de educação vinculado ao MEC. No IFSC (Instituto Federal de Santa Catarina), há um portfólio de 22 sistemas em média, variando entre 14 tecno- logias, a serem gerenciados. Sistemas que atendem a diversas áreas: administrativa, acadêmica, social entre outras. São sistemas de informação de extrema relevância para a instituição, pois influenciam diretamente nas atividades operacionais como também nas tomadas de decisões. Tratam-se de 30.000 (trinta mil) usuários ativos assistidos diretamente e ainda a comunidade indiretamente. Diariamente o sistemas contemplam cerca de 100 a 500 usuários em média considerando particularidades do período de acesso. Como consequências, essa variedade de sistemas resulta em redundância de atividades, fluxos de processos interrompidos, problemas de interoperabilidade entre os sistemas e a necessidade de maior controle para gerenciá-los. Essas consequências geram uma demanda considerável de ocorrências de indisponibilidade de serviços assim afetando diretamente os mesmos.
O contexto é de uma integração entre sistemas da instituição com o propósito de reduzir atividades redundantes, evitar erros de entradas por parte do usuário, manter fluxos de processos.
Os problemas no contexto exposto eram: cadastros em vários sistemas resul- tando em atividades redundantes; erros de entrada de dados; fluxo de processos interrompidos; falta de análise de dados para melhora dos fluxos; muitas ocorrências de chamados (resultado dos problemas anteriores). Esses problemas relatados geravam muita insatisfação dos usuários com o uso dos serviços.
O objetivo do experimento é ter um maior controle sobre essa integração po- dendo recuperá-la ao estado normal, se ocorrer alguma falha de recurso, sem ou com a mínima intervenção dos administradores de sistemas, tornando em um ambi- ente autogerenciável, assim reduzindo o número de ocorrência de chamados, um dos parâmetros utilizado como medição.
O estudo de caso foi aplicado em um ambiente com arquitetura SOA, trata- se de midlleware de integração composta por 4 (quatro) sistemas do portfólio da instituição. Sistemas estes desenvolvidos com diversas tecnologias como: Java, PHP, Oracle Forms, C# .Net, Oracle Database, MySql, PostgreSql, OpenLDAP entre outras. Hospedados em uma infraestrutura virtualizada.
O ambiente de execução isolado para deploy do componente a validar foi criado a partir do ambiente de execução do midlleware. A intenção foi usar as tecnologias já em execução na instituição.
O ambiente de execução do midlleware de integração roda em uma máquina virtual com sistema operacional Linux, distribuição Ubuntu Server, com o servidor de aplicação wildfly com interface administrador web por autenticação.
Os diagramas de implantação representados pelas figuras 15 e 16, mostram o ambiente antes e depois da aplicação do componente .
Figura 15 – Ambiente sem componente
Capítulo 6. AVALIAÇÃO DO ARTEFATO 69
Figura 16 – Ambiente com componente
Fonte: Autor (2017).
6.2 Metodologia
A escolha da metodologia deu-se em função do objetivo geral desse trabalho que é “melhorar a disponibilidade de sistemas de informação, por meio de uma arqui- tetura desenvolvida, baseada em recuperação autônoma, de modo que sistemas de informação se autorrecuperem de falhas, reduzindo o tempo de indisponibilidade com a mínima intervenção humana, a fim de que usuários tenham uma melhor experiência com sistemas de informação não apresentando de forma transparente possíveis falhas”. Nesse intuito, conduziu-se a avaliação do artefato(componente) desenvolvido, levando em consideração o método de pesquisa DSR.
A pesquisa sustentada pela DSR não pode estar voltada somente ao desenvol- vimento do artefato em si, mas a partir de avaliações, apresentar evidências de que o artefato poderá ser utilizado para resolver problemas reais (HEVNER; CHATTERJEE, 2010).
Das cinco formas de avaliação do artefato: observacional, analítica, experi- mental, teste e descritiva, foram selecionadas duas: observacional e analítica a partir dos requisitos dos métodos e técnicas aos quais o contexto atendia.
Nesse trabalho foi desenvolvida uma avaliação prática, levando em consideração métodos e técnicas de duas das formas de validação do DSR, representadas com as seguintes características:
Observacional: O principal objetivo é verificar como se comporta o artefato em um ambiente real podendo ser realizado com o apoio de elementos do estudo de caso, sendo o pesquisador um observador, sem interações diretas com o ambiente.
Analítica: O principal objetivo é verificar o desempenho do artefato, quanto ele consegue melhorar o sistema agregado a partir de sua arquitetura interna (a forma de acoplamento com o sistema de informação) e como interage com o ambiente externo (uma análise dinâmica do uso de recursos do ambiente).
A avaliação do componente baseado na arquitetura proposta foi mensurada a partir do tempo de inatividade do midlleware de integração até sua regeneração vol- tando a atividade.
A tabela 5, demonstra as variáveis aferidas, a ferramenta utilizada, o período de avaliação (entre janeiro de 2016 a setembro de 2017) e a forma de avaliação. A divergência dos períodos das formas de avaliaçao é devida por se tratar de um ambiente de produção onde as varíaveis observacionais poderam ser recuperadas de um momento passado, ao contrário das analíticas.
Tabela 5 – Variáveis, ferramentas, períodos e forma de avaliação
Variável aferida Ferramenta Período Forma Avaliação Quantidade de ocorrências de
indisponibilidade Zabbix Trimestral Observacional
Demanda de chamados OTRS Trimestral Observacional
Tempo médio entre falhas (MTBF) Fórmula
matemática Trimestral Observacional
Tempo médio para reparo (MTTR) Fórmula
matemática Trimestral Observacional
Média percentual do consumo CPU -
sem/com componente no ambiente nmon 360
Capítulo 6. AVALIAÇÃO DO ARTEFATO 71
Variável aferida Ferramenta Período
Forma Avalia- ção Faixa de consumo de memória - sem/com
componente no ambiente nmon
360
minutos Analítica
Faixa de recebimento em KiB/s (Throughput) -
sem/com componente no ambiente speedometer
30
minutos Analítica
Faixa de recebimento em KiB/s (Throughput) -
sem/com componente no ambiente speedometer
30
minutos Analítica Fonte: Autor (2017).
6.3 Resultados
Foram formatados relatórios para explanação dos resultados a considerar. Um primeiro relatório que comparou dados de monitoramento de inatividade do sistema extraído da ferramenta Zabbix com a quantidade de verificações de indisponibilidade do recurso gerenciado e a quantidade de chamados originados dessas indisponibilidades, extraídos da ferramenta OTRS.
O Zabbix é uma ferramenta que pode ser utilizada para monitorar toda sua infraestrutura de rede, além de aplicações, análise de experiência de usuário e análise de causa raiz em ambientes complexos, através do servidor Zabbix e as regras de correlacionamento.
O OTRS é um dos sistemas de tickets mais flexíveis, é baseado na Web e é utilizado para Atendimento ao Cliente, Help Desk e Gestão de Serviços de TI. Com uma implementação rápida e uma fácil personalização às suas necessidades, ajuda-o a reduzir custos e a aumentar a eficiência e a transparência da sua comunicação organizacional.
Para chegar a valores apreciáveis foi considerado o período de janeiro de 2016 a setembro de 2017, detalhando trimestralmente, conforme gráfico 1 .
Gráfico 1 – Comparação de ocorrências de indisponibilidades e chamados resultantes
Fonte: Autor (2017).
No período de Janeiro a Março de 2016 e 2017, sem aplicação do componente no ambiente, números que consideram um período da virada de semestre e novos processos seletivos, onde minutos de indisponibilidade detectados pela ferramenta ZABBIX geraram uma demanda considerável de chamados.
No período de Abril a Junho e Outubro a Dezembro de 2016, sem aplicação do componente no ambiente, sem nenhuma particularidade dos processos da instituição, mas considerando refatoração no middleware de integração a ferramenta ZABBIX, detectou-se números menores de ocorrências de indisponibilidade.
De Abril a Junho de 2017, com o componente em produção , nenhuma ocor- rência de indisponibilidade foi registrada pela ferramenta ZABBIX, sendo que, foram registrados no banco embarcado do componente um total de 4 ocorrências de indis- ponibilidade imperceptíveis para a ferramenta ZABBIX, pois o componente restaurou recursos do midlleware de integração antes que fosse capturado alguma indisponibili- dade.
E por fim, no período de julho a setembro de 2017, com o componente em produção e, considerando como um dos períodos de virada de semestre, novamente nenhuma ocorrência de indisponibilidade foi registrada pela ferramenta ZABBIX, sendo que, foram registrados no banco embarcado do componente um total de 9 ocorrências de indisponibilidade imperceptíveis para a ferramenta ZABBIX, pois o componente
Capítulo 6. AVALIAÇÃO DO ARTEFATO 73
restaurou recursos do midlleware de integração antes que fosse capturado alguma indisponibilidade.
O gráfico 2 traz números dos dois últimos cenários:
Gráfico 2 – Comparação de ocorrências ferramenta ZABBIX e registros no componente
Fonte: Autor (2017).
Tomamos uma abordagem de alta disponibilidade para o nosso problema, tra- tando uma degradação do desempenho como tempo de inatividade do middleware de integração. Para os propósitos desse trabalho, o desempenho é puramente associado à experiência do usuário final. Em outras palavras, consideramos métricas como o tempo de resposta final e a taxa de transferência de aplicativos. Tratamos uma aplicação que experimenta períodos prolongados (na ordem de dezenas de minutos) de perda de desempenho como uma falha.
Definida como a probabilidade de um sistema estar disponível quando neces- sário, a disponibilidade é um aspecto importante e está diretamente relacionado a confiabilidade. A disponibilidade, ou mais especificamente, a disponibilidade instantâ- nea, é tipicamente definida como a fração de tempo durante a qual um componente ou sistema está funcionando de forma aceitável, isto é, o tempo de atividade durante o