മെയിലിംഗ് ലിസ്റ്റിൽ നിന്ന് അൺസബ്‌സ്‌ക്രൈബ് ചെയ്യാൻ കുറച്ച് ദിവസമെടുക്കുന്നത് എന്തുകൊണ്ട്?

അൺസബ്‌സ്‌ക്രൈബുചെയ്യുന്നതിന് “ദിവസങ്ങളെടുക്കുന്നത്” എന്തുകൊണ്ടാണെന്ന് ഒരു ട്വീറ്റ് ചോദിച്ചു. മുറുകെ പിടിക്കുക, ഞാൻ നിങ്ങളോട് പറയാൻ പോകുന്നു അവിശ്വസനീയമായ എന്റർപ്രൈസ് ഡെവലപ്‌മെന്റ്™-ൽ ഇത് എങ്ങനെ ചെയ്തു എന്നതിന്റെ കഥ...

ഒരു ബാങ്ക് ഉണ്ട്. നിങ്ങൾ ഇതിനെക്കുറിച്ച് കേട്ടിരിക്കാം, നിങ്ങൾ യുകെയിലാണ് താമസിക്കുന്നതെങ്കിൽ, അതിനുള്ള സാധ്യത 10% ആണ് നിങ്ങളുടെ ബാങ്ക്. മികച്ച ശമ്പളത്തിന് ഞാൻ അവിടെ "കൺസൾട്ടന്റ്" ആയി ജോലി ചെയ്തു.

ബാങ്ക് മാർക്കറ്റിംഗ് കത്തുകൾ അയയ്ക്കുന്നു. ഓരോ ഇമെയിലിന്റെയും അടിക്കുറിപ്പിൽ ഒരു ചെറിയ "അൺസബ്‌സ്‌ക്രൈബ്" ലിങ്ക് ഉണ്ട്. ആളുകൾ ചിലപ്പോൾ ഈ ലിങ്കുകളിൽ ക്ലിക്ക് ചെയ്യാറുണ്ട്.

ഒരു ലിങ്കിൽ ക്ലിക്കുചെയ്യുന്നത് ഒരു ചരിത്രാതീത വെബ് സെർവർ കറങ്ങുന്നതിന് കാരണമാകുന്നു എവിടെയോ ബാങ്കിൽ. സത്യസന്ധമായി, അവനെ കണ്ടെത്താൻ എനിക്ക് മൂന്നാഴ്ചയെടുത്തു.

ഓരോ തവണയും ഒരു ലിങ്ക് ക്ലിക്ക് ചെയ്യുമ്പോൾ ഈ സേവനം നിങ്ങളുടെ ആന്തരിക ഇൻബോക്സിലേക്ക് ഒരു ഇമെയിൽ അയയ്ക്കുന്നു. ഇത് ദിവസത്തിൽ നൂറുകണക്കിന് തവണ സംഭവിക്കുന്നു.

മുമ്പ്, ഈ കത്തുകൾ ഒരു നിർദ്ദിഷ്ട ജീവനക്കാരന് അയച്ചിരുന്നു, എന്നാൽ അഞ്ച് വർഷം മുമ്പ് അദ്ദേഹം പോയി.

ഇപ്പോൾ കത്ത് വിതരണ ഗ്രൂപ്പിന് കൈമാറി. അവർക്ക് സ്വീകർത്താവിന്റെ വിലാസം മാറ്റാൻ കഴിഞ്ഞില്ല, കാരണം അത് ഹാർഡ്‌കോഡ് ചെയ്‌തിരുന്നു, മാത്രമല്ല അവർക്ക് സേവനത്തിൽ നിന്ന് സോഴ്‌സ് കോഡ് കണ്ടെത്താനാകാത്തതുമാണ്. സേവനം ജാവ 6 ൽ എഴുതിയിരിക്കുന്നു.

മെയിലിംഗ് ഗ്രൂപ്പിലെ കത്തുകൾ ബാങ്കിന്റെ ഹൈദരാബാദിലെ (ഇന്ത്യയിൽ) ഓഫ്‌ഷോർ സെന്ററിലെ രണ്ട് ജീവനക്കാർ പരിശോധിക്കുന്നു. അവർ കഠിനാധ്വാനം ചെയ്യുകയും അവരുടെ ജോലികൾ പൂർത്തിയാക്കുകയും ചെയ്യുന്നു ഗംഭീരം, പക്ഷേ നാശം, ഈ ജോലി അസഹനീയമാണ്.

ഞാൻ അവരുമായി വീഡിയോ കോൺഫറൻസ് വഴി ആശയവിനിമയം നടത്തി, അവർക്ക് എന്റർപ്രൈസ്-പോസ്റ്റ് ട്രോമാറ്റിക് സിൻഡ്രോമിന്റെ എല്ലാ ലക്ഷണങ്ങളും ഉണ്ടായിരുന്നു. അവർ ഈ വിഡ്ഢിത്തത്തോട് പോരാടി വര്ഷങ്ങളായി ഈ സമയത്തും ഒന്നും മാറിയിട്ടില്ല.

ഒരു കത്ത് വരുമ്പോൾ, അൺസബ്‌സ്‌ക്രൈബ് ചെയ്യുന്ന വിലാസം ബാങ്ക് ക്ലയന്റുടേതാണോ (അപ്പോൾ പ്രോട്ടോക്കോൾ ഒന്നാണോ) അല്ലെങ്കിൽ (പിന്നെ മറ്റൊന്ന്) എന്ന് നിർണ്ണയിക്കുന്ന ഒരു SQL സ്ക്രിപ്റ്റ് അവർ എക്സിക്യൂട്ട് ചെയ്യണം.

സ്വീകർത്താവ് ഒരു ഉപഭോക്താവാണെങ്കിൽ, അവർ പ്രീ-ഇടിഎൽ പരിതസ്ഥിതിയിൽ ഉപഭോക്തൃ റെക്കോർഡ് അപ്ഡേറ്റ് ചെയ്യുന്ന മറ്റൊരു SQL സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്. എല്ലാ മാറ്റങ്ങളും ലണ്ടൻ സമയം 16:00 ന് സ്‌കോട്ട്‌ലൻഡിലെ ഒരു പ്രത്യേക ടീം അവലോകനം ചെയ്യുന്നു. മാറ്റങ്ങൾ പരിശോധിച്ചുറപ്പിക്കുകയാണെങ്കിൽ, അവ യഥാർത്ഥ ഡാറ്റാബേസിലേക്ക് പ്രയോഗിക്കും മറ്റൊരു ദിവസം 16:00 ന്.

സ്വീകർത്താവ് ഒരു ക്ലയന്റല്ലെങ്കിൽ, അവർ അത് ഒരു Excel സ്‌പ്രെഡ്‌ഷീറ്റിലേക്ക് ചേർക്കുകയും വീട്ടിലേക്ക് പോകുന്നതിന് മുമ്പ് Swindon ലെ മാർക്കറ്റിംഗ് ടീമിന് അയയ്ക്കുകയും ചെയ്യും.

മാർക്കറ്റിംഗ് ടീം, ചായ ഇലകളും മറ്റ് നിഗൂഢ പരിശീലനങ്ങളും ഉപയോഗിച്ച്, ക്ലയന്റ് "സാധ്യതയുള്ള പ്രാധാന്യമുള്ളയാളാണോ" എന്ന് നിർണ്ണയിക്കുന്നു (ഇതിന്, ആന്തരിക നിയന്ത്രണങ്ങൾ അനുസരിച്ച്, "48 മണിക്കൂർ വരെ"). ഇല്ലെങ്കിൽ, വിലാസം മറ്റൊരു പട്ടികയിലേക്ക് ചേർക്കുകയും മറ്റൊരു SQL അന്വേഷണം നടപ്പിലാക്കുന്നതിനായി ഇന്ത്യയിലേക്ക് തിരികെ അയയ്ക്കുകയും ചെയ്യും.

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

അവർ "അതെ" എന്ന് ഉത്തരം നൽകിയാൽ (തുടക്കത്തിൽ "അതെ" എന്ന് വലിയ അക്ഷരങ്ങളിൽ എഴുതേണ്ടതായിരുന്നു), പിന്നീട് സ്വിൻഡനിൽ നിന്നുള്ള ടീം അവരെ ഇന്ത്യയിലേക്ക് അയയ്ക്കുന്നു. മൂന്നാമത് പട്ടികയും അവിടെ അടുത്ത സ്ക്രിപ്റ്റ് ഗംഭീരമായി എക്സിക്യൂട്ട് ചെയ്യുന്നു.

ഞാൻ ശരിയായി ഓർക്കുന്നുവെങ്കിൽ, അത് ശരാശരി എടുക്കും നാല് പ്രവൃത്തി ദിനങ്ങൾ. പ്രതിദിനം ശരാശരി 700 പേർ അൺസബ്‌സ്‌ക്രൈബുചെയ്യുന്നു, അതിൽ 70% "സാധ്യതയുള്ളതാണ്".

വഴിയിൽ, ഈ രണ്ട് ഇന്ത്യക്കാരും ഞങ്ങളുടെ ഡെവലപ്‌മെന്റ് ടീമിലേക്ക് മാറ്റി, ഈ വിഡ്ഢിത്തങ്ങളെയെല്ലാം മാറ്റിസ്ഥാപിച്ച സിസ്റ്റത്തിന്റെ പ്രധാനമന്ത്രിമാരായി. ഞാൻ ജോലി ചെയ്യുന്നതിൽ ഏറ്റവും സന്തോഷമുള്ളവരായിരുന്നു അവർ. ഈ പേടിസ്വപ്ന കോർപ്പറേറ്റ് പ്രക്രിയ ഈ വർഷങ്ങളിലെല്ലാം "സുഗമമായി" പ്രവർത്തിച്ചത് അവർക്ക് നന്ദി. പിന്നീട് അവർ ഇംഗ്ലണ്ടിലേക്ക് മാറി, അവരിൽ ഒരാൾ ഇപ്പോൾ 40+ ജീവനക്കാരുള്ള ഒരു വകുപ്പ് നടത്തുന്നു.

വിവർത്തകന്റെ കുറിപ്പ്: കെഡിപിവിയിലെ മൂങ്ങ - യോൾ.

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