SASE Framework Disaster Recovery Plan — แผนกู้คืนระบบเครือข่ายปลอดภัย | SiamCafe Blog

SASE คืออะไร และทำไมแผนกู้คืนระบบถึงสำคัญกับสถาปัตยกรรมนี้

SASE หรือ Secure Access Service Edge คือโมเดลการจัดการความปลอดภัยเครือข่ายแบบรวมศูนย์บนคลาวด์ ที่ผนวกทั้ง SD-WAN, ZTNA, CASB, SWG และ

Firewall-as-a-Service เข้าไว้ในบริการเดียว ทำให้องค์กรไม่ต้องติดตั้งอุปกรณ์หลายชิ้นที่สาขา แต่เชื่อมต่อเข้าจุดให้บริการของผู้ให้บริการโดยตรง ผม อ.บอม ที่เทรดฟอเร็กซ์มา 13 ปีและดูแลระบบไอทีของทีมมาตลอด มองว่า SASE เหมือนการเปิดบัญชีกับโบรกเกอร์ที่มีเซิร์ฟเวอร์กระจายทั่วโลก — เราไม่ต้องสนใจว่าระบบอยู่ที่ไหน ขอแค่เข้าถึงได้เร็วและปลอดภัย

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

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

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

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

ผลกระทบต่อผู้ใช้ต่างกันโดยสิ้นเชิง

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

องค์ประกอบหลักมีห้าส่วน หนึ่งคือ SD-WAN ซึ่งทำหน้าที่จัดการเส้นทางข้อมูลระหว่างสาขากับคลาวด์ สองคือจุดให้บริการ SASE หรือ PoP ที่กระจายอยู่ตามภูมิภาค สามคือ ZTNA ประตูเข้าถึงแอปพลิเคชันโดยไม่ต้องผ่านเครือข่ายส่วนตัวเดิม สี่คือผู้ให้บริการยืนยันตัวตนหรือ IdP เช่น Okta หรือ Microsoft Entra ซึ่งเป็นหัวใจเพราะถ้ายืนยันตัวตนไม่ได้ ทุกอย่างหยุดหมด และห้าคือระบบชื่อโดเมนหรือ DNS ที่นำทางทราฟฟิกไปยังปลายทางที่ถูกต้อง

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

หัวใจของแผนกู้คืนทุกฉบับคือตัวเลขสองตัว ตัวแรกคือ RTO หรือ Recovery Time Objective

คือระยะเวลาสูงสุดที่ระบบหยุดทำงานแล้วยอมรับได้ก่อนเกิดความเสียหายร้ายแรง ตัวที่สองคือ RPO หรือ Recovery Point Objective คือปริมาณข้อมูลสูงสุดที่ยอมเสียไป วัดจากช่วงเวลาห่างระหว่างการสำรองข้อมูลล่าสุดกับจุดที่เกิดเหตุ

เข้าใจ RTO และ RPO ตัวชี้วัดชี้ขาดความสำเร็จของแผน

หัวใจของแผนกู้คืนทุกฉบับคือตัวเลขสองตัว ตัวแรกคือ RTO หรือ Recovery Time Objective คือระยะเวลาสูงสุดที่ระบบหยุดทำงานแล้วยอมรับได้ก่อนเกิดความเสียหายร้ายแรง ตัวที่สองคือ RPO หรือ Recovery Point Objective คือปริมาณข้อมูลสูงสุดที่ยอมเสียไป วัดจากช่วงเวลาห่างระหว่างการสำรองข้อมูลล่าสุดกับจุดที่เกิดเหตุ

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

ตารางตัวอย่างเป้าหมายการกู้คืนสำหรับระบบ SASE ในองค์กรขนาดกลางมีลักษณะแบบนี้

องค์ประกอบ	ระบบหลัก	ระบบสำรอง	RTO เป้าหมาย	RPO เป้าหมาย
SD-WAN	สายไฟเบอร์ค่ายหลัก	สายไฟเบอร์ค่ายรอง พร้อม 4G/5G	ภายใน 30 วินาที	0 (แบบเรียลไทม์)
จุดให้บริการ SASE	จุดใกล้ที่สุด	จุดใกล้รองในภูมิภาคอื่น	ภายใน 60 วินาที	0
ZTNA Gateway	ภูมิภาคหลัก	ภูมิภาคสำรอง	ภายใน 5 นาที	0
ผู้ให้บริการยืนยันตัวตน	Okta	Microsoft Entra (สำรอง)	ภายใน 15 นาที	ไม่เกิน 5 นาที
DNS	Cloudflare	Route53 (สำรอง)	ภายใน 60 วินาที	0

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

ๆ ไม่ใช่สองสายจากค่ายเดียวกันที่วิ่งผ่านหลุมเดียวกันแล้วโดนแมวกัดทีเดียวหลุดพร้อมกันทั้งคู่ เพิ่ม 4G/5G เป็นชั้นสุดท้ายสำหรับเหตุฉุกเฉิน ระบบ SD-WAN รุ่นใหม่สลับเส้นทางอัตโนมัติภายในไม่กี่วินาทีเมื่อตรวจพบสายหลักขาด

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

กลยุทธ์การสำรองระบบทีละชั้น จากสายอินเทอร์เน็ตถึงระบบยืนยันตัวตน

การทำให้ระบบ SASE ทนทาน ต้องสำรองเป็นชั้น ๆ จากล่างขึ้นบน ชั้นแรกคือเส้นทางอินเทอร์เน็ต ทุกสาขาควรมีสายจากผู้ให้บริการสองรายที่ใช้โครงข่ายต่างกันจริง ๆ ไม่ใช่สองสายจากค่ายเดียวกันที่วิ่งผ่านหลุมเดียวกันแล้วโดนแมวกัดทีเดียวหลุดพร้อมกันทั้งคู่ เพิ่ม 4G/5G เป็นชั้นสุดท้ายสำหรับเหตุฉุกเฉิน ระบบ SD-WAN รุ่นใหม่สลับเส้นทางอัตโนมัติภายในไม่กี่วินาทีเมื่อตรวจพบสายหลักขาด

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

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

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

การทดสอบแผนกู้คืน จากการซักซ้อมบนโต๊ะถึงการจำลองเหตุจริง

แผนที่ไม่เคยทดสอบเท่ากับไม่มีแผน ประโยคนี้ผมพูดจนปากบ่อยเพราะเห็นความพังทลายจริงมาหลายครั้ง การทดสอบแบ่งเป็นสี่ระดับที่ค่อยเพิ่มความเข้มข้นขึ้น

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

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

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

รันบุ๊กและการนำไปใช้งานจริงในองค์กร

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

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

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

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

ตัวอย่างการลงมือทำ แผน 90 วันสู่ระบบกู้คืนที่พร้อมใช้จริง

ถ้าองค์กรของคุณยังไม่มีแผนกู้คืนสำหรับ SASE เลย อย่ารอความพร้อมแบบสมบูรณ์ เริ่มจากแผน 90 วันแบบนี้ได้ทันที

ใน 30 วันแรก ทำสิ่งสามอย่าง หนึ่ง จัดทำรายการองค์ประกอบของ SASE ทั้งหมดที่องค์กรใช้ พร้อมผู้ให้บริการและสัญญาที่เกี่ยวข้อง สอง ประเมินกับเจ้าของธุรกิจว่าระบบไหนหยุดได้นานแค่ไหน กำหนดเป้าหมาย RTO และ RPO เป็นลายลักษณ์อักษร สาม ตรวจว่า

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

SASE คืออะไร และทำไมต้องมีแผนกู้คืนระบบสำหรับสถาปัตยกรรมนี้?

SASE หรือ Secure Access Service Edge คือโมเดลการจัดการความปลอดภัยเครือข่ายแบบรวมศูนย์บนคลาวด์ ที่ผนวก SD-WAN, ZTNA, CASB, SWG และ Firewall-as-a-Service เข้าไว้ในบริการเดียว ทำให้องค์กรไม่ต้องติดตั้งอุปกรณ์หลายชิ้นที่สาขา แต่เชื่อมต่อเข้าจุดให้บริการของผู้ให้บริการโดยตรง อย่างไรก็ตาม ความสะดวกแบบรวมศูนย์นี้มีดาบสองคม เมื่อทุกอย่างไหลผ่านจุดเดียว จุดนั้นกลายเป็นคอขวดและจุดล้มเหลวเดียวที่ถ้าพังทีเดียวพังทั้งระบบ หาก SASE ล่ม พนักงานทั้งบริษัทจะเข้าถึงระบบงานไม่ได้ การขายหยุดชะงัก และในฝั่งการเงินหรือการเทรด การเข้าถึงแพลตฟอร์มที่หยุดแม้ 10 นาทีอาจแปลเป็นความขาดทุนจำนวนมาก ดังนั้นแผนกู้คืนระบบจึงต้องออกแบบไปพร้อมกับสถาปัตยกรรมตั้งแต่วันแรก ไม่ใช่ทำทีหลัง โดยทุกองค์ประกอบต้องมีสำรองอย่างน้อยหนึ่งชั้น เช่น สายอินเทอร์เน็ตสองค่าย จุดให้บริการสำรองในภูมิภาคอื่น และผู้ให้บริการยืนยันตัวตนสำรอง

องค์ประกอบของ SASE ที่ต้องมีแผนสำรองมีอะไรบ้าง?

ระบบ SASE ประกอบด้วยองค์ประกอบหลักห้าส่วนที่ต้องวางแผนสำรอง หนึ่งคือ SD-WAN ที่ทำหน้าที่จัดการเส้นทางข้อมูลระหว่างสาขากับคลาวด์ สองคือจุดให้บริการ SASE หรือ PoP ที่กระจายตามภูมิภาค สามคือ ZTNA ซึ่งเป็นประตูเข้าถึงแอปพลิเคชันโดยไม่ต้องผ่านเครือข่ายส่วนตัวเดิม สี่คือผู้ให้บริการยืนยันตัวตนหรือ IdP เช่น Okta หรือ Microsoft Entra ซึ่งถือเป็นหัวใจของระบบ เพราะถ้ายืนยันตัวตนไม่ได้ ทุกอย่างจะหยุดหมด และห้าคือระบบ DNS ที่นำทางทราฟฟิกไปยังปลายทางที่ถูกต้อง นอกจากนี้ยังมีส่วนที่คนมักลืมคือไฟล์ตั้งค่าและนโยบายความปลอดภัยทั้งหมด ทั้งกฎการกรอง กฎการอนุญาตเข้าถึง และกฎการแบ่งเซกเมนต์เครือข่าย ถ้าสิ่งเหล่านี้สูญหาย แม้ฮาร์ดแวร์กลับมาปกติก็ไม่รู้ว่าต้องตั้งค่าใหม่อย่างไร จึงแนะนำให้ทำตารางสรุประบบหลัก ระบบสำรอง เวลากู้คืน และข้อมูลที่ยอมเสียได้ของแต่ละองค์ประกอบ เพื่อให้ทีมเวรใช้ตัดสินใจได้จริงเวลาเกิดเหตุ

RTO และ RPO คืออะไร และเกี่ยวข้องกับแผนกู้คืนระบบ SASE อย่างไร?

RTO หรือ Recovery Time Objective คือระยะเวลาสูงสุดที่ระบบหยุดทำงานแล้วยอมรับได้ก่อนเกิดความเสียหายร้ายแรง ส่วน RPO หรือ Recovery Point Objective คือปริมาณข้อมูลสูงสุดที่ยอมเสียไป วัดจากช่วงเวลาห่างระหว่างการสำรองข้อมูลล่าสุดกับจุดที่เกิดเหตุ ทั้งสองตัวนี้คือหัวใจของแผนกู้คืนทุกฉบับ การกำหนดค่าต้องขึ้นอยู่กับลักษณะของแต่ละระบบ เช่น ระบบส่งคำสั่งซื้อขายในงานเทรดอาจต้องมี RTO ไม่เกิน 30 วินาที เพราะตลาดเคลื่อนทุกวินาที แต่ระบบรายงานภายในอาจยอมรับ RTO ได้ถึง 4 ชั่วโมงโดยไม่เสียหายมาก สิ่งสำคัญคือตัวเลขเหล่านี้ต้องกำหนดร่วมกับเจ้าของธุรกิจ ไม่ใช่ให้ทีมไอทีเดาเอง เพราะทุกคร

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

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

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

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

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

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