A Amazon não nasceu querendo construir a nuvem. As suas equipas de engenharia dedicavam 70% do tempo a gerir infraestrutura, e apenas 30% a construir produtos. Andy Jassy, o executivo que liderou a criação da AWS, explicou-o: o objetivo era inverter essa equação. A solução foi tratar a infraestrutura pelo que era — um serviço interno com clientes reais, métricas de entrega e uma equipa responsável por fazê-lo funcionar.
O resultado foi a AWS. A divisão mais rentável na história da internet.
Este não é um artigo sobre a nuvem. É sobre a pergunta que a Amazon se fez primeiro e que a maioria das equipas que gerem um Data Center ainda não considerou com clareza: A quem serve realmente o seu Data Center?
O cliente que ninguém identificou
Na Amazon, tudo tem um cliente. Antes de desenhar qualquer coisa, a equipa responde quem é esse cliente e o que precisa. Não de forma vaga, mas concreta: o que espera receber e como sabe quando algo não está a funcionar?
Na maioria dos Data Centers, essa pergunta não tem uma resposta clara. A infraestrutura IT serve a todos em geral e a ninguém em particular. As equipas utilizam-na porque não têm outra opção. O negócio depende dela sem a compreender totalmente. E o impacto real de uma falha no trabalho de outras pessoas nem sempre chega com clareza a quem gere a infraestrutura.
A Amazon começaria pelo cliente. Não pelos racks, a eficiência energética nem os SLAs.
Quem depende do seu Data Center para fazer o seu trabalho? O que precisa que a infraestrutura lhe entregue e como sabe quando algo falhou? Se conseguir responder a isto de forma concreta, está a gerir um serviço. Se não conseguir, está a gerir um custo.
Escrever primeiro o resultado, não a solução
A Amazon tem um método de trabalho conhecido como "Working Backwards", ou trabalhar ao contrário. Antes de construir qualquer coisa, a equipa escreve a nota de imprensa que anunciaria o produto terminado. A ideia é simples. Se não consegue descrever o resultado que vai gerar, provavelmente não tem claro o que está a fazer.
Aplicado à gestão de um Data Center, o exercício tem este aspeto: escreva o título que leria quem depende da sua infraestrutura se tudo funcionasse exatamente como deveria. Um resultado real, não uma percentagem técnica.
Algo como: a equipa de desenvolvimento implementa novos ambientes em minutos em vez de esperar semanas, a área financeira fecha o mês sem interrupções nem escaladas de última hora, ou a auditoria de conformidade não encontrou nenhuma surpresa porque tudo estava documentado e rastreado.
Se esse título for difícil de formular, se o que surge são indicadores de capacidade ou consumo energético em vez de benefícios concretos para alguém, a Amazon diria que ainda não tem claro a quem serve. E que até ter essa clareza, qualquer investimento no Data Center é difícil de justificar para além do gasto que representa.
Medir o que vê quem depende de si
A Amazon tem uma obsessão com os dados, mas com um tipo concreto: os que refletem a experiência de quem utiliza o serviço. Os que dizem se quem depende do sistema está a receber o que precisa, não apenas os que descrevem o estado interno da infraestrutura.
Na maioria dos Data Centers, o painel de controlo olha para dentro: PUE, capacidade disponível, número de incidentes. São indicadores operacionais, necessários e úteis para o dia a dia. O problema é que nem sempre dizem se quem depende da infraestrutura IT está bem servido.
A Amazon acrescentaria outra camada por cima. Coisas como quanto tempo passa desde que se solicita capacidade até que está disponível (medido a partir de quem precisa dela, não de quem a provisiona), ou quanto tempo demora a resolver um incidente contando desde que a aplicação falha, não desde que o alerta interno dispara. Também a percentagem de compromissos de serviço cumpridos dentro do prazo, e o custo por unidade de serviço entregue em vez de apenas o gasto total.
Isto liga-se a algo que já explorámos neste blog: os dados existem, mas nem sempre geram. A questão não é se o seu Data Center produz informação. É se essa informação lhe diz algo sobre como está a servir quem depende de si.
Agir como se fosse o primeiro dia
Jeff Bezos tinha uma obsessão: evitar o que chamava de Dia 2. O Dia 1 é quando uma equipa constrói e aprende. O Dia 2 é quando os processos se tornam automáticos, as decisões abrandam e se começa a gerir o que já existe sem questionar se ainda faz sentido.
"O Dia 2 é estagnação. Seguido de irrelevância. Seguido de declínio." — Jeff Bezos
Muitos Data Centers estão há anos nesse Dia 2 sem o saber. Os processos foram desenhados quando o negócio tinha outras necessidades. As ferramentas foram escolhidas há uma década. As métricas não mudaram desde a última auditoria. Ninguém as questiona porque ainda não falharam de forma visível, e enquanto não falharem, ninguém as toca.
Quando foi a última vez que alguém na sua equipa perguntou por que razão a gestão do Data Center funciona como funciona? Não para resolver um problema concreto, mas para ver se o modelo ainda faz sentido.
Essa é a diferença entre operar infraestrutura e assumir a responsabilidade por um serviço. Os serviços são revistos. Os custos são aprovados..
A Amazon não começou por querer construir a nuvem. Começou por se recusar a tratar a sua própria infraestrutura como uma caixa negra que apenas tinha de se manter ligada.
O Data Center que opera hoje tem o mesmo potencial — ou o mesmo risco. A diferença não está na automatização do Data Center que alcançou. Está em se quem o gere faz perguntas técnicas ou perguntas sobre o serviço que presta.
Gerir ou servir. A resposta define se o seu Data Center é um custo ou um ativo.
Ligações para as referências da Amazon
Andy Jassy: https://twitter.com/ajassy/status/1785293612835823716
Working Backwards. https://www.aboutamazon.com/news/workplace/an-insider-look-at-amazons-culture-and-processes
Jeff Bezos: https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders