История дифференциального анализатора
Первое правило Хамминга в системотехнике: Если вы оптимизируете компоненты, вы, вероятно, испортите производительность системы.
Он иллюстрирует это историей из собственной работы. Он управлял дифференциальным анализатором — аналоговой вычислительной машиной, которая решала дифференциальные уравнения путем механической интеграции. Спрос вырос, поэтому был заказан второй блок для подключения к первому, чтобы оба могли работать отдельно или вместе.
Строители, гордые своим мастерством, улучшили усилители в новом блоке. Хамминг настаивал: любое улучшение не должно мешать работе всей системы. В день приемки он провел классический тест: решить y'' + y = 0, построить график y vs y', ожидать идеальный круг. Тест сразу же провалился.
Причина: улучшенные усилители потребляли больше тока через цепь заземления. Неадекватное заземление, которое хорошо работало с исходными усилителями, теперь позволило токам утечки связываться между подсистемами. Улучшение одного компонента (усилители) деградировало интерфейс (заземление), и система отказала.
Исправление было тривиальным — более тяжелое медное заземление — но принцип был ясен: улучшение компонента изменяет поведение его интерфейса. Остальная система была разработана с учетом старого интерфейса. Улучшите компонент, сломайте интерфейс, ухудшите систему.
Распознавание оптимизации компонентов
Хамминг говорит, что это правило 'кажется столь разумным: если вы улучшите изолированный компонент, то вся система будет лучше' — и все же это ошибка. Отказ опосредован интерфейсом: улучшение компонента изменяет сигнал, который видит интерфейс.
Интерфейсы над компонентами
Практический вывод Хамминга: системные инженеры должны сначала разрабатывать и проверять интерфейсы, затем компоненты. Идеальный компонент с поломанным интерфейсом бесполезен. Посредственный компонент с хорошо определенным интерфейсом можно улучшить позже.
Правило 2: граничные условия (ограничения) системы часто более важны, чем оптимальные значения внутри этих границ. Система, разработанная для максимизации производительности в ожидаемой точке работы, часто хрупка: небольшие отклонения от ожидаемого диапазона вызывают отказы. Система, разработанная для безопасной работы в широком диапазоне — с четко определенными ограничениями — надежна.
Пример: система связи, разработанная ровно для 100 Мбит/с трафика при 25°C, отказывает, если трафик скачет до 110 Мбит/с или температура поднимается до 40°C. Система, разработанная с ограничением 'не должна превышать 90% использования при любой температуре ниже 60°C' более полезна, даже если ее пиковая производительность немного ниже.
Работа системного инженера: не оптимизировать A или B индивидуально, а оптимизировать A+B+C... в целом, с учетом ограничений.
Система образования: неудачная системотехника
Хамминг применяет свой собственный принцип к образованию. На протяжении десятилетий университеты оптимизировали отдельные курсы математики: исчисление было сведено к своим основам, линейная алгебра была очищена и затянута. Каждый курс, оцененный индивидуально, выглядит лучше.
Но рассматриваемый как система, появились большие пробелы:
- Математическая индукция: едва упоминается после средней школы.
- Комплексные числа: кратко введены в алгебру, а затем избегаются до поздней линейной алгебры, когда появляются комплексные собственные значения. Студенты сталкиваются с двумя новыми, сложными идеями одновременно без предварительной подготовки.
- Неопределенные коэффициенты: кратко упоминаются.
- Доказательства невозможности: почти полностью отсутствуют.
- Дискретная математика: в значительной степени игнорируется.
Оптимизация каждого компонента (каждого курса) создала пробелы в интерфейсах: отсутствующие концептуальные мосты между курсами. Выход системы — образованные инженеры и ученые — пострадали, хотя показатели выпуска каждого курса улучшились.
Сопротивление естественному желанию исправить сломанную часть
Наблюдение Хамминга: легко сказать правильные слова о системотехнике. Очень немногие люди могут на самом деле это сделать, когда наступает момент.
Естественная реакция при отказе системы: определить наиболее очевидно сломанный компонент и исправить его. Это компонентное мышление. Система отказала по причине, которая включает в себя взаимодействие компонентов, интерфейсов и ограничений — но наиболее видимый отказ обычно происходит на одном компоненте.
Дисциплина системного инженера: перед исправлением видимого отказа спросите: почему система произвела этот отказ на этом компоненте? Действительно ли компонент работает ниже нормы, или его просят работать вне его конверта проектирования остальной системой? Исправление симптома компонента оставляет системный отказ нетронутым.
Узкое место коммуникации в больших организациях следует этой схеме: отдел плохо общается (видимый отказ). Исправление компонента: нанять лучших коммуникаторов. Исправление системы: переработать архитектуру потока информации так, чтобы для достижения того же координирования требовалось меньше общения.
Системная диагностика
Различие: исправление компонента лечит симптом. Исправление системы лечит причину. Причина обычно включает в себя структуру системы — какие компоненты существуют, какие интерфейсы их соединяют, какие ограничения ограничивают их работу.