Topik ini menjelaskan item pemeriksaan yang didukung oleh Model Penilaian Kematangan Tata Kelola 3.0.
Keamanan
Kategori | Item Pemeriksaan | Deskripsi | Deskripsi Perbaikan Cepat | Dukungan Pengambilan Keputusan Terbantu |
Manajemen identitas personel | Multi-factor authentication (MFA) tidak diaktifkan untuk Akun Alibaba Cloud | Aktifkan multi-factor authentication (MFA) untuk Akun Alibaba Cloud Anda guna menambah lapisan keamanan. Konfigurasi tanpa MFA dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas personel | Pengguna Resource Access Management (RAM) memiliki login konsol dan AccessKey yang diaktifkan | Sesuai prinsip hak istimewa minimal, pengguna RAM seharusnya tidak memiliki login konsol dan AccessKey secara bersamaan. Jika kondisi ini ada, konfigurasinya dianggap tidak sesuai. Jika single sign-on (SSO) diaktifkan untuk akun tersebut, pengaturan login konsol diabaikan. Namun, konfigurasi tetap dianggap tidak sesuai jika pengguna memiliki AccessKey dan telah login ke konsol dalam 7 hari terakhir. | Perbaikan ini menonaktifkan login konsol untuk pengguna RAM yang dipilih. Sebelum menerapkan perbaikan, pastikan pengguna tersebut tidak lagi memerlukan akses konsol. | Ya |
Manajemen identitas personel | Pengguna RAM tidak memiliki MFA yang diaktifkan | MFA memberikan lapisan keamanan tambahan bagi pengguna RAM. Jika pengguna RAM memiliki login konsol yang diaktifkan tetapi tidak memiliki MFA yang diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Ya |
Manajemen identitas personel | RAM tidak digunakan untuk manajemen identitas | Akun Alibaba Cloud memiliki izin yang luas, dan kompromi akan menimbulkan risiko keamanan tinggi. Anda harus menggunakan identitas RAM untuk operasi harian. Jika tidak ada identitas RAM, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas personel | Pengguna RAM tidak memenuhi persyaratan kekuatan kata sandi | Menegakkan kebijakan kata sandi kuat mengurangi risiko credential stuffing dan serangan brute-force. Konfigurasi dianggap tidak sesuai jika persyaratan panjang, jenis karakter, masa berlaku, riwayat, atau batas percobaan ulang tidak diterapkan. | Perbaikan ini memperbarui pengaturan kekuatan kata sandi di RAM. Pengaturan dikonfigurasi sebagai berikut: panjang minimum kata sandi 8 karakter, persyaratan setidaknya tiga jenis karakter, usia maksimum kata sandi 90 hari, dan batas lima percobaan login per jam. Ini adalah rekomendasi praktik terbaik. Anda dapat menyesuaikan parameter untuk menerapkan persyaratan yang lebih ketat. Setelah penyiapan selesai, pengaturan berlaku untuk semua pengguna RAM. | Tidak |
Manajemen identitas personel | Akun Alibaba Cloud telah login ke konsol dalam 90 hari terakhir | Akun Alibaba Cloud memiliki izin yang luas yang tidak dapat dibatasi oleh kondisi seperti IP sumber atau waktu. Kompromi akun ini akan menimbulkan risiko keamanan tinggi. Jika akun telah digunakan untuk login ke konsol dalam 90 hari terakhir, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas personel | Ada pengguna RAM yang tidak aktif | Pengguna RAM dengan login konsol yang diaktifkan menggunakan kata sandi untuk login. Semakin lama kata sandi ada, semakin tinggi risiko eksposur. Jika pengguna RAM belum login selama lebih dari 90 hari, konfigurasinya dianggap tidak sesuai. | Perbaikan ini menonaktifkan login konsol untuk pengguna RAM yang dipilih. Sebelum menerapkan perbaikan, pastikan pengguna tersebut tidak lagi memerlukan akses konsol. Catatan: Jika SSO diaktifkan, menonaktifkan login konsol tidak menghapus pengguna dari daftar resource. Untuk menghapus peringatan, Anda harus menghapus pengguna RAM tersebut. | Ya |
Manajemen identitas personel | SSO RAM tidak diaktifkan untuk login konsol | Gunakan SSO untuk mengelola identitas pengguna secara terpusat dan mengurangi risiko keamanan. Konfigurasi dianggap tidak sesuai jika SSO RAM tidak dikonfigurasi atau jika tidak ada login SSO dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas personel | Manajemen terpadu untuk identitas multi-akun direkomendasikan | Gunakan Cloud SSO untuk mengelola semua pengguna di organisasi Anda. Anda dapat mengonfigurasi penyedia identitas perusahaan (IdP) untuk Alibaba Cloud SSO dan menetapkan izin akses seragam untuk akun anggota di Resource Directory (RD). Jika Cloud SSO belum digunakan selama lebih dari 90 hari, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas personel | Sinkronisasi pengguna SCIM RAM tidak diaktifkan | System for Cross-domain Identity Management (SCIM) menyinkronkan identitas perusahaan ke Alibaba Cloud, yang menghilangkan kebutuhan pembuatan pengguna manual. Konfigurasi dianggap tidak sesuai jika SCIM tidak dikonfigurasi atau jika pengguna yang disinkronkan belum login selama dua bulan. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas programatik | Ada AccessKey aktif untuk Akun Alibaba Cloud | AccessKey untuk Akun Alibaba Cloud memberikan izin penuh ke akun tersebut. Tidak dapat dibatasi oleh kondisi seperti IP sumber atau waktu. Kebocoran AccessKey ini akan menimbulkan risiko keamanan tinggi. Jika ada AccessKey aktif untuk akun tersebut, konfigurasinya dianggap tidak sesuai. | Perbaikan ini menonaktifkan AccessKey yang dipilih untuk Akun Alibaba Cloud. Sebelum menerapkan perbaikan, pastikan AccessKey tersebut tidak digunakan oleh program atau aplikasi apa pun. Menonaktifkan AccessKey sebagian meningkatkan skor keamanan, tetapi peringatan tetap ada hingga AccessKey dihapus. Catatan: Hanya Akun Alibaba Cloud yang dapat melakukan perbaikan ini. Upaya melakukan perbaikan ini menggunakan pengguna RAM atau peran RAM akan gagal. | Ya |
Manajemen identitas programatik | Pengguna RAM memiliki dua AccessKey aktif | Pengguna RAM dengan dua AccessKey aktif tidak dapat melakukan rotasi, yang meningkatkan risiko keamanan. Jika pengguna RAM memiliki dua AccessKey aktif, konfigurasinya dianggap tidak sesuai. | Perbaikan ini menonaktifkan AccessKey yang dipilih untuk pengguna RAM. Sebelum menerapkan perbaikan, pastikan AccessKey tersebut tidak digunakan oleh program atau aplikasi apa pun. | Ya |
Manajemen identitas programatik | Ada AccessKey yang terpapar dan belum ditangani | Jika AccessKey terpapar, penyerang dapat menggunakannya untuk mengakses resource dan data Anda. Jika ada peristiwa paparan AccessKey yang belum ditangani, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas programatik | Kunci KMS dijadwalkan untuk dihapus (baru di model 3.0) | Saat customer master key (CMK) dihapus, tidak dapat dipulihkan. Data yang dienkripsi dengan CMK dan kunci data terkait menjadi tidak dapat didekripsi secara permanen. Untuk mencegah penghapusan tidak sengaja dan gangguan layanan, pastikan CMK aktif tidak dijadwalkan untuk dihapus. Jika CMK dijadwalkan untuk dihapus, konfigurasinya dianggap tidak sesuai. | Perbaikan ini membatalkan penghapusan terjadwal untuk kunci KMS yang dipilih. Status kunci berubah dari Dijadwalkan untuk Dihapus menjadi Diaktifkan. Setelah kunci diaktifkan, dapat digunakan untuk mengenkripsi dan mendekripsi data, serta biaya standar berlaku. | Tidak |
Manajemen identitas programatik | AccessKey tidak dirotasi secara berkala | Rotasi AccessKey secara berkala mengurangi waktu eksposur dan menurunkan risiko kebocoran. Jika AccessKey pengguna RAM telah digunakan lebih dari 365 hari, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas programatik | Ada AccessKey yang tidak aktif | AccessKey pengguna RAM memungkinkan akses API ke Alibaba Cloud. Semakin lama AccessKey terpapar, semakin tinggi risiko kebocoran. Jika AccessKey belum digunakan lebih dari 365 hari, konfigurasinya dianggap tidak sesuai. | Perbaikan ini menonaktifkan AccessKey yang dipilih untuk pengguna RAM. Sebelum menerapkan perbaikan, pastikan AccessKey tersebut tidak digunakan oleh program atau aplikasi apa pun. Menonaktifkan AccessKey sebagian meningkatkan skor keamanan, tetapi peringatan tetap ada hingga AccessKey dihapus. | Ya |
Manajemen identitas programatik | Instans Redis tidak memiliki autentikasi kata sandi yang diaktifkan (baru di model 3.0) | Jika instans Redis di VPC tidak memiliki autentikasi kata sandi yang diaktifkan atau memiliki pengaturan keamanan yang salah, dapat menyebabkan kebocoran data, tindakan berbahaya tidak sah, masalah keamanan jaringan, atau gangguan layanan. Jika autentikasi kata sandi dinonaktifkan untuk instans Redis di VPC, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas programatik | Akses programatik tidak menggunakan solusi bebas AccessKey | Konfigurasi dianggap tidak sesuai jika instans ECS tidak memiliki peran instans, klaster ACK tidak memiliki plugin RRSA yang diaktifkan, atau layanan Function Compute tidak memiliki peran layanan. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen identitas programatik | Instans ECS tidak menggunakan Metadata Service yang diperkuat (V2) | Gunakan Metadata Service yang diperkuat (V2) untuk instans ECS guna mencegah potensi kebocoran token Security Token Service (STS) yang dapat terjadi dengan V1. Jika instans ECS menggunakan V1, konfigurasinya dianggap tidak sesuai. Untuk mengatasi masalah ini, tingkatkan Metadata Service ke V2. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen izin | Terlalu banyak identitas RAM memiliki izin AdministratorAccess | Sesuai prinsip hak istimewa minimal, Anda harus membatasi jumlah identitas RAM yang diberikan izin AdministratorAccess. Izin ini memungkinkan kontrol penuh atas semua resource, dan memberikannya kepada terlalu banyak identitas meningkatkan dampak potensi kebocoran identitas. Konfigurasi dianggap sesuai jika tiga atau kurang identitas RAM memiliki izin AdministratorAccess. | Perbaikan ini mengganti izin AdministratorAccess dengan izin PowerUserAccess. PowerUserAccess memberikan akses penuh ke layanan dan resource Alibaba Cloud tetapi tidak mencakup izin untuk mengelola identitas RAM, Resource Directory, resource bersama, atau informasi akun keuangan. Perbaikan ini menganalisis log audit izin dan secara otomatis mengganti izin AdministratorAccess dengan izin PowerUserAccess untuk identitas administrator yang tidak digunakan. | Tidak |
Manajemen izin | Terlalu banyak identitas RAM non-administrator memiliki izin penagihan berisiko tinggi | Sesuai prinsip hak istimewa minimal, Anda harus membatasi izin penagihan berisiko tinggi. Izin seperti `bss:*`, `bssapi:*`, `bss:PayOrder`, `bss:Modify*`, `bss:Create*`, `bss:*Order*`, dan `bss:Delete*` memungkinkan pengguna memodifikasi pesanan, faktur, kontrak, tagihan, transaksi, dan penarikan. Salah urus izin ini dapat menyebabkan kerugian finansial. Konfigurasi dianggap sesuai jika tiga atau kurang identitas RAM non-administrator memiliki izin ini. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen izin | Terlalu banyak identitas RAM non-administrator memiliki izin tinggi | Sesuai prinsip hak istimewa minimal, Anda harus membatasi izin tinggi. Izin ini memungkinkan identitas RAM meningkatkan izin mereka sendiri atau orang lain. Penyalahgunaan izin ini dapat membahayakan keamanan dan kerahasiaan resource Anda. Konfigurasi dianggap sesuai jika tiga atau kurang identitas RAM non-administrator memiliki izin tinggi. Untuk daftar lengkap izin tinggi, lihat dokumentasi. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen izin | Identitas RAM non-administrator memiliki izin dekripsi untuk semua kunci KMS | KMS memungkinkan Anda mengontrol siapa yang dapat menggunakan kunci Anda dan mengakses data terenkripsi Anda. Kebijakan RAM menentukan tindakan yang dapat dilakukan identitas, seperti pengguna, grup, atau peran, pada resource tertentu. Ikuti praktik keamanan terbaik dengan hanya memberikan izin yang diperlukan dan membatasi akses ke kunci tertentu. Memberikan izin `kms:Decrypt` untuk semua kunci menciptakan risiko keamanan berlebihan. Sebagai gantinya, identifikasi set minimum kunci yang diperlukan dan berikan akses hanya ke kunci tersebut. Misalnya, Anda dapat mengizinkan tindakan `kms:Decrypt` hanya pada kunci tertentu di wilayah tertentu. Pendekatan ini meminimalkan risiko eksposur data. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen izin | Identitas RAM memiliki izin tingkat produk yang menganggur | Izin tingkat produk dianggap menganggur jika tidak digunakan selama periode tertentu setelah diberikan. Hal ini dapat terjadi karena perubahan peran atau jika izin awal yang diberikan terlalu luas. Sebagai praktik terbaik, Anda harus menarik kembali izin yang menganggur untuk mencapai otorisasi detail halus. Jika identitas RAM memiliki izin tingkat produk yang menganggur selama 180 hari, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen izin | Identitas RAM memiliki izin operasi berisiko tinggi yang menganggur | Izin operasi berisiko tinggi, seperti membuat pengguna RAM, dianggap menganggur jika tidak digunakan selama periode tertentu setelah diberikan. Hal ini dapat terjadi karena perubahan peran atau jika izin awal yang diberikan terlalu luas. Sebagai praktik terbaik, Anda harus segera menarik kembali izin berisiko tinggi yang menganggur untuk mencegah insiden keamanan. Jika identitas RAM memiliki izin operasi berisiko tinggi yang menganggur selama 180 hari, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen izin | Semua identitas RAM memiliki izin AdministratorAccess | Sesuai prinsip hak istimewa minimal, Anda harus menghindari memberikan izin AdministratorAccess kepada semua identitas RAM untuk membatasi dampak potensi kebocoran identitas. Konfigurasi dianggap sesuai jika setidaknya satu identitas RAM memiliki izin non-administrator. | Perbaikan ini mengganti izin AdministratorAccess dengan izin PowerUserAccess. PowerUserAccess memberikan akses penuh ke layanan dan resource Alibaba Cloud tetapi tidak mencakup izin untuk mengelola identitas RAM, Resource Directory, resource bersama, atau informasi akun keuangan. Perbaikan ini menganalisis log audit izin dan secara otomatis mengganti izin AdministratorAccess dengan izin PowerUserAccess untuk identitas administrator yang tidak digunakan. | Tidak |
Manajemen izin | Access Analyzer tidak digunakan untuk manajemen izin (baru di model 3.0) | Access Analyzer membantu Anda mengidentifikasi resource yang dibagikan dengan akun eksternal dan mendeteksi pembagian tak terduga untuk mengurangi risiko keamanan. Access Analyzer juga mengidentifikasi identitas dengan izin berlebihan dan menghasilkan laporan analisis. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen izin | Menggunakan kebijakan kontrol untuk perlindungan batas multi-akun direkomendasikan | Kebijakan kontrol Resource Directory memungkinkan organisasi membatasi layanan cloud dan operasi yang dapat diakses akun anggota. Hal ini membantu memusatkan manajemen batas izin dan memastikan kepatuhan terhadap standar keamanan. Konfigurasi dianggap tidak sesuai jika tidak ada kebijakan kontrol kustom yang dibuat dan dilampirkan ke folder Resource Directory atau akun anggota. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen izin | Tidak ada pengguna RAM yang mewarisi izin dari grup pengguna RAM | Secara default, pengguna, grup, dan peran RAM tidak dapat mengakses resource apa pun. Anda harus memberikan izin menggunakan kebijakan RAM. Untuk menyederhanakan manajemen dan mengurangi risiko ekspansi izin tidak sengaja, Anda harus menerapkan kebijakan ke grup atau peran daripada pengguna individual. Konfigurasi sesuai dengan praktik terbaik jika setidaknya satu pengguna RAM mewarisi izin dari grup pengguna RAM. | Perbaikan cepat tidak didukung. | Tidak |
Pengumpulan dan pengarsipan log | Log ActionTrail tidak disimpan dalam jangka panjang | Konfigurasi dianggap tidak sesuai jika tidak ada jejak yang dibuat, atau jika jejak yang ada tidak mengarsipkan event dari semua wilayah, tidak mengarsipkan semua operasi baca dan tulis, atau menyimpan log kurang dari 180 hari. | Perbaikan ini meningkatkan pengaturan jejak yang ada untuk menyertakan semua event manajemen baca dan tulis serta event dari semua wilayah. Anda harus memilih setidaknya satu jejak yang ada untuk diperbarui. Event baru yang dihasilkan setelah perbaikan diterapkan dikirim ke penyimpanan tujuan jejak tersebut. Event historis tidak terpengaruh. | Tidak |
Pengumpulan dan pengarsipan log | EDAS tidak memiliki konfigurasi pengumpulan log (baru di model 3.0) | Alibaba Cloud Enterprise Distributed Application Service (EDAS) terintegrasi dengan Simple Log Service (SLS) untuk mengumpulkan log aplikasi dan log stdout kontainer dari klaster Kubernetes untuk kueri dan analisis. Jika pengumpulan log tidak dikonfigurasi untuk EDAS, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Pengumpulan dan pengarsipan log | Bucket OSS tidak memiliki kueri log real-time yang diaktifkan (baru di model 3.0) | Fitur logging real-time OSS mencatat akses ke bucket untuk tujuan audit, pemantauan, dan analisis. Konfigurasi dianggap tidak sesuai jika logging real-time dinonaktifkan atau jika periode retensi log 180 hari atau kurang. | Perbaikan cepat tidak didukung. | Tidak |
Pengumpulan dan pengarsipan log | Bucket OSS tidak memiliki pengiriman log yang diaktifkan (baru di model 3.0) | Log akses OSS dapat menghasilkan volume data yang besar. Fitur pengiriman log menulis file log per jam ke bucket tertentu menggunakan konvensi penamaan tetap. Anda dapat menganalisis log yang dikirim menggunakan Simple Log Service atau kluster Spark. Konfigurasi dianggap sesuai jika pengiriman log diaktifkan untuk bucket OSS. | Perbaikan cepat tidak didukung. | Tidak |
Pengumpulan dan pengarsipan log | Situs ESA tidak memiliki tugas pengiriman log yang dikonfigurasi | Pemeriksaan ini memverifikasi bahwa setidaknya satu tipe log dikonfigurasi untuk situs guna menyediakan log akses real-time untuk pemantauan, analisis, dan optimasi pengiriman konten. Jika tidak ada tipe log yang dikonfigurasi, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Pengumpulan dan pengarsipan log | Log Cloud Firewall tidak dikumpulkan dan disimpan selama 180 hari atau lebih | Cloud Firewall secara otomatis mencatat semua lalu lintas dan menyediakan halaman audit visual untuk peristiwa serangan, detail lalu lintas, dan log operasi. Periode retensi log default adalah 7 hari. Untuk kepatuhan dan keamanan yang ditingkatkan, Anda harus menyimpan log selama 180 hari atau lebih. Jika Anda membeli edisi langganan Cloud Firewall tetapi tidak menyimpan log selama 180 hari atau lebih, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan ini mengaktifkan analisis log untuk Cloud Firewall dan menetapkan periode retensi log. Untuk mematuhi regulasi perlindungan data dan keamanan jaringan, periode retensi harus 180 hari atau lebih. Setelah fitur ini diaktifkan, Cloud Firewall membuat Project dan Logstore khusus untuk menyimpan semua log. Biaya dikenakan berdasarkan durasi retensi dan kapasitas penyimpanan. Untuk informasi lebih lanjut, lihat detail penagihan. | Tidak |
Pengumpulan dan pengarsipan log | Agregasi terpusat log operasi multi-akun direkomendasikan | ActionTrail menyimpan event selama 90 hari secara default. Membuat jejak membantu Anda mempertahankan catatan operasi untuk kepatuhan. Jejak multi-akun memungkinkan administrator melacak dan mengaudit log secara terpusat di beberapa akun. Jika tidak ada jejak multi-akun, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Pengumpulan dan pengarsipan log | Mengaktifkan pengumpulan log terpusat untuk lingkungan multi-akun direkomendasikan | Jika layanan tepercaya untuk audit log Simple Log Service (SLS) dinonaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan kepatuhan | Resource cloud tidak sesuai | Jika aturan Cloud Config mendeteksi ketidaksesuaian dan tingkat resource sesuai di bawah 100%, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan kepatuhan | Cloud Config tidak diaktifkan | Jika Cloud Config tidak diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan kepatuhan | Aturan kepatuhan Cloud Config tidak diaktifkan | Jika aturan kepatuhan Cloud Config tidak diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan kepatuhan | Aturan kepatuhan Cloud Config tidak mencakup semua resource cloud | Jika cakupan aturan di bawah 100%, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan kepatuhan | Mengaktifkan pemeriksaan konfigurasi terpadu untuk lingkungan multi-akun direkomendasikan | Konfigurasi dianggap tidak sesuai jika salah satu kondisi berikut tidak terpenuhi: 1. Ada grup akun dan aturan dikonfigurasi. 2. Peristiwa ketidaksesuaian dikirim ke SLS. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan kepatuhan | Data pemeriksaan kepatuhan tidak diambil secara berkala | Jika Cloud Config tidak mengirimkan peristiwa ketidaksesuaian atau hasilnya tidak dilihat dalam 7 hari terakhir, konfigurasinya dianggap tidak sesuai. | Perbaikan ini membuat tugas pengiriman data resource di akun saat ini. Tugas ini mengirimkan snapshot konfigurasi dan kepatuhan serta perubahan ke SLS, OSS, atau MNS di akun Alibaba Cloud tertentu untuk persistensi dan notifikasi. Tugas pengiriman gratis, tetapi biaya standar berlaku untuk pengiriman data. Untuk informasi lebih lanjut, lihat detail penagihan. | Tidak |
Pemeriksaan kepatuhan | Pengiriman perubahan resource atau snapshot tidak dikonfigurasi | Jika Cloud Config tidak mengirimkan perubahan resource atau snapshot, konfigurasinya dianggap tidak sesuai. | Perbaikan ini membuat tugas pengiriman data resource di akun saat ini. Tugas ini mengirimkan snapshot konfigurasi dan kepatuhan serta perubahan ke SLS, OSS, atau MNS di akun Alibaba Cloud tertentu untuk persistensi dan notifikasi. Tugas pengiriman gratis, tetapi biaya standar berlaku untuk pengiriman data. Untuk informasi lebih lanjut, lihat detail penagihan. | Tidak |
Perlindungan resource komputasi | Isu baseline host memerlukan remediasi | Virus dan peretas mengeksploitasi kelemahan konfigurasi server untuk mencuri data atau menginstal backdoor. Pemeriksaan baseline menilai konfigurasi OS, database, perangkat lunak, dan kontainer. Meremediasi isu baseline memperkuat keamanan, mengurangi risiko intrusi, dan membantu memenuhi persyaratan kepatuhan. Jika ada baseline yang belum diperbaiki, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan resource komputasi | Kerentanan memerlukan remediasi | Manajemen kerentanan adalah proses berkelanjutan dan proaktif. Ini melindungi sistem, jaringan, dan aplikasi dari serangan siber dan pelanggaran data. Remediasi tepat waktu mencegah serangan dan meminimalkan kerusakan. Jika ada kerentanan yang belum diperbaiki, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan resource komputasi | Perlindungan ransomware tidak diaktifkan | Ransomware mengenkripsi data bisnis, yang dapat menyebabkan gangguan layanan, kebocoran data, dan kehilangan data. Mengonfigurasi perlindungan ransomware mengurangi risiko ini. Jika perlindungan ransomware dibeli tetapi tidak ada kebijakan perlindungan yang dibuat, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan Sumber Daya Komputasi | Antivirus tidak diaktifkan | Pemindaian antivirus membersihkan ancaman berbahaya, termasuk ransomware, trojan DDoS, malware penambangan, backdoor, dan cacing. Jika antivirus dibeli untuk Security Center (Edisi Perusahaan atau Ultimate) tetapi tidak ada kebijakan pemindaian berkala yang dikonfigurasi, konfigurasinya dianggap tidak sesuai. | Perbaikan ini mengonfigurasi pemindaian virus berkala di Security Center. Setelah perbaikan diterapkan, pemindaian berjalan di semua server yang memenuhi syarat sesuai interval dan jendela waktu yang dikonfigurasi. Peringatan virus muncul di modul peringatan keamanan. Anda harus segera menanganinya untuk memastikan keamanan server. | Tidak |
Perlindungan resource komputasi | Pemindaian gambar kontainer tidak dikonfigurasi | Gambar dengan kerentanan sistem atau aplikasi, atau gambar yang telah diganti dengan versi berbahaya, dapat memperkenalkan risiko. Memindai gambar di registri membantu tim keamanan mendorong temuan kepada pengembang untuk remediasi. Jika pemindaian gambar dibeli tetapi tidak ada cakupan pemindaian yang dikonfigurasi, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan runtime aplikasi | Situs ESA tidak memiliki aturan terkelola WAF yang dikonfigurasi | Pemeriksaan ini memverifikasi bahwa situs memiliki aturan terkelola WAF untuk melindungi aplikasi web dan API dengan lebih baik. Jika tidak ada aturan terkelola yang dikonfigurasi, konfigurasi tidak sesuai dengan praktik terbaik Perlindungan Aplikasi Web. | Aturan terkelola adalah aturan cerdas bawaan untuk ESA. Aturan ini melindungi terhadap serangan OWASP dan kerentanan origin yang muncul. Perbaikan ini mengaktifkan set aturan terkelola untuk situs ESA yang dipilih. Ketersediaan aturan bervariasi berdasarkan edisi. Untuk informasi lebih lanjut, lihat fitur yang didukung berdasarkan edisi. | Tidak |
Perlindungan runtime aplikasi | Situs ESA tidak memiliki aturan kustom WAF yang dikonfigurasi | Pemeriksaan ini memverifikasi bahwa situs memiliki aturan kustom WAF untuk mendeteksi dan mengurangi permintaan berbahaya. Jika tidak ada aturan kustom yang dikonfigurasi, konfigurasi tidak sesuai dengan praktik terbaik Perlindungan Aplikasi Web. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan runtime aplikasi | Konfigurasi perlindungan aplikasi tidak dibuat | Deteksi dan perlindungan runtime melindungi aplikasi Java dari kerentanan nol hari. Jika perlindungan aplikasi dibeli tetapi tidak ada konfigurasi atau grup yang ada, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan runtime aplikasi | Web Tamper Protection tidak diaktifkan | Web Tamper Protection memantau direktori atau file situs web secara real-time dan memulihkan konten yang dirusak dari cadangan. Ini mencegah injeksi konten ilegal dan memastikan ketersediaan situs. Jika Web Tamper Protection dibeli tetapi tidak ada server yang diikat, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Respons serangan jaringan | Anti-DDoS Pro atau Anti-DDoS Premium melebihi ambang batas pertahanan (baru di model 3.0) | Jika lalu lintas serangan melebihi bandwidth perlindungan instans Anti-DDoS, instans tersebut masuk ke mode black hole. Semua lalu lintas yang melaluinya diblokir, sehingga layanan tidak dapat diakses. Jika status IP instans Anti-DDoS adalah Black Hole Diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Respons serangan jaringan | Instans ECS melebihi ambang batas pertahanan DDoS (baru di model 3.0) | Jika instans ECS mengalami serangan DDoS volume tinggi yang melebihi bandwidth pertahanannya, kebijakan black hole Alibaba Cloud memblokir lalu lintas antara instans dan Internet untuk mencegah kerusakan lebih luas dan melindungi aset lain. Jika instans ECS dengan Alamat IP Publik Terbuka memiliki status perlindungan DDoS Black Hole Diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Respons serangan jaringan | EIP melebihi ambang batas pertahanan DDoS (baru di model 3.0) | Jika EIP mengalami serangan DDoS volume tinggi yang melebihi bandwidth pertahanannya, kebijakan black hole Alibaba Cloud memblokir lalu lintas antara EIP dan Internet untuk mencegah kerusakan lebih luas dan melindungi aset lain. Jika status perlindungan DDoS EIP adalah Black Hole Diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Respons serangan jaringan | Instans SLB melebihi ambang batas pertahanan DDoS (baru di model 3.0) | Jika instans SLB mengalami serangan DDoS volume tinggi yang melebihi bandwidth pertahanannya, kebijakan black hole Alibaba Cloud memblokir lalu lintas antara instans dan Internet untuk mencegah kerusakan lebih luas dan melindungi aset lain. Jika status perlindungan DDoS instans SLB adalah Black Hole Diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Respons serangan jaringan | Perlindungan DDoS Native tidak memiliki objek yang dilindungi ditambahkan | Setelah Anda membeli Perlindungan DDoS Native atau instans Anti-DDoS, Anda harus menambahkan aset IP publik sebagai objek yang dilindungi untuk mengaktifkan perlindungan DDoS. Tanpa langkah ini, perlindungan tidak efektif dan biaya terbuang sia-sia. | Perbaikan cepat tidak didukung. | Tidak |
Respons serangan jaringan | Perlindungan cerdas berbasis AI untuk situs web diatur ke mode Ketat | Perlindungan cerdas berbasis AI meningkatkan keamanan situs web. Namun, mode Ketat dapat menyebabkan positif palsu. Gunakan mode Ketat hanya untuk situs web dengan kinerja buruk atau perlindungan tidak memadai. Catatan: Domain situs web memiliki perlindungan serangan Lapisan 4 bawaan. Untuk sebagian besar situs web, gunakan mode Normal untuk menyeimbangkan perlindungan dan kelangsungan bisnis. | Perbaikan ini mengatur perlindungan cerdas berbasis AI ke Mode Blok dengan tingkat keparahan Normal. Anti-DDoS Proxy akan secara otomatis menghasilkan aturan kontrol akses yang akurat dan secara cerdas mempertahankan terhadap serangan berbahaya saat ancaman terdeteksi. | Tidak |
Kontrol akses jaringan | Instans ECS tidak dilarang diikat ke alamat IP publik | Untuk mengurangi risiko serangan, hindari mengekspos instans ECS langsung ke Internet publik. Gunakan NAT Gateway atau Server Load Balancer sebagai gantinya. Jika instans ECS diikat ke alamat IP publik, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Instans Elasticsearch memiliki titik akhir publik yang diaktifkan dan tidak memiliki daftar putih alamat IP | Menampilkan Elasticsearch ke Internet publik menimbulkan risiko keamanan. Elasticsearch menjadi terlihat oleh penyerang dan dapat mengalami kebocoran atau penghancuran data tanpa kontrol akses yang tepat. Sebagai praktik terbaik, izinkan akses hanya dari jaringan internal VPC dan konfigurasikan daftar putih IP yang sesuai. Jika titik akhir publik diaktifkan, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Layanan Kibana instans Elasticsearch memiliki titik akhir publik yang diaktifkan dan tidak memiliki daftar putih alamat IP | Menampilkan Kibana ke Internet publik menimbulkan risiko keamanan. Kibana menjadi terlihat oleh penyerang dan dapat mengalami kebocoran atau penghancuran data tanpa kontrol akses yang tepat. Sebagai praktik terbaik, izinkan akses hanya dari jaringan internal VPC dan konfigurasikan daftar putih IP yang sesuai. Jika titik akhir publik Kibana diaktifkan, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Instans MongoDB memiliki titik akhir publik yang diaktifkan dan tidak memiliki daftar putih alamat IP | Menampilkan database ke Internet publik menimbulkan risiko keamanan. Database menjadi terlihat oleh penyerang dan dapat mengalami kebocoran atau penghancuran data tanpa kontrol akses yang tepat. Sebagai praktik terbaik, izinkan akses hanya dari jaringan internal VPC, konfigurasikan daftar putih IP, dan gunakan kredensial kuat. Jika titik akhir publik diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Klaster PolarDB memiliki titik akhir publik yang dikonfigurasi | Menampilkan database ke Internet publik menimbulkan risiko keamanan. Database menjadi terlihat oleh penyerang dan dapat mengalami kebocoran atau penghancuran data tanpa kontrol akses yang tepat. Sebagai praktik terbaik, izinkan akses hanya dari jaringan internal VPC, konfigurasikan daftar putih IP, dan gunakan kredensial kuat. Jika titik akhir publik diaktifkan, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Instans RDS memiliki titik akhir publik yang diaktifkan dan tidak memiliki daftar putih alamat IP | Menampilkan database ke Internet publik menimbulkan risiko keamanan. Database menjadi terlihat oleh penyerang dan dapat mengalami kebocoran atau penghancuran data tanpa kontrol akses yang tepat. Sebagai praktik terbaik, izinkan akses hanya dari jaringan internal VPC, konfigurasikan daftar putih IP, dan gunakan kredensial kuat. Jika titik akhir publik diaktifkan, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Instans Redis memiliki titik akhir publik yang dikonfigurasi | Menampilkan database ke Internet publik menimbulkan risiko keamanan. Database menjadi terlihat oleh penyerang dan dapat mengalami kebocoran atau penghancuran data tanpa kontrol akses yang tepat. Sebagai praktik terbaik, izinkan akses hanya dari jaringan internal VPC, konfigurasikan daftar putih IP, dan gunakan kredensial kuat. Jika titik akhir publik diaktifkan, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Aturan inbound grup keamanan mengizinkan akses dari 0.0.0.0/0 ke port apa pun | Jangan izinkan semua alamat IP (0.0.0.0/0) mengakses port apa pun. Anda harus membatasi akses ke rentang IP dan port tertentu. Jika aturan inbound grup keamanan mengizinkan akses dari 0.0.0.0/0 tanpa menentukan port, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Instans Tablestore memiliki akses jaringan publik dan klasik yang diaktifkan | Tablestore membuat nama domain publik, nama domain VPC, dan nama domain jaringan klasik untuk setiap instans. Nama domain publik dapat diakses dari Internet. Nama domain jaringan klasik dapat diakses dari instans ECS di wilayah yang sama. Sebagai praktik terbaik, izinkan akses hanya dari konsol atau VPC. Membatasi akses jaringan publik dan klasik meningkatkan isolasi jaringan dan keamanan data. Jika jenis jaringan diatur ke "Hanya Konsol atau VPC" atau "Hanya VPC", konfigurasi sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Server API klaster ACK memiliki titik akhir publik yang diaktifkan (baru di model 3.0) | Mengaktifkan titik akhir publik untuk klaster ACK meningkatkan risiko serangan pada resource seperti pod, layanan, dan pengontrol replika. Jangan aktifkan titik akhir publik. Jika titik akhir publik diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Jenis jaringan template peluncuran ECS diatur ke jaringan klasik (baru di model 3.0) | Jaringan klasik tidak menawarkan isolasi jaringan antar pengguna. Beberapa penyewa berbagi pool IP yang sama, dan pengguna tidak dapat menyesuaikan topologi jaringan atau alamat IP. Kerentanan dalam aplikasi jaringan klasik dapat mengeksposnya ke penyewa lain. Virtual Private Cloud (VPC) menyediakan keamanan yang lebih kuat. Untuk organisasi yang memprioritaskan keamanan data, VPC adalah pilihan yang lebih baik. Jika template peluncuran ECS menggunakan jaringan klasik, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Node master klaster EMR memiliki titik akhir publik yang diaktifkan (baru di model 3.0) | Menetapkan alamat IP publik ke node master EMR meningkatkan eksposurnya terhadap serangan. Penyerang dapat memindai, menyusup, atau melakukan tindakan berbahaya lainnya, yang mengancam seluruh klaster. Jika titik akhir publik diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Aturan inbound grup keamanan yang terkait dengan grup penskalaan ESS mengizinkan akses dari 0.0.0.0/0 ke port apa pun (baru di model 3.0) | Saat aktivitas penskalaan dipicu, Auto Scaling membuat instans ECS menggunakan konfigurasi penskalaan. Jika aturan inbound grup keamanan yang terkait mengizinkan semua alamat IP (0.0.0.0/0) di port apa pun, instans baru menghadapi risiko keamanan. Jika aturan tersebut ada, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Proyek MaxCompute tidak memiliki daftar putih alamat IP (baru di model 3.0) | Dengan daftar putih alamat IP, hanya perangkat yang terdaftar yang dapat mengakses proyek. Tanpa daftar putih, perangkat apa pun yang menggunakan titik akhir publik dapat mengakses proyek, yang menimbulkan risiko eksposur. Jika proyek mengizinkan akses jaringan eksternal tanpa daftar putih alamat IP, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses jaringan | Grup keamanan mengekspos port berisiko tinggi (22, 3389, dll.) ke Internet publik | Jangan izinkan akses Internet publik ke port berisiko tinggi seperti SSH (22) dan RDP (3389) untuk mencegah serangan dan akses tidak sah. Jika port tersebut diekspos, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Instans NAT Gateway tidak sepenuhnya dilindungi oleh Firewall Batas NAT | Untuk mengurangi eksposur jaringan pribadi ke Internet publik, semua instans NAT Gateway harus dilindungi oleh Firewall Batas NAT Cloud Firewall. Jika Cloud Firewall digunakan tetapi beberapa NAT Gateway tidak memiliki perlindungan, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Lalu lintas antar-VPC tidak sepenuhnya dilindungi oleh Firewall Batas VPC | Semua lalu lintas antar-VPC harus melewati Firewall Batas VPC Cloud Firewall untuk mengurangi risiko lalu lintas internal. Jika Cloud Firewall digunakan tetapi beberapa lalu lintas antar-VPC tidak memiliki perlindungan, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Sistem pencegahan intrusi (IPS) Cloud Firewall tidak memiliki perlindungan dasar yang diaktifkan | Aktifkan perlindungan dasar di sistem pencegahan intrusi (IPS) Cloud Firewall. Ini menyediakan perlindungan dasar, termasuk memblokir serangan brute-force, eksploitasi eksekusi perintah, dan komunikasi C&C. Jika Cloud Firewall digunakan tetapi perlindungan dasar dinonaktifkan, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Sistem pencegahan intrusi (IPS) Cloud Firewall tidak memiliki intelijen ancaman yang diaktifkan | Aktifkan intelijen ancaman di IPS Cloud Firewall untuk memindai ancaman dan memblokir aktivitas berbahaya. Jika Cloud Firewall digunakan tetapi intelijen ancaman dinonaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Sistem pencegahan intrusi (IPS) Cloud Firewall tidak memiliki Mode Blok yang diaktifkan | Konfigurasikan IPS Cloud Firewall dalam Mode Blok untuk mencegat lalu lintas berbahaya dan menghentikan intrusi. Jika Cloud Firewall digunakan tetapi Mode Blok dinonaktifkan, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan ini mengaktifkan Mode Blok untuk mesin ancaman. Tingkat keparahan default adalah Sedang. | Tidak |
Perlindungan jaringan | Sistem pencegahan intrusi (IPS) Cloud Firewall tidak memiliki pembenahan virtual yang diaktifkan | Aktifkan pembenahan virtual di IPS Cloud Firewall. Ini menyediakan perlindungan real-time terhadap kerentanan kritis dan darurat di lapisan jaringan, yang mencegah eksploitasi tanpa mengganggu layanan. Jika Cloud Firewall digunakan tetapi pembenahan virtual dinonaktifkan, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Cloud Firewall memiliki otorisasi yang tersedia tidak mencukupi | Pemeriksaan ini memverifikasi bahwa jumlah otorisasi Cloud Firewall mencukupi. Jika Cloud Firewall digunakan tetapi jumlah aset IP publik yang tidak dilindungi melebihi jumlah otorisasi yang tersedia, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Cloud Firewall tidak memiliki kebijakan deny default yang dikonfigurasi | Untuk keamanan jaringan, konfigurasikan kebijakan deny default (kebijakan IPv4 dengan sumber dan tujuan diatur ke 0.0.0.0/0 dan tindakan diatur ke Deny). Ini memblokir semua lalu lintas kecuali lalu lintas tepercaya yang secara eksplisit diizinkan. Jika Cloud Firewall digunakan tetapi tidak ada kebijakan deny default yang dikonfigurasi, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Cloud Firewall tidak melindungi semua aset IP publik | Pemeriksaan ini memverifikasi bahwa semua aset IP publik dilindungi oleh Cloud Firewall. Jika Cloud Firewall digunakan tetapi beberapa aset IP publik tidak memiliki perlindungan Firewall Batas Internet, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Cloud Firewall tidak memiliki kebijakan daftar kontrol akses (ACL) yang dikonfigurasi | Setelah Anda mengaktifkan firewall, jika tidak ada kebijakan ACL yang dikonfigurasi, Cloud Firewall default mengizinkan semua lalu lintas. Anda harus mengonfigurasi kebijakan ACL untuk mengontrol akses tidak sah. Jika Cloud Firewall digunakan tetapi tidak ada kebijakan ACL, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Bandwidth perlindungan Cloud Firewall tidak mencukupi | Pemeriksaan ini memverifikasi bahwa bandwidth perlindungan Cloud Firewall mencukupi. Jika Cloud Firewall digunakan tetapi bandwidth puncak dalam 30 hari terakhir melebihi bandwidth yang dibeli, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan jaringan | Cloud Firewall tidak digunakan untuk melindungi lalu lintas jaringan | Cloud Firewall adalah firewall berbasis SaaS yang menyediakan isolasi keamanan terpadu untuk batas Internet, batas VPC, dan batas host. Ini adalah lini pertahanan pertama untuk beban kerja cloud. Jika Cloud Firewall tidak digunakan, konfigurasi tidak sesuai dengan praktik keamanan jaringan terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses data | Bucket OSS memiliki izin tulis-publik yang diaktifkan | OSS mendukung akses publik menggunakan kebijakan bucket dan ACL. Tulis-publik berarti siapa saja dapat memodifikasi atau mengunggah objek tanpa izin atau autentikasi. Hal ini berisiko kebocoran data dan akses berbahaya yang dapat menyebabkan biaya tinggi. Sebagai praktik terbaik, nonaktifkan izin tulis-publik. Akses data OSS hanya menggunakan URL yang ditandatangani atau API. Jika kebijakan bucket atau ACL berisi semantik tulis-publik, bucket berisiko dan tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses data | Bucket OSS memiliki aturan akses akun anonim | Menerapkan prinsip hak istimewa minimal mengurangi risiko keamanan dan membatasi dampak kesalahan atau perilaku berbahaya. Jika kebijakan bucket OSS mengizinkan akses anonim, penyerang dapat mengekstraksi data. Jika akun eksternal dikompromikan, data Anda dapat diubah atau dihapus, yang mengancam integritas, kerahasiaan, dan kelangsungan bisnis. Sebagai praktik terbaik, blokir akses anonim menggunakan kebijakan. Jika kebijakan bucket memberikan akses ke * (semua akun) dengan efek Allow, tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses data | Bucket OSS memiliki aturan akses untuk akun di luar organisasi | Pastikan bucket OSS hanya dapat diakses oleh akun internal untuk mencegah kebocoran data. Jika kebijakan otorisasi bucket mengizinkan akun eksternal, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kontrol akses data | Bucket OSS memiliki izin baca-publik yang diaktifkan | Cegah akses baca publik ke konten bucket OSS untuk memastikan kerahasiaan dan keamanan data. Jika izin baca-publik diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Sertifikat server SLB berisiko kedaluwarsa | Pastikan sertifikat server SLB tidak kedaluwarsa dalam 15 hari untuk menghindari kegagalan enkripsi. Jika masa berlaku tersisa 15 hari atau kurang, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | API di API Gateway dengan titik akhir publik tidak memiliki HTTPS yang dikonfigurasi | Hanya menggunakan HTTP untuk API publik menimbulkan risiko keamanan data. HTTP mengirimkan data dalam teks biasa, yang memungkinkan penyerang melihat informasi sensitif seperti kredensial dan data pribadi. Sebagai praktik terbaik, gunakan HTTPS untuk API publik dan paksa pengalihan HTTP-ke-HTTPS untuk memastikan transmisi terenkripsi. Jika domain API Gateway tidak memiliki HTTPS yang dikonfigurasi, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Sertifikat SSL CDN mendekati kedaluwarsa (baru di model 3.0) | Pastikan sertifikat SSL/TLS yang terikat domain tetap valid untuk menghindari risiko keamanan dan gangguan layanan. Jika sertifikat CDN kedaluwarsa dalam kurang dari 15 hari, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Domain CDN tidak memiliki pengalihan paksa HTTP-ke-HTTPS yang dikonfigurasi | Hanya menggunakan HTTP untuk domain CDN menimbulkan risiko keamanan data. HTTP mengirimkan data dalam teks biasa, yang memungkinkan penyerang melihat informasi sensitif seperti kredensial dan data pribadi. Sebagai praktik terbaik, gunakan HTTPS untuk domain CDN dan paksa pengalihan HTTP-ke-HTTPS untuk memastikan transmisi terenkripsi. Jika tipe pengalihan paksa domain CDN tidak diatur ke HTTP→HTTPS, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Domain CDN tidak memiliki HTTPS yang dikonfigurasi | Hanya menggunakan HTTP untuk domain CDN menimbulkan risiko keamanan data. HTTP mengirimkan data dalam teks biasa, yang memungkinkan penyerang melihat informasi sensitif seperti kredensial dan data pribadi. Sebagai praktik terbaik, gunakan HTTPS untuk domain CDN dan paksa pengalihan HTTP-ke-HTTPS untuk memastikan transmisi terenkripsi. Jika percepatan aman HTTPS tidak diaktifkan untuk domain CDN, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Instans Elasticsearch tidak menggunakan HTTPS | Hanya menggunakan HTTP untuk Elasticsearch menimbulkan risiko keamanan data. HTTP mengirimkan data dalam teks biasa, yang memungkinkan penyerang melihat informasi sensitif. Sebagai praktik terbaik, gunakan HTTPS untuk mengakses Elasticsearch dari aplikasi atau klien untuk memastikan transmisi terenkripsi. Jika pengaturan jaringan klaster mengaktifkan HTTPS, konfigurasi sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Instans SLB tidak memiliki pendengar HTTPS yang diaktifkan | Pastikan Server Load Balancer (SLB) memiliki pendengar HTTPS yang diaktifkan untuk mengenkripsi data dalam-transit menggunakan TLS. Jika pendengar HTTPS tidak diaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Sertifikat di Layanan Manajemen Sertifikat berisiko kedaluwarsa | Setelah sertifikat SSL kedaluwarsa, klien tidak dapat memverifikasi identitas server, yang menyebabkan kegagalan akses atau peringatan. Pembaruan yang tidak tepat waktu dapat mengurangi ketersediaan layanan, merusak kepercayaan pelanggan, atau menyebabkan kebocoran data. Berikan waktu yang cukup untuk pembaruan guna menghindari gangguan. Jika sertifikat di Layanan Manajemen Sertifikat kedaluwarsa dalam 15 hari atau kurang, konfigurasi tidak sesuai dengan praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Situs ESA tidak memiliki TLS v1.2 yang diaktifkan | Pemeriksaan ini memverifikasi bahwa situs memiliki TLS v1.2 yang diaktifkan untuk meningkatkan keamanan. Jika tidak diaktifkan, konfigurasi tidak sesuai dengan praktik keamanan data dalam-transit terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Situs ESA tidak memiliki HTTP Strict Transport Security (HSTS) yang diaktifkan | Pemeriksaan ini memverifikasi bahwa situs memiliki HSTS yang diaktifkan untuk mengurangi risiko pembajakan kunjungan pertama. Jika tidak diaktifkan, konfigurasi tidak sesuai dengan praktik keamanan data dalam-transit terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data dalam-transit | Situs ESA tidak memiliki HTTPS paksa yang diaktifkan | Pemeriksaan ini memverifikasi bahwa situs memiliki HTTPS paksa yang diaktifkan untuk mengalihkan permintaan HTTP dari klien ke node tepi ESA ke HTTPS. Jika tidak diaktifkan, konfigurasi tidak sesuai dengan praktik keamanan data dalam-transit terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Penyamaran data | Data Security Center tidak memiliki identifikasi data sensitif yang diaktifkan (baru di model 3.0) | Data sensitif mencakup data pelanggan, dokumen teknis, dan informasi pribadi. Data Security Center memindai database untuk data sensitif menggunakan aturan yang telah ditentukan dan jumlah hit. Database yang didukung termasuk MaxCompute, OSS, layanan ApsaraDB (RDS, PolarDB-X, PolarDB, OceanBase, dan Tablestore), dan database yang dikelola sendiri. Jika identifikasi data sensitif dinonaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data saat diam | Klaster PolarDB tidak memiliki enkripsi data transparan (TDE) yang diaktifkan (baru di model 3.0) | TDE melakukan enkripsi dan dekripsi I/O real-time pada file data. Data dienkripsi sebelum ditulis ke disk dan didekripsi saat dibaca ke memori. Jika TDE dinonaktifkan untuk PolarDB, dapat terjadi kebocoran data, akses tidak sah, atau perusakan. Jika TDE dinonaktifkan, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Perlindungan data saat diam | Instans RDS tidak memiliki enkripsi data transparan (TDE) yang diaktifkan (baru di model 3.0) | Gunakan TDE untuk enkripsi dan dekripsi I/O real-time dalam skenario yang sesuai dengan keamanan atau enkripsi data saat diam. TDE mengenkripsi data di lapisan database, yang mencegah penyerang membaca data sensitif langsung dari penyimpanan. Jika TDE dinonaktifkan untuk RDS, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Respons dan pemulihan insiden keamanan | Security Center memiliki peringatan tertunda | Peringatan keamanan menunjukkan ancaman yang terdeteksi oleh Security Center pada server atau produk cloud Anda. Jenis peringatan meliputi Perlindungan Tamper Web, proses abnormal, webshell, login abnormal, dan proses berbahaya. Menangani peringatan meningkatkan postur keamanan Anda. Jika ada peringatan tertunda, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Respons dan pemulihan insiden keamanan | Security Center tidak digunakan untuk perlindungan keamanan (baru di model 3.0) | Aset cloud menghadapi ancaman seperti virus, serangan siber, ransomware, dan eksploitasi kerentanan. Security Center menyediakan manajemen aset, pemeriksaan konfigurasi, dan pertahanan proaktif. Anda harus membeli layanan keamanan yang sesuai untuk membangun sistem pertahanan. Jika edisi Security Center Dasar atau lebih rendah, konfigurasinya dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Stabilitas
Kategori | Item pemeriksaan | Periksa deskripsi item | Deskripsi perbaikan cepat | Mendukung pengambilan keputusan terbantu |
Jenis instans | Klaster ACK menggunakan Edisi Dasar klaster yang dikelola | Klaster yang dikelola ACK dibagi menjadi Edisi Dasar dan Edisi Pro. Edisi Pro lebih meningkatkan keandalan, keamanan, dan penjadwalan klaster dibandingkan Edisi Dasar, yang membuatnya lebih cocok untuk menjalankan layanan skala besar di lingkungan produksi. Akun dianggap tidak sesuai jika tidak menggunakan Edisi Pro dari tipe klaster yang dikelola. | Perbaikan cepat tidak didukung. | Tidak |
Jenis instans | Instans ECS menggunakan tipe instans bersama atau yang telah dihentikan | Menggunakan tipe instans bersama atau yang telah dihentikan untuk instans ECS tidak dapat menjamin kinerja komputasi yang stabil. Menggunakan keluarga instans ECS bersama atau yang telah dihentikan dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Jenis instans | Instans Elasticsearch menggunakan tipe instans pengembangan dan pengujian | Instans Elasticsearch dengan 1 core dan 2 GB memori hanya cocok untuk skenario pengujian dan tidak untuk lingkungan produksi. Menggunakan instans Elasticsearch dengan 1 core dan 2 GB memori dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Jenis instans | Instans MongoDB menggunakan tipe instans node tunggal | Saat MongoDB menggunakan arsitektur node tunggal, waktu pemulihan kesalahan panjang dan tidak ada jaminan SLA. Menggunakan instans MongoDB yang bukan multi-zona dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Jenis instans | Instans RDS menggunakan tipe instans seri Dasar | Instans seri Dasar RDS hanya memiliki satu node database dan tidak memiliki node sekunder sebagai cadangan panas. Oleh karena itu, saat node gagal secara tak terduga atau melakukan tugas seperti me-restart instans, mengubah konfigurasi, atau meningkatkan versi, instans akan tidak tersedia untuk waktu yang lama. Pada saat yang sama, tipe instans bersama dan tujuan umum dalam keluarga instans RDS berbagi resource dengan instans lain pada mesin fisik yang sama dan hanya cocok untuk skenario aplikasi dengan persyaratan stabilitas rendah. Jika bisnis memiliki persyaratan ketersediaan tinggi untuk database, disarankan untuk menggunakan seri Ketersediaan-Tinggi/Klaster untuk seri produk dan tipe Dedicated untuk keluarga instans. Instans RDS dianggap tidak sesuai jika seri produk RDS tidak menggunakan seri Ketersediaan-Tinggi/Klaster, atau keluarga instans RDS tidak menggunakan tipe Dedicated. | Perbaikan cepat tidak didukung. | Tidak |
Jenis instans | Instans Redis menggunakan tipe instans edisi open source | Redis Enterprise Edition menyediakan kinerja yang lebih kuat, struktur data lebih banyak, dan metode penyimpanan lebih fleksibel. Tidak menggunakan Redis Enterprise Edition dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Jenis instans | Instans ApsaraMQ for RocketMQ menggunakan tipe instans Edisi Standar | Edisi Standar ApsaraMQ for RocketMQ menggunakan instans bersama dan tidak disarankan untuk digunakan di lingkungan produksi. Menggunakan edisi bersama instans RocketMQ dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Klaster ACK menggunakan versi Kubernetes yang telah kedaluwarsa | Komunitas Kubernetes merilis versi minor kira-kira setiap 4 bulan. Kami merekomendasikan menggunakan versi yang masih dalam pemeliharaan. Klaster versi kedaluwarsa memiliki risiko keamanan dan stabilitas. Setelah versi klaster kedaluwarsa, Anda tidak dapat menikmati fitur dan perbaikan bug yang didukung oleh versi Kubernetes baru, menerima dukungan teknis yang tepat dan efektif, atau memperbaiki kerentanan keamanan. Menggunakan versi klaster ACK yang masih dalam pemeliharaan dianggap sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Instans ECS menggunakan versi OS yang telah kedaluwarsa | Menggunakan versi OS yang tidak lagi didukung untuk instans ECS dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Instans Elasticsearch menggunakan versi yang tidak direkomendasikan | Instans Elasticsearch dianggap tidak sesuai jika versi yang digunakan tidak berada dalam rentang versi yang direkomendasikan secara resmi. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Versi mesin MSE terlalu rendah | Menggunakan versi mesin MSE terbaru adalah kunci untuk memastikan kelangsungan layanan MSE. Jika versi mesin terlalu rendah, dapat menyebabkan masalah seperti cacat kode yang menyebabkan GC tidak dikembalikan, overflow memori yang menyebabkan pertumbuhan memori terus-menerus, kecepatan startup lambat, dan cacat serialisasi JSON. Akun dianggap tidak sesuai jika versi mesin MSE-ZooKeeper atau MSE-ANS atau versi klien MSE-ANS terlalu rendah. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Versi gateway MSE-Ingress terlalu rendah | Menggunakan versi Ingress terbaru adalah kunci untuk memastikan kelangsungan layanan gateway. Jika versi terlalu rendah, dapat menyebabkan masalah seperti risiko keamanan atau stabilitas, dan dapat menyebabkan daftar instans yang tidak akurat untuk berlangganan layanan Nacos. Akun dianggap tidak sesuai jika versi MSE-Ingress terlalu rendah. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Versi utama database MySQL instans RDS terlalu rendah (Baru di Model 3.0) | Menggunakan versi MySQL yang siklus hidupnya telah berhenti atau akan segera berhenti mengekspos sistem ke masalah seperti risiko keamanan, hambatan kinerja, masalah kompatibilitas, dan kurangnya dukungan teknis. Meningkatkan ke versi MySQL yang didukung secara tepat waktu dapat memberikan patch keamanan terbaru, peningkatan kinerja, dan peningkatan fitur, yang mengurangi risiko O&M dan meningkatkan keandalan sistem secara keseluruhan. Instans RDS dianggap tidak sesuai jika menggunakan versi 5.5 atau 5.6. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Fungsi Function Compute (FC) 2.0 menggunakan runtime yang telah ditinggalkan (Baru di Model 3.0) | Saat versi runtime beriterasi, Function Compute berhenti memelihara beberapa runtime dan tidak lagi menyediakan dukungan teknis atau pembaruan keamanan untuknya. Kami merekomendasikan migrasi fungsi ke runtime terbaru yang didukung untuk mendapatkan dukungan teknis dan pembaruan keamanan. Fungsi FC 2.0 dianggap tidak sesuai jika menggunakan salah satu runtime berikut: nodejs12, nodejs10, nodejs8, dotnetcore2.1, python2.7, nodejs6, atau nodejs4.4. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Pemeriksaan klaster ACK menemukan bahwa versi komponen Kubelet pada node tertinggal dari lapisan kontrol (Baru di Model 3.0) | Jika versi komponen Kubelet pada node klaster ACK tertinggal dari lapisan kontrol, dapat menyebabkan masalah kompatibilitas. Lapisan kontrol, seperti API Server, mungkin tidak dapat berkomunikasi dengan Kubelet versi lama karena fitur baru atau peningkatan protokol. Hal ini dapat menyebabkan status node abnormal, kegagalan penjadwalan Pod, atau node ditandai sebagai tidak tersedia. Selain itu, versi Kubelet yang lama mungkin berisi kerentanan keamanan yang belum diperbaiki, yang meningkatkan risiko serangan pada node dan menghambat kemampuan pembaruan klaster secara keseluruhan. Untuk memulihkan stabilitas komunikasi dan menghilangkan risiko keamanan, Anda harus meningkatkan Kubelet ke versi yang kompatibel. Node dengan versi Kubelet yang tertinggal dari lapisan kontrol dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Versi stabil | Database klaster PolarDB tidak menggunakan versi minor yang stabil | Database PolarDB dianggap tidak sesuai jika status versi minornya bukan Stabil atau Beta. | Perbaikan ini mengaktifkan peningkatan otomatis versi minor untuk instans yang ditentukan. Saat versi mesin minor Anda lebih rendah dari versi mesin minor terbaru, sistem secara berkala mengeluarkan tugas O&M aktif untuk meningkatkan versi mesin minor. Operasi peningkatan otomatis dilakukan dalam jendela pemeliharaan yang Anda tetapkan. Selama proses peningkatan, proksi database (PolarProxy) atau mesin kernel (DB) di-restart, yang dapat menyebabkan koneksi sementara. Lakukan operasi peningkatan selama jam sepi dan pastikan aplikasi Anda memiliki mekanisme koneksi ulang otomatis. | Tidak |
Versi stabil | Instans RDS tidak memiliki peningkatan otomatis versi mesin minor yang diaktifkan (Baru di Model 3.0) | ApsaraDB RDS mendukung peningkatan otomatis atau manual versi mesin minor. Saat versi mesin minor lebih rendah dari versi mesin minor terbaru, sistem secara berkala mengeluarkan tugas O&M aktif untuk meningkatkan versi mesin minor. Instans mendapatkan versi terbaru termasuk peningkatan kinerja, dukungan fitur baru, dan perbaikan masalah keamanan, yang dapat memastikan optimasi dan keamanan layanan database secara berkelanjutan. Instans RDS dianggap tidak sesuai jika tidak memiliki peningkatan otomatis versi mesin minor yang diaktifkan. | Perbaikan ini secara otomatis mengaktifkan peningkatan otomatis versi mesin minor untuk instans RDS yang dipilih. Saat versi mesin minor instans RDS lebih rendah dari versi mesin minor terbaru, sistem secara berkala mengeluarkan tugas O&M aktif untuk meningkatkan versi mesin minor. Operasi peningkatan otomatis dilakukan dalam jendela pemeliharaan yang Anda tetapkan. Informasi tugas peningkatan yang dikeluarkan oleh sistem diberitahukan melalui saluran seperti pesan teks dan email yang ditetapkan di Pusat Pesan. | Tidak |
Versi stabil | Instans Redis belum ditingkatkan ke versi minor terbaru | Instans Redis dianggap tidak sesuai jika belum ditingkatkan ke versi minor terbaru. | Perbaikan ini mengaktifkan peningkatan otomatis versi minor untuk instans yang dipilih. Setelah diaktifkan, sistem secara berkala memeriksa status rilis versi. Jika versi baru ditemukan, versi tersebut ditingkatkan secara otomatis dalam periode yang dapat ditingkatkan 60 hari. Saat meningkatkan versi database, instans terlebih dahulu meningkatkan instans sekunder (Replica) atau menyiapkan instans baru. Pada waktu eksekusi yang ditentukan, dilakukan alih bencana primer/sekunder atau alih bencana instans untuk menyelesaikan operasi peningkatan. Selama fase alih bencana instans, instans berada dalam keadaan read-only hingga 60 detik sambil menunggu data disinkronkan sepenuhnya, dan terjadi koneksi sementara selama beberapa detik. Pastikan aplikasi Anda memiliki mekanisme koneksi ulang. | Tidak |
Risiko kedaluwarsa | Instans AnalyticDB for MySQL Edisi Gudang Data berisiko kedaluwarsa | Instans AnalyticDB for MySQL Edisi Gudang Data dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan ADB yang dipilih Anda. | Tidak |
Risiko kedaluwarsa | Instans Anti-DDoS berisiko kedaluwarsa | Instans DDoS dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu saat ini dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan DDoSCOO yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans ECS berisiko kedaluwarsa | Instans langganan ECS dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan ECS yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans EIP berisiko kedaluwarsa | Instans langganan EIP dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan EIP yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans KMS berisiko kedaluwarsa (Baru di Model 3.0) | Pastikan pembaruan tepat waktu untuk instans langganan KMS untuk menghindari gangguan bisnis akibat kedaluwarsa. Instans langganan KMS dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan KMS yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans MongoDB berisiko kedaluwarsa | Instans langganan MongoDB dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan MongoDB yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Klaster PolarDB berisiko kedaluwarsa | Instans langganan PolarDB dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan PolarDB yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans PolarDB-X berisiko kedaluwarsa | Instans PolarDB-X 1.0 atau PolarDB-X 2.0 dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu saat ini dan perpanjangan otomatis tidak diaktifkan. | Perbaikan cepat tidak didukung. | Tidak |
Risiko kedaluwarsa | Instans RDS berisiko kedaluwarsa | Instans langganan RDS dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan RDS yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans Redis berisiko kedaluwarsa | Instans langganan Redis dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan Redis yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans SLB berisiko kedaluwarsa | Instans langganan SLB dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan SLB yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Gateway VPN berisiko kedaluwarsa (Baru di Model 3.0) | Pastikan pembaruan tepat waktu untuk instans langganan Gateway VPN untuk menghindari gangguan bisnis akibat kedaluwarsa. Instans langganan Gateway VPN dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan VPN yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Paket bandwidth CEN berisiko kedaluwarsa | Paket bandwidth Cloud Enterprise Network dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu saat ini dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan CEN yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans bandwidth bersama berisiko kedaluwarsa | Instans bandwidth bersama dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu saat ini dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource CBWP yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Risiko kedaluwarsa | Instans Bastionhost berisiko kedaluwarsa | Instans Bastionhost dianggap tidak sesuai jika akan kedaluwarsa dalam kurang dari 7 hari dari waktu pemeriksaan dan perpanjangan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan perpanjangan otomatis untuk resource instans langganan Bastionhost yang dipilih Anda. Setelah perpanjangan otomatis diaktifkan, fitur ini berlaku mulai hari berikutnya. Aktifkan perpanjangan otomatis setidaknya 2 hari sebelum instans langganan kedaluwarsa. Jika instans Anda akan kedaluwarsa besok, kami sarankan Anda pergi ke konsol produk untuk memperbarui secara manual. Siklus perpanjangan otomatis didasarkan pada durasi perpanjangan otomatis yang ditetapkan. Misalnya, jika Anda memilih durasi perpanjangan 1 bulan, instans diperbarui secara otomatis selama 1 bulan sebelum setiap kedaluwarsa. Pastikan saldo akun, kupon tunai, atau metode pembayaran lainnya cukup untuk menutupi jumlah perpanjangan. | Tidak |
Perlindungan penghapusan | Perlindungan penghapusan tidak diaktifkan untuk klaster ACK | Klaster ACK dianggap tidak sesuai jika perlindungan penghapusan tidak diaktifkan. | Perbaikan ini mengaktifkan perlindungan penghapusan untuk resource yang dipilih. Resource tidak dapat dilepas melalui konsol, API, atau command line. Untuk melepas instans, pertama-tama buka halaman detail instans untuk mematikan sakelar perlindungan penghapusan. | Tidak |
Perlindungan penghapusan | Perlindungan penghapusan tidak diaktifkan untuk instans ALB | Instans ALB dianggap tidak sesuai jika perlindungan penghapusan tidak diaktifkan. | Perbaikan ini mengaktifkan perlindungan penghapusan untuk resource yang dipilih. Resource tidak dapat dilepas melalui konsol, API, atau command line. Untuk melepas instans, pertama-tama buka halaman detail instans untuk mematikan sakelar perlindungan penghapusan. | Tidak |
Perlindungan penghapusan | Perlindungan penghapusan tidak diaktifkan untuk instans EIP | Instans EIP dianggap tidak sesuai jika perlindungan penghapusan tidak diaktifkan. | Perbaikan ini mengaktifkan perlindungan penghapusan untuk resource yang dipilih. Resource tidak dapat dilepas melalui konsol, API, atau command line. Untuk melepas instans, pertama-tama buka halaman detail instans untuk mematikan sakelar perlindungan penghapusan. | Tidak |
Perlindungan penghapusan | Perlindungan rilis tidak diaktifkan untuk instans MongoDB | Instans MongoDB dianggap tidak sesuai jika perlindungan rilis tidak diaktifkan. | Perbaikan ini mengaktifkan perlindungan penghapusan untuk resource yang dipilih. Resource tidak dapat dilepas melalui konsol, API, atau command line. Untuk melepas instans, pertama-tama buka halaman detail instans untuk mematikan sakelar perlindungan penghapusan. | Tidak |
Perlindungan penghapusan | Kunci klaster tidak diaktifkan untuk klaster PolarDB | Instans PolarDB dianggap tidak sesuai jika kunci klaster tidak diaktifkan. | Perbaikan ini mengaktifkan perlindungan penghapusan untuk resource yang dipilih. Resource tidak dapat dilepas melalui konsol, API, atau command line. Untuk melepas instans, pertama-tama buka halaman detail instans untuk mematikan sakelar perlindungan penghapusan. | Tidak |
Perlindungan penghapusan | Perlindungan rilis tidak diaktifkan untuk instans RDS | Instans RDS dianggap tidak sesuai jika perlindungan rilis tidak diaktifkan. | Perbaikan ini mengaktifkan perlindungan penghapusan untuk resource yang dipilih. Resource tidak dapat dilepas melalui konsol, API, atau command line. Untuk melepas instans, pertama-tama buka halaman detail instans untuk mematikan sakelar perlindungan penghapusan. | Tidak |
Perlindungan penghapusan | Perlindungan penghapusan tidak diaktifkan untuk instans SLB | Instans SLB dianggap tidak sesuai jika perlindungan penghapusan tidak diaktifkan. | Perbaikan ini mengaktifkan perlindungan penghapusan untuk resource yang dipilih. Resource tidak dapat dilepas melalui konsol, API, atau command line. Untuk melepas instans, pertama-tama buka halaman detail instans untuk mematikan sakelar perlindungan penghapusan. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa instans CLB yang terikat ke Server API tidak ada (Baru di Model 3.0) | Jika Server API klaster ACK tidak terikat ke instans Classic Load Balancer (CLB), hal ini menyebabkan kurangnya titik masuk lalu lintas untuk layanan API. Klien eksternal seperti kubectl tidak dapat mengakses Server API melalui load balancing, yang sepenuhnya mengganggu manajemen klaster. Komponen klaster seperti kubelet dan pengontrol dapat menyebabkan status node abnormal, kegagalan penjadwalan Pod, dan layanan tidak tersedia karena ketidakmampuan membangun komunikasi yang stabil. Pada saat yang sama, node Server API secara langsung mengekspos alamat IP-nya, kehilangan distribusi lalu lintas dan kemampuan failover, yang menimbulkan risiko titik kegagalan tunggal dan meningkatkan ancaman akses tidak sah atau serangan DDoS. Instans CLB harus segera dibuat dan diikat untuk memulihkan ketersediaan tinggi dan akses aman. Klaster ACK dianggap tidak sesuai jika Server API-nya tidak terikat ke instans CLB. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa instans CLB yang terikat ke Server API berada dalam keadaan abnormal (Baru di Model 3.0) | Jika instans CLB yang terikat ke Server API klaster ACK berada dalam keadaan abnormal, hal ini menyebabkan kegagalan penerusan lalu lintas layanan API. Klien seperti kubectl tidak dapat membangun koneksi yang stabil, yang sepenuhnya memblokir manajemen klaster. Komponen internal seperti kubelet dan pengontrol menyebabkan status node abnormal, stagnasi penjadwalan Pod, dan layanan tidak tersedia karena gangguan komunikasi. Pada saat yang sama, kegagalan pemeriksaan kesehatan CLB dapat menyebabkan lalu lintas terkonsentrasi pada node yang rusak, yang memperburuk risiko titik kegagalan tunggal. Jika keadaan abnormal disertai dengan kesalahan konfigurasi keamanan seperti tidak ada enkripsi atau port yang terbuka, hal ini dapat menyebabkan akses tidak sah atau serangan man-in-the-middle. Status kesehatan CLB harus segera diperbaiki dan kebijakan keamanan diverifikasi untuk menghindari kelumpuhan klaster dan pelanggaran data. Klaster ACK dianggap tidak sesuai jika instans CLB yang terikat ke Server API-nya berada dalam keadaan abnormal. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa konfigurasi pendengar port CLB yang terikat ke Server API abnormal (Baru di Model 3.0) | Jika konfigurasi pendengar port CLB yang terikat ke Server API klaster ACK abnormal, hal ini menyebabkan gangguan akses layanan API. Klien seperti kubectl tidak dapat terhubung ke klaster, dan operasi O&M sepenuhnya gagal. Pada saat yang sama, komponen internal seperti kubelet dan pengontrol menyebabkan status node abnormal, kegagalan penjadwalan Pod, dan layanan tidak tersedia karena ketidakmampuan berkomunikasi dengan Server API. Jika protokol pendengar salah atau pembatasan grup keamanan tidak ada, hal ini dapat menyebabkan risiko akses tidak sah atau pembajakan lalu lintas. Konfigurasi port pendengar harus segera diperbaiki, dan jenis protokol serta kebijakan keamanan diverifikasi untuk menghindari kelumpuhan klaster dan pelanggaran data. Klaster ACK dianggap tidak sesuai jika konfigurasi pendengar port CLB yang terikat ke Server API-nya abnormal. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa jumlah server backend untuk layanan CoreDNS adalah 0 (Baru di Model 3.0) | Jika jumlah server backend untuk CoreDNS di klaster ACK adalah 0, hal ini menyebabkan kegagalan penemuan layanan sepenuhnya. Komunikasi antar-layanan dalam klaster, seperti panggilan layanan mikro dan akses database, terputus, dan aplikasi tidak dapat menyelesaikan alamat melalui nama layanan, yang secara langsung memengaruhi ketersediaan bisnis. Hal ini juga menyebabkan risiko stabilitas klaster. Klaster ACK dianggap tidak sesuai jika jumlah server backend untuk layanan CoreDNS-nya adalah 0. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Tingkat error 5xx ALB terlalu tinggi (Baru di Model 3.0) | Jika tingkat error 5xx instans ALB terus melebihi ambang batas tertentu selama periode waktu, hal ini menunjukkan bahwa layanan backend sering mengalami error internal. Hal ini dapat disebabkan oleh pengecualian aplikasi, sumber daya tidak mencukupi, kesalahan konfigurasi, atau kegagalan layanan dependen. Hal ini secara langsung menyebabkan penurunan pengalaman pengguna, peningkatan risiko gangguan bisnis, dan memengaruhi stabilitas dan ketersediaan sistem. Instans ALB dianggap tidak sesuai jika tingkat error 5xx-nya lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam rentang waktu tertentu di masa lalu. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Tingkat kegagalan jabat tangan TLS ALB terlalu tinggi (Baru di Model 3.0) | Tingkat kegagalan jabat tangan TLS ALB yang tinggi dapat menunjukkan adanya masalah dalam komunikasi terenkripsi antara klien dan server, seperti kesalahan konfigurasi sertifikat, versi protokol yang tidak kompatibel, suite kunci yang tidak cocok, atau klien menggunakan algoritma enkripsi yang tidak didukung. Hal ini tidak hanya menyebabkan kegagalan akses pengguna dan memengaruhi ketersediaan bisnis, tetapi juga dapat mengekspos kerentanan keamanan dan meningkatkan risiko serangan man-in-the-middle. Instans ALB dianggap tidak sesuai jika tingkat kegagalan jabat tangan TLS-nya lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam rentang waktu tertentu di masa lalu. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Tingkat kegagalan koneksi ALB terlalu tinggi (Baru di Model 3.0) | Tingkat kegagalan koneksi yang tinggi untuk Application Load Balancer (ALB) dapat menunjukkan bahwa layanan backend abnormal, jaringan tidak stabil, atau konfigurasi salah. Hal ini dapat menyebabkan kegagalan akses pengguna, gangguan bisnis, dan penurunan pengalaman pengguna. Dengan memeriksa metrik tingkat kegagalan koneksi ALB, Anda dapat segera menemukan dan menentukan akar penyebab masalah, yang meningkatkan ketersediaan dan stabilitas sistem, mengoptimalkan efisiensi penjadwalan lalu lintas, dan memastikan kelangsungan bisnis dan kualitas layanan. Hal ini memberikan kemampuan pengiriman aplikasi cloud yang lebih andal kepada pelanggan. Instans ALB dianggap tidak sesuai jika tingkat kegagalan koneksi-nya lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam rentang waktu tertentu di masa lalu. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Konfigurasi nama domain origin dalam nama domain CDN abnormal (Baru di Model 3.0) | Jika konfigurasi nama domain origin dalam nama domain CDN tidak ada, hal ini menyebabkan permintaan resource gagal dan memengaruhi fungsi bisnis. Pada saat yang sama, kegagalan pengambilan origin menyebabkan CDN terus mencoba ulang, yang meningkatkan overhead jaringan yang tidak berarti. Nama domain CDN dianggap tidak sesuai jika menggunakan nama domain OSS dalam informasi origin-nya, dan status resource bucket OSS yang sesuai bukan "Dalam Layanan". Nama domain CDN yang tidak menggunakan nama domain OSS sebagai informasi origin tidak termasuk dalam cakupan deteksi. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Nama domain OSS yang dikonfigurasi dalam record CNAME dalam resolusi nama domain DNS abnormal (Baru di Model 3.0) | Jika nama domain OSS yang salah dikonfigurasi dalam record CNAME resolusi nama domain DNS, mengakses resource melalui nama domain tersebut menyebabkan resource gagal dimuat secara normal, yang memengaruhi fungsi bisnis normal. Nama domain DNS dianggap tidak sesuai jika record CNAME dalam DNS dikonfigurasi dengan nama domain OSS, dan bucket OSS yang sesuai bukan "Dalam Layanan". Nama domain DNS yang tidak menggunakan nama domain OSS dalam record CNAME-nya tidak termasuk dalam cakupan deteksi. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Gambar kustom yang dikonfigurasi dalam template peluncuran instans ECS abnormal (Baru di Model 3.0) | Template peluncuran instans adalah alat untuk membuat instans dengan cepat, yang meningkatkan efisiensi dan pengalaman pengguna. Saat gambar kustom yang dikonfigurasi dalam template peluncuran tidak ada, hal ini menyebabkan eksekusi template peluncuran gagal. Template peluncuran instans ECS dianggap tidak sesuai jika gambar kustom yang terkait dengannya bukan resource "Dalam Layanan". | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Load balancer yang terkait dengan grup penskalaan ESS abnormal (Baru di Model 3.0) | Setelah grup penskalaan dikaitkan dengan instans load balancer, apakah grup penskalaan secara otomatis membuat instans atau instans ditambahkan secara manual ke grup penskalaan, instans tersebut secara otomatis ditambahkan ke server backend instans load balancer. Jika load balancer atau grup server load balancer tidak ada, hal ini menyebabkan grup penskalaan gagal melakukan penskalaan. Grup Auto Scaling dianggap tidak sesuai jika Classic Load Balancer atau Application Load Balancer yang terkait dengannya bukan resource "Dalam Layanan". | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Delay antara instans read-only RDS dan instans utama terlalu besar (Baru di Model 3.0) | Instans read-only RDS menggunakan teknologi replikasi berbasis log native MySQL (replikasi asinkron atau replikasi semi-sinkron), sehingga pasti ada latensi sinkronisasi. Latensi menyebabkan inkonsistensi data antara instans read-only dan instans utama, yang menyebabkan masalah bisnis. Selain itu, latensi juga dapat menyebabkan penumpukan log, yang dengan cepat menghabiskan ruang instans read-only. Instans read-only RDS dianggap tidak sesuai jika delay maksimum antara instans tersebut dan instans utama melebihi 60 detik dalam 7 hari. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Jumlah IP yang tersedia dalam instans VPC tidak mencukupi (Baru di Model 3.0) | Pastikan vSwitch VPC memiliki jumlah IP yang tersedia mencukupi untuk menghindari ketidakmampuan memperluas bisnis karena sumber daya tidak mencukupi. vSwitch VPC dianggap tidak sesuai jika jumlah IP IPv4 yang tersedia kurang dari atau sama dengan nilai tertentu (default adalah 10). | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Instans ECS telah dimatikan karena pembayaran tertunda atau larangan keamanan | Matinya instans ECS secara pasif menyebabkan gangguan layanan, kehilangan data, dan inkonsistensi data, serta memengaruhi kinerja sistem atau menimbulkan risiko keamanan. Akun dianggap berisiko jika ada instans ECS di bawah akun saat ini yang telah dimatikan karena pembayaran tertunda atau larangan keamanan. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa status backend instans CLB Server API abnormal (Baru di Model 3.0) | Jika status backend instans CLB Server API klaster ACK abnormal, hal ini menyebabkan komunikasi lapisan kontrol terputus, yang secara langsung menyebabkan kegagalan manajemen klaster sepenuhnya. Klien seperti kubectl tidak dapat mengakses Server API, sehingga tidak mungkin melakukan operasi seperti menerapkan aplikasi dan melihat status. Pada saat yang sama, komponen seperti kubelet dan pengontrol memicu status node abnormal, kegagalan penjadwalan Pod, dan kegagalan mekanisme pemulihan otomatis karena terputus dari Server API. Hal ini kemudian menyebabkan stabilitas klaster runtuh dan layanan bisnis terganggu karena API tidak dapat diakses. Selain itu, alat pemantauan seperti Prometheus tidak dapat mengumpulkan data metrik, sehingga tidak mungkin memberikan peringatan dan pemecahan masalah secara tepat waktu. Yang lebih serius lagi, ketidaktersediaan Server API dalam jangka panjang dapat menyebabkan inkonsistensi antara status klaster dan data yang disimpan di etcd, yang menyebabkan kehilangan data atau anomali operasi. Konfigurasi CLB, status kesehatan node backend, dan konektivitas jaringan harus segera diperiksa untuk memastikan distribusi lalu lintas normal dan menghindari kehancuran klaster sepenuhnya. Klaster ACK dianggap tidak sesuai jika status backend instans CLB Server API-nya abnormal. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa APIService tidak tersedia (Baru di Model 3.0) | Jika APIService klaster ACK tidak tersedia, hal ini menyebabkan fungsi API diperluas gagal. Resource kustom seperti CRD tidak dapat berkomunikasi dengan lapisan kontrol, yang menyebabkan anomali manajemen untuk komponen yang bergantung pada API diperluas, seperti Operator dan service mesh. Permintaan API seperti pembaruan status resource dan pengiriman konfigurasi gagal karena gangguan layanan, yang dapat menyebabkan kehilangan data pemantauan, kegagalan kebijakan otomatis, atau kesalahan perintah manajemen klaster. Jika API diperluas inti seperti Admission Webhooks terpengaruh, hal ini memblokir proses pembuatan resource, yang memperburuk risiko pemblokiran operasi klaster. APIService harus segera dipulihkan untuk menghindari kelumpuhan fungsi kunci dan inkonsistensi data. Klaster ACK dianggap tidak sesuai jika APIService-nya tidak tersedia. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa metode penagihan layanan LoadBalancer tidak konsisten dengan instans aktual (Baru di Model 3.0) | Jika metode penagihan layanan LoadBalancer klaster ACK tidak cocok dengan instans aktual, hal ini menyebabkan anomali penagihan. Hal ini dapat menyebabkan pengiriman tak terduga, seperti bayar sesuai pemakaian alih-alih langganan yang diharapkan, atau pelepasan resource tak terduga, seperti tidak memperbarui langganan saat kedaluwarsa, yang menyebabkan gangguan layanan. Pada saat yang sama, manajemen resource yang kacau mengganggu kebijakan penskalaan otomatis, yang meningkatkan biaya dan risiko O&M. Konfigurasi metode penagihan harus segera dikalibrasi untuk menghindari perbedaan penagihan dan penurunan ketersediaan bisnis. Klaster ACK dianggap tidak sesuai jika metode penagihan layanan LoadBalancer-nya tidak konsisten dengan instans aktual. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa ID instans sertifikat layanan LoadBalancer tidak konsisten dengan instans aktual (Baru di Model 3.0) | Jika ID instans sertifikat layanan LoadBalancer klaster ACK tidak cocok dengan sertifikat yang sebenarnya terikat, hal ini menyebabkan konfigurasi TLS gagal. Hal ini menyebabkan koneksi layanan HTTPS ditolak atau peringatan keamanan, dan gangguan akses pengguna. Sertifikat yang tidak valid dapat mengekspos lalu lintas yang tidak terenkripsi, yang meningkatkan risiko serangan man-in-the-middle. Pada saat yang sama, pemeriksaan kesehatan yang abnormal salah menilai status layanan backend, yang memperburuk kekacauan distribusi lalu lintas. Konfigurasi sertifikat harus segera disinkronkan untuk memulihkan komunikasi aman dan ketersediaan layanan. Klaster ACK dianggap tidak sesuai jika ID instans sertifikat layanan LoadBalancer-nya tidak konsisten dengan instans aktual. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan Pod CoreDNS abnormal (Baru di Model 3.0) | Pod CoreDNS yang abnormal di klaster ACK menyebabkan layanan resolusi DNS tidak stabil. Komunikasi antar-layanan melalui nama domain dapat mengalami timeout atau gagal, yang menyebabkan gangguan panggilan aplikasi. Pod yang abnormal dapat memicu pengontrol untuk me-restart terus-menerus, yang meningkatkan beban pada lapisan kontrol dan menghabiskan resource node tanpa memberikan layanan yang efektif. Jika Pod abnormal karena kesalahan konfigurasi atau kerentanan gambar, hal ini dapat menyebabkan pembajakan DNS atau polusi resolusi, yang menyebabkan kesalahan routing layanan atau pelanggaran data. Status Pod harus segera diperiksa dan konfigurasi diperbaiki untuk memulihkan keandalan layanan DNS. Klaster ACK dianggap tidak sesuai jika ada Pod CoreDNS yang abnormal. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa status komponen elastis abnormal (Baru di Model 3.0) | Jika status komponen elastis klaster ACK abnormal, hal ini menyebabkan mekanisme seperti penskalaan otomatis dan pemulihan kesalahan otomatis gagal. Tidak dapat melakukan penskalaan otomatis selama beban tinggi, yang menyebabkan hambatan resource, keterlambatan respons layanan, atau gangguan. Tidak dapat secara otomatis mengganti node atau Pod yang rusak, yang memperburuk risiko ketersediaan. Pada saat yang sama, klaster tidak dapat mengoptimalkan alokasi resource sesuai kebijakan, yang mengakibatkan pemborosan biaya atau penurunan efisiensi O&M. Dalam jangka panjang, hal ini dapat memblokir proses bisnis utama. Status komponen elastis harus segera diperbaiki untuk memulihkan kemampuan adaptif klaster. Klaster ACK dianggap tidak sesuai jika status komponen elastisnya abnormal. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa vSwitch kolam node tidak tersedia (Baru di Model 3.0) | Jika vSwitch kolam node klaster ACK tidak tersedia, hal ini menyebabkan komunikasi jaringan antar-node terputus. Pod dan layanan tidak dapat berinteraksi lintas node, yang menyebabkan kegagalan penemuan layanan atau stagnasi transmisi data. Komunikasi antara lapisan kontrol dan node pekerja terputus, dan node ditandai sebagai tidak tersedia, yang dapat memicu eviction yang salah atau pengurangan ukuran klaster yang abnormal. Pada saat yang sama, node tidak dapat mengakses penyimpanan eksternal, database, dan resource lainnya, yang menyebabkan fungsi aplikasi lumpuh. Risiko partisi jaringan diperburuk, yang dapat menyebabkan split-brain klaster atau inkonsistensi data. Dari perspektif O&M, tidak mungkin menentukan kesalahan secara tepat waktu karena gangguan data pemantauan. Layanan vSwitch harus segera dipulihkan untuk memastikan konektivitas jaringan. Klaster ACK dianggap tidak sesuai jika vSwitch kolam nodenya tidak tersedia. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa grup penskalaan kolam node tidak tersedia (Baru di Model 3.0) | Jika grup penskalaan kolam node klaster ACK tidak tersedia, hal ini menyebabkan klaster kehilangan kemampuan penskalaan otomatis sepenuhnya. Tidak dapat melakukan penskalaan otomatis selama beban tinggi, yang menyebabkan kehabisan resource node, kegagalan penjadwalan Pod, atau keterlambatan respons. Tidak dapat melakukan penskalaan saat beban rendah, yang mengakibatkan pengangguran resource dan pemborosan biaya. Mekanisme penggantian otomatis untuk node yang rusak gagal, yang dapat menyebabkan node offline dalam waktu lama dan memperburuk risiko titik kegagalan tunggal dalam klaster. Pada saat yang sama, grup penskalaan yang abnormal menghambat kemampuan klaster untuk merespons secara elastis terhadap lalu lintas mendadak atau kebutuhan pemeliharaan. Dalam jangka panjang, hal ini menyebabkan penurunan stabilitas layanan dan efisiensi O&M. Status grup penskalaan harus segera diperbaiki untuk memulihkan kemampuan elastis klaster. Klaster ACK dianggap tidak sesuai jika grup penskalaan kolam nodenya tidak tersedia. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa konfigurasi penskalaan kolam node tidak tersedia (Baru di Model 3.0) | Jika konfigurasi penskalaan kolam node klaster ACK tidak tersedia, hal ini menyebabkan klaster tidak dapat menyesuaikan jumlah node secara otomatis. Tidak dapat melakukan penskalaan selama beban tinggi, yang menyebabkan kehabisan resource, kegagalan penjadwalan Pod, atau gangguan layanan. Tidak dapat melakukan penskalaan saat beban rendah, yang mengakibatkan pemborosan resource dan lonjakan biaya. Pada saat yang sama, mekanisme penggantian otomatis untuk node yang rusak gagal, yang dapat menyebabkan node tidak tersedia dalam waktu lama dan mengurangi ketersediaan tinggi klaster. Dalam jangka panjang, hal ini juga menyebabkan kegagalan kebijakan otomatis seperti HPA (Penyekala Pod Horizontal), yang menyebabkan ketidakseimbangan status klaster dan peningkatan biaya O&M. Konfigurasi penskalaan harus segera diperbaiki untuk memulihkan kemampuan elastis. Klaster ACK dianggap tidak sesuai jika konfigurasi penskalaan kolam nodenya tidak tersedia. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Pemeriksaan klaster ACK menemukan bahwa grup keamanan kolam node tidak tersedia (Baru di Model 3.0) | Jika grup keamanan kolam node klaster ACK tidak tersedia, hal ini menyebabkan aturan akses jaringan gagal. Komunikasi antara komponen klaster seperti kubelet dan Server API, dan penemuan layanan antar-Pod dapat terputus karena pemblokiran port atau aturan yang hilang. Pada saat yang sama, lalu lintas tidak sah dapat menembus perlindungan, yang meningkatkan risiko intrusi node atau serangan DDoS. Jika aturan outbound abnormal, node tidak dapat mengakses penyimpanan eksternal, repositori gambar, atau layanan pemantauan, yang menyebabkan kegagalan panggilan layanan dependen. Kegagalan grup keamanan juga menyebabkan node salah diisolasi, yang memengaruhi penjadwalan Pod dan kelangsungan bisnis. Konfigurasi aturan harus segera diperbaiki untuk memulihkan isolasi jaringan dan keamanan komunikasi. Klaster ACK dianggap tidak sesuai jika grup keamanan kolam nodenya tidak tersedia. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Tingkat error 4xx ALB terlalu tinggi (Baru di Model 3.0) | Jika tingkat error 4xx instans ALB terus melebihi ambang batas tertentu selama periode waktu, biasanya berarti ada banyak pengecualian dalam permintaan klien, seperti permintaan tidak valid, kesalahan parameter, kegagalan autentikasi, atau frekuensi akses tinggi seperti serangan DDoS. Hal ini tidak hanya memengaruhi pengalaman pengguna normal, tetapi juga dapat mengekspos cacat desain antarmuka sistem atau risiko keamanan. Instans ALB dianggap tidak sesuai jika tingkat error 4xx-nya lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam rentang waktu tertentu di masa lalu. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Instans CEN tidak dikonfigurasi dengan pemeriksaan kesehatan VBR (Baru di Model 3.0) | Fitur pemeriksaan kesehatan Cloud Enterprise Network mendeteksi konektivitas sirkuit Express Connect yang terkait dengan instans VBR. Dalam skenario di mana ada rute redundan antara Cloud Enterprise Network dan pusat data, pemeriksaan kesehatan mendukung peralihan otomatis ke rute yang tersedia setelah mendeteksi kegagalan sirkuit Express Connect, yang memastikan transmisi lalu lintas tanpa gangguan. Instans CEN dianggap tidak sesuai jika VBR yang terkait dengannya tidak diatur dengan pemeriksaan kesehatan. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Record SPF dalam resolusi email domain DNS abnormal (Baru di Model 3.0) | SPF adalah protokol validasi email berbasis DNS yang digunakan untuk menentukan server surat mana yang diizinkan mengirim email atas nama domain, seperti alamat IP atau nama domain. Saat server surat menerima email, server tersebut memverifikasi alamat IP pengirim terhadap daftar yang diizinkan dalam record SPF untuk menentukan apakah email tersebut sah. Menetapkan nilai SPF yang wajar dan valid dapat mencegah pemalsuan email, mengurangi risiko spam, dan meningkatkan tingkat pengiriman email. Untuk setiap record MX dalam domain DNS, periksa apakah ada setidaknya satu record TXT dengan nilai SPF valid yang dimulai dengan v=spf1. Domain DNS yang tidak memenuhi kondisi di atas dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Instans ECS memiliki event O&M tertunda | Kegagalan merespons dan menangani event O&M terjadwal untuk ECS secara tepat waktu dapat menyebabkan instans ECS me-restart selama jam sibuk bisnis, yang memengaruhi stabilitas layanan pada instans ECS. Akun dianggap berisiko jika ada event O&M ECS tertunda dengan status Menanyakan, Terjadwal, atau Menjalankan. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Bucket OSS tidak diatur dengan nama domain kustom | Menggunakan nama domain kustom dapat meningkatkan citra merek dan profesionalisme, serta meningkatkan stabilitas. Nama domain kustom dapat diikat melalui CNAME untuk mencapai akselerasi CDN, yang meningkatkan kinerja akses. Ini juga mendukung akses aman HTTPS, yang meningkatkan keamanan transmisi data. Bucket OSS dianggap tidak sesuai jika tidak diatur dengan nama domain kustom. | Perbaikan cepat tidak didukung. | Tidak |
Pemeriksaan risiko | Replikasi data untuk instans RDS for PostgreSQL tidak menggunakan mode sinkron atau semi-sinkron (Baru di Model 3.0) | RDS for PostgreSQL mendukung tiga mode replikasi data: asinkron, sinkron, dan semi-sinkron. Mode asinkron memiliki kecepatan respons tercepat, tetapi hanya cocok untuk skenario dengan persyaratan persistensi data rendah. Kehilangan data dapat terjadi saat database crash, yang menimbulkan risiko persistensi. Instans RDS for PostgreSQL dianggap tidak sesuai jika menggunakan mode asinkron untuk replikasi data (parameter synchronous_commit dimatikan). | Perbaikan ini mengubah mode replikasi data database RDS for PostgreSQL ke mode semi-sinkron atau sinkron. Mode sinkron menyediakan tingkat perlindungan maksimum dan cocok untuk skenario dengan persyaratan persistensi data sangat tinggi, tetapi kecepatan responsnya lambat. Mode semi-sinkron menyediakan tingkat perlindungan ketersediaan tertinggi, yang menyeimbangkan persistensi data dan kecepatan respons. Untuk mengubah mode replikasi data ke semi-sinkron, versi kernel instans harus 20220228 atau lebih baru. Tindakan untuk memodifikasi parameter dieksekusi dalam jendela pemeliharaan yang ditetapkan untuk instans. | Tidak |
Pemeriksaan risiko | Penggunaan koneksi instans Redis terlalu tinggi (Baru di Model 3.0) | Jika penggunaan koneksi instans Redis terus melebihi ambang batas tertentu selama periode waktu, hal ini menunjukkan bahwa resource koneksi saat ini mendekati atau telah mencapai batasnya. Hal ini dapat menyebabkan klien baru tidak dapat membangun koneksi, permintaan ditolak, atau latensi respons meningkat, yang memengaruhi kinerja dan stabilitas bisnis. Situasi ini juga dapat menunjukkan masalah seperti kebocoran koneksi, konfigurasi kolam koneksi yang tidak wajar, atau tekanan lalu lintas mendadak. Instans Redis dianggap tidak sesuai jika penggunaan koneksi rata-ratanya lebih besar dari atau sama dengan 50% selama minimal 8 jam dalam rentang waktu tertentu di masa lalu. | Perbaikan cepat tidak didukung. | Tidak |
Pencadangan dan snapshot data | Pencadangan log tidak diaktifkan untuk instans AnalyticDB for MySQL | Klaster AnalyticDB for MySQL dianggap tidak sesuai jika pencadangan log tidak diaktifkan. | Perbaikan ini mengaktifkan pencadangan log untuk klaster AnalyticDB for MySQL yang dipilih, dengan periode penyimpanan default 7 hari. | Tidak |
Pencadangan dan snapshot data | Tidak ada set pencadangan data yang tersedia untuk instans AnalyticDB for PostgreSQL (Baru di Model 3.0) | Pemeriksaan pencadangan data untuk AnalyticDB for PostgreSQL bertujuan untuk memastikan bahwa instans memiliki set pencadangan yang tersedia untuk mencegah gangguan bisnis yang disebabkan oleh kehilangan data atau kesalahan operasi. Dengan memeriksa kebijakan pencadangan dan status pencadangan secara berkala, Anda dapat secara efektif meningkatkan keamanan data dan kemampuan pemulihan. Instans AnalyticDB for PostgreSQL penyimpanan yang berjalan, bukan tipe Serverless, dianggap tidak sesuai jika tidak memiliki set pencadangan data yang tersedia dalam jumlah jam tertentu di masa lalu (default adalah 7 hari atau 168 jam). | Setelah ini diaktifkan, instans AnalyticDB for PostgreSQL melakukan pencadangan data sesuai konfigurasi pencadangan, yang menghasilkan set pencadangan yang tersedia. AnalyticDB for PostgreSQL dapat memulihkan instans baru ke titik waktu historis melalui pencadangan dasar lengkap dan pencadangan log berkelanjutan, yang memastikan keamanan data pada waktu tersebut. | Tidak |
Pencadangan dan snapshot data | Perlindungan pencadangan data untuk instans ECS berisiko (Baru di Model 3.0) | Solusi snapshot dan pencadangan yang berbeda harus dipilih untuk skenario yang berbeda, seperti perlindungan data harian, pengawalan operasi berisiko tinggi, perlindungan bencana lintas wilayah, dan pemulihan mesin penuh. Jika tidak, mungkin tidak mungkin memulihkan data, dan solusi pencadangan yang tidak lengkap juga menyebabkan kemampuan dan efisiensi pemulihan file inti tidak memenuhi harapan. Instans ECS dianggap tidak sesuai jika belum mengaktifkan solusi pencadangan berikut: 1. Mengaktifkan solusi snapshot disk cloud. 2. Mengonfigurasi solusi pencadangan "File/Database yang Dikelola Sendiri". | Perbaikan cepat tidak didukung. | Tidak |
Pencadangan dan snapshot data | Kebijakan snapshot otomatis tidak diatur untuk disk ECS | Disk ECS dianggap tidak sesuai jika kebijakan snapshot otomatis tidak diatur untuknya. | Perbaikan ini mengaktifkan kebijakan snapshot yang ditentukan untuk instans disk ECS yang dipilih. Karena kebijakan snapshot bersifat independen di setiap wilayah, jika kebijakan dengan nama yang sama ada di wilayah tempat disk yang dipilih berada, kebijakan yang ada digunakan. Jika tidak, kebijakan snapshot baru dibuat. | Tidak |
Pencadangan dan snapshot data | Pencadangan log tidak diaktifkan untuk instans MongoDB | Instans MongoDB dianggap tidak sesuai jika pencadangan log tidak diaktifkan. | Perbaikan ini mengaktifkan pencadangan log untuk klaster MongoDB yang dipilih, dengan periode penyimpanan default 7 hari. | Tidak |
Pencadangan dan snapshot data | Kebijakan pencadangan data untuk sistem file NAS berisiko (Baru di Model 3.0) | Jika keranjang daur ulang NAS dan Cloud Backup tidak diaktifkan, Anda tidak dapat memulihkan tepat waktu saat file Anda dihapus atau dirusak secara tidak sengaja. Jika replikasi lintas wilayah tidak diaktifkan untuk penyimpanan cadangan, redundansi geo multi-versi tidak dapat dicapai, dan data tidak dapat dipulihkan di lokasi berbeda, yang secara serius memengaruhi kelangsungan bisnis. Sistem file NAS dianggap tidak sesuai jika belum mengaktifkan solusi pencadangan berikut: 1. Mengaktifkan fitur keranjang daur ulang NAS. 2. Mengaktifkan pencadangan NAS. | Perbaikan ini mengaktifkan fitur keranjang daur ulang NAS. Untuk menghindari gangguan bisnis atau kehilangan data permanen yang disebabkan oleh penghapusan file yang tidak disengaja dalam sistem file NAS tujuan umum, kami sarankan Anda mengaktifkan fitur keranjang daur ulang. Setelah ini diaktifkan, file atau direktori yang dihapus disimpan sementara di keranjang daur ulang dan dihapus secara permanen setelah periode retensi yang ditentukan. Anda dapat memulihkan file-file ini dan informasi metadata seperti UID, GID, dan ACL selama periode retensi. | Tidak |
Pencadangan dan snapshot data | Kebijakan pencadangan data untuk bucket OSS berisiko | Data di tingkat bucket harus dilindungi. Jika versioning tidak diaktifkan, versi historis data menimpa dan menghapus operasi mungkin tidak disimpan. Jika terjadi masalah, tidak mungkin memulihkan Object yang disimpan di bucket ke titik waktu tertentu. Pada saat yang sama, jika replikasi lintas wilayah tidak diaktifkan, operasi di bawah akun yang sama atau berbeda tidak disinkronkan ke wilayah lain. Saat terjadi bencana atau kegagalan, hal ini secara serius merugikan kelangsungan bisnis. Bucket OSS dianggap tidak sesuai jika tidak memiliki setidaknya satu solusi pencadangan berikut yang diaktifkan: 1. Mengaktifkan versioning OSS. 2. Mengaktifkan pencadangan bucket OSS. | Perbaikan ini mengaktifkan versioning untuk instans OSS yang dipilih. Setelah versioning diaktifkan, operasi menimpa dan menghapus data disimpan sebagai versi historis. Jika Anda secara tidak sengaja menimpa atau menghapus Object, Anda dapat memulihkan Object yang disimpan di bucket ke versi historis apa pun kapan saja. | Tidak |
Pencadangan dan snapshot data | Pencadangan level-2 tidak diaktifkan untuk klaster PolarDB | Klaster PolarDB dianggap tidak sesuai jika pencadangan level-2 tidak diaktifkan, dan periode retensi lebih besar dari atau sama dengan 30. | Perbaikan ini menetapkan siklus pencadangan level-2 dan periode retensi pencadangan level-2 (default adalah 30 hari) untuk klaster PolarDB yang dipilih. Jika pencadangan level-2 saat ini tidak diaktifkan, pencadangan tersebut diaktifkan secara otomatis. | Tidak |
Pencadangan dan snapshot data | Pencadangan log tidak diaktifkan untuk instans RDS | Instans RDS dianggap tidak sesuai jika pencadangan log tidak diaktifkan. | Perbaikan ini mengaktifkan pencadangan log untuk instans RDS yang dipilih, dengan periode penyimpanan default 7 hari. | Tidak |
Pencadangan dan snapshot data | Kebijakan pencadangan data untuk instans Tablestore berisiko (Baru di Model 3.0) | Jika pencadangan Tablestore dan pencadangan lintas wilayah tidak diaktifkan, data penting tidak dapat dipulihkan dengan cepat dengan cara yang sederhana, efisien, aman, dan andal. Saat terjadi kegagalan, kelangsungan bisnis secara serius terpengaruh. Instans Tablestore dianggap tidak sesuai jika solusi pencadangan tidak diaktifkan. | Perbaikan cepat tidak didukung. | Tidak |
Pencadangan dan snapshot data | Pod instans elastis ECI tidak memiliki volume data yang dipasang | Pod instans elastis ECI dianggap tidak sesuai jika tidak memiliki volume data yang dipasang. | Perbaikan cepat tidak didukung. | Tidak |
Pencadangan dan snapshot data | Pencadangan otomatis tidak diaktifkan untuk instans Elasticsearch | Instans Elasticsearch dianggap tidak sesuai jika pencadangan otomatis tidak diaktifkan. | Operasi ini mengaktifkan fitur pencadangan otomatis untuk instans Elasticsearch yang dipilih. Sistem secara otomatis mencadangkan data sesuai siklus pencadangan dan waktu yang ditetapkan. Jika data dihapus secara tidak sengaja atau terjadi kesalahan logika dalam aplikasi, Anda dapat menggunakan fitur pemulihan pencadangan otomatis untuk memulihkan data cadangan dari titik waktu tertentu ke instans ES asli, yang memastikan keamanan data. Catatan bahwa pencadangan otomatis hanya menyimpan data snapshot selama 7 hari terakhir, dan data pencadangan otomatis hanya dapat digunakan untuk memulihkan ke klaster asli. | Tidak |
Pencadangan dan snapshot data | Pencadangan inkremental tidak diatur untuk instans Redis | Instans Redis (Edisi Perusahaan Tair) dianggap tidak sesuai jika pencadangan inkremental tidak diaktifkan. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Klaster ACK memiliki risiko penyebaran zona tunggal | Menggunakan klaster regional dapat mencapai kemampuan pemulihan bencana lintas wilayah. Klaster ACK dianggap sesuai jika merupakan klaster regional dengan node yang tersebar di 3 zona atau lebih. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans ALB memiliki risiko penyebaran zona tunggal | Jika hanya satu zona yang dipilih, hal ini memengaruhi instans ALB saat zona ini gagal, yang memengaruhi stabilitas bisnis. Instans ALB dianggap sesuai jika merupakan instans multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Resource yang dipasang ke grup server ALB semuanya berada di zona tunggal | Menambahkan resource dari beberapa zona ke grup server load balancer ALB dapat memastikan bahwa bahkan jika satu zona gagal, aplikasi masih dapat berjalan di zona lain, yang memberikan toleransi kesalahan yang lebih baik. Grup server load balancer ALB dianggap sesuai jika resource yang dipasang padanya tersebar di beberapa zona. Aturan ini tidak berlaku jika grup server ALB tidak memiliki resource yang dipasang atau jika tipe grup server adalah IP atau Function Compute. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans Gerbang API memiliki risiko penyebaran zona tunggal | Kami merekomendasikan menggunakan instans Gerbang API multi-zona, yang memiliki kemampuan pemulihan bencana multi-zona. Instans gerbang dianggap sesuai jika multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Distribusi instans ECS dalam suatu wilayah tidak seimbang di berbagai zona (Baru di Model 3.0) | Menyebarkan semua instans ECS di zona yang sama menimbulkan risiko titik kegagalan tunggal. Saat zona tersebut gagal karena kerusakan perangkat keras, gangguan jaringan, atau masalah lainnya, semua instans ECS di wilayah tersebut menjadi tidak tersedia secara bersamaan, yang menyebabkan gangguan bisnis. Akun dianggap tidak sesuai jika semua instans ECS di wilayah yang sama ditempatkan di zona yang sama. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans Flink tidak menggunakan tipe CU cross-zone | Kami merekomendasikan mengaktifkan cross-zone untuk CU Flink, yang menyediakan kemampuan pemulihan bencana multi-zona. Instans Flink dianggap tidak sesuai jika tidak menggunakan CU multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans GWLB memiliki risiko penyebaran zona tunggal | Kami merekomendasikan mengaktifkan multi-zona untuk instans GWLB, yang menyediakan kemampuan pemulihan bencana multi-zona. Instans Gateway Load Balancer dianggap tidak sesuai jika bukan multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Resource yang dipasang ke grup server GWLB semuanya berada di zona tunggal (Baru di Model 3.0) | Memasang resource di grup server multi-zona dapat meningkatkan kemampuan pemulihan bencana sistem dan mengurangi risiko gangguan bisnis. Akun dianggap tidak sesuai jika instans GWLB adalah zona tunggal, atau jika grup server yang digunakan oleh pendengar di bawah instans GWLB tidak memiliki resource dari beberapa zona yang ditambahkan. Aturan ini tidak berlaku saat tidak ada resource di grup server atau tipe resource adalah IP. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Komponen terkait MSE memiliki risiko penyebaran zona tunggal | Kami merekomendasikan mengadopsi arsitektur penyebaran multi-zona untuk komponen terkait MSE untuk meningkatkan stabilitasnya. Komponen terkait MSE dianggap tidak sesuai jika ditempatkan di zona tunggal. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Gateway MSE memiliki risiko penyebaran zona tunggal | Semua replika instans gateway saat ini ditempatkan di zona (AZ) yang sama. Bentuk penyebaran ini tidak memiliki kemampuan ketersediaan tinggi, dan bisnis Anda mungkin rusak dalam kasus ekstrem. Tingkatkan ke versi baru sesegera mungkin untuk mendiskretisasi instans gateway ke beberapa zona. Komponen gateway MSE Ingress dianggap tidak sesuai jika memiliki arsitektur zona tunggal. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans MongoDB memiliki risiko penyebaran zona tunggal | Menggunakan instans MongoDB yang bukan multi-zona dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans NLB memiliki risiko penyebaran zona tunggal | Untuk instans Network Load Balancer, sangat disarankan untuk mengonfigurasi multi-zona untuk memenuhi pemulihan bencana multi-zona. Menggunakan instans Network Load Balancer zona tunggal dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Resource yang dipasang ke grup server NLB semuanya berada di zona tunggal | Kami merekomendasikan menambahkan resource dari beberapa zona ke grup server Network Load Balancer, yang menyediakan kemampuan pemulihan bencana multi-zona. Grup server Network Load Balancer dianggap sesuai jika resource-nya tersebar di beberapa zona. Hal ini tidak berlaku jika tidak ada resource di grup server atau tipe resource adalah IP. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Penyimpanan redundan zona tidak diaktifkan untuk bucket OSS | Bucket OSS dianggap tidak sesuai jika penyimpanan redundan zona tidak diaktifkan. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Klaster penyimpanan siaga panas tidak diaktifkan untuk klaster PolarDB | Klaster PolarDB dianggap tidak sesuai jika klaster penyimpanan siaga panas tidak diaktifkan dan datanya didistribusikan di zona tunggal. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Layanan titik akhir PrivateLink memiliki risiko penyebaran zona tunggal | Mengonfigurasi beberapa zona untuk layanan titik akhir dapat sangat mengurangi risiko gangguan layanan, mendistribusikan lalu lintas lebih merata untuk menghindari kelebihan beban pada zona tunggal, dan menyediakan akses terdekat, yang mengurangi latensi jaringan dan meningkatkan kecepatan akses. Mengonfigurasi beberapa zona untuk layanan titik akhir dianggap sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans RDS memiliki risiko penyebaran zona tunggal | Menggunakan instans RDS yang bukan multi-zona dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans Redis memiliki risiko penyebaran zona tunggal | Menggunakan instans Redis yang bukan multi-zona dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans SLB dan grup server pendengarnya memiliki risiko titik penyebaran tunggal | Akun dianggap tidak sesuai jika instans SLB bersifat single-zone, atau jika grup server yang digunakan oleh pendengar di bawah instans SLB tidak memiliki resource dari beberapa zona yang ditambahkan. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans ApsaraMQ for Kafka memiliki risiko penyebaran zona tunggal | Saat Anda menggunakan instans Edisi Profesional dan memilih hanya penyebaran single-zone selama penyebaran, Anda dapat meningkatkan klaster ke arsitektur penyebaran multi-zona dengan mengedit zona sekunder, yang meningkatkan kemampuan pemulihan bencana klaster. Instans ApsaraMQ for Kafka dianggap sesuai jika multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Router transit memiliki risiko penyebaran zona tunggal | Untuk router transit yang ada, sangat disarankan untuk mengonfigurasi multi-zona guna memenuhi kemampuan pemulihan bencana multi-zona. Router transit dianggap tidak sesuai jika koneksi VPC-nya hanya menyiapkan vSwitch di satu zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans AnalyticDB for PostgreSQL memiliki risiko penyebaran zona tunggal | Kami merekomendasikan mengaktifkan pemulihan bencana lintas zona untuk instans AnalyticDB for PostgreSQL. Saat zona utama gagal, sistem secara otomatis mengalihkan node zona sekunder ke node utama untuk terus memberikan layanan dan memastikan kelangsungan bisnis. Instans AnalyticDB for PostgreSQL dianggap tidak sesuai jika tidak memiliki pemulihan bencana lintas zona yang diaktifkan. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Klaster ClickHouse memiliki risiko penyebaran zona tunggal | Kami merekomendasikan menggunakan instans klaster ClickHouse multi-zona, yang memiliki kemampuan pemulihan bencana multi-zona. Instans klaster ClickHouse multi-zona dianggap sesuai. Saat ini, hanya versi komunitas yang diperiksa untuk arsitektur multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans HBase memiliki risiko penyebaran zona tunggal | Kami merekomendasikan mengadopsi arsitektur penyebaran multi-zona, yang memiliki kemampuan pemulihan bencana yang lebih tinggi. Instans HBase dianggap tidak sesuai jika tidak mengadopsi penyebaran multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans Lindorm memiliki risiko penyebaran zona tunggal | Kami merekomendasikan menyebarkan instans Lindorm di beberapa zona. Instans multi-zona memiliki kemampuan pemulihan bencana yang lebih tinggi. Pada saat yang sama, instans Lindorm dapat mencapai konsistensi data yang kuat antar-zona, dan juga dapat mengembalikan hasil tercepat di bawah konsistensi data akhir, yang meningkatkan kualitas layanan bisnis online. Instans Lindorm dianggap tidak sesuai jika tidak mengadopsi penyebaran multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans PolarDB-X 2.0 memiliki risiko penyebaran zona tunggal | Kami merekomendasikan menggunakan instans PolarDB-X 2.0 multi-zona, yang memiliki kemampuan pemulihan bencana multi-zona. Instans PolarDB-X 2.0 dengan arsitektur multi-zona dianggap sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans Tablestore memiliki risiko penyebaran zona tunggal | Instans Tablestore dianggap tidak sesuai jika tidak menggunakan penyebaran multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Pemeriksaan klaster ACK menemukan bahwa CoreDNS hanya memiliki satu replika (Baru di Model 3.0) | Jika konfigurasi replika tunggal CoreDNS pada klaster ACK dipertahankan, maka keandalan tinggi hilang. Saat Pod gagal, layanan DNS sepenuhnya terganggu, yang menyebabkan kegagalan resolusi nama domain layanan dalam klaster dan mengakibatkan gangguan komunikasi antar-aplikasi. Arsitektur titik tunggal tidak dapat mentoleransi kegagalan node atau operasi pemeliharaan. Layanan mungkin mengalami gangguan sementara selama peningkatan atau restart, dan risiko operasi jangka panjang diperparah. Jumlah replika harus segera diperluas untuk memastikan redundansi dan stabilitas layanan. Klaster ACK dianggap tidak sesuai jika CoreDNS-nya hanya memiliki satu replika. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Penyimpanan redundan zona tidak diaktifkan untuk bucket OSS yang terkait dengan ACR | Kami merekomendasikan menggunakan instans ACR Edisi Perusahaan dan mengaitkannya dengan bucket OSS yang memiliki penyimpanan redundan zona diaktifkan. ACR dianggap tidak sesuai jika dikaitkan dengan bucket OSS yang memiliki penyimpanan redundan lokal. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Klaster ACS memiliki risiko penyebaran zona tunggal | Kami merekomendasikan menggunakan klaster ACS regional multi-zona, yang memiliki kemampuan pemulihan bencana multi-zona. Klaster ACS dianggap sesuai jika merupakan klaster regional dengan node yang tersebar di 3 zona atau lebih. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans Elasticsearch memiliki risiko penyebaran zona tunggal | Menggunakan instans Elasticsearch yang bukan multi-zona dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Proyek SLS tidak menggunakan penyimpanan redundan zona | Simple Log Service menyediakan dua jenis redundansi penyimpanan: penyimpanan redundan lokal dan penyimpanan redundan zona. Ini mencakup mekanisme redundansi data dari satu zona hingga beberapa zona untuk memastikan ketahanan dan ketersediaan data. Proyek log dianggap sesuai jika menggunakan penyimpanan redundan zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Gateway VPN memiliki risiko penyebaran zona tunggal | Untuk instans tunnel tunggal yang ada, sangat disarankan agar Anda mengaktifkan ketersediaan tinggi AZ di konsol dan mengonfigurasi dual tunnel untuk terhubung ke rekan. VPN dianggap tidak sesuai jika menggunakan instans tunnel tunggal. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Gateway VPN tidak menggunakan mode dual-tunnel | Koneksi IPsec-VPN dual-tunnel memiliki tunnel primer dan sekunder. Jika tunnel primer gagal, lalu lintas dapat dikirimkan melalui tunnel sekunder, yang meningkatkan ketersediaan tinggi koneksi IPsec-VPN. Gateway VPN dual-tunnel dianggap sesuai jika baik tunnel primer maupun sekunder terhubung ke rekan. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Bastionhost memiliki risiko penyebaran zona tunggal | Kami merekomendasikan menggunakan Bastionhost Edisi Dual-Engine Perusahaan atau Edisi SM-compliant untuk memenuhi kemampuan pemulihan bencana multi-zona. Menggunakan Bastionhost Edisi Dasar dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur multi-zona | Instans ApsaraMQ for RocketMQ tidak menggunakan Edisi Kluster Ketersediaan-Tinggi | Kami merekomendasikan menggunakan Edisi Kluster Ketersediaan-Tinggi, yang memiliki kemampuan pemulihan bencana multi-zona. Instans ApsaraMQ for RocketMQ 5.0 dianggap tidak sesuai jika tidak multi-zona. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur klaster | Grup penskalaan ESS dikaitkan hanya dengan satu vSwitch | Dengan mengaitkan beberapa vSwitch, grup penskalaan dapat meningkatkan ketangguhan, keandalan, dan kinerja keseluruhan aplikasi, yang membantu memenuhi persyaratan bisnis dengan lebih baik. Jika satu vSwitch tidak dapat diakses karena masalah jaringan atau kondisi lainnya, lalu lintas pengguna masih dapat mengakses aplikasi melalui vSwitch lainnya. Grup penskalaan dianggap sesuai jika dikaitkan dengan setidaknya dua vSwitch. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur klaster | Komponen terkait MSE memiliki risiko titik penyebaran tunggal | Untuk komponen MSE ZooKeeper, kami merekomendasikan melakukan scaling-out ke 3 node atau lebih. Untuk komponen Nacos-ANS, kami merekomendasikan melakukan scaling-out ke 3 node atau lebih. Komponen terkait MSE dianggap tidak sesuai jika ditempatkan pada satu node. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur klaster | Gateway MSE memiliki risiko titik penyebaran tunggal | Instans node tunggal memiliki risiko arsitektur. Titik kegagalan tunggal menyebabkan layanan tidak tersedia. Kami merekomendasikan melakukan scaling-out ke 2 node atau lebih. Komponen MSE Ingress dianggap tidak sesuai jika ditempatkan pada satu node. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur klaster | Instans PolarDB memiliki risiko titik penyebaran tunggal | Instans PolarDB dianggap tidak sesuai jika tidak menggunakan Edisi Klaster atau Edisi Klaster Multi-master. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur klaster | Fitur alih bencana primer/sekunder otomatis tidak diaktifkan untuk instans RDS (Baru di Model 3.0). | Ketika node primer instans mengalami kegagalan dan tidak dapat digunakan, atau ketika ada potensi risiko dalam instans dan perbaikan darurat telah dilakukan pada node sekunder, RDS secara otomatis memicu alih bencana primer/sekunder, yang menukar node primer dan sekunder. Setelah alih bencana, endpoint instans tetap tidak berubah, dan aplikasi secara otomatis terhubung ke node primer baru (node sekunder asli), yang memastikan ketersediaan tinggi instans tersebut. Instans RDS dianggap tidak sesuai jika fitur alih bencana primer/sekunder otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan fitur alih bencana primer/sekunder otomatis untuk instans RDS. Ketika node primer instans mengalami kegagalan dan tidak dapat digunakan, atau ketika ada potensi risiko dalam instans dan perbaikan darurat telah dilakukan pada node sekunder, RDS secara otomatis memicu alih bencana primer/sekunder, yang menukar node primer dan sekunder. Setelah alih bencana, endpoint instans tetap tidak berubah, dan aplikasi secara otomatis terhubung ke node primer baru (node sekunder asli), yang memastikan ketersediaan tinggi instans tersebut. | Tidak |
Arsitektur klaster | Node primer dan sekunder klaster RDS tidak dikonfigurasi dengan ukuran instans yang sama (Baru di Model 3.0) | Jika node primer dan sekunder klaster RDS tidak dikonfigurasi dengan ukuran instans yang sama, hal ini dapat menyebabkan node sekunder tidak dapat mengambil alih secara mulus saat node primer gagal, yang mengakibatkan hambatan kinerja atau gangguan layanan. Selain itu, spesifikasi instans yang berbeda dapat menyebabkan ketidakcocokan resource, yang memengaruhi efisiensi sinkronisasi data dan kecepatan pemulihan, serta mengurangi kemampuan ketersediaan tinggi dan pemulihan bencana sistem. Mendeteksi dan memastikan bahwa ukuran instans node primer dan sekunder konsisten membantu meningkatkan stabilitas sistem, meningkatkan kemampuan alih bencana, dan memastikan kelangsungan bisnis. Hal ini memberikan keandalan yang lebih tinggi dan kendali O&M yang lebih baik kepada pelanggan. Klaster RDS dianggap tidak sesuai jika node primer dan sekundernya dikonfigurasi dengan ukuran instans yang berbeda. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur klaster | Node primer dan sekunder klaster RDS tidak dikonfigurasi dengan tipe instans yang sama (Baru di Model 3.0) | Jika node primer dan sekunder klaster RDS tidak dikonfigurasi dengan tipe instans yang sama, hal ini dapat menyebabkan node sekunder tidak dapat mengambil alih secara mulus saat node primer gagal, yang mengakibatkan hambatan kinerja atau gangguan layanan. Selain itu, spesifikasi instans yang berbeda dapat menyebabkan ketidakcocokan resource, yang memengaruhi efisiensi sinkronisasi data dan kecepatan pemulihan, serta mengurangi kemampuan ketersediaan tinggi dan pemulihan bencana sistem. Mendeteksi dan memastikan bahwa tipe instans node primer dan sekunder konsisten membantu meningkatkan stabilitas sistem, meningkatkan kemampuan alih bencana, dan memastikan kelangsungan bisnis. Hal ini memberikan keandalan yang lebih tinggi dan kendali O&M yang lebih baik kepada pelanggan. Klaster RDS dianggap tidak sesuai jika node primer dan sekundernya dikonfigurasi dengan tipe instans yang berbeda. | Perbaikan cepat tidak didukung. | Tidak |
Arsitektur klaster | Mode keandalan tinggi tidak digunakan untuk Express Connect (Baru di Model 3.0) | Gunakan mode keandalan tinggi Express Connect untuk membuat dua titik akses di wilayah yang sama guna mencapai redundansi jaringan, memastikan stabilitas dan keandalan transmisi data, serta memenuhi persyaratan kepatuhan. Sirkuit Express Connect dianggap tidak sesuai jika memiliki kurang dari 2 titik akses di wilayah yang sama. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Kapasitas penyimpanan tersisa instans RDS tidak mencukupi (Baru di Model 3.0) | Kapasitas penyimpanan tersisa instans RDS yang tidak mencukupi dapat menyebabkan kegagalan penulisan database, penurunan kinerja, dan bahkan gangguan layanan atau risiko kehilangan data. Penting untuk memperluas kapasitas atau membersihkan data secara tepat waktu guna menghindari anomali bisnis, memastikan stabilitas database, dan meningkatkan keandalan serta antisipasi O&M. Instans RDS dianggap tidak sesuai jika memiliki kurang dari 10% kapasitas penyimpanan tersisa selama 1 jam dalam 7 hari. | Perbaikan ini mengaktifkan fitur ekspansi penyimpanan otomatis untuk instans RDS. Setelah diaktifkan, ruang penyimpanan akan diperluas secara otomatis saat mencapai ambang batas. Instans tidak perlu di-restart selama proses ekspansi, dan tidak ada dampak terhadap bisnis. | Tidak |
Kuota dan kapasitas | Panggilan API ACK dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API ALB dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API CDN dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API ECS dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API NAS dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API PolarDB dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API RDS dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API Redis dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API RocketMQ dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API SLB dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API VPC dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Panggilan API Cloud Enterprise Network (CEN) dibatasi | Panggilan API dibatasi, yang menyebabkan kegagalan panggilan dan dapat memengaruhi stabilitas bisnis. Akun dianggap tidak sesuai jika terjadi pengecualian pembatasan untuk panggilan API dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total klaster ACK mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah klaster ACK mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total instans ALB mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total instans ALB mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah refresh URL CDN mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah refresh URL CDN mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah nama domain yang dipercepat yang didukung oleh CDN mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah nama domain yang dipercepat yang didukung oleh CDN mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah refresh direktori CDN mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah refresh direktori CDN mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah item pra-ambil CDN mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah item pra-ambil CDN mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total disk cloud EBS mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total disk cloud EBS mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota vCPU untuk instans langganan ECS mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait vCPU instans langganan ECS mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota vCPU untuk spot instans ECS mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait vCPU spot instans ECS mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota vCPU untuk instans bayar sesuai pemakaian ECS mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait kuota vCPU instans bayar sesuai pemakaian ECS mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total EIP mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total EIP mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total grup penskalaan ESS mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total grup penskalaan ESS mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Komponen terkait MSE memiliki risiko terkait kapasitas. | Memastikan kapasitas resource berada dalam rentang wajar. Jika batas kapasitas dilampaui, dapat menyebabkan risiko stabilitas. MSE dianggap tidak sesuai jika memiliki metrik terkait yang kapasitasnya dilampaui. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah entri SNAT yang dapat dipertahankan di NAT Gateway mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah entri SNAT yang dapat dipertahankan di NAT Gateway mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah EIP yang dapat diikat ke NAT Gateway mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah EIP yang dapat diikat ke NAT Gateway mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total instans NLB mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total instans NLB mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk instans on-demand RDS mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait instans on-demand RDS mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total stack ROS mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total stack ROS mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah pendengar yang dipertahankan oleh instans SLB mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah pendengar yang dipertahankan oleh instans SLB mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah server yang dapat dipasang ke backend instans SLB mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah server yang dapat dipasang ke backend instans SLB mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total instans SLB mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total instans SLB mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total grup keamanan mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total grup keamanan mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total elastic network interfaces mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total elastic network interfaces (ENIs) mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Kuota dan kapasitas | Penggunaan kuota untuk jumlah total set penyebaran mendekati batas atas (Baru di Model 3.0) | Kuota resource yang tidak mencukupi dapat membatasi operasi pembuatan, perubahan, atau ekspansi resource produk. Akun dianggap tidak sesuai ketika item kuota terkait jumlah total set penyebaran mencapai 80% dari batas atasnya. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan manajemen | Aturan peringatan pemantauan tidak diatur untuk resource produk cloud | Mencapai cakupan pemantauan resource secara penuh adalah fondasi dan kunci untuk memastikan kelangsungan bisnis. Menetapkan aturan peringatan untuk resource produk cloud adalah cara penting untuk mencapai pemantauan resource produk cloud. Akun dianggap tidak sesuai jika ada resource produk cloud yang tidak dicakup oleh aturan peringatan apa pun. | Perbaikan ini secara otomatis mengaktifkan aturan peringatan berdasarkan praktik terbaik untuk tipe resource cloud yang belum dikonfigurasi dengan Cloud Monitor. Secara default, notifikasi dikirim ke penerima pesan tipe "Kontak Peringatan Akun Alibaba Cloud". Verifikasi pengaturan sudah benar. Setelah diaktifkan, Anda dapat melihat status aktif atau memperbarui parameter peringatan di fitur peringatan satu-klik Cloud Monitor. | Tidak |
Pemantauan manajemen | Aturan peringatan prioritas tinggi tidak dikonfigurasi di ARMS | Mengkonfigurasi aturan peringatan yang efektif dapat memastikan Anda diberitahu secara tepat waktu ketika sistem bisnis tidak memenuhi kondisi operasi yang diharapkan, sehingga Anda dapat merespons darurat secara tepat waktu. Akun dianggap tidak sesuai jika tidak ada aturan peringatan level P1 yang dikonfigurasi untuk pemantauan aplikasi atau pemantauan Prometheus di Alibaba Cloud ARMS, atau jika tidak ada kebijakan notifikasi yang sesuai yang dikonfigurasi. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan manajemen | Peringatan prioritas tinggi di ARMS tidak ditangani secara tepat waktu | Metrik MTTx (Mean time to xx, seperti MTTR: Mean Time to Recovery) dapat digunakan sebagai ukuran penting efisiensi penanganan peringatan. Respons tepat waktu terhadap peringatan prioritas tinggi secara efektif dapat meningkatkan efisiensi pemulihan peringatan dan bahkan kegagalan, yang meningkatkan kualitas layanan sistem bisnis. Akun dianggap tidak sesuai jika tidak ada aturan peringatan level P1 yang dikonfigurasi untuk pemantauan aplikasi atau pemantauan Prometheus, atau jika ada peringatan di Alibaba Cloud ARMS yang belum diselesaikan dalam 30 menit (menunggu klaim, sedang dalam proses, atau diselesaikan setelah lebih dari 30 menit). | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan manajemen | Aturan peringatan dengan peringatan berkelanjutan tidak ditangani secara tepat waktu | Aturan peringatan yang berada dalam status peringatan secara berkelanjutan dalam waktu lama adalah masalah yang perlu diperhatikan dan dikelola. Biasanya, masalah ini perlu diselesaikan sesegera mungkin untuk mengembalikan metrik pemantauan ke tingkat normal, atau aturan peringatan perlu disesuaikan berdasarkan situasi aktual untuk menghindari banyak pesan peringatan atau kelelahan peringatan yang mengganggu pekerjaan pemantauan dan O&M normal. Akun dianggap tidak sesuai jika ada aturan peringatan yang diatur di Cloud Monitor yang berada dalam status peringatan secara berkelanjutan selama lebih dari 24 jam. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan manajemen | Pemantauan Prometheus tidak dikonfigurasi untuk klaster ACK | Menghubungkan klaster ACK ke pemantauan dapat membantu personel pengembangan dan O&M melihat status berjalan sistem, termasuk lapisan infrastruktur, lapisan kinerja kontainer, dan lainnya. Klaster ACK dianggap tidak sesuai jika "Aktifkan Pemantauan Prometheus Alibaba Cloud" tidak dikonfigurasi. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan manajemen | Pemantauan aplikasi tidak dikonfigurasi untuk klaster ACK | Untuk aplikasi berbasis distribusi dan mikroservis, Anda dapat menghubungkan ke Pemantauan Aplikasi ARMS untuk pelacakan lintas-layanan penuh dan pemantauan kinerja real-time tingkat kode guna membantu personel O&M memantau kesehatan aplikasi kapan saja. Suatu aplikasi dianggap tidak sesuai jika diterapkan di ACK atau ECS tetapi tidak terhubung ke Pemantauan Aplikasi ARMS. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan manajemen | Direkomendasikan pemantauan terpadu resource di seluruh akun Alibaba Cloud untuk ARMS | Dengan membuat instance agregasi global, Anda dapat mencapai pemantauan terpadu lintas akun. Akun dianggap tidak sesuai jika tidak menggunakan ARMS dan belum membuat instance GlobalView. | Perbaikan cepat tidak didukung. | Tidak |
Biaya
Kategori | Item pemeriksaan | Deskripsi item pemeriksaan | Deskripsi perbaikan cepat | Mendukung pengambilan keputusan terbantu |
Pemantauan biaya | Peringatan kredit tersedia tidak diaktifkan untuk akun (Baru di Model 3.0) | Jika "Peringatan Kredit Tersedia" tidak diaktifkan untuk akun di Pusat Pengguna, hal ini dapat menyebabkan risiko seperti penghentian layanan akibat pembayaran tertunda, kehilangan data, atau gangguan bisnis ketika saldo akun habis. Selain itu, tidak adanya mekanisme peringatan juga dapat menyebabkan pembengkakan biaya, yang memengaruhi manajemen anggaran perusahaan dan kepatuhan finansial. Jika "Peringatan Kredit Tersedia" tidak diaktifkan untuk akun di Pusat Pengguna, hal ini dianggap tidak sesuai. | Perbaikan ini akan mengaktifkan fitur peringatan kredit tersedia. Ketika kredit tersedia akun Anda lebih rendah dari ambang batas peringatan, Anda akan diberitahu melalui pesan teks, email, dan pesan internal ke kontak akun (hingga 5 hari berturut-turut). | Tidak |
Optimasi metode penagihan | Direkomendasikan menggunakan metode penagihan langganan atau menambahkan resource bayar sesuai pemakaian ke rencana penghematan untuk instans ECS | Kami merekomendasikan menggunakan metode penagihan langganan untuk resource yang digunakan secara stabil dalam jangka panjang. Umumnya, biaya instans ECS dengan penagihan langganan akan lebih rendah daripada penagihan bayar sesuai pemakaian. Rencana penghematan adalah paket diskon yang menawarkan diskon bayar sesuai pemakaian yang lebih rendah sebagai imbalan atas komitmen untuk menggunakan jumlah resource stabil selama periode tertentu. Jika instans ECS menggunakan metode penagihan bayar sesuai pemakaian dan belum membeli instans rencana penghematan, hal ini tidak dianggap sebagai praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi metode penagihan | Direkomendasikan menggunakan metode penagihan langganan untuk instans RDS | Kami merekomendasikan menggunakan metode penagihan langganan untuk resource yang digunakan secara stabil dalam jangka panjang. Umumnya, biaya instans RDS dengan penagihan langganan akan lebih rendah daripada penagihan bayar sesuai pemakaian. Jika instans RDS menggunakan metode penagihan bayar sesuai pemakaian, hal ini dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Situs ESA dalam keadaan abnormal | Item pemeriksaan ini memastikan bahwa situs diaktifkan untuk memastikan ESA dapat memberikan akselerasi dan perlindungan bagi situs. Jika tidak diaktifkan, hal ini tidak dianggap sebagai praktik terbaik untuk optimasi resource aplikasi. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Penggunaan resource instans ECS rendah | Menjaga penggunaan resource instans ECS pada tingkat yang wajar dalam jangka panjang adalah tugas penting dalam manajemen biaya cloud. Platform cloud menyediakan berbagai spesifikasi instans ECS bagi perusahaan. Perusahaan perlu memilih instans dengan spesifikasi yang sesuai berdasarkan kondisi siklus bisnis aktual mereka untuk mencapai pengendalian biaya instans ECS. Jika penggunaan CPU dan memori instans ECS keduanya di bawah 3% selama 30 hari berturut-turut, hal ini tidak dianggap sebagai praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Penggunaan resource disk ECS rendah | Menjaga penggunaan resource instans ECS pada tingkat yang wajar dalam jangka panjang adalah tugas penting dalam manajemen biaya cloud. Platform cloud menyediakan berbagai spesifikasi instans ECS bagi perusahaan. Perusahaan perlu memilih instans dengan spesifikasi yang sesuai berdasarkan kondisi siklus bisnis aktual mereka untuk mencapai pengendalian biaya instans ECS. Jika penggunaan disk ECS di bawah 3% selama 30 hari berturut-turut, hal ini tidak dianggap sebagai praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Penggunaan resource instans RDS rendah | Menjaga penggunaan resource instans RDS pada tingkat yang wajar dalam jangka panjang adalah tugas penting dalam manajemen biaya cloud. Platform cloud menyediakan berbagai spesifikasi instans RDS bagi perusahaan. Perusahaan perlu memilih instans dengan spesifikasi yang sesuai berdasarkan kondisi siklus bisnis aktual mereka untuk mencapai pengendalian biaya instans RDS. Jika penggunaan CPU, memori, dan disk instans RDS semuanya di bawah 3% selama 30 hari berturut-turut, hal ini tidak dianggap sebagai praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Penggunaan resource disk RDS rendah | Menjaga penggunaan resource instans RDS pada tingkat yang wajar dalam jangka panjang adalah tugas penting dalam manajemen biaya cloud. Platform cloud menyediakan berbagai spesifikasi instans RDS bagi perusahaan. Perusahaan perlu memilih instans dengan spesifikasi yang sesuai berdasarkan kondisi siklus bisnis aktual mereka untuk mencapai pengendalian biaya instans RDS. Jika penggunaan disk RDS di bawah 3% selama 30 hari berturut-turut, hal ini tidak dianggap sebagai praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans ALB yang menganggur | Jika load balancer ALB memiliki pendengar tanpa server backend yang ditambahkan, dan waktu pembuatannya lebih dari 7 hari, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans ECS yang menganggur | Jika instans ECS berada dalam status berhenti dan mode tanpa biaya untuk instans berhenti tidak diatur, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada disk ECS yang menganggur | Jika disk awan tidak digunakan dan dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans EIP yang menganggur | Jika EIP tidak diikat ke instans resource dan dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans sistem file NAS yang menganggur | Jika sistem file NAS tidak memiliki target pemasangan yang ditambahkan dan dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada NAT Gateway yang menganggur | Jika NAT Gateway tidak diikat ke EIP atau EIP yang diikat tidak memiliki entri SNAT/DNAT yang diatur, dan gateway dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans SLB yang menganggur | Jika load balancer SLB tidak memiliki pendengar yang berjalan dan dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans NAT Gateway VPC yang menganggur | Jika VPC NAT Gateway tidak diikat ke EIP, atau EIP yang diikat tidak memiliki entri SNAT/DNAT yang diatur, dan gateway dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans VPN Gateway yang menganggur | Jika VPN Gateway tidak memiliki kebijakan rute berbasis tujuan yang dikonfigurasi atau penyebaran rute BGP otomatis tidak diaktifkan, dan gateway dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans bandwidth bersama yang menganggur | Jika instans bandwidth bersama tidak diikat ke instans resource dan dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Optimasi resource aplikasi | Ada instans gambar kontainer yang menganggur | Jika instans gambar kontainer tidak memiliki namespace atau repositori gambar yang dibuat, dan instans dibuat lebih dari 7 hari lalu, maka dianggap tidak sesuai. | Perbaikan cepat tidak didukung. | Tidak |
Kebijakan biaya | Suite manajemen biaya tidak diaktifkan untuk klaster ACK | Metode tradisional tidak memiliki wawasan biaya efektif dan langkah pengendalian biaya untuk skenario cloud-native. Suite manajemen biaya menyediakan fitur seperti inspeksi pemborosan resource dan prediksi biaya resource. Jika fitur suite manajemen biaya tidak diaktifkan untuk klaster ACK, hal ini tidak dianggap sebagai praktik terbaik. | Perbaikan cepat tidak didukung. | Tidak |
Efisiensi
Kategori | Item pemeriksaan | Periksa deskripsi item | Deskripsi perbaikan cepat | Mendukung pengambilan keputusan terbantu |
Manajemen Resource | Resource terkait dibagi ke dalam grup resource berbeda | Jika resource terkait tidak ditempatkan dalam grup resource terpadu, hal ini mencegah manajemen berbasis grup resource untuk izin, keuangan, dan O&M mencakup semua resource target. Akun dianggap tidak sesuai jika ada resource terkait yang tidak berada dalam grup resource kustom yang sama. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen Resource | Tag kustom tidak digunakan untuk memberi tag resource | Melalui tag kustom, pengguna dapat lebih fleksibel mengidentifikasi, mengurutkan, dan mengatur berbagai resource. Akun dianggap tidak sesuai jika proporsi resource dengan tag kustom terhadap total resource kurang dari 75%. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen Resource | Grup resource kustom tidak digunakan untuk mengelompokkan resource | Melalui grup resource kustom, Anda dapat lebih fleksibel mengontrol akses dan penggunaan resource. Akun dianggap tidak sesuai jika proporsi resource yang termasuk dalam grup resource kustom terhadap total resource kurang dari 75%. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen Resource | Tag yang telah ditentukan sebelumnya tidak digunakan | Tag yang telah ditentukan sebelumnya adalah tag yang dibuat terlebih dahulu dan berlaku untuk semua wilayah. Menggunakan tag yang telah ditentukan sebelumnya dapat memudahkan pengikatan dan manajemen resource cloud selama fase implementasi resource. Akun dianggap tidak sesuai jika proporsi tag yang telah ditentukan sebelumnya terhadap tag kustom kurang dari 80%. | Perbaikan cepat tidak didukung. | Tidak |
Manajemen Resource | Tag pembuat tidak diaktifkan | Ketika skala resource di cloud terus berkembang, banyak orang perlu mengelola resource di cloud. Dalam skenario seperti biaya dan keamanan, penting untuk mengidentifikasi pembuat resource secara efektif guna memfasilitasi alokasi biaya atau pelacakan keamanan, serta meningkatkan efisiensi manajemen. Akun dianggap tidak sesuai jika tag pembuat tidak diaktifkan. | Tag pembuat adalah tag sistem yang secara otomatis dihasilkan dan diikat oleh Alibaba Cloud ke resource yang sesuai untuk mengidentifikasi pembuat resource. Tag pembuat dapat membantu Anda menganalisis biaya dan tagihan serta secara efektif mengelola biaya cloud perusahaan Anda. Perbaikan ini mengaktifkan tag pembuat untuk akun saat ini. | Tidak |
Manajemen Resource | Direkomendasikan mengaktifkan fitur pencarian resource multi-akun | Menggunakan direktori resource untuk mengelola beberapa akun Alibaba Cloud, akun manajemen atau akun administrator yang didelegasikan dapat melihat dan mencari resource cloud semua anggota dalam direktori resource. Akun dianggap tidak sesuai jika pencarian resource lintas akun tidak diaktifkan. | Perbaikan cepat tidak didukung. | Tidak |
Sistem akun | Akun tidak dikelola oleh direktori resource | Dibandingkan dengan manajemen terdesentralisasi beberapa akun, manajemen terpusat beberapa akun dapat memberikan nilai bagi perusahaan dalam hal izin, keamanan, dan biaya. Akun dianggap tidak sesuai jika tidak termasuk dalam direktori resource mana pun. | Perbaikan cepat tidak didukung. | Tidak |
Sistem akun | Direkomendasikan manajemen terpusat kontak pesan multi-akun | Melalui fitur manajemen kontak pesan direktori resource, Anda dapat mencapai manajemen terpusat kontak pesan lintas akun. Akun dianggap tidak sesuai jika tidak ada kontak pesan direktori resource yang terdeteksi atau kontak pesan tidak diikat ke direktori resource, folder resource, atau anggota. | Perbaikan cepat tidak didukung. | Tidak |
Sistem akun | Direkomendasikan menetapkan akun administrator yang didelegasikan untuk direktori resource tempat akun berada | Menggunakan akun administrator yang didelegasikan dapat memisahkan tugas manajemen organisasi dari tugas manajemen bisnis. Akun manajemen menjalankan tugas manajemen organisasi untuk direktori resource, dan akun administrator yang didelegasikan menjalankan tugas manajemen bisnis untuk layanan tepercaya. Akun dianggap tidak sesuai jika akun administrator yang didelegasikan tidak diatur dalam layanan tepercaya yang diaktifkan oleh akun manajemen direktori resource (MA). | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API ACK yang telah ditinggalkan | API ACK yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API ACK yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API ALB yang telah ditinggalkan | API ALB yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API ALB yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API CDN yang telah ditinggalkan | API CDN yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API CDN yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API CEN yang telah ditinggalkan | API CEN yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API CEN yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API ECS yang telah ditinggalkan | API ECS yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API ECS yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API NAS yang telah ditinggalkan | API NAS yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API NAS yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API PolarDB yang telah ditinggalkan | API PolarDB yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API PolarDB yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API RDS yang telah ditinggalkan | API RDS yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API RDS yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API Redis yang telah ditinggalkan | API Redis yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API Redis yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API RocketMQ yang telah ditinggalkan | API RocketMQ yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API RocketMQ yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API SLB yang telah ditinggalkan | API SLB yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API SLB yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Pengguna memanggil API VPC yang telah ditinggalkan | API VPC yang telah ditinggalkan tidak lagi dipelihara, memiliki risiko stabilitas, dan tidak dapat menggunakan fitur baru. Akun dianggap tidak sesuai jika telah terjadi panggilan ke API VPC yang telah ditinggalkan dalam 30 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Direkomendasikan menggunakan metode otomatis untuk manajemen resource berkelanjutan | Akun dianggap tidak sesuai jika rasio jumlah panggilan OpenAPI untuk mengelola resource secara berkelanjutan menggunakan metode non-konsol dalam 30 hari terakhir belum mencapai 100%. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Direkomendasikan menggunakan metode otomatis untuk penyediaan resource harian | Akun dianggap tidak sesuai jika rasio jumlah panggilan OpenAPI untuk membuat resource menggunakan metode non-konsol dalam satu tahun terakhir belum mencapai 100%. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Direkomendasikan menggunakan metode otomatis untuk mengelola resource | Akun dianggap tidak sesuai jika rasio panggilan OpenAPI yang dilakukan menggunakan sarana otomatis seperti SDK, Terraform, Cloud Control API, CADT, ROS, dan Katalog Layanan dalam 30 hari terakhir belum mencapai 100%. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Tingkat keberhasilan antarmuka pembuatan resource belum mencapai 100% | Akun dianggap tidak sesuai jika tingkat keberhasilan membuat resource infrastruktur menggunakan sarana otomatis seperti OpenAPI, Cloud Control API, SDK, atau Terraform dalam 30 hari terakhir belum mencapai 100%. | Perbaikan cepat tidak didukung. | Tidak |
Penyediaan dan orkestrasi resource | Tingkat keberhasilan antarmuka perubahan resource belum mencapai 100% | Akun dianggap tidak sesuai jika tingkat keberhasilan mengubah resource infrastruktur menggunakan sarana otomatis seperti OpenAPI, Cloud Control API, SDK, atau Terraform dalam 30 hari terakhir belum mencapai 100%. | Perbaikan cepat tidak didukung. | Tidak |
Kinerja
Kategori | Item pemeriksaan | Deskripsi item pemeriksaan | Deskripsi perbaikan cepat | Mendukung pengambilan keputusan terbantu |
Pemantauan kinerja | EIP yang terkait dengan ALB berisiko beban kinerja tinggi (Baru di Model 3.0) | Ketika penggunaan bandwidth keluar EIP yang terkait dengan instans ALB terlalu tinggi dalam waktu lama, hal ini menyebabkan penurunan kinerja sistem, pengurangan stabilitas, dan bahkan gangguan layanan. Disarankan untuk memperhatikan danmenanganinya secara tepat waktu. Instans ALB dianggap tidak sesuai jika penggunaan bandwidth keluar maksimum EIP yang terkait dengannya lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam 24 jam terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Bandwidth bersama yang terkait dengan ALB berisiko beban kinerja tinggi (Baru di Model 3.0) | Ketika penggunaan bandwidth keluar instans bandwidth bersama yang terkait dengan instans ALB terlalu tinggi dalam waktu lama, hal ini menyebabkan penurunan kinerja sistem, pengurangan stabilitas, dan bahkan gangguan layanan. Disarankan untuk memperhatikan dan menanganinya secara tepat waktu. Instans ALB dianggap tidak sesuai jika penggunaan bandwidth keluar maksimum instans bandwidth bersama yang terkait dengannya lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam 24 jam terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Disk awan EBS berisiko kinerja karena throughput tinggi | Hal ini membantu pelanggan mencegah hambatan kinerja, mengevaluasi apakah alokasi resource penyimpanan wajar, dan apakah perluasan diperlukan untuk memastikan kelangsungan bisnis. Disk awan EBS dianggap tidak sesuai jika penggunaan IOPS atau BPS-nya dalam 24 jam terakhir melebihi 90% dari IOPS atau BPS tipe disk awan tersebut. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Disk awan EBS berisiko kinerja karena penggunaan ruang tinggi | Penggunaan ruang disk yang terlalu tinggi dapat meningkatkan risiko kehilangan data. Hal ini membantu pelanggan menemukan potensi hambatan kinerja lebih awal dan mengambil langkah-langkah untuk menghindari penurunan kinerja. Disk awan EBS dianggap tidak sesuai jika penggunaan ruangnya melebihi 80%. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Instans ECS berisiko kinerja karena penggunaan CPU tinggi | Memastikan penggunaan CPU produk cloud inti ECS berada pada tingkat sehat adalah dasar untuk memastikan kinerja bisnis yang stabil dan operasi berkelanjutan. Beban tinggi tidak hanya menyebabkan respons aplikasi melambat, tetapi juga dapat memicu mekanisme perlindungan otomatis, seperti restart otomatis sistem atau penurunan layanan. Instans ECS dianggap tidak sesuai jika penggunaan CPU-nya terlalu tinggi, yaitu penggunaan CPU lebih besar dari 85% selama total kumulatif lebih dari 8 jam dalam 24 jam terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Instans ECS berisiko kinerja karena penggunaan memori tinggi | Memastikan penggunaan memori produk cloud inti ECS berada pada tingkat sehat untuk menghindari risiko penurunan kinerja atau gangguan layanan akibat memori tidak mencukupi. Instans ECS dianggap tidak sesuai jika penggunaan memorinya terlalu tinggi, yaitu penggunaan memori ECS lebih besar dari 85% selama total kumulatif lebih dari 9 jam dalam 24 jam terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Instans RDS berisiko beban kinerja tinggi (Baru di Model 3.0) | Ketika salah satu dari CPU, memori, dan jumlah koneksi instans RDS terlalu tinggi dalam waktu lama, hal ini menyebabkan penurunan kinerja sistem, pengurangan stabilitas, dan bahkan gangguan layanan. Disarankan untuk memperhatikan dan menanganinya secara tepat waktu. Instans RDS dianggap tidak sesuai jika rata-rata penggunaan salah satu metrik CPU, memori, penggunaan jumlah koneksi, atau IOPS lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Instans Redis berisiko beban kinerja tinggi (Baru di Model 3.0) | Ketika penggunaan CPU atau memori instans Redis terus-menerus tinggi dalam periode waktu tertentu, hal ini dapat menyebabkan penurunan kinerja sistem, pengurangan stabilitas, dan bahkan gangguan layanan. Disarankan untuk memperhatikan dan menanganinya secara tepat waktu. Instans Redis dianggap tidak sesuai jika rata-rata penggunaan CPU atau memori lebih besar dari atau sama dengan 80% selama total kumulatif lebih dari 8 jam dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Instans SLB berisiko beban kinerja tinggi (Baru di Model 3.0) | Ketika penggunaan salah satu dari jumlah koneksi maksimum, koneksi baru, dan lalu lintas keluar melalui Internet instans SLB terlalu tinggi dalam waktu lama, hal ini menyebabkan penurunan kinerja sistem, pengurangan stabilitas, dan bahkan gangguan layanan. Disarankan untuk memperhatikan dan menanganinya secara tepat waktu. Instans SLB dianggap tidak sesuai jika rata-rata penggunaan salah satu metrik penggunaan jumlah koneksi maksimum instans, koneksi baru, atau penggunaan lalu lintas keluar melalui Internet lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam 7 hari terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Pemantauan kinerja | Gateway VPN berisiko beban kinerja tinggi (Baru di Model 3.0) | Ketika penggunaan bandwidth masuk atau keluar Gateway VPN terlalu tinggi dalam waktu lama, hal ini menyebabkan penurunan kinerja sistem, pengurangan stabilitas, dan bahkan gangguan layanan. Disarankan untuk memperhatikan dan menanganinya secara tepat waktu. Gateway VPN dianggap tidak sesuai jika nilai maksimum penggunaan bandwidth masuk atau keluarnya lebih besar dari atau sama dengan 80% selama minimal 8 jam dalam 24 jam terakhir. | Perbaikan cepat tidak didukung. | Tidak |
Manfaatkan resource elastis | Grup penskalaan ECS berisiko tidak dapat melakukan penskalaan otomatis untuk kinerja | Produk cloud inti seperti resource ECS dapat secara otomatis menambah atau mengurangi resource berdasarkan beban kinerja, yang memastikan keseimbangan dinamis selama operasi bisnis. | Perbaikan cepat tidak didukung. | Tidak |
Manfaatkan resource elastis | Penskalaan otomatis tidak diaktifkan untuk RDS (Baru di Model 3.0) | Jika fitur penskalaan otomatis tidak diaktifkan untuk instans RDS, instans tersebut mungkin tidak dapat memperluas resource tepat waktu untuk mengatasi pertumbuhan beban selama jam sibuk bisnis, atau tidak dapat melepaskan resource menganggur selama jam sepi. Hal ini menyebabkan hambatan kinerja, keterlambatan respons, dan bahkan gangguan layanan, sekaligus menyebabkan pemborosan resource dan pengeluaran biaya yang tidak perlu. Mengaktifkan fitur penskalaan otomatis membantu pelanggan mencapai penjadwalan elastis dan pemanfaatan resource yang efisien, yang mengoptimalkan struktur biaya sekaligus memastikan stabilitas dan ketersediaan tinggi database, serta meningkatkan tingkat kecerdasan manajemen resource cloud. Instans RDS dianggap tidak sesuai jika penskalaan otomatis tidak diaktifkan. | Perbaikan ini mengaktifkan fitur ekspansi penyimpanan otomatis untuk instans RDS. Setelah diaktifkan, ruang penyimpanan akan diperluas secara otomatis saat mencapai ambang batas. Instans tidak perlu di-restart selama proses ekspansi, dan tidak ada dampak terhadap bisnis. | Tidak |
Desain jaringan | Aturan cache tidak dikonfigurasi untuk situs ESA | Item pemeriksaan ini memastikan bahwa situs memiliki aturan cache yang dikonfigurasi untuk mengurangi lalu lintas pengambilan origin. Jika tidak dikonfigurasi, hal ini tidak dianggap sebagai praktik terbaik untuk optimasi jaringan. | Perbaikan cepat tidak didukung. | Tidak |
Desain jaringan | Smart Routing tidak diaktifkan untuk situs ESA di wilayah global | Item pemeriksaan ini memastikan bahwa situs memiliki Smart Routing yang diaktifkan untuk meningkatkan efek akselerasi ESA di wilayah global. Jika tidak diaktifkan, hal ini tidak dianggap sebagai praktik terbaik untuk optimasi jaringan. | Perbaikan ini mengaktifkan layanan Smart Routing untuk situs yang dipilih. Setelah layanan ini diaktifkan, layanan tersebut melakukan deteksi jaringan real-time berdasarkan node tepi global Alibaba Cloud, secara cerdas memilih rute terbaik untuk transmisi data permintaan berdasarkan kondisi jaringan real-time, dan menggabungkannya dengan teknologi optimasi seperti stack protokol berkinerja tinggi untuk sangat mengurangi latensi jaringan global dan tingkat kegagalan permintaan, yang secara efektif meningkatkan pengalaman pengguna. Smart Routing ditagih berdasarkan jumlah permintaan. Untuk standar penagihan spesifik, lihat Penagihan. | Tidak |
Desain jaringan | CDN tidak digunakan untuk mempercepat akses ke resource OSS (Baru di Model 3.0) | Menggunakan CDN untuk mendistribusikan resource statis seperti gambar, video, dan dokumen di OSS dapat mengurangi biaya lalu lintas dan meningkatkan kecepatan pemuatan resource. CDN menempatkan node cache di berbagai wilayah di seluruh dunia. Saat pengguna meminta mengakses resource statis di OSS, CDN mengarahkan permintaan pengguna ke node cache terdekat, tanpa perlu permintaan jarak jauh untuk langsung mengakses resource OSS. Pada saat yang sama, node CDN terdekat mengembalikan resource yang di-cache kepada pengguna, tanpa perlu mengambil dari origin OSS. Proses ini menghasilkan biaya lalu lintas hilir CDN. Dibandingkan dengan lalu lintas keluar Internet OSS, harga satuan lalu lintas hilir CDN lebih rendah. Bucket OSS dianggap tidak sesuai jika lalu lintas masuk jaringan publiknya melebihi 100 B dalam 24 jam, tetapi CDN tidak digunakan untuk mengoptimalkan transmisi data OSS. | Perbaikan cepat tidak didukung. | Tidak |
Item pemeriksaan yang dihapus
Beberapa item pemeriksaan dari Model 2.0 telah digabungkan ke dalam Model 3.0 yang baru. Model 3.0 yang baru mencakup deteksi risiko terkait, sehingga item pemeriksaan berikut telah dihapus dari Model 3.0 yang baru.
Pilar | Kategori | Item pemeriksaan | Periksa deskripsi item |
Keamanan | Cegah penyalahgunaan hak istimewa | Terlalu banyak identitas RAM diberikan izin berisiko tinggi untuk OSS dan SLS | Untuk manajemen izin identitas RAM, kami merekomendasikan mengikuti prinsip hak istimewa minimal dengan hanya memberikan izin yang diperlukan. Salah urus izin berisiko tinggi dapat menyebabkan kehilangan data atau akses data tidak sah. Misalnya, identitas RAM dengan izin seperti `oss:Delete*` atau `log:Delete*` dapat menghapus data yang disimpan di OSS atau SLS. Identitas RAM dengan izin seperti `oss:PutBucketAcl`, `oss:PutObjectAcl`, atau `oss:PutBucketPolicy` dapat memodifikasi izin akses file dalam bucket OSS, yang dapat mengekspos file ke akses eksternal. Akun dengan tiga atau kurang identitas RAM yang memiliki izin berisiko tinggi ini dianggap sesuai. |
Keamanan | Cegah penyalahgunaan hak istimewa | Terlalu banyak identitas RAM diberikan izin berisiko tinggi untuk direktori resource | Dengan menggunakan direktori resource, Anda dapat mencapai manajemen terpadu akun dalam organisasi, membuat akun baru berdasarkan organisasi saat ini, atau menghapus akun yang ada dari organisasi saat ini. Menurut praktik terbaik, hanya administrator atau pemimpin tim manajemen cloud dalam organisasi yang harus memiliki izin operasi tulis untuk direktori resource, seperti mengaktifkan atau menonaktifkan direktori resource, membuat, mengundang, atau menghapus akun, dan mengganti tipe akun. Biasanya, tidak boleh lebih dari 3 orang dalam perusahaan dengan fungsi ini. Tidak disarankan untuk memberikan izin operasi tulis yang sesuai untuk direktori resource kepada pengguna biasa. Jika tidak, hal ini dapat menyebabkan kerusakan bisnis akibat kesalahan operasi seperti menghapus akun cloud. |
Keamanan | Gunakan otorisasi detail halus | Ada identitas RAM dengan cakupan akses operasi yang digabungkan | Untuk manajemen izin identitas RAM, kami merekomendasikan mengikuti prinsip hak istimewa minimal dengan hanya memberikan izin yang diperlukan. Akun dianggap sesuai jika identitas RAM terikat pada beberapa izin operasi layanan cloud. |
Keamanan | Gunakan otorisasi detail halus | Tidak ada identitas RAM dengan akses gabungan ke OSS dan SLS | Untuk manajemen izin identitas RAM, kami merekomendasikan mengikuti prinsip hak istimewa minimal dengan hanya memberikan izin yang diperlukan. Terutama untuk akses ke produk data, seperti OSS dan SLS, kami merekomendasikan otorisasi detail halus untuk mengurangi risiko pelanggaran data akibat kompromi identitas. Jika identitas RAM terikat pada izin operasi terkait produk data, otorisasi detail halus harus dilakukan. Jangan gunakan karakter wildcard * untuk otorisasi batch. Hal ini dianggap sesuai. |
Keamanan | Efisiensi dan kontrol otorisasi | Cakupan efektif kebijakan kustom yang diberikan kepada identitas RAM tidak menentukan grup resource | Secara default, cakupan efektif saat memberikan kebijakan kustom kepada identitas RAM adalah di tingkat akun. Dalam kasus ini, jika kebijakan kustom tidak secara eksplisit membatasi resource tertentu atau menentukan kondisi efektif izin, identitas RAM memiliki izin yang ditentukan untuk semua resource di bawah akun. Menurut praktik terbaik manajemen resource cloud, resource harus dikelompokkan berdasarkan grup resource, dan identitas RAM harus diberi otorisasi berdasarkan grup tersebut. Selama proses otorisasi, dengan membatasi cakupan efektif ke grup resource, Anda dapat lebih baik membatasi cakupan izin identitas RAM dan mencapai otorisasi detail halus. Dianggap sebagai praktik terbaik jika cakupan efektif kebijakan kustom yang diberikan kepada identitas RAM adalah grup resource, atau jika grup resource ditentukan dalam kondisi kebijakan. |
Keamanan | Efisiensi dan kontrol otorisasi | Tidak ada otorisasi identitas RAM dengan kebijakan sistem tingkat layanan yang digabungkan ke grup resource | Untuk manajemen izin identitas RAM, kami merekomendasikan mengikuti prinsip hak istimewa minimal dengan hanya memberikan izin yang diperlukan. Dengan membagi resource cloud ke dalam grup resource berdasarkan dimensi seperti aplikasi dan lingkungan, Anda dapat memberikan otorisasi berdasarkan grup resource selama otorisasi, yang lebih lanjut mempersempit cakupan izin dan menghindari risiko yang dibawa oleh izin berlebihan. Akun dianggap sesuai jika identitas RAM dengan kebijakan sistem tingkat layanan seperti AliyunECSFullAccess memiliki cakupan otorisasi grup resource. |
Keamanan | Efisiensi dan kontrol otorisasi | Tidak ada otorisasi identitas RAM dengan izin Admin yang digabungkan ke grup resource | Untuk manajemen izin identitas RAM, kami merekomendasikan mengikuti prinsip hak istimewa minimal dengan hanya memberikan izin yang diperlukan. Dengan membagi resource cloud ke dalam grup resource berdasarkan dimensi seperti aplikasi dan lingkungan, Anda dapat memberikan otorisasi berdasarkan grup resource selama otorisasi, yang lebih lanjut mempersempit cakupan izin dan menghindari risiko yang dibawa oleh izin berlebihan. Akun dianggap sesuai jika identitas RAM dengan izin AdministratorAccess memiliki cakupan otorisasi grup resource. |
Keamanan | Respons peringatan tidak sesuai | Aturan peringatan tidak diatur untuk event operasi berisiko | Akun dianggap tidak sesuai jika tidak ada aturan terkait keamanan akun atau kepatuhan operasi ActionTrail yang didukung dalam peringatan event ActionTrail yang diaktifkan. |
Keamanan | Aktifkan koreksi otomatis | Metode otomatis tidak digunakan untuk memperbaiki masalah ketidaksesuaian | Akun dianggap tidak sesuai jika pengguna belum mengaktifkan koreksi otomatis untuk aturan apa pun. |
Keamanan | Instans penyimpanan data harus menghindari akses jaringan publik | Daftar putih IP klaster PolarDB diatur ke 0.0.0.0/0 | Daftar putih IP adalah daftar IP yang diizinkan mengakses klaster PolarDB. Jika daftar putih IP diatur ke % atau 0.0.0.0/0, artinya alamat IP apa pun diizinkan mengakses klaster database. Pengaturan ini sangat mengurangi keamanan database dan tidak boleh digunakan kecuali diperlukan. Praktik terbaik merekomendasikan mengikuti prinsip hak istimewa minimal dan menetapkan daftar putih IP yang sesuai untuk memberikan perlindungan keamanan akses tingkat tinggi bagi klaster PolarDB. Tidak dianggap sebagai praktik terbaik jika daftar putih IP klaster diatur ke 0.0.0.0/0 atau %. |
Keamanan | Instans penyimpanan data harus menghindari akses jaringan publik | Daftar putih IP instans RDS diatur ke 0.0.0.0/0 | Daftar putih IP adalah daftar IP yang diizinkan mengakses instans RDS. Jika daftar putih IP diatur ke 0.0.0.0/0, artinya alamat IP apa pun diizinkan mengakses klaster database. Pengaturan ini sangat mengurangi keamanan database dan tidak boleh digunakan kecuali diperlukan. Praktik terbaik merekomendasikan mengikuti prinsip hak istimewa minimal dan menetapkan daftar putih IP yang sesuai untuk memberikan perlindungan keamanan akses tingkat tinggi bagi instans database. Tidak dianggap sebagai praktik terbaik jika daftar putih IP instans diatur ke 0.0.0.0/0. |
Keamanan | Instans penyimpanan data harus menghindari akses jaringan publik | Daftar putih IP instans Redis diatur ke 0.0.0.0/0 | Daftar putih IP adalah daftar IP yang diizinkan mengakses instans Redis. Jika daftar putih IP diatur ke 0.0.0.0/0, artinya alamat IP apa pun diizinkan mengakses klaster database. Pengaturan ini sangat mengurangi keamanan database dan tidak boleh digunakan kecuali diperlukan. Praktik terbaik merekomendasikan mengikuti prinsip hak istimewa minimal dan menetapkan daftar putih IP yang sesuai untuk memberikan perlindungan keamanan akses tingkat tinggi bagi instans database. Tidak dianggap sebagai praktik terbaik jika daftar putih IP instans diatur ke 0.0.0.0/0. |
Keamanan | Instans penyimpanan data harus menghindari akses jaringan publik | Daftar putih IP instans MongoDB diatur ke 0.0.0.0/0 | Daftar putih IP adalah daftar IP yang diizinkan mengakses instans MongoDB. Jika daftar putih IP diatur ke 0.0.0.0/0, artinya alamat IP apa pun diizinkan mengakses klaster database. Pengaturan ini sangat mengurangi keamanan database dan tidak boleh digunakan kecuali diperlukan. Praktik terbaik merekomendasikan mengikuti prinsip hak istimewa minimal dan menetapkan daftar putih IP yang sesuai untuk memberikan perlindungan keamanan akses tingkat tinggi bagi instans database. Tidak dianggap sebagai praktik terbaik jika daftar putih IP instans diatur ke 0.0.0.0/0. |
Keamanan | Instans penyimpanan data harus menghindari akses jaringan publik | Daftar putih IP instans Elasticsearch diatur ke 0.0.0.0/0 | Daftar putih IP instans adalah daftar IP yang diizinkan mengakses instans Elasticsearch. Jika daftar putih IP diatur ke 0.0.0.0/0 atau ::/0, artinya alamat IP apa pun diizinkan mengakses instans tersebut. Pengaturan ini sangat mengurangi keamanan instans dan tidak boleh digunakan kecuali diperlukan. Praktik terbaik merekomendasikan mengikuti prinsip hak istimewa minimal dan menetapkan daftar putih IP yang sesuai untuk memberikan perlindungan keamanan akses tingkat tinggi bagi instans tersebut. Tidak dianggap sebagai praktik terbaik jika daftar putih IP instans diatur ke 0.0.0.0/0 atau ::/0. |
Stabilitas | Perlindungan penghapusan | Perlindungan rilis tidak diaktifkan untuk resource Redis | Instans Redis dianggap tidak sesuai jika perlindungan rilis tidak diaktifkan. |
Stabilitas | Perlindungan penghapusan | Perlindungan rilis tidak diaktifkan untuk resource ECS | Instans ECS dianggap tidak sesuai jika perlindungan rilis tidak diaktifkan. |
Stabilitas | Manajemen perubahan | Jendela pemeliharaan untuk resource Redis tidak wajar | Instans Redis dianggap tidak sesuai jika periode pencadangan otomatisnya tidak berada dalam rentang 04:00-05:00, 05:00-06:00, atau 12:00-13:00. |
Stabilitas | Manajemen perubahan | Jendela pemeliharaan untuk resource PolarDB tidak wajar | Klaster PolarDB dianggap tidak sesuai jika jendela pemeliharaannya tidak berada dalam rentang 02:00-04:00 atau 06:00-10:00. |
Stabilitas | Manajemen perubahan | Jendela pemeliharaan untuk resource ADB tidak wajar | Klaster ADB dianggap tidak sesuai jika jendela pemeliharaannya tidak berada dalam rentang 02:00-04:00, 06:00-08:00, atau 12:00-13:00. |
Stabilitas | Manajemen perubahan | Jendela pemeliharaan untuk resource RDS tidak wajar | Instans RDS dianggap tidak sesuai jika jendela pemeliharaannya tidak berada dalam rentang 02:00-06:00 atau 06:00-10:00. |
Stabilitas | Manajemen perubahan | Jendela pemeliharaan untuk resource ECS tidak wajar | Membuat snapshot untuk instans ECS sementara mengurangi kinerja I/O penyimpanan blok. Kebijakan snapshot otomatis dianggap tidak sesuai jika waktu pembuatan snapshot tidak berada dalam rentang 1 atau 2. |
Biaya | Optimasi biaya resource | Paket kepatuhan "Praktik Terbaik untuk Deteksi Resource Menganggur" tidak diaktifkan | Akun dianggap tidak sesuai jika paket kepatuhan deteksi resource menganggur tidak diaktifkan di Cloud Config. |
Efisiensi | Pengelompokan dan isolasi resource | Beberapa akun tidak digunakan untuk mengelola resource dalam organisasi yang sama | Akun Alibaba Cloud memiliki banyak makna. Setiap akun cloud adalah penyewa yang sepenuhnya terisolasi, dan secara default, akses resource, penyebaran jaringan, dan izin identitas sepenuhnya independen dan terisolasi. Akun cloud juga dikaitkan dengan tagihan, sehingga layanan berbeda dapat ditempatkan di akun cloud berbeda untuk mencapai akuntansi dan penagihan independen. Menggunakan manajemen multi-akun dapat memberikan manfaat bagi perusahaan dalam hal isolasi lingkungan, kepatuhan keamanan, dan inovasi bisnis. Kondisi terpenuhi jika ada dua atau lebih akun Alibaba Cloud di bawah entitas yang sama. |
Efisiensi | Kualitas otomatisasi | Kuota ECS berisiko jenuh | Pembuatan, perubahan, atau penggunaan fitur produk resource dapat mengalami pengecualian. Produk dianggap berisiko jika memiliki item kuota resource dengan tingkat kuota tinggi dalam 7 hari terakhir dan telah mengalami error quota_exceed. |
Efisiensi | Kualitas otomatisasi | Kuota VPC berisiko jenuh | Pembuatan, perubahan, atau penggunaan fitur produk resource dapat mengalami pengecualian. Produk dianggap berisiko jika memiliki item kuota resource dengan tingkat kuota tinggi dalam 7 hari terakhir dan telah mengalami error quota_exceed. |
Efisiensi | Kualitas otomatisasi | Kuota SLB berisiko jenuh | Pembuatan, perubahan, atau penggunaan fitur produk resource dapat mengalami pengecualian. Produk dianggap berisiko jika memiliki item kuota resource dengan tingkat kuota tinggi dalam 7 hari terakhir dan telah mengalami error quota_exceed. |
Efisiensi | Kualitas otomatisasi | Kuota CEN berisiko jenuh | Pembuatan, perubahan, atau penggunaan fitur produk resource dapat mengalami pengecualian. Produk dianggap berisiko jika memiliki item kuota resource dengan tingkat kuota tinggi dalam 7 hari terakhir dan telah mengalami error quota_exceed. |
Efisiensi | Kualitas otomatisasi | Kuota ACK berisiko jenuh | Pembuatan, perubahan, atau penggunaan fitur produk resource dapat mengalami pengecualian. Produk dianggap berisiko jika memiliki item kuota resource dengan tingkat kuota tinggi dalam 7 hari terakhir dan telah mengalami error quota_exceed. |
Efisiensi | Kualitas otomatisasi | Kuota CDN berisiko jenuh | Pembuatan, perubahan, atau penggunaan fitur produk resource dapat mengalami pengecualian. Produk dianggap berisiko jika memiliki item kuota resource dengan tingkat kuota tinggi dalam 7 hari terakhir dan telah mengalami error quota_exceed. |