Setiap tahun, miliaran pengguna berinteraksi dengan produk dan layanan Google. Penawaran utama seperti Penelusuran, Gmail, Maps, YouTube, Chrome, dan kini juga Google Cloud, terintegrasi dengan lancar ke dalam kehidupan modern sehingga membantu menentukan pengalaman abad ke-21. Dampak di seluruh dunia ini adalah hasil dari kualitas penawaran kami yang telah terbukti dan ekspektasi bahwa Google selalu tersedia.
Di Google Cloud, kami terus memperkenalkan perubahan kode pada produk dan layanan kami untuk memastikan bahwa kami memberikan pengalaman pengguna terbaik, meningkatkan keamanan dan keandalan, serta mematuhi persyaratan peraturan dan kepatuhan. Setiap perubahan tersebut, baik besar maupun kecil, terkadang dapat merusak. Untuk mengatasi risiko tersebut, kami memprioritaskan keamanan perubahan di seluruh siklus proses perubahan.
Dokumen ini menjelaskan bagaimana tim Google Cloud membangun berdasarkan investasi Google selama puluhan tahun dalam keunggulan pengembangan untuk menerapkan praktik terbaik keandalan dan standar engineering yang memenuhi ekspektasi pelanggan Google Cloud untuk kecepatan dan keandalan pengembangan.
Siklus proses perubahan di Google Cloud
Tim produk Google Cloud berbagi banyak proses pengelolaan dan alat dengan tim engineering lainnya di Google. Kami menerapkan pendekatan pengembangan software standar untuk pengelolaan perubahan yang memprioritaskan continuous integration (CI) dan continuous delivery (CD). CI mencakup sering mengajukan, menguji, dan mengirimkan perubahan, sering kali beberapa kali dalam sehari untuk produk atau layanan tertentu. CD adalah ekstensi CI tempat engineer terus menyiapkan kandidat rilis berdasarkan snapshot codebase stabil terbaru.
Pendekatan ini memprioritaskan pembuatan dan peluncuran perubahan secara bertahap kepada pelanggan Google Cloud sesegera mungkin, tetapi juga seaman mungkin. Kami mempertimbangkan keamanan perubahan sebelum menulis kode apa pun, dan kami terus berfokus pada keamanan, bahkan setelah kami meluncurkan perubahan dalam produksi. Ada empat fase umum dalam model pengelolaan perubahan kami: desain, pengembangan, kualifikasi, dan peluncuran. Keempat fase ini ditampilkan dalam diagram berikut dan dibahas secara lebih mendetail di seluruh dokumen ini:
Didesain agar aman
Kami menyadari bahwa bahkan kesalahan kecil di awal proses pengembangan dapat menyebabkan masalah besar di kemudian hari yang secara signifikan memengaruhi pengalaman pelanggan. Oleh karena itu, kami mewajibkan semua perubahan besar untuk dimulai dengan dokumen desain yang disetujui. Kami memiliki template dokumen desain umum untuk tim engineer guna mengusulkan perubahan utama. Dokumen desain umum ini membantu kami mengevaluasi perubahan besar di seluruh produk Google Cloud secara konsisten. Diagram berikut menunjukkan tampilan proses desain standar kami untuk perubahan besar:
Fase desain dimulai saat developer software mengusulkan perubahan yang mengatasi persyaratan bisnis, teknis, biaya, dan pemeliharaan. Setelah mengirimkan perubahan tersebut, proses peninjauan dan persetujuan komprehensif akan dimulai dengan pakar senior, termasuk pakar keandalan dan keamanan, serta pimpinan teknis. Pekerjaan untuk menerapkan perubahan hanya dapat dilanjutkan setelah engineer yang mengusulkan desain mengatasi semua masukan dari pakar dan setiap pakar menyetujui desain. Proses desain dan peninjauan ini mengurangi kemungkinan tim produk Google Cloud mulai mengerjakan perubahan yang dapat berdampak negatif pada pelanggan dalam produksi.
Aman seperti yang dikembangkan
Proses pengembangan kode kami meningkatkan kualitas dan keandalan kode kami. Setelah persetujuan perubahan yang diusulkan, proses pengembangan dimulai dengan orientasi komprehensif untuk engineer baru, termasuk pelatihan, bimbingan, dan masukan mendetail tentang perubahan kode yang diusulkan. Pendekatan pengembangan dan pengujian berlapis dengan pengujian manual dan otomatis terus memvalidasi kode di setiap tahap pengembangan. Setiap perubahan kode ditinjau secara menyeluruh untuk memastikan bahwa perubahan tersebut memenuhi standar tinggi Google.
Diagram berikut memberikan alur kerja yang menggambarkan tampilan proses pengembangan kita:
Fase pengembangan dimulai saat engineer mulai menulis kode dan pengujian unit dan integrasi yang sesuai. Selama fase ini, engineer dapat menjalankan pengujian yang mereka tulis dan serangkaian pengujian pra-pengiriman untuk memastikan bahwa penambahan dan perubahan kode valid. Setelah menyelesaikan perubahan kode dan menjalankan pengujian, engineer meminta peninjauan manual dari orang lain yang sudah memahami kode tersebut. Proses peninjauan manual ini sering kali bersifat iteratif dan dapat menghasilkan revisi kode tambahan. Jika penulis dan peninjau mencapai konsensus, penulis akan mengirimkan kode.
Standar coding memastikan perubahan berkualitas tinggi
Budaya, praktik, dan alat engineering Google dirancang untuk memastikan bahwa kode kami benar, jelas, ringkas, dan efisien. Pengembangan kode di Google berlangsung di monorepo kami, repositori kode terintegrasi terbesar di dunia. Monorepo menyimpan jutaan file sumber, miliaran baris kode, dan memiliki histori ratusan juta commit yang disebut daftar perubahan. Jumlahnya terus bertambah dengan cepat, dengan puluhan ribu daftar perubahan baru yang ditambahkan setiap hari kerja. Manfaat utama monorepo adalah memfasilitasi penggunaan kembali kode, mempermudah pengelolaan dependensi, dan menerapkan alur kerja developer yang konsisten di seluruh produk dan layanan.
Penggunaan kembali kode sangat membantu karena kita sudah memiliki gambaran yang baik tentang performa kode yang digunakan kembali dalam produksi. Dengan memanfaatkan kode berkualitas tinggi yang sudah ada, perubahan secara inheren lebih andal dan lebih mudah dikelola sesuai standar yang diperlukan. Praktik ini tidak hanya menghemat waktu dan tenaga, tetapi juga memastikan bahwa kesehatan codebase secara keseluruhan tetap tinggi, sehingga menghasilkan produk yang lebih andal.
Layanan Google Cloud yang dibuat berdasarkan software open source berkualitas tinggi dapat melengkapi monorepo dengan repositori lain — biasanya Git — untuk menggunakan cabang guna mengelola software open source.
Catatan tentang pelatihan
Investasi dalam kualitas kode dimulai saat engineer bergabung dengan tim. Jika engineer masih baru di Google, atau kurang memahami infrastruktur dan arsitektur tim, mereka akan menjalani orientasi yang ekstensif. Sebagai bagian dari orientasi ini, mereka mempelajari panduan gaya, praktik terbaik, dan panduan pengembangan, serta melakukan latihan praktis secara manual. Selain itu, engineer baru memerlukan tingkat persetujuan tambahan untuk setiap pengiriman daftar perubahan. Persetujuan untuk perubahan dalam bahasa pemrograman tertentu diberikan oleh engineer yang telah lulus serangkaian ekspektasi yang ketat berdasarkan keahlian mereka dan telah memperoleh keterbacaan dalam bahasa pemrograman tersebut. Setiap engineer dapat memperoleh keterbacaan untuk bahasa pemrograman — sebagian besar tim memiliki beberapa pemberi persetujuan untuk bahasa pemrograman yang mereka gunakan untuk membuat kode.
Shift left meningkatkan kecepatan secara aman
Pengujian kemampuan awal adalah prinsip yang memindahkan pengujian dan validasi lebih awal dalam proses pengembangan. Prinsip ini didasarkan pada pengamatan kami bahwa biaya akan meningkat secara drastis di kemudian hari dalam proses rilis saat kita menemukan dan memperbaiki bug. Dalam kasus ekstrem, pertimbangkan bug yang ditemukan pelanggan dalam produksi. Bug ini dapat berdampak negatif pada workload dan aplikasi pelanggan, dan pelanggan mungkin juga perlu melalui proses Layanan Pelanggan Cloud sebelum tim engineer yang relevan dapat memitigasi bug tersebut. Jika engineer yang ditugaskan untuk menangani masalah tersebut bukan orang yang awalnya memperkenalkan perubahan yang berisi bug, engineer baru harus memahami perubahan kode, yang kemungkinan akan memperpanjang waktu yang diperlukan untuk mereproduksi dan akhirnya memperbaiki bug. Seluruh proses ini memerlukan banyak waktu dari pelanggan dan dukungan Google Cloud, serta menuntut engineer untuk menghentikan pekerjaan mereka untuk memperbaiki sesuatu.
Sebaliknya, pertimbangkan bug yang terdeteksi oleh kegagalan pengujian otomatis saat engineer sedang mengerjakan perubahan yang sedang dalam pengembangan. Saat melihat kegagalan pengujian, engineer dapat segera memperbaikinya. Karena standar coding kami, engineer bahkan tidak akan dapat mengirimkan perubahan dengan kegagalan pengujian. Deteksi awal ini berarti bahwa engineer dapat memperbaiki bug tanpa dampak pelanggan, dan tidak ada overhead pengalihan konteks.
Skenario kedua jauh lebih disukai oleh semua pihak yang terlibat. Akibatnya, selama bertahun-tahun, Google Cloud telah banyak berinvestasi dalam prinsip shift left ini, dengan memindahkan pengujian yang biasanya dilakukan selama fase kualifikasi perubahan dan peluncuran langsung ke loop pengembangan. Saat ini, semua pengujian unit, semua pengujian integrasi kecuali yang terbesar, dan analisis statis dan dinamis yang ekstensif selesai secara paralel saat engineer mengusulkan perubahan kode.
Pengujian pra-pengiriman otomatis menerapkan standar coding
Pengujian pra-pengiriman adalah pemeriksaan yang berjalan sebelum perubahan apa pun dikirimkan di direktori tertentu. Pengujian pra-pengiriman dapat berupa pengujian unit dan integrasi yang khusus untuk perubahan atau pengujian umum (misalnya, analisis statis dan dinamis) yang berjalan untuk perubahan apa pun. Secara historis, pengujian pra-pengiriman dijalankan sebagai langkah terakhir sebelum seseorang mengirimkan perubahan ke codebase. Saat ini, sebagian karena prinsip shift left dan penerapan CI, kami menjalankan pengujian pra-pengiriman secara berkelanjutan saat engineer membuat perubahan kode di lingkungan pengembangan dan sebelum menggabungkan perubahan ke dalam monorepo kami. Engineer juga dapat menjalankan rangkaian pengujian pra-pengiriman secara manual dengan sekali klik di UI pengembangan, dan setiap pengujian pra-pengiriman akan otomatis berjalan untuk setiap daftar perubahan sebelum peninjauan kode manual.
Rangkaian pengujian pra-pengiriman biasanya mencakup pengujian unit, pengujian fuzz (fuzzing), pengujian integrasi hermetis, serta analisis kode statis dan dinamis. Untuk perubahan pada library inti atau kode yang digunakan secara luas di Google, developer menjalankan pra-pengiriman global. Pra-pengiriman global menguji perubahan terhadap seluruh codebase Google, sehingga meminimalkan risiko perubahan yang diusulkan berdampak negatif pada project atau sistem lain.
Pengujian unit dan integrasi
Pengujian menyeluruh merupakan bagian integral dari proses pengembangan kode. Semua orang diperlukan untuk menulis pengujian unit untuk perubahan kode dan kami terus melacak cakupan kode di tingkat project untuk memastikan kami memvalidasi perilaku yang diharapkan. Selain itu, kami mewajibkan setiap perjalanan pengguna yang penting memiliki pengujian integrasi yang digunakan untuk memvalidasi fungsi semua komponen dan dependensi yang diperlukan.
Pengujian unit dan semua pengujian integrasi kecuali yang terbesar dirancang untuk diselesaikan segera, dan dijalankan secara bertahap dengan paralelisme tinggi di lingkungan terdistribusi, sehingga menghasilkan masukan pengembangan otomatis yang cepat dan berkelanjutan.
Fuzzing
Pengujian unit dan integrasi membantu kita memvalidasi perilaku yang diharapkan dengan input dan output yang telah ditentukan sebelumnya, sedangkan fuzzing adalah teknik yang membombardir aplikasi dengan input acak, yang bertujuan untuk mengekspos kelemahan atau kekurangan yang tersembunyi yang dapat menyebabkan kerentanan keamanan atau error. Fuzzing memungkinkan kami mengidentifikasi dan mengatasi potensi kelemahan dalam software secara proaktif, sehingga meningkatkan keamanan dan keandalan produk secara keseluruhan sebelum pelanggan berinteraksi dengan perubahan. Keacakan pengujian ini sangat berguna karena pengguna terkadang berinteraksi dengan produk kita dengan cara menarik yang tidak kita duga, dan fuzzing membantu kita memperhitungkan skenario yang tidak kita pertimbangkan secara manual.
Analisis statis
Alat analisis statis berperan penting dalam mempertahankan kualitas kode dalam alur kerja pengembangan kami. Analisis statis telah berkembang secara signifikan sejak awal linting dengan ekspresi reguler untuk mengidentifikasi pola kode C++ yang bermasalah. Saat ini, analisis statis mencakup semua bahasa produksi Google Cloud, dan menemukan pola kode yang salah, tidak efisien, atau tidak digunakan lagi.
Dengan frontend compiler dan LLM lanjutan, kami dapat secara otomatis mengusulkan peningkatan saat engineer menulis kode. Setiap perubahan kode yang diusulkan diperiksa dengan analisis statis. Seiring waktu, kami menambahkan pemeriksaan statis baru, seluruh codebase terus dipindai untuk kepatuhan, dan perbaikan secara otomatis dibuat dan dikirim untuk ditinjau.
Analisis dinamis
Meskipun analisis statis berfokus pada identifikasi pola kode yang diketahui yang dapat menyebabkan masalah, analisis dinamis menggunakan pendekatan yang berbeda. Proses ini melibatkan kompilasi dan menjalankan kode untuk menemukan masalah yang hanya muncul selama eksekusi seperti pelanggaran memori dan kondisi perlombaan. Google memiliki sejarah panjang dalam menggunakan analisis dinamis, dan bahkan telah membagikan beberapa alatnya kepada komunitas developer yang lebih luas, termasuk yang berikut ini:
- AddressSanitizer: Mendeteksi error memori seperti buffer overflow dan use-after-free
- ThreadSanitizer (C++, Go): Menemukan data race dan bug threading lainnya
- MemorySanitizer: Mengungkap penggunaan memori yang tidak diinisialisasi
Alat ini dan alat lainnya yang serupa sangat penting untuk menemukan bug kompleks yang tidak dapat dideteksi melalui analisis statis saja. Dengan menggunakan analisis statis dan dinamis, Google berupaya memastikan bahwa kodenya terstruktur dengan baik, bebas dari masalah yang diketahui, dan berperilaku seperti yang diharapkan dalam skenario dunia nyata.
Peninjauan kode oleh manusia memvalidasi perubahan dan hasil pengujian
Saat engineer mencapai tonggak pencapaian penting dalam kode mereka dan ingin mengintegrasikannya ke dalam repositori utama, mereka memulai peninjauan kode dengan mengusulkan daftar perubahan. Permintaan peninjauan kode terdiri dari hal berikut:
- Deskripsi yang menjelaskan tujuan perubahan dan konteks tambahan apa pun
- Kode yang sebenarnya dimodifikasi
- Pengujian unit dan integrasi untuk kode yang diubah
- Hasil pengujian pra-pengiriman otomatis
Pada tahap ini dalam proses pengembangan, orang lain akan turun tangan. Satu atau beberapa peninjau yang ditunjuk akan memeriksa daftar perubahan dengan cermat untuk memastikan kebenaran dan kejelasannya, menggunakan pengujian yang dilampirkan dan hasil pra-pengiriman sebagai panduan. Setiap direktori kode memiliki serangkaian peninjau yang ditunjuk yang bertanggung jawab untuk memastikan kualitas subset codebase tersebut, dan persetujuan mereka diperlukan untuk membuat perubahan dalam direktori tersebut. Peninjau dan engineer berkolaborasi untuk menemukan dan mengatasi masalah yang mungkin timbul dengan perubahan kode yang diusulkan. Jika daftar perubahan memenuhi standar kami, peninjau akan memberikan persetujuan ("LGTM", singkatan dari "looks good to me"). Namun, jika engineer masih dalam pelatihan untuk bahasa pemrograman yang digunakan, mereka memerlukan persetujuan tambahan dari pakar yang telah mendapatkan keterbacaan dalam bahasa pemrograman.
Setelah daftar perubahan lulus pengujian dan pemeriksaan otomatis serta menerima LGTM, engineer yang mengusulkan perubahan hanya diizinkan untuk melakukan perubahan minimal pada kode. Setiap perubahan yang signifikan akan membatalkan persetujuan dan memerlukan putaran peninjauan lainnya. Bahkan perubahan kecil akan otomatis ditandai kepada peninjau asli. Setelah engineer mengirimkan kode yang telah selesai, kode tersebut akan melalui putaran pengujian pra-pengiriman penuh lainnya sebelum daftar perubahan digabungkan ke dalam monorepo. Jika ada pengujian yang gagal, kiriman akan ditolak, dan developer serta peninjau akan menerima pemberitahuan untuk mengambil tindakan korektif sebelum mencoba mengirimkan perubahan lagi.
Kualifikasi rilis aman
Meskipun pengujian pra-pengiriman bersifat komprehensif, pengujian ini bukanlah akhir dari proses pengujian di Google. Tim sering kali memiliki pengujian tambahan, seperti pengujian integrasi berskala besar, yang tidak dapat dijalankan selama peninjauan kode awal (pengujian ini mungkin memerlukan waktu lebih lama untuk dijalankan atau memerlukan lingkungan pengujian fidelitas tinggi). Selain itu, tim perlu mengetahui kegagalan yang disebabkan oleh faktor di luar kendali mereka, seperti perubahan pada dependensi eksternal.
Itulah sebabnya Google mewajibkan fase kualifikasi setelah fase pengembangan. Fase kualifikasi ini menggunakan proses build dan pengujian berkelanjutan, seperti yang ditunjukkan dalam diagram berikut:
Proses ini secara berkala menjalankan pengujian untuk semua kode yang terpengaruh oleh perubahan langsung atau tidak langsung sejak pengujian terakhir. Setiap kegagalan akan otomatis dieskalasikan ke tim engineer yang bertanggung jawab. Dalam banyak kasus, sistem dapat secara otomatis mengidentifikasi daftar perubahan yang menyebabkan kerusakan, dan melakukan rollback. Pengujian integrasi skala besar ini dijalankan dalam spektrum lingkungan staging yang beralih dari lingkungan yang disimulasikan sebagian ke seluruh lokasi fisik.
Pengujian memiliki berbagai sasaran kualifikasi yang berkisar dari keandalan dan keamanan dasar hingga logika bisnis. Pengujian kualifikasi ini mencakup pengujian kode untuk hal berikut:
- Kemampuan untuk memberikan fungsi yang diperlukan, yang diuji dengan menggunakan pengujian integrasi skala besar
- Kemampuan untuk memenuhi persyaratan bisnis, yang diuji dengan representasi sintetis dari beban kerja pelanggan
- Kemampuan untuk mempertahankan kegagalan infrastruktur yang mendasarinya, yang diuji dengan menggunakan injeksi kegagalan di seluruh stack
- Kemampuan untuk mempertahankan kapasitas penayangan, yang diuji dengan framework pengujian beban
- Kemampuan untuk melakukan rollback dengan aman
Peluncuran yang aman
Meskipun dengan proses pengembangan, pengujian, dan kualifikasi yang paling kuat, cacat terkadang menyelinap ke lingkungan produksi yang berdampak negatif pada pengguna kami. Di bagian ini, kami menjelaskan cara proses peluncuran Google Cloud membatasi dampak perubahan yang rusak dan memastikan deteksi regresi yang cepat. Kami menerapkan pendekatan ini untuk semua jenis perubahan yang di-deploy ke produksi, termasuk biner, konfigurasi, update skema, perubahan kapasitas, dan daftar kontrol akses.
Perubahan propagasi dan pengawasan
Kami menerapkan pendekatan yang konsisten untuk men-deploy perubahan di seluruh Google Cloud guna meminimalkan dampak negatif bagi pelanggan, dan mengisolasi masalah ke setiap domain kegagalan logis dan fisik. Proses ini didasarkan pada praktik keandalan SRE yang telah kami terapkan selama puluhan tahun dan pada sistem pemantauan skala planet kami untuk mendeteksi dan memitigasi perubahan buruk secepat mungkin. Deteksi cepat memungkinkan kami memberi tahu pelanggan lebih cepat dan mengambil tindakan korektif untuk secara sistematis mencegah kegagalan serupa terjadi lagi.
Sebagian besar produk Google Cloud bersifat regional atau zonal. Artinya, produk regional yang berjalan di Region A tidak bergantung pada produk yang sama yang berjalan di Region B. Demikian pula, produk zona yang berjalan di Zona C dalam Region A tidak bergantung pada produk zona yang sama yang berjalan di Zona D dalam Region A. Arsitektur ini meminimalkan risiko pemadaman yang memengaruhi region lain atau zona lain dalam satu region. Beberapa layanan, seperti IAM atau Konsol Google Cloud, menyediakan lapisan yang konsisten secara global yang mencakup semua region, itulah sebabnya kami menyebutnya layanan global. Layanan global direplikasi di seluruh region, untuk menghindari titik tunggal kegagalan dan meminimalkan latensi. Platform peluncuran Google Cloud bersama mengetahui apakah layanan bersifat zonal, regional, atau global, dan mengatur perubahan produksi dengan tepat.
Proses peluncuran Google Cloud membagi semua replika layanan yang di-deploy di beberapa lokasi target menjadi beberapa gelombang. Gelombang awal mencakup sejumlah replika yang sedikit, dengan update yang dilakukan secara berurutan. Gelombang awal menyeimbangkan pelindungan sebagian besar beban kerja pelanggan dengan memaksimalkan eksposur terhadap keragaman beban kerja untuk mendeteksi masalah sedini mungkin, dan menyertakan beban kerja sintetis yang meniru pola beban kerja pelanggan umum.
Jika peluncuran tetap berhasil saat replika layanan diperbarui di lokasi target, gelombang peluncuran berikutnya akan meningkat secara bertahap dan memperkenalkan lebih banyak paralelisme. Meskipun beberapa paralelisme diperlukan untuk memperhitungkan jumlah lokasi Google Cloud, kami tidak mengizinkan update serentak ke lokasi yang berada dalam gelombang yang berbeda. Jika gelombang berlangsung hingga malam hari atau akhir pekan, gelombang tersebut dapat menyelesaikan progresnya, tetapi tidak ada gelombang baru yang dapat dimulai hingga awal jam buka untuk tim yang mengelola peluncuran.
Diagram berikut adalah contoh alur kerja yang menggambarkan logika peluncuran yang kami gunakan di seluruh Google Cloud untuk produk dan layanan regional:
Proses peluncuran Google Cloud menggunakan Canary Analysis Service (CAS) untuk mengotomatiskan pengujian A/B selama durasi peluncuran. Beberapa replika menjadi canary (yaitu, deployment perubahan sebagian dan terbatas waktu dalam layanan), dan replika yang tersisa membentuk grup kontrol yang tidak menyertakan perubahan. Setiap langkah proses peluncuran memiliki waktu pembuatan untuk mendeteksi masalah yang lambat sebelum melanjutkan ke langkah berikutnya untuk memastikan bahwa semua fungsi layanan dijalankan dengan baik dan potensi anomali terdeteksi oleh CAS. Waktu proses ditentukan dengan cermat untuk menyeimbangkan deteksi masalah yang muncul secara perlahan dengan kecepatan pengembangan. Peluncuran Google Cloud biasanya memerlukan waktu satu minggu.
Diagram ini memberikan ringkasan cepat tentang tampilan alur kerja CAS:
Alur kerja dimulai dengan alat peluncuran yang men-deploy perubahan ke replika canary. Alat peluncuran kemudian meminta verdict dari CAS. CAS mengevaluasi replika canary terhadap grup kontrol dan menampilkan verdict PASS atau FAIL. Jika sinyal kondisi gagal, pemberitahuan akan dibuat untuk pemilik layanan dan langkah peluncuran yang sedang berjalan akan dijeda atau di-roll back. Jika perubahan tersebut menyebabkan gangguan bagi pelanggan eksternal, insiden eksternal akan dideklarasikan dan pelanggan yang terpengaruh akan diberi tahu menggunakan layanan Personalisasi Status Layanan. Insiden juga memicu peninjauan internal. Filosofi Post-Mortem Google memastikan bahwa serangkaian tindakan korektif yang tepat diidentifikasi dan diterapkan untuk meminimalkan kemungkinan kegagalan serupa terjadi lagi.
Memantau sinyal dan keamanan pasca-peluncuran
Cacat software tidak selalu muncul secara instan, dan beberapa mungkin memerlukan keadaan tertentu untuk dipicu. Oleh karena itu, kami terus memantau sistem produksi setelah peluncuran selesai. Selama bertahun-tahun, kami telah memperhatikan bahwa meskipun peluncuran tidak langsung memicu masalah apa pun, peluncuran yang buruk masih menjadi penyebab paling mungkin dari insiden produksi. Oleh karena itu, playbook produksi kami menginstruksikan petugas responder insiden untuk mengaitkan peluncuran terbaru dengan masalah yang diamati, dan secara default melakukan roll back peluncuran terbaru jika petugas responder insiden tidak dapat mengesampingkan perubahan terbaru sebagai akar masalah insiden.
Pemantauan pasca-peluncuran dibuat berdasarkan kumpulan sinyal pemantauan yang sama dengan yang kami gunakan untuk analisis A/B otomatis selama periode peluncuran. Filosofi pemantauan dan pemberitahuan Google Cloud menggabungkan dua jenis pemantauan: introspektif (juga dikenal sebagai white-box) dan sintetis (juga dikenal sebagai black-box). Pemantauan introspektif menggunakan metrik seperti penggunaan CPU, penggunaan memori, dan data layanan internal lainnya. Pemantauan sintetis melihat perilaku sistem dari perspektif pelanggan, melacak tingkat error layanan, dan respons terhadap traffic sintetis dari layanan pemeriksa. Pemantauan sintetis berorientasi pada gejala dan mengidentifikasi masalah aktif, sedangkan pemantauan introspektif memungkinkan kita mendiagnosis masalah yang dikonfirmasi, dan dalam beberapa kasus mengidentifikasi masalah yang akan segera terjadi.
Untuk membantu mendeteksi insiden yang hanya memengaruhi beberapa pelanggan, kami mengelompokkan beban kerja pelanggan ke dalam kelompok beban kerja terkait. Notifikasi dipicu begitu performa kelompok menyimpang dari norma. Notifikasi ini memungkinkan kami mendeteksi regresi khusus pelanggan meskipun performa gabungan tampaknya normal.
Perlindungan supply chain software
Setiap kali tim Google Cloud memperkenalkan perubahan, kami menggunakan pemeriksaan keamanan yang disebut Otorisasi Biner untuk Borg (BAB) untuk melindungi supply chain software dan pelanggan Cloud kami dari risiko pihak internal. BAB dimulai pada tahap peninjauan kode dan membuat jejak audit kode dan konfigurasi yang di-deploy ke produksi. Untuk memastikan integritas produksi, BAB hanya mengizinkan perubahan yang memenuhi kriteria berikut:
- Tidak dapat dimodifikasi dan ditandatangani
- Berasal dari pihak build yang diidentifikasi dan lokasi sumber yang diidentifikasi
- Telah ditinjau dan disetujui secara eksplisit oleh pihak yang berbeda dengan penulis kode
Jika Anda tertarik untuk menerapkan beberapa konsep yang sama dalam siklus proses pengembangan software Anda sendiri, kami menyertakan konsep utama BAB dalam spesifikasi terbuka yang disebut Supply-chain Levels for Software Artifacts (SLSA). SLSA berfungsi sebagai framework keamanan untuk mengembangkan dan menjalankan kode di lingkungan produksi.
Kesimpulan
Google Cloud dibangun berdasarkan investasi Google selama puluhan tahun dalam keunggulan pengembangan. Kualitas kode dan kualitas produksi adalah prinsip budaya yang ditanamkan di semua tim engineer di Google. Proses peninjauan desain kami memastikan bahwa implikasi pada kode dan kesehatan produksi dipertimbangkan sejak awal. Proses pengembangan kami, berdasarkan prinsip shift left dan pengujian yang ekstensif, memastikan bahwa ide desain diterapkan dengan aman dan benar. Proses kualifikasi kami lebih lanjut memperluas pengujian untuk mencakup integrasi skala besar dan dependensi eksternal. Terakhir, platform peluncuran kami memungkinkan kami meningkatkan keyakinan secara bertahap bahwa perubahan tertentu benar-benar berperilaku seperti yang diharapkan. Dengan cakupan dari konsep hingga produksi, pendekatan kami memungkinkan kami memenuhi ekspektasi pelanggan Google Cloud terkait kecepatan dan keandalan pengembangan.