Xây dựng văn hóa On-Call lành mạnh

• Các mẹo của SoundCloud về “on-call”, tức chỉ định kỹ sư sẽ được gọi (paging) để xử lý khi có sự cố xảy ra ngoài giờ làm việc

1. Công việc on-call là tùy chọn (Optional, chỉ dành cho người tự nguyện đăng ký)

2. Vì là làm việc ngoài giờ hành chính nên được trả phụ cấp theo giờ, và khi phản hồi paging thì được trả thêm theo giờ

3. Kỹ sư on-call được tổ chức thành nhiều rotation

4. Mỗi rotation

→ gồm một nhóm kỹ sư đại diện cho một hoặc nhiều team

→ luôn có 1 kỹ sư trực để phụ trách hỗ trợ tuyến đầu cho các sự cố của mọi team trong rotation

→ các kỹ sư còn lại trực để cung cấp hỗ trợ tuyến hai cho các vấn đề liên quan đến dịch vụ của team mình

→ hỗ trợ tuyến hai dựa trên best-efforts: có thể nhận paging bất cứ lúc nào và nếu có thể thì cố gắng xử lý hết sức, nhưng nếu bản thân không thể thì không bắt buộc phải phản hồi

Vì sao công việc on-call lại tốt cho kỹ sư?

• Đưa nhiều kỹ sư khác nhau vào công việc on-call, ngoài DevOps và SRE (Site Reliability Engineers), là điều tốt cho cả công ty lẫn bản thân kỹ sư

• Giúp giảm gánh nặng cho các kỹ sư vận hành vốn thường xuyên phải làm ngoài giờ

• Tạo động lực để kỹ sư xây dựng các hệ thống ổn định và được tài liệu hóa tốt

→ việc trực tiếp chứng kiến sự cố giúp họ có được insight về cách cải thiện và làm hệ thống vững chắc hơn

• Cùng hỗ trợ cả hệ thống của mình lẫn hệ thống của người khác là cơ hội học hỏi rất tốt cho kỹ sư

Thông lệ tốt về quy trình: mỗi tổ chức đều khác nhau, nhưng đây là quy trình tối ưu mà SoundCloud đã tìm ra

• Chu kỳ trực của mỗi rotation khác nhau, nhưng phần lớn luân phiên theo đơn vị 1 đến 2 ngày

• Mức tối ưu là tham gia on-call khoảng 3 ngày mỗi tháng. Nhiều hơn sẽ dễ burnout, ít hơn thì kém hiệu quả.

→ tức số người tối ưu trong một rotation là 8~12 người. 10 người là hoàn hảo.

• Chọn quản lý chính thức/không chính thức trong rotation để quản lý rotation như lịch trực luân phiên, thay đổi nhân sự, v.v.

→ ví dụ: điều chỉnh lịch trực trong kỳ nghỉ lễ

Các team rotation và tổ chức

• Tổ chức của SoundCloud đã phát triển theo thời gian, với việc sáp nhập/chia tách/tạo team mới/chuyển team giữa các bộ phận

• Tuy nhiên, các team rotation on-call không phát triển với cùng tốc độ như tổ chức kỹ thuật

• Hiện nay nhiều rotation thậm chí trông như các nhóm ngẫu nhiên gồm những team hoàn toàn không liên quan

• Nhưng điều đó không thành vấn đề, và các nỗ lực thay đổi điều này đã bị dừng lại do kỹ sư phản đối

Thông lệ tốt về văn hóa: để mang lại lợi ích cho kỹ sư on-call và cả công ty, cần nuôi dưỡng các chuẩn mực và thái độ sau

• Những người làm on-call là những người muốn tham gia on-call. Kỹ sư tự nguyện gánh trách nhiệm (và được trả công) sẽ có nhiều động lực hơn khi ứng phó sự cố

• Các vấn đề như chu kỳ trực được các kỹ sư trong từng rotation tự thảo luận để quyết định. Công ty không đưa ra quy trình chuẩn về mô hình trực/thời điểm đổi ca/bàn giao ca giữa cá nhân

• Kỹ sư on-call thường dành thời gian trong giờ làm việc chính thức để điều tra các vấn đề này, nhằm ngăn chúng trở nên nghiêm trọng hơn hoặc khiến phải paging người khác ngoài giờ làm việc

• Khi ứng phó sự cố, kỹ sư có thể gọi kỹ sư khác để nhờ giúp đỡ. Không ai thích bị gọi hỗ trợ tuyến hai vào giữa đêm, nhưng nếu có thể thì họ vẫn phản hồi và hỗ trợ, từ đó có thể hướng dẫn để sau này người kia tự xử lý được tình huống tương tự

• Sau một khoảng thời gian hợp lý, có thể tự do bàn giao công việc cho người khác. Với các sự cố nghiêm trọng hoặc kéo dài, nếu kỹ sư đã mệt đến mức không thể làm việc hiệu quả thì nên bàn giao cho người khác trong vòng 4 giờ hoặc sớm hơn

• Quan trọng nhất là “nuôi dưỡng văn hóa học hỏi thay vì văn hóa đổ lỗi”. Nhấn mạnh bao nhiêu cũng không thừa

→ sai sót là phần không thể tránh khỏi trong ứng phó sự cố, và học từ sai sót sẽ giúp xây dựng một tổ chức kỹ thuật mạnh hơn và giỏi hơn về mặt kỹ thuật

→ nếu trừng phạt con người vì sai sót, kỹ sư sẽ sợ hành động khi gặp tình huống mới, sợ yêu cầu trợ giúp và sợ sự minh bạch

→ cuối cùng, trong một văn hóa đổ lỗi, họ sẽ rời rotation on-call hoặc rời công ty

Khi xảy ra sự cố lớn

• Việc ứng phó với sự cố sập toàn bộ site hoặc một sự cố nghiêm trọng là điều gây căng thẳng cho tất cả mọi người

• Đây cũng là một bài kiểm tra sức chịu đựng đối với văn hóa on-call của công ty

• Việc các kỹ sư có thể cùng làm việc và tin tưởng lẫn nhau quan trọng hơn bất cứ điều gì khác

• Nếu có thể thừa nhận điều mình không biết, nhờ người khác giúp đỡ, nói thật về việc mình đã mắc lỗi, và nói rằng mình quá mệt để tiếp tục, thì vấn đề sẽ được giải quyết nhanh hơn

• Việc nuôi dưỡng những hành vi này phải được thực hiện trước khi sự cố lớn xảy ra. Kỹ sư sẽ học hỏi qua kinh nghiệm khi xử lý các sự cố nhỏ và hợp tác với đồng nghiệp.

→ những sự cố nhỏ là bài tập dượt cho sự cố lớn

[xguru]

• Văn hóa on-call mà GitHub đã xây dựng https://vi.news.hada.io/topic?id=3551

• GitLab On-Call Runbooks https://vi.news.hada.io/topic?id=966

Startup thường thiếu người nên có cảm giác lúc nào cũng phải on-call...

Nhưng khi tổ chức bắt đầu lớn hơn một chút, chỉ một số người sẽ liên tục phải on-call, và có thể thấy họ bị kiệt sức khi vẫn phải xử lý sự cố vào buổi tối và cuối tuần.

Về cơ bản, có lẽ cần xây dựng văn hóa cho thật tốt (nghĩ lại thì chính tôi cũng chưa làm tốt việc này nên đang tự nhìn nhận lại...)