By: lew 
on 19 June 2021 - 14:30
Tags:
Topics:
หลังจากเมื่อวานนี้เกิดเหตุ HBO Max ส่งอีเมล "Integration Test Email #1" ไปยังผู้ใช้จำนวนมากทั่วโลก ทาง HBO Max ก็ออกมาขออภัย พร้อมกับยืนยันว่าพนักงานฝึกงานเป็นผู้ส่งเมลตามที่มีคนล้อกันจำนวนมาก พร้อมกับระบุว่ากำลังช่วยเหลือให้พนักงานผ่านเหตุการณ์นี้ไปได้
หลังจากข้อความชี้แจงนี้ออกมาวิศวกรทั่วโลกก็พากันส่งข้อความให้กำลังใจพร้อมเล่าประสบการณ์ความผิดพลาดในการทำงานของตัวเอง เช่น @rakyll วิศวกรอาวุโสของ AWS เล่าว่าเคยลบฐานข้อมูลโปรดักชั่น, @ocho_rios88 เล่าว่าเคยอัพเกรดระบบไอทีของสถานีโทรทัศน์แล้วระบบไม่เสถียรไปทั้งเดือน, @daenney เคยทำ Spotify ล่มทั้งโลก, @burkeholland เคยเปลี่ยนฐานข้อมูลพนักงานทั้งบริษัทให้นามสกุลกลายเป็น Holland
ทั้ง reply และ quote ยังมีอีกจำนวนมาก หลายคนไม่ได้ให้กำลังใจโดยตรง เช่น @mekkaokereke จาก Google Play ระบุว่าเหตุการณ์นี้เป็นเรื่องดีที่ช่วยให้ทีมเจอจุดที่ต้องป้องกันเพิ่มเติม
ที่มา - @HBOMaxHelp
We mistakenly sent out an empty test email to a portion of our HBO Max mailing list this evening. We apologize for the inconvenience, and as the jokes pile in, yes, it was the intern. No, really. And we’re helping them through it. ❤️
— HBOMaxHelp (@HBOMaxHelp) June 18, 2021
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- สรุปสาระสำคัญและของใหม่จาก Microsoft Ignite 2023 | Cloudnone Special EP
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
- สงคราม AI 2024: OpenAI ชิงปาดหน้า Google วันเดียว | Cloudnone EP.17
- Microsoft, Amazon, Google ประกาศตั้ง Data Center ในไทย แล้วไงต่อ | Cloudnone EP 16
- สงคราม GenAI บนคลาวด์ในปี 2024 ไปถึงไหนกันแล้ว | Cloudnone x AWS
Comments
@burkeholland เคยเปลี่ยนฐานข้อมูลพนักงานทั้งบริษัทให้นามสกุลกลายเป็น Holland
ข้อนี้น่าจะเคยกันหลายคน เผลอลืมเลือก where excute ที หายนะมาเยือน ยิ่งสมัยทำงานใหม่ๆ ยังไม่รู้วิธีป้องกัน แทบไปต่อไม่เป็น
ผมก็กับตัวทีนึง
มองหา daily backup ทันที
lewcpe.com, @wasonliw
เคยเผลอทำไปรอบนึง แต่ดีที่ว่า editor มันเตือนว่าจะส่ง UPDATE แบบไม่มี WHERE จริงๆ ใช่มั้ยครับ
editor ตัวไหนครับ น่าชื่นชม
lewcpe.com, @wasonliw
HeidiSQL ครับ
ผมก็ใช้ตัวนี้ ตอนเจอแจ้งเตือนอันนี้นี่ ห๊ะ แล้วก็ wow มากเลยครับ
Jusci - Google Plus - Twitter
อีก 10 ปีต่อมา น้องคนนี้ก็จะเป็นคนทวิตให้กำลังใจเด็กฝึกงานรุ่นต่อไป แล้วบอกว่าเคยทดสอบส่งเมลผิดไปหาลูกค้า 44 ล้านคนทั่วโลก...
โปรแกรมเมอร์ทำงานวันแรกแต่เผลอลบฐานข้อมูล Production, แอดมินที่ลบฐานข้อมูล GitLab เข้ามาให้กำลังใจ
ในข่าวตามลิงค์มีซ้อนกัน 2 ข่าว
แสดงว่า best practice ที่ว่า "Developer ห้ามแตะฐานข้อมูล Production" ก็ไม่มีใครทำได้จริงสินะ ไม่ว่าบริษัทจะใหญ่แค่ไหน
สบายใจล่ะ
อาจเป็นเพราะ dup db จาก prod มาใส่ staging แล้ว แต่ดันลืมแก้ api key ที่ใช้ส่งเมล์ไปใช้ api key สำหรับ prod ก็ได้ครับ
มันผิดได้หลายแบบมาก กรณีนี้สร้างความงงนิดเดียว ไม่ร้ายแรงแบบในหลายๆ กรณี
ที่ทำงานผม isolate network ระหว่าง PRD กับ environment อื่น เพื่อป้องกันปัญหาแบบนี้แหละ
ที่ใหญ่ๆปกติเขาน่าจะทำกันนะแบบนี้
ลองอ่านที่ผมพิมพ์อีกทีครับ
smtp server ของ UAT ควรจะแยกกับของprod นะครับ(ถ้าcopyมาแล้วลืมเปลี่ยนมันก็ควรจะส่งออกไปไม่ได้ เพราะหาไม่เจอ) โดยเฉพาะถ้าจะ ส่งmail ไปนอกองค์กร ต้องแยกzone ไปอีกชั้น คือไม่ให้ส่งตรงได้ ต้องยิงผ่านตัวเชื่อมอีกที
แต่อย่างว่า การแยกzoneแบบนี้ มันก็ขึ้นกับว่าระบบมันsensitiveแค่ไหน มีมาตรฐานอะไรคลุมหรือเปล่า เช่นถ้าเป็นสายfinance banking ก็อาจจะมีPCIDSS บังคับพวกนี้ก็จะทำให้ต้องแยกzoning ไปในตัว
อาจใช้บริการส่งเมล์แบบ mandrill ก็ได้ครับ ผมถึงใช้คำว่า api key
แสดงว่าคุณไม่ได้ isolated environment ไงครับถึงใช้ร่วมกันได้
แต่ก็นั่นแหละบางระบบก็ไม่จำเป็นต้องทำขนาดนั้น พอดีพูดในมุมของระบบที่sensitive มันต้องออกแบบให้ไม่มีทางเกิดความผิดพลาดแบบนี้ขึ้นมาได้เลย เพราะมันไม่มีทางมองเห็นข้ามกันได้
อย่างที่ผมบอกอีกทีอ่ะครับ ... คัดลอก env file มาแล้วลืมแก้
ต่อให้ isolate env ขนาดไหนแต่ไม่ limit access ก็เท่านั้นครับ ดีไม่ดีเรื่องนี้อาจเกิดขึ้นบน laptop ของน้องใหม่ก็ได้
ง่า หลักการของการisolated ก็คือการlimit access แยกกันอยู่แล้วล่ะครับ แต่ก็นั่นแหละ ขึ้นกับความจำเป็นของระบบ ไม่งั้นมันก็จะมีต้นทุนเพิ่มหลายเท่า ตามจำนวนวงของระบบ
ในฟามจริงทางปฏิบัติน่าจะต่างกันครับ และผมไม่คิดว่าเกิดจากความจำเป็น น่าจะเกิดจากความหละหลวมมากกว่า (อยากใช้คำว่าเชื่อใจนะ แต่มัน positive เกิน)
จากประสบการณ์ มันเป็นสิ่งที่ต้องทำ Production เท่านั้น กับ ปัญหามักจะเกิดบน Production ระบบทดสอบจำลองปริมาณ Error สะสมมันไม่มากพอจนเห็นปัญหา อ่าวจะ Drump ข้อมูลมาทดสอบก็ไม่มี Resource พอ
รวมถึงประสบการณ์ของ Developer ก็มีผลนะ คนที่เคยผ่านระบบใหญ่ ๆ มาจะรู้ปัญหาของระบบใหญ่ ๆ จะรู้ว่าควรใช้ Infa ยังไง เขียน code ยังไง กว่าจะ Deploy จะระวังสุด ๆ เพื่อลดปัญหา ส่วนน้องใหม่ ทำระบบใหญ่ ถ้าไม่ตามเทคนิคใหม่ ๆ ก็หลุดแน่นอน
ผมก็เคยนะ เอาเวอชั่นใหม่ขึ้น prod เป็นเว็บภาษาฝรั่งเศส
เสร็จแล้วเข้าไปเชคก่อนจะไปพักกินข้าว พวกตัวอักขระพิเศษของฝรั่งเศสพังหมดจ้า
ต้องรีบแก้ที่พวกฝรั่งจะมาทำงาน วันนั้นอดข้าวเที่ยง แต่เหมือนจะไม่มีใครรู้ แก้เสร็จทันเค้ามาทำงานกันพอดี
ปล...มีฝรั่งคนนึงมาทำงานวันแรก ลบข้อมูลบน prod หายทั้งเทเบิลก็มีมาแล้ว
บริษัทผมพนักงานปกติไม่มี access ที่จะเข้าไปอัพเดท prod data ได้คนที่จะขอ access ได้ต้องเป็นซีเนียร์ ต้องมี changelog มี approval ก็ช่วยกันได้ส่วนหนึ่ง
บ.เก่าผมต้องอนุมัติโดย CTO ขึ้นไปเท่านั้น ใครต่ำกว่าไม่มีสิทธิ์เข้าไปดูหรือเปลี่ยนข้อมูล (เป็น data breach โทษปรับสูงมาก)
ตอยฝึกงาน เคยลบ ฐานข้อมูล พนักงานในบริษัทออก เกลี้ยงเลย โชคดีมี ดึงแบกอัพกลับมาได้
เคยเหมือนกัน ตั้งแต่นั้นมาจะใส่ begin trans .... rollback ครอบตลอด เอาจนชัวร์แล้วค่อย commit
^
^
that's just my two cents.
5555 เคยลบ Production ลูกค้าแล้วไม่มี DB Backup ต้องไล่หา Excel มาเติมแทบตาย...
ก้อ Excel นั่นแหละ เขาเรียกว่า backup ใช่ไหมครับ สมัยผมเรียนหนังสือ เขา backup ด้วย transaction slip ที่เป็นกระดาษอ่ะ ระบบเน่าเอามาคียด้วยมือ
ผมไม่เรียก excel ว่า backup นะ มันค่อนข้างเสียเวลากว่าใช้ db ตรงๆ
สมัยเรียนใกล้จบ มีคาบเรียนไม่กี่คาบจึงหางานพิเศษทำ (ไม่ใช่ฝึกงานซะทีเดียว)
มีโอกาสได้ทำงานในบริษัทยางเจ้าใหญ่ ตอนนั้นยังใช้ netware อยู่เลย การเห็นห้อง server เห็นตู้แร็ค ตื่นเต้นมาก
วันหนึ่งลืม backup tape กลับถึงบ้านเพิ่งนึกได้ เคลียดมาก จนหาลาออก ไม่ไปทำอีกเลย
เชื่อว่าเกือบทุกคนมีประสบการณ์ทำอะไรผิดพลาดบน PRD เกือบหมดล่ะเนอะ
ของผมมี 2 ครั้ง อันนี้เป็น Interface จากอีกระบบ ข้อมูลเข้าไปซ้ำกันมั้ง กับอีกอันนึง มีบั๊กที่ถ้าเข้าเงื่อนไขนี้ โปรแกรมจะลบข้อมูลแบบเกินไปจาก where clause ที่ตั้งใจไว้ อันนี้หัวใจหล่นไปอยู่ตาตุ่มเลยครับ เพราะเป็นข้อมูล Finance ด้วย
..: เรื่อยไป
มันก็ป้องกันได้ ถ้ามีprocedure ที่ดีล่ะนะ เช่นห้าม access DB prodโดยตรง จะทำอะไร ต้องออก CR เขียนscript มีผลtest UATเรียบร้อย แล้วส่งscriptให้executor เป็นคนรัน ไม่ใช่เรารันเอง สำคัญคือห้ามใช้เครื่องส่วนตัวconnect เข้าdb ต้องใช้terminalจำกัดเท่านั้น
ตอนทำงานใหม่ๆเคยคิดว่าระบบพวกนี้ยุ่งยาก ทำเสียเวลา แต่พอพลาดเองก็จะเข้าใจเลยว่า ถ้ามีขั้นตอนเยอะๆมันก็ป้องกันได้ระดับนึงเลย
แต่ถ้ามีincident อันนี้ก็เหมือนจะเป็นช่องโหว่หลายๆที่ คือยังdevให้access ไปinvestigateหรือแก้ไขโดยตรงได้ ยิ่งโควิทWFH เลยกลายเป็นว่า remoteซ้อนremote หรือexecutor แชร์หน้าจอให้เราดูผ่านms team เป็นเรื่องธรรมดา(แต่ถ้ามองในมุมsecurityก็หวาดเสียวหน่อยต่อให้ต้องผ่านVPNก็ตาม)
เคยเหมือนกัน คำนวน vat ผิด...หายไปคนละ 1 สตางค์