Комментарии 73
я правильно понял, тестовые заказы на 7,84 миллиона рублей?
судя по статье, это были реальные платежные операции из копии продакшен-базы, которые в результате «обезличивания», (а вернее чистки части данных с продакшена), потеряли связь с заказами. А поскольку транзакции и реляционная целостность в современном мире считается устаревшим подходом, для приведения базы в порядок был специальный сервис, отменяющий платежные операции, не привязанные к заказам. Интересно, почему на продакшене нельзя было делать этого вручную, или может даже исправить причину появления таких операций?
Это были реальные заказы, загруженные с продакшн-базы в тестовую базу.
За время проведения оплаты пиццерия может встать в стоп (надо почистить печь, выключилось электричество, другие экстренные ситуации). В этом случае оформление заказа не происходит и такие платежи возвращаются автоматически по расписанию.
После оплаты мы делаем финальную проверку заказа и уже после проставляем статус, что заказ отправлен на исполнение.
Там алгоритм смотрит, что должен быть заказ в определенной стадии. Если заказа нет, то платеж считается непривязанным и должен быть возвращен.
Заказ как сущность в БД существует на момент оплаты и даже раньше. Дело не в этом. Дело в том, что после оплаты мы перепроверяем, не стала ли пиццерия в стоп за то время, пока клиент оплачивал (или не случилось ли что-то другое, что не даст исполнить заказ). И если исполнение заказа невозможно, мы говорим об этом клиенту и возвращаем деньги. За возврат денег отвечает фоновая задача, которая работает так: она ищет платежи, к которым не привязаны исполненные заказы, и отменяет эти платежи.
Насколько я понял, тут просто была не очень хорошо продумана логика.
Из того, что я прочитал, мне представляется, что в норме бесхозные оплаты всё равно не должны возикать — вы же не удаляете заказы сразу после того, как их застопорили?
Соответственно, автоматом отменять нужно только те оплаты, которые привязаны к застопоренному заказу.
А возникновение вообще бесхозной оплаты должно считаться нештатной ситуацией. И если такое обнаруживается, то нужно отправлять аларм человеку, который будет руками разбираться, почему случился такой пердимонокль.
Из того, что я прочитал, мне представляется, что в норме бесхозные оплаты всё равно не должны возикать — вы же не удаляете заказы сразу после того, как их застопорили?
Соответственно, автоматом отменять нужно только те оплаты, которые привязаны к застопоренному заказу.
А возникновение вообще бесхозной оплаты должно считаться нештатной ситуацией. И если такое обнаруживается, то нужно отправлять аларм человеку, который будет руками разбираться, почему случился такой пердимонокль.
Например, оплаты банковскими картами могут быть двух типов
SMS и DMS. В первом случае авторизация и ее выполнение происходят в рамках одной транзакции, а во втором случае они проходят в рамках 2 транзакций, т.е. клиент видит и думает, что оплатил, а по факту деньги только заблокировались и не ушли получателю, а выполнение транзакции происходит только при одобрении первой транзакции получателем
- да, скорее всего так.
- при первой транзакции создается ее id, который в дальнейшем и финишируется, если все устраивает получателя, либо финишируется с корректировкой суммы
P.S.: Мы работали по DMS с эквайером, чтобы избежать эксцессов по поводу отсутствия товара и оплаченной сумме. После перехода к Я.Кассе нам пришлось запретить оплату несобранных заказов в личном кабинете пользователей. И это очень неудобно добросовестным клиентам
Как бы не удивительно что такие проблемы ведь чудо написано на C#.
Обеспечивая бурный рост Dodo IS, мы нередко предпочитали скорость разработки всему остальному. Иногда это происходило в ущерб системной логике, архитектуре и инфраструктуре.
У меня приятель в Dodo работал. Рассказывал, что подобные «ускорения» приводили к тому, что js и css писали прямо в cshtml файлах в массовом порядке. Описанная в статье проблема была конечно архитектурная, а не тактическая, но симптомы на лицо. Он ушел из Dodo, потому что боялся что «ускорения» к чему-то подобному приведут. Надеюсь выводы сделаны и в дальнейшем у Dodo будет рост качества кода и безотказности системы! А пицца и так вкусная)
Кстати, это классный опыт — побывать на всех этапах цепочки, чтобы понимать какую боль ты порой доставляешь персоналу кажущимися гениальными техническими решениями :) Эх, вот бы безопасники хоть иногда работали на месте тех, кому закручивают гайки
Если эта информационная система автоматизирует сам процесс клининга, то — да, и программистам и архитекторам и другим инженерам будет полезно помыть пол, используя свою же систему. А если система автоматизирует прием заказов на клининг, то мыть пол не нужно, а будет полезно поработать оператором.
Это называется https://en.wikipedia.org/wiki/Eating_your_own_dog_food, и продукт в результате получается в сто раз круче.
Это называется https://en.wikipedia.org/wiki/Eating_your_own_dog_food, и продукт в результате получается в сто раз круче.
Простите, но вы немного перегибаете.
«С такой точки зрения инженерам много что полезно, побывать на всех этапах цепочки. И поработать курьером, поразвозить пиццу»
У нас пока нет аппов для курьеров. Но где-то через год они будут и тогда — да, поработать курьером будет полезно
«И поработать официантом, потому что они через сколько-то слоев взаимодействуют с бакендом»
В пиццерии нет официантов.
«И поработать уборщицей в туалете, потому что у вас вот все сотрудники взаимозаменяемы.»
Мы не автоматизируем уборку туалетов, так что это лишнее
«Для того чтобы писать хороший отказоустойчивый бакенд или разрабатывать архитектуру платежного гейта, или быть хорошим DBA или админом линукс-сервера не нужно знать специфику приготовления теста.»
Знать специфику приготовления теста не обязательно. Понимать, как работает пиццерия изнутри обязательно. От этого однозначно не будет хуже — как минимум, это новые знания, расширение кругозора и т.д. В нашем же случае мы видим очевидную пользу от этого — такие стажировки влияют на мотивацию людей и на отношение к разрабатываемому продукту.
«С такой точки зрения инженерам много что полезно, побывать на всех этапах цепочки. И поработать курьером, поразвозить пиццу»
У нас пока нет аппов для курьеров. Но где-то через год они будут и тогда — да, поработать курьером будет полезно
«И поработать официантом, потому что они через сколько-то слоев взаимодействуют с бакендом»
В пиццерии нет официантов.
«И поработать уборщицей в туалете, потому что у вас вот все сотрудники взаимозаменяемы.»
Мы не автоматизируем уборку туалетов, так что это лишнее
«Для того чтобы писать хороший отказоустойчивый бакенд или разрабатывать архитектуру платежного гейта, или быть хорошим DBA или админом линукс-сервера не нужно знать специфику приготовления теста.»
Знать специфику приготовления теста не обязательно. Понимать, как работает пиццерия изнутри обязательно. От этого однозначно не будет хуже — как минимум, это новые знания, расширение кругозора и т.д. В нашем же случае мы видим очевидную пользу от этого — такие стажировки влияют на мотивацию людей и на отношение к разрабатываемому продукту.
«Потому что работа курьером — это мягко говоря низкоквалифицированный, тяжелый и достаточно небезопасный труд.»
Можно просто доставить несколько заказов, находясь рядом с настоящим курьером. Было бы желание, а решение найдется.
«Для этого совершенно необязательно работать неделю в Сывтывкаре.»
Необязательно в Сыктывкаре и неделю. Пиццерии есть в Москве.
«Но будет ли лучше — далеко не факт.»
Наш опыт показывает, что будет лучше. Опыт — штука субъективная, я понимаю. Что и хочу донести в нашей переписке.
Можно просто доставить несколько заказов, находясь рядом с настоящим курьером. Было бы желание, а решение найдется.
«Для этого совершенно необязательно работать неделю в Сывтывкаре.»
Необязательно в Сыктывкаре и неделю. Пиццерии есть в Москве.
«Но будет ли лучше — далеко не факт.»
Наш опыт показывает, что будет лучше. Опыт — штука субъективная, я понимаю. Что и хочу донести в нашей переписке.
Не знаю как при поступлении на работу, но очень интересным «наказанием» в случае серьезного косяка я считаю предложить разработчику посидеть на саппорте клиентов.
Заставляют — не совсем верное слово. Это условие работы, которое обговаривается заранее. Можно проходить стажировку не с начала, а через полгода, например.
Не очень-то и вкусная. 6/10
Совсем невкусная. Из массовых лучшая у Папа Джонса, не в каждой пиццерии получается хрустящая рельефная корочка, но даже без неё пицца далеко впереди конкурентов из Пиццы Хат (совсем не как в 90-е) и Доминос (у них беда с рецептами).
А Додо может конкурировать с Империей пиццы и прочим локальным продуктом.
А Додо может конкурировать с Империей пиццы и прочим локальным продуктом.
> Он ушел из Dodo, потому что боялся
Зря боялся:
> Мы не будем наказывать людей
И зря ушёл, они ведь теперь меняются:
> мы просто сделаем все, чтобы такого больше не повторилось.
Итог: Вместо того, чтобы попробовать направить в нужное русло он просто свалил…
Зря боялся:
> Мы не будем наказывать людей
И зря ушёл, они ведь теперь меняются:
> мы просто сделаем все, чтобы такого больше не повторилось.
Итог: Вместо того, чтобы попробовать направить в нужное русло он просто свалил…
Я так и знал: навыки, аккуратность и опыт не заменишь UML-диаграммами.
Советую в архитектуру добавить систему антифрода — без нее вы в будущем получите еще много неприятностей.
И да, ни какой финансовый запрос в АПИ не должен выполняться в обход системы антифрода. Это аксиома для платежного шлюза. У разработчика не должно быть шансов создать endpoint в АПИ не унаследовав базовые проверки в антифроде. В первом приближении система антифрода может быть обычной таблицей барьерных лимитов.
И да, ни какой финансовый запрос в АПИ не должен выполняться в обход системы антифрода. Это аксиома для платежного шлюза. У разработчика не должно быть шансов создать endpoint в АПИ не унаследовав базовые проверки в антифроде. В первом приближении система антифрода может быть обычной таблицей барьерных лимитов.
А меня за такие косяки по рукам били. И я бил.
Неужели Senior Developer не поменяли? Просто пройтись по статье — косяков Senior Developer немеряно, начиная от «сильной связи». Жесткие такие косяки.
Хотя, такие люди, как правило, очень амбициозны, и поэтому очень убедительны. "Я создал монстра, и потратил на это много денег" — и его начальство любит и очень ценит, ведь он так крут. «Unix Way? Игрушка. Устойчивая распределенная архитектура? Оставьте это для учебников...»
Только в любой другой действительно ИТ-ориентированной компании такой надолго не задержался бы.
Простите за прямоту.
Неужели Senior Developer не поменяли? Просто пройтись по статье — косяков Senior Developer немеряно, начиная от «сильной связи». Жесткие такие косяки.
Хотя, такие люди, как правило, очень амбициозны, и поэтому очень убедительны. "Я создал монстра, и потратил на это много денег" — и его начальство любит и очень ценит, ведь он так крут. «Unix Way? Игрушка. Устойчивая распределенная архитектура? Оставьте это для учебников...»
Только в любой другой действительно ИТ-ориентированной компании такой надолго не задержался бы.
Простите за прямоту.
Вообще, вы правы. Но реальность бывает разная. В данном конкретном случае скорее всего бизнесу было важно как можно раньше получить готовый продукт и стоимость его последующего переделывания вполне могла оказаться (как реально, так и по предварительным расчетам) ниже чем стоимость выпуска системы с нормальной архитектурой, но позже. И действительно хороший сеньор должен понимать такие вещи и быть способен написать (вместе с командой конечно я не имею ввиду в одиночку) плохо, но максимально быстро. А если систему после этого еще и в принципе возможно переделать хорошо и правильно без ее остановок — то это практически идеальный вариант.
Бить надо тогда, когда точно известны требования, и их не учли.
А когда вы растете на 100% в год, и так несколько лет подряд. Вот тогда, чтобы ты не напридумывал сегодня через некоторое время это станет неактуальном в любом случае. Либо бизнес загнется, либо надо все переделывать под новые требования. Если делать хорошо, но долго, бизнес может к тому времени загнуться.
А когда вы растете на 100% в год, и так несколько лет подряд. Вот тогда, чтобы ты не напридумывал сегодня через некоторое время это станет неактуальном в любом случае. Либо бизнес загнется, либо надо все переделывать под новые требования. Если делать хорошо, но долго, бизнес может к тому времени загнуться.
Обеспечивая бурный рост Dodo IS, мы нередко предпочитали скорость разработки всему остальному. Иногда это происходило в ущерб системной логике, архитектуре и инфраструктуре.
Типичная ситуация, разработчики как раз тут чаще всего не особо виноваты, хотя часто оказываются "крайними". Скорее тут похвально то, что не стали наказывать за косяки, допущенные из-за построения процесса разработки.
В чем беда то, люди потеряли 200к рублей? Они больше на тестирование теряют, просто не с таким шумом. Это копейки.
Люди смогли безопасно протестировать архитектуру. Если бы потом заказов было бы на 100 миллионов, на реальных клиента?
В по такого применения иногда быстро написанный говнокод принесет миллиарды прибыли, а тут какие то 200к блин.
У них не спутник упал, и не машина контроль потеряла, как было у тойоты с 100 жертвами и 8 миллионами отозванных машин.
Windows по всему миру не упал и по никому деньги не перевело.
Очень радует тенденция публикования историй факапов, в которых:
Ни разу у вас пиццу не заказывал (в нашем городе относительно недавно), но сегодня это сделаю.
«Безусловно, мы сделаем серьезнейшие выводы из этой критической ошибки. Мы не будем наказывать людей — мы просто сделаем все, чтобы такого больше не повторилось.»
Ни разу у вас пиццу не заказывал (в нашем городе относительно недавно), но сегодня это сделаю.
Исходный код платежного шлюза располагается в специальном репозитории, закрытом от всех разработчиков. Для любого изменения исходников разработчику нужно оформить отдельную заявку.
И изменение, видимо, разработчик делает на выделенной машине без доступа в интернет с выдранными внешними портами и перенакатом образа ОС каждые два часа, под неусыпным присмотром охранника.
Хотя, вероятнее, копия репозитория с некоей версией шлюза валяется на локальном диске каждого разработчика, вносившего изменения.
Привет, Андрей, весело у тебя там.
Как-то такие статьи очеловечивают компанию. Не было мысли попробовать заказать у вас, а сейчас сижу ем
Всем привет.
Ситуация с Додо-пиццей привлекла и моё внимание. Именно из-за того, что
Примерно полтора года назад мы в CloudPayments сделали возможность отменять совершенные возвраты в течение 3 часов после их совершения: в это время мы еще не отправляем окончательное подтверждение в МПС. Кроме того, даже если эти три часа будут упущены, не получится сделать возвратов больше, чем на суточный оборот.
И в этой ситуации, чтобы не отменять вручную возвраты по всем этим 10000 заказов, можно было бы написать или позвонить в нашу поддержку, мы бы эти возвраты завернули в течение пяти минут.
Ситуация с Додо-пиццей привлекла и моё внимание. Именно из-за того, что
Примерно полтора года назад мы в CloudPayments сделали возможность отменять совершенные возвраты в течение 3 часов после их совершения: в это время мы еще не отправляем окончательное подтверждение в МПС. Кроме того, даже если эти три часа будут упущены, не получится сделать возвратов больше, чем на суточный оборот.
И в этой ситуации, чтобы не отменять вручную возвраты по всем этим 10000 заказов, можно было бы написать или позвонить в нашу поддержку, мы бы эти возвраты завернули в течение пяти минут.
недавно в развлекательных сетях проскакивала новость, что в до-до пицца сейчас вся внутренняя переписка только на английском, это правда?
Классика. Рано или поздно многие это проходят. Мы в свою очередь «привязали» продакшн условно к серверу — любое перемещение в тестовую среду просто отключает реальные клиентские сервисы…
А как у вас ПО узнает, что оно в тестовой среде?
Я думаю решений много и они очень индивидуальны в каждой системе. Если очень просто и условно, то у сервиса существует настройка — продакшн сервер. Запускаясь в тестовой среде сервис понимает, что его запустили не там где надо, и исходя из этого надо использовать альтернативную конфигурацию или что-то отключить. Параметр настройки я привел здесь достаточно условно — это может быть любым (любыми) отличиями тестовой среды.
Не понимаю, как Вы еще не разорились. Никакой информации про цену доставки, про режим работы. Сидел в 3 часа ночи выбирал пиццу, регистрировался, вбивал код с телефона — и это все чтобы узнать что никто ночью не может принять мой заказ? Я удручен таким обслуживанием.
Сейчас опять пытался заказать ту же пиццу, третий раз ввожу адрес, и этого недостаточно, надо нажать «оформить», чтобы узнать, что теста для кругов среднего размера нет в наличии, зато есть побольше и подороже. В пиццерии тесто закончилось? — Офигеть, это как-то больше похоже на разводилово.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как в «Додо Пицца» потеряли 8 миллионов за один час из-за технической ошибки, а потом вернули