Thailand

เมื่อวานเป็นวันแรกที่เว็บไซต์ เราไม่ทิ้งกัน.com เปิดให้บริการ และล่มในช่วงแรก วันนี้มีข้อมูลเบื้องหลังของระบบเว็บไซต์ออกมาให้ดูกัน

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

  • ทีมงานของธนาคารกรุงไทย มีเวลาเตรียมตัวเพียง 1 สัปดาห์ในการพัฒนาระบบขึ้นมาทั้งหมด
  • รูปแบบการทำงานแตกต่างจาก ชิมช้อปใช้ ที่กรองผู้ใช้เข้ามาทีละส่วนเพื่อให้ระบบรองรับไหว แต่ "เราไม่ทิ้งกัน" จะเปิดรับผู้ลงทะเบียนทั้งหมดพร้อมกัน
  • ระบบเบื้องหลังเป็น Google Cloud ที่ศูนย์ข้อมูลอยู่ที่สิงคโปร์ ตัวระบบ Google Cloud รองรับไหว แต่ก็มีปัจจัยอื่นๆ อีกมากมาเกี่ยวข้อง
  • ทีมงานคุยกับโอเปอเรเตอร์ เพื่อประสานงานเรื่อง network capacity และความเร็วของการส่งรหัส OTP ผ่าน SMS ล่วงหน้า
  • เมื่อเปิดใช้งานระบบตอน 18.00 น. มีผู้ใช้งานจำนวนมาก (20 ล้านรีเควสต์) ทำให้ระบบล่ม ทีมงานจึงต้องปรับปรุงระบบใหม่ ใช้เวลาประมาณชั่วโมงเศษๆ แต่ตอนหลังก็ไปติดคอขวดที่ระบบส่ง SMS อยู่ดี จึงต้องปรับปรุงระบบคิว SMS ให้คิวเก่าหายไป รีเซ็ตคิวใหม่
  • ข้อมูลล่าสุด (ประมาณ 9 โมงเช้าวันนี้ 29 มีนาคม) มีผู้ลงทะเบียนบนหน้าเว็บแล้วเกือบ 12 ล้านราย

Hiring! บริษัทที่น่าสนใจ

Carmen Software company cover
Carmen Software
Hotel Financial Solutions
Next Innovation (Thailand) Co., Ltd. company cover
Next Innovation (Thailand) Co., Ltd.
We are web design with consulting & engineering services driven the future stronger and flexibility.
KKP Dime company cover
KKP Dime
KKP Dime บริษัทในเครือเกียรตินาคินภัทร
Kiatnakin Phatra Financial Group company cover
Kiatnakin Phatra Financial Group
Financial Service
Fastwork Technologies company cover
Fastwork Technologies
Fastwork.co เว็บไซต์ที่รวบรวม ฟรีแลนซ์ มืออาชีพจากหลากหลายสายงานไว้ในที่เดียวกัน
Thoughtworks Thailand company cover
Thoughtworks Thailand
Thoughtworks เป็นบริษัทที่ปรึกษาด้านเทคโนโยลีระดับโลกที่คว้า Great Place to Work 3 ปีซ้อน
Iron Software company cover
Iron Software
Iron Software is an American company providing a suite of .NET libraries by engineer for engineers.
CLEVERSE company cover
CLEVERSE
Cleverse is a Venture Builder. Our team builds several tech companies.
Nipa Cloud company cover
Nipa Cloud
#1 OpenStack cloud provider in Thailand with our own data center and software platform.
Bangmod Enterprise company cover
Bangmod Enterprise
The leader in Cloud Server and Hosting in Thailand.
CIMB THAI Bank company cover
CIMB THAI Bank
MOVING FORWARD WITH YOU - CIMB is the leading ASEAN Bank
Bangkok Bank company cover
Bangkok Bank
Bangkok Bank is one of Southeast Asia's largest regional banks, a market leader in business banking
MuvMi (Urban Mobility Tech Co.,Ltd.) company cover
MuvMi (Urban Mobility Tech Co.,Ltd.)
Shape the future of urban mobility towards affordable, clean, and safe solutions
T.N. Digital Solution Co., Ltd. company cover
T.N. Digital Solution Co., Ltd.
TNDS has been involving in every first move of banking’s major digital transformation.
KBTG - KASIKORN Business-Technology Group company cover
KBTG - KASIKORN Business-Technology Group
KBTG - "The Technology Company for Digital Business Innovation"
Siam Commercial Bank Public Company Limited company cover
Siam Commercial Bank Public Company Limited
"Let's start a brighter career future together"
Icon Framework co.,Ltd. company cover
Icon Framework co.,Ltd.
Global Standard Platform for Real Estate แพลตฟอร์มสำหรับธุรกิจอสังหาริมทรัพย์ครบวงจร มาตรฐานระดับโลก
REFINITIV company cover
REFINITIV
The Financial and Risk business of Thomson Reuters is now Refinitiv
H LAB company cover
H LAB
Re-engineering healthcare systems through intelligent platforms and system design.
The Gang Technology Co., Ltd. company cover
The Gang Technology Co., Ltd.
We're a Digital Agency that helps our customers transform their business into digital with ease.
LTMH company cover
LTMH
LTMH มุ่งเน้นการพัฒนาผลิตภัณฑ์ที่สามารถช่วยพันธมิตรของเราให้บรรลุเป้าหมาย
Seven Peaks company cover
Seven Peaks
We Drive Digital Transformation
Wisesight (Thailand) Co., Ltd. company cover
Wisesight (Thailand) Co., Ltd.
The Best Choice For Handling Social Media · High Expertise in Social Data · Most Advanced and Secure
MOLOG Tech company cover
MOLOG Tech
We are Modern Logistic Platform, Specialize in WMS, OMS and TMS.
Data Wow Co.,Ltd company cover
Data Wow Co.,Ltd
We enable our clients to realize increased productivity by solving their most complex issues by Data
LINE Company Thailand company cover
LINE Company Thailand
LINE, the world's hottest mobile messaging platform, offers free text and voice messaging + Call
LINE MAN Wongnai company cover
LINE MAN Wongnai
Join our journey to becoming No.1 food platform in Thailand

ash_to_ash Sun, 29/03/2020 - 10:16

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

คิดเหมือนกันเลยครับ

ถ้าไปสู้ด้าน capacity ยังไงก้สู้คนไม่ไหวอยู่ดี สู้แบ่งตามเลขประชาชนไปเลย วันนี้คนที่ลงท้ายด้วยเลข 0 วันต่อไปคนที่ลงท้ายด้วยเลข 1 อะไรงี้

แล้วตัวเช็คเลขบัตรมันก็ต้องรองรับ capacity ตรงนี้ด้วยอยู่ดี แล้วเวลา 1 อาทิตย์จะสามารถเตรียมข้อมูลตรงนี้ ทันเหรอ?

ปัญหาคอขวดที่เจอกันเมื่อคืนอันหนึ่ง ไม่ใช่เพราะ Backend นะครับ แต่เป็นตรง Frontend ที่รองรับรีเควสต์ขนาดมหาศาลไม่ได้ กรองด้วยการเช็คไอดีก็ต้องใช้ทรัพยากรเช่น การคำนวนและหน่วยความจำ หลักๆเลยคือหน่วยความจำเพราะต้องอาศัย thread ขึ้นมารับรีเควสต์อยู่ดี

ถ้าลงทะเบียนสำเร็จเมื่อไหร่ นั่นแหละคือ หน้าที่ของ Backend คือการคำนวน Computation ซึ่งต้องอาศัยIO ซึ่งมาจากการดึงข้อมูลจากฐานข้อมูล ซึ่งผมว่า อันนี้ถ้า Backend ใข้คอมพิวเตอร์คลัสเตอร์ที่เชื่อมกับฐานข้อมูลด้วย latency ต่ำๆ ก็เอาอยู่สบายๆ

ผมหมายถึงการ check เลขบัตรประชาชนเพื่อแบ่งช่วงเวลาการลงทะเบียนด้วย javascript บน browser ตามไอเดียคนข้างบนครับ พอดีความเห็นต่อมาทักว่าตัวเช็คเลขบัตรมันก็ต้องรองรับ capacity ตรงนี้ด้วยอยู่ดี

takwing Sun, 29/03/2020 - 14:32

In reply to by crucifier

client-side processing ช่วยได้แน่นอนครับ แต่ในทางปฎิบัติไม่มั่นใจว่าจะเป็นไง
ถ้าจะทำแบบนี้ มันก็มีปัญหาอีกครับ ต้องสื่อสารกับคนไทยให้ดี
สมมติว่าวันๆนึงมีไว้สำหรับให้คนไทยที่มีไอดี X ถึงไอดี Y เท่านั้น ถ้าเกิดมีคนที่มีสิทธิ์ อยู่ในช่วงไอดีนั้น ทำไม่ทันอาจจะเพราะไม่รู้หรืออะไรก็ตาม ก็ต้องเสียเวลารอไปอีกหลายวันจนครบ
ซึ่งผมคิดว่า คนพัฒนาระบบคงคิดไว้แล้วว่า ทำแบบนี้เร็วกว่า ถ้าเค้าสามารถเพิ่ม Capacity ของทั้ง Frontend กับ Backend ได้ในระดับนึงที่คิดว่าพอแน่ๆสำหรับจำนวนรีเควสต์ที่จะเข้ามา

ถ้าเช็คด้วย javascript มันก็แค่คำสั่งเดียว และไม่ต้องติดต่อกับ server เลยก็ได้ครับ ไม่เปลีองทรัพยากรระบบด้วย เพราะ javascript พวกนี้รันที่ client side อยู่แล้ว
ถ้าเปิดหน้า web ขึ้นมา ก็จบแล้ว server ไม่ต้องรองรับการประมวลผล จะกว่าจะมี ajax request หรือ submit ครับ
แล้วการตรวจสอบความถูกต้องของเลขบัตรประชาชน มันมีสูตรคำนวณครับ เช็คได้จาก client side เลย ลอง search google คำว่า "วิธีตรวจสอบเลขบัตรประชาชน" มันก็มี code ให้ลอกได้ง่ายๆ เลยครับ (เข้าใจว่า website ที่มีให้กรอกบัตรประชาชนในประเทศเราน่าจะตรวจสอบด้วยวิธีนี้กันหมดอยู่แล้ว เพราะเป้น common knowledge)
ซึ่งหากมีการตรวจสอบ "วันที่ (อาจจะดึงจาก NTP เพื่อลด load ฝั่ง server)" + เลขสุดท้ายขชองบัตรประชาชน + ความถูกต้องของบัตรประชาชน ซึ่งทั้งหมดสามารถ hardcode ไว้ใน html ได้ และเอาใส่ไว้บน CDN ได้ บอกได้ว่า คนเข้าเเป็นสิบล้านก็ล่มยากครับ ถ้าล่มจาก Front end มันต้องเปิดหน้า web ไม่ขึ้นเลย

ปัญหาที่ผมอ่านมาส่วนใหญ่ น่าจะเป็น เขียน code ผิดมากกว่า หลายๆ อันเป็นพวก ไม่ได้ตี error ออกหน้าจอ จนคนต้องไป inspect ดู error

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

ปัญหาของกรณีนี้ ผมว่าไม่ใช่เรื่องรับ load ไม่ไหว แต่เป็นเรื่องของการ "ไม่คิดเผื่อ" ของคนออกนโยบาย เพราะการจำกัดแบบนี้ ทาง dev ทำเองไม่ได้ครับ ต้องคนให้ requirement เป็นคนกำหนด

ถ้าจะวางไว้ที่ฝั่งไคลเอนท์ ก็มีคำถามว่า distribution ของกลุ่มคนตามเลขไอดี นี่มีการกระจายตัวแบบไหน
ผมว่าไม่น่าจะใช่กราฟเส้นตรงขนานกับแกน X แน่ๆ แล้วจะจัดการไง เพราะมันก็จะมีช่วงเวลาที่คนเข้ามาใช้เยอะเพราะมีเลขบัตรเข้าเกณฑ์ของช่วงเวลานั้นๆเยอะ แต่บางช่วงเวลาอาจจะมีคนน้อยมากที่เข้าเกณฑ์

สุดท้ายก็อย่างที่บอก ทีมงานเค้าอาจจะคิดว่าเค้ามี Silver bullet อยู่แล้วเลยออกแบบมาแบบนี้

การกระจายตัวมันก็ดูได้ครับ ฝั่งรัฐมีข้อมูลเลขบัตรทั้งประเทศอยู่แล้ว

ประเด็นคือ มันไม่จำเป็นต้องเท่ากัน แต่มันต้องหาวิธีให้เมันไม่เยอะ

ต่อให้ สมมติว่ามันไปกระจุกที่เลข 5 เยอะ มันก็ยังดีกว่าปล่อยทั้ง 12 ล้านเข้ามาพร้อมๆ กัน
อาจจะเหลือ 8 ล้าน 7 ล้าน แต่ก็ไม่ใช่ 12 ล้าน

โลกนี้ไม่มีอะไรเป็น silver bullet ครับ แม้แต่ โลกของ lload distribuiton, microservice ก็ตาม
การใช้ "มาตรการ" มาช่วย มันก็ลดความเสี่ยงในการมีปัญหาได้เยอะ

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

ง่ายๆ เลยครับ

  1. ประกาศคุณสมบัติในการลงทะเบียนเพิ่มไปอีกข้อครับ
  2. ใช้ javascript เช็ควันที่ เทียบกับเลขบัตรประชาชนตัวสุดท้ายที่ลงทะเบียน ใครไม่ตรง หน้าเว็บแค่ popup มาว่าลงทะเบียนวันหลัง (เช็คด้วย string หรือสูตรคณิตศาสตร์ก็ได้ครับ server แทบไม่ต้องทำอะไรเลย)

อย่างน้อยก็เรื่องกฎหมายที่ทำให้วางแล้วขายลูกค้ายาก
เรื่อง Link ต่างประเทศด้วยไหมอันนี้ไม่รู้
เรื่องนี้มันเสียโอกาสทางภาษีมหาศาลนะ ทั้งภาษีเงินได้ แรงงานมีฝีมือ สารพัด

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

+100 ครับ เวลาคนถามถึงสาเหตุที่ cloud ไม่เข้ามาวางในไทยก็มักจะต้องตอบรวมๆไปหมดแบบนี้ เพราะเอาเข้าจริงระบบใหญ่ๆมันต้องคิดเรื่อง trade-off กันหลายอย่างรอบด้าน ทั้งทางเทคนิคและทางธุรกิจ จะบอกว่าไม่มาลงเพราะอย่างใดอย่างหนึ่งไปเลยมันก็ทั้งถูกและไม่ถูกอ่ะนะ

ภัยพิบัติที่เกิดขึ้นในอดีต

ผมจำสิ่งนี้ได้แม่น 55555

เป็นคนนึงไม่กล้าวาง cloud ไว้ที่ไทย ทั้งเรื่องกฎหมาย มาตรฐาน ถ้าอยู่บน AWS/Google/Azure อย่างน้อยเวลาล้มก็ไปพร้อมๆกันแยอะ รู้สาเหตุได้เร็ว อีกอย่างนึงคือ 3rd API ที่ cloud ไทยไม่มีเช่น Firebase etc.

capmoo Sun, 29/03/2020 - 10:24

ใช้ service otp เจ้าไหนหรอครับ ไปตายตรง otp หลายรอบมาก

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

ถ้ามีคนมาถามผมว่า "ทำไมไม่ใช้ cloud เจ้าอื่น" แล้วถ้าผมใช้ aws อยู่ผมจะตอบว่า "ก็ผมคุ้นเคยกับมัน" เหตุผลแค่นี้เลยครับ ผมว่าทีมงานนี้ก็เช่นกัน

น่าจะเพราะ Internet Gateway แทบทุกเจ้าต่อตรงกับกูเกิ้ลอยู่แล้วมั้งครับ? และก็ไม่ได้ต่อแบบนิด ๆ หน่อย ๆ ด้วย latency ก็น่าจะต่ำเพราะไม่ต้องผ่านโหนดเยอะ... ซึ่งแตกต่างจาก AWS ที่บางเจ้าก็ต่อตรงบางเจ้าก็ไปผ่าน IX ก่อนถึงจะไป AWS ครับ

รัฐบาลเตรียมเงินรองรับสำหรับแรงงานนอกระบบ3ล้านคน ไม่รวมแรงงานที่มีมีประกันสังคม และ เกษตรกร
แต่ปัจุบันคนลงทะเบียนไปแล้ว12ล้าน
ระบบมันไม่มีการคัดกรองอะไรเลยหรือไงครับ

ตอนลงทะเบียนจะคัดกรองยังไงครับ เพราะมันยังไม่มีการประมวลผล

ระบบจะรับคำร้อง ไปประมวลอีกทีเพื่อตัดสินว่าใครมีสิทธิ์ได้รับเงินเยียวยา ใครไม่มี

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

ผมเห็นด้วยนะครับ แต่ผมก็ยังทับถมเพราะคนออกมาบอกว่าไม่ล่มแน่นอนอยู่ดี

ตัวทีมพัฒนาเลยคงไม่พูดหรอก แต่เกลียดมากเวลาใครบอกอะไรที่เป็นไปไม่ได้ออกมาเนี่ย

อันนี้มันก็ลำบากครับ เอาใจเค้ามาใส่ใจเรา

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

ส่วนความเสถียรของระบบตอนนี้ก็ถือว่า โอเคขึ้นมากแล้ว ผมให้ผ่านครับ

ถ้าคนนั้นบอกว่า ระบบล่มแน่ๆครับพี่น้อง ทำใจไว้เลย ก็แย่ครับ ประชาชนแตกตื่นแน่ๆ

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

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

แต่ด้วยความที่โจทย์นี้ แตกต่างจากโจทย์ชิมช้อปใช้ โจทย์ชิมช้อปใช้คือลงทะเบียนก่อนได้ก่อน แต่โจทย์นี้คือ รับไว้ค่อยพิจารณาอีกที จึงไม่มีเหตุผลที่จะอั้นทราฟฟิก ก็ปล่อยเต็มที่จ้า แต่เหมือนลืมนึกเรื่องคอขวดระบบส่ง SMS ถ้าใช้ระบบ RTS หรือ Messenger(Line Connect) หรือ Email ซึ่งเป็นระบบใหม่กว่าก็น่าจะรับโหลดได้มากกว่านี้นะครับ

โดยรวม มีเวลาให้เกือบๆ 1 สัปดาห์กับงานไฟไหม้บ้าน ถือว่า เตรียมตัวมาดี ผมให้ทีมงานนี้ผ่านครับ!

ป.ล. สงสัยว่าทีม dev ได้นอนพักผ่อนบ้างหรือเปล่า? 555+

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

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

กับพวกอ่านหนังสือไม่เกิน 9 บรรทัด ฟังไม่เกิน 30 วินาที เขาก็บอกว่า เปิดรับลงทะเบียนเรื่อย ๆ ก็ยังจะออกันเข้าไป พอเจอ 2 อย่างนี้เข้าไป ก็เรียบร้อยครับ ล่ม...ตามระเบียบ

อันนี้ทำอะไรไม่ได้อยู่แล้วครับ ของมันจะต้องล่มก็คือต้องล่ม แล้วถ้าฝั่ง frontend ไม่ล่มแบบนี้ด้วยยิ่งมีข้อความชี้แจงไว้ได้ด้วยก็ดีครับจะได้บอกได้ว่าไม่อ่านเอง

sunVSmoon Sun, 29/03/2020 - 14:40

In reply to by hisoft

+1
ผมชื่นชมทีมทำงาน ทั้งพัฒนา ปรับปรุง แก้ไข
แต่ว่าเมื่อระบบมีปัญหา
และระดับผู้นำยืนยันว่าต่อหน้าประชาชนว่ายังไงก็ไม่ล่ม
มันก็ต้องติเพื่อให้ปร้บปรุงกันบ้าง
นี่ไม่ใช่ครั้งแรก ที่ระดับปฏิบัติการก็นั่งทำงานกันไป
ส่วนระดับบน วาทะกรรมประหลาดมันเยอะมาก
ที่ผมยังสงสัยว่าทำไมแบบนี้ไม่โดน fake news บ้าง
(พอฝั่งตรงข้ามยัดเยียดข้อหานี้กันเหลือเกิน)
-ระบบไม่ล่มแน่นอน
-หน้ากากมีสำรองพอ 200 ล้านชิ้น
-ไม่มีบุคลากรทางการแพทย์ติดเชื้อระหว่างการรักษา
-หน้ากากจัดสรรให้เพียงพอทุกโรงพยาบาล
-เรามีมาตรการพร้อม แล้วมาบอกรอประชุม ครม
-เรามีมาตรการพร้อม แต่รอให้ประชาชนช่วยกันเสนอแนวทางแก้ไข
แล้วช่วงนี้หลายโรงพยาบาล เริ่มเปิดบัญชีระดมทุนซื้อหน้ากาก N95 กันแล้ว
เพราะทนรองบประมาณจากส่วนกลางไม่ได้ และของก็ไม่ถึงมือ
ผมว่าถ้าไม่ทักไม่ท้วง เราจะปล่อยไปเรื่อยๆ นี่ก็แแปลกนะ

เข้าใจอะไรผิดปะครับ fake news มันแปลว่าข่าวปลอม มันก็ต้องเกี่ยวกับอดีต
เช่น นาย ก บอกว่าเมื่อวานระบบไม่ล่ม ทั้งๆ ที่ความจริงล่ม มันคือ fake news
ถ้านาย ก. บอกว่าระบบไม่มีทางล่ม (ระบบยังไม่เคยล่ม ณ จังหวะนั้น)แล้วปรากฏว่าตอนหลังล่ม อันนั้นไม่ใช่ fake news ครับ

สรุปง่ายๆ คือ news ไม่ว่าจะ fake จะจริง ก็ต้องเกี่ยวกับอดีตครับ เกี่ยวกับเหตุการณ์ที่เกิดขึ้นจริง คุณจะมาบอกว่าอนาคต fake ไม่ fake ไม่ได้ เพราะเราไม่มีทางรู้ว่าอนาคตจะเป็นอย่างไร

บางทีติซ้ำๆ ซากๆ คนก็รำคาญเหมือนกันผมว่า ยิ่งช่วงนี้มีแต่ด่ากันไปด่ากันมามีแต่อะไรลบๆ

เมื่อวานมีคอมเม้นของ "คนเก่ง" ทำนองว่า สงสัยให้เด็กฝึกงานเขียน สงสัยโดนหักหัวคิว
ทั้งๆที่ทีมงานทำงานกันไม่ได้หลับไม่ได้นอน อยากเห็นพวก "คนเก่ง" พวกนั้น มารับงาน scale นี้บ้าง อยากรู้ว่าจะเก่งจริงมั้ย

มันมีงานไหนที่เพิ่งเปิด production แล้วได้หลับได้นอนด้วยเหรอครับ? ปกติฝั่ง backend ก็ monitoring กันตลอดเวลาข้ามวันข้ามคืนกันทั้งนั้น

  • ปัญหาอยู่ที่ คอขวดส่ง sms ไม่แน่ใจว่าใช้ provider เจ้าไหน
  • เข้าใจว่าตอนแรกไม่ได้ทำระบบคิวสำหรับส่ง SMS
  • ปัญหานี้แก้โดยการทำระบบคิว อันที่จริงสามารถกระจายส่งไปตามหลาย provider ได้ด้วยนะครับ

sms ส่งเป็นหลักล้านนี่ ผมว่าเจ้าไหนก็เอาไม่อยู่ครับ
แล้วผมเข้าใจว่าคนทำไม่ได้ ก็ทำซ้ำๆ หลายๆ รอบด้วย เพราะพอทำแล้วไม่ได้ otp ก็ยิงคำสั่งเข้าไปใหม่
(ซึ่งจริงๆ ตรงนี้น่าจะหน่วงเวลา ไม่ให้ยิงคำสั่งซ้ำ ภายใน 30 วินาที อะไรก็ว่าไป น่าจะช่วยได้บ้าง)

อีกอย่าง ที่มันช้าเพราะเป็นคิวเนี่ยแหละครับ แต่ของในคิวมันเยอะมาก มันเลย process ไม่ทัน

คิวไม่ได้แก้ปัญหาเรื่องช้าครับ แค่ทำให้ process หน้าบ้านมันไม่ตาย request timeout และหลังบ้านไม่รับงานเกิน capacity เท่านั้น
แต่ถ้าส่งมาจำนวนมาก มันก็ไปกองในคิวอยู่ดี

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

มีใครพอทราบไหมครับว่าเค้าใช้ framework หรือ stack อะไรพัฒนา
จริงๆ ถ้ายอมเปิดเผยการออกแบบบางส่วนเท่าที่ไม่เป็นความลับ ผมเชื่อว่ามีคนภายนอกที่สามารถให้คำแนะนำได้น่ะครับ คนเราไม่สามารถเก่งได้ทุกอย่างหรือทำทุกอย่างได้ดี 100 % ภายในระยะเวลาจำกัดแบบนี้หรอกครับ