Pada petang 31 Ogos 2026, gangguan meluas bermula merentasi Microsoft 365, direkodkan dalam pusat pentadbiran sebagai EX1464935 dan kemudian diperluas di bawah MO1465074. Kesannya tidak terhad kepada e-mel. Exchange Online gagal bersama Teams, SharePoint Online dan OneDrive for Business, dan bersamanya alat tadbir urus dan keselamatan dalam Purview dan Defender XDR. Syarikat yang berhubung dengan pelanggan melalui e-mel, menyelaras kerja dalaman melalui sembang, menyimpan fail di awan dan memantau keselamatannya daripada papan pemuka kehilangan keempat-empatnya pada saat yang sama.

Microsoft menyifatkan puncanya sebagai masalah pada konfigurasi pengesahan teras yang digunakan oleh beberapa perkhidmatan dalaman dalam infrastruktur Exchange Online, dan melaksanakan mitigasi berperingkat yang menggunakan semula komponen pengesahan pada sampel infrastruktur sebelum meluaskannya. Aliran mel dan carian dipulihkan pada 1 September, dengan kesan terhad kepada sebilangan kecil pengguna yang berlarutan hingga 2 September. Gangguan penuh berlangsung lebih daripada sehari, dan kesan sisanya dua hari.

Ini bukan artikel tentang Microsoft. Setiap pembekal besar pernah mengalami gangguan, dan kami pernah membincangkan gangguan pada perkhidmatan AI lain sebelum ini. Ini ialah artikel tentang perkara yang didedahkan oleh gangguan kali ini, yang lebih berbahaya daripada yang kelihatan pada mulanya.

Apa yang anda kira sebagai enam sistem mungkin hanya satu

Minta mana-mana pengurus menyenaraikan sistem mereka dan anda akan mendapat satu senarai: sistem e-mel, sistem sembang, sistem fail, sistem keselamatan. Empat nama, empat ikon, biasanya empat baris dalam kontrak. Andaian semula jadinya ialah jika satu gagal, yang lain tidak turut terheret, kerana semuanya perkara yang berbeza.

Tetapi nama bukanlah sempadan sistem. Sempadan sebenar ialah apa yang dikongsi oleh perkhidmatan tersebut di bawahnya: siapa yang mengesahkan identiti anda, di mana sesi disimpan, rangkaian mana yang dilalui. Apabila empat perkhidmatan berkongsi satu lapisan pengesahan, dari sudut risiko ia adalah satu perkhidmatan, walau seberapa berasingan pun ia kelihatan pada invois.

Perkara yang janggal ialah perkongsian ini tidak pernah kelihatan pada masa biasa. Sebaliknya, inilah yang memberikan anda log masuk tunggal yang mudah dan integrasi lancar antara e-mel dan fail. Anda membeli kemudahan itu setiap hari dan membayarnya sekali setiap beberapa tahun, dalam satu hari yang panjang.

Ini terpakai kepada syarikat Saudi bersaiz sederhana sama seperti kepada perusahaan global. Fikirkan berapa banyak perkhidmatan anda yang bergantung pada satu akaun Google, atau satu nombor WhatsApp, atau satu pembekal pengehosan, atau seorang pekerja yang memegang kata laluan. Setiap satunya ialah titik kegagalan tunggal. Bezanya, yang anda miliki lebih kecil dan jauh lebih mudah dibaiki.

Petakan kebergantungan anda dalam satu jam

Anda tidak memerlukan alat atau perunding. Anda memerlukan sehelai kertas, satu jam dan jawapan yang jujur. Dalam lajur pertama, tulis setiap operasi yang tidak boleh ditinggalkan oleh perniagaan anda selama sehari penuh: menerima pesanan, mengeluarkan invois, menjawab pelanggan, memproses gaji, menyampaikan perkhidmatan. Kemudian tanya tiga soalan bagi setiap satu:

  • Operasi ini bergantung pada perkhidmatan luar yang mana? Tulis nama komersialnya dengan jelas: pembekal e-mel ini, platform kedai dalam talian itu, gerbang pembayaran itu, pembekal pemesejan itu.
  • Akaun atau identiti apakah yang anda gunakan untuk log masuk? Di sinilah biasanya kejutan muncul. Anda akan mendapati empat perkhidmatan berbeza yang dimasuki melalui satu akaun, atau tiga perkhidmatan yang terikat kepada satu nombor telefon bimbit untuk kod pengesahan.
  • Jika ini terhenti sekarang juga, apakah alternatifnya dalam masa satu jam? Jika jawapannya tiada, anda telah menemui titik kegagalan tunggal yang sebenar, bukan teori.

Apabila selesai, satu atau dua entri akan berulang dalam kebanyakan baris. Itulah kebergantungan kongsi anda. Jangan cuba menghapuskan kesemuanya, kerana itu tidak realistik dan tidak ekonomik. Ambil baris yang menghentikan hasil, dan uruskan yang itu dahulu.

Jenis gangguan yang paling boleh dicegah: tarikh tamat tempoh

Tidak semua gangguan sama. Sesetengahnya berpunca daripada kerumitan yang anda tidak kawal. Yang lain berpunca daripada tarikh yang tertulis di suatu tempat yang tiada siapa membacanya. Jenis kedua paling mudah dicegah dan paling kerap berulang, kerana ia hanya memerlukan susulan.

Inilah tarikh tamat tempoh yang secara senyap mengendalikan perniagaan anda, dan setiap satunya perlu berada dalam satu kalendar dengan pemilik yang dinamakan:

  • Sijil penyulitan laman web anda. Apabila ia tamat tempoh, laman anda tidak menjadi perlahan, sebaliknya ia memaparkan amaran keselamatan yang jelas kepada pelawat yang menghalang mereka daripada masuk. Kesannya terhadap jualan serta-merta dan menyeluruh.
  • Pendaftaran domain. Terlupa memperbaharui domain akan menjatuhkan laman web dan e-mel serentak, kerana e-mel berjalan pada domain yang sama. Ia antara gangguan terburuk kerana ia memutuskan saluran yang sepatutnya anda gunakan untuk memberi penjelasan.
  • Sijil cop e-invois. Garis panduan teknikal terperinci e-invois Pihak Berkuasa Zakat, Cukai dan Kastam (ZATCA) menyatakan bahawa pembayar cukai perlu memperbaharui pengecam cop kriptografi bagi unit penjana invois mereka sebelum pengecam sedia ada tamat tempoh, dan pembaharuan melibatkan pembatalan pengecam lama serta pengeluaran yang baharu. Terlepas tempoh itu, anda berdepan masalah invois, bukan sekadar pemberitahuan.
  • Kunci integrasi antara sistem anda. Token akses yang menghubungkan kedai anda dengan sistem inventori, atau sistem anda dengan gerbang pembayaran, mempunyai jangka hayat yang ditetapkan. Tamat tempohnya tidak menghentikan mana-mana sistem, tetapi menghentikan jambatan di antara keduanya, jadi pesanan terus masuk sementara penyegerakan terhenti secara senyap. Itulah jenis kegagalan yang lambat ditemui.
  • Sijil tandatangan aplikasi dan kad yang disimpan. Sijil tandatangan yang tamat tempoh menghalang anda daripada menghantar kemas kini ke gedung aplikasi, dan kad yang tamat tempoh pada langganan menghentikan perkhidmatan itu sendiri. Kedua-duanya cenderung tiba pada saat paling buruk.

Peraturan kerjanya mudah. Apa sahaja yang mempunyai tarikh tamat tempoh memerlukan tiga perkara: amaran enam puluh hari lebih awal, pemilik yang dinamakan dan bukannya jabatan, dan seorang timbalan yang tahu cara memperbaharuinya jika pemilik tiada. Jika salah satu daripada tiga itu tiada, anda kembali bergantung pada ingatan seseorang.

Apa yang perlu dilakukan pada hari pembekal anda gagal

Apabila gangguan melanda, perbezaan antara perniagaan yang kelihatan profesional dan yang kelihatan kelam-kabut bukanlah kelajuan pembaikan, kerana pembaikan memang bukan di tangan anda. Perbezaannya ialah tiga perkara yang anda sediakan lebih awal:

  • Saluran komunikasi di luar lapisan yang gagal. Jika seluruh penyelarasan dalaman anda berada dalam satu alat, anda tiada penyelarasan apabila alat itu gagal. Satu kumpulan sandaran pada saluran yang benar-benar berbeza, serta senarai kenalan yang disimpan di luar sistem, sudah memadai.
  • Mod manual yang diisytiharkan untuk operasi kritikal. Bagaimanakah anda menerima pesanan, merekodkan bayaran dan menyampaikan perkhidmatan tanpa sistem? Tulis pada satu halaman hari ini dan serahkan kepada pasukan. Syarikat yang menulis halaman itu kehilangan beberapa jam. Syarikat yang tidak menulisnya kehilangan sehari.
  • Mesej yang sedia untuk pelanggan. Pelanggan kurang marah dengan gangguan berbanding dengan kesenyapan. Nota ringkas yang menyatakan apa yang terjejas, apa penyelesaian sementaranya dan bila kemas kini seterusnya akan tiba mengubah kegagalan menjadi situasi yang terurus. Jangan janjikan masa pembaikan yang anda tidak kawal.

Selepas ia berakhir, tanya satu soalan sahaja dan tidak lebih: apakah yang kita pelajari hari ini tentang kebergantungan kita yang sebelum ini kita tidak tahu? Jawapannya lebih bernilai daripada mana-mana laporan, dan biasanya ia hanya satu baris yang wajar mendapat satu perubahan.

Pandangan Origami

Dalam kerja kami, perkara yang paling mengejutkan pemilik perniagaan jarang sekali gangguan itu sendiri. Ia adalah apabila mendapati sistem yang mereka sangka bebas antara satu sama lain gagal bersama-sama. Keputusan yang dibina atas kepercayaan bahawa kita ada alternatif akan runtuh apabila ternyata semua alternatif melalui pintu yang sama. Sebab itulah kami memulakan setiap perbincangan tentang kesinambungan dengan memetakan kebergantungan dan bukan dengan membeli alat, kerana alat yang anda beli mungkin juga berada pada lapisan yang sama dan menaikkan risiko dan bukannya mengurangkannya.

Kami juga berpendapat bahawa tindak balas yang betul terhadap gangguan seperti ini bukanlah melarikan diri daripada awan. Infrastruktur awan daripada pembekal yang serius lebih boleh dipercayai berbanding apa yang mampu dibina dan dikendalikan sendiri oleh kebanyakan syarikat, dan gangguan yang jarang berlaku tidak mengubah hakikat itu. Tindak balas yang betul ialah mengetahui dengan tepat operasi anda yang mana terhenti dan yang mana berterusan, dan telah memilihnya dengan sengaja dan bukannya menemuinya pada hari yang malang. Kesinambungan bukanlah sistem yang anda beli. Ia adalah satu set keputusan kecil yang anda buat ketika tiada sebarang tekanan untuk membuatnya.

Kesimpulan

Satu kerosakan dalam lapisan pengesahan yang dikongsi telah menghentikan enam produk selama lebih daripada sehari di syarikat-syarikat di seluruh dunia. Pengajarannya bukan menukar pembekal, tetapi mengetahui apa yang benar-benar dikongsi oleh sistem anda di bawah permukaan. Mulakan dengan jadual tiga lajur yang mendedahkan kebergantungan anda, letakkan setiap tarikh tamat tempoh dalam satu kalendar dengan pemilik yang dinamakan, dan tulis halaman mod manual sebelum anda memerlukannya. Itu kira-kira tiga jam kerja yang berdiri di antara anda dan sehari penuh lumpuh, menjadikannya pelaburan kesinambungan paling murah yang ada.

Sumber