Poema 7
Tão distante a rosa clara
Tão distante o amor afaga
No instante seu perfume deixa
No outro sua boca marca
Tão distante seus olhos choram
Tão distante sua boca treme
No instante quero que me ame
No outro quero que me deixe
Tão distante fico a sua espera
Tão distante a tristeza mata
No instante seu desejo arde
No outro seu gemido cala
Poema 6
Devoro-te o corpo nu
Não por amor
Pela fome que a paixão me traz
De seu corpo
Deslizar os lábios em seu ventre
Sentir a sutileza de seu corpo
Ouvir nos seus gemidos a entrega
Devora-me com a mesma fome
Não por que me amas
E sim por que a paixão da fome
E a fome do meu corpo ao seu
Poema 5
De que vale o amor então
Se não é tratado com tal zelo
Deixa de amar pelo medo
De que vale o amor então?
De que vale meu coração
Se em tua mão não posso deixar
Mais vale parar de batê-lo
Ou talvez no lixo entregar
De que vale meu corpo
Se não é para teus olhos admirar
Se tuas mão não são as que tocam
Não hei de um corpo mais precisar
De que vale minha alma impura
De romances e desejos enraizar
Se de minha alma com a tua não está mais junta
Então sem alma sem paz irei ficar
De que vale o amor então?
Poema 4
Não suspire agora,
A eternidade de um suspiro a outro
Corre o sussurro de meus desejos em teu corpo
Por mais um suspiro e outro
No seu suspirar acelerado
Procurar os lábios secos de paixão
E matar a sede, em seu corpo rubro
Não amar mais que um minuto
E viver em eterna paixão
No revolto desejo
Não mais de amor caíram
Mais que o primeiro beijo
Mais que uma simples tensão
Foge de mim o desejo
Num ultimo suspiro, a ultima canção.
Perco meus olhos em teus olhos
Tua boca a procurar
Somente sonhos ou devaneios
Mais uma noite para te amar
Perco meu corpo no seu corpo
Perco minha alma no te desejo
Apenas seus olhos para me fazer chorar
Hei de ter a ti por mais uma noite
Por mais uma noite se perder em ti
Por mais uma noite hei de sonhar
Não mais que um sonho de poder te amar
Uma pesquisa divulgada nesta quinta-feira pela Associação dos Magistrados Brasileiros (AMB) mostra que apenas 11% dos brasileiros confiam nos políticos e 16%, nos partidos políticos. Ainda segundo a pesquisa, Polícia Federal e as Forças Armadas são as instituições mais confiáveis, com a aprovação de, respectivamente, 75,5% e 74,7% dos entrevistados.
Poema 4
Não suspire agora,
A eternidade de um suspiro a outro
Corre o sussurro de meus desejos em teu corpo
Por mais um suspiro e outro
No seu suspirar acelerado
Procurar os lábios secos de paixão
E matar a sede, em seu corpo rubro
Não amar mais que um minuto
E viver em eterna paixão
No revolto desejo
Não mais de amor caíram
Mais que o primeiro beijo
Mais que uma simples tensão
Foge de mim o desejo
Num ultimo suspiro, a ultima canção.
Poema 3
Beijo-te a boca cálida
Beijo-te a lua nua
Seco-lhe as gotas da chorosa chuva
Não foi a brisa prazerosa
Que trouxeste seu perfume
Foi a noite escura
Que cobria a pele nua
E trouxera seu amar
Se não foste outro amor
Não seria mais verão
Hei de entristecer a primavera
E amar outro verão.
Poema 2
Insensatez eu diria
Acordar contigo em meu peito
Dormindo ainda ao relento
Tão insensato quanto imperfeito
Fazer não por volúpia
Queimar não por prazer
Arder não porque é chama
Cometer pecados, só para viver
Não amas o insensato ao lado
Morrer de amor os insensatos são jurados
Levantar e amar de novo
Cometer o mesmo erro tolo
Não que para amar precise de tato
Apenas para ser mais um insensato
Poema 1
Não existe beijo que sacia os lábios desejosos,
Não existe corpo que sacia o toque quente,
Não existe alma que sacia o coração vazio,
Deslizar-te a mão em sua face pálida,
Tocar os lábios, no seu corpo úmido,
Sentir o tremor, do desejo ardente,
Amor? Mais que o calor
Mais que o desejo
Não existe..
Não existe amor que sacia, eternamente....
Na parte 1 deste artigo, discutimos a respeito de como entender o comportamento dos usuários e modelá-lo em linguagem matemática para um exemplo de aplicação de ponto, porém o princípio é aplicado a qualquer aplicação, e o que será de extrema valia para quando terminarmos de avaliar o desempenho da aplicação bem como o hardware necessário, pois este conhecimento compilado em uma planilha Excel nos permitirá amanha, em alguma eventualidade fazer de traz para frente às perguntas que passarão a ser mais freqüentes durante a vida útil do sistema: se eu aumentar em 1.000 usuários o sistema, mantendo a infra-estrutura atual, qual será a degradação esperada que obteremos no tempo de resposta? Se adicionar um passo extra no processo de ponto, como sensibilizar uma segunda base de dados, qual será o impacto para o usuário final, bem qual seria o investimento em hardware necessário, e onde especificamente deverei investir, para que amortize essa degradação no tempo de resposta.
Breve consideração sobre virtualização
Quando estamos falando de visão de futuro em TI, onde se busca a construção de uma infra-estrutura de TI que seja capaz de responder em tempo real, ou seja, que a área de tecnologia seja capaz de definir acordos flexíveis de SLA com as áreas de negócio da empresa que dependem de sistemas, ie. definir um tempo de resposta no sistema para usuários e clientes, e em caso de uma situação atípica como uma campanha que aumente a demando do sistema, um ataque DDOS ou qualquer outro evento de demande muito mais do sistema de que ele estava inicialmente desenhado, isto é, buscar resilience.
Com as tecnologias correntes e disseminadas, todo o sistema repousa sobre um hardware monolítico, a aplicação usa todos os recursos que aquela máquina disponibiliza, faltando ou sobrando é o que está alocado estaticamente para aquela aplicação o que nos coloca em posição de lidar com alguns dilemas do tipo: se eu considerar o dimensionamento de hardware para a pior situação e que sua ocorrência seja esporádica e previsível, como declaração de imposto de renda, promoção, natal, etc. estaremos subutilizando nossos recursos computacionais fora destes picos de uso, porém as tecnologias de virtualização estão quebrando este paradigma, colocando a disposição a possibilidades de alterar dinamicamente a alocação de recursos de máquina (eg. CPU, Memória, I/O de disco e rede).
Mesmo com a virtualização a nossa disposição ainda nos falta entender como usá-la como uma arma de gerenciamento de forma efetiva. O bom dimensionamento de capacidade é fundamental para poder avaliar como dividir o hardware físico em partições lógicas para bom dimensionamento de capacidade, e a modelagem desta compilada nos permitirá tomar melhores decisões quando precisarmos rever o SLA.
No futuro teremos ferramentas mais completas, que analisará o histórico de desempenho e poderá predizer de forma mais completa e avaliando um conjunto maior de variáveis qual é a situação atual e qual será a conseqüência “se” isso ou aquilo acontecer, para melhor guiar na tomada de decisão de alocação de recursos de TI, como é o caso do System Center Capacity Planner 2006, porém ele hoje está restrito somente ao Microsoft Operations Manager e ao Microsoft Exchange Server, não lida ainda com a sua aplicação LOB que sua empresa desenvolveu.
A abordagem que apresentamos aqui é uma alternativa razoável e viável para fazer este trabalho do “what-if” de forma satisfatória, utilizando os recursos de TI atualmente disponíveis no mercado e que nos aproxima um pouco mais do nível de maturidade de infra-estrutura virtualizada dentro do modelo do Gartner. (este pode ser o tópico de outro post).
Analisando a Aplicação
O segundo ingrediente na analise de capacidade é conhecer o comportamento da aplicação sob carga, o que nos interessa neste teste é saber qual é o consumo de hardware para a execução de uma “transação”, e para isso iremos precisar primeiro eleger qual ferramenta iremos utilizar para tal, e como já era de se esperar, neste caso vou utilizar o WAST (MS Web Application Stress Tool), primeiro porque é simples, didático e gratuito, só por isso Depois de definidas as ferramentas, vamos montar o laboratório para analisar a aplicação, e para tanto precisaremos somente de um servidor equipado com caracteristicas semelhantes das que será utilizado na produção, ou seja, se a produção estiver com Xeon 5355 por exemplo, use o mesmo no teste de laboratório, essa é uma recomendação que faço, pois nos dias de hoje, não dá mais para fazer uma simples regra de três com o clock para estimar o desempenho, existe o números de núcleos, o compartilhamento de cache entre os núcles e a microarquitetura do processador que influência no desempenho, portanto a opção de usar o mesmo processador será para eliminar essas variáveis de nossa análise e tornar a “equação” mais simples, o mesmo vale para a configuração de discos e memoria suficiente para não ser gargalo.
Depois do laboratório montado, podemos iniciar os testes de carga sobre o sistema usando o WAST (veja tutorial completo), o resultado final será um relatório gerado pelo WAST em que descreve o resultado do ponto de vista do cliente, ie. quantas requisições ao servidor foram feitas e quantas foram atendidas em qual tempo, quantas não foram respondidas, etc. Outra informação importânte para a nossa análise são os impactos desta carga sobre o servidor, principalmente os seguintes índices:
• Web Service: Get Request/sec
• Web Service: Post Request/sec
• System: % Total processor time
• Active Server Pages: Request/sec
É importante afinar o teste de carga para que o número requisições realizadas pelo cliente não tenham como retorno erros como 404, 400 ou 500, pois significa que o cliente não foi atendido e claramente houveram mais requisições das que o servidor poderia atender, mesmo que o servidor web apresente recursos como CPU, I/O de disco e memória em condição confortável, pois muitos dos problemas que já me defrontei nestas condições apenas escondiam problemas de configuração e ajustes para harmonizar todo o sistema, pois por exemplo: na configuração padrão do IIS, ele permite até 25 threads por núcleo, se a aplicação necessita fazer alguma chamada ao banco de dados ou algum componente externo, aquela thread irá ficar alocada enquanto não houver retorno e a “transação” ser concluida, portanto em casos onde você tenha muitas requisições/segundo e uma lentidão para concluir a “transação”, mesmo tendo CPU disponível, não haverá thread para atender requisições e você receberá um ERRO 500: Server Busy, e portanto será ainda necessário fazer ajustes no IIS para garantir que ele esteja otimizado para as caracteristicas da sua aplicação, para isso recomendo a longa leitura do IIS 6.0 Performance and Tuning ou The Art and Science of Web Server Tuning with Internet Information Services 5.0, porém sem dúvida nenhuma será recompensadora.
Concluindo o teste de carga com sucesso e eliminando todos os problemas de ajustes, será necessário interpretar os dados que temos em mãos. Vamos imaginar hipoteticamente, apenas para trabalhar com um exemplo, que ao final do nosso teste obtivemos o seguinte conjunto de dados:
• System: % Total processor time: 92% na média durante o periodo de testes, com vários picos de 100%. Isso nos permite concluir de forma razoável que houve esgotamente da CPU;
• Active Server Pages: Request/sec: 152, porém para essa aplicação específica, onde é necessário entrar na página, se identificar e selecionar uma ou duas opções antes do POST, requer 8 requisições ASP até completar o processo de “bater o ponto”, portanto temos que é possível neste cenário realizar 19 (152/8) transações por segundo;
Calculando o tempo de resposta
O Teorema Little (LT) define que podemos calcular a capacidade de atender a requisições em uma rede como a razão entre a taxa de requisições sobre a taxa de requisições que podem ser processadas. Se o sistema chega a um ponto onde a razão se torna maior que 1, então nós excedemos a capacidade de atender mais requisições, portanto ou perderemos a requisições (Erro 500) ou teremos que enfileirá-la para ser atendida em algum momento. Portanto podemos com isso definir em que ponto o nosso sistema irá falhar. Se definirmos algum enfileiramento , a razão poderá exceder até o ponto onde houver cache para aceitar requisições, e eventualmente essa razão voltar a ficar abaixo de 1 por tempo suficiente para liberar o cache. Se na média durante o tempo essa taxa exceder a 1, o sistema irá começar a recusar requisições.
A figura abaixo determina o número de requisições que podem ser mantidas na fila e o tempo que uma requisição precisará esperar para ser atendida
Aplicação do LT (λ=taxa de requisição de Poisson, μ=capacidade de processamento de requisições, p=λ/μ ).
É neste ponto onde a probabilidade de Poisson se torna realmente útil. Podemos selecionar a taxa de requisições baseado na probabilidade de multiplos usuários acessarem o sistema simultaneamente, onde só com a média de requisições que encontramos com a curva de Gauss, porém não nos dava o pior caso que é exatamente o que procuramos. Agora podemos prever não só a média de requisições que podemos atender bem como tempo máximo que o usuário precisará esperar para que a requisições seja atendida.
Definindo o Ambiente:
Chegando a esse ponto já temos bastante informação a respeito de como funciona o sistema e como ele se comporta sob carga, portando concluimos a seguinte tabela e seu gráfico correspondente:
Sabemos ainda que pela probabilidade de Poisson, termos 19 usuários simultaneos requisitando o registro de ponto é de 1x10^-14 em termos percentuais, portanto acho que podemos considerar “pouco provável” :) Infelizmente o nosso trabalho muitas vezes não pára por aqui, pois se for necessário dimensionar o sistema para um número maior de usuários, por exemplo, será ainda necessário nos testes de carga determinar se o sistema consegue escalar linearmente com o aumento de processadores/máquinas, o que normalmente ocorre com aplicações stateless, ou se haverá penalidades, o que pode ocorrer em situações onde você tem um banco de dados ou um componentes que represente um gargalo na transação.
Bem… gerenciamento de capacidade é uma tarefa contínua e não existe regras fixas, mas sim boas práticas, das quais procurei nestes dois posts do blog compartilhar um pouco com vocês.
Texto retirado de: http://blogs.intel.com/brasildigital/2007/09/gerenciamento_de_capacidade_pa_1.html
comentado por Bruno Domingues em agosto 3, 2007
Depois de algum tempo resistindo a criar um blog, eu me rendi a essa oportunidade de escrever aqui no blog da Intel em nossa língua pátria. Meu nome é Bruno Domingues, tenho 28 anos, moro em Brasília e trabalho no segmento de governo da Intel, como Especialista de Soluções. Trago uma experiência de 8 anos em função similar na Microsoft, portanto esperem muitos exemplos e comentários nesta plataforma, pelo menos até perder o “vício”.
Vou procurar postar aqui tanto os meus comentários a respeito de notícias, tecnologia e links que eu julgar interessante, sempre do meu ponto de vista, que algumas vezes pode não ser o ponto de vista da Intel, afinal este é um blog. Tenho especial interesse em arquitetura e governança de TI, virtualização, gerenciamento de capacidade/avaliação de desempenho e segurança de forma geral.
Comentários são sempre bem vindos, e pelo fato de estar quase sempre conectado não se assustem se eu responder rapidamente.
Após minha apresentação como preâmbulo, vamos ao que nos interessa: gerenciamento de capacidade para aplicações web.
A arte de estimar a infra-estrutura necessária para uma dada aplicação web pode ser uma tarefa ardilosa se você tem o orçamento restrito, precisa acertar na primeira vez e sua empresa tem grandes expectativas no sucesso do empreendimento, sem muita margem de manobra para qual configuração apostar.
Os primeiros passos a serem dados nesta direção serão conhecer o comportamento dos seus usuários, ou pelo menos tentar predizê-lo, e também conhecer sua aplicação, ie. funcionamento, consumo de recursos computacionais, tempo de resposta, comportamento em sessões concorrentes etc…
Conhecendo o seu usuário:
O primeiro passo para um bom planejamento de capacidade, começa em conhecer bem o seu usuário, quando ele acessa o seu sistema, por quanto tempo ele permanece interagindo com a aplicação bem como ele interage e, mais importante de tudo, qual o tempo de resposta que ele espera.
Para ser didático, vamos trabalhar com o exemplo de uma aplicação de ponto, onde cada funcionário da sua empresa irá precisar efetuar logon na aplicação e dar aceite no horário que estará sendo apresentado na aplicação, porém neste momento vamos abstrair um pouco os detalhes da aplicação e vamos nos concentrar nos usuários.
Pelo fato da aplicação ser um sistema de ponto, é de se esperar que os usuários tenham seus picos de utilização no inicio da manhã quando estão chegando ao trabalho, no período de almoço e ao final do dia. Vamos aqui a título de ilustração assumir que a empresa tenha 5.000 funcionários e que obviamente nem todos efetuam logon ao mesmo tempo em suas estações de trabalho, pois sempre há os atrasados, aqueles que chegam mais cedo por deixarem primeiro os filhos na escola, tem o tempo do elevador, do café e de estacionar o carro, o que faz com que tenhamos uma distribuição no tempo do acesso destes usuários ao sistema, o que nos faz pelo bom senso desprezar a pior das situações, que seria 5.000 usuários acessando ao mesmo tempo o sistema, porém se a pior situação não é ter 5.000 usuários pendurados ao mesmo tempo no sistema, qual seria o razoável?
Para responder a essa pergunta pode-se estimar o pico de acesso dos usuários usando a curva Gauss, pois é um modelo que parece aderir bem à natureza do problema e dai já é o ponto de partida para criar o jogo de “what-if”.
A figura 1 representa o gráfico de uma razoável predição do comportamento de hits no sistema em um dia útil, e permite facilmente deduzir porque usar a curva de Gauss para modelar a carga no site web.
Embora o conjunto de dados levantados me traga os dados em horas, o que realmente importa aqui é quanto tempo o usuário precisará esperar para o servidor responder, ou pela lógica reversa, qual será o hardware necessário para que o usuário tenha resposta em até um tempo limite, considerado máximo (assumindo que não há otimizações a serem realizadas na aplicação), portanto é preciso calcular o número de hits/segundo no pico da nossa curva.
Para tal, vejamos a figura 2 que representa a equação da curva de Gauss. A variável y representa o número de usuários em um determinado momento e σ é o desvio padrão. Para aqueles que não têm dedicado muito tempo a estatística ou já não se recordam muito a este respeito, o desvio padrão representa a distância do centro da curva que contém 68% dos elementos do conjunto. Em se movendo três vezes o desvio padrão do centro da curva, 99,7% dos elementos estarão cobertos. O símbolo µ é a localização do centro da curva ou a média. x representa o número de elementos a direita ou esquerda da média.
A curva de Gauss precisa agora estar aderente a nossa estimativa, para tanto é necessário multiplicar a unidade da curva pelas requisições estimadas, e ainda deve-se trabalhar o desvio padrão para obter maior aderência ao conjunto de dados. O resultado final, portanto é a freqüência de usuários por segundo no ponto médio da curva, conforme apresentado na figura 3, onde usei uma planilha eletrônica para realizar tais manipulações estatísticas.
Olhando para o sistema de ponto com mais critério, parece muito ingênuo pensar que uma empresa com 5.000 funcionários de fato tenha em algum dia do ano 5.000 funcionários trabalhando num dado dia, pois existem as férias, licença-médica, maternidade, treinamento, viagem de negócio, trabalho externo etc. portanto vamos adotar de forma “heurística” um ponto de corte conservador, imaginemos 80% dos contribuintes da empresa, ie. 4.000 funcionários, que seria neste caso pior cenário. Mas, para se chegar a estimativa de usuários simultâneos acessando o sistema, iremos recorrer a outra ferramenta de probabilidade e estatística: a distribuição de Poisson.
Poisson é um dos métodos para modelar o uso. A teoria por trás da probabilidade de Poisson é que as requisições ao sistema obedecem a uma curva exponencial para solicitações simultânea de outros usuários. Usando a média, que encontramos na curva de Gauss (1,22 usuários/segundo em média) há uma alta probabilidade que 0, 1, 2 e 3 usuários acessem o sistema simultaneamente com o período de tempo escolhido, porém a probabilidade de seis ou mais usuários acessando o sistema simultaneamente cai drasticamente, conforme figura 4.
Na figura 5, µ é a média do número de usuários requisitando acesso ao site por unidade de tempo. Este número é derivado da fórmula de Gauss. O termo x se refere ao número de usuários entrando no sistema no período.
Podemos utilizar uma planilha eletrônica comum novamente para nos prover a distribuição de Poisson não cumulativa, conforme apresentado na figura 6.
Agora que chegamos a estimativa da razão de acesso, que modela em primeiro nível o lado dos usuários, devemos prestar atenção agora para o lado do servidor, ie. aplicação e hardware para completar o tripé que dão base a qualquer gerenciamento de capacidade, porém este será o tema da parte 2 deste assunto.
De acordo com algumas literaturas, a função do setor de TI é a prestação de Serviço seja dentro de uma empresa ou para um cliente. Todos esperam um serviço desse setor, cuja area implementa vários módulos como em qualquer setor de uma empresa, um deles é o setor de Suporte.
O Suporte é uma das peças criticas do setor. Ele lida diariamente com seu cliente, portanto um erro nesse setor pode influenciar toda a relação da empresa fornecedora de serviço com seu cliente.
Ha dois meios de se trabalhar no suporte: pró - ativamente ou defensivamente, resumindo, o suporte pró-ativo atende o cliente e continua seu trabalho no sentido de prevenir o surgimento de novos problemas; o suporte defensivo é que espera seu cliente chamá-lo para atendê-lo fazendo com que ele foque seu ponto naquele problema especifico.
Independente do modelo de atendimento, o suporte tem que atender as necessidades do cliente, que basicamente são:
- Atendimento Rápido
- Qualidade de atendimento
- Atendimento Eficaz
Não abordarei os tipos de atendimento nesse texto, deixarei para um próximo, pois é um assunto um pouco extenso.
A equipe de suporte precisa conhecer os tipos de clientes, para atendê-los da melhor forma, e para que eles não comecem a achar que o produto tem problemas demais, pois o cliente tende a achar que nunca estar errado. Esse é um dos tipos de clientes que vou descrever a seguir de acordo com o perfil de clientes traçado por Castro Filho (2003 p.58-62).
Usuário Terrorista
Ele nunca esta satisfeito com nada, a culpa é sempre do sistema. Não satisfeito em criticar negativamente o setor, ele espalha para o resto da companhia que tudo que atrasa o serviço na empresa é a informática. Sempre expondo o setor ao ridículo, e fazendo piadinhas, fica minando a credibilidade do setor perante aos outros usuários. O melhor jeito de lidar com um usuário terrorista é expô-lo aos seus companheiros, mostrando que o que ele está afirmando não é verdade. Ele não se adequa ao sistema e coloca suas falhas como culpa da área de TI. Agir com esse usuário da forma anteriormente citada convence o usuário ir mudando de atitude aos poucos.
Usuário Problema
Tudo para ele é um problema, ele reclama desde o atendimento que não é rápido suficiente até o erro da palavra que não foi corrigida pelo Word. Diferente do terrorista, ele não fala mal do setor mas sempre diz que tem algum problema. A melhor maneira de se lidar com este usuário, é atendê-lo de acordo e mostrar de forma didática que nem todos os problemas são do sistema e sim do mau uso dele e da falta de treinamento dos funcionários.
Usuário Neutro
Ele nunca está certo do problema, não critica o sistema, mas também não faz elogios e não participa ou agrega ao setor. O melhor jeito de interagir com esse usuário, é trazê-lo para o nosso lado, mostrar o funcionamento do sistema para que ele tenha idéias e que ajude no desenvolvimento do sistema. Sanar suas duvidas não é o suficiente, ele deve se sentir parte da equipe.
Usuário Mente Aberta
Ele está sempre aberto às novidades do setor, e entende o processo de evolução do sistema. É criativo, gosta de interagir com o setor, fornece idéias e participa ativamente quase como se fosse da equipe. Este usuário merece ter uma atenção especial, ele tem um grande potencial, pode ajudar no setor e fazer com que ele agregue valor a TI. Ele já tem afinidade com o setor e pode ser um grande aliado quando a TI for responsabilizada por algum erro não cometido.
Usuário Fã
Usuário fã é aquele que nunca discorda das decisões tomadas pelo setor de TI, apóia todos os procedimentos, incentiva a criação de novos sistemas. Defende sempre a TI, mesmo ela estando errada. É um usuário que deve bem cuidado.
Usuário Dependente
Esse é um tipo usuário não citado pela bibliografia mas que achamos importante incluir pois foi identificado em pesquisas mais recentes. O usuário dependente é um usuário comum: ele é bem atendido, e de tão bem atendido ele acaba criando dependência do setor. Para fazer qualquer coisa desde mudar a posição do monitor a fechar um programa, ou uma pagina na internet com falhas, ele se dirige ao setor para pedir para o suporte fazer por ele. Quando não atendido ele fica contrariado, pois primeiramente foi atendido como se fosse uma criança, e agora ele é atendido como um profissional. O melhor jeito de lidar com esse usuário é aos poucos desacostumá-lo do atendimento “Mãe – Filho”. Ele tem toda a capacidade de resolver problemas corriqueiros sozinho, o suporte é para auxiliá-lo não para fazer por ele.
Estes são, em resumo, os perfis de usuários mais comuns em empresas de qualquer porte. Não é difícil encontrá-los, traçar o perfil do usuário de sua empresa facilita não só o atendimento a ele, como agiliza os processos do setor de TI e suporte.
Saber lidar com seu usuário é saber lidar com sua empresa.
Vinicius de Moraes
Eu te peço perdão por te amar de repente
Embora o meu amor seja uma velha canção nos teus ouvidos
Das horas que passei à sombra dos teus gestos
Bebendo em tua boca o perfume dos sorrisos
Das noites que vivi acalentado
Pela graça indizível dos teus passos eternamente fugindo
Trago a doçura dos que aceitam melancolicamente.
E posso te dizer que o grande afeto que te deixo
Não traz o exaspero das lágrimas nem a fascinação das promessas
Nem as misteriosas palavras dos véus da alma...
É um sossego, uma unção, um transbordamento de carícias
E só te pede que te repouses quieta, muito quieta
E deixes que as mãos cálidas da noite encontrem sem fatalidade o olhar
[ extático da aurora.
Texto extraído da antologia "Vinicius de Moraes - Poesia completa e prosa", Editora Nova Aguilar - Rio de Janeiro, 1998, pág. 259.
