ค้นหาคำแนะนำในการวัดแอปที่มีความพร้อมใช้งานสูงที่ใช้ CDN

ฉันทำงานกับ บริษัท ที่ติดอันดับ Fortune 500 ที่ต่อสู้กับการวัดประสิทธิภาพและความพร้อมใช้งานอย่างแม่นยำสำหรับแอปพลิเคชันที่มีความพร้อมใช้งานสูง (เช่นแอปที่เพิ่มขึ้น 99.5% พร้อมการนำทางหน้า 5 วินาที) เราคำนึงถึงการหยุดทำงานทั้งที่กำหนดและไม่ได้กำหนดไว้เพื่อกำหนดหมายเลขความพร้อมใช้งานนี้ อย่างไรก็ตามเมื่อเร็ว ๆ นี้เราได้เพิ่ม CDN ลงในส่วนผสมซึ่งการวัดของเราค่อนข้างซับซ้อนเล็กน้อย ขณะนี้ CDN จัดการปริมาณการใช้งานของเราประมาณ 75% ในขณะที่ส่งส่วนที่เหลือไปยังเซิร์ฟเวอร์ของเราเอง

เราพยายามวัดสิ่งที่เราเรียกว่า "ประสบการณ์ผู้ใช้ที่แท้จริง" (เช่นสคริปต์ทดสอบของเราเลียนแบบผู้ใช้ทั่วไปที่คลิกผ่านแอปพลิเคชัน) สคริปต์ตรวจสอบเหล่านี้อยู่นอกเครือข่ายของเราซึ่งหมายความว่าเรากด CDN ประมาณ 75% เวลา.

ฝ่ายบริหารได้ตัดสินใจว่าเราใช้สถานการณ์กรณีที่เลวร้ายที่สุดในการวัดความพร้อมใช้งาน ดังนั้นหากเซิร์ฟเวอร์ต้นทางของเรามีปัญหา แต่ถึงกระนั้น CDN ก็ให้บริการเนื้อหาได้ดีเรายังคงมีความพร้อมอยู่ เช่นเดียวกับที่เป็นจริงวิธีอื่น ๆ ความคิดของฉันคือตราบใดที่ "ประสบการณ์ผู้ใช้" สำเร็จเราไม่ควรลงโทษตัวเองโดยไม่จำเป็น ท้ายที่สุด CDN ก็อยู่ที่นั่นเพื่อปรับปรุงประสิทธิภาพและความพร้อมใช้งาน!

ฉันแค่สงสัยว่าถ้าใครมีความรู้เกี่ยวกับวิธีการที่ บริษัท อื่น ๆ ใน Fortune 500 คำนวณตัวเลขความพร้อมใช้งานของพวกเขา? ยกตัวอย่างเช่นฉันดู apple.com ของหน้าร้านที่ใช้ CDN ที่ดูเหมือนจะไม่ลง (เว้นแต่จะมีการประกาศผลิตภัณฑ์ที่สำคัญ) มันจะดีมากถ้ามีข้อมูลที่เป็นเรื่องยากเพราะฉันไม่ เชื่อว่าเราจะต้องทำร้ายตัวเองโดยไม่จำเป็นจากการวัดเหล่านี้ เรากำลังตัดสินใจทางธุรกิจตามตัวเลขเหล่านี้

อย่างไรก็ตามฉันสามารถพูดได้ว่าการจัดการเหล่านี้สามารถมองเห็นปัญหาได้รับการแก้ไขและแก้ไขได้อย่างรวดเร็ว (อ่าน: เราตัดผ่านเทปสีแดงได้อย่างรวดเร็ว) โชคไม่ดีในฐานะนักพัฒนาฉันไม่ต้องการให้ผู้บริหารคิด แอปพลิเคชันขึ้นหรือลงเนื่องจากปัจจัยภายนอกบางอย่าง (เช่น CDN) มีอิทธิพลต่อตัวเลข

คิด?

(ฉันโพสต์คำถามนี้ผิดกับ StackOverflow ขออภัยล่วงหน้าสำหรับการข้ามโพสต์)

ในนามธรรมฉันจะบอกว่าคุณควรกำหนดสิ่งที่ถือว่า "พร้อมใช้งาน" กับ "ไม่พร้อมใช้งาน" และวัดด้วยตนเอง ตัวอย่างเช่นคุณอาจมี SLA ประสิทธิภาพฝั่งไคลเอ็นต์สำหรับไซต์ 1 วินาทีถึง "fold" และ 3 วินาทีสำหรับหน้าที่แสดงผลอย่างสมบูรณ์ เมื่อคุณไม่ตรงตาม SLA ประสิทธิภาพคุณควรนับว่าเป็นความล้มเหลวที่มีประโยชน์ในช่วงเวลานั้น ไม่สำคัญว่าคุณกำลังกดปุ่ม CDN หรือไม่ - ประสบการณ์ของผู้ใช้เป็นสิ่งที่สำคัญ

อย่างไรก็ตามเนื่องจากคุณทำการวัดทุก ๆ 5 นาทีจึงมีความสมเหตุสมผลที่จะวัดจำนวนการเข้าชม CDN เทียบกับไซต์หลักแยกต่างหากและคำนวณว่า 75% ของความพร้อมใช้งานมาจาก CDN และ 25% จากต้นแบบ ความยากของที่นี่คือ 75% เป็นเพียงค่าเฉลี่ย หากต้องการแบ่งปันความผิดอย่างถูกต้องในช่วงเวลาที่กำหนดคุณจำเป็นต้องรู้เมื่อไซต์หนึ่งหรือไซต์อื่นไม่ได้รับการติดต่อจากลูกค้าเช่นระหว่างการเปลี่ยนแปลงตามแผนที่วางไว้หรือหลังจากดำเนินการด้วยตนเองเมื่อตรวจพบปัญหา คุณต้องคำนึงถึงสิ่งที่เกิดขึ้นเมื่อหนึ่งในเว็บไซต์หลักหรือ CDN หยุดทำงาน ลูกค้าได้รับ HTTP 500 หรือไม่หรือไม่พวกเขาเพียงแค่ผ่านไปยังไซต์ที่ทำงานอย่างโปร่งใสหรือไม่ มากขึ้นอยู่กับการแก้ปัญหาภาระสมดุลของคุณ เมตริก "กรณีที่แย่ที่สุด" ที่คุณอธิบายดูเหมือนง่ายเกินไป ถามตัวเอง, "

เท่าที่คุณควรจะ "ตำหนิ" เมื่อ CDN หยุดทำงาน: แน่นอน หาก 75% ของเพลงยอดฮิตของคุณกำลังไปที่ CDN แสดงว่า 75% ของประสบการณ์ลูกค้าของคุณนั้นขึ้นอยู่กับพวกเขา คุณเป็นผู้รับผิดชอบในการมอบประสบการณ์ที่ดีให้กับลูกค้าของคุณดังนั้นหาก CDN กำลังประสบปัญหาคุณต้องใช้ทรัพยากรด้านวิศวกรรมของคุณเพื่อพิสูจน์และติดตามกับผู้ให้บริการ

อีกสิ่งหนึ่งที่ควรคำนึงถึงคือเกิดอะไรขึ้นเมื่อไซต์ต้นแบบไม่พร้อมใช้งานเป็นระยะเวลานาน ตามที่คุณอธิบายไว้ดูเหมือนว่า CDN เป็นสำเนาคงที่ของเนื้อหาบนไซต์ต้นแบบ หากไซต์ต้นแบบหยุดทำงานเป็นเวลานาน CDN อาจเริ่มค้างได้ ดังนั้นบางส่วนของ SLA ของคุณควรมีความสดใหม่: 1 วินาทีกับ "fold" และ 3 วินาทีสำหรับหน้าเว็บที่แสดงผลอย่างสมบูรณ์โดยมีเนื้อหาไม่เกิน 15 นาที

ฉันเห็นด้วยกับ user44700 จะเป็นการดีกว่าที่จะแยกการทดสอบความพร้อมใช้งานสำหรับเซิร์ฟเวอร์ของคุณกับ CDN และติดตามทั้งสองอย่างอิสระ ความพร้อมใช้งานที่แท้จริงของคุณคือ Server Avail * CDN Avail เนื่องจากหากทั้งสองล่ม - คุณกำลังพิจารณาว่าหน้า / ไซต์ของคุณไม่ทำงาน สิ่งนี้จะทำให้คุณเสียค่าใช้จ่ายน้อยลงด้วยผู้ขายที่มีการตรวจสอบ

ฉันจะไม่ไปเส้นทางของการสร้างการทดสอบเบราว์เซอร์เดียวและดูว่ารายการใดล้มเหลวในขณะที่มันสามารถใช้งานได้และบาง บริษัท เช่น Catchpoint มีแนวคิด "ความพร้อมใช้งานของเนื้อหา" - อาจไม่ตรงกับที่คุณต้องการสำหรับกรณีนี้ ยกตัวอย่างเช่นหน้าเว็บของคุณมีการเรียกไปยัง CDN สำหรับไฟล์ที่ส่งมอบ 404 โซลูชันการตรวจสอบส่วนใหญ่จะบอกคุณว่านี่เป็นความล้มเหลว แต่จริงๆแล้วมันเป็น CDN ที่ล้มเหลวหรือไม่ ไฟล์นั้นสำคัญหรือไม่ บางทีบางคนแค่ลืมที่จะลบการอ้างอิงที่ระลึกบางอย่างที่ไม่มีผู้ใช้ประกาศ

คุณสามารถอ่านโพสต์บล็อกนี้สำหรับแนวคิดเพิ่มเติม: http://blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

การรายงาน SLA ควรสะท้อนความเป็นจริงอย่างถูกต้อง หากคุณกำลังวัดความพร้อมใช้งานจากมุมมองของผู้ใช้และมีเพียงเซิร์ฟเวอร์ที่ทำการวัดเท่านั้นที่ประสบปัญหาการรายงานปัญหาภายใน SLA ของคุณจะไม่สะท้อนประสบการณ์การใช้งานของผู้ใช้

ฉันสามารถเข้าใจได้ว่าต้องการเก็บข้อมูลต้นฉบับไว้ในระดับสูงบางทีอาจรายงานเสมอแม้ว่าจะไม่ถูกต้อง แต่มีบันทึกระบุสาเหตุ

หากคุณไม่สามารถตกลงกันได้อาจมีวิธีแก้ปัญหาทางเทคนิคเพื่อทำให้เซิร์ฟเวอร์การวัดมีความผิดพลาดน้อยลง

หากข้อมูลถูกรายงานว่าเป็นเหตุขัดข้องและไม่เป็นไปตามที่รายงานนั้นให้คุณค่าอะไร

ในสภาพแวดล้อมของฉันเรารายงานจากหลายแหล่ง วิธีการตรวจสอบภายนอกเพื่อรายงานความพร้อมใช้งานจากมุมมองภายนอกเช่นเดียวกับการรายงานระบบบันทึกการดับภายในของเราซึ่งเป็นมนุษย์เข้ามาและพิจารณาปัจจัยหลายอย่างที่สะท้อนสถานการณ์ได้อย่างแม่นยำที่สุด

Gomez และ Keynote เป็นโซลูชันที่ได้รับการยอมรับจากองค์กรสำหรับการรวบรวมประเภทของการวัดที่คุณกล่าวถึง Gomez ยังมีบริการที่ตรวจสอบ enduser UX ของคุณด้วยการจัดหาไฟล์จาวาสคริปต์ google-analytics-esque

Pingdom นั้นดี: http://www.pingdom.com/

เราเป็น Fortune 500 ที่มีไซต์ที่เปิดใช้งาน CDN และเราใช้หลายสิ่ง คุณได้กำหนดไว้อย่างถูกต้องแล้วว่าคุณต้องวัดสิ่งต่าง ๆ หากคุณต้องการตรวจจับสิ่งต่าง ๆ ฉันยังไม่ชัดเจนในสิ่งที่คุณต้องการโดยเฉพาะ - หมายเลขความพร้อมใช้งานเพื่อช่วยคุณกำหนดว่าเมื่อใดที่แอพหยุดทำงานจริงหรือตัวเลขที่ทำให้คุณไม่สามารถจัดการได้ อย่างไรก็ตาม...

1. การตรวจสอบสังเคราะห์ภายนอก - Keynote / Gomez / Webmetrics เราเคยใช้ Keynote ตอนนี้เราใช้ Gomez แน่นอนว่าเมื่อคุณทราบสิ่งนี้ยังรวมถึง CDN และส่วนประกอบภายนอกอื่น ๆ - ซึ่งเป็นสิ่งที่ดีในการวัด SLA โดยรวมของคุณ แต่ไม่ดีนักในการกำหนด SLA ของแอปพลิเคชันของคุณ

ในการรับ "CDN ออกมา" คุณสามารถใช้จอภาพ Keynote / Gomez อื่นและชี้ไปที่แอพของคุณไม่ผ่าน CDN โดยใช้ชื่อ DNS สำรองหรืออะไรก็ได้ แต่เนื่องจากยังคงมีสินทรัพย์แบบคงที่จึงมีประโยชน์สำหรับประสิทธิภาพมากกว่าความพร้อมใช้งาน และมันทำให้อินเทอร์เน็ตเกิดการขัดข้องดับตัวแทนและอื่น ๆ ในลูปซึ่งเหมาะสำหรับวัตถุประสงค์บางอย่างและไม่ใช่อื่น ๆ

2. การตรวจสอบผู้ใช้จริง มีเครือข่าย (Coradiant, Tealeaf) และแท็กตาม (Jiffy, Gomez) เราใช้ Coradiant เป็นเครือข่ายดมกลิ่นและกำหนดประสิทธิภาพที่ผู้ใช้เห็นจริงของสินทรัพย์ที่โฮสต์ที่นี่ที่ศูนย์ข้อมูลของเรา - กล่าวอีกนัยหนึ่งคือแอปพลิเคชันจริงไม่ใช่ขยะแบบคงที่ทั้งหมดใน CDN จากนั้นเราเขียนรายงานเพื่อกำหนดอัตราข้อผิดพลาดและประสิทธิภาพของแอปและใช้ Apdex (apdex.org) เป็นตัวชี้วัดที่ได้รับ ในบางกรณีคุณไม่สามารถใช้เครือข่ายได้ (การรับส่งข้อมูลมากเกินไปหรือสินทรัพย์ของคุณไม่ได้โฮสต์ที่คุณสามารถเข้าใช้เครือข่ายได้) และการใช้แท็กนั้นไม่น่าเชื่อถือ มีประโยชน์อย่างมากในการเห็นเวลาตอบสนองและข้อผิดพลาดของผู้ใช้จริง - ง่ายต่อการตั้งค่าจอภาพสังเคราะห์ที่ไม่เกิดข้อผิดพลาดในทุกกรณีที่ผู้ใช้จริงทำ

3. การตรวจสอบสังเคราะห์ท้องถิ่น Nagios / zabbix / sitescope / a ร้อยคนอื่น ๆ หันจอภาพไปที่แอปของคุณในเครื่อง (อย่าไปที่ CDN) สำหรับการดำเนินการ (เช่นส่งหน้าเพื่อปลุกบางคน) การตรวจสอบความพร้อมนี่คือมาตรฐานทองคำ ไม่คำนึงถึงสิ่งต่างๆในเครือข่ายบัญชี

4. การตรวจสอบบันทึก เรียกอีกอย่างว่านี่คือสลัมผู้ใช้งานจริง แต่ถ้าคุณอยากเห็นสิ่งที่ผิดพลาดจริง ๆ มันมีประโยชน์มาก มีประโยชน์ "ไม่จริงที่เกิดขึ้น" ในการตรวจสอบผู้ใช้จริง บ่อยครั้งที่มีความพร้อมเท่านั้นเว้นแต่คุณจะเข้าสู่ระบบที่ใช้เวลาในชั้นเว็บซึ่งในกรณีนี้จะแสดงให้คุณเห็นว่าเซิร์ฟเวอร์ของคุณใช้เวลานานแค่ไหน - ไม่เป็นประโยชน์สำหรับผู้ใช้ที่กำลังเผชิญ SLA แต่มีประโยชน์มากสำหรับ ." ใช้ความกล้าหาญ

มันไม่ได้เป็นอย่างใดอย่างหนึ่งหรือเราใช้สิ่งเหล่านี้เพราะคุณต้องการ "เรื่องราวของผู้ใช้ปลายทาง" เช่นเดียวกับ "สิ่งที่โปรแกรมเมอร์เราต้องพึ่งพา"

BrowserMobยอดเยี่ยม