Два записа для одной задачи и панель инструментов, которая не могла оставаться на месте Недавно мы столкнулись с проблемой, когда два отдельных записа создавались для одной и той же задачи в нашем проекте. Это вызывало путаницу, так как пользователи не могли понять, почему они видели разные данные для одной и той же работы. Основная причина заключалась в том, что система, отвечающая за создание записей, не справлялась с нагрузкой. Мы провели анализ, чтобы выяснить, как именно происходил этот процесс, и обнаружили, что при одновременной отправке нескольких запросов создавалось несколько записей. Мы быстро реализовали решение, которое включало в себя добавление механизма блокировки, чтобы гарантировать, что только один запрос может создать запись за раз. Кроме того, мы заметили, что панель инструментов не отображала данные должным образом. Она постоянно перезагружалась, демонстрируя поведение, которое мы не могли объяснить. Проведя дополнительные исследования, мы обнаружили, что это было вызвано недостаточной оптимизацией запроса к базе данных, что приводило к высокому времени отклика. Мы обновили соответствующий код и добавили кэширование для снижения нагрузки на базу данных. Теперь обе проблемы решены, и пользователи могут работать с задачами без заминок. Мы продолжаем следить за поведением системы, чтобы гарантировать ее стабильность и производительность.

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

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

Очевидное решение — винить идентификаторы и сделать их более изысканными. Лучше уникальные теги. Более строгая политика, по которой ни две записи не могут иметь один и тот же идентификатор. У нас уже было это. Каждая запись имела свой абсолютно уникальный приватный тег, и это не помогло ни капли. Это была ловушка. Путаница с дублирующими записями выглядит как проблема идентификаторов и почти никогда ею не является. Уникальные теги гарантируют, что две записи разные. Они совершенно не гарантируют, что две записи описывают разные вещи в реальном мире. У нас была одна работа в реальности и две записи об этом здесь, каждая держала свой безупречный приватный тег, и обе были абсолютно неправы в том, что они отдельные.

То, что действительно беспокоило нас, когда мы осознали это, так это то, как этого можно было избежать. У задания уже было идеальное естественное имя. Человек сам ввел это имя, когда начал работу. Это введенное имя было той единственной истиной во всей вселенной, указывающей на этот конкретный объект работы, и мы относились к нему просто как к еще одной детали сбоку, пока чеканили наши собственные приватные теги и просили наших помощников, чтобы они, пожалуйста, запомнили их. Помощники не помнили. Они просили «запись для этой работы», получали ту копию, которая первым попадалась, делали на ней пометку и уходили. Другая копия оставалась в темноте, тихо накапливая свою собственную отдельную историю, всплывая только часто достаточно, чтобы заставить огни мигать.

Поэтому мы полностью исключили приватные теги из обсуждения. Теперь наши помощники ссылаются на работу по единственной вещи, которую действительно ввел человек: её реальному имени. Попросите работу по этому имени, и вы всегда, каждый раз, получите единственную каноническую запись. Первый помощник, который обращается к совершенно новой работе, создает её. Каждый следующий помощник обращается точно к той же записи, без рулетки. Мы также провели разовую очистку, которая нашла каждую работу с секретным двойником, объединила их истории и тихо сняла дубликаты. Затем мы провели все это так, чтобы каждый экран обновлялся в момент, когда что-либо меняется, чтобы все видели одну и ту же правду в один и тот же момент. Мерцание прекратилось в тот же день, и панель управления наконец научилась оставаться неподвижной.

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

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

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