একটি রোলআউট গল্প যা সবকিছুকে প্রভাবিত করেছে

বাস্তবতার শত্রু 12f-2 দ্বারা

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

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

পটভূমি + এটি কি ধরনের কার্যকারিতা?

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

সাধারণত এই জাতীয় জিনিসগুলি যে কোনও প্রকল্পের একেবারে শুরুতে নির্মিত হতে শুরু করে। কিন্তু ঐতিহাসিকভাবে MCS-এ ব্যাপারগুলো একটু ভিন্ন। MCS দুটি অংশে নির্মিত হয়েছিল:

• নিজস্ব কীস্টোন অনুমোদন মডিউল সহ ওপেনস্ট্যাক,
• Hotbox (S3 স্টোরেজ) Mail.ru ক্লাউড প্রকল্পের উপর ভিত্তি করে,

যার চারপাশে তখন নতুন পরিষেবা উপস্থিত হয়েছিল।

মূলত, এই দুটি ভিন্ন ধরনের অনুমোদন ছিল। এছাড়াও, আমরা কিছু পৃথক Mail.ru ডেভেলপমেন্ট ব্যবহার করেছি, উদাহরণস্বরূপ, একটি সাধারণ Mail.ru পাসওয়ার্ড স্টোরেজ, সেইসাথে একটি স্ব-লিখিত openid সংযোগকারী, যার জন্য SSO (এন্ড-টু-এন্ড অনুমোদন) Horizon প্যানেলে প্রদান করা হয়েছে। ভার্চুয়াল মেশিনের (নেটিভ OpenStack UI)।

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

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

আমরা কি রোল আউট যাচ্ছে?

খুব মোটামুটিভাবে বলতে গেলে, প্রায় 4 মাসের মধ্যে আমরা নিম্নলিখিতগুলি প্রস্তুত করেছি:

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

এই ধরনের একটি বড় পুনঃকর্মের জন্য বিভিন্ন উন্নয়ন দলের দ্বারা লিখিত বিভিন্ন সিস্টেমে বড়, জটিল এবং সবচেয়ে গুরুত্বপূর্ণভাবে সিঙ্ক্রোনাস পরিবর্তন প্রয়োজন। একবার একত্রিত হলে, পুরো সিস্টেমটি কাজ করা উচিত।

কিভাবে এই ধরনের পরিবর্তন রোল আউট এবং এটি স্ক্রু আপ না? প্রথমে আমরা ভবিষ্যতের দিকে একটু নজর দেওয়ার সিদ্ধান্ত নিয়েছি।

রোলআউট কৌশল

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

ডিগ্রেশন: একটি রোলআউট কি?

<সাবধানতা, দর্শন>

প্রতিটি আইটি বিশেষজ্ঞ সহজেই উত্তর দিতে পারেন রোলআউট কী। আপনি CI/CD ইনস্টল করেন এবং সবকিছু স্বয়ংক্রিয়ভাবে দোকানে পৌঁছে দেওয়া হয়। 🙂

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

আর পুরো ছবিটাই এরকম। রোলআউট চারটি প্রধান দিক নিয়ে গঠিত:

1. কোড ডেলিভারি, ডেটা পরিবর্তন সহ। উদাহরণস্বরূপ, তাদের অভিবাসন।
2. কোড রোলব্যাক হল কিছু ভুল হলে ফিরে যাওয়ার ক্ষমতা। উদাহরণস্বরূপ, ব্যাকআপ তৈরির মাধ্যমে।
3. প্রতিটি রোলআউট/রোলব্যাক অপারেশনের সময়। আপনাকে প্রথম দুটি পয়েন্টের যেকোনো অপারেশনের সময় বুঝতে হবে।
4. প্রভাবিত কার্যকারিতা. প্রত্যাশিত ইতিবাচক এবং সম্ভাব্য নেতিবাচক প্রভাব উভয়ই মূল্যায়ন করা প্রয়োজন।

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

আইন 1..এন, মুক্তির প্রস্তুতি

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

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

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

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

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

এবং তাই…

চূড়ান্ত কাজ, রোলিং আউট আগে

...এটি রোল আউট করার সময়.

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

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

1. প্রভাবিত (আমাদের কাছে পবিত্র, সবচেয়ে মূল্যবান) ব্যবহারকারী পরিকাঠামো,
2. কার্যকারিতা: রোলআউটের পরে আমাদের পরিষেবার ব্যবহার আগের মতোই হওয়া উচিত।

বরাদ্দ

দুই রোল, 8 হস্তক্ষেপ করবেন না

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

• রোলআউট নিজেই প্রায় 3 ঘন্টা সময় নেয়।
• পরীক্ষার জন্য 2 ঘন্টা।
• 2 ঘন্টা - পরিবর্তনের সম্ভাব্য রোলব্যাকের জন্য রিজার্ভ।

প্রতিটি ক্রিয়াকলাপের জন্য একটি গ্যান্ট চার্ট তৈরি করা হয়েছে, এটি কতক্ষণ সময় নেয়, ক্রমানুসারে কী ঘটে, সমান্তরালভাবে কী করা হয়।

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

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

ঘটনার ক্রনিকল

তাই, 15 এপ্রিল রবিবার রাত 29 টায় 10 জন কাজে আসেন। মূল অংশগ্রহণকারীদের ছাড়াও, কেউ কেউ দলকে সমর্থন করতে এসেছেন, যার জন্য তাদের বিশেষ ধন্যবাদ।

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

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

প্রত্যেকেরই একটি মুদ্রিত রোলআউট প্ল্যান পয়েন্ট বাই পয়েন্ট আছে, সবাই জানে কে কি করছে এবং কোন মুহূর্তে। প্রতিটি কর্মের পরে, আমরা সময়গুলি পরীক্ষা করি যাতে আমরা সেগুলি অতিক্রম না করি এবং সবকিছু পরিকল্পনা অনুযায়ী চলে। যারা বর্তমান পর্যায়ে সরাসরি রোলআউটে অংশগ্রহণ করছেন না তারা তাদের সহকর্মীদের বিরক্ত না করার জন্য একটি অনলাইন খেলনা (Xonotic, টাইপ 3 quacks) চালু করে প্রস্তুতি নিচ্ছেন। 🙂

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

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

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

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

03:00 -2 সমস্যা +2 সমস্যা
আগের দুটি বড় সমস্যা ঠিক করা হয়েছে, এবং প্রায় সব ছোটখাটো সমস্যাও। যারা ফিক্সে অব্যক্ত তারা তাদের অ্যাকাউন্টে সক্রিয়ভাবে কাজ করছে এবং তারা যা পায় তা রিপোর্ট করছে। আমরা অগ্রাধিকার দিই, দলের মধ্যে বিতরণ করি এবং সকালের জন্য অ-গুরুত্বপূর্ণ আইটেমগুলি রেখে দেই।

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

03:20 জরুরী সিঙ্ক
একটি নতুন সমস্যা সংশোধন করা হয়েছে. দ্বিতীয় জন্য, আমরা একটি জরুরি সিঙ্ক সংগঠিত করছি। আমরা বুঝতে পারি কি ঘটছে: পূর্ববর্তী ফিক্স একটি সমস্যা সংশোধন করেছে, কিন্তু আরেকটি তৈরি করেছে। সঠিকভাবে এবং ফলাফল ছাড়াই কীভাবে এটি করা যায় তা নির্ধারণ করার জন্য আমরা একটি বিরতি নিই।

03:30 ছয়টি চোখ
আমরা বুঝতে পারি যে বেসের চূড়ান্ত অবস্থা কী হওয়া উচিত যাতে সমস্ত অংশীদারদের জন্য সবকিছু ঠিকঠাক হয়। আমরা 6 চোখ দিয়ে একটি অনুরোধ লিখি, এটিকে প্রাক-প্রোডাকশনে রোল আউট করি, এটি পরীক্ষা করি, উত্পাদনের জন্য এটি রোল আউট করি।

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

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

06:00 UI এ সকলের জন্য উন্মুক্ত
বাগ সংশোধন করা হয়েছে. কিছু যেগুলি ব্যবহারকারীদের কাছে আপীল করে না তা পরে জন্য রেখে দেওয়া হয়। আমরা সবার জন্য ইন্টারফেস খুলি। আমরা বিলিং নিয়ে কাজ চালিয়ে যাচ্ছি, ব্যবহারকারীর প্রতিক্রিয়া এবং পর্যবেক্ষণের ফলাফলের জন্য অপেক্ষা করছি।

07:00 API লোড নিয়ে সমস্যা
এটা স্পষ্ট হয়ে যায় যে আমরা আমাদের API-তে লোডের সামান্য ভুল পরিকল্পনা করেছি এবং এই লোডটি পরীক্ষা করেছি, যা সমস্যাটি সনাক্ত করতে পারেনি। ফলস্বরূপ, ≈5% অনুরোধ ব্যর্থ হয়। আসুন একত্রিত হই এবং কারণটি সন্ধান করি।

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

08:00 এপিআই ফিক্স করুন
আমরা লোডের জন্য একটি সংশোধন করেছি, ব্যর্থতাগুলি চলে গেছে। আমরা বাড়িতে যেতে শুরু করি।

10:00 সব
সবকিছু ঠিক করা আছে। এটি নিরীক্ষণে শান্ত এবং গ্রাহকদের জায়গায়, দলটি ধীরে ধীরে ঘুমাতে যায়। বিলিং বাকি আছে, আমরা আগামীকাল এটি পুনরুদ্ধার করব।

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

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

মোটে

রোলআউটের জন্য 2 মাসের সক্রিয় প্রস্তুতির সময়, 43টি কাজ সম্পন্ন হয়েছিল, যা কয়েক ঘন্টা থেকে কয়েক দিন স্থায়ী হয়েছিল।

রোলআউটের সময়:

• নতুন এবং পরিবর্তিত দানব - 5 টুকরা, 2 টি মনোলিথ প্রতিস্থাপন;
• ডাটাবেসের মধ্যে পরিবর্তনগুলি - ব্যবহারকারীর ডেটা সহ আমাদের 6টি ডেটাবেস প্রভাবিত হয়েছে, তিনটি পুরানো ডেটাবেস থেকে একটি নতুন ডেটাবেস ডাউনলোড সম্পূর্ণ হয়েছে;
• সম্পূর্ণরূপে পুনরায় ডিজাইন ফ্রন্টএন্ড;
• ডাউনলোড করা কোডের পরিমাণ - নতুন কোডের 33 হাজার লাইন, ≈ পরীক্ষায় কোডের 3 হাজার লাইন, ≈ মাইগ্রেশন কোডের 5 হাজার লাইন;
• সমস্ত ডেটা অক্ষত, একটি একক গ্রাহকের ভার্চুয়াল মেশিন ক্ষতিগ্রস্ত হয়নি। 🙂

ভালো রোলআউটের জন্য ভালো অনুশীলন

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

1. রোলআউট কীভাবে ব্যবহারকারীদের প্রভাবিত করতে পারে বা করতে পারে তা আপনাকে প্রথমেই বুঝতে হবে। ডাউনটাইম হবে? যদি তাই হয়, ডাউনটাইম কি? এটি কিভাবে ব্যবহারকারীদের প্রভাবিত করবে? সম্ভাব্য সেরা এবং সবচেয়ে খারাপ পরিস্থিতি কি? এবং ঝুঁকি কভার করুন।
2. সবকিছু পরিকল্পনা করুন। প্রতিটি পর্যায়ে, আপনাকে রোলআউটের সমস্ত দিক বুঝতে হবে:
   • কোড বিতরণ;
   • কোড রোলব্যাক;
   • প্রতিটি অপারেশন সময়;
   • প্রভাবিত কার্যকারিতা।
3. রোলআউটের সমস্ত ধাপের পাশাপাশি তাদের প্রতিটিতে ঝুঁকিগুলি স্পষ্ট না হওয়া পর্যন্ত পরিস্থিতিগুলির মধ্য দিয়ে খেলুন। যদি আপনার কোন সন্দেহ থাকে, আপনি বিরতি নিতে পারেন এবং প্রশ্নবিদ্ধ পর্যায়টি আলাদাভাবে পরীক্ষা করতে পারেন।
4. প্রতিটি পর্যায় উন্নত করা যেতে পারে এবং করা উচিত যদি এটি আমাদের ব্যবহারকারীদের সাহায্য করে। উদাহরণস্বরূপ, এটি ডাউনটাইম কমাবে বা কিছু ঝুঁকি দূর করবে।
5. কোড ডেলিভারি পরীক্ষার চেয়ে রোলব্যাক টেস্টিং অনেক বেশি গুরুত্বপূর্ণ। এটি পরীক্ষা করা প্রয়োজন যে রোলব্যাকের ফলে সিস্টেমটি তার আসল অবস্থায় ফিরে আসবে এবং পরীক্ষার মাধ্যমে এটি নিশ্চিত করুন।
6. স্বয়ংক্রিয় হতে পারে এমন সবকিছুই স্বয়ংক্রিয় হওয়া উচিত। স্বয়ংক্রিয় হতে পারে না এমন সবকিছু একটি চিট শীটে আগাম লেখা উচিত।
7. সাফল্যের মানদণ্ড রেকর্ড করুন। কি কার্যকারিতা পাওয়া উচিত এবং কোন সময়ে? যদি এটি না ঘটে তবে একটি রোলব্যাক পরিকল্পনা চালান।
8. এবং সবচেয়ে গুরুত্বপূর্ণ - মানুষ। প্রত্যেকেরই সচেতন হওয়া উচিত যে তারা কী করছে, কেন এবং কী রোলআউট প্রক্রিয়াতে তাদের কর্মের উপর নির্ভর করে।

এবং এক বাক্যে, ভাল পরিকল্পনা এবং বিস্তারিতভাবে আপনি বিক্রয়ের ফলাফল ছাড়াই আপনি যা চান তা রোল আউট করতে পারেন। এমনকি এমন কিছু যা উত্পাদনে আপনার সমস্ত পরিষেবাকে প্রভাবিত করবে।

উত্স: www.habr.com