এই পর্বে যা শিখবেন
- পেশাদার IT সাপোর্টে ব্যবহৃত ছয় ধাপের troubleshooting পদ্ধতি, সহজ বাংলায় আর একটি বাস্তব উদাহরণে
- ভালো প্রশ্ন করা, error বার্তা পড়া আর সেটি দিয়ে ঠিকভাবে খোঁজা
- স্তরে স্তরে ভাবা, half-splitting আর known-good যন্ত্রাংশ দিয়ে দোষ আলাদা করা
- Windows আর নেটওয়ার্কের রোগ নির্ণয়ের টুল — কোনটি কখন, কী বলে
- ছয়টি বাস্তব কেস: ইন্টারনেট, স্লো PC, ডিসপ্লে, অ্যাপ crash, প্রিন্টার আর ফোন — সাথে কখন বিশেষজ্ঞের কাছে যাবেন আর কীভাবে লিখে রাখবেন
১ · ভালো সমস্যা-সমাধানকারী অনুমান করেন না
পর্ব ০৮-এ প্রতিদিনের সাধারণ সমস্যার একটি তালিকা দেখেছেন — শব্দ নেই তো ভলিউম দেখুন, ইন্টারনেট নেই তো রাউটার restart করুন। তালিকা কাজে লাগে, যতক্ষণ সমস্যাটা তালিকায় আছে। কিন্তু যেদিন এমন সমস্যা আসবে যা কোনো তালিকায় নেই? সেদিন কাজে লাগবে একটি পদ্ধতি। এই পর্ব সেই পদ্ধতির — troubleshooting.
একজন ভালো ডাক্তারের কথা ভাবুন। রোগী এসে বললেন “পেটে ব্যথা”। ডাক্তার সাথে সাথে অপারেশন করেন না, আবার আন্দাজে পাঁচ রকম ওষুধও দেন না। তিনি প্রশ্ন করেন: কবে থেকে? কোথায় ঠিক? খাওয়ার পরে বাড়ে? জ্বর আছে? তারপর ভাবেন — গ্যাস্ট্রিক, অ্যাপেন্ডিসাইটিস না পাথর। তারপর পরীক্ষা দেন, যাতে সম্ভাবনা কমে আসে। ভালো মোটরসাইকেল মিস্ত্রিও আগে দেখেন তেল আছে কি না, তারপর প্লাগে স্পার্ক — একটা একটা করে।
উপমা: হারানো চাবি খোঁজার দুই উপায়। প্রথম জন পুরো বাসা এলোমেলো করে খোঁজেন। দ্বিতীয় জন ভাবেন: “শেষ কখন চাবিটা হাতে ছিল? বাজার থেকে ফিরে দরজা খুলেছি — তাহলে দরজা থেকে রান্নাঘর, এর মধ্যেই আছে।” খোঁজার জায়গা ছোট করে আনা — troubleshooting-এর মূল কৌশল এটাই।
পুরো পদ্ধতির ভেতরে আছে বিজ্ঞানের সেই পুরোনো ধারা: পর্যবেক্ষণ → সম্ভাব্য ব্যাখ্যা, যাকে বলে হাইপোথিসিস → পরীক্ষা → সিদ্ধান্ত। তিনটি অভ্যাস এই পদ্ধতিকে কাজ করায়:
- একবারে একটি জিনিস বদলান। একসাথে driver আপডেট, RAM বদল আর রাউটার restart করলে সমস্যা মিটলেও জানবেন না কোনটা কাজ করল — পরের বার আবার শূন্য থেকে।
- সস্তা আর নিরাপদ পরীক্ষা আগে। তার লাগানো আছে কি না দেখতে দশ সেকেন্ড লাগে; Windows নতুন করে বসাতে লাগে সারা দিন, আর ডেটা হারানোর ঝুঁকি।
- লক্ষণ নয়, কারণ। প্রতিদিন restart করলে স্লো কম্পিউটার কিছুক্ষণ ভালো চলে — কিন্তু সেটা ব্যথানাশক, চিকিৎসা নয়। লক্ষ্য হলো root cause, যা সারালে সমস্যা আর ফেরে না।
Troubleshooting আসলে একটি খোঁজার সমস্যা: অসংখ্য সম্ভাব্য কারণের মধ্যে একটিকে খুঁজে বের করা। প্রতিটি প্রশ্ন আর প্রতিটি পরীক্ষার কাজ হলো সন্দেহের তালিকা ছোট করা। যে পরীক্ষা তালিকা ছোট করে না, সেটা সময় নষ্ট।
২ · ছয় ধাপের পদ্ধতি — চিহ্নিত করা থেকে লিখে রাখা
IT সাপোর্টের সবচেয়ে পরিচিত আন্তর্জাতিক সার্টিফিকেশনগুলোর একটি CompTIA A+. সেখানে troubleshooting শেখানো হয় ছয়টি ধাপে। ক্রমটা মনে রাখুন — ইন্টারভিউতেও প্রায়ই আসে।
| ধাপ | CompTIA-র নাম (সংক্ষেপে) | সহজ বাংলায় |
|---|---|---|
| ১ | Identify the problem | সমস্যা ঠিকভাবে চিহ্নিত করুন: প্রশ্ন করুন, লক্ষণ দেখুন, কী বদলেছে জানুন। কিছু বদলানোর আগে ব্যাকআপ। |
| ২ | Establish a theory of probable cause | সম্ভাব্য কারণ ভাবুন — সবচেয়ে সাধারণ আর স্পষ্টটি আগে (“প্লাগ লাগানো আছে তো?”)। |
| ৩ | Test the theory | পরীক্ষা করে দেখুন অনুমান ঠিক কি না। ভুল হলে নতুন অনুমান, বা দরকারে অভিজ্ঞ কারও কাছে। |
| ৪ | Plan of action and implement | সমাধানের পরিকল্পনা করুন (নির্মাতার নির্দেশনা দেখে, ঝুঁকি ভেবে), তারপর প্রয়োগ। |
| ৫ | Verify full functionality | পুরো ব্যবস্থা ঠিক চলছে কি না যাচাই; আবার যেন না হয় তার ব্যবস্থা। |
| ৬ | Document | কী পেলেন, কী করলেন, ফল কী — লিখে রাখুন। |
একটি বাস্তব উদাহরণে ছয়টি ধাপ চালিয়ে দেখি। নুসরাতের অফিসের ল্যাপটপে গত সপ্তাহ থেকে মাঝে মাঝে নীল পর্দা (BSOD) আসে, তারপর নিজে নিজে restart হয়। প্রতিটি ধাপে কী জানা গেল, খেয়াল করুন:
- চিহ্নিত করা
প্রশ্ন + ব্যাকআপকী, কবে, কী বদলেছে - সম্ভাব্য কারণ
hypothesisসাধারণটি আগে - পরীক্ষা
একটি জিনিস বদলপ্রমাণ খোঁজা - পরিকল্পনা ও প্রয়োগ
restore point আগেনিরাপদ সমাধান - যাচাই
কয়েক দিন ব্যবহারপ্রতিরোধ - লিখে রাখা
লগ / টিকেটপরের বারের জন্য
| কী করা হলো | |
| যা জানা গেল |
- চিহ্নিত করা। “মাঝে মাঝে নীল পর্দা” অস্পষ্ট। প্রশ্ন করে জানা গেল কবে শুরু, পর্দায় কী লেখা, আর সবচেয়ে গুরুত্বপূর্ণ — সেদিন কী নতুন এসেছিল। ফাইলগুলো আগে OneDrive-এ ব্যাকআপ করা হলো।
- সম্ভাব্য কারণ। stop code-এ “DRIVER” শব্দ আর সময়ের মিল — প্রথম সন্দেহ নতুন driver. RAM বা গরমও হতে পারে, তাই সেগুলো তালিকার নিচে থাকল, বাদ গেল না।
- পরীক্ষা। Reliability Monitor-এ (অংশ ৫) দেখা গেল প্রথম crash অ্যাডাপ্টার লাগানোর দিনই। তারপর শুধু একটি জিনিস বদলানো হলো — অ্যাডাপ্টার খুলে রাখা। নীল পর্দা থামল: অনুমান টিকল। না থামলে তালিকার দ্বিতীয় অনুমানে যাওয়া হতো।
- পরিকল্পনা ও প্রয়োগ। অ্যাডাপ্টার ফেলে না দিয়ে নির্মাতার অফিসিয়াল সাইট থেকে নতুন driver নামানো হলো। কিছু বদলানোর আগে System Restore-এর একটি restore point — ভুল হলে ফেরার পথ।
- যাচাই। শুধু “এখন ঠিক” নয় — যে কাজে সমস্যা হতো, সেভাবেই কয়েক দিন ব্যবহার। মাঝে মাঝে হওয়া সমস্যায় এক ঘণ্টার পরীক্ষায় কিছু প্রমাণ হয় না।
- লিখে রাখা। অফিসে একই অ্যাডাপ্টার আরও তিনটি কম্পিউটারে আছে। লগে এক লাইন থাকলে পরের জন দশ মিনিটে সমাধান করবেন, আট দিন নয়।
ধাপ ৩-এ অনুমান ভুল হওয়া ব্যর্থতা নয়, তথ্য — “এটা নয়” জানাও তালিকা ছোট করে। আর নিজের দক্ষতা বা অনুমতির বাইরে গেলে escalation — সব তথ্য গুছিয়ে অভিজ্ঞ কারও কাছে পাঠানো — পদ্ধতিরই অংশ (অংশ ৯)।
৩ · প্রশ্ন করা, error বার্তা পড়া আর ঠিকভাবে খোঁজা
প্রথম ধাপে কত ভালো তথ্য পেলেন, তার ওপরই বাকি সব নির্ভর করে। “কম্পিউটার কাজ করে না” — এই বাক্য থেকে কিছুই শুরু করা যায় না। পাঁচটি প্রশ্ন প্রায় সব ক্ষেত্রে কাজ করে:
🕒 কবে থেকে?
হঠাৎ, না ধীরে ধীরে? হঠাৎ মানে সাধারণত কোনো পরিবর্তন; ধীরে মানে ক্ষয় — ভরা ডিস্ক, পুরোনো ব্যাটারি, ধুলা।
সময়🔄 কী বদলেছে?
আপডেট, নতুন অ্যাপ, নতুন যন্ত্র, সেটিং, এমনকি জায়গা বদল বা ঝড়ের রাতের লোডশেডিং। সবচেয়ে কার্যকর প্রশ্ন এটিই।
পরিবর্তন💬 ঠিক কী লেখা আসে?
error বার্তা হুবহু — ছবি তুলে রাখুন। “কী যেন একটা এরর” দিয়ে কেউ সাহায্য করতে পারে না।
প্রমাণ🔁 আবার ঘটানো যায়?
নির্দিষ্ট কাজ করলেই হয়, নাকি এলোমেলো? যে সমস্যা ইচ্ছামতো ঘটানো যায়, তাকে বলে reproducible — অর্ধেক সমাধান সেখানেই।
পুনরাবৃত্তিপঞ্চম প্রশ্ন: সমস্যার পরিধি কত? শুধু একটি অ্যাপে, না সব অ্যাপে? শুধু একজনের কম্পিউটারে, না পুরো অফিসে? শুধু একটি ওয়েবসাইট, না সব? পরিধি যত বড়, কারণ তত “ওপরের দিকে” — সবার সাথে ভাগ করা কোনো জিনিসে (রাউটার, সার্ভার, ISP বা ইন্টারনেট সেবাদাতা)। পরিধি যত ছোট, কারণ তত কাছের — সেই যন্ত্র বা অ্যাপে।
Error বার্তা পড়তে শিখুন
অনেকে error বার্তা দেখলেই না পড়ে “OK” চাপেন। অথচ এটি প্রায়ই সমস্যার সবচেয়ে বড় সূত্র। একটি সাধারণ বার্তা ভেঙে দেখুন:
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
এখানে মানুষের ভাষার অংশ (“চালু হতে পারেনি”) খুব সাধারণ — হাজার কারণে হতে পারে। কিন্তু বন্ধনীর ভেতরের 0xc000007b হলো একটি নির্দিষ্ট error code — hex সংখ্যা (পর্ব ১৬)। এই কোডটি সাধারণত বোঝায় ৩২-bit আর ৬৪-bit ফাইলের গরমিল বা কোনো দরকারি লাইব্রেরি নষ্ট হওয়া। কোডটাই আসল তথ্য।
ঠিকভাবে খোঁজা — সার্চের কৌশল
- হুবহু লেখা উদ্ধৃতি চিহ্নে:
"0xc000007b"বা"DRIVER_IRQL_NOT_LESS_OR_EQUAL"লিখলে সার্চ ইঞ্জিন ঠিক সেই লেখা খোঁজে (পর্ব ১৩)। - ব্যক্তিগত অংশ বাদ দিন: বার্তায় আপনার নাম, ফোল্ডারের পথ (
C:\Users\Rahim\...) থাকলে সেটুকু বাদ দিয়ে খুঁজুন। - প্রসঙ্গ যোগ করুন: অ্যাপের নাম, সংস্করণ, Windows 10 না 11 — যেমন
"0xc000007b" Windows 11 অ্যাপের নাম. - উৎস যাচাই করুন: নির্মাতার সাপোর্ট পেজ, Microsoft Learn আর অভিজ্ঞদের ফোরাম আগে। “ক্লিক করে এই ফিক্সার টুল নামান” ধরনের সাইট এড়িয়ে চলুন — অনেক “ড্রাইভার আপডেটার” বা “PC ক্লিনার” নিজেই ঝামেলা বা malware.
error-এর ছবি বা লগ কাউকে পাঠানোর আগে দেখে নিন তাতে পাসওয়ার্ড, ব্যাংক বা bKash-এর তথ্য, OTP, লাইসেন্স কী বা অন্যের ব্যক্তিগত তথ্য আছে কি না। থাকলে ঢেকে দিন।
৪ · কোথায় দোষ — স্তরে স্তরে ভাবা, অর্ধেক করে খোঁজা
পর্ব ২৩-এ দেখেছেন, কম্পিউটার কয়েকটি স্তরে সাজানো — প্রতিটি স্তর নিচের স্তরের ওপর দাঁড়িয়ে। troubleshooting-এ এর মানে: নিচের স্তর ঠিক না থাকলে ওপরের স্তরে খোঁজা বৃথা। বিদ্যুৎ না থাকলে অ্যাপের সেটিং ঘেঁটে লাভ নেই।
| স্তর | সাধারণ লক্ষণ | দ্রুত পরীক্ষা |
|---|---|---|
| বিদ্যুৎ | কোনো সাড়া নেই, হঠাৎ বন্ধ | সকেট, UPS, চার্জারের বাতি; অন্য সকেটে |
| হার্ডওয়্যার | বিপ, পর্দা কালো, ক্লিক শব্দ, অতিরিক্ত গরম | POST-এর বিপ/LED (পর্ব ২৭), তার, RAM, SMART |
| অপারেটিং সিস্টেম | BSOD, সব কিছু স্লো, চালু হয় না | safe mode, Event Viewer, আপডেট ইতিহাস |
| অ্যাপ | একটি প্রোগ্রাম crash বা ভুল আচরণ | অন্য অ্যাপ ঠিক চলে? আপডেট, repair |
| নেটওয়ার্ক | সাইট খোলে না, ধীর, মাঝে মাঝে কেটে যায় | ipconfig, ping, অন্য যন্ত্রে চলে? |
| ব্যবহারকারী | “কাল পর্যন্ত এখানে বোতাম ছিল” | ঠিক কী করছেন — পাশে বসে দেখুন |
শেষ সারিটা হাসির নয়: ভুল অ্যাকাউন্ট, Caps Lock চালু, অন্য ফোল্ডারে সেভ — অনেক টিকেট এভাবেই মেটে।
Half-splitting — প্রতিবার অর্ধেক
সন্দেহভাজন অনেক হলে একটি একটি করে পরীক্ষা ধীর। তার বদলে একসাথে অর্ধেককে পরীক্ষা করুন — এর নাম half-splitting বা divide and conquer. লম্বা একটি বাতির সিরিজের একটি বাল্ব নষ্ট হলে অভিজ্ঞ ইলেকট্রিশিয়ান মাঝখানে মাপেন; বিদ্যুৎ সেখানে পৌঁছালে দোষ পরের অর্ধেকে। উদাহরণ: ইমরানের ব্রাউজার কিছুক্ষণ পরপর crash করে, আর তাতে ৮টি extension লাগানো।
| পরীক্ষা | |
| ফল | |
| সিদ্ধান্ত |
- শুরু। ৮টি extension, crash হয়। একটি একটি করে বন্ধ করলে খারাপ ভাগ্যে ৭টি পরীক্ষা লাগবে, আর প্রতিটির জন্য অপেক্ষা করতে হবে crash হয় কি না।
- পরীক্ষা ১ — অর্ধেক বন্ধ। A থেকে D বন্ধ। তবু crash হচ্ছে — তাহলে দোষী চালু থাকা অর্ধেকে: E, F, G, H. এক পরীক্ষায় চারটি নির্দোষ প্রমাণিত।
- পরীক্ষা ২ — বাকিদের অর্ধেক। E আর F বন্ধ, G আর H চালু। crash থামল — তাহলে দোষী বন্ধ করা জোড়ায়: E বা F.
- পরীক্ষা ৩। শুধু E চালু। crash নেই — তাহলে দোষী F, ভিডিও ডাউনলোডার। অচেনা উৎসের এমন extension প্রায়ই সমস্যার — আর কখনো নিরাপত্তারও ঝুঁকি।
- হিসাব। ৮ → ৪ → ২ → ১: তিনটি পরীক্ষা, কারণ ২×২×২ = ৮। ১,০০০টি সন্দেহভাজনেও লাগত মাত্র ১০টি (২১০ = ১,০২৪)। শর্ত একটাই: একবারে একটিই দোষী আর প্রতিবার পরীক্ষার ফল নির্ভরযোগ্য।
একই কৌশল সবখানে: কোন startup অ্যাপ কম্পিউটার ধীর করছে, নেটওয়ার্ক পথের কোথায় সংযোগ কাটছে (অংশ ৬), এমনকি প্রোগ্রামারদের Git-এর bisect কমান্ডেও।
Known-good যন্ত্রাংশ দিয়ে বদল
হার্ডওয়্যারে সবচেয়ে বিশ্বাসযোগ্য পরীক্ষা হলো সন্দেহের অংশটিকে একটি known-good অংশ দিয়ে বদলানো — যেটা অন্য জায়গায় ঠিক চলছে বলে নিশ্চিত জানেন। মনিটরে ছবি আসে না? ঘরের TV-তে একই HDMI তার দিয়ে কম্পিউটার লাগান। ছবি এলে দোষ মনিটরে; না এলে তার বদলে আবার দেখুন। শর্ত: “ভালো” অংশটি সত্যিই ভালো হতে হবে — “পুরোনো ড্রয়ারের তার, মনে হয় চলত” known-good নয়।
৫ · যন্ত্রপাতির বাক্স — রোগ নির্ণয়ের টুল
ডাক্তারের যেমন স্টেথোস্কোপ, থার্মোমিটার আর রক্ত পরীক্ষা — Windows-এর ভেতরেই তেমনি অনেক টুল আছে, নতুন কিছু ইনস্টল না করেই। সবচেয়ে সহজে খোলার উপায়: Win+R চেপে নিচের কমান্ড লিখে Enter. এগুলো শুধু দেখায়, নিজে কিছু বদলায় না।
| টুল | খোলার উপায় | কী বলে |
|---|---|---|
| Task Manager | Ctrl+Shift+Esc | এই মুহূর্তে কোন প্রোগ্রাম কতটা CPU, মেমরি, ডিস্ক খাচ্ছে; startup অ্যাপ |
| Resource Monitor | resmon | আরও গভীরে: কোন প্রোগ্রাম কোন ফাইল পড়ছে, ডিস্ক কতটা ব্যস্ত, মেমরির টানাটানি |
| Event Viewer | eventvwr | অতীতের ঘটনা: Windows Logs → System আর Application-এ error ও warning, সময়সহ |
| Reliability Monitor | perfmon /rel | দিনভিত্তিক গ্রাফ — কবে কী crash করল, কবে কোন আপডেট বসল |
| Device Manager | devmgmt.msc | সব হার্ডওয়্যার আর driver; হলুদ ⚠ মানে সমস্যা; driver Roll Back |
| Memory Diagnostic | mdsched | restart করে RAM পরীক্ষা; ফল পরে Event Viewer-এ |
| ডিস্কের স্বাস্থ্য — SMART | CrystalDiskInfo (ফ্রি, ওপেন সোর্স) | Good / Caution / Bad; নষ্ট sector, তাপমাত্রা, SSD কতটা ক্ষয়েছে |
Event Viewer প্রথমবার দেখলে ভয় লাগতে পারে — হাজারো লাল-হলুদ চিহ্ন। সুস্থ কম্পিউটারেও প্রচুর warning থাকে। কৌশল হলো সময় মেলানো: সমস্যা যে মুহূর্তে হয়েছিল, ঠিক সেই সময়ের ঘটনা দেখা। কয়েকটি পরিচিত Event ID: System লগে 41 (Kernel-Power) মানে কম্পিউটার ঠিকমতো বন্ধ না হয়েই আবার চালু হয়েছে (যেমন লোডশেডিং); উৎস “disk” আর ID 7 মানে ডিস্কে bad block — খারাপ লক্ষণ; Application লগে 1000 (Application Error) মানে কোনো অ্যাপ crash করেছে, সাথে থাকে কোন ফাইলের কারণে।
Reliability Monitor আরও সহজ: ১–১০ স্কেলের একটি রেখা, নিচে প্রতিদিনের লাল ✖ (crash) আর নীল ⓘ (আপডেট) — “কী বদলেছে?”-র উত্তর চোখের সামনে।
আরও দুটি পুরোনো বন্ধু
- Safe mode (পর্ব ২৭) — শুধু জরুরি driver আর service নিয়ে Windows চালু। safe mode-এ সমস্যা না থাকলে দোষী সম্ভবত কোনো তৃতীয় পক্ষের driver, অ্যাপ বা startup প্রোগ্রাম — এক পরীক্ষায় অনেক সন্দেহভাজন বাদ।
- System File Checker — Administrator হিসেবে খোলা টার্মিনালে
sfc /scannowWindows-এর নষ্ট সিস্টেম ফাইল খুঁজে মূল কপি দিয়ে ঠিক করে; আপনার ফাইলে হাত দেয় না।
নেটওয়ার্কের চার কমান্ড
পর্ব ২৯-এ টার্মিনাল আর পর্ব ৩৩-এ IP, DNS দেখেছেন। নেটওয়ার্ক সমস্যায় এই চারটি কমান্ডই বেশিরভাগ কাজ করে দেয় — সবগুলোই শুধু তথ্য দেখায়:
ipconfig /all # নিজের IP, gateway, DNS সার্ভার, DHCP চালু কি না
ping 192.168.0.1 # রাউটার (gateway) পর্যন্ত পৌঁছায়?
ping 8.8.8.8 # ইন্টারনেটের একটি নির্দিষ্ট IP পর্যন্ত পৌঁছায়?
tracert 8.8.8.8 # পথের প্রতিটি রাউটার — কোথায় আটকায়
nslookup google.com # DNS নাম থেকে IP বের করতে পারছে?
# Linux/macOS: ip addr (বা ifconfig), ping -c 4 ..., traceroute ..., nslookup ...- ipconfig — “আমি কে, আমার রাউটার কে, আমার DNS কে।” Default gateway সাধারণত বাসার রাউটারের ঠিকানা।
- ping — একটি ছোট বার্তা পাঠিয়ে উত্তরের অপেক্ষা; “Reply from …” আর সময় (ms) মানে পথ খোলা। “Request timed out” মানে উত্তর আসেনি (যদিও কিছু সার্ভার ইচ্ছা করে ping-এর উত্তর দেয় না)।
- tracert — পথের প্রতিটি রাউটারের তালিকা; কোন ধাপের পর থেকে
*আসে, সমস্যা সম্ভবত তার কাছাকাছি। - nslookup — DNS কাজ করছে কি না সরাসরি পরীক্ষা।
রাউটার আর ONU-এর বাতি পড়ুন
বাংলাদেশের অনেক বাসায় ব্রডব্যান্ড আসে ফাইবারে, একটি ONU হয়ে Wi-Fi রাউটারে। বাতিগুলো বিনা খরচের রোগ নির্ণয়: PON স্থির জ্বলা মানে ISP-র সাথে সংযোগ নিবন্ধিত; LOS লাল জ্বলা বা জ্বলা-নেভা মানে ফাইবারে আলোর সংকেতই আসছে না — তার কাটা, বেশি বাঁকানো বা ISP-র দিকে সমস্যা; তখন সরাসরি ISP-কে ফোন। রাউটারে Internet/WAN বাতি নিভে থাকলে রাউটার বাইরে পৌঁছাতে পারছে না। কোন বাতির কী রং কী মানে, তা মডেলভেদে আলাদা — যন্ত্রের গায়ের লেবেল বা ম্যানুয়াল দেখুন।
Speed test: Wi-Fi-তে আর তারে আলাদা মাপুন। ISP-র “২০ Mbps” মানে megabit — ডাউনলোডে দেখাবে প্রায় ২.৫ MB/s (৮ দিয়ে ভাগ)। তারে ঠিক আর Wi-Fi-তে ধীর হলে দোষ ঘরের Wi-Fi-র, ISP-র নয়।
৬ · কেস ১: “ইন্টারনেট চলে না”
“ইন্টারনেট চলে না” আসলে অনেক রকম সমস্যার একটি নাম। কৌশল হলো কাছ থেকে দূরে যাওয়া: নিজের যন্ত্র → Wi-Fi সংযোগ → IP ঠিকানা → রাউটার → ইন্টারনেট → DNS. প্রতিটি ধাপ পাশ করলে সন্দেহ এক ধাপ দূরে সরে। রাহিমের ল্যাপটপের সাথে কথোপকথনটি ধাপে ধাপে দেখুন:
- অন্য যন্ত্রে?
ফোন, অন্য PCপরিধি - সংযুক্ত?
Wi-Fi / তারলিংক - IP ঠিক?
ipconfigDHCP - রাউটার?
ping gatewayঘরের নেটওয়ার্ক - ইন্টারনেট?
ping 8.8.8.8ISP পর্যন্ত - DNS?
nslookupনাম → IP - সমাধান ও যাচাই
DNS automaticলিখে রাখা
| প্রশ্ন / পরীক্ষা | |
| রাহিমের উত্তর / ফল | |
| সিদ্ধান্ত |
- পরিধি আগে। ফোন চলছে মানে রাউটার, ONU আর ISP সব ঠিক — এক প্রশ্নে অর্ধেক পথ নির্দোষ। ফোনও না চললে পরের সব ধাপ বাদ দিয়ে সরাসরি রাউটার আর ONU-এর বাতি দেখতাম।
- লিংক। ল্যাপটপ Wi-Fi-তে যুক্ত, কিন্তু Windows বলছে “No internet” — অর্থাৎ রেডিও সংযোগ আছে, তার পরে কোথাও আটকাচ্ছে।
- IP ঠিকানা। ঠিকানা যদি
169.254দিয়ে শুরু হতো, তার মানে রাউটারের DHCP থেকে ঠিকানা পায়নি — Windows নিজে একটি APIPA ঠিকানা বসিয়েছে, যা দিয়ে ইন্টারনেট চলে না। এখানে ঠিকানা স্বাভাবিক, তাই DHCP নির্দোষ। - রাউটার পর্যন্ত। gateway-কে ping করে ২ ms-এ উত্তর — ল্যাপটপ থেকে রাউটারের পথ পুরো ঠিক।
- ইন্টারনেট পর্যন্ত।
8.8.8.8হলো Google-এর একটি পাবলিক DNS সার্ভারের ঠিকানা — নাম নয়, সংখ্যা। এখানে উত্তর আসা মানে ISP পার হয়ে ইন্টারনেটে প্যাকেট যাচ্ছে-আসছে। তবু ব্রাউজারে সাইট খোলে না — তাহলে নাম থেকে IP বের করার ধাপেই গোলমাল। - DNS.
nslookupউত্তর পেল না, আর ipconfig-এ দেখা গেল DNS সার্ভার হিসেবে একটি অচেনা ঠিকানা হাতে বসানো — আগের অফিসের সেটিং। ঠিকানা জানা আছে, কিন্তু বই খুলে ফোন নম্বর খুঁজে পাচ্ছে না। - সমাধান ও যাচাই। Settings → Network & internet → Wi-Fi → Hardware properties → DNS server assignment-এ “Automatic (DHCP)” করা হলো। সব সাইট খুলছে। চাইলে
ipconfig /flushdnsদিয়ে পুরোনো DNS cache মোছা যায় — নিরাপদ কমান্ড। লগে এক লাইন।
অন্য ধাপে থামলে: সব যন্ত্রে ইন্টারনেট নেই → রাউটার আর ONU ৩০ সেকেন্ড বন্ধ রেখে চালু, LOS বাতি, তারপর ISP. 169.254 ঠিকানা → Wi-Fi বন্ধ-চালু, রাউটার restart. gateway-তে ping যায় না → দুর্বল Wi-Fi, ভুল নেটওয়ার্ক বা তার। gateway-তে যায় কিন্তু 8.8.8.8-এ নয় → ONU বা ISP. Settings-এর “Network reset” সব নেটওয়ার্ক সেটিং মুছে দেয় — একেবারে শেষ উপায়।
নিজে চালিয়ে দেখুন — “ইন্টারনেট নেই” সিদ্ধান্ত-বৃক্ষ
নিচের কোডটি ওপরের ধাপগুলোকেই একটি সিদ্ধান্ত-বৃক্ষ (decision tree) হিসেবে চালায়। প্রতিটি ব্যবহারকারীর উত্তর দেওয়া আছে; যে উত্তর দেওয়া নেই, তাকে “ঠিক আছে” ধরা হয়। প্রথম যে পরীক্ষা ব্যর্থ হয়, সেখানেই থেমে সম্ভাব্য সমাধান বলে।
const checks = [
['others', 'Other devices online?', 'Whole network down: restart router, check ONU LOS light, call ISP'],
['link', 'Wi-Fi/cable connected?', 'Turn off airplane mode, reconnect Wi-Fi or cable'],
['ip', 'Valid IP (not 169.254.x.x)?', 'No DHCP reply: restart router, then ipconfig /renew'],
['gateway', 'ping gateway OK?', 'Local problem: weak Wi-Fi, wrong network or cable'],
['wan', 'ping 8.8.8.8 OK?', 'Router cannot reach internet: ONU or ISP side'],
['dns', 'nslookup google.com OK?', 'DNS problem: set DNS to automatic, flush DNS cache'],
];
function diagnose(who, answers) {
console.log(`--- ${who} ---`);
for (const [key, question, fix] of checks) {
const ok = answers[key] !== false; // not given = passed
console.log(`${ok ? '[YES]' : '[NO ]'} ${question}`);
if (!ok) return console.log(`=> Likely fix: ${fix}`);
}
console.log('=> Network OK: check the browser, VPN/proxy or the website');
}
diagnose('Rahim laptop', { dns: false });
diagnose('Office PC', { ip: false });
diagnose('Whole house', { others: false });আউটপুটে তিনটি অংশ। রাহিমের: পাঁচটি [YES], তারপর [NO ] nslookup google.com OK? আর => Likely fix: DNS problem: set DNS to automatic, flush DNS cache — ঠিক ওপরের stepper-এর মতো। দ্বিতীয়টি অফিসের কম্পিউটারের: দুটি [YES], তারপর [NO ] Valid IP (not 169.254.x.x)? আর DHCP-র সমাধান। তৃতীয়টি পুরো বাসার: প্রথম প্রশ্নেই [NO ] Other devices online?, তাই সরাসরি => Likely fix: Whole network down: restart router, check ONU LOS light, call ISP — বাকি পাঁচটি পরীক্ষা চালানোই হয় না। checks-এর ক্রমটাই পদ্ধতি: কাছ থেকে দূরে।
৭ · কেস ২ ও ৩: “PC খুব স্লো” আর “পর্দায় কিছু আসে না”
পর্ব ০৮-এ স্লো কম্পিউটারের প্রথম ধাপগুলো দেখেছেন — স্টোরেজ, startup apps, Task Manager, malware স্ক্যান। সেগুলো করেও সমস্যা থাকলে এবার গোয়েন্দার মতো প্রমাণ পড়ার পালা। প্রশ্ন একটাই: চারটি সম্পদের — CPU, মেমরি, ডিস্ক, নেটওয়ার্ক — কোনটি ভরে গেছে, আর কে ভরিয়েছে? যে সম্পদ ১০০% এর কাছে আটকে থাকে, সেটাই বোতলের সরু মুখ (bottleneck) — বাকি সব তার জন্য অপেক্ষা করে। সেলিনার অফিস ডেস্কটপ, ৮ GB RAM আর পুরোনো HDD; Resource Monitor খুলে ট্যাব ধরে ধরে পড়ুন:
- Overview
চারটি গ্রাফকে লাল? - CPU
% CPUপ্রসেস ধরে - Memory
Hard Faults/secRAM কম? - Disk
Active Time, Queueকে পড়ছে-লিখছে - Network
B/secকে নামাচ্ছে - রায়
SMART + লগমূল কারণ
| CPU | |
| মেমরি | |
| ডিস্ক | |
| নেটওয়ার্ক |
- Overview — কোন গ্রাফ লাল? CPU আর নেটওয়ার্ক প্রায় অলস, কিন্তু ডিস্কের “Highest Active Time” ১০০%-এ আটকে। প্রথম প্রমাণ: ডিস্ক এক মুহূর্তও বিশ্রাম পাচ্ছে না।
- CPU ট্যাব। প্রসেসগুলো CPU অনুযায়ী সাজালে কেউই উল্লেখযোগ্য নয়। CPU এখানে নির্দোষ — তাই নতুন প্রসেসর কেনার প্রশ্নই ওঠে না।
- Memory ট্যাব। RAM-এর তিন-পঞ্চমাংশ ব্যবহৃত, আর Hard Faults/sec খুব কম। হার্ড ফল্ট বেশি (শত শত, দীর্ঘক্ষণ) হলে বুঝতাম RAM কম পড়ায় Windows ডিস্কের page file-এ বারবার যাচ্ছে — তখন ডিস্কের ব্যস্ততার আসল কারণ হতো RAM. এখানে তা নয়।
- Disk ট্যাব — দোষী পাওয়া গেল। Disk Activity-তে Total (B/sec) অনুযায়ী সাজালে সবার ওপরে একটি ক্লাউড-সিঙ্ক অ্যাপ, হাজার হাজার ছোট ফাইল লিখছে। Storage অংশে Queue Length ৬ — কাজ লাইনে জমছে; আর কিছু ফাইলের Response Time ৮০০ ms-এর বেশি, যা যেকোনো HDD-র জন্যও অস্বাভাবিক।
- Network ট্যাব। সিঙ্ক অ্যাপ আপলোডও করছে, কিন্তু সামান্য। নেটওয়ার্ক বোতলের মুখ নয় — এটা নিশ্চিত হওয়াও দরকার, যাতে ভুল করে ISP-কে দোষ না দেওয়া হয়।
- রায় আর মূল কারণ। সিঙ্ক থামালে কম্পিউটার কিছুটা দ্রুত হয়, কিন্তু Response Time তবু বেশি। CrystalDiskInfo-তে HDD “Caution” — reallocated sector বাড়ছে; Event Viewer-এ disk-এর ID 7. মূল কারণ: মরতে থাকা HDD. করণীয়: আজই ব্যাকআপ, তারপর SSD-তে বদল (পর্ব ০৪)। সিঙ্ক রাতে চলার মতো সাজানো।
অন্য ফলাফল হলে রায় কী হতো, তার ছোট মানচিত্র:
- CPU ১০০%, একটি অচেনা প্রসেস: ডান-ক্লিক → Open file location; ফাইল অদ্ভুত জায়গায় (যেমন Temp) হলে malware সন্দেহ — Defender-এর পূর্ণ স্ক্যান (পর্ব ৪৩)।
- CPU কিছুক্ষণ পর পর ধীর, পাখা জোরে: thermal throttling — অতিরিক্ত গরমে CPU নিজের গতি কমায়। ধুলা পরিষ্কার, বাতাস চলাচল।
- মেমরি ৯০%+, Hard Faults শত শত: RAM কম — খোলা ট্যাব আর অ্যাপ কমান, বা RAM বাড়ান।
- ডিস্ক ১০০% কিন্তু HDD সুস্থ: Windows Update, অ্যান্টিভাইরাস স্ক্যান বা সার্চ ইনডেক্সিং — অপেক্ষা করুন; বারবার হলে SSD-ই স্থায়ী সমাধান।
কেস ৩: “পর্দায় কিছু আসে না”
এখানে নিয়ম: বাইরে থেকে ভেতরে, সস্তা থেকে দামি। বেশিরভাগ ক্ষেত্রে সমাধান প্রথম তিন সারিতেই।
| ক্রম | পরীক্ষা | ফল যা বলে |
|---|---|---|
| ১ | মনিটরের পাওয়ার বাতি জ্বলে? মনিটরের মেনু খোলে? | মেনু খুললে মনিটর জীবিত; সমস্যা সংকেতে |
| ২ | মনিটরের Input/Source ঠিক (HDMI 1, HDMI 2, DP)? | ভুল ইনপুটে “No signal” — খুব সাধারণ |
| ৩ | তার দুই মাথায় শক্ত করে; known-good তার দিয়ে বদল | নতুন তারে চললে পুরোনো তার নষ্ট |
| ৪ | আলাদা গ্রাফিক্স কার্ড থাকলে তার কার্ডে লাগানো, মাদারবোর্ডের পোর্টে নয় | ভুল পোর্টে প্রায়ই ছবি আসে না |
| ৫ | মনিটরে ল্যাপটপ লাগান, বা কম্পিউটারে TV লাগান | দোষ মনিটরে না কম্পিউটারে — আলাদা হলো |
| ৬ | বিপ বা মাদারবোর্ডের LED (পর্ব ২৭) | POST কোথায় আটকেছে — RAM, VGA না CPU |
| ৭ | বিদ্যুৎ পুরো খুলে, স্থির বিদ্যুৎ সরিয়ে RAM খুলে আবার বসানো | “পাখা ঘোরে, পর্দা কালো”-র সবচেয়ে প্রচলিত সমাধান |
| ৮ | এর পরেও না হলে | গ্রাফিক্স কার্ড, মাদারবোর্ড বা PSU — দোকানে known-good যন্ত্রাংশ দিয়ে পরীক্ষা |
৮ · কেস ৪–৬: অ্যাপ crash, প্রিন্টার আর ফোন
কেস ৪: একটি অ্যাপ বারবার বন্ধ হয়ে যায়
প্রথম প্রশ্ন পরিধির: শুধু এই অ্যাপ, নাকি অনেক অ্যাপ? অনেক অ্যাপ crash করলে সমস্যা নিচের স্তরে — RAM (Memory Diagnostic চালান), ডিস্ক বা OS. শুধু একটি অ্যাপ হলে ক্রমটা এমন:
- নির্দিষ্ট কাজে হয়? একটি নির্দিষ্ট ফাইলেই crash হলে ফাইলটি নষ্ট হতে পারে।
- আপডেট: অ্যাপ আর Windows দুটোই হালনাগাদ (software update) — আর আপডেটের পরেই শুরু হলে সেটাই “কী বদলেছে”।
- লগ পড়ুন: Reliability Monitor-এ crash-এর ওপর ক্লিক করলে বিস্তারিত; Event Viewer-এর Application লগে ID 1000-এ “Faulting module name” — কোন ফাইলের কারণে crash. সেই নাম দিয়ে খুঁজুন।
- Repair, তারপর reinstall: Settings → Apps → Installed apps → অ্যাপ → Advanced options-এ অনেক অ্যাপে Repair (ডেটা রাখে) আর Reset (অ্যাপের ডেটা মোছে — আগে ব্যাকআপ) থাকে।
- পুরোনো অ্যাপ নতুন Windows-এ: প্রোগ্রামের ফাইলে ডান-ক্লিক → Properties → Compatibility-তে আগের Windows-এর মোডে চালিয়ে দেখুন (compatibility মোড) — অনেক পুরোনো হিসাবের সফটওয়্যার এভাবে চলে।
অ্যান্টিভাইরাস অ্যাপটি আটকাচ্ছে মনে হলে পুরো সুরক্ষা বন্ধ করবেন না। আগে নিশ্চিত হোন অ্যাপটি অফিসিয়াল উৎসের; তারপর শুধু সেই অ্যাপের জন্য ব্যতিক্রম (exclusion) — আর তা-ও কোম্পানির IT-র অনুমতি নিয়ে।
কেস ৫: প্রিন্টার প্রিন্ট করে না
প্রিন্ট হলো একটি ছোট রিলে: অ্যাপ → Windows-এর print spooler (কাজের লাইন) → driver → সংযোগ (USB বা নেটওয়ার্ক) → প্রিন্টার। যেকোনো জায়গায় আটকাতে পারে। কাজের ক্রম:
- প্রিন্টার নিজে: চালু? কাগজ, কালি বা টোনার, কাগজ আটকানো, error বাতি? প্রিন্টারের নিজের বোতাম বা মেনু থেকে একটি test/configuration page ছাপুন — ছাপলে প্রিন্টার সুস্থ, সমস্যা কম্পিউটারের দিকে। এক পরীক্ষায় অর্ধেক পথ আলাদা।
- ঠিক প্রিন্টার বাছাই? প্রায়ই “Microsoft Print to PDF” বাছাই থাকে।
- আটকে থাকা লাইন: Settings → Bluetooth & devices → Printers & scanners → প্রিন্টার → Open print queue. একটি নষ্ট কাজ “Error” হয়ে থাকলে পেছনের সবাই আটকে থাকে — সেটি Cancel করুন। লাইন তবু না নড়লে Services (
services.msc)-এ “Print Spooler” Restart. - সংযোগ: Wi-Fi প্রিন্টার আর কম্পিউটার একই নেটওয়ার্কে? রাউটার restart-এর পর প্রিন্টারের IP বদলাতে পারে — কনফিগারেশন পেজে IP দেখে
pingকরুন। - Driver: নির্মাতার অফিসিয়াল সাইট থেকে আপনার মডেল আর Windows সংস্করণের driver; পুরোনোটি সরিয়ে নতুন করে যোগ।
কেস ৬: ফোনের স্টোরেজ ভরা, ব্যাটারি দ্রুত শেষ
Android ফোনে পদ্ধতি একই, শুধু টুল আলাদা (মেনুর নাম ব্র্যান্ডভেদে একটু আলাদা হয়):
- স্টোরেজ: Settings → Storage — কোন ভাগ (ছবি, ভিডিও, অ্যাপ) কত বড়। প্রায়ই দোষী WhatsApp বা Messenger-এর জমানো মিডিয়া: WhatsApp → Settings → Storage and data → Manage storage-এ বড় ফাইল আর ফরওয়ার্ড করা ভিডিও বেছে মোছা যায়। কোনো অ্যাপের Clear cache নিরাপদ; কিন্তু Clear storage/Clear data সেই অ্যাপের সব ডেটা আর লগইন মুছে দেয় — পার্থক্য খেয়াল করুন। ছবি মোছার আগে Google Photos বা কম্পিউটারে ব্যাকআপ।
- ব্যাটারি: Settings → Battery → Battery usage — কোন অ্যাপ কতটা খাচ্ছে। সাধারণ কারণ: উজ্জ্বল পর্দা, দুর্বল নেটওয়ার্ক (ফোন বারবার টাওয়ার খোঁজে), পটভূমির অ্যাপ আর পুরোনো ব্যাটারির ক্ষয়। অচেনা কোনো অ্যাপ ব্যাটারি আর ডেটা দুটোই বেশি খেলে malware সন্দেহ করুন।
- সমস্যা কি তৃতীয় পক্ষের অ্যাপে? অনেক Android ফোনে পাওয়ার বোতাম চেপে “Power off”-এ লম্বা চাপ দিলে safe mode-এ চালুর অপশন আসে — শুধু ফোনের নিজস্ব অ্যাপ চলে। safe mode-এ সমস্যা না থাকলে দোষী কোনো ইনস্টল করা অ্যাপ: সাম্প্রতিকগুলো একটি একটি করে সরান।
৯ · কখন থামবেন, কীভাবে লিখে রাখবেন, মানুষের সাথে কীভাবে কথা বলবেন
কখন নিজে না করে বিশেষজ্ঞের কাছে
- ধোঁয়া, পোড়া গন্ধ, ফুলে ওঠা ব্যাটারি: সাথে সাথে বিদ্যুৎ বিচ্ছিন্ন, ব্যবহার বন্ধ। ফোলা লিথিয়াম ব্যাটারিতে আগুনের ঝুঁকি — চাপ দেবেন না, ছিদ্র করবেন না।
- HDD থেকে ক্লিক-ক্লিক শব্দ, বা ডিস্ক চেনা যাচ্ছে না, অথচ ভেতরে অমূল্য ডেটা: বন্ধ করুন, আর চালাবেন না। প্রতিবার চালু করা আর রিকভারি সফটওয়্যার চালানো ক্ষতি বাড়াতে পারে। পেশাদার data recovery প্রতিষ্ঠানের কাছে নিন।
- পানি পড়েছে বা ওয়ারেন্টি আছে: চালু বা চার্জ না করে দোকানে; নিজে খুললে ওয়ারেন্টি বাতিল হতে পারে।
- অফিসে অনুমতির বাইরে (সার্ভার, ফায়ারওয়াল, অন্যের অ্যাকাউন্ট): escalation.
যেকোনো মেরামতের আগে ব্যাকআপ। driver বদল, Reset, ডিস্কের কাজ, এমনকি Windows-এর বড় আপডেট — শুরুর আগে জরুরি ফাইল অন্য কোথাও আছে কি না নিশ্চিত হোন।
লিখে রাখা — লগ খাতা আর টিকেট
একটি সাধারণ খাতা বা স্প্রেডশিটই যথেষ্ট (পর্ব ১০):
| তারিখ | যন্ত্র | লক্ষণ | মূল কারণ | সমাধান |
|---|---|---|---|---|
| ১২ অক্টো | নুসরাতের ল্যাপটপ | মাঝে মাঝে BSOD | USB Wi-Fi অ্যাডাপ্টারের পুরোনো driver | নির্মাতার নতুন driver; ৭ দিন যাচাই |
| ১৫ অক্টো | রাহিমের ল্যাপটপ | সাইট খোলে না | হাতে বসানো অচল DNS | DNS Automatic |
বড় অফিসে একই কাজ হয় help-desk ticket দিয়ে: প্রতিটি সমস্যার একটি নম্বর, কে জানালেন, অগ্রাধিকার (পুরো অফিসের ইন্টারনেট বন্ধ আর একজনের মাউস ধীর — দুটো সমান জরুরি নয়), অবস্থা (Open → Resolved → Closed) আর সমাধান। এই নোট জমেই তৈরি হয় অফিসের “knowledge base”.
মানুষের সাথে কথা বলা — নরম দক্ষতা
- আগে শুনুন, শেষ পর্যন্ত। বাধা না দিলে অর্ধেক তথ্য নিজে থেকেই আসে; ধৈর্য রাখুন।
- জারগন নয়, উপমা। “আপনার DNS resolver fail করছে” না বলে বলুন, “কম্পিউটার ঠিকানার বই খুলতে পারছিল না, বই বদলে দিয়েছি।”
- দোষ দেবেন না। “আপনি ভুল করেছেন” নয়, “এই সেটিং অনেকেই বদলে ফেলেন।”
- গোপনীয়তা রক্ষা করুন (পর্ব ৪৫)। অন্যের কম্পিউটারে ব্যক্তিগত ফাইল, ছবি, চ্যাট খুলবেন না। পাসওয়ার্ড জিজ্ঞেস করবেন না — দরকার হলে তাঁকেই টাইপ করতে বলুন। remote access শুধু সম্মতিতে। আর মনে রাখুন, “Microsoft থেকে বলছি, আপনার কম্পিউটারে ভাইরাস” ধরনের ফোন প্রতারণা (পর্ব ৪৩) — আসল সাপোর্ট এভাবে নিজে থেকে ফোন করে না।
পরীক্ষা ও ইন্টারভিউতে — IT সাপোর্ট, হেল্প ডেস্ক আর চাকরির পরীক্ষায় এ ধরনের প্রশ্ন প্রায়ই আসে:
- troubleshooting-এর ধাপগুলো কী? সমস্যা চিহ্নিত করা → সম্ভাব্য কারণ → পরীক্ষা → পরিকল্পনা ও প্রয়োগ → পুরো ব্যবস্থা যাচাই → লিখে রাখা।
- কম্পিউটারের IP
169.254.x.xহলে কী বোঝায়? DHCP সার্ভার থেকে ঠিকানা পায়নি; Windows নিজে APIPA ঠিকানা নিয়েছে — রাউটার বা সংযোগ পরীক্ষা করতে হবে। - ping কেন ব্যবহার করা হয়? একটি যন্ত্র নেটওয়ার্কে পৌঁছানো যায় কি না আর উত্তর আসতে কত সময় লাগে (latency), তা দেখতে।
- safe mode কখন কাজে লাগে? শুধু জরুরি driver আর service নিয়ে চালু করে বোঝা যায় সমস্যা Windows-এর মূল অংশে, নাকি তৃতীয় পক্ষের driver বা অ্যাপে।
- চালুর সময় বিপ শব্দের মানে? POST হার্ডওয়্যারে (প্রায়ই RAM বা গ্রাফিক্স) সমস্যা পেয়েছে; বিপের ছন্দের অর্থ মাদারবোর্ড বা firmware নির্মাতার ম্যানুয়ালে মেলাতে হয়।
আরও গভীরে: একটি নেটওয়ার্ক সমস্যা পেশাদাররা কীভাবে স্তর ধরে ধরে (OSI মডেল) খোঁজেন, তা দেখুন আমাদের Computer Networks কোর্সের নেটওয়ার্ক সমস্যা ডিবাগিংয়ের কেস স্টাডি-তে। আর RAM কম পড়লে কেন কম্পিউটার হঠাৎ প্রায় থেমে যায় (thrashing), তা Operating Systems কোর্সের thrashing পর্বে — Resource Monitor-এর হার্ড ফল্টের পেছনের তত্ত্ব।
১০ · AI-এর যুগে — AI ভালো সহকারী, কিন্তু আপনিই সিদ্ধান্তদাতা
সমস্যা সমাধানে AI চ্যাটবট সত্যিই কাজের সঙ্গী: অচেনা error code ব্যাখ্যা করে, সম্ভাব্য কারণের তালিকা বানায়, কোন মেনু কোথায় বলে, এমনকি একটি ipconfig-এর আউটপুট পড়ে দেয়। কিন্তু AI-ও অনুমান করে — আর আত্মবিশ্বাসের সাথে ভুল বলতে পারে (AI hallucination): এমন মেনু যা আপনার সংস্করণে নেই, এমন কমান্ড যা আসলে ডেটা মোছে। কৌশল তাই এই পর্বের পদ্ধতিই: নির্দিষ্ট লক্ষণ আর হুবহু error দিন, আর তার পরামর্শকে হাইপোথিসিস ভাবুন — পরীক্ষায় না টেকা পর্যন্ত সত্য নয়।
নিচের prompt-টি কপি করে নিজের তথ্য বসান। খেয়াল করুন, AI-কে আগে প্রশ্ন করতে আর একবারে একটি নিরাপদ পরীক্ষা দিতে বলা হয়েছে:
AI-এর পরামর্শ মানার আগে — চেকলিস্ট
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিয়ে নিজে কিছুক্ষণ ভাবুন — তারপর “→ উত্তর” চাপুন। ভালো troubleshooting-এর পেছনে আছে বিজ্ঞান, প্রকৌশল আর মানুষের মনের অনেক পুরোনো শিক্ষা।
প্র ০১Troubleshooting কি আসলে বৈজ্ঞানিক পদ্ধতিরই আরেক রূপ? হাইপোথিসিস আর পরীক্ষার ভূমিকা কী?
বিজ্ঞানের পদ্ধতি সংক্ষেপে: পর্যবেক্ষণ, একটি ব্যাখ্যা প্রস্তাব (হাইপোথিসিস), সেই ব্যাখ্যা থেকে একটি ভবিষ্যদ্বাণী, তারপর পরীক্ষা করে দেখা ভবিষ্যদ্বাণী মেলে কি না। troubleshooting-এ ঠিক এটাই হয়। “নতুন driver-এর কারণে নীল পর্দা” একটি হাইপোথিসিস; তার ভবিষ্যদ্বাণী — “অ্যাডাপ্টার খুলে রাখলে নীল পর্দা থামবে”; দুই দিনের ব্যবহার হলো পরীক্ষা।
বিজ্ঞানের দার্শনিক Karl Popper একটি গুরুত্বপূর্ণ কথা বলেছিলেন: ভালো তত্ত্ব হলো যাকে ভুল প্রমাণ করা সম্ভব। “কম্পিউটারটার মুড খারাপ” — এটি পরীক্ষা করা যায় না, তাই কোনো কাজের নয়। “ডিস্ক মরছে” — পরীক্ষা করা যায় (SMART, Event Viewer), তাই কাজের। আরেকটি শিক্ষা: বিজ্ঞানীরা একবারে একটি চলক (variable) বদলান, বাকি সব স্থির রাখেন — যাতে ফলের কারণ নিশ্চিত হয়। একসাথে তিনটি জিনিস বদলানো troubleshooter সেই নিয়ম ভাঙেন।
মানুষের মনের একটি ফাঁদও আছে — confirmation bias: যা আগে থেকে বিশ্বাস করি, শুধু তার পক্ষের প্রমাণ চোখে পড়ে। “নিশ্চয়ই ভাইরাস” ভেবে বসলে আমরা ধীর ডিস্কের প্রমাণ উপেক্ষা করি। তাই ভালো troubleshooter নিজেকে জিজ্ঞেস করেন: “আমার ধারণা ভুল হলে কী দেখতে পেতাম?”
কম্পিউটারের “bug” শব্দের সাথেও একটি গল্প জড়িয়ে আছে। ১৯৪৭ সালে হার্ভার্ডের Mark II কম্পিউটারের একটি relay-তে আটকে থাকা একটি মথ পাওয়া যায়; দলটি সেটি লগবুকে টেপ দিয়ে লাগিয়ে লেখে “First actual case of bug being found” — দলে ছিলেন Grace Hopper, যিনি গল্পটি পরে জনপ্রিয় করেন। মজার ব্যাপার, “bug” মানে যন্ত্রের ত্রুটি — এই অর্থ তার আগেই প্রচলিত ছিল, Thomas Edison-ও উনিশ শতকে এভাবে লিখেছেন; তাই “প্রকৃত” পোকাটাই রসিকতা। কিন্তু লগবুকে সময়সহ লিখে রাখার অভ্যাসটি আজও শেখার মতো।
মূল উপলব্ধি: troubleshooting হলো ছোট পরিসরের বিজ্ঞান — পরীক্ষাযোগ্য অনুমান, একবারে একটি চলক, আর নিজের বিশ্বাসকে প্রশ্ন করার সাহস। যিনি এভাবে ভাবেন, তিনি অচেনা সমস্যাতেও পথ হারান না।
প্র ০২“It's always DNS” — নেটওয়ার্কের কিছু স্তর কেন বারবার সমস্যার উৎস হয়?
নেটওয়ার্ক প্রকৌশলীদের মধ্যে একটি পরিচিত রসিকতা আছে, তিন লাইনের কবিতার মতো: “এটা DNS নয় / কোনোভাবেই DNS হতে পারে না / ...এটা DNS-ই ছিল।” রসিকতাটি টিকে আছে কারণ এতে সত্য আছে। কেন DNS এত ঘন ঘন দোষী?
প্রথম কারণ — নির্ভরতা। প্রায় প্রতিটি ইন্টারনেট কাজ শুরু হয় একটি নাম থেকে IP বের করে (পর্ব ৩৩)। DNS না চললে ইন্টারনেটের পথ পুরো খোলা থাকলেও ব্যবহারকারীর কাছে মনে হয় “ইন্টারনেট নেই” — ঠিক রাহিমের ক্ষেত্রে যেমন। দ্বিতীয় কারণ — cache আর TTL (time to live — একটি উত্তর কতক্ষণ জমা রাখা যাবে, তার মেয়াদ)। DNS-এর উত্তর নানা জায়গায় কিছু সময়ের জন্য জমা থাকে। তাই কোনো ভুল সেটিং সাথে সাথে ধরা পড়ে না; ঘণ্টাখানেক পরে, কোথাও কোথাও, এলোমেলোভাবে সমস্যা দেখা দেয় — আর তখন কেউ মনে রাখে না সকালে কী বদলানো হয়েছিল। তৃতীয় কারণ — বিস্তৃতি: একটি বড় DNS সেবা থামলে হাজার হাজার আলাদা ওয়েবসাইট একসাথে “নষ্ট” মনে হয়।
২০১৬ সালের ২১ অক্টোবর এর বড় উদাহরণ: Dyn নামের একটি DNS সেবাদাতার ওপর Mirai botnet-এর বিশাল DDoS আক্রমণ হয় — লক্ষ লক্ষ হ্যাক হওয়া IoT ক্যামেরা আর রাউটার থেকে। ফলে Twitter, Netflix, Reddit-এর মতো অনেক বড় সাইট বহু ব্যবহারকারীর কাছে, বিশেষত যুক্তরাষ্ট্রে, কয়েক ঘণ্টা প্রায় অচল ছিল — অথচ সাইটগুলোর নিজেদের সার্ভার সুস্থ ছিল।
অন্য স্তরেরও নিজস্ব “চিরচেনা দোষী” আছে: শারীরিক স্তরে ঢিলা তার আর ধুলা; বিদ্যুতে লোডশেডিং-পরবর্তী ভোল্টেজ; অ্যাপে মেয়াদোত্তীর্ণ certificate. Pareto নীতির (মোটামুটি “৮০/২০ নিয়ম”) মতোই, অল্প কয়েকটি কারণ থেকে বেশিরভাগ সমস্যা আসে — তাই অভিজ্ঞরা এই চেনা দোষীদের আগে পরীক্ষা করেন।
মূল উপলব্ধি: যে উপাদানের ওপর অনেক কিছু নির্ভর করে, আর যার ভুল দেরিতে ও অনিয়মিতভাবে প্রকাশ পায়, সেটাই সবচেয়ে বেশি বিভ্রান্তি তৈরি করে। তাই “ইন্টারনেট নেই” শুনলে ping 8.8.8.8 আর nslookup দুটোই করুন — পথ আর নাম আলাদা করে পরীক্ষা।
প্র ০৩একটি ছোট পরিবর্তন কীভাবে বিশ্বজুড়ে বিভ্রাট ঘটায়? বড় কোম্পানিগুলো ঘটনার পর কী শেখে?
২০২১ সালের ৪ অক্টোবর প্রায় ছয় ঘণ্টা Facebook, Instagram, WhatsApp আর Messenger সারা বিশ্বে অচল ছিল। বাংলাদেশেও বহু অনলাইন দোকান সেদিন হঠাৎ যোগাযোগহীন হয়ে পড়ে। কোম্পানির প্রকাশিত ব্যাখ্যা অনুযায়ী, নিয়মিত রক্ষণাবেক্ষণের সময় নেটওয়ার্কের সক্ষমতা মাপার একটি কমান্ড ভুলবশত তাদের ডেটা সেন্টারগুলোর মূল সংযোগ (backbone) বিচ্ছিন্ন করে দেয়। এমন ভুল কমান্ড আটকানোর জন্য একটি যাচাই-টুল ছিল, কিন্তু তাতে একটি bug থাকায় সেটি কমান্ড থামায়নি।
এরপর একটি স্বয়ংক্রিয় নিরাপত্তা-ব্যবস্থাই সমস্যা বাড়াল। তাদের DNS সার্ভারগুলো ডেটা সেন্টারে পৌঁছাতে না পেরে ধরে নিল যে নিজেরা অসুস্থ, আর BGP-এর মাধ্যমে ইন্টারনেটকে নিজেদের পথের ঘোষণা তুলে নিল। ফলে বাকি পৃথিবীর কাছে facebook.com-এর ঠিকানাই হারিয়ে গেল। মেরামতও কঠিন হলো: দূর থেকে ঢোকার ব্যবস্থাও সেই নেটওয়ার্কেই চলত, তাই প্রকৌশলীদের সরাসরি ডেটা সেন্টারে যেতে হয়েছিল।
২০২৪ সালের ১৯ জুলাই আরেকটি উদাহরণ: নিরাপত্তা প্রতিষ্ঠান CrowdStrike-এর একটি ত্রুটিপূর্ণ কনটেন্ট আপডেটে বিশ্বজুড়ে Microsoft-এর হিসাবে প্রায় ৮৫ লাখ Windows কম্পিউটার নীল পর্দায় আটকে যায় — বিমানবন্দর, ব্যাংক, হাসপাতাল ক্ষতিগ্রস্ত হয়। সমাধান ছিল safe mode বা recovery পরিবেশে ঢুকে একটি ফাইল সরানো — হাতে হাতে, প্রতিটি কম্পিউটারে।
এমন ঘটনার পর ভালো প্রতিষ্ঠান লেখে একটি post-incident review বা postmortem: সময়রেখা, মূল কারণ, কী ভালো কাজ করেছে, কী করেনি, আর কোন পরিবর্তন হবে। Google-এর Site Reliability Engineering চর্চায় জোর দেওয়া হয় “blameless” হওয়ার ওপর — প্রশ্ন “কে ভুল করল?” নয়, “ব্যবস্থা একটি ভুলকে এত বড় হতে দিল কেন?” দোষারোপ করলে মানুষ ভুল লুকায়, আর লুকানো ভুল থেকে শেখা যায় না।
মূল উপলব্ধি: বড় বিভ্রাট প্রায় কখনো একটি কারণে হয় না — একটি ছোট ভুল, একটি ব্যর্থ নিরাপত্তা-জাল আর একটি অপ্রত্যাশিত নির্ভরতা মিলে হয়। ধাপে ধাপে চালু করা, ফেরার পথ রাখা আর লিখে শেখা — ছোট অফিস থেকে বিশাল কোম্পানি পর্যন্ত একই নীতি।
প্র ০৪একটি খেলনা হাঁসকে সমস্যা বোঝালে সমাধান মেলে কেন? “Rubber duck debugging”-এর রহস্য কী?
১৯৯৯ সালে Andrew Hunt আর David Thomas-এর বিখ্যাত বই The Pragmatic Programmer-এ একটি গল্প আছে: এক প্রোগ্রামার সাথে একটি রাবারের হাঁস রাখতেন, আর আটকে গেলে হাঁসটিকে লাইন ধরে ধরে নিজের কোড বুঝিয়ে বলতেন। প্রায়ই ব্যাখ্যার মাঝপথেই থেমে যেতেন — “আরে, এই লাইনে তো ভুল!” এখান থেকেই নাম rubber duck debugging.
কেন কাজ করে? মাথার ভেতরে আমরা সমস্যাকে ভাবি ঝাপসা, লাফিয়ে লাফিয়ে — “এটা তো ঠিকই আছে” বলে অনেক ধাপ বাদ দিই। কিন্তু অন্যকে বোঝাতে গেলে প্রতিটি ধাপ ক্রমানুসারে, স্পষ্ট ভাষায় বলতে হয়। তখন সেই বাদ পড়া অনুমানগুলো সামনে আসে: “তারপর ল্যাপটপ Wi-Fi-তে যুক্ত হয়... আসলে কোন Wi-Fi-তে, সেটা তো দেখিনি!” মনোবিজ্ঞানে কাছাকাছি একটি ধারণা আছে — অন্যকে শেখাতে গেলে নিজের বোঝা গভীর হয়।
IT সাপোর্টে এর দুটি ব্যবহারিক রূপ। প্রথমত, ব্যবহারকারীকে সমস্যাটি নিজের ভাষায় ধাপে ধাপে বলতে দিন — অনেক সময় বলতে বলতেই তিনি বলে ফেলেন, “ও হ্যাঁ, কাল একটা নতুন প্রোগ্রাম বসিয়েছিলাম।” দ্বিতীয়ত, escalation করার সময় বা ফোরামে প্রশ্ন লেখার সময় সমস্যাটি গুছিয়ে লেখা — কী আশা করেছিলেন, কী ঘটল, কী চেষ্টা করেছেন। ভালো করে প্রশ্ন লিখতে বসলে প্রায়ই পাঠানোর আগেই উত্তর মেলে।
আজ AI চ্যাটবট অনেকের কাছে একটি “কথা বলা হাঁস” — আর সুবিধা হলো সে পাল্টা প্রশ্নও করে। তবে মনে রাখুন, হাঁসের আসল কাজ ছিল আপনাকে ভাবতে বাধ্য করা, উত্তর দেওয়া নয়। AI যদি আপনার হয়ে ভাবা শুরু করে আর আপনি যাচাই না করে মেনে নেন, তাহলে হাঁসের উপকারটাই হারিয়ে যায়।
মূল উপলব্ধি: সমস্যা স্পষ্ট ভাষায় বলতে পারা মানেই অর্ধেক সমাধান। ব্যাখ্যা করার চাপ লুকানো অনুমানগুলোকে আলোয় আনে — সেটা হাঁস, সহকর্মী বা AI, যাকেই বলুন।
প্র ০৫Toyota-র “পাঁচবার কেন” কৌশল কী? লক্ষণ ছেড়ে মূল কারণে পৌঁছাতে এটি কীভাবে সাহায্য করে, আর এর সীমা কোথায়?
Five whys কৌশলের শিকড় Toyota-র প্রতিষ্ঠাতা পরিবারের Sakichi Toyoda-র চিন্তায়, আর একে বিখ্যাত করেন Toyota Production System-এর রূপকার Taiichi Ohno. তাঁর পরিচিত উদাহরণটি একটি যন্ত্র থেমে যাওয়া নিয়ে: কেন থামল? — overload-এ fuse পুড়েছে। কেন overload? — bearing-এ যথেষ্ট তেল ছিল না। কেন তেল ছিল না? — তেলের পাম্প ঠিকমতো টানছিল না। কেন? — পাম্পের দণ্ড ক্ষয়ে গেছে। কেন ক্ষয়েছে? — কোনো ছাঁকনি (strainer) ছিল না, ধাতুর গুঁড়া ঢুকেছে। শুধু fuse বদলালে যন্ত্র কয়েক দিন পর আবার থামত; ছাঁকনি লাগালে সমস্যা শেষ।
IT-তে একই চর্চা: অফিসের ওয়েবসাইট বন্ধ। কেন? — সার্ভারের ডিস্ক ভরা। কেন? — লগ ফাইল মাসের পর মাস জমেছে। কেন? — পুরোনো লগ মোছার স্বয়ংক্রিয় নিয়ম চালু করা হয়নি। কেন? — সার্ভার বসানোর চেকলিস্টে এই ধাপ নেই। প্রথম উত্তর (জায়গা খালি করা) জরুরি চিকিৎসা; শেষ উত্তর (চেকলিস্টে ধাপ যোগ) আসল প্রতিরোধ — ভবিষ্যতের প্রতিটি সার্ভারের জন্য।
তবে কৌশলটির সীমাও আছে, আর সমালোচকেরা তা নিয়ে লিখেছেন। প্রথমত, বাস্তবে কারণ প্রায়ই একটি সরলরেখা নয় — অনেকগুলো কারণ একসাথে কাজ করে; পাঁচবার “কেন” একটি মাত্র পথ ধরে এগোয়, অন্যগুলো বাদ পড়ে। এ জন্য Kaoru Ishikawa-র মাছের কাঁটার মতো দেখতে কারণ-চিত্র (fishbone diagram) দিয়ে একসাথে অনেক শাখা — মানুষ, পদ্ধতি, যন্ত্র, উপকরণ — দেখা হয়। দ্বিতীয়ত, শৃঙ্খলটি সহজেই “কারণ রহিম ভুল করেছে” এ থেমে যায় — যা আসলে মূল কারণ নয়; প্রশ্ন হওয়া উচিত, ব্যবস্থাটা ভুল করা এত সহজ করল কেন।
মূল উপলব্ধি: “কেন” বারবার জিজ্ঞেস করা আমাদের লক্ষণ সারানোর তৃপ্তি থেকে টেনে মূল কারণের দিকে নিয়ে যায়। সংখ্যা পাঁচ নিয়ম নয় — যতক্ষণ না এমন কারণে পৌঁছান যা বদলালে সমস্যা আর ফিরবে না, আর যা কোনো মানুষকে দোষ না দিয়ে ব্যবস্থাকে উন্নত করে।
অনুশীলন
প্রথম দুটি নিজের Windows কম্পিউটারে দেখে করুন — শুধু দেখবেন, কিছু বদলাবেন না। তৃতীয়টি ভাবনার, চতুর্থটি ওপরের সিদ্ধান্ত-বৃক্ষ নিয়ে।
-
Reliability Monitor পড়ুন: Win+R →
perfmon /rel. গত কয়েক সপ্তাহে কোন দিন স্থিতিশীলতার রেখা সবচেয়ে নিচে নেমেছিল? সেদিন কোন লাল ✖ বা নীল ⓘ ঘটনা আছে? দুটোর মধ্যে কোনো সম্পর্ক দেখছেন?সাধারণত দেখবেন, রেখা নেমেছে যেদিন কোনো অ্যাপ crash করেছে (“Application failures”) বা Windows ঠিকমতো বন্ধ হয়নি (“Windows failures” — যেমন লোডশেডিংয়ে হঠাৎ বন্ধ)। অনেক সময় আগের দিন বা সেদিনই একটি নীল ⓘ থাকে — কোনো আপডেট বা driver ইনস্টল। এই মিলটাই “কী বদলেছে?” প্রশ্নের প্রমাণ। ঘটনায় ডাবল-ক্লিক করলে বিস্তারিত — অ্যাপের নাম আর কোন ফাইলের কারণে crash. মনে রাখুন, মিল মানেই কারণ নয় — এটি একটি হাইপোথিসিস।
-
নিজের নেটওয়ার্ক চিনুন: টার্মিনালে
ipconfig /allচালিয়ে আপনার IPv4 ঠিকানা, Default Gateway আর DNS Servers লিখুন। তারপর gateway আর8.8.8.8-কে ping করুন। দুটির সময়ে (ms) পার্থক্য কেন?বাসার Wi-Fi-তে সাধারণত ঠিকানা হয়
192.168.0.xবা192.168.1.x, gateway রাউটারের ঠিকানা (যেমন192.168.0.1), আর DNS প্রায়ই রাউটারের ঠিকানাই বা ISP-র কোনো ঠিকানা। gateway-তে ping সাধারণত কয়েক ms, কারণ রাউটার একই ঘরে;8.8.8.8-তে কয়েক দশ ms, কারণ প্যাকেট ISP হয়ে দূরের সার্ভারে যায় আর ফেরে। gateway-র সময়ই যদি বেশি বা অনিয়মিত হয়, তাহলে ধীর গতির দোষ ঘরের Wi-Fi-র, ISP-র নয়। ঠিকানা169.254দিয়ে শুরু হলে DHCP থেকে ঠিকানা পাননি। -
অফিসের রহস্য: একটি অফিসে ১২টি কম্পিউটার, দুটি কক্ষে — প্রতিটি কক্ষে একটি করে switch, দুটি switch একটি রাউটারে যুক্ত। সকালে দ্বিতীয় কক্ষের ৬টি কম্পিউটারেই ইন্টারনেট নেই, প্রথম কক্ষে সব ঠিক। কোথা থেকে শুরু করবেন, আর কোন কোন জিনিস প্রথমেই সন্দেহের বাইরে?
পরিধিই সবচেয়ে বড় সূত্র। প্রথম কক্ষ ঠিক মানে রাউটার, ONU আর ISP ঠিক — সন্দেহের বাইরে। আবার একসাথে ৬টি কম্পিউটারের নিজস্ব সমস্যা হওয়ার সম্ভাবনা খুব কম। তাই সন্দেহ সেই জিনিসে, যা শুধু দ্বিতীয় কক্ষের সবাই ভাগ করে: দ্বিতীয় switch আর তার রাউটারমুখী তার। প্রথম পরীক্ষা: switch-এর বিদ্যুৎ আর বাতি (রাতে প্লাগ খুলে গেছে? লোডশেডিংয়ের পর চালু হয়নি?)। তারপর known-good পরীক্ষা: একটি কম্পিউটার সরাসরি রাউটারে বা প্রথম কক্ষের switch-এ লাগিয়ে দেখুন — চললে switch বা তার দোষী।
-
সিদ্ধান্ত-বৃক্ষে নতুন রোগী: ওপরের কোডে
diagnose('Shop', { gateway: false, dns: false });যোগ করে চালান। কোন লাইন পর্যন্ত ছাপবে, আরdns: falseদেওয়া সত্ত্বেও DNS-এর সমাধান কেন আসবে না?ছাপবে
--- Shop ---, তারপর তিনটি[YES](Other devices, Wi-Fi/cable, Valid IP), তারপর[NO ] ping gateway OK?আর=> Likely fix: Local problem: weak Wi-Fi, wrong network or cable. প্রথম ব্যর্থ পরীক্ষাতেইreturnহয়, তাই DNS পর্যন্ত যাওয়াই হয় না। বাস্তবেও তাই হওয়া উচিত: রাউটার পর্যন্তই যেতে না পারলে DNS পরীক্ষাও ব্যর্থ হবে — কিন্তু সেটি আসল কারণ নয়, নিচের স্তরের সমস্যার প্রতিধ্বনি।
নিজেকে যাচাই করুন
ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।
ক্রমTroubleshooting-এর ছয়টি ধাপ সঠিক ক্রমে সাজান (▲▼ চেপে সরান)
- 🔍 সমস্যা চিহ্নিত করা — প্রশ্ন, লক্ষণ, কী বদলেছে, ব্যাকআপ
- 💡 সম্ভাব্য কারণ (হাইপোথিসিস) দাঁড় করানো
- 🧪 পরীক্ষা করে অনুমান যাচাই
- 🛠️ সমাধানের পরিকল্পনা ও প্রয়োগ
- ✅ পুরো ব্যবস্থা ঠিক চলছে কি না যাচাই ও প্রতিরোধ
- 📝 কী পাওয়া গেল, কী করা হলো — লিখে রাখা
Windows কম্পিউটারে ipconfig চালিয়ে IPv4 ঠিকানা 169.254.23.7 দেখা গেল। এর সবচেয়ে সম্ভাব্য অর্থ কী?
- DNS সার্ভার কাজ করছে না
- ISP-র লাইন বন্ধ
- কম্পিউটার DHCP সার্ভার থেকে ঠিকানা পায়নি
- কম্পিউটার স্বাভাবিকভাবে ইন্টারনেটে যুক্ত
একটি ল্যাপটপ থেকে ping 8.8.8.8 সফল, কিন্তু ব্রাউজারে কোনো ওয়েবসাইটের নাম লিখলে খোলে না। সন্দেহ সবচেয়ে বেশি কোথায়?
- Wi-Fi সংযোগে
- DNS-এ
- ISP-র লাইনে
- নেটওয়ার্ক কার্ডে
৮টি সম্ভাব্য দোষীর মধ্যে ঠিক একটি দোষী। প্রতিবার সন্দেহভাজনের অর্ধেক পরীক্ষা করলে সবচেয়ে বেশি কয়টি পরীক্ষায় দোষী নিশ্চিত হবে?
- ১টি
- ২টি
- ৭টি
- ৩টি
Windows safe mode-এ চালু করলে কম্পিউটারের একটি সমস্যা আর দেখা যায় না। এ থেকে সবচেয়ে যুক্তিসংগত সিদ্ধান্ত কোনটি?
- সমস্যা সম্ভবত তৃতীয় পক্ষের কোনো driver, অ্যাপ বা startup প্রোগ্রামে
- Windows-এর মূল অংশ নষ্ট, নতুন করে বসাতে হবে
- RAM নিশ্চিতভাবে নষ্ট
- এখন থেকে সবসময় safe mode-এ কাজ করাই সমাধান
Windows-এর Resource Monitor-এ দেখা গেল ডিস্কের Active Time প্রায় সবসময় ১০০%, অথচ CPU ১৫% আর RAM অর্ধেক খালি। কম্পিউটার ধীর হওয়ার সম্ভাব্য বোতলের মুখ (bottleneck) কোনটি?
- CPU
- RAM
- ডিস্ক
- ইন্টারনেট সংযোগ
একটি পুরোনো HDD থেকে ক্লিক-ক্লিক শব্দ আসছে, আর তাতে ব্যাকআপ ছাড়া পরিবারের বহু বছরের ছবি আছে। সবচেয়ে ভালো সিদ্ধান্ত কোনটি?
- ডিস্ক আর চালু না করে পেশাদার data recovery সেবার কাছে নেওয়া
- ইন্টারনেট থেকে কয়েকটি রিকভারি সফটওয়্যার নামিয়ে একে একে চালানো
- ডিস্ক ফরম্যাট করে আবার চেষ্টা করা
- স্ক্রু খুলে ডিস্কের ভেতর পরিষ্কার করা
শব্দকোষ
লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন — অর্থ দেখাবে। এই পর্বের সব নতুন শব্দ এখানে একসাথে:
মনে রাখুন
- ছয় ধাপ: চিহ্নিত করা → সম্ভাব্য কারণ → পরীক্ষা → পরিকল্পনা ও প্রয়োগ → যাচাই → লিখে রাখা। একবারে একটি জিনিস বদলান, সস্তা পরীক্ষা আগে।
- সেরা প্রশ্ন: কী বদলেছে? কবে থেকে? error হুবহু কী? আবার ঘটানো যায়? পরিধি কত বড়?
- “কোথায়” খুঁজুন: স্তর ধরে (বিদ্যুৎ → হার্ডওয়্যার → OS → অ্যাপ → নেটওয়ার্ক → ব্যবহারকারী), half-splitting-এ অর্ধেক করে, আর known-good অংশ দিয়ে বদলে।
- নেটওয়ার্ক: কাছ থেকে দূরে —
ipconfig(169.254 = DHCP নেই) → ping gateway → ping 8.8.8.8 →nslookup. Windows-এ Resource Monitor, Event Viewer, Reliability Monitor প্রমাণ দেয়। - ডেটা আগে, লিখে রাখা সবসময়: মেরামতের আগে ব্যাকআপ; মূল্যবান ডেটার নষ্ট ডিস্কে পেশাদার। AI-র পরামর্শ হাইপোথিসিস — যাচাই করে, নিরাপত্তা বন্ধ না করে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পর্ব ৫০ · ক্যাপস্টোন — একটি ছোট অফিসের পুরো IT পরিকল্পনাপরবর্তী পর্বশেখা সব কিছু একটি বাস্তব প্রজেক্টে।
- পর্ব ৪৮ · ফ্রিল্যান্সিং আর ডিজিটাল ক্যারিয়ারআগের পর্বIT সাপোর্টও একটি ক্যারিয়ারের পথ।
- কম্পিউটার ফান্ডামেন্টালস ও ICT · কোর্স হোম৫৫টি পর্বপুরো কোর্সের রোডম্যাপ — কোন পর্ব কখন।
- Computer Networksগভীরে যানIP, DNS, DHCP, routing আর নেটওয়ার্ক ডিবাগিং বিস্তারিত।
- Operating Systemsপাশের ট্র্যাকprocess, মেমরি, paging আর ফাইল-সিস্টেম — স্লো কম্পিউটারের পেছনের তত্ত্ব।