Я удалил реализацию SSE (Server-Sent Events), на создание которой потратил несколько недель кропотливой работы. Именно я первым предложил SSE и начал его реализовывать, и именно я в конечном счёте после обсуждения решил, что нам следует от него отказаться.
Коллега, работавший вместе со мной, обобщил технические решения, связанные с внедрением SSE, а затем переходом на опрос в предыдущей статье.
В этой статье рассматривается процесс, приведший к этому решению, а также то, что требовалось сделать за пределами цикла, пока мы вместе с AI быстро находили полный ответ.
AI быстро решает поставленную задачу
Qra — это сервис, который разворачивает приложения в Vizend и отображает их состояние. Развёртывание занимает от нескольких десятков секунд до нескольких минут. Передо мной поставили задачу реализовать функцию, позволяющую пользователям шаг за шагом отслеживать ход развёртывания. Вспомнив опыт другого проекта, где я визуализировал прогресс длительной асинхронной задачи с помощью SSE, я естественным образом решил, что и эту проблему можно решить с помощью SSE, и продолжил двигаться в этом направлении.
В то время наша команда вместе с AI-агентом дорабатывала рабочий процесс по мере реализации, проверки и изменения SSE. Хотя нам пришлось последовательно решить целый ряд проблем — от вопросов с ресурсами до выбора библиотеки для frontend, — реализация SSE без особых трудностей достигла staging. Казалось, что SSE удачно встраивается в систему.
По мере того как мы повторяли реализацию и проверку, SSE постепенно становился стабильнее.
Решение задачи ещё не доказывает, что исходное решение было правильным
Затем, вновь изучая производственные требования перед очередным обзором платформы Vizend, мы снова придали особое значение требованиям к stateless-архитектуре и горизонтальному масштабированию, которые учитывали с самого начала. В Qra экземпляр, обнаруживший изменение статуса развёртывания, мог отличаться от экземпляра, подключённого к пользователю через SSE, поэтому для немедленной доставки требовался отдельный канал ретрансляции. Однако Qra не был проектом, привязанным к конкретной инфраструктуре: это был платформенный сервис, поддерживающий несколько окружений.
Изначальное требование к Qra заключалось в том, чтобы «пользователи могли проверять ход развёртывания и могли видеть его», а не в том, чтобы «доставлятьего через SSE в режиме реального времени». Но после того, как мы выбрали SSE в качестве направления, я сосредоточился на том, как надёжнее реализовать этот подход, и не подумал заново рассмотреть сам выбор.
Если оценивать решение с точки зрения этого требования, опрос приводит к задержке обновления экрана и увеличению числа запросов. Однако основная цель этого экрана заключалась в том, чтобы пользователи могли видеть, насколько продвинулось развёртывание, а в случае сбоя — когда и почему он произошёл. Поскольку задержка обновления экрана на несколько секунд не оказывала существенного влияния ни на само развёртывание, ни на следующее действие пользователя, мы решили, что Qra может позволить себе эту цену.
Кроме того, мне показалось чрезмерным заново определять канал ретрансляции, управление соединениями и общие правила для backend и frontend лишь ради немедленного обновления одного экрана. Обсудив этот вопрос с коллегой, командой инфраструктуры и командой платформы Vizend, мы оставили общеплатформенные стандарты SSE в бэклоге и удалили SSE из Qra.
На пути к этому решению возникли два вопроса, относящиеся к разным уровням. «Хорошо ли работает SSE?» — это то, что мы могли достаточно полно проверить в рамках цикла выполнения AI. Но «Настолько ли важна мгновенная реакция для Qra, чтобы брать на себя такую операционную ответственность?» — это был вопрос, на который невозможно было ответить в рамках этого цикла, каким бы хорошим ни оказался результат реализации.
Во время ретроспективы различие стало яснее, когда я столкнулся с понятиями Single Loop и Double Loop из теории организационного обучения. Single Loopисправляет ошибки в рамках заданной цели, тогда как Double Loopзаново рассматривает цель и её предпосылки с самого основания. Несколько недель я работал над циклом повышения полноты SSE. Но когда я отступил на один шаг и посмотрел на ситуацию со стороны, остался второй вопрос: действительно ли SSE необходим для Qra.
Ощущение того, что следует поставить в приоритет
Столкнувшись с новой проблемой, мы обобщаем свой прошлый опыт и знания, чтобы найти аспекты, схожие с текущей проблемой. Однако после этого нам нужно снова повысить разрешение и изучить различия между прошлой и нынешней ситуациями.
В предыдущем проекте я как руководитель мог устанавливать и продвигать стандарты, подходящие для определённого окружения. Но в Qra, являющемся частью платформы, которая должна учитывать несколько окружений и команд, я не мог устанавливать такие стандарты, руководствуясь только собственным суждением. Я недостаточно чётко вынес это различие на первый план в процессе принятия решения.
Когда какой-либо подход однажды хорошо сработал, мы можем увериться, что и на этот раз он будет правильным. Чем сильнее эта уверенность, тем легче не заметить необходимость заново изучить различия текущей ситуации с высокой степенью детализации.
Найдя сходства посредством абстрагирования и изучив различия с высокой степенью детализации, нам нужно решить, чему отдать приоритет. Я считаю способность оценивать относительный вес множества факторов на этом этапе своего рода Taste. Здесь Taste трудно объяснить только как предпочтение или проницательность.
Говоря об этом ощущении, Andrew Ng описал человеческий вклад, который люди называют Taste, как контекстное преимущество. Иными словами, информация и опыт, накопленные в непосредственной близости от продукта и его пользователей, становятся материалом для принятия новых решений.
Трудно заранее включить в документы и обратную связь весь материал, необходимый для вынесения суждения. По мере выполнения работы может возникнуть новый контекст, и даже при рассмотрении одних и тех же фактов то, что следует считать более важным, может меняться в зависимости от цели, роли и обязанностей в конкретной ситуации.
В Qra изменился не материал для вынесения суждения, а вес, придаваемый этому материалу.
Сила превращать суждение в выбор
Чем быстрее ИИ выполнял выбранный мной ответ, тем дальше исходный вопрос отодвигался от рассмотрения. Правильность работы SSE можно было быстро проверить в цикле выполнения, но вопрос о том, следует ли продолжать использовать этот подход, оставался вопросом, который нужно было задать за пределами цикла.
Соблюдение критериев можно проверить внутри цикла, но вопрос о том, следует ли продолжать применять эти критерии, необходимо пересматривать за пределами цикла.
Даже в процессе работы люди должны продолжать спрашивать себя, по-прежнему ли их первоначальное суждение соответствует текущей цели и роли. Исходя из этого, они должны решать, продолжать ли использовать текущий подход, скорректировать его или изменить.
Человеческая субъектность проявляется не в повышении скорости выполнения, а в пересмотре уже выбранного ответа и принятии ответственности за него.
Источники
- HKK, Обеспечение возможностей работы в реальном времени: от внедрения SSE до возврата к опросу (Nextree, 2026-05-07)
- Andrew Ng, The Batch, выпуск 359 (2026-06-26)
- Chris Argyris, Обучение по двойному циклу в организациях (Harvard Business Review, 1977-09)
TaeZ