8 lines
22 KiB
JSON
8 lines
22 KiB
JSON
{
|
||
"index": 42,
|
||
"slug": "editorial-2026-11-practice-technology-evaluation",
|
||
"title": "Как сравнивать технологии, когда ошибка стоит дороже прототипа",
|
||
"excerpt": "Практический способ сравнить технологии по границе задачи: отделить факт от допущения, посчитать цену перехода, проверить отказ и не выдавать пустую ячейку за нулевой результат.",
|
||
"contentHtml": "<p>Команда выбирает новую технологию по удачному демо. Через несколько недель выясняется, что демо не учитывало миграцию данных, обучение, права доступа и поддержку редкого сбоя. Прототип работает, а основная система ещё не готова его принять. Люди переключаются на ручной разбор, релиз откладывается, а возврат к прежнему решению становится дороже с каждым изменением.</p>\n<p>Цена ошибки здесь не равна цене лицензии или времени на первый запуск. Она включает работу, которую не записали в сравнении: перенос состояния, изменение контрактов, настройку наблюдения, обучение дежурных и обратный переход. Ошибка становится дорогой ещё и потому, что таблица с итоговым баллом выглядит убедительно. Она скрывает, какие данные измерили, какие предположили и какие критерии добавили после просмотра результата.</p>\n<p><strong>Тезис:</strong> сравнение технологии — это проверка решения, а не конкурс инструментов. Хорошая матрица не обещает объективного победителя. Она показывает границу задачи, цену внедрения, эксплуатационный риск, качество evidence и условия, при которых вывод перестаёт действовать.</p>\n<h2>Механизм: четыре разных типа утверждений</h2>\n<p>Сначала разделите четыре сущности. Вопрос описывает, что нужно узнать. Наблюдение фиксирует то, что действительно получили при заданных условиях. Неопределённость показывает, где результат может измениться. Предпочтение задаёт важность критерия для конкретного решения. Эти сущности связаны, но не заменяют друг друга.</p>\n<p>Вес 35 не доказывает, что переход дешевле. Балл 3 не доказывает, что технология подходит вашему коду. Слово «надёжная» не заменяет границу отказа и способ проверки. Если в клетке нет входных данных или метода измерения, там должно стоять <code>unknown</code>, а не аккуратный ноль. Ноль означает известное плохое свойство. Пустое значение означает, что команда ещё не знает, что именно проверять.</p>\n<pre><code>const decision = {\n problem: 'снизить стоимость поддержки очереди',\n alternatives: ['runtime-a', 'runtime-b'],\n criteria: [\n { id: 'fit', weight: 40, evidence: 'unknown' },\n { id: 'adoption', weight: 35, evidence: 'unknown' },\n { id: 'operations', weight: 25, evidence: 'unknown' }\n ],\n status: 'plan-only',\n winner: null\n};</code></pre>\n<p>Этот фрагмент — учебный пример структуры, а не результат сравнения. Имена альтернатив условны. В нём нет запуска, производственного журнала, benchmark и рекомендации к внедрению. Поле <code>winner: null</code> защищает от перехода от намерения к утверждению. В настоящей системе такой объект должен дополниться владельцем решения, версией входных данных и разрешённым способом получить evidence.</p>\n<h2>Как оценить пригодность</h2>\n<p>Начинайте не с названия инструмента, а с границы задачи. «Нужна современная платформа» не позволяет проверить результат. «Нужно обрабатывать повторную доставку сообщения с сохранением порядка внутри одного ключа» уже задаёт вопрос к контракту и к отказам. Для каждой альтернативы запишите, какие части задачи она покрывает напрямую, а какие потребуют адаптера, собственной логики или изменения модели данных.</p>\n<p>Пригодность нельзя свести к числу функций в документации. Важен путь ошибки. Если операция прерывается после записи в одно хранилище и до подтверждения в другом, кто обнаружит рассогласование? Можно ли повторить действие без дубликата? Где живёт идентификатор операции? Если технология отвечает только на happy path, её высокий балл создаёт ложное чувство готовности.</p>\n<h2>Стоимость внедрения — не сноска</h2>\n<p>Cost of adoption состоит из нескольких работ. Назовите их отдельно: обучение команды, изменение кода, перенос данных, интеграция с инструментами сборки, наблюдение, документация, дежурство и обратимость. Не нужно сразу превращать список в финансовую модель. Нужно сделать скрытую работу видимой и назначить владельца каждого неизвестного пункта.</p>\n<p>Особенно опасна фраза «миграция простая». У неё нет проверяемого смысла, пока не названы объём данных, допустимое окно простоя, схема отката и критерий сохранности. Учебное сравнение может отметить эти поля как <code>unknown</code>. Оно не имеет права подставить среднюю оценку из другого проекта: другая версия, команда или форма данных меняет стоимость перехода.</p>\n<h2>Эксплуатация начинается после успешного теста</h2>\n<p>Технологию будет поддерживать не автор демо, а дежурная команда. Поэтому проверяйте не только пропускную способность, но и обнаружение отказа, восстановление, диагностику и обновление. Уточните, какие метрики доступны, какие события связываются одним идентификатором и что увидит оператор при частичном сбое.</p>\n<p>Фраза «работает стабильно» не является наблюдением. Нужны условия: версия, вход, длительность, нагрузка, число повторов и правило интерпретации. Без них цифра переносится на чужой контекст без основания. Если измерение ещё не разрешено или его конфигурация не описана, корректное действие — остановить сравнение, а не придумать результат.</p>\n<figure><img src=\"/assets/editorial/2026/technology-evaluation-2026-tradeoff-frontier.svg\" alt=\"Матрица сравнения технологий с критериями пригодности, стоимости внедрения и эксплуатации и остановкой при неполных данных\" loading=\"lazy\" /><figcaption>Матрица удерживает критерии и веса в одном месте. Она не содержит фактических баллов и не выбирает технологию без evidence.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика ошибок в сравнении технологий</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>У каждой альтернативы есть точный итоговый балл</td><td>Неизвестные данные заменили числами</td><td>Попросить вход, метод и источник каждого балла</td><td>Вернуть ячейку в <code>unknown</code> и остановить итог</td></tr><tr><td>Победитель меняется после каждого обсуждения</td><td>Вес критерия выбран после результата</td><td>Сравнить версии матрицы и время изменения веса</td><td>Зафиксировать причину веса до новых наблюдений</td></tr><tr><td>Демо успешно, но миграция не оценена</td><td>Проверяли happy path, а не границу перехода</td><td>Описать данные, откат, простой и владельца</td><td>Добавить отдельный adoption-критерий</td></tr><tr><td>Оператор узнаёт об отказе от пользователя</td><td>Эксплуатацию приняли за наличие метрик</td><td>Воспроизвести частичный сбой и пройти alert path</td><td>Потребовать сигнал, runbook и срок реакции</td></tr><tr><td>«Одинаковые условия» нельзя повторить</td><td>Конфигурация скрыта в окружении</td><td>Проверить версии, входы, повторения и лимиты</td><td>Не называть запуск benchmark до фиксации условий</td></tr></tbody></table></div>\n<h2>Как не спутать вес и evidence</h2>\n<p>Вес отвечает на вопрос «насколько этот критерий важен для решения». Evidence отвечает на вопрос «что мы наблюдали и насколько этому можно доверять». Веса 40, 35 и 25 могут быть полезной учебной конфигурацией, если команда явно объяснила приоритеты и понимает, что это не измерение. Они не превращают три неизвестных значения в доказательство.</p>\n<p>Проведите простую проверку чувствительности только после появления разрешённых данных: измените один вес в заранее заданном диапазоне и посмотрите, меняется ли порядок альтернатив. Если результат меняется от небольшого сдвига, решение зависит от предпочтения и должно так и сообщать. Если результат не меняется, это не доказывает универсальность. Он лишь устойчив к проверенному диапазону при тех же входах.</p>\n<h2>Учебный валидатор и отрицательный путь</h2>\n<pre><code>function validatePlan(plan) {\n if (plan.criteria.some(item => item.weight == null)) {\n return { status: 'stop-missing-weight' };\n }\n if (plan.criteria.some(item => item.evidence === 'unknown')) {\n return { status: 'stop-no-evidence' };\n }\n if (plan.winner != null && plan.status !== 'measured') {\n return { status: 'stop-unearned-winner' };\n }\n return { status: 'ready-for-review' };\n}</code></pre>\n<p>Валидатор — учебный код. Он не заменяет статистический анализ, архитектурное ревью и контроль доступа. Его задача — не дать форме выдать план за измерение. Если отсутствует вес, он возвращает <code>stop-missing-weight</code>. Если evidence неизвестен, он возвращает <code>stop-no-evidence</code>. Если появился победитель без статуса измерения, он возвращает <code>stop-unearned-winner</code>. Положительный статус означает только готовность к следующему ревью, а не разрешение на rollout.</p>\n<h2>Порядок действий</h2>\n<ol><li>Опишите наблюдаемую проблему и цену ошибки без названия любимой технологии.</li><li>Задайте одну границу решения: данные, контракт, операцию или путь отказа.</li><li>Назовите альтернативы и исключите варианты, которые не могут пройти эту границу.</li><li>Разделите критерии на пригодность, стоимость перехода и эксплуатацию; добавьте только то, что влияет на решение.</li><li>Запишите вес каждого критерия и причину веса до появления результата.</li><li>Для каждого будущего измерения укажите входы, версию среды, метод, повторы и правило трактовки неопределённости.</li><li>Отделите неизвестное от плохого результата. Не заменяйте отсутствующие данные нулём.</li><li>Проверьте отрицательный путь: частичный сбой, откат, потеря наблюдения и невозможность повторить условия.</li><li>Передайте матрицу на ревью с явным статусом: план, измерение или решение. Не смешивайте статусы.</li></ol>\n<h2>Когда сравнение нужно остановить</h2>\n<p>Остановитесь, если критерий не имеет владельца и метода проверки. Остановитесь, если конфигурация измерения скрывает версии, входы или лимиты. Остановитесь, если веса появились после того, как стал виден удобный результат. Остановитесь, если таблица требует назвать победителя, хотя наблюдений нет. Такой stop не означает, что технология плоха. Он означает, что вопрос ещё не готов к честному ответу.</p>\n<p>Есть и отрицательный путь после внедрения. Если стоимость поддержки превысила исходное допущение или оператор не может восстановить систему в заданное время, не защищайте первоначальный выбор суммой баллов. Зафиксируйте, какое условие нарушилось, ограничьте дальнейшее распространение решения и проверьте обратимость. Матрица нужна для пересмотра, а не для оправдания уже потраченной работы.</p>\n<h2>Ограничения</h2>\n<p>Матрица не оценивает всё. Она не заменяет проверку безопасности, лицензий, юридических требований, доступности специалистов и совместимости с конкретной инфраструктурой. Она не создаёт данные, которых нет, и не переносит benchmark из одного окружения в другое. Она также не решает конфликт приоритетов сама: владелец решения должен объяснить, почему одна цена важнее другой.</p>\n<p>Сумма баллов может упростить разговор, но скрывает форму trade-off. Альтернатива с меньшей ценой перехода может требовать больше ручной поддержки. Альтернатива с лучшим happy path может хуже вести себя при восстановлении. Если один критический отказ недопустим, его нельзя компенсировать высокими баллами по второстепенным критериям. Задайте veto-условие отдельно.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Сравнение готово к решению, когда другой инженер может восстановить его без устного контекста: видит проблему и границу; знает альтернативы; понимает смысл каждого критерия и веса; открывает источник каждого наблюдения; видит версии, входы, повторы и ограничения; может пройти отрицательный путь; знает владельца решения и срок пересмотра. До этого документ готов только к уточнению.</p>\n<p>Практическая финальная проверка проста. Удалите итоговый столбец и попросите коллегу ответить, какие данные ещё нужны для выбора. Если ответ не меняется, матрица действительно отделяет вопрос от результата. Если коллега вынужден защищать уже напечатанного победителя, таблица стала риторическим инструментом. Верните её к наблюдаемой проблеме.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://csrc.nist.gov/pubs/sp/800/30/r1/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments</a> — официальный документ о том, как оценка риска поддерживает выбор действий; источник не задаёт веса и не выбирает технологию за конкретную команду.</li><li><a href=\"https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html\" target=\"_blank\" rel=\"noopener noreferrer\">AWS Well-Architected Framework: Definitions</a> — официальные определения направлений оценки архитектуры и описание компромиссов в контексте конкретной рабочей нагрузки; это не универсальная рейтинговая шкала.</li><li><a href=\"https://docs.aws.amazon.com/wellarchitected/2022-03-31/framework/oe-operate.html\" target=\"_blank\" rel=\"noopener noreferrer\">AWS Well-Architected Framework: Operate</a> — официальная рекомендация связывать метрики с результатами, а сигналы — с процедурами и владельцами; она не подтверждает измерения из этой статьи.</li></ul>"
|
||
}
|