এলোমেলোভাবে নিজেদের হত্যা করার জন্য আমাদের কি প্রোগ্রাম ডিজাইন করা উচিত? [বন্ধ]


76

সংক্ষেপে, সামগ্রিক ব্যবস্থার ভালোর জন্য আমরা কি আমাদের প্রোগ্রাম, প্রসেস এবং থ্রেডগুলিকে নিম্ন স্তরে মৃত্যুর নকশা করি?

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

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

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

এই ধারণার একটি ইতিমধ্যে একটি নাম আছে? এটি ইতিমধ্যে শিল্পে ব্যবহৃত হচ্ছে?

সম্পাদনা

মন্তব্য এবং উত্তরগুলির ভিত্তিতে, আমি ভয় করি যে আমি আমার প্রশ্নে পরিষ্কার ছিলাম না। স্বচ্ছতার জন্য:

  • হ্যাঁ, আমি এলোমেলোভাবে বলতে চাইছি,
  • হ্যাঁ, আমি উত্পাদন বলতে চাই, এবং
  • না, কেবল পরীক্ষার জন্য নয়।

ব্যাখ্যা করার জন্য, আমি বহুচোষী জীবের সাথে সাদৃশ্য আঁকতে চাই।

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

একটি প্রোগ্রামে এলোমেলো মৃত্যুর অন্তর্ভুক্তি বৃহত্তর সিস্টেমকে অপ্রয়োজনীয় কৌশলগুলি গ্রহণযোগ্যতা বজায় রাখতে বাধ্য করবে। এই একই কৌশলগুলি কি অন্যান্য ধরণের অপ্রত্যাশিত ব্যর্থতার মুখে সিস্টেমকে স্থিতিশীল রাখতে সহায়তা করবে?

এবং, যদি কেউ এটি চেষ্টা করে থাকে তবে এটিকে কী বলা হয়? আমি ইতিমধ্যে এটি বিদ্যমান থাকলে এ সম্পর্কে আরও পড়তে চাই।


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

1
আমি যদি সঠিকভাবে বুঝতে পারি তবে এটি কিছুটা সম্পর্কিত হতে পারে: en.wikedia.org/wiki/Mutation_testing । মিউটেশন টেস্টিং আপনার পরীক্ষাগুলিকে শক্ত করতে সহায়তা করে, তবে আমি মনে করি আপনি নিজের কোডটিকে শক্ত করতে সহায়তা করার জন্য একটি এলোমেলো ভিত্তিক পদ্ধতির সন্ধান করছেন।
মেটাফাইট

10
আসলে, এই ধারণা কম্পিউটিং যত পুরাতন, এটা যে প্রোগ্রামে ব্যবহার করা হয়, এবং অবশ্যই একটি নাম আছে: এটা বলা হয়: বাগ
mouviciel

3
আপনার সরঞ্জাম নির্ভরযোগ্য হওয়ায় আপনি যদি কোনও অবিশ্বাস্য নেটওয়ার্কের পরীক্ষা না করেন তবে আপনি কোনও যোগাযোগ প্রোটোকল বাস্তবায়নকে কল করবেন না which
কাজ

5
মাইক্রোসফ্ট কিছুক্ষণ চেষ্টা করেছে, তারা এটিকে "উইন্ডোজ" কোডনাম দিয়ে ডাকে। যদি এটি আরও ভাল কৌশল তৈরি করে থাকে তবে বিতর্কযোগ্য ... এটি কেবল পরিবর্তে প্রত্যাশা কমিয়ে আনতে পারে।

উত্তর:


60

না।

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


10
ধন্যবাদ @ টেলাস্টিন। আমি মনে করি ক্রাশের কারণটি এখানে ফ্যাক্টর করতে পারে। উদ্দেশ্যমূলক মৃত্যু ক্রাশের পার্শ্ব-প্রতিক্রিয়া থাকতে পারে (লগ, ত্রুটি কোড, সংকেত) যা এটি একটি কোড ব্যর্থতা থেকে পৃথক করে।
জিম্বো

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

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

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

1
আপনি একটি স্মার্ট এলোমেলো ক্র্যাশার (কওস বানরের মতো) প্রয়োগ করতে পারেন যা কোনও প্রোগ্রাম এলোমেলোভাবে ক্র্যাশ হয়ে গেলে আপনাকে জানতে দেয়। আপনি যখন বৈধ ক্র্যাশটি আঘাত করেছেন এবং কখন এটি স্থিতিশীলতার পরীক্ষার ক্র্যাশ করেছেন তা আপনি জানেন।
জয়ন আর

19

ফল্ট সহনশীলতা প্রক্রিয়া পরীক্ষা করার জন্য সফ্টওয়্যার বা হার্ডওয়্যারের মধ্যে ত্রুটিগুলি প্রবর্তন করার প্রক্রিয়াটিকে ফাল্ট ইনজেকশন বলা হয় ।

উইকিপিডিয়া থেকে:

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


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

9

হ্যাঁ. হয়তো না.

পর্যায়ক্রমিক সমাপ্তি একটি দ্বি-তরোয়াল তরোয়াল। আপনি একটি প্রান্ত বা অন্য প্রান্তের সাথে আঘাত করতে যাচ্ছেন এবং যা দু'টি খারাপের চেয়ে কম তা আপনার পরিস্থিতির উপর নির্ভর করে।

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

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

আপনি যে একই থ্রেডে প্রচুর চালনা করেন সে ক্ষেত্রে (উদাহরণস্বরূপ, ওয়েব সার্ভারে), ব্যবহারিক সমাধানটি একটি মিশ্র পন্থা গ্রহণ করা হয় যা ফলস্বরূপ গ্রহণযোগ্য ব্যর্থতার হার হয় in আপনি যদি 100 টি থ্রেড চালান, 99: 1 এর স্বল্প-থেকে-দীর্ঘ অনুপাত চালানোর অর্থ হ'ল শুধুমাত্র একটি দীর্ঘমেয়াদী বাগ প্রদর্শন করবে এবং অন্যরা ব্যর্থতা ছাড়াই যা করা তা করা চালিয়ে যাবে। এটি তুলনা করুন যে 100% দীর্ঘ চলমান সাথে, যেখানে আপনি একই সাথে সমস্ত থ্রেড ব্যর্থ হওয়ার ঝুঁকিটি চালান।

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

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

আমি এলোমেলো সমাপ্তি করার বিরুদ্ধে সুপারিশ করব, কারণ এতে সময় সম্পর্কিত বাগগুলি পেরেক আরও কঠিন করে তোলে। কেওস বানর সুপারভাইজারি সফ্টওয়্যারটি কাজ করে তা নিশ্চিত করার জন্য এটি করে, যা কিছুটা ভিন্ন সমস্যা।


আপনি যদি এলোমেলো সময়ের ব্যবধানের পরে প্রক্রিয়াটি হত্যা করেন যা অনন্তে প্রসারিত হয়, তবে কিছু প্রক্রিয়া চিরকাল বেঁচে থাকবে। সুতরাং আমি মনে করি না যে হত্যার প্রক্রিয়া এলোমেলোভাবে দীর্ঘায়িত প্রক্রিয়াগুলির সাথে সমস্যাগুলি সনাক্ত করার সাথে বেমানান।
জোয়েরি সেব্রেচটস

9

আপনি কি সত্যই এলোমেলো মানে? আপনার সফ্টওয়্যার এলোমেলোভাবে নিজেকে হত্যা করা ভয়ানক ধারণা বলে মনে হচ্ছে। কোন পয়েন্টটি পরিবেশন করবে?

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

আমি বিশ্বাস করি যে 90 এর দশকের শেষ দিকে অ্যাপাচি ওয়েব সার্ভারটি এরকম কিছু ব্যবহার করেছিল। তাদের কর্মী প্রক্রিয়াগুলির একটি পুল ছিল (থ্রেড নয়) এবং প্রতিটি শ্রমিক প্রক্রিয়া একটি নির্দিষ্ট জীবনকাল পরে মারা যায়। এটি সার্ভারকে কিছু প্যাথলজিকাল অবস্থায় আটকে গিয়েছিল এমন কর্মী প্রক্রিয়া দ্বারা একচেটিয়াকরণ থেকে রক্ষা করে।

আমি কিছুদিন এলাকায় কাজ করি নি, তাই এখনও এই ঘটনাটি আছে কিনা তা আমি জানি না।


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

3
আজ অবধি, পাইথন মেমরি ফাঁসের ইউটিউবের সমাধানটি কেবল প্রক্রিয়াটি পুনরায় আরম্ভ করা।
জাভি

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

1
@ মার্কব্রেকেট দুর্ভাগ্যক্রমে, পর্যায়ক্রমিক পুনঃসূচনাটি খারাপ কোড সম্পর্কে প্রোগ্রামারদের নৈমিত্তিক করে বিপরীত উদ্দেশ্যে কাজ করে বলে মনে হচ্ছে। খারাপ কোডের কারণে সমস্যাগুলি যদি ঘাড়কে ঠিক করার মতো ব্যথা হয় তবে আমরা খারাপ কোড লেখার সম্ভাবনা কম করব।
অ্যান্থনি

+1 টি। এলোমেলো খারাপ। সংজ্ঞা অনুসারে, এটি এমন যে আপনি এর আচরণ সম্পর্কে ভবিষ্যদ্বাণী করতে পারবেন না। এমনকি যদি আপনি প্রোগ্রামটি প্রতিবার এবং বার বার বন্ধ করার উদ্দেশ্যে এটি রেখে দেন তবে এটি হতে পারে যে এটি এতো সহজেই সম্পন্ন হয় না, যেমনটি এলোমেলো হয়ে যায়, সুতরাং এটি সেখানে শুরু করার উদ্দেশ্যকে পরাস্ত করে। অনুমানযোগ্য মুহুর্তগুলিতে প্রক্রিয়াগুলি বন্ধ রাখা প্রোগ্রামার এবং সেই বিশেষ বৈশিষ্ট্যটি বিক্রয় করার চেষ্টাকারী বিপণনকারীদের পক্ষে সহজতর হতে পারে .. "হ্যাঁ, এটি ঠিক। এটি এলোমেলো মুহুর্তে বন্ধ হয়! না, এটি একটি বৈশিষ্ট্য! হ্যালো? হ্যালো?!"
নীল

7

আমি যে সমস্যাটি দেখছি তা হ'ল যদি এই জাতীয় প্রোগ্রামটি মারা যায় তবে আমরা কেবল "ওহ এটি অন্য একটি এলোমেলো সমাপ্তি - এটি নিয়ে উদ্বেগের কিছু নেই" বলব। তবে যদি এমন কোনও আসল সমস্যা হয় যার সমাধানের প্রয়োজন হয়? এটি উপেক্ষা করা হবে।

ডেভেলপাররা মাইস্টাইকগুলি তৈরি করা, বাগগুলি এটি উত্পাদন পদ্ধতিতে তৈরি করা, হার্ডওয়্যার ব্যর্থতা ইত্যাদির কারণে প্রোগ্রামগুলি ইতিমধ্যে "এলোমেলোভাবে" ব্যর্থ হয় this প্রোগ্রামগুলিতে মৃত্যুর নকশা তৈরি করা কেবলমাত্র ব্যর্থতার সম্ভাবনা বাড়িয়ে তোলে এবং কেবল আমাদেরকে অতিরিক্ত অর্থ বাড়াতে বাধ্য করে, যার অর্থ ব্যয় হয়।

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


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

4

অ্যাপ্লিকেশনটিতে এলোমেলো প্রস্থান কোড যুক্ত করার প্রয়োজন হবে না। পরীক্ষকরা স্ক্রিপ্টগুলি লিখতে পারেন যা এলোমেলোভাবে অ্যাপ্লিকেশনটির প্রক্রিয়াগুলিকে হত্যা করে।

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

বাহ্যিকভাবে অর্জন করা যায় এমন পরিস্থিতিতে প্রোগ্রামের জন্য টেস্ট কোড যুক্ত করবেন না।

এটি যদি উত্পাদনের উদ্দেশ্যে করা হয় তবে আমি বিশ্বাস করতে পারি না এটি গুরুতর!

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

বাস্তব বা বাস্তববাদী ত্রুটি যদি অ্যাপ্লিকেশনটিতে তৈরি করা হয় তবে তারা বাস্তব ক্ষতিসাধনের মতোই আর্থিক ক্ষতি করতে পারে এবং উদ্দেশ্যমূলক অর্থনৈতিক ক্ষতি মূলত সংজ্ঞা অনুসারে একটি অপরাধমূলক কাজ

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

এমনকি এটির মতো স্টান্টগুলি সম্পর্কেও ভাবেন না: এটিকে যতটা সম্ভব নির্ভরযোগ্যতার সাথে কাজ করুন এবং জাল ব্যর্থতার পরিস্থিতিগুলি কেবল বিশেষ বিল্ড বা কনফিগারেশনে রাখুন।


এটি গ্রহণযোগ্য উত্তর আইএমও হওয়া উচিত। এসআরপি এখানে প্রযোজ্য।
ব্যবহারকারী 408866

দুর্ভাগ্যক্রমে, আমি কেবল পরীক্ষার জন্য বোঝাতে চাইছি না। আমি ব্যাখ্যা করার জন্য প্রশ্নটি প্রসারিত করব।
জিম্বো

আপনি যদি এটি সঠিকভাবে করেন তবে এই এলোমেলো (এবং করুণাময় নয়!) ক্রাশগুলি কোনও স্থায়ী ক্ষতি করতে পারে না। এটি হ'ল: সময়ের সাথে আপনি এমন সমস্ত প্রান্তের কেসগুলি কেটে ফেলতে পারেন যেখানে ক্ষতি হয়; এর মধ্যে কয়েকটি আপনি কখনও টেস্টিং মেশিনে দেখতে পাবেন না। এবং যদি কখনও কখনও আসল ক্রাশ হয় তবে আপনার কোনও সমস্যাও হবে না। আমি কখনই এটি চেষ্টা করি নি, তবে এটি কিছু পরিস্থিতিতে আমার কাছে বোধগম্য মনে হয়। অবশ্যই এই কিছু যা অ্যাপ্লিকেশনের একটি সরকারী বৈশিষ্ট্য হওয়া প্রয়োজন, না কিছু উন্নয়নে sneaks।
হান্স-পিটার Störr

3

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


2

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

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

এক পর্যায়ে, আপনি নির্ধারণ করতে পারেন যে আপনি ব্যর্থতা হ'ল বা পরিচালনা করা হচ্ছে না তা নিশ্চিত। ব্যর্থতার পয়েন্টগুলি সনাক্ত করতে এখন আপনি এলোমেলোভাবে রাগটি টানতে শুরু করতে পারেন।

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


2

আপনি যে শব্দটির সন্ধান করছেন তা সম্প্রতি নাসিম নিকোলাস তালেব দ্বারা তৈরি করা হয়েছে: অ্যান্টিফ্রেগিলিটি। তাঁর অ্যান্টিফ্রেগিল বইটি অবশ্যই প্রস্তাবিত। এটি সবেমাত্র আইটির উল্লেখ করেছে তবে অব্যক্ত, সুস্পষ্ট সমান্তরালগুলি সবচেয়ে অনুপ্রেরণামূলক। তার ধারণা হ'ল ভঙ্গুর </> মজবুত </> মজবুত <-> অ্যান্টিফ্রেগিলির স্কেল প্রসারিত করা। এলোমেলো ইভেন্টগুলির সাথে সুগন্ধযুক্ত বিরতি, দৃust়তা এলোমেলো ইভেন্টগুলির সাথে পরিচালনা করে এবং এলোমেলো ইভেন্টগুলির সাথে অ্যান্টি-ভঙ্গুর লাভ।


1

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

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

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

আপনি ঠিক কী করছেন তা আমি জানি না তবে এটির মূল্য কি না তা জানার জন্য আপনার যদি ব্যর্থতা এমন কিছু মনে হয় যা আপনার অ্যাকাউন্টে নেওয়ার দরকার (যেমন এটি ব্যয় করা উপেক্ষা করে) বা এটি বিশ্লেষণ করা খুব ব্যয়বহুল কিছু (ত্রুটি গ্রহণের মতো) অ্যাকাউন্টে বিকাশের সময় খরচ করে)।


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

1

আইআইএস সার্ভারে একটি কনফিগারযোগ্য বৈশিষ্ট্য রয়েছে যা তারা নির্দিষ্ট পরিমাণ মেমোরি ব্যবহার করার পরে বা নির্দিষ্ট সংখ্যক অনুরোধগুলি পরিবেশন করার পরে বা নির্দিষ্ট টাইমস্প্যানের জন্য বেঁচে থাকার পরে কর্মীদের প্রক্রিয়াগুলি স্বয়ংক্রিয়ভাবে পুনর্ব্যবহার করে। ( http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx ) এবং ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx? Mfr = সত্য )

আইআইএসের মতো কোনও কন্টেইনার যখন এটি করে, এটি সার্ভারকে দুর্বৃত্ত প্রক্রিয়া থেকে রক্ষা করার জন্য অর্থবোধ করে। তবে আমি এটি বন্ধ রাখতে পছন্দ করব, কারণ আপনি যদি আপনার কোডটি পর্যাপ্ত পরিমাণে পরীক্ষা করে থাকেন তবে তা বোঝা যায় না।

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

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


1

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

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


2
লিঙ্কগুলি বাসি যায়। আপনার উত্তরটিতে ক্র্যাশ শুধুমাত্র সফ্টওয়্যার এর মূল পয়েন্টগুলি সংক্ষিপ্ত করে রাখলে আপনার উত্তর আরও শক্তিশালী হবে।

1

সত্যিই এলোমেলোভাবে, না। তবে একটি নির্দিষ্ট ব্যবধানে দীর্ঘ-চলমান প্রক্রিয়াগুলি / থ্রেডগুলি প্রস্থান / পুনঃসূচনা করার জন্য, বা প্রদত্ত (তবে নির্দিষ্ট মানদণ্ডের উপর নির্ভরশীল) সময়ের জন্য অলস থাকার পরে বা কোনও বিশেষ ধরণের কার্য সম্পাদন করার পরে সম্ভবত এটি ভাল ধারণা idea দীর্ঘ-চলমান প্রক্রিয়াগুলি বাসি জিনিসগুলি অন্তর্ভুক্ত করে অনিবার্যভাবে রাষ্ট্র গঠন করে, সম্ভবত সিস্টেমের স্থিতিশীলতার উন্নতি ঘটায়, অদলবদল স্থানটি প্রকাশিত হতে বাধা দেয়, যা সমস্তগুলি পরিষ্কার হয়ে যায় (বা পাওয়া উচিত)।


1

এটি আপনি যে ধরণের অ্যাপ্লিকেশনটি ডিজাইন করছেন তার উপর নির্ভর করে।

র্যান্ডম ক্র্যাশগুলি বিতরণকৃত (নেটওয়ার্কযুক্ত) সিস্টেমগুলির দৃust়তা পরীক্ষা ও উন্নত করার এক দুর্দান্ত উপায়।

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

তুমি এটা কিভাবে করলে? অপ্রয়োজনীয়তা যোগ করা এবং স্কেলিং একটি সাধারণ সমাধান।

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

যাইহোক, যদি আপনার প্রোগ্রামটি কোনও একক প্রক্রিয়া অ্যাপ্লিকেশন যা কোনও নেটওয়ার্কে কাজ করে না, তবে এটি নিজেই মেরে ফেললে কোনও কিছুই পরীক্ষা করা যায় না কারণ এর থেকে পুনরুদ্ধারের কোনও উপায় নেই।

বিশৃঙ্খলা বানর ধারণা সম্পর্কে কিছু অতিরিক্ত মন্তব্য এখানে দেওয়া হয়েছে: http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html


1

এটা সম্ভব যে মহাজাগতিক বিকিরণের কারণে একটি এলোমেলো বিট ফ্লিপ ঘটে । এই সমস্যাটি স্বীকৃতি পেয়েছে এবং বিট উল্টাপাল্টা যাতে না ঘটে সে জন্য বিভিন্ন কৌশল তৈরি করা হয়েছিল।

তবে এটি 100% ঠিক করা সম্ভব নয়, এবং স্মৃতি দুর্নীতি এখনও সমস্যা সৃষ্টি করতে পারে এবং এই সমস্যাগুলি এখনও চলছে ( খুব কম সম্ভাবনার সাথে )।

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

আপনার যদি কোনও সাধারণ ডেস্কটপ অ্যাপ্লিকেশন ডিজাইন করতে হয় তবে আপনার কোডটিতে বাগ হিসাবে ক্র্যাডগুলি এলোমেলো হওয়া উচিত।


0

এটি কোনও ধারণার বিদগ্ধ বলে মনে হয় না।

অ্যান্ড্রয়েড ওএস এলোমেলোভাবে ব্যবহারকারী অ্যাপস / পরিষেবাগুলিকে হত্যা করে এবং পুনরায় চালু করে। আমার অভিজ্ঞতায় এটি অবশ্যই আমাকে ত্রুটির অবস্থার বিষয়ে আরও গভীরভাবে চিন্তা করার পাশাপাশি আরও শক্তিশালী আর্কিটেকচার ডিজাইন করতে সহায়তা করেছে।


4
অ্যান্ড্রয়েডের ক্রিয়াগুলি এলোমেলো নয়, তবে ক্রিয়াকলাপগুলি যখন বলা হয় তখন রাষ্ট্রের সংরক্ষণ করতে সক্ষম হওয়া দরকার। একটি সূক্ষ্ম, কিন্তু গুরুত্বপূর্ণ, পার্থক্য আছে।
blrfl

আমি যা পড়েছি থেকে যে কোন গ্যারান্টি আছে onDestroy, onPause, onSaveInstanceState, ইত্যাদি ... কখনও কোনো কার্যকলাপ বা পরিষেবায় ডাকা হবে। একটি অ্যাপ স্তরে এমনকি onDestoryকলব্যাকও নেই isn't হ্যাঁ প্রশংসনীয় শাটডাউনগুলির জন্য কিছু হুক রয়েছে তবে আপনাকে এখনও এলোমেলো প্রস্থানের জন্য প্রস্তুত থাকতে হবে।
জাভি

onPause()কোনও কার্যকলাপ নিহত হওয়ার আগে আপনাকে কল করার নিশ্চয়তা দেওয়া হয়েছে । হানিকম্বের পরে, আপনি সেই প্লাসের গ্যারান্টিযুক্ত onStop()। অ্যান্ড্রয়েড অ্যাপ্লিকেশনগুলি কেবলমাত্র সম্পর্কিত ক্রিয়াকলাপের সংকলন যা সম্পর্কিত হতে পারে এবং যতক্ষণ পর্যন্ত মৃত্যুদণ্ড কার্যকর করার বিষয়টি সম্পর্কিত তেমন কোনও অ্যাপ-স্তরের ধারণা নেই।
ব্লারফ্ল

আহ্ জেনে ভাল।
জাভি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.