By: lew 
on 5 April 2020 - 17:47
Tags:
Topics:
Phil Murphy ผู้ว่าการรัฐนิวเจอร์ซีย์แถลงการรับมือโรค COVID-19 โดยมีประเด็นหนึ่งคือระบบสวัสดิการสังคมของรัฐ ที่กำลังรับโหลดสูงกว่าปกติ 16 เท่าตัวกำลังมีปัญหารับโหลดไม่ไหว ทำให้การจ่ายเงินชดเชยตามสิทธิ์ทำได้ช้ากว่าปกติ โดยระบบสวัสดิการรัฐนี้เก่ากว่า 40 ปีและพัฒนาด้วยภาษา COBOL โดยระบุว่าทางรัฐจะเพิ่มตำแหน่งโปรแกรมเมอร์ COBOL เข้าไปในรายการอาสาสมัคร
ตัวผู้ว่ายอมรับว่าการที่ระบบเก่าที่ไม่มีประสิทธิภาพเพียงพอต่อความต้องการยังทำงานอยู่เช่นนี้เป็นความผิดพลาด เขาระบุว่าหลังจบเหตุการณ์จะมีการหาสาเหตุว่าทำไมจึงมีระบบเก่าขนาดนี้อยู่ในระบบ
การปลดพนักงานจำนวนมากในสหรัฐฯ ทำให้สองสัปดาห์ที่ผ่านมา รัฐได้รับคำขอค่าชดเชยแล้ว 362,000 รายการ ตัวผู้ว่าขออภัยที่การจ่ายเงินอาจล่าช้าแต่สัญญาว่าจะได้เงินครบทุกคน
ที่มา - The Register
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
Comments
My time to shine.
นึกถึง software backend ของค่ายสื่อสาร กับธนาคารบ้านเราเลยครับ
ไม่ล้มแน่นอนระบบเรารองรับได้เป็นล้านทรานแซกชั่นต่อวินาที -> ล่มตั้งแต่นาทีแรก และระบบพึ่งเขียนมาไม่ถึงเดือน...
อันนั้นน่าจะเป็นที่คำโม้ของคนพรีเซ้นท์ที่ไม่ถงไม่ถามสุขภาพเอนจิเนียร์สักคำมากกว่านะครับ
ระบบอะไรก็ล่มได้ทั้งนั้นล่ะครับ
แต่เลือกเทคโนโลยีถูกต้อง ก็มีคนเข้าใจมันเยอะ มีคนปรับแต่งมันเป็นเยอะ หามือเทพๆ มาไล่ปัญหาได้ง่ายกว่า
lewcpe.com, @wasonliw
40 ปีเลย เครื่อง Server เป็นรุ่นอะไรเนี่ย
ให้เดาก็พวก VMX เปิด prompt มาน่าจะ list file กันไม่เป็น...
lewcpe.com, @wasonliw
Q: ทำไมจึงมีระบบเก่าขนาดนี้อยู่ในระบบ?
A: if it work, don't touch it...
รับโหลดไม่ไหว ยังนิยามว่า work ได้อยู่รึเปล่า
ก็ปรกติมันไหว นี่มันไม่ปรกติ
ถ้าระบบออกแบบมาให้ไม่ต้องรองรับกรณีที่ไม่ปกติ ก็ไม่ต้องเดือดร้อนอะไรครับ ปล่อยมันพังไป แต่ในความเป็นจริงคือปล่อยมันพังไม่ได้ ก็แปลว่ามันไม่ work แล้ว
ผมไม่ถนัดเรื่องการสเกล ปกติแล้วมีระบบอะไรที่จะไม่ร่วงตอนเจอโหลดมากกว่าปกติ 16 เท่ามั้ยครับ
ตัวมันไม่ work ก็ต้องมีแผนที่ทำให้ solution มัน work ครับ
ผมยกของที่หนักกว่า 20 กิโลกรัมไม่ได้ แล้วในชีวิตประจำวันผมก็คงยกไม่เกิน 10 กิโลกรัมด้วย วันนึงผมต้องแบกข้าวสาร 50 กิโลกรัม ผมก็ต้องแบ่งเป็นถุงละ 10 กิโลกรัมค่อยๆยก หรือหาตัวช่วย
แล้วถ้าผมแบ่งถุงไม่ได้ หรือหาคนอื่นมาช่วยไม่ได้ ด้วยข้อจำกัดของผมเอง ผมก็ต้องบอกว่าผมไม่ work เหมือนกัน ผมคงต้องไปฟิตกล้ามเพิ่ม
ระบบมันไม่จำเป็นต้องรับโหลดมากกว่าปกติ xx เท่าได้ครับ แต่มันควรจะยืดหยุ่นพอที่จะทำให้คนใช้มันเอาตัวรอดได้เท่าที่ทำได้ ไม่ใช่บอกว่าปกติมัน work อยู่แล้ว พอไม่ปกติก็อ้างว่ามันไม่ปกติ แล้วไม่ยอมปรับปรุงอะไรอยู่ดี
โดยทั่วๆ ไปแล้ว พอทราบมั้ยครับว่าเค้าทำยังไงเวลาที่โหลดมันเยอะอ่ะครับ ผมพยายามหาอ่านแต่หาไม่เจอ เจอแต่วิธีบ้านๆ พวกอัดทรัพยากรเช่นซีพียู แรม ซึ่งผมว่าถึงเวลามันจะตัน
อัดทรัพยากรเช่นซีพียู แรม เข้าไปในเครื่องเดิมจะเป็น Vertical scaling ครับ ถ้าเครื่องเดียวไม่ไหวแล้วก็จะกลายเป็นต้อง Horizontal scaling(scale-out) เพิ่มเครื่องเข้าไป ช่วยๆกันทำ ซึ่งก็ขึ้นอยู่กับว่าได้ออกแบบระบบให้มันทำได้รึเปล่า
บริษัทผมไม่เลือกทางอัดทรัพยากรหรือเพิ่ม mainframe แต่เน้นลด MIPS แทน จูนโค้ดเก่าให้มีประสิทธิภาพมากขึ้น (COBOL / DB2) ปกติจะเจอโหลดหนักๆก็พวก month-end/quarter-end/year-end มีการจัดระเบียบ job ที่รัน job ไหน priority ไม่สูงก็ได้ resource ไม่เยอะ หรือโยกไปรันช่วงอื่น
ไม่ว่าจะเป็นการเพิ่มเครื่องหรือจูนโค้ดก็ต้องใช้งบ (upfront cost vs developer hours) ก็คงพอเห็นใจได้ว่าทำไมรัฐนี้ถึงไม่เคยทำ (คงส่ง proposal ไปแล้วโดนตีตก 555)
หืมม น่าสนใจที่บ.ยังใช้ COBOL อยู่ครับ และขอบคุณที่แชร์ให้ฟัง
ผมว่าจูนยังไงๆ ถึงจุดนึงมันก็จะตันใช่มั้ยครับ
ปล. COBOL มัน scale ได้มั้ย?
ก็มันไม่ work ถึงต้องประกาศหาคนมา touch ไงครับ
ประเด็นคือ เขาไม่เข้าใจว่ามันอยู่มาได้ยังไง
คำตอบคือ ก็เพราะก่อนหน้านี้มันไม่เคยมีปัญหานี่แหละ
คือระบบมันใช้ได้อยู่เดิม และใช้งานมานานปรับแก้มาเยอะ การเปลี่ยนมันคือการรื้อใหม่หมด และทำ feature เก่าใหม่ทั้งหมด
กรณีบ้านเราที่คล้ายๆกันคือ kbank ที่ย้ายจาก mainframe เป็นระบบใหม่ใช้เวลาถึง 10 ปี (แต่ก็ผ่านมาหลายคณะ รื้อเริ่มใหม่หลายรอบ) แถมตอนช่วงใหม่ๆ ก็มีปัญหาเยอะแยะ
จึงไม่น่าแปลกที่แทบไม่มีใครแตะระบบพวกนี้ เพราะลงทุนสูง (มาก) ใช้เวลานานมาก ในขณะที่ของเก่าในสถานการณ์ปกติมันใช้งานได้
อย่าลืมเห็นใจเครื่องอายุ 40 ปี กับประโยคนี้ด้วยนะครับ "รับโหลดสูงกว่าปกติ 16 เท่าตัว"
เมื่อ 40 ปีที่แล้ว มันอาจจะรับโหลด 16 เท่าสบายๆ เลยนะ
ดีไม่ดีอาจจะ "ไม่เคยบูต"
lewcpe.com, @wasonliw
ถ้า COBOL "อาจจะ" port ไป MainFrame ได้ และถ้า port ไป MainFrame ได้ ผมว่า IBM ยินดีให้ย้ายไปใช้ z รุ่นใหม่ๆ ได้ฟรีๆ เลยมั๊งช่วงนี้
ปล. แต่ต้องดู z/OS ด้วยละมั๊งว่า backward ไปได้ขนาดไหน หรือต่อให้โบราณจริง z9 น่าจะยังมี on อยู่บ้างนะ z9 นี่เปิดหัวเต็ม ก็ไม่ธรรมดานา
เขียนใหม่ด้วยภาษาอื่นดีกว่าไหม
โดยอาจต้องใช้ specification ของไฟล์ข้อมูลเดิม เพื่อให้ส่งออกและนำเข้าข้อมูลกันได้
ถ้าภาษา cobol น่าจะต้องเปลี่ยนเครื่องเลยน่ะครับ
เปลี่ยนให้ COBAL มารันบน VM, Cluster หรือรันบนเครื่อง Server ใหม่แทน เพื่อแก้ปัญหานี้ไม่ได้เลยเหรอครับ
หรือเปลี่ยนไปใช้ GnuCOBOL ที่รันบน Windows/Linux ได้ (พึ่งหาเจอใน Wiki) น่าจะ Compatible ส่วนใหญ่ของโปรแกรมนะ
ความล้มเหลว คือจุดเริ่มต้นสู่ความหายนะ มีผลกระทบมากกว่าแค่เสียเงิน เวลา อนาคต และทรัพยากรที่เสียไป - จงอย่าล้มเหลว
งานพวกนี้เน้น high availability ครับ ไม่ได้เปลี่ยนกันได้ง่ายๆเหมือนงานทั่วไป(กรณีนี้เข้าใจว่าบน mainframe ด้วย) แถมงาน support ก็ต้องดีเยี่ยมด้วย(แน่นอนว่าแพง)
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)