Prinsip desain beban kerja misi-kritis
Metodologi desain misi-kritis didukung oleh lima prinsip desain utama yang berfungsi sebagai kompas untuk keputusan desain berikutnya di seluruh area desain penting. Kami sangat menyarankan Anda membiasakan diri dengan prinsip-prinsip ini untuk lebih memahami dampaknya dan trade-off yang terkait dengan ketidakpatuhan.
Penting
Artikel ini adalah bagian dari seri beban kerja azure Well-Architected misi penting . Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan apa itu beban kerja misi penting?
Prinsip-prinsip desain misi penting ini beresonansi dan memperluas pilar kualitas Azure Well-Architected Framework—Keandalan, Keamanan, Pengoptimalan Biaya, Keunggulan Operasional, dan Efisiensi Performa.
Keandalan
Keandalan maksimum - Pengejaran mendasar dari solusi yang paling dapat diandalkan, memastikan trade-off dipahami dengan benar.
| Prinsip desain | Pertimbangan |
|---|---|
| Desain Aktif/Aktif | Untuk memaksimalkan ketersediaan dan mencapai toleransi kesalahan regional, komponen solusi harus didistribusikan di beberapa Zona Ketersediaan dan wilayah Azure menggunakan model penyebaran aktif/aktif jika memungkinkan. |
| Pengurangan radius ledakan dan isolasi kesalahan | Kegagalan tidak mungkin dihindari di lingkungan cloud multi-penyewa yang sangat terdistribusi seperti Azure. Dengan mengantisipasi kegagalan dan dampak yang berkorelasi, dari komponen individual ke seluruh wilayah Azure, solusi dapat dirancang dan dikembangkan dengan cara yang tangguh. |
| Amati kesehatan aplikasi | Sebelum masalah yang berdampak pada keandalan aplikasi dapat dimitigasi, mereka harus terlebih dahulu terdeteksi dan dipahami. Dengan memantau pengoperasian aplikasi relatif terhadap keadaan sehat yang diketahui, menjadi mungkin untuk mendeteksi atau bahkan memprediksi masalah keandalan, memungkinkan tindakan perbaikan cepat diambil. |
| Otomatisasi drive | Salah satu penyebab utama waktu henti aplikasi adalah kesalahan manusia, apakah itu karena penyebaran perangkat lunak yang tidak cukup teruji atau kesalahan konfigurasi. Untuk meminimalkan kemungkinan dan dampak kesalahan manusia, sangat penting untuk mengupayakan otomatisasi di semua aspek solusi cloud untuk meningkatkan keandalan; pengujian, penyebaran, dan manajemen otomatis. |
| Desain untuk penyembuhan diri | Penyembuhan diri menggambarkan kemampuan sistem untuk menangani kegagalan secara otomatis melalui protokol remediasi yang telah ditentukan sebelumnya yang terhubung ke mode kegagalan dalam solusi. Ini adalah konsep lanjutan yang membutuhkan tingkat kematangan sistem yang tinggi dengan pemantauan dan otomatisasi, tetapi harus menjadi aspirasi dari awal untuk memaksimalkan keandalan. |
| Penghindarian kompleksitas | Hindari kompleksitas yang tidak perlu saat merancang solusi dan semua proses operasional untuk mendorong keandalan dan efisiensi manajemen, meminimalkan kemungkinan kegagalan. |
Efisiensi Performa
Performa dan skalabilitas berkelanjutan - Desain untuk skalabilitas di seluruh solusi end-to-end tanpa hambatan performa.
| Prinsip desain | Pertimbangan |
|---|---|
| Desain untuk peluasan skala | Peluasan skala adalah konsep yang berfokus pada kemampuan sistem untuk merespons permintaan melalui pertumbuhan horizontal. Ini berarti bahwa seiring pertumbuhan lalu lintas, lebih banyak unit sumber daya ditambahkan secara paralel alih-alih meningkatkan ukuran sumber daya yang ada. Kemampuan sistem untuk menangani peningkatan lalu lintas yang diharapkan dan tidak terduga melalui unit skala sangat penting untuk performa dan keandalan secara keseluruhan dengan mengurangi dampak kegagalan sumber daya tunggal lebih lanjut. |
| Otomatisasi untuk hyperscale | Operasi skala di seluruh solusi harus sepenuhnya otomatis untuk meminimalkan dampak performa dan ketersediaan dari peningkatan lalu lintas yang tidak terduga atau diharapkan, memastikan waktu yang diperlukan untuk melakukan operasi skala dipahami dan selaras dengan model untuk kesehatan aplikasi. |
| Validasi dan pengujian berkelanjutan | Pengujian otomatis harus dilakukan dalam proses CI/CD untuk mendorong validasi berkelanjutan untuk setiap perubahan aplikasi. Pengujian beban terhadap garis besar performa dengan eksperimen chaos yang disinkronkan harus disertakan untuk memvalidasi ambang batas, target, dan asumsi yang ada, serta membantu mengidentifikasi risiko dengan cepat terhadap ketahanan dan ketersediaan. Pengujian tersebut harus dilakukan dalam lingkungan pementasan dan pengujian, tetapi juga secara opsional dalam lingkungan pengembangan. Ini juga dapat bermanfaat untuk menjalankan subset pengujian terhadap lingkungan produksi, terutama bersama dengan model penyebaran biru/hijau untuk memvalidasi stempel penyebaran baru sebelum menerima lalu lintas produksi. |
| Mengurangi overhead dengan layanan komputasi terkelola | Menggunakan layanan komputasi terkelola dan arsitektur kontainer secara signifikan mengurangi overhead administratif dan operasional yang sedang berlangsung dari merancang, mengoperasikan, dan menskalakan aplikasi dengan mengalihkan penyebaran dan pemeliharaan infrastruktur ke penyedia layanan terkelola. |
| Performa garis besar dan mengidentifikasi hambatan | Pengujian performa dengan telemetri terperinci dari setiap komponen sistem memungkinkan identifikasi hambatan dalam sistem, termasuk komponen yang perlu diskalakan dalam kaitannya dengan komponen lain, dan informasi ini harus dimasukkan ke dalam model kapasitas. |
| Kapasitas model | Model kapasitas memungkinkan perencanaan tingkat skala sumber daya untuk profil beban tertentu, dan juga mengekspos performa komponen sistem dalam kaitannya satu sama lain, sehingga memungkinkan perencanaan alokasi kapasitas di seluruh sistem. |
Keunggulan Operasional
Operasi berdasarkan desain - Direkayasa untuk bertahan dengan manajemen operasional yang kuat dan tegas.
| Prinsip desain | Pertimbangan |
|---|---|
| Komponen yang digabungkan secara longgar | Coupling longgar memungkinkan pengujian, penyebaran, dan pembaruan independen dan sesuai permintaan pada komponen aplikasi sambil meminimalkan dependensi antar-tim untuk dukungan, layanan, sumber daya, atau persetujuan. |
| Mengotomatiskan proses build dan rilis | Proses build dan rilis yang sepenuhnya otomatis mengurangi gesekan dan meningkatkan kecepatan penyebaran pembaruan, menghadirkan pengulangan dan konsistensi di seluruh lingkungan. Automation mempersingkat perulangan umpan balik dari pengembang yang mendorong perubahan untuk mendapatkan wawasan tentang kualitas kode, cakupan pengujian, ketahanan, keamanan, dan performa, yang meningkatkan produktivitas pengembang. |
| Kelincahan pengembang | Otomatisasi Integrasi Berkelanjutan dan Penyebaran Berkelanjutan (CI/CD) memungkinkan penggunaan lingkungan pengembangan berumur pendek dengan siklus hidup yang terkait dengan cabang fitur terkait, yang mempromosikan kelincahan pengembang dan mendorong validasi sedini mungkin dalam siklus rekayasa untuk meminimalkan biaya rekayasa bug. |
| Mengukur kesehatan operasional | Instrumentasi diagnostik penuh dari semua komponen dan sumber daya memungkinkan pengamatan log, metrik, dan jejak yang berkelanjutan, tetapi juga memfasilitasi pemodelan kesehatan untuk mengukur kesehatan aplikasi dalam konteks ketersediaan dan persyaratan performa. |
| Melatih pemulihan dan kegagalan latihan | Perencanaan dan latihan Business Continuity (SM) dan Pemulihan Bencana (DR) sangat penting dan harus sering dilakukan, karena pembelajaran dapat secara berulang meningkatkan rencana dan prosedur untuk memaksimalkan ketahanan jika terjadi waktu henti yang tidak dijadwalkan. |
| Merangkul peningkatan operasional berkelanjutan | Prioritaskan peningkatan rutin sistem dan pengalaman pengguna, menggunakan model kesehatan untuk memahami dan mengukur efisiensi operasional dengan mekanisme umpan balik untuk memungkinkan tim aplikasi memahami dan mengatasi kesenjangan secara berulang. |
Keamanan
Selalu aman - Desain untuk keamanan end-to-end untuk menjaga stabilitas aplikasi dan memastikan ketersediaan.
| Prinsip desain | Pertimbangan |
|---|---|
| Memantau keamanan seluruh solusi dan merencanakan respons insiden | Menghubungkan peristiwa keamanan dan audit untuk memodelkan kesehatan aplikasi dan mengidentifikasi ancaman aktif. Tetapkan prosedur otomatis dan manual untuk merespons insiden menggunakan alat Security Information and Event Management (SIEM) untuk pelacakan. |
| Model dan menguji terhadap potensi ancaman | Pastikan pengerasan sumber daya yang sesuai dan menetapkan prosedur untuk mengidentifikasi dan mengurangi ancaman yang diketahui, menggunakan pengujian penetrasi untuk memverifikasi mitigasi ancaman, serta analisis kode statis dan pemindaian kode. |
| Mengidentifikasi dan melindungi titik akhir | Pantau dan lindungi integritas jaringan titik akhir internal dan eksternal melalui kemampuan dan appliance keamanan, seperti firewall atau firewall aplikasi web. Gunakan pendekatan standar industri untuk melindungi dari vektor serangan umum seperti serangan Distributed Denial-Of-Service (DDoS), seperti SlowLoris. |
| Melindungi dari kerentanan tingkat kode | Identifikasi dan mitigasi kerentanan tingkat kode, seperti pembuatan skrip lintas situs atau injeksi SQL, dan gabungkan patch keamanan ke dalam siklus hidup operasional untuk semua bagian basis kode, termasuk dependensi. |
| Mengotomatiskan dan menggunakan hak istimewa paling sedikit | Dorong otomatisasi untuk meminimalkan kebutuhan interaksi manusia dan menerapkan hak istimewa paling sedikit di seluruh aplikasi dan sarana kontrol untuk melindungi dari eksfiltrasi data dan skenario aktor jahat. |
| Mengklasifikasikan dan mengenkripsi data | Mengklasifikasikan data sesuai dengan risiko dan menerapkan enkripsi standar industri saat tidak aktif dan saat transit, memastikan kunci dan sertifikat disimpan dengan aman dan dikelola dengan benar. |
Pengoptimalan Biaya
Ada tradeoff biaya yang jelas terkait dengan memperkenalkan keandalan yang lebih besar, yang harus dipertimbangkan dengan hati-hati dalam konteks persyaratan beban kerja.
Memaksimalkan keandalan dapat memengaruhi biaya keuangan solusi secara keseluruhan. Misalnya, duplikasi sumber daya dan distribusi sumber daya di seluruh wilayah untuk mencapai ketersediaan tinggi memiliki implikasi biaya yang jelas. Untuk menghindari kelebihan biaya, jangan rekayasa berlebihan atau provisi berlebihan di luar persyaratan bisnis yang relevan.
Juga, ada biaya tambahan yang terkait dengan investasi rekayasa dalam konsep keandalan mendasar, seperti merangkul infrastruktur sebagai kode, otomatisasi penyebaran, dan rekayasa kekacauan. Ini dikenakan biaya dalam hal waktu dan upaya, yang dapat diinvestasikan di tempat lain untuk memberikan fungsionalitas dan fitur aplikasi baru.
Desain asli cloud
Layanan terkelola asli Azure - Layanan terkelola asli Azure diprioritaskan karena overhead administratif dan operasionalnya yang lebih rendah serta integrasi yang ketat dengan konfigurasi dan instrumentasi yang konsisten di seluruh tumpukan aplikasi.
Penyelarasan peta jalan - Menggabungkan kemampuan layanan Azure baru dan yang akan ditingkatkan saat tersedia secara Umum (GA) agar tetap dekat dengan tepi utama Azure.
Rangkul kemampuan pratinjau dan mitigasi kesenjangan yang diketahui - Meskipun layanan Generally Available (GA) diprioritaskan untuk dukungan, pratinjau layanan Azure secara aktif dieksplorasi untuk penggabungan yang cepat, memberikan umpan balik teknis dan dapat ditindaklanjuti ke grup produk Azure untuk mengatasi kesenjangan.
Penyelarasan zona pendaratan Azure - Dapat disebarkan dalam zona pendaratan Azure dan selaras dengan metodologi desain zona pendaratan Azure, tetapi juga berfungsi penuh dan dapat disebarkan di lingkungan kosong di luar zona pendaratan.
Langkah selanjutnya
Tinjau masalah lintas pemotongan yang terkait dengan beban kerja misi penting.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk