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

অনুমোদন রানটির, cron ফাইলের অস্তিত্বের নয়।

সবুজ রান মানে সম্পূর্ণ কাজ নয়

শিডিউলার লক্ষ করে যে একটি প্রক্রিয়া শুরু হয়েছে এবং পরে বেরিয়ে গেছে; সেই প্রক্রিয়া তার অস্তিত্বের উদ্দেশ্যে থাকা রিসোর্সে পৌঁছেছে কি না তা তার কোনো ধারণা নেই। যে স্ক্রিপ্ট ব্যর্থ সংযোগকে খালি ফলাফল হিসেবে ধরে, বা ত্রুটি ধরে শূন্য দিয়ে বেরিয়ে যায়, সেটি চিরকাল সুস্থ দেখাবে। উপসর্গটি লাল স্ট্যাটাস নয়; এটি অনুপস্থিত কাজের সাথে যুক্ত একটি বিশ্বাসযোগ্য স্ট্যাটাস।

যাচাই করার পদ্ধতি ঠিক করার আগে রানটির আসলে কী প্রয়োজন তা নাম দিন। একটি ব্যাকআপের প্রয়োজন হতে পারে ব্যক্তিগত DNS এবং প্রমাণিত এন্ডপয়েন্ট, কেবল একটি টানেল প্রক্রিয়া নয়।

সংযোগ যাচাই করুন, ইন্টারফেসের নাম নয়

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

বিচ্ছিন্ন অবস্থার ফলাফলও নির্ধারণ করুন। একটি সাধারণ বাদ পড়া, সংক্ষিপ্ত সময়ের মধ্যে পুনরায় চেষ্টা এবং অপারেটরের কাছে দৃশ্যমান মিস করা সময়সীমা তিনটি ভিন্ন উত্তর, এবং পুনরাবৃত্ত সময়সূচি এদের মধ্যে বেছে নেয় না।

বাদ পড়া ও ব্যর্থতা ভিন্ন ফলাফল

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

একটি systemd স্থাপনায় ExecCondition= কাজের ভার শুরুর আগে সেই পরীক্ষকটি চালায়। এর প্রস্থান আচরণ নির্দিষ্ট: শূন্য এগিয়ে যায়, এক থেকে 254 পর্যন্ত কোড ইউনিটকে ব্যর্থ চিহ্নিত না করেই বাকি শুরুর কমান্ডগুলো বাদ দেয়, আর 255 বা অস্বাভাবিক সমাপ্তি এটিকে ব্যর্থ করে। এটি তিনটি পৃথক সংকেত দেয়, যা কেবল তখনই কাজে লাগে যদি পরীক্ষকের চুক্তি সচেতনভাবে এগুলোর সাথে মিলিয়ে নেওয়া হয়। সফলতাকে পুনঃসংজ্ঞায়িত করা সেটিংস চিত্রটি বদলে দিতে পারে, তাই মিলকরণটি নথিভুক্ত করুন।

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

পুরো রান পাহারা দিন, কেবল শুরু নয়

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

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

তিনটি ক্ষেত্রে কর্মপ্রবাহটি গ্রহণ করুন: প্রস্তুত পথ, অনুপলব্ধ পথ, এবং চলার মাঝে ক্ষতি। এর চেয়ে কম কিছু সময়সূচি পরীক্ষা করে, কাজ নয়।

সম্পর্কিত নিবন্ধ