কিভাবে একটি DevOps দৃষ্টিকোণ থেকে একটি প্রযুক্তিগত ঋণ বিক্রি?

এটি প্রায়শই নাটকীয়ভাবে এবং করুণভাবে যুক্তি দেওয়া হয় যে প্রযুক্তিগত ঋণ তৈরি না করাই ভাল। হ্যাঁ, এটি ছাড়া এটি অবশ্যই ভাল। কিন্তু পরিণতি এখনও নির্মূল করা যেতে পারে।

আমি প্রযুক্তিগত ঋণকে সমস্ত পরিবর্তন এবং উন্নতি, অবকাঠামোগত পরিবর্তন এবং প্রক্রিয়া পরিবর্তন, ফাঁকগুলি দূর করার লক্ষ্যে টিম কাঠামোর পরিবর্তনগুলি (পণ্য লঞ্চ করার কাঠামোর মধ্যে সচেতনভাবে তৈরি করা হয়েছে) এবং সময়ের সাথে ব্যাপকভাবে হস্তক্ষেপ করে এমন বৈশিষ্ট্যগুলি হিসাবে উল্লেখ করি৷

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

প্রযুক্তিগত ঋণ - এটা কার?

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

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

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

বছরের পর বছর জড়িত থাকার পরে, আমি বুঝতে পেরেছিলাম যে আমরা ফ্রোডোর মতো, যিনি সবাইকে একটি আংটি অফার করেছিলেন। এটি এমন, "আমাকে এই বোঝা বহন করতে সাহায্য করুন!" আমরা প্রযুক্তিগত ঋণ মোকাবেলা করার জন্য ব্যবসার জন্য অপেক্ষা করছি (ঠিকভাবে চাই)। কিন্তু ব্যবসা নিয়ে আমাদের পারস্পরিক ভুল বোঝাবুঝির মূল কারণ এটা কখনোই চাইবে না।

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

কল্পনা করুন আপনি একটি ক্যাবে উঠবেন, এবং ড্রাইভার জিজ্ঞাসা করবে, "আমি কি গাড়ি ধোয়ার সময় থামতে পারি?"

এই পরিস্থিতিতে ব্যবসা একটি ক্লায়েন্ট, এবং বিকাশকারীরা ক্যাব ড্রাইভার।

• ব্যবসাটি ক্ষুব্ধ: "কেমন আসে?! আমি ভ্রমণের সময় পরিশোধ করছি, এবং আপনি গাড়ি ধোয়ার জন্য যাচ্ছেন!"

• যার জন্য ক্যাব চালক যুক্তিসঙ্গতভাবে উত্তর দেয়: "আপনি কি একটি পরিষ্কার গাড়িতে চড়তে চান না যার গন্ধ ভালো?"

• ব্যবসার উত্তর: "মানুষ, আমি অবশ্যই করি! কিন্তু আমি ডিফল্টরূপে এটি আশা করি, এবং আমি এটির জন্য এখন গাড়ি ধোয়াতে থামতে প্রস্তুত নই!"

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

কারণ, আগেই বলেছি, কেউ মান চায় না। তবে এটি ডিফল্টরূপে প্রত্যাশিত।

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

আমার যাত্রার সময়, আমি প্রযুক্তিগত ঋণ "ক্রয়" করার জন্য ব্যবসায়িক প্রেরণার 3টি বিভাগ তৈরি করেছি:

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

  
  

  আমার দৃষ্টিতে, এটি একটি দুর্দান্ত ফ্রিস্টাইল যা প্রায়শই বিপর্যয়ের দিকে নিয়ে যায় কারণ প্রযুক্তিগত ঋণের জন্য বাস্তববাদের প্রয়োজন হয়। যখন আমরা এটি বাস্তবসম্মতভাবে করি না, তখন আমরা সিউডো-কুল আর্কিটেকচারের একটি লেভিয়াথান তৈরি করি।

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

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

এর পরে, আমি আমার অভিজ্ঞতা এবং আমার এবং আমার দুর্দান্ত দলের জন্য কী কাজ করছে তা নিয়ে আলোচনা করব।

প্রযুক্তিগত ঋণের সাথে খরগোশের গর্ত কতটা গভীর?

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

প্রযুক্তিগত ঋণ নিয়ে কাজ করার ক্ষেত্রে এটি একটি স্বাভাবিক এবং বাধ্যতামূলক প্রথম ধাপ। আপনি প্রথম জিনিসটি খুঁজে পেতে তাড়াহুড়ো করা উচিত নয়। আপনার সামগ্রিকভাবে পরিস্থিতি বিশ্লেষণ করা উচিত।

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

আমাদের অ্যাপ্লিকেশনে কমপক্ষে 80টি ভিন্ন উপাদান ছিল (বন্টন, ইনস্টলেশন নয়)। পরিস্থিতি বুঝে তা সামাল দিতে হয়েছে।

পর্যায় 1. ভার্চুয়াল দল

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

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

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

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

তাই, আমি ফেজ 2 এ চলে গেলাম।

পর্যায় 2. প্রযুক্তিগত ঋণ আমার

ফেজ 1 এ, আমি আমাদের কোম্পানির সিইওর সাথে একমত হয়েছিলাম যে আমরা একটি ব্যাকলগ কোটা চালু করব। আমরা ব্যবসায়িক ইস্যুতে 70%, ত্রুটি দূরীকরণে 15% এবং প্রযুক্তিগত ঋণের জন্য 15% ব্যয় করব।

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

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

এবং তাই আমরা যাত্রা শুরু. প্রযুক্তিগত নেতা (যারা দায়িত্বে আছেন) এবং প্রযুক্তিগত ঋণের জন্য 15% কোটা রয়েছে (সময় আছে)। কিন্তু বাস্তবতা শেষ পর্যন্ত কেমন হলো?

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

মানুষ লগ দিন!

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

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

৫% ভাগ্যবান বলে বিবেচিত হয়...

বাস্তবতা হল যে 15% কোটা থাকা সত্ত্বেও, প্রতিটি স্প্রিন্টে কিছু ব্যবসায়িক সংকট এবং জরুরী ইনজেকশন রয়েছে কারণ "সঙ্গীর এখন এটি প্রয়োজন, নয়তো সে চলে যাবে!" অবশ্যই, এই প্রযুক্তিগত ঋণ প্রথমে স্প্রিন্টের বাইরে ঠেলে দেওয়া হয় - ফলস্বরূপ, আমাদের 0% সহ স্প্রিন্ট ছিল।

15% সহ স্প্রিন্টও ছিল, কিন্তু আমাদের গড়ে মাত্র 5-8% প্রযুক্তিগত ঋণ ছিল। এটি একটি বড় সমস্যা কারণ একজন প্রোগ্রামার জানেন না যে তার বাস্তবায়নের জন্য কতটা সময় থাকবে।

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

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

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

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

পদ্ধতির সীমাবদ্ধতা

পণ্যের মালিকরা এই বাস্তবতায় অভ্যস্ত যে ব্যাকলগ সবই তাদের এবং সমস্ত কাজ তাদের দ্বারা সমন্বিত হয়: "কোটা ভালো, কিন্তু প্রযুক্তিগত ঋণের এই কোটায় দলটি কী করবে তা শুধুমাত্র আমরাই ঠিক করি!"

এবং যখন বিকাশকারীরা রিফ্যাক্টরিং, বয়লারপ্লেট নির্মূল ইত্যাদির মতো কাজগুলি নিয়ে আসে (মজবুত সংযোগের কথা মনে রাখবেন), তারা একটি যৌক্তিক প্রতিক্রিয়া পেয়েছে: "কী?! কী বয়লারপ্লেট? আমরা কী নিয়ে কথা বলছি?!"

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

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

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

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

কারণ তাদের সত্যিই কোন সময় ছিল না, অতিরিক্ত কাজের চাপ ছিল এবং কাজ করতে বাধা দেওয়া হয়েছিল।

কিন্তু এই পদ্ধতির নেতিবাচক দিক সত্ত্বেও, আমরা বেশ অনেক কিছু অর্জন করেছি।

এই পদ্ধতির মাধ্যমে আমরা কী অর্জন করেছি?

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

দ্বিতীয়ত, আমরা অনেক উপাদানে স্প্যাগেটি কোডের বিরুদ্ধে লড়াই সফলভাবে বাস্তবায়ন করেছি।

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

আমি অনেক চেষ্টা দেখেছি এবং প্রথম পর্বে নিজে এটি ভিন্নভাবে করার চেষ্টা করেছি। এটা কাজ করেনি.

প্রকৃতপক্ষে, এই মোডে কাজ করা দীর্ঘ সময়ের জন্য স্থায়ী হতে পারে না। এটি একটি সীমিত কার্টে ব্লাঞ্চ যা ব্যবস্থাপনা আপনাকে দেয়, আপনাকে CTO এবং দলের নেতা হিসাবে বিশ্বাস করে।

পর্যায় 3. বৈধ প্রকল্প

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

• এই প্রকল্পের কাঠামোর মধ্যে আমরা যে কাজ শুরু করেছি তা আমি যতটা সম্ভব সংকুচিত করেছি।

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

একটি গুরুত্বপূর্ণ বিষয় হল যে আমাদের একটি নির্দিষ্ট বিভ্রম রয়েছে যে আমরা প্রযুক্তিগত ঋণের ব্যবসায়িক মূল্য গণনা করার চেষ্টা করছি, যদিও এটি খুব কমই সম্ভব। আর যদি এখনও হিসেব করা যায়, তাহলে আমাদের কাছে দুঃস্বপ্নের কারিগরি ঋণ আছে!

ইতিবাচক মান নেতিবাচক মূল্যের চেয়ে ব্যবসার জন্য ভাল কাজ করে। আপনি যদি বলেন, "এই ক্লায়েন্ট চলে যাবে। সে এত টাকা এনেছে," তাহলে সে চলে না যাওয়া পর্যন্ত কাজ হবে না। এটা কোনো ব্যবসায়িক মূল্য নয়। তদুপরি, ঝুঁকি নিয়ে কাজ করার সংস্কৃতি এখনও খুব বেশি নয়, তাই মোডটি হল: "তারা চলে যাওয়া পর্যন্ত কোন ক্ষতি নেই।"

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

কারিগরি ঋণ কীভাবে বিক্রি করবেন তার নির্দেশিকা

প্রযুক্তিগত ঋণ বিক্রির জন্য এই পর্যায়ের সম্পূর্ণ কর্মপ্রবাহ এখানে।

ফোকাসের একটি এলাকা চয়ন করুন (শুধু একটি)

যেহেতু এটি ভয়ের মাধ্যমে বিক্রি হচ্ছে, তাই এমন একটি এলাকা বেছে নিন যা সত্যিই আপনার ব্যবসাকে প্রভাবিত করে। ক্ষেত্রগুলি ভিন্ন হতে পারে: প্রাপ্যতা, পুনঃকর্মের গতি, A/B পরীক্ষা এবং পরীক্ষা-নিরীক্ষার নিরাপত্তা এবং পুনরায় কাজের খরচ। এলাকা এবং বিষয় একটি বিশাল সংখ্যা আছে.

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

ইন্টিগ্রাল এনালাইসিস করুন

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

প্রাপ্যতার প্রথম নিয়মটি এমন একটি সিস্টেম তৈরি করার চেষ্টা করা নয় যা সর্বদা উপলব্ধ থাকবে তবে একটি ঘটনা ঘটলে প্রস্তুত থাকা। এটা আমাদের নিশ্চিত করতে হবে।

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

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

কম্পোনেন্ট-বাই-কম্পোনেন্ট বিশ্লেষণ করুন

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

আমরা এটি সব দিয়েছি, কিন্তু এটি এখনও বিপণনযোগ্য নয়। বাইরে যেতে এবং এখন এটি খোলাখুলিভাবে দেখানোর জন্য, আমরা এই পর্যায়ের প্রতিটি প্রকল্পের জন্য নিম্নলিখিত কাজ করেছি।

সারবস্তু, পরিমাণগত সূচক গঠন করুন

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

মূল্যকে কেবল ব্যবসায়িক মূল্য হিসাবে নেওয়া উচিত নয়। এগুলিকে বলা যেতে পারে, উদাহরণস্বরূপ, "X মিথ্যা ইতিবাচকের বেশি নয়।"

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

প্রকল্প রক্ষা

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

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

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

পদ্ধতির সুবিধা

সুতরাং, আমরা লাফ দিতে শুরু করলাম (অতলের উপর)। আমরা এটি সফলভাবে করছি। এখন, আমরা এই প্রকল্পের দ্বিতীয় রাউন্ডে আছি। অর্থাৎ, আমরা প্রকল্পগুলির প্রথম পুলটি টেনে নিয়েছি এবং প্রকল্পগুলির দ্বিতীয় পুলটিতে সম্মত হয়েছি। কি বদলে গেছে?

আস্থা বৃদ্ধি

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

বড় প্রকল্প করছেন

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

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

প্রকল্পের OPS'রা

সবচেয়ে গুরুত্বপূর্ণ, আমরা বুঝতে পেরেছি যে আমাদের পরিকাঠামো এবং রোলআউট প্রক্রিয়াতে নতুনভাবে ডিজাইন করার জন্য অনেক কিছু আছে। OPS'ers স্পষ্টভাবে এই প্রকল্পে অন্তর্ভুক্ত ছিল.

আমার মনে, এটি Kubernetes এবং Docker এর চেয়ে বেশি DevOps যখন OPS'ers ডেভেলপারদের সাথে আলোচনা করে কিভাবে একটি কম্পোনেন্টের আর্কিটেকচার পরিবর্তন করতে হয়, এবং ডেভেলপাররা OPS'ers এর সাথে আলোচনা করে কিভাবে পরিকাঠামো পরিবর্তন করা যায়।

কেন আমি এখনই এটা করিনি?

এখানে আমরা ফেজ 2 এর শেষে আমি যে বিষয়ে কথা বলছিলাম সেখানে ফিরে আসি: এটি আগে কাজ করত না। কারণ আমরা ফেজ 2-এ যা করেছি (স্প্যাগেটি কোড যা আমরা নতুন করে ডিজাইন করেছি, টেস্টের পেশী-বিল্ডিং, এবং CI প্রক্রিয়াগুলির পুনরায় ডিজাইন) পরিমাপযোগ্য মেট্রিক্স সম্পর্কিত ব্যবসার কাছে বিক্রি করা অসম্ভব ছিল।

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

আমার দৃষ্টিকোণ থেকে, আপনার যদি এমন একটি প্রযুক্তি প্ল্যাটফর্ম থাকে যার জন্য এই ধরনের গভীর পরিকাঠামোগত পুনর্ব্যবহার প্রয়োজন, আপনি ফেজ 2 এড়াতে পারবেন না।

আপনাকে এটির জন্য যেতে হবে, তবে আপনাকে কেবল সারাক্ষণ ঘুড়ির মতো ওড়াতে নয় বরং আপনার ব্যবসার আস্থা না হারানোর জন্য এই দোকানটি দ্রুত বন্ধ করার জন্য প্রস্তুত থাকতে হবে।