company_banner

[обновлено] Как нагрузочное тестирование процессинга обошлось нам в €157 000 и почему никого не уволили


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


    К исследованию побудили два фактора: появление у нас собственного процессинга карт и предстоящая крупная распродажа одного из популярных в РФ онлайн-ритейлеров.


    Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.


    Как оказалось, мы не одиноки – ни один из наших банков-партнеров еще полгода назад не знал своего настоящего «потолка» и решал проблемы по мере поступления. По сути, они просто добавляли новые мощности прямо во время распродаж, хотя и не всегда успешно.


    Будущие жертвы


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


    Ниже представлена упрощенная схема взаимодействия нескольких организаций для обеспечения возможности оплатить какой-то товар картой через сервис Яндекс.Денег:



    Все ключевые участники эксперимента на одной схеме. Яндекс.Танк – это отличный инструмент Яндекса для нагрузочного тестирования и комфортного анализа производительности.


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


    1. Заполненная форма с данными карты передается на серверы фронтенда, которые ее обрабатывают и передают данные в бэкенд, а в дальнейшем – в отвечающее за работу со счетами ядро.


    2. Платежный сервис блокирует сумму операции на счете пользователя и параллельно отправляет информацию об операции в банк-эквайер, который далее передает сведения в Mastercard и НСПК.


    3. Спустя сутки НСПК присылает файл блокировок в банк-эквайер и Яндекс.Деньги, после чего список блокировок разбирается в наших микросервисах и происходит списание денег со счета пользователя.

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


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

    Тут есть один тонкий момент. Дело в том, что все банки и Mastercard зарабатывают на выставляемых друг другу комиссиях за переводы. Сделать такую комиссию нулевой для тестов было практически невозможно. По нашим оценкам, совокупная цифра должна была составить 0,7% по отдельному коду категории оплаты MCC.


    Кстати о комиссии

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


    Запомните этот момент – в конце статьи будет с чем сравнить.


    А не расстрелять ли нам процессинг


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


    1. Производительность ключевых микросервисов (например, связанных с шифрованием карточных данных) ограничена лицензией.


    2. Расположение микросервисов тоже ограничено лицензией. То есть сервер с купленной лицензией нельзя даже перенести в тестовую среду.


    3. Никто из наших банков-партнеров ранее ничего подобного не проводил и свою емкость не исследовал, поэтому просить мудрого совета было не у кого. Здесь выручило тесное сотрудничество с Mastercard и крупицы знаний из личного опыта отдельных людей.

    В качестве подготовительных действий, мы также отключили дополнительную защиту платежа 3DSecure (SMS-коды), сняли лимиты на число и сумму операций на каждом этапе платежа, а также договорились со службами безопасности участников, чтобы они не били тревогу.

    Тем важнее становился проект для Яндекс.Денег, так как кроме практической пользы можно было сделать нечто полезное для всей российской банковской отрасли – результаты и методика исследования могут пригодиться не только нам. Кроме того, мне лично всегда было любопытно, как поведет себя наш процессинг, если его как следует «расстрелять».


    Радиус поражения


    Как вы понимаете, никто не согласовал бы команде даже потенциальную остановку сервиса. Даже на несколько секунд.


    Поэтому расстрел предстояло сделать бережным и прогнозируемым:


    • В качестве нагрузочной операции выбрали пополнение счета кошелька с банковской карты, которая привязана к другому кошельку. Эта достаточно простая операция влечет за собой массу транзакций между Яндекс.Деньгами, банком-эквайром, платежной системой и НСПК. Что и требуется для эксперимента.


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


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

    MCC код (Merchant Category Code) — представляет собой 4-значный номер, присваиваемый платежными системами VISA, Mastercard и др. для классификации деятельности торговой точки в операции оплаты по банковским картам. Для владельца такой торговой точки важно получить как можно более выгодный MCC и платить меньшую комиссию платежной системе.

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



    Общая схема эксперимента: многопоточное пополнение кошельков с банковских карт других кошельков.


    Для эксперимента мы согласовали уровень подаваемой интенсивности в 20 RpS (Requests per Second, число запросов в секунду). Для достижения большей производительности можно добавлять новые модули, но в схеме эксперимента присутствовал только один.


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



    На графике виден рост производительности на модуле процессинга при росте входной интенсивности, с провалом в центре как раз в момент проседания производительности нашего процессинга.


    Кроме того, тесты вызвали некоторые проблемы в нашем бэкенде и ядре системы, создав массу блокировок по карточным счетам. Блокировки – это нормальная ситуация для любой карточной операции, так как перед реальным списанием деньги просто блокируются на счету пользователя и запись об этом попадает в общий файл Mastercard.


    Такой файл каждый банк-эквайер ежедневно получает от Mastercard каждый раз в одно и то же время по согласованию и далее его разбирает. Так вот, после экспериментов файл с обычным размером 20 МБ увеличился в 5 раз и стал весить 104 МБ. На отработку такого списка потребовалось больше ресурсов, то есть пришлось переписать отдельные модули микросервисов, которые обрабатывали файл блокировок.


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


    Продолжаем обстрел


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



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


    После окончания потока в 24 778 операций объем блокировок для каждой карты продолжил расти, что приводило к замедлениям при проведении платежей: перед каждым списанием процессингу приходилось считывать заново весь список блокировок конкретной карты. Решение — увеличить число карт с 50 до 10 050, что позволило для каждой сократить список блокировок с 200 до 1 при аналогичном количестве операций.


    Следующая волна тестов принесла 50 000 операций, а списания подгрузились в базу процессинга за 40 минут, после чего нужно было их еще и обработать. Файл блокировок продолжал угрожающе расти с каждым экспериментом. А ведь ключевая БД процессинга работает на Oracle с ограничением в 4 ГБ на файл. До предела еще далеко, но становилось некомфортно.


    В ходе отдельного эксперимента мы оценили производительность обработки списаний. За сутки провели тесты с интенсивностью 15 блокировок в секунду и последующим потоком списаний. Файл со списаниям пришел к нам в 18:00 следующего дня с задержкой в 1,5 часа, и наш процессинг обработал все 1 135 000 записей за 2 часа 10 минут. Для контраста, обычный разбор среднестатистического списка блокировок занимает десяток минут.


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


    Кроме того, массированный обстрел повсеместно привел к росту размера логов, что дополнительно проверило на прочность нашу систему сбора логов на EHK (Elasticsearch/Heka/Kibana), о которой недавно рассказывали.


    Кульминацией стал эксперимент на двое суток с суммарным числом операций 1 400 000, во второй день которого одновременно происходили две вещи:


    • Проходили тестовые стрельбы с платежами.


    • Разбирался файл блокировок предыдущего дня объемом 3,1 ГБ.

    Две эти операции нагрузили процессинг по полной в рамках существующих лицензионных ограничений 20 RpS.


    Боевые стрельбы закончились через два дня на отметке 3 157 800 проведенных операций. Однако как следует отпраздновать успех и полюбоваться цифрами нам не дали.


    Привет от Mastercard


    Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р.



    При заказе терминала под тестовые операции мы указали неверный MCC код, из-за чего и получилось невероятная комиссия.


    А вот и причина безобразия – мы выбрали не тот код MCC для терминала эквайринга, через который проходили все тестовые стрельбы. Поэтому за операцию на 1 р. платили 4 р. комиссии. Узнать об этой проблеме в ходе эксперимента не представлялось возможным, так как Mastercard выставил счет через неделю.


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


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


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

    Яндекс.Деньги 105,17
    Об электронных платежах и устройстве Я.Денег
    Поделиться публикацией
    Комментарии 82
    • 0
      Разъясните, пожалуйста, что такое RpS?

      3 157 800 операций — это за сколько дней?
      • +1
        requests per second же
        • +2
          RpS — Request per Second — число запросов в секунду, метрика использования сетевого ресурса. В нашем случае, один запрос был равен одному переводу с карты на счёт.

          3 157 800 операций было проведено за двое суток эксперимента.
          • +2
            Мы обычно используем термин tps — transaction per second
            • +2
              rps != tps, обычно rps в лучшем случае равен tps или всегда меньше (а порой на порядок).

              «Хозяйке на заметку»: если общаться не только внутри IT, а ещё из бизнесом — rps проще объяснить и " продать", чем tps (хотя и то и то, весьма сложно объяснимо, обычно все хотят мерять «пользователями» — что совершенно неверно с точки зрения нагрузочного тестирования).
              Да и «запросы», по-хорошему, «транзакциями» называть не стоит (легко будет запутаться, если читать литературу, пользоваться инструментами, например newrelic), если речь только про название, а не суть.

              RPS — это прежде всего, то что породило запросы к сервису (как правило внешние), а TPS — это то, что уже происходило внутри и пораждало запросы (транзакции) к другим сервисам, базам данных, да даже просто другим участкам кода и в принципе много чего ещё можно измерять, в зависимости от возможностей вашего мониторинга.

              Всё конечно весьма условно, но по опыту, в такой терминологии жить гораздо проще. ;)
              • 0
                Спасибо!
                Мы чаще тестируем только одну систему, все остальные на заглушках, так что tps отличается от rps только если часть транзакций принимаются но не обрабатываются, то есть после достижения макс.перф, так что мы rps называем tps.
                В данном случае, конечно, все эти ньюансы надо учесть.
          • 0
            +поправили в статье — спасибо!
          • –3
            Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.

            Да, это ужасно интересно!
            • +3
              Какая прекрасно мелкая, нелепая и дорогая ошибка. Человеческий фактор во всей красе, надо полагать.
              • 0
                Без него никуда. Я помню как-то несколько лет назад Гугл пропал для всей России на несколько часов. Оказалось тоже кто-то опечатался: подключили новый, ускоренный, канал но ошибка в таблицах роутинга привела к тому, что вместо разрешения обоих каналов они оба оказались запрещены (где-то «или» с «и» перепутали).

                Думаю там убытки сравнимые были…
              • +1
                > Как нагрузочное тестирование процессинга обошлось нам в €157 000 и почему никого не уволили

                Я то подумал проблема была у вас и с интересом читал что же вы не правильно сделали, а оказывается банка-эквайринг ошибся(
                • +1
                  вообще поток слабоват, в начале статьи писали про сотни операций в секунду. Все таки хорошо, если бы можно было на полноценной тестовой системе всё это повторить, было бы и дешевле и можно было бы больше чем 20tx/sec послать. Которыми в общем то мало кого удивишь…
                  • 0
                    Вы сильно удивитесь, когда начнете узнавать реальные цифры производительности российских банков-эммитентов. Действительно думаете, что по карточке среднего российского банка идет поток в 20 транзакций в секунду?
                    • +1

                      Мне интересно, или даже любопытно, у вас есть какие-нибудь числа по поводу пиковой нагрузки в такого рода случаях?


                      Например, среднее время ответа (запрос + валидация + перевод) какой-либо операции (например, оплата по карте), сколько транзакций в секунду в час пик, а сколько ночью.


                      Я иногда присутствую при нагрузочном тестировании и мне интересна чужая статистика для сравнения.


                      Спасибо заранее.

                      • +5
                        В Qiwi, правда, по кошельку тестируем от 100 до 200 транзакций в секунду на магазин. AliExpress умеют устраивать красивые акции с эффектным ростом оборота. :) image
                        • +7

                          Как можно читать этот график, если на нем нет оси Y?


                          Иллюстрация в тему

                          • 0
                            Число оплат за 5 минут. Y раскрыть не могу, NDA же. :)
                            • 0

                              Так Y не обязательно должно быть в настоящих числах, может быть и в у.е.
                              Главное видеть, сколько было до, и насколько это линия подскочила.
                              Сейчас это может быть так: было 90 у.е, стало 99, а шкала от 90 до 100

                          • 0
                            AliExpress умеют устраивать красивые акции с эффектным ростом оборота. :)

                            О, да, распродажи и подготовка к ним — это уйма других интересных историй :) Производительность карточных авторизаций крайне важна и для нашего бизнеса, и для исследований. Хотя бы потому что нагрузки там значительно больше и финансовые риски выше, особенно в преддверии распродаж. Такие акции — как раз интересны взрывным ростом интенсивности, когда график улетает в потолок. Мы на регулярной основе исследуем на боевой среде latency и throughput возможностей нашей системы по карточным авторизациям, чтобы гарантировать поддержку на уровне сотен операций в секунду (точно не меньше 500 TpS). Причем такие эксперименты не требуют от нас финансовых затрат, там мы давно всё учли :).
                            • 0
                              500 — огонь. А в чем была разница с тестированием из статьи? Почему там всего 20 тогда?
                              • +1
                                Так от 500 TpS — это про авторизации карточных операций, а операций по картам собственной эмиссии — от 20 TpS. Кроме того для авторизаций карточных операций проводились эксперименты по нахождению конкретно максимума производительности, а в текущей статье мы описали stress и volume тестирование для операций по своим эмитированным картам.
                                • 0
                                  Понял, спасибо! :)
                            • 0
                              Спасибо, если я правильно понимаю, вы симулируете ситуацию, когда магазин получает платежей от Qiwi клиентов с throughput 100-200 TpS? А какой в этом случае получается response time? Когда пользователь видит, что покупка успешна, она действительно успешна, или «запрос принят и сейчас обрабатывается»?

                              А график, насколько я вижу, содержит тот самый пик при тестировании? Или же это Shopping Festival 11.11, а стрелочка показывает обыкновенный «размер» выручки в каждый день?
                              • 0
                                Спасибо, если я правильно понимаю, вы симулируете ситуацию, когда магазин получает платежей от Qiwi клиентов с throughput 100-200 TpS

                                Да.
                                А какой в этом случае получается response time?

                                Норма — в пределах 2-3 секунд.
                                Когда пользователь видит, что покупка успешна, она действительно успешна, или «запрос принят и сейчас обрабатывается»?

                                Успешна. Причем онлайн обновляется баланс клиента и, по умолчанию, баланс компании, которая принимает платеж.
                                Или же это Shopping Festival 11.11, а стрелочка показывает обыкновенный «размер» выручки в каждый день?

                                Все верно, это Ali 11.11. Только не выручки, а числа оплат. Графики с тестов не такие эффектные. :)
                              • 0
                                без оси y этот график не представляется важным или несущим хоть какую-то информацию… ну понятноже, иначе как соотношение понять
                              • 0
                                Я иногда присутствую при нагрузочном тестировании и мне интересна чужая статистика для сравнения.

                                Я бы с радостью рассказал о них подробнее, но пока это тайна.
                              • 0
                                160 в секунду. И это год назад.
                                • 0
                                  работая в одном из вендоров процессинга — в принципе, какие-то цифры есть…
                                  Но насчёт «среднего российского банка» — думаю вы правы, 20tps вполне реальная ситуация.
                                  • 0

                                    У нас 130

                                  • +2
                                    В рамках проведённого эксперимента в первую очередь нам было важно провести именно stress и volume тестирование, оценить влияние на систему в ходе постоянного длительного накопления операций. Мы не пытались выяснить максимальную производительность, поэтому и стреляли не до отсечки. Кроме того предметом исследования являлись не авторизации карточных операций, а операции по картам собственной эмиссии на одном из сегментов процессинга. Каждый такой сегмент использует готовое платное решение от стороннего производителя. Мощности одного такого сегмента ограничены, а их увеличение требует привлечения дополнительных денежных средств.
                                    • 0
                                      20tps это очень много для эквайера/платежного шлюза. Сервисов, которые выдают больше 1tps можно по пальцам пересчитать. И если они возникают банки действительно руками увеличивают мощности. Условно должно произойти чудо, чтобы трафик Али или Киви пошел через тебя.
                                    • +1

                                      Спасибо огромное, материал и опыт просто бесценные.
                                      Безумству храбрых поем мы песню.

                                      • +14
                                        Так вы заплатили все-таки 157 000 евро или отсудили свою правоту?
                                        • 0
                                          Так вы заплатили все-таки 157 000 евро или отсудили свою правоту?


                                          В итоге мы заплатили существенно меньше, сократив стоимость на порядок. А это уже успех, достаточный, чтобы никого не увольнять :)
                                        • +1

                                          Как то непонятно


                                          Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию)… Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р… Поэтому операции проводились не по оговоренной ставке. Грубо говоря, за операцию на 1 р. мы платили 4 р. комиссии.

                                          Как с 1 р. за операции при комиссии в 4 р. сумма выросла более чем в 75 раз?


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

                                          Такой файл каждый банк-эквайер ежедневно получает от Mastercard каждый раз в одно и то же время по согласованию и далее его разбирает.

                                          Mastercard и НСПК присылают файлы, но в одном моменте один, в другом другой...


                                          Дело в том, что все банки и Mastercard зарабатывают на выставляемых друг другу комиссиях за переводы.

                                          НСПК не за бесплатно работает

                                          • +1
                                            Как то непонятно. Как с 1 р. за операции при комиссии в 4 р. сумма выросла более чем в 75 раз?

                                            В итоге мы провели 3 157 800 операций при комиссии 4 р. за штуку, и общая сумма составила 12 631 200 р. или € 157 890 на момент организации эксперимента.
                                          • +1
                                            Странная терминология для процессинга. Обычно процессинг оперирует термином tps (transaction per second). И что это за нагрузка 20 tps? Вон в процессингах идут 1500 tps от которых TSYS загибается — вот это нагрузка!

                                            Вообще не ясен смысл статьи, если честно. Статья о том как мы накосячили с MCC в проде? Почему нельзя было в тестовой среде это сделать?
                                            • +1
                                              Вероятно причина в том, что хотели протестировать работу всей структуры в целом.
                                              Надо сказать, что 125 тысяч (с учётом комиссии 0.7 212.5 тысяч) очень небольшая цена за такие данные.
                                              Главное, что бы такое тестирование не вызвало проблемы на проде!
                                              • +1
                                                А почему вы 125 000 считаете потерянными? Они же на свои кошельки переводили. Стоимость эксперимента должна была быть 0.7% от 125 000. То есть в районе тыщи рублей.
                                                • 0
                                                  точно
                                                  Я ещё и 0,7% перепутал с коэффициентом 0,7 :)
                                            • 0
                                              Подскажите, а вы проводили эксперимент одновременно с работой обычных клиентов? От них не было жалоб на какие-нибудь задержки в обслуживании?
                                              • 0
                                                Подскажите, а вы проводили эксперимент одновременно с работой обычных клиентов? От них не было жалоб на какие-нибудь задержки в обслуживании?

                                                Да, эксперимент проводился вместе с работой обычных клиентов на той же среде. При этом наши экспериментальные операции фактически ничем не отличались от аналогичных пользовательских. И самое приятное для нас — никто из них не пострадал. Все было сделано более, чем аккуратно.
                                              • –4
                                                Если что-то обошлось в круглую сумму, но никого не уволили — статья про Яндекс.
                                                • +1
                                                  Для любого, кто видел какой-нибудь процессинг изнутри статья странная примерно вся, но как базовика меня более всего удивило вот это:
                                                  А ведь ключевая БД процессинга работает на Oracle с ограничением в 4 ГБ на файл.
                                                  Что это за ограничение и откуда взялось?
                                                  • 0
                                                    Это ограничение на размер datafile, но в tablespace может быть много файлов, так что это не повлияет.
                                                    • 0
                                                      Что-то я тупанул — если это ограничение на datafile ASM, то там не 4, а 2, и не GB, а TB, так что вообще не понятно откуда такое число взялось…
                                                    • 0
                                                      Там 32-битная машина, что ли?
                                                      • +5
                                                        4Гб ограничение FAT )
                                                        • 0
                                                          Действительно, странно. UTL_FILE ограничений на размер читаемого файл не имеет, external table тоже, sql*loader тем более. Было бы интересно узнать подробнее про это ограничение.
                                                          • 0
                                                            Я по оракл не спец, но тоже заинтересовался, вспонив fat32 :)
                                                            Нагуглил вот это:

                                                            http://alldba.ru/index.php/38-subd/index.php?option=com_content&view=article&id=64&Itemid=164
                                                            • +1
                                                              Единственное, что приходит в голову с таким ограничением — это Oracle Database Express Edition. Цитата с сайта —
                                                              Oracle Database XE может быть установлена на любой компьютер с любым количеством процессоров (одна база данных на машину), но с ограничением в 4Гб пользовательских данных, использует не более 1Гб оперативной памяти и только один из имеющихся процессоров.

                                                              Собственно пруф
                                                              • +1
                                                                Что это за ограничение и откуда взялось?

                                                                Гипотезы интересные, но в нашем случае всё несколько иначе :) На момент проведения эксперимента все блокировки приходили в виде xml-файла, загружающего в поле Oracle типа CLOB, максимальный размер которого 4 Гб. Мы уже переписали этот механизм и результаты проведённого эксперимент тут сыграли не последнюю роль.
                                                                • 0
                                                                  Безотносительно креативности идеи хранить блокировки таким образом, ограничение все таки примерно 8Тб, а никак не 4Гб. Дока.
                                                              • 0

                                                                А что было бы если размер файла превысил 4ГБ и база упала? И вообще был ли риск для простых пользователей?

                                                                • –26
                                                                  Что-то мне кажется, потому никого не уволили так как решение принимал какой-то начальник, важный начальничек.
                                                                  А так как он чей-то родственник начальничка повыше, за него сверху заступились и убыток «списали».
                                                                  Ну в прочем как обычно в большинсте компаниях на постсоветском пространстве.
                                                                  За коррупцию вообще молчу, это поголовно.
                                                                  ИМХО.
                                                                  • +1
                                                                    Равнять совок и Яндекс не стоит. Яндекс — единственная европейская компания на территории РФ зародившаяся и ныне живая. Нет в них совка, так уж получилось.
                                                                    • +2
                                                                      единственная европейская компания на территории РФ

                                                                      откуда дровишки?

                                                                      • +2
                                                                        «европейская» — это у вас синоним «хорошая»?
                                                                      • +6
                                                                        Вы статью вообще до конца дочитали? Или вы хотите, чтобы Яндекс уволил сотрудников банква-экваера за то, что те затупили? :D
                                                                        • –11
                                                                          Конечно прочитал.
                                                                          Только мне не понятно, кто тот самый ответственный человек допустивший такую оплошность.
                                                                          Если бы это был рядовой или руководитель низшей планки — он бы уже давно был уволен, как минимум.
                                                                          Эта «счастливая» статья напоминает пару месяцев назад историю как devops случайно удалил не ту базу и как они потом восстанавливали старую базу при посторонней помощи. И всю эту историю выложили в паблик.

                                                                          PS. сотрудники яндекса всегда минусуют критику? И это называется «единственная европейская компания на территории РФ зародившаяся и ныне живая»?
                                                                          • +11
                                                                            Я не сотрудник Яндекса, но я минусанул. Причина? Со словами «мне кажется» идёт оголтелое (ака не имеющее доказательств) обвинение в кумовстве, с плавным переводом вопроса в политическую плоскость, с параллельным обобщением на всю индустрию.
                                                                            • +1

                                                                              "Это был рядовой или руководитель низшей планки" только блин не из Яндекса. Это так сложно понять?

                                                                              • +3
                                                                                > он бы уже давно был уволен, как минимум.
                                                                                я не очень понимаю, а что бы это улучшило? Увольнение сотрудника за оплошность — это вообще как-то дико, на мой взгляд, звучит. Можно уволить за саботаж, за то, что не работает, за обнаружившуюся непроходимую тупость, постоянно приводящую к убыткам, можно по политическим мотивам. А за единичную ошибку — вы это как потом объясните его коллегам?
                                                                                • +1

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


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

                                                                              • 0
                                                                                Ну, можно было сперва прогнать пару пробных транзакций, выждать день, убедиться что всё ок и гнать нагрузку.
                                                                                • 0
                                                                                  Собственно говоря, так и было, мы провели пробные транзакции, подождали день, перешли к крупномасштабному эксперименту, но счёт по ним всем выставили через неделю. При этом итоговый счет содержал только сумму по всем транзакциям в совокупности без дополнительных комментариев.
                                                                                  • 0
                                                                                    Посмотреть МСС можно сразу после блокировки, так что косяк не только у банка.
                                                                                • +1

                                                                                  "Или вы хотите, чтобы Яндекс уволил сотрудников банква-экваера за то, что те затупили? :D"


                                                                                  Насколько я понял, ошиблись сотрудники Яндекс.Денег.

                                                                              • –2
                                                                                Тема "… почему никого не уволили" не раскрыта :-) В результате 2-х месяцев боданий был перерасчет или как?

                                                                                Проглядывает жуткая не технологичность процессинга — обмен файлами транзакций, ежесуточный их разбор…
                                                                                Планируется ли переход на блокчейн или что-то подобное?
                                                                                • 0
                                                                                  обмен файлами транзакций, ежесуточный их разбор

                                                                                  ;) добро пожаловать в реальный мир…
                                                                                  • +5
                                                                                    Зачем тут блокчейн!?!?!? Что в платежной системе банк не доверяет оператору платежный системы? Что есть ситуации кода целые сегменты ПС выплывают на стуки из онланйа?
                                                                                    Что это за новомодный тренд пытаться засунуть блокчейн во все щели!
                                                                                    • 0

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

                                                                                    • +2
                                                                                      Обмен данными по блокировкам нужен. В некоторых случаях операцию по карте может одобрить платежная система, и банк не будет об этой операции знать пока она ему об этом не скажет.
                                                                                    • +1
                                                                                      Классная статья, спасибо!
                                                                                      Вопрос насчет вашей системы логирования на основе эластика: сколько ГБ логов туда попало за день при максимальной нагрузке(если не секрет конечно)?
                                                                                      • 0
                                                                                        Сотни миллионов операций во всей системе не сравнимы с единицами миллионов операций процессинга во время нашего эксперимента, поэтому существенной нагрузки на систему логирования на основе эластика мы не заметили.
                                                                                      • 0

                                                                                        Почему графики как у JMeter? Использовалась та же библиотечка?

                                                                                        • 0
                                                                                          Да, там самая библиотека. В качестве генераторов трафика использовались и phantom (дефолтный для Яндекс.Танка) и jmeter.
                                                                                        • 0
                                                                                          Для меня самое большое приключение — это купить билет на КампНоу, когда за 2 дня до матча выбрасывают оставшиеся 10тыс билетов. Сайт пускает в порядке живой очереди, иногда с часовым ожиданием… Платежная система может выбросить на последнем этапе…
                                                                                          В общем, хотелось бы, чтобы системы были более совершенны и дарили пользователям только радость)
                                                                                          • 0
                                                                                            Активная работа ритейла подразумевает ещё и активную работу ККМ нового типа. Не будет ли этот момент узким местом?
                                                                                            • 0
                                                                                              Гипотетически вполне вероятно ККМ может стать узким местом. Это, кстати, хорошая перспектива для дальнейших исследований, которые нам ещё предстоит провести. Пока у нас такой возможности не было.
                                                                                              • 0
                                                                                                Там проблема в фискальных накопителях. Они обрабатывают около 1 чека в три секунды.
                                                                                                Как только они научатся быстрее шифровать — будет легче.
                                                                                              • 0
                                                                                                Для полноты картины нужно было бы упомянуть железо, на котором работает процессинг.
                                                                                                Приведенные цифры мало о чем говорят без этого.

                                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                Самое читаемое