PVcomBank tuyển dụng Chuyên viên Cao cấp Dịch vụ giám sát 24/7 (giờ...

Nhân viên chính thức Lương thỏa thuận Hạn: 2026-11-30

Mô tả công việc

Nhiệm vụ chính

Nhận phân công công việc của lãnh đạo có thẩm quyền, lập kế hoạch công việc chi tiết và báo cáo tiến độ, kết quả công việc cho lãnh đạo;

Tham gia các hoạt động đào tạo, hướng dẫn, trao đổi kiến thức, sinh hoạt chuyên môn và các hoạt động sinh hoạt chung khác trong Khối.

Nhiệm vụ chuyên môn

Chủ trì xây dựng, vận hành và tối ưu các nền tảng Monitoring/Observability; đảm bảo khả năng giám sát toàn diện hạ tầng, mạng, cơ sở dữ liệu, ứng dụng, API và dịch vụ số.

Thiết kế, tích hợp và quản lý dữ liệu giám sát (Metrics, Logs, Traces, Events); xây dựng Dashboard, Catalog chỉ số và cơ chế đo lường SLI/SLO/SLA phục vụ quản trị dịch vụ.

Xây dựng, chuẩn hóa và cải tiến quy trình giám sát, cảnh báo; tối ưu ngưỡng cảnh báo, giảm cảnh báo giả và nâng cao khả năng phát hiện, khoanh vùng sự cố.

Phát triển, tích hợp và tự động hóa các hoạt động giám sát, cảnh báo, tạo ticket, thông báo, báo cáo và hỗ trợ xử lý sự cố thông qua Script, API, Workflow và Runbook.

Tham gia đánh giá, lựa chọn, triển khai, nâng cấp và quản lý vòng đời các công cụ giám sát; xây dựng, cập nhật tài liệu kỹ thuật và quy trình vận hành.

Hỗ trợ xử lý sự cố; thu thập và phân tích dữ liệu, xây dựng timeline, thực hiện hoặc tham gia RCA;

Theo dõi, đôn đốc các hành động khắc phục, phòng ngừa và phối hợp với các đơn vị liên quan đến khi sự cố được xử lý hoàn tất.

Thực hiện các nhiệm vụ khác theo phân công của lãnh đạo Phòng và lãnh đạo Trung tâm.

Yêu cầu ứng viên

Bằng cấp: Tốt nghiệp Cao đẳng trở lên các chuyên ngành thuộc lĩnh vực Công nghệ thông tin, Điện tử viễn thông, Toán tin, hoặc tốt nghiệp Đại học trở lên các chuyên ngành về tài chính ngân hàng;

Kiến thức chuyên môn:

Tối thiểu 03 năm kinh nghiệm trong lĩnh vực vận hành CNTT, giám sát hệ thống, SRE hoặc quản trị nền tảng; ưu tiên có kinh nghiệm triển khai, vận hành các nền tảng Monitoring/Observability trong môi trường 24/7.

Hiểu biết về Observability, Metrics, Logs, Traces, SLI/SLO, Error Budget và các chỉ số đo lường độ tin cậy dịch vụ.

Có kinh nghiệm với một hoặc nhiều công cụ giám sát như Grafana, Prometheus, ELK/OpenSearch, Zabbix, Dynatrace, Splunk, Datadog hoặc các giải pháp tương đương.

Có khả năng xây dựng Dashboard, Alert Rule, truy vấn và phân tích dữ liệu giám sát; hiểu biết về hệ điều hành, mạng, cơ sở dữ liệu, middleware, container, cloud và kiến trúc ứng dụng.

Có kỹ năng scripting, tích hợp tự động hóa và hiểu biết về các quy trình Event, Incident, Problem, Change Management theo ITSM/ITIL.

Kỹ năng, phẩm chất:

Tư duy hệ thống, khả năng phân tích và giải quyết sự cố; chủ động, trách nhiệm và tinh thần cải tiến liên tục.

Có kỹ năng lập kế hoạch, điều phối công việc, phối hợp đa đơn vị và thúc đẩy thực hiện mục tiêu chung.

Có khả năng giao tiếp, trình bày, xây dựng tài liệu và đào tạo nghiệp vụ.

Có khả năng đọc hiểu tài liệu kỹ thuật bằng tiếng Anh; sẵn sàng tham gia hỗ trợ xử lý sự cố ngoài giờ khi cần thiết.

Phân tích kỹ năng cần có

1. Phân tích tổng thể vị trí

Vị trí Chuyên viên Cao cấp Dịch vụ giám sát 24/7 – Khối CNTT tại PVcomBank không chỉ là theo dõi cảnh báo trên dashboard. Yêu cầu trọng tâm là xây dựng và vận hành nền tảng Monitoring/Observability, chuẩn hóa tín hiệu giám sát, xây dựng cơ chế đo lường độ tin cậy dịch vụ, tự động hóa cảnh báo và phối hợp xử lý sự cố theo quy trình ITSM.

Điểm cần làm rõ trong phỏng vấn là cụm “dịch vụ giám sát 24/7” nhưng vị trí được ghi là “giờ hành chính”. Ứng viên nên hỏi cụ thể về ca trực, tần suất hỗ trợ ngoài giờ, cơ chế bật người trực và chính sách bù đắp cho công việc ngoài giờ.

2. Yêu cầu bắt buộc cần đáp ứng

Bằng cấp Cao đẳng trở lên thuộc lĩnh vực Công nghệ thông tin, Điện tử viễn thông, Toán tin; hoặc Đại học trở lên thuộc lĩnh vực tài chính – ngân hàng.
Tối thiểu 03 năm kinh nghiệm trong vận hành CNTT, giám sát hệ thống, SRE hoặc quản trị nền tảng.
Ưu tiên kinh nghiệm vận hành nền tảng Monitoring/Observability trong môi trường cần hỗ trợ liên tục.
Hiểu Metrics, Logs, Traces, Events, SLI, SLO, SLA và Error Budget.
Có kinh nghiệm thực tế với ít nhất một trong các công cụ: Grafana, Prometheus, ELK/OpenSearch, Zabbix, Dynatrace, Splunk, Datadog hoặc công cụ tương đương.
Có khả năng đọc tài liệu kỹ thuật tiếng Anh và sẵn sàng hỗ trợ xử lý sự cố ngoài giờ khi cần thiết.
Chứng chỉ không được yêu cầu rõ ràng trong tin tuyển dụng, vì vậy chứng chỉ chỉ là lợi thế hỗ trợ, không thay thế kinh nghiệm thực tế.

3. Phân tích kỹ năng chuyên môn

Nhóm kỹ năng	Yêu cầu trọng tâm	Kiến thức và năng lực nên có
Monitoring và Observability	Quản lý toàn bộ vòng đời nền tảng giám sát	Xây dựng nguồn dữ liệu, thu thập Metrics, Logs, Traces, Events; thiết kế Dashboard, Alert Rule, Recording Rule; quản lý quyền truy cập, dữ liệu nhạy cảm và vòng đời công cụ
Độ tin cậy dịch vụ	Quản trị dịch vụ theo mục tiêu	Phân biệt SLI, SLO, SLA; tính Error Budget; xác định chỉ số phản ánh tính khả dụng, độ trễ, tỷ lệ lỗi và tính đúng đắn của dữ liệu
Công cụ giám sát	Sử dụng thành thạo ít nhất một stack	Grafana, Prometheus, ELK/OpenSearch, Zabbix, Dynatrace, Splunk, Datadog; hiểu truy vấn, cảnh báo, dashboard, tích hợp dữ liệu và phân tích chéo
Hạ tầng và kiến trúc	Nắm đủ kiến trúc để khoanh vùng sự cố	Hệ điều hành Linux/Windows, mạng, DNS, TCP/IP, HTTP/TLS, cơ sở dữ liệu, middleware, API, container, cloud và kiến trúc ứng dụng
Tự động hóa	Giảm thao tác thủ công và rút ngắn thời gian xử lý	Python, Bash hoặc PowerShell; REST API, Webhook, Workflow; tự động tạo ticket, thông báo, báo cáo và cập nhật trạng thái sự cố
ITSM và Incident Management	Quản lý sự cố theo quy trình chuẩn	Phân biệt Event, Incident, Problem và Change; xây dựng timeline; điều phối xử lý; thực hiện Root Cause Analysis và theo dõi hành động khắc phục
Dữ liệu và phân tích	Biến dữ liệu giám sát thành thông tin ra quyết định	Phân tích xu hướng, tương quan, tỷ lệ cảnh báo giả, độ trễ, thời gian phát hiện và khắc phục; sử dụng SQL và ngôn ngữ truy vấn phù hợp
Tài liệu và trao đổi	Làm việc trong môi trường doanh nghiệp	Viết Runbook, tài liệu kiến trúc, quy trình vận hành và báo cáo sự cố; trình bày rõ ràng đến cả kỹ thuật lẫn lãnh đạo

3.1. Kiến thức Observability cần nắm vững

Ứng viên cần phân biệt rõ:

Monitoring: giám sát những thông tin đã biết trước cần theo dõi, ví dụ CPU, dung lượng đĩa, tỷ lệ lỗi giao dịch.
Observability: khả năng hiểu trạng thái bên trong của hệ thống thông qua các tín hiệu do hệ thống phát ra, đặc biệt khi sự cố chưa từng xảy ra và chưa có cảnh báo được viết trước.
Metrics: số đo tổng hợp, phù hợp để theo dõi xu hướng và kích hoạt cảnh báo.
Logs: bản ghi sự kiện chi tiết, phù hợp để truy vết và phân tích nguyên nhân.
Traces: đường đi của một yêu cầu qua nhiều dịch vụ, giúp xác định điểm nghẽn hoặc lỗi trong luồng phân tán.
Events: sự kiện có ý nghĩa về vận hành hoặc nghiệp vụ, chẳng hạn thay đổi cấu hình, triển khai phiên bản hoặc phát sinh giao dịch bất thường.

Một lộ trình học hợp lý là chọn một stack cốt lõi, chẳng hạn Grafana + Prometheus + OpenSearch/ELK, hiểu sâu stack đó rồi mở rộng sang Zabbix hoặc nền tảng thương mại. Ứng viên không cần biết sâu toàn bộ danh sách công cụ, nhưng phải giải thích được lựa chọn, giới hạn và cách tích hợp giữa các công cụ.

3.2. Kiến thức SRE và quản trị dịch vụ

Cần hiểu và trả lời được các khái niệm sau:

SLI: chỉ số đo lường một thuộc tính của dịch vụ, ví dụ tỷ lệ yêu cầu thành công hoặc độ trễ trung vị.
SLO: mục tiêu nội bộ về độ tin cậy của dịn vụ trong một khoảng thời gian, ví dụ 99,9% yêu cầu thành công trong 30 ngày.
SLA: cam kết với khách hàng hoặc bên liên quan; thường có hậu quả tài chính khi không đạt.
Error Budget: phần sai số cho phép dựa trên SLO, thường được tính bằng `1 – SLO`.
MTTD: thời gian trung bình phát hiện sự cố.
MTTA: thời gian trung bình tiếp nhận và bắt đầu xử lý.
MTTR: thời gian trung bình khôi phục dịch vụ.
Postmortem: bài học sau sự cố, tập trung vào nguyên nhân gốc và hành động phòng ngừa thay vì đổ lỗi cá nhân.

Có thể lấy ví dụ: với SLO khả dụng 99,9% trong tháng 30 ngày, thời gian gián đoạn được phép xấp xỉ 43,8 phút. Cần nói rõ cách tính thực tế có thể khác tùy chính sách của từng đơn vị.

3.3. Kỹ năng truy vấn và xây dựng cảnh báo

Nên có khả năng:

Viết PromQL cơ bản như `up`, `rate(http_requests_total[5m])` và tính phân vị độ trễ bằng histogram.
Truy vấn log theo thời gian, mức độ lỗi, mã giao dịch, dịch vụ hoặc người dùng trong OpenSearch/Elasticsearch.
Phân biệt cảnh báo theo triệu chứng với cảnh báo theo nguyên nhân.
Thiết kế cảnh báo dựa trên tần suất, mức độ nghiêm trọng, khả năng tự khắc phục và giá trị kinh doanh.
Giảm cảnh báo giả bằng cách tinh chỉnh ngưỡng, dùng điều kiện kép, nhóm theo dịch vụ và áp dụng thời gian chờ phù hợp.
Kiểm soát cardinality để tránh làm tăng chi phí lưu trữ và làm chậm hệ thống giám sát.
Xây dựng dashboard theo nhiều lớp: tổng quan dịch vụ, hạ tầng, ứng dụng, phụ thuộc và tác động nghiệp vụ.

3.4. Tự động hóa và tích hợp ITSM

Ứng viên nên biết cách mô tả một quy trình tự động hóa hoàn chỉnh, chẳng hạn:

1. Prometheus hoặc công cụ giám sát phát hiện dịch vụ không đạt SLO.
2. Alert Rule gửi cảnh báo đến hệ thống trung gian.
3. Script hoặc Workflow kiểm tra xem sự cố đã tồn tại chưa.
4. Hệ thống tự tạo ticket, gán nhóm phụ trách và thông báo qua đúng kênh.
5. Trạng thái ticket được đồng bộ với hệ thống giám sát.
6. Khi sự cố được khắc phục, hệ thống ghi nhận thời gian, cập báo cáo và các hành động còn dang dở.

Đây là ví dụ rất tốt để chứng minh khả năng hiểu mối liên hệ giữa Observability, Incident Management, Automation và Change Management.

3.5. Kiến thức bảo mật cần lưu ý

Ngân hàng có yêu cầu bảo mật cao hơn môi trường công nghệ thông thông thường. Ứng viên nên chuẩn bị kiến thức về:

Phân quyền truy cập dashboard, dữ liệu log và API giám sát.
Quản lý bí mật bằng biến môi trường hoặc kho bí mật, không đưa mật khẩu vào mã nguồn.
Mã hóa kết nối, chứng thư số và xác thực máy chủ.
Che dữ liệu nhạy cảm, dữ liệu khách hàng và dữ liệu giao dịch trong log.
Quy trình thay đổi, phê duyệt, kiểm thử và hoàn tác khi nâng cấp nền tảng giám sát.

4. Kỹ năng mềm và phẩm chất cần thể hiện

Kỹ năng mềm	Biểu hiện mong muốn
Tư duy hệ thống	Nhìn được mối liên hệ giữa hạ tầng, ứng dụng, dữ liệu, cảnh báo và tác động nghiệp vụ
Phân tích sự cố	Giữ được sự bình tĩnh, đặt giả thuyết có thứ tự, thu thập bằng chứng và cập nhật timeline
Chủ động và trách nhiệm	Không chỉ phát hiện cảnh báo mà còn đề xuất nguyên nhân, hành động và hướng sửa lâu dài
Lập kế hoạch	Sắp xếp ưu tiên theo mức độ ảnh hưởng, thời gian phục hồi và rủi ro vận hành
Phối hợp đa đơn vị	Trao đổi rõ với lãnh đạo, nhà phát triển, mạng, cơ sở dữ liệu, bảo mật và bộ phận nghiệp vụ
Giao tiếp và trình bày	Chuyển dữ liệu phức tạp thành thông tin dễ hiểu cho cả đối tượng kỹ thuật và không kỹ thuật
Viết tài liệu	Tạo Runbook rõ ràng, có điều kiện kích hoạt, bước xử lý, lệnh tham khảo và phương án hoàn tác
Tinh thần cải tiến	Liên tục đánh giá chất lượng cảnh báo, độ bao phủ giám sát, thời gian xử lý và mức độ tự động hóa

5. Chứng chỉ gợi ý theo mức độ ưu tiên

Chứng chỉ	Khi nào nên học	Giá trị thực tế
ITIL 4 Foundation	Ưu tiên cao nếu ít kinh nghiệm ITSM	Hỗ trợ hiểu Incident, Problem, Change và vai trò của Service Management
Prometheus Certified	Phù hợp về mặt kỹ thuật cho stack Prometheus	Chứng minh kiến thức về metric, PromQL, recording rule, alert và exemplar
Grafana Associate hoặc chứng chỉ liên quan của Grafana Labs	Sau khi đã hiểu Prometheus	Hỗ trợ dashboard, datasource, biến, cảnh báo và plugin
Certified Kubernetes Administrator	Khi vị trí có yêu cầu quản trị container	Chứng minh khả năng xử lý pod, service, deployment và sự cố cluster
AWS Solutions Architect Associate hoặc Microsoft Azure Administrator AZ-104	Khi môi trường sử dụng cloud tương ứng	Hỗ trợ kiến trúc cloud, định danh, giám sát và quyền truy cập
Chứng chỉ Linux hoặc nền tảng quản trị hệ điều hành	Khi cần cải thiện kỹ năng vận hành	Hỗ trợ đọc log, dịch vụ, tài nguyên và xử lý sự cố máy chủ
Splunk hoặc Elastic Observability	Nếu doanh nghiệp ưu tiên stack tương ứng	Tăng lợi thế khi phỏng vấn về log search, dashboard và correlation
CompTIA Security+ hoặc tương đương	Khi muốn chứng minh tư duy bảo mật	Hữu ích cho phân quyền, bí mật, audit và bảo vệ dữ liệu giám sát

Không nên học quá nhiều chứng chỉ cùng lúc. Lựa chọn tối đa hai chứng chỉ có liên quan trực tiếp đến stack và mục tiêu nghề nghiệp, đồng thời thể hiện bằng một dự án thực tế.

6. Cách thể hiện năng lực trong hồ sơ

Hồ sơ nên có các thành phần sau:

Mô tả rõ stack giám sát đã sử dụng, quy mô giám sát và phạm vi hạ tầng, ứng dụng.
Nêu số lượng hoặc quy mô tính cờ như số dịch vụ, số dashboard, số cảnh báo, số host, số API hoặc số ticket.
Trình bày kết quả đo được như thời gian phát hiện, thời gian xử lý, tỷ lệ cảnh báo giả, độ bao phủ tín hiệu hoặc số giờ tiết kiệm.
Mô tả một sự cố đáng nhớ theo cấu trúc tình huống, nhiệm vụ, hành động, kết quả và bài học.
Trình bày workflow tự động tạo ticket hoặc thông báo, kèm sơ đồ luồng hoặc đường dẫn tài liệu portfolio.
Nêu kinh nghiệm làm việc với ITSM, Change Management, quy trình phê duyệt và lịch sử thay đổi.
Liệt kê chứng chỉ, khóa học và portfolio kỹ thuật có liên quan.

Một ví dụ mạnh: “Xây dựng quy trình tự động tạo ticket khi cảnh báo độ trễ API vượt ngưỡng trong 10 phút, giúp thời gian tiếp nhận sự cố giảm từ 12 phút xuống 4 phút.” Cách diễn đạt này thể hiện rõ công cụ, quy trình, vấn đề và kết quả.

Chuẩn bị phỏng vấn

1. Quy trình phỏng vấn dự kiến

Tin tuyển dụng chưa công bố quy trình chính thức. Với vị trí kỹ thuật cấp cao, quy trình thường có thể gồm các bước sau, nhưng ứng viên cần xác nhận lại với người tuyển dụng:

1. Sàng lọc hồ sơ: xác nhận kinh nghiệm, bằng cấp, mức lương mong muốn và khả năng làm việc theo lịch hỗ trợ sự cố.
2. Phỏng vấn nhân sự: đánh giá động lực, mức lương, địa điểm, quyền lợi và khả năng làm việc theo lịch hỗ trợ sự cố.
3. Phỏng vấn chuyên môn: kiểm tra Observability, SRE, công cụ giám sát, hạ tầng, tự động hóa và ITSM.
4. Bài kiểm tra hoặc tình huống thực tế: thiết kế giải pháp giám sát, phân tích cảnh báo, xử lý sự cố hoặc xây dựng câu trả lời phản hồi tình huống.
5. Phỏng vấn lãnh đạo: đánh giá tư duy hệ thống, khả năng lập kế hoạch, phối hợp, lãnh đạo và mức độ phù hợp với vị trí cao cấp.
6. Phỏng vấn tổng kết: thống nhất mức lương, thời gian bắt đầu, chính sách đào tạo và các điều khoản liên quan.

2. Chuẩn bị cho từng vòng

Vòng	Trọng tâm đánh giá	Cách chuẩn bị
Sàng lọc	Đúng yêu cầu bằng cấp, 03 năm kinh nghiệm và khả năng hỗ trợ sự cố	Chuẩn hóa CV theo từng nền tảng đã vận hành, chuẩn bị mô tả ngắn về vai trò và lý do chuyển sang Observability
Nhân sự	Lương, lợi ích, lịch làm việc, tính cách và mức độ sẵn sàng	Chuẩn bị mức lương kỳ vọng có căn cứ, câu hỏi về lịch hỗ trợ ngoài giờ và câu trả lời về động lực
Chuyên môn	Kiến thức, khả năng thiết kế và sử dụng công cụ thực tế	Ôn PromQL, Grafana, OpenSearch/ELK, SLO, RCA, ITSM; chuẩn bị sơ đồ kiến trúc và ví dụ sự cố
Bài kiểm tra	Tốc độ phân tích, tính cấu trúc, khả năng tự động hóa và giao tiếp	Luyện giải bài trong 60 phút, trả lời theo cấu trúc yêu cầu – thiết kế – phân tích – giải pháp – rủi ro
Lãnh đạo	Tư duy hệ thống, ưu tiên, phối hợp, khả năng dẫn dắt vấn đề	Chuẩn bị câu trả lời về quyết định khó, xử lý sự cố, ảnh hưởng nghiệp vụ và phát triển năng lực đội ngũ
Tổng kết	Mức độ khớp và khả năng thành công lâu dài	Tổng hợp điểm mạnh, điểm cần cải thiện, thông điệp nghề nghiệp và kế hoạch 90 ngày đầu

3. Câu hỏi chuyên môn thường gặp và gợi ý trả lời

3.1. Phân biệt Monitoring và Observability

Nên trả lời rằng Monitoring tập trung vào những điều kiện đã biết trước và dựa trên cảnh báo có ngưỡng, còn Observability cung cấp khả năng hiểu trạng thái bên trong hệ thống thông qua nhiều loại tín hiệu để điều tra các lỗi chưa từng được mô hình hóa. Trong ngân hàng, mục tiêu cuối cùng không chỉ là phát hiện sự cố mà còn là định vị nhanh, hiểu tác động và giảm thời gian khôi phục.

3.2. SLI, SLO và SLA khác nhau thế nào?

SLI là phép đo thực tế.
SLO là mục tiêu nội bộ dựa trên SLI.
SLA là cam kết với bên ngoài và thường có hậu quả tài chính.
Cần chỉ ra cách tính cửa sổ thời gian, cách loại trừ lỗi và nguồn dữ liệu chính.

3.3. Error Budget dùng để làm gì?

Error Budget thể hiện sai số cho phép trước khi vi phạm SLO. Nó giúp cân bằng giữa tốc độ phát triển và độ ổn định, đồng thời là căn cứ để quyết định tạm dừng thay đổi rủi ro, tăng cường kiểm thử hoặc cho phép phát hành tính năng mới.

3.4. Làm thế nào để giảm cảnh báo giả?

Nên trình bày theo chuỗi: rà soát cảnh báo theo tần suất và mức ảnh hưởng; kiểm tra ngưỡng, thời gian chờ và điều kiện phụ; gom cảnh báo theo dịch vụ; bổ sung thông tin ngữ cảnh trong thông báo; ưu tiên cảnh báo dựa trên SLO; đánh giá định kỳ hiệu quả từng quy tắc.

3.5. Traces khác Logs và Metrics ở điểm nào?

Metrics phù hợp để phát hiện xu hướng và kích hoạt cảnh báo; Logs cung cấp ngữ cảnh chi tiết của từng sự kiện; Traces mô tả quan hệ thời gian và đường đi của một yêu cầu. Trong sự cố phân tán, ba loại tín hiệu nên được sử dụng kết hợp thay vì lựa chọn một loại duy nhất.

3.6. RCA được thực hiện như thế nào?

Quy trình tốt gồm: xác nhận phạm vi, dựng timeline, phân biệt hiện tượng và nguyên nhân, thu thập bằng chứng, xác định nguyên nhân trực tiếp và nguyên nhân gốc, xác định yếu tố góp phần, đề xuất hành động có chủ sở hữu và thời hạn, sau đó theo dõi hiệu quả hành động.

3.7. Một sự cố xảy ra lúc 23 giờ, bạn xử lý thế nào?

Cần trả lời theo thứ tự: bảo đảm an toàn dữ liệu và dịch vụ; xác nhận phạm vi; phân loại cấp độ; thông báo đúng người trực; khôi phục dịch vụ; cập nhật timeline và trạng thái; ghi nhận sự cố; phối hợp khắc phục; thực hiện RCA và phòng ngừa tái diễn.

3.8. Thay đổi nền tảng giám sát cần kiểm soát ra sao?

Nêu quy trình: phân tích yêu cầu và rủi ro; lập kế hoạch; xác định phạm vi và tiêu chí thành công; kiểm thử trong môi trường trước; xây dựng phương án hoàn tác; lấy phê duyệt; triển khai theo giai đoạn; kiểm tra sau triển khai; ghi nhận thay đổi và bài học.

3.9. Vì sao chọn Prometheus, Grafana hoặc công cụ thương mại?

Không nên trả lời chỉ vì quen công cụ. Hãy so sánh chi phí, khả năng mở rộng, hệ sinh thái, khả năng tích hợp ITSM và cloud, độ phức tạp vận hành, yêu cầu bảo mật, chất lượng correlation và tổng chi phí sở hữu trong ba năm.

3.10. Bạn nâng cấp kỹ năng Observability bằng cách nào?

Câu trả lời tốt cần cho thấy việc tự xây môi trường thực hành, đọc tài liệu chính thức, phân tích sự cố thật, xây dựng dashboard và alert, viết Runbook, đồng thời đóng góp hoặc theo dõi một dự án mã nguồn mở phù hợp.

4. Bài kiểm tra tình huống nên chuẩn bị

Có thể luyện với kịch bản: “Dịch vụ Internet Banking tăng đột ngột 40% số yêu cầu, độ trễ p95 tăng từ 800 mili giây lên 3 giây và tỷ lệ lỗi tăng từ 0,2% lên 3%. Hãy đề xuất cách giám sát, khoanh vùng và ứng cứu.”

Bài làm tốt cần bao gồm:

1. Xác nhận phạm vi và mức độ ảnh hưởng người dùng.
2. Kiểm tra giám sát hạ tầng, mạng, ứng dụng, cơ sở dữ liệu và phụ thuộc bên ngoài.
3. Phân biệt tăng tải thực sự với lỗi cấu hình, tài nguyên, phụ thuộc hoặc triển khai.
4. Xác định tín hiệu cần kiểm tra theo thứ tự ưu tiên.
5. Xây dựng giả thuyết và phương pháp kiểm chứng.
6. Đề xuất hành động cứu hộ, quyết định rollback hoặc phân tích băng thông nếu phù hợp.
7. Cập nhật timeline, mức cảnh báo và quy trình thông báo.
8. Sau sự cố, đề xuất hành động phòng ngừa và SLO phù hợp.

5. Câu hỏi tình huống và câu trả lời theo cấu trúc

Dùng cấu trúc Tình huống – Nhiệm vụ – Hành động – Kết quả – Bài học cho câu hỏi về sự cố. Ví dụ:

Tình huống: nền tảng giám sát gửi hơn 300 cảnh báo trong một giờ, khiến đội ngũ bỏ sót cảnh báo quan trọng.
Nhiệm vụ: đánh giá tác động và đề xuất cải thiện trong hai tuần.
Hành động: phân loại cảnh báo theo dịch vụ và mức độ; đo tần suất; xác định nguồn cảnh báo lặp; điều chỉnh ngưỡng và thời gian chờ; thêm thông tin ngữ cảnh; xây dựng báo cáo chất lượng cảnh báo.
Kết quả: giảm cảnh báo lặp, tăng tỷ lệ cảnh báo được xử lý đúng thời hạn và phục hồi tín hiệu quan trọng trong thời gian ngắn hơn.
Bài học: số lượng cảnh báo không đồng nghĩa với khả năng phát hiện sự cố tốt; chất lượng tín hiệu mới là mục tiêu quan trọng.

6. Chuẩn bị hình thức và hành vi

Trang phục nên theo phong cách business casual lịch sự, gọn gàng và trang trọng, ưu tiên màu trung tính. Vị trí không giao tiến trực tiếp với khách hàng nên không nhất thiết dùng bộ vest nếu lời mời không yêu cầu; có thể hỏi trước.
Mang sẵn sơ đồ kiến trúc hệ thống từng làm việc, không chia sẻ thông tin mật của khách hàng hoặc doanh nghiệp trước.
Trả lời ngắn gọn, rõ ràng, có số liệu. Không nói quá nhiều về công cụ mà thiếu phân tích vấn đề.
Nếu chưa biết câu trả lời, nêu rõ điều đã biết, cách sẽ kiểm tra và phương án xử lý an toàn.
Chuẩn bị sẵn ba câu hỏi dành cho người phỏng vấn và năm câu hỏi dành cho lãnh đạo khối CNTT.

7. Câu hỏi nên đặt cho người phỏng vấn

1. Vị trí giám sát dịch vụ 24/7 nhưng làm việc trong giờ hành chính có cơ chế trực và hỗ trợ ngoài giờ như thế nào?
2. Tần suất trực, thời gian phản hồi và chính sách bù đắp cho ca ngoài giờ là ra sao?
3. Stack Monitoring/Observability hiện tại của khối gồm những công cụ nào? Nền tảng nào đang được ưu tiên mở rộng?
4. Phạm vi giám sát bao gồm hạ tầng vật lý, cloud, container, cơ sở dữ liệu, API và ứng dụng nghiệp vụ đến mức nào?
5. Đội ngũ hiện có bao nhiêu người và sự cố thường được phân loại theo những cấp độ nào?
6. Các KPI chính của đội giám sát là gì: độ bao phủ, thời gian phát hiện, thời gian phản hồi, thời gian khôi phục hay chất lượng cảnh báo?
7. Quy trình Incident, Problem và Change Management được sử dụng với công cụ nào?
8. Vị trí này được giao quyền xây dựng hay chủ trì nền tảng, hay chủ yếu vận hành và tối ưu nền tảng đã có?
9. Cơ hội đào tạo, hỗ trợ chứng chỉ, hội nghị kỹ thuật và ngân sách học tập như thế nào?
10. Tiêu chí thành công rõ ràng nhất sau 03 tháng đầu tiên là gì?
11. Lịch làm việc, chính sách làm thêm và điều kiện làm việc tại văn phòng Hà Nội ra sao?
12. Quy trình phê duyệt thay đổi và yêu cầu bảo mật có ảnh hưởng thế nào đến tốc độ triển khai công cụ giám sát?

Lộ trình ôn thi

1. Mục tiêu ôn thi

Sau lộ trình 14 ngày, ứng viên cần đạt được bốn kết quả:

1. Giải thích chắc chắn các khái niệm Observability, Metrics, Logs, Traces, SLI, SLO, SLA và Error Budget.
2. Biết sử dụng thực tế một stack giám sát, ưu tiên Grafana, Prometheus và OpenSearch/ELK.
3. Có khả năng thiết kế dashboard, cảnh báo, quy trình xử lý sự cố và workflow tự động hóa.
4. Trả lời được câu hỏi chuyên môn, câu hỏi tình huống và câu hỏi về định hướng phát triển nghề nghiệp.

Thời gian hợp lý là khoảng 2–3 giờ mỗi ngày, tập trung vào thực hành thay vì chỉ đọc lý thuyết.

2. Lộ trình 14 ngày

Ngày	Nội dung	Bài thực hành và tiêu chí hoàn thành
Ngày 1	Phân tích lại tin tuyển dụng, lập hồ sơ năng lực	Tạo bảng tự đánh giá mức độ mạnh, trung bình và yếu của từng nhóm kỹ năng; chuẩn hóa CV theo năng lực thực tế
Ngày 2	Nền tảng Observability	So sánh Monitoring và Observability; phân biệt Metrics, Logs, Traces và Events; lập sơ đồ luồng tín hiệu từ ứng dụng đến dashboard
Ngày 3	Prometheus và PromQL	Cài Prometheus, Node Exporter và một ứng dụng mẫu; thực hiện truy vấn tỷ lệ lỗi, tần suất, độ trễ và tài nguyên
Ngày 4	Grafana	Tạo dashboard tổng quan dịch vụ, tài nguyên máy chủ và ứng dụng; thêm biến, data source, panel và liên kết điều hướng
Ngày 5	Alerting	Tạo cảnh báo theo lỗi, độ trễ, mất dịch vụ và tài nguyên; tinh chỉnh thời gian chờ, nhãn và mức độ nghiêm trọng
Ngày 6	OpenSearch hoặc ELK	Thu thập log có cấu trúc; lọc theo thời gian, mức lỗi và mã giao dịch; xây dựng dashboard log và cơ chế nhận diện lỗi lặp
Ngày 7	Traces và quan hệ dịch vụ	Tìm hiểu OpenTelemetry, trace ID, span và mối liên hệ giữa trace, log, metric; vẽ sơ đồ một luồng yêu cầu phân tán
Ngày 8	SRE, SLO và Error Budget	Xây dựng SLI cho API; đề xuất SLO; tính Error Budget; lập quy tắc quyết định khi tạm dừng thay đổi hoặc tăng cường ổn định
Ngày 9	Hạ tầng, mạng và hệ điều hành	Ôn Linux process, service, log, DNS, TCP/IP, HTTP/TLS, cơ sở dữ liệu, middleware, API và container; vẽ sơ đồ phụ thuộc của một dịch vụ
Ngày 10	Tự động hóa bằng Python và API	Viết script lấy dữ liệu cảnh báo, tạo ticket mô phỏng, gửi thông báo và cập nhật trạng thái; xử lý lỗi và ghi log an toàn
Ngày 11	ITSM, Incident và RCA	Lập quy trình Event – Incident – Problem – Change; xây dựng timeline và bản mẫu báo cáo RCA; xác định hành động phòng ngừa có chủ sở hữu
Ngày 12	Bài tình huống	Giải bài Internet Banking bị tăng độ trễ trong 60 phút; trình bày rõ kế hoạch phát hiện, khoanh vùng, cứu hộ và phòng ngừa
Ngày 13	Phỏng vấn mô phỏng	Trả lời ít nhất 20 câu hỏi chuyên môn và 8 câu hỏi tình huống; ghi âm để kiểm tra tốc độ, độ rõ ràng và số lần dùng từ chung chung
Ngày 14	Tổng kết	Rà soát CV, portfolio, thông tin lương, câu hỏi dành cho nhà tuyển dụng; chuẩn bị phương án xử lý trường hợp kỹ thuật bị hỏi ngoài dự kiến

3. Bài lab trọng tâm nên hoàn thành

3.1. Môi trường

Có thể dựng bằng Docker Compose hoặc Kubernetes nhẹ với các thành phần:

Một ứng dụng API mô phỏng có tỷ lệ lỗi và độ trễ thay đổi theo thời gian.
Prometheus để thu thập và tính toán metric.
Grafana để hiển thị dashboard và cảnh báo.
OpenSearch hoặc ELK để lưu và truy vấn log.
Jaeger hoặc OpenTelemetry Collector để minh họa trace.
Một webhook mô phỏng tạo ticket.

3.2. Sản phẩm cần có

1. Sơ đồ kiến trúc Monitoring/Observability.
2. Dashboard có lớp tổng quan, lớp ứng dụng và lớp hạ tầng.
3. Ít nhất bốn Alert Rule: mất dịch vụ, tỷ lệ lỗi, độ trễ p95 và tài nguyên gần hết ngưỡng.
4. Một bảng định nghĩa SLI, SLO, cửa sổ đo và Error Budget.
5. Một quy trình tự động tạo ticket khi cảnh báo quan trọng phát sinh.
6. Một Runbook xử lý sự cố được.
7. Một bản timeline và RCA mô phỏng.
8. Một slide tóm tắt kết quả kèm điểm cải thiện về độ chính xác của cảnh báo.

3.3. Tiêu chí chất lượng

Mỗi cảnh báo có mức độ nghiêm trọng, điều kiện kích hoạt, thời gian chờ, chủ sở hữu và Runbook.
Dashboard có thông tin đủ để phân biệt lỗi ứng dụng, hạ tầng và phụ thuộc bên ngoài.
Log không chứa dữ liệu bí mật hoặc thông tin khách hàng nhạy cảm.
Script có kiểm tra lỗi, xử lý lặp an toàn và nhật ký đầy đủ.
Mọi giả định trong thiết kế được ghi rõ.

4. Kiến thức nền cần ưu tiên

4.1. Observability

Máy trạng thái và tín hiệu hệ thống.
Cardinality và chi phí dữ liệu.
Sampling trong trace và log.
Correlation giữa log, metric và trace.
OpenTelemetry và chiến lếp thu thập dữ liệu.
Synthetic monitoring và kiểm thử chủ động.

4.2. SRE và Incident Management

Mục tiêu độ tin cậy và quyết định cân bằng tốc độ phát triển với ổn định.
Quản lý sự cố, phân loại mức độ, vai trò trực và quy trình truyền thông.
Runbook, Playbook, Postmortem và hành động phòng ngừa.
Change Management, thay đổi khẩn cấp và phương án hoàn tác.

4.3. Hệ điều hành và mạng

Linux: process, service, port, disk, memory, network và log.
DNS, DHCP, TCP/IP, HTTP, TLS, firewall, load balancer và VPN.
Container: Docker, Kubernetes, pod, service, deployment và persistent volume.
Cơ sở dữ liệu: connection, query chậm, lock, replication và transaction log.
API: REST, authentication, authorization, timeout, retry và circuit breaker.

4.4. ITSM

Incident: sự cố đang xảy ra và cần phục hồi nhanh.
Problem: nguyên nhân gốc có thể tái diễn.
Change: thay đổi được kiểm soát và phê duyệt.
Service Request: yêu cầu dịch vụ thông thường.
Known Error và Problem Management.

5. Tài liệu tham khảo nên ưu tiên

Tài liệu chính thức Prometheus về metric, PromQL, alert rule, recording rule và exemplar.
Tài liệu Grafana về dashboard, data source, alert, biến và plugin.
Tài liệu OpenSearch hoặc Elasticsearch về query, index và dashboard.
Tài liệu OpenTelemetry về trace, metric và log.
Tài liệu Kubernetes về workload, service, pod và troubleshooting.
Tài liệu ITIL 4 về Incident, Problem và Change Management.
Sách Site Reliability Engineering của Google và các bài viết về SLO, Error Budget.
Tài liệu ITIL hoặc quy trình nội bộ của từng tổ chức về phân loại sự cố và báo cáo RCA.

Nên ưu tiên tài liệu chính thức và ví dụ thực tế hơn các bài tóm tắt không rõ nguồn gốc. Khi học, mỗi khái niệm nên được ghi lại bằng một câu giải thích, một ví dụ và một truy vấn hoặc sơ đồ liên quan.

6. Danh sách kiểm tra trước ngày phỏng vấn

CV có số liệu và phạm vi trách nhiệm rõ ràng.
Portfolio có sơ đồ kiến trúc, dashboard, cảnh báo và workflow tự động hóa.
Có thể giải thích mọi công cụ trong CV, kể cả lý do không còn sử dụng.
Chuẩn bị tối thiểu ba ví dụ về sự cố, cải tiến cảnh báo và tự động hóa.
Hiểu rõ lý do chuyển sang Observability hoặc SRE.
Xác định mức lương kỳ vọng và thông tin cần làm rõ về lịch hỗ trợ ngoài giờ.
Chuẩn bị tài liệu tiếng Anh liên quan và một danh sách thuật ngữ thường dùng.
Kiểm tra kết nốn Internet, camera, micro, nền phông và thiết bị dự phòng nếu phỏng vấn trực tuyến.
Thử phản hồi trả lời trong một phút và nói rõ điểm chưa chắc chắn.

7. Chuẩn bị tiếng Anh

Không nhất thiết luyện hội thoại nâng cao nếu yêu cầu chính là đọc tài liệu. Tuy nhiên, nên chuẩn bị từ vựng về monitoring, observability, reliability, incident, alert, dashboard, latency, throughput, availability, root cause và remediation. Có thể luyện giải thích ngắn một kiến trúc giám sát bằng tiếng Anh trong 3–5 phút để tăng sự tự tin khi trao đổi với chuyên gia hoặc đọc tài liệu trong cuộc họp.

Tư vấn nghề nghiệp

1. Định vị nghề nghiệp của vị trí

Đây là hướng đi khá mạnh trong lĩnh vực vận hành CNTT và độ tin cậy dịch vụ. Tên chức danh hiện tại là Chuyên viên Cao cấp, nhưng nội dung công việc có hướng tiến gần với Senior Observability Engineer, SRE hoặc Trưởng nhóm giám sát.

Lộ trình phát triển có thể là:

1. Chuyên viên giám sát hệ thống.
2. Chuyên viên Observability hoặc SRE.
3. Chuyên viên cao cấp hoặc kỹ sư giám sát.
4. Trưởng nhóm giám sát, kỹ sư trưởng hoặc kiến trúc sư vận hành.
5. Quản lý vận hành CNTT hoặc quản lý nền tảng giám sát.

2. Lộ trình nâng cấp năng lực

Trong 6 tháng

Chọn một stack cốt lõi và đạt khả năng vận hành độc lập.
Luyện PromQL, truy vấn log, thiết kế cảnh báo và phân tích độ trễ.
Làm chủ quy trình Incident, Change, RCA và viết Runbook.
Tự động hóa ít nhất một quy trình tạo ticket hoặc tổng hợp báo cáo.

Trong 12 tháng

Nâng cấp kỹ năng cloud-native, Kubernetes và OpenTelemetry.
Xây dựng chương trình quản lý SLO cho một nhóm dịch vụ thực tế.
Làm việc với quản lý thay đổi, kiểm toán, phân quyền và bảo mật dữ liệu giám sát.
Đóng góp tài liệu, runbook hoặc hướng dẫn cho đồng nghiệp.

Trong 18–24 tháng

Dẫn dắt một nhóm hoặc chương trình cải thiện chất lượng giám sát toàn ngân hàng.
Xây dựng chỉ số đo lường hiệu quả của đội ngũ và cơ chế cải tiến liên tục.
Tích lũy kinh nghiệm quản lý đối tác, ngân sách công cụ và đánh giá giải pháp.
Chuẩn bị chứng chỉ có liên quan để củng cố hồ sơ chuyên môn.

3. Các KPI nên gắn với vị trí

Trong phỏng vấn, ứng viên có thể đề xuất hoặc hỏi về các chỉ số sau:

Tỷ lệ dịch vụ và hạ tầng được bao phủ bởi tín hiệu giám sát.
Tỷ lệ cảnh báo hữu ích, tỷ lệ cảnh báo giả và số cảnh báo lặp.
Thời gian trung bình phát hiện, tiếp nhận và khôi phục sự cố.
Tỷ lệ sự cố có timeline đầy đủ, phân loại đúng và hành động phòng ngừa hoàn thành.
Số lượng quy trình được tự động hóa và số giờ tiết kiệm mỗi tháng.
Mức độ tuân thủ quy trình thay đổi và audit.
Tỷ lệ tái diễn của sự cố sau khi áp dụng hành động phòng ngừa.

4. Mức lương kỳ vọng tham khảo

Tin tuyển dụng ghi lương thỏa thuận và không công bố phúc lợi, thưởng hoặc chính sách bù đắp ca trực. Dưới đây là mức ước tính cho công việc vận hành Observability tại Hà Nội, tính theo lương gross hằng tháng và chưa bao gồm thưởng:

Kinh nghiệm và định hướng	Khoảng lương gross ước tính mỗi tháng
03–05 năm, đã vận hành nền tảng giám sát và có thể làm việc độc lập	25–40 triệu đồng
05–08 năm, thành thạo một stack lớn, tự động hóa và xử lý sự cố phức tạp	35–55 triệu đồng
08 năm trở lên, có thể dẫn dắt, thiết kế chiến lược Observability và phối hợp nhiều đơn vị	45–70 triệu đồng
Trưởng nhóm, kiến trúc sư vận hành hoặc quản lý nền tảng	55–85 triệu đồng

Mức lương có thể thay đổi tùy ngân hàng và thời điểm. Các mức trên cũng phụ thuộc vào quy mô tổ chức, phạm vi trách nhiệm, lịch trực ngoài giờ, công cụ đang sử dụng, năng lực quản lý và cấu trúc thưởng. Thưởng hiệu quả công việc, phụ cấp ca trực, phúc lợi và tỷ lệ thưởng theo KPI không được nêu trong tin tuyển dụng nên cần hỏi riêng trong phỏng vấn.

5. Cách đàm phán lương

Nên đưa ra khoảng dự kiến dựa trên tổng thu nhập mong muốn, thay vì chỉ nói một con số lương cơ bản. Có thể dùng mẫu sau:

> “Dựa trên kinh nghiệm vận hành nền tảng giám sát, kinh nghiệm xử lý sự cố và phạm vi trách nhiệm hiện tại, tôi kỳ vọng tổng thu nhập hằng tháng trong khoảng X đến Y. Tôi muốn hiểu thêm về cơ chế thưởng theo KPI, phụ cấp ca trực và các khoản bù đắp khác trước khi chốt phương án.”

Nên hỏi rõ:

Lương cơ bản và ngưỡng thưởng.
Cơ chế thưởng cá nhân và thưởng đội.
Phụ cấp cho ca trực hoặc hỗ trợ ngoài giờ.
Chính sách làm thêm và ngày nghỉ bù.
Phúc lợi, bảo hiểm, đào tạo và thiết bị làm việc.
Thời điểm xét tăng lương và tiêu chí tăng lương.

6. Kế hoạch 90 ngày nếu được nhận việc

30 ngày đầu

Học kiến trúc, danh mục dịch vụ, quy trình phê duyệt, lịch trực và danh sách hệ thống quan trọng.
Xác định các điểm mù giám sát và nguồn dữ liệu chưa đầy đủ.
Phân tích chất lượng cảnh báo hiện tại và thống nhất cách đo.

Từ ngày 31 đến 60

Chuẩn hóa dashboard và quy tắc cảnh báo ưu tiên.
Triển khai hoặc cải thiện một quy trình tự động hóa.
Xây dựng mẫu timeline, RCA, Runbook và báo cáo KPI.
Phối hợp đào tạo các điểm còn thiếu với đội ngũ.

Từ ngày 61 đến 90

Đánh giá lại độ bao phủ tín hiệu, tỷ lệ cảnh báo giả và thời gian phản hồi.
Trình bày kết quả cải thiện cùng danh sách hành động tiếp theo.
Đề xuất lộ trình chuẩn hóa nền tảng và phát triển năng lực cho đội.

7. Rủi ro cần cân nhắc

Tên vị trí có thể gây hiểu nhầm: cần xác minh mức độ tham gia thiết kế nền tảng so với vận hành và xử lý sự cố.
Khối lượng trực ngoài giờ: cần biết tần suất, cơ chế bật người trực, thời gian phản hồi và chính sách bù đắp.
Khả năng phát triển: cần biết đội có cơ hội làm kiến trúc, tự động hóa, SRE và cải tiến quy trình hay chủ yếu xử lý cảnh báo hằng ngày.
Chất lượng dữ liệu: một nền tảng giám sát thiếu tín hiệu hoặc log không chuẩn sẽ giảm hiệu quả dù công cụ mạnh.
Sai lệch chức danh và quyền lực: cần thống nhất rõ về việc dẫn dắt, phê duyệt thay đổi và khả năng cải thiến quy trình.

8. Lời khuyên phát triển bền vững

Ứng viên nên xây dựng hồ sơ theo hướng chứng minh khả năng biến dữ liệu giám sát thành quyết định vận hành, không chỉ biết cấu hình công cụ. Hãy lưu giữ portfolio, sơ đồ kiến trúc, ví dụ cảnh báo, quy trình RCA, workflow tự động hóa và kết quả đo được. Đây là tài liệu quan trọng khi ứng tuyển các vị trí SRE, kiến trúc sư vận hành hoặc trưởng nhóm trong tương lai.

Câu hỏi thường gặp

Tôi là sinh viên năm cuối chưa có kinh nghiệm làm việc, có thên ứng tuyển vị trí này không?

Vị trí yêu cầu tối thiểu 03 năm kinh nghiệm nên cơ hội đạt yêu cầu hiện tại khá thấp. Tuy vậy, bạn vẫn có thể chuẩn bị bằng một dự án thực tế gồm Prometheus, Grafana, OpenSearch hoặc ELK, cùng dashboard, cảnh báo, Runbook và bài RCA. Hãy tìm thực tập hoặc vị trí vận hành hệ thống ban đầu, sau đó tích lũy kinh nghiệm về quản trị nền tảng, giám sát, SRE, ITSM và tự động hóa trước khi ứng tuyển lại. Không nên đưa kinh nghiệm dự án học thuật vào CV như kinh nghiệm làm việc.

Tôi có 02 năm kinh nghiệm vận hành hệ thống, có nên nộp hồ sơ để xem cơ hội không?

Bạn có thể nộp hồ sơ nếu tin tuyển dụng cho phép ứng tuyển sớm, nhưng cần thừa nhận rõ khoảng cách 01 năm kinh nghiệm và nhấn mạnh các thành tựu có thể chứng minh. Những điểm cộng gồm vận hành dịch vụ 24/7, xử lý cảnh báo, viết Runbook, làm việc với ITSM, quản trị Linux hoặc mạng, tự động hóa bằng Script và hiểu SLO. Trong thư ứng tuyển, hãy nêu rõ mục tiêu đạt 03 năm và các dự án sẽ hoàn thành trong 06 tháng tới. Nếu có thể, hãy tích lũy thêm kinh nghiệm thực tế về Prometheus, Grafana hoặc OpenSearch trước khi phỏng vấn.

Tôi đang chuyển từ lập trình backend sang vị trí Observability hoặc SRE, liên hệ nghề nghiệp nào có thể dùng?

Kinh nghiệm backend rất có giá trị vì bạn đã hiểu ứng dụng, API, cơ sở dữ liệu, log, độ trễ và cách phân tích sự cố. Hãy chuyển góc nhìn từ xây tính năng sang quan sát hành vi hệ thống trong vận hành. Bạn có thể chứng minh khả năng xây health endpoint, metric theo huse, structured log, distributed trace, alerting theo SLO, viết dashboard và tự động hóa bằng Python hoặc API. Hãy bổ sung kiến thức về Kubernetes, Prometheus, OpenTelemetry, incident management và RCA. Một portfolio kết hợp giữa kinh nghiệm phát triển và vận hành sẽ giúp bạn cạnh tranh tốt hơn.

Trong nhiều công cụ giám sát được nêu, tôi nên ưu tiên học công cụ nào?

Hãy chọn một stack mà bạn có thể trình bày sâu. Lựa chọn phổ biến là Grafana kết hợp Prometheus cho metric và dashboard, OpenSearch hoặc ELK cho log, OpenTelemetry để thu thập trace và API để tích hợp ITSM. Sau đó bổ sung Zabbix nếu môi trường doanh nghiệp dùng nhiều giám sát hạ tầng. Dynatrace, Splunk và Datadog cũng đáng học khi doanh nghiệp đang tuyển theo hệ sinh thái đó. Điều quan trọng hơn việc biết nhiều tên là khả năng giải thích cách thu thập tín hiệu, thiết kế cảnh báo, đo chất lượng cảnh báo, xử lý cardinality và tự động hóa quy trình.

Mức lương hợp lý khi ứng tuyển vị trí Chuyên viên Cao cấp giám sát tại Hà Nội là bao nhiêu?

Với khoảng 03–05 năm kinh nghiệm, mức lương gross có thể tham khảo khoảng 25–40 triệu đồng mỗi tháng; kinh nghiệm sâu hơn và khả năng dẫn dắt có thể đưa mức lương cao hơn. Mức lương có thể thay đổi tùy ngân hàng và thời điểm. Tin tuyển dụng ghi lương thỏa thuận và không nêu phúc lợi, thưởng hoặc bù đắp ca trực, vì vậy bạn cần hỏi rõ tổng thu nhập gồm lương cơ bản, thưởng theo KPI và phụ cấp ngoài giờ trước khi chốt mức đề xuất.

KPI quan trọng nhất của một chuyên viên giám sát là gì?

Không nên chỉ nhìn vào số cảnh báo đã xử lý. KPI cân bằng nên gồm độ bao phủ giám sát, tỷ lệ cảnh báo hữu ích, tỷ lệ cảnh báo giả, thời gian phát hiện, thời gian phản hồi, thời gian khôi phục, tỷ lệ sự cố có RCA đầy đủ và số quy trình được tự động hóa. Với vị trí cao cấp, kỳ vọng còn cao hơn: bạn phải đề xuất cải thiện hệ thống, không chỉ xử lý đầu vào của đội.

Tôi nên làm rõ điều gì về yêu cầu hỗ trợ sự cố ngoài giờ?

Hãy hỏi trực tiếp về tần suất trực, cách xác định người trực, thời gian phản hồi, mức bù đắp, ngày nghỉ bù và ảnh hưởng đến lịch nghỉ. Cụm “dịch vụ giám sát 24/7” có thể chỉ đặc thù của dịch vụ, trong khi vị trí làm việc theo giờ hành chính; tuy nhiên mô tả cũng yêu cầu hỗ trợ ngoài giờ khi cần thiết. Mức độ tham gia thực tế là thông tin quan trọng ảnh hưởng đến lương, sức khỏe và mức độ bền vững của công việc.

Tôi chỉ đọc được tài liệu tiếng Anh nhưng giao tiếp tiếng Anh chưa tốt, có nên ứng tuyển không?

Có, vì yêu cầu được nêu là đọc và hiểu tài liệu kỹ thuật bằng tiếng Anh, không yêu cầu trình bày bằng tiếng Anh. Hãy chuẩn bị thuật ngữ, đọc tài liệu chính thức và giải thích sơ đồ bằng tiếng Việt trước. Trong phỏng vấn, bạn có thể nói rõ rằng khả năng đọc là điểm mạnh và đang chủ động cải thiện giao tiếp. Nếu có từ vựng nghiệp vụ và khả năng viết tài liệu kỹ thuật tốt, ứng viên vẫn có lợi thế rõ ràng.

Lộ trình nâng cấp từ giám sát hệ thống lên vị trí cao cấp nên được xây dựng như thế nào?

Hãy tập trung vào bốn lớp năng lực: thành thạo một stack giám sát, hiểu sâu SRE và SLO, tự động hóa quy trình bằng Script hoặc API, và khả năng điều phối sự cố cùng nhiều đơn vị. Sau đó bổ sung cloud-native, OpenTelemetry, bảo mật và quản lý thay đổi. Mỗi năm hãy tạo ra ít nhất một kết quả đo được như giảm cảnh báo giả, giảm thời gian khôi phục hoặc tự động hóa một quy trình. Khi đã dẫn dắt sự cố và cải tiến quy trình trong phạm vi rộng, bạn sẽ có cơ sở ứng tuyển các vị trí kỹ sư, trưởng nhóm hoặc kiến trúc sư vận hành.

Nếu không có nhiều kinh nghiệm với công cụ thương mại như Splunk hoặc Datadog, tôi có còn cơ hội không?

Có. Yêu cầu ghi “một hoặc nhiều công cụ” và chấp nhận giải pháp tương đương, nên kinh nghiệm sâu với Prometheus, Grafana, OpenSearch hoặc Zabbix vẫn hoàn toàn phù hợp. Hãy thể hiện khả năng chuyển đổi giữa công cụ bằng cách nêu các khái niệm chung: datasource, query, dashboard, alert rule, incident và workflow. Nếu phỏng vấn về công cụ thương mại, hãy trung thực về kinh nghiệm và tập trung vào cách bạn sẽ học, đọc tài liệu và chuyển đổi mô hình vận hành.

Chuyên viên Cao cấp Dịch vụ giám sát 24/7 (giờ hành chính) - K.CNTT