Bagikan melalui


Pemantauan dan respons cloud

Artikel ini adalah bagian dari seri dalam panduan pemantauan cloud.

Respons adalah hasil dari penetapan satu atau beberapa tindakan berdasarkan keputusan menurut data dari pemantauan yang memungkinkan konsumen layanan:

  • Membuatnya dapat ditindaklanjuti: Gunakan konfigurasi pemantauan yang disetel dengan baik untuk membuat sinyal yang dapat ditindaklanjuti.
  • Terus memantau: Terapkan pemantauan di seluruh aktivitas insiden dan pemecahan masalah untuk lebih membantu mendiagnosis masalah.
  • Mengotomatiskan: Mengonfigurasi investigasi otomatis, diagnosis, resolusi, pemulihan, dan remediasi berdasarkan sinyal yang diidentifikasi.

Prinsip signifikansi berlaku di sini. Ini membantu alur proses atau kebijakan untuk tindakan menyetel dan mengoptimalkan pemberitahuan, pemberitahuan, dan hash laporan. Pemantauan cloud jauh lebih daripada memberi tahu manusia bahwa ada sesuatu yang salah. Ini juga tentang memberikan sinyal kepada sistem dan layanan untuk bereaksi.

Pemantauan memainkan peran penting dalam berbagai skenario:

  • Mengaktifkan perilaku layanan dinamis: Mengontrol sistem dan layanan secara dinamis untuk bereaksi berdasarkan data pemantauan dan menghilangkan insiden secara otomatis.
  • Terus mengevaluasi sinyal: Terus menginformasikan dan menyediakan telemetri untuk proses dinamis, kepatuhan, penskalaan otomatis, dan visualisasi.
  • Tindakan organisasi: Bantu organisasi TI bertindak dan mengelola perubahan.

Memperingatkan

Automation menggantikan proses manajemen layanan yang lebih mahal di lanskap cloud modern, menghilangkan lebih banyak insiden. Pemberitahuan memainkan peran penting dalam kesadaran tetapi harus dapat ditindak untuk menghindari kelelahan atau kebisingan pemberitahuan.

Menentukan pemberitahuan membantu secara proaktif memastikan bahwa layanan dan sistem tetap sehat, responsif, andal, dan aman. Menjamin performa, menjunjung tinggi Tujuan Tingkat Layanan (SLO), ketersediaan, dan privasi membutuhkan strategi pemberitahuan yang tepat. Meningkatkan pemberitahuan tidak penting untuk diamati, dan hari ini seharusnya tidak dianggap sebagai garis pertahanan pertama. Sebaliknya, otomatisasi harus memainkan peran penting di sini.

Secara tradisional, pemantauan berarti meningkatkan pemberitahuan bahwa seseorang dapat bertindak, menyiratkan proses yang sepenuhnya reaktif. Pendekatan ini harus direvisi setelah manajemen layanan modern atau praktik operasi cloud. Pendekatan ini dengan cermat mengikuti jalur Manajemen Insiden ITIL tradisional, yang tidak cocok dengan tujuan efisiensi cloud melalui kelincahan, biaya minimum, dan pengoptimalan.

Pendekatan modern dapat memiliki frekuensi kondisi yang terdeteksi yang jauh lebih informatif dan otomatis, misalnya:

Kondisi terdeteksi Tindakan primitif Aksi modern
  • Metrik performa - pemanfaatan memori yang tinggi.
  • Ancaman keamanan - mendeteksi aktivitas jaringan yang mencurigakan.
  • Kesalahan ketersediaan - Permintaan penyimpanan blob Azure gagal.
  • Memberi peringatan dan pemberitahuan, webhook, pemberitahuan push, playbook, penskalaan otomatis Log kueri untuk mengidentifikasi komponen yang melanggar dan memicu otomatisasi untuk memperbaiki masalah dengan komponen yang melanggar.

    Berikut adalah daftar sumber daya yang relevan untuk kemampuan pemberitahuan dan otomatisasi di Azure:

    Pemantauan cloud modern

    Dibandingkan dengan platform pemantauan dan alat terkait yang tersedia di masa lalu, penawaran komputasi cloud:

    • Lebih banyak fleksibilitas untuk merancang opsi respons.
    • Cara yang lebih mudah untuk mengembangkan dan mengaktifkan respons otomatis.
    • Protokol cloud atau metode API lebih mudah diintegrasikan dengan sistem manajemen kerja, termasuk DevOps.

    Pertimbangkan mode berikut untuk rentang tindakan otomatis, baik itu untuk penyelidikan, pengayaan, perutean, penugasan, remediasi, pemulihan, atau resolusi:

    Metode orkestrasi Deskripsi
    Otomatis Tindakan dilakukan secara otomatis. Otomatisasi penuh harus terbukti andal, efisien, dan tahan lama di mana kegunaannya tidak berumur pendek dan aman. Otomatisasi penuh membebaskan sumber daya Anda sehingga mereka dapat lebih fokus pada inisiatif strategis Anda.
    Semi-otomatis Persetujuan diperlukan untuk setiap tindakan remediasi.
    Manual Operator memilih contoh otomatisasi atau playbook dari putaka yang dikurasi.

    Pemberitahuan tergantung pada data berinstrumentasi berdasarkan peristiwa keamanan, metrik performa, informasi ketersediaan, dan log. Tindakan berbasis data dihasilkan dari menganalisis perspektif holistik dan end-to-end dari setiap sumber daya yang dipantau dengan menggabungkan dan memproses berbagai jenis data yang dikumpulkan untuk menentukan dampak dan tindakan responsif apa yang harus diambil.

    Perluas pembacaan Anda dengan sumber daya ini untuk mempelajari selengkapnya tentang otomatisasi berdasarkan pemberitahuan metrik dan peristiwa keamanan:

    Efisiensi biaya

    Seperti halnya disiplin pengamatan lainnya, tim perlu memahami dan mewujudkan implikasi biaya dan bagaimana jenis respons yang ditentukan dalam mendukung manajemen insiden modern membantu mengontrol biaya. Meskipun tujuan menyeluruh adalah untuk mengurangi Mean Time to Recovery (MTTR) dengan merespons dan menyelesaikan masalah dengan cepat, Anda harus terus-menerus mengevaluasi potensi biaya dan dampak pada ALIRAN PENDAPATAN IT atau bisnis.

    Setiap insiden yang dilaporkan memiliki biaya. Misalkan organisasi berinvestasi dalam orkestrasi untuk mengotomatiskan respons. Dalam hal ini, Anda harus mengevaluasi manfaat biaya dan dampak biaya dengan meningkatkan konsumsi dari layanan cloud untuk menggunakan layanan atau fitur yang memungkinkan otomatisasi.

    Automation

    Otomatisasi cloud menawarkan keuntungan signifikan untuk pemantauan keamanan dan kesehatan. Kecepatan, fleksibilitas, dan presisi adalah tiga pola dasar yang dibawa otomatisasi cloud ke operasi yang responsif. Sering kali ini disebut orkestrasi, dan cloud Microsoft menawarkan beberapa layanan.

    Misalnya:

    1. Ancaman berbasis identitas terdeteksi dari satu atau beberapa log, yang meningkatkan peringatan.
    2. Otomatisasi segera dipicu untuk mengumpulkan lebih banyak informasi dan menghubungkan lebih banyak log untuk memperkaya pemberitahuan.
    3. Operator mengambil tindakan dengan memilih otomatisasi yang tepat dari pustaka, seperti menonaktifkan akun pengguna.

    Contoh atau kasus penggunaan dapat sepenuhnya otomatis.

    Peran otomatisasi kemudian menyediakan semacam playbook yang mengurangi biaya dan menghemat waktu:

    • Tidak ada insiden keamanan yang diperlukan untuk mengikuti penyelidikan, diagnosis, resolusi, dan pemulihan yang panjang.
    • Siklus deteksi hingga koreksi bisa dalam hitungan detik atau menit versus jam.

    Selanjutnya, tim Anda perlu membuat daftar atau pustaka contoh otomatisasi yang dapat digunakan secara fleksibel - baik dari bahan baku di situs web publik atau dikumpulkan secara internal dan disimpan dalam repositori kontrol sumber.

    Berikut adalah daftar pembacaan yang disarankan untuk lebih banyak otomatisasi berdasarkan peristiwa identitas atau keamanan:

    Strategi peringatan yang berhasil

    Anda tidak dapat memperbaiki apa yang Anda tidak tahu rusak.

    Mengetahui tentang apa yang penting sangatlah penting. Hal ini didukung dengan mengumpulkan dan mengukur metrik dan log yang tepat. Anda juga memerlukan alat pemantauan yang mampu menyimpan, menggabungkan, memvisualisasikan, menganalisis, dan memulai respons otomatis saat kondisi terpenuhi. Anda dapat meningkatkan pengamatan layanan dan aplikasi Anda hanya jika Anda sepenuhnya memahami komposisinya. Anda memetakan komposisi tersebut ke dalam konfigurasi pemantauan terperinci untuk diterapkan oleh platform pemantauan. Konfigurasi ini mencakup status kegagalan yang dapat diprediksi (gejalanya, bukan penyebab kegagalannya) yang masuk akal untuk diwaspadai.

    Pemberitahuan informasi

    Dalam keadaan tertentu, beberapa pemberitahuan dapat bersifat informasi. Kita dapat menggunakan ini untuk mempelajari tentang bagaimana sistem kita berulah. Misalnya, Anda mungkin ingin mendapatkan pemberitahuan informasi ini:

    • VM dimatikan: VM secara otomatis dimatikan untuk meminimalkan biaya limbah dan kontrol berdasarkan jadwal atau pemanfaatan rendah yang terdeteksi.

      Dalam contoh ini, orkestrasi digunakan berdasarkan fitur penjadwalan asli dan oleh platform pemantauan yang mendeteksi kondisi pemanfaatan. Alih-alih peringatan yang memberi tahu atau meningkat sebagai satu-satunya tindakan, hal ini memberi tahu Anda tentang tindakan yang dilakukan dan alasannya.

    • Sumber daya diam: Sumber daya IaaS atau PaaS tidak aktif untuk jangka waktu yang lama atau tidak disediakan berdasarkan rekomendasi Azure Advisor.

      Dalam contoh ini, orkestrasi dapat digunakan untuk mengelola aktivitas terkait infrastruktur tersebut berdasarkan logika bisnis atau alur kerja proses ITSM. Respons dan tindakan yang jauh lebih cepat diperlukan saat ini. Dengan cloud, pemberitahuan lebih sedikit untuk manusia daripada untuk respons otomatis atau orkestrasi yang sedang berlangsung sebagai bagian dari aliran nilai otomatis.

    Pertimbangan strategi pemberitahuan

    Perlu diingat bahwa pembelajaran adalah kunci, dan ketika dirancang dengan benar, pemberitahuan informasi dapat memberi Anda banyak wawasan tentang ekosistem dan kesehatan cloud Anda.

    Pertimbangkan prinsip-prinsip berikut untuk menentukan apakah suatu gejala merupakan kandidat yang tepat untuk waspada:

    • Dapat ditindaklaksakan: Apakah masalahnya penting? Apakah itu mencerminkan masalah nyata dalam kesehatan aplikasi Anda? Misalnya, Anda mungkin ingin mengirim pemberitahuan ketika pemanfaatan CPU terlalu tinggi selama periode berkelanjutan untuk sumber daya atau kueri SQL secara konsisten menyebabkan masalah performa, tetapi Anda mungkin tidak ingin mengirim pemberitahuan saat CPU lonjakan dalam waktu singkat. Buat hal-hal yang dapat ditindak untuk mengurangi positif palsu dan menghindari kelelahan pemberitahuan.

    • Urgensi: Apakah masalah membutuhkan perhatian mendesak? Jika demikian, tim yang bertanggung jawab harus segera diberitahu.

    • Dampak pelanggan: Apakah pengguna layanan atau aplikasi terpengaruh oleh masalah ini?

    • Dampak pada sistem dependen: Apakah ada pemberitahuan dari dependensi yang saling terkait yang dapat dikorelasikan untuk menghindari memberi tahu tim yang berbeda yang semuanya mengerjakan masalah yang sama?

    Dengan pertimbangan awal ini, Anda dapat mulai mengembangkan konfigurasi pemantauan Anda. Anda dapat menguji dan memvalidasi asumsi di seluruh lingkungan. Misalnya, terus mengevaluasi pertimbangan dan pertanyaan ini di lingkungan nonproduksi serta produksi. Peningkatan berkelanjutan adalah kunci keberhasilan respons pada sinyal pemantauan.

    Ketika terus mengevaluasi apa yang berfungsi, pertimbangkan untuk mengajukan pertanyaan-pertanyaan ini kepada diri Anda sendiri untuk membantu mendorong kesadaran tentang efektivitas respons pemantauan Anda:

    • Volume pemberitahuan: Apakah Anda mendapatkan volume pemberitahuan tinggi? Apakah ada banyak pemberitahuan yang tidak dapat ditindaklanjuti yang dapat dihindari?
    • Masalah yang tidak diketahui: Apakah Anda mendapatkan laporan atau tiket dari pengguna yang mengalami masalah yang tidak tertangkap oleh konfigurasi pemantauan?
    • Positif palsu: Apakah Anda mendapatkan pemberitahuan atau sinyal yang salah ditandai?
    • Pemberitahuan atau peristiwa: Apakah Anda benar-benar perlu mengirim pemberitahuan, atau mungkinkah beberapa pemberitahuan yang dinaikkan hanya menjadi peristiwa yang ditandai dalam sistem? Jika sinyal muncul saat Anda memintanya, dibandingkan dengan mengirim pemberitahuan, apakah cukup untuk menghindari kelelahan pemberitahuan dan pemberitahuan yang tidak dapat ditindaklanjuti?

    Lihat gambaran umum platform pemantauan dalam seri artikel ini untuk pemahaman yang lebih mendalam tentang kemampuan di seluruh solusi pemantauan Microsoft.

    Langkah berikutnya