Сбои в работе веб-проекта: не "если" а "когда"

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

Реакция важнее причины.

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

Коммуникация в кризис.

Одна из главных задач поддержки при сбое — информирование. Руководитель должен сразу получить сообщение: «Мы знаем о проблеме, причина в хостинге, ориентировочное время восстановления — 30 минут». Это позволяет бизнесу вовремя перенаправить трафик или предупредить отдел продаж.

Разбор полетов.

Каждый серьезный сбой должен заканчиваться глубоким анализом. Почему это произошло? Могли ли мы это предотвратить? Что нужно изменить в архитектуре проекта, чтобы такая ошибка стала невозможной? Без этого анализа поддержка превращается в бесконечный бег по граблям.

Резервирование как инвестиция.

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