Допустимое число ошибок

Рекомендуем ввести дополнительную метрику качества – число ошибок 50Х за сутки, отданных посетителям веб-системы.

В момент подобной ошибки пользователь получает в ответ системную страницу с сообщением о возникшей неполадке и рекомендацией попробовать зайти позднее.

В ряде случаев подобные ошибки возвращаются веб-системой:

• Если PHP-воркеры не справляются с обработкой запросов
• Если база данных перегружена
• Если возникла внутренняя ошибка PHP, ошибка недостатка каких-либо ресурсов в операционной системе и т.п.

Исследуйте все подобные инциденты. А затем системно внедряйте в процессы разработки-эксплуатации практики, которые сведут аналогичные ситуации к минимуму.

В качестве примера используйте показатель не более 100 50Х ошибок, которые возвращаются клиентам за сутки. И стремитесь к его достижению.

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

• В условиях конкурентной нагрузки
• Параллельных импортов-экспортов в базу данных
• При возможных ошибках в программном обеспечении операционной системы и библиотек PHP
• При некорректных параметрах запуска функций (например, рекурсия в регулярных выражениях, переполняющая внутренний стек).

  Метрики отказоустойчивости

Большинство крупных веб-проектов напрямую связаны с выполнением основных бизнес-процессов компаний.

Требования к их отказоустойчивости включают защиту от выхода из строя:

• Процессора в веб-сервере
• Жесткого диска в базе данных
• Питания серверной стойки

Поэтому необходимо предусмотреть схему резервирования, которая поможет минимизировать время простоя веб-проекта.

Какое время недоступности приемлемо для веб-системы и как «редко» подобные инциденты могут возникать – зависит от бизнес-требований к веб-проекту. Чем меньше требуемое время простоя в часах в год, тем оборудование/тариф будут дороже. Даже крупные облачные хостинги, такие как Amazon Web Services, не гарантируют 100% доступность веб-системы в год.

Распространенная метрика доступности центров обработки данных – «девятки»:

• Tier 2 (отказоустойчивость — 99,749 %) – возможный простой в год: 22h 0m 7.9s
• Tier 3 (отказоустойчивость — 99,982 %) – возможный простой в год: 1h 34m 40.3s
• Tier 4 (отказоустойчивость — 99,995 %) – возможный простой в год: 26m 17.8s. Это высший на сегодня уровень надежности дата-центров с двойным резервированием и дублированием всех подсистем.

При выборе хостинг-провайдера необходимо обратить внимание на гарантируемую отказоустойчивость. Отказоустойчивость всей системы зависит от самого «слабого» узла.

Рекомендуем получить от специалистов дата-центра информацию о способах восстановления системы в случае внезапного выхода из строя master-сервера базы данных, который по репликации сохраняет данные на slave-сервере. А также выяснить, сколько времени потребует переключение slave-сервера на роль master-сервера и подключение для распределения нагрузки дополнительного slave-сервера взамен другого.

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