Archives for Juli 2020

EC2 Memantau Praktik Terbaik: Menggunakan SIOS AppKeeper untuk Melindungi NGINX Webservers di Amazon EC2

Juli 14, 2020 by Jason Aw Leave a Comment

EC2 Memantau Praktik Terbaik: Menggunakan SIOS AppKeeper untuk Melindungi NGINX Webservers di Amazon EC2

NGINX adalah server web yang juga dapat bertindak sebagai penyeimbang beban, proxy terbalik, dll. Bersama-sama di antara mereka, NGINX dan Apache melayani lebih dari 50% lalu lintas di web. Saat ini banyak perusahaan yang menjalankan NGINX Open Source atau NGINX Plus webservers mereka di lingkungan Amazon EC2 menggunakan Amazon Linux, Red Hat Linux, dan Ubuntu.

Semua orang setuju bahwa ini adalah praktik terbaik untuk memantau aplikasi seperti NGINX di EC2 dan merespons setiap penyimpangan sistem dengan cepat. Pengguna mengharapkan akses cepat dan waktu aktif konstan untuk aplikasi mereka.

Pilihan saat ini untuk memantau webservers NGINX di Amazon EC2

Banyak perusahaan mengerahkan Amazon CloudWatch untuk memantau aplikasi mereka, dan bahkan menciptakan beberapa tingkat otomatisasi dengan mengembangkan skrip atau dengan menggunakan AWS Lambda. Tetapi mengonfigurasi Amazon CloudWatch dengan benar dengan metrik khusus dan mengatur Amazon Lambda membutuhkan sejumlah keahlian teknis yang mungkin melebihi kemampuan banyak perusahaan. Dan kemudian ada biaya dan upaya yang diperlukan untuk memelihara skrip apa pun saat aplikasi berkembang.

Pilihan lain adalah menggunakan solusi pemantauan kinerja aplikasi (APM), seperti solusi dari New Relic, Dynatrace, Datadog, atau LogicMonitor. Solusi APM sangat bagus. Mereka melakukan pekerjaan yang sangat baik untuk mengawasi semua sistem Anda dan menunjukkan dengan tepat apa yang terjadi dan mengapa. Mereka membuat log yang dapat dibagikan dengan dan ditafsirkan oleh tim pengembangan Anda untuk menciptakan kembali masalah dan memastikan bahwa itu tidak terjadi lagi. Tapi inilah masalahnya: solusi APM menyediakan banyak data yang harus Anda pilah (memisahkan "sinyal dari kebisingan") dan mereka tidak melakukan apa pun untuk memulihkan dari kegagalan ketika terjadi. Alat APM hanya bagian dari solusi untuk mengurangi waktu henti untuk webservers NGINX Anda.

Tetapi beberapa perusahaan tidak memiliki staf internal atau alat untuk memantau lingkungan EC2 mereka sendiri. Ini adalah alasan mengapa mereka memilih untuk melakukan outsourcing tugas ke penyedia layanan yang dikelola. Ada beberapa manfaat nyata untuk bekerja dengan MSP untuk mengelola lingkungan Anda, seperti tidak harus mempekerjakan lebih banyak staf saat lingkungan Anda berkembang, atau tidak harus melatih tim Anda tentang teknologi baru. Dan MSP menikmati efisiensi karena mereka dapat menyebar investasi mereka ke banyak klien. Tetapi ada kelemahannya. Dalam beberapa kasus, Anda dapat dikunci ke dalam kontrak berbiaya tinggi, biaya tetap, dan biaya dapat meningkat jika masalah dialami dan harus ditingkatkan untuk mengatasinya. Dan Anda kehilangan kesinambungan antara tim yang memantau lingkungan dan mereka yang bertanggung jawab untuk membangun dan menggunakan aplikasi.

Apakah Anda memilih untuk berinvestasi dalam solusi APM atau untuk melakukan outsourcing ke MSP, Anda masih perlu memikirkan seberapa cepat Anda dapat memulihkan server web NGINX Anda dari downtime jika dan ketika itu terjadi. Kami ingin mengusulkan alternatif lain: remediasi otomatis dengan SOIS AppKeeper.

SIOS AppKeeper: Remediasi otomatis untuk server web NGINX di EC2

Banyak pelanggan kami telah memilih untuk menggunakan SIOS AppKeeper untuk melindungi server web NGINX mereka. Meskipun mereka dapat memilih solusi pemantauan kinerja aplikasi standar (APM) atau solusi pemantauan pihak ketiga, mereka memilih untuk mengandalkan AppKeeper untuk secara otomatis memulihkan layanan atau seluruh instance EC2 jika terjadi kegagalan. Kami akan melihat beberapa alasan mengapa dan membagikan kepada Anda sebuah video pendek yang menunjukkan bagaimana AppKeeper bekerja dengan NGINX.

SIOS AppKeeper adalah layanan SaaS yang mudah dipasang dan dikonfigurasikan dan memonitor semua aplikasi yang berjalan di Amazon EC2, seperti webservers NGINX Anda dan layanan "nginx", "cache manager", dan "pekerja" mereka. Ketika anomali terdeteksi, AppKeeper secara otomatis me-restart layanan, dan jika itu tidak berhasil, reboot seluruh contoh. Tidak ada lagi membaca log yang menyakitkan untuk menunjukkan alasan kegagalan, atau eskalasi kepada pengembang untuk memulai kembali layanan Anda atau biaya outsourcing yang mahal. AppKeeper menyediakan fungsionalitas "set-it-and-forget-it" sehingga Anda dapat yakin mengetahui bahwa NGINX webservers Anda mengikuti praktik terbaik pemantauan EC2 dan berjalan dengan baik, atau akan segera dimulai kembali jika mereka mengalami masalah.

Saat ini ratusan perusahaan mengandalkan AppKeeper untuk menjaga lingkungan cloud mereka tetap berjalan. Kami mengundang Anda untuk melihat video cepat ini untuk demonstrasi tentang bagaimana AppKeeper melindungi server web NGINX.

Jika Anda ingin mencoba SIOS AppKeeper untuk Anda sendiri, kami menawarkan uji coba gratis selama 14 hari. Cukup klik di sini untuk mendaftar.

Apa itu Amazon CloudWatch?

Juli 12, 2020 by Jason Aw Leave a Comment

Apa itu Amazon CloudWatch

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.

AWS EC2 Monitoring dengan AppKeeper

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

Juli 8, 2020 by Jason Aw Leave a Comment

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:

Uji pembaruan kernel dan pembaruan keamanan
Validasi pengaturan dan penyetelan konfigurasi
Mereproduksi masalah produksi dan menguji pembaruan dan patch perangkat lunak
Verifikasi kompatibilitas versi aplikasi dan kurangi risiko downtime karena perubahan yang tidak kompatibel
Berikan ruang yang aman untuk berlatih dan merevisi go-live, pemeliharaan, penghentian, dan kegiatan prosedural perusahaan lainnya
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:

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

Studi Kasus: Solusi Pemantauan AWS EC2 membebaskan perusahaan manufaktur global dari tekanan saat berpindah ke cloud.

Juli 7, 2020 by Jason Aw Leave a Comment

Pabrikan Tokyo Diamond Tools Melindungi Aplikasi Penting dengan SIOS AppKeeper

Didirikan pada tahun 1932, Tokyo Diamond Tools Mfg. Co, Ltd memproduksi alat berlian untuk memotong, memotong, memoles, dan proses pengeboran di berbagai bidang seperti elektronik rumah, semikonduktor, perangkat elektronik, kesehatan dan teknik sipil. Meskipun merupakan perusahaan yang telah lama berdiri dengan lebih dari 80 tahun sejarah, Tokyo Diamond selalu secara agresif memperkenalkan alat-alat TI baru. Perusahaan memutuskan untuk pindah ke Amazon AWS dan virtualisasi untuk kecepatan dan efisiensi peningkatan bisnis. SIOS AppKeeper memainkan peran penting dalam memberikan perlindungan ketersediaan aplikasi yang mereka butuhkan. Salah satu alasan perpindahan Tokyo Diamond Tools ke cloud dan AWS adalah Gempa Bumi Besar Jepang Timur tahun 2011. Meskipun tidak ada kerusakan langsung ke server di kantor pusat, peralatan di pabrik Sendai di Prefektur Miyagi keluar dari rak, menyebabkan kerusakan serius. Tokyo Diamond melihat perlunya rencana kesinambungan bisnis yang lebih baik. Ini adalah pendorong utama untuk beralih ke virtualisasi sistem inti mereka dan menggunakan lingkungan cloud.

Pada awalnya, perusahaan mulai memigrasi aplikasi yang relatif kecil ke cloud. “Kami mulai bergerak sekitar November 2011. Pada saat itu, kami tidak punya pilihan selain AWS, ”kata Mr Takuji Kokubo, kepala Sistem TI di Tokyo Diamond. Mereka mengelola operasi sendiri menggunakan portal cloud "Managed Cloud with AWS" Sony Network Communications. Mr. Kokubo, adalah "operasi IT One Man" yang menggambarkan dirinya sendiri, sehingga efisiensi dan otomasi penting untuk memungkinkan kelancaran operasi sistem TI perusahaan, di lokasi di Jepang serta di Singapura dan Thailand.

Takuji Kokubo, Tokyo Diamond Tools — Tuan Takuji Kokubo,
Kepala Sistem TI
Tokyo Diamond Tools Mfg. Co, Ltd.

Pindah ke cloud dan mengidentifikasi kebutuhan untuk solusi pemulihan

Diamond Tools mengimplementasikan Amazon EC2 dan Amazon S3, layanan penyimpanan cloud. Mereka memindahkan groupware, dukungan penjualan, dan sistem konferensi video mereka ke AWS. Sistem konferensi video Diamond Tools sangat penting untuk operasi sehari-hari mereka. “Ini adalah alat yang sangat sering digunakan dalam berbagai konferensi dan pertemuan dengan lokasi di luar negeri. Ini digunakan sekitar 100 kali sebulan, dan dengan transisi dari sistem SaaS pay-as-you-go konvensional ke AWS, kami dapat mengurangi biaya sebanyak dua juta yen setahun, ”kata Kokubo. Sebelumnya, kualitas suara sering turun ketika terlalu banyak pengguna termasuk perusahaan lain yang terhubung ke sistem secara bersamaan. Kemudian Pak Kokubo akan menerima keluhan dari pengguna tetapi masalahnya tidak dapat diselesaikan dengan mudah. Membangun sistem konferensi video khusus perusahaan di AWS telah menstabilkan kualitas video dan audio dan mengurangi keluhan.

Mr. Kokubo segera mengalami masalah dengan lingkungan EC2 mereka. “EC2 stabil sebagai infrastruktur; namun, terkadang layanan di dalamnya gagal. Saya selalu khawatir, dan suatu hari, selama perjalanan bisnis ke luar negeri, saya mendapat telepon yang mengatakan bahwa pengguna tidak dapat mengakses sistem. Saya harus membuka laptop saya, yang saya bawa sepanjang waktu, untuk terhubung ke AWS melalui VPN dan memulihkan layanan yang gagal, ”kata Mr. Kokubo. Jelas proses ini tidak dapat diskalakan.

Kegagalan layanan sering terjadi pada contoh di mana aplikasi groupware berjalan. Sebagian besar karyawan perusahaan menggunakan aplikasi groupware setiap pagi untuk memeriksa kalender atau memesan ruang pertemuan. "Banyak orang akan memanggil saya untuk bertanya apa yang terjadi jika mereka mengalami masalah," kata Tuan Kokubo. Dia belajar risiko mengurus sistem sendiri melalui pengalaman ini.

“Sepuluh tahun yang lalu, sistem akan berhenti ketika ada kegagalan, dan pengguna terbiasa dengan itu. Namun, hari ini, saya mendapat keluhan begitu sesuatu berhenti. Sekarang, sistem diharapkan dapat beroperasi setiap saat, seperti air yang keluar dari keran kapan saja. Sistem downtime menjadi semakin tidak dapat diterima, ”kata Mr. Kokubo.

Mr. Kokubo selalu merasa bahwa dia harus mengurus masalah apa pun ketika salah satu layanan yang berjalan di EC2 gagal. Menjadi satu-satunya orang yang mampu menangani masalah apa pun terus menjadi beban baginya. Pak Kokubo berkata, “Menjadi seorang pria yang berbelanja di IT, saya cenderung menganggap bahwa nilai saya terletak pada hanya menyediakan fungsi help desk. Tapi itu tidak baik – saya perlu mempertimbangkan bagaimana saya dapat membuat sistem Tokyo Diamond bekerja tanpa dukungan saya. "

Karena dia adalah satu-satunya profesional TI di perusahaan yang lebih mengandalkan layanan cloud, dia tahu dia butuh bantuan. “Ketika Sony Network Communications memberi tahu saya bahwa SIOS AppKeeper menyediakan operasi otomatis dan manajemen instance EC2, saya memutuskan untuk menggunakannya bahkan sebelum melihat detailnya. Jika kami dapat memiliki solusi yang memulihkan layanan EC2 secara otomatis, maka saya tidak perlu memecahkan masalah setiap masalah dengan menghubungkan ke VPN saat bepergian, "tambah Mr. Kokubo.

SIOS AppKeeper adalah layanan cloud yang memantau instance EC2 dan memulai kembali layanan secara otomatis ketika mendeteksi gangguan sistem. Ketika layanan yang dipantau gagal, SIOS AppKeeper memulihkan layanan secara otomatis tanpa harus memiliki staf yang campur tangan secara manual.

Lebih dari 10 Aplikasi Berjalan pada AWS

Tokyo Diamond terus memigrasi aplikasi lain ke AWS, dan pada Juni 2018 ada lebih dari 10 aplikasi yang berjalan di AWS. “Saya merasa bahwa AWS berguna: sistem operasi dimulai dalam 10 menit dan sumber daya dapat ditingkatkan / turun secara fleksibel tergantung pada bisnis. Kami bahkan dapat menghapus sumber daya meskipun tidak berfungsi. Namun, sistem inti yang memproses sejumlah besar data dipindahkan ke lingkungan virtual menggunakan pusat data, bukan AWS. Kami menggunakan AWS dan pusat data virtual untuk membangun sistem tergantung pada penggunaan dan kebutuhan, ”kata Mr. Kokubo.

Tokyo Diamond saat ini memantau tiga aplikasi penting yang diandalkan karyawan dengan AppKeeper, termasuk aplikasi groupware, otomasi tenaga penjualan, dan sistem konferensi video mereka. Pak Kokubo berkata, “Pertama, kami mengklasifikasikan aplikasi kami dan memutuskan untuk memulai dengan tiga aplikasi. Adalah layak untuk membayar biaya jika saya dapat dibebaskan dari beban mental sehari-hari dan mendapatkan ketenangan pikiran selama perjalanan bisnis. ”

SIOS AppKeeper Memungkinkan Personil TI untuk Fokus pada Tugas Lainnya

Menurut Tuan Kokubo, ia tidak perlu lagi memikirkan operasi dan manajemen instance yang dipantau oleh AppKeeper. AppKeeper bekerja dengan sempurna. Ini telah meluangkan waktunya untuk fokus pada mesin virtual dan aplikasi AWS lainnya. Mr. Kokubo merasa bahwa AppKeeper memberinya rasa aman tentang aplikasi inti ini.

Namun, ia memang memiliki permintaan untuk tim pengembangan SIOS Technology tentang AppKeeper. “Jika tidak ada acara, saya khawatir tentang apakah itu berfungsi dengan baik, atau saya mungkin lupa cara login. Akan lebih baik jika sering memberi tahu saya bahwa itu berfungsi, ”kata Kokubo. Operasi dan manajemen otomatis adalah kekuatan SIOS AppKeeper; Namun, hal itu bisa tidak terlihat ketika tidak ada yang terjadi.

Karena itu, Tuan Kokubo setuju bahwa sangat menguntungkan bahwa ia dibebaskan dari keharusan memecahkan masalah aplikasi ini. Sekarang dia dapat menghabiskan lebih banyak waktu untuk manajemen, termasuk mengembangkan strategi dan perencanaan TI Diamond Tool, keamanan, dan inisiatif BCP.

Meskipun hari ini Diamond Tool menggunakan SIOS AppKeeper untuk operasi dan manajemen tiga aplikasi, ia berencana untuk memperluas cakupan AppKeeper ke aplikasi lain segera. Ini akan memungkinkan Pak Kokubo menghabiskan banyak waktu untuk kegiatan-kegiatan bernilai tambah itu. "Bahkan jika kita mencoba untuk merekrut personel sistem, itu sulit karena tenaga kerja Jepang menyusut. Di masa depan, saya berharap alat sistem untuk menggantikan orang yang menggunakan AI (Kecerdasan Buatan), dan saya berharap SIOS AppKeeper juga mengembangkan fungsi seperti AI untuk secara otomatis mengatasi kegagalan berdampak tinggi, ”kata Kokubo, berharap untuk hari ketika otomatisasi lebih lanjut manajemen operasi akan direalisasikan.

Pelajari lebih lanjut tentang SIOS AppKeeper

Mendaftar untuk Uji Coba Gratis SIOS AppKeeper