Hàng chục (hoặc hơn) bài học từ 15 năm quản lý sự cố phần mềm

Là một kỹ sư phần mềm, việc xử lý các sự cố thật tệ. Bạn nhận được trang đang được gọi vào lúc 3 giờ sáng thứ Bảy? Nó có thể gây sợ hãi, hút hồn và nói chung là một tình tiết ghê tởm. Nếu nó xảy ra thường xuyên tại nơi làm việc của bạn, nó có thể gây ra PTSD theo đúng nghĩa đen.

Thật không may, đây là một phần của hệ tư tưởng phần mềm. Nếu có thì đây chính là ngọn lửa mà qua đó kỹ thuật thực sự được rèn giũa. Những sự cố này dạy bạn cách xây dựng các hệ thống vững chắc và trong nhiều trường hợp, làm thế nào để không làm như vậy.

Bài viết này đi sâu vào 2 khía cạnh về cách xử lý sự cố phần mềm:

• 🛠️ Những cách thực hành mà một người cần thấm nhuần vào nền tảng phần mềm và nhóm của mình để ngăn chặn và rút kinh nghiệm từ những kinh nghiệm này.

• 🧘 Người ta cần phải có thái độ kiên cường và vượt qua những trải nghiệm này không những không bị tổn thương mà còn nhiều hơn những gì họ đã trải qua.

Các chủ đề chúng tôi sẽ đề cập là -

1. Tự động hóa hệ thống của bạn nhiều nhất có thể
2. Theo dõi các chỉ số dẫn đầu và tụt hậu
3. Cảnh báo “có thể hành động” phải hiển nhiên
4. Thiết lập chuỗi cuộc gọi rõ ràng và đường dẫn leo thang
5. Trao quyền cho tuyến đầu để đưa ra quyết định lớn
6. Không phải tất cả các sự cố đều được tạo ra như nhau
7. Giải quyết trước, đặt câu hỏi sau
8. Đảm bảo có một người chịu trách nhiệm
9. Giao tiếp rõ ràng và thường xuyên
10. Việc khám nghiệm tử thi không đáng trách là rất quan trọng
11. Việc theo dõi khám nghiệm tử thi là rất quan trọng
12. Sự cố không xấu miễn là MTTD thấp
13. Hài hước là sự cân bằng tuyệt vời

Hãy để chúng tôi đi sâu vào để biết một số chi tiết!

Tự động hóa hệ thống của bạn nhiều nhất có thể

Bạn thực sự muốn giảm thiểu số lượng sự cố mà bạn biết được thông qua khách hàng của mình hoặc thông qua một số ngày hoặc tuần sai lệch nghiêm trọng về kế toán kể từ khi sự cố bắt đầu. Mặc dù “tự động hóa” là một từ được sử dụng quá nhiều trong kỹ thuật nhưng đây là một trong những lĩnh vực mà bạn thực sự muốn tìm sự cân bằng phù hợp giữa tỷ lệ tín hiệu trên tạp âm và đảm bảo rằng bạn và nhóm của bạn nhận được cảnh báo mà không cần bất kỳ sự can thiệp nào của con người.

Nếu có quá nhiều thứ để lựa chọn, hãy chọn cấp độ siêu cao. Số liệu cấp cao nhất bạn có thể chọn là gì? Cái gì nếu các hệ thống thành phần không hoạt động như mong đợi, sẽ đi chệch khỏi định mức? Đây có thể là theo dõi doanh thu chảy qua nền tảng (đối với nền tảng thương mại điện tử, tài chính hoặc dựa trên đô la) hoặc số lượng người dùng đang hoạt động hiện tại (đối với nền tảng truyền thông xã hội).

Nếu bạn thấy các con số bị sụt giảm hoặc giảm đi một hoặc hai độ lệch chuẩn, hãy thông báo ngay cho nhóm phát triển. Việc tập trung các cảnh báo đầu tiên (hoặc quan trọng nhất) vào hoạt động kinh doanh hoặc trải nghiệm cốt lõi của người dùng sẽ là thước đo tuyệt vời để theo dõi. Khi bạn trở nên phức tạp hơn và hiểu hệ thống tốt hơn, bạn có thể bắt đầu đi sâu hơn vào ngăn xếp từ quan điểm về khả năng quan sát.

Theo dõi các chỉ số dẫn đầu và tụt hậu

Các chỉ báo hàng đầu có tính chất dự đoán và có khả năng chỉ ra một vấn đề sắp xảy ra trong khi các chỉ báo tụt hậu mang tính chất hậu kiểm và đại diện cho hậu quả sau khi vấn đề đã được xử lý tốt. Nếu bạn có thể khai thác các chỉ báo hàng đầu (chẳng hạn như “Thời lượng phiên” bắt đầu giảm), ngoài hoặc thay cho các chỉ báo tụt hậu (chẳng hạn như “số lượng lệnh đặt giảm mạnh”), bạn có thể ngăn chặn điều gì đó là khá thảm họa.

Cảnh báo “có thể hành động” phải hiển nhiên

Cảnh báo của bạn phải hiển nhiên để có thể hiểu rõ những bước tiếp theo cần thực hiện khi chúng bị sa thải. Cho dù đó là để xác định mức độ nghiêm trọng của sự cố, khắc phục sự cố hay khắc phục sự cố thì cảnh báo cũng cần có đủ thông tin chi tiết. Bạn muốn đảm bảo rằng không cần phải thảo luận trực tiếp nhiều để xác định xem phải làm gì với cảnh báo.

Bạn có thể dán những chi tiết này vào nội dung của cảnh báo hoặc nếu nó khá dài dòng, bạn có thể liên kết với (các) sổ tay hướng dẫn mà nhóm duy trì cho những loại vấn đề này.

Thiết lập chuỗi cuộc gọi rõ ràng và đường dẫn leo thang

Việc có một bản phác thảo rõ ràng về những gì sẽ xảy ra khi cảnh báo kích hoạt, bao gồm cả việc cảnh báo sẽ được chuyển đến ai dựa trên những yếu tố như quyền sở hữu dịch vụ, nhận thức về múi giờ, v.v. là điều quan trọng để đảm bảo phản hồi nhanh chóng. Ngoài tuyến phòng thủ đầu tiên ngay lập tức đó, điều quan trọng không kém là phải đảm bảo có sự rõ ràng về cách thức và đối tượng mà người ứng phó sự cố có thể chuyển vụ việc lên cấp cao hơn.

Thông thường, nếu vấn đề phức tạp hoặc có phạm vi lớn hơn nhiều so với khả năng của một người, thì có thể cần phải thu hút nhiều người cấp cao hơn (hoặc nhiều người trong nhóm) cũng như các bên liên quan đa chức năng. Làm cho tất cả những thứ đó có thể truy cập dễ dàng thông qua công cụ (như PagerDuty, OpsGenie) hoặc tài liệu rõ ràng (chạy sách, trang wiki, repo README), có thể là sự khác biệt giữa một sự cố thảm khốc hoặc một chiếc burger chẳng có gì.

Trao quyền cho tuyến đầu để đưa ra những quyết định lớn

Mặc dù bạn cần đường dẫn báo cáo rõ ràng nhưng bạn không muốn đó là phản hồi mặc định. Bạn phải trao quyền cho những người ứng phó đầu tiên để họ có thể thực hiện hành động thực tế nhằm ngăn chặn tình trạng chảy máu hoặc đưa ra quyết định khắc phục ngay tại chỗ mà không cần phải tham khảo ý kiến của quản lý cấp cao. Điều này vừa tốt cho công ty về mặt hạn chế hậu quả, vừa tốt cho những nhân viên được giao trách nhiệm cao rằng họ được tin tưởng đưa ra những quyết định lớn. Giảm quan liêu và tăng cường quyền tự quyết của các cá nhân.

Không phải tất cả các sự cố đều được tạo ra như nhau

Cùng với những thứ như chuỗi cuộc gọi và đường dẫn báo cáo, một tài sản thế chấp quan trọng khác là thang đo mức độ ưu tiên sự cố. Đây thường là tài liệu tham khảo nhanh cho người ứng phó đầu tiên hoặc người chỉ huy sự cố. Nó giúp họ nhanh chóng xác định mức độ nghiêm trọng của sự cố và gắn nhãn sự cố như vậy vì nó có thể đảm bảo các cấp độ phản hồi khác nhau.

Việc phân biệt giữa các sự cố nghiêm trọng (như ngừng hoạt động hệ thống hoặc hỏng dữ liệu tài chính) và các sự cố nhỏ (chẳng hạn như trục trặc trong bảng màu) là điều cần thiết để người ứng phó tránh cảnh báo sai. Nó cũng đảm bảo phản ứng của nhóm vẫn hiệu quả và tập trung.

Giải quyết trước, đặt câu hỏi sau

Không còn nghi ngờ gì nữa, một trong những điều quan trọng nhất cần làm là giải quyết sự cố càng nhanh càng tốt. Bạn không muốn tốn thời gian tìm hiểu lý do tại sao điều gì đó lại xảy ra hoặc làm thế nào để ngăn chặn nó trong khi sự việc đang diễn ra. Bạn có thể dành nó cho việc khám nghiệm tử thi. Hiện tại, hãy tập trung giải quyết sự việc một cách tàn nhẫn và đặt những câu hỏi khó sau này.

Đảm bảo có một người chịu trách nhiệm

Đôi khi, sự cố có thể trở nên quá lớn. Chúng liên quan đến quá nhiều dịch vụ, trải rộng trên nhiều lĩnh vực kinh doanh hoặc chúng chỉ thực sự có tác động về mặt doanh thu hoặc danh tiếng. Đó là lúc điều cực kỳ quan trọng là phải có một người được chỉ định làm “cảnh sát giao thông” để giải quyết toàn bộ vụ việc. Tại Place Exchange, chúng tôi đã thành lập “Chỉ huy sự cố” là một nhóm nhỏ những người được đào tạo về ứng phó sự cố phức tạp.

Lý do việc có loại vai trò này rất quan trọng là vì khi có nhiều bên tham gia thì cần phải có ai đó điều khiển giao thông. Thông thường, các kỹ sư sẽ bắt đầu đi sâu tìm hiểu về mức độ phức tạp của vấn đề hoặc cố gắng hiểu cách giải quyết vấn đề.

Vai trò của Người chỉ huy Sự cố là duy trì sự tập trung của nhóm vào việc giải quyết sự cố nhanh chóng. Họ đảm bảo rằng mọi người đều có thiên hướng hành động và trong khi các cuộc điều tra bên lề có thể quan trọng thì việc đảm bảo động lực về phía trước thậm chí còn quan trọng hơn. Họ cũng chịu trách nhiệm đảm bảo rằng có sự liên lạc rõ ràng và liên tục với các bên liên quan và đối tác bên trong và bên ngoài.

Người chỉ huy sự cố thường sẽ bắt đầu một đường dây liên lạc bằng giọng nói đồng bộ, chẳng hạn như cuộc trò chuyện nhóm trên Slack hoặc cuộc họp trên Google Meet. Điều này đảm bảo rằng những người quan trọng trong việc giải quyết vụ việc được liên lạc thường xuyên. Thật ngạc nhiên là điều nhỏ nhặt này lại hiệu quả đến thế nào so với việc chỉ cho phép mọi người giải quyết mọi việc một cách không đồng bộ bằng cách sử dụng tính năng trò chuyện.

Người chỉ huy sự cố cũng chịu trách nhiệm đảm bảo có sự phân công rõ ràng cho các nhiệm vụ cần hoàn thành và đảm bảo có trách nhiệm giải trình trong việc nhận lại phản hồi hoặc kết quả cho những nhiệm vụ đó.

Người ta thường nói, nếu bạn nhờ 2 người cho một con ngựa ăn thì con ngựa đó sẽ chết. Người chỉ huy sự cố sẽ ngăn chặn điều đó xảy ra và chịu trách nhiệm cuối cùng về việc giải quyết nhanh chóng sự cố.

Giao tiếp rõ ràng và thường xuyên

Mọi người thường sẽ bỏ qua ứng dụng hoặc phần mềm yêu thích của họ nếu họ được thông báo về cách nhóm đang làm việc chăm chỉ để giải quyết sự cố. Cố gắng giấu kín mọi thứ vì bạn cảm thấy mình không hoàn toàn có thể xử lý được vụ việc hoặc bạn và nhóm của mình cảm thấy xấu hổ về điều đó không phải là lý do để ngăn cản việc giao tiếp lan ra bên ngoài.

Đảm bảo việc giao tiếp ngắn gọn, thường xuyên và minh bạch với cả đối tác bên trong và bên ngoài của bạn vì điều đó sẽ giúp xây dựng thiện chí.

Việc khám nghiệm tử thi không có lỗi là rất quan trọng

Việc khám nghiệm tử thi hoặc hồi tưởng sau sự cố là điều quan trọng để xây dựng văn hóa học tập và chúng nhất thiết phải vô tội. Hãy phê phán quá trình chứ không phải con người. Không ai khắt khe với bản thân hơn (những) người có thể đã gây ra điều này và bạn chẳng thu được gì từ việc chỉ trích họ ở nơi công cộng. Nếu có thì tất cả các nghiên cứu đều cho thấy rằng bạn thực sự thua khi làm điều này. Mọi người ở Etsy nói về nó tốt hơn nhiều, vì vậy hãy đọc https://www.etsy.com/codeascraft/blameless-postmortems nếu bạn muốn tìm hiểu thêm.

Việc theo dõi các cuộc khám nghiệm tử thi là rất quan trọng

Mặc dù việc tự mình tiến hành khám nghiệm tử thi là điều quan trọng để xây dựng nhận thức và các vòng phản hồi để rút ra bài học từ những sự cố này, nhưng các mục hành động được thảo luận để ngăn chặn những điều này xảy ra trong tương lai, có thể còn quan trọng hơn. Nếu nhóm đã xác định được một loạt lỗ hổng hoặc lỗ hổng trong hệ thống, điều cực kỳ quan trọng là phải tập trung và chú ý giải quyết chúng kịp thời để ngăn vấn đề tương tự xảy ra lần nữa.

Thật khó để ngăn chặn sự cố xảy ra và đó thường là một cuộc trò chuyện khó khăn với doanh nghiệp và khách hàng của bạn. Nhưng nếu cùng một sự cố xảy ra lặp đi lặp lại, thì điều đó vừa khó bảo vệ hơn vừa cho thấy vấn đề nghiêm trọng về sức khỏe và kỹ năng của đội.

Sự cố không tệ miễn là MTTD thấp

Mọi người đều hiểu nó. Ngay cả những người kinh doanh cũng hiểu được điều đó. Xây dựng phần mềm là CỨNG và trong một thế giới mà tất cả phần mềm của chúng tôi đều có hàng trăm trong số hàng nghìn phần mềm phụ thuộc, nơi các đường lỗi có thể bị nứt, thì không thể đoán trước được. Chết tiệt sẽ đập vào quạt, và không sao cả. Chúng ta không thể ngăn chặn sự cố xảy ra. Tuy nhiên, điều thực sự hữu ích là đảm bảo rằng MTTD cho sự cố của bạn thực sự thấp.

Thời gian trung bình để phát hiện (MTTD) là một chỉ báo hiệu suất chính (KPI) đo thời gian trung bình cần thiết để một tổ chức xác định một sự cố hoặc mối đe dọa bảo mật. Thật khó để khái quát hóa, dựa trên lĩnh vực kinh doanh, mức độ nghiêm trọng của tác động, v.v., nhưng nếu bạn có thể giảm MTTD của mình xuống còn vài giây đến vài phút, thì bạn có thể giảm đáng kể tác động của một sự cố so với việc nói ra. là hàng giờ đến hàng ngày (chưa nói đến hàng tuần hoặc hàng tháng, điều đáng tiếc là hoàn toàn có thể xảy ra).

Sự hài hước giúp bạn giảm bớt nỗi đau trong khoảnh khắc

Tất cả điều này là rất NGHIÊM TRỌNG! Tiền đang bị thất lạc! Khách hàng có trải nghiệm khủng khiếp! Tuy nhiên, giữa tất cả những điều đó, tôi thấy điều quan trọng là phải có khiếu hài hước. Chúng ta không nên quên rằng mọi người đều là con người trong quá trình này và đang trải qua những mức độ căng thẳng khác nhau. Tiêm những liều lượng hài hước vào những thời điểm thích hợp sẽ giúp giảm bớt phần nào áp lực đó.

Nó xây dựng cảm giác về tình bạn thân thiết khiến cả nhóm cảm thấy như họ đang ở cùng nhau hơn là đang ở trên một hòn đảo trong địa ngục.

Đó là một bọc. Cảm ơn vì đã đọc!

⭐ Nếu bạn thích loại nội dung này, hãy nhớ theo dõi tôi hoặc đăng ký https://a1engineering.substack.com/subscribe ! ⭐

Ảnh nổi bật của Julien L trên Bapt