กำไร:
- ค้นหาสัญญาณรบกวนอย่างรวดเร็วโดยใช้ AI เพื่อสรุป จัดกลุ่ม และบันทึกไทม์ไลน์
- ความสามารถในการแยกความสัมพันธ์และสาเหตุ และรักษาข้อเสนอแนะต้นตอของปัญญาประดิษฐ์เป็นสมมติฐานที่ต้องได้รับการตรวจสอบ
- ความสามารถในการเข้าถึงสาเหตุที่แท้จริงโดยการใช้วิธี '5 ทำไม' ด้วยปัญญาประดิษฐ์ และสนับสนุนแต่ละขั้นตอนด้วยหลักฐานที่แท้จริง
การวิเคราะห์บันทึกและการวิเคราะห์สาเหตุ: การค้นหาสัญญาณรบกวนด้วย AI
เมื่อระบบล่ม สิ่งแรกที่คุณดูคือบันทึก Log คือสตรีมข้อความที่เก็บบันทึกเวลาของ "สิ่งที่ฉันทำ เกิดอะไรขึ้น อะไรเสียหาย" ของระบบหรือแอปพลิเคชัน แต่โครงสร้างพื้นฐานที่ทันสมัยผลิตบันทึกได้หลายล้านบรรทัดต่อชั่วโมง มันไม่ใช่ทะเลแห่งข้อมูล แต่มักเป็นทะเลแห่งเสียงรบกวน การวิเคราะห์บันทึกเป็นศิลปะในการค้นหาสัญญาณที่สำคัญ (ข้อผิดพลาด ความผิดปกติ รูปแบบ) ในสัญญาณรบกวนนี้ กระบวนการตอบคำถาม “สาเหตุที่แท้จริงคืออะไร” หลังจากเหตุการณ์หนึ่งเรียกว่าการวิเคราะห์สาเหตุที่แท้จริง (RCA - Root Cause Analysis) ที่นี่ AI มีประสิทธิภาพมากในการสรุปบรรทัดหลายพันบรรทัดต่อวินาที แยกรูปแบบ สร้างไทม์ไลน์ และแสดงรายการสาเหตุที่เป็นไปได้ แต่คำเตือน: AI ก่อให้เกิดสาเหตุที่เป็นไปได้ คุณคือผู้ตรวจสอบในระบบว่าอันไหนจริงและตัดสินใจ
ในหน่วยนี้ คุณจะได้เรียนรู้วิธีสรุปบันทึกด้วย AI อย่างมั่นใจ วิธีสร้างไทม์ไลน์ของเหตุการณ์ วิธีแยกความแตกต่างระหว่างความสัมพันธ์ (การเปลี่ยนแปลงร่วมกัน) และสาเหตุ (สิ่งหนึ่งทำให้เกิดอีกสิ่งหนึ่ง) และวิธีการเรียกใช้วิธี RCA เช่น "5 Whys" กับ AI
เหตุใดความสัมพันธ์จึงไม่ใช่สาเหตุ
นี่เป็นแนวคิดที่สำคัญที่สุดของหน่วยนี้ เพียงเพราะสองเหตุการณ์เกิดขึ้นในเวลาเดียวกัน เหตุการณ์หนึ่งไม่ได้ทำให้เกิดอีกเหตุการณ์หนึ่ง CPU ของเซิร์ฟเวอร์และการรับส่งข้อมูลเครือข่ายอาจเพิ่มขึ้นในเวลาเดียวกัน แต่เหตุการณ์หนึ่งไม่ใช่ผลลัพธ์ของอีกเหตุการณ์หนึ่ง ทั้งสองเหตุการณ์อาจเป็นผลลัพธ์ของเหตุการณ์ที่สาม (เช่น การเริ่มต้นงานแบทช์) เมื่อ AI เห็นว่าหน่วยเมตริกเปลี่ยนแปลงไปพร้อมกัน ระบบจะตั้งสมมติฐานว่า “X อาจเกิดจาก Y” นี่คือจุดเริ่มต้น ไม่ใช่บทสรุป ในการตรวจสอบสาเหตุ คุณต้องแยกตัวแปร (ทริกเกอร์ X ในสภาพแวดล้อมการทดสอบและดูว่า Y เกิดขึ้นหรือไม่) หรือพิสูจน์กลไก (แสดงวิธีการทางเทคนิคที่ X สร้าง Y)
ข้อควรระวัง: ใช้ประโยคของ AI "นี่อาจเป็นเหตุให้เกิดสิ่งนี้" เป็นสมมติฐาน ไม่ใช่การค้นพบ ใน RCA สาเหตุที่แท้จริงที่ไม่ถูกต้องจะนำไปสู่การแก้ไขที่ไม่ถูกต้องและการเกิดซ้ำของเหตุการณ์ คุณพบผู้ต้องสงสัยรายแรกแล้ว ไม่ใช่สาเหตุ งานเริ่มต้นที่นั่น
ทีละขั้นตอน: การวิเคราะห์บันทึกด้วย AI
- ปรับขอบเขตให้แคบลง ระบุหน้าต่างเหตุการณ์ ไม่ใช่บันทึกทั้งหมด: "กิจกรรมเริ่มเวลา 14:05 น. วิกฤติตั้งแต่ 14:00–14:20 น." แจ้งช่วงเวลาและบริการที่เกี่ยวข้องแก่ AI
- หน้ากาก. บันทึกประกอบด้วย IP ภายใน ชื่อโฮสต์ ผู้ใช้ และโทเค็น มาสก์พวกมัน (10.x.x.x, host-A, user1, REDACTED) จากนั้นจึงส่งออก
- ขอสรุปและจัดกลุ่ม "จัดกลุ่มบันทึกนี้ตามความรุนแรง นับข้อผิดพลาดที่เกิดซ้ำ ค้นหาการประทับเวลาของข้อผิดพลาดแรก" ขอโครงสร้าง ไม่ใช่บันทึกดิบ
- ตั้งค่าไทม์ไลน์. “จัดกิจกรรมเหล่านี้ให้ตรงเวลาและแสดงสิ่งที่ตามมา” การค้นหาโดมิโนตัวแรกเป็นหนทางสู่สาเหตุที่แท้จริง
- ถามสมมติฐาน ไม่ใช่หลักฐาน “ระบุสาเหตุที่แท้จริงที่เป็นไปได้ตามลำดับความน่าจะเป็น และให้คำสั่งยืนยันแก่ฉันเพื่อรันบนระบบสำหรับแต่ละรายการ” ถามเพื่อการวินิจฉัยไม่ใช่ผลลัพธ์
- ตรวจสอบในระบบ. ทดสอบแต่ละสมมติฐานด้วยคำสั่งวินิจฉัยแบบอ่านอย่างเดียว (log grep, การสืบค้นสถานะ, เมตริก) กำจัดจนกว่าจะมีสาเหตุเดียวที่ยืนยันได้
5 ทำไมต้องใช้วิธี
เครื่องมือคลาสสิกและทรงพลังของ RCA คือ "5 Whys" โดยเริ่มจากอาการเดียวแล้วถามว่า "ทำไม" ห้าครั้ง การถามจะทำให้คุณทราบถึงสาเหตุที่แท้จริงภายใต้อาการที่ผิวเผิน ตัวอย่าง: "ไซต์ขัดข้อง เพราะเหตุใด แอปพลิเคชันเสียชีวิตเนื่องจากหน่วยความจำไม่เพียงพอ เพราะเหตุใด แบบสอบถามใช้หน่วยความจำทั้งหมด เพราะเหตุใด แบบสอบถามไม่ได้ใช้ดัชนี สาเหตุใด ดัชนีถูกลบในรุ่นล่าสุด เหตุใดจึงไม่พบสิ่งนี้ในการตรวจสอบการเปลี่ยนแปลง" สาเหตุที่แท้จริงไม่ได้อยู่ที่ "ไซต์ขัดข้อง" แต่เป็น "กระบวนการตรวจสอบการเปลี่ยนแปลงที่อ่อนแอ" AI จะเป็นพันธมิตรที่ดีในการสร้างห่วงโซ่นี้ แต่คุณต้องสำรองข้อมูลแต่ละขั้นตอน "ทำไม" ด้วยหลักฐานที่แท้จริง ไม่เช่นนั้น AI อาจสร้างห่วงโซ่ที่น่าเชื่อถือแต่เป็นเท็จ
มินิเคสสามอัน
กรณีที่ 1 — 40,000 เส้น 3 นาที ผู้ดูแลระบบได้เริ่มสแกนบันทึกแอปพลิเคชัน 40,000 บรรทัดด้วยตนเองในระหว่างการหยุดทำงานข้ามคืน เขาให้ส่วนที่เกี่ยวข้องของบันทึกที่ปกปิดไว้แก่ AI เป็นเวลา 20 นาที และขอสรุปและจัดกลุ่ม AI ทำเครื่องหมายจุดบกพร่อง OutOfMemory แรกเมื่อเวลา 02:14 น. ทันทีหลังจากจุดบกพร่องการหมดเวลาที่เพิ่มขึ้น วิศวกรได้รับใบบันทึกเวลาภายใน 3 นาที ยืนยันการวินิจฉัยเดิมบนแผงเมตริกของตัวเอง
กรณีที่ 2 — กลับจากสาเหตุที่แท้จริง ทีมงานคิดว่าสมมติฐานแรกของ AI ("บันทึกเต็มดิสก์") นั้นถูกต้องและล้างบันทึกแล้ว แต่เหตุการณ์ซ้ำรอยในวันรุ่งขึ้น ในรอบที่สอง พวกเขาใช้ "5 Whys" อย่างมีระเบียบวินัย เหตุผลที่แท้จริงก็คือข้อผิดพลาดของแอปพลิเคชันเขียนคอร์ดัมพ์หลายร้อยคอร์ต่อวินาที สมมติฐานแรกคือสหสัมพันธ์ เหตุผลที่แท้จริงนั้นแตกต่างออกไป การยอมรับโดยไม่มีการยืนยันทำให้ได้รับการอภัยโทษเพียงวันเดียวเท่านั้น
กรณีที่ 3 — ไทม์ไลน์พบผู้กระทำผิด มีบันทึกอุปกรณ์หลายสิบเครื่องในระหว่างที่เครือข่ายขัดข้องเป็นระยะๆ วิศวกรมอบบันทึกที่ปกปิดไว้ให้กับ AI และสร้างไทม์ไลน์ที่เป็นหนึ่งเดียว แผนภูมิแสดงให้เห็นว่าการหยุดทำงานแต่ละครั้งเริ่มต้น 30 วินาทีพอดีหลังจากข้อความตรวจสอบความสมบูรณ์ของสวิตช์สำรอง ความสัมพันธ์นี้เป็นเบาะแสที่ชัดเจน ทีมงานตรวจสอบข้อผิดพลาดของเฟิร์มแวร์ของคีย์บนอุปกรณ์และทำการเปลี่ยนใหม่
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) สรุปบันทึกและการจัดกลุ่ม:
ด้านล่างนี้คือบันทึกที่ปกปิดสำหรับ [บริการ] ตั้งแต่เวลา 14:00-14:20 น. บอกฉัน: (1) จัดกลุ่มและนับบรรทัดตามความรุนแรง (ข้อผิดพลาด/คำเตือน/ข้อมูล) (2) แสดงรายการรูปแบบข้อผิดพลาดที่เกิดซ้ำ 5 อันดับแรก (3) ค้นหาการประทับเวลาของข้อผิดพลาดแรก อย่าเขียนบันทึกดิบใหม่ เพียงให้ข้อมูลสรุปที่มีโครงสร้าง การเพิ่มบรรทัดที่สร้างขึ้น บันทึก: [บันทึกที่ถูกปกปิด]
2) การตั้งค่าไทม์ไลน์:
เราจัดเรียงบันทึกเหตุการณ์ที่ปกปิดต่อไปนี้ไว้ในไทม์ไลน์เดียว (การประทับเวลา + แหล่งที่มา + เหตุการณ์) แสดงสิ่งที่ตามมาและทำเครื่องหมายเหตุการณ์ที่ดูเหมือนจะเป็นสิ่งกระตุ้นแรก โปรดทราบว่านี่เป็นสมมติฐานและจำเป็นต้องตรวจสอบสาเหตุ การบันทึก: [การบันทึกแบบสวมหน้ากาก]
3) 5 เหตุผลที่พันธมิตร RCA:
บทบาทของคุณ: ผู้อำนวยความสะดวก RCA อาการ: [อาการ] ทำ “5 ทำไม” กับฉัน: “ทำไม” ในแต่ละขั้นตอน ถามผมจะตอบตามหลักฐานที่ผมมีคุณถามคำถามต่อไป หากหลักฐานของฉันไม่ชัดเจน โปรดเตือนฉันและบอกฉันว่าฉันต้องรวบรวมข้อมูลใดบ้าง อย่าประกาศสาเหตุที่แท้จริงโดยไม่มีหลักฐาน
4) คำสั่งสมมติฐาน + การตรวจสอบ:
แสดงรายการสาเหตุที่เป็นไปได้สำหรับอาการนี้ [อาการ] ตามลำดับความน่าจะเป็น ด้วยเหตุผลแต่ละข้อ: (ก) คุณสงสัยอะไร (ข) ให้คำสั่งการตรวจสอบแบบอ่านอย่างเดียวแก่ฉันเพื่อให้ทำงานบนระบบของฉัน (ห้ามลบ/เปลี่ยนแปลง) อธิบายว่าผลลัพธ์ใดที่ยืนยันหรือพิสูจน์หักล้างสมมติฐาน
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
พรอมต์ที่อ่อนแอ:
เกิดอะไรขึ้นกับบันทึกนี้? [บันทึกดิบ 10,000 บรรทัด]
การดำเนินการนี้จะทำให้ข้อมูลที่ละเอียดอ่อนรั่วไหลและปล่อยให้ AI โดยไม่มีบริบท AI อาจสะดุดบนเส้นสุ่มและให้เหตุผลเพียงผิวเผินหรือแม้แต่การแต่งขึ้น
พรอมต์อันทรงพลัง:
บทบาทของคุณ: SRE อาวุโส เหตุการณ์: บริการชำระเงินมีข้อผิดพลาด 50% ระหว่างเวลา 02:10-02:25 น. ด้านล่างนี้คือบันทึกที่ปกปิดของหน้าต่างนั้น ให้ฉัน (1) สรุปที่จัดกลุ่มตามความรุนแรง (2) การประทับเวลาของข้อผิดพลาดแรก (3) สาเหตุที่แท้จริงที่เป็นไปได้ตามลำดับความน่าจะเป็น และคำสั่งการตรวจสอบแบบอ่านอย่างเดียวสำหรับแต่ละรายการ ทำเครื่องหมายการอ้างสาเหตุเป็นสมมติฐาน บันทึก: [บันทึกที่ถูกปกปิด]
ขั้นตอน
วัตถุประสงค์
บทบาทของเอไอ
บทบาทของผู้ชาย
สรุป/การจัดกลุ่ม
ลดเสียงรบกวน
การกำหนดค่าหลายพันแถว
กำหนดขอบเขตและหน้ากาก
ไทม์ไลน์
ตามหาโดมิโนตัวแรก
การเรียงลำดับเหตุการณ์
ตรวจสอบแสตมป์
การสร้างสมมติฐาน
คัดแยกผู้ต้องสงสัย
รายการความเป็นไปได้
กรองตามบริบท
การตรวจสอบ
ค้นหาเหตุผลที่แท้จริง
แนะนำคำสั่งวินิจฉัย
รันคำสั่งและแสดงความคิดเห็น
การตัดสินใจ
เลือกที่จะแก้ไข
เสนอตัวเลือก
ตัดสินใจและยืนยัน
ข้อผิดพลาดทั่วไป
- ความสัมพันธ์ที่ผิดพลาดสำหรับสาเหตุ การยอมรับตัวชี้วัดสองตัวที่เปลี่ยนแปลงร่วมกันเป็น "ตัวหนึ่งทำให้เกิดอีกตัวหนึ่ง" ทำให้เกิดการแก้ไขที่ผิดพลาด
- การวางบันทึกดิบโดยไม่มีการมาสก์ การให้บันทึกที่มี IP, โทเค็น และผู้ใช้แก่เครื่องมือที่เปิดอยู่ถือเป็นการละเมิดความปลอดภัย
- การประกาศสมมติฐานแรกว่าเป็นสาเหตุที่แท้จริง การยอมรับข้อเสนอแนะแรกของ AI โดยไม่ยืนยันว่าเป็นการเชิญชวนให้ทำกิจกรรมซ้ำ
- ส่งออกบันทึกทั้งหมด บันทึกขนาดใหญ่ที่ไม่มีบริบทจะเสียบ AI เข้ากับเส้นสุ่ม ยุบไปที่หน้าต่างเหตุการณ์
- 5 เหตุผลที่ไม่มีหลักฐาน หากคุณไม่สำรองข้อมูลแต่ละขั้นตอน "ทำไม" ด้วยข้อมูลจริง คุณจะจบลงด้วยห่วงโซ่ที่น่าเชื่อถือแต่ถูกสร้างขึ้นมา
เคล็ดลับ: ก่อนที่จะจบ RCA ให้ถามว่า "หากต้นเหตุนี้ได้รับการแก้ไขแล้วจริงๆ จะไม่เกิดขึ้นอีกหรือไม่" ถามคำถาม. หากคำตอบคือ "อาจจะ" แสดงว่าคุณยังไม่ได้ทราบสาเหตุที่แท้จริง ถามอีกว่า "ทำไม"
โดยสรุป
การวิเคราะห์บันทึกเป็นเรื่องเกี่ยวกับการค้นหาสัญญาณในมหาสมุทรแห่งเสียงรบกวน AI สรุปและจัดโครงสร้างมหาสมุทรนี้ภายในไม่กี่วินาที กำหนดไทม์ไลน์ และสร้างสมมติฐาน แต่ความสัมพันธ์ไม่ใช่สาเหตุ สาเหตุที่ AI แนะนำนั้นเป็นความสงสัยเบื้องต้น ไม่ใช่การค้นพบจนกว่าจะได้รับการยืนยัน ยุบบันทึกลงในหน้าต่างเหตุการณ์ ปิดบัง ขอโครงสร้าง เจาะลึกด้วย “5 Whys” และทดสอบแต่ละสมมติฐานบนระบบด้วยคำสั่งแบบอ่านอย่างเดียว คุณคือผู้ค้นหาสาเหตุที่แท้จริงและยืนยันการแก้ไข AI คือเพื่อนของคุณ
งานสมัคร
รวบรวมบันทึกของเหตุการณ์ที่ผ่านมา (หรือเหตุการณ์ทดสอบ) ยุบลงในหน้าต่างเหตุการณ์ และปกปิดพื้นที่ละเอียดอ่อน ขอสรุปและกำหนดการจาก AI ด้วยเทมเพลต "สรุปบันทึก" และ "ไทม์ไลน์" ด้านบน จากนั้นย้ายจากอาการไปยังสาเหตุที่แท้จริงด้วยเทมเพลต "5 เหตุผลที่พันธมิตร RCA" เขียนหลักฐานของคุณเองสำหรับแต่ละขั้นตอน สุดท้าย ทดสอบสมมติฐานเบื้องต้นของ AI ด้วยคำสั่งการตรวจสอบ และบันทึกว่าได้รับการยืนยันหรือหักล้างหรือไม่ สรุปกระบวนการเป็น 6 ข้อ
รายการตรวจสอบ
- [ ] ฉันได้ยุบบันทึกลงในหน้าต่างกิจกรรมและปกปิดพื้นที่ละเอียดอ่อนหรือไม่?
- [ ] ฉันขอ AI เพื่อสรุปและไทม์ไลน์ที่มีโครงสร้าง ไม่ใช่บันทึกดิบหรือไม่?
- [ ] ฉันทำเครื่องหมายการอ้างเหตุผลของ AI ว่าเป็นสมมติฐานหรือไม่
- [ ] ฉันได้ทดสอบแต่ละสมมติฐานบนระบบด้วยคำสั่งตรวจสอบยืนยันแบบอ่านอย่างเดียวหรือไม่
- [ ] ฉันได้สำรองข้อมูลแต่ละขั้นตอนของ “5 ทำไม” ด้วยหลักฐานจริงหรือไม่?
- [ ] ฉันได้ตั้งคำถามและตัดสินใจว่าสาเหตุที่แท้จริงจะป้องกันเหตุการณ์นี้ได้หรือไม่?