Prosedur operasional untuk beban kerja misi penting di Azure
Operasi yang andal dan efektif harus didasarkan pada prinsip otomatisasi sedapat mungkin dan konfigurasi sebagai kode. Pendekatan ini membutuhkan investasi rekayasa yang substansial dalam proses DevOps. Alur otomatis digunakan untuk menyebarkan artefak kode aplikasi dan infrastruktur. Manfaat dari pendekatan ini termasuk hasil operasional yang konsisten dan akurat dengan prosedur operasional manual minimal.
Area desain ini mengeksplorasi cara menerapkan prosedur operasional yang efektif dan konsisten.
Penting
Artikel ini adalah bagian dari seri beban kerja misi penting Azure Well-Architected Framework . Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan Apa itu beban kerja misi penting?.
Proses DevOps
DevOps menggabungkan proses pengembangan dan operasional serta tim ke dalam satu fungsi rekayasa. Ini mencakup seluruh siklus hidup aplikasi dan menggunakan otomatisasi dan alat DevOps untuk melakukan operasi penyebaran dengan cara yang cepat, efisien, dan dapat diandalkan. DevOps memproses dukungan dan mempertahankan integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) sambil menumbuhkan budaya peningkatan berkelanjutan.
Tim DevOps untuk aplikasi yang sangat penting harus bertanggung jawab atas tugas-tugas ini:
- Pembuatan dan pengelolaan sumber daya aplikasi dan infrastruktur melalui otomatisasi CI/CD.
- Pemantauan dan pengamatan aplikasi.
- Kontrol akses berbasis peran Azure (RBAC) dan manajemen identitas untuk komponen aplikasi.
- Manajemen jaringan untuk komponen aplikasi.
- Manajemen biaya untuk sumber daya aplikasi.
DevSecOps memperluas model DevOps dengan mengintegrasikan pemantauan keamanan, audit aplikasi, dan jaminan kualitas dengan pengembangan dan operasi sepanjang siklus hidup aplikasi. Tim DevOps diperlukan untuk skenario yang sensitif terhadap keamanan dan sangat teregulasi untuk memastikan bahwa keamanan dimasukkan di seluruh siklus hidup pengembangan daripada pada tahap rilis atau gerbang tertentu.
Mempertimbangkan rancangan
Proses rilis dan pembaruan. Hindari proses manual untuk setiap perubahan pada komponen aplikasi atau infrastruktur yang mendasarinya. Proses manual dapat menyebabkan hasil yang tidak konsisten.
Dependensi pada tim IT pusat. Proses DevOps mungkin sulit diterapkan ketika ada dependensi keras pada fungsi terpusat karena dependensi ini mencegah operasi end-to-end.
Pengelolaan identitas dan akses. Tim DevOps dapat mempertimbangkan peran Azure RBAC terperinci untuk berbagai fungsi teknis, seperti AppDataOps untuk manajemen database. Terapkan model zero-trust di seluruh peran DevOps.
Rekomendasi desain
Tentukan pengaturan konfigurasi dan pembaruan sebagai kode. Terapkan manajemen perubahan melalui kode untuk mengaktifkan proses rilis dan pembaruan yang konsisten, termasuk tugas seperti rotasi kunci atau rahasia dan manajemen izin. Gunakan proses pembaruan yang dikelola alur, seperti eksekusi alur terjadwal, bukan mekanisme pembaruan otomatis bawaan.
Jangan gunakan proses pusat atau provisi alur untuk instansiasi atau manajemen sumber daya aplikasi. Melakukannya memperkenalkan dependensi aplikasi eksternal dan vektor risiko tambahan, seperti yang terkait dengan skenario tetangga yang bising.
Jika Anda perlu menggunakan proses provisi terpusat, pastikan bahwa persyaratan ketersediaan dependensi sepenuhnya selaras dengan persyaratan misi penting. Tim pusat harus memberikan transparansi sehingga operasionalisasi holistik aplikasi end-to-end tercapai.
Dedikasikan proporsi kapasitas rekayasa selama setiap sprint untuk mendorong peningkatan platform dasar dan meningkatkan keandalan. Kami menyarankan agar Anda mengalokasikan 20-40 persen kapasitas untuk peningkatan ini.
Kembangkan kriteria rekayasa umum, arsitektur referensi, dan pustaka yang selaras dengan prinsip desain inti. Terapkan konfigurasi garis besar yang konsisten untuk keandalan, keamanan, dan operasi melalui pendekatan berbasis kebijakan yang menggunakan Azure Policy.
Anda juga dapat menggunakan kriteria rekayasa umum dan artefak terkait, seperti kebijakan Azure dan sumber daya Terraform untuk pola desain umum, di seluruh beban kerja lain dalam ekosistem aplikasi organisasi Anda yang lebih luas.
Terapkan model zero-trust di lingkungan aplikasi penting. Gunakan teknologi seperti Microsoft Entra Privileged Identity Management untuk memastikan bahwa operasi konsisten dan hanya terjadi melalui proses CI/CD atau prosedur operasional otomatis.
Anggota tim seharusnya tidak memiliki akses tulis yang berdiri ke lingkungan apa pun. Anda mungkin ingin membuat pengecualian di lingkungan pengembangan untuk memungkinkan pengujian dan penelusuran kesalahan yang lebih mudah.
Tentukan proses darurat untuk akses just-in-time ke lingkungan produksi. Pastikan bahwa akun break glass ada jika terjadi masalah serius dengan penyedia autentikasi.
Pertimbangkan untuk menggunakan AIOps untuk terus meningkatkan prosedur dan pemicu operasional.
Operasi aplikasi
Desain aplikasi dan rekomendasi platform memengaruhi prosedur operasional. Ada juga kemampuan operasional yang disediakan oleh berbagai layanan Azure, terutama untuk ketersediaan dan pemulihan yang tinggi.
Mempertimbangkan rancangan
Operasi bawaan layanan Azure. Layanan Azure menyediakan kemampuan platform bawaan (diaktifkan secara default) dan dapat dikonfigurasi, seperti redundansi zona dan replikasi geografis. Keandalan aplikasi tergantung pada operasi ini. Kemampuan tertentu yang dapat dikonfigurasi dikenakan biaya tambahan, seperti konfigurasi penyebaran multi-tulis untuk Azure Cosmos DB. Hindari membangun solusi kustom kecuali Anda benar-benar perlu.
Akses operasional dan waktu eksekusi. Sebagian besar operasi yang diperlukan diekspos dan dapat diakses melalui Azure Resource Manager API atau portal Azure. Namun, operasi tertentu memerlukan bantuan dari teknisi dukungan. Misalnya, pemulihan dari cadangan berkala database Azure Cosmos DB, atau pemulihan sumber daya yang dihapus, hanya dapat dilakukan oleh teknisi dukungan Azure melalui kasus dukungan. Dependensi ini dapat memengaruhi waktu henti aplikasi. Untuk sumber daya stateless, kami sarankan Anda menyebarkan ulang alih-alih menunggu teknisi dukungan mencoba memulihkan sumber daya yang dihapus.
Penegakan kebijakan. Azure Policy menyediakan kerangka kerja untuk menegakkan dan mengaudit garis besar keamanan dan keandalan untuk memastikan kepatuhan terhadap kriteria rekayasa umum untuk aplikasi penting misi. Lebih khusus lagi, Azure Policy membentuk bagian kunci dari sarana kontrol Azure Resource Manager, melengkapi RBAC dengan membatasi tindakan yang dapat dilakukan pengguna yang berwenang. Anda dapat menggunakan Azure Policy untuk menegakkan konvensi keamanan dan keandalan penting di seluruh layanan platform.
Modifikasi dan penghapusan sumber daya. Anda dapat mengunci sumber daya Azure untuk mencegahnya dimodifikasi atau dihapus. Namun, kunci memperkenalkan overhead manajemen dalam alur penyebaran. Untuk sebagian besar sumber daya, kami merekomendasikan proses RBAC yang kuat dengan pembatasan ketat daripada kunci sumber daya.
Rekomendasi desain
Mengotomatiskan prosedur failover. Untuk model aktif/aktif, gunakan model kesehatan dan operasi skala otomatis untuk memastikan bahwa tidak diperlukan intervensi failover. Untuk model aktif/pasif, pastikan bahwa prosedur failover diotomatisasi atau setidaknya dikodifikasi dalam alur.
Prioritaskan penggunaan penskalaan otomatis asli Azure untuk layanan yang mendukungnya. Untuk layanan yang tidak mendukung penskalaan otomatis asli, gunakan proses operasional otomatis untuk menskalakan layanan. Gunakan unit skala dengan beberapa layanan untuk mencapai skalabilitas.
Gunakan kemampuan platform-native untuk pencadangan dan pemulihan, memastikan bahwa kemampuan tersebut selaras dengan RTO/RPO dan persyaratan retensi data Anda. Tentukan strategi untuk retensi cadangan jangka panjang sesuai kebutuhan.
Gunakan kemampuan bawaan untuk manajemen dan perpanjangan sertifikat SSL, seperti yang disediakan oleh Azure Front Door.
Untuk tim eksternal, buat proses pemulihan untuk sumber daya yang memerlukan bantuan. Misalnya, jika platform data salah dimodifikasi atau dihapus, metode pemulihan harus dipahami dengan baik, dan proses pemulihan harus diberlakukan. Demikian pula, tetapkan prosedur untuk mengelola gambar kontainer yang dinonaktifkan di registri.
Praktikkan operasi pemulihan terlebih dahulu, pada sumber daya dan data non-produksi, sebagai bagian dari persiapan kelangsungan bisnis standar.
Identifikasi pemberitahuan penting dan tentukan audiens dan sistem target. Tentukan saluran yang jelas untuk menjangkau pemangku kepentingan yang sesuai. Kirim hanya pemberitahuan yang dapat ditindaklanjuti untuk menghindari kebisingan putih dan mencegah pemangku kepentingan operasional mengabaikan pemberitahuan dan kehilangan informasi penting. Terapkan peningkatan berkelanjutan untuk mengoptimalkan pemberitahuan dan menghapus kebisingan putih yang diamati.
Terapkan tata kelola dan Azure Policy berbasis kebijakan untuk memastikan penggunaan kemampuan operasional yang sesuai dan garis besar konfigurasi yang andal di semua layanan aplikasi.
Hindari penggunaan kunci sumber daya pada sumber daya regional ephemeral. Sebaliknya, andalkan penggunaan alur RBAC dan CI/CD yang sesuai untuk mengontrol pembaruan operasional. Anda dapat menerapkan kunci sumber daya untuk mencegah penghapusan sumber daya global berumur panjang.
Manajemen pembaruan
Desain misi-kritis sangat mendukung prinsip sumber daya aplikasi stateless sementara. Jika Anda menerapkan prinsip ini, Anda biasanya dapat melakukan pembaruan dengan menggunakan penyebaran baru dan alur pengiriman standar.
Mempertimbangkan rancangan
Penyelarasan dengan peta jalan Azure. Selaraskan beban kerja Anda dengan peta jalan Azure sehingga sumber daya platform dan dependensi runtime diperbarui secara teratur.
Deteksi pembaruan otomatis. Siapkan proses untuk memantau dan mendeteksi pembaruan secara otomatis. Gunakan alat seperti GitHub Dependabot.
Pengujian dan validasi. Uji dan validasi versi baru paket, komponen, dan dependensi dalam konteks produksi sebelum rilis apa pun. Versi baru mungkin berisi perubahan yang melanggar.
Dependensi runtime. Perlakukan dependensi runtime seperti Anda melakukan perubahan lain pada aplikasi. Versi lama mungkin memperkenalkan kerentanan keamanan dan mungkin memiliki efek negatif pada performa. Pantau lingkungan runtime aplikasi dan selalu perbarui.
Kebersihan komponen dan rumah tangga. Menonaktifkan atau menghapus sumber daya yang tidak digunakan. Misalnya, pantau registri kontainer dan hapus versi gambar lama yang tidak Anda gunakan.
Rekomendasi desain
Pantau sumber daya ini dan selalu perbarui:
- Platform hosting aplikasi. Misalnya, Anda perlu memperbarui versi Kubernetes di Azure Kubernetes Service (AKS) secara teratur, terutama mengingat bahwa dukungan untuk versi yang lebih lama tidak berkelanjutan. Anda juga perlu memperbarui komponen yang berjalan di Kubernetes, seperti cert-manager dan Azure Key Vault CSI, dan menyelaraskannya dengan versi Kubernetes di AKS.
- Pustaka eksternal dan SDK (.NET, Java, Python).
- Penyedia terraform.
Hindari perubahan operasional manual untuk memperbarui komponen. Pertimbangkan penggunaan perubahan manual hanya dalam situasi darurat. Pastikan Anda memiliki proses untuk merekonsiliasi perubahan manual apa pun kembali ke repositori sumber untuk menghindari penyimpangan dan mengeluarkan pengulangan.
Buat prosedur otomatis untuk menghapus versi lama gambar dari Azure Container Registry.
Manajemen rahasia
Kedaluwarsa kunci, rahasia, dan sertifikat adalah penyebab umum pemadaman aplikasi. Manajemen rahasia untuk aplikasi misi penting harus memberikan keamanan yang diperlukan dan menawarkan tingkat ketersediaan yang sesuai untuk menyelaraskan dengan persyaratan keandalan maksimum Anda. Anda perlu melakukan rotasi kunci, rahasia, dan sertifikat secara teratur dengan menggunakan layanan terkelola atau sebagai bagian dari manajemen pembaruan, dan menerapkan proses untuk perubahan kode dan konfigurasi.
Banyak layanan Azure mendukung autentikasi Microsoft Entra alih-alih mengandalkan string/kunci koneksi. Menggunakan ID Microsoft Entra sangat mengurangi overhead operasional. Jika Anda menggunakan solusi manajemen rahasia, solusi tersebut harus berintegrasi dengan layanan lain, mendukung redundansi zona dan regional, dan menyediakan integrasi dengan ID Microsoft Entra untuk autentikasi dan otorisasi. Key Vault menyediakan fitur-fitur ini.
Mempertimbangkan rancangan
Ada tiga pendekatan umum untuk manajemen rahasia. Setiap pendekatan membaca rahasia dari penyimpanan rahasia dan menyuntikkannya ke dalam aplikasi pada waktu yang berbeda.
Pengambilan waktu penyebaran. Keuntungan dari pendekatan ini adalah bahwa solusi manajemen rahasia hanya perlu tersedia pada waktu penyebaran karena tidak ada dependensi langsung setelah waktu tersebut. Contohnya termasuk memasukkan rahasia sebagai variabel lingkungan ke dalam penyebaran Kubernetes atau ke dalam rahasia Kubernetes.
Hanya perwakilan layanan penyebaran yang perlu dapat mengakses rahasia, yang menyederhanakan izin RBAC dalam sistem manajemen rahasia.
Namun, ada kerugian dari pendekatan ini. Ini memperkenalkan kompleksitas RBAC dalam peralatan DevOps sehubungan dengan mengontrol akses perwakilan layanan dan dalam aplikasi sehubungan dengan melindungi rahasia yang diambil. Selain itu, manfaat keamanan solusi manajemen rahasia tidak diterapkan karena pendekatan ini hanya bergantung pada kontrol akses di platform aplikasi.
Untuk menerapkan pembaruan atau rotasi rahasia, Anda perlu melakukan penyebaran ulang penuh.
Pengambilan pengaktifan aplikasi. Dalam pendekatan ini, rahasia diambil dan disuntikkan pada pengaktifan aplikasi. Manfaatnya adalah Anda dapat dengan mudah memperbarui atau memutar rahasia. Anda tidak perlu menyimpan rahasia di platform aplikasi. Menghidupkan ulang aplikasi diperlukan untuk mengambil nilai terbaru.
Pilihan penyimpanan umum termasuk Azure Key Vault Provider for Secrets Store CSI Driver dan akv2k8s. Solusi Azure asli, Key Vault pengaturan aplikasi yang dirujuk, juga tersedia.
Kerugian dari pendekatan ini adalah menciptakan dependensi runtime pada solusi manajemen rahasia. Jika solusi manajemen rahasia mengalami pemadaman, komponen aplikasi yang sudah berjalan mungkin dapat terus melayani permintaan. Setiap operasi hidupkan ulang atau peluasan skala kemungkinan akan mengakibatkan kegagalan.
Pengambilan runtime. Mengambil rahasia saat runtime dari dalam aplikasi itu sendiri adalah pendekatan yang paling aman karena bahkan platform aplikasi tidak pernah memiliki akses ke rahasia. Aplikasi perlu mengautentikasi dirinya sendiri ke sistem manajemen rahasia.
Namun, untuk pendekatan ini, komponen aplikasi memerlukan dependensi langsung dan koneksi ke sistem manajemen rahasia. Ini membuatnya lebih sulit untuk menguji komponen secara individual dan biasanya mengharuskan penggunaan SDK.
Rekomendasi desain
Jika memungkinkan, gunakan autentikasi Microsoft Entra untuk menyambungkan ke layanan alih-alih menggunakan string koneksi atau kunci. Gunakan metode autentikasi ini bersama dengan identitas terkelola Azure sehingga Anda tidak perlu menyimpan rahasia di platform aplikasi.
Manfaatkan pengaturan kedaluwarsa di Key Vault, dan konfigurasikan pemberitahuan untuk kedaluwarsa mendatang. Lakukan semua pembaruan kunci, rahasia, dan sertifikat dengan menggunakan proses rilis standar.
Sebarkan instans Key Vault sebagai bagian dari stempel regional untuk mengurangi efek potensial kegagalan ke stempel penyebaran tunggal. Gunakan instans terpisah untuk sumber daya global. Untuk informasi tentang sumber daya tersebut, lihat pola arsitektur khas untuk beban kerja misi penting.
Untuk menghindari kebutuhan untuk mengelola kredensial perwakilan layanan atau kunci API, gunakan identitas terkelola alih-alih perwakilan layanan untuk mengakses Key Vault jika memungkinkan.
Terapkan pola pengkodian untuk memastikan bahwa rahasia diambil kembali ketika kegagalan otorisasi terjadi pada runtime.
Terapkan proses rotasi kunci yang sepenuhnya otomatis yang berjalan secara berkala dalam solusi.
Gunakan pemberitahuan kunci hampir kedaluwarsa di Azure Key Vault untuk mendapatkan pemberitahuan tentang kedaluwarsa yang akan datang.
Pertimbangan khusus IaaS saat menggunakan VM
Jika Anda perlu menggunakan IaaS VM, beberapa prosedur dan praktik yang dijelaskan sebelumnya dalam dokumen ini mungkin berbeda. Penggunaan VM memberikan lebih banyak fleksibilitas dalam opsi konfigurasi, sistem operasi, akses driver, akses sistem operasi tingkat rendah, dan jenis perangkat lunak yang dapat Anda instal. Kerugiannya adalah peningkatan biaya operasional dan tanggung jawab untuk tugas yang biasanya dilakukan oleh penyedia cloud saat Anda menggunakan layanan PaaS.
Mempertimbangkan rancangan
- VM individual tidak menyediakan ketersediaan tinggi, redundansi zona, atau geo-redundansi.
- VM individual tidak diperbarui secara otomatis setelah Anda menyebarkannya. Misalnya, SQL Server 2019 yang disebarkan pada Windows Server 2019, tidak akan secara otomatis diperbarui ke rilis yang lebih baru.
- Layanan yang berjalan di VM memerlukan perlakuan khusus dan alat tambahan jika Anda ingin menyebarkan dan mengonfigurasinya melalui infrastruktur sebagai kode.
- Azure secara berkala memperbarui platformnya. Pembaruan ini mungkin memerlukan boot ulang VM. Updates yang memerlukan boot ulang biasanya diumumkan terlebih dahulu. Lihat Pemeliharaan untuk komputer virtual di Azure dan Menangani pemberitahuan pemeliharaan terencana.
Rekomendasi desain
Hindari operasi manual pada VM dan terapkan proses yang tepat untuk menyebarkan dan meluncurkan perubahan.
- Otomatiskan penyediaan sumber daya Azure dengan menggunakan solusi infrastruktur sebagai kode seperti templat Azure Resource Manager (ARM), Bicep, Terraform, atau solusi lainnya.
Pastikan bahwa proses operasional untuk penyebaran VM, pembaruan, dan pencadangan dan pemulihan telah diberlakukan dan diuji dengan benar. Untuk menguji ketahanan, masukkan kesalahan ke dalam aplikasi, catat kegagalan, dan mitigasi kegagalan tersebut.
Pastikan bahwa strategi tersedia untuk kembali ke status sehat terakhir yang diketahui jika versi yang lebih baru tidak berfungsi dengan benar.
Buat cadangan yang sering untuk beban kerja stateful, pastikan bahwa tugas pencadangan bekerja secara efektif, dan terapkan pemberitahuan untuk proses pencadangan yang gagal.
Pantau VM dan deteksi kegagalan. Data mentah untuk pemantauan dapat berasal dari berbagai sumber. Analisis penyebab masalah.
Pastikan pencadangan terjadwal berjalan seperti yang diharapkan dan cadangan berkala dibuat sesuai kebutuhan. Anda dapat menggunakan Pusat pencadangan untuk mendapatkan wawasan.
Prioritaskan penggunaan Virtual Machine Scale Sets daripada VM untuk mengaktifkan kemampuan seperti skala, skala otomatis, dan redundansi zona.
Prioritaskan penggunaan gambar standar dari Marketplace Azure daripada gambar kustom yang perlu dipertahankan.
Gunakan Azure VM Image Builder atau alat lain untuk mengotomatiskan proses build dan pemeliharaan untuk gambar yang disesuaikan sesuai kebutuhan.
Di luar rekomendasi khusus ini, terapkan praktik terbaik untuk prosedur operasional untuk skenario aplikasi yang sangat penting sebagaimana mestinya.
Langkah selanjutnya
Tinjau pola arsitektur untuk skenario aplikasi misi-kritis: