Встановлення Saleor: де ламається самостійне розгортання
Встановлення Saleor своїми силами виглядає як звичайний деплой Django-проєкту: підняти застосунок, застосувати міграції, підключити базу й кеш. Ламається все зазвичай не на цьому кроці, а на стиках — коли магазин починає працювати під реальним трафіком і із зовнішніми системами.
Перший шар збоїв — каталог. Товари, варіанти та залишки приходять з облікової системи, а картки правлять ще й в адмінці: без однозначного власника даних кожна синхронізація затирає чуже редагування.
На вітрині з'являються позиції з нульовим залишком і старою ціною, а розбіжність між вітриною та оформленням замовлення спливає вже в момент оплати.
Другий шар — кошик і замовлення. Якщо оформлення проходить через кілька кроків без єдиної транзакції та без резервування залишку, на піковому навантаженні в день розпродажу частина кошиків губиться, а замовлення дублюються.
Клієнт бачить одне списання, склад — дві заявки, і розбір займає день, а не хвилини. Цілісність каталогу та замовлень тримається не на повторних спробах, а на ідемпотентних операціях і явних блокуваннях залишку.
Третій шар — інтеграції: оплата, доставка, склад, розсилки.
На піку вони отримують у рази більше запитів, і без черг з обмеженням паралелізму фонові завдання накопичуються, повідомлення від зовнішніх систем губляться, а статуси замовлень перестають збігатися з фактичним відвантаженням. Нижче розбираємо, як це закривається під час розгортання ecommerce-платформи.
Гнучка схема каталогу та замовлень: що дає налаштування
Картка товару — не один запис, а набір варіантів: колір, розмір, комплектація, у кожного свій залишок і ціна. Коректна модель даних каталогу пов'язує варіанти, склади й канали продажів явно, тому вітрина віддає лише те, що доступно в потрібному каналі.
У Saleor ця схема закладена штатно, але потребує налаштування — інакше з'являються дублі товарів і розбіжність між вітриною та складом.
Каталог, варіанти та склади
Атрибути описуємо типізованими полями, а не вільним текстом: фільтри та добірки будуються за індексами, а не перебором. Категорії вибудовуємо деревом із передбачуваною глибиною, щоб видача за розділом не підтягувала каталог цілком.
Резерв відділяємо від фактичного залишку: поки замовлення не підтверджено, товар залишається доступним іншим покупцям, а склад не показує «мінус».
Вітринний шар і пікові навантаження
Вітринний шар збирає сторінку каталогу підготовленими вибірками замість каскаду запитів: час відгуку сягає часток секунди замість секунд і не зростає з глибиною каталогу.
Пропускну здатність у пік перевіряємо прогонами на реальному профілі — розпродаж, рекламна кампанія, сезонний сплеск — і доводимо до стану, коли вітрина тримає потік без черги.
Оформлення замовлення проходить однією операцією: списання залишку, створення замовлення й запис історії статусів не розходяться між собою. Повторне надсилання форми не створює другого замовлення, а обрив на кроці оплати не залишає заморожений резерв. Зникає клас відмов: «продали те, чого немає» і «замовлення є, а позицій немає».
Режими розгортання: порівняння варіантів
Вибір варіанта розгортання визначає, як швидко виходить оновлення Saleor, наскільки передбачувано застосунок переживе зростання каталогу і хто відповідає за доступ до даних. Нижче — три схеми, між якими реально обирають на старті.
| Варіант | Коли підходить | Обмеження варіанта |
|---|---|---|
| Розміщення на своєму контурі | Вимоги тримати дані й доступи всередині своєї інфраструктури, є свій відділ експлуатації, нестандартна мережева схема | Оновлення й масштабування виконуються вручну, міграції бази плануються як окрема операція з простоєм або перемиканням реплік |
| Контейнерна схема | Потрібні регулярні релізи, горизонтальне масштабування вітрини та фонових завдань, середовище розробки повторює робочий контур | Без збору метрик і логів зростає час розбору збоїв, потрібна інфраструктурна команда та регламент викочування |
| Керована платформа | Швидкий запуск, невелика команда, немає задачі тримати інженера експлуатації | Частина параметрів недоступна, оновлення й міграції прив'язані до регламенту майданчика, глибина налаштувань шарів обмежена |
Що змінюється під час масштабування
У контейнерній схемі шар застосунку не зберігає стан, тому вітрина масштабується репліками, а черга фонових завдань виноситься окремо й зростає незалежно.
GraphQL-запити кешуються, важкі вибірки каталогу йдуть на репліки бази — кошик і оформлення замовлення залишаються на основному вузлі.
Перехід між варіантами виконується перенесенням дампа бази та медіафайлів, тому вибрана схема не замикає вас: розбираємо, який контур закриває ваші обмеження щодо доступів і навантаження.
Порядок встановлення Saleor: від аудиту до передачі
Порядок робіт вибудувано так, щоб кожен крок спирався на результат попереднього: спочатку фіксуємо фактичний стан контуру, потім проєктуємо схему і лише після цього торкаємося робочого контуру. Нижче — етапи впровадження в тому вигляді, у якому вони йдуть на проєктах із живим трафіком.
- Обстеження інфраструктури. Фіксуємо поточну картину: розміщення сервісів, будову баз, ліміти серверів, інструменти, які використовує команда. На виході — звіт із вузькими місцями, які безпосередньо впливають на схему розгортання.
- Проєктування схеми. Визначаємо склад компонентів Saleor, схему зберігання даних, ролі сервісів, точки інтеграції з обліковою системою та оплатою. Топологію узгоджуємо до початку робіт.
- Розділення середовищ. Піднімаємо окремі контури для розробки, приймання та експлуатації — зі своїми базами, ключами й конфігурацією. Оновлення обкатуються на копії даних і не зачіпають покупців.
- Встановлення та налаштування. Розгортаємо застосунок, черги фонових завдань, пошуковий індекс і кеш, налаштовуємо міграції та резервне копіювання — спочатку на тестовому контурі.
- Навантажувальна перевірка. Моделюємо реальні сценарії: перегляд каталогу, кошик, оформлення замовлення, вивантаження. Дивимося час відгуку під піком і поведінку системи в разі відмови окремого вузла.
- Передача проєкту. Віддаємо доступи й документацію щодо розгортання та відновлення, навчаємо команду, фіксуємо регламент оновлень і залишаємося на супроводі.
Склад постачання: конфігурації, схеми та регламенти
Постачання — це не архів із кодом, а набір артефактів, за якими систему можна експлуатувати й розвивати без автора. Усе, що налаштовується під час встановлення Saleor, фіксується в репозиторії та документації: конфігурації, схеми, політики й регламенти переходять замовнику.
- Конфігурації проєкту — файли середовищ для розробки, тестового та робочого контурів, змінні підключення до бази й черги, секрети винесено окремо.
- Схема інтеграцій — карта зв'язків із платежами, доставкою, складом і обліковою системою: напрямок обміну, формат даних, поведінка в разі недоступності зовнішньої сторони. Окремо описано програмний інтерфейс, за яким підключаються вітрина та мобільний застосунок.
- Політики доступу — ролі та права на замовлення, каталог і ціни; обмеження на вхід до адмінки та службові методи.
- Схема даних і міграції — структура каталогу (товари, варіанти, колекції, склади), правила наповнення та порядок перенесення з попередньої системи.
- Регламент оновлень — періодичність оновлення платформи та залежностей, перевірка на тестовому контурі, точки відкату.
- Моніторинг і журнали — зібрані метрики, аварійні пороги, маршрут оповіщень.
- Документація та чек-ліст приймання — інструкції для адміністраторів і розробників, сценарії перевірки перед викладкою.
Такий склад знімає залежність від підрядника: новий інженер входить у систему за схемами та регламентами, а не за пам'яттю попередньої команди.
Кейс: перенесення каталогу без зупинки продажів
Магазин на старій платформі тримав каталог на 40+ тисяч позицій, а синхронізація залишків ішла пакетно й блокувала вітрину: вивантаження займало до 40 хвилин, у цей час картки не відкривалися, а частину замовлень менеджери оформлювали вручну.
Розбіжності залишків і цін сягали 8% позицій — підтримка розбирала їх щодня, замість того щоб займатися покупцями.
Перенесення зробили без зупинки продажів. Новий контур на Saleor піднімали паралельно робочому: каталог та історія замовлень виїжджали пакетами на запис, старий магазин продовжував приймати замовлення.
Поки тривало завантаження, зустрічні зміни доїжджали додатково, а ключі ідемпотентності не давали дублям потрапити до каталогу.
Що змінилося
Перемикання вітрини минуло без простою: покупці не побачили ні сторінки обслуговування, ні помилок оформлення, а повернутися на старий контур у разі відхилення можна було однією командою.
Час відгуку каталогу на важких фільтрах скоротився майже втричі — індекс і кеш перезбираються у фоні, а не на кожен запит.
Метрики після
- Простій магазину: нуль замість планових кількох годин.
- Вивантаження каталогу: з 40 хвилин до одиниць хвилин, вітрина залишається доступною.
- Звернення до підтримки щодо «товару немає / ціна не та»: менше вчетверо.
- Розбіжності залишків: з 8% позицій до часток відсотка.
Звільнений час підтримки пішов на консультації та роботу з оптовими клієнтами, а не на розбір розбіжностей. Підключення нового каналу продажів тепер не потребує окремого вивантаження — каталог надходить з одного джерела.
Чим відрізняється розгортання з нуля від перенесення магазину?
Розгортання з нуля — чиста інсталяція Saleor: схему каталогу проєктуємо під завдання, а не успадковуємо від попередньої платформи. Атрибути, варіанти товару, склади й правила цін задаються відразу в потрібній моделі, інтеграції підключаються до порожньої бази. Обсяг робіт — налаштування та перевірка сценаріїв, а не перенесення.
Перенесення магазину — зворотна задача: зберегти працюючий бізнес у момент зміни платформи. Переносимо каталог, категорії, атрибути, залишки, історію замовлень і користувачів.
Головна складність — невідповідність схеми каталогу: те, що на попередній платформі було однією сутністю, тут розкладається на кілька й потребує явного перетворення.
Міграція даних іде через аудит: що переносимо як є, що перезбираємо, а що не беремо. Вивантаження йде в нейтральний формат, завантаження — з перевіркою збіжності: число позицій, залишки, ціни та прив'язка замовлень мають збігтися до і після. Розбіжності шукаємо на тестовому контурі, а не на бойовій базі.
Сумісність інтеграцій — другий великий ризик переїзду. Платіжні шлюзи, служби доставки, склад і бухгалтерія обмінюються даними за своїми контрактами: частина підключається штатними засобами, частина потребує доопрацювання. Старі адреси карток і категорій переводимо на нові постійними перенаправленнями.
Звідси висновок: розгортання з нуля передбачуване за термінами, переїзд — етапи та план відкату. За невеликого каталогу та малої кількості зв'язків швидше чиста інсталяція з повторним завантаженням даних.
Обмеження платформи та часті технічні питання
Платформа закриває каталог, кошик і оформлення з коробки, але межі в неї є — їх краще знати до запуску. Нижче — сумніви, які найчастіше звучать на оцінці, і те, як ми знімаємо їх на рівні архітектури.
Де межа каталогу і як вітрина поводиться на піку?
Обмеження задає не число товарів, а індексація та кеш: десятки тисяч позицій із фасетними фільтрами йдуть в окремий пошуковий шар. Запити обмежені за глибиною та вартістю, щоб важкий виклик не займав обробник, а застосунок масштабується горизонтально. Кошик і оформлення залишаються швидкими під час акції.
Як стикується склад і облікова система?
Залишки, ціни та статуси замовлень ходять через API — за розкладом і за подіями. Пріоритет джерела фіксуємо заздалегідь: склад диктує залишок, магазин — ціну, а розбіжності потрапляють до журналу й не перетворюються на продаж відсутнього товару.
Що з платежами та безпекою?
Шлюз підключається конфігурацією, оплата йде з підтвердженням за 3-D Secure. Карткові дані не проходять через застосунок — використовується токенізація на боці провайдера, тому контур аудиту залишається вузьким, а платіжний провайдер змінюється без переписування вітрини.
У якому порядку виходять оновлення платформи?
Нову мажорну гілку ми не викладаємо в день релізу: спочатку проміжний стенд, прогін сценаріїв замовлення та міграції даних, потім викладка з можливістю відкату. Оновлення йдуть пакетами.
Обговоримо завдання: що потрібно для оцінки та старту
Щоб обговорити завдання предметно й повернутися з оцінкою проєкту, а не із загальними словами, нам потрібні межі робіт. Нижче — мінімальний набір вихідних даних. Якщо чогось поки немає — не критично: частину уточнимо на дзвінку, частину зберемо самі під час розбору.
- Каталог: скільки товарів і категорій, які атрибути та варіанти (розміри, опції), звідки переносимо дані.
- Модель продажів: одна вітрина чи кілька, мови та валюти, чи потрібні різні склади й правила доставки.
- Оплата й логістика: які платіжні провайдери та служби доставки підключаємо, чи є нестандартні сценарії на кшталт часткової оплати або самовивозу.
- Інтеграції: ERP, склад, CRM, аналітика — що і в який бік має обмінюватися даними з Saleor.
- Навантаження: очікуваний трафік у пік, число одночасних покупців, вимоги до часу відгуку каталогу й оформлення замовлення.
- Інфраструктура: де розміщуємо проєкт, який контур є зараз, хто відповідає за доступи, домени й сертифікати.
- Обмеження: дата запуску, зобов'язання перед партнерами, що вже готово щодо контенту та макетів.
На основі цього команда інженерів фіксує обсяг, розбиває його на етапи й віддає план робіт і терміни з явними припущеннями та точками узгодження. Опишіть завдання у зручному вигляді — повернемося з оцінкою та планом.
