Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Tahap 2: Menerapkan observabilitas
Pada tahap ini, Anda memulai proses bagi tim Anda untuk secara bertahap menuju Bintang Utara.
Pilih platform observabilitas Anda
Langkah pertama adalah mengidentifikasi alat yang tepat untuk menelan, memvisualisasikan, dan menganalisis sinyal, dan mengirim peringatan. Saat Anda memilih alat, pertimbangkan set fitur, model lisensi, harga, persyaratan keterampilan, dan pemeliharaannya.
Set fitur
Berikut adalah beberapa pertanyaan yang perlu dipertimbangkan:
-
Konfigurasi dan kustomisasi. Fitur apa yang disediakan alat untuk menyederhanakan pengalaman investigasi dan membantu mengurangi MTTR? Apakah alat ini menyediakan korelasi alarm, matematika metrik, fleksibilitas dalam menangani telemetri yang hilang, atau deteksi anomali?
-
Granularitas. Apa granularitas yang didukung dari konsumsi dan visualisasi sinyal telemetri?
-
Persona. Apakah alat ini mendukung pengalaman yang ingin Anda tawarkan kepada pengembang, insinyur platform, dan persona lainnya? Apakah ini bekerja untuk persona teknis dan bisnis?
-
Widget. Jenis widget apa yang didukung dasbor? Apakah alat ini memungkinkan pembuatan widget khusus?
-
Solusi bawaan. Apa jenis solusi observabilitas bawaan yang ditawarkan alat untuk mengurangi waktu untuk menilai?
-
Otomatisasi dan AI generatif. Fitur apa yang disediakan alat yang dapat membantu mengotomatiskan atau mengurangi kerja keras untuk Anda dan tim Anda? Misalnya, deteksi anomali otomatis, analitik prediktif, dan kemampuan AI generatif lainnya dapat membantu mengurangi stres asumsi dan hal-hal yang tidak diketahui (yaitu, hal-hal yang tidak Anda sadari atau pahami sepenuhnya). Apakah alat ini mendukung penggunaan AI/ML model generatif untuk meningkatkan analisis data dalam skala? Apakah itu memberi Anda opsi untuk mengotomatisasi dan mengimplementasikan? AIOps
-
Keamanan.Jenis otentikasi dan integrasi otorisasi apa yang didukung alat ini? Apakah pengalaman pengguna dan login memenuhi kebutuhan organisasi Anda?
-
OpenTelemetry dukungan. Apakah alat dan agen mendukung OpenTelemetry? Sebagian besar platform observabilitas mendukung konsumsi sinyal yang OpenTelemetry kompatibel, tetapi tidak semua agen menyediakan opsi konfigurasi untuk meneruskan sinyal ini ke platform observabilitas.
-
Integrasi. Integrasi apa yang ditawarkan alat ini? Pertimbangkan apakah Anda perlu mengirim peringatan ke Slack, anggota tim halaman, atau mengotomatiskan resolusi.
-
Skalabilitas. Seberapa skalabel dan kinerjanya alat ini? Solusi observabilitas harus ditingkatkan seiring permintaan dan penggunaan Anda meningkat, sehingga dapat memberikan diagnosis meskipun aplikasi Anda tidak tersedia.
-
Support. Model dukungan apa yang ditawarkan? Alat observabilitas Anda harus tersedia bahkan jika aplikasi Anda gagal sehingga Anda dapat memenuhi MTTR dan target ketersediaan aplikasi atau perjanjian tingkat layanan (). SLAs Solusi open source mungkin menawarkan dukungan formal terbatas.
Model perizinan dan penyebaran
Pertimbangkan model lisensi solusi (open source atau komersial) dan model penerapan (dihosting sendiri atau berbasis cloud). Opsi open source seringkali memiliki biaya dimuka yang lebih rendah tetapi mungkin memerlukan lebih banyak waktu untuk penerapan, penyiapan dan konfigurasi, pemeliharaan, dan peningkatan keterampilan tim sebelum memberikan nilai. Jika Anda mempertimbangkan opsi open source, Anda mungkin memerlukan tim ahli observabilitas yang berdedikasi. Perangkat lunak komersial biasanya menawarkan waktu yang lebih cepat untuk menilai dengan biaya di muka yang lebih tinggi, dan kebutuhan akan tim observabilitas khusus berkembang dari waktu ke waktu seiring dengan meningkatnya adopsi, kompleksitas, dan kematangan. Solusi yang dihosting sendiri memerlukan lebih banyak waktu untuk penerapan, penyiapan dan konfigurasi, pemeliharaan, dan overhead operasional dibandingkan dengan solusi berbasis cloud.
Dimensi harga
Bagaimana model penetapan harga alat memengaruhi total biaya kepemilikan (TCO) Anda saat aplikasi Anda mendapatkan pengguna baru, jejak arsitektur yang lebih besar, atau fitur dan aplikasi baru? Misalnya, beberapa model lisensi tipikal bersifat abadi atau berdasarkan langganan, jumlah pengguna bernama, konsumsi, atau volume. Pertimbangkan bagaimana aplikasi Anda dan alat observabilitas akan diskalakan dalam penggunaan dan bagaimana model lisensi dapat memengaruhi biaya alat.
Keterampilan tim
Bergantung pada keahlian saat ini dan kedewasaan tim Anda, Anda harus menentukan berapa banyak peningkatan keterampilan yang akan dibutuhkan. Pertimbangkan jenis dukungan apa yang disediakan vendor untuk melatih tim Anda. Juga pertimbangkan apakah struktur organisasi Anda mendukung konfigurasi dan manajemen alat yang Anda pilih. Misalnya, jika Anda memilih OpenTelemetry, Anda harus mempertimbangkan untuk membentuk tim terpisah yang berspesialisasi dalam observabilitas.
Operasi dan pemeliharaan
Evaluasi pertanyaan-pertanyaan berikut:
-
Opsi penerapan apa yang ditawarkan agen observabilitas atau kolektor? Apakah opsi tersebut memenuhi persyaratan arsitektur Anda? Misalnya, jika Anda menggunakan penerapan kontainer untuk alat observabilitas, apakah itu mendukung daemonset atau sespan? Langkah atau alat tambahan apa yang perlu diambil atau digunakan oleh tim operasi untuk memastikan keselarasan dengan keamanan dan semua proses lainnya?
-
Apa upaya yang diperlukan untuk mempertahankan solusi? Seberapa sederhana atau otomatiskah proses memperbarui agen atau kolektor? Antarmuka observabilitas yang dikelola sepenuhnya dan berbasis cloud biasanya memiliki overhead operasional yang lebih rendah dibandingkan dengan aplikasi yang digunakan sendiri dan dihosting, meskipun manajemen agen atau kolektor tetap sama. Pertimbangkan struktur tim Anda, dan pertimbangkan biaya manusia untuk mempertahankan opsi yang Anda pilih.
Instrumen aplikasi Anda
Jawaban atas pertanyaan di bagian sebelumnya memberi Anda informasi yang Anda butuhkan untuk instrumen aplikasi Anda—yaitu, menambahkan kode untuk menangkap sinyal telemetri ke aplikasi Anda dan untuk mengukur, mengamati, dan memvalidasi perilaku. Anda dapat menggunakan SDKs seperti OpenTelemetry SDK untuk bahasa aplikasi Anda untuk secara otomatis instrumen aplikasi Anda. Anda mungkin masih perlu menambahkan kode instrumentasi manual untuk menutupi celah dan untuk memastikan end-to-end visibilitas. Berhati-hatilah dengan telemetri yang Anda tambahkan, dan pastikan Anda dapat menghubungkannya kembali ke satu atau lebih SLIs dan SLOs yang Anda buat di tahap sebelumnya.
Kumpulkan telemetri
Menerapkan komponen observabilitas
Saat telemetri mengalir dan tertelan ke dalam platform observabilitas, buat dasbor, peringatan, buku pedoman, dan runbook.
-
Dasbor: Buat dasbor yang berisi informasi yang relevan, termasuk representasi visual dari tren saat ini dan historis yang terkait dengan hasil prioritas Anda. Buat dasbor ini tersedia untuk pemangku kepentingan yang Anda tentukan di tahap 1. Untuk informasi selengkapnya, lihat Membangun dasbor untuk visibilitas operasional di situs
web Amazon Builders' Library. -
Peringatan: Tentukan peringatan untuk memberi tahu tim Anda ketika hasil berisiko atau sedang dilanggar. Pertimbangkan untuk menambahkan peringatan untuk masalah keamanan dan kinerja. Optimalkan peringatan untuk mengurangi kelelahan dan biaya peringatan dengan mengadopsi yang berikut:
-
Gunakan deteksi anomali untuk menghindari pengaturan ambang batas yang keras, yang memerlukan penyesuaian yang sering, dan untuk mengurangi terjadinya yang tidak diketahui-tidak diketahui.
-
Gunakan kombinasi peringatan cerdas yang melihat beberapa metrik terkait bersama-sama alih-alih menyiapkan peringatan individual untuk setiap metrik. Misalnya, alih-alih menyiapkan peringatan terpisah untuk CPU, memori, dan waktu respons, buat satu peringatan bermakna yang hanya memicu ketika metrik ini secara kolektif menunjukkan masalah nyata. Pendekatan ini secara signifikan mengurangi kebisingan peringatan dan membantu tim Anda fokus pada masalah yang berdampak pada layanan yang sebenarnya daripada harus merespons lonjakan metrik yang terisolasi.
-
Hasilkan peringatan hanya ketika pengalaman atau hasil pengguna berisiko. Misalnya, hindari peringatan tentang lonjakan CPU yang disebabkan oleh peningkatan otomatis saat aplikasi Anda tidak memiliki pengguna aktif.
-
-
Buku pedoman: Buku pedoman memberikan model mental dan konteks kepada orang yang merespons insiden atau peringatan, dan membantu mereka mengidentifikasi akar penyebabnya lebih cepat. Pertimbangkan untuk membuat buku pedoman untuk aplikasi yang sangat digabungkan dan kompleks dan untuk aplikasi yang tidak memiliki instrumentasi tetapi secara langsung memengaruhi hasil yang Anda identifikasi dan prioritaskan di tahap 1.
-
Runbook: Gunakan runbook untuk menentukan langkah-langkah yang diperlukan untuk menyelesaikan insiden atau peringatan.
Validasi sistem observabilitas
Sepanjang siklus hidup pengembangan perangkat lunak (SDLC) Anda, validasi bahwa dasbor memberikan perilaku dan pembaruan yang diharapkan selama pengujian sistem. Menerapkan rekayasa kekacauan dan memvalidasi langkah-langkah yang didokumentasikan dalam buku pedoman dan runbook, untuk memastikan bahwa mereka akurat dan memenuhi tujuannya. Anda juga harus memvalidasi kepemilikan peringatan dan jalur eskalasi.
