Apa itu Amazon CloudWatch?

Apa yang dapat Anda lakukan dengan CloudWatch dan beberapa rintangan untuk dipertimbangkan

Dengan AWS yang memiliki pangsa pasar cloud yang dominan, banyak perusahaan yang memigrasi sistem lokal mereka ke cloud dengan Amazon AWS.  Jadi, bagaimana seharusnya sistem yang berjalan di lingkungan AWS dikelola?

Dalam posting blog ini, kami akan memperkenalkan fitur Amazon CloudWatch, layanan pemantauan yang disediakan oleh AWS, serta tantangan untuk mengimplementasikannya dan bagaimana menyelesaikannya.

Menggunakan Amazon CloudWatch untuk memonitor lingkungan AWS Anda

Untuk memastikan bahwa Anda memiliki lingkungan cloud yang stabil, penting untuk mendeteksi anomali ("gangguan sistem") dengan cepat dan merespons secara tepat waktu.  Pemantauan menjadi tugas penting dan perlu bagi organisasi mana pun yang pindah ke cloud.  Ini tidak berbeda dengan jika Anda mengelola aplikasi dan infrastruktur di tempat. Jadi, bagaimana seharusnya Anda memonitor di lingkungan AWS? Satu pilihan adalah menggunakan Amazon CloudWatch, yang memonitor penggunaan CPU, memori, dan disk dan memberi tahu Anda ketika ambang yang telah ditentukan terlampaui.  Plus, Anda dapat mengatur metrik Anda sendiri untuk memantau berbagai item seperti log aplikasi.

Bagian terbaik tentang Amazon CloudWatch adalah layanan yang disediakan oleh AWS sendiri.  Ini memiliki afinitas tinggi dengan Amazon EC2 dan layanan AWS lainnya, sehingga dapat dengan cepat menanggapi ekstensi fungsional yang sering dan perubahan spesifikasi, dan dapat dengan mudah mendukung AWS Auto Scaling, yang secara otomatis menambah atau mengurangi sumber daya sesuai dengan beban.  Amazon CloudWatch menyediakan pemantauan akurat yang disesuaikan dengan keadaan unik setiap lingkungan.

Tantangan implementasi Amazon CloudWatch

Sementara Amazon CloudWatch sangat cocok untuk organisasi dengan insinyur cloud dan tim DevOps yang berpengalaman, ada beberapa hal yang harus diperhatikan oleh rata-rata pengguna.

Amazon CloudWatch efektif untuk memantau lingkungan AWS organisasi, tetapi memerlukan tingkat keterampilan dan pengetahuan tertentu untuk mengonfigurasi dan menggunakan.  Terutama ketika Anda mengatur metrik Anda sendiri, menyiapkan lansiran, atau mempertimbangkan Penskalaan Otomatis akun, kompleksitasnya meningkat. Misalnya, Jika Anda mengatur pemantauan, itu mudah, tetapi jika Anda mengatur email, me-reboot, AutoScaling, dll., Tergantung pada situasi sumber daya, itu bisa sulit.

Jika Anda ingin mengotomatiskan proses pemulihan dengan instruksi seperti "restart server ketika kesalahan terjadi", Anda harus terlebih dahulu membuat skenario pemulihan dengan skrip AWS Lambda yang menyediakan deskripsi terperinci tentang kondisi dan tindakan yang harus diambil.  Seberapa familiar tim Anda dengan AWS Lambda?

Keuntungan utama dari Amazon CloudWatch adalah Anda dapat memonitor lingkungan Anda dengan seksama, tetapi untuk melakukan itu, Anda harus mendesain terlebih dahulu dengan tepat untuk setiap sistem item yang akan dipantau dan kapan, nilai ambang, dll.  Tugas desain ini bisa memakan banyak waktu.  Tentu saja, sistem kritis-misi Anda perlu diawasi dengan ketat dengan cara ini, tetapi tingkat detail dan kecanggihan ini tidak sesuai untuk semua sistem. Untuk beberapa, seperti situs web internal atau server WordPress, Anda harus meminimalkan biaya operasi dan tenaga kerja Anda. Dalam kasus seperti itu, kami ingin menyarankan Anda mempertimbangkan alat yang dapat lebih mudah dioperasikan dan dikelola.

SIOS AppKeeper untuk memonitor sistem operasi dan layanan aplikasi yang berjalan pada AWS

Untuk aplikasi kritis non-misi, kami ingin merekomendasikan SIOS AppKeeper dari SIOS Technology.  AppKeeper mudah untuk menginstal dan mengkonfigurasi serta memantau layanan (proses) aplikasi yang berjalan pada instance EC2.  AppKeeper secara otomatis me-restart layanan ketika kesalahan terdeteksi dan reboot instance jika perlu.   Bahkan pengguna yang pindah ke cloud untuk pertama kalinya dapat mengatur AppKeeper untuk memonitor instance EC2 mereka dan pulih secara otomatis, tanpa perlu memiliki keterampilan scripting yang canggih.

Dengan AppKeeper, tidak perlu memilih layanan individual untuk dipantau. Anda cukup memulai dengan memilih instance EC2 yang akan dipantau dan tindakan apa yang ingin Anda ambil secara otomatis.  Anda selalu bisa lebih spesifik tentang layanan mana yang harus dipantau dan bagaimana caranya, tetapi AppKeeper dirancang agar mudah dikonfigurasikan di luar kotak.  Ketika kesalahan terdeteksi atau secara otomatis dipulihkan dari, log kegagalan dicatat dan disimpan sehingga penyebab kegagalan dapat diselidiki kemudian.

Daripada menggunakan Amazon CloudWatch untuk memonitor segala sesuatu di lingkungan AWS Anda, kami menyarankan Anda mengambil inventaris lingkungan Anda berdasarkan SLA Anda dan persyaratan pemulihan, dan menggunakan SIOS AppKeeper untuk memantau sistem dan aplikasi di mana Anda ingin mengurangi overhead operasional Anda.

Nantikan posting blog di masa depan di mana kita akan pergi ke detail yang lebih besar membandingkan cara mengatur CloudWatch dan AppKeeper untuk melakukan fungsi yang sama.

Pelajari lebih lanjut tentang SIOS AppKeeper

Mendaftar untuk Uji Coba Gratis SIOS AppKeeper

Sistem Test / QA adalah Bagian Kritis Ketersediaan Perusahaan

"Aku bisa menciummu," itulah yang dikatakan seorang teman kepadaku hampir tiga dekade lalu ketika dia berlari ke arahku. Dia telah menjatuhkan buluh untuk saxophone dalam perjalanan ke salah satu kompetisi band terbesar di wilayah kami. Saya tidak tahu siapa mereka, tetapi ketika saya melihat sebatang buluh di kursi di dalam bus, saya mengambilnya dan membawanya bersama saya ke area pemanasan. Tiga menit setelah pemanasan, buluh pertamanya retak dan dia panik ketika merogoh saku kosong untuk penggantian. Ketika aku sadar bahwa aku telah menemukan mereka, dia berkata, "Aku bisa menciummu sekarang."

Sebagai Wakil Presiden Pengalaman Pelanggan di SIOS Technology Corp. Saya memiliki kesenangan unik dan berbeda bekerja dengan sejumlah pelanggan dan mitra perusahaan pada fase berbeda dari spektrum ketersediaan. Terkadang saya memiliki kesempatan untuk bekerja dengan pelanggan akhir untuk penyelesaian masalah, mitigasi, dan perbaikan. Di lain waktu tim kami secara aktif bekerja dengan mitra dan pelanggan untuk merancang dan mengimplementasikan ketersediaan perusahaan untuk melindungi sistem mereka dari gangguan. Pengalaman pelanggan baru-baru ini mengingatkan saya pada sesuatu yang terjadi hampir 30 tahun yang lalu ketika teman saya berkata, "Aku bisa menciummu."

Saya dan tim saya melakukan panggilan telepon. Panggilan dimulai dengan basa-basi, perkenalan, dan gambaran umum tentang lingkungan perusahaan pelanggan. Tiga puluh menit setelah telepon, segalanya berjalan sangat baik. Arsitektur mereka solid, bijaksana, dan terdokumentasi dengan baik. Tim mereka berpengetahuan, secara teknis sehat, dan berpengalaman. Tapi kemudian, pelanggan mengisyaratkan bahwa karena penghematan biaya mereka tidak akan berencana untuk mempertahankan sistem uji / kualitas khusus. Aku menghela nafas panjang.  Sebenarnya itu lebih seperti menghembuskan napas seperti hembusan udara dari perut. Saya bersiap untuk merespons, tetapi sebelum saya dapat, sebuah suara menerobos.  "Penyebab utama downtime adalah kurangnya proses," seru Arsitek Perwakilan Mitra melalui panggilan bersama kami. Setelah olok-olok singkat, pelanggan setuju untuk mempertahankan sistem tes / QA dan saya hampir berkata, "Saya bisa menciummu!"

Di garis depan dari banyak penyebaran Perusahaan (sistem baru, migrasi pusat data, dan pembaruan sistem) tim saya di Dukungan dan Layanan telah melihat lusinan masalah yang bisa dimediasi dengan menggunakan sistem / cluster uji.

Sistem uji / kualitas adalah bagian yang tak ternilai dari strategi HA untuk menghindari downtime. Tugas umum yang terkait dengan mempertahankan penyebaran perusahaan seperti tambalan, pembaruan, dan perubahan konfigurasi disertai risiko. Risiko yang sangat besar.

Risiko yang umum diidentifikasi dari pengujian dalam produksi meliputi beberapa masalah serius dan berpotensi bencana: 

• Data rusak atau tidak valid
• Kebocoran data yang dilindungi
• Pengakuan pendapatan salah (pesanan dibatalkan, dll.)
• Sistem kelebihan beban
• Efek samping atau dampak yang tidak diinginkan pada sistem produksi lainnya
• Tingkat kesalahan tinggi yang memicu peringatan dan orang-orang halaman saat panggilan
• Analisis miring (corong lalu lintas, hasil uji A / B, dll.)
• Log lalu lintas yang tidak akurat penuh dengan aktivitas skrip dan bot (a)

Jika pelanggan mencoba menerapkan perubahan berisiko dalam produksi, hasilnya bisa sangat merusak. Di atas semua yang tercantum di atas, ada peningkatan risiko downtime, korupsi instalasi aplikasi, dan dalam beberapa kasus kerusakan permanen. Ambil contoh Pelanggan X (toko SAP Enterprise profil tinggi di industri manufaktur).

Setelah membaca pemberitahuan kritis dari situs terkemuka, Administrator OS dengan cepat memperbarui node produksinya ke pembaruan kernel terbaru yang tersedia. Dalam beberapa jam, simpul Produksi memulai serangkaian crash dan panik kernel yang belum diinisiasi. Dengan tergesa-gesa, ia telah menginstal kernel yang tidak sesuai dengan konfigurasinya; kombinasi paket aplikasi yang ada, perangkat, sistem file, dan paket terkait. Hal ini menyebabkan pemadaman produksi dan beberapa peningkatan prioritas tinggi ke beberapa vendor.

Ketika tambalan diterapkan pada sistem uji / QA atau kotak pasir, tambalan dan perbaikan kritis dapat dikelola dan diverifikasi untuk mengurangi hilangnya produktivitas dan waktu henti yang tidak direncanakan. Menguji aplikasi dalam lingkungan seperti produksi memungkinkan Anda untuk mengidentifikasi masalah yang tidak terduga dan memperbaiki masalah sebelum mereka berdampak buruk pada operasi Anda. Desain dan pengujian pra-produksi menghilangkan gangguan bisnis yang mahal, meningkatkan pengalaman pelanggan Anda dan melindungi merek Anda.

Menggunakan sistem QA uji untuk Meningkatkan Ketersediaan dan Proses Produksi

Berikut adalah dasar-dasar yang menggunakan sistem uji / QA, dapat menyediakan untuk meningkatkan ketersediaan dan proses produksi Anda. Lingkungan terkendali, yang serupa (harus menyerupai produksi sedekat mungkin) dengan lingkungan produksi, memberikan kemampuan untuk:

1. Uji pembaruan kernel dan pembaruan keamanan
2. Validasi pengaturan dan penyetelan konfigurasi
3. Mereproduksi masalah produksi dan menguji pembaruan dan patch perangkat lunak
4. Verifikasi kompatibilitas versi aplikasi dan kurangi risiko downtime karena perubahan yang tidak kompatibel
5. Berikan ruang yang aman untuk berlatih dan merevisi go-live, pemeliharaan, penghentian, dan kegiatan prosedural perusahaan lainnya
6. Latih karyawan baru dan anggota tim tanpa memengaruhi klien perusahaan

Jika Anda memiliki lingkungan Uji / QA untuk menggunakan perangkat lunak ketersediaan perusahaan penting Anda, saya bisa mencium Anda sekarang. Memiliki lingkungan ini memberi tim Anda kemampuan "untuk menguji, memvalidasi, dan memverifikasi (2)" arsitektur, persyaratan bisnis, skenario pengguna, dan integrasi umum dengan sistem atau serangkaian sistem yang paling mirip dengan lingkungan produksi – Anda tahu yang menghasilkan uang. Tentu saja, Anda masih harus menjadwalkan jendela untuk mempertahankan sistem produksi Anda dan melakukan pengujian pada mereka juga, tetapi setelah langkah buffer aman telah selesai di antaranya.

– Cassius Rhue, VP, Pengalaman Pelanggan

————-

Referensi:

1. https://opensource.com/article/19/5/dont-test-produksi Diakses 5/4/2020
2. https://www.softwaretestingclass.com/system-testing-what-why-how/ Diakses 5/4/2020