Мониторинг и аналитика

Разрабатывая проект, нужно сразу думать о том, как мониторить его состояние в период эксплуатации. Перезапуск Apache и MySQL помогает почти всегда, но не является "правильным" выходом, так как не диагностируется и не исправляется проблема. А о проблемах, при отсутствии системы мониторинга, узнаётся либо от клиента, либо от посетителей, либо от собственного руководства, что совсем не является признаком качественной работы студии.

Цель этой главы - понять, какой бизнес-процесс нужно выстроить, чтобы взять процесс эксплуатации под контроль. Высоконагруженные проекты имеют тенденцию со временем деградировать, подчиняясь закону энтропии. Тем не менее, проект можно поддерживать, делать его простым, прозрачным и удобным. Он будет развиваться, приносить и пользу и радость.

  Почему у проекта возникают проблемы

1. Проектирование. Не всегда достаточно выделяется времени на этот этап - это субъективный фактор. Требования меняются до самого конца - это объективный фактор, не зависящий ни от студии, ни от менеджера. В результате отсутствия или не должного проектирования бывают не предусмотрены многие аспекты, которые, как потом выясняется, можно было предусмотреть и предотвратить.
2. Сжатые сроки на развертывание веб-проекта на хостинге. Это проблемы бизнеса, который требует запуска проекта "ещё вчера" или "раньше конкурентов", но реализовывать эти требования - разработчику. Работа в таких условиях требует немалого опыта.
3. Мало кто проводит и умеет делать нагрузочное тестирование, так как главное тут - опыт.
4. Не все задумываются над организацией: мониторинга, резервного копирования, обновления софта на серверах и подобных "второстепенных" задач.

Система запускается "как есть" и по инерции может поработать год-два без вмешательства. Но невыполнение (не полное выполнение) вышеописанных требований ведёт к деградации системы.

Деградация может быть остановлена, а может быть ускорена. К сожалению, достаточно часто происходит второе в силу:

• В случае торможения системы не ищутся причины, а принимаются меры приводящие к сиюминутному результату: перезапускается Apache или MySQL и подобные решения.
• Программисты что-то дописывают на "боевых" серверах, зачастую без тестирования: так быстрее.
• Меняются программисты и менеджеры проекта и при отсутствии документации теряется логика развития: никто не представляет себе систему в целом, как единый организм.

  Как должно быть: идеальная система

Создать идеальную систему не сложно. Сложно в условиях постоянного давления со стороны бизнеса её поддерживать в должном состоянии. (А давление заключается в постоянном внесении изменений в проект.) Но к этому надо стремиться, этого надо добиваться:

• Доступ на сервера строго ограничен кругом квалифицированных администраторов, занимающихся только эксплуатацией проекта. Разработчики могут их только консультировать.
• Вся система должна быть покрыта "датчиками" и мониторится. Уведомления должны идти на SMS, в крайнем случае на e-mail. Хорошо, если есть дежурные администраторы в режиме 24/7.
• Перед попаданием на рабочий сервер код должен обязательно пройти цепочку серверов (develop, testing, stage сервера) для функционального и нагрузочного тестирования.
• Рабочие сервера должны быть "стерильны", код выкладывается только через систему контроля версий.
• ПО на серверах постоянно обновляется, "дырки" закрываются, предварительно всё тестируется.

  Если нет своего администратора

Если нет своего администратора, то придётся обращаться либо к услугам аутсорсинга, либо использовать внешние системы типа Яндекс.Метрики, которые смогут вам сообщить хотя бы о недоступности вашего сервиса.

Для стабильной эксплуатации системы нужно:

1. Ввести строгий регламент работы для программистов и администраторов.
2. Покрыть систему "датчиками". Это подскажет где что не так.
3. Анализировать тенденции движения системы. Нужен прогноз того, что может случиться с системой завтра, через неделю, в течение месяца.