Apabila Amazon Web Services mengalami gangguan besar di wilayah Virginia Utara pada 19-20 Oktober 2025, punca segera kelihatan mudah: keadaan perlumbaan dalam sistem pengurusan DNS DynamoDB. Tetapi apabila komuniti teknikal menyelidiki laporan postmortem terperinci Amazon, satu cerita yang lebih kompleks timbul tentang cabaran semula jadi mengurus sistem teragih yang sangat rumit dan sama ada pendekatan tradisional untuk kebolehpercayaan memadai pada skala awan.
Keadaan Perlumbaan DNS Yang Memulakan Segalanya
Gangguan ini bermula dengan apa yang kelihatan seperti masalah sistem teragih klasik - pelaku DNS berganda yang bekerja secara bebas merentasi Zon Ketersediaan berbeza menjadi tidak selaras. Satu pelaku mengalami kelewatan luar biasa semasa memproses kemas kini, manakala yang lain meluru ke hadapan dengan pelan lebih baharu. Masa tersebut mencipta ribut sempurna di mana pelan DNS lapuk menimpa pelan semasa, kemudian proses pembersihan memadamkan pelan aktif sepenuhnya. Ini meninggalkan titik akhir wilayah DynamoDB tanpa alamat IP, secara efektif menjadikan perkhidmatan itu tidak dapat diakses.
Apa yang membimbangkan jurutera ialah kekurangan perlindungan asas sistem teragih. Seperti yang dinyatakan seorang pemberi komen, Kedengarannya seperti kes 'mengembangkan algoritma sistem teragih sendiri' tanpa pelaburan awal dalam melaksanakan sistem teragih benar yang kukuh. Sistem itu kekurangan operasi banding-dan-tukar atau semakan versi yang betul yang boleh menghalang pelan basi daripada menimpa data lebih baharu.
Sistem Dalaman AWS Utama yang Disebut
- DNS Planner: Memantau kesihatan load balancer dan mencipta pelan DNS
- DNS Enactor: Melaksanakan perubahan DNS kepada Route53 (berjalan dalam 3 AZ)
- DWFM (Droplet Workflow Manager): Menguruskan pelayan fizikal untuk EC2
- Network Manager: Mengendalikan penyebaran konfigurasi rangkaian
- NLB Health Check Subsystem: Memantau kesihatan nod load balancer
Kegagalan Berturutan Dedah Isu Seni Bina Lebih Mendalam
Walaupun isu DNS diselesaikan dalam beberapa jam, kerosakan sebenar datang daripada kegagalan berturutan merentasi infrastruktur AWS. Pengurus Aliran Kerja Droplet (DWFM), yang menguruskan pelayan fizikal untuk contoh EC2, memasuki apa yang dipanggil jurutera sebagai keruntuhan kesesakan. Apabila DWFM cuba menubuhkan semula pajakan dengan titisan merentasi armada EC2, jumlah kerja yang banyak mencipta gelung maklum balas di mana percubaan tamat masa dan beratur lebih banyak kerja cuba semula, menghalang sebarang kemajuan.
Memandangkan situasi ini tidak mempunyai prosedur pemulihan operasi yang ditetapkan, jurutera berhati-hati dalam cuba menyelesaikan isu dengan DWFM tanpa menyebabkan masalah lanjut.
Pengakuan dalam laporan Amazon ini amat membimbangkan komuniti teknikal. Bahawa komponen teras infrastruktur EC2 sedemikian kekurangan prosedur pemulihan ditetapkan untuk mod kegagalan ini mencadangkan isu lebih mendalam dalam kesediaan operasi. Penyelesaian akhir - menyekat kerja masuk dan memulakan semula hos DWFM terpilih - pada asasnya adalah pembedahan kecemasan pada sistem hidup.
Debat Sistem Kompleks
Gangguan ini mencetuskan perdebatan hangat tentang bagaimana kita memikirkan kegagalan dalam sistem kompleks. Ramai jurutera menunjuk kepada esei Richard Cook How Complex Systems Fail sebagai memberikan konteks penting. Cook berhujah bahawa dalam sistem benar-benar kompleks, konsep punca tunggal mengelirukan - kegagalan timbul daripada gabungan keadaan pendam yang secara individu mungkin tidak berbahaya.
Perspektif ini mencabar pendekatan tindak balas insiden tradisional. Seperti yang dijelaskan seorang pemberi komen, Memandangkan sumber terhad, patutkah anda bertindak balas kepada insiden ini dengan mengaudit sistem pengurusan DNS anda untuk keadaan perlumbaan? Atau sebaliknya, anda harus memikirkan bagaimana membuat Pengurus Droplet bertahan daripada pemisahan daripada DynamoDB tanpa memasuki keruntuhan kesesakan? Jawapannya mungkin melibatkan kedua-duanya, tetapi keutamaan yang penambahbaikan memberikan paling banyak kebolehpercayaan menjadi semakin sukar apabila sistem menjadi lebih kompleks.
Realiti Operasi vs Kesempurnaan Teoretikal
Perbincangan mendedahkan ketegangan antara amalan terbaik sistem teragih teoretikal dan realiti operasi menjalankan perkhidmatan pada skala AWS. Beberapa pemberi komen dengan pengalaman di syarikat teknologi besar menerangkan cabaran giliran bertugas dan pengumpulan hutang teknikal beransur-ansur yang menjadikan sistem lebih rapuh dari masa ke masa.
Seorang kontraktor berkongsi: Saya tidak pernah bekerja di syarikat yang mengendalikan giliran bertugas sebagai urusan sangat serius. Di atas kertas, mereka kedua-duanya mengatakan ia serius dan semua perkara SLA disediakan, tetapi dalam realiti tidak ada sokongan mencukupi. Ini mencadangkan bahawa walaupun di pembekal awan utama, faktor manusia dan organisasi mungkin sama penting dengan faktor teknikal dalam mengekalkan kebolehpercayaan.
Insiden ini juga menyerlahkan cabaran kebergantungan merentasi wilayah. Walaupun model wilayah AWS dipasarkan sebagai bebas sepenuhnya, gangguan itu mendedahkan bahawa beberapa perkhidmatan global masih bergantung kepada us-east-1, mencipta titik kegagalan tunggal yang menjejaskan pelanggan di seluruh dunia. Ini bukan kali pertama ini berlaku, mencadangkan bahawa menghapuskan kebergantungan ini lebih mencabar daripada yang kelihatan.
Perkhidmatan AWS yang Terjejas
- Teras: DynamoDB, EC2, Network Load Balancer
- Pengkomputeran: Lambda, ECS, EKS, Fargate
- Identiti: IAM, AWS Management Console, Security Token Service
- Analitik: Redshift
- Perniagaan: Amazon Connect
- Sokongan: Managed Workflows for Apache Airflow, Outposts, Support Center
Pandangan Ke Hadapan
Amazon telah mengambil tindakan segera dengan melumpuhkan automasi DNS bermasalah di seluruh dunia. Pembaikan dirancang mereka termasuk menangani keadaan perlumbaan, menambah kawalan halaju kepada alih gagal semak kesihatan NLB, dan membina ujian lebih baik untuk aliran kerja pemulihan DWFM. Tetapi persoalan lebih luas kekal: boleh mana-mana organisasi benar-benar menjangka dan mencegah semua mod kegagalan dalam sistem kerumitan ini?
Perbincangan komuniti teknikal mencadangkan bahawa apabila sistem menjadi lebih kompleks, pendekatan kita kepada kebolehpercayaan mesti berkembang melampaui mencari dan membaiki punca akar ke arah mereka bentuk sistem yang boleh merosot dengan anggun dan pulih dengan pantas. Gangguan AWS berfungsi sebagai peringatan bahawa dalam sistem teragih, kegagalan tidak dapat dielakkan - tetapi kegagalan katastrofik tidak semestinya berlaku.
Perbualan berterusan tentang sama ada sistem AI semasa boleh membantu dengan senario penyelesaian masalah kompleks sedemikian, dengan pendapat berbelah bahagi tentang sama ada pengecaman corak sahaja boleh menyelesaikan masalah yang memerlukan pemahaman mendalam tentang interaksi sistem. Apa yang jelas ialah apabila infrastruktur awan menjadi lebih penting kepada perniagaan global, taruhan untuk melakukan ini dengan betul terus meningkat.
Rujukan: Ringkasan Gangguan Perkhidmatan Amazon DynamoDB di Wilayah Virginia Utara (US-EAST-1)