tản mạn Năng lực vận hành #1

bài viết thể hiện quan điểm cá nhân
viewer discretion is advised

Như đã phân tích trong bài trước:

Năng lực trả lời các câu hỏi liên quan đến vận hành của phía VN là tương đối hạn chế, khả năng sẵn sàng giải trình của phía VN thường chỉ ở mức độ 30% so với yêu cầu, đặc biệt khi xảy ra các sự cố vận hành.

Hạn chế về Năng lực giải trình nói trên khiến phía VN bị đánh giá thấp ở Tính minh bạch. Vì thế, muốn được nhìn nhận là Có năng lực vận hành đạt chuẩn, tôi nghĩ trước tiên chúng ta phải chú trọng xây dựng Năng lực giải trình, đó cũng là chủ đề của bài viết này.

I. Lộ trình giả thiết

Yêu cầu đặt ra (WHAT) ở đây là:

 Xây dựng năng lực giải trình

Ta sẽ đào sâu, chia chẻ (breakdown) tiếp cái WHAT này ra.

Theo hướng breakdown với mục tiêu là Mức độ sẵn sàng trả lời các câu hỏi vận hành đạt 80%, tôi hình dung khái quát lộ trình để tiến lên từng bước có thể như sau:

(. Level 0: Lúng túng trước các câu hỏi về Nguyên nhân, Phương án, Con số) <— we start here

  • . Level 1: Expect được các câu hỏi từ khách hàng trong các trường hợp vận hành
  • . Level 2: Hiểu về mặt lý thuyết các câu trả lời khả dĩ cho các câu hỏi trên
  • . Level 3: Hiểu cần có những thông tin gì để đưa ra được câu trả lời hợp lý và thuyết phục (xác định được những thông tin là đối tượng cần thu thập/ thống kê, các loại log cần lấy, các con số cần thống kê/ kiểm kê định kỳ …)
  • . Level 4: Đặt mục tiêu sẵn sàng giải trình/ đối diện khách hàng ( vd. mục tiêu thời gian trung bình cần để điều tra, xây dựng bộ câu hỏi vận hành thường gặp, mục tiêu tần suất diễn tập giải trình nội bộ )
  • . Level 5: Có lộ trình, quy trình thu thập các thông tin cần thiết phục vụ việc giải trình
  • . Level 6: Sẵn sàng cam kết nguồn lực để Thực thi và vận hành theo lộ trình
  • . Level 7: Vận hành ổn định các quy trình và luôn sẵn sàng giải trình với đủ thông tin

Tóm lại, tôi nghĩ mọi tổ chức/ công ty cần xây dựng cơ chế thu thập thông tin phù hợp với thách thức mà tổ chức đang/ sẽ phải đối mặt.

Đó là sẽ là một dự án đòi hỏi cả tổ chức phải vào cuộc để xác định Yêu cầu/ mục tiêu cần đạt được: Khả năng trả lời được những câu hỏi vận hành nào trong vòng bao lâu.

Tiếp theo cần lên kế hoạch, thống nhất lộ trình, sau đó là huy động nguồn lực thực hiện theo lộ trình, định kỳ giám sát kết quả và điều chỉnh lộ trình một cách linh hoạt.

II. Ví dụ minh hoạ các level trong lộ trình 

Đến đây tôi sẽ lấy một tình huống cần giải trình nho nhỏ ở mức độ team dự án để minh hoạ. Tình huống là team nhận được yêu cầu như sau:

“Nhờ các team kiểm tra gấp giúp có dự án nào đang không phân quyền các confluene page chứa thông tin sensitive ko”?

(câu trên có chỗ viết sai chính tả nhưng vì là trích dẫn y nguyên nên xin để như vậy, đảm bảo tính chân thực)

Đi theo mô hình các level ở phần trên, có thể hình dung sự phản ứng của team tương ứng với từng level giả định như sau:

Level 0: Lúng túng trước câu hỏi, phản ứng bản năng

  • Không biết có loại câu hỏi như trên
  • Riêng việc hiểu đúng câu hỏi đã mất thời gian
  • Trả lời dựa trên suy nghĩ đơn giản: Tôi nghĩ confluence. là bảo mật rồi mà
  • Trả lời một phần và chấm hết: các password đã được để ở những page nhất định và đã được phân quyền

Level 1: Expect được câu hỏi

Mặc dầu đã trả lời như ở Level 0, team tiếp tục nhận được câu hỏi liên quan (follow up questions), tiếp tục được yêu cầu phải cung cấp thêm thông tin, đưa bằng chứng cụ thể, bị comment …, VD :

.Confluence không tự nó bảo mật cho bạn mà còn tuỳ vào cách bạn cài đặt, phân quyền trên confluence. ….

. Ngoài thông tin password thì có team còn giữ những thông tin sensitive nào nữa?

. Phân quyền của team hiện có cập nhật theo đúng phân công nhiệm vụ mới nhất không? hiện có đang còn phân quyền cho cả những member đã rời khỏi team không? …

Team bắt đầu hiểu ra rằng mình chưa nhận thức được đầy đủ phạm vi của yêu cầu và cũng sẽ không thể dễ dàng “thoát khỏi” tình huống này chỉ với các câu trả lời “bản năng” được.

Hẹn gặp lại các bạn ở bài tiếp theo.

Add a Comment

Scroll Up