DevOps മെട്രിക്സ് - കണക്കുകൂട്ടലുകൾക്കായി ഡാറ്റ എവിടെ നിന്ന് ലഭിക്കും

സത്യം പറഞ്ഞാൽ, മോണിറ്ററിംഗ് ഡിപ്പാർട്ട്‌മെന്റിൽ നിന്നുള്ള തന്റെ സഹപ്രവർത്തകരുടെ വൃഥാ പ്രയത്നങ്ങളിൽ ഇവാൻ പലപ്പോഴും ചിരിച്ചു. കമ്പനിയുടെ മാനേജ്‌മെന്റ് അവരോട് നേടിയെടുക്കാൻ ഉത്തരവിട്ട മെട്രിക്‌സ് നടപ്പിലാക്കാൻ അവർ വളരെയധികം പരിശ്രമിച്ചു. മറ്റാരും ഒന്നും ചെയ്യരുതെന്ന് അവർ തിരക്കിലായിരുന്നു.

എന്നാൽ മാനേജുമെന്റിന് ഇത് പര്യാപ്തമായിരുന്നില്ല - അവർ നിരന്തരം കൂടുതൽ കൂടുതൽ പുതിയ അളവുകൾ ഓർഡർ ചെയ്തു, മുമ്പ് ചെയ്തിരുന്നത് വളരെ വേഗത്തിൽ ഉപയോഗിക്കുന്നത് അവസാനിപ്പിച്ചു.

ഈയിടെയായി, എല്ലാവരും LeadTime-നെക്കുറിച്ചാണ് സംസാരിക്കുന്നത് - ബിസിനസ് ഫീച്ചറുകൾ ഡെലിവറി ചെയ്യാനുള്ള സമയം. മെട്രിക് ഒരു ഭ്രാന്തൻ നമ്പർ കാണിച്ചു - ഒരു ടാസ്ക് നൽകാൻ 200 ദിവസം. എല്ലാവരും എങ്ങനെ ആഹ്ലാദിച്ചും ആഹ്ലാദിച്ചും ആകാശത്തേക്ക് കൈകൾ ഉയർത്തി!

കുറച്ച് സമയത്തിന് ശേഷം, ശബ്ദം ക്രമേണ ഇല്ലാതാകുകയും മറ്റൊരു മെട്രിക് സൃഷ്ടിക്കാൻ മാനേജ്‌മെന്റിന് ഒരു ഓർഡർ ലഭിക്കുകയും ചെയ്തു.

പുതിയ മെട്രിക് ഒരു ഇരുണ്ട മൂലയിൽ നിശബ്ദമായി മരിക്കുമെന്ന് ഇവാന് പൂർണ്ണമായും വ്യക്തമായിരുന്നു.

തീർച്ചയായും, ഇവാൻ ചിന്തിച്ചു, നമ്പർ അറിയുന്നത് ആരോടും ഒന്നും പറയുന്നില്ല. 200 ദിവസമോ 2 ദിവസമോ - വ്യത്യാസമില്ല, കാരണം നമ്പർ ഉപയോഗിച്ച് കാരണം നിർണ്ണയിക്കാനും അത് നല്ലതാണോ ചീത്തയാണോ എന്ന് മനസിലാക്കാനും കഴിയില്ല.

ഇത് മെട്രിക്സിന്റെ ഒരു സാധാരണ കെണിയാണ്: ഒരു പുതിയ മെട്രിക് അസ്തിത്വത്തിന്റെ സാരാംശം പറയുകയും ചില രഹസ്യ രഹസ്യം വിശദീകരിക്കുകയും ചെയ്യുമെന്ന് തോന്നുന്നു. എല്ലാവരും ഇതിനായി വളരെയധികം പ്രതീക്ഷിക്കുന്നു, പക്ഷേ ചില കാരണങ്ങളാൽ ഒന്നും സംഭവിക്കുന്നില്ല. അതെ, കാരണം മെട്രിക്സിൽ രഹസ്യം കണ്ടെത്തരുത്!

ഇവാനെ സംബന്ധിച്ചിടത്തോളം ഇത് ഒരു കടന്ന ഘട്ടമായിരുന്നു. അയാൾക്ക് അത് മനസ്സിലായി മെട്രിക്സ് ഒരു സാധാരണ മരം ഭരണാധികാരിയാണ് അളവുകൾക്കായി, എല്ലാ രഹസ്യങ്ങളും അന്വേഷിക്കണം സ്വാധീന വസ്തു, അതായത്. ഈ മെട്രിക് രൂപപ്പെട്ടതാണ്.

ഒരു ഓൺലൈൻ സ്റ്റോറിനെ സംബന്ധിച്ചിടത്തോളം, സ്വാധീനത്തിന്റെ ലക്ഷ്യം പണം കൊണ്ടുവരുന്ന അതിന്റെ ക്ലയന്റുകളായിരിക്കും, കൂടാതെ DevOps-ന് പൈപ്പ്‌ലൈൻ ഉപയോഗിച്ച് വിതരണങ്ങൾ സൃഷ്ടിക്കുകയും പുറത്തിറക്കുകയും ചെയ്യുന്ന ടീമുകളായിരിക്കും.

ഒരു ദിവസം, ഹാളിലെ സുഖപ്രദമായ കസേരയിൽ ഇരുന്നു, സ്വാധീനത്തിന്റെ ലക്ഷ്യം ടീമുകളാണെന്ന വസ്തുത കണക്കിലെടുത്ത്, DevOps മെട്രിക്സ് എങ്ങനെ കാണണമെന്ന് ശ്രദ്ധാപൂർവ്വം ചിന്തിക്കാൻ ഇവാൻ തീരുമാനിച്ചു.

DevOps മെട്രിക്സിന്റെ ഉദ്ദേശ്യം

ഡെലിവറി സമയം കുറയ്ക്കാൻ എല്ലാവരും ആഗ്രഹിക്കുന്നുവെന്ന് വ്യക്തമാണ്. 200 ദിവസം, തീർച്ചയായും, നല്ലതല്ല.

എന്നാൽ എങ്ങനെ, അതാണ് ചോദ്യം?

കമ്പനി നൂറുകണക്കിന് ടീമുകളെ നിയമിക്കുന്നു, ആയിരക്കണക്കിന് വിതരണങ്ങൾ ദിവസവും DevOps പൈപ്പ്ലൈനിലൂടെ പോകുന്നു. യഥാർത്ഥ ഡെലിവറി സമയം ഒരു വിതരണമായി ദൃശ്യമാകും. ഓരോ ടീമിനും അതിന്റേതായ സമയവും അതിന്റേതായ സവിശേഷതകളും ഉണ്ടായിരിക്കും. ഈ കുഴപ്പങ്ങൾക്കിടയിൽ നിങ്ങൾക്ക് എങ്ങനെ എന്തെങ്കിലും കണ്ടെത്താനാകും?

ഉത്തരം സ്വാഭാവികമായി ഉയർന്നു - പ്രശ്നമുള്ള ടീമുകളെ കണ്ടെത്തുകയും അവരുമായി എന്താണ് സംഭവിക്കുന്നതെന്നും എന്തുകൊണ്ടാണ് ഇത് ഇത്രയധികം സമയമെടുക്കുന്നതെന്നും കണ്ടെത്തേണ്ടതുണ്ട്, കൂടാതെ എല്ലാം എങ്ങനെ വേഗത്തിൽ ചെയ്യാമെന്ന് "നല്ല" ടീമുകളിൽ നിന്ന് പഠിക്കുക. ഇത് ചെയ്യുന്നതിന്, ഓരോ DevOps സ്റ്റാൻഡുകളിലും ടീമുകൾ ചെലവഴിച്ച സമയം നിങ്ങൾ അളക്കേണ്ടതുണ്ട്:

“ടീമുകൾ സ്റ്റാൻഡുകൾ കടന്നുപോകുന്ന സമയത്തെ അടിസ്ഥാനമാക്കി തിരഞ്ഞെടുക്കുന്നതായിരിക്കും സിസ്റ്റത്തിന്റെ ലക്ഷ്യം, അതായത്. തൽഫലമായി, തിരഞ്ഞെടുത്ത സമയത്തോടുകൂടിയ കമാൻഡുകളുടെ ഒരു ലിസ്റ്റ് നമുക്ക് ലഭിക്കും, അല്ലാതെ ഒരു സംഖ്യയല്ല.

സ്റ്റാൻഡിൽ ആകെ എത്ര സമയം ചെലവഴിച്ചുവെന്നും സ്റ്റാൻഡുകൾക്കിടയിൽ എത്ര സമയം ചെലവഴിച്ചുവെന്നും കണ്ടെത്തിയാൽ, ഞങ്ങൾക്ക് ടീമുകളെ കണ്ടെത്തി അവരെ വിളിച്ച് കാരണങ്ങൾ കൂടുതൽ വിശദമായി മനസ്സിലാക്കി ഇല്ലാതാക്കാം, ”ഇവാൻ ചിന്തിച്ചു.

DevOps-നുള്ള ഡെലിവറി സമയം എങ്ങനെ കണക്കാക്കാം

ഇത് കണക്കാക്കാൻ, DevOps പ്രക്രിയയും അതിന്റെ സത്തയും പരിശോധിക്കേണ്ടത് ആവശ്യമാണ്.

കമ്പനി പരിമിതമായ എണ്ണം സിസ്റ്റങ്ങൾ ഉപയോഗിക്കുന്നു, അവയിൽ നിന്ന് മാത്രമേ വിവരങ്ങൾ ലഭിക്കൂ, മറ്റെവിടെയുമില്ല.

കമ്പനിയിലെ എല്ലാ ജോലികളും ജിറയിൽ രജിസ്റ്റർ ചെയ്തു. ഒരു ടാസ്‌ക് ഏറ്റെടുക്കുമ്പോൾ, അതിനായി ഒരു ബ്രാഞ്ച് സൃഷ്‌ടിക്കുകയും അത് നടപ്പിലാക്കിയതിന് ശേഷം ബിറ്റ്ബക്കറ്റിനും പുൾ അഭ്യർത്ഥനയ്ക്കും വേണ്ടി പ്രതിജ്ഞാബദ്ധമാക്കുകയും ചെയ്തു. ഒരു പിആർ (പുൾ അഭ്യർത്ഥന) സ്വീകരിച്ചപ്പോൾ, ഒരു വിതരണം സ്വയമേവ സൃഷ്ടിക്കപ്പെടുകയും Nexus ശേഖരത്തിൽ സംഭരിക്കുകയും ചെയ്തു.

അടുത്തതായി, റോൾഔട്ട്, ഓട്ടോമാറ്റിക്, മാനുവൽ ടെസ്റ്റിംഗ് എന്നിവയുടെ കൃത്യത പരിശോധിക്കാൻ ജെങ്കിൻസ് ഉപയോഗിച്ച് നിരവധി സ്റ്റാൻഡുകളിൽ വിതരണം ചെയ്തു:

സ്റ്റാൻഡിലെ സമയം കണക്കാക്കാൻ ഏത് സിസ്റ്റങ്ങളിൽ നിന്ന് എന്ത് വിവരങ്ങൾ എടുക്കാമെന്ന് ഇവാൻ വിവരിച്ചു:

• Nexus-ൽ നിന്ന് - വിതരണ നിർമ്മാണ സമയവും കമാൻഡ് കോഡ് അടങ്ങിയ ഫോൾഡറിന്റെ പേരും
• ജെങ്കിൻസിൽ നിന്ന് - ഓരോ ജോലിയുടെയും ആരംഭ സമയം, കാലാവധി, ഫലം, സ്റ്റാൻഡ് പേര് (ജോലിയുടെ പാരാമീറ്ററുകളിൽ), ഘട്ടങ്ങൾ (ജോലി ഘട്ടങ്ങൾ), Nexus-ലെ വിതരണത്തിലേക്കുള്ള ലിങ്ക്.
• പൈപ്പ് ലൈനിൽ ജിറയെയും ബിറ്റ്ബക്കറ്റിനെയും ഉൾപ്പെടുത്തേണ്ടെന്ന് ഇവാൻ തീരുമാനിച്ചു, കാരണം... അവ കൂടുതൽ വികസന ഘട്ടവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, അല്ലാതെ സ്റ്റാൻഡുകളിൽ പൂർത്തിയായ വിതരണവുമായി ബന്ധപ്പെട്ടിരുന്നില്ല.

ലഭ്യമായ വിവരങ്ങളുടെ അടിസ്ഥാനത്തിൽ, ഇനിപ്പറയുന്ന ഡയഗ്രം വരച്ചു:

വിതരണങ്ങൾ സൃഷ്‌ടിക്കുന്നതിന് എത്ര സമയമെടുക്കുന്നുവെന്നും അവയിൽ ഓരോന്നിനും എത്ര സമയം ചെലവഴിക്കുന്നുവെന്നും അറിയുന്നതിലൂടെ, മുഴുവൻ DevOps പൈപ്പ്‌ലൈനിലൂടെ (മുഴുവൻ ചക്രം) പോകുന്നതിനുള്ള മൊത്തം ചെലവ് നിങ്ങൾക്ക് എളുപ്പത്തിൽ കണക്കാക്കാം.

ഇവാൻ അവസാനിപ്പിച്ച DevOps മെട്രിക്കുകൾ ഇതാ:

• സൃഷ്ടിച്ച വിതരണങ്ങളുടെ എണ്ണം
• സ്റ്റാൻഡിലേക്ക് "വന്നു" സ്റ്റാൻഡ് "പാസാക്കിയ" വിതരണങ്ങളുടെ പങ്ക്
• സ്റ്റാൻഡിൽ ചെലവഴിച്ച സമയം (സ്റ്റാൻഡ് സൈക്കിൾ)
• മുഴുവൻ ചക്രം (എല്ലാ സ്റ്റാൻഡുകൾക്കുമുള്ള ആകെ സമയം)
• ജോലിയുടെ കാലാവധി
• സ്റ്റാൻഡുകൾക്കിടയിലുള്ള പ്രവർത്തനരഹിതമായ സമയം
• ഒരേ സ്റ്റാൻഡിൽ ജോലി ആരംഭിക്കുന്നതിനുള്ള ഇടവേളകൾ

ഒരു വശത്ത്, അളവുകൾ സമയത്തിന്റെ അടിസ്ഥാനത്തിൽ DevOps പൈപ്പ്ലൈനിനെ നന്നായി ചിത്രീകരിച്ചു, മറുവശത്ത്, അവ വളരെ ലളിതമായി കണക്കാക്കപ്പെട്ടു.

നന്നായി ചെയ്ത ജോലിയിൽ സംതൃപ്തനായ ഇവാൻ ഒരു അവതരണം നടത്തി മാനേജ്മെന്റിന് സമർപ്പിക്കാൻ പോയി.

അവൻ മ്ലാനതയോടെ കൈ താഴ്ത്തി തിരിച്ചു വന്നു.

"ഇതൊരു പരാജയമാണ്, സഹോദരാ," വിരോധാഭാസമായ സഹപ്രവർത്തകൻ പുഞ്ചിരിച്ചു ...

ലേഖനത്തിൽ കൂടുതൽ വായിക്കുക "എത്ര പെട്ടെന്നുള്ള ഫലങ്ങൾ ഇവാനെ സഹായിച്ചു".

അവലംബം: www.habr.com