Miliaran pengguna berinteraksi dengan produk dan layanan Google setiap tahun. Penawaran utama seperti Penelusuran, Gmail, Maps, YouTube, Chrome, dan kini jugaGoogle Cloud, terintegrasi dengan lancar ke dalam kehidupan modern sehingga membantu mendefinisikan 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, baik besar maupun kecil, terkadang dapat merusak sesuatu. Untuk mengatasi risiko tersebut, kami memprioritaskan keamanan perubahan di seluruh siklus proses perubahan.
Dokumen ini menjelaskan cara tim Google Cloud mengembangkan investasi Google selama puluhan tahun dalam keunggulan pengembangan untuk menerapkan praktik terbaik keandalan dan standar teknik yang memenuhi Google Cloud ekspektasi pelanggan terhadap kecepatan dan keandalan pengembangan.
Masa berlaku perubahan di Google Cloud
Google Cloud tim produk berbagi sebagian besar proses dan alat pengelolaan 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 kali mengusulkan, menguji, dan mengirimkan perubahan, sering kali beberapa kali sehari untuk produk atau layanan tertentu. CD adalah ekstensi CI yang memungkinkan engineer terus-menerus menyiapkan kandidat rilis berdasarkan snapshot terbaru dan stabil dari codebase.
Pendekatan ini memprioritaskan pembuatan dan peluncuran perubahan secara bertahap kepada pelanggan secepat mungkin, tetapi juga seaman mungkin.Google Cloud 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 lebih mendetail di seluruh dokumen ini:
Didesain agar aman
Kami menyadari bahwa kesalahan kecil di awal proses pengembangan dapat menyebabkan masalah besar di kemudian hari yang berdampak signifikan pada pengalaman pelanggan. Oleh karena itu, kami mewajibkan semua perubahan besar dimulai dengan dokumen desain yang disetujui. Kami memiliki template dokumen desain umum bagi tim engineering untuk mengusulkan perubahan besar. Dokumen desain umum ini membantu kami mengevaluasi perubahan besar di seluruh produk secara konsisten.Google Cloud Diagram berikut menunjukkan tampilan proses desain standar kami untuk perubahan besar:
Fase desain dimulai saat developer software mengusulkan perubahan yang memenuhi persyaratan bisnis, teknis, biaya, dan pemeliharaan. Setelah mengirimkan perubahan tersebut, proses peninjauan dan persetujuan yang komprehensif akan dimulai dengan pakar senior, termasuk pakar keandalan dan keamanan, serta pimpinan teknis. Pengerjaan untuk menerapkan perubahan hanya dapat dilakukan setelah engineer yang mengusulkan desain menanggapi semua masukan dari pakar dan setiap pakar menyetujui desain tersebut. Proses desain dan peninjauan ini mengurangi kemungkinan tim produkGoogle Cloud bahkan 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 atas perubahan yang diusulkan, proses pengembangan dimulai dengan orientasi yang komprehensif bagi engineer baru, termasuk pelatihan, bimbingan, dan masukan mendetail tentang perubahan kode yang diusulkan. Pendekatan pengembangan dan pengujian berlapis-lapis 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 perkiraan tampilan proses pengembangan kami:
Fase pengembangan dimulai saat engineer mulai menulis kode dan pengujian unit dan integrasi yang sesuai. Selama fase ini, engineer dapat menjalankan pengujian yang ditulisnya dan rangkaian pengujian pra-pengiriman untuk memastikan penambahan dan perubahan kode valid. Setelah menyelesaikan perubahan kode dan menjalankan pengujian, engineer meminta peninjauan manual dari orang lain yang memahami kode tersebut. Proses peninjauan manual ini sering kali bersifat iteratif dan dapat menghasilkan revisi kode tambahan. Saat penulis dan pengulas mencapai konsensus, penulis mengirimkan kode.
Standar coding memastikan perubahan berkualitas tinggi
Budaya, praktik, dan alat rekayasa Google dirancang untuk memastikan bahwa kode kami benar, jelas, ringkas, dan efisien. Pengembangan kode di Google dilakukan 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. Perkembangannya terus pesat, dengan puluhan ribu daftar perubahan baru 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 bermanfaat 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 kualitas keseluruhan codebase tetap tinggi, sehingga menghasilkan produk yang lebih andal.
Google Cloud layanan yang dibangun di atas software open source berkualitas tinggi dapat melengkapi monorepo dengan repositori lain — biasanya Git — untuk menggunakan percabangan guna mengelola software open source.
Catatan tentang pelatihan
Investasi dalam kualitas kode dimulai saat seorang engineer bergabung dengan tim. Jika engineer tersebut baru di Google, atau kurang memahami infrastruktur dan arsitektur tim, dia akan menjalani proses orientasi yang ekstensif. Sebagai bagian dari aktivasi 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 memenuhi serangkaian ekspektasi ketat berdasarkan keahlian mereka dan telah mendapatkan 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.
Menerapkan langkah-langkah keamanan secara keseluruhan akan meningkatkan kecepatan dengan aman
Pengujian kemampuan awal adalah prinsip yang memindahkan pengujian dan validasi ke tahap awal dalam proses pengembangan. Prinsip ini didasarkan pada pengamatan kami bahwa biaya akan meningkat secara signifikan jika kita menemukan dan memperbaiki bug di tahap akhir proses rilis. 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 engineering yang relevan dapat mengurangi dampak bug tersebut. Jika engineer yang ditugaskan untuk mengatasi masalah tersebut adalah orang yang berbeda dengan orang yang awalnya memperkenalkan perubahan yang berisi bug, engineer baru tersebut harus memahami perubahan kode, yang kemungkinan akan menambah waktu yang diperlukan untuk mereproduksi dan akhirnya memperbaiki bug. Seluruh proses ini memerlukan banyak waktu dari dukungan pelanggan dan Google Cloud, serta mengharuskan engineer menghentikan pekerjaan yang sedang mereka lakukan untuk memperbaiki sesuatu.
Sebaliknya, pertimbangkan bug yang terdeteksi oleh kegagalan pengujian otomatis saat engineer sedang mengerjakan perubahan yang masih dalam pengembangan. Saat melihat kegagalan pengujian, engineer dapat segera memperbaikinya. Karena standar coding kami, teknisi bahkan tidak dapat mengirimkan perubahan dengan kegagalan pengujian. Deteksi awal ini berarti engineer dapat memperbaiki bug tanpa berdampak pada pelanggan, dan tidak ada overhead pengalihan konteks.
Skenario terakhir jauh lebih baik bagi semua pihak yang terlibat. Oleh karena itu, selama bertahun-tahun, Google Cloud telah banyak berinvestasi dalam prinsip shift left ini, dengan memindahkan pengujian yang biasanya dilakukan selama kualifikasi perubahan dan fase peluncuran langsung ke dalam loop pengembangan. Saat ini, semua pengujian unit, semua pengujian integrasi kecuali yang terbesar, serta analisis statis dan dinamis yang ekstensif diselesaikan secara paralel saat engineer mengusulkan perubahan kode.
Pengujian pra-kirim otomatis menerapkan standar coding
Pengujian pra-pengiriman adalah pemeriksaan yang dijalankan sebelum perubahan dikirimkan di direktori tertentu. Pengujian pra-submit dapat berupa pengujian unit dan integrasi khusus untuk perubahan atau pengujian umum (misalnya, analisis statis dan dinamis) yang dijalankan untuk perubahan apa pun. Secara historis, pengujian pra-kirim dijalankan sebagai langkah terakhir sebelum seseorang mengirimkan perubahan ke codebase. Saat ini, sebagian karena prinsip shift left dan penerapan CI, kami menjalankan pengujian pra-kirim secara berkelanjutan saat engineer membuat perubahan kode di lingkungan pengembangan dan sebelum menggabungkan perubahan ke monorepo kami. Engineer juga dapat menjalankan rangkaian pengujian pra-kirim secara manual dengan satu klik di UI pengembangan, dan setiap pengujian pra-kirim akan otomatis dijalankan untuk setiap daftar perubahan sebelum peninjauan kode manual.
Rangkaian pengujian pra-pengiriman umumnya mencakup pengujian unit, pengujian fuzz (fuzzing), pengujian integrasi hermetik, serta analisis kode statis dan dinamis. Untuk perubahan pada library inti atau kode yang digunakan secara luas di Google, developer menjalankan pra-commit global. Pengujian pra-submit global menguji perubahan terhadap seluruh codebase Google, sehingga meminimalkan risiko bahwa perubahan yang diusulkan akan berdampak negatif pada project atau sistem lain.
Pengujian unit dan integrasi
Pengujian menyeluruh merupakan bagian integral dari proses pengembangan kode. Semua orang diwajibkan 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 penting memiliki pengujian integrasi yang memvalidasi fungsionalitas semua komponen dan dependensi yang diperlukan.
Pengujian unit dan semua pengujian integrasi kecuali yang terbesar dirancang untuk diselesaikan dengan cepat, dan dieksekusi secara inkremental dengan paralelisme tinggi dalam lingkungan terdistribusi, sehingga menghasilkan masukan pengembangan otomatis yang cepat dan berkelanjutan.
Fuzzing
Meskipun pengujian unit dan integrasi membantu kita memvalidasi perilaku yang diharapkan dengan input dan output yang telah ditentukan sebelumnya, fuzzing adalah teknik yang membanjiri aplikasi dengan input acak, yang bertujuan untuk mengekspos kekurangan atau kelemahan tersembunyi yang dapat menyebabkan kerentanan keamanan atau error. Fuzzing memungkinkan kami mengidentifikasi dan mengatasi potensi kelemahan dalam software kami secara proaktif, sehingga meningkatkan keamanan dan keandalan produk kami secara keseluruhan sebelum pelanggan berinteraksi dengan perubahan. Keacakan pengujian ini sangat berguna karena pengguna terkadang berinteraksi dengan produk kami dengan cara yang menarik dan tidak kami duga, dan fuzzing membantu kami memperhitungkan skenario yang tidak kami pertimbangkan secara manual.
Analisis statis
Alat analisis statis berperan penting dalam menjaga kualitas kode dalam alur kerja pengembangan kami. Analisis statis telah berkembang secara signifikan dari awal penggunaannya untuk melakukan linting dengan ekspresi reguler guna mengidentifikasi pola kode C++ yang bermasalah. Saat ini, analisis statis mencakup semua bahasa produksi, dan menemukan pola kode yang salah, tidak efisien, atau tidak digunakan lagi. Google Cloud
Dengan frontend compiler dan LLM canggih, kami dapat secara otomatis menyarankan peningkatan saat engineer menulis kode. Setiap perubahan kode yang diusulkan diperiksa dengan analisis statis. Seiring waktu, kami akan menambahkan pemeriksaan statis baru, sehingga seluruh codebase terus dipindai untuk memastikan kepatuhan, dan perbaikan akan 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. Hal ini melibatkan kompilasi dan menjalankan kode untuk menemukan masalah yang hanya muncul selama eksekusi seperti pelanggaran memori dan kondisi persaingan. Google memiliki sejarah panjang dalam memanfaatkan 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 belum diinisialisasi
Alat ini dan alat lainnya yang serupa sangat penting untuk menemukan bug kompleks yang tidak dapat dideteksi hanya melalui analisis statis. 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 mencapai tonggak penting dalam kodenya dan ingin mengintegrasikannya ke repositori utama, engineer akan memulai peninjauan kode dengan mengusulkan daftar perubahan. Permintaan peninjauan kode terdiri dari hal berikut:
- Deskripsi yang menjelaskan tujuan perubahan dan konteks tambahan
- Kode yang benar-benar dimodifikasi
- Pengujian unit dan integrasi untuk kode yang diubah
- Hasil pengujian pra-pengiriman otomatis
Pada titik ini dalam proses pengembangan, manusia lain akan terlibat. Satu atau beberapa peninjau yang ditunjuk akan memeriksa daftar perubahan dengan cermat untuk memastikan kebenaran dan kejelasan, menggunakan pengujian terlampir dan hasil pra-pengiriman sebagai panduan. Setiap direktori kode memiliki serangkaian peninjau yang ditunjuk dan bertanggung jawab untuk memastikan kualitas subset codebase tersebut, dan yang persetujuannya diperlukan untuk melakukan perubahan dalam direktori tersebut. Peninjau dan engineer berkolaborasi untuk menemukan dan mengatasi masalah yang mungkin muncul dengan perubahan kode yang diusulkan. Jika daftar perubahan memenuhi standar kami, peninjau akan memberikan persetujuannya ("LGTM", singkatan dari "looks good to me"). Namun, jika engineer masih dalam pelatihan untuk bahasa pemrograman yang digunakan, dia memerlukan persetujuan tambahan dari pakar yang telah memperoleh keterbacaan dalam bahasa pemrograman tersebut.
Setelah daftar perubahan lolos pengujian dan pemeriksaan otomatis serta menerima LGTM, engineer yang mengusulkan perubahan hanya diizinkan melakukan perubahan minimal pada kode. Perubahan substansial akan membatalkan persetujuan dan memerlukan putaran peninjauan lainnya. Bahkan perubahan kecil akan otomatis ditandai kepada peninjau asli. Setelah engineer mengirimkan kode akhir, kode tersebut akan melalui putaran pengujian pra-pengiriman penuh lainnya sebelum daftar perubahan digabungkan ke dalam monorepo. Jika ada pengujian yang gagal, pengiriman akan ditolak, dan developer serta peninjau akan menerima notifikasi untuk melakukan tindakan perbaikan sebelum mencoba mengirimkan perubahan lagi.
Kualifikasi rilis aman
Meskipun pengujian pra-pengiriman komprehensif, pengujian ini bukan akhir dari proses pengujian di Google. Tim sering kali memiliki pengujian tambahan, seperti pengujian integrasi skala besar, yang tidak dapat dijalankan selama peninjauan kode awal (pengujian ini mungkin memerlukan waktu lebih lama untuk dijalankan atau memerlukan lingkungan pengujian dengan fidelitas tinggi). Selain itu, tim harus mengetahui kegagalan yang disebabkan oleh faktor di luar kendali mereka, seperti perubahan pada dependensi eksternal.
Itulah sebabnya Google memerlukan 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 dijalankan terakhir kali. Kegagalan apa pun akan otomatis diteruskan kepada tim engineering yang bertanggung jawab. Dalam banyak kasus, sistem dapat secara otomatis mengidentifikasi daftar perubahan yang menyebabkan kerusakan, dan mengembalikannya. Pengujian integrasi skala besar ini dijalankan dalam spektrum lingkungan staging yang berkisar dari lingkungan yang disimulasikan sebagian hingga 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 menggunakan pengujian integrasi skala besar
- Kemampuan untuk memenuhi persyaratan bisnis, yang diuji dengan representasi sintetis workload 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 roll back dengan aman
Peluncuran yang aman
Meskipun dengan proses pengembangan, pengujian, dan kualifikasi yang paling ketat, kerusakan terkadang masuk ke lingkungan produksi yang berdampak negatif bagi pengguna kami. Di bagian ini, kami menjelaskan cara Google Cloud proses peluncuran membatasi dampak perubahan yang rusak dan memastikan deteksi cepat terhadap regresi. Kami menerapkan pendekatan ini untuk semua jenis perubahan yang di-deploy ke produksi, termasuk biner, konfigurasi, update skema, perubahan kapasitas, dan daftar kontrol akses.
Penyebaran dan pengawasan perubahan
Kami menerapkan pendekatan yang konsisten untuk men-deploy perubahan di seluruh Google Cloud untuk meminimalkan dampak negatif terhadap pelanggan, dan mengisolasi masalah ke domain kegagalan logis dan fisik individual. Proses ini dibangun berdasarkan praktik keandalan SRE kami selama puluhan tahun dan 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 mencegah kegagalan serupa terjadi lagi secara sistematis.
Sebagian besar Google Cloud produk 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 konsolGoogle 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 kecil replika, dengan update yang dilakukan secara berurutan. Gelombang awal menyeimbangkan perlindungan sebagian besar workload pelanggan dengan memaksimalkan eksposur terhadap keragaman workload untuk mendeteksi masalah sedini mungkin, dan menyertakan workload sintetis yang meniru pola workload pelanggan umum.
Jika peluncuran tetap berhasil saat replika layanan diperbarui di lokasi target, gelombang peluncuran berikutnya akan meningkat secara progresif dalam ukuran dan memperkenalkan lebih banyak paralelisme. Meskipun beberapa paralelisme diperlukan untuk memperhitungkan jumlah lokasi, kami tidak mengizinkan pembaruan serentak ke lokasi yang berada dalam gelombang berbeda. Google Cloud Jika gelombang berlanjut hingga malam atau akhir pekan, gelombang tersebut dapat menyelesaikan progresnya, tetapi tidak ada gelombang baru yang dapat dimulai hingga awal jam kerja tim yang mengelola peluncuran.
Diagram berikut adalah contoh alur kerja yang mengilustrasikan 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 pematangan untuk menangkap masalah yang muncul secara perlahan sebelum melanjutkan ke langkah berikutnya untuk memastikan semua fungsi layanan berjalan dengan baik dan potensi anomali terdeteksi oleh CAS. Waktu pemrosesan ditentukan dengan cermat untuk menyeimbangkan deteksi masalah yang muncul secara perlahan dengan kecepatan pengembangan.Peluncuran biasanya memerlukan waktu satu minggu. Google Cloud
Diagram ini memberikan ringkasan singkat tentang tampilan alur kerja CAS:
Alur kerja dimulai dengan alat peluncuran yang men-deploy perubahan ke replika canary. Kemudian, alat peluncuran akan meminta verdict dari CAS. CAS mengevaluasi replika canary terhadap grup kontrol dan menampilkan putusan LULUS atau GAGAL. Jika ada sinyal kondisi yang gagal, pemberitahuan akan dibuat untuk pemilik layanan dan langkah peluncuran yang sedang berjalan akan dijeda atau di-roll back. Jika perubahan menyebabkan gangguan pada pelanggan eksternal, insiden eksternal akan dinyatakan dan pelanggan yang terpengaruh akan diberi tahu menggunakan layanan Kesehatan Layanan yang Dipersonalisasi. Insiden juga memicu peninjauan internal. Filosofi Post-mortem Google memastikan bahwa serangkaian tindakan korektif yang tepat diidentifikasi dan diterapkan untuk meminimalkan kemungkinan terjadinya kegagalan serupa lagi.
Memantau sinyal dan keamanan setelah peluncuran
Cacat software tidak selalu muncul secara instan, dan beberapa di antaranya mungkin memerlukan kondisi tertentu untuk memicu. 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 tetap menjadi penyebab paling mungkin terjadinya insiden produksi. Oleh karena itu, playbook produksi kami menginstruksikan petugas responder insiden untuk mengorelasikan peluncuran terbaru dengan masalah yang diamati, dan secara default melakukan roll back peluncuran terbaru jika petugas responder insiden tidak dapat mengesampingkan perubahan terbaru sebagai penyebab utama insiden.
Pemantauan pasca-peluncuran didasarkan pada kumpulan sinyal pemantauan yang sama 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 pemakaian CPU, pemakaian memori, dan data layanan internal lainnya. Pemantauan sintetis melihat perilaku sistem dari perspektif pelanggan, melacak tingkat kesalahan layanan dan respons terhadap traffic sintetis dari layanan pemeriksa. Pemantauan sintetis berorientasi pada gejala dan mengidentifikasi masalah aktif, sedangkan pemantauan introspektif memungkinkan kami mendiagnosis masalah yang telah 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 kohor beban kerja terkait. Pemberitahuan dipicu segera setelah performa kohor menyimpang dari norma. Dengan pemberitahuan ini, kami dapat mendeteksi regresi khusus pelanggan meskipun performa gabungan tampak normal.
Perlindungan supply chain software
Setiap kali tim 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. Google Cloud BAB dimulai pada tahap peninjauan kode dan membuat jejak audit kode dan konfigurasi yang di-deploy ke produksi. Untuk memastikan integritas produksi, BAB hanya menerima perubahan yang memenuhi kriteria berikut:
- Tahan terhadap upaya manipulasi dan ditandatangani
- Berasal dari pesta pembuatan yang teridentifikasi dan lokasi sumber yang teridentifikasi
- Telah ditinjau dan disetujui secara eksplisit oleh pihak yang berbeda dari 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 beberapa dekade dalam keunggulan pengembangan. Kualitas kode dan kualitas produksi adalah prinsip budaya yang ditanamkan di semua tim engineering 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 ekstensif, memastikan ide desain diterapkan dengan aman dan benar. Proses kualifikasi kami selanjutnya memperluas pengujian untuk mencakup integrasi skala besar dan dependensi eksternal. Terakhir, platform peluncuran kami memungkinkan kami membangun keyakinan secara progresif bahwa perubahan tertentu benar-benar berfungsi seperti yang diharapkan. Mulai dari konsep hingga produksi, pendekatan kami memungkinkan kami memenuhi ekspektasi pelanggan terhadap kecepatan pengembangan dan keandalan.Google Cloud