શા માટે ઇજનેરો એપ્લિકેશન મોનિટરિંગની કાળજી લેતા નથી?

દરેકને શુક્રવારની શુભેચ્છાઓ! મિત્રો, આજે આપણે કોર્સને સમર્પિત પ્રકાશનોની શ્રેણી ચાલુ રાખીએ છીએ "DevOps પ્રેક્ટિસ અને ટૂલ્સ", કારણ કે કોર્સ માટે નવા જૂથમાં વર્ગો આવતા સપ્તાહના અંતમાં શરૂ થશે. તેથી, ચાલો શરૂ કરીએ!

મોનીટરીંગ છે માત્ર. આ જાણીતી હકીકત છે. નાગીઓસને લાવો, રીમોટ સિસ્ટમ પર NRPE ચલાવો, NRPE TCP પોર્ટ 5666 પર Nagios ને ગોઠવો અને તમારી પાસે દેખરેખ છે.

તે એટલું સરળ છે કે તે રસપ્રદ નથી. હવે તમારી પાસે CPU સમય, ડિસ્ક સબસિસ્ટમ, RAM માટે મૂળભૂત મેટ્રિક્સ છે, જે મૂળભૂત રીતે Nagios અને NRPE ને પૂરા પાડવામાં આવે છે. પરંતુ આ ખરેખર "મોનિટરિંગ" નથી. આ તો માત્ર શરૂઆત છે.

(સામાન્ય રીતે તેઓ PNP4Nagios, RRDtool અને Thruk ઇન્સ્ટોલ કરે છે, Slack માં સૂચનાઓ સેટ કરે છે અને સીધા nagiosexchange પર જાય છે, પરંતુ ચાલો તેને હમણાં માટે છોડી દઈએ).

સારી દેખરેખ વાસ્તવમાં ખૂબ જટિલ છે, તમારે ખરેખર જે એપ્લિકેશનનું તમે નિરીક્ષણ કરી રહ્યાં છો તેના આંતરિક ભાગને જાણવાની જરૂર છે.

શું મોનીટરીંગ મુશ્કેલ છે?

કોઈપણ સર્વર, તે લિનક્સ હોય કે વિન્ડોઝ, વ્યાખ્યા દ્વારા અમુક હેતુ પૂરા કરશે. અપાચે, સામ્બા, ટોમકેટ, ફાઇલ સ્ટોરેજ, એલડીએપી - આ બધી સેવાઓ એક અથવા વધુ બાબતોમાં વધુ કે ઓછી અનન્ય છે. દરેકનું પોતાનું કાર્ય છે, તેની પોતાની લાક્ષણિકતાઓ છે. મેટ્રિક્સ, KPIs (મુખ્ય પ્રદર્શન સૂચકાંકો) મેળવવાની વિવિધ રીતો છે, જે સર્વર લોડ હેઠળ હોય ત્યારે તમારા માટે રસપ્રદ છે.

ફોટોના લેખક લ્યુક ચેઝર પર અનસ્પ્લેશ

(હું ઈચ્છું છું કે મારા ડેશબોર્ડ્સ નિયોન વાદળી હોય - સ્વપ્નમાં નિસાસો નાખતા -... હમ્મ...)

કોઈપણ સૉફ્ટવેર કે જે સેવાઓ પ્રદાન કરે છે તેની પાસે મેટ્રિક્સ એકત્રિત કરવાની પદ્ધતિ હોવી આવશ્યક છે. અપાચે પાસે મોડ્યુલ છે mod-status, સર્વર સ્થિતિ પૃષ્ઠ પ્રદર્શિત કરે છે. Nginx પાસે છે - stub_status. ટોમકેટ પાસે JMX અથવા કસ્ટમ વેબ એપ્લિકેશન છે જે કી મેટ્રિક્સ દર્શાવે છે. MySQL પાસે "ગ્લોબલ સ્ટેટસ બતાવો" વગેરે આદેશ છે.
તો શા માટે વિકાસકર્તાઓ તેઓ બનાવેલી એપ્લિકેશન્સમાં સમાન મિકેનિઝમ્સ બનાવતા નથી?

શું ફક્ત વિકાસકર્તાઓ જ આ કરે છે?

મેટ્રિક્સ એમ્બેડિંગ પ્રત્યેની ઉદાસીનતાનું ચોક્કસ સ્તર વિકાસકર્તાઓ સુધી મર્યાદિત નથી. મેં એવી કંપનીઓમાં કામ કર્યું છે જ્યાં તેઓએ ટોમકેટનો ઉપયોગ કરીને એપ્લિકેશન્સ વિકસાવી છે અને સામાન્ય ટોમકેટ ભૂલ લોગ્સ સિવાય તેમના પોતાના મેટ્રિક્સ, સેવા પ્રવૃત્તિના કોઈ લોગ્સ પ્રદાન કર્યા નથી. કેટલાક વિકાસકર્તાઓ ઘણા બધા લૉગ્સ જનરેટ કરે છે જેનો અર્થ સિસ્ટમ એડમિનિસ્ટ્રેટર માટે કંઈ નથી કે જેઓ તેમને સવારે 3:15 વાગ્યે વાંચવા માટે પૂરતા કમનસીબ છે.

ફોટોના લેખક ટિમ ગૌ પર અનસ્પ્લેશ

સિસ્ટમ ઇજનેરો કે જેઓ આવા ઉત્પાદનોને રિલીઝ કરવામાં સક્ષમ કરે છે તેઓએ પરિસ્થિતિ માટે કેટલીક જવાબદારી પણ ઉઠાવવી જોઈએ. થોડા સિસ્ટમ એન્જિનિયરો પાસે તે મેટ્રિક્સના સંદર્ભ અને એપ્લિકેશન પ્રવૃત્તિના પ્રકાશમાં તેનું અર્થઘટન કરવાની ક્ષમતા વિના, લોગમાંથી અર્થપૂર્ણ મેટ્રિક્સ કાઢવાનો પ્રયાસ કરવાનો સમય અથવા કાળજી હોય છે. "કંઈક હાલમાં (અથવા ટૂંક સમયમાં ખોટું થશે)" સૂચકાંકો સિવાય, કેટલાક સમજી શકતા નથી કે તેઓ તેનાથી કેવી રીતે લાભ મેળવી શકે છે.

મેટ્રિક્સની જરૂરિયાત અંગે વિચારસરણીમાં ફેરફાર ફક્ત વિકાસકર્તાઓમાં જ નહીં, પરંતુ સિસ્ટમ એન્જિનિયરોમાં પણ થવો જોઈએ.

કોઈપણ સિસ્ટમ એન્જિનિયર માટે કે જેમણે માત્ર જટિલ ઘટનાઓને જ પ્રતિસાદ આપવાની જરૂર નથી, પરંતુ તે ન થાય તેની પણ ખાતરી કરવાની જરૂર છે, મેટ્રિક્સનો અભાવ સામાન્ય રીતે આમ કરવામાં અવરોધ છે.

જો કે, સિસ્ટમ એન્જિનિયરો સામાન્ય રીતે તેમની કંપની માટે પૈસા કમાવવા માટે કોડ સાથે ટિંકર કરતા નથી. તેઓને એવા મુખ્ય વિકાસકર્તાઓની જરૂર છે જેઓ સમસ્યાઓને ઓળખવામાં, કામગીરીની સમસ્યાઓ વિશે જાગૃતિ વધારવામાં અને તેના જેવી બાબતોમાં સિસ્ટમ એન્જિનિયરની જવાબદારીનું મહત્વ સમજે છે.

આ વસ્તુ devops

ડેવોપ્સ માનસિકતા વિકાસ (દેવ) અને ઓપરેશન્સ (ઓપ્સ) વિચારસરણી વચ્ચેની સમન્વયનું વર્ણન કરે છે. કોઈપણ કંપની કે જે "ડૂ ડેવોપ્સ" કરવાનો દાવો કરે છે તે આવશ્યક છે:

1. એવી વસ્તુઓ કહે છે જે તેઓ કદાચ નથી કરતા (ધ પ્રિન્સેસ બ્રાઇડ મેમનો ઉલ્લેખ કરીને - "મને નથી લાગતું કે તેનો અર્થ તમે શું વિચારો છો!")
2. સતત ઉત્પાદન સુધારણાના વલણને પ્રોત્સાહિત કરો.

તમે ઉત્પાદનને સુધારી શકતા નથી અને જો તમે જાણતા ન હોવ કે તે હાલમાં કેવી રીતે કાર્ય કરે છે તો તેમાં સુધારો કરવામાં આવ્યો છે. તમે જાણી શકતા નથી કે ઉત્પાદન કેવી રીતે કાર્ય કરે છે જો તમે સમજી શકતા નથી કે તેના ઘટકો કેવી રીતે કાર્ય કરે છે, તે કઈ સેવાઓ પર આધાર રાખે છે, તેના મુખ્ય પીડા બિંદુઓ અને અવરોધો.
જો તમે સંભવિત અડચણો પર ધ્યાન આપતા નથી, તો પોસ્ટમોર્ટમ લખતી વખતે તમે ફાઈવ વાયઝ ટેકનિકને અનુસરી શકશો નહીં. તમે ઉત્પાદન કેવી રીતે કાર્ય કરે છે તે જોવા અથવા તે "સામાન્ય અને ખુશ" જેવું દેખાય છે તે જાણવા માટે તમે બધું એક સ્ક્રીન પર મૂકી શકશો નહીં.

ડાબે, ડાબે શિફ્ટ, મેં કહ્યું લીઈ-

મારા માટે, Devops ના મુખ્ય સિદ્ધાંતો પૈકી એક છે “ડાબે શિફ્ટ”. આ સંદર્ભમાં ડાબે શિફ્ટ કરવાનો અર્થ છે શક્યતાને સ્થાનાંતરિત કરવી (કોઈ જવાબદારી નથી, પરંતુ માત્ર ક્ષમતાઓ) એવી વસ્તુઓ કરવા માટે કે જેના વિશે સિસ્ટમ ઇજનેરો સામાન્ય રીતે કાળજી લે છે, જેમ કે પર્ફોર્મન્સ મેટ્રિક્સ બનાવવું, વધુ કાર્યક્ષમ રીતે લોગનો ઉપયોગ કરવો વગેરે, સોફ્ટવેર ડિલિવરી લાઇફ સાયકલમાં ડાબી બાજુએ.

ફોટોના લેખક મેકર્સ દ્વારા નેસા પર અનસ્પ્લેશ

સૉફ્ટવેર ડેવલપર્સ તેના તમામ સ્વરૂપો, મેટ્રિક્સ, લોગિંગ, મોનિટરિંગ ઇન્ટરફેસ અને સૌથી અગત્યનું, જુઓ કે તેમનું ઉત્પાદન ઉત્પાદનમાં કેવી રીતે કાર્ય કરે છે. તમે વિકાસકર્તાઓને જ્યાં સુધી તેઓ મેટ્રિક્સ જોઈ શકતા નથી અને તેઓ કેવા દેખાય છે, પ્રોડક્ટના માલિક તેમને આગામી બ્રીફિંગમાં CTO સમક્ષ કેવી રીતે રજૂ કરે છે, વગેરેને પ્રભાવિત કરી શકતા નથી ત્યાં સુધી મોનિટરિંગમાં પ્રયત્નો અને સમયનું રોકાણ કરવા માટે તમે મેળવી શકતા નથી.

ટૂંક સમયમાં બોલી

1. તમારા ઘોડાને પાણી તરફ દોરી જાઓ. વિકાસકર્તાઓને બતાવો કે તેઓ પોતાના માટે કેટલી મુશ્કેલી ટાળી શકે છે, તેમની અરજીઓ માટે યોગ્ય KPIs અને મેટ્રિક્સ ઓળખવામાં મદદ કરે છે જેથી CTO દ્વારા બૂમો પાડતા ઉત્પાદન માલિકની ચીસો ઓછી થાય. ધીમેધીમે અને શાંતિથી તેમને પ્રકાશમાં લાવો. જો તે કામ ન કરે, તો લાંચ આપો, ધમકી આપો અને તેમને અથવા ઉત્પાદન માલિકને અરજીઓમાંથી આ મેટ્રિક્સ શક્ય તેટલી ઝડપથી મેળવવા માટે અમલમાં મુકો અને પછી આકૃતિઓ દોરો. આ મુશ્કેલ હશે કારણ કે તેને પ્રાથમિકતા તરીકે જોવામાં આવશે નહીં અને પ્રોડક્ટ રોડમેપમાં ઘણા આવક પેદા કરતા પ્રોજેક્ટ્સ બાકી હશે. તેથી, ઉત્પાદનમાં દેખરેખને અમલમાં મૂકવા માટે ખર્ચવામાં આવેલા સમય અને ખર્ચને યોગ્ય ઠેરવવા માટે તમારે વ્યવસાય કેસની જરૂર પડશે.
2. સિસ્ટમ એન્જિનિયરોને સારી ઊંઘ મેળવવામાં મદદ કરો. તેમને બતાવો કે કોઈ પણ પ્રોડક્ટ રિલીઝ થઈ રહી છે તેના માટે "ચાલો રિલીઝ કરો" ચેકલિસ્ટનો ઉપયોગ કરવો એ સારી બાબત છે. અને ખાતરી કરો કે ઉત્પાદનમાંની બધી એપ્લિકેશનો મેટ્રિક્સ સાથે આવરી લેવામાં આવી છે તે વિકાસકર્તાઓને શું અને ક્યાં ખોટું થઈ રહ્યું છે તે જોવાની મંજૂરી આપીને તમને રાત્રે વધુ સારી રીતે ઊંઘવામાં મદદ કરશે. જો કે, કોઈપણ ડેવલપર, પ્રોડક્ટ માલિક અથવા CTO ને ચિડાવવા અને નિરાશ કરવાનો સાચો રસ્તો એ છે કે સતત રહેવું અને પ્રતિકાર કરવો. જો તમે ફરીથી છેલ્લી ઘડી સુધી રાહ જોશો તો આ વર્તણૂક કોઈપણ ઉત્પાદનની પ્રકાશન તારીખને અસર કરશે, તેથી ફરીથી ડાબે શિફ્ટ કરો અને શક્ય તેટલી વહેલી તકે તમારા પ્રોજેક્ટ પ્લાનમાં આ મુદ્દાઓ મેળવો. જો જરૂરી હોય તો, પ્રોડક્ટ મીટિંગમાં જવાનો તમારો રસ્તો બનાવો. નકલી મૂછો પહેરો અને લાગ્યું કે કંઈક, તે ક્યારેય નિષ્ફળ જશે નહીં. તમારી ચિંતાઓ જણાવો, સ્પષ્ટ લાભો દર્શાવો અને પ્રચાર કરો.
3. સુનિશ્ચિત કરો કે ડેવલપમેન્ટ (દેવ) અને ઓપરેશન્સ (ઓપ્સ) બંને રેડ ઝોનમાં જતા પ્રોડક્ટ મેટ્રિક્સના અર્થ અને પરિણામને સમજે છે. ઉત્પાદન સ્વાસ્થ્યના એકમાત્ર વાલી તરીકે Ops ને છોડશો નહીં, ખાતરી કરો કે વિકાસકર્તાઓ પણ સામેલ છે (#productsquads).
4. લોગ્સ એક મહાન વસ્તુ છે, પરંતુ મેટ્રિક્સ પણ છે. તેમને ભેગું કરો અને તમારા લોગને નકામીતાના વિશાળ જ્વલંત બોલમાં કચરાપેટી બનવા દો નહીં. વિકાસકર્તાઓને સમજાવો અને બતાવો કે શા માટે અન્ય કોઈ તેમના લૉગ્સને સમજી શકશે નહીં, તેમને બતાવો કે સવારે 3:15 વાગ્યે નકામા લૉગ્સ જોવાનું શું છે.

ફોટોના લેખક માર્કો હોર્વેટ પર અનસ્પ્લેશ

બસ એટલું જ. નવી સામગ્રી આવતા અઠવાડિયે બહાર પાડવામાં આવશે. જો તમે કોર્સ વિશે વધુ જાણવા માંગતા હો, તો અમે તમને આમંત્રિત કરીએ છીએ ચાલુ દિવસ, જે સોમવારે યોજાશે. અને હવે અમે પરંપરાગત રીતે તમારી ટિપ્પણીઓની રાહ જોઈ રહ્યા છીએ.

સોર્સ: www.habr.com