El espacio en rack no es capacidad

«¿Cómo de lleno está ese rack?» suena a pregunta con un número por respuesta. No lo es. Son cinco preguntas con un mismo abrigo, y todo panel que la contesta con una sola cifra ha elegido en silencio cuál de las cinco quería decir y ha tirado las otras cuatro.

Las cinco son cosas genuinamente distintas. Cuántas unidades de rack están ocupadas. Cuántas de las máquinas que hay dentro están de verdad en servicio y no en preparación o en cuarentena. Cuántas de ellas se le podrían vender mañana a un cliente. Cuánta potencia tienen presupuestada esas máquinas frente al presupuesto del rack. Y cuánta potencia consumen en realidad.

Se puede estar al noventa por ciento en la primera y no tener nada que vender, porque todo lo que hay en el rack ya está ligado a un cliente. Se puede estar al cuarenta por ciento en la primera y no poder añadir una máquina, porque el presupuesto de potencia está agotado. No son casos extremos. Son el estado normal de un centro de datos que lleva un tiempo en marcha.

Así construimos la respuesta como cinco lecturas separadas y, más importante todavía, así hicimos difícil que una versión futura de nosotros mismos las promedie.

Cinco ejes, cinco respuestas distintas

Conviene leer esa tabla como una lista de tipos de retorno y no como una lista de funcionalidades. El primer eje devuelve una forma por cara. El segundo devuelve un mapa de estado a recuento. El tercero devuelve tres recuentos de máquinas. El cuarto devuelve dos cifras en vatios. El quinto no devuelve nada en absoluto. Ninguna de las cinco es un número pelado, y eso no es un accidente del diseño: es la primera de cuatro cosas que impiden que exista una puntuación combinada.

Si todos los ejes devolvieran un porcentaje, un promedio sería una línea de código. Nadie lo revisaría como una decisión, porque no lo parecería. Parecería una comodidad. Hacer que las formas de retorno sean estructuralmente incomparables obliga a quien quiera una cifra combinada a escribir primero la conversión que las aplana, y una conversión se ve en un diff de una manera en la que una división no.

Lo desconocido es por eje, y lleva un motivo

El segundo cierre es qué ocurre cuando un eje no sabe.

Hoy existen tres motivos, y son claves y no frases, porque el panel los muestra en nueve idiomas. El rack no tiene presupuesto de potencia registrado. Una o varias de las máquinas que hay dentro no conocen su propio consumo reservado. No hay sensor.

La diferencia importa porque son tres conversaciones distintas. La primera es un hueco de datos en la ficha del rack. La segunda es un hueco de datos en una máquina, y dice algo concreto: la suma que se está a punto de leer tiene un agujero. La tercera no es un hueco en absoluto, es la ausencia de un hardware para el que no hemos construido soporte.

El eje de potencia es donde esto muerde. Si el rack no tiene presupuesto, no hay nada contra lo que medir y el eje queda desconocido por esa razón. Si el rack tiene presupuesto pero una máquina colocada no tiene cifra reservada, el eje queda desconocido por otra razón distinta, y este es el caso que una implementación ingenua resuelve mal. Resulta muy tentador tratar un vataje ausente como cero y seguir sumando. Eso produce un rack que parece holgado y está lleno, que es la respuesta equivocada más cara que puede dar este sistema: alguien programa una entrega contra ella.

La regla es que un desconocido en un lado deja desconocido el eje entero. Una suma con un agujero no es una suma más pequeña.

El eje que siempre es desconocido

El quinto eje, la potencia observada, devuelve desconocido todas y cada una de las veces. En este producto no hay unidad de distribución de energía, ni acometida, ni toma, ni sensor de temperatura. Ni parcialmente, ni detrás de un interruptor: ninguno.

Lo obvio sería dejarlo fuera hasta que exista. Lo pusimos en la pantalla de todos modos, diciendo que no hay sensor, y la razón es lo que su ausencia le haría a quien lo lee. Con cuatro ejes en pantalla y uno de ellos etiquetado como potencia, una persona razonable concluye que la cifra de potencia es una medición. No lo es. Es un presupuesto: lo que alguien escribió en un formulario como consumo previsto de una máquina, sumado.

Mostrar el quinto eje como explícitamente desconocido es lo que mantiene honesto al cuarto. Una afirmación de capacidad montada con datos incompletos es justo el modo de fallo contra el que está escrita toda esta parte del diseño, y la defensa más barata es nombrar aquello que no se ha medido.

Hacer la puntuación imposible en vez de prohibida

Nada de lo anterior sobrevive al contacto con un trimestre ajetreado si no hay algo que lo imponga. «Acordamos no combinar esto» es un comentario, y un comentario no falla.

Así que hay una prueba que lee el fichero fuente con el compilador de TypeScript y afirma tres cosas sobre él.

Ninguna función exportada de ese fichero devuelve un number pelado. No hay por tanto nada en el módulo que promediar, ni siquiera por accidente.

La función que ensambla las cinco lecturas no contiene ningún operador aritmético, ni reduce, ni Math. Recorre el registro de ejes y llama a cada lector. Eso es todo lo que se le permite hacer, y cualquier cifra combinada nacería necesariamente ahí, porque es el único sitio donde las cinco lecturas están a la vez en ámbito. Ese es el tercer cierre.

Y las propias palabras están prohibidas: un rastreo rechaza healthScore, rackHealth, overallScore, combinedScore y capacityScore en cualquier combinación de mayúsculas. Esa última es tosca y aun así la mantuvimos, porque el fallo del que protege es alguien intentando ser útil un viernes a las cuatro y media.

El sentido de escribirlo así no es que una regla no se pueda romper. Es que romperla exige borrar una prueba, y borrar una prueba es una línea en un pull request por la que alguien va a preguntar. Añadir una división entre dos números que ya estaban ahí, no.

Probamos la guarda en rojo antes de fiarnos de ella, de dos maneras distintas: una expresión aritmética dentro de la función que ensambla las lecturas, y una función exportada que devolvía un número. Ambas se retiraron después. Una guarda que no ha fallado nunca es una guarda cuyos selectores no se han comprobado.

Añadir un eje tiene que ser un error de compilación

Los cinco ejes viven en un registro. Los productores viven en una tabla indexada por ese registro, así que un sexto eje sin lector es un error de tipos y no una fila que falta en silencio. Ese es el cuarto.

Eso cubre el código. No cubre la pantalla, y la pantalla es donde un eje que falta resulta más peligroso: sencillamente no aparece, y la tabla parece completa. Así que una segunda guarda deriva la lista de ejes del registro y exige, para cada uno, una etiqueta y una ayuda en los nueve catálogos, una rama de renderizado propia dentro del componente, y una rama de desconocido con una frase traducida para cada motivo del registro de motivos.

Esa guarda se ganó el sueldo de inmediato. Descubrió enseguida que el eje de potencia observada no aparecía nombrado en ninguna parte del componente de renderizado, que es exactamente el estado en el que un eje produce una celda vacía en lugar de una explicación, y una celda vacía se lee como un cero. Escribir pruebas por eje no habría podido encontrarlo, por la misma razón por la que una prueba por caso no encuentra un caso que falta: habría hecho falta saber ya que el eje existía.

El mismo razonamiento vale para la traducción. Un código de motivo sin una frase detrás es un hueco en blanco en un idioma que nadie del equipo lee, y nueve catálogos son muchos sitios donde esconder un hueco en blanco.

Lo que apuntaríamos

1. 01Decidir en qué se mide cada respuesta antes de decidir qué aspecto tiene. Unas unidades que no se pueden sumar son la defensa más barata que se construirá jamás.
2. 02Dar a lo desconocido un motivo propio por eje, y no dejar nunca que una entrada ausente se convierta en un cero de camino a una suma.
3. 03Mantener en pantalla el eje que no se puede medir, etiquetado como no medido, para que el eje de al lado no se confunda con una medición.
4. 04Poner la prohibición en una prueba que lea el código fuente, y no en un comentario, y ver la prueba en rojo una vez antes de confiar en ella.
5. 05Derivar la guarda del registro, para que añadir un sexto eje sea ruidoso en el código y en la pantalla en lugar de silencioso en ambos.

Para dejar claro dónde está esto: el trabajo de logística de centro de datos está detrás de un interruptor de despliegue apagado por defecto y, por encima, detrás de un ajuste por organización, así que nada de esto es algo que se pueda comprar hoy. Es la forma que volveríamos a construir, y los cinco ejes son la parte de la que estamos más seguros. La pregunta relacionada de quién puede escribir en un rack, y qué impide de verdad que dos personas reclamen el mismo slot, está en el único límite real a la ocupación de un rack.

Del trabajo de centro de datos en Provibr.