প্রোগ্রামার, ডেভপস এবং শ্রোডিঞ্জারের বিড়াল

একজন নেটওয়ার্ক ইঞ্জিনিয়ারের বাস্তবতা (নুডলস এবং... লবণ দিয়ে?)

সম্প্রতি, ইঞ্জিনিয়ারদের সাথে বিভিন্ন ঘটনা নিয়ে আলোচনা করার সময়, আমি একটি আকর্ষণীয় প্যাটার্ন লক্ষ্য করেছি।

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

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

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

আমি সবসময় ভাবতাম এমন কেন? কি তোলে প্রোগ্রামাররা এই ধারণার সমালোচনা করে যে "মূল কারণ একটি মিথ"? একটি ইমিউন সিস্টেমের মতো যা একটি বিদেশী এজেন্টকে স্বীকৃতি দেয়। কেন তারা এই ভাবে প্রতিক্রিয়া, যখন devops বরং ঝোঁক এই ধারণা বিবেচনা?

আমি সম্পূর্ণরূপে নিশ্চিত নই, তবে এই বিষয়ে আমার কিছু চিন্তা আছে। এটি বিভিন্ন প্রেক্ষাপটের সাথে সম্পর্কিত যেখানে এই পেশাদাররা তাদের দৈনন্দিন কাজ সম্পাদন করে।

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

সফ্টওয়্যার বিকাশের প্রাথমিক অনুমান: একই ইনপুট ডেটা নির্ভরযোগ্যভাবে এবং নির্ধারকভাবে একই আউটপুট তৈরি করে।

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

যাই হোক না কেন, ডিটারমিনিজম হল একটি মৌলিক, প্রায় গ্রহণযোগ্য অনুমান যা প্রোগ্রামাররা করে থাকে।

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

সুতরাং অভিজ্ঞ প্রকৌশলীদের পক্ষে সন্দেহ করা সহজ যে সমস্ত ঘটনার একটি একক মূল কারণ রয়েছে এবং "ফাইভ কেন" এর মতো কৌশলগুলি সঠিকভাবে (এবং বারবার!) সেই মূল কারণটির দিকে নিয়ে যাবে। আসলে, এটি তাদের নিজস্ব অভিজ্ঞতার বিরোধিতা করে, যেখানে ধাঁধার টুকরোগুলি অনুশীলনে এত সুন্দরভাবে মাপসই হয় না। অতএব, তারা এই ধারণাটি আরও সহজে গ্রহণ করে।

অবশ্যই, আমি বলছি না যে বিকাশকারীরা নির্বোধ, বোকা বা বুঝতে অক্ষম যে কীভাবে লিনিয়ারিটি প্রতারণামূলক হতে পারে। অভিজ্ঞ প্রোগ্রামাররাও সম্ভবত তাদের সময়ে অনেক অনির্ধারণবাদ দেখেছেন।

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

এটি পর্যবেক্ষিত বিকাশকারী প্রতিক্রিয়াগুলি সম্পূর্ণরূপে ব্যাখ্যা করতে পারে না, তবে এটি একটি শক্তিশালী অনুস্মারক যে আমাদের প্রতিক্রিয়াগুলি অনেকগুলি কারণের একটি জটিল মিশ্রণ৷

এই জটিলতাটি মনে রাখা গুরুত্বপূর্ণ, আমরা একটি একক ঘটনার সাথে মোকাবিলা করছি কিনা, একটি সফ্টওয়্যার বিতরণ পাইপলাইনে সহযোগিতা করছি বা বৃহত্তর বিশ্বকে বোঝার চেষ্টা করছি।

উত্স: www.habr.com