Well-Architected Framework: Perspektif layanan keuangan (FS)

Last reviewed 2026-10-28 UTC

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

Audiens target untuk dokumen ini mencakup pengambil keputusan, arsitek, administrator, developer, dan operator yang mendesain, membangun, men-deploy, dan memelihara workload FS di Google Cloud. Contoh organisasi FS yang dapat memperoleh manfaat dari panduan ini mencakup bank, pemain infrastruktur pembayaran, penyedia asuransi, dan operator pasar modal.

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

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 kembali arsitektur Anda secara mendasar guna mengurangi overhead pengelolaan, mengoptimalkan biaya, meningkatkan keamanan, serta meningkatkan keandalan dan ketahanan.

Halaman berikut menjelaskan prinsip dan rekomendasi yang spesifik untuk workload FS untuk setiap pilar Well-Architected Framework:

Kontributor

Penulis:

Kontributor lainnya:

Perspektif jasa keuangan: Keunggulan operasional

Dokumen dalam Google Cloud Well-Architected Framework: Perspektif jasa keuangan (FS) ini memberikan ringkasan prinsip dan rekomendasi untuk membangun, men-deploy, dan mengoperasikan workload FS 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 Well-Architected Framework.

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

Keunggulan operasional memberikan manfaat berikut untuk workload FS:

  • Menjaga kepercayaan dan reputasi: Lembaga keuangan sangat bergantung pada kepercayaan pelanggan. Gangguan operasional atau pelanggaran keamanan dapat sangat mengikis kepercayaan ini dan menyebabkan pelanggan beralih ke kompetitor. Keunggulan operasional membantu meminimalkan risiko ini.

  • Memenuhi persyaratan kepatuhan terhadap peraturan yang ketat: Jasa keuangan tunduk pada berbagai peraturan yang kompleks, seperti berikut:

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

  • Memastikan kelangsungan dan ketahanan bisnis: Pasar dan layanan keuangan sering kali beroperasi secara terus-menerus. Oleh karena itu, ketersediaan tinggi dan disaster recovery yang efektif sangatlah penting. Prinsip keunggulan operasional memandu desain dan implementasi sistem yang tangguh. Pilar keandalan memberikan panduan lebih lanjut di area ini.

  • Melindungi data sensitif: Lembaga keuangan menangani data pelanggan dan keuangan yang sangat sensitif dalam jumlah besar. 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 pengeluaran 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 FS, ketersediaan aplikasi biasanya diklasifikasikan berdasarkan metrik batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (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). Mengembangkan 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:

  • Mengembangkan dan menentukan 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 diambil jika layanan tidak memenuhi SLO. Misalnya, untuk meningkatkan ketahanan platform, Anda mungkin perlu memfokuskan resource pengembangan untuk memperbaiki masalah.
  • Validasi persyaratan SLA untuk setiap layanan dan kenali 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
Transaksi pembayaran berhasil

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

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

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

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

Jaminan kontrak untuk rasio 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

Waktu rata-rata 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 yang bergulir.

Target internal untuk kecepatan pemrosesan transaksi pembayaran.

Contoh: Memastikan bahwa 99,5% transaksi pembayaran diproses dalam waktu 400 milidetik selama periode 30 hari berturut-turut.

Komitmen kontrak untuk menyelesaikan masalah pemrosesan pembayaran yang penting dalam jangka waktu yang ditentukan.

Contoh: Untuk masalah pemrosesan pembayaran yang kritis (didefinisikan sebagai pemadaman layanan yang memengaruhi lebih dari 1% transaksi), penyedia layanan berkomitmen untuk memberikan waktu penyelesaian 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 − periode nonaktif) ÷ total waktu operasional × 100, diukur per menit.

Target internal untuk waktu beroperasi platform pembayaran inti.

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

Komitmen formal yang mengikat secara hukum kepada klien terkait waktu beroperasi minimum platform pembayaran, termasuk konsekuensi jika gagal memenuhinya.

Contoh: Platform akan mempertahankan ketersediaan minimum sebesar 99,9% per bulan kalender, tidak termasuk masa 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 bahwa SLA terpenuhi. Dengan menggunakan serangkaian SLI yang didefinisikan dengan baik, engineer dan developer dapat memantau aplikasi FS pada tingkat berikut:

  • Langsung dalam layanan tempat aplikasi di-deploy, seperti Google Kubernetes Engine 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 dasbor dan mekanisme pemberitahuan dan pemantauan yang efektif, gunakan alat Google Cloud Observability bersama dengan Cloud Monitoring. Untuk mengetahui informasi tentang kemampuan pemantauan dan deteksi khusus keamanan, lihat pilar keamanan.

Menentukan dan menguji proses pengelolaan insiden

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

Pengujian rutin proses pengelolaan insiden memberikan manfaat berikut:

  • Mempertahankan performa saat beban puncak: Pengujian performa dan beban secara 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 bottleneck dan batasan: Pengujian stres mendorong sistem hingga batasnya, dan memungkinkan lembaga keuangan mengidentifikasi potensi bottleneck dan batasan performa sebelum memengaruhi operasi penting. Pendekatan proaktif ini memungkinkan lembaga keuangan menyesuaikan infrastruktur dan aplikasi mereka untuk performa dan skalabilitas yang optimal.
  • Memvalidasi keandalan dan ketahanan: Pengujian rutin, termasuk chaos engineering atau simulasi kegagalan, 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.
  • Melakukan perencanaan kapasitas yang efektif: Pengujian performa memberikan data berharga tentang pemanfaatan resource dalam berbagai kondisi beban, yang sangat penting untuk perencanaan kapasitas yang akurat. Institusi keuangan dapat menggunakan data ini untuk mengantisipasi kebutuhan kapasitas di masa mendatang secara proaktif dan untuk menghindari masalah performa akibat keterbatasan resource.
  • Berhasil men-deploy fitur baru dan perubahan kode: 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 mengharuskan institusi memiliki praktik pengujian yang kuat untuk memastikan stabilitas dan keandalan sistem penting mereka. Pengujian rutin 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 melibatkan elemen-elemen berikut:

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

Menerapkan pengujian performa dan beban secara rutin

Pengujian performa dan beban 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 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 cloud dan aplikasi untuk 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 tangguh. Anda dapat menggabungkan berbagai jenis pengujian dalam pipeline CI/CD, termasuk pengujian unit, pengujian integrasi, dan pengujian menyeluruh. Gunakan produk seperti Cloud Build dan Cloud Deploy untuk membuat dan mengelola pipeline CI/CD Anda.

Terus meningkatkan kualitas dan berinovasi

Untuk workload jasa keuangan di cloud, bermigrasi ke cloud hanyalah langkah awal. Peningkatan dan inovasi yang berkelanjutan sangat penting karena alasan berikut:

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

Untuk memastikan peningkatan dan inovasi yang berkelanjutan, pertimbangkan rekomendasi berikut.

Melakukan retrospektif rutin

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

  • Beri tim kesempatan untuk merenungkan pengalaman mereka, mengidentifikasi hal-hal yang berjalan baik, dan menentukan area yang perlu ditingkatkan.
  • Adakan retrospektif setelah pencapaian project, insiden besar, atau siklus pengujian yang signifikan. Tim dapat belajar dari keberhasilan dan kegagalan serta terus menyempurnakan proses dan praktik mereka.
  • Gunakan pendekatan terstruktur seperti model start-stop-continue untuk memastikan bahwa 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.
  • Terapkan budaya tidak saling menyalahkan, di mana kegagalan dipandang sebagai peluang untuk pertumbuhan dan peningkatan.
  • Ciptakan lingkungan yang aman secara psikologis yang memungkinkan tim mengambil risiko dan mempertimbangkan solusi inovatif. Tim belajar dari keberhasilan dan kegagalan, sehingga menghasilkan organisasi yang lebih tangguh dan mudah beradaptasi.
  • Kembangkan budaya yang memfasilitasi berbagi pengetahuan yang diperoleh dari proses pengelolaan insiden dan latihan pengujian.

Mendapatkan informasi terbaru 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 jasa keuangan.

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

Perspektif jasa keuangan: Keamanan, privasi, dan kepatuhan

Dokumen dalam Google Cloud Well-Architected Framework: Perspektif jasa keuangan (FS) ini memberikan ringkasan prinsip dan rekomendasi untuk memenuhi persyaratan keamanan, privasi, dan kepatuhan workload jasa keuangan (FS) di Google Cloud. Rekomendasi ini membantu Anda membangun infrastruktur yang tangguh dan sesuai, melindungi data sensitif, menjaga kepercayaan pelanggan, menavigasi lanskap persyaratan peraturan yang kompleks, dan mengelola ancaman cyber secara efektif. Rekomendasi dalam dokumen ini selaras dengan pilar keamanan Well-Architected Framework.

Keamanan dalam cloud computing adalah masalah penting bagi organisasi FS, yang sangat menarik bagi penjahat cyber karena banyaknya data sensitif yang mereka kelola, termasuk detail pelanggan dan catatan keuangan. Konsekuensi pelanggaran keamanan sangatlah parah, termasuk kerugian finansial yang signifikan, kerusakan reputasi jangka panjang, dan denda peraturan yang signifikan. Oleh karena itu, workload FS memerlukan kontrol keamanan yang ketat.

Untuk membantu memastikan keamanan dan kepatuhan yang komprehensif, Anda perlu memahami tanggung jawab bersama antara Anda (organisasi FS) dan Google Cloud. Google Cloud bertanggung jawab untuk mengamankan infrastruktur yang mendasarinya, 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, ekosistem partnerGoogle Cloud menawarkan integrasi keamanan dan layanan terkelola.

Rekomendasi keamanan dalam dokumen ini dipetakan ke prinsip inti berikut:

Menerapkan pengamanan dari desain

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

Untuk menerapkan prinsip keamanan berdasarkan desain untuk workload FS 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 dan resource sensitif, serta membantu mencegah pemindahan data yang tidak sah dan akses yang tidak sah, sebagaimana diwajibkan oleh peraturan.
  • Tentukan konfigurasi keamanan sebagai kode menggunakan alat infrastructure as code (IaC) seperti Terraform. Pendekatan ini menyematkan kontrol keamanan dari 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 mematuhi kebijakan.
  • Menyediakan antarmuka terpadu untuk insight keamanan 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 makin 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 mendukung verifikasi berkelanjutan terhadap setiap pengguna dan perangkat, yang menghilangkan kepercayaan implisit dan mengurangi 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.
  • Sediakan pengelolaan akses dan identitas 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 lain yang 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 yang 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 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 sanksi ketidakpatuhan. Prinsip keamanan shift-left mendorong pengujian dan integrasi keamanan sejak awal, yang membantu mengurangi biaya dan kompleksitas perbaikan.

Untuk menerapkan keamanan shift-left, pertimbangkan rekomendasi berikut:

  • Pastikan pemeriksaan keamanan otomatis dilakukan 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 pusat yang aman 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.

  • Pindai aplikasi web secara otomatis untuk menemukan 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 provenance kode menggunakan framework Supply-chain Levels for Software Artifacts (SLSA). Terapkan provenance workload yang berjalan di lingkungan Anda menggunakan solusi seperti Otorisasi Biner. Pastikan workload Anda hanya menggunakan library software open source yang terverifikasi dengan menggunakan Assured Open Source Software.

  • 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 workload. Misalnya, untuk workload dalam container, gunakan fitur pemindaian container Artifact Registry.

Menerapkan pertahanan cyber preventif

Lembaga keuangan adalah target utama serangan cyber yang canggih. Peraturan sering kali memerlukan threat intelligence yang kuat dan mekanisme pertahanan proaktif. Pertahanan cyber preemptive berfokus pada deteksi dan respons ancaman proaktif dengan menggunakan analisis dan otomatisasi tingkat lanjut.

Pertimbangkan rekomendasi berikut:

  • Identifikasi dan mitigasi potensi ancaman secara proaktif, dengan menggunakan layanan threat intelligence, respons insiden, dan validasi keamanan dari Mandiant.
  • Lindungi aplikasi web dan API dari eksploitasi web dan serangan DDoS di edge jaringan menggunakan Google Cloud Armor.
  • Gabungkan dan prioritaskan temuan serta rekomendasi keamanan menggunakan Security Command Center, yang memungkinkan tim keamanan mengatasi potensi risiko secara proaktif.
  • Validasi pertahanan preemptive 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 cyber yang dicegah. Anda bisa mendapatkan metrik dan data yang diperlukan dari dasbor SOAR Google Security Operations.

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

AI dan ML makin banyak digunakan untuk kasus penggunaan layanan keuangan seperti deteksi penipuan dan perdagangan algoritmik. Peraturan mengharuskan 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 Gemini Enterprise Agent Platform. Fitur seperti penjelasan model dan metrik keadilan dapat membantu mengatasi masalah AI yang bertanggung jawab.
  • Manfaatkan kemampuan operasi dan analisis keamanan Google Security Operations, yang menggunakan AI dan ML untuk menganalisis volume data keamanan yang besar, mendeteksi anomali, dan mengotomatiskan respons ancaman. Kemampuan ini membantu meningkatkan postur 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.
  • Selaraskan 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 yang didukung AI, pengurangan positif palsu dalam notifikasi 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, jejak audit tertentu, dan standar perlindungan data. Untuk memastikan bahwa data sensitif diidentifikasi, dilindungi, dan dikelola dengan benar, organisasi FS memerlukan kebijakan tata kelola data dan skema klasifikasi data yang kuat. Pertimbangkan rekomendasi berikut untuk membantu Anda memenuhi persyaratan peraturan:

  • Siapkan batas data di Google Cloud untuk workload sensitif dan teregulasi menggunakan Assured Workloads. Hal ini membantu Anda memenuhi persyaratan kepatuhan khusus pemerintah dan industri seperti FedRAMP dan CJIS.
  • Identifikasi, klasifikasikan, dan lindungi data sensitif, termasuk informasi keuangan, dengan menerapkan Sensitive Data Protection. Tindakan ini membantu Anda memenuhi peraturan privasi data seperti GDPR dan CCPA.
  • Lacak detail aktivitas administratif dan akses ke resource menggunakan Cloud Audit Logs. Log ini sangat penting untuk memenuhi persyaratan audit yang ditetapkan oleh banyak peraturan keuangan.
  • Saat Anda memilih regionGoogle Cloud untuk workload dan data Anda, pertimbangkan peraturan lokal yang terkait dengan residensi data. Infrastruktur global Google Cloud 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 tersebut merupakan persyaratan mendasar dari banyak peraturan keamanan dan privasi.
  • Terapkan kontrol yang diperlukan untuk memenuhi persyaratan peraturan Anda. Memvalidasi bahwa kontrol berfungsi seperti yang diharapkan. Minta kontrol divalidasi lagi oleh auditor eksternal untuk membuktikan kepada regulator bahwa workload Anda mematuhi peraturan.

Memprioritaskan inisiatif keamanan

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

  1. Membangun fondasi keamanan yang kuat: Fokus pada area inti keamanan, termasuk pengelolaan akses dan identitas, 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. Atasi 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 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 jasa keuangan: Keandalan

Dokumen dalam Google Cloud Well-Architected Framework: Perspektif jasa keuangan (FS) ini memberikan ringkasan prinsip dan rekomendasi untuk mendesain, men-deploy, dan mengoperasikan workload FS yang andal di Google Cloud. Dokumen ini membahas cara mengintegrasikan praktik keandalan dan kemampuan observasi tingkat lanjut ke dalam blueprint arsitektur Anda. Rekomendasi dalam dokumen ini selaras dengan pilar keandalan Well-Architected Framework.

Bagi lembaga keuangan, infrastruktur yang andal dan tangguh merupakan kebutuhan bisnis dan keharusan peraturan. Untuk memastikan workload FS di Google Cloud andal, Anda harus memahami dan memitigasi potensi titik kegagalan, men-deploy resource secara redundan, dan merencanakan pemulihan. Ketahanan operasional adalah hasil dari keandalan. Ketahanan adalah kemampuan untuk menyerap, beradaptasi, dan pulih dari gangguan. Ketahanan operasional membantu organisasi FS 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 FS beroperasi di bawah mandat keandalan yang ketat oleh badan pengatur seperti Federal Reserve System di AS, European Banking Authority di Uni Eropa, dan Prudential Regulation Authority di Inggris Raya. Secara global, regulator menekankan ketahanan operasional, yang sangat penting untuk stabilitas keuangan dan perlindungan konsumen. Ketahanan operasional adalah kemampuan untuk bertahan dari gangguan, pulih secara efektif, dan mempertahankan layanan penting. Hal ini memerlukan pendekatan yang harmonis untuk mengelola risiko teknologi dan dependensi pada pihak ketiga.

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

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

Rekomendasi keandalan dalam dokumen ini dipetakan ke prinsip-prinsip inti berikut:

Memprioritaskan deployment multi-zona dan multi-region

Untuk aplikasi jasa 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 masuk akal. Alasannya adalah jika satu lokasi gagal, lokasi lain mungkin menerima jumlah traffic tambahan yang sangat tinggi.

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

  • Lebih memilih referensi yang memiliki cakupan lokasi yang lebih luas. Jika memungkinkan, gunakan resource regional, bukan resource zona, dan gunakan resource multi-regional atau global, bukan resource regional. Pendekatan ini membantu menghindari kebutuhan untuk memulihkan operasi menggunakan cadangan.
  • Di setiap region, manfaatkan tiga zona, bukan dua. Untuk menangani failover, sediakan kapasitas berlebih 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.
  • Distribusikan traffic pengguna di seluruh region menggunakan Cloud DNS, dan deploy load balancer regional di setiap region. Load balancer global adalah opsi lain yang dapat Anda pertimbangkan, bergantung pada persyaratan dan tingkat kekritisannya. 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 titik tunggal kegagalan (SPOF) memengaruhi seluruh stack aplikasi.

Pertimbangkan rekomendasi berikut untuk menghindari SPOF:

  • Hindari men-deploy hanya satu server aplikasi atau database.
  • Pastikan pembuatan ulang otomatis VM yang gagal menggunakan grup instance terkelola (MIG).
  • Distribusikan traffic secara merata ke seluruh resource yang tersedia dengan menerapkan load balancing.
  • Gunakan konfigurasi HA untuk database seperti Cloud SQL.
  • Tingkatkan ketersediaan data 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

Perlu diketahui bahwa ketersediaan keseluruhan atau gabungan sistem dipengaruhi oleh ketersediaan setiap tingkat atau komponen sistem. Jumlah tingkat dalam stack aplikasi memiliki hubungan terbalik dengan ketersediaan gabungan stack. 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 perantaian. 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 menggunakan pendekatan perantaian dan paralelisasi:

    Formula ketersediaan gabungan untuk layanan berantai dibandingkan dengan layanan paralel.

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

    • Layanan berantai menghasilkan ketersediaan gabungan hanya 98% (0,99 × 0,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 layanan Google Cloud dengan SLA waktu beroperasi yang dapat membantu memenuhi tingkat waktu beroperasi keseluruhan yang diperlukan untuk stack aplikasi Anda.

  • Saat mendesain arsitektur, pertimbangkan konsekuensi antara ketersediaan, kompleksitas operasional, latensi, dan biaya. Meningkatkan jumlah angka sembilan ketersediaan umumnya memerlukan biaya lebih tinggi, tetapi hal ini membantu Anda memenuhi persyaratan peraturan.

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

    Untuk layanan keuangan penting, opsi arsitektur mungkin terbatas. Namun, penting untuk mengidentifikasi persyaratan ketersediaan dan menghitung ketersediaan secara akurat. Melakukan penilaian semacam ini akan 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 pemadaman layanan zona dan regional. Strategi disaster recovery (DR) yang jelas memungkinkan Anda pulih 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 durasi kehilangan data (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-regional atau global, Anda harus menentukan strategi replikasi. Strategi replikasi biasanya asinkron. Nilai dengan cermat pengaruh replikasi tersebut terhadap 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 jika replikasi data sangat penting.

Pertimbangkan rekomendasi berikut:

  • Gunakan layanan penyimpanan multi-regional 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.
  • Validasi bahwa rencana DR Anda efektif dengan menguji rencana tersebut secara rutin.
  • Perhatikan RTO dan RPO serta korelasinya dengan toleransi dampak yang ditetapkan oleh peraturan keuangan di wilayah hukum Anda.

Untuk mengetahui informasi selengkapnya, lihat Merancang disaster recovery 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. Mereka 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 hosting komputasi dan 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 akan 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 kontinjensi untuk pengambilan data dan kelangsungan operasional jika hubungan dengan penyedia cloud berakhir. Perusahaan harus menilai kelayakan keluar sebelum membuat kontrak cloud dan harus mempertahankan kemampuan untuk mengubah 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 Managed Service untuk Apache Airflow.

Mengotomatiskan proses penyediaan dan pemulihan infrastruktur

Otomatisasi membantu meminimalkan kesalahan manusia serta 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.
  • Mengurangi intervensi manual dengan mengotomatiskan proses failover. Respons otomatis juga dapat membantu mengurangi dampak kegagalan. Misalnya, Anda dapat menggunakan Eventarc atau Workflows untuk otomatis memicu tindakan perbaikan sebagai respons terhadap masalah yang diamati melalui log audit.
  • Tingkatkan kapasitas resource cloud Anda selama failover menggunakan penskalaan otomatis.
  • Terapkan kebijakan dan batasan secara otomatis untuk persyaratan peraturan di seluruh topologi cloud Anda selama deployment layanan dengan mengadopsi rekayasa platform.

Perspektif jasa keuangan: Pengoptimalan biaya

Dokumen dalam Google Cloud Well-Architected Framework: Perspektif jasa keuangan (FS) ini memberikan ringkasan prinsip dan rekomendasi untuk mengoptimalkan biaya workload FS Anda di Google Cloud. Rekomendasi dalam dokumen ini selaras dengan pilar pengoptimalan biaya dari Well-Architected Framework.

Pengoptimalan biaya yang kuat untuk workload jasa keuangan memerlukan elemen dasar 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 cost driver 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 pengeluaran di sejumlah besar domain. Pendekatan ini mengasumsikan bahwa tim pusat berada di posisi terbaik untuk mengidentifikasi peluang bernilai tinggi guna meningkatkan efisiensi.

Pendekatan terpusat mungkin memberikan beberapa keberhasilan selama tahap awal adopsi cloud atau untuk workload yang tidak penting. Namun, satu tim tidak dapat mendorong pengoptimalan biaya di seluruh organisasi. Saat penggunaan resource atau tingkat pengawasan peraturan meningkat, pendekatan terpusat tidak dapat dipertahankan. 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 dibuat oleh tim eksternal.

Untuk pengoptimalan biaya yang efektif, data terkait pengeluaran harus sangat terlihat, dan engineer serta pengguna cloud lainnya yang dekat dengan workload 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 pemborosan menggunakan alat Google Cloud

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

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

Active Assist memberikan rekomendasi cerdas di berbagai layanan seperti Cloud Run untuk microservice, 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 dari Anda. Rekomendasi ini membantu Anda mengidentifikasi resource nonaktif dan komitmen yang kurang dimanfaatkan.

Memusatkan pemantauan dan kontrol FinOps melalui antarmuka terpadu

Laporan Penagihan Cloud dan FinOps hub memungkinkan Anda menerapkan pemantauan biaya yang komprehensif. Tampilan komprehensif ini sangat penting bagi auditor keuangan dan tim keuangan internal untuk melacak pengeluaran 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 pengeluaran

Active Assist efektif dalam mengidentifikasi pemborosan yang jelas. Namun, menentukan nilai bisa lebih sulit, terutama jika workload berada pada produk yang tidak sesuai atau jika workload tidak memiliki keselarasan yang jelas dengan nilai bisnis. Untuk workload FS, nilai bisnis tidak hanya mencakup pengurangan biaya. Nilainya mencakup mitigasi risiko, kepatuhan terhadap peraturan, dan memperoleh keunggulan kompetitif.

Untuk memahami pengeluaran dan nilai cloud secara holistik, Anda memerlukan pemahaman yang lengkap di berbagai level: dari mana pengeluaran berasal, fungsi bisnis apa yang didorong oleh pengeluaran, dan kelayakan teknis untuk melakukan refaktorisasi atau mengoptimalkan workload yang dimaksud.

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

Piramida data-informasi-pengetahuan-kebijaksanaan (DIKW) menunjukkan cara menggunakan data pengeluaran cloud untuk menginformasikan keputusan.

Diagram sebelumnya menunjukkan cara menggunakan pendekatan DIKW untuk menyaring data pengeluaran cloud mentah menjadi hasil analisis yang bisa ditindaklanjuti dan keputusan yang mendorong nilai bisnis.

  • Data: Di lapisan ini, Anda mengumpulkan aliran data penggunaan dan biaya yang mentah dan belum diproses untuk resource cloud Anda. Tim FinOps pusat Anda menggunakan alat seperti invoice Penagihan Cloud, ekspor penagihan, dan Cloud Monitoring untuk mendapatkan data yang terperinci dan mendetail. Misalnya, titik data bisa 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 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, pelabelan, hierarki resource, akun penagihan, dan dasbor Looker kustom. Misalnya, Anda mungkin menentukan bahwa tim pengujian app1 di AS menghabiskan USD 650 selama minggu kedua bulan Juli sebagai bagian dari latihan pengujian stres.
  • Kebijaksanaan: Di lapisan ini, tim produk dan aplikasi Anda menggunakan pengetahuan kontekstual untuk menilai nilai bisnis dari pengeluaran cloud dan untuk membuat keputusan strategis yang tepat. Tim Anda mungkin menjawab pertanyaan seperti berikut:
    • Apakah USD 5.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 pengeluaran cloud.

Menganalisis data pembelanjaan yang disediakan oleh Google Cloud

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

Memvisualisasikan data melalui alat yang tersedia

Tingkatkan dasbor bawaan Google Cloud dengan pelaporan kustom menggunakan alat seperti Data Studio di atas BigQuery Export. Tim keuangan dapat membuat dasbor kustom yang mengontekstualisasikan pengeluaran cloud terhadap metrik keuangan, persyaratan pelaporan kepada regulator, 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 yang mendorong pengeluaran cloud, Anda perlu mengidentifikasi siapa yang mengeluarkan uang dan alasannya. Tingkat pemahaman ini memerlukan praktik alokasi biaya yang kuat, yang melibatkan penyertaan 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 tersebut untuk melacak biaya yang dikeluarkan tim untuk resource tersebut. Idealnya, Anda harus mengalokasikan 100% biaya cloud ke sumber pengeluaran. Dalam praktiknya, Anda mungkin 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. Pengaitan ini sangat penting untuk tagihan balik internal, pelaporan kepada regulator, dan menyelaraskan pengeluaran cloud dengan sasaran unit bisnis. Misalnya, tag berikut mengidentifikasi dengan jelas tim yang melakukan pengeluaran, region mereka, 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 manual rentan terhadap error dan inkonsistensi, yang tidak dapat diterima di lingkungan FS yang mengutamakan kemampuan audit dan akurasi keuangan. Pemberian tag otomatis memastikan bahwa resource dikategorikan dengan benar saat dibuat.
  • Kesederhanaan: Mengukur faktor yang sederhana dan tidak berkorelasi. Lingkungan FS bersifat kompleks. Untuk memastikan bahwa aturan alokasi biaya di lingkungan tersebut mudah dipahami dan diterapkan, aturan harus sesederhana mungkin. Hindari rekayasa aturan yang berlebihan untuk kasus yang sangat spesifik (edge). Aturan yang kompleks dapat menyebabkan kebingungan dan penolakan dari tim operasional.

Setelah menentukan strategi alokasi menggunakan tag, Anda harus memutuskan tingkat perincian yang harus diterapkan pada strategi tersebut. Perincian yang diperlukan bergantung pada kebutuhan bisnis Anda. Misalnya, beberapa organisasi mungkin perlu melacak biaya di tingkat produk, beberapa mungkin memerlukan data biaya untuk setiap pusat biaya, dan yang lain mungkin memerlukan data biaya per lingkungan (pengembangan, staging, 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 penegakan kebijakan di Google Cloud. Secara default, izin Identity and Access Management (IAM), kebijakan keamanan, dan biaya diatribusikan ke project dan folder. Saat meninjau data biaya yang diekspor dari Penagihan Cloud, Anda dapat melihat hierarki folder dan project yang terkait dengan data biaya tersebut. JikaGoogle Cloud hierarki resource Anda mencerminkan struktur akuntabilitas organisasi Anda untuk pengeluaran, ini adalah cara paling sederhana untuk menerapkan alokasi biaya.
  • Gunakan tag dan label untuk perincian tambahan. Tag memberikan cara yang fleksibel untuk mengategorikan resource dalam ekspor penagihan. Tag dan label memfasilitasi perincian biaya yang mendetail berdasarkan aplikasi dan lingkungan.

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

Mendorong akuntabilitas dan memotivasi engineer untuk mengambil tindakan

Tim FinOps cloud 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 untuk mengoptimalkan biaya.

Membangun tim FinOps terpusat untuk tata kelola

Praktik Cloud FinOps tidak berkembang secara organik. Tim FinOps khusus harus menentukan dan menetapkan 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.
  • Melakukan intervensi saat tim engineering tidak bertanggung jawab atas biaya.

Mendapatkan sponsor dan mandat eksekutif

Kepemimpinan senior, termasuk CTO, CFO, dan CIO, harus secara aktif memperjuangkan perubahan di seluruh organisasi menuju budaya FinOps. Dukungan mereka sangat penting untuk memprioritaskan akuntabilitas biaya, mengalokasikan resource untuk program FinOps, memastikan partisipasi lintas fungsi, dan mendorong kepatuhan terhadap persyaratan FinOps.

Memberikan insentif kepada tim untuk mengoptimalkan biaya

Engineer dan tim engineering mungkin tidak memiliki motivasi diri untuk berfokus pada pengoptimalan biaya. Penting untuk menyelaraskan sasaran tim dan individu dengan efisiensi biaya dengan menerapkan insentif seperti berikut:

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

Menerapkan teknik showback dan penagihan balik

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

Fokus pada nilai dan TCO, bukan biaya

Saat Anda 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 disaster recovery, yang merupakan persyaratan penting untuk workload FS. Layanan terkelola memberikan nilai jangka panjang yang jauh lebih tinggi, yang mengimbangi biaya infrastruktur. Layanan terkelola memberikan kemampuan kepatuhan yang kuat, memiliki fitur keandalan bawaan, dan dapat membantu mengurangi overhead 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 Google Cloud, seperti berikut:

Manfaatkan diskon

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

Anda dapat memanfaatkan jenis diskon berikut untuk resourceGoogle Cloud :

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

Anda dapat memperoleh penghematan yang signifikan dengan menggunakan CUD selain diskon perusahaan.

Selain CUD, gunakan pendekatan berikut untuk mengurangi tarif penagihan:

  • Gunakan Spot VM untuk workload yang fault-tolerant dan fleksibel. Spot VM lebih murah 80% daripada VM biasa.
  • BigQuery menawarkan beberapa model harga, yang mencakup harga on-demand dan harga berbasis edisi yang didasarkan pada komitmen dan persyaratan penskalaan otomatis. Jika Anda menggunakan resource BigQuery dalam jumlah besar, pilih edisi yang sesuai untuk mengurangi biaya per slot untuk workload 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 jasa keuangan: Pengoptimalan performa

Dokumen dalam Google Cloud Well-Architected Framework: Perspektif jasa keuangan (FS) ini memberikan ringkasan prinsip dan rekomendasi untuk mengoptimalkan performa workload FS Anda di Google Cloud. Rekomendasi dalam dokumen ini selaras dengan pilar pengoptimalan performa Well-Architected Framework.

Pengoptimalan performa memiliki sejarah panjang dalam layanan keuangan. Teknologi ini telah membantu organisasi FS mengatasi tantangan teknis dan hampir selalu menjadi pendukung 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 mengabaikan kernel OS dan menyematkan thread aplikasi ke core komputasi membantu mencapai latensi yang deterministik dan rendah untuk aplikasi perdagangan. Pengurangan latensi memfasilitasi likuiditas yang lebih tinggi dan lebih kuat dengan spread 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, kompromi berikut lebih transparan dan dapat dikontrol di cloud:

  • Waktu penyiapan produk versus biaya.
  • Performa end-to-end di tingkat sistem versus performa di tingkat node.
  • Ketersediaan talenta versus ketangkasan 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 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 biaya 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 penyebaran skala secara optimal menggunakan sistem terdistribusi berbasis Kubernetes yang dirancang dengan baik.

Rekomendasi pengoptimalan performa dalam dokumen ini dipetakan ke prinsip-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 buy-side research desk, tujuan bisnisnya bisa berupa mengoptimalkan output per jam riset atau memprioritaskan eksperimen dari tim yang memiliki rekam jejak yang terbukti, seperti Sharpe ratio yang lebih tinggi. Di sisi penjualan, Anda dapat menggunakan analisis untuk melacak minat klien dan memprioritaskan throughput ke model AI yang mendukung riset 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 resource jika dibandingkan dengan operasi bisnis seperti biasa (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 penghitungan analisis risiko (seperti XVA) dalam hitungan menit, bukan jam atau hari. Solusi ini membantu organisasi memenuhi persyaratan kepatuhan yang relevan. Hal ini juga memungkinkan trader melakukan percakapan berkualitas lebih tinggi dengan klien mereka, yang berpotensi menawarkan spread yang lebih ketat, likuiditas yang lebih kuat, dan lindung nilai 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 dengan lebih efisien atau holistik.
  • Fokus pada pengoptimalan performa di tingkat sistem. Lihat lebih jauh dari pemisahan konvensional antara change-the-bank dan run-the-bank, serta silo antara front-office dan back-office.

Memprioritaskan keamanan tanpa mengorbankan performa untuk risiko yang belum terbukti

Kepatuhan terhadap peraturan dan keamanan di organisasi FS harus memiliki standar yang tinggi. 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 unik seperti Spanner. Jangan otomatis mengabaikan opsi teknologi tersebut karena kesalahpahaman umum tentang risiko operasional yang tinggi atau postur kepatuhan terhadap peraturan yang tidak memadai.

Google Cloud telah bekerja sama dengan G-SIFI untuk memastikan bahwa pendekatan berbasis AI untuk Anti-Pencucian Uang (AML) dapat digunakan di seluruh wilayah hukum tempat institusi melayani pelanggan. Misalnya, HSBC secara signifikan meningkatkan performa unit kejahatan keuangannya (Fincrime) dengan hasil 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 difokuskan hanya pada peringatan berisiko tinggi yang dapat ditindaklanjuti.
  • Output yang dapat diaudit dan dapat dijelaskan untuk mendukung kepatuhan terhadap peraturan.

Pertimbangkan rekomendasi berikut:

  • Pastikan 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 explainable AI.

  • Mencapai transparansi untuk workload AI generatif dengan menggunakan teknik seperti kutipan ke sumber, grounding, dan RAG.

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

Memikirkan kembali arsitektur Anda untuk beradaptasi dengan peluang dan persyaratan baru

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

Pertimbangkan rekomendasi berikut untuk memikirkan kembali arsitektur workload Anda secara berkala 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 burst workload lokal ke cloud. Namun, untuk kasus penggunaan pemodelan numerik tertentu seperti simulasi strategi investasi atau pemodelan XVA, menggabungkan Kubernetes dengan Kueue mungkin 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 pasar dan aplikasi perdagangan.

  • Lebih dari 80% aplikasi trading 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 meningkatkan resource.
  • Aplikasi yang tersisa (kurang dari 20%) memerlukan latensi rendah (kurang dari satu milidetik), determinisme, dan keadilan dalam pengiriman pesan. Secara konvensional, sistem ini berjalan di fasilitas kolokasi yang kaku dan mahal. Bahkan, kategori aplikasi ini semakin banyak yang di-replatform di cloud, baik di edge maupun sebagai aplikasi cloud-first.

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

Secara historis, banyak organisasi FS membangun teknologi eksklusif untuk mendapatkan keunggulan kompetitif. Misalnya, pada awal tahun 2000-an, bank investasi dan perusahaan perdagangan yang sukses memiliki implementasi teknologi dasar mereka sendiri, seperti sistem pub-sub dan broker pesan. 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.

Mengadopsi pendekatan data-as-a-service (DaaS) untuk waktu penyiapan produk yang lebih cepat dan transparansi biaya

Organisasi FS sering kali berkembang melalui kombinasi pertumbuhan organik serta merger dan akuisisi (M&A). Akibatnya, organisasi perlu mengintegrasikan teknologi yang berbeda. 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 BigQuery sharing untuk membangun platform data-as-a-service (DaaS) yang siap dianalisis. Platform ini dapat memberikan data pasar dan input dari sumber alternatif. Pendekatan ini menghilangkan kebutuhan untuk membangun pipeline data redundan dan memungkinkan Anda berfokus pada inisiatif yang lebih berharga. Selain itu, perusahaan yang digabungkan atau diakuisisi dapat dengan cepat dan efisien merasionalisasi kebutuhan lisensi data dan infrastruktur pasca-penggabungan. Alih-alih menghabiskan upaya untuk menyesuaikan dan menggabungkan aset dan operasi data lama, bisnis gabungan dapat berfokus pada peluang bisnis baru.

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

Keunggulan kompetitif bagi bank kini bukan lagi sistem perbankan inti, melainkan lapisan pengalaman pelanggan. Namun, sistem perbankan lama sering kali menggunakan aplikasi monolitik yang dikembangkan dalam bahasa seperti Cobol dan terintegrasi di seluruh rantai nilai perbankan. Integrasi ini menyulitkan pemisahan lapisan rantai nilai, sehingga hampir mustahil untuk mengupgrade dan memodernisasi sistem tersebut.

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