আমি Gitae বানিয়েছি কারণ বারবার একই practical প্রশ্নের মুখোমুখি হতাম: website সত্যিই down, নাকি সমস্যা শুধু আমার দিক থেকে?
একটি browser tab ভালো diagnostic tool নয়। Page না খোলার কারণ origin server down হতে পারে, কিন্তু DNS, HTTPS certificate, routing, firewall rule, বন্ধ বা filtered port, ISP, VPN path, browser state বা local cache-ও একই symptom তৈরি করতে পারে। বাইরে থেকে ফল একই দেখায়, কিন্তু সঠিক action সম্পূর্ণ আলাদা হতে পারে।
Gitae দিয়ে আমি এই সমস্যাটাই সমাধান করতে চেয়েছি: শুধু green বা red status নয়, বরং issue-টাকে এমন একটি layer পর্যন্ত narrow করা যেটা পরের ধাপে পরীক্ষা করা উচিত।
“Website down” বলার পিছনে আসল সমস্যা
অনেক simple website checker শুধু একটি narrow প্রশ্নের উত্তর দেয়: একটি নির্দিষ্ট সময়ে একটি নির্দিষ্ট location থেকে URL response দিয়েছিল কি? তথ্যটি useful, কিন্তু এটি outage diagnosis নয়।
DNS ভুল হলে application restart করে লাভ নেই। HTTPS certificate-এর কারণে fail করলে page content বদলানো irrelevant। TCP port unreachable হলেও server নিজে চালু থাকতে পারে। আর site external server থেকে খুললেও আমার connection থেকে না খুললে সমস্যা application server-এ নয়, আমার network আর destination-এর মাঝের path-এ হতে পারে।
তাই Gitae-কে আমি একটি সহজ model-এর ওপর বানিয়েছি: website হলো dependency-এর chain, আর প্রতিটি check সেই chain-এর শুধু একটি অংশ সম্পর্কে evidence দেয়।
External viewpoint, কিন্তু absolute truth নয়
Gitae-এর checks আমার Moscow এবং Helsinki-এর VDS server থেকে চলে। এতে problem প্রথম যেখানে দেখেছি, সেই computer ও network-এর বাইরে observation point পাই।
Site local-এ fail করলেও দুই VDS থেকেই respond করলে এটি useful signal: origin অন্তত সব জায়গা থেকে unreachable নয়। তখন local DNS, ISP routing, VPN, browser, firewall বা নির্দিষ্ট network path-এর সমস্যা বেশি গুরুত্ব দিয়ে দেখি। Remote probe-ও fail করলে server, DNS, certificate, routing বা বড় network issue investigate করার কারণ শক্ত হয়।
তবে remote check নিজে থেকেই local check-এর চেয়ে “more reliable” নয়। দুই VDS location পুরো Internet-কে represent করে না। Moscow ও Helsinki থেকে site চলতে পারে, কিন্তু অন্য country, ISP, CDN edge বা network থেকে fail করতে পারে। আমার কাছে remote result হলো extra observation point, global verdict নয়।
Gitae এখন কী কী check করে
- Website check — external server থেকে URL respond করছে কি না দেখে।
- SSL check — HTTPS/TLS certificate status এবং certificate-related problem পরীক্ষা করে।
- DNS check, nslookup এবং dig — domain কীভাবে resolve হচ্ছে এবং কোন DNS records ফিরছে তা দেখায়।
- Reverse DNS এবং IP check — IP information এবং PTR/reverse-DNS data দেখায়।
- Domain info এবং domain age — domain-এর basic metadata দেয়।
- Port check — probe location থেকে target port reachable কি না test করে।
- Find your IP — service যে public IP দেখতে পাচ্ছে তা দেখায়।
- Ping এবং traceroute — latency, packet loss এবং host পর্যন্ত path নিয়ে network signal দেয়।
- Hosting check এবং CMS detection — infrastructure ও technology সম্পর্কে identification signal দেখায়।
আমি ইচ্ছা করেই এই result-গুলোকে signal হিসেবে দেখি। PTR record server owner prove করে না। Public fingerprint-ভিত্তিক CMS detection exact software stack prove করে না। একটি probe থেকে unreachable port মাঝপথে filtered হতে পারে; সবার জন্য closed হওয়া জরুরি নয়।
আমি result কীভাবে interpret করি
আসল value আসে যখন একাধিক check একসঙ্গে পড়া হয়।
DNS expected address দেয়, HTTPS certificate valid, দুই VDS থেকেই site respond করে, কিন্তু local-এ এখনও খুলছে না—এমন হলে server বদলানোর আগে আমি local path আরও গভীরে দেখি। DNS inconsistent হলে বা remote website check-ও fail করলে infrastructure side investigate করার বেশি কারণ থাকে।
Ping এবং traceroute-ও সাবধানে পড়তে হয়। ICMP filter বা rate-limit হতে পারে। Traceroute-এ missing hop মানেই node broken নয়, আর ping reply না করা host HTTPS স্বাভাবিকভাবে serve করতে পারে। এগুলো context দেয়, final diagnosis নয়।
আমার মূল rule হলো: একটি successful check পুরো system healthy prove করে না, আর একটি failed check একাই cause explain করে না।
Availability আর SEO একই বিষয় নয়
Availability SEO-এর জন্যও important, কিন্তু technical outage ranking problem-এর সমান নয়। Crawling indexing নয়, আর indexing traffic নয়।
Crawler যদি DNS, network বা server error-এর কারণে site-এ পৌঁছাতে না পারে, সেই সময় affected content সফলভাবে fetch করতে পারে না। Google document করে যে crawling-এর সময় network এবং DNS error-কে server-side 5xx error-এর মতো handle করা হয়, এবং দীর্ঘ unavailability crawl ও already indexed URL-এ প্রভাব ফেলতে পারে। কিন্তু প্রতিটি ছোট outage automatically SEO loss করবে—এ কথা বলা ঠিক নয়। Diagnostic tool এটাও prove করতে পারে না যে পরে traffic change ওই outage-এর কারণেই হয়েছে।
User-এর ক্ষেত্রে logic সহজ: site access করতে না পারলে ব্যবহারও করতে পারে না। Project অনুযায়ী lost session, lead, conversion বা revenue হতে পারে। কিন্তু technical diagnostic সেই business impact calculate করে না।
“Website down” হলে practical check order
- অন্য network থেকে symptom confirm করুন। Local browser-কে পুরো Internet-এর representative ভাববেন না।
- DNS check করুন। Domain resolve এবং expected records verify করুন।
- HTTPS/TLS check করুন। Certificate validity এবং connection error দেখুন।
- প্রয়োজনীয় port check করুন। Probe location থেকে reachability test করুন।
- Network signals compare করুন। Ping ও traceroute-কে supporting evidence হিসেবে ব্যবহার করুন।
- IP, reverse DNS, hosting ও CMS signals দেখুন। Expected infrastructure-এ পৌঁছাচ্ছেন কি না বুঝতে সাহায্য করে।
- তারপর investigation narrow করুন। Evidence application, server, DNS, network path না local environment—কোন দিকে বেশি যাচ্ছে তা ঠিক করুন।
এটি universal incident response protocol নয়। আমার জন্য এটি সেই ভুল এড়ানোর উপায়, যেটা আমি Gitae বানিয়ে কমাতে চেয়েছি: একমাত্র তথ্য “site খুলছে না” বলে ভুল layer পরিবর্তন করা।
আগে real usefulness, পরে monetization
এখন Gitae monetized নয়। আগে নিজের জন্য বানিয়েছি, কারণ নিজের machine-এর বাইরে থেকে দ্রুত site check করে সরাসরি DNS, certificate, port এবং network diagnostics-এ যেতে চেয়েছিলাম, আলাদা tool-এর মধ্যে ঘুরতে নয়।
Current goal হলো diagnostics আরও useful করা এবং দেখা project SEO ও real demand থেকে organic traffic পায় কি না। Moderate traffic পেলেও automated website monitoring with instant messenger alerts যোগ করতে চাই। একই idea manual diagnosis থেকে detection পর্যন্ত বাড়বে: কিছু unavailable হয়েছে তা আগে জানা, তারপর owner-কে দ্রুত investigation শুরু করার জন্য যথেষ্ট information দেওয়া।
Core idea simple থাকা উচিত
“Up” এবং “down” symptom, explanation নয়।
DNS, HTTPS/TLS, routing, ports, hosting, application এবং user-এর নিজের network—সবই simple-looking availability problem তৈরি করতে পারে। Gitae magically সব root cause খুঁজে দেয় না, এবং দুই external server পুরো Internet কী দেখছে তা বলে না। তবে এটি এক জায়গায় কয়েকটি independent signal একত্র করতে পারে।
আমি এমন tool-ই চেয়েছিলাম: “site খুলছে না” থেকে আরও useful প্রশ্নে যাওয়া—“পরের কোন layer investigate করা উচিত?”