Стейджинг і безпечні викладки: як оновлювати живий сайт, не ламаючи його

Більшість сайтів малого бізнесу правлять прямо на продакшені. Хтось змінює налаштування, оновлює плагін, підправляє шаблон — і дізнається, чи спрацювало, подивившись на живий сайт. Здебільшого це працює, саме тому так і живе, а ті рази, коли не спрацювало, коштують непропорційно дорого відносно самої зміни.

Видимий симптом — не простої. Це страх. Команди, які правлять продакшен, перестають оновлюватися, бо кожне оновлення стає публічною ставкою, а сайт, який перестали оновлювати, перетворюється на ту саму проблему безпеки, про яку пишуть у кожній другій статті про WordPress. Стейджинг — не розкіш для розробників; це те, що робить рутинне обслуговування достатньо безпечним, щоб воно взагалі відбувалося.

Для чого потрібні середовища

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

Що робить стейджинг корисним, а що — пасткою

Стейджинг, який відрізняється від продакшену так, що ніхто цього не відстежував, пройде тест, який продакшен потім провалить. Чотири властивості вирішують, чи каже він вам правду.

• Ті самі версії. PHP, база даних, вебсервер, плагіни, тема. Зміна, протестована на PHP 8.3 і викладена на PHP 8.1, не протестована.
• Реалістичні дані. Стейджинг із дванадцятьма товарами не покаже запит, який виконується девʼять секунд на чотирьох тисячах. Оновлюйте копію з продакшену регулярно й знеособлюйте персональні дані при цьому, бо копія бази клієнтів на слабко захищеному сервері — це витік, який чекає, щоб про нього повідомили.
• Ізоляція від зовнішнього світу. Три конкретні ізоляції, кожна з яких когось уже зганьбила: жодної вихідної пошти на реальні адреси, платіжні шлюзи в тестовому режимі й вимкнені теги аналітики та реклами.
• Невидимість для пошукових систем. Проіндексований стейджинг конкурує зі справжнім сайтом і подекуди його обганяє. Парольний захист на рівні сервера надійніший за директиву в robots, бо директива — це прохання, а пароль — ні.

Найпоширеніший збій — жоден із цих. Це застарілість: стейджинг, оновлений один раз вісімнадцять місяців тому, у якого з продакшеном спільна хіба що назва теми. Тестування проти нього дає впевненість без інформації.

Що саме викладається

Викладка на WordPress складніша, ніж звучить, бо сайт — це чотири різні речі, і рухаються вони в різні боки.

1. Код. Тема й власні плагіни. Їде зі стейджингу в продакшен і має жити в системі контролю версій, щоб викладене було відомим станом, а не тим, що лежало на сервері.
2. Контент. Сторінки, записи, товари, медіа. Їде з продакшену на стейджинг, бо справжній контент створюють у продакшені.
3. Конфігурація. Налаштування, опції, меню, визначення форм. Живе в базі поруч із контентом — тому вона й незручна.
4. Сторонні плагіни. Оновлюються на місці й є головною причиною, з якої викладка взагалі буває терміновою.

Третій пункт і ламає більшість саморобних процесів. Оскільки налаштування й контент ділять базу, копіювання бази зі стейджингу перезаписує реальні замовлення й реальні заявки, а копіювання з продакшену стирає ту зміну конфігурації, яку ви щойно перевірили. Елегантної відповіді на малому масштабі немає. Робоча — вносити зміни конфігурації двічі й свідомо: один раз на стейджингу для перевірки, один раз на продакшені для застосування, із письмовою нотаткою, що саме змінено. Звучить примітивно й запобігає найпоширенішій категорії самозаподіяної втрати даних.

Відкат: питання, яке ставлять до викладки, а не після

Кожна викладка потребує відповіді на «що робимо, якщо це неправильно», ухваленої заздалегідь і такої, що займає хвилини, а не години.

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

Знімок перед викладкою — найдешевша доступна страховка, і робиться він близько хвилини. Він же напряму повʼязаний із ширшим питанням, чи працює ваше відновлення взагалі, — це тема навчального відновлення: відкат є відновленням під тиском часу, і якщо відновлення ніколи не тестували, то й відкат теж.

Коли викладати, якщо в команді немає відділу експлуатації

Класична порада — не викладати в пʼятницю. Справжній принцип — не викладати тоді, коли нікому лагодити, а для більшості малих бізнесів це означає уникати кінця дня й дня перед чиєюсь відпусткою.

Три звички дають більше за будь-який графік.

• Викладайте мало й часто. Реліз з однією зміною діагностується за секунди. Реліз із чотирнадцяти змін, накопичених за два місяці, бо викладки здаються ризикованими, і є справді ризикованим.
• Відділяйте патчі безпеки від функціональних змін. Критичне виправлення плагіна не має чекати на готовність редизайну, а вікно експлуатації розкритих вразливостей вимірюється годинами, а не спринтами.
• Записуйте, що змінилося. Один рядок на викладку з датою. Коли за тиждень щось зламається, цей файл відповість на питання, яке інакше забере пів дня.

Мінімальний процес для бізнесу без розробників

Більшість читачів не має конвеєра й не збирається його будувати. Ця версія не потребує нічого, крім того, що вже дає хостинг.

1. Оновіть стейджинг із продакшену перед початком, щоб тестувати проти поточної реальності.
2. Внесіть зміну на стейджингу й запишіть одним реченням, що саме зробили.
3. Перевірте пʼять речей, які ламаються найчастіше: головну, сторінку послуги чи товару, реальне надсилання контактної форми, чекаут, якщо він є, і сайт на телефоні.
4. Зробіть знімок продакшену, потім застосуйте ту саму зміну там.
5. Перевірте ті самі пʼять речей на продакшені — самі, а не за припущенням.

Двадцять хвилин, і оновлення перетворюється з події на рутину. Сенс рутини не в бездоганності, а в тому, що збій ловите ви у вівторок уранці, а не клієнт у суботу ввечері.

Що перевіряти після кожної викладки

Короткий список перевірок кращий за довгий, бо довгий не виконують. Пʼять пунктів покривають переважну більшість післявикладкових інцидентів.

Чи відкривається сайт, включно зі сторінкою, яка не є головною. Чи проходить основний конверсійний шлях: форма надіслана й отримана або замовлення оформлене. Чи виходить пошта із сервера й доходить — це окреме від того, що форма показала успіх. Чи спрацьовують теги аналітики, бо втрачений тег невидимий тижнями, а потім породжує загадку у звітах. І чи не просіла швидкість, бо оновлення плагіна, яке додало двісті кілобайтів JavaScript, зʼявиться в польових даних задовго до того, як хтось повʼяже це з релізом.

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

Як отримати стейджинг, не змінюючи хостинг

Заперечення зазвичай у вартості, і зазвичай воно помилкове. Шляхів три, і лише один із них передбачає доплату.

• У хостера це вже є. Більшість керованих WordPress-провайдерів включає стейджинг в один клік, про який у компанії ніхто не знає. Перевірте панель, перш ніж щось купувати.
• Піддомен на тому самому акаунті. Безкоштовно, достатньо для більшості тестів і вимагає дисципліни: пароль на рівні сервера, вимкнена пошта й нагадування в календарі оновити копію. Слабкість у тому, що сервер спільний, тож перевірити щось про сам сервер не вийде.
• Локальна копія. Безкоштовні інструменти піднімають повне середовище WordPress на ноутбуці хвилин за десять. Найкраща ізоляція, найгірша реалістичність і правильна відповідь для перевірки оновлення плагіна на сайті з невеликими даними.

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

Кому дозволено викладати

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

Це належить домовленості про підтримку, а не чиїйсь памʼяті — поруч із часом реакції й інтервалом патчингу, описаними в матеріалі про те, що має входити в план підтримки.

Три зміни, які не можна тестувати на стейджингу

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

• Усе, що залежить від обсягу. Кешування, черги, фонові завдання й запити до бази поводяться інакше під реальним трафіком. Стейджинг покаже, що функція працює, і не покаже, що вона працює для тисячі людей одночасно.
• Зміни в DNS і сертифікатах. Їх у принципі не можна відрепетирувати: перемикання відбувається один раз і одразу в бойових умовах. Тут рятує не тест, а короткий TTL, виставлений за добу до зміни, і наперед підготований відкат.
• Інтеграції з бойовими ключами. Платіжні шлюзи, бухгалтерія, склад. Тестовий режим перевіряє формат обміну, а не поведінку реальної системи під реальним замовленням. Перше бойове замовлення після такої зміни варто зробити самому й одразу.

Практичний висновок простий: для цих трьох категорій планом є не тестування, а спостереження одразу після зміни й готовність відкотити. Знання, чого стейджинг не покриває, важить не менше за сам стейджинг.

Коротко

Правка продакшену зазвичай працює, і ціна цього — не простої, а страх, через який оновлення перестають робити взагалі. Двох середовищ достатньо: стейджинг і продакшен, у який пише лише викладка. Стейджинг корисний лише тоді, коли збігаються версії, дані реалістичні й знеособлені, він ізольований від справжньої пошти, платежів і аналітики й невидимий для пошукових систем; звичний збій у тому, що він застарів на півтора року. Викладка на WordPress незручна, бо код їде вгору, контент — униз, а конфігурація живе разом із контентом, тож вносьте зміни конфігурації свідомо в обох місцях, а не копіюйте бази. Вирішуйте відкат до викладки й робіть знімок безпосередньо перед нею, бо нічний бекап — це кілька годин втрачених замовлень. Викладайте мало й часто, відділяйте патчі безпеки від функціональних змін, пишіть рядок на реліз і перевіряйте пʼять речей після — самостійно.