พื้นฐาน AI
การทำอัตโนมัติของเหตุการณ์คืออะไร? กระบวนการทำงาน, แนวทางควบคุม, และกรณีการใช้งาน
เพิ่ม Unite.AI ลงในแหล่งข้อมูลที่คุณต้องการบน Google
การทำอัตโนมัติของเหตุการณ์ใช้ซอฟต์แวร์เพื่อตรวจจับ, เสริมข้อมูล, ส่งต่อ, ประสานงาน, และบางครั้งแก้ไขเหตุการณ์ด้านการปฏิบัติการหรือความปลอดภัย มันเชื่อมสัญญาณการตรวจสอบกับคู่มือการดำเนินการ, ระบบตั๋ว, การสื่อสาร, การควบคุมการเข้าถึง, และการกระทำการกู้คืน เพื่อให้ผู้ตอบสนองใช้เวลาน้อยลงในการคัดลอกข้อมูลและใช้เวลามากขึ้นในการตัดสินใจ
การทำอัตโนมัติไม่ใช่การกำจัดความรับผิดชอบของมนุษย์ โปรแกรมที่ปลอดภัยจะแยกขั้นตอนเชิงกำหนดที่มีความเสี่ยงต่ำออกจากการกระทำที่อาจส่งผลต่อผู้ใช้หรือการผลิต แล้วจึงใช้การอนุมัติ, การให้สิทธิ์ที่จำกัด, บันทึกการตรวจสอบ, เวลาจำกัด, และการย้อนกลับตามผลกระทบ
ประเด็นสำคัญ
- ทำอัตโนมัติการรวบรวมหลักฐานที่ทำซ้ำได้ก่อนพยายามแก้ไขด้วยระบบอัตโนมัติ
- ใช้ระดับความรุนแรง, ความมั่นใจ, ระยะผลกระทบ, และความสามารถในการย้อนกลับเพื่อเลือกระดับการอนุมัติ
- ปฏิบัติต่อคู่มือการดำเนินการแต่ละรายการเหมือนโค้ดการผลิตที่มีเวอร์ชันพร้อมการทดสอบและเจ้าของ
- วัดการตรวจจับ, การรับทราบ, การกู้คืน, การเกิดซ้ำ, และผลกระทบต่อผู้ใช้—not เพียงปริมาณการแจ้งเตือน
จากสัญญาณสู่การตอบสนองที่ประสานงาน
กระบวนการทำงานอาจทำการลบการแจ้งเตือนที่ซ้ำซ้อน, แนบการปรับใช้และบันทึกล่าสุด, ระบุเจ้าของบริการ, เปิดบันทึกเหตุการณ์, เรียกทีมผู้อยู่บนสาย, สร้างช่องทางการสื่อสาร, และเริ่มไทม์ไลน์ ขั้นตอนเหล่านี้ช่วยลดภาระความคิดโดยไม่ทำการวินิจฉัยที่เสี่ยงโดยอัตโนมัติ
การเชื่อมโยงต้องรักษาหลักฐานไว้ หากแพลตฟอร์มจัดกลุ่มอาการมากเกินไปอาจทำให้เหตุการณ์ที่เกิดพร้อมกันถูกซ่อน เชื่อมการทำอัตโนมัติกับการเป็นเจ้าของการดำเนินงานไอทีและเก็บสัญญาณดิบที่ผู้ตอบสนองอาจต้องการ
เลือกการกระทำตามความเสี่ยง
การสอบถามแบบอ่านอย่างเดียว, การจับภาพสแนปช็อต, และการเปลี่ยนแปลงการจราจรที่ย้อนกลับได้มักง่ายต่อการทำอัตโนมัติมากกว่าการลบข้อมูล, การหมุนรหัสผ่านกว้าง, หรือการเปลี่ยนแปลงสคีมาการผลิต กำหนดเงื่อนไขก่อน, เวลาจำกัดการดำเนินการ, เงื่อนไขหลัง, และการย้อนกลับสำหรับแต่ละการกระทำ
ใช้ตัวตนของบริการที่มีสิทธิ์น้อยที่สุดและแยกการอนุญาตออกจากเครื่องมือกระบวนการทำงาน ขั้นตอนที่มีผลกระทบสูงควรต้องการผู้อนุมัติที่ระบุ หาก AIOps เสนอสาเหตุหรือการแก้ไข ผู้ตอบสนองยังคงต้องการหลักฐานสนับสนุนและวิธีที่ปลอดภัยในการปฏิเสธ
สร้างคู่มือการดำเนินการที่เชื่อถือได้
คู่มือการดำเนินการควรระบุอินพุต, การพึ่งพา, เจ้าของ, ขอบเขต, พฤติกรรมเมื่อเกิดความล้มเหลว, และหลักฐานที่สร้างขึ้น ทดสอบในสเตจและในวันฝึกซ้อม ขั้นตอนที่เป็นอิดีโปเทนท์มีคุณค่าเพราะการลองใหม่จะไม่ก่อให้เกิดอันตรายเพิ่มเติม
ทำเวอร์ชันและตรวจสอบการทำอัตโนมัติเช่นซอฟต์แวร์อื่น ๆ ตรวจสอบการหมดอายุของข้อมูลรับรอง, การเปลี่ยนแปลง API, ขีดจำกัดอัตรา, การดำเนินการบางส่วน, และการเชื่อมโยงที่ซ่อนอยู่ระหว่างบริการ ขั้นตอนแบบแมนนวลยังคงจำเป็นเมื่อแพลตฟอร์มอัตโนมัติเองไม่พร้อมใช้งาน
เรียนรู้หลังการกู้คืน
การทำอัตโนมัติควรเก็บบันทึกที่มีการประทับเวลาของสัญญาณ, การตัดสินใจ, การกระทำ, การอนุมัติ, และผลลัพธ์ การตรวจสอบแบบไม่มีการตำหนิสามารถแยกเงื่อนไขของระบบที่มีส่วนร่วมออกจากตัวกระตุ้นสุดท้ายและเปลี่ยนบทเรียนเป็นการปรับปรุงที่ทดสอบแล้ว
มาตรการที่เป็นประโยชน์รวมถึงค่าเฉลี่ยเวลาที่ใช้ในการรับทราบและกู้คืน, เปอร์เซ็นต์ของขั้นตอนที่ปลอดภัยที่ทำอัตโนมัติ, อัตราการกระทำที่ล้มเหลว, เหตุการณ์ที่เกิดซ้ำ, และผลกระทบต่อผู้ใช้ เชื่อมผลลัพธ์กับการวางแผน DevOps แทนการมุ่งเน้นจำนวนตั๋วที่ปิด
ประเภทของการทำอัตโนมัติของเหตุการณ์
การทำอัตโนมัติของเหตุการณ์ทำให้สัญญาณที่เข้ามามีรูปแบบเดียวและเสริมข้อมูล การทำอัตโนมัติของการประสานงานสร้างบันทึกเหตุการณ์, เรียกเจ้าของ, เปิดช่องทางการสื่อสาร, และโพสต์การอัปเดตสถานะ การทำอัตโนมัติการวินิจฉัยทำการสอบถามแบบอ่านอย่างเดียวหรือจับภาพสแนปช็อต การทำอัตโนมัติการแก้ไขเปลี่ยนสถานะของระบบ, ส่วนการทำอัตโนมัติการกู้คืนตรวจสอบสุขภาพของบริการและปิดการบรรเทาชั่วคราว
ประเภทเหล่านี้ไม่ควรใช้ระดับความเชื่อมั่นเริ่มต้นเดียวกัน การเสริมข้อมูลมักสามารถทำได้โดยอัตโนมัติ; การสลับการทำงานของการผลิตอาจต้องการการตรวจสอบความมั่นใจและผู้อนุมัติ; การกู้คืนข้อมูลมักต้องการผู้บังคับบัญชาเหตุการณ์และเจ้าของแอปพลิเคชัน การควบคุมควรตามผลกระทบที่เป็นไปได้ ไม่ใช่ว่าขั้นตอนนั้นทำโดยกฎหรือโมเดลการเรียนรู้ของเครื่อง
เหตุการณ์ด้านความปลอดภัยเพิ่มข้อกำหนดการรักษาหลักฐาน การทำอัตโนมัติควรหลีกเลี่ยงการแก้ไขโฮสต์ที่ถูกทำลายก่อนที่ข้อมูลที่เปลี่ยนแปลงได้จะถูกจับ, การเปิดเผยตัวบ่งชี้ที่ละเอียดอ่อนในช่องทางสาธารณะ, หรือการกักกันโครงสร้างพื้นฐานที่ใช้ร่วมกันโดยไม่เข้าใจระยะผลกระทบ คู่มือการดำเนินงานและฟอเรนซิกส์อาจทับซ้อนกัน แต่ลำดับของพวกมันอาจแตกต่างกัน
การออกแบบกระบวนการทำงานและแผนควบคุม
จำลองคู่มือการดำเนินการเป็นสถานะที่ชัดเจนพร้อมเงื่อนไขก่อนและผลลัพธ์สุดท้าย ทุกการกระทำควรรายงานว่าเริ่ม, สำเร็จ, ล้มเหลว, หมดเวลา, หรือข้าม, พร้อมกับตัวระบุการดำเนินการที่ไม่เปลี่ยนแปลง ตัวประสานงานศูนย์กลางสามารถประสานขั้นตอนได้ แต่บริการต่อไปควรบังคับใช้การอนุญาตของตนเองและตรวจสอบอินพุตอย่างอิสระ
ใช้ข้อมูลรับรองที่จำกัดและอายุสั้นและจำกัดเส้นทางเครือข่ายจากเครื่องยนต์อัตโนมัติ แยกผู้ดำเนินการสำหรับการพัฒนา, การทดสอบ, และการผลิต ความลับต้องไม่ปรากฏในบันทึกแชทหรือบันทึกเหตุการณ์ สำหรับการกระทำที่มีผลกระทบสูง ต้องการการอนุมัติจากสองคนหรือบทบาทฉุกเฉินที่การใช้งานสร้างเส้นทางการตรวจสอบทันที
ออกแบบให้รองรับความล้มเหลวบางส่วน ตั๋วอาจถูกสร้างขณะที่การเรียกไม่สำเร็จ; การเปลี่ยนแปลงการจราจรอาจสำเร็จในบางภูมิภาคและหมดเวลาในอีกภูมิภาค การกระทำชดเชย, งานปรับความสอดคล้อง, และการเป็นเจ้าของที่ชัดเจน ป้องกันไม่ให้กระบวนการรายงานความสำเร็จเพียงเพราะกระบวนการประสานงานสิ้นสุดลง
ตัวอย่าง, การทดสอบ, และความพร้อม
กรณีการใช้งานแรกที่พร้อมคือการหมดการเชื่อมต่อฐานข้อมูล: รวบรวมเมตริกของพูล, การปรับใช้ล่าสุด, คำสั่งที่ทำงานช้า, และข้อมูลเจ้าของ; เปิดเหตุการณ์; เสนอการขยายหรือการกระทำการจราจรที่ย้อนกลับได้; ต้องการการอนุมัติ; จากนั้นตรวจสอบอัตราข้อผิดพลาดและความหน่วงเวลา รูปแบบเดียวกันสามารถใช้กับการหมดอายุใบรับรอง, ความดันดิสก์, งานที่ล้มเหลว, หรือกิจกรรมบัญชีที่น่าสงสัย
ทดสอบคู่มือการดำเนินการผ่านการทดสอบหน่วย, API จำลอง, เหตุการณ์สเตจ, วันฝึกซ้อม, และการฝึกผลิตภัณฑ์ที่ควบคุมได้ แทรกข้อมูลเก่า, การปฏิเสธสิทธิ์, การพึ่งพาที่ช้า, เหตุการณ์ซ้ำ, และเหตุการณ์ที่ขัดแย้ง ยืนยันว่าการลองใหม่ปลอดภัยและผู้ตอบสนองสามารถควบคุมแบบแมนนวลได้โดยไม่ต้องต่อสู้กับการทำอัตโนมัติ
ความพร้อมพัฒนาอย่างต่อเนื่องจากการแจ้งเตือน, การเสริมข้อมูล, การกระทำที่แนะนำ, ไปสู่การแก้ไขอัตโนมัติที่จำกัด การก้าวหน้าควรขึ้นอยู่กับหลักฐาน: การวินิจฉัยที่เสถียร, อัตราการกระทำที่ล้มเหลวต่ำ, การย้อนกลับที่ตรวจสอบได้, และประโยชน์ที่ชัดเจนต่อผู้ใช้ การปิดอัตโนมัติควรเป็นเรื่องหายากจนกว่าระบบจะพิสูจน์การกู้คืนและรักษาหลักฐานเพียงพอสำหรับการเรียนรู้ในภายหลัง
ตัวอย่างทำงาน: การทำอัตโนมัติเหตุการณ์บริการการผลิต
พิจารณา API การชำระเงินที่อัตราข้อผิดพลาดเพิ่มขึ้นหลังการปรับใช้ ระบบตรวจสอบส่งการแจ้งเตือนเชิงโครงสร้างที่มีข้อมูลบริการ, สภาพแวดล้อม, ภูมิภาค, เวอร์ชัน, งบประมาณข้อผิดพลาด, และลิงก์คู่มือ การทำอัตโนมัติเสริมข้อมูลด้วยบันทึกการเปลี่ยนแปลง, สุขภาพการพึ่งพา, บันทึกล่าสุด, และการเป็นเจ้าของ, จากนั้นรวมการแจ้งเตือนที่ซ้ำเป็นเหตุการณ์เดียว นโยบายเชิงกำหนดสามารถหยุดการปรับใช้ต่อได้ทันที; การย้อนกลับควรต้องมีหลักฐานว่าเวอร์ชันใหม่เป็นสาเหตุและการย้อนกลับปลอดภัย
กระบวนการทำงานมอบหมายผู้บังคับบัญชาเหตุการณ์, เปิดช่องทางการสื่อสาร, บันทึกไทม์ไลน์, และแนะนำขั้นตอนการวินิจฉัย การแก้ไขอัตโนมัติเข้าด้วยการกระทำที่เสี่ยงต่ำและย้อนกลับได้ เช่น การเปลี่ยนการจราจรไปยังอินสแตนซ์ที่ทำงานดี ทุกการกระทำต้องการการอนุญาต, ขีดจำกัดความพร้อมทำพร้อมกัน, เวลาจำกัด, เงื่อนไขหลังที่ตรวจสอบ, และการย้อนกลับ สรุปเชิงสร้างอาจช่วยผู้ตอบสนอง, แต่ข้อมูลเทเลเมทรีและคำสั่งต้นทางยังคงมองเห็นได้เพื่อให้ทีมสามารถท้าทายเรื่องราวที่ไม่ถูกต้อง
วัดเวลาที่ใช้ในการตรวจจับ, รับทราบ, บรรเทา, และกู้คืน; ปริมาณการแจ้งเตือน; การกดทับการซ้ำ; ความสำเร็จของการแก้ไข; การเกิดซ้ำ; และอันตรายที่เกิดจากการทำอัตโนมัติ รันวันฝึกซ้อมสำหรับข้อมูลรับรองที่หมดอายุ, ภูมิภาคบางส่วน, การแจ้งเตือนที่ทำให้เข้าใจผิด, และการย้อนกลับที่ล้มเหลว หลังการกู้คืน, เก็บรักษาไทม์ไลน์ข้อเท็จจริง, ระบุเงื่อนไขเทคนิคและองค์กรที่มีส่วนร่วม, ปรับปรุงคู่มือและการทดสอบ, และติดตามงานแก้ไขจนเสร็จสมบูรณ์ แทนการถือว่าการบรรเทาที่รวดเร็วเป็นจุดสิ้นสุดของงานความเชื่อถือได้
เช็คลิสต์การนำไปใช้เชิงปฏิบัติ
แปลงแนวคิดเป็นกระบวนการทำงานที่จำกัดและทดสอบได้: ตรวจจับ → เสริมข้อมูล → แยกประเภท → อนุมัติ → แก้ไข → เรียนรู้ กำหนดเจ้าของที่รับผิดชอบ, บันทึกข้อมูลและการพึ่งพา, สร้างฐานข้อมูลพื้นฐานง่าย, ตั้งเกณฑ์การยอมรับและการหยุด, ทดสอบความล้มเหลวที่เป็นตัวอย่าง, และกำหนดการตรวจสอบ, การย้อนกลับ, และการทบทวนก่อนขยายขอบเขต บันทึกเวอร์ชันและสมมติฐานเพื่อให้ทีมอื่นสามารถทำซ้ำผลลัพธ์และเข้าใจการเปลี่ยนแปลง
ก่อนเปิดใช้งาน, ดำเนินการตรวจสอบความพร้อมที่บันทึกไว้กับผู้ที่สร้าง, ปฏิบัติการ, ปกป้อง, และได้รับผลกระทบจากระบบ ทดสอบกรณีปกติ, เงื่อนไขขอบเขต, ความล้มเหลวของการพึ่งพา, และการใช้ผิดวิธี; เก็บรักษาหลักฐานและความเสี่ยงที่ยังไม่ได้แก้ไข กำหนดว่าใครสามารถอนุมัติการปล่อย, เปลี่ยนค่าเกณฑ์, แทนที่ผลลัพธ์, หรือหยุดการทำงานได้ ทบทวนการตัดสินใจหลังจากข้อมูลจากโลกจริงมาถึง เพราะการทดลองที่ประสบความสำเร็จทางเทคนิคไม่รับประกันประสิทธิภาพที่เชื่อถือได้ในระดับกว้าง
- EVIDENCE: เก็บสัญญาณดิบและบริบทไว้
- GUARDRAILS: ขอบเขต, การอนุมัติ, และการย้อนกลับ
- LEARNING: การทบทวนช่วยปรับปรุงระบบและคู่มือ
คำถามที่พบบ่อย
การทำอัตโนมัติของเหตุการณ์เหมือนกับ AIOps หรือไม่?
ไม่ใช่ AIOps ใช้การวิเคราะห์หรือการเรียนรู้ของเครื่องกับข้อมูลการดำเนินงาน การทำอัตโนมัติของเหตุการณ์เป็นชั้นการดำเนินการและประสานงานที่กว้างกว่า; สามารถใช้กฎง่าย ๆ, ผลลัพธ์จาก AIOps, หรือทั้งสองอย่าง
อะไรควรทำอัตโนมัติก่อน?
เริ่มต้นด้วยขั้นตอนที่มีความถี่สูง, ความเสี่ยงต่ำ, และเข้าใจดี เช่น การเสริมข้อมูล, การค้นหาเจ้าของ, การจับหลักฐาน, การอัปเดตสถานะ, และการวินิจฉัยที่ย้อนกลับได้
แหล่งอ้างอิงหลัก
