กำไร:
- ความสามารถในการสร้าง runbook การชันสูตรพลิกศพ และโครงกระดูกเอกสารทางสถาปัตยกรรมจากบันทึกที่กระจัดกระจายด้วยปัญญาประดิษฐ์
- ความสามารถในการบังคับใช้วินัยในการกำหนด 'การห้ามการผลิต' และการทดสอบและการทำเครื่องหมายแต่ละ runbook อย่างละเอียดในสภาพแวดล้อมจริง
- ความสามารถในการเข้าใจว่า Runbook ที่ไม่ถูกต้องนั้นอันตรายมากกว่าไม่มีเลย และช่วยให้เอกสารคงอยู่ตลอดกระบวนการเปลี่ยนแปลง
การจัดการเอกสารและข้อมูล: Runbook สถาปัตยกรรม และหน่วยความจำสถาบันด้วย AI
ภารกิจการจัดการระบบที่ถูกละเลยแต่ช่วยชีวิตได้มากที่สุดคือการจัดทำเอกสาร เมื่อระบบล่มและผู้ที่สร้างมันต้องพักร้อนและไม่มีการเขียนถึงวิธีกู้คืน ถือเป็นค่ำคืนที่ยาวนานสำหรับทุกคน เอกสารประกอบเป็นหน่วยความจำสถาบันที่เขียนและพร้อมใช้งานเกี่ยวกับวิธีการตั้งค่าระบบ วิธีการทำงาน และสิ่งที่ต้องดำเนินการหากเกิดปัญหา ประเภทที่สำคัญที่สุดของหน่วยความจำนี้คือ runbook: คู่มือการใช้งานที่บอกคุณทีละขั้นตอนว่าต้องทำอย่างไรในสถานการณ์ที่กำหนด (บริการขัดข้อง ดิสก์เต็ม การสำรองข้อมูลล้มเหลว) ที่นี่ AI แก้ปัญหา "หน้าว่าง" และ "ความเกียจคร้าน" ซึ่งเป็นศัตรูที่ใหญ่ที่สุดของการเขียนเอกสาร: โดยจะสร้าง runbook ที่จัดระเบียบจากบันทึกย่อที่กระจัดกระจายของคุณ ขั้นตอนจากประวัติคำสั่ง คำอธิบายจากสถาปัตยกรรม แต่หลักการที่สำคัญคือ AI ได้สร้างพิมพ์เขียวและโครงกระดูก คุณเป็นผู้ทดสอบและตรวจสอบแต่ละขั้นตอนเพื่อดูว่าถูกต้องหรือไม่ การรันบุ๊กที่ไม่ถูกต้องเป็นอันตรายมากกว่าการไม่มีรันบุ๊กเลย
ในหน่วยนี้ สมุดบัญชี การชันสูตรพลิกศพ (รายงานการสอบสวนหลังเหตุการณ์) เอกสารทางสถาปัตยกรรม และการเขียนฐานความรู้ การสร้างแบบร่างด้วย AI และที่สำคัญที่สุด คุณจะได้เรียนรู้ถึงความเสี่ยงของเอกสารที่ไม่ผ่านการตรวจสอบ
เหตุใด runbook ที่ไม่ถูกต้องจึงเลวร้ายยิ่งกว่าไม่มี runbook?
นี่คือแนวคิดที่สำคัญที่สุดของหน่วยนี้ ทีมที่ไม่มี Runbook จะต้องระมัดระวังและน่าสงสัยในช่วงเวลาแห่งความตื่นตระหนก คิดสองครั้งเกี่ยวกับทุกคำสั่ง แต่คนที่มีสมุดบัญชี "อย่างเป็นทางการ" ไว้วางใจมันอย่างสุ่มสี่สุ่มห้า - ในตอนกลางคืนภายใต้ความเครียดและดำเนินการตามขั้นตอนโดยไม่มีคำถาม หากรันบุ๊กนั้นถูกเผยแพร่โดยไม่ได้ผลิตและทดสอบโดย AI และมีขั้นตอนหนึ่งที่ผิดพลาด (คำสั่งที่ไม่ถูกต้อง ข้อกำหนดเบื้องต้นที่ขาดหายไป ขั้นตอนทางเลือกที่ข้ามไป) ผลลัพธ์ที่ได้คือหายนะ นั่นเป็นเหตุผลว่าทำไม Runbook ทุกเล่มที่ผลิตด้วย AI จึงต้องดำเนินการตั้งแต่ต้นจนจบในสภาพแวดล้อมจริง และทุกขั้นตอนจะต้องได้รับการตรวจสอบก่อนที่จะเผยแพร่ Runbook ที่ยังไม่ทดลองก็เหมือนกับคำสัญญาที่ให้ความมั่นใจแต่ว่างเปล่า
ข้อควรระวัง: ประทับตรา runbook ด้วย "ทดสอบแล้ว: [วันที่], [บุคคล]" ทำเครื่องหมายฉบับร่างที่ยังไม่ทดสอบอย่างชัดเจนด้วยป้ายกำกับ “ฉบับร่าง — ไม่ได้รับการยืนยัน” ดังนั้นจึงไม่มีใครใช้ขั้นตอนที่ไม่ได้รับการยืนยันได้อย่างปลอดภัยในภาวะวิกฤติที่แท้จริง
กายวิภาคของ runbook ที่ดี
Runbook ที่ดีประกอบด้วยส่วนต่างๆ ที่เฉพาะเจาะจง และ AI สามารถสร้างโครงกระดูกนั้นได้ดี: ชื่อและวัตถุประสงค์ (สำหรับสถานการณ์ใด) ข้อกำหนดเบื้องต้น (การเข้าถึงใด เครื่องมือใดที่จำเป็น) อาการ (เมื่อใดที่ฉันจะใช้ Runbook นี้) ขั้นตอน (พร้อมลำดับเลข คำสั่งที่คัดลอกได้) การตรวจสอบ (วิธีรับรู้ความสำเร็จหลังจากแต่ละขั้นตอน) การย้อนกลับ (วิธียกเลิกหากขั้นตอนหนึ่งเสีย) และการยกระดับ (ฉันจะโทรหาใครหากฉันไม่สามารถเข้าใจได้) คุณสามารถให้ AI บันทึกที่กระจัดกระจายของคุณและขอให้มันใส่ลงในโครงสร้างนี้ คุณมั่นใจในความถูกต้องของเนื้อหาเท่านั้น
ทีละขั้นตอน: การผลิตเอกสารด้วย AI
- รวบรวมวัตถุดิบ. ประวัติคำสั่งของคุณ บันทึกของคุณ อีเมลเก่า บันทึกการแชท เนื้อหาจริงแม้ว่าจะยุ่งเหยิง แต่ก็ยังดีกว่าการสร้าง AI
- ขอแบบโครงสร้าง. “ทำให้สิ่งนี้เป็น Runbook โดยมีหัวข้อต่อไปนี้: วัตถุประสงค์ ข้อกำหนดเบื้องต้น อาการ ขั้นตอน การตรวจสอบ การย้อนกลับ การยกระดับ”
- ห้ามการประดิษฐ์ "อย่าเพิ่มคำสั่ง, IP, เวอร์ชันหรือขั้นตอนใดๆ ที่ฉันไม่ได้แจ้งให้คุณ ทำเครื่องหมายส่วนที่ขาดหายไปว่า [ต้องกรอก]" วิธีนี้จะช่วยป้องกันข้อผิดพลาดที่อันตรายที่สุด — ขั้นตอนการเตรียมการที่ดูเหมือนจะเป็นไปได้
- หน้ากาก. ใช้ตัวยึดตำแหน่งแทนโฮสต์จริง, IP, ผู้ใช้ หากมีการแชร์เอกสารความลับก็ไม่ควรรั่วไหล
- ทดสอบเลย รัน runbook ตั้งแต่ต้นจนจบในสภาพแวดล้อมจริง (ควรทดสอบ) แก้ไขขั้นตอนที่ไม่ทำงาน หายไป หรือไม่ชัดเจน
- ประทับตราและเผยแพร่ เพิ่มวันที่ทดสอบ ผู้ทดสอบ และอัปเดตล่าสุด เอกสารมีชีวิตชีวา จะต้องได้รับการอัปเดตเมื่อระบบมีการเปลี่ยนแปลง
มินิเคสสามอัน
กรณีที่ 1 — ทำงาน 2 ชั่วโมง 15 นาที ผู้ดูแลระบบได้เลื่อนการจัดทำเอกสารขั้นตอนการกู้คืนข้อมูลสำรองออกไปเป็นเวลาหลายเดือน เขามอบประวัติคำสั่งเทอร์มินัล (สวมหน้ากาก) และบันทึกย่อที่กระจัดกระจายให้กับ AI และแทรกลงในกรอบงาน runbook AI สร้างโครงร่างที่เรียบร้อยใน 15 นาที ผู้ดูแลระบบใช้เวลา 45 นาทีในการรันแบบร่างตั้งแต่ต้นจนจบบนเซิร์ฟเวอร์ทดสอบ และแก้ไขสองขั้นตอนที่ขาดหายไป ผลลัพธ์: Runbook ที่ผ่านการทดสอบและเชื่อถือได้
กรณีที่ 2 — จับได้ว่าเป็นเท็จ ทีมงานให้ AI เขียน service restart runbook แต่ลืมแบน "fabrication" YZ เพิ่มคำสั่ง "ล้างแคชก่อน" ซึ่งดูสมเหตุสมผล แต่ไม่มีอยู่ในบริการนั้น โชคดีที่วิศวกรรันรันบุ๊กในสภาพแวดล้อมการทดสอบ คำสั่งนั้นทำให้เกิดข้อผิดพลาด ขั้นตอนการทดสอบบันทึกขั้นตอนที่สร้างขึ้นซึ่งจะสร้างความสับสนในภาวะวิกฤติที่แท้จริง
กรณีที่ 3 — การชันสูตรพลิกศพแบบเร่งด่วน หลังจากการไฟฟ้าดับครั้งใหญ่ ทีมงานจำเป็นต้องเขียนผลการชันสูตรพลิกศพ แต่ไม่มีใครสามารถเริ่มต้นได้ พวกเขาส่งไทม์ไลน์ของเหตุการณ์และบันทึกที่ปกปิดไว้ให้กับ AI และขอโครงกระดูกหลังการชันสูตรพลิกศพที่ไร้ตำหนิ ทั้งสรุป ผลกระทบ ไทม์ไลน์ สาเหตุที่แท้จริง และการดำเนินการแก้ไข พิมพ์เขียว AI ลดการทำงานหนึ่งชั่วโมงเหลือสิบนาที ทีมงานทุ่มเทแรงกายแรงใจในการตรวจสอบข้อเท็จจริงและชี้แจงประเด็นการดำเนินการ
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) การสร้างโครงกระดูก runbook:
บทบาทของคุณ: SRE อาวุโส สร้าง runbook จากบันทึกย่อ/ประวัติคำสั่งที่ปกปิดด้านล่าง หัวข้อ: วัตถุประสงค์ ข้อกำหนดเบื้องต้น อาการ (เมื่อใช้งาน) ขั้นตอน (ระบุหมายเลข สามารถคัดลอกได้) การตรวจสอบในแต่ละขั้นตอน การย้อนกลับ การยกระดับ กฎ: อย่าสร้างคำสั่ง/IP/เวอร์ชัน/ขั้นตอนใดๆ ที่ฉันไม่ได้ให้คุณ เขียนส่วนที่ขาดหายไป [TO BE FILLED] วัสดุ: [หมายเหตุสวมหน้ากาก]
2) การชันสูตรศพโดยไม่มีการตำหนิ:
บทบาทของคุณ: ผู้อำนวยความสะดวกในการสืบสวนเหตุการณ์ เขียนภาพร่างหลังการชันสูตรศพโดยปราศจากตำหนิจากไทม์ไลน์และบันทึกที่ปกปิดไว้ต่อไปนี้: สรุป ผลกระทบ (ระยะเวลา/ขอบเขต) เส้นเวลา สาเหตุที่แท้จริง (หากได้รับการยืนยัน) ปัจจัยที่มีส่วนร่วม การดำเนินการแก้ไข (เจ้าของ + ลำดับความสำคัญ) อย่าโทษคนแต่โฟกัสที่ระบบ อย่าเขียนสาเหตุที่แท้จริงโดยไม่มีหลักฐาน ข้อมูล: [...]
3) คำอธิบายสถาปัตยกรรม/บริการ:
เขียนเอกสารการบริการจากข้อมูลการกำหนดค่า/ไดอะแกรมที่ปกปิดต่อไปนี้: บริการทำหน้าที่อะไร ประกอบด้วยส่วนประกอบใดบ้าง การขึ้นต่อกันคืออะไร การไหลของข้อมูลเป็นอย่างไร พอร์ต/โปรโตคอลใด เก็บไว้เป็นเทคนิคแต่สามารถอ่านได้ ทำเครื่องหมายความสัมพันธ์ที่คุณไม่แน่ใจว่า "ต้องมีการยืนยัน" ข้อมูล: [สวมหน้ากาก]
4) การตรวจสอบทบทวนเอกสาร:
ตรวจสอบเอกสารที่มีอยู่ต่อไปนี้และตรวจสอบสกุลเงิน: (1) ส่วนใดที่ขาดหายไป/คลุมเครือ (2) ขั้นตอนใดบ้างที่ยังไม่ผ่านการทดสอบ (3) ข้อมูลใดบ้างที่อาจล้าสมัย เขียนสิ่งที่ฉันควรถาม/ยืนยันสำหรับการค้นพบแต่ละครั้ง เอกสาร: [เอกสารปกปิด]
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
พรอมต์ที่อ่อนแอ:
เขียน Runbook การบำรุงรักษาเซิร์ฟเวอร์ให้ฉัน
ไม่มีวัสดุที่แท้จริง AI สร้างข้อความทั้งหมดจากความรู้ทั่วไปของตัวเอง ซึ่งไม่เหมาะกับสภาพแวดล้อมของคุณหรือแม้แต่มีขั้นตอนที่ปรุงแต่งขึ้น นี่เป็นแหล่งที่อันตรายของความมั่นใจที่ผิดพลาด
พรอมต์อันทรงพลัง:
บทบาทของคุณ: SRE อาวุโส ด้านล่างนี้คือประวัติคำสั่งที่ปกปิดและบันทึกย่อของฉันที่ฉันนำไปใช้ในเหตุการณ์ "ดิสก์บริการการชำระเงินเต็ม" สร้าง runbook จากสิ่งเหล่านี้: วัตถุประสงค์, ข้อกำหนดเบื้องต้น (การเข้าถึง/เครื่องมือ), อาการ, ขั้นตอนที่กำหนดหมายเลข (ด้วยคำสั่งของฉัน), การตรวจสอบในแต่ละขั้นตอน, การย้อนกลับ, การยกระดับ อย่าให้ฉันทำตามคำสั่งที่ฉันไม่ได้ให้ ทำให้ช่องว่าง [TO BE FILLED] ใส่คำเตือน "ไม่ได้ทดสอบ" ในตอนท้าย วัสดุ: [ประวัติคำสั่งปกปิด]
ประเภทเอกสาร
การมีส่วนร่วมของเอไอ
ผลงานภาคบังคับของมนุษย์
หนังสือวิ่ง
โครงกระดูก + เค้าโครง
การทดสอบในสภาพแวดล้อมจริง แม่นยำ
หลังการชันสูตรพลิกศพ
โครงร่าง + โครงสร้าง
ตรวจสอบข้อเท็จจริงและสาเหตุที่แท้จริง
เอกสารทางสถาปัตยกรรม
คำอธิบาย + การไหล
ยืนยันความสัมพันธ์และการพึ่งพา
บทความฐานความรู้
ร่างด่วน
การตรวจสอบความเป็นปัจจุบันและความถูกต้อง
ข้อผิดพลาดทั่วไป
- การเผยแพร่ runbooks ที่ยังไม่ทดลอง ขั้นตอนที่ไม่ได้รับการยืนยันจะถูกนำไปใช้อย่างสุ่มสี่สุ่มห้าในช่วงวิกฤต runbook ผิดคือหายนะ
- ไม่ให้มีการสั่งห้ามการประดิษฐ์ หากคุณไม่บอก AI ว่า "อย่าเพิ่มสิ่งที่ฉันยังไม่ได้ให้" มันจะทำให้เกิดขั้นตอนที่สมเหตุสมผลแต่ไม่สมจริง
- ข้ามการมาสก์ ข้อมูลลับรั่วไหลเมื่อมีการแชร์เอกสารที่มีโฮสต์จริง, IP และผู้ใช้
- ไม่อัพเดตเอกสาร เอกสารที่ไม่ได้รับการอัพเดตเมื่อมีการเปลี่ยนแปลงระบบทำให้เข้าใจผิดเมื่อเวลาผ่านไป
- เผยแพร่โดยไม่ต้องประทับตรา ไม่ชัดเจนว่าเอกสารที่ไม่มีวันที่และสถานะการทดสอบจะเชื่อถือได้หรือเป็นแบบร่าง
เคล็ดลับ: วิธีที่ดีที่สุดในการคงเอกสารให้ “ใช้งานได้จริง” คือการผูกเอกสารเข้ากับกระบวนการเปลี่ยนแปลง: เมื่อระบบเปลี่ยนแปลง ปล่อยให้การอัปเดต runbook ที่เกี่ยวข้องเป็นหนึ่งในเกณฑ์ความสมบูรณ์สำหรับการเปลี่ยนแปลง AI เร่งความเร็วการอัปเดต แต่คุณเป็นกระบวนการที่กระตุ้น
โดยสรุป
เอกสารประกอบคือความทรงจำของสถาบัน Runbook เป็นแนวทางการดำเนินงานที่ช่วยชีวิตผู้คนในช่วงวิกฤต AI สร้างร่างที่จัดระเบียบจากบันทึกยุ่งๆ ของคุณ แก้ปัญหาหน้าว่างและความเกียจคร้าน แต่ความจริงที่สำคัญที่สุดคือ: Runbook ที่ไม่ถูกต้องมีอันตรายมากกว่าไม่มีเลย เนื่องจากจะถูกนำไปใช้อย่างสุ่มสี่สุ่มห้าในภาวะวิกฤติ ดังนั้นห้ามไม่ให้ AI "สร้าง" ปิดบังมัน และทดสอบอย่างละเอียดและประทับตราแต่ละ runbook ในสภาพแวดล้อมจริง รักษาเอกสารให้คงอยู่เมื่อระบบเปลี่ยนแปลง AI สร้างกรอบการทำงาน คุณคือผู้ที่รับประกันความถูกต้องและการทดสอบ
งานสมัคร
เลือกขั้นตอนที่ไม่ได้บันทึกไว้ในทีมของคุณ (เช่น เริ่มบริการใหม่หรือกู้คืนข้อมูลสำรอง) ปิดบังประวัติคำสั่งและบันทึกที่เกี่ยวข้องของคุณ และให้ AI สร้างแบบร่างโดยใช้เทมเพลต "การสร้างโครงกระดูก Runbook" ด้านบน อย่าลืมสั่งห้ามการประดิษฐ์ เรียกใช้แบบร่างในสภาพแวดล้อมการทดสอบและตั้งค่าสถานะและแก้ไขขั้นตอนที่เสียหาย/ขาดหายไป เพิ่มวันที่ทดสอบและข้อมูลผู้ทดสอบลงใน runbook เขียนความแตกต่างที่ AI สร้างขึ้นและคุณแก้ไขในกระบวนการเป็น 5 รายการ
รายการตรวจสอบ
- [ ] ฉันสร้าง runbook จากวัสดุจริง (หมายเหตุ ประวัติคำสั่ง) ฉันไม่ได้สร้างขึ้นใหม่ตั้งแต่ต้นใช่หรือไม่
- [ ] ฉันเคยแบน AI จาก "การเพิ่มคำสั่ง/IPs/ขั้นตอนที่ฉันไม่ได้ให้" หรือไม่?
- [ ] ฉันปกปิดข้อมูลที่ละเอียดอ่อน เช่น โฮสต์, IP และผู้ใช้หรือไม่
- [ ] ฉันได้เรียกใช้และตรวจสอบ runbook ในสภาพแวดล้อมจริง/ทดสอบแล้วหรือไม่
- [ ] ฉันได้เพิ่มวันที่ทดสอบ ผู้ทดสอบ และข้อมูลอัปเดตล่าสุดแล้วหรือยัง
- [ ] ฉันได้วางแผนที่จะเชื่อมโยงเอกสารกับกระบวนการเปลี่ยนแปลงระบบและอัปเดตให้ทันสมัยอยู่เสมอหรือไม่?