Linux Patch Management Trong Production: Quy Trình Cập Nhật An Toàn Cho Sysadmin

Linux patch management không chỉ là chạy apt upgrade hoặc dnf update rồi hy vọng mọi thứ ổn. Trong production, cập nhật hệ điều hành là một quy trình vận hành có rủi ro: bản vá bảo mật cần đi nhanh, nhưng downtime, lỗi dependency, kernel panic, service không khởi động lại được và thay đổi hành vi thư viện cũng có thể làm gián đoạn dịch vụ.

Bài viết này đưa ra một quy trình thực chiến cho sysadmin: phân loại bản vá, dựng staging/lab, chuẩn bị snapshot/backup, chạy lệnh cập nhật trên Ubuntu/Debian và RHEL/Rocky/AlmaLinux, kiểm tra sau cập nhật, rollback, troubleshooting và checklist nghiệm thu.

1. Vì sao patch management cần quy trình riêng?

Nhiều sự cố production không đến từ hacker mà đến từ thao tác bảo trì thiếu kiểm soát. Một bản cập nhật OpenSSL, glibc, systemd, kernel hoặc driver có thể yêu cầu restart service, reboot máy hoặc thay đổi dependency. Nếu cập nhật toàn bộ fleet cùng lúc, bạn có thể biến một lỗi nhỏ thành sự cố diện rộng.

Patch management tốt phải cân bằng ba mục tiêu:

Giảm rủi ro bảo mật: vá CVE quan trọng trước khi bị khai thác.
Giữ ổn định dịch vụ: cập nhật có kiểm soát, theo batch, có rollback.
Có bằng chứng vận hành: log, checklist, ticket, người phê duyệt, kết quả kiểm tra.

2. Phân loại bản vá: không phải update nào cũng giống nhau

Trước khi cập nhật, hãy phân loại:

Critical security patch: CVE đang bị khai thác, ảnh hưởng internet-facing service, cần xử lý trong vài giờ hoặc 1-2 ngày.
High/medium security patch: cần lên lịch theo maintenance window gần nhất.
Bug fix: sửa lỗi vận hành, nên test kỹ nếu chạm service quan trọng.
Feature update: ít khi nên đưa vào production nếu không có nhu cầu rõ.
Kernel/firmware/driver: cần reboot và kiểm tra tương thích hạ tầng ảo hóa/phần cứng.

Nếu dùng CMDB hoặc inventory, thêm trường business criticality, owner, maintenance window và rollback method cho từng server.

3. Chuẩn bị trước khi cập nhật

3.1. Kiểm kê hệ thống

Trước khi vá, biết chính xác bạn đang có gì:

hostnamectl
uname -a
cat /etc/os-release
systemctl --failed
ss -tulpn
 df -h

Ý nghĩa:

hostnamectl, /etc/os-release: xác nhận OS và version.
uname -a: kernel hiện tại, quan trọng khi so sánh sau reboot.
systemctl --failed: nếu trước update đã có service lỗi, đừng đổ hết cho bản vá.
ss -tulpn: ghi nhận port/service đang chạy.
df -h: thiếu disk trong /boot hoặc /var là nguyên nhân update fail rất phổ biến.

3.2. Snapshot, backup và rollback plan

Với VM, hãy tạo snapshot trước maintenance window. Với database hoặc stateful service, snapshot VM chưa chắc đủ; cần backup application-aware hoặc replication failover. Rollback plan tối thiểu phải trả lời:

Nếu update fail giữa chừng thì làm gì?
Nếu service không start sau update thì rollback package hay restore snapshot?
Nếu kernel mới lỗi thì boot kernel cũ thế nào?
Ai có quyền quyết định rollback?
Thời điểm nào dừng troubleshooting để rollback?

4. Kiểm tra bản vá trên Ubuntu/Debian

Luôn bắt đầu bằng cập nhật metadata và xem danh sách gói có thể nâng cấp:

sudo apt update
apt list --upgradable

Output mẫu:

openssl/jammy-updates 3.0.2-0ubuntu1.18 amd64 [upgradable from: 3.0.2-0ubuntu1.16]
linux-image-generic/jammy-updates 5.15.0.112.112 amd64 [upgradable from: 5.15.0.109.109]

Để xem changelog một gói:

apt changelog openssl | less

Cập nhật một gói cụ thể:

sudo apt install --only-upgrade openssl

Cập nhật toàn bộ gói đã cài:

sudo apt upgrade

Với production, tránh chạy dist-upgrade/full-upgrade bừa bãi nếu chưa hiểu tác động vì lệnh có thể thêm/xóa package để giải quyết dependency.

5. Kiểm tra bản vá trên RHEL/Rocky/AlmaLinux

Trên hệ RHEL-like, dùng dnf để xem security advisory:

sudo dnf check-update
sudo dnf updateinfo list security
sudo dnf updateinfo info --security

Cập nhật security patch:

sudo dnf update --security

Cập nhật một package cụ thể:

sudo dnf update openssl

Output thường cho biết package, version mới và repository. Hãy lưu log vào ticket:

sudo dnf update --security 2>&1 | tee /var/log/patch-$(date +%F).log

6. Chiến lược rollout an toàn

Đừng cập nhật tất cả server cùng lúc. Một mô hình an toàn:

Lab/staging: test bản vá trên môi trường giống production nhất có thể.
Canary: cập nhật 1-2 server ít rủi ro trong cụm.
Batch nhỏ: 10-20% fleet mỗi lượt, theo availability zone hoặc role.
Pause quan sát: theo dõi error rate, latency, CPU, memory, log.
Rollout toàn bộ: chỉ tiếp tục khi batch trước đạt tiêu chí nghiệm thu.

Với load balancer, hãy drain node trước khi cập nhật:

# Ví dụ ý tưởng, tùy load balancer thực tế
mark-node-drain web-01
ssh web-01 'sudo apt update && sudo apt upgrade -y && sudo reboot'
wait-node-healthy web-01
mark-node-active web-01

7. Kiểm tra sau cập nhật

Sau update/reboot, đừng chỉ thấy SSH vào được rồi kết luận thành công. Chạy checklist:

uname -a
uptime
systemctl --failed
systemctl status nginx --no-pager
journalctl -p warning -S -30m --no-pager
ss -tulpn
curl -I http://127.0.0.1/

Giải thích:

uname -a: xác nhận kernel mới nếu có reboot.
systemctl --failed: phát hiện service lỗi.
journalctl -p warning -S -30m: xem cảnh báo/lỗi sau maintenance.
curl -I: kiểm tra HTTP local trước khi mở node lại cho traffic.

Nếu là ứng dụng web, cần kiểm tra thêm synthetic transaction: login, đọc dữ liệu, ghi dữ liệu test, gọi API quan trọng.

8. Xử lý lỗi thường gặp

8.1. /boot đầy, kernel update fail

Kiểm tra:

df -h /boot
dpkg -l 'linux-image*' | grep '^ii'

Trên Ubuntu, có thể dọn kernel cũ bằng:

sudo apt autoremove --purge

Không xóa kernel đang chạy. Luôn kiểm tra uname -r trước.

8.2. Package bị giữ lại

apt-mark showhold
sudo apt-mark unhold package-name

Chỉ unhold khi biết vì sao package bị hold. Nhiều hệ thống production hold version vì tương thích ứng dụng.

8.3. Service không khởi động sau update

systemctl status service-name --no-pager
journalctl -u service-name -S -1h --no-pager
systemd-analyze verify /etc/systemd/system/service-name.service

Nếu lỗi do config deprecated, đọc release note và sửa config. Nếu lỗi do package regression, cân nhắc rollback package hoặc restore snapshot.

8.4. Kernel mới lỗi sau reboot

Trong console của hypervisor/cloud, boot vào kernel cũ từ GRUB. Sau khi vào được hệ thống, đặt kernel ổn định làm mặc định hoặc gỡ kernel lỗi theo quy trình của distro.

9. Tự động hóa nhưng không buông kiểm soát

Công cụ như Ansible, Landscape, Foreman/Katello, Uyuni, AWS Systems Manager Patch Manager hoặc unattended-upgrades giúp giảm thao tác tay. Nhưng production vẫn cần policy:

Nhóm server nào auto security patch được?
Gói nào bị exclude?
Maintenance window là khi nào?
Reboot tự động hay cần phê duyệt?
Log và báo cáo compliance gửi về đâu?

Ví dụ Ansible đơn giản cho Debian/Ubuntu:

- hosts: web
  serial: 2
  become: yes
  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes
        cache_valid_time: 3600
    - name: Upgrade packages
      apt:
        upgrade: safe
    - name: Check failed units
      command: systemctl --failed --no-legend
      register: failed_units
      changed_when: false
    - debug:
        var: failed_units.stdout_lines

serial: 2 giúp cập nhật từng nhóm nhỏ thay vì toàn bộ host cùng lúc.

10. Checklist nghiệm thu production

Đã xác định danh sách server, owner, mức độ quan trọng và maintenance window.
Đã đọc advisory/changelog cho gói quan trọng.
Đã test trên lab/staging hoặc canary.
Đã có snapshot/backup và rollback plan rõ ràng.
Đã kiểm tra dung lượng /boot, /var, trạng thái service trước update.
Đã cập nhật theo batch, có thời gian quan sát giữa các batch.
Đã reboot khi cần và xác nhận kernel/service đúng trạng thái.
Đã kiểm tra log, metric, synthetic transaction và cảnh báo monitoring.
Đã lưu output lệnh, thời gian, người thực hiện vào ticket/change record.
Đã cập nhật inventory/compliance report sau khi hoàn tất.

11. Bài lab cuối bài

Dựng một VM Ubuntu hoặc Rocky Linux và thực hành:

Tạo snapshot VM.
Ghi nhận trạng thái trước update bằng các lệnh inventory.
Cập nhật một package cụ thể, sau đó cập nhật toàn bộ security patch.
Reboot nếu có kernel mới.
Kiểm tra systemctl --failed, journalctl và service chính.
Giả lập lỗi bằng cách sửa sai config của một service test, rồi dùng log để tìm nguyên nhân.
Restore snapshot để hiểu thời gian rollback thực tế.

Sau lab, hãy viết lại runbook theo môi trường của bạn: distro, cloud provider, backup tool, monitoring và quy trình phê duyệt.

Kết luận

Linux patch management trong production là một năng lực cốt lõi của sysadmin. Cập nhật nhanh giúp giảm rủi ro bảo mật, nhưng cập nhật có quy trình mới giúp dịch vụ ổn định. Hãy bắt đầu bằng inventory, phân loại rủi ro, test trên staging/canary, rollout theo batch, kiểm tra kỹ sau cập nhật và luôn có rollback plan. Khi quy trình này được lặp lại đều đặn, patching không còn là “đêm bảo trì căng thẳng” mà trở thành một phần bình thường của vận hành hệ thống.