ตารางเครื่องมือ CI/CD ทุกประเภท พร้อม Resource Requirements (Minimum)

ผลตรวจ Compliance และการเลือกเครื่องมืออัตโนมัติ

คำนวณจากชุดเครื่องมือทั้งหมดที่วางไว้ในแท็บ 1 เทียบกับกฎหมายและมาตรฐานที่บังคับใช้กับประเภทโครงการที่เลือก

คะแนนแยกตามมาตรฐานรายฉบับ

แต่ละฉบับคิดคะแนนจากมาตรการของตัวเองเท่านั้น จึงเห็นได้ว่าฉบับไหนยังไม่ผ่านและติดข้อใด

Automation: เครื่องมือที่ควรเพิ่มเพื่อให้ผ่านมาตรฐาน

เลือกด้วยอัลกอริทึม greedy set-cover — เครื่องมือที่ปิดช่องว่างได้มากที่สุดต่อทรัพยากรที่เพิ่มน้อยที่สุด

มาตรการทั้งหมดที่ต้องทำ และสถานะ

ทะเบียนกฎหมายและมาตรฐานทั้งหมดในระบบ

ผลลัพธ์ระยะยาวของพื้นที่จัดเก็บ

รายละเอียดต่อ VM

รายละเอียดต่อเครื่องมือ (เฉพาะที่เลือกใช้)

สร้างจากชุดเครื่องมือและผัง VM ในแท็บวางแผน — ไม่ดึงข้อมูลภายนอก เปลี่ยนเครื่องมือแล้วแผนภาพนี้เปลี่ยนตาม

ซอร์ส Mermaid (คัดลอกไปใช้ในเอกสารได้)

ซอร์ส Mermaid ของสถาปัตยกรรม

ข้อกำหนด Automation จากมาตรฐานและเครื่องมือที่เลือก

หน้านี้สร้างไฟล์พร้อมใช้สองชุดแยกกัน: Pipeline YAML (cicd.yml / GitLab / Azure / Jenkins) สำหรับ env เครื่องมือ และขั้นตอน CI/CD และ สคริปต์ติดตั้ง .sh คนละไฟล์ต่อ VM ตามผังทรัพยากร

งานใน Pipeline (เปิด/ปิดได้)

ติ๊กงานที่ต้องการใน YAML — ไม่กระทบสคริปต์ติดตั้งบน VM

วิธีคำนวณกรณีเครื่องเดียวแชร์หลายเครื่องมือ

เงื่อนไขที่ 1 — A: Peak-Max (ค่า minimum ที่สูงสุด)

A = MAX( minimum ของทุกเครื่องมือบนเครื่องนั้น )

ตีความว่า ณ เวลาใดเวลาหนึ่งมีเครื่องมือเพียงตัวเดียวที่ทำงานหนักที่สุด เป็นพื้นขั้นต่ำที่ต้องมีเพื่อให้เครื่องมือที่หนักที่สุดรันผ่านได้ ถ้าต่ำกว่านี้จะมีอย่างน้อยหนึ่งเครื่องมือที่รันไม่ได้เลย

เงื่อนไขที่ 2 — B: Weighted-Sum 20-60% และบันไดร่วมเครื่อง

w_solo = w_base + w_span × activity_index = 0.20 + 0.40 × activity_index  →  ช่วงเดี่ยว 0.20 ถึง 0.60

w_max(n) = 60%, 54%, 48%, 42%, 36%, 30%, 24%, 20% เมื่อมี n = 1 … 8+ เครื่องมือ self-hosted บนเครื่องเดียวกัน (managed ไม่นับ)

w_i = 0.20 + (w_max(n) − 0.20) × activity_index

B1 (strict) = Σ ( minimum_i × w_i ) — บวกทุกเครื่องมือ

B2 (realistic) = Σresident( min × w ) + MAXci_seq + MAXasync + MAXload

เหตุผลของบันได: เครื่องมือบนเครื่องเดียวกันไม่ได้พุ่งพร้อมกันทั้งก้อน ยิ่งอยู่ร่วมกันมาก เปอร์เซ็นต์ซ้อนทับยิ่งลด จนพื้น 20% ที่ n ≥ 8

ตัวตรวจ — C: Resident Floor

C = MAX(idle) + w_max(n) × (Σ idle − MAX(idle))

กัน daemon ที่หนักที่สุดเต็ม และลดส่วนที่ซ้อนของตัวอื่นตามบันไดเดียวกับ B ถ้า A และ B ต่ำกว่า C แปลว่าเครื่องบูตขึ้นมาก็เต็มแล้ว จึงต้องยกผลลัพธ์ขึ้นเป็น C

ผลลัพธ์สุดท้าย

REQUIRED = MAX(A, B, C) + OS Reserve  →  ปัดขึ้นตาม Allocation Ladder

ตรงตามโจทย์ที่ระบุว่า “ต้องเป็นค่าที่มากสุดสำหรับ minimum เท่านั้น” โดย OS Reserve คือทรัพยากรที่กันไว้ให้ระบบปฏิบัติการและ Container Runtime

พื้นที่จัดเก็บ

Disk OS = (OS Reserve + Σ Install) / (1 − Disk Free Ratio)

Data(h) = GB/วัน × Scale × (1 + Growth)h/12 × MIN(Retention, h × 30.44) × (1 + Index Overhead)

Disk Data = Data(h) / (1 − Disk Free Ratio)

เหตุผลของ MIN(Retention, ...): ระบบจะเข้าสู่สภาวะคงตัวเมื่อถึงรอบ retention (ข้อมูลเก่าถูกลบเท่าที่ข้อมูลใหม่เข้ามา) แต่อัตราการผลิตข้อมูลต่อวันยังโตขึ้นทุกปีตาม Growth จึงต้องคูณตัวคูณการเติบโตเข้าไปด้วย

พารามิเตอร์ของโมเดล

ข้อจำกัดที่ต้องรู้ก่อนนำตัวเลขไปใช้

1. ค่า minimum เป็นค่าตั้งต้นจากเอกสารติดตั้งของผู้พัฒนาแต่ละเครื่องมือ รวมกับค่าที่พบจากการใช้งานจริงระดับ UAT/Production ขนาดเล็ก ไม่ใช่ผลวัดจากระบบของท่าน — ต้องวัด baseline จริง 2-4 สัปดาห์หลังติดตั้ง แล้วปรับตัวเลขในไฟล์ scripts/catalog_data.py และ build ใหม่
2. คอลัมน์ “มาตรฐานที่ช่วยตอบ” บอกว่าเครื่องมือมีความสามารถตรงกับข้อกำหนดใด ไม่ได้รับประกันว่าตั้งค่าถูกต้อง — การผ่านมาตรฐานจริงยังต้องมีการตั้งค่า กระบวนการ และหลักฐานการตรวจสอบประกอบด้วย
3. โหมด strict ให้ค่าสูงกว่าความเป็นจริงอย่างมากบนเครื่องที่มีเครื่องมือ ephemeral จำนวนมาก เพราะบวกทุกตัวแม้ในความจริงจะรันเรียงต่อกัน
4. ปริมาณข้อมูลต่อวันอ่อนไหวต่อระดับ log และจำนวน build มาก ต้องตั้ง Scale Factor ให้ตรงกับของจริงก่อนอ่านผล
5. โมเดลนี้ไม่ครอบคลุม network bandwidth, disk IOPS, ค่า license และค่าบุคลากร ซึ่งต้องประเมินแยก
6. เครื่องมือที่เป็น GPL/AGPL (MinIO, Grafana, Zabbix, FOSSology, Wazuh, testssl.sh) ขัดกับข้อห้ามใช้ GPL/AGPL ของโครงการภาครัฐบางแห่ง ต้องตรวจเงื่อนไขการใช้งานหรือขอ commercial license ก่อน

ที่มาของข้อมูล