เส้นทางการจัดการค่าใช้จ่าย AWS ของทีมพัฒนา AB180: ตั้งแต่ตรวจบิลไปจนถึงวัฒนธรรม FinOps

สรุปโดย Gemini

--

AB180 ดำเนินงานโซลูชันวัดผลประสิทธิภาพการตลาดอย่าง 'Airbridge' ที่ต้องประมวลผลข้อมูลจำนวนมหาศาล และได้สร้างวัฒนธรรมการจัดการค่าใช้จ่าย AWS (FinOps) อย่างเป็นระบบขึ้นมา เราขอแบ่งปันประสบการณ์และองค์ความรู้ที่ได้รับระหว่างทางนั้น

แนวทางการดำเนินงานด้านการจัดการค่าใช้จ่ายของ AB180:
เราใช้กระบวนการต่อไปนี้เพื่อ 'บริหาร' ค่าใช้จ่าย

• แดชบอร์ดบน Google Sheets: เราสร้างแดชบอร์ดโดยใช้ Google Sheets ซึ่งช่วยให้จัดการและแชร์ข้อมูลได้ง่าย นอกจากจะแสดงสถานะค่าใช้จ่ายตามแท็กแล้ว ยังแสดงปริมาณการเก็บข้อมูลที่ส่งผลโดยตรงต่อต้นทุนควบคู่กันไป เพื่อให้เข้าใจสาเหตุของความผันผวนได้อย่างเป็นธรรมชาติ อีกทั้งยังแสดงภาพรวมสถานะความครอบคลุมของ Savings Plan และจำลองผลลัพธ์ล่วงหน้าเมื่อมีการเปลี่ยนแปลงสัญญา เพื่อช่วยให้ตัดสินใจได้อย่างสมเหตุสมผล
• การตรวจสอบค่าใช้จ่ายแบบสม่ำเสมอและอัตโนมัติ: ทุก ๆ 2 สัปดาห์ เราจะมีการประชุมสั้น ๆ ประมาณ 30 นาทีเพื่อตรวจสอบความเปลี่ยนแปลงของค่าใช้จ่าย งานที่ทำซ้ำเป็นประจำ เช่น การสร้างเอกสารประชุม การแจ้งเตือนใน Slack และการเขียนบันทึกการประชุม ถูกทำให้เป็นอัตโนมัติให้มากที่สุดเพื่อเพิ่มประสิทธิภาพ หากความเปลี่ยนแปลงของค่าใช้จ่ายมีมาก ผู้รับผิดชอบจะวิเคราะห์สาเหตุและแชร์ผ่านคอมเมนต์ใน Google Sheets เพื่อให้เกิดความโปร่งใส
• การประเมินค่าใช้จ่ายล่วงหน้าก่อนพัฒนา: เมื่อมีการพัฒนาฟีเจอร์ใหม่หรือเปลี่ยนแปลงสถาปัตยกรรม เรากำหนดให้ต้องระบุค่าใช้จ่ายที่คาดการณ์ไว้ในเอกสาร 'Tech Spec' วิธีนี้ช่วยให้สามารถตัดสินใจทางเทคนิคที่ดีกว่าโดยคำนึงถึงต้นทุนตั้งแต่ขั้นตอนการพัฒนา

กระบวนการยกระดับระบบการจัดการค่าใช้จ่าย:
ระบบในปัจจุบันไม่ได้เกิดขึ้นในชั่วข้ามคืน แต่พัฒนาผ่านขั้นตอนต่อไปนี้

• Phase 0 (ตรวจบิล): ในช่วงแรก เราทำได้เพียงตรวจสอบบิลในแต่ละเดือน
• Phase 1 (การจัดหมวดหมู่ขั้นต่ำ): เราเริ่มจัดหมวดหมู่รีซอร์สในระดับขั้นต่ำโดยใช้แท็ก Name
• Phase 2 (ยกระดับกลยุทธ์แท็ก): เรากำหนดกลยุทธ์แท็กบนพื้นฐานของนโยบายที่ชัดเจน เช่น Team, Service การเผยแพร่คู่มือเพียงอย่างเดียวไม่เพียงพอ จึงเชื่อมโยงกับนโยบาย IAM เพื่อบังคับการตั้งค่าแท็ก และสร้างกลไกที่ส่งการแจ้งเตือนอัตโนมัติผ่าน Slack bot สำหรับรีซอร์สที่ไม่มีแท็ก ผลลัพธ์คือเราสามารถควบคุมค่าใช้จ่ายของรีซอร์สที่ไม่มีแท็กให้ต่ำกว่า 1% ของทั้งหมดได้

5 บทเรียนที่ได้รับจากเส้นทางที่ผ่านมา:

• วิศวกรรมที่เหมาะกับบริบทเป็นสิ่งสำคัญ แทนที่จะมุ่งหาระบบที่สมบูรณ์แบบสำหรับควบคุมต้นทุน การค่อย ๆ สร้างระบบบริหารจัดการในระดับที่ 'เหมาะสม' กับขนาดและสถานการณ์ของบริษัทจะเป็นทางเลือกที่ชาญฉลาดกว่า
• การ 'ควบคุม' ต้นทุนกับการ 'ปรับให้เหมาะสม' เป็นคนละเรื่องกัน 'การควบคุม' คือการทำให้ต้นทุนคาดการณ์ได้มากขึ้น ส่วน 'การปรับให้เหมาะสม' คือการลดต้นทุนลงโดยตรง ต้องตัดสินใจว่าจะโฟกัสกับอะไรตามลำดับความสำคัญของสถานการณ์
• ควรทำระบบอัตโนมัติอย่างจริงจัง ไม่ใช่แค่ทำงานซ้ำ ๆ ให้อัตโนมัติ แต่ควรสร้างสภาพแวดล้อมแบบ 'Self-serve' ที่เพื่อนร่วมงานสามารถค้นดูข้อมูลและระบุปัญหาได้ด้วยตนเอง เพื่อยกระดับประสิทธิภาพการทำงานให้สูงสุด
• ต้องสร้าง 'กลไก' แทนที่จะพูดว่า "มาติดแท็กกันให้ดี" การออกแบบ 'อุปกรณ์/กลไก' ที่ทำให้หลีกเลี่ยงการปฏิบัติตามนโยบายไม่ได้ เช่น หากไม่มีแท็กก็จะไม่ได้รับสิทธิ์เข้าถึงรีซอร์ส จะมีประสิทธิภาพมากกว่า
• FinOps ในท้ายที่สุดคือ 'วัฒนธรรม' สิ่งสำคัญที่สุดคือการพยายามอย่างต่อเนื่องเพื่อให้เกิดการรับรู้ว่าการจัดการต้นทุนไม่ใช่งานของผู้รับผิดชอบเฉพาะคน แต่เป็นความรับผิดชอบร่วมกันของทุกคนที่สร้างผลิตภัณฑ์ และค่อย ๆ สร้างวัฒนธรรมนั้นขึ้นมา

[tujuc]

โอ้โห.. ถ้าแค่ติด Tag พื้นฐานที่สุดเอาไว้ก่อน ก็น่าจะช่วยได้ระดับหนึ่งเลยนะครับ.. :)

แต่การลดค่าใช้จ่ายด้วยการใช้พวก RI หรือ SP แบบนี้ ถือเป็นพื้นฐานที่ต้องทำอยู่แล้วหรือเปล่าครับ....
แล้วขนาดไหนถึงจะเป็นไซซ์ที่เหมาะกับการใช้งานในอินฟราของเรา ก็เป็นจุดที่ต้องคิดหนักพอสมควรเหมือนกันนะครับ...

[dongho42]

แม้จะมีการพูดถึงเรื่องนี้ในบทความอยู่แล้ว แต่ผมได้ทำ SP simulator แยกขึ้นมาเอง เพื่อคำนวณจาก workload ในช่วง n วันล่าสุดว่าควรซื้อ SP เพิ่มอีกเท่าไร จึงจะทำให้ "ต้นทุนเดิม + ต้นทุนที่ลดลงจากการได้รับ Covered + ต้นทุนที่สูญเปล่าจากการเกิด Recurring" น้อยที่สุด แล้วใช้ผลนั้นในการตัดสินใจครับ

[slave4salary]

ฉันเป็นพนักงานปัจจุบันของ AWS kor

หนึ่งในการอบรมสำคัญที่สุดที่ได้ยินหลังเข้าทำงานคือให้คิดหาวิธีที่ช่วยให้ลูกค้าใช้จ่ายค่าใช้จ่ายคลาวด์ให้น้อยลง โดยหนึ่งในวิธีที่มีประสิทธิภาพมากที่สุดคือการแนะนำ RI & SP

[cocofather]

ช่วยลดค่าบริการให้หน่อย..

[toughrogrammer]

แม้จะไม่รู้เรื่อง RI แต่ในกรณีของ SP นั้นสามารถนำไปใช้กับหลายเวิร์กโหลดได้ ดังนั้นถ้ามีค่าใช้จ่ายคงที่ที่ต้องจ่ายอยู่ ก็ถือว่าน่าลองพิจารณาอย่างมากครับ ถึงขั้นที่พวกเรายังเคยซื้อโดยคำนึงถึงช่วงเวลาที่คาดว่าจะทำ optimization เสร็จไว้ล่วงหน้าด้วย... 555 เช่น ถ้าคิดว่าอีก 9 เดือนจะ optimize เสร็จจนค่าเซิร์ฟเวอร์ลดลงครึ่งหนึ่ง แต่ถึงอย่างนั้นการซื้อไว้ 1 ปีล่วงหน้าก็ยังคุ้มกว่า ก็จะซื้อกันในลักษณะนั้นครับ