DevOps মেট্রিক্স - গণনার জন্য ডেটা কোথায় পেতে হবে

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

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

ইদানীং, সবাই লিডটাইম সম্পর্কে কথা বলছে - ব্যবসার বৈশিষ্ট্য সরবরাহের সময়। মেট্রিক একটি উন্মাদ সংখ্যা দেখিয়েছে - একটি কাজ প্রদানের জন্য 200 দিন। সবাই কেমন আহা-আহাদে আকাশের দিকে হাত তুলেছে!

কিছু সময় পরে, গোলমাল ধীরে ধীরে কমে যায় এবং ব্যবস্থাপনা আরেকটি মেট্রিক তৈরি করার আদেশ পায়।

এটি ইভানের কাছে সম্পূর্ণরূপে পরিষ্কার ছিল যে নতুন মেট্রিকটি অন্ধকার কোণে নিঃশব্দে মারা যাবে।

প্রকৃতপক্ষে, ইভান ভেবেছিল, সংখ্যাটি জেনেও কাউকে কিছু বলা যায় না। 200 দিন বা 2 দিন - কোনও পার্থক্য নেই, কারণ সংখ্যা দ্বারা কারণ নির্ধারণ করা এবং এটি ভাল বা খারাপ কিনা তা বোঝা অসম্ভব।

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

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

একটি অনলাইন স্টোরের জন্য, প্রভাবের বস্তু হবে এর ক্লায়েন্টরা যারা অর্থ আনয়ন করে এবং DevOps-এর জন্য, এটি এমন দল হবে যারা একটি পাইপলাইন ব্যবহার করে বিতরণ তৈরি করে এবং রোল আউট করে।

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

DevOps মেট্রিক্সের উদ্দেশ্য

এটা স্পষ্ট যে সবাই প্রসবের সময় কমাতে চায়। 200 দিন অবশ্যই ভাল নয়।

কিন্তু কীভাবে, সেই প্রশ্ন?

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

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

"সিস্টেমটির উদ্দেশ্য হবে তারা স্ট্যান্ড পাস করার সময় অনুসারে দল নির্বাচন করা, যেমন ফলস্বরূপ, আমাদের নির্বাচিত সময়ের সাথে কমান্ডের একটি তালিকা পাওয়া উচিত, সংখ্যা নয়।

যদি আমরা খুঁজে পাই যে স্ট্যান্ডে মোট কত সময় ব্যয় করা হয়েছিল এবং স্ট্যান্ডের মধ্যে ডাউনটাইমে কত সময় ব্যয় হয়েছিল, আমরা দলগুলিকে খুঁজে বের করতে পারি, তাদের কল করতে পারি এবং আরও বিশদে কারণগুলি বুঝতে পারি এবং সেগুলিকে নির্মূল করতে পারি,” ভাবলেন ইভান৷

DevOps-এর জন্য ডেলিভারির সময় কীভাবে গণনা করবেন

এটি গণনা করার জন্য, DevOps প্রক্রিয়া এবং এর সারমর্মটি অনুসন্ধান করা প্রয়োজন ছিল।

কোম্পানি সীমিত সংখ্যক সিস্টেম ব্যবহার করে, এবং তথ্য শুধুমাত্র তাদের থেকে পাওয়া যাবে এবং অন্য কোথাও নয়।

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

এরপরে, রোলআউট, স্বয়ংক্রিয় এবং ম্যানুয়াল পরীক্ষার সঠিকতা পরীক্ষা করার জন্য জেনকিন্স ব্যবহার করে বেশ কয়েকটি স্ট্যান্ডে বিতরণটি রোল আউট করা হয়েছিল:

ইভান বর্ণনা করেছেন যে কোন সিস্টেম থেকে স্ট্যান্ডে সময় গণনা করার জন্য কী তথ্য নেওয়া যেতে পারে:

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

উপলব্ধ তথ্যের উপর ভিত্তি করে, নিম্নলিখিত চিত্রটি আঁকা হয়েছিল:

ডিস্ট্রিবিউশন তৈরি করতে কত সময় লাগে এবং সেগুলির প্রতিটিতে কত সময় ব্যয় হয় তা জেনে, আপনি সহজেই পুরো DevOps পাইপলাইন (সম্পূর্ণ চক্র) পেরিয়ে যাওয়ার মোট খরচ গণনা করতে পারেন।

এখানে DevOps মেট্রিক্স রয়েছে যা ইভান দিয়ে শেষ করেছেন:

• তৈরি করা বিতরণের সংখ্যা
• বিতরণের ভাগ যা স্ট্যান্ডে "এসেছে" এবং স্ট্যান্ডটি "পাস করেছে"
• স্ট্যান্ডে কাটানো সময় (স্ট্যান্ড সাইকেল)
• সম্পূর্ণ চক্র (সমস্ত স্ট্যান্ডের জন্য মোট সময়)
• কাজের সময়কাল
• স্ট্যান্ডের মধ্যে ডাউনটাইম
• একই স্ট্যান্ডে চাকরি লঞ্চের মধ্যে ডাউনটাইম

একদিকে, মেট্রিক্সগুলি সময়ের পরিপ্রেক্ষিতে DevOps পাইপলাইনকে খুব ভালভাবে চিহ্নিত করেছে, অন্যদিকে, সেগুলিকে খুব সাধারণ হিসাবে বিবেচনা করা হয়েছিল।

ভাল কাজ করায় সন্তুষ্ট, ইভান একটি প্রেজেন্টেশন তৈরি করেন এবং এটি পরিচালনার কাছে উপস্থাপন করতে যান।

সে বিষণ্ণ হয়ে ফিরে এল এবং হাত নামিয়ে।

"এটা একটা ফাজলামি, ভাই," হাস্যকর সহকর্মী হাসল...

নিবন্ধে আরও পড়ুন "কিভাবে দ্রুত ফলাফল ইভান সাহায্য».

উত্স: www.habr.com