Rackruimte is geen capaciteit

"Hoe vol is dat rack" klinkt als een vraag met een getal als antwoord. Dat is het niet. Het zijn vijf vragen in één jas, en elk dashboard dat hem met één cijfer beantwoordt heeft stilletjes gekozen welke van de vijf het bedoelde en de andere vier weggegooid.

De vijf zijn werkelijk verschillende dingen. Hoeveel rack-units bezet zijn. Hoeveel van de machines die erin staan daadwerkelijk in dienst zijn en niet in staging of quarantaine. Hoeveel ervan morgen aan een klant verkocht zouden kunnen worden. Hoeveel vermogen er voor de machines erin begroot is, afgezet tegen het budget van het rack. En hoeveel vermogen ze werkelijk opnemen.

Je kunt op negentig procent staan bij de eerste en niets te verkopen hebben, omdat alles in het rack al aan een klant gebonden is. Je kunt op veertig procent staan bij de eerste en er geen machine bij kunnen zetten, omdat het vermogensbudget op is. Dat zijn geen randgevallen. Dat is de normale toestand van een datacenter dat al een tijd draait.

Zo hebben wij het antwoord als vijf losse metingen gebouwd, en, belangrijker nog, zo hebben we het een toekomstige versie van onszelf moeilijk gemaakt om ze te middelen.

Vijf assen, vijf verschillende antwoorden

Lees die tabel als een lijst van retourtypen en niet als een lijst van functies. De eerste as geeft een vorm per zijde terug. De tweede geeft per toestand een aantal terug. De derde geeft drie aantallen machines. De vierde geeft twee getallen in watt. De vijfde geeft helemaal niets terug. Geen van de vijf is een kaal getal, en dat is geen toevalligheid van het ontwerp: het is het eerste van vier dingen die verhinderen dat er een gecombineerd cijfer bestaat.

Gaf elke as een percentage terug, dan was een gemiddelde één regel code. Niemand zou het als een beslissing beoordelen, want het zou er niet als een beslissing uitzien. Het zou er als gemak uitzien. Door de retourvormen structureel onvergelijkbaar te maken moet wie een gecombineerd cijfer wil eerst de omzetting schrijven die ze plat slaat, en een omzetting is in een diff zichtbaar op een manier waarop een deling dat niet is.

Onbekend is per as, en draagt een reden

De tweede sluiting is wat er gebeurt als een as het niet weet.

Er bestaan vandaag drie redenen, en het zijn sleutels en geen zinnen, omdat het paneel ze in negen talen weergeeft. Het rack heeft geen vermogensbudget vastgelegd. Een of meer van de machines erin kent zijn eigen gereserveerde opname niet. Er is geen sensor.

Het verschil doet ertoe omdat het drie verschillende gesprekken zijn. Het eerste is een gat in de invoer bij het rack. Het tweede is een gat in de invoer bij een machine, en het zegt iets specifieks: de som die je zo gaat lezen heeft een gat. Het derde is helemaal geen gat, het is de afwezigheid van hardware waar wij geen ondersteuning voor gebouwd hebben.

De vermogensas is waar dit bijt. Heeft het rack geen budget, dan is er niets om tegen af te zetten en is de as om die reden onbekend. Heeft het rack wel een budget maar kent één geplaatste machine geen gereserveerd getal, dan is de as om een andere reden onbekend, en dit is het geval dat een naïeve implementatie fout doet. Het is heel verleidelijk om een ontbrekend wattage als nul te behandelen en gewoon door te tellen. Dat levert een rack op dat ruim lijkt en vol is, en dat is het duurste foute antwoord dat dit systeem kan geven: iemand plant er een levering op.

De regel is dat onbekend aan één kant de hele as onbekend maakt. Een som met een gat erin is geen kleinere som.

De as die altijd onbekend is

De vijfde as, gemeten vermogen, geeft elke keer onbekend terug. Er is in dit product geen power distribution unit, geen voeding, geen aansluiting en geen temperatuursensor. Niet gedeeltelijk, niet achter een vlag: geen.

Het voor de hand liggende is hem weg te laten tot hij bestaat. Wij zetten hem toch op het scherm, met de mededeling dat er geen sensor is, en de reden is wat zijn afwezigheid met de lezer zou doen. Met vier assen op het scherm, waarvan er één vermogen heet, concludeert een redelijk mens dat het vermogenscijfer een meting is. Dat is het niet. Het is een budget: wat iemand in een formulier heeft ingevuld als de verwachte opname van een machine, bij elkaar opgeteld.

De vijfde as uitdrukkelijk als onbekend tonen is wat de vierde eerlijk houdt. Een capaciteitsbewering die uit onvolledige gegevens is samengesteld is precies het faalgeval waartegen dit hele deel van het ontwerp geschreven is, en de goedkoopste verdediging ertegen is benoemen wat je niet gemeten hebt.

Het cijfer onmogelijk maken in plaats van verbieden

Niets van het bovenstaande overleeft een druk kwartaal als er niets is dat het afdwingt. "We hadden afgesproken deze niet te combineren" is een commentaarregel, en een commentaarregel kan niet falen.

Er is dus een test die het bronbestand met de TypeScript-compiler leest en er drie dingen over vaststelt.

Geen enkele geëxporteerde functie in dat bestand geeft een kale number terug. Er is daarmee niets in de module om te middelen, zelfs niet per ongeluk.

De functie die de vijf metingen samenstelt bevat geen rekenkundige operator, geen reduce en geen Math. Hij loopt over het register van assen en roept elke lezer aan. Meer mag hij niet doen, en een gecombineerd cijfer zou noodzakelijkerwijs daar geboren worden, want dat is de enige plek waar alle vijf de metingen tegelijk in beeld zijn. Dat is de derde sluiting.

En de woorden zelf zijn verboden: een scan verwerpt healthScore, rackHealth, overallScore, combinedScore en capacityScore in elke schrijfwijze. Die laatste is grof en we hebben hem toch gehouden, want het falen waar hij tegen waakt is iemand die op vrijdag om half vijf behulpzaam wil zijn.

Het punt van deze schrijfwijze is niet dat een regel niet te breken zou zijn. Het is dat breken vraagt om een test te verwijderen, en een verwijderde test is een regel in een pull request waar iemand naar zal vragen. Een deling toevoegen tussen twee getallen die er al stonden is dat niet.

We hebben de bewaking eerst rood bewezen voordat we erop vertrouwden, op twee verschillende manieren: een rekenkundige uitdrukking in de functie die de metingen samenstelt, en een geëxporteerde functie die een getal teruggeeft. Allebei zijn ze er weer uit gehaald. Een bewaking die nooit gefaald heeft is een bewaking waarvan je de selectors niet gecontroleerd hebt.

Een as toevoegen moet een compileerfout zijn

De vijf assen staan in één register. De producenten staan in een record met dat register als sleutel, dus een zesde as zonder lezer is een typefout in plaats van een stil ontbrekende rij. Dat is de vierde sluiting.

Dat dekt de code. Het dekt het scherm niet, en het scherm is waar een ontbrekende as het gevaarlijkst is: hij verschijnt eenvoudigweg niet, en de tabel ziet er compleet uit. Een tweede bewaking leidt de lijst met assen daarom uit het register af en eist er per as een opschrift en een toelichting in alle negen catalogi, een eigen weergavetak in het component, en een onbekend-tak met een vertaalde zin voor elke reden in het redenregister.

Die bewaking verdiende zichzelf meteen terug. Hij stelde meteen vast dat de as gemeten vermogen nergens in het weergavecomponent genoemd werd, precies de toestand waarin een as een lege cel oplevert in plaats van een uitleg, en een lege cel leest als nul. Tests per as hadden dat niet kunnen vinden, om dezelfde reden waarom een test per geval een ontbrekend geval niet kan vinden: je had dan al moeten weten dat de as bestond.

Dezelfde redenering geldt voor vertaling. Een redencode zonder zin erachter is een lege plek in een taal die niemand in het team leest, en negen catalogi zijn veel plekken waar een lege plek zich kan verstoppen.

Wat we zouden opschrijven

1. 01Bepaal waarin elk antwoord gemeten wordt voordat je bepaalt hoe het eruitziet. Eenheden die niet opgeteld kunnen worden zijn de goedkoopste verdediging die je ooit zult bouwen.
2. 02Geef onbekend een eigen reden per as, en laat een ontbrekende invoer nooit onderweg naar een som een nul worden.
3. 03Houd de as die je niet kunt meten op het scherm, gemerkt als ongemeten, zodat de as ernaast niet voor een meting wordt aangezien.
4. 04Zet het verbod in een test die de bron leest, niet in een commentaarregel, en bewijs die test één keer rood voordat je erop steunt.
5. 05Leid de bewaking uit het register af, zodat een zesde as toevoegen luidruchtig is in de code en op het scherm in plaats van stil in allebei.

Om duidelijk te zijn over waar dit staat: het werk aan datacenterlogistiek zit achter een uitrolvlag die standaard uit staat en daarbovenop achter een instelling per organisatie, dus niets hiervan is iets dat je vandaag kunt kopen. Het is de vorm die we opnieuw zouden bouwen, en de vijf assen zijn het deel waar we het zekerst over zijn. De verwante vraag wie er überhaupt in een rack mag schrijven, en wat er werkelijk voorkomt dat twee mensen hetzelfde slot claimen, staat in de enige echte grens op rackbezetting.

Uit het datacenterwerk aan Provibr.