HighLoad++, Evgeny Kuzovlev (EcommPay IT): ডাউনটাইমের এক মিনিটের জন্য $100000 খরচ হলে কী করবেন

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

পরবর্তী HighLoad++ সম্মেলন 6 এবং 7 এপ্রিল, 2020-এ সেন্ট পিটার্সবার্গে অনুষ্ঠিত হবে। বিস্তারিত এবং টিকিট এ লিংক. নভেম্বর 9, 18:00 | হাইলোড++ মস্কো 2018, দিল্লি + কলকাতা হল। থিসিস এবং উপহার.

Evgeniy Kuzovlev (এর পরে – EC): - বন্ধুরা, হ্যালো! আমার নাম কুজোভলেভ ইভজেনি। আমি EcommPay কোম্পানি থেকে এসেছি, একটি নির্দিষ্ট বিভাগ হল EcommPay IT, কোম্পানির গ্রুপের IT বিভাগ। এবং আজ আমরা ডাউনটাইম সম্পর্কে কথা বলব - কীভাবে সেগুলি এড়ানো যায়, কীভাবে তাদের পরিণতিগুলি এড়ানো যায় না তা কমিয়ে আনা যায়। বিষয়টি নিম্নরূপ বলা হয়েছে: "যখন ডাউনটাইমের এক মিনিটের জন্য $100 খরচ হয় তখন কী করবেন"? সামনের দিকে তাকিয়ে, আমাদের সংখ্যা তুলনামূলক।

EcommPay IT কি করে?

আমরা কারা? আমি তোমার সামনে দাঁড়িয়ে আছি কেন? এখানে তোমাকে কিছু বলার অধিকার আমার কেন? এবং আমরা এখানে আরো বিস্তারিত কি সম্পর্কে কথা বলতে হবে?

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

আমরা আমাদের সমস্ত পণ্য লিখেছি (এবং আমাদের কাছে সেগুলির অনেকগুলি রয়েছে - আমাদের বড় আইটি পণ্যগুলির লাইনে আমাদের প্রায় 16 টি বিভিন্ন উপাদান রয়েছে) নিজেরাই; আমরা নিজেরাই লিখি, আমরা নিজেদের বিকাশ করি। এবং এই মুহুর্তে আমরা প্রতিদিন প্রায় এক মিলিয়ন লেনদেন করি (মিলিয়ন সম্ভবত এটি বলার সঠিক উপায়)। আমরা একটি মোটামুটি তরুণ কোম্পানি - আমাদের বয়স মাত্র ছয় বছর।

6 বছর আগে এটি এমন একটি স্টার্টআপ ছিল যখন ছেলেরা ব্যবসার সাথে আসে। তারা একটি ধারণা দ্বারা একত্রিত হয়েছিল (একটি ধারণা ছাড়া আর কিছুই ছিল না), এবং আমরা দৌড়ে গেলাম। যেকোনো স্টার্টআপের মতো, আমরা দ্রুত দৌড়েছি... আমাদের জন্য, গুণমানের চেয়ে গতি বেশি গুরুত্বপূর্ণ।

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

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

ডাউনটাইমস অপারেশনের আদেশ।

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

যখন আমরা আমাদের দৃষ্টিভঙ্গি পরিবর্তন করতে শুরু করি, তখন আমরা 4টি আদেশ তৈরি করি। আমি সেগুলি স্লাইডে উপস্থাপন করেছি:

এই আদেশগুলি বেশ সহজ:

• দ্রুত সমস্যা চিহ্নিত করুন।
• আরও দ্রুত এটি পরিত্রাণ পেতে.
• কারণ বুঝতে সাহায্য করুন (পরে, বিকাশকারীদের জন্য)।
• এবং প্রমিত পদ্ধতি।

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

সমস্যা সমাধান: এগুলি কখন ঘটে এবং সেগুলি সম্পর্কে কী করতে হবে?

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

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

• হার্ডওয়্যার ব্যর্থতা.
• বাহ্যিক পরিষেবা ব্যর্থ হয়েছে৷
• সফ্টওয়্যার সংস্করণ পরিবর্তন (একই স্থাপনা)।
• বিস্ফোরক লোড বৃদ্ধি।

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

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

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

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

এই চারটি সমস্যার মধ্যে বেশ কয়েকটি ক্লাউড থাকলে তা সঙ্গে সঙ্গে সমাধান হয়ে যায়। আপনি যদি Microsoft Azhur, Ozone ক্লাউডের মধ্যে থাকেন, অথবা Yandex বা Mail থেকে আমাদের ক্লাউড ব্যবহার করেন, তাহলে অন্তত একটি হার্ডওয়্যার ত্রুটি তাদের সমস্যা হয়ে দাঁড়ায় এবং হার্ডওয়্যারের ত্রুটির পরিপ্রেক্ষিতে আপনার জন্য অবিলম্বে সবকিছু ঠিক হয়ে যায়।

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

সফ্টওয়্যার সংস্করণ পরিবর্তন. ঘাঁটি

আমাদের ডেভেলপারদের উৎপাদন অ্যাক্সেস নেই। কেন এমন হল? এটা ঠিক যে আমরা PCI DSS প্রত্যয়িত, এবং আমাদের ডেভেলপারদের "পণ্য"-এ প্রবেশ করার অধিকার নেই। এটা, সময়কাল. আদৌ। অতএব, উন্নয়নের দায়িত্ব ঠিক সেই মুহুর্তে শেষ হয় যখন ডেভেলপমেন্ট রিলিজের জন্য বিল্ড জমা দেয়।

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

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

সফ্টওয়্যার সংস্করণ পরিবর্তন করার জন্য প্রয়োজনীয়তা

তিনটি প্রয়োজনীয়তা আছে:

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

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

  এখানে দ্বিতীয় প্রশ্নের সমাধান হল মিনিমাইজেশন: আপনি আপনার ট্র্যাফিকের শুধুমাত্র একটি অংশ একটি নতুন লাইনে, একটি নতুন কোড সহ একটি লাইনে পাঠাতে পারেন (উদাহরণস্বরূপ, 2%)। আর এই 2% 100% নয়! যদি আপনি একটি অসফল স্থাপনার কারণে আপনার 100% ট্রাফিক হারিয়ে ফেলেন, তাহলে সেটা ভীতিকর; আপনি যদি আপনার ট্রাফিকের 2% হারান, তাহলে সেটা অপ্রীতিকর, কিন্তু এটা ভীতিকর নয়। অধিকন্তু, ব্যবহারকারীরা সম্ভবত এটি লক্ষ্য করবেন না, কারণ কিছু ক্ষেত্রে (সব ক্ষেত্রে নয়) একই ব্যবহারকারী, F5 টিপে, অন্য একটি কার্যকরী সংস্করণে নিয়ে যাওয়া হবে।

  নীল/সবুজ স্থাপন। রাউটিং

  যাইহোক, সবকিছু এত সহজ নয় "নীল/সবুজ স্থাপন"... আমাদের সমস্ত উপাদান তিনটি গ্রুপে বিভক্ত করা যেতে পারে:

  • এটি ফ্রন্টএন্ড (পেমেন্ট পেজ যা আমাদের ক্লায়েন্টরা দেখে);
  • প্রক্রিয়াকরণ কোর;
  • পেমেন্ট সিস্টেমের সাথে কাজ করার জন্য অ্যাডাপ্টার (ব্যাংক, মাস্টারকার্ড, ভিসা...)।

  এবং এখানে একটি সূক্ষ্মতা রয়েছে - সূক্ষ্মতাটি লাইনের মধ্যে রাউটিং এর মধ্যে রয়েছে। আপনি যদি ট্রাফিকের 100% পরিবর্তন করেন তবে আপনার এই সমস্যাগুলি থাকবে না। কিন্তু আপনি যদি 2% স্যুইচ করতে চান, আপনি প্রশ্ন জিজ্ঞাসা করতে শুরু করেন: "কিভাবে এটি করবেন?" সহজ জিনিসটি সোজা সামনে: আপনি এলোমেলো পছন্দ দ্বারা nginx-এ রাউন্ড রবিন সেট আপ করতে পারেন এবং আপনার বাম দিকে 2%, ডানে 98% আছে৷ কিন্তু এটা সবসময় উপযুক্ত নয়।

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

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

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

  এটি আমাদের জন্য উপযুক্ত নয় কারণ আমাদের ইতিমধ্যে নিয়মিত nginx ছিল। nginx+ এ স্যুইচ করা যে ব্যয়বহুল তা নয়, এটি আমাদের জন্য কিছুটা বেদনাদায়ক এবং খুব সঠিক নয়। উদাহরণস্বরূপ, "স্টিকস সেশনস" আমাদের জন্য কাজ করেনি এই সহজ কারণে যে "স্টিকস সেশন" "হয়-অথবা" এর উপর ভিত্তি করে রাউটিং অনুমোদন করে না। সেখানে আপনি উল্লেখ করতে পারেন যে আমরা "স্টিকস সেশন" কি করি, উদাহরণস্বরূপ, IP ঠিকানা বা IP ঠিকানা এবং কুকিজ বা পোস্টপ্যারামিটার দ্বারা, কিন্তু "হয়-অথবা" সেখানে আরও জটিল।

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

  এবং আমরা, আসলে, এই ধরনের একটি স্ক্রিপ্ট লিখেছি, নিজেদেরকে "ওপেনরেস্টি" সেট করেছি এবং এই স্ক্রিপ্টে আমরা 6 টি ভিন্ন প্যারামিটারের মাধ্যমে "বা" সংযোজন করে সাজাই। এক বা অন্য প্যারামিটারের উপস্থিতির উপর নির্ভর করে, আমরা জানি যে ব্যবহারকারী এক পৃষ্ঠা বা অন্য, এক লাইন বা অন্য একটি পৃষ্ঠায় এসেছেন।

  নীল/সবুজ স্থাপন। সুবিধাগুলি এবং অসুবিধাগুলি

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

  
  
  অতএব, এটি আমাদের জন্য কাজ করেনি - আমরা খোলামেলা করেছি। তদনুসারে, রাউটিং সহ আমরা এরকম কিছু পেয়েছি:

  নীল/সবুজ স্থাপনার, সেই অনুযায়ী, আমি যে সুবিধাগুলি উল্লেখ করেছি এবং অসুবিধাগুলি করেছি৷

  দুটি অসুবিধা:

  • আপনাকে রাউটিং নিয়ে বিরক্ত করতে হবে;
  • দ্বিতীয় প্রধান অসুবিধা হল খরচ.

  আপনার দ্বিগুণ সার্ভার দরকার, আপনার দ্বিগুণ অপারেশনাল রিসোর্স দরকার, এই পুরো চিড়িয়াখানাটি বজায় রাখার জন্য আপনাকে দ্বিগুণ প্রচেষ্টা ব্যয় করতে হবে।

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

  কিভাবে একটি দ্রুত স্থাপনা করতে?

  আমরা কীভাবে ন্যূনতমকরণ এবং দ্রুত রোলব্যাকের সমস্যাটি সমাধান করব সে সম্পর্কে কথা বলেছি, তবে প্রশ্নটি রয়ে গেছে: "কিভাবে দ্রুত স্থাপন করা যায়?"

  
  
  এটা এখানে সংক্ষিপ্ত এবং সহজ.

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

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

  বিস্ফোরক লোড বৃদ্ধি

  আমরা সফ্টওয়্যার সংস্করণ পরিবর্তন সম্পর্কে কথা বলেছি. আমাদের কাছে পরবর্তী জিনিস হল লোডের বিস্ফোরক বৃদ্ধি। এখানে, আমি সম্ভবত বোঝার বিস্ফোরক বৃদ্ধি দ্বারা বোঝাতে চাইছি একেবারে সঠিক জিনিস নয় ...

  আমরা একটি নতুন সিস্টেম লিখেছি - এটি পরিষেবা-ভিত্তিক, ফ্যাশনেবল, সুন্দর, সর্বত্র কর্মী, সর্বত্র সারি, সর্বত্র অসিঙ্ক্রোনি। এবং এই ধরনের সিস্টেমে, ডেটা বিভিন্ন প্রবাহের মাধ্যমে প্রবাহিত হতে পারে। প্রথম লেনদেনের জন্য, ১ম, ৩য়, ১০ম কর্মী ব্যবহার করা যেতে পারে, দ্বিতীয় লেনদেনের জন্য - ২য়, ৪র্থ, ৫ম। এবং আজ, ধরা যাক, সকালে আপনার কাছে একটি ডেটা প্রবাহ রয়েছে যা প্রথম তিনজন কর্মীকে ব্যবহার করে এবং সন্ধ্যায় এটি নাটকীয়ভাবে পরিবর্তিত হয় এবং সবকিছুই অন্য তিনজন কর্মীকে ব্যবহার করে।

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

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

  কেন এটা আমাদের জন্য একটি সমস্যা? আসুন একটু পিছিয়ে যাই। এখন আমাদের পিছনে প্রায় 70টি পেমেন্ট সিস্টেম রয়েছে। সকালে, ট্র্যাফিক Sberbank এর মধ্য দিয়ে যায়, তারপর Sberbank পড়ে যায়, উদাহরণস্বরূপ, এবং আমরা এটিকে অন্য পেমেন্ট সিস্টেমে স্যুইচ করি। Sberbank এর আগে আমাদের 100 জন কর্মী ছিল, এবং এর পরে আমাদের অন্য পেমেন্ট সিস্টেমের জন্য 100 জন কর্মী বৃদ্ধি করতে হবে। আর এসব কিছু মানুষের অংশগ্রহণ ছাড়াই হওয়া বাঞ্ছনীয়। কারণ যদি মানুষের অংশগ্রহণ থাকে, সেখানে একজন প্রকৌশলী 24/7 বসে থাকা উচিত, যিনি কেবল এটিই করবেন, কারণ এই ধরনের ব্যর্থতা, যখন 70 টি সিস্টেম আপনার পিছনে থাকে, নিয়মিত ঘটে।

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

  এখন পর্যন্ত আমরা এটা ওপেন সোর্স করিনি, কিন্তু রিপোর্টের পর হঠাৎ যদি বুঝতে পারি যে আপনার এমন একটি জিনিস দরকার, আপনার এটি দরকার, আমার পরিচিতিগুলি শেষ স্লাইডে রয়েছে - দয়া করে আমাকে লিখুন। অন্তত ১০-১২ জন থাকলে আমরা স্পন্সর করব।

  
  
  কিভাবে এটা কাজ করে? এর একটি কটাক্ষপাত করা যাক! সামনের দিকে তাকিয়ে: বাম দিকে আমাদের পর্যবেক্ষণের একটি অংশ রয়েছে: এটি একটি লাইন, শীর্ষে ইভেন্ট প্রক্রিয়াকরণের সময়, মাঝখানে লেনদেনের সংখ্যা, নীচে কর্মীদের সংখ্যা।

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

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

  মনিটরিং। কিভাবে দ্রুত সমস্যা চিহ্নিত করতে?

  এখন প্রথম পয়েন্টটি হল "কিভাবে দ্রুত সমস্যাটি সনাক্ত করা যায়?" মনিটরিং ! আমাদের কিছু বিষয় দ্রুত বুঝতে হবে। কি জিনিস আমরা দ্রুত বুঝতে হবে?

  
  
  তিনটি জিনিস!

  • আমাদের অবশ্যই আমাদের নিজস্ব সম্পদের কর্মক্ষমতা বুঝতে হবে এবং দ্রুত বুঝতে হবে।
  • আমাদের অবশ্যই ব্যর্থতাগুলিকে দ্রুত বুঝতে হবে এবং আমাদের বাহ্যিক সিস্টেমগুলির কার্যকারিতা নিরীক্ষণ করতে হবে।
  • তৃতীয় পয়েন্ট হল যৌক্তিক ত্রুটি চিহ্নিত করা। এটি যখন সিস্টেমটি আপনার জন্য কাজ করছে, সমস্ত সূচক অনুযায়ী সবকিছু স্বাভাবিক, কিন্তু কিছু ভুল হয়ে যায়।

  আমি সম্ভবত আপনাকে এখানে এমন কিছু বলব না। আমি ক্যাপ্টেন স্পষ্ট হব. আমরা বাজারে যা ছিল তা খুঁজছিলাম। আমাদের একটি "মজা চিড়িয়াখানা" আছে। এই ধরনের চিড়িয়াখানা আমাদের এখন আছে:

  
  
  আমরা হার্ডওয়্যার নিরীক্ষণ করতে, সার্ভারের প্রধান সূচকগুলি নিরীক্ষণ করতে Zabbix ব্যবহার করি। আমরা ডাটাবেসের জন্য Okmeter ব্যবহার করি। আমরা "Grafana" এবং "Prometheus" ব্যবহার করি অন্য সমস্ত সূচকের জন্য যা প্রথম দুটির সাথে খাপ খায় না, কিছু "Grafana" এবং "Prometheus" এর সাথে এবং কিছু "Grafana" এর সাথে "Influx" এবং Telegraf।

  এক বছর আগে আমরা নিউ রিলিক ব্যবহার করতে চেয়েছিলাম। দুর্দান্ত জিনিস, এটি সবকিছু করতে পারে। কিন্তু যতটা সে সব করতে পারে, সে এত দামী। যখন আমরা 1,5 হাজার সার্ভারের ভলিউম হয়ে গেলাম, তখন একজন বিক্রেতা আমাদের কাছে এসে বললেন: "আসুন আগামী বছরের জন্য একটি চুক্তি শেষ করি।" আমরা দামের দিকে তাকিয়ে বললাম না, আমরা তা করব না। এখন আমরা নিউ রিলিক পরিত্যাগ করছি, নিউ রিলিকের পর্যবেক্ষণে আমাদের প্রায় 15টি সার্ভার বাকি আছে। দাম একেবারে বন্য হতে পরিণত.

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

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

  পর্যবেক্ষণের জন্য কোন সূচকগুলি গুরুত্বপূর্ণ?

  আমরা প্রধানত কি নিরীক্ষণ করি? কোন সূচকগুলি আমাদের কাছে গুরুত্বপূর্ণ?

  
  

  • ফ্রন্টে রেসপন্স টাইম/আরপিএস একটি অত্যন্ত গুরুত্বপূর্ণ সূচক। তিনি অবিলম্বে উত্তর দেন যে আপনার সাথে কিছু ভুল হয়েছে।
  • সমস্ত সারিতে প্রক্রিয়াকৃত বার্তার সংখ্যা৷
  • শ্রমিকের সংখ্যা।
  • মৌলিক সঠিকতা মেট্রিক্স।

  শেষ বিন্দু হল "ব্যবসা", "ব্যবসা" মেট্রিক। আপনি যদি একই জিনিস নিরীক্ষণ করতে চান তবে আপনাকে এক বা দুটি মেট্রিক্স সংজ্ঞায়িত করতে হবে যা আপনার জন্য প্রধান সূচক। আমাদের মেট্রিক হল থ্রুপুট (এটি হল মোট লেনদেনের প্রবাহের সফল লেনদেনের সংখ্যার অনুপাত)। যদি 5-10-15 মিনিটের ব্যবধানে এতে কিছু পরিবর্তন হয় তবে এর অর্থ আমাদের সমস্যা রয়েছে (যদি এটি আমূল পরিবর্তন হয়)।

  এটি আমাদের জন্য কেমন দেখাচ্ছে তা হল আমাদের বোর্ডগুলির একটির উদাহরণ:

  
  
  বাম দিকে 6টি গ্রাফ রয়েছে, এটি লাইন অনুসারে - কর্মীদের সংখ্যা এবং সারিতে থাকা বার্তাগুলির সংখ্যা। ডান দিকে - RPS, RTS। নীচে একই "ব্যবসা" মেট্রিক আছে। এবং "ব্যবসা" মেট্রিকে আমরা অবিলম্বে দেখতে পাচ্ছি যে দুটি মাঝারি গ্রাফে কিছু ভুল হয়েছে... এটি কেবল আরেকটি সিস্টেম যা আমাদের পিছনে দাঁড়িয়ে আছে যা পড়ে গেছে।

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

  
  
  গ্রাফটি আমাদের দেখায় যে পেমেন্ট সিস্টেমগুলির মধ্যে একটি 3 সেকেন্ডের মধ্যে প্রতিক্রিয়া জানাতে শুরু করেছে - আমাদের সমস্যা রয়েছে। তদুপরি, 20-30 সেকেন্ডের ব্যবধানে সমস্যা শুরু হলে এই জিনিসটি প্রতিক্রিয়া দেখাবে।

  এবং তৃতীয় শ্রেণির পর্যবেক্ষণ ত্রুটি যা বিদ্যমান তা হল যৌক্তিক পর্যবেক্ষণ।

  সত্যি কথা বলতে, এই স্লাইডে কী আঁকতে হবে তা আমি জানতাম না, কারণ আমরা দীর্ঘদিন ধরে বাজারে এমন কিছু খুঁজছিলাম যা আমাদের জন্য উপযুক্ত। আমরা কিছুই খুঁজে পাইনি, তাই আমাদের নিজেদেরই করতে হয়েছিল।

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

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

  এই সমস্যাটি কীভাবে দ্রুত সনাক্ত করা যায় সে সম্পর্কে ছিল।

  স্থাপনার কারণগুলি কীভাবে নির্ধারণ করবেন

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

  
  
  যদি আমরা লগ সম্পর্কে কথা বলি (মূল কারণ হল লগ), আমাদের লগের বেশিরভাগই ELK স্ট্যাকে থাকে - প্রায় প্রত্যেকেরই একই রকম থাকে। কারও কারও জন্য, এটি ELK-তে নাও হতে পারে, কিন্তু আপনি যদি গিগাবাইটে লগ লেখেন, তাহলে শীঘ্র বা পরে আপনি ELK-তে আসবেন। আমরা তাদের টেরাবাইটে লিখি।

  
  
  এখানে একটি সমস্যা আছে. আমরা এটি ঠিক করেছি, ব্যবহারকারীর জন্য ত্রুটি সংশোধন করেছি, সেখানে যা ছিল তা খনন করতে শুরু করেছি, কিবানায় আরোহণ করেছি, সেখানে লেনদেন আইডি প্রবেশ করেছি এবং এর মতো একটি ফুটক্লথ পেয়েছি (অনেকটি দেখায়)। এবং এই পায়ের কাপড়ে একেবারে কিছুই স্পষ্ট নয়। কেন? হ্যাঁ, কারণ এটি স্পষ্ট নয় যে কোন অংশটি কোন শ্রমিকের, কোন অংশটি কোন উপাদানের। এবং সেই মুহুর্তে আমরা বুঝতে পেরেছিলাম যে আমাদের ট্রেসিং দরকার - সেই একই OpenTracing যা আমি বলেছিলাম।

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

  আমরা "জেগার" এর দিকে তাকিয়েছি: আপনি যন্ত্রের অ্যাপ্লিকেশন করতে পারেন, আপনি এপিআইতে লিখতে পারেন (তখন পিএইচপির জন্য এপিআই স্ট্যান্ডার্ডটি অনুমোদিত হয়নি - এটি এক বছর আগে ছিল, তবে এখন এটি ইতিমধ্যে অনুমোদিত হয়েছে), তবে সেখানে একেবারে কোন ক্লায়েন্ট ছিল. "ঠিক আছে," আমরা ভেবেছিলাম, এবং আমাদের নিজস্ব ক্লায়েন্ট লিখেছিলাম। আমরা কি পেলাম? এটি মোটামুটি এটির মতো দেখাচ্ছে:

  
  
  Jaeger-এ, প্রতিটি বার্তার জন্য স্প্যান তৈরি করা হয়। অর্থাৎ, যখন একজন ব্যবহারকারী সিস্টেমটি খুলেন, তখন তিনি প্রতিটি আগত অনুরোধের জন্য এক বা দুটি ব্লক দেখতে পান (1-2-3 - ব্যবহারকারীর কাছ থেকে আগত অনুরোধের সংখ্যা, ব্লকের সংখ্যা)। ব্যবহারকারীদের জন্য এটি সহজ করার জন্য, আমরা লগ এবং সময় ট্রেস ট্যাগ যোগ. তদনুসারে, একটি ত্রুটির ক্ষেত্রে, আমাদের অ্যাপ্লিকেশনটি যথাযথ ত্রুটি ট্যাগ দিয়ে লগটিকে চিহ্নিত করবে। আপনি ত্রুটি ট্যাগ দ্বারা ফিল্টার করতে পারেন এবং শুধুমাত্র একটি ত্রুটি সহ এই ব্লক ধারণকারী স্প্যানগুলি প্রদর্শিত হবে৷ যদি আমরা স্প্যানটি প্রসারিত করি তবে এটির মতো দেখায়:

  
  
  স্প্যান ভিতরে ট্রেস একটি সেট আছে. এই ক্ষেত্রে, এই তিনটি পরীক্ষার ট্রেস, এবং তৃতীয় ট্রেস আমাদের বলে যে একটি ত্রুটি ঘটেছে৷ একই সময়ে, এখানে আমরা একটি টাইম ট্রেস দেখতে পাই: আমাদের উপরে একটি টাইম স্কেল আছে এবং আমরা দেখি কোন সময়ের ব্যবধানে এই বা সেই লগটি রেকর্ড করা হয়েছে।

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

  
  
  আমাদের কাছে এই এক্সটেনশনটি রয়েছে - এটি ওপেনট্রেসিং এপিআই-এর একটি ক্লায়েন্ট, এটি পিএইচপি-এক্সটেনশন হিসাবে তৈরি করা হয়েছে, অর্থাৎ, আপনাকে এটিকে একত্রিত করতে হবে এবং এটি সিস্টেমে ইনস্টল করতে হবে। এক বছর আগেও আলাদা কিছু ছিল না। এখন অন্যান্য ক্লায়েন্ট আছে যা উপাদানের মত। এখানে এটি আপনার উপর নির্ভর করে: হয় আপনি একজন কম্পোজারের সাহায্যে উপাদানগুলিকে পাম্প করবেন, অথবা আপনি এক্সটেনশন ব্যবহার করবেন।

  কর্পোরেট মান

  আমরা তিনটি আদেশ সম্পর্কে কথা বললাম. চতুর্থ আদেশ হল প্রমিত পদ্ধতি। এই সম্পর্কে কি? এটি এই সম্পর্কে:

  
  
  এখানে "কর্পোরেট" শব্দটি কেন? আমরা একটি বড় বা আমলাতান্ত্রিক কোম্পানি, না! আমি এখানে "কর্পোরেট" শব্দটি এই প্রসঙ্গে ব্যবহার করতে চেয়েছিলাম যে প্রতিটি কোম্পানি, প্রতিটি পণ্যের নিজস্ব মান থাকা উচিত, আপনি সহ। আমরা কি মান আছে?

  
  

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

  ডাউনটাইম কি বিবেচনা করা হয়?

  
  
  এই সব কি নেতৃত্বে?

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

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

  এখানেই শেষ! তোমার প্রশ্নগুলো.

  
  

  ব্যালেন্সার এবং ডাটাবেস মাইগ্রেশন সম্পর্কে

  শ্রোতাদের কাছ থেকে প্রশ্ন (এর পরে – বি): – শুভ সন্ধ্যা। এমন একটি অ্যাডমিন প্রতিবেদনের জন্য আপনাকে অনেক ধন্যবাদ! আপনার ব্যালেন্স সম্পর্কে একটি সংক্ষিপ্ত প্রশ্ন. আপনি উল্লেখ করেছেন যে আপনার একটি WAF আছে, অর্থাৎ, আমি এটি বুঝি, আপনি একধরনের বাহ্যিক ব্যালেন্সার ব্যবহার করেন...

  ইকে: - না, আমরা আমাদের পরিষেবাগুলিকে ব্যালেন্স হিসাবে ব্যবহার করি। এই ক্ষেত্রে, WAF আমাদের জন্য একচেটিয়াভাবে একটি DDoS সুরক্ষা সরঞ্জাম।

  ভিতরে: - আপনি ব্যালেন্সার সম্পর্কে কয়েকটি শব্দ বলতে পারেন?

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

  ভিতরে: - এছাড়াও একটি সহজ প্রশ্ন। এখানে নীল/সবুজ স্থাপনা। আপনি কি করবেন, উদাহরণস্বরূপ, ডাটাবেস মাইগ্রেশনের সাথে?

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

  বন্ধুরা, আপনাদের উৎসাহিত করার জন্য আমার কাছে একটি ছোট পুরস্কারও আছে - একটি বই। এবং সেরা প্রশ্নের জন্য আমাকে পুরস্কৃত করা উচিত।

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

  ইকে: - এই ক্ষেত্রে আমাদের জন্য "মার্চেন্ট" হল পেমেন্ট সিস্টেমের মতোই বাহ্যিক পরিষেবা। আমরা ব্যবসায়ীর প্রতিক্রিয়া গতি নিরীক্ষণ.

  ডাটাবেস এনক্রিপশন সম্পর্কে

  ভিতরে: - হ্যালো. আমার একটি সামান্য সম্পর্কিত প্রশ্ন আছে. আপনার কাছে PCI DSS সংবেদনশীল ডেটা আছে। আমি জানতে চেয়েছিলাম যে আপনি কীভাবে সারিগুলিতে PAN সংরক্ষণ করেন যেগুলিতে আপনাকে স্থানান্তর করতে হবে? আপনি কোন এনক্রিপশন ব্যবহার করেন? এবং এটি দ্বিতীয় প্রশ্নের দিকে নিয়ে যায়: পিসিআই ডিএসএস অনুসারে, পরিবর্তনের ক্ষেত্রে (প্রশাসকদের বরখাস্ত করা ইত্যাদি) ক্ষেত্রে ডেটাবেসটি পর্যায়ক্রমে পুনরায় এনক্রিপ্ট করা প্রয়োজন - এই ক্ষেত্রে অ্যাক্সেসযোগ্যতার কী হবে?

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

  ভিতরে: - আপনার কি এখন 2 কিলোবাইট দরকার?

  ইকে: - মনে হচ্ছে গতকাল 256 ছিল... আচ্ছা, আর কোথায়?!

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

  কখনও কখনও পেমেন্ট ম্যানুয়ালি করতে হয়...

  ভিতরে: – অর্থাৎ, কোনো অপারেশনের জন্য যদি ফেরত আসে, তাহলেও কি আপনি পুরানো কী দিয়ে ডিক্রিপ্ট করবেন?

  ইকে: - হ্যাঁ.

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

  ইকে: - হ্যা মাঝেমাঝে.

  ভিতরে: - আপনি এই তথ্য কোথা থেকে পাবেন? নাকি আপনি নিজেই এই স্টোরেজ ফ্যাসিলিটিতে যান?

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

  
  
  ভিতরে: - আমার কিছু প্রশ্ন আছে. তাদের মধ্যে একটি হল পিসিআই ডিএসএস জোনের ধারাবাহিকতা: আপনি কীভাবে তাদের সার্কিট লগ করবেন? এই প্রশ্নটি কারণ বিকাশকারী লগগুলিতে কিছু রাখতে পারতেন! দ্বিতীয় প্রশ্ন: আপনি কিভাবে হটফিক্স রোল আউট করবেন? ডাটাবেসে হ্যান্ডলগুলি ব্যবহার করা একটি বিকল্প, তবে বিনামূল্যে হট-ফিক্স থাকতে পারে - সেখানে পদ্ধতিটি কী? এবং তৃতীয় প্রশ্নটি সম্ভবত RTO, RPO সম্পর্কিত। আপনার প্রাপ্যতা ছিল 99,97, প্রায় চার নাইন, কিন্তু আমি এটি বুঝতে পেরেছি, আপনার কাছে একটি দ্বিতীয় ডেটা সেন্টার, একটি তৃতীয় ডেটা সেন্টার এবং একটি পঞ্চম ডেটা সেন্টার রয়েছে... আপনি কীভাবে তাদের সিঙ্ক্রোনাইজ করবেন, তাদের প্রতিলিপি করবেন এবং অন্য সবকিছু?

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

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

  ভিতরে: - আপনি যদি দ্বিতীয়টি পান তবে আপনি তৃতীয়টি পাননি কেন? কারণ এখনো কারোর মস্তিষ্ক বিভক্ত হয়নি...

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

  ভিতরে: - শুভ সন্ধ্যা. প্রতিবেদনের জন্য ধন্যবাদ. আপনি আপনার ডিবাগার সম্পর্কে কথা বলেছেন, যা উত্পাদনে কিছু পরীক্ষামূলক লেনদেন চালায়। কিন্তু টেস্ট লেনদেন সম্পর্কে বলুন! এটা কত গভীরে যায়?

  ইকে: - এটি সম্পূর্ণ উপাদানের সম্পূর্ণ চক্রের মধ্য দিয়ে যায়। একটি উপাদানের জন্য, একটি পরীক্ষা লেনদেন এবং একটি উত্পাদন লেনদেনের মধ্যে কোন পার্থক্য নেই। কিন্তু একটি যৌক্তিক দৃষ্টিকোণ থেকে, এটি কেবল সিস্টেমে একটি পৃথক প্রকল্প, যার উপর শুধুমাত্র পরীক্ষামূলক লেনদেন চালানো হয়।

  ভিতরে: -কোথায় কেটে দিলে? এখানে কোর পাঠানো হয়েছে...

  ইকে: – আমরা পরীক্ষামূলক লেনদেনের ক্ষেত্রে এই ক্ষেত্রে "Kor" এর পিছনে আছি... আমাদের কাছে রাউটিং এর মতো একটি জিনিস রয়েছে: "Kor" জানে এটি কোন পেমেন্ট সিস্টেমে পাঠানো উচিত - আমরা এটি একটি জাল পেমেন্ট সিস্টেমে পাঠাই, যা কেবল একটি দেয় http সংকেত এবং যে সব.

  ভিতরে: - আমাকে বলুন, অনুগ্রহ করে, আপনার আবেদনটি কি একটি বিশাল মনোলিথে লেখা ছিল, নাকি আপনি এটিকে কিছু পরিষেবা বা এমনকি মাইক্রোসার্ভিসেও কেটেছিলেন?

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

  যদি সার্ভারে পরিষেবাটি আপস করা হয় ...

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

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

  ভিতরে: - এবং এই প্রেক্ষাপটে, আমার কাছে আরও মজার বিষয় হল যে পরিষেবাগুলির সাথে আপনার কিছু নির্দিষ্ট চুক্তি রয়েছে - তারা কী করতে পারে, কোন "ক্রিয়াগুলির" মাধ্যমে তারা একে অপরের সাথে যোগাযোগ করতে পারে... এবং একটি স্বাভাবিক প্রবাহে, কিছু নির্দিষ্ট পরিষেবা কিছু অনুরোধ করে সারি, অন্য দিকে "ক্রিয়াগুলির" একটি তালিকা। তারা স্বাভাবিক পরিস্থিতিতে অন্যদের দিকে ফিরে যায় বলে মনে হয় না এবং তাদের দায়িত্বের অন্যান্য ক্ষেত্র রয়েছে। যদি তাদের মধ্যে একটি আপস করা হয়, তাহলে এটি কি সেই পরিষেবার "ক্রিয়াগুলি" ব্যাহত করতে সক্ষম হবে? ..

  ইকে: - আমি বুঝেছি. যদি একটি স্বাভাবিক পরিস্থিতিতে অন্য সার্ভারের সাথে যোগাযোগের অনুমতি দেওয়া হয় তবে হ্যাঁ। এসএলএ চুক্তি অনুসারে, আমরা নিরীক্ষণ করি না যে আপনাকে শুধুমাত্র প্রথম 3টি "ক্রিয়া" করার অনুমতি দেওয়া হয়েছে এবং আপনাকে 4টি "ক্রিয়া" করার অনুমতি দেওয়া হচ্ছে না। এটি সম্ভবত আমাদের জন্য অপ্রয়োজনীয়, কারণ আমাদের ইতিমধ্যেই একটি 4-স্তরের সুরক্ষা ব্যবস্থা রয়েছে, নীতিগতভাবে, সার্কিটের জন্য। আমরা ভিতরের স্তরের চেয়ে কনট্যুর দিয়ে আত্মরক্ষা করতে পছন্দ করি।

  কিভাবে Visa, MasterCard এবং Sberbank কাজ করে

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

  ইকে: - এই মিশ্রণ আগে. আমাদের মিশ্রণগুলি একই ডেটা সেন্টারে অবস্থিত।

  ভিতরে: - মোটামুটিভাবে বলতে গেলে, আপনার কি একটি সংযোগ বিন্দু আছে?

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

  ভিতরে: - তারা কিভাবে সংরক্ষিত হতে পারে? আমি জানি যে ভিসা নীতিগতভাবে শুধুমাত্র একটি সংযোগের অনুমতি দেয়!

  ইকে: - তারা নিজেরাই সরঞ্জাম সরবরাহ করে। যাই হোক না কেন, আমরা এমন সরঞ্জাম পেয়েছি যা ভিতরে সম্পূর্ণরূপে অপ্রয়োজনীয়।

  ভিতরে: - তাহলে স্ট্যান্ডটি তাদের কানেক্টস অরেঞ্জ থেকে?

  ইকে: - হ্যাঁ.

  ভিতরে: - কিন্তু এই ক্ষেত্রে কী হবে: যদি আপনার ডেটা সেন্টার অদৃশ্য হয়ে যায়, আপনি কীভাবে এটি ব্যবহার চালিয়ে যেতে পারেন? নাকি যান চলাচল বন্ধ হয়ে যায়?

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

  আমি Sberbank কর্মচারীদের অসন্তুষ্ট করলে আমি আন্তরিকভাবে ক্ষমাপ্রার্থী। কিন্তু আমাদের পরিসংখ্যান অনুযায়ী, রাশিয়ান ব্যাংকগুলির মধ্যে, Sberbank প্রায়শই পড়ে। Sberbank-এ কিছু না পড়ে এক মাসও যায় না।

  
  
  

  কিছু বিজ্ঞাপন 🙂

  আমাদের সাথে থাকার জন্য আপনাকে ধন্যবাদ. আপনি আমাদের নিবন্ধ পছন্দ করেন? আরো আকর্ষণীয় বিষয়বস্তু দেখতে চান? অর্ডার দিয়ে বা বন্ধুদের সুপারিশ করে আমাদের সমর্থন করুন, $4.99 থেকে বিকাশকারীদের জন্য ক্লাউড ভিপিএস, এন্ট্রি-লেভেল সার্ভারগুলির একটি অনন্য অ্যানালগ, যা আমাদের দ্বারা আপনার জন্য উদ্ভাবিত হয়েছে: VPS (KVM) E5-2697 v3 (6 কোর) 10GB DDR4 480GB SSD 1Gbps থেকে $19 বা কিভাবে একটি সার্ভার শেয়ার করবেন সম্পর্কে সম্পূর্ণ সত্য? (RAID1 এবং RAID10 এর সাথে উপলব্ধ, 24 কোর পর্যন্ত এবং 40GB DDR4 পর্যন্ত)।

  আমস্টারডামের ইকুইনিক্স টায়ার IV ডেটা সেন্টারে ডেল R730xd 2x সস্তা? শুধু এখানে 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 টিভি $199 থেকে নেদারল্যান্ডে! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 থেকে! সম্পর্কে পড়ুন কিভাবে ইনফ্রাস্ট্রাকচার কর্পোরেশন তৈরি করা যায়। এক পয়সার জন্য 730 ইউরো মূল্যের Dell R5xd E2650-4 v9000 সার্ভার ব্যবহার করে ক্লাস?

উত্স: www.habr.com