Обновлять сайт или не трогать, пока работает: взвешенный подход к обновлениям

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

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

Почему сайт бизнеса не похож на коробочный

Любой сайт, который приносит деньги, за несколько лет обрастает доработками. Это происходит естественно, шаг за шагом.

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

Каждое из этих решений писалось под конкретную версию платформы и конкретное окружение. Часть делалась основательно, часть — как временное решение, которое «потом переделаем», и осталась навсегда. Кое-что делал прежний подрядчик, которого уже не найти. Кое-что — сотрудник, который давно уволился. Документации, скорее всего, нет ни на что.

Именно это и отличает живой сайт от чистой установки. И именно поэтому обновление на нём — не нажатие кнопки, а работа с непредсказуемым результатом.

Что реально происходит при обновлении

Обновление платформы или версии серверного программного обеспечения — это замена того основания, на котором стоят все ваши доработки.

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

Результат бывает трёх видов.

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

Незаметная поломка. Самый опасный вариант. Сайт открывается, выглядит нормально, но перестала работать отправка заявок с формы. Или выгрузка остатков молча стала загружать вчерашние данные. Или письма перестали доходить. Обнаруживается это через две недели, когда кто-то случайно замечает, что заявок подозрительно мало.

Поломка под нагрузкой. Всё работает при проверке и падает, когда приходят люди.

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

Почему потом это тяжело чинить

Здесь и находится главный аргумент в пользу осторожности.

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

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

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

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

Когда обновляться действительно нужно

Осторожность не означает «не обновляться никогда». Есть ситуации, когда откладывать нельзя.

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

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

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

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

Сайт всё равно переделывается. Если предстоит крупная переработка, разумно делать её сразу на актуальной версии.

Во всех остальных случаях вопрос «обновляться или нет» решается не желанием иметь свежие цифры в панели управления, а трезвым расчётом.

Как принимать решение

Практический подход выглядит так.

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

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

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

Посмотрите на календарь. Обновлять сайт в разгар сезона — очень дорогая идея. Любые рискованные работы делаются в период низкого спроса.

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

Если обновляться всё-таки нужно: как снизить риск

Когда решение принято, есть набор мер, которые превращают лотерею в управляемую процедуру.

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

Тестовая копия сайта. Обновление сначала ставится на копию, а не на живой сайт. Это самая важная мера из всех. На копии можно спокойно всё сломать, разобраться и понять объём работ, не теряя ни одной заявки.

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

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

Постепенность. Не обновлять всё сразу. Сначала одно, проверка, потом другое. Если что-то сломается, будет понятно, что именно.

Правильное время. Ночь, выходные, низкий сезон. И обязательно — не перед отпуском специалиста, который это делает.

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

Две истории из практики

Чтобы разговор не был отвлечённым, приведём два типичных сюжета, которые повторяются у разных компаний почти дословно.

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

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

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

Что делать с накопленными доработками

Если каждое обновление превращается в риск, значит, проблема не только в обновлении.

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

Практические шаги, которые окупаются.

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

Комментарии в коде. Когда доработка делается, пусть в ней остаётся хотя бы пара строк с объяснением. Через три года это будет единственная подсказка.

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

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

Чем аккуратнее устроен сайт, тем менее страшным становится обновление. И наоборот: чем больше в нём необъяснимых мест, тем разумнее правило «работает — не трогай».

Что в итоге

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

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

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

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