วันที่ 24 กันยายน 2026 กรมสรรพากรญี่ปุ่นอัปเกรดระบบภาษีของประเทศครั้งใหญ่ หลังจากนั้นเคาน์เตอร์ที่สำนักงานสรรพากรใช้เวลา "นานพอสมควร" ในการรับชำระเงินสดและออกใบรับรองการชำระภาษี ส่วน e-Tax ซึ่งเป็นระบบยื่นภาษีออนไลน์ก็มีข้อขัดข้องหลายจุดและต้องปิดปรับปรุงฉุกเฉินต่อเนื่อง ระบบรวมศูนย์ขนาดยักษ์ที่ไม่เสถียรหลังสลับระบบใหม่ เป็นเรื่องที่คนเคยแตะระบบกระจายศูนย์หรือระบบอัตโนมัติยิ่งเข้าใจได้ง่าย แต่ "เข้าใจว่ามันพังได้" กับ "ตอนพังมีทางหนีที่เพียงพอ" เป็นคนละเรื่องกัน
สมมติว่าคุณกำลังรีบทำเรื่องหนึ่ง แล้วเจ้าหน้าที่ที่เคาน์เตอร์บอกว่า "ระบบทั้งหมดมีปัญหา ยังไม่ทราบว่าจะกลับมาใช้ได้เมื่อไร ถ้ารีบก็มาที่สำนักงานได้ เราจะดำเนินการให้"
ปกติเราก็คงคิดว่า "งั้นก็ไปเลยสิ"
แต่ลองคิดต่ออีกนิด จะเห็นภาพที่ไม่น่าอภิรมย์
คนที่ทำออนไลน์หรือผ่านช่องทางปกติไม่ได้จะไหลมาที่เคาน์เตอร์ ขณะที่ฝั่งเจ้าหน้าที่ ระบบก็รวนจนงานแต่ละรายการช้าลง คนมามากขึ้น แต่กำลังในการทำงานกลับลดลง
"มาแล้วดำเนินการให้ได้" ไม่ได้แปลว่า "มาแล้วเสร็จในพริบตา"
สุดท้ายถ้ากำหนดเวลายังเหลือเฟือ การรอก็กลายเป็นการตัดสินใจที่สมเหตุสมผลมากทีเดียว
แล้วในใจก็อดร้องไม่ได้ว่า
"รับเป็นกระดาษไปเลยเถอะ ขอร้อง"
แต่กระดาษไม่ใช่ฐานข้อมูลสำรองวิเศษ
1. เดือนกันยายน 2026 เกิดอะไรขึ้น
กรมสรรพากรอัปเกรดระบบภาษีแห่งชาติเมื่อวันที่ 24 กันยายน 2026 ก่อนหน้านี้ กรมเคยระบุแนวคิดการพัฒนาระบบรุ่นใหม่ KSK2 ไว้สามข้อ
- เปลี่ยนจากงานที่ยึดเอกสารกระดาษเป็นหลัก ไปเป็นงานที่ยึดข้อมูลเป็นหลัก
- รวมฐานข้อมูลและแอปพลิเคชันที่เคยแยกตามประเภทภาษีเข้าด้วยกัน
- เปลี่ยนจากระบบที่เน้นเมนเฟรมซึ่งใช้ระบบปฏิบัติการเฉพาะของผู้ผลิต ไปเป็นระบบเปิดที่ใช้ระบบปฏิบัติการทั่วไป
พูดง่าย ๆ คือไม่ใช่แค่ปรับหน้าจอใหม่ แต่เป็นการอัปเกรดใหญ่ที่เปลี่ยนทั้งวิธีเก็บข้อมูล ขอบเขตของแอปพลิเคชัน และโครงสร้างพื้นฐานไปพร้อมกัน
ในวันที่ 24 กันยายน ซึ่งเป็นวันอัปเกรดนั่นเอง กรมสรรพากรได้ประกาศเรื่อง "ความล่าช้าของขั้นตอนต่าง ๆ ที่เคาน์เตอร์สำนักงานสรรพากร" โดยอธิบายว่าการรับชำระเงินสดและการออกใบรับรองการชำระภาษีใช้เวลานานพอสมควร และแม้จะขอใบรับรองผ่าน e-Tax ก็ยังออกให้ทันทีไม่ได้ ตัวการอัปเกรดเสร็จสิ้นแล้ว แต่การทำงานของระบบที่งานเคาน์เตอร์ต้องใช้มีปัญหา
ในสัปดาห์เดียวกันที่สลับระบบ ยังมีปัญหาล็อกอินผ่าน Mynaportal (พอร์ทัลบริการออนไลน์ของรัฐที่ผูกกับบัตรประจำตัวประชาชนแบบ My Number) ปัญหาการแสดงผลว่าชำระเสร็จเมื่อจ่ายผ่านอินเทอร์เน็ตแบงก์กิ้ง การหยุดทำงานของฟังก์ชันบางส่วนใน e-Tax และการปิดปรับปรุงฉุกเฉินเพื่อแก้ไขข้อขัดข้อง ส่วนการหยุดทำงานของฟังก์ชันบางส่วนใน e-Tax มีประกาศว่าแก้ไขเรียบร้อยภายในวันที่ 27 กันยายน
ส่วนประกาศเรื่องความล่าช้าที่เคาน์เตอร์ ก็ยังคงอยู่ในหน้าข้อมูลฉุกเฉินของเว็บไซต์กรมสรรพากรจนถึงวันที่ 28 กันยายน และ ณ จุดนั้นยังไม่มีการเปิดเผยสาเหตุที่แท้จริงอย่างละเอียด
อีกเรื่องที่สำคัญคืออย่าสับสนระหว่างการปิดปรับปรุงตามแผนกับความขัดข้อง การอัปเกรดครั้งนี้มีแผนปิดระบบยาวตั้งแต่เวลา 0:00 น. ของวันที่ 19 ถึง 8:30 น. ของวันที่ 24 และปิดทั้งวันในวันที่ 26 กันยายนอยู่แล้ว จากนั้นข้อขัดข้องหลังสลับระบบและการปิดปรับปรุงฉุกเฉินก็มาซ้อนทับเข้ามา
ดังนั้นการรู้สึกว่า "ระบบหยุดอยู่ตลอดเลยหรือเปล่า" จึงเป็นเรื่องธรรมดา เพราะในนั้นมีทั้งการหยุดตามแผนและการหยุดจากความขัดข้องปนกันอยู่
2. ระบบที่ดูแลเงินก็พังได้ และบางทีก็ต้องหยุดเองด้วยเหตุผลนั้นแหละ
"ถ้าเป็นระบบที่ดูแลภาษีและเงิน เขาน่าจะสร้างให้ไม่ล่มเด็ดขาดไม่ใช่หรือ"
สัญชาตญาณก็บอกแบบนั้น
แต่ระบบสำคัญไม่ได้มีแค่ความพร้อมใช้งาน ยังมีความถูกต้องสอดคล้องของข้อมูลด้วย
ตัวอย่างเช่น สิ่งที่น่ากลัวที่สุดในการรับชำระภาษีไม่ใช่แค่หน้าจอเปิดไม่ได้ห้านาที แต่เป็นสิ่งเหล่านี้
- จ่ายไปแล้วแต่ถูกนับว่ายังไม่ได้จ่าย
- รายการเดียวถูกบันทึกซ้ำสองครั้ง
- ออกใบรับรองโดยอ้างอิงข้อมูลเก่า
- ระบบหนึ่งอัปเดตแล้ว อีกระบบถูกทิ้งไว้ข้างหลัง
- หลังกู้ระบบ พอรันซ้ำก็ทำรายการเดิมอีกรอบ
ในสภาพแบบนี้ "ปล่อยให้ระบบเดินต่อไปก่อน" บางครั้งอันตรายกว่าการหยุดเสียอีก
เอกสาร SRE ของ Google (วิศวกรรมความเชื่อถือได้ของระบบ) ก็อธิบายไว้ว่า เมื่อเกิดความขัดข้องใหญ่ ควรหยุดความเสียหายไม่ให้ลามก่อนการค้นหาสาเหตุ และถ้ามีโอกาสที่ข้อมูลจะเสียหาย การตรึงระบบไว้ (freeze) อาจเป็นทางเลือกที่ดีกว่า
ไม่ใช่ว่าระบบเกี่ยวกับเงินแล้วเลยหยุด
แต่เพราะเกี่ยวกับเงิน จึงบางครั้งต้องตัดสินใจหยุด แทนที่จะปล่อยให้เดินต่อทั้งที่รับประกันความถูกต้องไม่ได้
ถ้า "ลองรีสตาร์ทหรือยัง" แก้ได้ทุกอย่าง ผู้ดูแลระบบหลักของประเทศคงได้กลับบ้านเร็วกว่านี้เยอะ
3. ผ่านการทดสอบทีละส่วนครบแล้ว พอรวมระบบก็ยังระเบิดได้เป็นปกติ
ความน่ากลัวของระบบรวมศูนย์คือ ต่อให้ทุกชิ้นส่วนปกติดี พอรวมกันก็ยังพังได้
ระบบ A ปกติ
ระบบ B ก็ปกติ
ฐานข้อมูลก็ปกติ
การยืนยันตัวตนก็ปกติ
แต่ถ้ารูปแบบข้อมูลที่ส่งจาก A ไป B ผิดไปแค่ตัวอักษรเดียว ระบบก็หยุด
ถ้าข้อมูลที่ย้ายจากระบบเก่ามาระบบใหม่มีค่าที่ผิดปกติ ระบบก็หยุด
ถ้าระหว่างการลองส่งซ้ำ มีแต่คำตอบที่หายไป เราก็จะไม่รู้ว่ารายการนั้น "ถูกประมวลผลแล้วหรือยัง"
แคชเก่า แบบฟอร์มเก่า การเชื่อมต่อกับหน่วยงานภายนอก สิทธิ์การเข้าถึง เวลา งานแบตช์ การเข้ารหัสอักขระ ตัวอักษรแบบโบราณ การส่งซ้ำตอนเกิดข้อขัดข้อง ยิ่งมีรอยต่อมาก การผสมผสานที่มองไม่เห็นตอนทดสอบทีละส่วนก็ยิ่งเพิ่มขึ้น
แค่ระบบอัตโนมัติเล็ก ๆ ของคนทั่วไป ก็ยังพังง่ายเพราะสถานะเก่า การรันซ้ำสองครั้ง งานตกหล่น ความต่างของ API ภายนอก และผลข้างเคียงจากการลองซ้ำ
แล้วนี่คือเรื่องแบบเดียวกัน แต่ทำกับระบบหลักที่ครอบคลุมสำนักงานสรรพากรทั่วประเทศ ภาษีหลายประเภท การรับชำระ การคืนภาษี การออกใบรับรอง e-Tax และหน่วยงานภายนอก
คนที่รู้ว่าการรวมระบบยากแค่ไหนก็จะคิดว่า "ช่วงเพิ่งสลับระบบ ต้องมีอะไรโผล่มาบ้างแหละ"
แต่นั่นไม่ใช่ใบอนุญาตให้พ้นผิด
สิ่งที่ควรประเมินไม่ใช่แค่ "ไม่มีข้อขัดข้องเลยสักเรื่องหรือเปล่า" แต่คือ "ตอนเกิดข้อขัดข้อง ลดระดับการทำงานลงอย่างปลอดภัยได้แค่ไหน"
4. ทำไมถึงบอกว่า "ยังไม่ทราบกำหนดการกลับมาใช้งาน"
นี่เป็นประโยคที่ผู้ใช้บริการรู้สึกลำบากใจที่สุดอย่างหนึ่ง
"ยังไม่กำหนดเวลากลับมาใช้งาน"
แต่ในขั้นที่ยังไม่รู้สาเหตุ การสัญญาเวลาแบบเดา ๆ ก็อันตรายไม่แพ้กัน
การกู้ระบบสำคัญไม่ได้จบแค่เปิดเซิร์ฟเวอร์ขึ้นมาได้
ขั้นแรกคือแยกให้ได้ว่าขอบเขตของความขัดข้องอยู่ตรงไหน
ต่อมาตรวจว่ามีข้อมูลที่เขียนค้างครึ่งทางหรือไม่
ตรวจว่าถ้ารันซ้ำแล้วจะไม่เกิดการประมวลผลซ้ำซ้อน
ตรวจว่าสถานะไม่ขัดแย้งกับหน่วยงานภายนอกที่เชื่อมต่ออยู่
ถ้าจำเป็นก็ต้องพิจารณาย้อนกลับไปใช้ระบบเดิม หรือหาเส้นทางสำรอง
หลังกู้ระบบแล้ว ต้องไล่ประมวลผลงานที่สะสมระหว่างหยุดไปตามลำดับ และเทียบผลให้ตรงกัน
โดยเฉพาะถ้ามีกรณีแบบ "ฝั่งผู้ส่งดูเหมือนสำเร็จ แต่ฝั่งผู้รับยังไม่ยืนยัน" ปนอยู่ จะยุ่งยากมาก
Amazon เผยแพร่หลักการออกแบบระบบกระจายศูนย์ที่อธิบายว่า ความสามารถในการส่งซ้ำได้อย่างปลอดภัยนั้นสำคัญ คือ idempotency หรือการออกแบบให้ส่งคำขอเดิมซ้ำกี่ครั้งก็ไม่เกิดผลข้างเคียงซ้ำซ้อน
การที่บอกเวลากู้ระบบไม่ได้ ไม่ใช่หลักฐานว่าผู้รับผิดชอบนั่งเฉย ๆ
ถ้ายังไม่รู้ว่าพังไปถึงไหน ย้อนกลับได้ถึงไหน และต้องเริ่มใหม่จากตรงไหนจึงจะไม่ประมวลผลซ้ำ การคาดการณ์ที่แม่นยำก็ทำได้ยากโดยธรรมชาติ
5. "ถ้ารีบให้มาที่เคาน์เตอร์" ในแง่ของการต่อคิว นี่น่ากลัวทีเดียว
ถึงตรงนี้เคาน์เตอร์ก็เข้าฉาก
แม้ระบบมีปัญหา ก็มีบางครั้งที่เขาบอกว่า "มาที่สำนักงานแล้วดำเนินการให้ได้"
นี่คือทางหนีที่น่าขอบคุณ
แต่ในมุมของเวลารอคอย เงื่อนไขที่รวมกันนั้นอันตรายมาก
ลองทำให้เรื่องปกติง่ายลง
ให้ปริมาณคนที่มาที่เคาน์เตอร์เป็น λ และปริมาณที่เจ้าหน้าที่ทำได้เป็น μ
เมื่อเกิดข้อขัดข้อง อาจเกิดสองอย่างพร้อมกัน
อย่างแรก คนที่ปกติทำออนไลน์หรือจบด้วยการประมวลผลภายในได้ ก็มาที่เคาน์เตอร์ด้วย λ จึงเพิ่มขึ้น
อย่างที่สอง เจ้าหน้าที่ใช้ระบบได้ยากขึ้น การตรวจสอบและการคีย์มือต่อรายการเพิ่มขึ้น μ จึงลดลง
ความต้องการเพิ่ม ขณะที่ความสามารถในการให้บริการลดลง
นี่คือการผสมที่เลวร้ายที่สุดสำหรับระบบคิว
และเจ้าหน้าที่สรรพากรก็ไม่ได้เพิ่มจำนวนเองอัตโนมัติเมื่อเกิดข้อขัดข้อง
เอกสาร SRE ของ Google ก็ระบุว่า เมื่อระบบใกล้โหลดเกิน ไม่ได้แค่ช้าลงเล็กน้อยเป็นเส้นตรง แต่จะแย่ลงแบบไม่เป็นเชิงเส้น เพราะเวลารอที่เพิ่มขึ้นและความล้มเหลวที่ลามต่อกันเป็นทอด ๆ ด้วยเหตุนี้การควบคุมโหลดและการตอบสนองแบบลดระดับจึงสำคัญ
"มาที่เคาน์เตอร์แล้วดำเนินการได้" ไม่ได้แปลว่า "เคาน์เตอร์ว่าง"
ถ้ากำหนดเวลายังเหลือ การไม่พุ่งไปในวันที่คนแน่นที่สุดแล้วรอให้ระบบกลับมาก่อน ก็สมเหตุสมผลเมื่อคิดถึงต้นทุนด้านเวลา
ในทางกลับกัน ถ้าเกี่ยวกับกำหนดเวลาตามกฎหมายหรือความเร่งด่วน อย่าตัดสินใจเองแล้วปล่อยไว้ ควรตรวจสอบวิธีทางเลือกจากประกาศอย่างเป็นทางการล่าสุดของกรมสรรพากรและสำนักงานสรรพากร
6. "ให้ใช้กระดาษ" ถูกแค่ครึ่งเดียว กระดาษเป็นทางหนีสำหรับการรับเรื่อง แต่ไม่ใช่ฐานข้อมูลสำรอง
ยิ่งดูความขัดข้อง ก็ยิ่งเริ่มคิดว่า
"รับเป็นกระดาษก็ได้นี่"
ความคิดนี้ไม่ได้ผิดเสียทีเดียว
คู่มือแผนความต่อเนื่องของระบบสารสนเทศของ NIST (สถาบันมาตรฐานและเทคโนโลยีแห่งชาติสหรัฐฯ) ก็ระบุว่า ในช่วงสั้น ๆ การทำงานบางส่วนหรือทั้งหมดด้วยมือเป็นวิธีประมวลผลสำรองเมื่อเกิดข้อขัดข้อง
พูดอีกอย่างคือ การทำด้วยมือเป็นมาตรการต่อเนื่องธุรกิจอย่างหนึ่งที่ถูกต้องตามหลัก
แต่ "เขียนลงกระดาษแล้วจบทุกอย่าง" ก็ไม่จริงเสมอไป
สิ่งที่กระดาษทำได้ เช่น
- บันทึกข้อเท็จจริงว่ารับคำขอหรือคำปรึกษาแล้ว
- ยืนยันวันและเวลาที่รับเรื่อง
- รับเอกสารที่จำเป็นไว้
- จัดลำดับไว้สำหรับประมวลผลหลังระบบกลับมา
- ให้เลขอ้างอิงหรือใบสำเนาแก่ผู้มาติดต่อ
ในทางกลับกัน การเทียบข้อมูลกับฐานกลาง การตรวจสถานะการชำระ การเปิดดูบันทึกในอดีต การออกใบรับรองที่ถูกต้อง และการเชื่อมกับหน่วยงานภายนอก บางอย่างทำให้จบโดยไม่มีระบบหลักไม่ได้
ดังนั้นสิ่งที่ควรเป็นไม่ใช่ "ถอยกลับไปใช้กระดาษทั้งหมด"
แต่คือ "ต่อให้ระบบหลักล่ม อย่างน้อยการรับเรื่องก็ต้องไม่ตายตามไปด้วย"
กระดาษไม่ใช่ฐานข้อมูลสำรอง
แต่ใบรับเรื่องที่เป็นกระดาษเป็นทางออกฉุกเฉินได้
7. สิ่งที่ต้องการจริง ๆ คือ "การทำงานแบบลดระดับ ที่ไม่หยุดสนิท"
ระบบที่ทนต่อความขัดข้อง ไม่ได้รักษาฟังก์ชันปกติไว้ครบ 100% เสมอไป
ตรงกันข้าม มันเหลือไว้แค่ฟังก์ชันสำคัญแล้วสลับไปโหมดแบบเรียบง่าย
Google SRE เรียกสิ่งนี้ว่าการลดระดับฟังก์ชันอย่างเป็นขั้นตอน หรือ graceful degradation ส่วน NIST ก็ระบุอุปกรณ์สำรอง สถานที่สำรอง และการประมวลผลด้วยมือ เป็นทางเลือกของแผนความต่อเนื่อง
ถ้านำมาใช้กับงานภาษี ภาพในอุดมคติจะเป็นแบบนี้
- ไม่หยุดรับเรื่อง รับข้อมูลคำขอขั้นต่ำได้แม้แบบออฟไลน์หรือกระดาษ
- ออกเลขรับเรื่อง ไม่ให้เกิดความรู้สึกว่า "ไม่รู้ว่ารับไปหรือยัง"
- ใส่คิวรอประมวลผลทีหลัง หลังกู้ระบบแล้วประมวลผลซ้ำตามลำดับได้
- กันการประมวลผลซ้ำ มีตัวระบุที่ทำให้ต่อให้ใส่คำขอเดิมเข้าไปอีก ก็นับเป็นครั้งเดียว
- แบ่งตามความเร่งด่วน จัดลำดับก่อนให้เรื่องที่มีกำหนดเวลาหรือกระทบชีวิตประจำวันมาก
- แสดงสถานะให้ผู้ใช้เห็น แยกประกาศว่าอะไรหยุด อะไรใช้ได้ อะไรกลับมาแล้ว
- เทียบข้อมูลหลังกู้ระบบ นำการรับเรื่องแบบกระดาษและออฟไลน์ไปเทียบกับข้อมูลจริง เพื่อหางานที่ตกหล่นและงานที่ซ้ำ
สิ่งสำคัญไม่ใช่ภาพลวงตาว่า "ต่อให้เกิดข้อขัดข้องก็ทำงานได้เหมือนเดิม"
แต่คือการออกแบบว่าจะพังอย่างไร
8. แล้ว e-Tax มีข้อขัดข้องบ่อยแค่ไหน
เมื่อดูประกาศอย่างเป็นทางการของ e-Tax ในปี 2026 จะพบประกาศข้อขัดข้องหลายครั้งตลอดทั้งปี ได้แก่ การแจ้งผลชำระเสร็จล่าช้าในเดือนมกราคม ปัญหาการเชื่อมกับ Mynaportal และล็อกอินยากในเดือนกุมภาพันธ์ ล็อกอินยากในเดือนมีนาคม ปัญหาผ่าน Mynaportal ในเดือนกรกฎาคม การใช้ชำระตรง (Direct Payment) ไม่ได้ในเดือนสิงหาคม และข้อขัดข้องหลายจุดหลังอัปเกรดในเดือนกันยายน
แต่ตรงนี้อย่านับแบบลวก ๆ
ทั้งหมดนี้ไม่ใช่ข้อขัดข้องเดียวกัน
บางเรื่องเป็นปัญหาของ e-Tax เอง บางเรื่องเป็นฝั่งการเชื่อมกับ Mynaportal การชำระเงิน การแสดงผล หรือบริการภายนอก และการปิดปรับปรุงตามแผนก็ไม่ใช่ข้อขัดข้อง
ดังนั้นสิ่งที่พูดได้จากรายการอย่างเป็นทางการคือ "มีการประกาศข้อขัดข้องบางส่วนและข้อขัดข้องของระบบที่เชื่อมต่อหลายครั้งต่อปี" เท่านั้น ยังพูดไม่ได้ว่า "ระบบภาษีทั้งประเทศล่มทั่วประเทศบ่อย ๆ"
เหตุที่เรื่องเดือนกันยายน 2026 เด่นเป็นพิเศษ ก็เพราะในสัปดาห์สลับระบบของการอัปเกรดครั้งใหญ่ มีทั้งการปิดตามแผนที่ยาวและข้อขัดข้องหลังสลับระบบหลายอย่างมาซ้อนกัน
9. พอรู้ว่าการรวมระบบนรกแค่ไหน วิธีโกรธก็เปลี่ยนไปนิดหน่อย
คนที่เคยสร้างระบบอัตโนมัติเล็ก ๆ ด้วยตัวเอง จะมองความขัดข้องของระบบยักษ์ต่างไปเล็กน้อย
เมื่อก่อนก็คงจบที่
"ทำไมของแบบนี้ถึงล่มได้เนี่ย"
แต่พอเคยเชื่อมหลายบริการเข้าด้วยกัน มีคิว มีการลองซ้ำ เก็บสถานะ และเชื่อมกับ API ภายนอก ก็จะมีความรู้สึกอีกแบบปนเข้ามาว่า
"โอ้โห สลับระบบรวมนี่มันนรกจริง ๆ"
แยกกันทำงานได้หมด แต่รวมแล้วพัง
แก้อันหนึ่งก็ไปพังรอยต่ออีกจุด
สถานะเก่ายังค้างอยู่
ลองซ้ำแล้วกลายเป็นซ้ำสองครั้ง
เปิดล็อกดูก็เป็นข้อมูลเมื่อวาน
แค่ได้ลิ้มรสเวอร์ชันย่อส่วนของเรื่องเหล่านี้ ก็จินตนาการความยากของระบบหลักขนาดยักษ์ได้ง่ายขึ้น
แต่ความเข้าใจกับการประเมินเป็นคนละเรื่อง
ไม่ควรจบที่ "มันยากก็เลยช่วยไม่ได้" แต่ให้ดูสิ่งต่อไปนี้
- ก่อนสลับระบบ ทดสอบโหลดและทดสอบการย้ายข้อมูลไปได้ถึงไหน
- ตอนเกิดข้อขัดข้อง ลดระดับการทำงานได้ถึงไหน
- การรับเรื่องด้วยมือทำงานได้ถึงไหน
- การแจ้งสถานะเพียงพอสำหรับผู้ใช้หรือไม่
- หลังกู้ระบบแล้ว จะเปิดเผยสาเหตุและมาตรการป้องกันการเกิดซ้ำหรือไม่
- ในการสลับระบบครั้งหน้า จะกำจัดอุบัติเหตุแบบเดียวกันได้หรือไม่
เพราะซับซ้อน อุบัติเหตุจึงเกิดขึ้นได้
และเพราะซับซ้อน การออกแบบและการเรียนรู้หลังเกิดเหตุจึงสำคัญ
10. สรุป "ไม่ใช่ให้ทำทุกอย่างด้วยกระดาษ" แต่คือ "อย่างน้อยทางเข้าต้องไม่ตายแม้ใช้กระดาษ"
เมื่อระบบหลักของสำนักงานสรรพากรล่ม ผู้ใช้บริการย่อมรู้สึกว่าไม่เป็นธรรมอย่างยิ่ง
เป็นที่ที่ดูแลเงินและขั้นตอนทางกฎหมาย แต่ก็ล่มได้
ไม่รู้ด้วยว่าจะกลับมาเมื่อไร
บอกว่าไปที่เคาน์เตอร์ก็ทำได้ แต่คิดยังไงก็น่าจะแน่น
จึงอยากพูดว่า "ใช้กระดาษไปเลย"
ในความรู้สึกนี้ มีข้อเรียกร้องด้านการออกแบบที่สำคัญมากซ่อนอยู่
การใช้กระดาษอย่างเดียวแทนระบบภาษีทั้งหมดนั้นไม่สมจริง
แต่ก็ไม่จำเป็นที่ทันทีที่ระบบล่ม การรับเรื่อง การบันทึก การจัดลำดับความสำคัญ และคิวรอประมวลผลต้องตายตามไปด้วย
สิ่งที่ระบบยักษ์ต้องมีไม่ใช่ตำนานว่า "ไม่มีวันพัง"
แต่คือเหลืองานขั้นต่ำไว้ได้แม้พัง
ย้อนกลับได้โดยไม่ประมวลผลซ้ำ
บอกผู้ใช้ได้ว่าอะไรใช้ได้และอะไรใช้ไม่ได้
และหลังกู้ระบบ ต้องเก็บงานที่ค้างระหว่างหยุดกลับมาทำได้อย่างปลอดภัย
พูดให้สั้นที่สุด ข้อเรียกร้องสุดท้ายคือ
"ไม่ได้ให้ทำทุกอย่างด้วยกระดาษ"
"แต่อย่างน้อยการรับเรื่อง ขอให้ใช้กระดาษก็ยังเริ่มได้ ขอร้อง"
เอกสารอ้างอิง
- กรมสรรพากร "เรื่องความล่าช้าของขั้นตอนต่าง ๆ ที่เคาน์เตอร์สำนักงานสรรพากร" 2026-09-24
https://www.nta.go.jp/files/000041014.pdf - กรมสรรพากร "เรื่องการอัปเกรดระบบภาษีแห่งชาติ"
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - รายงานกรมสรรพากร 2025 "ระบบรุ่นใหม่ (KSK2)"
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax "เวลาปิดปรับปรุงที่เกี่ยวกับการอัปเกรดระบบภาษีแห่งชาติ"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax "รายการประกาศ"
https://www.e-tax.nta.go.jp/topics/ - e-Tax "[แก้ไขแล้ว] เรื่องสถานการณ์ที่ใช้ e-Tax ไม่ได้"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
