By: mk 
on 29 March 2020 - 09:53
Tags:
Topics:
เมื่อวานเป็นวันแรกที่เว็บไซต์ เราไม่ทิ้งกัน.com เปิดให้บริการ และล่มในช่วงแรก วันนี้มีข้อมูลเบื้องหลังของระบบเว็บไซต์ออกมาให้ดูกัน
ข้อมูลนี้มาจากคุณสมคิด จิรานันตรัตน์ อดีตประธาน KBTG ของธนาคารกสิกรไทย ที่ปัจจุบันไปเป็นที่ปรึกษาให้ธนาคารกรุงไทย ในฐานะองค์กรที่รับผิดชอบเว็บไซต์โครงการรัฐบาล ทั้ง "ชิมช้อปใช้" ช่วงก่อนหน้านี้ และโครงการล่าสุดคือ "เราไม่ทิ้งกัน"
- ทีมงานของธนาคารกรุงไทย มีเวลาเตรียมตัวเพียง 1 สัปดาห์ในการพัฒนาระบบขึ้นมาทั้งหมด
- รูปแบบการทำงานแตกต่างจาก ชิมช้อปใช้ ที่กรองผู้ใช้เข้ามาทีละส่วนเพื่อให้ระบบรองรับไหว แต่ "เราไม่ทิ้งกัน" จะเปิดรับผู้ลงทะเบียนทั้งหมดพร้อมกัน
- ระบบเบื้องหลังเป็น Google Cloud ที่ศูนย์ข้อมูลอยู่ที่สิงคโปร์ ตัวระบบ Google Cloud รองรับไหว แต่ก็มีปัจจัยอื่นๆ อีกมากมาเกี่ยวข้อง
- ทีมงานคุยกับโอเปอเรเตอร์ เพื่อประสานงานเรื่อง network capacity และความเร็วของการส่งรหัส OTP ผ่าน SMS ล่วงหน้า
- เมื่อเปิดใช้งานระบบตอน 18.00 น. มีผู้ใช้งานจำนวนมาก (20 ล้านรีเควสต์) ทำให้ระบบล่ม ทีมงานจึงต้องปรับปรุงระบบใหม่ ใช้เวลาประมาณชั่วโมงเศษๆ แต่ตอนหลังก็ไปติดคอขวดที่ระบบส่ง SMS อยู่ดี จึงต้องปรับปรุงระบบคิว SMS ให้คิวเก่าหายไป รีเซ็ตคิวใหม่
- ข้อมูลล่าสุด (ประมาณ 9 โมงเช้าวันนี้ 29 มีนาคม) มีผู้ลงทะเบียนบนหน้าเว็บแล้วเกือบ 12 ล้านราย
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- NVIDIA จะไปหยุดที่ตรงไหน ทำไมครองโลกดาต้าเซ็นเตอร์ | Cloudnone EP.22
- ถึงคลาวด์เคราะห์: ทำอย่างไรเมื่อบริการคลาวด์ที่ใช้ถูกยกเลิก | Cloudnone EP. 21
- รู้จักอาชีพ Site Reliability Engineer สำคัญยังไง? | Cloudnone EP. 20
- อธิบาย CrowdStrike ทางเทคนิค ทำไมถึงทำพีซีจอฟ้าเป็นล้านๆ เครื่อง | Cloudnone EP.19
- Kubernetes [Part 2] ยี่ห้อไหนดี งานไหนต้องใช้ แล้วเลือกยังไง? | Cloudnone EP.18
Comments
ใช้ gcloud ด้วยแฮะ +1
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
ผมสงสัย
รู้อยู่แล้วว่าคนจะแห่กันเข้ามา
น่าจะจำกัดสิทธิ์ เช่น โดยอิงจาก เลขบัตรประชาชน แล้วแบ่งตาม
เลขช่วงอายุ ว่าวันจันทร์คนอายุเท่านี้ถึงเท่านี้
แล้ววนกันไปจนครบเดือน มันก็จะแก้ surge ได้หรือเปล่า
คิดเหมือนกันเลยครับ
ถ้าไปสู้ด้าน capacity ยังไงก้สู้คนไม่ไหวอยู่ดี สู้แบ่งตามเลขประชาชนไปเลย วันนี้คนที่ลงท้ายด้วยเลข 0 วันต่อไปคนที่ลงท้ายด้วยเลข 1 อะไรงี้
แล้วตัวเช็คเลขบัตรมันก็ต้องรองรับ capacity ตรงนี้ด้วยอยู่ดี แล้วเวลา 1 อาทิตย์จะสามารถเตรียมข้อมูลตรงนี้ ทันเหรอ?
กรองขั้นแรกด้วย javascript ที่ frontend ถ้ามั่วผ่านไปได้ค่อยกรองที่ backend อีกที น่าจะลดโหลดได้เยอะครับ
ปัญหาคอขวดที่เจอกันเมื่อคืนอันหนึ่ง ไม่ใช่เพราะ Backend นะครับ แต่เป็นตรง Frontend ที่รองรับรีเควสต์ขนาดมหาศาลไม่ได้ กรองด้วยการเช็คไอดีก็ต้องใช้ทรัพยากรเช่น การคำนวนและหน่วยความจำ หลักๆเลยคือหน่วยความจำเพราะต้องอาศัย thread ขึ้นมารับรีเควสต์อยู่ดี
ถ้าลงทะเบียนสำเร็จเมื่อไหร่ นั่นแหละคือ หน้าที่ของ Backend คือการคำนวน Computation ซึ่งต้องอาศัยIO ซึ่งมาจากการดึงข้อมูลจากฐานข้อมูล ซึ่งผมว่า อันนี้ถ้า Backend ใข้คอมพิวเตอร์คลัสเตอร์ที่เชื่อมกับฐานข้อมูลด้วย latency ต่ำๆ ก็เอาอยู่สบายๆ
ผมหมายถึงการ check เลขบัตรประชาชนเพื่อแบ่งช่วงเวลาการลงทะเบียนด้วย javascript บน browser ตามไอเดียคนข้างบนครับ พอดีความเห็นต่อมาทักว่าตัวเช็คเลขบัตรมันก็ต้องรองรับ capacity ตรงนี้ด้วยอยู่ดี
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 แทบไม่ต้องทำอะไรเลย)
อยากรู้ว่า cloud เจ้าใหญ่ๆ AWS Azure นี่ไม่มีที่ไหนมี server ไทยเลยใช่ไหมครับ เพราะ กฎหมายเราด้วยหรือเปล่า
อย่างน้อยก็เรื่องกฎหมายที่ทำให้วางแล้วขายลูกค้ายาก
เรื่อง Link ต่างประเทศด้วยไหมอันนี้ไม่รู้
เรื่องนี้มันเสียโอกาสทางภาษีมหาศาลนะ ทั้งภาษีเงินได้ แรงงานมีฝีมือ สารพัด
ไม่น่าจะมีเลย
อย่าง Azure Region ที่ใกล้ที่สุดก็สิงค์โปร์ ไกลหน่อยก็ญี่ปุ่น จีน เกาหลี อินเดีย ออสเตรเลีย
ส่วนสาเหตุก็น่าจะมีหลายอย่าง ทั้งตัวกฎหมาย สภาพภูมิประเทศและภูมิอากาศ ภัยพิบัติที่เกิดขึ้นในอดีต ปริมาณการใช้ไฟฟ้า ระบบสาธารณูปโภคและโครงสร้างพื้นฐาน สิ่งแวดล้อมและผลกระทบที่เกิดขึ้น การสนับสนุนทางเศรษฐกิจและอื่น ๆ โดยรัฐบาล การตอบสนองต่อภาวะฉุกเฉินของพื้นที่เช่นไฟดับ ไฟไหม้ การรักษาความปลอดภัย ฯลฯ
+100 ครับ เวลาคนถามถึงสาเหตุที่ cloud ไม่เข้ามาวางในไทยก็มักจะต้องตอบรวมๆไปหมดแบบนี้ เพราะเอาเข้าจริงระบบใหญ่ๆมันต้องคิดเรื่อง trade-off กันหลายอย่างรอบด้าน ทั้งทางเทคนิคและทางธุรกิจ จะบอกว่าไม่มาลงเพราะอย่างใดอย่างหนึ่งไปเลยมันก็ทั้งถูกและไม่ถูกอ่ะนะ
ผมจำสิ่งนี้ได้แม่น 55555
เป็นคนนึงไม่กล้าวาง cloud ไว้ที่ไทย ทั้งเรื่องกฎหมาย มาตรฐาน ถ้าอยู่บน AWS/Google/Azure อย่างน้อยเวลาล้มก็ไปพร้อมๆกันแยอะ รู้สาเหตุได้เร็ว อีกอย่างนึงคือ 3rd API ที่ cloud ไทยไม่มีเช่น Firebase etc.
ส่วนใหญ่มีแค่ Edge Site ในไทยครับ (ล่าสุดคือ Azure ที่เพิ่มมาปีที่แล้ว เป็นเชิง ExpressRoute)
Coder | Designer | Thinker | Blogger
ใช้ service otp เจ้าไหนหรอครับ ไปตายตรง otp หลายรอบมาก
เข้าใจว่าต่อตรงกับ operator เลย
อย่างงี้ต้อง implement เยอะมากเลยนะ
ที่เคยทำกับ 3rd party (โบราณกาล)เค้าแค่โยน soap มาให้เราเท่านั้นครับ ฝั่งผมแค่ดูคิวที่ผูกกับ timestamp เท่านั้นพอ timeout ก็ตัดออก
ทำไมไม่ใช้ cloud เจ้าอื่น
แล้วทำไม่ไม่อยากให้ใช้ Google เหรอครับ
ไปพิมพ์ตอนไหนว่าไม่อยากให้ใช้ google แค่อยากรู้ถึงความต่างทำไมถึงไม่ใช้ เพราะมันมีสองเจ้าตลาดโลกอยู่ เข้าใจน่ะ
ก็ถ้าพิมพ์ถามแบบนี้เข้าใจ แต่คุณพิมพ์แบบบนผมก็ถาม จะมาแดกดันทำไมอะ เข้าใจนะ!
ตีความลบ สรุปเองว่าผมไม่อยากใช้ ผมก็ไม่พอใจสิเดี๋ยวคนอิ่นมาต่อเละเลยทีนี้ผม ( ••)>⌐■-■ = (⌐■■)
ถ้ามีคนมาถามผมว่า "ทำไมไม่ใช้ cloud เจ้าอื่น" แล้วถ้าผมใช้ aws อยู่ผมจะตอบว่า "ก็ผมคุ้นเคยกับมัน" เหตุผลแค่นี้เลยครับ ผมว่าทีมงานนี้ก็เช่นกัน
อ่อครับ อาจจะเป็นส่วนทั้งหมดเลย ของคุ้นมือดีสุด
น่าจะเพราะ Internet Gateway แทบทุกเจ้าต่อตรงกับกูเกิ้ลอยู่แล้วมั้งครับ? และก็ไม่ได้ต่อแบบนิด ๆ หน่อย ๆ ด้วย latency ก็น่าจะต่ำเพราะไม่ต้องผ่านโหนดเยอะ... ซึ่งแตกต่างจาก AWS ที่บางเจ้าก็ต่อตรงบางเจ้าก็ไปผ่าน IX ก่อนถึงจะไป AWS ครับ
ขอบคุณข้อมูลครับ
รัฐบาลเตรียมเงินรองรับสำหรับแรงงานนอกระบบ3ล้านคน ไม่รวมแรงงานที่มีมีประกันสังคม และ เกษตรกร
แต่ปัจุบันคนลงทะเบียนไปแล้ว12ล้าน
ระบบมันไม่มีการคัดกรองอะไรเลยหรือไงครับ
ตอนลงทะเบียนจะคัดกรองยังไงครับ เพราะมันยังไม่มีการประมวลผล
ระบบจะรับคำร้อง ไปประมวลอีกทีเพื่อตัดสินว่าใครมีสิทธิ์ได้รับเงินเยียวยา ใครไม่มี
ไม่ล่มน่ะสิแปลก... มีเวลาให้พัฒนาเพียง 1 สัปดาห์ เรียกว่างานไฟไหม้เลยล่ะครับ... พัฒนามาได้ขนาดนี้ ผมต้องชมทีมผู้พัฒนาเลยครับ
+1
ชมได้ไง เราต้องหาจุดบกพร่องคอยด่าต่อไป /s
ล้อเล่นนะครับ hindsight is 20/20
+1
ผมเห็นด้วยนะครับ แต่ผมก็ยังทับถมเพราะคนออกมาบอกว่าไม่ล่มแน่นอนอยู่ดี
ตัวทีมพัฒนาเลยคงไม่พูดหรอก แต่เกลียดมากเวลาใครบอกอะไรที่เป็นไปไม่ได้ออกมาเนี่ย
อันนี้มันก็ลำบากครับ เอาใจเค้ามาใส่ใจเรา
คนที่ออกมาประกาศก็อาจจะได้รับการยืนยันมาจากฝั่งผู้พัฒนาทั้งฝั่งไทยและสิงคโปร์ว่า ระบบเสถียรแน่นอน
ถ้าคนนั้นบอกว่า ระบบล่มแน่ๆครับพี่น้อง ทำใจไว้เลย ก็แย่ครับ ประชาชนแตกตื่นแน่ๆ
ส่วนความเสถียรของระบบตอนนี้ก็ถือว่า โอเคขึ้นมากแล้ว ผมให้ผ่านครับ
ผมเห็นว่าหลังมีปัญหาก็ออกมาบอกว่าไม่ต้องรีบ ลงเมื่อไหร่ก็ได้เงินเหมือนกัน ถ้าบอกแบบนี้ไว้แต่แรกว่าระบบอาจมีปัญหาบ้างหากคนใช้เยอะแต่จะกลับมาใช้ได้และลงทะเบียนเมื่อไหร่ก็ได้คนก็จะไม่แตกตื่นขนาดนี้ครับ
ผมเห็นด้วยนะ ก็ต้องยอมรับว่า มีคนพวกที่พูดกดดัน หักคอ กับพวกอ่านหนังสือไม่เกิน 9 บรรทัด ฟังไม่เกิน 30 วินาที อยู่ในสังคมด้วย... พวกพูดกดดัน หักคอ ก็จะแบบลูกน้องอธิบายแล้วว่า เปอร์เซนต์การล่มมันมี แต่ก็ออกมาพูดกับสังคมว่า ไม่ล่มแน่นอน ซึ่งไม่ดูความเป็นจริง หรือไม่มีความรู้ในด้านเทคโนโลยี และเชิงจิตวิทยา แทนที่จะอธิบายว่า ค่อย ๆ เข้า ระบบจะได้ไม่ล่ม ไม่ได้จำกัดลงทะเบียน ได้ลงทะเบียนกันทุกคนแน่นอน(ส่วนได้เงิน ไม่ได้เงินนั้นอีกเรื่อง) แบบนี้คนก็จะได้ชิวๆ ลงทะเบียนกันไป (พวกนี้จัดการง่าย พอระบบล่ม เดี๋ยวเขาก็โดนด่าเละเทะเอง) กับพวกอ่านหนังสือไม่เกิน 9 บรรทัด ฟังไม่เกิน 30 วินาที เขาก็บอกว่า เปิดรับลงทะเบียนเรื่อย ๆ ก็ยังจะออกันเข้าไป พอเจอ 2 อย่างนี้เข้าไป ก็เรียบร้อยครับ ล่ม...ตามระเบียบ
แต่ด้วยความที่โจทย์นี้ แตกต่างจากโจทย์ชิมช้อปใช้ โจทย์ชิมช้อปใช้คือลงทะเบียนก่อนได้ก่อน แต่โจทย์นี้คือ รับไว้ค่อยพิจารณาอีกที จึงไม่มีเหตุผลที่จะอั้นทราฟฟิก ก็ปล่อยเต็มที่จ้า แต่เหมือนลืมนึกเรื่องคอขวดระบบส่ง SMS ถ้าใช้ระบบ RTS หรือ Messenger(Line Connect) หรือ Email ซึ่งเป็นระบบใหม่กว่าก็น่าจะรับโหลดได้มากกว่านี้นะครับ
โดยรวม มีเวลาให้เกือบๆ 1 สัปดาห์กับงานไฟไหม้บ้าน ถือว่า เตรียมตัวมาดี ผมให้ทีมงานนี้ผ่านครับ!
ป.ล. สงสัยว่าทีม dev ได้นอนพักผ่อนบ้างหรือเปล่า? 555+
ใช่ครับ นั่นคือเป้าหมายที่ผมทับถมเลยครับ ตรงตัวคนที่แปลงจากคำว่าระบบมีโอกาสล่มแน่ๆ เป็นคำว่าล่มแน่ๆ นี่แหละไม่ว่าคนไหนระดับไหนก็ตาม อาจจะไม่ใช่คนที่ออกมาพูดแต่เป็นสักคนนึงในขั้นตอนถ่ายทอดข้อมูลกันออกมา ผมรังเกียจการกระทำแบบนั้นเป็นอย่างมาก
อันนี้ทำอะไรไม่ได้อยู่แล้วครับ ของมันจะต้องล่มก็คือต้องล่ม แล้วถ้าฝั่ง frontend ไม่ล่มแบบนี้ด้วยยิ่งมีข้อความชี้แจงไว้ได้ด้วยก็ดีครับจะได้บอกได้ว่าไม่อ่านเอง
+1
ผมชื่นชมทีมทำงาน ทั้งพัฒนา ปรับปรุง แก้ไข
แต่ว่าเมื่อระบบมีปัญหา
และระดับผู้นำยืนยันว่าต่อหน้าประชาชนว่ายังไงก็ไม่ล่ม
มันก็ต้องติเพื่อให้ปร้บปรุงกันบ้าง
นี่ไม่ใช่ครั้งแรก ที่ระดับปฏิบัติการก็นั่งทำงานกันไป
ส่วนระดับบน วาทะกรรมประหลาดมันเยอะมาก
ที่ผมยังสงสัยว่าทำไมแบบนี้ไม่โดน fake news บ้าง
(พอฝั่งตรงข้ามยัดเยียดข้อหานี้กันเหลือเกิน)
-ระบบไม่ล่มแน่นอน
-หน้ากากมีสำรองพอ 200 ล้านชิ้น
-ไม่มีบุคลากรทางการแพทย์ติดเชื้อระหว่างการรักษา
-หน้ากากจัดสรรให้เพียงพอทุกโรงพยาบาล
-เรามีมาตรการพร้อม แล้วมาบอกรอประชุม ครม
-เรามีมาตรการพร้อม แต่รอให้ประชาชนช่วยกันเสนอแนวทางแก้ไข
แล้วช่วงนี้หลายโรงพยาบาล เริ่มเปิดบัญชีระดมทุนซื้อหน้ากาก N95 กันแล้ว
เพราะทนรองบประมาณจากส่วนกลางไม่ได้ และของก็ไม่ถึงมือ
ผมว่าถ้าไม่ทักไม่ท้วง เราจะปล่อยไปเรื่อยๆ นี่ก็แแปลกนะ
เข้าใจอะไรผิดปะครับ fake news มันแปลว่าข่าวปลอม มันก็ต้องเกี่ยวกับอดีต
เช่น นาย ก บอกว่าเมื่อวานระบบไม่ล่ม ทั้งๆ ที่ความจริงล่ม มันคือ fake news
ถ้านาย ก. บอกว่าระบบไม่มีทางล่ม (ระบบยังไม่เคยล่ม ณ จังหวะนั้น)แล้วปรากฏว่าตอนหลังล่ม อันนั้นไม่ใช่ fake news ครับ
สรุปง่ายๆ คือ news ไม่ว่าจะ fake จะจริง ก็ต้องเกี่ยวกับอดีตครับ เกี่ยวกับเหตุการณ์ที่เกิดขึ้นจริง คุณจะมาบอกว่าอนาคต fake ไม่ fake ไม่ได้ เพราะเราไม่มีทางรู้ว่าอนาคตจะเป็นอย่างไร
บางทีติซ้ำๆ ซากๆ คนก็รำคาญเหมือนกันผมว่า ยิ่งช่วงนี้มีแต่ด่ากันไปด่ากันมามีแต่อะไรลบๆ
เห็นด้วยเลยครับ
เมื่อวานมีคอมเม้นของ "คนเก่ง" ทำนองว่า สงสัยให้เด็กฝึกงานเขียน สงสัยโดนหักหัวคิว
ทั้งๆที่ทีมงานทำงานกันไม่ได้หลับไม่ได้นอน อยากเห็นพวก "คนเก่ง" พวกนั้น มารับงาน scale นี้บ้าง อยากรู้ว่าจะเก่งจริงมั้ย
มันมีงานไหนที่เพิ่งเปิด production แล้วได้หลับได้นอนด้วยเหรอครับ? ปกติฝั่ง backend ก็ monitoring กันตลอดเวลาข้ามวันข้ามคืนกันทั้งนั้น
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
+1 เช่นกัน ผมว่าทีมพัฒนาก็เก่งพอตัวเลยล่ะ
..: เรื่อยไป
sms ส่งเป็นหลักล้านนี่ ผมว่าเจ้าไหนก็เอาไม่อยู่ครับ
แล้วผมเข้าใจว่าคนทำไม่ได้ ก็ทำซ้ำๆ หลายๆ รอบด้วย เพราะพอทำแล้วไม่ได้ otp ก็ยิงคำสั่งเข้าไปใหม่
(ซึ่งจริงๆ ตรงนี้น่าจะหน่วงเวลา ไม่ให้ยิงคำสั่งซ้ำ ภายใน 30 วินาที อะไรก็ว่าไป น่าจะช่วยได้บ้าง)
อีกอย่าง ที่มันช้าเพราะเป็นคิวเนี่ยแหละครับ แต่ของในคิวมันเยอะมาก มันเลย process ไม่ทัน
คิวไม่ได้แก้ปัญหาเรื่องช้าครับ แค่ทำให้ process หน้าบ้านมันไม่ตาย request timeout และหลังบ้านไม่รับงานเกิน capacity เท่านั้น
แต่ถ้าส่งมาจำนวนมาก มันก็ไปกองในคิวอยู่ดี
เท่าอ่านอัปเดทตอนยอด 18 ล้านวันนี้ คือใช้ SMS gateway ของ TRUE ครับ
ยอมรับเป็นคนหนึ่งที่แอบบ่นกับทีม dev นี้เหมือนกัน แต่พออ่านรายละเอียดของการ dev แล้ว ก็ขอคารวะเลยครับ กับเวลาขนาดนี้
จากประสบการณ์
ไม่ว่าสายงานไหน คนนอกไม่รู้หรอกว่าคนที่ทำงานชิ้นนี้มาเผชิญอุปสรรค์อะไรบ้าง ส่วนใหญ่เราก็นั่งวิจารณ์กัน ทำไมไม่ทำอย่างนั้น ทำไมไม่ทำอย่างนี้ หารู้ไม่ว่าเขาก็คิดไอ้ที่เราแนะนำออกเหมือนกัน เพียงแต่ ณ ตอนนั้นมีเงื่อนไขให้ทำไม่ได้
gcloud ไม่ล่มแต่ nginx ใน compute engine น่าจะล่ม
มีใครพอทราบไหมครับว่าเค้าใช้ framework หรือ stack อะไรพัฒนา
จริงๆ ถ้ายอมเปิดเผยการออกแบบบางส่วนเท่าที่ไม่เป็นความลับ ผมเชื่อว่ามีคนภายนอกที่สามารถให้คำแนะนำได้น่ะครับ คนเราไม่สามารถเก่งได้ทุกอย่างหรือทำทุกอย่างได้ดี 100 % ภายในระยะเวลาจำกัดแบบนี้หรอกครับ
ตัวเว็บใช้ Angular ครับ ส่วน database ผมไม่ทราบจริง ๆ ครับ
Coder | Designer | Thinker | Blogger
ผมขอเดาว่า frontend framework น่าจะ angularjs เพราะแค่ UI เลือกวันเกิดที่เป็น Material UI หราซะขนาดนั้น
คอนเฟิร์มว่า Angular ครับ
Coder | Designer | Thinker | Blogger