พื้นฐาน AI
FinOps 101: คู่มือเบื้องต้นสำหรับการดำเนินงานด้านการเงินบนคลาวด์
เพิ่ม Unite.AI ลงในแหล่งข้อมูลที่คุณต้องการบน Google
FinOps คือกรอบการทำงานเชิงปฏิบัติและแนวปฏิบัติวัฒนธรรมที่มุ่งเพิ่มมูลค่าทางธุรกิจของเทคโนโลยีผ่านการทำงานร่วมกันระหว่างวิศวกรรม การเงิน ผลิตภัณฑ์ การจัดซื้อและผู้บริหาร มันเชื่อมโยงการใช้งานทางเทคนิคกับค่าใช้จ่าย มูลค่า และการตัดสินใจที่ทันเวลา
FinOps ไม่ได้เป็นเพียงทีมที่ตัดค่าใช้จ่าย การใช้จ่ายเพิ่มขึ้นอาจถูกต้องเมื่อทำให้บริการที่มีคุณค่าดีขึ้น; การใช้จ่ายลดลงอาจเป็นอันตรายเมื่อทำให้ความน่าเชื่อถือลดลงหรือการเติบโตช้าลง เป้าหมายคือการทำการแลกเปลี่ยนที่รับผิดชอบโดยใช้ข้อมูลที่แชร์ร่วมกัน
ประเด็นสำคัญ
- จัดสรรการใช้งานเทคโนโลยีและค่าใช้จ่ายให้กับขอบเขตที่รับผิดชอบ เช่น ผลิตภัณฑ์ ทีม หรือสภาพแวดล้อม
- ใช้เศรษฐศาสตร์หน่วย—ค่าใช้จ่ายต่อธุรกรรม ลูกค้า หรือการสรุปโมเดล—to เชื่อมการใช้จ่ายกับคุณค่า
- แยกการปรับแต่งการใช้งานออกจากการปรับอัตราค่าใช้จ่ายและรวมข้อจำกัดด้านความน่าเชื่อถือ ความปลอดภัย และความยั่งยืน
- Inform, Optimize และ Operate สร้างวงจรต่อเนื่องแทนที่จะเป็นโครงการประหยัดครั้งเดียว
สร้างขอบเขตและข้อมูลค่าใช้จ่ายที่แชร์ร่วม
ขอบเขตคือส่วนย่อยที่กำหนดของการใช้จ่ายเทคโนโลยีที่สอดคล้องกับโครงสร้างธุรกิจ แท็ก บัญชี โครงการ และการส่งออกข้อมูลการเรียกเก็บเงินช่วยจัดสรรค่าใช้จ่ายโดยตรง ในขณะที่แพลตฟอร์มที่แชร์ต้องการกฎการจัดสรรที่มีเอกสารบันทึก
ข้อมูลควรเป็นข้อมูลที่ทันเวลา มีความแม่นยำพอสำหรับการตัดสินใจและสามารถเปรียบเทียบกับใบแจ้งหนี้ได้ ค่าใช้จ่ายที่ไม่ได้จัดสรรและค่าใช้จ่ายที่แชร์ควรยังคงมองเห็นได้แทนที่จะบังคับให้มีความแม่นยำเทียม เชื่อมการเปลี่ยนแปลงค่าใช้จ่ายกับการปรับใช้ การรับทราฟฟิก และการตัดสินใจด้านสถาปัตยกรรม
ให้ข้อมูลด้วยการคาดการณ์และเศรษฐศาสตร์หน่วย
แดชบอร์ดอธิบายว่าการใช้งานและค่าใช้จ่ายเกิดขึ้นที่ไหน; การคาดการณ์ประเมินความต้องการในอนาคต; งบประมาณแสดงแผนที่ได้ตกลงกัน การจัดการความผิดปกติตรวจจับการเปลี่ยนแปลงที่ไม่คาดคิดอย่างรวดเร็ว แต่ความผิดปกติอาจเป็นการเติบโตที่ถูกต้องแทนที่จะเป็นการเสียเปล่า
เมตริกหน่วยแบ่งค่าใช้จ่ายตามผลลัพธ์ที่เกี่ยวข้องกับคุณค่า สำหรับ AI ตัวอย่างได้แก่ค่าใช้จ่ายต่อภารกิจที่สำเร็จหรือพันการสรุปที่ตรวจสอบแล้ว ให้จับคู่เมตริกทางการเงินกับคุณภาพและความหน่วงเวลาเพื่อให้ทีมไม่ปรับให้เกิดความล้มเหลวที่ราคาถูก
ปรับแต่งการใช้งานและอัตรา
การปรับแต่งการใช้งานกำจัดทรัพยากรที่ไม่ได้ใช้ ปรับขนาดงานให้เหมาะสม กำหนดเวลางานที่ยืดหยุ่น และเปลี่ยนสถาปัตยกรรม การปรับอัตราใช้การสัญญา การจอง การต่อรองราคาและกลยุทธ์การให้สิทธิ์เพื่อจ่ายน้อยลงสำหรับการใช้งานที่จำเป็น
การสัญญาจะสร้างความเสี่ยงต่อการคาดการณ์และการปรับขนาดอย่างก้าวร้าวอาจลดห่วงโซ่สำรอง ประเมินความน่าเชื่อถือ ความปลอดภัย ความพยายามของวิศวกรรมและผลกระทบต่อคาร์บอนของการวางตำแหน่ง การวัดจาก งาน AI carbon-footprint สามารถเสริมข้อมูลค่าใช้จ่ายได้
ดำเนินการผ่านนโยบายและระบบอัตโนมัติ
นโยบายกำหนดความเป็นเจ้าของ บริการที่อนุมัติ การเก็บรักษาข้อมูล อำนาจการสัญญาและระดับการเพิ่มระดับการแจ้งเตือน ระบบอัตโนมัติสามารถบังคับใช้แท็ก หยุดสภาพแวดล้อมที่ละทิ้งหรือแจ้งผู้ถือครองได้ แต่การกระทำที่ทำลายต้องมีการป้องกันและข้อยกเว้น
บูรณาการ FinOps กับ DevOps เพื่อให้วิศวกรเห็นค่าใช้จ่ายระหว่างการออกแบบและการส่งมอบ ไม่ใช่เฉพาะหลังจากใบแจ้งหนี้ ตรวจสอบผลลัพธ์ ปรับปรุงการคาดการณ์และนำบทเรียนเข้าสู่ขั้นตอน Inform ถัดไป
ประยุกต์ FinOps นอกเหนือจากคลาวด์สาธารณะ
กรอบงานปัจจุบันของ FinOps Foundation ครอบคลุมขอบเขตเทคโนโลยีที่กว้างขึ้นรวมถึง SaaS การให้สิทธิ์ ศูนย์ข้อมูลและ AI หลักการเดียวกัน—ข้อมูลที่แชร์ การตัดสินใจที่รับผิดชอบและการวัดคุณค่า—ยังคงใช้ได้ แม้ว่ากลไกการเรียกเก็บและการจัดสรรอาจแตกต่างกัน
เริ่มต้นด้วยปัญหาที่มีคุณค่าสูงและจำนวนความสามารถที่จำกัด การปฏิบัติที่เจริญเติบโตไม่ใช่การมีแดชบอร์ดมากที่สุด แต่คือการทำการแลกเปลี่ยนที่เร็วขึ้น ดีกว่าและตรวจสอบผลลัพธ์ได้
หลักการ FinOps และโมเดลค่าใช้จ่ายคลาวด์
FinOps คือแนวปฏิบัติข้ามหน้าที่ที่ช่วยให้ทีมวิศวกรรม การเงิน การจัดซื้อ และผลิตภัณฑ์ทำการตัดสินใจที่ทันเวลาเกี่ยวกับมูลค่าและค่าใช้จ่ายของคลาวด์ที่เปลี่ยนแปลงได้ ไม่ใช่โครงการตัดค่าใช้จ่ายครั้งเดียว ใบเรียกเก็บคลาวด์ประกอบด้วยการใช้งาน อัตรา การสัญญา ภูมิภาค ชั้น ราคา การถ่ายโอนข้อมูล การสนับสนุน สิทธิ์และภาษี การจัดสรรแมปค่าธรรมเนียมเหล่านั้นไปยังผลิตภัณฑ์ ทีม สภาพแวดล้อม หรือ ลูกค้าผ่านบัญชี การสมัครสมาชิก โครงการ แท็ก ป้ายกำกับ และกฎค่าใช้จ่ายที่แชร์
วงจร FinOps มักอธิบายเป็น inform, optimize, และ operate. Inform สร้างการจัดสรรที่เชื่อถือได้, เศรษฐศาสตร์หน่วย, งบประมาณและการคาดการณ์. Optimize กำจัดของเสีย ปรับขนาด กำหนดเวลาการทำงานที่ไม่ใช่การผลิต ปรับปรุงสถาปัตยกรรม และจัดการสัญญา. Operate ฝังข้อเสนอแนะค่าใช้จ่ายเข้าสู่การวางแผนและวิศวกรรม การกำกับดูแลศูนย์กลางจัดมาตรฐานและเครื่องมือ ในขณะที่ทีมผลิตภัณฑ์เป็นผู้ตัดสินใจแลกเปลี่ยนระหว่างความน่าเชื่อถือ ความปลอดภัย ประสิทธิภาพ และแผนงาน การเงินตรวจสอบบัญชีและการคาดการณ์; การจัดซื้อจัดการเงื่อนไขเชิงพาณิชย์
เมตริก, สัญญา, และการปรับแต่ง
การใช้จ่ายทั้งหมดไม่เพียงพอ เมตริกหน่วย—ค่าใช้จ่ายต่อธุรกรรม ลูกค้า การสรุปโมเดล การสร้าง หรือบันทึกที่จัดเก็บ—เชื่อมการบริโภคกับคุณค่าและเผยว่าการเติบโตมีประสิทธิภาพหรือไม่ ติดตามค่าใช้จ่ายสัญญาที่หักค่าเสื่อม ประหยัดที่เกิดขึ้น ของเสีย ความผิดพลาดของการคาดการณ์ การครอบคลุมการจัดสรร และการตอบสนองต่อความผิดปกติ หลีกเลี่ยงเป้าหมายที่กระตุ้นให้ทีมย้ายค่าใช้จ่าย ลดความน่าเชื่อถือ หรือลบการสังเกตที่มีประโยชน์ การประมาณค่าใช้จ่ายต้องระบุสกุลเงิน ช่วงเวลา และกฎการรวม
ความจุสำรองและสัญญาการออมลดอัตราในแลกกับระยะเวลาและความเสี่ยงการใช้งาน โมเดลความต้องการพื้นฐาน การเติบโต ฤดูกาล และการย้ายบริการก่อนการซื้อ การปรับขนาดควรใช้ CPU, หน่วยความจำ, I/O, ความหน่วงเวลา และการสำรองที่ต่อเนื่อง ไม่ใช่เฉพาะค่าเฉลี่ย CPU เท่านั้น ความจุ Spot เหมาะกับงานที่สามารถหยุดชั่วคราวพร้อมเช็คพอยท์และลองใหม่ วัฏจักรการจัดเก็บและการถ่ายโอนข้อมูลมักต้องการการเปลี่ยนแปลงสถาปัตยกรรม การปรับแต่งแต่ละครั้งควรผ่านการทดสอบด้านประสิทธิภาพ การกู้คืนและความปลอดภัย
การกำกับดูแลและงานโหลดคลาวด์–AI
งบประมาณและการแจ้งเตือนความผิดปกติต้องมีผู้รับผิดชอบและเกณฑ์ที่ทำได้ Showback ให้ข้อมูลแก่ทีม; chargeback กำหนดความรับผิดชอบทางการเงินแต่ต้องการการจัดสรรที่เสถียร ทำให้นโยบายอัตโนมัติพร้อมข้อยกเว้นและวันหมดอายุ และตรวจสอบทรัพยากรที่ไม่ได้ใช้ สัญญาที่หลงเหลือ และเครื่องมือที่ซ้ำซ้อน AI นำมาซึ่งความขาดแคลนตัวเร่งความเร็ว การใช้ token ที่แปรผัน การเคลื่อนย้ายข้อมูลขนาดใหญ่ และการทดลองที่มีคุณค่าที่ไม่แน่นอน วัดค่าใช้จ่ายต่อภารกิจที่สำเร็จคุณภาพ‑qualified และรวมการรันที่ล้มเหลวและการตรวจสอบ FinOps ประสบความสำเร็จเมื่อค่าใช้จ่ายกลายเป็นสัญญาณการออกแบบโดยไม่ลดทอนความปลอดภัยหรือคุณค่าของลูกค้าสำหรับบริการ
ตัวอย่างทำงาน: ลดค่าใช้จ่ายหน่วยของบริการ AI
ทีมกำหนดหน่วยเป็นค่าใช้จ่ายต่อเคสสนับสนุนที่แก้ไขสำเร็จตามคุณภาพที่ต้องการ การเรียกเก็บ, token, โมเดล, แคช, การเรียกคืน, การตรวจสอบและข้อมูลโครงสร้างพื้นฐานทั้งหมดจะถูกจัดสรรให้กับบริการ การวิเคราะห์แสดงว่าคำสั่งยาว, บริบทเอกสารที่ทำซ้ำ, การลองใหม่, และโมเดลขนาดใหญ่ในการจำแนกง่ายทำให้ค่าใช้จ่ายสูง ตัวเราตัวจัดเส้นทางที่เล็กลง, แคชที่รับรู้สิทธิ์, บริบทที่จำกัด, และการฝังแบบแบทช์ลดค่าใช้จ่ายโดยยังคงชุดการประเมินส่วนตัวที่ไม่เปลี่ยนแปลง
การเปิดตัวเปรียบเทียบคุณภาพ การปฏิเสธ ความหน่วงเวลา การเพิ่มระดับ และผลลัพธ์ของลูกค้าพร้อมกับค่าใช้จ่าย งบประมาณและการแจ้งเตือนความผิดปกติมีเจ้าของบริการ; สัญญาจะถูกซื้อเฉพาะสำหรับภาระงานพื้นฐานที่เสถียร การจัดสรรค่าใช้จ่ายและเวอร์ชันโมเดลปรากฏบนแดชบอร์ด และความปลอดภัยหรือการสังเกตไม่ได้ถูกปิดเพื่อให้ได้เป้าหมาย ทีมรายงานการออมต่อเคสที่แก้ไขแทนการลดราคาต่อ token เพราะโมเดลราคาถูกที่ทำให้ต้องลองใหม่และตรวจสอบอาจทำให้ค่าใช้จ่ายและภาระของผู้ใช้เพิ่มขึ้น
หลักฐานการดำเนินการและความพร้อมใช้งาน
การตัดสินใจเชิงผลิตต้องมากกว่าการสาธิตที่ประสบความสำเร็จ กำหนดผู้ใช้เป้าหมาย สภาพแวดล้อมการทำงาน อินพุต เอาต์พุต การพึ่งพา เจ้าของ และผลของความล้มเหลวที่สำคัญแต่ละประการ สร้างฐานบรรทัดฐานที่ทำซ้ำได้และชุดการประเมินที่มีเวอร์ชันก่อนการปรับแต่ง ทดสอบกรณีปกติ เงื่อนไขขอบเขต อินพุตที่ผิดรูปหรือขาดหาย การเปลี่ยนแปลงการกระจาย การขัดข้องของการพึ่งพา การใช้ผิดวิธี และกลุ่มหรือสภาพแวดล้อมที่อาจไม่ได้รับการสนับสนุนอย่างเพียงพอ วัดคุณภาพงานพร้อมการสอบเทียบหรือความไม่แน่นอน ความหน่วงเวลา ปริมาณการทำงาน ค่าใช้จ่ายทรัพยากร การเข้าถึง ความเป็นส่วนตัว และความปลอดภัย บันทึกการแปลงและเกณฑ์ทั้งหมดเพื่อให้ผู้ตรวจสอบอิสระสามารถทำซ้ำผลลัพธ์และแยกแยะหลักฐานจากต้นแบบที่ดึงดูดใจ
ก่อนการเปิดตัว กำหนดอำนาจสำหรับการปล่อย, ข้อยกเว้น, การเปลี่ยนแปลง, การย้อนกลับ, และการยกเลิก ใช้การเปิดตัวแบบขั้นตอน, เก็บสำรองที่ปลอดภัย, และตรวจสอบการเฝ้าระวังด้วยความล้มเหลวที่ใส่เจตนา Telemetry การดำเนินงานควรเผยอินพุตคุณภาพ พฤติกรรมเอาต์พุต เวอร์ชันโมเดลหรือกฎ, สถานะการพึ่งพา, การแทรกแซงของมนุษย์, และผลลัพธ์ที่ยืนยันโดยไม่เก็บข้อมูลที่ละเอียดอ่อนไม่จำเป็น กำหนดเกณฑ์การแจ้งเตือนและผู้รับผิดชอบการตอบสนอง จากนั้นตรวจสอบหลักฐานในโลกจริงหลังการปรับใช้แทนที่จะสมมติว่าประสิทธิภาพออฟไลน์จะคงอยู่ ทบทวนใหม่เมื่อแหล่งข้อมูล ผู้ใช้ โมเดล ผู้จำหน่าย นโยบาย ฮาร์ดแวร์ หรือเป้าหมายเปลี่ยน แบบระบบที่รักษาไว้ยังต้องมีเอกสารการกู้คืน การเรียนรู้จากเหตุการณ์ การลบและการเก็บรักษา และจุดชัดเจนที่ควรปิดหรือเปลี่ยนแทน
คำถามที่พบบ่อย
ใครเป็นเจ้าของค่าใช้จ่ายคลาวด์ใน FinOps?
ความเป็นเจ้าของเป็นการแชร์ วิศวกรรมมีอิทธิพลต่อสถาปัตยกรรมและการใช้, การเงินจัดทำแผนและการกระทบยอด, ส่วนผลิตภัณฑ์และผู้บริหารเชื่อมการใช้จ่ายกับคุณค่า
FinOps มีไว้เฉพาะบริษัทขนาดใหญ่หรือไม่?
ไม่. ทีมขนาดเล็กสามารถเริ่มต้นด้วยความเป็นเจ้าของที่ชัดเจน งบประมาณ การแจ้งเตือนความผิดปกติและจังหวะการทบทวนเป็นประจำ ก่อนที่จะนำเครื่องมือพิเศษมาใช้
แหล่งอ้างอิงหลัก
