เมื่อคุณตรวจสอบเว็บไซต์ของคุณจากที่เดียว คุณกำลังทดสอบของคุณการเชื่อมต่อไปยังเซิร์ฟเวอร์ของคุณ นั่นไม่ได้บอกคุณเกี่ยวกับประสบการณ์ของผู้ใช้ในสิงคโปร์ เซาเปาโล หรือสตอกโฮล์ม หากต้องการตรวจสอบเว็บไซต์จากหลายตำแหน่งเป็นวิธีเดียวที่จะดูภาพทั้งหมดได้
ถ้ามันขึ้นอยู่กับคุณแต่ลงสำหรับพวกเขา มันจะขึ้นจริงไหม?
คุณได้สร้างผลิตภัณฑ์ SaaS กับลูกค้าใน 15 ประเทศ ธุรกิจกำลังเติบโต การตรวจสอบสถานะการออนไลน์ของคุณบอกว่า 99.9% ทุกอย่างดูดี
ลูกค้าในมุมไบส่งอีเมลถึง: "ฉันไม่สามารถเข้าถึงบัญชีของฉันได้เป็นเวลาสองวันแล้ว" ผู้มีโอกาสเป็นลูกค้าในเบอร์ลินทวีต: "ลองใช้การสาธิตของคุณแต่ไซต์ไม่เคยโหลดเลย" ทีมงานของคุณในซานฟรานซิสโกตรวจสอบไซต์ — ทำงานได้อย่างสมบูรณ์แบบ
คุณเจาะลึกการตรวจสอบของคุณ สีเขียวทั้งหมด ไม่มีการแจ้งเตือน คุณตรวจสอบบันทึกเซิร์ฟเวอร์ของคุณ — ไม่มีข้อผิดพลาด แดชบอร์ด CDN ของคุณบอกว่า Edge ทั้งหมดใช้งานได้ ไม่มีเหตุการณ์ที่ต้องตรวจสอบ เพราะตามเครื่องมือของคุณ ไม่มีอะไรเกิดขึ้น
แต่มีบางอย่างเกิดขึ้น เว็บไซต์ของคุณไม่สามารถเข้าถึงได้ในบางภูมิภาค — และคุณไม่สามารถมองเห็นได้
นี่คือเหตุผลที่คุณต้องตรวจสอบเว็บไซต์ของคุณจากหลาย ๆ ที่ ไม่ใช่เพียงแห่งเดียว อินเทอร์เน็ตมีลักษณะแตกต่างกันไปขึ้นอยู่กับตำแหน่งที่คุณยืนอยู่
อินเทอร์เน็ตไม่ใช่เสาหิน มันเป็นเครือข่ายนับพันเครือข่าย — และเส้นทางจากอุปกรณ์ของผู้ใช้ไปยังเซิร์ฟเวอร์ของคุณจะเปลี่ยนไปตามตำแหน่งที่พวกเขาอยู่
DNS มีการกระจาย เมื่อผู้ใช้ในจาการ์ตาสอบถามโดเมนของคุณ พวกเขาจะไม่เข้าถึงเซิร์ฟเวอร์ DNS เดียวกันกับผู้ใช้ในชิคาโก หากโหนด anycast ของผู้ให้บริการ DNS ของคุณในเอเชียตะวันออกเฉียงใต้ได้รับการกำหนดค่าไม่ถูกต้องหรือล่ม ผู้ใช้ในภูมิภาคนั้นจะได้รับข้อผิดพลาด NXDOMAIN ในขณะที่ส่วนที่เหลือของโลกทำงานได้ดี
สถานการณ์จริง: Singapore PoP ของผู้ให้บริการ DNS ให้บริการบันทึกเก่าเป็นเวลา 4 ชั่วโมง ผู้ใช้ในเอเชียตะวันออกเฉียงใต้ไม่สามารถเข้าถึงเว็บไซต์ของคุณ การติดตามของคุณในเวอร์จิเนียไม่เห็นมีอะไรผิดปกติ
BGP กำหนดวิธีที่แพ็กเก็ตเดินทางผ่านอินเทอร์เน็ต การประกาศเส้นทางที่กำหนดค่าไม่ถูกต้องสามารถส่งการจราจรบนทางอ้อมที่ไร้สาระหรือเข้าไปในหลุมดำได้ ปัญหาการกำหนดเส้นทางเหล่านี้มักเป็นปัญหาเฉพาะภูมิภาค การเข้าชมจากบราซิลอาจทำงานได้อย่างสมบูรณ์ในขณะที่การเข้าชมจากอาร์เจนตินาลดลง
สถานการณ์จริง: ISP ในละตินอเมริกาประกาศเส้นทางที่ไม่ดี เว็บไซต์ของคุณไม่สามารถเข้าถึงได้สำหรับผู้ใช้ 3 ล้านคน การตรวจสอบตามสหรัฐอเมริกาของคุณแสดงเวลาทำงาน 100%
CDN ของคุณมีตำแหน่ง Edge 200 แห่ง แต่ละจุดเป็นจุดล้มเหลวที่เป็นอิสระ ขอบในซิดนีย์อาจให้บริการเนื้อหาที่เสียหาย Edge ในแฟรงค์เฟิร์ตอาจมีใบรับรองที่หมดอายุ หน้าสถานะ CDN ระบุว่า "ระบบปฏิบัติการทั้งหมด" เนื่องจากประสิทธิภาพโดยรวมนั้นดี — ผู้ใช้ของคุณในภูมิภาคเหล่านั้นไม่เห็นด้วย
สถานการณ์จริง: CDN edge ในมุมไบส่งคืน 503 เป็นเวลา 6 ชั่วโมง ขอบอื่นๆทำงานได้อย่างสมบูรณ์แบบ หากคุณตรวจสอบจากสหรัฐอเมริกาเท่านั้น คุณจะไม่เห็นอะไรเลย
ISP บางรายมีการเพียร์ที่ไม่ดีกับผู้ให้บริการโฮสติ้งหรือช่วง IP บางราย จุดเชื่อมต่อที่หนาแน่นสามารถเปลี่ยนเว็บไซต์ที่รวดเร็วให้กลายเป็นเว็บไซต์ที่ใช้งานไม่ได้สำหรับผู้ใช้หลายล้านคนบน ISP นั้น ในขณะที่ผู้ใช้บนเครือข่ายอื่นในเมืองเดียวกันก็ไม่มีปัญหา
สถานการณ์จริง: ISP รายใหญ่ของอินโดนีเซียควบคุมการรับส่งข้อมูลไปยังช่วง IP ของ AWS ในช่วงชั่วโมงเร่งด่วน ผู้ใช้พบการโหลดหน้าเว็บ 15 วินาที ผู้ใช้บน ISP อื่นโหลดใน 800ms
เธรดทั่วไป: ความล้มเหลวทั้งหมดเหล่านี้เกิดขึ้นเฉพาะสถานที่ สิ่งเหล่านี้จะไม่ส่งผลกระทบต่อเซิร์ฟเวอร์ต้นทางของคุณ พวกมันจะไม่แสดงใน APM ของคุณ สิ่งเหล่านี้จะมองไม่เห็นจากที่ที่คุณนั่งอยู่ — เว้นแต่ว่าคุณจะคอยติดตามเว็บไซต์ของคุณจากหลาย ๆ ที่ทั่วโลก
ไม่ใช่ว่าการตรวจสอบปัจจุบันของคุณเสียหาย มันถูกออกแบบมาสำหรับปัญหาที่ง่ายกว่า
บริการตรวจสอบส่วนใหญ่มีสถานที่ตั้ง 5–15 แห่ง ซึ่งมีน้ำหนักมากไปยังสหรัฐอเมริกาและยุโรปตะวันตก หากผู้ใช้ของคุณครอบคลุมละตินอเมริกา เอเชียตะวันออกเฉียงใต้ แอฟริกา หรือยุโรปตะวันออก การมอนิเตอร์ของคุณมีจุดบอดที่สำคัญ
ตรวจสอบจาก AWS us-east-1 ไปยังเซิร์ฟเวอร์ AWS us-west-2 ทดสอบผู้ให้บริการคลาวด์แบบเพียร์ ไม่ใช่เส้นทางเครือข่ายในโลกแห่งความเป็นจริง การเชื่อมต่อระหว่างกันบนคลาวด์นั้นรวดเร็วและเชื่อถือได้ การเชื่อมต่อ ISP ของผู้ใช้ของคุณไม่ใช่
การรู้ว่า "ไซต์ดังกล่าวหยุดให้บริการจากสิงคโปร์" ไม่สามารถดำเนินการได้ มันเป็น DNS หรือไม่? หมดเวลาการจับมือ TCP? TLS ล้มเหลวใช่ไหม TTFB ขัดขวาง? หากไม่มีรายละเอียดเวลาในการตอบสนองและข้อมูลการติดตาม คุณจะไม่สามารถวินิจฉัยสาเหตุที่แท้จริงได้
โดยทั่วไปการตรวจสอบแบบกระจายระดับองค์กรจะมีราคา 200–500 ดอลลาร์สหรัฐฯ ต่อเดือน สำหรับสตาร์ทอัพและธุรกิจขนาดเล็ก นั่นเป็นค่าใช้จ่ายจำนวนมาก ทีมต่างประนีประนอมกับเครื่องมือราคาถูกกว่าซึ่งมีพื้นที่น้อยกว่า และหวังว่าจะได้สิ่งที่ดีที่สุด
เมื่อคุณตรวจสอบเว็บไซต์จากหลายตำแหน่ง — 50, 70 หรือมากกว่า — คุณจะลดจุดบอดของคุณได้อย่างมาก คุณไปจากการหวังว่าจะไม่มีปัญหาในภูมิภาคที่เปิดเผยไปสู่การรู้อย่างแท้จริง
ปัญหาความพร้อมใช้งานในภูมิภาคมีค่าใช้จ่ายจริง แม้ว่าแดชบอร์ดของคุณจะแสดงเป็นสีเขียวก็ตาม
ผู้ใช้ที่ไม่สามารถโหลดไซต์ของคุณได้ไม่ต้องยื่นตั๋วสนับสนุน — พวกเขาหาทางเลือกอื่น การหยุดทำงานในระดับภูมิภาคที่กินเวลาไม่กี่ชั่วโมงทำให้ผู้เข้าชมที่ไม่เคยปรากฏในการวิเคราะห์ของคุณต้องเสียค่าใช้จ่าย เนื่องจากไม่สามารถโหลด JavaScript ของคุณได้ คุณจะไม่มีวันรู้ว่าพวกมันมีอยู่จริง
หน้าลงทะเบียนของคุณหมดเวลาในบราซิล การชำระเงินของคุณล้มเหลวในอินเดีย สิ่งเหล่านี้ไม่ใช่ "กรณีขอบ" - บราซิลและอินเดียมีประชากรอินเทอร์เน็ตจำนวนมาก หากคุณไม่ได้ตรวจสอบเว็บไซต์ของคุณจากหลายสถานที่ในภูมิภาคเหล่านี้ คุณกำลังสูญเสียรายได้ที่คุณไม่สามารถวัดเป็นจำนวนได้
Google รวบรวมข้อมูลจากที่ตั้งทางภูมิศาสตร์หลายแห่ง หาก Googlebot ไม่สามารถเข้าถึงเว็บไซต์ของคุณจากบางภูมิภาค หน้าเหล่านั้นจะถูกยกเลิกการจัดทำดัชนี คะแนน Core Web Vitals ลดลงในภูมิภาคที่มีเวลาในการตอบสนองสูง อันดับตก — และคุณจะไม่รู้ว่าทำไมจนกว่าปริมาณการเข้าชมทั่วไปจะลดลงแล้ว
"บริการของพวกเขาไม่เคยทำงานจากที่นี่" นั่นคือสิ่งที่มีการพูดถึงใน Reddit, Twitter และฟอรัมอุตสาหกรรม เมื่อผลิตภัณฑ์ของคุณได้รับชื่อเสียงว่าไม่น่าเชื่อถือในบางภูมิภาค การกลับการรับรู้นั้นจะใช้เวลาหลายเดือน แม้ว่าคุณจะแก้ไขปัญหาพื้นฐานแล้วก็ตาม
การตรวจสอบหลายสถานที่อย่างมีประสิทธิภาพต้องใช้เสาหลัก 3 ประการ ได้แก่ ความครอบคลุม ความลึกของการวินิจฉัย และการรับรู้ถึงแนวโน้ม
ครอบคลุมทุกทวีปที่สำคัญ รวมสถานที่ที่ผู้ใช้ของคุณอยู่จริงๆ ไม่ใช่แค่เมืองระดับ 1 เท่านั้น โตเกียว สิงคโปร์ ซิดนีย์ มุมไบ แฟรงก์เฟิร์ต เซาเปาโล โจฮันเนสเบิร์ก ตำแหน่งเพิ่มเติมแต่ละแห่งจะช่วยลดความครอบคลุมของจุดบอดของคุณ
ตำแหน่งมากขึ้น = ความประหลาดใจน้อยลงจากอีเมลลูกค้าที่ไม่พอใจ
วัดทุกเฟส: ความละเอียด DNS, TCP handshake, การเจรจา TLS, เวลาเป็นไบต์แรก, การถ่ายโอนเนื้อหา เมื่อบางสิ่งช้าหรือล้มเหลว คุณจำเป็นต้องรู้ว่าเฟสใดที่รับผิดชอบ ไม่เช่นนั้น คุณจะแก้ไขจุดบกพร่องแบบสุ่มสี่สุ่มห้า
"มันช้า" ไม่สามารถดำเนินการได้ "450ms DNS จากโตเกียว" คือ
Traceroute จะแสดงให้คุณชัดเจนว่าฮอปเครือข่ายใดที่เพิ่มเวลาแฝงหรือปล่อยแพ็กเก็ต ข้อมูลประวัติช่วยให้คุณเปรียบเทียบประสิทธิภาพปัจจุบันกับเส้นพื้นฐานได้ พวกเขาจะบอกคุณว่ามีบางสิ่งที่พังใหม่หรือด้อยประสิทธิภาพมาโดยตลอด
การยกระดับตามหลักฐานจะได้รับการตอบกลับเร็วขึ้นจากผู้ให้บริการ
ไม่ว่าคุณจะใช้บริการที่มีการจัดการหรือสร้างขึ้นเอง สิ่งเหล่านี้ล้วนเป็นพื้นฐาน
ตรวจสอบ Google Analytics, การวิเคราะห์ Cloudflare หรือบันทึกการเข้าถึงเซิร์ฟเวอร์เพื่อดูว่าประเทศและเมืองใดที่ขับเคลื่อนการรับส่งข้อมูล ตำแหน่งการตรวจสอบของคุณควรตรงกับภูมิศาสตร์ของผู้ใช้ของคุณ — การตรวจสอบจากแฟรงก์เฟิร์ตไม่ได้ช่วยอะไรหากผู้ใช้ของคุณอยู่ในมะนิลา
สถานที่น้อยกว่า 50 แห่งทำให้เกิดช่องว่างที่สำคัญ รับประกันความครอบคลุมในภูมิภาคที่ด้อยโอกาส: เอเชียตะวันออกเฉียงใต้ ละตินอเมริกา แอฟริกา ยุโรปตะวันออก และโอเชียเนีย สิ่งเหล่านี้มักเป็นปัญหาที่ซ่อนอยู่โดยตรวจไม่พบ
ตรวจสอบหน้าลงทะเบียน ขั้นตอนการชำระเงิน จุดสิ้นสุดการเข้าสู่ระบบ และเส้นทาง API ที่สำคัญ หน้าแรกที่ใช้งานไม่ได้จะไม่มีประโยชน์อะไรหากผู้ใช้ของคุณไม่สามารถดำเนินการซื้อให้เสร็จสิ้นหรือลงชื่อเข้าใช้บัญชีของตนได้
กำหนดค่าเวลา DNS, TCP, TLS และ TTFB ตั้งค่า Traceroute และ MTR เมื่อคุณต้องการวินิจฉัยปัญหาเกี่ยวกับเส้นทาง หากไม่มีข้อมูลนี้ คุณจะรู้ว่ามีบางอย่างผิดปกติแต่ไม่ใช่สิ่งที่ต้องแก้ไข
อย่าเพิ่งแจ้งเตือนเมื่อไฟฟ้าขัดข้องทั่วโลก รับการแจ้งเตือนเมื่อภูมิภาคใดภูมิภาคหนึ่งเกินเกณฑ์เวลาแฝงหรือความพร้อมใช้งานลดลง แม้ว่าพื้นที่อื่นๆ ในโลกจะปกติดีก็ตาม ความเสื่อมโทรมของภูมิภาคมักเป็นสาเหตุของปัญหาที่ใหญ่กว่า
"250ms จากสิงคโปร์ดีหรือไม่ดี" คุณจะรู้ก็ต่อเมื่อคุณมีบริบททางประวัติศาสตร์เท่านั้น สร้างประสิทธิภาพพื้นฐานสำหรับแต่ละภูมิภาค ระวังการเสื่อมสภาพอย่างค่อยเป็นค่อยไป ปัญหาที่พัฒนาอย่างช้าๆ มักจะพลาดได้ง่ายจนกระทั่งกลายเป็นปัญหาขัดข้อง
ใช้เวลา 10 นาทีในแต่ละสัปดาห์เพื่อทบทวนผลงานระดับภูมิภาค มองหาภูมิภาคที่มีเวลาแฝงสูงกว่าหรือมีความพร้อมใช้งานต่ำกว่าอย่างสม่ำเสมอ รูปแบบเหล่านี้เผยให้เห็นปัญหาที่การแจ้งเตือนแบบเรียลไทม์อาจพลาดไป
เมื่อคุณติดต่อ CDN ผู้ให้บริการโฮสติ้ง หรือบริการ DNS เกี่ยวกับปัญหาระดับภูมิภาค ให้นำข้อมูลการติดตาม การแบ่งเวลา และแผนภูมิประวัติมาด้วย "ผู้ใช้ในบราซิลกำลังบ่น" ถูกไล่ออก "นี่คือ Traceroute 7 วันที่แสดง 400 มิลลิวินาทีที่ขอบเซาเปาโลของคุณ" ได้รับความสนใจ
Latency Global ถูกสร้างขึ้นโดยเฉพาะเพื่อตรวจสอบเว็บไซต์จากหลายแห่งทั่วโลก เราดำเนินการตรวจสอบจาก มากกว่า 70 แห่งทั่ว 6 ทวีป — ครอบคลุมภูมิภาคที่บริการตรวจสอบติดตามส่วนใหญ่เพิกเฉย: เอเชียตะวันออกเฉียงใต้ ละตินอเมริกา แอฟริกา ตะวันออกกลาง และยุโรปตะวันออก
การตรวจสอบทุกครั้งจะมีการแจกแจงเวลาแฝงแบบเต็ม: DNS, TCP, TLS, TTFB คุณสามารถเรียกใช้ Traceroute และ MTR ตามความต้องการจากตำแหน่งใดก็ได้เพื่อวินิจฉัยปัญหาการกำหนดเส้นทาง ข้อมูลประวัติช่วยให้คุณเปรียบเทียบประสิทธิภาพปัจจุบันกับเส้นพื้นฐานได้ และมีค่าใช้จ่าย 5 เหรียญสหรัฐฯ/เดือน ไม่ใช่ 200-500 เหรียญสหรัฐฯ ที่โดยปกติแล้วการตรวจสอบทั่วโลกขององค์กรจะมีค่าใช้จ่าย
โครงสร้างพื้นฐานการตรวจสอบทั่วโลกมีราคาแพงในการดำเนินการ เรารักษาราคาให้สามารถเข้าถึงได้โดยการให้บริการลูกค้าที่ชำระเงินซึ่งเห็นคุณค่าของบริการ ไม่ใช่โดยการรักษาระดับฟรี
การตรวจสอบตำแหน่งเดียวจะทดสอบการเชื่อมต่อจากจุดหนึ่งบนอินเทอร์เน็ตไปยังเซิร์ฟเวอร์ของคุณ มันไม่ได้บอกคุณเกี่ยวกับประสบการณ์ของผู้ใช้ในภูมิภาคอื่น DNS สามารถแก้ไขได้แตกต่างกันไปตามภูมิศาสตร์ เส้นทางเส้นทางจะแตกต่างกันไปตามสถานที่ ขอบ CDN ล้มเหลวอย่างอิสระ ISP มีการจัดการเพียร์ที่แตกต่างกัน วิธีเดียวที่จะทราบว่าเว็บไซต์ของคุณใช้ได้กับผู้ใช้ในสิงคโปร์ เซาเปาโล หรือสตอกโฮล์มหรือไม่ก็คือการทดสอบจากสถานที่เหล่านั้น
ขึ้นอยู่กับการกระจายผู้ใช้ของคุณ แต่มีมากกว่านั้นดีกว่า หากผู้ใช้ของคุณกระจุกตัวอยู่ในบางประเทศ ให้ครอบคลุมประเทศเหล่านั้นโดยเฉพาะ หากคุณมีผู้ชมทั่วโลก ตั้งเป้าไปที่สถานที่มากกว่า 50 แห่ง ครอบคลุมทวีปหลักๆ ทั้งหมด ทุกภูมิภาคที่ถูกเปิดเผยเป็นจุดบอดที่อาจซ่อนปัญหาได้
ผู้ให้บริการคลาวด์ (AWS, GCP, Azure) มีการเชื่อมต่อระหว่างภูมิภาคที่ยอดเยี่ยม การตรวจสอบจาก AWS ap-southeast-1 ไปยังเซิร์ฟเวอร์ AWS us-west-2 ของคุณมักจะเดินทางผ่านเครือข่ายแกนหลักคลาวด์ส่วนตัวที่มีความสม่ำเสมอและมีเวลาแฝงต่ำ นั่นไม่ใช่วิธีที่ผู้ใช้ของคุณเชื่อมต่อ ผู้ใช้จริงสำรวจโครงสร้างพื้นฐานอินเทอร์เน็ตสาธารณะที่มีความแปรปรวนทั้งหมด — ISP peering, สายเคเบิลข้ามมหาสมุทร, พฤติกรรมแปลก ๆ ในการกำหนดเส้นทางระดับภูมิภาค การตรวจสอบจากจุดชมวิวที่ไม่ใช่คลาวด์จะทำให้ได้ภาพที่สมจริงยิ่งขึ้น
ปัญหาคือการรู้ว่าเมื่อใดควรเรียกใช้ เมื่อผู้ใช้ร้องเรียน ปัญหาอาจดำเนินไปเป็นเวลาหลายชั่วโมงหรืออาจได้รับการแก้ไขแล้ว การตรวจสอบอย่างต่อเนื่องจะตรวจจับปัญหาที่เกิดขึ้น และหากคุณต้องการแก้ไขข้อบกพร่อง การมีข้อมูลการติดตามในอดีตจะแสดงให้คุณเห็นว่าเส้นทางเครือข่ายมีลักษณะอย่างไรในระหว่างที่เกิดเหตุการณ์ ไม่ใช่แค่หลังจากเหตุการณ์จบลงแล้ว
ชี้ไปที่การวิเคราะห์ของคุณ: เปอร์เซ็นต์ของผู้ใช้ที่มาจากนอกขอบเขตการตรวจสอบของคุณมีกี่เปอร์เซ็นต์ คำนวณรายได้จากภูมิภาคเหล่านั้น จากนั้นลองพิจารณาว่า: หากไซต์ของคุณล่มเป็นเวลา 4 ชั่วโมงในภูมิภาคเหล่านั้นและคุณไม่ทราบว่าจะมีค่าใช้จ่ายเท่าไร สำหรับธุรกิจส่วนใหญ่ ราคา $5/เดือนถือเป็นข้อผิดพลาดในการปัดเศษ เมื่อเทียบกับการสูญเสียรายได้ที่อาจเกิดขึ้นจากการหยุดทำงานในภูมิภาคที่ตรวจไม่พบเพียงครั้งเดียว
การตรวจสอบ DNS จับปัญหาตัวแก้ไข การตรวจสอบ SSL จะแจ้งเตือนคุณก่อนที่ใบรับรองจะหมดอายุในระดับภูมิภาค การตรวจสอบพอร์ตจะตรวจสอบบริการที่ไม่ใช่ HTTP การตรวจสอบ Ping จะวัดเวลาแฝงของเครือข่ายดิบโดยไม่มีค่าใช้จ่าย HTTP Traceroute และ MTR ช่วยวินิจฉัยปัญหาการกำหนดเส้นทางเมื่อเกิดปัญหา การตั้งค่าที่ครอบคลุมใช้จอภาพหลายประเภทสำหรับมุมการมองเห็นที่แตกต่างกัน
หยุดหวังว่าเว็บไซต์ของคุณจะทำงานได้ทุกที่ เริ่มรู้. เพิ่ม URL ของคุณ เลือกสถานที่ตรวจสอบ และดูสิ่งที่ผู้ใช้ทั่วโลกได้รับประสบการณ์จริง ก่อนที่พวกเขาจะส่งอีเมลถึงคุณเกี่ยวกับเรื่องนี้
$5/เดือน • ไม่มีสัญญา • ยกเลิกได้ตลอดเวลา