Gitae را ساختم تا قطعی سایت را فراتر از یک جواب سادهٔ «بالاست یا پایین» عیب‌یابی کنم

Gitae را ساختم چون بارها به یک سؤال عملی برمی‌خوردم: آیا سایت واقعاً down است، یا مشکل فقط از سمت من است؟

یک تب مرورگر ابزار تشخیص خوبی نیست. صفحه ممکن است به‌خاطر down بودن origin server باز نشود، اما علت می‌تواند DNS، مشکل certificate در HTTPS، routing، قانون firewall، پورت بسته یا فیلترشده، ISP، مسیر VPN، وضعیت browser یا cache محلی هم باشد. علامت ظاهری یکی است، اما کاری که باید انجام داد می‌تواند کاملاً متفاوت باشد.

مسئله‌ای که می‌خواستم Gitae حل کند همین بود: نه فقط یک وضعیت سبز یا قرمز، بلکه کمک برای محدود کردن مشکل به layer بعدی که ارزش بررسی دارد.

مشکل واقعی پشت جملهٔ «سایت down است»

بسیاری از website checkerهای ساده فقط یک سؤال محدود را جواب می‌دهند: آیا این URL در این لحظه از این مکان پاسخ داد؟ این اطلاعات مفید است، اما هنوز تشخیص outage نیست.

اگر DNS اشتباه باشد، restart کردن application چیزی را درست نمی‌کند. اگر HTTPS به‌خاطر certificate شکست بخورد، تغییر محتوای صفحه بی‌ربط است. اگر TCP port در دسترس نباشد، خود server ممکن است همچنان کار کند. و اگر سایت از یک server خارجی باز شود ولی از اتصال من نه، مشکل می‌تواند جایی در مسیر بین network من و مقصد باشد، نه در application server.

به همین دلیل Gitae را بر اساس یک مدل کاربردی‌تر ساختم: سایت زنجیره‌ای از dependencyهاست و هر check فقط دربارهٔ بخشی از این زنجیره شواهد می‌دهد.

دید خارجی، نه حکم مطلق

بررسی‌های Gitae از VDS serverهای خودم در مسکو و هلسینکی اجرا می‌شوند. این کار به من نقاط مشاهده‌ای خارج از کامپیوتر و شبکه‌ای می‌دهد که مشکل را اول بار در آن دیدم.

اگر سایت در local باز نشود ولی از هر دو VDS پاسخ بدهد، این یک نشانهٔ مهم است: origin حداقل برای همه‌جا unreachable نیست. در این حالت بیشتر به local DNS، routing شرکت ISP، VPN، browser، firewall یا مشکل وابسته به network path نگاه می‌کنم. اگر remote probeها هم شکست بخورند، دلیل بیشتری برای بررسی server، DNS، certificate، routing یا مشکل گسترده‌تر شبکه وجود دارد.

با این حال remote check به‌صورت خودکار «قابل‌اعتمادتر» از local check نیست. دو نقطهٔ VDS نمایندهٔ کل اینترنت نیستند. سایت می‌تواند از مسکو و هلسینکی کار کند و از کشور، ISP، CDN edge یا network دیگری مشکل داشته باشد. من نتیجهٔ remote را یک نقطهٔ مشاهدهٔ اضافه می‌دانم، نه حکم جهانی.

Gitae امروز چه چیزهایی را بررسی می‌کند

• Website check — بررسی می‌کند URL از یک server خارجی پاسخ می‌دهد یا نه.
• SSL check — وضعیت certificate مربوط به HTTPS/TLS و مشکلات مرتبط با آن را بررسی می‌کند.
• DNS check، nslookup و dig — نشان می‌دهند domain چگونه resolve می‌شود و چه DNS recordهایی برمی‌گردند.
• Reverse DNS و IP check — اطلاعات IP و داده‌های PTR/reverse-DNS را نشان می‌دهند.
• Domain info و domain age — metadata پایهٔ domain را فراهم می‌کنند.
• Port check — دسترسی به target port را از محل probe تست می‌کند.
• Find your IP — public IP قابل مشاهده برای service را نشان می‌دهد.
• Ping و traceroute — نشانه‌های شبکه دربارهٔ latency، packet loss و مسیر تا host می‌دهند.
• Hosting check و CMS detection — نشانه‌های infrastructure و technology را برای کمک به شناسایی نشان می‌دهند.

عمداً این نتایج را «نشانه» می‌دانم. PTR record ثابت نمی‌کند مالک server چه کسی است. CMS detection بر اساس public fingerprintها software stack دقیق را ثابت نمی‌کند. پورتی که از یک probe قابل دسترسی نیست ممکن است در مسیر فیلتر شده باشد، نه اینکه برای همه بسته باشد.

چطور نتایج را تفسیر می‌کنم

ارزش اصلی وقتی به دست می‌آید که چند check را کنار هم ببینیم.

اگر DNS آدرس مورد انتظار را برگرداند، HTTPS certificate valid باشد و سایت از هر دو VDS پاسخ بدهد اما local همچنان باز نشود، قبل از تغییر server مسیر محلی را بیشتر بررسی می‌کنم. اگر DNS ناسازگار باشد یا remote website check هم fail شود، دلیل بیشتری برای بررسی infrastructure دارم.

Ping و traceroute هم باید با احتیاط خوانده شوند. ICMP ممکن است filter یا rate-limit شود. ناپدید شدن یک hop در traceroute لزوماً به معنی خراب بودن آن node نیست، و hostی که به ping جواب نمی‌دهد ممکن است HTTPS را کاملاً عادی سرو کند. این ابزارها context اضافه می‌کنند؛ تشخیص نهایی نمی‌دهند.

اصل اصلی من این است: یک check موفق سلامت کل system را ثابت نمی‌کند، و یک check ناموفق هم به‌تنهایی علت را توضیح نمی‌دهد.

Availability و SEO یک چیز نیستند

Availability برای SEO هم مهم است، اما technical outage همان ranking problem نیست. Crawling همان indexing نیست و indexing هم traffic نیست.

اگر crawler به دلیل DNS، network یا server error نتواند به سایت برسد، در آن لحظه نمی‌تواند محتوای تحت‌تأثیر را با موفقیت دریافت کند. Google مستند کرده که network و DNS error در crawling مشابه server-side 5xx errorها در نظر گرفته می‌شوند و unavailable بودن طولانی می‌تواند روی crawl و URLهای indexشده اثر بگذارد. اما این به معنی آن نیست که هر outage کوتاه خودکار باعث ضرر SEO می‌شود، و diagnostic tool هم نمی‌تواند ثابت کند تغییر بعدی traffic دقیقاً از همان outage ناشی شده است.

برای user منطق ساده‌تر است: اگر سایت را باز نکند، نمی‌تواند از آن استفاده کند. بسته به پروژه این می‌تواند به session، lead، conversion یا revenue از دست‌رفته منجر شود. ولی check فنی این business impact را محاسبه نمی‌کند.

ترتیب عملی برای بررسی یک سایت «down»

1. علامت را از network دیگری تأیید کن. فرض نکن browser محلی نمایندهٔ کل اینترنت است.
2. DNS را بررسی کن. resolve شدن domain و recordهای مورد انتظار را تأیید کن.
3. HTTPS/TLS را بررسی کن. validity گواهی و connection errorها را ببین.
4. پورت لازم را بررسی کن. دسترسی از محل probe را تست کن.
5. Network signalها را مقایسه کن. ping و traceroute را به‌عنوان دادهٔ کمکی استفاده کن.
6. IP، reverse DNS، hosting و CMS را ببین. این نشانه‌ها کمک می‌کنند مطمئن شوی به infrastructure مورد انتظار می‌رسی.
7. بعد محدودهٔ بررسی را کوچک کن. تصمیم بگیر شواهد بیشتر به application، server، DNS، network path یا local environment اشاره دارند.

این یک incident response protocol جهانی نیست. برای من روشی است برای جلوگیری از همان اشتباهی که می‌خواستم حذف کنم: تغییر دادن layer اشتباه فقط چون تنها اطلاعات اولیه «سایت باز نمی‌شود» است.

اول استفادهٔ واقعی، بعد monetization

Gitae فعلاً monetized نیست. ابتدا آن را برای خودم ساختم چون می‌خواستم سایت را سریع از خارج کامپیوتر خودم بررسی کنم و بعد مستقیم سراغ DNS، certificate، port و network diagnostics بروم، بدون اینکه بین ابزارهای جداگانه جابه‌جا شوم.

هدف فعلی من مفیدتر کردن diagnostics و دیدن این است که آیا پروژه می‌تواند از SEO و تقاضای واقعی organic traffic بگیرد. اگر حتی traffic متوسطی به دست آورد، می‌خواهم automated website monitoring با instant messenger alert اضافه کنم. این ادامهٔ همان ایده از manual diagnosis به detection است: فهمیدن اینکه چیزی unavailable شده و دادن اطلاعات کافی به owner برای شروع سریع بررسی.

هستهٔ ایده باید ساده بماند

«Up» و «down» علامت‌اند، نه توضیح.

DNS، HTTPS/TLS، routing، port، hosting، application و network خود کاربر همگی می‌توانند یک availability problem ساده‌نما ایجاد کنند. Gitae به شکل جادویی هر root cause را پیدا نمی‌کند و آن نقاط VDS خارجی نشان نمی‌دهند کل اینترنت چه می‌بیند. اما می‌تواند چند signal مستقل را در یک جا جمع کند.

این همان ابزاری بود که می‌خواستم: کمک کند از «سایت باز نمی‌شود» به سؤال بسیار مفیدتری برسم: «بعدی کدام layer را باید بررسی کنم؟»