Espaço em bastidor não é capacidade

«Quão cheio está aquele bastidor» soa a uma pergunta com um número por resposta. Não é. São cinco perguntas vestidas com um só casaco, e todos os painéis que lhe respondem com um único valor escolheram em silêncio qual das cinco queriam dizer e deitaram fora as outras quatro.

As cinco são coisas genuinamente diferentes. Quantas unidades de bastidor estão ocupadas. Quantas das máquinas lá dentro estão de facto em serviço, e não em preparação ou em quarentena. Quantas delas poderiam ser vendidas a um cliente amanhã. Quanta energia as máquinas lá dentro estão orçamentadas para consumir, face ao orçamento do bastidor. E quanta energia estão realmente a consumir.

Pode estar a noventa por cento na primeira e não ter nada para vender, porque tudo o que está no bastidor já está afeto a um cliente. Pode estar a quarenta por cento na primeira e ser incapaz de acrescentar uma máquina, porque o orçamento de energia está gasto. Não são casos limite. São o estado normal de um centro de dados que já anda a funcionar há algum tempo.

Foi assim que construímos a resposta, como cinco leituras separadas, e, mais importante ainda, foi assim que tornámos difícil que uma versão futura de nós próprios lhes tire uma média.

Cinco eixos, cinco respostas diferentes

Leia essa tabela como uma lista de tipos de retorno e não como uma lista de funcionalidades. O primeiro eixo devolve uma forma por face. O segundo devolve um mapa de estado para contagem. O terceiro devolve três contagens de máquinas. O quarto devolve dois valores em watts. O quinto não devolve nada. Nenhum dos cinco é um número simples, e isso não é um acaso do desenho: é a primeira de quatro coisas que impedem a existência de uma pontuação combinada.

Se todos os eixos devolvessem uma percentagem, uma média seria uma linha de código. Ninguém a analisaria como uma decisão, porque não teria aspeto de decisão. Teria aspeto de conveniência. Tornar as formas de retorno estruturalmente incomparáveis significa que quem quiser um valor combinado tem primeiro de escrever a conversão que as achata, e uma conversão vê-se numa comparação de código de uma maneira que uma divisão não se vê.

O desconhecido é por eixo, e traz consigo uma razão

O segundo fecho é o que acontece quando um eixo não sabe.

Existem hoje três razões, e são chaves em vez de frases, porque o painel apresenta-as em nove idiomas. O bastidor não tem orçamento de energia registado. Uma ou mais das máquinas lá dentro não conhece o seu próprio consumo reservado. Não existe sensor.

A diferença interessa porque são três conversas diferentes. A primeira é uma falha de introdução de dados no registo do bastidor. A segunda é uma falha de introdução de dados numa máquina, e diz uma coisa muito concreta: a soma que está prestes a ler tem um buraco. A terceira não é falha nenhuma, é a ausência de hardware para o qual não construímos suporte.

O eixo da energia é onde isto morde. Se o bastidor não tiver orçamento, não há contra o que medir e o eixo fica desconhecido por essa razão. Se o bastidor tiver orçamento mas uma das máquinas colocadas não tiver valor reservado, o eixo fica desconhecido por outra razão, e é este o caso que uma implementação ingénua erra. É muito tentador tratar uma potência em falta como zero e continuar a somar. Isso produz um bastidor que parece espaçoso e está cheio, que é a resposta errada mais cara que este sistema pode dar: alguém agenda uma entrega com base nela.

A regra é que desconhecido de um dos lados torna desconhecido o eixo inteiro. Uma soma com um buraco não é uma soma mais pequena.

O eixo que está sempre desconhecido

O quinto eixo, a energia observada, devolve desconhecido em todas as ocasiões, sem exceção. Não existe neste produto unidade de distribuição de energia, nem alimentação, nem tomada, nem sensor de temperatura. Nem parcialmente, nem atrás de um sinalizador: nenhum.

A coisa óbvia a fazer é deixá-lo de fora até existir. Pusemo-lo no ecrã na mesma, a dizer que não existe sensor, e a razão é aquilo que a sua ausência faria ao leitor. Com quatro eixos no ecrã, um deles rotulado como energia, uma pessoa razoável conclui que o valor de energia é uma medição. Não é. É um orçamento: aquilo que alguém escreveu num formulário como consumo previsto de uma máquina, somado.

Mostrar o quinto eixo como explicitamente desconhecido é o que mantém honesto o quarto. Uma afirmação de capacidade montada a partir de dados incompletos é exatamente o modo de falha contra o qual toda esta secção do desenho está escrita, e a defesa mais barata contra ele é nomear aquilo que não se mediu.

Tornar a pontuação impossível em vez de proibida

Nada do que está acima sobrevive ao contacto com um trimestre atarefado a não ser que algo o imponha. «Combinámos não juntar isto» é um comentário, e um comentário não falha.

Por isso existe um teste que lê o ficheiro de origem com o compilador de TypeScript e afirma três coisas sobre ele.

Nenhuma função exportada nesse ficheiro devolve um number simples. Não há portanto nada no módulo de que se possa tirar uma média, nem sequer por acidente.

A função que reúne as cinco leituras não contém nenhum operador aritmético, nenhum reduce e nenhum Math. Percorre o registo de eixos e chama cada leitor. É tudo o que lhe é permitido fazer, e qualquer valor combinado nasceria necessariamente ali, porque é o único sítio onde as cinco leituras estão em âmbito ao mesmo tempo. Esse é o terceiro fecho.

E as próprias palavras estão proibidas: uma varredura rejeita healthScore, rackHealth, overallScore, combinedScore e capacityScore em qualquer combinação de maiúsculas e minúsculas. A última é grosseira e mantivemo-la na mesma, porque a falha contra a qual protege é alguém ser prestável às quatro e meia de uma sexta-feira.

O objetivo de escrever isto assim não é que uma regra não possa ser quebrada. É que quebrá-la exige apagar um teste, e apagar um teste é uma linha num pedido de integração sobre a qual alguém vai perguntar. Acrescentar uma divisão entre dois números que já lá estavam não é.

Provámos a guarda vermelha antes de confiar nela, de duas maneiras distintas: uma expressão aritmética dentro da função que reúne as leituras, e uma função exportada que devolvia um número. Ambas foram novamente retiradas. Uma guarda que nunca falhou é uma guarda cujos seletores ninguém verificou.

Acrescentar um eixo tem de ser um erro de compilação

Os cinco eixos vivem num único registo. Os produtores vivem numa tabela cujas chaves são esse registo, pelo que um sexto eixo sem leitor é um erro de tipos em vez de uma linha que falta em silêncio. Esse é o quarto.

Isso cobre o código. Não cobre o ecrã, e o ecrã é onde um eixo em falta é mais perigoso: simplesmente não aparece, e a tabela parece completa. Por isso uma segunda guarda deriva a lista de eixos do registo e exige, para cada um, um rótulo e uma dica nos nove catálogos, um ramo de apresentação próprio no componente, e um ramo de desconhecido com uma frase traduzida para cada razão do registo de razões.

Essa guarda mereceu o seu lugar de imediato. Descobriu logo que o eixo da energia observada não era nomeado em lado nenhum do componente de apresentação, que é exatamente o estado em que um eixo produz uma célula vazia em vez de uma explicação, e uma célula vazia lê-se como zero. Escrever testes por eixo não teria conseguido descobrir isso, pela mesma razão pela qual um teste por caso não consegue encontrar um caso em falta: teria sido preciso já saber que o eixo existia.

O mesmo raciocínio aplica-se à tradução. Um código de razão sem frase por trás é um espaço em branco numa língua que ninguém na equipa lê, e nove catálogos são muitos sítios onde um espaço em branco se pode esconder.

O que registaríamos

1. 01Decida em que se mede cada resposta antes de decidir com que aspeto ela fica. Unidades que não podem ser somadas são a defesa mais barata que alguma vez irá construir.
2. 02Dê ao desconhecido uma razão própria por eixo e nunca deixe que uma entrada em falta se torne um zero a caminho de uma soma.
3. 03Mantenha no ecrã o eixo que não consegue medir, rotulado como não medido, para que o eixo ao lado não seja confundido com uma medição.
4. 04Ponha a proibição num teste que lê o código-fonte, e não num comentário, e prove uma vez que o teste fica vermelho antes de depender dele.
5. 05Derive a guarda do registo, para que acrescentar um sexto eixo seja ruidoso no código e no ecrã, em vez de silencioso em ambos.

Para ser claro quanto ao ponto em que isto está: o trabalho de logística de centro de dados vive atrás de um sinalizador de lançamento que está desligado por predefinição e, por cima dele, de uma definição por organização, pelo que nada disto é coisa que se possa comprar hoje. É a forma que voltaríamos a construir, e os cinco eixos são a parte de que estamos mais confiantes. A questão relacionada de quem tem sequer autorização para escrever num bastidor, e daquilo que impede na prática duas pessoas de marcarem o mesmo slot, está em o único limite real à ocupação de um bastidor.

Do trabalho de centro de dados na Provibr.