Naha insinyur henteu paduli ngeunaan ngawaskeun aplikasi?

Wilujeng Jumaah sadayana! Babaturan, ayeuna urang neraskeun séri publikasi anu dikhususkeun pikeun kursus "Praktik sareng alat DevOps", sabab kelas di grup anyar pikeun kursus bakal dimimitian dina ahir minggu hareup. Janten, hayu urang mimitian!

Ngawaskeun téh adil. Ieu fakta dipikawanoh. Bawa Nagios, ngajalankeun NRPE dina sistem jauh, ngonpigurasikeun Nagios on NRPE TCP port 5666 jeung anjeun geus ngawaskeun.

Ieu jadi gampang teu metot. Ayeuna anjeun gaduh métrik dasar pikeun waktos CPU, subsistem disk, RAM, disayogikeun sacara standar ka Nagios sareng NRPE. Tapi ieu sanés "ngawaskeun" sapertos kitu. Ieu ngan mimiti.

(Biasana aranjeunna masang PNP4Nagios, RRDtool sareng Thruk, nyetél béwara di Slack sareng langsung ka nagiosexchange, tapi hayu urang tinggalkeun ayeuna).

Ngawaskeun alus saleresna rada rumit, anjeun leres-leres kedah terang kana internal aplikasi anu anjeun pantau.

Naha ngawaskeun sesah?

Sakur server, naha Linux atanapi Windows, ku harti bakal nyayogikeun sababaraha tujuan. Apache, Samba, Tomcat, panyimpen file, LDAP - sadaya jasa ieu langkung atanapi kirang unik dina hiji atanapi langkung hal. Unggal boga fungsi sorangan, ciri sorangan. Aya sababaraha cara pikeun kéngingkeun métrik, KPI (indikator kinerja konci), anu pikaresepeun pikeun anjeun nalika pangladén dina beban.

Pangarang poto Lukas Caturer dina Unsplash

(Mugi dashboard abdi neon biru - ngahuleng ngalamun -... hmm ...)

Sakur parangkat lunak anu nyayogikeun jasa kedah gaduh mékanisme pikeun ngumpulkeun métrik. Apache ngagaduhan modul mod-status, mintonkeun kaca status server. Nginx boga - stub_status. Tomcat gaduh JMX atanapi aplikasi wéb khusus anu nunjukkeun métrik konci. MySQL ngagaduhan paréntah "tunjukkeun status global" jsb.
Janten naha pamekar henteu ngawangun mékanisme anu sami kana aplikasi anu aranjeunna ciptakeun?

Naha ukur pamekar anu ngalakukeun ieu?

A tingkat nu tangtu indifference mun metrics embedding henteu dugi ka pamekar. Kuring digawé di pausahaan mana maranéhna dimekarkeun aplikasi maké Tomcat na teu nyadiakeun salah sahiji metrics sorangan, euweuh log aktivitas jasa, iwal log kasalahan Tomcat umum. Sababaraha pamekar ngahasilkeun loba log nu hartina nanaon ka administrator sistem anu cukup sial maca aranjeunna dina 3:15 isuk-isuk.

Pangarang poto Tim Gouw dina Unsplash

Insinyur sistem anu ngamungkinkeun produk sapertos dileupaskeun ogé kedah nanggung tanggung jawab pikeun kaayaan éta. Sababaraha insinyur sistem gaduh waktos atanapi paduli pikeun nyobian ékstrak métrik anu bermakna tina log, tanpa kontéks métrik éta sareng kamampuan pikeun napsirkeunana dina kagiatan aplikasi. Sababaraha henteu ngartos kumaha aranjeunna tiasa nyandak kauntungan tina éta, lian ti "aya anu ayeuna (atanapi bakal enggal janten) salah" indikator.

Parobihan dina pamikiran ngeunaan kabutuhan métrik kedah lumangsung henteu ngan ukur di kalangan pamekar, tapi ogé di kalangan insinyur sistem.

Pikeun naon waé insinyur sistem anu kedah henteu ngan ukur ngabales kajadian kritis, tapi ogé mastikeun yén éta henteu kajantenan, kurangna métrik biasana janten halangan pikeun ngalakukeunana.

Sanajan kitu, insinyur sistem ilaharna teu tinker kalawan kode pikeun nyieun duit keur parusahaan maranéhanana. Éta peryogi pangembang utama anu ngartos pentingna tanggung jawab insinyur sistem dina ngaidentipikasi masalah, ningkatkeun kasadaran masalah kinerja, sareng anu sanésna.

Ieu devops hal

Méntalitas devops ngajelaskeun sinergi antara pamikiran pangwangunan (dev) sareng operasi (ops). Sakur perusahaan anu ngaku "ngalakukeun devops" kedah:

1. nyebutkeun hal maranéhna meureun henteu (ngarujuk kana The Putri panganten awewe meme - "Kuring teu nyangka eta hartina naon pikir eta hartina!")
2. Ajak sikep perbaikan produk kontinyu.

Anjeun moal tiasa ningkatkeun produk sareng terang yén éta parantos ningkat upami anjeun henteu terang kumaha ayeuna jalanna. Anjeun teu tiasa terang kumaha produkna tiasa dianggo upami anjeun henteu ngartos kumaha komponén-komponénna, jasa anu gumantungna, titik nyeri sareng bottlenecks utama na.
Upami anjeun henteu ningali poténsi bottlenecks, anjeun moal tiasa nuturkeun téknik Lima Whys nalika nyerat Postmortem. Anjeun moal tiasa nempatkeun sadayana dina hiji layar pikeun ningali kumaha produkna tiasa dianggo atanapi terang kumaha sigana "normal sareng bagja."

Geser ka kénca, Kénca, ceuk kuring LEEEE—

Pikeun kuring, salah sahiji prinsip konci Devops nyaéta "shift left". Shift kénca dina konteks ieu hartina mindahkeun kamungkinan (euweuh tanggung jawab, tapi ngan ukur kamampuan) pikeun ngalakukeun hal-hal anu biasana diperhatikeun ku insinyur sistem, sapertos nyiptakeun métrik kinerja, ngagunakeun log langkung éfisién, jsb., ka kénca dina Siklus Kahirupan Pangiriman Perangkat Lunak.

Pangarang poto NESA ku Makers dina Unsplash

Pamekar parangkat lunak kedah tiasa ngagunakeun sareng terang alat ngawaskeun anu dianggo ku perusahaan pikeun ngalaksanakeun monitoring dina sagala bentuk, métrik, logging, ngawaskeun antarmuka sareng, anu paling penting, lalajo kumaha produk maranéhanana jalan dina produksi. Anjeun moal tiasa kéngingkeun pamekar pikeun investasi usaha sareng waktos dina ngawaskeun dugi aranjeunna tiasa ningali métrik sareng pangaruh kumaha aranjeunna katingali, kumaha pamilik produk nampilkeun aranjeunna ka CTO dina pengarahan salajengna, jsb.

Pondokna

1. Anjog kuda anjeun ka cai. Témbongkeun pamekar sabaraha gangguan maranéhna bisa nyingkahan keur diri, mantuan aranjeunna ngaidentipikasi KPIs katuhu jeung metrics pikeun aplikasi maranéhanana ku kituna aya kirang yelling ti nu boga produk anu keur yelled di ku CTO. Bawa aranjeunna kana caang, gently tur tenang. Upami éta henteu hasil, teras nyogok, ngancem, sareng ngadorong boh aranjeunna atanapi anu gaduh produk pikeun nerapkeun métrik ieu tina aplikasi gancang-gancang, teras tarik diagram. Ieu bakal sesah sabab moal katingali salaku prioritas sareng peta jalan produk bakal ngagaduhan seueur proyék ngahasilkeun pendapatan anu ditangguhkeun. Ku alatan éta, anjeun bakal kudu kasus bisnis keur menerkeun waktu jeung expense spent ngalaksanakeun monitoring kana produk.
2. Pitulung insinyur sistem meunang sare wengi alus urang. Tunjukkeun aranjeunna yén ngagunakeun daptar pariksa "hayu urang ngaleupaskeun" pikeun produk anu dileupaskeun mangrupikeun hal anu saé. Sareng mastikeun yén sadaya aplikasi dina produksi ditutupan ku métrik bakal ngabantosan anjeun bobo langkung saé wengi ku ngamungkinkeun para pamekar ningali naon anu salah sareng dimana. Nanging, cara anu leres pikeun ngaganggu sareng ngagagalkeun pamekar, pamilik produk, atanapi CTO nyaéta tetep sareng nolak. Paripolah ieu bakal mangaruhan tanggal sékrési produk naon waé upami anjeun ngantosan dugi ka menit terakhir deui, janten pindah ka kénca deui sareng kéngingkeun masalah ieu kana rencana proyék anjeun pas mungkin. Upami diperyogikeun, angkat ka rapat produk. Ngagem kumis palsu jeung ngarasa atawa hal, éta moal gagal. Nyaritakeun kasalempang Sadérék, témbongkeun mangpaat anu jelas, jeung nginjil.
3. Mastikeun yén duanana ngembangkeun (dev) jeung operasi (ops) ngartos harti jeung konsekuensi metrics produk pindah kana zone beureum. Ulah ninggalkeun Ops salaku hiji-hijina wali kaséhatan produk, pastikeun pamekar ogé kalibet (#productsquads).
4. Log mangrupikeun hal anu saé, tapi ogé métrik. Gabungkeun aranjeunna sareng ulah ngantep log anjeun janten sampah dina bal anu teu aya gunana. Ngajelaskeun tur némbongkeun pamekar naha teu saurang ogé bakal ngarti log maranéhanana, némbongkeun aranjeunna naon éta kasampak dina log gunana di 3:15 isuk-isuk.

Pangarang poto Marko Horvat dina Unsplash

Éta hungkul. Bahan anyar bakal dileupaskeun minggu payun. Upami anjeun hoyong diajar langkung seueur ngeunaan kursus, kami ngajak anjeun Buka Poé, nu bakal lumangsung dina Senén. Sareng ayeuna urang sacara tradisional ngantosan koméntar anjeun.

sumber: www.habr.com