GitHub Actions Matrix High Availability HA Setup — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

GitHub Actions Matrix คืออะไร และทำไมต้องออกแบบให้มีความพร้อมใช้งานสูง

หลายคนที่ใช้ GitHub Actions มาระยะหนึ่งจะเจอปัญหาเดียวกัน คือไปป์ไลน์ล้มเหลวไม่ใช่เพราะโค้ดมีบั๊ก

แต่เพราะระบบผู้เรียกใช้งานจริงมีข้อจำกัดเรื่องเวลาหยุดทำงาน ตัวอย่างเช่นรันเนอร์ที่ตั้งเองหรือเซิร์ฟเวอร์ที่คอยรับงานต่าง ๆ ดับกลางคืน งานที่คิวไว้ก็ค้างทั้งหมด ทีมพัฒนาต้องรอ ยอดขายหรือการส่งมอบล่าช้า ผมเองดูแลระบบมานานหลายปีและใช้ GitHub Actions ในการสร้างระบบสัญญาณซื้อขายอัตโนมัติสำหรับงานเทรดของผมเองด้วย เลยเข้าใจดีว่าความล้มเหลวเพียงไม่กี่นาทีมีค่าเท่าไร การใช้ Matrix Build ของ GitHub Actions ที่ให้เราสั่งงานเดียวกันกระจายไปหลายสภาพแวดล้อมหลายเครื่องพร้อมกัน นั้นเมื่อผสมกับการออกแบบให้ระบบพร้อมใช้งานตลอดเวลา จะกลายเป็นแผนป้องกันความเสี่ยงที่ทรงพลังมาก

เทคนิคนี้โดยหลักคือการรันงานเดียวกันหลาย ๆ เวอร์ชันพร้อมกันผ่านกลไกแจกแจงค่าต่าง ๆ ในไฟล์การตั้งค่า เช่น สั่งทดสอบโค้ดเดียวกันบนสามระบบปฏิบัติการ หรือรันทดสอบซ้ำหลายรอบผ่านเครือข่ายต่างกันเพื่อยืนยันผล ประโยชน์ที่ได้คือถ้าเครื่องใดเครื่องหนึ่งล้มเหลว เรายังมีผลจากเครื่องอื่นให้เทียบกันได้ทันทีว่าปัญหาเกิดจากโค้ดหรือจากเครื่อง ต่างจากการรันเดียวจบที่ถ้าเครื่องดับก็ต้องรันใหม่ทั้งหมด ในบริบทของการทำงานแบบกระจายความเสี่ยง ความหมายจึงครอบคลุมทั้งตัวรันเนอร์หลายตัว ฐานข้อมูลที่มีสำเนาสำรองพร้อมสลับใช้ และการตั้งค่าให้งานกระจายไปยังเครื่องที่พร้อมใช้งานจริง ๆ ไม่ใช่แค่ประกาศตัวเลขกันเฉย ๆ

ผมขอยกตัวอย่างจากงานจริงเลยนะครับ ระบบสัญญาณของผมต้องคำนวณข้อมูลราคาทุกสิบวินาที ถ้างานประมวลผลที่สั่งผ่านการดำเนินการอัตโนมัติหยุดค้างเพียงสองสามนาที สัญญาณอาจส่งช้าหรือส่งผิดพลาด เสียเงินจริง ๆ ทางแก้ที่ผมใช้คือรันงานคำนวณเดียวกันบนรันเนอร์สองเครื่องในสองภูมิภาคผ่านกลไกแจกแจงค่า เครื่องหลักส่งผลออกไปก่อน ส่วนเครื่องสำรองทำหน้าที่ตรวจสอบและพร้อมสลับทันทีถ้าเกิดเหตุ นี่คือหัวใจของเรื่องนี้ ไม่ใช่แค่เพิ่มจำนวนเครื่อง แต่คือการออกแบบให้เกิดความซ้ำซ้อนที่มีบทบาทชัดเจน จุดสำคัญที่มือใหม่มักพลาดคือคิดว่าใช้บริการคลาวด์แล้วระบบพร้อมใช้งานสูงโดยอัตโนมัติ ความจริงคือบริการอาจล่ม อาจมีข้อจำกัดของงานพร้อมกัน หรือรันเนอร์ที่ตั้งเองอาจตายเพราะหน่วยความจำเต็ม การวางแผนให้รองรับความล้มเหลวต้องเริ่มจากการเข้าใจว่าจุดล้มเหลวอยู่ตรงไหนบ้าง

ก่อนจะเขียนไฟล์การตั้งค่าอะไรทั้งสิ้น ต้องประเมินสภาพแวดล้อมให้ชัดก่อนว่าเราจะใช้รันเนอร์ที่บริการให้มา หรือจะตั้งรันเนอร์ของเราเอง

ถ้าเป้าหมายคือความพร้อมใช้งานสูงจริง ๆ ผมแนะนำให้ผสมทั้งสองแบบ ใช้รันเนอร์ของบริการเป็นหลักและมีรันเนอร์ตั้งเองเป็นเสริม กรณีงานเชื่อมต่อกับฐานข้อมูลภายในหรือต้องการความเร็วพิเศษ สำหรับสเปกเครื่องที่ใช้ตั้งรันเนอร์เอง ผมสรุปจากประสบการณ์ตั้งระบบให้หลายองค์กรไว้ดังตารางนี้

ก่อนจะเขียนไฟล์การตั้งค่าอะไรทั้งสิ้น ต้องประเมินสภาพแวดล้อมให้ชัดก่อนว่าเราจะใช้รันเนอร์ที่บริการให้มา หรือจะตั้งรันเนอร์ของเราเอง ถ้าเป้าหมายคือความพร้อมใช้งานสูงจริง ๆ ผมแนะนำให้ผสมทั้งสองแบบ ใช้รันเนอร์ของบริการเป็นหลักและมีรันเนอร์ตั้งเองเป็นเสริม กรณีงานเชื่อมต่อกับฐานข้อมูลภายในหรือต้องการความเร็วพิเศษ สำหรับสเปกเครื่องที่ใช้ตั้งรันเนอร์เอง ผมสรุปจากประสบการณ์ตั้งระบบให้หลายองค์กรไว้ดังตารางนี้

องค์ประกอบ	ขั้นต่ำ	แนะนำสำหรับใช้งานจริง
หน่วยประมวลผล	2 แกน	16 แกนขึ้นไป
หน่วยความจำ	4 กิกะไบต์	8 กิกะไบต์ขึ้นไป
พื้นที่จัดเก็บ	50 กิกะไบต์ แบบเอสเอสดี	50 กิกะไบต์ขึ้นไป แบบเอ็นวีเมมเอสเอสดี
ระบบปฏิบัติการ	อูบันตู 22.04 ขึ้นไป	อูบันตู 24.04 แบบยาว
เครือข่าย	100 เมกะบิต	1 กิกะบิตขึ้นไป

เวลาตั้งเครื่อง ผมมีขั้นตอนพื้นฐานที่ทำเสมอ เริ่มจากปรับปรุงระบบให้ทันสมัยด้วยคำสั่งอัปเดตและอัปเกรด จากนั้นติดตั้งเครื่องมือพื้นฐานที่จำเป็นเช่นเครื่องมือดาวน์โหลด เครื่องมือจัดการเข้ารหัส ตัวจัดการแพ็กเกจเพิ่มเติม และเครื่องมือประมวลผลข้อความอย่างเจสัน ขั้นตอนพวกนี้ฟังดูธรรมดาแต่ลืมบ่อยมาก แล้วเจอปัญหาว่างานสั่งรันแล้วตายกลางทางเพราะขาดเครื่องมือบางตัว สำหรับฝั่งระบบตระกูลแดหัวแดงก็ใช้แนวทางเดียวกัน เพียงเปลี่ยนตัวจัดการแพ็กเกจเป็นแบบดีเอ็นเอฟ

หัวใจของการออกแบบให้พร้อมใช้งานสูงคือการกำหนดเป้าหมายสองตัวเลขให้ชัด คือเวลากู้คืนและจุดกู้คืนข้อมูล เวลากู้คืนคือยอมรับได้ว่าระบบหยุดได้นานแค่ไหน ส่วนจุดกู้คืนข้อมูลคือยอมเสียข้อมูลได้มากแค่ไหน ทีมที่ไม่กำหนดสองตัวนี้ไว้ล่วงหน้าจะทำงานไปลุยกันเป้าหมายกันเองในภายหลัง จากประสบการณ์ ทีมส่วนใหญ่ควรตั้งเวลากู้คืนที่แอปพลิเคชันไม่เกินห้าวินาทีด้วยการมีสำเนาหลายชุดวางหลังตัวกระจายโหลด ฐานข้อมูลยอมรับได้ที่ไม่เกินสามสิบวินาทีด้วยระบบหลักและสำเนาที่สลับอัตโนมัติ และส่วนจัดเก็บไฟล์ตั้งเป้ากู้ภายในหนึ่งชั่วโมงด้วยการสำรองข้อมูลประจำวันไปยังคลาวด์ การกำหนดตัวเลขเหล่านี้ยังช่วยให้เราเลือกเครื่องมือถูก เพราะบางเครื่องมือเหมาะกับเวลากู้คืนระดับนาที บางตัวทำได้ระดับวินาทีเท่านั้น

เมื่อโครงสร้างพร้อมแล้ว ขั้นถัดไปคือการเขียนไฟล์การตั้งค่าให้ใช้กลไกแจกแจงค่าอย่างเต็มที่ หลักการของผมคือแจกแจงค่าตามมิติที่มีความเสี่ยงจริง

ไม่ใช่แจกแจงเพื่อความสวยงาม ตัวอย่างเช่นระบบของผมต้องรองรับทั้งระบบลินุกซ์และวินโดวส์ เพราะแพลตฟอร์มเทรดบางตัวรันเฉพาะวินโดวส์ ดังนั้นมิติแรกที่แจกแจงคือระบบปฏิบัติการ มิติที่สองคือภูมิภาคที่รันเนอร์อยู่ การรันงานเดียวกันบนสองภูมิภาคพร้อมกันเป็นการสร้างความซ้ำซ้อนที่มีความหมายจริง ไม่ใช่แค่ทดสอบเยอะขึ้น

เขียนการตั้งค่า Matrix ให้กระจายความเสี่ยงอย่างมีประสิทธิภาพ

เมื่อโครงสร้างพร้อมแล้ว ขั้นถัดไปคือการเขียนไฟล์การตั้งค่าให้ใช้กลไกแจกแจงค่าอย่างเต็มที่ หลักการของผมคือแจกแจงค่าตามมิติที่มีความเสี่ยงจริง ไม่ใช่แจกแจงเพื่อความสวยงาม ตัวอย่างเช่นระบบของผมต้องรองรับทั้งระบบลินุกซ์และวินโดวส์ เพราะแพลตฟอร์มเทรดบางตัวรันเฉพาะวินโดวส์ ดังนั้นมิติแรกที่แจกแจงคือระบบปฏิบัติการ มิติที่สองคือภูมิภาคที่รันเนอร์อยู่ การรันงานเดียวกันบนสองภูมิภาคพร้อมกันเป็นการสร้างความซ้ำซ้อนที่มีความหมายจริง ไม่ใช่แค่ทดสอบเยอะขึ้น

strategy: fail-fast: false max-parallel: 6 matrix: os: [ubuntu-latest, windows-latest] region: [asia, europe, us] exclude:

• os: windows-latest

region: us

จุดที่ต้องใส่ใจสูงสุดคือค่าปิดการหยุดทันทีเมื่อเกิดความล้มเหลว ค่าเริ่มต้นของระบบคือถ้างานหนึ่งล้มเหลว งานที่เหลือทั้งหมดจะถูกยกเลิกทันที ซึ่งตรงข้ามกับเป้าหมายความพร้อมใช้งานสูงโดยสิ้นเชิง เพราะถ้าเครื่องแรกล้มเหลวเพราะปัญหาเครือข่าย งานที่เหลือซึ่งอาจรันได้ปกติก็ถูกยกเลิกไปด้วย การตั้งค่าให้ไม่หยุดทันทีเมื่อเกิดความล้มเหลวคือหัวใจที่ทำให้กลไกนี้กลายเป็นเครื่องมือกระจายความเสี่ยงได้จริง และการกำหนดจำนวนงานสูงสุดที่รันพร้อมกันช่วยควบคุมไม่ให้เราโดนจำกัดโควตาของบริการ

สำหรับงานที่ต้องการความแม่นยำสูงเช่นการคำนวณสัญญาณ ผมมีรูปแบบที่ใช้ประจำคือรันงานคำนวณเดียวกันสองครั้งบนเครื่องต่างกัน แล้วให้งานต่อไปเทียบผลลัพธ์กัน ถ้าผลตรงกันคือพร้อมเผยแพร่ ถ้าไม่ตรงกันแปลว่ามีบางอย่างผิดปกติเช่นข้อมูลที่ดึงมาไม่ตรงกันหรือค่าตั้งเริ่มต้นคลาดเคลื่อน ให้แจ้งเตือนและยกเลิกการเผยแพร่ นี่คือการสร้างระบบตรวจสอบข้ามจากการทำงานซ้ำซ้อนโดยตรง

jobs: compute: strategy: fail-fast: false matrix: replica: [1, 2] runs-on: ${{ matrix.replica == 1 && 'runner-asia' || 'runner-europe' }} timeout-minutes: 15 steps:

• uses: actions/checkout@v4
• name: คำนวณและส่งผล

run: ./compute.sh --replica ${{ matrix.replica }} verify: needs: [compute] runs-on: ubuntu-latest steps:

• name: เทียบผลจากสำเนาทั้งสอง

run: ./verify.sh

ส่วนที่คนมักลืมคือตัวรันเนอร์ไม่ใช่จุดล้มเหลวเดียว ระบบที่งานเหล่านี้เชื่อมต่อกันคือฐานข้อมูล แคช และตัวกระจายโหลด ต้องออกแบบให้ทนต่อความล้มเหลวด้วย

แนวทางที่ผมใช้ในงานจริงคือวางระบบด้วยการจัดกลุ่มคอนเทนเนอร์แบบกระจาย โดยตัวแอปวางสำเนาสามตัววางหลังตัวกระจายโหลด ฐานข้อมูลใช้โพสต์เกรสเอสคิวแอลแบบหลักพร้อมสำเนาที่สลับอัตโนมัติ และแคชใช้เรดิสแบบมีผู้เฝ้าระวังสำหรับสลับหลักอัตโนมัติ

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

ติดตั้งระบบสนับสนุน ฐานข้อมูล และแคชให้ทนต่อความล้มเหลว

ส่วนที่คนมักลืมคือตัวรันเนอร์ไม่ใช่จุดล้มเหลวเดียว ระบบที่งานเหล่านี้เชื่อมต่อกันคือฐานข้อมูล แคช และตัวกระจายโหลด ต้องออกแบบให้ทนต่อความล้มเหลวด้วย แนวทางที่ผมใช้ในงานจริงคือวางระบบด้วยการจัดกลุ่มคอนเทนเนอร์แบบกระจาย โดยตัวแอปวางสำเนาสามตัววางหลังตัวกระจายโหลด ฐานข้อมูลใช้โพสต์เกรสเอสคิวแอลแบบหลักพร้อมสำเนาที่สลับอัตโนมัติ และแคชใช้เรดิสแบบมีผู้เฝ้าระวังสำหรับสลับหลักอัตโนมัติ

version: '3.8' services: app: deploy: replicas: 3 resources: limits: cpus: '16.0' memory: 8G restart_policy: condition: on-failure delay: 5s max_attempts: 3 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 10s timeout: 5s retries: 3 depends_on: db: condition: service_healthy redis: condition: service_healthy db: image: postgres:16-alpine volumes:

• db_data:/var/lib/postgresql/data

environment: POSTGRESPASSWORDFILE: /run/secrets/db_password redis: image: redis:7-alpine command: redis-server --maxmemory 512mb --maxmemory-policy allkeys-lru --appendonly yes volumes: db_data: redis_data:

การวางระบบที่พร้อมใช้งานสูงไม่ได้จบที่การติดตั้ง แต่จบที่การเฝ้าดูที่ดี ระบบที่ไม่มีการเฝ้าดูคือระบบที่จะล่มแล้วเราไม่รู้จนกว่าลูกค้าโทรมา

ผมตั้งระบบเก็บตัวชี้วัดด้วยพรอมีทีอุสเสมอ เปิดเส้นทางเก็บตัวชี้วัดบนพอร์ตแยก และใช้ระบบแสดงภาพรวมเพื่อดูแนวโน้ม ตัวชี้วัดที่ผมมองเป็นอันดับแรกคืออัตราความสำเร็จของงานแต่ละชุด เวลาที่ใช้เฉลี่ยต่องาน จำนวนงานค้างในคิว และเวลาตอบสนองของฐานข้อมูล

สำหรับฐานข้อมูล ผมใช้เครื่องมือจัดการสลับหลักอัตโนมัติที่ทำงานร่วมกับตัวเฝ้าดู ถ้าหลักล้มเหลวภายในเวลาไม่กี่วินาทีระบบจะยกระดับสำเนาขึ้นเป็นหลักให้เอง และการเชื่อมต่อผ่านตัวรวมการเชื่อมต่อจะช่วยให้แอปพลิเคชันไม่ต้องเขียนโค้ดจัดการสลับเอง ส่วนแคชที่มีผู้เฝ้าระวังจะเลือกหลักใหม่เมื่อหลักเดิมไม่ตอบสนอง ทั้งหมดนี้ทำให้เวลากู้คืนอยู่ในระดับไม่กี่วินาทีถึงสิบกว่าวินาทีตามเป้าหมายที่ตั้งไว้

เรื่องการสำรองข้อมูลก็สำคัญไม่แพ้กัน ผมตั้งการสำรองแบบวันต่อวันไปยังคลาวด์ด้วยเครื่องมือที่เข้ารหัสข้อมูลก่อนส่ง และสำคัญที่สุดคือต้องทดสอบกู้คืนจริงอย่างน้อยเดือนละครั้ง ทีมจำนวนมากมีไฟล์สำรองแต่ไม่เคยทดสอบกู้คืน พอเกิดเหตุจริงกลายเป็นว่าไฟล์สำรองเสียหรือขั้นตอนกู้คืนไม่สมบูรณ์ นี่คือบทเรียนที่ผมเห็นซ้ำ ๆ มาตลอดหลายปีในการดูแลระบบ

เฝ้าดูระบบ แจ้งเตือน และปรับปรุงต่อเนื่องอย่างเป็นระบบ

การวางระบบที่พร้อมใช้งานสูงไม่ได้จบที่การติดตั้ง แต่จบที่การเฝ้าดูที่ดี ระบบที่ไม่มีการเฝ้าดูคือระบบที่จะล่มแล้วเราไม่รู้จนกว่าลูกค้าโทรมา ผมตั้งระบบเก็บตัวชี้วัดด้วยพรอมีทีอุสเสมอ เปิดเส้นทางเก็บตัวชี้วัดบนพอร์ตแยก และใช้ระบบแสดงภาพรวมเพื่อดูแนวโน้ม ตัวชี้วัดที่ผมมองเป็นอันดับแรกคืออัตราความสำเร็จของงานแต่ละชุด เวลาที่ใช้เฉลี่ยต่องาน จำนวนงานค้างในคิว และเวลาตอบสนองของฐานข้อมูล

ระบบแจ้งเตือนต้องออกแบบให้ไม่ส่งเยอะจนทีมเริ่มเมิน หลักการของผมคือแจ้งเฉพาะเมื่อเกินเกณฑ์ที่กำหนดไว้จริง เช่น อัตราความล้มเหลวของงานเกินร้อยละห้าในห้านาที หรือคิวงานยาวเกินสามสิบงาน หรือเวลาตอบสนองฐานข้อมูลเกินห้าสิบมิลลิวินาทีต่อเนื่องหนึ่งนาที การแจ้งเตือนที่ดีต้องระบุด้วยว่าเกิดที่ไหน บริการไหน และควรตรวจสอบอะไรก่อน ไม่ใช่แค่บอกว่ามีปัญหาแล้วให้เดากัน

นอกจากนี้ ผมมีการซ้อมแผนฉุกเฉินเป็นประจำด้วยการจำลองความล้มเหลวทุกเดือน ปิดรันเนอร์หลักทิ้งหนึ่งตัวแล้วดูว่าระบบกระจายงานไปที่ตัวอื่นได้ภายในเวลาเท่าไร ปิดฐานข้อมูลหลักแล้วจับเวลาว่าระบบสลับให้เองเร็วแค่ไหน การซ้อมพวกนี้เผยจุดอ่อนที่ไม่มีทางเห็นจากการอ่านเอกสารหรือไล่โค้ด เช่นเคยเจอกรณีที่หลังจากสลับฐานข้อมูลแล้วแอปยังค้างการเชื่อมต่อเดิมจนหมดเวลา ต้องปรับเวลาอายุการเชื่อมต่อให้สั้นลงถึงจะทำงานถูก

วงจรปรับปรุงของผมเป็นแบบนี้เสมอ เก็บข้อมูลจากการเฝ้าดูมาประ

คำถามที่พบบ่อย

GitHub Actions Matrix ช่วยเพิ่มความพร้อมใช้งานสูงของไปป์ไลน์ได้อย่างไร?

GitHub Actions Matrix ช่วยให้เราสั่งรันงานเดียวกันกระจายไปยังหลายสภาพแวดล้อมและหลายเครื่องพร้อมกันผ่านกลไกแจกแจงค่าในไฟล์การตั้งค่า ตัวอย่างเช่น การทดสอบโค้ดเดียวกันบนสามระบบปฏิบัติการ หรือรันทดสอบซ้ำหลายรอบผ่านเครือข่ายต่างกันเพื่อยืนยันผล ประโยชน์สำคัญคือเมื่อเครื่องใดเครื่องหนึ่งล้มเหลว เรายังมีผลจากเครื่องอื่นให้เปรียบเทียบได้ทันทีว่าปัญหาเกิดจากโค้ดหรือจากตัวเครื่องเอง ต่างจากการรันเดียวจบที่ถ้าเครื่องดับก็ต้องรันใหม่ทั้งหมด ในบริบทของการกระจายความเสี่ยง ความหมายครอบคลุมทั้งตัวรันเนอร์หลายตัว ฐานข้อมูลที่มีสำเนาสำรองพร้อมสลับใช้ และการตั้งค่าให้งานกระจายไปยังเครื่องที่พร้อมใช้งานจริง ไม่ใช่เพียงแค่เพิ่มจำนวนเครื่องเท่านั้น แต่ต้องออกแบบความซ้ำซ้อนที่แต่ละชุดมีบทบาทชัดเจน เช่น เครื่องหลักส่งผลออกไปก่อน ส่วนเครื่องสำรองทำหน้าที่ตรวจสอบและพร้อมสลับทันทีเมื่อเกิดเหตุ

ควรเลือกใช้รันเนอร์ที่บริการให้มาหรือตั้งรันเนอร์เอง แบบไหนเหมาะกับความพร้อมใช้งานสูงกว่า?

จากประสบการณ์ดูแลระบบ ผมแนะนำให้ผสมทั้งสองแบบ คือใช้รันเนอร์ของบริการเป็นหลัก และมีรันเนอร์ที่ตั้งเองเป็นเสริมในกรณีที่งานต้องเชื่อมต่อกับฐานข้อมูลภายในองค์กรหรือต้องการความเร็วพิเศษ เหตุผลคือบริการคลาวด์อาจล่ม อาจมีข้อจำกัดเรื่องจำนวนงานพร้อมกัน หรือรันเนอร์ที่ตั้งเองอาจตายเพราะหน่วยความจำเต็ม หลายคนเข้าใจผิดว่าใช้คลาวด์แล้วระบบจะมีความพร้อมใช้งานสูงโดยอัตโนมัติ ซึ่งไม่เป็นความจริงเสมอไป การวางแผนต้องเริ่มจากการระบุจุดล้มเหลวทั้งหมดก่อน สำหรับสเปกเครื่องที่ตั้งรันเนอร์เองเพื่อใช้งานจริง ควรใช้หน่วยประมวลผลอย่างน้อย 16 แกน หน่วยความจำ 8 กิกะไบต์ขึ้นไป พื้นที่จัดเก็บแบบเอ็นวีเมมเอสเอสดี 50 กิกะไบต์ขึ้นไป ระบบปฏิบัติการอูบันตู 24.04 แบบยาว และเครือข่าย 1 กิกะบิตขึ้นไป อีกทั้งอย่าลืมติดตั้งเครื่องมือพื้นฐาน เช่น เครื่องมือดาวน์โหลด เครื่องมือจัดการเข้ารหัส และเครื่องมือประมวลผลข้อความอย่างเจสัน ซึ่งลืมติดตั้งบ่อยมากจนงานตายกลางทาง

เวลากู้คืน (RTO) และจุดกู้คืนข้อมูล (RPO) คืออะไร และควรตั้งเป้าไว้เท่าไรดี?

เวลากู้คืนคือระยะเวลาที่ยอมรับได้ว่าระบบหยุดทำงานได้นานแค่ไหน ส่วนจุดกู้คืนข้อมูลคือปริมาณข้อมูลที่ยอมเสียได้มากแค่ไหนเมื่อเกิดเหตุล้มเหลว การกำหนดสองตัวเลขนี้ให้ชัดเจนก่อนลงมือเป็นหัวใจของการออกแบบความพร้อมใช้งานสูง เพราะทีมที่ไม่กำหนดไว้ล่วงหน้าจะทำงานไปแล้วลุยกันเองเรื่องเป้าหมายในภายหลัง จากประสบการณ์ ทีมส่วนใหญ่ควรตั้งเวลากู้คืนของแอปพลิเคชันไม่เกินห้าวินาที ด้วยการมีสำเนาหลายชุดวางอย

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6