ITSM Helix + iTRACS
Abre-se um ticket no Helix. Executa-se no DCiM. Fecha-se nos dois. Sem que o operador do data center toque alguma vez na ferramenta de ticketing.
O QUE ESTAMOS A INTEGRAR
Gestão e sincronização de tickets (Work Orders)
SISTEMAS INTEGRADOS
Helix - iTRACS
RESULTADO PRINCIPAL
O principal resultado é acabar com a dupla gestão de tickets. O operador do data center trabalha apenas no iTRACS, e as mudanças de estado (Em curso e Fechado) são sincronizadas automaticamente com o Helix.
Contexto da integração
iTRACS ON PREMISE
Fabricante: Commscope
Versão: 5.4.5 ou posterior
Módulos: WSDL
Helix CLOUD
Fabricante: BMC Software
Módulos: Web Services
O desafio: porque era necessária esta integração?
- Dupla gestão permanente entre o ITSM e o DCiM. Sem integração, cada ticket de alteração no data center é gerido duas vezes: no Helix (onde é aberto, atribuído e acompanhado no processo ITSM) e no DCiM (onde se planeia a localização, se executa a ligação e se comissiona o equipamento). O operador do data center tem de ler o ticket no Helix, transpor mentalmente a informação para o DCiM, executar o trabalho, voltar ao Helix para atualizar o estado e, por fim, fechá-lo nos dois sítios. Este trabalho duplicado não só consome tempo, como também gera incoerências: o ticket no Helix indica “em curso” quando o DCiM já o fechou, ou vice-versa. Com a integração, o operador trabalha apenas no DCiM e os estados propagam-se automaticamente.
- Informação do ticket incompleta ou inadequada para a execução física. Um ticket de comissionamento precisa de dados muito específicos para ser executado num data center: tipo de equipamento, fabricante, modelo, número de fontes de alimentação com a respetiva potência e tensão, placas PCI com tipo e número de portas, e linha de negócio. Sem integração, esta informação chega ao operador em formato livre (um email, um campo de texto genérico), e o operador tem de andar atrás do requerente para completar o que falta. A integração normaliza este fluxo: o formulário ITSM inclui os campos obrigatórios de que o DCiM precisa, e toda essa informação chega estruturada ao pedido do DCiM, pronta para planear.
- Falta de visibilidade do estado real de execução no ITSM. O responsável pelo serviço de TI vê no Helix que há 20 tickets de comissionamento abertos. Mas não sabe quais estão planeados, quais estão a ser executados fisicamente e quais estão bloqueados à espera de um rack livre. Essa informação vive apenas na cabeça do operador do data center ou no DCiM. A sincronização bidirecional de estados faz com que o Helix reflita a realidade operacional do data center: se o operador passar o ticket para “Em curso” no DCiM, o Helix mostra-o de imediato. O ITSM deixa de ser um sistema de tickets desligado da execução real.
- Rastreabilidade: o processo ITIL de gestão de alterações quebra-se à porta do data center. As organizações investem na implementação de processos ITIL com ferramentas como o BMC Helix para garantir rastreabilidade, aprovações e controlo de alterações. Mas, quando o ticket chega ao data center, o processo torna-se manual: o operador executa o trabalho sem que o ITSM reflita o que foi feito, quando, por quem e o que ficou documentado no DCiM. A integração estende o processo ITIL até ao último metro: cada mudança de estado no DCiM é sincronizada automaticamente com o Helix, e o fecho do ticket inclui o comentário do operador como confirmação de que o trabalho foi efetivamente concluído. É um fecho com evidência operacional.
- Atualmente, o ITSM Helix não dispõe de um conector nativo com o iTRACS. Esta limitação impede estabelecer um fluxo de comunicação automatizado entre os dois ambientes. Obriga a realizar determinadas tarefas manualmente e em duplicado, e a manter a informação sincronizada em ambos. Consequentemente, aumenta a carga operacional e o risco de inconsistências ou de informação desatualizada entre os sistemas.
Os sistemas do ecossistema
SISTEMA | DESCRIÇÃO | FORNECE | RECEBE |
ITSM Helix | Plataforma ITSM utilizada para a gestão e o registo de tickets/Work Orders. | Geração de Work Orders/Tickets e fornecimento da informação associada ao pedido. A criação de um pedido no REMEDY desencadeia a sua transferência para o iTRACS para tratamento. | Recebe do iTRACS a evolução do ticket, principalmente as mudanças de estado, mantendo sincronizada a situação da Work Order entre os dois sistemas. |
iTRACS | Plataforma de gestão de infraestrutura de centro de dados (DCiM). | Receção das Work Orders provenientes do Helix e respetiva gestão a partir desta plataforma. | Recebe os pedidos e a informação necessária para o seu tratamento, e devolve ao Helix as mudanças de estado geradas durante a gestão. |
O diagrama de ligação
A arquitetura é composta por dois sistemas externos (Helix e iTRACS) e um servidor de integrações. Este servidor contém, por um lado, os Web Services que recebem a informação do Helix e, por outro, uma aplicação que comunica ao Helix, de forma síncrona, as mudanças de estado que ocorrem no iTRACS.
O fluxo de dados em ação
Descreve-se a seguir o fluxo de trabalho de um pedido no iTRACS:
O processo de integração começa no Helix, onde se abre um novo pedido para a realização de uma tarefa no iTRACS.
O pedido fica registado no iTRACS na janela Manager (Workflow -> Manager).
Os projetos com os novos Requests do Helix são criados sob o projeto raiz “Remedy Requests”. Chamam-se “Remedy Request Ticket XXXX”, em que XXXX é o identificador do ticket do Helix. Cada projeto contém um Request com o mesmo nome.
Com o Request selecionado, podemos consultar no separador de notas a informação associada ao pedido.
O utilizador deverá confirmar o início das ações solicitadas no Helix, mudando o estado para “Em curso”. No iTRACS, corresponde ao estado “Planned”.
Esta mudança de estado invoca o agente de integração, que comunica a alteração ao Helix. Uma vez comunicado o estado ao Helix, o campo Reference refletirá a alteração no iTRACS, acrescentando ONGOING STATUS OK após o identificador do ticket.
Em caso de erro na comunicação com o Helix, o estado mudará para “Flagged” e será acrescentado ao campo “Reference” o estado da sincronização com o Remedy: “Status ONGOING ERROR”.
Para relançar o processo de sincronização, é necessário mudar manualmente o estado de novo para Planned.
O iTRACS faz 3 tentativas de comunicação antes de deixar o processo no estado ONGOING ERROR. Por isso, é possível que, passados alguns minutos após a mudança para Flagged, o estado volte automaticamente para Planned e ONGOING OK.
Passados alguns minutos, verificaremos que o estado foi também atualizado no Helix, consultando o campo Reference, que deverá indicar “Status CLOSED OK”.
Em caso de erro na sincronização com o Helix, o estado no iTRACS mudará para Flagged e o campo Reference indicará “Status CLOSED ERROR”.
Tal como no caso anterior, o iTRACS fará 3 tentativas de sincronização. Se, após essas tentativas, não conseguir comunicar com sucesso com o Helix, deixará o estado em “Flagged”, com Status CLOSED ERROR no campo Reference. Para voltar a tentar a sincronização, será necessário mudar manualmente o estado de novo para “Closed”.
MODELO E EXECUÇÃO
Orientado a eventos para a sincronização de mudanças de estado.
ACIONADOR
Criação de Work Orders e eventos associados a mudanças de estado no iTRACS.
O que fez a diferença
Decisões de design que não eram as óbvias, e porque as tomámos.
Fator-chave 1: Sincronização baseada em eventos
Optou-se por um modelo de sincronização orientado a eventos para propagar as mudanças de estado do iTRACS para o Helix. As mudanças de estado nas Work Orders do iTRACS geram eventos que desencadeiam automaticamente a execução do componente de integração e a correspondente atualização do ticket no Helix.
Esta abordagem permite manter ambas as plataformas sincronizadas em tempo real, minimizar os processos de consulta periódica e garantir uma maior coerência entre o estado operacional da Work Order no iTRACS e a sua representação no sistema ITSM.
O seu ecossistema tecnológico está preparado para se ligar?
Diga-nos que sistemas tem e quais precisa que comuniquem entre si.