ACB Insurance - IT Application Operation Lead

1. Tổng quan vị trí

Vị trí ACB Insurance - IT Application Operation Lead là vị trí thuộc mảng DevOps, SRE và vận hành ứng dụng, không phải vị trí kinh doanh ngân hàng hay chỉ xử lý yêu cầu hỗ trợ người dùng. Ứng viên còn chịu trách nhiệm trực tiếp đến tính ổn định của ứng dụng số trong môi trường vận hành thật, triển khai bản phát hành, cấu hình hệ thống, giám sát, xử lý sự cố và chuẩn hóa tài liệu vận hành.

Ba trục năng lực quan trọng nhất là:

1. Vận hành hệ thống trong môi trường Production: bảo đảm tính sẵn sàng, tuân thủ SLA, xử lý sự cố và giảm thời gian khôi phục dịch vụ.
2. Triển khai và phát hành ứng dụng: sử dụng quy trình Agile, CI/CD, quản lý cấu hình và bảo đảm phát hành an toàn, đúng lịch.
3. Nền tảng kỹ thuật: Kubernetes, Docker, Kong API Gateway, microservice, Redis, Linux, Python, Ansible và hệ thống observability.

Chức danh có chữ Lead, nhưng mô tả không đề cập rõ đến quản lý trực tiếp nhân sự. Vì vậy, ứng viên cần thể hiện năng lực làm chủ hệ thống, điều phối sự cố, ra quyết định trong tình huống áp lực và dẫn dắt về mặt kỹ thuật; không nên mô tả vị trí này là quản lý nhân sự nếu chưa có bằng chứng.

2. Ma trận kỹ năng và mức độ ưu tiên

3. Phân tích các kỹ năng trọng tâm

Kubernetes và Docker

Ứng viên không nên chỉ biết cách tạo Deployment hoặc chạy lệnh kubectl. Cần trả lời được các câu hỏi thực tế:

• Lựa chọn namespace, label, selector, service và secret như thế nào?
• Readiness probe, liveness probe và startup probe khác nhau ra sao?
• Cấu hình requests, limits, autoscaling và disruption budget thế nào?
• Phân biệt lỗi do image, cấu hình, dependency, network hay tài nguyên không đủ như thế nào?
• Triển khai canary, rollback và kiểm tra sau phát hành bằng cách nào?
• RBAC, NetworkPolicy và quản lý bí mật có vai trò gì trong môi trường Production?

Kong API Gateway và Redis

Cần nắm các khái niệm route, service, plugin, upstream, consumer và cách Kong phối hợp với các microservice. Các plugin nên biết gồm authentication, rate limiting, request/response transformation, logging và tracing. Với Redis, ứng viên cần hiểu cơ chế cache, TTL, eviction policy, failover, connection pool và ảnh hưởng của cache đến tính nhất quán dữ liệu.

CI/CD và phát hành an toàn

Một câu trả lời tốt cần trình bày đầy đủ chuỗi phát hành:

1. Kiểm tra mã nguồn và review.
2. Build và unit test.
3. Quét bảo mật, dependency và container image.
4. Đóng gói và đẩy image vào registry.
5. Phát hành qua GitLab CI hoặc ArgoCD.
6. Chờ trạng thái ổn định, kiểm tra lỗi và giám sát.
7. Rollback hoặc dừng phát hành nếu có cảnh báo bất thường.
8. Lưu bằng chứng, phê duyệt và cập nhật CMDB/tài liệu.

Observability

Phân biệt rõ:

• Metric: xu hướng định lượng như độ trễ, tỷ lệ lỗi, lưu lượng và sử dụng tài nguyên.
• Log: chi tiết sự kiện và ngữ cảnh xử lý.
• Trace: luồng của một yêu cầu qua nhiều dịch vụ.

Ứng viên cần biết cách xây dựng dashboard cho từng dịch vụ, cảnh báo dựa trên ngưỡng lỗi và độ trễ, tránh cảnh báo nhiễu, đồng thời trả lời câu hỏi: làm thế nào phát hiện sự cố trước khi người dùng báo? Dynatrace là điểm cộng, không nên thay thế toàn bộ nền tảng Prometheus, Grafana và ELK trong phần chuẩn bị.

Quản lý cấu hình và tài liệu

CMDB trong bối cảnh này là cơ sở dữ liệu quản lý cấu hình, giúp biết một ứng dụng gồm những thành phần nào, phụ thuộc vào đâu, chủ sở hữu là ai, cấu hình hiện tại và lịch sử thay đổi ra sao. Ứng viên cần biết cách tránh cấu hình nằm rải rác trong tài liệu cá nhân, mã nguồn hoặc đầu óc của kỹ sư, đồng thời bảo đảm mọi thay đổi Production đều có phiên bản, người phê duyệt, thời điểm và kết quả kiểm tra.

4. Kỹ năng mềm cần thể hiện

• Ứng phó sự cố: bình tĩnh, xác định phạm vi ảnh hưởng, ưu tiên giảm thiểu tác động thay vì tìm nguyên nhân ngay lập tức.
• Giao tiếp với đa bên: truyền đạt rõ tình trạng cho kỹ thuật, nghiệp vụ và khách hàng nội bộ; điều chỉnh mức chi tiết theo đối tượng.
• Tư duy quyết định: biết khi nào rollback, khi nào tạm dừng phát hành và khi nào cần mở rộng phạm vi điều tra.
• Tổ chức công việc: quản lý nhiều yêu cầu, ưu tiên theo mức ảnh hưởng và SLA.
• Tư duy phòng ngừa: sau mỗi sự cố đều đề xuất hành động giảm khả năng tái diễn.
• Tài liệu hóa: viết runbook rõ ràng để người khác có thể tiếp quản trong ca đêm, ngày nghỉ hoặc khi vắng mặt.
• Thương lượng: đề xuất phương án khả thi khi các bên có lợi ích hoặc nguồn lực khác nhau.

5. Chứng chỉ nên cân nhắc

Không nên dồn toàn bộ thời gian vào chứng chỉ khi còn thiếu kinh nghiệm thực tế. Với vị trí này, kinh nghiệm vận hành Production và khả năng giải thích sự cố thật có giá trị cao hơn việc liệt kê nhiều chứng chỉ chưa sử dụng.

6. Đánh giá điều kiện ứng tuyển và điểm cần bù

Điều kiện cứng nhất trong tin tuyển dụng là ít nhất 5 năm kinh nghiệm ở các vai trò DevOps, System Engineer, Fullstack, Application Support hoặc tương đương. Ứng viên dưới ngưỡng này vẫn có thể nộp hồ sơ nếu có kinh nghiệm dự án thực tế tương đương, nhưng cần chứng minh rõ hơn.

Các khoảng cách thường gặp và cách bù:

• Chưa dùng Kubernetes thực tế: triển khai service trên minikube hoặc kind, cấu hình probe, secret, ingress, autoscaling và mô phỏng pod lỗi.
• Chưa dùng Kong: dựng môi trường local với hai microservice, định tuyến qua Kong và cấu hình plugin rate limit hoặc authentication.
• Chưa dùng ArgoCD: xây pipeline GitLab CI đóng gói image và manifest, sau đó dùng ArgoCD triển khai và rollback.
• Chưa quen trực sự cố Production: chuẩn bị tối thiểu hai câu chuyện theo cấu trúc tình huống, hành động, kết quả và cải tiến sau sự cố.
• Chưa từng dẫn dắt: thể hiện vai trò điều phối trong một sự cố, dự án phát hành hoặc quy trình chuẩn hóa; không nên tự nhận là quản lý nhân sự.
• Chưa có kinh nghiệm bảo hiểm: học cơ bản về khách hàng, hợp đồng, quy trình nghiệp vụ và yêu cầu bảo mật dữ liệu, nhưng không thay thế kinh nghiệm kỹ thuật bằng kiến thức nghiệp vụ.

7. Hướng dẫn xây dựng hồ sơ

Tiêu đề hồ sơ nên gọn và đúng công nghệ, chẳng hạn:

> DevOps/SRE và Ứng dụng Vận hành | Kubernetes, Kong, GitLab CI, ArgoCD, Observability | SLA và Incident Management

Mỗi kinh nghiệm nên theo cấu trúc: hành động + công nghệ + phạm vi + kết quả. Ví dụ:

> Quản lý pipeline GitLab CI và triển khai 12 dịch vụ lên Kubernetes qua ArgoCD; giảm thời gian phát hành từ 45 phút xuống 18 phút, duy trì tỷ lệ phát hành thành công trên 98% và rút ngắn thời gian khôi phục trung bình xuống còn 20 phút.

Chỉ sử dụng số liệu thật. Những số liệu có giá trị gồm:

• Số dịch vụ, môi trường, người dùng hoặc lưu lượng phục vụ.
• Tần suất phát hành.
• Tỷ lệ phát hành thành công và tỷ lệ thay đổi gây sự cố.
• Thời gian triển khai, thời gian khôi phục trung bình và thời gian phát hiện sự cố.
• Mức SLA hoặc sẵn sàng thực tế của dịch vụ.
• Số cảnh báo nhiễu được loại bỏ, số sự cố tái diễn được ngăn chặn.
• Mức độ hoàn thiện của CMDB, runbook và tài liệu phục hồi.

Ngoài CV, nên chuẩn bị sẵn một bộ tài liệu không chứa thông tin mật của ngân hàng gồm:

1. Sơ đồ kiến trúc release và observability.
2. Một quy trình phát hành có kiểm soát.
3. Một runbook xử lý sự cố.
4. Một báo cáo sự cố hoặc post-mortem.
5. Một dashboard và một danh sách cảnh báo có chủ đích.

8. Điểm cần xác minh trước khi nộp hồ sơ

Tin tuyển dụng không cung cấp lương cụ thể, phúc lợi, lịch làm việc, chính sách trực, ca đêm hoặc cơ cấu nhóm. Ứng viên cần hỏi rõ trong phỏng vấn:

• Có ca trực hoặc trực sự cố ngoài giờ không?
• Tỷ lệ vận hành theo lịch, ca đêm và cuối tuần ra sao?
• Nhóm báo cáo cho ai và chịu trách nhiệm quản lý trực tiếp bao nhiêu người?
• Phạm vi ứng dụng, số dịch vụ và mức độ phụ thuộc hệ thống ngân hàng ra sao?
• Tiêu chí thành công của vị trí trong 6 tháng đầu là gì?
• Có đào tạo hoặc cấp chứng chỉ CKA, Kong, Dynatrace không?

Biểu mẫu trong tin tuyển dụng đang hiển thị trình độ học vấn bị cắt ở mức cao đẳng, trong khi yêu cầu chính thức là tốt nghiệp đại học. Ứng viên nên gửi CV và bằng cấp đầy đủ, đồng thời xác nhận lại với bộ phận tuyển dụng để tránh bị bỏ qua do lựa chọn trên biểu mẫu.