❤️ AZDIGI chính thức cập nhật hệ thống blog mới hoàn chỉnh. Tuy nhiên có thể một số bài viết bị sai lệch hình ảnh, hãy ấn nút Báo cáo bài viết ở cuối bài để AZDIGI cập nhật trong thời gian nhanh nhất. Chân thành cám ơn.

Bạn quản lý 5 cái VPS: production, staging, database, hai cái app server. Mỗi lần cần kiểm tra gì đó, bạn phải nhớ IP, username, SSH key nào dùng cho server nào, rồi mở terminal, gõ lệnh, lặp lại cho từng server. Nhân lên nếu bạn quản lý 10, 20 servers — và chắc chắn sẽ có lúc bạn nhầm server production với staging.

Trong doanh nghiệp lớn, người ta dùng CMDB (Configuration Management Database) — một hệ thống trung tâm ghi lại tất cả thông tin về hạ tầng: server nào chạy gì, IP bao nhiêu, ai quản lý, kết nối với nhau ra sao. Nghe phức tạp, nhưng bản chất nó chỉ là một nơi duy nhất chứa mọi thông tin về server của bạn.

Bài viết này hướng dẫn bạn biến OpenClaw thành CMDB cá nhân. Từ việc chuẩn bị kết nối SSH an toàn, ghi thông tin server, đặt rules giới hạn quyền để bot không phá server production, đến sử dụng hàng ngày và tự động hoá. Đây là phần bạn nên đọc kỹ nhất nếu đang dùng OpenClaw để quản lý server thật.

Quản lý nhiều VPS từ một nơi với OpenClaw

Chuẩn bị kết nối SSH

Trước khi OpenClaw có thể quản lý server, bạn cần cho nó khả năng SSH vào các VPS. Phần này hướng dẫn chi tiết từng bước, bao gồm cả việc bảo mật — vì cho bot quyền SSH vào server mà không giới hạn là cực kỳ nguy hiểm.

Bước 1: Tạo SSH key trên server chạy OpenClaw

Trên server đang chạy OpenClaw, tạo một SSH key riêng dành cho bot:

ssh-keygen -t ed25519 -C "openclaw-bot" -f ~/.ssh/id_ed25519_openclaw

Khi được hỏi passphrase, bạn có thể để trống (Enter 2 lần) để bot có thể SSH tự động mà không cần nhập mật khẩu. Mình dùng ed25519 thay vì RSA vì nó nhanh hơn, key ngắn hơn, và bảo mật tương đương RSA-3072 trở lên.

Sau khi tạo xong, bạn sẽ có hai file:

  • ~/.ssh/id_ed25519_openclaw — private key (giữ trên server OpenClaw, không chia sẻ)
  • ~/.ssh/id_ed25519_openclaw.pub — public key (copy sang các VPS)

Bước 2: Tạo user riêng cho bot trên mỗi VPS

Đây là bước quan trọng nhất mà nhiều người bỏ qua. Không bao giờ cho bot SSH bằng root. Hãy tạo một user riêng với quyền hạn chế trên mỗi VPS cần quản lý:

# SSH vào VPS bằng root hoặc user có sudo
ssh root@VPS_IP

# Tạo user riêng cho bot
adduser openclaw --disabled-password --gecos ""

# Tạo thư mục .ssh cho user mới
mkdir -p /home/openclaw/.ssh
chmod 700 /home/openclaw/.ssh
chown openclaw:openclaw /home/openclaw/.ssh

Bước 3: Copy SSH key sang các VPS

Cách nhanh nhất là dùng ssh-copy-id từ server chạy OpenClaw:

ssh-copy-id -i ~/.ssh/id_ed25519_openclaw.pub openclaw@VPS_IP

Nếu ssh-copy-id không dùng được (VPS chưa có password cho user openclaw), copy thủ công:

# Trên server OpenClaw, xem public key
cat ~/.ssh/id_ed25519_openclaw.pub
# Trên VPS, paste vào authorized_keys của user openclaw
echo "ssh-ed25519 AAAA... openclaw-bot" >> /home/openclaw/.ssh/authorized_keys
chmod 600 /home/openclaw/.ssh/authorized_keys
chown openclaw:openclaw /home/openclaw/.ssh/authorized_keys

Test kết nối từ server OpenClaw:

ssh -i ~/.ssh/id_ed25519_openclaw openclaw@VPS_IP "hostname && whoami"

Nếu thấy hostname và username openclaw hiện ra — thành công.

Bước 4: Cấu hình SSH config

Thay vì nhớ IP, port, user của từng server, tạo file ~/.ssh/config trên server OpenClaw để đặt alias:

# ~/.ssh/config trên server chạy OpenClaw

Host web-prod
    HostName 203.0.113.10
    User openclaw
    IdentityFile ~/.ssh/id_ed25519_openclaw
    Port 22


Host web-staging
    HostName 203.0.113.20
    User openclaw
    IdentityFile ~/.ssh/id_ed25519_openclaw
    Port 2222


Host db-master
    HostName 203.0.113.30
    User openclaw
    IdentityFile ~/.ssh/id_ed25519_openclaw
    Port 22


Host app-01
    HostName 203.0.113.41
    User openclaw
    IdentityFile ~/.ssh/id_ed25519_openclaw

Host app-02
    HostName 203.0.113.42
    User openclaw
    IdentityFile ~/.ssh/id_ed25519_openclaw

Bây giờ thay vì ssh -i ~/.ssh/id_ed25519_openclaw openclaw@203.0.113.10, bạn (và bot) chỉ cần gõ ssh web-prod. Gọn hơn rất nhiều, và bot cũng dễ hiểu hơn khi bạn nói “SSH vào web-prod”.

Bước 5: Giới hạn sudo cho user bot

User openclaw cần chạy một số lệnh với sudo (xem log, check service status), nhưng tuyệt đối không được có quyền chạy mọi thứ. Trên mỗi VPS, tạo file sudoers riêng:

# Trên VPS, tạo file sudoers cho user openclaw
visudo -f /etc/sudoers.d/openclaw

Nội dung tuỳ theo loại server. Ví dụ cho production server (chỉ cho phép đọc):

# /etc/sudoers.d/openclaw — Production (READ-ONLY)
# Cho phép xem status, không cho phép thay đổi
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --no-pager *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/df -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/free -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/top -bn1
openclaw ALL=(ALL) NOPASSWD: /usr/bin/tail /var/log/*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/cat /etc/nginx/nginx.conf
openclaw ALL=(ALL) NOPASSWD: /usr/bin/nginx -t
# Chặn tuyệt đối các lệnh nguy hiểm
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/rm *
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/dd *
openclaw ALL=(ALL) NOPASSWD: !/usr/sbin/reboot
openclaw ALL=(ALL) NOPASSWD: !/usr/sbin/shutdown *
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/systemctl restart *
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/systemctl stop *

Cho staging server (cho phép nhiều hơn):

# /etc/sudoers.d/openclaw — Staging (READ + WRITE)
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart php*-fpm
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --no-pager *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/df -h, /usr/bin/free -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/tail /var/log/*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/nginx -t
# Vẫn chặn các lệnh huỷ diệt
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/rm -rf *
openclaw ALL=(ALL) NOPASSWD: !/usr/sbin/reboot
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/dd *

Đây là lớp bảo vệ ở tầng Linux. Dù bot có “muốn” chạy rm -rf / cũng không được phép.

Kết nối qua Tailscale (khuyến nghị)

Cách ở trên dùng SSH truyền thống qua public IP — hoạt động tốt nhưng có nhược điểm: bạn phải mở port SSH ra internet. Nếu có Tailscale, mọi thứ đơn giản và an toàn hơn nhiều.

Cài Tailscale trên server OpenClaw

# Cài Tailscale
curl -fsSL https://tailscale.com/install.sh | sh

# Kết nối vào Tailscale network
sudo tailscale up

# Kiểm tra IP Tailscale
tailscale ip -4
# Ví dụ output: 100.64.0.1

Lần đầu chạy tailscale up, nó sẽ cho bạn một link để đăng nhập trên trình duyệt và xác thực máy vào Tailscale network.

Cài Tailscale trên các VPS cần quản lý

Lặp lại quy trình tương tự trên mỗi VPS:

# Trên mỗi VPS
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Sau khi tất cả máy join xong, kiểm tra trên server OpenClaw:

tailscale status
# Output mẫu:
# 100.64.0.1   openclaw-server   thach@   linux   -
# 100.64.0.2   web-prod          thach@   linux   -
# 100.64.0.3   web-staging       thach@   linux   -
# 100.64.0.4   db-master         thach@   linux   -

Bây giờ thay vì dùng public IP trong SSH config, bạn dùng Tailscale IP:

# ~/.ssh/config — dùng Tailscale IP
Host web-prod
    HostName 100.64.0.2
    User openclaw
    IdentityFile ~/.ssh/id_ed25519_openclaw
Host db-master
    HostName 100.64.0.4
    User openclaw
    IdentityFile ~/.ssh/id_ed25519_openclaw

Bật Tailscale SSH (tuỳ chọn nâng cao)

Tailscale có tính năng SSH tích hợp — bạn không cần quản lý SSH key thủ công nữa. Trên mỗi VPS:

sudo tailscale set --ssh

Sau đó bot có thể SSH trực tiếp mà không cần copy key. Tailscale xác thực dựa trên danh tính máy trong network. Bạn kiểm soát quyền SSH bằng ACL trên Tailscale dashboard.

So sánh: SSH truyền thống vs Tailscale SSH

Để dễ hình dung khi nào nên dùng cách nào:

┌─────────────────────┬──────────────────────┬──────────────────────┐
│                     │ SSH truyền thống     │ Tailscale SSH        │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Mở port ra internet │ Có (port 22)         │ Không                │
│ Quản lý SSH key     │ Thủ công             │ Tự động              │
│ Mã hoá              │ SSH encryption       │ WireGuard + SSH      │
│ VPS đổi IP          │ Phải update config   │ Không ảnh hưởng      │
│ Setup ban đầu       │ Đơn giản             │ Cần cài Tailscale    │
│ Phụ thuộc           │ Không                │ Tailscale service    │
│ Phù hợp khi         │ Ít server, đơn giản  │ Nhiều server, team   │
└─────────────────────┴──────────────────────┴──────────────────────┘

Khuyến nghị của mình: Nếu quản lý từ 3 server trở lên, dùng Tailscale. Bạn sẽ cảm ơn mình khi không phải mở port 22 ra internet và không phải nhớ IP nào của server nào.

Ghi thông tin server vào TOOLS.md

TOOLS.md là file ghi chú kỹ thuật trong workspace OpenClaw. Bot đọc file này mỗi phiên để biết bạn có những tài nguyên gì. Ghi thông tin tất cả server vào đây, càng chi tiết càng tốt.

Format chuẩn cho mỗi server

Mỗi server nên có đủ các trường sau:

### Servers
#### Production — web-prod
- SSH: `ssh web-prod` (100.64.0.2 qua Tailscale)
- User: openclaw
- OS: Ubuntu 24.04
- CPU/RAM: 4 vCPU / 8GB RAM
- Disk: 80GB SSD (cảnh báo khi > 70%)
- Stack: Nginx 1.26 + PHP 8.3-FPM + MySQL 8.0
- Dịch vụ quan trọng: nginx, php8.3-fpm, mysql
- Backup: daily snapshot lúc 3:00 AM
- 🔴 RISK: HIGH — xem Server Rules bên dưới

Giải thích tại sao cần ghi từng trường:

  • SSH alias: Bot biết cách kết nối mà không cần hỏi
  • OS + Stack: Bot biết chạy lệnh gì (apt vs yum, systemctl vs service)
  • Disk + ngưỡng cảnh báo: Bot tự biết khi nào cần alert
  • Dịch vụ quan trọng: Bot biết check status những service nào
  • Backup schedule: Bot kiểm tra backup có chạy đúng không
  • Risk level: Bot biết mức độ cẩn thận cần thiết — đây là trường quan trọng nhất

Ví dụ TOOLS.md đầy đủ

### Servers

#### Production — web-prod
- SSH: `ssh web-prod` (100.64.0.2)
- User: openclaw
- OS: Ubuntu 24.04
- CPU/RAM: 4 vCPU / 8GB
- Disk: 80GB SSD (cảnh báo khi > 70%)
- Stack: Nginx 1.26 + PHP 8.3-FPM + MySQL 8.0
- Dịch vụ: nginx, php8.3-fpm, mysql
- Backup: daily snapshot 3AM
- SSL: Let's Encrypt, auto-renew
- 🔴 HIGH RISK — READ-ONLY cho bot


#### Staging — web-staging
- SSH: `ssh web-staging` (100.64.0.3)
- User: openclaw
- OS: Ubuntu 24.04
- CPU/RAM: 2 vCPU / 4GB
- Disk: 40GB SSD
- Stack: giống production
- 🟡 MEDIUM RISK — bot được restart services


#### Database — db-master
- SSH: `ssh db-master` (100.64.0.4)
- User: openclaw
- OS: Ubuntu 22.04
- CPU/RAM: 4 vCPU / 16GB
- Disk: 200GB NVMe (cảnh báo khi > 60%)
- Stack: MySQL 8.0 (master), Redis 7
- Backup: mysqldump daily 2AM → /backup/mysql/
- 🔴 HIGH RISK — KHÔNG BAO GIỜ restart MySQL khi chưa hỏi

#### App Servers — app-01, app-02
- SSH: `ssh app-01`, `ssh app-02` (100.64.0.5, 100.64.0.6)
- User: openclaw
- OS: Ubuntu 24.04
- Stack: Node.js 22, PM2
- Note: chạy behind load balancer, deploy cả 2 cùng lúc
- 🟡 MEDIUM RISK — bot được restart PM2 apps

⚠️ Đặt rules giới hạn quyền cho agent

Đây là phần quan trọng nhất của bài viết. Nếu bạn chỉ đọc một phần, hãy đọc phần này.

OpenClaw có quyền SSH vào server và chạy lệnh. Nếu bạn không đặt giới hạn, nó có thể thực thi bất kỳ lệnh nào — bao gồm rm -rf /, DROP DATABASE, hay restart production lúc nửa đêm. Bot không có ý định xấu, nhưng nó có thể hiểu nhầm yêu cầu của bạn hoặc đưa ra quyết định sai.

Mình chia thành 4 lớp bảo vệ, từ nhẹ đến nặng. Bạn nên áp dụng ít nhất 2 lớp.

Lớp 1: Rules trong TOOLS.md / AGENTS.md (bắt buộc)

Đây là lớp đơn giản nhất — bạn viết rules bằng ngôn ngữ tự nhiên, bot đọc và tuân thủ. Thêm một section “Server Rules” vào TOOLS.md hoặc AGENTS.md:

### Server Rules

#### Quy tắc chung
- Mỗi lệnh có thể thay đổi state (restart, delete, modify config) phải HỎI XÁC NHẬN trước khi chạy
- KHÔNG BAO GIỜ chạy rm -rf trên bất kỳ server nào
- KHÔNG chạy DROP DATABASE, TRUNCATE TABLE trên production
- KHÔNG sửa file config (.conf, .env) trên production mà không confirm trước
- Khi được hỏi "deploy lên production" → luôn deploy staging trước, test, rồi mới hỏi lại về production


#### Production (🔴 HIGH RISK)
- Chế độ: READ-ONLY
- Được phép: xem log, check status, check disk/ram/cpu, đọc config, test nginx config
- KHÔNG được: restart service, sửa config, xoá file, chạy migration
- Mọi thay đổi phải: (1) giải thích sẽ làm gì, (2) hỏi xác nhận, (3) chờ approve


#### Staging (🟡 MEDIUM RISK)
- Được phép: deploy code, restart services, sửa config, chạy migration
- KHÔNG được: xoá database, format disk, thay đổi SSH config
- Deploy xong: tự động chạy health check và báo cáo

#### Dev/Test (🟢 LOW RISK)
- Bot được tự do thao tác
- Vẫn hỏi trước khi xoá data

Lưu ý: Rules trong file chỉ là “lời hứa” — bot tuân thủ vì nó đọc và hiểu. Nhưng không có gì ngăn bot phá vỡ rules nếu nó hiểu nhầm yêu cầu. Đó là lý do bạn cần thêm các lớp bảo vệ tiếp theo.

Lớp 2: Phân quyền Linux trên server (khuyến nghị)

Đây là lớp bảo vệ ở tầng hệ điều hành — dù bot có “muốn” chạy lệnh cấm cũng không thể. Mình đã hướng dẫn tạo user openclaw và cấu hình sudoers ở phần trên. Đây là tóm tắt theo từng loại server:

Production server — chỉ cho phép đọc:

# /etc/sudoers.d/openclaw
# CHỈ cho phép xem, không cho phép thay đổi
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --no-pager *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/df -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/free -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/top -bn1
openclaw ALL=(ALL) NOPASSWD: /usr/bin/tail /var/log/*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/nginx -t

Staging server — cho phép restart service cụ thể:

# /etc/sudoers.d/openclaw
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart php8.3-fpm
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload nginx
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --no-pager *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/df -h, /usr/bin/free -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/tail /var/log/*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/nginx -t

Lưu ý: Không thêm dòng openclaw ALL=(ALL) NOPASSWD: ALL — dòng này cho full sudo và vô hiệu hoá mọi giới hạn.

Lớp 3: OpenClaw exec policy

OpenClaw có cơ chế approval cho các lệnh nguy hiểm. Khi bot cần chạy một lệnh yêu cầu elevated permissions (ví dụ: lệnh có sudo, lệnh chạy trên host thay vì sandbox), nó sẽ dừng lại và hỏi bạn approve trước khi thực thi.

Bạn sẽ thấy thông báo dạng:

🔒 Lệnh cần approval:
ssh web-prod "sudo systemctl restart nginx"
/approve allow-once   ← cho phép lần này
/approve allow-always ← cho phép luôn lệnh tương tự
/approve deny         ← từ chối

Đây là lớp bảo vệ cuối cùng — bạn luôn có quyền từ chối trước khi lệnh được thực thi. Đặc biệt hữu ích cho production server.

Lớp 4: Phân loại server theo mức rủi ro

Kết hợp tất cả các lớp ở trên, bạn có thể phân loại server thành 3 mức rủi ro. Đây là cách mình tổ chức:

🔴 Production (HIGH RISK)
├── Rules: READ-ONLY trong TOOLS.md
├── Linux: sudoers chỉ cho phép đọc
├── Exec: mọi lệnh cần approval
└── Bot chỉ được: xem log, check status, check disk/ram

🟡 Staging (MEDIUM RISK)
├── Rules: READ + WRITE cụ thể trong TOOLS.md
├── Linux: sudoers cho phép restart service chỉ định
├── Exec: lệnh restart cần approval, lệnh đọc không cần
└── Bot được: deploy, restart nginx/php, sửa config

🟢 Dev/Test (LOW RISK)
├── Rules: tự do trong TOOLS.md
├── Linux: sudoers rộng hơn
├── Exec: không cần approval
└── Bot được tự do thao tác

Template TOOLS.md an toàn cho người mới

Nếu bạn mới bắt đầu, copy template này vào TOOLS.md rồi thay thông tin server của bạn:

### Servers

#### [Tên server] — [SSH alias]
- SSH: `ssh [alias]` ([IP])
- User: openclaw
- OS: [Ubuntu/AlmaLinux + version]
- CPU/RAM: [specs]
- Disk: [size] (cảnh báo khi > [%])
- Stack: [Nginx/Apache + PHP/Node + DB]
- Dịch vụ: [service1, service2]
- Backup: [schedule]
- [🔴/🟡/🟢] [HIGH/MEDIUM/LOW] RISK


### Server Rules


#### Quy tắc chung
- Mỗi lệnh thay đổi state → HỎI XÁC NHẬN trước
- KHÔNG rm -rf, KHÔNG DROP DATABASE trên production
- KHÔNG sửa config production mà không confirm
- Deploy production → staging trước, test xong mới production


#### [Tên server production] (🔴)
- READ-ONLY: chỉ xem log, check status, check tài nguyên
- Mọi thay đổi: giải thích → xác nhận → chờ approve


#### [Tên server staging] (🟡)
- Được: deploy, restart, sửa config
- Không: xoá data, thay đổi hạ tầng

#### [Tên server dev] (🟢)
- Tự do thao tác

Sử dụng hàng ngày

Sau khi setup xong, bạn tương tác hoàn toàn bằng ngôn ngữ tự nhiên. Dưới đây là các ví dụ thực tế.

Kiểm tra tài nguyên toàn bộ server

Bạn: “Kiểm tra disk và RAM tất cả server”

Bot sẽ: SSH vào từng server trong TOOLS.md, chạy df -h và free -h, tổng hợp kết quả:

📊 Báo cáo tài nguyên:

web-prod:    Disk 45/80GB (56%) | RAM 5.2/8GB (65%) ✅
web-staging: Disk 12/40GB (30%) | RAM 1.8/4GB (45%) ✅
db-master:   Disk 142/200GB (71%) | RAM 12/16GB (75%) ⚠️
app-01:      Disk 8/40GB (20%)  | RAM 2.1/4GB (53%) ✅
app-02:      Disk 9/40GB (23%)  | RAM 2.3/4GB (58%) ✅

⚠️ db-master: disk > 70% ngưỡng cảnh báo. Kiểm tra /backup có file cũ cần dọn không?

Kiểm tra service status

Bạn: “Check nginx và MySQL có chạy bình thường trên production không?”

Bot sẽ: SSH vào web-prod, chạy systemctl status nginx và systemctl status mysql, phân tích output:

🟢 web-prod service status:

nginx:  active (running) since Mon 2026-03-10 08:15:00 — uptime 4 days
mysql:  active (running) since Mon 2026-03-10 08:15:12 — uptime 4 days

Cả hai service chạy bình thường, không có lỗi trong journal gần đây.

Xem log lỗi

Bạn: “Xem error log nginx trên production 1 giờ qua, tóm tắt cho mình”

Bot sẽ: SSH vào web-prod, chạy sudo tail -n 200 /var/log/nginx/error.log, lọc log trong 1 giờ qua, phân tích và tóm tắt:

📋 Nginx error log — web-prod (1 giờ qua):

- 12 lần "upstream timed out" từ PHP-FPM → có thể PHP xử lý chậm
- 3 lần "client sent too large body" → client upload file > limit
- Không có lỗi 5xx nghiêm trọng

💡 Đề xuất: kiểm tra PHP-FPM process manager, có thể cần tăng pm.max_children.

So sánh config giữa 2 server

Bạn: “So sánh config nginx giữa production và staging, xem khác nhau chỗ nào”

Bot sẽ: SSH cả hai server, lấy file nginx.conf, diff và highlight khác biệt:

🔍 Khác biệt nginx.conf — production vs staging:

1. worker_connections: prod=2048, staging=1024
2. client_max_body_size: prod=50m, staging=100m ← staging cho phép upload lớn hơn
3. SSL certificate: prod dùng Let's Encrypt, staging dùng self-signed
4. Gzip: prod bật gzip_static on, staging không có

Còn lại giống nhau. Bạn muốn sync config nào từ prod sang staging không?

Deploy lên staging

Bạn: “Deploy version mới lên staging”

Bot sẽ: Thực hiện step-by-step theo quy trình:

📦 Deploy lên web-staging:

1. ✅ SSH vào web-staging
2. ✅ cd /var/www/app && git pull origin main
   → Updated: 3 files changed, 45 insertions, 12 deletions
3. ✅ composer install --no-dev
4. ✅ php artisan migrate --force
   → Migrated: 2026_03_14_create_orders_table
5. ✅ sudo systemctl restart php8.3-fpm
6. ✅ Health check: curl -s -o /dev/null -w "%{http_code}" http://localhost → 200

🟢 Deploy thành công. Staging đang chạy version mới.
Bạn muốn mình test thêm endpoint nào không?

Lưu ý: nếu bạn nói “deploy lên production”, bot sẽ hỏi xác nhận trước (vì rules trong TOOLS.md yêu cầu), và có thể đề xuất deploy staging trước.

Tự động hoá với Cron Jobs

Cron jobs cho phép bot tự động chạy kiểm tra định kỳ mà bạn không cần nhớ. Kết hợp với bài 4 về Cron Jobs, dưới đây là các cron jobs phổ biến cho quản lý server:

Báo cáo sức khoẻ hàng ngày

openclaw cron add "Kiểm tra tất cả server trong TOOLS.md: uptime, CPU load, RAM, disk usage. Chỉ báo cáo chi tiết nếu có vấn đề (disk > 70%, RAM > 80%, load > CPU cores). Còn lại tóm tắt 1 dòng mỗi server." \
  --cron "0 8 * * *" --channel telegram

Mỗi sáng lúc 8h, bạn nhận tin nhắn Telegram tóm tắt tình trạng tất cả server. Chỉ cần đọc 30 giây là biết mọi thứ ổn hay có gì cần xử lý.

Kiểm tra backup

openclaw cron add "SSH vào db-master, kiểm tra file backup MySQL mới nhất trong /backup/mysql/. Cảnh báo nếu: (1) backup cũ hơn 24 giờ, (2) file size nhỏ bất thường (< 100MB khi bình thường > 500MB), (3) không tìm thấy file backup nào." \
  --cron "0 7 * * *" --channel telegram

Kiểm tra SSL certificate

openclaw cron add "Kiểm tra ngày hết hạn SSL certificate trên web-prod. Chạy: echo | openssl s_client -connect web-prod:443 -servername domain.com 2>/dev/null | openssl x509 -noout -dates. Cảnh báo nếu còn dưới 14 ngày." \
  --cron "0 9 * * 1" --channel telegram

SSL certificate hết hạn mà không ai biết là lỗi phổ biến. Cron job này kiểm tra mỗi thứ Hai và cảnh báo sớm 2 tuần.

Tổng hợp log lỗi hàng tuần

openclaw cron add "SSH vào web-prod, đọc /var/log/nginx/error.log 7 ngày gần nhất. Tổng hợp top 5 lỗi phổ biến nhất, số lần xuất hiện, và đề xuất fix nếu có thể." \
  --cron "0 9 * * 1" --channel telegram

Security audit hàng tuần

openclaw cron add "Kiểm tra bảo mật trên tất cả server: (1) có package nào cần security update không (apt list --upgradable), (2) có SSH login thất bại bất thường không (journalctl -u sshd --since '7 days ago' | grep Failed), (3) có user lạ nào được tạo mới không. Tóm tắt kết quả." \
  --cron "0 10 * * 0" --channel telegram

Chủ nhật hàng tuần, bot rà soát security cơ bản. Không thay thế được security audit chuyên nghiệp, nhưng bắt được 80% vấn đề phổ biến.

Inventory tracking trong memory

Bot có memory dài hạn — nó có thể ghi lại mọi thay đổi trên server. Đây là lợi thế mà terminal thông thường không có: bạn có changelog tự động mà không cần duy trì thủ công.

Bot tự ghi changelog

Mỗi khi bạn yêu cầu bot thực hiện thay đổi trên server, nó sẽ ghi vào memory file. Ví dụ:

# memory/2026-03-14.md
## Server Changes
- 10:30 — Updated Nginx 1.24 → 1.26 on web-prod (requested by Thạch)
- 11:00 — Deployed v2.5.0 to web-staging, ran migration create_orders_table
- 14:15 — Increased PHP memory_limit 256M → 512M on web-prod (approved by Thạch)
- 16:00 — Cleaned /backup/mysql/ on db-master, removed backups older than 30 days

Hỏi lại lịch sử

Sau này bạn có thể hỏi:

  • “Lần cuối update Nginx production là khi nào?” → Bot tìm trong memory: “2026-03-14, Nginx 1.24 → 1.26”
  • “Tuần qua có thay đổi gì trên db-master?” → Bot tổng hợp từ memory files
  • “Ai yêu cầu tăng PHP memory_limit?” → Bot: “Thạch, ngày 14/3, từ 256M lên 512M”

Đây chính là CMDB cá nhân: một nơi duy nhất chứa thông tin server (TOOLS.md) + lịch sử thay đổi (memory) + khả năng truy vấn bằng ngôn ngữ tự nhiên.

Kết luận

Quản lý nhiều VPS bằng OpenClaw không khó — setup SSH, ghi thông tin server, đặt vài cron jobs là xong. Nhưng phần quan trọng nhất không phải là tính năng mà là bảo mật.

Hãy nhớ 4 lớp bảo vệ:

  1. Rules trong TOOLS.md — bot đọc và tuân thủ
  2. Phân quyền Linux — user openclaw chỉ có quyền cần thiết
  3. Exec policy — lệnh nguy hiểm cần approval
  4. Phân loại server — production read-only, staging cho phép thay đổi

Áp dụng ít nhất 2 lớp, lý tưởng là cả 4. Một agent có quyền SSH vào server mà không có giới hạn giống như đưa chìa khoá nhà cho người lạ — có thể không có chuyện gì xảy ra, nhưng bạn không muốn test điều đó trên production.

Kết hợp với bài 9 về giám sát server, bạn có một hệ thống vừa phản ứng (nhận alert khi có sự cố) vừa chủ động (kiểm tra định kỳ, quản lý hạ tầng bằng chat) hoàn chỉnh.

Các bài trong serie:

Có thể bạn cần xem thêm

Chia sẻ:
Bài viết đã được kiểm duyệt bởi AZDIGI Team

Về tác giả

Thạch Phạm

Thạch Phạm

Đồng sáng lập và Giám đốc điều hành của AZDIGI. Có hơn 15 năm kinh nghiệm trong phổ biến kiến thức liên quan đến WordPress tại thachpham.com, phát triển website và phát triển hệ thống.

Website
Hơn 10 năm phục vụ 80.000+ khách hàng

Bắt đầu dự án web của bạn với AZDIGI

Web Hosting
Cloud Server
Email Business
VPS
Khám phá giải pháp