# OPS 7. Bagaimana cara mengetahui bahwa Anda siap untuk mendukung beban kerja?
Evaluasi kesiapan operasional beban kerja, proses, dan prosedur, serta personel Anda untuk memahami risiko operasional terkait beban kerja Anda.
**Topics**
+ [OPS07-BP01 Memastikan kemampuan personel](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 Memastikan peninjauan yang konsisten terkait kesiapan operasional](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 Menggunakan runbook untuk menjalankan prosedur](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 Menggunakan buku panduan untuk menyelidiki masalah](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 Membuat keputusan yang tepat untuk melakukan deployment sistem dan perubahan](ops_ready_to_support_informed_deploy_decisions.md)
+ [OPS07-BP06 Mengaktifkan rencana dukungan untuk beban kerja produksi](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 Memastikan kemampuan personel
Miliki mekanisme untuk memvalidasi bahwa Anda memiliki jumlah personel terlatih yang sesuai untuk mendukung beban kerja. Mereka harus diberi pelatihan tentang platform dan layanan yang membentuk beban kerja Anda. Berikan kepada mereka pengetahuan yang diperlukan untuk mengoperasikan beban kerja. Anda harus memiliki cukup banyak personel terlatih untuk mendukung pengoperasian normal beban kerja dan menyelesaikan masalah terkait insiden yang muncul. Miliki cukup banyak personel sehingga Anda dapat melakukan rotasi untuk personel yang siap tugas mendadak dan personel yang liburan guna menghindari personel menjadi terlalu lelah.
**Hasil yang diinginkan:**
+ Ada cukup banyak personel terlatih untuk mendukung beban kerja pada saat beban kerja tersedia.
+ Anda memberikan pelatihan untuk personel tentang perangkat lunak dan layanan yang membentuk beban kerja Anda.
**Antipola umum:**
+ Melakukan deployment beban kerja tanpa anggota tim yang terlatih untuk mengoperasikan platform dan layanan yang digunakan.
+ Tidak memiliki cukup banyak personel untuk mendukung rotasi personel yang siap tugas mendadak atau personel yang sedang libur.
**Manfaat menjalankan praktik terbaik ini:**
+ Memiliki anggota tim yang terampil memungkinkan dukungan yang efektif untuk beban kerja.
+ Dengan cukup banyak anggota tim, Anda dapat mendukung beban kerja dan rotasi personel yang siap tugas mendadak sekaligus mengurangi risiko personel terlalu lelah.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Validasikan bahwa terdapat personel yang terlatih dengan memadai untuk mendukung beban kerja. Pastikan Anda memiliki jumlah anggota tim yang cukup untuk menangani aktivitas operasional normal, termasuk rotasi personel siap tugas mendadak.
**Contoh pelanggan**
AnyCompany Retail memastikan tim yang mendukung beban kerja memiliki staf yang terlatih dalam jumlah yang sesuai. Mereka memiliki cukup banyak rekayasawan untuk mendukung rotasi personel yang siap tugas mendadak. Personel mendapatkan pelatihan tentang perangkat lunak dan platform yang merupakan dasar pembangunan beban kerja dan mereka didorong untuk mendapatkan sertifikasi. Ada cukup banyak personel sehingga orang dapat mengambil cuti sambil tetap ada dukungan untuk beban kerja dan rotasi personel yang siap tugas mendadak.
**Langkah implementasi**
1. Tetapkan jumlah personel yang memadai untuk mengoperasikan dan mendukung beban kerja Anda, termasuk tugas mendadak.
1. Latih personel Anda tentang perangkat lunak dan platform yang membentuk beban kerja Anda.
1. [AWS Training and Certification](https://aws.amazon.com/training/) memiliki pustaka kursus tentang AWS. Kursus-kursus ini disediakan gratis dan berbayar, baik secara online maupun tatap muka.
1. [AWS melakukan hosting acara dan webinar](https://aws.amazon.com/events/) di mana Anda belajar dari para ahli AWS.
1. Evaluasi ukuran dan keterampilan tim secara teratur seiring perubahan kondisi pengoperasian dan beban kerja. Sesuaikan ukuran dan keterampilan tim agar memenuhi persyaratan operasional.
**Tingkat upaya untuk rencana implementasi:** Tinggi. Mempekerjakan dan melatih tim untuk mendukung beban kerja dapat memerlukan upaya yang cukup besar tetapi memiliki manfaat jangka panjang yang substansial.
## Sumber daya
**Praktik Terbaik Terkait:**
+ [OPS11-BP04 Menjalankan manajemen pengetahuan](ops_evolve_ops_knowledge_management.md) - Anggota tim harus memiliki informasi yang diperlukan untuk mengoperasikan dan mendukung beban kerja. Manajemen pengetahuan merupakan kunci untuk penyediaan tersebut.
**Dokumen terkait:**
+ [Acara dan Webinar AWS](https://aws.amazon.com/events/)
+ [AWS Training and Certification](https://aws.amazon.com/training/)
# OPS07-BP02 Memastikan peninjauan yang konsisten terkait kesiapan operasional
Gunakan Peninjauan Kesiapan Operasional (ORR) untuk memvalidasi bahwa Anda dapat mengoperasikan beban kerja Anda. ORR adalah mekanisme yang dikembangkan di Amazon untuk memvalidasi bahwa tim dapat mengoperasikan beban kerja mereka dengan aman. ORR adalah proses peninjauan dan inspeksi menggunakan daftar periksa persyaratan. ORR adalah pengalaman layanan mandiri yang digunakan tim untuk memastikan beban kerja mereka. ORR mencakup praktik terbaik dari pelajaran yang kami dapatkan selama bertahun-tahun membangun perangkat lunak.
Daftar periksa ORR terdiri dari rekomendasi arsitektur, proses operasional, manajemen peristiwa, dan kualitas rilis. Proses Koreksi Kesalahan (CoE) kami merupakan pendorong utama item-item ini. Analisis pascainsiden Anda sendiri harus mendorong pengembangan ORR Anda. ORR tidak hanya tentang mengikuti praktik terbaik tapi juga mencegah kemungkinan peristiwa yang telah Anda lihat sebelumnya. Terakhir, keamanan, pengelolaan, dan kepatuhan persyaratan juga dapat disertakan dalam ORR.
Jalankan ORR sebelum beban kerja meluncur ke ketersediaan umum dan kemudian ke seluruh siklus pengembangan perangkat lunak. Menjalankan ORR sebelum peluncuran meningkatkan kemampuan Anda untuk mengoperasikan beban kerja dengan aman. Jalankan kembali ORR Anda secara berkala pada beban kerja untuk mengetahui penyimpangan dari praktik terbaik. Anda dapat memiliki daftar periksa ORR untuk peluncuran layanan baru dan ORR untuk peninjauan berkala. Ini membantu Anda untuk tetap up to date dengan praktik terbaik yang muncul dan menggabungkan pelajaran yang didapatkan dari analisis pascainsiden. Saat penggunaan cloud Anda matang, Anda dapat membangun persyaratan ORR ke dalam arsitektur Anda secara default.
**Hasil yang diinginkan:** Anda memiliki daftar periksa ORR dengan praktik terbaik untuk organisasi Anda. ORR dilakukan sebelum peluncuran beban kerja. ORR dijalankan secara berkala selama kursus siklus beban kerja.
**Antipola umum:**
+ Anda meluncurkan beban kerja tanpa mengetahui apakah Anda dapat mengoperasikannya.
+ Persyaratan pengelolaan dan keamanan tidak diikutsertakan ketika menyertifikasi beban kerja untuk peluncuran.
+ Beban kerja tidak dievaluasi kembali secara berkala.
+ Beban kerja diluncurkan tanpa diterapkannya prosedur yang diperlukan.
+ Anda melihat pengulangan kegagalan akar masalah yang sama di beberapa beban kerja.
**Manfaat menjalankan praktik terbaik ini:**
+ Beban kerja Anda mencakup praktik terbaik arsitektur, proses, dan manajemen.
+ Pelajaran yang didapatkan digabungkan dalam proses ORR.
+ Prosedur yang diperlukan tersedia ketika beban kerja diluncurkan.
+ ORR dijalankan di seluruh siklus perangkat lunak beban kerja Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
ORR adalah dua hal: proses dan daftar periksa. Proses ORR Anda harus diadopsi oleh organisasi Anda dan didukung oleh sponsor eksekutif. Minimal, ORR harus dilakukan sebelum beban kerja meluncur ke ketersediaan umum. Jalankan ORR di seluruh siklus pengembangan perangkat lunak untuk tetap up to date dengan praktik terbaik atau persyaratan baru. Daftar periksa ORR harus mencakup item konfigurasi, persyaratan keamanan dan pengelolaan, serta praktik terbaik dari organisasi Anda. Seiring waktu, Anda dapat menggunakan layanan, seperti [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html), dan [Pagar Pembatas AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html), untuk membangun praktik terbaik dari ORR ke pagar pembatas untuk deteksi praktik terbaik secara otomatis.
**Contoh pelanggan**
Setelah beberapa insiden produksi, AnyCompany Retail memutuskan untuk menerapkan proses ORR. Mereka membangun daftar periksa yang terdiri dari praktik terbaik, persyaratan pengelolaan dan kepatuhan, serta pelajaran yang didapatkan dari pemadaman. Beban kerja baru melakukan ORR sebelum diluncurkan. Setiap beban kerja melakukan ORR setiap tahun dengan sebagian praktik terbaik untuk menggabungkan praktik terbaik dan persyaratan baru yang ditambahkan ke daftar periksa ORR. Seiring waktu, AnyCompany Retail menggunakan [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) untuk mendeteksi beberapa praktik terbaik, yang mempercepat proses ORR.
**Langkah implementasi**
Untuk mempelajari selengkapnya tentang ORR, baca: [laporan resmi Peninjauan Kesiapan Operasional (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Laporan resmi ini menyediakan detail informasi tentang riwayat proses ORR, cara membangun praktik ORR Anda sendiri, dan cara mengembangkan daftar periksa ORR Anda. Langkah-langkah berikut ini merupakan versi singkat dari dokumen tersebut. Untuk pemahaman yang mendalam tentang apa itu ORR dan bagaimana membangunnya, sebaiknya baca laporan resmi tersebut.
1. Kumpulkan pemangku kepentingan utama, termasuk perwakilan dari keamanan, operasi, dan pengembangan.
1. Minta setiap pemangku kepentingan untuk menyediakan setidaknya satu persyaratan. Untuk iterasi pertama, coba batasi jumlah item menjadi 30 atau kurang.
+ [Lampiran B: Contoh pertanyaan ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) dari laporan resmi Peninjauan Kesiapan Operasional (ORR) yang berisi sampel pertanyaan yang dapat Anda gunakan untuk memulai.
1. Kumpulkan persyaratan Anda ke dalam lembar kerja.
+ Anda dapat menggunakan [lensa kustom](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) di [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) untuk mengembangkan ORR Anda dan membagikannya ke seluruh akun dan Organisasi AWS Anda.
1. Identifikasi satu beban kerja untuk diberikan ORR. Idealnya adalah beban kerja sebelum peluncuran atau beban kerja internal.
1. Pelajari daftar periksa ORR dan catat semua penemuan yang dibuat. Penemuannya mungkin akan buruk jika terdapat mitigasi. Untuk penemuan yang minim mitigasi, tambahkan beban kerja ke backlog item Anda dan implementasikan sebelum peluncuran.
1. Lanjutkan penambahan praktik terbaik dan persyaratan ke daftar periksa ORR Anda seiring waktu.
Pelanggan Dukungan dengan Enterprise Support dapat mengajukan permintaan [Lokakarya Peninjauan Kesiapan Operasional](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) dari Manajer Akun Teknis mereka. Lokakarya ini adalah sesi *penelusuran mundur (working backward)* interaktif untuk mengembangkan daftar periksa ORR Anda.
**Tingkat upaya untuk rencana implementasi:** Tinggi. Untuk mengadopsi praktik ORR pada organisasi Anda diperlukan sponsor eksekutif dan dukungan pemangku kepentingan. Buat dan perbarui daftar periksa dengan masukan dari seluruh organisasi Anda.
## Sumber daya
**Praktik Terbaik Terkait:**
+ [OPS01-BP03 Evaluasi persyaratan tata kelola](ops_priorities_governance_reqs.md) – Persyaratan tata kelola sangat sesuai untuk daftar periksa ORR.
+ [OPS01-BP04 Evaluasi persyaratan kepatuhan](ops_priorities_compliance_reqs.md) – Terkadang persyaratan kepatuhan tercantum di daftar periksa ORR. Terkadang persyaratan kepatuhan adalah proses yang terpisah.
+ [OPS03-BP07 Bekali tim dengan sumber daya dengan sesuai](ops_org_culture_team_res_appro.md) – Kemampuan tim merupakan kandidat yang bagus untuk persyaratan ORR.
+ [OPS06-BP01 Antisipasikan perubahan yang tidak berhasil](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Rencana rollback atau rollfoward harus dibuat sebelum Anda meluncurkan beban kerja Anda.
+ [OPS07-BP01 Memastikan kemampuan personel](ops_ready_to_support_personnel_capability.md) – Untuk mendukung beban kerja, Anda harus memiliki personel yang diperlukan.
+ [SEC01-BP03 Mengidentifikasi dan memvalidasi tujuan kontrol](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – Tujuan kontrol keamanan menyempurnakan persyaratan ORR.
+ [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – Rencana pemulihan bencana merupakan persyaratan ORR yang bagus.
+ [COST02-BP01 Mengembangkan kebijakan berdasarkan keperluan organisasi Anda](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – Kebijakan manajemen biaya bagus untuk dicantumkan dalam daftar ORR Anda.
**Dokumen terkait:**
+ [AWS Control Tower - Pagar Pembatas di AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool - Lensa Kustom](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Templat Peninjauan Kesiapan Operasional oleh Adrian Hornsby](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [Laporan Resmi Peninjauan Kesiapan Operasional (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**Video terkait:**
+ [AWS Dukungan Anda \$1 Membangun Peninjauan Kesiapan Operasional (ORR) yang Efektif](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**Contoh terkait:**
+ [Sampel Lensa Peninjauan Kesiapan Operasional (ORR)](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**Layanan terkait:**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 Menggunakan runbook untuk menjalankan prosedur
Sebuah *runbook* adalah proses terdokumentasi untuk mencapai hasil tertentu. Runbook terdiri dari serangkaian langkah yang diikuti seseorang untuk menyelesaikan sesuatu. Runbook telah digunakan dalam operasi sejak masa-masa awal industri penerbangan. Dalam operasi cloud, kita menggunakan runbook untuk mengurangi risiko dan mencapai hasil yang diinginkan. Dalam bentuk paling sederhananya, runbook adalah daftar periksa untuk menyelesaikan tugas.
Runbook adalah bagian penting dari operasi beban kerja Anda. Mulai dari orientasi anggota tim baru hingga melakukan deployment rilis utama, runbook adalah proses terkodifikasi yang memberikan hasil konsisten, siapa pun yang menggunakannya. Runbook harus dipublikasikan di lokasi sentral dan diperbarui seiring prosesnya berkembang karena memperbarui runbook adalah komponen utama dari proses manajemen perubahan. Runbook juga harus menyertakan panduan tentang penanganan kesalahan, alat, izin, pengecualian, dan eskalasi jika terjadi masalah.
Saat organisasi Anda matang, mulailah mengotomatiskan runbook. Mulailah dengan runbook yang singkat dan sering digunakan. Gunakan bahasa skrip untuk mengotomatiskan langkah-langkah atau mempermudah pelaksanaan langkah-langkah. Seiring Anda mengotomatiskan beberapa runbook pertama, Anda akan mendedikasikan waktu untuk mengotomatiskan runbook yang lebih kompleks. Seiring waktu, sebagian besar runbook Anda harus diotomatiskan dalam cara tertentu.
**Hasil yang diinginkan:** Tim Anda memiliki kumpulan panduan langkah demi langkah untuk melakukan tugas beban kerja. Runbook berisi hasil yang diinginkan, alat dan izin yang diperlukan, serta petunjuk untuk penanganan kesalahan. Runbook disimpan di lokasi sentral dan sering diperbarui.
**Antipola umum:**
+ Mengandalkan memori untuk menyelesaikan setiap langkah dari suatu proses.
+ Menerapkan perubahan secara manual tanpa daftar periksa.
+ Anggota tim yang berbeda-beda melakukan proses yang sama, tetapi dengan langkah atau hasil yang berbeda.
+ Membiarkan runbook tidak sinkron dengan perubahan sistem dan otomatisasi.
**Manfaat menjalankan praktik terbaik ini:**
+ Mengurangi tingkat kesalahan untuk tugas manual.
+ Operasi dilakukan secara konsisten.
+ Anggota tim baru dapat mulai melakukan tugas dengan lebih cepat.
+ Runbook dapat diotomatiskan untuk mengurangi upaya yang diperlukan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Runbook dapat memiliki beberapa bentuk, bergantung pada tingkat kematangan organisasi Anda. Minimal, runbook harus terdiri dari dokumen teks langkah demi langkah. Hasil yang diinginkan harus ditunjukkan dengan jelas. Dokumentasikan dengan jelas izin atau alat khusus yang diperlukan. Berikan panduan mendetail tentang penanganan kesalahan dan eskalasi jika terjadi kesalahan. Cantumkan pemilik runbook dan publikasikan di lokasi sentral. Setelah runbook Anda didokumentasikan, validasikan dengan meminta orang lain di tim Anda untuk menjalankannya. Seiring prosedur berkembang, perbarui runbook Anda sesuai dengan proses manajemen perubahan Anda.
Runbook teks Anda harus diotomatiskan seiring organisasi Anda makin matang. Dengan layanan seperti [otomatisasi AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), Anda dapat mentransformasikan teks biasa menjadi otomatisasi yang dapat dijalankan dengan beban kerja Anda. Otomatisasi ini dapat dijalankan sebagai respons terhadap peristiwa, sehingga mengurangi beban operasional untuk memelihara beban kerja Anda.
**Contoh pelanggan**
AnyCompany Retail harus melakukan pembaruan skema basis data selama deployment perangkat lunak. Tim Operasi Cloud bekerja sama dengan Tim Administrasi Basis Data untuk membuat runbook guna menerapkan perubahan ini secara manual. Runbook ini mencantumkan setiap langkah prosesnya dalam bentuk daftar periksa. Runbook ini berisi bagian tentang penanganan kesalahan jika terjadi kesalahan. Mereka memublikasikan runbook di wiki internal mereka bersama dengan runbook mereka yang lain. Tim Operasi Cloud berencana untuk mengotomatiskan runbook dalam sprint mendatang.
## Langkah implementasi
Jika Anda belum memiliki repositori dokumen, repositori kontrol versi adalah tempat yang tepat untuk mulai membangun pustaka runbook Anda. Anda dapat membangun runbook Anda menggunakan Markdown. Kami telah menyediakan contoh templat runbook yang dapat Anda gunakan untuk mulai membangun runbook.
```
# Judul Runbook ## Info Runbook | ID Runbook | Deskripsi | Alat yang Digunakan | Izin Khusus | Penulis Runbook | Terakhir Diperbarui | POC Eskalasi | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | Apa tujuan penggunaan runbook ini? Apa hasil yang diinginkan? | Alat | Izin | Nama Anda | 21-9-2022 | Nama Eskalasi | ## Langkah 1. Langkah pertama 2. Langkah kedua
```
1. Jika Anda belum memiliki repositori atau wiki dokumentasi, buat repositori kontrol versi baru di sistem kontrol versi Anda.
1. Identifikasi proses yang tidak memiliki runbook. Proses yang ideal adalah proses yang dilakukan secara semireguler, sedikit jumlah langkahnya, dan memiliki kegagalan berdampak rendah.
1. Di repositori dokumen Anda, buat draf dokumen Markdown baru menggunakan templat tersebut. Isi `Judul Runbook` dan bidang yang diperlukan di bagian `Info Runbook`.
1. Dimulai dengan langkah pertama, isi bagian `Langkah` dalam runbook ini.
1. Berikan runbook ini kepada para anggota tim. Minta mereka menggunakan runbook ini untuk memvalidasi langkah-langkahnya. Jika ada sesuatu yang belum dimasukkan atau memerlukan kejelasan, perbarui runbook ini.
1. Publikasikan runbook ini ke penyimpanan dokumentasi internal Anda. Setelah dipublikasikan, beri tahu tim Anda dan pemangku kepentingan lainnya.
1. Seiring waktu, Anda akan membangun pustaka runbook. Saat pustaka tersebut tumbuh, mulailah bekerja untuk mengotomatiskan runbook.
**Tingkat upaya untuk rencana implementasi:** Rendah. Standar minimum untuk runbook adalah panduan teks langkah demi langkah. Mengotomatiskan runbook dapat meningkatkan upaya implementasi.
## Sumber daya
**Praktik terbaik terkait:**
+ [OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi](ops_ops_model_def_proc_owners.md): Runbook harus memiliki pemilik yang bertanggung jawab untuk memeliharanya.
+ [OPS07-BP04 Menggunakan buku panduan untuk menyelidiki masalah](ops_ready_to_support_use_playbooks.md): Runbook dan playbook mirip satu sama lain dengan satu perbedaan utama: runbook memiliki hasil yang diinginkan. Dalam banyak kasus, runbook dipicu setelah playbook mengidentifikasi akar penyebab.
+ [OPS10-BP01 Menggunakan proses untuk manajemen peristiwa, insiden, dan masalah](ops_event_response_event_incident_problem_process.md): Runbook adalah bagian dari praktik manajemen yang baik terkait peristiwa, insiden, dan masalah.
+ [OPS10-BP02 Menjalankan proses untuk setiap peringatan](ops_event_response_process_per_alert.md): Runbook dan playbook harus digunakan untuk menanggapi peringatan. Seiring waktu, reaksi ini harus diotomatiskan.
+ [OPS11-BP04 Menjalankan manajemen pengetahuan](ops_evolve_ops_knowledge_management.md): Memelihara runbook adalah bagian penting dari manajemen pengetahuan.
**Dokumen terkait:**
+ [Mencapai Keunggulan Operasional menggunakan playbook dan runbook otomatis](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: Bekerja dengan runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Playbook migrasi untuk migrasi besar AWS - Tugas 4: Meningkatkan runbook migrasi Anda](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [Gunakan runbook Otomatisasi AWS Systems Manager untuk menyelesaikan tugas operasional](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Video terkait:**
+ [AWS re:Invent 2019: Panduan mandiri untuk runbook, laporan insiden, dan respons insiden (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [Cara mengotomatiskan Operasi IT di AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [Integrasikan Skrip ke dalam AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Contoh terkait:**
+ [AWS Systems Manager: Panduan otomatisasi](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager: Pulihkan volume root dari snapshot runbook terbaru](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [Membangun runbook respons insiden AWS menggunakan notebook Jupyter dan CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab - Runbook](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix - Pustaka Python untuk membuat runbook di Notebook Jupyter](https://github.com/Nurtch/rubix)
+ [Menggunakan Document Builder untuk membuat runbook kustom](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [Lab Well-Architected: Mengotomatiskan operasi dengan Playbook dan Runbook](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
**Layanan terkait:**
+ [Otomatisasi AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 Menggunakan buku panduan untuk menyelidiki masalah
Playbook adalah panduan mendetail yang digunakan untuk menyelidiki insiden. Ketika terjadi sebuah insiden, playbook digunakan untuk menyelidiki, membuat cakupan dampak, dan mengidentifikasi akar masalah. Playbook digunakan untuk berbagai skenario, dari deployment yang gagal hingga insiden keamanan. Dalam banyak kasus, playbook mengidentifikasi akar masalah yang dimitigasi menggunakan runbook. Playbook adalah komponen pokok dalam rencana respons insiden organisasi Anda.
Playbook yang baik memiliki sejumlah fitur utama. Playbook memberikan panduan secara mendetail bagi pengguna, dalam proses penemuan. Dengan berpikir secara holistik, langkah apa saja yang sebaiknya diikuti seseorang untuk mendiagnosis insiden? Tetapkan secara jelas di dalam playbook jika alat-alat khusus atau izin yang dinaikkan diperlukan di dalam playbook. Memiliki rencana komunikasi untuk memberi informasi kepada para pemangku kepentingan mengenai status penyelidikan adalah komponen utama. Dalam situasi ketika akar penyebab tidak dapat diidentifikasi, playbook harus memiliki rencana eskalasi. Jika akar masalah diidentifikasi, playbook harus mengarah ke runbook yang menjelaskan cara menyelesaikannya. Playbook harus disimpan secara terpusat dan dipelihara secara rutin. Jika playbook digunakan untuk pemberitahuan khusus, bekali tim Anda dengan penunjuk ke playbook di dalam pemberitahuan tersebut.
Otomatisasi playbook Anda seiring kematangan organisasi. Mulai dengan playbook yang mencakup insiden berisiko rendah. Gunakan penulisan skrip untuk mengotomatiskan langkah-langkah penemuan. Pastikan Anda memiliki runbook pendamping untuk memitigasi akar masalah umum.
**Hasil yang diinginkan:** Organisasi Anda memiliki playbook untuk insiden umum. Playbook disimpan di lokasi terpusat dan tersedia untuk anggota tim Anda. Playbook sering diperbarui. Runbook pendamping dibuat untuk akar masalah apa pun yang diketahui.
**Antipola umum:**
+ Tidak ada cara standar untuk menyelidiki insiden.
+ Anggota tim mengandalkan memori otot atau pengetahuan institusional untuk memecahkan masalah kegagalan deployment.
+ Anggota tim baru mempelajari cara menyelidiki permasalahan melalui coba-coba.
+ Praktik terbaik untuk menyelidiki permasalahan tidak dibagikan ke seluruh tim.
**Manfaat menjalankan praktik terbaik ini:**
+ Playbook meningkatkan upaya Anda untuk memitigasi insiden.
+ Anggota tim yang berbeda-beda dapat menggunakan playbook yang sama untuk mengidentifikasi akar masalah secara konsisten.
+ Setelah akar masalah diketahui kemudian bisa dikembangkan runbook, sehingga dapat mempercepat waktu pemulihan.
+ Playbook memungkinkan anggota tim untuk mulai berkontribusi lebih cepat.
+ Tim dapat menskalakan proses mereka dengan playbook yang dapat diulang.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Bagaimana Anda membangun dan menggunakan playbook bergantung pada kematangan organisasi Anda. Jika Anda baru mengenal cloud, bangun playbook dalam bentuk teks di dalam repositori dokumen pusat. Seiring kematangan organisasi, playbook dapat menjadi semi-otomatis dengan bahasa skrip seperti Python. Skrip-skrip ini dapat dijalankan di dalam notebook Jupyter untuk mempercepat penemuan. Organisasi tingkat lanjut memiliki playbook yang sepenuhnya otomatis untuk permasalahan umum yang diperbaiki secara otomatis dengan runbook.
Mulai bangun playbook Anda dengan mengidentifikasi insiden-insiden umum yang terjadi pada beban kerja Anda. Pilih playbook untuk insiden berisiko rendah dan dengan akar masalah yang telah dipersempit menjadi beberapa permasalahan untuk mengawalinya. Setelah Anda memiliki playbook untuk skenario yang lebih sederhana, beralihlah ke skenario berisiko lebih tinggi atau skenario dengan akar masalah yang tidak dikenal dengan baik.
Playbook teks Anda harus diotomatiskan seiring pematangan organisasi Anda. Dengan layanan seperti [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), teks biasa dapat ditransformasikan menjadi otomatis. Otomatisasi ini dapat dijalankan terhadap beban kerja untuk mempercepat penyelidikan. Otomatisasi ini dapat diaktifkan untuk merespons peristiwa, sehingga mengurangi rata-rata waktu untuk menemukan dan menyelesaikan insiden.
Pelanggan dapat menggunakan [Manajer Insiden AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) untuk merespons insiden. Layanan ini menyediakan satu antarmuka untuk memeriksa insiden, memberi informasi kepada pemangku kepentingan selama penemuan dan mitigasi, dan berkolaborasi melalui insiden. Layanan ini menggunakan AWS Systems Manager Automations untuk mempercepat deteksi dan pemulihan.
**Contoh pelanggan**
Insiden produksi memberikan dampak pada AnyCompany Retail. Rekayasawan yang siap dipanggil kapan saja (on-call) menggunakan playbook untuk menyelidiki permasalahan. Seiring mereka mengikuti langkah-langkahnya, mereka terus memutakhirkan pemangku kepentingan utama yang diidentifikasi di dalam playbook. Rekayasawan mengidentifikasi akar masalah sebagai kondisi pacu di dalam layanan backend. Menggunakan runbook, rekayasawan meluncurkan ulang layanan, sehingga AnyCompany Retail dapat kembali online.
## Langkah implementasi
Jika Anda belum memiliki repositori dokumen, kami menyarankan pembuatan repositori kontrol versi untuk pustaka playbook Anda. Anda dapat membangun playbook Anda menggunakan Markdown, yang kompatibel dengan sebagian besar sistem otomatisasi playbook. Jika Anda memulai dari nol, gunakan contoh templat playbook berikut ini.
```
# Judul Playbook ## Info Playbook | ID Playbook | Deskripsi | Alat yang Digunakan | Izin Khusus | Penyusun Playbook | Terakhir Diperbarui | POC Eskalasi | Pemangku Kepentingan | Rencana Komunikasi | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | Untuk apa playbook ini? Untuk insiden apa playbook ini? | Alat | Izin | Nama Anda | 21-09-2022 | Nama Eskalasi | Nama Pemangku Kepentingan | Bagaimana pembaruan akan disampaikan selama penyelidikan? | ## Langkah 1. Langkah pertama 2. Langkah kedua
```
1. Jika Anda belum memiliki repositori dokumen atau wiki, buat repositori kontrol versi baru untuk playbook Anda di sistem kontrol versi Anda.
1. Identifikasi permasalahan umum yang memerlukan penyelidikan. Ini sebaiknya adalah skenario dengan akar masalah yang dibatasi ke beberapa permasalahan dan penyelesaiannya berisiko rendah.
1. Menggunakan templat Markdown, lengkapi bagian `Nama Playbook` dan bidang di bawah `Info Playbook`.
1. Lengkapi langkah-langkah pemecahan masalah. Sampaikan sejelas mungkin tindakan yang akan dilakukan atau area apa saja yang harus Anda selidiki.
1. Berikan playbook tersebut kepada anggota tim dan minta mereka mempelajari dan memvalidasinya. Jika terdapat hal yang terlewat atau tidak jelas, perbarui playbook.
1. Terbitkan playbook di dalam repositori dokumen Anda dan informasikan kepada tim dan pemangku kepentingan.
1. Pustaka playbook ini akan tumbuh seiring Anda menambahkan lebih banyak playbook. Setelah Anda memiliki beberapa playbook, mulailah mengotomatiskannya menggunakan alat seperti AWS Systems Manager Automations untuk terus menyinkronkan otomatisasi dan playbook.
**Tingkat upaya untuk rencana implementasi:** Rendah. Playbook Anda harus berupa dokumen teks yang disimpan di lokasi terpusat. Organisasi yang lebih matang akan beralih ke otomatisasi playbook.
## Sumber daya
**Praktik terbaik terkait:**
+ [OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi](ops_ops_model_def_proc_owners.md): Runbook harus memiliki pemilik yang bertanggung jawab untuk memeliharanya.
+ [OPS07-BP03 Menggunakan runbook untuk menjalankan prosedur](ops_ready_to_support_use_runbooks.md): Runbook dan playbook mirip, tetapi dengan satu perbedaan utama: runbook memiliki hasil yang diinginkan. Dalam banyak kasus, runbook digunakan setelah playbook mengidentifikasi akar penyebab.
+ [OPS10-BP01 Menggunakan proses untuk manajemen peristiwa, insiden, dan masalah](ops_event_response_event_incident_problem_process.md): Playbook adalah bagian dari praktik manajemen yang baik terkait peristiwa, insiden, dan masalah.
+ [OPS10-BP02 Menjalankan proses untuk setiap peringatan](ops_event_response_process_per_alert.md): Runbook dan playbook harus digunakan untuk menanggapi peringatan. Seiring waktu, reaksi ini harus diotomatiskan.
+ [OPS11-BP04 Menjalankan manajemen pengetahuan](ops_evolve_ops_knowledge_management.md): Memelihara playbook adalah bagian penting dari manajemen pengetahuan.
**Dokumen terkait:**
+ [ Mencapai Keunggulan Operasional menggunakan playbook dan runbook otomatis ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: Bekerja dengan runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [ Gunakan runbook AWS Systems Manager Automations untuk menyelesaikan tugas operasional ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Video terkait:**
+ [AWS re:Invent 2019: Panduan mandiri untuk runbook, laporan insiden, dan respons insiden (SEC318-R1) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [Manajer Insiden AWS Systems Manager - Lokakarya Virtual AWS](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ Integrasikan Skrip ke dalam AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Contoh terkait:**
+ [ Kerangka Kerja Playbook Pelanggan AWS](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager: Panduan otomatisasi ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ Membangun runbook respons insiden AWS menggunakan notebook Jupyter dan CloudTrail Lake ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix – Pustaka Python untuk membuat runbook di Notebook Jupyter ](https://github.com/Nurtch/rubix)
+ [ Menggunakan Document Builder untuk membuat runbook kustom ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Lab Well-Architected: Mengotomatiskan operasi dengan Playbook dan Runbook ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Lab Well-Architect: Playbook respons insiden dengan Jupyter ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
**Layanan terkait:**
+ [AWS Systems Manager Automation ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Manajer Insiden AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 Membuat keputusan yang tepat untuk melakukan deployment sistem dan perubahan
Miliki proses untuk perubahan yang sukses dan tidak sukses pada beban kerja Anda. Pre-mortem adalah latihan simulasi tim terhadap kegagalan untuk mengembangkan strategi mitigasi. Gunakan pre-mortem untuk mengantisipasi kegagalan dan menciptakan prosedur ketika diperlukan. Evaluasi manfaat dan risiko dari deployment perubahan ke beban kerja Anda. Verifikasi apakah semua perubahan mematuhi tata kelola.
**Hasil yang diinginkan:**
+ Anda mengambil keputusan yang tepat ketika melakukan deployment perubahan ke beban kerja Anda.
+ Perubahan mematuhi tata kelola.
**Antipola umum:**
+ Melakukan deployment perubahan ke beban kerja tanpa proses untuk menangani deployment yang gagal.
+ Membuat perubahan pada lingkungan produksi Anda yang tidak mematuhi persyaratan tata kelola.
+ Melakukan deployment versi baru beban kerja Anda tanpa menetapkan garis dasar untuk pemanfaatan sumber daya.
**Manfaat menjalankan praktik terbaik ini:**
+ Anda siap untuk menangani perubahan yang tidak sukses pada beban kerja Anda.
+ Perubahan pada beban kerja Anda mematuhi kebijakan tata kelola.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Rendah
## Panduan implementasi
Gunakan pre-mortem guna mengembangkan proses untuk perubahan yang tidak sukses. Dokumentasikan proses Anda untuk perubahan yang tidak sukses. Pastikan semua perubahan mematuhi tata kelola. Evaluasi manfaat dan risiko deployment perubahan ke beban kerja Anda.
**Contoh pelanggan**
AnyCompany Retail melakukan pre-mortem secara teratur guna memvalidasi proses mereka untuk perubahan yang tidak sukses. Mereka mendokumentasikan proses mereka di Wiki bersama dan sering kali memperbaruinya. Semua perubahan mematuhi persyaratan tata kelola.
**Langkah implementasi**
1. Ambil keputusan yang tepat ketika melakukan deployment perubahan ke beban kerja Anda. Tetapkan dan tinjau kriteria untuk deployment yang sukses. Kembangkan skenario atau kriteria yang akan memicu pengembalian perubahan ke versi sebelumnya. Pikirkan manfaat deployment perubahan dibandingkan risiko perubahan yang tidak sukses.
1. Verifikasi apakah semua perubahan mematuhi kebijakan tata kelola.
1. Gunakan pre-mortem guna membuat rencana untuk perubahan yang tidak sukses dan mendokumentasikan strategi mitigasi. Jalankan sesi latihan table-top untuk memperagakan perubahan yang tidak sukses dan memvalidasi prosedur pengembalian ke versi sebelumnya.
**Tingkat upaya untuk rencana implementasi:** Sedang. Mengimplementasikan praktik pre-mortem memerlukan koordinasi dan upaya dari para pemangku kepentingan dalam seluruh organisasi Anda
## Sumber daya
**Praktik terbaik terkait:**
+ [OPS01-BP03 Evaluasi persyaratan tata kelola](ops_priorities_governance_reqs.md) - Persyaratan tata kelola merupakan faktor kunci dalam menentukan apakah akan melakukan deployment perubahan.
+ [OPS06-BP01 Antisipasikan perubahan yang tidak berhasil](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) - Buat rencana untuk memitigasi deployment yang gagal dan gunakan pre-mortem untuk memvalidasinya.
+ [OPS06-BP02 Menguji deployment](ops_mit_deploy_risks_test_val_chg.md) - Setiap perubahan perangkat lunak harus diuji dengan tepat sebelum deployment untuk mengurangi kecacatan dalam produksi.
+ [OPS07-BP01 Memastikan kemampuan personel](ops_ready_to_support_personnel_capability.md) - Memiliki cukup banyak personel yang terlatih untuk mendukung beban kerja sangat penting dalam mengambil keputusan yang tepat dalam hal deployment perubahan sistem.
**Dokumen terkait:**
+ [Amazon Web Services: Risiko dan Kepatuhan](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [ Model Tanggung Jawab Bersama AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Tata Kelola dalam AWS Cloud: Keseimbangan yang Tepat Antara Ketangkasan dan Keamanan ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
# OPS07-BP06 Mengaktifkan rencana dukungan untuk beban kerja produksi
Aktifkan dukungan untuk perangkat lunak dan layanan yang diandalkan beban kerja produksi Anda. Pilih tingkat dukungan yang sesuai untuk memenuhi kebutuhan tingkat layanan produksi Anda. Rencana dukungan untuk dependensi ini diperlukan untuk berjaga-jaga jika ada gangguan layanan atau masalah perangkat lunak. Dokumentasikan rencana dukungan dan cara meminta dukungan untuk semua vendor perangkat lunak dan layanan. Implementasikan mekanisme yang memverifikasi bahwa titik kontak dukungan selalu yang terbaru.
**Hasil yang diinginkan:**
+ Implementasikan rencana dukungan untuk perangkat lunak dan layanan yang diandalkan beban kerja produksi.
+ Pilih rencana dukungan yang sesuai berdasarkan kebutuhan tingkat layanan.
+ Dokumentasikan rencana dukungan, tingkat dukungan, dan cara meminta dukungan.
**Antipola umum:**
+ Anda tidak memiliki rencana dukungan untuk vendor perangkat lunak yang penting. Beban kerja Anda terkena dampaknya dan Anda tidak dapat melakukan apa-apa untuk mempercepat perbaikan atau mendapatkan informasi terbaru yang tepat waktu dari vendor.
+ Developer yang merupakan titik utama kontak untuk vendor perangkat lunak tidak lagi bekerja di perusahaan. Anda tidak dapat menghubungi dukungan vendor secara langsung. Anda harus meluangkan waktu menelusuri dan mencari-cari dalam sistem kontak generik, sehingga menambah waktu yang diperlukan untuk merespons ketika diperlukan.
+ Penghentian produksi terjadi pada vendor perangkat lunak. Tidak ada dokumentasi tentang cara mengajukan kasus dukungan.
**Manfaat menjalankan praktik terbaik ini:**
+ Dengan tingkat dukungan yang sesuai, Anda dapat memperoleh respons dalam kerangka waktu yang diperlukan untuk memenuhi kebutuhan tingkat layanan.
+ Sebagai pelanggan yang didukung, Anda dapat melapor jika ada masalah produksi.
+ Vendor layanan dan perangkat lunak dapat membantu menyelesaikan masalah selama insiden.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Rendah
## Panduan implementasi
Aktifkan rencana dukungan untuk vendor perangkat lunak dan layanan yang diandalkan beban kerja produksi Anda. Atur rencana dukungan yang sesuai untuk memenuhi kebutuhan tingkat layanan Anda. Untuk pelanggan AWS, ini artinya mengaktifkan Business Support AWS atau yang lebih tinggi pada akun apa pun tempat Anda memiliki beban kerja produksi. Temui vendor dukungan secara teratur untuk mendapatkan informasi terbaru mengenai kontak, proses, dan penawaran dukungan. Dokumentasikan cara meminta dukungan dari vendor perangkat lunak dan layanan, termasuk cara melapor jika ada penghentian. Implementasikan mekanisme untuk menjaga agar kontak selalu yang terbaru.
**Contoh pelanggan**
Di AnyCompany Retail, semua dependensi layanan dan perangkat lunak komersial memiliki rencana dukungan. Contohnya, mereka mengaktifkan AWS Enterprise Support di semua akun dengan beban kerja produksi. Semua developer dapat membuka kasus dukungan bila ada masalah. Ada halaman wiki dengan informasi tentang cara meminta dukungan, siapa yang harus diberi tahu, dan praktik terbaik untuk mempercepat kasus.
**Langkah implementasi**
1. Bekerjasamalah dengan pemangku kepentingan di organisasi Anda untuk mengidentifikasi vendor perangkat lunak dan layanan yang diandalkan beban kerja Anda. Dokumentasikan dependensi ini.
1. Tentukan kebutuhan tingkat layanan untuk beban kerja Anda. Pilih rencana dukungan yang selaras dengannya.
1. Untuk layanan dan perangkat lunak komersial, tetapkan rencana dukungan dengan vendor.
1. Dengan berlangganan AWS Business Support atau lebih tinggi untuk semua akun produksi, waktu respons AWS Dukungan akan lebih cepat dan hal ini sangat disarankan. Jika Anda tidak memiliki dukungan premium, Anda harus memiliki rencana tindakan untuk menangani masalah, yang memerlukan bantuan dari AWS Dukungan. AWS Dukungan memberikan kombinasi alat dan teknologi, orang, dan program yang dirancang untuk secara proaktif membantu Anda mengoptimalkan performa, menurunkan biaya, dan berinovasi dengan lebih cepat. AWS Business Support memberikan manfaat tambahan, termasuk akses ke AWS Trusted Advisor dan AWS Personal Health Dashboard dan waktu respons yang lebih cepat.
1. Dokumentasikan rencana dukungan di alat manajemen pengetahuan Anda. Sertakan cara untuk meminta dukungan, siapa yang harus diberi tahu jika kasus dukungan diajukan, dan cara untuk melapor selama insiden. Wiki merupakan mekanisme yang bagus untuk memungkinkan semua orang membuat pembaruan yang diperlukan pada dokumentasi ketika mereka mengetahui tentang perubahan untuk mendukung proses atau kontak.
**Tingkat upaya untuk rencana implementasi:** Rendah. Sebagian besar vendor perangkat lunak dan layanan menawarkan pilihan rencana dukungan. Mendokumentasikan dan berbagi praktik terbaik terkait dukungan di sistem manajemen pengetahuan Anda akan memastikan tim Anda mengetahui tindakan yang harus dilakukan jika ada masalah produksi.
## Sumber daya
**Praktik terbaik terkait:**
+ [OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi](ops_ops_model_def_proc_owners.md)
**Dokumen terkait:**
+ [AWS Dukungan Plans ](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**Layanan terkait:**
+ [AWS Business Support ](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support ](https://aws.amazon.com/premiumsupport/plans/enterprise/)