7.8 ডেটা মান ও পর্যবেক্ষণযোগ্যতা

পরিচিতি ও প্রেরণা

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

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

ডেটা পর্যবেক্ষণযোগ্যতা সেই শৃঙ্খলা যা আপনার ভোক্তাদের আগে এটি ধরে। এটি সফটওয়্যার পর্যবেক্ষণযোগ্যতা ও টেলিমেট্রি (অধ্যায় 9.2)-র সরাসরি সমান্তরাল: যে সহজাত বোধ আপনাকে অনুরোধ বিলম্ব ও ত্রুটি হার পর্যবেক্ষণ করতে বলে, তাই আপনাকে ডেটা সতেজতা, পরিমাণ, স্কিমা ও বিতরণ পর্যবেক্ষণ করতে বলে। এই অধ্যায় ডেটা কৌশল ও শাসন (অধ্যায় 7.1) এবং ডেটা প্রকৌশল (অধ্যায় 7.2)-এর ওপর গড়ে, এবং ডেটা মডেলিং ও শব্দার্থিক স্তর (অধ্যায় 7.7) এবং দায়িত্বশীল ও বিশ্বস্ত AI (অধ্যায় 6.5)-এ জোগান দেয়। অনেক উৎস সিস্টেম মেলানো এন্টারপ্রাইজ এবং বিধিবদ্ধ পরিসংখ্যান প্রকাশ করা সরকারের জন্য ডেটা নির্ভরযোগ্যতাকে মালিক ও সেবা-স্তরসহ প্রকৌশল সমস্যা গণ্য করা আস্থা ও একটি অত্যন্ত প্রকাশ্য সংশোধনের মধ্যে পার্থক্য।

মূল নীতিসমূহ

• ডেটা মান ব্যবহারের উপযুক্ততা, নিখুঁততা নয়; উদ্দেশ্যের বিপরীতে তা সংজ্ঞায়িত করুন।
• খারাপ ডেটা কোনো ডেটার চেয়েও খারাপ, কারণ এটি নীরবে সিদ্ধান্ত দূষিত করে।
• কোডের মতো ডেটা পরীক্ষা করুন: পাইপলাইনে দাবি, প্রত্যাশা ও স্কিমা পরীক্ষা।
• উৎপাদনকারী ও ভোক্তার মধ্যে চুক্তি প্রত্যাশা সুস্পষ্ট ও প্রয়োগযোগ্য করে।
• সেবা যেভাবে পর্যবেক্ষণ করেন সেভাবে সতেজতা, পরিমাণ, স্কিমা ও বিতরণ পর্যবেক্ষণ করুন।
• বংশধারা “কিছু ভুল আছে”-কে “এটি ভেঙেছে এবং এটি প্রভাবিত করে”-তে পরিণত করে।
• ডেটা ঘটনাকে মালিকানা, তীব্রতা ও সেবা-স্তরসহ প্রোডাকশন ঘটনার মতো গণ্য করুন।
• সমস্যা যেখানে ঢোকে সেখানে শনাক্ত করুন, একটি ড্যাশবোর্ডে তিন স্তর নিচে নয়।

সুপারিশ

মাত্রা অনুযায়ী মান সংজ্ঞায়িত করুন এবং তা মাপুন

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

দাবি ও প্রত্যাশা দিয়ে পাইপলাইন পরীক্ষা করুন

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

উৎপাদনকারী ও ভোক্তার মধ্যে ডেটা চুক্তি স্থাপন করুন

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

ডেটা পর্যবেক্ষণযোগ্যতার চারটি সংকেত পর্যবেক্ষণ করুন

ডেটা পর্যবেক্ষণযোগ্যতা চারটি সংকেত দেখে, আপনি একটি চলমান সেবা যেভাবে দেখেন তার সরাসরি সমান্তরালে (অধ্যায় 9.2)। সতেজতা: ডেটা কি যতটা সাম্প্রতিক হওয়া উচিত ততটা, নাকি পাইপলাইন থমকেছে। পরিমাণ: সারি গণনা কি প্রত্যাশিত পরিসরে, নাকি একটি টেবিল অর্ধেক-খালি বা দ্বিগুণ-লোড হয়ে এসেছে। স্কিমা: কাঠামো কি অপ্রত্যাশিতভাবে বদলেছে। বিতরণ: মান নিজেরাই কি ড্রিফট করেছে, যাতে ২ শতাংশ নাল থাকা একটি কলাম হঠাৎ ৪০ শতাংশ নাল, বা একটি গড় এমনভাবে সরেছে যা উজান বাগের সংকেত দেয়। আপনার গুরুত্বপূর্ণ টেবিলে এই সংকেত যন্ত্রসজ্জিত করুন, তাদের স্বাভাবিক প্যাটার্ন শিখুন এবং লঙ্ঘনে সতর্ক করুন। এভাবে আপনি “একজন নির্বাহী লক্ষ করলেন ড্যাশবোর্ড ভুল দেখাচ্ছে”-কে “মালিক দল ব্যর্থতার বিন্দুতে পেজ হলো” দিয়ে প্রতিস্থাপন করেন। ডেটা সমস্যার সম্ভাব্য সবচেয়ে খারাপ শনাক্তকারী হলো সংখ্যাটি বিশ্বাস করা একজন নিম্নধারা মানুষ।

অসঙ্গতি শনাক্তকরণ যোগ করুন, কিন্তু সতর্কতা-ক্লান্তির বিপরীতে সুর করুন

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

প্রভাব বিশ্লেষণ ও মূল কারণের জন্য বংশধারা অনুসরণ করুন

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

ডেটা ঘটনাকে প্রোডাকশন ঘটনার মতো গণ্য করুন

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

নিরন্তর প্রোফাইল ও মেলান

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

ট্রেড-অফ: সুবিধা ও অসুবিধা

পদ্ধতি	সুবিধা	অসুবিধা	সবচেয়ে ভালো মানায়
দাবি টেস্ট (কঠোর ব্যর্থতা)	খারাপ ডেটা ঠান্ডা থামায়, স্পষ্ট অপরিবর্তনীয়	ছোট সমস্যায় পাইপলাইন আটকাতে পারে	জটিল কী, রেফারেন্সিয়াল অখণ্ডতা
প্রত্যাশা টেস্ট (নরম চিহ্ন)	ড্রিফট ধরে, কম ভঙ্গুর	সুর লাগে, উপেক্ষিত হতে পারে	বিতরণ, পরিমাণ ব্যান্ড
ডেটা চুক্তি	উজান বিস্ময় ঠেকায়, স্পষ্ট মালিকানা	সমন্বয় ও শাসন ওভারহেড	আন্তঃ-দল উৎপাদনকারী বা ভোক্তা সীমানা
অসঙ্গতি শনাক্তকরণ	সূক্ষ্ম, অপ্রত্যাশিত ড্রিফট ধরে	সতর্কতা ক্লান্তি, মিথ্যা ইতিবাচক	উচ্চ-মূল্যের টেবিল, ঋতুভিত্তিক মেট্রিক
ম্যানুয়াল স্পট চেক	শুরু করা সস্তা, টুলিং নেই	স্কেল করে না, নীরব ত্রুটি মিস করে	কেবল খুব প্রারম্ভিক পর্যায়
পূর্ণ পর্যবেক্ষণযোগ্যতা প্ল্যাটফর্ম	ব্যাপক কভারেজ, বংশধারা, সতর্কতা	খরচ, সেটআপ, চালানোর আরেকটি সিস্টেম	অনেক উৎস, নিয়ন্ত্রিত প্রতিবেদন

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. খারাপ ডেটা প্রোডাকশনে পৌঁছালে প্রথমে কে জানতে পারে, এবং কীভাবে? এটি আপনার ডেটা নির্ভরযোগ্যতা সম্পর্কে একক সবচেয়ে প্রকাশক প্রশ্ন, কারণ সৎ উত্তর সাধারণত “একজন ভোক্তা, দৈবক্রমে।” একজন বিশ্লেষক, নির্বাহী বা গ্রাহক যদি আপনার শনাক্তকরণ সিস্টেম হন, আপনার শনাক্তকরণের গড় সময় দিনে মাপা হয় এবং প্রতিবার আপনার বিশ্বাসযোগ্যতা আঘাত পায়। বিকল্প হলো যন্ত্রসজ্জা যা খারাপ সংখ্যা ছড়ানোর আগে ব্যর্থতার বিন্দুতে মালিক দলকে পেজ করে। প্রকৃত সংখ্যা আনুন: আপনার শেষ দশটি ডেটা ঘটনার কতগুলো মনিটরিং দ্বারা ধরা পড়েছিল বনাম একজন নিম্নধারা মানুষ প্রতিবেদন করেছিলেন, এবং প্রতিটি কতক্ষণ অশনাক্ত ছিল। উত্তর বলে আপনার পর্যবেক্ষণযোগ্যতা আছে নাকি কেবল আশা, এবং আপনি প্রথমে কোথায় সতেজতা, পরিমাণ, স্কিমা ও বিতরণ পরীক্ষায় বিনিয়োগ করবেন তা সরাসরি চালানো উচিত।

2. কোন ডেটাসেটের মালিক, চুক্তি ও সেবা-স্তর আছে, এবং কোনগুলো এতিম? পরিসরে বেশিরভাগ ডেটা মান ব্যর্থতা একটি মালিকহীন ইন্টারফেসে ফিরে যায়: একটি উৎপাদনকারী দল কিছু বদলেছে কে নির্ভর করে জানা ছাড়া, কারণ কোনো চুক্তি তা বলেনি। মালিকানা সেই ভিত্তি যা চুক্তি, সতর্কতা পথ ও ঘটনা সাড়া সম্ভব করে, এবং এতিম ডেটাসেটই সেখানে নীরব দূষণ বাস করে। আপনার সবচেয়ে গুরুত্বপূর্ণ টেবিলের মধ্য দিয়ে যান এবং প্রতিটির জন্য জিজ্ঞেস করুন কে জবাবদিহিযোগ্য, উৎপাদনকারী কিসে প্রতিশ্রুতিবদ্ধ, এবং ভোক্তাদের কী সতেজতা ও নির্ভুলতার প্রতিশ্রুতি দেওয়া হয়েছে। আপনার বংশধারা আনুন: সবচেয়ে বড় নিম্নধারা ক্ষতির পরিসরসহ টেবিলগুলোরই এটি সবচেয়ে বেশি দরকার এবং প্রায়ই সেগুলোতেই এটি অনুপস্থিত। “গুরুত্বপূর্ণ” ও “মালিকানাধীন”-এর মধ্যকার ফাঁক আপনার পরবর্তী ত্রৈমাসিকের অগ্রাধিকার তালিকা।

3. একটি ডেটা মান ঘটনা আমাদের আসলে কত খরচ করে, এবং আমরা কি সেভাবে আচরণ করি? দল ডেটা মানে কম বিনিয়োগ করে কারণ খারাপ ডেটার খরচ ছড়ানো ও বিলম্বিত, তাই তা কখনো খরচের লাইন হিসেবে দেখা দেয় না, যেখানে মান টুলিং গড়ার খরচ সুনির্দিষ্ট ও তাৎক্ষণিক। একটি প্রকৃত ঘটনার শুরু-থেকে-শেষ দাম কষে এটি পুনঃফ্রেম করুন: ভুল সিদ্ধান্ত, পুনর্কাজ, বংশধারা ছাড়া মূল কারণ ট্রেসে ব্যয় হওয়া ইঞ্জিনিয়ার ঘণ্টা, মানুষ নীরবে নিজের ছায়া ডেটাসেট পুনর্নির্মাণ করায় ক্ষয়িত আস্থা, এবং নিয়ন্ত্রিত বা জনসম্মুখ পরিবেশে সংশোধন নোটিশ ও তার সুনামের ক্ষতি। গত বছরের একটি সুনির্দিষ্ট উদাহরণ আনুন এবং সততার সঙ্গে যোগফল কষুন। একটি পেমেন্ট বা জনসাধারণের পরিসংখ্যান পাইপলাইনে একটি একক নীরব ব্যর্থতা এক বছরের পর্যবেক্ষণযোগ্যতা টুলিংয়ের চেয়ে বেশি খরচ করতে পারলে ব্যবসায়িক যুক্তি নিজেই তৈরি হয়, এবং আলোচনা বিনিয়োগ করা হবে কি না থেকে কোথায় তাতে সরে।

4. আমরা কি ক্ষতির পরিসর অনুযায়ী আমাদের ডেটাসেট র‍্যাঙ্ক করেছি, এবং আমাদের মনিটরিং বিনিয়োগ কি আসলে সেই র‍্যাঙ্কিং অনুসরণ করে? পরিসরে কেন্দ্রীয় ব্যর্থতার ধরন হলো নির্ভরযোগ্যতার প্রচেষ্টা সমানভাবে খরচ করা, ফলে কেউ বিশ্বাস না করা অন্বেষণমূলক টেবিল বোর্ড মেট্রিকে জোগান দেওয়া টেবিলের সমান মনোযোগ পায়, যখন একটি কম-মূল্যের টেবিলে চুলের-ট্রিগার সতর্কতা মানুষকে সেই চ্যানেল মিউট করতে প্রশিক্ষিত করে যা জটিল পেজও বহন করে। আপনি কোলাহলে না ডুবে সবকিছু যন্ত্রসজ্জিত করতে পারেন না, এবং সমস্যা আগে ভোক্তাদের কাছে পৌঁছাতে না দিয়ে কিছুই যন্ত্রসজ্জিত করতে পারেন না, তাই প্রকৃত সিদ্ধান্ত হলো পূর্ণ চিকিৎসা (চুক্তি, কঠোর দাবি, পর্যবেক্ষণযোগ্যতা এবং অন-কল মালিকানা) কোথায় যায় এবং হালকা-স্পর্শ প্রোফাইলিং কোথায় যথেষ্ট। আপনার টেবিলের একটি তালিকা আনুন যা তাদের ওপর কী নির্ভর করে তা দিয়ে চিহ্নিত: বোর্ড মেট্রিক, গ্রাহক-মুখী পণ্য, নিয়ন্ত্রক প্রতিবেদন এবং মেশিন লার্নিং মডেল, তারপর সেই র‍্যাঙ্কিং আজ আপনার পরীক্ষা ও সতর্কতা আসলে কোথায় বসে তার সঙ্গে তুলনা করুন। অনেক উৎস মেলানো এন্টারপ্রাইজ বা বিধিবদ্ধ পরিসংখ্যান প্রকাশ করা সরকারের জন্য আইনি বা জনসম্মুখ উন্মুক্ততাসহ টেবিল তালিকার শীর্ষে থাকে, এবং “ভুল হলে সবচেয়ে ক্ষতি” এবং “সবচেয়ে বেশি পর্যবেক্ষিত”-র মধ্যে যেকোনো ফাঁক এখনই সংশোধনযোগ্য একটি অগ্রাধিকার ত্রুটি।

5. কোন মেশিন লার্নিং মডেল ও বিশ্লেষণ আমরা কখনো যাচাই করি না এমন ডেটার ওপর সিদ্ধান্ত নিচ্ছে, এবং তারা নীরবে কী ত্রুটি এনকোড করছে? একটি ড্যাশবোর্ড একজন মানুষকে ভুল সংখ্যা দেখায় যিনি প্রশ্ন করতে পারেন, কিন্তু একটি মডেল ভুল ফিচারে প্রশিক্ষিত হয় এবং সেই ত্রুটি তার করা প্রতিটি পূর্বাভাসে এনকোড করে, এমন পরিসর ও অস্বচ্ছতায় যা ক্ষতি ধরা বা ফেরানো অনেক কঠিন করে। প্রতিদ্বন্দ্বী চাপ গতি: ডেটা বিজ্ঞান দল নতুন ফিচারে দ্রুত চলতে চায়, এবং প্রতিটি ফিডে যাচাই, চুক্তি ও সতেজতা গ্যারান্টি যোগ করা ঘর্ষণ মনে হয় যতক্ষণ না একটি মডেল নীরবে অবনতি হয় কারণ একটি উজান কলাম ড্রিফট করেছে। আপনার প্রোডাকশন মডেল ও বিশ্লেষণের একটি তালিকা, প্রতিটি যে ডেটাসেট ভোগ করে, এবং সেই ফিডের কোনগুলোর টেস্ট, চুক্তি ও পর্যবেক্ষণযোগ্যতা আছে বনাম কোনগুলো অরক্ষিত তার একটি সৎ চিহ্ন আনুন। যে এন্টারপ্রাইজ বা সরকারি পরিবেশে একটি মডেল ঋণ, সুবিধা বা প্রয়োগ সিদ্ধান্ত প্রভাবিত করে, অযাচাইকৃত প্রশিক্ষণ ডেটা একটি মান ঝুঁকির ওপরে একটি নিরীক্ষা ও ন্যায্যতা দায় হয়ে ওঠে, তাই কোন ফিড একটি মডেল রিলিজ গেট করে সেই প্রশ্নের একজন মালিক ও একটি নথিবদ্ধ উত্তর থাকা উচিত (অধ্যায় 6.5)।

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

খাতভেদে দৃষ্টিভঙ্গি

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

ছোট ব্যবসা। কোনো ডেটা ইঞ্জিনিয়ার নেই আর বাজেট কম, তাই একটি আলাদা স্ট্যাক দাঁড় করানোর বদলে আপনি যে ওয়্যারহাউস, BI টুল বা SaaS প্ল্যাটফর্মের দাম দেন তাতে ইতিমধ্যে গাঁথা মান ফিচারের ওপর ঝুঁকুন। আপনার প্রচেষ্টা সেই মুষ্টিমেয় সংখ্যায় কেন্দ্রীভূত করুন যা আসলে সিদ্ধান্ত চালায় (রাজস্ব, পাইপলাইন, ইনভেন্টরি), নিয়মিত ছন্দে একটি স্বাধীন উৎসের বিপরীতে সেগুলো স্যানিটি-চেক করুন, এবং বিক্রেতার সতেজতা ও স্কিমা সতর্কতা থাকলে যথেষ্ট ভালো গণ্য করুন। আপনি ইতিমধ্যে চালানো টুলে এমবেডেড মান কেনা রক্ষণাবেক্ষণের কেউ না থাকা পাইপলাইন গড়াকে হারায়।

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

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

উদাহরণ

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

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

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

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• ডেটা মানকে চলমান প্রকৌশল চর্চার বদলে এককালীন পরিষ্কার প্রকল্প গণ্য করা।
• ব্যর্থতার বিন্দুতে মনিটরিংয়ের বদলে নিম্নধারা ভোক্তাদের কাছ থেকে ব্যর্থতা আবিষ্কার করা।
• ডেটাসেটের মালিকানা নেই, তাই কিছু ভাঙলে কেউ জবাবদিহিযোগ্য নয় এবং কেউ পেজ হয় না।
• উৎপাদনকারীরা চুক্তি ছাড়া স্কিমা বা শব্দার্থিকতা বদলায়, প্রতিটি ভোক্তাকে নীরবে ভাঙে।
• অসঙ্গতি সতর্কতা এত কোলাহলপূর্ণ যে দল চ্যানেল মিউট করে এবং প্রকৃত ঘটনা মিস করে।
• অযাচাইকৃত ডেটা সরাসরি মেশিন লার্নিং মডেলে ঢোকানো, পরিসরে ত্রুটি এনকোড করা (অধ্যায় 6.5)।
• বংশধারা হাতে আঁকা ডায়াগ্রাম হিসেবে রক্ষণাবেক্ষণ করা যা আঁকার পরের দিনই ভুল।
• গুরুত্বপূর্ণ টেবিলে ব্যবহারের-উপযুক্ত মানের বদলে সর্বত্র নিখুঁত ডেটার পিছনে ছোটা।
• কাঁচা ডেটা মুছে ফেলা, ফলে পরে একটি মান বাগ দেখা দিলে আপনি পুনঃপ্রক্রিয়া বা মেলাতে পারেন না।

পরিপক্বতা মডেল

• স্তর 1, সূচনা: মান কারও কাজ নয়। সমস্যা ভোক্তারা খুঁজে পায়, সাধারণত একটি ভুল সংখ্যা একটি প্রতিবেদনে পৌঁছানোর পরে। কোনো টেস্ট, মনিটরিং বা মালিকানা নেই। সংশোধন ম্যানুয়াল অগ্নিনির্বাপণ, এবং একই ব্যর্থতা পুনরাবৃত্তি হয়।
• স্তর 2, বিকাশ: কিছু দল তাদের জটিল টেবিলে মৌলিক টেস্ট (কী, নাল, গ্রহণযোগ্য মান) এবং যে ডেটাসেট তারা সবচেয়ে বেশি যত্ন করে তাতে সামান্য সতেজতা ও পরিমাণ মনিটরিং যোগ করে। চর্চা যেখানে আছে সেখানে কাজ করে, কিন্তু কভারেজ ও কঠোরতা দল-ধরে-দল ভিন্ন, কিছুই প্রমিত নয়, এবং ঘটনা এখনো প্রতিক্রিয়াশীলভাবে সামলানো হয়।
• স্তর 3, মানসম্মতকরণ: মান মাত্রা সীমাসহ সংজ্ঞায়িত, এবং একই প্রত্যাশা দল জুড়ে প্রযোজ্য, কে একটি পাইপলাইন গড়েছে তার ওপর নির্ভর না করে। ডেটা চুক্তি মূল উৎপাদনকারী সীমানা শাসন করে, পর্যবেক্ষণযোগ্যতা গুরুত্বপূর্ণ টেবিলে সতেজতা, পরিমাণ, স্কিমা ও বিতরণ ঢাকে, এবং বংশধারা প্রভাব বিশ্লেষণ সমর্থন করে। প্রতিটি গুরুত্বপূর্ণ ডেটাসেটের একজন নামকরা মালিক আছে, এবং ডেটা ঘটনা প্রতিষ্ঠান-ব্যাপী একটি নথিবদ্ধ তীব্রতা ও সাড়া প্রক্রিয়া অনুসরণ করে।
• স্তর 4, ব্যবস্থাপনা: মান ও নির্ভরযোগ্যতা ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। ডেটা ডাউনটাইম প্রকৃত মেট্রিকে অনুসরণ করা হয়: শনাক্তকরণের গড় সময়, সমাধানের গড় সময়, সম্মত সেবা-স্তরের বিপরীতে সতেজতা ও নির্ভুলতা, এবং ত্রুটি বাজেট যা একটি ডেটাসেট কাজ ট্রিগার করার আগে খরচ করতে পারে। মেলানো ভাঙন হার, টেস্ট পাস হার এবং অসঙ্গতি মিথ্যা-ইতিবাচক হার সময়ের সঙ্গে প্রবণতা মাপা হয়, সতর্কতা অনুমানে নয় সেই সংখ্যার বিপরীতে সুর করা হয়, এবং একটি ডেটা রিলিজে যাওয়া-না-যাওয়ার সিদ্ধান্ত আশার বদলে ভিত্তিরেখার বিপরীতে মাপা মানের ওপর নেওয়া হয়।
• স্তর 5, সমন্বয়: মান ও পর্যবেক্ষণযোগ্যতা সর্বব্যাপী, স্বয়ংক্রিয় ও অভিযোজিত। অসঙ্গতি শনাক্তকরণ সূক্ষ্ম ড্রিফট ধরে, চুক্তি যান্ত্রিকভাবে প্রয়োগ হয়, এবং বংশধারা স্বয়ংক্রিয়ভাবে ধরা ও একটি ক্যাটালগে প্রকাশিত। ডেটার প্রোডাকশন সেবার মতো সেবা-স্তর ও অন-কল মালিকানা আছে, মেলানো নিরন্তর চলে, এবং দোষারোপহীন পোস্টমর্টেম ডেটা ডাউনটাইমের স্থির হ্রাসে জোগান দেয়। মান ডেটা শাসন, মেশিন লার্নিং ও ব্যবসায়িক পরিকল্পনার সঙ্গে একীভূত, এবং ডেটা পরিদৃশ্য সরলে প্রতিষ্ঠান নিরন্তর সীমা, কভারেজ ও মালিকানা পুনঃপরিসর করে।

আলোচনার ভাবনা

1. আপনার কোন টেবিল এক সপ্তাহ নীরবে ভুল হলে সবচেয়ে বেশি ক্ষতি করবে, এবং সেগুলোই কি আপনি সবচেয়ে বেশি পর্যবেক্ষণ করেন?
2. আপনার শেষ উজান-সৃষ্ট ঘটনা একটি ডেটা চুক্তি কোথায় ঠেকাত, এবং কেন একটি ছিল না?
3. একটি সাধারণ মূল-কারণ তদন্তে আজ কতটা প্রকৌশল সময় লাগে, এবং স্বয়ংক্রিয় বংশধারা কতটা বাঁচাবে?
4. আপনার কোনো মেশিন লার্নিং মডেল কি এমন ডেটায় প্রশিক্ষিত হচ্ছে যা আপনি যাচাই করেন না, এবং তারা কী ত্রুটি এনকোড করছে?
5. আপনার সতর্কতা কি এতটা ভালো সুর করা যে মানুষ প্রতিটি সতর্কতায় কাজ করে, নাকি কেউ চ্যানেল মিউট করেছে?
6. আপনার সবচেয়ে গুরুত্বপূর্ণ ভোক্তারা আসলে কোন সতেজতা ও নির্ভুলতা সেবা-স্তরে স্বাক্ষর করবে, এবং আপনি কি আজ তা পূরণ করতে পারেন?

প্রধান শিক্ষা

• ডেটা মান নির্ভুলতা, সম্পূর্ণতা, সামঞ্জস্য, সময়োপযোগিতা, বৈধতা ও অনন্যতা জুড়ে ব্যবহারের উপযুক্ততা।
• খারাপ ডেটা কোনো ডেটার চেয়েও খারাপ, কারণ এটি সিদ্ধান্ত ও মডেল নীরবে দূষিত করে।
• কোডের মতো ডেটা পরীক্ষা করুন: দাবি ও প্রত্যাশা টেস্টের সঙ্গে স্কিমা পরীক্ষা, CI-তে ও প্রোডাকশনে।
• উৎপাদনকারী ও ভোক্তার প্রত্যাশা সুস্পষ্ট ও প্রয়োগযোগ্য করতে ডেটা চুক্তি ব্যবহার করুন।
• সফটওয়্যার পর্যবেক্ষণযোগ্যতার সমান্তরালে সতেজতা, পরিমাণ, স্কিমা ও বিতরণ পর্যবেক্ষণ করুন (অধ্যায় 9.2)।
• দ্রুত মূল কারণ ও প্রভাব বিশ্লেষণের জন্য বংশধারা ধরুন, এবং ভোক্তাদের জন্য তা প্রকাশ করুন।
• ডেটা ঘটনাকে মালিকানা, তীব্রতা ও সেবা-স্তরসহ প্রোডাকশন ঘটনার মতো গণ্য করুন।
• যেখানে ভুল ডেটা সবচেয়ে ক্ষতি করে সেখানে যন্ত্রসজ্জিত করুন; সর্বত্র নিখুঁততা নয়, ব্যবহারের-উপযুক্ত মান লক্ষ্য করুন।

তথ্যসূত্র ও আরও পড়ার জন্য

• Barr Moses, Lior Gavish ও Molly Vorwerck, “Data Quality Fundamentals.”
• Jacek Majchrzak, Sven Balnojan ও Marian Siwiak, “Data Contracts.”
• Danette McGilvray, “Executing Data Quality Projects.”
• Thomas C. Redman, “Data Driven: Profiting from Your Most Important Business Asset.”
• Laura Sebastian-Coleman, “Measuring Data Quality for Ongoing Improvement.”
• Joe Reis ও Matt Housley, “Fundamentals of Data Engineering.”
• DAMA International, “DAMA-DMBOK: Data Management Body of Knowledge.”
• ISO/IEC 25012, “Data quality model.”