เราคิดที่จะสร้างระบบการตรวจสอบในขั้นตอนของการจัดตั้งทีมผลิตภัณฑ์ เห็นได้ชัดว่าธุรกิจของเรา - การแสวงหาผลประโยชน์ - ไม่อยู่ในทีมเหล่านี้ ทำไมเป็นอย่างนั้น?
ความจริงก็คือทีมของเราทั้งหมดสร้างขึ้นจากระบบข้อมูลส่วนบุคคล ไมโครเซอร์วิส และแนวหน้า ดังนั้นทีมจึงไม่เห็นความสมบูรณ์โดยรวมของระบบทั้งหมดโดยรวม ตัวอย่างเช่น พวกเขาอาจไม่รู้ว่าส่วนเล็กๆ ในส่วนลึกของแบ็กเอนด์ส่งผลต่อส่วนหน้าอย่างไร ขอบเขตความสนใจของพวกเขาจำกัดอยู่ที่ระบบที่รวมระบบเข้าด้วยกัน หากทีมและบริการ A แทบไม่มีความเกี่ยวข้องกับบริการ B เลย บริการดังกล่าวแทบจะมองไม่เห็นสำหรับทีม
ในทางกลับกัน ทีมงานของเราทำงานร่วมกับระบบที่มีการบูรณาการอย่างแน่นหนาระหว่างกัน: มีการเชื่อมต่อมากมายระหว่างระบบ นี่เป็นโครงสร้างพื้นฐานที่มีขนาดใหญ่มาก และการดำเนินงานของร้านค้าออนไลน์นั้นขึ้นอยู่กับระบบเหล่านี้ทั้งหมด (ซึ่งเรามีจำนวนมาก)
ปรากฎว่าแผนกของเราไม่ได้อยู่ในทีมใด ๆ แต่ตั้งอยู่ด้านข้างเล็กน้อย ในเรื่องราวทั้งหมดนี้ งานของเราคือการทำความเข้าใจอย่างครอบคลุมว่าระบบข้อมูลทำงานอย่างไร ฟังก์ชันการทำงาน การผสานรวม ซอฟต์แวร์ เครือข่าย ฮาร์ดแวร์ และวิธีเชื่อมต่อทั้งหมดนี้เข้าด้วยกัน
แพลตฟอร์มที่ร้านค้าออนไลน์ของเราดำเนินการมีลักษณะดังนี้:
- ด้านหน้า
- สำนักงานกลาง
- สำนักงานกลับ
ไม่ว่าเราต้องการมากแค่ไหน มันก็ไม่ได้เกิดขึ้นที่ระบบทั้งหมดจะทำงานได้อย่างราบรื่นและไร้ที่ติ ประเด็นสำคัญอีกครั้งคือจำนวนระบบและการบูรณาการ - สำหรับเหตุการณ์คล้าย ๆ กับเรา เหตุการณ์บางอย่างก็หลีกเลี่ยงไม่ได้ แม้ว่าจะมีคุณภาพของการทดสอบก็ตาม ยิ่งไปกว่านั้น ทั้งภายในระบบที่แยกจากกันและในแง่ของการบูรณาการ และคุณจำเป็นต้องตรวจสอบสถานะของแพลตฟอร์มทั้งหมดอย่างครอบคลุม ไม่ใช่แค่ส่วนใดส่วนหนึ่งเท่านั้น
ตามหลักการแล้ว การตรวจสอบสุขภาพทั่วทั้งแพลตฟอร์มควรเป็นแบบอัตโนมัติ และเรามาถึงการตรวจสอบซึ่งเป็นส่วนหนึ่งของกระบวนการนี้อย่างหลีกเลี่ยงไม่ได้ ในตอนแรก มันถูกสร้างมาสำหรับส่วนหน้าเท่านั้น ในขณะที่ผู้เชี่ยวชาญด้านเครือข่าย ผู้ดูแลระบบซอฟต์แวร์และฮาร์ดแวร์มีและยังคงมีระบบตรวจสอบแบบเลเยอร์ต่อเลเยอร์เป็นของตัวเอง คนเหล่านี้ติดตามผลในระดับของตนเองเท่านั้นไม่มีใครมีความเข้าใจอย่างถ่องแท้เช่นกัน
ตัวอย่างเช่น หากเครื่องเสมือนขัดข้อง ในกรณีส่วนใหญ่ มีเพียงผู้ดูแลระบบที่รับผิดชอบด้านฮาร์ดแวร์และเครื่องเสมือนเท่านั้นที่รู้เรื่องนี้ ในกรณีเช่นนี้ ทีมงานแนวหน้ามองเห็นข้อเท็จจริงของข้อขัดข้องของแอปพลิเคชัน แต่ไม่มีข้อมูลเกี่ยวกับข้อขัดข้องของเครื่องเสมือน และผู้ดูแลระบบสามารถรู้ได้ว่าลูกค้าคือใครและมีความคิดคร่าวๆ เกี่ยวกับสิ่งที่กำลังทำงานอยู่บนเครื่องเสมือนนี้ โดยต้องเป็นโครงการขนาดใหญ่บางประเภท เขาคงไม่รู้เกี่ยวกับเจ้าตัวน้อยเลย ไม่ว่าในกรณีใด ผู้ดูแลระบบจะต้องไปหาเจ้าของและถามว่ามีอะไรอยู่ในเครื่องนี้ สิ่งใดที่ต้องกู้คืน และสิ่งใดที่ต้องเปลี่ยนแปลง และหากมีบางสิ่งที่ร้ายแรงจริงๆ พัง พวกเขาก็เริ่มวิ่งเป็นวงกลม - เพราะไม่มีใครเห็นระบบโดยรวม
ท้ายที่สุดแล้ว เรื่องราวที่แตกต่างกันดังกล่าวส่งผลต่อส่วนหน้า ผู้ใช้ และฟังก์ชันธุรกิจหลักของเรา นั่นก็คือ การขายออนไลน์ เนื่องจากเราไม่ได้เป็นส่วนหนึ่งของทีม แต่มีส่วนร่วมในการดำเนินการแอปพลิเคชันอีคอมเมิร์ซทั้งหมดโดยเป็นส่วนหนึ่งของร้านค้าออนไลน์ เราจึงรับหน้าที่สร้างระบบตรวจสอบที่ครอบคลุมสำหรับแพลตฟอร์มอีคอมเมิร์ซ
โครงสร้างระบบและสแต็ก
เราเริ่มต้นด้วยการระบุชั้นการตรวจสอบหลายชั้นสำหรับระบบของเรา ซึ่งภายในนั้นเราจะต้องรวบรวมตัวชี้วัด และทั้งหมดนี้จำเป็นต้องนำมารวมกัน ซึ่งเป็นสิ่งที่เราทำในขั้นตอนแรก ในขั้นตอนนี้ เรากำลังสรุปการรวบรวมเมตริกคุณภาพสูงสุดในทุกเลเยอร์ของเรา เพื่อสร้างความสัมพันธ์และทำความเข้าใจว่าระบบมีอิทธิพลซึ่งกันและกันอย่างไร
การขาดการตรวจสอบที่ครอบคลุมในช่วงเริ่มต้นของการเปิดตัวแอปพลิเคชัน (ตั้งแต่เราเริ่มสร้างมันในขณะที่ระบบส่วนใหญ่อยู่ในการผลิต) นำไปสู่ความจริงที่ว่าเรามีหนี้ทางเทคนิคที่สำคัญในการตั้งค่าการตรวจสอบของแพลตฟอร์มทั้งหมด เราไม่สามารถมุ่งเน้นไปที่การตั้งค่าการตรวจสอบสำหรับ IS เดียวและดำเนินการตรวจสอบอย่างละเอียด เนื่องจากระบบที่เหลือจะถูกทิ้งไว้โดยไม่มีการตรวจสอบเป็นระยะเวลาหนึ่ง เพื่อแก้ไขปัญหานี้ เราได้ระบุรายการตัวชี้วัดที่จำเป็นที่สุดสำหรับการประเมินสถานะของระบบข้อมูลตามเลเยอร์ และเริ่มนำไปใช้งาน
จึงตัดสินใจกินช้างเป็นชิ้น ๆ
ระบบของเราประกอบด้วย:
- ฮาร์ดแวร์;
- ระบบปฏิบัติการ;
- ซอฟแวร์;
- ส่วน UI ในแอปพลิเคชันการตรวจสอบ
- ตัวชี้วัดทางธุรกิจ
- แอปพลิเคชันบูรณาการ
- ความปลอดภัยของข้อมูล
- เครือข่าย
- ตัวปรับสมดุลการจราจร
ศูนย์กลางของระบบนี้คือการตรวจสอบตัวเอง โดยทั่วไปแล้ว เพื่อทำความเข้าใจสถานะของระบบทั้งหมด คุณจำเป็นต้องรู้ว่าเกิดอะไรขึ้นกับแอปพลิเคชันบนเลเยอร์เหล่านี้ทั้งหมดและทั่วทั้งชุดแอปพลิเคชัน
แล้วเรื่องสแต็คล่ะ
เราใช้ซอฟต์แวร์โอเพ่นซอร์ส ที่ศูนย์ เรามี Zabbix ซึ่งเราใช้เป็นระบบแจ้งเตือนเป็นหลัก ทุกคนรู้ดีว่ามันเหมาะอย่างยิ่งสำหรับการตรวจสอบโครงสร้างพื้นฐาน สิ่งนี้หมายความว่า? ตัวชี้วัดระดับต่ำที่ทุกบริษัทที่ดูแลศูนย์ข้อมูลของตนเองมี (และ Sportmaster มีศูนย์ข้อมูลของตนเอง) - อุณหภูมิเซิร์ฟเวอร์ สถานะหน่วยความจำ การจู่โจม ตัวชี้วัดอุปกรณ์เครือข่าย
เราได้รวม Zabbix เข้ากับ Telegram Messenger และ Microsoft Teams ซึ่งใช้งานกันเป็นทีม Zabbix ครอบคลุมเลเยอร์ของเครือข่าย ฮาร์ดแวร์ และซอฟต์แวร์บางอย่างจริง ๆ แต่ไม่ใช่ยาครอบจักรวาล เราปรับปรุงข้อมูลนี้จากบริการอื่นๆ บางอย่าง ตัวอย่างเช่น ในระดับฮาร์ดแวร์ เราเชื่อมต่อโดยตรงผ่าน API ไปยังระบบเวอร์ชวลไลเซชันของเราและรวบรวมข้อมูล
อะไรอีก. นอกจาก Zabbix แล้ว เรายังใช้ Prometheus ซึ่งช่วยให้เราตรวจสอบหน่วยวัดในแอปพลิเคชันสภาพแวดล้อมแบบไดนามิกได้ นั่นคือเราสามารถรับตัววัดแอปพลิเคชันผ่านตำแหน่งข้อมูล HTTP และไม่ต้องกังวลว่าตัววัดใดที่จะโหลดเข้าไปและตัวไหนไม่โหลด จากข้อมูลนี้ จึงสามารถพัฒนาแบบสอบถามเชิงวิเคราะห์ได้
แหล่งข้อมูลสำหรับเลเยอร์อื่นๆ เช่น ตัวชี้วัดทางธุรกิจ จะถูกแบ่งออกเป็นสามองค์ประกอบ
ประการแรก สิ่งเหล่านี้คือระบบธุรกิจภายนอก Google Analytics เรารวบรวมการวัดจากบันทึก จากนั้นเราได้รับข้อมูลเกี่ยวกับผู้ใช้ที่ใช้งานอยู่ คอนเวอร์ชัน และทุกอย่างที่เกี่ยวข้องกับธุรกิจ ประการที่สอง นี่คือระบบตรวจสอบ UI ควรอธิบายให้ละเอียดกว่านี้
กาลครั้งหนึ่งเราเริ่มต้นด้วยการทดสอบด้วยตนเอง และขยายไปสู่การทดสอบฟังก์ชันการทำงานและการผสานรวมโดยอัตโนมัติ จากนี้ เราได้ทำการตรวจสอบ โดยเหลือเพียงฟังก์ชันหลักเท่านั้น และใช้เครื่องหมายที่มีความเสถียรที่สุดเท่าที่จะเป็นไปได้และไม่เปลี่ยนแปลงบ่อยเมื่อเวลาผ่านไป
โครงสร้างทีมใหม่หมายความว่ากิจกรรมแอปพลิเคชันทั้งหมดจำกัดอยู่เฉพาะทีมผลิตภัณฑ์ ดังนั้นเราจึงหยุดทำการทดสอบล้วนๆ แต่เราสร้างการตรวจสอบ UI จากการทดสอบที่เขียนด้วย Java, Selenium และ Jenkins (ใช้เป็นระบบสำหรับเรียกใช้และสร้างรายงาน)
เรามีการทดสอบมากมาย แต่สุดท้ายเราก็ตัดสินใจไปที่ถนนสายหลัก ซึ่งเป็นตัวชี้วัดระดับบนสุด และถ้าเรามีการทดสอบเฉพาะจำนวนมาก จะทำให้ข้อมูลอัปเดตได้ยาก การเปิดตัวครั้งต่อไปแต่ละครั้งจะทำให้ระบบทั้งหมดเสียหายอย่างมาก และสิ่งที่เราจะทำคือแก้ไขมัน ดังนั้นเราจึงมุ่งเน้นไปที่สิ่งพื้นฐานที่ไม่ค่อยเปลี่ยนแปลง และเราเพียงติดตามสิ่งเหล่านั้นเท่านั้น
สุดท้าย ประการที่สาม แหล่งข้อมูลคือระบบการบันทึกแบบรวมศูนย์ เราใช้ Elastic Stack สำหรับบันทึก จากนั้นเราสามารถดึงข้อมูลนี้เข้าสู่ระบบการตรวจสอบของเราสำหรับตัวชี้วัดทางธุรกิจ นอกเหนือจากทั้งหมดนี้ เรายังมีบริการ Monitoring API ของเราเอง ซึ่งเขียนด้วยภาษา Python ซึ่งจะสอบถามบริการใดๆ ผ่านทาง API และรวบรวมข้อมูลจากบริการเหล่านั้นลงใน Zabbix
คุณลักษณะที่ขาดไม่ได้อีกประการหนึ่งของการตรวจสอบคือการแสดงภาพ ของเรามีพื้นฐานมาจาก Grafana มันโดดเด่นเหนือระบบการแสดงภาพอื่น ๆ ตรงที่ช่วยให้คุณแสดงภาพการวัดจากแหล่งข้อมูลที่แตกต่างกันบนแดชบอร์ด เราสามารถรวบรวมตัววัดระดับบนสุดสำหรับร้านค้าออนไลน์ได้ เช่น จำนวนคำสั่งซื้อในชั่วโมงสุดท้ายจาก DBMS ตัววัดประสิทธิภาพสำหรับระบบปฏิบัติการที่ร้านค้าออนไลน์นี้ใช้งานจาก Zabbix และตัววัดสำหรับอินสแตนซ์ของแอปพลิเคชันนี้ จากโพรมีธีอุส และทั้งหมดนี้ก็จะอยู่ในแดชบอร์ดเดียว ชัดเจนและเข้าถึงได้
ให้ฉันทราบเกี่ยวกับความปลอดภัย - ขณะนี้เรากำลังสรุประบบ ซึ่งเราจะรวมเข้ากับระบบการตรวจสอบทั่วโลกในภายหลัง ในความคิดของฉัน ปัญหาหลักที่อีคอมเมิร์ซเผชิญในด้านความปลอดภัยของข้อมูลนั้นเกี่ยวข้องกับบอท ตัวแยกวิเคราะห์ และการใช้กำลังดุร้าย เราจำเป็นต้องจับตาดูสิ่งนี้ เนื่องจากทั้งหมดนี้สามารถส่งผลกระทบอย่างยิ่งต่อทั้งการทำงานของแอปพลิเคชันและชื่อเสียงของเราจากมุมมองทางธุรกิจ และด้วยสแต็กที่เลือก เราจึงสามารถครอบคลุมงานเหล่านี้ได้สำเร็จ
จุดสำคัญอีกประการหนึ่งคือ Prometheus ประกอบเลเยอร์แอปพลิเคชัน ตัวเขาเองยังรวมเข้ากับ Zabbix อีกด้วย และเรายังมี Sitespeed ซึ่งเป็นบริการที่ช่วยให้เราสามารถดูพารามิเตอร์ต่างๆ เช่น ความเร็วในการโหลดเพจของเรา ปัญหาคอขวด การเรนเดอร์เพจ การโหลดสคริปต์ ฯลฯ นอกจากนี้ยังผสานรวม API อีกด้วย ดังนั้นตัวชี้วัดของเราจึงถูกรวบรวมใน Zabbix และดังนั้นเราจึงแจ้งเตือนจากที่นั่นด้วย ขณะนี้การแจ้งเตือนทั้งหมดถูกส่งไปยังวิธีการส่งหลัก (สำหรับตอนนี้เป็นอีเมลและโทรเลข และ MS Teams ก็เพิ่งเชื่อมต่อกัน) มีแผนที่จะอัปเกรดการแจ้งเตือนเป็นสถานะที่สมาร์ทบอททำงานเป็นบริการและให้ข้อมูลการตรวจสอบแก่ทีมผลิตภัณฑ์ที่สนใจทั้งหมด
สำหรับเรา ตัวชี้วัดมีความสำคัญไม่เพียงแต่สำหรับระบบข้อมูลแต่ละระบบเท่านั้น แต่ยังรวมถึงตัวชี้วัดทั่วไปสำหรับโครงสร้างพื้นฐานทั้งหมดที่แอปพลิเคชันใช้ด้วย: คลัสเตอร์ของเซิร์ฟเวอร์จริงที่เครื่องเสมือนทำงานอยู่ ตัวปรับสมดุลการรับส่งข้อมูล ตัวโหลดบาลานเซอร์เครือข่าย ตัวเครือข่ายเอง การใช้ช่องทางการสื่อสาร . ตัวชี้วัดเพิ่มเติมสำหรับศูนย์ข้อมูลของเราเอง (เรามีหลายศูนย์และโครงสร้างพื้นฐานมีขนาดค่อนข้างใหญ่)
ข้อดีของระบบการติดตามของเราคือช่วยให้เราเห็นสถานะสุขภาพของทุกระบบและสามารถประเมินผลกระทบที่มีต่อกันและต่อทรัพยากรที่ใช้ร่วมกันได้ และท้ายที่สุด ช่วยให้เรามีส่วนร่วมในการวางแผนทรัพยากร ซึ่งเป็นความรับผิดชอบของเราด้วย เราจัดการทรัพยากรเซิร์ฟเวอร์ - กลุ่มภายในอีคอมเมิร์ซ คอมมิชชั่นและการรื้อถอนอุปกรณ์ใหม่ ซื้ออุปกรณ์ใหม่เพิ่มเติม ดำเนินการตรวจสอบการใช้ทรัพยากร ฯลฯ ทุกปี ทีมจะวางแผนโครงการใหม่ พัฒนาระบบ และเป็นสิ่งสำคัญสำหรับเราในการจัดหาทรัพยากรให้พวกเขา
และด้วยความช่วยเหลือของตัวชี้วัด เราจึงเห็นแนวโน้มการใช้ทรัพยากรโดยระบบข้อมูลของเรา และจากสิ่งเหล่านี้ เราสามารถวางแผนบางสิ่งบางอย่างได้ ในระดับเวอร์ช่วลไลเซชั่น เรารวบรวมข้อมูลและดูข้อมูลเกี่ยวกับจำนวนทรัพยากรที่มีอยู่ตามศูนย์ข้อมูล และภายในศูนย์ข้อมูลแล้ว คุณจะเห็นการรีไซเคิล การกระจายสินค้าจริง และการใช้ทรัพยากร ยิ่งไปกว่านั้น ทั้งกับเซิร์ฟเวอร์แบบสแตนด์อโลนและเครื่องเสมือนและคลัสเตอร์ของเซิร์ฟเวอร์จริงที่เครื่องเสมือนเหล่านี้หมุนอย่างแรง
อนาคต
ตอนนี้เรามีแกนหลักของระบบพร้อมแล้ว แต่ยังมีหลายสิ่งที่ยังต้องดำเนินการ อย่างน้อยที่สุด นี่คือชั้นความปลอดภัยของข้อมูล แต่ก็เป็นสิ่งสำคัญเช่นกันในการเข้าถึงเครือข่าย พัฒนาการแจ้งเตือน และแก้ไขปัญหาความสัมพันธ์ เรามีเลเยอร์และระบบมากมาย และในแต่ละเลเยอร์ก็มีเมตริกอีกมากมาย มันกลายเป็น Matryoshka ในระดับ Matryoshka
หน้าที่ของเราคือการแจ้งเตือนที่ถูกต้องในท้ายที่สุด ตัวอย่างเช่น หากมีปัญหากับฮาร์ดแวร์ อีกครั้งกับเครื่องเสมือน และมีแอปพลิเคชันที่สำคัญ และบริการไม่ได้รับการสำรองในทางใดทางหนึ่ง เราพบว่าเครื่องเสมือนเสียชีวิต จากนั้นตัวชี้วัดทางธุรกิจจะแจ้งเตือนคุณ: ผู้ใช้หายไปที่ไหนสักแห่ง ไม่มีการแปลง UI ในอินเทอร์เฟซไม่พร้อมใช้งาน ซอฟต์แวร์และบริการก็หยุดทำงานเช่นกัน
ในสถานการณ์นี้ เราจะได้รับสแปมจากการแจ้งเตือน และสิ่งนี้ไม่เหมาะกับรูปแบบของระบบการตรวจสอบที่เหมาะสมอีกต่อไป มีคำถามเรื่องความสัมพันธ์เกิดขึ้น ดังนั้น ตามหลักการแล้ว ระบบตรวจสอบของเราควรพูดว่า: "พวกคุณ เครื่องจักรทางกายภาพของคุณเสียชีวิตแล้ว และแอปพลิเคชันนี้และตัวชี้วัดเหล่านี้ก็เช่นกัน" ด้วยความช่วยเหลือจากการแจ้งเตือนเพียงครั้งเดียว แทนที่จะโจมตีเราอย่างดุเดือดด้วยการแจ้งเตือนนับร้อยครั้ง ควรรายงานสิ่งสำคัญ - สาเหตุซึ่งช่วยในการขจัดปัญหาอย่างรวดเร็วเนื่องจากการแปลเป็นภาษาท้องถิ่น
ระบบการแจ้งเตือนและการประมวลผลการแจ้งเตือนของเราสร้างขึ้นจากบริการสายด่วนตลอด XNUMX ชั่วโมง การแจ้งเตือนทั้งหมดที่ถือว่าต้องมีและรวมอยู่ในรายการตรวจสอบจะถูกส่งไปที่นั่น การแจ้งเตือนแต่ละรายการจะต้องมีคำอธิบาย: เกิดอะไรขึ้น ความหมายจริงคืออะไร และมีผลกระทบอย่างไร และยังมีลิงก์ไปยังแดชบอร์ดและคำแนะนำเกี่ยวกับสิ่งที่ต้องทำในกรณีนี้
ทั้งหมดนี้เกี่ยวกับข้อกำหนดในการสร้างการแจ้งเตือน จากนั้นสถานการณ์สามารถพัฒนาไปในสองทิศทาง - ไม่ว่าจะมีปัญหาและจำเป็นต้องแก้ไข หรือระบบติดตามมีความล้มเหลว แต่ไม่ว่าในกรณีใดคุณต้องไปคิดออก
โดยเฉลี่ยแล้ว ขณะนี้เราได้รับการแจ้งเตือนประมาณร้อยรายการต่อวัน โดยคำนึงถึงข้อเท็จจริงที่ว่าความสัมพันธ์ของการแจ้งเตือนยังไม่ได้รับการกำหนดค่าอย่างเหมาะสม และหากเราต้องทำงานด้านเทคนิค และบังคับปิดบางสิ่ง จำนวนนั้นก็จะเพิ่มขึ้นอย่างมาก
นอกเหนือจากการตรวจสอบระบบที่เราดำเนินการและการรวบรวมตัวชี้วัดที่ถือว่ามีความสำคัญในด้านของเราแล้ว ระบบการตรวจสอบยังช่วยให้เรารวบรวมข้อมูลสำหรับทีมผลิตภัณฑ์ได้ สิ่งเหล่านี้สามารถมีอิทธิพลต่อองค์ประกอบของตัวชี้วัดภายในระบบข้อมูลที่เราตรวจสอบ
เพื่อนร่วมงานของเราอาจจะมาขอเพิ่มตัวชี้วัดที่จะเป็นประโยชน์สำหรับทั้งเราและทีมงาน หรือตัวอย่างเช่น ทีมอาจมีตัวชี้วัดพื้นฐานที่เรามีไม่เพียงพอ พวกเขาจำเป็นต้องติดตามตัวชี้วัดบางอย่างโดยเฉพาะ ใน Grafana เราสร้างพื้นที่สำหรับแต่ละทีมและให้สิทธิ์ผู้ดูแลระบบ นอกจากนี้ หากทีมต้องการแดชบอร์ด แต่พวกเขาไม่สามารถ/ไม่รู้ว่าต้องทำอย่างไร เราก็ช่วยพวกเขา
เนื่องจากเราอยู่นอกกระแสการสร้างมูลค่าของทีม การเผยแพร่ และการวางแผน เราจึงค่อย ๆ มาถึงข้อสรุปว่าการเผยแพร่ระบบทั้งหมดนั้นราบรื่นและสามารถเผยแพร่ได้ทุกวันโดยไม่ต้องประสานงานกับเรา และเป็นสิ่งสำคัญสำหรับเราในการตรวจสอบการเผยแพร่เหล่านี้ เนื่องจากอาจส่งผลกระทบต่อการทำงานของแอปพลิเคชันและทำลายบางสิ่งบางอย่าง และนี่เป็นสิ่งสำคัญ ในการจัดการการเผยแพร่ เราใช้ Bamboo จากจุดที่เราได้รับข้อมูลผ่าน API และสามารถดูได้ว่ามีการเผยแพร่ใดบ้างในระบบข้อมูลใดและสถานะของการเผยแพร่ และที่สำคัญที่สุดคือกี่โมง เราวางเครื่องหมายการเผยแพร่ซ้อนทับบนตัววัดที่สำคัญที่สำคัญ ซึ่งแสดงให้เห็นอย่างชัดเจนในกรณีที่เกิดปัญหา
ด้วยวิธีนี้เราจะเห็นความสัมพันธ์ระหว่างการออกใหม่และปัญหาที่เกิดขึ้น แนวคิดหลักคือการทำความเข้าใจว่าระบบทำงานอย่างไรในทุกเลเยอร์ ระบุปัญหาอย่างรวดเร็ว และแก้ไขได้รวดเร็วเช่นเดียวกัน ท้ายที่สุดแล้วมักเกิดขึ้นว่าสิ่งที่ใช้เวลามากที่สุดไม่ใช่การแก้ปัญหา แต่เป็นการค้นหาสาเหตุ
และในอนาคตในด้านนี้ เราต้องการมุ่งเน้นไปที่การดำเนินการเชิงรุก ตามหลักการแล้ว ฉันอยากจะทราบเกี่ยวกับปัญหาที่กำลังจะเกิดขึ้นล่วงหน้า ไม่ใช่หลังจากความเป็นจริง เพื่อที่ฉันจะได้ป้องกันมันแทนที่จะแก้ไข บางครั้งการแจ้งเตือนที่ผิดพลาดของระบบการตรวจสอบเกิดขึ้นทั้งจากข้อผิดพลาดของมนุษย์และเนื่องจากการเปลี่ยนแปลงในแอปพลิเคชันและเราดำเนินการเรื่องนี้ แก้ไขจุดบกพร่อง และพยายามเตือนผู้ใช้ที่ใช้งานกับเราเกี่ยวกับเรื่องนี้ก่อนที่จะมีการปรับเปลี่ยนระบบการตรวจสอบใด ๆ หรือดำเนินกิจกรรมเหล่านี้ในหน้าต่างทางเทคนิค
ดังนั้น ระบบจึงถูกเปิดตัวและทำงานได้สำเร็จตั้งแต่ต้นฤดูใบไม้ผลิ... และกำลังแสดงผลกำไรอย่างแท้จริง แน่นอนว่านี่ไม่ใช่เวอร์ชันสุดท้าย เราจะแนะนำฟีเจอร์ที่มีประโยชน์อีกมากมาย แต่ในปัจจุบัน ด้วยการผสานรวมและแอปพลิเคชันมากมาย การตรวจสอบอัตโนมัติจึงเป็นสิ่งที่หลีกเลี่ยงไม่ได้จริงๆ
หากคุณตรวจสอบโปรเจ็กต์ขนาดใหญ่ที่มีการบูรณาการจำนวนมากด้วย ให้เขียนความคิดเห็นว่าคุณพบหัวข้อย่อยอะไรบ้างสำหรับสิ่งนี้
ที่มา: will.com