1. KIỂM TRA PHẦN CỨNG (OUT-OF-BAND MANAGEMENT)
Mục tiêu: Đảm bảo platform vật lý không
báo lỗi trước khi check mức OS.
- Kiểm tra: Login Web UI
(iDRAC/iLO/ILOM/iRMC). Check tab Dashboard/Logs (PSU, Fan, RAM ECC, Disk).
- Giải pháp xử lý khi có lỗi
(Fault/Critical):
+
Lỗi RAM/Nguồn/Quạt/Mainboard: Xuất log hệ thống (TSR/SupportAssist với Dell,
AHS với HP, Snapshot với Oracle ILOM). Mở ticket gửi vendor hoặc đối tác bảo
hành để thay thế linh kiện (Part Replacement).
+
Lỗi Ổ cứng vật lý (Predictive Failure hoặc Failed):
* Nếu ổ nằm trong mảng RAID có dự phòng (RAID 1, 5, 6, 10): Tiến hành cắm
nóng (hot-swap) ổ cứng mới cùng loại.
* Theo dõi tiến trình "Rebuilding" trên giao diện quản trị cho
đến khi báo "Optimal".
* Tuyệt đối không rút 2 ổ cứng cùng lúc nếu không nắm rõ cấu hình RAID.
2. KIỂM TRA TÀI NGUYÊN OS (CPU
& RAM)
Mục tiêu: Đánh giá mức
độ chịu tải, phát hiện bottleneck tài nguyên.
- Tải CPU (Load Average > số core)
& Process treo:
+
Lệnh: uptime, htop, top -c
+
Giải pháp:
* Dùng 'htop' xác định PID của process đang ngốn CPU.
* Nếu là app nghiệp vụ bị treo (loop): Báo Dev/App team kiểm tra thread,
hoặc thực hiện restart service theo SOP của từng app (VD: systemctl restart
nginx, hoặc kill -9 PID).
* Nếu là tiến trình lạ (nghi ngờ malware/miner): Cô lập mạng, check
source thực thi bằng "ls -l /proc/<PID>/exe" và xóa file.
- Tình trạng RAM & Swap (RAM available
< 10%, Swap tăng):
+
Lệnh: free -m
+
Giải pháp:
* Xử lý tạm thời (Giải phóng Cache OS): Chạy lệnh "sync; echo 3
> /proc/sys/vm/drop_caches" để giải phóng pagecache, dentries và
inodes.
* Xử lý triệt để: Kiểm tra xem app nào gây memory leak. Nếu là Java,
check lại tham số JVM Heap (Xmx, Xms). Nếu server thực sự thiếu RAM, lập kế hoạch
xin thêm resource (Scale-up).
3. KIỂM TRA LƯU TRỮ VÀ I/O DISK
Mục tiêu: Đảm bảo
không bị tràn ổ cứng và IOPS đáp ứng đủ nhu cầu.
- Dung lượng phân vùng (Disk Space >
85%):
+
Lệnh: df -hT
+
Giải pháp:
* Truy tìm file lớn: "find /var -type f -size +1G -exec ls -lh {}
\;" hoặc dùng "du -sh /* | sort -hr".
* Dọn dẹp: Zip/tar các file log cũ đẩy sang server backup.
* Lưu ý cực kỳ quan trọng: TUYỆT ĐỐI KHÔNG dùng lệnh "rm" xóa
file log ứng dụng đang chạy (sẽ gây treo app hoặc OS không nhả dung lượng). Phải
làm rỗng file bằng lệnh: "> /path/to/file.log" hoặc "truncate
-s 0 /path/to/file.log".
- Số lượng Inode cạn kiệt (IUse% >
90%):
+
Lệnh: df -i
+
Giải pháp: Lỗi này do có thư mục chứa hàng triệu file rác/nhỏ. Dùng lệnh
"find / -xdev -type f | cut -d "/" -f 2 | sort | uniq -c" để
dò tìm thư mục nào đang chứa nhiều file nhất và tiến hành xóa theo batch (VD:
find /var/spool/postfix/maildrop -type f -mtime +5 -delete).
- Hiệu năng Disk I/O (%util > 90%,
await cao):
+
Lệnh: iostat -dxz 1 5, iotop
+
Giải pháp: Dùng "iotop" xem process nào đang cày ổ cứng. Nếu là batch
job/backup, dời lịch chạy sang giờ thấp điểm (đêm). Nếu là SAN storage, check lại
đường truyền quang (Multipath, Zoning) xem có bị đứt 1 path gây nghẽn không.
4. KIỂM TRA LOG HỆ THỐNG OS
Mục tiêu: Truy vết
nguyên nhân khi có sự cố ngầm.
- Lỗi dmesg (OOM
Killer, I/O Error):
+ Lệnh: dmesg -T | egrep -i
'error|warn|fault|killed|fail'
+ Giải pháp:
* "Out of memory: Kill process": OS đã tự động kill app. Cần
tăng RAM hoặc limit memory của app đó lại.
* "I/O error": Ổ cứng vật lý có bad sector hoặc cáp lỏng. Lên
kế hoạch downtime, umount phân vùng và chạy "fsck -y /dev/sdX" để sửa
lỗi file system, chuẩn bị sẵn phương án thay ổ cứng.
- Lỗi Service (Systemd):
+
Lệnh: systemctl --failed, journalctl -u <service_name>
+
Giải pháp: Đọc dòng log cuối của service xem báo lỗi gì (thường do sai cú pháp
file config, sai permission thư mục, hoặc port bị chiếm). Sửa lỗi cấu hình, chạy
"systemctl daemon-reload" và "systemctl start
<service>".
5. KIỂM TRA MẠNG VÀ KẾT NỐI SAN (NETWORK & SAN
MULTIPATH)
Mục tiêu: Đảm bảo luồng traffic mạng ổn định,
không rớt gói tin và đường truyền quang (FC SAN) xuống tủ đĩa không bị đứt
path.
- Trạng thái Card mạng (NIC / Bonding)
& Port:
+
Lệnh: ip -s link show, ethtool <tên_card>, ss -tulnp
+
Đánh giá:
* "ip -s link": Nhìn cột RX/TX. Nếu thông số
"errors" hoặc "dropped" > 0 và tăng liên tục -> Card
mạng, cáp hoặc port trên Switch (Cisco/Juniper...) bị lỗi vật lý hoặc nghẽn.
* "ethtool": Đảm bảo "Speed" đúng thiết kế
(1G/10G/25G) và "Link detected: yes".
* "ss -tulnp": Các port dịch vụ core (22, 80, 443, 1521, v.v.)
phải ở trạng thái LISTEN.
+
Giải pháp: Rút/cắm lại cáp, đổi port Switch, check lại cấu hình LACP/Teaming
trên OS và Switch. Nếu rớt port dịch vụ, check lại iptables/firewalld hoặc
restart app.
- Kết nối SAN Storage (Multipath):
+
Lệnh: multipath -ll
+
Đánh giá: Tất cả các LUN/Volume phải hiển thị đủ số lượng path (ví dụ 2 hoặc 4
path) và trạng thái phải là "active/ready". Báo "failed" hoặc
"faulty" là đứt cáp quang hoặc chết cổng HBA / SAN Switch.
+
Giải pháp: Check đèn cảnh báo trên SAN Switch, check cáp quang, rescan lại HBA
bằng lệnh "echo 1 > /sys/class/fc_host/hostX/issue_lip".
6. KIỂM TRA ĐỒNG BỘ THỜI GIAN (TIME SYNCHRONIZATION)
Mục tiêu: Bắt buộc chuẩn xác tới từng
miligiây, đặc biệt quan trọng với các hệ thống giao dịch, cước, database
(Oracle) và cluster.
- Dịch vụ NTP/Chrony:
+
Lệnh: chronyc sources -v (với RHEL/CentOS 7+) hoặc ntpq -p
+
Đánh giá:
* Cột "State" (hoặc dấu * đầu dòng) chỉ định server đang sync.
* Độ lệch thời gian (Offset) phải ở mức micro/milisecond. Nếu lệch vài
giây hoặc vài phút, database cluster có nguy cơ split-brain hoặc reject giao dịch.
+
Giải pháp: Nếu mất sync, chạy "systemctl restart chronyd" hoặc ép
sync ngay lập tức bằng "chronyc makestep". Check lại rule firewall
port 123 UDP nối ra NTP Server nội bộ.
7. KIỂM TRA HA VÀ CÂN BẰNG TẢI (HAPROXY / KEEPALIVED)
Mục tiêu: Đảm bảo tính sẵn sàng cao (High
Availability), không có node nào trong cụm bị rớt khỏi pool cân bằng tải.
- Dịch vụ Cân bằng tải & Cluster IP
(VIP):
+
Lệnh: systemctl status haproxy, ip a | grep <VIP>
+
Đánh giá: HAProxy phải đang active. Lệnh "ip a" phải thấy IP ảo (VIP)
đang nằm trên con Master hiện tại.
+
Giải pháp:
* Truy cập trang HAProxy Stats (nếu có cấu hình) để xem backend nào đang
báo DOWN đỏ.
* Check file config xem có sai syntax không: "haproxy -c -f
/etc/haproxy/haproxy.cfg".
* Nếu VIP xuất hiện trên cả 2 node (Split-brain), rớt mạng Heartbeat giữa
2 server -> Phải tắt Keepalived ở node Backup và check cáp mạng chéo nối 2
server.
8. KIỂM TRA MÔI TRƯỜNG CONTAINER (DOCKER / OPENSHIFT)
Mục tiêu: Rà soát trạng thái các dịch vụ
chạy dưới dạng Microservices/Containers.
- Docker Engine & Containers:
+
Lệnh: docker ps -a, docker stats --no-stream
+
Đánh giá: Lọc các container đang "Exited" hoặc "Restarting"
liên tục. Lệnh "docker stats" giúp soi CPU/RAM của từng container.
Tràn ổ cứng do Docker Log là lỗi kinh điển cần check.
+
Giải pháp:
* Đọc log container chết: "docker logs --tail 50
<container_id>".
* Xóa log/ảnh rác giải phóng ổ đĩa: "docker system prune -a
--volumes" (Thận trọng khi dùng, phải chắc chắn không xóa nhầm volume
data).
9. KIỂM TRA CRONJOB & BACKUP TIẾN TRÌNH
Mục tiêu: Đảm bảo các script tự động
(backup, dọn dẹp log, chốt số liệu) chạy đúng giờ.
- Lập lịch hệ thống:
+
Lệnh: crontab -l, tail -n 50 /var/log/cron
+
Đánh giá: Đối chiếu log xem các job backup DB, rsync file có được kích hoạt
thành công vào ban đêm không.
+
Giải pháp: Nếu crontab không chạy, check lại đường dẫn tuyệt đối trong script
(cron không nhận biến môi trường giống user bình thường). Khuyến nghị luôn
redirect output log ra file khi viết cron (VD: 0 2 * * * /opt/scripts/backup.sh
>> /var/log/backup.log 2>&1).
10. KIỂM TRA VÀ XỬ LÝ LỖI FILE SYSTEM & MOUNTPOINT
Mục tiêu: Đảm bảo tính toàn vẹn của dữ liệu,
xử lý nhanh các sự cố mất kết nối ổ đĩa hoặc lỗi cấu trúc phân vùng.
- Lỗi "Read-only file system":
+
Hiện tượng: Ứng dụng báo lỗi không thể ghi log, chạy lệnh "touch
/path/test.txt" báo Read-only. Phân vùng tự động chuyển sang chế độ RO.
+
Nguyên nhân: OS phát hiện lỗi cấu trúc (corruption) trên disk, hoặc mất kết nối
đột ngột xuống mạng SAN (FC/iSCSI) nên tự lock ổ lại để bảo vệ dữ liệu.
+
Giải pháp triệt để:
* Tuyệt đối KHÔNG chạy lệnh fsck khi phân vùng đang được mount (sẽ làm hỏng
hoàn toàn data).
* Phải umount phân vùng đó: "umount /mountpoint" (nếu báo
device busy thì dùng "fuser -km /mountpoint" để kill các process đang
bám vào ổ).
* Chạy lệnh sửa lỗi: "fsck -y /dev/sdX" (với định dạng ext4)
hoặc "xfs_repair /dev/sdX" (với định dạng xfs).
* Sau khi sửa xong, mount lại: "mount -a".
- Lỗi "Stale file handle" (Treo
NFS/CIFS Mount):
+
Hiện tượng: Gõ lệnh "df -h" bị treo cứng không ra kết quả. Truy cập
vào thư mục mount báo lỗi Stale file handle.
+
Nguyên nhân: Server NFS đích bị reboot hoặc rớt mạng, khiến kết nối trên Client
bị kẹt.
+
Giải pháp: Dùng cờ lazy unmount để gỡ ép buộc: "umount -l
/mountpoint". Sau đó check lại ping đến NFS Server và chạy "mount
-a" để map lại.
- Lỗi mất phân vùng LVM sau khi Reboot:
+
Lệnh kiểm tra: pvs, vgs, lvs, lsblk, cat /etc/fstab
+
Hiện tượng: Khởi động lại server bị văng vào "Emergency Mode" hoặc mất
phân vùng data.
+
Giải pháp:
* Lỗi fstab: Kiểm tra file /etc/fstab xem có mount nhầm UUID hoặc sai cú
pháp không. Bỏ comment (#) dòng lỗi để boot tạm vào OS.
* LVM không tự active: Chạy lệnh "vgchange -ay" để kích hoạt tất
cả Volume Group, sau đó "mount -a".
11. CÁC CÔNG VIỆC VẬN HÀNH THƯỜNG NGÀY (DAILY ROUTINE
CHECKLIST)
Mục tiêu: Quy trình chuẩn (SOP) dành cho kỹ
sư vận hành đầu ca, đảm bảo không bỏ sót các rủi ro tiềm ẩn.
- [ ] Check System Dashboard (Đầu ca):
+
Mở hệ thống Monitor tập trung (Zabbix, Prometheus/Grafana, SolarWinds).
+
Rà soát toàn bộ các Event báo đỏ (Critical/High) trong đêm. Phân loại sự cố phần
cứng, đường truyền hay app để báo cáo/phối hợp xử lý.
- [ ] Check trạng thái Backup (Cực kỳ quan
trọng):
+
Kiểm tra log của các cronjob chạy script backup (Database dump, rsync source
code) đêm hôm trước.
+
So sánh dung lượng file backup: Lệnh "ls -lh /path/to/backup". Nếu
file backup hôm nay tự nhiên dung lượng nhỏ đi bất thường (VD: Mọi ngày 50GB,
nay còn 1KB) -> Script backup đã bị lỗi, cần chạy tay lại ngay lập tức.
- [ ] Housekeeping & Dọn dẹp không
gian đĩa:
+
Check các thư mục log của OS (/var/log/messages, /var/log/secure) và App (VD:
WebLogic, Oracle, Tomcat, Nginx).
+
Nén (tar.gz) và move các log cũ (trên 30 ngày) sang server lưu trữ.
+
Làm rỗng (Truncate) các file log đang phình to đột biến: ">
/path/to/app.log".
- [ ] Rà soát Security & Access (Cuối
ca):
+
Check nhanh "last -a" để xem có IP lạ nào login thành công vào
root/admin không.
+
Check "history" lệnh của các user vận hành xem có ai thao tác nhầm lệnh
nguy hiểm ("rm -rf", "chmod 777") không.
- [ ] Ghi chép Logbook / Bàn giao ca:
+
Lập danh sách các thay đổi cấu hình (Change Management) đã thực hiện trong ngày
(VD: Mở port nào, thêm rule iptables nào, restart dịch vụ nào lúc mấy giờ).
+
Cập nhật vào hệ thống Ticket hoặc Wiki nội bộ để người ca sau nắm lịch sử hệ thống.
12. KIỂM TRA BẢO MẬT VÀ TƯỜNG LỬA (FIREWALL & SELINUX)
Mục tiêu: Đảm bảo luồng mạng không bị chặn
đột ngột ở mức OS và các chính sách bảo mật không cản trở ứng dụng (đặc biệt là
các service phức tạp như Oracle, WebLogic).
- Kiểm tra Tường lửa (Firewalld /
Iptables):
+
Lệnh: firewall-cmd --list-all (hoặc iptables -vnL)
+
Hiện tượng lỗi: Ứng dụng báo connection refused hoặc timeout dù port đã LISTEN
(ss -tulnp thấy có port).
+
Giải pháp:
* Mở port tạm thời để test: "firewall-cmd --add-port=1521/tcp"
(Không có cờ --permanent).
* Mở port vĩnh viễn (sau khi test OK): "firewall-cmd
--add-port=1521/tcp --permanent" và "firewall-cmd --reload".
* Tránh tình trạng flush iptables bừa bãi ("iptables -F") trên
môi trường production vì có thể làm sập các rule NAT hoặc Docker routing.
- Kiểm tra SELinux (Security-Enhanced
Linux):
+
Lệnh: getenforce, sestatus
+
Hiện tượng lỗi: Service khởi động thất bại, báo lỗi "Permission
denied" dù đã set chmod 777 cho thư mục (rất hay gặp khi cấu hình
Nginx/Apache đọc file ngoài thư mục mặc định).
+
Giải pháp:
* Đọc log kiểm tra xem SELinux có đang block không: "grep AVC
/var/log/audit/audit.log" hoặc "cat /var/log/messages | grep
setroubleshoot".
* Xử lý tạm thời: Chuyển SELinux sang chế độ cảnh báo "setenforce
0" để xác định đúng nguyên nhân do SELinux.
* Xử lý triệt để: Khôi phục lại context chuẩn bằng lệnh "restorecon
-Rv /đường/dẫn" hoặc dùng "audit2allow" để tạo rule cho phép app
hoạt động mà không cần tắt hẳn SELinux.
13. QUẢN LÝ NGƯỜI DÙNG, PHÂN QUYỀN VÀ TRUY CẬP (USERS,
SUDO, SSH)
Mục tiêu: Rà soát quyền truy cập trước khi
bàn giao, đảm bảo không có backdoor hoặc user lạ có quyền cao nhất (root).
- Rà soát tài khoản hệ thống (User &
Group):
+
Lệnh: awk -F: '($3 == "0") {print}' /etc/passwd
+
Đánh giá: Chạy lệnh trên để kiểm tra xem có tài khoản nào ngoài
"root" đang bị gán UID = 0 (quyền tối thượng) hay không. Bất kỳ user
lạ nào có UID 0 đều là rủi ro bảo mật nghiêm trọng.
+
Giải pháp: Khóa ngay user nghi ngờ bằng lệnh "passwd -l
<username>" hoặc xóa bỏ nếu xác nhận là tài khoản rác.
- Rà soát quyền Sudo (Sudoers):
+
Lệnh: visudo (để xem cấu hình /etc/sudoers)
+
Đánh giá: Kiểm tra các dòng không yêu cầu password (NOPASSWD). Rà soát xem các
user vận hành có đang được cấp full quyền "ALL=(ALL) ALL" hay không.
+
Giải pháp: Thu hồi quyền "ALL" của các user không cần thiết, chỉ cấp
quyền chạy chính xác các lệnh ứng dụng (VD: systemctl restart tomcat).
- Bảo mật SSH:
+
File cấu hình: /etc/ssh/sshd_config
+
Kiểm tra: Đảm bảo "PermitRootLogin" được set là "no" hoặc
"prohibit-password" (chỉ cho phép login bằng key). Cấm root login trực
tiếp bằng mật khẩu để chống brute-force.
+
Hành động bàn giao: Yêu cầu người nhận bàn giao add SSH Public Key của họ vào
"~/.ssh/authorized_keys" của user vận hành, sau đó xóa key cũ của
mình.
14. KIỂM TRA THÔNG SỐ KERNEL VÀ GIỚI HẠN TÀI NGUYÊN
(SYSCTL & ULIMIT)
Mục tiêu: Đảm bảo OS được tuning đúng mức
để chịu tải cao, không bị crash các hệ thống core (Billing, Database,
Middleware) do chạm ngưỡng giới hạn mặc định của Linux.
- Kiểm tra User Limits (Ulimit):
+
Lệnh: ulimit -a (xem hiện tại), cat /etc/security/limits.conf (cấu hình cứng).
+
Hiện tượng lỗi: App (như Java, WebLogic) văng lỗi "Too many open
files" hoặc "Cannot create new native thread".
+
Giải pháp: Tăng thông số "nofile" (số lượng file mở đồng thời) và
"nproc" (số lượng process/thread tối đa) trong limits.conf cho user
chạy app. (VD: "oracle soft nofile 65536"). Yêu cầu user logout và
login lại để nhận cấu hình mới.
- Kiểm tra Kernel Parameters (Sysctl):
+
Lệnh: sysctl -p, cat /etc/sysctl.conf
+
Hiện tượng lỗi: Database (Oracle) không cấp phát được vùng nhớ lớn (SGA), hoặc
hệ thống mạng bị cạn kiệt cổng kết nối TCP (TCP Time Wait cao).
+
Giải pháp:
* Tuning TCP/IP: Bổ sung các thông số giảm thời gian giữ kết nối như
"net.ipv4.tcp_fin_timeout", "net.ipv4.tcp_tw_reuse" để nhả
port nhanh chóng.
* Tuning Memory: Đảm bảo "kernel.shmmax" và
"kernel.shmall" đủ lớn theo khuyến cáo của vendor DB. Chạy
"sysctl -p" để áp dụng ngay không cần reboot.
15. QUẢN LÝ GÓI PHẦN MỀM VÀ CẬP NHẬT (PACKAGE MANAGEMENT)
Mục tiêu: Kiểm soát các bản vá lỗi
(Patching) và đảm bảo tính đồng nhất của hệ điều hành.
- Cập nhật và Rollback (Yum/Dnf/Apt):
+
Lệnh check: yum check-update hoặc apt list --upgradable
+
Lệnh lịch sử: yum history
+
Đánh giá/Giải pháp:
* Khi cài mới hoặc update package, luôn check lịch sử "yum
history".
* Nếu một bản vá kernel hoặc thư viện glibc làm chết ứng dụng, lập tức
dùng lệnh "yum history undo <ID_giao_dịch>" để rollback (hạ cấp)
về phiên bản trước đó.
* Quản lý Repository: Kiểm tra các repo rác trong
"/etc/yum.repos.d/", disable các repo không cần thiết để tránh xung đột
package khi update hệ thống.
16. KIỂM TRA MÔI TRƯỜNG ẢO HÓA (NẾU CHẠY TRÊN VMWARE/ESXI)
Mục tiêu: Đảm bảo các máy ảo (VM) không bị
treo do ngốn tài nguyên từ hypervisor hoặc quên xóa Snapshot gây full
Datastore.
- Kiểm tra VMware Tools & Trạng thái
VM:
+ Lệnh: systemctl status vmtoolsd (trên OS) hoặc check
trên vCenter.
+ Đánh giá/Giải pháp: vmtoolsd phải đang chạy
để vCenter lấy được metric (RAM/CPU) và thực hiện graceful shutdown. Nếu
lỗi, chạy "yum reinstall open-vm-tools".
- Quản lý Snapshot:
+
Hiện tượng: Hệ thống lưu trữ bị chậm đột ngột (high latency), I/O wait trên OS
tăng vọt.
+
Giải pháp: Rà soát trên vCenter xem có Snapshot nào đang tồn tại quá 3 ngày
không (đặc biệt sau các đợt patching/deploy). Việc gom (Consolidate) Snapshot lớn
lúc cao điểm có thể làm treo VM, cần lên lịch làm vào ban đêm.
17. CẤU HÌNH MỨC OS CHO DATABASE & MIDDLEWARE (ORACLE
/ WEBLOGIC)
Mục tiêu: Bàn giao lại các tinh chỉnh đặc
thù (hardcode) tại mức hệ điều hành dành riêng cho các hệ thống Core, tính cước
hoặc thanh khoản.
- Quản lý đĩa Raw/ASM cho Oracle Database:
+
Lệnh: ls -l /dev/mapper/ | grep asm, cat
/etc/udev/rules.d/99-oracle-asmdevices.rules
+
Đánh giá: Oracle RAC thường dùng ASM trên các đĩa raw được cấu hình qua udev hoặc
ASMLib/AFD.
+
Giải pháp: Khi thêm LUN mới từ tủ SAN, người vận hành phải chạy "multipath
-ll" lấy WWID, sau đó cập nhật vào file udev rules và chạy "udevadm
trigger" để mapping quyền (owner: oracle:dba) trước khi báo cho team DBA
nhận đĩa. Tuyệt đối không format đĩa này bằng fdisk/mkfs.
- Giám sát tiến trình Middleware
(WebLogic/Tomcat):
+
Lệnh: ps -ef | grep weblogic, netstat -anp | grep <port_admin_server>
+
Hiện tượng/Giải pháp: Nếu WebLogic NodeManager hoặc AdminServer bị crash do vọt
Heap Memory (OutofMemoryError), cần check file log "AdminServer.log"
hoặc các file ".out". Bàn giao rõ đường dẫn chứa các file
setDomainEnv.sh để người sau biết chỗ tăng/giảm tham số Xms, Xmx.
18. ROUTING TẠI LOCAL OS & VLAN TAGGING
Mục tiêu: Đảm bảo luồng định tuyến mạng
tĩnh (Static Route) đến các dải mạng nghiệp vụ không bị mất sau khi reboot.
- Kiểm tra Static Route:
+
Lệnh: ip route show, cat /etc/sysconfig/network-scripts/route-<interface>
+
Hiện tượng: Ping gateway và các server cùng dải báo OK, nhưng không kết nối được
đến các mạng nội bộ khác hoặc mạng Core/Cisco Switch lớp trên.
+
Giải pháp: Đảm bảo các route tĩnh được ghi cứng vào file "route-ethX"
(với RedHat/CentOS) hoặc netplan (với Ubuntu). Nếu chỉ gõ lệnh "ip route
add" bằng tay, khi reboot hoặc restart network, kết nối sẽ đứt toàn bộ.
- Sub-interface & VLAN:
+
Lệnh: ip a | grep '@' (VD: eth0.100@eth0)
+
Đánh giá: Bàn giao rõ các cổng mạng vật lý nào đang cấu hình trunking từ Switch
lên và được bóc tag VLAN trực tiếp trên Linux.
19. KIỂM TRA CHỨNG CHỈ BẢO MẬT (SSL/TLS CERTIFICATES)
Mục tiêu: Không để xảy ra downtime hệ thống
do chứng chỉ số nội bộ hoặc public bị hết hạn.
- Rà soát hạn dùng Certificate trên
HAProxy / Web Server:
+
Lệnh: openssl x509 -enddate -noout -in /đường/dẫn/tới/cert.pem
+
Đánh giá/Giải pháp: Liệt kê toàn bộ các đường dẫn lưu file chứng chỉ đang gắn
trên HAProxy, Nginx hoặc OpenShift Ingress. Cài đặt các cảnh báo cronjob chạy
script check hạn cert trước 30 ngày để gia hạn (Renew). Nếu cert hết hạn, toàn
bộ kết nối HTTPS từ Client/API sẽ bị chặn ngay lập tức.
20. KIỂM TRA HỆ THỐNG TRUYỀN NHẬN DỮ LIỆU (SFTP / CHROOT
JAIL)
Mục tiêu: Đảm bảo luồng đẩy/kéo file (ví dụ
file giao dịch, file CDR cước) từ các đối tác hoặc hệ thống vệ tinh diễn ra
xuyên suốt, an toàn.
- Giám sát cấu hình SFTP nội bộ:
+
File kiểm tra: /etc/ssh/sshd_config (phần Match Group sftp_users)
+
Hiện tượng: Đối tác báo không đẩy được file hoặc login thành công nhưng thấy
toàn bộ thư mục root (/) của server.
+
Giải pháp bàn giao: Đảm bảo các user SFTP bị nhốt đúng vào thư mục cấu hình
(ChrootDirectory /data/sftp/%u). Cấu hình quyền thư mục chroot bắt buộc phải là
root:root và chmod 755, nếu sai quyền, SFTP sẽ văng lỗi "Broken pipe"
ngay khi login.
21. XỬ LÝ SỰ CỐ PHÂN GIẢI TÊN MIỀN (DNS & HOSTS LOCAL)
- Hiện tượng: Ping IP thì thông, nhưng App
gọi API (dạng domain) sang hệ thống đối tác hoặc server khác thì báo lỗi
"Could not resolve host".
- Lệnh kiểm tra: nslookup <tên_miền>,
cat /etc/hosts, cat /etc/resolv.conf
- Giải pháp xử lý:
+
Nếu "nslookup" không ra IP: Sửa nhanh nhất là chui vào file
"/etc/hosts", gõ cứng 1 dòng mapping: "<IP_đích> <tên_miền_đích>" rồi lưu lại.
+
Nếu có máy chủ DNS nội bộ: Check file "/etc/resolv.conf" xem dòng
"nameserver <IP>" có trỏ đúng IP của DNS Server công ty không.
22. KỸ NĂNG TÌM KIẾM FILE VÀ CẤU HÌNH (FIND & GREP)
- Hiện tượng: Người mới không biết thư mục
cài App, file config, hay file log nằm ở đâu.
- Lệnh xử lý:
+
Tìm 1 file theo tên (VD nginx.conf): "find / -type f -name
'*nginx.conf*'"
+
Tìm cấu hình Port/IP nằm ở file nào: "grep -rn '8080' /etc /opt /var"
(Lục nội dung mọi file xem chứa chữ 8080).
+
Tìm các file rác lớn ăn mòn ổ đĩa: "find /var -type f -size +1G -exec ls
-lh {} \;"
23. XỬ LÝ LỖI BỊ KHÓA TIẾN TRÌNH CÀI ĐẶT (YUM / APT LOCK)
- Hiện tượng: Đang cần cài phần mềm (VD:
yum install telnet) thì báo lỗi "Another app is currently holding the yum
lock".
- Lệnh kiểm tra: ps
-ef | grep yum
- Giải pháp: Do có
người đang cài dở thì rớt mạng. Dùng "ps -ef | grep yum" lấy số PID
đang treo. Chạy "kill -9 <PID>". Nếu vẫn khóa, chạy xóa file
rác: "rm -f /var/run/yum.pid" (với CentOS) rồi cài lại.
24. NÉN, CHUYỂN DỮ LIỆU &
BACKUP THỦ CÔNG (TAR / SCP / RSYNC)
- Hiện tượng: Ổ đĩa đầy
(99%), cần nén gấp log và ném sang một Server Backup khác để làm trống đĩa.
- Lệnh xử lý:
+ Nén nhỏ dung lượng: "tar -czvf
log_thang_3.tar.gz /var/log/app_logs/thang_3/"
+ Bắn file sang Server khác: "scp
log_thang_3.tar.gz user_backup@192.168.1.100:/thu_muc_luu_tru/"
+ Nếu file quá lớn hoặc mạng chập chờn: Dùng
rsync để lỡ rớt mạng copy nối tiếp được: "rsync -avP file_khung.tar.gz
user@192.168.1.100:/dich/".
25. QUẢN LÝ KHỞI ĐỘNG DỊCH VỤ
(AUTO-START)
- Hiện tượng: Server
reboot lại, Ping thấy lên rồi nhưng App/Web/DB không tự lên.
- Lệnh kiểm tra: systemctl is-enabled
<tên_service>
- Giải pháp: Nếu kết quả là
"disabled", app chưa được tự động chạy cùng OS. Chạy lệnh
"systemctl enable <tên_service>" để đăng ký nó vào chu trình
boot. Dặn người mới rà soát lại toàn bộ dịch vụ core (Oracle, Nginx, Docker)
xem đã "enabled" chưa.
26. LẤY THÔNG TIN HỆ THỐNG GẤP ĐỂ
MỞ TICKET (SYSTEM INFO)
- Hiện tượng: Nửa đêm
chết phần cứng, cần thông tin để gọi Vendor bảo hành.
- Lệnh xử lý (Lưu ý
cho người mới):
+ Xem Service Tag
/ Số Serial: "dmidecode -s system-serial-number" (Đọc mã này cho tổng
đài).
+
Xem Model máy chủ: "dmidecode -s system-product-name" (VD trả về
PowerEdge R740).
+
Xem phiên bản OS: "cat /etc/os-release" hoặc "cat
/etc/redhat-release".
TƯ VẤN: Click Here hoặc Hotline/Zalo 090.29.12.888
=============================
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
