คุณคงสงสัยอย่างแน่นอนว่าโครงสร้างพื้นฐานของโครงการของคุณมีค่าใช้จ่ายเท่าไร ในเวลาเดียวกัน เป็นเรื่องที่น่าประหลาดใจ: การเติบโตของต้นทุนไม่เป็นเชิงเส้นเมื่อเทียบกับปริมาณงาน เจ้าของธุรกิจ สถานีบริการ และผู้พัฒนาหลายรายแอบเข้าใจว่าตนจ่ายเงินมากเกินไป แต่เพื่ออะไรกันแน่?
โดยทั่วไปแล้ว การลดต้นทุนมักมาจากการค้นหาโซลูชันที่ถูกที่สุด แผน AWS หรือการปรับการกำหนดค่าฮาร์ดแวร์ให้เหมาะสมในกรณีของชั้นวางจริง ไม่เพียงเท่านั้น จริงๆ แล้วใครๆ ก็ทำเช่นนี้ตามที่พระเจ้าพอพระทัย หากเรากำลังพูดถึงสตาร์ทอัพ นี่อาจเป็นนักพัฒนาชั้นนำที่ปวดหัวมากมาย ในสำนักงานขนาดใหญ่ สิ่งนี้จะได้รับการจัดการโดย CMO/CTO และบางครั้งผู้อำนวยการทั่วไปก็มีส่วนเกี่ยวข้องในเรื่องนี้เป็นการส่วนตัวร่วมกับหัวหน้าฝ่ายบัญชี โดยทั่วไปแล้ว ผู้ที่มีความกังวลเรื่อง “แก่นแท้” มากพอ และปรากฎว่าค่าโครงสร้างพื้นฐานกำลังเพิ่มขึ้น แต่ผู้ที่ไม่มีเวลาจัดการกับมันกำลังเผชิญกับมัน
หากคุณต้องการซื้อกระดาษชำระสำหรับใช้ในสำนักงาน ผู้จัดการฝ่ายจัดหาหรือผู้รับผิดชอบจากบริษัททำความสะอาดจะเป็นผู้ดำเนินการ หากเรากำลังพูดถึงการพัฒนา - โอกาสในการขายและ CTO การขาย - ทุกอย่างก็ชัดเจนเช่นกัน แต่ตั้งแต่สมัยก่อน เมื่อ "ห้องเซิร์ฟเวอร์" เป็นชื่อของตู้ที่มีระบบทาวเวอร์ธรรมดาที่มี RAM มากกว่าเล็กน้อยและมีฮาร์ดไดรฟ์สองสามตัวในการจู่โจม ทุกคน (หรืออย่างน้อยก็หลายคน) ก็เพิกเฉยต่อ ความจริงที่ว่าการซื้อกำลังการผลิตควรได้รับการจัดการโดยบุคคลที่ได้รับการฝึกอบรมมาเป็นพิเศษ
อนิจจา ความทรงจำและประสบการณ์ทางประวัติศาสตร์บ่งชี้ว่า เป็นเวลาหลายทศวรรษแล้วที่งานนี้เปลี่ยนมาเป็นคน "สุ่ม" ใครก็ตามที่ใกล้เคียงที่สุดจะตอบคำถาม และเมื่อไม่นานมานี้ อาชีพ FinOps ก็เริ่มเป็นรูปเป็นร่างในตลาดและมีรูปทรงที่เป็นรูปธรรม นี่เป็นบุคคลที่ได้รับการฝึกอบรมมาเป็นพิเศษซึ่งมีหน้าที่ควบคุมการซื้อและการใช้กำลังการผลิต และท้ายที่สุดในการลดต้นทุนของบริษัทในด้านนี้
เราไม่สนับสนุนให้ละทิ้งโซลูชันที่มีราคาแพงและมีประสิทธิภาพ แต่ละธุรกิจจะต้องตัดสินใจด้วยตัวเองว่าต้องการอะไรเพื่อการดำรงอยู่ที่สะดวกสบายในแง่ของภาษีฮาร์ดแวร์และระบบคลาวด์ แต่ก็อดไม่ได้ที่จะให้ความสนใจกับความจริงที่ว่าการซื้ออย่างไม่รอบคอบ "ตามรายการ" โดยไม่มีการตรวจสอบและวิเคราะห์การใช้งานในภายหลังสำหรับหลาย ๆ บริษัท ส่งผลให้เกิดการสูญเสียอย่างมากในท้ายที่สุดเนื่องจากการจัดการ "สินทรัพย์" ของแบ็กเอนด์ที่ไม่มีประสิทธิภาพ
FinOps คือใคร
สมมติว่าคุณมีองค์กรที่มีชื่อเสียง ซึ่งพนักงานขายพูดถึง "องค์กร" ด้วยน้ำเสียงที่ไพเราะ อาจเป็นไปได้ว่า "ตามรายการ" คุณซื้อเซิร์ฟเวอร์หลายสิบหรือสองเครื่อง, AWS และ "สิ่งเล็กน้อย" อื่น ๆ ซึ่งสมเหตุสมผล: ในบริษัทขนาดใหญ่ มีการเคลื่อนไหวบางอย่างเกิดขึ้นอย่างต่อเนื่อง - บางทีมเติบโต บางทีมก็สลายตัว และบางทีมก็ถูกโอนไปยังโครงการใกล้เคียง และการรวมกันของความเคลื่อนไหวเหล่านี้ ร่วมกับกลไกการจัดซื้อแบบ "ตามรายการ" จะนำไปสู่ปัญหาผมหงอกใหม่ในที่สุดเมื่อพิจารณาบิลโครงสร้างพื้นฐานรายเดือนถัดไป
แล้วจะทำอย่างไร - อดทนต่อให้เป็นสีเทาทาสีทับหรือหาสาเหตุของการปรากฏตัวของศูนย์ที่น่ากลัวมากมายเหล่านี้ในการชำระเงิน?
พูดตามตรง: การอนุมัติ การอนุมัติ และการชำระเงินโดยตรงของแอปพลิเคชันภายในบริษัทสำหรับอัตราค่าไฟฟ้า AWS เดียวกันนั้นไม่ได้รวดเร็วเสมอไป (ในความเป็นจริง แทบไม่เคยเลย) และเนื่องจากความเคลื่อนไหวขององค์กรอย่างต่อเนื่อง การเข้าซื้อกิจการเดียวกันนี้บางส่วนจึงอาจ "สูญหาย" ไปที่ไหนสักแห่ง และเป็นเรื่องเล็กน้อยที่จะยืนเฉยๆ หากผู้ดูแลระบบที่ใส่ใจสังเกตเห็นชั้นวางที่ไม่มีเจ้าของในห้องเซิร์ฟเวอร์ของเขา ในกรณีของภาษีคลาวด์ ทุกอย่างจะน่าเศร้ากว่านี้มาก สามารถวางได้หลายเดือน - จ่ายเงิน แต่ในขณะเดียวกันใครก็ตามในแผนกที่ซื้อก็ไม่ต้องการอีกต่อไป ในเวลาเดียวกัน เพื่อนร่วมงานจากสำนักงานถัดไปเริ่มที่จะฉีกผมที่ยังไม่เป็นหงอกไม่เพียงแต่บนศีรษะเท่านั้น แต่ยังรวมถึงที่อื่นด้วย - พวกเขาไม่สามารถจ่ายภาษี AWS เท่ากันโดยประมาณในสัปดาห์ที่ n ซึ่ง มีความจำเป็นอย่างยิ่ง
วิธีแก้ปัญหาที่ชัดเจนที่สุดคืออะไร? ใช่แล้ว มอบบังเหียนให้กับผู้ที่ต้องการความช่วยเหลือ แล้วทุกคนก็มีความสุข แต่การสื่อสารในแนวนอนไม่ได้ถูกสร้างขึ้นอย่างดีเสมอไป และแผนกที่สองอาจไม่รู้เกี่ยวกับความมั่งคั่งของแผนกแรกซึ่งกลับกลายเป็นว่าไม่ต้องการความมั่งคั่งนี้จริงๆ
ใครจะตำหนิเรื่องนี้? - จริงๆ แล้วไม่มีใครเลย นั่นคือวิธีการตั้งค่าทุกอย่างในตอนนี้
ใครทนทุกข์ทรมานจากสิ่งนี้? - แค่นั้นแหละทั้งบริษัท
ใครสามารถแก้ไขสถานการณ์ได้บ้าง? - ใช่ ใช่ FinOps
FinOps ไม่ได้เป็นเพียงชั้นระหว่างนักพัฒนาและอุปกรณ์ที่พวกเขาต้องการ แต่เป็นบุคคลหรือทีมที่จะรู้ว่ามัน "อยู่" ที่ไหน อะไร และดีแค่ไหนในแง่ของอัตราภาษีคลาวด์เดียวกันกับที่บริษัทซื้อ ในความเป็นจริง คนเหล่านี้จะต้องทำงานควบคู่กับ DevOps ในด้านหนึ่ง และฝ่ายการเงินในอีกด้านหนึ่ง โดยมีบทบาทเป็นตัวกลางที่มีประสิทธิภาพ และที่สำคัญที่สุดคือนักวิเคราะห์
เล็กน้อยเกี่ยวกับการเพิ่มประสิทธิภาพ
เมฆ. ค่อนข้างถูกและสะดวกมาก แต่โซลูชันนี้จะหยุดราคาถูกลงเมื่อจำนวนเซิร์ฟเวอร์ถึงเลขสองหรือสามหลัก นอกจากนี้ คลาวด์ยังทำให้สามารถใช้บริการต่างๆ ที่ไม่เคยมีมาก่อนได้มากขึ้นเรื่อยๆ เช่น ฐานข้อมูลในรูปแบบบริการ (Amazon AWS, Azure Database), แอปพลิเคชันแบบไร้เซิร์ฟเวอร์ (AWS Lambda, Azure Functions) และอื่นๆ อีกมากมาย ทุกอันเจ๋งมากเพราะใช้งานง่าย ซื้อแล้วไปได้เลย ไม่มีปัญหา แต่ยิ่งบริษัทและโครงการต่างๆ ของบริษัทเจาะลึกเข้าไปในกลุ่มเมฆมากเท่าใด CFO ก็จะยิ่งแย่ลงเท่านั้น และยิ่งนายพลเปลี่ยนเป็นสีเทาเร็วขึ้น
ความจริงก็คือใบแจ้งหนี้สำหรับบริการคลาวด์ต่างๆ มักสร้างความสับสนอย่างมาก: สำหรับรายการหนึ่ง คุณอาจได้รับคำอธิบายสามหน้าว่าเงินของคุณไปทำอะไร ที่ไหน และอย่างไร แน่นอนว่านี่เป็นเรื่องน่ายินดี แต่แทบจะเป็นไปไม่ได้เลยที่จะเข้าใจ ยิ่งไปกว่านั้น ความคิดเห็นของเราเกี่ยวกับปัญหานี้ยังห่างไกลจากความคิดเห็นเดียว: ในการโอนบัญชีคลาวด์ไปยังมนุษย์ มีบริการทั้งหมด เช่น หรือ . หากมีคนใส่ใจที่จะสร้างบริการแยกต่างหากสำหรับการถอดรหัสใบเสร็จ ขนาดของปัญหาก็จะเกินกว่าค่าย้อมผมแล้ว
FinOps ทำอะไรในสถานการณ์นี้:
- เข้าใจอย่างชัดเจนว่าซื้อโซลูชันคลาวด์ปริมาณเท่าใดและเมื่อใด
- รู้ว่าความสามารถเหล่านี้ถูกนำมาใช้อย่างไร
- แจกจ่ายซ้ำขึ้นอยู่กับความต้องการของหน่วยเฉพาะ
- ไม่ซื้อ "เพื่อที่จะได้เป็น"
- และในที่สุดก็ช่วยคุณประหยัดเงินได้
ตัวอย่างที่ดีคือพื้นที่เก็บข้อมูลบนคลาวด์ของสำเนาฐานข้อมูลแบบ Cold ตัวอย่างเช่น คุณเก็บถาวรเพื่อลดปริมาณพื้นที่และการรับส่งข้อมูลที่ใช้เมื่ออัปเดตที่เก็บข้อมูลหรือไม่ ใช่ ดูเหมือนว่าสถานการณ์จะถูกลง ในกรณีเฉพาะเจาะจงเพียงกรณีเดียว แต่สถานการณ์ที่ถูกเช่นนี้โดยรวมแล้วส่งผลให้มีต้นทุนที่สูงเกินไปสำหรับบริการคลาวด์ในภายหลัง
หรือสถานการณ์อื่น: คุณซื้อความจุสำรองบน AWS หรือ Azure เพื่อไม่ให้ตกอยู่ภายใต้ภาระงานสูงสุด คุณแน่ใจหรือไม่ว่านี่คือทางออกที่ดีที่สุด ท้ายที่สุดแล้ว หากอินสแตนซ์เหล่านี้ไม่มีการใช้งาน 80% แสดงว่าคุณเพียงแค่ให้เงินแก่ Amazon ยิ่งไปกว่านั้น ในกรณีดังกล่าว AWS และ Azure เดียวกันมีอินสแตนซ์ที่ขยายได้ - เหตุใดคุณจึงต้องมีเซิร์ฟเวอร์ที่ไม่ทำงาน หากคุณสามารถใช้เครื่องมือเพื่อแก้ไขปัญหาการโหลดสูงสุดได้ หรือแทนที่จะใช้อินสแตนซ์ On Premise คุณควรพิจารณาแบบเหมาจ่าย ซึ่งมีราคาถูกกว่ามากและมีส่วนลดให้ด้วย
โดยวิธีการเกี่ยวกับส่วนลด
ดังที่เรากล่าวไว้ในตอนต้นว่าใครก็ตามมักจะดำเนินการจัดซื้อจัดจ้าง - พวกเขาพบสิ่งสุดท้ายแล้วเขาก็ทำเอง บ่อยครั้งที่คนที่มีงานยุ่งอยู่แล้วกลายเป็น "คนหัวรุนแรง" และด้วยเหตุนี้เราจึงได้รับสถานการณ์ที่คน ๆ หนึ่งตัดสินใจอย่างรวดเร็วและชำนาญ แต่เป็นอิสระโดยสมบูรณ์ตัดสินใจว่าจะซื้ออะไรและในปริมาณเท่าใด
แต่เมื่อมีการโต้ตอบกับพนักงานขายจากบริการคลาวด์ คุณจะได้รับเงื่อนไขที่ดีกว่าเมื่อเป็นเรื่องของการซื้อความจุแบบขายส่ง เห็นได้ชัดว่าคุณไม่สามารถรับส่วนลดดังกล่าวจากรถยนต์ที่มีการลงทะเบียนแบบเงียบ ๆ และด้านเดียวได้ - แต่หลังจากพูดคุยกับผู้จัดการฝ่ายขายจริงแล้วคุณอาจเหนื่อยหน่าย หรือคนเหล่านี้สามารถบอกคุณได้ว่าปัจจุบันมีส่วนลดอะไรบ้าง นอกจากนี้ยังสามารถเป็นประโยชน์ได้
ในเวลาเดียวกัน คุณต้องจำไว้ว่าแสงไม่ได้มาบรรจบกันเหมือนลิ่มบน AWS หรือ Azure แน่นอนว่าไม่มีคำถามเกี่ยวกับการจัดห้องเซิร์ฟเวอร์ของคุณเอง แต่มีทางเลือกอื่นนอกเหนือจากโซลูชันคลาสสิกทั้งสองนี้จากยักษ์ใหญ่
ตัวอย่างเช่น Google นำแพลตฟอร์ม Firebase มาสู่บริษัทต่างๆ ซึ่งสามารถโฮสต์โปรเจ็กต์มือถือเดียวกันแบบครบวงจร ซึ่งอาจต้องมีการปรับขนาดอย่างรวดเร็ว พื้นที่จัดเก็บข้อมูล ฐานข้อมูลแบบเรียลไทม์ การโฮสต์และการซิงโครไนซ์ข้อมูลบนคลาวด์โดยใช้โซลูชันนี้เป็นตัวอย่างมีอยู่ในที่เดียว
ในทางกลับกัน หากเราไม่ได้พูดถึงโครงการที่มีเสาหิน แต่เกี่ยวกับความสมบูรณ์ของโครงการเหล่านั้น การแก้ปัญหาแบบรวมศูนย์ก็ไม่มีประโยชน์เสมอไป หากโครงการมีอายุการใช้งานยาวนาน มีประวัติการพัฒนาเป็นของตัวเอง และมีปริมาณข้อมูลที่สอดคล้องกันที่จำเป็นสำหรับการจัดเก็บ ก็ควรพิจารณาการจัดวางแบบกระจัดกระจายมากขึ้น
เมื่อปรับต้นทุนให้เหมาะสมสำหรับบริการคลาวด์ คุณอาจตระหนักได้ทันทีว่าสำหรับแอปพลิเคชันที่สำคัญต่อธุรกิจ คุณสามารถซื้ออัตราภาษีที่มีประสิทธิภาพมากขึ้นซึ่งจะทำให้บริษัทมีรายได้อย่างต่อเนื่อง ในเวลาเดียวกัน การจัดเก็บ "มรดก" ของการพัฒนา ไฟล์เก็บถาวรเก่า ฐานข้อมูล ฯลฯ ในระบบคลาวด์ที่มีราคาแพงถือเป็นวิธีแก้ปัญหา ท้ายที่สุดแล้ว สำหรับข้อมูลดังกล่าว ศูนย์ข้อมูลมาตรฐานที่มี HDD ปกติและฮาร์ดแวร์ที่ใช้พลังงานปานกลางโดยไม่มีสิ่งรบกวนใดๆ ค่อนข้างเหมาะสม
อีกครั้ง คุณอาจคิดว่า “เรื่องยุ่งยากนี้ไม่คุ้ม” แต่ปัญหาทั้งหมดของสิ่งพิมพ์นี้ขึ้นอยู่กับความจริงที่ว่าในขั้นตอนต่างๆ ผู้รับผิดชอบละเลยสิ่งเล็กๆ น้อยๆ และทำในสิ่งที่สะดวกและรวดเร็วยิ่งขึ้น ซึ่งในท้ายที่สุดหลังจากผ่านไปสองสามปีก็ส่งผลให้เกิดเรื่องราวที่น่าสยดสยองเหล่านั้น
ผลหรือไม่
โดยทั่วไปแล้ว คลาวด์นั้นเจ๋งมาก พวกมันช่วยแก้ปัญหามากมายให้กับธุรกิจทุกขนาด อย่างไรก็ตามปรากฏการณ์ใหม่นี้หมายความว่าเรายังไม่มีวัฒนธรรมการบริโภคและการจัดการ FinOps เป็นเครื่องมือระดับองค์กรที่ช่วยให้คุณใช้ประโยชน์จากพลังคลาวด์ได้อย่างมีประสิทธิภาพมากขึ้น สิ่งสำคัญคือไม่ต้องเปลี่ยนตำแหน่งนี้ให้กลายเป็นอะนาล็อกของทีมยิงซึ่งมีหน้าที่จับนักพัฒนาที่ไม่ตั้งใจด้วยมือและ "ดุ" พวกเขาให้หยุดทำงาน
นักพัฒนาควรพัฒนาไม่นับเงินของบริษัท ดังนั้น FinOps ควรทำให้ทั้งกระบวนการจัดซื้อและกระบวนการเลิกใช้งานหรือถ่ายโอนความจุคลาวด์ไปยังทีมอื่น ๆ เป็นกิจกรรมที่เรียบง่ายและสนุกสนานสำหรับทุกฝ่าย
ที่มา: will.com