Мониторинг сайта: как первым узнать, когда что-то сломалось

Этот пост адресован менеджерам проектов по сайтам, а так же тем, кому это ещё предстоит в будущем. Итак, вы ведёте проект по разработке или поддержке сайта. Под вашим руководством работает несколько человек, а так же какие-то правки вносят другие люди – блоггеры, контентщики, сеошники. По хорошему надо ставить все задачи в таск-менеджер, но мы-то с вами знаем, что это не панацея. Ваш руководитель любит пробегать мимо и разбрасывать устные указания. Часть изменений вы вносите в личном общении с верстальщиками. А люди из соседнего отдела вообще вносят мелкие правки и слышать не хотят о том, что вы менеджер и должны контролировать этот процесс.

При этом, если вы с верстальщиками компетентны в плане корректного html-кода, то остальные участники могут тупо редактировать контент через “визуальный редактор” в админке, снося таким образом все тщательно выверенные стили и яваскрипты. Более того, я встречал менеджеров, которые даже не догадываются что когда два человека одновременно редактируют страницу – изменения одного из них всегда будут утеряны. Они уверены в том, что админка “сведёт” их правки воедино, как это сделали бы системы контроля исходного кода (svn). А если к сайту имеет доступ ещё и сам клиент..

Итак, вы менеджер по этому сайту, и у вас ум за разум заходит при попытке контролировать всё и вся. На вас выливают ушаты помоев за то, что на какой-то странице какая-то точка стоит не там где надо. По-хорошему надо было с самого начала писать тесты, но время утеряно, тестов нет, а контролировать надо прямо сейчас. Как?

Вам поможет система мониторинга. В обычном понимании мониторинг – это контроль отклика сайта, который показывает что сайт не упал. Здесь же задача гораздо шире. Во-первых, простое решение “в лоб” не подходит: нельзя сохранять и проверять контрольную сумму html-кода страницы, так как на дворе 2011 год и все страницы сайтов практически всегда динамические. Где-то меняются баннеры, где-то показываются различные товары, где-то выводятся разные анонсы. Решение должно быть более детальным.

Итак, допустим мы написали маленький скрипт на 5 строчек, который циклом проходит по списку URL-ов и скачивает html-контент. Смотрите, что с ним можно сделать:

Решение #1: задавать для каждого URL-а допустимую дельту. Вы вычисляете контрольную сумму (сумму ascii-кодов всех символов html-кода страницы) и сравниваете с сохранённой в предыдущем цикле. Если разница больше дельты – отправляете тревожный сигнал (например письмо менеджеру). Новая сумма в любом случае всегда сохраняется, чтобы последующее сравнение производилось уже с ней.

Чем хорошо это решение: просто и пишется за 5 минут. Чем плохо это решение: если на какой-то странице есть большой динамический блок и мало контента, вам придётся использовать большую дельту и вы можете упустить изменения в основном тексте страницы.

Решение #2, более изящное: задавать допустимую дельту не одну для всей страницы, а индивидуально для блоков. Правда, вам придётся размечать все блоки страницы комментариями или осмысленными айдишниками тэгов (например div id=”content”), но все нормальные верстальщики изначально так и делают. Таким образом вы сможете задать, например:

– от <body> до </body> допустимо изменение 10 000 символов;
– в блоке “left_column” допустимо изменение 1000 символов;
– от начала до конца контента допустимо изменение не более 20 символов.

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