ตอนนี้หัวข้อของ DevOps กำลังเป็นที่ฮือฮา การบูรณาการอย่างต่อเนื่องและขั้นตอนการส่งมอบ ทุกคนกำลังใช้มัน แต่ส่วนใหญ่มักไม่ได้ให้ความสำคัญกับการรับรองความน่าเชื่อถือของระบบข้อมูลในขั้นตอนต่างๆ ของไปป์ไลน์ CI/CD ในบทความนี้ ฉันอยากจะพูดถึงประสบการณ์ของฉันในการตรวจสอบคุณภาพซอฟต์แวร์โดยอัตโนมัติและการนำสถานการณ์ที่เป็นไปได้ไปใช้สำหรับ "การรักษาตนเอง"
ฉันทำงานเป็นวิศวกรในแผนกการจัดการบริการไอทีของบริษัท . ความเชี่ยวชาญหลักของฉันคือการนำประสิทธิภาพของแอปพลิเคชันต่างๆ ไปใช้และระบบตรวจสอบความพร้อมใช้งาน ฉันมักจะสื่อสารกับลูกค้าไอทีจากกลุ่มตลาดที่แตกต่างกันเกี่ยวกับปัญหาปัจจุบันเกี่ยวกับการตรวจสอบคุณภาพของบริการไอทีของพวกเขา เป้าหมายหลักคือการลดรอบเวลาการเผยแพร่ให้เหลือน้อยที่สุดและเพิ่มความถี่ในการเผยแพร่ แน่นอนว่าทั้งหมดนี้เป็นสิ่งที่ดี: มีการเปิดตัวมากขึ้น - คุณสมบัติใหม่มากขึ้น - ผู้ใช้มีความพึงพอใจมากขึ้น - กำไรมากขึ้น แต่ในความเป็นจริง สิ่งต่างๆ ไม่ได้ผลดีเสมอไป ด้วยอัตราการปรับใช้ที่สูงมาก คำถามก็เกิดขึ้นทันทีเกี่ยวกับคุณภาพของการเปิดตัวของเรา แม้จะมีไปป์ไลน์แบบอัตโนมัติเต็มรูปแบบ หนึ่งในความท้าทายที่ใหญ่ที่สุดก็คือการย้ายบริการจากการทดสอบไปสู่การใช้งานจริง โดยไม่ส่งผลกระทบต่อเวลาทำงานของแอปพลิเคชันและประสบการณ์ผู้ใช้
จากผลของการสนทนากับลูกค้าหลายครั้ง ฉันสามารถพูดได้ว่าการเปิดตัวการควบคุมคุณภาพ ปัญหาความน่าเชื่อถือของแอปพลิเคชัน และความเป็นไปได้ของ "การรักษาตัวเอง" (เช่น การย้อนกลับเป็นเวอร์ชันที่เสถียร) ในขั้นตอนต่างๆ ของ CI ไปป์ไลน์ /CD เป็นหนึ่งในหัวข้อที่น่าตื่นเต้นและเกี่ยวข้องที่สุด
เมื่อเร็ว ๆ นี้ฉันเองทำงานด้านลูกค้า - ในบริการสนับสนุนซอฟต์แวร์แอปพลิเคชันธนาคารออนไลน์ สถาปัตยกรรมของแอปพลิเคชันของเราใช้ไมโครเซอร์วิสที่เขียนเองจำนวนมาก สิ่งที่น่าเศร้าที่สุดคือไม่ใช่นักพัฒนาทุกคนที่สามารถรับมือกับการพัฒนาที่สูงได้ คุณภาพของไมโครเซอร์วิสบางตัวต้องทนทุกข์ทรมานซึ่งทำให้เกิดชื่อเล่นตลกสำหรับพวกเขาและผู้สร้าง มีเรื่องเล่ากันว่าผลิตภัณฑ์เหล่านี้ทำจากวัสดุอะไร
"การกำหนดปัญหา"
ความถี่ในการเผยแพร่สูงและไมโครเซอร์วิสจำนวนมากทำให้ยากต่อการเข้าใจการทำงานของแอปพลิเคชันโดยรวม ทั้งในขั้นตอนการทดสอบและในขั้นตอนการปฏิบัติงาน การเปลี่ยนแปลงเกิดขึ้นอย่างต่อเนื่อง และเป็นเรื่องยากมากที่จะควบคุมโดยไม่มีเครื่องมือตรวจสอบที่ดี บ่อยครั้งหลังจากการเปิดตัวตอนกลางคืนในตอนเช้า นักพัฒนาจะนั่งเหมือนอยู่บนถังแป้งและรอให้ไม่มีอะไรพัง แม้ว่าการตรวจสอบทั้งหมดจะประสบความสำเร็จในขั้นตอนการทดสอบก็ตาม
มีอีกจุดหนึ่ง ในขั้นตอนการทดสอบจะมีการตรวจสอบฟังก์ชันการทำงานของซอฟต์แวร์: การใช้งานฟังก์ชันหลักของแอปพลิเคชันและไม่มีข้อผิดพลาด การประเมินประสิทธิภาพเชิงคุณภาพหายไปหรือไม่คำนึงถึงทุกแง่มุมของแอปพลิเคชันและเลเยอร์การรวม เมตริกบางอย่างอาจไม่ได้รับการตรวจสอบเลย ด้วยเหตุนี้ เมื่อเกิดความเสียหายในสภาพแวดล้อมการผลิต แผนกสนับสนุนทางเทคนิคจะทราบเรื่องนี้ก็ต่อเมื่อผู้ใช้จริงเริ่มร้องเรียนเท่านั้น ฉันต้องการลดผลกระทบของซอฟต์แวร์คุณภาพต่ำต่อผู้ใช้ปลายทางให้เหลือน้อยที่สุด
หนึ่งในโซลูชันคือการใช้กระบวนการตรวจสอบคุณภาพซอฟต์แวร์ในขั้นตอนต่างๆ ของไปป์ไลน์ CI/CD และเพิ่มสถานการณ์จำลองต่างๆ สำหรับการกู้คืนระบบในกรณีฉุกเฉิน เรายังจำได้ว่าเรามี DevOps ธุรกิจคาดหวังว่าจะได้รับผลิตภัณฑ์ใหม่โดยเร็วที่สุด ดังนั้นการตรวจสอบและสคริปต์ทั้งหมดของเราต้องเป็นแบบอัตโนมัติ
งานจะแบ่งออกเป็นสองส่วน:
- การควบคุมคุณภาพของชุดประกอบในขั้นตอนการทดสอบ (เพื่อทำให้กระบวนการจับชุดประกอบคุณภาพต่ำเป็นไปโดยอัตโนมัติ)
- การควบคุมคุณภาพซอฟต์แวร์ในสภาพแวดล้อมการผลิต (กลไกการตรวจจับปัญหาอัตโนมัติและสถานการณ์ที่เป็นไปได้สำหรับการรักษาตนเอง)
เครื่องมือสำหรับการตรวจสอบและรวบรวมตัวชี้วัด
เพื่อให้บรรลุเป้าหมายที่ตั้งไว้ จำเป็นต้องมีระบบการตรวจสอบที่สามารถตรวจจับปัญหาและถ่ายโอนไปยังระบบอัตโนมัติในขั้นตอนต่างๆ ของไปป์ไลน์ CI/CD มันจะเป็นสิ่งที่ดีเช่นกันหากระบบนี้ให้ตัวชี้วัดที่เป็นประโยชน์สำหรับทีมต่างๆ: การพัฒนา การทดสอบ และการปฏิบัติการ และจะยอดเยี่ยมอย่างยิ่งหากเป็นธุรกิจด้วย
ในการรวบรวมการวัด คุณสามารถใช้ชุดของระบบต่างๆ (Prometheus, ELK Stack, Zabbix ฯลฯ) แต่ในความคิดของฉัน โซลูชันระดับ APM เหมาะที่สุดสำหรับงานเหล่านี้ () ซึ่งสามารถทำให้ชีวิตของคุณง่ายขึ้นอย่างมาก
ในฐานะส่วนหนึ่งของงานของฉันในบริการสนับสนุน ฉันเริ่มทำโปรเจ็กต์ที่คล้ายกันโดยใช้โซลูชันคลาส APM จาก Dynatrace ตอนนี้ ฉันทำงานให้กับผู้ประกอบระบบ ฉันรู้จักตลาดระบบตรวจสอบค่อนข้างดี ความคิดเห็นส่วนตัวของฉัน: Dynatrace เหมาะที่สุดสำหรับการแก้ปัญหาดังกล่าว
Dynatrace ให้มุมมองแนวนอนของการดำเนินการของผู้ใช้ทุกคนในระดับย่อยจนถึงระดับการเรียกใช้โค้ด คุณสามารถติดตามห่วงโซ่การโต้ตอบทั้งหมดระหว่างบริการข้อมูลต่างๆ ตั้งแต่ระดับส่วนหน้าของแอปพลิเคชันบนเว็บและมือถือ เซิร์ฟเวอร์แอปพลิเคชันส่วนหลัง บัสบูรณาการ ไปจนถึงการโทรไปยังฐานข้อมูลเฉพาะ
. การสร้างการพึ่งพาทั้งหมดระหว่างส่วนประกอบของระบบโดยอัตโนมัติ
. การตรวจจับและสร้างเส้นทางการดำเนินการบริการโดยอัตโนมัติ
เรายังจำได้ว่าเราต้องผสานรวมกับเครื่องมืออัตโนมัติต่างๆ โซลูชันมี API ที่สะดวกสบายซึ่งช่วยให้คุณสามารถส่งและรับตัววัดและเหตุการณ์ต่างๆ ได้
ต่อไป เรามาดูวิธีแก้ปัญหาเหล่านี้โดยละเอียดโดยใช้ระบบ Dynatrace กัน
ภารกิจที่ 1 ระบบอัตโนมัติของการควบคุมคุณภาพของชุดประกอบในขั้นตอนการทดสอบ
ความท้าทายประการแรกคือการค้นหาปัญหาให้เร็วที่สุดเท่าที่จะเป็นไปได้ในขั้นตอนการส่งมอบแอปพลิเคชัน เฉพาะการสร้างโค้ดที่ "ดี" เท่านั้นที่ควรไปถึงการใช้งานจริง ในการดำเนินการนี้ ไปป์ไลน์ของคุณที่อยู่ในขั้นตอนการทดสอบควรมีการตรวจสอบเพิ่มเติมเพื่อตรวจสอบคุณภาพของบริการของคุณ
มาดูวิธีการนำไปใช้และทำให้กระบวนการนี้เป็นแบบอัตโนมัติทีละขั้นตอน:
รูปภาพแสดงขั้นตอนการทดสอบคุณภาพซอฟต์แวร์อัตโนมัติ:
- การใช้งานระบบตรวจสอบ (การติดตั้งตัวแทน)
- การระบุเหตุการณ์สำหรับการประเมินคุณภาพของซอฟต์แวร์ของคุณ (ตัวชี้วัดและค่าเกณฑ์) และถ่ายโอนไปยังระบบการตรวจสอบ
- การสร้างโหลดและการทดสอบสมรรถนะ
- การรวบรวมข้อมูลประสิทธิภาพและความพร้อมใช้งานในระบบติดตาม
- การถ่ายโอนข้อมูลการทดสอบตามเหตุการณ์การประเมินคุณภาพซอฟต์แวร์จากระบบการตรวจสอบไปยังระบบ CI/CD การวิเคราะห์แอสเซมบลีอัตโนมัติ
ขั้นตอนที่ 1 การปรับใช้ระบบตรวจสอบ
ขั้นแรก คุณต้องติดตั้งเอเจนต์ในสภาพแวดล้อมการทดสอบของคุณ ในเวลาเดียวกัน โซลูชัน Dynatrace มีคุณสมบัติที่ดี - ใช้เอเจนต์สากล OneAgent ซึ่งติดตั้งบนอินสแตนซ์ระบบปฏิบัติการ (Windows, Linux, AIX) ตรวจจับบริการของคุณโดยอัตโนมัติและเริ่มรวบรวมข้อมูลการตรวจสอบ คุณไม่จำเป็นต้องกำหนดค่าเอเจนต์แยกต่างหากสำหรับแต่ละกระบวนการ สถานการณ์จะคล้ายกันสำหรับแพลตฟอร์มคลาวด์และคอนเทนเนอร์ ในเวลาเดียวกัน คุณยังสามารถทำให้กระบวนการติดตั้งตัวแทนเป็นอัตโนมัติได้ Dynatrace เข้ากันได้อย่างลงตัวกับแนวคิด "โครงสร้างพื้นฐานเป็นโค้ด" (): มีสคริปต์และคำแนะนำสำเร็จรูปสำหรับแพลตฟอร์มยอดนิยมทั้งหมด คุณฝังตัวแทนไว้ในการกำหนดค่าบริการของคุณ และเมื่อคุณปรับใช้ คุณจะได้รับบริการใหม่ทันทีพร้อมกับตัวแทนที่ทำงานอยู่แล้ว
ขั้นตอนที่ 2: กำหนดเหตุการณ์ด้านคุณภาพซอฟต์แวร์ของคุณ
ตอนนี้คุณต้องตัดสินใจเกี่ยวกับรายการบริการและการดำเนินธุรกิจ สิ่งสำคัญคือต้องคำนึงถึงการดำเนินงานของผู้ใช้ที่มีความสำคัญทางธุรกิจต่อบริการของคุณ ที่นี่ฉันขอแนะนำให้ปรึกษากับนักวิเคราะห์ธุรกิจและระบบ
ถัดไป คุณต้องพิจารณาว่าคุณต้องการรวมเมตริกใดไว้ในการตรวจสอบสำหรับแต่ละระดับ ตัวอย่างเช่น นี่อาจเป็นเวลาดำเนินการ (แบ่งออกเป็นค่าเฉลี่ย ค่ามัธยฐาน เปอร์เซ็นไทล์ ฯลฯ) ข้อผิดพลาด (โลจิคัล บริการ โครงสร้างพื้นฐาน ฯลฯ) และตัววัดโครงสร้างพื้นฐานต่างๆ (ฮีปหน่วยความจำ ตัวรวบรวมขยะ จำนวนเธรด ฯลฯ)
สำหรับระบบอัตโนมัติและความสะดวกในการใช้งานโดยทีม DevOps แนวคิดของ "การตรวจสอบเป็นโค้ด" จะปรากฏขึ้น สิ่งที่ฉันหมายถึงคือนักพัฒนา/ผู้ทดสอบสามารถเขียนไฟล์ JSON ง่ายๆ ที่กำหนดเมตริกการประกันคุณภาพซอฟต์แวร์
ลองดูตัวอย่างไฟล์ JSON ดังกล่าวกัน ออบเจ็กต์จาก Dynatrace API ถูกใช้เป็นคู่คีย์/ค่า (สามารถดูคำอธิบาย API ได้ที่นี่ ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}ไฟล์นี้เป็นอาร์เรย์ของคำจำกัดความอนุกรมเวลา:
- timeseriesId – ตัววัดที่กำลังตรวจสอบ เช่น เวลาตอบสนอง จำนวนข้อผิดพลาด หน่วยความจำที่ใช้ ฯลฯ
- การรวมกลุ่ม - ระดับของการรวมเมตริกในกรณีของเรา เฉลี่ย แต่คุณสามารถใช้สิ่งใดก็ได้ที่คุณต้องการ (เฉลี่ย, ต่ำสุด, สูงสุด, ผลรวม, จำนวน, เปอร์เซ็นไทล์)
- แท็ก – แท็กอ็อบเจ็กต์ในระบบการตรวจสอบ หรือคุณสามารถระบุตัวระบุอ็อบเจ็กต์เฉพาะได้
- รุนแรงและเป็นคำเตือน – ตัวบ่งชี้เหล่านี้จะควบคุมค่าเกณฑ์ของตัวชี้วัดของเรา หากค่าการทดสอบเกินเกณฑ์ที่รุนแรง โครงสร้างของเราจะถูกทำเครื่องหมายว่าไม่สำเร็จ
รูปภาพต่อไปนี้แสดงตัวอย่างการใช้เกณฑ์ดังกล่าว
ขั้นตอนที่ 3: การสร้างโหลด
เมื่อเรากำหนดระดับคุณภาพของบริการของเราแล้ว เราจำเป็นต้องสร้างโหลดทดสอบ คุณสามารถใช้เครื่องมือทดสอบใดก็ได้ที่คุณคุ้นเคย เช่น Jmeter, Selenium, Neotys, Gatling เป็นต้น
ระบบการตรวจสอบของ Dynatrace ช่วยให้คุณสามารถบันทึกข้อมูลเมตาต่างๆ จากการทดสอบของคุณและรับรู้ว่าการทดสอบใดเป็นของรอบการเปิดตัวใดและบริการใด ขอแนะนำให้เพิ่มส่วนหัวเพิ่มเติมให้กับคำขอทดสอบ HTTP
รูปต่อไปนี้แสดงตัวอย่างโดยการใช้ X-Dynatrace-Test ส่วนหัวเพิ่มเติม เราระบุว่าการทดสอบนี้เกี่ยวข้องกับการทดสอบการดำเนินการในการเพิ่มสินค้าลงในรถเข็น
เมื่อคุณรันการทดสอบโหลดแต่ละครั้ง คุณจะส่งข้อมูลบริบทเพิ่มเติมไปยัง Dynatrace โดยใช้ Event API จากเซิร์ฟเวอร์ CI/CD ด้วยวิธีนี้ ระบบสามารถแยกแยะระหว่างการทดสอบต่างๆ ได้
. เหตุการณ์ในระบบการตรวจสอบเกี่ยวกับการเริ่มการทดสอบโหลด
ขั้นตอนที่ 4-5 รวบรวมข้อมูลประสิทธิภาพและถ่ายโอนข้อมูลไปยังระบบ CI/CD
เมื่อรวมกับการทดสอบที่สร้างขึ้น เหตุการณ์จะถูกส่งไปยังระบบการตรวจสอบเกี่ยวกับความจำเป็นในการรวบรวมข้อมูลในการตรวจสอบตัวบ่งชี้คุณภาพการบริการ นอกจากนี้ยังระบุไฟล์ JSON ของเราซึ่งกำหนดตัวชี้วัดหลักด้วย
เหตุการณ์เกี่ยวกับความจำเป็นในการตรวจสอบคุณภาพของซอฟต์แวร์ที่สร้างขึ้นบนเซิร์ฟเวอร์ CI/CD เพื่อส่งไปยังระบบการตรวจสอบ
ในตัวอย่างของเรา มีการเรียกเหตุการณ์การตรวจสอบคุณภาพ perfSigDynatraceReport (ประสิทธิภาพ_ลายเซ็นต์) - นี่พร้อมแล้ว สำหรับการบูรณาการกับ Jenkins ซึ่งพัฒนาโดยทีมงานจาก T-Systems Multimedia Solutions กิจกรรมการเปิดตัวการทดสอบแต่ละรายการประกอบด้วยข้อมูลเกี่ยวกับบริการ หมายเลขบิวด์ และเวลาทดสอบ ปลั๊กอินรวบรวมค่าประสิทธิภาพ ณ เวลาที่สร้าง ประเมิน และเปรียบเทียบผลลัพธ์กับบิลด์ก่อนหน้าและข้อกำหนดที่ไม่สามารถใช้งานได้
เหตุการณ์ในระบบการตรวจสอบเกี่ยวกับการเริ่มการตรวจสอบคุณภาพงานสร้าง
หลังจากการทดสอบเสร็จสิ้น หน่วยวัดทั้งหมดสำหรับการประเมินคุณภาพซอฟต์แวร์จะถูกโอนกลับไปยังระบบบูรณาการอย่างต่อเนื่อง เช่น Jenkins ซึ่งสร้างรายงานเกี่ยวกับผลลัพธ์
ผลลัพธ์ของสถิติเกี่ยวกับแอสเซมบลีบนเซิร์ฟเวอร์ CI/CD
สำหรับแต่ละรุ่น เราจะเห็นสถิติสำหรับตัวชี้วัดแต่ละตัวที่เราตั้งไว้ตลอดการทดสอบทั้งหมด นอกจากนี้เรายังดูว่ามีการละเมิดค่าเกณฑ์บางอย่างหรือไม่ (คำเตือนและขีด จำกัด ที่รุนแรง) ตามตัวชี้วัดรวม โครงสร้างทั้งหมดจะถูกทำเครื่องหมายว่าเสถียร ไม่เสถียร หรือล้มเหลว นอกจากนี้ เพื่อความสะดวก คุณสามารถเพิ่มตัวบ่งชี้ลงในรายงานโดยเปรียบเทียบรุ่นปัจจุบันกับรุ่นก่อนหน้าได้
ดูสถิติโดยละเอียดเกี่ยวกับแอสเซมบลีบนเซิร์ฟเวอร์ CI/CD
การเปรียบเทียบรายละเอียดของสองชุดประกอบ
หากจำเป็น คุณสามารถไปที่อินเทอร์เฟซ Dynatrace และที่นั่นคุณสามารถดูสถิติสำหรับแต่ละรุ่นของคุณโดยละเอียดมากขึ้น และเปรียบเทียบระหว่างกัน
การเปรียบเทียบสถิติการสร้างใน Dynatrace
ผลการวิจัย
ด้วยเหตุนี้ เราจึงได้รับบริการ "การตรวจสอบเป็นบริการ" โดยอัตโนมัติในไปป์ไลน์การผสานรวมอย่างต่อเนื่อง นักพัฒนาหรือผู้ทดสอบเพียงต้องกำหนดรายการเมตริกในไฟล์ JSON แล้วทุกอย่างจะเกิดขึ้นโดยอัตโนมัติ เราได้รับการควบคุมคุณภาพการเผยแพร่อย่างโปร่งใส: การแจ้งเตือนทั้งหมดเกี่ยวกับประสิทธิภาพ การใช้ทรัพยากร หรือการถดถอยทางสถาปัตยกรรม
ภารกิจที่ 2 ระบบอัตโนมัติของการควบคุมคุณภาพซอฟต์แวร์ในสภาพแวดล้อมการผลิต
ดังนั้นเราจึงได้แก้ไขปัญหาในการทำกระบวนการตรวจสอบอัตโนมัติในขั้นตอนการทดสอบใน Pipeline แล้ว วิธีนี้ทำให้เราลดเปอร์เซ็นต์ของส่วนประกอบคุณภาพต่ำที่เข้าถึงสภาพแวดล้อมการผลิตให้เหลือน้อยที่สุด
แต่จะทำอย่างไรถ้าซอฟต์แวร์ที่ไม่ดีถูกขายออกไปหรือมีบางอย่างพัง สำหรับโลกในอุดมคติ เราต้องการกลไกในการตรวจจับปัญหาโดยอัตโนมัติ และหากเป็นไปได้ ระบบเองก็สามารถกู้คืนฟังก์ชันการทำงานได้ อย่างน้อยก็ในเวลากลางคืน
ในการดำเนินการนี้ โดยการเปรียบเทียบกับส่วนก่อนหน้า เราต้องจัดให้มีการตรวจสอบคุณภาพซอฟต์แวร์อัตโนมัติในสภาพแวดล้อมการผลิต และเพื่อยึดตามสถานการณ์สำหรับการรักษาระบบด้วยตนเอง
แก้ไขอัตโนมัติเป็นรหัส
บริษัทส่วนใหญ่มีฐานความรู้ที่สะสมเกี่ยวกับปัญหาทั่วไปประเภทต่างๆ และรายการการดำเนินการเพื่อแก้ไข เช่น การรีสตาร์ทกระบวนการ การล้างทรัพยากร การย้อนกลับเวอร์ชัน การคืนค่าการเปลี่ยนแปลงการกำหนดค่าที่ไม่ถูกต้อง การเพิ่มหรือลดจำนวนส่วนประกอบใน คลัสเตอร์ การสลับโครงร่างสีน้ำเงินหรือสีเขียว เป็นต้น
แม้ว่าทีมต่างๆ ที่ฉันพูดคุยด้วยจะรู้จักกรณีการใช้งานเหล่านี้มาหลายปีแล้ว แต่มีเพียงไม่กี่ทีมที่คิดหรือลงทุนในการทำให้ระบบอัตโนมัติ
หากคุณลองคิดดู ไม่มีอะไรซับซ้อนเกินไปในการปรับใช้กระบวนการสำหรับประสิทธิภาพของแอปพลิเคชันที่รักษาตนเอง คุณต้องนำเสนอสถานการณ์การทำงานที่ทราบอยู่แล้วของผู้ดูแลระบบของคุณในรูปแบบของโค้ดสคริปต์ (แนวคิด "แก้ไขอัตโนมัติเป็นโค้ด") ซึ่งคุณเขียนไว้ล่วงหน้าสำหรับแต่ละกรณีโดยเฉพาะ สคริปต์การซ่อมแซมอัตโนมัติควรมุ่งเป้าไปที่การกำจัดสาเหตุของปัญหา คุณเป็นผู้กำหนดการกระทำที่ถูกต้องเพื่อตอบสนองต่อเหตุการณ์
ตัววัดใดๆ จากระบบการตรวจสอบของคุณสามารถทำหน้าที่เป็นตัวกระตุ้นให้เริ่มการทำงานของสคริปต์ได้ สิ่งสำคัญคือตัววัดเหล่านี้จะระบุได้อย่างแม่นยำว่าทุกอย่างไม่ดี เนื่องจากคุณไม่ต้องการได้รับผลบวกลวงในสภาพแวดล้อมที่มีประสิทธิผล
คุณสามารถใช้ระบบหรือชุดของระบบใดก็ได้: Prometheus, ELK Stack, Zabbix ฯลฯ แต่ฉันจะยกตัวอย่างตามโซลูชัน APM (Dynatrace จะเป็นตัวอย่างอีกครั้ง) ซึ่งจะช่วยทำให้ชีวิตของคุณง่ายขึ้นด้วย
ประการแรก มีทุกสิ่งที่เกี่ยวข้องกับประสิทธิภาพในแง่ของการทำงานของแอปพลิเคชัน โซลูชันนี้มีตัววัดหลายร้อยตัวในระดับต่างๆ ที่คุณสามารถใช้เป็นตัวกระตุ้นได้:
- ระดับผู้ใช้ (เบราว์เซอร์ แอปพลิเคชันมือถือ อุปกรณ์ IoT พฤติกรรมผู้ใช้ คอนเวอร์ชัน ฯลฯ)
- ระดับของการบริการและการปฏิบัติการ (ประสิทธิภาพ ความพร้อมใช้งาน ข้อผิดพลาด ฯลฯ)
- ระดับโครงสร้างพื้นฐานของแอปพลิเคชัน (หน่วยวัดระบบปฏิบัติการโฮสต์, JMX, MQ, เว็บเซิร์ฟเวอร์ ฯลฯ );
- ระดับแพลตฟอร์ม (การจำลองเสมือน, คลาวด์, คอนเทนเนอร์ ฯลฯ )
การตรวจสอบระดับใน Dynatrace
ประการที่สอง ตามที่ฉันได้กล่าวไว้ก่อนหน้านี้ Dynatrace มี API แบบเปิด ซึ่งทำให้ง่ายมากในการผสานรวมกับระบบของบุคคลที่สามต่างๆ เช่น การส่งการแจ้งเตือนไปยังระบบอัตโนมัติเมื่อเกินพารามิเตอร์การควบคุม
ด้านล่างนี้เป็นตัวอย่างสำหรับการโต้ตอบกับ Ansible
ด้านล่างนี้ ฉันจะยกตัวอย่างว่าระบบอัตโนมัติประเภทใดที่สามารถทำได้ นี่เป็นเพียงส่วนหนึ่งของกรณีนี้ รายการในสภาพแวดล้อมของคุณสามารถจำกัดได้ด้วยจินตนาการและความสามารถของเครื่องมือตรวจสอบของคุณเท่านั้น
1. การปรับใช้ไม่ถูกต้อง - การย้อนกลับเวอร์ชัน
แม้ว่าเราจะทดสอบทุกอย่างได้ดีมากในสภาพแวดล้อมการทดสอบ แต่ก็ยังมีโอกาสที่รีลีสใหม่อาจทำให้แอปพลิเคชันของคุณเสียหายในสภาพแวดล้อมการใช้งานจริง ปัจจัยมนุษย์เดียวกันไม่ได้ถูกยกเลิก
ในรูปต่อไปนี้ เราจะเห็นว่ามีเวลาดำเนินการของบริการเพิ่มขึ้นอย่างรวดเร็ว จุดเริ่มต้นของการข้ามนี้เกิดขึ้นพร้อมกับเวลาของการปรับใช้กับแอปพลิเคชัน เราส่งข้อมูลทั้งหมดนี้ในรูปแบบเหตุการณ์ไปยังระบบอัตโนมัติ หากประสิทธิภาพของบริการไม่กลับมาเป็นปกติหลังจากเวลาที่เราตั้งไว้ สคริปต์จะถูกเรียกโดยอัตโนมัติซึ่งจะย้อนเวอร์ชันกลับไปเป็นเวอร์ชันเก่า
ประสิทธิภาพการดำเนินงานลดลงหลังจากการปรับใช้
2. กำลังโหลดทรัพยากรที่ 100% - เพิ่มโหนดในการกำหนดเส้นทาง
ในตัวอย่างต่อไปนี้ ระบบการมอนิเตอร์จะพิจารณาว่าหนึ่งในคอมโพเนนต์กำลังประสบปัญหาโหลด CPU 100%
โหลดซีพียู 100%
มีหลายสถานการณ์ที่เป็นไปได้สำหรับเหตุการณ์นี้ ตัวอย่างเช่น ระบบตรวจสอบจะตรวจสอบเพิ่มเติมว่าการขาดแคลนทรัพยากรเกี่ยวข้องกับการเพิ่มภาระในบริการหรือไม่ หากเป็นเช่นนั้น สคริปต์จะถูกดำเนินการซึ่งจะเพิ่มโหนดให้กับการกำหนดเส้นทางโดยอัตโนมัติ ดังนั้นจึงคืนค่าการทำงานของระบบโดยรวม
ปรับขนาดหลังเหตุการณ์
3. ขาดพื้นที่บนฮาร์ดไดรฟ์ - การทำความสะอาดดิสก์
ฉันคิดว่าหลายคนได้ทำกระบวนการเหล่านี้เป็นแบบอัตโนมัติแล้ว เมื่อใช้ APM คุณยังสามารถมอนิเตอร์พื้นที่ว่างบนระบบย่อยของดิสก์ได้ หากไม่มีพื้นที่ว่างหรือดิสก์ทำงานช้า เราจะเรียกสคริปต์เพื่อล้างข้อมูลหรือเพิ่มพื้นที่
โหลดแผ่นดิสก์ 100%
4. กิจกรรมผู้ใช้ต่ำหรือการแปลงต่ำ - สลับระหว่างสาขาสีน้ำเงินและสีเขียว
ฉันมักจะเห็นลูกค้าใช้สองลูป (ปรับใช้สีน้ำเงิน-เขียว) สำหรับแอปพลิเคชันในสภาพแวดล้อมการผลิต สิ่งนี้ช่วยให้คุณสลับระหว่างสาขาได้อย่างรวดเร็วเมื่อนำเสนอรุ่นใหม่ บ่อยครั้งหลังจากการปรับใช้ การเปลี่ยนแปลงครั้งใหญ่สามารถเกิดขึ้นได้โดยไม่สังเกตเห็นได้ในทันที ในกรณีนี้ อาจไม่สามารถสังเกตการเสื่อมประสิทธิภาพและความพร้อมใช้งานได้ หากต้องการตอบสนองต่อการเปลี่ยนแปลงดังกล่าวอย่างรวดเร็ว ควรใช้เมตริกต่างๆ ที่สะท้อนถึงพฤติกรรมของผู้ใช้ (จำนวนเซสชันและการกระทำของผู้ใช้, Conversion, อัตราตีกลับ) รูปต่อไปนี้แสดงตัวอย่างที่เมื่ออัตราการแปลงลดลง การสลับระหว่างสาขาซอฟต์แวร์จะเกิดขึ้น
อัตราการแปลงลดลงหลังจากสลับระหว่างสาขาซอฟต์แวร์
กลไกการตรวจจับปัญหาอัตโนมัติ
สุดท้ายนี้ ฉันจะให้อีกตัวอย่างหนึ่งแก่คุณว่าทำไมฉันถึงชอบ Dynatrace มากที่สุด
ในส่วนของเรื่องราวของฉันเกี่ยวกับการตรวจสอบคุณภาพของแอสเซมบลีอัตโนมัติในสภาพแวดล้อมการทดสอบ เราได้กำหนดค่าเกณฑ์ทั้งหมดด้วยตนเอง นี่เป็นเรื่องปกติสำหรับสภาพแวดล้อมการทดสอบ ผู้ทดสอบจะกำหนดตัวบ่งชี้ก่อนการทดสอบแต่ละครั้งโดยขึ้นอยู่กับโหลด ในสภาพแวดล้อมการผลิต เป็นที่พึงปรารถนาที่จะตรวจพบปัญหาโดยอัตโนมัติ โดยคำนึงถึงกลไกพื้นฐานต่างๆ
Dynatrace มีเครื่องมือปัญญาประดิษฐ์ในตัวที่น่าสนใจ ซึ่งใช้กลไกในการพิจารณาตัวชี้วัดที่ผิดปกติ (พื้นฐาน) และสร้างแผนที่ของการโต้ตอบระหว่างส่วนประกอบทั้งหมด การเปรียบเทียบและเชื่อมโยงเหตุการณ์ระหว่างกัน เพื่อกำหนดความผิดปกติในการดำเนินงานบริการของคุณและให้รายละเอียด ข้อมูลในแต่ละปัญหาและสาเหตุที่แท้จริง
ด้วยการวิเคราะห์การขึ้นต่อกันระหว่างส่วนประกอบต่าง ๆ โดยอัตโนมัติ Dynatrace จะตัดสินไม่เพียงแต่ว่าบริการที่เป็นปัญหาคือต้นตอของปัญหาเท่านั้น แต่ยังรวมถึงการขึ้นต่อกันของบริการอื่น ๆ ด้วย ในตัวอย่างด้านล่าง Dynatrace จะตรวจสอบและประเมินความสมบูรณ์ของแต่ละบริการภายในการดำเนินการธุรกรรมโดยอัตโนมัติ โดยระบุบริการ Golang ว่าเป็นสาเหตุที่แท้จริง
ตัวอย่างการระบุสาเหตุของความล้มเหลว
รูปภาพต่อไปนี้แสดงกระบวนการตรวจสอบปัญหากับแอปพลิเคชันของคุณตั้งแต่เริ่มต้นของเหตุการณ์
การแสดงภาพปัญหาที่เกิดขึ้นพร้อมการแสดงส่วนประกอบและเหตุการณ์ทั้งหมด
ระบบติดตามได้รวบรวมลำดับเหตุการณ์ทั้งหมดที่เกี่ยวข้องกับปัญหาที่เกิดขึ้น ในหน้าต่างด้านล่างไทม์ไลน์ เราจะเห็นเหตุการณ์สำคัญทั้งหมดในแต่ละองค์ประกอบ ตามเหตุการณ์เหล่านี้ คุณสามารถกำหนดขั้นตอนสำหรับการแก้ไขอัตโนมัติในรูปแบบของโค้ดสคริปต์ได้
นอกจากนี้ ฉันแนะนำให้คุณรวมระบบการตรวจสอบเข้ากับส่วนให้บริการหรือตัวติดตามจุดบกพร่อง เมื่อเกิดปัญหา นักพัฒนาจะได้รับข้อมูลที่ครบถ้วนอย่างรวดเร็วเพื่อวิเคราะห์ในระดับโค้ดในสภาพแวดล้อมการใช้งานจริง
ข้อสรุป
ด้วยเหตุนี้ เราจึงได้ไปป์ไลน์ CI/CD ที่มีการตรวจสอบคุณภาพซอฟต์แวร์อัตโนมัติในตัวใน Pipeline เราลดจำนวนแอสเซมบลีคุณภาพต่ำให้เหลือน้อยที่สุด เพิ่มความน่าเชื่อถือของระบบโดยรวม และหากระบบของเรายังคงล้มเหลว เราจะเปิดใช้กลไกเพื่อกู้คืน
การลงทุนกับการตรวจสอบคุณภาพซอฟต์แวร์โดยอัตโนมัตินั้นคุ้มค่าอย่างยิ่ง แม้ว่ากระบวนการนี้อาจไม่ใช่กระบวนการที่รวดเร็วเสมอไป แต่เมื่อเวลาผ่านไป ก็จะเกิดผล ฉันขอแนะนำว่าหลังจากแก้ไขเหตุการณ์ใหม่ในสภาพแวดล้อมการผลิตแล้ว คุณควรคิดทันทีว่าจอภาพใดที่จะเพิ่มสำหรับการตรวจสอบในสภาพแวดล้อมการทดสอบ เพื่อหลีกเลี่ยงบิลด์ที่ไม่ดีไม่ให้เข้าสู่การใช้งานจริง และสร้างสคริปต์เพื่อแก้ไขปัญหาเหล่านี้โดยอัตโนมัติ
ฉันหวังว่าตัวอย่างของฉันจะช่วยคุณในความพยายามของคุณ นอกจากนี้ ฉันยังสนใจที่จะเห็นตัวอย่างตัวชี้วัดที่ใช้ในการนำระบบการรักษาตนเองไปใช้
ที่มา: will.com