ഡെവലപ്പർമാർ ചൊവ്വയിൽ നിന്നുള്ളവരാണ്, അഡ്മിൻമാർ ശുക്രനിൽ നിന്നുള്ളവരാണ്

യാദൃശ്ചികതകൾ ക്രമരഹിതമാണ്, തീർച്ചയായും അത് മറ്റൊരു ഗ്രഹത്തിലായിരുന്നു...

ഒരു ബാക്കെൻഡ് ഡെവലപ്പർ അഡ്‌മിനുമൊത്തുള്ള ഒരു ടീമിൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള മൂന്ന് വിജയ-പരാജയ കഥകൾ പങ്കിടാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

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

+ എല്ലാ ശക്തിയും നിങ്ങളുടെ കൈകളിലാണ്.
+ സെർവറിലേക്കുള്ള പ്രവേശനത്തിനായി ആരോടും യാചിക്കേണ്ട ആവശ്യമില്ല.
+ എല്ലാ ദിശകളിലും വേഗത്തിലുള്ള പ്രതികരണ സമയം.
+ കഴിവുകൾ നന്നായി മെച്ചപ്പെടുത്തുന്നു.
+ ഉൽപ്പന്ന വാസ്തുവിദ്യയെക്കുറിച്ച് പൂർണ്ണമായ ധാരണ ഉണ്ടായിരിക്കുക.

- ഉയർന്ന ഉത്തരവാദിത്തം.
- ബ്രേക്കിംഗ് പ്രൊഡക്ഷൻ റിസ്ക്.
- എല്ലാ മേഖലകളിലും ഒരു നല്ല സ്പെഷ്യലിസ്റ്റ് ആകുന്നത് ബുദ്ധിമുട്ടാണ്.

താൽപ്പര്യമില്ല, നമുക്ക് മുന്നോട്ട് പോകാം

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

• ഉത്പാദനത്തിൽ ശരാശരി വിന്യാസ സമയം 4-5 മണിക്കൂറാണ്
• ഉൽപ്പാദനത്തിൽ പരമാവധി വിന്യാസ സമയം 9 മണിക്കൂർ
• ഒരു ഡെവലപ്പറെ സംബന്ധിച്ചിടത്തോളം, പ്രൊഡക്ഷൻ സെർവർ പോലെ തന്നെ ഒരു ബ്ലാക്ക് ബോക്സാണ് പ്രൊഡക്ഷനിലെ ആപ്ലിക്കേഷൻ. ആകെ എത്ര പേരുണ്ട്?
• റിലീസുകളുടെ കുറഞ്ഞ നിലവാരം, പതിവ് പിശകുകൾ
• ഡെവലപ്പർ റിലീസ് പ്രക്രിയയിൽ പങ്കെടുക്കുന്നില്ല

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

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

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

നിയമം 3, ചെറുത്
അടിയന്തിര ടിക്കറ്റ്, പ്രധാന പ്രവർത്തനം ഉൽപ്പാദനത്തിലെ ഉപയോക്താക്കളിൽ ഒരാൾക്ക് പ്രവർത്തിക്കില്ല. കുത്താനും പരിശോധിക്കാനും ഞങ്ങൾ രണ്ട് മണിക്കൂർ ചെലവഴിക്കുന്നു. ഒരു വികസന അന്തരീക്ഷത്തിൽ, എല്ലാം പ്രവർത്തിക്കുന്നു. php-fpm ലോഗുകൾ പരിശോധിക്കുന്നത് നല്ല ആശയമാണെന്ന് വ്യക്തമായ ധാരണയുണ്ട്. അക്കാലത്ത് ELK അല്ലെങ്കിൽ Prometheus പോലുള്ള ലോഗ് സിസ്റ്റങ്ങളൊന്നും പദ്ധതിയിൽ ഉണ്ടായിരുന്നില്ല. ഞങ്ങൾ അഡ്മിനിസ്ട്രേഷൻ ഡിപ്പാർട്ട്‌മെന്റിലേക്ക് ഒരു ടിക്കറ്റ് തുറക്കുന്നു, അതുവഴി അവർ സെർവറിലെ php-fpm ലോഗുകളിലേക്ക് പ്രവേശനം നൽകുന്നു. ഞങ്ങൾ ഒരു കാരണത്താലാണ് ആക്‌സസ്സ് ആവശ്യപ്പെടുന്നതെന്ന് ഇവിടെ നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്, തമോദ്വാരത്തെക്കുറിച്ചും അഡ്മിൻമാരും 24/7 തിരക്കിലായതിനെക്കുറിച്ച് നിങ്ങൾ ഓർക്കുന്നില്ലേ? ലോഗുകൾ സ്വയം നോക്കാൻ നിങ്ങൾ അവരോട് ആവശ്യപ്പെടുകയാണെങ്കിൽ, ഇത് "ഈ ജീവിതത്തിൽ അല്ല" എന്ന മുൻഗണനയുള്ള ഒരു ജോലിയാണ്. ടിക്കറ്റ് സൃഷ്ടിച്ചു, അഡ്മിനിസ്ട്രേഷൻ ഡിപ്പാർട്ട്‌മെന്റ് മേധാവിയിൽ നിന്ന് ഞങ്ങൾക്ക് ഒരു തൽക്ഷണ പ്രതികരണം ലഭിച്ചു: “നിങ്ങൾക്ക് പ്രൊഡക്ഷൻ ലോഗുകളിലേക്ക് ആക്‌സസ് ആവശ്യമില്ല, ബഗുകളില്ലാതെ എഴുതുക.” ഒരു തിരശ്ശീല.

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

രൂപാന്തരം.
ഇതെല്ലാം വളരെക്കാലം സഹിച്ചു, ടീമിനൊപ്പം ഞങ്ങൾ ഞങ്ങൾക്ക് കൂടുതൽ വിജയകരമായ ഒരു ദിശയിലേക്ക് നയിക്കാൻ തുടങ്ങി. ചുരുക്കിപ്പറഞ്ഞാൽ എന്തെല്ലാം പ്രശ്നങ്ങളാണ് നമ്മൾ നേരിട്ടത്?

• ഡെവലപ്പർമാരും അഡ്മിനിസ്‌ട്രേഷൻ വിഭാഗവും തമ്മിലുള്ള ഗുണനിലവാരമുള്ള ആശയവിനിമയത്തിന്റെ അഭാവം
• അഡ്മിനിസ്ട്രേറ്റർമാരേ, ഇത് മാറുന്നു(!), ആപ്ലിക്കേഷൻ എങ്ങനെയാണ് ഘടനാപരമായിരിക്കുന്നതെന്നും അതിന് എന്ത് ഡിപൻഡൻസികളുണ്ടെന്നും അത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും മനസ്സിലാകുന്നില്ല.
• ഉൽപ്പാദന അന്തരീക്ഷം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഡവലപ്പർമാർക്ക് മനസ്സിലാകുന്നില്ല, അതിന്റെ ഫലമായി പ്രശ്നങ്ങളോട് ഫലപ്രദമായി പ്രതികരിക്കാൻ കഴിയില്ല.
• വിന്യാസ പ്രക്രിയയ്ക്ക് വളരെയധികം സമയമെടുക്കും.
• അസ്ഥിരമായ റിലീസുകൾ.

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

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

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

ഉറവിടം: www.habr.com