บริหารต้นทุน
เริ่มทบทวนค่าใช้จ่าย AWS: เช็กลิสต์ที่ทีมไอทีขนาดเล็กนำไปใช้ได้
ตั้งต้นจากข้อมูลค่าใช้จ่ายที่เปรียบเทียบกันได้ ค้นหารายการที่ต้องตรวจสอบ และสรุปเป็นงานปรับปรุงที่มีผู้รับผิดชอบและทดสอบผลได้
1. ตกลงก่อนว่าการทบทวนครั้งนี้ต้องตอบเรื่องอะไร
การทบทวนค่าใช้จ่าย AWS ครั้งแรกควรช่วยให้ทีมไอทีขนาดเล็กอธิบายได้ว่าเงินส่วนใหญ่ใช้ไปกับอะไร และได้รายการงานต่อที่ทีมจัดการไหว เริ่มจากคำถามเดียวว่า ค่าใช้จ่ายส่วนที่เปลี่ยนไปมีรายการใดอธิบายได้แล้ว และรายการใดต้องตรวจเพิ่ม ชวนทั้งคนที่เข้าใจปริมาณงานของแอปพลิเคชันและคนที่รับผิดชอบงบประมาณมาร่วมกัน
กำหนดบัญชี ระบบงาน และช่วงเวลาของรายงานก่อนเปิดแดชบอร์ด จดกิจกรรมทางธุรกิจไว้ข้างตัวเลขด้วย เช่น การเปิดตัวสินค้า การขยายตลาด การทดสอบ และความต้องการตามฤดูกาล เพราะทั้งหมดมีผลต่อการพิจารณาว่าค่าใช้จ่ายเหมาะสมหรือไม่ แนวทางบริหารต้นทุนของ AWS เชื่อมการตัดสินใจเรื่องค่าใช้จ่ายกับเป้าหมายธุรกิจและผู้รับผิดชอบที่ชัดเจน
- ระบุเจ้าของการทบทวนและคนที่อธิบายความต้องการใช้งานได้
- บันทึกบัญชีที่รวมในรายงาน สกุลเงิน และวิธีนับต้นทุนที่ใช้
- เลือกช่วงเวลาเปรียบเทียบที่ใช้ซ้ำได้ พร้อมจดเหตุการณ์พิเศษ
2. สร้างข้อมูลตั้งต้นที่เปรียบเทียบได้ใน Cost Explorer
ใช้มุมมองรายเดือนดูทิศทางโดยรวม แล้วใช้รายวันหาว่าการเปลี่ยนแปลงเริ่มตรงไหน Cost Explorer เลือกช่วงเวลา จัดกลุ่ม และกรองข้อมูลได้ เริ่มจากค่าใช้จ่ายแยกตามบริการและบัญชี จากนั้นตรวจรายการที่เปลี่ยนมากและยังอธิบายไม่ได้ ใช้การตั้งค่ารายงานแบบเดียวกันทุกครั้ง เพื่อไม่ให้ความต่างของรายงานถูกเข้าใจว่าเป็นความต่างของต้นทุน
หากทำได้ ให้เทียบช่วงเวลาที่ครบแล้วด้วยกัน ค่าใช้จ่ายเดือนปัจจุบันที่ยังไม่จบต้องมีบริบทก่อนนำไปเทียบกับทั้งเดือนก่อน เขียนคำอธิบายสั้น ๆ พร้อมลิงก์หลักฐานให้แต่ละรายการที่เปลี่ยนไป และเก็บรายการที่ยังหาคำตอบไม่ได้ไว้ให้เห็นชัด กราฟที่ดูเรียบร้อยยังไม่พอหากทีมไม่รู้ว่าระบบงานใดทำให้ค่าใช้จ่ายเปลี่ยน
- บันทึกช่วงเวลา ตัวกรอง และตัวชี้วัดต้นทุนที่ใช้ในแต่ละมุมมอง
- แยกการเติบโตของงานที่อธิบายได้ออกจากค่าใช้จ่ายที่ยังต้องตรวจ
- ตรวจเครดิตหรือรายการครั้งเดียวก่อนสรุปแนวโน้ม
3. เชื่อมค่าใช้จ่ายเข้ากับเจ้าของและวัตถุประสงค์
ยอดรวมตามบริการช่วยบอกจุดเริ่มตรวจ แต่อาจยังไม่บอกว่าใครมีข้อมูลพอที่จะตัดสินใจปรับระบบ ใช้ชุดแท็กขนาดเล็กที่ตั้งค่าให้สม่ำเสมอ เช่น แอปพลิเคชัน สภาพแวดล้อม และผู้รับผิดชอบ แท็กสำหรับจัดสรรต้นทุนของ AWS ต้องเปิดใช้งานก่อน จึงจะแสดงใน Cost Explorer หรือรายงานจัดสรรต้นทุนได้
เริ่มแก้แท็กที่ขาดในระบบที่กำลังทบทวน ตกลงค่าที่อนุญาตให้ใช้กับทีมที่สร้างทรัพยากร และมอบหมายคนตรวจค่าใช้จ่ายที่ยังจัดกลุ่มไม่ได้ หากมีโครงสร้างพื้นฐานใช้ร่วมกัน ให้บันทึกวิธีที่ทีมจะพิจารณาหรือจัดสรรค่าใช้จ่ายส่วนนั้น แทนการใส่ชื่อแอปพลิเคชันที่ทำให้เข้าใจเจ้าของต้นทุนผิด
- ระบุผู้รับผิดชอบด้านเทคนิคของแต่ละรายการที่กำลังตรวจ
- ตรวจว่าแท็กจัดสรรต้นทุนที่เลือกไว้เปิดใช้งานแล้วจริง
- ใช้ค่าแท็กให้สม่ำเสมอและไม่ใส่ข้อมูลอ่อนไหวในแท็ก
4. เปลี่ยนข้อค้นพบให้เป็นงานปรับปรุงที่ทดสอบได้
AWS ระบุว่าทรัพยากรที่ไม่ได้ใช้งานหรือมีขนาดเกินความจำเป็น รวมถึงรูปแบบการคิดค่าใช้จ่าย เป็นประเด็นที่ควรพิจารณาปรับต้นทุน ใช้คำแนะนำเป็นข้อมูลตั้งต้นเพื่อตรวจต่อ โดยดูช่วงงานสูงสุด งานตามกำหนด และความต้องการด้านความพร้อมใช้งานก่อนปรับขนาด ทรัพยากรที่ดูเงียบในเวลาทำการอาจมีหน้าที่สำคัญตอนกลางคืน
สำหรับแต่ละรายการ ให้เขียนสิ่งที่จะเปลี่ยน ผู้รับผิดชอบ หลักฐาน และเกณฑ์บริการที่ยังต้องผ่าน เลือกจำนวนงานให้พอกับกำลังตรวจสอบของทีม หากกำลังพิจารณาผูกพันการใช้จ่ายล่วงหน้า ให้บันทึกความต้องการที่คาดว่าจะเหลือหลังปรับสถาปัตยกรรมและขนาดทรัพยากรตามแผน แล้วจึงทบทวนเงื่อนไขที่เกี่ยวข้อง
- ยืนยันวัตถุประสงค์และระบบที่พึ่งพากันก่อนเลิกใช้ทรัพยากร
- ทดสอบการปรับขนาดด้วยพฤติกรรมการใช้งานที่เป็นตัวแทนของงานจริง
- บันทึกวิธีย้อนกลับและวันที่จะกลับมาตรวจผล
5. ตัวอย่างสมมติ: ระบบทดสอบที่ยังไม่มีเจ้าของชัดเจน
สมมติว่าร้านค้าออนไลน์แห่งหนึ่งพบค่าใช้จ่ายประมวลผลของสภาพแวดล้อม staging ต่อเนื่องหลังจบแคมเปญ ชื่อทรัพยากรดูเหมือนใช้กับโครงการชั่วคราว แต่ในตอนแรกทีมยังอธิบายไม่ได้ว่าใครใช้งานอยู่ เรื่องนี้จึงต้องหาผู้รับผิดชอบและการใช้งานที่เหลือให้ชัดก่อนตัดสินใจปิดระบบ
เจ้าของแอปพลิเคชันยืนยันว่ายังมีการทดสอบการเชื่อมต่อระหว่างระบบตอนกลางคืน ทีมจึงเสนอให้ตั้งเวลาเปิดใช้งานตามช่วงทดสอบที่ตรวจสอบแล้ว และทดลองพฤติกรรมการเริ่มระบบใหม่อย่างควบคุม พร้อมบันทึกผลว่างานทดสอบจบครบหรือไม่และค่าใช้จ่ายในช่วงที่เปรียบเทียบกันได้ ตัวอย่างนี้แสดงวิธีทบทวน ไม่ใช่ผลลัพธ์ของลูกค้าหรือประมาณการเงินที่ประหยัดได้
- หาเจ้าของระบบและยืนยันงานธุรกิจที่ยังต้องใช้ระบบนี้
- ทดสอบตารางเปิดใช้งานที่เสนอโดยรวมงานที่พึ่งพาระบบนี้ด้วย
- ตรวจทั้งต้นทุนและพฤติกรรมบริการก่อนยอมรับการเปลี่ยนแปลง
6. ตั้งการแจ้งเตือนและสรุปงานต่อให้กระชับ
ตั้ง AWS Budgets ให้ตรงกับขอบเขตค่าใช้จ่ายที่ตกลงไว้ และเลือกผู้รับการแจ้งเตือนที่รู้ว่าจะเริ่มตรวจจากตรงไหน บริการนี้แจ้งเตือนจากยอดที่เกิดขึ้นแล้วหรือค่าคาดการณ์ได้ ข้อมูลงบประมาณอัปเดตตามข้อมูลบิล จึงควรใช้การแจ้งเตือนเป็นสัญญาณให้เข้ามาทบทวน การแจ้งเตือนเพียงอย่างเดียวไม่ได้จำกัดการใช้จ่ายทันที
จบการประชุมด้วยรายการงานสั้น ๆ ที่มีผู้รับผิดชอบ วันทบทวน และหลักฐานที่ต้องใช้เพื่อปิดแต่ละเรื่อง ครั้งถัดไปให้เทียบผลด้วยวิธีนับต้นทุนเดิม พร้อมบันทึกความต้องการใช้งานที่เปลี่ยนไป เก็บปัญหาเรื่องเจ้าของระบบและแท็กที่ยังไม่ครบไว้ในรายการเดียวกับงานเทคนิค เพื่อให้ได้รับการติดตามเช่นกัน
- ตรวจขอบเขตงบประมาณ ประเภทค่าใช้จ่ายที่รวม และผู้รับการแจ้งเตือน
- กำหนดขั้นตอนแรกในการตรวจสอบสำหรับการแจ้งเตือนแต่ละรายการ
- บันทึกการเปลี่ยนแปลงที่ยอมรับ เรื่องที่เลื่อนไป และวันทบทวนครั้งต่อไป