Por Leon Adato
Uma das vantagens de ser um veterano com 30 anos de TI é que posso valorizar certas consistências no setor. E, às vezes, esse prazer vem com uma generosa dose de ceticismo.
Por exemplo, o termo "big data" é a palavra da moda agora, bem no início da lista com outras expressões queridas das ofertas de fornecedores de TI. Mas é claro que "big data" existe há muito mais tempo do que levou para chegar às listas de "como podemos usar isso para vender?" dos departamentos de marketing. Na verdade, o conceito remonta a meados dos anos 1990.
No entanto, este não é um artigo sobre a história do termo "big data".
O motivo de eu trazer à tona a história desse termo é o contexto. Na época em que John Mashey e seus amigos estavam sentados à mesa de almoço da Silicon Graphics e aplicaram o termo de acordo com nossa compreensão atual de coleta e armazenamento de dados, armazenar um terabyte de dados custava em torno de US$ 280 mil. Isso presumindo, é claro, que você tivesse uma matriz em que coubessem tantas unidades. Lembre-se que foi em 1997 que a IBM lançou sua unidade de disco rígido "Titan", que contava com 5 bandejas de 3,5" que sustentavam o que então era uma enormidade: 16 gigabytes de dados.
Por isso, tenho de me perguntar, novamente com um certo ceticismo e sarcasmo, em que tamanho eles estavam pensando quando diziam big?
De qualquer forma, era o consenso geral — como já havia sido muito antes do advento dos próprios computadores — que dados e informações eram coisas muitíssimo diferentes. Os dados, sejam pequenos, médios ou econômicos, podiam geralmente ser encontrados em todos os lugares e coletados pelo preço de lápis e papel. Informações, por outro lado, exigiam um pouco mais de esforço.
Voltando aos dias atuais, o ditado "você pode ter dados sem informações, mas não pode ter informações sem dados" nunca foi tão óbvio ou verdadeiro. Somos inundados em um mar de dados, alimentado por rios caudalosos como a Internet das coisas, a computação móvel e as mídias sociais. O objetivo do big data é canalizar essas águas turbulentas para extrair insights importantes.
No entanto, este também não é um artigo sobre os objetivos ou oportunidades representados pelo big data.
Há quase 20 anos, minha especialidade no campo de TI tem sido o monitoramento e o gerenciamento de sistemas. Os que compartilham minha paixão por encontrar formas cada vez mais novas e criativas de determinar quando, como e se algo assustador aconteceu a um servidor compreendem que a relação entre dados e informações não é realmente uma dicotomia. É uma tríade.
É claro que o bom monitoramento começa com os dados. Uma grande quantidade deles, coletados regularmente de uma variedade de dispositivos, aplicativos e fontes no data center. E é claro que transformar esses dados em informações significativas — gráficos, quadros, tabelas e até medidores de velocidade — que representam o estado atual e a integridade dos serviços essenciais é o lado trabalhoso da tarefa.
Mas, a menos que essas informações levem à ação, tudo isso não resulta em nada. E é disso, meu paciente leitor, que trata este artigo: a importância dessa etapa adicional de transformar o insight baseado em dados em comportamento prático. O que me surpreende é como esse aspecto é pouco valorizado. Deixe-me explicar:
Digamos que você tenha configurado diligentemente seu monitoramento para coletar dados de disco rígido de todos os seus servidores essenciais. Você não está só coletando tamanho de disco e espaço usado, mas também extraindo estatísticas sobre IOPS, erros de leitura e de gravação.
Isso são dados.
Agora, digamos que sua tecnologia de monitoramento sofisticada e robusta faça um pouco mais, não apenas convertendo essas métricas em quadros e gráficos bonitos, mas também analisando os dados históricos para estabelecer linhas de base de modo que seus alertas não apenas sejam acionados quando, por exemplo, o uso do disco passar de 90%, mas, em vez disso, quando o uso do disco saltar de 50% do normal por um determinado período.
Isso são informações.
Digamos que você aplique esse monitoramento a todos os 5 mil servidores críticos e comece a "desfrutar" de cerca de 375 tíquetes de "disco cheio" por mês.
Essa, infelizmente, é a situação normal na maioria das empresas. É o ponto em que, como engenheiro de monitoramento (ou pelo menos, a pessoa encarregada do monitoramento do servidor), você começa a notar os olhares sombrios e sorrisos de desdém mal disfarçados de colegas que foram acordados às 2h da madrugada pelo "seu" monitoramento.
Então, o que está faltando? A resposta está em uma simples pergunta: E agora? Depois que você e sua equipe de servidor discutiram os detalhes do alerta de disco cheio, a próxima coisa a fazer é se perguntar: "O que devemos fazer agora? Qual é o nosso próximo passo?" Nesse caso, provavelmente envolveria limpar o diretório temporário para verificar se isso resolve o problema.
E a próxima etapa lógica a partir daí é a automação. Muitas vezes, a mesma plataforma de monitoramento que faz estardalhaço a respeito de um servidor estar inativo às 2 da madrugada pode limpar esse diretório temporário para você. Bem na hora, enquanto você está em sono profundo. Depois, se (e apenas se) o problema persistir, um tíquete será gerado envolvendo um ser humano. E esse ser humano saberá que antes que seu precioso sono fosse interrompido de forma tão rude, o diretório temporário já foi limpo, então se trata de algo um pouco mais sofisticado que isso.
Leon Adato, gerente técnico da SolarWinds
