Well-Architected Framework: Perspektif industri layanan keuangan (FSI)

Last reviewed 2025-07-28 UTC

Dokumen dalam Google Cloud Framework Berarsitektur Baik ini menjelaskan prinsip dan rekomendasi untuk membantu Anda mendesain, membangun, dan mengelola aplikasi industri jasa keuangan (FSI) di Google Cloud yang memenuhi sasaran operasional, keamanan, keandalan, biaya, dan performa Anda.

Target audiens untuk dokumen ini mencakup pengambil keputusan, arsitek, administrator, developer, dan operator yang mendesain, membangun, men-deploy, dan memelihara workload FSI di Google Cloud. Contoh organisasi FSI yang dapat memanfaatkan panduan ini mencakup bank, pelaku infrastruktur pembayaran, penyedia asuransi, dan operator pasar modal.

Organisasi FSI memiliki pertimbangan khusus, terutama untuk arsitektur dan ketahanan. Pertimbangan ini terutama didorong oleh persyaratan peraturan, risiko, dan performa. Dokumen ini memberikan panduan umum yang didasarkan pada pertimbangan desain yang telah kami amati di berbagai pelanggan FSI di seluruh dunia. Baik workload Anda sepenuhnya berada di cloud atau sedang bertransisi ke deployment hybrid atau multi-cloud, panduan dalam dokumen ini membantu Anda mendesain workload di Google Cloud untuk memenuhi persyaratan peraturan dan beragam perspektif risiko Anda. Panduan ini mungkin tidak mengatasi tantangan unik setiap organisasi. Solusi ini menyediakan fondasi yang memenuhi banyak persyaratan peraturan utama organisasi FSI.

Tantangan utama dalam mendesain workload cloud adalah menyelaraskan deployment cloud dengan lingkungan lokal, terutama saat Anda menginginkan pendekatan yang konsisten terhadap keamanan, keandalan, dan ketahanan. Layanan cloud menciptakan peluang untuk memikirkan ulang arsitektur Anda secara mendasar guna mengurangi overhead pengelolaan, mengoptimalkan biaya, meningkatkan keamanan, serta meningkatkan keandalan dan ketahanan.

Halaman berikut menjelaskan prinsip dan rekomendasi khusus untuk beban kerja FSI untuk setiap pilar Well-Architected Framework:

Kontributor

Penulis:

Kontributor lainnya:

Perspektif FSI: Keunggulan operasional

Dokumen dalam Google Cloud Framework yang Dirancang dengan Baik: Perspektif FSI memberikan ringkasan prinsip dan rekomendasi untuk membangun, men-deploy, dan mengoperasikan workload industri jasa keuangan (FSI) yang andal di Google Cloud. Rekomendasi ini membantu Anda menyiapkan elemen dasar seperti kemampuan observasi, otomatisasi, dan skalabilitas. Rekomendasi dalam dokumen ini selaras dengan pilar keunggulan operasional dari Framework yang Dirancang dengan Baik.

Keunggulan operasional sangat penting untuk workload FSI di Google Cloud karena sifat workload tersebut yang sangat diatur dan sensitif. Keunggulan operasional memastikan bahwa solusi cloud dapat beradaptasi dengan kebutuhan yang terus berubah dan memenuhi persyaratan Anda dalam hal nilai, performa, keamanan, dan keandalan. Kegagalan di area ini dapat mengakibatkan kerugian finansial yang signifikan, hukuman peraturan, dan kerusakan reputasi.

Keunggulan operasional memberikan manfaat berikut untuk workload FSI:

  • Menjaga kepercayaan dan reputasi: Lembaga keuangan sangat mengandalkan kepercayaan pelanggan mereka. Gangguan operasional atau pelanggaran keamanan dapat mengikis kepercayaan ini secara signifikan dan menyebabkan pelanggan beralih ke produk lain. Keunggulan operasional membantu meminimalkan risiko ini.

  • Memenuhi persyaratan kepatuhan terhadap peraturan yang ketat: FSI tunduk pada berbagai peraturan yang rumit, seperti berikut:

    Proses operasional, pemantauan, dan pengelolaan insiden yang andal sangat penting untuk menunjukkan kepatuhan terhadap peraturan dan menghindari hukuman.

  • Memastikan kelangsungan dan ketahanan bisnis: Pasar dan layanan keuangan sering kali beroperasi secara berkelanjutan. Oleh karena itu, ketersediaan tinggi dan pemulihan dari bencana (disaster recovery) yang efektif sangat penting. Prinsip keunggulan operasional memandu desain dan penerapan sistem yang tangguh. Pilar keandalan memberikan panduan lebih lanjut di area ini.

  • Melindungi data sensitif: Lembaga keuangan menangani banyak sekali data pelanggan dan keuangan yang sangat sensitif. Kontrol operasional yang kuat, pemantauan keamanan, dan respons insiden yang cepat sangat penting untuk mencegah pelanggaran data dan menjaga privasi. Pilar keamanan memberikan panduan lebih lanjut di area ini.

  • Mengoptimalkan performa untuk aplikasi penting: Banyak aplikasi keuangan, seperti platform perdagangan dan analisis real-time, memerlukan performa tinggi dan latensi rendah. Untuk memenuhi persyaratan performa ini, Anda memerlukan desain komputasi, jaringan, dan penyimpanan yang sangat dioptimalkan. Pilar pengoptimalan performa memberikan panduan lebih lanjut di area ini.

  • Mengelola biaya secara efektif: Selain keamanan dan keandalan, lembaga keuangan juga memperhatikan efisiensi biaya. Keunggulan operasional mencakup praktik untuk mengoptimalkan pemanfaatan resource dan mengelola pembelanjaan cloud. Pilar pengoptimalan biaya memberikan panduan lebih lanjut di area ini.

Rekomendasi keunggulan operasional dalam dokumen ini dipetakan ke prinsip inti berikut:

Menentukan SLA serta SLO dan SLI yang sesuai

Di banyak organisasi FSI, ketersediaan aplikasi biasanya diklasifikasikan berdasarkan metrik tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). Untuk aplikasi penting bisnis yang melayani pelanggan eksternal, perjanjian tingkat layanan (SLA) juga dapat ditentukan.

SLA memerlukan framework metrik yang merepresentasikan perilaku sistem dari perspektif kepuasan pengguna. Praktik Site Reliability Engineering (SRE) menawarkan cara untuk mencapai tingkat keandalan sistem yang Anda inginkan. Membuat framework metrik melibatkan penentuan dan pemantauan indikator numerik utama untuk memahami kondisi sistem dari perspektif pengguna. Misalnya, metrik seperti latensi dan tingkat error mengukur seberapa baik performa layanan. Metrik ini disebut indikator tingkat layanan (SLI). Pengembangan SLI yang efektif sangat penting karena SLI menyediakan data mentah yang diperlukan untuk menilai keandalan secara objektif.

Untuk menentukan SLA, SLI, dan SLO yang bermakna, pertimbangkan rekomendasi berikut:

  • Kembangkan dan tentukan SLI untuk setiap layanan penting. Tetapkan nilai target yang menentukan tingkat performa yang dapat diterima.
  • Kembangkan dan tentukan tujuan tingkat layanan (SLO) yang sesuai dengan SLI. Misalnya, SLO dapat menyatakan bahwa 99,9% permintaan harus memiliki latensi kurang dari 200 milidetik.
  • Identifikasi tindakan perbaikan internal yang harus dilakukan jika layanan tidak memenuhi SLO. Misalnya, untuk meningkatkan ketahanan platform, Anda mungkin perlu memfokuskan sumber daya pengembangan untuk memperbaiki masalah.
  • Validasi persyaratan SLA untuk setiap layanan dan akui SLA sebagai kontrak formal dengan pengguna layanan.

Contoh tingkat layanan

Tabel berikut memberikan contoh SLI, SLO, dan SLA untuk platform pembayaran:

Metrik bisnis SLI SLO SLA
Keberhasilan transaksi pembayaran

Ukuran kuantitatif persentase semua transaksi pembayaran yang dimulai yang berhasil diproses dan dikonfirmasi.

Contoh: (jumlah transaksi yang berhasil ÷ total jumlah transaksi yang valid) × 100, diukur selama periode 5 menit bergulir.

Target internal untuk mempertahankan persentase tinggi transaksi pembayaran yang berhasil selama periode tertentu.

Contoh: Pertahankan rasio keberhasilan transaksi pembayaran sebesar 99,98% selama periode 30 hari, tidak termasuk permintaan yang tidak valid dan pemeliharaan terencana.

Jaminan kontraktual untuk tingkat keberhasilan dan kecepatan pemrosesan transaksi pembayaran.

Contoh: Penyedia layanan menjamin bahwa 99,0% transaksi pembayaran yang dimulai oleh klien akan berhasil diproses dan dikonfirmasi dalam waktu satu detik.
Latensi pemrosesan pembayaran

Rata-rata waktu yang diperlukan untuk memproses transaksi pembayaran dari inisiasi oleh klien hingga konfirmasi akhir.

Contoh: Waktu respons rata-rata dalam milidetik untuk konfirmasi transaksi, yang diukur selama periode 5 menit bergulir.

Target internal untuk kecepatan pemrosesan transaksi pembayaran.

Contoh: Pastikan 99,5% transaksi pembayaran diproses dalam waktu 400 milidetik selama periode 30 hari.

Komitmen kontraktual untuk menyelesaikan masalah pemrosesan pembayaran kritis dalam jangka waktu tertentu.

Contoh: Untuk masalah pemrosesan pembayaran yang kritis (didefinisikan sebagai gangguan yang memengaruhi lebih dari 1% transaksi), penyedia layanan berkomitmen untuk menyelesaikan masalah dalam waktu dua jam sejak masalah dilaporkan atau terdeteksi.
Ketersediaan platform

Persentase waktu saat API pemrosesan pembayaran inti dan antarmuka pengguna beroperasi dan dapat diakses oleh klien.

Contoh: (total waktu operasional − waktu nonaktif) ÷ total waktu operasional × 100, diukur per menit.

Target internal untuk uptime platform pembayaran inti.

Contoh: Mencapai ketersediaan platform 99,995% per bulan kalender, tidak termasuk periode pemeliharaan terjadwal.

Komitmen formal dan mengikat secara hukum kepada klien terkait waktu aktif minimum platform pembayaran, termasuk konsekuensi jika tidak dapat dipenuhi.

Contoh: Platform akan mempertahankan ketersediaan minimum 99,9% per bulan kalender, tidak termasuk periode pemeliharaan terjadwal. Jika ketersediaan turun di bawah tingkat minimum, klien akan menerima kredit layanan sebesar 5% dari biaya layanan bulanan untuk setiap penurunan 0,1%.

Gunakan data SLI untuk memantau apakah sistem berada dalam SLO yang ditentukan dan untuk memastikan SLA terpenuhi. Dengan menggunakan serangkaian SLI yang ditentukan dengan baik, engineer dan developer dapat memantau aplikasi FSI di tingkat berikut:

  • Langsung di dalam layanan tempat aplikasi di-deploy, seperti GKE atau Cloud Run.
  • Dengan menggunakan log yang disediakan oleh komponen infrastruktur, seperti load balancer.

OpenTelemetry menyediakan standar open source dan serangkaian teknologi untuk mengambil semua jenis telemetri, termasuk metrik, trace, dan log. Google Cloud Managed Service for Prometheus menyediakan backend yang terkelola sepenuhnya dan sangat skalabel untuk metrik dan operasi Prometheus dalam skala besar.

Untuk mengetahui informasi selengkapnya tentang SLI, SLO, dan anggaran error, lihat buku panduan SRE.

Untuk mengembangkan mekanisme dan dasbor pemantauan serta pemberitahuan yang efektif, gunakan alat Google Cloud Observability bersama dengan Google Cloud Monitoring. Untuk mengetahui informasi tentang kemampuan pemantauan dan deteksi khusus keamanan, lihat pilar keamanan.

Menentukan dan menguji proses manajemen insiden

Proses pengelolaan insiden yang terdefinisi dengan baik dan diuji secara rutin berkontribusi langsung terhadap nilai, performa, keamanan, dan keandalan beban kerja FSI di Google Cloud. Proses ini membantu lembaga keuangan memenuhi persyaratan peraturan yang ketat, melindungi data sensitif, mempertahankan kelangsungan bisnis, dan menjaga kepercayaan pelanggan.

Pengujian rutin terhadap proses pengelolaan insiden memberikan manfaat berikut:

  • Mempertahankan performa di bawah beban puncak: Pengujian performa dan beban rutin membantu lembaga keuangan memastikan bahwa aplikasi dan infrastruktur berbasis cloud mereka dapat menangani volume transaksi puncak, volatilitas pasar, dan skenario permintaan tinggi lainnya tanpa penurunan performa. Kemampuan ini sangat penting untuk mempertahankan pengalaman pengguna yang lancar dan memenuhi permintaan pasar keuangan.
  • Mengidentifikasi potensi hambatan dan batasan: Pengujian beban mendorong sistem hingga batasnya, dan memungkinkan lembaga keuangan mengidentifikasi potensi hambatan dan batasan performa sebelum memengaruhi operasi penting. Pendekatan proaktif ini memungkinkan lembaga keuangan menyesuaikan infrastruktur dan aplikasi mereka untuk mendapatkan performa dan skalabilitas yang optimal.
  • Memvalidasi keandalan dan ketahanan: Pengujian rutin, termasuk rekayasa kekacauan atau kegagalan yang disimulasikan, membantu memvalidasi keandalan dan ketahanan sistem keuangan. Pengujian ini memastikan bahwa sistem dapat pulih dengan baik dari kegagalan dan mempertahankan ketersediaan tinggi, yang penting untuk kelangsungan bisnis.
  • Lakukan perencanaan kapasitas yang efektif: Pengujian performa memberikan data berharga tentang pemanfaatan resource dalam berbagai kondisi beban, yang sangat penting untuk perencanaan kapasitas yang akurat. Lembaga keuangan dapat menggunakan data ini untuk mengantisipasi kebutuhan kapasitas di masa mendatang secara proaktif dan menghindari masalah performa akibat kendala resource.
  • Men-deploy fitur baru dan perubahan kode dengan berhasil: Mengintegrasikan pengujian otomatis ke dalam pipeline CI/CD membantu memastikan bahwa perubahan dan deployment baru divalidasi secara menyeluruh sebelum dirilis ke lingkungan produksi. Pendekatan ini secara signifikan mengurangi risiko error dan regresi yang dapat menyebabkan gangguan operasional.
  • Memenuhi persyaratan peraturan untuk stabilitas sistem: Peraturan keuangan sering kali mewajibkan lembaga memiliki praktik pengujian yang andal untuk memastikan stabilitas dan keandalan sistem penting mereka. Pengujian reguler membantu menunjukkan kepatuhan terhadap persyaratan ini.

Untuk menentukan dan menguji proses pengelolaan insiden, pertimbangkan rekomendasi berikut.

Menetapkan prosedur respons insiden yang jelas

Serangkaian prosedur respons insiden yang sudah teruji mencakup elemen berikut:

  • Peran dan tanggung jawab yang ditentukan untuk komandan insiden, penyelidik, komunikator, dan pakar teknis untuk memastikan respons yang efektif dan terkoordinasi.
  • Protokol komunikasi dan jalur eskalasi yang ditentukan untuk memastikan informasi dibagikan dengan cepat dan efektif selama insiden.
  • Prosedur yang didokumentasikan dalam runbook atau playbook yang menguraikan langkah-langkah untuk komunikasi, triase, penyelidikan, dan penyelesaian.
  • Pelatihan dan persiapan rutin yang membekali tim dengan pengetahuan dan keterampilan untuk merespons secara efektif.

Terapkan pengujian performa dan beban secara rutin

Pengujian performa dan beban secara rutin membantu memastikan bahwa aplikasi dan infrastruktur berbasis cloud dapat menangani beban puncak dan mempertahankan performa yang optimal. Pengujian beban menyimulasikan pola traffic yang realistis. Pengujian beban kerja menguji sistem hingga batasnya untuk mengidentifikasi potensi bottleneck dan batasan performa. Anda dapat menggunakan produk seperti Cloud Load Balancing dan layanan pengujian beban untuk menyimulasikan traffic dunia nyata. Berdasarkan hasil pengujian, Anda dapat menyesuaikan infrastruktur dan aplikasi cloud untuk mendapatkan performa dan skalabilitas yang optimal. Misalnya, Anda dapat menyesuaikan alokasi resource atau menyesuaikan konfigurasi aplikasi.

Mengotomatiskan pengujian dalam pipeline CI/CD

Menggabungkan pengujian otomatis ke dalam pipeline CI/CD membantu memastikan kualitas dan keandalan aplikasi cloud dengan memvalidasi perubahan sebelum deployment. Pendekatan ini secara signifikan mengurangi risiko error dan regresi, serta membantu Anda membangun sistem software yang lebih stabil dan andal. Anda dapat menggabungkan berbagai jenis pengujian dalam pipeline CI/CD, termasuk pengujian unit, pengujian integrasi, dan pengujian end-to-end. Gunakan produk seperti Cloud Build dan Cloud Deploy untuk membuat dan mengelola pipeline CI/CD Anda.

Terus meningkatkan dan berinovasi

Untuk beban kerja jasa keuangan di cloud, migrasi ke cloud hanyalah langkah awal. Peningkatan dan inovasi berkelanjutan sangat penting karena alasan berikut:

  • Mempercepat inovasi: Manfaatkan teknologi baru seperti AI untuk meningkatkan kualitas layanan Anda.
  • Mengurangi biaya: Menghilangkan inefisiensi dan mengoptimalkan penggunaan resource.
  • Meningkatkan ketangkasan: Beradaptasi dengan perubahan pasar dan peraturan dengan cepat.
  • Meningkatkan kualitas pengambilan keputusan: Gunakan produk analisis data seperti BigQuery dan Looker untuk membuat pilihan yang tepat.

Untuk memastikan peningkatan dan inovasi berkelanjutan, pertimbangkan rekomendasi berikut.

Lakukan retrospektif secara rutin

Retrospektif sangat penting untuk terus meningkatkan kualitas prosedur respons insiden, dan untuk mengoptimalkan strategi pengujian berdasarkan hasil performa dan pengujian beban secara rutin. Untuk memastikan retrospektif efektif, lakukan hal berikut:

  • Berikan kesempatan kepada tim untuk merenungkan pengalaman mereka, mengidentifikasi hal-hal yang berjalan dengan baik, dan menentukan area yang perlu ditingkatkan.
  • Lakukan retrospektif setelah pencapaian project, insiden besar, atau siklus pengujian yang signifikan. Tim dapat belajar dari kesuksesan dan kegagalan serta terus meningkatkan proses dan praktik mereka.
  • Gunakan pendekatan terstruktur seperti model start-stop-continue untuk memastikan sesi retrospektif produktif dan menghasilkan langkah-langkah yang dapat ditindaklanjuti.
  • Gunakan retrospektif untuk mengidentifikasi area tempat otomatisasi pengelolaan perubahan dapat ditingkatkan lebih lanjut untuk meningkatkan keandalan dan mengurangi risiko.

Menumbuhkan budaya belajar

Budaya belajar memfasilitasi eksplorasi teknologi baru yang aman di Google Cloud, seperti kemampuan AI dan ML untuk meningkatkan layanan seperti deteksi penipuan dan saran keuangan yang dipersonalisasi. Untuk mempromosikan budaya belajar, lakukan hal berikut:

  • Dorong tim untuk bereksperimen, berbagi pengetahuan, dan terus belajar.
  • Menerapkan budaya tanpa menyalahkan, di mana kegagalan dipandang sebagai peluang untuk tumbuh dan berkembang.
  • Ciptakan lingkungan yang aman secara psikologis yang memungkinkan tim mengambil risiko dan mempertimbangkan solusi inovatif. Tim belajar dari kesuksesan dan kegagalan, yang menghasilkan organisasi yang lebih tangguh dan mudah beradaptasi.
  • Kembangkan budaya yang memfasilitasi berbagi pengetahuan yang diperoleh dari proses manajemen insiden dan latihan pengujian.

Selalu dapatkan info terkini tentang teknologi cloud

Pembelajaran berkelanjutan sangat penting untuk memahami dan menerapkan langkah-langkah keamanan baru, memanfaatkan analisis data tingkat lanjut untuk mendapatkan insight yang lebih baik, dan mengadopsi solusi inovatif yang relevan dengan industri keuangan.

  • Maksimalkan potensi layanan Google Cloud dengan terus mendapatkan informasi tentang perkembangan, fitur, dan praktik terbaik terbaru.
  • Saat fitur dan layanan baru diperkenalkan, identifikasi peluang untuk mengotomatiskan lebih lanjut proses, meningkatkan keamanan, serta meningkatkan performa dan skalabilitas aplikasi Anda. Google Cloud
  • Berpartisipasilah dalam konferensi, webinar, dan sesi pelatihan yang relevan untuk memperluas pengetahuan dan memahami kemampuan baru.
  • Dorong anggota tim untuk mendapatkan Google Cloud sertifikasi untuk membantu memastikan bahwa organisasi memiliki keterampilan yang diperlukan agar berhasil di cloud.

Perspektif FSI: Keamanan, privasi, dan kepatuhan

Dokumen dalam Google Cloud Framework yang Dirancang dengan Baik: Perspektif FSI ini memberikan ringkasan prinsip dan rekomendasi untuk memenuhi persyaratan keamanan, privasi, dan kepatuhan workload industri jasa keuangan (FSI) di Google Cloud. Rekomendasi ini membantu Anda membangun infrastruktur yang tangguh dan sesuai, melindungi data sensitif, mempertahankan kepercayaan pelanggan, memahami lanskap kompleks persyaratan peraturan, dan mengelola ancaman siber secara efektif. Rekomendasi dalam dokumen ini selaras dengan pilar keamanan dari Framework yang Dirancang dengan Baik.

Keamanan dalam komputasi awan adalah masalah penting bagi organisasi FSI, yang sangat menarik bagi penjahat siber karena banyaknya data sensitif yang mereka kelola, termasuk detail pelanggan dan catatan keuangan. Konsekuensi pelanggaran keamanan sangat berat, termasuk kerugian finansial yang signifikan, kerusakan reputasi jangka panjang, dan denda peraturan yang signifikan. Oleh karena itu, workload FSI memerlukan kontrol keamanan yang ketat.

Untuk membantu memastikan keamanan dan kepatuhan yang komprehensif, Anda perlu memahami tanggung jawab bersama antara Anda (organisasi FSI) dan Google Cloud. Google Cloud bertanggung jawab untuk mengamankan infrastruktur dasar, termasuk keamanan fisik dan keamanan jaringan. Anda bertanggung jawab untuk mengamankan data dan aplikasi, mengonfigurasi kontrol akses, serta mengonfigurasi dan mengelola layanan keamanan. Untuk mendukung upaya keamanan Anda, Google Cloud ekosistem partner menawarkan integrasi keamanan dan layanan terkelola.

Rekomendasi keamanan dalam dokumen ini dipetakan ke prinsip inti berikut:

Menerapkan keamanan dari desain

Peraturan keuangan seperti Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS), Gramm-Leach-Bliley Act (GLBA) di Amerika Serikat, dan berbagai hukum perlindungan data keuangan nasional mewajibkan keamanan diintegrasikan ke dalam sistem sejak awal. Prinsip keamanan berdasarkan desain menekankan integrasi keamanan di seluruh siklus proses pengembangan untuk membantu memastikan bahwa kerentanan diminimalkan sejak awal.

Untuk menerapkan prinsip keamanan berdasarkan desain untuk workload FSI Anda di Google Cloud, pertimbangkan rekomendasi berikut:

  • Pastikan hanya izin yang diperlukan yang diberikan dengan menerapkan prinsip hak istimewa terendah melalui kontrol akses berbasis peran (RBAC) terperinci di Identity and Access Management (IAM). Penggunaan RBAC adalah persyaratan utama dalam banyak peraturan keuangan.
  • Terapkan perimeter keamanan di sekitar layanan dan data sensitif Anda dalam Google Cloud dengan menggunakan Kontrol Layanan VPC. Perimeter keamanan membantu menyegmentasikan dan melindungi data serta resource sensitif, serta membantu mencegah pemindahan data yang tidak sah dan akses yang tidak sah, sebagaimana diwajibkan oleh peraturan.
  • Tentukan konfigurasi keamanan sebagai kode dengan menggunakan alat infrastructure as code (IaC) seperti Terraform. Pendekatan ini menyematkan kontrol keamanan sejak fase deployment awal, yang membantu memastikan konsistensi dan kemampuan audit.
  • Pindai kode aplikasi Anda dengan mengintegrasikan Pengujian Keamanan Aplikasi Statis (SAST) ke dalam pipeline CI/CD dengan Cloud Build. Buat gerbang keamanan otomatis untuk mencegah deployment kode yang tidak sesuai.
  • Menyediakan antarmuka terpadu untuk insight keamanan dengan menggunakan Security Command Center. Penggunaan Security Command Center memungkinkan pemantauan berkelanjutan dan deteksi dini kesalahan konfigurasi atau ancaman yang dapat menyebabkan pelanggaran peraturan. Untuk memenuhi persyaratan standar seperti ISO 27001 dan NIST 800-53, Anda dapat menggunakan template pengelolaan postur.
  • Lacak pengurangan kerentanan yang diidentifikasi dalam deployment produksi dan persentase deployment IaC yang mematuhi praktik terbaik keamanan. Anda dapat mendeteksi dan melihat kerentanan serta informasi tentang kepatuhan terhadap standar keamanan menggunakan Security Command Center. Untuk mengetahui informasi selengkapnya, lihat Temuan kerentanan.

Menerapkan zero trust

Peraturan keuangan modern semakin menekankan perlunya kontrol akses yang ketat dan verifikasi berkelanjutan. Persyaratan ini mencerminkan prinsip zero trust, yang bertujuan untuk melindungi workload dari ancaman internal dan eksternal serta pelaku kejahatan. Prinsip zero-trust menganjurkan verifikasi berkelanjutan setiap pengguna dan perangkat, yang menghilangkan kepercayaan implisit dan memitigasi pergerakan lateral.

Untuk menerapkan zero trust, pertimbangkan rekomendasi berikut:

  • Aktifkan akses kontekstual berdasarkan identitas pengguna, keamanan perangkat, lokasi, dan faktor lainnya dengan menggabungkan kontrol IAM dengan Chrome Enterprise Premium. Pendekatan ini memastikan verifikasi berkelanjutan sebelum akses ke data dan sistem keuangan diberikan.
  • Menyediakan pengelolaan identitas dan akses yang aman dan skalabel dengan mengonfigurasi Identity Platform (atau penyedia identitas eksternal Anda jika Anda menggunakan Workforce Identity Federation). Siapkan autentikasi multi-faktor (MFA) dan kontrol lainnya yang sangat penting untuk menerapkan zero trust dan membantu memastikan kepatuhan terhadap peraturan.
  • Terapkan MFA untuk semua akun pengguna, terutama untuk akun yang memiliki akses ke data atau sistem sensitif.
  • Mendukung audit dan investigasi terkait kepatuhan terhadap peraturan dengan membuat logging dan pemantauan komprehensif terhadap akses pengguna dan aktivitas jaringan.
  • Aktifkan komunikasi pribadi dan aman antar-layanan dalam lingkunganGoogle Cloud dan lokal tanpa mengekspos traffic ke internet publik menggunakan Private Service Connect.
  • Terapkan kontrol identitas terperinci dan berikan otorisasi akses di tingkat aplikasi menggunakan Identity-Aware Proxy (IAP), bukan mengandalkan mekanisme keamanan berbasis jaringan seperti tunnel VPN. Pendekatan ini membantu mengurangi pergerakan lateral dalam lingkungan.

Menerapkan keamanan shift-left

Regulator keuangan mendorong tindakan keamanan proaktif. Mengidentifikasi dan mengatasi kerentanan di awal siklus proses pengembangan membantu mengurangi risiko insiden keamanan dan potensi penalti akibat ketidakpatuhan. Prinsip keamanan shift-left mendorong pengujian dan integrasi keamanan awal, yang membantu mengurangi biaya dan kompleksitas perbaikan.

Untuk menerapkan keamanan shift-left, pertimbangkan rekomendasi berikut:

  • Pastikan pemeriksaan keamanan otomatis di awal proses pengembangan dengan mengintegrasikan alat pemindaian keamanan, seperti pemindaian kerentanan container dan analisis kode statis, ke dalam pipeline CI/CD dengan Cloud Build.

  • Pastikan hanya artefak yang aman yang di-deploy dengan menggunakan Artifact Registry untuk menyediakan repositori yang aman dan terpusat untuk paket software dan image container dengan pemindaian kerentanan terintegrasi. Gunakan repositori virtual untuk memitigasi serangan kebingungan dependensi dengan memprioritaskan artefak pribadi Anda daripada repositori jarak jauh.

  • Memindai aplikasi web secara otomatis untuk mencari kerentanan umum dengan mengintegrasikan Web Security Scanner, yang merupakan bagian dari Security Command Center, ke dalam pipeline pengembangan Anda.

  • Terapkan pemeriksaan keamanan untuk kode sumber, proses build, dan asal kode dengan menggunakan framework Supply-chain Levels for Software Artifacts (SLSA). Terapkan asal-usul workload yang berjalan di lingkungan Anda dengan menggunakan solusi seperti Otorisasi Biner. Pastikan beban kerja Anda hanya menggunakan library software open source terverifikasi dengan menggunakan Assured Open Source.

  • Lacak jumlah kerentanan yang diidentifikasi dan diperbaiki dalam siklus proses pengembangan Anda, persentase deployment kode yang lulus pemindaian keamanan, dan pengurangan insiden keamanan yang disebabkan oleh kerentanan software. Google Cloud menyediakan alat untuk membantu pelacakan ini untuk berbagai jenis beban kerja. Misalnya, untuk beban kerja dalam container, gunakan fitur pemindaian container Artifact Registry.

Menerapkan pertahanan cyber preventif

Lembaga keuangan adalah target utama serangan cyber canggih. Peraturan sering kali memerlukan mekanisme pertahanan proaktif dan intelijen ancaman yang andal. Pertahanan siber preventif berfokus pada deteksi dan respons ancaman proaktif menggunakan analisis dan otomatisasi tingkat lanjut.

Pertimbangkan rekomendasi berikut:

  • Identifikasi dan mitigasi potensi ancaman secara proaktif, dengan menggunakan layanan kecerdasan ancaman, respons insiden, dan validasi keamanan dari Mandiant.
  • Lindungi aplikasi web dan API dari eksploitasi web dan serangan DDoS di edge jaringan dengan menggunakan Google Cloud Armor.
  • Gabungkan dan prioritaskan temuan dan rekomendasi keamanan menggunakan Security Command Center, yang memungkinkan tim keamanan mengatasi potensi risiko secara proaktif.
  • Validasi pertahanan preventif dan rencana respons insiden dengan melakukan simulasi keamanan dan uji penetrasi secara rutin.
  • Ukur waktu untuk mendeteksi dan merespons insiden keamanan, efektivitas upaya mitigasi DDoS, dan jumlah serangan siber yang berhasil dicegah. Anda bisa mendapatkan metrik dan data yang diperlukan dari dasbor SOAR dan SIEM Google Security Operations.

Menggunakan AI secara aman dan bertanggung jawab, serta menggunakan AI untuk keamanan

AI dan ML semakin banyak digunakan untuk kasus penggunaan layanan keuangan seperti deteksi penipuan dan perdagangan algoritma. Peraturan mewajibkan agar teknologi ini digunakan secara etis, transparan, dan aman. AI juga dapat membantu meningkatkan kemampuan keamanan Anda. Pertimbangkan rekomendasi berikut untuk menggunakan AI:

  • Kembangkan dan deploy model ML di lingkungan yang aman dan diatur dengan menggunakan Vertex AI. Fitur seperti penjelasan model dan metrik keadilan dapat membantu mengatasi masalah terkait AI bertanggung jawab.
  • Manfaatkan kemampuan analisis dan operasi keamanan Google Security Operations, yang menggunakan AI dan ML untuk menganalisis data keamanan dalam volume besar, mendeteksi anomali, dan mengotomatiskan respons ancaman. Kemampuan ini membantu meningkatkan kondisi keamanan Anda secara keseluruhan dan membantu pemantauan kepatuhan.
  • Tetapkan kebijakan tata kelola yang jelas untuk pengembangan dan deployment AI dan ML, termasuk pertimbangan terkait keamanan dan etika.
  • Selaras dengan elemen Secure AI Framework (SAIF), yang memberikan pendekatan praktis untuk mengatasi masalah keamanan dan risiko sistem AI.
  • Lacak akurasi dan efektivitas sistem deteksi penipuan berteknologi AI, pengurangan positif palsu dalam pemberitahuan keamanan, dan peningkatan efisiensi dari otomatisasi keamanan berbasis AI.

Memenuhi kebutuhan peraturan, kepatuhan, dan privasi

Layanan keuangan tunduk pada berbagai peraturan, termasuk persyaratan residensi data, jalur audit tertentu, dan standar perlindungan data. Untuk memastikan bahwa data sensitif diidentifikasi, dilindungi, dan dikelola dengan benar, organisasi FSI memerlukan kebijakan tata kelola data yang kuat dan skema klasifikasi data. Pertimbangkan rekomendasi berikut untuk membantu Anda memenuhi persyaratan peraturan:

  • Siapkan batas data di Google Cloud untuk workload sensitif dan teregulasi dengan menggunakan Assured Workloads. Dengan melakukannya, Anda dapat memenuhi persyaratan kepatuhan khusus pemerintah dan industri seperti FedRAMP dan CJIS.
  • Identifikasi, klasifikasikan, dan lindungi data sensitif, termasuk informasi keuangan, dengan menerapkan Cloud Data Loss Prevention (Cloud DLP). Tindakan ini membantu Anda mematuhi peraturan privasi data seperti GDPR dan CCPA.
  • Lacak detail aktivitas administratif dan akses ke resource dengan menggunakan Cloud Audit Logs. Log ini sangat penting untuk memenuhi persyaratan audit yang ditetapkan oleh banyak peraturan keuangan.
  • Saat Anda memilih Google Cloud region untuk beban kerja dan data Anda, pertimbangkan peraturan setempat yang terkait dengan residensi data. Google Cloud Infrastruktur global memungkinkan Anda memilih region yang dapat membantu Anda memenuhi persyaratan residensi data.
  • Kelola kunci yang digunakan untuk mengenkripsi data keuangan sensitif dalam penyimpanan dan dalam pengiriman menggunakan Cloud Key Management Service. Enkripsi semacam ini adalah persyaratan mendasar dari banyak peraturan keamanan dan privasi.
  • Terapkan kontrol yang diperlukan untuk memenuhi persyaratan peraturan Anda. Validasi bahwa kontrol berfungsi seperti yang diharapkan. Dapatkan validasi ulang kontrol oleh auditor eksternal untuk membuktikan kepada badan pengatur bahwa beban kerja Anda mematuhi peraturan.

Memprioritaskan inisiatif keamanan

Mengingat luasnya persyaratan keamanan, lembaga keuangan harus memprioritaskan inisiatif yang didasarkan pada penilaian risiko dan mandat peraturan. Sebaiknya gunakan pendekatan bertahap berikut:

  1. Membangun fondasi keamanan yang kuat: Berfokus pada area inti keamanan, termasuk pengelolaan identitas dan akses, keamanan jaringan, serta perlindungan data. Fokus ini membantu membangun postur keamanan yang kuat dan membantu memastikan pertahanan yang komprehensif terhadap ancaman yang terus berkembang.
  2. Menangani peraturan penting: Prioritaskan kepatuhan terhadap peraturan utama seperti PCI DSS, GDPR, dan hukum nasional yang relevan. Tindakan ini membantu memastikan perlindungan data, mengurangi risiko hukum, dan membangun kepercayaan dengan pelanggan.
  3. Menerapkan keamanan tingkat lanjut: Terapkan praktik keamanan tingkat lanjut secara bertahap seperti zero trust, solusi keamanan berbasis AI, dan perburuan ancaman proaktif.

Perspektif FSI: Keandalan

Dokumen dalam Google Cloud Framework yang Dirancang dengan Baik: Perspektif FSI memberikan ringkasan prinsip dan rekomendasi untuk mendesain, men-deploy, dan mengoperasikan beban kerja industri jasa keuangan (FSI) yang andal di Google Cloud. Dokumen ini membahas cara mengintegrasikan praktik keandalan dan kemampuan observasi tingkat lanjut ke dalam cetak biru arsitektur Anda. Rekomendasi dalam dokumen ini selaras dengan pilar keandalan dari Framework yang Dirancang dengan Baik.

Bagi lembaga keuangan, infrastruktur yang andal dan tangguh merupakan kebutuhan bisnis sekaligus keharusan peraturan. Untuk memastikan workload FSI di Google Cloud dapat diandalkan, Anda harus memahami dan mengurangi potensi titik kegagalan, men-deploy resource secara redundan, dan merencanakan pemulihan. Ketahanan operasional adalah hasil dari keandalan. Resiliensi adalah kemampuan untuk menyerap, beradaptasi dengan, dan pulih dari gangguan. Ketahanan operasional membantu organisasi FSI memenuhi persyaratan peraturan yang ketat. Hal ini juga membantu menghindari bahaya yang tidak dapat ditoleransi bagi pelanggan.

Elemen penyusun keandalan utama di Google Cloud adalah region, zona, dan berbagai cakupan lokasi resource cloud: zona, regional, multi-regional, global. Anda dapat meningkatkan ketersediaan dengan menggunakan layanan terkelola, mendistribusikan resource, menerapkan pola ketersediaan tinggi, dan mengotomatiskan proses.

Persyaratan peraturan

Organisasi FSI beroperasi berdasarkan mandat keandalan yang ketat dari lembaga pengatur seperti Federal Reserve System di Amerika Serikat, European Banking Authority di Uni Eropa, dan Prudential Regulation Authority di Inggris Raya. Secara global, badan pengatur menekankan ketahanan operasional, yang sangat penting bagi stabilitas keuangan dan perlindungan konsumen. Ketahanan operasional adalah kemampuan untuk menahan gangguan, memulihkan diri secara efektif, dan mempertahankan layanan penting. Hal ini memerlukan pendekatan yang terpadu untuk mengelola risiko teknologi dan ketergantungan pada pihak ketiga.

Persyaratan peraturan di sebagian besar wilayah hukum memiliki tema umum berikut:

  • Keamanan siber dan ketahanan teknologi: Memperkuat pertahanan terhadap ancaman siber dan memastikan ketahanan sistem IT.
  • Pengelolaan risiko pihak ketiga: Mengelola risiko yang terkait dengan meng-outsource layanan kepada penyedia teknologi informasi dan komunikasi (ICT).
  • Kelangsungan bisnis dan respons insiden: Perencanaan yang andal untuk mempertahankan operasi penting selama gangguan dan untuk memulihkan secara efektif.
  • Melindungi stabilitas keuangan: Memastikan kesehatan dan stabilitas sistem keuangan secara keseluruhan.

Rekomendasi keandalan dalam dokumen ini dipetakan ke prinsip inti berikut:

Membuat prioritas deployment multi-zona dan multi-region

Untuk aplikasi layanan keuangan yang penting, sebaiknya gunakan topologi multi-region yang didistribusikan di setidaknya dua region dan di tiga zona dalam setiap region. Pendekatan ini penting untuk ketahanan terhadap pemadaman layanan zona dan region. Peraturan sering kali menetapkan pendekatan ini, karena jika terjadi kegagalan di satu zona atau region, sebagian besar yurisdiksi menganggap gangguan parah pada zona kedua sebagai konsekuensi yang mungkin terjadi. Alasannya adalah jika satu lokasi gagal, lokasi lainnya mungkin menerima jumlah traffic tambahan yang sangat tinggi.

Pertimbangkan rekomendasi berikut untuk membangun ketahanan terhadap pemadaman layanan zona dan region:

  • Lebih memilih resource yang memiliki cakupan lokasi yang lebih luas. Jika memungkinkan, gunakan resource regional, bukan resource zona, dan gunakan resource multiregional atau global, bukan resource regional. Pendekatan ini membantu menghindari kebutuhan untuk memulihkan operasi dengan menggunakan cadangan.
  • Di setiap region, manfaatkan tiga zona, bukan dua. Untuk menangani pengalihan, sediakan kapasitas sepertiga lebih banyak dari perkiraan.
  • Minimalkan langkah-langkah pemulihan manual dengan menerapkan deployment aktif-aktif seperti contoh berikut:
    • Database terdistribusi seperti Spanner menyediakan redundansi dan sinkronisasi bawaan di seluruh region.
    • Fitur HA Cloud SQL menyediakan topologi yang hampir aktif-aktif, dengan replika baca di seluruh zona. Layanan ini memberikan tujuan titik pemulihan (RPO) antar-region yang mendekati 0.
  • Mendistribusikan traffic pengguna di seluruh region dengan menggunakan Cloud DNS, dan men-deploy load balancer regional di setiap region. Load balancer global adalah opsi lain yang dapat Anda pertimbangkan, bergantung pada persyaratan dan tingkat kekritisan Anda. Untuk mengetahui informasi selengkapnya, lihat Manfaat dan risiko load balancing global untuk deployment multi-region.
  • Untuk menyimpan data, gunakan layanan multi-region seperti Spanner dan Cloud Storage.

Menghilangkan titik tunggal kegagalan

Distribusikan resource di berbagai lokasi dan gunakan resource redundan untuk mencegah satu titik kegagalan (SPOF) memengaruhi seluruh stack aplikasi.

Pertimbangkan rekomendasi berikut untuk menghindari SPOF:

  • Hindari men-deploy hanya satu server aplikasi atau database.
  • Pastikan pembuatan ulang VM yang gagal secara otomatis dengan menggunakan grup instance terkelola (MIG).
  • Mendistribusikan traffic secara merata di seluruh resource yang tersedia dengan menerapkan load balancing.
  • Gunakan konfigurasi HA untuk database seperti Cloud SQL.
  • Tingkatkan ketersediaan data dengan menggunakan persistent disk regional dengan replikasi sinkron.

Untuk mengetahui informasi selengkapnya, lihat Mendesain infrastruktur yang andal untuk workload Anda di Google Cloud.

Memahami dan mengelola ketersediaan gabungan

Perhatikan bahwa ketersediaan keseluruhan atau gabungan sistem dipengaruhi oleh ketersediaan setiap tingkat atau komponen sistem. Jumlah tingkat dalam stack aplikasi memiliki hubungan terbalik dengan ketersediaan stack gabungan. Pertimbangkan rekomendasi berikut untuk mengelola ketersediaan gabungan:

  • Hitung ketersediaan gabungan stack multi-tingkat menggunakan formula tier1_availability × tier2_availability × tierN_availability.

    Diagram berikut menunjukkan penghitungan ketersediaan gabungan untuk sistem multi-tingkat yang terdiri dari empat layanan:

    Formula ketersediaan gabungan untuk layanan multi-tingkat yang memiliki empat layanan.

    Dalam diagram sebelumnya, layanan di setiap tingkat memberikan ketersediaan 99,9%, tetapi ketersediaan gabungan sistem lebih rendah, yaitu 99,6% (0,999 × 0,999 × 0,999 × 0,999). Secara umum, ketersediaan gabungan stack multi-tingkat lebih rendah daripada ketersediaan tingkat yang memberikan ketersediaan terendah.

  • Jika memungkinkan, pilih paralelisasi daripada penggabungan. Dengan layanan yang diparalelkan, ketersediaan end-to-end lebih tinggi daripada ketersediaan setiap layanan individual.

    Diagram berikut menunjukkan dua layanan, A dan B, yang di-deploy dengan menggunakan pendekatan penggabungan dan paralelisme:

    Formula ketersediaan gabungan untuk layanan berantai dibandingkan dengan layanan yang diparalelkan.

    Dalam contoh sebelumnya, kedua layanan memiliki SLA 99%, yang menghasilkan ketersediaan gabungan berikut, bergantung pada pendekatan penerapan:

    • Layanan berantai menghasilkan ketersediaan gabungan hanya 98% (.99 × .99).
    • Layanan yang diparalelkan menghasilkan ketersediaan gabungan yang lebih tinggi sebesar 99,99% karena setiap layanan berjalan secara independen dan setiap layanan tidak terpengaruh oleh ketersediaan layanan lainnya. Formula untuk layanan paralel gabungan adalah 1 − (1 − A) × (1 − B).

  • Pilih Google Cloud layanan dengan SLA waktu aktif yang dapat membantu memenuhi tingkat waktu aktif keseluruhan yang diperlukan untuk tumpukan aplikasi Anda.

  • Saat mendesain arsitektur, pertimbangkan kompromi antara ketersediaan, kompleksitas operasional, latensi, dan biaya. Meningkatkan jumlah sembilan ketersediaan umumnya memerlukan biaya lebih besar, tetapi tindakan ini membantu Anda memenuhi persyaratan peraturan.

    Misalnya, ketersediaan 99,9% (tiga sembilan) berarti potensi periode nonaktif selama 86 detik dalam satu hari 24 jam. Sebaliknya, 99% (dua sembilan) berarti periode nonaktif 864 detik selama periode yang sama, yang 10 kali lebih banyak daripada periode nonaktif dengan ketersediaan tiga sembilan.

    Untuk layanan keuangan penting, opsi arsitektur mungkin terbatas. Namun, penting untuk mengidentifikasi persyaratan ketersediaan dan menghitung ketersediaan secara akurat. Melakukan penilaian seperti ini membantu Anda menilai implikasi keputusan desain terhadap arsitektur dan anggaran Anda.

Menerapkan strategi DR yang andal

Buat rencana yang jelas untuk berbagai skenario bencana, termasuk gangguan tingkat zona dan regional. Strategi pemulihan dari bencana (DR) yang jelas memungkinkan Anda memulihkan diri dari gangguan dan melanjutkan operasi normal dengan dampak minimal.

DR dan ketersediaan tinggi (HA) adalah konsep yang berbeda. Dengan deployment cloud, secara umum, DR berlaku untuk deployment multi-region dan HA berlaku untuk deployment regional. Arketipe deployment ini mendukung mekanisme replikasi yang berbeda.

  • HA: Banyak layanan terkelola menyediakan replikasi sinkron antara zona dalam satu region secara default. Layanan tersebut mendukung batas waktu pemulihan (RTO) dan toleransi jumlah data yang hilang (RPO) nol atau mendekati nol. Dukungan ini memungkinkan Anda membuat topologi deployment aktif-aktif yang tidak memiliki SPOF.
  • DR: Untuk workload yang di-deploy di dua region atau lebih, jika Anda tidak menggunakan layanan multi-region atau global, Anda harus menentukan strategi replikasi. Strategi replikasi biasanya bersifat asinkron. Menilai dengan cermat bagaimana replikasi tersebut memengaruhi RTO dan RPO untuk aplikasi penting. Identifikasi operasi manual atau semi-otomatis yang diperlukan untuk failover.

Untuk lembaga keuangan, pilihan region failover Anda mungkin dibatasi oleh peraturan tentang kedaulatan data dan residensi data. Jika Anda memerlukan topologi aktif-aktif di dua region, sebaiknya pilih layanan multi-regional terkelola, seperti Spanner dan Cloud Storage, terutama saat replikasi data sangat penting.

Pertimbangkan rekomendasi berikut:

  • Gunakan layanan penyimpanan multiregional terkelola untuk data.
  • Ambil snapshot data di persistent disk dan simpan snapshot di lokasi multi-region.
  • Saat Anda menggunakan resource regional atau zona, siapkan replikasi data ke region lain.
  • Pastikan rencana DR Anda efektif dengan menguji rencana tersebut secara rutin.
  • Pahami RTO dan RPO serta korelasinya dengan toleransi dampak yang ditetapkan oleh peraturan keuangan di wilayah hukum Anda.

Untuk mengetahui informasi selengkapnya, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud.

Memanfaatkan layanan terkelola

Jika memungkinkan, gunakan layanan terkelola untuk memanfaatkan fitur bawaan untuk pencadangan, HA, dan skalabilitas. Pertimbangkan rekomendasi berikut untuk menggunakan layanan terkelola:

  • Menggunakan layanan terkelola di Google Cloud. Layanan ini menyediakan HA yang didukung oleh SLA. Layanan ini juga menawarkan mekanisme pencadangan bawaan dan fitur ketahanan.
  • Untuk pengelolaan data, pertimbangkan layanan seperti Cloud SQL, Cloud Storage, dan Spanner,
  • Untuk komputasi dan hosting aplikasi, pertimbangkan grup instance terkelola (MIG) Compute Engine dan cluster Google Kubernetes Engine (GKE). MIG regional dan cluster regional GKE tahan terhadap pemadaman zona.
  • Untuk meningkatkan ketahanan terhadap pemadaman layanan region, gunakan layanan multi-regional terkelola.
  • Identifikasi kebutuhan rencana keluar untuk layanan yang memiliki karakteristik unik dan tentukan rencana yang diperlukan. Regulator keuangan seperti FCA, PRA, dan EBA mewajibkan perusahaan memiliki strategi dan rencana darurat untuk pengambilan data dan kelangsungan operasional jika hubungan dengan penyedia cloud berakhir. Perusahaan harus menilai kelayakan keluar sebelum menandatangani kontrak cloud dan harus mempertahankan kemampuan untuk mengganti penyedia tanpa gangguan operasional.
  • Pastikan layanan yang Anda pilih mendukung ekspor data ke format terbuka seperti CSV, Parquet, dan Avro. Verifikasi apakah layanan tersebut didasarkan pada teknologi terbuka, seperti dukungan GKE untuk format Open Container Initiative (OCI) atau Cloud Composer yang dibangun di Apache Airflow.

Mengotomatiskan proses penyediaan dan pemulihan infrastruktur

Otomatisasi membantu meminimalkan kesalahan manusia dan membantu mengurangi waktu dan resource yang diperlukan untuk merespons insiden. Penggunaan otomatisasi dapat membantu memastikan pemulihan yang lebih cepat dari kegagalan dan hasil yang lebih konsisten. Pertimbangkan rekomendasi berikut untuk mengotomatiskan cara Anda menyediakan dan memulihkan resource:

  • Minimalkan kesalahan manusia dengan menggunakan alat Infrastructure as Code (IaC) seperti Terraform.
  • Kurangi intervensi manual dengan mengotomatiskan proses failover. Respons otomatis juga dapat membantu mengurangi dampak kegagalan. Misalnya, Anda dapat menggunakan Eventarc atau Workflows untuk memicu tindakan perbaikan secara otomatis sebagai respons terhadap masalah yang diamati melalui log audit.
  • Tingkatkan kapasitas resource cloud Anda selama failover menggunakan penskalaan otomatis.
  • Terapkan kebijakan dan pelindung secara otomatis untuk persyaratan peraturan di seluruh topologi cloud Anda selama deployment layanan dengan menerapkan platform engineering.

Perspektif FSI: Pengoptimalan biaya

Dokumen dalam Google Cloud Framework yang Dirancang dengan Baik: Perspektif FSI ini memberikan ringkasan prinsip dan rekomendasi untuk mengoptimalkan biaya workload industri jasa keuangan (FSI) Anda di Google Cloud. Rekomendasi dalam dokumen ini selaras dengan pilar pengoptimalan biaya dari Framework yang Dirancang dengan Baik.

Pengoptimalan biaya yang andal untuk workload layanan keuangan memerlukan elemen mendasar berikut:

  • Kemampuan untuk mengidentifikasi pemanfaatan resource yang boros versus yang mendorong nilai.
  • Budaya akuntabilitas keuangan yang tertanam.

Untuk mengoptimalkan biaya, Anda memerlukan pemahaman yang komprehensif tentang pendorong biaya dan kebutuhan resource di seluruh organisasi Anda. Di beberapa organisasi besar, terutama yang baru memulai perjalanan cloud, satu tim sering kali bertanggung jawab untuk mengoptimalkan pembelanjaan di sejumlah besar domain. Pendekatan ini mengasumsikan bahwa tim pusat adalah pihak yang paling tepat untuk mengidentifikasi peluang bernilai tinggi guna meningkatkan efisiensi.

Pendekatan terpusat mungkin berhasil pada tahap awal adopsi cloud atau untuk workload non-kritis. Namun, satu tim tidak dapat mendorong pengoptimalan biaya di seluruh organisasi. Jika penggunaan resource atau tingkat pengawasan peraturan meningkat, pendekatan terpusat tidak akan berkelanjutan. Tim terpusat menghadapi tantangan skalabilitas, terutama saat menangani sejumlah besar produk dan layanan keuangan. Tim project yang memiliki produk dan layanan mungkin menolak perubahan yang dilakukan oleh tim eksternal.

Untuk pengoptimalan biaya yang efektif, data terkait pembelanjaan harus sangat terlihat, dan para engineer serta pengguna cloud lainnya yang dekat dengan beban kerja harus termotivasi untuk mengambil tindakan guna mengoptimalkan biaya. Dari sudut pandang organisasi, tantangan untuk pengoptimalan biaya adalah mengidentifikasi area yang harus dioptimalkan, mengidentifikasi engineer yang bertanggung jawab atas area tersebut, lalu meyakinkan mereka untuk mengambil tindakan pengoptimalan yang diperlukan. Dokumen ini memberikan rekomendasi untuk mengatasi tantangan ini.

Rekomendasi pengoptimalan biaya dalam dokumen ini dipetakan ke prinsip inti berikut:

Mengidentifikasi limbah menggunakan alat Google Cloud

Google Cloud menyediakan beberapa produk, alat, dan fitur untuk membantu Anda mengidentifikasi pemborosan. Pertimbangkan rekomendasi berikut.

Gunakan otomatisasi dan AI untuk mengidentifikasi secara sistematis hal yang perlu dioptimalkan

Active Assist memberikan rekomendasi cerdas di seluruh layanan yang penting bagi FSI, seperti Cloud Run untuk mikroservice, BigQuery untuk analisis data, Compute Engine untuk aplikasi inti, dan Cloud SQL untuk database relasional. Rekomendasi Active Assist diberikan tanpa biaya dan tanpa konfigurasi apa pun oleh Anda. Rekomendasi ini membantu Anda mengidentifikasi sumber daya yang tidak digunakan dan komitmen yang kurang dimanfaatkan.

Memusatkan pemantauan dan kontrol FinOps melalui antarmuka terpadu

Laporan Penagihan Cloud dan hub FinOps memungkinkan Anda menerapkan pemantauan biaya yang komprehensif. Tampilan komprehensif ini sangat penting bagi auditor keuangan dan tim keuangan internal untuk melacak pembelanjaan cloud, menilai postur keuangan, mengevaluasi kematangan FinOps di berbagai unit bisnis atau pusat biaya, dan memberikan narasi keuangan yang konsisten.

Mengidentifikasi nilai dengan menganalisis dan memperkaya data pembelanjaan

Active Assist efektif dalam mengidentifikasi pemborosan yang jelas. Namun, menentukan nilai bisa jadi lebih sulit, terutama saat beban kerja berada di produk yang tidak sesuai atau saat beban kerja tidak memiliki keselarasan yang jelas dengan nilai bisnis. Untuk workload FSI, nilai bisnis melampaui pengurangan biaya. Nilai tersebut mencakup mitigasi risiko, kepatuhan terhadap peraturan, dan memperoleh keunggulan kompetitif.

Untuk memahami pembelanjaan dan nilai cloud secara holistik, Anda memerlukan pemahaman yang menyeluruh di berbagai tingkat: dari mana pembelanjaan berasal, fungsi bisnis apa yang didorong oleh pembelanjaan tersebut, dan kelayakan teknis untuk memfaktorkan ulang atau mengoptimalkan beban kerja yang dimaksud.

Diagram berikut menunjukkan cara Anda dapat menerapkan piramida data-informasi-pengetahuan-kebijaksanaan (DIKW) dan Google Cloud alat untuk mendapatkan pemahaman holistik tentang biaya dan nilai cloud.

Piramida data-informasi-pengetahuan-kebijaksanaan (DIKW) menunjukkan cara menggunakan data pembelanjaan cloud untuk mendukung pengambilan keputusan.

Diagram sebelumnya menunjukkan cara Anda dapat menggunakan pendekatan DIKW untuk menyaring data mentah pembelanjaan cloud menjadi insight dan keputusan yang dapat ditindaklanjuti yang mendorong nilai bisnis.

  • Data: Di lapisan ini, Anda mengumpulkan aliran data penggunaan dan biaya mentah yang belum diproses untuk resource cloud Anda. Tim FinOps pusat Anda menggunakan alat seperti invoice Penagihan Cloud, ekspor penagihan, dan Cloud Monitoring untuk mendapatkan data mendetail yang terperinci. Misalnya, titik data dapat berupa VM bernama app1-test-vmA yang berjalan selama 730 jam di region us-central1 dan dikenai biaya USD 70.
  • Informasi: Di lapisan ini, tim FinOps pusat Anda menggunakan alat seperti laporan Penagihan Cloud dan FinOps Hub untuk menyusun data mentah guna membantu menjawab pertanyaan seperti "Kategori resource apa yang dibelanjakan orang?" Misalnya, Anda mungkin mengetahui bahwa total USD 1.050 telah dibelanjakan untuk VM jenis mesin n4-standard-2 di dua region di AS.
  • Pengetahuan: Di lapisan ini, tim FinOps pusat Anda memperkaya informasi dengan konteks bisnis yang sesuai tentang siapa yang membelanjakan uang dan untuk tujuan apa. Anda menggunakan mekanisme seperti pemberian tag, pemberian label, hierarki resource, akun penagihan, dan dasbor Looker kustom. Misalnya, Anda dapat menentukan bahwa tim pengujian app1 di Amerika Serikat membelanjakan 650 USD selama minggu kedua bulan Juli sebagai bagian dari latihan pengujian beban.
  • Kebijaksanaan (Wisdom): Di lapisan ini, tim produk dan aplikasi Anda menggunakan pengetahuan yang dikontekstualisasi untuk menilai nilai bisnis pembelanjaan cloud dan membuat keputusan strategis yang tepat. Tim Anda dapat menjawab pertanyaan seperti berikut:
    • Apakah Rp50.000.000 yang dibelanjakan untuk pipeline analisis data menghasilkan nilai bisnis?
    • Dapatkah kita merancang ulang pipeline agar lebih efisien tanpa mengurangi performa?

Pertimbangkan rekomendasi berikut untuk menganalisis data pembelanjaan cloud.

Menganalisis data pembelanjaan yang disediakan oleh Google Cloud

Mulai dengan data mendetail Penagihan Cloud yang diekspor ke BigQuery dan data yang tersedia di log Monitoring. Untuk mendapatkan insight yang dapat ditindaklanjuti dan membuat keputusan, Anda perlu menyusun data ini dan memperkayanya dengan konteks bisnis.

Memvisualisasikan data melalui alat yang tersedia

Tingkatkan kualitas dasbor bawaan Google Cloud dengan pelaporan kustom menggunakan alat seperti Looker Studio di atas ekspor BigQuery. Tim keuangan dapat membuat dasbor kustom yang mengontekstualisasikan pembelanjaan cloud terhadap metrik keuangan, persyaratan pelaporan peraturan, dan profitabilitas unit bisnis. Kemudian, mereka dapat memberikan narasi keuangan yang jelas untuk analisis dan pengambilan keputusan oleh pemangku kepentingan eksekutif.

Mengalokasikan pembelanjaan untuk mendorong akuntabilitas

Setelah memahami faktor-faktor yang mendorong pembelanjaan cloud, Anda perlu mengidentifikasi siapa yang membelanjakan uang dan alasannya. Tingkat pemahaman ini memerlukan praktik alokasi biaya yang andal, yang melibatkan pelampiran metadata yang relevan dengan bisnis ke resource cloud. Misalnya, jika resource tertentu digunakan oleh tim Banking-AppDev, Anda dapat melampirkan tag seperti team=banking_appdev ke resource untuk melacak biaya yang dikeluarkan tim untuk resource tersebut. Idealnya, Anda harus mengalokasikan 100% biaya cloud ke sumber pembelanjaan. Dalam praktiknya, Anda dapat memulai dengan target yang lebih rendah karena membangun struktur metadata untuk mendukung alokasi biaya 100% adalah upaya yang kompleks.

Pertimbangkan rekomendasi berikut untuk mengembangkan strategi metadata guna mendukung alokasi biaya:

  • Validitas: Pastikan tag membantu mengidentifikasi indikator performa utama (KPI) terkait bisnis dan persyaratan peraturan. Asosiasi ini sangat penting untuk pengembalian dana internal, pelaporan peraturan, dan menyelaraskan pembelanjaan cloud dengan sasaran unit bisnis. Misalnya, tag berikut mengidentifikasi dengan jelas tim pembelanjaan, region, dan produk yang mereka kerjakan: team=banking_appdev, region=emea, product=frontend.
  • Otomatisasi: Untuk mencapai tingkat kepatuhan pemberian tag yang tinggi, terapkan pemberian tag melalui otomatisasi. Pemberian tag secara manual rentan terhadap error dan inkonsistensi, yang tidak dapat diterima di lingkungan FSI yang mengutamakan auditabilitas dan akurasi keuangan. Pemberian tag otomatis memastikan bahwa resource dikategorikan dengan benar saat dibuat.
  • Kesederhanaan: Mengukur faktor sederhana yang tidak berkorelasi. Lingkungan FSI rumit. Untuk memastikan bahwa aturan alokasi biaya di lingkungan tersebut mudah dipahami dan diterapkan, aturan tersebut harus sesederhana mungkin. Hindari membuat aturan yang terlalu rumit untuk kasus yang sangat spesifik (edge). Aturan yang rumit dapat menyebabkan kebingungan dan penolakan dari tim operasional.

Setelah menentukan strategi alokasi menggunakan tag, Anda harus memutuskan tingkat perincian tempat strategi harus diterapkan. Perincian yang diperlukan bergantung pada kebutuhan bisnis Anda. Misalnya, beberapa organisasi mungkin perlu melacak biaya di tingkat produk, beberapa organisasi mungkin memerlukan data biaya untuk setiap pusat biaya, dan organisasi lainnya mungkin memerlukan data biaya per lingkungan (pengembangan, penyiapan, dan produksi).

Pertimbangkan pendekatan berikut untuk mencapai tingkat perincian alokasi biaya yang sesuai untuk organisasi Anda:

  • Gunakan hierarki project di Google Cloud sebagai titik awal alami untuk alokasi biaya. Project mewakili titik penerapan kebijakan di Google Cloud. Secara default, izin IAM, kebijakan keamanan, dan biaya dikaitkan dengan project dan folder. Saat meninjau data biaya yang diekspor dari Penagihan Cloud, Anda dapat melihat hierarki folder dan project yang terkait dengan data biaya. Jika hierarki resource Anda mencerminkan struktur akuntabilitas organisasi Anda untuk pembelanjaan, maka ini adalah cara paling sederhana untuk menerapkan alokasi biaya.Google Cloud
  • Gunakan tag dan label untuk perincian tambahan. Label memberikan cara yang fleksibel untuk mengategorikan resource dalam hasil ekspor penagihan. Tag dan label memfasilitasi perincian biaya yang mendetail menurut aplikasi dan lingkungan.

Sering kali, Anda mungkin perlu menggunakan hierarki project yang dikombinasikan dengan pemberian tag dan pelabelan untuk alokasi biaya yang efektif. Apa pun pendekatan alokasi biaya yang Anda pilih, ikuti rekomendasi yang dijelaskan sebelumnya untuk mengembangkan strategi metadata yang efektif: validasi, otomatisasi, dan kesederhanaan.

Mendorong akuntabilitas dan memotivasi engineer untuk mengambil tindakan

Tim cloud FinOps bertanggung jawab untuk mendorong organisasi agar sadar akan biaya dan nilai. Setiap tim produk dan tim engineering harus mengambil tindakan yang diperlukan untuk pengoptimalan biaya. Tim ini juga bertanggung jawab atas perilaku biaya workload layanan keuangan dan untuk memastikan bahwa workload mereka memberikan nilai bisnis yang diperlukan.

Pertimbangkan rekomendasi berikut untuk mendorong akuntabilitas dan memotivasi tim agar mengoptimalkan biaya.

Membentuk tim FinOps terpusat untuk tata kelola

Praktik Cloud FinOps tidak berkembang secara organik. Tim FinOps khusus harus menentukan dan menerapkan praktik FinOps dengan melakukan hal berikut:

  • Membangun proses, alat, dan panduan yang diperlukan.
  • Buat, komunikasikan, dan terapkan kebijakan yang diperlukan, seperti pemberian tag wajib, peninjauan anggaran, dan proses pengoptimalan.
  • Mendorong tim engineering untuk bertanggung jawab atas biaya.
  • Campur tangan jika tim engineering tidak bertanggung jawab atas biaya.

Mendapatkan dukungan dan mandat eksekutif

Pimpinan senior, termasuk CTO, CFO, dan CIO, harus secara aktif memperjuangkan peralihan ke budaya FinOps di seluruh organisasi. Dukungan mereka sangat penting untuk memprioritaskan akuntabilitas biaya, mengalokasikan sumber daya untuk program FinOps, memastikan partisipasi lintas fungsi, dan mendorong kepatuhan terhadap persyaratan FinOps.

Memberikan insentif kepada tim untuk mengoptimalkan biaya

Tim engineering dan engineer mungkin tidak termotivasi sendiri untuk berfokus pada pengoptimalan biaya. Penting untuk menyelaraskan tujuan tim dan individu dengan efisiensi biaya dengan menerapkan insentif seperti berikut:

  • Menginvestasikan kembali sebagian penghematan dari pengoptimalan biaya di tim yang mencapai pengoptimalan.
  • Mengakui dan merayakan upaya dan keberhasilan pengoptimalan biaya secara publik.
  • Gunakan teknik gamifikasi untuk memberi penghargaan kepada tim yang secara efektif mengoptimalkan biaya.
  • Mengintegrasikan metrik efisiensi ke dalam sasaran performa.

Menerapkan teknik showback dan chargeback

Pastikan tim memiliki visibilitas yang jelas terhadap resource dan biaya cloud yang mereka miliki. Menetapkan tanggung jawab keuangan kepada individu yang tepat dalam tim. Gunakan mekanisme formal untuk menerapkan pemberian tag yang ketat dan menerapkan aturan transparan untuk mengalokasikan biaya bersama.

Berfokus pada nilai dan TCO, bukan biaya

Saat mengevaluasi solusi cloud, pertimbangkan total biaya kepemilikan (TCO) jangka panjang. Misalnya, menghosting sendiri database untuk aplikasi mungkin tampak lebih murah daripada menggunakan layanan database terkelola seperti Cloud SQL. Namun, untuk menilai nilai jangka panjang dan TCO, Anda harus mempertimbangkan biaya tersembunyi yang terkait dengan database yang dihosting sendiri. Biaya tersebut mencakup upaya engineering khusus untuk patching, penskalaan, penguatan keamanan, dan pemulihan bencana, yang merupakan persyaratan penting untuk workload FSI. Layanan terkelola memberikan nilai jangka panjang yang jauh lebih tinggi, yang mengimbangi biaya infrastruktur. Layanan terkelola memberikan kemampuan kepatuhan yang andal, memiliki fitur keandalan bawaan, dan dapat membantu mengurangi beban operasional Anda.

Pertimbangkan rekomendasi berikut untuk berfokus pada nilai dan TCO.

Menggunakan teknik dan alat khusus produk untuk pengoptimalan resource

Manfaatkan alat dan fitur pengoptimalan biaya yang disediakan oleh produk, seperti berikut: Google Cloud

Manfaatkan diskon

Pastikan tarif penagihan untuk resource cloud Anda serendah mungkin dengan menggunakan diskon yang ditawarkan Google. Tim produk dan engineering masing-masing biasanya mengelola pengoptimalan resource. Tim FinOps pusat bertanggung jawab untuk mengoptimalkan tarif penagihan karena mereka memiliki visibilitas terhadap persyaratan resource di seluruh organisasi. Oleh karena itu, mereka dapat menggabungkan persyaratan dan memaksimalkan diskon berbasis komitmen.

Anda dapat memanfaatkan jenis diskon berikut untuk resource Google Cloud :

  • Diskon perusahaan adalah diskon yang dinegosiasikan berdasarkan komitmen organisasi Anda untuk membelanjakan total minimum Google Cloud di Google Cloud dengan tarif penagihan yang lebih rendah.
  • CUD berbasis resource diberikan sebagai imbalan atas komitmen untuk menggunakan resource Compute Engine dalam jumlah minimum selama periode satu tahun atau tiga tahun. DA berbasis resource berlaku untuk resource yang ada di project dan region tertentu. Untuk membagikan CUD di beberapa project, Anda dapat mengaktifkan berbagi diskon.
  • CUD berbasis pembelanjaan diberikan sebagai imbalan atas komitmen untuk membelanjakan jumlah minimum uang untuk produk tertentu selama periode satu tahun atau tiga tahun. Diskon berbasis pembelanjaan berlaku di tingkat akun penagihan. Diskon diterapkan secara regional atau global, bergantung pada produknya.

Anda dapat memperoleh penghematan yang signifikan dengan menggunakan DA di samping diskon perusahaan.

Selain DA, gunakan pendekatan berikut untuk mengurangi tarif penagihan:

  • Gunakan Spot VM untuk workload yang fault-tolerant dan fleksibel. Spot VM lebih murah lebih dari 80% dibandingkan VM reguler.
  • BigQuery menawarkan beberapa model harga, yang mencakup harga sesuai permintaan dan harga berbasis edisi yang didasarkan pada komitmen dan persyaratan penskalaan otomatis. Jika Anda menggunakan volume resource BigQuery yang signifikan, pilih edisi yang sesuai untuk mengurangi biaya per slot untuk beban kerja analisis.
  • Evaluasi dengan cermat Google Cloud region yang tersedia untuk layanan yang perlu Anda gunakan. Pilih region yang sesuai dengan tujuan biaya Anda dan faktor-faktor seperti latensi dan persyaratan kepatuhan. Untuk memahami kompromi antara biaya, keberlanjutan, dan latensi, gunakan Google Cloud Pemilih Region.

Perspektif FSI: Pengoptimalan performa

Dokumen dalam Google Cloud Framework yang Dirancang dengan Baik: Perspektif FSI ini memberikan ringkasan prinsip dan rekomendasi untuk mengoptimalkan performa workload industri jasa keuangan (FSI) Anda di Google Cloud. Rekomendasi dalam dokumen ini selaras dengan pilar pengoptimalan performa dari Framework yang Dirancang dengan Baik.

Pengoptimalan performa telah lama dilakukan dalam layanan keuangan. Teknologi ini telah membantu organisasi FSI mengatasi tantangan teknis dan hampir selalu menjadi pendorong atau akselerator untuk pembuatan model bisnis baru. Misalnya, ATM (diperkenalkan pada tahun 1967) mengotomatiskan proses pengeluaran uang tunai dan membantu bank mengurangi biaya bisnis inti mereka. Teknik seperti melewati kernel OS dan menyematkan thread aplikasi ke core komputasi membantu mencapai latensi rendah dan deterministik untuk aplikasi perdagangan. Pengurangan latensi memfasilitasi likuiditas yang lebih tinggi dan lebih kuat dengan selisih yang lebih ketat di pasar keuangan.

Cloud menciptakan peluang baru untuk pengoptimalan performa. Hal ini juga menantang beberapa pola pengoptimalan yang diterima secara historis. Secara khusus, pertimbangan berikut lebih transparan dan dapat dikontrol di cloud:

  • Waktu penyiapan produk versus biaya.
  • Performa menyeluruh di tingkat sistem versus performa di tingkat node.
  • Ketersediaan talenta versus fleksibilitas pengambilan keputusan terkait teknologi.

Misalnya, menyesuaikan hardware dan resource IT dengan persyaratan keterampilan tertentu adalah tugas yang mudah di cloud. Untuk mendukung pemrograman GPU, Anda dapat dengan mudah membuat VM berbasis GPU. Anda dapat menskalakan kapasitas di cloud untuk mengakomodasi lonjakan permintaan tanpa menyediakan resource secara berlebihan. Kemampuan ini membantu memastikan bahwa workload Anda dapat menangani beban puncak, seperti pada hari nonfarm payroll dan saat volume perdagangan jauh lebih besar daripada tingkat historis. Daripada menghabiskan waktu untuk menulis kode yang sangat dioptimalkan di tingkat server individual (seperti kode yang sangat disesuaikan dalam bahasa C) atau menulis kode untuk lingkungan komputasi berperforma tinggi (HPC) konvensional, Anda dapat melakukan penskalaan secara optimal dengan menggunakan sistem terdistribusi berbasis Kubernetes yang memiliki arsitektur yang baik.

Rekomendasi pengoptimalan performa dalam dokumen ini dipetakan ke prinsip inti berikut:

Menyelaraskan metrik performa teknologi dengan indikator bisnis utama

Anda dapat memetakan pengoptimalan performa ke hasil nilai bisnis dengan beberapa cara. Misalnya, di meja riset sisi pembelian, tujuan bisnis dapat berupa mengoptimalkan output per jam riset atau memprioritaskan eksperimen dari tim yang memiliki rekam jejak yang terbukti, seperti rasio Sharpe yang lebih tinggi. Di sisi penjualan, Anda dapat menggunakan analisis untuk melacak minat klien dan memprioritaskan throughput ke model AI yang mendukung riset yang paling menarik.

Menghubungkan sasaran performa dengan indikator performa utama (KPI) bisnis juga penting untuk mendanai peningkatan performa. Inisiatif inovasi dan transformasi bisnis (terkadang disebut upaya change-the-bank) memiliki anggaran yang berbeda dan berpotensi memiliki tingkat akses yang berbeda ke sumber daya jika dibandingkan dengan operasi business-as-usual (BAU) atau run-the-bank. Misalnya, Google Cloud membantu tim teknologi dan manajemen risiko dari G-SIFI untuk berkolaborasi dengan analis kuantitatif front office dalam solusi untuk melakukan perhitungan analisis risiko (seperti XVA) dalam hitungan menit, bukan jam atau hari. Solusi ini membantu organisasi memenuhi persyaratan kepatuhan yang relevan. Alat ini juga memungkinkan trader melakukan percakapan berkualitas lebih tinggi dengan klien mereka, yang berpotensi menawarkan selisih yang lebih ketat, likuiditas yang lebih kuat, dan hedging yang lebih hemat biaya.

Saat menyelaraskan metrik performa dengan indikator bisnis, pertimbangkan rekomendasi berikut:

  • Hubungkan setiap inisiatif teknologi dengan tujuan dan hasil utama (OKR) bisnis yang relevan, seperti meningkatkan pendapatan atau laba, mengurangi biaya, dan memitigasi risiko secara lebih efisien atau holistik.
  • Berfokus pada pengoptimalan performa di tingkat sistem. Lihat di luar pemisahan konvensional antara mengubah bank dan mengelola bank serta silo front office versus back office.

Memprioritaskan keamanan tanpa mengorbankan performa untuk risiko yang belum terbukti

Kepatuhan terhadap peraturan dan keamanan di organisasi FSI harus memiliki standar yang tinggi dan tidak diragukan lagi. Mempertahankan standar yang tinggi sangat penting untuk menghindari kehilangan klien dan mencegah kerusakan yang tidak dapat diperbaiki pada merek organisasi. Sering kali, nilai tertinggi diperoleh melalui inovasi teknologi seperti AI generatif dan layanan terkelola yang unik seperti Spanner. Jangan otomatis mengabaikan opsi teknologi tersebut karena kesalahpahaman umum tentang risiko operasional yang sangat tinggi atau postur kepatuhan terhadap peraturan yang tidak memadai.

Google Cloud telah bekerja sama secara erat dengan G-SIFI untuk memastikan bahwa pendekatan berbasis AI untuk Anti-Pencucian Uang (AML) dapat digunakan di seluruh wilayah hukum tempat institusi tersebut melayani pelanggan. Misalnya, HSBC meningkatkan performa unit kejahatan keuangan (Fincrime) secara signifikan dengan hasil sebagai berikut:

  • Hampir dua hingga empat kali lebih banyak aktivitas mencurigakan yang terkonfirmasi.
  • Biaya operasional yang lebih rendah karena penghapusan lebih dari 60% positif palsu dan waktu investigasi yang hanya berfokus pada peringatan berisiko tinggi yang dapat ditindaklanjuti.
  • Hasil yang dapat diaudit dan dapat dijelaskan untuk mendukung kepatuhan terhadap peraturan.

Pertimbangkan rekomendasi berikut:

  • Konfirmasi bahwa produk yang ingin Anda gunakan dapat membantu memenuhi persyaratan keamanan, ketahanan, dan kepatuhan untuk wilayah hukum tempat Anda beroperasi. Untuk mencapai tujuan ini, bekerja samalah dengan tim akun, tim risiko, dan tim produk. Google Cloud
  • Buat model yang lebih canggih dan berikan transparansi kepada pelanggan dengan memanfaatkan kemampuan penjelasan AI (misalnya, atribusi nilai Shapley). Teknik seperti atribusi nilai Shapley dapat mengatribusikan keputusan model ke fitur tertentu di tingkat input.

  • Mencapai transparansi untuk beban kerja AI generatif dengan menggunakan teknik seperti kutipan ke sumber, perujukan, dan RAG.

  • Jika kemampuan penjelasan tidak cukup, pisahkan langkah-langkah pengambilan keputusan dalam aliran nilai Anda dan gunakan AI untuk mengotomatiskan hanya langkah-langkah yang tidak terkait pengambilan keputusan. Dalam beberapa kasus, AI yang dapat dijelaskan mungkin tidak cukup atau suatu proses mungkin memerlukan intervensi manusia karena masalah peraturan (misalnya, GDPR, Pasal 22). Dalam kasus tersebut, sajikan semua informasi yang dibutuhkan agen manusia untuk pengambilan keputusan dalam satu panel kontrol, tetapi otomatiskan tugas pengumpulan, penyerapan, manipulasi, dan peringkasan data.

Pikirkan ulang arsitektur Anda untuk beradaptasi dengan peluang dan persyaratan baru

Mengembangkan arsitektur saat ini dengan kemampuan berbasis cloud dapat memberikan nilai yang signifikan. Untuk mencapai hasil yang lebih transformatif, Anda perlu memikirkan ulang arsitektur secara berkala dengan menggunakan pendekatan cloud-first.

Pertimbangkan rekomendasi berikut untuk secara berkala memikirkan ulang arsitektur workload Anda guna mengoptimalkan performa lebih lanjut.

Menggunakan alternatif berbasis cloud untuk sistem dan penjadwal HPC lokal

Untuk memanfaatkan elastisitas yang lebih tinggi, postur keamanan yang lebih baik, serta kemampuan pemantauan dan tata kelola yang ekstensif, Anda dapat menjalankan workload HPC di cloud atau memperluas workload lokal ke cloud. Namun, untuk kasus penggunaan pemodelan numerik tertentu seperti simulasi strategi investasi atau pemodelan XVA, menggabungkan Kubernetes dengan Kueue dapat menawarkan solusi yang lebih efektif.

Beralih ke pemrograman berbasis grafik untuk simulasi

Simulasi Monte Carlo mungkin jauh lebih berperforma dalam sistem eksekusi berbasis grafik seperti Dataflow. Misalnya, HSBC menggunakan Dataflow untuk menjalankan penghitungan risiko 16 kali lebih cepat dibandingkan dengan pendekatan sebelumnya.

Menjalankan platform perdagangan dan bursa berbasis cloud

Percakapan dengan pelanggan Google Cloud mengungkapkan bahwa prinsip Pareto 80/20 berlaku untuk persyaratan performa aplikasi pasar dan perdagangan.

  • Lebih dari 80% aplikasi perdagangan tidak memerlukan latensi yang sangat rendah. Namun, mereka mendapatkan manfaat signifikan dari kemampuan ketahanan, keamanan, dan elastisitas cloud. Misalnya, BidFX, platform multi-dealer valuta asing menggunakan cloud untuk meluncurkan produk baru dengan cepat dan meningkatkan ketersediaan serta jejaknya secara signifikan tanpa menambah resource.
  • Aplikasi yang tersisa (kurang dari 20%) memerlukan latensi rendah (kurang dari milidetik), determinisme, dan keadilan dalam pengiriman pesan. Biasanya, sistem ini berjalan di fasilitas kolokasi yang kaku dan mahal. Semakin banyak aplikasi dalam kategori ini yang di-platform ulang di cloud, baik di edge maupun sebagai aplikasi cloud-first.

Menyiapkan teknologi Anda untuk masa mendatang guna memenuhi kebutuhan bisnis saat ini dan masa depan

Secara historis, banyak organisasi FSI membangun teknologi eksklusif untuk mendapatkan keunggulan kompetitif. Misalnya, pada awal tahun 2000-an, bank investasi dan perusahaan perdagangan yang sukses memiliki penerapan teknologi dasar mereka sendiri seperti sistem pub-sub dan message broker. Dengan evolusi teknologi open source dan cloud, teknologi tersebut telah menjadi komoditas dan tidak menawarkan nilai bisnis inkremental.

Pertimbangkan rekomendasi berikut untuk memastikan teknologi Anda siap menghadapi masa depan.

Menerapkan pendekatan data-as-a-service (DaaS) untuk mempercepat waktu pemasaran dan transparansi biaya

Organisasi FSI sering kali berkembang melalui kombinasi pertumbuhan organik dan merger serta akuisisi (M&A). Akibatnya, organisasi perlu mengintegrasikan teknologi yang berbeda-beda. Mereka juga perlu mengelola resource duplikat, seperti vendor data, lisensi data, dan titik integrasi. Google Cloud memberikan peluang untuk menciptakan nilai yang berbeda dalam integrasi pasca-merger.

Misalnya, Anda dapat menggunakan layanan seperti berbagi BigQuery untuk membangun platform data-as-a-service (DaaS) yang siap analisis. Platform ini dapat memberikan data pasar dan input dari sumber alternatif. Pendekatan ini menghilangkan kebutuhan untuk membangun pipeline data yang berlebihan dan memungkinkan Anda berfokus pada inisiatif yang lebih berharga. Selain itu, perusahaan yang digabungkan atau diakuisisi dapat dengan cepat dan efisien merasionalisasi kebutuhan infrastruktur dan lisensi data pasca-penggabungan mereka. Daripada menghabiskan upaya untuk menyesuaikan dan menggabungkan operasi dan aset data lama, bisnis gabungan dapat berfokus pada peluang bisnis baru.

Bangun lapisan abstraksi untuk mengisolasi sistem yang ada dan menangani model bisnis yang muncul

Keunggulan kompetitif bank semakin bergantung pada lapisan pengalaman pelanggan, bukan sistem perbankan inti. Namun, sistem perbankan lama sering kali menggunakan aplikasi monolitik yang dikembangkan dalam bahasa seperti Cobol dan diintegrasikan di seluruh rantai nilai perbankan. Integrasi ini membuat lapisan rantai nilai sulit dipisahkan, sehingga hampir tidak mungkin untuk mengupgrade dan memodernisasi sistem tersebut.

Salah satu solusi untuk mengatasi tantangan ini adalah dengan menggunakan lapisan isolasi seperti sistem pengelolaan API atau lapisan penyiapan seperti Spanner yang menduplikasi buku catatan dan memfasilitasi modernisasi layanan dengan analisis dan AI tingkat lanjut. Misalnya, Deutsche Bank menggunakan Spanner untuk mengisolasi sistem perbankan inti lama mereka dan memulai perjalanan inovasi mereka.