Perjalanan Tim Pengembang AB180 dalam Mengelola Biaya AWS: Dari Memeriksa Tagihan hingga Budaya FinOps

Diringkas dengan Gemini.

--

Sambil mengoperasikan solusi pengukuran kinerja pemasaran 'Airbridge' yang memproses sangat banyak data, kami telah membangun budaya pengelolaan biaya AWS (FinOps) yang sistematis. Kami membagikan pengalaman dan know-how yang diperoleh dalam proses tersebut.

Cara AB180 mengoperasikan manajemen biaya:
Kami menjalankan proses berikut untuk 'mengelola' biaya.

• Dasbor berbasis Google Sheets: Kami membangun dasbor dengan memanfaatkan Google Sheets, yang memudahkan pengolahan dan berbagi data. Tidak hanya menampilkan kondisi biaya per tag, dasbor ini juga memperlihatkan volume pengumpulan data yang berdampak langsung pada biaya sehingga penyebab perubahan dapat dipahami secara intuitif. Selain itu, kami memvisualisasikan status coverage Savings Plan dan mensimulasikan hasilnya terlebih dahulu saat kontrak diubah untuk membantu pengambilan keputusan yang rasional.
• Pemeriksaan biaya berkala dan otomatis: Setiap dua minggu sekali, kami memeriksa perubahan biaya melalui rapat singkat sekitar 30 menit. Pekerjaan berulang seperti pembuatan materi rapat, notifikasi Slack, dan penulisan notulen diotomatisasi semaksimal mungkin untuk meningkatkan efisiensi. Jika perubahan biaya besar, penanggung jawab menganalisis penyebabnya melalui komentar di Google Sheets dan membagikannya untuk memastikan transparansi.
• Menghitung estimasi biaya sebelum pengembangan: Saat mengembangkan fitur baru atau mengubah arsitektur, kami mewajibkan perhitungan estimasi biaya dalam dokumen 'Tech Spec'. Dengan demikian, keputusan teknis yang lebih baik dengan mempertimbangkan biaya dapat diambil sejak tahap pengembangan.

Proses memajukan sistem manajemen biaya:
Sistem saat ini tidak dibangun dalam semalam. Sistem ini berkembang melalui tahapan berikut.

• Phase 0 (memeriksa tagihan): Pada awalnya, kami hanya sampai pada tahap memeriksa tagihan setiap bulan.
• Phase 1 (klasifikasi minimum): Kami mulai mengklasifikasikan resource secara minimal dengan memanfaatkan tag Name.
• Phase 2 (mematangkan strategi tag): Kami menetapkan strategi tag berbasis kebijakan yang jelas seperti Team dan Service. Karena hanya mendistribusikan panduan tidak cukup, kami menautkannya dengan kebijakan IAM untuk memaksa pengaturan tag, dan membangun mekanisme yang secara otomatis mengirim notifikasi melalui bot Slack untuk resource yang tidak memiliki tag. Hasilnya, kami berhasil menjaga biaya resource tanpa tag di bawah 1% dari total.

5 pelajaran yang diperoleh dari perjalanan ini:

• Engineering yang sesuai dengan situasi itu penting. Daripada mengejar sistem sempurna untuk mengendalikan biaya, lebih bijak membangun tata kelola yang 'tepat' secara bertahap sesuai skala dan situasi perusahaan.
• 'Pengendalian' biaya dan 'optimasi' adalah hal yang berbeda. 'Pengendalian' yang meningkatkan prediktabilitas biaya dan 'optimasi' yang menurunkan biaya itu sendiri jelas berbeda. Kita perlu memutuskan fokus berdasarkan prioritas situasi.
• Otomatisasi harus dilakukan dengan berani. Lebih dari sekadar mengotomatisasi pekerjaan rutin berulang, produktivitas dapat dimaksimalkan dengan membangun lingkungan 'self-serve' agar rekan kerja bisa langsung menelusuri data dan mengidentifikasi masalah sendiri.
• Kita harus membangun 'mekanisme'. Alih-alih mengatakan "mari pasang tag dengan baik", lebih efektif merancang 'perangkat (mekanisme)' yang membuat kebijakan mau tak mau harus diikuti, misalnya resource tidak akan diberi izin jika tidak memiliki tag.
• FinOps pada akhirnya adalah 'budaya'. Yang paling penting adalah terus berupaya dan membangun budaya agar pengelolaan biaya dipahami bukan sebagai tugas orang tertentu, melainkan tanggung jawab semua orang yang membuat produk.

[tujuc]

Oho.. sepertinya kalau setidaknya tag yang paling dasar saja dipasang, sudah lumayan membantu.. :)

Tapi, apakah mengurangi biaya dengan memanfaatkan hal seperti RI atau SP itu termasuk hal yang sudah jadi dasar....
Sampai sejauh mana ukuran yang akan dipakai di infrastruktur kami memang jadi bagian yang cukup banyak perlu dipikirkan...

[dongho42]

Ini memang disebutkan juga di artikel, tetapi saya secara terpisah membuat simulator SP, lalu berdasarkan workload selama n hari terakhir menghitung seberapa banyak SP tambahan yang perlu dibeli agar kombinasi "biaya saat ini + penghematan biaya karena tercakup + biaya yang terbuang karena menjadi recurring" menjadi yang paling kecil, dan dari situ saya mengambil keputusan.

[slave4salary]

Saya adalah karyawan AWS Korea yang saat ini bekerja di sana.

Salah satu pelatihan terpenting yang didengar setelah bergabung adalah memikirkan cara agar pelanggan dapat menggunakan biaya cloud seminimal mungkin, dan sebagai salah satu metode yang paling efektif, RI & SP diperkenalkan.

[cocofather]

Tolong turunkan biayanya..

[toughrogrammer]

Meski tidak begitu paham soal RI, untuk SP ini bisa diterapkan ke berbagai workload, jadi kalau ada biaya tetap yang terus keluar, ini sangat layak untuk dipertimbangkan. Bahkan kami pernah membelinya dengan mempertimbangkan sampai kapan optimasi yang diperkirakan akan selesai... wkwk. Misalnya, kalau 9 bulan lagi optimasi selesai dan biaya server tampaknya akan turun setengahnya, tetap lebih menguntungkan membeli untuk 1 tahun, jadi kami mengambil pendekatan seperti itu.