Beban kerja tingkat operator di Azure
Sistem misi penting terutama berfokus pada memaksimalkan waktu aktif dan mereka ada di banyak industri. Dalam industri telekomunikasi, mereka disebut sebagai sistem kelas operator. Sistem ini dikembangkan karena satu atau beberapa driver berikut:
- Meminimalkan hilangnya nyawa atau cedera.
- Memenuhi persyaratan peraturan tentang keandalan untuk menghindari pembayaran denda.
- Mengoptimalkan layanan kepada pelanggan untuk meminimalkan churn kepada pesaing.
- Memenuhi Perjanjian Tingkat Layanan (SLA) kontraktual dengan pelanggan bisnis atau pemerintah.
Rangkaian artikel ini menerapkan metodologi desain untuk beban kerja misi penting untuk menginformasikan panduan preskriptif untuk membangun dan mengoperasikan beban kerja telekomunikasi yang sangat andal, tangguh, dan tersedia di Azure.
Catatan
Artikel dalam seri ini berfokus pada memberikan pertimbangan misi-kritis tambahan saat merancang tingkat keandalan 99,999% ('5 9s') dalam industri telekomunikasi.
Apa itu beban kerja tingkat operator?
Istilah beban kerja mengacu pada kumpulan sumber daya aplikasi yang mendukung tujuan bisnis umum atau eksekusi proses bisnis umum, dengan beberapa layanan, seperti API dan penyimpanan data, bekerja sama untuk memberikan fungsionalitas end-to-end tertentu.
Istilah misi-kritis mengacu pada klasifikasi kekritisan di mana biaya keuangan yang signifikan (penting bagi bisnis) atau biaya manusia (safety-critical) dikaitkan dengan tidak tersedia atau kurang performa.
Beban kerja kelas operator berpivot pada bisnis penting dan penting bagi keselamatan, di mana ada persyaratan mendasar untuk beroperasi hanya dengan menit atau bahkan detik waktu henti per tahun kalender. Kegagalan untuk mencapai persyaratan waktu aktif ini dapat mengakibatkan hilangnya kehidupan yang luas, dikenakan denda yang signifikan, atau hukuman kontraktual.
Aspek operasional beban kerja mencakup bagaimana keandalan diukur dan target yang harus dipenuhi atau dilampaui. Sistem yang sangat andal biasanya menargetkan waktu aktif 99,999% (biasanya disebut sebagai '5 9s') atau waktu henti 0,001% dalam setahun (sekitar 5 menit). Beberapa sistem menargetkan waktu aktif 99,9999%, atau waktu henti 30 detik per tahun, atau bahkan tingkat keandalan yang lebih tinggi. Ini mencakup semua bentuk dan penyebab pemadaman - pemeliharaan terjadwal, kegagalan infrastruktur, kesalahan manusia, masalah perangkat lunak, dan bahkan bencana alam.
Meskipun platform yang digunakan telah berevolusi dari perangkat keras khusus dan eksklusif melalui perangkat keras komersial, di luar rak ke cloud OpenStack atau VMware, perusahaan Telekomunikasi secara konsisten memberikan layanan yang mencapai ≤ 5 menit waktu henti per tahun, dan dalam banyak kasus, mencapai ≤ 30 detik waktu henti karena pemadaman yang tidak terjadwal.
Apa saja tantangan umumnya?
Membangun beban kerja tingkat operator adalah tantangan karena alasan utama ini:
Pendekatan angkat dan geser
Perusahaan telekomunikasi memiliki aplikasi yang dirancang dengan baik yang memberikan perilaku yang diharapkan pada infrastruktur yang ada. Namun, perawatan harus dilakukan sebelum berasumsi bahwa porting aplikasi ini apa adanya ke infrastruktur cloud publik tidak akan memengaruhi ketahanannya.
Aplikasi yang ada membuat serangkaian asumsi tentang infrastruktur dasarnya, yang tidak mungkin tetap benar saat berpindah dari lokal ke cloud publik. Arsitek harus memeriksa bahwa mereka masih memegang dan menyesuaikan infrastruktur dan desain aplikasi untuk mengakomodasi realitas baru. Arsitek juga harus mencari peluang di mana infrastruktur baru menghapus batasan yang ada di tempat.
Misalnya, peningkatan sistem lokal harus terjadi karena tidak layak untuk mempertahankan perangkat keras yang cukup untuk membuat penyebaran baru bersama dan perlahan-lahan transisi dengan cara yang aman. Jalur peningkatan ini menghasilkan sejumlah persyaratan tentang bagaimana peningkatan dan pembatalan dikelola. Persyaratan ini menyebabkan kompleksitas dan berarti bahwa peningkatan jarang dan hanya diizinkan di jendela pemeliharaan yang dikelola dengan hati-hati.
Namun, di cloud publik, wajar untuk membuat penyebaran baru secara paralel dengan penyebaran yang ada. Proses ini menciptakan peluang untuk penyederhanaan utama dalam desain dan peningkatan operasional aplikasi dalam pengalaman pengguna, dan harapan.
Solusi monolitik
Pengalaman di berbagai industri misi-kritis menunjukkan bahwa tidak realistis untuk mencoba membangun solusi monolitik yang akan mencapai tingkat ketersediaan yang diinginkan. Hanya ada terlalu banyak sumber kegagalan potensial dalam sistem yang kompleks. Sebaliknya, solusi yang berhasil terdiri dari elemen independen dan redundan individu. Setiap unit memiliki ketersediaan yang relatif mendasar (biasanya ~ 99,9%), tetapi ketika digabungkan bersama-sama, total solusi mencapai tujuan ketersediaan yang diperlukan. Seni rekayasa kelas operator kemudian menjadi memastikan bahwa satu-satunya dependensi yang umum untuk elemen redundan adalah yang benar-benar diperlukan karena mereka memberikan pengaruh paling signifikan pada ketersediaan keseluruhan, seringkali urutan besarnya lebih besar dari apa pun dalam desain.
Hanya membangun redundansi zona
Menggunakan Zona Ketersediaan Microsoft Azure adalah pilihan dasar untuk mengurangi risiko pemadaman karena kegagalan perangkat keras atau masalah lingkungan yang dilokalkan. Namun, tidak cukup untuk mencapai ketersediaan tingkat operator, terutama karena alasan ini:
Zona Ketersediaan (AZ) dirancang sehingga latensi jaringan antara dua zona dalam satu wilayah ≤ 2 md. AZ tidak dapat tersebar secara luas dan geografis. Jadi, AZ berbagi risiko kegagalan yang berkorelasi karena bencana alam, seperti banjir atau pemadaman listrik besar-besaran, yang dapat menonaktifkan beberapa AZ dalam suatu wilayah.
Banyak layanan Azure dirancang secara eksplisit agar zona-redundan sehingga aplikasi yang menggunakannya tidak memerlukan logika eksplisit untuk mendapatkan manfaat dari perolehan ketersediaan. Fungsi redundansi dalam layanan ini memerlukan kolaborasi antara elemen di setiap zona. Sering kali ada risiko kegagalan perangkat lunak yang tidak dapat ditolak di satu zona yang menyebabkan kegagalan berkorelasi di zona lain. Misalnya, masalah apa pun dengan rahasia atau sertifikat yang digunakan dengan layanan zona redundan dapat memengaruhi semua AZ secara bersamaan.
Apa saja area desain utamanya?
Saat mendesain beban kerja tingkat operator, pertimbangkan area berikut:
| Area desain | Deskripsi |
|---|---|
| Toleransi kegagalan | Desain aplikasi harus memungkinkan kegagalan yang tidak dapat ditolak sehingga aplikasi secara keseluruhan dapat terus beroperasi pada tingkat tertentu. Desain harus meminimalkan titik kegagalan dan mengambil pendekatan federasi. |
| Model data | Desain harus mengatasi kebutuhan konsistensi, ketersediaan, dan toleransi partisi database. Ketersediaan Carrier Grade mengharuskan aplikasi disebarkan di beberapa wilayah. Penyebaran ini membutuhkan pemikiran yang cermat tentang bagaimana data aplikasi akan dikelola di seluruh wilayah tersebut. |
| Pemodelan kesehatan | Model kesehatan yang efektif memberikan pengamatan semua komponen, platform, dan aplikasi, sehingga masalah dapat dengan cepat terdeteksi dan respons siap baik melalui penyembuhan diri atau remediasi lainnya. |
| Pengujian dan validasi | Desain dan implementasi aplikasi harus diuji secara menyeluruh. Selain itu, integrasi dan penyebaran aplikasi sebagai solusi keseluruhan harus diuji. |
Langkah selanjutnya
Mulailah dengan meninjau prinsip desain untuk skenario aplikasi tingkat operator.
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