بنيت Gitae لأنني كنت أعود مراراً إلى السؤال العملي نفسه: هل الموقع متوقف فعلاً، أم أن المشكلة موجودة عندي فقط؟
تبويب واحد في المتصفح ليس أداة تشخيص جيدة. قد لا تفتح الصفحة لأن origin server متوقف فعلاً، لكن السبب قد يكون أيضاً DNS أو مشكلة في شهادة HTTPS أو routing أو قاعدة في firewall أو منفذاً مغلقاً أو مفلترًا أو مشكلة لدى ISP أو مسار VPN أو حالة المتصفح أو cache محلي. العرض الظاهر واحد، لكن الإجراء الصحيح قد يكون مختلفاً تماماً.
هذه هي المشكلة التي أردت أن يحلها Gitae: ليس مجرد إظهار مؤشر أخضر أو أحمر، بل مساعدتي على تضييق نطاق العطل إلى الطبقة التي ينبغي فحصها بعد ذلك.
المشكلة الحقيقية خلف عبارة «الموقع متوقف»
كثير من أدوات website checker البسيطة تجيب عن سؤال ضيق: هل رد هذا الرابط من مكان معين في لحظة معينة؟ هذه معلومة مفيدة، لكنها ليست تشخيصاً لسبب الانقطاع.
إذا كان DNS خاطئاً فلن يفيد restart للتطبيق. إذا فشل HTTPS بسبب الشهادة فلن يحل تغيير محتوى الصفحة شيئاً. إذا تعذر الوصول إلى TCP port فقد يظل server نفسه يعمل. وإذا كان الموقع يفتح من server خارجي ولا يفتح من اتصالي، فقد تكون المشكلة في المسار بين شبكتي والوجهة وليس في application server.
لذلك بنيت Gitae على نموذج أبسط وأكثر فائدة: الموقع سلسلة من الاعتماديات، وكل فحص يقدم دليلاً عن جزء واحد فقط من هذه السلسلة.
رؤية خارجية، وليست حكماً مطلقاً
تعمل اختبارات Gitae من خوادم VDS الخاصة بي في موسكو وهلسنكي. هذا يمنحني نقاط مراقبة خارج الكمبيوتر والشبكة التي لاحظت منها المشكلة أول مرة.
إذا فشل الموقع محلياً لكنه رد من موقعي VDS، فهذه إشارة مهمة إلى أن origin على الأقل ليس غير قابل للوصول من كل مكان. عندها أنظر بجدية أكبر إلى DNS المحلي، routing لدى مزود الخدمة، VPN، المتصفح، firewall أو مشكلة مرتبطة بمسار الشبكة. وإذا فشلت الفحوصات البعيدة أيضاً، يصبح فحص server أو DNS أو الشهادة أو routing أو مشكلة شبكة أوسع أكثر منطقية.
لكن remote check ليس تلقائياً «أكثر موثوقية» من local check. موقعان فقط لا يمثلان الإنترنت كله. قد يعمل الموقع من موسكو وهلسنكي ويتعطل من بلد آخر أو ISP آخر أو CDN edge آخر. أتعامل مع النتيجة البعيدة كنقطة مراقبة إضافية، لا كحكم عالمي.
ما الذي يفحصه Gitae حالياً؟
- Website check — يفحص ما إذا كان URL يرد من server خارجي.
- SSL check — يفحص حالة شهادة HTTPS/TLS والمشكلات المتعلقة بها.
- DNS check وnslookup وdig — تساعد على رؤية كيفية resolve للدومين وما هي سجلات DNS التي تعاد.
- Reverse DNS وIP check — تعرض معلومات IP وبيانات PTR/reverse-DNS.
- Domain info وdomain age — توفر metadata أساسية عن الدومين.
- Port check — يختبر إمكانية الوصول إلى المنفذ المستهدف من موقع الفحص.
- Find your IP — يعرض الـ public IP الذي تراه الخدمة.
- Ping وtraceroute — يوفران إشارات شبكة عن latency وpacket loss والمسار نحو host.
- Hosting check وCMS detection — تعرض إشارات عن البنية التحتية والتقنيات يمكن أن تساعد في التعرف عليها.
أتعمد التعامل مع هذه النتائج باعتبارها إشارات. سجل PTR لا يثبت من يملك server. اكتشاف CMS من public fingerprints لا يثبت الـ software stack بدقة. والمنفذ غير القابل للوصول من probe واحد قد يكون مفلترًا في الطريق بدلاً من أن يكون مغلقاً للجميع.
كيف أقرأ النتائج؟
القيمة الحقيقية تظهر عند جمع عدة فحوصات بدلاً من قراءة كل نتيجة منفردة.
إذا أعاد DNS العنوان المتوقع، وكانت شهادة HTTPS valid، ورد الموقع من خادمي VDS، لكنه ما زال لا يفتح عندي محلياً، فسأفحص المسار المحلي بعمق قبل أن أغيّر server. والعكس صحيح: إذا كانت نتائج DNS غير متسقة أو فشل remote website check أيضاً، فهناك أسباب أقوى لفحص البنية التحتية.
يجب كذلك قراءة ping وtraceroute بحذر. قد يتم filter أو rate-limit لـ ICMP. عدم ظهور hop في traceroute لا يعني تلقائياً أن ذلك node معطل، وhost الذي لا يرد على ping قد يقدم HTTPS بشكل طبيعي. هذه الأدوات تضيف context، لكنها لا تمنح تشخيصاً نهائياً.
قاعدتي الأساسية هي: نجاح فحص واحد لا يثبت أن النظام كله سليم، وفشل فحص واحد لا يشرح السبب وحده.
التوفر وSEO ليسا الشيء نفسه
Availability مهم أيضاً للـ SEO، لكن technical outage لا يساوي ranking problem. Crawling ليس indexing، وindexing ليس traffic.
إذا لم يتمكن crawler من الوصول إلى الموقع بسبب DNS أو network أو server error، فلن يستطيع جلب المحتوى المتأثر بنجاح في تلك اللحظة. توضح Google أن network وDNS errors أثناء crawling تُعامل بطريقة مشابهة لأخطاء server-side 5xx، وأن عدم التوفر لفترة طويلة قد يؤثر في crawl وفي URLات المفهرسة بالفعل. لكن هذا لا يعني أن كل outage قصير يسبب خسارة SEO تلقائياً، ولا يمكن لأداة تشخيص أن تثبت أن تغير traffic لاحقاً سببه هذا الانقطاع تحديداً.
بالنسبة للمستخدمين المنطق أبسط: إذا لم يستطيعوا فتح الموقع فلن يستطيعوا استخدامه. بحسب المشروع قد يعني ذلك فقدان sessions أو leads أو conversions أو revenue. لكن نتيجة الفحص التقني لا تحسب هذا الأثر التجاري.
ترتيب عملي لفحص موقع «متوقف»
- أكد العرض من شبكة أخرى. لا تفترض أن متصفحك المحلي يمثل الإنترنت كله.
- افحص DNS. تأكد من resolve للدومين ومن السجلات المتوقعة.
- افحص HTTPS/TLS. راجع صلاحية الشهادة وأخطاء الاتصال.
- افحص المنفذ المطلوب. اختبر إمكانية الوصول إليه من probe.
- قارن إشارات الشبكة. استخدم ping وtraceroute كبيانات مساعدة.
- راجع IP وreverse DNS وhosting وCMS. يمكن لهذه الإشارات أن تساعدك على التأكد من أنك تصل إلى البنية التحتية المتوقعة.
- بعد ذلك فقط ضيق نطاق التحقيق. حدد ما إذا كانت الأدلة تشير أكثر إلى التطبيق أو server أو DNS أو network path أو البيئة المحلية.
هذا ليس incident response protocol صالحاً لكل حالة. بالنسبة لي هو طريقة لتجنب الخطأ الذي أردت التخلص منه: تعديل الطبقة الخطأ لمجرد أن المعلومة الوحيدة في البداية هي «الموقع لا يفتح».
الفائدة الحقيقية أولاً، ثم monetization
حالياً لا توجد monetization في Gitae. بنيته أولاً لنفسي لأنني أردت طريقة سريعة لفحص الموقع من خارج جهازي ثم الانتقال مباشرة إلى DNS والشهادة والمنافذ والشبكة من دون القفز بين أدوات منفصلة.
هدفي الآن هو جعل diagnostics أكثر فائدة ومعرفة هل يستطيع المشروع جذب organic traffic عبر SEO والطلب الحقيقي. إذا وصل حتى إلى traffic متوسط، أريد إضافة automated website monitoring مع instant messenger alerts. ستكون الفكرة نفسها ممتدة من التشخيص اليدوي إلى الاكتشاف: معرفة أن شيئاً أصبح unavailable، ثم إعطاء المالك معلومات كافية ليبدأ التحقيق بسرعة.
الفكرة الأساسية أريدها أن تبقى بسيطة
«Up» و«down» أعراض، وليسا تفسيراً.
DNS وHTTPS/TLS وrouting والمنافذ وhosting والتطبيق وشبكة المستخدم نفسه كلها قد تنتج مشكلة availability تبدو بسيطة. Gitae لا يجد كل root cause بطريقة سحرية، وخادمان خارجيان لا يخبرانني بما يراه الإنترنت كله. لكنه يستطيع جمع عدة إشارات مستقلة في مكان واحد.
هذه هي الأداة التي أردتها لنفسي: الانتقال من «الموقع لا يفتح» إلى سؤال أكثر فائدة بكثير: «أي طبقة يجب أن أفحصها بعد ذلك؟»