วิธีการใช้หลักการสี่ตาสำหรับการแก้ไขฉุกเฉิน?


13

พิจารณาสถานการณ์นี้ (เปรียบเทียบใด ๆ กับสถานการณ์โลกแห่งความเป็นจริงโดยไม่ได้ตั้งใจ):

  • 3:07 am : ฝ่ายสนับสนุนที่โทรเข้ามา " มีบางอย่างในการผลิตลดลงฉันต้องการความช่วยเหลือของคุณ! "
  • 3:12 น. : เชื่อมต่อกับระบบ (ยอมรับการเข้าสู่ระบบ) ... และไม่มีเวลาดื่มกาแฟ
  • 3:15 น. : โชคดีคุณทันทีคุณสามารถตรวจสอบปัญหาผ่านข้อความแสดงข้อผิดพลาดบางแห่ง
  • 3:17 น. : ใช้กล่องเครื่องมือ SCM ของคุณเพื่อคว้ารหัสแก้ไขปัญหาทดสอบได้ดีมาก ... การแก้ไขของฉันใช้งานได้!
  • 3:20 น. : ติดต่อกับทีมDev Ops เพื่อจัดส่งการแก้ไขและเพื่อให้การผลิตทำงานอีกครั้ง
  • 3:21 น. : ธงสีแดง ... " หากต้องการความเคารพต่อเราต้องมีอีก 2 ตาที่จะได้รับการอนุมัติสำหรับการแก้ไขนี้ "
  • 3:22 am : ggggrrrreat ตอนนี้เราจะเรียกใครอีกแล้ว (= ปลุกผู้จัดการบางคน)?

หากคุณใช้ขั้นตอนการอนุมัติคล้ายกับคำตอบของฉัน " อะไรคือการใช้งานที่เป็นไปได้ (หรือตัวอย่าง) ของหลักการสี่ตา? " แล้วคุณโชคไม่ดี ... นี่คือตัวเลือกของคุณ:

  • การแก้ไขของคุณจะติดอยู่ (อ่าน: การผลิตจะลดลง) จนกว่าจะมีดวงตาอีก 2 ตาเข้ามาเกี่ยวข้อง
  • คุณหาวิธีที่จะหลีกเลี่ยงดวงตาที่หายไป

ดังนั้นวิธีการใช้หลักการสี่ตาสำหรับการแก้ไขฉุกเฉิน? ... เพื่อให้คุณได้รับการผลิตและทำงานโดยเร็วเช่นประมาณ 3:25 น. ... และเพื่อให้คุณสามารถปิดการโทร (และกลับไปที่ที่คุณมาจาก)


คุณได้ติดต่อทีมงานซึ่งหมายความว่าพวกเขาควรจะได้รับพรแพตช์แล้วด้วยความเคารพต่อหลักการการอนุมัติในสถานที่ ฉันเริ่มเกลียดคำถามเกี่ยวกับวาทศิลป์เหล่านั้นจริง ๆ :( แค่ความคิดเห็นของฉันอย่าไปยุ่งกับมันมากเกินไป
Tensibai

@ Tensibai ใครจะเป็นไปได้ "ได้อวยพรแพทช์" (หรือแก้ไข) ล่วงหน้าไม่ทราบว่าสาเหตุของปัญหาคือเมื่อ "คุณได้รับการติดต่อ"? นอกจากนี้คุณยังสามารถเฉพาะเจาะจงเกี่ยวกับวาทศิลป์ได้หรือไม่? ไม่ใช่แบบที่ดีอย่างอื่นใช่ไหม
Pierre.Vriens

ฉันหมายความว่าคุณบอกว่าคุณสามารถติดต่อทีมได้ที่ 3:20 ซึ่งหมายความว่าไม่ใช่แค่คุณผลักดันการแก้ไข ฉันใช้วาทศิลป์เป็น 'กรณีสมมุติอิงจากประสบการณ์หรือไม่ซึ่งคุณรู้อยู่แล้วว่าคำตอบใดที่คุณรออยู่' ความกังวลของฉันมากขึ้นหรือน้อยลงเกี่ยวกับเมตาดาต้าฉันรู้สึกโดดเดี่ยวที่ไม่สนใจคำถาม 'หลักการทั่วไป' นี้ดังนั้นฉันอาจผิด สิ่งที่ฉันแน่ใจคือฉันจะไม่เข้าเยี่ยมชม Q / A สองเท่าเกี่ยวกับหลักการทั่วไปถ้าฉันเป็นคนนอกรุ่นเบต้านี้
Tensibai

ฉันอาจพูดแบบเดียวกันเกี่ยวกับคำถามทั่วไปของเจนกินส์ถ้าพวกเขากำลังมา
Tensibai

ภาระผูกพันจะไม่ถูกคำนวณจนกระทั่งเบต้าสาธารณะตอนนี้เป็นการส่วนตัวเรากำลังสร้างสิ่งที่ผู้ใช้ 'มุ่งมั่น' รู้สึกว่าเป็นคำถามที่เป็นแบบอย่างสำหรับเว็บไซต์นี้และฉันคิดว่าเรามีงานจำนวนมากใน 12 วันที่เหลือหรือฉันอาจ ต้องผ่าน 7 ขั้นตอนของความเศร้าโศก
Tensibai

คำตอบ:


8

ใน SCM โลกที่ฉันส่วนใหญ่คุ้นเคยกับสถานการณ์ดังกล่าวข้างต้นโดยทั่วไปจะมีการแก้ไขโดยสิ่งที่เรียกว่า " ยากขั้นตอนรายการ -approval

นี่คือพิมพ์เขียวของมัน:

  • กำหนดเวลาทำการของคุณพูดตั้งแต่ 8 โมงเช้าถึงหกโมงเย็น
  • กำหนดรายการการอนุมัติที่สมบูรณ์ของ (พูด) การอนุมัติ 3 ระดับ (สำหรับบทบาท X, Y และ Z)
  • กำหนดรายการการอนุมัติแบบย่อของ (พูด) การอนุมัติเพียง 1 ระดับ (เฉพาะบทบาท X)
  • การเปลี่ยนแปลงตามแผนมักต้องการการอนุมัติทั้งหมดจากรายการการอนุมัติที่สมบูรณ์
  • สำหรับการเปลี่ยนแปลงที่ไม่ได้วางแผนรายการอนุมัติเสร็จสมบูรณ์จะถูกนำมาใช้ยังจะรวบรวมการอนุมัติที่ต้องการให้ได้รับการอนุมัติจะได้รับการออกในช่วงชั่วโมงธุรกิจที่กำหนดไว้
  • สำหรับการอนุมัติการเปลี่ยนแปลงที่ไม่ได้วางแผนไว้ที่จะออกนอกเวลาทำการที่กำหนด:
    • ต้องมีการอนุมัติจากรายการการอนุมัติแบบย่อ (เช่นบทบาท X ด้านบน) เท่านั้นที่จะอนุญาตการเปลี่ยนแปลง และหลังจากได้รับการอนุมัติตามรายการการอนุมัติแบบย่อการปรับใช้การเปลี่ยนแปลง (ในสภาพแวดล้อมเป้าหมาย) จะถูกดำเนินการจริง
    • แต่จะต้องมีการโพสต์เพิ่มเติมอีกครั้งหลังจากนั้น (ภายในเวลาที่เหมาะสมจำนวนชั่วโมง / วัน) คือจากทุกบทบาทที่มีอยู่ในรายการอนุมัติที่สมบูรณ์ (เช่นบทบาท Y และ Z ด้านบน) ซึ่งไม่อยู่ในรายการอนุมัติแบบย่อ (เช่นบทบาท X ด้านบน) และหากภายในระยะเวลา (ล่วงหน้า) ตกลงจำนวนชั่วโมง / วันไม่ได้มีการออกโพสต์อนุมัติทั้งหมด (เช่นเนื่องจากการแก้ไขทำงาน "เวลา" นี้ แต่เป็นเพียงการแก้ไขชั่วคราวเท่านั้น) การเปลี่ยนแปลงอาจมีการย้อนกลับ . ในขณะที่มีการอนุมัติโพสต์ค้างชำระอย่างน้อย 1 ครั้งการเปลี่ยนแปลงจะถูกทำเครื่องหมายเป็น "รอการอนุมัติโพสต์"

ด้วยวิธีแก้ปัญหาดังกล่าวสามารถปิดการโทรประมาณ3:23 น. ... เนื่องจากจะไม่มีการตั้งค่าสถานะสีแดงอีกในเวลา3:21 น. ... ggggrrreat ถึงเวลาที่เบียร์จะฉลองการแก้ไขของฉันเพื่อให้การผลิตดำเนินต่อไปอีกครั้ง (แทนกาแฟ) ... และนิ้วที่ผ่านการอนุมัติโพสต์ที่โดดเด่นจะมาในเร็ว ๆ นี้ ...


3

ในกรณีที่มีการแก้ไขฉุกเฉินนอกเวลาทำการจะมีประโยชน์มากกว่าที่จะต้องลงชื่อออกน้อยกว่าสำหรับการเปลี่ยนแปลงมากกว่าขั้นตอนปกติของคุณ โดยทั่วไปคุณสามารถปรับใช้การแก้ไขแล้วทำการอนุมัติภายหลังในวันทำการถัดไป หากการแก้ไขไม่ได้รับอนุมัติจะสามารถเปลี่ยนกลับและแทนที่ด้วยโซลูชันถาวร

ในสถานการณ์ที่ไฟฟ้าดับลำดับความสำคัญอันดับหนึ่งคือการคืนค่าบริการ หากองค์กรของคุณไม่รู้จักกระบวนการผ่อนคลายนี้ในระหว่างที่เกิดเหตุขัดข้องใช่แล้วตัวเลือกเดียวของคุณคือการเริ่มปลุกผู้คนให้ลงชื่อสมัครใช้มากขึ้น


ฉันเห็นด้วยกับข้อเสนอแนะของคุณซึ่งดูเหมือนจะคล้ายกับคำแนะนำของฉัน (คำตอบ) คุณลองนึกถึงตัวอย่างในโลก SCM ที่คุณคุ้นเคยและคุณจะนำไปใช้ที่นั่นได้อย่างไร ถ้าเป็นเช่นนั้นคุณสามารถขยายในคำตอบของคุณ?
Pierre.Vriens
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.