ഹൈലോഡ് ഐടി സിസ്റ്റങ്ങളുടെ പ്രവർത്തനത്തിലും പിന്തുണയിലും അഞ്ച് പ്രശ്നങ്ങൾ

ഹലോ, ഹബ്ർ! പത്ത് വർഷമായി ഞാൻ ഹൈലോഡ് ഐടി സംവിധാനങ്ങളെ പിന്തുണയ്ക്കുന്നു. 1000+ RPS മോഡിലോ മറ്റ് സാങ്കേതിക കാര്യങ്ങളിലോ പ്രവർത്തിക്കാൻ nginx സജ്ജീകരിക്കുന്നതിലെ പ്രശ്നങ്ങളെക്കുറിച്ച് ഞാൻ ഈ ലേഖനത്തിൽ എഴുതില്ല. അത്തരം സിസ്റ്റങ്ങളുടെ പിന്തുണയിലും പ്രവർത്തനത്തിലും ഉണ്ടാകുന്ന പ്രക്രിയകളിലെ പ്രശ്നങ്ങളെക്കുറിച്ചുള്ള എന്റെ നിരീക്ഷണങ്ങൾ ഞാൻ പങ്കിടും.

നിരീക്ഷിക്കുന്നു

"എന്തുകൊണ്ട്... സൈറ്റ് വീണ്ടും പ്രവർത്തിക്കുന്നില്ല?" എന്ന ഉള്ളടക്കമുള്ള ഒരു അഭ്യർത്ഥന വരുന്നത് വരെ സാങ്കേതിക പിന്തുണ കാത്തിരിക്കുന്നില്ല. സൈറ്റ് തകരാറിലായതിന് ശേഷം ഒരു മിനിറ്റിനുള്ളിൽ, പിന്തുണ ഇതിനകം തന്നെ പ്രശ്നം കാണുകയും അത് പരിഹരിക്കാൻ തുടങ്ങുകയും വേണം. എന്നാൽ ഈ സൈറ്റ് മഞ്ഞുമലയുടെ അഗ്രമാണ്. അതിന്റെ ലഭ്യത ആദ്യം നിരീക്ഷിക്കേണ്ട ഒന്നാണ്.

ഒരു ഓൺലൈൻ സ്റ്റോറിന്റെ ശേഷിക്കുന്ന സാധനങ്ങൾ ഇആർപി സിസ്റ്റത്തിൽ നിന്ന് ഇനി വരാത്ത സാഹചര്യത്തിൽ എന്തുചെയ്യണം? അതോ ക്ലയന്റുകൾക്കുള്ള കിഴിവുകൾ കണക്കാക്കുന്ന CRM സിസ്റ്റം പ്രതികരിക്കുന്നത് നിർത്തിയോ? സൈറ്റ് പ്രവർത്തിക്കുന്നതായി തോന്നുന്നു. സോപാധികമായ Zabbix-ന് അതിന്റെ 200 പ്രതികരണം ലഭിക്കുന്നു. ഡ്യൂട്ടി ഷിഫ്റ്റിന് മോണിറ്ററിംഗിൽ നിന്ന് അറിയിപ്പുകളൊന്നും ലഭിച്ചിട്ടില്ല, ഗെയിം ഓഫ് ത്രോൺസിന്റെ പുതിയ സീസണിന്റെ ആദ്യ എപ്പിസോഡ് സന്തോഷത്തോടെ കാണുന്നു.

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

അതിനാൽ, സെർവറുകളിലെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളുടെ സാങ്കേതിക പാരാമീറ്ററുകൾ നിരീക്ഷിക്കുന്നതിനു പുറമേ, നിങ്ങൾ ബിസിനസ്സ് മെട്രിക്സ് കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്. പണത്തെ നേരിട്ട് ബാധിക്കുന്ന അളവുകൾ. ബാഹ്യ സംവിധാനങ്ങളുമായുള്ള വിവിധ ഇടപെടലുകൾ (CRM, ERP എന്നിവയും മറ്റുള്ളവയും). ഒരു നിശ്ചിത സമയത്തേക്കുള്ള ഓർഡറുകളുടെ എണ്ണം. വിജയിച്ചതോ പരാജയപ്പെട്ടതോ ആയ ക്ലയന്റ് അംഗീകാരങ്ങളും മറ്റ് മെട്രിക്കുകളും.

ബാഹ്യ സംവിധാനങ്ങളുമായുള്ള ഇടപെടൽ

ഒരു ബില്യൺ റുബിളിൽ കൂടുതൽ വാർഷിക വിറ്റുവരവുള്ള ഏതൊരു വെബ്‌സൈറ്റും മൊബൈൽ ആപ്ലിക്കേഷനും ബാഹ്യ സംവിധാനങ്ങളുമായി സംവദിക്കുന്നു. മുകളിൽ സൂചിപ്പിച്ച CRM, ERP എന്നിവയിൽ നിന്ന് ആരംഭിച്ച് വാങ്ങലുകൾ വിശകലനം ചെയ്യുന്നതിനും ക്ലയന്റിന് അവൻ തീർച്ചയായും വാങ്ങുന്ന ഒരു ഉൽപ്പന്നം വാഗ്ദാനം ചെയ്യുന്നതിനുമായി ഒരു ബാഹ്യ ബിഗ് ഡാറ്റ സിസ്റ്റത്തിലേക്ക് വിൽപ്പന ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നതോടെ അവസാനിക്കുന്നു (വാസ്തവത്തിൽ, അല്ല). അത്തരം ഓരോ സിസ്റ്റത്തിനും അതിന്റേതായ പിന്തുണയുണ്ട്. പലപ്പോഴും ഈ സംവിധാനങ്ങളുമായുള്ള ആശയവിനിമയം വേദനയ്ക്ക് കാരണമാകുന്നു. പ്രത്യേകിച്ചും പ്രശ്നം ആഗോളമായിരിക്കുമ്പോൾ, നിങ്ങൾ അത് വ്യത്യസ്ത സിസ്റ്റങ്ങളിൽ വിശകലനം ചെയ്യേണ്ടതുണ്ട്.

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

ഈ പ്രശ്നത്തിനുള്ള ഏറ്റവും നല്ല പരിഹാരം ആശയവിനിമയത്തിനായി ഒരൊറ്റ ഇടം സൃഷ്ടിക്കുക എന്നതാണ്, ഉദാഹരണത്തിന് സ്ലാക്കിൽ. ബാഹ്യ സിസ്റ്റങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന പ്രക്രിയയിൽ പങ്കെടുക്കുന്ന എല്ലാവരെയും ചേരാൻ ക്ഷണിക്കുന്നു. കൂടാതെ ആപ്ലിക്കേഷനുകൾ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യാതിരിക്കാൻ ഒരൊറ്റ ട്രാക്കറും. അറിയിപ്പുകൾ നിരീക്ഷിക്കുന്നത് മുതൽ ഭാവിയിലെ ബഗ് സൊല്യൂഷനുകളുടെ ഔട്ട്‌പുട്ട് വരെ അപ്ലിക്കേഷനുകൾ ഒരിടത്ത് ട്രാക്ക് ചെയ്യണം. ഇത് യാഥാർത്ഥ്യത്തിന് നിരക്കാത്തതാണെന്നും ചരിത്രപരമായി ഞങ്ങൾ ഒരു ട്രാക്കറിൽ പ്രവർത്തിക്കുന്നുവെന്നും അവർ മറ്റൊന്നിൽ പ്രവർത്തിക്കുന്നുവെന്നും നിങ്ങൾ പറയും. വ്യത്യസ്ത സംവിധാനങ്ങൾ പ്രത്യക്ഷപ്പെട്ടു, അവർക്ക് അവരുടേതായ സ്വയംഭരണ ഐടി ടീമുകൾ ഉണ്ടായിരുന്നു. ഞാൻ സമ്മതിക്കുന്നു, അതിനാൽ പ്രശ്നം CIO അല്ലെങ്കിൽ ഉൽപ്പന്ന ഉടമ തലത്തിൽ മുകളിൽ നിന്ന് പരിഹരിക്കേണ്ടതുണ്ട്.

നിങ്ങൾ ഇടപഴകുന്ന ഓരോ സിസ്റ്റവും മുൻ‌ഗണന പ്രകാരം പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന് വ്യക്തമായ SLA ഉള്ള ഒരു സേവനമെന്ന നിലയിൽ പിന്തുണ നൽകണം. സോപാധിക അഡ്മിൻ ആൻഡ്രി നിങ്ങൾക്കായി ഒരു മിനിറ്റ് ഉള്ളപ്പോഴല്ല.

ബോട്ടിൽനെക്ക് മാൻ

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

രേഖകളുടെ അഭാവമാണ് ഈ പ്രശ്നത്തിന്റെ അടിസ്ഥാനം. എല്ലാത്തിനുമുപരി, നിങ്ങളുടെ സിസ്റ്റത്തിന്റെ എല്ലാ സേവനങ്ങളും വിവരിച്ചിട്ടുണ്ടെങ്കിൽ, ഒരു അനലിസ്റ്റില്ലാതെ പ്രശ്നം കൈകാര്യം ചെയ്യാൻ കഴിയും. devops അവന്റെ തിരക്കുള്ള ഷെഡ്യൂളിൽ നിന്ന് കുറച്ച് ദിവസമെടുത്ത് എല്ലാ സെർവറുകളും സേവനങ്ങളും സാധാരണ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള നിർദ്ദേശങ്ങളും വിവരിച്ചാൽ, അവന്റെ അഭാവത്തിൽ പ്രശ്നം പരിഹരിക്കാൻ കഴിയും. അവധിക്കാലത്ത് കടൽത്തീരത്ത് നിങ്ങളുടെ ബിയർ വേഗത്തിൽ പൂർത്തിയാക്കേണ്ടതില്ല, പ്രശ്നം പരിഹരിക്കാൻ wi-fi തിരയുക.

സപ്പോർട്ട് സ്റ്റാഫിന്റെ കഴിവും ഉത്തരവാദിത്തവും

വലിയ പ്രോജക്ടുകളിൽ കമ്പനികൾ ഡെവലപ്പർമാരുടെ ശമ്പളം ഒഴിവാക്കില്ല. അവർ സമാന പ്രോജക്റ്റുകളിൽ നിന്നുള്ള ചെലവേറിയ മധ്യവർത്തികളോ മുതിർന്നവരെയോ തിരയുന്നു. പിന്തുണയോടെ, സ്ഥിതി അല്പം വ്യത്യസ്തമാണ്. സാധ്യമായ എല്ലാ വഴികളിലൂടെയും ഈ ചെലവുകൾ കുറയ്ക്കാൻ അവർ ശ്രമിക്കുന്നു. കമ്പനികൾ വിലകുറഞ്ഞ ഇന്നലത്തെ എനികെ തൊഴിലാളികളെ നിയമിക്കുകയും ധീരമായി യുദ്ധത്തിൽ ഏർപ്പെടുകയും ചെയ്യുന്നു. Zelenograd ലെ ഒരു പ്ലാന്റിന്റെ ഒരു ബിസിനസ് കാർഡ് വെബ്സൈറ്റിനെക്കുറിച്ചാണ് നമ്മൾ സംസാരിക്കുന്നതെങ്കിൽ ഈ തന്ത്രം സാധ്യമാണ്.

നമ്മൾ ഒരു വലിയ ഓൺലൈൻ സ്റ്റോറിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, ഒരു എനികെ അഡ്മിനിസ്ട്രേറ്ററുടെ പ്രതിമാസ ശമ്പളത്തേക്കാൾ കൂടുതൽ പ്രവർത്തനരഹിതമായ ഓരോ മണിക്കൂറും ചിലവാകും. വാർഷിക വിറ്റുവരവിന്റെ 1 ബില്യൺ റുബിളുകൾ ഒരു ആരംഭ പോയിന്റായി എടുക്കാം. റേറ്റിംഗിൽ നിന്നുള്ള ഏതൊരു ഓൺലൈൻ സ്റ്റോറിന്റെയും ഏറ്റവും കുറഞ്ഞ വിറ്റുവരവാണിത് 100-ലെ ടോപ്പ് 2018. ഈ തുക പ്രതിവർഷം മണിക്കൂറുകളുടെ എണ്ണം കൊണ്ട് ഹരിച്ച് 100 റുബിളിൽ കൂടുതൽ അറ്റ ​​നഷ്ടം നേടുക. നിങ്ങൾ രാത്രി സമയം കണക്കാക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് സുരക്ഷിതമായി തുക ഇരട്ടിയാക്കാം.

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

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

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

വികസന ടീമുമായുള്ള ആശയവിനിമയം

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

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

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

പുതിയ ഫീച്ചറുകൾ സൃഷ്‌ടിക്കുന്നതിനേക്കാൾ ഉൽപ്പാദനക്ഷമത പ്രശ്‌നങ്ങൾക്കാണ് മുൻഗണന നൽകുന്നത്. ഉപയോക്താക്കൾ ബഗുകളിൽ നിരന്തരം ഇടറിവീഴുകയാണെങ്കിൽ മോശം അവലോകനങ്ങൾ വരാൻ അധികനാളില്ല. കേടായ പ്രശസ്തി വീണ്ടെടുക്കാൻ പ്രയാസമാണ്.

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

ഈ സമീപനത്തിൽ, പിന്തുണയും വികസനവും സ്വന്തം ലക്ഷ്യങ്ങളും ലക്ഷ്യങ്ങളുമുള്ള വ്യത്യസ്ത വകുപ്പുകളല്ല. വികസനം പ്രവർത്തനത്തിൽ ഉൾപ്പെട്ടിരിക്കുന്നു, തിരിച്ചും. വിതരണം ചെയ്‌ത ടീമുകളുടെ പ്രസിദ്ധമായ വാചകം: “പ്രശ്‌നം എന്റെ ഭാഗത്തല്ല” എന്നത് ചാറ്റുകളിൽ ഇടയ്‌ക്കിടെ ദൃശ്യമാകില്ല, മാത്രമല്ല അന്തിമ ഉപയോക്താക്കൾ അൽപ്പം സന്തോഷവതിയാകും.

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