TERMO DE REFERÊNCIA
Objeto
Aquisição de soluções de software de Gestão e Planejamento de Capacidade
e Gerenciamento de Desempenho de Aplicações (Application
Performance Management - APM) para todo o ambiente físico, virtual e de
armazenamento (SAN, NAS e Mainframe), contemplando Licenças de Uso,
Instalação, Configuração e Migração de dados, Operação Assistida (hands-on),
Treinamento e Manutenção e Suporte Técnico 24x7.
Tabela de Itens
Item
1
1.1
Características
Quantidade
Solução de Software de Gestão e Planejamento
de Capacidade
Requisitos do(s) componente(s) da solução
De acordo com
“Ambiente Atual
Prodam”
1.4
Licenças de uso contemplando o cenário descrito no
item “Ambiente Atual PRODAM”
Serviços de Instalação, Configuração e Migração de
dados
Operação Assistida (Hands-on) – 90 dias
1.5
Treinamento
7
1.6
Manutenção e Suporte Técnico 24x7 – 36 meses
Solução de Software de Gerenciamento de
Desempenho
de
Aplicações
(Application
Performance Management - APM)
Requisitos do(s) componente(s) da solução
1
De acordo com
“Ambiente Atual
Prodam”
2.4
Licenças de uso contemplando o cenário descrito no
item “Ambiente Atual PRODAM”
Serviços de Instalação, Configuração e Migração de
dados
Operação Assistida (Hands-on) – 90 dias
2.5
Treinamento
12
2.6
Manutenção e Suporte Técnico 24x7 – 36 meses
1
1.2
1.3
2
2.1
2.2
2.3
1
-
1
1
Ambiente Atual Prodam
Este item tem por objetivo apresentar o atual ambiente de recursos da
PRODAM, a saber:
Ambiente de Baixa Plataforma:
− Servidores Físicos: 505;
DIT/GIE
TR CAPACIDADE E APM
Página 1 de 33
−
−
−
−
−
Processadores Físicos: 1330;
Máquinas Virtuais: 1.040;
Servidores de aplicação: 230
Storage SAN: Fujitsu Modelo DX8400;
Storage NAS: Net App Modelo FAS2020 e EMC Modelo EMCVNX5400.
Ambiente de Alta Plataforma (Mainframe):
− IBM z/OS Z10 modelo 2098-O02 (2 CP’s / 120 GB Memória Total /
Storage de 36,70 TB)
1
Solução de Software de Gestão e Planejamento de
Capacidade
1.1. Requisitos do(s) componente(s) da solução
1.1.1. Repositório Central Automatizado para Capacidade (Banco de
Dados de Capacidade)
1.1.1.1. A solução deve fornecer componente responsável por prover um
repositório central automatizado para capacidade (Banco de
Dados de Capacidade), garantindo a administração do processo
de coleta e armazenando das métricas de desempenho, dados de
configurações, serviços, processos e negócios;
1.1.1.2. Este componente é responsável, ainda, pela normalização dos
dados de capacidade, garantindo assim que independentemente
da fonte de dados utilizada exista a equivalência das métricas
coletadas, não importando o seu formato de registro original;
1.1.1.3. A solução deverá suportar como base de dados ao menos um dos
gerenciadores abaixo:
1.1.1.3.1. Oracle 11.2 (64-bit) nas versões Enterprise Edition ou
Standard Edition ou superior;
1.1.1.3.2. MS Sql Server 2014 ou superior;
1.1.1.3.3. My Sql 5.6 ou superior;
1.1.1.3.4. Postgresql 9.2 ou superior;
1.1.1.4. A solução deverá contemplar licenças de gerenciador de banco
de dados, conforme item acima, para 5 usuários simultâneos;
1.1.1.5. A solução que for utilizada e possuir a feature “Partioning
Support”, deverá habilitá-la;
1.1.1.6. A solução deverá suportar execução do servidor de aplicação
responsável pela operação/manutenção do BDC (Banco de
Dados de Capacidade) em plataformas Windows Server 2008
(64bit), Windows Server 2008 R2, Windows Server 2012 (com
GUI), Windows Server 2012 R2 (com GUI) ou versão superior,
Red Hat Enterprise Linux ES 5.4 a 5.7, Red Hat Enterprise Linux
ES 6.2 e Red Hat Emterprise Linux 7;
1.1.1.7. A solução deverá suportar a instalação do servidor de aplicação
em plataforma de virtualização VMware ESX 5.x e ESXi 6.x;
DIT/GIE
TR CAPACIDADE E APM
Página 2 de 33
1.1.1.8. A solução deverá ser capaz de coletar dados de performance
obtidos através de tecnologias específicas para tal fim, já
existentes no ambiente, não demandando a instalação de agente
específico nos servidores para a obtenção de tais métricas
(deverá ser “agentless”);
1.1.1.9. A solução deverá ser capaz de coletar, nativamente, métricas de
performance de servidores físicos e virtuais através da importação
de dados;
1.1.1.10.
A solução deverá ser capaz de coletar métricas de
performance do ambiente de virtualização VMware (clusters,
hosts e máquinas virtuais) através da conexão com VMware
vCenter nas versões 5.x e 6.x;
1.1.1.11.
Referente à configuração administrativa do vCenter,
deverá:
1.1.1.11.1. Permitir a coleta dos dados obtidos pelo vCenter
diariamente (dados coletados pelo vCenter em intervalos de
5 minutos) e semanalmente (dados coletados pelo vCenter
em intervalos de 30 minutos);
1.1.1.11.2. Quanto às métricas, deverá suportar aquelas coletadas em
Level 1, Level 2 e Level 3;
1.1.1.11.3. Deverá possuir mecanismo que permita, alternativamente,
a coleta destes dados através da vSphere API.
1.1.1.12. A solução deverá ser capaz de coletar métricas de
performance de servidores através da importação de dados
obtidos pelo BMC Performance Analyser for Servers (também
conhecido como Patrol Perform/Predict), dados estes gerados
via utilitário print udr;
1.1.1.13. A solução deverá ser capaz de obter as informações das
métricas de performance coletadas através do Microsoft
Performance Monitor;
1.1.1.14. A solução deverá ser capaz de coletar as informações das
métricas de performance obtidas através do UNIX SAR em
plataformas HP-UX, IBM z/OS, Linux e Sun Solaris;
1.1.1.15. A solução deverá ser capaz de coletar, automática e
nativamente, as métricas sobre CPU, discos, rede, processos,
transações e workloads, além de dados de configuração
coletados de aplicações baseadas em JVM e .NET pela
solução de Gerenciamento de Desempenho de Aplicações
(APM) descrita neste Termo de Referência, item 2;
1.1.1.16. A solução deverá possuir mecanismo que permita coletar as
métricas de performance via ST03 do SAP R/3 versões 4.6 e
4.7 e do SAP NetWeaver 7.x. As seguintes métricas ST03
deverão ser coletadas:
1.1.1.16.1. APPLICATION_STATISTIC (diária, por tipo de task, tcode e
usuário);
1.1.1.16.2. TIME_STATISTIC (horária, por tipo de task e tcode);
1.1.1.16.3. TASKTYPE_STATISTIC (horária, por tipo de task);
1.1.1.16.4. TASKTYPE_SUMMARY (diária, por tipo de task);
1.1.1.16.5. RFC_CLIENT_DEST_STATISTIC;
1.1.1.16.6. RFC_SERVER_DEST_STATISTIC;
DIT/GIE
TR CAPACIDADE E APM
Página 3 de 33
1.1.1.16.7. MEMORY_STATISTIC.
1.1.1.17. A solução deverá ser capaz de coletar métricas de
performance e dados de configuração de servidores através da
importação de dados obtidos pelo Microsoft System Center
Operations Manager (SCOM) 2012 R2 ou superior, tanto para a
plataforma física quanto para a virtual (HyperV);
1.1.1.18. A solução deverá possuir mecanismo que permita a coleta de
métricas de equipamentos de armazenamento (NetApp, EMC,
Fujitsu, IBM Mainframe) sobre throughput, IOPS, latência,
queue lenght, system-level CPU e armazenamento para os
seus diversos componentes, tais como aggregates, volumes,
LUN, discos e portas fiber channel;
1.1.1.19. A solução deverá possuir mecanismo que permita a coleta e
armazenamento de dados diversos (a saber, métricas “não TI”,
tais como consumo de energia, uso de espaço físico, métricas
associadas a planos de negócios, métricas financeiras, etc) em
seu banco de dados;
1.1.1.20. A solução deverá permitir o uso de métricas de performance de
servidores obtidos a partir de arquivos simples, tais como
planilhas excel e arquivos texto (CSV);
1.1.1.21. A solução deverá ser capaz de coletar informações em
repositórios externos baseados em Microsoft SQL-Server;
1.1.1.22. A solução deverá ser capaz de coletar informações em
repositórios externos baseados em Oracle;
1.1.1.23. A solução deverá ser capaz de coletar informações em
repositórios externos baseados em Sybase;
1.1.1.24. A solução deverá prover um SDK, de forma a permitir a
inclusão dos dados de métricas de performance obtidos por
mecanismos/ferramentas
outros/as,
independente
de
fornecedor ou plataforma, no repositório central da solução;
1.1.1.25. A solução deverá centralizar a informação em um BDC (Banco
de Dados de Capacidade);
1.1.1.26. A solução deverá normalizar os dados obtidos a partir das
diversas fontes aqui solicitadas, permitindo desta forma utilizar
o conjunto das métricas armazenadas no BDC (Banco de
Dados de Capacidade) independente de sua origem;
1.1.1.27. A solução deverá prover mecanismo que permita ao
administrador da solução definir o período de retenção dos
dados “crus” (raw data) no banco de dados de capacidade;
1.1.1.28. A solução deverá efetuar a carga de todas as métricas
coletadas (independente do tipo de métrica e/ou fonte de
dados) em duas fases: uma primeira fase de “staging”, onde o
analista de capacidade poderá validar o processo de carga
criado - e uma segunda fase de “migração” definitiva dos dados
para o banco de dados de capacidade. Somente após esta
segunda fase os dados deverão estar efetivamente disponíveis
para uso pela solução;
1.1.1.29. A solução deverá possuir mecanismo que permita ao
administrador definir agendamentos automáticos (schedules)
para as duas fases descritas acima, o “staging” e a “migração”
DIT/GIE
TR CAPACIDADE E APM
Página 4 de 33
1.1.1.30.
1.1.1.31.
1.1.1.32.
1.1.1.33.
1.1.1.34.
1.1.1.35.
1.1.1.36.
1.1.1.37.
1.1.1.38.
1.1.1.39.
dos dados coletados. Ainda, este mecanismo deverá permitir a
execução de tais tarefas de forma periódica, sendo que a
solução deverá permitir ao administrador definir tal
periodicidade;
A solução deverá possuir log para registro dos processos de
“staging” e “migração”;
A solução deverá possuir mecanismo que permita ao
administrador definir o período de retenção das logs de
“staging” e “migração”;
A solução deverá permitir o agrupamento de várias entidades
(tais como servidores, VMs, clusters, workloads, transações,
hosts, etc);
A solução deverá permitir que tais agrupamentos sejam
organizados em camada única (flat) ou em estrutura
hierárquica, sendo que uma determinada entidade poderá
pertencer a múltiplos grupos lógicos. (exemplo: o “Servidor A”
pode pertencer aos grupos Servidores_Windows_2008,
Aplicação_Web e Brasil > São Paulo > Campinas);
A solução deverá possuir mecanismo que possibilite exportar
os dados existentes no banco de dados de capacidade em
formato CSV e XLS;
A solução deverá possuir mecanismo de agregação ou
sumarização (doravante denominado “rollup”) dos dados “crus”
(raw data) de forma a possibilitar uma maior velocidade na
obtenção de resultados nos relatórios de análise;
A solução deverá permitir a definição do período de retenção
dos dados gerados por este processo de “rollup”;
De forma a evitar perda de dados relevantes para os estudos
de Capacidade, a solução deverá trabalhar com o conceito de
percentil para execução deste processo de agregação,
suportando ao menos os seguintes tipos de “rollup”: 90
percentil, 95 percentil, Valor Máximo, Valor Mínimo e Média
Ponderada;
Deverá ainda permitir a habilitação de outros tipos de “rollup”
neste processo de agregação, tais como outros valores de
percentil e/ou Desvio Padrão;
Independente do tipo de “rollup”, a solução deverá possibilitar
que estes ocorram obedecendo a um padrão de tempo diário
(por dia) e/ou horário (por hora).
1.1.2. Interface Web para visualização de dados e emissão de relatórios
1.1.2.1.
1.1.2.2.
DIT/GIE
A solução deverá fornecer interface web responsável por
permitir a visualização dos dados de desempenho históricos e
atuais armazenados no Banco de Dados de Capacidade, para
todo o ambiente gerenciado ou por agrupamentos de
componentes;
A solução deverá permitir a visualização de dados de
desempenho e configuração armazenados no Banco de Dados
TR CAPACIDADE E APM
Página 5 de 33
1.1.2.3.
1.1.2.4.
1.1.2.5.
1.1.2.6.
1.1.2.7.
1.1.2.8.
1.1.2.9.
1.1.2.10.
1.1.2.11.
1.1.2.12.
1.1.2.13.
DIT/GIE
de Capacidade em diversos formatos e relatórios, de forma a
permitir o efetivo gerenciamento de capacidade da
infraestrutura, das aplicações e dos equipamentos, a partir da
combinação de diferentes tipos de dados para análise em um
só lugar;
A solução deverá possibilitar o agrupamento dos elementos
gerenciados de acordo com necessidades de apresentação
diversas, tais como secretaria, localização, serviço atendido,
tipo da plataforma, e outros;
A solução deverá prover análise que contemple o uso de
“planning percentile”, de forma a facilitar referida análise bem
como a interpretação dos dados históricos em avaliação;
A solução deverá gerar gráficos com relatórios de utilização
dos componentes como um todo, bem como por agrupamento
previamente definido pelo administrador da solução;
A solução deverá permitir incluir/excluir a visão de curva de
tendência para os dados apresentados nos relatórios de
utilização;
A solução deverá gerar gráficos com relatórios de otimização
dos componentes como um todo, bem como por agrupamento
previamente definido pelo administrador da solução;
A solução deverá possibilitar a execução de “drill-down” a partir
do gráfico de utilização dos componentes, de forma a
possibilitar a identificação do consumo histórico de recursos
por componente;
A solução deverá possibilitar a execução de “drill-down” a partir
do gráfico de otimização dos componentes, de forma a
possibilitar a identificação do consumo histórico de recursos
por componente;
O relatório de otimização deverá apresentar os consumos por
faixa de uso, permitindo assim que o administrador da solução
tenha um mapa gráfico completo do ambiente em relação aos
recursos sub-utilizados, com utilização dentro do esperado,
com utilização acima do esperado e também super-utilização);
A solução deverá apresentar, quando da execução do drilldown neste relatório de otimização, os recursos que estão
dentro de cada faixa de utilização, inclusive com filtro que
permita ver todos os componentes ou somente aqueles que
estejam dentro de determinada condição (por exemplo, ver
somente os sub-utilizados);
A solução deverá possuir estas faixas de uso já configuradas
de acordo com boas práticas observadas no mercado, todavia
deverá também permitir que sejam feitos ajustes nestas faixas
de utilização – possibilitando assim que a tecnologia seja
adequada à realidade do ambiente CONTRATANTE;
A solução deverá possuir mecanismo nativo que possibilite a
visualização dos componentes gerenciados de acordo com
focos específicos de análise, incluindo ao menos: servidores,
capacidade, "planning percentile”, médias e picos;
TR CAPACIDADE E APM
Página 6 de 33
1.1.2.14. A solução deverá possuir mecanismo para geração de
relatórios com acesso via web browser;
1.1.2.15. A solução deverá permitir a criação de dashboards, agrupando
em uma única interface diferentes relatórios;
1.1.2.16. A geração dos dashboards deve valer-se de mecanismo do tipo
“arrastar e soltar” para sua criação;
1.1.2.17. A solução deverá permitir ao administrador da solução definir
diversos perfis de usuários, bem como quais os dashboards
que cada perfil terá acesso;
1.1.2.18. Este componente deverá suportar execução em plataformas
Windows Server 2008 (64bit) ou Windows Server 2008 R2;
1.1.2.19. A solução deverá prover, ao menos, os seguintes tipos de
relatórios:
1.1.2.19.1.
Relatórios de Inventário:
1.1.2.19.1.1. Alocação de vRAM em Cluster VM vs. RAM
Instalada;
1.1.2.19.1.2. Lista de Frames AIX;
1.1.2.19.1.3. Alocação de Cores em Frames AIX;
1.1.2.19.1.4. Lista de LPARs AIX;
1.1.2.19.1.5. Lista de Pools AIX;
1.1.2.19.1.6. Lista de Servidores Físicos;
1.1.2.19.1.7. Lista de Clusters VMware ESX;
1.1.2.19.1.8. Lista de Hosts VMware ESX;
1.1.2.19.1.9. Lista de Máquinas Virtuais VMware;
1.1.2.19.1.10.
Lista dos Grupos de Aplicações;
1.1.2.19.1.11.
Host VM RAM: Alocação;
1.1.2.19.1.12.
Lista de Processos por Host;
1.1.2.19.1.13.
Performance de Transações;
1.1.2.19.1.14.
Data Center vCenter;
1.1.2.19.1.15.
Administração da Ferramenta: Sumário de
Utilização das Tablespaces;
1.1.2.19.1.16.
Administração da Ferramenta: Detalhes das
Tablespaces;
1.1.2.19.1.17.
Administração da Ferramenta: Relatório de
Migração de Dados;
1.1.2.19.1.18.
Administração da Ferramenta: Relatório de
GAPs na Carga de Dados;
1.1.2.19.1.19.
Administração da Ferramenta: Relatório de
Performance da Migração de Dados;
1.1.2.19.1.20.
Administração da Ferramenta: Relatório de
Status do Processo de Rollup.
1.1.2.19.2.
Relatórios de Exceção:
1.1.2.19.2.1. Maiores Consumidores de CPU (para LPARs
AIX);
1.1.2.19.2.2. Menores Consumidores de CPU (para LPARs
AIX);
1.1.2.19.2.3. Maiores Consumidores de CPU (para Hosts ESX);
1.1.2.19.2.4. Menores Consumidores de CPU (para Hosts
ESX);
DIT/GIE
TR CAPACIDADE E APM
Página 7 de 33
1.1.2.19.2.5. Maiores Consumidores de CPU (para Servidores
Físicos);
1.1.2.19.2.6. Menores Consumidores de CPU (para Servidores
Físicos);
1.1.2.19.2.7. Maiores Consumidores de CPU (para Máquinas
Virtuais);
1.1.2.19.2.8. Menores Consumidores de CPU (para Máquinas
Virtuais);
1.1.2.19.2.9. Maiores Consumidores de CPU (para Cluster);
1.1.2.19.2.10.
Menores Consumidores de CPU (para
Cluster);
1.1.2.19.2.11.
Maiores Consumidores de Memória (para
LPARs AIX);
1.1.2.19.2.12.
Menores Consumidores de Memória (para
LPARs AIX);
1.1.2.19.2.13.
Maiores Consumidores de Memória (para
Máquinas Virtuais);
1.1.2.19.2.14.
Menores Consumidores de Memória (para
Máquinas Virtuais);
1.1.2.19.2.15.
Maiores Consumidores de Memória (para
Hosts ESX);
1.1.2.19.2.16.
Menores Consumidores de Memória (para
Hosts ESX);
1.1.2.19.2.17.
Maiores Consumidores de Memória (para
Servidores Físicos);
1.1.2.19.2.18.
Menores Consumidores de Memória (para
Servidores Físicos);
1.1.2.19.2.19.
Mapa de Calor (Heatmap) mensal para
consumo de CPU para grupos de servidores;
1.1.2.19.2.20.
Mapa de Calor (Heatmap) mensal para
consumo de Memória para grupos de servidores.
1.1.2.19.3.
Relatório de Tendências:
1.1.2.19.3.1. Tendência de Utilização – AIX;
1.1.2.19.3.2. Tendência de Utilização – Servidores Físicos;
1.1.2.19.3.3. Tendência de Utilização – Hosts VMware ESX;
1.1.2.19.3.4. Tendência de Utilização – Máquinas Virtuais
VMware.
1.1.2.19.4.
Relatórios para Detecção de Baseline:
1.1.2.19.4.1. Dia de Pico – Servidores AIX;
1.1.2.19.4.2. Dia de Pico – Servidores ESX;
1.1.2.19.4.3. Dia de Pico – Servidores Físicos;
1.1.2.19.4.4. Dia de Pico – Máquinas Virtuais;
1.1.2.19.4.5. Hora de Pico – Servidores AIX:
1.1.2.19.4.6. Hora de Pico – Servidores ESX;
1.1.2.19.4.7. Hora de Pico – Servidores Físicos;
1.1.2.19.4.8. Hora de Pico – Máquinas Virtuais;
1.1.2.19.4.9. Pico em Três Horas – Servidores AIX;
1.1.2.19.4.10.
Pico em Três Horas – Servidores ESX;
DIT/GIE
TR CAPACIDADE E APM
Página 8 de 33
1.1.2.19.4.11.
1.1.2.19.4.12.
Pico em Três Horas – Servidores Físicos;
Pico em Três Horas – Máquinas Virtuais
1.1.2.19.5.
Relatórios - Nível de Sistemas:
1.1.2.19.5.1. Lista de Serviços por Servidor;
1.1.2.19.5.2. Sumário de Utilização de Hosts;
1.1.2.19.5.3. Tendência de Utilização de CPU;
1.1.2.19.5.4. Tendência de Utilização de Memória;
1.1.2.19.5.5. Utilização de CPU por Host e VM;
1.1.2.19.5.6. Utilização de CPU (% Utilizado);
1.1.2.19.5.7. CPU - Tamanho de Fila (Queue Length);
1.1.2.19.5.8. CPU - Tamanho de Fila (Queue Length) –
Utilização;
1.1.2.19.5.9. Utilização de Memória por Host e VM;
1.1.2.19.5.10.
Utilização de Disco por Host e VM;
1.1.2.19.5.11.
Utilização de Rede por Host e VM;
1.1.2.19.5.12.
“Read Byte Rate” de Disco por Host;
1.1.2.19.5.13.
“Write Byte Rate” de Disco por Host;
1.1.2.19.5.14.
Storage (GB) Utilizado por Host e VM;
1.1.2.19.5.15.
Utilização Percentual de Storage por Host;
1.1.2.19.5.16.
CPU Ready;
1.1.2.19.5.17.
“Ballooning” de Memória;
1.1.2.19.5.18.
Swap de Memória;
1.1.2.19.5.19.
Overhead de Memória.
1.1.2.19.6.
Relatórios de Correlação e Workload:
1.1.2.19.6.1. Lista de Serviços para Servidores;
1.1.2.19.6.2. Lista de Serviços – Sinalizadores;
1.1.2.19.6.3. Lista de Serviços – Correlação Agregada;
1.1.2.19.6.4. Lista de Serviços – Correlação Individual;
1.1.2.19.6.5. Performance de Transações.
1.1.2.19.7.
Relatórios de Storage – Nível de Datastore VMware:
1.1.2.19.7.1. Menor Latência do Datastore por VM;
1.1.2.19.7.2. Maior Latência do Datastore por VM;
1.1.2.19.7.3. Menor Utilização do Datastore (% de Utilização);
1.1.2.19.7.4. Maior Utilização do Datastore (% de Utilização);
1.1.2.19.7.5. Menor Utilização do Datastore (por Cluster);
1.1.2.19.7.6. Maior Utilização do Datastore (por Cluster);
1.1.2.19.7.7. Menor Utilização das VMs por Datastore (% de
Utilização);
1.1.2.19.7.8. Alocação do Datastore;
1.1.2.19.7.9. Capacidade do Datastore e VMs;
1.1.2.19.7.10.
Latência do Datastore por VM;
1.1.2.19.7.11.
Performance do Datastore – Todas as VMs;
1.1.2.19.7.12.
Tendências do Datastore;
1.1.2.19.7.13.
Tendências do Datastore por VM;
1.1.2.19.7.14.
Utilização do Datastore;
1.1.2.19.7.15.
Utilização do Datastore por VM;
1.1.2.19.7.16.
Utilização do Datastore por Cluster;
DIT/GIE
TR CAPACIDADE E APM
Página 9 de 33
1.1.2.19.7.17.
Utilização do Datastore por Cluster (Total).
1.1.2.19.8.
Relatórios de Uso e Risco para Plataforma VMware:
1.1.2.19.8.1. Capacidade de CPU do Cluster por VM;
1.1.2.19.8.2. Capacidade de Memória do Cluster por VM;
1.1.2.19.8.3. Estado Atual de Uso do Cluster;
1.1.2.19.8.4. Estado
de
Uso
do
Cluster
Pós
Redimensionamento Proposto;
1.1.2.19.8.5. Relatório de “Sizing” de VM – Para Todos os
Clusters;
1.1.2.19.8.6. Relatório de “Sizing” de VM – Por Cluster;
1.1.2.19.8.7. Tendência de Uso do Cluster (CPU e Memória);
1.1.2.19.8.8. Sumário de Utilização do Cluster;
1.1.2.19.8.9. Sumário de Utilização do Host ESX;
1.1.2.19.8.10.
Relatório de “Top CPU Ready” – Para todas
as VMs;
1.1.2.19.8.11.
Relatório de “Top CPU Ready” – Por Host;
1.1.2.19.8.12.
Relatório de “Top CPU Ready” – Por Cluster;
1.1.2.19.8.13.
Relatório de Risco – Maiores Consumidores
de CPU e Memória;
1.1.2.19.8.14.
Relatório de Desperdício – Menores
Consumidores de CPU e Memória.
1.1.2.20. A solução deverá também possuir conjunto de relatórios
específicos associados a ferramenta de APM (Application
Performance Manager) com, no mínimo, os seguintes tipos de
relatórios:
1.1.2.20.1. Relatório de “Headroom” por Aplicação;
1.1.2.20.2. Relatórios de Aplicação:
1.1.2.20.2.1. Relatório de “Breakdown” por Aplicação;
1.1.2.20.2.2. Relatório de Lista de Aplicações.
1.1.2.20.3. Relatórios de Correlação de Capacidade;
1.1.2.20.4. Relatórios de Carga de Trabalho para o Capacity
Manager (por VM, por Aplicação);
1.1.2.20.5. Relatório de Configuração de “Heap”;
1.1.2.20.6. Relatórios de Horários de Pico:
1.1.2.20.6.1.
Hora de Pico;
1.1.2.20.6.2. Pico em três horas.
1.1.2.20.7.
Relatório de Tempos de Resposta e Throughtput;
1.1.2.20.8.
Relatório dos Maiores Processos;
1.1.2.20.9.
Gráfico de Replay de Transações;
1.1.2.20.10. Relatório de Apresentação do Sumário de
Transações;
1.1.2.20.11. Relatórios de Utilização:
1.1.2.20.11.1. Correlação de Carga de Trabalho;
1.1.2.20.11.2. Mensagem do Coeficiente de Correlação da
Carga de Trabalho.
1.1.2.20.12. Lista de Cargas de Trabalho por Host;
1.1.2.20.13. Histogramas de Throughput das Cargas de Trabalho.
DIT/GIE
TR CAPACIDADE E APM
Página 10 de 33
1.1.2.21. A solução deverá possibilitar também a criação de novos
relatórios, de forma a permitir o uso dos dados existentes no
banco de dados de capacidade da maneira mais apropriada ao
atendimento das necessidades de análise;
1.1.2.22.
A solução deverá permitir a criação de relatórios que
possibilitem a análise de correlação entre métricas de
infraestrutura e métricas de negócios;
1.1.2.23. A solução deverá permitir que sejam efetuadas alterações na
aparência da interface web;
1.1.2.24. A solução deverá permitir que os parâmetros de limites
(thresholds)
utilizados
nos
relatórios
sejam
alterados/redefinidos de acordo com a necessidade do
ambiente;
1.1.2.25. A solução deverá trabalhar com faixas de limites (thresholds)
que permitam uma adequada interpretação dos dados.
1.1.3. Análise de Desempenho Futuro
1.1.3.1.
A solução deverá fornecer componente para análise de
desempenho futuro (forecast) que permite a construção de
modelos de ambiente com a infraestrutura computacional
utilizada para atender as demandas de negócio, considerando
os dados armazenados no Banco de Dados de Capacidade;
1.1.3.2. Estes modelos deverão ser utilizados para estimar
crescimentos futuros, bem como para executar as seguintes
tarefas:
1.1.3.2.1. Proporcionar o planejamento de capacidade contínua
para sistemas de produção;
1.1.3.2.2. Visualizar utilização dos recursos e desempenho
passado, corrente e futuro;
1.1.3.2.3. Identificar os tempos de respostas para aplicações;
1.1.3.2.4. Identificar problemas na utilização dos recursos.
1.1.3.3. A solução deverá fornecer um sistema de modelagem, com
capacidade de modelagem analítica;
1.1.3.4. O sistema de modelagem deverá possuir integração com o BDC
(Banco de Dados de Capacidade), de forma a utilizar as
informações ali armazenadas para as modelagens analíticas;
1.1.3.5. A aplicação cliente responsável pela modelagem deverá suportar
instalação em plataforma Windows 7 (32bit ou 64bit);
1.1.3.6. A solução deverá permitir o uso de tempos de resposta
calibrados/aferidos, possibilitando assim a definição do tempo de
resposta para um determinado baseline a partir de dados
coletados através de ferramentas específicas de medição e/ou
monitoração, ou mesmo logs de aplicativos. Este valor deverá ser
utilizado como ponto de ajuste de calibração nas modelagens,
referente aos tempos de resposta em intervalos futuros;
1.1.3.7. A solução deverá permitir, como critério para tempos de resposta,
o uso da taxa de chegada (arrival rate) como “baselines” em um
determinado intervalo de tempo em situações onde não for
DIT/GIE
TR CAPACIDADE E APM
Página 11 de 33
possível definir-se o tempo de resposta calibrado. Poderão ser
usadas informações de taxas de chegada coletadas em logs ou
através de ferramentas de monitoração relacionadas a contagem
de usuários, transações ou mesmo funções específicas (como por
exemplo: “lê” e “escreve”). Ainda, os intervalos de tempo deverão
permitir que se configure a taxa de chegada por segundo, minuto
ou hora;
1.1.3.8. A solução deverá permitir, caso não seja possível definir os
tempos de resposta de forma calibrada ou através de taxas de
chegada, que se defina um tempo de resposta em relação à carga
de trabalho como sendo um múltiplo do tempo de resposta do
“baseline”. Neste caso, o resultado esperado será a quantidade
de vezes que um determinado tempo de resposta será superior
(em situações de crescimento) ao tempo de resposta determinado
no “baseline”;
1.1.3.9. A solução deverá permitir que se estabeleçam requerimentos de
tempos de resposta, de forma a determinar um objetivo limite em
relação aos tempos de resposta aceitáveis para determinado
modelo;
1.1.3.10.
A solução deverá fornecer software de modelagem que
suporte (mas não limitado a) servidores que executem sistema
operacional HP-UX, IBM z/OS, Linux (RedHat, SuSE, Alpha),
Windows Server (2000, 2003, 2008, 2012), SUN Solaris;
1.1.3.11.
A solução deverá fornecer software de modelagem que
possibilite a execução de análises de capacidade em ambiente
Mainframe IBM;
1.1.3.12. Deverá possuir biblioteca de modelos de hardware (HML –
Hardware Model Library) compatível com as definições
mantidas pela Standard Performance Evaluation Corporation
(http://www.spec.org);
1.1.3.13. Deverá implementar também, nas definições dos modelos de
hardware, fatores de escalabilidade e linearidade – permitindo
assim uma maior acuracidade nas simulações executadas
utilizando tais modelos de hardware;
1.1.3.14. Deverá permitir considerar, na configuração do hardware, a
habilitação ou não do parâmetro de multithreading;
1.1.3.15. Deverá implementar, a partir da biblioteca de modelos de
hardware, uma unidade de medida que indique a capacidade
de processamento dos servidores da plataforma distribuída –
contemplando a capacidade máxima do equipamento e a
capacidade atual, de acordo com as configurações existentes;
1.1.3.16. Esta biblioteca de modelos de hardware deverá, para a
plataforma Mainframe, ser compatível com o indicador MIPS;
1.1.3.17. Deverá possuir uma biblioteca de modelos de componentes
que permita o uso de diversos VMMs (Virtual Machine Monitor)
nas simulações relacionadas a ambientes virtuais,
contemplando: VMware ESX 3.0, 3.5, 4.0, 4.1, 5.0, 5.1 e 5.5;
Microsoft Hyper-V, Hyper-V R2 e Hyper-V 2012; Integrity VM;
Logical Domains; RHEL KVM 5 e 6; RHEL Xen 5; Xen Server;
DIT/GIE
TR CAPACIDADE E APM
Página 12 de 33
1.1.3.18.
1.1.3.19.
1.1.3.20.
1.1.3.21.
1.1.3.22.
1.1.3.23.
1.1.3.24.
1.1.3.25.
1.1.3.26.
1.1.3.27.
1.1.3.28.
1.1.3.29.
1.1.3.30.
1.1.3.31.
DIT/GIE
vPars Monitor; Oracle VM Server 3; Power5, Power6 e Power7
VMMs; z/OS V1R9, V1R11 e V1R13 VMMs;
Deverá possuir biblioteca de modelos de hardware que suporte
plataformas com foco em implementação de infraestrutura para
Cloud, contemplando Cisco UCS, FlexPod UCS e VCE Vblock;
Deverá possuir biblioteca de modelos de hardware que suporte
ambientes de Cloud pública, contemplando Amazon EC2,
Microsoft Azure, Rackspace, Savvis e Terremark vCloud;
A solução deverá prover mecanismo para atualização periódica
do hardware de servidores constantes da biblioteca de modelos
de hardware;
A solução deverá permitir a simulação de cenários
considerando alterações de carga de trabalho no ambiente
previamente definido;
A solução deverá ser capaz de simular o crescimento vertical
(adição de componentes ao servidor ou reposição por um
hardware mais potente) e horizontal (adicionando novos
servidores à plataforma existente);
A solução deverá ser capaz de simular cenários do tipo P2V,
ou seja, a virtualização de servidores físicos;
A solução deverá ser capaz de simular cenários do tipo V2P,
ou seja, a migração de servidores virtualizados para servidores
físicos;
A solução deverá ser capaz de simular cenários do tipo V2V,
ou seja, a migração de uma plataforma de virtualização para
outra plataforma de virtualização;
A solução deverá ser capaz de simular cenários do tipo P2P,
ou seja, a migração de uma plataforma física para outra
plataforma física;
A solução deverá ser capaz de simular cenários do tipo P2C,
ou seja, a migração de uma plataforma física para ambiente em
cloud;
A solução deverá ser capaz de simular cenários do tipo V2C,
ou seja, a migração de servidores virtualizados para ambiente
em cloud;
A solução deverá ser capaz de simular a consolidação de
servidores;
A solução deverá ser capaz de simular mudanças na
configuração de servidores, mudanças estas que podem ser
relacionadas a alterações de hardware (inclusão/exclusão de
memória e/ou processadores), alterações de modelos de
equipamentos de mesmo fabricante ou então de outros
fabricantes;
A solução deverá permitir também, na simulação de mudanças
de configuração para servidores virtuais, a alteração de
parâmetros relacionados ao ambiente virtual – tais como
parâmetros de alocação exclusiva de recursos e “capping” de
memória e CPU;
TR CAPACIDADE E APM
Página 13 de 33
1.1.3.32. A solução deverá permitir simulações que possibilitem a
análise de possíveis migrações entre plataformas: CISC x
CISC; RISC x RISC; CISC x RISC; RISC x CISC;
1.1.3.33. A solução deverá permitir a simulação de aumento contínuo da
carga de trabalho dos servidores de um determinado cenário;
1.1.3.34. A solução deverá permitir a simulação de aumentos
variáveis/sazonais da carga de trabalho dos servidores de um
determinado cenário;
1.1.3.35. A solução deverá ser capaz de modelar cenários com uso de
dados coletados automaticamente de aplicações baseadas em
JVM e .NET pela solução de Gerenciamento de Desempenho
de Aplicações (APM) descrita neste Termo de Referência, item
2, de forma a possibilitar simulações de mudanças nos
workloads destas aplicações;
1.1.3.36. A solução deverá permitir que tais modelagens para as cargas
de trabalho das aplicações possam ser executadas de forma
total ou individual, por aplicação, possibilitando desta forma
estudar taxas de crescimento independentes para cada
aplicação;
1.1.3.37. A solução deverá ser capaz de reassinalar a carga de uma
determinada aplicação específica (com dados oriundos de
ferramenta APM, descrita neste Termo de Referência, item 2)
para outro servidor, possibilitando assim a execução de
estudos de comportamento do ambiente frente às diversas
possíveis mudanças que possam vir a ocorrer;
1.1.3.38. A solução deverá permitir a definição do intervalo de baseline,
possibilitando assim usar os dados históricos mais adequados
nas simulações a serem executadas;
1.1.3.39. A solução deverá permitir a definição do intervalo de forecast
desejado (em semanas, meses ou trimestres), possibilitando
assim avaliar cada cenário simulado de acordo com o período
futuro necessário;
1.1.3.40. A solução deverá permitir que sejam criadas modelagens a
partir dos dados de baseline (possibilitando assim a
comparação entre diversos cenários criados paralelamente) e
também após uma modelagem prévia, permitindo também a
criação de cadeia de cenários;
1.1.3.41. A solução deverá permitir que todos os possíveis cenários de
simulação sejam exercitados usando a infraestrutura real
existente, bem como usando servidores hipotéticos (não
existentes na infraestrutura);
1.1.3.42. A solução deverá permitir que seja definida também
infraestrutura hipotética de virtualização (Cluster - balanceado
ou não balanceado - e Hosts), para posterior uso nos cenários
de simulação a serem exercitados;
1.1.3.43. A solução deverá prover “wizards” que possibilitem uma fácil e
rápida geração de cenários de simulação;
1.1.3.44. A solução deverá salvar os cenários de simulações criados,
permitindo assim seu uso posterior quando necessário.
DIT/GIE
TR CAPACIDADE E APM
Página 14 de 33
1.2. Licenças de uso contemplando o cenário descrito no item “Ambiente
Atual PRODAM”
1.2.1. O licenciamento de uso do(s) software(s) componente(s) da solução
deverá permitir a ativação da solução no ambiente da contratante, respeitando
as seguintes condições:
1.2.1.1. As licenças de uso fornecidas referem-se ao direito de
uso perpétuo do(s) programa(s) que compõem a solução;
1.2.1.2. O número total de licenças deverá ser definido pela
CONTRATADA, de acordo com políticas de licenciamento
da empresa fornecedora da solução, com base no
ambiente da Contratante e números expressos no item
“Ambiente Atual Prodam”;
1.2.1.3. A Documentação do Licenciamento e Direito de Uso do
Software, envolvido na solução, deve ser fornecida pelo
fabricante, garantindo à CONTRATANTE o suporte
técnico e atualização do software durante todo o prazo
contratado.
1.3. Serviços de Instalação, Configuração e Migração de dados
1.3.1. Toda e qualquer instalação e configuração da solução é de
responsabilidade da CONTRATADA e deve ser iniciado em até 30 dias
após a assinatura do contrato;
1.3.2. A CONTRATADA deve garantir que os dados históricos e atuais de
capacidade da solução atual instalada em ambiente CONTRATANTE
esteja disponível na solução adquirida.
1.4. Operação Assistida (hands-on)
1.4.1. A CONTRATADA deverá manter profissional capacitado no(s) produto(s)
componente(s) da solução por um período mínimo de 90 (noventa) dias,
de segunda a sexta-feira das 8:00h às 17:00h (ou a critério, negociado
entre as partes) no ambiente da contratante no intuito de atuar na
customização, operacionalização (hands-on) e suporte inicial da solução;
1.4.2. Um analista da CONTRATANTE acompanhará o profissional da
CONTRATADA durante o período de operação assistida;
1.4.3. A operação assistida será iniciada somente após a finalização da
instalação da solução em ambiente da Contratante;
1.4.4. A CONTRATANTE emitirá Termo de Aceite para fins de comprovação
após completados 60 (sessenta) dias de operação assistida.
1.5. Treinamento
1.5.1. A CONTRATADA deverá oferecer treinamento oficial da solução
implantada, no prazo de até 30 (trinta) dias corridos a contar da data de
emissão do Termo de Aceite, com o mínimo de 40 (quarenta) horas de
DIT/GIE
TR CAPACIDADE E APM
Página 15 de 33
1.5.2.
1.5.3.
1.5.4.
1.5.5.
duração de cada produto/modulo que compõe a solução, para o mínimo
de 7 (sete) funcionários da CONTRATANTE (divididos em 2 turmas,
agendadas em datas distintas a critério da CONTRATANTE);
O treinamento deve ser realizado em dias úteis, dentro do Município de
São Paulo;
Deverá ser fornecido material impresso ou digital no idioma português ou
inglês;
Ao final do treinamento, os participantes deverão receber certificado de
conclusão;
O treinamento deverá ser ministrado por instrutores certificados pela
empresa fornecedora da solução, englobando, pelo menos, os seguintes
aspectos:
1.5.5.1. Introdução ao software (conceitos, componentes e
arquitetura);
1.5.5.2. Planejamento de uso (requisitos de ambiente para
instalação);
1.5.5.3. Instalação e configuração do produto;
1.5.5.4. Customização e gerenciamento;
1.5.5.5. Utilização, entendimento, operação.
1.6. Manutenção e Suporte Técnico 24x7
1.6.1. A Manutenção refere-se à continuidade operacional do(s) software(s)
que compõe(m) a solução adquirida dentro do período de 36 (trinta e
seis) meses contados a partir da data de emissão do Termo de Aceite,
abrangendo todas as atividades de manutenção e suporte requeridas;
1.6.2. Entende-se como suporte o atendimento, pela CONTRATADA, quanto a
informações sobre uso e funcionalidades do produto, sem custos
adicionais para a CONTRATANTE e sem limite de horas. Inclui também
as atividades consultivas para orientação à contratante quanto às
providências necessárias à possível utilização, em juízo, das evidências
detectadas através do software;
1.6.3. O atendimento para suporte e manutenção será feito pela
CONTRATADA no regime 24 x 7 x 365, inclusive nas dependências da
contratante quando necessário;
1.6.4. Os chamados para suporte e manutenção serão realizados através de
telefone ou correio eletrônico e deverão ser atendidos pela
CONTRATADA em até 3 (três) horas após o recebimento da solicitação.
Uma solução de contorno ou solução definitiva deve ser dada/aplicada
em até 8 (oito) horas;
1.6.5. Toda intervenção na solução, na atualização de versão e adequações
das funcionalidades durante o período de contrato, deverão ser
realizadas
sem
quaisquer
ônus
para
CONTRATANTE,
independentemente do serviço executado;
1.6.6. Em caso de atualização decorrente de necessidade de correção dos
produtos e atualizações de versões, quando disponibilizadas pela
empresa fornecedora do software, cabe à CONTRATADA:
1.6.7. Identificar e interpretar os defeitos apresentados pelo software;
DIT/GIE
TR CAPACIDADE E APM
Página 16 de 33
1.6.8. Transmitir por escrito, à empresa fabricante do(s) software(s), todas as
informações relativas aos problemas encontrados no mesmo, quando
estes não puderem ser resolvidas pela CONTRATADA;
1.6.9. Transmitir por escrito, à CONTRATANTE todas as informações e
providências tomadas pela empresa fabricante do(s) software(s), no
sentido de:
1.6.10.
Determinar uma solução de contorno para defeito apresentado;
1.6.11.
Determinar como e quando será feita a correção definitiva do
defeito apresentado.
1.6.12.
Dentro do período de vigência do Contrato:
1.6.13.
Realizar as manutenções necessárias e solicitadas para que o
ambiente esteja atualizado;
1.6.14.
Entregar à CONTRATANTE o meio magnético ou senha de
download e a documentação atualizados das novas versões que
venham a ser liberadas pelo fornecedor para correções de erros que
afetem o seu funcionamento normal, ou que possuam melhorias de
performance e novas funcionalidades;
1.6.15.
Proceder à instalação e configuração necessárias.
2. Solução de Software de Gerenciamento de Desempenho de Aplicações
(Application Performance Management - APM)
2.1. Requisitos do(s) componente(s) da solução
2.1.1.
Requisitos Gerais de Gerenciamento de Aplicações
2.1.1.1.
2.1.1.2.
2.1.1.3.
2.1.1.4.
2.1.1.5.
2.1.1.6.
2.1.1.7.
2.1.1.8.
DIT/GIE
Monitorar e incluir a visão de desempenho e
disponibilidade dos serviços que sustentam a aplicação
JEE, tais como: servidores de aplicação, servidores WEB
e conexão backend (Oracle, PostgreSQL, Web Services,
EJB, RMI, JMS);
Compatibilidade total com a especificação Java 2 SDK,
Standard Edition 1.5 e superiores;
Monitorar aplicações desenvolvidas na plataforma JEE e
possuir total compatibilidade com a especificação Java 2
SDK, Standard Edition 1.5 e superiores;
A solução deve permitir a monitoração de extensões
lambda do JDK 1.8;
Deve ter capacidade de monitorar qualquer aplicação
Microsoft .NET para Windows e aplicações executadas no
container IIS;
Possuir total compatibilidade com a especificação
Microsoft .NET framework V2.0 e superiores suportadas
pelo fabricante;
Monitorar aplicações desenvolvidas na plataforma PHP,
framework 5.4 e 5.5;
1.8 Ser compatível com as diferentes implementações
da JVM (Oracle, IBM e OpenJDK);
TR CAPACIDADE E APM
Página 17 de 33
2.1.1.9.
Deve ser independente do container e contemplar, pelo
menos, todos os abaixo descritos:
2.1.1.9.1. Sun Glassfish
2.1.1.9.2. Oracle Application Server
2.1.1.9.3. Tomcat
2.1.1.9.4. Jboss
2.1.1.9.5. Weblogic
2.1.1.9.6. Websphere Application Server"
2.1.1.10. Monitorar aplicações instaladas nos containers em
quaisquer das plataformas eversões Java_SE: X-86 com
JVM 1.5, RISC com JVM 1.5 e superiores;
2.1.1.11. Não utilizar da interface de monitoramento JVMPI dado
seu excessivo consumode recursos de CPU e seus
efeitos sobre a performance das JVMs e também pelo
fato de tal interface estar descontinuada a partir da versão
JavaSE – 1.5;
2.1.1.12. Monitorar, de forma automática (plug-and-play), todos os
componentes padrão da arquitetura JEE sem a
necessidade de qualquer customização adicional;
2.1.1.13. Suportar extração de dados via JMX (JSR 3: JavaTM
Management Extensions(JMXTM) Specification) e
mBeans;
2.1.1.14. Coletar indicadores de consumo de memória da JVM;
2.1.1.15. Coletar indicadores de consumo de CPU do servidor de
aplicação;
2.1.1.16. Coletar indicadores de consumo de CPU do processo
Java;
2.1.1.17. Coletar indicadores de tempo médio individualizado da
execução dos componentes padrão da arquitetura JEE
(Servlets, JSP, JSF, EJB, Métodos das ClassesJava,
JDBC, Queries, JTA, JMS, JNDI, etc);
2.1.1.18. Coletar indicadores de número de sessões em tempo
real;
2.1.1.19. Capturar erros e exceções em qualquer ponto da
aplicação, em tempo real, e fornecer dados, também em
tempo real, que permitam aos administradores identificar
o tipo de erro e o ponto exato da transação onde o
mesmo ocorreu;
2.1.1.20. Monitorar recursos de infraestrutura do servidor de
aplicação (utilização e disponibilidade de thread e
connection pools, memória, CPU) correlacionando os
dados coletados com os dados da aplicação monitorada,
em mesma escala de tempo;
2.1.1.21. Monitorar a interação entre a aplicação e serviços de
mensageria (ex: JMS),quanto à disponibilidade e tempos
de resposta dos serviços;
2.1.1.22. Monitorar serviços de acesso ao banco de dados,
utilizado pelas aplicações, quanto ao teor das clásulas
SQL (select, commit, update e insert) encaminhadas ao
DIT/GIE
TR CAPACIDADE E APM
Página 18 de 33
2.1.1.23.
2.1.1.24.
2.1.1.25.
2.1.1.26.
2.1.1.27.
2.1.1.28.
2.1.1.29.
2.1.1.30.
2.1.1.31.
2.1.1.32.
2.1.1.33.
2.1.1.34.
2.1.1.35.
DIT/GIE
banco de dados, seu processamento e disponibilidade,
quando utilizadas pelas aplicações;
Ao monitorar os serviços de acesso ao banco, no mínimo,
deve ser mostrado a query executada e seu tempo de
execução;
Monitorar o tempo total gasto para processamento do
conjunto de dados obtidos por uma query junto ao banco
de dados;
Monitorar o comportamento da utilização de memória pelo
servidor de aplicaçãoJEE, bem como o processo de
gerenciamento
de
memória
denominado
GarbageCollection;
Fornecer dados em tempo real sobre o comportamento
das diversas áreas de memória da JVM (EX: Eden,
Tenured, Permanent e Old), incluindo a especificação do
Java 1.8;
Monitorar volume de objetos instanciados em memória,
sejam eles tanto do tipo “collections” quanto do tipo “não
collections”, e também os utilizados pela aplicação para
conexões a banco de dados;
Monitorar em tempo real e histórico a execução da
aplicação e correlacionar métricas obtidas em diferentes
períodos definidos pelo usuário;
Permitir o rastreamento das transações entre JVMs que
estejam no mesmo servidor ou em servidores distintos;
Ter a capacidade de correlacionar a performance
percebida pelos usuários da aplicação com as camadas
da infraestrutura que a suportam, apresentando em uma
única tela a performance do pool de servidores, rede e
front end, para rápida identificação do domínio da falha;
Apresentar mapa automático (console de serviços) da
arquitetura da aplicação monitorada evidenciando os
componentes da aplicação Java (instâncias), os backends
ao qual ela se conecta (bancos de dados, Web Services,
conexões socket com outros sistemas), e as transações
que consomem determinada infraestrutura de aplicações;
Mostrar para cada transação escolhida na interface o
mapa de relacionamento atualizado, informando quais
backends participam daquela transação;
Para cada método, permitir identificar a contribuição para
os métodos caller e para a transação da qual faz parte;
Apresentar informações de transações mostrando a
tempo gasto em cada camada de aplicação sendo
invocada;
Dentre as métricas coletadas referentes às páginas web
que complementam as métricas de experiência do
usuário, devem ser informados, quando disponíveis: o
tempo médio de construção de objetos DOM (javascript);
o tempo médio de carga total da página - de quando o
TR CAPACIDADE E APM
Página 19 de 33
browser faz a primeira requisição da página até o
recebimento de todo o conteúdo;
2.1.1.36. Não deve existir limite na quantidade de transações de
negócios que podem ser monitoradas. A solução deve
permitir o cadastro de a monitoração de quantas
transações forem necessárias;
2.1.1.37. A solução deve monitorar arquiteturas SOA em diversos
frameworks e servidores de aplicação e deve mostrar um
mapa de dependência entre os serviços, consumidores,
hosts;
2.1.1.38. A solução não deve se ater somente a monitorar os itens
básicos e frameworks padrão. Deve ser possível estender
as capacidades de monitoração e criar métricas
específicas conforme a necessidade de cada aplicação.
Por exemplo, pode existir a necessidade de se criar uma
métricas exclusiva para uma classe construída em nossa
fábrica de software.
2.1.2.
Requisitos gerais
2.1.2.1.
2.1.2.2.
2.1.2.3.
2.1.2.4.
2.1.2.5.
2.1.2.6.
2.1.2.7.
DIT/GIE
Monitorar aplicações com base na instrumentalização no
nível da JVM e para tanto utilizar a tecnologia “Bytecode
Instrumentation” para monitoramento das classes
emétodos das aplicações sejam estes apresentados na
forma dos componentes-padrão da arquitetura JEE (JSP,
JSF, Servlets, EJB, EJB3, JNDI, XML, JDBC, JCA, JTA),
sejam estes componentes apresentados na forma de
classes de negócio especializadas (POJO– Plain Old
Java Objects);
Monitorar a performance das aplicações com baixo
incremento de consumo nos servidores monitorados, via
tecnologia de Bytecode Instrumentation, dentre outras
funcionalidades;
Permitir a configuração de limites (thresholds) para
qualquer dos itens e também para agrupamentos de itens
monitorados;
Associar ações aos limites (thresholds) configurados:
notificação automática por e-mail, alerta na tela do
usuário de monitoramento;
Deve ser possível a configuração de janelas de
manutenção, que é a definição de datas e horários
quando os itens estarão propositalmente indisponíveis,
situações nas quais a solução não deverá gerar alertas.
Fornecer recurso para a exportação das informações
coletadas pela solução para os formatos tradicionais de
intercâmbio de arquivos entre aplicações, pelo menos
para um formato padrão a seguir: CSV, JSON ou XML;
Fornecer acesso aos recursos do produto via interface
web (compatibilidade, no mínimo, com versões de
browsers Internet Explorer e/ou Firefox;
TR CAPACIDADE E APM
Página 20 de 33
2.1.2.8.
2.1.2.9.
2.1.2.10.
2.1.2.11.
2.1.2.12.
2.1.2.13.
2.1.2.14.
2.1.2.15.
2.1.2.16.
2.1.2.17.
2.1.2.18.
2.1.2.19.
2.1.2.20.
2.1.2.21.
2.1.2.22.
DIT/GIE
Gerar relatórios e disponibilizar gráficos via interface web
(análise em tempo de execução) a qualquer momento e
também a partir de base histórica;
Monitorar o tempo de resposta das transações
apresentando os tempos parciais por classes e métodos;
Coletar indicadores de erros na aplicação por
determinado intervalo de tempo;
Possibilitar a análise de indicadores em determinado
intervalo de tempo;
Capaz de apresentar as métricas descritas (indicadores)
de forma individualizada para cada uma das instâncias
monitoradas;
Permitir a configuração do número de transações
executadas a serem monitoradas;
Agrupar métricas de várias instâncias de uma aplicação
em uma visão consolidada das múltiplas instâncias, além
da apresentação individualizada por instância monitorada;
Permitir o agrupamento de métricas similares de qualquer
dos componentes da aplicação em um gráfico único
permitindo ainda sua ordenação e seleção dos top “n";
Permitir o aumento de visibilidade sobre a performance
da aplicação e o correlacionamento de métricas de uma
JVM isolada quanto de uma visão consolidada das JVMs
permitindo assim visão efetiva da performance da
aplicação;
Coletar informações de performance (tempo de resposta,
erros, número de execuções) em tempo real e apresentar
em forma gráfica em intervalos configuráveis, com
granularidade de, no mínimo, 1 minuto;
Gerar uma linha de base estatística para cada aplicação
monitorada que deverá representar o comportamento
habitual estatístico da aplicação;
Gerar alertas identificando a camada da aplicação
(apresentação, back-ends e recursos) onde o desvio foi
identificado,
o
comportamento
esperado
e
o
comportamento apresentado sempre que a aplicação
apresentar comportamento diferente daquele esperado
pela linha de base;
Calcular a linha de base estatística com base na hora do
dia e dia da semana;
Possibilitar a extração de informações, através de
relatórios, personalizadas e de forma interativa, sem
necessidade de uso de outros produtos para esta
atividade;
Permitir que as telas de apresentação das métricas
(dashboards) sejam facilmente personalizáveis pelos
próprios usuários de acordo com sua necessidade, sem a
intervenção de pessoal técnico especializado e também
sem a necessidade de desenvolvimento de código ou
utilização de API’s;
TR CAPACIDADE E APM
Página 21 de 33
2.1.2.23. Os alarmes de serviços devem resultar da condição de
um ou mais itens de configuração combinados
impactarem a qualidade ou nível do risco associado ao
serviço;
2.1.2.24. Permitir a definição de política para aquele modelo de
serviço que determinará como um alarme em um item de
configuração impactará outros itens de configuração e os
serviços;
2.1.2.25. Possuir uma interface de relatórios, que permita a
geração, sob demanda ou agendada, de relatórios
históricos, inclusive para impressão, para os serviços
gerenciados, contendo relatórios como:
2.1.2.25.1.
sumário de serviços - mostrar um sumário da saúde
de um serviço e a lista de paradas em um período;
2.1.2.25.2. top 10 ICs (backends) que degradem serviços –
mostrar os 10 itens que geraram downtime de
serviços;
2.1.2.25.3. disponibilidade
de
serviço
–
mostrar
a
disponibilidade para um dado serviço em um
período;
2.1.2.25.4. saúde de serviço – mostrar a saúde para um dado
serviço em um período;
2.1.2.25.5. qualidade de serviço - mostrar a qualidade para um
dado serviço em um período;
2.1.2.25.6. top 10 serviços com alto risco – mostrar os 10
serviços que durante mais tempo tiveram com risco;
2.1.2.25.7. top 10 serviços com baixa qualidade – mostrar os
10 serviços que durante mais tempo tiveram baixa
qualidade;
2.1.2.25.8. top 10 serviços com ICs degradados - mostrar os 10
itens de configuração com maior downtime de
serviço.
2.1.2.26. Deve prover métricas referentes a carga de páginas web
facilitando a identificação de gargalos - rede, browser,
servidor de aplicação;
2.1.2.27. No que diz respeito a monitoração de páginas web,
solução deve permitir a agregação de métricas por grupos
de URL;
2.1.2.28. Com o objetivo de acelerar o tempo de desenvolvimento a
solução devem prover painéis pré-construídos com as
métricas referentes a carga de páginas web;
2.1.2.29. A solução deve possuir a capacidade de descobrir e
instrumentar métodos de forma automática enriquecendo
e facilitando a investigação problemas;
2.1.2.30. Considerando a funcionalidade de instrumentação
automática de métodos, a solução deve permitir a
configuração do escopo e abrangência da descoberta;
2.1.2.31. Uma vez executada uma instrumentação automática a
aplicação deve prover forma de exportar as descobertas
DIT/GIE
TR CAPACIDADE E APM
Página 22 de 33
2.1.2.32.
2.1.2.33.
2.1.2.34.
2.1.2.35.
2.1.2.36.
2.1.2.37.
2.1.2.38.
2.1.3.
para uma posterior utilização em outros componentes
similares;
A solução deve conter funcionalidades para detecção de
erros através de análises estatísticas e detecção de
anomalias e padrões;
A detecção automática de anomalias deve permitir,
durante a investigação do problema, a filtragem dos
componentes participantes da transação;
A solução deve possuir a capacidade de mostrar,quando
existentes, transações oriundas de applicativos móveis
indicando o sistema operacional utilizado;
Deve ser possível monitorar aplicações de big data, entre
elas, MongoDB e Hadoop;
Monitorar em tempo de execução e detectar mudanças
ocorridas na aplicação (arquivos do tipo .class, .java, .jar,
.ear, .xml, .properties, etc.) e correlacioná-las com a
performance da aplicação;
Deverá prover funcionalidade de comparação diferencial
entre versões de arquivos da aplicação, baseados em
formato texto, cuja alteração tenha sido detectada pela
solução;
Deve identificar qual tipo de alteração foi implementada
bem como a data e horário onde a mesma ocorreu.
Arquitetura da solução de monitoramento
2.1.3.1.
2.1.3.2.
2.1.3.3.
2.1.3.4.
2.1.3.5.
2.1.3.6.
2.1.3.7.
2.1.3.8.
DIT/GIE
Não necessitar realizar modificações ou alterações dos
códigos fontes das aplicações monitoradas;
Não requerer a inserção de scripts no código fonte da
aplicação monitorada, com exceção do monitoramento da
camada web;
Preservar os dados históricos na mudança de versão da
solução de monitoramento, inclusive as baselines, sendo
esses visualizados na nova versão;
Monitoramento da aplicação iniciado de forma automática
juntamente com a inicialização do servidor de aplicações;
No caso de utilização de banco de dados próprio, as
licenças necessárias serão de responsabilidade da
CONTRATADA;
O processamento de dados para consolidação da base,
assim como para geração de relatórios e consultas, não
deverá ocorrer nos servidores monitorados e sim em um
servidor de gerenciamento específico para esse fim;
Servidor de gerenciamento compatível com os sistemas
operacionais Windows e Linux (nas distribuições RHEL,
Suse e Oracle Linux);
Deverá ser compatível com os sistemas de virtualização
VMware, Hyper-V, Xene RHEV;
TR CAPACIDADE E APM
Página 23 de 33
2.1.3.9.
2.1.3.10.
2.1.3.11.
2.1.3.12.
2.1.3.13.
2.1.4.
Não apresentar incremento no consumo de CPU do
ambiente monitorado superior a 5% (cinco por cento) com
coleta incluindo monitoração até nível de método no
servidor de aplicação JAVA, e sem a ocorrência de
perdas de dados coletados, com margem de tolerância de
consumo de CPU de, no máximo, 7% (sete por cento);
Possibilitar a pesquisa de erros em bases históricas sem
a necessidade de leitura de arquivos de log externos à
solução;
Armazenar 100% (cem por cento) dos dados coletados,
em base histórica pelo período de 2 (dois) anos;
Processar os dados para consolidação da base, assim
como para geração de relatórios e consultas, fora dos
servidores monitorados. Usar um servidor de
gerenciamento específico para esse fim;
É obrigatório que a solução seja escalável permitindo a
monitoração de mais de 4000 servidores de aplicação,
sem degradação de performance.
Integração com outras soluções
2.1.4.1.
A solução deve permitir monitoração de servidores
sharepoint nas versões 2007, 2010 - rodando em
Windows versões suportadas pelo sharepoint 2013 Windows 2012R;
2.1.4.2. A solução deve permitir monitoração de servidores de
mensageria IBM MQ nas seguintes versões V6.0.x, v7.0 ,
v7.1, v7.5 - WebSphereMQ Queue Manager;
2.1.4.3. A solução deve permitir monitoração de servidores IBM
Websphere Message Broker nas seguintes versões v7.0
,v8.0;
2.1.4.4. Ao monitorar o IBM MQ no mínimo as seguintes
informação devem ser providas:
2.1.4.4.1. Métricas
de
Canal
Channel
Indoubt
Status,Aggregated Channel Instance Counts,Channel
Name,Channel Type,Cluster Name,Max Message
Length,Queue Manager Name;
2.1.4.4.2. Métricas de Queue - Creation Date,Default
Priority,Max Message Length,Max Queue Depth.
2.1.4.5.
Deve permitir a coleta de informações dos servidores web
: Apache, IIS e IBM HTTP Server (IHS):
2.1.4.5.1.
Apache 2.0, 2.2, 2.4;
2.1.4.5.2.
Microsoft IIS 6.0, 7.0;
2.1.4.5.3.
IBM HTTP Server (IHS) 7.0, 8.5.
2.1.4.6. Ao monitorar os servidores web Apache ou IBM, as
informações abaixo quando publicadas devem ser
informadas:
2.1.4.6.1.
Disponibilidade;
DIT/GIE
TR CAPACIDADE E APM
Página 24 de 33
2.1.4.6.2.
Status;
2.1.4.6.3.
Bytes Transferidos por intervalo de tempo;
2.1.4.6.4.
Requisições por Intervalo;
2.1.4.6.5.
Número de ocupados;
2.1.4.6.6.
Número de disponíveis.
2.1.4.7. A solução deve possuir API REST documentada;
2.1.4.8. Com a solução deve ser possível monitorar bancos de
dados Oracle nas versões Oracle 9i, Oracle 10g, Oracle
11g (até R2), Oracle 11g R2 PS2/PS3, Oracle 12c;
2.1.4.9. Ao monitorar os bancos de dados Oracle citados acima,
no mínimo a seguintes recursos devem ser observados:
2.1.4.9.1.
Disponibilidade;
2.1.4.9.2.
Número de deadlocks;
2.1.4.9.3.
Número de full table scans;
2.1.4.9.4.
Quantidade de waits e switchs nos arquivos Redo
Log;
2.1.4.9.5.
Quantidades de taxas de get e wait em segmentos
de rollback;
2.1.4.9.6.
Tamanho do Buffer SGA - System Global Area;
2.1.4.9.7.
Taxa de sort em memória e disco;
2.1.4.9.8.
Quantidade de read/write nas table spaces.
2.1.4.10. Deve ser possível monitorar arquiteturas as plataformas
abaixo:
2.1.4.10.1. Oracle Service Bus (OSB);
2.1.4.10.2. TIBCO BusinessWorks;
2.1.4.10.3. TIBCO Enterprise Message Service;
2.1.4.10.4. WebMethods Broker;
2.1.4.10.5. WebMethods Integration Server;
2.1.4.10.6. IBM WebSphere Process Server (WPS);
2.1.4.10.7. IBM WebSphere Enterprise Service Bus (WESB).
2.1.5.
Requisitos Específicos para o monitoramento da Experiência
do Usuário Final através de transações HTTP/HTTPS reais
2.1.5.1.
2.1.5.2.
2.1.5.3.
2.1.5.4.
2.1.5.5.
DIT/GIE
Oferecer uma monitoração sem agentes baseada na
captura e decodificação de pacotes de rede, não
intrusiva;
Possuir rotina de Exportação e Importação das
configurações dos coletores;
Oferecer funcionalidade para replicar as configurações
feitas em um coletor para os demais coletores existentes
no ambiente, reduzindo assim o esforço de
gerenciamento da solução;
Possuir capacidade de executar Backup e Restore de
dados;
Permitir o cadastramento e configuração de chaves
privadas para monitoração do tráfego HTTPS;
TR CAPACIDADE E APM
Página 25 de 33
2.1.5.6.
Permitir a completa e total proteção às informações de
identificação dos usuários (ex.: usuário/senha), através do
cadastramento e armazenamento de parâmetros
http/https que são sensíveis à segurança;
2.1.5.7. Possuir funcionalidade de gravação das transações cuja
estrutura HTTP(assinatura) possa ser capturada e
promovida aos status de transação monitorada pela
solução;
2.1.5.8. A gravação e o armazenamento da estrutura de uma
nova transação não devem requerer nenhum tipo de
programação ou configuração avançada, devendo estar
disponível na interface gráfica;
2.1.5.9. Monitorar todas as transações reais que trafegam na rede
e que estão configuradas para serem monitoradas pela
solução;
2.1.5.10. Verificar se uma transação ou requisição HTTP ou
HTTPS foi atendida do ponto de vista do usuário final,
dentro dos parâmetros configurados;
2.1.5.11. Permitir a definição, para cada transação cadastrada, dos
componentes desta transação (.gif, .jpeg, .css, etc), da
sua obrigatoriedade na resposta para caracterização de
sucesso na transação;
2.1.5.12. Permitir a definição, para cada transação cadastrada, de
limites (thresholds) pelos quais os defeitos serão
caracterizados;
2.1.5.13. Permitir a definição, para cada transação cadastrada, dos
tipos de erros de execução possíveis. Ex.: HTTP 203 Erro de Comunicação, HTTP 401 - Acesso não
autorizado, etc;
2.1.5.14. Permitir a definição, para cada transação cadastrada, dos
níveis de serviço acordados para a mesma;
2.1.5.15. Monitorar 100% das transações HTTP e HTTPS reais dos
usuários, não sendo permitida monitoração baseada em
amostragem;
2.1.5.16. Fornecer as seguintes informações para cada transação
monitorada:
2.1.5.16.1.
Data e Hora
2.1.5.16.2.
Endereço IP da aplicação cliente (ex. Navegador)
2.1.5.16.3.
Endereço IP e porta do servidor web (HTTP
Server)
2.1.5.16.4.
Endereço IP do servidor de aplicação
2.1.5.16.5.
Nome do Request Handler (ex. ActionServlet) da
transação
2.1.5.16.6.
Tempo de resposta da transação
(Requisição/Resposta HTTP)
2.1.5.16.7.
Tipo de defeito detectado
2.1.5.16.8.
Condição de defeito (threshold)
2.1.5.16.9.
Valor real observado
2.1.5.16.10. Tamanho (kB)
2.1.5.16.11. Throughput (kB/s)
DIT/GIE
TR CAPACIDADE E APM
Página 26 de 33
2.1.5.16.12.
2.1.5.16.13.
Tempo até primeira resposta (s)
Parâmetros HTTP"
2.1.5.17. Capacidade de mostrar como a taxa de sucesso de uma
transação, o tempo médio, e a contagem de transações
mudaram durante um período de tempo específico, como
por exemplo, hoje em comparação com ontem;
2.1.5.18. Análise da performance das aplicações por grupo de
usuários finais.
2.1.5.19. Monitoração baseada em incidentes na experiência do
usuário permitindo a priorização pela criticidade da
transação, dos usuários e impacto ao negócio;
2.1.5.20. Forte integração com a análise de causa raiz, permitindo
conectar imediatamente um problema na experiência do
usuário com o componente da aplicação que está
causando a degradação, como por exemplo comando
SQL, chamada WebServices, programa no mainframe,
EJB, etc. Esta correlação deve ser feita transação a
transação de tal maneira a obter uma visão fim-a-fim;
2.1.5.21. Permitir a análise de problemas através do conceito de
pareto onde 20% das transações resultam em 80% dos
problemas;
2.1.5.22. Permitir a definição de acordos de níveis de serviço onde
um processo de negócio tenha percentuais associados
para a quantidade de transações que completaram com
sucesso e a quantidade de transações que completaram
dentro de um tempo estabelecido;
2.1.5.23. Em hipótese alguma a aplicação deve enviar dados para
fora do Brasil. A solução deve ser entregue no modelo
ON Premise, ou seja, com todos os servidores instalados
em um datacenter dentro do Brasil.
2.1.6.
Requisitos Específicos para o monitoramento de Ambientes
SOA (Service Oriented Architecture)
2.1.6.1.
Monitorar pelo menos os seguintes ESBs (Enterprise
Service Bus):
2.1.6.1.1.
Oracle Service Bus 3.0 (também conhecido como
AquaLogic Service Bus 3.0);
2.1.6.1.2.
Oracle Service Bus 10.3, 11.1.1.3, 11.1.1.4,
11.1.1.5, 11.1.1.7;
2.1.6.1.3.
WebSphere Process Server/ESB 7.0, ESB 7.5.1,
8.0.
2.1.6.2.
Monitorar detalhes intrínsecos ao Oracle ESB e
apresentar painéis com no mínimo as seguintes métricas:
2.1.6.2.1. Proxy Services;
2.1.6.2.2. Business Services;
2.1.6.2.3. Pipeline;
DIT/GIE
TR CAPACIDADE E APM
Página 27 de 33
2.1.6.2.4. XQueries;
2.1.6.2.5. Transports;
2.1.6.2.6. UDDI.
2.1.6.3.
Monitorar detalhes intrínsecos ao WebSphere ESB e
Websphere Process Server (WPS) e apresentar painéis
com no mínimo as seguintes métricas:
2.1.6.3.1. Business Processes;
2.1.6.3.2. Business State Machines;
2.1.6.3.3. Business Rules;
2.1.6.3.4. Java Components;
2.1.6.3.5. Mediation Flows;
2.1.6.3.6. Mediation Primitives;
2.1.6.3.7. Human Tasks;
2.1.6.3.8. Selectors;
2.1.6.3.9. Interface Maps;
2.1.6.3.10. Adapters;
2.1.6.3.11. BO Maps;
2.1.6.3.12. Relationships;
2.1.6.3.13. Selectors;
2.1.6.3.14. WPS Faults.
2.1.6.4.
Permitir o rastreamento de transações entre processos,
de tal maneira a capturar uma transação que seja iniciada
no WebLogic Portal, passe pelo ESB e chegue ao
Aqualogic Data Services. O mecanismo de rastreamento
deve ser genérico a ponto de permitir que chamadas a
quaisquer
WebServices
sejam
passíveis
de
correlacionamento, não importando a origem ou o
destino;
2.1.6.5. Permitir-se-á que o mecanismo de rastreamento insira
identificadores de correlação nas mensagens SOAP
trafegadas entre os processos, no entanto o mecanismo
deverá prover opções de onde esse identificador será
inserido, como por exemplo:
2.1.6.5.1. Na própria mensagem SOAP (no cabeçalho da
mensagem) ou;
2.1.6.5.2. No cabeçalho da mensagem HTTP que encapsula a
mensagem SOAP.
2.1.6.6. O mecanismo de rastreamento deverá suportar
mensagens SOAP v 1.1.
2.1.6.7. O mecanismo de rastreamento deverá ser próprio da
ferramenta de monitoramento, não requerendo a criação
de código customizado tanto para a inserção do
identificador de correlação quanto para a identificação
dos Web Services, exceto em casos que a pilha
WebServices não for suportada;
2.1.6.8. Monitorar cada execução de Web Service detalhando o
namespace ao qual pertence bem como a operação
DIT/GIE
TR CAPACIDADE E APM
Página 28 de 33
invocada. Isto deverá ser feito tanto para Web Services
produzidos quanto para Web Services consumidos;
2.1.6.9. Apresentar painéis de monitoramento dos Web Services
contendo gráficos Top-N com o tempo médio dos Web
Services produzidos e consumidos pelas aplicações;
2.1.6.10. Cada Web Service monitorado deverá produzir, no
mínimo, as seguintes métricas:
2.1.6.10.1. Tempo Médio de Resposta;
2.1.6.10.2. Quantidade de execuções por intervalo;
2.1.6.10.3. Concorrência;
2.1.6.10.4. Exceções na camada SOAP;
2.1.6.10.5. Exceções na camada Java;
2.1.6.10.6. Execuções “congeladas”.
2.1.6.11. Monitorar exceções de negócio geradas pela camada
SOAP como, por exemplo, “parâmetros inválidos na
mensagem”;
2.1.6.12. Monitorar o tempo de resposta médio e a quantidade de
execuções do processamento (parsing) de mensagens
XML através de XQueries;
2.1.6.13. O monitoramento do ambiente SOA deverá abranger
100% das transações e deverá estar habilitado todo o
tempo. O monitoramento baseado em amostragem ou
execução de transações simuladas não será aceito;
2.1.6.14. A solução deverá apresentar acréscimo de consumo de
CPU de até 5% sobre o ambiente SOA monitorado,
admitindo-se uma tolerância de 40% sobre este valor
(total máximo admitido de 7%).
2.2. Licenças de uso contemplando o cenário descrito no item “Ambiente
Atual PRODAM”
2.2.1. O licenciamento de uso do(s) software(s) componente(s) da solução
deverá permitir a ativação da solução no ambiente da contratante, respeitando
as seguintes condições:
2.2.1.1. As licenças de uso fornecidas referem-se ao direito de
uso perpétuo do(s) programa(s) que compõem a solução;
2.2.1.2. O número total de licenças deverá ser definido pela
CONTRATADA, de acordo com políticas de licenciamento
da empresa fornecedora da solução, com base no
ambiente da Contratante e números expressos no item
“Ambiente Atual Prodam”;
2.2.1.3. A Documentação do Licenciamento e Direito de Uso do
Software, envolvido na solução, deve ser fornecida pelo
fabricante, garantindo à CONTRATANTE o suporte
técnico e atualização do software durante todo o prazo
contratado.
DIT/GIE
TR CAPACIDADE E APM
Página 29 de 33
2.3. Serviços de Instalação, Configuração e Migração de dados
2.3.1. Toda e qualquer instalação e configuração da solução é de
responsabilidade da CONTRATADA e deve ser iniciado em até 30 dias
após a assinatura do contrato;
2.3.2. A CONTRATADA deve garantir que os dados históricos e atuais de
capacidade da solução atual instalada em ambiente CONTRATANTE
esteja disponível na solução adquirida.
2.4. Operação Assistida (hands-on)
2.4.1. A CONTRATADA deverá manter profissional capacitado no(s) produto(s)
componente(s) da solução por um período mínimo de 90 (noventa) dias,
de segunda a sexta-feira das 8:00h às 17:00h (ou a critério, negociado
entre as partes) no ambiente da contratante no intuito de atuar na
customização, operacionalização (hands-on) e suporte inicial da solução;
2.4.2. Um analista da CONTRATANTE acompanhará o profissional da
CONTRATADA durante o período de operação assistida;
2.4.3. A operação assistida será iniciada somente após a finalização da
instalação da solução em ambiente da Contratante;
2.4.4. A CONTRATANTE emitirá Termo de Aceite para fins de comprovação
após completados 60 (sessenta) dias de operação assistida.
2.5. Treinamento
2.5.1. A CONTRATADA deverá oferecer treinamento oficial da solução
implantada, no prazo de até 30 (trinta) dias corridos a contar da data de
emissão do Termo de Aceite, com o mínimo de 40 (quarenta) horas de
duração de cada produto/modulo que compõe a solução, para o mínimo
de 12 (doze) funcionários da CONTRATANTE (divididos em 2 turmas,
agendadas em datas distintas a critério da CONTRATANTE);
2.5.2. O treinamento deve ser realizado em dias úteis, dentro do Município de
São Paulo;
2.5.3. Deverá ser fornecido material impresso ou digital no idioma português ou
inglês;
2.5.4. Ao final do treinamento, os participantes deverão receber certificado de
conclusão;
2.5.5. O treinamento deverá ser ministrado por instrutores certificados pela
empresa fornecedora da solução, englobando, pelo menos, os seguintes
aspectos:
2.5.5.1. Introdução ao software (conceitos, componentes e
arquitetura);
2.5.5.2. Planejamento de uso (requisitos de ambiente para
instalação);
2.5.5.3. Instalação e configuração do produto na infraestrutura
Prodam;
2.5.5.4. Customização e gerenciamento;
DIT/GIE
TR CAPACIDADE E APM
Página 30 de 33
2.5.5.5.
Utilização, entendimento, operação.
2.6. Manutenção e Suporte Técnico 24x7
2.6.1. A Manutenção refere-se à continuidade operacional do(s) software(s)
que compõe(m) a solução adquirida dentro do período de 36 (trinta e
seis) meses contados a partir da data de emissão do Termo de Aceite,
abrangendo todas as atividades de manutenção e suporte requeridas;
2.6.2. Entende-se como suporte o atendimento, pela CONTRATADA, quanto a
informações sobre uso e funcionalidades do produto, sem custos
adicionais para a CONTRATANTE e sem limite de horas. Inclui também
as atividades consultivas para orientação à contratante quanto às
providências necessárias à possível utilização, em juízo, das evidências
detectadas através do software;
2.6.3. O atendimento para suporte e manutenção será feito pela
CONTRATADA no regime 24 x 7 x 365, inclusive nas dependências da
contratante quando necessário;
2.6.4. Os chamados para suporte e manutenção serão realizados através de
telefone ou correio eletrônico e deverão ser atendidos pela
CONTRATADA em até 3 (três) horas após o recebimento da solicitação.
Uma solução de contorno ou solução definitiva deve ser dada/aplicada
em até 8 (oito) horas;
2.6.5. Toda intervenção na solução, na atualização de versão e adequações
das funcionalidades durante o período de contrato, deverão ser
realizadas
sem
quaisquer
ônus
para
CONTRATANTE,
independentemente do serviço executado;
2.6.6. Em caso de atualização decorrente de necessidade de correção dos
produtos e atualizações de versões, quando disponibilizadas pela
empresa fornecedora do software, cabe à CONTRATADA:
2.6.7. Identificar e interpretar os defeitos apresentados pelo software;
2.6.8. Transmitir por escrito, à empresa fabricante do(s) software(s), todas as
informações relativas aos problemas encontrados no mesmo, quando
estes não puderem ser resolvidas pela CONTRATADA;
2.6.9. Transmitir por escrito, à CONTRATANTE todas as informações e
providências tomadas pela empresa fabricante do(s) software(s), no
sentido de:
2.6.10.
Determinar uma solução de contorno para defeito apresentado;
2.6.11.
Determinar como e quando será feita a correção definitiva do
defeito apresentado.
2.6.12.
Dentro do período de vigência do Contrato:
2.6.13.
Realizar as manutenções necessárias e solicitadas para que o
ambiente esteja atualizado;
2.6.14.
Entregar à CONTRATANTE o meio magnético ou senha de
download e a documentação atualizados das novas versões que
venham a ser liberadas pelo fornecedor para correções de erros que
afetem o seu funcionamento normal, ou que possuam melhorias de
performance e novas funcionalidades;
2.6.15.
Proceder à instalação e configuração necessárias.
DIT/GIE
TR CAPACIDADE E APM
Página 31 de 33
3. Confidencialidade
3.1. A CONTRATADA deverá zelar pelo sigilo de quaisquer informações
referentes à estrutura, sistemas, usuários, contribuintes, topologia, e ao
modo de funcionamento e tratamento das informações da
CONTRATANTE, durante e após fim do contrato, salvo se houver
autorização expressa para divulgação.
4. Condições de Faturamento
4.1. O valor será faturado mensalmente e o encaminhamento da Nota Fiscal
de Serviço deverá ser realizado através de Solicitação de Pagamento, até
o 5º (quinto) dia útil do mês subsequente ao da efetiva prestação dos
serviços.
5. Proposta para Condições de Pagamento
5.1. A Nota Fiscal de Serviços deverá ser emitida e encaminhada à
CONTRATANTE, através do setor de Expediente;
5.2. Após o recebimento da Nota Fiscal de Serviços, a CONTRATANTE
disporá de até 05 (cinco) dias úteis para emissão do Termo de Aceite,
aprovando os serviços prestados;
5.3. Além de cumprir todas as legislações atinentes à sua constituição e aos
serviços prestados, a CONTRATADA deverá apresentar, a cada pedido
de pagamento que efetue, juntamente com a Nota Fiscal de Serviços,
todos os documentos que comprovem a regularidade fiscal da empresa,
apresentadas no início desta contratação, no original ou cópia com os
respectivos originais para comprovação de autenticidade;
5.4. O pagamento será realizado por intermédio de crédito em conta corrente
ou por outra modalidade que possa vir a ser determinada pela Gerência
Financeira (GFI), em 30 (trinta) dias corridos a contar da data de emissão
do Termo de Aceite;
5.5. A CONTRATANTE promoverá, previamente a qualquer desembolso em
benefício
da
CONTRATADA,
a
verificação
no
site
http://www3.prefeitura.sp.gov.br/candin/ de qualquer pendência no
Cadastro Informativo Municipal (CADIN) da Prefeitura do Município de
São Paulo, sendo que se for verificada a existência de registro no CADIN
em nome da CONTRATADA, incidirão as disposições do artigo 3º da Lei
Municipal n.º 14.094, de 06 de dezembro de 2005, suspendendo-se o
pagamento enquanto perdurar o registro, ressalvadas a hipótese prevista
no artigo 9º do Decreto Municipal n.º 47.096, de 21 de março de 2006;
5.6. Caso a Nota Fiscal/Fatura contenha divergências com relação ao
estabelecido no Instrumento Contratual, a CONTRATANTE ficará
obrigada a comunicar a empresa CONTRATADA, formalmente, o motivo
da não aprovação no prazo de 05 (cinco) dias úteis. A devolução da Nota
Fiscal/Fatura, devidamente, regularizada pela CONTRATANTE, deverá
ser efetuada em até 05 (cinco) dias úteis da data de comunicação formal
pela CONTRATADA;
5.7. Em caso de atraso de pagamento dos valores devidos à CONTRATADA,
mediante requerimento formalizado por esta, incidirão juros moratórios
calculados utilizando-se o índice oficial de remuneração básica da
DIT/GIE
TR CAPACIDADE E APM
Página 32 de 33
caderneta de poupança e de juros simples no mesmo percentual de juros
incidentes sobre a caderneta de poupança, para fins de compensação da
mora (TR + 0,5% “pro-rata tempore”), observando-se para tanto, o
período correspondente à data prevista para o pagamento e aquela data
em que o pagamento efetivamente ocorreu.
6. Considerações Gerais
6.1. As soluções que compõem o objeto deste Termo de Referência podem
ser ofertadas através de 1 (uma/um) ou mais ferramentas/softwares,
desde que atendam aos requisitos exigidos;
6.2. Todos os recursos de software e mão-de-obra necessários para a
prestação dos serviços objeto deste edital (mídia de instalação, manuais,
licenças de uso, treinamento, e outros se necessários) serão fornecidos
pela CONTRATADA, devendo ser instalados na sede da CONTRATANTE
(Av. Francisco Matarazzo,1500 – 14º andar - Barra Funda – SP), toda a
solução será mantida e configurada pela CONTRATADA pelo tempo
contratado.
7. Critérios técnicos de julgamento/Documentos de habilitação técnica
7.1. Apresentar atestado de capacidade técnica, passado em papel timbrado,
por entidade pública ou privada, que comprove o correto cumprimento de
obrigações e serviços, pertinentes e compatíveis com o objeto do TR,
devidamente datado assinado e com identificação do atestante.
São Paulo, 14 de Outubro de 2015.
Gilson Santos Chagas
Gerência de Estratégia e Desenho do Serviço (GIE)
DIT/GIE
TR CAPACIDADE E APM
Página 33 de 33