เว็บไซต์ของ Lowe's เป็นหนึ่งในเว็บไซต์อีคอมเมิร์ซที่มีประสิทธิภาพเร็วที่สุด

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

Abhimanyu Raibahadur
Abhimanyu Raibahadur
Ashish Choudhury
Ashish Choudhury
Dhilip venkatesh Uvarajan
Dhilip venkatesh Uvarajan
Dinakar Chandolu
Dinakar Chandolu
Safwan Samla
Safwan Samla

Lowe's เป็นผู้ค้าปลีกอุปกรณ์ซ่อมแซมบ้านมูลค่าเกือบ 90,000 ล้านดอลลาร์สหรัฐ ซึ่งมีร้านค้าประมาณ 2,200 แห่งและจ้างพนักงานมากกว่า 300,000 คน การสร้างระบบการทดสอบและการตรวจสอบอัตโนมัติที่ป้องกันไม่ให้ประสิทธิภาพถดถอยเมื่อนำไปใช้งานจริงช่วยให้ทีมความเร็วเว็บไซต์ของ Lowe's ปรับปรุงประสิทธิภาพเว็บไซต์ได้ และทำให้เว็บไซต์ติดอันดับเว็บไซต์ค้าปลีกชั้นนำ

ปัญหา

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

โซลูชัน

ทีมความเร็วของเว็บไซต์ใช้เครื่องมือโอเพนซอร์สเพื่อสร้างระบบการทดสอบและตรวจสอบประสิทธิภาพอัตโนมัติสําหรับสภาพแวดล้อมก่อนเข้าสู่ช่วงการทํางานจริง ระบบจะวัดประสิทธิภาพของคำขอดึงข้อมูล (PR) ทั้งหมด และป้องกันไม่ให้ PR เผยแพร่ไปยังเวอร์ชันที่ใช้งานจริงหากไม่เป็นไปตามงบประมาณด้านประสิทธิภาพและเกณฑ์เมตริกของทีมความเร็วเว็บไซต์ นอกจากนี้ ระบบยังวัดการปฏิบัติตามข้อกําหนดของ SEO และ ADA ด้วย

ผลกระทบ

จากตัวอย่าง 1 ทีมที่ติดตั้งใช้งานบิลด์ 102 รายการในช่วง 16 สัปดาห์ ระบบทดสอบและตรวจสอบประสิทธิภาพอัตโนมัติได้ป้องกันไม่ให้บิลด์ 32 รายการที่มีประสิทธิภาพต่ำกว่าเกณฑ์เข้าสู่เวอร์ชันที่ใช้งานจริง

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

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

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

การใช้งาน

หัวใจสําคัญของแอปการจัดการความเร็วเว็บไซต์ (SSG) คือ Lighthouse CI แอป SSG ใช้ Lighthouse เพื่อตรวจสอบและตรวจสอบประสิทธิภาพหน้าเว็บของคำขอดึงข้อมูลทุกรายการ

แผนภาพกระบวนการของแอป SSG โดยขั้นตอนที่แสดงในแผนภาพจะอธิบายไว้ในส่วนถัดไปของบทความ

แอป SSG ทําให้การสร้างไม่สําเร็จหากไม่เป็นไปตามงบประมาณด้านประสิทธิภาพและเป้าหมายเมตริกที่ทีมความเร็วเว็บไซต์กําหนดไว้ ซึ่งไม่เพียงบังคับใช้ประสิทธิภาพการโหลดเท่านั้น แต่ยังบังคับใช้ SEO, PWA และความสามารถในการเข้าถึง ซึ่งสามารถรายงานสถานะไปยังผู้เขียน ผู้ตรวจสอบ และทีม SRE ได้ทันที นอกจากนี้ คุณยังกําหนดค่าให้ข้ามการตรวจสอบได้หากจําเป็นต้องมีข้อยกเว้น

ขั้นตอนกระบวนการจัดการความเร็วอัตโนมัติ (ASG)

Spinnaker

จุดเริ่มต้น นักพัฒนาซอฟต์แวร์ผสานโค้ดของตนเข้ากับสภาพแวดล้อมก่อนเข้าสู่เวอร์ชันที่ใช้งานจริง

  1. ติดตั้งใช้งานสภาพแวดล้อมก่อนการเผยแพร่ด้วยชิ้นงาน CDN
  2. ตรวจสอบว่าการทำให้ใช้งานได้สําเร็จ
  3. เรียกใช้คอนเทนเนอร์ Docker เพื่อเริ่มสร้างแอปพลิเคชัน ASG หรือส่งการแจ้งเตือน (ในกรณีที่การทำให้ใช้งานได้ไม่สำเร็จ)

Jenkins และ Lighthouse

  1. สร้างแอปพลิเคชัน ASG ด้วย Jenkins
  2. เรียกใช้คอนเทนเนอร์ Docker ที่กําหนดเองซึ่งติดตั้ง Chrome และ Lighthouse แล้ว ดึง lighthouserc.json จากแอป SSG แล้วเรียกใช้ lhci autorun --collect-url=https://example.com

แอป Jenkins และ SSG

  1. ดึงข้อมูล assertion-results.json จาก lhci และเปรียบเทียบกับงบประมาณที่กําหนดไว้ล่วงหน้าใน budgets.json บันทึกเอาต์พุตเป็นไฟล์ข้อความและอัปโหลดไปยัง Nexus เพื่อเปรียบเทียบในอนาคต
  2. เปรียบเทียบ assertion-results.json ปัจจุบันกับบิลด์ที่ประสบความสําเร็จครั้งล่าสุด (ดาวน์โหลดจาก Nexus) และบันทึกเป็นไฟล์ข้อความ
  3. สร้างอีเมล HTML พร้อมข้อมูลความสําเร็จหรือไม่สําเร็จ
  4. ส่งอีเมลไปยังรายชื่ออีเมลสำหรับเผยแพร่ที่เกี่ยวข้องด้วย Jenkins