ক্যাওস ইঞ্জিনিয়ারিং: ইচ্ছাকৃত ধ্বংসের শিল্প। অংশ ২

বিঃদ্রঃ. অনুবাদ: এই নিবন্ধটি AWS প্রযুক্তি প্রচারক অ্যাড্রিয়ান হর্নসবির নিবন্ধগুলির একটি দুর্দান্ত সিরিজ অব্যাহত রেখেছে, যিনি আইটি সিস্টেমে ব্যর্থতার পরিণতিগুলিকে প্রশমিত করার জন্য পরীক্ষা-নিরীক্ষার গুরুত্বকে একটি সহজ এবং পরিষ্কার উপায়ে ব্যাখ্যা করতে সেট করেছেন৷

"যদি আপনি একটি পরিকল্পনা প্রস্তুত করতে ব্যর্থ হন, তাহলে আপনি ব্যর্থ হওয়ার পরিকল্পনা করেন।" - বেঞ্জামিন ফ্রাঙ্কলিন

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

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

দারুণ প্রশ্ন! যাইহোক, তিনি এই পান্ডা দ্বারা বিশেষভাবে বিরক্ত বলে মনে হচ্ছে না ...

বিশৃঙ্খলা পান্ডা সঙ্গে জগাখিচুড়ি না!

সংক্ষিপ্ত উত্তর: অনুরোধের পথ ধরে গুরুত্বপূর্ণ পরিষেবাগুলিকে লক্ষ্য করুন৷

দীর্ঘ কিন্তু পরিষ্কার উত্তর: বিশৃঙ্খলার সাথে পরীক্ষা কোথায় শুরু করবেন তা বোঝার জন্য তিনটি ক্ষেত্রে মনোযোগ দিন:

1. তাকান ক্র্যাশ ইতিহাস এবং নিদর্শন সনাক্ত করুন;
2. সিদ্ধান্ত সমালোচনামূলক নির্ভরতা;
3. তথাকথিত ব্যবহার করুন অতিরিক্ত আত্মবিশ্বাসের প্রভাব.

এটা মজার, কিন্তু এই অংশ ঠিক হিসাবে সহজে বলা যেতে পারে "আত্ম-আবিষ্কার এবং আলোকিতকরণের যাত্রা". এটিতে আমরা কিছু দুর্দান্ত যন্ত্রের সাথে "বাজানো" শুরু করব।

1. উত্তর অতীতে মিথ্যা

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

"বর্তমানকে বুঝতে হলে অতীতকে জানতে হবে।" - কার্ল সেগান

ব্যর্থতার ইতিহাস দেখুন, তাদের COE বা পোস্টমর্টেমগুলিতে ট্যাগ করুন এবং তাদের শ্রেণীবদ্ধ করুন। সাধারণ প্যাটার্নগুলি সনাক্ত করুন যা প্রায়শই সমস্যার দিকে পরিচালিত করে এবং প্রতিটি COE-এর জন্য নিজেকে নিম্নলিখিত প্রশ্ন জিজ্ঞাসা করুন:

"এটি কি ভবিষ্যদ্বাণী করা যেতে পারে এবং তাই ফল্ট ইনজেকশন দ্বারা প্রতিরোধ করা যেতে পারে?"

আমার ক্যারিয়ারের প্রথম দিকে একটি ব্যর্থতার কথা মনে আছে। এটি সহজেই প্রতিরোধ করা যেত যদি আমরা কয়েকটি সাধারণ বিশৃঙ্খলা পরীক্ষা চালাতাম:

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

যাইহোক, কিছুক্ষণের জন্য সবকিছু ঠিক ছিল।

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

হঠাৎ, অন্যান্য সমস্ত দৃষ্টান্তও স্বাস্থ্য পরীক্ষায় ব্যর্থ হতে শুরু করে।

একটি নতুন দৃষ্টান্ত শুরু করার জন্য প্যাকেজগুলি ডাউনলোড এবং ইনস্টল করা প্রয়োজন এবং অটোস্কেলিং গ্রুপে - একের পর এক - অক্ষম করতে ELB-এর চেয়ে অনেক বেশি সময় লেগেছে৷ এটা স্পষ্ট যে শীঘ্রই পুরো প্রক্রিয়াটি একটি জটিল পর্যায়ে পৌঁছেছে এবং অ্যাপ্লিকেশনটি ক্র্যাশ হয়ে গেছে।

তারপরে আমরা চিরতরে নিম্নলিখিত পয়েন্টগুলি বুঝতে পেরেছি:

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

এবং তাই, এটি কি পূর্বাভাস দেওয়া যেতে পারে, এবং তাই সমস্যাটি প্রবর্তন করে প্রতিরোধ করা যেতে পারে?

হাঁ, এবং বিভিন্ন উপায়ে।

প্রথমত, যেমন টুল ব্যবহার করে উচ্চ CPU ব্যবহার অনুকরণ করে stress-ng বা cpuburn:

❯ stress-ng --matrix 1 -t 60s

চাপ-এনজি

দ্বিতীয়ত, সঙ্গে উদাহরণ ওভারলোড করে wrk এবং অন্যান্য অনুরূপ উপযোগিতা:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

পরীক্ষাগুলি তুলনামূলকভাবে সহজ, তবে বাস্তব ব্যর্থতার চাপের মধ্য দিয়ে না গিয়ে চিন্তার জন্য কিছু ভাল খাবার সরবরাহ করতে পারে।

কিন্তু সেখানে থামবেন না. একটি পরীক্ষার পরিবেশে ক্র্যাশ পুনরুত্পাদন করার চেষ্টা করুন এবং আপনার প্রশ্নের উত্তর পরীক্ষা করুন "এটি কি পূর্বাভাস করা যেতে পারে এবং তাই একটি দোষ প্রবর্তন দ্বারা প্রতিরোধ করা যেতে পারে?" অনুমান পরীক্ষা করার জন্য এটি একটি বিশৃঙ্খলা পরীক্ষার মধ্যে একটি ছোট বিশৃঙ্খলা পরীক্ষা, কিন্তু একটি ব্যর্থতা দিয়ে শুরু।

এটা কি স্বপ্ন ছিল, নাকি সত্যিই ঘটেছে?

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

তারপর সবচেয়ে বড় পরিসরের সাথে সবচেয়ে সাধারণ প্যাটার্নগুলিতে স্যুইচ করুন।

2. একটি নির্ভরতা মানচিত্র তৈরি করুন

আপনার আবেদন সম্পর্কে চিন্তা করার জন্য একটি মুহূর্ত নিন. এর নির্ভরতার একটি পরিষ্কার মানচিত্র আছে? আপনি কি জানেন যে ব্যর্থতা থাকলে তাদের কী প্রভাব পড়বে?

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

নির্ভরতা সনাক্তকরণ এবং নথিভুক্ত করাকে বলা হয় "একটি নির্ভরতা মানচিত্র নির্মাণ» (নির্ভরতা ম্যাপিং). এটি সাধারণত কোড প্রোফাইলিং টুল ব্যবহার করে একটি বড় কোড বেস সহ অ্যাপ্লিকেশনের জন্য করা হয়। (কোড প্রোফাইলিং) এবং যন্ত্র (যন্ত্র). আপনি নেটওয়ার্ক ট্র্যাফিক নিরীক্ষণ করে একটি মানচিত্র তৈরি করতে পারেন।

যাইহোক, সমস্ত নির্ভরতা একই নয় (যা প্রক্রিয়াটিকে আরও জটিল করে তোলে)। কিছু সমালোচনামূলক, অন্যান্য - মাধ্যমিক (অন্তত তাত্ত্বিকভাবে, যেহেতু ক্র্যাশগুলি প্রায়শই নির্ভরশীলতার সমস্যাগুলির কারণে ঘটে যা অ-সমালোচনামূলক হিসাবে বিবেচিত হত).

সমালোচনামূলক নির্ভরতা ছাড়া, পরিষেবা কাজ করতে পারে না। অ-সমালোচনা নির্ভরতা "করা উচিত নয়» পতনের ক্ষেত্রে পরিষেবাকে প্রভাবিত করতে৷ নির্ভরতা বোঝার জন্য, আপনার অ্যাপ্লিকেশন দ্বারা ব্যবহৃত APIগুলি সম্পর্কে আপনার স্পষ্ট ধারণা থাকতে হবে। এটি মনে হওয়ার চেয়ে অনেক বেশি কঠিন হতে পারে - অন্তত বড় অ্যাপ্লিকেশনের জন্য।

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

আপনি যেমন প্রোগ্রাম ব্যবহার করতে পারেন netstat - একটি কমান্ড লাইন ইউটিলিটি যা সিস্টেমে সমস্ত নেটওয়ার্ক সংযোগের (সক্রিয় সকেট) একটি তালিকা প্রদর্শন করে। উদাহরণস্বরূপ, সমস্ত বর্তমান সংযোগ তালিকাভুক্ত করতে, টাইপ করুন:

❯ netstat -a | more 

AWS এ আপনি ব্যবহার করতে পারেন প্রবাহ লগ (ফ্লো লগ) VPC হল এমন একটি পদ্ধতি যা আপনাকে VPC-তে নেটওয়ার্ক ইন্টারফেসে যাওয়া বা থেকে IP ট্র্যাফিকের তথ্য সংগ্রহ করতে দেয়। এই ধরনের লগগুলি অন্যান্য কাজেও সাহায্য করতে পারে - উদাহরণস্বরূপ, কেন নির্দিষ্ট ট্র্যাফিক দৃষ্টান্তে পৌঁছায় না এই প্রশ্নের উত্তর খোঁজা৷

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

AWS এক্স-রে কনসোল

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

অনেক অ্যাপ্লিকেশন নির্ভরতার সাথে সংযোগ করতে DNS ব্যবহার করে, অন্যরা কনফিগারেশন ফাইলগুলিতে পরিষেবা আবিষ্কার বা এমনকি হার্ড-কোডেড আইপি ঠিকানা ব্যবহার করতে পারে (যেমন /etc/hosts).

উদাহরণস্বরূপ, আপনি তৈরি করতে পারেন DNS ব্ল্যাকহোল সাহায্যে iptables এবং দেখুন কি বিরতি. এটি করতে, নিম্নলিখিত কমান্ড লিখুন:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

DNS ব্ল্যাক হোল

যদি /etc/hosts বা অন্যান্য কনফিগারেশন ফাইল, আপনি এমন আইপি ঠিকানাগুলি খুঁজে পাবেন যেগুলি সম্পর্কে আপনি কিছুই জানেন না (হ্যাঁ, দুর্ভাগ্যবশত, এটিও ঘটে), আপনি আবার উদ্ধারে আসতে পারেন iptables. ধরা যাক আপনি আবিষ্কার করেছেন 8.8.8.8 এবং জানি না যে এটি Google এর সর্বজনীন DNS সার্ভার ঠিকানা। ব্যবহার করে iptables আপনি নিম্নলিখিত কমান্ড ব্যবহার করে এই ঠিকানায় আগত এবং বহির্গামী ট্র্যাফিক ব্লক করতে পারেন:

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

অ্যাক্সেস বন্ধ করা হচ্ছে

প্রথম নিয়মটি Google এর সর্বজনীন DNS থেকে সমস্ত প্যাকেট ড্রপ করে: ping কাজ করে, কিন্তু প্যাকেট ফেরত দেওয়া হয় না। দ্বিতীয় নিয়মটি আপনার সিস্টেম থেকে উদ্ভূত সমস্ত প্যাকেটকে Google-এর সর্বজনীন DNS-এর দিকে ড্রপ করে - এর প্রতিক্রিয়া হিসাবে ping আমরা পেতে অপারেশন অনুমতি না.

দ্রষ্টব্য: এই বিশেষ ক্ষেত্রে এটি ব্যবহার করা ভাল হবে whois 8.8.8.8, কিন্তু এই শুধু একটি উদাহরণ.

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

আপনি যদি লাল বড়িটি গ্রহণ করেন, আপনি ওয়ান্ডারল্যান্ডে থাকবেন, এবং আমি আপনাকে দেখাব যে খরগোশের গর্তটি কত গভীরে যায়।"

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

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

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

3. অতিরিক্ত আত্মবিশ্বাস থেকে সাবধান

"যে কোন কিছুর স্বপ্ন দেখে, তাতে বিশ্বাস করে।" - ডেমোস্থেনিস

আপনি কি কখনও শুনেছেন অতিরিক্ত আত্মবিশ্বাসের প্রভাব?

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

প্রবৃত্তি এবং অভিজ্ঞতার উপর ভিত্তি করে...

আমার অভিজ্ঞতায়, এই বিকৃতিটি বিশৃঙ্খল ইঞ্জিনিয়ারিং দিয়ে কোথায় শুরু করতে হবে তার একটি দুর্দান্ত ইঙ্গিত।

অতিরিক্ত আত্মবিশ্বাসী অপারেটর থেকে সাবধান থাকুন:

চার্লি: "এই জিনিসটি পাঁচ বছরে পড়েনি, সবকিছু ঠিক আছে!"
ক্র্যাশ: "অপেক্ষা কর... আমি শীঘ্রই সেখানে আসব!"

অত্যধিক আত্মবিশ্বাসের ফলস্বরূপ পক্ষপাত একটি প্রতারক এবং এমনকি বিপজ্জনক জিনিস যা এটিকে প্রভাবিত করে এমন বিভিন্ন কারণের কারণে। এটি বিশেষত সত্য যখন দলের সদস্যরা তাদের হৃদয়কে একটি প্রযুক্তিতে ঢেলে দেয় বা এটিকে "স্থির" করতে অনেক সময় ব্যয় করে।

সাতরে যাও

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

এই দ্বিতীয় অংশ শেষ হয়. অনুগ্রহ করে রিভিউ লিখুন, মতামত শেয়ার করুন বা শুধু হাততালি দিন মধ্যম. পরের অংশে আমি সত্যিই আমি সিস্টেমে ব্যর্থতা প্রবর্তনের জন্য সরঞ্জাম এবং পদ্ধতি বিবেচনা করব। পর্যন্ত!

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• «ক্যাওস ইঞ্জিনিয়ারিং: ইচ্ছাকৃত ধ্বংসের শিল্প। অংশ ২";
• «কুবারনেটসে কীভাবে উচ্চ প্রাপ্যতা অর্জন করা যায়";
• «মনিটরিং এবং কুবারনেটস (পর্যালোচনা এবং ভিডিও প্রতিবেদন)";
• «Kubernetes-এ kube-proxy এবং নোডের অনুপলব্ধতা নিয়ে পরীক্ষা করা হচ্ছে».

উত্স: www.habr.com