Конфликты редактирования: как не затереть чужую работу

Одновременное редактирование в приложении: версии записей, блокировки и сравнение изменений. Как сохранить работу сотрудников и проверить конфликты.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

Два сотрудника нажали «сохранить». Один исчез из истории

Возьмём учебный сервис для поставщика. Менеджер открыл заказ и уточняет адрес доставки. В соседнем отделе сотрудник меняет контактное лицо. Оба видят одну исходную карточку. Первый сохраняет адрес, второй отправляет свою форму целиком. Контакт обновился. Адрес вернулся к старому значению. Сервер ответил успехом обоим, поэтому искать виноватого будут среди людей. У приложения сегодня выходной от ответственности.

Потерянное обновление не обязательно связано с высокой нагрузкой. Достаточно двух открытых вкладок, задержанного запроса или фонового импорта. Сотрудник мог сам редактировать запись на ноутбуке и телефоне. Система, которая принимает последнее пришедшее состояние без проверки, не знает, является ли оно последним решением пользователя. Она знает только порядок доставки пакетов.

Из-за этого конфликт — продуктовая задача, а не исключительно вопрос базы данных. Нужно определить, что человек редактирует, какие изменения совместимы и как продолжить работу после расхождения. Ошибка «объект изменён» технически честна. Но если форма после неё очищается, пользователь получает предложение повторить весь труд. По смыслу оно не сильно отличается от исходной потери.

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

Почему «последний сохранивший победил» — плохое правило по умолчанию

Порядок получения запросов не отражает осознанный выбор. Человек мог долго проверять расчёт, а другой быстро поправить комментарий. Если второй запрос пришёл позднее, это не делает его источником более свежего расчёта. Приложение должно знать исходную версию, на которой сделано изменение, и сравнить её с текущей.

Версия может быть отдельным счётчиком, токеном или иной установленной характеристикой состояния. Важно, чтобы она менялась при соответствующих обновлениях и проверялась в момент принятия записи. Дата на экране удобна для человека, но её смысл и точность нужно согласовать. Нельзя случайно использовать время локального компьютера как доказательство актуальности серверных данных.

В HTTP для условного изменения может применяться If-Match с ETag. MDN описывает этот заголовок как условие соответствия текущему представлению ресурса; при несовпадении возможен ответ 412. Это конкретный механизм контроля, а не готовый интерфейс разрешения конфликтов. Пользователю всё равно нужно объяснить, что сохранить не удалось и как продолжить.

Продуктовое правило выглядит так: изменение подготовлено на версии А; сервер принимает его, если нужное состояние всё ещё соответствует А; иначе возвращает актуальные данные и понятное расхождение. Проверка должна быть атомарной с записью. Отдельное чтение версии, за которым следует безусловное обновление, оставляет окно для нового изменения между двумя шагами.

Полная форма и конкретное изменение ведут себя по-разному

Когда браузер отправляет всю карточку, он несёт с собой значения, к которым пользователь не прикасался. Именно они способны затереть чужую работу. Отправка только изменённых полей уменьшает этот риск, но не устраняет смысловые конфликты. Адрес доставки может зависеть от выбранного склада; срок — от состава заказа. Два разных поля иногда изменяют одно деловое решение.

Для каждого сценария полезно определить единицу согласования. Отдельный комментарий может быть самостоятельной записью. Пара «количество и единица измерения» обычно требует связанной проверки. Состав заказа, цена и утверждённая сумма могут образовывать целый агрегат. Не стоит выбирать границу только потому, что таблица базы уже разделена на колонки.

В учебном примере адрес и контакт можно попытаться объединить автоматически, если правила заказа это допускают и обе правки сделаны на понятном основании. А изменение статуса на «отгружен» одновременно с пересмотром состава требует другого решения. Автоматическое слияние по различным именам полей выглядело бы умно, пока товар не уехал в составе, который никто не принимал.

Явный список изменённых полей помогает программе и интерфейсу. Пользователь видит своё намерение; сервер проверяет нужные связи; журнал отражает фактическую операцию. Однако список должен формироваться надёжно. Нельзя доверить клиенту право объявить любые данные «неизменёнными» и тем самым обойти бизнес-проверку.

Блокировка, версии и совместная правка: выбор по сценарию

Оптимистический контроль подходит, когда столкновения редки, а пользователь может быстро сравнить изменения. Люди свободно открывают объект, сервер проверяет актуальность при сохранении. Нет необходимости держать карточку занятой весь день только потому, что кто-то ушёл на обед с открытой вкладкой.

Блокировка полезна, если операция требует последовательного владения записью или совместное изменение слишком сложно согласовать. Но у продуктовой блокировки должны быть владелец, срок, продление и порядок освобождения. Закрытие браузера не гарантирует доставку команды «я закончил». Без истечения аренды приложение выращивает музей навсегда занятых документов.

Совместный текстовый редактор решает другой класс задач. Несколько авторов одновременно меняют текст, видят курсоры, получают соответствующие правила согласования. Это не универсальная замена контролю заказа. Даже если текст сливается без потерь, переход финансового документа в новый статус требует своих правил и полномочий.

Транзакция помогает, но не угадывает намерение сотрудника

На сервере нужны корректные механизмы конкурентного доступа. Документация PostgreSQL по изоляции транзакций объясняет различия уровней и возможные аномалии. Выбор уровня и порядка повторения операций зависит от задачи. Повысить изоляцию на всё приложение без понимания нагрузки — не готовый продуктовый рецепт.

Транзакция обеспечивает согласованный набор изменений на сервере, но не знает, что пользователь смотрел старую карточку десять минут. Этот контекст должен прийти в запросе и участвовать в условии обновления. Иначе сервер вполне последовательно выполнит две несовместимые человеческие правки. Техническая дисциплина без проверки намерения способна аккуратно сохранить неправильный результат.

Раздел PostgreSQL о блокировках описывает, в том числе, блокировки строк и взаимные блокировки. Это инструменты короткой серверной операции. Не следует держать транзакцию открытой всё время, пока человек заполняет форму. Человеческая пауза и серверная критическая секция имеют разную продолжительность и разные последствия.

Для команды разработки полезно сформулировать инвариант: принятая запись должна соответствовать версии и условиям, проверенным в той же операции. Для команды продукта — результат: пользователь не теряет правки и понимает, почему сервер отказал. Приёмка должна подтверждать оба утверждения.

Экран конфликта обязан сохранить работу

Хороший экран показывает три состояния: что было при открытии, что сейчас хранится, что предложил пользователь. Тогда видно, почему возникло расхождение. Два столбца без исходного состояния могут скрыть, какие поля действительно изменили. Человек начинает выбирать по памяти, а приложение уже однажды доказало, что с памятью здесь напряжённо.

Не нужно показывать все десятки неизменённых полей. Сосредоточьтесь на затронутых значениях и зависимостях. Для адреса достаточно понятных частей; для списка товаров — добавлений, удалений и изменённых количеств. Важные изменения не следует прятать только цветом: подписи «ваша правка» и «текущая запись» помогают и на телефоне, и при особенностях восприятия цвета.

У пользователя должен оставаться черновик. После обновления данных он может применить совместимые изменения, пересмотреть спорные или отказаться. Кнопка «перезаписать всё» требует особой осторожности: она фактически предлагает проигнорировать чужой труд. Если такой вариант нужен определённой роли, последствия обозначают явно и проверяют права на сервере.

Не обвиняйте сотрудника формулировкой «вы использовали устаревшие данные». Он использовал форму, которую вы ему показали. Лучше сказать: «Пока вы редактировали заказ, контакт изменился. Ваша правка адреса сохранена в черновике. Сравните значения перед отправкой». Такая реплика сообщает событие и следующий шаг, не устраивая воспитательный час.

После сравнения запись может измениться ещё раз

Разрешение конфликта не замораживает весь бизнес. Пока первый сотрудник выбирает нужное значение, третий меняет срок. Поэтому повторное сохранение также должно проверять версию, на основе которой пользователь принял решение. Иначе экран сравнения создаёт красивую, но ложную гарантию.

При частых столкновениях нужно исследовать процесс. Возможно, несколько отделов постоянно правят один огромный объект и границы работы выбраны неверно. Можно отделить самостоятельные комментарии, поручения, подтверждения или версии расчёта. Это снижает площадь конфликта без борьбы за каждую букву.

Иногда достаточно показать присутствие другого участника и предупредить о текущей работе. Но индикатор «Анна редактирует» не является блокировкой. Он может запаздывать, исчезнуть при обрыве связи или не учитывать импорт. Если команда рассчитывает на исключительность, нужен соответствующий серверный механизм, а не вежливый аватар.

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

Сохранение карточки и внешние последствия

Некоторые правки запускают письма, задачи или передачу в учётную систему. Если конфликт обнаруживается после такого действия, сервер уже поздно объясняет, что ничего не сохранено. Порядок проверок и последствий должен быть спроектирован. Сначала принимается допустимая операция; затем предусмотренным способом выполняются связанные действия и фиксируется их состояние.

Если запись принята, но внешняя передача не состоялась, интерфейс не должен показывать общий успех всего маршрута. Если передача состоялась, но подтверждение потерялось, бездумное повторение может создать дубль. Это смежная тема: идемпотентность запросов разбирает защиту одной операции от повторного исполнения. Контроль версии защищает другой аспект — актуальность основания для изменения.

Для принятой правки полезно сохранять связь с запросом, версией и последующими событиями. Тогда поддержку можно спросить: какая версия стала основанием, кто принял изменение и что ушло наружу. Журнал — инструмент объяснения. Не нужно обещать, что его наличие автоматически устраняет ошибки согласования.

Автосохранение усиливает эту задачу. Форма может отправлять несколько изменений подряд, ответы приходят не в ожидаемом порядке, пользователь продолжает печатать. Индикатор сохранения должен относиться к нужной версии черновика. Ответ на старый запрос не вправе объявлять последнюю правку уже сохранённой.

Фоновый импорт — тоже редактор

Интеграция часто меняет те же объекты, что и сотрудники. На экране никто не видит коллегу, но импорт обновляет статус или контакт. Если механизм версий применяется только к браузеру, фоновая запись может обходить все принятые правила. У объекта должна быть единая дисциплина обновления для всех путей.

Для каждого поля полезно назначить владельца смысла. Цена приходит из учётной системы, локальная заметка принадлежит отделу продаж, статус исполнения — согласованному источнику. Если два сервиса считают одно поле своим, конфликт будет повторяться независимо от качества интерфейса. Программа способна показать войну систем, но не назначить победителя вместо бизнеса.

При импорте можно сохранять время события, время получения и версию источника. Старое событие, доставленное сегодня, не обязательно является новым состоянием. Решение зависит от протокола интеграции. «Последнее полученное» и «последнее произошедшее» — разные порядки, особенно после перерыва связи.

Человек должен понимать, что значение изменено автоматически и по какому основанию. Но не нужно засыпать интерфейс техническими деталями. В карточке достаточно полезного уведомления, а в журнале — проверяемой связи с событием. Так сотрудник видит причину, а поддержка получает материал для расследования.

Проверять нужно двумя вкладками и плохой связью

Минимальный тест: открыть одну запись в двух независимых сессиях, внести несовместимые правки и сохранить их по очереди. Вторая операция должна обнаружить конфликт, а черновик остаться доступным. Затем поменяйте порядок. Проверка только одного успешного сохранения не подтверждает защиту от столкновений.

Дальше проверяют параллельную отправку: запросы стартуют почти одновременно. Важна серверная атомарность, а не вежливость интерфейса. Если обе операции прошли на одной исходной версии и одна затёрла другую, визуальное предупреждение работало как декоративная табличка «осторожно».

Отдельный набор — разные поля, зависимые поля, удалённая запись, изменение прав и фоновый импорт. Результат каждого сценария заранее описывают. Для разных полей может быть допустимо слияние; для зависимых требуется отказ. Удалённую запись нельзя незаметно создать заново из старой формы, если такое поведение не предусмотрено процессом.

Проверьте сохранение после таймаута, восстановление вкладки, смену устройства и повторное разрешение уже устаревшего конфликта. На телефоне сравнение не должно уезжать за экран; доступ к черновику нужен без точного попадания в маленький значок. Общий красивый интерфейс бесполезен, если кризисная ветка сделана как служебное сообщение для разработчика.

Метрики: конфликт не всегда ошибка продукта

Количество обнаруженных конфликтов не следует автоматически уменьшать до нуля. После введения контроля число отказов может вырасти, потому что ранее потери происходили молча. Для оценки нужны время разрешения, доля потерянных черновиков, повторные столкновения и количество некорректных принятых состояний.

Полезно отдельно видеть объекты, которые редактируют особенно часто. Если один заказ постоянно блокирует работу нескольких ролей, это сигнал проверить процесс и границу объекта. Возможно, сотрудникам нужны независимые поручения вместо правки общего поля «следующий шаг». Иногда архитектурное решение начинается с вопроса, зачем пять человек одновременно меняют одну строку.

Учебный расчёт может сравнивать время восстановления потерянной правки с временем сравнения конфликта. Но в экономику нужно включать последствия неверной записи: повторную доставку, пересогласование, работу поддержки. Не вся ошибка измеряется минутами ввода. Неправильный адрес умеет стать дорогим очень быстро.

Данные наблюдения не должны раскрывать содержимое чувствительных форм всем, кто видит панель мониторинга. Для агрегированной оценки достаточно категории события и технической связи. Конкретные значения открываются по соответствующим правам. Контроль редактирования не отменяет обычную дисциплину доступа.

Что записать в техническое задание

Опишите единицу изменения, способ контроля версии, допустимые совместные правки, поведение при отказе и сохранение черновика. Для блокировки укажите владельца, срок и порядок освобождения. Для автоматического слияния — точные правила и случаи, в которых решение возвращается человеку.

Задайте сценарии приёмки словами сотрудников: менеджер изменил адрес, логист поменял способ доставки; бухгалтер закрыл документ, пользователь сохранил старую форму; импорт обновил статус во время ввода. Под каждым сценарием должно быть ожидаемое состояние данных и интерфейса. Это проверяемее требования «все изменения синхронизируются без ошибок».

Рядом опишите связанные действия: какие события создаются после принятой правки и как восстанавливается их результат. Общий разбор журнала аудита поможет определить след изменения. Но сам конфликт разрешается до потери работы, а не после чтения отчёта о том, кто последний нажал кнопку.

В рамках разработки веб-приложения такие правила относятся к модели продукта. Они не должны внезапно появляться в конце проекта как «непредвиденная сложность многопользовательского режима». Если пользователей больше одного, столкновения являются ожидаемой частью работы.

Пять минут, которые показывают настоящую многопользовательскую работу

Откройте одну карточку в двух вкладках. Измените разные поля, затем одно и то же поле. Сохраните, вернитесь к первой форме и повторите отправку. Посмотрите не только на сообщения, но и на итоговую запись. Потом спросите, где остался черновик проигравшей попытки.

Если всё прошло без предупреждений, это не обязательно означает прекрасную синхронизацию. Возможно, приложение просто молча выбирает последнего. Найдите исходную версию и доказательство её проверки. Если такого механизма нет, команда пока договорилась только о порядке прихода запросов, а не о порядке принятия решений.

Профессиональный продукт не обязан предотвращать сам факт одновременной работы. Он обязан не превращать её в незаметное уничтожение чужих изменений. Два сотрудника могут спорить о значении. Система должна сохранить их труд и показать спор, а не объявить победителя по скорости сети.

Частые вопросы

Достаточно ли отправлять только изменённые поля?

Это уменьшает риск затереть незатронутые значения, но не устраняет конфликты зависимых полей и устаревшие решения. Нужны контроль актуальности и правила совместимости изменений. Проверка выполняется на сервере вместе с принятием операции.

Нужно ли блокировать карточку при каждом открытии?

Не всегда. Для редких столкновений может подходить оптимистический контроль версии. Блокировка нужна по смыслу операции и должна иметь владельца, срок и порядок освобождения. Само присутствие человека в интерфейсе не является надёжной блокировкой.

Поможет ли журнал аудита избежать потери правок?

Журнал помогает увидеть принятые изменения и разбирать последствия. Он не заменяет сравнение версии и сохранение черновика. Чтобы не потерять работу, приложение должно обнаруживать конфликт до безусловной перезаписи устаревшим состоянием.