arrow_back

Memecahkan Masalah Beban Kerja di GKE untuk Site Reliability Engineers

Gabung Login

Memecahkan Masalah Beban Kerja di GKE untuk Site Reliability Engineers

1 jam 30 menit 1 Kredit

GSP902

Lab Mandiri Google Cloud

Catatan: Peluncuran lab ini biasanya memerlukan waktu kurang dari satu menit. Akan tetapi, selama periode permintaan yang tinggi, lab ini dapat memerlukan waktu hingga 20 menit untuk penyediaan resource. Waktu penyediaan tidak akan memotong waktu peluncuran lab.

Ringkasan

Site Reliability Engineers (SRE) memiliki serangkaian tanggung jawab, dan manajemen insiden merupakan bagian yang sangat penting dari peran mereka. Anda akan mempelajari cara memanfaatkan kemampuan terintegrasi Google Cloud Operations Suite, termasuk logging, pemantauan, dan dasbor yang lengkap dan siap pakai.

Proses pemecahan masalah merupakan pendekatan iterasi, yaitu ketika SRE membentuk hipotesis mengenai akar potensi penyebab terjadinya sebuah insiden, kemudian memfilter, menelusuri, dan menelusuri sejumlah besar data telemetri yang dikumpulkan dari sistem untuk memvalidasi atau menolak hipotesis tersebut. Jika hipotesisnya tidak valid, SRE akan membentuk hipotesis lain dan menjalankan iterasi lain sampai mereka dapat mengisolasi akar penyebabnya. Di situs Google, lihat mempelajari lebih lanjut SRE di Google Site Reliability Engineering.

Dalam lab ini, Anda akan mempelajari cara melakukan perjalanan iterasi secara efisien dan efektif menggunakan alat operasi Google Cloud.

Yang akan Anda pelajari

Di lab ini, Anda akan mempelajari cara:

  • Menavigasi halaman resource Google Kubernetes Engine (GKE)

  • Memanfaatkan dasbor GKE untuk menampilkan data operasi dengan cepat

  • Membuat metrik berbasis log untuk menangkap masalah yang spesifik

  • Membuat Tujuan Tingkat Layanan (SLO)

  • Menentukan Pemberitahuan untuk memberi tahu staf SRE terkait insiden

Penyiapan dan persyaratan

Sebelum mengklik tombol Start Lab (Mulai Lab)

Baca petunjuk ini. Lab memiliki timer dan Anda tidak dapat menjedanya. Timer, yang dimulai saat Anda mengklik Start Lab (Mulai Lab), menampilkan lamanya resource Cloud akan tersedia untuk Anda.

Lab praktis Qwiklabs ini memungkinkan Anda melakukan aktivitas lab sendiri di lingkungan cloud nyata, bukan di lingkungan demo atau simulasi. Yaitu dengan cara memberi Anda kredensial sementara yang baru yang digunakan untuk login dan mengakses Google Cloud Platform selama durasi lab.

Yang diperlukan

Untuk menyelesaikan lab ini, Anda memerlukan:

  • Akses ke browser internet standar (disarankan browser Chrome).
  • Waktu untuk menyelesaikan lab.

Catatan: Jika Anda sudah memiliki project atau akun GCP pribadi, jangan gunakan project atau akun tersebut untuk lab ini.

Cara memulai lab dan login ke Google Cloud Console

  1. Klik tombol Start Lab. Jika Anda perlu membayar lab, jendela pop-up akan terbuka untuk memilih metode pembayaran. Di sebelah kiri adalah panel Lab Details dengan berikut ini:

    • Tombol Open Google Console
    • Waktu tersisa
    • Kredensial sementara yang harus Anda gunakan untuk lab ini
    • Informasi lain, jika diperlukan, untuk menyelesaikan lab ini
  2. Klik Open Google Console. Lab akan menjalankan resource, lalu membuka tab lain yang menampilkan halaman Login.

    Tips: Atur tab di jendela terpisah secara berdampingan.

    Catatan: Jika Anda melihat dialog Choose an account, klik Use Another Account.
  3. Jika perlu, salin Username dari panel Lab Details dan tempel ke dialog Sign in. Klik Next.

  4. Salin Password dari panel Lab Details dan tempel ke dialog Welcome. Klik Next.

    Penting: Anda harus menggunakan kredensial dari panel sebelah kiri. Jangan menggunakan kredensial Google Cloud Skills Boost. Catatan: Menggunakan akun Google Cloud sendiri untuk lab ini dapat dikenai biaya tambahan.
  5. Klik halaman berikutnya:

    • Setujui persyaratan dan ketentuan.
    • Jangan tambahkan opsi pemulihan atau autentikasi 2 langkah (karena ini akun sementara).
    • Jangan daftar uji coba gratis.

Setelah beberapa saat, Cloud Console akan terbuka di tab ini.

Catatan: Anda dapat melihat menu dengan daftar Produk dan Layanan Google Cloud dengan mengklik Menu navigasi di kiri atas. Ikon menu navigasi

Mengaktifkan Google Cloud Shell

Google Cloud Shell adalah mesin virtual yang dimuat dengan fitur pengembangan. Mesin virtual ini menawarkan direktori beranda persisten sebesar 5 GB dan berjalan di Google Cloud. Google Cloud Shell menyediakan akses command-line ke resource GCP.

  1. Di GCP console, pada toolbar kanan atas, klik tombol Buka Cloud Shell.

    Ikon Cloud Shell

  2. Klik Continue (Terus):

    cloudshell_continue

Butuh beberapa saat untuk penyediaan dan terhubung ke lingkungan. Ketika Anda terhubung, Anda sudah diautentikasi, dan proyek diatur ke PROJECT_ID Anda. Sebagai contoh:

Terminal Cloud Shell

gcloud adalah fitur command-line untuk Google Cloud Platform. Fitur ini sudah terinstal di Cloud Shell dan mendukung penyelesaian tab.

Anda dapat menampilkan daftar nama akun yang aktif dengan perintah ini:

gcloud auth list

Output:

Credentialed accounts:
- <myaccount>@<mydomain>.com (active)

Contoh output:

Credentialed accounts:
 - google1623327_student@qwiklabs.net

Anda dapat menampilkan daftar ID project dengan perintah ini:

gcloud config list project

Output:

[core]
project = <project_ID>

Contoh output:

[core]
project = qwiklabs-gcp-44776a13dea667a6

Skenario

Organisasi Anda telah men-deploy aplikasi microservice multi-tingkat. Ini merupakan aplikasi e-commerce berbasis web yang bernama "Hipster Shop", di mana pengguna dapat mencari item vintage, menambahkannya ke keranjang, dan membelinya. Hipster Shop tersusun dari banyak microservice, ditulis dalam bahasa yang berbeda-beda, yang dikomunikasikan via gRPC dan REST API. Arsitektur deployment-nya dioptimalkan untuk tujuan pembelajaran dan melibatkan teknologi modern sebagai bagian dari stack: Kubernetes, Istio, Cloud Operations, App Engine, gRPC, OpenTelemetry, dan teknologi berbasis cloud yang serupa.

Sebagai bagian dari tim Site Reliability Engineering (SRE), Anda akan dihubungi ketika pengguna akhir melaporkan masalah dalam melihat produk dan menambahkannya ke dalam keranjang. Anda akan menjelajahi beragam layanan yang di-deploy untuk menentukan akar penyebab masalah dan menyiapkan Tujuan Tingkat Layanan (SLO) untuk mencegah insiden serupa terjadi di masa mendatang. Pelajari hal tersebut lebih lanjut pada artikel blog berikut: SLO, SLI, SLA, oh my—CRE life lessons.

Tugas 1. Menavigasi halaman resource Google Kubernetes Engine (GKE)

Untuk bagian pertama lab ini, Anda akan melihat halaman resource Google Kubernetes Engine (GKE), lalu bernavigasi ke beragam dasbor metrik untuk menginvestigasi masalah yang dilaporkan oleh pengguna akhir dengan detail yang lengkap.

  1. Di Cloud Console, dari Menu navigasi pilih Kubernetes Engine > Clusters.

  2. Konfirmasikan bahwa cluster Kubernetes berikut tersedia: cloud-ops-sandbox. Validasikan bahwa setiap cluster memiliki tanda centang hijau di sampingnya untuk mengindikasikan bahwa cluster aktif dan berjalan dengan baik.

  3. Klik link cloud-ops-sandbox di bawah kolom Name untuk menavigasi ke tab Details cluster.

  4. Klik tab Nodes untuk melihat seluruh node di dalam cluster. Validasikan bahwa ada kumpulan node tunggal.

  5. Di bawah bagian Node Pools dari tab Nodes, klik link node pertama dalam tabel di bawah kolom Name untuk menampilkan detail node selengkapnya. Scroll ke bagian bawah halaman dan klik link untuk Node pertama pada tabel di bagian bawah halaman.

Tab Nodes

  1. Di halaman detail node yang dihasilkan, catat metrik node yang tersedia. Metrik ini dicantumkan di bawah bagian Resource summary dan berisi CPU dan Penggunaan Memori serta hal lainnya. Lab ini menghasilkan beban selama penyediaan dan Anda akan melihat aktivitas metrik tetapi tanpa lonjakan yang jelas atau metrik di atas batas "requested" untuk grafik yang ditampilkan di bagian Summary.

  2. Untuk penyelidikan lebih jauh, ketimbang menavigasi setiap node individu untuk menampilkan metriknya, klik tiga titik di pojok kanan atas dari kotak CPU dan pilih View in Metrics Explorer.

Di halaman Metrics Explorer, Anda akan melihat metrik yang dikaitkan dengan node yang baru dinavigasi. Terdapat tiga filter yang dikonfigurasi di Metrics explorer di bawah bagian Filters.

  1. Hapus filter untuk nodename dengan memperluas filter dan mengklik ikon hapus.

  2. Di bawah bagian How do you want to view that data, setel Group by ke node_name.

Ketika filter disetel, visualisasi akan diperbarui dan Anda dapat melihat metrik yang sama untuk semua node di kumpulan node dari cluster cloud-ops-sandbox.

Diagram garis

Catatan: Anda dapat menemukan dua metrik tambahan yang juga ditampilkan, yaitu inti batas dan inti permintaan. Inti batas adalah batas inti CPU dari container yang berjalan di node, sementara metrik inti permintaan merupakan jumlah inti CPU yang diminta oleh container yang berjalan di node. Anda dapat mengetahui selengkapnya tentang metrik Kubernetes di halaman dokumentasi berikut: metrik Kubernetes.

Tugas 2. Mengakses data operasional melalui Dasbor GKE

Di bagian selanjutnya, Anda akan mempelajari cara memperoleh data operasional mendetail secara cepat dari beragam resource yang di-deploy ke GKE via dasbor GKE.

Harap diingat bahwa pengguna situs telah melaporkan bahwa mereka tidak dapat melihat detail produk atau menambahkan item ke keranjang mereka. Anda dapat memverifikasi ini dengan membuka situs.

  1. Buka Menu navigasi > Kubernetes Engine > Services & Ingress. Klik pada bagian Endpoints (alamat IP) untuk layanan frontend-external.
  2. Klik pada produk mana pun yang ditampilkan di halaman landing untuk mereproduksi error yang dilaporkan.

Setelah mereproduksi error, perhatikan bahwa pelacakan tumpukan menyebutkan bahwa aplikasi "failed to get product recommendations".

Menyelidiki recommendationservice yang di-deploy ke GKE:

  1. Navigasikan ke Cloud Monitoring dari Cloud Console, dari Menu Navigasi pilih Monitoring > Dashboards.
Catatan: Agar tidak terus-menerus men-scroll ke bawah di menu kiri untuk menuju bagian Monitoring selama menjalani lab ini, arahkan kursor ke bagian Monitoring di menu kiri dan pilih ikon pin yang muncul. Langkah ini akan menempatkan bagian Monitoring di sisi atas menu kiri untuk penggunaan berikutnya.
  1. Saat halaman landing Dashboards terbuka, klik GKE.

Anda akan melihat tampilan dasbor yang menyediakan metrik terkait Cluster, Namespace, Workload, Service, Pod dan Container yang relevan untuk resource GKE yang ditemukan dalam project di tampilan agregat.

Untuk skenario lab ini, Anda ingin menampilkan log dan metrik yang terkait dengan recommendationservice karena pengguna akhir mendapatkan error yang terkait dengan rekomendasi produk saat menampilkan halaman landing produk. Anda akan membuat filter untuk cluster cloud-ops-sandbox guna menginvestigasi gejala yang mungkin terjadi dan mendiagnosis masalah lebih jauh.

Pada langkah selanjutnya, Anda akan menambahkan filter ke GKE Dashboard.

  1. Klik tombol Add Filter di sisi atas halaman GKE Dashboard.

  2. Dari filter yang tersedia, pilih Workloads > recommendationservice.

Opsi filter recommendationservice

  1. Klik tombol Apply setelah memilih filter yang tepat. Bagian Filter di halaman GKE Dashboard akan tampak serupa dengan gambar berikut.

Bagian Filter di halaman GKE Dashboard

Tampilan ini memungkinkan Anda untuk memfokuskan perhatian Anda pada microservice recommendationservice yang bermasalah.

  1. Di bawah bagian Workloads, klik recommendationservice untuk membuka panel Deployment details. Tampilan ini berisi detail Alerts, SLOs, Events, Metrics, dan Logs. Pada tahap lab ini, tidak ada SLO yang tersedia. Anda akan menambahkan SLO di bagian selanjutnya dari lab ini.

  2. Klik tab Metrics untuk menampilkan metrik yang terkait dengan recommendationservice. Anda dapat mengubah pilihan drop-down Metrics untuk mengubah data visualisasi yang diberikan dan menampilkan beragam metrik yang tersedia untuk layanan ini.

bagian recommendationservice

  1. Klik tab Log untuk menampilkan log yang terkait dengan recommendationservice. Anda dapat memfilter log yang tersedia menggunakan drop-down Severity yang sesuai dengan tingkat log dari entri yang tersedia. Langkah ini bermanfaat dalam konteks SRE untuk menemukan error yang tercatat dalam log dan memanfaatkan entri untuk memecahkan masalah.

  2. Setel Severity ke Error untuk memfilter log recommendationservice.

Bagian log

  1. Pada tahap ini, error yang terkait dengan kode yang bermasalah akan tampak jelas. Cari frasa invalid literal for int() with base 10: '5.0' pada item di rangkaian hasil. Error ini muncul dalam filter recommendationservice, mengonfirmasikan bahwa layanan mengandung bug dalam kode.

Anda akan men-deploy ulang microservice recommendationservice untuk memastikan bahwa error tidak ada lagi.

Catatan: Agar mudah, Anda akan menyimulasi deployment versi aplikasi terbaru menggunakan kubectl.
  1. Jalankan perintah berikut di Cloud Shell:
git clone --depth 1 --branch cloudskillsboost_asm https://github.com/GoogleCloudPlatform/cloud-ops-sandbox.git
  1. Kemudian, jalankan:
cd cloud-ops-sandbox/sre-recipes
  1. Navigasikan ke Menu Navigasi > Kubernetes Engine > Clusters. Pilih titik tiga di sisi kanan cluster cloud-ops-sandbox dan pilih opsi Connect.

  2. Di dialog modal Connect to the cluster, klik tombol RUN IN CLOUD SHELL. Tekan Enter untuk menjalankan perintah setelah terisi di Cloud Shell.

  3. Terakhir, jalankan perintah restore untuk memperbarui layanan:

./sandboxctl sre-recipes restore "recipe3"
  1. Untuk memverifikasi bahwa aplikasi berjalan dengan benar, navigasikan ke Menu Navigasi > Kubernetes Engine > Services & Ingress.

  2. Klik Endpoint untuk layanan frontend-external.

Langkah ini akan mengalihkan Anda ke situs Hipster Shop yang digunakan untuk latihan lab ini. Klik produk mana pun untuk memverifikasi bahwa produk dimuat tanpa memunculkan error.

Situs Hipster Shop.

Di bagian lab ini, Anda menjelajahi log dan metrik yang tersedia di dasbor GKE untuk mendiagnosis masalah pada beban kerja aplikasi yang di-deploy oleh tim DevOps. Anda telah dapat menemukan penyebab masalah secara tepat dan memperbaikinya dengan men-deploy ulang microservice yang bermasalah dengan perbaikan bug.

Tugas 3. Pemantauan proaktif dengan metrik berbasis log

Untuk memastikan kode recommendationservice yang diperbarui bekerja sebagaimana yang diharapkan, dan agar mencegah insiden mendatang agar tidak terjadi lagi, Anda perlu memutuskan untuk membuat metrik berbasis log untuk memantau log dan memberi tahu SRE ketika insiden serupa terjadi di masa mendatang.

Di bagian ini, Anda akan membuat metrik berbasis log yang spesifik pada error yang ditemukan dalam bagian sebelumnya.

Menggunakan metrik berbasis log, Anda dapat menentukan metrik yang dapat menelusuri error pada log untuk merespons masalah dan gejala serupa secara proaktif sebelum ditemukan oleh pengguna akhir.

  1. Dari Cloud Console, klik Menu Navigasi > Logging > Logs Explorer.
Catatan: Agar tidak terus-menerus men-scroll ke bawah di Menu navigasi untuk menuju bagian Logging selama menjalani lab ini, arahkan kursor ke bagian Logging dan pilih ikon pin yang muncul. Langkah ini akan menempatkan bagian Logging di sisi atas Menu navigasi untuk penggunaan berikutnya.
  1. Di bagian Query results, klik +Create metric. Langkah ini akan membuka tab baru untuk membuat metrik berbasis log.

  2. Masukkan opsi berikut di halaman Create logs metric:

  • Metric Type: Counter
  • Log metric name: Error_Rate_SLI
  • Filter Selection: (Salin dan tempel filter di bawah ini)
resource.labels.cluster_name="cloud-ops-sandbox" AND resource.labels.namespace_name="default" AND resource.type="k8s_container" AND labels.k8s-pod/app="recommendationservice" AND severity>=ERROR Catatan: Di bagian selanjutnya, Anda akan memanfaatkan beragam metrik yang berpusat pada Ketersediaan untuk memberi tahu tim SRE secara proaktif mengenai masalah terkait. Akan tetapi, harap diingat bahwa metrik kustom berbasis log yang ditentukan dalam bagian ini juga dapat dimanfaatkan untuk menghasilkan pemberitahuan ketika kondisi filter terpenuhi.
  1. Klik Create Metric.

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat metrik log

Tugas 4. Membuat SLO

Setelah membuat metrik berbasis log yang secara dekat menggambarkan pengalaman pengguna, tim SRE akan menggunakannya untuk mengukur kepuasan pengguna, metrik ini adalah SLI kami dan akan digunakan untuk menentukan Tujuan Tingkat Layanan (SLO) pada recommendationservice. Anda menggunakan SLO untuk menentukan tujuan tingkat layanan untuk metrik performa. SLO merupakan tujuan terukur untuk performa selama beberapa waktu. Di Google Cloud, situs Anthos, lihat Mendesain dan menggunakan SLO untuk panduan lebih lanjut tentang desain SLO dan filter yang akan Anda gunakan di bawah.

Cloud Operations Suite menyediakan pemantauan berorientasi layanan, yang berarti Anda mengonfigurasi SLI, SLO, dan Pemberitahuan Laju Pengeluaran untuk suatu layanan.

  1. Navigasikan ke Menu navigasi > Monitoring > Services. Halaman hasil akan menampilkan daftar layanan yang di-deploy ke GKE untuk beban kerja aplikasi.

  2. Pilih layanan recommendationservice dari daftar layanan yang tersedia yang akan mengalihkan Anda ke halaman Service details.

  3. Klik + Create SLO di sisi kanan atas halaman.

  4. Pada Langkah 1 Anda akan disajikan dialog untuk membuat SLI baru. Tetapkan parameter berikut:

  • Pilih metrik: Other

  • Berbasis permintaan atau berbasis jendela: Request Based

  1. Klik Continue.

  2. Pada Langkah 2 Define SLI details, Performance Metric harus disetel ke nilai berikut:custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency. Penetapan akan menunjukkan latensi bolak-balik dari permintaan yang dibuat oleh klien ke layanan rekomendasi.

Setel Performance metric ke Less than -∞ to 100 ms.

Membuat halaman Tujuan Tingkat Layanan (SLO)

  1. Klik Continue.

  2. Setelah mengonfigurasi SLI, pada Langkah 3 Set your service-level objective (SLO), Anda akan menentukan SLO yang menyertakan sasaran Performa (target keandalan) dan periode Kepatuhan (periode pengukuran). Untuk mempelajari lebih lanjut, di Site Reliability Workbook Google, lihat Memilih periode waktu yang tepat. Buat pilihan berikut:

  • Period type: Calendar

  • Period length: Calendar month

  • Performance Goal: 99%

  1. Klik Continue.

  2. Klik Create SLO di langkah terakhir wizard untuk menyelesaikan proses pembuatan SLO.

Langkah ini akan mengembalikan Anda ke halaman landing Monitoring > Services. Anda akan mendapati pelanggaran SLO di bawah bagian Current status of the SLO.

  1. Klik pada entri yang tercantum dan pilih tab Error budget setelah diperluas.

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat Tujuan Tingkat Layanan (SLO)

Bagian Error budget merepresentasikan persentase sebenarnya dari anggaran error yang tersisa untuk periode kepatuhan Pada SLO yang telah ditetapkan, terdapat periode satu bulan kalender dan sasaran performa sebesar 99% atau lebih baik.

Sebagaimana ditunjukkan oleh persentase, error yang menyebabkan halaman produk tidak dimuat dengan benar dalam skenario fiktif sangat menurunkan kualitas tujuan tingkat layanan yang ditentukan. Ini mungkin bukan merupakan kasus skenario dunia nyata, karena lab ini menjalankan uji beban terhadap cluster Kubernetes yang menghosting beban kerja aplikasi.

Tugas 5. Menentukan pemberitahuan di SLO

Untuk memberi tahu tim SRE mengenai pelanggaran rangkaian SLO secara proaktif, sebaiknya tentukan pemberitahuan yang akan terpicu ketika SLO dilanggar. Pemberitahuan ini dapat memunculkan saluran notifikasi pilihan Anda, termasuk: Email, SMS, PagerDuty, Slack, WebHook, atau langganan topik PubSub.

  1. Navigasikan ke Menu navigasi > Monitoring > Services.

  2. Klik layanan recommendationservice dari daftar layanan yang tersedia.

  3. Di bawah bagian Current status of 1 SLO, Anda akan menemukan SLO yang dibuat pada tugas terakhir. Anda mungkin harus memperluas jendela browser yang mencantumkan SLO untuk melihat opsi lain.

  4. Klik tombol CREATE SLO ALERT yang tersaji di SLO. Langkah ini akan memungkinkan Anda untuk menentukan kebijakan Pemberitahuan ketika SLO dilanggar.

Pada input modal Create SLO burn rate alert policy, Anda akan menemukan kolom Burn rate threshold dan Burn rate threshold di Langkah 1 dari wizard. Durasi lookback memungkinkan Anda untuk menentukan durasi waktu dari waktu saat ini agar Kebijakan Pemberitahuan melihat balik untuk menemukan pelanggaran laju pengeluaran yang mungkin terjadi. Nilai minimum laju pengeluaran memungkinkan Anda untuk menspesifikkan irisan waktu jendela guna membagi durasi lihat balik untuk menguji apakah SLO telah dilanggar.

  1. Biarkan nilai default tersebut:
  • Lookback duration: 60 minutes

  • Burn rate threshold: 10

  1. Klik Next.

  2. Pada Langkah 2, Anda dapat menentukan saluran notifikasi untuk mendapatkan pemberitahuan ketika pelanggaran ditemukan. Untuk tujuan lab ini, Anda dapat memasok alamat email atau saluran SMS secara opsional untuk mendapatkan notifikasi.

Langkah 2. Bagian Who should be notified (opsional)

  1. Klik Next.

Langkah 3 bersifat opsional dan memungkinkan Anda untuk memasok informasi apa pun kepada pengguna akhir yang mendapatkan notifikasi, sehingga mereka mendapatkan konteks langsung mengenai masalah yang terjadi dan cara untuk menyelesaikannya.

  1. Klik Save.

Klik Periksa kemajuan saya untuk memverifikasi sasaran. Buat Pemberitahuan pada Service Level Objective (SLO)

(Opsional) Menghapus kebijakan pemberitahuan

Jika Anda menyiapkan pemberitahuan email sebagai bagian dari kebijakan pemberitahuan, ada kemungkinan Anda akan menerima beberapa email tentang resource meskipun lab sudah selesai.

Untuk menghindarinya, hapus kebijakan pemberitahuan sebelum menyelesaikan lab Anda.

Selamat!

Di lab ini, Anda menjelajahi Cloud Operations Suite, yang memungkinkan Site Reliability Engineers (SRE) untuk menginvestigasi dan mendiagnosis masalah yang dialami dengan beban kerja yang dideploy. Agar meningkatkan keandalan beban kerja, Anda menjelajahi cara menavigasi halaman resource atau GKE, menampilkan data operasional dari dasbor GKE, membuat metrik berbasis log untuk menangkap masalah yang spesifik, dan merespons insiden secara proaktif dengan menetapkan service level objective dan pemberitahuan untuk memberitahu tim SRE mengenai masalah yang dialami sebelum menyebabkan gangguan.

Selesaikan quest

Lab mandiri ini merupakan bagian dari quest Google Cloud's Operations Suite on GKE, Cloud Architecture, DevOps Essentials dan quest badge keahlian Measure Site Reliability menggunakan Cloud Operations Suite. Quest adalah serangkaian lab terkait yang membentuk jalur pembelajaran. Daftar ke quest dan langsung dapatkan kredit penyelesaian jika Anda telah mengikuti lab ini. Lihat quest lain yang tersedia.

Mengikuti lab berikutnya

Coba Pemantauan dan Logging untuk Cloud Functions

Langkah berikutnya

Pelatihan & Sertifikasi Google Cloud

...membantu Anda mengoptimalkan teknologi Google Cloud. Kelas kami mencakup keterampilan teknis dan praktik terbaik untuk membantu Anda memahami dengan cepat dan melanjutkan proses pembelajaran. Kami menawarkan pelatihan tingkat dasar hingga lanjutan dengan opsi on demand, live, dan virtual untuk menyesuaikan dengan jadwal Anda yang sibuk. Sertifikasi membantu Anda memvalidasi dan membuktikan keterampilan serta keahlian Anda dalam teknologi Google Cloud.

Manual Terakhir Diperbarui pada 13 Juli 2022

Lab Terakhir Diuji pada 13 Juli 2022

Hak cipta 2020 Google LLC Semua hak dilindungi undang-undang. Google dan logo Google adalah merek dagang dari Google LLC. Semua nama perusahaan dan produk lain mungkin adalah merek dagang masing-masing perusahaan yang bersangkutan.