Поддержка сайта: обновления, резервные копии и безопасность

Сайт редко ломается внезапно. Обычно он год живёт без обновлений, обрастает плагинами и виджетами, теряет часть резервных копий, а потом в один день перестаёт открываться — и выясняется, что восстанавливать нечего. Мы занимаемся технической поддержкой сайтов и видим одни и те же сценарии из проекта в проект. Ниже собрано то, из чего складывается нормальное обслуживание: обновления, резервные копии, безопасность, хостинг и порядок действий на случай аварии.

Что входит в поддержку сайта

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

• Наблюдение за работой сайта. Доступность, скорость, ошибки в журналах сервера, сроки действия домена и сертификата.
• Обновления. Система управления, модули и библиотеки, версии серверного программного обеспечения.
• Резервные копии. Регулярное создание, хранение отдельно от сервера и проверка того, что копия действительно разворачивается.
• Безопасность. Разграничение доступов, защита форм, реакция на подозрительную активность, устранение уязвимостей.
• Контентные и мелкие доработки. Тексты, изображения, новые страницы, правки вёрстки.
• Реакция на аварии. Понятный порядок действий и зафиксированное время ответа.

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

Обновления: почему их откладывают

Причина всегда одна и та же: сайт работает, трогать страшно. Логика понятная — обновление модуля может сломать вёрстку или отключить нужную функцию. Но откладывание не убирает риск, а накапливает его. Через год разрыв между установленной и текущей версией становится таким, что обновиться одним шагом уже нельзя, а часть модулей к тому времени перестаёт поддерживаться авторами.

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

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

Как обновлять без риска

Порядок, которого мы придерживаемся, простой и почти не зависит от платформы.

1. Сделать резервную копию файлов и базы данных непосредственно перед работой.
2. Развернуть копию сайта на тестовой площадке — отдельном поддомене, закрытом от индексации и от посторонних.
3. Обновить на тестовой копии, а не на живом сайте.
4. Проверить ключевые сценарии: главная страница, каталог, карточка товара или услуги, поиск, корзина, отправка формы, вход в административную часть.
5. Перенести изменения на рабочий сайт в часы наименьшей посещаемости.
6. После обновления ещё раз пройти по тем же сценариям и заглянуть в журнал ошибок.

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

Резервные копии: что, куда и как часто

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

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

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

Копия, которая не разворачивается, копией не является

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

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

Безопасность: откуда приходят проблемы

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

Отдельно скажем про формы. Форма обратной связи — это дверь, через которую на сервер попадают данные извне. Всё, что приходит из формы, должно проверяться на стороне сервера, а не только в браузере: проверку в браузере обходят одной строкой в консоли.

Доступы: скучно, но важнее многого

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

• У каждого человека своя учётная запись, а не общая на всех.
• Права выдаются по задаче: редактору не нужен доступ к настройкам сервера.
• Учётные записи ушедших сотрудников и завершивших работу подрядчиков отключаются в тот же день.
• Пароли хранятся в менеджере паролей, а не в файле «доступы.txt» на рабочем столе.
• Доступ к хостингу, домену и почте оформлен на компанию, а не на личный аккаунт сотрудника.

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

Хостинг как часть поддержки

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

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

Что делать, когда сайт уже не работает

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

1. Открывается ли сайт по адресу и по IP. Если по адресу нет, а по IP да, вопрос в домене или DNS.
2. Действуют ли домен и сертификат. Просроченный сертификат даёт предупреждение в браузере, просроченный домен — полную недоступность.
3. Что отвечает сервер. Ошибка 500 говорит о проблеме в коде или конфигурации, 404 — о неверном адресе или сбитых правилах, 502 и 504 — о перегрузке или упавшем процессе.
4. Что в журналах ошибок сервера и системы управления. Обычно там сразу видно файл и строку.
5. Что менялось последним. Обновление, новый модуль, правка настроек, действия хостинга.
6. Если причина не находится быстро, разворачивается последняя рабочая копия, и разбор продолжается уже без простоя.

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

Персональные данные и документы на сайте

Как только на сайте появляется форма с именем, телефоном или почтой, компания начинает обрабатывать персональные данные. Это накладывает обязанности, которые проще выполнить сразу, чем объясняться потом.

• Политика обработки персональных данных опубликована и доступна с любой страницы.
• Рядом с каждой формой есть согласие на обработку данных, которое посетитель отмечает сам — предустановленная галочка согласием не считается.
• Понятно, кому и зачем передаются данные, если на сайте работают сторонние сервисы аналитики, чатов и рекламы.
• Заявки не хранятся вечно и не пересылаются на личную почту сотрудников без ограничений.
• Есть способ отозвать согласие и удалить данные по обращению.

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

Регламент: что и когда проверять

Поддержка перестаёт быть реакцией на проблемы, когда становится расписанием. Ниже — тот набор проверок, от которого мы отталкиваемся; под конкретный проект он корректируется. По такому расписанию ведётся, например, сайт расчётного центра коммунальных услуг.

Что спросить у подрядчика по поддержке

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

• Где хранятся резервные копии, за какой период и кто их проверяет.
• Как выглядит порядок обновлений: есть ли тестовая площадка.
• Какое время реакции на обращение и как оно отличается для аварии и для обычной задачи.
• Кто имеет доступ к серверу и как эти доступы отзываются.
• Что происходит, если мы решим сменить подрядчика: передаются ли доступы, код и копии.
• Как ведётся учёт работ — видно ли владельцу, что именно делалось в прошлом месяце.

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

Если вести поддержку своими силами некому, эту работу можно передать: мы берём на сопровождение и чужие сайты — подробнее о студии и её услугах на главной странице «Вебтую».

Что ломается без всякого взлома

Часть аварий не связана со злоумышленниками: просто вокруг сайта что-то поменялось, а сам он остался прежним. Типичный набор выглядит так.

• Истёк сертификат, и браузер показывает предупреждение вместо страницы.
• Хостинг перевёл сервер на новую версию PHP, и старый код перестал работать или начал сыпать ошибками.
• Сторонний сервис поменял обмен данными, и выгрузка товаров или передача заявок в CRM остановилась.
• Закончилось место на диске, и сайт перестал принимать загрузки и писать в базу.
• Внешний скрипт виджета перестал отвечать, и страница подвисает при загрузке.
• Изменились правила почтовых служб, и письма с сайта стали уходить в спам.

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

Скорость и техническое состояние для поиска

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

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

Что устаревает быстрее всего

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

Актуальность содержимого

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

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

• последняя новость или запись в блоге двух-трёхлетней давности;
• на главной висит давно закончившаяся акция;
• форма отправляет письма на ящик уволившегося сотрудника;
• в шапке телефон одного города, а в подвале другого;
• ссылки на страницы в социальных сетях, которых больше нет.

Форматы обслуживания

• Разовые работы. Сайт стабилен, задачи появляются раз в несколько месяцев, простой не критичен. Оплачивается затраченное время.
• Абонемент. Фиксированный объём часов в месяц с оговорённым временем реакции, регулярные проверки входят в объём.
• Полное сопровождение. Для сайтов, через которые идут заказы: мониторинг, дежурство по инцидентам и планомерное развитие.

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

Если бюджет ограничен: что делать в первую очередь

1. То, что угрожает работоспособности: обновления безопасности, резервные копии, сертификат, работающие формы.
2. То, что влияет на обращения: цены, состав услуг, контакты, страницы, на которые ведёт реклама.
3. Скорость и мобильная версия.
4. Оформление — когда содержание уже в порядке.

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

Коротко

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

Мы берём на себя обслуживание сайтов на разных платформах: следим за доступностью, обновляем, храним и проверяем резервные копии, закрываем уязвимости и отвечаем на срочные обращения. Если хотите передать эти задачи и перестать держать их в голове, посмотрите, как устроена техническая поддержка сайтов у нас, или напишите — разберём состояние вашего сайта и предложим план обслуживания.