Your uptime dashboard is lying to you. It says your site is online. The homepage loads. The SSL certificate is valid. Ev

તમારું અપટાઇમ ડેશબોર્ડ તમને જૂઠું બોલી રહ્યું છે. તે કહે છે કે તમારી સાઇટ ઓનલાઇન છે. હોમપેજ લોડ થાય છે. SSL સર્ટિફિકેટ માન્ય છે. દરેક પિક્સેલ બરાબર ત્યાં જ રેન્ડર થાય છે જ્યાં તેણે હોવું જોઈએ. તે દરમિયાન, તમારા સ્ટોરે છ કલાકથી એક પણ અસલી ઓર્ડર પ્રોસેસ કર્યો નથી, અને તમને આ વાત જણાવનાર પ્રથમ વ્યક્તિ તમારો ક્લાયન્ટ હશે જે પૂછશે કે દૈનિક વેચાણ રિપોર્ટ કેમ શૂન્ય થઈ ગયો.

ઇ-કોમર્સ પ્લેટફોર્મને બ્રોશર સાઇટની જેમ લેવામાં આવતી આ એક મૂળભૂત ખામી છે. સ્ટાન્ડર્ડ અપટાઇમ મોનિટરિંગ માત્ર એક જ પ્રશ્ન પૂછે છે: શું સર્વરે 200 OK સ્ટેટસ આપ્યું? WooCommerce સ્ટોર માટે, આ પ્રશ્ન આખી વાતથી વિરુદ્ધ છે. સર્વર ચાલતું હોઈ શકે છે, ચેકઆઉટ પેજ એકદમ વ્યવસ્થિત દેખાઈ શકે છે, છતાં પણ પૈસા આવવાનું બંધ થઈ શકે છે. તે એક સાયલન્ટ ફેઈલ્યોર (silent failure) છે, અને તે સર્વર ક્રેશ થવા કરતાં વધુ ખર્ચાળ છે.

જ્યારે "ઓનલાઇન" હોવાનો કોઈ અર્થ ન હોય

200 રિસ્પોન્સ માત્ર એટલું જ સાબિત કરે છે કે PHP એ એક્ઝિક્યુશન પૂરું કર્યું અને બ્રાઉઝરને HTML પાછું મોકલ્યું. તે એ સાબિત નથી કરતું કે Stripe નું JavaScript લોડ થયું છે. તે એ સાબિત નથી કરતું કે 'place-order' બટન કામ કરતા એન્ડપોઇન્ટ (endpoint) પર સબમિટ થાય છે. તે એ સાબિત નથી કરતું કે વેબહૂક (webhook) ફાયર થયું, સ્ટોક એડજસ્ટ થયો, અથવા કન્ફર્મેશન ઈમેલ મોકલવામાં આવ્યો. મુલાકાતી એક સંપૂર્ણ લોડ થયેલું ચેકઆઉટ જુએ છે, કાર્ડ નંબર દાખલ કરે છે, 'buy' પર ક્લિક કરે છે, અને કંઈ જ થતું નથી. અથવા તો તેનાથી પણ ખરાબ, પેમેન્ટ ક્લિયર થઈ જાય છે પરંતુ ઓર્ડર 'ફેઈલ્ડ' તરીકે નોંધાય છે.

જો તમારી મોનિટરિંગ વ્યૂહરચના માત્ર હોમપેજ પિંગ કરવાથી શરૂ થઈને પિંગ કરવા પર જ પૂરી થતી હોય, તો તમે ખોટી બાબત પર નજર રાખી રહ્યા છો. તમે હેડરને બગાડતા થીમ ક્રેશને નોટિસ કરશો. તમે ટેસ્ટ મોડમાં અટવાયેલ પેમેન્ટ ગેટવેને નોટિસ નહીં કરી શકો. તમને ત્યારે જ ખબર પડશે જ્યારે કોઈ રેવન્યુ ગ્રાફ ચેક કરશે અથવા કોઈ ગુસ્સાવાળા ફોન કોલનો જવાબ આપશે.

સ્ટોર ડાઉન થયા વગર પણ બંધ થઈ જાય તેવા પાંચ રસ્તાઓ

અહીં એવા ચોક્કસ નિષ્ફળતાઓ છે જે WooCommerce સ્ટોરને 100% અપટાઇમ પર રાખે છે જ્યારે કન્વર્ઝન શૂન્ય થઈ જાય છે:

• પેમેન્ટ ગેટવે ટેસ્ટ મોડમાં અટકી જાય છે. ડેવલપર કોઈ બગ (bug) ને રિપ્રોડ્યુસ કરવા માટે Stripe અથવા PayPal ને સેન્ડબોક્સ (sandbox) મોડમાં સ્વિચ કરે છે, સમસ્યા ઉકેલે છે, અને સ્વિચ પાછી ફેરવવાનું ભૂલી જાય છે. અસલી ગ્રાહકો અસલી કાર્ડ નંબર દાખલ કરે છે અને ટેસ્ટ-મોડની દીવાલ સાથે અથડાય છે. ક્યારેક ભૂલ સ્પષ્ટ હોય છે; ક્યારેક તે હોતી નથી, અને ટ્રાન્ઝેક્શન ફક્ત અટકી જાય છે.
• પ્લગઇન અપડેટ ચેકઆઉટ ટેમ્પલેટને બગાડે છે. WooCommerce અપડેટ બહાર પાડે છે, અથવા પેજ બિલ્ડર કોઈ ફેરફાર કરે છે, અને ચેકઆઉટ ફોર્મ હવે યોગ્ય રીતે દેખાતું નથી. પેજ લોડ થાય છે, પરંતુ બિલિંગ ફીલ્ડ્સ ગાયબ થઈ જાય છે, અથવા 'place-order' બટન પર ક્લિક કરવાથી JavaScript એરર આવે છે. સર્વર બરાબર છે. યુઝર એક્સપિરિયન્સ બગડી ગયો છે.
• ગેટવે એરરને કારણે ફેઈલ્ડ ઓર્ડર્સમાં વધારો થાય છે. API કી એક્સપાયર થઈ જાય છે. કરન્સીમાં તફાવત જોવા મળે છે. 3D Secure ની જરૂરિયાતો બદલાય છે. આ ભૂલો WooCommerce એડમિનમાં 'ફેઈલ્ડ ઓર્ડર્સ' તરીકે દેખાય છે, તમારા અપટાઇમ લોગ્સમાં સર્વર એરર તરીકે નહીં. જો તમે ખોટી સ્ક્રીન જોશો, તો તમે ધીમે ધીમે થતા રેવન્યુના નુકસાનને ચૂકી જશો.
• સર્વર-સાઇડ ઓર્ડર પાઇપલાઇન અટકી જાય છે. ગ્રાહક 'buy' પર ક્લિક કર્યા પછી થર્ડ-પાર્ટી ERP ઇન્ટિગ્રેશન, કસ્ટમ સ્ટોક-સિંક ફંક્શન, અથવા શિપિંગ-રેટ કેલ્ક્યુલેટર ટાઈમઆઉટ થઈ જાય છે. ઓર્ડર અનિશ્ચિત સમય માટે 'pending' સ્ટેટસમાં રહે છે. ગ્રાહક પેજ રિફ્રેશ કરે છે, મૂંઝવણમાં મુકાય છે, અને છોડી દે છે. તમારા હોસ્ટિંગ મેટ્રિક્સ હજુ પણ ગ્રીન દેખાય છે.
• કોઈ સ્પષ્ટ કારણ વગર ઓર્ડર ફ્લો અટકી જાય છે. કોઈ ફેટલ એરર નથી. કોઈ પ્લગઇન કોન્ફ્લિક્ટ નથી. કેશ (cache) ફક્ત જૂનું ચેકઆઉટ JavaScript સર્વ કરવાનું શરૂ કરે છે. કન્સેન્ટ-મેનેજમેન્ટ બેનર પેમેન્ટ iframe ને બ્લોક કરે છે. CDN એજ નોડ સ્ક્રિપ્ટનું જૂનું વર્ઝન ડિલિવર કરે છે. સાઇટ ઓનલાઇન છે. ચેકઆઉટ નથી.

જે ખરેખર મહત્વનું છે તેનું મોનિટરિંગ કરો

આ નિષ્ફળતાઓને પકડવા માટે, તમારે ઇન્ફ્રાસ્ટ્રક્ચર જોવાનું બંધ કરવું પડશે અને બિઝનેસ લોજિક જોવાનું શરૂ કરવું પડશે. વાસ્તવિક ટ્રાન્ઝેક્શન ફ્લોની જટિલતાને ધ્યાનમાં રાખીને મોનિટરિંગ વ્યૂહરચના કેવી રીતે બનાવવી તે અહીં છે.

માત્ર અપટાઇમ નહીં, પણ ઓર્ડર ફ્લોનું મોનિટરિંગ કરો. પ્રોડક્ટ કાર્ટમાં ઉમેરી શકાય છે કે નહીં, ચેકઆઉટ એન્ડપોઇન્ટ માન્ય JSON સાથે પ્રતિસાદ આપે છે કે નહીં, અને સફળ પેમેન્ટ પછી 'thank-you' પેજ લોડ થાય છે કે નહીં તે ટ્રેક કરો. જો તમે એક્સટર્નલ પિંગ ટૂલ્સ પર આધાર રાખતા હોવ, તો તેમને માત્ર ડોમેન રૂટ નહીં, પણ ક્રિટિકલ પાથ (critical path) પર હિટ કરવા માટે કોન્ફિગર કરો.

ફેઈલ્ડ ઓર્ડર્સની સરખામણી સાત દિવસના બેઝલાઇન સાથે કરો. નિરપેક્ષ સંખ્યાઓનો ઉપયોગ કરશો નહીં. પ્રમોશન પછી સોમવાર સવાર માટે એક કલાકમાં પાંચ ફેઈલ્ડ ઓર્ડર્સ સામાન્ય હોઈ શકે છે. શાંત બુધવારની બપોરે એક કલાકમાં પાંચ ફેઈલ્ડ ઓર્ડર્સ એ રેડ ફ્લેગ (ચેતવણી) છે. તમારી પોતાની રોલિંગ બેઝલાઇનથી થતા વિચલન (deviation) પર ધ્યાન આપો, મનસ્વી થ્રેશોલ્ડ પર નહીં.

લાઇવ ગેટવે સેન્ડબોક્સ મોડમાં છે કે નહીં તે તપાસો. આને તમારી ડિપ્લોયમેન્ટ ચેકલિસ્ટ અને તમારા ઓટોમેટેડ ટેસ્ટનો ભાગ બનાવો. એક્ટિવ ગેટવે સેટિંગ્સ તપાસો, અથવા પબ્લિક API કીનું વિશ્લેષણ કરો જેથી ખાતરી કરી શકાય કે તે પ્રોડક્શન ક્રેડેન્શિયલ્સ છે. સ્ટોર ક્યારેય ટેસ્ટ એન્વાયરમેન્ટ સાથે જોડાયેલ હોય ત્યારે લાઇવ ન થવો જોઈએ.

દરરોજ સર્વર-સાઇડ સ્મોક ટેસ્ટ ચલાવો. માનવીય આંખો દ્વારા પકડાય તે પહેલાં ચેકઆઉટમાં આવતી ખામીને પકડવા માટે આ સૌથી અસરકારક સેફ્ટી નેટ છે.

ડેઇલી સ્મોક ટેસ્ટ બનાવવો

યોગ્ય સ્મોક ટેસ્ટ તમારા ડેટાબેઝમાં અરાજતા ઊભી કર્યા વિના વાસ્તવિક ઓર્ડર બનાવે છે. પ્રક્રિયા આ મુજબ છે: એક છુપાયેલ વર્ચ્યુઅલ પ્રોડક્ટ બનાવો, WooCommerce API દ્વારા ટેસ્ટ ઓર્ડર ચલાવો, ટોટલ સાચી રીતે ગણાય છે કે નહીં તે ચકાસો, ઓર્ડરને તેના વિવિધ સ્ટેટસમાંથી પસાર કરો, અને પછી દરેક આર્ટિફેક્ટ (artifact) ડિલીટ કરો.

અમલીકરણની વિગતો મહત્વની છે. જો તમે ક્લીનઅપ (cleanup) કાળજીપૂર્વક કરવામાં નહીં, તો તમારા રિપોર્ટ્સ નકલી ઓર્ડર અને ફેન્ટમ પ્રોડક્ટ્સથી ભરાઈ જશે.

ટેસ્ટ દરમિયાન WooCommerce ઇમેઇલ્સ રોકી રાખો. તમે ક્યારેય નહીં ઈચ્છો કે સ્ટોર માલિક અથવા કોઈ એડમિનને રાત્રે 3:00 વાગ્યે "New Order" ઇમેઇલ મળે કારણ કે કોઈ cron job એ તેની દૈનિક તપાસ કરી હોય. સ્ક્રિપ્ટ દરમિયાન આઉટગોઇંગ નોટિફિકેશન્સ ડિસેબલ કરો, અથવા ટેસ્ટ ઓર્ડર ID સાથે જોડાયેલા કોઈપણ ઇમેઇલને બ્લોક કરવા માટે ફિલ્ટરનો ઉપયોગ કરો.

જો સ્ક્રિપ્ટ ક્રેશ થાય તો ડેટા ક્લીનઅપ કરવા માટે shutdown function નો ઉપયોગ કરો. PHP તમને shutdown function રજીસ્ટર કરવાની મંજૂરી આપે છે જે ફેટલ એરર (fatal error) પ્રોસેસને બંધ કરી દે ત્યારે પણ કાર્ય કરે છે. જો ટેક્સની ગણતરી કરતી વખતે અથવા ઓર્ડર સ્ટેટસ બદલતી વખતે તમારો સ્મોક ટેસ્ટ અટકી જાય, તો પણ તે ક્લીનઅપ રૂટિન ચાલવું જ જોઈએ. અન્યથા તમે ઓર્ડર અને પ્રોડક્ટ્સના અવશેષો (orphaned orders and products) પાછળ છોડી દેશો.

ઓર્ફન ડેટા (orphan data) ટાળવા માટે બનાવ્યા પછી તરત જ ID રેકોર્ડ કરો. જે ક્ષણે વર્ચ્યુઅલ પ્રોડક્ટ બનાવવામાં આવે, તેનો ID કેપ્ચર કરો. જે ક્ષણે ટેસ્ટ ઓર્ડર બનાવવામાં આવે, તેનો ID કેપ્ચર કરો. આને તરત જ વેરિયેબલ્સમાં સ્ટોર કરો. તમે હમણાં શું બનાવ્યું તે જાણવા માટે સ્ક્રિપ્ટના અંત સુધી રાહ ન જુઓ. જો સ્ક્રિપ્ટ અધવચ્ચે નિષ્ફળ જાય, તો તમારી પાસે તે ID પહેલેથી જ હોવા જોઈએ જેથી તમારો shutdown handler ચોક્કસપણે જાણી શકે કે શું ડિલીટ કરવાનું છે.

આ ટેસ્ટ યુઝર ઇન્ટરફેસને બાયપાસ કરીને સીધું એપ્લિકેશન લેયર સાથે વાત કરે છે. તે મહત્વપૂર્ણ છે. ફ્રન્ટ એન્ડ કેશ્ડ (cached), મિનિફાઇડ (minified) અથવા ડઝનબંધ બ્રાઉઝર એક્સ્ટેન્શન દ્વારા મેનિપ્યુલેટ થયેલ હોઈ શકે છે. API મૂળ સત્ય રજૂ કરે છે: શું WooCommerce હજુ પણ ઓર્ડર બનાવી શકે છે, ગણતરી કરી શકે છે અને સ્ટેટસ બદલી શકે છે?

સુરક્ષાના બે સ્તરો

તમારે એક્સટર્નલ અને ઇન્ટરનલ બંને મોનિટરિંગની જરૂર છે, અને દરેક સ્તર તમને ખરેખર શું કહે છે તે સમજવાની જરૂર છે.

એક્સટર્નલ મોનિટરિંગ આ પ્રશ્નનો જવાબ આપે છે, "શું લોકો સાઇટ પર પહોંચી શકે છે?" DNS સમસ્યાઓ, SSL એક્સપાયરી, ડાઉન થયેલા સર્વર્સ અને નેટવર્ક પાર્ટિશનિંગ પકડવા માટે તેનો ઉપયોગ કરો. ઇન્ફ્રાસ્ટ્રક્ચર નિષ્ફળતા સામે તે તમારી સુરક્ષાની પ્રથમ લાઇન છે.

ઇન્ટરનલ મોનિટરિંગ આ પ્રશ્નનો જવાબ આપે છે, "શું લોકો કંઈક ખરીદી શકે છે?" તે તમારી એપ્લિકેશનની અંદર રહે છે. તે ઓર્ડર નિષ્ફળતાના દર, ગેટવે મોડ્સ, ચેકઆઉટ દરમિયાન ડેટાબેઝ પરફોર્મન્સ અને તમારા દૈનિક સ્મોક ટેસ્ટના પરિણામો પર નજર રાખે છે. તે બિઝનેસ-લોજિકની એવી નિષ્ફળતાઓ પકડે છે જે કોઈ પણ એક્સટર્નલ પિંગ સર્વિસ ક્યારેય જોઈ શકશે નહીં.

આઉટેજ (outage) ઘોંઘાટવાળું હોય છે. સાઇટ ડાઉન થાય છે, એલર્ટ આવે છે, અને તમે તેને ઠીક કરો છો. ગ્રાહકો કદાચ નારાજ થશે, પરંતુ તેઓ ઘણીવાર પાછા આવે છે. પરંતુ બ્રોકન ચેકઆઉટ શાંત હોય છે. તમારા એડ્સ ચાલતા રહે છે, તમારું એક્વિઝિશન બજેટ વપરાતું રહે છે, અને ગ્રાહકો એક શબ્દ પણ બોલ્યા વિના જતા રહે છે. તમારું અપટાઇમ ડેશબોર્ડ આખા સમય દરમિયાન આશ્વાસન આપતા લીલા રંગમાં જ દેખાશે.

હોમપેજ જોવાનું બંધ કરો. પૈસા પર નજર રાખવાનું શરૂ કરો.