Для сайта-визитки и магазина с постоянными заказами один и тот же сбой имеет разные последствия. Даже внутри магазина недоступность архивной новости и невозможность оплатить покупку не равны по важности. Поэтому обсуждение надёжности лучше начинать с операций, от которых зависит работа компании.
Число серверов и красивый процент доступности появятся позже. Сначала владельцу и исполнителю нужно договориться, какой результат считается нормальным, как обнаруживается нарушение и что делать при его возникновении. Это помогает выбирать работы по их влиянию на сайт, а не по сложности предлагаемой технологии.
Выберите важные действия посетителя
Составьте короткий список: открыть каталог, получить цену, отправить заявку, войти в кабинет, оформить и оплатить заказ. У каждого действия есть ожидаемый результат. Ответ сервера с кодом 200 не подтверждает, что письмо дошло сотруднику или заказ сохранился в учётной системе.
Отдельно отметьте периоды, когда нарушение особенно чувствительно: рекламная кампания, приём заявок к сроку, часы работы отдела продаж. Условия должны быть конкретными. Фраза «всё критично» не помогает выбрать между восстановлением оплаты и исправлением второстепенной страницы, если проблема затронула несколько функций одновременно.
Проверьте внешние зависимости этих действий. Сайт может отвечать, но не получать расчёт доставки. Нужно заранее решить, допустим ли другой способ оформления или операция должна завершаться понятным отказом. Такие варианты обсуждаются в статье о недоступности внешних сервисов.
Определите наблюдаемый результат
Для заявки можно проверять сохранение обращения и доставку уведомления. Для каталога — доступность страницы и время ответа. Для обмена остатками — возраст последнего корректного обновления. Каждому показателю нужны источник данных, период наблюдения и ограничения измерения.
Внешняя проверка видит часть пути посетителя, журналы приложения — другую. Если запрос не дошёл до сервера, запись в его журнале не появится. Если ошибка затрагивает отдельный регион или роль пользователя, одна проверка из одного места может её пропустить. Эти ограничения стоит записать, а не прятать за общей цифрой.
Для начала достаточно нескольких полезных показателей. Их задача — помогать обнаруживать и разбирать нарушения. Десятки графиков без связи с пользовательскими операциями не дают такого результата. Практический набор проверок разобран в материале о мониторинге сайта.
Разделите цель и обязательство по договору
В инженерной практике измеряемый показатель называют SLI, а целевой уровень — SLO. Эти термины удобны при обсуждении, но сами по себе не создают договорных обязательств. SLA описывает согласованные условия услуги и последствия их нарушения; его содержание нужно смотреть в конкретном договоре.
Не переносите процент из предложения провайдера на весь сайт. Доступность виртуальной машины не равна успешности оплаты, доставки письма или обмена с 1С. Для каждого обещания важно уточнить предмет измерения, исключения и ответственность сторон. Иначе стороны будут обсуждать разные услуги одной и той же формулировкой.
Согласуйте восстановление и сохранность данных
Два отдельных вопроса: как долго можно восстанавливать работу и насколько старые данные допустимо получить после восстановления. Требование быстро открыть сайт не отвечает на вопрос о заказах, появившихся перед сбоем. Для активно меняющегося проекта нужны обе границы.
Это целевые требования, которые ещё предстоит проверить. Наличие резервной копии не доказывает возможность уложиться в выбранное время. Проведите пробное восстановление и измерьте этапы: получение доступа, загрузку данных, запуск и проверку операций. Разница между временем реакции и восстановления разобрана в отдельной статье.
Сопоставьте требования с расходами
Более строгие условия могут потребовать другой организации дежурства, независимых копий, запасных ресурсов и регулярных учений. Но иногда первая полезная работа гораздо проще: восстановить доступы, исправить резервирование или добавить контроль формы. Выбор зависит от обнаруженных слабых мест.
Сравнивайте меры по тому, какие нарушения они предотвращают или сокращают. Запасной сервер не поможет от ошибочного удаления данных на всех узлах, а частые копии не заменят человека, который получит сигнал и начнёт восстановление. Требования должны связывать технические средства и порядок работы исполнителей.
Пересматривайте договорённости после изменений
Новая платёжная система, рост заказов или появление личного кабинета меняют значимость операций. После таких изменений обновите проверки и план восстановления. Разбор уже произошедших сбоев тоже даёт материал: какой сигнал опоздал, чего не хватило для восстановления, какой шаг оказался ручным.
Храните договорённости в коротком доступном документе. Для каждой важной операции укажите проверку, цель, ответственного и действие при нарушении. Такой документ полезнее общей фразы о бесперебойной работе, потому что по нему можно проверить готовность поддержки и выбрать следующий шаг.
Уточните также, как владелец узнаёт о ходе восстановления. Даже когда технические действия идут правильно, отсутствие сведений мешает решить, приостанавливать ли рекламу или принимать обращения другим способом. Канал связи и ответственный за обновление статуса — часть рабочего порядка, которую можно согласовать без дополнительных серверов.
Если хотите определить разумные требования к надёжности вашего сайта, напишите в HOMEWEB. Помогу связать важные для бизнеса операции с проверками, резервированием и порядком восстановления.
