Your uptime dashboard is lying to you. It says your site is online. The homepage loads. The SSL certificate is valid. Every pixel renders exactly where it should. Meanwhile, your store has not processed a real order in six hours, and the first person to tell you is your client wondering why the daily sales report flatlined.

This is the fundamental flaw in treating an e-commerce platform like a brochure site. Standard uptime monitoring asks exactly one question: did the server return a 200 OK status? For a WooCommerce store, that question misses the point entirely. The server can be humming, the checkout page can look pristine, and the money can still stop moving. That is a silent failure, and it is far more expensive than a noisy server crash.

"ഓൺലൈൻ" എന്നത് കൊണ്ട് യാതൊരു അർത്ഥവുമില്ലാത്തപ്പോൾ

ഒരു 200 റെസ്‌പോൺസ് എന്നത് PHP എക്സിക്യൂഷൻ പൂർത്തിയാക്കി ബ്രൗസറിലേക്ക് HTML അയച്ചു എന്ന് മാത്രമേ തെളിയിക്കുന്നുള്ളൂ. Stripe-ന്റെ JavaScript ലോഡ് ആയി എന്ന് അത് തെളിയിക്കുന്നില്ല. 'place-order' ബട്ടൺ പ്രവർത്തിക്കുന്ന ഒരു എൻഡ്‌പോയിന്റിലേക്ക് (endpoint) വിവരങ്ങൾ അയക്കുന്നുണ്ടോ എന്നും അത് തെളിയിക്കുന്നില്ല. വെബ്‌ഹുക്ക് (webhook) പ്രവർത്തിച്ചോ, സ്റ്റോക്ക് ക്രമീകരിക്കപ്പെട്ടോ, അല്ലെങ്കിൽ കൺഫർമേഷൻ ഇമെയിൽ അയച്ചോ എന്നും അത് ഉറപ്പുവരുത്തുന്നില്ല. ഒരു സന്ദർശകൻ പൂർണ്ണമായി ലോഡ് ആയ ഒരു ചെക്കൗട്ട് പേജ് കാണുന്നു, കാർഡ് നമ്പർ നൽകുന്നു, 'buy' ക്ലിക്ക് ചെയ്യുന്നു, എന്നാൽ ഒന്നും സംഭവിക്കുന്നില്ല. അല്ലെങ്കിൽ ഇതിലും മോശമായത്, പേയ്‌മെന്റ് വിജയകരമായി പൂർത്തിയായെങ്കിലും ഓർഡർ പരാജയപ്പെട്ടതായി രേഖപ്പെടുത്തുന്നു.

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

സൈറ്റ് പ്രവർത്തനരഹിതമാകാതെ തന്നെ ഒരു സ്റ്റോർ തകരാറിലാകുന്ന അഞ്ച് വഴികൾ

ഒരു WooCommerce സ്റ്റോർ 100% അപ്‌ടൈമിൽ നിലകൊള്ളുമ്പോഴും കൺവേർഷൻ സീറോയിലേക്ക് താഴുന്ന ചില പ്രത്യേക പരാജയങ്ങൾ താഴെ പറയുന്നവയാണ്:

  • പേയ്‌മെന്റ് ഗേറ്റ്‌വേകൾ ടെസ്റ്റ് മോഡിൽ കുടുങ്ങുന്നു. ഒരു ഡെവലപ്പർ ബഗ് (bug) പരിശോധിക്കാനായി Stripe അല്ലെങ്കിൽ PayPal സാൻഡ്‌ബോക്സ് (sandbox) മോഡിലേക്ക് മാറ്റുകയും, പ്രശ്നം പരിഹരിച്ച ശേഷം അത് തിരികെ മാറ്റാൻ മറന്നുപോവുകയും ചെയ്യുന്നു. യഥാർത്ഥ ഉപഭോക്താക്കൾ യഥാർത്ഥ കാർഡ് നമ്പറുകൾ നൽകുന്നുണ്ടെങ്കിലും അവർക്ക് ടെസ്റ്റ് മോഡിലെ തടസ്സം നേരിടുന്നു. ചിലപ്പോൾ പിശക് വ്യക്തമായി കാണാം; ചിലപ്പോൾ അത് കാണില്ല, ഇടപാടുകൾ വെറുതെ ഹാങ്ങ് ആയിപ്പോകുന്നു.
  • ഒരു പ്ലഗിൻ അപ്‌ഡേറ്റ് ചെക്കൗട്ട് ടെംപ്ലേറ്റിനെ തകരാറിലാക്കുന്നു. WooCommerce ഒരു അപ്‌ഡേറ്റ് പുറത്തിറക്കുന്നു, അല്ലെങ്കിൽ ഒരു പേജ് ബിൽഡർ മാറ്റങ്ങൾ വരുത്തുന്നു, തൽഫലമായി ചെക്കൗട്ട് ഫോം ശരിയായി കാണപ്പെടുന്നില്ല. പേജ് ലോഡ് ആകുന്നുണ്ടെങ്കിലും ബില്ലിംഗ് ഫീൽഡുകൾ കാണുന്നില്ല, അല്ലെങ്കിൽ 'place-order' ബട്ടൺ ക്ലിക്ക് ചെയ്യുമ്പോൾ ഒരു JavaScript എറർ കാണിക്കുന്നു. സെർവർ ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടാകാം, എന്നാൽ ഉപഭോക്താവിന്റെ അനുഭവം (user experience) തകരാറിലാകുന്നു.
  • ഗേറ്റ്‌വേ പിശകുകൾ കാരണം പരാജയപ്പെട്ട ഓർഡറുകൾ വർദ്ധിക്കുന്നു. API കീകൾ കാലാവധി തീരുന്നു. കറൻസി വ്യത്യാസങ്ങൾ ഉണ്ടാകുന്നു. 3D Secure ആവശ്യകതകളിൽ മാറ്റം വരുന്നു. ഈ പിശകുകൾ നിങ്ങളുടെ അപ്‌ടൈം ലോഗുകളിൽ സെർവർ എററുകളായിട്ടല്ല, മറിച്ച് WooCommerce അഡ്മിനിൽ പരാജയപ്പെട്ട ഓർഡറുകളായിട്ടാണ് കാണപ്പെടുന്നത്. തെറ്റായ സ്ക്രീൻ നിരീക്ഷിച്ചാൽ, സാവധാനം സംഭവിക്കുന്ന വരുമാന നഷ്ടം നിങ്ങൾക്ക് തിരിച്ചറിയാൻ കഴിയില്ല.
  • സെർവർ സൈഡ് ഓർഡർ പൈപ്പ്‌ലൈൻ തടസ്സപ്പെടുന്നു. ഉപഭോക്താവ് 'buy' ക്ലിക്ക് ചെയ്തതിന് ശേഷം ഒരു തേർഡ് പാർട്ടി ERP ഇന്റഗ്രേഷൻ, കസ്റ്റം സ്റ്റോക്ക്-സിങ്ക് ഫംഗ്ഷൻ, അല്ലെങ്കിൽ ഷിപ്പിംഗ് റേറ്റ് കാൽക്കുലേറ്റർ എന്നിവ ടൈം ഔട്ട് (timeout) ആകുന്നു. ഓർഡർ അനന്തമായി 'pending' സ്റ്റാറ്റസിൽ തുടരുന്നു. ഉപഭോക്താവ് പേജ് റീഫ്രഷ് ചെയ്യുന്നു, ആശയക്കുഴപ്പത്തിലാകുന്നു, തുടർന്ന് സൈറ്റ് വിട്ടുപോകുന്നു. നിങ്ങളുടെ ഹോസ്റ്റിംഗ് മെട്രിക്സുകൾ ഇപ്പോഴും പച്ച നിറത്തിൽ (green) കാണപ്പെടുന്നുണ്ടാകാം.
  • പ്രത്യേകിച്ച് കാരണങ്ങളൊന്നുമില്ലാതെ ഓർഡർ പ്രക്രിയ നിലയ്ക്കുന്നു. വലിയ പിശകുകളോ പ്ലഗിൻ പ്രശ്നങ്ങളോ ഒന്നുമില്ലാതെ തന്നെ ഇത് സംഭവിക്കാം. കാഷെ (cache) പഴയ ചെക്കൗട്ട് JavaScript നൽകാൻ തുടങ്ങുന്നു. ഒരു കൺസെന്റ് മാനേജ്‌മെന്റ് ബാനർ പേയ്‌മെന്റ് iframe-നെ തടയുന്നു. ഒരു CDN എഡ്ജ് നോഡ് സ്ക്രിപ്റ്റിന്റെ പഴയ പതിപ്പ് നൽകുന്നു. സൈറ്റ് ഓൺലൈൻ ആണ്, എന്നാൽ ചെക്കൗട്ട് പ്രവർത്തിക്കുന്നില്ല.

യഥാർത്ഥത്തിൽ ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ നിരീക്ഷിക്കുക

ഈ പരാജയങ്ങൾ കണ്ടെത്താൻ, നിങ്ങൾ ഇൻഫ്രാസ്ട്രക്ചർ നിരീക്ഷിക്കുന്നത് നിർത്തി ബിസിനസ് ലോജിക് (business logic) നിരീക്ഷിച്ചു തുടങ്ങണം. ഒരു യഥാർത്ഥ ഇടപാട് പ്രക്രിയയുടെ സങ്കീർണ്ണത കണക്കിലെടുത്ത് എങ്ങനെ ഒരു മോണിറ്ററിംഗ് തന്ത്രം കെട്ടിപ്പടുക്കാം എന്ന് നോക്കാം.

അപ്‌ടൈം മാത്രമല്ല, ഓർഡർ ഫ്ലോയും നിരീക്ഷിക്കുക. ഒരു ഉൽപ്പന്നം കാർട്ടിലേക്ക് ചേർക്കാൻ കഴിയുന്നുണ്ടോ, ചെക്കൗട്ട് എൻഡ്‌പോയിന്റ് സാധുവായ JSON നൽകുന്നുണ്ടോ, വിജയകരമായ പേയ്‌മെന്റിന് ശേഷം 'thank-you' പേജ് ലോഡ് ആകുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. നിങ്ങൾ പുറത്തുള്ള പിംഗ് ടൂളുകളെയാണ് ആശ്രയിക്കുന്നതെങ്കിൽ, അവ വെറും ഡൊമെയ്ൻ റൂട്ടിൽ (domain root) മാത്രം ഒതുങ്ങാതെ ക്രിട്ടിക്കൽ പാത്തുകളിൽ (critical path) പ്രവർത്തിപ്പിക്കാൻ ക്രമീകരിക്കുക.

പരാജയപ്പെട്ട ഓർഡറുകളെ ഏഴ് ദിവസത്തെ ബേസ്‌ലൈനുമായി (baseline) താരതമ്യം ചെയ്യുക. കേവല സംഖ്യകൾ മാത്രം ഉപയോഗിക്കരുത്. ഒരു പ്രമോഷന് ശേഷമുള്ള തിങ്കളാഴ്ച രാവിലെ അഞ്ച് പരാജയപ്പെട്ട ഓർഡറുകൾ എന്നത് സാധാരണയായിരിക്കാം. എന്നാൽ ശാന്തമായ ഒരു ബുധനാഴ്ച ഉച്ചകഴിഞ്ഞ് അഞ്ച് പരാജയപ്പെട്ട ഓർഡറുകൾ എന്നത് ഒരു അപകടസൂചനയാണ്. കൃത്യമായ പരിധികൾ (arbitrary thresholds) നോക്കുന്നതിന് പകരം നിങ്ങളുടെ തന്നെ നിലവിലുള്ള ബേസ്‌ലൈനിൽ നിന്നുള്ള വ്യതിയാനം ശ്രദ്ധിക്കുക.

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

ദിവസേന ഒരു സെർവർ-സൈഡ് സ്മോക്ക് ടെസ്റ്റ് (smoke test) നടത്തുക. മനുഷ്യർ ശ്രദ്ധിക്കുന്നതിന് മുൻപ് തന്നെ തകരാറിലായ ചെക്കൗട്ട് കണ്ടെത്താനുള്ള ഏറ്റവും ഫലപ്രദമായ മാർഗ്ഗമാണിത്.

ദിവസേനയുള്ള സ്മോക്ക് ടെസ്റ്റ് നിർമ്മിക്കാം

ശരിയായ ഒരു സ്മോക്ക് ടെസ്റ്റ് നിങ്ങളുടെ ഡാറ്റാബേസിൽ കുഴപ്പങ്ങൾ ഉണ്ടാക്കാതെ തന്നെ യഥാർത്ഥമെന്ന് തോന്നിക്കുന്ന ഒരു ഓർഡർ നിർമ്മിക്കുന്നു. ഇതിന്റെ പ്രക്രിയ ഇപ്രകാരമാണ്: ഒരു ഹിഡൻ വെർച്വൽ പ്രോഡക്റ്റ് നിർമ്മിക്കുക, WooCommerce API വഴി ഒരു ടെസ്റ്റ് ഓർഡർ നടത്തുക, ടോട്ടലുകൾ കൃത്യമായി കണക്കാക്കുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്തുക, ഓർഡർ അതിന്റെ വിവിധ സ്റ്റാറ്റസുകളിലൂടെ കടത്തിവിടുക, തുടർന്ന് എല്ലാ വിവരങ്ങളും (artifacts) ഡിലീറ്റ് ചെയ്യുക.

ഇതിന്റെ നിർവ്വഹണ രീതികൾ വളരെ പ്രധാനമാണ്. ക്ലീനപ്പ് (cleanup) ശ്രദ്ധാപൂർവ്വം ചെയ്തില്ലെങ്കിൽ, നിങ്ങളുടെ റിപ്പോർട്ടുകൾ വ്യാജ ഓർഡറുകളും ഫാൻ്റം പ്രോഡക്റ്റുകളും കൊണ്ട് നിറയും.

ടെസ്റ്റിംഗിനിടെ WooCommerce ഇമെയിലുകൾ തടയുക. ഒരു cron job അതിന്റെ ദൈനംദിന പരിശോധന നടത്തുന്നതുകൊണ്ട് പുലർച്ചെ 3:00 AM-ന് സ്റ്റോർ ഉടമയ്ക്കോ അഡ്മിനിനോ "New Order" എന്ന ഇമെയിൽ ലഭിക്കുന്നത് നിങ്ങൾ ഒരിക്കലും ആഗ്രഹിക്കില്ല. സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുന്ന സമയത്ത് ഔട്ട്‌ഗോയിംഗ് നോട്ടിഫിക്കേഷനുകൾ ഡിസേബിൾ ചെയ്യുക, അല്ലെങ്കിൽ ടെസ്റ്റ് ഓർഡർ ഐഡികളുമായി ബന്ധപ്പെട്ട ഇമെയിലുകൾ തടയാൻ ഒരു ഫിൽട്ടർ ഉപയോഗിക്കുക.

സ്ക്രിപ്റ്റ് ക്രാഷ് ചെയ്താൽ ഡാറ്റ ക്ലീൻ അപ്പ് ചെയ്യാൻ ഒരു shutdown function ഉപയോഗിക്കുക. ഒരു fatal error പ്രോസസ്സിനെ തടസ്സപ്പെടുത്തിയാലും പ്രവർത്തിക്കുന്ന ഒരു shutdown function രജിസ്റ്റർ ചെയ്യാൻ PHP നിങ്ങളെ അനുവദിക്കുന്നു. ടാക്സ് കണക്കാക്കുമ്പോഴോ ഓർഡർ സ്റ്റാറ്റസുകൾ മാറ്റുമ്പോഴോ സ്മോക്ക് ടെസ്റ്റ് പരാജയപ്പെട്ടാൽ പോലും ആ ക്ലീനപ്പ് റൂട്ടീൻ പ്രവർത്തിക്കണം. അല്ലാത്തപക്ഷം, പൂർത്തിയാകാത്ത ഓർഡറുകളും പ്രോഡക്റ്റുകളും ഡാറ്റാബേസിൽ അവശേഷിക്കും.

അനാവശ്യ ഡാറ്റ ഒഴിവാക്കാൻ ഐഡികൾ (IDs) നിർമ്മിച്ച ഉടൻ തന്നെ രേഖപ്പെടുത്തുക. വെർച്വൽ പ്രോഡക്റ്റ് നിർമ്മിച്ച നിമിഷം തന്നെ അതിന്റെ ID ശേഖരിക്കുക. ടെസ്റ്റ് ഓർഡർ നിർമ്മിച്ച നിമിഷം തന്നെ അതിന്റെ ID ശേഖരിക്കുക. ഇവ ഉടൻ തന്നെ വേരിയബിളുകളിൽ സൂക്ഷിക്കുക. നിങ്ങൾ എന്താണ് നിർമ്മിച്ചതെന്ന് ചോദിക്കാൻ സ്ക്രിപ്റ്റിന്റെ അവസാനം വരെ കാത്തുനിൽക്കരുത്. സ്ക്രിപ്റ്റ് പകുതി വഴിയിൽ പരാജയപ്പെട്ടാൽ, എന്ത് ഡിലീറ്റ് ചെയ്യണമെന്ന് നിങ്ങളുടെ shutdown handler-ന് കൃത്യമായി അറിയാൻ ഈ IDകൾ കയ്യിൽ ഉണ്ടായിരിക്കണം.

ഈ ടെസ്റ്റ് യൂസർ ഇന്റർഫേസിനെ മറികടന്ന് നേരിട്ട് ആപ്ലിക്കേഷൻ ലെയറുമായി ആശയവിനിമയം നടത്തുന്നു. അത് പ്രധാനമാണ്. ഫ്രണ്ട് എൻഡ് കാഷെഡ് (cached) ആകാം, മിനിഫൈഡ് (minified) ആകാം, അല്ലെങ്കിൽ നിരവധി ബ്രൗസർ എക്സ്റ്റൻഷനുകൾ വഴി മാറ്റം വരുത്തിയതാകാം. എന്നാൽ API ആണ് യഥാർത്ഥ അവസ്ഥ പ്രതിനിധീകരിക്കുന്നത്: WooCommerce-ന് ഇപ്പോഴും ഒരു ഓർഡർ ക്രിയേറ്റ് ചെയ്യാനും കണക്കുകൂട്ടാനും സ്റ്റാറ്റസ് മാറ്റാനും കഴിയുന്നുണ്ടോ?

സംരക്ഷണത്തിന്റെ രണ്ട് പാളികൾ

നിങ്ങൾക്ക് എക്സ്റ്റേണൽ (external), ഇന്റേണൽ (internal) എന്നിങ്ങനെ രണ്ട് തരം മോണിറ്ററിംഗും ആവശ്യമാണ്, കൂടാതെ ഓരോ പാളിയും നിങ്ങൾക്ക് എന്താണ് നൽകുന്നതെന്ന് മനസ്സിലാക്കേണ്ടതുമുണ്ട്.

"ആളുകൾക്ക് സൈറ്റിൽ എത്താൻ കഴിയുന്നുണ്ടോ?" എന്ന ചോദ്യത്തിനാണ് എക്സ്റ്റേണൽ മോണിറ്ററിംഗ് ഉത്തരം നൽകുന്നത്. DNS പ്രശ്നങ്ങൾ, SSL കാലാവധി കഴിയുന്നത്, സെർവറുകൾ പ്രവർത്തനരഹിതമാകുന്നത്, നെറ്റ്‌വർക്ക് തകരാറുകൾ എന്നിവ കണ്ടെത്താൻ ഇത് ഉപയോഗിക്കുക. ഇൻഫ്രാസ്ട്രക്ചർ പരാജയങ്ങൾക്കെതിരെയുള്ള നിങ്ങളുടെ ആദ്യ പ്രതിരോധ നിരയാണിത്.

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

ഒരു ഔട്ട്‌േജ് (outage) ശബ്ദമുണ്ടാക്കുന്നതാണ്. സൈറ്റ് പ്രവർത്തനരഹിതമാകുമ്പോൾ അലേർട്ടുകൾ വരുന്നു, നിങ്ങൾ അത് പരിഹരിക്കുന്നു. ഉപഭോക്താക്കൾ പരാതിപ്പെട്ടേക്കാം, പക്ഷേ അവർ മിക്കവാറും തിരികെ വരും. എന്നാൽ തകരാറിലായ ഒരു ചെക്കൗട്ട് നിശബ്ദമാണ്. നിങ്ങളുടെ പരസ്യങ്ങൾ തുടർന്നും പ്രവർത്തിച്ചുകൊണ്ടിരിക്കും, ഉപഭോക്താക്കളെ ആകർഷിക്കാനുള്ള ബജറ്റ് പാഴാകിക്കൊണ്ടിരിക്കും, ഉപഭോക്താക്കൾ ഒന്നും പറയാതെ തന്നെ പോയിക്കൊണ്ടിരിക്കും. നിങ്ങളുടെ അപ്‌ടൈം ഡാഷ്‌ബോർഡ് (uptime dashboard) ആ സമയമത്രയും പച്ച നിറത്തിൽ സുരക്ഷിതമാണെന്ന് തോന്നിപ്പിക്കുകയും ചെയ്യും.

ഹോംപേജ് നോക്കുന്നത് നിർത്തുക. പണം ശ്രദ്ധിച്ചു തുടങ്ങുക.