Escolha um número O Request Tracker é um poderoso sistema de helpdesk open source que mais administradores deveriam conhecer. por Julian Hein A Information Technology Infrastructure Library (ITIL ou biblioteca de Infraestrutura de Tecnologia da Informação) [1], que foi desenvolvida nos anos 80, se estabeleceu nos anos recentes como o Padrão para Gerenciamento de Serviços de TI (ITSM). Uma das funções mais importantes dentro do framework é o service desk o ponto de contato único e central para todos os usuários. Logo surgiram grandes versões comerciais de suítes de software para ITIL, mas já há sistemas de código aberto disponíveis. Dentre eles, destacam-se o OTRS [2] e o Request Tracker (RT) [3], que podem ser usados para gerenciar processos de suporte a um amplo espectro de negócios. Neste artigo, me concentrarei no RT. Tudo no lugar O RT oferece todas as funções que você precisa para operar um sistema de controle, incluindo aceitação e identificação de email ou outros chamados, alocação de prioridades, atribuição de protocolos para a equipe operacional, notificação para o solicitante original e fechamento do chamado no final do processo. Embora muitos clientes e usuários finais usem o email para se comunicar com a aplicação, o help desk pode contar com uma interface web limpa, que já foi traduzida para mais de 30 idiomas (figura 1). O código fonte da versão atual (3.8.8) está disponível no site do fornecedor e é licenciado sob GNU GPL. A instalação manual do software definitivamente não é algo trivial. Além de um servidor web e um banco de dados, você precisará de um grande número de módulos Perl, alguns dos quais precisam ser instalados manualmente. O RT está disponível em muitas distribuições Linux por meio do sistema gerenciador de pacotes, sendo que o Ubuntu conta com a versão mais recente. No campo dos bancos de dados, o RT é compatível com o clássico MySQL, mas também com PostgreSQL e Oracle. 74 www.admin-magazine.com.br
Após completar a instalação e a configuração básica no arquivo de configuração do RT, você pode configurar o resto das ferramentas praticamente apenas através da interface web, como as filas de atendimento onde os chamados individuais são processados. Muitas outras coisas, como privilégios de usuários, templates de email ou campos adicionais são normalmente configurados individualmente para cada uma dessas filas, embora você possa criar itens globais no sistema. Na verdade, o administrador só precisa de uma visita rápida ao console para se conectar ao servidor de email, uma vez que o email de entrada é aceito pelo programa local rt-mail-gate e encaminhado para o RT. Você precisa configurar esse programa e acertar todos os parâmetros necessários como o destinatário em seu servidor de email local. Após esses passos, usuários finais podem usar o email para abrir chamados e enviar mensagens de erro para o sistema de protocolos (tickets). Se o sistema está configurado para tanto, os usuários finais receberão uma resposta automática com o número do protocolo atribuído ao caso e uma explicação dos próximos passos. O RT sempre cria protocolos individuais a partir das mensagens que recebe e então as exibe na área de tickets/ protocolos ainda sem dono (unowned) na interface web. Dependendo do fluxo de trabalho necessário, a equipe de help desk poderá se responsabilizar pelos protocolos voluntariamente ou eles podem ser atribuídos por um responsável com base no assunto e na carga de trabalho dos funcionários disponíveis. A equipe de suporte pode então usar a ferramenta para fazer perguntas que ajudarão a resolver o problema. A ferramenta cria logs e armazena todos os passos em um histórico com marcações de tempo. Isso significa que, se um membro da equipe fica doente, ou tem que transferir o caso para outra pessoa, o novo responsável pode ver imediatamente o que foi discutido e o que aconteceu até o ponto em que parou. Figura 1 A página principal da interface web dá ao usuário um bom panorama dos protocolos atuais. A aba The Basics contém as propriedades básicas dos protocolos, como número, status atual, prioridade inicial e final, e a fila para a qual o protocolo foi atribuído. A área People contém detalhes dos indivíduos associados ao protocolo, incluindo o Requestor (quem enviou o email com o pedido original) e o dono da tarefa (Owner), ou seja, a pessoa responsável pelo processamento do caso. Além disso, você pode adicionar outras pessoas para o protocolo (chamadas de watchers, ou observadores), que recebem cópias das correspondências de email associadas ao protocolo com níveis variados de detalhes. O administrador geralmente quer configurar o sistema de forma que pessoas externas recebam as cópias como se fosse o próprio requisitante e adicionar a equipe interna na correspondência com a identidade como TECNOLOGIA Protocolos e filas Os protocolos incluem uma variedade de campos e são subdivididos em vários grupos. O grupo é definido no cabeçalho de cada protocolo. As categorias individuais podem ser ocultas ou exibidas e codificadas com cor para fácil identificação (figura 2). Figura 2 O cabeçalho do protocolo, com todos os metadados. Admin Magazine #4 Dezembro de 2011 75
Figura 3 Visualização de dependência entre múltiplos protocolos. AdminCCs. A grande diferença reside na configuração do fluxo de trabalho. Os copiados externos somente receberão os emails trocados, enquanto AdminCcs também recebem comentários internos. Além disso, você pode se corresponder com parceiros e colegas de trabalho dentro de um único protocolo, sem que o cliente receba comentários internos e potencialmente confidenciais. Os vários campos de data estão localizados no painel Dates. Embora os campos Created (criado), Closed (fechado) e Updated (atualizado) sejam configurados automaticamente, você pode configurar manualmente Starts (inícios), Started (iniciados), Last Contact (último contato) e Due (devido). Os campos de dados servem meramente para calcular prazos ou para computar tempos de resposta para propósitos de controle. A data Figura 4 Visualização da história de processamento do protocolo. também suporta monitoramento e avaliação precisa dos níveis de serviço. Ligações entre vários protocolos formam outra função organizacional do RT. Você pode usar o recurso para modelar dependências entre diversas tarefas no painel Links. Os tipos de relacionamentos são Depends on (depende de), Children (derivado) e Refers to (se refere a). Se você configurar uma relação do tipo "o protocolo nove é "pai" do protocolo três". Com base nesses relacionamentos, você pode introduzir regras lógicas no sistema de protocolos. Por exemplo, um protocolo que depende de outros protocolos não pode ser finalizado até que eles também sejam finalizados. O RT pode visualizar essas dependências através de múltiplos níveis, criando gráficos de dependência a partir dos dados de um protocolo (figura 3). Para se lembrar (ou lembrar outro usuário) de um prazo importante, você pode criar lembretes para os protocolos, que são exibidos na página inicial ou despachados por email. Além dos dados básicos, o RT consegue registrar também o histórico completo do processo, incluindo estampas de tempo e quaisquer campos que sejam modificados. O histórico é exibido após os metadados em qualquer protocolo (figura 4). Para preservar a atividade de auditoria do sistema, não há opção de deletar ou manipular as transações na interface web. Claro, o usuário pode modificar quase qualquer coisa do ticket, mas o sistema sempre criará registros com detalhes sobre quem modificou, o que foi modificado e quando. As várias filas são usadas para processar protocolos e normalmente organizadas por tópico, departamento ou processo. Filas podem possuir seu próprio endereço de email, prioridades e prazos. As permissões também são configuradas de uma forma em que sejam específicas para filas. Isso significa que você pode definir com precisão qual departamento pode ver, modificar e possivelmente deletar os protocolos. Essas configurações podem ser definidas por usuário, grupos de usuários e papéis. Para cada fila, o administrador configura observadores individuais para receber automaticamente cópias da correspondência sem que haja a necessidade de configurar isso para cada protocolo. Por exemplo, um líder de equipe pode ser notificado de todas as ações que ocorrem dentro do seu departa- 76 www.admin-magazine.com.br
mento. Os fluxos de trabalho e campos personalizados descritos são também configurados de acordo com a fila específica. Estrutura de fluxo de trabalho Todas as ações automatizadas no Request Tracker são controladas por um mecanismo interno de scripts. As regras correspondentes são definidas como scrips [4], que é uma brincadeira com os termos script e subscription (subscrição). Uma regra sempre abrange três partes: condição, ação e modelo. Para configurar isso, você precisará definir qual evento dispara qual ação com qual condição. Exemplos de tais eventos são On Create, On Resolve, On Owner Change, On Priority Change, On Status Change e On Comment. A segunda configuração, Action (ação), define a ação que será disparada quando um evento ocorre. Exemplos disso são mensagens de emails, como Autoreply to Requestor (resposta automática), Notify Owner (notificar dono do protocolo), Notify AddminCCs as Comment (notificar administradores); ou várias ações de protocolos, como Open Ticket (abrir protocolo), Resolve Ticket (solucionar protocolo) ou Create Ticket (criar protocolo). A terceira configuração, Template, define o template a ser usado quando uma ação se executa. Ele pode ser de email ou de um novo protocolo. Dentro desses templates, todas as propriedades do protocolo podem ser usadas como variáveis. O RT substituirá as propriedades depois, com dados em tempo real do protocolo em questão quando um script é executado (listagem 1). Como você pode ver na listagem 1, usuários receberão uma resposta automática quando um chamado for atribuído a uma pessoa. Essa resposta preenche diversas funções: informa ao usuário que o pedido foi recebido, dá informações sobre o protocolo e informa sobre os passos do processo. Esse comportamento pode ser configurado usando: Condition: On Create Action: Autoreply to Requesto Template: Autoreply Template O mecanismo de script torna possível a configuração e automatização do RT e seus processos, de forma que permita uma configuração altamente granular da lógica de correspondência completa isto é, o que acontece quando o email chega, qual é a TECNOLOGIA Listagem 1: Exemplo de um template RT 01 Assunto: [{$rtname} #{$Ticket->id()}] Ticket closed! 02 03 Concluímos o seguinte protocolo: 04 05 Protocolo: [{$rtname} #{$Ticket->id()}] 06 Fila: {$Ticket->QueueObj->Name} 07 Assunto: {$Ticket->Subject (Nenhum assunto) } 08 Dono: {$Ticket->OwnerObj->Name} 09 Requisitante: {$Ticket->Requestors->EmailsAsString()} 10 URL do protocolo: {$RT::WebURL}Ticket/Display.html?id={$Ticket->id} 11 12 Por favor, confira o conteúdo. Se tudo lhe satisfizer, 13 nenhuma ação adicional é necessária. Se o problema 14 ainda persistir, responda a este email: neste caso, 15 o protocolo será reaberto automaticamente. Obrigado. Listagem 2: Criação especial de endereço 01 if ($self->ticketobj->requestoraddresses =~ m/lc\@customer\.com/) { 02 $RT::Logger->error( Add Helpdesk Address ); 03 $self->ticketobj->addwatcher( Type => Cc, Email=> helpdesk@customer.com ); 04 } Admin Magazine #4 Dezembro de 2011 77
Figura 5 Relatório sobre as licenças usadas para vários protocolos. aparência do email de saída e quais ações são disparadas por email. Os Scrips também podem ser usados para controlar o comportamento dentro do RT. Por exemplo, quando um protocolo é fechado em uma fila, outro pode ser criado automaticamente em outra fila por exemplo, para suportar tarefas de garantia de qualidade após o término de um chamado. Além de eventos e ações pré-definidas, você pode criar várias versões para um usuário particular. Uma vez que o RT foi escrito em Perl, scrips autodefinidos são criados na sintaxe Perl. A listagem 2 mostra uma ação definida por usuário que sempre ocorre quando um protocolo é criado. O script checa o endereço do remetente para o padrão @cliente.com. Se o nome do domínio ocorre no endereço, um endereço de email adicional (heldeskp@ customer.com) é adicionado como cópia no email. Dessa forma, o help desk do cliente sempre recebe cópias de cada email. Esse tipo de funcionalidade permite a automatização de muitas tarefas de email dentro do sistema de protocolos. Classificando tickets com campos personalizados Outra função muito poderosa no RT são os campos personalizados, os quais o administrador gerencia por meio de um menu separado de configuração. Além dos protocolos, campos personalizados podem ser criados para filas, usuários, grupos de usuários e até mesmo para transações de protocolos. O RT suporta tipos diferentes de campos personalizados, como listas drop-down com seleções simples e múltiplas, campos de texto simples, campos complexos que usam CamelCase e atualizam campos para arquivos anexados, entre outros. Os campos podem ter opções de seleção pré-definidas, checar a valide dos dados inseridos e podem até mesmo ser inseridos na forma de um formulário de entrada de texto livre. Os administradores podem adicionar um campo personalizado para uma ou múltiplas filas. O campo personalizado existirá somente nas filas para os quais foram criados. Por exemplo, só faz sentido especificar o nome de impressora nos protocolos relativos a problemas de impressão. Você pode atribuir permissões de usuário para campos individuais. Isso permite que você defina com precisão quais usuários ou grupos podem ver, modificar ou gerenciar propriedades de campos individuais personalizados. Esses campos podem ser usados também no escopo dos fluxos de trabalho. Por exemplo, uma liberação pode ser emitida somente pelo gerenciador de liberações. Outros usuários podem talvez ver o campo, mas sem permissão para fazer modificações. Quando o gerente modificar o campo de status, o mecanismo de fluxo de trabalho libera automaticamente a mudança correspondente. Relatório Um sistema integrado de relatórios garante a capacidade de gerar e visualizar várias estatísticas. Por exemplo, se você precisa de um relatório mensal, deve primeiro definir o critério de busca necessário para a avaliação, como todos os protocolos processados na fila de requisições que foram criados no último mês. Você também pode armazenar esses critérios de busca para evitar ter de recriá-los no mês seguinte. O usuário pode exibir e avaliar os resultados como uma lista de protocolos para visualizar, por exemplo, qual usuário criou os protocolos e até mesmo usar os campos personalizados para isso. Por exemplo, se você tem um campo de licença, pode identificar os números das licenças de software (figura 5). Personalizações e extensões Como já mencionei, o RT se adapta bem às necessidades específicas de uma organização, mas você também pode modificar usu- 78 www.admin-magazine.com.br
ários individuais ou papéis. Essa tarefa normalmente é feita ao se configurar filas, fluxos de trabalho e campos personalizados, mas até mesmo a interface web é configurável em muitos aspectos. Por exemplo, usuários podem criar painéis de visualização individuais para tarefas especiais perto do painel de visualização na página inicial. Um usuário que age como um gerente de mudanças precisa de uma visualização diferente dos protocolos em relação a alguém do operacional. No seu painel de visualização de gestão de mudanças, esse usuário pode ver protocolos de outras áreas também. Além disso, a visualização e a estruturação de protocolos não são organizadas por fila, mas por status do processo. Por exemplo, os protocolos podem ser organizados em uma lista de mudanças que ainda precisam de aprovação, de mudanças que estão esperando por implementação e de mudanças que foram implementadas, mas ainda precisam ser liberadas. Além dessas opções de configuração, o RT oferece muitas outras ferramentas e opções que fazem a vida do administrador mais fácil. Por exemplo, você pode publicar buscas ou filas inteiras em um feed RSS. Membros da equipe podem se subscrever para feeds e manter controle sobre mudanças importantes sem receber mensagens de email para o protocolo em questão. O feed RSS também pode ser usado para integrar informação do sistema de protocolos com outros meios, como wikis ou websites. Uma vez que ele usa o formato icalendar, as informações dos protocolos também podem ser integrados com o calendário. Usuários podem processar um grande número de protocolos similares ao mesmo tempo por operações em lote, para transferir os protocolos de maior prioridade para um colega se um administrador estiver doente. As mudanças podem até mesmo ser implementadas offline, salvando o dado do protocolo em um arquivo de texto e então importando os dados de volta ao RT após fazer mudanças; uma interface móvel do RT também está disponível para aprimorar o processamento em celulares e smartphones. Recursos além do escopo funcional podem ser adicionados como extensões [5]. A longa lista no wiki do RG inclui um construtor de fluxo de trabalho gráfico, assim como vários pacotes para estatísticas e relatórios ou para mapeamento e gerenciamento de acordos de níveis de serviço (SLAs). Com um pouco de conhecimento em Perl, os administradores podem fazer mudanças mais profundas e escrever seus próprios módulos. Eles podem ser claramente separados do código padrão e usados posteriormente, após uma atualização, sem a necessidade de mudar o código fonte cada vez que uma nova versão chega. Conclusões O RT é um sistema de controle em código aberto bem implementado e poderoso que os administradores devem levar seriamente em consideração. O software esteve sob desenvolvimento por anos e a lista de emails dele fornece um excelente apoio. Por conta de seus ricos recursos, arquitetura aberta e habilidade de personalização, o RT recompensa o usuário com instalação quase ilimitada e opções de extensão, após uma curva de aprendizado administrável. O autor Julian Hein é o fundador e CEO da empresa alemã NETWAYS (http://www.netways.de), que atua na implementação e operação de redes complexas há mais de dez anos. Mais informações [1] ITIL: http://en.wikipedia.org/ wiki/information_technology_ Infrastructure_Library [2] OTRS: http://otrs.org/ [3] Request Tracker: www.bestpractical. com/rt/ [4] Script: http://requesttracker.wikia. com/wiki/scrip [5] Extensões RT: http://requesttracker. wikia.com/wiki/extensions Gostou deste artigo? Veja este artigo em nosso site: http://www.lnm.com.br/admin/ article/5741 Queremos ouvir sua opinião. Fale conosco em: cartas@admin-magazine.com.br TECNOLOGIA Admin Magazine #4 Dezembro de 2011 79