Escolar Documentos
Profissional Documentos
Cultura Documentos
002 - ITIL - V3 - Design de Serviços PDF
002 - ITIL - V3 - Design de Serviços PDF
002 - ITIL - V3 - Design de Serviços PDF
Design de Servios
Estratgia de Servio
Design de Servios
Transio de Servio
Operao de Servio
Melhoria de Servio Continuada.
Peter Fanning
Atuando Executivo
Design de Servios amplia nossos horizontes e nos ajuda a ver uma tela maior,
mais coeso de TI Servio de Gesto de.
Sharon Taylor
Mentores
Tony Jenkins
Para desenvolver ITIL v3 para refletir as melhores prticas actuais e produzir publicaes de
valor duradouro, OGC amplas consultas com diferentes das partes interessadass em todo o
mundo em todas as fases do processo. OGC tambm gostaria de agradecer s seguintes
pessoas e suas organizaes, por suas contribuies orientao refrescante ITIL a:
Revisores
Justin Alford, Esprito Consultoria; Rajeev Andharia, Sun; Antonio Arvalo, SATEC; Kamal Kishore Arora, Infosys
Technologies; G. Arvinda; Martin Andenmatten, Independente; Brian Barber, Serra de Sistemas; Pierre Bernard, Pink
Elephant, Jason Besant; Twane Boettinger, primeiro cdn; Juergen Breithaupt, Infora; Javier Marques Cabrero, Deloitte;
Neil Chadwick, David Colburn, The Creek; Bob Costa, do Exrcito dos EUA; Wills Damasio, Quint Wellington Redwood;
Catalin Danila, GlaxoSmithKline, SRL Romnia; Juergen Dierlamm, Rechtsanwaitkanzlei Dierlamm; Peter Doherty, CA;
Thomas Dressler, EDV-Beratung; Fouad El Sioufy, TUV Rheinland Secure IT GmbH; Jaime Eduardo Facioli, Kalendae IT
Service Management; Juergen Feldges, DNV; Prasad Gadgil, Satyam Computer Services Ltd; Kingshuk Ghosh, HP;
Sandeep Gondhalekar, Quint Wellington Redwood, John Graham, Educad; Juergen Gross, Independente; Ib Guldager,
CSC; Tsuyoshi Hamada, HP; Eero Heikkonen, Efecte; Christoph Herwig, Accenture; Thomas Hess, pluralis AG; Maria
Hondros, da Microsoft, Thomas Jahn; Chris Jones, Ariston Consultoria Estratgica; Daniel Keller, SUIT Sua; Brian Kerr,
Axios Systems, Robert Kuhlig, mITSM; Hendrikje Kuhne, KTP-organisationsterberatung; Dirk Koetting, EDV - Konzepte;
Madhav Lakshminarayanan; Jane Link, Acerit Limited; Ernst Guido Leidheuser , Telelogic; Ryan Lloyd, MKS; Eduardo
Magalhes, Paulo Martini, HP; Raimund Martl, HP, Ruth Mason, Kcit; Tan Heng Meng, Starhub; Rohit Nand, Infosys,
Edward Newman; Glen Notman, Pink Elephant, Tuomas Nurmela, TietoEnator Processamento e Rede Oy; Benjamin
Orazem, SRC.SI; Fadi Otoun; Gerard Persoon, E.Novation; Neil Pinkerton, Laughingtree; Christian Probst, Quint
Wellington Redwood; Rajwardhan Purohit; Rajesh Radhakrishnan, IBM; Zahra Rahemtulla, BearingPoint, Arvind Raman,
Infosys; Brian Rowlatt, a LogicaCMG; Sutirtha Roy Chowdhury, Serra de Sistemas; Parmjit Sangha, Alexander Sapronov,
HP; Frances Scarff, OGC; Alan Shepherd, Deutsche Bank AG, Renato Maia Silva; Moira Stepchuk, Pultorak; Russel
Steyn, Foster-Melliar; Stephen Straker, Fujitsu, rico Sylva, Microsoft; Jos Tamo, QualiTI7; Brett Tilney; Michael
Tomkinson, BT; Mathias Traugott, Swisscom, Ken Turbitt, BMC Software; Wiley Vasquez, BMC Software, Brian
Verbrugge, RBC; Ettiene Vermeulen, Datacentrix; Joachim von Caron, Lufthansa Systems; Andreas Weinberger,
DekaBank; Sven Werner, Unilog Avinci GmbH; Ken Williamson, Tyler Pedra Consultoria; Ann Inverno, EMC, Theresa
Wright, Computacenter Servios; Geoffrey Wyeth, Independente; Rob Young, Fox IT, Michael Zimmermann , NETCONS
Todos organizaos que usam a TI vai depender de TI para ser bem sucedido.
Se os processos de TI e servios de TI so implementados, geridos e apoiados
de forma adequada, o negcio ser mais bem sucedido, sofrem menos
perturbaes e perda de horas produtivas, reduzir custars, aumentar a receita,
melhorar as relaes pblicas e alcanar o seu objetivo de negcios.
A partir desta perspectiva, Design de Servios pode ser visto como a recolha de
necessidades de servios e mape-los s necessidades de servios integrados
e de criar o projeto especificaos para o servio ativos necessrios para
prestao de servios. Uma caracterstica particular dessa abordagem uma
forte nfase na reutilizao durante o projeto.
Servios
Projeto de sistemas de gerenciamento de servios e ferramentas,
especialmente o Portflio de Servios
Tecnologia arquiteturas e sistema de gestos
Processoes
Mtodos de medio e mtricos.
Captulo 4 explica o processo de ponta a ponta das reas chave para o sucesso
Design de Servios. Estes processos so utilizados por todas as outras fases do
Servio Ciclo de VidaE outros processos so levados em conta por Design de
Servio. No entanto, aqui que o Gerenciamento de Catlogo de Servio,
Gerenciamento de Nvel de Servio,Gerenciamento da
Capacidade,Gerenciamento de Disponibilidade,Gerenciamento da Continuidade
do Servio,Gesto de Segurana da Informao e Gesto de Fornecedores so
abordados em detalhes.
O Core ITIL composto por cinco publicaes (Figura 1.3). Cada uma delas
fornece a orientao necessria para uma abordagem integrada, tal como
exigido pela ISO / IEC 20000 padro especificao:
Estratgia de Servio
Design de Servios
Transio de Servio
Operao de Servio
Melhoria de Servio Continuada.
Embora esta publicao pode ser lido de forma isolada, recomenda-se que seja
utilizada em conjunto com a outra ITIL publicaes. As orientaes do ITIL
publicaes aplicvel genericamente. burocrtica nem pesado se for
utilizado de forma sensata e no pleno reconhecimento das necessidades do
negcio da organizao. Design de Servios importante para o palco para
entregar servios de forma eficaz para o negcio e atender a demanda de
crescimento e mudana. Enhancement tipicamente superior em custar e
recursos do que desenvolvimento. Considerao importante deve ser dado a
projetar para a facilidade e economia de apoio ao longo de todo ciclo de vida,
Mas, mais importante ainda, no possvel eliminar completamente re-
engenharia um servio de uma vez em produo. possvel chegar perto, mas
vai ser impossvel voltar a um projeto uma vez que algo est sendo executado.
Reequipamento do projeto difcil e caro e nunca alcana o que poderia ter sido
alcanado se projetado
1,4 Uso
Esta publicao relevante para qualquer pessoa envolvida na concepo,
implementao ou suporte de servios de TI. Ela ter relevncia para o arquiteto
de TI, gerentes de TI e profissionais de todos os nveis. Todas as publicaes do
ITIL Servio de Gesto de Biblioteca ncleo precisa ser lido para apreciar e
entender o ciclo de vida total dos servios e do IT Service Management.
2.3.1 Funes
2.3.2 Processos
Uma abordagem holstica deve ser adotada por todos os aspectos de servios
de design e reas para garantir a consistncia e integrao em todas as
atividades e processos atravs da tecnologia de TI inteira, fornecendo fim-a-fim
funcionalidade de negcios relacionados e qualidade.
2.4.2 mbito
Muitas vezes, o projeto de um grande servio novo ou alterado vai exigir que o
projeto mudars so considerados, e muitas vezes afectam ou que so afectadas
por todos os outros quatro fases do Servio Ciclo de Vida. essencial, portanto,
que os sistemas de TI e servios so concebidos, planejada, implementada e
gerida de forma adequada para o negcio como um todo. A exigncia, ento
fornecer servios de TI que:
O ISG vai incluir discusses sobre todos os aspectos do negcio que envolvem
servios de TI, bem como proposta ou possvel mudar num estratgico nvel.
Assuntos para o ISG para discutir podem incluir:
Uma vez que as informaes exactas tenha sido obtido com o que necessrio
e assinado, no que diz respeito s necessidades modificadas do negcio, O
plano para a prestao de um servio para atender a necessidade concordou
pode ser desenvolvida.
A maneira mais eficaz de gerenciar todos os aspectos dos servios por meio de
sua ciclo de vida usando apropriada sistema de gestos e ferramentas para
apoiar e automatizar processos eficientes. O Portflio de Servios o sistema
de gesto mais crtico usado para apoiar todos os processos e descreve um
provedor do servios em termos de valor de negcio. Ele articula as
necessidades do negcio ea resposta do provedor para essas necessidades.
Por definio, termos de valor de negcios correspondem aos termos de
mercado, fornecendo um meio para comparar a competitividade servio atravs
de prestadores alternativos. Ao agir como a base de uma deciso-quadro, um
Portflio de Servios ou esclarece ou ajuda a esclarecer o seguinte estratgico
perguntas:
Uma vez que um estratgico deciso de fretar um servio feita, esta a fase
do ciclo de vida de servios ao Design de Servios comea arquitetar o servio,
que acabar por se tornar parte do Catlogo de Servios. O Portflio de
Servios devem conter informaes relativas a todos os servios e seu status
atual no organizao. As opes de estado na Carteira de servio deve incluir:
Nome do servio
Descrio do servio
Servio estado
Servio classificao e criticidade
Aplicaos usado
Dados e / ou esquema de dados utilizados
Processo de negcioes suportada
Os proprietrios do negcio
Negcio usurios
TI proprietrios
Garantia de servio referncias SLA nvel, e SLR
Servios de apoios
Apoiar recursos
Dependente servios
Apoio Olas, contratos e acordos
Servio custars
Taxas de servio (se aplicvel)
As receitas de servios (se aplicvel)
Servio mtricos.
Assim, o sistema pode ser, por exemplo, uma organizao de todo, uma funo
de negcios, ou uma linha de produto de um sistema de informao. Cada um
destes sistemas ter uma "arquitectura", tal como definido anteriormente,
constitudo pelo componentes do sistema, as relaes entre eles (como
interfaces de controle e intercmbio de dados), as relaes entre o sistema eo
seu ambiente (polticas, organizacionais, tecnolgicos, etc) e os princpios de
design que informar, orientar e restringir a sua estrutura e operao, Bem como
o seu futuro desenvolvimento.
Arquiteturas de tecnologia
Arquitecturas de gesto
Tal arquitetura pode ser usado para projetar e implementar solues de gesto
eficiente, eficaz e integrada, que esto alinhados com os requisitos de negcio
da organizao e seus gerentes de negcios. Esta arquitetura de gesto pode
ser aplicada dentro de uma organizao:
Esta seo fornece uma introduo geral ao processar teoria e prtica, Que a
base para o projeto de ITIL os processos que so utilizados no Servio Ciclo de
Vida. Um processo de modelo possibilita a compreenso e ajuda a articular as
caractersticas distintivas de um processo.
Processos, uma vez definido, devem ser documentados e controlados. Uma vez
sob controlo, podem ser repetidos e tornar controlvel. Graus de controlo sobre
os processos podem ser definidos, e em seguida de medio do processo e
mtricos podem ser construdos em que o processo para controlar e melhorar o
processo, tal como ilustrado na Figura 3.11.
Todas estas reas devem ser includas no projeto de qualquer processo. Estas
novas publicaes ITIL ter sido escrito em torno de "conjuntos de processos"
que refletem as etapas do ciclo de vida de um servio. O Design de Servios
conjunto de processos detalhados nesta publicao abrange os processos,
principalmente com relao a todos os aspectos do projeto.
Trabalhar com processos definidos tem sido a base do ITIL desde o seu incio.
Ao definir o que o organizao'S so actividades que so necessrias entradas
e sadas que ir resultar do processo, possvel trabalhar de modo mais
eficiente e eficaz. Medio e direco das actividades aumenta este eficcia.
Finalmente, atravs da adio de normas para o processo, possvel adicionar
qualidade medidas para a sada.
As necessidades do negcio
O estratgia para ser adoptada para a aquisio e desenvolvimento ou da
soluo de
Os prazos envolvidos
O recursos necessrio, levando-se em considerao instalaes, Infra-
estrutura de TI e as habilidades certas de pessoal a fim de garantir a
entrega servio atende s necessidades do cliente
O desenvolvimento do servio e dos seus componentes constituintes,
incluindo a administrao e de outros operacional mecanismos, tais como
a medio, monitoramento e elaborao de relatrios
Servio e planos de teste de componentes.
Gesto do projecto cuidadoso ter de ser usado para assegurar que o conflito
evitado e que os componentes compatveis so desenvolvidos a partir das vrias
actividades de desenvolvimento diferentes
Isto significa que os designers nem sempre so "livres" para criar a soluo mais
adequada para o negcio, Uma vez que no cai dentro das restries impostas,
conforme ilustrado na Figura 3.13. A limitao mais bvia o financeiro. Pode
haver insuficiente oramento disponvel para a soluo mais adequada,
portanto, uma alternativa mais barata servio teria que ser identificadas e
acordadas com o negcio. O designer s pode fornecer a soluo que se
encaixa dentro de todas as limitaes atualmente conhecidos, ou ento tentar
levantar ou renegociao de alguns dos constrangimentos - por exemplo,
atravs da obteno de um oramento maior. Na Figura 3.13, no s ser mais
do oramento devem ser obtidas para implementar a soluo desejada, mas
tambm por no-conformidade com algumas das normas e regulamentos
pertinentes. Portanto, neste caso uma alternativa, a soluo mais barata
compatvel seria provavelmente necessrio.
Estratgia de Descrio
entrega
Parceria ou Acordos formais entre duas ou mais organizaes de trabalhar juntos para
multi-sourcing projetar, desenvolver, transio, Manter, operar e / ou apoio De servios de
TI(S). O foco aqui tende a ser em estratgico parcerias que utilizar o
conhecimento crtico ou oportunidades de mercado.
Um banco de tamanho mdio se fundiu com outro banco que tinha um portflio
de produtos complementares. Por isso a integrao de aplicaos era simples.
No entanto, os dois bancos sentiram que a consolidao das operaes seria
benfico, mas no conseguiu alavancar o economias de escala a um nvel
suficiente. Terceirizao tambm foi uma opo, mas sim os dois bancos
escolhemos fazer parceria com uma empresa terceirizada. Os bancos forneceu
o conhecimento especfico do banco para fazer a sua De servios de TIa
organizao de um centro de dados atraentes para os bancos menores. O
parceiro de outsourcing, desde a experincia e tecnologia necessria nova
clientes beneficiar das economias de escala.
O desenvolvimento iterativo implica que o ciclo de vida vai ser percorrido mais
de uma vez, por design. Tcnicas como a prototipagem so usados para obter
uma melhor compreenso dos requisitos (por meio de testes, gesto e funcional
operacional atividades e atravs da comunicao com usurios).
Mtodos que incorporem RAD iterao e entrega incremental pode ser usado
para reduzir o desenvolvimento e os riscos de implementao. O real projetos
pode no ser necessariamente mais fcil de gerir, mas eles podem facilitar a
implementao e aceitao. Eles oferecem mais opes de contingncia e
permitir aos desenvolvedores a lidar com a mudana de requisitos de negcio e
das condies ambientais. Eles tambm fornecem ambos os marcos e pontos
de deciso para fins de controle do projeto. Estes mtodos podem
adicionalmente ser utilizadas para:
'Aptido para fins comerciais ", como o critrio para aceitao de entregas
Representao de todas as partes que podem afetar os requisitos de
aplicao em todo o desenvolvimento processo
Usurio comprometimento 15% durante todo o projeto 100% ao longo do projeto para
de recursos patrocinador do projeto, 30%
para os outros selecionados
Pacotes e prototipagem
Definio da estrutura de ponderao avaliao matrizes
Iterao na seleo de pacotes.
Disponvel off-the-shelf
Pode ser configurado. Estimar o esforo para executar a configurao.
Isso s precisa ser feito uma vez e ser preservado ao longo atualizaes
do produto
Deve ser personalizado. Estimar o esforo para realizar a personalizao
inicialmente e repeti-lo em cada atualizao do produto, tendo em conta
que o conceito de personalizao pode no ser aplicvel a futuros
lanamentos.
Figura 4.1 d uma boa viso geral das ligaes, entradas e sadas envolvidos
em cada fase do ciclo de vida de servios. Ela ilustra os principais resultados
produzidos por cada fase, os quais so usados como entradas pelas fases
subsequentes. O Portflio de Servios atua como "a coluna vertebral" do Ciclo
de Vida do Servio. a nica fonte integrada de informaes sobre o estado de
cada servio, juntamente com outros detalhes do servio e as interfaces e
dependncias entre servios. A informao na Carteira de servio usado pelas
atividades dentro de cada fase do ciclo de vida de servios.
4.1.2 mbito
Definio de servio
Produo e manuteno de um preciso Catlogo de Servios
Interfaces, dependncias e de consistncia entre o Catlogo de Servios
e Portflio de Servios
Interfaces e dependncias entre todos servios e servios de apoios
dentro do Catlogo de Servio e da CMS
Interfaces e dependncias entre todos os servios, e de apoio
componentes e Item de Configuraos (IC) dentro do Catlogo de Servio
e da CMS.
Para evitar confuso, pode ser uma boa idia para definir uma hierarquia de
servios na Catlogo de Servios, Qualificando exatamente que tipo de servio
registrado, por exemplo, servio de negcio (O que visto pelo cliente).
Alternativamente, servios de apoios, tais como servio de infra-estruturas
servios, de rede, servios de aplicativos (todos invisveis para o cliente, mas
essencial para a prestao de servios de TI) tambm precisam ser registradas.
Isso muitas vezes d origem a uma hierarquia de servios incorporando servios
ao cliente e outros servios relacionados, incluindo servios de apoio, servios
compartilhados e servios de commodities, cada um com definido e acordado
nvel de servios.
O catlogo de servio pode tambm ser utilizado para outros Servio de Gesto
de fins (por exemplo para a realizao de um Anlise de Impacto no Negcio
(BIA) como parte da Continuidade do Servio de TI Planejamento, Ou como um
ponto de partida para re-distribuio carga de trabalhos, como parte de
Gerenciamento da Capacidade). O custar e esforo de produzir e manter o
catlogo, com a sua relaos para a tecnologia de sustentao componentes, ,
portanto, facilmente justificvel. Se isso for feito em conjunto com a definio de
prioridades de BIA, ento possvel garantir que os servios mais importantes
so cobertos em primeiro lugar. Um exemplo de um simples Catlogo de
Servios que pode ser usada como um ponto de partida dado no Apndice G.
4.2.2 mbito
SLM oferece uma interface consistente para o negcio para todos os problemas
relacionados ao servio. Ele fornece o negcio com as metas de servio
acordadas e os necessrios gesto da informao para garantir que os
objectivos foram alcanados. Caso os objectivos sejam violados, SLM deve
fornecer feedback sobre a causa da violao e detalhes das aes tomadas
para evitar a violao de recorrentes. Assim SLM oferece um canal de
comunicao confivel e uma relao de confiana com o apropriado clientes e
representantes das empresas.
Embora Figura 4.6 ilustra todas as principais atividades da SLM como atividades
separadas, elas devem ser implementadas como um SLM integrado processo
que podem ser aplicadas de forma consistente a todas as reas das empresas e
de todos os clientes. Estas atividades so descritas nas sees seguintes.
Este o lugar onde um SLA cobre um servio, para todos os clientes desse
servio - por exemplo, um SLA pode ser estabelecido para o servio de uma
organizao de e-mail - que abrange todos os clientes que servio. Isto pode
parecer bastante simples. No entanto, as dificuldades podem surgir se os
requisitos especficos de clientes diferentes variar para o mesmo servio, ou se
as caractersticas da infra-estrutura significa que diferentes nvel de servios so
Multi-nvel SLAs
Algumas organizaes tm optado por adotar uma estrutura SLA multi-nvel. Por
exemplo, uma estrutura de trs camadas como se segue:
Conforme mostrado na Figura 4.7, tal estrutura permite que os SLAs sejam
mantidos a um tamanho administrvel, evita a duplicao desnecessria, e
reduz a necessidade de atualizaes freqentes. No entanto, isso no significa
Tambm vale a pena lembrar que os SLAs podem ter de cobrir os servios
oferecidos internacionalmente. Nesses casos, o SLA pode ter que ser traduzida
em vrias lnguas. Lembre-se tambm que um SLA redigido em um nico idioma
pode ter que ser revistos para adequao em vrias partes do mundo (ou seja,
um verso redigido na Austrlia pode ter que ser revistos para adequao nos
EUA ou no Reino Unido - e diferenas de estilo, terminologia e cultura Deve ser
tomado em conta).
Esta uma das primeiras actividades dentro do Design de Servios fase do ciclo
de vida de servios. Uma vez que o Catlogo de Servios foi produzido e da
estrutura SLA acordado, uma SLR primeiro deve ser elaborado. aconselhvel
envolver clientes, desde o incio, mas ao invs de ir junto com uma folha em
branco para comear, pode ser melhor para produzir um projecto primeiro
esboo da atuao metas e da gesto e operacional requisitos, como um ponto
de partida para discusso mais detalhada e profunda. Tenha cuidado, porm,
para no ir muito longe e parecem estar apresentando ao cliente um "fato
consumado".
As SLRs deve ser uma parte integrante do Design de Servios critrios, de que
o funcional especificao uma parte. Eles devem, desde o incio, fazem parte
do teste / experimentao critrios como o servio progride atravs dos estgios
de projeto e desenvolvimento ou aquisio. Este SLR ser gradualmente
refinado como o servio progride atravs dos estgios de seu ciclo de vida, at
que finalmente se torna um SLA piloto durante o incio do perodo de vida de
suporte. Este SLA piloto ou projecto dever ser desenvolvido juntamente com o
servio em si, e deve ser assinado e formalizado antes que o servio
introduzido em uso ao vivo.
Pode ser difcil estabelecer os requisitos, tal como o negcio pode no saber o
que eles querem - especialmente se no pediu anteriormente - e eles podem
precisar de ajuda para entender e definir as suas necessidades, especialmente
em termos de capacidade,segurana,disponibilidade e servios de TI
continuidade. Esteja ciente de que os requisitos inicialmente expressos no
podem ser aqueles finalmente concordou. Vrias iteraes de negociaes
podem ser necessrias antes de um equilbrio econmico est fechado entre o
que pedido eo que vivel e acessvel. Este processo pode envolver uma
reformulao da soluo de servio de cada vez.
Se novos servios esto a ser introduzido de uma forma perfeita para o viver
ambiente, Outra rea que requer ateno o planejamento e formalizao dos
mecanismos de apoio para o servio e sua componentes. Conselho deve ser
solicitada Gesto da Mudana e Gerenciamento da Configurao para
assegurar a planejamento abrangente e cobre a implementao,
desenvolvimento e apoio do servio e seus componentes. Responsabilidades
especficas precisam ser definidos e adicionado ao existente contratos / ANO, ou
novos precisam ser acordados. O regime de apoio e de todos os escalada rotas
tambm precisa de adicionar ao SCC, incluindo o Catlogo de Servios se for o
caso, para que o Service Desk e outro pessoal de apoio esto cientes deles. Se
necessrio, formao inicial e familiarizao para o Service Desk e outros grupo
de apoios e transferncia de conhecimento deve ser concluda antes de apoio
ao vivo necessrio.
Deve notar-se que os recursos de suporte adicionais (isto , mais pessoal) pode
ser necessrio para suportar novos servios. Muitas vezes existe uma
expectativa de que um j sobrecarregado grupo de apoio pode magicamente
lidar com o esforo adicional imposta por um novo servio.
Nada deve ser includo em um SLA a menos que possa ser efetivamente
monitorados e medidos em um ponto de comum acordo. A importncia desta
no pode ser negligenciado, como a incluso de itens que no podem ser
eficazmente controlado quase sempre resulta em disputas e eventual perda de
f na SLM processo. Um monte de organizaos descobriram o caminho mais
difcil e, como resultado, absorvido pesado custars, tanto no sentido financeiro
como tambm em termos de negativo impactos da sua credibilidade.
Desde o incio, sbio para tentar gerenciar as expectativas dos clientes. Isso
significa definir expectativas adequadas e metas apropriadas, em primeiro lugar,
e colocando um processo sistemtico no local para gerenciar as expectativas
daqui para frente, como a satisfao = percepo - expectativa (onde uma
pontuao zero ou positivo indica um cliente satisfeito). SLAs so apenas
documentos, e em si no alterar significativamente a qualidade de servio sendo
fornecido (embora possam afetar o comportamento e ajudar a engendrar um
adequado cultura de servio, Que pode ter um efeito benfico imediato, e fazer
melhorias de longo prazo possvel). Um certo grau de pacincia , portanto,
necessria e deve ser construdo em expectativas.
Sempre que possvel, deveriam ser fixados objectivos para estes e monitorados
como parte do SLA (por exemplo, uma pontuao mdia de 3,5 deve ser
alcanada pelo provedor de servios em resultados dados, com base em um
sistema de pontuao de 1 a 5, onde 1 pobre atuao e 5 excelente).
Garantir que, se usurios fornecer feedback que recebem algo em troca, e
demonstrar-lhes que seus comentrios foram incorporadas em um plano de
ao, talvez um SIP. Todas as medidas de satisfao dos clientes devem ser
revistos, e onde as variaes so identificados, eles devem ser analisados com
medidas tomadas para corrigir a variao.
OLAs devem ser monitorados contra alvos OLA e SLA e relatrios sobre as
realizaes previstas como feedback para os gerentes da apropriadas de cada
equipe de suporte. Isso destaca reas de problemas potenciais, que podem
precisar de ser abordados internamente ou por mais rever de SLA ou o OLA.
Sria considerao deve ser dada introduo OLAs formais para todas as
equipes de suporte interno, que contribuem para o apoio de operacional
servios.
Antes de cometer a SLAs nova ou revista, por isso importante que as actuais
disposies contratuais so investigadas e, se necessrio, atualizado. Esta
provavelmente a incorrer adicional custars, que deve ser absorvido pela TI ou
passado para o cliente. Neste ltimo caso, o cliente deve concordar com isso, ou
os alvos mais relaxado em contratos existentes devem ser acordados para
incluso em SLAs. Este atividade deve ser concludo em estreita consulta com o
Gesto de Fornecedores processo, para garantir no s que os requisitos sejam
cumpridos SLM, mas tambm que todos os requisitos de outros processos so
considerados, particularmente fornecedor e polticas contratuais e normas.
Relatrios peridicos deve ser produzido e distribudo aos clientes (ou seus
representantes) e apropriados gerentes de TI de alguns dias de antecedncia
nvel de servio revises, de modo que quaisquer dvidas ou divergncias
podem ser resolvidas antes da reunio de avaliao. A reunio no ento
desviado por tais questes.
Reunies de avaliao peridica deve ser realizada em uma base regular com
os clientes (ou seus representantes) para analisar a realizao de servios no
ltimo perodo e para visualizar todas as questes para o prximo perodo.
normal para realizar tais reunies mensais ou, no mnimo, trimestrais.
Particular ateno deve ser focada em cada violao de nvel de servio para
determinar exatamente o que causou a perda de servio eo que pode ser feito
para evitar que se repitam. Se for decidido que o nvel de servio era, ou se
tornou, inatingvel, pode ser necessrio rever, renegociar, rever-acordar metas
de servios diferentes. Se a quebra de servio foi causado por uma falha de um
terceiro ou interno grupo de apoio, Tambm pode ser necessrio rever a base
acordo ou OLA. Anlise dos custos e do impacto das violaes de servio
fornece informaes valiosas e justificao das atividades SIP e aes. A
necessidade constante de melhoria precisa ser equilibrado e focado nas reas
com maior probabilidade de dar o benefcio maior de negcios.
'Espio Um em ambos os campos "- Gestores de Nvel de Servio pode ser visto
com uma certa desconfiana tanto pela Provedor de servios de TI pessoal e os
representantes dos clientes. Isto devido a dupla natureza do trabalho, onde
eles esto atuando como um representante do cliente no-oficial ao falar com a
equipe de TI, e como um representante do provedor de TI quando falar com o
clientes. Isso geralmente agravada quando se tem para representar a
'oposio' ponto de vista em qualquer reunio etc Para evitar isso o Gerente de
Nvel de Servio deve ser to aberta e til quanto possvel (dentro dos limites de
Estes revers deve garantir que os servios cobertos e as metas de cada ainda
so relevantes - e que nada de significativo mudou que invalida o acordo de
qualquer forma (isto deve incluir mudanas de infra-estrutura, mudanas
empresariais, fornecedor alteraes, etc.) Onde mudars so feitas, os acordos
devem ser atualizados em Gesto da Mudana controlar a refletir a nova
situao. Se todos os acordos so registados como IC dentro da CMS, mais
fcil avaliar o impacto e implementar as mudanas de uma maneira controlada.
Key Performance Indicators (KPIs) e mtricas podem ser usadas para julgar o
eficincia e eficcia das atividades SLM eo progresso da SIP. Essas mtricas
devem ser desenvolvidos a partir do servio ao cliente, e perspectiva de
negcios e deve abranger ambas as medies subjetivas e objetivas, tais como
o seguinte.
Objetivo:
Subjetiva:
A SLM processo muitas vezes gera um bom ponto de partida para um SIP - eo
processo de reviso de servios pode conduzir este, mas todos os processos e
todas as reas da provedor de servios organizao deve ser envolvido na SIP.
4.2.7.1 KPIs
Cuidados devem ser tomados ao abrir discusses sobre nvel de servios, pela
primeira vez, como provvel que 'problemas atuais "(a falha que ocorreu
ontem) ou de longa durao queixas (aquela impressora velha que temos vindo
a tentar obter substitudo por idades) so susceptveis de ser exibido no incio.
Importante ainda que estes possam ser, eles no devem ser autorizados a
entrar no caminho de estabelecer os requisitos de longo prazo. Esteja ciente, no
entanto, que pode ser necessrio para resolver quaisquer questes levantadas
no incio antes de ganhar alguma credibilidade para avanar.
No escolher uma rea onde existem grandes problemas como o SLA primeiro.
Tente escolher uma rea que tende a mostrar alguns benefcios rpidos e
desenvolver o processo de SLM. Nada encoraja a aceitao de uma nova idia
mais rpido do que o sucesso.
Uma vez que o SLA inicial j foi concluda, e as dificuldades iniciais superar, em
seguida, seguir em frente e gradualmente introduzir SLAs para outros servios /
clientes. Se for decidido, desde o incio para ir para uma estrutura multi-nvel,
provvel que os problemas de nvel corporativo tm que ser cobertos para todos
os clientes no momento do SLA inicial. Tambm vale a pena experimentao as
questes corporativas durante esta fase inicial.
No v para alvos fceis no nvel corporativo. Podem ser fcil de alcanar, mas
no tm valor na melhoria do servio qualidade ou credibilidade. Alm disso, se
os objectivos so fixados a um nvel suficientemente elevado, o SLA corporativo
pode ser usado como o padro que todos os novos servios devem alcanar.
Devem ser tomadas medidas para anunciar a existncia da nova SLAs e OLAs
entre o Service Desk e outros grupo de apoios, com detalhes de quando eles se
tornam operacional. Pode ser til para extrair principais alvos desses acordos
em tabelas que podem estar em exibio em reas de suporte, de modo que os
funcionrios esto sempre cientes dos objectivos a que eles esto trabalhando.
Se as ferramentas de apoio permitem, essas metas devem ser registrados
dentro das ferramentas, como dentro de um Catlogo de Servios ou CMS, de
4.3.2 mbito
Entender tudo isso vai permitir Gerenciamento da Capacidade para garantir que
toda a capacidade atual e futura e atuao aspectos servios so fornecidos de
forma rentvel.
Verifique SLA
Controle e implementao
A principal diferena entre os sub-processos est nos dados que esto sendo
monitorados e coletados, ea perspectiva de que analisado. Por exemplo, o
nvel de utilizao dos componentes individuais no infra-estruturas - tais como
processadores, discos e as ligaes de rede - de interesse em Gerenciamento
da Capacidade componente, Enquanto que a operao rendimento taxas e
tempo de respostas so de interesse em Gerenciamento da Capacidade de
servio. Para Gerenciamento da Capacidade de negcios, As taxas de
transao de transferncia para a necessidade do servio online a ser traduzido
em volumes de negcios - por exemplo, em termos de facturas de venda
levantada ou pedidos. O maior desafio Gerenciamento da Capacidade
entender a relao entre as demandas e exigncias do negcio e os negcios
carga de trabalho, E de ser capaz de traduzir estes em termos de impacto e
efeito destas sobre o servio e recurso carga de trabalhos e utilizaes, de modo
que adequado limiars pode ser fixada em cada nvel.
A utilizao do processador
Utilizao de memria
Por cento por processador transao tipo
Taxas de ES (fsica e buffer) e utilizao de dispositivo
Comprimentos de fila
Utilizao de disco
Taxas de transao
Os tempos de resposta
Lote durao
O uso de banco de dados
O uso de ndice
Taxas de acerto
Concorrente usurio nmeros
Trfego taxas de rede.
Ao considerar os dados que precisam ser includos, uma distino deve ser feita
entre os dados coletados para monitorar capacidade (E.g. rendimento) E os
dados para monitorizar atuao (E.g. tempo de respostas). Os dados de ambos
os tipos exigido pelo servio e Gerenciamento da Capacidade componente
sub-processos. Este monitoramento e recolha precisa incorporar todos os
componentes na servio, Assim, monitorar a experincia do "end-to-end 'do
cliente. Os dados devem ser recolhidas a nvel total de utilizao de recursos e
com um perfil mais detalhado para a carga que cada servio coloca em cada
componente particular. Isso precisa ser realizado em toda a tecnologia de
acolhimento, ou servidor, O local, rede servidor e cliente ou estao de trabalho.
Da mesma forma que os dados precisam ser coletados para cada servio.
Muitas vezes, mais difcil obter os dados sobre os volumes de negcios atuais,
conforme exigido pela Administrao de Empresas Capacidade sub-processo.
Estas estatsticas podem precisar de ser derivada a partir dos dados disponveis
para o servio e Gerenciamento da Capacidade componente sub-processos.
Muitos tm SLAs usurio tempos de resposta como uma das metas a serem
medidos, mas igualmente muitos organizaos tm grande dificuldade em apoiar
esta exigncia. Tempos de resposta do usurio de TI e servios de rede pode
ser monitorado e medido pelo seguinte:
Anlise
Afinao
Implementao
Projetando resilincia
Este atividade pode ser realizada como um curto prazo exigncia porque no
existem suficientes actual capacidade para apoiar o trabalho a ser executado,
ou, como uma poltica deliberada de gesto de TI, para limitar a capacidade
necessria no longo prazo.
A curto prazo de Gesto da procura pode ocorrer quando h uma parcial falha
de um recurso crtico no Infra-estrutura de TI. Por exemplo, se houver uma falha
de um processador dentro de um multi-processador servidor, Pode no ser
possvel executar a gama de servios. No entanto, um nmero limitado de
servios poderia ser executado. Gerenciamento da Capacidade deve estar
ciente da prioridade do negcio de cada um dos servios, conhecer as
necessidades de recursos de cada servio (Neste caso, a quantidade de energia
do processador necessrio para executar o servio) e, em seguida, ser capaz de
identificar quais os servios que podem ser executados enquanto h uma
quantidade limitada de energia do processador disponvel.
A influncia sobre os servios que esto em execuo poderia ser exercida por:
Restries fsicas: Por exemplo, pode ser possvel parar alguns servios
de estar disponvel em certos momentos, ou para limitar o nmero de
clientes que podem usar um servio em particular - por exemplo, atravs
Baselining
Anlise de tendncias
Anlise de tendncias pode ser feito sobre a utilizao dos recursos e servio
atuao informao que foi recolhida pelo Gerenciamento da Capacidade
processo. Os dados podem ser analisados numa folha de clculo, e as
Modelagem analtica
Modelagem, simulao
Aplicao dimensionamento tem vida til limitada. Ele iniciado no projeto fase
de um novo servio, ou quando h uma mudana significativa para um servio
existente, e completa-se quando o aplicao aceito no ao vivo operacional
ambiente. Dimensionamento de atividades deve incluir todas as reas de
tecnologia relacionados com as aplicaes, e no apenas os prprios
aplicativos. Isto deve incluir a infra-estrutura, meio ambiente e de dados, e,
muitas vezes, usar a modelagem e tendncias tcnicas.
4.3.6.1 Entradas
4.3.6.2 Sadas
Alguns dos KPIs e mtricos que podem ser usados para avaliar a eficincia e
eficcia das atividades de gerenciamento de capacidade deve incluir:
Para cada componente deve haver uma equipe de tcnicos responsveis pela
sua controlar e gesto. Os relatrios devem ser produzidos para ilustrar como os
componentes esto realizando e quanto de sua capacidade mxima est sendo
usado.
Relatrios de exceo
Dados comerciais
Dados de servio
Os dados financeiros
4.4.2 mbito
Nmero de quebras
Nmero de quebras
MTRS deve ser usado para evitar a ambiguidade do termo da indstria mais
comum Mean Time To Repair (MTTR), que em algumas definies inclui
somente reparar tempo, mas em outros inclui recuperao tempo. O tempo de
inatividade em MTRS abrange todos os fatores contribuintes que fazem o
servio, componente ou CI indisponveis:
VBFs certos pode precisar de projetos especiais, que esto agora a ser
utilizados como uma questo de curso dentro Design de Servios planos, que
inclui:
O negcio pode ter, por muitos anos, aceitou que a disponibilidade de TI que a
experincia representada em termos de disponibilidade de componentes e no
global servio ou de negcios disponibilidade. No entanto, isso no mais visto
como aceitvel eo negcio est ansiosa para melhor representar a
disponibilidade de medida (s) que mostram as conseqncias positivas e
negativas de a disponibilidade de TI em seus negcios e usurios.
Anlise de indisponibilidade
O custar de uma falha que poderia simplesmente ser expresso como o nmero
de negcios ou TI transaos impactados, quer como um nmero real (derivado
de instrumentao) ou com base em um estimativa. Quando medido contra os
VBFs que suportam o negcio operao, O que pode proporcionar uma
indicao bvia de a consequncia da falha. A vantagem dessa abordagem a
relativa facilidade de obteno dos dados de impacto e da falta de quaisquer
O valor monetrio pode ser calculada como uma combinao dos custos
associados ao insucesso tangveis, mas tambm pode incluir uma srie de
custos intangveis. O valor monetrio tambm deve refletir o impacto do custo
para o conjunto organizao, Ou seja, o negcio ea organizao de TI.
Perda de clientes
Perda da boa vontade do cliente (insatisfao do cliente)
Perda de oportunidade de negcio (vender, conquistar novos clientes ou
de receita, etc)
Danos reputao do negcio
Perda de confiana no Provedor de servios de TI
Danificar a moral do pessoal.
Uma boa tcnica para ajudar com a anlise tcnica dos incidentes que afectam
a disponibilidade de componentes servios e de TI ter viso 'ciclo de vida' de
um incidente. Cada incidente passa por vrias fases principais. O tempo
decorrido nestas fases pode variar consideravelmente. Para fins de
gerenciamento de disponibilidade, "ciclo de vida" do incidente padro, como
descrito em Gerenciamento de Incidentes, foi ampliado para fornecer ajuda e
orientao especificamente na rea de "projetar para recuperao'. Figura 4.15
ilustra o ciclo de vida do incidente expandido.
Sistemas de gesto
Componente Anlise de Impacto falha (CFIA) podem ser utilizados para prever e
avaliar o impacto sobre o servio de TI resultantes da falha de componentes
dentro da tecnologia. A sada de um CFIA pode ser usado para identificar onde
adicional resilincia devem ser consideradas para evitar ou minimizar o impacto
da falha de componentes para a operao de negcio e usurios. Isto
particularmente importante durante a Design de Servios palco, onde
necessrio prever e avaliar o impacto sobre a disponibilidade do servio de TI
decorrentes de falhas de componentes dentro do Design de Servios de TI
proposta. No entanto, a tcnica tambm pode ser aplicada aos servios
existentes e infra-estrutura.
CFIA uma tcnica relativamente simples, que pode ser usada para fornecer
esta informao. IBM concebeu CFIA no incio de 1970, com suas origens
baseadas em design de hardware e configurao. No entanto, recomenda-se
que CFIA ser usado num contexto mais amplo de modo a reflectir o completo
escopo da infra-estrutura de TI, ou seja, hardware, rede, software, aplicaos,
centros de dados e pessoal de apoio. Alm disso, a tcnica tambm pode ser
aplicado para identificar e dependncias impacto sobre o suporte de TI
organizao habilidades e competncias entre o pessoal de apoio do servio de
TI novo. Este atividade geralmente completada em conjunto com ITSCM e
possivelmente Gerenciamento da Capacidade.
Para realizar uma CFIA avanada requer a matriz CFIA a ser expandido para
fornecer campos adicionais necessrios para a anlise mais detalhada. Isto
poderia incluir campos, tais como:
Anlise da rvore de Falhas (TLC) uma tcnica que pode ser usada para
determinar a cadeia de eventos que provoca uma perturbao De servios de
TIs. TLC, em conjunto com os mtodos de clculo, pode oferecer detalhada
modelos de disponibilidade. Isto pode ser usado para avaliar a melhoria de
disponibilidade que pode ser alcanado atravs de tecnologia individuais opes
de concepo dos componentes. Usando FTA:
Esta a tcnica bsica FTA. Esta tcnica pode tambm ser refinados, mas
complexo e FTA a avaliao matemtica de rvores de falhas esto fora do
mbito da presente publicao.
Modelagem
M_o_R fornece uma estrutura que experimentado, testado e eficaz para ajudar
a eliminar - ou gerenciar - os riscos envolvidos em alcanar seus objetivos.
M_o_R adota uma aplicao sistemtica de princpios, abordagem e processoes
para a tarefa de identificar, avaliar e depois planejamento e implementao de
respostas de risco. Orientao enfatiza uma abordagem de colaborao e incide
sobre os seguintes elementos fundamentais:
O alterao de horrio
Planos de lanamento e os liberar programar
Todos transio planos, projetos e programas
Planejadas e programaes de manuteno preventiva
O cronograma para testar a continuidade dos servios de TI e
recuperao planos
Planos de negcios e horrios.
SLAs
OLAs
Subjacente contratos
Gesto da Mudana horrios
Lanamento de Gerenciamento de Implantao horrios.
O alterao de horrio
Os horrios de liberao
4.4.6.1 Entradas
4.4.6.2 Sadas
A fim de proporcionar estrutura e foco para uma ampla gama de iniciativas que
podem ter de ser tomadas para melhorar disponibilidade, Um plano de
disponibilidade devem ser formuladas e mantida. O Plano de Disponibilidade
deve ter objectivos, objetivos e entregas e deve considerar as questes mais
amplas de pessoas, processos, ferramentas e tcnicas, bem como ter um foco
de tecnologia. Nas fases iniciais, pode ser alinhada com uma implementao
plano para gerenciamento de disponibilidade, mas os dois so diferentes e no
devem ser confundidas. Como o processo de Gerenciamento de Disponibilidade
amadurece, o plano deve evoluir para cobrir o seguinte:
Uma abordagem de ciclo de vida devem ser adotados para a criao e operao
de um processo GCSTI. Figura 4.21 apresenta o ciclo de vida do GCSTI, desde
a iniciao at a garantia contnua que a proteo oferecida pelo plano atual e
reflete tudo mudars para os servios e nvel de servios. ITSCM um processo
cclico atravs do ciclo de vida de garantir que, uma vez servio planos de
continuidade e recuperao foram desenvolvidos so mantidos alinhados com
Planos de Continuidade de Negcios (PCN) e as prioridades de negcios. Figura
4.21 tambm mostra a papel jogado dentro do processo ITSCM do BCM.
As sees a seguir contm detalhes de cada uma das fases do ciclo de vida
dentro GCSTI.
A BIA identifica:
Esses itens fornecem os drivers para o nvel dos mecanismos de ITSCM que
precisam ser considerados ou implantado. Uma vez apresentadas as seguintes
opes, o negcio pode decidir que os nveis mais baixos de servio ou atrasos
maiores so mais aceitveis, com base numa anlise custo-benefcio, Ou talvez
que medidas gerais de preveno de desastres tero de ser implementadas.
Impactos devem ser medidos contra cenrios especficos para cada processo de
negcio, tais como a incapacidade de liquidao de operaes no mercado
monetrio de um processo de negociar, ou impossibilidade de nota fiscal por
um perodo de dias. Um exemplo um ambiente de mercado monetrio lidar
onde a perda de informaes de dados de mercado poderia significar que a
organizao comea a perder dinheiro imediatamente como o comrcio no
pode continuar. Alm disso, clientes pode ir para outra organizao, o que
significaria a perda de potencial de negcio. Perda do sistema de liquidao no
impede comrcio de acontecer, mas se ofcios j realizadas no pode ser
resolvido dentro de um determinado perodo de tempo, a organizao pode estar
em violao das regras de regulao ou perodos de liquidao e sofrer multas e
reputao danificada. Isto pode realmente ser a mais significativa impacto do
que a incapacidade para o comrcio devido a uma incapacidade de satisfazer as
expectativas dos clientes.
Uma metodologia padro, tal como o Gesto de Risco (M_o_R), deve ser usado
para avaliar e gerir os riscos dentro de uma organizao. O quadro M_o_R
ilustrado na Figura 4.23.
Figura 4.24 apresenta um perfil de risco exemplo, contendo muitos riscos que
esto fora do nvel definido de "aceitvel risco'. Aps a anlise de risco
possvel determinar as respostas adequadas de risco ou medidas de reduo de
risco (mecanismos ITSCM) para gerenciar os riscos, ou seja, reduzir o risco a
um nvel aceitvel ou mitigar o risco. Sempre que possvel, as respostas de risco
adequados devem ser implementados para reduzir tanto o impacto ou a
probabilidade, ou de ambos, desses riscos de se manifestarem. No contexto da
ITSCM, h um certo nmero de riscos que precisam de ser tomadas em
considerao. O seguinte no uma lista exaustiva, mas d alguns exemplos de
riscos e ameaas que precisam ser abordadas pelo ITSCM processo.
Armazenamento off-site
Para certos tipos de servios, manuais de trabalho-around pode ser uma medida
eficaz interino por um perodo de tempo limitado, at o De servios de TI
retomada. Por exemplo, uma Service Desk o registro de chamadas de servio
Acordos de reciprocidade
Recuperao gradual
Esta opo (por vezes referido como 'espera frio') Inclui o proviso de
alojamento vazio, totalmente equipada com o poder, controles ambientais e de
infra-estrutura de cabeamento de rede local, ligaes de telecomunicaes, e
disponvel em uma situao de desastre para uma organizao para instalar o
seu equipamento prprio computador. No inclui o equipamento de computao
actual, portanto, no aplicvel para servios que requerem rpida
recuperao, Como configurar-tempo necessrio para a recuperao de
servios pode comear. Esta opo de recuperao recomendado apenas
para servios que podem suportar um atraso de tempo de recuperao em dias
ou semanas, no horas. Qualquer servio no-crtica que pode suportar este tipo
de atraso deve levar em conta o custo desta opo versus o benefcio para o
negcio antes de determinar se um recuperao gradual opo deve ser includo
nas opes ITSCM para a organizao.
O alojamento pode ser fornecido comercialmente por terceiro, Para uma taxa, ou
pode ser privado, (estabelecido pela prpria organizao) e, desde como um
servio fixo ou porttil.
Recuperao intermediria
Esta opo (por vezes referido como 'espera passiva') selecionada por
organizaes que precisam recuperar instalaes de TI dentro de um tempo pr-
Recuperao rpida
Esta opo (por vezes referido como "hot standby"), prev recuperao rpida e
restaurao de servios e s vezes fornecida como uma extenso para o
recuperao intermediria fornecida por um provedor de recuperao de
terceiros. Algumas organizaes ir fornecer suas prprias instalaes dentro da
organizao, mas no em um local alternativo ao utilizado para as operaes
normais. Outros aplicar seus prprios internos locais segundo em um local
alternativo para fornecer mais resistente recuperao.
Recuperao imediata
Esta opo (tambm muitas vezes referida como "hot standby", "espelhamento",
"balanceamento de carga" ou "local split '), prev a imediata restaurao dos
servios, sem prejuzo do servio. Para servios crticos de negcios, as
organizaes requerem operao contnua ir fornecer suas prprias instalaes
dentro da organizao, mas no no mesmo local das operaes normais.
Equipamentos de TI ser suficiente "dual localizado" em qualquer local de uma
propriedade ou hospedado para executar o servio de competir a partir de
qualquer localizao em caso de perda de uma unidade, sem perda de servio
para o cliente. O segundo local pode ento ser recuperado, enquanto o servio
fornecido a partir do nico local opervel. Esta uma opo cara, mas pode ser
justificada por crtico processo de negcioes ou VBFs onde no disponibilidade
de um curto perodo pode resultar numa significativa impacto, Ou em que no
seria adequado para ser executado De servios de TIs numa terceiro'S
premissas para segurana ou outras razes. A instalao precisa ser localizado
separadamente e longe o suficiente do local de casa que no ser afectado por
uma catstrofe que afeta esse local. No entanto, estes espelhado servidors
opes e sites devem ser implementadas em estreita ligao com
Gerenciamento de Disponibilidade como eles suportam servios com elevados
nveis de disponibilidade.
Figura 4.25 mostra que um nmero de opes pode ser utilizada para
proporcionar a continuidade do servio. Um exemplo da Figura 4.25 mostra que,
O plano deve garantir que todos os detalhes sobre a recuperao dos servios
de TI aps um desastre so totalmente documentados. Deve ter detalhes
suficientes para permitir que um tcnico familiarizado com os sistemas a ser
capaz de seguir os procedimentos. O recuperao planos incluem detalhes
importantes, tais como o ponto de recuperao de dados, uma lista de sistemas
dependentes, a natureza do dependncia e seus pontos de recuperao de
dados, hardware e sistema de requisitos de software, detalhes de configurao e
referncias a informaes relevantes ou essenciais outro sobre o servio e
sistemas.
uma boa idia de incluir uma lista que abrange aces especficas
necessrias durante todas as fases de recuperao para o servio e do sistema.
Por exemplo, depois que o sistema foi restaurado para um estado operacional,
cheques, cheques de conectividade funcionalidade ou consistncia de dados e
verificaes de integridade devem ser realizadas antes de entregar o servio
para o negcio.
Planejamento, organizao
Teste
Todos os testes devem ser realizados contra cenrios de teste definidos, que
so descritos de forma to realista quanto possvel. Deve notar-se, contudo, que
mesmo a mais abrangente teste no cobre tudo. Por exemplo, em uma
interrupo do servio onde houve leso ou at mesmo a morte de colegas, a
reao do pessoal a uma crise no pode ser testada e os planos precisam fazer
a permisso para isso. Alm disso, os testes devem ter claramente definido
objetivos e Fator Crtico de Sucessos, que vai ser utilizado para determinar o
grau de sucesso do exerccio.
Invocao
A deciso de invocar deve ser feito rapidamente, pois pode haver uma vantagem
de tempo envolvido no estabelecimento de instalaes de um local de
recuperao. No caso de um incndio do edifcio grave, a deciso pode ser
relativamente fcil de fazer. No entanto, no caso de falha de energia ou de
hardware culpa, Onde um resoluo esperado dentro de um curto perodo, o
prazo deve ser definido pelo qual tempo se o incidente no foi resolvido,
invocao ter lugar. Se usar provedores de servios externos, eles devem ser
avisados imediatamente se h uma chance de que a invocao poder ter lugar.
Por isso o design da invocao processo deve fornecer orientaes sobre como
todas essas reas e circunstncias devem ser avaliadas para ajudar a pessoa
de invocar a continuidade plano.
O Plano ITSCM deve incluir detalhes sobre as atividades que precisam ser
realizadas, incluindo:
Uma vez que a recuperao foi completa, a empresa deve ser capaz de operar a
partir do local de recuperao no nvel determinado e acordado no estratgia e
relevantes SLA. O objetivo, No entanto, ser a de construir o negcio para nveis
normais, manter operao a partir do local de recuperao no curto prazo e
desocupar o local de recuperao no menor tempo possvel. Detalhes de todas
essas atividades precisam ser contido dentro dos planos. Se usar servios
externos, haver um perodo finito contratual para usar as instalaes.
Independentemente do perodo, um retorno ao normal deve ser cuidadosamente
planejada e realizada de forma controlada. Normalmente, esse ser mais um fim
de semana e pode incluir alguns necessrio tempo de inatividade em horrio
comercial. importante que isso seja bem gerido e que todos os envolvidos
esto cientes de suas responsabilidades para garantir uma transio suave.
4.5.6.1 Entradas
4.5.6.2 Sadas
4.6.2 mbito
O ISM processo deve ser o ponto focal para todas as questes de segurana de
TI, e deve assegurar que um Poltica de Segurana da Informao produzido,
mantido e imposto que cobre o uso e abuso de todos os sistemas e servios de
TI. ISM precisa entender o total de TI e ambiente de segurana de negcios,
incluindo a:
Compreender tudo isto permitir ISM para assegurar que todos os actuais e
futuros aspectos de segurana e os riscos do negcio so custo-benefcio
gerenciado.
Controlar
Plano
Executar
Avaliao
Manter
A governao da segurana
Alinhamento estratgico:
Os requisitos de segurana deve ser impulsionada por exigncias
corporativas
Solues de segurana precisam se encaixar processos
empresariais
Investimento em informao segurana devem estar alinhados
com a empresa estratgia e acordada no perfil de risco.
Entrega de valor:
Um conjunto padro de prticas de segurana, ou seja, os
requisitos de segurana de linha de base melhores prticass
Devidamente priorizadas e distribudas esforo para reas com
maior impacto e benefcio do negcio
Solues institucionalizadas e comoditizado
Solues completas organizao, cobertura e processo, bem como
a tecnologia
Uma cultura de melhoria contnua.
Gesto de riscos:
Consensual no perfil de risco
Compreenso de exposio ao risco
Conscincia de gesto de risco prioridades
Mitigao de riscos
Aceitao de riscos / deferncia.
Gesto de desempenho:
Conjunto definido, concordou e significativa de mtricos
Processo de medio que vai ajudar a identificar deficincias e
fornecer feedback sobre os progressos realizados questes
resolver
Garantia independente.
Gesto de recursos:
Conhecimento capturado e disponvel
Documentado segurana processos e prticas
Arquitetura de segurana desenvolvido (s) para utilizar
eficientemente os recursos de infra-estrutura.
Garantia de processo de negcio.
ISM de atividade pode ser desencadeada por vrios eventos. Estes incluem:
4.6.6.1 Entradas
4.6.6.2 Sadas
Muitos KPIs e mtricos pode ser usada para avaliar a eficcia e eficincia do
processo de ISM e actividades. Estas mtricas precisam ser desenvolvidos a
partir do servio, cliente e perspectiva de negcios tais como:
Todas as informaes necessrias pelo ISM deve ser contido dentro dos SIGE.
Isto deve incluir todos segurana controles, riscos, violaes, processos e
relatrios necessrios para apoiar e manter a Poltica de Segurana da
Informao e o ISMS. Esta informao dever abranger todos os servios de TI
e componentes e precisa ser integrado e mantido em alinhamento com todos os
outros sistemas de TI de gesto da informao, em especial o Portflio de
Servios e do. CMS Os SIGE tambm ir fornecer a entrada para auditorias de
segurana e revises e para as atividades de melhoria contnua to importante
para todos ISMSs. Os SIGE tambm ir fornecer valiosa contribuio para o
projeto de novos sistemas e servios.
Isto significa que no so novas reas de risco que podem ter um significativo
impacto em operaes crticas de negcios, tais como:
4.7.2 mbito
A chave para uma relao bem sucedida parceria est sendo absolutamente
clara sobre os benefcios e os custos de tal relacionamento vai entregar antes de
entrar nela. Ambas as partes, ento sabe o que esperado deles desde o incio.
O sucesso da parceria pode envolver um acordo sobre a transferncia de
pessoal para o parceiro ou terceirizao organizao como parte do acordo e de
relacionamento.
Estes processos podem, e deve ser, diferente, com base no tipo, tamanho e
categoria do fornecedor e do contrato.
Contratos formais
Segurana requisitos
Continuidade de requisitos de negcios
Mandatado tcnico padros
Planos de migrao (acordado agendada mudar)
Acordos de confidencialidade.
Acordos subjacentes
Tal como aconteceu com SLA, importante que OLAs so monitorados para
destacar os potenciais problemas. O Gerente de Nvel de Servio tem a
responsabilidade geral para avaliar o desempenho em relao s metas para
que as medidas podem ser tomadas para remediar, e prevenir a recorrncia de
futuro, quaisquer violaes OLA. Dependendo do tamanho da organizao e da
variedade de servios, por exemplo, SLAs e OLAS, um Gerente de Nvel de
Servio deve assumir a responsabilidade por seu servio ou conjunto de
servios.
Dois nveis de educao formal rever precisam ocorrer ao longo do contrato ciclo
de vida para minimizar risco e assegurar o negcio percebe benefcio mximo
do contrato:
Crticas de contrato deve ser feita em uma base regular para garantir o contrato
de continuar a atender s necessidades de negcio. Crticas de contrato
avaliar a operao de contrato de forma holstica e em um nvel mais alto do que
os comentrios de servios que so realizados em um operacional nvel. Esses
exames devem considerar:
4.7.6.1 Entradas
4.7.6.2 Sadas
Muitos KPIs e mtricos pode ser usada para avaliar a eficcia e eficincia do
Gesto de Fornecedores processos e atividades. Essas mtricas precisam ser
Gesto de Fornecedores enfrenta muitos desafios, que podem incluir alguns dos
seguintes:
Gesto de infra-estrutura
Gesto Ambiental
Dados e Gesto de Informao
Aplicao de Gesto de.
Gerenciabilidade: Ser que funciona? Ser que no? Como que falha?
Eficincia: Quantas recursos que consumir?
Disponibilidade e confiana: Como confivel que preciso para ser?
Capacidade e atuao: Qual a capacidade que precisamos?
Segurana: O que classificao de segurana necessria?
Instalao: Quanto esforo necessrio para instalar o aplicao?
usando a instalao automatizada procedimentos?
Continuidade: Qual o nvel de resilincia e recuperao necessria?
Controlabilidade: Pode ser monitorado, gerenciado e ajustado?
Manutenibilidade: Como bem pode a aplicao ser ajustada, corrigido,
mantido e mudado para necessidades futuras?
Operacionalidade: Ser que os aplicativos perturbar outras aplicaes
em suas funcionalidades?
Mensurabilidade e reportabilidade: Podemos medir e informar sobre
todos os aspectos necessrios da aplicao?
H uma srie de tcnicas que podem ser utilizadas para investigar situaes de
negcios e elicitar os requisitos de servio. Por vezes, o clientes e a negcio no
esto completamente certos do que realmente so suas necessidades e vai
precisar de alguma ajuda e inspirao do designer ou coletor requisitos. Este
deve ser preenchido de forma sensvel para garantir que ele no visto como TI
ditar os requisitos de negcios novamente. As duas tcnicas mais utilizadas so
entrevistas e workshops, mas estes so geralmente complementados por outras
tcnicas, como a observao e cenrios.
5.1.3.1 Entrevistas
sempre uma boa idia para escrever as notas da entrevista o mais rpido
possvel - de preferncia, de imediato e, geralmente, no dia seguinte.
5.1.3.2 Workshops
Obter uma viso ampla da rea sob investigao - com um grupo de das
partes interessadass em uma sala vai permitir uma compreenso mais
completa dos problemas e problemas
Aumente a velocidade e produtividade - muito mais rpido para ter uma
reunio com um grupo de pessoas do que entrevistando-os um por um
Obter buy-in e aceitao para o servio de TI
Obter uma viso de consenso - se todos os das partes interessadass
esto envolvidos, a chance deles tomar posse dos resultados
melhorada.
Pode ser demorada para organizar - por exemplo, nem sempre fcil de
obter todas as pessoas necessrias em conjunto ao mesmo tempo,
5.1.3.3 Observao
Por outro lado, sendo observado pode ser um pouco irritante, eo velho ditado
"voc muda quando est sendo observado" tem de ser tido em conta em sua
abordagem e descobertas.
5.1.3.5 Shadowing
Eles foram o usurio para incluir todas as etapas, para que no haja
tomadas como certas elementos eo problema do conhecimento tcito
dirigida
Ao ajudar o usurio visualizar todas as contingncias, eles ajudam a lidar
com a incerteza sobre os futuros sistemas e servios
Um grupo de oficina de refino de um cenrio vai identificar os caminhos
que no se adaptam a empresa cultura
Eles fornecem uma ferramenta para preparar teste scripts.
5.1.3.7 prototipagem
H uma forte ligao entre cenrios e prottipos porque os cenrios podem ser
usados como base para o desenvolvimento de prottipos. Alm de confirmar os
requisitos dos usurios, prototipagem muitas vezes podem ajudar os usurios a
identificar novas necessidades.
Iterao infinita
Uma viso que, se o prottipo funciona, o servio completo pode estar
pronto amanh.
Definindo os atores
H alguns participantes que devem ter parte nos requisitos processo. Eles
representam trs grandes das partes interessadas grupos:
O negcio
A comunidade de usurios
A equipe de desenvolvimento do servio.
Tcito Explcito
Individual Habilidades, valores, Tarefas descrio do trabalhos,
tomado como certo metas, volumes e frequncias
intuio,
Corporativo Normas, para trs-histria, Procedimentos, guias de estilo,
cultura, Comunidades de processos, compartilhamento de
prtica conhecimento
Uma vez que o documento considerado como sendo completa, deve ser
analisado por representantes comerciais e confirmada como sendo uma
indicao verdadeira dos requisitos, neste ponto do tempo. Durante esta fase, os
revisores analisar os requisitos e pergunta se eles esto bem definida, clara e
completa.
Cada requisito na lista deve ser verificado para ver se ele est ou no bem
formado e A SMART (Especfico, mensurvel, atingvel, realista e oportuno).
Normas para a nomeao devem estar no lugar, por isso, por exemplo, se um
novo tipo de dados requerido num novo servio, Ento no h a necessidade
de utilizar os nomes que correspondam a estas normas. Um exemplo padro
pode ser 'todas as capitais, sem sublinhado e sem abreviaturas.
Uma vez que os dados tenham sido captado e armazenado, o prximo aspecto
a ser considerado a recuperao da informao a partir dos dados. Servios
para permitir o acesso fcil a dados estruturados atravs de ferramentas de
consulta de vrios nveis de sofisticao so necessrios a todas as
organizaes, e gerar as suas prprias exigncias arquitetnicas.
Estudo de viabilidade
Anlise
Projeto
Teste
Implementao
Avaliao
Manuteno.
A outra abordagem tem uma viso global de todos os servios para garantir a
contnua manuteno e gerenciamento da aplicaos:
A chave criar um projeto flexvel, de modo que fazer uma mudar no enviar os
desenvolvedores de todo o caminho de volta para o incio da fase de projeto. H
uma srie de abordagens que podem minimizar a chance de que isso acontea,
incluindo:
Tem diretrizs e estruturas que podem ser adotadas para determinar e definir as
sadas de projeto dentro do Gerenciamento de Aplicativos, como Capability
Maturity Model Integration (CMMI).
Estes incluem:
O RACI modelo ser benfico para permitir que as decises sejam tomadas com
ritmo e confiana. RACI um acrnimo para as quatro principais funes:
Atividade AR C Eu Eu C
1
Atividade A R C C C
2
Atividade Eu A R Eu C
6.4.3 Planner TI
Design de hardware
Design de software
Projeto ambiental
Projeto de processos
Design de dados.
Considerao deve ser dada aos requisitos exatos para a ferramenta. Quais so
os requisitos obrigatrios e quais so os requisitos desejados? Geralmente a
ferramenta deve apoiar os processos, e no o contrrio, para minimizar a
modificao dos processos para se adequar a ferramenta. Sempre que possvel,
melhor para comprar um instrumento totalmente integrado (embora no seja
custa da eficincia e eficcia) para apoiar a muitos (se no todos) Servio de
Gesto de processos. Se isto no for possvel, deve-se considerar que as
interfaces entre as diferentes ferramentas.
Nos estgios iniciais, a considerao tambm deve ser dada para a plataforma
sobre a qual a ferramenta que se espera que operar - Isto pode ser em hardware
e software existentes ou uma nova compra. Pode haver restries impostas por
TI estratgia - Por exemplo, todos os novos produtos podem ter a residir em
especfico servidors. Isto pode restringir o qual os produtos podem ser includos
na avaliao processo. Certifique-se de que a aquisio se encaixa dentro
existente aprovado oramentos.
Pode ser que a "progressos rpidos" devem ser implementadas a curto prazo
para melhorar a situao actual, mas estes processos melhorados podem ter
que ser descartado ou alterado, como parte das estratgias de mdio ou longo
prazo. Se "progressos rpidos" so implementadas, importante que eles no
devem ser realizados custa do longo prazo objetivos, assim que estes devem
ser considerados em todos os momentos. No entanto, cada organizao ter
que comear de algum lugar, eo ponto de partida ser sempre que a
organizao est agora em termos de TI Servio de Gesto de maturidade.
Uma vez que o viso e objetivos de alto nvel foram definidos, o provedor de
servios ento precisa analisar a situao actual, em termos do que processoes
esto no lugar ea maturidade da organizao. Os passos e atividades que
precisam ser concludas aqui so:
As aes de melhoria
A abordagem a adoptar e os mtodos a serem utilizados
Atividades e os prazos
Avaliao de risco e gesto
Recursos e oramentos
Papels e responsabilidades
Monitoramento, Medio e anlise.
Seis Sigma uma metodologia desenvolvida por Bill Smith na Motorola Inc., em
1986, e foi originalmente projetado para gerenciar variaes do processo que
causam defeitos, definidos como desvio inaceitvel da mdia ou de destino, e
trabalhar sistematicamente para a gesto variao de eliminar os defeitos. Seis
Sigma j cresceu alm do controle de defeitos e frequentemente utilizado para
medir a melhoria em TI execuo do processo. (Six Sigma uma marca de
servio registrada e marca registrada da Motorola Inc.)
Para mais informaes sobre a melhoria dos servios prticas, por favor,
consulte a publicao Melhoria de Servio Continuada.
Todos os ambientes
Garantir e piloto critrios e perodos
Critrios Responsabilidade
Ter a data do "go-live" e do prazo de garantia acordado com todas Alterar, Nvel de servio
as partes envolvidas, juntamente com os critrios de aceitao
finais?
Tem o SLA / SLR sido analisados, revisados e acordados com Nvel de servio
todas as partes interessadas?
Ter todos clientes e das partes interessadass foram identificados e Nvel de servio, Relao
registrados no CMS? Profissional
Tudo pode SLA / alvos SLR ser monitorado, medido, relatados e Nvel de servio,
revistos, incluindo disponibilidade e atuao? Disponibilidade
Ter todos usurios foram identificados / aprovada e suas contas Gesto de Contas
apropriadas criado por eles?
Ter todos os planos de teste foi completado com sucesso? Test Manager
Tenha tudo operacional contnuo carga de trabalhos e custars foi Operaes, TI Finanas
identificado e aprovado?
Localizao Primeiro andar, sempre que possvel, sem riscos de gua, gs, qumicos,
ou de fogo nas imediaes, acima, abaixo ou ao lado
A qualidade do ar Presso positiva, filtrada ingesto de poluio gasosa baixo (por exemplo,
o dixido de enxofre 0,14 ppm), os nveis de p de partculas de 1
micron>, menos do que 5 x 106 particles/m3. Desactivao automtica de
fumaa ou de deteco de incndio
Poder Unidade de Distribuio de Energia (PDU), com a oferta de trs fases para
no-switched caixas, uma por parte de equipamento, com as devidas
classificados disjuntores para cada oferta. Em alternativa, as tiras de
distribuio aprovados potncia pode ser utilizada. Equilibradas cargas
trifsicas. UPS (online ou linha interativa com Simple Network
Management Protocol (SNMP) Management) para garantir a tenso
fornecida de 5% da classificao com o impulso mnimo, quedas, picos
e mais / sob condies de tenso
Pisos falsos Antiesttica, ladrilhos elevvel 600 x 600 milmetros em pedestais, com
pedestais alternativas aparafusado ao cho slido. Mnimo de folga 600
milmetros para o cho slido. Cargas no cho de at 5kN/m2 com um
mnimo recomendado de 3 m entre o piso eo teto falso
Paredes internas Do cho ao teto falso, resistente ao fogo, mas com o fluxo de ar acima e
abaixo do nvel do cho
Deteco de HSSD ou VESDA alarme multi-nvel com auto FM200 (ou substituio
incndio / halon alternativa) a liberao de 'duplo-knock "deteco
preveno
Detectores Para fumaa, temperatura, potncia, umidade, gua e intruso com alarme
ambientais automtico capacidade. Locais painis de alarme com painis repetidores
e capacidade de alarme tambm remoto
Segurana da Terra limpa deve ser fornecido no PDU e para todos os equipamentos.
energia Com claramente marcado remotas de desligamento botes em cada
sada. Tomadas de energia suja, claramente marcado, tambm deve ser
fornecido
A qualidade do ar Presso positiva, filtrada ingesto de poluio gasosa baixo (por exemplo,
o dixido de enxofre 0,14 ppm), os nveis de p de partculas de 1
micron>, menos do que 5 x 106 particles/m3. Desactivao automtica de
fumaa ou de deteco de incndio
Poder PDU com alimentao trifsica no-switched caixas, uma por parte de
equipamento, com as devidas classificados disjuntores para cada oferta.
Em alternativa, as tiras de distribuio aprovados potncia pode ser
utilizada. Equilibradas cargas trifsicas. Sala de UPS para garantir a
tenso fornecida de 5% da classificao com o impulso mnimo,
quedas, picos e mais / sob condies de tenso
Pisos falsos Antiesttica, ladrilhos elevvel 600 x 600 milmetros em pedestais, com
pedestais alternativas aparafusado ao cho slido. Mnimo de folga 600
milmetros para o cho slido. Cargas no cho de at 5kN/m2 com um
mnimo recomendado de 3 m entre o piso eo teto falso
Paredes internas Do cho ao teto falso, resistente ao fogo, mas com o fluxo de ar acima e
abaixo do nvel do cho
Segurana da Terra limpa deve ser fornecido no PDU e para todos os equipamentos.
energia Com claramente marcado remotas de desligamento botes em cada
sada. Tomadas de energia suja, claramente marcado, tambm deve ser
fornecido
As conexes de O espao de equipamento deve ser cheias com fio com capacidade
rede adequada para um crescimento razovel. Todos os cabos devem ser
colocados e fixados a suportes de cabos adequados
Poder Fonte de energia limpa, com uma potncia fornecida pela UPS para o
rack completo
Pisos falsos Mnimo recomendado de 3 m entre o piso eo teto com todos os cabos
fixados no compartimento multi-trunking
Paredes internas Sempre que possvel todas as paredes devem ser resistentes ao fogo
As conexes de rede O espao de equipamento deve ser ligado com inundaes adequada
capacidade para crescimento razovel. Todos os cabos devem ser
colocados e fixados a suportes de cabos adequados
Pisos falsos Preferido, se possvel, mas todos os cabos devem estar contidos dentro
de trunking apropriado
.................................................. ........................
O acordo abrange o prviso e apoio dos servios do ABC, que ..... (Breve
servio descrio).
Este acordo vlido por 12 meses a partir da (data) at (data). O acordo ser
revisto anualmente. Pequenas mudanas podem ser registrados no formulrio,
no final do contrato, desde que sejam mutuamente aprovado pelos dois partidos
e gerida atravs do Gesto da Mudana processo.
Signatrios:
Descrio do servio:
O Servio de ABC consiste .... (Uma descrio mais completa para incluir
funes de negcio, entregas e todas as informaes relevantes para descrever
o servio e sua escala, impacto e prioridade para a negcio).
mbito do acordo:
Uma descrio das horas que o clientes pode esperar que o servio esteja
disponvel (por exemplo, 7 24 365, das 08:00 s 18:00 - de segunda a sexta-
feira).
Disponibilidade do servio:
Detalhes acordados de como e em que ponto isso vai ser medido e indicado, e
sobre o que concordou perodo tambm deve ser documentada.
Confiabilidade:
Atendimento ao cliente:
Detalhes de como entrar em contato com a Central de Servio, as horas que vai
estar disponvel, o apoio est disponvel e horas o que fazer fora do horrio de
obter assistncia (por exemplo, chamada de apoio, assistncia de terceiros, etc)
devem ser documentados. O SLA tambm podem incluir referncia a Internet /
Intranet Auto-ajuda e / ou registro de incidentes. Mtricos e medidas devem ser
includos, tais como metas de telefone de chamada de resposta (nmero de
toques, chamadas no atendidas, etc)
Metas para Incidente tempos de resposta (quanto tempo ser antes que algum
comea a atender o cliente - pode incluir o tempo de viagem, etc)
Nota. Em alguns casos, pode ser apropriado para fazer referncia para terceiros
contactos e contratos e OLAs - mas no como uma forma de desviar a
responsabilidade.
Detalhes dos contatos dentro de cada uma das partes envolvidas no acordo e
que a escalada processoes e pontos de contacto. Isto tambm deve incluir a
definio de uma denncia e procedimento para o gerenciamento de
reclamaes.
Desempenho do servio:
Gesto da Mudana:
Continuidade de servio:
Impresso:
Responsabilidades:
Glossrio:
Folha de alterao:
Deve notar-se que o SLA contedo dadas acima so apenas exemplos. Eles
no devem ser consideradas exaustivas ou obrigatria, mas eles fornecem um
bom ponto de partida.
.................................................. .......................
Signatrios:
Horas de servio:
Uma descrio das horas para que o servio seja prestado apoio.
Metas de servio:
Detalhes dos contatos dentro de cada uma das partes envolvidas no acordo e
que a escalada processos e pontos de contato.
Gesto da Mudana:
Gerenciamento de lanamento:
Gerenciamento de Configurao:
Gerenciamento de Disponibilidade:
Gerenciamento da Capacidade:
Gesto de Fornecedores:
Prviso de informaes:
Glossrio:
No Des Tip Ser Propr Unid Ser Imp Prior S Ho Cont Esca Rela Come Segur
me cri o vio ietri ade vice acto idad L ras atos lada trio ntrio ana
do o de de s de o da de Man nos e de A de Com Cont s de s de Classi
serv Serv ser apoi empr Neg age Neg neg ser erciai acto servi servi fica
io io vi o esa cio r (s) cio cios vi s s os os o
o (s) s (s) s o
Ser
vi
o1
Ser
vi
o2
Ser
vi
o3
Ser
vi
o4
Viso e direo
Processo
Pessoas
Tecnologia
Cultura.
Boa documentao
1 Introduo
Esta seo explica brevemente o pano de fundo desta questo do plano de
capacidade, como foi produzido eo que ele contm. Por exemplo:
2 Resumo de Gesto
Grande parte do plano de capacidade, por necessidade, contm detalhes
tcnicos que no de interesse para todos os leitores do plano. O resumo de
gesto deve destacar as principais questes, opes, recomendaes e custars.
Pode ser necessrio para produzir um resumo separado documento que contm
os pontos principais de cada uma das sees do plano principal
3 cenrios de negcios
necessrio colocar o plano em contexto da atual e previsto negcio ambiente.
Por exemplo, uma companhia area britnica planejado para mover um grande
nmero de funcionrios em seu edifcio-sede. Um rcio de 1,7 pessoas por
terminal desktop foi previsto. Gerenciamento da Capacidade foi alertado e foi
capaz de calcular o trfego de rede extra que seria o resultado.
5 Os mtodos utilizados
O Plano de Capacidade utiliza informaes recolhidas pelos sub-processos.
Esta sub-seo, portanto, deve conter detalhes de como e quando esta
informao foi obtida - por exemplo, previses de negcios obtido a partir de
planos de negcios, carga de trabalho previses obtidas a partir de clientes,
nvel de servio previses obtidas pelo uso de modelagem ferramentas
6 suposies feitas
importante que todas as suposies feitas, particularmente as relativas aos
drivers de negcio para a TI de Capacidade, so destaque no incio do plano. Se
eles so os pilares sobre os quais clculos mais detalhados so construdos,
ento vital que todos os interessados entender isso
7 resumo Servio
A seo de resumo de servio deve incluir:
10 Custos previstos
O custars associados com estas opes devem ser documentadas aqui. Alm
disso, o custo actual e prevista de fornecimento De servios de TIs devem ser
includas. Na prtica, Gerenciamento da Capacidade obtm grande parte desta
informao a partir da Gesto Financeira processo e do Plano Financeiro de TI.
1 CONTROLE DOCUMENTO
Este documento deve ser mantida para assegurar que os sistemas de infra-
estrutura e instalaes includos, apropriadamente, apoiar as empresas
recuperao requisitos.
1,2 re Documentoviso
2 INFORMAES DE APOIO
2.1 Introduo
1.
2.
Lista de siglas
AM Gerenciamento de Disponibilidade
CI Item de Configurao
TI Tecnologia da Informao
QA Garantia de Qualidade
TO Observation tcnica
UC Subjacente Contrato
UP Perfil do Usurio
Aplicao Software que fornece funes que so exigidas por um servio de TI.
Cada aplicao pode ser parte de mais do que um servio de TI. Um
aplicativo executado em um ou mais servidores ou clientes. Veja
tambm Gerenciamento de Aplicativos, Application Portfolio.
Brainstorming (Desenho de Servio) Uma tcnica que ajuda uma equipe a gerar
idias. As idias no so revisados durante a sesso de brainstorming,
mas numa fase posterior. Brainstorming muitas vezes usado pelo
Gerenciamento de Problemas para identificar as possveis causas.
Classificao O ato de atribuir uma categoria para algo. A classificao usada para
garantir uma gesto coerente e de relatrios. CIs, incidentes,
problemas, mudanas, etc, so geralmente classificados.
Componente Um termo geral que utilizado para significar uma parte de algo mais
complexo. Por exemplo, um sistema de computador pode ser um
componente de um Servio de TI, um aplicativo pode ser um
componente de uma Unidade de lanamento. Os componentes que
precisam ser gerenciados deve ser Itens de Configurao.
Componente Anlise (Desenho de Servio) Uma tcnica que ajuda a identificar o impacto da
de Impacto falha falha CI em servios de TI. A matriz criada com TI em uma
extremidade e IC, por outro. Isso permite a identificao de itens de
configurao crtica (que poderia causar o fracasso de mltiplos
servios de TI) e de Servios de TI (frgeis que tm vrios pontos
nicos de falha).
Base de configurao (Transio de Servio) Uma linha de base de uma configurao que
tenha sido formalmente aceite e gerido atravs do processo de
Gerenciamento de Mudana. A linha de base de configurao usado
como base para futuras Builds, Releases e alteraes.
Item de Configurao (Transio de Servio) qualquer componente que precisa de ser gerida
de forma a oferecer um servio de TI. As informaes sobre cada IC
registrada em um registro de configurao dentro do Sistema de
Gesto de Configurao e mantido durante todo seu ciclo de vida
pelo Configuration Management. CIs esto sob o controle de
Gerenciamento de Mudana. ICs tipicamente incluem servios de TI,
hardware, software, prdios, pessoas e documentao formal, como a
documentao do processo e SLAs.
Contramedida Pode ser usado para se referir a qualquer tipo de controlo. O termo de
contramedidas mais frequentemente usado quando se refere a
medidas que aumentar a resilincia, tolerncia a falhas ou a
confiabilidade de um servio de TI.
Fator Crtico de Algo que deve acontecer se um processo, projeto, plano ou Servio de
Sucesso TI ter sucesso. KPIs so usados para medir a realizao de cada
CSF. Por exemplo, uma LCR de "proteger Servios de TI ao fazer
alteraes" poderiam ser medidos por KPIs como "reduo percentual
de alteraes mal sucedidas", "percentagem de reduo Alteraes
causando incidentes", etc
Apto para o efeito Um termo informal usado para descrever um processo, Item de
Configurao, Servio de TI, etc, que capaz de cumprir os seus
objectivos ou nveis de servio. Estar apto para o efeito requer um
projeto adequado, implementao, controle e manuteno.
ISO 9001 Uma norma internacional para Sistemas de Gesto da Qualidade. Veja
tambm ISO 9000, Norma.
ISO / IEC 20000 ISO Especificao e Cdigo de Boas Prticas para o Gerenciamento
de Servios. ISO / IEC 20000 est alinhado com ITIL Best Practice.
Erro Conhecido (Operao de Servio) Um problema que tem uma causa raiz
documentada e uma soluo alternativa. Erros Conhecidos so criados
e gerenciados durante todo seu ciclo de vida pelo Gerenciamento de
Problemas. Erros conhecidos tambm pode ser identificado por
Desenvolvimento ou Fornecedores.
Linha de Servio (Estratgia de Servio) Um Core Service ou servio de apoio que tem
pacotes de mltiplos nveis de servio. Uma linha de servio
gerenciado por um gerente de produto e cada pacote de nvel de
servio projetado para suportar um determinado segmento de
mercado.
Gesto da Informao Informaes que so usadas para apoiar a tomada de deciso pelos
gestores. Gesto da informao muitas vezes gerado
automaticamente por ferramentas que suportam os diversos processos
de Gerenciamento de Servios. Gesto da Informao, muitas vezes
inclui os valores de KPIs como "porcentagem de alteraes que levam
a incidentes", ou "taxa de correo pela primeira vez".
Soluo manual Uma soluo que requer a interveno manual. Soluo manual
tambm usado como o nome de uma opo de recuperao em que
o Business Process Funciona sem o uso de servios de TI. Esta uma
medida temporria e normalmente combinada com outra opo de
Tempo mdio entre (Desenho de Servio) Uma Mtrica para medir e relatar Confiabilidade.
falhas MTBF o tempo mdio que um Item de Configurao ou Servio de TI
pode desempenhar sua funo acordada sem interrupo. Este
medido a partir de quando o servio de CI ou ele comea a trabalhar,
at que prximo falhar.
Tempo mdio entre (Desenho de Servio) A mtrica usada para medir e informar
Incidentes de Servio Confiabilidade. TMEIS o tempo mdio de quando um sistema ou
servio de TI falhar, at que prximo falhar. TMEIS igual ao MTBF +
MTRS.
Mean Time To Repair O tempo mdio para reparar um Item de Configurao ou Servio de
TI aps uma falha. MTTR medido a partir de quando o servio de CI
ou falhar at que seja consertado. MTTR no inclui o tempo
necessrio para recuperar ou restaurar. MTTR por vezes
incorretamente usado para significar tempo mdio para restaurar o
servio.
Tempo mdio para O tempo mdio para restaurar um Item de Configurao ou Servio de
restaurar o servio TI aps uma falha. MTRS medido a partir de quando o servio de CI
ou falhar at que seja totalmente restaurado e entregar a sua
funcionalidade normal. Veja tambm Manutenibilidade, Tempo mdio
para reparo.
Office of Government OGC dona da marca ITIL (direitos autorais e marca registrada). OGC
Commerce um departamento do Governo do Reino Unido que suporta a entrega
da agenda do governo de aquisies por meio de seu trabalho nos
contratos de colaborao e no aumento dos nveis de habilidades e
capacidade de aquisio dentro dos departamentos. Ele tambm
fornece suporte para complexos projetos do setor pblico.
Custo Operacional Custo resultante da execuo dos servios de TI. Muitas vezes,
repetindo pagamentos. Por exemplo os custos de pessoal,
manuteno de hardware e eletricidade (tambm conhecido como
"despesas correntes" ou "despesas receitas).
Ps-Implementao Uma reviso que ocorre depois de uma mudana ou um projeto foi
comentrio implementado. A PIR determina se a alterao ou projeto foi bem
sucedido, e identifica oportunidades de melhoria.
Pr-requisito para o Uma atividade que precisa ser concluda, ou uma condio que
sucesso precisa ser cumprida, para permitir a implementao bem sucedida de
um Plano ou processo. A PFS frequentemente uma sada de um
processo que uma entrada necessria para outro processo.
Proprietrio do Um papel responsvel por garantir que um processo est apto para o
Processo efeito. As responsabilidades do proprietrio do processo incluem
patrocnio, Design, Gesto de Mudana e melhoria contnua do
processo e suas mtricas. Este papel muitas vezes atribuda a
mesma pessoa que exerce a funo de Gerente de Processo, mas as
duas funes pode ser separado em organizaes maiores.
Processos de A ISO / IEC 20000 Processo de grupo que inclui Gesto de Negcios e
Relacionamento Gesto de Relacionamento Fornecedor.
Tempo de Resposta Uma medida do tempo necessrio para completar uma operao ou
transao. Usado em Gerenciamento da Capacidade como uma
medida do desempenho de TI Infra-estrutura, e em Gerenciamento de
Incidentes como uma medida do tempo necessrio para atender o
telefone, ou para iniciar Diagnstico.
Avaliao de Risco Os passos iniciais da gesto de risco. Analisando o valor dos ativos
para o negcio, identificando ameaas a esses ativos, e avaliar como
cada ativo vulnervel a essas ameaas. Avaliao de Risco pode ser
Design de Servios (Desenho de Servio) Uma fase no Ciclo de Vida de um Servio de TI.
Design de Servios inclui uma srie de processos e funes e o ttulo
de um dos ITIL Ncleo publicaes. Veja tambm Design.
Service Manager Um gestor que responsvel por gerenciar o ciclo de vida de ponta a
ponta de um ou mais servios de TI. O Gerenciador de Servios termo
tambm usado para significar qualquer gestor dentro do provedor de
servio de TI. Mais comumente usado para se referir a um Gerente de
Relacionamento de Negcios, Gerente de Processos, Gerente de
Contas ou um gerente snior com a responsabilidade de Servios de
TI em geral.
Ponto nico de falha (Desenho de Servio) qualquer item de configurao que pode causar
um incidente quando falha, e para os quais uma contramedida no foi
implementado. A SPOF pode ser uma pessoa, ou um passo em um
processo ou atividade, bem como um componente da infra-estrutura
de TI. Veja tambm falha.
A anlise SWOT (Melhoria de Servio Continuada) Uma tcnica que analisa e analisa
os pontos fortes e fraquezas internas de uma organizao e as
oportunidades e ameaas externas que enfrenta SWOT significa
Foras, Fraquezas, Oportunidades e Ameaas.
Terceiro Uma pessoa, grupo ou empresa que no faz parte do Acordo de Nvel
de Servio para um servio de TI, mas necessrio para garantir a
entrega bem sucedida do Servio de TI. Por exemplo, um fornecedor
de software, uma empresa de manuteno de hardware, ou um
departamento de instalaes. Requisitos para terceiros so
normalmente especificada na sustentao Contratos ou Acordos de
Nvel Operacional.
Limiar O valor de uma mtrica que deve causar um alerta a ser gerado, ou de
gesto a adoptar. Por exemplo "Incidente Prioridade 1 no resolvido
em quatro horas", "mais de cinco erros de disco moles em uma hora",
ou "mais de 10 mudanas no em um ms.
Custo Total de (Estratgia de Servio) Uma metodologia usada para ajudar a tomar
Propriedade decises de investimento. TCO avalia o Custo do Ciclo de Vida cheia
de possuir um item de configurao, no apenas o custo inicial ou
preo de compra.
Transao Uma funo discreta realizada por um servio de TI. Por exemplo
transferir dinheiro de uma conta bancria para outra. Uma nica
operao pode envolver inmeros acrscimos, supresses e
modificaes de dados. Ou todos estes completo com xito ou
nenhuma delas realizada.
Afinao A Atividade responsvel por planejar mudanas para tornar o uso mais
eficiente dos recursos. Tuning parte de Gesto de Desempenho, que
tambm inclui o monitoramento de desempenho e implementao das
mudanas necessrias.
Caso de Uso (Desenho de Servio) Uma tcnica usada para definir funcionalidade e
objectivos, e para projetar testes. Casos de Uso definir cenrios
realistas que descrevem as interaes entre usurios e um servio de
TI ou outro sistema.
Usurio Uma pessoa que usa o servio de TI em uma base dia-a-dia. Usurios
so distintos de clientes, como alguns clientes no usar o servio
diretamente.
Value for Money Uma medida informal de rentabilidade. Custo-benefcio muitas vezes
baseada em uma comparao com o custo de alternativas. Veja
tambm Anlise de Custo-Benefcio.
Vulnerabilidade Uma fraqueza que pode ser explorada por uma ameaa. Por exemplo,
uma porta de firewall aberto, uma senha que nunca alterado, ou um
tapete inflamvel. A falta de controle tambm considerado uma
vulnerabilidade.