Dokumen di Framework Arsitektur Google Cloud ini memberikan prinsip-prinsip operasional untuk menjalankan layanan Anda dengan cara yang andal, seperti cara men-deploy update, menjalankan layanan di lingkungan produksi, dan menguji kegagalan. Merancang untuk keandalan harus mencangkup keseluruhan dari siklus proses layanan Anda, bukan hanya desain software.
Pilih nama yang bagus untuk aplikasi dan layanan.
Hindari penggunaan nama kode internal dalam file konfigurasi produksi, karena dapat membingungkan, terutama bagi karyawan baru, yang berpotensi meningkatkan waktu mitigasi (TTM) untuk pemadaman. Sebisa mungkin, pilih nama yang bagus untuk semua layanan aplikasi, dan resource sistem penting Anda seperti VM, cluster, dan instance database, sesuai dengan batas panjang nama. Nama yang baik menjelaskan tujuan entitas; akurat, spesifik, dan berbeda; dan berarti bagi siapa saja yang melihatnya. Nama yang baik menghindari akronim, nama kode, singkatan, dan terminologi yang berpotensi menyinggung, dan tidak akan menciptakan respons publik negatif meskipun dipublikasikan secara eksternal.
Terapkan peluncuran progresif dengan pengujian canary
Perubahan global seketika pada biner atau konfigurasi layanan sangat berisiko. Luncurkan versi file baru yang dapat dieksekusi dan perubahan konfigurasi secara bertahap. Mulailah dengan cakupan kecil, seperti beberapa instance VM dalam satu zona, dan perluas cakupannya secara bertahap. Melakukan roll back dengan cepat jika perubahan tidak berjalan seperti yang Anda harapkan, atau berdampak negatif terhadap pengguna di setiap tahap peluncuran. Tujuan Anda adalah mengidentifikasi dan mengatasi bug jika hanya memengaruhi sebagian kecil traffic pengguna, sebelum Anda meluncurkan perubahan secara global.
Siapkan sebuah pengujian canary sistem yang mengetahui perubahan layanan dan melakukan perbandingan A/B dari metrik server yang diubah dengan server lainnya. Sistem harus menandai perilaku yang tidak terduga atau tidak wajar. Jika perubahan tidak berjalan seperti yang Anda harapkan, sistem pengujian canary akan otomatis menghentikan peluncuran. Masalahnya dapat menjadi jelas, seperti error pengguna, atau halus, seperti peningkatan penggunaan CPU atau penggelembungan memori.
Sebaiknya hentikan dan lakukan roll back pada saat ada masalah pertama dan masalah diagnosis tanpa menimbulkan tekanan waktu untuk pemadaman. Setelah perubahan lulus pengujian canary, sebarkan ke cakupan yang lebih besar secara bertahap, seperti ke zona penuh, kemudian kemudian zona kedua. Beri waktu bagi sistem yang diubah untuk menangani volume traffic pengguna yang semakin besar guna mengekspos bug laten.
Untuk informasi selengkapnya, lihat Strategi deployment dan pengujian aplikasi.
Sebarkan traffic untuk promosi dan peluncuran dengan waktu
Anda mungkin memiliki acara promosi, seperti penjualan yang dimulai pada waktu yang tepat dan mendorong banyak pengguna untuk terhubung ke layanan secara bersamaan. Jika demikian, desain kode klien untuk penyebaran traffic selama beberapa detik lebih. Gunakan penundaan acak sebelum mereka memulai permintaan.
Anda juga dapat melakukan pra-penyiapan pada sistem. Saat melakukan pra-penyiapan sistem, Anda mengirim traffic pengguna yang Anda antisipasi terlebih dahulu untuk memastikan sistem berfungsi seperti yang Anda harapkan. Pendekatan ini mencegah lonjakan traffic seketika yang dapat menyebabkan server Anda error pada waktu mulai yang dijadwalkan.
Mengotomatiskan build, pengujian, dan deployment
Hilangkan upaya manual dari proses rilis Anda dengan menggunakan pipeline continuous integration dan continuous delivery (CI/CD). Lakukan pengujian dan deployment integrasi otomatis. Misalnya, buat proses CI/CD modern dengan GKE.
Untuk mengetahui informasi selengkapnya, lihat continuous integration, continuous delivery, otomatisasi pengujian, dan otomatisasi deployment.
Bertahan dari error operator
Desain alat operasional Anda untuk menolak konfigurasi yang berpotensi tidak valid. Mendeteksi dan mengirimkan pemberitahuan saat versi konfigurasi kosong, sebagian atau terpotong, rusak, secara logis salah atau tidak terduga, atau tidak diterima dalam waktu yang diharapkan. Alat-alat juga harus menolak versi konfigurasi yang terlalu berbeda dari versi sebelumnya.
Melarang perubahan atau perintah dengan cakupan yang terlalu luas yang berpotensi merusak. Perintah umum ini dapat berupa "Cabut perizinan untuk semua pengguna", "Mulai ulang semua VM di region ini", atau "Format ulang semua disk di zona ini. Perubahan tersebut hanya boleh diterapkan jika operator menambahkan tanda command line atau setelan opsi penggantian darurat saat operator men-deploy konfigurasi.
Alat harus menampilkan cakupan dampak perintah yang berisiko, seperti jumlah VM yang terkena dampak perubahan, dan memerlukan konfirmasi operator eksplisit sebelum alat tersebut dilanjutkan. Anda juga dapat menggunakan fitur untuk mengunci resource penting dan mencegah penghapusan yang tidak disengaja atau tidak sah, seperti penguncian kebijakan retensi Cloud Storage.
Uji Pemulihan Kegagalan
Uji prosedur operasional Anda secara rutin agar pulih dari kegagalan di layanan Anda. Tanpa pengujian reguler, prosedur Anda mungkin tidak berfungsi saat Anda membutuhkannya jika terjadi kegagalan nyata. Item yang akan diuji secara berkala mencakup failover regional cara melakukan roll back rilis, dan cara memulihkan data dari pencadangan.
Lakukan pengujian disaster recovery
Seperti halnya tes pemulihan kegagalan, jangan menunggu bencana terjadi. Uji dan verifikasi prosedur dan proses pemulihan dari bencana Anda secara berkala.
Anda dapat membuat arsitektur sistem untuk memberikan ketersediaan tinggi (HA). Arsitektur ini tidak sepenuhnya tumpang tindih dengan pemulihan bencana (DR), tetapi sering kali perlu untuk mempertimbangkan HA kedalam akun saat Anda memikirkan nilai objektif waktu pemulihan (RTO) dan objektif titik pemulihan (RPO) nilai.
HA membantu Anda memenuhi atau melampaui tingkat performa operasional yang disepakati, seperti waktu beroperasi. Saat menjalankan workload produksi di Google Cloud, Anda dapat men-deploy instance standby pasif atau aktif di region kedua. Dengan arsitektur ini, aplikasi tersebut akan terus menyediakan layanan dari region yang tidak terpengaruh jika terjadi bencana di region utama. Untuk informasi selengkapnya, lihat Merancang pemulihan dari bencana untuk pemadaman layanan cloud.
Praktikkan rekayasa kekacauan.
Pertimbangkan penggunaan rekayasa kekacauan dalam praktik pengujian Anda. Munculkan kegagalan yang sesungguhnya ke berbagai komponen sistem produksi dengan beban di lingkungan yang aman. Pendekatan ini membantu memastikan bahwa tidak ada dampak sistem secara keseluruhan karena layanan Anda menangani kegagalan dengan benar di setiap level.
Kegagalan yang Anda masukkan kedalam sistem dapat mencakup tugas error, error dan waktu tunggu pada RPC, atau pengurangan ketersediaan resource. Gunakan injeksi kesalahan acak untuk menguji kegagalan sesekali (flapping) didalam dependensi layanan. Perilaku ini sulit dideteksi dan dimitigasi dalam produksi.
Rekayasa kekacauan memastikan bahwa dampak dari eksperimen tersebut diminimalkan dan ditanggulangi. Perlakukan pengujian tersebut sebagai praktik untuk pemadaman layanan yang sebenarnya dan penggunaan semua informasi yang dikumpulkan untuk meningkatkan respons pemadaman layanan Anda.
Langkah selanjutnya
- Membuat pemberitahuan yang efisien (dokumen berikutnya dalam seri ini)
Pelajari kategori lainnya dalam Framework Arsitektur seperti desain sistem, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.