Top 40+ câu hỏi phỏng vấn SRE nhiều cấp độ

Nội dung bài viết

Bạn đang chuẩn bị cho phỏng vấn Site Reliability Engineer (SRE)? Từ junior đến quản lý, mỗi cấp độ SRE sẽ có những yêu cầu và thử thách riêng biệt. Bài viết này là tổng hợp hơn 40 câu hỏi phỏng vấn SRE phổ biến, được phân loại chi tiết theo từng cấp độ. Nắm chắc các kiến thức này, bạn sẽ sẵn sàng vượt qua và chinh phục thử thách để đạt được công việc mơ ước.

Đọc bài viết để hiểu thêm về:

Các loại câu hỏi thường gặp trong phỏng vấn Site Reliability Engineer;
Câu hỏi phỏng vấn kỹ sư SRE cấp độ cơ bản;
Câu hỏi phỏng vấn kỹ sư SRE cấp trung;
Câu hỏi phỏng vấn kỹ sư SRE cấp cao;
Tips chuẩn bị cho buổi phỏng vấn Site Reliability Engineer thành công.

Các loại câu hỏi thường gặp trong phỏng vấn Site Reliability Engineer

Câu hỏi về thiết kế và kiến trúc hệ thống

Đây là một phần không thể thiếu trong các buổi phỏng vấn kỹ sư SRE. Nhà tuyển dụng muốn đánh giá:

Hiểu biết về các hệ thống phức tạp
Khả năng lập kế hoạch và quản lý các hệ thống có khả năng mở rộng, đáng tin cậy và hiệu quả.
Tư duy tổng thể và khả năng dự đoán rủi ro của bạn khi xây dựng hệ thống.

Bạn cần chuẩn bị cách thiết kế một dịch vụ, ôn luyện các khái niệm như cân bằng tải, bộ nhớ đệm, lưu trữ dữ liệu và phục hồi sau thảm họa.

Câu hỏi về quản lý và khắc phục sự cố

Quản lý sự cố là trọng tâm của kỹ sư SRE. Các câu hỏi có thể bao gồm tình huống giả định hoặc kinh nghiệm xác định và giải quyết các vấn đề xử lý sự cố ngừng hoạt động và suy giảm hệ thống. Điều nhà tuyển dụng tìm kiếm là cách bạn ưu tiên xử lý, ra quyết định dưới áp lực, và mức độ thành thạo khi dùng các công cụ giám sát hoặc quy trình post-mortem.

Câu hỏi về lập trình và tự động hóa

Bạn có thể được yêu cầu viết code đơn giản, hoặc nói về các công cụ scripting và automation bạn từng dùng.

Mục tiêu của phần này là đánh giá khả năng viết code sạch, hiệu quả, cùng hiểu biết cơ bản về thuật toán và cấu trúc dữ liệu.

Câu hỏi về số liệu độ tin cậy và hiệu suất

Những câu hỏi này đánh giá kiến thức của ứng viên về các chỉ số hiệu suất chính và khả năng sử dụng các chỉ số để thúc đẩy cải thiện độ tin cậy. Hãy chuẩn bị nói về SLI, SLO, SLA, cách bạn đặt ra, theo dõi và cải thiện chúng.

Câu hỏi về sự phù hợp văn hóa và hợp tác

Kỹ sư SRE cần hợp tác hiệu quả với các nhóm phát triển và vận hành. Nhà tuyển dụng thường hỏi về cách bạn phối hợp trong dự án, chia sẻ kiến thức hoặc xử lý bất đồng. Những câu hỏi này sẽ đánh giá sự phù hợp của bạn với văn hóa công ty.

Đọc chi tiết: Site Reliability Engineer là gì: Kỹ năng cần có của mỗi kỹ sư SRE

Câu hỏi phỏng vấn SRE cấp độ cơ bản: Câu hỏi kiến thức

1. SRE khác với DevOps như thế nào?

Mặc dù SRE và DevOps có chung mục tiêu là cải thiện sự hợp tác giữa các nhóm phát triển và vận hành, nhưng cả 2 có cách tiếp cận riêng biệt:

DevOps là một triết lý văn hóa và mô hình tổ chức, trong khi SRE là cách triển khai DevOps bằng tư duy kỹ thuật và các chỉ số đo lường cụ thể.
Với DevOps, trọng tâm là thay đổi văn hóa làm việc, khuyến khích hợp tác, tự động hóa quy trình triển khai, sử dụng CI/CD, IaC và các công cụ giúp đội Dev và Ops phối hợp nhịp nhàng hơn.
Với SRE, trọng tâm là độ tin cậy và hiệu suất. Kỹ sư SRE thường có nền tảng lập trình mạnh, họ viết code để tự động hóa vận hành, thiết lập và theo dõi các chỉ số như SLI, SLO, SLA, và đảm bảo hệ thống hoạt động ổn định theo các ngưỡng đó.

2. Giải thích các khái niệm SLA, SLO và SLI.

SLA (Service-Level Agreement): SLA là thỏa thuận chính thức giữa nhà cung cấp dịch vụ và người dùng cuối, xác định mức độ dịch vụ mong đợi. SLA nêu rõ các chỉ số hiệu suất chính như thời gian hoạt động, thời gian phản hồi và thời gian hỗ trợ. SLA có tính ràng buộc pháp lý và thường kèm hình phạt nếu không đáp ứng các tiêu chuẩn đã thỏa thuận.
SLO (Service-Level Objective): SLO là mục tiêu cụ thể, có thể đo lường mà nhà cung cấp dịch vụ muốn đạt được. SLO được xây dựng dựa trên SLA và được sử dụng để thiết lập kỳ vọng thực tế về độ tin cậy của dịch vụ. Ví dụ: SLO có thể quy định rằng 99,9% yêu cầu sẽ được xử lý trong một thời gian phản hồi cụ thể.
SLI (Service-Level Indicator): SLI là chỉ số được sử dụng để đo lường hiệu suất của dịch vụ. SLI cung cấp dữ liệu cần thiết để đánh giá liệu các SLO có được đáp ứng hay không. Ví dụ về SLI bao gồm độ trễ (thời gian phản hồi), tỷ lệ lỗi và thông lượng. SLI rất cần thiết để theo dõi hiệu suất dịch vụ và xác định các điểm cần cải thiện.

3. Giải thích cấu trúc dữ liệu và mô tả cấu trúc dữ liệu vật lý cũng như cấu trúc dữ liệu logic.

Cấu trúc dữ liệu là một tập hợp các quy tắc để tổ chức và lưu trữ dữ liệu trong máy tính. Cấu trúc dữ liệu được sử dụng để cấu trúc cơ sở dữ liệu, quản lý bộ nhớ và tổ chức dữ liệu. Cấu trúc dữ liệu cho phép tổ chức dữ liệu dễ dàng, truy xuất dữ liệu dễ dàng và sử dụng tài nguyên hiệu quả.

Cấu trúc dữ liệu vật lý là dữ liệu được lưu trữ trong bộ nhớ vật lý thực tế. Bao gồm Arrays và Linked Lists:
- Arrays là tập hợp các phần tử dữ liệu liền kề cùng kiểu.
- Linked Lists cũng là tập hợp các phần tử dữ liệu nhưng có thể liền kề hoặc không liền kề trong bộ nhớ. Linked Lists bao gồm các node lưu trữ dữ liệu và một con trỏ trỏ đến node tiếp theo trong bộ nhớ.
Cấu trúc dữ liệu logic được xem là tất cả các cấu trúc dữ liệu được xây dựng bằng cách sử dụng hai cấu trúc dữ liệu vật lý trên. Các cấu trúc dữ liệu logic có thể là stack, queue, tree, graph… Các cấu trúc dữ liệu này chỉ có logic và dựa trên logic này, định nghĩa một thuộc tính và lưu trữ dữ liệu bằng Arrays và Linked Lists trong bộ nhớ.

4. Tại sao giám sát lại quan trọng trong SRE?

Giám sát bao gồm việc liên tục thu thập và phân tích dữ liệu từ hệ thống để đảm bảo hệ thống hoạt động chính xác. Giám sát là một trong những trụ cột quan trọng nhất trong SRE vì nó giúp đội ngũ hiểu được hệ thống đang thực sự hoạt động như thế nào, thay vì chỉ “đoán” dựa trên cảm nhận:

Giám sát giúp xác định các vấn đề trước khi chúng ảnh hưởng đến người dùng. Thiết lập cảnh báo cho các hành vi bất thường cho phép kỹ sư SRE nhanh chóng phát hiện và xử lý sự cố, giảm thiểu thời gian ngừng hoạt động và tác động đến người dùng.
Giám sát cung cấp thông tin chi tiết về hiệu suất hệ thống, cho phép các kỹ sư SRE tối ưu hóa tài nguyên và cải thiện hiệu suất. Các số liệu như mức sử dụng CPU, mức sử dụng bộ nhớ và thời gian phản hồi giúp xác định điểm nghẽn hiệu suất và các lĩnh vực cần cải thiện.
Giám sát giúp hiểu rõ việc sử dụng tài nguyên và lập kế hoạch tăng trưởng trong tương lai. Bằng cách phân tích xu hướng sử dụng, kỹ sư SRE dự báo nhu cầu và đảm bảo hệ thống có thể xử lý lưu lượng truy cập tăng cao.
Giám sát cung cấp dữ liệu để chẩn đoán và giải quyết sự cố nhanh chóng. Các công cụ giám sát cung cấp thông tin giá trị về trạng thái của hệ thống khi sự cố xảy ra, giúp các kỹ sư SRE xác định nguyên nhân gốc rễ và triển khai bản sửa lỗi.
Giám sát đảm bảo hệ thống đáp ứng các yêu cầu về quy định và bảo mật. Kỹ sư SRE có thể chứng minh việc tuân thủ các tiêu chuẩn và quy định của ngành bằng cách theo dõi các số liệu chính và tạo báo cáo.

5. Giải thích khái niệm Error Budget và ý nghĩa của nó.

Error Budget (ngân sách lỗi) thể hiện biên độ cho phép đối với các lỗi hệ thống trong một khung thời gian cụ thể, cân bằng giữa đổi mới và độ tin cậy. Error Budget định hướng cho việc ra quyết định triển khai và quản lý rủi ro, đảm bảo các tính năng mới được giới thiệu mà không ảnh hưởng đến tính ổn định của hệ thống.

6. DHCP là gì và được sử dụng để làm gì?

DHCP (Dynamic Host Configuration Protocol) là một giao thức cho phép các mạng tự động cấp phát địa chỉ IP cho các máy chủ trong mạng. DHCP được sử dụng để gán địa chỉ IP cho các thiết bị như máy tính và bộ định tuyến. Khi một thiết bị được cài đặt, nó có thể cần một địa chỉ IP để truy cập Internet. Vì vậy, khi một thiết bị mới được cài đặt, nó sẽ nhận được địa chỉ IP từ DHCP để có thể kết nối vào mạng.

Khi một thiết bị kết nối với mạng, trước tiên nó cần một địa chỉ IP để có thể giao tiếp với các máy chủ khác trên mạng. Và vì hầu hết các mạng chỉ có một địa chỉ IP được gán cho mỗi thiết bị, nên phải có một cơ chế phân bổ động các địa chỉ đó.

Để máy chủ DHCP hoạt động, phải có ít nhất 2 phần: 1 giao diện (thường là Ethernet hoặc WiFi) và 1 cơ sở dữ liệu lưu trữ thông tin về kết nối và người dùng. Vì mỗi thiết bị được kết nối đều cần 1 giao diện, cơ sở dữ liệu này phải chứa tất cả thông tin về các thiết bị đó và cách chúng được kết nối. Tất cả dữ liệu này sau đó được tổng hợp lại khi có yêu cầu kết nối.

7. Lệnh kill của Linux là gì?

Lệnh kill của Linux là một cách dễ dàng để tắt tất cả các tiến trình đang chạy. Với lệnh này, bạn có thể tắt một tiến trình, ví dụ: một chương trình, một dịch vụ hoặc một tiến trình không chạy trên bất kỳ hệ thống Linux nào. Nói cách khác, nó sẽ tắt hoặc chấm dứt bất kỳ tiến trình nào đang chạy trên hệ thống.

Lệnh này đặc biệt hữu ích để đóng một ứng dụng bị treo, chiếm CPU quá mức, hoặc không phản hồi, giúp SRE giải phóng tài nguyên nhanh mà không cần khởi động lại toàn bộ hệ thống.

8. Sự khác biệt giữa SNAT và DNAT là gì?

SNAT	DNAT
Thường được sử dụng để thay đổi địa chỉ hoặc cổng riêng tư thành địa chỉ hoặc cổng công khai cho các packet rời khỏi mạng.	Thường được sử dụng để chuyển hướng các packet đến có đích là địa chỉ hoặc cổng công khai đến địa chỉ IP hoặc cổng riêng tư bên trong mạng.
Dịch địa chỉ IP nguồn trong kết nối sang địa chỉ IP của hệ thống BIG-IP mà người ta xác định.	Dịch địa chỉ IP của máy chủ nội bộ được thiết bị bảo vệ thành địa chỉ IP công cộng.
Được sử dụng để thay đổi địa chỉ nguồn của packet.	Được sử dụng để thay đổi địa chỉ đích của packet.
Thay đổi cổng nguồn trong TCP/UDP header.	Thay đổi cổng đích trong TCP/UDP header.
Thường cho phép nhiều máy chủ bên trong có thể truy cập vào bất kỳ máy chủ nào bên ngoài.	Thường cho phép nhiều máy chủ ở bên ngoài có được một máy chủ duy nhất ở bên trong.

9. Có những loại khả năng quan sát nào? Làm thế nào để cải thiện khả năng quan sát của hệ thống?

Khả năng quan sát (observability) là khả năng hiểu rõ những gì đang diễn ra bên trong hệ thống phức tạp thông qua dữ liệu được thu thập từ bên ngoài. Có nhiều loại khả năng quan sát khác nhau trong một tổ chức:

Giám sát thời gian thực: Cho phép người dùng trong tổ chức theo dõi những gì đang diễn ra theo thời gian thực, bao gồm những thông tin như số lượng người truy cập trang web trên điện thoại hoặc máy tính bảng.
Giám sát lịch sử: Cho phép người dùng trong tổ chức xem dữ liệu từ các kỳ trước, hữu ích nhất khi theo dõi các giao dịch tài chính như số tiền đã chi tiêu theo thời gian.
Giám sát toàn hệ thống: Được sử dụng trên tất cả các thiết bị trong một tổ chức, bao gồm điện thoại và máy tính, cho phép người dùng trong tổ chức xem dữ liệu trên tất cả các thiết bị trong tổ chức.

Chúng ta có thể tăng khả năng quan sát của tổ chức bằng cách:

Nhận biết các loại dữ liệu lưu chuyển từ một môi trường, xác định loại dữ liệu nào trong số đó có liên quan và giá trị đối với các observability của bạn.
Giúp dữ liệu trở nên có ý nghĩa bằng cách clọc và chuyển dữ liệu thành thông tin chi tiết có thể thực hiện được liên quan đến hiệu suất của hệ thống.

Khả năng quan sát có thể cung cấp thông tin hữu ích về mức độ trưởng thành DevOps của một tổ chức.

10. Runbook là gì và tại sao nó lại quan trọng?

Sổ tay hướng dẫn (runbook) biên soạn các quy trình và thao tác thường quy mà một kỹ sư SRE có thể thực hiện. Runbook cung cấp hướng dẫn từng bước để giải quyết sự cố thường gặp và thực hiện các tác vụ. Runbook rất cần thiết vì chúng chuẩn hóa quy trình, giảm downtime và hỗ trợ nhân viên on-call.

11. Hệ thống tập tin “/proc” là gì?

/proc là pseudo-fs (pseudo filesystem – hệ thống tệp giả lập) hiển thị trạng thái kernel & tiến trình. Nó được mount trong hệ thống Linux khi cần thực thi một tiến trình hoặc truy cập một số tài nguyên hệ thống nhất định. Có các thư mục con bên dưới /proc:

/proc/cpuinfo: Cho biết thông tin chi tiết về CPU (tên, tốc độ, số core).
/proc/meminfo: Hiển thị dung lượng RAM đang dùng/còn trống.
/proc/1/: Chứa thông tin về tiến trình đầu tiên (PID 1, thường là init hoặc systemd).
/proc/<PID>/maps: Cho biết tiến trình đó đang dùng những vùng bộ nhớ nào.

12. Hard link và soft link khác nhau như thế nào?

Cả hard link và soft link đều là cách tạo liên kết đến một file khác, nhưng chúng khác nhau ở một số điểm sau:

Về số inode: Các tập tin hard link có cùng số inode, trong khi tập tin soft link sẽ có số inode khác nhau.
Về thư mục: Không được phép sử dụng hard link cho các thư mục, nhưng có thể sử dụng soft link để liên kết các thư mục.
Về hệ thống tập tin: Hard link không thể sử dụng trên nhiều hệ thống tập tin, trong khi soft link có thể.
Về dữ liệu: Dữ liệu có trong tệp gốc vẫn có sẵn trong các hard link, còn soft link chỉ trỏ đến tên tệp chứ không lưu trữ dữ liệu của tệp.
Về xóa tập tin gốc: Nếu tệp gốc bị xóa, hard link vẫn hoạt động vì nó truy cập vào dữ liệu và tệp gốc đã truy cập. Trong khi đó, soft link sẽ không hoạt động.
Về tốc độ: Hard link tương đối nhanh hơn, trong khi soft link chậm hơn so với link thông thường.

13. Canary Release là gì?

Canary Release là một chiến lược triển khai trong đó phiên bản dịch vụ mới được triển khai dần dần cho một nhóm nhỏ người dùng trước khi được cung cấp cho toàn bộ người dùng. Chiến lược này giúp phát hiện vấn đề sớm, giảm thiểu rủi ro và phản hồi của người dùng.

14. Giải thích về APR (Accelerated Problem Resolution). APR có những giai đoạn nào?

Trong SRE, APR là quy trình chuẩn giúp phát hiện, chẩn đoán, khắc phục và cải thiện sự cố nhanh nhất có thể, nhằm giảm thiểu downtime và tác động đến người dùng.

5 giai đoạn chính của APR trong SRE bao gồm:

Giám sát và cảnh báo: Giám sát liên tục là nền tảng cơ bản của APR, bao gồm chủ động quan sát các chỉ số hệ thống để phát hiện bất thường hoặc suy giảm hiệu suất. Khi phát hiện bất thường, cảnh báo sẽ được tạo ra để thông báo cho kỹ sư SRE.
Chẩn đoán nhanh: Tốc độ là yếu tố then chốt trong việc giải quyết vấn đề nhằm giảm thiểu thời gian ngừng hoạt động. Kỹ sư SRE thực hiện đánh giá ban đầu nhanh chóng để hiểu rõ bản chất và mức độ nghiêm trọng của sự cố, bao gồm thu thập dữ liệu, log và các thông tin chẩn đoán khác để xác định nguyên nhân gốc rễ.
Giải quyết và giảm thiểu sự cố: Tùy thuộc vào bản chất của sự cố, việc này có thể bao gồm việc áp dụng các bản sửa lỗi nhanh, định tuyến lại lưu lượng mạng hoặc mở rộng tài nguyên.
Phân tích và ghi chép sau sự cố: Sau khi giải quyết sự cố, một quy trình phân tích sau sự cố (postmortem) sẽ được tiến hành kỹ lưỡng để tìm hiểu nguyên nhân, cách xử lý và tác động của nó. Thông tin này được ghi chép để tham khảo trong tương lai, rút kinh nghiệm và cải thiện các chiến lược ứng phó.
Cải tiến liên tục: Thông tin chi tiết từ phân tích hậu sự cố được sử dụng để cải thiện hệ thống và quy trình ứng phó sự cố. Điều này bao gồm việc triển khai các biện pháp phòng ngừa, nâng cao công cụ giám sát, cải thiện cơ chế cảnh báo và tinh chỉnh các giao thức để giải quyết các sự cố trong tương lai nhanh hơn và hiệu quả hơn.

Câu hỏi phỏng vấn SRE cấp độ cơ bản: Câu hỏi thực hành

15. Quá trình lưu trữ đệm diễn ra ở đâu trên máy chủ? Và việc vô hiệu hóa bộ nhớ đệm là gì?

Việc lưu trữ đệm có thể diễn ra ở nhiều cấp độ khác nhau trong một máy chủ:

Ở máy chủ web front-end, khi một trang được yêu cầu, nội dung của trang đó sẽ được lưu vào bộ nhớ đệm.
Trên máy chủ web back-end, khi một trang được yêu cầu, nội dung của bộ nhớ đệm sẽ được kiểm tra để xem nội dung đó có còn hợp lệ hay không. Nếu vẫn còn hợp lệ, không cần thực hiện yêu cầu nào. Thay vào đó, dữ liệu được lưu trong bộ nhớ đệm có thể được phục vụ ngay lập tức. Nếu dữ liệu được lưu trong bộ nhớ đệm đã thay đổi kể từ khi được lưu trữ, thì cần phải cập nhật dữ liệu đó trước khi có thể phục vụ.

Việc vô hiệu hóa bộ nhớ đệm cũng là một phần quan trọng của việc lưu trữ bộ nhớ đệm trên máy chủ, bao gồm kiểm tra xem nội dung được lưu có còn đúng hay không và liệu có cần cập nhật trước khi phục vụ hay không.

16. Viết một hàm trong Python để kiểm tra xem một chuỗi nhất định có phải là chuỗi palindrome hay không.

Một chuỗi palindrome là một chuỗi có cùng nội dung khi đọc xuôi hay ngược. Dưới đây là một hàm Python để kiểm tra xem một chuỗi có phải là chuỗi palindrome hay không:

def is_palindrome(s): return s == s[::-1].

17. Hãy mô tả quy trình Post-Mortem Analysis.

Tạo timeline các sự kiện dẫn đến và trong quá trình xảy ra sự cố giúp xác định các hành động và quyết định quan trọng góp phần gây ra sự cố.
Xác định nguyên nhân cơ bản của sự cố và hiểu rõ nguyên nhân gốc rễ giúp phát triển các giải pháp thiết thực để ngăn ngừa tái diễn.
Đánh giá ảnh hưởng của sự cố đến người dùng và doanh nghiệp, giúp ưu tiên các hành động khắc phục và hiểu rõ mức độ nghiêm trọng của sự cố.
Xây dựng các hành động khắc phục để ngăn ngừa tái diễn. Điều này có thể bao gồm sửa lỗi, cập nhật quy trình hoặc triển khai giám sát bổ sung.
Tạo báo cáo ghi lại tất cả các phát hiện và hành động đã thực hiện. Ghi chép lại quá trình phân tích hậu kiểm đảm bảo rằng các bài học kinh nghiệm được chia sẻ với nhóm và có thể được tham khảo trong tương lai.

18. Viết một tập lệnh theo dõi mức sử dụng CPU và gửi cảnh báo nếu vượt quá ngưỡng nhất định.

Để theo dõi mức sử dụng CPU và gửi cảnh báo nếu vượt quá ngưỡng nhất định, bạn có thể sử dụng một tập lệnh Bash đơn giản. Sau đây là một ví dụ:

while true; do cpu=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1}'); if (( $(echo "$cpu > 80" | bc -l) )); then echo "CPU usage is above 80%"; fi; sleep 60; done.

Câu hỏi phỏng vấn kỹ sư SRE cấp trung

19. Bạn sử dụng những công cụ nào để giám sát và logging?

Prometheus: Bộ công cụ giám sát và cảnh báo nguồn mở thu thập và lưu trữ số liệu trong cơ sở dữ liệu chuỗi thời gian, cung cấp khả năng truy vấn mạnh mẽ và tích hợp tốt với các công cụ khác.
Grafana: Nền tảng giám sát và trực quan hóa dữ liệu tích hợp với nhiều nguồn dữ liệu khác nhau, để tạo ra bảng thông tin tương tác và có thể tùy chỉnh.
Nagios: Công cụ giám sát ứng dụng, dịch vụ và cơ sở hạ tầng, cung cấp các tính năng cảnh báo và báo cáo để theo dõi tình trạng hệ thống.
Datadog: Nền tảng giám sát và phân tích dựa trên đám mây cung cấp khả năng hiển thị theo thời gian thực về cơ sở hạ tầng và ứng dụng. Nền tảng hỗ trợ tích hợp nhiều dịch vụ khác nhau và cung cấp các tính năng như bảng điều khiển cảnh báo và quản lý log.
ELK Stack (Elasticsearch, Logstash, Kibana): ELK Stack là một bộ công cụ nguồn mở dùng để tìm kiếm, phân tích và trực quan hóa dữ liệu log. Elasticsearch lưu trữ và lập chỉ mục dữ liệu log, Logstash xử lý và chuyển đổi log, còn Kibana cung cấp giao diện web để truy vấn và trực quan hóa dữ liệu.
Splunk: Nền tảng thương mại để tìm kiếm, giám sát và phân tích dữ liệu do máy tạo ra. Splunk cung cấp các công cụ mạnh mẽ để quản lý log, giám sát thời gian thực và phân tích dữ liệu .

20. Bạn sử dụng những chiến lược nào để phục hồi sau thảm họa?

Để đảm bảo hệ thống có thể phục hồi nhanh sau sự cố nghiêm trọng, tôi thường áp dụng một số chiến lược như:

Sao lưu định kỳ: Dữ liệu được backup nhiều bản và lưu ở các vị trí khác nhau để phòng ngừa mất mát.
Sao chép dữ liệu (Replication): Duy trì bản sao đồng bộ giữa các vùng hoặc data center để có thể khôi phục gần như ngay lập tức.
Chuyển đổi dự phòng (Failover): Có hệ thống standby sẵn sàng kích hoạt tự động khi hệ thống chính gặp sự cố.
Lập kế hoạch phục hồi: Xác định rõ vai trò, quy trình và mức ưu tiên dịch vụ trong tình huống thảm họa.
Kiểm tra định kỳ (Disaster Recovery Drill): Thường xuyên mô phỏng sự cố để đảm bảo quy trình thực sự hiệu quả.

Mục tiêu là giảm tối đa RTO và RPO, đảm bảo dịch vụ nhanh chóng trở lại hoạt động bình thường mà không mất dữ liệu.

21. Bạn áp dụng phương pháp nào để logging và giám sát trong kiến trúc microservice?

Việc logging và giám sát trong kiến trúc microservice yêu cầu các biện pháp tốt nhất cụ thể để đảm bảo khả năng hiển thị và khả năng bảo trì:

Logging tập trung: Tổng hợp log từ tất cả các dịch vụ trong một hệ thống tập trung như ELK Stack (Elasticsearch, Logstash, Kibana) hoặc Splunk. Logging tập trung giúp đơn giản hóa việc tìm kiếm, phân tích và đối chiếu log từ các dịch vụ khác nhau.
Logging có cấu trúc: Sử dụng các định dạng log có cấu trúc (ví dụ: JSON) để phân tích cú pháp và truy vấn. Log có cấu trúc giúp phân tích và trực quan hóa dữ liệu log dễ dàng hơn.
ID tương quan: Bao gồm ID tương quan trong log để theo dõi các yêu cầu trên nhiều dịch vụ. ID tương quan giúp theo dõi luồng yêu cầu qua hệ thống, giúp gỡ lỗi và chẩn đoán sự cố dễ dàng hơn.
Chỉ số cấp độ dịch vụ: Theo dõi các chỉ số cụ thể của từng dịch vụ như tỷ lệ yêu cầu, tỷ lệ lỗi và độ trễ. Chỉ số cấp độ dịch vụ cung cấp thông tin chi tiết về hiệu suất và tình trạng của từng dịch vụ.
Kiểm tra tình trạng: Triển khai kiểm tra tình trạng cho các dịch vụ để đảm bảo chúng hoạt động chính xác. Các trình điều phối (ví dụ: Kubernetes ) có thể sử dụng kiểm tra tình trạng để quản lý các phiên bản dịch vụ.

22. Bạn sẽ bảo mật container Docker của mình như thế nào?

Để giữ cho các container docker của mình an toàn, tôi thường làm các bước sau:

Chọn image đáng tin cậy: Chỉ dùng image chính chủ hoặc đã được kiểm định, tránh các image từ nguồn không rõ.
Bật Docker Content Trust (DCT): Đảm bảo chỉ chạy các image đã được ký xác thực.
Giới hạn tài nguyên: Thiết lập CPU, RAM limit cho từng container để tránh chiếm dụng quá mức.
Dùng công cụ kiểm tra bảo mật: Ví dụ như Trivy, Clair hoặc Docker Bench for Security để phát hiện lỗ hổng.
Cập nhật và quét định kỳ: Container và base image luôn được cập nhật để giảm nguy cơ bị khai thác.

23. Bạn sẽ xử lý lỗi hệ thống như thế nào khi tải cao điểm?

Khi hệ thống gặp lỗi trong thời gian tải cao, tôi luôn ưu tiên phản ứng nhanh, sau đó mới tối ưu lâu dài. Quy trình của tôi thường gồm 4 bước:

Kích hoạt phản hồi sự cố: Thông báo ngay cho đội SRE/DevOps và kích hoạt kênh liên lạc khẩn.
Xác định nguyên nhân tạm thời: Dựa vào metric, log, alert để khoanh vùng nhanh vấn đề, ví dụ, bottleneck ở DB hay network.
Khắc phục tức thời: Thực hiện scale up, cache tạm, hoặc redirect traffic để ổn định hệ thống.
Phân tích hậu sự cố: Sau khi dịch vụ ổn định, thực hiện root cause analysis để tránh lỗi tương tự tái diễn.

24. Bạn quản lý bí mật và dữ liệu nhạy cảm trong hệ thống như thế nào?

Tôi luôn tuân thủ nguyên tắc truy cập đặc quyền tối thiểu – chỉ cấp quyền cho ai hoặc dịch vụ nào thực sự cần. Cụ thể, tôi lưu trữ bí mật trong Vault (như HashiCorp Vault hoặc AWS Secrets Manager), đảm bảo mã hóa dữ liệu khi truyền và khi lưu trữ.

25. Bạn xử lý sự cố sản xuất như thế nào?

Trong một lần ứng dụng web của tôi gặp hiện tượng tăng độ trễ đột biến khi traffic tăng cao, tôi nhanh chóng xác định bottleneck nằm ở database. Tôi đã thực hiện tối ưu hóa các truy vấn chậm và triển khai bộ nhớ đệm, giúp giải quyết vấn đề và cải thiện hiệu suất lên 50%. Sau đó, tôi ghi lại toàn bộ sự cố trong postmortem để cải thiện giám sát và cảnh báo cho lần sau.

26. Bạn quản lý việc di chuyển cơ sở dữ liệu như thế nào khi làm việc trong môi trường trực tiếp?

Tôi thường thực hiện theo các bước:

Kiểm tra cẩn thận trong môi trường staging
Sử dụng công cụ quản lý migration có version control như Flyway hoặc Liquibase để rollback dễ dàng
Thực hiện migration từng phần hoặc trong giờ thấp điểm để giảm tác động đến người dùng
Theo dõi metric và log sau khi triển khai để phát hiện sớm vấn đề
Luôn có bản sao lưu trước khi migrate, đảm bảo có thể khôi phục nếu xảy ra lỗi.

27. Bạn triển khai kỹ thuật Chaos như thế nào?

Kỹ thuật Chaos cố tình đưa lỗi vào hệ thống để kiểm tra khả năng phục hồi và hiểu rõ hành vi của hệ thống trong điều kiện lỗi. Mục tiêu là xác định điểm yếu trước khi chúng gây ra sự cố thực tế. Tôi triển khai kỹ thuật Chaos như sau:

Thiết lập các số liệu cơ sở thể hiện hành vi bình thường của hệ thống, chẳng hạn như thời gian phản hồi, tỷ lệ lỗi và thông lượng.
Dự đoán cách hệ thống sẽ phản ứng với các lỗi hoặc sự gián đoạn cụ thể, tạo cơ sở cho các thí nghiệm.
Sử dụng các công cụ như Chaos Monkey để đưa ra các lỗi được kiểm soát, chẳng hạn như tắt máy chủ, gây ra độ trễ hoặc mô phỏng tình trạng mất mạng.
Quan sát phản ứng của hệ thống đối với các lỗi được đưa vào bằng các công cụ giám sát và bảng điều khiển.
So sánh tác động thực tế với giả thuyết để xác định sự khác biệt và các lĩnh vực cần cải thiện. Ghi lại các phát hiện và hiểu biết sâu sắc.
Dựa trên kết quả thí nghiệm, thực hiện các thay đổi để tăng cường khả năng phục hồi của hệ thống, chẳng hạn như cải thiện khả năng chịu lỗi, dự phòng và quy trình phục hồi.

28. Mô tả một tình huống mà bạn đã cải thiện độ tin cậy của một hệ thống.

Trong một dự án, chúng tôi nhận thấy tình trạng ngừng hoạt động thường xuyên do một điểm lỗi duy nhất trong database layer. Tôi đã triển khai thiết lập sao chép multi-master bằng hệ thống cơ sở dữ liệu phân tán để cải thiện độ tin cậy. Thiết lập này cho phép các thao tác đọc và ghi diễn ra trên nhiều node, loại bỏ điểm lỗi duy nhất.

Ngoài ra, tôi đã cấu hình tính năng chuyển đổi dự phòng tự động để đảm bảo lưu lượng truy cập sẽ chuyển đổi liền mạch sang các node hoạt động bình thường mà không ảnh hưởng đến người dùng trong trường hợp một node gặp sự cố. Tôi triển khai giám sát và cảnh báo để phát hiện sớm sự cố và phản hồi nhanh chóng. Nhờ đó, độ tin cậy của hệ thống được cải thiện đáng kể, giảm thời gian ngừng hoạt động và nâng cao sự hài lòng của người dùng.

29. Nêu một trường hợp bạn đã cải thiện hiệu suất hệ thống

Bằng cách phân tích các điểm nghẽn và áp dụng một số kỹ thuật lưu trữ đệm, tôi đã tối ưu hóa dịch vụ có độ trễ cao. Một lớp lưu trữ đệm phân tán đã được giới thiệu, các truy vấn cơ sở dữ liệu đã được tối ưu hóa.

Hai thay đổi này giúp giảm đáng kể thời gian phản hồi và cải thiện trải nghiệm người dùng tổng thể, từ đó tăng đáng kể sự hài lòng của khách hàng.

30. Tạo một phiên bản Twitter đơn giản trong đó người dùng có thể gửi tweet, theo dõi/bỏ theo dõi người dùng khác và xem 10 tweet gần đây nhất.

class Twitter {
    // Thuộc về từng người dùng và danh sách những người họ đang theo dõi
    private class User{
        int userID;
        HashMap<Integer, Boolean> followings;
        User(int id){
            userID = id;
            followings = new HashMap<>();
        }
    }
    
    // Mỗi tweet riêng lẻ, kèm thông tin người dùng đã đăng
    private class Tweet{
        int tweetID, userID;
        Tweet(int userID, int tweetID){
            this.tweetID = tweetID;
            this.userID = userID;
        }
    }
    
    // Danh sách chứa tất cả các tweet
    List<Tweet> tweets;
    
    // Map dùng để lấy thông tin người dùng trong thời gian O(1)
    HashMap<Integer, User> map;
    
    public Twitter() {
        map = new HashMap<>();
        tweets = new ArrayList<>();
    }
    
    public void postTweet(int userId, int tweetId) {
        // Nếu người dùng chưa tồn tại thì tạo mới
        if(!map.containsKey(userId))
            map.put(userId, new User(userId));
        
        // Thêm tweet vào danh sách của người dùng tương ứng
        tweets.add(new Tweet(userId, tweetId));
    }
    
    public List<Integer> getNewsFeed(int userId) {
        List<Integer> feeds = new ArrayList<>();
        int n = tweets.size()-1;
        int count = 0;
        
        // Vòng lặp trả về tối đa 10 tweet gần nhất từ chính người dùng
        // hoặc từ những người mà họ đang theo dõi
        
        while(n >= 0 && count < 10){
            int tweetID = tweets.get(n).tweetID;
            int userID = tweets.get(n).userID;
            
        // Kiểm tra xem người dùng hiện tại có theo dõi người đăng tweet hay không
            boolean exist = (map.get(userId)).followings.containsKey(userID);
            if(userId == userID || exist){
                feeds.add(tweetID);
                count++;
            }
            n--;
        }
        return feeds;
    }
    
    public void follow(int followerId, int followeeId) {
        
        // Nếu người theo dõi hoặc người được theo dõi chưa tồn tại
        // thì tạo mới và thêm vào danh sách theo dõi
        if(!map.containsKey(followerId))
            map.put(followerId, new User(followerId));
        
        if(!map.containsKey(followeeId))
            map.put(followeeId, new User(followeeId));
        
        (map.get(followerId)).followings.put(followeeId, true);
    }
    
    public void unfollow(int followerId, int followeeId) {
        // Nếu người theo dõi hoặc người được theo dõi chưa tồn tại
        // thì xóa khỏi danh sách theo dõi (nếu có)
        if(!map.containsKey(followerId))
            map.put(followerId, new User(followerId));
        
        if(!map.containsKey(followeeId))
            map.put(followeeId, new User(followeeId));
        
        (map.get(followerId)).followings.remove(followeeId);
    }
}

Độ phức tạp thời gian cho giải pháp sẽ là O(10), một hằng số . Lý do là vì chỉ có tối đa 10 tweet được trả về cho người dùng.

31. Viết một REST API đơn giản trong Node.js để trả về danh sách người dùng.

Để tạo một REST API đơn giản trong Node.js trả về danh sách người dùng, tôi sử dụng Express để thiết lập máy chủ và xác định tuyến xử lý các yêu cầu GET.

Sau đây là ví dụ cơ bản:

const express = require('express'); const app = express(); const users = [{ id: 1, name: 'John Doe' }, { id: 2, name: 'Jane Doe' }]; app.get('/users', (req, res) => { res.json(users); }); app.listen(3000, () => { console.log('Server is running on port 3000'); });

32. Viết một tập lệnh Bash để sao lưu một thư mục vào máy chủ từ xa.

Để sao lưu một thư mục vào máy chủ từ xa, bạn có thể sử dụng tập lệnh Bash để rsynctruyền tệp hiệu quả. Sau đây là một ví dụ đơn giản:

rsync -avz /local/directory user@remote:/remote/directory.

Câu hỏi phỏng vấn kỹ sư SRE cấp cao

33. Bạn ưu tiên các sự cố như thế nào trong môi trường sản xuất?

Tôi ưu tiên các sự cố dựa trên tác động của chúng đối với người dùng và hoạt động kinh doanh, đảm bảo các vấn đề quan trọng được giải quyết trước.

Bằng cách sử dụng các tiêu chí và SLA được xác định trước, tôi có thể phân loại và quản lý sự cố một cách hiệu quả, đồng thời cập nhật thông tin cho các bên liên quan trong suốt quá trình.

34. Làm thế nào để đảm bảo tính khả dụng và độ tin cậy cao của các dịch vụ trong hệ thống phân tán?

Trong vai trò trước đây, tôi đã đảm bảo tính khả dụng cao bằng cách triển khai đa vùng với tính năng chuyển đổi dự phòng tự động. Chúng tôi sử dụng bộ cân bằng tải để phân phối lưu lượng đồng đều và giám sát hệ thống bằng các công cụ như Prometheus và Grafana. Khi xảy ra sự cố, tôi đã tự động hóa các cảnh báo và runbook để phản hồi nhanh chóng, giúp giảm thiểu thời gian ngừng hoạt động.

35. Bạn cho rằng số liệu nào là quan trọng nhất để theo dõi tình trạng của hệ thống và tại sao?

Tôi ưu tiên nhóm chỉ số mà Google gọi là bốn tín hiệu vàng: độ trễ, lưu lượng, lỗi và độ bão hòa.

Độ trễ ảnh hưởng đến trải nghiệm người dùng, vì vậy việc giữ độ trễ ở mức thấp là rất quan trọng.
Tỷ lệ lỗi giúp xác định các vấn đề mới phát sinh
Độ bão hòa cho biết chúng ta đang ở gần giới hạn công suất đến mức nào.

Bằng cách theo dõi những chỉ số này, tôi có thể chủ động giải quyết các vấn đề tiềm ẩn trước khi chúng ảnh hưởng đến người dùng.

36. Làm thế nào để cân bằng giữa sự đổi mới và độ tin cậy trong môi trường làm việc có nhịp độ nhanh?

Tôi áp dụng nguyên tắc cân bằng theo ngân sách lỗi (Error Budget): Nếu hệ thống vẫn nằm trong giới hạn SLO cho phép, nhóm có thể triển khai tính năng mới, thử nghiệm hoặc tinh chỉnh hiệu năng. Khi vượt ngưỡng, toàn bộ ưu tiên chuyển sang ổn định hóa và cải thiện độ tin cậy.

Tôi cũng sử dụng các kỹ thuật triển khai an toàn như canary release, feature flag và CI/CD có rollback tự động.

37. Làm thế nào để cân bằng giữa công việc chủ động như cải thiện độ tin cậy của hệ thống, với công việc bị động như giải quyết vấn đề sản xuất?

Tôi thường áp dụng nguyên tắc 50/50:

50% thời gian cho công việc chủ động như tối ưu hiệu năng, tăng độ tin cậy, kiểm thử hỗn loạn;
50% cho công việc phản ứng như xử lý sự cố và giám sát.

Sự cân bằng này cho phép tôi tập trung vào các dự án độ tin cậy dài hạn trong khi vẫn phản ứng nhanh với các vấn đề sản xuất tức thời. Tôi cũng thiết lập cơ chế luân phiên trực on-call công bằng, để không ai bị quá tải và mọi người đều hiểu rõ hệ thống ở mức vận hành thực tế.

38. Bạn triển khai và quản lý triển khai Blue-Green như thế nào?

Blue-Green là một chiến lược phát hành phiên bản ứng dụng mới với thời gian ngừng hoạt động và rủi ro tối thiểu. Các bước triển khai chính bao gồm:

Thiết lập môi trường: Tạo hai môi trường riêng biệt, blue cho phiên bản hiện tại và green cho phiên bản mới. Cả hai môi trường phải giống hệt nhau về cấu hình và cơ sở hạ tầng.
Triển khai lên môi trường Green: Triển khai phiên bản ứng dụng mới lên môi trường Green trong khi môi trường Blue phục vụ lưu lượng sản xuất. Kiểm tra kỹ lưỡng phiên bản mới nhất trong môi trường Green.
Chuyển đổi lưu lượng: Sau khi phiên bản mới trong môi trường Green được xác thực và sẵn sàng, tiếp tục chuyển đổi lưu lượng từ môi trường Blue sang môi trường Green. Việc này có thể được thực hiện bằng cách sử dụng bộ cân bằng tải hoặc thay đổi DNS.
Giám sát và xác thực: Giám sát chặt chẽ môi trường Green sau khi chuyển đổi lưu lượng để đảm bảo phiên bản mới hoạt động như mong đợi. Xác thực hiệu suất, tính ổn định và trải nghiệm người dùng.
Kế hoạch khôi phục: Chuẩn bị kế hoạch khôi phục trong trường hợp phát sinh sự cố với phiên bản mới. Nếu xảy ra sự cố, hãy khôi phục lưu lượng truy cập về môi trường Blue để giảm thiểu gián đoạn.

39. Bạn xử lý các sự cố quy mô lớn liên quan đến nhiều nhóm như thế nào?

Việc xử lý các sự cố quy mô lớn liên quan đến nhiều đội ngũ đòi hỏi một phương pháp tiếp cận phối hợp và có cấu trúc. Dưới đây là cách tôi xử lý:

Thiết lập hệ thống chỉ huy sự cố để quản lý và điều phối các nỗ lực ứng phó. Phân công các vai trò như Chỉ huy, Trưởng nhóm Vận hành và Trưởng nhóm Truyền thông để đảm bảo trách nhiệm rõ ràng.
Thiết lập một kênh truyền thông tập trung để cập nhật và phối hợp theo thời gian thực. Thường xuyên cập nhật cho tất cả các bên liên quan, bao gồm cả đội ngũ điều hành, về tình trạng và tiến độ của sự cố.
Nhanh chóng đánh giá tác động của sự cố và ưu tiên hành động dựa trên mức độ nghiêm trọng. Tập trung khôi phục các dịch vụ quan trọng trước tiên trong khi điều tra nguyên nhân gốc rễ.
Thúc đẩy sự hợp tác giữa các nhóm bằng cách tổ chức các cuộc họp cập nhật tình hình thường xuyên và sử dụng các công cụ cộng tác.
Ghi chép chi tiết các hành động, quyết định và phát hiện trong suốt sự cố. Điều này rất quan trọng cho việc phân tích và rút kinh nghiệm sau sự cố.
Triển khai các bản sửa lỗi và giải pháp thay thế để giảm thiểu sự cố. Sau khi giải quyết, đảm bảo tất cả hệ thống được khôi phục hoàn toàn và hoạt động bình thường.
Phân tích hậu sự cố kỹ lưỡng để xác định nguyên nhân gốc rễ, các yếu tố góp phần và các lĩnh vực cần cải thiện. Ghi lại bài học kinh nghiệm và thực hiện các biện pháp phòng ngừa để tránh các sự cố trong tương lai.

40. Mô tả quy trình của bạn cho việc lập kế hoạch năng lực (capacity planning) và kiểm thử hiệu năng (performance testing) là gì khi mô hình lưu lượng chưa biết hoặc thay đổi liên tục?

(Khi trả lời, bạn nên mô tả cách bạn dự báo nhẹ (lightweight forecasting), kiểm thử tải (load testing), và điều chỉnh năng lực theo thời gian thực)

Ví dụ trả lời:

Tôi kết hợp giữa ước lượng từ dưới lên (bottom-up), ví dụ tính toán số QPS (queries per second) dự kiến cho từng tính năng, với kịch bản từ trên xuống (top-down) để mô phỏng các tình huống tải thực tế.

Sau đó, tôi xác thực giả thuyết bằng load test mô phỏng hành vi người dùng thực. Tôi thiết kế hệ thống có khả năng mở rộng linh hoạt (elasticity), với autoscaling dựa trên CPU, RPS và độ sâu hàng đợi (queue depth), đồng thời đặt giới hạn chi phí (cost guardrails).

Tôi theo dõi các chỉ số như p95/p99 latency và saturation, sau đó hiệu chỉnh hàng tháng dựa trên dữ liệu lưu lượng thực tế. Cách này giúp giảm rủi ro trước những biến động bất ngờ mà không cần đầu tư thừa tài nguyên.

41. Mô tả một sự cố mà bạn phải xử lý lỗi liên hoàn.

Trong một vai trò trước đây, tôi đã gặp phải sự cố sập hệ thống trên nền tảng thương mại điện tử do sự cố với dịch vụ xử lý thanh toán. Sự cố bắt đầu khi khối lượng giao dịch lớn dẫn đến quá tải dịch vụ thanh toán, khiến hệ thống không phản hồi. Sự cố ảnh hưởng đến các dịch vụ phụ thuộc như xử lý đơn hàng và quản lý hàng tồn kho. Kết quả là khách hàng gặp sự cố khi đặt hàng và dữ liệu hàng tồn kho thiếu nhất quán.

Để giải quyết tình huống này tôi đã:

Nhanh chóng xác định nguyên nhân gốc rễ nằm ở dịch vụ thanh toán và tiến hành khôi phục về phiên bản ổn định trước đó, đồng thời triển khai giới hạn tốc độ để ngăn chặn tình trạng quá tải dịch vụ.
Phối hợp với nhiều nhóm để đánh giá tác động, trao đổi với các bên liên quan và quản lý kỳ vọng của khách hàng. Chúng tôi đã thiết lập một kênh liên lạc tập trung để chia sẻ thông tin cập nhật và tiến độ.
Sau khi giải quyết vấn đề trước mắt, tôi tiến hành phân tích nguyên nhân gốc rễ kỹ lưỡng để hiểu rõ các yếu tố góp phần gây ra sự cố lan tỏa. Chúng tôi đã xác định được các vấn đề nghiêm trọng là kiểm tra tải không đầy đủ và cô lập lỗi.
Chúng tôi đã triển khai các cải tiến như tăng cường kiểm tra tải, chiến lược cô lập lỗi tốt hơn và cải thiện giám sát để phát hiện sớm sự cố.

Tips chuẩn bị cho buổi phỏng vấn kỹ sư SRE

Chuẩn bị cho buổi phỏng vấn SRE không chỉ là ôn lại kiến thức kỹ thuật. Nhà tuyển dụng muốn thấy ở bạn tư duy hệ thống, kỹ năng xử lý sự cố, khả năng làm việc giữa hai thế giới Dev và Ops, và trên hết là sự cân bằng giữa độ tin cậy và tốc độ đổi mới.

Dưới đây là những gợi ý thực tế giúp bạn chuẩn bị tốt hơn:

Hiểu rõ cơ sở hạ tầng và công nghệ của công ty

Nghiên cứu hệ thống công nghệ, cơ sở hạ tầng của công ty và những thách thức mà họ phải đối mặt về độ tin cậy và khả năng mở rộng. Điều này giúp bạn điều chỉnh phản hồi của mình cho phù hợp với bối cảnh cụ thể.

Ôn lại các nguyên tắc và thực hành SRE

Đảm bảo bạn nắm vững các nguyên tắc cốt lõi của kỹ thuật đảm bảo độ tin cậy của trang web, bao gồm các chỉ số SLI, SLO và error budgets.

Đọc chi tiết: SRE là gì: Nguyên tắc, công cụ và số liệu quan trọng cần biết

Luyện tập kịch bản xử lý sự cố

Hãy chuẩn bị nói về một hoặc hai sự cố thực tế bạn từng xử lý:

Sự cố là gì?
Bạn phát hiện và phản ứng thế nào?
Cách bạn khôi phục và rút kinh nghiệm ra sao?

Ôn tập lập trình và thiết kế hệ thống

Bạn có thể được yêu cầu viết mã hoặc thiết kế hệ thống trong buổi phỏng vấn. Hãy ôn lại kiến thức về các ngôn ngữ lập trình liên quan đến vị trí ứng tuyển và sẵn sàng thảo luận về các nguyên tắc thiết kế hệ thống.

Chuẩn bị câu hỏi hành vi

Vai trò SRE đòi hỏi khả năng giao tiếp, phối hợp và làm việc nhóm. Hãy nghĩ trước vài ví dụ thực tế thể hiện bạn:

Xử lý áp lực khi on-call.
Hợp tác với team dev để fix sự cố.
Giao tiếp rõ ràng khi có outage.

Đặt câu hỏi ngược về thực hành SRE của doanh nghiệp

Thể hiện sự quan tâm đến những thách thức và thực hành SRE cụ thể bằng cách đặt những câu hỏi sâu sắc. Những câu hỏi này thể hiện bạn tư duy như một người làm SRE thực thụ. Điều này cũng giúp bạn hiểu liệu văn hóa và thực hành của công ty có phù hợp với mục tiêu nghề nghiệp của bạn hay không.

Thực hiện phỏng vấn thử (mock interview)

Thực hành với đồng nghiệp hoặc cố vấn, đặc biệt là các câu hỏi về thiết kế hệ thống và xử lý sự cố. Điều này giúp bạn diễn đạt quá trình tư duy và kiến thức kỹ thuật rõ ràng hơn.

Đọc thêm: SRE Roadmap: Lộ trình toàn diện trở thành kỹ sư SRE

Tổng kết

Với hơn 40 câu hỏi phỏng vấn kỹ sư SRE được phân loại theo từng cấp độ ở trên, bạn đã có trong tay một bộ “đề cương chiến lược” để tự tin bước vào buổi phỏng vấn. Điều quan trọng không chỉ là ghi nhớ câu trả lời mẫu, mà là hiểu sâu các nguyên tắc cốt lõi của nghề SRE: độ tin cậy (reliability), tự động hóa (automation), giám sát (monitoring) và xử lý sự cố (incident response). Khi bạn nắm vững những khái niệm này và có thể liên hệ với kinh nghiệm thực tế, bạn sẽ không chỉ trả lời trôi chảy mà còn thể hiện được tư duy của một kỹ sư SRE thực thụ.