on
หลังจากเมื่อวานนี้เกิดเหตุ 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
@burkeholland
akira Sat, 19/06/2021 - 14:40
@burkeholland เคยเปลี่ยนฐานข้อมูลพนักงานทั้งบริษัทให้นามสกุลกลายเป็น Holland
ข้อนี้น่าจะเคยกันหลายคน เผลอลืมเลือก where excute ที หายนะมาเยือน ยิ่งสมัยทำงานใหม่ๆ ยังไม่รู้วิธีป้องกัน แทบไปต่อไม่เป็น
ผมก็กับตัวทีนึง
lew Sat, 19/06/2021 - 14:53
In reply to @burkeholland by akira
ผมก็กับตัวทีนึง
มองหา daily backup ทันที
เคยเผลอทำไปรอบนึง แต่ดีที่ว่า
osmiumwo1f Mon, 21/06/2021 - 10:37
In reply to @burkeholland by akira
เคยเผลอทำไปรอบนึง แต่ดีที่ว่า editor มันเตือนว่าจะส่ง UPDATE แบบไม่มี WHERE จริงๆ ใช่มั้ยครับ
editor ตัวไหนครับ น่าชื่นชม
lew Mon, 21/06/2021 - 17:05
In reply to เคยเผลอทำไปรอบนึง แต่ดีที่ว่า by osmiumwo1f
editor ตัวไหนครับ น่าชื่นชม
HeidiSQL ครับ
osmiumwo1f Mon, 21/06/2021 - 23:28
In reply to editor ตัวไหนครับ น่าชื่นชม by lew
HeidiSQL ครับ
ผมก็ใช้ตัวนี้
mementototem Tue, 22/06/2021 - 08:45
In reply to HeidiSQL ครับ by osmiumwo1f
ผมก็ใช้ตัวนี้ ตอนเจอแจ้งเตือนอันนี้นี่ ห๊ะ แล้วก็ wow มากเลยครับ
อีก 10 ปีต่อมา
mrmamon Sat, 19/06/2021 - 14:53
อีก 10 ปีต่อมา น้องคนนี้ก็จะเป็นคนทวิตให้กำลังใจเด็กฝึกงานรุ่นต่อไป แล้วบอกว่าเคยทดสอบส่งเมลผิดไปหาลูกค้า 44 ล้านคนทั่วโลก...
โปรแกรมเมอร์ทำงานวันแรกแต่เผล
whitebigbird Sat, 19/06/2021 - 14:57
โปรแกรมเมอร์ทำงานวันแรกแต่เผลอลบฐานข้อมูล Production, แอดมินที่ลบฐานข้อมูล GitLab เข้ามาให้กำลังใจ
ในข่าวตามลิงค์มีซ้อนกัน 2 ข่าว
แสดงว่า best practice ที่ว่า
iamfalan Sat, 19/06/2021 - 15:46
แสดงว่า best practice ที่ว่า "Developer ห้ามแตะฐานข้อมูล Production" ก็ไม่มีใครทำได้จริงสินะ ไม่ว่าบริษัทจะใหญ่แค่ไหน
สบายใจล่ะ
อาจเป็นเพราะ dup db จาก prod
whitebigbird Sat, 19/06/2021 - 19:10
In reply to แสดงว่า best practice ที่ว่า by iamfalan
อาจเป็นเพราะ dup db จาก prod มาใส่ staging แล้ว แต่ดันลืมแก้ api key ที่ใช้ส่งเมล์ไปใช้ api key สำหรับ prod ก็ได้ครับ
มันผิดได้หลายแบบมาก กรณีนี้สร้างความงงนิดเดียว ไม่ร้ายแรงแบบในหลายๆ กรณี
ที่ทำงานผม isolate network
trustme Sat, 19/06/2021 - 20:18
In reply to อาจเป็นเพราะ dup db จาก prod by whitebigbird
ที่ทำงานผม isolate network ระหว่าง PRD กับ environment อื่น เพื่อป้องกันปัญหาแบบนี้แหละ
ที่ใหญ่ๆปกติเขาน่าจะทำกันนะแบบนี้
ลองอ่านที่ผมพิมพ์อีกทีครับ
whitebigbird Sun, 20/06/2021 - 00:50
In reply to ที่ทำงานผม isolate network by trustme
ลองอ่านที่ผมพิมพ์อีกทีครับ
smtp server ของ UAT
Fourpoint Mon, 21/06/2021 - 00:01
In reply to อาจเป็นเพราะ dup db จาก prod by whitebigbird
smtp server ของ UAT ควรจะแยกกับของprod นะครับ(ถ้าcopyมาแล้วลืมเปลี่ยนมันก็ควรจะส่งออกไปไม่ได้ เพราะหาไม่เจอ) โดยเฉพาะถ้าจะ ส่งmail ไปนอกองค์กร ต้องแยกzone ไปอีกชั้น คือไม่ให้ส่งตรงได้ ต้องยิงผ่านตัวเชื่อมอีกที
แต่อย่างว่า การแยกzoneแบบนี้ มันก็ขึ้นกับว่าระบบมันsensitiveแค่ไหน มีมาตรฐานอะไรคลุมหรือเปล่า เช่นถ้าเป็นสายfinance banking ก็อาจจะมีPCIDSS บังคับพวกนี้ก็จะทำให้ต้องแยกzoning ไปในตัว
อาจใช้บริการส่งเมล์แบบ
whitebigbird Mon, 21/06/2021 - 00:34
In reply to smtp server ของ UAT by Fourpoint
อาจใช้บริการส่งเมล์แบบ mandrill ก็ได้ครับ ผมถึงใช้คำว่า api key
แสดงว่าคุณไม่ได้ isolated
Fourpoint Mon, 21/06/2021 - 11:14
In reply to อาจใช้บริการส่งเมล์แบบ by whitebigbird
แสดงว่าคุณไม่ได้ isolated environment ไงครับถึงใช้ร่วมกันได้
แต่ก็นั่นแหละบางระบบก็ไม่จำเป็นต้องทำขนาดนั้น พอดีพูดในมุมของระบบที่sensitive มันต้องออกแบบให้ไม่มีทางเกิดความผิดพลาดแบบนี้ขึ้นมาได้เลย เพราะมันไม่มีทางมองเห็นข้ามกันได้
อย่างที่ผมบอกอีกทีอ่ะครับ ...
whitebigbird Mon, 21/06/2021 - 11:19
In reply to แสดงว่าคุณไม่ได้ isolated by Fourpoint
อย่างที่ผมบอกอีกทีอ่ะครับ ... คัดลอก env file มาแล้วลืมแก้
ต่อให้ isolate env ขนาดไหนแต่ไม่ limit access ก็เท่านั้นครับ ดีไม่ดีเรื่องนี้อาจเกิดขึ้นบน laptop ของน้องใหม่ก็ได้
ง่า หลักการของการisolated
Fourpoint Tue, 22/06/2021 - 16:19
In reply to อย่างที่ผมบอกอีกทีอ่ะครับ ... by whitebigbird
ง่า หลักการของการisolated ก็คือการlimit access แยกกันอยู่แล้วล่ะครับ แต่ก็นั่นแหละ ขึ้นกับความจำเป็นของระบบ ไม่งั้นมันก็จะมีต้นทุนเพิ่มหลายเท่า ตามจำนวนวงของระบบ
ในฟามจริงทางปฏิบัติน่าจะต่างก
whitebigbird Tue, 22/06/2021 - 16:34
In reply to ง่า หลักการของการisolated by Fourpoint
ในฟามจริงทางปฏิบัติน่าจะต่างกันครับ และผมไม่คิดว่าเกิดจากความจำเป็น น่าจะเกิดจากความหละหลวมมากกว่า (อยากใช้คำว่าเชื่อใจนะ แต่มัน positive เกิน)
จากประสบการณ์
max212 Sat, 19/06/2021 - 21:35
In reply to แสดงว่า best practice ที่ว่า by iamfalan
จากประสบการณ์ มันเป็นสิ่งที่ต้องทำ Production เท่านั้น กับ ปัญหามักจะเกิดบน Production ระบบทดสอบจำลองปริมาณ Error สะสมมันไม่มากพอจนเห็นปัญหา อ่าวจะ Drump ข้อมูลมาทดสอบก็ไม่มี Resource พอ
รวมถึงประสบการณ์ของ Developer ก็มีผลนะ คนที่เคยผ่านระบบใหญ่ ๆ มาจะรู้ปัญหาของระบบใหญ่ ๆ จะรู้ว่าควรใช้ Infa ยังไง เขียน code ยังไง กว่าจะ Deploy จะระวังสุด ๆ เพื่อลดปัญหา ส่วนน้องใหม่ ทำระบบใหญ่ ถ้าไม่ตามเทคนิคใหม่ ๆ ก็หลุดแน่นอน
ผมก็เคยนะ เอาเวอชั่นใหม่ขึ้น
panther Sat, 19/06/2021 - 15:46
ผมก็เคยนะ เอาเวอชั่นใหม่ขึ้น prod เป็นเว็บภาษาฝรั่งเศส
เสร็จแล้วเข้าไปเชคก่อนจะไปพักกินข้าว พวกตัวอักขระพิเศษของฝรั่งเศสพังหมดจ้า
ต้องรีบแก้ที่พวกฝรั่งจะมาทำงาน วันนั้นอดข้าวเที่ยง แต่เหมือนจะไม่มีใครรู้ แก้เสร็จทันเค้ามาทำงานกันพอดี
ปล...มีฝรั่งคนนึงมาทำงานวันแรก ลบข้อมูลบน prod หายทั้งเทเบิลก็มีมาแล้ว
บริษัทผมพนักงานปกติไม่มี
pepporony Sat, 19/06/2021 - 16:13
บริษัทผมพนักงานปกติไม่มี access ที่จะเข้าไปอัพเดท prod data ได้คนที่จะขอ access ได้ต้องเป็นซีเนียร์ ต้องมี changelog มี approval ก็ช่วยกันได้ส่วนหนึ่ง
บ.เก่าผมต้องอนุมัติโดย CTO
mr_tawan Sun, 20/06/2021 - 20:14
In reply to บริษัทผมพนักงานปกติไม่มี by pepporony
บ.เก่าผมต้องอนุมัติโดย CTO ขึ้นไปเท่านั้น ใครต่ำกว่าไม่มีสิทธิ์เข้าไปดูหรือเปลี่ยนข้อมูล (เป็น data breach โทษปรับสูงมาก)
ตอยฝึกงาน เคยลบ ฐานข้อมูล
kyle Sat, 19/06/2021 - 16:47
ตอยฝึกงาน เคยลบ ฐานข้อมูล พนักงานในบริษัทออก เกลี้ยงเลย โชคดีมี ดึงแบกอัพกลับมาได้
เคยเหมือนกัน
kswisit Sat, 19/06/2021 - 17:15
เคยเหมือนกัน ตั้งแต่นั้นมาจะใส่ begin trans .... rollback ครอบตลอด เอาจนชัวร์แล้วค่อย commit
5555 เคยลบ Production
Hadakung Sat, 19/06/2021 - 23:09
5555 เคยลบ Production ลูกค้าแล้วไม่มี DB Backup ต้องไล่หา Excel มาเติมแทบตาย...
ก้อ Excel นั่นแหละ
sp Sun, 20/06/2021 - 09:18
In reply to 5555 เคยลบ Production by Hadakung
ก้อ Excel นั่นแหละ เขาเรียกว่า backup ใช่ไหมครับ สมัยผมเรียนหนังสือ เขา backup ด้วย transaction slip ที่เป็นกระดาษอ่ะ ระบบเน่าเอามาคียด้วยมือ
ผมไม่เรียก excel ว่า backup
Lightwave Sun, 20/06/2021 - 11:12
In reply to ก้อ Excel นั่นแหละ by sp
ผมไม่เรียก excel ว่า backup นะ มันค่อนข้างเสียเวลากว่าใช้ db ตรงๆ
สมัยเรียนใกล้จบ
sMaliHug Sun, 20/06/2021 - 15:04
สมัยเรียนใกล้จบ มีคาบเรียนไม่กี่คาบจึงหางานพิเศษทำ (ไม่ใช่ฝึกงานซะทีเดียว)
มีโอกาสได้ทำงานในบริษัทยางเจ้าใหญ่ ตอนนั้นยังใช้ netware อยู่เลย การเห็นห้อง server เห็นตู้แร็ค ตื่นเต้นมาก
วันหนึ่งลืม backup tape กลับถึงบ้านเพิ่งนึกได้ เคลียดมาก จนหาลาออก ไม่ไปทำอีกเลย
เชื่อว่าเกือบทุกคนมีประสบการณ
btoy Sun, 20/06/2021 - 16:44
เชื่อว่าเกือบทุกคนมีประสบการณ์ทำอะไรผิดพลาดบน PRD เกือบหมดล่ะเนอะ
ของผมมี 2 ครั้ง อันนี้เป็น Interface จากอีกระบบ ข้อมูลเข้าไปซ้ำกันมั้ง กับอีกอันนึง มีบั๊กที่ถ้าเข้าเงื่อนไขนี้ โปรแกรมจะลบข้อมูลแบบเกินไปจาก where clause ที่ตั้งใจไว้ อันนี้หัวใจหล่นไปอยู่ตาตุ่มเลยครับ เพราะเป็นข้อมูล Finance ด้วย
มันก็ป้องกันได้
Fourpoint Mon, 21/06/2021 - 00:01
มันก็ป้องกันได้ ถ้ามี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 ผิด..
nant Tue, 22/06/2021 - 19:32
เคยเหมือนกัน คำนวน vat ผิด...หายไปคนละ 1 สตางค์