7 ошибок одного Black Friday. Основано на реальных событиях

Всем привет! Меня зовут Влад Опухлый, я — Magento Tech Lead. Последние 5 лет я работаю в компании Magecom. В этой статье расскажу об истории одного из самых сложных кейсов за всё то время, которое я занимаюсь Magento-разработкой. Это были действительно безумные сутки с большим количеством людей на созвоне, когда мне пришлось работать около 30 часов подряд. С тех пор я не люблю проводить Black Friday в офисе.

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

Это статья основана на моём докладе с Magento Meetup Online #8, который я доработал и добавил больше конкретики и советов.

Иллюстрации Марии Рыбак

Ошибка #1: Вера в безупречность дорогого Payment Method

Мы переезжали с Magento 1 на Magento 2, у нас было примерно 750–800 тыс. заказов и чуть меньше кастомеров. В целом, не мало, но и не так много для Magento.

После нашего переезда на Magento 2 нужно было перенести все payment methods, чтобы у пользователей была возможность повторно совершить ордер и использовать данные карт, внесенные ранее за прошлые 5–7 лет существования на Magento 1.

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

На хорошее тестирование времени, к сожалению, не хватало, особенно на тестирование продакшн credentials.

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

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

Мы увидели странный SQL-запрос, который увеличивал нагрузку на базу данных в геометрической прогрессии.

Целью этого запроса была проверка fraud-detection system модуля Cyber Source. Это модуль платежной системы, который маркировал ордера как мошенник/не мошенник, нужна ли перепроверка или можно обрабатывать и списывать средства автоматически.

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

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

Мы начали быстро искать причину.

Первое, что пришло на помощь — AWS DB monitor, New Relic и SQL slow query.
С помощью просмотра данных статистики был найден самый тяжелый и медленный скрипт. Как оказалось, поле, по которому выполнялась выборка, было без индекса, и добавление индекса помогло убрать бешеную нагрузку от запросов.

Это быстро спасло ситуацию, но с этой ошибки я вынес для себя урок. Если мы покупаем дорогой и популярный third-party модуль, это ещё не значит, что он будет работать идеально и быстро.

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

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

Ошибка #2: «Стандартные» лоад-тесты

60/30/10 — это примерная пропорция того, как распределяется трафик на сайте, где:

  • 60% трафика сёрфят по закэшированным страницам;
  • 30% трафика занимаются поиском;
  • 10% находятся сейчас на чекауте.

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

В случае, если не все запросы покрываются Elasticsearch, увеличивается количество запросов на базу данных, и это в свою очередь замедляет следующие 10%, которые находятся на чекауте.

Как вы знаете, страница чекаута (и корзины) не кэшируется. 60% трафика кэшируется при помощи Varnish и Full Page Cache, а 30% сохраняется в Elasticsearch — запросы возвращаются быстро и не сильно нагружают базу. А с теми 10%, которые должны идти на чекаут, дела обстоят хуже.

Как было сказано выше: самые сложные страницы — чекаут и корзина. Они обе не кэшируются и добавляют очень много нагрузки на базу данных.

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

Почему универсальные нагрузочные тесты помогают не всегда

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

В нашем случае причиной обрушившегося чекаута и сайта был тот факт, что пропорция на самом деле составляла 30/20/50, где 50% трафика ушла сразу же на чекаут! Да-да, 50%.

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

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

Поэтому трафик ещё за несколько дней был низким, а именно в Black Friday все пользователи ринулись на чекаут, а многие даже заранее сложили в корзину акционные товары.

Пользователи сайта начали замечать, что чекаут работает медленнее, а самое простое решение — обновить страницу, а лучше сделать это несколько раз, что вызывало еще больше сложных PHP/SQL и AJAX-запросов.

В результате, сессии не закрывались и накапливались как снежный ком, пока база данных не начала отвечать на запрос SELECT * FROM Customers в течение 20 секунд.

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

Быстрым и временным решением проблемы, чтобы избежать потери заказов, было открыть второй канал продаж на какое-то время, чтобы избавить от огромного количества людей на чекауте и перенаправить поток. Спасало и то, что у клиента было больше 40 тыс. представителей в США и Канаде, и они позволили выжить кастомер-саппорту.

На уровне сервера, на 502 страницу была добавлена ссылка на страницу помощи, куда можно дозвониться, чтобы хоть немного уменьшить количество одновременных пользователей на чекауте, которые в пике переваливали за 1000!

Это большая нагрузка для Magento. Возможно, вы справлялись с нагрузкой, когда 1000+ кастомеров на чекауте хорошо обрабатывались, но это была не наша история. Мы тогда только мигрировали Magento и 2–2,5 месяца работали по плану, а все лоад-тесты успешно проходили.

Ошибка #3: Плохая координация команд

Мы работали с большой командой из примерно 30 человек. Фактор, который заставлял нас спешить — грядущий юбилей самого бренда клиента. Мы понимали, что есть дедлайн, и нужно быстро выдать результат и работающий сайт. В целом, у нас всё получилось.

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

Как только мы вытащили сайт из даунтайма, и вроде нагрузка чуть уменьшилась, и сайт начал работать стабильнее, начали приходить заказы — 3–5 штук в секунду.

Мы начали замечать, что просадка уже шла не только по базе данных, а и по процессору. На то время была поднято два сервера по 48–50 ядер в AWS — громадные ресурсы, но даже их получилось убить, так как мы создавали второй сервер, и команда клиента решила, что они будут их администрировать.

Мы создали один сервер, настроили, протестировали — всё было неплохо.

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

Проблема была в том, что в одном образе сервера был и Varnish, и Nginx, и PHP-FPM — всё в связке. То есть вместо того, чтобы был один Varnish, за Load Balancer и два сервера отдельные с PHP-FPM. У нас всё получилось так, что в каждом сервере по одному инстансу Varnish. Это привело к тому, что кэш на серверах не прогревался полностью, и запросы уходили на Magento, минуя Varnish и не будучи зашифрованными.

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

У нас уже не было проблем с платежной системой, которая выполняла медленные запросы, но мы увидели, что линейно начала нарастать нагрузка на базу и увеличилась нагрузка на процессора. В итоге, два сервера по 50 ядер были загружены почти на 100%.

Молниеносным решением клиентской команды DevOps было увеличить ресурсы. После того, когда два сервера по 96 ядер были нагружены уже на 70%, ситуация стала улучшаться. В целом, больше не терялось время на обработку критического количества запросов и ордеров.

Как только показалось, что мы всё разрулили, мы столкнулись с очередной проблемой. Заказы сформированы — пришло примерно 7 000 заказов за 2 часа. Сайт справился, и их нужно было обработать, запроцессить и начинать отправлять.

ERP клиента тоже не была безупречной, хорошо протестирована для работы в нагрузке и не смогла вытащить такое огромное количество запросов за раз и начала отказывать. Срочно пришлось писать SQL-запрос, изменяющий статус на временный, и потом обновлять по 300–500 ордеров за раз тоже при помощи SQL, чтобы их можно было вытащить во внешнюю систему, обработать и отправить клиентам. Это тоже заняло примерно полчаса-час и делалось в спешке, примерно на 20-й час от старта Black Friday.

Ошибка #4: Отличия в настройках серверов

Следующее, с чем мы столкнулись — проблемы в конфигурации Load Balancer.

Мы заметили, что второй сервер начал перегружаться сильнее, и пошёл перекос в пропорции 30% на 70%. Было сложно быстро найти причину, но позже увидели, что одним и тем же пользователям постоянно прилетают одинаковые ответы от AWS, что означало, что юзеры фиксируются за серверами.

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

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

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

Ошибка #5: Коробочные настройки Magento/AWS/MySQL

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

База данных всегда выдерживала меньше всего нагрузки, и из-за спешки протестировать репликацию мы не успели. Соответственно, Read Replica не была настроена, мы не использовали Magento Cloud, поэтому базе данных приходилось хуже всего.

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

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

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

После прогонки, донастройки базы и перезагрузки на 48 ядрах, она начала работать в нагрузку 50%, хотя до этого 96 ядер заходили за 100%.

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

Ошибка #6: Медленный код

Мне как программисту сложно сказать, что причина медленного сервера и медленно работающего сайта — медленный код, но такое тоже случается :)

Причины медленного кода и что повлияло на нашу историю:

Причина #0. Бюрократия и согласованность со срочными релизами.

Причина #1. Недостаточное время, заложенное на код ревью.

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

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

После Black Friday необходимость в более тщательных тестах и подготовке к релизам появилась.

Причина #2. Отсутствие пост-релизных performance тестов.

В Magento Cloud с коробки есть New Relic и Blackfire — невероятно классная штука на продакшене!

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

Ошибка #7: Всё вместе

В целом, у нас был очень быстрый сервер, классное оборудование, одни из самых больших инстансов и огромная команда из 30 человек.

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

При том, что мы протестировали нашу ожидаемую нагрузку — примерно 10 000 параллельных юзеров, 3 000 параллельно ищущих юзеров и около 100 юзеров на чекауте, — всё пошло не по плану.

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

Выводы и советы

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

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

При покупке third-party модулей не думайте, что цена = качество. Если модуль стоит больше $1000, всё равно нужно его протестировать, посмотреть логику и желательно сделать это на окружении, максимально близком к продакшену. Некоторые ошибки никогда не появляются на стейджинге, UAT, а когда они появляются на продакшене, может быть слишком поздно.

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

Изучайте поведение кастомеров на сайте. Если у вас предвидится большое количество юзеров на чекауте, внимательно смотрите на настройки базы и тестируйте базу на нагрузку. База — самый тонкий боттлнек, и огромное количество AJAX-запросов, которые идут к базе на чекауте, могут стать серьезной проблемой.

Полезные инструменты

Google Analytics — полезный инструмент, который позволяет понять среднестатистическое поведение трафика. Можно зайти и посмотреть, сколько человек на чекауте в режиме реального времени, за определенный период или после отправки рассылок, например, чтобы понимать, на что ориентироваться.

New Relic позволяет увидеть самые тяжелые запросы и боттлнеки по базе. Можно посмотреть, как сильно загружена база и сколько сессий открыто. Больше всего блокируют базу открытые сессии, которые не смогли закрыться. Лимит на очень больших серверах, примерно на 100 ядрах, для баз данных составляет чуть больше 1000. В нашем случае сайт начинал работать очень медленно примерно после 1000 коннекшенов. После того, как решались проблемы с базой, эти коннекшены моментально закрывались и падали до нормального количества — 10–20.

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

xDebug Profiler + PHPStorm. Можно использовать эту связку локально, она тоже позволяет протестировать отдельные страницы. Хотя я считаю, что связка Blackfire и New Relic куда лучше, чтобы видеть максимально близкие результаты к тому, что будет на продакшене.

Varnishstat. Это то, что помогло нам выяснить причину некэшируемых запросов, которые гробили базу после новостной рассылки. Varnishstat — команда, которую можно запустить на инстансе, где у вас крутится Varnish и посмотреть hit rate (количество запросов, которые попадают/не попадают в Varnish), логи, какие запросы по каким урлам идут. Когда мы увидели на нашем проекте, что большинство запросов, их поведение, характер и формат ссылки очень похожи, мы связались с командой, которая делала рассылку, и девопсами. Поняли, что для таких ссылок у нас не настроены правила кэширования для Varnish. А после того, как правило добавили, перезагрузили, нагрузка ушла с 95–100% до 12% спустя 3 минуты. Вот такая простая, но очень полезная утилита.

MySQL Tuner. Утилита, которая позволяет проверить, какие есть параметры в MySQL или MariaDB, например. Можно настроить, чтобы он работал эффективнее и использовал ресурсы эффективнее.

Полезная книга которая могла уберечь от стресса и многих ошибок: «Идеальный программист».

👍НравитсяПонравилось14
В избранноеВ избранном6
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Да пофиг это все. Делитесь ссылками на вкусные предложения.

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

Прям вспомнил — вздрогнул :) У нас такого типа авралы были при старте продаж каждой новой модели айфона. Правда, обычно Magento вытягивала, падали другие системы на бэкофисе клиента, уже при непосредственной обработке заказаов ...
С другой стороны, потом работал на площадке клиента с рутинными 700К заказов в месяц — и ничего похожего не было. Как систему построить :)
Что подумалось:
— сессии перетащить в Редис, это — общее место много лет как.
— БД — мастер-слейв настроить, вон и в девдокс раздел есть под названием «Split database performance solution»
— там же и про Message Queues можно посмотреть — вдруг, что полезное вынесете
— насколько я помню, сам чекаут сделан так, что достаточно легко горизонтально масштабируется добавлением фронтовых нод.
— ручками профилировать запросы к БД, добавлять (и убирать) индексы, переписывать код в объезд маджентовского БД слоя. Иногда раз в 20-40 производительность поднять удавалось ... ORM там такой, своебразный
— посмотреть на форки MySQL — там тоже что-то выиграть можно
— девопса взять, чтоб подъем дополнительных нод фронта-бэка автоматизировал нормально, дэшбордов красивых с постоянным анализом логов и алертами нарисовал, NewRelic алерты настроил и т.п.
— CloudFlare перед всем поставить можно, иногда полезно.
— выделенную команду сапорт-инженеров создать, чтоб накапливали опыт именно эксплкатации подобных систем. Потом можно как отдельный сервис продавать. Задорого.

Это так, что вспомнилось. Я из этого дивного мира Мадженто вышел уже полтора года как, чего и
вам желаю ...

С другой стороны, потом работал на площадке клиента с рутинными 700К заказов в месяц

на какой платформе если не секрет?

— сессии перетащить в Редис, это — общее место много лет как.

было сделано

— БД — мастер-слейв настроить, вон и в девдокс раздел есть под названием «Split database performance solution»

было сделано

— там же и про Message Queues можно посмотреть — вдруг, что полезное вынесете

мало асинхронного было увы по флоу почти все синхронное было

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

не могу сказать что это прям легко, PHP выполнение при скейлинге лучше, но всеравно в базу упиралось
Есть возможность шардинга базы (на 3 базы разбить) но это привело бы к тому, что потом на мадженто клауд нельзя бы было переехать (что было озвучено клиентом за пол года до черной пятницы)

— ручками профилировать запросы к БД, добавлять (и убирать) индексы, переписывать код в объезд маджентовского БД слоя. Иногда раз в 20-40 производительность поднять удавалось ... ORM там такой, своебразный

более чем валидно, видел на других проектах, работает но не мадженто вей (потом в случае работы с саппортом клауда и траблов с базами саппорт мог бы ссылаться на отпупление от гайдов и best practices (но без плагинов, репозиториев, интерцепторов, обзерверов и тд — 100% быстрее было бы в десятки раз)

— посмотреть на форки MySQL — там тоже что-то выиграть можно

наскольк помню была MariaDB

— девопса взять, чтоб подъем дополнительных нод фронта-бэка автоматизировал нормально, дэшбордов красивых с постоянным анализом логов и алертами нарисовал, NewRelic алерты настроил и т.п.

Идея хорошая, в целом точно помогло бы быть стабильнее, но в пиковом трафике задежки времени на апскейл могли бы вызвать не стабильное состояние

— CloudFlare перед всем поставить можно, иногда полезно.

После проблем с не правильной архитектурой сервера переехали на Fastly, стало лучше

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

был доступен сервис 24/7 но шейред между несколькими проектами ( в черную пятницу понятное дело перегруженнее) чем обычно

В целом все пункты точно валидны и чувствуется что были пройдены а не прочитаны )

Это так, что вспомнилось. Я из этого дивного мира Мадженто вышел уже полтора года как, чего и
вам желаю ...

Что дальше? (после мадженты)

на какой платформе если не секрет?

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

но в пиковом трафике задежки времени на апскейл могли бы вызвать не стабильное состояние

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

более чем валидно, видел на других проектах, работает но не мадженто вей (потом в случае работы с саппортом клауда и траблов с базами саппорт мог бы ссылаться на отпупление от гайдов и best practices

Это — да, есть такое. Задорого делаем модуль с кнопкой «сделать временно хорошо»
При переезде в облако — сносим :)

Что дальше? (после мадженты)

Копаю в направлении поработать наконец-то по специальности, по которой окончил политех — «автоматизация научных исследований». Благо тут недалеко универ № 7 в мире по биотехнологиям ...

Представляю как больно было клиенту когда 1я маджента устарела и вышла вторая с немного «другой» скоростью и сложностью кастомизаций

Знаю отличное решение против проблем Чёрной пятницы, на которое никогда не пойдут: НЕ ДЕЛАТЬ чёрную пятницу. А распродать весь хлам заранее, сказав что до чёрной пятницы ничего не останется (можно сымитировать низкие остатки). А на чёрную пятницу привезти какой-то товар новый, и дать маленькую скидку (опять же сымитировать) или бесплатную доставку при заказе только сегодня.

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

1 хороший товаровед может сократить бюджет скидок чуть ли не в ноль. А 1 хороший маркетолог — сделать чёрную пятницу даже в субботу после неё. Для средних точек (до 5 000 товаров, похожие считаются одним SKU) это может быть 1 человек, для 10000 — 15000 — 2 взаимозаменяемых, возможно даже посменно на 1 рабочем месте.

Почти так и есть, во второй год я тоже скажал почти то же самое (давайте делить трафик)
(порой сложно написать письмо руководству и описать все что есть а не «соглашаться» на то что хотят и говорить «да» )

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

Вообще не вариант, так как многие интернет магазины именно в этот день зарабатывают конские суммы. Сама была на икоме когда-то и видела соотношение спроса в Black Friday и в обычный день.

Ну и прекрасно. Никто не запрещал повесить ВЫВЕСКУ «чёрная пятница». Но продавать при этом не залежалый товар, а наоборот, тот на котором наценка выше, и цена плохо сравнима с конкурентами.

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

Мсье вообще не понимает, что именно значит чёрная пятница для икомерса.

Ну где уж мне понимать расхожие мифы. Как думаешь, за сегодня из ≈200 спама и 60 СМСок, по скольким из них я чего-то купил? И это мне ещё роботы сегодня не звонили

Я совсем не это имею в виду.
Подготовка к BF это не только понимание паттернов поведения клиентов, которые в этот день будут совсем другими, к слову, мы не наступили на те грабли, о которых говорил ТС когда все массово побежали на чекаут сразу.
Это возможность масштабирования системы в случае необходимости, которая также подразумевает под собой blue-green deployment и другие фичи, которые разрабатываются месяцами ранее чтобы с лихвой окупиться за этот один день.
Это изменения в поисковой системе: S&P, Elasticsearch (или что там сейчас стильное, модное, молодёжное), дизайне, тегировании и т.д.
Вывесить баннер «Распродажа» и разослать смски это только верхушка айсберга.

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

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

Разумеется, пустить покупки и поиск через разные точки, чтобы можно было отрегулировать нагрузку — это не по-маджентовски :)

Плюс решение в лоб: пользователь зареган или нет. А если зареган — соответствует ли его профиль живому человеку. Потому что в эту чёрную пятницу тебе просто повезло, что конкуренты DDOS не заказали. А то скопытился бы ресурс уже на первой минуте. А так — спокойно выгружаешь незареганных на отдельный сервер, и пущай они даже там «купить» клацают. Когда уже реально оформляют покупку, с подтверждением контактных данных — тогда уже и переводи её в основной, заодно проверив повторно наличие товара.

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

А чем сильно лучше твой ЭластикСёрч обычного поиска по базе?

Тим що СУБД не призначена для семантичного пошуку
Намагаються, але все ще не спеціалізований інструмент

То зрозуміло, питання було чи він використовується як кеш. А взагалі-то інфа о товарі не настільки масивна, щоб усі його дані не запулити в оперативу, скажімо на рівні бекенду, і шукати лише в пам′яті. Там зовсім інший порядок швидкості, і паралелізація є, і багато ядер проца задіяно. Тому власне питання, чи кешувати на бекенді, чи база сама вміє, чи операційна система то зробить на рівні файлового читання.

Проблема бази — транзакційна цілісність. Тобто, будь-який апдейт фейлить кеш. А це означає, що на майже усі сутності доведеться давати поле, що контролюватиме версію чи таймстемп чи ще щось достатньо унікальне для синхронізації кешу.

Особисто я би дивився саме в бік збергання даних на рівні аплкухи. Бо тоді можна робити безліч цікавих речей. І я не думаю, ще це дорого по ресурсах. Якщо потрібно розкидати то все по 2 і більше різних серверах — то варто лише одному з них дозволити зміни даних, так набагато простіше контролювати цілісність і нема серйозних проблем із трафіком навіть при падінні швидкості каналів, та й у разі збоїв легко знайти винуватця.

щоб усі його дані не запулити в оперативу, скажімо на рівні бекенду, і шукати лише в пам′яті

Як шукати по пам’яті з урахуванням семантики?

для синхронізації кешу

Як апдейт корзини фейлить кеш для sku?

Корзини — ніяк. А от будь-якого SKU, або його наявності — аж бігом. Ми ж бо любимо «нормальні форми», тому у нас скоріше за все нема поля «в наявності», а є поле кількості, ще й в окремій таблиці. А кількість постійно змінюєсться.

Кількість кешується окремо в редіс, показувати на фронті в вигляді several, some, many
Після проведення оплати — змінюється в БД
Чи навіть проводиться як різниця між кількістю замовлених і наявних на складі

То там ще й редіс потрібен? Який сам по собі те ще «щастя» у плані блек боксу, дебажити його задоволення сумнівне.

Спасибо. Прочитал — и прямо накатила ностальгия. Когда-то мы то же писали монолиты по классической 3-tier архитектуре. И, как и следовало ожидать — все упиралось в одну проблему: база!
Я считаю что единая база — это и есть главная архитектурная ошибка, можно сказать это уже анти-паттерн. Сначала все-все, включая сессии пользователей и логи, пихать в одну базу. Потом везде ставить NOLOCK что бы она хоть как-то шевелилась, и в итоге тупо упереться в «потолок», потому что эту мега-базу невозможно масштабировать горизонтально, а «вертикально» уже максимум.
Никакой херово написанный код так не затормозит систему, как запрос в базе! Тем более что не-оптимальный код легко вычисляется профайлерами. А вот проблемы с базой можно увидеть только на реальной нагрузке.
Я видел такие истории несколько раз на проектах 2000х годов. Потом умные люди додумались что далеко не все данные нужно пихать в надежную, но медленную СУБД. Появился NoSQL — и сразу снял больше половины нагрузки с SQL базы.
А сейчас уже большинство смирилось что strong consistency в реалиях облаков практически нереальна, и согласились на eventual consistency. Это дает возможность полностью уйти от единой базы в сторону микро-сервисов.
Собственно микро-сервисная архитектура на текущий момент и есть настоящим решением описанной проблемы. Когда при увеличении нагрузки систему можно неограниченно масштабировать «горизонтально» — то «положить» ее очень сложно! Это может влететь клиенту в копеечку — но ресурсов облака гарантированно хватит на любой наплыв клиентов в Black Friday.

Огромное спасибо за коммент,
Случилось это год назад и тоже вспоминаю с ностальгией и грустью.

Согласен на 100%! (когда база становится ботлнеком, появляется много проблем, блокировки транзакций, задержки в ответах, цепная реакция на всех типах запросов и быстрого решения в высокий трафик вероятно нет)

Но в целом есть ограничение платформы (Magento 2) даже на их PAS/SAS (Magento Cloud) а точнее Adobe Cloud нет возможности юзать NoSQL

Судя по последним слухам Adobe таки решила переписать все на микросервисы (пусть и с запозданием но вероятно через 1-2 года будет)

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

Одно из типичных решений — поменьше фильтровать на базе, побольше на логике. Когда поиск идёт по не-типичным параметрам, стоит сделать поиск по типичным, и сохранить его результат. В идеале, если позволяет трафик (вот, кстати, одна из точек компромиса) отдать всё на клиента, сделав поиск по типичным параметрам, а уже когда начнёт клацать галочки — фильтровать у него же на лету. Но поди докажи ещё браузеру не делать оптимистических загрузок

В принципе, кеширование делает в аккурат то же самое.

В Magento 2 чекаут содержит кучу AJAX запросов и не кешируется (остальное — да)

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

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

Спс за идею

То есть 1 мидл * 1 неделю + QA помануалить (автотест даже сразу не писать, мануалка быстрее, автотест уже в след.версии, когда код устаканится).

В чём суть: просто выдать массив IDшников либо массив полных данных о товаре. Я бы давал полные, ну кроме картинок. Почему так: быстро выдав данные, можно надеяться на столь же быстрый пропуск клиентом мусора и заанкеривание на нужный именно ему товар. И если из 1000 он выберет 1, это хороший результат. 2000? Ну можно и 2000, если он знает, чего хочет. А 100 — так это вообще должна быть дефолтная минималка, на случай если он НЕ знает, чего хочет, пусть увидит глазами первую сотню.

На самом деле, это лишь в теории хорошая идея — чтобы клиенты галочки клацали и по параметрам искали. Вы заставляете их думать. А надо заставлять видеть и немножко читать + самую малость активных действий для создания анкера поведенческой цепи. Конечно, галочки оставить можно и нужно, но в идеале — дать человеку выбрать самому, если количество подходящего ему товара составляет 5%-10% и более (реальный процент зависит от того, сколько попадает в экран). А для этого нужен способ «подсматривать» нужную инфу о товаре, не переходя на него (переход — это принятие решения, читай заставляешь думать). А для этого нужно делать переход только по кнопке, а по нажатию на товар — только смотреть, открыв попап (пусть даже на весь экран).

Да, это нарушает привычное UI. Так в этом же и замануха — чтобы подсадить на UI, которое сначала любопытно, а потом уже не можешь без него обойтись, настолько втянулся за пару заходов. А уж если создать список «недавно просмотренные» столь же доступный, как корзина или список желаний... так это вообще станет расширением памяти клиента. Если конечно не жадничать и проработать UI быстрой работы с этим списком (большие кнопки, настройки приватности, настройки автоочистки).

Цель проста: заставить покупать. Всё остальное вторично и сводится к технической оптимизации. Но в первую очередь ты оптимизируешь память клиента и его выбор. Когда клиент даёт слишком много запросов, для него самого это «слишком» раз в 20 серьёзнее и это кричащий сигнал, что что-то не так, что надо искать способ либо делать выбор за клиента, либо разблокировать «буриданова осла», меняя цены, фотки, описание, или радикально сокращая ассортимент.

ПРИМЕР: типично ищется товар, который есть в наличии и которого нет, и всё это в общую кучу. Догадываешься, насколько мерзостен этот запрос для базы, учитывая пагинацию. Правильно — брать товар ТОЛЬКО который в наличии, его же индексировать для поиска, и только когда клиент просмотрел весь список (а ты правильно посчитал ему страницы, чтобы он захотел посмотреть все) — только тогда лениво смотришь то, чего нет в наличии.

Другой вопрос, как скормить это поисковикам? Придётся давать альтернативные пути. Потому что сделать одинаково, чтобы подходило и человеку, и роботу — нереально даже в теории. А человек в приоритете. А робот может (и будет) давать бесполезную нагрузку, и с огромной вероятностью намеренно ДДОСить. Потому, как только пахнет роботятиной, нужно тут же модифицировать либо поведение текущих страниц, либо перенаправлять его в отдельное дерево (каталог), который он сможет неспешно обойти, не напрягая базу тяжёлой «едой» для мозга клиента.

Классический тест на робота: отсутствие реакции на кнопку. Человек нажмёт второй раз, роботы к этому не приучены.

Появился NoSQL — и сразу снял больше половины нагрузки с SQL базы.

Уф
Не думав, що людям все ще подобається втрачати дані клієнтів

Если внимательно проанализировать все данные, которые хранит современное приложение — то окажется что как минимум 30% из них только сохраняются — и никогда больше не используются! Еще 40% — используются в течении ограниченного времени и дальше лежат мертвым грузом. По-настоящему критичных данных, потеря которых серьезно повредит бизнесу — от силы 10%.
Самое глупое: даже когда используют СУБД что бы «не потерять данные» — то по-факту этой СУБД «выкручивают руки» таким образом что бы она не работала как должна! Ставят везде NOLOCK (грязное чтение!), избегают транзакций, не нормализуют таблицы, и повсеместно реализуют запись по принципу «кто последний — тот и папа».
Интернет-магазины по факту работают так же, как 10 лет назад. Только теперь они генерируют и хранят в сотни раз больше информации. Почему? Да просто потому что могут! Раньше нужно было экономить ресурсы и хранить только самое важное — а сейчас в безразмерные облака можно записывать каждый клик пользователя. И потому будут нужны Big Data технологии что бы разгрести всю эту помойку.

Рант на тему — «всі роблять неправильно, тому це стало нормою робити погано»
А перша частина з взятими зі стелі числами тільки не дуже вийшла

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

По моему личному опыту, если вы не Ебей с Амазоном(а вы cкорее всего не они) то в примерно ста процентах случаев все эти стррррашные проблемы с БД из-за кривых рук. Что, кстати, мы видим и в кулсториях: «добавление индекса помогло убрать бешеную нагрузку от запросов». Надо же, ну кто бы мог подумать что надо индексы правильно расставлять. Хотя любой юниор-ДБАшник первым делом тыкнёт пальцем в «table full scan» и заголосит «да вы же, вы же в индексы не попадаете, ироды!».

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

База точно так же профилируется, собираются статистики и вполне удаётся «вычислить» проблемные места. Вобщем, повторюсь, не в базах данных тут дело.

большинство смирилось что strong consistency в реалиях облаков практически нереальна, и согласились на eventual consistency.

Пока вы показываете количество лайков у товара — то все согласны, а потом «на складе одна единица товара, а купили его трое, причём все уже оплатили и деньги проведены по ERP» — и уже не согласны.

Надо же, ну кто бы мог подумать что надо индексы правильно расставлять.

и как уже написали, 10%-20% запросов написать в обход тяжелого ОРМа (Doctrine, Hibernate, Magentoовский, etc)

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

первым делом тыкнёт пальцем в «table full scan»

причем желательно делать это еще на этапе проектирования — а как в такой схеме будут выглядеть вот такие 3 типичных запроса? мы сможем их делать без full scan?

ну и конечно — за «тру ORM» присматривать
а то на раз SELECT N+1 сделает, и заметить не успеешь, как оно так получится.
то есть понимать что такое «объектно-реляционное рассогласование импедансов» и о чем древняя статья «Вьетнам компьютерной науки»

База точно так же профилируется, собираются статистики и вполне удаётся «вычислить» проблемные места.

Да — для этого у нас когда-то на проекте было 3 ДБА (2 у нас и 1 у клиента), которые 24 часа (по 8 часов каждый) мониторили базу и разруливали затыки!
Это только в теории можно один раз настроить индексы — и все будет хорошо. На практике очень часто в течении дня приходилось руками сбрасывать план запроса или даже отключать индексы, когда какой-то клиент срочно захотел залить в базу 100500 новых продуктов. А дежурить на базе в какой-нибудь Black Friday — это было как запускать ракету в космос!
И что сейчас? Как только ушли от огромных монолитных баз — так и ДБА стали не нужны!
Вывод: если какая-то технология требует сложного тюнинга и «танцев с бубном» что бы работать хорошо и быстро — то вместо искать «шаманов» что бы с ней работать — лучше просто ее выбросить и заменить на что-то нормальное!

Пока вы показываете количество лайков у товара — то все согласны, а потом «на складе одна единица товара, а купили его трое, причём все уже оплатили и деньги проведены по ERP» — и уже не согласны.

Но в итоге все-равно оказывается что бизнесу дешевле разрулить пару раз в день проблему с нехваткой товара, чем платить ДБА за постоянный мониторинг базы и разруливание дедлоков. Тем более что при использовании «грязного чтения» СУБД все равно не защищает от описанной проблемы. А NOLOCK я видел на 90% проектов, которые используют СУБД. Просто потому что с транзакциями «по честному» база перестает шевелиться очень скоро.

то вместо искать «шаманов» что бы с ней работать — лучше просто ее выбросить и заменить на что-то нормальное!

то есть когда борются с GC — надо его выбросить, и перейти на системы без GC?

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

да ну :) не, наверное и так бывает.
но обычно вой будет стоять не слабый, если система постоянно продает несуществующий товар.

Это только в теории можно один раз настроить индексы — и все будет хорошо.

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

Просто потому что с транзакциями «по честному» база перестает шевелиться очень скоро.

потому что когда бекендеры — нубы в SQL, они используют транзакции как постучать по дереву и сплюнуть через левое плечо.
или, так сама коробочная система написана. А они, «коробочные ERP» обычно так и написаны — с крайне неэффективной работой с РСУБД, потому что авторам требуется создать удобства разработчикам, а не эффективность работы в проде.

Как только ушли от огромных монолитных баз — так и ДБА стали не нужны!

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

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

то есть когда борются с GC — надо его выбросить, и перейти на системы без GC?

Если GC — это Garbage Сollection то где-то так и есть. Если в программе «борются с GC» — то ее пора выбросить. В нормальных условиях GC работает «прозрачно» и не требует «пинков» от девелопера. Если с ним проблемы то:
1) Код написал жопорукими индусами, которые, например в каждой строке ставят ToList, создают массивы в цикле или засирают хип другими способами. Тут не с GC нужно бороться!
2) Логика программы действительно требует сложной работы с памятью. Тут еже имеет смысл подумать от других инструментах: от stackallock до unsafe кода с указателями или вообще модуля на Managed C++.
Мое мнение такое: если с чем-то приходится бороться — то проблема именно в этом и нужно искать другое решение, которое не требует борьбы.

если система постоянно продает несуществующий товар.

В современных реалиях избежать этого просто невозможно! Представьте что у вас всемирный магазин: это куча дата-центров в облаке, даже сигнал с другого конца Земли доходит не моментально. Осталась 1 единица товара: как можно гарантировать что два пользователя не закажут ее одновременно?!
Ну разве что когда любой пользователь заказал товар блокировать всех остальных секунд на 10 что бы успеть все синхронизировать. Но такой перфоманс просто заставит пользователей идти на другие магазины, где не надо ждать!
Поэтому коллизии неизбежны — они существуют даже на уровне сетевых пакетов! Если что-то пошло не так — то есть механизмы компенсации. В конце-концов дешевле прислать подарок одному недовольному пользователю — чем надежная система, но тысячи пользователей недовольных скоростью.

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

Собственно все технологии ИТ как раз об этом: как бороться со сложностью «съедая слона по кусочкам». «Держать сложность в одном месте» — по мне это звучит как 100% анти — патерн!

Если GC — это Garbage Сollection то где-то так и есть

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

Мое мнение такое: если с чем-то приходится бороться — то проблема именно в этом и нужно искать другое решение, которое не требует борьбы.

мое же мнение такое
серебрянной пули не существует.
бороться придется — везде.

В современных реалиях избежать этого просто невозможно!

есть тьма способов как этого избежать, как на уровне бизнес-процесса так и технологических

Представьте что у вас всемирный магазин:

сколько всемирных магазинов вы знаете?
какой процент составляют всемирные магазины среди общего числа магазинов?

Поэтому коллизии неизбежны

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

«Держать сложность в одном месте» — по мне это звучит как 100% анти — патерн!

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

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

Спасибо за конструктив, учитывая лимиты NDA и отсутсвие опыта в написании статей получилось и правда без контекста и интро, пролог бы мог помочь не меньше чем выводы, учту и если найдется минута добавлю

Ошибка была только одна — отсутствие SLO «Black Friday» и бюджета на его имплементацию. И да — купить софт, настроть, запустить и терпеливо ждать даунтайма — это не SLO.
Лично я бы решил вопрос крайне просто — взял бы 1% самых лояльных клиентов и выслал бы им «супер-пупер-скидка до пятницы», чтоб они выступили в качестве тестеров. Их метрики намного ценнее той скидки, которую им можно дать, а результаты сразу бы показали проблемные точки.
Так что это — проблема уровня CTO, а те семь ошибок — симптоматика.

Идея хорошая, стыдно (наверное) признать что не слышал ранее о SLO,
спасибо за констуктив и новую абривиатуру для изучения

Буду благодарен если посоветуете интересную книгу / ресурс где это описано достаточно просто и емко

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

С кем поведёшься :)
Просто я ещё из того поколения, которое мало получало, работая в IT, особенно весьма далековато от Киева. Потому, просил ещё и долю малую от проданного. Отсюда и знаю, как эту долю извлекать из хомосапиенсов, и вообще в теме такой работы, и съедал по собаке в неделю.

IT в принципе гуманитарная наука, как только шаг вправо-влево от CRUD c формочками. И это ты ещё про корпоративную логику не спросил, там всё куда серьёзнее, потому что уже время людей стоит денег и надо эти траты радикально сокращать, перенося все прелести женской логики в код.

Ой, он будет нам сказать за кровавые энтерпрайзы

Меня зовут Влад Опухлый

Мабуть важко було в школі.

Важко буде дружині :)

Помилка 0
>Если мы покупаем дорогой и популярный third-party модуль, это ещё не значит, что он будет работать идеально и быстро
— Купувати код, який може компроментувати 800к кастомерів?

Помилка 1
>AWS
— ДБ під реальним навантаженням не на baremetal

Помилка 2
>добавление индекса помогло убрать бешеную нагрузку от запросов
— В залежності від СУБД, навантаження і даних в таблиці таке могло покласти СУБД на деякий не дуже малий час

Помилка 3
>в базе данных создаются сессии
— memcached, redis, any in memory DB

Помилка 4
>Это был очередной сюрприз, о которым нас не оповестили.
— Відсутність моніторингу розсилок?
— Робітники клієнта не можуть бути навчені?
— Відсутність персони, яка відповідальна за взаємодію зі сторони клієнта?
— Відсутність єдиної панелі, в якій будуть ключові параметри, по яким клієнту, вам і девопсам буде ясно, що в системі є проблеми

Помилка 5
>После этого команда клиента решила, что нужно сделать ещё один сервер, не известив нас об изменениях в инфраструктуре
— Це третій зальот робітників клієнта і далі ще буде

Выводы и советы

Знайти нормального адміна на вашу СУБД
Знайти нормального пхпшніка, який буде писати «модулі»
Розробити сценарій, коли додавання серверів вирішить проблему з навантаженням
Продивитись логи і створити load tests для тестування сценарію
Створити маркетинговий привід, знизити кількість серверів і протестувати сценарій вживу
Протестувати СУБД на baremetal в ДЦ поблизу ДЦ з aws

MySQL Tuner

Оригінальний наче був на перлі
Останнє оновлення 2015 і сайт зараз продає зброю (kek)

Оригінальний наче був на перлі
Останнє оновлення 2015 і сайт зараз продає зброю (kek)

mysqltuner.pl — жив курилка!!!

www.howtoforge.com/...​rformance-with-mysqltuner

wget http://mysqltuner.com/mysqltuner.pl

github.com/...​L Tuner&type=Repositories

pmachapman/mysqltuner
zeryl/MySQLTuner-PHP
rytis/MySQL-performance-tuner

¯\_(ツ)_/¯ qwant підвів мене
В гуглі перший лінк на коректний проект

Спасибо, что поделились. Всегда полезно учится на ошибках других. Не знаю, был ли в команде ДБА, но, думаю, многие проблемы с запросами можно было попытаться выявить заранее. А MySQL tuner может как помочь, так и поломать.

Спасибо, увы DBA не было (был клиентский IT Department без строго описаных ролей) но в целом выделение ролей и их наличие уменьшыло бы вероятность проблем.

MySQL tuner может как помочь, так и поломать

Это да, в целом все что с него получили проверяли и смотрели на динамику работы по к-ву сессий и загрузке DB инстанса, не все помогало сразу)

Вот для этих целей и нужен фриланс. Имейте хорошо знакомого вам удалёнщика, который почасово всё починит. Только хоть сколько-либо крупные заказы надо квантовать не в часах, а в днях — так и договориться проще, и не будет ничего под ковёр заметать, считая что время у него есть. А выгода от его работы превышает цену на порядок. Вот только решение, где надо работать, а где не надо — принять адекватно может только он сам, вот и приходится делать психологический трюк, провоцируя работать больше по «мелочам», но не лезть в крупные подвижки без доказательства их необходимости или выгоды (с оценкой рисков).

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

Согласен в чем то, но энтерпрайс боится фриланс (иначе бы аутстаф/аутсор вымер)

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

Собственно, это не совсем фриланс, это скорее постоянный найм, но на неполное время. Львиная доля фриланса именно такая, аутстафная по своей природе.

Подписаться на комментарии