Pada malam 31 Agustus 2026, gangguan luas dimulai di Microsoft 365, dicatat di pusat admin sebagai EX1464935 dan kemudian diperluas di bawah MO1465074. Dampaknya tidak terbatas pada email. Exchange Online tumbang bersama Teams, SharePoint Online, dan OneDrive for Business, dan bersama mereka alat tata kelola dan keamanan di Purview dan Defender XDR. Perusahaan yang menjangkau pelanggannya lewat email, berkoordinasi secara internal lewat chat, menyimpan file di cloud, dan memantau keamanannya dari dasbor kehilangan keempatnya pada saat yang sama.

Microsoft menggambarkan penyebabnya sebagai masalah pada konfigurasi autentikasi inti yang digunakan oleh beberapa layanan internal di dalam infrastruktur Exchange Online, dan menerapkan mitigasi bertahap yang menerapkan ulang komponen autentikasi pada sebagian sampel infrastruktur sebelum memperluasnya. Alur email dan pencarian dipulihkan pada 1 September, dengan dampak terbatas pada sebagian kecil pengguna yang bertahan hingga 2 September. Gangguan penuh berlangsung lebih dari sehari, dan sisanya dua hari.

Ini bukan artikel tentang Microsoft. Setiap penyedia besar pernah mengalami gangguan, dan kami sudah pernah membahas gangguan pada layanan AI lain. Ini adalah artikel tentang hal yang disingkap oleh gangguan kali ini, yang lebih berbahaya daripada kelihatannya.

Yang Anda hitung sebagai enam sistem mungkin hanya satu

Minta manajer mana pun untuk menyebutkan sistem mereka dan Anda akan mendapat daftar: sistem email, sistem chat, sistem file, sistem keamanan. Empat nama, empat ikon, biasanya empat baris di kontrak. Asumsi alaminya adalah satu yang tumbang tidak akan menyeret yang lain, karena semuanya hal yang berbeda.

Tetapi nama bukanlah batas sistem. Batas yang sebenarnya adalah apa yang dibagi layanan-layanan itu di bawahnya: siapa yang memverifikasi identitas Anda, di mana sesi disimpan, jaringan mana yang mereka lalui. Ketika empat layanan berbagi satu lapisan autentikasi, dari sudut pandang risiko mereka adalah satu layanan, seterpisah apa pun kelihatannya di tagihan.

Bagian yang tidak nyaman adalah bahwa pembagian ini tidak pernah terlihat di masa normal. Justru sebaliknya, inilah yang memberi Anda kemudahan masuk sekali dan integrasi mulus antara email dan file. Anda membeli kemudahan itu setiap hari dan membayarnya sekali setiap beberapa tahun, dalam satu hari yang panjang.

Hal ini berlaku bagi perusahaan Saudi berukuran menengah sama halnya dengan perusahaan global. Pikirkan berapa banyak layanan Anda yang bergantung pada satu akun Google, atau satu nomor WhatsApp, atau satu penyedia hosting, atau satu karyawan yang memegang kata sandi. Masing-masing adalah titik kegagalan tunggal. Bedanya, milik Anda lebih kecil dan jauh lebih mudah diperbaiki.

Petakan ketergantungan Anda dalam satu jam

Anda tidak memerlukan alat atau konsultan. Anda memerlukan selembar kertas, satu jam, dan jawaban yang jujur. Di kolom pertama, tulis setiap operasi yang tidak bisa ditinggalkan bisnis Anda selama sehari penuh: menerima pesanan, menerbitkan faktur, menjawab pelanggan, menjalankan penggajian, memberikan layanan. Lalu ajukan tiga pertanyaan untuk masing-masing:

  • Operasi ini bergantung pada layanan eksternal apa? Tulis nama komersialnya dengan lugas: penyedia email ini, platform toko online itu, gateway pembayaran itu, penyedia layanan pesan itu.
  • Akun atau identitas apa yang Anda gunakan untuk masuk? Di sinilah biasanya kejutan muncul. Anda akan menemukan empat layanan berbeda yang dimasuki lewat satu akun, atau tiga layanan yang terikat pada satu nomor ponsel untuk kode verifikasi.
  • Jika ini berhenti sekarang juga, apa alternatifnya dalam satu jam? Jika jawabannya tidak ada, Anda telah menemukan titik kegagalan tunggal yang nyata, bukan teoretis.

Setelah selesai, satu atau dua entri akan berulang di sebagian besar baris. Itulah ketergantungan bersama Anda. Jangan mencoba menghilangkan semuanya, karena itu tidak realistis maupun ekonomis. Ambil baris yang menghentikan pendapatan, dan tangani itu lebih dulu.

Jenis gangguan yang paling bisa dicegah: tanggal kedaluwarsa

Tidak semua gangguan sama. Sebagian berasal dari kerumitan yang tidak Anda kendalikan. Sebagian lain berasal dari tanggal yang tertulis di suatu tempat yang tidak dibaca siapa pun. Jenis kedua paling mudah dicegah dan paling sering berulang, karena yang dibutuhkannya hanyalah tindak lanjut.

Inilah tanggal kedaluwarsa yang diam-diam mengendalikan bisnis Anda, dan masing-masing harus masuk ke satu kalender dengan penanggung jawab yang disebut namanya:

  • Sertifikat enkripsi situs web Anda. Ketika kedaluwarsa, situs Anda tidak menjadi lambat, melainkan menampilkan peringatan keamanan yang gamblang kepada pengunjung sehingga mereka tidak jadi masuk. Dampaknya pada penjualan langsung dan total.
  • Pendaftaran domain. Lupa memperpanjang domain akan menjatuhkan situs web dan email sekaligus, karena email berjalan di domain yang sama. Ini termasuk gangguan terburuk karena memutus justru saluran yang akan Anda gunakan untuk memberi penjelasan.
  • Sertifikat stempel faktur elektronik. Pedoman teknis terperinci faktur elektronik Otoritas Zakat, Pajak, dan Bea Cukai (ZATCA) menyatakan bahwa wajib pajak memperbarui pengenal stempel kriptografis untuk unit penghasil faktur mereka sebelum pengenal yang ada kedaluwarsa, dan bahwa pembaruan melibatkan pencabutan pengenal lama dan penerbitan yang baru. Terlewat jendela waktunya, Anda menghadapi masalah penagihan, bukan sekadar notifikasi.
  • Kunci integrasi antar-sistem Anda. Token akses yang menghubungkan toko Anda dengan sistem inventaris, atau sistem Anda dengan gateway pembayaran, memiliki masa berlaku tertentu. Kedaluwarsanya tidak menghentikan kedua sistem, melainkan menghentikan jembatan di antara keduanya, sehingga pesanan terus masuk sementara sinkronisasi diam-diam berhenti. Itulah jenis kegagalan yang terlambat ditemukan.
  • Sertifikat penandatanganan aplikasi dan kartu yang tersimpan. Sertifikat penandatanganan yang kedaluwarsa menghalangi Anda merilis pembaruan ke toko aplikasi, dan kartu yang kedaluwarsa pada langganan menghentikan layanannya sendiri. Keduanya cenderung datang pada saat yang paling buruk.

Aturan kerjanya sederhana. Apa pun yang memiliki tanggal kedaluwarsa membutuhkan tiga hal: peringatan enam puluh hari sebelumnya, penanggung jawab yang disebut namanya dan bukan departemennya, dan wakil yang tahu cara memperbaruinya jika penanggung jawab sedang tidak ada. Jika salah satu dari ketiganya tidak ada, Anda kembali bergantung pada ingatan seseorang.

Apa yang harus dilakukan pada hari penyedia Anda tumbang

Saat gangguan terjadi, perbedaan antara bisnis yang terlihat profesional dan bisnis yang terlihat gelagapan bukanlah kecepatan perbaikan, karena perbaikan memang tidak ada di tangan Anda. Perbedaannya adalah tiga hal yang Anda siapkan sebelumnya:

  • Saluran komunikasi di luar lapisan yang tumbang. Jika seluruh koordinasi internal Anda ada di satu alat, Anda tidak punya koordinasi ketika alat itu tumbang. Grup cadangan di saluran yang benar-benar berbeda, ditambah daftar kontak yang disimpan di luar sistem, sudah cukup.
  • Mode manual yang ditetapkan untuk operasi penting. Bagaimana Anda menerima pesanan, mencatat pembayaran, dan memberikan layanan tanpa sistem? Tulis di satu halaman hari ini dan serahkan kepada tim. Perusahaan yang menulis halaman itu kehilangan beberapa jam. Perusahaan yang tidak menulisnya kehilangan sehari.
  • Pesan yang siap untuk pelanggan. Pelanggan lebih marah karena diam daripada karena gangguannya. Catatan singkat yang menyebutkan apa yang terdampak, apa solusi sementaranya, dan kapan pembaruan berikutnya datang mengubah kegagalan menjadi situasi yang terkelola. Jangan menjanjikan waktu perbaikan yang tidak Anda kendalikan.

Setelah selesai, ajukan satu pertanyaan saja, tidak lebih: apa yang kita pelajari hari ini tentang ketergantungan kita yang sebelumnya tidak kita ketahui? Jawabannya lebih berharga daripada laporan apa pun, dan biasanya berupa satu baris yang layak mendapat satu perubahan.

Pandangan Origami

Dalam pekerjaan kami, yang paling mengejutkan pemilik bisnis jarang sekali gangguan itu sendiri. Yang mengejutkan adalah mendapati bahwa sistem yang mereka yakini independen ternyata tumbang bersamaan. Keputusan yang dibangun di atas keyakinan bahwa kita punya alternatif akan runtuh ketika ternyata semua alternatif melewati pintu yang sama. Itulah sebabnya kami memulai setiap pembicaraan tentang kelangsungan dengan memetakan ketergantungan, bukan dengan membeli alat, karena alat yang Anda beli bisa saja berada di lapisan yang sama dan justru menaikkan risiko alih-alih menurunkannya.

Kami juga berpendapat bahwa respons yang tepat terhadap gangguan seperti ini bukanlah lari dari cloud. Infrastruktur cloud dari penyedia yang serius lebih andal daripada yang dapat dibangun dan dioperasikan sendiri oleh sebagian besar perusahaan, dan gangguan yang jarang terjadi tidak mengubah hal itu. Respons yang tepat adalah mengetahui secara persis operasi mana yang berhenti dan mana yang terus berjalan, dan telah memilihnya dengan sengaja alih-alih menemukannya pada hari yang buruk. Kelangsungan bukanlah sistem yang Anda beli. Kelangsungan adalah serangkaian keputusan kecil yang Anda ambil ketika tidak ada tekanan apa pun untuk mengambilnya.

Kesimpulan

Satu kesalahan pada lapisan autentikasi bersama menghentikan enam produk selama lebih dari sehari di perusahaan-perusahaan di seluruh dunia. Pelajarannya bukan berganti penyedia, melainkan mengetahui apa yang benar-benar dibagi sistem Anda di bawah permukaan. Mulailah dengan tabel tiga kolom yang menyingkap ketergantungan Anda, masukkan setiap tanggal kedaluwarsa ke satu kalender dengan penanggung jawab yang disebut namanya, dan tulis halaman mode manual sebelum Anda membutuhkannya. Itu sekitar tiga jam kerja yang berdiri di antara Anda dan sehari penuh kelumpuhan, sehingga menjadikannya investasi kelangsungan paling murah yang tersedia.

Sumber