അനാഥ സേവനങ്ങൾ: (മൈക്രോ) സേവന വാസ്തുവിദ്യയുടെ പോരായ്മ

Banki.ru പോർട്ടലിന്റെ ഓപ്പറേഷൻസ് ഡയറക്ടർ ആൻഡ്രി നിക്കോൾസ്കി കഴിഞ്ഞ വർഷത്തെ സമ്മേളനത്തിൽ സംസാരിച്ചു DevOpsDays മോസ്കോ അനാഥ സേവനങ്ങളെക്കുറിച്ച്: ഇൻഫ്രാസ്ട്രക്ചറിലെ ഒരു അനാഥനെ എങ്ങനെ തിരിച്ചറിയാം, അനാഥ സേവനങ്ങൾ എന്തുകൊണ്ട് മോശമാണ്, അവരുമായി എന്തുചെയ്യണം, ഒന്നും സഹായിക്കുന്നില്ലെങ്കിൽ എന്തുചെയ്യണം.

കട്ടിന് താഴെ റിപ്പോർട്ടിന്റെ ഒരു വാചക പതിപ്പ് ഉണ്ട്.

ഹലോ സഹപ്രവർത്തകരെ! എന്റെ പേര് ആൻഡ്രി, ഞാൻ Banki.ru-ൽ ഓപ്പറേഷൻസ് തലവൻ.

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

സേവനങ്ങളുടെ പ്രോസ്

സേവനങ്ങളുടെ ഗുണങ്ങളെക്കുറിച്ച് ഞാൻ വേഗത്തിൽ പരിശോധിക്കും.

ആദ്യത്തേത് സ്കെയിലിംഗ് ആണ്. നിങ്ങൾക്ക് വേഗത്തിൽ സേവനത്തിൽ എന്തെങ്കിലും ചെയ്യാനും ഉൽപ്പാദനം ആരംഭിക്കാനും കഴിയും. നിങ്ങൾക്ക് ട്രാഫിക് ലഭിച്ചു, നിങ്ങൾ സേവനം ക്ലോൺ ചെയ്തു. നിങ്ങൾക്ക് കൂടുതൽ ട്രാഫിക് ഉണ്ട്, നിങ്ങൾ അത് ക്ലോൺ ചെയ്‌ത് ജീവിക്കുക. ഇതൊരു നല്ല ബോണസാണ്, തത്വത്തിൽ, ഞങ്ങൾ ആരംഭിച്ചപ്പോൾ, ഇത് ഞങ്ങൾക്ക് ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യമായി കണക്കാക്കപ്പെട്ടു, എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഇതെല്ലാം ചെയ്യുന്നത്.

രണ്ടാമതായി, ഒറ്റപ്പെട്ട വികസനം, നിങ്ങൾക്ക് നിരവധി ഡവലപ്‌മെന്റ് ടീമുകൾ ഉള്ളപ്പോൾ, ഓരോ ടീമിലും നിരവധി വ്യത്യസ്ത ഡവലപ്പർമാർ, ഓരോ ടീമും അവരുടേതായ സേവനം വികസിപ്പിക്കുന്നു.

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

ചിത്രം നോക്കൂ: ഇതൊരു നല്ല ഡെവലപ്പറാണ്, അദ്ദേഹത്തിന് വലിയ കൈകളുണ്ട്, അവന് ഒരുപാട് ചെയ്യാൻ കഴിയും. ഈ കൈകൾ എവിടെ നിന്ന് വരുന്നു എന്നതാണ് പ്രധാന പ്രശ്നം.

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

സേവന-അധിഷ്ഠിത ആർക്കിടെക്ചർ പ്രാഥമികമായി devops ആണ്. അതായത്, നിങ്ങൾക്ക് ഓട്ടോമേഷൻ ഇല്ലെങ്കിൽ, വിന്യാസ പ്രക്രിയ ഇല്ല, നിങ്ങൾ അത് സ്വമേധയാ കോൺഫിഗർ ചെയ്യുകയാണെങ്കിൽ, നിങ്ങളുടെ കോൺഫിഗറേഷനുകൾ സേവന സന്ദർഭത്തിൽ നിന്ന് ഉദാഹരണത്തിലേക്ക് മാറാം, എന്തെങ്കിലും ചെയ്യാൻ നിങ്ങൾ അവിടെ പോകേണ്ടതുണ്ട്, അപ്പോൾ നിങ്ങൾ നരകത്തിലാണ്.

ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് 20 സേവനങ്ങളുണ്ട്, നിങ്ങൾക്ക് കൈകൊണ്ട് വിന്യസിക്കേണ്ടതുണ്ട്, നിങ്ങൾക്ക് 20 കൺസോളുകൾ ഉണ്ട്, നിങ്ങൾ ഒരേസമയം ഒരു നിൻജ പോലെ "enter" അമർത്തുക. അത് വളരെ നല്ലതല്ല.

പരിശോധനയ്ക്ക് ശേഷം നിങ്ങൾക്ക് ഒരു സേവനം ഉണ്ടെങ്കിൽ (തീർച്ചയായും ടെസ്റ്റിംഗ് ഉണ്ടെങ്കിൽ), നിങ്ങൾ ഇപ്പോഴും അത് ഒരു ഫയൽ ഉപയോഗിച്ച് പൂർത്തിയാക്കേണ്ടതുണ്ട്, അതുവഴി അത് നിർമ്മാണത്തിൽ പ്രവർത്തിക്കുന്നു, എനിക്ക് നിങ്ങൾക്കായി ഒരു മോശം വാർത്തയും ഉണ്ട്.

നിങ്ങൾ നിർദ്ദിഷ്ട ആമസോൺ സേവനങ്ങളെ ആശ്രയിക്കുകയും റഷ്യയിൽ ജോലി ചെയ്യുകയും ചെയ്യുന്നുവെങ്കിൽ, രണ്ട് മാസം മുമ്പ് നിങ്ങൾക്ക് "ചുറ്റുമുള്ളതെല്ലാം തീപിടിച്ചിരിക്കുന്നു, എനിക്ക് സുഖമാണ്, എല്ലാം ശാന്തമാണ്"

വിന്യാസം യാന്ത്രികമാക്കാൻ ഞങ്ങൾ അൻസിബിൾ, ഒത്തുചേരലിനുള്ള പപ്പറ്റ്, വിന്യാസം ഓട്ടോമേറ്റ് ചെയ്യാൻ മുള, എങ്ങനെയെങ്കിലും എല്ലാം വിവരിക്കാൻ കൺഫ്ലൂയൻസ് എന്നിവ ഉപയോഗിക്കുന്നു.

ഞാൻ ഇതിനെക്കുറിച്ച് വിശദമായി സംസാരിക്കില്ല, കാരണം റിപ്പോർട്ട് കൂടുതൽ ആശയവിനിമയ രീതികളെക്കുറിച്ചാണ്, അല്ലാതെ സാങ്കേതിക നിർവ്വഹണത്തെക്കുറിച്ചല്ല.

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

ഉദാഹരണത്തിന്, ഓരോ ഡവലപ്പർക്കും ഞങ്ങൾ ഒരു പ്ലാറ്റ്ഫോം നൽകുന്നു, അതിൽ ഞങ്ങളുടെ പക്കലുള്ള ഏകദേശം എല്ലാം ഉണ്ട്, വികസിപ്പിക്കാൻ കഴിയുന്ന എല്ലാ സേവനങ്ങളും, അങ്ങനെ അയാൾക്ക് ഒരു ഒറ്റപ്പെട്ട അന്തരീക്ഷമുണ്ട്, അയാൾക്ക് അത് തകർക്കാനും അവൻ ആഗ്രഹിക്കുന്നതുപോലെ അത് നിർമ്മിക്കാനും കഴിയും.

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

ശരി, പരസ്പരവിരുദ്ധമായ ആശ്രിതത്വങ്ങളുണ്ട്, പ്രോജക്റ്റിന്റെ ഒരു ഭാഗം ഒരു പതിപ്പിന്റെ ലൈബ്രറിയെ ആശ്രയിക്കുമ്പോൾ, പ്രോജക്റ്റിന്റെ മറ്റൊരു ഭാഗം മറ്റൊരു പതിപ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു, കൂടാതെ ലൈബ്രറികൾ ഒരുമിച്ച് ഇൻസ്റ്റാൾ ചെയ്തിട്ടില്ല.

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

നിങ്ങൾ ഒരു കമ്പനിയിൽ ഒരു ഭാഷയിൽ എഴുതുകയാണെങ്കിൽ, ഓരോ ഡവലപ്പർക്കും മൂന്ന് വെർച്വൽ മെഷീനുകൾ സാധാരണമാണെന്ന് തോന്നുന്നു. നിങ്ങൾക്ക് വ്യത്യസ്ത പ്രോഗ്രാമിംഗ് ഭാഷകളുണ്ടെങ്കിൽ, സ്ഥിതി കൂടുതൽ വഷളാകുന്നു.

നിങ്ങൾക്ക് ഇതിൽ സൈറ്റുകളും സേവനങ്ങളും ഉണ്ട്, ഇതിൽ, Go-യ്‌ക്ക് മറ്റൊരു സൈറ്റ്, റൂബിക്ക് ഒരു സൈറ്റ്, വശത്ത് മറ്റ് ചില റെഡികൾ. തൽഫലമായി, ഇതെല്ലാം പിന്തുണയ്‌ക്കുള്ള ഒരു വലിയ ഫീൽഡായി മാറുന്നു, എല്ലായ്‌പ്പോഴും അതിൽ ചിലത് തകർക്കാൻ കഴിയും.

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

ഓരോ സേവനത്തിനും അതിന്റേതായ ടീം ഉണ്ട്

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

പിന്തുണയിൽ നിന്ന് നിങ്ങൾക്ക് എളുപ്പത്തിൽ ടാസ്‌ക്കുകൾ സമർപ്പിക്കാനാകും. ഉദാഹരണത്തിന്, ഇൻഷുറൻസ് സേവനം തകർന്നു. ഉടൻ തന്നെ ഇൻഷുറൻസ് കൈകാര്യം ചെയ്യുന്ന ടീം അത് പരിഹരിക്കാൻ പോകുന്നു.

പുതിയ സവിശേഷതകൾ വേഗത്തിൽ സൃഷ്ടിക്കപ്പെടുന്നു, കാരണം നിങ്ങൾക്ക് ഒരു ആറ്റോമിക് സേവനം ഉള്ളപ്പോൾ, നിങ്ങൾക്ക് വേഗത്തിൽ എന്തെങ്കിലും സ്ക്രൂ ചെയ്യാൻ കഴിയും.

നിങ്ങളുടെ സേവനം നിങ്ങൾ തകർക്കുമ്പോൾ, ഇത് അനിവാര്യമായും സംഭവിക്കുമ്പോൾ, നിങ്ങൾ മറ്റുള്ളവരുടെ സേവനങ്ങളെ ബാധിച്ചില്ല, മറ്റ് ടീമുകളിൽ നിന്നുള്ള ഡെവലപ്പർമാർ നിങ്ങളുടെ അടുത്തേക്ക് ബിറ്റുകൾ ഉപയോഗിച്ച് ഓടിവന്ന് പറയില്ല: "അയ്യോ, അത് ചെയ്യരുത്."

എല്ലായ്പ്പോഴും എന്നപോലെ, സൂക്ഷ്മതകളുണ്ട്. ഞങ്ങൾക്ക് സുസ്ഥിരമായ ടീമുകളുണ്ട്, മാനേജർമാർ ടീമിൽ പെടുന്നു. വ്യക്തമായ രേഖകളുണ്ട്, മാനേജർമാർ എല്ലാം സൂക്ഷ്മമായി നിരീക്ഷിക്കുന്നു. ഒരു മാനേജരുള്ള ഓരോ ടീമിനും നിരവധി സേവനങ്ങളുണ്ട്, കൂടാതെ ഒരു പ്രത്യേക കഴിവുണ്ട്.

ടീമുകൾ ഫ്ലോട്ടിംഗ് ആണെങ്കിൽ (ഞങ്ങളും ചിലപ്പോൾ ഇത് ഉപയോഗിക്കാറുണ്ട്), "സ്റ്റാർ മാപ്പ്" എന്ന് വിളിക്കുന്ന ഒരു നല്ല രീതിയുണ്ട്.

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

അനാഥ സേവനങ്ങൾ എങ്ങനെയാണ് ദൃശ്യമാകുന്നത്?

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

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

അതേ സമയം, പിന്തുണയിൽ നിന്നും ബിസിനസ്സിൽ നിന്നുമുള്ള ചുമതലകൾ അപ്രത്യക്ഷമാകുന്നില്ല; അവ ബാക്ക്‌ലോഗിൽ അവസാനിക്കുന്നു. സർവീസ് വികസിപ്പിക്കുന്ന സമയത്ത് എന്തെങ്കിലും വാസ്തു പിഴവുകൾ ഉണ്ടായാൽ, അവയും ബാക്ക്ലോഗിൽ അവസാനിക്കുന്നു. സേവനം പതുക്കെ മോശമാവുകയാണ്.

ഒരു അനാഥനെ എങ്ങനെ തിരിച്ചറിയാം?

ഈ പട്ടിക സാഹചര്യം നന്നായി വിവരിക്കുന്നു. അവരുടെ അടിസ്ഥാന സൗകര്യങ്ങളെക്കുറിച്ച് ആരാണ് എന്തെങ്കിലും പഠിച്ചത്?

ഡോക്യുമെന്റ് ചെയ്ത പ്രവർത്തനങ്ങളെക്കുറിച്ച്: ഒരു സേവനമുണ്ട്, പൊതുവേ, ഇത് പ്രവർത്തിക്കുന്നു, അത് എങ്ങനെ പ്രവർത്തിക്കണം എന്നതിനെക്കുറിച്ചുള്ള രണ്ട് പേജുള്ള മാനുവൽ ഇതിന് ഉണ്ട്, എന്നാൽ ഇത് ഉള്ളിൽ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ആർക്കും അറിയില്ല.

അല്ലെങ്കിൽ, ഉദാഹരണത്തിന്, ഒരു തരത്തിലുള്ള ലിങ്ക് ഷോർട്ട്നർ ഉണ്ട്. ഉദാഹരണത്തിന്, വ്യത്യസ്‌ത സേവനങ്ങളിൽ വ്യത്യസ്‌ത ആവശ്യങ്ങൾക്കായി ഞങ്ങൾക്ക് നിലവിൽ മൂന്ന് ലിങ്ക് ഷോർട്ട്‌നറുകൾ ഉപയോഗത്തിലുണ്ട്. ഇതെല്ലാം അനന്തരഫലങ്ങൾ മാത്രമാണ്.

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

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

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

ഉദാഹരണത്തിന്, ഞങ്ങൾ അപ്രതീക്ഷിതമായ വിവിധ സ്ഥലങ്ങളിൽ സ്ഫിങ്ക്സ് ഉള്ള ഒരു സേവനം ഉണ്ടായിരുന്നു. ഞാൻ എന്താണ് ചെയ്യേണ്ടതെന്ന് പിന്നീട് പറയാം.

ഔട്ട്‌സോഴ്‌സർമാർക്ക് സ്വയം എഴുതിയ ചട്ടക്കൂടുകൾ ഉണ്ട്. മുമ്പത്തെ പ്രോജക്‌റ്റിൽ നിന്ന് കോപ്പി-പേസ്റ്റ് ഉള്ള വെറും PHP മാത്രമാണിത്, അവിടെ നിങ്ങൾക്ക് എല്ലാത്തരം കാര്യങ്ങളും കണ്ടെത്താനാകും. ചില ഫയലുകളിൽ നിരവധി വരികൾ മാറ്റാൻ ചില സങ്കീർണ്ണമായ ബാഷ് സ്ക്രിപ്റ്റുകൾ ഉപയോഗിക്കേണ്ടിവരുമ്പോൾ വിന്യാസ സ്ക്രിപ്റ്റുകൾ ഒരു വലിയ പോരായ്മയാണ്, ഈ വിന്യാസ സ്ക്രിപ്റ്റുകളെ ഏതെങ്കിലും മൂന്നാം സ്ക്രിപ്റ്റ് എന്ന് വിളിക്കുന്നു. ഫലമായി, നിങ്ങൾ വിന്യാസ സംവിധാനം മാറ്റുക, മറ്റെന്തെങ്കിലും തിരഞ്ഞെടുക്കുക, ഹോപ്പ് ചെയ്യുക, എന്നാൽ നിങ്ങളുടെ സേവനം പ്രവർത്തിക്കുന്നില്ല. കാരണം അവിടെ വ്യത്യസ്ത ഫോൾഡറുകൾക്കിടയിൽ 8 ലിങ്കുകൾ കൂടി ഇടേണ്ടതായി വന്നു. അല്ലെങ്കിൽ ആയിരം റെക്കോർഡുകൾ പ്രവർത്തിക്കുന്നു, പക്ഷേ ഒരു ലക്ഷം ഇനി പ്രവർത്തിക്കില്ല.

ഞാൻ ക്യാപ്റ്റനായി തുടരും. ഒരു ഔട്ട്‌സോഴ്‌സ് സേവനം സ്വീകരിക്കുന്നത് നിർബന്ധിത നടപടിക്രമമാണ്. ആരെങ്കിലും എപ്പോഴെങ്കിലും ഔട്ട്‌സോഴ്‌സ് ചെയ്‌ത സേവനം വന്നിട്ടുണ്ടോ, എവിടെയും സ്വീകരിക്കപ്പെടാതെ പോയിട്ടുണ്ടോ? ഇത് ഒരു അനാഥ സേവനം പോലെ ജനപ്രിയമല്ല, പക്ഷേ ഇപ്പോഴും.

സേവനം പരിശോധിക്കേണ്ടതുണ്ട്, സേവനം അവലോകനം ചെയ്യേണ്ടതുണ്ട്, പാസ്‌വേഡുകൾ മാറ്റേണ്ടതുണ്ട്. അവർ ഞങ്ങൾക്ക് ഒരു സേവനം നൽകിയപ്പോൾ ഞങ്ങൾക്ക് ഒരു കേസ് ഉണ്ടായിരുന്നു, ഒരു അഡ്മിൻ പാനൽ ഉണ്ട് “ലോഗിൻ ചെയ്താൽ == 'അഡ്മിൻ' && പാസ്‌വേഡ് == 'അഡ്മിൻ'...", അത് കോഡിൽ തന്നെ എഴുതിയിരിക്കുന്നു. ഞങ്ങൾ ഇരുന്നു ചിന്തിക്കുന്നു, ആളുകൾ ഇത് 2018 ൽ എഴുതുന്നുണ്ടോ?

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

മെച്ചപ്പെടുത്തലിനായി ഒരു സേവനം അയയ്ക്കുന്നതിൽ ലജ്ജിക്കേണ്ട കാര്യമില്ല. നിങ്ങൾ പറയുമ്പോൾ: "ഞങ്ങൾ ഈ സേവനം സ്വീകരിക്കില്ല, ഞങ്ങൾക്ക് 20 ടാസ്ക്കുകൾ ഉണ്ട്, അവ ചെയ്യുക, ഞങ്ങൾ സ്വീകരിക്കും," ഇത് സാധാരണമാണ്. നിങ്ങൾ ഒരു മാനേജരെ സജ്ജീകരിക്കുന്നുവെന്നോ ബിസിനസ്സ് പണം പാഴാക്കുന്നുവെന്നോ നിങ്ങളുടെ മനസ്സാക്ഷിയെ വേദനിപ്പിക്കരുത്. ബിസിനസ്സ് പിന്നീട് കൂടുതൽ ചെലവഴിക്കും.

ഒരു പൈലറ്റ് പ്രോജക്റ്റ് ഔട്ട്സോഴ്സ് ചെയ്യാൻ തീരുമാനിച്ചപ്പോൾ ഞങ്ങൾക്ക് ഒരു കേസ് ഉണ്ടായിരുന്നു.

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

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

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

അനാഥർക്ക് എന്താണ് പ്രശ്നം?

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

കപ്പൽ വളരെ മോശമായ രീതിയിൽ മുങ്ങിയിരിക്കാം, ഉദാഹരണത്തിന്, രാജാവ് ഇതിനകം കൊടുങ്കാറ്റിൽ എവിടെയെങ്കിലും അതിൽ കയറുമ്പോൾ. അതിനാൽ, അവൻ ഉടൻ തന്നെ മുങ്ങിമരിച്ചു, എജൈലിന്റെ അഭിപ്രായത്തിൽ നേരത്തെ പരാജയപ്പെടുന്നത് നല്ലതാണ്.

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

എന്തുകൊണ്ടാണ് അനാഥ സേവനങ്ങൾ അപകടകരമാകുന്നത്:

• സർവീസ് പെട്ടെന്ന് തകരാറിലായേക്കാം.
• സേവനം നന്നാക്കാൻ വളരെ സമയമെടുക്കുന്നു അല്ലെങ്കിൽ നന്നാക്കുന്നില്ല.
• സുരക്ഷാ പ്രശ്നങ്ങൾ.
• മെച്ചപ്പെടുത്തലുകളിലും അപ്ഡേറ്റുകളിലും പ്രശ്നങ്ങൾ.
• ഒരു പ്രധാന സേവനം തകരാറിലായാൽ, കമ്പനിയുടെ പ്രശസ്തി ബാധിക്കപ്പെടും.

അനാഥ സേവനങ്ങളുമായി എന്തുചെയ്യണം?

എന്തുചെയ്യണമെന്ന് ഞാൻ വീണ്ടും ആവർത്തിക്കും. ആദ്യം, ഡോക്യുമെന്റേഷൻ ഉണ്ടായിരിക്കണം. 7 വർഷം Banki.ru- ൽ ടെസ്റ്റർമാർ ഡവലപ്പർമാരുടെ വാക്ക് എടുക്കരുതെന്നും പ്രവർത്തനങ്ങൾ എല്ലാവരുടെയും വാക്ക് എടുക്കരുതെന്നും എന്നെ പഠിപ്പിച്ചു. നമുക്ക് പരിശോധിക്കേണ്ടതുണ്ട്.

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

മൂന്നാമതായി, സാങ്കേതിക കടവുമായി പ്രവർത്തിക്കുന്നു. നിങ്ങൾ ഏതെങ്കിലും തരത്തിലുള്ള ഊന്നുവടികൾ ചെയ്യുമ്പോഴോ ഒരു സേവനം സ്വീകരിക്കുമ്പോഴോ എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ടെന്ന് പറയുമ്പോൾ, അത് ചെയ്തുവെന്ന് നിങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട്. കാരണം, ചെറിയ ദ്വാരം അത്ര ചെറുതല്ലെന്ന് അത് മാറിയേക്കാം, നിങ്ങൾ അതിലൂടെ വീഴും.

വാസ്തുവിദ്യാ ജോലികൾക്കൊപ്പം, ഞങ്ങൾക്ക് സ്ഫിങ്ക്സിനെക്കുറിച്ചുള്ള ഒരു കഥ ഉണ്ടായിരുന്നു. സേവനങ്ങളിലൊന്ന് ലിസ്റ്റുകളിൽ പ്രവേശിക്കാൻ സ്ഫിങ്ക്സ് ഉപയോഗിച്ചു. ഒരു പേജ് ചെയ്‌ത ലിസ്‌റ്റ് മാത്രം, എന്നാൽ എല്ലാ രാത്രിയിലും അത് വീണ്ടും സൂചികയിലാക്കി. ഇത് രണ്ട് സൂചികകളിൽ നിന്ന് സമാഹരിച്ചു: എല്ലാ രാത്രിയിലും ഒരു വലിയ സൂചിക സൂചികയിലാക്കി, അതിൽ ഒരു ചെറിയ സൂചികയും ഉണ്ടായിരുന്നു. എല്ലാ ദിവസവും, ഒന്നുകിൽ ബോംബ് സ്‌ഫോടനമോ ഇല്ലയോ എന്നതിന്റെ 50% സാധ്യതയുള്ളതിനാൽ, കണക്കുകൂട്ടൽ സമയത്ത് സൂചിക തകർന്നു, ഞങ്ങളുടെ വാർത്തകൾ പ്രധാന പേജിൽ അപ്‌ഡേറ്റ് ചെയ്യുന്നത് നിർത്തി. ആദ്യം സൂചിക വീണ്ടും സൂചികയിലാക്കാൻ 5 മിനിറ്റ് എടുത്തു, പിന്നീട് സൂചിക വളർന്നു, ചില ഘട്ടങ്ങളിൽ വീണ്ടും സൂചിക 40 മിനിറ്റ് എടുക്കാൻ തുടങ്ങി. ഞങ്ങൾ ഇത് വെട്ടിക്കളഞ്ഞപ്പോൾ, ഞങ്ങൾ ആശ്വാസത്തിന്റെ നെടുവീർപ്പിട്ടു, കാരണം കുറച്ച് സമയം കൂടി കടന്നുപോകുമെന്നും ഞങ്ങളുടെ സൂചിക മുഴുവൻ സമയവും വീണ്ടും സൂചികയിലാക്കുമെന്നും വ്യക്തമായിരുന്നു. ഇത് ഞങ്ങളുടെ പോർട്ടലിന് ഒരു പരാജയമായിരിക്കും, എട്ട് മണിക്കൂർ ഒരു വാർത്തയും ഇല്ല - അതാണ്, ബിസിനസ്സ് നിർത്തി.

ഒരു അനാഥ സേവനവുമായി പ്രവർത്തിക്കാനുള്ള പദ്ധതി

വാസ്തവത്തിൽ, ഇത് ചെയ്യാൻ വളരെ ബുദ്ധിമുട്ടാണ്, കാരണം devops ആശയവിനിമയത്തെക്കുറിച്ചാണ്. നിങ്ങളുടെ സഹപ്രവർത്തകരുമായി നല്ല ബന്ധത്തിലായിരിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു, നിങ്ങളുടെ സഹപ്രവർത്തകരെയും മാനേജർമാരെയും നിയന്ത്രണങ്ങൾ കൊണ്ട് തലയ്ക്ക് മുറുകെ പിടിക്കുമ്പോൾ, ഇത് ചെയ്യുന്നവരോട് അവർക്ക് പരസ്പരവിരുദ്ധമായ വികാരങ്ങൾ ഉണ്ടായേക്കാം.

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

ഇതെല്ലാം സഹായിച്ചില്ലെങ്കിൽ, നിങ്ങളുടെ അനാഥ സേവനം ഇപ്പോഴും അനാഥമാണെങ്കിൽ, ആരും അത് ഏറ്റെടുക്കാൻ ആഗ്രഹിക്കുന്നില്ല, ഡോക്യുമെന്റേഷൻ എഴുതിയിട്ടില്ല, ഈ സേവനത്തിലേക്ക് വിളിച്ച ടീം ഒന്നും ചെയ്യാൻ വിസമ്മതിക്കുന്നു, ഒരു ലളിതമായ മാർഗമുണ്ട് - വീണ്ടും ചെയ്യാൻ എല്ലാം .

അതായത്, നിങ്ങൾ സേവനത്തിനായുള്ള ആവശ്യകതകൾ പുതുതായി എടുക്കുകയും വിചിത്രമായ സാങ്കേതിക പരിഹാരങ്ങളില്ലാതെ മികച്ച പ്ലാറ്റ്‌ഫോമിൽ ഒരു പുതിയ സേവനം എഴുതുകയും ചെയ്യുന്നു. നിങ്ങൾ യുദ്ധത്തിൽ അതിലേക്ക് പലായനം ചെയ്യുന്നു.

Yii 1-ൽ ഞങ്ങൾ ഒരു സേവനം എടുക്കുകയും അത് കൂടുതൽ വികസിപ്പിക്കാൻ കഴിയില്ലെന്ന് മനസ്സിലാക്കുകയും ചെയ്തപ്പോൾ ഞങ്ങൾക്ക് ഒരു സാഹചര്യമുണ്ടായി, കാരണം Yii 1-ൽ നന്നായി എഴുതാൻ കഴിയുന്ന ഡെവലപ്പർമാരില്ല. എല്ലാ ഡെവലപ്പർമാരും സിംഫോണി XNUMX-ൽ നന്നായി എഴുതുന്നു. എന്തുചെയ്യും? ഞങ്ങൾ സമയം അനുവദിച്ചു, ഒരു ടീമിനെ അനുവദിച്ചു, ഒരു മാനേജരെ അനുവദിച്ചു, പ്രോജക്റ്റ് മാറ്റിയെഴുതി, അതിലേക്ക് ട്രാഫിക് സുഗമമായി മാറ്റി.

ഇതിനുശേഷം, പഴയ സേവനം ഇല്ലാതാക്കാൻ കഴിയും. കോൺഫിഗറേഷൻ മാനേജുമെന്റ് സിസ്റ്റത്തിൽ നിന്ന് നിങ്ങൾക്ക് കുറച്ച് സേവനം എടുത്ത് വൃത്തിയാക്കേണ്ടിവരുമ്പോൾ ഇത് എന്റെ പ്രിയപ്പെട്ട നടപടിക്രമമാണ്, തുടർന്ന് ഡവലപ്പർമാർക്ക് അവശേഷിക്കാത്ത തരത്തിൽ ഉൽപ്പാദനത്തിലുള്ള എല്ലാ കാറുകളും പ്രവർത്തനരഹിതമാക്കിയിരിക്കുന്നു. ശേഖരം Git-ൽ അവശേഷിക്കുന്നു.

ഞാൻ സംസാരിക്കാൻ ആഗ്രഹിച്ചത് ഇതാണ്, ചർച്ച ചെയ്യാൻ ഞാൻ തയ്യാറാണ്, വിഷയം ഹോളിവർ ആണ്, പലരും അതിൽ നീന്തി.

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

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

ഞങ്ങൾ നിലവിൽ Node.js-ൽ ഒരു സേവനം നിർമ്മിക്കുകയാണ്, ഇത് ഓരോ ഡെവലപ്പർക്കും ഒരു പ്രത്യേക ഭാഷയുള്ള അടുത്തുള്ള ഒരു പ്ലാറ്റ്ഫോം മാത്രമായിരിക്കും. പക്ഷേ ഞങ്ങൾ ഇരുന്നു, കളി മെഴുകുതിരിയുടെ വിലയാണെന്ന് ഞങ്ങൾ കരുതി. അതായത് നിങ്ങൾ ഇരുന്ന് ചിന്തിക്കേണ്ട ചോദ്യമാണിത്.

നിങ്ങളുടെ സേവനങ്ങൾ എങ്ങനെയാണ് നിരീക്ഷിക്കുന്നത്? എങ്ങനെയാണ് നിങ്ങൾ ലോഗുകൾ ശേഖരിക്കുകയും നിരീക്ഷിക്കുകയും ചെയ്യുന്നത്?

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

ഒരേ പരിതസ്ഥിതിയിൽ പപ്പറ്റും അൻസിബിളുമായി എങ്ങനെ ജീവിക്കാം?

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

നിങ്ങൾ എങ്ങനെയാണ് അനുയോജ്യത നിലനിർത്തുന്നത്? അൻസിബിളിലും പപ്പറ്റിലും നിങ്ങൾക്ക് കോൺഫിഗറുകളുണ്ടോ?

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

റൂബിയുടെ വിവിധ പതിപ്പുകളെ കുറിച്ചായിരുന്നു അവതരണം. എന്ത് പരിഹാരം?

ഞങ്ങൾ ഇത് ഒരിടത്ത് കണ്ടുമുട്ടി, അത് എല്ലായ്പ്പോഴും നമ്മുടെ തലയിൽ സൂക്ഷിക്കണം. ആപ്ലിക്കേഷനുകളുമായി പൊരുത്തപ്പെടാത്ത റൂബിയിൽ ഓടുന്ന ഭാഗം ഞങ്ങൾ ഓഫാക്കി പ്രത്യേകം സൂക്ഷിച്ചു.

ഈ വർഷത്തെ സമ്മേളനം DevOpsDays മോസ്കോ ഡിസംബർ 7 ന് ടെക്നോപോളിസിൽ നടക്കും. നവംബർ 11 വരെ റിപ്പോർട്ടുകൾക്കായുള്ള അപേക്ഷകൾ ഞങ്ങൾ സ്വീകരിക്കുന്നു. എഴുതുക നിങ്ങൾക്ക് സംസാരിക്കാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ ഞങ്ങളോട്.

പങ്കെടുക്കുന്നവർക്കുള്ള രജിസ്ട്രേഷൻ തുറന്നിരിക്കുന്നു, ഞങ്ങളോടൊപ്പം ചേരൂ!

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