ITIL v3 – Transição de Serviço – Parte 1

A Transição de Serviço é composto por um conjunto de processos e atividades para a transição de serviços no ambiente de produção. Aqui, deve-se encarar como um projeto de implantação, pois neste estágio do ciclo de vida precisamos gerenciar bem os recursos para implantar com sucesso um novo serviço ou uma alteração em um existente.

Irei abordar aqui os Gerenciamentos:

  • de Mudança;
  • da Configuração;
  • de Deliberações;

Gerenciamento de Mudança

As mudanças podem ser levantadas por várias razões, sendo elas do tipo proativa, para gerar benefício ao negócio (reduzir custos e melhorar os serviços, por exemplo) ou de forma reativa, para resolver erros e adaptar-se a circunstâncias de mudança.

“Mudança de Serviço” é a mudança de um serviço existente ou introdução de um serviço novo, ou seja, é a adição, modificação ou remoção de um serviço autorizado, planejado ou suportado ou componente de serviço e sua documentação associada.

“Requisição de Mudança (RDM)” é uma solicitação formal de mudança que busca alterar um ou mais Itens de Configuração, podendo ser uma Requisição de Serviço, chamada na Central de Serviços, documento do início do projeto. Cada tipo de mudança pode requerer diferentes tipos de Requisição de Mudança.

Os negócios de uma organização mudam frequentemente, pois as empresas se vêem obrigadas a melhorar seus produtos e serviços por questões de competitividade no mercado.

A TI precisa estar pronta para mudanças nos negócios ao mesmo tempo em que precisa buscar estabilidade na infraestrutura de TI. Toda mudança precisa ser feita com cautela para evitar incidentes, interrupções nos serviços atuais e até retrabalhos. Ao mesmo tempo que se a TI for muito demorada para estas mudanças, pode atrapalhar o andamento da empresa diante da concorrência. Diante disso, existe a necessidade de processos que controle, considere e trate os riscos destas mudanças.

O Gerenciamento de Mudança não garante que os risco deixaram de acontecer, mas devem mitigar ao máximo esses risco, de forma que eles sejam previsíveis e gerenciados.

Seus principais objetivos são:

  • Assegurar que as mudanças sejam feitas de forma controlada, e sejam avaliadas, priorizadas, planejadas, testadas, implantadas e documentadas;
  • Identificar os problemas que continuam aparecendo e que requerem mais mudanças;
  • Introduzir novas idéias e dispositivos que causem mais mudanças, com foco na qualidade;
  • Minimizar incidentes relacionados com a mudança;
  • Fazer o balanço entre a necessidade e impacto;

As Requisições de Mudança (RDM) estão classificadas em três categorias:

  • Padrão – Uma mudança de serviço que é pré-aprovada pelo Ger. de Mudança e já tem procedimentos aceitos e estabelecidos. Ex.: Upgrade no servidor; instalação de um novo computador para um funcionário da empresa; trocar uma estação de trabalho de lugar.
  • Normal – Esta mudança segue o fluxo normal de avaliação, aprovação e autorização. Ex.: Alteração do SO e plataforma tecnológica utilizada pelo serviço de e-mail.
  • Emergencial – Uma mudança de serviço que pretende reparar um erro em um serviço de TI que está causando um impacto negativo para a empresa, e que por isso, precisa ser corrigido rapidamente. Esta mudança precisa ser desenhada e testada, ou então poderá causar um impacto maior que o inicial. Ex.: A troca de um HD e os dados recuperados a partir do último backup.

As atividades seguem o seguinte fluxo:

  1. Criar e registrar a RDM – A RDM pode vir acompanhada de uma proposta de mudança que explica as facilidades que serão criadas para uma unidade de negócio, ou por que o Gerente de Problema quer implantar esta mudança para resolver um problema;
  2. Revisar a RDM – As partes envolvidas verificam se a RDM é viável, necessária, está com as informações completas e se já não existe um outro registro em aberto. Esta atividade normalmente é feita pelo Gerente de Mudança;
  3. Avaliar a Mudança – Aqui é feita a análise de risco para o negócio, a probabilidade de um risco acontecer e seu possível impacto;
  4. Autorizar a Mudança – Após a avaliação, a RDM será aceita ou não para executar a sua implantação;
  5. Coordenar a implantação – As RDMs autorizadas devem ser passadas para os grupos técnicos construírem a mudança, sendo o Gerenciamento de Mudança responsável apenas por controlar e coordenar, mas não de executar em si as mudanças;
  6. Revisar e encerrar – As mudanças implantadas, com exceção da Mudança Padrão, precisam ser avaliadas após certo tempo, se a mudança cumpriu o propósito inicial, se os usuários ficaram satisfeitos, se ocorreu algum efeito colateral, e se os custos e esforços estimaram excederam;

O Ger. de Mudanças tem forte vínculo com o Ger. da Configuração, pois é este último quem irá fornecer informações sobre os Itens de Configuração (ICs) que fazem parte da mudança. Através do Sistema de Gerenciamento da Configuração (SGC) o Ger. de Mudança pode avaliar os riscos e impacto da mudança. Sendo assim, o Ger. de Mudança troca informações com o Ger. da Configuração e também avisa-o quando as mudanças forem feitas com sucesso, para que o SGC seja atualizado.

Gerenciamento da Configuração

Este é o processo que identifica todos os Itens de Configuração (ICs) necessários para entregar o serviço de TI, onde irá fornecer um modelo lógico de infraestrutura de TI em que os serviços de TI são relacionados com os diferentes componentes necessários para fornecer o serviço.

Ele é o responsável pelos registros e atualizações dos Itens da Configuração e seus relacionamentos, não sendo apenas utilizado pelos processos da Transição de Serviço, mas também por todos os outros processo do ciclo de vida do serviço.

Entenda como Itens de Configuração:

  • Hardwares;
  • Softwares;
  • Documentação de processos e procedimentos;
  • Licensas;
  • Acordos de Nível de Serviço;
  • Planos de recuperação de desastres;
  • Políticas internas;
  • Plano de Negócio;
  • Planos de Capacidade e de Continuidade;
  • Acordos com clientes;
  • Pacote de Desenho de Serviço;
  • etc;

Algumas características do Ger. da Configuração são:

  • Suportar o negócio e os objetivos de controle e requisito do cliente;
  • Suportar de forma eficiente e eficaz os processos de Ger. de Serviço, fornecendo informações de configuração precisas;
  • Minimizar os números de questões sobre qualidade e conformidade causadas por configuração incorreta de serviços e ativos;
  • Otimizar os ativos de serviços, configurações de TI, habilidades e recursos;
  • Maior controle sobre os ativos da TI em uso;
  • Habilidade para executar serviços de TI com alta qualidade;

Muitas empresas não sabem o que possuem em sua infraestrutura nem o que entregam aos clientes. Quando se conhece a estrutura de TI, torna-se mais fácil gerenciá-la.

Seu objetivo principal é definir e controlar os componentes de serviços e infraestrutura, e manter informações precisas no histórico sobre configuração, estado dos serviços e infraestrutura atual e planejada.

Seu funcionamento básico é o seguinte, baseia-se nas informações sobre os ICs  que são mantidos no Banco do Gerenciamento de Configuração (BDGC), onde ele alimenta o Sistema de Gerenciamento da Configuração (SGC), que é o repositório central de informação que servirá de suporte para todos os outros processos de Gerenciamento de Serviços. É necessário que todas as informações estejam atualizadas e corretas, pois outros processos dependem destas informações.

As principais atividades do Ger. da Configuração são:

  1. Gerenciamento e planejamento – Define o escopo do que será controlado (serviços, aplicativos, infraestrutura, locais), políticas, papéis e responsabilidades, interfaces com outros processos, ferramentas a serem usadas, etc;
  2. Identificação da configuração – Define o critério para seleção de ICs e seus componentes, seleciona os ICs e componentes, associa um ID para cada IC especifica atributos relevantes;
  3. Controle da identificação – Garante que os ICs sejam gerenciados adequadamente, ou seja, nenhum deles podem ser removidos, alterados ou inseridos sem um procedimento definido;
  4. Controle de status e relatório – Controla o status do IC ao longo do seu ciclo de vida (em teste, em produção, em manutenção, aposentado);
  5. Verificação e Auditoria – Conduz auditoria para assegurar que as informações registradas conferem com a situação atual.

Gerenciamento de Deliberação/Liberação e Implantação

Assim que o Ger. de Mudança aprova uma mudança, o Ger. de Liberação pode entrar em ação para liberar novas versões de software/hardware no ambiente de produção. O Ger. de Liberação entra na etapa final, quando a mudança já foi desenvolvida e precisa ser liberada no ambiente de produção. Este processo vai se preocupar com os aspectos relacionados com a liberação de serviço, incluindo montagem do pacote da nova versão (empacotamento), instalação, treinamento de usuários e equipe de suporte.

Sua meta é distribuir liberações dentro da produção e estabelecer o uso efetivo de serviços, sendo assim, o valor pode ser entregue ao cliente e o serviço pode ser gerenciado pelo pessoal de operações. Este gerenciamento é responsável pelo controle de versões e instalação do software, hardware e outros componentes da infraestrutura, do ambiente de desenvolvimento ao ambiente de testes e depois para o ambiente de produção. Ele não é responsável pela mudança em si, mas sim pela sua liberação.

Seus objetivos principais são assegurar que:

  •  Existam planos de liberação e implantação claros e compreensíveis, alinhados com as atividades dos clientes;
  • Um pacote de liberação possa ser construído, instalado, testado e implantado de forma eficiente;
  • Um serviço novo ou alterado e seus sistemas, tecnologia e organizações sejam capazes de entregar os requisitos de serviço acordados;
  • Exista o mínimo de impacto imprevisto nos serviços em produção, operações e organização de suporte;
  • Clientes, usuários e equipes de Ger. de Serviço estejam satisfeitos com as práticas de serviço e as saídas.

Deve-se tomar três decisões importantes relacionadas à implantação de um serviço:

  • O nível de unidade de liberação mais apropriado para cada serviço ou componente;
  • Opção de implantação mais apropriada;
  • Modelo a ser usado para construir e implantar uma liberação de forma eficiente;

Existem diversas formas de implantação, cada um com um impacto e recursos diferenciados, que devem ser analisados para que haja um bom resultado:

  • Big Bang – O serviço é atualizado para todos os usuários da organização simultaneamente (Ex.: Sistema ERP);
  • Por Fase – A implantação ocorre por seção ou por base de usuários conforme um intervalo agendado (Ex.: atualização por departamento);
  • Empurrada – Implantação feita a partir de um local centra (Ex.: antivírus);
  • Puxada – A implantação é disponibilizada em um local central e os usuários fazem a implantação sozinhos. (Ex.: atualização de softwares que não precisam de mudança imediata);
  • Automática – Utiliza-se sistemas de implantação automatizada, quando o processo é repetível;
  • Manual – O pessoal da TI precisa implantar o serviço;

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Certificações que possuo: EC-Council CEH, CompTIA (Security+, CySA+ e Pentest+), EXIN (EHF e ISO 27001), MCSO, MCRM, ITIL v3. Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação e Ethical Hacking.

8 Responses to “ITIL v3 – Transição de Serviço – Parte 1”

  1. Richer William de Lima Verzeletti disse:

    A instalação de um equipamento novo como de exemplo um Switch, poderia ser utilizada uma RDM padrão, visto que o equipamento não está em produção?

    • Diego Macêdo disse:

      Se este tipo de procedimento for uma mudança de serviço pré-aprovada pelo Ger. de Mudança e já tiver procedimentos aceitos e estabelecidos, poderia. Caso contrário, poderá seguir como uma mudança normal, o que faz mais sentido, pois não é toda hora que se instala um Switch em um ambiente operacional. Além do mais, se esse equipamento for conectado a outros dispositivos durante a mudança, o impacto pode ser maior e por isto faria mais sentido continuar como uma mudança “normal”.

  2. Luiz disse:

    Diego, a quem você imputa a responsabilidade pela iniciativa de propor uma atualização de um ativo de TI (software) que está em operação? Seria de um integrante da própria operação ou seria de alguém do desenho do serviço?

    • Diego Macêdo disse:

      A iniciativa pode ser de qualquer um, desde que siga os trâmites da gestão de mudança. O ideal é que seja criado um formulário solicitando a atualização do software e este seja enviado para o comitê de gestão de mudança avaliar o impacto desta atualização, definindo se irão atualizar ou não.

  3. Erik disse:

    Dúvida em uma requisição de mudança, quem deve avaliar itens a serem aplicados (como demanda de origem) são os aprovadores ou executores? Existe alguma parte/termo dentro das práticas do Itil que realça isso?

  4. Miguel Amaro disse:

    Muito bom

  5. Adilson Cullmann disse:

    Belo Texto!! Ajudou demais no meu projeto 🙂

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *