OPS06-BP01 Antisipasikan perubahan yang tidak berhasil - Pilar Keunggulan Operasional

OPS06-BP01 Antisipasikan perubahan yang tidak berhasil

Rencanakan untuk kembali ke keadaan yang diketahui pasti baik, atau perbaiki di lingkungan produksi jika deployment menyebabkan hasil yang tidak diinginkan. Adanya kebijakan untuk menetapkan rencana semacam ini bermanfaat bagi semua tim dalam mengembangkan strategi untuk pulih dari perubahan yang gagal. Beberapa contoh strategi adalah langkah deployment dan rollback, kebijakan perubahan, penanda fitur, pemisahan lalu lintas, dan pergeseran lalu lintas. Rilis tunggal dapat mencakup beberapa perubahan komponen yang terkait. Strategi harus memberikan kemampuan untuk bertahan atau pulih dari kegagalan perubahan komponen apa pun.

Hasil yang diinginkan: Anda telah menyiapkan rencana pemulihan yang mendetail untuk perubahan Anda apabila perubahan tersebut tidak berhasil. Selain itu, Anda telah mengurangi ukuran rilis untuk meminimalkan dampak potensial pada komponen beban kerja lainnya. Hasilnya, Anda telah mengurangi dampak bisnis Anda dengan mempersingkat potensi waktu henti yang diakibatkan oleh perubahan yang gagal dan meningkatkan fleksibilitas serta efisiensi waktu pemulihan.

Antipola umum:

  • Anda melakukan deployment dan aplikasi Anda menjadi tidak stabil tetapi tampaknya ada pengguna aktif di sistem. Anda harus memutuskan apakah akan mengembalikan perubahan yang akan berdampak pada pengguna aktif atau menunggu untuk mengembalikan perubahan karena tahu bagaimana pun juga pengguna dapat terkena dampaknya.

  • Setelah membuat perubahan rutin, lingkungan baru Anda dapat diakses tetapi salah satu subnet Anda menjadi tidak dapat dijangkau. Anda harus memutuskan apakah akan mengembalikan semuanya atau mencoba memperbaiki subnet yang tidak dapat diakses tersebut. Sementara Anda sedang memutuskan hal ini, subnet tersebut tetap tidak dapat dijangkau.

  • Sistem Anda tidak dirancang dapat diperbarui dengan rilis-rilis yang lebih kecil. Akibatnya, Anda mengalami kesulitan dalam membatalkan perubahan massal tersebut selama deployment yang gagal.

  • Anda tidak menggunakan infrastruktur sebagai kode (IaC) dan Anda melakukan pembaruan manual pada infrastruktur Anda sehingga mengakibatkan konfigurasi yang tidak diinginkan. Anda tidak dapat melacak dan membatalkan perubahan manual secara efektif.

  • Karena Anda belum mengukur peningkatan frekuensi deployment Anda, tim Anda kesulitan mengurangi ukuran perubahan mereka dan meningkatkan rencana rollback mereka untuk setiap perubahan, yang berimbas pada risiko yang lebih besar dan tingkat kegagalan yang meningkat.

  • Anda tidak mengukur total durasi pemadaman yang disebabkan oleh perubahan yang tidak berhasil. Tim Anda tidak dapat memprioritaskan dan meningkatkan proses deployment serta efektivitas rencana pemulihannya.

Manfaat menjalankan praktik terbaik ini: Memiliki rencana untuk pulih dari perubahan yang gagal meminimalkan rata-rata waktu untuk pulih (MTTR) dan mengurangi dampak bisnis Anda.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Tinggi

Panduan implementasi

Kebijakan dan praktik yang konsisten serta terdokumentasi yang diadopsi oleh tim rilis memungkinkan organisasi untuk merencanakan apa yang harus terjadi apabila terjadi kegagalan perubahan. Kebijakan harus memungkinkan perbaikan maju (fix forward) dalam keadaan tertentu. Dalam situasi apa pun, rencana perbaikan maju atau rollback harus didokumentasikan dan diuji dengan baik sebelum deployment ke produksi langsung sehingga waktu yang diperlukan untuk mengembalikan perubahan dapat diminimalkan.

Langkah implementasi

  1. Dokumentasikan kebijakan yang mengharuskan tim memiliki rencana efektif untuk mengembalikan perubahan dalam periode tertentu.

    1. Kebijakan harus menentukan kapan situasi perbaikan maju diperbolehkan.

    2. Rencana rollback yang terdokumentasi harus dapat diakses oleh semua pihak yang terlibat.

    3. Tentukan persyaratan untuk rollback (misalnya, ketika ternyata ada perubahan tidak sah yang telah di-deploy).

  2. Analisis tingkat dampak semua perubahan yang berkaitan dengan setiap komponen beban kerja.

    1. Biarkan perubahan berulang untuk distandardisasi, dijadikan templat, dan diotorisasi di awal jika perubahan tersebut mengikuti alur kerja konsisten yang memberlakukan kebijakan perubahan.

    2. Kurangi potensi dampak perubahan apa pun dengan menjadikan ukuran perubahan lebih kecil sehingga pemulihan membutuhkan waktu yang lebih singkat dan menyebabkan lebih sedikit dampak bisnis.

    3. Pastikan prosedur rollback mengembalikan kode ke keadaan yang pasti baik untuk menghindari insiden jika memungkinkan.

  3. Integrasikan alat dan alur kerja untuk menegakkan kebijakan Anda secara terprogram.

  4. Buat agar data tentang perubahan dapat dilihat oleh pemilik beban kerja lain untuk meningkatkan kecepatan diagnosis perubahan yang gagal yang tidak dapat dibatalkan.

    1. Ukur keberhasilan praktik ini menggunakan data perubahan yang terlihat dan identifikasi peningkatan iteratif.

  5. Gunakan alat pemantauan untuk memverifikasi keberhasilan atau kegagalan deployment untuk mempercepat pengambilan keputusan saat melakukan rollback.

  6. Ukur durasi pemadaman Anda selama perubahan yang gagal untuk terus meningkatkan kualitas rencana pemulihan Anda.

Tingkat upaya untuk rencana implementasi: Sedang

Sumber daya

Praktik terbaik terkait:

Dokumen terkait:

Video terkait: