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

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

লিওন রাশিয়ান ভাষায় খুব রঙিনভাবে কথা বলে, তাই যদি আপনার কাছে 35-40 মিনিট থাকে তবে আমি ভিডিওটি দেখার পরামর্শ দিচ্ছি। নিচে সময় বাঁচাতে পাঠ্য সংস্করণ।

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

এক মাস আগে

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

শিক্ষণ কৌশলগুলি জন্ম থেকে তিন বছর বয়স পর্যন্ত খুব ছোট বাচ্চাদের জন্য পাঠ্যক্রমের একটি বাজারের নেতা। ঐতিহ্যগত "কাগজ" কোম্পানি ইতিমধ্যে 40 বছর বয়সী, এবং প্ল্যাটফর্মের ডিজিটাল SaaS সংস্করণ 10 বছর পুরানো৷ তুলনামূলকভাবে সম্প্রতি, কোম্পানির মানগুলির সাথে ডিজিটাল প্রযুক্তিকে অভিযোজিত করার প্রক্রিয়া শুরু হয়েছে৷ "নতুন" সংস্করণটি 2017 সালে চালু হয়েছিল এবং এটি প্রায় পুরানোটির মতো ছিল, কেবল এটি আরও খারাপ কাজ করেছিল।

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

একটু সামনের দিকে তাকালে, আমি লক্ষ্য করব যে আমি আমার কাজ শুরু করেছি সর্বোচ্চ বার্ষিক ট্রাফিকের সময়, যা বিভিন্ন কারণে আকর্ষণীয়।

প্ল্যাটফর্ম, যা মাত্র 2 বছর পুরানো বলে মনে হচ্ছে, একটি অদ্ভুত স্ট্যাক ছিল: 2008 থেকে ColdFusion এবং SQL সার্ভার। কোল্ডফিউশন, যদি আপনি না জানেন, এবং সম্ভবত আপনি জানেন না, একটি এন্টারপ্রাইজ পিএইচপি যা 90-এর দশকের মাঝামাঝি সময়ে এসেছিল এবং তারপর থেকে আমি এটির কথাও শুনিনি। এছাড়াও ছিল: রুবি, মাইএসকিউএল, পোস্টগ্রেএসকিউএল, জাভা, গো, পাইথন। কিন্তু মূল মনোলিথটি ColdFusion এবং SQL সার্ভারে চলে।

সমস্যার

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

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

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

দুদিন আগে

একটি নতুন কাজ শুরু করার দুই দিন আগে, আমি অফিসে পৌঁছেছি, শেষ কাগজপত্র পূরণ করেছি, দলের সাথে দেখা করেছি এবং আবিষ্কার করেছি যে দলটি সেই সময়ে একটি সমস্যার সাথে লড়াই করছে। এটি ছিল যে গড় পৃষ্ঠা লোডিং সময় লাফিয়ে 4 সেকেন্ডে, অর্থাৎ 2 বার।

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

প্রথম দিন

দুই দিন কেটে গেছে এবং আমার কাজের প্রথম দিনে আমি আবিষ্কার করেছি যে সমস্যাটি দূর হয়নি।

দুই দিনের জন্য, ব্যবহারকারীদের পৃষ্ঠাগুলি গড়ে 4 সেকেন্ডে লোড হয়। আমি জিজ্ঞাসা করি যে তারা কি সমস্যা খুঁজে পেয়েছে।

- হ্যাঁ, আমরা টিকিট খুলেছি।
- আর?
- আচ্ছা, তারা এখনও আমাদের উত্তর দেয়নি।

তারপরে আমি বুঝতে পেরেছিলাম যে আমাকে আগে যা বলা হয়েছিল তা ছিল আইসবার্গের একটি ছোট টিপ যা আমাকে লড়াই করতে হয়েছিল।

একটি ভাল উদ্ধৃতি আছে যা এটি খুব ভালভাবে ফিট করে:

"কখনও কখনও প্রযুক্তি পরিবর্তন করতে হলে আপনাকে প্রতিষ্ঠান পরিবর্তন করতে হবে।"

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

দিন তিন

সুতরাং, লোডিং 4 সেকেন্ড স্থায়ী হয়, এবং 13 থেকে 15 পর্যন্ত বৃহত্তম শিখর।

এই সময়ের মধ্যে তৃতীয় দিনে, ডাউনলোডের গতি এইরকম দেখায়:

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

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

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

— আমি জিজ্ঞাসা করতে বিব্রতবোধ করছি, কিন্তু 150 কে 17 দিয়ে ভাগ করলে প্রায় 8 পাওয়া যায়? আপনি কি বলছেন যে প্রতিটি সার্ভার প্রতি সেকেন্ডে 8টি অনুরোধের অনুমতি দেয় এবং আগামীকাল যদি প্রতি সেকেন্ডে 160টি অনুরোধ আসে তবে আমাদের আরও 2টি সার্ভারের প্রয়োজন হবে?

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

var currentClass = classes.getCurrentClass();
return currentClass;

একটি ফাংশন ছিল getCurrentClass(), কারণ সাইটের সবকিছু একটি ক্লাসের প্রসঙ্গে কাজ করে - এটা ঠিক। এবং এই জন্য প্রতিটি পৃষ্ঠায় একটি ফাংশন ছিল 200+ অনুরোধ.

এইভাবে সমাধানটি খুব সহজ ছিল, এমনকি আপনাকে কিছু পুনরায় লিখতে হবে না: শুধু একই তথ্য আবার জিজ্ঞাসা করবেন না।

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

আমি খুব খুশি ছিলাম কারণ আমি সিদ্ধান্ত নিয়েছিলাম যে তৃতীয় দিনেই আমি মূল সমস্যাটি খুঁজে পেয়েছি। আমি যেমন নিষ্পাপ ছিলাম, এটি ছিল অনেক সমস্যার মধ্যে একটি।

কিন্তু এই প্রথম সমস্যাটি সমাধান করা গ্রাফটি অনেক নিচে নেমে গেছে।

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

দশম দিন

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

মজার কিছু আবার আবিষ্কৃত হয়েছে. দলটি নিয়ে গঠিত: 18 জন বিকাশকারী; 8 পরীক্ষার্থী; 3 পরিচালক; 2 স্থপতি। এবং তারা সকলেই সাধারণ আচার-অনুষ্ঠানে অংশ নিয়েছিল, অর্থাৎ, 30 জনেরও বেশি লোক প্রতিদিন সকালে স্ট্যান্ড-আপে আসে এবং তারা কী করেছিল তা বলেছিল। এটা স্পষ্ট যে বৈঠকে 5 বা 15 মিনিট সময় লাগেনি। সবাই ভিন্ন সিস্টেমে কাজ করে বলে কেউ কারো কথা শোনেনি। এই ফর্মে, একটি গ্রুমিং সেশনের জন্য প্রতি ঘন্টায় 2-3 টি টিকিট ইতিমধ্যেই একটি ভাল ফলাফল ছিল।

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

ফলস্বরূপ আমরা পেয়েছি:

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

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

এগারো দিন

দলের কাঠামো পরিবর্তনের প্রক্রিয়ায়, আমি কীভাবে গণনা করতে হয় তা আবিষ্কার করেছি গল্পপয়েন্ট. 1 SP এক দিনের সমান ছিল, এবং প্রতিটি টিকিটে উন্নয়ন এবং QA উভয়ের জন্য SP রয়েছে, অর্থাৎ কমপক্ষে 2 SP।

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

আমরা একটি বাগ খুঁজে পেয়েছি: একটি প্রতিবেদনে, যেখানে প্রতিবেদনের প্রয়োজনের সময়কালের শুরু এবং শেষ তারিখটি প্রবেশ করানো হয়, শেষ দিনটি বিবেচনায় নেওয়া হয় না। অর্থাৎ, অনুরোধে কোথাও <= ছিল না, কিন্তু সহজভাবে <। আমাকে বলা হয়েছিল যে এটি তিনটি স্টোরি পয়েন্ট, অর্থাৎ 3 দিন.

এর পরে আমরা:

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

বিংশতম দিন

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

দীর্ঘমেয়াদী লক্ষ্য:

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

অতীতে প্রায়ই বলা হত: "আসুন সবকিছু আবার লিখি [ভাষা/ফ্রেমওয়ার্ক], সবকিছু আরও ভাল কাজ করবে!"

বেশিরভাগ ক্ষেত্রে এটি কাজ করে না, এটি ভাল যদি পুনর্লিখন কাজ করে। অতএব, আমাদের একটি রোডম্যাপ তৈরি করতে হবে - একটি নির্দিষ্ট কৌশল যা ধাপে ধাপে ব্যাখ্যা করে কিভাবে ব্যবসার লক্ষ্যগুলি অর্জন করা হবে (আমরা কী করব এবং কেন), যা:

• প্রকল্পের মিশন এবং লক্ষ্য প্রতিফলিত করে;
• প্রধান লক্ষ্যগুলিকে অগ্রাধিকার দেয়;
• তাদের অর্জনের জন্য একটি সময়সূচী রয়েছে।

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

অর্থাৎ, সাংগঠনিক KPIs টিম দ্বারা সমর্থিত, এবং দল KPIs পৃথক KPIs দ্বারা সমর্থিত। অন্যথায়, যদি প্রযুক্তিগত কেপিআইগুলি সাংগঠনিকদের সাথে মিলে না যায়, তবে প্রত্যেকে নিজের উপর কম্বল টেনে নেয়।

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

আপনি কিভাবে আরো নতুন পণ্য থাকার লক্ষ্য সমর্থন করতে পারেন?

• প্রথমত, আমরা ত্রুটিগুলি সংশোধন করার পরিবর্তে নতুন পণ্য বিকাশে আরও সময় ব্যয় করতে চাই। এটি একটি যৌক্তিক সমাধান যা পরিমাপ করা সহজ।
• দ্বিতীয়ত, আমরা লেনদেনের পরিমাণ বৃদ্ধিকে সমর্থন করতে চাই, কারণ মার্কেট শেয়ার যত বেশি হবে, তত বেশি ব্যবহারকারী এবং তদনুসারে, আরও বেশি ট্রাফিক৷

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

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

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

দিন ত্রিশ

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

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

আরেকটি মজার বিষয় হল যে একটি বৃহত্তম ক্লায়েন্টের সাথে চুক্তিতে বলা হয়েছে যে প্ল্যাটফর্মের দ্বারা সমর্থিত সমস্ত সফ্টওয়্যার সংস্করণ অবশ্যই n-1 হতে হবে, অর্থাৎ, সর্বশেষ সংস্করণ নয়, তবে চূড়ান্ত সংস্করণ।

এটা পরিষ্কার যে আমরা n-1 থেকে কত দূরে ছিলাম যদি প্ল্যাটফর্মটি ColdFusion এবং SQL Server 2008-এর উপর ভিত্তি করে হয়, যা জুলাই মাসে আর সমর্থিত ছিল না।

দিন পঁয়তাল্লিশ

দ্বিতীয় মাসের মাঝামাঝি সময়ে আমি বসতে এবং করতে যথেষ্ট সময় পেয়েছি মূল্যপ্রবাহম্যাপিং সম্পূর্ণ প্রক্রিয়ার জন্য। একটি পণ্য তৈরি করা থেকে শুরু করে ভোক্তাদের কাছে পৌঁছে দেওয়া পর্যন্ত এগুলি প্রয়োজনীয় পদক্ষেপগুলি নেওয়া দরকার এবং সেগুলিকে যতটা সম্ভব বিস্তারিতভাবে বর্ণনা করা দরকার।

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

যখন আমি এটি করেছি, দুটি জিনিস আমার নজরে পড়েছে:

• QA থেকে ডেভেলপারদের কাছে ফেরত দেওয়া টিকিটের উচ্চ শতাংশ;
• পুল অনুরোধ পর্যালোচনাগুলি খুব বেশি সময় নিয়েছে৷

সমস্যা ছিল যে এই উপসংহার যেমন: এটা অনেক সময় লাগে বলে মনে হচ্ছে, কিন্তু আমরা কতক্ষণ নিশ্চিত না.

"আপনি যা পরিমাপ করতে পারবেন না তা আপনি উন্নত করতে পারবেন না।"

সমস্যাটি কতটা গুরুতর তা কীভাবে জায়েজ করবেন? এটা কি দিন বা ঘন্টা নষ্ট করে?

এটি পরিমাপ করার জন্য, আমরা জিরা প্রক্রিয়ায় কয়েকটি ধাপ যুক্ত করেছি: প্রতিটি টিকিট কতক্ষণ অপেক্ষা করে এবং কতবার এটি একটি নির্দিষ্ট ধাপে ফিরে আসে তা পরিমাপ করতে "দেবের জন্য প্রস্তুত" এবং "QA-এর জন্য প্রস্তুত"।

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

• প্রক্রিয়া দক্ষতা: কর্মক্ষমতা এবং পরিকল্পিত/বিলি।
• প্রক্রিয়া গুণমান: ত্রুটির সংখ্যা, QA থেকে ত্রুটি।

এটা সত্যিই বুঝতে সাহায্য করে কোনটা ভালো যাচ্ছে আর কোনটা ভালো যাচ্ছে না।

পঞ্চাশতম দিন

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

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

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

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

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

একান্নতম দিন

আমার কে আছে তা বোঝার জন্য আমি দলটিকে ঘনিষ্ঠভাবে দেখতে শুরু করলাম এবং আবারও মনে পড়ল:

"বেশিরভাগ সমস্যা মানুষের সমস্যা।"

আমি দেখেছি যে দলটি যেমন - দেব এবং অপস উভয়েরই - তিনটি বড় সমস্যা রয়েছে:

• বর্তমান অবস্থা নিয়ে সন্তুষ্টি।
• দায়িত্বের অভাব - কারণ ব্যবসাকে প্রভাবিত করার জন্য কেউ কখনও অভিনয়কারীদের কাজের ফলাফল আনেনি।
• পরিবর্তনের ভয়।

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

কিন্তু আপনি কিছু পরিবর্তন ছাড়া ভাল পেতে পারেন না.

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

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

• 12 সেকেন্ড লোড হচ্ছে;
• 5-10 মিনিট ডাউনটাইম প্রতিটি রিলিজ;
• জটিল সমস্যা সমাধানে দিন ও সপ্তাহ লাগে;
• ডিউটি ​​কর্মীদের অভাব 24x7 / অন-কল।

কেউ কখনও জিজ্ঞাসা করার চেষ্টা করেনি কেন আমরা এটি আরও ভাল করি না, এবং কেউ কখনও বুঝতে পারেনি যে এটি এভাবে হতে হবে না।

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

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

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

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

দ্বিতীয়ত, যারা অযোগ্য দেখাতে ভয় পায় overanalyse. আপনি যখন বলেন ঠিক কী করা দরকার, এটি শুরু হয়: "না, আমরা যদি এখানে এটি সম্পর্কে চিন্তা করি?" এই অর্থে, আমাদের কোম্পানি অনন্য নয়; এটি তরুণদের জন্য একটি আদর্শ সমস্যা।

প্রতিক্রিয়া হিসাবে, আমি নিম্নলিখিত অনুশীলনগুলি চালু করেছি:

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

ষাটতম দিন

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

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

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

ইনভেন্টরি ফলাফল:

• আমরা একই ডেটা সেন্টার ছেড়েছি।
• আমরা 3টি লগ পরিষেবার সাথে চুক্তি বাতিল করেছি৷ কারণ আমাদের তাদের মধ্যে 5টি ছিল - প্রতিটি বিকাশকারী যারা কিছু নিয়ে খেলতে শুরু করেছিল একটি নতুন নিয়েছিল৷
• 7টি AWS সিস্টেম বন্ধ করা হয়েছে। আবার, কেউ মৃত প্রকল্প বন্ধ করেনি; তারা সবাই কাজ চালিয়ে গেছে।
• 6 গুণ দ্বারা সফ্টওয়্যার খরচ হ্রাস.

পঁচাত্তর দিন

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

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

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

এ প্রসঙ্গে কিছু মজার বিষয় ছিল। উদাহরণস্বরূপ, আমি বলেছিলাম যে আমাদের বিষয়বস্তুর ধরণের উপর নির্ভর করে পৃথক ওয়েব সার্ভারের মধ্যে ট্র্যাফিক বিভক্ত করতে হবে।

অর্থাৎ, ColdFusion জেটি এবং nginx এর মধ্য দিয়ে যায় এবং পৃষ্ঠাগুলি চালু করে। এবং ইমেজ, JS এবং CSS তাদের নিজস্ব কনফিগারেশন সহ একটি পৃথক nginx এর মধ্য দিয়ে যায়। এটি একটি মোটামুটি আদর্শ অনুশীলন যা আমি বলছি আমি লিখেছি বছর দুয়েক আগে. ফলস্বরূপ, ছবিগুলি অনেক দ্রুত লোড হয়, এবং... গড় লোডিং গতি 200 ms বেড়েছে৷

এটি ঘটেছে কারণ জেটির সাথে আসা ডেটার উপর ভিত্তি করে গ্রাফটি তৈরি করা হয়েছে। যে, দ্রুত বিষয়বস্তু হিসাবের অন্তর্ভুক্ত করা হয় না - গড় মান লাফিয়ে উঠেছে। এটি আমাদের কাছে পরিষ্কার ছিল, আমরা হেসেছিলাম, কিন্তু আমরা কীভাবে পরিচালনা পর্ষদের কাছে ব্যাখ্যা করতে পারি কেন আমরা কিছু করেছি এবং জিনিসগুলি 12% খারাপ হয়েছে?

পঁচাশি দিন

তৃতীয় মাসের শেষে, আমি বুঝতে পেরেছিলাম যে একটি জিনিস ছিল যা আমি মোটেও গণনা করিনি: সময়। আমি যে বিষয়ে কথা বলেছি তার সবকিছুই সময় নেয়।

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

উপসংহার

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

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

এটি সংস্কৃতি বা এর অভাব যা অন্যান্য সমস্ত সমস্যার দিকে পরিচালিত করে। আমরা এমন একটি সংস্কৃতি গড়ে তোলার চেষ্টা করছি যেখানে মানুষ:

• ব্যর্থতা ভয় পায় না;
• ভুল থেকে শিক্ষা নাও;
• অন্যান্য দলের সাথে সহযোগিতা;
• উদ্যোগ নাও;
• দায়িত্ব নিতে;
• একটি লক্ষ্য হিসাবে ফলাফল স্বাগত জানাই;
• সাফল্য উদযাপন

এর সাথে বাকি সব আসবে।

লিওন ফায়ার টুইটারে, ফেইসবুক এবং অন মধ্যম.

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

উত্স: www.habr.com