Keuntungan:
- Keupayaan untuk merangka permintaan perubahan, penilaian risiko dan pelan rollback dengan kecerdasan buatan dan menjadikan perubahan itu selamat dan boleh diramal
- Keupayaan untuk mengembangkan domain dengan maklumat pergantungannya sendiri, mengklasifikasikan kebolehdapatan semula dan memperoleh keupayaan untuk merancang penggunaan beransur-ansur dengan kenari.
- Keupayaan untuk memahami bahawa manusialah yang meluluskan, menjadualkan dan memikul tanggungjawab untuk perubahan, dan memperoleh disiplin untuk tidak melaksanakannya tanpa kriteria kejayaan dan jalan kembali.
Pengurusan Perubahan: Tetingkap Penilaian Risiko, Rollback dan Penyelenggaraan dengan AI
Sebilangan besar bencana dalam sistem pengeluaran timbul bukan daripada serangan tetapi daripada perubahan: tampalan, kemas kini konfigurasi, pelancaran keluaran, pembaikan "kecil". Itulah sebabnya setiap organisasi yang matang mempunyai pengurusan perubahan: proses pendisiplinan merancang perubahan pengeluaran, menilai risikonya, meluluskannya, melaksanakannya dan melancarkannya semula apabila perlu. Matlamatnya bukan untuk menghalang perubahan, tetapi untuk menjadikannya selamat dan boleh diramal. Di sini, AI ialah pembantu yang berkuasa dalam merangka permintaan perubahan, menyenaraikan risiko dan sistem yang terjejas, mewujudkan rangka kerja pelan rollback dan menyediakan senarai semak penggunaan. Tetapi peraturan asas kekal: AI menghasilkan pelan tindakan untuk mendokumentasikan perubahan dan risiko; Orang yang meluluskan, menjadualkan dan bertanggungjawab untuk perubahan itu.
Dalam unit ini, konsep permintaan perubahan, penilaian risiko, pelan rollback, tetingkap penyelenggaraan, pengedaran kenari/berperingkat dan CAB (Lembaga Penasihat Perubahan); Anda akan belajar cara merancang perubahan selamat dengan AI.
Anatomi permintaan perubahan yang baik
Perubahan yang tidak terkawal ialah ayat "Saya mengemas kini ini"; Perubahan terkawal adalah rancangan. Permintaan perubahan yang baik menjawab soalan ini: Apakah yang berubah? (skop), Mengapa? (justifikasi), Sistem manakah yang terjejas? (domain dan tanggungan), Apakah tahap risiko? (rendah/sederhana/tinggi), Bila? (tetingkap penyelenggaraan), Bagaimana untuk memohon? (langkah), Bagaimana untuk mengesahkan? (kriteria kejayaan), Bagaimana untuk mendapatkannya semula jika ia menjadi teruk? (rollback), Siapa yang meluluskan? (pihak berkuasa). AI mengisi rangka ini dengan cepat — tetapi anda yang benar-benar mengetahui domain dan risiko, yang mengetahui organisasi; Anda melengkapkan senarai AI dengan pengetahuan pergantungan anda sendiri.
Petua: Dua bahagian perubahan yang paling kerap diabaikan ialah "pelan rollback" dan "kriteria pengesahan kejayaan". Jika anda tidak mempunyai jawapan bertulis kepada soalan "di manakah saya betul-betul beralih dengan arahan yang mana jika ia menjadi buruk" dan "bagaimana saya membuktikan ia berjaya" sebelum melaksanakan perubahan, perubahan itu belum bersedia lagi.
Rollback: pintu keluar setiap perubahan
Inti pengurusan perubahan ialah pelan pemulihan. Setiap perubahan mesti mempunyai laluan putar balik: tampung gulung balik, pulihkan konfigurasi sebelumnya, versi putar balik ke versi sebelumnya, undur dari syot kilat. Perbezaan kritikal ialah: beberapa perubahan mudah dibalikkan (baris konfigurasi), ada yang tidak boleh diterbalikkan atau sangat sukar (penghijrahan skema pangkalan data, pemadaman data). Perubahan tidak dapat dipulihkan ialah kelas risiko tertinggi dan memerlukan perhatian yang paling, sandaran paling banyak, tetingkap penyelenggaraan yang paling sempit. Tanya AI "bolehkah perubahan ini dikembalikan, dan jika tidak, apakah langkah keselamatan tambahan yang perlu saya ambil?"
Tetingkap penyelenggaraan dan penggunaan berperingkat
Tetingkap penyelenggaraan ialah tempoh masa pra-umum di mana perubahan akan memberi kesan kepada jumlah pengguna paling sedikit — biasanya pada waktu malam atau pada hujung minggu apabila trafik rendah. Tetapi memilih masa dengan baik tidak mencukupi; Melancarkan perubahan secara beransur-ansur mengurangkan lagi risiko. Penggunaan Canary adalah untuk menggunakan perubahan pada bahagian kecil dahulu (satu pelayan, 5% pengguna), memantaunya dan menyebarkannya jika tiada masalah. Dengan cara ini, pepijat tidak akan menjejaskan keseluruhan armada tetapi sebahagian kecil dan akan ditangkap lebih awal. Anda boleh meminta AI untuk pelan penggunaan berperingkat dan metrik untuk dijejaki pada setiap fasa.
Langkah demi langkah: Perubahan dibantu AI
- Draf permintaan. Dokumentasikan perubahan dengan AI dalam tajuk di atas.
- Luaskan impaknya. Lengkapkan senarai sistem yang terjejas oleh AI dengan peta pergantungan anda sendiri; "Apa lagi yang berkaitan dengan perkhidmatan ini?"
- Klasifikasikan risiko. Rendah/sederhana/tinggi dan boleh diterbalikkan? Ia memerlukan proses yang paling ketat, yang tinggi dan tidak dapat dipulihkan.
- Tulis rollback dan ujinya. Tuliskan langkah gulung semula dan cuba gulung semula dalam persekitaran ujian jika boleh — "pelan gulung balik" yang tidak boleh ditarik balik tidak dikira sebagai pelan.
- Rancang tingkap dan aras. Tentukan tetingkap penyelenggaraan dan peringkat kenari, dan metrik yang perlu dipantau pada setiap peringkat.
- Pengesahan dan komunikasi. Dapatkan kelulusan pihak berkuasa (CAB jika perlu), maklumkan kepada mereka yang terjejas, laksana, pantau, sahkan.
tiga kes mini
Kes 1 — Pelan putar balik menyelamatkan malam itu. Satu pasukan menggunakan tampung pelayan web; Tampalan itu secara tidak dijangka memecahkan kebergantungan dan tapak mula memberikan ralat 500. Tetapi terdapat langkah rollback yang jelas disediakan dengan AI dalam permintaan perubahan: "alih keluar tampung, pulihkan pakej sebelumnya, muat semula perkhidmatan." Pasukan itu kembali dalam masa 6 minit. Tanpa pelan rollback, gangguan akan berlarutan selama berjam-jam semasa mencari punca pada tengah malam.
Kes 2 — Canary menangkap pepijat pada 5%. Versi baharu akan diedarkan. Pasukan itu meminta AI untuk pelan penggunaan berperingkat: pertama 1 pelayan, tonton, kemudian 25%, kemudian semua. Masa tindak balas dilihat berganda pada pelayan Canary; pengedaran telah dihentikan. Pepijat hanya berterusan pada satu pelayan, dengan 95% pengguna tidak terjejas. Sekiranya ia tersebar sekaligus, keseluruhan perkhidmatan akan runtuh.
Kes 3 — Ukuran tambahan bagi perubahan tidak dapat dipulihkan. Penghijrahan skema pangkalan data telah dirancang — perubahan yang akan menjadi sangat sukar untuk dikembalikan. Jurutera itu bertanya kepada AI tentang risiko; YZ menyatakan bahawa perubahan itu tidak boleh diterbalikkan dan mengesyorkan sandaran penuh, larian ujian berasingan dan tetingkap sempit. Pasukan mengambil sandaran penuh sejurus sebelum penghijrahan, mencubanya pada salinan terlebih dahulu. Terdapat masalah semasa penghijrahan, tetapi terima kasih kepada sandaran, konsistensi telah dipulihkan dalam masa 20 minit.
Empat templat yang boleh disalin
1) Tukar draf permintaan:
Peranan anda: pakar pengurusan perubahan. Draf permintaan perubahan untuk perubahan berikut: [ubah]. Tajuk: Apa/Mengapa, Sistem dan Ketergantungan Terjejas, Tahap Risiko(rendah/sederhana/tinggi + justifikasi), Adakah Ia Rollback, Langkah Pelaksanaan, Kriteria Pengesahan Kejayaan, Langkah Balik, Syor Tetingkap Penyelenggaraan, Kelulusan yang Diperlukan. Tandakan pergantungan yang anda tidak pasti sebagai "sahkan".
2) Penilaian risiko dan kesan:
Nilaikan perubahan berikut dari segi risiko: [perubahan]. (1) Senaraikan sistem yang mungkin terjejas secara langsung dan tidak langsung, (2) apakah senario terburuk, (3) adakah ia boleh diterbalikkan, jika tidak, apakah langkah tambahan yang perlu saya ambil, (4) mewajarkan tahap risiko. Jelaskan bahawa ini adalah penilaian awal dan keputusan adalah milik saya.
3) Membuat pelan rollback:
Tulis pelan rollback langkah demi langkah untuk [perubahan]. Pastikan setiap langkah boleh disalin dan disahkan. Jika terdapat bahagian perubahan yang tidak boleh diubah, nyatakan dengan jelas dan tuliskan sandaran yang perlu saya ambil untuknya. Tambah cara untuk mengesahkan kejayaan Rollback.
4) Pelan pengedaran (kanari) berfasa:
Cadangkan rancangan berperingkat [pengerahan] untuk pengerahan berikut: fasa yang manakah (cth. 1 pelayan -> 25% -> semua), berapa lama saya perlu menunggu pada setiap fasa dan APAKAH metrik yang harus saya jejak (masa tindak balas, kadar ralat, dsb.)? Apakah ambang yang harus saya hentikan dan gulungkan semula pengerahan jika ia melebihi? Tulis mata keputusan anda dengan jelas.
Gesaan lemah / Gesaan kuat
Gesaan yang lemah:
Patutkah saya menggunakan tampalan ini?
Tiada konteks, tiada impak, tiada redundansi, tiada tingkap. AI tidak mengetahui sistem anda mahupun risiko anda; "ya/tidak" yang akan diberikannya adalah tekaan yang tidak bertanggungjawab.
Gesaan kuat:
Peranan anda: pakar pengurusan perubahan. Saya akan menggunakan tampung keselamatan pada kumpulan pelayan web dalam pengeluaran (8 pelayan, di belakang pengimbang beban). Beri saya: (1) permintaan perubahan draf untuk perubahan ini, (2) kebergantungan yang mungkin terjejas (saya akan mengesahkan), (3) langkah rollback, (4) pelan kenari sebagai 1 pelayan -> 25% -> semua dan metrik yang akan saya pantau pada setiap peringkat. Wajarkan tahap risiko. Saya meluluskan dan memutuskan.
Tukar ciri
risiko rendah
berisiko tinggi
kebolehbalikan
rollback mudah
tidak boleh ditarik balik/sukar
domain
Hidangan tunggal, terpencil
Pelbagai perkhidmatan, rantaian pergantungan
Pengagihan
boleh direct
kenari wajib + tingkap sempit
Kelulusan
dalam pasukan
CAB / kelulusan tertinggi
ganti
Standard
Sandaran penuh + ujian ujian tambahan
Kesilapan biasa
- Melaksanakan tanpa pelan rollback. Perubahan adalah satu perjudian jika jalan kembali tidak ditulis.
- Mengekalkan sfera pengaruh yang sempit. Memintas kebergantungan tersembunyi yang dilampirkan pada perkhidmatan akan mengakibatkan gangguan sampingan yang tidak dijangka.
- Tersalah anggap perubahan tak boleh balik sebagai perubahan biasa. Perubahan seperti pemindahan skema dan pemadaman data memerlukan proses yang paling ketat dan sandaran penuh.
- Menyebarkannya ke seluruh armada sekaligus. Tanpa Canary, pepijat akan melanda semua pengguna sekaligus.
- Tidak menentukan kriteria kejayaan. Jika maksud "berjaya" tidak ditulis, anda mungkin tersalah anggap perubahan yang rosak sebagai "selesai".
Perhatian: Senarai sistem terjejas yang dihasilkan oleh AI adalah permulaan, bukan senarai lengkap. AI tidak mengetahui kebergantungan organisasi anda; Jawapan tepat kepada soalan "Jika perkhidmatan ini ranap, apakah lagi yang akan ranap?" terletak pada pengetahuan korporat anda. Andaikan senarai AI tidak lengkap dan kembangkannya.
Secara ringkasnya
Kebanyakan bencana pengeluaran timbul daripada perubahan, bukan serangan; Pengurusan perubahan tidak menghalang perubahan, ia menjadikannya selamat dan boleh diramal. AI; Draf permintaan perubahan, penilaian risiko, pelan rollback dan senarai semak penggunaan berperingkat dengan pantas. Tetapi kembangkan domain dengan pengetahuan kebergantungan sebenar anda, klasifikasikan kebolehbalikan, tulis rollback dan ujinya jika boleh, agihkan risiko dengan tetingkap penyelenggaraan dan kenari, tentukan kriteria kejayaan. Manusialah yang meluluskan, menjadualkan dan memikul tanggungjawab untuk perubahan itu; AI ialah rakan kongsi yang mempercepatkan rancangan.
Tugasan permohonan
Pilih perubahan pengeluaran yang anda bercadang untuk membuat tidak lama lagi (atau baru-baru ini dibuat). Minta AI menyediakan permintaan perubahan yang lengkap dengan templat "Draf permintaan perubahan" di atas. Kembangkan senarai "sistem yang terjejas" yang dihasilkan AI oleh sekurang-kurangnya dua item dengan maklumat pergantungan anda sendiri. Cetak langkah pemulangan dengan templat "Jana pelan pemulangan" dan tentukan sama ada terdapat mana-mana bahagian perubahan yang tidak boleh ditarik balik. Akhirnya, buat pelan kenari. Ringkaskan keseluruhan rancangan dalam 6 mata dan perhatikan kelulusan yang diperlukan.
senarai semak
- [ ] Adakah saya telah menyediakan permintaan untuk perubahan yang merangkumi apa/mengapa, kesan, risiko, langkah, pengesahan dan pemulangan semula?
- [ ] Adakah saya telah mengembangkan senarai sistem AI yang terjejas dengan maklumat pergantungan saya sendiri?
- [ ] Adakah saya telah mengklasifikasikan sama ada perubahan itu boleh diterbalikkan atau tidak boleh diterbalikkan?
- [ ] Saya menulis langkah rollback dan mencubanya dalam persekitaran ujian, jika boleh?
- [ ] Adakah saya telah menentukan tetingkap penyelenggaraan dan pelan penggunaan kenari serta metrik pemantauan untuk setiap fasa?
- [ ] Adakah saya telah menentukan kriteria pengesahan kejayaan dan menerima kelulusan yang diperlukan?