শীর্ষ fakapov সায়ান

সব ভাল! 

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

প্রস্তাবনা

অনেক দিন আগে, যখন সিয়ানে মনোলিথ ছিল, এবং মাইক্রোসার্ভিসের কোনও ইঙ্গিত ছিল না, আমরা 3-5 পৃষ্ঠাগুলি পরীক্ষা করে একটি সংস্থানের প্রাপ্যতা পরিমাপ করেছি। 

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

সাইটের মূল পেজগুলোই বা কিভাবে বুঝলাম আমরা নিচের দিকে আঘাত করেছি

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

ধরা যাক আমরা খুঁজে পেয়েছি যে সাইটের অনেকগুলি অতি-গুরুত্বপূর্ণ বিভাগ রয়েছে যা প্রধান পরিষেবার জন্য দায়ী - বিজ্ঞাপনগুলি অনুসন্ধান করা এবং জমা দেওয়া৷ যদি ব্যর্থ হওয়া অনুরোধের সংখ্যা 1% ছাড়িয়ে যায়, এটি একটি গুরুতর ঘটনা। যদি প্রাইম টাইমে 15 মিনিটের মধ্যে ত্রুটির হার 0,1% ছাড়িয়ে যায়, তবে এটি একটি গুরুতর ঘটনা হিসাবে বিবেচিত হয়। এই মানদণ্ডগুলি বেশিরভাগ ঘটনাকে কভার করে; বাকিগুলি এই নিবন্ধের সুযোগের বাইরে।

শীর্ষ সেরা ঘটনা Cian

সুতরাং, আমরা অবশ্যই একটি ঘটনা ঘটেছে তা নির্ধারণ করতে শিখেছি। 

এখন প্রতিটি ঘটনা বিশদভাবে বর্ণনা করা হয়েছে এবং জিরা মহাকাব্যে প্রতিফলিত হয়েছে। যাইহোক: এর জন্য আমরা একটি পৃথক প্রকল্প শুরু করেছি, এটিকে FAIL বলা হয় - এটিতে কেবল মহাকাব্য তৈরি করা যেতে পারে। 

আপনি যদি গত কয়েক বছরের সমস্ত ব্যর্থতা সংগ্রহ করেন, নেতারা হলেন: 

• mssql সম্পর্কিত ঘটনা;
• বাহ্যিক কারণ দ্বারা সৃষ্ট ঘটনা;
• অ্যাডমিন ত্রুটি

আসুন প্রশাসকদের ভুলের পাশাপাশি কিছু অন্যান্য আকর্ষণীয় ব্যর্থতাগুলি আরও বিশদে দেখুন।

পঞ্চম স্থান - "ডিএনএসে জিনিসগুলিকে সাজানো"

এটি একটি ঝড় মঙ্গলবার ছিল. আমরা ডিএনএস ক্লাস্টারে শৃঙ্খলা পুনরুদ্ধার করার সিদ্ধান্ত নিয়েছি। 

আমি অভ্যন্তরীণ ডিএনএস সার্ভারগুলিকে বাইন্ড থেকে পাওয়ারডিএনএসে স্থানান্তর করতে চেয়েছিলাম, এর জন্য সম্পূর্ণ আলাদা সার্ভার বরাদ্দ করে, যেখানে ডিএনএস ছাড়া কিছুই নেই। 

আমরা আমাদের ডিসিগুলির প্রতিটি অবস্থানে একটি ডিএনএস সার্ভার রেখেছি, এবং মুহূর্তটি জোনগুলিকে বাইন্ড থেকে পাওয়ারডিএনএসে সরানোর এবং পরিকাঠামোটিকে নতুন সার্ভারে স্যুইচ করার সময় এসেছে৷ 

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

সিদ্ধান্তে:

আগে যদি আমরা কাজের প্রস্তুতির সময় বাহ্যিক কারণগুলিকে অবহেলা করে থাকি তবে এখন সেগুলিও আমরা যা প্রস্তুতি নিচ্ছি তার তালিকায় অন্তর্ভুক্ত করা হয়েছে। এবং এখন আমরা নিশ্চিত করার চেষ্টা করি যে সমস্ত উপাদান n-2 সংরক্ষিত থাকে এবং কাজের সময় আমরা এই স্তরটিকে n-1-এ নামিয়ে দিতে পারি।

• একটি অ্যাকশন প্ল্যান তৈরি করার সময়, সেই পয়েন্টগুলি চিহ্নিত করুন যেখানে পরিষেবাটি ব্যর্থ হতে পারে এবং এমন একটি দৃশ্যের মাধ্যমে চিন্তা করুন যেখানে সবকিছু "খারাপ থেকে খারাপ" হয়েছে।
• বিভিন্ন ভূ-অবস্থান/ডেটা সেন্টার/র্যাক/সুইচ/ইনপুট জুড়ে অভ্যন্তরীণ DNS সার্ভার বিতরণ করুন।
• প্রতিটি সার্ভারে, একটি স্থানীয় ক্যাশিং ডিএনএস সার্ভার ইনস্টল করুন, যা প্রধান ডিএনএস সার্ভারে অনুরোধগুলিকে পুনঃনির্দেশ করে এবং যদি এটি অনুপলব্ধ হয় তবে এটি ক্যাশে থেকে প্রতিক্রিয়া জানাবে। 

চতুর্থ স্থান - "এনজিনেক্সে জিনিসগুলি পরিষ্কার করা"

এক ভাল দিন, আমাদের দল সিদ্ধান্ত নিয়েছে যে "আমাদের এটি যথেষ্ট ছিল" এবং nginx কনফিগারেশনগুলি রিফ্যাক্টর করার প্রক্রিয়া শুরু হয়েছিল। মূল লক্ষ্য হল কনফিগারগুলিকে একটি স্বজ্ঞাত কাঠামোতে আনা। পূর্বে, সবকিছু "ঐতিহাসিকভাবে প্রতিষ্ঠিত" ছিল এবং কোন যুক্তি বহন করেনি। এখন প্রতিটি সার্ভার_নাম একই নামের একটি ফাইলে সরানো হয়েছে এবং সমস্ত কনফিগার ফোল্ডারে বিতরণ করা হয়েছে। যাইহোক, কনফিগারেশনে 253949 লাইন বা 7836520 অক্ষর রয়েছে এবং এটি প্রায় 7 মেগাবাইট নেয়। কাঠামোর শীর্ষ স্তর: 

Nginx গঠন

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

এটি অনেক ভালো হয়ে উঠেছে, কিন্তু কনফিগারের নাম পরিবর্তন ও বিতরণের প্রক্রিয়ায়, তাদের মধ্যে কিছু ভুল এক্সটেনশন ছিল এবং অন্তর্ভুক্ত *.conf নির্দেশে অন্তর্ভুক্ত ছিল না। ফলস্বরূপ, কিছু হোস্ট অনুপলব্ধ হয়ে ওঠে এবং মূল পৃষ্ঠায় 301 ফিরে আসে। প্রতিক্রিয়া কোডটি 5xx/4xx না হওয়ার কারণে, এটি অবিলম্বে লক্ষ্য করা যায়নি, তবে শুধুমাত্র সকালে। এর পরে, আমরা পরিকাঠামোর উপাদানগুলি পরীক্ষা করার জন্য পরীক্ষা লিখতে শুরু করি।

সিদ্ধান্তে: 

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

তৃতীয় স্থান - "হঠাৎ করে ক্যাসান্দ্রায় স্থান ফুরিয়ে গেল"

ডেটা ক্রমাগত বেড়েছে, এবং ক্যাসান্ড্রা ক্লাস্টারে বড় কেসস্পেসগুলির মেরামত ব্যর্থ হতে শুরু করার মুহুর্ত পর্যন্ত সবকিছু ঠিক ছিল, কারণ কম্প্যাকশন তাদের উপর কাজ করতে পারেনি। 

এক ঝড়ের দিন ক্লাস্টারটি প্রায় কুমড়ায় পরিণত হয়েছিল, যথা:

• ক্লাস্টারে মোট স্থানের প্রায় 20% বাকি ছিল;
• সম্পূর্ণরূপে নোড যোগ করা অসম্ভব, কারণ পার্টিশনে স্থানের অভাবের কারণে নোড যোগ করার পরে পরিষ্কার করা যায় না;
• কম্প্যাকশন কাজ না করায় উৎপাদনশীলতা ধীরে ধীরে কমে যায়; 
• ক্লাস্টার জরুরি মোডে আছে।

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

সিদ্ধান্তে:

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

দ্বিতীয় স্থান - "কনসাল কী-ভ্যালু স্টোরেজ থেকে ডেটা অদৃশ্য হয়ে গেছে"

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

সিদ্ধান্তে:

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

প্রথম স্থান - "ক্যাপ্টেন অপ্রকাশিত" 

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

সিদ্ধান্তে:

এই বাগটি অন্বেষণ করা খুব আকর্ষণীয় এবং উত্তেজনাপূর্ণ ছিল)। 

• আপনার পর্যবেক্ষণ সংগঠিত করুন যাতে এটি আপনাকে দ্রুত এই ধরনের ওঠানামা খুঁজে পেতে সহায়তা করে। উদাহরণস্বরূপ, আপনি প্রতিটি আপস্ট্রিমের প্রতিটি ব্যাকএন্ডে rps নিরীক্ষণ করতে ELK ব্যবহার করতে পারেন, nginx এর দৃষ্টিকোণ থেকে তাদের প্রতিক্রিয়া সময় নিরীক্ষণ করতে পারেন। এই ক্ষেত্রে, এটি আমাদের সমস্যা চিহ্নিত করতে সাহায্য করেছে। 

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

উত্স: www.habr.com