റഷ്യയിലെ DevOps സ്റ്റേറ്റ് 2020

എന്തിന്റെയെങ്കിലും അവസ്ഥ എങ്ങനെ മനസ്സിലാക്കാം?

വിവിധ വിവര സ്രോതസ്സുകളിൽ നിന്ന് രൂപീകരിച്ച നിങ്ങളുടെ അഭിപ്രായത്തെ നിങ്ങൾക്ക് ആശ്രയിക്കാം, ഉദാഹരണത്തിന്, വെബ്സൈറ്റുകളിലെ പ്രസിദ്ധീകരണങ്ങൾ അല്ലെങ്കിൽ അനുഭവം. നിങ്ങൾക്ക് സഹപ്രവർത്തകരോടും പരിചയക്കാരോടും ചോദിക്കാം. കോൺഫറൻസുകളുടെ വിഷയങ്ങൾ നോക്കുക എന്നതാണ് മറ്റൊരു ഓപ്ഷൻ: പ്രോഗ്രാം കമ്മിറ്റി വ്യവസായത്തിന്റെ സജീവ പ്രതിനിധികളാണ്, അതിനാൽ പ്രസക്തമായ വിഷയങ്ങൾ തിരഞ്ഞെടുക്കുന്നതിൽ ഞങ്ങൾ അവരെ വിശ്വസിക്കുന്നു. ഒരു പ്രത്യേക മേഖല ഗവേഷണവും റിപ്പോർട്ടുകളും ആണ്. പക്ഷേ ഒരു പ്രശ്നമുണ്ട്. DevOps-ന്റെ അവസ്ഥയെക്കുറിച്ചുള്ള ഗവേഷണം ലോകത്ത് വർഷം തോറും നടത്തപ്പെടുന്നു, റിപ്പോർട്ടുകൾ വിദേശ കമ്പനികൾ പ്രസിദ്ധീകരിക്കുന്നു, കൂടാതെ റഷ്യൻ DevOps-നെക്കുറിച്ച് മിക്കവാറും വിവരങ്ങളൊന്നുമില്ല.

എന്നാൽ അത്തരമൊരു പഠനം നടത്തിയ ദിവസം വന്നിരിക്കുന്നു, ഇന്ന് നമ്മൾ ഫലങ്ങളെക്കുറിച്ച് സംസാരിക്കും. റഷ്യയിലെ DevOps-ന്റെ അവസ്ഥ കമ്പനികൾ സംയുക്തമായി പഠിച്ചു "എക്സ്പ്രസ് 42"കൂടാതെ"ഒന്റിക്കോ". DevOps പ്രാക്ടീസുകളും ടൂളുകളും നടപ്പിലാക്കാനും വികസിപ്പിക്കാനും ടെക്നോളജി കമ്പനികളെ എക്സ്പ്രസ് 42 സഹായിക്കുന്നു, റഷ്യയിൽ DevOps-നെ കുറിച്ച് ആദ്യമായി സംസാരിച്ചവരിൽ ഒരാളായിരുന്നു ഇത്. പഠനത്തിന്റെ രചയിതാക്കളായ ഇഗോർ കുറോച്ച്കിൻ, വിറ്റാലി ഖബറോവ് എന്നിവർ എക്സ്പ്രസ് 42-ൽ വിശകലനത്തിലും കൺസൾട്ടിംഗിലും ഏർപ്പെട്ടിട്ടുണ്ട്, അതേസമയം വിവിധ കമ്പനികളിലെ പ്രവർത്തനത്തിൽ നിന്നും അനുഭവത്തിൽ നിന്നുമുള്ള സാങ്കേതിക പശ്ചാത്തലമുണ്ട്. 8 വർഷമായി, സഹപ്രവർത്തകർ ഡസൻ കണക്കിന് കമ്പനികളും പ്രോജക്‌റ്റുകളും - സ്റ്റാർട്ടപ്പുകൾ മുതൽ സംരംഭങ്ങൾ വരെ - വ്യത്യസ്ത പ്രശ്‌നങ്ങളും അതുപോലെ വ്യത്യസ്ത സാംസ്‌കാരിക, എഞ്ചിനീയറിംഗ് പക്വതകളും പരിശോധിച്ചു.

അവരുടെ റിപ്പോർട്ടിൽ, ഇഗോറും വിറ്റാലിയും ഗവേഷണ പ്രക്രിയയിൽ എന്ത് പ്രശ്‌നങ്ങളുണ്ടായിരുന്നു, അവ എങ്ങനെ പരിഹരിച്ചു, അതുപോലെ തന്നെ DevOps ഗവേഷണം തത്വത്തിൽ എങ്ങനെ നടക്കുന്നുവെന്നും എന്തുകൊണ്ടാണ് Express 42 സ്വന്തമായി നടത്താൻ തീരുമാനിച്ചതെന്നും പറഞ്ഞു. അവരുടെ റിപ്പോർട്ട് കാണാം ഇവിടെ.

DevOps റിസർച്ച്

സംഭാഷണം ആരംഭിച്ചത് ഇഗോർ കുറോച്ച്കിൻ ആണ്.

DevOps കോൺഫറൻസുകളിലെ പ്രേക്ഷകരോട് ഞങ്ങൾ പതിവായി ചോദിക്കുന്നു, "നിങ്ങൾ ഈ വർഷത്തെ DevOps സ്റ്റാറ്റസ് റിപ്പോർട്ട് വായിച്ചിട്ടുണ്ടോ?" കുറച്ച് പേർ കൈകൾ ഉയർത്തുന്നു, ഞങ്ങളുടെ പഠനം കാണിക്കുന്നത് മൂന്നാമതൊരാൾ മാത്രമേ അവരെ പഠിക്കുന്നുള്ളൂ. നിങ്ങൾ ഒരിക്കലും അത്തരം റിപ്പോർട്ടുകൾ കണ്ടിട്ടില്ലെങ്കിൽ, അവയെല്ലാം വളരെ സാമ്യമുള്ളതാണെന്ന് ഉടൻ തന്നെ പറയാം. മിക്കപ്പോഴും ഇതുപോലുള്ള വാക്യങ്ങളുണ്ട്: "കഴിഞ്ഞ വർഷത്തെ അപേക്ഷിച്ച് ..."

ഇവിടെ ഞങ്ങൾക്ക് ഞങ്ങളുടെ ആദ്യത്തെ പ്രശ്‌നമുണ്ട്, തുടർന്ന് രണ്ടെണ്ണം കൂടി:

1. കഴിഞ്ഞ വർഷത്തെ ഡാറ്റ ഞങ്ങളുടെ പക്കലില്ല. റഷ്യയിലെ DevOps-ന്റെ അവസ്ഥ ആർക്കും താൽപ്പര്യമില്ല;
2. രീതിശാസ്ത്രം. അനുമാനങ്ങൾ എങ്ങനെ പരീക്ഷിക്കണം, എങ്ങനെ ചോദ്യങ്ങൾ നിർമ്മിക്കാം, എങ്ങനെ വിശകലനം ചെയ്യാം, ഫലങ്ങൾ താരതമ്യം ചെയ്യാം, കണക്ഷനുകൾ കണ്ടെത്തുന്നത് എങ്ങനെയെന്ന് വ്യക്തമല്ല;
3. ടെർമിനോളജി. എല്ലാ റിപ്പോർട്ടുകളും ഇംഗ്ലീഷിലാണ്, വിവർത്തനം ആവശ്യമാണ്, ഒരു പൊതു DevOps ചട്ടക്കൂട് ഇതുവരെ കണ്ടുപിടിച്ചിട്ടില്ല, എല്ലാവരും അവരുടേതായ രീതിയിൽ വരുന്നു.

ലോകമെമ്പാടുമുള്ള DevOps സംസ്ഥാന വിശകലനങ്ങൾ എങ്ങനെയാണ് നടന്നതെന്ന് നമുക്ക് നോക്കാം.

ചരിത്ര പശ്ചാത്തലം

DevOps ഗവേഷണം 2011 മുതൽ നടത്തി. കോൺഫിഗറേഷൻ മാനേജ്‌മെന്റ് സിസ്റ്റങ്ങളുടെ ഡെവലപ്പറായ പപ്പറ്റ് ആയിരുന്നു അവ ആദ്യമായി നടത്തിയത്. അക്കാലത്ത്, അടിസ്ഥാന സൗകര്യങ്ങളെ കോഡിന്റെ രൂപത്തിൽ വിവരിക്കുന്നതിനുള്ള പ്രധാന ഉപകരണങ്ങളിലൊന്നായിരുന്നു ഇത്. 2013 വരെ, ഈ പഠനങ്ങൾ ഒരു അടഞ്ഞ ഫോർമാറ്റിലും പൊതു റിപ്പോർട്ടിംഗ് ഇല്ലാതെയും നടത്തിയ സർവേകളായിരുന്നു.

2013-ൽ, DevOps-ലെ എല്ലാ പ്രധാന പുസ്തകങ്ങളുടെയും പ്രസാധകനായ ഐടി വിപ്ലവം പ്രത്യക്ഷപ്പെട്ടു. പപ്പറ്റിനൊപ്പം, അവർ ആദ്യത്തെ സ്റ്റേറ്റ് ഓഫ് DevOps പ്രസിദ്ധീകരണം തയ്യാറാക്കി, അവിടെ 4 പ്രധാന മെട്രിക്കുകൾ ആദ്യമായി പ്രത്യക്ഷപ്പെട്ടു. അടുത്ത വർഷം, വ്യവസായ സമ്പ്രദായങ്ങളിലും ടൂളുകളിലും പതിവ് സാങ്കേതിക റഡാറുകൾക്ക് പേരുകേട്ട കൺസൾട്ടിംഗ് സ്ഥാപനമായ ThoughtWorks ഉൾപ്പെട്ടു. 2015-ൽ, മെത്തഡോളജി ഉള്ള ഒരു വിഭാഗം ചേർത്തു, അവർ എങ്ങനെയാണ് വിശകലനം നടത്തുന്നത് എന്ന് വ്യക്തമായി.

2016-ൽ, പഠനത്തിന്റെ രചയിതാക്കൾ, അവരുടെ സ്വന്തം കമ്പനിയായ DORA (DevOps റിസർച്ച് ആൻഡ് അസസ്മെന്റ്) സൃഷ്ടിച്ച് ഒരു വാർഷിക റിപ്പോർട്ട് പ്രസിദ്ധീകരിച്ചു. അടുത്ത വർഷം, ഡോറയും പപ്പറ്റും അവരുടെ അവസാന സംയുക്ത റിപ്പോർട്ട് പുറത്തിറക്കി.

തുടർന്ന് രസകരമായ എന്തെങ്കിലും ആരംഭിച്ചു:

2018-ൽ, കമ്പനികൾ വിഭജിക്കുകയും രണ്ട് സ്വതന്ത്ര റിപ്പോർട്ടുകൾ പുറത്തുവിടുകയും ചെയ്തു: ഒന്ന് പപ്പറ്റിൽ നിന്ന്, രണ്ടാമത്തേത് ഡോറയിൽ നിന്ന് ഗൂഗിളിനൊപ്പം. പ്രധാന അളവുകോലുകളെയും കമ്പനിയുടെ മൊത്തത്തിലുള്ള പ്രകടനത്തെയും ബാധിക്കുന്ന പ്രധാന അളവുകൾ, പ്രകടന പ്രൊഫൈലുകൾ, എഞ്ചിനീയറിംഗ് രീതികൾ എന്നിവ ഉപയോഗിച്ച് DORA അതിന്റെ രീതിശാസ്ത്രത്തെ തുടർന്നും പ്രയോജനപ്പെടുത്തുന്നു. DevOps-ന്റെ പ്രക്രിയയുടെയും പരിണാമത്തിന്റെയും വിവരണത്തോടെ പപ്പറ്റ് അതിന്റേതായ സമീപനം വാഗ്ദാനം ചെയ്തു. എന്നാൽ കഥ വേരൂന്നിയില്ല, 2019-ൽ പപ്പറ്റ് ഈ രീതി ഉപേക്ഷിച്ച് റിപ്പോർട്ടുകളുടെ ഒരു പുതിയ പതിപ്പ് പുറത്തിറക്കി, അതിൽ പ്രധാന സമ്പ്രദായങ്ങളും അവ DevOps-നെ അവരുടെ കാഴ്ചപ്പാടിൽ എങ്ങനെ ബാധിക്കുന്നുവെന്നും പട്ടികപ്പെടുത്തി. തുടർന്ന് മറ്റൊരു സംഭവം നടന്നു: ഗൂഗിൾ ഡോറയെ വാങ്ങി, അവർ ഒരുമിച്ച് മറ്റൊരു റിപ്പോർട്ട് പുറത്തിറക്കി. നിങ്ങൾ അവനെ കണ്ടിട്ടുണ്ടാകും.

ഈ വർഷം, കാര്യങ്ങൾ സങ്കീർണ്ണമായി. പപ്പറ്റ് സ്വന്തം സർവേ ആരംഭിച്ചതായി അറിയപ്പെടുന്നു. ഞങ്ങളേക്കാൾ ഒരാഴ്ച മുമ്പ് അവർ അത് ചെയ്തു, അത് ഇതിനകം അവസാനിച്ചു. ഞങ്ങൾ അതിൽ പങ്കെടുക്കുകയും അവർക്ക് താൽപ്പര്യമുള്ള വിഷയങ്ങൾ നോക്കുകയും ചെയ്തു. ഇപ്പോൾ പപ്പറ്റ് അതിന്റെ വിശകലനം നടത്തി റിപ്പോർട്ട് പ്രസിദ്ധീകരിക്കാനുള്ള ഒരുക്കത്തിലാണ്.

എന്നാൽ ഡോറയിൽ നിന്നും ഗൂഗിളിൽ നിന്നും ഇതുവരെ ഒരു അറിയിപ്പും ഉണ്ടായിട്ടില്ല. മെയ് മാസത്തിൽ, സർവേ ആരംഭിക്കുമ്പോൾ, ഡോറയുടെ സ്ഥാപകരിലൊരാളായ നിക്കോൾ ഫോർസ്‌ഗ്രെൻ മറ്റൊരു കമ്പനിയിലേക്ക് മാറിയതായി വിവരം ലഭിച്ചു. അതിനാൽ, ഈ വർഷം ഡോറയിൽ നിന്ന് ഗവേഷണമോ റിപ്പോർട്ടോ ഉണ്ടാകില്ലെന്ന് ഞങ്ങൾ അനുമാനിച്ചു.

റഷ്യയിലെ കാര്യങ്ങൾ എങ്ങനെയാണ്?

ഞങ്ങൾ DevOps ഗവേഷണം നടത്തിയിട്ടില്ല. ഞങ്ങൾ കോൺഫറൻസുകളിൽ സംസാരിച്ചു, മറ്റുള്ളവരുടെ കണ്ടെത്തലുകൾ വീണ്ടും പറയുന്നു, 2019-ലേക്കുള്ള "DevOps സ്റ്റേറ്റ്" Raiffeisenbank വിവർത്തനം ചെയ്തു (Habre-ൽ അവരുടെ പ്രഖ്യാപനം നിങ്ങൾക്ക് കാണാം), അവർക്ക് നന്ദി. പിന്നെ എല്ലാം.

അതിനാൽ, DORA രീതികളും കണ്ടെത്തലുകളും ഉപയോഗിച്ച് ഞങ്ങൾ റഷ്യയിൽ ഞങ്ങളുടെ സ്വന്തം ഗവേഷണം നടത്തി. ടെർമിനോളജിയുടെയും വിവർത്തനത്തിന്റെയും സമന്വയം ഉൾപ്പെടെ, ഞങ്ങളുടെ ഗവേഷണത്തിനായി ഞങ്ങൾ Raiffeisenbank-ൽ നിന്നുള്ള സഹപ്രവർത്തകരുടെ റിപ്പോർട്ട് ഉപയോഗിച്ചു. വ്യവസായവുമായി ബന്ധപ്പെട്ട ചോദ്യങ്ങൾ DORA റിപ്പോർട്ടുകളിൽ നിന്നും ഈ വർഷത്തെ പപ്പറ്റ് ചോദ്യാവലിയിൽ നിന്നും എടുത്തതാണ്.

ഗവേഷണ പ്രക്രിയ

റിപ്പോർട്ട് അന്തിമഭാഗം മാത്രമാണ്. മുഴുവൻ ഗവേഷണ പ്രക്രിയയും നാല് പ്രധാന ഘട്ടങ്ങൾ ഉൾക്കൊള്ളുന്നു:

തയ്യാറെടുപ്പ് ഘട്ടത്തിൽ, ഞങ്ങൾ വ്യവസായ വിദഗ്ധരെ അഭിമുഖം ചെയ്യുകയും അനുമാനങ്ങളുടെ ഒരു ലിസ്റ്റ് തയ്യാറാക്കുകയും ചെയ്തു. അവയുടെ അടിസ്ഥാനത്തിൽ, ചോദ്യങ്ങൾ സമാഹരിക്കുകയും ഓഗസ്റ്റ് മുഴുവൻ ഒരു സർവേ ആരംഭിക്കുകയും ചെയ്തു. പിന്നെ ഞങ്ങൾ റിപ്പോർട്ട് തന്നെ വിശകലനം ചെയ്തു തയ്യാറാക്കി. ഡോറയെ സംബന്ധിച്ചിടത്തോളം, ഈ പ്രക്രിയയ്ക്ക് 6 മാസമെടുക്കും. ഞങ്ങൾ 3 മാസത്തിനുള്ളിൽ കണ്ടുമുട്ടി, ഞങ്ങൾക്ക് വേണ്ടത്ര സമയമില്ലെന്ന് ഇപ്പോൾ ഞങ്ങൾ മനസ്സിലാക്കുന്നു: വിശകലനം നടത്തുന്നതിലൂടെ മാത്രമേ നിങ്ങൾ എന്ത് ചോദ്യങ്ങൾ ചോദിക്കണമെന്ന് നിങ്ങൾക്ക് മനസ്സിലാകൂ.

പങ്കെടുക്കുന്നവർ

എല്ലാ വിദേശ റിപ്പോർട്ടുകളും പങ്കെടുക്കുന്നവരുടെ ഛായാചിത്രത്തോടെ ആരംഭിക്കുന്നു, അവരിൽ ഭൂരിഭാഗവും റഷ്യയിൽ നിന്നുള്ളവരല്ല. റഷ്യൻ പ്രതികരിക്കുന്നവരുടെ ശതമാനം വർഷം തോറും 5 മുതൽ 1% വരെ ചാഞ്ചാടുന്നു, ഇത് ഒരു നിഗമനത്തിലും എത്തിച്ചേരാൻ അനുവദിക്കുന്നില്ല.

Accelerate State of DevOps 2019 റിപ്പോർട്ടിൽ നിന്നുള്ള മാപ്പ്:

ഞങ്ങളുടെ പഠനത്തിൽ, 889 ആളുകളെ അഭിമുഖം നടത്താൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു - ഇത് വളരെ കൂടുതലാണ് (DORA അതിന്റെ റിപ്പോർട്ടുകളിൽ പ്രതിവർഷം ആയിരത്തോളം ആളുകളുമായി വോട്ടെടുപ്പ് നടത്തുന്നു) ഇവിടെ ഞങ്ങൾ ലക്ഷ്യം കൈവരിച്ചു:

ശരിയാണ്, ഞങ്ങളുടെ എല്ലാ പങ്കാളികളും അവസാനത്തിലെത്തിയില്ല: പൂർത്തീകരണത്തിന്റെ ശതമാനം പകുതിയിൽ കുറവാണ്. എന്നാൽ ഇത് പോലും ഒരു പ്രതിനിധി സാമ്പിൾ നേടാനും വിശകലനം നടത്താനും മതിയായിരുന്നു. DORA അതിന്റെ റിപ്പോർട്ടുകളിൽ ഫിൽ ശതമാനം വെളിപ്പെടുത്തുന്നില്ല, അതിനാൽ ഇവിടെ താരതമ്യമില്ല.

വ്യവസായങ്ങളും സ്ഥാനങ്ങളും

ഞങ്ങളുടെ പ്രതികരിച്ചവർ ഒരു ഡസൻ വ്യവസായങ്ങളെ പ്രതിനിധീകരിക്കുന്നു. വിവര സാങ്കേതിക വിദ്യയിൽ പാതി ജോലി. സാമ്പത്തിക സേവനങ്ങൾ, വ്യാപാരം, ടെലികമ്മ്യൂണിക്കേഷൻ എന്നിവയും മറ്റും ഇത് പിന്തുടരുന്നു. സ്ഥാനങ്ങളിൽ സ്പെഷ്യലിസ്റ്റുകളും (ഡെവലപ്പർ, ടെസ്റ്റർ, ഓപ്പറേഷൻ എഞ്ചിനീയർ) മാനേജ്മെന്റ് സ്റ്റാഫും (ടീമുകളുടെ തലവന്മാർ, ഗ്രൂപ്പുകൾ, ഏരിയകൾ, ഡയറക്ടർമാർ):

രണ്ടിൽ ഒരാൾ ഇടത്തരം കമ്പനിയിൽ ജോലി ചെയ്യുന്നു. ഓരോ മൂന്നാമത്തെ വ്യക്തിയും വലിയ കമ്പനികളിൽ ജോലി ചെയ്യുന്നു. 9 പേർ വരെയുള്ള ടീമുകളിലാണ് മിക്കവരും പ്രവർത്തിക്കുന്നത്. വെവ്വേറെ, ഞങ്ങൾ പ്രധാന പ്രവർത്തനങ്ങളെക്കുറിച്ച് ചോദിച്ചു, ഭൂരിഭാഗവും ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ പ്രവർത്തനവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, ഏകദേശം 40% വികസനത്തിൽ ഏർപ്പെട്ടിരിക്കുന്നു:

അതിനാൽ വിവിധ വ്യവസായങ്ങൾ, കമ്പനികൾ, ടീമുകൾ എന്നിവയുടെ പ്രതിനിധികളുടെ താരതമ്യത്തിനും വിശകലനത്തിനുമായി ഞങ്ങൾ വിവരങ്ങൾ ശേഖരിച്ചു. എന്റെ സഹപ്രവർത്തകൻ വിറ്റാലി ഖബറോവ് വിശകലനത്തെക്കുറിച്ച് പറയും.

വിശകലനവും താരതമ്യവും

വിറ്റാലി ഖബറോവ്: ഞങ്ങളുടെ സർവേ പൂർത്തിയാക്കിയ, ചോദ്യാവലി പൂരിപ്പിച്ച്, ഞങ്ങളുടെ അനുമാനങ്ങൾ കൂടുതൽ വിശകലനം ചെയ്യുന്നതിനും പരിശോധിക്കുന്നതിനുമായി ഞങ്ങൾക്ക് ഡാറ്റ നൽകുകയും ചെയ്ത എല്ലാ പങ്കാളികൾക്കും നന്ദി. ഞങ്ങളുടെ ക്ലയന്റുകൾക്കും ഉപഭോക്താക്കൾക്കും നന്ദി, വ്യവസായ ആശങ്കകൾ തിരിച്ചറിയുന്നതിനും ഞങ്ങളുടെ ഗവേഷണത്തിൽ ഞങ്ങൾ പരീക്ഷിച്ച അനുമാനങ്ങൾ രൂപപ്പെടുത്തുന്നതിനും സഹായിച്ച അനുഭവ സമ്പത്ത് ഞങ്ങൾക്ക് ഉണ്ട്.

നിർഭാഗ്യവശാൽ, നിങ്ങൾക്ക് ഒരു വശത്ത് ചോദ്യങ്ങളുടെ ഒരു പട്ടികയും മറുവശത്ത് ഡാറ്റയും എടുക്കാൻ കഴിയില്ല, എങ്ങനെയെങ്കിലും അവ താരതമ്യം ചെയ്യുക, പറയുക: "അതെ, എല്ലാം അങ്ങനെ പ്രവർത്തിക്കുന്നു, ഞങ്ങൾ ശരിയായിരുന്നു" കൂടാതെ പിരിഞ്ഞുപോകുക. ഇല്ല, ഞങ്ങൾ തെറ്റിദ്ധരിക്കപ്പെട്ടിട്ടില്ലെന്നും ഞങ്ങളുടെ നിഗമനങ്ങൾ വിശ്വസനീയമാണെന്നും ഉറപ്പാക്കാൻ ഞങ്ങൾക്ക് മെത്തഡോളജിയും സ്റ്റാറ്റിസ്റ്റിക്കൽ രീതികളും ആവശ്യമാണ്. ഈ ഡാറ്റയെ അടിസ്ഥാനമാക്കി ഞങ്ങൾക്ക് ഞങ്ങളുടെ തുടർന്നുള്ള ജോലികൾ നിർമ്മിക്കാൻ കഴിയും:

പ്രധാന അളവുകൾ

ഞങ്ങൾ DORA മെത്തഡോളജി ഒരു അടിസ്ഥാനമായി എടുത്തു, അത് അവർ "Accelerate State of DevOps" എന്ന പുസ്തകത്തിൽ വിശദമായി വിവരിച്ചിട്ടുണ്ട്. പ്രധാന അളവുകൾ റഷ്യൻ വിപണിക്ക് അനുയോജ്യമാണോ, “റഷ്യയിലെ വ്യവസായം വിദേശ വ്യവസായവുമായി എങ്ങനെ പൊരുത്തപ്പെടുന്നു?” എന്ന ചോദ്യത്തിന് ഉത്തരം നൽകാൻ DORA ഉപയോഗിക്കുന്നതുപോലെ തന്നെ അവ ഉപയോഗിക്കാമോ എന്ന് ഞങ്ങൾ പരിശോധിച്ചു.

പ്രധാന അളവുകൾ:

1. വിന്യാസ ആവൃത്തി. ആപ്ലിക്കേഷന്റെ ഒരു പുതിയ പതിപ്പ് പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിലേക്ക് എത്ര തവണ വിന്യസിച്ചിട്ടുണ്ട് (ആസൂത്രിത മാറ്റങ്ങൾ, ഹോട്ട്ഫിക്സുകളും സംഭവ പ്രതികരണങ്ങളും ഒഴികെ)?
2. ഡെലിവറി സമയം. ഒരു മാറ്റം വരുത്തുന്നതിനും (കോഡായി പ്രവർത്തനക്ഷമത എഴുതുന്നതിനും) ഉൽപ്പാദന പരിതസ്ഥിതിയിൽ മാറ്റം വിന്യസിക്കുന്നതിനും ഇടയിലുള്ള ശരാശരി സമയം എത്രയാണ്?
3. വീണ്ടെടുക്കൽ സമയം. ആപ്ലിക്കേഷൻ ഉപയോക്താക്കളെ ബാധിക്കുന്ന ഒരു സംഭവം, സേവന നിലവാരത്തകർച്ച അല്ലെങ്കിൽ ഒരു ബഗ് കണ്ടെത്തൽ എന്നിവയ്ക്ക് ശേഷം ഒരു പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിലേക്ക് ഒരു ആപ്ലിക്കേഷൻ പുനഃസ്ഥാപിക്കാൻ ശരാശരി എത്ര സമയമെടുക്കും?
4. പരാജയപ്പെട്ട മാറ്റങ്ങൾ. ഉൽപ്പാദന പരിതസ്ഥിതിയിലെ വിന്യാസങ്ങളുടെ എത്ര ശതമാനം ആപ്ലിക്കേഷൻ ഡീഗ്രേഡേഷനിലേക്കോ സംഭവങ്ങളിലേക്കോ നയിക്കുന്നു, കൂടാതെ പരിഹാരങ്ങൾ ആവശ്യമാണ് (മാറ്റങ്ങളുടെ റോൾബാക്ക്, ഒരു ഹോട്ട്ഫിക്സ് അല്ലെങ്കിൽ പാച്ചിന്റെ വികസനം)?

DORA അതിന്റെ ഗവേഷണത്തിൽ ഈ അളവുകോലുകളും സംഘടനാ പ്രകടനവും തമ്മിൽ ഒരു ബന്ധം കണ്ടെത്തി. ഞങ്ങളുടെ പഠനത്തിലും ഞങ്ങൾ ഇത് പരീക്ഷിക്കുന്നു.

എന്നാൽ നാല് പ്രധാന അളവുകൾക്ക് എന്തെങ്കിലും സ്വാധീനിക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കാൻ, നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട് - അവ എങ്ങനെയെങ്കിലും പരസ്പരം ബന്ധപ്പെട്ടിട്ടുണ്ടോ? DORA ഒരു മുന്നറിയിപ്പ് നൽകി: വിജയിക്കാത്ത മാറ്റങ്ങളും (പരാജയ നിരക്ക് മാറ്റുക) മറ്റ് മൂന്ന് മെട്രിക്കുകളും തമ്മിലുള്ള ബന്ധം അൽപ്പം ദുർബലമാണ്. അതേ ചിത്രത്തെക്കുറിച്ച് ഞങ്ങൾക്ക് ലഭിച്ചു. ഡെലിവറി സമയം, വിന്യാസ ആവൃത്തി, വീണ്ടെടുക്കൽ സമയം എന്നിവ പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നുവെങ്കിൽ (പിയേഴ്സൺ കോറിലേഷനിലൂടെയും ചാഡോക്ക് സ്കെയിലിലൂടെയും ഞങ്ങൾ ഈ പരസ്പരബന്ധം സ്ഥാപിച്ചു), വിജയിക്കാത്ത മാറ്റങ്ങളുമായി അത്തരം ശക്തമായ പരസ്പര ബന്ധമില്ല.

തത്വത്തിൽ, പ്രതികരിക്കുന്നവരിൽ ഭൂരിഭാഗവും ഉൽപ്പാദനത്തിൽ വളരെ ചെറിയ സംഭവങ്ങളുണ്ടെന്ന് ഉത്തരം നൽകുന്നു. പരാജയപ്പെട്ട മാറ്റങ്ങളുടെ കാര്യത്തിൽ പ്രതികരിക്കുന്നവരുടെ ഗ്രൂപ്പുകൾക്കിടയിൽ ഇപ്പോഴും കാര്യമായ വ്യത്യാസമുണ്ടെന്ന് ഞങ്ങൾ പിന്നീട് കാണുമെങ്കിലും, ഈ വിഭജനത്തിനായി ഞങ്ങൾക്ക് ഇതുവരെ ഈ മെട്രിക് ഉപയോഗിക്കാൻ കഴിയില്ല.

(ഞങ്ങളുടെ ചില ഉപഭോക്താക്കളുമായുള്ള വിശകലനത്തിന്റെയും ആശയവിനിമയത്തിന്റെയും പ്രക്രിയയിൽ ഇത് മാറിയതുപോലെ) ഒരു സംഭവമായി കണക്കാക്കുന്നതിനെക്കുറിച്ചുള്ള ധാരണയിൽ നേരിയ വ്യത്യാസമുണ്ടെന്ന വസ്തുതയാണ് ഞങ്ങൾ ഇതിന് ആട്രിബ്യൂട്ട് ചെയ്യുന്നത്. സാങ്കേതിക വിൻഡോയിൽ ഞങ്ങളുടെ സേവനത്തിന്റെ പ്രവർത്തനം പുനഃസ്ഥാപിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞെങ്കിൽ, ഇതൊരു സംഭവമായി കണക്കാക്കാമോ? ഒരുപക്ഷേ ഇല്ല, കാരണം ഞങ്ങൾ എല്ലാം ശരിയാക്കി, ഞങ്ങൾ മികച്ചവരാണ്. സാധാരണ, പരിചിതമായ മോഡിൽ ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ 10 തവണ റീ-റോൾ ചെയ്യേണ്ടി വന്നാൽ അത് ഒരു സംഭവമായി കണക്കാക്കാമോ? ഇല്ലെന്നു തോന്നുന്നു. അതിനാൽ, വിജയിക്കാത്ത മാറ്റങ്ങളും മറ്റ് അളവുകളും തമ്മിലുള്ള ബന്ധത്തെക്കുറിച്ചുള്ള ചോദ്യം തുറന്നിരിക്കുന്നു. ഞങ്ങൾ അത് കൂടുതൽ വ്യക്തമാക്കും.

ഡെലിവറി സമയം, വീണ്ടെടുക്കൽ സമയം, വിന്യാസ ആവൃത്തി എന്നിവ തമ്മിൽ ഒരു പ്രധാന ബന്ധം ഞങ്ങൾ കണ്ടെത്തി എന്നതാണ് ഇവിടെ പ്രധാനം. അതിനാൽ, പ്രതികരിക്കുന്നവരെ പ്രകടന ഗ്രൂപ്പുകളായി വിഭജിക്കാൻ ഞങ്ങൾ ഈ മൂന്ന് അളവുകൾ എടുത്തു.

ഗ്രാമിന് എത്രമാത്രം തൂക്കിക്കൊടുക്കും?

ഞങ്ങൾ ശ്രേണിപരമായ ക്ലസ്റ്റർ വിശകലനം ഉപയോഗിച്ചു:

• ഞങ്ങൾ പ്രതികരിക്കുന്നവരെ ഒരു എൻ-ഡൈമൻഷണൽ സ്‌പെയ്‌സിൽ വിതരണം ചെയ്യുന്നു, അവിടെ ഓരോ പ്രതികരിക്കുന്നയാളുടെയും കോർഡിനേറ്റ് ചോദ്യങ്ങൾക്കുള്ള അവരുടെ ഉത്തരങ്ങളാണ്.
• ഓരോ പ്രതിയും ഒരു ചെറിയ ക്ലസ്റ്ററായി പ്രഖ്യാപിക്കപ്പെടുന്നു.
• ഞങ്ങൾ പരസ്പരം അടുത്തുള്ള രണ്ട് ക്ലസ്റ്ററുകളെ ഒരു വലിയ ക്ലസ്റ്ററിലേക്ക് കൂട്ടിച്ചേർക്കുന്നു.
• ഞങ്ങൾ അടുത്ത ജോഡി ക്ലസ്റ്ററുകൾ കണ്ടെത്തി അവയെ ഒരു വലിയ ക്ലസ്റ്ററിലേക്ക് കൂട്ടിച്ചേർക്കുന്നു.

ഇങ്ങനെയാണ് ഞങ്ങൾ പ്രതികരിക്കുന്നവരെയെല്ലാം നമുക്ക് ആവശ്യമുള്ള ക്ലസ്റ്ററുകളുടെ എണ്ണത്തിലേക്ക് തരംതിരിക്കുന്നത്. ഒരു ഡെൻഡ്രോഗ്രാമിന്റെ (ക്ലസ്റ്ററുകൾ തമ്മിലുള്ള ബന്ധങ്ങളുടെ ഒരു വൃക്ഷം) സഹായത്തോടെ, രണ്ട് അയൽ ക്ലസ്റ്ററുകൾ തമ്മിലുള്ള ദൂരം ഞങ്ങൾ കാണുന്നു. ഈ ക്ലസ്റ്ററുകൾക്കിടയിൽ ഒരു നിശ്ചിത ദൂരപരിധി നിശ്ചയിച്ച് പറയുക മാത്രമാണ് ഞങ്ങൾക്ക് അവശേഷിക്കുന്നത്: "ഈ രണ്ട് ഗ്രൂപ്പുകളും പരസ്പരം വേർതിരിച്ചറിയാൻ കഴിയും, കാരണം അവ തമ്മിലുള്ള ദൂരം ഭീമാകാരമാണ്."

എന്നാൽ ഇവിടെ ഒരു മറഞ്ഞിരിക്കുന്ന പ്രശ്നമുണ്ട്: ക്ലസ്റ്ററുകളുടെ എണ്ണത്തിൽ ഞങ്ങൾക്ക് നിയന്ത്രണങ്ങളൊന്നുമില്ല - നമുക്ക് 2, 3, 4, 10 ക്ലസ്റ്ററുകൾ ലഭിക്കും. ആദ്യത്തെ ആശയം ഇതായിരുന്നു - DORA ചെയ്യുന്നതുപോലെ എന്തുകൊണ്ട് ഞങ്ങളുടെ എല്ലാ പ്രതികരണക്കാരെയും 4 ഗ്രൂപ്പുകളായി വിഭജിച്ചുകൂടാ. എന്നാൽ ഈ ഗ്രൂപ്പുകൾ തമ്മിലുള്ള വ്യത്യാസങ്ങൾ നിസ്സാരമാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി, പ്രതികരിക്കുന്നയാൾ യഥാർത്ഥത്തിൽ അവന്റെ ഗ്രൂപ്പിൽ പെട്ടയാളാണെന്ന് ഞങ്ങൾക്ക് ഉറപ്പുനൽകാൻ കഴിയില്ല, അല്ലാതെ അയൽക്കാരനല്ല. റഷ്യൻ വിപണിയെ നാല് ഗ്രൂപ്പുകളായി വിഭജിക്കാൻ ഞങ്ങൾക്ക് ഇതുവരെ കഴിയില്ല. അതിനാൽ, ഞങ്ങൾ മൂന്ന് പ്രൊഫൈലുകളിൽ സ്ഥിരതാമസമാക്കി, അവയ്ക്കിടയിൽ സ്ഥിതിവിവരക്കണക്ക് കാര്യമായ വ്യത്യാസമുണ്ട്:

അടുത്തതായി, ഞങ്ങൾ ക്ലസ്റ്ററുകൾ പ്രകാരം പ്രൊഫൈൽ നിർണ്ണയിച്ചു: ഓരോ ഗ്രൂപ്പിനും ഓരോ മെട്രിക്കിനും ഞങ്ങൾ മീഡിയൻ എടുത്ത് പ്രകടന പ്രൊഫൈലുകളുടെ ഒരു പട്ടിക സമാഹരിച്ചു. വാസ്തവത്തിൽ, ഓരോ ഗ്രൂപ്പിലെയും ശരാശരി പങ്കാളിയുടെ പ്രകടന പ്രൊഫൈലുകൾ ഞങ്ങൾക്ക് ലഭിച്ചു. ഞങ്ങൾ മൂന്ന് കാര്യക്ഷമത പ്രൊഫൈലുകൾ തിരിച്ചറിഞ്ഞു: താഴ്ന്ന, ഇടത്തരം, ഉയർന്നത്:

പ്രകടന പ്രൊഫൈൽ നിർണ്ണയിക്കുന്നതിന് 4 പ്രധാന അളവുകൾ അനുയോജ്യമാണെന്ന ഞങ്ങളുടെ അനുമാനം ഞങ്ങൾ ഇവിടെ സ്ഥിരീകരിച്ചു, അവ പാശ്ചാത്യ, റഷ്യൻ വിപണികളിൽ പ്രവർത്തിക്കുന്നു. ഗ്രൂപ്പുകൾ തമ്മിൽ വ്യത്യാസമുണ്ട്, അത് സ്ഥിതിവിവരക്കണക്ക് പ്രാധാന്യമുള്ളതാണ്. ഈ പരാമീറ്റർ ഉപയോഗിച്ച് ഞങ്ങൾ ആദ്യം പ്രതികരിച്ചവരെ വിഭജിച്ചില്ലെങ്കിലും ശരാശരിയുടെ അടിസ്ഥാനത്തിൽ പരാജയപ്പെട്ട മാറ്റങ്ങളുടെ മെട്രിക് കണക്കിലെടുത്ത് പ്രകടന പ്രൊഫൈലുകൾ തമ്മിൽ കാര്യമായ വ്യത്യാസമുണ്ടെന്ന് ഞാൻ ഊന്നിപ്പറയുന്നു.

അപ്പോൾ ചോദ്യം ഉയർന്നുവരുന്നു: ഇതെല്ലാം എങ്ങനെ ഉപയോഗിക്കാം?

എങ്ങനെ ഉപയോഗിക്കാം

ഞങ്ങൾ ഏതെങ്കിലും ടീമിനെ എടുത്ത്, 4 പ്രധാന മെട്രിക്കുകൾ എടുത്ത് ടേബിളിൽ പ്രയോഗിച്ചാൽ, 85% കേസുകളിലും ഞങ്ങൾക്ക് ഒരു സമ്പൂർണ്ണ പൊരുത്തം ലഭിക്കില്ല - ഇത് ഒരു ശരാശരി പങ്കാളിയാണ്, അല്ലാതെ യഥാർത്ഥത്തിൽ ഉള്ളതല്ല. ഞങ്ങൾ എല്ലാവരും (ഓരോ ടീമും) അല്പം വ്യത്യസ്തരാണ്.

ഞങ്ങൾ പരിശോധിച്ചു: ഞങ്ങൾ പ്രതികരിച്ചവരേയും DORA പ്രകടന പ്രൊഫൈലും എടുത്ത്, ഒന്നോ അല്ലെങ്കിൽ മറ്റൊരു പ്രൊഫൈലുമായി എത്ര പേർ പ്രതികരിച്ചുവെന്ന് പരിശോധിച്ചു. പ്രതികരിച്ചവരിൽ 16% മാത്രമാണ് പ്രൊഫൈലുകളിൽ ഒന്നിൽ കൃത്യമായി വീണതെന്ന് ഞങ്ങൾ കണ്ടെത്തി. ബാക്കിയുള്ളവയെല്ലാം ഇടയിൽ എവിടെയോ ചിതറിക്കിടക്കുന്നു:

പ്രകടന പ്രൊഫൈലിന് പരിമിതമായ വ്യാപ്തിയുണ്ടെന്നാണ് ഇതിനർത്ഥം. ആദ്യ ഏകദേശ കണക്കിൽ നിങ്ങൾ എവിടെയാണെന്ന് മനസിലാക്കാൻ, നിങ്ങൾക്ക് ഈ പട്ടിക ഉപയോഗിക്കാം: "ഓ, ഞങ്ങൾ മീഡിയം അല്ലെങ്കിൽ ഹൈ ആയി അടുത്തതായി തോന്നുന്നു!" നിങ്ങൾ അടുത്തതായി എവിടേക്കാണ് പോകുന്നതെന്ന് നിങ്ങൾക്ക് മനസ്സിലായാൽ, അത് മതിയാകും. എന്നാൽ നിങ്ങളുടെ ലക്ഷ്യം സ്ഥിരവും തുടർച്ചയായ പുരോഗതിയും ആണെങ്കിൽ, എവിടെയാണ് വികസിപ്പിക്കേണ്ടതെന്നും എന്തുചെയ്യണമെന്നും കൂടുതൽ കൃത്യമായി അറിയാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, അധിക ഫണ്ടുകൾ ആവശ്യമാണ്. ഞങ്ങൾ അവരെ കാൽക്കുലേറ്ററുകൾ എന്ന് വിളിച്ചു:

• ഡോറ കാൽക്കുലേറ്റർ
• കാൽക്കുലേറ്റർ എക്സ്പ്രസ് 42* (വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്നു)
• സ്വന്തം വികസനം (നിങ്ങൾക്ക് നിങ്ങളുടെ സ്വന്തം ആന്തരിക കാൽക്കുലേറ്റർ സൃഷ്ടിക്കാൻ കഴിയും).

അവ എന്തിനുവേണ്ടിയാണ് വേണ്ടത്? മനസ്സിലാക്കുക:

• ഞങ്ങളുടെ സ്ഥാപനത്തിലെ ടീം ഞങ്ങളുടെ മാനദണ്ഡങ്ങൾ പാലിക്കുന്നുണ്ടോ?
• ഇല്ലെങ്കിൽ, ഞങ്ങൾക്ക് അവളെ സഹായിക്കാനാകുമോ - ഞങ്ങളുടെ കമ്പനിക്കുള്ള വൈദഗ്ധ്യത്തിന്റെ ചട്ടക്കൂടിനുള്ളിൽ അത് വേഗത്തിലാക്കാൻ?
• അങ്ങനെയെങ്കിൽ, നമുക്ക് ഇതിലും നന്നായി ചെയ്യാൻ കഴിയുമോ?

കമ്പനിക്കുള്ളിലെ സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കാനും നിങ്ങൾക്ക് അവ ഉപയോഗിക്കാം:

• ഞങ്ങൾക്ക് എന്ത് ടീമുകളുണ്ട്?
• ടീമുകളെ പ്രൊഫൈലുകളായി വിഭജിക്കുക;
• കാണുക: ഓ, ഈ കമാൻഡുകൾ മോശമായി പ്രവർത്തിക്കുന്നു (അവ അൽപ്പം പുറത്തെടുക്കുന്നില്ല), എന്നാൽ ഇവ രസകരമാണ്: അവ എല്ലാ ദിവസവും വിന്യസിക്കുന്നു, പിശകുകളില്ലാതെ, അവർക്ക് ഒരു മണിക്കൂറിൽ താഴെ സമയമുണ്ട്.

ഞങ്ങളുടെ കമ്പനിയിൽ ഇതുവരെ തുല്യത കൈവരിക്കാത്ത ടീമുകൾക്ക് ആവശ്യമായ വൈദഗ്ധ്യവും ഉപകരണങ്ങളും ഉണ്ടെന്ന് നിങ്ങൾക്ക് കണ്ടെത്താനാകും.

അല്ലെങ്കിൽ, കമ്പനിക്കുള്ളിൽ നിങ്ങൾക്ക് മികച്ചതായി തോന്നുന്നുവെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നുവെങ്കിൽ, നിങ്ങൾ പലരെക്കാളും മികച്ചയാളാണ്, അപ്പോൾ നിങ്ങൾക്ക് കുറച്ച് വിശാലമായി കാണാനാകും. ഇത് റഷ്യൻ വ്യവസായം മാത്രമാണ്: സ്വയം ത്വരിതപ്പെടുത്തുന്നതിന് റഷ്യൻ വ്യവസായത്തിൽ ആവശ്യമായ വൈദഗ്ദ്ധ്യം നേടാനാകുമോ? എക്സ്പ്രസ് 42 കാൽക്കുലേറ്റർ ഇവിടെ സഹായിക്കും (ഇത് വികസനത്തിലാണ്). നിങ്ങൾ റഷ്യൻ വിപണിയെ മറികടക്കുകയാണെങ്കിൽ, നോക്കുക ഡോറ കാൽക്കുലേറ്റർ ലോക വിപണിയിലേക്കും.

നന്നായി. നിങ്ങൾ DORA കാൽക്കുലേറ്ററിലെ എലിറ്റ് ഗ്രൂപ്പിലാണെങ്കിൽ, നിങ്ങൾ എന്താണ് ചെയ്യേണ്ടത്? ഇവിടെ നല്ല പരിഹാരമില്ല. നിങ്ങൾ മിക്കവാറും വ്യവസായത്തിന്റെ മുൻനിരയിലാണ്, കൂടുതൽ ത്വരിതപ്പെടുത്തലും വിശ്വാസ്യതയും ആന്തരിക ഗവേഷണ-വികസനത്തിലൂടെയും കൂടുതൽ വിഭവങ്ങൾ ചെലവഴിക്കുന്നതിലൂടെയും സാധ്യമാണ്.

നമുക്ക് ഏറ്റവും മധുരതരമായ - താരതമ്യത്തിലേക്ക് പോകാം.

താരതമ്യം

റഷ്യൻ വ്യവസായത്തെ പാശ്ചാത്യ വ്യവസായവുമായി താരതമ്യം ചെയ്യാൻ ഞങ്ങൾ ആദ്യം ആഗ്രഹിച്ചു. ഞങ്ങൾ നേരിട്ട് താരതമ്യം ചെയ്യുകയാണെങ്കിൽ, ഞങ്ങൾക്ക് കുറച്ച് പ്രൊഫൈലുകൾ ഉണ്ടെന്നും അവ പരസ്പരം അൽപ്പം കൂടിച്ചേർന്നതായും ഞങ്ങൾ കാണുന്നു, അതിർത്തികൾ കുറച്ചുകൂടി മങ്ങുന്നു:

ഞങ്ങളുടെ എലൈറ്റ് പെർഫോമർമാർ ഉയർന്ന പ്രകടനം നടത്തുന്നവർക്കിടയിൽ മറഞ്ഞിരിക്കുന്നു, പക്ഷേ അവർ അവിടെയുണ്ട് - ഇവരാണ് കാര്യമായ ഉയരങ്ങളിൽ എത്തിയ എലൈറ്റ്, യൂണികോണുകൾ. റഷ്യയിൽ, എലൈറ്റ് പ്രൊഫൈലും ഉയർന്ന പ്രൊഫൈലും തമ്മിലുള്ള വ്യത്യാസം ഇതുവരെ വേണ്ടത്ര പ്രാധാന്യമർഹിക്കുന്നില്ല. എഞ്ചിനീയറിംഗ് സംസ്കാരത്തിന്റെ വർദ്ധനവ്, എഞ്ചിനീയറിംഗ് രീതികൾ നടപ്പിലാക്കുന്നതിന്റെ ഗുണനിലവാരം, കമ്പനികളിലെ വൈദഗ്ദ്ധ്യം എന്നിവ കാരണം ഭാവിയിൽ ഈ വേർതിരിവ് സംഭവിക്കുമെന്ന് ഞങ്ങൾ കരുതുന്നു.

റഷ്യൻ വ്യവസായത്തിനുള്ളിലെ നേരിട്ടുള്ള താരതമ്യത്തിലേക്ക് നീങ്ങുകയാണെങ്കിൽ, ഉയർന്ന പ്രൊഫൈൽ ടീമുകൾ എല്ലാ അർത്ഥത്തിലും മികച്ചതാണെന്ന് നമുക്ക് കാണാൻ കഴിയും. ഈ അളവുകോലുകളും ഓർഗനൈസേഷണൽ പ്രകടനവും തമ്മിൽ ബന്ധമുണ്ടെന്ന ഞങ്ങളുടെ അനുമാനവും ഞങ്ങൾ സ്ഥിരീകരിച്ചു: ഉയർന്ന പ്രൊഫൈൽ ടീമുകൾ ലക്ഷ്യങ്ങൾ കൈവരിക്കാൻ മാത്രമല്ല, അവയെ മറികടക്കാനും കൂടുതൽ സാധ്യതയുണ്ട്.
നമുക്ക് ഹൈ പ്രൊഫൈൽ ടീമുകളായി മാറാം, അവിടെ നിർത്തരുത്:

എന്നാൽ ഈ വർഷം സവിശേഷമാണ്, ഒരു മഹാമാരിയിൽ കമ്പനികൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് പരിശോധിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു: ഉയർന്ന പ്രൊഫൈൽ ടീമുകൾ വ്യവസായ ശരാശരിയേക്കാൾ മികച്ചതും മികച്ചതുമാണ്:

• പുതിയ ഉൽപ്പന്നങ്ങൾ പുറത്തിറക്കാനുള്ള സാധ്യത 1,5-2 മടങ്ങ് കൂടുതലാണ്,
• ആപ്ലിക്കേഷൻ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ വിശ്വാസ്യത കൂടാതെ / അല്ലെങ്കിൽ പ്രകടനം മെച്ചപ്പെടുത്താൻ 2 മടങ്ങ് കൂടുതൽ സാധ്യതയുണ്ട്.

അതായത്, വേഗത്തിൽ വികസിപ്പിക്കുന്നതിനും പുതിയ ഉൽപ്പന്നങ്ങൾ സമാരംഭിക്കുന്നതിനും നിലവിലുള്ള ഉൽപ്പന്നങ്ങൾ പരിഷ്‌ക്കരിക്കുന്നതിനും അതുവഴി പുതിയ വിപണികളെയും പുതിയ ഉപയോക്താക്കളെയും കീഴടക്കുന്നതിനും അവർ ഇതിനകം സഹായിച്ച കഴിവുകൾ:

മറ്റെന്താണ് ഞങ്ങളുടെ ടീമുകളെ സഹായിച്ചത്?

എഞ്ചിനീയറിംഗ് രീതികൾ

ഞങ്ങൾ പരിശോധിച്ച ഓരോ പരിശീലനത്തിനും കാര്യമായ കണ്ടെത്തലുകളെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് പറയും. ഒരുപക്ഷേ മറ്റെന്തെങ്കിലും ടീമുകളെ സഹായിച്ചിട്ടുണ്ടാകാം, പക്ഷേ നമ്മൾ സംസാരിക്കുന്നത് DevOps-നെക്കുറിച്ചാണ്. DevOps-ൽ, വ്യത്യസ്ത പ്രൊഫൈലുകളുടെ ടീമുകൾ തമ്മിലുള്ള വ്യത്യാസങ്ങൾ ഞങ്ങൾ കാണുന്നു.

ഒരു സേവനമായി പ്ലാറ്റ്ഫോം

പ്ലാറ്റ്‌ഫോം പ്രായവും ടീം പ്രൊഫൈലും തമ്മിൽ കാര്യമായ ബന്ധം ഞങ്ങൾ കണ്ടെത്തിയില്ല: ലോ-ടീമുകൾക്കും ഉയർന്ന ടീമുകൾക്കുമായി പ്ലാറ്റ്‌ഫോമുകൾ ഒരേ സമയം പ്രത്യക്ഷപ്പെട്ടു. എന്നാൽ രണ്ടാമത്തേതിന്, പ്ലാറ്റ്ഫോം ശരാശരി കൂടുതൽ സേവനങ്ങളും പ്രോഗ്രാം കോഡിലൂടെ നിയന്ത്രണത്തിനായി കൂടുതൽ പ്രോഗ്രാമിംഗ് ഇന്റർഫേസുകളും നൽകുന്നു. പ്ലാറ്റ്‌ഫോം ടീമുകൾ അവരുടെ ഡവലപ്പർമാരെയും ടീമുകളെയും പ്ലാറ്റ്‌ഫോം ഉപയോഗിക്കാനും അവരുടെ പ്രശ്‌നങ്ങളും പ്ലാറ്റ്‌ഫോമുമായി ബന്ധപ്പെട്ട സംഭവങ്ങളും കൂടുതൽ തവണ പരിഹരിക്കാനും മറ്റ് ടീമുകളെ ബോധവൽക്കരിക്കാനും സഹായിക്കാനും സാധ്യതയുണ്ട്.

അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡായി

ഇവിടെ എല്ലാം വളരെ നിലവാരമുള്ളതാണ്. ഇൻഫ്രാസ്ട്രക്ചർ കോഡിന്റെ പ്രവർത്തനത്തിന്റെ ഓട്ടോമേഷനും ഇൻഫ്രാസ്ട്രക്ചർ റിപ്പോസിറ്ററിയിൽ എത്ര വിവരങ്ങൾ സംഭരിച്ചിരിക്കുന്നു എന്നതും തമ്മിൽ ഞങ്ങൾ ഒരു ബന്ധം കണ്ടെത്തി. ഹൈ പ്രൊഫൈൽ കമാൻഡുകൾ റിപ്പോസിറ്ററികളിൽ കൂടുതൽ വിവരങ്ങൾ സംഭരിക്കുന്നു: ഇതാണ് ഇൻഫ്രാസ്ട്രക്ചർ കോൺഫിഗറേഷൻ, സിഐ / സിഡി പൈപ്പ്ലൈൻ, പരിസ്ഥിതി ക്രമീകരണങ്ങൾ, ബിൽഡ് പാരാമീറ്ററുകൾ. അവർ ഈ വിവരങ്ങൾ കൂടുതൽ തവണ സംഭരിക്കുന്നു, ഇൻഫ്രാസ്ട്രക്ചർ കോഡ് ഉപയോഗിച്ച് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു, കൂടാതെ ഇൻഫ്രാസ്ട്രക്ചർ കോഡിനൊപ്പം പ്രവർത്തിക്കുന്നതിന് കൂടുതൽ പ്രക്രിയകളും ടാസ്ക്കുകളും ഓട്ടോമേറ്റ് ചെയ്യുന്നു.

രസകരമെന്നു പറയട്ടെ, ഇൻഫ്രാസ്ട്രക്ചർ ടെസ്റ്റുകളിൽ കാര്യമായ വ്യത്യാസം ഞങ്ങൾ കണ്ടില്ല. ഹൈ പ്രൊഫൈൽ ടീമുകൾക്ക് പൊതുവെ കൂടുതൽ ടെസ്റ്റ് ഓട്ടോമേഷൻ ഉണ്ടെന്നതാണ് ഞാൻ ഇതിന് ആട്രിബ്യൂട്ട് ചെയ്യുന്നത്. ഇൻഫ്രാസ്ട്രക്ചർ ടെസ്റ്റുകളിലൂടെ അവർ പ്രത്യേകം ശ്രദ്ധ തിരിക്കരുത്, മറിച്ച് അവർ ആപ്ലിക്കേഷനുകൾ പരിശോധിക്കുന്ന ടെസ്റ്റുകളാണ്, അവർക്ക് നന്ദി, അവർ എന്താണ്, എവിടെയാണ് തകർന്നതെന്ന് അവർ ഇതിനകം കാണുന്നു.

സംയോജനവും വിതരണവും

ഏറ്റവും വിരസമായ വിഭാഗം, കാരണം ഞങ്ങൾ സ്ഥിരീകരിച്ചു: നിങ്ങൾക്ക് കൂടുതൽ ഓട്ടോമേഷൻ ഉണ്ട്, നിങ്ങൾ കോഡ് ഉപയോഗിച്ച് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു, നിങ്ങൾക്ക് മികച്ച ഫലങ്ങൾ ലഭിക്കാനുള്ള സാധ്യത കൂടുതലാണ്.

വാസ്തുവിദ്യ

മൈക്രോസർവീസുകൾ പ്രകടനത്തെ എങ്ങനെ ബാധിക്കുന്നുവെന്ന് കാണാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. സത്യത്തിൽ, അവർ അങ്ങനെ ചെയ്യുന്നില്ല, കാരണം മൈക്രോസർവീസുകളുടെ ഉപയോഗം പ്രകടന സൂചകങ്ങളുടെ വർദ്ധനവുമായി ബന്ധപ്പെട്ടിട്ടില്ല. ഹൈ പ്രൊഫൈൽ കമാൻഡുകൾക്കും ലോ പ്രൊഫൈൽ കമാൻഡുകൾക്കും മൈക്രോസർവീസുകൾ ഉപയോഗിക്കുന്നു.

ഉയർന്ന ടീമുകളെ സംബന്ധിച്ചിടത്തോളം, മൈക്രോ സർവീസ് ആർക്കിടെക്ചറിലേക്കുള്ള മാറ്റം അവരുടെ സേവനങ്ങൾ സ്വതന്ത്രമായി വികസിപ്പിക്കാനും പുറത്തുവിടാനും അവരെ അനുവദിക്കുന്നു എന്നതാണ് പ്രധാന കാര്യം. വാസ്തുവിദ്യ ഡവലപ്പർമാരെ ടീമിന് പുറത്തുള്ള ഒരാളെ കാത്തുനിൽക്കാതെ സ്വയംഭരണാധികാരത്തോടെ പ്രവർത്തിക്കാൻ അനുവദിക്കുകയാണെങ്കിൽ, വേഗത വർദ്ധിപ്പിക്കുന്നതിനുള്ള ഒരു പ്രധാന കഴിവാണിത്. ഈ സാഹചര്യത്തിൽ, മൈക്രോസർവീസുകൾ സഹായിക്കുന്നു. മാത്രമല്ല അവ നടപ്പിലാക്കുന്നത് വലിയ പങ്ക് വഹിക്കുന്നില്ല.

ഇതെല്ലാം നമ്മൾ എങ്ങനെ കണ്ടുപിടിച്ചു?

DORA മെത്തഡോളജി പൂർണ്ണമായി പകർത്താൻ ഞങ്ങൾക്ക് അതിമോഹമായ ഒരു പദ്ധതി ഉണ്ടായിരുന്നു, പക്ഷേ വിഭവങ്ങൾ കുറവായിരുന്നു. DORA ധാരാളം സ്പോൺസർഷിപ്പ് ഉപയോഗിക്കുകയും അവരുടെ ഗവേഷണത്തിന് അര വർഷമെടുക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, ഞങ്ങൾ ചുരുങ്ങിയ സമയത്തിനുള്ളിൽ ഞങ്ങളുടെ ഗവേഷണം നടത്തി. DORA ചെയ്യുന്നതുപോലെ ഒരു DevOps മോഡൽ നിർമ്മിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു, ഭാവിയിൽ ഞങ്ങൾ അത് ചെയ്യും. ഇതുവരെ ഞങ്ങൾ ഹീറ്റ് മാപ്പുകളിലേക്ക് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു:

ഓരോ പ്രൊഫൈലിലെയും ടീമുകളിലുടനീളമുള്ള എഞ്ചിനീയറിംഗ് പരിശീലനങ്ങളുടെ വിതരണം ഞങ്ങൾ പരിശോധിച്ചു, ഉയർന്ന പ്രൊഫൈൽ ടീമുകൾ ശരാശരി എഞ്ചിനീയറിംഗ് രീതികൾ ഉപയോഗിക്കാനുള്ള സാധ്യത കൂടുതലാണെന്ന് കണ്ടെത്തി. ഇതിനെക്കുറിച്ച് നിങ്ങൾക്ക് ഞങ്ങളുടെ ലേഖനത്തിൽ കൂടുതൽ വായിക്കാം റിപ്പോർട്ട്.

ഒരു മാറ്റത്തിന്, സങ്കീർണ്ണമായ സ്ഥിതിവിവരക്കണക്കുകളിൽ നിന്ന് ലളിതമായവയിലേക്ക് മാറാം.

മറ്റെന്താണ് നമ്മൾ കണ്ടെത്തിയത്?

ഉപകരണങ്ങൾ

ലിനക്സ് ഫാമിലിയുടെ ഒഎസാണ് മിക്ക കമാൻഡുകളും ഉപയോഗിക്കുന്നതെന്ന് ഞങ്ങൾ നിരീക്ഷിക്കുന്നു. എന്നാൽ വിൻഡോസ് ഇപ്പോഴും ട്രെൻഡിലാണ് - ഞങ്ങളുടെ പ്രതികരിച്ചവരിൽ നാലിലൊന്ന് എങ്കിലും അതിന്റെ ഒന്നോ അതിലധികമോ പതിപ്പുകളുടെ ഉപയോഗം ശ്രദ്ധിച്ചു. വിപണിക്ക് ഈ ആവശ്യമുണ്ടെന്ന് തോന്നുന്നു. അതിനാൽ, നിങ്ങൾക്ക് ഈ കഴിവുകൾ വികസിപ്പിക്കാനും കോൺഫറൻസുകളിൽ അവതരണങ്ങൾ നടത്താനും കഴിയും.

ഓർക്കസ്ട്രേറ്റർമാർക്കിടയിൽ, ഇത് ആർക്കും രഹസ്യമല്ല, കുബർനെറ്റസ് ലീഡ് ചെയ്യുന്നു (52%). ലൈൻ ഓർക്കസ്ട്രേറ്റർ ഡോക്കർ സ്വാം ആണ് (ഏകദേശം 12%). ഏറ്റവും പ്രചാരമുള്ള CI സിസ്റ്റങ്ങൾ Jenkins, GitLab എന്നിവയാണ്. ഏറ്റവും ജനപ്രിയമായ കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് സിസ്റ്റം അൻസിബിൾ ആണ്, തുടർന്ന് ഞങ്ങളുടെ പ്രിയപ്പെട്ട ഷെൽ.

നിലവിൽ ക്ലൗഡ് ഹോസ്റ്റിംഗ് ദാതാവാണ് ആമസോൺ. റഷ്യൻ മേഘങ്ങളുടെ പങ്ക് ക്രമേണ വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണ്. അടുത്ത വർഷം റഷ്യൻ ക്ലൗഡ് ദാതാക്കൾക്ക് എങ്ങനെ അനുഭവപ്പെടും, അവരുടെ വിപണി വിഹിതം വർദ്ധിക്കുമോ എന്ന് കാണുന്നത് രസകരമായിരിക്കും. അവ, അവ ഉപയോഗിക്കാൻ കഴിയും, അത് നല്ലതാണ്:

ഞാൻ ഇഗോറിന് ഫ്ലോർ കൈമാറുന്നു, അദ്ദേഹം കുറച്ച് സ്ഥിതിവിവരക്കണക്കുകൾ നൽകും.

ആചാരങ്ങളുടെ വ്യാപനം

ഇഗോർ കുറോച്ച്കിൻ: കമ്പനിയിൽ പരിഗണിക്കപ്പെടുന്ന എഞ്ചിനീയറിംഗ് രീതികൾ എങ്ങനെ വിതരണം ചെയ്യുന്നുവെന്ന് സൂചിപ്പിക്കാൻ ഞങ്ങൾ പ്രതികരിച്ചവരോട് പ്രത്യേകം ആവശ്യപ്പെട്ടു. മിക്ക കമ്പനികളിലും, വ്യത്യസ്തമായ പാറ്റേണുകൾ അടങ്ങുന്ന ഒരു സമ്മിശ്ര സമീപനമുണ്ട്, പൈലറ്റ് പ്രോജക്ടുകൾ വളരെ ജനപ്രിയമാണ്. പ്രൊഫൈലുകൾ തമ്മിൽ ചെറിയ വ്യത്യാസവും ഞങ്ങൾ കണ്ടു. സ്പെഷ്യലിസ്റ്റുകളുടെ ചെറിയ ടീമുകൾ വർക്ക് പ്രോസസുകളും ടൂളുകളും മാറ്റുകയും വിജയകരമായ കീഴ്വഴക്കങ്ങൾ മറ്റ് ടീമുകളുമായി പങ്കിടുകയും ചെയ്യുമ്പോൾ ഉയർന്ന പ്രൊഫൈലിന്റെ പ്രതിനിധികൾ "താഴെയിൽ നിന്നുള്ള സംരംഭം" പാറ്റേൺ ഉപയോഗിക്കുന്നു. മീഡിയത്തിൽ, കമ്മ്യൂണിറ്റികളും മികവിന്റെ കേന്ദ്രങ്ങളും സൃഷ്ടിക്കുന്നതിലൂടെ കമ്പനിയെ മുഴുവൻ ബാധിക്കുന്ന ഒരു ടോപ്പ്-ഡൗൺ സംരംഭമാണിത്:

എജൈൽ ആൻഡ് DevOps

Agile ഉം DevOps ഉം തമ്മിലുള്ള ബന്ധത്തെക്കുറിച്ചുള്ള ചോദ്യം പലപ്പോഴും വ്യവസായത്തിൽ ചർച്ച ചെയ്യപ്പെടുന്നു. 2019/2020 ലെ സ്‌റ്റേറ്റ് ഓഫ് എജൈൽ റിപ്പോർട്ടിലും ഈ പ്രശ്‌നം ഉന്നയിക്കപ്പെട്ടിട്ടുണ്ട്, അതിനാൽ കമ്പനികളിൽ Agile, DevOps പ്രവർത്തനങ്ങൾ എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്ന് താരതമ്യം ചെയ്യാൻ ഞങ്ങൾ തീരുമാനിച്ചു. Agile ഇല്ലാത്ത DevOps അപൂർവമാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി. പ്രതികരിച്ചവരിൽ പകുതി പേർക്കും, എജൈലിന്റെ വ്യാപനം വളരെ മുമ്പേ ആരംഭിച്ചു, ഏകദേശം 20% ഒരേസമയം ആരംഭിച്ചത് നിരീക്ഷിച്ചു, കൂടാതെ ലോ പ്രൊഫൈലിന്റെ അടയാളങ്ങളിലൊന്ന് എജൈൽ, ഡെവോപ്സ് പ്രാക്ടീസുകളുടെ അഭാവം ആയിരിക്കും:

കമാൻഡ് ടോപ്പോളജികൾ

കഴിഞ്ഞ വർഷം അവസാനം പുസ്തകംടീം ടോപ്പോളജികൾ”, കമാൻഡ് ടോപ്പോളജികൾ വിവരിക്കുന്നതിനുള്ള ഒരു ചട്ടക്കൂട് നിർദ്ദേശിക്കുന്നു. റഷ്യൻ കമ്പനികൾക്ക് ഇത് ബാധകമാണോ എന്നത് ഞങ്ങൾക്ക് രസകരമായിത്തീർന്നു. ഞങ്ങൾ ചോദ്യം ചോദിച്ചു: "ഏത് പാറ്റേണുകളാണ് നിങ്ങൾ കണ്ടെത്തുന്നത്?".

പ്രതികരിച്ചവരിൽ പകുതിയിലും ഇൻഫ്രാസ്ട്രക്ചർ ടീമുകളും വികസനത്തിനും പരിശോധനയ്ക്കും പ്രവർത്തനത്തിനുമായി പ്രത്യേക ടീമുകളും നിരീക്ഷിക്കപ്പെടുന്നു. പ്രത്യേക DevOps ടീമുകൾ 45% രേഖപ്പെടുത്തി, അതിൽ ഹൈയുടെ പ്രതിനിധികൾ കൂടുതൽ സാധാരണമാണ്. അടുത്തതായി ക്രോസ്-ഫംഗ്ഷണൽ ടീമുകൾ വരുന്നു, അവ ഹൈയിലും കൂടുതൽ സാധാരണമാണ്. ഉയർന്ന, ഇടത്തരം പ്രൊഫൈലുകളിൽ പ്രത്യേക SRE കമാൻഡുകൾ ദൃശ്യമാകുകയും ലോ പ്രൊഫൈലിൽ അപൂർവ്വമായി കാണുകയും ചെയ്യുന്നു:

DevQaOps അനുപാതം

സ്കൈങ് പ്ലാറ്റ്ഫോം ടീമിന്റെ ടീം ലീഡറിൽ നിന്ന് ഞങ്ങൾ ഈ ചോദ്യം Facebook-ൽ കണ്ടു - കമ്പനികളിലെ ഡവലപ്പർമാർ, ടെസ്റ്റർമാർ, അഡ്മിനിസ്ട്രേറ്റർമാർ എന്നിവരുടെ അനുപാതത്തിൽ അദ്ദേഹത്തിന് താൽപ്പര്യമുണ്ടായിരുന്നു. ഞങ്ങൾ അത് ചോദിക്കുകയും പ്രൊഫൈലുകളെ അടിസ്ഥാനമാക്കിയുള്ള പ്രതികരണങ്ങൾ നോക്കുകയും ചെയ്തു: ഉയർന്ന പ്രൊഫൈൽ പ്രതിനിധികൾക്ക് ഓരോ ഡെവലപ്പർക്കും ടെസ്റ്റ്, ഓപ്പറേഷൻസ് എഞ്ചിനീയർമാർ കുറവാണ്:

2021 വർഷത്തേക്കുള്ള പ്ലാനുകൾ

അടുത്ത വർഷത്തേക്കുള്ള പദ്ധതികളിൽ, പ്രതികരിച്ചവർ ഇനിപ്പറയുന്ന പ്രവർത്തനങ്ങൾ ശ്രദ്ധിച്ചു:

DevOps ലൈവ് 2020 കോൺഫറൻസിനൊപ്പം നിങ്ങൾക്ക് ഇവിടെ കവല കാണാം. ഞങ്ങൾ പ്രോഗ്രാം ശ്രദ്ധാപൂർവ്വം അവലോകനം ചെയ്തു:

• ഒരു ഉൽപ്പന്നമെന്ന നിലയിൽ അടിസ്ഥാന സൗകര്യങ്ങൾ
• DevOps പരിവർത്തനം
• DevOps പ്രാക്ടീസുകളുടെ വിതരണം
• DevSecOps
• കേസ് ക്ലബ്ബുകളും ചർച്ചകളും

എന്നാൽ ഞങ്ങളുടെ അവതരണ സമയം എല്ലാ വിഷയങ്ങളും ഉൾക്കൊള്ളാൻ പര്യാപ്തമല്ല. തിരശ്ശീലയ്ക്ക് പിന്നിൽ അവശേഷിക്കുന്നു:

• ഒരു സേവനമായും ഉൽപ്പന്നമായും പ്ലാറ്റ്ഫോം;
• കോഡ്, പരിതസ്ഥിതികൾ, മേഘങ്ങൾ എന്നിങ്ങനെ അടിസ്ഥാന സൗകര്യങ്ങൾ;
• തുടർച്ചയായ സംയോജനവും വിതരണവും;
• വാസ്തുവിദ്യ;
• DevSecOps പാറ്റേണുകൾ;
• പ്ലാറ്റ്ഫോമും ക്രോസ്-ഫംഗ്ഷണൽ ടീമുകളും.

റിപ്പോർട്ട് ചെയ്യുക ഞങ്ങൾക്ക് ഒരു വലിയ, 50 പേജുകൾ ലഭിച്ചു, നിങ്ങൾക്ക് ഇത് കൂടുതൽ വിശദമായി കാണാൻ കഴിയും.

സംഗ്രഹിക്കുന്നു

ഞങ്ങളുടെ ഗവേഷണവും റിപ്പോർട്ടും വികസനം, പരിശോധന, പ്രവർത്തനങ്ങൾ എന്നിവയിലേക്കുള്ള പുതിയ സമീപനങ്ങൾ പരീക്ഷിക്കുന്നതിന് നിങ്ങളെ പ്രചോദിപ്പിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു, ഒപ്പം നാവിഗേറ്റുചെയ്യാനും പഠനത്തിലെ മറ്റ് പങ്കാളികളുമായി സ്വയം താരതമ്യം ചെയ്യാനും നിങ്ങളുടെ സ്വന്തം സമീപനങ്ങൾ മെച്ചപ്പെടുത്താൻ കഴിയുന്ന മേഖലകൾ തിരിച്ചറിയാനും നിങ്ങളെ സഹായിക്കുന്നു.

റഷ്യയിലെ DevOps നിലയെക്കുറിച്ചുള്ള ആദ്യ പഠനത്തിന്റെ ഫലങ്ങൾ:

• പ്രധാന അളവുകൾ. വികസനം, പരിശോധന, പ്രവർത്തന പ്രക്രിയകൾ എന്നിവയുടെ ഫലപ്രാപ്തി വിശകലനം ചെയ്യുന്നതിന് പ്രധാന അളവുകൾ (ഡെലിവറി സമയം, വിന്യാസ ആവൃത്തി, വീണ്ടെടുക്കൽ സമയം, മാറ്റ പരാജയങ്ങൾ) അനുയോജ്യമാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി.
• പ്രൊഫൈലുകൾ ഉയർന്നത്, ഇടത്തരം, താഴ്ന്നത്. ശേഖരിച്ച ഡാറ്റയെ അടിസ്ഥാനമാക്കി, മെട്രിക്‌സ്, സമ്പ്രദായങ്ങൾ, പ്രോസസ്സുകൾ, ടൂളുകൾ എന്നിവയുടെ അടിസ്ഥാനത്തിൽ വ്യതിരിക്തമായ സവിശേഷതകളുള്ള ഉയർന്ന, ഇടത്തരം, താഴ്ന്ന വിഭാഗങ്ങളുടെ സ്ഥിതിവിവരക്കണക്കനുസരിച്ച് നമുക്ക് വേർതിരിച്ചറിയാൻ കഴിയും. ഉയർന്ന പ്രൊഫൈലിന്റെ പ്രതിനിധികൾ താഴ്ന്നതിനേക്കാൾ മികച്ച ഫലങ്ങൾ കാണിക്കുന്നു. അവർ തങ്ങളുടെ ലക്ഷ്യങ്ങൾ കൈവരിക്കാനും മറികടക്കാനും കൂടുതൽ സാധ്യതയുണ്ട്.
• സൂചകങ്ങൾ, പകർച്ചവ്യാധികൾ, 2021-ലെ പദ്ധതികൾ. ഈ വർഷത്തെ ഒരു പ്രത്യേക സൂചകം കമ്പനികൾ എങ്ങനെയാണ് പാൻഡെമിക്കിനെ നേരിട്ടത് എന്നതാണ്. ഉയർന്ന പ്രതിനിധികൾ മികച്ച പ്രകടനം കാഴ്ചവച്ചു, ഉപയോക്തൃ ഇടപെടൽ അനുഭവപ്പെട്ടു, വിജയത്തിന്റെ പ്രധാന കാരണങ്ങൾ കാര്യക്ഷമമായ വികസന പ്രക്രിയകളും ശക്തമായ എഞ്ചിനീയറിംഗ് സംസ്കാരവുമായിരുന്നു.
• DevOps പരിശീലനങ്ങളും ഉപകരണങ്ങളും അവയുടെ വികസനവും. അടുത്ത വർഷത്തെ കമ്പനികളുടെ പ്രധാന പദ്ധതികളിൽ DevOps പ്രാക്ടീസുകളുടെയും ടൂളുകളുടെയും വികസനം, DevSecOps പ്രാക്ടീസുകളുടെ ആമുഖം, സംഘടനാ ഘടനയിലെ മാറ്റങ്ങൾ എന്നിവ ഉൾപ്പെടുന്നു. പൈലറ്റ് പ്രോജക്റ്റുകൾ, കമ്മ്യൂണിറ്റികളുടെയും യോഗ്യതാ കേന്ദ്രങ്ങളുടെയും രൂപീകരണം, കമ്പനിയുടെ മുകളിലും താഴെയുമുള്ള സംരംഭങ്ങൾ എന്നിവയിലൂടെയാണ് DevOps രീതികൾ ഫലപ്രദമായി നടപ്പിലാക്കുന്നതും വികസിപ്പിക്കുന്നതും.

നിങ്ങളുടെ ഫീഡ്‌ബാക്കും കഥകളും ഫീഡ്‌ബാക്കും കേൾക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. പഠനത്തിൽ പങ്കെടുത്ത എല്ലാവർക്കും ഞങ്ങൾ നന്ദി പറയുന്നു, അടുത്ത വർഷം നിങ്ങളുടെ പങ്കാളിത്തം പ്രതീക്ഷിക്കുന്നു.

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