Я работаю в компании из списка Fortune 500, которая не может точно измерить производительность и доступность приложений с высокой доступностью (т. Е. Приложений, которые увеличиваются на 99,5% при переходе от страницы к странице за 5 секунд). Мы учитываем как запланированные, так и внеплановые простои, чтобы определить этот номер доступности. Однако недавно мы добавили в набор CDN, что немного усложняет наши показатели. CDN теперь обрабатывает около 75% нашего трафика, а оставшуюся часть отправляет на наши собственные серверы.
Мы пытаемся измерить то, что мы называем «истинным пользовательским опытом» (то есть наши сценарии тестирования имитируют типичного пользователя, щелкающего по приложению). Эти сценарии мониторинга находятся за пределами нашей сети, что означает, что мы попадаем в CDN примерно на 75% время.
Руководство решило, что для оценки доступности мы возьмем наихудший сценарий. Так что, если на наших исходных серверах возникают проблемы, но CDN все же отлично обслуживает контент, мы все равно будем следить за доступностью. То же верно и наоборот. Я считаю, что до тех пор, пока «пользовательский опыт» будет успешным, мы не должны без надобности наказывать себя. В конце концов, CDN нужен для повышения производительности и доступности!
Мне просто интересно, знает ли кто-нибудь, как другие компании из списка Fortune 500 рассчитывают свои показатели доступности? Я смотрю на apple.com, например, витрину магазина, использующую CDN, которая, кажется, никогда не отключается (если только не будет объявлено крупное объявление о продукте). Было бы здорово иметь некоторые достоверные фактические данные, потому что я не Не верю, что нам нужно без надобности навредить себе по этим показателям. Мы являются принятие деловых решений на основе этих цифр.
Однако я могу сказать, что, учитывая, что эти показатели видны руководству, проблемы решаются и решаются довольно быстро (читай: мы довольно быстро преодолеваем бюрократизм). К сожалению, как разработчик, я не хочу, чтобы руководство думало что приложение работает или не работает, потому что на числа влияет какой-то внешний фактор (например, CDN).
Мысли?
(Я по ошибке разместил этот вопрос на StackOverflow, заранее извините за перекрестную публикацию)
Я согласен с user44700, лучше разделить тестирование доступности для ваших серверов и CDN и отслеживать два независимых теста независимо друг от друга. Ваша истинная доступность будет: Server Avail * CDN Avail, поскольку если какая-либо из них выйдет из строя - вы считаете, что ваша страница / сайт не работает. Это также будет стоить вам меньше с любым из поставщиков мониторинга.
Я бы не стал идти по пути создания одного теста браузера и смотреть, какие элементы не сработали, хотя он может работать, и у некоторых компаний, таких как Catchpoint, есть концепция «доступности контента» - это может быть не совсем то, что вам нужно для этого случая. Скажем, например, на вашей веб-странице есть вызов CDN для файла, который доставляет 404, большинство решений для мониторинга скажут вам, что это сбой, но действительно ли это был CDN? Этот файл вообще был важен? возможно, кто-то просто забыл удалить ссылку на реликвию, которую никто не замечает.
Вы можете прочитать это сообщение в блоге, чтобы получить еще несколько идей: http://blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/
Говоря абстрактно, я бы сказал, что вам следует четко определить, что составляет «доступное» и «недоступное», и сравнить себя с этим. Например, у вас может быть соглашение об уровне обслуживания на стороне клиента для сайта: 1 секунда до «сгиба» и 3 секунды для полностью отображаемой страницы. Если вы не соблюдаете SLA производительности, вы должны засчитать это как отказ доступности для этого периода времени. Неважно, попадаете ли вы в CDN или нет - главное - это опыт пользователя.
Однако, поскольку вы проводите измерения только каждые 5 минут, кажется разумным измерять попадания в CDN по сравнению с главным сайтом отдельно и вычислять, что 75% доступности поступает из CDN, а 25% - из главного. Сложность здесь в том, что 75% - это всего лишь среднее. Чтобы точно распределить вину за определенный период времени, вам необходимо знать, когда тот или иной сайт на самом деле не ориентирован на клиента, например, во время запланированного изменения или после ручного действия при обнаружении проблемы. Вам также необходимо учитывать, что произойдет, если один из главных сайтов или CDN не работает. Получает ли клиент HTTP 500 или он просто прозрачно переключается на рабочий сайт? Многое зависит от вашего решения для балансировки нагрузки. Описанная вами метрика «наихудшего случая» кажется слишком упрощенной. Спросите себя: «Что испытывают наши клиенты?»
Что касается того, следует ли вам брать на себя «вину», когда CDN не работает: абсолютно. Если 75% ваших обращений попадают в CDN, то 75% вашего клиентского опыта зависит от них. Вы несете ответственность за обеспечение хорошего обслуживания своих клиентов, поэтому, если у CDN возникают проблемы, вам необходимо использовать свои инженерные ресурсы, чтобы доказать это и связаться с поставщиком.
Еще одна вещь, о которой следует подумать, - это то, что происходит, когда главный сайт недоступен в течение длительного периода времени. Как вы это описали, похоже, что CDN - это статическая копия контента на главном сайте. Если главный сайт не работает в течение длительного времени, сеть CDN может начать устаревать. Так что, возможно, частью вашего SLA должна быть актуальность: 1 секунда до «сгиба» и 3 секунды для полностью обработанной страницы с контентом не старше 15 минут.
Отчетность SLA должна точно отражать реальность. Если вы измеряете доступность с точки зрения пользователя, и только сервер, выполняющий измерения, испытывает проблемы, сообщение об этой проблеме в рамках вашего SLA не будет отражать пользовательский опыт.
Я понимаю, что хочу поддерживать исходную информацию на высоком уровне, возможно, всегда сообщать об этом, даже если неточно, но с примечанием, объясняющим, почему.
Если вы не можете прийти к соглашению, возможно, есть техническое решение, чтобы сделать измерительный сервер менее подверженным ошибкам.
Если информация сообщается как об отключении, а это не так, какую ценность представляет отчетность?
В моей среде мы составляем отчеты из нескольких источников. Методология внешнего мониторинга для сообщения о доступности с внешней точки зрения, а также для отчетности о нашей внутренней системе регистрации отключений, которая вводится человеком и учитывает множество факторов, которые наиболее точно отражают ситуацию.
Gomez и Keynote - это общепринятые решения для сбора упомянутых вами типов показателей. У Gomez также есть служба, которая отслеживает UX вашего конечного пользователя, получая файл javascript в стиле Google Analytics.
Pingdom хороши: http://www.pingdom.com/
Мы в списке Fortune 500 с сайтом с поддержкой CDN и используем несколько вещей. Вы правильно определили, что вам нужно измерять разные вещи, если вы хотите обнаруживать разные вещи. Мне непонятно, что именно вы хотите - номера доступности, которые помогут вам определить, когда приложение на самом деле не работает, или цифры, которые отвлекают от вас руководство. Тем не мение...
Чтобы получить "CDN из этого", вы можете взять другой монитор Keynote / Gomez и направить его на свои приложения. не через CDN с использованием альтернативного DNS-имени или еще чего-то. Но поскольку в нем все еще есть статические ресурсы, он больше полезен для производительности, чем для доступности. И он держит в курсе сбои в работе интернета, агентов и т. Д., Что подходит для одних целей и не подходит для других.
Мониторинг реального пользователя. Есть сетевые (Coradiant, Tealeaf) и теговые (Jiffy, Gomez). Мы используем Coradiant в качестве сетевого сниффера, и он определяет реальную видимую пользователем производительность ресурсов, размещенных здесь, в нашем центре обработки данных, другими словами, реальных приложений, а не всего статического мусора в CDN. Затем мы написали отчеты для определения частоты ошибок и производительности приложений и использовали Apdex (apdex.org) в качестве производной метрики. В некоторых случаях вы не можете использовать сеть (слишком много трафика или ваши активы не размещены там, где вы можете получить доступ к сети), а на основе тегов не так надежно. Имеет огромное преимущество в том, что фактически видит время отклика конечного пользователя и ошибки - легко настроить синтетический монитор, который не дает ошибок во всех случаях, как у реального пользователя.
Локальный синтетический мониторинг. Nagios / zabbix / sitescope / сотня других. Направьте монитор на свое приложение локально (не проходите через CDN). Это золотой стандарт для действенного (например, отправить страницу, чтобы кого-нибудь разбудить) мониторинга доступности. Не учитывает сетевые вещи.
Журнал мониторинга. В каком-то смысле это мониторинг реальных пользователей гетто. Но если вы действительно хотите посмотреть, что и когда было с ошибкой, это очень удобно. Имеет преимущество «нет, на самом деле это случилось» реального мониторинга пользователей. Часто только доступность, если вы не регистрируете время, затраченное на веб-уровне, и в этом случае он показывает, сколько времени заняло ваше серверное время - не полезно для пользователей, сталкивающихся с SLA, но очень полезно для того, «над каким кодом нам нужно работать. . " Используйте splunk.
Это не «либо или», мы используем все это, потому что вам нужна «история конечного пользователя», а также «на какого программиста нам нужно опираться».
BrowserMob отлично