จิ๊ง! ตี 3 คุณกำลังฝันดี และทันใดนั้นก็มีสายเข้า สัปดาห์นี้คุณเข้าเวร และดูเหมือนว่าจะมีบางอย่างเกิดขึ้น ระบบอัตโนมัติโทรมาหาว่ามีอะไรผิดปกติ นี่เป็นส่วนสำคัญในการจัดการระบบคอมพิวเตอร์สมัยใหม่ แต่มาดูวิธีทำให้การแจ้งเตือนดีขึ้นสำหรับผู้คนกันดีกว่า
ทำความคุ้นเคยกับปรัชญาการติดตามผลซึ่งเกิดจากหน้าที่ของฉันในทีมติดตามต่างๆ หลายทศวรรษ เธอได้รับอิทธิพลส่วนใหญ่จากพระคัมภีร์จริงของ Rob Evashchuk (ปรัชญาการแจ้งเตือนของฉัน) รวมอยู่ในหนังสือเรื่อง และจองโดย John Alspaugh (หมายเหตุเกี่ยวกับการตั้งค่าการแจ้งเตือน)
, и — ขอบคุณสำหรับความช่วยเหลือของคุณในการแก้ไขโพสต์
กรณีคืออะไร?
ฉันตัดสินใจใช้ตัวย่อที่สวยงามเช่น หรือ . ฉันเรียกมันว่า วิธีกรณี. เขาอธิบายสี่ประเด็นที่ควรคำนึงถึงเมื่อทำงานกับการตรวจสอบอัตโนมัติ:
- (บริบทถูกผูกไว้)
- (มูลค่าเชิงปฏิบัติ)
- (เน้นอาการ)
- (ระดับ)
หากคุณใช้ CASE คุณจะปฏิบัติต่อการแจ้งเตือนโดยไม่แยแสต่อสุขภาพ และไม่ปลุกผู้คนให้ตื่นในตอนกลางคืน ควรมีการประเมินการติดตามอย่างสม่ำเสมอเพื่อความมีประโยชน์และประสิทธิผล เมื่อบุคคลได้รับการแจ้งเตือน พวกเขาจะมีรูปแบบทางจิตที่ดีขึ้นและมีความมั่นใจมากขึ้น
เพื่อให้ง่ายต่อการจดจำ ลองจินตนาการว่าคุณจำเป็นต้องมี CASE [นั่นคือ กรณี เหตุผล - บันทึกของนักแปล] เพื่อปรับการแจ้งเตือนแต่ละครั้ง :แว่นกันแดด:
และทำไมทั้งหมดนี้?
. ด้วยเหตุผลหลายประการ และ CASE จะไม่กำจัดสิ่งเหล่านั้นทั้งหมด แต่ด้วยสิ่งนี้ คุณจะตื่นขึ้นมาตอนกลางคืนเพื่อรับการแจ้งเตือนที่ดีขึ้น วิธีการนี้ครอบคลุมถึงกระบวนการต่างๆ ขององค์กรที่จะช่วยในเรื่องนี้ด้วย
ข้อดีของวิธีการ RED และ USE คือด้วยความช่วยเหลือของพวกเขา เราไม่เพียงแต่รู้วิธีการทำงานเท่านั้น แต่ยังพูดภาษาเดียวกันระหว่างกันอีกด้วย ความหวังของฉันคือวิธี CASE จะทำให้การหารือเกี่ยวกับการแจ้งเตือนที่ปกป้องระบบของเราง่ายขึ้นแต่ทำให้เพื่อนร่วมงานของเรายุ่ง
ประเด็นก็คือ คุณต้องสร้างวัฒนธรรมในองค์กรของคุณที่การแจ้งเตือนได้รับการปฏิบัติโดยไม่แยแสในทางที่ดี สามารถสร้างการแจ้งเตือนเพื่อวัตถุประสงค์เฉพาะได้ แต่ไม่ใช่ข้อเท็จจริงที่จะไม่สูญเสียคุณค่าในภายหลัง เหตุใดเราจึงตั้งค่าการแจ้งเตือนนี้ มีการปรับปรุงเกณฑ์มานานแค่ไหนแล้ว? ด้วย CASE คำถามเหล่านี้สามารถตอบได้
Context-Heavy - การเชื่อมโยงบริบท
ตี 3 ไม่ใช่เวลาที่ดีที่สุดในการอ่านข้อความที่มีคำศัพท์ที่ฉลาดมากมาย เพื่อการตอบสนองอย่างมีประสิทธิภาพ คุณต้องมีข้อมูล ตามหลักการแล้ว นี่ควรเป็นข้อมูลเกี่ยวกับปัญหาเฉพาะซึ่งมีบริบทชัดเจนทันที และควรกำหนดค่าการแจ้งเตือนเพื่อให้เป็นไปได้ นี่คือ "การสังเกต" และ "การปฐมนิเทศ" จาก . ไม่ใช่เรื่องน่าละอายที่จะใช้เวลากับการตั้งค่านี้ เนื่องจากการเบี่ยงเบนความสนใจของบุคคลอย่างต่อเนื่องนั้นมีราคาแพงกว่าด้วยซ้ำ ให้เกียรติซึ่งกันและกัน
ปัญหามีหลายแหล่ง โดยเฉพาะผี.
ฉันจะช่วยเจ้าหน้าที่ปฏิบัติหน้าที่ได้อย่างไร? สิ่งแรกที่เจ้าหน้าที่ปฏิบัติหน้าที่เห็นคือการแจ้งเตือน เขาจึงตั้งสมมติฐานทั้งหมดบนพื้นฐานของมัน จากนั้นเขาก็ดูคำแนะนำและแดชบอร์ด แต่มีข้อมูลเกี่ยวกับการแจ้งเตือนเฉพาะอยู่เสมอ ไม่ใช่แค่ข้อมูลทั่วไปใช่ไหม Alspaugh แนะนำให้ "คิดถึงวิธีตีความหรือตอบสนองต่อการแจ้งเตือน" (สไลด์ 29). การแจ้งเตือนที่ดีจะเน้นไปที่ผู้ปฏิบัติหน้าที่ ไม่ใช่เพียงกำหนดตามเกณฑ์เท่านั้น
ต่อไปนี้เป็นแนวคิดบางประการเกี่ยวกับวิธีปรับปรุงบริบทการแจ้งเตือน:
- แสดงให้ผู้ใช้เห็นถึงสิ่งที่มีประโยชน์และสร้างขึ้นเป็นพิเศษ ไม่ใช่แค่คำแนะนำทั่วไปหรือแดชบอร์ด ก่อนหน้านี้ พวกเขาและฉันใช้แดชบอร์ดเชิงสืบสวนที่กำหนดค่าไว้สำหรับการแจ้งเตือนเฉพาะ สิ่งนี้จะช่วยได้หากทราบปัญหา แต่จะทำให้ผู้อื่นสับสนเท่านั้น เราต้องหาจุดสมดุลที่นี่
- บอกเราเกี่ยวกับประวัติการแจ้งเตือน: ใหม่หรือไม่ มันทำงานบ่อยไหม? มันเป็นฤดูกาลหรือไม่?
- แสดงการเปลี่ยนแปลงล่าสุดในสถานะของระบบ มีอะไรเปลี่ยนแปลงเมื่อเร็ว ๆ นี้? (เช่น การปรับใช้หรือการเปิด/ปิดใช้งานฟังก์ชันการทำงาน)
- แสดงความสัมพันธ์และให้ข้อมูลสำหรับแบบจำลองทางจิต: การพึ่งพาของระบบควรมองเห็นได้ชัดเจน โดยควรมีข้อบ่งชี้ถึงฟังก์ชันการทำงาน
- เชื่อมต่อผู้ใช้กับทีมอย่างรวดเร็ว: พวกเขาสามารถเห็นเหตุการณ์ที่กำลังดำเนินอยู่หรือสามารถค้นหาได้ว่ามีใครอีกในบริษัทที่ได้รับการแจ้งเตือนหรือไม่ โปรแกรม เปิดใช้งานแล้วเหรอ?
ตามหลักการแล้ว โปรแกรมการจัดการเหตุการณ์จะให้คำแนะนำเกี่ยวกับวิธีการปรับปรุงบริบทการแจ้งเตือนของการสืบสวนเหตุการณ์ มีบางอย่างให้ทำอยู่เสมอ!
นำไปปฏิบัติได้ - คุณค่าในทางปฏิบัติ
เจ้าหน้าที่ปฏิบัติหน้าที่ควรดำเนินการตอบสนองการแจ้งหรือไม่? ถ้าไม่ต้องทำอะไรหรือไม่รู้จะทำอะไรทำไมถึงปลุกเขา? คุณต้องหลีกเลี่ยงการแจ้งเตือนที่รบกวนผู้ปฏิบัติหน้าที่และไม่จำเป็นต้องดำเนินการใดๆ
ฉันควรทำอย่างไรดี? คุณต้องการอะไร?
ในอดีต เมื่อระบบเรียบง่ายและทีมมีขนาดเล็ก เราจึงตั้งค่าการตรวจสอบเพื่อให้อยู่เหนือสิ่งต่างๆ การแจ้งเตือนว่าโหลดบนฮีปเพิ่มขึ้นจะทำให้เรามีบริบทหากบริการทำงานผิดปกติในภายหลัง ในวงกว้าง การแจ้งเตือนดังกล่าวมีแต่จะสร้างความสับสน เนื่องจากระบบของเราทำงานในสภาวะเสื่อมโทรมและมีความรุนแรงต่างกันอยู่เสมอ สิ่งนี้นำไปสู่อย่างรวดเร็ว และแน่นอนว่า สูญเสียความไวต่อความรู้สึก ดังนั้นเจ้าหน้าที่ปฏิบัติหน้าที่จึงเพิกเฉยหรือกรองการแจ้งเตือนดังกล่าวและไม่ได้ตอบกลับตามความจำเป็นเสมอไป อย่าตกหลุมพรางนี้! อย่าตั้งค่าการแจ้งเตือนทั้งหมดติดต่อกันแล้วส่งทางอีเมลไปยังโฟลเดอร์ที่ถูกทอดทิ้ง
ต่อไปนี้คือข้อความแจ้งที่มีคุณค่าในทางปฏิบัติ:
- การแจ้งเตือนต้องมีการดำเนินการมากกว่าการรายงานข่าวเพียงอย่างเดียว
- การดำเนินการนี้เป็นเรื่องยากหรือมีความเสี่ยงที่จะทำให้เป็นอัตโนมัติ หากการกระทำสามารถทำให้เป็นอัตโนมัติได้ ก็ทำให้เป็นอัตโนมัติ หยุดรบกวนผู้คน!
- ประกาศประกอบด้วยคำแนะนำเร่งด่วนในแบบฟอร์ม (SLA) หรือ (อาร์ทีโอ) เจ้าหน้าที่ปฏิบัติหน้าที่สามารถเปิดใช้งานโปรแกรมการจัดการเหตุการณ์ขององค์กรได้
ฉันต้องการชี้แจง: ฉันไม่ได้บอกว่าการแจ้งเตือนควรมาเฉพาะกับ SLO ที่สำคัญที่สุด (วัตถุประสงค์ระดับบริการ) สำหรับ API เท่านั้น การตรวจสอบ SLO มีการแยกส่วนและแบ่งออกอย่างต่อเนื่อง และต้องใช้แนวทางเดียวกันกับบริการทั้งหมด เห็นได้ชัดว่าคุณจะติดตาม SLO ที่สำคัญที่สุดสำหรับลูกค้าที่จ่ายเงินให้คุณ แต่ SLO ของโครงสร้างพื้นฐาน เช่น ฐานข้อมูล ก็จำเป็นต้องได้รับการตรวจสอบเช่นกัน ในไม่ช้าคุณจะต้องจัดการกับลูกค้าภายในและสนับสนุนพวกเขา และไม่มีที่สิ้นสุด
ตามอาการ - เน้นตามอาการ
ไม่ว่าคุณจะชอบหรือไม่ก็ตาม คุณกำลังทำงานในระบบกระจาย (Kavaj). เป็นผลให้คุณใช้กลยุทธ์ที่แตกต่างกันเพื่อแยกบริการและปกป้องพวกเขาจากความล้มเหลว (Trainor และคณะ)3 และแม้ว่าการรวบรวมขยะล่าช้าหรือการสืบค้นฐานข้อมูลที่ค้างจะบ่งชี้ถึงปัญหา แต่ก็ไม่จำเป็นต้องรีบแก้ไขหากผู้ใช้ไม่มีปัญหาในอนาคตอันใกล้นี้
สิ่งเหล่านี้เป็นสัญญาณที่สำคัญและอาจมีคุณค่าในทางปฏิบัติ แต่หากไม่รบกวนผู้ใช้ ก็ถือว่าไม่เร่งด่วนพอที่จะเบี่ยงเบนความสนใจของผู้ดูแล การแจ้งเตือนตามสาเหตุคือภาพรวมของแบบจำลองทางจิตของเราเกี่ยวกับความล้มเหลวของระบบ การติดตามอาการที่สำคัญจะดีกว่าการพยายามระบุสาเหตุที่เป็นไปได้ทั้งหมดของความล้มเหลว
หากต้องการทำให้การแจ้งเตือนมีความหมาย ให้เน้นที่ สำคัญต่อผู้ใช้ Evashchuk เรียกสิ่งนี้ว่า "การตรวจสอบผู้ใช้" โปรดจำไว้ว่าจะต้องนำปรัชญานี้ไปใช้ทั่วทั้งองค์กร หากบริการมีปัญหาเร่งด่วนในโครงสร้างพื้นฐานลึกลงไป ทีมงานที่เหมาะสมจะดูแลปัญหาเหล่านั้น การปกป้องระบบจากความล้มเหลวดังกล่าวเป็นเรื่องที่แยกจากกันโดยสิ้นเชิง (ผู้ฝึกสอน และคณะ หัวข้อเกี่ยวกับกลยุทธ์ในการลดการอ้างอิงที่สำคัญ).
อาการไม่แปรผันตาม.
Richard Cook เตือนเราว่าระบบที่ซับซ้อนเต็มไปด้วยข้อบกพร่อง ข้อบกพร่อง และปัญหาต่างๆ. การพยายามระบุสาเหตุที่เป็นไปได้ทั้งหมดถือเป็นงานของ Sisyphean คุณพยายามอธิบายปัญหาแต่ปัญหาเหล่านั้นเปลี่ยนแปลงตลอดเวลา Cindy Sridharan เชื่อว่า “ระบบไม่จำเป็นต้องอยู่ในสภาพที่สมบูรณ์ทุกวินาที” และควรใช้แนวทางที่เป็นมนุษย์มากกว่า ( (“การตรวจสอบระบบแบบกระจาย”), 7).
หลีกเลี่ยงการแจ้งเตือนหลังเกิดเหตุ
โดยทั่วไปแล้ว การแจ้งเตือนสาเหตุจะได้รับการกำหนดค่าเพื่อแก้ไขเหตุการณ์ และการแจ้งเตือนที่จำกัดเกี่ยวกับข้อเท็จจริงของสิ่งที่เกิดขึ้นทำให้เกิดความรู้สึกปลอดภัยที่ผิดพลาด เนื่องจากระบบจะเสนอวิธีใหม่ในการทำลายทุกครั้ง
อย่าหลงกลโดยการแจ้งเตือนสาเหตุ คิดดีกว่า:
- เหตุใดการแจ้งเตือนตามอาการจึงไม่สังเกตเห็นปัญหา
- การปรับปรุงบริบทสำหรับผู้ใช้จะเป็นประโยชน์หรือไม่
- จะปรับปรุงเครื่องมือติดตามเพื่อให้การวินิจฉัยเร็วขึ้น แทนที่จะสะสมการแจ้งเตือนเกี่ยวกับสิ่งที่เกิดขึ้นได้อย่างไร
เครื่องมือติดตามเพื่อการวินิจฉัยจะช่วยได้ก็ต่อเมื่อคุณคิดว่าเครื่องมือเหล่านี้เป็นหนทางในการเปลี่ยนจากอาการไปสู่แนวทางแก้ไข หากไม่มีคำติชมนี้ คุณจะถูกโจมตีด้วยการแจ้งเตือนล่าช้าและแผนภูมิเกี่ยวกับความล้มเหลวในอดีต และไม่ใช่คำพูดเกี่ยวกับความล้มเหลวในอนาคต นี่เป็นโอกาสที่ดีสำหรับองค์กรในการย้ายจากการป้องกันหนึ่งไปยังอีกการโจมตีหนึ่ง และนักพัฒนาและผู้จัดการผลิตภัณฑ์ก็จะมีความคาดหวังและเป้าหมายที่ชัดเจนเหมือนกัน กรณี - CASE (:wink:) - มีความชัดเจนสำหรับการแจ้งเตือนแต่ละครั้ง
การแจ้งเตือนตามเหตุผลสามารถยอมรับได้ในการกลั่นกรอง
บางครั้งระบบของเราทำให้เรามีตัวเลือกน้อยมากในแง่ของการแจ้งเตือนตามสาเหตุ และบางครั้งผู้ปฏิบัติหน้าที่ก็เข้าใจดีว่าอาการจะนำไปสู่ความล้มเหลวอย่างแน่นอนดังนั้นจึงมีคุณค่าในทางปฏิบัติ บางทีคุณอาจไม่แน่ใจว่าเกิดอะไรขึ้น และกำลังตั้งค่าการแจ้งเตือนให้อยู่ในด้านความปลอดภัย หวังว่าการดำเนินการนี้จะเป็นการชั่วคราวจนกว่าเราจะสามารถเปลี่ยนระบบเพื่อแก้ไขปัญหาด้านประสิทธิภาพได้
คำนึงถึงองค์ประกอบอื่นๆ ของ CASE เมื่อต้องรับมือกับสถานการณ์เหล่านี้ เพียงเพราะมันเป็นเพียงชั่วคราวไม่ได้หมายความว่าคุณสามารถหยุดคิดด้วยสมองได้
ประเมินแล้ว - การประเมินผล
การเปลี่ยนแปลงใดๆ ในระบบ (โค้ดใหม่ โครงสร้างพื้นฐานใหม่ สิ่งใหม่ๆ) จะขยายขอบเขตของความล้มเหลว (Cook, 3) การแจ้งเตือนนี้ยังคงทำงานตามที่คาดไว้หรือไม่ รูปแบบทางจิตที่ชัดเจนและเป็นปัจจุบันของระบบและประสบการณ์ที่ตอบสนองต่อการแจ้งเตือนการสนับสนุนบางอย่าง - นี่คือคุณสมบัติที่สำคัญ . ข้อบกพร่องในระบบมีการพัฒนาอยู่ตลอดเวลา และเราต้องตามให้ทัน
คุณต้องประเมินคุณภาพของการแจ้งเตือนแต่ละรายการอย่างต่อเนื่องเพื่อให้แน่ใจว่าทำงานได้ตามที่คาดหวัง เรียนท่านผู้นำ! มันจะง่ายกว่ามากสำหรับทีมของคุณหากคุณช่วยพวกเขาสร้างกระบวนการนี้! ต่อไปนี้เป็นแนวคิดในการประเมินบางส่วน:
- ใช้ , หรือวิธีทดสอบการแจ้งเตือนอื่นๆ ทีมงานทำเองได้โดยไม่ต้องพึ่งระบบจัดการเหตุการณ์ที่ยุ่งยาก!
- รวมการรวบรวมการแจ้งเตือนที่เกี่ยวข้องกับเหตุการณ์ทั้งหมดไว้ในโปรแกรมการจัดการเหตุการณ์ของคุณ ทำเครื่องหมายว่ามีประโยชน์ เป็นอันตราย ไม่เหมาะสม ไม่ชัดเจน ฯลฯ ใช้เป็นข้อเสนอแนะ
- การแจ้งเตือนที่ถูกต้องจะเกิดขึ้นไม่บ่อยนักและได้รับการทดสอบอย่างรอบคอบ ตรวจสอบให้แน่ใจว่าลิงก์ทั้งหมดใช้งานได้ ชี้ไปที่บริบทที่ถูกต้อง ฯลฯ
- หากการแจ้งเตือนไม่เคยเริ่มทำงานหรือเริ่มทำงานบ่อยเกินไป แสดงว่ามีสิ่งผิดปกติเกิดขึ้น แก้ไขหรือถอดออก ระวังความเฉื่อยชาหรือกิจกรรมมากเกินไป!
- ตั้งค่าการประทับเวลาการแจ้งเตือนพร้อมวันหมดอายุ หากวันหมดอายุหมดอายุ ให้ประเมินการแจ้งเตือนโดยใช้วิธี CASE และอัปเดตการประทับเวลา เช่นเดียวกับอาหาร ควรตรวจสอบวันหมดอายุอย่างสม่ำเสมอ
- ลดความซับซ้อนของกระบวนการปรับปรุงการแจ้งเตือน ใช้การตรวจสอบเป็นโค้ดและจัดเก็บการแจ้งเตือนในพื้นที่เก็บข้อมูล Git คำขอดึงข้อมูลช่วยให้ทีมมีส่วนร่วมและให้ประวัติการแจ้งเตือนที่ผ่านมาแก่คุณ และคุณจะไม่กลัวที่จะเปลี่ยนการแจ้งเตือนหรือขออนุญาตจากผู้ที่รับผิดชอบอีกต่อไป
- ตั้งค่าคำติชมสำหรับการแจ้งเตือน แม้ว่าจะเป็นเรื่องง่ายก็ตาม เพื่อให้เจ้าหน้าที่ปฏิบัติหน้าที่ทำเครื่องหมายการแจ้งเตือนว่าไร้ประโยชน์หรือล่วงล้ำ ฝังลิงก์หรือคำกระตุ้นการตัดสินใจลงในการแจ้งเตือนและตรวจสอบความคิดเห็นของคุณเป็นประจำ
- สร้างกฎเกณฑ์ในทีม - ให้ผู้ปฏิบัติหน้าที่ทำงานเพื่อทำให้การปฏิบัติหน้าที่ง่ายขึ้นเมื่อมีงานน้อย ขอให้ทุกอย่างหลังจากคุณดีขึ้นกว่าเดิมเล็กน้อย
ข้อสรุป
ฉันเชื่อว่าวิธีการของ CASE ช่วยให้นักพัฒนาและองค์กรสามารถหารือเกี่ยวกับการตั้งค่าและส่งการแจ้งเตือนอัตโนมัติได้ นักพัฒนารายหนึ่งสามารถเริ่มประเมินการแจ้งเตือนโดยใช้วิธี CASE จากนั้นทั้งองค์กรจะเข้าร่วมกับนักพัฒนา การจัดการ และโปรแกรมการจัดการเหตุการณ์อื่น ๆ เพื่อรักษาการแจ้งเตือนให้อยู่ในสภาพดี ไม่ต้องใช้เครื่องมือพิเศษหรือกระบวนการที่ซับซ้อนใดๆ
อุตสาหกรรมทั้งหมดจำเป็นต้องคำนึงถึงปัจจัยด้านมนุษย์ในขณะปฏิบัติหน้าที่ โดยไม่ต้องเสียสละการบริการลูกค้าชั้นยอด เครื่องมือและแนวทางปฏิบัติทั้งหมดนี้สามารถและควรได้รับการปรับปรุง ฉันหวังว่าวิธี CASE จะช่วยในเรื่องนี้
เพลิดเพลินกับการแจ้งเตือนที่ได้รับการปรับปรุง!
ที่มา: will.com