É correto contornar Incidentes através de processos de Gerenciamento de Mudanças?
Por mais estranho que pareça, esta duvida ainda é bastante comum, como já me fizeram por diversas vezes esta mesma pergunta, vamos aqui tentar auxiliar aos interessados a chegarem ao um denominador comum, em uma abordagem o mais prática possível e ressalvando as dificuldades e restrições pelo uso da forma escrita.
Para isto, é necessário registrar alguns pontos iniciais, que podem auxiliar no entendimento da questão.
1. O que é Incidente:
Primeiramente precisamos entender o que é um Incidente: Em tese, um incidente é todo tipo de imprevisto (Já vivenciado ou não) e que durante a sua ocorrência pode vir a comprometer ou causar impacto nas operações normais de uma organização.
Ex:
- Parada de um servidor durante o seu período normal de operação;
- Parada do sistema de emissão e notas fiscais durante o período de pico da expedição de mercadorias;
- Lentidão no trafego de dados em um determinado momento do dia, onde se executa alguma rotina crítica de negócio, causando a demora na conclusão desta rotina.
1.1. Objetivo do Processo de Gerenciamento de Incidentes:
O processo de Gerenciamento de Incidentes possui um objetivo muito claro e muito específico, que é: “Tomar as providencias necessárias, no menor tempo possível, para que a as operações da organização retornem ao seu estado normal de operação através do contorno/solução dos incidentes”.
Exemplo:
Durante o processo de tratamento do incidente há alguns passos formais a serem seguidos, e quando são praticados, os passos mais comuns são:
- Identificação do Evento,
- Confirmação do Evento;
- Abertura do registro do incidente
a. Identificação da Causa,
b. Tratamento da Causa,
c. Aplicação da correção,
d. Validação do contorno do incidente e,
4. Encerramento do registro do incidente,
Até aqui, nenhuma novidade, e normalmente são assim mesmo que as coisas acontecem em um
IRT – Incident Response Team / Service-Desk,
1.2. O que se Pretende Resolver:
a) Há casos onde o ciclo de vida do incidente deve ser executado em questão de alguns poucos minutos, dependendo da gravidade e do impacto causado pelo mesmo aos negócios da organização.
Obs.: (Pense em um site de vendas pela Internet permanecer algumas horas fora do ar…isto em si, já poderia representar um grande prejuízo, e ainda poderia ser transformado em uma calamidade, se o momento da parada, fosse às vésperas do dia de Natal);
Exemplos de Algumas Possíveis Causas:
- Erro lógico na Aplicação
- Vulnerabilidade ou quebra de segurança
- Erro físico ou Lógico no Servidor de Aplicação;
- Erro físico ou lógico no Servidor de Banco de Dados
- Erro físico ou lógico no Serviço de Rede interna
- Erro físico ou lógico no Serviço de Rede Externa
- Erro em algum componente de Hardware / Software que suporte a aplicação ou serviço
Dependendo da complexidade do ambiente (Quanto mais crítico o serviço mais complexo será o ambiente que lhe presta suporte, e quanto mais complexo o ambiente, mais difícil será identificar qual é a causa que provocou o incidente), e ainda poderíamos ter diversas pequenas causas que se somadas, poderiam promover a ocorrência do mesmo tipo de incidente ou Consequência:
b) Em Razão disto, o item mais crítico o tratamento de um incidente é identificar a sua existência (Algum evento já está ocorrendo), algumas equipes são informadas da existência de um incidente pelo usuário, e ai.., já se foram até os 30 minutos de prazo previstos para o seu contorno. E neste caso, somente a partir de então dará inicio a busca da causa e promover as ações para o seu tratamento/contorno.
2. O que é Mudança:
Em tese, uma mudança é um processo formal, planejado e documentado para aplicação de melhorias ou alterações estruturais ao ambiente (Infraestrutura, serviços, aplicações, segurança, processos, etc…). Toda mudança deve prever, avaliar e tratar todos os impactos que por ventura ela possa vir a causar ao ambiente onde será promovida.
Ex:
- Migração de dados de um servidor para outro;
- Promoção de um pacote de melhorias em uma aplicação;
- Instalação e configuração de uma nova rede / sub-rede
- Instalação, migração ou Upgrade de versão de um serviço;
2.1. Como as mudanças podem ser classificadas
As mudanças podem ainda ser classificadas de acordo com o seu tamanho, complexidade ou quantidade de serviços /ativos envolvidos/impactados em sua aplicação.
a) Recomenda-se que mudanças Muito Complexas, sejam executadas através de Projetos de Gerenciamento de Mudanças;
Ex:
- Migração / Upgrade de Serviço Crítico
- Migração de Versão de Banco de Dados
- Migração de IP´s
- Instalação e Configuração de Storage
O Gerente de Projeto tem a função de gerenciar e integrar todas as atividades e pessoas envolvidas na execução da mudança a fim de que o objetivo do projeto seja atendido. O Projeto inclui no processo de mudança à atividade de gerenciamento e integração das equipes, que por sua natureza demora mais tempo que uma mudança simples (Dias, Semanas e até meses para ser concluída todas as atividades necessárias para a realização da mudança).
b) Mudanças mais simples ou menos complexas, podem ser executadas através de processos padronizados de Gerenciamento de Mudanças (Framework/Roadmap/Procedimento).
Ex:
- Aplicação de um pacote de atualização em um serviço.
- Instalação Física de um servidor
- Configuração de uma Nova VM
- Inclusão de base de dados na rotina de backup
O Gerente de Mudança tem a função de gerenciar as analises de impacto, prover as ações de contorno e integrar as atividades envolvidas na execução da mudança a fim de que todos façam a sua parte e mudança ocorra com êxito, uma dica nestes casos é que uma mudança não pode demorar mais que uma semana, se o seu ciclo de vida for maior que isto, sugerimos realiza-la através de um projeto.
c) O que estes dois processos de mudanças tem em comum.
- Identificação prévia do Escopo/Objetivo da Mudança
- Analise de impacto no ambiente
- Estimativa de esforço e Prazo /Previsão de Entrega
- Analise de impacto no ambiente
- Preparação prévia do ambiente para aplicação da mudança.
- Alocação de Recursos humanos e Técnicos.
- Ambos possuem um responsável indicado pelo planejamento, controle e execução.
d) Em que estes dois processos de mudanças são diferentes.
A diferença básica é na forma ou na abordagem aplicada no planejamento, execução e controle, ou seja, quanto mais complexo, mais longo for o tempo necessário para aplicação de uma mudança, maior deverá ser o nível de robustez do processo responsável pelo seu planejamento, execução e controle de execução.
a) O Gerenciamento de Mudança é indicado para mudanças com ciclo de vida mais curto e possivelmente menos complexos, suas etapas são executadas através de reuniões de planejamento e controle e as atividades são endereçadas através de roadmap para as mesmas pessoas da equipe de mudanças. O Próprio processo se encarrega de empurrar ou direcionar a aplicação da mudança, o gerente de mudanças conduz o e monitora as atividades conforme as regras previstas no processo.
b) O Projeto de Gerenciamento de Mudança é indicado para mudanças que tem ciclo de vida mais longo, onde os eventos da mudança passam a ser as etapas do projeto, as pessoas alocadas podem ou não fazer parte da equipe de mudança, o nível de risco é proporcional a complexidade do projeto, e as atividades necessárias para a sua execução extrapolam as ações previstas no processo de Gerenciamento de mudança tradicional. O planejamento, execução e o controle é mais complexo e necessita de um agente que promova a sua integração e controle, características mais aderentes a função de Gerente de Projeto, o qual tem responsabilidade de puxar o processo de mudança e garantir a sua aplicação.
3. Retornando A Dúvida Inicial:
Com estas explanações preliminares já é possível perceber a diferença entre os dois processos e mais precisamente entender os motivos pelos quais um Incidente não deve, em tese, ser contornado/solucionado através de uma mudança.
Mas quando um incidente é contornado/solucionado através do próprio processo de incidente (O que seria o mais recomendado), as duvidas tornam a aparecer, vejamos quais são as mais frequentes:
3.1. Dúvidas Operacionais:
O Gerente de incidentes, em principio efetuou o seu trabalho , e com um pouco de sorte e competência técnica de sua equipe, o mesmo tenha sido contornado dentro dos limites de tempo estabelecidos pelo (SLA) – Nível de Serviço estipulado para o tipo de incidente em questão.
O Gerente de Mudanças acredita que houve um erro, pois qualquer tipo de mudança deveria em tese ser efetuada somente através do processo de Gerenciamento de Mudanças, afinal de contas, foi alterada alguma coisa no ambiente, tal é o fato de que houve uma aplicação de correção, e claramente a mesma foi executada “fora do processo” de gerenciamento de mudanças.
3.2. Dúvidas Conceituais que geram a controvérsia (e Graves…):
- Um incidente grave ao ponto de interromper todas as operações de uma organização é um “problema” , e que para ser resolvido, devido à gravidade do fato, deverá ser realizada uma Mudança conformidade com o processo de Gerenciamento de mudanças.
- Qualquer tipo de mudança promovidas no ambiente devem necessariamente ser executado pelo processo de Gerenciamento de Mudanças.
- Há uma relação de um para um entre os Incidentes e Mudanças, e todos estão sujeitos a métricas de SLA – Níveis de Serviço.
3.3. Dúvidas Decorrentes das Dúvidas anteriores…
a) Se o Incidente promoveu uma alteração no ambiente, porque ela não foi promovida pelo processo de Mudança?
– O Incidente tem tempo de resposta (Minutos, Horas) e a mudança aplicada no contorno do incidente não possui analise completa de causa raiz, foi realizada analise preliminar de possíveis causas, sucessivamente até que incidente fosse contornado.
Mesmo o serviço tenha retornado a sua condição de funcionamento, podem ainda haver outras causas não tratadas pelo incidente e o mesmo pode vir a recorrer.
O processo de mudança tem planejamento formal e prazo de entrega (Dias, Semanas, Meses), não cabe usar Gerenciamento de Mudanças para contorno de incidentes, devido ao fator tempo de resposta.
b) Como a mudança promovida pelo incidente foi documentada?
Há duas formas possíveis de documentar incidentes:
Incidentes não críticos são documentados na medida em que o incidente é tratado, devendo ser controladas e documentadas as mudanças através do processo de Gerenciamento de Configuração, ou quando o tratamento não envolver mudanças na configuração, através de descrição detalhadas das atividades executadas para o contorno do incidente.
Incidentes Críticos Podem ser documentados da mesma forma adotada na documentação de incidentes não críticos, porém, pode-se realizar isto assim que o incidente seja contornado/solucionado (Isto mesmo, pode-se documentar depois, justamente para agilizar o atendimento do incidente, (Veja Cobit item AI6).
c) Se os Incidentes promovem todas as mudanças necessárias no ambiente, para que serve então o processo de Gerenciamento de mudanças?
Como já vimos, as duas formas de aplicação de mudança (Através de Processo de Mudança ou através de Projeto de Mudança) não são aplicáveis para a solução de incidentes, devido a incidente possui tempo de resposta e os demais possuem prazo de entrega.
(Obs Importante: NÃO EXISTE SLA, SLO, SLM ou qualquer outro tipo de métrica orientada a medir nível de serviço que possa ser aplicável para o processo de GERENCIAMENTO DE MUDANÇAS, e as métricas aplicáveis nestes casos, podem ser as mesmas utilizadas para os projetos, Veja PMI/PMBOK).
Incidentes promovem ações de contorno ou corretivas urgentes, mudanças promovem instalações de novos serviços e melhorias no ambiente, portanto ambos os processos são necessários e muito importantes.
d) Deveria então existir um processo de mudança dentro do Incidente?
No sentido formal do processo de mudança Não e também não é a ação mais indicada, a documentação das possíveis “mudanças” aplicadas no contorno / solução de incidentes resume-se a documentação da causa identificada do incidente e na documentação da ação que efetivamente foi aplicada para o seu contorno ou solução (Ajuste, Correção, Parâmetros, etc..).
Aos que possuem ferramenta de Gerenciamento de configuração, a informação da ação podem ser registradas em uma ferramenta de (CMDB) é suficiente para documentar a mudança de quase todo tipo de incidente (Não se trata desastres e acidentes através de Incidentes).
Quando não se tem disponível uma ferramenta de (CMDB), basta identificar a causa e descrever as ações o mais detalhadamente possível, também pode ser válido para documentar as mudanças realizadas pelo incidente.
e) Quando e Como o gerente de mudança vai tomar conhecimento do que foi alterado pelo Incidente?
Esta pergunta é interessante, pois os dois processos podem se comunicar através do Processo de Gerenciamento de PROBLEMAS.
Note que um problema só pode ser aberto com base em incidentes, pode ser originado de um único incidente ou mais de um incidente, desde que haja alguma correlação entre eles (Mesmo Ativo, mesmo Serviço, mesmo consequência), e somente após os incidentes estarem encerrados, ou seja, os eventos já foram contornados/solucionados e o tempo de resposta do incidente já tenha sido atendido.
É responsabilidade do processo de Gerenciamento de problemas, analisar o conjunto de incidentes ocorridos em um determinado período, e realizar uma detalhada investigação de causa raiz (Quase como se fosse uma AUTOPSIA) dos incidentes mais relevantes ou recorrentes no mesmo periodo.
É através do problema, que TODAS as causas de um determinado incidente sejam identificadas e tratadas, de forma que o incidente não mais ocorra ou reduza a sua incidência.
Métricas aplicáveis ao Processo de Gerenciamento de Problemas são relacionadas à redução do volume de incidentes, Se um problema foi aberto, as causas foram identificadas, e as ações corretivas decorrentes do mesmo foram aplicadas com sucesso pelas Mudanças:
Dois Fatos podem ocorrer:
O Incidente deixará de existir
O Gerenciamento de Problemas cumpriu a sua função, indicou as melhorias corretas para eliminação das causas dos Incidentes, e estas por sua vez foram promovidas com exito pelo processo de Gerenciamento de Mudanças.
O incidente volta a ocorrer,
Há apenas tres hipóteses possíveis para a recorrencia deste incidente:
- Surgiu uma nova causa para ocasioná-lo,
- A analise de causa raiz realziada pelo processo de Gerenciamento de problema não foi suficientemente bem realizada para identificas todas as causas(Ficaram causas sem serem tratadas).
- Houve erros não identificados durante a aplicação da Mudança
As ações corretivas identificadas pelo processo de Gerenciamento de Problemas devem originar as Requisições de Mudanças destinadas as melhorias necessárias no ambiente.
f) Quem é o responsável pelo controle do conteúdo das mudanças aplicadas pelo processo de Gerenciamento de Incidentes, Gerente de Mudanças e Gerente de Projetos de Mudanças?
O responsável pelo repositório de documentação das mudanças promovidas pelos Incidentes, Processo de Gerenciamento de Mudanças e Projetos de Gerenciamento de Mudanças é o processo de Gerenciamento de Configuração, ou seja, o controle do conteúdo é responsabilidade do Gerente de Configuração.
Se houver aplicação de CMDB, o controle deve ser feito pela própria ferramenta, quando não se possui este tipo de ferramenta, uma planilha detalhada para cada ativo passível de configuração, pode ajudar no controle.
Cada processo deve informar as suas mudanças no controle do Gerenciamento de Configuração.
4. Então, como estes processos são Integrados?
4.1. Incidentes:
Processo independente, não depende diretamente dos processos de Problemas e Mudanças, apenas identifica e valida os eventos verdadeiros e confirmando a existência de um incidente. Identifica causas possíveis do incidente, e promove as correções necessárias para que o evento seja contornado/solucionado.
Possui tempo de resposta de acordo com a severidade e impacto do incidente, e pode variar de alguns minutos a algumas horas.
4.2. Problemas.
Devem ser abertos problemas para incidentes graves ou muito recorrentes, para que se possam realizar investigação de causa raiz de todas as causas possíveis que possam gerar um determinado tipo de incidente.
O período de investigação pode durar em média de 5 a 10 dias, e gera como resultado o detalhamento da investigação de causas e endereçamento de recomendações de melhorias necessárias.
(Normalmente tratam-se incidentes graves individualmente, ou sejam 1 incidente Grave = 1 problema, e para os incidentes de menor severidade, pode-se criar um problema para um grupo de incidentes correlacionados, através da identificação de fatores de agrupamento (mesmo serviço, mesmo servidor, mesmo impacto).
Para incidentes não graves e isolados, não é necessário incluir o incidente no processo de Gerenciamento de Problemas.
Das analises de Causa Raiz e recomendações de ações corretivas são geradas as solicitações de mudanças
4.3. Mudanças,
As mudanças podem ser originadas de todas as dimensões relacionadas com o ambiente (Aplicações, Infraestrutura, Serviços e Segurança, etc…), quando uma mudança tem a função de resolver situações relacionadas a incidentes, deve haver um problema e as suas recomendações de melhorias previamente documentadas..
Se a mudança for relacionada a incidente e não houver um problema, que previamente a justifique, a execução desta mudança não possivelmente não promoverá a redução do volume do incidente ao qual se deseja eliminar/reduzir a sua incidência.
4.4. Configuração.
O Processo de Gerenciamento de Configuração devem manter o armazenamento dos seus registros a disposição dos processos anteriores, sendo utilizados como informações iniciais para a realização de suas atividades. Ao final de cada processo, os seus respectivos responsáveis deverão atualizar os registros para seu próprio uso no futuro, ou pelos demais processos.
—-
Este artigo está disponível para download no formato de Documento (PDF) na pagina de Download do Site da AGHATHA em : http://www.aghatha.com.br/
—- Fim Conteúdo Artigo —-
Agradecimentos e Convites:
As informações e comentários existentes neste artigo são o fruto de observações e experiências adquiridas pelo autor durante a execução de projetos ao longo de 30 anos de atuação no mercado. Utilizamos este espaço para a divulgação e intercâmbio destes conhecimentos junto aos nossos leitores, clientes e amigos.
Caso você tenha alguma dúvida ou necessidade de informações adicionais para o seu entendimento ou aplicação, entre em contato conosco através do e-mail abaixo.
Abraço e Felicidades a Todos,
Eurico Haan de Oliveira
www.aghatha.com.br
Consultoria@aghatha.com.br
———
Declaração e Preservação de Direitos:
Todas as demais marcas, modelos, desenhos, nomes, incluindo o conteúdo integral deste artigo, são de propriedade de seus respectivos fabricantes, autores ou publicadores.
O leitor está autorizado a fazer o uso interno e não comercial do conteúdo deste artigo, desde que mantidas as observações de direitos autorais e mantidas as referencias a suas origens e identificação dos respectivos autores e proprietários.
Direitos de uso comerciais deste artigo são preservados e mantidos em nome exclusivo do autor e o leitor não está autorizado a utiliza-los, de forma integral ou parcial para usos e fins comercias e/ou em atividades que visem à obtenção de lucro ou benefício comercial próprio ou a terceiros.
This work is licensed under a Creative Commons Atribuição-Uso não-comercial-Vedada a criação de obras derivadas 3.0 Unported License.
Para a confecção deste artigo foram citadas e/ou utilizados os seguintes nomes, marcas e publicações:
- COBIT ® 4.1, que é de propriedade exclusiva ISACA – Information Systems Audit and Control Association (www.isaca.org ) e IT Governance Institute™ (www.itgi.org), sendo Todos os direitos autorais reservados.
- Conteúdo Artigo – é de propriedade exclusiva do Autor e de AGHATHA (http://www.aghatha.com.br / Http://www.aghatha.com ), sendo os direitos preservados todos os direitos autorais e exploração comercial.
- COSO®, que é de propriedade exclusiva Committee of Sponsoring Organizations of the Treadway Commission (COSO)™ (www.coso.org/), sendo Todos os direitos autorais reservados.
- ISO-IEC® Standard – São de propriedade exclusiva do International Organization for Standardization (ISO®) e International Electrotechnical Commission (IEC®) (www.iso.org), sendo Todos os direitos autorais reservados.
- ITIL V-3 ® – IT Infrastructure Library® (www.itil-officialsite.com) que é de propriedade e proteção exclusiva da Coroa Britanica (www.ogc.gov.uk) – Office of Government Commerce (OGC) – UK, sendo Todos os direitos autorais reservados.
- PCAOB ® é propriedade exclusiva do Public Company Accounting Oversight Board – (http://pcaobus.org/), sendo Todos os direitos autorais reservados.
- PMI ® / PMBOK ® propriedade exclusiva do Project Management Institute ( www.pmi.org/), sendo Todos os direitos autorais reservados
– Fim Declarações de Direitos de Copyright —
— Fim Artigo
-30.018215
-51.186294
Read Full Post »
AGHATHA - Governança, Gestão de Riscos e Compliance 