𝗥𝗮𝘁𝗲-𝗟𝗶𝗺𝗶𝘁 𝗬𝗼𝘂𝗿 𝗔𝗴𝗲𝗻𝘁 𝗕𝗲𝗳𝗼𝗿𝗲 𝗦𝗼𝗺𝗲𝗼𝗻𝗲 𝗘𝗹𝘀𝗲 𝗗𝗼𝗲𝘀
ആയിരം ഇമെയിലുകൾ അയക്കുമ്പോൾ ഒരു സ്പാം റിപ്പോർട്ട് വന്നാൽ പോലും ആ ഇമെയിൽ അക്കൗണ്ട് പരിശോധനയിലാകും. 0.5% സ്പാം റിപ്പോർട്ടുകൾ വന്നാൽ പ്ലാറ്റ്ഫോം നിങ്ങളുടെ ഇമെയിൽ അയയ്ക്കൽ താൽക്കാലികമായി നിർത്തിവെക്കും. ബൗൺസുകളും (Bounces) ഇതേപോലെയാണ് പ്രവർത്തിക്കുന്നത്. ഈ പരിധികളിൽ എത്തിക്കഴിഞ്ഞാൽ, വെറുതെ സമയം കഴിയുന്നതുവരെ കാത്തിരുന്നാൽ മാത്രം പോരാ. പ്രശ്നം പരിഹരിച്ചതിന്റെ തെളിവ് സഹിതം നിങ്ങൾ സപ്പോർട്ടുമായി ബന്ധപ്പെടേണ്ടതുണ്ട്.
പ്ലാറ്റ്ഫോം നിശ്ചയിച്ചിട്ടുള്ള പരിധികൾ നിങ്ങളുടെ ലക്ഷ്യമായി കാണരുത്. അവയെ നിങ്ങളുടെ അവസാന പ്രതിരോധ മാർഗമായി മാത്രം കാണുക. അതിനേക്കാൾ കർശനമായ നിയന്ത്രണങ്ങൾ നിങ്ങൾ തന്നെ ഏർപ്പെടുത്തണം.
ഓട്ടോണമസ് ഏജന്റുകൾ (Autonomous agents) പരമ്പരാഗത കോഡുകളിൽ നിന്ന് വ്യത്യസ്തമായാണ് പ്രവർത്തിക്കുന്നത്. ഒരു മോഡൽ ഒരു ലൂപ്പിൽ (loop) അകപ്പെട്ടേക്കാം. ഒരു മറുപടി ഒരു വെബ്ഹൂക്ക് (webhook) പ്രവർത്തിപ്പിക്കുന്നു, അത് മറ്റൊരു മറുപടിയെ ഉൽപ്പാദിപ്പിക്കുന്നു. ഒരു ചെറിയ ബഗ് മിനിറ്റുകൾക്കുള്ളിൽ ആയിരക്കണക്കിന് ഇമെയിലുകളായി മാറാം. എത്രത്തോളം അയക്കുന്നു എന്നതിനെക്കുറിച്ച് മോഡലുകൾക്ക് അറിവുണ്ടാകില്ല. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിൽ (infrastructure) അത്തരം ഒരു അവബോധം നിങ്ങൾ തന്നെ നിർമ്മിച്ചെടുക്കണം.
നിങ്ങളുടെ വർക്ക്സ്പേസ് സംരക്ഷിക്കാൻ പോളിസികൾ (policies) ഉപയോഗിക്കുക. ഒരു പോളിസിയിലൂടെ നിങ്ങൾക്ക് ഇവ നിശ്ചയിക്കാം: • ദൈനംദിന അയയ്ക്കൽ ക്വാട്ടകൾ (Daily send quotas) • സ്റ്റോറേജ് പരിധികൾ (Storage caps) • ററ്റൻഷൻ വിൻഡോകൾ (Retention windows) • സ്പാം ക്രമീകരണങ്ങൾ (Spam settings)
സ്വയം ഏർപ്പെടുത്തുന്ന ക്വാട്ട എന്നത് 'ത്രോട്ട്ലിംഗ്' (throttling) അല്ല. അതൊരു ഉറപ്പാണ്. ഒരു സപ്പോർട്ട് ഏജന്റിന് ഒരു ദിവസം 150 ഇമെയിലുകൾ മാത്രമേ ആവശ്യമുള്ളൂ എങ്കിൽ, 151 എന്ന പരിധി എന്തോ കുഴപ്പമുണ്ടെന്ന് നിങ്ങൾക്ക് സൂചിപ്പിക്കുന്നു. ഇത് ഒരു സർക്യൂട്ട് ബ്രേക്കർ (circuit breaker) പോലെ പ്രവർത്തിക്കുന്നു. വലിയ നഷ്ടങ്ങൾ ഉണ്ടാകുന്നതിന് മുമ്പ് പിഴവുകൾ തിരിച്ചറിയാൻ ഇത് സഹായിക്കുന്നു.
ദിശ നിയന്ത്രിക്കുന്നതിനായി നിങ്ങൾക്ക് ഔട്ട്ബൗണ്ട് റൂളുകളും (outbound rules) ഉപയോഗിക്കാം. പ്രത്യേക ഡൊമെയ്നുകളെ ബ്ലോക്ക് ചെയ്യാനോ ഏജന്റുകൾ പുതിയ ത്രെഡുകൾ (threads) തുടങ്ങുന്നത് തടയാനോ ഇതിലൂടെ സാധിക്കും. സന്ദേശം അയക്കുന്നതിന് മുമ്പ് തന്നെ ഈ റൂളുകൾ പരിശോധിക്കപ്പെടും. ഒരു റൂൾ പരിശോധിക്കുമ്പോൾ സിസ്റ്റത്തിന് എന്തെങ്കിലും പിശക് സംഭവിച്ചാൽ, അത് സന്ദേശം അയക്കാതെ തടഞ്ഞുവെക്കും (fails closed). അതായത്, സുരക്ഷിതമല്ലാത്ത രീതിയിൽ സന്ദേശം അയക്കുന്നതിനേക്കാൾ നല്ലത് അത് ബ്ലോക്ക് ചെയ്യുന്നതാണ്.
സുരക്ഷിതമായിരിക്കാൻ ഈ ഘട്ടങ്ങൾ പാലിക്കുക: • മെസ്സേജ് ഡെലിവറി, ബൗൺസ്, പരാതി, റിജക്ഷൻ എന്നിവയ്ക്കായുള്ള വെബ്ഹൂക്കുകൾക്ക് (webhooks) സബ്സ്ക്രൈബ് ചെയ്യുക. • നിങ്ങളുടെ സ്വന്തം ടെലിമെറ്ററിയിലൂടെ (telemetry) ഈ നിരക്കുകൾ നിരീക്ഷിക്കുക. • നിരക്കുകൾ വർദ്ധിക്കുകയാണെങ്കിൽ നിങ്ങളുടെ ഔട്ട്ബൗണ്ട് ലോജിക് മാനുവലായി നിർത്തിവെക്കുക.
"പ്ലാറ്റ്ഫോം ഞങ്ങളെ നിർത്തിവെച്ചു" എന്ന് പറയുന്നതിനേക്കാൾ നല്ലത് "ഞങ്ങൾ സ്വയം നിർത്തിവെച്ചു" എന്ന് പറയുന്നതാണ് ഒരു ഇൻസിഡന്റ് റിപ്പോർട്ട് (incident report) ആയി.
വോളിയം പെട്ടെന്ന് വർദ്ധിക്കുന്നത് (volume spikes) നിങ്ങൾ ഭയപ്പെടുന്നുണ്ടെങ്കിൽ, ക്വാട്ട എന്നത് ഒരു അവസാന പോയിന്റായി കാണരുത്. അതിനെ ഒരു എസ്കലേഷൻ പാതയായി (escalation path) മാറ്റുക. ഒരു ഏജന്റ് പരിധിയിൽ എത്തിയാൽ, ഒരു മനുഷ്യനെ അറിയിക്കുകയോ അല്ലെങ്കിൽ അംഗീകാരത്തിനായി സന്ദേശങ്ങൾ ക്യൂ ചെയ്യുകയോ ചെയ്യുക. വൈകിപ്പോകുന്ന ഒരു ഇമെയിൽ ചെറിയൊരു പ്രശ്നമാണ്. എന്നാൽ സന്ദേശങ്ങൾ അയക്കുന്ന അക്കൗണ്ടിന്റെ സൽപ്പേര് (sender reputation) നഷ്ടപ്പെട്ടാൽ അത് വീണ്ടെടുക്കാൻ ആഴ്ചകൾ വേണ്ടിവരും.
അടുത്ത ഘട്ടം: നിങ്ങളുടെ ഏറ്റവും ഉയർന്ന വോളിയത്തിന്റെ ഇരട്ടി (2x) ദൈനംദിന ക്വാട്ട നൽകിക്കൊണ്ട് ഒരു പോളിസി നിർമ്മിക്കുക. ഇത് നിങ്ങളുടെ വർക്ക്സ്പേസുമായി ബന്ധിപ്പിക്കുക. ഒരു സ്റ്റേജിംഗ് എൻവയോൺമെന്റിൽ (staging environment) ഈ ക്വാട്ട പ്രവർത്തിപ്പിച്ചു നോക്കുക. നിങ്ങളുടെ അലേർട്ടുകൾ (alerts) പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, അവിടെ ഒരു പിഴവ് ഉണ്ടെന്ന് മനസ്സിലാക്കാം.
Source: https://dev.to/qasim157/rate-limit-your-own-agent-before-someone-else-does-33cb
Optional learning community: https://t.me/GyaanSetuAi