Văn hóa on-call mà GitHub đã xây dựng

GitHub từng là một hệ thống monolith lớn được xây dựng bằng Ruby on Rails.

Phần khó nhất trong mô hình on-call của monolith

• Vì bao gồm rất nhiều sản phẩm và tính năng lớn, nên phần lớn kỹ sư không hiểu đủ sâu codebase để tự tin ứng phó sự cố khi trực on-call. Khi bị gọi, họ cảm thấy mình giống một tổng đài chuyển tiếp hơn là một kỹ sư, vì phải escalte sang các team khác.

• Khoảng cách giữa các ca on-call quá dài và mỗi ca kéo dài 24 giờ. Kỹ sư chỉ trực on-call tối đa 4 lần mỗi năm nên không tích lũy được đủ ngữ cảnh trong lúc trực.

• Hệ thống giám sát và cảnh báo bị phân tán giữa nhiều team, trong khi mỗi người chỉ trải nghiệm on-call trong 24 giờ, nên monitoring và tài liệu cho on-call không được duy trì tốt.

• Vì phần lớn kỹ sư không tự tin với on-call của monolith, nên chỉ có 5–10 người thực sự hiểu toàn bộ hệ thống phải tham gia mọi sự cố production, dẫn đến sự mất cân bằng trong trách nhiệm on-call.

Văn hóa on-call mới

Rào cản về tổ chức công việc

• Họ tạo service catalog để làm rõ quyền sở hữu file, ánh xạ file vào service rồi ánh xạ service trở lại team.

• Vì monitoring và cảnh báo được thiết lập cho toàn bộ monolith, họ yêu cầu từng team tự xây dựng monitoring cho khu vực mà mình chịu trách nhiệm.

• Do có nhiều team phải làm việc này, họ tạo issue trên GitHub cho từng team và cung cấp checklist.

Rào cản về văn hóa và đào tạo

• Đại dịch đã tác động tiêu cực đến mọi người, nên họ phải ưu tiên cách tiếp cận dựa trên sự đồng cảm hơn nhiều so với dự tính ban đầu.

• Phần lớn kỹ sư chưa có kinh nghiệm on-call và cũng ít kinh nghiệm vận hành, nên họ xây dựng chương trình đào tạo. Họ bố trí giờ làm việc với các chuyên gia on-call, chuẩn bị đầy đủ công cụ và tài liệu, đồng thời tạo các kênh Slack để mọi người có thể nhờ giúp đỡ.

• Nhiều kỹ sư lo lắng on-call sẽ ảnh hưởng đến cuộc sống của mình đến mức nào. Nếu chưa có nhiều kinh nghiệm, việc điều chỉnh thời gian sinh hoạt thường ngày trong lúc trực có thể rất khó. Để hỗ trợ, họ tổng hợp các mẹo từ các chuyên gia on-call và áp dụng những biện pháp như để người khác có thể backup khi ai đó bỏ lỡ cuộc gọi. Đây là vấn đề của sự chưa quen thuộc, nên không thể chỉ giải quyết bằng đào tạo; phải trực on-call nhiều lần theo thời gian thì mọi người mới thấy thoải mái hơn.

• Vì có rất nhiều lo lắng về việc không xử lý tốt on-call, họ cố gắng tạo cảm giác an tâm rằng mắc lỗi cũng không sao, và dù làm tốt đến đâu thì sự cố vẫn có thể xảy ra.

• Mỗi sản phẩm có mức độ nghiêm trọng khác nhau, nên có team phải phản hồi trong vòng 5 phút, nhưng cũng có team có thể xử lý vào ngày hôm sau. Một số người cho rằng điều này không công bằng, nhưng thực chất chỉ là mỗi kỹ sư có mối quan tâm khác nhau.

• Khi triển khai thay đổi, không phải team nào cũng có thể dành nhiều thời gian để cải thiện trải nghiệm on-call. Khi on-call không vận hành tốt, cần cải thiện chính quy trình on-call. Họ truyền đạt với các team rằng nên dùng khoảng 20% thời gian để trả nợ kỹ thuật và khoảng 20% để cải thiện trải nghiệm on-call, và điều đó đòi hỏi góc nhìn dài hạn từ phía lãnh đạo.

[galadbran]

Tôi không rõ "on-call" là kiểu gì lắm... có phải là yêu cầu hỗ trợ không nhỉ. Chắc không phải kiểu trả lời điện thoại như ở nước mình...

[andrewchaa]

Ở công ty tôi, thông thường on-call là việc trong khoảng một tuần mỗi hai tháng phải phản ứng theo thời gian thực với các sự cố hệ thống ngoài giờ làm việc. Người ta dùng khá nhiều một ứng dụng tên là PagerDuty; khi xảy ra sự cố có mức độ nghiêm trọng cao — chẳng hạn phát sinh dead letter, hoặc tỷ lệ lỗi API vượt qua một ngưỡng nhất định... — thì điện thoại sẽ nhận cảnh báo ngay lập tức, rồi bạn truy cập bằng laptop của công ty, kiểm tra log và thực hiện các biện pháp cần thiết.

[sukso96100]

Bạn có thể hiểu là kiểu trực trực ca.

[bach80]

Cảm giác kiểu như trực ban hoặc trực tuần nhỉ. Kiểu luân phiên xử lý sự cố...