Инциденты и внеплановые работы SpaceWeb в 2026 году
Инциденты и внеплановые работы SpaceWeb в 2026 году
Последняя проверка: 31 августа 2026 года.
Краткий вывод
В личном кабинете SpaceWeb обнаружены два уведомления о внеплановых работах в июле 2026 года:
- сетевые работы с объявленным шестичасовым окном возможной недоступности;
- перезагрузка сервера на следующий день после публикации уведомления.
Оба сообщения предупреждают о возможном воздействии, но не подтверждают фактический простой. Поэтому объявленное окно нельзя использовать как измеренную продолжительность недоступности.
Хронология уведомлений
| Дата уведомления | Работы | Объявленное воздействие | Фактический результат | Источник |
|---|---|---|---|---|
| 28 июля | Внеплановые работы на сети | Ресурсы могли быть недоступны с 14:00 до 20:00; часовой пояс не указан | Не подтверждён | Клиентское уведомление в панели SpaceWeb |
| 10 июля | Внеплановые работы на сервере | Перезагрузка сервера 11 июля с 05:00; длительность и часовой пояс не указаны | Не подтверждён | Клиентское уведомление в панели SpaceWeb |
Внеплановые сетевые работы 28 июля
В уведомлении от 28 июля указано:
Ресурсы могут быть недоступны с 14:00 до 20:00.
Это окно возможного воздействия продолжительностью до шести часов. Из сообщения нельзя установить:
- какие именно ресурсы или серверы были затронуты;
- начались ли работы ровно в 14:00;
- была ли недоступность непрерывной;
- какой часовой пояс использовался;
- завершились ли работы раньше или позже 20:00;
- менялись ли маршруты, IP-адреса или сетевое оборудование;
- был ли фактический простой у сайтов и других сервисов аккаунта.
Для уточнения события нужны данные внешнего мониторинга, журнал обращений или итоговое сообщение провайдера.
Перезагрузка сервера 11 июля
Уведомление было опубликовано 10 июля. В нём указана перезагрузка сервера 11 июля с 05:00.
Сообщение не содержит:
- идентификатор сервера;
- причину работ;
- ожидаемую длительность;
- часовой пояс;
- число возможных перезагрузок;
- подтверждение успешного завершения;
- сведения о фактической недоступности сайта, почты или базы данных.
Перезагрузка обычно создаёт короткое окно недоступности, но без мониторинга нельзя приписывать событию конкретную продолжительность.
Почему это фиксируется в журнале инцидентов
Работы были объявлены заранее, но названы провайдером внеплановыми и допускали недоступность ресурсов. Это операционный сигнал, который полезно хранить рядом с инцидентами, однако отдельно от подтверждённых аварий.
В сводную таблицу значимых простоев событие следует переносить только при наличии хотя бы одного подтверждения:
- внешний мониторинг зафиксировал недоступность;
- провайдер сообщил о фактическом сбое;
- объявленное окно было превышено;
- после работ сервер не запустился или работал с ошибками;
- появились проблемы сети, диска, DNS или почты;
- была потеря данных;
- опубликован итоговый отчёт с реальным воздействием.
Что проверять после сетевых работ
Для VPS, сайта или другого ресурса полезно сохранить результаты до работ и повторить их после завершения:
curl -fsS -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/
dig +short example.com A
dig +short example.com AAAA
mtr -rwzc 100 SERVER_IP
Дополнительно проверить:
- доступность сайта из нескольких операторов;
- SSH, VPN и административную панель;
- исходящий и входящий трафик;
- DNS и TTL;
- IPv4 и IPv6;
- reverse DNS;
- firewall и allowlists;
- внешний мониторинг;
- задания резервного копирования;
- маршруты до основной аудитории.
Что проверять после перезагрузки сервера
uptime
who -b
last -x | head -20
systemctl --failed
journalctl -b -p warning
Для приложения отдельно проверить:
- web server и PHP-FPM;
- базу данных;
- очереди и cron;
- Docker containers;
- свободное место;
- монтирование дополнительных дисков;
- отправку почты;
- backup agent;
- синхронизацию времени;
- автоматический запуск всех сервисов.
Ограничения источника
Источник — скриншот раздела «Уведомления → Важное» клиентской панели SpaceWeb, предоставленный 31 августа 2026 года.
В репозиторий перенесена только текстовая выжимка. Исходный скриншот не публикуется, поскольку содержит идентификатор аккаунта.
По одному уведомлению нельзя утверждать, что простой действительно произошёл или длился всё объявленное окно.
Влияние на оценку провайдера
Эти два уведомления сами по себе не требуют переносить SpaceWeb из категории «Норм».
Для пересмотра оценки нужны дополнительные данные:
- повторяемость внеплановых работ;
- реальная длительность воздействия;
- число затронутых серверов и сервисов;
- качество предупреждения и итоговой коммуникации;
- наличие компенсации;
- данные независимого мониторинга;
- результат восстановления после перезагрузки.
Источник
- клиентские уведомления SpaceWeb от 10 и 28 июля 2026 года, показанные в личном кабинете