Praktik terbaik operasi

Last reviewed 2023-12-20 UTC

Bagian ini memperkenalkan operasi yang harus dipertimbangkan saat men-deploy dan mengoperasikan beban kerja tambahan ke lingkungan Google Cloud Anda. Bagian ini tidak dimaksudkan untuk mencakup semua operasi di lingkungan cloud Anda, tetapi memperkenalkan keputusan terkait rekomendasi dan resource arsitektur yang di-deploy oleh blueprint.

Memperbarui resource fondasi

Meskipun cetak biru ini memberikan titik awal yang tidak pasti untuk lingkungan dasar Anda, persyaratan dasar Anda mungkin terus berkembang seiring waktu. Setelah deployment awal, Anda dapat menyesuaikan setelan konfigurasi atau mem-build layanan bersama baru untuk digunakan oleh semua workload.

Untuk memodifikasi resource fondasi, sebaiknya Anda melakukan semua perubahan melalui pipeline dasar. Tinjau strategi cabang untuk pengantar alur penulisan kode, menggabungkannya, dan memicu pipeline deployment.

Menentukan atribut untuk project beban kerja baru

Saat membuat project baru melalui modul project factory dari pipeline otomatisasi, Anda harus mengonfigurasi berbagai atribut. Proses Anda dalam mendesain dan membuat project untuk beban kerja baru harus mencakup keputusan berikut:

  • Google Cloud API mana yang akan diaktifkan
  • VPC Bersama mana yang akan digunakan, atau apakah akan membuat jaringan VPC baru
  • Peran IAM yang akan dibuat untuk project-service-account awal yang dibuat oleh pipeline
  • Label project mana yang akan diterapkan
  • Folder tempat project di-deploy
  • Akun penagihan mana yang akan digunakan
  • Apakah project akan ditambahkan ke perimeter Kontrol Layanan VPC
  • Apakah akan mengonfigurasi nilai minimum pemberitahuan penagihan dan anggaran untuk project

Untuk referensi lengkap tentang atribut yang dapat dikonfigurasi untuk setiap project, lihat variabel input untuk factory project di pipeline otomatisasi.

Mengelola izin dalam skala besar

Saat men-deploy project beban kerja di atas fondasi Anda, Anda harus mempertimbangkan bagaimana Anda akan memberikan akses kepada developer dan konsumen project yang dituju. Sebaiknya tambahkan pengguna ke grup yang dikelola oleh penyedia identitas Anda yang sudah ada, sinkronkan grup dengan Cloud Identity, lalu terapkan peran IAM ke grup. Selalu perhatikan prinsip hak istimewa terendah.

Sebaiknya gunakan juga pemberi rekomendasi IAM untuk mengidentifikasi kebijakan izinkan yang memberikan peran dengan hak istimewa berlebih. Desain proses untuk meninjau rekomendasi secara berkala atau menerapkan rekomendasi secara otomatis ke dalam pipeline deployment Anda.

Mengoordinasikan perubahan antara tim jaringan dan tim aplikasi

Topologi jaringan yang di-deploy oleh blueprint mengasumsikan bahwa Anda memiliki tim yang bertanggung jawab untuk mengelola resource jaringan, dan tim terpisah yang bertanggung jawab untuk men-deploy resource infrastruktur beban kerja. Saat tim beban kerja men-deploy infrastruktur, mereka harus membuat aturan firewall untuk mengizinkan jalur akses yang diinginkan antar-komponen beban kerja, tetapi mereka tidak memiliki izin untuk mengubah kebijakan firewall jaringan itu sendiri.

Rencanakan bagaimana tim akan bekerja sama untuk mengoordinasikan perubahan pada resource jaringan terpusat yang diperlukan untuk men-deploy aplikasi. Misalnya, Anda dapat mendesain proses saat tim beban kerja meminta tag untuk aplikasi mereka. Tim jaringan kemudian membuat tag dan menambahkan aturan ke kebijakan firewall jaringan yang memungkinkan traffic mengalir di antara resource dengan tag, dan mendelegasikan peran IAM untuk menggunakan tag kepada tim beban kerja.

Mengoptimalkan lingkungan Anda dengan portofolio Active Assist

Selain pemberi rekomendasi IAM, Google Cloud menyediakan portofolio layanan Active Assist untuk membuat rekomendasi tentang cara mengoptimalkan lingkungan Anda. Misalnya, insight firewall atau pemberi rekomendasi project tanpa pengawasan memberikan rekomendasi yang dapat ditindaklanjuti yang dapat membantu memperketat postur keamanan Anda.

Desain proses untuk meninjau rekomendasi secara berkala atau menerapkan rekomendasi secara otomatis ke dalam pipeline deployment Anda. Tentukan rekomendasi mana yang harus dikelola oleh tim pusat dan rekomendasi mana yang menjadi tanggung jawab pemilik beban kerja, serta menerapkan peran IAM agar dapat mengakses rekomendasi yang sesuai.

Memberikan pengecualian untuk kebijakan organisasi

Blueprint ini menerapkan serangkaian batasan kebijakan organisasi yang direkomendasikan untuk sebagian besar pelanggan dalam sebagian besar skenario, tetapi Anda mungkin memiliki kasus penggunaan sah yang memerlukan pengecualian terbatas pada kebijakan organisasi yang Anda terapkan secara luas.

Misalnya, blueprint akan menerapkan batasan iam.disableServiceAccountKeyCreation. Batasan ini merupakan kontrol keamanan yang penting karena kunci akun layanan yang bocor dapat menimbulkan dampak negatif yang signifikan. Sebagian besar skenario harus menggunakan alternatif yang lebih aman untuk kunci akun layanan untuk melakukan autentikasi. Namun, mungkin ada kasus penggunaan yang hanya dapat melakukan autentikasi dengan kunci akun layanan, seperti server lokal yang memerlukan akses ke layanan Google Cloud dan tidak dapat menggunakan gabungan workload identity. Dalam skenario ini, Anda mungkin memutuskan untuk mengizinkan pengecualian kebijakan, selama kontrol kompensasi tambahan seperti praktik terbaik untuk mengelola kunci akun layanan diterapkan.

Oleh karena itu, Anda harus merancang proses bagi beban kerja untuk meminta pengecualian terhadap kebijakan, dan memastikan bahwa pembuat keputusan yang bertanggung jawab untuk memberikan pengecualian memiliki pengetahuan teknis untuk memvalidasi kasus penggunaan dan berkonsultasi tentang apakah kontrol tambahan harus diterapkan untuk memberi kompensasi. Saat Anda memberikan pengecualian untuk beban kerja, ubah batasan kebijakan organisasi sesempit mungkin. Anda juga dapat menambahkan batasan secara bersyarat ke kebijakan organisasi dengan menentukan tag yang memberikan pengecualian atau penerapan untuk kebijakan, lalu menerapkan tag ke project dan folder.

Melindungi resource Anda dengan Kontrol Layanan VPC

Blueprint membantu menyiapkan lingkungan Anda untuk Kontrol Layanan VPC dengan memisahkan jaringan dasar dan jaringan terbatas. Namun, secara default, kode Terraform tidak mengaktifkan Kontrol Layanan VPC karena pengaktifan ini dapat menjadi proses yang mengganggu.

Perimeter menolak akses ke layanan Google Cloud yang dibatasi dari traffic yang berasal dari luar perimeter, yang mencakup konsol, workstation developer, dan pipeline dasar yang digunakan untuk men-deploy resource. Jika menggunakan Kontrol Layanan VPC, Anda harus mendesain pengecualian untuk perimeter yang mengizinkan jalur akses yang Anda inginkan.

Perimeter Kontrol Layanan VPC ditujukan untuk kontrol pemindahan yang tidak sah antara organisasi Google Cloud Anda dan sumber eksternal. Perimeter tidak dimaksudkan untuk mengganti atau menduplikasi kebijakan yang memungkinkan kontrol akses terperinci ke setiap project atau resource. Saat Anda mendesain dan merancang perimeter, sebaiknya gunakan perimeter terpadu umum untuk overhead pengelolaan yang lebih rendah.

Jika Anda harus mendesain beberapa perimeter untuk mengontrol traffic layanan secara terperinci dalam organisasi Google Cloud, sebaiknya tentukan dengan jelas ancaman yang ditangani oleh struktur perimeter yang lebih kompleks dan jalur akses di antara perimeter yang diperlukan untuk operasi yang dimaksudkan.

Untuk mengadopsi Kontrol Layanan VPC, evaluasi hal berikut:

Setelah perimeter diaktifkan, sebaiknya desain proses untuk menambahkan project baru secara konsisten ke perimeter yang benar, dan proses untuk mendesain pengecualian saat developer memiliki kasus penggunaan baru yang ditolak oleh konfigurasi perimeter Anda saat ini.

Menguji perubahan seluruh organisasi di organisasi terpisah

Sebaiknya jangan pernah men-deploy perubahan pada produksi tanpa pengujian. Untuk resource beban kerja, pendekatan ini difasilitasi oleh lingkungan terpisah untuk pengembangan, non-produksi, dan produksi. Namun, beberapa resource di organisasi tidak memiliki lingkungan terpisah untuk memfasilitasi pengujian.

Untuk perubahan pada tingkat organisasi, atau perubahan lain yang dapat memengaruhi lingkungan produksi, seperti konfigurasi antara penyedia identitas Anda dan Cloud Identity, sebaiknya buat organisasi terpisah untuk tujuan pengujian.

Mengontrol akses jarak jauh ke virtual machine

Karena sebaiknya Anda men-deploy infrastruktur yang tidak dapat diubah melalui pipeline foundation, pipeline infrastruktur, dan pipeline aplikasi, sebaiknya Anda hanya memberi developer akses langsung ke virtual machine melalui SSH atau RDP untuk kasus penggunaan terbatas atau luar biasa.

Untuk skenario yang memerlukan akses jarak jauh, sebaiknya kelola akses pengguna menggunakan Login OS jika memungkinkan. Pendekatan ini menggunakan layanan Google Cloud terkelola untuk menerapkan kontrol akses, pengelolaan siklus proses akun, verifikasi dua langkah, dan logging audit. Atau, jika Anda harus mengizinkan akses melalui kunci SSH dalam metadata atau kredensial RDP, Anda bertanggung jawab untuk mengelola siklus proses kredensial dan menyimpan kredensial dengan aman di luar Google Cloud.

Dalam skenario apa pun, pengguna yang memiliki akses SSH atau RDP ke VM dapat berisiko eskalasi hak istimewa, jadi Anda harus mendesain model akses dengan mempertimbangkan hal ini. Pengguna dapat menjalankan kode pada VM tersebut dengan hak istimewa akun layanan terkait atau membuat kueri server metadata untuk melihat token akses yang digunakan untuk mengautentikasi permintaan API. Akses ini kemudian dapat menjadi eskalasi hak istimewa jika Anda tidak sengaja meminta pengguna untuk beroperasi dengan hak istimewa akun layanan.

Mengurangi pengeluaran berlebihan dengan merencanakan pemberitahuan anggaran

Blueprint ini menerapkan praktik terbaik yang diperkenalkan dalam Framework Arsitektur Google Cloud: Pengoptimalan Biaya untuk mengelola biaya, termasuk hal berikut:

  • Menggunakan satu akun penagihan untuk semua project di fondasi perusahaan.

  • Tetapkan label metadata billingcode pada setiap project yang digunakan untuk mengalokasikan biaya antar-pusat biaya.

  • Tetapkan anggaran dan nilai minimum pemberitahuan.

Anda bertanggung jawab untuk merencanakan anggaran dan mengonfigurasi pemberitahuan penagihan. Cetak biru ini membuat pemberitahuan anggaran untuk project workload saat perkiraan pengeluaran berjalan sesuai rencana untuk mencapai 120% anggaran. Pendekatan ini memungkinkan tim pusat mengidentifikasi dan mengurangi insiden pengeluaran berlebihan yang signifikan. Peningkatan tak terduga yang signifikan pada pengeluaran tanpa alasan yang jelas dapat menjadi indikator insiden keamanan dan harus diselidiki dari perspektif kontrol biaya dan keamanan.

Bergantung pada kasus penggunaan, Anda dapat menetapkan anggaran berdasarkan biaya seluruh folder lingkungan, atau semua project yang terkait dengan pusat biaya tertentu, bukan menetapkan anggaran terperinci untuk setiap project. Sebaiknya Anda juga mendelegasikan anggaran dan setelan pemberitahuan kepada pemilik workload yang mungkin menetapkan nilai minimum pemberitahuan yang lebih terperinci untuk pemantauan harian mereka.

Untuk panduan membangun kemampuan FinOps, termasuk memperkirakan anggaran untuk beban kerja, lihat Mulai menggunakan FinOps di Google Cloud.

Mengalokasikan biaya di antara pusat biaya internal

Konsol memungkinkan Anda melihat laporan penagihan untuk melihat dan memperkirakan biaya dalam beberapa dimensi. Selain laporan bawaan, sebaiknya Anda mengekspor data penagihan ke set data BigQuery dalam project prj-c-billing-logs. Data penagihan yang diekspor memungkinkan Anda mengalokasikan biaya pada dimensi kustom, seperti pusat biaya internal, berdasarkan metadata label project seperti billingcode.

Kueri SQL berikut adalah contoh kueri untuk memahami biaya semua project yang dikelompokkan menurut label project billingcode.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Untuk menyiapkan ekspor ini, lihat mengekspor data Penagihan Cloud ke BigQuery.

Jika memerlukan akuntansi internal atau penagihan balik antara pusat biaya, Anda bertanggung jawab untuk memasukkan data yang diperoleh dari kueri ini ke dalam proses internal Anda.

Menyerap temuan dari kontrol detektif ke dalam SIEM yang ada

Meskipun resource dasar membantu Anda mengonfigurasi tujuan gabungan untuk log audit dan temuan keamanan, Anda bertanggung jawab untuk memutuskan cara menggunakan dan menggunakan sinyal ini.

Jika Anda memiliki persyaratan untuk menggabungkan log di semua lingkungan cloud dan lokal ke dalam SIEM yang ada, tentukan cara menyerap log dari project prj-c-logging dan temuan dari Security Command Center ke dalam alat dan proses yang sudah ada. Anda dapat membuat satu ekspor untuk semua log dan temuan jika satu tim bertanggung jawab untuk memantau keamanan di seluruh lingkungan, atau Anda dapat membuat beberapa ekspor yang difilter ke kumpulan log dan temuan yang diperlukan untuk beberapa tim dengan tanggung jawab yang berbeda.

Atau, jika volume dan biaya log terlalu tinggi, Anda dapat menghindari duplikasi dengan menyimpan log dan temuan Google Cloud hanya di Google Cloud. Dalam skenario ini, pastikan tim Anda yang ada memiliki akses dan pelatihan yang tepat agar dapat bekerja dengan log dan temuan langsung di Google Cloud.

  • Untuk log audit, desain tampilan log untuk memberikan akses ke subset log dalam bucket log terpusat kepada tim individual, bukan menduplikasi log ke beberapa bucket yang akan meningkatkan biaya penyimpanan log.
  • Untuk temuan keamanan, berikan peran tingkat folder dan tingkat project ke Security Command Center agar tim dapat melihat dan mengelola temuan keamanan hanya untuk project yang menjadi tanggung jawab mereka, langsung di konsol.

Mengembangkan library kontrol secara berkelanjutan

Blueprint dimulai dengan dasar kontrol untuk mendeteksi dan mencegah ancaman. Sebaiknya tinjau kontrol ini dan tambahkan kontrol lain berdasarkan persyaratan Anda. Tabel berikut merangkum mekanisme untuk menerapkan kebijakan tata kelola dan cara memperluasnya untuk persyaratan tambahan Anda:

Kontrol kebijakan yang diterapkan oleh blueprint Panduan untuk memperluas kontrol ini

Security Command Center mendeteksi kerentanan dan ancaman dari berbagai sumber keamanan.

Menentukan modul kustom untuk Security Health Analytics dan modul kustom untuk Event Threat Detection.

Layanan Kebijakan Organisasi menerapkan serangkaian batasan kebijakan organisasi yang direkomendasikan di layanan Google Cloud.

Terapkan batasan tambahan dari daftar batasan yang tersedia yang sudah dibuat sebelumnya atau buat batasan kustom.

Kebijakan Open Policy Agent (OPA) memvalidasi kode dalam pipeline dasar untuk konfigurasi yang dapat diterima sebelum deployment.

Buat batasan tambahan berdasarkan panduan di GoogleCloudPlatform/policy-library.

Pemberitahuan tentang metrik berbasis log dan metrik performa mengonfigurasi metrik berbasis log untuk memberi tahu tentang perubahan pada kebijakan dan konfigurasi IAM pada beberapa resource sensitif.

Desain metrik berbasis log tambahan dan kebijakan pemberitahuan untuk peristiwa log yang seharusnya tidak terjadi di lingkungan Anda.

Solusi kustom untuk analisis log otomatis secara rutin mengkueri log untuk menemukan aktivitas yang mencurigakan dan membuat temuan Security Command Center.

Tulis kueri tambahan untuk membuat temuan peristiwa keamanan yang ingin Anda pantau, menggunakan analisis log keamanan sebagai referensi.

Solusi kustom untuk merespons perubahan aset membuat temuan Security Command Center dan dapat mengotomatiskan tindakan perbaikan.

Membuat feed Inventaris Aset Cloud tambahan untuk memantau perubahan jenis aset tertentu dan menulis Cloud Functions tambahan dengan logika kustom untuk merespons pelanggaran kebijakan.

Kontrol ini dapat berkembang seiring dengan perubahan persyaratan dan kematangan Anda di Google Cloud.

Mengelola kunci enkripsi dengan Cloud Key Management Service

Google Cloud menyediakan enkripsi default dalam penyimpanan untuk semua konten pelanggan, tetapi juga menyediakan Cloud Key Management Service (Cloud KMS) untuk memberi Anda kontrol tambahan atas kunci enkripsi untuk data dalam penyimpanan. Sebaiknya Anda mengevaluasi apakah enkripsi default sudah memadai, atau apakah Anda memiliki persyaratan kepatuhan bahwa Anda harus menggunakan Cloud KMS untuk mengelola kunci sendiri. Untuk informasi selengkapnya, lihat memutuskan cara memenuhi persyaratan kepatuhan untuk enkripsi dalam penyimpanan.

Blueprint menyediakan project prj-c-kms di folder umum dan project prj-{env}-kms di setiap folder lingkungan untuk mengelola kunci enkripsi secara terpusat. Pendekatan ini memungkinkan tim pusat mengaudit dan mengelola kunci enkripsi yang digunakan oleh resource dalam project workload, untuk memenuhi persyaratan peraturan dan kepatuhan.

Bergantung pada model operasional Anda, Anda dapat memilih untuk mengelola satu instance project terpusat Cloud KMS di bawah kontrol satu tim. Anda juga dapat mengelola kunci enkripsi secara terpisah di setiap lingkungan, atau Anda dapat memilih beberapa instance terdistribusi sehingga akuntabilitas untuk kunci enkripsi dapat didelegasikan kepada tim yang sesuai. Ubah contoh kode Terraform sesuai kebutuhan agar sesuai dengan model operasional Anda.

Secara opsional, Anda dapat menerapkan kebijakan organisasi kunci enkripsi yang dikelola pelanggan (Customer-Managed Encryption Key/CMEK) untuk memberlakukan bahwa jenis resource tertentu selalu memerlukan kunci CMEK, dan hanya kunci CMEK dari daftar project tepercaya yang diizinkan yang dapat digunakan.

Simpan dan audit kredensial aplikasi dengan Secret Manager

Sebaiknya jangan pernah menyimpan secret sensitif (seperti kunci API, sandi, dan sertifikat pribadi) ke repositori kode sumber. Sebagai gantinya, commit rahasia ke Secret Manager dan berikan peran IAM Secret Manager Secret Accessor kepada pengguna atau akun layanan yang perlu mengakses secret tersebut. Sebaiknya Anda memberikan peran IAM ke rahasia perorangan, bukan ke semua secret dalam project.

Jika memungkinkan, Anda harus membuat secret production secara otomatis dalam pipeline CI/CD dan membuatnya tidak dapat diakses oleh pengguna manusia, kecuali dalam situasi darurat. Dalam skenario ini, pastikan Anda tidak memberikan peran IAM untuk melihat rahasia ini kepada pengguna atau grup mana pun.

Blueprint menyediakan satu project prj-c-secrets di folder umum dan satu project prj-{env}-secrets di setiap folder lingkungan untuk mengelola secret secara terpusat. Pendekatan ini memungkinkan tim pusat mengaudit dan mengelola secret yang digunakan oleh aplikasi untuk memenuhi persyaratan peraturan dan kepatuhan.

Bergantung pada model operasional, Anda dapat memilih satu instance Secret Manager terpusat di bawah kendali satu tim, atau mengelola secret secara terpisah di setiap lingkungan. Atau, Anda mungkin lebih memilih beberapa instance Secret Manager terdistribusi sehingga setiap tim workload dapat mengelola secret mereka sendiri. Ubah contoh kode Terraform sesuai kebutuhan agar sesuai dengan model operasional Anda.

Merencanakan akses akses darurat ke akun istimewa tinggi

Meskipun kami merekomendasikan agar perubahan pada resource fondasi dikelola melalui IaC yang dikontrol versi dan di-deploy oleh pipeline dasar, Anda mungkin memiliki skenario luar biasa atau darurat yang memerlukan akses istimewa untuk memodifikasi lingkungan Anda secara langsung. Sebaiknya Anda membuat rencana untuk akun akses darurat (terkadang disebut akun pemadam kebakaran atau darurat) yang memiliki akses istimewa ke lingkungan Anda jika terjadi keadaan darurat atau saat proses otomatisasi mengalami gangguan.

Tabel berikut menjelaskan beberapa contoh tujuan akun akses darurat.

Tujuan akses darurat Deskripsi

Admin super

Akses darurat ke peran Admin super yang digunakan dengan Cloud Identity, misalnya untuk memperbaiki masalah yang terkait dengan penggabungan identitas atau autentikasi multi-faktor (MFA).

Administrator organisasi

Akses darurat ke peran Organization Administrator, yang kemudian dapat memberikan akses ke peran IAM lainnya di organisasi.

Administrator pipeline fondasi

Akses darurat untuk mengubah resource di project CICD Anda di Google Cloud dan repositori Git eksternal jika otomatisasi pipeline foundation tidak berfungsi.

Operasi atau SRE

Tim operasi atau SRE memerlukan akses istimewa untuk merespons pemadaman layanan atau insiden. Tindakan ini dapat mencakup tugas seperti memulai ulang VM atau memulihkan data.

Mekanisme Anda untuk mengizinkan akses akses darurat bergantung pada alat dan prosedur yang Anda miliki, tetapi beberapa contoh mekanisme mencakup berikut ini:

  • Gunakan alat yang sudah ada untuk pengelolaan akses hak istimewa guna menambahkan pengguna untuk sementara ke grup yang telah ditentukan sebelumnya dengan peran IAM dengan hak istimewa tinggi atau menggunakan kredensial akun dengan hak istimewa tinggi.
  • Pra-penyediaan akun yang dimaksudkan hanya untuk penggunaan administrator. Misalnya, developer Dana mungkin memiliki identitas dana@example.com untuk penggunaan sehari-hari dan admin-dana@example.com untuk akses akses darurat.
  • Gunakan aplikasi seperti akses istimewa tepat waktu yang memungkinkan developer melakukan eskalasi mandiri ke peran dengan hak istimewa yang lebih tinggi.

Apa pun mekanisme yang Anda gunakan, pertimbangkan cara operasional Anda menjawab pertanyaan-pertanyaan berikut:

  • Bagaimana Anda merancang ruang lingkup dan perincian akses akses darurat? Misalnya, Anda dapat mendesain mekanisme akses darurat yang berbeda untuk unit bisnis yang berbeda guna memastikan bahwa keduanya tidak dapat saling mengganggu.
  • Bagaimana mekanisme Anda mencegah penyalahgunaan? Apakah Anda memerlukan persetujuan? Misalnya, Anda mungkin melakukan operasi pemisahan dengan satu orang memegang kredensial dan satu orang memegang token MFA.
  • Bagaimana cara mengaudit dan memberi peringatan terkait akses akses darurat? Misalnya, Anda dapat mengonfigurasi modul Event Threat Detection kustom untuk membuat temuan keamanan saat akun akses darurat yang telah ditentukan digunakan.
  • Bagaimana cara menghapus akses akses darurat dan melanjutkan operasi normal setelah insiden berakhir?

Untuk tugas eskalasi akses umum dan roll back perubahan, sebaiknya buat desain alur kerja otomatis tempat pengguna dapat melakukan operasi tanpa memerlukan eskalasi hak istimewa untuk identitas pengguna mereka. Pendekatan ini dapat membantu mengurangi kesalahan manusia dan meningkatkan keamanan.

Untuk sistem yang memerlukan intervensi rutin, mengotomatiskan perbaikan mungkin merupakan solusi terbaik. Google mendorong pelanggan untuk mengadopsi pendekatan produksi zero-touch untuk membuat semua perubahan produksi menggunakan otomatisasi, proxy yang aman, atau akses darurat yang diaudit. Google menyediakan buku SRE bagi pelanggan yang ingin menggunakan pendekatan SRE Google.

Langkah selanjutnya