Шукаєте рекомендацію щодо вимірювання програми з високою доступністю, яка використовує CDN

Я працюю в компанії Fortune 500, яка бореться з точним вимірюванням продуктивності та доступності для додатків із високою доступністю (тобто додатків, які на 99,5% збільшуються за 5 секунд навігації сторінки до сторінки). Ми визначаємо як запланований, так і позаплановий час простою для визначення цього числа доступності. Однак нещодавно ми додали CDN до складу суміші, що трохи ускладнює наші показники. Зараз CDN обробляє близько 75% нашого трафіку, а решту відправляє на наші власні сервери.

Ми намагаємося виміряти те, що ми називаємо "справжнім користувацьким досвідом" (тобто наші тестові сценарії імітують типового користувача, що клацає через додаток.) ​​Ці сценарії моніторингу знаходяться поза нашою мережею, а це означає, що ми вражаємо CDN приблизно 75% час.

Керівництво вирішило, що ми приймаємо найгірший сценарій для вимірювання доступності. Тож якщо у наших серверів-початківців є проблеми, але все ж CDN подає вміст просто чудово, ми все ще вражаємо наявністю. Так само і навпаки. Думаю, що, поки "досвід користувачів" буде успішним, ми не повинні зайво карати себе. Зрештою, CDN є для покращення продуктивності та доступності!

Мені просто цікаво, чи хтось знає, як інші компанії Fortune 500 обчислюють їх кількість? Я переглядаю, наприклад, apple.com, вітрину магазину, яка використовує CDN, який ніколи не здається (якщо тільки не відбудеться головне оголошення про товар.) Було б чудово мати деякі важкі фактичні дані, бо я не Не віримо, що нам потрібно зайво шкодити цим показникам. Ми є прийняття бізнес - рішень на основі цих чисел.

Я можу сказати, однак, враховуючи, що ці показники видно керівництву, проблеми вирішуються та вирішуються досить швидко (читайте: ми вирішуємо червону стрічку досить швидко.) На жаль, як розробник, я не хочу, щоб управління думало що додаток вгору або вниз, тому що деякий зовнішній фактор (тобто CDN) впливає на числа.

Думки?

(Я помилково опублікував це питання в StackOverflow, заздалегідь пробачте за перехресний пост)

В рефераті я б сказав, що вам слід чітко визначити, що є "доступним" проти "недоступним", і виміряти себе проти цього. Наприклад, у вас може бути клієнтська угода про ефективність роботи клієнта для сайту за 1 секунду до "складання" та 3 секунди для повністю відтвореної сторінки. Якщо ви не зустрічаєте угоди про рівень ефективності, ви повинні вважати це недоліком доступності для цього періоду часу. Не має значення, потрапляєте ви в CDN чи ні - важливо користувацьке враження.

Однак, оскільки ви здійснюєте вимірювання лише кожні 5 хвилин, здається, що розумно вимірювати звернення до CDN порівняно з головним сайтом окремо і обчислювати, що 75% доступності надходить від CDN і 25% від головного. Складність тут полягає в тому, що 75% - це лише середній показник. Для точного розподілу вини за певний проміжок часу потрібно знати, коли той чи інший сайт насправді не стикається з клієнтом, наприклад, під час запланованих змін або після вручну, коли виявлена ​​проблема. Вам також потрібно врахувати, що станеться, коли один з головного сайту або CDN не працює. Чи отримує клієнт HTTP 500 або він просто прозоро переходить на робочий сайт? Багато що залежить від вашого рішення щодо балансування навантаження. Описана вами метрика "найгіршого випадку" здається занадто спрощеною. Запитайте себе, "

Що стосується того, чи варто брати на себе «вину», коли CDN знижений: абсолютно. Якщо 75% ваших звернень збираються на CDN, то 75% вашого досвіду клієнтів залежить від них. Ви несете відповідальність за надання хорошого досвіду своїм клієнтам, тому, якщо у CDN виникають проблеми, вам потрібно використовувати свої інженерні ресурси, щоб довести це та проконсультуватися з постачальником.

Ще одна річ, про яку слід подумати - це те, що відбувається, коли головний сайт недоступний протягом тривалого періоду часу. Як ви вже описали це, здається, що CDN є статичною копією вмісту на майстер-сайті. Якщо основний сайт довго не працює, CDN може почати старіти. Тому, можливо, частиною вашої домовленості за угодою є свіжість: 1 секунда до "складання" та 3 секунди для повністю відтвореної сторінки, вміст якої не перевищує 15 хвилин.

Я погоджуюся з user44700, краще розділити тестування доступності для ваших серверів порівняно з CDN і відстежувати два незалежні незалежно. Вашою справжньою доступністю буде Server Avail * CDN Avail, оскільки якщо будь-який знизиться - ви вважаєте, що ваша сторінка / сайт вниз. Це також обійдеться вам дешевше з будь-яким із постачальників моніторингу.

Я б не йшов шляхом створення одного тесту браузера і не дивився на те, які елементи не вдалися, хоча це може спрацювати, і деякі компанії, такі як Catchpoint, мають поняття "доступність контенту" - це може бути не саме те, що ви хочете для цього випадку. Скажімо, наприклад, що ваша веб-сторінка має виклик CDN для файлу, що забезпечує 404, більшість моніторингових рішень скажуть вам, що це збій - але чи справді CDN не вдався? Чи був цей файл навіть важливим? можливо, хтось просто забув видалити якусь реліктову посилання, яку жоден користувач не помічає.

Ви можете прочитати цю публікацію в блозі, щоб отримати ще кілька ідей: http://blog.catchpoint.com/2010/07/21/true-available-of-a-webpage/

Звітність за угодами про угода про Угода повинна точно відображати реальність. Якщо ви вимірюєте доступність з точки зору користувача, і лише сервер, який виконує вимірювання, має проблеми, звітування про цю проблему у вашому довіреному слові не відображатиме користувачів.

Я можу зрозуміти, бажаючи привести джерельну інформацію до високого стандарту, можливо, завжди повідомляючи про неї, навіть якщо неточна, але з приміткою, яка визначає, чому.

Якщо ви не можете дійти згоди, можливо, є технічне рішення, щоб зробити вимірювальний сервер менш непрацездатним.

Якщо інформація повідомляється як відключення, а її не було, яке значення надає звітність?

У моєму середовищі ми повідомляємо з різних джерел. Методика зовнішнього моніторингу для звітування про доступність із зовнішньої точки зору, а також звітування про нашу внутрішню систему запису відключень, яка введена людиною та враховує безліч факторів, які найбільш точно відображають ситуацію.

Gomez та Keynote - це прийняті для підприємства рішення для збору типів згаданих вами показників. Також у Gomez є сервіс, який відстежує ваш UX користувач шляхом пошуку файлу JavaScript google-analytics-esque.

Pingdom хороші: http://www.pingdom.com/

Ми Fortune 500 з сайтом, що підтримує CDN, і ми використовуємо кілька речей. Ви правильно визначили, що потрібно вимірювати різні речі, якщо ви хочете виявити різні речі. Мені незрозуміло, що ви конкретно хочете - номери доступності, які допоможуть вам визначити, коли програма насправді не працює, або номери, які отримують управління від спини. Все одно ...

1. Зовнішній синтетичний моніторинг - Основна / Гомес / Вебметрія. Раніше ми використовували Keynote, зараз ми використовуємо Gomez. Звичайно, як ви зазначаєте, це також включає CDN та будь-які інші зовнішні компоненти - що добре вимірювати загальний рівень дозволу на обслуговування, але не настільки добре, щоб визначити домовленості про домовленість ваших програм.

Щоб вимкнути "CDN з нього", ви можете взяти інший монітор Keynote / Gomez і вказати на ваші програми не через CDN, використовуючи альтернативне ім'я DNS або щось інше. Але оскільки він все ще має статичні активи, він більш корисний для продуктивності, ніж доступність. І він зберігає відключення в Інтернеті, відключення агентів тощо у циклі, що підходить для одних цілей, а не для інших.

2. Реальний моніторинг користувачів. Існує мережа (Coradiant, Tealeaf) та теги (Jiffy, Gomez). Ми використовуємо Coradiant як мережевий снайпер, і він визначає реальну ефективність активів, розміщених тут, в нашому центрі обробки даних, інакше кажучи, фактичні програми та не всі статичні сміття на CDN. Потім ми писали звіти, щоб визначити показник помилок і ефективності програми та використовували Apdex (apdex.org) як похідний показник. У деяких випадках ви не можете користуватися мережею (занадто великий трафік, або ваші активи не розміщуються там, де можна потрапити в мережу), а теги на базі не є надійними. Має величезну користь від фактичного перегляду часу та помилок кінцевого користувача - легко налаштувати синтетичний монітор, який не помиляється у всіх випадках, які робить реальний користувач.

3. Місцевий синтетичний моніторинг. Nagios / zabbix / sitescope / сотня інших. Наведіть монітор на свою програму локально (не проходьте CDN). Для моніторингу доступності (наприклад, надіслати сторінку, щоб когось розбудити), це золотий стандарт. Не враховує інформацію про мережу.

4. Моніторинг журналу. У певному сенсі це моніторинг реальних користувачів гетто. Але якщо ви дійсно просто хочете побачити, що помиляється, коли, це досить зручно. Чи має перевагу "немає насправді того, що трапилося" реального моніторингу користувачів. Часто лише доступність, якщо ви не реєструєте час на веб-ярусі, і в цьому випадку він показує, скільки часу зайняв ваш сервер - не корисно для користувачів, що стикаються з угодами про обслуговування, але дуже корисно для "над яким кодом нам потрібно працювати . " Використовуйте сплюнк.

Це не те, або ми використовуємо все це, тому що ви хочете "історію кінцевого користувача", а також "якого програміста нам потрібно спиратися".

BrowserMob чудовий