Как избежать простоя сайта: чек-лист владельца из десяти пунктов
Полностью исключить простои нельзя — даже у гигантов с их бюджетами сайты иногда лежат. Но между «сайт падает раз в год на десять минут» и «сайт лежит каждый месяц по полдня» — не везение, а десяток скучных привычек. Вот они, в порядке отдачи на вложенное время.
Сначала рамка. Простой — это произведение двух величин: как часто сайт падает и как долго лежит. Первую половину сокращает профилактика (пункты 1–6), вторую — готовность к инциденту (пункты 7–10). Экономика обычно на стороне второй половины: превратить трёхчасовой простой в двадцатиминутный проще и дешевле, чем предотвратить сам сбой. Сколько стоит час лежащего сайта именно вам — считали здесь; эта цифра определяет, сколько разумно вложить в пункты ниже.
Сократить частоту падений
1. Хостинг с запасом, а не впритык. Большинство «загадочных» сбоев — это ресурсы, кончившиеся в пик: память, процессор, соединения с базой. Правило простое: если в обычный день сервер загружен больше чем наполовину, пиковый день его положит. Когда сайт уже сейчас периодически тормозит — сначала прочитайте наш разбор «VPS или виртуальный хостинг», потом переезжайте.
2. Автопродление всего, что истекает. Домен и SSL-сертификат — два предсказуемых убийцы сайтов: их «сбои» известны за месяцы. Автопродление у регистратора, автовыпуск сертификата — и независимый контроль сроков снаружи, потому что автоматика тоже ломается (как именно — в разборе про «внезапно» истёкшие сертификаты).
3. Никаких изменений сразу на живом сайте. Значительная часть простоев рукотворна: обновление плагина, правка шаблона, «быстрый фикс» в пятницу вечером. Лекарство скучное: тестовая копия сайта для любых обновлений, бэкап перед любыми правками, изменения — не в часы пик и не перед выходными.
4. Бэкапы, которые восстанавливаются. Бэкап, который ни разу не разворачивали, — это гипотеза, а не бэкап. Минимальный стандарт: автоматические ежедневные копии, хранение вне хостинга (падение хостинга не должно уносить и сайт, и копии) и пробное восстановление раз в квартал с секундомером — эта цифра и есть ваше реальное время восстановления в худшем сценарии.
5. Обновления и базовая защита. Взломанный сайт — это простой с отягчающими: чистка, переиндексация, вывод из чёрных списков растягиваются на недели. Регулярные обновления CMS и плагинов, минимум лишних расширений, сложные пароли и двухфакторка на админке и у регистратора закрывают большинство сценариев.
6. Знать свои зависимости. Сайт лежит не только когда лежит сервер: падение платёжного шлюза, CDN, сервиса капчи или внешнего API кладёт ключевые сценарии при формально живом сайте. Составьте список внешних сервисов, от которых зависит оформление заказа, и решите для каждого: есть ли деградация без него (оплата при получении, отключаемая капча) или его падение — ваш простой.
Сократить длительность падений
7. Узнавать о сбое раньше клиентов. Главный множитель длительности простоя — время, пока о нём никто не знает. Ночное падение без мониторинга живёт до утра; с мониторингом и звонком — минуты. Проверки должны идти снаружи, из нескольких регионов, с интервалом, соответствующим цене простоя (как выбрать), и накрывать не только главную: домен, сертификат, DNS, ключевые страницы. Минимальный набор собирается из проверки доступности и проверки сертификата.
8. План инцидента на одну страницу. В момент падения думается плохо — план должен быть написан заранее: куда смотреть в первую очередь, где логи, как откатить последнее изменение, телефон поддержки хостинга, где лежат доступы. У нас есть готовый каркас — «Сайт упал: первые 10 минут»; адаптируйте под себя и положите туда, где найдёте в панике.
9. Доступы не в одной голове. Сбой в отпуске единственного человека с паролями — классика длинных простоев. Доступы к хостингу, регистратору, DNS и админке должны быть минимум у двоих, а у аккаунтов — актуальные почта и телефон для восстановления.
10. Разбор после каждого инцидента. Пять минут после восстановления: что упало, почему, как узнали, сколько чинили, что сделать, чтобы не повторилось. Без этого пункта список выше не работает — сбои будут повторяться по кругу. Журнал инцидентов из мониторинга здесь заменяет память и споры о том, «сколько на самом деле лежали».
С чего начать, если сейчас нет ничего
| Когда | Что сделать | Время |
|---|---|---|
| Сегодня | Включить автопродление домена и SSL; поставить мониторинг доступности, домена и сертификата | 30 минут |
| На этой неделе | Проверить бэкапы восстановлением; написать план инцидента; раздать доступы второму человеку | 2–3 часа |
| В этом месяце | Завести тестовую копию для обновлений; составить список зависимостей; оценить запас хостинга | 1 день |
И ориентир, чтобы понимать, к чему стремиться: аптайм 99,9% — 43 минуты простоя в месяц — достижим для обычного сайта на приличном хостинге без всякой магии, ровно этим списком. Погоня за девятками дальше — уже вопрос архитектуры и бюджета, мы разбирали эту арифметику в статье про уровни SLA.
Пруфен проверяет доступность, домен, сертификат и DNS из 13 точек — 11 из них в России — с интервалом от 2 минут и будит Email, Telegram, Макс или звонком. Журнал инцидентов ведётся сам — пункт 10 получаете бесплатным приложением. Бесплатного тарифа хватает на 5 проверок.