DevOps મેટ્રિક્સ - ગણતરી માટે ડેટા ક્યાંથી મેળવવો

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

પરંતુ તે મેનેજમેન્ટ માટે પૂરતું ન હતું - તેઓએ સતત વધુ અને વધુ નવા મેટ્રિક્સનો ઓર્ડર આપ્યો, જે અગાઉ કરવામાં આવ્યું હતું તેનો ઉપયોગ કરવાનું ખૂબ જ ઝડપથી બંધ કર્યું.

તાજેતરમાં, દરેક વ્યક્તિ લીડટાઈમ વિશે વાત કરે છે - વ્યવસાય સુવિધાઓની ડિલિવરીનો સમય. મેટ્રિકએ એક ઉન્મત્ત નંબર દર્શાવ્યો - એક કાર્ય પહોંચાડવા માટે 200 દિવસ. બધાએ કેવી રીતે ઓહ અને આહ કરી અને આકાશ તરફ તેમના હાથ ઊંચા કર્યા!

થોડા સમય પછી, અવાજ ધીમે ધીમે ઓછો થયો અને મેનેજમેન્ટને અન્ય મેટ્રિક બનાવવાનો ઓર્ડર મળ્યો.

ઇવાનને તે સંપૂર્ણપણે સ્પષ્ટ હતું કે નવું મેટ્રિક અંધારા ખૂણામાં શાંતિથી મૃત્યુ પામશે.

ખરેખર, ઇવાને વિચાર્યું, નંબર જાણવાથી કોઈને કંઈપણ કહેવાતું નથી. 200 દિવસ અથવા 2 દિવસ - તેમાં કોઈ તફાવત નથી, કારણ કે સંખ્યા દ્વારા કારણ નક્કી કરવું અને તે સારું છે કે ખરાબ છે તે સમજવું અશક્ય છે.

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

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

ઓનલાઈન સ્ટોર માટે, પ્રભાવનો હેતુ તેના ગ્રાહકો હશે જેઓ નાણાં લાવે છે, અને DevOps માટે, તે ટીમો હશે જે પાઇપલાઇનનો ઉપયોગ કરીને વિતરણો બનાવે છે અને રોલઆઉટ કરે છે.

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

DevOps મેટ્રિક્સનો હેતુ

તે સ્પષ્ટ છે કે દરેક વ્યક્તિ ડિલિવરીનો સમય ઘટાડવા માંગે છે. 200 દિવસ, અલબત્ત, કોઈ સારા નથી.

પરંતુ કેવી રીતે, તે પ્રશ્ન છે?

કંપની સેંકડો ટીમોને રોજગારી આપે છે અને દરરોજ હજારો વિતરણો DevOps પાઇપલાઇનમાંથી પસાર થાય છે. વાસ્તવિક વિતરણ સમય વિતરણ તરીકે દેખાશે. દરેક ટીમનો પોતાનો સમય અને તેની પોતાની લાક્ષણિકતાઓ હશે. તમે આ ગડબડ વચ્ચે કંઈપણ કેવી રીતે શોધી શકો છો?

જવાબ સ્વાભાવિક રીતે ઊભો થયો - અમારે સમસ્યાવાળી ટીમો શોધવાની અને તેમની સાથે શું ચાલી રહ્યું છે અને શા માટે આટલો સમય લાગી રહ્યો છે તે શોધવાની જરૂર છે, અને "સારી" ટીમો પાસેથી શીખવું જોઈએ કે બધું ઝડપથી કેવી રીતે કરવું. અને આ કરવા માટે, તમારે દરેક DevOps સ્ટેન્ડ પર ટીમો દ્વારા વિતાવેલા સમયને માપવાની જરૂર છે:

"સિસ્ટમનો ઉદ્દેશ્ય ટીમોને સ્ટેન્ડ પસાર કરવાના સમયના આધારે પસંદ કરવાનો રહેશે, એટલે કે. પરિણામે, અમને પસંદ કરેલ સમય સાથે આદેશોની સૂચિ મેળવવી જોઈએ, સંખ્યા નહીં.

જો આપણે શોધી કાઢીએ કે સ્ટેન્ડ પર કુલ કેટલો સમય વિતાવ્યો હતો અને સ્ટેન્ડ વચ્ચેના ડાઉનટાઇમમાં કેટલો સમય વિતાવ્યો હતો, તો અમે ટીમો શોધી શકીએ છીએ, તેમને કૉલ કરી શકીએ છીએ અને કારણોને વધુ વિગતવાર સમજી શકીએ છીએ અને તેને દૂર કરી શકીએ છીએ," ઇવાનએ વિચાર્યું.

DevOps માટે ડિલિવરી સમયની ગણતરી કેવી રીતે કરવી

તેની ગણતરી કરવા માટે, DevOps પ્રક્રિયા અને તેના સારનો અભ્યાસ કરવો જરૂરી હતું.

કંપની મર્યાદિત સંખ્યામાં સિસ્ટમ્સનો ઉપયોગ કરે છે, અને માહિતી ફક્ત તેમની પાસેથી જ મેળવી શકાય છે અને બીજે ક્યાંય નહીં.

કંપનીના તમામ કાર્યો જીરામાં નોંધાયેલા હતા. જ્યારે કોઈ કાર્ય હાથ ધરવામાં આવ્યું હતું, ત્યારે તેના માટે એક શાખા બનાવવામાં આવી હતી, અને અમલીકરણ પછી, BitBucket અને પુલ વિનંતીને પ્રતિબદ્ધ કરવામાં આવી હતી. જ્યારે PR (પુલ વિનંતી) સ્વીકારવામાં આવી હતી, ત્યારે વિતરણ આપમેળે બનાવવામાં આવ્યું હતું અને નેક્સસ રિપોઝીટરીમાં સંગ્રહિત થઈ ગયું હતું.

આગળ, રોલઆઉટ, સ્વચાલિત અને મેન્યુઅલ પરીક્ષણની શુદ્ધતા ચકાસવા માટે જેનકિન્સનો ઉપયોગ કરીને કેટલાક સ્ટેન્ડ પર વિતરણ કરવામાં આવ્યું હતું:

સ્ટેન્ડ પરના સમયની ગણતરી કરવા માટે કઈ માહિતી કઈ સિસ્ટમમાંથી લઈ શકાય છે તેનું વર્ણન ઈવાને કર્યું:

• નેક્સસમાંથી - વિતરણ બનાવવાનો સમય અને ફોલ્ડરનું નામ જેમાં આદેશ કોડ છે
• જેનકિન્સ તરફથી - દરેક જોબનો પ્રારંભ સમય, અવધિ અને પરિણામ, સ્ટેન્ડનું નામ (જોબ પરિમાણોમાં), સ્ટેજ (નોકરીનાં પગલાં), નેક્સસમાં વિતરણની લિંક.
• ઇવાને જીરા અને બીટબકેટને પાઇપલાઇનમાં સામેલ ન કરવાનું નક્કી કર્યું, કારણ કે... તેઓ ડેવલપમેન્ટ સ્ટેજ સાથે વધુ સંબંધિત હતા, અને સ્ટેન્ડ પર ફિનિશ્ડ ડિસ્ટ્રિબ્યુશન રોલઆઉટ કરવા માટે નહીં.

ઉપલબ્ધ માહિતીના આધારે, નીચેનો આકૃતિ દોરવામાં આવ્યો હતો:

ડિસ્ટ્રિબ્યુશન બનાવવામાં કેટલો સમય લાગે છે અને તેમાંના દરેક પર કેટલો સમય પસાર થાય છે તે જાણીને, તમે સમગ્ર DevOps પાઇપલાઇન (સંપૂર્ણ ચક્ર)માંથી પસાર થવાના કુલ ખર્ચની સરળતાથી ગણતરી કરી શકો છો.

ઇવાન સાથે સમાપ્ત થયેલ DevOps મેટ્રિક્સ અહીં છે:

• બનાવેલ વિતરણોની સંખ્યા
• વિતરણનો હિસ્સો જે સ્ટેન્ડ પર “આવ્યો” અને સ્ટેન્ડ “પાસ” થયો
• સ્ટેન્ડ પર વિતાવેલો સમય (સ્ટેન્ડ સાયકલ)
• પૂર્ણ ચક્ર (તમામ સ્ટેન્ડ માટે કુલ સમય)
• નોકરીની અવધિ
• સ્ટેન્ડ વચ્ચે ડાઉનટાઇમ
• સમાન સ્ટેન્ડ પર જોબ લોન્ચ વચ્ચેનો ડાઉનટાઇમ

એક તરફ, મેટ્રિક્સ સમયની દ્રષ્ટિએ DevOps પાઇપલાઇનને ખૂબ જ સારી રીતે દર્શાવે છે, બીજી તરફ, તે ખૂબ જ સરળ માનવામાં આવતી હતી.

સારી રીતે કરવામાં આવેલ કામથી સંતુષ્ટ, ઇવાન એક પ્રેઝન્ટેશન કર્યું અને મેનેજમેન્ટ સમક્ષ રજૂઆત કરવા ગયો.

તે અંધકારમય અને તેના હાથ નીચે કરીને પાછો આવ્યો.

"આ એક ફિયાસ્કો છે, ભાઈ," માર્મિક સાથીદાર હસ્યો...

લેખમાં વધુ વાંચો “ઇવાનને કેટલા ઝડપી પરિણામોએ મદદ કરી».

સોર્સ: www.habr.com