อะไรคือวิธีที่ดีในการตรวจสอบร้านค้าสด?

คำนำ: เราต้องการขยายการตรวจสอบของหนึ่งในเว็บช็อปของเราเนื่องจากผู้ให้บริการมีปัญหากับการกำหนดค่า PHP และบางส่วนของเว็บช็อปสดที่ขัดข้อง (แบ็กเอนด์และเช็คเอาต์ไม่ทำงาน) ฉันไม่ต้องการพูดคุยเกี่ยวกับการย้ายไปยังผู้ให้บริการรายอื่นที่นี่

เนื่องจากเรากำลังคิดเกี่ยวกับความเป็นไปได้ในการตรวจสอบเว็บช็อปและความพร้อมใช้งานของบางส่วน (เช่น "เช็คเอาต์ใช้งานได้หรือไม่") คำถามคือ:

เครื่องมือและกลยุทธ์ใดที่คุณแนะนำให้ตรวจสอบเว็บไซต์ออนไลน์

ความคิดบางอย่าง:

• คุณตรวจสอบอัตโนมัติหรือไม่หากการชำระเงินยังคงทำงานอยู่ในเว็บไซต์สด
• สิ่งที่สามารถเป็นพารามิเตอร์ที่ดีในการตรวจสอบเพื่อตรวจสอบความล้มเหลว? คำสั่งซื้อล่าสุด <1 วันที่ผ่านมาเข้าสู่ระบบผู้ใช้ล่าสุด ...
• การใช้งาน cron: การตรวจสอบตัวอย่างสำหรับวันที่ / เวลาของการสั่งซื้อครั้งล่าสุดและหากนานเกินไปให้ส่งอีเมลและ / หรือตรวจสอบด้วยตนเองหากการชำระเงินยังคงใช้ได้หรือไม่
• ใช้ซอฟต์แวร์ / เครื่องมือเช่น Icinga, Uptime Robot, ...
• กำลังส่งอีเมลเตือนถึงผู้ดูแลระบบ ...

รอคำตอบของคุณ :)

มีสองสิ่งที่คุณสามารถทำได้โดยอัตโนมัติ

1. หากบางส่วนของร้านค้าหยุดทำงานการทดสอบหน่วยเป็นวิธีที่ดีในการตรวจสอบว่าฟังก์ชันบางอย่างยังทำงานอยู่หรือไม่
2. เพื่อทดสอบส่วนหน้าฉันใช้phpQueryบนรีโมตเซิร์ฟเวอร์เพื่อค้นหาองค์ประกอบ DOM บางอย่างในหน้าหลักบางหน้าเช่น 'จะยังมีผลิตภัณฑ์ในรายการหมวดหมู่', 'มีส่วนท้าย * ในหน้าแรก' ฯลฯ
3. ตั้งค่า cronjob ง่าย ๆ ที่ส่ง Ping โฮสต์ของคุณเพื่อดูว่ายังมีอยู่หรือไม่
4. ใช้ฟีด RSS ของ Magento ดั้งเดิมเพื่อตรวจสอบว่าคำสั่งซื้อยังคงมาอยู่หรือไม่ในร้านค้าที่มีการจราจรหนาแน่นไม่มีคำสั่งซื้อเป็นชั่วโมงในช่วงเย็นวันศุกร์เป็นตัวบ่งชี้ที่ดีว่ามีบางอย่างผิดปกติ :)
5. ตรวจสอบผู้ให้บริการการชำระเงินของคุณ ในเนเธอร์แลนด์เราใช้ iDeal เพื่อจัดการการชำระเงิน เว็บไซต์นี้แสดงเวลาที่เครื่อง PSP ของคุณอาจให้บริการที่คล้ายกัน

* หากไม่มีส่วนท้ายของหน้าซึ่งอาจชี้ไปที่ข้อผิดพลาด PHP หยุดการเรนเดอร์

นี่คือโซลูชันสองสามข้อที่เราใช้ พวกเขาต้องการเวลาในการตั้งค่าและสามารถเปิดใช้งานได้ฟรี

เป็นคำถามที่ดีมากจริงๆฉันรอคอยคำตอบทั้งหมด!

ฉันจะประกบกับคำตอบที่ยอดเยี่ยมของ Sander ซึ่งถือว่าคุณได้ตั้งค่าและใช้บริการตรวจสอบอย่าง Pingdom *:

• ดูเนื้อหาบนหน้า; มักจะเป็น</html>แท็กปิด ฉันได้เห็นbefore_body_endสคริปต์จำนวนมากล้มเหลวกับบุคคลที่ 3 (ข้อยกเว้นที่ไม่ได้ตรวจจับ ฯลฯ ) ซึ่งไม่ปรากฏแก่ผู้ใช้ปลายทาง แต่กลับสถานะ 500 - แย่มากสำหรับเครื่องมือ SEO / Google / Webmaster
• ตั้งค่าเครื่องมือของผู้ดูแลเว็บเพื่อแจ้งเตือนคุณเมื่อมีข้อผิดพลาดเพิ่มขึ้นเกินเกณฑ์ที่กำหนด
• ตั้งค่าการเตือนสำหรับ SSL ที่ไม่ถูกต้องบนหน้าเว็บ
• ตั้งค่าการเตือนสำหรับข้อผิดพลาดจาวาสคริปต์ในหน้า
• ใช้กลุ่มอีเมล / bcc สำหรับอีเมลล้มเหลวในการชำระเงินรายงานข้อผิดพลาด
• ติดต่อกับผู้คนในคอลล์เซ็นเตอร์ของคุณอย่างแน่นหนาและตรวจสอบให้แน่ใจว่าพวกเขารู้วิธีการคัดกรองปัญหา - พวกเขามักจะเป็นคนแรกที่ชี้ให้เห็นเมื่อสิ่งต่าง ๆ ผิดปกติ
• ไซต์ที่ช้านั้นแย่พอ ๆ กับไซต์ดาวน์ ตรวจสอบให้แน่ใจว่าการแจ้งเตือนของคุณมีความละเอียดอ่อนว่าเมื่อไซต์ของคุณใช้เวลาโหลดนานกว่าปกติ
• สมัครสมาชิกฟีด Twitter สำหรับบริการของบุคคลที่สาม / โฮสต์ที่สำคัญทั้งหมดของคุณ โฮสต์ที่ใหญ่กว่ามักจะมีตัวกระตุ้น Twitter สำหรับเมื่อมีปัญหา คุณสามารถกำหนดค่า Twitter ให้กับอีเมล / ข้อความของคุณเมื่อบางบัญชีโพสต์

DevOps:

• ตั้งค่า Nagios สำหรับการตรวจสอบระบบที่สำคัญและส่งการแจ้งเตือน
• ตั้งค่า syslog หรือ Splunk (ฟรีมากถึง # ของแบบสอบถาม / วัน) เพื่อรวบรวมบันทึกและการแจ้งเตือนปัญหาตามข้อมูลบันทึก
• กำหนดค่าการตรวจสอบอุปกรณ์เครือข่ายของคุณเป็นประจำ ฉันเคยเห็น (มากกว่าหนึ่งครั้ง) นิคส์ย้อนกลับและลดลงจาก 1GB เป็น 10MB ที่เราไม่รู้จัก

สำหรับทีมใหญ่:

• ตั้งค่าเซิร์ฟเวอร์ CI (Travis, Jenkins / Hudson, Capistrano) เพื่อเตือนคุณเกี่ยวกับการทดสอบความล้มเหลวที่อาจเกิดขึ้นหลังจากคอมมิท
• ตั้งค่า hooks ล่วงหน้าล่วงหน้าในการควบคุมซอร์สของคุณเพื่อบังคับใช้มาตรฐานรหัสหรือเพื่อตรวจสอบปัญหาที่โจ่งแจ้งเช่นรหัสที่ใช้ไม่ได้
• เช่นเดียวกับ Sander กล่าวว่าตั้งค่าบางอย่างเพื่อตรวจสอบฟีด RSS สำหรับคำสั่งซื้อและปริมาณตามเวลาของวัน - ประโยชน์ที่นี่คือมันไม่ได้ล้างและโดยทั่วไปถ้าคุณตั้งค่าเกณฑ์การแจ้งเตือนต่ำพอปัญหาที่อาจเกิดขึ้นจะเดินทางทันที
• ใช้ซีลีเนียม มาก. มีการทดสอบสคริปต์ที่ดำเนินการผ่านกระบวนการชำระเงินทุก ๆ ชั่วโมงหรือสองชั่วโมง
• ตั้งค่าการแจ้งเตือนปฏิทินและการแจ้งเตือนเฉพาะสำหรับการหมดอายุ SSL

คุณกำลังจะสร้างข้อมูลจำนวนมากและผลบวกที่ผิดพลาด; อย่ากลายเป็นภูมิคุ้มกันต่อการเตือน

ฉันไม่ได้มีส่วนเกี่ยวข้องกับ Pingdom ฉันรักผลิตภัณฑ์ (ฟรี) ของพวกเขา

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

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

ฉันชอบ NewRelic และ PagerDuty สำหรับสิ่งนี้พวกเขาสมบูรณ์แบบและแจ้งให้คุณทราบ (อีเมลข้อความและการโทร) ในเวลาไม่กี่นาทีหากเว็บไซต์ของคุณหรือส่วนใดส่วนหนึ่งของเว็บไซต์ของคุณหยุดทำงาน มันจะแจ้งให้ทราบว่า CPU หรือหน่วยความจำของคุณมีค่าเกินกว่าร้อยละของการใช้งานที่ระบุทำให้ไซต์ไม่ตอบสนอง

• ตั้งค่าของที่ระลึกใหม่พร้อมหน้าทั้งหมดที่คุณต้องการตรวจสอบและตรวจสอบความถี่ ตัวอย่าง: โฮมเพจ, หน้า 1 หมวดหมู่, หน้าผลิตภัณฑ์ 1 หน้า, หน้าตะกร้า, หน้าชำระเงิน ฯลฯ
• เพิ่มผู้ใช้ (ผู้ที่ได้รับการแจ้งเตือน) กำหนดเวลา (วันและเวลาที่คุณต้องการรับการแจ้งเตือน) บริการ (การแจ้งเตือนที่ระลึกใหม่) และนโยบายการเพิ่มการแจ้งเตือน PagerDuty และประเภทของการแจ้งเตือนที่คุณต้องการ (อีเมลข้อความโทร)

https://www.pagerduty.com/docs/guides/new-relic-integration-guide/

ข้อจำกัดความรับผิดชอบ: ฉันไม่ได้เกี่ยวข้องกับบริการใด ๆ ข้างต้น

MageMonitoring - https://github.com/magento-hackathon/Hackathon_MageMonitoring เครื่องมือโอเพนซอร์สที่ยอดเยี่ยมฟรีที่ติดตามเซิร์ฟเวอร์และสุขภาพวีโอไอพีส่งอีเมลที่มีข้อยกเว้นและบันทึกระบบ ฯลฯ

• Munin ในด้านผู้ให้บริการเพื่อรับค่าประวัติสำหรับเซิร์ฟเวอร์ทั้งหมด (LB, App, DB, Redis, ฯลฯ ) และบริการทั้งหมด (หน่วยความจำโหลด io เป็นต้น)
• Nagios / Icinga บนผู้ให้บริการหรือด้านในพื้นที่สำหรับการโหลดการตรวจสอบแบบสดใกล้กับเซิร์ฟเวอร์ทั้งหมด
• Pingdom เพื่อรวบรวมเวลาตอบกลับสำหรับ URL "สำคัญ" เช่นหน้าแรกชำระเงิน ฯลฯ
• Pingdom สำหรับการตรวจสอบผู้ใช้จริงคุณจะได้รับค่าที่คล้ายกับ APDEX และดูการพัฒนาที่ผ่านมา
• Pingdom เพื่อตรวจสอบ URL และเนื้อหาที่ถูกต้อง
• การรายงานด้วยคำสั่ง X สุดท้ายในโหมดโหลดซ้ำอัตโนมัติ ด้วยฉันสามารถเห็นการแบ่งที่เป็นไปได้
• การทดสอบอัตโนมัติกับซีลีเนียมบนระบบเวทีเดียวกัน ฉันไม่ใช่เพื่อนของการชำระเงินอัตโนมัติในระบบสดของฉัน คุณจะได้รับปัญหาเกี่ยวกับการบัญชีของคุณในภายหลัง :)
• Zapier และ Twilio สำหรับ Email2SMS ข้อผิดพลาดที่สำคัญจะถูกส่งเป็น SMS ไปยังโทรศัพท์
• freeboard.io และ dweet.io แสดงทุกอย่างบนแดชบอร์ดที่ดี