Um mecanismo de introspecção para depurar o comportamento de sistemas distribuídos

Tamanho: px
Começar a partir da página:

Download "Um mecanismo de introspecção para depurar o comportamento de sistemas distribuídos"

Transcrição

1 Um mecanismo de introspecção para depurar o comportamento de sistemas distribuídos Thiago Araújo, Carla Wanderley e Arndt von Staa Departamento de Informática PUC-Rio Rio de Janeiro, Brazil {taraujo, cgaldino, Resumo Sistemas distribuídos são difíceis de depurar devido à dificuldade de coletar, organizar e relacionar informações sobre a sua execução. Quando uma falha é descoberta, inferir o estado do sistema e as operações que tenham alguma relação com ela costuma ser uma tarefa difícil, em que técnicas tradicionais de depuração costumam não ser aplicáveis, e quando são, tendem a ser pouco eficazes. Este trabalho apresenta um mecanismo baseado em logs de eventos anotados com informações de contexto, que permitem uma ferramenta de visualização exibir somente os eventos que forem do contexto de interesse do operador que estiver depurando o sistema. Nós aplicamos este mecanismo em um sistema real e seu esforço para detectar e diagnosticar a causa de falhas foi drasticamente reduzido. Abstract Distributed systems are hard to debug due to the difficulty to collect, organize and relate information about their behaviour. When a failure is detected the task to infer the system s state and the operations that have some connection with the problem is often quite difficult and usual debugging techniques often do not apply and, when they do, they are not very effective. This work presents a mechanism based on event logs annotated with contextual information, allowing visualization tools to organize events according to the context of interest for the system operator. We applied this mechanism to a real system and its the effort and cost to detect and diagnose the cause of problems was dramatically reduced. Index Terms Software quality, Software debugability, Software maintenance, Software recovery. I. INTRODUÇÃO Durante o desenvolvimento de sistemas distribuídos é comum necessitar-se de informações de introspecção para avaliar o comportamento do sistema, a fim de auxiliar um desenvolvedor ou mesmo um administrador no processo de análise e diagnóstico de falhas. Uma técnica comum é produzir logs com mensagens que descrevam o comportamento do sistema, associando-as, se possível, com o valor de variáveis do contexto. Entretanto, apesar desta técnica produzir algum resultado, o esforço empregado do ponto de vista de quem está depurando é muito grande [1]. Identificamos que os principais problemas são: Em um sistema real o conjunto de logs costuma ser muito extenso e apresenta informações de diferentes contextos misturadas em uma mesma dimensão, reduzindo a visibilidade das informações relevantes para o problema em questão. Os arquivos de log costumam estar distribuídos em diferentes máquinas, impondo a quem estiver depurando um esforço adicional para acessá-los. É difícil para a pessoa que estiver depurando interrelacionar os eventos, sejam eles do mesmo contexto ou de contextos diferentes, a fim de criar os elos lógicos que expliquem o comportamento faltoso. A forma de representar e exibir os logs são a chave para o problema em questão. O ideal para a pessoa que estiver depurando é poder selecionar somente os eventos do seu contexto de interesse e visualizá-los em uma lista temporal única. Também é interessante descobrir informações de localidade, como por exemplo, de qual máquina o evento foi emitido, executando qual processo, em qual componente, em qual procedimento, disparado por qual usuário, com quais variáveis locais e globais, em qual ponto da pilha de execução, etc. Também é desejável identificar relacionamentos não-explícitos entre os eventos, que muitas vezes podem fornecer pistas para determinar a causa da falha. Finalmente, é importante que somente as informações necessárias sejam apresentadas ao usuário, ressaltando que este pode incorporar diferentes perfis, cada um interessado em um conjunto diferente de informações. Podemos citar como perfis comuns: desenvolvedor da aplicação, desenvolvedor do middleware, administrador da aplicação, administrador da infra-estrutura, entre outros. Este trabalho apresenta um mecanismo de introspecção 1 que procura resolver os problemas citados através de um log em que os eventos são anotados com as informações do contexto em que foram criados. Cada entidade geradora de log (processo, thread, máquina) notifica seus eventos para um repositório central, que os armazena de forma estruturada. Com isso permitimos que, através de uma interface de consulta, um usuário seja capaz de estudar o comportamento do sistema filtrando os eventos a serem exibidos segundo um contexto de interesse. Este contexto é formado por um conjunto de tags que enriquecem a informação do evento e podem ser utilizadas para indicar o que se deseja visualizar. Como exemplo, considere um sistema composto por dispositivos móveis comunicando-se com um servidor em nu-

2 vem. Simplificando o mecanismo, definimos que cada evento gerado por este sistema deva conter uma tag name que representa a máquina de origem e uma tag action que representa a operação corrente. Suponha que cada dispositivo móvel dispara no servidor, dentre outras operações, uma de sincronia de dados. Sabemos que quando um determinado dispositivo dispara esta operação, o servidor apresenta uma falha, entretanto não sabemos o seu nome. Depurando da forma tradicional, ou seja, coletando manualmente os logs de cada dispositivo, teríamos que realizar um esforço muito grande para relacioná-los em uma linha temporal única, e ainda assim seria necessário filtrar esta lista deixando somente os eventos relacionados com a sincronia. Utilizando a interface de consulta proposta, um administrador do sistema precisaria somente especificar qual o contexto de interesse dele, neste caso informando a tag [action:sync], e após encontrar um evento que represente a falha, utilizar o nome do dispositivo de origem para refinar a busca, ou seja, fazer uma nova consulta utilizando as tags [action:sync][name:tablet 1]. Continuando este procedimento o administrador chegará a uma visão limpa do comportamento do sistema que exiba somente os eventos de seu interesse. A fim de avaliar a solução proposta realizamos um estudo de caso utilizando um sistema real de cardápios digitais, que possui um alto grau de complexidade devido à sua flexibilidade de configuração e às garantias de retrocompatibilidade que implementa, tornando-o interessante para o problema em questão. Avaliamos o mecanismo proposto de duas formas: (1) medindo o esforço para instrumentar o sistema e (2) em um experimento com usuários reais utilizando a interface de consulta para diagnosticar falhas, outrora descobertas no ambiente de produção. A expectativa era que o esforço de instrumentação fosse baixo e que os usuários conseguissem diagnosticar as falhas em um tempo inferior ao que foi necessário quando elas foram descobertas no ambiente de produção. Ambas as expectativas foram atendidas e o mecanismo proposto demonstrou ser uma ferramenta poderosa de depuração. O artigo esta organizado da seguinte forma: na seção 1 introduzimos o problema; na seção 2 apresentamos contexto de pesquisa em que foi realizado este trabalho; na seção 3 descrevemos a nossa solução; na seção 4 apresentamos o estudo de caso realizado sobre um sistema de cardápio digital; na seção 5 discutimos os trabalhos relacionados; e, finalmente, na seção 6 concluímos o trabalho e apresentamos os próximos passos desta pesquisa. II. CONTEXTO DE PESQUISA Este trabalho foi desenvolvido no contexto de uma pesquisa em sistemas orientados à recuperação [2]. Em tais 1 Capacidade do sistema conhecer a si mesmo, disponibilizando metainformações sobre a sua estrutura interna e seu comportamento durante a execução. sistemas assume-se que defeitos podem existir [3] [4] e que, em um primeiro momento, o sistema deve estar preparado para, em curto espaço de tempo, tratar as consequentes falhas a fim de evitar danos e manter os serviços disponíveis (MT- TRc 2 ), e num segundo momento, determinar as causas dessas falhas e removê-las (MTTRp 3 ). Esta abordagem permite que durante o tempo em que a falha está sendo diagnosticada para identificar o defeito e a seguir removê-lo o sistema continue em uso, ainda que com funcionalidades reduzidas. Desejamos que, a partir da criação de uma infra-estrutura para tratar da coleta e análise das informações de um sistema, sejamos capazes de identificar seus comportamentos anômalos, diagnosticá-los, e, quando se tratar de uma falha, possamos compensá-la e escolher a estratégia adequada para recuperar o sistema. Quando falamos em anomalias referimonos tanto a comportamentos inesperados, exceções, dados inconsistentes ou até mesmo falhas que comprometam a execução da aplicação como um todo, como por exemplo, uma falha de segmentação. Abordagens semelhantes a esta vêm sendo produzidas no contexto de computação autonômica [5] e seus avanços podem ser encontrados em trabalhos como [6], [7], [8], [9] e [10]. Para ser capaz de corrigir um sistema em tempo de execução, sua infra-estrutura deve apresentar alguns mecanismos, entre eles: Introspecção - O sistema deve ser capaz de conhecer a si mesmo, ou seja, deve disponibilizar para consulta informações sobre sua arquitetura, suas funcionalidades e seu estado em cada ponto de uma execução [11]. Coleta de eventos - As informações sobre a execução de um sistema devem ser coletadas e organizadas em uma base de dados para facilitar o raciocínio sobre a sua integridade. As consultas sobre esta base de dados devem poder ser realizadas a partir de agentes internos, como mecanismos de verificação e recuperação, ou externos, como desenvolvedores depurando a aplicação. Detecção de falhas - O sistema deve apresentar mecanismos para verificar os contratos da aplicação [12] e notificar as falhas encontradas. Entendemos como falha qualquer comportamento que impeça a execução de uma operação ou resulte em um estado inconsistente. Compensação de falhas - Capacidade de repor o sistema em um estado correto sem corrigir a falha. Dependendo da natureza da falha ela pode levar o sistema a um estado inconsistente, seja pela falha em si, ou pela execução incompleta da atividade interrompida. Logo, é necessário dispor de mecanismos para reverter os efeitos colaterais de uma falha e restaurar o sistema a um estado consistente mesmo que não se tenha corrigido as consequências da falha. 2 MTTRc - Mean Time To Recover 3 MTTRp - Mean Time To Repair

3 Recuperação de falhas - Capacidade de por o sistema em estado correto corrigindo o efeito da falha, ao invés de meramente por em algum estado correto. A partir da detecção de uma falha deve ser adotada uma estratégia que faça com que a aplicação volte à rotina normal de execução. Dentre estas estratégias, podemos citar, entre outras, a reexecução da atividade faltosa, a reinicialização ou substituição de componentes seguida da reexecução. Flexibilidade na arquitetura - A fim de aumentar a robustez do sistema, a sua infra-estrutura deve permitir que a aplicação continue operante ainda que possua módulos comprometidos ou inoperantes devido a falhas, e estes, possam ser restaurados a partir dos mecanismos de recuperação. O presente artigo tem foco nas etapas de introspecção e coleta de eventos e busca responder as seguintes questões: Qual o grau de introspecção que o sistema deve ter? O que deve ser coletado? Como estas informações devem ser armazenadas? Além disso, conhecemos a princípio quais pontos do código são mais propensos a falhas, logo devem ter um grau de introspecção maior? Certamente não, pois é impossível prever todos os casos de falha que um sistema está sujeito e quais informações serão necessárias para detectá-las, logo, os mecanismos citados devem permitir que a equipe de manutenção aprenda com as falhas ao longo da vida útil do software e insira novas informações de introspecção de forma incremental. Ainda que parte das falhas possa ser compensada ou mesmo recuperada com soluções gerais, como a reinicialização de um serviço, a reconexão de um componente ou a limpeza de um cache, existem outras que necessitam de intervenção humana para realizar seu diagnóstico e definir como deve ser a sua recuperação. Para estas, ao menos na primeira vez, o diagnóstico e a correção devem ser realizados por humanos, e, em seguida, estes podem ser implementados como rotinas de detecção e recuperação. Sendo assim, as etapas de introspecção e coleta de eventos devem ser projetadas de forma que atendam também às necessidades dos usuários humanos, a fim de reduzir seu esforço na depuração das falhas encontradas. adequada para a depuração?. Infelizmente não, pois a forma mais adequada depende do problema que está sendo tratado no momento. O mesmo evento pode ser interessante para dois perfis de depuração distintos. Por exemplo, um evento de falha na autenticação pode ser interessante tanto para o desenvolvedor que está verificando por que o seu componente não interage mais com o sistema, como para o administrador da infra-estrutura que está atendendo uma reclamação de um usuário que não consegue realizar o login. Observe que são contextos diferentes, e se ainda assim tentarmos gerar um log para cada um deles duplicando os eventos que forem interessantes a ambos, podemos cair no mesmo problema, em que o usuário deseja uma organização ligeiramente diferente. Idealmente o usuário deve ser capaz de visualizar somente os eventos de interesse para o problema em questão, portanto, propomos um modelo em que o evento deve sempre conter as propriedades do seu contexto atual, e a partir destas definir se ele é interessante ou não para a visualização corrente do depurador. Em nossa solução o evento é representado com uma mensagem, um identificador temporal e um conjunto de tags. Cada tag é representada por um par nome-valor, representando as propriedades contextuais do sistema no instante em que o evento foi criado. O valor de cada tag é opcional, dependendo da sua natureza. Um evento pode ser identificado unicamente no sistema a partir do par formado pelo seu identificador temporal e a máquina de origem. Na Figura 1 apresentamos a arquitetura desta solução, cuja explicação será dividida em três partes: (1) a escrita das informações de introspecção, (2) o fluxo dos eventos, e (3) a ferramenta para inspecionar o comportamento do sistema. III. UM LOG COM INFORMAÇÕES DE CONTEXTO Analisando o modelo mental de um desenvolvedor que está depurando logs de um sistema distribuído, a primeira pergunta que este se faz é: porque eles não estão todos em um mesmo arquivo? Devido à natureza deste tipo de sistema é comum o log estar distribuído em diferentes máquinas, separados por serviços, componentes ou ainda por intervalo de tempo. Portanto, estudar o comportamento deste tipo de sistema exige um esforço considerável. Assim que este desenvolvedor se conforma, a segunda pergunta que ele se faz é: poderiam ao menos estar separados de uma forma mais Figura 1. Arquitetura da solução

4 A. Escreva sua própria informação de introspecção O desenvolvedor terá maior eficácia na depuração se a semântica do sistema for incorporada à geração dos seus eventos. Em geral, não temos necessidade de saber cada função que foi executada, por outro lado, seria ótimo saber por quais etapas do procedimento ele passou. Como o próprio desenvolvedor define as etapas existentes em cada procedimento durante a fase de projeto do sistema, é importante que ele participe também do processo de construção das informações de introspecção, inserindo-as durante a codificação como uma instrumentação no código. Consequentemente, deverá ser implementada para cada plataforma uma biblioteca seguindo a interface a seguir: interface Tag { attribute string key; attribute string value; } typedef sequence<tag> TagList; interface TagDictionary { attribute TagList tags; } module EventMonitor { void notifyevent(in string message); void notifyevent( in string message, in TagDictionary dict); void pushtag(in string name); void pushtag( in string name, in string value); void poptag(); } O processo de instrumentação é tão simples quanto o de escrita de logs, inclusive deve ser encarado desta forma pelos desenvolvedores. Em cada ponto do código que seja interessante colocar uma notificação de log, deve ser inserida também a notificação de um evento para o mecanismo de introspecção (ou somente este último). Salientamos que a escrita da instrumentação deva ser realizada junto com a codificação do sistema, pois este é um dos momentos em que o desenvolvedor tem maior atenção sobre aquela parte do código. Descrevendo a interface apresentada, a principal primitiva é o método notifyevent que cria um novo evento e promove seu registro na linha temporal do sistema. Este método recebe como parâmetro uma mensagem e, opcionalmente, o conjunto de tags que representa o contexto em que o evento está inserido. Como exemplo, a mensagem Invalid client settings poderia estar associada a tags como platform, request id, step, com os valores: web server, 1234 e verifying client settings, respectivamente. Em Python, por exemplo, teríamos um código assim: logger.notify( Invalid client settings, { platform : web server, request_id : 1234, step : verifying client settings }) Por mais simples que seja este último exemplo podemos identificar que algumas tags terão uma frequência muito grande, como a tag request id, e em alguns casos estarão em todos os eventos gerados, como, por exemplo, a tag platform. Para reduzir o esforço do usuário na tarefa de instrumentação e viabilizar a utilização da técnica, a biblioteca deve fornecer as primitivas pushtag e poptag, que inserem e removem tags de uma pilha global, respectivamente. Esta pilha representa o contexto corrente da execução e suas tags são inseridas em todos os eventos gerados. Naturalmente, quando o desenvolvedor empilha ou desempilha alguma tag ele está informando ao mecanismo de introspecção que o contexto está sendo alterado, e, quando os próximos eventos forem notificados, eles serão anotados com este novo estado da pilha. Utilizando a pilha de contexto, podemos reescrever o exemplo anterior da seguinte forma: # Na função main da aplicação logger.push_tag( platform : web server )... # Na função que trata de novas requisições logger.push_tag( request_id : request.id)... # No ponto de notificação especificamente logger.notify( Invalid client settings, { step : verifying client settings }) No exemplo acima emitimos um evento com três tags, sendo as duas primeiras definidas através da pilha de contexto e a última definida durante a notificação. Como a tag platform deve estar presente em todos os eventos e seu valor é constante, ela pôde ser empilhada diretamente na função main da aplicação. Entretanto, apesar da tag request id estar presente em todos os eventos emitidos durante a execução de um tratamento de requisição, o seu valor muda a cada chamada, portanto, ela só pôde ser empilhada no escopo em que o valor deste identificador é definido. Além de evitar a reescrita de tags em cada notificação de evento, a pilha de tags resolve o problema de visibilidade das informações entre escopos: devido ao encapsulamento, é comum uma função não ter acesso a todas as variáveis que representam o seu contexto corrente, pois uma parte considerável pode estar definida em escopos superiores. Portanto, os eventos notificados nestas funções apresentariam um contexto incompleto, reduzindo a eficácia da inspeção. A pilha de tags resolve este problema mantendo armazenadas as tags dos escopos superiores, que são embutidas automaticamente em eventos criados nos escopos inferiores. Como exemplo, os eventos emitidos na camada de banco de dados terão uma tag com o identificador da requisição corrente, que foi definido na camada de controle. Naturalmente, as chamadas push tag e pop tag devem formar um par, ou seja, cada chamada a função push tag deve ter associada uma chamada pop tag para limitar o escopo

5 de atuação da tag. Continuando o exemplo anterior, as suas chamadas pop tag seriam inseridas da seguinte forma: # No final da função que trata de requisições logger.pop_tag()... # No final da função main da aplicação logger.pop_tag() A chamada pop tag remove a tag presente no topo da pilha. Observe que esta chamada não recebe parâmetros, pois assume que sempre removerá a tag inserida pelo seu par. Ou seja, se eu entrei em um contexto de sincronia e fiz a chamada push tag( sync ), espera-se que a chamada pop tag() ao final deste escopo remova, com precisão, a tag sync. Imediatamente consideramos que isso era um risco para a técnica, pois eventualmente o desenvolvedor esqueceria de desempilhar alguma tag, tornando a pilha inconsistente até o final da execução do sistema. Para contornar este problema sugerimos a implementação de açúcares sintáticos nas bibliotecas, cujo funcionamento deve ser definido de acordo com a linguagem de implementação. Na linguagem Objective-C por exemplo, criamos um envelope, que consiste em uma variável alocada na pilha cujo construtor empilha a tag (push tag) e o destrutor desempilha automaticamente pop tag ao término do escopo da variável. Em Python adotamos uma abordagem um pouco diferente: criamos um decorator de função que empilha uma nova tag ao entrar na função e a desempilha ao sair, tanto por retorno normal quanto um retorno de exceção. Envelope em Objective-C: - (void)myfunc { SCOPED_TAG( operation, processing request )... } Decorator em operation, processing request ) def processclientrequest():... É importante salientar que a biblioteca de apoio à instrumentação deve ser implementada com foco na linguagem de programação alvo e seguindo sua filosofia de utilização, a fim de produzir uma interface de interação mais amigável ao desenvolvedor. B. O fluxo de eventos Primeiramente, é importante definir o que é um evento: é uma mensagem com um conjunto de tags associadas e um identificador temporal. Cada tag por sua vez é um par <nome, valor>, em que o campo valor é opcional. A fim de garantir a interoperabilidade entre diferentes bibliotecas, cada evento é serializado em um formato bem definido, que segue o seguinte padrão: cada tag é escrita sob a forma de uma tupla [<nome>:<valor>] e tanto o identificador temporal quanto a mensagens são consideradas tags neste momento. Um evento é uma sequência de tuplas com uma quebra de linha no final, como no exemplo a seguir. [application:hello world] [environment:server] [component:web server] [request id:1234] [client id:4321] [operation:processing client request] [message: verifying client settings]\n Após serializados, os eventos são enviados a um servidor central responsável pelo seu tratamento e armazenamento. No entanto, o processo de envio pode não ser trivial se considerarmos que o sistema é distribuído e envolve diferentes plataformas, cada uma com um conjunto de características que influencia a etapa de notificação. Em um sistema web sendo executado na intranet do servidor central, por exemplo, o processo de envio de novos eventos pode ser direto e sem confirmação, pois neste caso podemos contar com um alto índice de disponibilidade. Entretanto, quando consideramos aplicações ubíquas, estas podem não ter uma disponibilidade de rede constante, indo além, a rede pode ter uma qualidade baixa, exigindo um mecanismo de retransmissão. Além disso, estas aplicações costumam ser mais suscetíveis a quedas de energia, o que nos remete ao problema de manter em memória os eventos que ainda não foram enviados. Para solucionar estes problemas propomos que as bibliotecas de sistemas ubíquos utilizem uma política de envio de pequenos pacotes, lidos diretamente do disco em um modelo produtorconsumidor. Cada evento criado deve ser imediatamente gravado no arquivo corrente, e quando este atingir um tamanho limite deve ser fechado e marcado para envio. Em caso de falta de energia, ao ser reiniciada a aplicação continua escrevendo no último arquivo. Outra consequência desta abordagem é a garantia que em um desastre, como um acesso inválido de memória, as informações da falha estão salvas antes da aplicação fechar. Conforme dito anteriormente, o armazenamento de eventos é realizado em um servidor central responsável por interpretar as informações recebidas e fazer alguns ajustes, como por exemplo, a normalização de identificadores temporais. Considerando que cada máquina envolvida no sistema possui seu próprio relógio, que eventualmente está diferente do relógio no servidor central, é necessário converter os logs recebidos para o relógio do servidor central. Solucionamos este problema enviando junto com os eventos o timestamp corrente de cada máquina, e a partir dele calculamos o delta temporal ajustando a coerência dos relógios. Em nossa implementação do servidor central armazenamos os eventos em um banco de dados NoSQL [13], devido a forma como estruturamos o evento. Este tipo de banco de dados armazena cada entrada em um formato de tuplas, semelhante a nossa representação de eventos, e utiliza algoritmos de busca otimizados para este tipo de estrutura. Além disso, este tipo de banco de dados pode ser distribuído, e, considerando o problema de volume de eventos, este recurso combinado a estratégias de computação na nuvem podem resolver o problema de uma forma simples e de baixo custo.

6 C. A ferramenta de inspeção Somente armazenar eventos de uma forma estruturada não é suficiente. Se em uma depuração o operador do sistema serializar todos os eventos do banco de dados, ele continuará com o mesmo problema: um volume considerável de dados misturando eventos de diferentes contextos. Voltamos ao problema inicial: como visualizar somente os eventos que tem alguma relação com o problema em análise? Nossa solução foi construir uma ferramenta de visualização que permite selecionar o conteúdo desejado de acordo com o contexto de interesse. A interface desta ferramenta é apresentada na Figura 2. A ferramenta apresenta uma interface simples, com controles que definem o contexto de interesse e a lista de eventos que se encaixam neste contexto (Figura 2a). Estes controles são: Campos para limitar o espaço temporalmente: datas de corte superior e inferior (Figura 2b). Restrições baseadas nas tags de cada evento (Figura 2c). Cada alteração no controle atualiza a lista para o novo contexto. Desta forma, o operador pode começar com restrições muito específicas, como buscar pela tag Error, em seguida encontrar o último evento com ela, que provavelmente é o que ele estava procurando, e a partir deste descobrir mais informações que ajudem a continuar a depuração, como por exemplo, o dispositivo móvel que notificou o erro. Com estas informações, as restrições da busca podem ser modificadas para visualizar o histórico do dispositivo encontrado, inclusive exibindo eventos relacionados a ele em outros dispositivos ou servidores presentes no sistema. Neste momento a visualização pode estar ainda muito poluída, logo o operador deve adicionar novas restrições a fim de restringir ainda mais o escopo, até chegar à sequência de eventos que explique com clareza o comportamento faltoso. As restrições são representadas como duas listas: a primeira contém tags que tornam o evento interessante para o usuário, ou seja, os eventos que possuírem todas estas tags são incluídos na exibição. A segunda lista contém tags que definem os eventos indesejados, ou seja, qualquer evento que possuir uma destas tags é desconsiderado na exibição. Além disso, a restrição pode ser especificada com uma tag que possua apenas nome, ou ainda com um valor definido a partir de uma expressão regular. Outra questão abordada é a poluição visual relacionada ao número de tags no evento. Considere o seguinte exemplo: [environment:mobile] [application:hello world] [cpu:80] [memory:2524] [version:3] [flow:main] [message:main screen loaded]\n Este evento pode ser interessante tanto para avaliar o desempenho da aplicação, através das tags cpu e memory, quanto para a visualização do fluxo de acesso de telas do sistema. Logo, todas as tags devem existir, entretanto, algumas podem não ser interessantes para alguns contextos. A fim de solucionar este problema a ferramenta apresenta um recurso para que o operador indique as tags que não devem ser exibidas na lista de eventos (Figura 2d), a fim de reduzir a poluição visual durante a depuração. Estas tags também podem ser representadas sob a forma de uma expressão regular. A ferramenta também possui um recurso de atualização incremental (Figura 2e), opcional, que faz com que a lista de eventos seja atualizada em tempo real, permitindo que o operador acompanhe o comportamento do sistema como um todo em uma linha temporal única, respeitando as restrições definidas. Relacionado a este recurso de atualização em tempo real, existe o problema de atualização da lista de eventos mesmo quando o recurso de atualização incremental está desativado. Considerando que estamos trabalhando com sistemas distribuídos, dispositivos ubíquos podem passar por períodos sem rede, uma determinada visualização pode se tornar inconsistente em alguns momentos, ou seja, o servidor pode receber um conjunto de eventos interessantes para esta visualização e que não estão sendo exibidos, pois foram renderizadas em um momento anterior à chegada dos eventos. Observe que isso não é o problema de atualização incremental, pois estes novos eventos podem estar intercalados com os existentes no servidor. Para solucionar este problema implementamos nesta interface um algoritmo que verifica se existem novos dados no servidor e os insere na lista, mantendo a ordem temporal. IV. ESTUDO DE CASO: UM CARDÁPIO DIGITAL Fizemos um estudo de caso em um sistema real com o objetivo de medir o esforço necessário para implantar o mecanismo apresentado neste trabalho e verificar se a sua utilização acelera o processo de diagnostico de falhas. O sistema alvo foi uma solução de cardápio digital implementada como um sistema distribuído, composto por um conjunto de tablets por cliente, uma aplicação web para realizar a gestão do conteúdo e um servidor para tratar da sincronização entre a aplicação web e os tablets. O aplicativo executado em cada tablet foi desenvolvido em Objective-C sobre a plataforma ios [14], enquanto a aplicação web e o servidor de sincronia foram implementados em Python, utilizando a biblioteca DJango [15]. O esforço foi medido em percentual de código destinado à instrumentação, pois as horas desprendidas na tarefa foram o único custo para implantação da metodologia proposta. Também fizemos um experimento com usuários reais em um ambiente controlado, em que a tarefa era diagnosticar um conjunto de falhas injetadas propositalmente no sistema. Estas falhas foram descobertas no ambiente de produção e na época foram diagnosticadas da forma tradicional, sem auxilio do mecanismo proposto. O objetivo deste experimento foi avaliar a contribuição da ferramenta no processo de depuração, que foi medido comparando o

7 Figura 2. Screenshot da interface de consulta tempo gasto por cada usuário durante o experimento com o tempo gasto pelo usuário que realizou o diagnóstico original no ambiente de produção. O aplicativo executado no tablet é baseado em uma linha de produto [16] com dois níveis, e, durante a configuração de cada cliente, é produzido um layout customizado seguindo a identidade visual da sua marca, de acordo com a escolha prévia dos assets da linha de produto. Além da escolha dos assets existe uma configuração fina dos mesmos, realizada através de arquivos de configuração. Observe que o layout produzido é sensível a escolha dos assets e das configurações definidas. A aplicação web de gestão do conteúdo permite inserir, editar e remover diferentes tipos de produtos, além de fornecer mecanismos para configurar o aplicativo dos tablets. O servidor de sincronização é responsável pela atualização incremental do conteúdo e das configurações dos tablets. A escolha deste sistema como estudo de caso se adequa perfeitamente ao presente trabalho devido às dificuldades identificadas em seu ambiente de produção, que se deve principalmente ao trabalho concorrente de diferentes tipos de atores sobre as informações de um mesmo cliente. De forma resumida, os atores do sistema são: um administrador configurando a linha de produto de cada cliente segundo suas necessidades, uma equipe de catalogação inserindo a ficha técnica de produtos (Ex: vinhos) requisitados pelos clientes e uma equipe de designers produzindo o layout segundo as especificações de cada cliente. É importante deixar claro que o trabalho realizado por estes atores não é restrito à etapa inicial de implantação do sistema, mas persiste ao longo da sua utilização. Em suma, este sistema possui um número incomum de superusuários que em alguns momentos trabalham concorrentemente com relação ao mesmo cliente, muitas vezes sem estarem conscientes disso. O sistema foi projetado para funcionar desta forma, entretanto, a falta de comunicação entre os envolvidos ou a falta de atenção pode tornar inconsistente a configuração de um cliente. Como exemplo, podemos citar o caso em que um administrador modificou a configuração nos assets A e B, e inseriu o asset C. Em seguida este administrador pediu para o designer responsável adequar o layout as modificações, esquecendo de mencionar a inclusão do asset C. Este problema ainda pode ser agravado considerando que cada parte do sistema é versionada de forma independente e a aplicação dos tablets deve manter retrocompatibilidade. Ou seja, em uma evolução da aplicação web, por exemplo, o servidor responsável pela sincronia deve ser capaz de disponibilizar um conteúdo compatível com todas as versões de tablets em uso. Este sistema ainda compartilha a dificuldade de depuração de aplicações ubíquas, pois o usuário final do sistema (consumidor em um restaurante) não tem interesse, ou mesmo conhecimento, de como reportar um falha a algum responsável que seja capaz de corrigi-la. Esta dificuldade fortalece a proposta deste trabalho, que viabiliza o monitoramento e depuração de cada parte do sistema em tempo real. A. Esforço de instrumentação Decidimos instrumentar o código da aplicação executada nos tablets e o código do servidor de sincronização, pois estas são as partes do sistema que apresentam maior dificuldade de

8 depuração, logo representam maior risco ao projeto. O código das aplicações possuía algumas assertivas executáveis [11], que foram utilizadas como ponto de partida para instrumentálo. O primeiro passo foi definir o conjunto de tags a ser utilizado, que dividimos em tags gerais e tags do domínio da aplicação. O esforço para definir o conjunto de tags é subjetivo e variável de acordo com o tipo de projeto. Neste estudo de caso definimos um conjunto inicial em uma reunião de 2h envolvendo todos os desenvolvedores, e ao longo do tempo, fomos ajustando de acordo com as necessidades identificadas. Aliás, esta flexibilidade na manipulação do conjunto é uma vantagem, pois as evoluções arquiteturais do sistema eventualmente serão refletidas no conteúdo da introspecção. A composição final do conjunto de tags para o sistema em questão foi: Tags gerais: Error - Falha interna ao sistema. Disaster - Falha que causa um dano irrecuperável. Warning - Inconsistência dos dados ou condição suspeita. Environment - Define o ambiente de execução (Ex: mobile). Function - Nome da função corrente. Action - Ação corrente dentro da execução. CPU - Carga corrente de processamento. Memory - Memória ocupada pela aplicação. Tags da aplicação: User - Usuário que disparou a operação. Company - Empresa do usuário que disparou a operação. RequestID - Identificador da requisição corrente. DeviceID - Identificador do dispositivo que executou a operação. DeviceStatus - Estado corrente das informações do dispositivo (Ex: em atualização). CurrentView - Visão corrente do aplicativo embarcado. ItemCode - Item visualizado na tela corrente. O processo de instrumentação levou 20 horas de desenvolvimento, envolvendo dois desenvolvedores que participaram da construção do sistema e possuem um vasto conhecimento sobre o mesmo. Medimos o percentual de código instrumentado contando o número de operações destinadas à configuração e emissão de log, dividindo-as pelo número total de operações, e os resultados foram 7% para o aplicativo embarcado e 14% para o sistema de sincronização, que apresentou um percentual maior por ser um código mais complexo e mais propenso a falhas. Além disso, ainda que o esforço de instrumentação fosse alto, o custo-benefício poderia valer a pena. Suponhamos que o custo de instrumentação fosse equivalente ao custo de produção do sistema, ou seja, teríamos um esforço de 200% para produzi-lo. Se este trabalho adicional permitir que um diagnóstico seja realizado em 5% do tempo original, para sistemas de missão-crítica, o mecanismo proposto ainda seria vantajoso. O custo de instrumentação foi baixo para este estudo de caso e pode ser bem maior para outros sistemas, entretanto a instrumentação deve ser colocada durante o desenvolvimento, seguindo as mesmas regras das assertivas, logo este custo tende a ser diluído na codificação, inclusive, auxiliando o desenvolvedor a raciocinar um pouco mais sobre a estrutura da sua aplicação. B. Avaliação da ferramenta de inspeção Fizemos um teste qualitativo com um grupo de usuários a fim de avaliar a rapidez com que conseguiam diagnosticar falhas através da ferramenta de inspeção. Escolhemos três falhas que ocorreram no sistema em produção cujo custo de depuração foi alto: Problema: Cadastrei um novo cliente, configurei sua conta e enviei o login e senha por . Ele acabou de ligar dizendo que instalou corretamente o aplicativo no tablet mas não consegue ativálo com suas credenciais. A mensagem de erro diz que existe um problema na configuração da conta. Diagnóstico: O administrador que cadastrou a conta esqueceu de fazer o upload do layout produzido para este cliente. Problema: Um cliente acaba de ligar reclamando que seus tablets não estão sendo sincronizados. Diagnóstico: Existe um erro na implementação que permite um prato ser harmonizado com um vinho que não está ativo na carta. Quando o sistema de sincronização compila os dados a serem enviados para o tablet falta uma informação e este aborta a operação. Problema: Acabei de configurar a conta de um cliente que tinha entrado em contato conosco ha três meses, instalado o aplicativo nos tablets, mas não efetuado a compra. Agora que ele fez isso eu configurei sua conta, mas os tablets não estão sendo ativados por algum motivo e indicam que existe um problema na configuração. Tenho certeza que fiz o upload do layout e da configuração. Diagnóstico: O aplicativo instalado nos tablets deste cliente é antigo e requer uma versão de layout anterior a corrente. Como ele não possuía uma conta na época que esta versão era utilizada não existe um layout compatível com ela. Os problemas escolhidos são simples, entretanto sua diagnosticação é difícil quando realizada através das técnicas de depuração tradicionais. Usualmente o log dos tablets é inacessível e o do servidor apresenta um volume considerável de registros, envolvendo diversas operações de diferentes clientes, dificultando sua análise.

9 O primeiro problema ocorreu com uma frequência alta nos primeiros meses de uso do sistema, representando um custo de depuração de 30 minutos em média por incidente. Inclusive, o tempo de depuração desta falha não variou muito, pois a co-evolução do sistema a mascarou de diferentes formas. Os demais problemas ocorreram uma única vez, o primeiro representando um custo de depuração de 1h e o segundo de 2h e 30 minutos. O grupo submetido ao experimento foi composto por quatro pessoas envolvidas no desenvolvimento do sistema, sendo dois desenvolvedores e dois administradores. Fizemos o teste com cada um individualmente, apresentando um problema de cada vez e pedindo que este o diagnosticasse utilizando a nossa ferramenta. Em cada diagnóstico anotamos o tempo gasto e demais comentários sobre a metodologia utilizada na depuração. Os tempos medidos são apresentados na tabela a seguir junto com os tempos de depuração de quando as falhas foram descoberta no sistema real. Tabela I TEMPO EM MINUTOS DE DEPURAÇÃO PARA CADA PROBLEMA P1 P2 P3 Desenvolvedor sem introspecção Desenvolvedor Desenvolvedor Administrador Administrador Todos os usuários da ferramenta diagnosticaram as falhas com um tempo inferior ao diagnóstico original realizado por um desenvolvedor sem instrumentação. O resultado superou nossas expectativas e nos surpreendeu verificar que os usuários não-técnicos tiveram uma resposta mais rápida que os desenvolvedores, que conheciam o funcionamento interno do sistema. Concluímos que isso aconteceu devido a dois fatores: (1) estes usuários atuam diretamente no sistema em produção, estando mais próximos das falhas reais, e (2) têm uma visão simplificada do todo por não conhecer detalhes de implementação, gerando um grupo menor de hipóteses sobre possíveis causas do problema e, principalmente, dando foco a elas. Nem sempre isso é interessante, entretanto mostrou-se eficiente para os problemas apresentados neste experimento. As três falhas foram escolhidas de forma que nenhum dos usuários tivesse algum conhecimento privilegiado, seja por ela estar relacionada a uma parte do sistema que eles mesmos codificaram, como por algum contato com a manifestação original da falha no ambiente de produção. Além disso, durante o experimento também tomamos o cuidado de não influenciar os usuários, auxiliando somente na utilização da interface de inspeção. Um efeito colateral deste experimento foi a descoberta de uma série de problemas de IHC, que não pertenciam ao escopo deste trabalho, entretanto serão considerados como um trabalho futuro a fim de reduzir ainda mais o esforço e a taxa de falhas da depuração. V. TRABALHOS RELACIONADOS Existem muitos trabalhos na literatura que abordam o problema de depuração baseada em logs, a maioria com foco na detecção automática de falhas [17] [18] [19] [20] [21] [22] [23], poucos no seu diagnóstico [24] [25] [26]. Em ambos os casos o conteúdo do log costuma ser muito superficial, sendo capturado de arquivos de log genéricos [17] [23], lidos do sistema como uma caixa-preta [21] ou gerados automaticamente [18] [25]. Em geral, estas abordagens não produzem informações suficientes para realizar análises profundas ou selecionar eventos de acordo com o contexto de interesse. Alguns trabalhos baseados em mineração e clusterização de dados [27] [28] procuram solucionar este problema detectando padrões, extraindo propriedades das mensagens e classificando-as, entretanto, o número de propriedades acaba sendo limitado à visibilidade do escopo que as criou. Outra questão é a escolha entre a instrumentação automática e a manual. A instrumentação automática apresenta um custo ínfimo e produz um volume maior de logs, porém a manual é escrita pelo próprio desenvolvedor, logo, acaba sendo direcionada para as informações que este considera mais relevantes. Nosso trabalho procura reduzir estas limitações ao fornecer um mecanismo capaz de transcrever, com pouco esforço, o modelo mental dos desenvolvedores sob a forma de instrumentação. O evento é escrito da forma tradicional, entretanto, ao ser emitido é complementado pelas propriedades presentes na pilha de tags. Observe que esta pilha viabiliza a inserção de propriedades definidas em escopos superiores, mesmo que, devido a modularidade, elas não possam ser acessadas pelo escopo corrente. Sem esta pilha o evento seria gerado somente com as propriedades do escopo local, que são importantes, mas não definem o contexto da execução. Encontramos poucos trabalhos [29] [30] [20] [21] que investem em visualizadores para auxiliar a inspeção manual. Estes trabalhos buscam solucionar o problema do volume de logs condensando os eventos e gerando gráficos estatísticos. Esta solução apresenta bons resultados para detectar e diagnosticar falhas de rede e segurança, entretanto é inadequada para falhas de lógica comportamental do sistema, que é o problema tratado por este trabalho e exige um nível maior de profundidade na inspeção. A nossa abordagem segue na direção contrária, buscando mecanismos para aumentar o detalhamento dos log em vez de simplificá-los. Resolvemos o problema do volume de logs através de filtros seguindo o contexto de interesse do usuário, com um grau de flexibilidade alto na sua definição, viabilizado pelas propriedades inseridas na etapa de instrumentação.

10 VI. CONCLUSÃO Apresentamos neste trabalho um mecanismo de diagnóstico de causa de falhas com foco em sistemas distribuídos. O mecanismo é implementado através de logs em que cada evento é anotado com informações do contexto que foi gerado. Estas informações são representadas como tags, compostas por um nome e, opcionalmente, um valor associado. O conjunto de eventos gerado por cada entidade do sistema é enviado para uma base de dados central. Construímos também uma ferramenta de inspeção para apresentar os eventos do sistema em uma linha temporal unificada, exibindo somente os itens do log completo que forem do interesse do depurador, desta forma reduzindo seu esforço para compreender o comportamento do sistema. Realizamos um estudo de caso sobre um sistema de cardápio digital em que foi medido o esforço para instrumentar o sistema e foi realizado um experimento com um grupo de usuários para avaliar as contribuições do mecanismo apresentado. Os resultados foram excelentes, mostrando que a ferramenta não só reduziu o tempo de depuração como se mostrou apta para ser utilizada por usuários não-técnicos. Este trabalho foi uma etapa de uma pesquisa em sistemas orientados a recuperação e servirá como base para trabalhos futuros de detecção e diagnóstico automático de falhas. Além disso, durante a realização do trabalho identificamos alguns trabalhos futuros: (1) estudar soluções de computação nas nuvens para garantir a escalabilidade da solução, (2) criar um mecanismo para inferir novas tags para eventos a partir de relacionamentos não-explícitos entre eles, (3) evoluir a ferramenta de inspeção para visualizar múltiplos contextos concorrentemente, possivelmente relacionando-os, e (4) estudar como a programação orientada a aspectos pode auxiliar a injeção de tags e notificações de eventos. VII. AGRADECIMENTOS Agradecemos ao CNPq pelos auxílios e bolsas: , , e REFERÊNCIAS [1] C. L. Mendes and D. A. Reed, Monitoring large systems via statistical sampling, Int. J. High Perform. Comput. Appl., vol. 18, pp , [2] D. Patterson, A. Brown, P. Broadwell, G. Candea, M. Chen, J. Cutler, P. Enriquez, A. Fox, E. Kiciman, M. Merzbacher, D. Oppenheimer, N. Sastry, W. Tetzlaff, J. Traupman, and N. Treuhaft, Recovery oriented computing (roc): Motivation, definition, techniques, and case studies, EECS Department, University of California, Berkeley, Tech. Rep. UCB/CSD , Mar [3] A. B. Brown and D. A. Patterson, To err is human, in Proceedings of the First Workshop on Evaluating and Architecting System dependability (EASY 01, [4] A. Fox, Toward recovery-oriented computing, in In VLDB, 2002, pp [5] R. Murch, Autonomic Computing. IBM Press, [6] S.-W. Cheng, A.-C. Huang, D. Garlan, B. Schmerl, and P. Steenkiste, Rainbow: Architecture-based self-adaptation with reusable infrastructure, Autonomic Computing, International Conference on, vol. 0, pp , [7] A. Unruh, J. Bailey, and K. Ramamohanarao, Building more robust multi-agent systems using a log-based approach, Web Intelli. and Agent Sys., vol. 7, pp , January [8] A. Avizienis, Toward systematic design of fault-tolerant systems, Computer, vol. 30, pp , April [9] S. Kumar and P. R. Cohen, Towards a fault-tolerant multi-agent system architecture, in Proceedings of the fourth international conference on Autonomous agents. ACM, 2000, pp [10] L. Mariani, M. PezzÃ, and D. Willmor, Generation of integration tests for self-testing components, in Applying Formal Methods: Testing, Performance and M/ECommerce, FORTE 2004 Workshops The FormEMC, EPEW, ITM, Toledo, Spain, October 1-2, 2004, ser. Lecture Notes in Computer Science, vol Springer, 2004, pp [11] A. von Staa, Programacao Modular. Campus, [12] R. Mitchell and J. McKim, Design by contract, by example, in Proceedings of the 39th International Conference and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS39). IEEE Computer Society, 2001, p [13] C. Strozzi. (2012, Apr.) Nosql. [Online]. Available: US/nosql [14] Apple. (2012, Apr.) ios. [Online]. Available: [15] A. Holovaty and J. Kaplan-Moss, The Definitive Guide to Django: Web Development Done Right (Pro). Berkely, CA, USA: Apress, [16] Software product lines: practices and patterns. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., [17] S. E. Hansen and E. T. Atkins, Automated system monitoring and notification with swatch, in Proceedings of the 7th USENIX conference on System administration, 1993, pp [18] J. H. Andrews and Y. Zhang, Broad-spectrum studies of log file analysis, in Proceedings of the 22nd International Conference on Software Engineering (ICSE ACM Press, 2000, pp [19] R. Vaarandi, Sec: a lightweight event correlation tool, in IP Operations and Management, 2002 IEEE Workshop on, 2002, pp [20] J. Stearley, Towards informatic analysis of syslogs, in Proceedings of the 2004 IEEE International Conference on Cluster Computing. IEEE Computer Society, 2004, pp [21] P. Bodik, G. Friedman, L. Biewald, H. Levine, G. C, K. Patel, G. Tolle, J. Hui, O. Fox, M. I. Jordan, and D. Patterson, Combining visualization and statistical analysis to improve operator confidence and efficiency for failure detection and localization, in In Proceedings of the 2nd IEEE International Conference on Autonomic Computing (ICAC â05. IEEE Computer Society, 2005, pp [22] L. Mariani and F. Pastore, Automated identification of failure causes in system logs, in Proceedings of the th International Symposium on Software Reliability Engineering. Washington, DC, USA: IEEE Computer Society, 2008, pp [23] K. Thomson, Logsurfer - real time log monitoring and alerting, Mar [24] M. Chen, A. X. Zheng, J. Lloyd, M. I. Jordan, and E. Brewer, Failure diagnosis using decision trees, in In Proceedings of the International Conference on Autonomic Computing (ICAC, 2004, pp [25] P. Reynolds, C. Killian, J. L. Wiener, J. C. Mogul, M. A. Shah, and A. Vahdat, Pip: detecting the unexpected in distributed systems, in Proceedings of the 3rd conference on Networked Systems Design & Implementation - Volume 3, ser. NSDI 06. Berkeley, CA, USA: USENIX Association, 2006, pp [26] D. Geels, G. Altekar, P. Maniatis, T. Roscoe, and I. Stoica, Friday: global comprehension for distributed replay, in Proceedings of the 4th USENIX conference on Networked systems design; implementation, ser. NSDI 07. USENIX Association, 2007, pp [27] J. L. Hellerstein, S. Ma, and C.-S. Perng, Discovering actionable patterns in event data, IBM Syst. J., vol. 41, pp , [28] R. Vaarandi, A data clustering algorithm for mining patterns from event logs, in in IEEE IPOMâ03 Proceedings, 2003, pp [29] T. Takada and H. Koide, Mielog: A highly interactive visual log browser using information visualization and statistical analysis, in Proceedings of the 16th USENIX conference on System administration. Berkeley, CA, USA: USENIX Association, 2002, pp [30] T. Takada and H. Koike, Tudumi: Information visualization system for monitoring and auditing computer logs. in IV, 2002, pp

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

Anderson Corrêa Carraro 1, Fernando Alves Rodrigues 2, Silvio Francisco dos Santos 3

Anderson Corrêa Carraro 1, Fernando Alves Rodrigues 2, Silvio Francisco dos Santos 3 DESENVOLVIMENTO E IMPLANTAÇÃO DE UM SISTEMA INFORMATIZADO PARA O CONTROLE DE PROCESSOS DA QUALIDADE NA DIRETORIA DE METROLOGIA CIENTÍFICA E INDUSTRIAL DIMCI/INMETRO. Anderson Corrêa Carraro 1, Fernando

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

Software de gerenciamento do sistema Intel. Guia do usuário do Pacote de gerenciamento do servidor modular Intel

Software de gerenciamento do sistema Intel. Guia do usuário do Pacote de gerenciamento do servidor modular Intel Software de gerenciamento do sistema Intel do servidor modular Intel Declarações de Caráter Legal AS INFORMAÇÕES CONTIDAS NESTE DOCUMENTO SÃO RELACIONADAS AOS PRODUTOS INTEL, PARA FINS DE SUPORTE ÀS PLACAS

Leia mais

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MINISTÉRIO DO DESENVOLVIMENTO AGRÁRIO SUBSECRETARIA DE PLANEJAMENTO, ORÇAMENTO E ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE MODERNIZAÇÃO E INFORMÁTICA CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MANUAL

Leia mais

HP Quality Center. Preparar materiais de treinamento e observações para a nova versão 16 Suporte pós-atualização 16 Suporte 17 Chamada à ação 17

HP Quality Center. Preparar materiais de treinamento e observações para a nova versão 16 Suporte pós-atualização 16 Suporte 17 Chamada à ação 17 Documento técnico HP Quality Center Atualize o desempenho Índice Sobre a atualização do HP Quality Center 2 Introdução 2 Público-alvo 2 Definição 3 Determine a necessidade de uma atualização do HP Quality

Leia mais

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE por Miguel Aguiar Barbosa Trabalho de curso II submetido como

Leia mais

Sistemas Operacionais Aula 03: Estruturas dos SOs. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com

Sistemas Operacionais Aula 03: Estruturas dos SOs. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com Sistemas Operacionais Aula 03: Estruturas dos SOs Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com OBJETIVOS Descrever os serviços que um sistema operacional oferece aos usuários e outros sistemas

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

ITIL. Conteúdo. 1. Introdução. 2. Suporte de Serviços. 3. Entrega de Serviços. 4. CobIT X ITIL. 5. Considerações Finais

ITIL. Conteúdo. 1. Introdução. 2. Suporte de Serviços. 3. Entrega de Serviços. 4. CobIT X ITIL. 5. Considerações Finais ITIL Conteúdo 1. Introdução 2. Suporte de Serviços 3. Entrega de Serviços 4. CobIT X ITIL 5. Considerações Finais Introdução Introdução Information Technology Infrastructure Library O ITIL foi desenvolvido,

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

APRENDENDO LÓGICA DE PROGRAMAÇÃO VIA WEB

APRENDENDO LÓGICA DE PROGRAMAÇÃO VIA WEB APRENDENDO LÓGICA DE PROGRAMAÇÃO VIA WEB Romero Tori Universidade de São Paulo Escola Politécnica INTERLAB Laboratório de Tecnologias Interativas-USP Instituto Sumaré de Educação Superior rometori@usp.br

Leia mais

7 Utilização do Mobile Social Gateway

7 Utilização do Mobile Social Gateway 7 Utilização do Mobile Social Gateway Existem três atores envolvidos na arquitetura do Mobile Social Gateway: desenvolvedor do framework MoSoGw: é o responsável pelo desenvolvimento de novas features,

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

CIBM. IBM SmartCloud Entry. Guia do Usuário - Versão 2.2

CIBM. IBM SmartCloud Entry. Guia do Usuário - Versão 2.2 CIBM Guia do Usuário - Versão 2.2 Esta edição aplica-se à versão 2, release 2, modificação 0 do (número do produto 5765-SKC) e a todos os releases e modificações subsequentes, até que seja indicado de

Leia mais

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20 Guia de utilização Índice Introdução... 3 O que é o sistema BlueTalk... 3 Quem vai utilizar?... 3 A utilização do BlueTalk pelo estagiário do Programa Acessa Escola... 5 A arquitetura do sistema BlueTalk...

Leia mais

Acordo de Nível de Serviço

Acordo de Nível de Serviço VERSÃO 20120815 Acordo de Nível de Serviço Gestão Compartilhada Página. 2 de 13 Sumário PARTE 1... 3 1 INTRODUÇÃO... 3 2 DEFINIÇÕES... 4 2.1 GESTÃO COMPARTILHADA... 4 2.2 PROVEDOR... 4 2.3 CLIENTE... 4

Leia mais

Portal Contador Parceiro

Portal Contador Parceiro Portal Contador Parceiro Manual do Usuário Produzido por: Informática Educativa 1. Portal Contador Parceiro... 03 2. Acesso ao Portal... 04 3. Profissionais...11 4. Restrito...16 4.1 Perfil... 18 4.2 Artigos...

Leia mais

Documento de Análise e Projeto VideoSystem

Documento de Análise e Projeto VideoSystem Documento de Análise e Projeto VideoSystem Versão Data Versão Descrição Autor 20/10/2009 1.0 21/10/2009 1.0 05/11/2009 1.1 Definição inicial do documento de análise e projeto Revisão do documento

Leia mais

1 ACESSO AO PORTAL UNIVERSITÁRIO 3 3 PLANO DE ENSINO 6 4 AULAS 7 5 AVALIAÇÃO E EXERCÍCIO 9 6 ENQUETES 12 7 QUADRO DE AVISOS 14

1 ACESSO AO PORTAL UNIVERSITÁRIO 3 3 PLANO DE ENSINO 6 4 AULAS 7 5 AVALIAÇÃO E EXERCÍCIO 9 6 ENQUETES 12 7 QUADRO DE AVISOS 14 portal@up.com.br Apresentação Este manual contém informações básicas, e tem como objetivo mostrar a você, aluno, como utilizar as ferramentas do Portal Universitário e, portanto, não trata de todos os

Leia mais

Instalação do IBM SPSS Modeler Server Adapter

Instalação do IBM SPSS Modeler Server Adapter Instalação do IBM SPSS Modeler Server Adapter Índice Instalação do IBM SPSS Modeler Server Adapter............... 1 Sobre a Instalação do IBM SPSS Modeler Server Adapter................ 1 Requisitos de

Leia mais

Backup e restauração do Active Directory com o Acronis Backup & Recovery 11 White paper técnico

Backup e restauração do Active Directory com o Acronis Backup & Recovery 11 White paper técnico Backup e restauração do Active Directory com o Acronis Backup & Recovery 11 White paper técnico Aplica-se às seguintes edições: Advanced Server Virtual Edition Advanced Server SBS Edition Advanced Workstation

Leia mais

Índice. http://www.gosoft.com.br/atualiza/gosoftsigadmservico.pdf Versão 4.0

Índice. http://www.gosoft.com.br/atualiza/gosoftsigadmservico.pdf Versão 4.0 Índice I ENVIO DE BOLETOS POR E-MAIL... 2 APRESENTAÇÃO... 2 ALTERAÇÕES NO SIGADM CONDOMÍNIO... 4 ALTERAÇÕES NO SIGADM IMÓVEIS... 6 ALTERAÇÕES NO SIGADM CONCILIAÇÃO BANCÁRIA... 8 ALTERAÇÕES NO SIGADM CONDOMÍNIO

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

Leia mais

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Departamento de Ciências da Computação e Estatística Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP André

Leia mais

Um Arcabouço open source em Python para DBC com

Um Arcabouço open source em Python para DBC com Um Arcabouço open source em Python para DBC com Suporte à Evolução Dinâmica não Antecipada Yguaratã C. Cavacanti 1, Hyggo Oliveira de Almeida 1, Evandro Costa 2 1 Instituto de Computação Universidade Federal

Leia mais

GUIA RÁPIDO SISTEMA ANTIFURTO THEFT DETERRENT

GUIA RÁPIDO SISTEMA ANTIFURTO THEFT DETERRENT GUIA RÁPIDO SISTEMA ANTIFURTO THEFT DETERRENT SUMÁRIO Prefácio... 1 A quem se destina... 1 Nomenclatura utilizada neste documento... 1 Tela de login... 2 Tela Inicial... 4 Gestão de Dispositivo Acompanhar

Leia mais

GLADIADOR INTERNET CONTROLADA v.1.2.3.9

GLADIADOR INTERNET CONTROLADA v.1.2.3.9 GLADIADOR INTERNET CONTROLADA v.1.2.3.9 Pela grande necessidade de controlar a internet de diversos clientes, a NSC Soluções em Informática desenvolveu um novo produto capaz de gerenciar todos os recursos

Leia mais

Capítulo 25. Gerenciamento de Configuração. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D.

Capítulo 25. Gerenciamento de Configuração. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D. Capítulo 25 Gerenciamento de Configuração slide 624 2011 Pearson Prentice Hall. Todos os direitos reservados. Tópicos abordados Gerenciamento de mudanças Gerenciamento de versões Construção de sistemas

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE]

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE] 1/6 Banco de Dados O que é um Banco de Dados? Uma coleção de dados relacionados [ELMASRI/NAVATHE] Conjunto de dados integrados que tem por objetivo atender a uma comunidade específica [HEUSER] Um conjunto

Leia mais

Guia de Inicialização para o Windows

Guia de Inicialização para o Windows Intralinks VIA Versão 2.0 Guia de Inicialização para o Windows Suporte 24/7/365 da Intralinks EUA: +1 212 543 7800 Reino Unido: +44 (0) 20 7623 8500 Consulte a página de logon da Intralinks para obter

Leia mais

Qlik Sense Desktop. Qlik Sense 2.0.2 Copyright 1993-2015 QlikTech International AB. Todos os direitos reservados.

Qlik Sense Desktop. Qlik Sense 2.0.2 Copyright 1993-2015 QlikTech International AB. Todos os direitos reservados. Qlik Sense Desktop Qlik Sense 2.0.2 Copyright 1993-2015 QlikTech International AB. Todos os direitos reservados. Copyright 1993-2015 QlikTech International AB. Todos os direitos reservados. Qlik, QlikTech,

Leia mais

Sistema BuildParty para montagem e gerenciamento de eventos. Plano de Testes. Versão <1.1> DeltaInfo. Soluções para web Soluções para o mundo

Sistema BuildParty para montagem e gerenciamento de eventos. Plano de Testes. Versão <1.1> DeltaInfo. Soluções para web Soluções para o mundo Sistema BuildParty para montagem e gerenciamento de eventos Plano de Testes Versão DeltaInfo Soluções para web Soluções para o mundo DeltaInfo 2 Histórico de Revisões Data Versão Descrição Autores

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

SGBD x Disponibilidade

SGBD x Disponibilidade SGBD x Disponibilidade Objetivo Escopo Motivação Conceitos básicos Disponibilidade Redundância de software Redundância de hardware 1 Objetivo: Objetivo Discutir tecnologias e práticas operacionais utilizadas

Leia mais

Detecção e investigação de ameaças avançadas. VISÃO GERAL

Detecção e investigação de ameaças avançadas. VISÃO GERAL Detecção e investigação de ameaças avançadas. VISÃO GERAL DESTAQUES Introdução ao RSA Security Analytics, que oferece: Monitoramento da segurança Investigação de incidente Geração de relatórios de conformidade

Leia mais

Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB

Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB Alt-N Technologies, Ltd 1179 Corporate Drive West, #103 Arlington, TX 76006 Tel: (817) 652-0204 2002 Alt-N

Leia mais

Teste Funcional 3. Arndt von Staa Departamento de Informática PUC-Rio Março 2015

Teste Funcional 3. Arndt von Staa Departamento de Informática PUC-Rio Março 2015 Teste Funcional 3 Arndt von Staa Departamento de Informática PUC-Rio Março 2015 Especificação Objetivo desse módulo Apresentar uma modalidade de geração de casos de teste a partir de casos de uso Justificativa

Leia mais

FAT32 ou NTFS, qual o melhor?

FAT32 ou NTFS, qual o melhor? FAT32 ou NTFS, qual o melhor? Entenda quais as principais diferenças entre eles e qual a melhor escolha O que é um sistema de arquivos? O conceito mais importante sobre este assunto, sem sombra de dúvidas,

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Julio Cezar Fialho Freire de Carvalho 1, Aline Maria Malachini Miotto Amaral 2 1 INTRODUÇÃO

Julio Cezar Fialho Freire de Carvalho 1, Aline Maria Malachini Miotto Amaral 2 1 INTRODUÇÃO 26 a 29 de outubro de 2010 ISBN 978-85-61091-69-9 ESTUDO E DEFINIÇÃO DA APLICAÇÃO PARA CONTROLE DE VERSÕES DOS ARTEFATOS GERENCIADOS PELA FERRAMENTA S.A.Do.M (SOFTWARE ARTIFACTS DOCUMENTATION AND MANAGEMENT)

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

Manual do usuário - Service Desk SDM - COPASA. Service Desk

Manual do usuário - Service Desk SDM - COPASA. Service Desk Manual do usuário - Service Desk SDM - COPASA Service Desk Sumário Apresentação O que é o Service Desk? Terminologia Status do seu chamado Utilização do Portal Web Fazendo Login no Sistema Tela inicial

Leia mais

15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função

15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função Análise por pontos de função Análise por Pontos de Função Referência: Manual de práticas de contagem IFPUG Versão 4.2.1 Técnica que permite medir a funcionalidade de um software ou aplicativo, sob a visão

Leia mais

Manual SAGe Versão 1.2 (a partir da versão 12.08.01)

Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação

Leia mais

Produto IV: ATU SAAP. Manual de Referência

Produto IV: ATU SAAP. Manual de Referência Produto IV: ATU SAAP Manual de Referência Pablo Nogueira Oliveira Termo de Referência nº 129275 Contrato Número 2008/000988 Brasília, 30 de outubro de 2008 1 Sistema de Apoio à Ativideade Parlamentar SAAP

Leia mais

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo? O que é a UML? Introdução a UML Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação

Leia mais

Exame de Fundamentos da ITIL

Exame de Fundamentos da ITIL Exame de Fundamentos da ITIL Simulado B, versão 5.1 Múltipla escolha Instruções 1. Todas as 40 perguntas devem ser respondidas. 2. Todas as respostas devem ser assinaladas na grade de respostas fornecida.

Leia mais

MANUAL DO USUÁRIO SUMÁRIO

MANUAL DO USUÁRIO SUMÁRIO SUMÁRIO 1. Home -------------------------------------------------------------------------------------------------------- 7 2. Cadastros -------------------------------------------------------------------------------------------------

Leia mais

Softwares de Sistemas e de Aplicação

Softwares de Sistemas e de Aplicação Fundamentos dos Sistemas de Informação Softwares de Sistemas e de Aplicação Profª. Esp. Milena Resende - milenaresende@fimes.edu.br Visão Geral de Software O que é um software? Qual a função do software?

Leia mais

PROTOCOLO 802.1X COM FRERADIUS FACULDADE DE TECNOLOGIA SENAC GOIÁS GESTÃO EM TECNOLOGIA DA INFORMAÇÃO

PROTOCOLO 802.1X COM FRERADIUS FACULDADE DE TECNOLOGIA SENAC GOIÁS GESTÃO EM TECNOLOGIA DA INFORMAÇÃO FACULDADE DE TECNOLOGIA SENAC GOIÁS GESTÃO EM TECNOLOGIA DA INFORMAÇÃO WISLIY LOPES JULIANO PIROZZELLI TULIO TSURUDA LUIZ GUILHERME MENDES PROTOCOLO 802.1X COM FRERADIUS GOIÂNIA JUNHO DE 2014 Sumário 1.

Leia mais

Treinamento Auditor Fiscal. Instrutor: Jaime Naves Gestora: Adriana Nunes

Treinamento Auditor Fiscal. Instrutor: Jaime Naves Gestora: Adriana Nunes Treinamento Auditor Fiscal Instrutor: Jaime Naves Gestora: Adriana Nunes Conceito: O Auditor Fiscal WEB é uma solução que permite a usuários de qualquer segmento empresarial realizar auditorias sobre os

Leia mais

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira.

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Período letivo: 4 Semestre. Quinzena: 5ª. Faculdades Santa Cruz - Inove Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Unidade Curricular Sistemas Distribuídos Processos

Leia mais

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN SISTEMAS OPERACIONAIS Apostila 03 Estrutura do Sistema Operacional UNIBAN 1.0 O Sistema Operacional como uma Máquina Virtual A arquitetura (conjunto de instruções, organização de memória, E/S e estrutura

Leia mais

Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software

Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software Ricardo Terra 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Campus da Pampulha 31.270-010

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Consistência e Replicação Capítulo 7 Agenda Razões para Replicação Replicação como técnica de escalabilidade Modelos de Consistência centrados

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Questões Em uma rede de sobreposição (overlay), mensagens são roteadas de acordo com a topologia da sobreposição. Qual uma importante desvantagem

Leia mais

CA Business Service Insight

CA Business Service Insight CA Business Service Insight Guia do Business Relationship View 8.2 A presente documentação, que inclui os sistemas de ajuda incorporados e os materiais distribuídos eletronicamente (doravante denominada

Leia mais

Conceitos Básicos e Implementação. Entrega de Serviços. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

Conceitos Básicos e Implementação. Entrega de Serviços. Professor Gledson Pompeu (gledson.pompeu@gmail.com) Conceitos Básicos e Implementação Pref. Mun. Vitória 2007 Analista de Suporte 120 A ITIL (information technology infrastructure library) visa documentar as melhores práticas na gerência, no suporte e na

Leia mais

Política de uso de dados

Política de uso de dados Política de uso de dados A política de dados ajudará você a entender como funciona as informações completadas na sua área Minhas Festas. I. Informações que recebemos e como são usadas Suas informações

Leia mais

3 SCS: Sistema de Componentes de Software

3 SCS: Sistema de Componentes de Software 3 SCS: Sistema de Componentes de Software O mecanismo para acompanhamento das chamadas remotas se baseia em informações coletadas durante a execução da aplicação. Para a coleta dessas informações é necessário

Leia mais

Manual de utilização do. sistema integrado de controle médico WWW.ISA.NET.BR

Manual de utilização do. sistema integrado de controle médico WWW.ISA.NET.BR Manual de utilização do sistema integrado de controle médico WWW.ISA.NET.BR Sistema integrado de controle médico Acesso... 3 Menu principal... 4 Cadastrar... 6 Cadastro de pacientes... 6 Convênios... 10

Leia mais

Seminário: Google File System (GFS)

Seminário: Google File System (GFS) UNIVERSIDADE FEDERAL DE SANTA CATARINA UFSC Disciplina: Sistemas Operacionais I INE5355 Alunos: Armando Fracalossi 06132008 Maurílio Tiago Brüning Schmitt 06132033 Ricardo Vieira Fritsche 06132044 Seminário:

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Sistema Web de Ensino Voltado aos Conteúdos da Física

Sistema Web de Ensino Voltado aos Conteúdos da Física Sistema Web de Ensino Voltado aos Conteúdos da Física Fábio Luiz P. Albini 1 Departamento de Informática, Instituto Federal do Paraná (IFPR) Curitiba, Paraná 81520-000, Brazil. fabio.albini@ifpr.edu.br

Leia mais

Falha benigna. Sistema. Sistema Próprio. Interrompido. Restauração. Falha catastrófica. Falha catastrófica. Sistema. Impróprio

Falha benigna. Sistema. Sistema Próprio. Interrompido. Restauração. Falha catastrófica. Falha catastrófica. Sistema. Impróprio INE 5418 Segurança de Funcionamento Tipos de s Detecção de s Recuperação de s Segurança de Funcionamento Representa a confiança depositada em um determinado sistema em relação ao seu correto funcionamento

Leia mais

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes

Leia mais

Ambiente Virtual de Aprendizagem C.S.G. M anual do Professor

Ambiente Virtual de Aprendizagem C.S.G. M anual do Professor Ambiente Virtual de Aprendizagem C.S.G. M anual do Professor Sumário Pré-requisitos para o Moodle... Entrar no Ambiente... Usuário ou senha esquecidos?... Meus cursos... Calendário... Atividades recentes...

Leia mais

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros (regras de interação)

Leia mais

Manual de Sistema - DDMantra

Manual de Sistema - DDMantra Prezado Cliente Bysoft Você acaba de adquirir um sistema de recuperação e consulta de informações automáticas do Mantra Neste material, você encontrará explicações de todos os recursos oferecidos pelo

Leia mais

Sistemas Operacionais

Sistemas Operacionais UNIVERSIDADE BANDEIRANTE DE SÃO PAULO INSTITUTO POLITÉCNICO CURSO DE SISTEMAS DE INFORMAÇÃO Sistemas Operacionais Notas de Aulas: Tópicos 7 e 8 Estrutura do Sistema Operacional São Paulo 2009 1 Sumário

Leia mais

Manual do Usuário Android Neocontrol

Manual do Usuário Android Neocontrol Manual do Usuário Android Neocontrol Sumário 1.Licença e Direitos Autorais...3 2.Sobre o produto...4 3. Instalando, Atualizando e executando o Android Neocontrol em seu aparelho...5 3.1. Instalando o aplicativo...5

Leia mais

Explore o IceWarp Versão 11.2 com HTML5 WebAdmin. www.icewarp.com

Explore o IceWarp Versão 11.2 com HTML5 WebAdmin. www.icewarp.com Explore o IceWarp Versão 11.2 com HTML5 WebAdmin A rotina da administração cotidiana pode ser divertida e simples com a nova e responsiva interface WebAdmin. Gerencie domínios, usuários, grupos e listas

Leia mais

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido Arquitetura Roteiro Arquitetura Tipos de Arquitetura Centralizado Descentralizado Hibrido Questionário 2 Arquitetura Figura 1: Planta baixa de uma casa 3 Arquitetura Engenharia de Software A arquitetura

Leia mais

Inicialização Rápida do Novell Vibe Mobile

Inicialização Rápida do Novell Vibe Mobile Inicialização Rápida do Novell Vibe Mobile Março de 2015 Introdução O acesso móvel ao site do Novell Vibe pode ser desativado por seu administrador do Vibe. Se não conseguir acessar a interface móvel do

Leia mais

Requisitos do Sistema

Requisitos do Sistema PJ8D - 017 ProJuris 8 Desktop Requisitos do Sistema PJ8D - 017 P á g i n a 1 Sumario Sumario... 1 Capítulo I - Introdução... 2 1.1 - Objetivo... 2 1.2 - Quem deve ler esse documento... 2 Capítulo II -

Leia mais

Resumo. Introdução Classificação Fases Curiosidades

Resumo. Introdução Classificação Fases Curiosidades Tolerância à falha Resumo Introdução Classificação Fases Curiosidades Introdução Sistemas Tolerantes a Falhas são aqueles que possuem a capacidade de continuar provendo corretamente os seus serviços mesmo

Leia mais

Como Configurar Catálogos de Correio Eletrônico com o MDaemon 6.0

Como Configurar Catálogos de Correio Eletrônico com o MDaemon 6.0 Como Configurar Catálogos de Correio Eletrônico com o MDaemon 6.0 Alt-N Technologies, Ltd 1179 Corporate Drive West, #103 Arlington, TX 76006 Tel: (817) 652-0204 2002 Alt-N Technologies. Todos os Direitos

Leia mais

PAINEL MANDIC CLOUD. Mandic. Somos Especialistas em Cloud. Manual do Usuário

PAINEL MANDIC CLOUD. Mandic. Somos Especialistas em Cloud. Manual do Usuário Mandic. Somos Especialistas em Cloud. PAINEL MANDIC CLOUD Manual do Usuário 1 BEM-VINDO AO SEU PAINEL DE CONTROLE ESTE MANUAL É DESTINADO AO USO DOS CLIENTES DA MANDIC CLOUD SOLUTIONS COM A CONTRATAÇÃO

Leia mais

Exame de Fundamentos da ITIL

Exame de Fundamentos da ITIL Exame de Fundamentos da ITIL Simulado A, versão 5.1 Múltipla escolha Instruções 1. Todas as 40 perguntas devem ser respondidas. 2. Todas as respostas devem ser assinaladas na grade de respostas fornecida.

Leia mais

Especificação Técnica

Especificação Técnica Pág. 1/8 CONTRATAÇÃO DE SOLUÇÃO SMS Pág. 2/8 Equipe Responsável Elaboração Assinatura Data Divisão de Padrões de Tecnologia DIPT Aprovação Assinatura Data Departamento de Arquitetura Técnica DEAT Pág.

Leia mais

Manual do Usuário ZKPatrol1.0

Manual do Usuário ZKPatrol1.0 Manual do Usuário ZKPatrol1.0 SOFTWARE Sumário 1 Introdução de Funções... 3 1.2 Operação Básica... 4 1.3 Seleção de idioma... 4 2 Gerenciamento do Sistema... 5 2.1 Entrar no sistema... 5 2.2 Sair do Sistema...

Leia mais

A CMNet disponibilizou no dia 24 de junho para download no Mensageiro a nova versão do Padrão dos Sistemas CMNet.

A CMNet disponibilizou no dia 24 de junho para download no Mensageiro a nova versão do Padrão dos Sistemas CMNet. Prezado Cliente, A CMNet disponibilizou no dia 24 de junho para download no Mensageiro a nova versão do Padrão dos Sistemas CMNet. No Padrão 9 você encontrará novas funcionalidades, além de alterações

Leia mais

MARACATU. A component search tool. Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes

MARACATU. A component search tool. Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes MARACATU A component search tool Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes Vinicius Cardoso Garcia July 29, 2005 Agenda Introdução Especificação

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

CA Nimsoft Monitor Snap

CA Nimsoft Monitor Snap CA Nimsoft Monitor Snap Guia de Configuração do Monitoramento do WebSphere websphere série 1.6 Aviso de copyright do CA Nimsoft Monitor Snap Este sistema de ajuda online (o Sistema ) destina-se somente

Leia mais

Nome da Empresa Sistema digitalizado no almoxarifado do EMI

Nome da Empresa Sistema digitalizado no almoxarifado do EMI Nome da Empresa Documento Visão Histórico de Revisões Data Versão Descrição Autor 23/02/2015 1.0 Início do projeto Anderson, Eduardo, Jessica, Sabrina, Samuel 25/02/2015 1.1 Correções Anderson e Eduardo

Leia mais

Como conduzir com sucesso um projeto de melhoria da qualidade

Como conduzir com sucesso um projeto de melhoria da qualidade Como conduzir com sucesso um projeto de melhoria da qualidade Maria Luiza Guerra de Toledo Coordenar e conduzir um projeto de melhoria da qualidade, seja ele baseado no Seis Sigma, Lean, ou outra metodologia

Leia mais

15 Conceitos de Bancos de Dados com o LibreOffice Base

15 Conceitos de Bancos de Dados com o LibreOffice Base Introdução a Informática - 1º semestre AULA 14 Prof. André Moraes Objetivos desta aula: Explorar as propriedades na criação de bancos de dados no LibreOffice Base; Criar e explorar tabelas; Criar e explorar

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais