# Model operasi
Pada bagian ini, kami telah menyediakan cara untuk memahami model operasi tempat Anda bekerja, bagaimana model itu dapat divisualisasikan, dan bagaimana, pada tingkat tim, Anda harus berevolusi untuk mengekstrak nilai maksimum dari investasi Anda yang ditanamkan dalam layanan cloud. Dengan demikian, Anda dapat meningkatkan praktik operasional Anda, membangun tim dan beban kerja yang gesit, dan berkontribusi positif terhadap hasil bisnis Anda.
Sudah menjadi hal umum bagi tim Anda untuk hadir dalam beberapa lapisan organisasi, dan lapisan tersebut memiliki cara kerja yang sekarang ada. Dengan partisipasi Anda bersama tim Anda dalam mencapai hasil bisnis artinya Anda harus memahami di mana tim Anda berada di lapisan tersebut, posisi tim yang berinteraksi dengan Anda, dan bagaimana cara kerja mereka. Berikutnya, tim harus memahami peran mereka dalam kesuksesan tim lain, mengetahui peran tim lain dalam kesuksesan mereka, dan memiliki sasaran bersama.
Lapisan-lapisan ini membentuk model operasi keseluruhan organisasi. Bagaimana organisasi berfungsi untuk memberikan hasil bisnis akan tergantung pada banyak faktor, seperti jenis, industri, geografi, ukuran, dan tingkat otonomi. Namun demikian, bisa dikelompokkan dalam tiga kategori besar:
+ Tersentralisasi
+ Terdesentralisasi
+ Terfederasi
Topologi tingkat organisasi ini dijelaskan dalam [Mengatur untuk kesuksesan](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/implement-roadmap.html#organize).
Tim dan beban kerja Anda hadir dalam model operasi organisasi Anda. Namun demikian, satu model operasi saja tentunya tidak cukup untuk mendukung semua tim dan beban kerja mereka. Oleh karena itu, tim Anda juga membutuhkan model operasinya sendiri. Cara kerja ini dibentuk oleh organisasi Anda, departemen Anda, susunan tim Anda, dan karakteristik beban kerja itu sendiri.
Sebagian besar organisasi yang berpindah ke cloud melakukannya sebagai bagian dari program transformasi perusahaan yang berupaya untuk membuka cara kerja baru (model operasi) untuk mendukung tujuan strategis jangka panjang. Perjalanan ini bukanlah sebuah titik dalam lini masa latihan, tetapi merupakan sebuah proses yang membutuhkan evolusi berkelanjutan dan kemajuan bertahap menuju tujuan strategis. Hal ini akan memungkinkan pemilik beban kerja untuk terus beradaptasi dengan model operasi yang berkembang dengan hanya mengalami sedikit gangguan.
Amazon sering digunakan sebagai contoh bagaimana organisasi besar mampu berinovasi dalam skala besar dengan memberdayakan tim untuk tetap dekat dengan pelanggan, meluncurkan produk dan layanan inovatif dengan cepat, dan memanfaatkan arsitektur teknis yang mendukung kecepatan dan kelincahan. Ini mengharuskan kami untuk merestrukturisasi bagaimana tim kami diatur, dan sekarang dikenal sebagai *tim dua pizza*. Tim dua pizza memiliki semua sumber daya yang tepat yang tertanam di dalamnya (teknik, pengujian, manajemen produk dan program, dan operasi) untuk memiliki dan menjalankan beban kerja secara menyeluruh (end-to-end).
Kami menyarankan Anda untuk berupaya mewujudkan model operasi ini sebagai cara yang terbukti bagi tim beban kerja untuk bisa bergerak dengan cepat dan berkontribusi pada hasil bisnis secara keseluruhan dengan cara yang paling baik dalam melayani pelanggan mereka.
Organisasi-organisasi yang ingin meniru keberhasilan ini mungkin perlu menyesuaikan model operasi mereka di sepanjang perjalanan transformasi mereka. Di tingkat organisasi dan tim, hal ini membutuhkan pertimbangan, perencanaan, dan komunikasi. Bagian berikut menyediakan cara yang bisa dilakukan untuk memvisualisasikan model operasi tingkat tim ini dan bagaimana mengembangkannya dengan prinsip *Anda membangunnya, Anda menjalankannya*.
# Representasi model operasi 2 per 2
Representasi model operasi 2 per 2 merupakan ilustrasi untuk membantu Anda memahami hubungan antar-tim dalam lingkungan. Diagram ini berfokus pada tindakan dan pelaksananya serta hubungan antar-tim, selain itu kami juga akan mendiskusikan tata kelola dan pembuatan keputusan yang berkaitan dengan contoh ini.
Tim Anda dapat memiliki tanggung jawab dalam berbagai model bergantung pada beban kerja yang mereka dukung. Anda mungkin ingin mencoba area disiplin yang lebih terspesialisasi daripada yang dijelaskan. Variasi model ini dapat menjadi tak terbatas seiring Anda memisahkan atau menggabungkan aktivitas, atau menyebarkan tim dan memberikan detail spesifik.
Anda dapat mengidentifikasi bahwa Anda memiliki kemampuan yang tumpang tindih atau tidak diketahui untuk seluruh tim, yang dapat memberikan keuntungan tambahan, atau mendorong efisiensi. Anda juga dapat mengidentifikasi kebutuhan yang belum terpenuhi dalam organisasi dan dapat merencanakan penanganannya.
Saat mengevaluasi perubahan organisasi, pelajari kompensasi antara model, posisi tim individu Anda dalam model (sekarang dan setelah perubahan), bagaimana hubungan dan kemampuan tim akan berubah, dan apakah manfaat sesuai dengan dampak pada organisasi.
Anda bisa sukses menggunakan masing-masing dari empat model operasi berikut. Beberapa model lebih sesuai untuk kasus penggunaan tertentu atau pada titik tertentu dalam pengembangan. Beberapa model dapat memberikan manfaat lebih dari model yang digunakan dalam lingkungan.
**Topics**
+ [Model operasi yang terpisah sepenuhnya](fully-separated-operating-model.md)
+ [DevOps dengan penyedia layanan terkelola cloud](devops-with-cloud-managed-service-provider.md)
+ [Operasi cloud dan pemberdayaan platform (COPE)](cloud-operations-and-platform-enablement.md)
+ [DevOps Terdistribusi](distributed-devops.md)
+ [DevOps Terdesentralisasi](decentralized-devops.md)
+ [Mengembangkan model operasi Anda](evolving-your-ops-model.md)
# Model operasi yang terpisah sepenuhnya
Dalam diagram berikut, Aplikasi dan Infrastruktur berada pada sumbu vertikal. Aplikasi merujuk pada beban kerja yang digunakan dalam hasil bisnis dan dapat dikembangkan secara kustom atau perangkat lunak yang dibeli. Platform merujuk pada infrastruktur fisik serta virtual dan perangkat lunak lainnya yang mendukung beban kerja tersebut.
Rekayasa dan Operasi berada pada sumbu horizontal. Rekayasa merujuk pada pengembangan, pembangunan, dan pengujian aplikasi serta infrastruktur. Operasi adalah deployment, pembaruan, dan dukungan yang masih berlangsung untuk aplikasi dan infrastruktur.
![\[Diagram model tradisional\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png)
Secara historis, organisasi-organisasi biasanya menganut kerangka kerja seperti ITIL atau standar seperti ISO dan membentuk kegiatan operasional mereka sesuai standar-standar itu, yang sering kali menghasilkan topologi yang sepenuhnya terpisah. Dalam model ini, aktivitas dalam setiap kuadran dilakukan oleh tim yang berbeda. Pekerjaan diteruskan antar tim melalui mekanisme seperti permintaan pekerjaan, antrean, tiket, atau dengan menggunakan sistem manajemen layanan IT (ITSM).
Transisi tugas kepada atau antar-tim dapat meningkatkan kompleksitas, serta menyebabkan bottleneck dan penundaan. Permintaan mungkin ditunda hingga menjadi prioritas. Kecacatan yang terlambat diidentifikasi dapat memerlukan banyak upaya untuk pengerjaan ulang dan mungkin harus melewati tim yang sama beserta fungsinya satu kali lagi. Jika ada insiden yang memerlukan tindakan tim rekayasawan, respons mereka akan ditunda oleh aktivitas transfer.
Ada risiko ketidaksesuaian yang lebih tinggi saat bisnis, pengembangan, dan tim operasi dikelola di sekitar aktivitas atau fungsi yang sedang dijalankan. Hal ini dapat membuat tim berfokus pada tanggung jawab spesifik mereka, bukan pada mencapai hasil bisnis. Tim dapat terspesialisasi secara sempit, terisolasi secara fisik, atau terisolasi secara logis, menghambat komunikasi dan kolaborasi.
# DevOps dengan penyedia layanan terkelola cloud
DevOps dengan model penyedia layanan yang dikelola cloud akan mengikuti metodologi *Anda membangunnya, Anda menjalankannya* untuk tim aplikasi. Namun demikian, organisasi Anda mungkin belum memiliki keterampilan, atau anggota tim, untuk mendukung rekayasa platform khusus dan tim operasi, atau Anda mungkin tidak ada dalam posisi ingin meluangkan waktu dan tenaga untuk melakukannya.
Jika tidak, Anda mungkin ingin memiliki tim platform yang berkonsentrasi pada pengembangan kemampuan yang akan memberikan bisnis Anda diferensiasi, tetapi Anda ingin melakukan outsourcing pada operasi harian yang tidak mendatangkan keuntungan kompetitif dan diferensiasi.
Penyedia Layanan Terkelola seperti [AWS Managed Services](https://aws.amazon.com/managed-services/), atau Penyedia [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider), menyediakan keahlian untuk mengimplementasikan lingkungan cloud, dan mendukung persyaratan keamanan dan kepatuhan serta tujuan bisnis Anda.
![\[DevOps dengan penyedia layanan terkelola cloud\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png)
Untuk variasi ini, kami akan menetapkan agar tata kelola dipusatkan dan dikelola oleh tim platform, dengan pembuatan akun dan kebijakan yang dikelola dengan AWS Organizations dan AWS Control Tower.
Dalam model ini, mekanisme harus diubah agar dapat dijalankan dengan penyedia layanan tersebut. Hal ini tidak mengatasi bottleneck dan penundaan yang disebabkan oleh transisi tugas antar-tim, termasuk penyedia layanan, atau kemungkinan pengerjaan ulang terkait dengan keterlambatan identifikasi kecacatan.
Anda mendapatkan manfaat dari standar penyedia, praktik terbaik, proses, dan keahlian. Anda juga mendapatkan manfaat dari pengembangan berkelanjutan penawaran layanan.
Menambahkan layanan terkelola ke model operasi Anda dapat menghemat waktu dan sumber daya Anda, serta memungkinkan Anda menjaga tim internal Anda untuk tetap belajar dan fokus pada hasil strategis yang akan membedakan bisnis Anda, dan bukan mengembangkan keterampilan dan kemampuan baru. Hal ini juga dapat memberikan waktu bagi Anda untuk membangun dan mematangkan kemampuan platform Anda sendiri tanpa memperlambat program migrasi cloud Anda.
# Operasi cloud dan pemberdayaan platform (COPE)
Model cloud operations and platform enablement (COPE) ini berupaya membangun metodologi *Anda membangunnya, Anda menjalankannya* dengan mendukung tim aplikasi untuk melakukan aktivitas rekayasa dan operasi untuk beban kerja mereka, mengadopsi budaya DevOps.
Tim aplikasi Anda mungkin bertugas untuk melakukan migrasi, mengadopsi cloud, atau melakukan modernisasi beban kerja, dan tidak memiliki kemampuan yang ada untuk mendukung arsitektur cloud serta operasi cloud secara memadai. Kurangnya kemampuan tim aplikasi dan keakraban ini cenderung akan memperlambat kelincahan organisasi Anda dan berdampak pada hasil bisnis.
Untuk mengatasi masalah ini, Anda dapat menggunakan keahlian operasional yang ada dari dalam organisasi Anda untuk mendukung tim aplikasi yang sedang berproses mengadopsi operasi cloud. Ini dapat berupa tim ahli tim virtual khusus yang di beranggotakan peserta-peserta pilihan dari seluruh organisasi. Namun demikian, tujuannya tetap sama, yaitu memberikan dukungan operasional yang membangun kemampuan tim beban kerja, menggunakan prinsip otomatisasi cloud first, menghilangkan upaya-upaya yang menuntut tetapi tidak memberikan diferensiasi, menyediakan pola standar, dan mempromosikan otonomi. Tujuannya adalah untuk membangun kematangan yang cukup di seluruh kemampuan cloud dan menurunkan hambatan tanggung jawab operasional sehingga tim aplikasi tidak lagi membutuhkan dukungan tambahan.
Model COPE berkonsentrasi pada tingkat beban kerja. Jika pendekatan ini diperlukan di beberapa tim sekaligus, dan jika Anda melakukan proyek migrasi multi-tahun yang kompleks dan dalam skala besar, atau jika Anda sedang membangun platform untuk mendukung inisiatif ini, Anda harus mempertimbangkan untuk menggunakan Pusat Keunggulan Cloud (CCoE). Ini adalah sebuah mekanisme yang banyak ditemukan berhasil ketika dilakukan dalam upaya untuk mempercepat migrasi mereka ke cloud dan secara luas mengubah organisasi mereka.
![\[Operasi Cloud dan Pemberdayaan Platform (COPE)\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png)
Tim rekayasa platform Anda membangun lapisan tipis kemampuan platform bersama inti, yang didasarkan pada standar yang telah ditentukan sebelumnya yang harus diadopsi oleh tim aplikasi dan disediakan oleh tim COPE. Tim rekayasa platform mengodekan arsitektur referensi dan pola yang disediakan untuk tim aplikasi melalui mekanisme layanan mandiri. Dengan menggunakan layanan seperti AWS Service Catalog, tim aplikasi dapat melakukan deployment arsitektur referensi, pola, layanan, dan konfigurasi yang disetujui, serta secara default mematuhi tata kelola terpusat dan standar keamanan.
Tim rekayasa platform juga menyediakan set layanan yang terstandardisasi (misalnya, alat pengembangan, alat observabilitas, alat pencadangan dan pemulihan, serta jaringan) kepada tim aplikasi.
Tim COPE mengelola dan mendukung layanan-layanan terstandardisasi dan memberikan bantuan kepada tim aplikasi yang membangun kehadiran cloud mereka berdasarkan arsitektur dan pola yang dijadikan referensi. Tim COPE bekerja dengan tim aplikasi untuk membantu mereka membangun operasi dasar. Selama proses ini, tim aplikasi akan mengemban tanggung jawab yang semakin besar atas sistem dan sumber daya mereka dari waktu ke waktu. Tim COPE mendorong peningkatan berkelanjutan bersama dengan tim rekayasa platform serta bertindak sebagai pendukung untuk tim aplikasi.
Tim aplikasi mendapatkan bantuan dalam menyiapkan lingkungan, pipeline CI/CD, manajemen perubahan, observabilitas dan pemantauan, serta menetapkan insiden dan proses manajemen peristiwa dengan tim COPE yang terintegrasi sebagaimana yang diperlukan. Tim COPE bekerja sama dengan tim aplikasi dalam menjalankan aktivitas operasi ini, menghapus keterlibatan tim COPE dari waktu ke waktu saat tim aplikasi mengambil alih kepemilikan.
Tim aplikasi memperoleh manfaat dari keterampilan tim COPE dan pelajaran yang dipetik oleh organisasi. Mereka dilindungi oleh pagar pembatas yang didirikan melalui tata kelola tersentralisasi. Tim aplikasi melakukan pembangunan berdasarkan kesuksesan yang diakui dan mendapatkan manfaat dari pengembangan berkelanjutan dari standar organisasi yang telah diadopsi. Mereka mendapatkan wawasan ke operasi beban kerja melalui proses penetapan observabilitas dan pemantauan dan dapat memahami dampak perubahan yang dibuat untuk beban kerja dengan lebih baik.
Tim COPE juga dapat mempertahankan akses yang diperlukan untuk mendukung aktivitas operasi, memberikan tampilan operasi perusahaan yang mencakup tim aplikasi, dan untuk menyediakan dukungan manajemen insiden yang sangat penting. Tim COPE mempertahankan tanggung jawab untuk aktivitas yang dianggap sebagai pekerjaan berat yang tidak mendatangkan keuntungan kompetitif, yang mereka penuhi melalui solusi standar yang dapat didukung dalam skala besar. Mereka juga terus mengelola aktivitas operasi terprogram dan otomatis yang dipahami dengan baik untuk tim aplikasi sehingga mereka dapat fokus menjadikan aplikasi mereka kompetitif.
Anda mendapatkan keuntungan dari standar, praktik terbaik, proses, dan keahlian organisasi yang diperoleh dari keberhasilan tim Anda. Anda menetapkan mekanisme untuk mereplikasi pola yang berhasil ini untuk tim baru yang melakukan adopsi atau modernisasi di cloud. Model ini menekankan pada kemampuan tim COPE untuk membantu penetapan tim aplikasi, serta mentransisikan pengetahuan dan artefak. Hal ini akan mengurangi beban operasional tim aplikasi dengan risiko bahwa tim aplikasi bisa gagal menjadi independen secara umum. Hal ini juga akan membangun hubungan antara CCoE, COPE, dan tim aplikasi dalam membuat loop umpan balik guna mendukung perkembangan dan inovasi lebih lanjut.
Menetapkan tim rekayasa platform dan COPE, sekaligus menentukan standar di seluruh organisasi, dapat memfasilitasi adopsi cloud dan mendukung upaya modernisasi yang dilakukan. Dengan memberikan dukungan tambahan dari tim COPE yang bertindak sebagai konsultan dan mitra untuk tim aplikasi, Anda dapat menghilangkan hambatan tingkat beban kerja yang memperlambat adopsi tim aplikasi dari kemampuan cloud yang bermanfaat.
# DevOps Terdistribusi
Model DevOps terdistribusi memisahkan (atau mendistribusikan) operasi rekayasa aplikasi dan tanggung jawab operasi rekayasa infrastruktur di seluruh tim teknik, mengikuti [metodologi COPE](cloud-operations-and-platform-enablement.md).
Rekayasawan aplikasi Anda melakukan rekayasa dan operasi beban kerja mereka. Dengan cara yang sama, rekayasawan infrastruktur melakukan rekayasa dan operasi pada platform yang digunakan untuk mendukung tim aplikasi.
![\[Diagram model DevOps terdistribusi\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png)
Untuk contoh ini, kami memperlakukan tata kelola sebagai tata kelola terpusat di tempat lain dalam organisasi. Standar sudah didistribusikan, disediakan, atau dibagikan kepada tim aplikasi.
Gunakan alat atau layanan yang memungkinkan Anda mengelola lingkungan di seluruh akun Anda secara tersentralisasi, seperti [AWS Organizations](https://aws.amazon.com/organizations/). Layanan seperti [AWS Control Tower](https://aws.amazon.com/controltower/features/) akan memperluas kemampuan manajemen ini dengan membantu Anda menentukan cetak biru (yang mendukung model operasi Anda) untuk penyiapan akun, menerapkan tata kelola berkelanjutan menggunakan AWS Organizations, dan mengotomatiskan penyediaan akun baru.
*You build it you run it* bukan berarti tim aplikasi bertanggung jawab atas tumpukan penuh (full-stack), tool chain, dan platform.
Tim rekayasawan platform menyediakan set layanan yang terstandardisasi (misalnya, alat pengembangan, alat pemantauan, alat pencadangan dan pemulihan, serta jaringan) kepada tim aplikasi. Tim platform juga dapat menyediakan ke layanan penyedia cloud yang disetujui, konfigurasi tertentu, atau keduanya, kepada tim aplikasi.
Mekanisme yang menyediakan kemampuan mandiri untuk men-deploy layanan dan konfigurasi yang disetujui, seperti Service Catalog, dapat membantu membatasi penundaan yang terkait dengan permintaan pemenuhan, dan sekaligus menegakkan tata kelola.
Tim platform mengaktifkan visibilitas tumpukan penuh (full stack) agar tim aplikasi dapat membedakan antara masalah dengan komponen aplikasi dan layanan serta komponen infrastruktur yang digunakan aplikasi. Tim platform juga dapat menyediakan bantuan untuk mengonfigurasi layanan ini dan panduan tentang cara meningkatkan operasi sebuah tim aplikasi.
Seperti yang didiskusikan sebelumnya, tersedianya mekanisme sangat penting untuk meminta penambahan, perubahan, dan pengecualian terhadap standar guna mendukung aktivitas dan inovasi aplikasi.
Model DevOps terdistribusi memberikan loop umpan balik yang kuat kepada tim aplikasi. Operasi harian beban kerja meningkatkan kontak dengan pelanggan, baik melalui interaksi langsung atau tidak langsung lewat permintaan fitur dan dukungan. Visibilitas yang lebih tinggi ini memungkinkan tim aplikasi untuk menangani masalah dengan cepat. Keterlibatan yang mendalam dan hubungan yang lebih dekat memberikan wawasan atas kebutuhan pelanggan dan menciptakan inovasi yang lebih cepat.
Semua ini juga berlaku untuk tim platform yang mendukung tim aplikasi, karena tim platform harus melihat tim aplikasi ini sebagai pelanggan mereka.
Standar yang diadopsi mungkin belum disetujui untuk penggunaan, mengurangi jumlah peninjauan yang diperlukan untuk memasuki produksi. Menggunakan standar yang didukung dan diuji serta disediakan oleh tim platform dapat mengurangi frekuensi masalah dengan layanan tersebut. Pengadopsian standar akan membantu tim aplikasi untuk fokus menjadikan beban kerja mereka kompetitif.
# DevOps Terdesentralisasi
Model DevOps terdesentralisasi adalah variasi dari metodologi *Anda membangunnya, Anda menjalankannya* di mana operasi sebagian besar berada di bawah kepemilikan tim beban kerja.
Rekayasawan aplikasi Anda melakukan rekayasa dan operasi-operasi beban kerja mereka. Dengan cara yang sama, rekayasawan infrastruktur melakukan rekayasa dan operasi-operasi pada platform yang digunakan untuk mendukung tim aplikasi.
![\[Diagram DevOps terdesentralisasi\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png)
Untuk contoh ini, kami membuat tata kelola menjadi terdesentralisasi. Standar masih didistribusikan, disediakan, atau dibagikan kepada tim aplikasi oleh tim platform, tetapi tim aplikasi bebas untuk merekayasa dan mengoperasikan kemampuan platform baru guna mendukung beban kerja.
Dalam model ini, tim aplikasi mengalami lebih sedikit kendala, tetapi hal itu disertai dengan peningkatan tanggung jawab yang signifikan. Keterampilan tambahan (dan anggota tim potensial) harus ada untuk mendukung kemampuan platform tambahan. Risiko pengerjaan ulang yang signifikan akan meningkat jika keahlian tidak memadai dan kecacatan tidak teridentifikasi lebih awal.
Terapkan kebijakan yang tidak didelegasikan secara khusus ke tim aplikasi. Gunakan alat atau layanan yang memungkinkan Anda untuk mengelola lingkungan di seluruh akun Anda secara tersentralisasi, seperti [AWS Organizations](https://aws.amazon.com/organizations/). Layanan seperti [AWS Control Tower](https://aws.amazon.com/controltower/features/) akan memperluas kemampuan manajemen ini dengan membantu Anda menentukan cetak biru (yang mendukung model operasi Anda) untuk penyiapan akun, menerapkan tata kelola berkelanjutan menggunakan AWS Organizations, dan mengotomatiskan penyediaan akun baru.
Tim aplikasi akan diuntungkan dengan memiliki mekanisme untuk meminta penambahan dan perubahan standar. Mereka dapat memberikan kontribusi berupa standar baru yang dapat memberikan manfaat bagi tim aplikasi lain. Tim platform dapat memutuskan bahwa memberikan dukungan langsung untuk kemampuan tambahan ini merupakan dukungan yang efektif untuk hasil bisnis.
Model ini meminimalkan kendala inovasi dengan keterampilan yang signifikan dan persyaratan anggota tim. Ini mengatasi banyak hambatan dan penundaan yang disebabkan oleh transisi tugas antar tim sambil tetap mempromosikan pengembangan hubungan yang efektif antara tim dan pelanggan.
# Mengembangkan model operasi Anda
Model-model yang disediakan secara progresif terus bergerak menuju semakin banyaknya otonomi yang dimilikinya pada tingkat beban kerja, sesuai dengan prinsip tim dua pizza. Anda harus memahami bahwa perjalanan ini adalah perjalanan dari pendekatan tradisional ke pendekatan DevOps terdesentralisasi (sebagai dasar untuk evolusi berkelanjutan ke model tim dua pizza), dan ini kemungkinan akan memakan waktu dan membutuhkan kematangan pembangunan di sejumlah kemampuan. Oleh karena itu, kami telah memberikan contoh bagaimana Anda dapat bertransisi antar model saat tim dan organisasi Anda bergerak di sepanjang perjalanan transformasi perusahaan. Dalam setiap perubahan atau model, Anda berkembang menuju tim yang lebih otonom, tetapi masih selaras secara organisasi.
![\[Diagram evolusi model operasi cloud dari on-premise hingga aliran dan proses nilai otomatis\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)
Saat melakukan evaluasi tentang bagaimana tim Anda dapat mendukung evolusi organisasi, pelajari kompensasi antara model, posisi tim individu Anda dalam model (sekarang dan setelah evolusi), bagaimana hubungan dan kemampuan tim akan berubah, dan apakah manfaat-manfaat yang didapatkan sesuai dengan dampak pada organisasi. Perlu diingat bahwa perubahan tidak pernah linier. Beberapa model lebih sesuai untuk kasus penggunaan atau titik tertentu dalam perjalanan, dan beberapa model ini mungkin memberikan keunggulan dibandingkan dengan yang ada di lingkungan Anda.
# Hubungan dan kepemilikan
Model operasi menentukan hubungan antar-tim dan mendukung kepemilikan serta tanggung jawab yang dapat diidentifikasi.
**Topics**
+ [OPS02-BP01 Sumber daya telah mengidentifikasi pemilik](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 Aktivitas operasi memiliki pemilik teridentifikasi yang bertanggung jawab atas performanya](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 Mekanisme tersedia untuk mengelola tanggung jawab dan kepemilikan](ops_ops_model_def_responsibilities_ownership.md)
+ [OPS02-BP05 Mekanisme tersedia untuk meminta penambahan, perubahan, dan pengecualian](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP06 Tanggung jawab antara tim telah dinegosiasikan atau ditetapkan sebelumnya](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 Sumber daya telah mengidentifikasi pemilik
Sumber daya untuk beban kerja Anda harus memiliki pemilik yang teridentifikasi untuk pengontrolan perubahan, penyelesaian masalah, dan fungsi-fungsi lainnya. Pemilik ditetapkan untuk beban kerja, akun, infrastruktur, platform, dan aplikasi. Kepemilikan dicatat menggunakan alat seperti daftar sentral atau metadata yang dilampirkan ke sumber daya. Nilai bisnis komponen menginformasikan proses dan prosedur yang diterapkan kepadanya.
**Hasil yang diinginkan:**
+ Sumber daya telah mengidentifikasi pemilik dengan menggunakan metadata atau daftar sentral.
+ Anggota tim dapat mengidentifikasi siapa pemilik sumber daya.
+ Akun memiliki satu pemilik apabila mungkin.
**Anti-pola umum:**
+ Kontak alternatif untuk Akun AWS Anda tidak diisi.
+ Sumber daya tidak memiliki tag yang mengidentifikasi tim mana yang memilikinya.
+ Anda memiliki ITSM antrian tanpa pemetaan email.
+ Dua tim sama-sama merupakan pemilik bagian penting dari infrastruktur.
**Manfaat menjalankan praktik terbaik ini:**
+ Kontrol perubahan untuk sumber daya akan menjadi mudah dilakukan dengan ditetapkannya kepemilikan.
+ Anda dapat melibatkan pemilik yang benar ketika menyelesaikan masalah.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Tentukan pentingnya kepemilikan untuk kasus penggunaan sumber daya di lingkungan Anda. Kepemilikan dapat berarti siapa yang mengawasi perubahan pada sumber daya, yang mendukung sumber daya selama penyelesaian masalah, atau siapa yang bertanggung jawab terhadapnya secara finansial. Sebutkan dan catat pemilik untuk sumber daya, termasuk nama, informasi kontak, organisasi, serta tim.
**Contoh pelanggan**
AnyCompany Ritel mendefinisikan kepemilikan sebagai tim atau individu yang memiliki perubahan dan dukungan untuk sumber daya. Mereka memanfaatkan AWS Organizations untuk mengelola mereka Akun AWS. Kontak akun alternatif dikonfigurasi menggunakan kotak masuk grup. Setiap ITSM antrian memetakan ke alias email. Tag mengidentifikasi siapa yang memiliki AWS sumber daya. Untuk infrastruktur dan platform-platform lainnya, mereka memiliki halaman wiki yang mengidentifikasi kepemilikan dan informasi kontak.
### Langkah-langkah implementasi
1. Mulai dengan menentukan kepemilikan untuk organisasi Anda. Kepemilikan dapat menyiratkan siapa yang memiliki risiko untuk sumber daya, siapa yang memiliki perubahan pada sumber daya, atau siapa yang mendukung sumber daya ketika melakukan penyelesaian masalah. Kepemilikan juga dapat menyiratkan kepemilikan sumber daya secara finansial atau administratif.
1. Gunakan [AWS Organizations](https://aws.amazon.com/organizations/) untuk mengelola akun. Anda dapat mengelola kontak alternatif untuk akun Anda secara terpusat.
1. Penggunaan alamat email dan nomor telepon milik perusahaan untuk informasi kontak akan membantu Anda untuk mengaksesnya meskipun orang yang memilikinya sudah tidak bekerja di organisasi Anda. Misalnya, buatlah daftar distribusi email terpisah untuk penagihan, operasional, dan keamanan lalu konfigurasikan ketiganya sebagai kontak Penagihan, Keamanan, dan Operasional di masing-masing Akun AWS yang aktif. Beberapa orang akan menerima AWS pemberitahuan dan dapat merespons, bahkan jika seseorang sedang berlibur, mengubah peran, atau meninggalkan perusahaan.
1. Jika akun tidak dikelola oleh [AWS Organizations](https://aws.amazon.com/organizations/), kontak akun alternatif dapat membantu AWS menghubungi personel yang tepat jika diperlukan. Konfigurasikan kontak alternatif akun sehingga menunjuk ke sebuah grup, bukan ke individu perseorangan.
1. Gunakan tag untuk mengidentifikasi pemilik AWS sumber daya. Anda dapat menentukan pemilik maupun informasi kontak mereka dalam tag terpisah.
1. Anda dapat menggunakan aturan [AWS Config](https://aws.amazon.com/config/) untuk menegaskan bahwa sumber daya memiliki tag kepemilikan yang diperlukan.
1. Untuk panduan mendalam tentang cara membangun strategi pemberian tag untuk organisasi Anda, silakan lihat [laporan resmi mengenai Praktik Terbaik Pemberian Tag AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
1. Gunakan [Amazon Q Business](https://aws.amazon.com/q/business/), sebuah asisten percakapan yang menggunakan AI generatif untuk meningkatkan produktivitas tenaga kerja, menjawab pertanyaan, dan menyelesaikan tugas berdasarkan informasi dalam sistem perusahaan Anda.
1. Hubungkan Amazon Q Business ke sumber data perusahaan Anda. Amazon Q Business menawarkan konektor bawaan ke lebih dari 40 sumber data yang didukung, termasuk Amazon Simple Storage Service (Amazon S3), SharePoint Microsoft, Salesforce, dan Atlassian Confluence. Untuk informasi selengkapnya, silakan lihat [Konektor Amazon Q](https://aws.amazon.com/q/business/connectors/).
1. Untuk sumber daya, platform, dan infrastruktur lainnya, buatlah dokumentasi yang mengidentifikasi kepemilikan. Dokumentasi ini harus dapat diakses oleh semua anggota tim.
**Tingkat upaya untuk rencana implementasi:** Rendah. Manfaatkan informasi kontak akun dan tag untuk menetapkan kepemilikan AWS sumber daya. Untuk sumber daya lain, Anda dapat menggunakan sesuatu yang sederhana seperti tabel di wiki untuk mencatat kepemilikan dan informasi kontak, atau menggunakan ITSM alat untuk memetakan kepemilikan.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [OPS02-BP02 Proses dan prosedur telah mengidentifikasi pemilik](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS02-BP04 Mekanisme ada untuk mengelola tanggung jawab dan kepemilikan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
**Dokumen terkait:**
+ [Manajemen Akun AWS - Memperbarui informasi kontak](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - Memperbarui kontak alternatif di organisasi Anda](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [Laporan resmi Praktik Terbaik Pemberian Tag AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Bangun aplikasi AI generatif perusahaan pribadi dan aman dengan Amazon Q Business and AWS IAM Identity Center](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [Amazon Q Business, sekarang tersedia secara umum dan dapat membantu Anda meningkatkan produktivitas tenaga kerja dengan AI generatif](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [AWS Cloud Blog Operasi & Migrasi - Menerapkan kontrol penandaan otomatis dan terpusat dengan dan AWS ConfigAWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Blog Keamanan - Perpanjang kait pra-komit Anda dengan AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Mengintegrasikan AWS CloudFormation Guard ke dalam pipa CI/CD](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**Lokakarya terkait:**
+ [Lokakarya - Pemberian Tag AWS](https://catalog.workshops.aws/tagging/)
**Contoh terkait:**
+ [Aturan AWS Config - Amazon EC2 dengan tag yang diperlukan dan nilai yang valid](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**Layanan terkait:**
+ [Aturan AWS Config - tag yang dibutuhkan](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi
Pahami siapa pemegang kepemilikan atas definisi dari masing-masing proses dan prosedur, alasan prosedur dan proses tertentu digunakan, serta alasan adanya kepemilikan tersebut. Dengan memahami alasan untuk menggunakan proses dan prosedur tertentu, peluang pengembangan dapat lebih mudah diidentifikasi.
**Hasil yang diinginkan:** Organisasi Anda memiliki serangkaian proses dan prosedur yang terdefinisi dengan baik dan terpelihara untuk tugas-tugas operasional. Proses dan prosedur-prosedur tersebut disimpan di lokasi terpusat dan tersedia untuk anggota tim Anda. Proses dan prosedur-prosedur sering diperbarui, dengan kepemilikan yang ditetapkan dengan jelas. Jika memungkinkan, skrip, templat, dan dokumen otomatisasi diimplementasikan sebagai kode.
**Anti-pola umum:**
+ Proses tidak didokumentasikan. Mungkin terdapat skrip yang terfragmentasi di stasiun kerja operator yang terisolasi.
+ Pengetahuan tentang cara menggunakan skrip dipegang oleh beberapa individu perorangan atau secara informal sebagai pengetahuan tim.
+ Proses warisan sudah harus diperbarui, tetapi kepemilikan pembaruan masih tidak jelas, dan penulis aslinya sudah bukan bagian dari organisasi.
+ Proses dan skrip tidak dapat ditemukan, sehingga tidak tersedia saat diperlukan (misalnya, dalam merespons sebuah insiden).
**Manfaat menjalankan praktik terbaik ini:**
+ Proses dan prosedur-prosedur akan meningkatkan upaya Anda untuk mengoperasikan beban kerja Anda.
+ Anggota tim baru menjadi lebih efektif dengan lebih cepat.
+ Mengurangi waktu mitigasi insiden.
+ Anggota tim (dan tim) yang berbeda dapat menggunakan proses dan prosedur yang sama secara konsisten.
+ Tim dapat menskalakan proses mereka dengan proses yang dapat diulang.
+ Proses dan prosedur standar membantu mengurangi dampak pengalihan tanggung jawab beban kerja antar-tim.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Proses dan prosedur-prosedur memiliki pemilik yang jelas untuk bertanggung jawab atas penetapannya.
+ Identifikasi aktivitas operasi yang dijalankan untuk mendukung beban kerja Anda. Buatlah dokumentasi dari aktivitas ini di lokasi yang mudah ditemukan.
+ Identifikasi secara khusus individu atau tim yang bertanggung jawab atas spesifikasi dari sebuah aktivitas. Mereka bertanggung jawab untuk memverifikasi bahwa aktivitas dapat dijalankan dengan sukses oleh anggota tim yang memiliki keterampilan memadai serta memiliki izin, akses, serta alat yang sesuai. Jika terdapat masalah saat menjalankan aktivitas tersebut, maka anggota tim yang menjalankannya bertanggung jawab untuk memberikan umpan balik mendetail yang diperlukan agar aktivitas tersebut dapat ditingkatkan.
+ Rekam kepemilikan dalam metadata artefak aktivitas melalui layanan seperti AWS Systems Manager, melalui dokumen, dan AWS Lambda. Rekam kepemilikan sumber daya menggunakan grup sumber daya atau tag, dengan menentukan informasi kontak dan kepemilikan. Gunakan AWS Organizations untuk membuat kebijakan penandaan dan merekam informasi kontak serta kepemilikan.
+ Seiring waktu, prosedur ini harus dikembangkan agar dapat dijalankan sebagai kode, sehingga mengurangi kebutuhan akan campur tangan manusia.
+ Misalnya, pertimbangkan fungsi AWS Lambda, templat CloudFormation, atau dokumen AWS Systems Manager Automation.
+ Jalankan kontrol versi di repositori yang sesuai.
+ Sertakan tanda sumber daya yang sesuai sehingga pemilik dan dokumentasi dapat diidentifikasi dengan mudah.
**Contoh pelanggan**
AnyCompany Retail mendefinisikan kepemilikan sebagai tim atau individu perseorangan yang memiliki proses untuk suatu aplikasi atau kelompok aplikasi (yang memiliki teknologi dan praktik arsitektur yang sama). Awalnya, proses dan prosedur didokumentasikan dalam bentuk panduan langkah demi langkah di dalam sistem manajemen dokumen, yang dapat ditemukan menggunakan tag pada Akun AWS yang meng-host aplikasi dan di kelompok sumber daya tertentu yang ada di dalam akun. Mereka memanfaatkan AWS Organizations untuk mengelola Akun AWS mereka. Seiring waktu, proses-proses tersebut dikonversi menjadi kode, dan sumber daya didefinisikan dengan menggunakan infrastruktur sebagai kode (seperti templat CloudFormation atau AWS Cloud Development Kit (AWS CDK)). Proses operasional menjadi dokumen otomatisasi di dalam AWS Systems Manager atau fungsi AWS Lambda, yang dapat diaktifkan sebagai tugas terjadwal, sebagai respons terhadap peristiwa-peristiwa seperti alarm CloudWatch AWS atau peristiwa AWS EventBridge, atau diaktifkan berdasarkan permintaan di dalam platform manajemen layanan TI (ITSM). Semua proses memiliki tanda untuk mengidentifikasi kepemilikan. Dokumentasi untuk otomatisasi dan proses dipertahankan di halaman wiki yang dihasilkan oleh repositori kode untuk proses tersebut.
### Langkah-langkah implementasi
1. Dokumentasikan proses dan prosedur yang ada.
1. Tinjau dan terus perbarui proses dan prosedur tersebut.
1. Identifikasi pemilik untuk setiap proses atau prosedur.
1. Tempatkan mereka di bawah kontrol versi.
1. Jika memungkinkan, bagikan proses dan prosedur-prosedur itu di seluruh beban kerja dan lingkungan yang berbagi desain arsitektur.
1. Buat mekanisme untuk umpan balik dan perbaikan.
1. Tentukan kebijakan untuk frekuensi peninjauan proses.
1. Tentukan proses untuk peninjau dan pemberi persetujuan.
1. Implementasikan permasalahan-permasalahan atau antrean tiket untuk umpan balik yang akan diberikan dan dilacak.
1. Jika memungkinkan, proses dan prosedur harus memiliki klasifikasi risiko dan persetujuan di awal dari dewan persetujuan perubahan (CAB).
1. Verifikasi bahwa proses dan prosedur dapat diakses dan ditemukan oleh orang-orang yang perlu menjalankannya.
1. Gunakan tanda untuk menunjukkan di mana proses dan prosedur dapat diakses untuk beban kerja.
1. Gunakan pesan kesalahan dan peristiwa yang dapat dipahami untuk menunjukkan proses atau prosedur yang sesuai untuk mengatasi sebuah permasalahan.
1. Gunakan wiki dan manajemen dokumen, dan jadikan proses dan prosedur dapat dicari secara konsisten di seluruh organisasi.
1. Gunakan [Amazon Q Business](https://aws.amazon.com/q/business/), sebuah asisten percakapan yang menggunakan AI generatif untuk meningkatkan produktivitas tenaga kerja, menjawab pertanyaan, dan menyelesaikan tugas berdasarkan informasi dalam sistem perusahaan Anda.
1. Hubungkan Amazon Q Business ke sumber data perusahaan Anda. Amazon Q Business menawarkan konektor-konektor bawaan ke lebih dari 40 sumber data yang didukung, termasuk Amazon S3, Microsoft SharePoint, Salesforce, dan Atlassian Confluence. Untuk informasi selengkapnya, silakan lihat [Konektor Amazon Q](https://aws.amazon.com/q/business/connectors/).
1. Lakukan otomatisasi jika perlu.
1. Otomatisasi harus dikembangkan ketika layanan dan teknologi menyediakan API.
1. Berikan edukasi secara memadai tentang proses. Kembangkan kisah dan persyaratan pengguna untuk mengotomatiskan proses-proses tersebut.
1. Ukur penggunaan proses dan prosedur Anda dengan sukses, dan laporkan masalah atau ajukan tiket untuk mendukung perbaikan berulang.
**Tingkat upaya untuk rencana implementasi:** Sedang
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [OPS02-BP01 Sumber daya memiliki pemilik teridentifikasi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 Mekanisme tersedia untuk mengelola tanggung jawab dan kepemilikan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS11-BP04 Menjalankan manajemen pengetahuan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Dokumen terkait:**
+ [AWS Laporan resmi - Pengantar DevOps di AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Laporan resmi AWS - Praktik Terbaik Penandaan Sumber Daya AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Laporan resmi AWS - Mengatur Lingkungan AWS Anda dengan Menggunakan Beberapa Akun](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Blog Operasi dan Migrasi AWS Cloud - Menggunakan Amazon Q Business untuk merampingkan operasi Anda ](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [AWS Cloud Blog Operasi & Migrasi - Membangun Praktik Otomatisasi Cloud untuk Keunggulan Operasional: Praktik Terbaik dari AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [Blog Operasi & Migrasi AWS Cloud - Menerapkan kontrol penandaan otomatis dan tersentralisasi dengan AWS Config dan AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [Blog Keamanan AWS - Perpanjang hook pra-commit Anda dengan AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [Blog DevOps AWS - Mengintegrasikan AWS CloudFormation Guard ke dalam pipeline CI/CD](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**Lokakarya terkait:**
+ [AWS Lokakarya Keunggulan Operasional Well-Architected](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [Lokakarya - Penandaan AWS](https://catalog.workshops.aws/tagging/)
**Video terkait:**
+ [Cara melakukan otomatisasi Operasi IT di AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS re:Invent 2020 - Melakukan otomatisasi atas apa pun dengan AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 - Melakukan otomatisasi manajemen dan kepatuhan patch dengan menggunakan AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [Dukungans You - Memahami Lebih Dalam AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
**Layanan terkait:**
+ [AWS Systems Manager - Otomatisasi](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 Aktivitas operasi memiliki pemilik teridentifikasi yang bertanggung jawab atas performanya
Pahami siapa yang bertanggung jawab untuk menjalankan aktivitas tertentu terhadap beban kerja yang ditentukan serta alasan adanya tanggung jawab tersebut. Memahami siapa yang bertanggung jawab untuk menjalankan aktivitas dapat memberikan informasi tentang siapa yang akan melakukan aktivitas tersebut, memvalidasi hasilnya, serta memberikan umpan balik kepada pemilik aktivitas.
**Hasil yang diinginkan:**
Organisasi Anda secara jelas menetapkan tanggung jawab untuk menjalankan aktivitas tertentu pada beban kerja yang ditentukan dan merespons peristiwa-peristiwa yang dihasilkan oleh beban kerja tersebut. Organisasi mendokumentasikan kepemilikan proses dan pemenuhan dan membuat informasi ini dapat ditemukan. Anda meninjau dan memperbarui tanggung jawab ketika ada perubahan yang terjadi pada organisasi, dan tim melacak serta mengukur performa aktivitas identifikasi kekurangan dan inefisiensi. Anda mengimplementasikan mekanisme umpan balik untuk melacak kekurangan dan perbaikan serta mendukung perbaikan berulang.
**Anti-pola umum:**
+ Anda tidak mendokumentasikan tanggung jawab.
+ Terdapat skrip yang terfragmentasi di stasiun kerja operator yang terisolasi. Hanya sedikit orang saja yang tahu cara menggunakannya atau secara informal menyebutnya sebagai *pengetahuan tim*.
+ Proses warisan sudah harus diperbarui, tetapi tidak ada yang tahu siapa yang memiliki proses tersebut, dan penulis aslinya sudah tidak lagi menjadi bagian dari organisasi.
+ Proses dan skrip tidak dapat ditemukan, dan tidak tersedia saat diperlukan (misalnya, saat merespons insiden).
**Manfaat menjalankan praktik terbaik ini:**
+ Anda memahami siapa yang bertanggung jawab untuk menjalankan sebuah aktivitas, siapa yang harus mendapatkan notifikasi saat diperlukan tindakan, dan siapa yang melakukan tindakan, memvalidasi hasilnya, serta memberikan umpan balik kepada pemilik aktivitas tersebut.
+ Proses dan prosedur-prosedur akan meningkatkan upaya Anda untuk mengoperasikan beban kerja Anda.
+ Anggota tim baru menjadi lebih efektif dengan lebih cepat.
+ Anda mengurangi waktu yang dibutuhkan untuk memitigasi insiden.
+ Tim yang berbeda menggunakan proses dan prosedur yang sama untuk melakukan tugas-tugas secara konsisten.
+ Tim dapat menskalakan proses mereka dengan proses yang dapat diulang.
+ Proses dan prosedur standar membantu memitigasi dampak pengalihan tanggung jawab beban kerja antar-tim.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Untuk mulai menentukan tanggung jawab, mulailah dengan dokumentasi yang sudah ada sekarang, seperti matriks tanggung jawab, proses dan prosedur, peran dan tanggung jawab, serta alat-alat dan otomatisasi. Tinjau dan lakukan diskusi mengenai tanggung jawab untuk proses yang terdokumentasi. Lakukan peninjauan bersama tim untuk mengidentifikasi ketidakselarasan antara tanggung jawab dokumen dan proses. Diskusikan layanan-layanan yang ditawarkan dengan pelanggan internal tim tersebut untuk mengidentifikasi perbedaan ekspektasi di antara tim.
Analisis dan atasi perbedaan. Identifikasi setiap peluang perbaikan, dan cari aktivitas padat sumber daya yang sering diminta, yang biasanya merupakan kandidat kuat untuk perbaikan. Jelajahi praktik terbaik, pola, dan panduan preskriptif untuk menyederhanakan dan melakukan standardisasi perbaikan. Dokumentasikan peluang-peluang perbaikan, dan lacak perbaikan hingga selesai.
Seiring waktu, prosedur-prosedur ini harus dikembangkan agar dapat dijalankan sebagai kode, sehingga akan mengurangi kebutuhan akan campur tangan manusia. Misalnya, prosedur-prosedur itu dapat dimulai dalam bentuk fungsi AWS Lambda, templat CloudFormation, atau dokumen Otomatisasi AWS Systems Manager. Pastikan bahwa semua prosedur ini memiliki kontrol versi di repositori yang sesuai, dan sertakan tag sumber daya yang sesuai sehingga tim dapat mengidentifikasi pemilik dan dokumentasi dengan mudah. Buatlah dokumentasi tanggung jawab untuk melaksanakan aktivitas, kemudian pantau otomatisasi untuk inisiasi dan operasi yang berhasil, serta kinerja hasil yang diinginkan.
**Contoh pelanggan**
AnyCompany Retail mendefinisikan kepemilikan sebagai tim atau individu perseorangan yang memiliki proses untuk suatu aplikasi atau kelompok aplikasi yang memiliki teknologi dan praktik arsitektur yang sama. Awalnya, perusahaan ini mendokumentasikan proses dan prosedur dalam bentuk panduan langkah demi langkah di dalam sistem manajemen dokumen. Mereka membuat prosedur tersebut dapat ditemukan dengan menggunakan tag pada Akun AWS yang meng-host aplikasi dan pada kelompok sumber daya tertentu di dalam akun, dengan menggunakan AWS Organizations untuk mengelola Akun AWS mereka. Seiring waktu, AnyCompany Retail mengonversi proses-proses tersebut menjadi kode dan mendefinisikan sumber daya dengan menggunakan infrastruktur sebagai kode (melalui layanan seperti CloudFormation atau templat AWS Cloud Development Kit (AWS CDK)). Proses operasional menjadi dokumen otomatisasi di dalam fungsi AWS System Manager atau fungsi AWS Lambda, yang dapat dimulai sebagai tugas terjadwal untuk merespons peristiwa seperti alarm Amazon CloudWatch atau peristiwa Amazon EventBridge, atau berdasarkan permintaan di dalam platform manajemen layanan IT (ITSM). Semua proses memiliki tag untuk mengidentifikasi pemiliknya. Tim mengelola dokumentasi untuk otomatisasi dan proses di dalam halaman wiki yang dihasilkan oleh repositori kode untuk proses tersebut.
### Langkah-langkah implementasi
1. Dokumentasikan proses dan prosedur yang ada.
1. Tinjau dan pastikan dokumentasi tersebut mutakhir.
1. Pastikan bahwa setiap proses atau prosedur mempunyai pemilik.
1. Tempatkan prosedur di bawah kontrol versi.
1. Jika memungkinkan, bagikan proses dan prosedur-prosedur itu di seluruh beban kerja dan lingkungan yang berbagi desain arsitektur.
1. Buat mekanisme untuk umpan balik dan perbaikan.
1. Tentukan kebijakan untuk frekuensi peninjauan proses.
1. Tentukan proses untuk peninjau dan pemberi persetujuan.
1. Implementasikan permasalahan-permasalahan atau antrean tiket untuk memberikan dan melacak umpan balik.
1. Jika memungkinkan, sediakan klasifikasi risiko dan persetujuan awal untuk proses dan prosedur dari dewan persetujuan perubahan (CAB).
1. Buat proses dan prosedur dapat diakses dan ditemukan oleh pengguna yang perlu menjalankannya.
1. Gunakan tanda untuk menunjukkan di mana proses dan prosedur dapat diakses untuk beban kerja.
1. Gunakan pesan kesalahan dan peristiwa yang dapat dipahami untuk menunjukkan proses atau prosedur yang sesuai untuk mengatasi masalah.
1. Gunakan wiki atau manajemen dokumen agar proses dan prosedur dapat dicari secara konsisten di seluruh organisasi.
1. Lakukan otomatisasi jika perlu.
1. Kembangkan otomatisasi ketika layanan dan teknologi menyediakan API.
1. Pastikan bahwa proses tersebut dapat dipahami dengan baik, dan kembangkan kisah serta persyaratan pengguna untuk mengotomatiskan proses tersebut.
1. Ukur penggunaan proses dan prosedur yang sukses, dengan pelacakan masalah untuk mendukung perbaikan berulang.
**Tingkat upaya untuk rencana implementasi:** Sedang
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [OPS02-BP01 Sumber daya memiliki pemilik teridentifikasi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 Mekanisme tersedia untuk mengelola tanggung jawab dan kepemilikan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS02-BP05 Mekanisme tersedia untuk mengidentifikasi tanggung jawab dan kepemilikan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_find_owner.html)
+ [OPS11-BP04 Menjalankan manajemen pengetahuan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Dokumen terkait:**
+ [Laporan Resmi AWS \$1 Pengantar DevOps di AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Laporan resmi AWS \$1 Praktik Terbaik Pemberian Tag Sumber Daya AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Laporan resmi AWS \$1 Mengatur Lingkungan AWS Anda dengan Menggunakan Beberapa Akun](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Blog Operasi & Migrasi AWS Cloud \$1 Membangun Praktik Otomatisasi Cloud untuk Keunggulan Operasional: Praktik Terbaik dari AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [Lokakarya - Pemberian Tag AWS](https://catalog.workshops.aws/tagging/)
+ [Konektor Manajemen Layanan AWS](https://aws.amazon.com/service-management-connector/)
**Video terkait:**
+ [Pusat Pengetahuan Langsung AWS \$1 Pemberian Tag pada Sumber Daya AWS](https://www.youtube.com/watch?v=MX9DaAQS15I)
+ [AWS re:Invent 2020 \$1 Melakukan otomatisasi atas apa pun dengan AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 \$1 Melakukan otomatisasi manajemen dan kepatuhan patch dengan menggunakan AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [AWS Dukungans You \$1 Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
# OPS02-BP04 Mekanisme tersedia untuk mengelola tanggung jawab dan kepemilikan
Pahami tanggung jawab yang dimiliki oleh peran Anda dan bagaimana Anda berkontribusi terhadap hasil bisnis, karena pemahaman ini akan mendasari penentuan prioritas tugas Anda dan mengapa peran Anda itu penting. Hal ini akan membantu anggota tim untuk mengenali kebutuhan dan merespons dengan tepat. Ketika anggota tim mengetahui peran mereka, mereka dapat membangun kepemilikan, mengidentifikasi peluang perbaikan, dan memahami cara untuk memengaruhi atau membuat perubahan yang sesuai.
Kadang-kadang, sebuah tanggung jawab mungkin tidak memiliki pemilik yang jelas. Dalam situasi seperti ini, rancang sebuah mekanisme untuk mengatasi kesenjangan ini. Buat jalur eskalasi yang ditentukan dengan baik kepada seseorang yang memiliki wewenang untuk menetapkan kepemilikan atau rencana untuk memenuhi kebutuhan tersebut.
**Hasil yang diinginkan:** Tim-tim yang ada dalam organisasi Anda memiliki tanggung jawab yang sudah ditentukan dengan jelas yang mencakup bagaimana kaitan mereka dengan sumber daya, tindakan yang harus dilakukan, proses, dan prosedur. Tanggung jawab ini selaras dengan tanggung jawab dan sasaran tim, serta tanggung jawab yang dimiliki tim lain. Anda mendokumentasikan rute eskalasi dengan cara yang konsisten dan dapat ditemukan dan memasukkan keputusan tersebut ke dalam artefak dokumentasi, misalnya matriks tanggung jawab, definisi tim, atau halaman wiki.
**Anti-pola umum:**
+ Tanggung jawab tim yang bersifat ambigu atau tidak ditentukan dengan baik.
+ Tim tidak menyelaraskan peran dengan tanggung jawab.
+ Tim tidak menyelaraskan tujuan dan sasarannya dengan tanggung jawabnya, sehingga kesuksesan menjadi sulit diukur.
+ Tanggung jawab anggota tim tidak selaras dengan tim dan organisasi yang lebih luas.
+ Tim Anda tidak memperbarui tanggung jawab mereka, sehingga tanggung jawab tidak konsisten dengan tugas yang dilakukan oleh tim.
+ Jalur eskalasi untuk menentukan tanggung jawab tidak ditetapkan atau tidak jelas.
+ Jalur eskalasi tidak memiliki pemilik utas tunggal untuk memastikan pemberian respons yang cepat.
+ Peran, tanggung jawab, dan jalur eskalasi tidak dapat ditemukan, dan tidak tersedia saat diperlukan (misalnya, saat merespons insiden).
**Manfaat menjalankan praktik terbaik ini:**
+ Ketika Anda memahami siapa yang memegang tanggung jawab atau kepemilikan, Anda dapat menghubungi tim atau anggota tim yang tepat untuk melakukan permintaan atau pengalihann tugas.
+ Untuk mengurangi risiko tidak adanya tindakan dan kebutuhan yang tidak tertangani, Anda telah mengidentifikasi seseorang yang memiliki wewenang untuk menetapkan tanggung jawab atau kepemilikan.
+ Ketika Anda mendefinisikan cakupan suatu tanggung jawab dengan jelas, anggota tim Anda mendapatkan otonomi dan kepemilikan.
+ Tanggung jawab Anda akan mendasari keputusan yang Anda ambil, tindakan yang akan Anda lakukan, dan penyerahan aktivitas Anda ke pemiliknya yang benar.
+ Tanggung jawab yang ditinggalkan dapat dengan mudah diidentifikasi karena Anda memiliki pemahaman yang jelas tentang hal-hal yang berada di luar tanggung jawab tim Anda, sehingga membantu Anda dalam melakukan eskalasi untuk meminta klarifikasi.
+ Tim menghindari kebingungan dan ketegangan, dan mereka dapat mengelola beban kerja serta sumber daya dengan lebih memadai.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Identifikasi peran dan tanggung jawab anggota tim, dan pastikan bahwa mereka memahami apa yang diharapkan dari peran mereka. Buat informasi ini dapat ditemukan sehingga anggota-anggota organisasi Anda dapat mengidentifikasi siapa yang perlu mereka hubungi saat ada kebutuhan khusus, baik berupa tim atau perorangan. Ketika organisasi berusaha memanfaatkan peluang untuk memigrasi dan memodernisasi AWS, peran dan tanggung jawab juga dapat berubah. Jaga agar tim Anda dan para anggotanya tetap menyadari tanggung jawab mereka, dan latih mereka dengan semestinya untuk melaksanakan tugas selama perubahan ini.
Tentukan peran atau tim yang harus menerima eskalasi untuk mengidentifikasi tanggung jawab dan kepemilikan. Tim ini dapat berinteraksi dengan berbagai pemangku kepentingan untuk mengambil suatu keputusan. Namun, mereka harus memiliki wewenang manajemen proses pengambilan keputusan.
Sediakan mekanisme yang dapat diakses bagi anggota organisasi untuk menemukan dan mengidentifikasi kepemilikan dan tanggung jawab. Mekanisme ini memberi tahu mereka siapa yang harus dihubungi saat ada kebutuhan khusus.
**Contoh pelanggan**
AnyCompany Retail baru-baru ini menyelesaikan migrasi beban kerja dari lingkungan on-premise ke zona landasan mereka di AWS dengan pendekatan angkat dan geser. Mereka melakukan peninjauan operasi untuk merenungkan cara mereka menyelesaikan tugas-tugas operasional umum dan memastikan bahwa matriks tanggung jawab mereka yang ada sekarang sudah sesuai dengan operasi yang ada di lingkungan baru. Ketika mereka bermigrasi dari on-premise ke AWS, mereka mengurangi tanggung jawab tim infrastruktur yang berkaitan dengan perangkat keras dan infrastruktur fisik. Langkah ini juga mengungkap adanya peluang baru untuk mengembangkan model operasi untuk beban kerja mereka.
Di saat mereka mengidentifikasi, menangani, dan mendokumentasikan sebagian besar tanggung jawab, mereka juga menetapkan rute eskalasi untuk tanggung jawab apa pun yang terlewatkan atau untuk tanggung jawab yang mungkin perlu diubah sesuai perkembangan praktik operasi. Untuk mengeksplorasi peluang-peluang baru untuk melakukan standardisasi dan meningkatkan efisiensi di seluruh beban kerja Anda, berikan akses ke alat-alat operasi seperti AWS Systems Manager dan alat-alat keamanan seperti AWS Security Hub CSPM dan Amazon GuardDuty. AnyCompany Retail menyusun sebuah tinjauan tanggung jawab dan strategi berdasarkan perbaikan yang ingin mereka tangani terlebih dahulu. Ketika perusahaan ini mengadopsi cara-cara kerja dan pola teknologi baru, mereka memperbarui matriks tanggung jawab mereka agar sesuai dengan itu semua.
### Langkah-langkah implementasi
1. Mulailah dengan dokumentasi yang sudah ada. Beberapa dokumen sumber yang umum antara lain:
1. Matriks pertanggungjawaban atau matriks bertanggung jawab, bisa dipertanggungjawabkan, dibuat dengan konsultasi, dan berdasarkan informasi (RACI)
1. Definisi tim atau halaman wiki
1. Definisi dan penawaran layanan
1. Deskripsi peran atau pekerjaan
1. Tinjau dan lakukan diskusi tentang tanggung jawab yang didokumentasikan:
1. Lakukan peninjauan bersama tim untuk mengidentifikasi ketidakselarasan yang terjadi antara tanggung jawab yang terdokumentasi dan tanggung jawab yang umumnya dijalankan oleh tim.
1. Diskusikan layanan-layanan potensial yang ditawarkan oleh pelanggan internal untuk mengidentifikasi adanya perbedaan ekspektasi di antara tim.
1. Lakukan analisis dan atasi perbedaan.
1. Identifikasi peluang perbaikan.
1. Identifikasi permintaan padat sumber daya yang sering kali mendapat permintaan, yang biasanya merupakan kandidat kuat untuk perbaikan.
1. Cari praktik terbaik, pahami pola, dan ikuti panduan preskriptif, serta lakukan penyederhanaan dan standardisasi perbaikan.
1. Dokumentasikan peluang-peluang perbaikan, dan lacak hingga perbaikan tersebut selesai.
1. Jika tim belum memiliki tanggung jawab untuk mengelola dan melacak penugasan tanggung jawab, identifikasi seseorang yang ada di dalam tim untuk memegang tanggung jawab ini.
1. Tentukan proses bagi tim untuk meminta klarifikasi tanggung jawab.
1. Tinjau prosesnya, dan pastikan bahwa proses tersebut jelas dan mudah digunakan.
1. Pastikan seseorang memiliki dan melacak proses eskalasi hingga selesai.
1. Buat metrik operasional untuk mengukur efektivitas.
1. Ciptakan sebuah mekanisme umpan balik untuk memastikan bahwa tim dapat menyoroti peluang-peluang perbaikan.
1. Implementasikan sebuah mekanisme untuk peninjauan berkala.
1. Buatlah dokumentasi di sebuah lokasi yang dapat ditemukan dan dapat diakses.
1. Wiki atau portal dokumentasi adalah pilihan umum.
**Tingkat upaya untuk rencana implementasi:** Sedang
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [OPS01-BP06 Mengevaluasi kompromi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS03-BP02 Anggota tim diberdayakan untuk bertindak ketika hasil dipertaruhkan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html)
+ [OPS03-BP03 Tim didorong untuk membawa masalah ke tingkat yang lebih tinggi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html)
+ [OPS03-BP07 Bekali tim dengan sumber daya dengan sesuai](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html)
+ [OPS09-BP01 Mengukur sasaran operasi dan KPI dengan metrik](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
+ [OPS09-BP03 Meninjau metrik-metrik operasi dan memprioritaskan perbaikan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS11-BP01 Buatlah suatu proses untuk peningkatan berkelanjutan](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**Dokumen terkait:**
+ [Laporan resmi AWS - Pengantar DevOps di AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Laporan Resmi AWS - Kerangka Kerja Adopsi AWS Cloud: Perspektif Operasi](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [Keunggulan Operasional Kerangka Kerja AWS Well-Architected - Topologi model operasi Tingkat beban kerja](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [Panduan Preskriptif AWS - Membangun Model Operasi Cloud Anda](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [Panduan Preskriptif AWS - Membuat matriks RACI atau RASCI untuk model operasi cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html)
+ [Blog Operasi & Migrasi AWS Cloud - Memberikan Nilai Bisnis dengan Tim Platform Cloud](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [Blog Operasi & Migrasi AWS Cloud - Mengapa Model Operasi Cloud?](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [DevOps Blog AWS - Bagaimana organisasi memodernisasi untuk operasi cloud](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/)
**Video terkait:**
+ [Summit Online AWS - Model Operasi Cloud untuk Transformasi yang Dipercepat](https://www.youtube.com/watch?v=ksJ5_UdYIag)
+ [ re:Invent 2023 AWS - Keamanan cloud yang tahan masa depan: Model operasi baru](https://www.youtube.com/watch?v=GFcKCz1VO2I)
# OPS02-BP05 Mekanisme tersedia untuk meminta penambahan, perubahan, dan pengecualian
Anda dapat mengajukan permintaan kepada pemilik proses, prosedur, dan sumber daya. Permintaan tersebut mencakup penambahan, perubahan, dan pengecualian. Permintaan ini diajukan melalui sebuah proses manajemen perubahan. Buatlah keputusan-keputusan yang matang berdasarkan informasi untuk menyetujui permintaan apabila memungkinkan dan dianggap tepat setelah dilakukan evaluasi manfaat dan risiko.
**Hasil yang diinginkan:**
+ Anda dapat mengajukan permintaan untuk mengubah proses, prosedur, dan sumber daya berdasarkan kepemilikan yang ditetapkan.
+ Perubahan harus dibuat dengan penuh pertimbangan, dengan memikirkan manfaat dan risikonya.
**Anti-pola umum:**
+ Anda harus memperbarui cara Anda melakukan deployment terhadap aplikasi Anda, tetapi perubahan proses deployment tidak dapat diminta dari tim operasi.
+ Rencana pemulihan bencana harus diperbarui, tetapi tidak ada pemilik yang diidentifikasi untuk dapat dimintai perubahan.
**Manfaat menjalankan praktik terbaik ini:**
+ Proses, prosedur, dan sumber daya dapat berubah seiring dengan terjadinya perubahan persyaratan.
+ Pemilik dapat mengambil keputusan yang matang berdasarkan informasi ketika harus membuat perubahan.
+ Perubahan harus dibuat dengan cara yang penuh pertimbangan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Untuk mengimplementasikan praktik terbaik ini, Anda harus dapat membuat permintaan perubahan proses, prosedur, dan sumber daya. Proses manajemen perubahan bisa jadi hal yang ringan. Buatlah dokumentasi proses manajemen perubahan.
**Contoh pelanggan**
AnyCompany Retail menggunakan sebuah matriks penetapan tanggung jawab (RACI) untuk mengidentifikasi siapa yang memiliki perubahan untuk proses, prosedur, dan sumber daya. Mereka memiliki proses manajemen perubahan terdokumentasi yang ringan dan mudah diikuti. Menggunakan matriks RACI dan proses, siapa pun dapat menyampaikan permintaan perubahan.
**Langkah-langkah implementasi**
1. Identifikasi proses, prosedur, dan sumber daya untuk beban kerja Anda dan pemilik untuk masing-masing. Buatlah dokumentasi tentang itu semua dalam sistem manajemen pengetahuan Anda.
1. Jika Anda belum menerapkan [OPS02-BP01 Sumber daya telah mengidentifikasi pemilik](ops_ops_model_def_resource_owners.md), [OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi](ops_ops_model_def_proc_owners.md), atau [OPS02-BP03 Aktivitas operasi memiliki pemilik teridentifikasi yang bertanggung jawab atas performanya](ops_ops_model_def_activity_owners.md), mulailah dengan yang pertama.
1. Bekerjasamalah dengan para pemangku kepentingan yang ada di organisasi Anda untuk mengembangkan sebuah proses manajemen perubahan. Proses tersebut harus meliputi penambahan, perubahan, dan pengecualian untuk sumber daya, proses, dan prosedur.
1. Anda dapat menggunakan [Manajer Perubahan AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) sebagai sebuah platform manajemen perubahan untuk sumber daya beban kerja.
1. Buatlah dokumentasi proses manajemen perubahan dalam sistem manajemen pengetahuan Anda.
**Tingkat upaya untuk rencana implementasi:** Sedang. Mengembangkan sebuah proses manajemen perubahan memerlukan penyelarasan dengan banyak pemangku kepentingan yang ada di seluruh organisasi Anda.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [OPS02-BP01 Sumber daya telah mengidentifikasi pemilik](ops_ops_model_def_resource_owners.md) - Sumber daya membutuhkan pemilik yang teridentifikasi sebelum Anda membangun sebuah proses manajemen perubahan.
+ [OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi](ops_ops_model_def_proc_owners.md) - Proses membutuhkan pemilik yang teridentifikasi sebelum Anda membangun sebuah proses manajemen perubahan.
+ [OPS02-BP03 Aktivitas operasi memiliki pemilik teridentifikasi yang bertanggung jawab atas performanya](ops_ops_model_def_activity_owners.md) - Kegiatan Operasi membutuhkan pemilik yang teridentifikasi sebelum Anda membangun sebuah proses manajemen perubahan.
**Dokumen terkait:**
+ [ Panduan Preskriptif AWS - Playbook landasan dasar untuk migrasi besar AWS: Membuat matriks RACI](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [ Manajemen Perubahan dalam Laporan Resmi Cloud](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**Layanan terkait:**
+ [Manajer Perubahan AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
# OPS02-BP06 Tanggung jawab antara tim telah dinegosiasikan atau ditetapkan sebelumnya
Miliki perjanjian yang telah ditetapkan atau dinegosiasikan antara tim yang menjelaskan bagaimana mereka akan bekerja sama dan saling mendukung satu sama lain (contohnya, waktu respons, tujuan tingkat layanan, atau perjanjian tingkat layanan). Saluran komunikasi antar-tim didokumentasikan. Memahami dampak dari pekerjaan tim terhadap hasil bisnis, dan hasil dari tim dan organisasi yang lain akan membuat Anda tahu tentang penentuan prioritas tugas mereka dan membantu mereka merespons dengan tepat.
Ketika ada tanggung jawab dan kepemilikan yang tidak ditetapkan atau tidak diketahui, maka Anda akan menanggung risiko tidak menangani aktivitas yang diperlukan secara tepat waktu serta risiko munculnya upaya yang berulang dan kemungkinan bertentangan untuk menangani kebutuhan-kebutuhan tersebut.
**Hasil yang diinginkan:**
+ Perjanjian bekerja atau mendukung antar-tim sudah disetujui dan didokumentasikan.
+ Tim-tim yang mendukung atau bekerja dengan satu sama lain memiliki ekspektasi respons dan saluran komunikasi yang telah ditetapkan sebelumnya.
**Anti-pola umum:**
+ Ada sebuah masalah yang terjadi dalam produksi dan dua tim terpisah mulai menyelesaikan masalahnya sendiri-sendiri. Upaya terpisah mereka memperpanjang masa henti produksi.
+ Tim operasi membutuhkan bantuan dari tim pengembangan, tetapi tidak ada waktu respons yang disepakati. Permintaannya tetap berada dalam timbunan yang belum dikerjakan (backlog).
**Manfaat menjalankan praktik terbaik ini:**
+ Tim mengetahui cara berinteraksi dan mendukung satu sama lain.
+ Ekspektasi untuk tingkat responsivitas sudah diketahui.
+ Saluran komunikasi sudah ditetapkan dengan jelas.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Rendah
## Panduan implementasi
Dengan mengimplementasikan praktik terbaik ini, artinya bahwa sudah tidak ada lagi ambiguitas tentang bagaimana tim bekerja dengan satu sama lain. Perjanjian resmi mengatur tentang bagaimana tim bekerja sama atau mendukung satu sama lain. Saluran komunikasi antar-tim sudah didokumentasikan.
**Contoh pelanggan**
Tim SRE AnyCompany Retail memiliki perjanjian tingkat layanan dengan tim pengembangan mereka. Setiap kali tim pengembangan mengajukan sebuah permintaan dalam sistem tiket mereka, mereka dapat mengantisipasi bahwa respons akan diterima dalam waktu lima belas menit. Jika ada penghentian kerja di lokasi, tim SRE akan memimpin pelaksanaan investigasi dengan dukungan dari tim pengembangan.
**Langkah-langkah implementasi**
1. Melalui kerja sama dengan para pemangku kepentingan yang ada di seluruh organisasi Anda, buatlah perjanjian antara tim berdasarkan proses dan prosedur.
1. Jika sebuah proses atau prosedur dimiliki bersama antara dua tim, kembangkan sebuah runbook tentang cara tim akan bekerja sama.
1. Jika ada ketergantungan antara tim, buat dan sepakati SLA respons untuk permintaan.
1. Buatlah dokumentasi tanggung jawab dalam sistem manajemen pengetahuan Anda.
**Tingkat upaya untuk rencana implementasi:** Sedang. Jika belum ada perjanjian yang dibuat antara tim, mungkin akan diperlukan upaya agar para pemangku kepentingan di seluruh organisasi Anda bisa sepakat.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [OPS02-BP02 Proses dan Prosedur memiliki pemilik teridentifikasi](ops_ops_model_def_proc_owners.md) - Kepemilikan proses harus diidentifikasi sebelum menetapkan perjanjian antar tim.
+ [OPS02-BP03 Aktivitas operasi memiliki pemilik teridentifikasi yang bertanggung jawab atas performanya](ops_ops_model_def_activity_owners.md) - Kepemilikan kegiatan operasi harus diidentifikasi sebelum menetapkan perjanjian antar tim.
**Dokumen terkait:**
+ [Wawasan Eksekutif AWS - Memberdayakan Inovasi dengan Tim Dua Pizza ](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [Pengantar DevOps di AWS - Tim Dua Pizza](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)