Сложность обмена данными между двумя базами на примере Rozetka.UA

Обмен данными между базами — непростая задача, с которой справляются очень немногие. Не относитесь к этому легкомысленно! Выбор правильной архитектуры — залог успеха Вашего проекта! На данный момент, даже у такого крупного интернет-магазина, как Rozetka.UA не все гладко с этим.

Пока следующие статьи в работе, я решил, что могу написать небольшую статью, так сказать, “с колес”. Дело в том, что на днях я покупал в интернет-магазине “Rozetka.UA” оперативную память для одного из наших серверов. Мне нужна была немного устаревшая память, так, как и этот сервер не особо новый. Я заказал вот такую красненькую память — 2 штуки.

При оформлении  поставил галочку “самовывоз”. Было около 4 часа дня, и, у меня было время заехать и забрать этот товар, если бы он, вдруг, оказался у них в магазине. Итак, я оформил заказ. Это была среда. После этого, по вайберу мне пришло сообщение, что мой товар можно будет забрать в пятницу, т.е. через день. Дальше, мне звонит менеджер и говорит, что данного товара осталась только 1 штука. Я спросил, есть ли аналогичный по всем характеристикам товар, так как в компьютер лучше ставить 2 модуля памяти одного и того же производителя. Менеджер немного поклацал и сказал, что, да, есть практически такой же товар производителя Kingston, но чуть дороже. Я сказал, что это меня полностью устраивает. Он ответил, что товар есть в магазине, что он его поставил в резерв и можно прямо сейчас уже ехать и забирать. Я обрадовался и спросил, поменяется ли номер заказа или останется тот же? Он ответил, что мне придет смска. Я подождал смс еще минут 20, так как не был уверен, сколько я там на месте проведу времени не зная номера заказа. Видимо, менеджер имел в виду то сообщение по вайберу, что мне уже пришло. Но это несколько странно, так как то сообщение было с другой номенклатурой товаров и в нем было указано, что мне нужно приехать в пятницу. Дальше, я решил, что, может, я на сайте смогу узнать номер заказа, но обнаружил, есть только мой старый заказ, и в нем не изменилась ни номенклатура, не стоимость. Статус у заказа все еще был “Новый”. Я решил посмотреть, какую память мне мог поставить в заказ менеджер и обнаружил, что у производителя Kingston были 2 разные номенклатуры памяти, по-практически одной и той же цене. При этом, один из этих товаров у меня бы не заработал. Соответственно,  мне очень нужно было понять, какую же именно номенклатуру менеджер поставил в заказ. А учитывая, что никаких доказательств того, что заказ, действительно, изменился, кроме слов менеджера, у меня не было, а я, даже, не запомнил его имя, то в этот день я решил уже никуда не ехать. От греха подальше, я создал новый заказ, в котором выбрал именно ту номенклатуру, что мне нужна. После создания нового заказа, мне пришло по вайберу сообщение, что заказ можно будет забрать завтра, т.е. в четверг. Через час в тот же день, я обнаружил, что в старом заказе статус поменялся на “Ожидает в пункте самовывоза”. Но номенклатура и стоимость в нем не изменились. На следующий день, картина с обоими моими заказами уже выглядела вот так.

Как видите, в старом заказе все еще фигурирует красная память и старая стоимость. А в новом правильная зеленая память и новая стоимость.

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

В итоге, насколько я понимаю, если бы я не создал новый заказ, а забрал бы товар по старому заказу, то старый заказ с неверной номенклатурой и стоимостью на сайте поменял бы статус на “Выполнен” и остался бы висеть в истории заказов. Это неудобно, так как я часто обращаюсь к истории заказов с Rozetka.Ua, чтобы посмотреть модели товаров, которые я приобрел и почитать их характеристики. А, представьте, как это может быть неудобно людям, которые захотят провести финансовую сверку своих данных с данными Rozetka.Ua и просто не подозревают, что данные на сайте могут отличаться от данных в их внутренней базе, а реальную сверку нужно у них просить отдельно? Я очень надеюсь, что эти недочеты в скором времени Rozetka.UA подправит.

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

Как видите, он до сих пор висит у меня со статусом “Новый”. Я уверен, что во внутренней базе этот заказ у них отменен, а на сайте, почему-то отображается вот так…

Теперь, немного поговорим о том, почему же наша компания всегда выступает за ведение учета в единой базе везде, где это только возможно. Да, пример немного не специфичный, так как в рамках данного проекта, мы с Вами, в основном, говорим об этих проблемах в контексте ведения, именно, бухгалтерского и управленческого учета в единой базе. Но данный пример, все же, очень показателен и касается любого из нас. Сразу оговорюсь, что внутренней кухни Rozetka.UA я не знаю, но я много раз видел подобные проблемы у других компаний, потому, не думаю, что сильно ошибаюсь в своих “домыслах”.

Так вот, дело в том, что синхронизация двух и более источников данных между собой — это не та работа, которую можно начать и в какое-то ограниченное время закончить. И, самая основная беда в том, что заказчик уже на этапе постановки задачи приходит с этой роковой ошибкой в архитектуре. Он, даже, может проводить тендеры с такой изначально выбранной архитектурой. Пытаешься объяснить ответственному лицу, насколько большие проблемы могут возникнуть, и обязательно возникнут, при таких решениях. Объясняешь, насколько это дороже и сложнее обслуживать. Он идет, общается с руководством, и, все равно, не всегда может донести корректно эту мысль, а часто и получает отказ от перевода всего на единую базу. Кроме того, руководство не понимает, почему сумма на внедрения может значительно увеличиться от необходимости грамотной настройки синхронизации между базами. И в этом случае, мы пытаемся выйти напрямую на руководство, чтобы пообщаться, но это не всегда получается… К сожалению, с высоты руководству часто кажется, что, мол, что за проблема такая — перенести один документ в другую базу, а из другой базы перенести другой документ в первую. Сама постановка задачи же поместилась в одно предложение. 🙂 Значит, по идее, и реализация будет довольно простой! В итоге, пытаются сделать все это за один раз и дешево, за что, в итоге, получают проблему с синхронизацией данных… Особенно, если исполнитель попался, который говорит: “Скажите мне что сделать и я сделаю”. И он не особо беспокоится о том, что будет у заказчика с данными после окончания проекта. А между тем, самое дешевое и надежное решение — это, как раз, использовать единую базу.

К примеру, если рассмотреть данный пример с Rozetka.UA, то в архитектуру на упрощенном уровне, на котором любит рисовать схемы руководство, могло быть заложено следующее:

1. Пользователь на сайте вбивает заказ, и он переносится во внутреннюю базу компании.
2. Когда менеджер меняет статус заказа во внутренней базе компании, новый статус заказа переносится в базу данных сайта.

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

В целом, я не говорю, что Rozetka.UA выбрала неправильную архитектуру по обмену данными с сайтом. Скорее всего, как раз, правильную. Такая архитектура, разумеется, имеет право на жизнь. И, в некоторых случаях, ее нужно выбирать. Проблема заключается в том, что отладка синхронизации, если уж ее приходится использовать, никогда не должна останавливаться. Т.е. раз в несколько дней или, даже, каждый день, автоматическая обработка, которую, конечно, еще нужно написать, должна сверять те данные, которые, по идее, должны совпадать для обоих баз. Когда нет различий — все хорошо и не тратим на это время. Когда есть различия, то обработка должна сигнализировать разработчику, например, на электронную почту, что есть различия, а он уже должен восстанавливать причинно-следственную связь и разбираться, как эти различия появились. Таким образом, всплывают процессы, которые на этапе проектирования не были учтены, о них не знали, либо, даже, забыли о них. И они обязательно будут. От этого никуда не деться. Не стройте иллюзий, что Вы избежите этого. Любой другой путь приведет к тому, что данные в нескольких базах поплывут безвозвратно. Особенно, если Вы автоматическую проверку не внедрите как часть архитектуры синхронизации данных, а просто несколько раз вручную сверите данные между собой, решите, что они не отличаются и что все хорошо, дело сделано. Но нет, так не бывает! Сами процессы могут поменяться уже после внедрения таким образом, что синхронизация перестанет работать корректно. Да и, в принципе, из-за одного какого-то недокументированного редкого действия данные могут поплыть так, что концов уже не найдешь… Заметьте, что при работе в  единой базе, мы о таких вопросах НИКОГДА не задумываемся! Их для нас просто не существует!

Часто руководство пребывает в блаженном неведении, что все их базы четко копейка в копейку синхронизированы и совпадают. В этом и беда. Как видите, если руководство Rozetka.UA решит, что можно какие-то отчеты строить по данным сайта, то, во всяком случае, на текущий момент, их ждет разочарование… А, ведь, Rozetka.UA, на мой взгляд, самый технологичный интернет-магазин в Украине. И я  уверен, что они тратят на поддержку ИТ достаточно большие средства! И, заметно, что они постоянно работают над улучшением сервиса. То, что было раньше и то, чего они достигли сейчас — это просто небо и земля! И я люблю покупать там товары, что и Вам рекомендую. Так что я пишу данную статью не с целью поругать Rozetka.Ua, а с одной стороны, с целью указать им над чем еще стоит поработать, ради моего удобства как покупателя. А с другой стороны, показать Вам, что, даже у такой крупной и серьезной структуры, которая вкладывает в поддержку IT достаточно внушительные средства, есть проблемы обмена между двумя базами. Поймите, что это очень сложный и серьезный вопрос, а ему, почему-то, уделяется невероятно мало внимания! И нужно, чтобы руководство заказчика было, как минимум, в курсе этой проблемы, а отладкой синхронизации занимались истинные перфекционисты, которые хорошо понимают данную задачу. Правда, думаю, что, конкретно с Rozetka.UA проблема заключается только в том, чтобы руководство поставило задачу своим айтишникам потратить на это время и наладить процессы обмена, которые, как видите, вышли из-под контроля.

Буквально, на днях, мне попалась интересная статья про такое понятие, как “Технический долг”. Она о том, что ко всем “костылям”, которые были занесены в программный код, как временное решение, требуется отразить в проекте их последующее разрешение. Главное, чтобы заказчик видел, что есть доработки, на которые, еще, в будущем, придется потратить время и средства. И, как раз, в случае, когда есть несколько баз, я бы на каждый месяц зарезервировал какое-то время специалиста под “допиливание” процедуры обмена. Причем, не важно, есть у Вас свой штатный программист или у Вас программисты на аутсорсе. Все равно это нужно делать. Просто не питайте иллюзий, что синхронизация делается один раз и на века и тогда у Вас будет возникать меньше неожиданностей в работе. Спасибо за внимание!

Юрий Халтин, исполнительный директор ООО «Бизнес Сервис Провайдер».