Sugeng dinten jumat sedaya! Kanca-kanca, dina iki kita nerusake seri publikasi khusus kanggo kursus kasebut , amarga kelas ing grup anyar kanggo kursus bakal diwiwiti ing pungkasan minggu ngarep. Dadi, ayo miwiti!
Pemantauan yaiku mung. Iki kasunyatan sing dikenal. Nggawa Nagios, mbukak NRPE ing sistem remot, ngatur Nagios ing NRPE TCP port 5666 lan sampeyan kudu ngawasi.
Gampang banget ora menarik. Saiki sampeyan duwe metrik dhasar kanggo wektu CPU, subsistem disk, RAM, diwenehake kanthi standar kanggo Nagios lan NRPE. Nanging iki ora bener "ngawasi" kaya ngono. Iki mung wiwitan.
(Biasane padha nginstal PNP4Nagios, RRDtool lan Thruk, nyetel kabar ing Slack lan langsung menyang nagiosexchange, nanging ayo ninggalake sing metu kanggo saiki).
Ngawasi apik iku bener cukup Komplek, sampeyan pancene kudu ngerti internals saka aplikasi sing ngawasi.
Apa ngawasi angel?
Sembarang server, dadi Linux utawa Windows, kanthi definisi bakal duwe sawetara tujuan. Apache, Samba, Tomcat, panyimpenan file, LDAP - kabeh layanan iki luwih utawa kurang unik ing siji utawa luwih. Saben duwe fungsi dhewe, ciri dhewe. Ana macem-macem cara kanggo entuk metrik, KPI (indikator kinerja utama), sing menarik kanggo sampeyan nalika server lagi dimuat.
Pengarang foto ing
(Muga-muga dashboardku biru neon - ngelamun -... hmm...)
Piranti lunak apa wae sing nyedhiyakake layanan kudu duwe mekanisme kanggo ngumpulake metrik. Apache duwe modul mod-status, nampilake kaca status server. Nginx wis - stub_status. Tomcat duwe JMX utawa aplikasi web khusus sing nuduhake metrik kunci. MySQL duwe printah "show global status" etc.
Dadi kenapa pangembang ora nggawe mekanisme sing padha menyang aplikasi sing digawe?
Apa mung pangembang sing nindakake iki?
Tingkat tartamtu saka indifference kanggo metrik embedding ora winates kanggo pangembang. Aku kerja ing perusahaan sing ngembangake aplikasi nggunakake Tomcat lan ora menehi metrik dhewe, ora ana log kegiatan layanan, kajaba log kesalahan Tomcat umum. Sawetara pangembang ngasilake akeh log sing ora ana gunane kanggo administrator sistem sing cukup apes maca ing 3:15 esuk.
Pengarang foto ing
Insinyur sistem sing ngidini produk kasebut diluncurake uga kudu tanggung jawab kanggo kahanan kasebut. Sawetara insinyur sistem duwe wektu utawa keprigelan kanggo nyoba ngekstrak metrik sing migunani saka log, tanpa konteks metrik kasebut lan kemampuan kanggo napsirake babagan kegiatan aplikasi. Sawetara ora ngerti carane bisa entuk manfaat saka iku, liyane saka "ana sing saiki (utawa bakal rauh) salah" pratondho.
Owah-owahan ing pamikiran babagan kabutuhan metrik kudu kedadeyan ora mung ing antarane pangembang, nanging uga ing antarane insinyur sistem.
Kanggo insinyur sistem sing ora mung kudu nanggapi acara kritis, nanging uga mesthekake yen ora kedadeyan, kekurangan metrik biasane dadi alangan kanggo nindakake.
Nanging, insinyur sistem biasane ora nggunakake kode kanggo nggawe dhuwit kanggo perusahaan. Dheweke butuh pangembang utama sing ngerti pentinge tanggung jawab insinyur sistem kanggo ngenali masalah, nambah kesadaran babagan masalah kinerja, lan liya-liyane.
Iki devops bab
Mentalitas devops nggambarake sinergi antarane pamikiran pembangunan (dev) lan operasi (ops). Sembarang perusahaan sing ngaku "nindakake devops" kudu:
- ngomong apa sing mbokmenawa ora (ngarujuk marang The Princess Bride meme - "Aku ora mikir tegese apa sing sampeyan pikirake!")
- Dorong sikap perbaikan produk sing terus-terusan.
Sampeyan ora bisa nambah produk lan ngerti manawa produk kasebut wis apik yen sampeyan ora ngerti cara kerjane saiki. Sampeyan ora bisa ngerti carane produk bisa digunakake yen sampeyan ora ngerti carane komponen sawijining, layanan gumantung, titik pain utama lan bottlenecks.
Yen sampeyan ora nonton kanggo bottlenecks potensial, sampeyan ora bakal bisa tindakake technique Five Whys nalika nulis Postmortem. Sampeyan ora bakal bisa sijine kabeh ing layar siji kanggo ndeleng carane produk bisa utawa ngerti apa iku katon kaya "normal lan seneng."
Shift ngiwa, ngiwa, aku ngomong LEEEE-
Kanggo kula, salah sawijining prinsip utama Devops yaiku "shift left". Shift ngiwa ing konteks iki tegese ngganti kemungkinan (ora tanggung jawab, nanging mung kapabilitas) kanggo nindakake samubarang sing biasane digatekake dening insinyur sistem, kayata nggawe metrik kinerja, nggunakake log kanthi luwih efisien, lsp., ing sisih kiwa ing Siklus Urip Pangiriman Piranti Lunak.
Pengarang foto ing
Pangembang piranti lunak kudu bisa nggunakake lan ngerti alat ngawasi sing digunakake perusahaan supaya bisa ngawasi kabeh bentuk, metrik, logging, antarmuka ngawasi lan, sing paling penting, nonton carane produk bisa digunakake ing produksi. Sampeyan ora bisa njaluk pangembang kanggo nandur modal gaweyan lan wektu kanggo ngawasi nganti padha bisa ndeleng metrik lan pengaruhe carane katon, carane pemilik produk presents menyang CTO ing briefing sabanjurΓ©, etc.
Suwe-suwe ngomong
- Nuntun jaran menyang banyu. Tampilake pangembang carane akeh alangan sing bisa dihindari kanggo awake dhewe, mbantu dheweke ngenali KPI lan metrik sing tepat kanggo aplikasi kasebut supaya kurang bengok-bengok saka pemilik produk sing dicekel dening CTO. Nggawa menyang cahya, alon-alon lan tenang. Yen ora bisa, banjur nyogok, ngancam, lan mbujuk wong-wong mau utawa pemilik produk supaya bisa ngetrapake metrik kasebut saka aplikasi kanthi cepet, banjur tarik diagram. Iki bakal angel amarga ora bakal dideleng minangka prioritas lan peta dalan produk bakal duwe akeh proyek ngasilake pendapatan sing ditundha. Mula, sampeyan butuh kasus bisnis kanggo mbenerake wektu lan biaya sing ditindakake kanggo ngawasi produk kasebut.
- Tulung insinyur sistem supaya turu kanthi apik. Tampilake manawa nggunakake dhaptar priksa "ayo ngeculake" kanggo produk apa wae sing dirilis iku apik. Lan manawa kabeh aplikasi ing produksi ditutupi metrik bakal mbantu sampeyan turu luwih apik ing wayah wengi kanthi ngidini pangembang ndeleng apa sing salah lan ing endi. Nanging, cara sing bener kanggo ngganggu lan ngganggu pangembang, pemilik produk, utawa CTO yaiku tetep lan nolak. Prilaku iki bakal mengaruhi tanggal rilis produk apa wae yen sampeyan ngenteni nganti menit pungkasan maneh, mula ngalih maneh ngiwa lan entuk masalah kasebut menyang rencana proyek sampeyan sanalika bisa. Yen perlu, pindhah menyang rapat produk. Nganggo mustache palsu lan felt utawa soko, iku ora bakal gagal. Ngomongake keprihatinan sampeyan, tuduhake manfaat sing jelas, lan nginjil.
- Priksa manawa pangembangan (dev) lan operasi (ops) ngerti makna lan akibat saka metrik produk sing pindhah menyang zona abang. Aja ninggalake Ops minangka wali tunggal kesehatan produk, priksa manawa pangembang uga melu (#productsquads).
- Log minangka barang sing apik, nanging uga metrik. Gabungke lan aja nganti log sampeyan dadi sampah ing bal sing ora ana gunane. Nerangake lan nuduhake pangembang kenapa ora ana wong liya sing ngerti log, tuduhake apa sing katon ing log sing ora ana guna ing jam 3:15 esuk.
Pengarang foto ing
Mekaten. Materi anyar bakal dirilis minggu ngarep. Yen sampeyan pengin sinau luwih lengkap babagan kursus kasebut, kita ngajak sampeyan , sing bakal ditindakake ing dina Senin. Lan saiki kita biasane ngenteni komentar sampeyan.
Source: www.habr.com