Miliaran pengguna setiap tahun berinteraksi dengan produk dan layanan Google. Penawaran utama seperti Penelusuran, Gmail, Maps, YouTube, Chrome, dan kini juga Google Cloud, terintegrasi dengan sangat 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 kami dan layanan untuk memastikan bahwa kami memberikan pengalaman pengguna sebaik mungkin, meningkatkan keamanan dan keandalan, serta mematuhi peraturan dan kepatuhan lainnya. Setiap perubahan tersebut, baik besar maupun kecil, terkadang dapat merusak. Untuk mengatasi risiko tersebut, kami memprioritaskan keamanan perubahan di seluruh siklus hidup suatu perubahan.
Dokumen ini menjelaskan cara tim Google Cloud membangun solusi berdasarkan pengalaman puluhan tahun Google investasi dalam keunggulan pengembangan untuk menerapkan praktik terbaik keandalan dan engineering yang memenuhi ekspektasi pelanggan Google Cloud untuk kecepatan dan keandalan pengembangan.
Lamanya perubahan di Google Cloud
Tim produk Google Cloud berbagi banyak proses pengelolaan dan alat dengan tim engineering lainnya di Google. Kami menerapkan standar pendekatan pengembangan perangkat lunak untuk manajemen perubahan yang memprioritaskan prioritas berkelanjutan integration (CI) dan continuous delivery (CD). CI mencakup sering mengajukan, menguji, dan mengirimkan perubahan, sering kali beberapa kali sehari untuk produk atau layanan tertentu. CD adalah perpanjangan dari CI di mana insinyur terus-menerus menyiapkan kandidat rilis berdasarkan snapshot stabil terbaru dari codebase.
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 pertanyaan dalam model manajemen perubahan: 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 kesalahan kecil di awal proses pengembangan pun dapat menyebabkan masalah besar di kemudian hari yang secara signifikan mempengaruhi pengalaman pelanggan. Sebagai seorang hasilnya, kami mengharuskan agar semua perubahan besar dimulai dengan dokumen desain yang disetujui. Kami memiliki {i>template<i} dokumen desain yang umum bagi tim teknik untuk mengusulkan program perubahan. Dokumen desain umum ini membantu kami mengevaluasi perubahan besar di seluruh produk Google Cloud secara konsisten. Diagram berikut menunjukkan proses desain standar untuk sebuah perubahan besar adalah sebagai berikut:
Fase desain dimulai ketika pengembang perangkat lunak 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. 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 tinjauan ini mengurangi kemungkinan bahwa Tim produk Google Cloud bahkan mulai mengerjakan perubahan yang dapat berdampak negatif pada pelanggan dalam proses produksi.
Aman sebagaimana dikembangkan
Proses pengembangan kode kami meningkatkan kualitas dan keandalan kode kami. Setelah persetujuan terhadap perubahan yang diusulkan, proses pengembangan dimulai dengan orientasi yang komprehensif untuk para insinyur baru, termasuk pelatihan, bimbingan, dan umpan balik terperinci 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 produk tersebut memenuhi standar tinggi Google.
Diagram berikut menyediakan alur kerja yang menggambarkan sekitar apa proses pengembangan kita akan terlihat seperti:
Fase pengembangan dimulai ketika seorang insinyur mulai menulis kode dan pengujian unit dan integrasi yang sesuai. Selama fase ini, insinyur dapat menjalankan tes yang mereka tulis dan serangkaian tes pra-pengiriman untuk memastikan bahwa kode tambahan dan perubahan adalah valid. Setelah menyelesaikan perubahan kode dan menjalankan engineer, engineer meminta peninjauan manual dari orang lain yang kode. Proses peninjauan manual ini sering berulang dan dapat mengakibatkan 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 memfasilitasi penggunaan ulang kode, membuat manajemen dependensi lebih mudah, 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 kuat dan lebih mudah dikelola pada saat standar. 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 dibangun di software open source berkualitas tinggi dapat melengkapi monorepo dengan repositori lain — biasanya Git — untuk menggunakan percabangan untuk mengelola perangkat lunak {i>open source<i}.
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, yaitu panduan gaya belajar, praktik terbaik, dan panduan pengembangan, serta melakukan latihan praktis secara manual. Selain itu, insinyur baru memerlukan 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 mendapatkan keterbacaan dalam bahasa pemrograman tersebut. Setiap insinyur dapat memperoleh keterbacaan bahasa pemrograman — sebagian besar tim memiliki beberapa pemberi persetujuan untuk dalam bahasa pemrograman yang mereka buatkan kodenya.
Geser ke kiri meningkatkan kecepatan dengan 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 seorang insinyur yang ditugaskan untuk mengatasi masalah ini adalah orang yang berbeda dengan yang pertama kali memperkenalkan perubahan yang berisi {i>bug<i}, insinyur baru harus terbiasa dengan perubahan kode, kemungkinan menambah waktu yang dibutuhkan untuk mereproduksi dan pada akhirnya dapat memperbaiki {i>bug<i}. Seluruh proses ini membutuhkan banyak waktu mulai dari pelanggan dan dukungan Google Cloud, serta menuntut para engineer untuk yang sedang mereka kerjakan 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 dini ini berarti bahwa engineer dapat memperbaiki bug tanpa dampak pelanggan, dan tidak ada overhead pengalihan konteks.
Skenario terakhir ini sangat cocok untuk semua orang yang terlibat. Hasilnya, dari tahun ke tahun, Google Cloud telah berinvestasi cukup besar dalam peralihan ini memindahkan pengujian yang secara tradisional dilakukan selama kualifikasi perubahan dan fase peluncuran secara langsung ke loop pengembangan. Hari ini, semua pengujian unit, tetapi tes integrasi terbesar, dan analisis statis dan dinamis yang luas diselesaikan secara paralel saat seorang insinyur mengajukan perubahan kode.
Pengujian pra-pengiriman otomatis menerapkan standar coding
Pengujian pra-pengiriman adalah pemeriksaan yang berjalan sebelum perubahan apa pun dikirimkan dalam saat ini. 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.
Paket pengujian pra-pengiriman umumnya mencakup pengujian unit, pengujian fuzz (fuzzing), pengujian integrasi hermetic, serta analisis kode statis dan dinamis. Sebagai perubahan pada perpustakaan inti atau kode yang digunakan secara luas di Google, pengembang 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 tak terpisahkan 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, setiap perjalanan penting pengguna harus memiliki pengujian integrasi di mana kita memvalidasi fungsionalitas semua komponen yang diperlukan dan dependensi.
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.
Proses fuzzing
Sedangkan pengujian unit dan integrasi membantu kita memvalidasi perilaku yang diharapkan dengan input dan {i>output<i} yang telah ditentukan, {i>fuzzing<i} adalah teknik yang membombardir aplikasi dengan input acak, yang bertujuan untuk mengekspos kekurangan atau kelemahan tersembunyi yang dapat menyebabkan kerentanan atau {i>error<i} pada keamanan. 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 memainkan peran penting dalam menjaga kualitas kode dalam alur kerja pengembangan Anda. 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 penambahan pemeriksaan statis baru dari waktu ke waktu, seluruh codebase terus dipindai untuk memeriksa kepatuhan, dan perbaikan secara otomatis telah 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++, Mulai): Menemukan data race dan bug threading lainnya
- MemorySanitizer: Mengungkap penggunaan memori yang tidak diinisialisasi
Alat ini dan alat-alat lain yang seperti itu penting untuk menangkap {i>bug<i} kompleks yang tidak dapat dideteksi hanya melalui analisis statis. Dengan menggunakan model dinamis, Google berusaha memastikan bahwa kodenya terstruktur dengan baik, bebas dari masalah yang diketahui, dan berperilaku seperti yang diharapkan dalam skenario dunia nyata.
Peninjauan kode manual memvalidasi perubahan dan hasil pengujian
Ketika seorang insinyur mencapai tonggak 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 titik ini dalam proses pengembangan, orang lain bekerja. paket Premium AI atau lebih peninjau yang ditunjuk memeriksa daftar perubahan dengan teliti untuk memastikan keakuratannya. dan kejelasan, menggunakan pengujian terlampir 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 memberikan persetujuan mereka ("LGTM," singkat untuk "tampak bagus bagi saya"). Namun, jika insinyur itu masih dalam pelatihan untuk bahasa pemrograman yang digunakan, mereka membutuhkan persetujuan tambahan dari seorang ahli yang telah mendapatkan keterbacaan dalam bahasa pemrograman.
Setelah daftar perubahan lulus pengujian dan pemeriksaan otomatis serta menerima LGTM, insinyur yang mengusulkan perubahan hanya diperbolehkan membuat sedikit perubahan terhadap pada kode sumber. Perubahan substansial apa pun akan membatalkan persetujuan dan mewajibkan perubahan peninjauan. Bahkan perubahan kecil pun akan otomatis ditandai ke versi aslinya {i>reviewer<i} (peninjau). 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 mewaspadai kegagalan yang disebabkan oleh faktor-faktor di luar kendali mereka, seperti perubahan pada ketergantungan 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 {i>changelist<i} yang menyebabkan kerusakan, dan melakukan {i>rollback<i}. 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 dasar dan keamanan hingga logika bisnis. Pengujian kualifikasi ini mencakup pengujian kode untuk hal berikut:
- Kemampuan untuk memberikan fungsionalitas yang diperlukan, yang diuji dengan menggunakan pengujian integrasi berskala besar
- Kemampuan untuk memenuhi persyaratan bisnis, yang telah diuji dengan respons sintetis representasi workload dari pelanggan
- Kemampuan untuk mempertahankan kegagalan infrastruktur dasar, yang diuji menggunakan injeksi kegagalan di seluruh stack
- Kemampuan untuk mempertahankan kapasitas penayangan, yang diuji dengan framework pengujian beban
- Kemampuan untuk melakukan rollback dengan aman
Peluncuran aman
Bahkan dengan proses pengembangan, pengujian, dan kualifikasi terkuat sekalipun, terkadang dapat menyelinap ke lingkungan produksi yang berdampak negatif pada pengguna. 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 pada semua jenis perubahan yang diterapkan ke produksi, termasuk biner, konfigurasi, pembaruan skema, kapasitas perubahan, dan daftar kontrol akses.
Mengubah 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 memberi tahu pelanggan lebih cepat dan mengambil tindakan korektif untuk mencegah secara sistematis kegagalan serupa agar tidak 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 terpisah dari produk zona yang sama yang berjalan di Zona D di 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 berbagai lokasi target menjadi gelombang. Gelombang awal mencakup sejumlah replika yang sedikit, dengan update yang dilakukan secara berurutan. Keseimbangan gelombang awal melindungi sebagian besar workload pelanggan dengan memaksimalkan eksposur terhadap workload mendeteksi masalah sedini mungkin, dan menyertakan workload sintetis yang meniru pola beban kerja pelanggan yang umum.
Jika peluncuran tetap berhasil karena replika layanan diupdate di target lokasi, gelombang peluncuran berikutnya bertambah secara bertahap dan menghasilkan 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 ombak meluas hingga malam hari atau akhir pekan, AI dapat menyelesaikan perkembangannya, tetapi tidak ada gelombang baru yang dapat dimulai sampai awal jam kerja 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 Layanan Analisis Canary (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 dari proses peluncuran memiliki waktu untuk menangkap masalah lambat sebelum berlanjut ke langkah berikutnya untuk memastikan bahwa telah dijalankan dengan baik dan bahwa 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 pada canary dengan replika baca. Alat peluncuran kemudian meminta verdict dari CAS. CAS mengevaluasi replika canary terhadap grup kontrol dan menampilkan verdict PASS atau FAIL. Jika ada sinyal kesehatan yang gagal, peringatan akan dibuat untuk pemilik layanan dan yang sedang berjalan akan dijeda atau di-roll back. Jika perubahan menyebabkan gangguan terhadap pelanggan eksternal, insiden eksternal dilaporkan dan terpengaruh pelanggan akan diberi tahu melalui Service Health yang Dipersonalisasi layanan. Insiden juga memicu peninjauan internal. Filosofi Postmortem Google memastikan serangkaian tindakan korektif yang tepat diidentifikasi dan diterapkan pada meminimalkan kemungkinan terjadinya 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 produksi sistem 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. Karena ini, produksi kami playbook menginstruksikan tim respons insiden untuk menghubungkan peluncuran terbaru dengan masalah yang diamati, dan secara default melakukan roll back peluncuran terbaru jika terjadi tim tanggap darurat tidak dapat mengesampingkan perubahan terbaru sebagai penyebab utama insiden itu.
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 mengamati perilaku sistem dari perspektif pelanggan, melacak tingkat kesalahan layanan, dan terhadap traffic sintetis dari layanan prober. Pemantauan sintetis berorientasi pada gejala dan mengidentifikasi masalah aktif, sedangkan pemantauan memungkinkan kita mendiagnosis masalah yang sudah terkonfirmasi, dan dalam beberapa masalah yang akan segera terjadi.
Untuk membantu mendeteksi insiden yang hanya memengaruhi beberapa pelanggan, kami mengelompokkan beban kerja pelanggan ke dalam beberapa kelompok workload terkait. Notifikasi dipicu sebagai segera setelah kinerja kelompok menyimpang dari kebiasaan. Peringatan ini memungkinkan mendeteksi regresi spesifik per pelanggan meskipun performa gabungan agar normal.
Perlindungan supply chain software
Setiap kali tim Google Cloud melakukan 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 yang di-deploy ke lingkungan production. Untuk memastikan integritas produksi, BAB hanya mengizinkan perubahan yang memenuhi kriteria berikut:
- Tahan gangguan dan ditandatangani
- Berasal dari pihak build yang telah diidentifikasi dan lokasi sumber yang teridentifikasi
- Telah ditinjau dan disetujui secara eksplisit oleh pihak yang berbeda dengan penulis kode
Jika Anda tertarik untuk menerapkan beberapa konsep yang sama pada perangkat lunak 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 pengembangan yang unggul. Kualitas kode dan kualitas produksi adalah prinsip budaya yang ditanamkan di semua tim engineer di Google. Proses tinjauan desain kami memastikan bahwa terhadap kode dan kondisi produksi akan dipertimbangkan sejak awal. Proses pengembangan kami, berdasarkan prinsip shift left dan pengujian yang ekstensif, memastikan bahwa ide desain diterapkan dengan aman dan benar. Dengan proses kualifikasi memperluas pengujian untuk mencakup integrasi skala besar dan dependensi eksternal. Terakhir, platform peluncuran memungkinkan kami untuk secara bertahap membangun keyakinan bahwa perubahan yang diberikan 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.