VPN স্বাস্থ্য পরীক্ষা ও অ্যাপ্লিকেশন স্বাস্থ্য পরীক্ষা আলাদা করুন

আপনার টানেল প্রক্রিয়া চলমান থাকলেও সুরক্ষিত সংযোগ ব্যবহারের অযোগ্য হতে পারে, আর একটি ব্যর্থ ওয়েব পেজ টানেল ভেঙে পড়ার প্রমাণ নয়। যখন একটি প্রোব সবগুলোর প্রতিনিধিত্ব করে, তখন একটি রিস্টার্ট নীতি ভুল কম্পোনেন্ট রিস্টার্ট করে এবং একে অটোমেশন বলে। নিচের প্রতিটি পরীক্ষা যে স্তরটি পর্যবেক্ষণ করে, তার ব্যর্থতা যে ক্রিয়া চালু করে এবং সেই ক্রিয়া কাজ করেছে এমন প্রমাণের নাম দেয়। শেষ ধাপটি পুরো সেটটিকে এমন একটি পৃষ্ঠায় পরিণত করে যা কেউ রাত তিনটায় অনুসরণ করতে পারে।

ধাপ 1: প্রতিটি পরীক্ষা যে স্তর পর্যবেক্ষণ করে তার নাম দিন

সেগুলোর কোনোটি লেখার আগে জিজ্ঞাসা করুন প্রতিটি প্রোব আসলে কী দেখতে পারে। লাইভনেস প্রমাণ করে ডেমন চালু আছে, হ্যান্ডশেক বা পিয়ার তালিকা প্রমাণ করে সম্পর্ক বিদ্যমান, রাউটেড অনুরোধ প্রমাণ করে ডেলিভারি, আর লুকআপ প্রমাণ করে রেজোলিউশন। তারা ঠিক এই ক্রমে ব্যর্থ হয়, এবং এর কোনোটিই পরেরটিকে বোঝায় না। একটি সবুজ প্রসেস চেক পাশে থাকা একটি মৃত টানেলই স্বাভাবিক অবস্থা, কোনো বিরোধ নয়।

চারটি চেক এই ক্রমে লিখুন, প্রতিটির সঠিক কমান্ড ও প্রত্যাশিত আউটপুটসহ। যে প্রোবের প্রত্যাশিত আউটপুট আপনি বলতে পারবেন না, সতর্কবার্তা দেখে থাকা প্রত্যেক অপারেটর তাকে আলাদাভাবে পড়বেন। একই তালিকা কেবল রানবুকে নয়, সতর্কবার্তার লেখাতেও দিন, যাতে রাতে জাগানো ব্যক্তি লক্ষণের আগে স্তরটির সঙ্গে দেখা করেন। প্রতিটি কমান্ড যে হোস্টে চলে সেখানে কপি-পেস্ট করার উপযোগী রাখুন।

তারপর অ্যাপ্লিকেশন চেকটি পঞ্চম, আলাদা আইটেম হিসেবে যোগ করুন। যে পৃষ্ঠার অ্যাকাউন্ট পরিষেবা বন্ধ, সেটি টানেল রিস্টার্ট করার ন্যায্যতা দেয় না।

ধাপ 2: প্রতিটি ব্যর্থতাকে একটি ক্রিয়ার সঙ্গে বাঁধুন

প্রতিটি চেকের জন্য ঠিক করুন কী রিস্টার্ট হবে, কী ব্লকড থাকবে এবং কী মানুষকে ডাকবে। টানেল স্তরের ব্যর্থতা টানেল রিস্টার্ট করার ন্যায্যতা দিতে পারে; রিজলভার ব্যর্থতা ক্লায়েন্টের DNS ইন্টিগ্রেশনের দিকে ইশারা করে; অ্যাপ্লিকেশন স্তরের ব্যর্থতা প্রায় কখনোই টানেল স্পর্শ করা উচিত নয়।

ব্যর্থতা কী করবে না তা বলুন, কারণ বিপজ্জনক ডিফল্টগুলোই অনুমতিদায়ক। অসুস্থ অবস্থা কখনোই সরাসরি অ্যাপ্লিকেশন ট্র্যাফিকের অনুমতি হয়ে উঠতে পারে না, কারণ যে ফলব্যাক নিঃশব্দে টানেল এড়িয়ে যায় তা টানেলের অস্তিত্বের কারণটাই সরিয়ে দেয়। ক্রিয়াগুলোও সংকুচিত করুন: একটি গন্তব্য ধীর বলে শেয়ার্ড কম্পোনেন্ট রিস্টার্ট করা স্থানীয় সমস্যাকে পুরো ফ্লিটের সমস্যা করে তোলে। এটি কারণ খুঁজতে আপনার প্রয়োজনীয় প্রমাণও নষ্ট করে।

ধাপ 3: প্রোবগুলো নিরীহ ও সস্তা রাখুন

ছোট, কেবল-পড়ার অনুরোধ ব্যবহার করুন: একটি স্ট্যাটিক রিসোর্স, নিজের নির্ভরতা জানায় এমন একটি স্বাস্থ্য এন্ডপয়েন্ট, অথবা আপনার নিয়ন্ত্রণাধীন পোর্টে TCP সংযোগ। শংসাপত্র, প্রাইভেট ব্রাউজিং এবং প্রতি ব্যবধানে অবস্থা বদলায় এমন কিছু এড়িয়ে চলুন, কারণ যে প্রোব লেখে তা নির্ধারিত সময়সূচিতে লোড টেস্ট।

প্রতিটি প্রোবের জন্য গন্তব্য, রুট প্রত্যাশা ও টাইমআউট লিখে রাখুন। রুট প্রত্যাশাই সেই ক্ষেত্র যা মানুষ বাদ দেয়, আর পরবর্তীতে সতর্কবার্তা পড়ার সময় টানেল ব্যর্থতাকে রাউটিং ভুল থেকে আলাদা করে ঠিক এই ক্ষেত্রটিই। আপনি যে পুনরুদ্ধারের সময় প্রতিশ্রুতি দেন তা থেকে ব্যবধান ও ব্যর্থতার সীমা বের করুন, এবং টাইমআউট ব্যবধানের চেয়ে ছোট রাখুন। পরেরটি শুরু হওয়ার সময়ও চলমান প্রোব একটি ব্যর্থতা দুইবার জানায় এবং ফ্ল্যাপের মতো দেখায়।

ধাপ 4: প্রতিটি স্তর ভাঙুন এবং সঠিক প্রোব লাল হচ্ছে কি না দেখুন

টানেল প্রক্রিয়া থামান এবং নিশ্চিত করুন প্রসেস চেক ব্যর্থ হয়, অথচ DNS হয়তো ক্যাশ থেকে উত্তর দিতে পারে। একটি রুট বদলান এবং নিশ্চিত করুন রাউটেড অনুরোধ ব্যর্থ হয়, অথচ প্রক্রিয়া ও হ্যান্ডশেক সুস্থ থাকে। শুধু DNS ভাঙুন এবং নিশ্চিত করুন অ্যাপ্লিকেশন চেক টানেল ত্রুটির বদলে রেজোলিউশন জানায়। যদি দুটি প্রোব সবসময় একসঙ্গে নড়ে, তবে আপনার ভাবনার চেয়ে কম চেক আছে।

একই শৃঙ্খলায় পুনরুদ্ধারের দিকটি পরীক্ষা করুন। স্তর পুনরুদ্ধারের পর প্রোবকে হাতে রিস্টার্ট ছাড়াই পরিষ্কার হতে হবে, আর যে ক্রিয়া চালু হয়েছিল তা পেছনে কোনো বাইপাস রেখে যাওয়া উচিত নয়। সবুজ অবস্থায় ভরসা করার আগে একটি পূর্ণ চক্র দেখুন, কারণ যে প্রোব কেবল হাতে পরিষ্কার হয় তা একটি ভাঙা পুনরুদ্ধার পথ লুকায়।

ধাপ 5: রানবুকটি সতর্কবার্তা যেখানে ইশারা করে সেখানে রাখুন

পাঁচ সারির একটি পৃষ্ঠা পুরো নকশা বহন করে: স্তর, কমান্ড, প্রত্যাশিত ফলাফল, ব্যর্থতায় ক্রিয়া, মালিক। প্রতিটি প্রোব সম্পর্কে একটি লাইন যোগ করুন যে এটি সচেতনভাবে কী পরীক্ষা করে না। সেই লাইনটিই পরের ব্যক্তিকে এমন ষষ্ঠ চেক যোগ করা থেকে আটকায় যা সবকিছু মাপে আর কিছুই আলাদা করে না। সতর্কবার্তার লেখা থেকে পৃষ্ঠাটির লিংক দিন, নইলে ঘটনা চলাকালে কেউ এটি খুলবে না।

কন্টেইনার ডিপ্লয়মেন্টে নির্ভরতার শর্ত কেবল স্টার্টআপ গড়ে, আর কিছুই না। Compose স্টার্টআপ ক্রম ও স্বাস্থ্য শর্ত ডকুমেন্টেশন বর্ণনা করে কীভাবে রেডিনেস পরিষেবাগুলো শুরুর ক্রম নির্ধারণ করে; এর কোনোটিই পরে ইগ্রেস নীতি প্রয়োগ করে না, আর কোনোটিই টানেল পড়ে গেলে বন্ধ হয়ে ব্যর্থ হয় না। ধারাবাহিক প্রয়োগের জন্য নিজস্ব নীতি ও নিজস্ব প্রোব দরকার, একই পৃষ্ঠায় লেখা।

রানবুক তখনই সম্পূর্ণ, যখন সঠিক স্তরটি পুনরুদ্ধার হয় এবং কেউ একটি অনুপলব্ধ ওয়েবসাইটকে ভাঙা টানেল হিসেবে না পড়ে। এটি টানেল নয়, নথিটিকেই পরীক্ষা করে।