রাশিয়া 2020-এ DevOps রাজ্য

আপনি এমনকি কিছু অবস্থা কিভাবে বুঝতে?

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

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

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

DevOps গবেষণা

ইগর কুরোচকিন কথোপকথন শুরু করলেন।

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

এখানে আমাদের প্রথম সমস্যা রয়েছে, তারপরে আরও দুটি সমস্যা রয়েছে:

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

বিশ্বে DevOps-এর অবস্থার বিশ্লেষণ সাধারণত কীভাবে করা হয়েছিল তা দেখা যাক।

ঐতিহাসিক পটভূমি

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

2013 সালে, IT বিপ্লব হাজির, DevOps-এ সমস্ত প্রধান বইয়ের প্রকাশক। Puppet এর সাথে একসাথে, তারা প্রথম প্রকাশনা "State of DevOps" প্রস্তুত করেছে, যেখানে 4টি মূল মেট্রিক্স প্রথমবারের মতো উপস্থিত হয়েছে। পরের বছর, পরামর্শকারী সংস্থা থটওয়ার্কস, যা শিল্প অনুশীলন এবং সরঞ্জামগুলির নিয়মিত প্রযুক্তি রাডারগুলির জন্য পরিচিত, জড়িত হয়েছিল। এবং 2015 সালে, পদ্ধতির সাথে একটি বিভাগ যুক্ত করা হয়েছিল, এবং তারা কীভাবে বিশ্লেষণ করে তা স্পষ্ট হয়ে ওঠে।

2016 সালে, গবেষণার লেখকরা, তাদের কোম্পানি DORA (DevOps গবেষণা এবং মূল্যায়ন) তৈরি করে, একটি বার্ষিক প্রতিবেদন প্রকাশ করেছেন। পরের বছর, DORA এবং Puppet তাদের চূড়ান্ত যৌথ প্রতিবেদন জারি করে।

এবং তারপর জিনিস আকর্ষণীয় হয়ে ওঠে:

2018 সালে, কোম্পানিগুলি বিভক্ত হয়েছিল এবং দুটি স্বাধীন রিপোর্ট প্রকাশিত হয়েছিল: একটি পুপেট থেকে, দ্বিতীয়টি DORA থেকে Google-এর সহযোগিতায়৷ DORA মূল মেট্রিক্স, পারফরম্যান্স প্রোফাইল এবং ইঞ্জিনিয়ারিং অনুশীলনের সাথে তার পদ্ধতি ব্যবহার করতে থাকে যা কোম্পানি জুড়ে মূল মেট্রিক এবং কর্মক্ষমতা প্রভাবিত করে। এবং পুতুল প্রক্রিয়ার বর্ণনা এবং DevOps এর বিবর্তনের সাথে তার পদ্ধতির প্রস্তাব করেছে। কিন্তু গল্পটি ধরা পড়েনি; 2019 সালে, পাপেট এই পদ্ধতিটি ত্যাগ করে এবং প্রতিবেদনের একটি নতুন সংস্করণ প্রকাশ করে, যেখানে এটি মূল অনুশীলনগুলি এবং কীভাবে তারা তাদের দৃষ্টিকোণ থেকে DevOps কে প্রভাবিত করে তা তালিকাভুক্ত করেছে। তারপরে আরেকটি ঘটনা ঘটেছে: গুগল DORA কিনেছে এবং তারা একসাথে আরেকটি প্রতিবেদন প্রকাশ করেছে। সম্ভবত আপনি এটা দেখেছেন.

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

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

রাশিয়ার জিনিসগুলি কেমন?

আমরা DevOps নিয়ে কোনো গবেষণা করিনি। আমরা কনফারেন্সে বক্তৃতা করেছি, অন্য লোকেদের উপসংহারগুলি পুনরায় বলেছি এবং Raiffeisenbank 2019-এর জন্য "State of DevOps" অনুবাদ করেছে (আপনি Habré-এ তাদের ঘোষণা খুঁজে পেতে পারেন), তাদের অনেক ধন্যবাদ। এবং এটা সব.

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

গবেষণা প্রক্রিয়া

রিপোর্ট শুধুমাত্র চূড়ান্ত অংশ. সমগ্র গবেষণা প্রক্রিয়া চারটি বড় পর্যায় নিয়ে গঠিত:

প্রস্তুতির পর্যায়ে, আমরা শিল্প বিশেষজ্ঞদের সাক্ষাৎকার নিয়েছি এবং অনুমানের একটি তালিকা প্রস্তুত করেছি। তাদের উপর ভিত্তি করে, আমরা প্রশ্ন সংকলন করেছি এবং পুরো আগস্ট মাসের জন্য একটি সমীক্ষা শুরু করেছি। তারপর আমরা নিজেই বিশ্লেষণ করে প্রতিবেদন তৈরি করেছি। DORA এর জন্য, এই প্রক্রিয়াটি 6 মাস সময় নেয়। আমরা এটি 3 মাসে সম্পন্ন করেছি, এবং এখন আমরা বুঝি যে আমাদের কাছে সবেমাত্র পর্যাপ্ত সময় ছিল: শুধুমাত্র বিশ্লেষণ করে আপনি বুঝতে পারেন কোন প্রশ্নগুলি জিজ্ঞাসা করা দরকার।

অংশগ্রহণকারীদের

সমস্ত বিদেশী প্রতিবেদন অংশগ্রহণকারীদের একটি প্রতিকৃতি দিয়ে শুরু হয় এবং তাদের বেশিরভাগই রাশিয়ার নয়। রাশিয়ান উত্তরদাতাদের শতাংশ প্রতি বছর 5 থেকে 1% থেকে ওঠানামা করে এবং এটি আমাদের কোন সিদ্ধান্তে পৌঁছাতে দেয় না।

এক্সিলারেট স্টেট অফ DevOps 2019 রিপোর্ট থেকে মানচিত্র:

আমাদের গবেষণায়, আমরা 889 জনের সাক্ষাত্কার নিতে সক্ষম হয়েছি - এটি অনেক বেশি (ডোরা তার প্রতিবেদনে বার্ষিক এক হাজার লোকের সমীক্ষা করে) এবং এখানে আমরা আমাদের লক্ষ্য অর্জন করেছি:

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

শিল্প এবং অবস্থান

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

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

এইভাবে আমরা বিভিন্ন শিল্প, কোম্পানি এবং দলের প্রতিনিধিদের তুলনা এবং বিশ্লেষণের জন্য তথ্য সংগ্রহ করেছি। আমার সহকর্মী Vitaly Khabarov বিশ্লেষণ সম্পর্কে আপনাকে বলতে হবে.

বিশ্লেষণ এবং তুলনা

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

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

মূল ম্যাট্রিক্স

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

মূল ম্যাট্রিক্স:

1. স্থাপনার ফ্রিকোয়েন্সি। কত ঘন ঘন একটি অ্যাপ্লিকেশনের একটি নতুন সংস্করণ উত্পাদন পরিবেশে স্থাপন করা হয় (পরিকল্পিত পরিবর্তন, হটফিক্স এবং ঘটনার প্রতিক্রিয়া ব্যতীত)?
2. ডেলিভারি সময়। একটি পরিবর্তন (কোড হিসাবে কার্যকারিতা লেখা) এবং উত্পাদন পরিবেশে পরিবর্তন স্থাপনের মধ্যে গড় সময় কত?
3. পুনরুদ্ধারের সময়. একটি ঘটনা, পরিষেবার অবনতি বা অ্যাপ্লিকেশন ব্যবহারকারীদের প্রভাবিত করে এমন একটি ত্রুটি সনাক্ত করার পরে একটি উত্পাদন পরিবেশে একটি অ্যাপ্লিকেশন পুনরুদ্ধার করতে গড়ে কতক্ষণ সময় লাগে?
4. ব্যর্থ পরিবর্তন. একটি পণ্য পরিবেশে কত শতাংশ স্থাপনা অ্যাপ্লিকেশনের অবনতি বা ঘটনা ঘটায় এবং পরিণতিগুলিকে বাদ দিতে হয় (পরিবর্তনগুলি ফিরিয়ে আনা, একটি হটফিক্স বা প্যাচ তৈরি করা)?

DORA এর গবেষণা এই মেট্রিক্স এবং সাংগঠনিক কর্মক্ষমতা মধ্যে একটি সংযোগ খুঁজে পেয়েছে. আমরা আমাদের গবেষণায় এটি পরীক্ষাও করি।

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

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

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

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

গ্রামে ঝুলতে কত?

আমরা শ্রেণিবদ্ধ ক্লাস্টার বিশ্লেষণ ব্যবহার করেছি:

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

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

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

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

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

তারপর প্রশ্ন ওঠে: কিভাবে এই সব ব্যবহার করতে?

কিভাবে ব্যবহার করবেন

যদি আমরা যেকোন দল, 4টি মূল মেট্রিক্স গ্রহণ করি এবং এটি টেবিলে প্রয়োগ করি, তাহলে 85% ক্ষেত্রে আমরা একটি সম্পূর্ণ ম্যাচ পাব না - এটি শুধুমাত্র গড় অংশগ্রহণকারী, এবং বাস্তবে যা নয়। আমরা সবাই (এবং প্রতিটি দল) একটু আলাদা।

আমরা পরীক্ষা করেছি: আমরা আমাদের উত্তরদাতা এবং DORA পারফরম্যান্স প্রোফাইল নিয়েছি, এবং কতজন উত্তরদাতা এক বা অন্য প্রোফাইলের সাথে সঙ্গতিপূর্ণ তা দেখেছি। আমরা দেখেছি যে শুধুমাত্র 16% উত্তরদাতা সঠিকভাবে প্রোফাইলগুলির মধ্যে একটিতে পড়েছেন৷ বাকি সবগুলো মাঝে মাঝে ছড়িয়ে ছিটিয়ে আছে:

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

• DORA ক্যালকুলেটর
• ক্যালকুলেটর এক্সপ্রেস 42* (বিকাশ চলছে)
• আপনার নিজস্ব বিকাশ (আপনি নিজের অভ্যন্তরীণ ক্যালকুলেটর তৈরি করতে পারেন)।

তারা কি জন্য প্রয়োজন? বুঝতে:

• আমাদের প্রতিষ্ঠানের দল কি আমাদের মান পূরণ করে?
• যদি না হয়, আমরা কি তাকে সাহায্য করতে পারি - আমাদের কোম্পানির দক্ষতার কাঠামোর মধ্যে এটিকে গতিশীল করতে পারি?
• যদি তাই হয়, আমরা কি আরও ভাল করতে পারি?

আপনি কোম্পানির মধ্যে পরিসংখ্যান সংগ্রহ করতে তাদের ব্যবহার করতে পারেন:

• আমরা কি ধরনের দল আছে?
• দলগুলিকে প্রোফাইলে ভাগ করুন;
• দেখুন: ওহ, এই দলগুলি কম পারফর্ম করছে (একটু ধীর), কিন্তু এগুলি দুর্দান্ত: তারা প্রতিদিন স্থাপন করে, ত্রুটি ছাড়াই, তাদের লিড টাইম এক ঘন্টারও কম।

এবং তারপরে আপনি জানতে পারেন যে আমাদের কোম্পানির মধ্যে আমাদের কাছে সেই দলগুলির জন্য প্রয়োজনীয় দক্ষতা এবং সরঞ্জাম রয়েছে যেগুলি এখনও কম পড়ছে৷

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

ফাইন। এবং আপনি যদি DORA ক্যালকুলেটর অনুসারে এলিট গ্রুপে থাকেন তবে আপনার কী করা উচিত? এখানে কোন ভালো সমাধান নেই। সম্ভবত, আপনি শিল্পের অগ্রভাগে আছেন এবং অভ্যন্তরীণ R&D এবং বৃহৎ সংস্থান ব্যয়ের মাধ্যমে আরও ত্বরণ এবং নির্ভরযোগ্যতার উন্নতি সম্ভব।

আসুন মধুরতম অংশে যাওয়া যাক - তুলনা।

তুলনা

আমরা প্রথমে পশ্চিমা শিল্পের সাথে রাশিয়ান শিল্পের তুলনা করতে চেয়েছিলাম। যদি আমরা সরাসরি তুলনা করি, আমরা দেখতে পাই যে আমাদের প্রোফাইল কম আছে, এবং তারা একে অপরের সাথে একটু বেশি মিশে গেছে, সীমানা একটু বেশি ঝাপসা:

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

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

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

• নতুন পণ্যগুলি প্রায় 1,5-2 গুণ বেশি প্রকাশ করা হয়েছিল,
• বর্ধিত নির্ভরযোগ্যতা এবং/অথবা অ্যাপ্লিকেশন পরিকাঠামোর কর্মক্ষমতা 2 গুণ বেশি প্রায়ই।

অর্থাৎ, যে দক্ষতাগুলি তারা ইতিমধ্যে তাদের দ্রুত বিকাশ করতে সাহায্য করেছে, নতুন পণ্য প্রবর্তন করেছে, বিদ্যমান পণ্যগুলিকে সংশোধন করেছে, এর ফলে নতুন বাজার এবং নতুন ব্যবহারকারীদের জয় করেছে:

আর কী আমাদের দলকে সাহায্য করেছে?

ইঞ্জিনিয়ারিং অনুশীলন

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

একটি পরিষেবা হিসাবে প্ল্যাটফর্ম

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

কোড হিসাবে পরিকাঠামো

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

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

ইন্টিগ্রেশন এবং ডেলিভারি

সবচেয়ে বিরক্তিকর বিভাগ, কারণ আমরা নিশ্চিত করেছি: আপনার যত বেশি অটোমেশন থাকবে, আপনি কোডের সাথে যত ভালো কাজ করবেন, তত বেশি ভালো ফলাফল পাওয়ার সম্ভাবনা থাকবে।

স্থাপত্য

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

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

কিভাবে আমরা এই সব আবিষ্কার?

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

আমরা প্রতিটি প্রোফাইলের দলগুলির মধ্যে প্রকৌশল অনুশীলনের বন্টন দেখেছি এবং দেখেছি যে হাই প্রোফাইলের দলগুলি, গড়ে, প্রকৌশল অনুশীলনগুলি প্রায়শই ব্যবহার করে৷ আপনি আমাদের এই সব সম্পর্কে আরও পড়তে পারেন রিপোর্ট.

একটি পরিবর্তনের জন্য, আসুন জটিল পরিসংখ্যান থেকে সাধারণ পরিসংখ্যানে স্যুইচ করি।

আমরা আর কি আবিষ্কার করেছি?

যন্ত্র

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

অর্কেস্ট্রেটরদের মধ্যে, এটি কোন গোপন বিষয় নয় যে কুবারনেটস নেতৃত্ব দেয় (52%)। লাইনে পরবর্তী অর্কেস্ট্রেটর হল ডকার সোয়ার্ম (প্রায় 12%)। সর্বাধিক জনপ্রিয় সিআই সিস্টেমগুলি হল জেনকিন্স এবং গিটল্যাব। সবচেয়ে জনপ্রিয় কনফিগারেশন ম্যানেজমেন্ট সিস্টেম হল Ansible, এর পরে আমাদের প্রিয় শেল।

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

আমি ইগরকে মেঝে দিই, যারা আরও কিছু পরিসংখ্যান দেবে।

অনুশীলনের বিস্তার

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

চটপটে এবং DevOps

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

দল টপোলজি

গত বছরের শেষে বইটি “দল টপোলজি", যা টিম টপোলজি বর্ণনা করার জন্য একটি কাঠামো প্রস্তাব করে। আমরা ভাবছিলাম এটা রাশিয়ান কোম্পানির ক্ষেত্রে প্রযোজ্য হবে কিনা। এবং আমরা প্রশ্ন জিজ্ঞাসা করেছি: "আপনি কোন নিদর্শন দেখতে পাচ্ছেন?"

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

DevQaOps অনুপাত

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

2021 এর জন্য পরিকল্পনা

পরবর্তী বছরের জন্য তাদের পরিকল্পনায়, উত্তরদাতারা নিম্নলিখিত ক্রিয়াকলাপগুলি উল্লেখ করেছেন:

এখানে আপনি DevOps Live 2020 সম্মেলনের ছেদ দেখতে পাবেন। আমরা সাবধানে প্রোগ্রামটি পর্যালোচনা করেছি:

• একটি পণ্য হিসাবে অবকাঠামো
• DevOps রূপান্তর
• DevOps অনুশীলন বিতরণ
• ডেভসেকস
• কেস ক্লাব এবং আলোচনা

কিন্তু আমাদের আলোচনায় সমস্ত বিষয় কভার করার জন্য পর্যাপ্ত সময় থাকবে না। দৃশ্যের অন্তরালে:

• একটি পরিষেবা এবং একটি পণ্য হিসাবে প্ল্যাটফর্ম;
• কোড, পরিবেশ এবং মেঘ হিসাবে অবকাঠামো;
• ক্রমাগত একীকরণ এবং বিতরণ;
• স্থাপত্য;
• DevSecOps প্যাটার্নস;
• প্ল্যাটফর্ম এবং ক্রস-কার্যকরী দল।

প্রতিবেদন আমাদের বিশাল, 50 পৃষ্ঠা দীর্ঘ, এবং আপনি এটি আরও বিশদে দেখতে পারেন।

বুদ্ধিমান

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

রাশিয়ার DevOps রাজ্যের প্রথম গবেষণার ফলাফল:

• মূল ম্যাট্রিক্স. আমরা দেখেছি যে মূল মেট্রিক্স (প্রসবের সময়, স্থাপনার হার, পুনরুদ্ধারের সময়, এবং পরিবর্তন ব্যর্থতা) উন্নয়ন, পরীক্ষা এবং অপারেশন প্রক্রিয়াগুলির কার্যকারিতা বিশ্লেষণের জন্য উপযুক্ত।
• প্রোফাইল উচ্চ, মাঝারি, নিম্ন. সংগৃহীত তথ্যের উপর ভিত্তি করে, পরিসংখ্যানগতভাবে বিভিন্ন গ্রুপ সনাক্ত করা সম্ভব: উচ্চ, মাঝারি, নিম্ন, মেট্রিক্স, অনুশীলন, প্রক্রিয়া এবং সরঞ্জামগুলির উপর ভিত্তি করে স্বতন্ত্র বৈশিষ্ট্য সহ। হাই প্রোফাইলের প্রতিনিধিরা নিম্ন থেকে ভালো ফলাফল দেখায়। তারা তাদের লক্ষ্য অর্জন এবং অতিক্রম করার সম্ভাবনা বেশি।
• সূচক, মহামারী এবং 2021 এর পরিকল্পনা। এই বছরের একটি বিশেষ সূচক হ'ল সংস্থাগুলি কীভাবে মহামারী মোকাবেলা করেছে। উচ্চ পারফরম্যান্স আরও ভাল, ব্যবহারকারীর ক্রিয়াকলাপ বৃদ্ধি পেয়েছে এবং সাফল্যের প্রধান কারণগুলি ছিল দক্ষ বিকাশ প্রক্রিয়া এবং একটি শক্তিশালী প্রকৌশল সংস্কৃতি।
• DevOps অনুশীলন, সরঞ্জাম এবং তাদের বিকাশ। পরবর্তী বছরের জন্য কোম্পানিগুলির প্রধান পরিকল্পনাগুলির মধ্যে রয়েছে DevOps অনুশীলন এবং সরঞ্জামগুলির বিকাশ, DevSecOps অনুশীলনগুলির প্রবর্তন এবং সাংগঠনিক কাঠামোর পরিবর্তন৷ এবং DevOps অনুশীলনের কার্যকর বাস্তবায়ন এবং বিকাশ পাইলট প্রকল্প, সম্প্রদায় এবং সক্ষমতা কেন্দ্র গঠন, কোম্পানির উচ্চ এবং নিম্ন স্তরে উদ্যোগের মাধ্যমে পরিচালিত হয়।

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

উত্স: www.habr.com