Após a minha última publicação, quando finalizei a abordagem de alguns conceitos chave e introduzi métricas de capacity planning, coincidentemente passei por uma auditoria pesada, realizada por uma entidade externa à empresa, com forte orientação a processos e metodologia. Sem dúvida um teste para saber se o que eu escrevo ao meu leitor está indo na direção correta, aderente, e não é um tiro n’água.

Para
minha alegria, e posso considerar que a de todos os que me acompanham,
todos os pontos que a auditoria identificou foram classificados como de
baixo risco, e os de médio diziam respeito a investimento em ferramentas
e contratações, ou seja, em termos de metodologia de processo de
capacidade, foi classificado com um alto nível de maturidade – uma
vitória, já que partimos do zero e hoje temos indicadores e fortes
controles estabelecidos, tanto em acompanhamento de negócio como em
planejamento de TI. 

Mas,
durante o processo, foi chamada a atenção em particular para um ponto
que estava a caminho e conseguimos reverter. Tratava-se especificamente
de uma indicação de que não fazíamos cálculos usando alguns parâmetros
recomendados no manual do fabricante para, por exemplo, o cálculo da
memória, ou dimensionamento de CPUs por ciclo, e sim estávamos levando
em conta as métricas do TPC.

Esse
ponto gerou uma discussão conceitual longa, afinal, qual a melhor
maneira de realizar os cálculos e as projeções de planejamento de
capacidade? Práticas fornecidas em manuais do fabricante ou o padrão
do TPC, que leva em conta um conjunto de fatores, como sistema
operacional, banco de dados, entre outros fatores?

Ao
final, a auditoria reverteu o ponto e cedeu a boa e velha estatística. É
claro que as técnicas recomendadas no manual do fabricante são
importantes e aplicáveis, porém foi consensualmente aceito que são
restritas a um único universo, e quando tratamos de capacity plannig
de ambientes multidisciplinares, com diferentes tipos de sistemas
operacionais, modelos de hardware, bancos de dados e aplicações de middleware, não
conseguimos com facilidade operacionalizar todas as técnicas de
dimensionamento requisitadas pelos fabricantes, por isso o TPC é uma
ferramenta valiosa.

Dada
essa importância, pretendo apresentar brevemente a vocês um exemplo
simples de planejamento de capacidade para a CPU de um servidor fictício
(que poderia ser qualquer SO/Database) baseado em estatísticas de
regressão usando as regras do TPC e o MS-EXCEL.

Não
pretendo fazer deste artigo um guia de como executar as projeções ou
as predições usando Excel ou apenas apresentar quais dados devem ser
levados primariamente em consideração para executar qualquer trabalho
dessa natureza. Sabendo a metodologia, a ferramenta é irrelevante, o
importante é a análise realizada sobre os dados.

Para realizar as projeções, precisamos inicialmente conhecer e ter estruturado (conf. abordamos nos artigos anteriores):

1. Conhecer o tpmC do servidor: nesse caso, usaremos um valor de exemplo de 65.000 tpmC x core.
2. Conhecer o volume de negócio que afeta o serviço de TI: nesse caso, hipoteticamente foi atribuído um valor a um consumo de recursos de forma a exemplificar o processo.
3. Possuir um histórico de consumo e de volume executado:
   em nosso exemplo, estou projetando a partir do mês 08/11 até o final do
   ano, com base no volume informado o consumo do servidor e,
   adicionalmente, o “limite” de capacidade do servidor (quanto de volume o
   servidor suporta até atingir o threshold pré-definido por capacity planning).

O Resultado é a tabela 1, para chegarmos nesses números fizemos basicamente os seguintes passos:

1. Quanto
   em tpmC significa o consumo percentual de CPU (indicador de estamos
   projetando), esse calculo se obtém multiplicando o total de tpmc do
   servidor pelo % de recursos consumidos.
2. Criar
   a projeção com base nos dados realizados, para isso usamos a função
   para regressão linear “proj.lin”, que permite aproximar 2 grupos
   distintos de variáveis.
3. Buscar
   um R² próximo a 1, e caso não seja possível achar um R² alto, buscar
   um, aplicar a função DISTF, que deve retornar a probabilidade de
   distribuição F, que representa a probabilidade de não ser por acaso o
   valor de R² obtido entre Volumetria x tpmC (apresenta um indicador mais
   confiável).

Em nosso caso, para a tabela abaixo, temos os seguintes indicadores:

• R²: 0,726
• F:  15,93
• Probabilidade F: 0,99

Ou seja, uma alta probabilidade da volumetria estar relacionada ao consumo de tpmC

 

Graficamente podemos representar de forma assertiva:

 

Obrigado
e até a próxima, quando falaremos de performance e desempenho e o quanto
isso pode reduzir de custos e esforços dentro da organização.