Quản lý nhiều VPS và nhiều bot: bảng tổng hợp, kiến trúc 3 tầng và 4 cấp độ trưởng thành

Có một khoảnh khắc mà mọi trader chạy nhiều bot đều trải qua, và nó thường đến vào buổi sáng: bạn mở RDP tới máy thứ ba, và tự hỏi "lần cuối mình xem máy này là khi nào?"

Bạn không nhớ. Và điều đó không phải vì bạn bất cẩn — nó là hệ quả tất yếu của việc quản lý bằng trí nhớ. Với một hoặc hai VPS, trí nhớ còn đủ dùng. Với năm máy, nó không còn đủ, và bạn sẽ bắt đầu bỏ sót mà không hề biết.

Bài này nói về việc vận hành nhiều VPS và nhiều bot như một hệ thống, không phải như nhiều việc riêng lẻ. Phần đầu là ba cách quản lý và điểm gãy của từng cách — hữu ích để biết mình đang ở đâu. Phần giữa là kiến trúc tập trung tối thiểu (ba tầng, đủ đơn giản để tự làm) và định dạng file trạng thái chuẩn để mọi máy nói cùng một ngôn ngữ. Phần sau là bốn cấp độ trưởng thành, sổ đăng ký tài khoản, và cách cảnh báo theo tài khoản thay vì theo máy.

1. Điểm gãy: khi số máy vượt số lần bạn có thể nhớ

Việc quản lý bot không khó dần theo số máy — nó khó theo bình phương số máy, vì mỗi máy có thể ảnh hưởng tới máy khác theo những cách không rõ ràng:

• Cùng một tài khoản chạy trên hai máy (do lỗi triển khai) → hai EA tranh nhau quản lý cùng một lệnh.
• Cùng một file heartbeat được hai EA ghi vào → bạn không biết tài khoản nào đang chết.
• Cùng một file log bị hai tiến trình ghi xen kẽ → không đọc được.
• Cùng một khoá API hoặc cùng một tài khoản email dùng cho cảnh báo → cảnh báo bị gộp và mất ngữ cảnh.

Không có cách nào phát hiện những vấn đề này bằng cách nhìn từng máy riêng lẻ. Bạn chỉ thấy chúng khi có một bức tranh tổng thể — và đó là toàn bộ lý do cần một hệ thống quản lý tập trung.

Dấu hiệu bạn đã vượt giới hạn của cách quản lý hiện tại:

1. Bạn không nhớ lần cuối kiểm tra từng máy.
2. Bạn phát hiện một máy lệch cấu hình chỉ khi đã có sự cố.
3. Bạn có hai nguồn thông tin khác nhau cho cùng một câu hỏi và không biết nguồn nào đúng.
4. Khi có cảnh báo, bạn phải mở RDP để biết nó thuộc tài khoản nào.

Nếu bạn thấy mình trong hai dấu hiệu trở lên, hãy đọc phần tiếp theo — không phải để mua công cụ, mà để chọn cấp độ phù hợp.

2. Ba cách quản lý và điểm gãy của từng cách

Cách 1 — RDP từng máy, kiểm tra bằng mắt. Dùng được tới 1–2 máy. Điểm gãy: máy thứ ba. Không phải vì bạn không thể mở ba cửa sổ RDP, mà vì bạn không thể duy trì một nhịp kiểm tra đều đặn cho ba máy bằng kỷ luật cá nhân. Sẽ có ngày bạn bận và bỏ qua một máy, và bạn sẽ không biết đã bỏ qua máy nào.

Cách 2 — Mỗi máy một script riêng. Dùng được tới 3–8 máy. Đây là bước tiến lớn: mỗi máy tự báo khi có sự cố, nên bạn không phụ thuộc vào việc phải mở RDP. Điểm gãy nằm ở chữ "riêng": mỗi máy một cấu hình, ngưỡng khác nhau, tên file khác nhau, kênh cảnh báo khác nhau. Sau vài tháng, bạn có tám hệ thống không giống nhau, và câu hỏi "máy nào đã được cài bản script mới nhất?" không có câu trả lời.

Cách 3 — Một nơi tổng hợp + cảnh báo chung. Dùng được tới 8–50 máy. Mọi máy ghi cùng một định dạng, một nơi đọc tất cả, một bảng tổng hợp, một kênh cảnh báo. Điểm gãy mới xuất hiện: nơi tổng hợp trở thành điểm chết đơn. Nếu nó chết, bạn mất tầm nhìn toàn hệ thống — và không có gì báo cho bạn, vì chính nó là thứ đáng lẽ phải báo. Đây là lý do mục 6 tồn tại.

Cách đọc bảng này: đừng nhảy cấp vì bạn muốn, hãy nhảy cấp vì cấp hiện tại đã gãy. Nâng cấp sớm tạo ra hệ thống phức tạp mà bạn chưa cần, và phức tạp là thứ khó gỡ rối nhất khi có sự cố.

3. Kiến trúc tập trung tối thiểu

Tầng 1 — mỗi VPS tự ghi trạng thái. Đây là phần bạn đã có nếu đã làm theo các bài trước: EA ghi file nhịp mỗi 30 giây, chứa TimeLocal(), TimeCurrent(), số lệnh, và equity. Điểm quan trọng là mọi máy ghi cùng một định dạng — cùng tên file, cùng thứ tự trường, cùng đơn vị. Nếu mỗi máy một định dạng, tầng 2 không thể tự động hoá.

Tầng 2 — một nơi tổng hợp. Đọc file nhịp của mọi máy, so với ngưỡng, phân loại trạng thái từng tài khoản, và dựng một bảng tổng hợp. Cách đơn giản nhất để làm việc này mà không cần hạ tầng phức tạp: mỗi máy đẩy file nhịp của mình lên một nơi chung (một thư mục đồng bộ, một endpoint HTTP, hoặc một repo Git riêng tư), rồi một tiến trình duy nhất đọc tất cả.

Điểm cần nhấn: tầng 2 nên là nơi duy nhất đưa ra kết luận. Nếu mỗi máy tự quyết định có báo động hay không, bạn quay lại cách 2 — mỗi máy một logic, không ai kiểm tra chéo.

Tầng 3 — lớp ngoài canh nơi tổng hợp. Một dịch vụ độc lập (hoặc chỉ là scheduled task trên một máy khác, hoặc một dịch vụ uptime miễn phí) kiểm tra: nơi tổng hợp còn sống không? Nó có cập nhật dữ liệu trong vòng 10 phút qua không? Nếu không, báo cho bạn.

Tầng 3 có thể rất đơn giản: một dịch vụ uptime miễn phí ping tới một endpoint mà nơi tổng hợp cung cấp, trả về thời điểm cập nhật cuối cùng. Nếu endpoint không trả lời, bạn nhận email. Đó là toàn bộ tầng 3, và nó đủ dùng.

4. Một định dạng file nhịp chuẩn cho mọi máy

Đây là phần quan trọng nhất để hệ thống hoạt động trông như một hệ thống. Nếu bạn chỉ làm đúng một việc sau khi đọc bài này, hãy làm việc này.

Nguyên tắc: mọi máy, mọi EA, mọi tài khoản ghi cùng một định dạng, khác nhau chỉ ở giá trị. Dùng định dạng có khoá tên trường (thay vì chỉ các con số theo thứ tự), để có thể thêm trường mới mà không phá vỡ các máy cũ:

{
  "may": "VPS-A",
  "tai_khoan": "1234567",
  "loai_tk": "live",
  "ea": "BotXAU v3",
  "symbol": "XAUUSD",
  "gio_may": 1757694540,
  "gio_tick": 1757694538,
  "so_lenh": 1,
  "equity": 10240.55,
  "margin_level": 412.8,
  "ram_pct": 63,
  "dia_pct": 41,
  "phien_ban_ea": "3.1.2"
}

Sáu trường quan trọng nhất và lý do:

Trường phien_ban_ea là trường mà hầu hết mọi người bỏ qua và sau đó hối hận. Không có nó, bạn không có cách nào biết chắc một máy đã được cập nhật bản EA mới — và bạn sẽ phát hiện ra bằng cách nhìn thấy kết quả giao dịch khác nhau giữa hai máy chạy cùng chiến lược.

Một script gom trạng thái từ nhiều máy và in bảng tổng hợp:

# tong-hop.ps1 — đọc file nhịp của mọi máy, in bảng, chỉ ra việc cần làm
# Cấu trúc: D:\FindMe\nhip\VPS-A\1234567.json, D:\FindMe\nhip\VPS-B\3456789.json ...
$goc      = "D:\FindMe\nhip"
$nguongNhip = 90      # giây
$nguongTick = 120     # giây

$ketQua = foreach ($f in Get-ChildItem -Path $goc -Recurse -Filter *.json) {
  $j = Get-Content $f.FullName -Raw | ConvertFrom-Json
  $now     = [DateTimeOffset]::Now.ToUnixTimeSeconds()
  $nhipTre = $now - [int]$j.gio_may
  $tickTre = $now - [int]$j.gio_tick

  $trangThai = if     ($nhipTre -gt $nguongNhip)             { "TREO" }
               elseif ($tickTre -gt $nguongTick)             { "MAT DU LIEU" }
               elseif ([int]$j.margin_level -lt 300)         { "MARGIN THAP" }
               else                                          { "OK" }

  [pscustomobject]@{
    TaiKhoan   = $j.tai_khoan
    Loai       = $j.loai_tk
    May        = $j.may
    EA         = $j.ea + " (" + $j.phien_ban_ea + ")"
    NhipTre    = [int]$nhipTre
    TickTre    = [int]$tickTre
    SoLenh     = [int]$j.so_lenh
    MarginPct  = [int]$j.margin_level
    TrangThai  = $trangThai
  }
}

$ketQua | Sort-Object TrangThai, May | Format-Table -AutoSize

# Việc cần làm ngay: mọi dòng không phải OK
$canXuLy = $ketQua | Where-Object TrangThai -ne "OK"
if ($canXuLy) {
  Write-Output "`n=== CẦN XỬ LÝ ($($canXuLy.Count) tài khoản) ==="
  $canXuLy | ForEach-Object {
    "{0} · {1} · {2} · {3} · {4} lệnh đang mở" -f $_.TrangThai, $_.TaiKhoan, $_.May, $_.EA, $_.SoLenh
  }
} else {
  Write-Output "`nTất cả tài khoản đều bình thường."
}

Điểm đáng chú ý về thiết kế script: nó in cả bảng đầy đủ và một khối "cần xử lý" ở cuối. Bảng đầy đủ để bạn nhìn thấy tổng thể khi cần; khối cuối để bạn biết việc cần làm trong 5 giây. Nếu bạn chỉ in bảng đầy đủ, bạn sẽ phải tự quét mắt 20 dòng mỗi sáng — và sau một tuần bạn sẽ ngừng quét.

5. Bảng tổng hợp bạn cần nhìn mỗi sáng

Bảng này là thứ thay thế tám lần mở RDP. Nó có sáu cột, và cột quan trọng nhất là cột cuối — vì đó là kết luận, không phải dữ liệu thô.

Nguyên tắc thiết kế: nếu bạn phải mở RDP để trả lời một câu hỏi nào, hãy đưa câu trả lời đó vào bảng. Mỗi lần bạn tự hỏi "máy này đang có lệnh không?" hoặc "bản EA nào đang chạy ở đây?", hãy thêm một cột. Bảng sẽ lớn dần trong vài tuần đầu và sau đó ổn định — vì bạn sẽ hết câu hỏi.

Nhìn vào bảng mẫu trong hình, có ba dòng đáng học:

Dòng 3 — nhịp 4.812 giây nhưng vẫn có 2 lệnh đang mở. Đây là dòng quyết định bạn có nên tự khởi động lại hay không. Tự khởi động lại khi có lệnh mở có thể làm mất trạng thái quản lý của EA. Có so_lenh trong bảng nghĩa là hệ thống tự động có thể quyết định theo số lệnh thay vì chỉ làm một việc cố định.

Dòng 4 — nhịp 41 giây, trạng thái OK. Đây là ví dụ về ngưỡng đúng: 41 giây không vượt ngưỡng 90 giây, nên không báo. Nếu bạn đặt ngưỡng 30 giây, dòng này sẽ báo động — và bạn sẽ có báo động giả mỗi ngày.

Dòng 5 — "không có", trạng thái CHƯA CHẠY. Trạng thái này khác với TREO và khác với OK. Nó nghĩa là tài khoản này chưa từng ghi nhịp — có thể EA chưa được cài, hoặc file nhịp bị sai đường dẫn. Nếu bạn gộp trạng thái này vào "TREO", bạn sẽ đi khởi động lại một tài khoản chưa từng chạy.

6. Nơi tổng hợp cũng có thể chết

Đây là phần dễ bị bỏ qua nhất khi tự dựng hệ thống tập trung, và nó quay lại đúng nguyên tắc của bài "2 lớp canh chừng": thứ gì nằm trong hệ thống bạn đang giám sát thì không thể là lớp giám sát cuối cùng.

Nơi tổng hợp là một tiến trình. Nó có thể:

• Không chạy (task bị vô hiệu, máy bị reboot, tiến trình bị kill).
• Chạy nhưng lỗi câm (không đọc được thư mục, không gửi được cảnh báo, nhưng không báo lỗi gì).
• Chạy và gửi cảnh báo, nhưng kênh cảnh báo bị hỏng (token hết hạn, bot bị chặn).

Trong cả ba trường hợp, bạn mất tầm nhìn toàn hệ thống và không biết gì — cho tới khi bạn tự mở bảng tổng hợp và thấy nó cập nhật lần cuối từ ba ngày trước.

Cách phòng, theo thứ tự đơn giản tăng dần:

Mức 1 — Ghi lại thời điểm cập nhật cuối và hiển thị ở đầu bảng. Một dòng "cập nhật lúc 06:41:02, 12 giây trước" ở đầu báo cáo. Nếu bạn nhìn thấy con số này, bạn biết hệ thống còn sống. Đơn giản, hiệu quả, mất 1 dòng code.

Mức 2 — Cảnh báo giả theo lịch. Mỗi sáng vào một giờ cố định (ví dụ 7 giờ), hệ thống gửi một tin "kiểm tra kênh cảnh báo — mọi thứ bình thường". Nếu bạn không nhận được tin đó vào một ngày có giao dịch, bạn biết kênh hoặc hệ thống có vấn đề. Đây là mẹo dùng chính sự vắng mặt của thông tin làm tín hiệu — và nó rất hiệu quả.

Mức 3 — Một dịch vụ ngoài kiểm tra. Một dịch vụ uptime miễn phí kiểm tra endpoint của nơi tổng hợp mỗi 5 phút. Nếu endpoint trả về "dữ liệu cũ hơn 15 phút", coi như lỗi. Đây là lớp ngoài thật sự, và nó là mức duy nhất phát hiện được trường hợp nơi tổng hợp chết hoàn toàn cùng máy chạy nó.

7. Bốn cấp độ trưởng thành

Cấp 1 — 1–2 máy. Kiểm tra bằng mắt hai lần một ngày, ghi lại giờ kiểm tra để không quên ngày nào. Chưa cần tự động hoá. Việc quan trọng nhất ở cấp này là xây thói quen ghi lại — vì dữ liệu bạn ghi bây giờ sẽ là mức nền để so sánh sau này.

Cấp 2 — 3–5 máy. Mỗi máy một script nhịp, gửi cảnh báo tới một kênh chung. Nhưng điểm mấu chốt ở cấp này là chuẩn hoá: cùng tên file, cùng định dạng, cùng ngưỡng. Nếu bạn không chuẩn hoá ở đây, bạn sẽ phải làm lại khi lên cấp 3.

Cấp 3 — 6–15 máy. Thêm ba thứ: một bảng tổng hợp duy nhất, một sổ đăng ký tài khoản (mục 8), và chuẩn hoá cấu hình MT5 (portable + profile có tên thống nhất). Đây là cấp mà chi phí vận hành bắt đầu giảm theo quy mô — nếu bạn làm đúng.

Cấp 4 — 16+ máy. Tự động hoá triển khai EA, phân nhóm theo chiến lược, cảnh báo theo tài khoản thay vì theo máy, và tách máy theo mức vốn để một sự cố hạ tầng không ảnh hưởng mọi tài khoản cùng lúc.

Sai lầm phổ biến nhất ở đây là nhảy cấp: mua ngay một hệ thống phức tạp ở cấp 4 khi đang có hai máy. Kết quả là bạn có nhiều thứ có thể hỏng, và khi có sự cố bạn không biết lỗi nằm ở đâu. Nguyên tắc đúng: mỗi cấp thêm một thứ, và chỉ nâng cấp khi cấp hiện tại đã ổn định ít nhất hai tuần.

8. Sổ đăng ký tài khoản — thứ mà thiếu là bạn mất dấu

Khi số tài khoản vượt quá năm, bạn cần một nơi ghi lại cái gì đang chạy ở đâu. Không phải vì bạn hay quên, mà vì có những câu hỏi không thể trả lời bằng cách nhìn màn hình:

• Tài khoản 1234567 đang chạy trên máy nào, EA nào, phiên bản nào?
• Symbol XAUUSD đang được giao dịch bởi bao nhiêu EA trên bao nhiêu tài khoản? (Nếu hai EA cùng giao dịch một symbol trên hai tài khoản, bạn đang có rủi ro gấp đôi mà có thể không nhận ra.)
• Tài khoản nào đang dùng vốn thật, tài khoản nào là demo?
• Bản EA nào đang chạy trên máy nào?

Sổ đăng ký tối thiểu là một file có bảy cột:

Hai điều sổ này làm được mà bảng trạng thái không làm được:

Thứ nhất, nó phát hiện rủi ro tập trung theo symbol. Nhìn bảng trên: ba tài khoản cùng giao dịch XAUUSD, với tổng vốn 23.000. Nếu bạn chỉ nhìn từng máy, bạn không thấy điều này — nhưng nó có nghĩa là một cú biến động XAUUSD ảnh hưởng tới cả ba tài khoản cùng lúc.

Thứ hai, nó là nguồn sự thật cho câu hỏi "máy nào đang chạy bản nào". Khi bạn phát hành bản EA mới, sổ cho bạn danh sách việc cần làm, và bạn có thể đối chiếu với trường phien_ban_ea trong file nhịp để biết máy nào đã cập nhật thật.

Với hệ thống tự động, sổ này nên được sinh ra từ chính file nhịp (vì file nhịp đã có may, tai_khoan, ea, phien_ban_ea) thay vì nhập tay. Sổ nhập tay sẽ lệch với thực tế trong vòng hai tuần.

Nghi thức buổi sáng: 5 phút thay cho một giờ

Một hệ thống quản lý chỉ có giá trị nếu bạn thật sự dùng nó mỗi ngày. Vì vậy hãy thiết kế một nghi thức ngắn, cố định, làm được cả vào những ngày bạn bận nhất — nếu nghi thức dài, bạn sẽ bỏ nó vào đúng những ngày có nhiều việc, tức là những ngày bạn cần nó nhất.

Nghi thức 5 phút gồm bốn bước, làm theo đúng thứ tự:

Bước 1 — Nhìn khối "cần xử lý" ở cuối báo cáo. Nếu trống, bạn đã xong. Đây là lý do script ở mục 4 in khối này riêng: để bước đầu tiên của bạn có thể kết thúc trong 5 giây.

Bước 2 — Với mỗi dòng trong khối đó, kiểm tra cột số lệnh đang mở. Không có lệnh nào thì xử lý nhanh và an toàn. Có lệnh đang mở thì cần cẩn thận hơn, và đây là lúc bạn nên đọc log trước khi làm gì.

Bước 3 — Đối chiếu cột phiên bản EA với sổ đăng ký. Bước này chỉ mất 10 giây nhưng phát hiện được loại lỗi âm thầm nhất: một máy đang chạy bản EA cũ mà bạn tưởng đã cập nhật.

Bước 4 — Kiểm tra thời điểm cập nhật cuối của chính báo cáo. Nếu báo cáo cũ hơn một giờ, vấn đề không nằm ở các tài khoản — vấn đề nằm ở hệ thống tổng hợp và bạn cần xử lý nó trước.

Bốn bước này nghe đơn giản, nhưng chúng bao phủ gần như toàn bộ những gì có thể sai trong một đêm. Và quan trọng hơn: chúng nhất quán. Một nghi thức 5 phút làm mỗi ngày hiệu quả hơn nhiều so với việc dành hai tiếng mỗi Chủ nhật để "kiểm tra tất cả" — vì sự cố xảy ra hằng đêm, không xảy ra vào Chủ nhật.

9. Triển khai một EA mới lên nhiều máy

Đây là tác vụ mà ở quy mô nhỏ thì đơn giản và ở quy mô lớn thì trở thành nguồn lỗi chính. Quy trình gồm bốn bước:

Bước 1 — Cập nhật sổ đăng ký trước, triển khai sau. Ghi vào sổ: EA nào, phiên bản nào, sẽ chạy trên tài khoản nào, máy nào. Nếu bạn triển khai trước rồi mới ghi, bạn sẽ quên ít nhất một máy.

Bước 2 — Triển khai theo từng nhóm, không làm hết một lượt. Nhóm theo máy hoặc theo mức vốn. Với nhóm đầu tiên, chạy đủ 24 giờ và kiểm tra: log có gì bất thường, số lệnh có hợp lý, phien_ban_ea trong file nhịp có đúng bản mới.

Bước 3 — Đối chiếu bằng file nhịp, không bằng trí nhớ. Sau khi triển khai toàn bộ, đọc bảng tổng hợp và kiểm tra cột phiên bản: mọi máy phải hiển thị bản mới. Đây là bước bạn phát hiện máy nào bị bỏ sót.

Bước 4 — Giữ bản cũ để quay lại. Trước khi ghi đè file .ex5, đổi tên bản cũ thành BotXAU v3.1.2.ex5. Nếu bản mới có vấn đề, bạn khôi phục trong một phút thay vì phải biên dịch lại từ mã nguồn — và nếu bạn không giữ mã nguồn trên VPS, "một phút" có thể trở thành "một buổi chiều".

Một chi tiết kỹ thuật quan trọng: đừng ghi đè file `.ex5` khi EA đang chạy trên chart. MT5 có thể đã nạp file vào bộ nhớ, và việc ghi đè có thể gây ra hành vi không xác định. Hãy gỡ EA khỏi chart, cập nhật file, rồi gắn lại — hoặc lên lịch triển khai vào lúc không phiên.

10. Cảnh báo theo tài khoản, không theo máy

Đây là thay đổi nhỏ về cách đặt cảnh báo nhưng có ảnh hưởng lớn tới chất lượng thông tin.

Cách đặt cảnh báo theo máy: "VPS-A có vấn đề." Vấn đề: bạn biết máy nào hỏng nhưng không biết tài khoản nào bị ảnh hưởng. Nếu VPS-A chạy ba tài khoản, bạn phải tự kiểm tra xem cả ba có sao không.

Cách đặt cảnh báo theo tài khoản: "Tài khoản 3456789 (live, VPS-B, BotGold) im lặng 4.812 giây, 2 lệnh đang mở." Vấn đề: bạn biết chính xác chuyện gì, ở đâu, và có nên tự khởi động lại hay không — ngay trong tin nhắn.

Sự khác biệt không nằm ở việc tin nhắn dài hơn, mà ở việc nó trả lời được câu hỏi tiếp theo. Cảnh báo tốt là cảnh báo mà bạn không phải mở thêm gì để hành động.

Ba thực hành cụ thể cho việc này:

• Một cảnh báo cho một tài khoản. Nếu ba tài khoản cùng chết, bạn nhận ba tin nhắn — không gộp. Gộp sẽ làm mất ngữ cảnh và bạn sẽ phải tra lại từng cái.
• Cảnh báo tổng hợp chỉ dùng cho báo cáo định kỳ, không dùng cho sự cố đang diễn ra.
• Luôn có số lệnh đang mở. Đây là trường quyết định giữa "tự khởi động lại" và "gọi người".

11. Chi phí và thời gian vận hành theo quy mô

Con số dưới đây là ước lượng thực tế về thời gian vận hành mỗi ngày, giả định bạn đã làm theo các cấp độ ở mục 7. Đây là phần ít được nói nhưng quyết định việc chạy nhiều bot có bền vững hay không.

Cột cuối của bảng này là điểm đáng chú ý: ở quy mô lớn, công việc vận hành chuyển từ "đi tìm vấn đề" sang "xử lý vấn đề đã được tìm ra". Đây là dấu hiệu của một hệ thống trưởng thành: bạn không còn dành thời gian để nhìn, mà dành thời gian để sửa.

Và một lưu ý về chi phí hạ tầng ở mỗi cấp: chi phí VPS tăng tuyến tính theo số máy, nhưng chi phí cơ hội của thời gian vận hành lại tăng nhanh hơn nhiều. Ba tiếng mỗi ngày để đối chiếu 10 máy bằng tay là 90 giờ một tháng — trong khi một lần đầu tư 8 giờ để dựng bảng tổng hợp sẽ tiết kiệm gần như toàn bộ số đó.

12. Checklist và tóm lại

Checklist 10 điểm cho việc quản lý nhiều bot:

1. Mọi máy dùng cùng một định dạng file nhịp (có khoá tên trường)
2. File nhịp có may, tai_khoan, gio_may, gio_tick, so_lenh, phien_ban_ea
3. Có một nơi tổng hợp duy nhất đọc tất cả các máy
4. Kết luận trạng thái được sinh ra ở tầng tổng hợp, không ở từng máy
5. Bảng tổng hợp có cột kết luận, không chỉ dữ liệu thô
6. Bảng hiển thị thời điểm cập nhật cuối cùng
7. Có cảnh báo giả theo lịch để kiểm tra kênh cảnh báo
8. Có lớp ngoài kiểm tra chính nơi tổng hợp
9. Có sổ đăng ký tài khoản, sinh từ file nhịp chứ không nhập tay
10. Cảnh báo theo tài khoản, kèm số lệnh đang mở

Bốn ý cần nhớ:

1. Quản lý bằng trí nhớ chỉ chịu được hai máy. Từ máy thứ ba, bạn cần một bức tranh tổng thể — không phải vì bạn kém, mà vì đó là giới hạn của con người.
2. Chuẩn hoá định dạng là phần quan trọng nhất của cả hệ thống. Không chuẩn hoá thì mọi thứ còn lại đều phải làm bằng tay.
3. Nơi tổng hợp cũng có thể chết, và khi nó chết bạn mất tầm nhìn hoàn toàn. Hãy cho nó một lớp ngoài — dù chỉ là một cảnh báo giả theo lịch.
4. Mỗi cấp độ thêm một thứ. Nhảy cấp tạo ra hệ thống nhiều chỗ hỏng mà bạn không đủ thông tin để gỡ rối.

Nếu bạn muốn đi tiếp: EA Watchdog: tự viết lớp canh chừng thứ hai hướng dẫn phần file nhịp mà bài này dựa vào, MT5 treo nhưng vẫn "đang chạy" giải thích chi tiết cách phân loại trạng thái, và Chọn VPS cho bot MT5 chạy 24/7 là phần hạ tầng tương ứng.

Một máy thì bạn quản lý được bằng trí nhớ. Mười máy thì bạn cần một bảng — và một thứ canh cái bảng đó.