Когда публикация есть, а автоматизация считает иначе

Канал о системном и бизнес-анализе, продуктовом мышлении и архитектуре. Как выявлять реальные проблемы, строить работающие решения и не терять здравый смысл в IT. Все вопросы - @innokentyB

contentopsпубликациядзен

Публикация может существовать, даже когда автоматизация уверена, что её нет. Сегодня у нас случился именно такой сбой.

Мы выпускали статью в Дзене. Статья появилась, но контур доставки сохранил ошибку загрузки изображения и статус неопределённого результата.

Один из агентов попробовал проверить публикацию с сервера, получил редирект на авторизацию и сделал неверный вывод: статьи нет. Я открыл канал и прямую ссылку сам — статья на месте и видна читателю.

В итоге одновременно существовали три разных факта:

  • попытка доставки завершилась с ошибкой;
  • подтверждение результата со стороны провайдера осталось неопределённым;
  • публикация была доступна по публичной ссылке.

Если хранить это одним полем «опубликовано / не опубликовано», система неизбежно начнёт врать. Ошибка отдельного шага превратится в вывод обо всём результате. А одна неудачная проверка — в доказательство отсутствия того, что на самом деле существует.

Поэтому теперь дорабатываем ContentOps так, чтобы отдельно сохранять попытку, подтверждение провайдера и проверку публичной видимости. Исправление ещё в работе. Этот случай как раз показал, зачем оно нужно.

Сообщение агента, ошибка адаптера и ответ одной проверки — наблюдения, а не финальный факт. Вопрос к команде должен звучать иначе: какое независимое свидетельство подтверждает, что результат действительно существует и доступен тому, для кого мы его делали?

А что у вас считается доказательством завершения: статус внутри контура или внешний проверяемый результат?

Читайте так же