Prezado Luciano, Interessante a tua colocação, Tenho o seguinte ponto de vista: A falha (queima do fusível) ocorreu e a solução de contorno para colocar os clientes no ar (1a. prioridade) é até mesmo tirar o fusível de uma régua ou estabilizador não crítico e restabelecer a rede imediatamente. Como solução seria a revisão do projeto de alimentação do servidor para que se tenha ou outro nobreak de reserva, pronto para assumir ou até mesmo um estabilizador para permitir uma manutenção do Nobreak mantendo a rede no ar. Até memos porque a pane de fusível pode ocorrer em horário que não tem comércio aberto e a rede não poderia esperar. Cabe ainda uma análise de risco mais acurada para verificação de outros "pontos críticos" para manutenção do SLA. Na minha instalação (rsrsr - Na realidade é do cliente) sempre precedo os SLAs com uma anáise de riscos (todos) para tratamento dos riscos e depois fechamos o SLA. Espero ter ajudado. Estas trocas de experiências são uma das melhores atrações de nossa lista. Ainda no teu argumento, manter o ----- Original Message ----- From: Luciano Silveira To: [email protected] Sent: Wednesday, June 17, 2009 10:54 AM Subject: [itsm_br] Re: Ainda incidente?
E aí Felipe, quando trabalhava ao seu lado sempre gostei deste seu perfil de grande questionador. Têm horas que trabalhamos no automático e acabamos esquecendo de pensar/perguntar se aquela forma de fazer é a melhor ou mais correta. Acredito que as respostas dadas até o momento já ajudam na reflexão da questão, então gostaria de aproveitar para colocar um outro caso que ocorreu: Certo dia durante o expediente o no-break "caiu" e com ele vários servidores ficaram inoperantes, causando parada de diversos serviços (incidentes). O Diretor, também grande conhecedor de ITIL, questionando a equipe de suporte sobre o que havia ocorrido recebeu a informação que houve queima do fusível, como não havia outro de reserva no local (grande falha por sinal) já estavam providenciando aquisição de outro no comércio para restabelecerem os serviços. Porém o Diretor disse para colocar o no-break em by-pass para que os serviços voltassem em operação o quanto antes (haviam muitos empregados parados) e posteriormente na janela de manutenção realizarem a troca (além de registrar o problema para investigação da capacidade do sistema eletrico). No final acabou-se trocando o fusível bem naquele instante(acho que conseguiram utilizar o de outro equipamento que estava danificado). A princípio discordei do Diretor, já que utilizando o by-pass estaríamos colocando em risco a proteção elétrica dos servidores e com esta solução poderíamos causar um incidente ainda mais grave. Os argumentos dele eram que o incidente teria que ser solucionado na menor janela de tempo possível. Até que ponto é correto assumir um risco para atender um acordo de nível de serviço? Luciano Silveira [email protected] MSP - Microsoft Student Partner MCSA, MCTS, MCP Google profile: http://www.google.com/profiles/lucianojs 48 3365-0930 (NET) | 48 8465-0930 (OI) | 34 3221-8550 (Fixo Voip - Atendo em Floripa) Florianópolis - SC --- In [email protected], "Sergio Rubinato Filho" <rubin...@...> wrote: > > Caro Felipe Rezende, > > > > Depois de vários comentário "interessantes" derivados de sua pergunta e > refletindo sobre o seu caso, minha recomendação inicial é: > > > > O "X" da questão está na satisfação e comprometimento do usuário em função > ao do serviço prestado - e conseqüentemente a forma com que a TI prove > suporte aos serviços que oferece. > > > > Permita transmitir o meu entendimento e idéias entorno do assunto de forma > prática: o usuário, sentindo alguma degradação no serviço (sempre em função > do que fora combinado - ANS), está no direito de pedir auxilio e negociar o > momento mais conveniente para que uma solução (de contorno ou definitiva) > seja aplicada. Daí temos a questão da gestão do serviço que TI presta neste > momento, que na minha opinião está buscando sair da sua condição de > subdesenvolvimento - no que toca os métodos de gestão - por meio de aplicar > as práticas correntes e supostamente mais modernas. Mais isso é um outro > assunto, que alias dá pano pra manga. > > > > Voltando a vaca fria: como proceder com o gerenciamento deste registro de > incidentes? (ocorrência, trouble ticket, TT, ticket, chame-se como quiser > desde que esteja claro o que se pretende com o registro desta informação). > > > > Em qualquer relação (sobre tudo numa prestação de serviços) todos os > elementos do sistema tem um papel a ser desempenhado que deve ser medido, > possibilitando a entrega do serviço da forma mais eficiente, controlada > (tirando a máxima utilidade do sistema como um todo). Com isso assumimos que > o usuário também deve ser medido quando da interação com o processo, sempre > na forma de esforço e disponibilidade da parte dele (o que por princípio não > é linear e sim transacional). Do lado da TI a forma com que medimos a > produtividade e efetividade do suporte aos serviços de TI por convenção > assume períodos lineares, que na minha avaliação é uma das causas raiz do > problema. Explico: não podemos responsabilizar a TI por algo que está fora > do seu controle (reforço o exemplo da medicina: se um médico pede um exame > ou prescreve um medicamento no sentido de tratar a condição é > responsabilidade do paciente seguir as recomendações dentro dos prazos > convenientes e que não ofereçam risco a sua saúde). Por isso sustento a > prática de medição da nossa proficiência TÉCNICA por esforço (horas de fato > trabalhadas) que alocamos para restabelecer o serviço e, separadamente mas > no contexto de prestação de serviços, nossa proficiência de GERENCIAMENTO > (tempo total linear que lançamos não das nossas habilidades interpessoais, > confiabilidade, integridade, etc para auxiliar o nosso usuário). Quais as > vantagens aqui são: 1) atribuir claramente qual recurso lançaremos não em > cada etapa da prestação do serviço, 2) clareza e transparência facilitando a > contabilização dos recursos utilizados pelo sistema, 3) assertividade na > alocação de recursos, 4) melhor qualidade percebida na prestação do serviço, > 5) facilidade de se apresentar o resultado do trabalho, 6) clareza na > prestação de contas e recebimentos por conta dos serviços prestados. > > > > Além de muita comunicação e entendimento mutuo (inerente de qualquer > prestação de serviço de qualidade), umas das ferramentas que você pode > lançar mão é e justamente o ITIL no que diz respeito ao Gerenciamento de > Incidentes. Você pode usar os STATUS do registro (aberto, em andamento, > diagnosticado, solucionado, corrigido, restabelecido, encerrado, etc - > atenção para não se pegar na semântica) como forma de registrar a cadência > linear do registro e as interações com o usuário (como se fosse o prontuário > do atendimento) e SUB-RESGISTROS de Incidentes (também conhecidos como > pai-filho, incidentes hierárquicos, incidentes relacionados, etc) para > registras o esforço necessário para resolvermos a situação (comparando com > pedidos de exames, receituários, etc). Com isso o seu registro principal de > incidentes segue com o uso linear dos status, apresentando ao usuário e > buscando registrar o entendimento e comprometimento dele por meio de: > detalhar o que está acontecendo, apresentar solução recomendada (e os > porquês), condições e prazos para evoluirmos para a próxima etapa do suporte > e os acordos relativos em função do acordo de nível de serviço ao qual > estamos seguindo (revisite na medicina o processo de diagnostico e > tratamento de doenças que você achará muitas respostas). > > > > Posto isso, creio que atacamos o cerne da questão: organização do trabalho > passando principalmente pela definição clara de papeis, responsabilidades, > expectativas, forma de acompanhamento, parâmetros de medição de qualidade e > método de apresentação dos resultados. > > > > Espero que com esta pequena mensagem tenha conseguido transmitir que para a > correção e restabelecimento do serviço como combinado não depende somente da > TI, portanto não podemos somente medir o desempenho de um todos componentes > do sistema e esperar que tenhamos uma visão clara da qualidade do serviço > como um tudo - o que é geralmente a regra em TI). > > > > Desejo muita sorte e paciência para que você consigo desatar este nó. > > > > Cordiais, > > > > Sergio Rubinato Filho > > > > From: [email protected] [mailto:[email protected]] On Behalf Of > Pablo Emanuel > Sent: Monday, June 08, 2009 8:30 AM > To: [email protected] > Subject: Re: [itsm_br] Ainda incidente? > > > > > > > > > Carlos, > > > > pelas definições do ITIL, um incidente nunca é "promovido" para problema ou > mudança. Um incidente pode estar associado a um problema (ou até mesmo a > mais de um) e, se não tivermos nenhuma solução de contorno, a solução do > incidente pode até estar vinculada à resolução do problema (que, muito > provavelmente, será uma mudança), mas nunca um vira o outro. A pergunta > original pode ser generalizada para "o que fazer quando não existe > workaround e a solução de um incidente depende de uma mudança?" > > > > Não me atrevo a dizer que eu tenha a solução definitiva para esta questão, > mas o procedimento que eu tenho seguido nestes casos é negociar com a(s) > área(s) afetada(s) - envolvendo o ponto focal da área no processo de change > management (normalmente o gerente da área) - o prazo necessário para a > execução da mudança (de acordo com os procedimentos de change management), e > alterar o status do incidente para um status especificamente criado para > este fim até a execução da mudança. Desta forma, podemos identificar este > cenário nos relatórios. Se simplesmente deixássemos o íncidente como > "Aberto", ele se misturaria com os incidentes em que não houve acordo com as > áreas; se simplesmente encerrássemos o incidente, ele se misturaria com os > casos em que a solução de contorno foi efetiva. > > > > Abraço, > > > > Pablo Emanuel > > 2009/6/7 Carlos Roberto Santos Almeida <carlos.alme...@...> > > > > Boa noite. > > > > Felipe, > > > > > > Ao me deparar com esse tipo de situação, tento sempre ponderar o seguinte: > > > > O objetivo do processo de Incident Management, segundo o book, é devolver o > serviço normal no menor espaço de tempo possível. Sendo assim, Tickets cujo > o atendimento pode ser "postergado" descaracteriza essa máxima, > descaracterizando assim o ticket que poderá ser "promovido" de incident para > problem (caso a causa raiz ainda não seja conhecida/documentada) ou ainda > change (sendo agregado à janela padrão de mundaças). > > > > O book prevê que o incident pode ser reconhecido como algo que afeta > parcialmente um determinado serviço. Pórem, se o impacto é tão parcial que a > resolução possa esperar a próxima janela de mudanças, este ticket original > deve ser fechado com as informações das tratativas executadas e com a > solicitação do usuário de aguardar a próxima janela de mudança. > > > > Outro ponto de análise para se tirar da situação proposta é que, hoje em dia > com a infra atual, os serviços estão todos agregados em servidores. Sendo > assim, a solução para incidents que afetam (totalmente ou parcialmente) um > determinado serviço, dificilmente estarão nos clients e possivelmente > estarão afetando mais que um usuário no ambiente. Dessa forma, mais uma vez > migraremos o ticket para a disciplina de problem e em seguida change. > > > > Lógico que toda essa colocação é do ambito teórico e que, no âmbito prático, > o que vale é o acordo prévio com o cliente sobre a tratativa que será dada > para esta situações. > > > > > > Espero ter contribuido para a discussão. > > > > -- > Att.: > > > > Carlos Roberto Santos Almeida > Mobile +55 11-8279-7704 > carlos.alme...@... > "http://www.linkedin.com/in/carlosroberto"; > > 2009/6/3 Felipe Rezende Sales Barbosa <felipe...@...> > > > > Caros, > > > > Gostaria de uma ajuda de vocês. > > Sabendo que um incidente é uma interrupção total ou parcial ou ainda uma > queda de qualidade de um determinado serviço de TI, tenho a seguinte dúvida: > > > > Considere o cenário em que ocorreu um incidente do tipo queda de qualidade > em um determinado serviço de TI e a solução para o mesmo exige uma parada > momentânea do serviço. Porém, o usuário que abriu o incidente não aceita > essa parada e prefere ficar com o serviço com baixa qualidade, tendo > portanto que esperar pela próxima janela de manutenção do serviço para > resolver a questão. > > A dúvida é a seguinte: Até a próxima janela de manutenção esse incidente > fica aberto? Sendo sim a resposta, essa ação impacta no indicador de tempo > de resolução de incidentes. > > > > Aguardo a participação de todos. > > > > Atenciosamente, > > > -- > Felipe Rezende Sales Barbosa > > Consultor > > Invit Information Services - Uberlândia > (34)9929-1109 > ------------------------------------------------------------------------------ Esta mensagem foi verificada pelo E-mail Protegido Terra. Atualizado em 17/06/2009
