TREINAMENTO

OPERAÇÃO
NOC
APRESENTAÇÃO
CONHECENDO O AMBIENTE

NOC é o acrônimo de Network Operate Center, somos responsáveis pela gerência do hardware e serviços de remote hands.
Estamos situados em 5 estados brasileiros mais o Distrito Federal.

 Brasília (DF)
• SIG
• SCN
 Curitiba (PR)
 Belo Horizonte (MG)
• TNE
• MPI
 Porto Alegre (RS)
 Rio de Janeiro (RJ)
• PRAIA
• RB1
 São Paulo (SP)
CONTATOS
CONTATOS
ESCALONAMENTO

Dentro de toda organização de TI que se preze, sempre existe o escalonamento a nível hierárquico, ou seja, de
baixo para cima, para todo e qualquer tipo de solicitação, quer seja dúvida, reclamação, informação, sugestão do
seu trabalho, isto deverá ser feito exatamente da forma que as informações acima estão dispostas, devemos
direcionar os eventos para o nosso ponto focal, caso a demanda solicitada não seja atendida, o ponto focal
passará a realizar o escalonamento hierárquico que consiste em passar as informações para quem está acima
dele, no caso o gestor e assim por diante.

Contudo, existe o feeling do operador, por exemplo, nos finais de semana, encontramos um evento crítico no qual
está degradando o ambiente de produção de TI da Oi de alguma forma, a primeira ação a ser tomada é entrar em
contato com o primeiro escalonamento, no caso a coordenação, caso não seja possível entrar em contato com o
mesmo, devemos partir para o próximo nível e assim por diante.

Na nossa área, é imprescindível que a gestão Oi seja informada de qualquer incidente massivo, ou demanda
impactante no ambiente para que no momento em que os mesmos forem acionados por outras equipes eles
estejam cientes do que está acontecendo no seu ambiente de responsabilidade. Portanto, a partir do momento em
que nos deparamos com uma crise, devemos informar tanto nossa gestão Global, quanto nossa gestão Oi.
APRESENTAÇÃO
BMC REMEDY Mid Tier 8.1
BMC REMEDY Mid Tier 8.1

A nossa principal ferramenta de trabalha se chama BMC Remedy Mid Tier 8.1. Segue link:

http://asepxweb:8080/midtier_linux/shared/login.jsp
BMC REMEDY Mid Tier 8.1

Esta é a ferramenta de atendimento aos “chamados” da infra-estrutura de TI da Oi, a partir dele nós estaremos
cientes dos alarmes, incidentes, solicitações, entre outros direcionados às filas do NOC.

O acesso a esta ferramenta se dá através de uma matrícula no qual nos é fornecida através da gestão, esta
matrícula também servirá para o acesso da rede da Oi e também dos servidores pertinentes aos nossos
procedimentos, tanto ambiente Windows como ambiente Unix/Linux.

Assim que obtivermos nossa matrícula, devemos inseri-la no campo “Nome de Usuário” e em seguida ao campo
“Senha”. O campo “Autenticação”, não se faz necessário o preenchimento para logar na ferramenta.
Posteriormente deve se clicar no botão “Logar”. A seguir uma imagem de como os campos devem ser preenchidos.
BMC REMEDY Mid Tier 8.1
COMO SURGEM OS CHAMADOS

Agora que estamos familiarizados com a ferramenta de tratamento de incidentes da Oi, o Remedy, vamos entender
como funciona o fluxo de abertura para alarmes automáticos que surgem na fila do NOC.

Existem duas maneiras para que surjam os alarmes na fila do NOC, são elas:

Automáticas;
Manuais;

Chamados gerados AUTOMATICAMENTE.

Para que isso seja possível existe uma ferramenta por nome de BEM, esta é a ferramenta que faz integração com
o Patrol Agent que está instalado dentro de cada servidor do ambiente de produção monitorado na Oi, através
dela são configurados os “tresholds” para monitoração do servidor, tanto física como lógica.
Está em andamento a atualização da monitoração de todo ambiente para o PNET que diferente do Patrol não
necessita da instalação de agentes nos equipamentos monitorados.
COMO SURGEM OS CHAMADOS

Chamados gerados MANUALMENTE.

São chamados abertos por qualquer usuário e/ou cliente através do Service Desk ou pelo próprio
solicitante através do Remedy.

- Através do Service Desk: Digamos que não estou conseguindo acessar determinado site e não tenho acesso ao
Remedy no momento ou não tenho permissão para utilizá-lo. Ligo no Service Desk, me identifico e solicito abertura de
um chamado para tratar minha reclamação. O Atendente por sua vez irá categorizar o chamado de acordo com meus
relatos gerando assim um chamado designado para fila solucionadora, seja do NOC ou não.

- Através do Solicitante: Digamos que novamente não estou conseguindo acessar determinado site, porém estou em
minha estação de trabalho com acesso e permissão para abertura de chamados através do Remedy. O primeiro passo
é abrir o Remedy e preencher os dados do solicitante, informar o problema no campo descrição e categorizar o
chamado de forma que seja designado para fila solucionadora.
No Remedy nós podemos tratar o ARS, PKE, PBI, CRQ e GMUD. Existem vídeos informando como tratar cada um
deles.
AGENTES DE SOLUÇÃO NOC
BSA
CY_OPERACAOBSA_N2_GLOBALWEB
CY_OPERACAOHWBSA_N2_GLOBALWEB
CY_OPERACAOGESTAOBSA_N2_OI
CY_HWFORNECEDORBSA_N2_OI
CY_CRQ_CYBER_CLIENTE_BSA_N2_OI
CY_CRQ_CYBER_HWPADRAO_BSA_N2_OI
INFRA_DC_OPERACAO_CLIENTES_BSA
PAE
INFRA_DC_OPERACAO_PAE
INFRA_DC_OPERACAO_HW_PAE
CY_CRQ_CYBER_HWPADRAO_RS_N2_OI
CY_HWFORNECEDORPAE_N2_OI
INFRA_DC_OPERACAO_CLIENTES_POA
BHE
INFRA_DC_OPERACAO_BHE
INFRA_DC_OPERACAO_HW_BHE
CY_CRQ_CYBER_HWPADRAO_BH_N2_OI
CY_HWFORNECEDORBHE_N2_OI
INFRA_DC_OPERACAO_CABLING_BHE
RJO
INFRA_DC_OPERACAO_PRAIA_RJO
INFRA_DC_OPERACAO_RB1_RJO
INFRA_DC_OPERACAO_HW_RJO
CY_CRQ_CYBER_HWPADRAO_RJ_N2_OI
CY_HWFORNECEDORRJO_N2_OI
INFRA_DC_OPERACAO_CABLING_RJO
CTA
INFRA_DC_OPERACAO_CTA
INFRA_DC_OPERACAO_HW_CTA
CY_CRQ_CYBER_HWPADRAO_PR_N2_OI
CY_HWFORNECEDORCTA_N2_OI
CY_OPERACAOGESTAOBSA_N2_OI
INFRA_DC_OPERACAO_CLIENTES_CTA
SPO
INFRA_DC_OPERACAO_SPO
INFRA_DC_OPERACAO_HW_SPO
CY_CRQ_CYBER_HWPADRAO_SP_N2_OI
CY_HWFORNECEDORSPO_N2_OI
INFRA_DC_OPERACAO_CLIENTES_SPO​
SEVERIDADES

A partir do momento que você coloca o chamado em andamento no seu nome, ele passa a ser de sua total
responsabilidade de execução, e ele deve ser tratado dentro de um prazo pré-estipulado e acordado com a gestão
Oi, que se chama SLA (service level agreement) ou ANS (acordo de nível de serviço).
Para que nós possamos entender estes sla’s propostos ao NOC nós precisamos, primeiramente, entender como
funciona a severidade de cada chamado. A Oi, hoje, trabalha com 4 severidades, seguem:

Severidade 4 – Falha pontual.

Severidade 3 – Falha de componente com redundância que não gere impacto nas atividades da área cliente.
Falha sistêmica que não gere impacto nas atividades da área cliente.

Severidade 2 – Falha sistêmica em aplicação e/ou funcionalidade que afete a execução das atividades da área
cliente porém sem impedir o seu trabalho. (Degradado)

Severidade 1 – Falha sistêmica em aplicação e/ou funcionalidade que impeça a execução das atividades da área
cliente. (Indisponível)
SLA

Existe um SLA para cada severidade:

Severidade 4
– 5 dias úteis
Severidade 3
– 24h corridas
Severidade 2
– 8h corridas
Severidade 1
– 4h corridas
CLASSIFICAÇÃO DO CHAMADO
Temos “Classificação do Chamado” para cada ARS, esta classificação serve para que a gestão de
incidentes e gestão de problemas atuem no estudo posterior de medidas que possam ser tomadas para
que o impacto deste incidente possa ser diminuído através da identificação da causa raiz. São eles:

Atividade Recorrente
Eventos já conhecidos pelo suporte no qual não existe possibilidade de serem extintos, tais como alarme
de disco;

Incidente
Qualquer evento que não faz parte do funcionamento padrão de um serviço e que sua causa poderá
causar uma interrupção ou redução na qualidade do serviço no qual será necessária a atuação posterior
para identificação de sua causa raiz e a possibilidade da diminuição do seu impacto;

Pedido de suporte

Pedido de ajuda enviado ao N3 ou demais áreas quando o responsável pelo serviço necessita de ajuda.
CLASSIFICAÇÃO DO CHAMADO

Evento
Alarme no ambiente de TI gerado automaticamente que deve ser registrado e que demandará uma ação das
equipes responsáveis pela gestão dos serviços. As categorias de monitoração de Eventos são de uso exclusivo da
ferramentas, isto é, não estão disponíveis para a classificação de um incidente pelo Service Desk. Exemplo: alarme
de queda de um nó do cluster do siebel.

Atividade Implantação
Atividade exclusiva da área de implantação de novos projetos e/ou novos serviços solicitados por clientes externos
e internos
STATUS DO CHAMADO
Designado
Este status ocorrerá somente na primeira fila de tratamento, que foi para a categorização o direcionou pela primeira vez;

Em Andamento
Este informa que o chamado está em execução por alguém;

Pendente
Este status é utilizado quando o chamado está aguardando alguma demanda interna ou a resolução de algum outro
chamado, quando o selecionamos devemos preencher o “detalhamento do status”;

Redesignado

Este status ocorre quando o chamado passa de uma fila para outra;

Resolvido
Quando a solução definitiva deste chamado foi executada;

Fechado
Ocorre o fechamento do chamado passado sete dias de resolvido;

Cancelado
Quando o chamado for aberto de forma improcedente, o NOC não cancela chamado, sempre devemos direcionar a fila
competente.
DIRECIONAMENTO DO ARS

Quando consultamos um procedimento que nos orienta a direcionar o chamado a uma fila específica, devemos
abastecer o histórico do chamado com a maior quantidade de informações possíveis, ou seja, tudo que fizermos
durante a atuação no chamado devemos informar no ARS para que o suporte tenha um melhor entendimento da
situação atual do chamado.
Seguem alguns exemplos de scripts que inserimos no chamado durante o tratamento:

===============================================
MODELO de ANDAMENTO do ARS
===============================================
\\NOC: Ação: CONSULTANDO PROCEDIMENTO.

===============================================
MODELO para utilização DURANTE atendimento do ARS
===============================================
\\NOC: Ação: EXECUTANDO PROCEDIMENTO NOC.
DIRECIONAMENTO DE CHAMADO
========================================
MODELO de REDESIGNAMENTO de Chamado
========================================
Ambiente Afetado..............: (Sistema que está com Falha, exemplo: SIEBEL)
Componente......................: (Serviço ou processo que gerou a degradação/indisponibilidade)
Descrição do Problema......: (Descrever o problema/funcionalidade que gerou a
degradação/indisponibilidade no sistema)
Detalhes da Analise............: (Descrever de forma clara analise realizada durante a investigação
da falha)
Responsável.......................: (Nome do Analista GW que analisou o problema)
Ramal.................................: (Ramal do Analista GW que analisou o problema)
Grupo Redesignado...........: (Nome do Grupo onde o ARS será encaminhado)
Motivo................................: (Deve ser inserido um motivo pelo qual o chamado foi designado, tais como:
1 - Continuação de Atividade em outra equipe;
2 - Análise indica responsabilidade da outra equipe;
3 - Solicitação do cliente;
4 - Necessidade de Análise por outra equipe;
5 - Devolução do chamado após atividade;)
Estes modelos deverão ser utilizados no tratamento de todos os chamados. A não utilização
implicará diretamente na nota do colaborador.
DIRECIONAMENTO DE CHAMADO

========================================
MODELO de RESOLUÇÃO de Chamado
========================================
Ambiente Afetado...........: (Sistema que está com Falha, exemplo: SIEBEL)
Componente..................: (Serviço ou processo que gerou a degradação/indisponibilidade)
Problema........................: (Descrever o problema/funcionalidade que gerou a
degradação/indisponibilidade no sistema, ou problema relatado pelo usuário)
Causa Raiz.....................: (Descrever o problema que causou a falha do tipo: certificado expirado,
problema de hardware, GMUD em Execução/Erro de implantação)
Solução..........................: (Ação tomada para contingenciar/resolver o problema )
BASE DE CONHECIMENTO

Para acessar todos nossos procedimentos temos nossa Base de Conhecimento, a qual pode ser acessada
através do endereço:

http://sharepoint/site/0171/servicedesk/base_conhecimento/default.aspx
Sites de monitoração / pesquisa

Base: http://noc.brasiltelecom.com.br:8080/base.jsp
Remedy: http://asepxweb:8080/midtier_linux/shared/login.jsp
Monitor: http://mon.brasiltelecom.com.br:8080/monitor/ambientes.jsp
Portal Backup: http://portalbackup/
Monitoração: http://mon.brasiltelecom.com.br/
Expediente equipes: http://expedientesuporte:7780/pls/apex/f?p=1010:14:2034054923970503::NO:::
SIS: http://itoc.telemar/operacao/sistema_itoc/Planilhas%20Telemar/OPERACAO_SIS.htm
Farol ARS: http://gsuprd01/farol_chamados/index.php
Portal GMUD: http://portalgmud/
Portal de Arquitetura: http://arquitetura/conteudo_site/Aplicacoes/default.htm
Categorizações: http://10.32.214.139/autoatendimento/agentedesolucao.php
Portal Identidade OI: https://identidadeoi.com.br/senha/index.seam
Portal Interativa: http://interativa/
TMS: http://tms.telemar/tms/Default.aspx
Base de conhecimento: http://sharepoint/site/0171/servicedesk/base_conhecimento/default.aspx
Planilhas Hardware: http://sharepoint/tecnologia/0038/OPERACAO/Hardware/Forms/AllItems.aspx
Disco Virtual: https://ud.globalweb.com.br/index.php/apps/files/
Painel GMUD: http://nocpx01/noc/index.php
Filas Cyber: http://legado.brasiltelecom.com.br:8081/incidentes/paginas/publico/op_dc_serv_cyber.jsf
PBI e PKE http://legado.brasiltelecom.com.br:8082/pke_pbi/
BMC REMEDY USER
APLICAÇÕES
APLICAÇÕES

Clique na Imagem abaixo para acessar as aplicações:

APLICAÇÕES
HARDWARE
HARDWARE

Para tratamento dos chamados utilizamos os procedimentos NOC0105 e NOC0250.

OBS.: Chamados SEV1 e SEV2 com status EM ANDAMENTO geram escalações, desta forma
Devemos dar toda atenção a estes chamados afim de resolvê-los ou contingenciá-los.

Hoje trabalhamos com vários fornecedores como UNITECH, IBM, HP, EMC, FUJITSU entre outros.
A seguir seguem dados relevantes para RONDA e coleta de logs (UNITECH).

Todos chamados da fila HW, devem ser recategorizados conforme abaixo para possibilitar a inserção de
dados relevantes como: chamado fornecedor, GMUD, etc.
HARDWARE
Atividade Recorrente:
INFRA ESTRUTURA
OPERACAO TI
HARDWARE
VERIFICAÇÃO DE HARDWARE
SO (UNIX ou WINDOWS)
LOCALIDADE

Campos adicionais Atividade Recorrente:

HARDWARE
Incidente:
INFRA ESTRUTURA
OPERACAO TI
HARDWARE
FALHA DE HARDWARE
SO (UNIX ou WINDOWS)
LOCALIDADE

Campos adicionais Incidente:

Identificando os LEDs

Existem quatro padrões de identificação para servidores/storages

GREE
N
Normal Operation

BLUE Normal Operation

AMBE
R Fault / Warning Condition

RED Fault / Warning Condition

HARDWARE

Utilizamos algumas planilhas para controle do NOC e visualização da nossa GESTÃO Oi.

http://sharepoint/tecnologia/0038/OPERACAO/Hardware/Forms/AllItems.aspx

 MUDANÇAS – Todas mudanças devem estar cadastradas nesta planilha, conforme abas:
• Aguard GMUD – Todas mudanças com status diferente de EXECUTADA ou CANCELADA.
• Executadas – Todas mudanças com status EXECUTADA ou CANCELADA.
• Padrão de GMUD – Os textos pré definidos para preenchimento dos campos no planejamento

 NÃO RONDA – Todos ARS’s redesignados da fila HW_BSA para outras filas e que devem retornar par nossa
fila.
• Ex.: solicitação de logs, validação, solicitação de janela, etc.
Identificando tipos de máquinas
Servidores

Storages
IBM X-Series

*Operator Panel Operator Painel – Opened View

IBM X-Series
Verificação dos led's no operator panel :

Over Spec- Maquina trabalhando acima da capacidade da fonte de alimentação.

PS1/PS2- Problema na fonte de alimentação na fonte 1 ou 2 (verificar atrás das fontes para ver se estão acesos os
led's AC/DC) se estiverem e um erro falso, resolvendo com atualização de firmware. se um dos dois estiver
apagado verificar se o cabo de força esta bem conectado, se estiver será necessário a troca da fonte.
CPU- Problema no processador.
VRM- problema no regulador de voltagem do processador.
IBM X-Series
CNFG- Erro de configuração. Será necessário verificar log da maquina.

MEM- Problema de memória.

NMI- Possivel problema de Device Driver no S.O. É aconselhável atualizar os device drivers e em seguida
monitorar o equipamento. os drivers mais importantes são:

-Driver da controladora de discos (ex: Server Raid)

-Driver das HBAs Qlogic
-Driver da placa Ethernet

Se o NMI voltar a ser apresentado, é aconselhável ver no event log do Windows o que estava acontecendo no
momento que o erro foi apresentado.

RAID- problema na controladora Server Raid.

BRD- System Board (placa mãe).

FAN- Ventiladores

DASD- Verificar se existe algum disco na maquina com led âmbar (amarelo) aceso, se sim anotar o P/N FRU do
disco (na frente do disco) e ou capacidade do HD (ex: 500Gb- 15K). Abrir chamado técnico informando o Part
Number do disco.
Dell PowerEdge - Series

• Para os servidores DELL existe um LED indicador de

operação normal ou em falha. Caso de LED âmbar
abrir chamado para SO verificar.

Quando há algum componente em falha o display frontal LCD torna-se âmbar e informa o
código do erro. O chamado pode ser direcionado diretamente para o atendimento de
hardware, informando à CAU o erro mencionado no display.
Dell PowerEdge - Series

• Quando for verificado LED âmbar na frente dos servidores Poweredge, podemos verificar as fontes e HDDs para
determinar se há LEDs de Fault e caso haja, abrir chamado de hardware diretamente.

*5,6 => Somente duas (2) Fontes(power supply) - quando LED âmbar aceso, SEVERIDADE = 3
SUN V Series

System Fault LED

Power/OK LED OK-to-Remove LED

Power button Security keyswitch

• Para os servidores DELL existe um LED indicador de

operação normal ou em falha. Caso de LED âmbar abrir
chamado para SO verificar.

*Rear View – Power Supplies

• Quando determinada falha no sistema, verificar as condições das

Fontes. Quando OS Fault em ambar, fonte em falha. Quando AC
Presense em ambar, sem entrada de energia energia.

PS Fault

DC Status

AC Presense
EMC² Celerra Series

Quando houver qualquer LED âmbar na frente do equipamento, abrir chamado de hardware
diretamente.
Hitachi 9980V

• Para o 9980V, quando há Alarm ou Message,

deve ser aberto chamado de hardware diretamente
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE

Informar também nome do operador do NOC

responsável pela abertura do chamado.
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
HARDWARE
GMUD – Gestão de Mudanças
Tipos de Mudança

TIPO DEFINIÇÃO
Mudança pré-aprovada em sistema ou infra-estrutura com risco baixo ou controlado, história de
Padrão sucesso e documentação adequada.
 Há uma sensível redução na alocação de recursos envolvidos no processo.

Risco de Efeito Colateral

Mudança que passa pelo comitê de mudanças regular para sua aprovação.
Programada  Por ser planejada, as áreas de TI podem alocar os recursos e programarem-se para a aprovação e
execução desta mudança
Mudança que não pode aguardar o comitê de mudanças regular.
Urgente  Deve ser utilizada de preferência para correções ou demandas que não podem aguardar o prazo
de mudança programada.
Quando existir um ARS de incidente de severidade 1 ou 2 em andamento, a mudança está
Emergencial previamente aprovada.
 As ações são registradas no ticket de incidente (ARS Helpdesk) e a ocorrência como correção.

71
Categorias de Risco

• Identifica a criticidade do sistema para o negócio e o impacto da mudança no

ambiente.

Sistemas Críticos

Categoria 2 Categoria 1
Não Impacta Impacta
Criticidade

Demais Sistemas
Demais Sistemas

Categoria 4 Categoria 3
Não Impacta Impacta

Risco de indisponibilizar ou degradar o ambiente durante a

mudança
SLA
Sistemas Críticos
• Mudanças Programadas – Categoria de Risco 1:
Categoria 2 Categoria 1
• Mudanças de maior criticidade e visibilidade. Não Impacta Impacta

Criticidade
• Afetam diretamente o negócio da empresa.
• Indisponibilizam ou degradam Sistemas Críticos. Demais Sistemas
Demais Sistemas

Categoria 4 Categoria 3
Não Impacta Impacta

Risco de indisponibilizar ou degradar o ambiente

durante a mudança

• Mudanças Programadas – Categoria de Risco 2, 3 e 4:

Sistemas Críticos
• Mudanças que não afetam diretamente o negócio
• Podem afetar aplicações que suportam o dia a dia Categoria 2 Categoria 1
de diversas áreas. Não Impacta Impacta

Criticidade
Demais Sistemas
Demais Sistemas

Categoria 4 Categoria 3
Não Impacta Impacta
Aprovação Limite para submissão
Risco de indisponibilizar ou degradar o ambiente
durante a mudança
CAB Mínimo de 03 dias úteis
antes do CAB
SLA

Sistemas Críticos

• Mudanças Urgentes – Todas as Categoria de Risco: Categoria 2 Categoria 1

Não Impacta Impacta

Criticidade
• Envolvem sistemas críticos e/ou não-críticos.
• Não podem aguardar o prazo de submissão de uma Mudança Programada. Demais Sistemas
Demais Sistemas

Categoria 4 Categoria 3
Não Impacta Impacta

Risco de indisponibilizar ou degradar o ambiente

durante a mudança

Aprovação Limite para submissão

Ressalva Mínimo de 02h úteis* antes

da sua execução.
Comitê Presencial de Mudanças

Consiste em uma reunião presencial para aprovação das mudanças com status “aprovada”.

 O CAB é realizado em 1 reunião semanal, todas as terças:

- Mudanças previstas para execução entre 18:00 de 4af e 17:59 de 4af;

Voltar para o fluxo

Voltar para a tela

Resumo Mudança HOT
– Na guia REGISTRO inserimos:
• Dados do responsável;
• Quando será feito.
– Clicar em Salvar;
– Escolher a mudança padrão;
– Alterar o IC (Excluir o atual e inserir o novo);
– Clicar em Avançar;
– Mudança avança direto para guia IMPLANTAÇÃO onde acontecerá a execução da mesma;
– Assim que a última atividade é executada a mudança avança para CONCLUSÃO onde devemos avaliar o
objetivo podendo utilizar se necessário os campos:
• Motivo e Justificativa;
Resumo Mudança HOT

Mudanças Padrão do NOC:

Mudanças Padrão da Implantação Utilizadas pelo NOC:
[DC_OP_HW_BSA] TROCA DE BATERIA DE FRAME
[CYBER] ATUALIZAÇÃO SCRIPT BD – Equipe SQL
[DC_OP_HW_BSA] TROCA DE DISCO STORAGE SHARK FRAME
[CYBER] DEPLOY DE APLICAÇÃO – Equipe Windows
[DC_OP_HW_BSA] TROCA HOT DE FONTE DE ENERGIA C/REDUNDANCIA
[DC_OP_HW_BSA] TROCA HOT HD/UNIDADE DE DISCO-SERVIDOR
Resumo Mudança PROGRAMADA
– Na guia REGISTRO inserimos:
• Dados do responsável;
• Quando será feito (06 dias úteis à frente, salvo exceções).
– Clicar em Salvar;
– Preenchemos:
• O que será feito;
• Origem;
• Meio de implantação;
– Inserir o IC;
– Inserir Anexos (Monitoração e demais necessários);
– Clicar em Salvar e Avançar para a guia PLANEJAMENTO, devemos verificar áreas impactadas na guia
REGISTRO em IC, atenção para as colunas:
• Tipo IC, IC Pai, Nome IC e Status.
– Verificar IC no CMDB, aba ARS (mudanças anteriores) afim de encontrar executores, aprovadores e plano
técnico;
Resumo Mudança PROGRAMADA
– Concluir plano Técnico;
– Concluir plano Backout (Dica: Toda atividade após nossa fila deve ter uma atividade de Backout);
– Inserir Impacto;
– Salvar e Avançar para APROVAÇÃO onde devemos seguir os SLA’s:
• Aprovações técnicas para categoria de risco 1: 6 dias corridos (levando em consideração as datas do
CAB);
• Aprovações técnicas para categorias de risco 2, 3 e 4: 3 dias úteis;
• Aprovações Área Impactada: Até 02 horas úteis antes do início da mudança;
• Aprovações de Cliente: Até as 18:00h da data do início da mudança;
– Avançar para IMPLANTAÇÃO onde devemos:
• Acompanhar todas as atividades (Sempre que algum executor atrasar o início ou ultrapassar o fim em 15
minutos devemos acioná-los);
• Iniciar Backout caso necessário;
– Assim que a última atividade é executada a mudança avança para CONCLUSÃO onde devemos avaliar o
objetivo podendo utilizar se necessário os campos:
• Motivo e Justificativa;
Resumo Mudança URGENTE
– Na guia REGISTRO inserimos:
• Dados do responsável;
• Quando será feito (06 dias úteis à frente, salvo exceções).
– Clicar em Salvar;
– Preenchemos:
• O que será feito;
• Origem;
• Meio de implantação;
– Inserir o IC;
– Inserir Anexos (Monitoração e demais necessários);
– Clicar em Salvar e Avançar para a guia APROVAÇÃO, onde devemos obter o OK do GESTOR N5 em até 04 horas
após ter avançado para aprovação.
– Após aprovação do N5 mudança retorna para a guia PLANEJAMENTO, devemos verificar áreas impactadas na guia
REGISTRO em IC, atenção para as colunas:
• Tipo IC, IC Pai, Nome IC e Status.
– Verificar IC no CMDB, aba ARS (mudanças anteriores) afim de encontrar executores, aprovadores e plano técnico;
Resumo Mudança URGENTE

– Concluir plano Técnico;

– Concluir plano Backout (Dica: Toda atividade após nossa fila deve ter uma atividade de Backout);
– Inserir Impacto;
– Salvar e Avançar para APROVAÇÃO onde devemos seguir os SLA’s:
• Aprovações técnicas para todas categorias: Até 02 horas úteis antes do início da mudança;
• Aprovações Área Impactada: Até 02 horas úteis antes do início da mudança;
• Aprovações de Cliente: Até o horário do início da mudança;

– Avançar para IMPLANTAÇÃO onde devemos:

• Acompanhar todas as atividades (Sempre que algum executor atrasar o início ou ultrapassar o fim em 15 minutos
devemos acioná-los);
• Iniciar Backout caso necessário;

– Assim que a última atividade é executada a mudança avança para CONCLUSÃO onde devemos avaliar o
objetivo podendo utilizar se necessário os campos:
• Motivo e Justificativa;
GMUD
GLOSSÁRIO
Área impactada – Área de TI que tem ação prevista em função dos Ics afetados pela mudança.

ARS - Action Request System - Ferramenta utilizada pelo processo de Gerir Mudanças.

CAB - Change Advisory Board - Comitê presencial para aprovação de mudanças programadas.

CMDB - Configuration Management DataBase - Base de dados para armazenamento de informações sobre componentes de TI (hardware ou software), seus relacionamentos,
configurações e documentações, promovendo a normalização, padronização e disponibilização destas informações para os aplicativos ligados ao gerenciamento de TI.

ECAB - Emergency Change Advisory Board - Comitê via áudio para aprovação de mudanças Urgentes.

EM – Executor da Mudança – Responsável por implantar a mudança, executando as atividades técnicas planejadas.

GMUD – Gerência de Mudanças – Equipe responsável por gerir o processo.

IC - Item de Configuração - Componente de TI físico ou lógico gerenciado pelo seu impacto operacional.

IO – Information Owner - Representante da diretoria N1 (nos diretores ligados diretamente ao Presidente) ou N2 (nos diretores ligados ao COO) nos processos de mudanças e
releases.
ITOC - Information Technology Operation Center – Área responsável por monitorar e acompanhar mudanças críticas selecionadas por GMUD, além de acionar executores,
líderes e gestores quando necessário.
LM – Líder da Mudança – Responsável por registrar e planejar a mudança e garantindo sua execução dentro dos critérios de Aderência à SOX, disponibilidade do ambiente e
entrega.
PO - Production Owner - Responsável pela Produção

SO - System Owner - Responsável pelo Sistema

STI - Ferramenta de workflow e repositório de artafatos utilizada pelo processo de Gerir Desenvolvimento.
 Antonio Júnior
Coordenador de Operações
(61)3305-5550 | 61)98421-9484
antonio.junior@globalweb.com.br