Почему модернизация сайта — это не про дизайн, а про спасение бизнеса от падений

Но сам повод рабочий: бизнес до сих пор сидит на легаси, и это давно не про «эстетику устарела», а про то, что прод регулярно падает.

Где обычно сыпется

Старый сайт — это не «некрасивый дизайн». Это PHP 5.x без патчей, jQuery 1.6, MySQL с таблицами на сотни строк без индексов, и где-нибудь в углу — .htaccess размером с «Войну и мир». Хостинг — shared за три доллара в месяц, SSL — самоподписанный, бэкапы — «иногда Вася делает по пятницам». Когда такая конструкция ложится под нагрузкой или после апдейта CMS, дебажить приходится вслепую: логов нет, мониторинга нет, версии библиотек неизвестны, а заказчик на той стороне провода искренне верит, что «вчера ещё работало».

Что агентство предлагает — и где включается скепсис

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

Что сделать, пока пресс-релиз не превратился в проект

Прежде чем подписываться на любую «модернизацию» — локальную или от заокеанского агентства — стоит прогнать минимальную диагностику и зафиксировать текущее состояние. Иначе через месяц выяснится, что новый фронт ходит в старый API по SOAP, а миграция данных — это mysqldump на 4 Гб, который не влезает в таймаут.

# версии рантайма
php -v
mysql --version
node -v 2>/dev/null || echo "node: not found"
# что отвечает сервер
curl -sI | head -20
# SSL — живой ли вообще
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com \
< /dev/null 2>/dev/null | openssl x509 -noout -dates
# что слушает порты
lsof -i -P -n | grep LISTEN
# бэкап ДО любых изменений — не после, а ДО
tar czf backup-www-$(date +%F).tar.gz /var/www/
mysqldump -u root -p --all-databases > backup-db-$(date +%F).sql
# проверить, что бэкап не пустой
ls -lh backup-*.tar.gz backup-*.sql

Первое правило при работе с легаси — бэкап. Второе — тоже бэкап. Третье — бэкап бэкапа на отдельный хост. Всё остальное можно переписать, восстановить из копии данных нельзя.