ความผิดพลาดของฉันช่วยบริษัทประหยัดเงินได้ 500,000 ดอลลาร์
(ludic.mataroa.blog)- วิศวกรคนหนึ่งลดค่า การตั้งค่าให้ว่าง 10 นาที หลังการรันคิวรีของ Snowflake ทำให้ค่าใช้จ่ายฐานข้อมูลที่คาดการณ์ต่อปีลดลงจากราว 1 ล้านดอลลาร์เหลือ 500,000 ดอลลาร์
- Advanced Analytics Platform ที่ล่าช้ามาหลายปี แม้เปิดใช้งานแล้วก็ยังพึ่งพา สายโซ่ ETL ที่ซับซ้อน ซึ่งพันกันระหว่างสเปรดชีต, S3, Lambda, MongoDB, Snowflake และ JavaScript stored procedure
- แกนของการสิ้นเปลืองค่าใช้จ่ายคือโครงสร้างที่ประมวลผลข้อมูลไม่ถึง 1TB ต่อวัน แต่กลับปล่อยให้คอมพิวต์เปิดค้างไว้นานหลัง คิวรีเฉลี่ย 2 วินาที
- การเปลี่ยนแปลงถูกนำไปใช้กับคอมพิวต์เพียงบางส่วนก่อน ผู้จัดการยอมรับผลการประหยัด แต่ก็พยายามชะลอการใช้ทั่วทั้งระบบ และใน PowerPoint ก็ถูกทำให้ดูเหมือนเป็นการปรับแต่งจาก การวิเคราะห์รูปแบบการใช้งาน
- แม้จะลดค่าใช้จ่ายได้ 500,000 ดอลลาร์แล้ว ผลตอบแทนก็ยังไม่แน่นอน มีแต่ภาระประชุมและรายงานที่เพิ่มขึ้น กลายเป็นตัวอย่างว่าความไร้ประสิทธิภาพขององค์กรสร้างต้นทุนทางการเมืองที่สูงกว่าการลงมือทำสั้น ๆ ของบุคคล
แพลตฟอร์มวิเคราะห์ที่ถูกเลื่อนมาหลายปี
- บริษัทประกาศว่าจะทำงานให้ ขับเคลื่อนด้วยข้อมูล มากขึ้น จึงตัดสินใจสร้างแพลตฟอร์มวิเคราะห์และจ้างคนที่เกี่ยวข้องเข้ามา
- วิศวกรที่เข้ามาในตำแหน่งนักวิทยาศาสตร์ข้อมูลกลับไม่ได้ทำงานด้าน data science จริง ๆ และเมื่อขอคอมพิวต์สำหรับงานแมชชีนเลิร์นนิงหรือ data pipeline ก็ได้รับคำตอบให้รอจนกว่า Advanced Analytics Platform หรือ AAP จะ deploy เสร็จ
- เดิม AAP มีกำหนดเปิดตัวในเดือนมกราคม แต่เลื่อนไปมีนาคม และหลังจากนั้นก็ถูกพักไว้โดยอ้างเหตุผลเรื่อง Covid
- หลังจากเขาออกจากบริษัทไปแล้ว 3 ปี AAP ก็พร้อมเปิดใช้งาน แต่กลับพบว่าฟีเจอร์ที่จำเป็นจริง ๆ ไม่ได้อยู่ในแผนตั้งแต่แรก
- ในสัปดาห์เดียวกันนั้น วิศวกร 4 คนลาออกจากบริษัท และเขาก็เข้าร่วมทีม AAP หลังยื่นเงื่อนไขบางอย่าง
หนี้ทางเทคนิคที่เผยออกมาทันทีหลังเปิดใช้งาน
- AAP เพิ่งเปิดใช้งานได้ไม่นานก็มีทั้ง หนี้ทางเทคนิค และความเสี่ยงในการปฏิบัติการจำนวนมาก
- เพื่อนร่วมงานที่เพิ่งเข้ามาใหม่พบตั้งแต่วันแรกว่า หากเข้าไปยังโฟลเดอร์ผิดใน repository ของโปรเจกต์ ก็อาจลบ production ได้ผ่าน CI/CD pipeline
- ไฟล์นั้นยังมีคีย์และรหัสผ่านที่จำเป็นสำหรับบัญชีผู้ดูแลระบบอยู่ด้วย
- การเปลี่ยนสิทธิ์เข้าถึงฐานข้อมูลเป็นงานแค่อัปโหลดไฟล์ CSV ขนาดราว 2KB แต่กลับต้องผ่านเส้นทางที่ยาวเกินจำเป็น
- Python แยกวิเคราะห์สเปรดชีต
- นำผลลัพธ์ไปใส่ใน S3
- Lambda แปลงมันกลับไปเป็น S3 อีกครั้ง
- MongoDB ดึงไฟล์จาก S3
- Lambda อีกตัวส่งเรคอร์ดจาก MongoDB ไปยัง S3
- Snowpipe นำข้อมูลจาก S3 เข้า Snowflake
- JavaScript stored procedure จัดรูปข้อมูลจาก Snowflake ใหม่ให้เป็น relational format
- ทีมความปลอดภัยต้องการรูปแบบที่สแกนเนื้อหาอันตรายได้ง่าย จึงทำให้ทุกอย่างถูกแปลงเป็น CSV แต่สุดท้าย เครื่องมือสแกน ที่ว่าไม่ได้ถูก deploy จริง
- ฟังก์ชัน Lambda เริ่มต้นด้วย
counter = 1ซึ่งเป็นร่องรอยจาก implementation เดิม และบรรทัดนี้ก็ถูกคัดลอกต่อกันมาเรื่อย ๆ - การทดสอบ CI/CD อยู่ในสถานะล้มเหลวต่อเนื่องหลายเดือน เพราะระหว่างดีบักมีการใช้คำสั่ง
teeจนทำให้รหัสความล้มเหลวถูกเขียนทับ - แม้แต่การดึงรหัสผ่าน API ก็ซับซ้อนเป็นสองชั้น
- หากค้นหาคีย์อย่าง
service-passwordในบริการ AWS ก็จะได้ค่าเป็นservice-passwordเช่นกัน - จากนั้นต้องนำค่านั้นไปใช้ค้นหารหัสผ่านจริงในอีกบริการหนึ่ง
- หากค้นหาคีย์อย่าง
- สคริปต์สร้างไฟล์ตั้งค่า pipeline เริ่มต้นด้วยโค้ดที่คอมเมนต์ทิ้งไว้ 600 บรรทัด เพราะคิดว่าอาจจำเป็นในภายหลัง
การตั้งค่า Snowflake ที่ทำให้ค่าใช้จ่ายบานปลาย
- แพลตฟอร์มนี้มีค่าใช้จ่ายสูงกว่ารูปแบบการปฏิบัติการเดิมหลายเท่า และเกินงบค่าฐานข้อมูลอย่างมาก
- เดิมทีดูเหมือนตั้งใจให้มีค่าใช้จ่ายดำเนินงานราว 200,000 ดอลลาร์ ต่อปี แต่ต้นทุนที่คาดการณ์จริงกลับพุ่งเกือบแตะ 1 ล้านดอลลาร์
- ฐานข้อมูลที่ใช้คือ Snowflake และ Snowflake คิดค่าบริการตามขนาดของคอมพิวเตอร์ที่ใช้รันคิวรี
- ค่าใช้จ่ายของคอมพิวต์จะเกิดขึ้นเฉพาะตอนที่มันเปิดอยู่
- ทีมรันคิวรีหลายพันครั้งต่อสัปดาห์ โดยส่วนใหญ่เป็นคิวรีสำหรับการทดลองของนักพัฒนาที่ค่อย ๆ ปรับรายงาน PowerBI ซึ่งแทบไม่มีใครเปิดอ่าน
- เวลารันคิวรีเฉลี่ยอยู่ที่ประมาณ 2 วินาที แต่คอมพิวต์ถูกตั้งให้คงสถานะว่างไว้อีก 10 นาทีหลังจบคิวรี
- ราวหนึ่งเดือนหลังเข้าร่วมทีม เขาพบการตั้งค่านี้และเสนอให้ปรับ แต่การพูดคุยกลับวนเวียนอยู่กับขั้นตอนเรื่องการทำ discovery โดยไม่มีการลงมือจริง
การเปลี่ยนแปลง 5 นาทีและการยืนยันผล
- หลายเดือนต่อมา เขาได้รับการ์ด “Discovery: Optimise Costs” และต้องมีผลลัพธ์ไปพูดใน standup ถัดไป จึงตัดสินใจตรวจสอบสมมติฐานเดิมด้วยตัวเอง
- เขาขอให้วิศวกรใหม่จากอีกทีมที่ดูมีความสามารถได้รับสิทธิ์ผู้ดูแลระบบ แต่ผู้จัดการไม่อนุญาต
- ผู้จัดการกลับแชร์ credential ฐานข้อมูลระดับต่ำที่ไม่ใช่สิทธิ์ผู้ดูแลแทน และวิศวกรคนนั้นก็ช่วย ตรวจสอบความสมเหตุสมผล ของโอกาสในการลดต้นทุน
- เวลา 4 โมงเย็นของวันทำงานสุดท้ายในสัปดาห์ เขาตรวจสอบในแชตของวิศวกรที่ไม่มีผู้ดูแลระบบอยู่ว่าไม่มีปัญหาอะไร ก่อนจะเปลี่ยนการตั้งค่า
- เพื่อความปลอดภัย เขาเริ่มใช้กับ คอมพิวต์เพียงบางส่วน ก่อน ไม่ได้ใช้กับทั้งหมด
ผลการประหยัดและปฏิกิริยาขององค์กร
- เช้าวันจันทร์ถัดมา ยอดบิลที่คาดการณ์ลดลงจากราว 1 ล้านดอลลาร์เหลือ 500,000 ดอลลาร์
- ทีมพยายามทำให้เรื่องนี้ดูเป็นความสำเร็จด้านการประหยัดต้นทุนครั้งใหญ่ แต่ในมุมมองของเขา มันใกล้เคียงกับการหยุดการเผาเงินที่เกิดขึ้นอยู่แล้วมากกว่า
- ทีมอื่นตั้งข้อสงสัยว่าเหตุใดวิศวกรที่เพิ่งเข้ามาใหม่จึงเกิดขึ้นพร้อมกับการประหยัดครั้งนี้ และทำไมก่อนหน้านี้ถึงไม่มีใครรู้ว่าลดต้นทุนได้แบบนี้
- ผู้จัดการดีใจ แต่ก็มองว่าหากนำการเปลี่ยนแปลงไปใช้กับคอมพิวต์ทั้งหมดทันที แผนกอาจถูกจับตามองมากเกินไปและเจอคำถามที่ไม่ต้องการ
- มีนัยว่าควรค่อย ๆ ทยอยใช้ เพื่อให้ดูเหมือนเป็นงานที่ใช้เวลานาน
- เขาต้องทำ PowerPoint และข้อความก็ถูกเรียบเรียงในทำนองว่า “การวิเคราะห์ทางสถิติอย่างรอบคอบเกี่ยวกับรูปแบบการใช้งานเผยให้เห็นโอกาสในการจัดสรรทรัพยากรได้อย่างมีประสิทธิภาพมากขึ้น”
- ทั้งที่การเปลี่ยนจริง ๆ คือแค่การปรับตั้งค่าไม่ให้คอมพิวต์ราคาแพงถูกปล่อยว่างค้างไว้ทั้งวัน
ภาระที่เหลืออยู่หลังความสำเร็จ
- เขามองว่าการหาเพียงวิศวกรเก่ง ๆ สักไม่กี่คนแล้วขยับกันอย่างไม่เป็นทางการ ทำให้ได้ผลงานที่มากกว่าได้ง่ายกว่าทั้งแผนกเสียอีก
- เขาตัดสินว่าคนมีความสามารถมีอยู่ในองค์กร แต่โครงสร้างองค์กรทำให้พวกเขาใช้ศักยภาพไม่ได้
- หลังช่วยประหยัดเงินได้ 500,000 ดอลลาร์ เขาขอขึ้นเงินเดือน 30,000 ดอลลาร์ แต่ข้อความนั้นถูกอ่านข้ามไป และเขาคาดว่าสุดท้ายอาจไม่ได้อะไรเลยหรือได้เพียงราว 5,000 ดอลลาร์
- มีการนัดประชุมเพื่อพูดถึงการลดต้นทุนมากขึ้น และยังมีภาระในการทำ PowerPoint เพิ่มเข้ามา
- เขาปิดท้ายว่าการไม่ทำอะไรเลยอาจเป็นผลดีกับตัวเองมากกว่า เพราะแค่ลงมือ 5 นาที เขาก็สร้างผลงานที่ใหญ่ที่สุดในอาชีพ แต่กลับต้องแบกรับภาระเพิ่มเติมทันที
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ทั้งบทความนี้ทำให้รู้สึกร่วมมาก
ประวัติผลงานด้านการลดต้นทุนที่ผมทิ้งไว้ใน US Navy คือ มากกว่า 50 ล้านดอลลาร์ ทุกครั้งที่ทำอะไรสักอย่างก็ต้องทำ PowerPoint แล้วนำเสนอต่อนายพล และครั้งหนึ่งเกือบถูกลงโทษหนักเพียงเพราะไม่ได้ปล่อยให้หัวหน้าเอาผลงานไป ทั้งที่จริง ๆ แล้วหัวหน้าคนนั้นไม่รู้เลยด้วยซ้ำว่าผมทำอะไร จึงไม่ได้คิดจะเอาผลงานไปอยู่แล้ว
ส่วนหนึ่งในนั้นเป็นช่วงที่ทำโปรเจกต์ระดับทั้งองค์กรในฐานะ Lean Six-Sigma Black Belt ซึ่งถึงขั้นทำให้ผมเกลียดคำเรียกนี้ทั้งคำ งานนั้นคือ ลดค่าใช้จ่ายของ DOD ให้มากที่สุดเท่าที่ทำได้ ตามตัวอักษร และเป็นช่วงที่แย่ที่สุดในอาชีพ รางวัลจากการแก้ปัญหาที่ช่วยประหยัดเงินได้หลายล้านดอลลาร์แบบลงมือทำเอง ก็คืองานนั้นเอง
เห็นด้วยกับช่วงท้ายของบทความ ต้องระวังเวลาไปทำสิ่งดี ๆ ในที่ทำงาน รางวัลแทบไม่เคยเป็นเงิน แต่จะกลับมาในรูปของงานที่มากขึ้นด้วยเงินเดือนเท่าเดิม
ก่อนหน้านี้ผมเคยอยู่ในที่ที่ดีกว่านี้มาก และถ้าผมตั้งใจออกหน้าเพื่อช่วยประหยัดเงินหลายล้านดอลลาร์ ผมก็ได้รับการยินดีจริง ๆ และหัวหน้าก็ยอมรับผลงานให้
ห้ามอยู่ในที่ทำงานที่มี วัฒนธรรมเป็นพิษ เด็ดขาด ต่อให้เงินดีกว่าก็ตาม ไม่มีอะไรบั่นทอนจิตวิญญาณได้เท่ากับการถูกพวกนักไต่เต้าที่ไร้ความสามารถและใจแคบ กับพวกบ้าควบคุมกดทับ
ประเด็นหลักคือ “ข้อดีของรัฐบาลสหรัฐฯ คือมันใหญ่มาก ขนาดที่ถ้าคำตอบที่ดีที่สุดช่วยลดได้ 30% แต่ทางเลือกที่รองลงมาลดได้แค่ 29% ก็ยังประหยัดได้หลายสิบล้านถึงหลายร้อยล้านดอลลาร์อยู่ดี จนไม่มีใครสังเกตเห็น”
หนึ่งในโปรเจกต์ใหญ่คือ ประสิทธิภาพพลังงานของค่ายทหารระยะไกล ถ้าส่งเชื้อเพลิงไปถึงบางพื้นที่ของอัฟกานิสถาน ต้นทุนจะอยู่ที่ประมาณ 100 ดอลลาร์ต่อแกลลอน และเครื่องปั่นไฟเคลื่อนที่จำนวนมากก็เดินเครื่องกันอยู่แค่ราว 20–40% ของกำลังผลิต ถ้าจำไม่ผิด ประมาณ 70% คือจุดที่มีประสิทธิภาพที่สุด ดังนั้นแค่สร้างอาคารเล็ก ๆ หรือรวมเต็นท์หลายหลังให้ใช้เครื่องปั่นไฟเครื่องเดียวกัน ก็ลดการใช้เชื้อเพลิงได้มากและยังปรับปรุงคุณภาพบริการได้ด้วย
ในฐานะวิศวกร FAANG ผมเคยทำงานที่เกี่ยวข้องโดยตรงกับกระแสเงิน และมีประสบการณ์ในหลายด้านที่น่าจะเป็นประโยชน์
แต่แล้วก็คิดว่าการหาคนที่เหมาะสมและพื้นที่งานที่เหมาะสมน่าจะเป็น 95% ของงาน เลยยอมแพ้ไป
แต่โครงสร้างกลับเป็นว่าถ้าไปเข้าอบรมหลักสูตรนี้ ก็จะถูกดันเรื่องเลื่อนตำแหน่งอย่างรวดเร็ว
ผมอยากได้งานมนุษย์เงินเดือนที่มั่นคง แต่ก็รู้ว่าถ้าผมทำได้ดี ผู้จัดการจะมองสิ่งนั้นเป็นเวลาว่าง แล้วโยนงานเพิ่มมาให้จนสุดขีด คนโลภไม่มีทางยอมแบ่งรายได้หรือแบ่งกำไรเด็ดขาด แค่จะให้ขึ้นเงินเดือนปีละ 5% แล้วบอกให้หุบปากทำงานไป
เมื่อหลายงานก่อน บริษัทให้ผมเขียนชื่อโปรเจกต์ที่ผมดูแลบำรุงรักษาอยู่แบบแอ็กทีฟ รายการนั้นใน Excel ขนาดฟอนต์ปกติเต็มไป สองหน้าจอเต็ม ๆ ผมหมดไฟจนถึงขั้นซึมเศร้าหนัก
ที่แย่กว่านั้นคือผมก็เกลียดเรื่องไร้สาระอย่างพิธีกรรมแห่งการจำยอมที่เรียกว่าการหางานด้วย
ทำให้นึกถึงบทความของ Dan Luu: https://danluu.com/nothing-works/
เครื่องมือซอฟต์แวร์สำหรับชิปก็คล้ายกัน มาตรฐานคือจ้างผู้ขาย EDA รายใหญ่ทำเครื่องมือให้ แต่เครื่องมือแบบปรับแต่งเองที่เราสร้างให้ผลลัพธ์ดีมาก และโดยปกติจะมีคนคนเดียวสร้างหรือดูแล
ตอนที่ผมอยู่ที่นั่น รอบการจำลองส่วนใหญ่รันบนซิมูเลเตอร์แบบปรับแต่งเองที่มีคนคนเดียวดูแล และนั่นช่วยประหยัดค่าใช้จ่ายซิมูเลเตอร์ได้หลายล้านดอลลาร์ต่อปี ตอนนั้นราคามาตรฐานคือไลเซนส์ซิมูเลเตอร์หนึ่งตัวปีละหลายพันดอลลาร์ และฟาร์มเครื่องจำลองมีประมาณหนึ่งพันเครื่อง
ถ้าคนคนเดียวสามารถสร้างหรือดูแลเครื่องมือที่มีมูลค่าหลายล้านดอลลาร์ต่อปีให้บริษัทได้ ก็เหมือนว่าคู่แข่งก็ควรทำเช่นกันโดยธรรมชาติ แต่ในความเป็นจริง ส่วนใหญ่ไม่ได้ทำ ก็เหมือนกับที่คู่แข่งไม่จ้างคนที่เปิดดูเวเฟอร์เป็น ทั้งที่การทำแบบนั้นจะช่วยให้ออกสินค้าได้เร็วขึ้นและถูกลง
Dan Luu พูดถึง “สมมติฐานตลาดมีประสิทธิภาพเวอร์ชันงานค็อกเทลปาร์ตี้” แต่เวอร์ชันเศรษฐศาสตร์ของ “ไม่มีอะไรใช้การได้” น่าจะใกล้เคียงกับ https://en.wikipedia.org/wiki/The_Market_for_Lemons มากกว่า เป็นบทความที่ว่าด้วยบทบาทของข้อมูลและ ความไม่สมมาตรของข้อมูล ในตลาด
สมมติฐานตลาดมีประสิทธิภาพล้มเหลว เพราะความรู้ที่สมบูรณ์เป็นไปไม่ได้ และ adverse selection มีอยู่จริง
มีบริษัทบางแห่งที่ตรงกันข้ามกับสิ่งที่บทความต้นฉบับบรรยายไว้โดยสิ้นเชิง ถ้าได้ทำงานในบริษัทแบบนั้นสักครั้งแล้ว ก็เป็นไปไม่ได้ที่จะกลับไปยอมอยู่กับที่แย่ ๆ อีก
ทั้งบทความคือทองคำเลย
ผู้จัดการถามว่าเขาประหยัดได้มากขนาดนั้นโดยไม่ต้องให้พวกเขาช่วยได้อย่างไร, ขอให้เตรียมสไลด์, ถามซ้ำหลายครั้งว่าเกิดอะไรขึ้น, และต้องค่อย ๆ ปล่อยออกไปให้ดูเหมือนเป็นการทำแบบค่อยเป็นค่อยไปตามเวลา ไม่ใช่สิ่งที่เกิดจาก toggle เล็ก ๆ อันเดียว แถมพอขอขึ้นเงินเดือนเทียบกับผลกระทบที่ทำได้ก็ไม่สำเร็จ
เพื่อประโยชน์ของเจ้าตัวเอง น่าจะลองสมัครที่อย่าง FAANG ดู อย่างน้อยก็มีโอกาสสูงกว่าจะได้รับการดูแลดีกว่านี้
แล้วถ้าใส่ Twitter card metadata ในบล็อก น่าจะทำให้แสดงบน Twitter ได้ดูดีกว่านี้
“สวัสดีครับ ผมจะอธิบายว่าเราประหยัดเงิน 500,000 ดอลลาร์ได้อย่างไร โดยพื้นฐานแล้ว ผมใช้เวลาหนึ่งวันดูว่า infrastructure เดิมถูก deploy มาเละเทะแค่ไหน แล้วลบฟีเจอร์ทดสอบในโค้ดที่ก่อปัญหาออกไป นี่เป็น oversight อย่างสมบูรณ์ในทุกด้าน ทั้ง development, management และ testing โดยรวมแล้วโค้ดนี้แทบจะแย่ที่สุดเท่าที่จะเป็นไปได้ แต่ก็ถูกปล่อยออกมาเฉย ๆ และผมถูกบอกว่าอย่าพูดแบบนี้ เพราะทุกคนจะดูแย่ และให้ค่อย ๆ rollout เพื่อให้ดูเหมือนว่าผู้จัดการได้ทำอะไรบางอย่าง”
จากนั้นคงวางไมค์แล้วเดินลงเวทีไป
พูดตรง ๆ ผมคงหมดใจจะสนใจงานไปอย่างมหาศาล ถึงจะทำงานสายนี้มาเกือบ 20 ปี และเป็นคนที่ต้องใส่ใจงานเพราะต้องจ่ายบิลและเลี้ยงลูกก็ตาม
ผมทำ spreadsheet โมเดลค่าใช้จ่าย จัดทำเอกสาร แล้วส่งให้หัวหน้า เขาบอกว่า “จะลองดูให้” ผ่านไป 2 สัปดาห์ผมถามว่าได้ดูหรือยัง เขาบอกว่า “ดูเหมือนจะถูกนะ ทำดีมาก” ผมถามว่าจะลองนำไปใช้ไหม คำตอบนี่สุดยอดมาก
“ไม่ เราไม่ได้รับเงินเดือนมาเพื่อประหยัดเงิน เราได้รับเงินเดือนมาเพื่อใช้เงิน”
ตอนนั้นเองที่ผมเข้าใจสัญญา Cost+Award Fee ของรัฐบาลอย่างแท้จริง
ข้อเสียคืออาจต้องเขียนเอกสารนั้นก่อนจะเปลี่ยนแปลงอะไร ต้องให้ทั้งทีมรีวิว และต้องทำให้ทุกคน “align” กันก่อน
ไม่ใช่ว่าบังเอิญประหยัดได้ 500,000 ดอลลาร์ แต่ตั้งใจประหยัด 500,000 ดอลลาร์ แล้วตอนนี้กำลังเสียใจ นั่นไม่ใช่เรื่องเดียวกัน
องค์กรขนาดใหญ่ ไร้ประสิทธิภาพมากจนชวนสงสัยว่าแข่งขันได้อย่างไร แต่พวกเขามีเงินเยอะ มี economies of scale และอะไรทำนองนั้น ระหว่างทาง ต่อให้เผาเงินหลายล้านดอลลาร์ไปกับความสิ้นเปลืองและความไร้ประสิทธิภาพโง่ ๆ ก็แทบไม่มีใครสนใจ
ถึงอย่างนั้นพวกเขาก็ยังให้บริการหรือผลิตภัณฑ์ที่มีคุณค่าอยู่ ไม่ว่าจะไร้ประสิทธิภาพแค่ไหน ก็ยังมีประสิทธิภาพกว่าการไม่มีอยู่เลย ดังนั้นต่อให้ไม่มีการแข่งขัน องค์กรแบบนี้ก็ยังคงมีอยู่
คุณอาจถามว่าแล้วการแข่งขันกับองค์กรเล็กล่ะ องค์กรเล็กมีประสิทธิภาพจากขนาดน้อยกว่า แต่ถ้ามีประสิทธิภาพในด้านอื่น บางครั้งก็แข่งขันกับบริษัทยักษ์ใหญ่ได้อย่างมีผล แต่พอเติบโตจนกลายเป็นองค์กรขนาดใหญ่ สุดท้ายก็จะมีความไร้ประสิทธิภาพแบบองค์กรขนาดใหญ่
มันก็เป็นแบบนี้แหละ ไม่ใช่ว่าไม่มีใครสนใจ ตรงกันข้าม เจ้าของบริษัทสนใจมาก ๆ ปัญหาคือพูดตรง ๆ ว่าไม่มีใครรู้วิธีแก้
บริษัทใหญ่มีแนวโน้มลงเอยด้วยรูปแบบความล้มเหลวคล้ายบริษัทที่รัฐเผด็จการควบคุมอยู่ และก็น่าสนใจว่าจีนเดินไต่เส้นระหว่างการควบคุมกับการเติบโตในเรื่องนี้ได้ดีแค่ไหน
พวกเขาบีบคอตลาดไปพร้อมกับที่ตัวเองไร้ประสิทธิภาพมากขึ้น
การแข่งขันเป็นนิทานที่เล่าให้ MBA ฟังเพื่อให้พวกเขาไปเริ่มธุรกิจใหม่ ๆ และทำให้ดูเหมือนมีการแข่งขันอยู่ ทั้งที่ตั้งแต่แรกพวกเขาไม่มีโอกาสเลย
ถ้าสามารถกำจัดความสูญเปล่าทั้งหมดด้วยการทำ optimization ได้ ผมคิดว่าเราคงได้เห็น deflation ด้วยซ้ำ ในขณะที่คอมพิวเตอร์และ business process มีประสิทธิภาพมากขึ้นเรื่อย ๆ
ครั้งหนึ่งเคยพบบั๊กตัวหนึ่งและกู้ รายได้ 4 ล้านดอลลาร์ต่อปี กลับมาได้
เรื่องนั้นถูกกลบไว้เพื่อปกป้องทีมและผู้บริหารที่ปล่อยให้ความผิดพลาดนั้นดำเนินอยู่นานขนาดนั้น ผมไม่ได้ขึ้นเงินเดือน แต่ก็ได้พันธมิตรบางคน และอยู่ได้สบาย ๆ ไปพักหนึ่ง
เซิร์ฟเวอร์สองเครื่องนั้นเกี่ยวข้องกับข้อมูล feed บางอย่าง และผมสังเกตว่าการต่อสายแปลกไปจากคำอธิบายฟังก์ชันที่ได้ยินมา
ค่าใช้จ่ายที่คาดว่าจะเกิดจาก downtime ของระบบนี้อยู่ที่ประมาณ 7 ล้านดอลลาร์ต่อนาที ผมยกประเด็นนี้กับพนักงานที่รับผิดชอบหลายคนและทีมเครือข่าย แต่ถูกเมินสนิท ด้วยเหตุผลว่า “เราไม่มีทางต่อสายแบบนั้นหรอก” และเพราะผมเป็นเด็กใหม่
เพราะมันดูสำคัญ ผมจึงยกเรื่องนี้ขึ้นอีกครั้งในการประชุมกลุ่มประจำสัปดาห์ แล้วมีคนไปตรวจสอบด้วยตัวเองและกลับมาบอกว่าเป็นอย่างที่ผมพูดจริง ๆ เรื่องนี้เป็นเรื่องใหญ่ และทีมเครือข่ายต้องทำงานฉุกเฉินอยู่ราว 2 สัปดาห์เพื่อแก้ปัญหาให้เรียบร้อย
ทุกคนโกรธผม ทั้งที่ผมป้องกันหายนะของบริษัทไว้ได้ แต่การที่ผมทำแบบนั้นทำให้ทุกคนดูแย่ โดยเฉพาะเพราะผมมีสถานะต่ำในทีม นั่นเป็นบทเรียนสำคัญ
ระบบที่สร้างขึ้นเพื่อแก้บั๊กนั้น โดยแท้จริงแล้วคือ การโจมตีแบบ man-in-the-middle ต่อการส่งใบสั่งยาของร้านขายยา เพราะร้านขายยาไม่เคยนำการอัปเดตราคาไปใช้เลย จึงทำการคำนวณราคาใหม่ก่อนที่ใบสั่งยาจะถูกส่งเข้าไปยังระบบของบริษัทประกัน ผมทำงานให้เชนร้านขายยาอิสระขนาดเล็ก และไม่มีระบบจ่ายยากลาง
ด้วยความอัจฉริยะไร้ขอบเขตในตอนนั้น ผมตั้งชื่อระบบตามชื่อคนที่แอบชอบ สำนักงานใหญ่ชอบมากจนสร้างรางวัลประจำปีที่ตั้งชื่อตามระบบของผม และผลก็คือมันกลายเป็นรางวัลที่ตั้งชื่อตามคนที่ผมแอบชอบ แต่ผมอายเกินกว่าจะบอกที่มาจริง ๆ
แม้จะเป็นเรื่องเมื่อ 25 ปีก่อน จนถึงตอนนี้ก็ยังมีการทำและมอบถ้วยรางวัลที่มีชื่อของคนที่เคยแอบชอบคนนั้นอยู่ทุกปี ถ้าคนนั้นรู้คงตกใจสุด ๆ
เรื่องแบบนี้มีมาตลอด
สมัยก่อน ผมเข้าไปในห้องที่เต็มไปด้วยเทอร์มินัล VT100 ช่วงสุดสัปดาห์ปลายเทอม มีนักศึกษา CS ที่เบื่อ ๆ กำลังรอให้ compile เสร็จอยู่ ผมดูระบบแล้วพบว่าทุกคนเอางาน compile ใส่ batch queue ไว้ แต่ priority เริ่มต้นของคิวนั้นต่ำกว่างานแบบ interactive ดังนั้นการกดคีย์หนึ่งครั้งจากที่ไหนก็ตามจะได้ priority สูงกว่า และยิ่งผู้คนเช็กตำแหน่งงาน compile ของตัวเอง ก็ยิ่งทำให้มันช้าลง
ใน 15 นาทีถัดมา ผมคอยเพิ่ม priority ของงานที่อยู่หัวคิวเรื่อย ๆ และอีกหนึ่งชั่วโมงต่อมาทุกคนก็ทำงานเสร็จแล้วกลับบ้าน ห้องนั้นจึงตกเป็นของผม เป็นชัยชนะของ ผู้ดูแลระบบเถื่อน ;-)
เมื่อไม่กี่เดือนก่อน ผมพบ S3 bucket ที่โตขึ้นเรื่อย ๆ และกินเงินเดือนละ 80,000 ดอลลาร์ ทำให้บริษัทประหยัดเงินได้ปีละ 1 ล้านดอลลาร์
พอตรวจดู พบว่าระบบที่ไม่ได้ใช้งานแล้วกำลังคัดลอกไฟล์ไปยัง bucket นั้น ผมติดต่อผู้มีส่วนได้ส่วนเสีย แล้วพวกเขาก็ปิดมันและลบไฟล์
ดูเหมือนผู้บริหารระดับบนจะไม่ค่อยสนใจ หัวหน้าของหัวหน้าผมบอกให้ลองติดต่อทีมอื่นที่ควรจะจับเรื่องนี้ได้ตั้งแต่แรก แล้วก็จบแค่นั้น
“ตัวอย่างเช่น มีการรัน INSERT ไปยัง [table name deleted]_HOURLY 234,745 ครั้ง และทั้งหมดมีน้อยกว่า 1000 แถว”
นี่เป็นข้อความที่โพสต์จริงใน Slack สนับสนุน Snowflake ขององค์กรเรา และเป็นปัญหาแทบจะเหมือนกันเลย คือ transaction เล็ก ๆ ที่กระจายไปตามช่วงเวลา คอยปลุก cluster ให้ทำงานอยู่เรื่อย ๆ ผลิตภัณฑ์นี้ไม่ได้ถูกออกแบบมาให้เหมาะกับ use case ทั่วไปอย่าง การโหลดข้อมูลปริมาณน้อยอย่างต่อเนื่อง
ผมเป็นผู้ดูแล data warehouse ที่มีประสบการณ์จริง จึงได้เห็นผู้คนค่อย ๆ ค้นพบคำบรรยายงานของผมใหม่ทีละข้อเมื่อเจอค่าใช้จ่ายเกินงบ พวกเขาพูดอย่างจริงจังทำนองว่า “มันเป็นแบบ self-managed แต่เราต้อง monitor ค่าใช้จ่าย และเขียนการโหลดกับ query ใหม่ให้มีประสิทธิภาพขึ้น” ผมกลัวที่จะถามว่าพวกเขาคิดว่าผมทำอะไรทั้งวัน
นานมาแล้วในกาแล็กซีอันไกลโพ้น ผมแทนที่งานที่ต้องใช้ N × (ไลเซนส์ Oracle + เซิร์ฟเวอร์ Sun) ด้วย สคริปต์ Perl น้อยกว่า 100 บรรทัด และเซิร์ฟเวอร์ Sun หนึ่งเครื่อง ประหยัดได้มากกว่า 300 ล้านดอลลาร์ต่อปี
ระหว่างนั้นยังประดิษฐ์ MapReduce ขึ้นมาด้วย ก่อน Google เสียอีก
ปัญหาคือการคำนวณสถิติต่าง ๆ จาก log ของเว็บเซิร์ฟเวอร์ เช่น 10 หน้ายอดนิยม วิธีแก้เดิมคือเพราะ log ใหญ่มาก จึงโหลดทั้งหมดเข้าไปในฐานข้อมูล Oracle ที่รันบนหลายเซิร์ฟเวอร์ แล้วรัน SQL query หลายชุด ทำซ้ำทุกวัน
แกลเลอรีคอมเมนต์ HN ที่น่าประทับใจซึ่งพูดถึงงานเขียนของผู้เขียนนั้นยอดเยี่ยมมาก: https://ludic.mataroa.blog/compliments/
เป็นไปได้มากเช่นกันว่าคนจำนวนมากในองค์กรนำหน้าผู้เขียนไปไกลแล้ว เป็นไปได้มากกว่าด้วยซ้ำว่า engineer หรือ manager ในกลุ่มเดียวกันกำลัง กักตุน ความไร้ประสิทธิภาพนั้นไว้ใช้ในช่วงลดค่าใช้จ่าย และผู้เขียนทำให้โอกาสนั้นพังลง แบบนั้นเมื่อไม่มีอะไรให้ตัดแล้ว ความเจ็บปวดอย่างหนักและผลประเมินงานที่แย่ก็อาจเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้
อาจเป็นเพราะระดับวาทกรรมของ HN ตกต่ำลง จนตอนนี้แทบทุกคอมเมนต์กลายเป็นเป้าหมายได้แล้ว เลยพักการใช้งานไป
[1] https://twitter.com/shit_hn_says