Embed Size (px)
Citation preview
1 / 18
#interna
TERMO DE REFERÊNCIA – SOLUÇÕES DE TI
IMPORTANTE
O cronograma estipulado deverá ser cumprido rigorosamente pelos fornecedores. Eventuais modificações nos prazos poderão ocorrer a critério do Banco do Brasil.
Etapa Data
Publicação 25/09/2019
Recebimento de dúvidas 02/10/2019
Esclarecimento de dúvidas 09/10/2019
Recebimento da Resposta 16/10/2019
As dúvidas decorrentes da interpretação desta RFP deverão ser encaminhadas ao endereço eletrônico [email protected], sob o título: RFP – Contratação - OpenStack – DÚVIDA. As mensagens deverão conter a identificação da empresa, o nome do responsável e telefone para contato. Os esclarecimentos às dúvidas serão divulgados por esta mesma via.
A resposta do fornecedor a esta consulta, por meio de Proposta Comercial, deve ser encaminhada em meio digital para o endereço eletrônico citado acima, sob o título: RFP – Contratação - OpenStack – RESPOSTA, juntamente com a planilha de Precificação e qualquer documentação adicional julgada necessária.
A Proposta Comercial deverá apresentar preços com base/formato da tabela apresentada no item <nº do item no TR ou planilha de precificação> deste documento.
Apreciaríamos ainda, a apresentação, caso haja, de sugestões de qualquer natureza, inclusive com indicação de cenários alternativos que possam vir a configurar melhoria e/ou vantajosidade ao Banco do Brasil.
Objeto: Contratação de Licenças e Suporte para uso do OpenStack pelo período de
36 (trinta e seis) meses, prorrogáveis por até 60 (sessenta) meses.
2 / 18
#interna
ANEXO I – Especificações Técnicas e Condições de Prestação dos Serviços
1. Especificações Técnicas
Contratação de Licenças e Suporte para uso do OpenStack pelo período de 36 (trinta e
seis) meses, prorrogáveis por até 60 (sessenta) meses.
1.1. O OpenStack é uma plataforma de computação em nuvem que controla recursos de computação, armazenamento e rede em todo o datacenter. O software é projetado, em código aberto, para ambiente de IaaS (infraestrutura como serviço) e funciona com uma combinação de ferramentas/módulos para criar e gerenciar nuvens públicas e privadas. Em seu release Stein (10.04.2019), a plataforma possui 44 módulos conforme tabela e descrição abaixo:
Módulo Versão Descrição/Objetivo
Aodh 8.0.0 Desencadear ações, com base em regras definidas, sobre os dados de
amostra ou evento coletados pelo Ceilometer.
Barbican 8.0.0 Serviço de gerenciamento de chaves. Ele fornece armazenamento,
provisionamento e gerenciamento seguros de dados secretos, como
senhas, chaves de criptografia, certificados X.509 e dados binários
brutos.
Blazar 3.0.0
Serviço de reserva de recursos para o OpenStack. O Blazar permite
que os usuários reservem um tipo / quantidade de recursos específicos
por um período de tempo específico e os alocam para os usuários com
base em suas reservas.
Ceilometer 12.0.0 Coleta, normaliza e transforma os dados produzidos pelos serviços do
OpenStack. Os dados coletados destinam-se ao uso para criar
diferentes visualizações e ajudar a resolver vários casos de uso de
telemetria.
Cinder 14.0.0
Serviço de armazenamento em bloco para o OpenStack. Ele virtualiza
o gerenciamento de dispositivos de armazenamento em bloco e
fornece aos usuários finais uma API de autoatendimento para solicitar
e consumir esses recursos sem exigir conhecimento de onde o
armazenamento deles está realmente implantado ou em que tipo de
dispositivo. Isso é feito através do uso de uma implementação de
referência (LVM – Logical Volume Manager) ou drivers de plug-in para
outro armazenamento.
Cloudkitty 9.0.0 Serviço projetado para converter métricas em preços. O CloudKitty
suporta vários coletores, várias políticas de classificação e várias
saídas.
Congress 9.0.0 Destinado a efetuar políticas de governança. Com o congress é
possível declarar, monitorar, implementar e auditar as políticas de
governança definidas para a nuvem.
Cyborg 2.0.0
Visa fornecer uma estrutura de gerenciamento de propósito geral para
recursos de aceleração (ou seja, vários tipos de aceleradores como
GPU, FPGA, ASIC, NP, SoCs, SSDs NVMe / NOF, ODP, DPDK /
SPDK e assim por diante).
3 / 18
#interna
Designate 8.0.0
Serviço DNSaaS (DNS como serviço) para o OpenStack. Ele fornece
uma API REST com autenticação integrada do Keystone. Pode ser
configurado para gerar automaticamente registros com base nas ações
do Nova e Neutron. O Designate suporta uma variedade de servidores
DNS, incluindo o Bind9 e o PowerDNS.
Ec2-api 8.0.0 O EC2API é uma camada de compatibilidade para o serviço de API do
Amazon EC2 no OpenStack.
Freezer 7.0.0
O Freezer é um distributed backup restore and disaster recovery como
uma plataforma de serviço. Ele foi projetado para ser multi OS (Linux,
Windows, OSX, * BSD), focado em fornecer eficiência e flexibilidade
para backups baseados em block, backups incrementais baseados em
arquivos, ações point-in-time, sincronização de jobs (ou seja,
sincronização de backup em múltiplos nós ) e muitos outros recursos.
Destina-se a ser útil para todos os ambientes, incluindo grandes
nuvens efêmeras.
Glance 18.0.0
Serviço de imagem que inclui a descoberta, registro e recuperação de
imagens de máquinas virtuais. O Glance tem uma API RESTful que
permite a consulta de metadados de imagem de VM, bem como a
recuperação da imagem real. Imagens de VM disponibilizadas através
do Glance podem ser armazenadas em uma variedade de locais,
desde sistemas de arquivos simples até sistemas de armazenamento
de objetos, como o projeto OpenStack Swift.
Heat 12.0.0
Orquestrador de recursos de infraestrutura para aplicações em nuvem
baseado em modelos na forma de arquivos de texto que podem ser
tratados como código. O Heat fornece uma API ReST nativa do
OpenStack e uma API de consulta compatível com o CloudFormation.
O Heat também fornece um serviço de escalonamento automático que
se integra aos serviços de telemetria do OpenStack.
Horizon 15.0.0 A Dashboard do OpenStack é extensível e fornece uma interface de
usuário baseada na Web para os serviços do OpenStack.
Ironic 12.0.0
Módulo que fornece máquinas bare-metal (em oposição a virtuais). Ele
pode ser usado independentemente ou como parte de uma nuvem
OpenStack e integra-se aos serviços OpenStack Identidade
(Keystone), Computação (Nova), Rede (Neutron), Imagem (Glance) e
Objeto (Swift). Quando o serviço Bare Metal é configurado
adequadamente com os serviços de computação e de rede, é possível
provisionar máquinas virtuais e físicas por meio da API do serviço de
computação.
Karbor 1.2.0
O Karbor lida com a proteção dos dados e meta-dados que abrangem
um aplicativo OpenStack contra perda / dano através de uma estrutura
padrão de APIs e serviços que permite que os fornecedores
introduzam vários serviços de proteção de dados em um fluxo coerente
e unificado para o usuário.
Keystone 15.0.0 Serviço de autenticação des clientes e dos módulos do OpenStack.
Essa API de indentidade do OpenStack suporta LDAP, OAuth, OpenID
Connect, SAML e SQL.
Magnum 8.0.0 O Magnum disponibiliza os mecanismos de orquestração de
contêineres, como Docker Swarm, Kubernetes e Apache Mesos, como
recursos de primeira classe no OpenStack. A Magnum usa o Heat para
4 / 18
#interna
orquestrar uma imagem do sistema operacional que contenha o Docker
e o Kubernetes e executa essa imagem em máquinas virtuais ou bare-
metal em uma configuração de cluster.
Manila 8.0.0
Serviço de compartilhamento de arquivos do OpenStack. O Manila
fornece o gerenciamento de compartilhamentos de arquivos, por
exemplo, NFS e CIFS como um serviço principal para o OpenStack. O
Manila trabalha com uma variedade de matrizes e dispositivos de
armazenamento de backend proprietários, com sistemas de arquivos
distribuídos de código aberto, bem como com um servidor Linux NFS
ou Samba.
Masakari 7.0.0 Fornece o serviço de alta disponibilidade de instâncias para nuvens
OpenStack recuperando automaticamente instâncias com falha.
Mistral 8.0.0
Serviço de fluxo de trabalho. Utiliza arquivos YAML para gerenciar o
estado, ordem de execução correta, paralelismo, sincronização e alta
disponibilidade.
Monasca-api 2.8.0 O Monasca é uma solução de monitoramento de serviços multi-
inquilino, escalável, de alto desempenho e tolerante a falhas, que se
integra ao OpenStack. Ele usa uma API REST para processamento e
consulta de métricas de alta velocidade e possui um mecanismo de
alarme de fluxo contínuo e um mecanismo de notificação.
Monasca-events-
api 0.2.0
Monasca-log-api 2.8.0
Murano 7.0.0 O Murano permite que desenvolvedores de aplicativos e
administradores de nuvem publiquem vários aplicativos prontos para
nuvem em um catálogo navegável. O Murano usa o OpenStack Heat
para orquestrar recursos de infraestrutura para o aplicativo.
Neutron 14.0.0 Projeto de rede SDN focado no fornecimento de rede como serviço
(NaaS) em ambientes virtuais de computação.
Nova 19.0.0 Implementação de serviços e bibliotecas associadas para fornecer
acesso de autoatendimento massivamente escalonáve, sob demanda,
para computar recursos, incluindo bare metal, máquinas virtuais e
contêineres.
Octavia 4.0.0 Solução de balanceamento de carga que gerencia uma frota de
máquinas virtuais, contêineres ou servidores bare metal que são
ativados sob demanda.
Panko 6.0.0
Fornece um serviço de armazenamento de eventos de indexação de
metadados, que permite aos usuários capturar as informações de
estado dos recursos do OpenStack em um determinado momento. Seu
objetivo é permitir um meio escalonável de armazenar dados de curto e
longo prazo para casos de uso, como auditoria e depuração do
sistema.
Placement 1.0.0 Fornece uma API HTTP usada para rastrear provedores de recursos,
inventários e usos.
Qinling 2.0.0 Qinling é o FAAS - função como um serviço para o OpenStack. Este
projeto visa fornecer uma plataforma para suportar funções sem
servidor (como o AWS Lambda).
Sahara 10.0.0 Fornece aos usuários um meio simples de provisionar estruturas de
processamento de dados (como Hadoop, Spark e Storm) no
OpenStack. Isso é realizado especificando os parâmetros de
configuração, como a versão do framework, a topologia do cluster,
5 / 18
#interna
detalhes do hardware do nó entre outros.
Searchligth 6.0.0 O projeto Searchlight fornece recursos de indexação e pesquisa nos
recursos do OpenStack. Seu objetivo é obter alto desempenho e
consultas flexíveis combinadas com indexação quase em tempo real.
Senlin 7.0.0 Senlin é um serviço de cluster para nuvens OpenStack. Cria e opera
clusters de objetos homogêneos expostos por outros serviços do
OpenStack. O objetivo é facilitar a orquestração de coleções de objetos
semelhantes.
Solum 6.0.0
O Solum é projetado nativamente para nuvens OpenStack e aproveita
vários outros projetos da plataforma. Vários ambientes de multi-
linguagem são suportados com uma solução modular de "pacote de
linguagem" para que se possa executar facilmente aplicativos escritos
em qualquer linguagem de sua escolha.
Storlets 3.0.0 O Openstack Storlets é uma extensão do Openstack Swift, que permite
executar código definido pelo usuário dentro do armazenamento de
objetos de maneira segura e isolada por meio do uso de contêineres do
Docker.
Swift 2.20.0 O Swift é um módulo de armazenamento de objeto. É construído para
dimensionamento e otimizado para durabilidade, disponibilidade e
simultaneidade em todo o conjunto de dados. Swift é ideal para
armazenar dados não estruturados que podem crescer sem limite.
Tacker 1.0.0
O Tacker fornece um gerenciador VNF (VNFM – Virtual Network
Function Manager) e um orquestrador NFV (NFVO – Network
Functions Virtualization Orquestration) para implantar e operar os
Serviços de Rede e as Funções de Rede Virtual (VNFs) em uma
plataforma de infraestrutura NFV como o OpenStack. Ele é baseado no
ETSI MANO Architectural Framework e fornece uma pilha funcional
para orquestrar os serviços de rede de ponta a ponta usando VNFs.
Tricircle 6.0.0
Fornece automação de rede em todo o Neutron em implantações de
várias regiões do OpenStack. Casos de uso incluem alta
disponibilidade de aplicativos, ISPs duplos para redundância de links
de internet, isolamento de tráfego leste-oeste, rede cruzada Nuetron L2
para NFV e expansão de capacidade de nuvem.
Trove 11.0.0 O Trove é um mecanismo de banco de dados relacional e não
relacional de provisionamento de banco de dados como serviço.
Vitrage 4.0.0 O Vitrage é o serviço OpenStack RCA (Root Cause Analysis) para
organizar, analisar e expandir os alarmes e eventos do OpenStack,
fornecendo insights sobre a causa raiz dos problemas e deduzindo sua
existência antes que eles sejam detectados diretamente.
Watcher 2.0.0 O Watcher fornece um serviço de otimização de recursos flexível e
escalonável para nuvens baseadas em OpenStack. O Watcher fornece
um loop de otimização completo, incluindo um receptor de métricas,
processador de otimização e um aplicador de plano de ação.
Zaqar 8.0.0
O Zaqar é um serviço de mensageria para desenvolvedores Web e
mobile. O serviço apresenta uma API totalmente RESTful, que os
desenvolvedores podem usar para enviar mensagens entre vários
componentes de seus aplicativos SaaS (software como serviço) e
mobile. Os operadores de nuvem podem aproveitar o Zaqar para
fornecer equivalentes de SQS e SNS aos seus clientes.
6 / 18
#interna
Zun 3.0.0
O Zun fornece uma API do OpenStack para iniciar e gerenciar
contêineres respaldados por diferentes tecnologias de contêiner.
Diferente do Magnum, o Zun é para usuários que desejam tratar
contêineres como um recurso gerenciado pelo OpenStack. Os
contêineres gerenciados pelo Zun devem estar bem integrados com
outros recursos do OpenStack, como a rede Neutron e o volume
Cinder. Os usuários recebem APIs simplificadas para gerenciar
contêineres sem a necessidade de explorar as complexidades de
diferentes tecnologias de contêiner.
1.2. Os módulos core da Plataforma OpenStack - definidos pela OpenStack Foundation
(responsável pela administração da distribuição comunitária) são os listados a seguir:
Keystone – Identity;
Nova – Compute;
Glance – Image;
Neutron – Network;
Cinder - Block Device;
Heat – Orchestration;
Aodh – Alarm;
Gnocchi – Metrics;
Ceilometer – Metrics;
Octavia - Load Balancer;
Magnum – Kubernetes;
Trove – Database;
Designate – DNS;
Ironic – Baremetal;
Barbican – Secret;
Sahara - Integration –HADOOP;
Karbor - Integration -Disaster Recovery;
Freeze -Integration –Backups;
Cloudkitty - Billing
Horizon – Dashboard.
O licenciamento, instalação e suporte da plataforma OpenStack deve contemplar no mínimo
os módulos relacionados acima.
7 / 18
#interna
1.3. A PROPONENTE deverá fornecer o OpenStack – última versão estável em todos os
seus componentes, em ambiente virtualizado e bare metal, em ambiente multicluster e
multirregião.
1.4. A PROPONENTE deverá fornecer a subscrição do Sistema Operacional a ser suportado
pelo Openstack fornecido.
2. Descrição e Condições de Prestação dos serviços:
2.1. O serviço objeto deste ANEXO I compreende a Prestação de Serviços de Suporte Técnico
sob demanda para todos os componentes da Plataforma OpenStack - Última versão
estável, instalada na Diretoria de Tecnologia do Banco do Brasil – Brasília/DF (DITEC).
2.2. A PROPONENTE deverá assegurar, durante a vigência contratual, o perfeito e integral
funcionamento dos sistemas sem ônus adicionais para o BANCO.
2.3. As atividades de Prestação de Serviços de Suporte Técnico sob demanda descritas
adiante deverão ser prestadas pela PROPONENTE nas 24 horas de todos os dias da
semana, de segunda a domingo, incluindo feriados.
2.4. O PROPONENTE deverá:
2.4.1. Garantir a prestação dos serviços dentro dos níveis mínimos exigidos, conforme
especificados no Anexo II.
2.4.2. Manter à disposição do Banco, durante todo o período do contrato, histórico
atualizado das manutenções e suporte dos recursos. Os relatórios deverão ser
enviados ao BANCO via e-mail, mensalmente até o dia 10, ou próximo dia útil, e
sempre que solicitados.
2.4.3. Assegurar que o software se mantenha totalmente operacional garantindo que
todas as suas funcionalidades estejam disponíveis para os operadores desse.
2.4.4. Indicar todas as atualizações de software que se façam necessárias para o sistema
e indicar correções de eventuais problemas apresentados quando das atualizações.
2.4.5. Disponibilizar canal de atendimento por meio de serviço telefônico gratuito do tipo
“0800”, e-mail ou site na Web, 24 (vinte e quatro) horas por dia, 7 (sete) dias por
semana, incluindo feriados, para:
2.4.5.1. Abertura (registro) e acompanhamento de chamados técnicos;
8 / 18
#interna
2.4.5.2. Esclarecimento de dúvidas, dando suporte aos usuários na operação e
utilização das facilidades da plataforma;
2.4.5.3. Respostas a consultas;
2.4.5.4. Solução de problemas.
2.4.6. Fornecer protocolos numerados para cada chamado registrado pelo Banco no
canal de atendimento, com anotação da data e hora de sua abertura. O número do
protocolo deverá ser informado no ato do registro do chamado.
2.4.6.1. O chamado do Banco permanecerá aberto até que a PROPONENTE
solucione o incidente e providencie o encerramento do chamado com o
respectivo aceite do Banco. Para dar a concordância no fechamento do
chamado, o Banco verificará se o incidente foi solucionado, caso não tenha sido,
o chamado permanecerá aberto e os prazos serão contados a partir da abertura
original do chamado técnico.
2.5. Os serviços de Suporte Técnico deverão ser prestados por técnicos devidamente
habilitados e credenciados, que estarão sujeitos às políticas de Segurança do Banco.
2.6. A PROPONENTE encarregar-se-á de fornecer, para utilização de seus técnicos, qualquer
equipamento, inclusive os de testes, necessários a execução das atividades, que deverão
ser mantidos em plenas condições de uso e funcionamento durante a vigência do contrato,
sem prejuízo de aquisição de outros equipamentos que se fizerem necessário;
2.7. A PROPONENTE, a critério do Banco, deverá substituir, no prazo de até 30 dias, o
profissional, por deficiência técnica identificada ou ocorrência relativa à postura e/ou
comportamento profissional, reclamados pelos usuários internos.
2.8. Ao final de cada intervenção, a PROPONENTE entregará ao Banco um relatório
circunstanciado do atendimento, mencionando os defeitos verificados, as providências
adotadas, as recomendações e orientações técnicas e o tempo despendido no
atendimento. O relatório deverá conter as assinaturas do técnico da PROPONENTE e do
funcionário comissionado do Banco.
2.9. A critério do Banco do Brasil e sempre que este julgar necessário, a PROPONENTE
deverá:
9 / 18
#interna
2.9.1. Prestar ao Banco, sempre que este solicitar, informações, orientações e
esclarecimentos relativos ao funcionamento, instalação, configuração e administração
do sistema;
2.9.2. A critério do Banco, as respostas às solicitações poderão ser atendidas pela
PROPONENTE por escrito ou mediante a visita de técnico habilitado pelo fabricante
nas localidades onde os sistemas estiverem instalados, sem custos adicionais para o
Banco.
2.10. Composição dos Sistemas e Locais de Prestação dos Serviços.
SITE COMPONENTE/
ESPECIFICAÇÃO ENDEREÇO
INICIO DA
PRESTAÇÃO DE
SERVIÇOS
DITEC - DF
Subscrição de licenças
OpenStack
Última versão estável
STN 716 Conjunto C - 1. andar
- Ala Sul - Asa Norte –
Brasília/DF - CEP: 70770-910
A partir da assinatura do
contrato
DITEC - DF
Suporte à Plataforma
OpenStack
Última versão estável
STN 716 Conjunto C - 1. andar
- Ala Sul - Asa Norte –
Brasília/DF - CEP: 70770-910
A partir da assinatura do
contrato
DITEC - DF
Subscrição do Sistema
Operacional suportado à
Plataforma OpenStack
Última versão estável
STN 716 Conjunto C - 1. andar
- Ala Sul - Asa Norte –
Brasília/DF - CEP: 70770-910
A partir da assinatura do
contrato
10 / 18
#interna
Anexo II – NMSE – Níveis Mínimos de Serviços Exigidos
Definições da Prestação de Serviço
1. Escopo dos Serviços
1.1. Os Níveis Mínimos de Serviço Exigidos (NMSE) definem os termos e as condições
sob as quais a PROPONENTE deverá prover os serviços de Suporte Técnico da
Plataforma OpenStack – Última versão estável, sob demanda, instalados nas
dependências do BANCO para quaisquer atividades elencadas no escopo deste
documento.
1.2. A PROPONENTE assumirá a inteira responsabilidade pelo funcionamento e
disponibilidade dos serviços contratados e reconhece que o não atendimento dos
níveis de serviços contratados pode resultar em impacto adverso e relevante nos
negócios e nas operações do BANCO, ficando a PROPONENTE, portanto, sujeita às
sanções previstas neste documento, bem como às sanções da Lei número 13.303, de
30 de junho de 2016.
1.3. A PROPONENTE deverá prestar os serviços descritos para a totalidade de produtos
relacionados na RFP e nas condições estabelecidas neste documento.
1.4. A PROPONENTE ficará desobrigada do cumprimento dos níveis de serviço enquanto
a prestação de serviços estiver prejudicada em função de impedimento ou retardo
decorrente de responsabilidade comprovada do BANCO.
1.5. Os níveis de serviço definidos neste documento serão apurados mensalmente.
11 / 18
#interna
2. Suporte ao Cliente
2.1. A PROPONENTE deverá disponibilizar canal de atendimento por meio de serviço
telefônico gratuito do tipo “0800”, e-mail ou site na Web, 24 (vinte e quatro) horas por
dia, 7 (sete) dias por semana, incluindo feriados, para:
2.1.1. Abertura (registro) e acompanhamento de chamados técnicos;
2.1.2. Esclarecimento de dúvidas, dando suporte aos usuários na operação e
utilização das facilidades dos sistemas;
2.1.3. Respostas a consultas;
2.1.4. Solução de problemas.
2.2. A PROPONENTE fornecerá suporte técnico com atendimento dentro do período de 24
(vinte e quatro) horas, 07 (sete) dias por semana, incluindo feriados atuando na
resolução de problemas e configurações necessárias, não sendo admitidas quaisquer
formas de acesso remoto aos sistemas a partir de ambientes externos ao Banco.
2.3. A cada chamado registrado pelo BANCO DO BRASIL, a PROPONENTE deverá
fornecer protocolos numerados, com anotação da data e hora de abertura dos
chamados, que serão utilizados para o cálculo do tempo de atendimento dos
chamados.
2.4. A PROPONENTE deverá prestar os serviços de suporte técnico nas dependências do
BANCO DO BRASIL, onde os equipamentos estiverem instalados, incluindo o
transporte de equipamentos, peças e mão de obra.
2.5. Os serviços de Suporte Técnico deverão ser prestados por técnicos devidamente
habilitados e credenciados, que estarão sujeitos às políticas de Segurança do Banco.
2.6. Em todas as atividades do serviço de atendimento e suporte técnico, os profissionais
da PROPONENTE deverão utilizar a língua portuguesa, exceto no uso de termos
técnicos e na utilização de textos técnicos, que poderão estar redigidos no idioma
inglês.
2.7. A PROPONENTE deverá solucionar os problemas de funcionamento incorreto do sistema, de
acordo com a classificação de criticidade a seguir:
Criticidade Ocorrência
C0 Indica que 1 (um) ou mais módulos core estão com inoperância total das
funcionalidades ou facilidades do serviço.
C1 Indica que 1 (um) ou mais módulos core estão com inoperância parcial
12 / 18
#interna
das funcionalidades ou facilidades do serviço.
C2
Indica inoperância total ou parcial das funcionalidades ou facilidades do
serviço de 1 (um) ou mais módulos não core. Nesta criticidade, incluem-
se, também, falha de componentes ou módulos isolados que não
resultem em restrições substanciais de um serviço, as solicitações de
mudança, reprogramações e dúvidas técnicas.
2.8. Após o primeiro retorno e a devida análise do problema, a criticidade poderá ser
redefinida pela PROPONENTE em comum acordo com o BANCO.
2.9. A criticidade do incidente somente poderá ser alterada para nível mais baixo que o
nível atual com o respectivo aceite do BANCO DO BRASIL e, neste caso, o prazo
para solução do incidente contará a partir da abertura original do chamado. Caso o
impacto de um incidente já aberto evolua para uma criticidade mais alta, a criticidade
deve ser alterada para refletir a nova situação e, neste caso, o prazo para solução do
incidente contará a partir da alteração da criticidade.
2.10. O chamado do BANCO DO BRASIL permanecerá aberto até que a PROPONENTE
solucione o incidente e providencie o encerramento do chamado com o respectivo
aceite do BANCO DO BRASIL. Para dar a concordância no fechamento do chamado,
o BANCO DO BRASIL verificará se o incidente foi solucionado. Caso não tenha sido
solucionado, o chamado permanecerá aberto e os prazos serão contados a partir da
abertura inicial do chamado.
2.11. Ao final de cada intervenção, a PROPONENTE deverá entregar ao BANCO DO
BRASIL, um relatório circunstanciado do atendimento do chamado técnico,
mencionando o diagnóstico com defeitos verificados, as providências adotadas e/ou
implementadas, as recomendações/ orientações técnicas e o tempo despendido no
atendimento. O relatório deverá conter as assinaturas do técnico da PROPONENTE e
do funcionário comissionado do BANCO DO BRASIL.
13 / 18
#interna
3. Pontos de Contato e Escalamento
3.1. A PROPONENTE deve informar ao BANCO, em até 30 (trinta) dias corridos após a
assinatura do Contrato, uma lista de contatos com os níveis hierárquicos internos,
similares à hierarquia da PROPONENTE, contendo os respectivos nomes e telefones
(inclusive celulares), e deve manter essa relação atualizada.
4. Responsabilidades do PROPONENTE
4.1. A PROPONENTE será responsável por indicar todas as atualizações do software,
considerando o incremento de releases, desde que dentro da atual distribuição;
A PROPONENTE deve prestar ao BANCO DO BRASIL, sempre que este solicitar,
informações, orientações e esclarecimentos relativos ao funcionamento, instalação,
configuração e administração da Plataforma OpenStack – Última versão estável;
4.2. Havendo descumprimento de qualquer nível de serviço, sem prejuízo da aplicação
dos descontos previstos, a PROPONENTE deverá investigar e relatar as causas dos
incidentes, bem como tomar medidas preventivas apropriadas para evitar
reincidências.
5. Relatórios de Níveis de Serviço
5.1. A PROPONENTE deve utilizar ferramentas e procedimentos de avaliação e
monitoração capazes de avaliar e reportar o desempenho dos serviços em relação
aos níveis de serviço estabelecidos, consolidando e entregando ao BANCO DO
BRASIL relatórios com informações gerenciais e de acompanhamento do atendimento
dos Níveis de Serviço contratados.
5.2. A entrega deverá ser realizada por meio eletrônico (e-mail), até o 10º (décimo) dia útil
do mês subsequente ao período apurado.
5.3. O formato do relatório deverá ser definido entre a PROPONENTE e o BANCO DO
BRASIL, e deverá prover, no mínimo, as seguintes informações:
a. Número de abertura do chamado;
b. Data e hora de abertura/reabertura do chamado;
c. Data e hora do início do atendimento
14 / 18
#interna
d. Data e hora da aplicação da solução (Contorno ou Definitiva);
e. Tipo de solução aplicada (Contorno ou Definitiva);
f. Data e hora do fechamento do chamado;
g. Nível de Criticidade;
h. Descrição do problema;
i. Descrição da solução;
j. Tempo de recuperação operacional (TRO);
k. Tempo excluído (tempo com pendência do Banco do Brasil, a ser validado).
l. Identificação do (s) equipamento (s) impactado (s) no chamado.
m. Tempo de atendimento.
5.4. A PROPONENTE deve disponibilizar ao BANCO DO BRASIL, informações sobre o
andamento dos atendimentos técnicos, e quaisquer outras informações que se façam
necessárias, no prazo máximo de 72 (setenta e duas) horas.
5.5. A não apresentação dos relatórios de níveis de serviços por parte da PROPONENTE
a sujeitará aos descontos, conforme indicador NMSE.
6. Regra de aplicação de desconto
6.1. No que diz respeito ao não atendimento das obrigações relativas aos níveis de
serviço, a PROPONENTE deverá apresentar descontos na fatura no mês
subsequente ao da violação dos níveis de serviço.
6.2. A incidência do desconto será sobre o valor mensal da fatura de serviços.
6.3. O desconto total mensal será calculado pela soma de todos os descontos apurados
em cada indicador.
6.4. Os descontos calculados para os níveis de serviço estão limitados a 20% do valor
faturado mensal.
6.5. A PROPONENTE previamente autoriza o BANCO a descontar o montante dos valores
por ele devidos, conforme indicadores NMSE.
15 / 18
#interna
6.6. Havendo descumprimento de qualquer nível de serviço, sem prejuízo da aplicação
dos descontos previstos, a PROPONENTE deverá tomar medidas preventivas
apropriadas para evitar reincidências.
7. Definições de indicadores de qualidade
7.1. Descrição do Indicador – Tempo de Recuperação Operacional – TRO
7.1.1. Representa o tempo máximo tolerado pelo BANCO DO BRASIL para
restabelecimento operacional do serviço interrompido, seja solução temporária ou
definitiva.
7.1.2. A medição deste período corresponde ao tempo decorrido entre o início do
chamado técnico até o fechamento do chamado com o aceite do BANCO DO
BRASIL.
7.1.3. Serão excluídos do período de indisponibilidade os tempos relativos a
impedimento ou retardo comprovadamente causados pelo BANCO. Estes tempos
deverão ser validados pelo Fiscal de serviço nomeado pelo BANCO.
7.1.4. O tempo de resolução dos incidentes será contabilizado de forma, ininterrupta a
partir da abertura do chamado técnico, devido sua maior urgência e impacto.
7.2. Métrica
TRO = (DHR – DHA) – TPBB
DHR = Data, hora e minuto do encerramento da ocorrência.
DHA = Data, hora e minuto da abertura da ocorrência.
TPBB = Tempo de pendência do Banco do Brasil. (A ser validado pelo BANCO)
7.3. Periodicidade de Medição
Mensal, por evento.
7.4. Meta
Criticidade TRO
C0 2 hora
16 / 18
#interna
C1 4 hora
C2 24 horas
7.5. Descontos
Criticidade Evento de quebra da
meta
Persistência de
quebra(hora ou
fração)
C0 3,0% 1,00%
C1 2,0% 0,50%
C2 1,0% 0,25%
Os descontos serão aplicados sobre o valor da fatura mensal do serviço.
7.6. Descrição do Indicador
7.6.1. Entrega de Relatório Gerencial – ERG
Este indicador verifica se os relatórios mensais de acompanhamento dos níveis
de serviço foram entregues/disponibilizados no prazo estipulado.
7.7. Métrica
ERG = DEE – DPE
ERG = Entrega de relatórios.
DPE = Data prevista da entrega.
DEE = Data da efetiva entrega.
7.8. Periodicidade de Medição
Mensal
7.9. Meta
Até o 10º dia útil do mês subsequente à apuração
17 / 18
#interna
7.10. Descontos
0,5% do valor da fatura mensal, por dia de atraso.
18 / 18
#interna
8. Vigência
O período de vigência é de 36 (trinta e seis) meses, prorrogável por até 60 meses.
9. Forma de entrega do Nível de serviço
9.1. Descrição do Indicador
9.1.1. A PROPONENTE deverá utilizar ferramenta de atendimento disponibilizada
pelo BANCO para recebimento de demandas, relatório das atividades e
declaração de conclusão.
9.1.2. Serão excluídos do período de indisponibilidade os tempos relativos a
impedimento ou retardo comprovadamente causados pelo BANCO. Estes tempos
deverão ser validados pelo Fiscal de serviço nomeado pelo BANCO.
9.1.3. O tempo de resolução dos incidentes será contabilizado de forma, ininterrupta a
partir da abertura do chamado técnico, devido sua maior urgência e impacto.
9.1.4. A critério do BANCO, as demandas serão formalizadas via e-mail corporativo.
9.1.5. A PROPONENTE pode a qualquer momento acessar a ferramenta pelo
ambiente de trabalho fornecido pelo BANCO.
9.1.6. O BANCO pode utilizar quaisquer informações transitadas com a
PROPONENTE para aferição e cobrança do Nível de Serviço, incluindo, mas não
se limitando a:
- Data, hora, conteúdo, remetentes E destinatários de e-mail;
- Data, hora, conteúdo, relatório de trabalho, remetentes e destinatários da
ferramenta de atendimento ARS.
