آپ کا اپ ٹائم ڈیش بورڈ آپ کو دھوکہ دے رہا ہے۔ یہ کہتا ہے کہ آپ کی سائٹ آن لائن ہے۔ ہوم پیج لوڈ ہو رہا ہے۔ SSL سرٹیفکیٹ درست ہے۔ ہر پکسل بالکل اپنی صحیح جگہ پر نظر آ رہا ہے۔ اس کے باوجود، آپ کے اسٹور نے چھ گھنٹوں سے کوئی حقیقی آرڈر پراسیس نہیں کیا، اور آپ کو یہ بات بتانے والا پہلا شخص آپ کا کلائنٹ ہے جو یہ پوچھ رہا ہے کہ روزانہ کی سیلز رپورٹ کیوں رک گئی ہے۔

یہ ایک ای کامرس پلیٹ فارم کو محض ایک معلوماتی (brochure) سائٹ سمجھنے کی بنیادی خامی ہے۔ معیاری اپ ٹائم مانیٹرنگ صرف ایک ہی سوال پوچھتی ہے: کیا سرور نے 200 OK اسٹیٹس واپس کیا؟ ایک WooCommerce اسٹور کے لیے، یہ سوال اصل مقصد سے بالکل ہٹ جاتا ہے۔ سرور بالکل ٹھیک کام کر رہا ہو سکتا ہے، چیک آؤٹ پیج بالکل درست نظر آ سکتا ہے، لیکن پھر بھی پیسے آنا بند ہو سکتے ہیں۔ یہ ایک خاموش ناکامی ہے، اور یہ سرور کے کریش ہونے (جو کہ واضح ہوتا ہے) سے کہیں زیادہ مہنگی پڑتی ہے۔

جب "آن لائن" ہونے کا کوئی مطلب نہ رہے

ایک 200 رسپانس صرف یہ ثابت کرتا ہے کہ PHP نے اپنا کام مکمل کر لیا ہے اور براؤزر کو HTML واپس بھیج دیا ہے۔ یہ اس بات کا ثبوت نہیں ہے کہ Stripe کا JavaScript لوڈ ہو گیا ہے۔ یہ اس بات کا ثبوت نہیں ہے کہ 'place-order' بٹن ایک کام کرنے والے اینڈ پوائنٹ پر ڈیٹا بھیجتا ہے۔ یہ اس بات کا ثبوت نہیں ہے کہ ویب ہک (webhook) چلا، اسٹاک ایڈجسٹ ہوا، یا کنفرمیشن ای میل بھیجی گئی۔ ایک وزیٹر کو مکمل لوڈ شدہ چیک آؤٹ نظر آتا ہے، وہ کارڈ نمبر درج کرتا ہے، 'buy' پر کلک کرتا ہے، اور کچھ نہیں ہوتا۔ یا اس سے بھی بدتر، آرڈر 'فیلڈ' کے طور پر ریکارڈ ہوتا ہے جبکہ ادائیگی درحقیقت مکمل ہو چکی ہوتی ہے۔

اگر آپ کی مانیٹرنگ کی حکمت عملی صرف ہوم پیج کو پنگ (ping) کرنے تک محدود ہے، تو آپ غلط چیز دیکھ رہے ہیں۔ آپ کو اس تھیم کریش کا پتہ چلے گا جو ہیڈر کو خراب کر دے، لیکن آپ کو اس پیمنٹ گیٹ وے کا پتہ نہیں چلے گا جو ٹیسٹ موڈ میں پھنس گیا ہے۔ آپ کو اس کا علم صرف تب ہوگا جب کوئی ریونیو گراف چیک کرے گا یا کسی غصے بھرے فون کال کا جواب دے گا۔

پانچ طریقے جن سے اسٹور ڈاؤن ہوئے بغیر ختم ہو جاتا ہے

یہ وہ مخصوص ناکامیاں ہیں جو ایک WooCommerce اسٹور کو 100% اپ ٹائم پر رکھتی ہیں جبکہ کنورژن (conversion) صفر ہو جاتی ہے:

  • پیمنٹ گیٹ ویز ٹیسٹ موڈ میں پھنس جاتے ہیں۔ ایک ڈویلپر کسی بگ (bug) کو دوبارہ پیدا کرنے کے لیے Stripe یا PayPal کو سینڈ باکس (sandbox) پر سوئچ کرتا ہے، مسئلہ حل کرتا ہے، اور دوبارہ اصلی موڈ پر لانا بھول جاتا ہے۔ حقیقی صارفین اصلی کارڈ نمبر درج کرتے ہیں اور ٹیسٹ موڈ کی دیوار سے ٹکرا جاتے ہیں۔ کبھی کبھی غلطی واضح ہوتی ہے؛ کبھی کبھی نہیں، اور ٹرانزیکشن بس لٹک جاتی ہے۔
  • پلگ ان اپ ڈیٹ چیک آؤٹ ٹیمپلیٹ کو خراب کر دیتی ہے۔ WooCommerce ایک اپ ڈیٹ جاری کرتا ہے، یا کوئی پیج بلڈر تبدیلی کرتا ہے، اور چیک آؤٹ فارم اب درست طریقے سے نظر نہیں آتا۔ پیج لوڈ ہوتا ہے، لیکن بلنگ کے فیلڈز غائب ہو جاتے ہیں، یا 'place-order' بٹن پر کلک کرنے سے JavaScript ایرر آتا ہے۔ سرور ٹھیک ہے، لیکن صارف کا تجربہ (user experience) خراب ہو چکا ہے۔
  • گیٹ وے کی غلطیوں کی وجہ سے فیلڈ آرڈرز میں اضافہ ہوتا ہے۔ API کیز (keys) کی میعاد ختم ہو جاتی ہے۔ کرنسی کا فرق ظاہر ہوتا ہے۔ 3D Secure کی ضروریات بدل جاتی ہیں۔ یہ غلطیاں WooCommerce ایڈمن میں فیلڈ آرڈرز کے طور پر نظر آتی ہیں، نہ کہ آپ کے اپ ٹائم لاگز میں سرور ایررز کے طور پر۔ اگر آپ غلط اسکرین دیکھ رہے ہیں، تو آپ آمدنی کے اس خاموش نقصان کو نہیں دیکھ پائیں گے۔
  • سرور سائیڈ آرڈر پائپ لائن رک جاتی ہے۔ کسی تھرڈ پارٹی ERP انٹیگریشن، کسٹم اسٹاک سنک فنکشن، یا شپنگ ریٹ کیلکولیٹر کی وجہ سے کسٹمر کے 'buy' پر کلک کرنے کے بعد ٹائم آؤٹ ہو جاتا ہے۔ آرڈر غیر معینہ مدت کے لیے 'پینڈنگ' اسٹیٹس میں رہتا ہے۔ کسٹمر پیج ریفریش کرتا ہے، الجھن کا شکار ہوتا ہے، اور چلا جاتا ہے۔ آپ کے ہوسٹنگ میٹرکس اب بھی 'گرین' نظر آتے ہیں۔
  • آرڈر کا بہاؤ بغیر کسی واضح وجہ کے رک جاتا ہے۔ کوئی فیٹل ایرر (fatal error) نہیں ہوتا۔ کوئی پلگ ان کا ٹکراؤ (conflict) نہیں ہوتا۔ کیش (cache) بس پرانا چیک آؤٹ JavaScript دکھانا شروع کر دیتا ہے۔ ایک کنسنٹ مینجمنٹ بینر پیمنٹ آئی فریم (iframe) کو روک دیتا ہے۔ ایک CDN ایج نوڈ اسکرپٹ کا پرانا ورژن فراہم کرتا ہے۔ سائٹ آن لائن ہے، لیکن چیک آؤٹ کام نہیں کر رہا۔

ان چیزوں کی نگرانی کریں جو اصل میں اہمیت رکھتی ہیں

ان ناکامیوں کو پکڑنے کے لیے، آپ کو انفراسٹرکچر پر نظر رکھنا چھوڑ کر بزنس لاجک پر نظر رکھنی ہوگی۔ یہاں ایک ایسی مانیٹرنگ حکمت عملی بنانے کا طریقہ ہے جو حقیقی ٹرانزیکشن فلو کی پیچیدگی کو مدنظر رکھتی ہے۔

صرف اپ ٹائم نہیں، بلکہ آرڈر فلو کی نگرانی کریں۔ ٹریک کریں کہ آیا کوئی پروڈکٹ کارٹ میں شامل کی جا سکتی ہے، آیا چیک آؤٹ اینڈ پوائنٹ درست JSON کے ساتھ جواب دیتا ہے، اور کیا کامیاب ادائیگی کے بعد 'تھینک یو' پیج لوڈ ہوتا ہے۔ اگر آپ بیرونی پنگ ٹولز پر انحصار کرتے ہیں، تو انہیں صرف ڈومین روٹ کے بجائے کریٹیکل پاتھ (critical path) کو ہٹ کرنے کے لیے کنفیگر کریں۔

فیلڈ آرڈرز کا موازنہ سات دن کے بیس لائن (baseline) سے کریں۔ مطلق اعداد و شمار استعمال نہ کریں۔ کسی پروموشن کے بعد پیر کی صبح ایک گھنٹے میں پانچ فیلڈ آرڈرز نارمل ہو سکتے ہیں۔ لیکن کسی پرسکون بدھ کی دوپہر کو ایک گھنٹے میں پانچ فیلڈ آرڈرز خطرے کی گھنٹی ہیں۔ اپنی ہی رولنگ بیس لائن سے ہونے والے انحراف کو دیکھیں، نہ کہ کسی من مانے حد (threshold) کو۔

چیک کریں کہ آیا لائیو گیٹ ویز (gateways) سینڈ باکس موڈ میں ہیں یا نہیں۔ اسے اپنی ڈیپلائمنٹ چیک لسٹ اور اپنے خودکار (automated) ٹیسٹ کا حصہ بنائیں۔ ایکٹو گیٹ وے سیٹنگز کا معائنہ کریں، یا پبلک API کیز کا تجزیہ کریں تاکہ اس بات کو یقینی بنایا جا سکے کہ وہ پروڈکشن کریڈنشلز ہیں۔ کوئی بھی اسٹور کبھی بھی ٹیسٹ انوائرمنٹ سے منسلک رہتے ہوئے لائیو نہیں جانا چاہیے۔

روزانہ سرور سائیڈ اسموک ٹیسٹ (smoke test) چلائیں۔ یہ چیک آؤٹ کے ناکام ہونے کا پتہ لگانے کے لیے انسانی آنکھوں سے پہلے کام کرنے والا سب سے مؤثر حفاظتی جال ہے۔

روزانہ اسموک ٹیسٹ کی تیاری

ایک مناسب اسموک ٹیسٹ آپ کے ڈیٹا بیس میں انتشار پیدا کیے بغیر ایک حقیقت پسندانہ آرڈر تخلیق کرتا ہے۔ اس کا طریقہ کار کچھ یوں ہے: ایک پوشیدہ ورچوئل پروڈکٹ تیار کریں، WooCommerce API کے ذریعے ایک ٹیسٹ آرڈر چلائیں، اس بات کی تصدیق کریں کہ ٹوٹل (totals) درست طریقے سے کیلکولیٹ ہو رہے ہیں، آرڈر کو اس کے مختلف اسٹیٹس (statuses) سے گزاریں، اور پھر ہر چیز (artifact) کو حذف کر دیں۔

اس کے نفاذ (implementation) کی تفصیلات اہمیت رکھتی ہیں۔ اگر آپ صفائی (cleanup) کا خیال احتیاط سے نہیں رکھیں گے، تو آپ کی رپورٹس جعلی آرڈرز اور فرضی مصنوعات سے بھر جائیں گی۔

ٹیسٹ کے دوران WooCommerce ای میلز کو روک دیں۔ آپ بالکل بھی نہیں چاہیں گے کہ اسٹور کا مالک یا کوئی اصل ایڈمن رات کے 3:00 بجے "New Order" کی ای میل وصول کرے کیونکہ کسی کرون جاب (cron job) نے اپنا روزانہ کا چیک مکمل کیا ہے۔ اسکرپٹ کے دوران باہر جانے والے نوٹیفیکیشنز کو غیر فعال کر دیں، یا ٹیسٹ آرڈر آئی ڈیز (IDs) سے منسلک کسی بھی ای میل کو بلاک کرنے کے لیے فلٹر کا استعمال کریں۔

اگر اسکرپٹ کریش ہو جائے تو ڈیٹا کی صفائی کے لیے شٹ ڈاؤن فنکشن (shutdown function) کا استعمال کریں۔ PHP آپ کو ایک شٹ ڈاؤن فنکشن رجسٹر کرنے کی اجازت دیتا ہے جو اس وقت بھی چلتا ہے جب کوئی فیٹل ایرر (fatal error) پروسیس کو ختم کر دے۔ اگر آپ کا اسموک ٹیسٹ ٹیکس کیلکولیٹ کرتے ہوئے یا آرڈر کے اسٹیٹس تبدیل کرتے ہوئے رک جائے، تب بھی صفائی کا وہ عمل (cleanup routine) چلنا چاہیے۔ ورنہ آپ کے پیچھے یتیم (orphaned) آرڈرز اور مصنوعات رہ جائیں گی۔

یتیم ڈیٹا سے بچنے کے لیے تخلیق کے فوراً بعد آئی ڈیز (IDs) ریکارڈ کریں۔ جیسے ہی ورچوئل پروڈکٹ تخلیق ہو، اس کی آئی ڈی حاصل کر لیں۔ جیسے ہی ٹیسٹ آرڈر تخلیق ہو، اس کی آئی ڈی حاصل کر لیں۔ انہیں فوراً ویری ایبلز (variables) میں محفوظ کر لیں۔ اسکرپٹ کے اختتام تک انتظار نہ کریں کہ ڈیٹا بیس سے پوچھا جائے کہ آپ نے ابھی کیا بنایا ہے۔ اگر اسکرپٹ دورانِ عمل ناکام ہو جائے، تو آپ کو وہ آئی ڈیز پہلے سے چاہیے ہوں گی تاکہ آپ کا شٹ ڈاؤن ہینڈلر (shutdown handler) جان سکے کہ بالکل کیا حذف کرنا ہے۔

یہ ٹیسٹ یوزر انٹرفیس (user interface) کو نظر انداز کر کے براہ راست ایپلی کیشن لیئر (application layer) سے بات کرتا ہے۔ یہ اہم ہے۔ فرنٹ اینڈ (front end) کیش شدہ (cached)، منٹی فائیڈ (minified) یا درجنوں براؤزر ایکسٹینشنز کے ذریعے تبدیل شدہ ہو سکتا ہے۔ API اصل حقیقت کی نمائندگی کرتی ہے: کیا WooCommerce اب بھی آرڈر تخلیق، کیلکولیٹ اور تبدیل کر سکتا ہے؟

تحفظ کی دو تہیں

آپ کو بیرونی اور اندرونی دونوں طرح کی مانیٹرنگ کی ضرورت ہے، اور آپ کو یہ سمجھنے کی ضرورت ہے کہ ہر تہہ آپ کو اصل میں کیا بتاتی ہے۔

بیرونی مانیٹرنگ اس سوال کا جواب دیتی ہے، "کیا لوگ سائٹ تک پہنچ سکتے ہیں؟" اسے DNS کے مسائل، SSL کی میعاد ختم ہونے، ڈاؤن شدہ سرورز اور نیٹ ورک پارٹیشننگ (network partitioning) کو پکڑنے کے لیے استعمال کریں۔ یہ انفراسٹرکچر کی ناکامیوں کے خلاف آپ کی دفاع کی پہلی لائن ہے۔

اندرونی مانیٹرنگ اس سوال کا جواب دیتی ہے، "کیا لوگ کچھ خرید سکتے ہیں؟" یہ آپ کی ایپلی کیشن کے اندر ہوتی ہے۔ یہ آرڈر کی ناکامی کی شرح، گیٹ وے موڈز، چیک آؤٹ کے دوران ڈیٹا بیس کی کارکردگی، اور آپ کے روزانہ کے اسموک ٹیسٹ کے نتائج کو دیکھتی ہے۔ یہ بزنس لاجک (business-logic) کی ان ناکامیوں کو پکڑتی ہے جنہیں کوئی بھی بیرونی پنگ سروس (ping service) کبھی نہیں دیکھ سکے گی۔

سرور کا بند ہونا (outage) شور مچاتا ہے۔ سائٹ ڈاؤن ہوتی ہے، الرٹ بجتا ہے، اور آپ اسے ٹھیک کر دیتے ہیں۔ گاہک شاید شکوہ کریں، لیکن وہ اکثر واپس آ جاتے ہیں۔ لیکن ایک خراب چیک آؤٹ خاموش ہوتا ہے۔ آپ کے اشتہارات چلتے رہتے ہیں، آپ کا کسٹمر حاصل کرنے کا بجٹ جلتا رہتا ہے، اور گاہک ایک لفظ کہے بغیر چلے جاتے ہیں۔ آپ کا اپ ٹائم ڈیش بورڈ (uptime dashboard) اس پورے وقت اطمینان بخش سبز رنگ میں رہتا ہے۔

ہوم پیج کو دیکھنا چھوڑیں۔ پیسے پر نظر رکھنا شروع کریں۔