Mengapa para insinyur tidak peduli dengan pemantauan aplikasi?

Semua dengan Jumat! Teman-teman, hari ini kami melanjutkan serangkaian publikasi yang ditujukan untuk kursus Praktek dan Alat DevOps , karena kelas-kelas dalam grup baru pada kursus akan dimulai pada akhir minggu depan. Jadi mari kita mulai!



Memantau itu mudah . Ini adalah fakta yang diketahui. Angkat Nagios, jalankan NRPE pada sistem jarak jauh, konfigurasikan Nagios pada port NRPE TCP 5666 dan Anda memiliki pemantauan.

Sangat mudah sehingga tidak menarik. Sekarang Anda memiliki metrik dasar untuk waktu prosesor, subsistem disk, RAM, yang datang secara default di Nagios dan NRPE. Namun dalam kenyataannya, ini bukan "pemantauan" seperti itu. Ini baru permulaan.

(Biasanya mereka menginstal PNP4Nagios, RRDtool dan Thruk, mengatur notifikasi di Slack dan langsung menuju ke nagiosexchange, tetapi untuk sekarang biarkan saja).

Pemantauan yang baik sebenarnya cukup rumit, Anda benar-benar perlu mengetahui internal aplikasi yang Anda tonton.

Apakah pemantauan sulit?

Server apa pun, apakah Linux atau Windows, menurut definisi akan melayani beberapa tujuan. Apache, Samba, Tomcat, penyimpanan file, LDAP - semua layanan ini lebih atau kurang unik dalam satu atau lebih hal. Masing-masing memiliki fungsi sendiri, karakteristiknya sendiri. Ada beberapa cara berbeda untuk mendapatkan metrik, KPI (indikator kinerja utama), menarik bagi Anda ketika server sedang dimuat.


Foto oleh Luke Chesser di Unsplash


(Saya ingin dasbor saya dicat dengan warna biru-neon - mendesah melamun - ... hmm ...)

Perangkat lunak apa pun yang menyediakan layanan harus memiliki mekanisme untuk mengumpulkan metrik. Apache memiliki modul mod-status yang menampilkan halaman mod-status server. Nginx memiliki stub_status . Tomcat memiliki JMX atau aplikasi web khusus yang menunjukkan metrik kunci. MySQL memiliki perintah "tampilkan status global", dll.
Jadi mengapa pengembang tidak menanamkan mekanisme seperti itu dalam aplikasi yang mereka buat?

Apakah pengembang hanya melakukan ini?

Tingkat ketidakpedulian tertentu untuk menanamkan metrik tidak terbatas pada pengembang. Saya bekerja di perusahaan tempat saya mengembangkan aplikasi menggunakan Tomcat dan tidak menghasilkan metrik saya, tidak ada log aktivitas layanan, kecuali untuk log kesalahan Tomcat umum. Beberapa pengembang menghasilkan banyak log yang tidak berarti apa-apa bagi administrator sistem, yang kurang beruntung membacanya pada pukul 3.15 pagi.


Diposting oleh Tim Gouw di Unsplash

Insinyur sistem yang memungkinkan produk tersebut untuk dirilis juga harus memiliki tanggung jawab atas situasi tersebut. Beberapa insinyur sistem memiliki waktu dan perhatian untuk mencoba mendapatkan metrik yang bermakna dari log, tanpa konteks metrik ini dan kemampuan untuk menafsirkannya berdasarkan aktivitas aplikasi. Beberapa tidak mengerti manfaat apa yang bisa mereka dapatkan dari ini, kecuali untuk indikator seperti "sesuatu saat ini (atau akan segera) salah."

Perubahan dalam pemikiran tentang perlunya metrik harus terjadi tidak hanya di antara pengembang, tetapi juga di antara para insinyur sistem.

Untuk setiap insinyur sistem yang perlu tidak hanya merespons peristiwa kritis, tetapi juga untuk memastikan ketidakhadiran mereka, tidak adanya metrik biasanya menjadi penghalang untuk ini.

Namun, insinyur sistem biasanya tidak menggali kode, menghasilkan uang untuk perusahaan mereka. Mereka membutuhkan pengembang terkemuka yang memahami pentingnya tanggung jawab seorang insinyur sistem dalam mendeteksi masalah, meningkatkan kesadaran akan masalah kinerja, dan sejenisnya.

Ini hal yang penting

Mentalitas devops menggambarkan sinergi pemikiran pengembang (devs) dan eksploitasi (ops). Perusahaan mana pun yang mengaku “melakukan devop” harus:

1. untuk mengatakan apa yang mungkin tidak mereka lakukan (petunjuk pada meme dari film "Princess Bride" - "Saya tidak berpikir itu berarti apa yang Anda pikirkan artinya!")
2. mempromosikan posisi peningkatan produk berkelanjutan.

Anda tidak dapat meningkatkan produk dan tahu bahwa itu telah ditingkatkan jika Anda tidak tahu cara kerjanya saat ini. Anda tidak akan dapat mengetahui bagaimana suatu produk bekerja jika Anda tidak memahami bagaimana komponennya bekerja, layanan yang menjadi sandarannya, titik-titik rasa sakit utama dan kemacetannya.
Kecuali jika Anda mengamati potensi kemacetan, Anda tidak dapat mengikuti teknik Lima Alasan saat menulis Postmortem. Anda tidak dapat mengumpulkan semuanya di satu layar untuk melihat bagaimana produk bekerja atau untuk mengetahui tampilannya “normal dan bahagia.”

Pergeseran kiri, KIRI, SAYA BILANG, Tidaaaaaak—

Bagi saya, salah satu prinsip utama Devops adalah "bergeser ke kiri". Pergeseran ke kiri dalam konteks ini berarti pergeseran kemampuan ( bukan tanggung jawab , tetapi hanya kemampuan) untuk melakukan apa yang biasanya diperhatikan oleh teknisi sistem, misalnya, membuat metrik kinerja, menggunakan log lebih efisien, dll., Ke kiri dalam siklus hidup pengiriman perangkat lunak ( Siklus Hidup Pengiriman Perangkat Lunak).


Foto oleh NESA oleh Makers di Unsplash

Pengembang perangkat lunak harus dapat menggunakan dan mengetahui alat pemantauan yang digunakan perusahaan untuk memantau dalam semua bentuk, metrik, pencatatan, antarmuka pemantauan dan, yang paling penting, mengamati bagaimana produk mereka bekerja dalam produksi . Anda tidak dapat memaksa pengembang untuk menginvestasikan waktu dan upaya untuk memantau sampai mereka dapat melihat metrik dan memengaruhi penampilan mereka, bagaimana pemilik produk akan mempresentasikan CTO mereka pada pengarahan berikutnya, dll.

Singkatnya

1. Bawa kuda ke air. Tunjukkan pada pengembang berapa banyak masalah yang dapat mereka hindari untuk diri mereka sendiri, bantu mereka mengidentifikasi KPI dan metrik yang tepat untuk aplikasi mereka sehingga ada lebih sedikit jeritan dari pemilik produk yang ditelusuri CTO. Bawa mereka ke cahaya, lembut dan tenang. Jika ini tidak berhasil, maka suap, mengancam dan membujuk mereka atau pemilik produk untuk dengan cepat mendapatkan metrik ini dari aplikasi, dan kemudian menggambar diagram. Ini akan sulit, karena tidak akan dianggap prioritas, dan akan ada banyak proyek penghasil pendapatan yang menunggu implementasi dalam peta jalan produk. Oleh karena itu, Anda akan memerlukan kasus bisnis untuk membenarkan waktu dan uang yang dihabiskan untuk menerapkan pemantauan dalam produk.
2. Bantu insinyur sistem mendapatkan tidur yang cukup. Tunjukkan pada mereka bahwa menggunakan daftar periksa rilis rilis untuk produk apa pun adalah baik. Dan memeriksa bahwa semua aplikasi dalam produksi ditutupi dengan metrik akan membantu Anda tidur nyenyak, membiarkan pengembang melihat apa yang berhasil dan di mana itu tidak berfungsi. Namun, cara yang tepat untuk mengganggu dan membuat marah setiap pengembang, pemilik produk, dan CTO adalah dengan mendorong tongkat ke roda dan menahannya. Perilaku ini akan memengaruhi tanggal rilis produk apa pun jika Anda menunggu lagi hingga menit terakhir, jadi sekali lagi bergeser ke kiri dan sertakan masalah ini sesegera mungkin dalam rencana proyek. Jika perlu, pergilah ke pertemuan produk. Kenakan kumis palsu dan rasakan atau sesuatu seperti itu, tidak pernah gagal. Laporkan kekhawatiran Anda, tunjukkan manfaat yang jelas, dan evangelisasi.
3. Pastikan bahwa pengembang (pengembang) dan operasi (operator) memahami arti dan konsekuensi dari memindahkan metrik produk ke zona merah. Jangan meninggalkan operasi sebagai satu-satunya penjaga atas kinerja produk, pastikan bahwa pengembang juga berpartisipasi di dalamnya (#productsquads).
4. Log adalah hal yang hebat, tetapi metrik juga. Gabungkan mereka dan jangan biarkan log Anda menjadi sampah dalam bola besar kesia-siaan. Jelaskan dan tunjukkan kepada pengembang mengapa tidak ada orang selain mereka yang mengerti log mereka, tunjukkan bagaimana rasanya menonton log yang tidak berguna pada jam 3:15 pagi.

Foto oleh Marko Horvat di Unsplash

Itu saja. Materi baru akan dirilis minggu depan. Jika Anda ingin mempelajari lebih lanjut tentang kursus, kami mengundang Anda ke hari terbuka , yang akan diadakan pada hari Senin. Dan sekarang kami secara tradisional menunggu komentar Anda.