WordPress застряг у режимі обслуговування: як безпечно видалити та запобігти повторенням

Повідомлення WordPress «Briefly unavailable for scheduled maintenance» — це програмний еквівалент того, коли швейцар виходить покурити і зачиняє будинок ззовні.

Іноді воно зникає за секунди. Інші рази банер висить годинами, бо оновлення перервалося, PHP вийшов за межі часу виконання, диск заповнився або модель прав доступу «закрили настільки, що нічого не працює». Гарна новина: виправлення зазвичай просте. Погана новина: можна зробити гірше, якщо ставитися до цього як до швидкої правки.

Що таке режим обслуговування насправді (і чого він не є)

Режим обслуговування WordPress не є «режимом» в якомусь складному сенсі. Це файл. Конкретно — файл з іменем .maintenance у кореневій теці WordPress. Під час оновлень ядра/плагінів/тем WordPress створює цей файл як прапорець і перевіряє його при кожному запиті. Якщо файл існує і його мітка часу «свіжа», WordPress показує повідомлення про обслуговування і припиняє подальшу обробку.

Така простота — одночасно перевага й пастка. Якщо оновлення завершилося нормально, WordPress видаляє файл. Якщо оновлення перервалося — таймаут, фатальна помилка, вбите PHP-процес, проблема з правами, закінчення диску тощо — файл може залишитися. І ваш сайт буде «коротко недоступний» стільки, скільки ваш бізнес може терпіти несподівану сороміцьку паузу.

Режим обслуговування також часто плутають з:

• CDN або зворотний проксі, що кешує сторінку обслуговування довше, ніж файл існує.
• функцією «режим обслуговування» плагіна, що не має відношення до базового механізму .maintenance.
• зламаним оновленням, коли сайт дійсно впав (фатальні помилки), а банер був лише першим симптомом, який ви помітили.

Операційно ставтеся до режиму обслуговування як до lock-файлу. Ваше завдання — відповісти на два питання перед тим, як видаляти його: (1) чи оновлення все ще виконується, і (2) чи воно завершилося з помилкою, що лишила систему в неконсистентному стані?

Швидкий план діагностики (перший/другий/третій)

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

Перший крок: підтвердьте, що бачать користувачі

1. Отримайте заголовки та вміст з origin (обійдіть CDN, якщо можете). Якщо ви бачите HTML обслуговування від origin, це реальна проблема. Якщо тільки CDN показує банер — це кеш.
2. Перевірте існування .maintenance і його мітку часу. Якщо він давній — майже напевно застарілий.

Другий крок: вирішіть, чи оновлення ще виконується

1. Пошукайте активні PHP-процеси, що їдять CPU/час, і перевірте логи вебсерверу на довготривалі запити до update.php або admin-ajax.php.
2. Перевірте стан оновлень WordPress за допомогою WP-CLI, якщо він доступний.

Третій крок: перевірте, що сайт не впаде після видалення файлу

1. Перевірте вільне місце на диску (оновлення записують багато дрібних файлів і розпаковують архіви).
2. Перевірте власника/права файлів для wp-content та директорій ядра.
3. Пошукайте артефакти неповних оновлень, наприклад у wp-content/upgrade та частково розпаковані каталоги плагінів.

Ось і все. Не починайте випадково видаляти каталоги плагінів, ніби граєте в «лупцювання крота» з файловою системою.

Безпечне зняття режиму: дисциплінований підхід

Так, загальна порада — «видаліть .maintenance». Іноді цього достатньо. Але у продуктивному середовищі «достатньо» — це шлях до простою довшого, ніж банер обслуговування.

Ось дисциплінований алгоритм, який я використовую на реальних системах:

1. З’ясуйте корінь WordPress (не гадати; на хостингах із розділеними середовищами легко помилитися).
2. Підтвердіть наявність файлу і перегляньте його. Він містить мітку часу і іноді підказує, яке оновлення його створило.
3. Перевірте, чи оновлення ще триває (список процесів, логи, стан WP-CLI).
4. Зробіть снапшот або резервну копію перед змінами, якщо у вас є можливість відкату (снапшот VM, ZFS snapshot, хостинг-бекап). Якщо відкату немає — будьте надзвичайно обережні.
5. Зніміть блокування, видаливши .maintenance тільки після того, як ви впевнені, що нічого активного не оновлюється.
6. Перевірте сайт (головну сторінку, wp-admin, сторінку для незалогіненого користувача, дію для залогіненого користувача).
7. Завершіть або повторіть оновлення коректно, щоб повернути систему в консистентний стан.

Коротка цитата, яку варто тримати в голові, коли хочеться «просто видалити файл і піти»:

«Надія — це не стратегія.» — приписують багатьом операційним лідерам; часто використовується в інженерії надійності

А тепер перейдемо до практичної роботи.

Практичні завдання: команди, виводи, рішення (12+)

Припущення для прикладів:

• Linux-хост з Nginx або Apache
• WordPress знаходиться в /var/www/html
• WP-CLI може бути встановлений або ні

Якщо ваші шляхи відрізняються, підлаштуйте їх. Не «змушуйте працювати» команди, копіюючи їх сліпо.

Завдання 1: Перевірте, що ви б’єте по origin (не по кешу)

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/ | sed -n '1,20p'
HTTP/2 503
date: Sat, 27 Dec 2025 10:18:02 GMT
content-type: text/html; charset=UTF-8
cache-control: no-cache, must-revalidate, max-age=0
server: nginx

Що це означає: 503 вказує, що обробник обслуговування (або щось вище) віддає помилку. Заголовок cache-control натякає на динамічну відповідь, але не робіть поспішних висновків.

Рішення: Якщо бачите заголовки від CDN (наприклад, via або специфічні заголовки CDN), протестуйте origin напряму (Host header до origin IP або внутрішня адреса LB). Якщо origin в порядку, а CDN — ні, маєте справу з кешуванням, а не з WordPress.

Завдання 2: Підтвердіть вміст сторінки обслуговування

cr0x@server:~$ curl -sS https://example.com/ | sed -n '1,5p'
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Briefly unavailable for scheduled maintenance. Check back in a minute.</title>

Що це означає: Це канонічне повідомлення WordPress про обслуговування.

Рішення: Продовжуйте перевірки файлової системи. Якщо вміст відрізняється, ви можете бачити сторінку плагіна-мейнтененсу, блок WAF або кастомну сторінку помилки.

Завдання 3: Знайдіть корінь WordPress (не гадати)

cr0x@server:~$ sudo find /var/www -maxdepth 4 -name wp-config.php -print
/var/www/html/wp-config.php

Що це означає: Тека, що містить wp-config.php, зазвичай є коренем WordPress.

Рішення: Використовуйте цю теку для подальших операцій. Якщо є кілька результатів, зіставте їх з віртуальними хостами перед змінами.

Завдання 4: Перевірте, чи існує .maintenance і наскільки він давній

cr0x@server:~$ cd /var/www/html && sudo ls -la .maintenance
-rw-r--r-- 1 www-data www-data 114 Dec 27 09:01 .maintenance

Що це означає: Файл існує, належить веб-користувачу. Мітка часу натякає, що він там уже довше, ніж «коротко».

Рішення: Якщо він старший за кілька хвилин і оновлення не виконується, ймовірно, він застарілий і безпечний для видалення після верифікації.

Завдання 5: Прочитайте файл .maintenance для контексту

cr0x@server:~$ sudo cat /var/www/html/.maintenance
<?php $upgrading = 1766826061; ?>

Що це означає: У ньому зберігається UNIX-таймштамп у $upgrading. WordPress використовує це, щоб вирішити, чи застосувати режим обслуговування.

Рішення: Перетворіть у людський час. Якщо він давній — ви не перервете активне оновлення, видаляючи його.

Завдання 6: Перетворіть таймштамп updating

cr0x@server:~$ date -d @1766826061
Sat Dec 27 09:01:01 UTC 2025

Що це означає: Обслуговування почалося о 09:01 UTC.

Рішення: Якщо зараз набагато пізніше — припускайте, що оновлення провалилося або було вбите.

Завдання 7: Пошукайте активні процеси оновлення (PHP-FPM / PHP)

cr0x@server:~$ ps aux | egrep 'php-fpm|php.*wp-admin|php.*update' | head
www-data  21314  0.0  0.6 373400 53324 ?        S    10:12   0:00 php-fpm: pool www
www-data  21315  0.0  0.6 373400 53288 ?        S    10:12   0:00 php-fpm: pool www

Що це означає: Ви бачите воркери PHP-FPM, але нічого, що явно вказує на «виконується оновлення». Це нормальна активність.

Рішення: Якщо бачите довготривалий PHP-процес, прив’язаний до endpoint оновлення, зачекайте або дослідіть логи перед тим, як видаляти lock.

Завдання 8: Перевірте логи вебсерверу на помилки оновлення

cr0x@server:~$ sudo tail -n 30 /var/log/nginx/error.log
2025/12/27 09:01:32 [error] 21001#21001: *188 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function ..." while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET /wp-admin/update.php?action=update-plugin&plugin=foo/bar.php HTTP/2.0"

Що це означає: Запит оновлення зіткнувся з фатальною помилкою під час виконання. Класичний шлях залишити .maintenance у системі.

Рішення: Очікуйте частково оновлений плагін/тему/ядро. Плануйте відновлення, перевстановивши пошкоджений компонент коректно після відновлення доступу.

Завдання 9: Перевірте місце на диску (оновлення мовчки падають при нестачі простору)

cr0x@server:~$ df -h /var/www/html
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        40G   39G  420M  99% /

Що це означає: 99% заповнення. Це не «трохи тісно», це «наступний запис зазнає поразки». Оновлення розпаковують архіви та створюють тимчасові файли; вони програють при такій ситуації.

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

Завдання 10: Перевірте робочу директорію upgrade

cr0x@server:~$ sudo ls -la /var/www/html/wp-content/upgrade
total 12
drwxr-xr-x  3 www-data www-data 4096 Dec 27 09:01 .
drwxr-xr-x 11 www-data www-data 4096 Dec 27 09:01 ..
drwx------  4 www-data www-data 4096 Dec 27 09:01 plugin-temp-ABcD12

Що це означає: WordPress використовує wp-content/upgrade для тимчасової розпаковки. Залишені каталоги можуть свідчити про перерване оновлення.

Рішення: Не видаляйте механічно. Спочатку відновіть доступ до сайту, потім почистіть після підтвердження того, що саме впало.

Завдання 11: Перевірте власника та права файлів (поширена помилка після «затвердження безпеки»)

cr0x@server:~$ sudo stat -c '%U:%G %a %n' /var/www/html/wp-content /var/www/html/wp-content/plugins
root:root 755 /var/www/html/wp-content
root:root 755 /var/www/html/wp-content/plugins

Що це означає: Належність root, а не веб-користувач. Якщо WordPress працює під www-data, він може не мати прав для запису оновлень, видалення .maintenance або створення тимчасових файлів.

Рішення: Виправте власника відповідно до моделі виконання (часто www-data:www-data на Debian/Ubuntu). Якщо використовуєте користувача деплою з груповими правами + setgid — робіть це свідомо; не імпровізуйте.

Завдання 12: Видаліть .maintenance (тільки після перевірок)

cr0x@server:~$ sudo rm -f /var/www/html/.maintenance && sudo ls -la /var/www/html/.maintenance
ls: cannot access '/var/www/html/.maintenance': No such file or directory

Що це означає: Файл блокування віддалено.

Рішення: Негайно протестуйте сайт від origin. Якщо він все ще показує повідомлення про обслуговування, маєте справу з кешуванням або іншим механізмом.

Завдання 13: Підтвердіть, що сайт повернувся (і чи він дійсно працює)

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/ | sed -n '1,10p'
HTTP/2 200
date: Sat, 27 Dec 2025 10:19:44 GMT
content-type: text/html; charset=UTF-8
server: nginx

Що це означає: HTTP 200. Банер обслуговування більше не віддається.

Рішення: Тепер перевірте wp-admin і логи. HTTP 200 може все ще повертати пошкоджену тему з сумним HTML-каркасом.

Завдання 14: Перевірте стан WordPress за допомогою WP-CLI (якщо доступний)

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp core version
6.4.3

Що це означає: WP-CLI працює і ядро читається. Добрий знак.

Рішення: Використовуйте WP-CLI, щоб коректно завершити оновлення, а не натискати кнопки в wp-admin під час інциденту.

Завдання 15: Подивіться, чи є очікувані або наполовину виконані оновлення

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp plugin status | sed -n '1,12p'
Plugin name  Status   Update  Version
akismet      active   none    5.3
foo-plugin   active   available 2.1.0
bar-plugin   inactive none    1.9

Що це означає: Принаймні одне оновлення плагіна доступне; можливо саме воно й впало.

Рішення: Якщо оновлення спричинило інцидент, оновлюйте контрольовано (WP-CLI, по одному плагіну), стежачи за логами та місцем на диску.

Завдання 16: Спробуйте контрольоване оновлення плагіна (по одному)

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp plugin update foo-plugin
Downloading update from https://downloads.wordpress.org/plugin/foo-plugin.2.1.0.zip...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.

Що це означає: Шлях оновлення працює end-to-end: завантаження, розпакування, заміна, очищення.

Рішення: Якщо це не вдається (права, диск, мережа), виправте базову причину перед повтором. Повторення невдалого оновлення породжує каталоги з напіврозпакованими плагінами і жаління совісті.

Завдання 17: Якщо wp-admin зламаний, швидко відключіть підозрілий плагін

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp plugin deactivate foo-plugin
Plugin 'foo-plugin' deactivated.

Що це означає: Ви видалили плагін з рантайму, не видаляючи файлів.

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

Завдання 18: Якщо немає WP-CLI, зробіть мінімальну перевірку файлової системи на наполовину інстальовані плагіни

cr0x@server:~$ sudo find /var/www/html/wp-content/plugins -maxdepth 2 -type f -name '*.php' | head
/var/www/html/wp-content/plugins/akismet/akismet.php
/var/www/html/wp-content/plugins/foo-plugin/foo-plugin.php
/var/www/html/wp-content/plugins/bar-plugin/bar.php

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

Рішення: Якщо плагін напіввстановлений — перевстановіть його з надійного джерела або відновіть з бекапу. Не «патчіть» випадковими файлами.

Чому це відбувається: реальні режими відмов

Застряглий режим обслуговування — це симптом. Хвороба зазвичай одна з наступних:

1) Перерване оновлення (таймаути, вбивання процесів, рестарти)

Оновлення WordPress — це послідовність записів: завантажити zip, розпакувати у тимчасову теку, замінити файли, виконати процедури оновлення, видалити .maintenance. Якщо PHP вийшов за ліміт часу, FPM рестартнувся, контейнер задеплоєний заново або хост перезавантажився в невдалий момент, прибирання може не відбутися. Сайт лишається заблокованим через наявний lock-файл.

Докази: логи з фаталами/таймаутами на update.php, залишки в wp-content/upgrade і таймштамп .maintenance, що співпадає з вікном останнього деплою/рестарту.

2) Диск заповнений (або вичерпані іноди)

Оновлення потребують багато записів. Не великі файли — багато дрібних. Майже заповнена файлова система викликає непередбачувані збої: розпакування архіву падає, тимчасові теки не створюються, і WordPress може не змогти видалити .maintenance, навіть якщо оновлення «майже» вдалося.

Докази: df -h понад 95%, помилки ENOSPC у логах, або вичерпані іноди на файлових системах з мільйонами дрібних файлів.

3) Невідповідні права / власник

Веб-процес має мати можливість записувати в певні шляхи під час оновлень. Деякі команди «затверджують права після аудиту безпеки», а потім забувають, що WordPress — не статичний генератор сайтів. Якщо wp-content належить root і недоступний для запису рантайму, WordPress може створити .maintenance в одному контексті користувача і не змогти видалити його пізніше.

Докази: stat показує невідповідність власників, помилки типу «Could not create directory» і інтерфейс оновлення просить FTP-креденціали (ознака того, що прямі файлові операції не доступні).

4) Шари кешування віддають застаріле maintenance

Ви видалили .maintenance, оновили сторінку — і банер досі є. Тоді згадуєте про CDN, зворотний проксі, object cache, плагін сторінкового кешу, кеш браузера і, можливо, edge worker «оптимізує» HTML. Будь-хто з них може кешувати 503 і продовжувати віддавати його.

Докази: origin повертає 200, а edge — 503; заголовки відрізняються між origin і edge; очищення кешу вирішує проблему миттєво.

5) Оновлення «успішно» завершилося, але рантайм зламаний

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

Докази: PHP fatal після видалення файлу, недоступність wp-admin і логи з відсутніми функціями/класами, пов’язаними з кодом плагіна/теми.

Короткий жарт #1: Режим обслуговування WordPress — це як записка на дверях «Повернусь за хвилину». Вона ніколи не означає одну хвилину.

Поширені помилки: симптом → причина → виправлення

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

Банер обслуговування лишається навіть після видалення .maintenance

• Симптом: .maintenance відсутній, але користувачі все ще бачать сторінку обслуговування.
• Причина: Закешована відповідь (CDN, зворотний проксі, плагін кешу) або ви видалили .maintenance не у тому корені сайту (неправильний docroot).
• Виправлення: Перевірте відповідь origin за допомогою curl, підтвердіть правильний docroot через конфіг vhost, при потребі очистіть кеш на краю.

Сайт повертає 500 після видалення .maintenance

• Симптом: Режим обслуговування зник, але тепер 500 або біла сторінка.
• Причина: Оновлення залишило плагін/тему напівоновленими; несумісна версія PHP; відсутнє розширення; пошкоджена карта автозавантаження.
• Виправлення: Перевірте логи помилок; відключіть підозрілі плагіни (WP-CLI або перейменування директорії); перевстановіть пошкоджений плагін/тему; підтвердіть вимоги до версії PHP/розширень.

Режим обслуговування повертається одразу після видалення

• Симптом: Видалили .maintenance, оновили сторінку — і файл з’явився знову.
• Причина: Процес оновлення ще працює (cron, автооновлення, інша сесія в wp-admin) і відтворює файл.
• Виправлення: Зупиніть активність оновлення (пауза pipeline, тимчасова відключення автооновлень, дослідження cron), потім видаліть файл, коли система стабільна.

Оновлення постійно падають і лишають .maintenance

• Симптом: Це патерн, а не поодинокий випадок. Кожне оновлення ризикує простоєм.
• Причина: Файлова система недоступна для запису рантайму; тиск диску; блокування вихідного трафіку до джерел оновлень; інструменти безпеки переписують права.
• Виправлення: Виправте модель виконання: узгоджений user/group, записувані шляхи оновлення, достатній резерв місця на диску, дозволити вихідні з’єднання до джерел, припинити «жонглювання chmod» у цілях безпеки.

wp-admin просить FTP-креденціали під час оновлень

• Симптом: Інтерфейс оновлення вимагає FTP/SSH логін.
• Причина: WordPress не може писати напряму в файлову систему (права/власник або тека змонтована в режимі тільки для читання).
• Виправлення: Виправте власника/права і опції монтування. Якщо у вас іммутабельна інфраструктура — робіть оновлення через пайплайн збірки, а не через wp-admin.

Тільки деякі сторінки показують режим обслуговування

• Симптом: Головна сторінка працює, а конкретні сторінки показують обслуговування (або навпаки).
• Причина: Неконсистентність кешу (один нод кешу має застарілий 503) або плагін, що генерує сторінку обслуговування умовно.
• Виправлення: Очищайте кеш глобально; перевіряйте кілька POP-ів; підтвердьте, чи ввімкнено плагін «режим обслуговування».

Три історії з корпоративного життя

Міні-історія #1: Інцидент через хибні припущення

Середня компанія тримала WordPress за балансувальником навантаження з двома нодами додатку. Оновлення були «простими»: зайшов у wp-admin, натиснув оновити, дочекався спінера і все. Одного ранку маркетинг вирішив оновити плагін за п’ять хвилин до запуску кампанії. Сайт пішов у режим обслуговування і залишився там.

На виклику інженер видалив .maintenance на вузлі A. Нічого не змінилося. Видалив знову. Все одно. Вони вирішили, що проблема «деінде» і почали перезапускати сервіси.

Хибне припущення: що існує лише одна файлова система. Насправді ноди A і B мали локальні диски (без спільного сховища). Балансувальник віддавав частину трафіку на вузол B, де .maintenance усе ще існував. Користувачі отримували рулетку: оновіть — можливо побачите сайт; оновіть ще раз — можливо побачите maintenance.

Коли вони зрозуміли, що це проблема багатонодового узгодження, вирішення було неромантичним: прибрати .maintenance на обох нодах і перестати робити in-place оновлення для «pet» нод. Вони перенесли оновлення плагінів у етап збірки артефактів і деплоїли узгоджено по нодах.

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

Міні-історія #2: Оптимізація, яка обернулася проти команди

Інша організація хотіла швидші сторінки. Вони додали агресивне кешування на краю і налаштували його кешувати «помилки на короткий час», щоб захищати origin під навантаженнями. Мета розумна. Небезпечний дефолт.

Під час оновлення ядра WordPress сайт віддав 503 сторінку обслуговування десь секунд на 20. Кеш на краю запам’ятав цей 503. Клієнти продовжували отримувати повідомлення про обслуговування набагато довше, ніж тривало фактичне оновлення, навіть після видалення .maintenance. Внутрішньо команда бачила сайт (бо обходила CDN у корпоративній мережі). Зовні клієнти бачили «Briefly unavailable». Кількість тікетів підтримки почала швидко зростати.

Вони очистили edge-кеш — і все одразу відновилося. Потім довелося пояснювати, чому 20-секундне оновлення спричинило довший простій. Постінцидентне рішення не було «не кешувати». Воно полягало в тому, щоб не кешувати сторінку обслуговування, не кешувати 503 на шляхах WordPress і налаштувати правила обходу для /wp-admin/ та endpoint-ів, пов’язаних з оновленнями.

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

Міні-історія #3: Нудна, але правильна практика, що врятувала день

Команда в ентерпрайз тримала WordPress як частину більшої платформи. Нічого особливого: Nginx, PHP-FPM, MariaDB і пайплайн деплою, що збирає артефакт для ядра WordPress і затверджених плагінів. Редактори все ще користувалися wp-admin для контенту, але оновлення коду були тільки через CI/CD.

Одного дня автоновлення випадково ввімкнули для плагіна (налаштування змінилося під час міграції). Плагін спробував оновити себе під час пікового трафіку. Він створив .maintenance і потім впав, бо файлова система була за задумом тільки для читання (deploy-only).

Сайт увійшов у режим обслуговування, але команда мала два запобіжники: (1) версіонований артефакт означав, що кодова база консистентна, і (2) погоджені снапшоти що годину дозволили миттєво відкотитися, якщо файлову систему порушено. Вони видалили .maintenance, підтвердили, що файли не змінені (бо не могли бути змінені), вимкнули автоновлення плагінів і відкрили зміни до процесу, щоб запобігти дрейфу налаштувань.

Ніяких геройств. Ніякої хащі SSH. Просто чисті межі: рантайм може слугувати, пайплайн може писати. Це не захопливо, і в цьому суть.

Запобігання: зробіть це нудним і це припиниться

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

Віддавайте перевагу контрольованим оновленням (WP-CLI або пайплайн), а не клік-операціям

Натискати «Update now» у wp-admin з ноутбука в кафе — це не стратегія деплою. Це вправа довіри. Використовуйте WP-CLI на сервері або виконуйте оновлення в пайплайні, який можна повторити, логувати та відкотити.

Тримайте запас дискового простору свідомо

Для хостів WordPress я раджу тримати принаймні кілька гігабайтів вільними на невеликих томах і більше на великих. Оновлення, кеші, логи, завантаження зображень і бекапи конкурують за місце. Тиск диску викликає дивні симптоми задовго до 100% заповнення.

Зробіть власника/права файлів консистентними

Обирайте одну операційну модель і дотримуйтеся її:

• Модель змінного сервера: WordPress може писати оновлення. Тоді рантайм-користувач має володіти або мати права на запис у відповідні шляхи. Підходить для невеликих сайтів; ризиковано для великих.
• Модель іммутабельного деплою: Рантайм тільки читає; оновлення відбуваються в етапі збірки. Добре для надійності; вимагає дисципліни.

Змішування двох моделей призводить до класичної ситуації, коли WordPress може створити .maintenance, але не може його видалити. Це не «безпека». Це пастка, яку ви самі собі ставите.

Запобіжні заходи: моніторинг режиму обслуговування і алерти

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

Правила кешування: не дозволяйте «коротко недоступно» стати «постійно кешованим»

На CDN або зворотному проксі встановіть розумну поведінку для відповідей 503 і для шляхів адміністрування WordPress. Режим обслуговування — транзитна відповідь, яку не слід широко кешувати.

Короткий жарт #2: Нічого так не звучить «рівень підприємства», як кешувати сторінку помилки у 200 місцях по всьому світу.

Контрольні списки / поетапний план

Контрольний список A: Вивести сайт з режиму обслуговування безпечно (10–15 хв)

1. Підтвердьте, що бачить користувач (origin vs кеш).
2. Знайдіть коректний корінь WordPress через wp-config.php.
3. Перевірте існування та мітку часу .maintenance.
4. Шукайте активні оновлення (процеси, логи).
5. Перевірте місце на диску та іноди.
6. Перегляньте wp-content/upgrade на предмет тимчасових тек.
7. Зробіть снапшот/бекуп, якщо доступно.
8. Видаліть .maintenance.
9. Валідуйте: головна сторінка, кілька глибоких посилань, вхід в wp-admin.
10. Перегляньте логи, щоб підтвердити відсутність продовжуваних фаталів/таймаутів.

Контрольний список B: Відновлення з причин невдалого оновлення (30–90 хв)

1. Виправте тиск диску (очистіть старі логи, кеші, непотрібні бекапи).
2. Виправте власника/права згідно з вашою моделлю.
3. Оновлюйте через WP-CLI по одному компоненту.
4. Якщо плагін/тема пошкоджені — перевстановіть чисто.
5. Підтвердіть версію PHP і наявні розширення відповідно до вимог плагінів.
6. Зробіть швидкий smoke-test і слідкуйте за логами помилок.

Контрольний список C: Запобігання повторенням (тут дорослі заробляють гроші)

1. Вирішіть: змінна модель WordPress чи іммутабельний артефактний деплой. Запишіть це.
2. Додайте синтетичний моніторинг на відповідь обслуговування.
3. Додайте алерти на диск та іноди до критичного рівня.
4. Налаштуйте правила CDN/proxy, щоб уникати кешування 503 сторінок обслуговування.
5. Плануйте оновлення у часи низької активності з чіткими шляхами відкату.
6. Тестуйте бекапи/снапшоти, а не лише налаштовуйте їх.

Цікаві факти та історичний контекст

• Режим обслуговування WordPress реалізовано простим lock-файлом (.maintenance) замість прапорця в базі, що робить його швидким і незалежним від стану БД.
• Повідомлення «Briefly unavailable…» існує багато версій і збереглося, бо воно надійне в умовах часткових оновлень: якщо PHP може прочитати файл, він може показати повідомлення.
• WP-CLI починався як community-проєкт і став де-факто стандартом, бо оновлення через інтерфейс не масштабується в операціях.
• Автоматичні фонові оновлення ввели, щоб зменшити лаг у патчах безпеки, але вони додали новий режим відмов: непильні оновлення на неправильно налаштованих файлових системах.
• Оновлення WordPress працюють шляхом розпаковування ZIP-архівів у тимчасові теки, тому чутливі до місця на диску та доступності інодів.
• Раніше багато хостів дозволяли оновлення через FTP, бо PHP часто працював як непривілейований користувач, що не міг писати в директорію сайту.
• Деякі шари кешу за умовчанням кешують 503 як міру стійкості, що може ненавмисно продовжити видимий період обслуговування далеко за фактичне вікно оновлення.
• Екосистема плагінів ускладнює експлуатацію: одне оновлення плагіна може змінити вимоги рантайму (версію PHP, розширення), перетворивши рутинне оновлення на простій.

Питання та відповіді

1) Чи завжди безпечно видаляти файл .maintenance?

Зазвичай так — якщо оновлення не виконується активно. Якщо оновлення ще працює, видалення може дозволити трафіку потрапити на напівоновлений код. Спочатку перевірте процеси/логи і мітку часу.

2) Де знаходиться файл .maintenance?

У кореневій теці WordPress (та сама тека, що містить wp-config.php). Якщо у вас декілька сайтів, кожен має свій корінь і власний .maintenance.

3) Чому режим обслуговування повертається після видалення?

Бо хтось або щось його відтворює: автоновлення повторюється, cron, або інша сесія адміністратора намагається оновити. Зупиніть джерело оновлень, а потім видаліть файл.

4) Я видалив .maintenance і тепер біла сторінка. Що це?

Ймовірно оновлення внесло фатальну помилку (несумісність плагіна/теми, відсутнє PHP-розширення, зламаний автозавантажувач). Перегляньте логи PHP/Nginx/Apache і відключіть підозрілий плагін або перемкніть тему.

5) Чи може кеш створити видимість, що WordPress ще в режимі обслуговування?

Абсолютно. CDN та зворотні проксі можуть кешувати відповідь обслуговування. Порівняйте origin і edge відповіді; очистіть кеши, якщо origin здоровий.

6) Який найшвидший спосіб відключити плагіни, якщо wp-admin не працює?

WP-CLI — найшвидше: wp plugin deactivate --all (потім по черзі включайте заново). Без WP-CLI можна перейменувати директорію плагіна, але це грубіше і менш аудитовно.

7) Чи впливає режим обслуговування лише на фронтенд?

Може впливати і на фронтенд, і на адмінку, залежно від шляху запиту і таймінгу. Під час оновлень часто неможливо надійно користуватися wp-admin, поки оновлення триває або lock не знято.

8) Як запобігти цьому при майбутніх оновленнях?

Виправте корені: забезпечте достатній простір на диску, консистентні права доступу і контрольовані методи оновлення (WP-CLI або пайплайн). Також налаштуйте кеші, щоб не кешувалися 503 відповіді.

9) Чи можна видаляти вміст wp-content/upgrade?

Після відновлення сервісу і підтвердження, що оновлення не виконується, можете видалити старі тимчасові теки в wp-content/upgrade. Якщо не впевнені — залиште доки не завершите відновлення; вони можуть бути доказами помилки.

10) Що робити у мульти-нодовій конфігурації?

Перевірте кожен вузол, що може віддавати сайт. Якщо сховище не спільне, кожен вузол може мати свій .maintenance. Також переконайтеся, що оновлення не запускаються незалежно на різних нодах.

Висновок: наступні кроки для зменшення часу простою

Коли WordPress застряг у режимі обслуговування, механічне рішення — видалення .maintenance. Професійне рішення — упевнитися, що ви не перериваєте активне оновлення, потім виправити причину, через яку воно зупинилося.

Зробіть наступне:

1. Перевірте origin проти кешу і очищайте лише після доведення, що проблема в кеші.
2. Перевірте місце на диску і права доступу — дві нудні проблеми, що створюють більшість драм.
3. Завершуйте оновлення через WP-CLI (по одному) або перенесіть оновлення в пайплайн.
4. Додайте моніторинг на відповідь обслуговування, щоб виявляти проблему до повідомлень клієнтів.

Зробіть оновлення нудними, повторюваними і видимими. WordPress все одно знаходить способи вас здивувати — але менше з них станеться о 09:01 в день запуску.