Місце у стійці не є ємністю

«Наскільки повна ця стійка» звучить як питання, відповіддю на яке є число. Це не так. Це пʼять питань в одному пальті, і кожна панель, що відповідає на них однією цифрою, тихо обрала, яке з пʼятьох мала на увазі, а решту чотири викинула.

Ці пʼять справді є різними речами. Скільки юнітів стійки зайнято. Скільки машин усередині насправді в експлуатації, а не в підготовці чи в карантині. Скільки з них можна продати клієнтові завтра. Скільки потужності машинам усередині закладено в бюджет проти бюджету самої стійки. І скільки вони споживають насправді.

Ви можете мати девʼяносто відсотків за першим і не мати чого продати, бо все у стійці вже привʼязане до клієнта. Ви можете мати сорок відсотків за першим і не мати змоги додати машину, бо бюджет потужності вичерпано. Це не крайні випадки. Це нормальний стан центру обробки даних, який попрацював якийсь час.

Ось як ми побудували відповідь як пʼять окремих показань і, що важливіше, як зробили так, щоб майбутній версії нас самих було важко їх усереднити.

Пʼять осей, пʼять різних відповідей

Читайте цю таблицю як перелік типів повернення, а не як перелік можливостей. Перша вісь повертає форму на кожен бік. Друга повертає відображення зі стану в кількість. Третя повертає три кількості машин. Четверта повертає дві цифри у ватах. Пʼята не повертає взагалі нічого. Жодна з пʼятьох не є голим числом, і це не випадковість задуму: це перше з чотирьох, що не дає існувати зведеній оцінці.

Якби кожна вісь повертала відсоток, середнє було б одним рядком коду. Ніхто не розглядав би його як рішення, бо воно не мало б вигляду рішення. Воно мало б вигляд зручності. Структурна незіставність форм повернення означає, що кожен, хто захоче зведену цифру, спершу мусить написати перетворення, яке їх сплощує, а перетворення видно у diff так, як не видно ділення.

Невідоме є окремим на кожній осі й несе причину

Другим запобіжником є те, що стається, коли вісь не знає.

Сьогодні існує три причини, і вони є ключами, а не реченнями, бо панель відтворює їх девʼятьма мовами. У стійки не записано бюджет потужності. Одна чи кілька машин у ній не знають власного зарезервованого споживання. Немає сенсора.

Різниця має значення, бо це три різні розмови. Перша є прогалиною у введених даних запису стійки. Друга є прогалиною у введених даних машини, і вона каже дещо конкретне: у сумі, яку ви збираєтеся прочитати, є діра. Третя взагалі не є прогалиною, це відсутність обладнання, підтримки якого ми не будували.

Найболючіше це на осі потужності. Якщо у стійки немає бюджету, немає з чим порівнювати, і вісь невідома саме з цієї причини. Якщо бюджет у стійки є, але одна розміщена машина не має зарезервованої цифри, вісь невідома з іншої причини, і саме цей випадок наївна реалізація робить неправильно. Дуже спокусливо вважати відсутню потужність нулем і далі підсумовувати. Це дає стійку, яка має вигляд просторої і є повною, а це найдорожча хибна відповідь, яку ця система може дати: хтось планує під неї доставку.

Правило полягає в тому, що невідоме з одного боку робить невідомою всю вісь. Сума з дірою не є меншою сумою.

Вісь, яка завжди невідома

Пʼята вісь, спостережена потужність, повертає невідоме щоразу. У цьому продукті немає ні блока розподілу живлення, ні вводу, ні розетки, ні датчика температури. Не частково, не за прапорцем: жодного.

Очевидним рішенням є прибрати її, поки її немає. Ми все одно поставили її на екран із написом, що сенсора немає, і причиною є те, що її відсутність зробила б із читачем. Коли на екрані чотири осі й одна з них підписана як потужність, розумна людина робить висновок, що цифра потужності є вимірюванням. Це не так. Це бюджет: те, що хтось увів у форму як очікуване споживання машини, підсумоване.

Показ пʼятої осі як явно невідомої є тим, що тримає четверту чесною. Твердження про ємність, зібране з неповних даних, є рівно тим режимом відмови, проти якого написано весь цей розділ задуму, і найдешевшим захистом від нього є назвати те, чого ви не виміряли.

Зробити оцінку неможливою, а не забороненою

Ніщо з наведеного не переживає зіткнення із заклопотаним кварталом, якщо це не буде чимось забезпечене. «Ми домовилися їх не поєднувати» є коментарем, а коментар не падає.

Тож існує тест, який читає вихідний файл компілятором TypeScript і стверджує про нього три речі.

Жодна експортована функція в тому файлі не повертає голе number. Отже, у модулі немає чого усереднювати, навіть випадково.

Функція, яка збирає пʼять показань, не містить ні арифметичного оператора, ні reduce, ні Math. Вона проходить реєстром осей і викликає кожен зчитувач. Це все, що їй дозволено, і будь-яка зведена цифра неминуче народилася б саме там, бо це єдине місце, де всі пʼять показань водночас у полі видимості. Це третій запобіжник.

І самі слова заборонені: сканування відхиляє healthScore, rackHealth, overallScore, combinedScore і capacityScore у будь-якому регістрі. Останнє є грубим, і ми все одно його лишили, бо відмова, від якої воно захищає, це чиясь готовність допомогти о пів на пʼяту в пʼятницю.

Сенс такого письма не в тому, що правило не можна порушити. Він у тому, що порушення вимагає видалити тест, а видалення тесту є рядком у запиті на злиття, про який хтось спитає. Додавання ділення між двома числами, які й так там були, ним не є.

Ми довели, що запобіжник червоний, перш ніж йому довіритися, двома окремими способами: арифметичним виразом усередині функції, яка збирає показання, і експортованою функцією, що повертає число. Обидва потім прибрали. Запобіжник, який ніколи не падав, є запобіжником, чиїх селекторів ви не перевіряли.

Додавання осі мусить бути помилкою компіляції

Пʼять осей живуть в одному реєстрі. Виробники живуть у записі з ключами з того реєстру, тож шоста вісь без зчитувача є помилкою типу, а не тихо відсутнім рядком. Це четвертий запобіжник.

Це покриває код. Це не покриває екран, а екран є місцем, де відсутня вісь найнебезпечніша: вона просто не зʼявляється, і таблиця має вигляд повної. Тож другий запобіжник виводить перелік осей із реєстру й вимагає для кожної підпис і підказку в усіх девʼятьох каталогах, власну гілку відтворення в компоненті та гілку невідомого з перекладеним реченням для кожної причини з реєстру причин.

Цей запобіжник відпрацював себе одразу. Він виявив, що вісь спостереженої потужності ніде не згадана в компоненті відтворення, а це рівно той стан, у якому вісь дає порожню комірку замість пояснення, а порожня комірка читається як нуль. Тести на кожну вісь не могли б цього знайти з тієї самої причини, з якої тест на кожен випадок не може знайти відсутній випадок: вам довелося б уже знати, що вісь існує.

Те саме міркування стосується перекладу. Код причини, за яким немає речення, є порожнім місцем мовою, якою в команді ніхто не читає, а девʼять каталогів це багато місць, де може сховатися порожнеча.

Що ми б записали

1. 01Вирішіть, у чому вимірюється кожна відповідь, перш ніж вирішувати, який вона має вигляд. Одиниці, які не можна додати, є найдешевшим захистом, який ви коли-небудь збудуєте.
2. 02Дайте невідомому власну причину на кожній осі й ніколи не дозволяйте відсутньому входу стати нулем дорогою до суми.
3. 03Тримайте вісь, яку ви не можете виміряти, на екрані з підписом, що вона не вимірюється, щоб сусідню вісь не сприйняли за вимірювання.
4. 04Покладіть заборону в тест, який читає вихідний код, а не в коментар, і доведіть, що тест червоний, перш ніж на нього покладатися.
5. 05Виводьте запобіжник із реєстру, щоб додавання шостої осі було гучним у коді й на екрані, а не тихим в обох.

Аби було ясно, де це стоїть: робота над логістикою центру обробки даних лежить за прапорцем розгортання, який типово вимкнено, а поверх нього ще й за налаштуванням на кожну організацію, тож нічого з цього не є тим, що можна піти й купити сьогодні. Це форма, яку ми збудували б знову, і пʼять осей є тією частиною, у якій ми впевнені найбільше. Суміжне питання про те, кому взагалі дозволено писати у стійку і що насправді зупиняє двох людей, які заявляють один слот, є в єдиній справжній межі зайнятості стійки.

Із роботи над центрами обробки даних у Provibr.