Hướng dẫn ước tính quy mô phần cứng hệ thống thông tin (TTAK.KO-10.0292/R3)

1. Tổng quan

A. Định nghĩa

Hướng dẫn tiêu chuẩn của TTA (Hiệp hội Công nghệ Thông tin và Truyền thông Hàn Quốc) nhằm ước tính dung lượng phần cứng như máy chủ, lưu trữ, mạng một cách khách quan và định lượng dựa trên khối lượng công việc và chỉ số hiệu năng khi xây dựng hệ thống thông tin; bản R3 (sửa đổi tháng 12/2023) cập nhật công thức ước tính và bảng tham chiếu để phản ánh môi trường điện toán đám mây và ảo hóa.

Ước tính quy mô (Sizing) là hoạt động quyết định có căn cứ về việc "cần thiết bị hiệu năng đến đâu và bao nhiêu." Đây không phải là báo giá đơn thuần mà là bài toán khớp cung-cầu: dự báo khối lượng công việc tương lai và tính ngược ra tài nguyên tính toán để hấp thụ khối lượng đó. Chỉ dựa vào kinh nghiệm hay đề xuất của nhà cung cấp sẽ làm mờ trách nhiệm phán đoán và khiến đề xuất giữa các nhà thầu không thể so sánh, trong khi hướng dẫn này buộc phải có quy trình tính toán chung và chỉ số hiệu năng tiêu chuẩn (như tpmC) để các nhà cung cấp, kiểm toán viên và cơ quan đặt hàng khác nhau tạo ra căn cứ có thể kiểm chứng theo cùng một cách.

Số hiệu tiêu chuẩn TTA TTAK.KO-10.0292 đã được sửa đổi nhiều lần, mở rộng đối tượng và chỉ số ước tính. Ban đầu nòng cốt là ước tính tpmC lấy máy chủ làm trung tâm, nhưng qua các lần sửa đổi, phạm vi mở rộng sang lưu trữ, mạng, thiết bị an ninh, và bổ sung logic hiệu chỉnh dựa trên tiền đề chia sẻ tài nguyên ảo hóa và đám mây. Nói cách khác, cần hiểu rằng hướng dẫn không phải là máy tính cố định mà là một tiêu chuẩn sống, mô hình ước tính của nó được cập nhật theo sự thay đổi của môi trường kỹ thuật.

Tính chất của hướng dẫn này có thể tóm tắt thành ba điểm. Thứ nhất là tính khách quan — căn cứ ước tính được nêu rõ bằng chỉ số tiêu chuẩn và hệ số nên ai cũng có thể truy lại và kiểm chứng. Thứ hai là tính định lượng — loại bỏ phán đoán kinh nghiệm và tính ngược quy mô từ con số khối lượng công việc. Thứ ba là tính tái lập — quy định quy trình sao cho cùng đầu vào cho cùng kết quả, khiến kết quả giữa các nhà cung cấp và kiểm toán viên có thể so sánh được. Ba tính chất này là căn cứ để hướng dẫn hoạt động như một chuẩn mực trên thực tế trong hệ thống đấu thầu công và kiểm toán.

B. Bối cảnh ra đời và sự cần thiết

Ước tính phần cứng thất bại theo hai hướng. Ước tính thừa mua thiết bị nhiều hơn cần thiết, lãng phí ngân sách, diện tích sàn, điện năng và làm mát, để lại tài nguyên nhàn rỗi ngay cả trước khi hết khấu hao. Ngược lại, ước tính thiếu dẫn đến trễ phản hồi, timeout, sự cố lúc cao điểm, phá vỡ niềm tin dịch vụ và buộc mở rộng khẩn cấp với chi phí bổ sung và gián đoạn hệ thống. Cả hai thất bại đều là chi phí, nhưng đặc biệt ước tính thiếu biểu hiện dưới dạng dịch vụ công cộng ngừng ngay sau khi khai trương, gây tác động xã hội lớn.

Đặc biệt trong dự án công và quy mô lớn dùng tiền thuế của người dân, "tại sao cần chừng này thiết bị" phải được giải trình khách quan trong quá trình kiểm toán, thẩm định ngân sách và đấu thầu. Ví dụ, nếu một cơ quan công đề xuất hàng chục máy chủ hiệu năng cao cho hệ thống thế hệ mới, việc kiểm toán yêu cầu căn cứ của số lượng đó: số người dùng đồng thời, khối lượng giao dịch, tỷ lệ cao điểm, tỷ lệ dự phòng. Không có hướng dẫn tiêu chuẩn, việc giải trình này rơi vào lập luận vòng quanh rằng "nhà cung cấp đề xuất như vậy," nhưng có hướng dẫn thì có thể truy lại công thức và hệ số ước tính để kiểm chứng tính hợp lệ của kết quả sau đó.

Việc chuẩn hóa căn cứ ước tính còn có chức năng phòng ngừa tranh chấp. Khi phát sinh vấn đề hiệu năng sau khai trương, so sánh giả định khối lượng công việc đã dùng khi ước tính với khối lượng thực tế cho phép phân định trách nhiệm thuộc về yêu cầu thiếu sót của cơ quan đặt hàng, sai sót ước tính của nhà cung cấp, hay đợt tăng nhu cầu không thể dự báo. Việc phán đoán sau này như vậy chỉ khả thi khi căn cứ được lập thành văn bản.

C. Đối tượng ước tính quy mô

Đối tượng ước tính được phân thành máy chủ (WAS/DB/AP), lưu trữ và sao lưu, mạng (đường truyền và switch), thiết bị an ninh. Mỗi đối tượng có tính chất tải khác nhau nên chỉ số cũng khác: máy chủ ước tính quanh thông lượng mỗi giây (TPS, tpmC) và CPU/bộ nhớ, lưu trữ quanh tổng lượng dữ liệu, tốc độ tăng và IOPS (nhập/xuất mỗi giây), mạng quanh phiên đồng thời và băng thông (bps), thiết bị an ninh quanh phiên xử lý mỗi giây và throughput.

Lý do chỉ số khác nhau theo đối tượng là vì vị trí nút thắt cổ chai khác nhau. Dù giao dịch nhanh đến đâu, nếu IOPS đĩa không theo kịp thì DB trở thành nút thắt; dù máy chủ dư dả, băng thông đường truyền không đủ thì việc truyền khối lượng lớn bị chặn. Do đó ước tính không phải là công việc đơn chỉ số mà là công việc đa chiều kiểm tra nút thắt của từng tài nguyên cùng nhau, và cấp dồi dào một tài nguyên mà bỏ mặc phần còn lại thì cả hệ thống bị buộc vào hiệu năng của mắt xích yếu nhất.

Đối tượng cũng khác nhau về tính chất tải theo tầng (tier). Trong kiến trúc ba tầng (web-WAS-DB), tầng web xử lý nhiều yêu cầu tĩnh và phiên nên dễ mở rộng ngang, WAS dùng nhiều CPU cho logic nghiệp vụ, còn DB là điểm đơn có trạng thái với gánh nặng mở rộng dọc và dự phòng lớn. Vì vậy cùng một giao dịch cũng được ước tính ra tài nguyên yêu cầu khác nhau theo tầng, và đặc biệt tầng DB khó mở rộng nên cái giá của sai sót ước tính ở đó là lớn nhất.

2. Quy trình ước tính và cấu trúc tổng thể

flowchart LR
  A["Phân tích yêu cầu & khối lượng"] --> B["Chọn đối tượng & phương pháp"]
  B --> C["Áp dụng giá trị nền & hệ số hiệu chỉnh"]
  C --> D["Tính quy mô"]
  D --> E["Kiểm chứng & điều chỉnh"]
  E -->|"thiếu hoặc thừa"| A

Logic cốt lõi của quy trình là "định nghĩa nhu cầu trước, rồi chia nhu cầu đó cho hiệu năng đơn vị của thiết bị." Tóm tắt dưới dạng phép chia, ước tính là thiết bị cần thiết = tổng hiệu năng yêu cầu ÷ hiệu năng đơn vị của một máy, và việc dựng tử số chính xác đến đâu quyết định chất lượng ước tính.

Ở bước đầu tiên, phân tích khối lượng công việc, người dùng đồng thời, giao dịch (TPS), lượng dữ liệu và thời điểm cao điểm (tải tối đa) được xác định. Vì ước tính phải chịu được cao điểm chứ không phải trung bình, việc xác định cao điểm đặc biệt quan trọng. Chẳng hạn các hệ thống có tải tăng vọt tại một thời điểm cụ thể—quyết toán thuế cuối năm, đăng ký môn học, đặt vé dịp lễ—chắc chắn sẽ thất bại nếu ước tính theo tải trung bình. Ở bước này, kịch bản cao điểm được cố định thành con số cụ thể dựa trên log quá khứ, thống kê hệ thống tương tự và phỏng vấn người phụ trách nghiệp vụ.

Tiếp theo phương pháp ước tính được định theo từng đối tượng. Ước tính định lượng dựa trên chỉ số tiêu chuẩn phù hợp với hệ thống mới quy mô lớn, còn mô hình tham chiếu được dùng kèm khi mở rộng hệ thống hiện có hoặc khi có nhiều trường hợp tương tự. Sau đó hệ số hiệu chỉnh—hiệu năng, tỷ lệ dự phòng, dự phòng kép, tỷ lệ khả dụng mục tiêu—được áp dụng để phồng tổng hiệu năng yêu cầu, quy mô được tính toán, và cuối cùng được kiểm chứng và điều chỉnh qua benchmark (BMT), thử tải và xem xét tính hợp lệ. Nếu kiểm chứng cho thấy thừa hoặc thiếu, việc quay lại giả định khối lượng để ước tính lại là vòng lặp lặp đi lặp lại tạo nên bản chất của quy trình này.

Quy trình này nhấn mạnh tính truy vết của từng bước. Phải có thể lần ngược từ số lượng thiết bị cuối cùng đến hồ sơ khối lượng công việc thì mới có thể giải trình trong kiểm toán và thẩm định. Ngược lại, nếu giả định của một bước nào đó không được lập thành văn bản, điểm đó trở thành điểm mù của việc kiểm chứng, khiến không thể quy trách nhiệm khi phát sinh vấn đề sau khai trương. Vì vậy việc lưu lại sản phẩm của từng bước (hồ sơ khối lượng, bảng căn cứ hiệu chỉnh, báo cáo kết quả ước tính) là yêu cầu thực chất để tuân thủ hướng dẫn.

Bước	Nội dung	Sản phẩm
Phân tích khối lượng	Xác định người dùng đồng thời, giao dịch (TPS), lượng dữ liệu, cao điểm	Hồ sơ khối lượng
Chọn phương pháp	Quyết định phương pháp ước tính theo đối tượng (định lượng, tham chiếu)	Tài liệu phương pháp
Áp dụng hiệu chỉnh	Phản ánh hệ số hiệu năng, dự phòng, dự phòng kép, khả dụng	Bảng căn cứ hiệu chỉnh
Tính & kiểm chứng	Tính quy mô rồi kiểm chứng tính hợp lệ và benchmark	Báo cáo kết quả ước tính

3. Phương pháp ước tính và chỉ số hiệu năng

flowchart TB
  subgraph Demand["Hiệu năng yêu cầu (tử số)"]
    T1["Khối lượng giao dịch nền"] --> M["Tổng hiệu năng yêu cầu"]
    T2["Tỷ lệ cao điểm"] --> M
    T3["Dự phòng, dự phòng kép, khả dụng"] --> M
  end
  subgraph Unit["Hiệu năng đơn vị (mẫu số)"]
    U1["tpmC / OPS / SPECint"] --> U["Hiệu năng đơn vị thiết bị"]
  end
  M --> R["Quy mô cần = hiệu năng yêu cầu ÷ hiệu năng đơn vị"]
  U --> R

Phương pháp ước tính được xây dựng theo ba trục lớn. Cơ sở số (định lượng) tính bằng chỉ số hiệu năng tiêu chuẩn như tpmC của TPC-C, thông lượng giao dịch (OPS), SPECint của SPEC. tpmC, nghĩa là "số giao dịch đặt hàng mới có thể xử lý mỗi phút," là chỉ số benchmark TPC-C; vì các hãng máy chủ công bố giá trị đo được chứng nhận, dùng nó làm mẫu số (hiệu năng đơn vị) cho căn cứ rõ ràng và phù hợp với hệ thống mới quy mô lớn. SPECint biểu thị hiệu năng phép toán số nguyên và được dùng để ước tính công việc thiên về CPU.

Cơ sở mô hình tham chiếu so sánh và suy luận từ giá trị đo thực tế hoặc cấu hình tiêu chuẩn của các hệ thống hiện có tương tự. Nó được dùng khi việc rút ra chỉ số mới khó (ví dụ thiết bị công nghệ mới không có benchmark) hoặc khi cần đối chiếu kết quả định lượng. Ví dụ, nếu hệ thống cùng nghiệp vụ của một cơ quan ngang hàng đang vận hành trên bốn máy chủ và khối lượng của ta gấp 1,5 lần họ, ta lấy khoảng sáu máy chủ làm giá trị tham chiếu để đối chiếu với con số định lượng. Mô hình tham chiếu phù hợp thực tế cao nhưng có hạn chế là kết quả phụ thuộc vào chất lượng của đối tượng tham chiếu.

Cùng với đó, hiệu chỉnh và dự phòng được áp dụng chung để hấp thụ tính bất định của thực tế. Bộ khung của công thức là hiệu năng cần = khối lượng giao dịch nền × tỷ lệ cao điểm × tỷ lệ dự phòng ÷ hiệu năng đơn vị thiết bị. Như một trường hợp cụ thể, trong hệ thống bình thường xử lý 100 giao dịch mỗi giây, nếu tải tăng gấp ba lúc cao điểm (tỷ lệ cao điểm 3) và mức sử dụng CPU giới hạn ở 70% để dành 30% dự phòng (tỷ lệ dự phòng ≈ 1/0,7 ≈ 1,43), thì hiệu năng thực sự phải đảm bảo là 100 × 3 × 1,43 ≈ 429 TPS, cao hơn bốn lần giá trị nền. Thêm dự phòng kép (N+1) cho chịu lỗi lại làm tăng quy mô đảm bảo. Nhân các hệ số một cách rõ ràng như vậy làm căn cứ ước tính minh bạch và cho phép xét tính hợp lệ của từng hệ số riêng lẻ.

Phương pháp	Mô tả	Tình huống phù hợp
Cơ sở số (định lượng)	Tính bằng chỉ số tiêu chuẩn như tpmC, OPS, SPECint	Mới, quy mô lớn; cần căn cứ được chứng nhận
Cơ sở mô hình tham chiếu	So sánh và suy luận từ trường hợp hệ thống tương tự, cấu hình tiêu chuẩn	Mở rộng, đối chiếu; khó rút chỉ số
Hiệu chỉnh và dự phòng	Phản ánh tỷ lệ cao điểm, tốc độ tăng, dự phòng kép, khả dụng mục tiêu	Áp dụng chung cho mọi ước tính

Đặt hệ số hiệu chỉnh bằng bao nhiêu là cốt lõi của sự đánh đổi. Đặt dự phòng lớn thì an toàn nhưng trôi về ước tính thừa; đặt nhỏ thì kinh tế nhưng yếu lúc cao điểm. Hướng dẫn yêu cầu phạm vi tham chiếu theo đặc tính nghiệp vụ và trình bày căn cứ để các hệ số này không bị định tùy tiện, và đây là ranh giới phân biệt "ước tính theo cảm tính" và "ước tính tiêu chuẩn."

Không chỉ CPU/tpmC mà ước tính bộ nhớ cũng quan trọng riêng. WAS lấy bộ nhớ nền bằng số phiên đồng thời × lượng heap dùng mỗi phiên, còn DB ước tính bằng cách cộng bộ đệm buffer, vùng sắp xếp và connection pool. Nếu bộ nhớ thiếu, việc swapping và GC (thu gom rác) tăng vọt làm phản hồi sụt giảm dù CPU dư dả, nên nút thắt điển hình "CPU dồi dào mà vẫn chậm" đến từ ước tính thiếu bộ nhớ. Do đó ước tính CPU dựa trên tpmC và ước tính bộ nhớ phải thực hiện độc lập và đối chiếu chéo.

Tỷ lệ dự phòng cũng ẩn biến số thời gian duy trì cao điểm. Đỉnh tức thời có thể hấp thụ bằng xếp hàng và buffer, nhưng nếu cao điểm kéo dài hàng chục phút trở lên thì tài nguyên thực sự cần đến mức đó. Do đó cùng một tỷ lệ cao điểm, "tải ngắn và nhọn" và "tải dài và thoải" yêu cầu hiệu năng khác nhau, và phải nắm được hình thái (thời gian duy trì, phân bố) của tải trong phân tích khối lượng thì mới quyết định tỷ lệ dự phòng hợp lý.

4. Trường hợp thực tế ước tính và so sánh

Ước tính định lượng và ước tính tham chiếu không loại trừ nhau mà bổ sung cho nhau. Trong thực tế thường dùng cấu trúc ba bước: rút quy mô sơ bộ bằng công thức định lượng, đối chiếu chéo bằng mô hình tham chiếu xem giá trị có nằm trong phạm vi hợp lý không, rồi cuối cùng thực chứng bằng BMT (thử nghiệm benchmark). Nếu ba phương pháp lệch nhau lớn thì một trong các giả định khối lượng hoặc hệ số là sai, báo hiệu cần xem xét lại.

Lý do việc đối chiếu chéo này quan trọng là vì sai số mà mỗi phương pháp bỏ sót là khác nhau. Công thức định lượng nếu giả định hệ số sai thì lệch lớn một cách âm thầm và thiếu cảm giác thực tế, còn mô hình tham chiếu thì thực tế nhưng bị méo nếu đặc tính nghiệp vụ của đối tượng tham chiếu khác biệt. BMT có độ tin cậy cao nhất nhưng tốn thời gian, chi phí và khó có được dữ liệu thực. Chồng ba phương pháp lên nhau cho phép phương pháp này bắt được sai số của phương pháp kia, làm tăng độ vững của ước tính so với khi chỉ dựa vào một phương pháp duy nhất.

Hãy xem một cổng thông tin công cộng như một trường hợp cụ thể. Với 10.000 người dùng đồng thời bình thường và 0,2 giao dịch mỗi giây mỗi người, tải nền là 2.000 TPS. Nhưng nếu truy cập tăng gấp năm vào ngày công bố chính sách, áp dụng tỷ lệ cao điểm 5 yêu cầu 10.000 TPS. Thêm tỷ lệ dự phòng 1,43 và dự phòng kép cho vận hành không gián đoạn, hiệu năng cần đảm bảo vượt 20.000 TPS, và nếu hiệu năng đơn vị của một máy chủ ở mức tương đương tpmC nào đó thì số máy chủ cần thiết được rút ra. Không có phép tính này, khẳng định "vài máy chủ là đủ" chỉ là một tuyên bố không thể kiểm chứng.

Lý do logic ước tính của từng tài nguyên khác nhau là sự khác nhau về vị trí nút thắt đã nêu ở trên, và hàm ý thực tiễn là "phải đảm bảo tài nguyên một cách cân bằng." Đầu tư thừa vào một tài nguyên làm tăng chi phí nhưng để hiệu năng tổng thể bị buộc vào tài nguyên yếu nhất, không cải thiện. Cảm giác cân bằng này làm cho ước tính quy mô thành một hoạt động thiết kế chứ không phải phép chia đơn thuần.

Ước tính mạng cũng không kết thúc bằng phép nhân băng thông đơn giản. Phải xem cùng nhau số phiên đồng thời, lưu lượng trung bình/cao điểm mỗi phiên, và giới hạn xử lý phiên của thiết bị an ninh (firewall, IPS). Ví dụ, nếu băng thông dư dả nhưng bảng phiên đồng thời của firewall đầy thì kết nối mới bị từ chối—một nút thắt riêng không giải quyết được bằng cách tăng đường truyền. Nhận diện "giá trị giới hạn cạn kiệt trước nhất" của từng tài nguyên như vậy là yếu tố then chốt của ước tính chính xác.

Ước tính lưu trữ khác logic với máy chủ. Phải xem cùng nhau không chỉ tổng lượng dữ liệu mà cả tốc độ tăng và IOPS. Ví dụ, giả định dữ liệu ban đầu 10TB với tăng 30% mỗi năm cần khoảng 22TB sau ba năm, và thêm overhead sao lưu, snapshot, index cùng không gian dự phòng (thường 20–30%) cho ra dung lượng thực tế cần đảm bảo. Đồng thời phải xác nhận riêng cấu hình đĩa (SSD/HDD, RAID) có chịu được IOPS mà giao dịch yêu cầu không, để tránh trường hợp dung lượng đủ nhưng nhập/xuất trở thành nút thắt.

Vì giả định tốc độ tăng tích lũy theo lãi kép nên dù sai số nhỏ cũng doãng ra lớn về dài hạn. Trong ví dụ trên, ước tính tăng thấp sai thành 50% thay vì 30% làm nhu cầu thực tế sau ba năm vọt lên khoảng 34TB, vượt xa con số ước tính. Do đó, lấy tiền đề rằng lưu trữ là tài nguyên được ước tính lại và mở rộng thường xuyên hơn máy chủ, việc đồng thời thiết kế cấu trúc cho phép mở rộng trực tuyến (lưu trữ scale-out, mở rộng volume) là thực tiễn. Đây là lý do máy chủ được tiếp cận với cấp ban đầu dồi dào, còn lưu trữ được tiếp cận thiên về khả năng mở rộng.

Phân loại	Máy chủ	Lưu trữ	Mạng
Chỉ số cốt lõi	TPS, tpmC, SPECint	Tổng lượng, tốc độ tăng, IOPS	Phiên đồng thời, băng thông
Yếu tố nút thắt	CPU, bộ nhớ	Dung lượng, nhập/xuất	Đường truyền, switch
Phản ánh dự phòng	Giới hạn mức dùng CPU	Không gian dự phòng 20–30%	Băng thông cao điểm

Tại hiện trường kiểm toán khu vực công thực tế, mỗi mục trong bảng này được kiểm tra xem "giá trị giả định—căn cứ—phép tính—kết quả" có khớp từng dòng không. Ví dụ, tỷ lệ cao điểm 3 trong ước tính máy chủ có dựa trên log lưu lượng ba năm quá khứ không, hay không gian dự phòng 25% có phản ánh overhead sao lưu và index không. Đưa hệ số lớn vào mà không có căn cứ sẽ bị điều chỉnh giảm vì ước tính thừa, ngược lại bỏ sót tốc độ tăng sẽ bị chỉ ra là rủi ro mở rộng sớm. Bằng cách này hướng dẫn làm cho ước tính thành dạng có thể kiểm toán và đảm bảo tính chính đáng của ngân sách.

5. Chuyên sâu: Sự thay đổi ước tính trong thời đại đám mây/FinOps

Từ góc nhìn của Kỹ sư chuyên nghiệp, thay đổi gần đây đáng chú ý là việc chuyển sang đám mây đang làm thay đổi mô hình ước tính. Ước tính thời đại on-premises là mô hình cấp cố định (provisioning theo cao điểm) mua toàn bộ thiết bị chịu được cao điểm tương lai từ đầu. Nhưng trong môi trường on-demand, auto-scaling, ta chỉ giữ tài nguyên tối thiểu bình thường và tăng tự động khi tải lên, nên trọng tâm chuyển từ "cấp cố định theo cao điểm" sang "cấp đàn hồi + tối ưu chi phí (FinOps)."

Dù vậy, hướng dẫn ước tính quy mô vẫn còn giá trị, thậm chí vai trò được định nghĩa lại. Auto-scaling cũng phải định dung lượng tối thiểu/tối đa và trần ngân sách thì mới chặn được chi phí thất thoát, và định các giá trị ranh giới đó cần căn cứ định lượng dựa trên khối lượng công việc. Các quyết định như reserved instance (RI), savings plan hạ đơn giá qua cam kết dài hạn cũng đứng trên phán đoán ước tính "tải nền là bao nhiêu." Tức là đám mây không xóa bỏ ước tính mà đổi tính chất của nó từ tính toán ban đầu một lần sang quản lý dung lượng và chi phí liên tục.

Trong môi trường container/Kubernetes, requests/limits của pod và ngưỡng của HPA (Horizontal Pod Autoscaler) trở thành đối tượng ước tính mới. Đặt requests quá lớn lãng phí tài nguyên node; quá nhỏ gây OOM (hết bộ nhớ) và throttling phá vỡ hiệu năng. Rốt cuộc, logic căn bản của hướng dẫn "đo hiệu năng yêu cầu và chia cho tài nguyên đơn vị" hoạt động không đổi, chỉ đổi đơn vị từ máy chủ vật lý sang pod.

Như một trường hợp thực tế, thương mại điện tử quy mô lớn trải qua đỉnh cực đoan khi tải vào ngày sale lớn nhảy lên hàng chục lần so với bình thường. Do không thể xử lý bằng cấp cố định, họ vận hành với tài nguyên tối thiểu bình thường, scale-up trước để khớp tải dự báo trước sự kiện và hấp thụ biến động còn lại bằng auto-scaling. Ngay cả khi đó, "tăng đến đâu (dung lượng tối đa)" và "trần ngân sách" được định trước bằng phép tính sizing, và tại đây logic của hướng dẫn ước tính quy mô được tái sử dụng làm bộ khung kiểm soát chi phí đám mây.

Sự phát triển của khả năng quan sát (Observability) chuyển căn cứ ước tính từ dự báo trước sang hiệu chỉnh liên tục dựa trên đo lường thực tế. Quan sát liên tục tải thực tế qua APM và thu thập metric cho phép kiểm chứng tỷ lệ cao điểm và dự phòng giả định khi ước tính có khớp thực tế không, và phản ánh vào quyết định mở rộng tiếp theo. Điều này có thể xem là kéo dài vòng lặp "kiểm chứng và điều chỉnh" mà hướng dẫn yêu cầu vào tận giai đoạn vận hành.

Về hướng ra đề dự kiến, ước tính quy mô phần cứng có khả năng chuyên sâu vượt dạng trả lời ngắn "trình bày chính xác công thức và hệ số ước tính" sang hỏi về quan hệ với đám mây/auto-scaling, tối ưu chi phí theo góc nhìn FinOps, và liên kết với thiết kế khả dụng. Do đó trong bài làm, việc đan xen cùng nhau căn cứ cổ điển là công thức tpmC và dòng chảy mới nhất là cấp đàn hồi, quản lý dung lượng liên tục là chiến lược điểm cao. Trình bày lý do tồn tại của hướng dẫn (đảm bảo căn cứ khách quan) như một nguyên lý xuyên suốt cả on-premises và đám mây sẽ tăng sức thuyết phục.

6. Điểm cần cân nhắc và hàm ý

Phản ánh tương lai và tăng trưởng: Ước tính phải bao quát không phải ảnh chụp tại thời điểm khai trương mà tăng trưởng dữ liệu và người dùng trong 3–5 năm tới. Bỏ sót tốc độ tăng gây mở rộng sớm với chi phí bổ sung và gián đoạn, còn ước tính quá cao gây đầu tư thừa ban đầu. Trình bày rõ căn cứ của đường cong tăng trưởng (kế hoạch kinh doanh, xu hướng quá khứ) là then chốt.
Liên kết với thiết kế khả dụng và dự phòng kép: Tỷ lệ khả dụng mục tiêu (ví dụ 99,9%) quyết định dung lượng dự phòng kép và DR (khôi phục thảm họa), nên không thể tách rời khỏi ước tính. Yêu cầu vận hành không gián đoạn cần các node dự phòng N+1 trở lên, làm quy mô đảm bảo lớn lên tương ứng. Yêu cầu khả dụng phải được cố định thành mục tiêu định lượng trước rồi mới phản ánh vào ước tính.
Rủi ro của ước tính không kiểm chứng: Đừng dừng ở công thức mà phải thực chứng bằng BMT và thử tải. tpmC được nhà cung cấp chứng nhận là giá trị trong điều kiện lý tưởng và thường không xuất hiện y nguyên trong công việc thực, nên phải hiệu chỉnh khoảng cách với giá trị đo bằng dữ liệu và truy vấn thực thì con số ước tính mới có được niềm tin.
Chuyển hướng chiến lược sang đám mây/FinOps: Trong môi trường lai (hybrid) on-premises–đám mây, việc bố trí chiến lược tải nền vào on-premises/RI và tải biến động vào on-demand/auto-scaling là hữu hiệu. Ước tính trở thành căn cứ định ranh giới của việc bố trí này và được dùng làm đường cơ sở không chỉ cho dung lượng ban đầu mà cho tối ưu chi phí liên tục.
Nhất quán với tiêu chuẩn và kiểm toán: Nếu là dự án công thì căn cứ ước tính phải nhất quán với hướng dẫn TTA và tiêu chí kiểm toán thì mới qua được thẩm định ngân sách và kiểm toán. Lập thành văn bản phương pháp ước tính, hệ số, căn cứ tham chiếu để đảm bảo khả năng kiểm chứng sau này là điểm thực tiễn mà Kỹ sư chuyên nghiệp phải nắm.
Cân bằng tài nguyên và khả năng mở rộng theo tầng: Đảm bảo CPU, bộ nhớ, IOPS, băng thông một cách cân bằng, nhưng một điểm đơn như DB khó mở rộng ngang thì phải dành dự phòng và dự phòng kép dồi dào ngay từ đầu. Phân biệt tầng dễ mở rộng với tầng khó mở rộng và áp dụng tỷ lệ dự phòng khác biệt sẽ cho hiệu quả chi phí cao.
Tính bền vững và hiệu quả điện năng (Green IT): Gần đây trung tâm dữ liệu đối mặt với ràng buộc điện năng và carbon ngày càng lớn, nên ước tính thừa là gánh nặng không chỉ về ngân sách mà cả về điện năng, làm mát, carbon. Ước tính cần góc nhìn xem xét cùng nhau hiệu năng trên mỗi watt và PUE để chọn quy mô bền vững.
Ra quyết định trong điều kiện bất định: Vì khối lượng công việc tương lai về bản chất là dự báo, nên ước tính không phải bằng một kịch bản duy nhất mà bằng nhiều kịch bản lạc quan/nền/bi quan và trình bày khoảng đó cho người ra quyết định là điều nên làm. Tính đàn hồi của đám mây trở thành phương tiện hấp thụ tính bất định này, nên dịch vụ càng mới với độ tin cậy dự báo càng thấp thì giá trị của cấp đàn hồi so với cấp cố định càng lớn.

Tài liệu tham khảo

Thư viện tiêu chuẩn của Hiệp hội Công nghệ Thông tin và Truyền thông Hàn Quốc (TTA): https://www.tta.or.kr
Trang chính thức benchmark TPC-C (tpmC): https://www.tpc.org/tpcc/
SPEC (Standard Performance Evaluation Corporation): https://www.spec.org

Tóm tắt một câu: TTAK.KO-10.0292/R3 là hướng dẫn ước tính khách quan dung lượng HW dựa trên chỉ số hiệu năng tiêu chuẩn như tpmC theo quy trình phân tích khối lượng → chọn phương pháp → hiệu chỉnh → tính toán và kiểm chứng; với logic hiệu năng yêu cầu = khối lượng nền × tỷ lệ cao điểm × tỷ lệ dự phòng ÷ hiệu năng đơn vị nó ngăn ước tính thừa và thiếu, cung cấp căn cứ kiểm toán cho dự án công, và trong thời đại đám mây/FinOps vai trò của nó được định nghĩa lại vượt khỏi ước tính dung lượng ban đầu thành đường cơ sở cho cấp đàn hồi và tối ưu chi phí liên tục.