Câu hỏi phỏng vấn SRE và cách trả lời

Bạn đã đọc hàng trăm danh sách câu hỏi DevOps mà không danh sách nào khớp với mô tả công việc bạn ứng tuyển. Khoảng cách đó là có thật, và phần này sẽ giải thích một vòng phỏng vấn SRE thực sự đánh giá điều gì trước khi các danh sách câu hỏi bên dưới đi vào chi tiết. Nói ngắn gọn: tư duy về độ tin cậy trước tiên, chiều sâu hệ thống thứ hai, và code đứng thứ ba.

Sự khác biệt quan trọng nằm giữa việc biết một công cụ và hiểu độ tin cậy nghĩa là gì. Một ứng viên có thể đọc vanh vách các lệnh Kubernetes nhưng không giải thích được ngân sách lỗi dùng để làm gì sẽ gặp khó khăn, trong khi một ứng viên tư duy rõ ràng về sự cố, đo lường và đánh đổi có thể học công cụ ngay trong công việc. Người phỏng vấn thiết kế các vòng dựa trên niềm tin đó.

Một vòng phỏng vấn điển hình gồm kiến thức nền về độ tin cậy, một bài tập gỡ lỗi trực tiếp, một vòng thiết kế tập trung vào các chế độ lỗi, một vòng viết code xoay quanh tự động hóa, và một vòng phỏng vấn hành vi về trực ca. Một số công ty gộp phần gỡ lỗi vào vòng thiết kế; rất ít công ty bỏ hẳn nó, vì đây chính là vòng phân biệt những người từng thực sự mang theo máy nhắn tin với những người chỉ đọc về nó.

Đây là vòng mà từ ngữ rất quan trọng, vì các thuật ngữ này có ý nghĩa chính xác và người phỏng vấn lắng nghe xem bạn có dùng đúng hay không. Hãy luyện tập nói to các định nghĩa bằng ngôn từ của riêng bạn thay vì học thuộc lòng công thức.

• Sự khác biệt giữa SLI, SLO và SLA là gì?
• Bạn sẽ chọn SLI như thế nào cho một dịch vụ mà các nhóm khác phụ thuộc vào?
• Ngân sách lỗi là gì, và nhóm nên làm gì khi nó dùng hết?
• Độ khả dụng một trăm phần trăm có phải là mục tiêu hợp lý không? Hãy giải thích câu trả lời của bạn.
• Bạn đặt mục tiêu độ khả dụng cho một dịch vụ hoàn toàn mới, chưa có lịch sử, như thế nào?
• Một dịch vụ đạt SLO mỗi tháng nhưng người dùng vẫn liên tục phàn nàn. Điều gì đã sai?
• Các phân vị độ trễ thay đổi cách bạn đo lường một dịch vụ như thế nào?

Hai câu hỏi cuối là những câu phân biệt ứng viên. Cả hai đều nhằm kiểm tra xem bạn có hiểu rằng SLO là một đại diện cho trải nghiệm người dùng, không phải điểm số cần bảo vệ, và rằng giá trị trung bình che giấu những yêu cầu thực sự khiến người dùng tức giận.

Các vòng gỡ lỗi thường diễn ra trực tiếp và mang tính đối thoại: người phỏng vấn mô tả triệu chứng và bạn tiến dần đến nguyên nhân bằng cách yêu cầu bằng chứng. Họ đang đánh giá phương pháp của bạn, vì vậy hãy nói thành tiếng. Hãy nói bạn sẽ kiểm tra điều gì, mỗi kết quả sẽ loại trừ điều gì, và tiếp theo bạn sẽ kiểm tra gì.

• Độ trễ của một dịch vụ tăng vọt vào giữa trưa mà không có lần triển khai nào. Hãy trình bày cách bạn điều tra.
• Người dùng báo cáo lỗi ngắt quãng nhưng bảng điều khiển của bạn trông bình thường. Bạn sẽ nhìn vào đâu?
• Hãy giải thích những gì xảy ra từ lúc gõ một URL đến khi trang được hiển thị.
• Một máy chủ có load average cao nhưng mức sử dụng CPU thấp. Chuyện gì đang xảy ra?
• Bạn tìm ra tiến trình nào đang làm đầy ổ đĩa bằng cách nào, và bạn làm gì trước tiên?
• Hãy mô tả cách bạn gỡ lỗi một lỗi phân giải DNS bên trong một cụm.
• Các chế độ lỗi của việc thử lại là gì, và làm sao để việc thử lại trở nên an toàn?
• Bạn sẽ thiết kế health check như thế nào cho một dịch vụ đứng sau load balancer?
• Điều gì xảy ra khi một connection pool cơ sở dữ liệu cạn kiệt, và bạn phát hiện điều đó ra sao?

Các vòng thiết kế mở rộng cùng lối tư duy đó: bạn được yêu cầu xây dựng thứ gì đó, rồi được hỏi điều gì sẽ hỏng. Hãy chuẩn bị để nói về lỗi dây chuyền, backpressure, suy giảm mềm dẻo và dư địa công suất mà không cần được nhắc, vì tự nguyện nêu ra chính là tín hiệu quan trọng. Các bộ câu hỏi chuyên biệt hơn theo từng vị trí được tổng hợp tại ngân hàng câu hỏi phỏng vấn.

Vòng phỏng vấn hành vi cho vị trí SRE xoay quanh khả năng phán đoán dưới áp lực, và các câu hỏi rất cụ thể: hãy mô tả một sự cố bạn đã xử lý, một lần gián đoạn bạn gây ra, một bản postmortem bạn đã viết, một công việc lặp đi lặp lại bạn đã tự động hóa. Câu trả lời mơ hồ sẽ thất bại ở đây vì người phỏng vấn từng trực ca và có thể nhận ra ngay.

Hãy hình dung một kỹ sư nền tảng đang chuẩn bị cho vị trí liên quan đến độ tin cậy. Anh ấy từng gặp một sự cố khi một thay đổi cấu hình làm sập một API nội bộ trong một phần buổi sáng, và bản nháp đầu tiên của câu chuyện đổ lỗi cho một bước review bị thiếu. Việc viết lại xoay quanh những gì anh ấy đã quan sát, những gì đã thử, lý do vì sao rollback mất nhiều thời gian đến vậy, và cảnh báo anh ấy đã thêm vào sau đó đã biến một lời biện hộ thành bằng chứng cho khả năng phán đoán. Đó chính là hình dạng mà người phỏng vấn muốn thấy.

Hãy nói những câu chuyện này thành tiếng trước buổi phỏng vấn. Đọc lại trong im lặng sẽ che giấu những chỗ mà dòng thời gian bị hụt, còn công cụ phỏng vấn giả lập có thể đặt câu hỏi cho bạn trong thời gian giới hạn để bạn nghe được những khoảng dừng của chính mình. Trong buổi phỏng vấn trực tiếp, SubcueAI ghi lại câu hỏi và soạn sẵn câu trả lời có cấu trúc trên màn hình, chạy từ ứng dụng desktop gốc trên macOS hoặc Windows, hoặc từ Side Panel của tiện ích mở rộng trình duyệt trên Chrome và Edge, không có bot nào tham gia cuộc gọi. Nó không giúp được gì trong một bài đánh giá có giám sát hoặc một bài tập gỡ lỗi có chia sẻ màn hình, nơi mọi thứ bạn nhìn thấy cũng hiện ra với người phỏng vấn.