Maligayang Biyernes sa lahat! Mga kaibigan, ngayon ay ipinagpapatuloy namin ang serye ng mga publikasyon na nakatuon sa kurso , dahil ang mga klase sa bagong grupo para sa kurso ay magsisimula sa katapusan ng susunod na linggo. Kaya, magsimula tayo!
Ang pagsubaybay ay lamang. Ito ay isang kilalang katotohanan. Ilabas ang Nagios, patakbuhin ang NRPE sa remote system, i-configure ang Nagios sa NRPE TCP port 5666 at mayroon kang pagsubaybay.
Napakadali nito hindi kawili-wili. Mayroon ka na ngayong mga pangunahing sukatan para sa oras ng CPU, disk subsystem, RAM, na ibinibigay bilang default sa Nagios at NRPE. Ngunit ito ay hindi talaga "pagsubaybay" bilang tulad. Ito ay simula pa lamang.
(Karaniwan ay nag-i-install sila ng PNP4Nagios, RRDtool at Thruk, nagse-set up ng mga notification sa Slack at dumiretso sa nagiosexchange, ngunit hayaan muna natin iyon sa ngayon).
Magandang pagsubaybay ay talagang medyo kumplikado, kailangan mo talagang malaman ang mga panloob ng application na iyong sinusubaybayan.
Mahirap ba ang pagsubaybay?
Anumang server, maging Linux man o Windows, ay magsisilbi sa ilang layunin. Apache, Samba, Tomcat, file storage, LDAP - lahat ng mga serbisyong ito ay higit o hindi gaanong natatangi sa isa o higit pang mga aspeto. Ang bawat isa ay may sariling pag-andar, sariling katangian. Mayroong iba't ibang paraan upang makakuha ng mga sukatan, mga KPI (mga pangunahing tagapagpahiwatig ng pagganap), na kawili-wili sa iyo kapag ang server ay nasa ilalim ng pagkarga.
May-akda ng larawan sa
(Sana ang aking mga dashboard ay neon blue - humihingal na parang panaginip -... hmm...)
Anumang software na nagbibigay ng mga serbisyo ay dapat may mekanismo para mangolekta ng mga sukatan. May module ang Apache mod-status, ipinapakita ang pahina ng status ng server. Ang Nginx ay may - stub_status. Ang Tomcat ay may JMX o custom na web application na nagpapakita ng mga pangunahing sukatan. Ang MySQL ay may command na "ipakita ang pandaigdigang katayuan" atbp.
Kaya bakit hindi bumuo ang mga developer ng mga katulad na mekanismo sa mga application na kanilang nilikha?
Mga developer lang ba ang gumagawa nito?
Ang isang tiyak na antas ng kawalang-interes sa pag-embed ng mga sukatan ay hindi limitado sa mga developer. Nagtatrabaho ako sa mga kumpanya kung saan nakabuo sila ng mga application gamit ang Tomcat at hindi nagbigay ng alinman sa kanilang sariling mga sukatan, walang mga log ng aktibidad ng serbisyo, maliban sa mga pangkalahatang log ng error ng Tomcat. Ang ilang mga developer ay bumubuo ng maraming mga log na walang kahulugan sa system administrator na hindi pinalad na basahin ang mga ito sa 3:15 ng umaga.
May-akda ng larawan sa
Ang mga inhinyero ng system na nagbibigay-daan sa pagpapalabas ng mga naturang produkto ay dapat ding magkaroon ng ilang responsibilidad para sa sitwasyon. Ilang system engineer ang may oras o pangangalaga na subukang kunin ang mga makabuluhang sukatan mula sa mga log, nang walang konteksto ng mga sukatan na iyon at ang kakayahang bigyang-kahulugan ang mga ito ayon sa aktibidad ng aplikasyon. Ang ilan ay hindi nauunawaan kung paano sila makikinabang dito, maliban sa "may isang bagay sa kasalukuyan (o malapit nang maging) mali" na mga tagapagpahiwatig.
Ang pagbabago sa pag-iisip tungkol sa pangangailangan para sa mga sukatan ay dapat mangyari hindi lamang sa mga developer, kundi pati na rin sa mga system engineer.
Para sa sinumang system engineer na kailangang hindi lamang tumugon sa mga kritikal na kaganapan, ngunit tiyaking hindi ito mangyayari, ang kakulangan ng mga sukatan ay karaniwang hadlang sa paggawa nito.
Gayunpaman, ang mga system engineer ay karaniwang hindi gumagamit ng code upang kumita ng pera para sa kanilang kumpanya. Kailangan nila ng mga nangungunang developer na nauunawaan ang kahalagahan ng responsibilidad ng system engineer sa pagtukoy ng mga problema, pagpapataas ng kamalayan sa mga isyu sa pagganap, at mga katulad nito.
Ito devops bagay
Inilalarawan ng devops mentality ang synergy sa pagitan ng development (dev) at operations (ops) na pag-iisip. Anumang kumpanya na nagsasabing "gumawa ng devops" ay dapat:
- sinasabi ang mga bagay na malamang na hindi nila (referring to The Princess Bride meme - "I don't think it means what you think it means!")
- Hikayatin ang isang saloobin ng patuloy na pagpapabuti ng produkto.
Hindi mo mapapahusay ang isang produkto at alam mong napabuti ito kung hindi mo alam kung paano ito gumagana sa kasalukuyan. Hindi mo malalaman kung paano gumagana ang isang produkto kung hindi mo naiintindihan kung paano gumagana ang mga bahagi nito, ang mga serbisyo kung saan ito nakasalalay, ang mga pangunahing punto ng sakit at mga bottleneck nito.
Kung hindi ka manood ng mga potensyal na bottleneck, hindi mo magagawang sundin ang Five Whys technique kapag nagsusulat ng Postmortem. Hindi mo magagawang ilagay ang lahat sa isang screen upang makita kung paano gumagana ang isang produkto o malaman kung ano ang hitsura nito "normal at masaya."
Shift left, LEFT, SABI KO LEEEEβ
Para sa akin, ang isa sa mga pangunahing prinsipyo ng Devops ay "shift left". Ang paglipat sa kaliwa sa kontekstong ito ay nangangahulugan ng paglilipat ng posibilidad (walang pananagutan, ngunit mga kakayahan lamang) na gawin ang mga bagay na karaniwang pinapahalagahan ng mga system engineer, tulad ng paggawa ng mga sukatan ng pagganap, paggamit ng mga log nang mas mahusay, atbp., sa kaliwa sa Siklo ng Buhay ng Paghahatid ng Software.
May-akda ng larawan sa
Ang mga developer ng software ay dapat na magamit at malaman ang mga tool sa pagsubaybay na ginagamit ng kumpanya upang maisakatuparan ang pagsubaybay sa lahat ng mga anyo nito, sukatan, pag-log, mga interface ng pagsubaybay at, pinaka-mahalaga, panoorin kung paano gumagana ang kanilang produkto sa produksyon. Hindi mo maaakit ang mga developer na maglaan ng pagsisikap at oras sa pagsubaybay hanggang sa makita nila ang mga sukatan at maimpluwensyahan ang hitsura nila, kung paano ipapakita ng may-ari ng produkto ang mga ito sa CTO sa susunod na briefing, atbp.
Sa madaling sabi
- Akayin ang iyong kabayo sa tubig. Ipakita sa mga developer kung gaano karaming problema ang maaari nilang iwasan para sa kanilang sarili, tulungan silang tukuyin ang mga tamang KPI at sukatan para sa kanilang mga aplikasyon upang mabawasan ang sigawan mula sa may-ari ng produkto na sinisigawan ng CTO. Dalhin sila sa liwanag, malumanay at mahinahon. Kung hindi iyon gumana, suhol, banta, at akitin sila o ang may-ari ng produkto na ipatupad ang pagkuha ng mga sukatan na ito mula sa mga application sa lalong madaling panahon, at pagkatapos ay iguhit ang mga diagram. Magiging mahirap ito dahil hindi ito makikita bilang isang priyoridad at ang roadmap ng produkto ay magkakaroon ng maraming mga proyektong kikitain ang nakabinbin. Samakatuwid, kakailanganin mo ng isang kaso ng negosyo upang bigyang-katwiran ang oras at gastos na ginugol sa pagpapatupad ng pagsubaybay sa produkto.
- Tulungan ang mga system engineer na makatulog ng mahimbing. Ipakita sa kanila na ang paggamit ng checklist na "ilabas natin" para sa anumang produktong ilalabas ay isang magandang bagay. At ang pagtiyak na ang lahat ng application sa produksyon ay sakop ng mga sukatan ay makakatulong sa iyong makatulog nang mas mahusay sa gabi sa pamamagitan ng pagpapahintulot sa mga developer na makita kung ano ang nangyayaring mali at kung saan. Gayunpaman, ang tamang paraan para mairita at mabigo ang sinumang developer, may-ari ng produkto, o CTO ay ang magpumilit at lumaban. Ang gawi na ito ay makakaapekto sa petsa ng paglabas ng anumang produkto kung maghihintay ka muli hanggang sa huling minuto, kaya lumipat muli sa kaliwa at ilagay ang mga isyung ito sa iyong plano ng proyekto sa lalong madaling panahon. Kung kinakailangan, pumunta sa mga pulong ng produkto. Magsuot ng pekeng bigote at felt or something, hinding-hindi ito mabibigo. Ipahayag ang iyong mga alalahanin, ipakita ang malinaw na mga benepisyo, at mag-ebanghelyo.
- Tiyakin na parehong nauunawaan ng development (dev) at operations (ops) ang kahulugan at resulta ng mga sukatan ng produkto na lumilipat sa red zone. Huwag iwanan ang Ops bilang nag-iisang tagapag-alaga ng kalusugan ng produkto, tiyaking kasangkot din ang mga developer (#productsquads).
- Ang mga log ay isang magandang bagay, ngunit gayon din ang mga sukatan. Pagsamahin ang mga ito at huwag hayaang maging basura ang iyong mga tala sa isang malaking naglalagablab na bola ng kawalang-silbi. Ipaliwanag at ipakita sa mga developer kung bakit walang ibang makakaintindi sa kanilang mga log, ipakita sa kanila kung ano ang pakiramdam na tumingin sa mga walang kwentang log sa 3:15 ng umaga.
May-akda ng larawan sa
Iyon lang. Ang bagong materyal ay ilalabas sa susunod na linggo. Kung gusto mong matuto nang higit pa tungkol sa kurso, inaanyayahan ka naming , na magaganap sa Lunes. At ngayon kami ay tradisyonal na naghihintay para sa iyong mga komento.
Pinagmulan: www.habr.com