Làm thế nào để thực hiện nguyên tắc bốn mắt để sửa chữa khẩn cấp?

Xem xét kịch bản này (mọi so sánh với các tình huống trong thế giới thực hoàn toàn là tình cờ):

• 3:07 sáng : cuộc gọi hỗ trợ đến " Một vài thứ trong sản xuất bị hỏng, tôi cần sự giúp đỡ của bạn! ".
• 3:12 sáng : kết nối với hệ thống (đăng nhập được chấp nhận) ... và không có thời gian để uống cà phê.
• 3:15 sáng : may mắn cho bạn, ngay lập tức bạn có thể phát hiện ra vấn đề thông qua một số thông báo lỗi ở đâu đó.
• 3:17 sáng : sử dụng hộp công cụ SCM của bạn để lấy mã, khắc phục sự cố, kiểm tra nó, thật tuyệt ... cách khắc phục của tôi hoạt động!
• 3:20 sáng : liên lạc với nhóm Dev Ops để chuyển bản sửa lỗi và để sản xuất hoạt động trở lại.
• 3:21 sáng : cờ đỏ ... " Để tôn trọng bốn mắt , chúng tôi cần thêm 2 mắt để được chấp thuận cho sửa chữa này ".
• 3:22 sáng : ggggrrrreat, bây giờ thì sao, chúng ta có thể gọi ai khác (= đánh thức người quản lý nào đó)?

Nếu bạn đã thực hiện một số quy trình phê duyệt tương tự như câu trả lời của tôi cho "Việc triển khai có thể (hoặc ví dụ) của nguyên tắc bốn mắt là gì? ", Thì bạn đã hết may mắn ... đây là lựa chọn của bạn:

• Sửa lỗi của bạn sẽ bị kẹt (đọc: sản xuất sẽ ngừng hoạt động) cho đến khi có thêm 2 mắt tham gia.
• Bạn tìm ra một cách để có được xung quanh đôi mắt bị mất.

Vậy làm thế nào để thực hiện nguyên tắc bốn mắt để khắc phục khẩn cấp? ... Vì vậy, bạn có thể sản xuất và chạy càng sớm càng tốt, tức là khoảng 3:25 sáng ... Và để bạn cũng có thể đóng cuộc gọi (và quay lại nơi bạn đến)?

Trong thế giới SCM nơi tôi hầu hết quen thuộc, kịch bản trên thường được giải quyết bằng cái gọi là " thủ tục danh sách viết tắt -approval.

Đây là một bản thiết kế của nó:

• Xác định giờ làm việc của bạn, nói từ 8 giờ sáng đến 6 giờ chiều.
• Xác định danh sách phê duyệt đầy đủ gồm 3 cấp phê duyệt (cho các vai trò X, Y và Z).
• Xác định danh sách phê duyệt viết tắt của (nói) chỉ 1 cấp phê duyệt (chỉ dành cho vai trò X).
• Thay đổi theo kế hoạch luôn yêu cầu tất cả các phê duyệt từ danh sách phê duyệt hoàn chỉnh.
• Đối với các thay đổi ngoài kế hoạch , danh sách phê duyệt hoàn chỉnh cũng được sử dụng để thu thập các phê duyệt cần thiết, miễn là các phê duyệt sẽ được ban hành trong giờ làm việc được xác định.
• Đối với mọi phê duyệt về các thay đổi ngoài dự kiến sẽ được ban hành ngoài giờ làm việc đã xác định:
  • Chỉ các phê duyệt từ danh sách phê duyệt viết tắt (như vai trò X ở trên) là bắt buộc để cho phép thay đổi. Và sau khi ủy quyền của danh sách phê duyệt viết tắt được đưa ra, việc triển khai thay đổi (trong môi trường đích) sẽ thực sự được thực hiện.
  • Nhưng thêm bài -approvals sẽ là cần thiết sau đó (trong một số tiền hợp lý số giờ / ngày), tức là từ tất cả các vai trò chứa trong danh sách chính đầy đủ (chẳng hạn như vai trò Y và Z ở trên), mà không được cũng chứa trong danh sách chính viết tắt (chẳng hạn như vai trò X ở trên). Và nếu trong khoảng thời gian (trả trước) đã thỏa thuận, không phải tất cả các phê duyệt sau đã được ban hành (ví dụ: vì bản sửa lỗi đã hoạt động "lần này", nhưng chỉ giống như một bản sửa lỗi tạm thời), thì thay đổi có thể phải chịu sự phục hồi . Mặc dù có ít nhất 1 lần phê duyệt sau xuất sắc, thay đổi được đánh dấu là "phê duyệt bài chờ".

Với giải pháp như vậy, cuộc gọi có thể được đóng lại vào khoảng 3:23 sáng ... vì sẽ không còn cờ đỏ nào vào lúc 3:21 sáng nữa (thay vì cà phê) ... và ngón tay vượt qua các phê duyệt bài xuất sắc sẽ đến sớm ...

Trong trường hợp sửa chữa khẩn cấp ngoài giờ, sẽ thực tế hơn khi yêu cầu đăng nhập ít hơn cho các thay đổi so với quy trình thông thường của bạn. Nói chung, bạn có thể triển khai một bản sửa lỗi và sau đó thực hiện sau phê duyệt vào ngày làm việc tiếp theo. Nếu sửa chữa không được chấp thuận, nó có thể được hoàn nguyên và thay thế bằng một giải pháp vĩnh viễn.

Trong tình huống ngừng hoạt động, ưu tiên số một phải là khôi phục dịch vụ. Nếu tổ chức của bạn không nhận ra quy trình thoải mái này trong thời gian ngừng hoạt động, thì có, lựa chọn duy nhất của bạn là bắt đầu đánh thức nhiều người hơn để đăng xuất.