DevOps কি

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

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

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

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

কেন DevOps

প্রথম প্রশ্ন যা সবাইকে এবং সর্বদা তাড়া করে - কেন? অনেক লোক মনে করে যে DevOps শুধুমাত্র অটোমেশন বা অনুরূপ জিনিস যা প্রতিটি কোম্পানি ইতিমধ্যেই ছিল।

— আমাদের ক্রমাগত ইন্টিগ্রেশন ছিল - এর মানে আমাদের ইতিমধ্যেই DevOps ছিল, এবং কেন এই সমস্ত জিনিসের প্রয়োজন? তারা বিদেশে মজা করছে, কিন্তু তারা আমাদের কাজ করতে বাধা দিচ্ছে!

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

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

নীতিগতভাবে, আইটিতে সবকিছু এই পদ্ধতির অনুযায়ী তৈরি করা উচিত। এখানে আইটি প্রক্রিয়াগুলি স্বয়ংক্রিয়ভাবে ব্যবহার করা হয়।

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

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

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

এই পণ্যটি ইউনিলিভার 1 বিলিয়ন ডলারে কিনেছিল। এটি এখন জিলেটের সাথে প্রতিযোগিতা করে এবং আমেরিকান বাজারে ভোক্তাদের একটি উল্লেখযোগ্য অংশ কেড়ে নিয়েছে। এক বক্স শেভ বলে:

- 4টি ব্লেড? আপনি আন্তরিক? আপনার কেন এটি প্রয়োজন - এটি শেভের মান উন্নত করে না। একটি বিশেষভাবে নির্বাচিত ক্রিম, সুগন্ধি এবং দুটি ব্লেড সহ একটি উচ্চ মানের রেজার সেই বোকা 4 জিলেট ব্লেডের চেয়ে অনেক বেশি সমস্যার সমাধান করে! আমরা কি শীঘ্রই 10 এ পৌঁছাব?

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

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

টাইম-টু-মার্কেট হল ধারণা থেকে চূড়ান্ত বাস্তবায়ন পর্যন্ত সময় কমিয়ে আনা।

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

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

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

1968 সালে, একজন স্বপ্নদর্শী লোক, মেলভিন কনওয়ে, নিম্নলিখিত ধারণাটি তৈরি করেছিলেন।

যে সংস্থাটি সিস্টেম তৈরি করে সেটি একটি নকশা দ্বারা সীমাবদ্ধ যা সেই সংস্থার যোগাযোগ কাঠামোর প্রতিলিপি করে।

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

পড়ুন কনওয়ের আইন সম্পর্কে পারেন লিঙ্কের মাধ্যমে. DevOps সংস্কৃতি বা দর্শন বোঝার জন্য এটি গুরুত্বপূর্ণ কারণ DevOps-এ মৌলিকভাবে পরিবর্তন হওয়া একমাত্র জিনিস হল দলগুলোর মধ্যে যোগাযোগের কাঠামো.

প্রক্রিয়ার দৃষ্টিকোণ থেকে, DevOps-এর আগে, সমস্ত ধাপ: বিশ্লেষণ, উন্নয়ন, পরীক্ষা, অপারেশন, রৈখিক ছিল।
DevOps এর ক্ষেত্রে, এই সমস্ত প্রক্রিয়া একই সাথে ঘটে।

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

তাহলে কেন আপনার DevOps দরকার?

ডিজিটাল পণ্য বিকাশের জন্য. আপনার কোম্পানির একটি ডিজিটাল পণ্য না থাকলে, DevOps প্রয়োজন হয় না - এটি খুবই গুরুত্বপূর্ণ।

DevOps অনুক্রমিক সফ্টওয়্যার উত্পাদন গতির সীমাবদ্ধতা অতিক্রম করে৷. এটিতে সমস্ত প্রক্রিয়া একই সাথে ঘটে।

অসুবিধা বাড়ে। যখন DevOps ধর্মপ্রচারকারীরা আপনাকে বলে যে এটি আপনার জন্য সফ্টওয়্যার প্রকাশ করা সহজ করে তুলবে, এটি আজেবাজে কথা।

DevOps এর সাথে, জিনিসগুলি কেবল আরও জটিল হয়ে উঠবে।

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

DevOps কোম্পানির প্রক্রিয়া এবং সংগঠনকে সম্পূর্ণরূপে পরিবর্তন করে — আরও স্পষ্টভাবে, এটি DevOps নয় যা পরিবর্তন করে, কিন্তু ডিজিটাল পণ্য। DevOps-এ আসতে, আপনাকে এখনও এই প্রক্রিয়াটিকে সম্পূর্ণ পরিবর্তন করতে হবে।

একটি বিশেষজ্ঞের জন্য প্রশ্ন

তোমার কী আছে? একটি কোম্পানিতে কাজ করার সময় এবং একজন বিশেষজ্ঞ হিসাবে বিকাশ করার সময় আপনি নিজেকে জিজ্ঞাসা করতে পারেন এমন প্রশ্নগুলি।

আপনি একটি ডিজিটাল পণ্য তৈরি করার জন্য একটি কৌশল আছে? যদি থাকে তবে এটি ইতিমধ্যেই ভাল। এর মানে আপনার কোম্পানি DevOps-এর দিকে এগিয়ে যাচ্ছে।

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

আপনার কোম্পানী কি ডিজিটাল পণ্য কুলুঙ্গিতে বাজারের নেতাদের একজন? Spotify, Yandex, Uber হল এমন কোম্পানি যারা এখন প্রযুক্তিগত উন্নতির শীর্ষে রয়েছে।

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

সংগঠন

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

"কূপ" এর সমস্যা

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

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

DevOps এই বিভ্রান্তির মুহূর্তটি অতিক্রম করার পরামর্শ দেয় এবং একটি সাধারণ মিথস্ক্রিয়া মানচিত্র তৈরি করার জন্য সমস্ত বিভাগ একসাথে কাজ করে।

দুটি কারণ এটিকে বাধা দেয়।

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

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

— আমরা শুধু CI চালু করতে চেয়েছিলাম, কিন্তু দেখা গেল যে ব্যবস্থাপনার প্রয়োজন নেই।

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

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

মানুষ কোনো না কোনো তারকা বা পতাকার জন্য লড়ছে, সবাই তাদের পারদর্শিতা খুঁড়ছে।

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

এটা কি আপনার কোম্পানিতে একই?

এটি পরীক্ষা করতে, আপনি নিজেকে নিম্নলিখিত প্রশ্নগুলি জিজ্ঞাসা করতে পারেন।

দলগুলি কি সাধারণ সরঞ্জামগুলি ব্যবহার করে এবং সেই সাধারণ সরঞ্জামগুলির পরিবর্তনগুলিতে অবদান রাখে?

দলগুলি কত ঘন ঘন পুনর্গঠন করে—এক দল থেকে কিছু বিশেষজ্ঞ অন্য দলে চলে যায়? এটি একটি DevOps পরিবেশে যে এটি স্বাভাবিক হয়ে যায়, কারণ কখনও কখনও একজন ব্যক্তি কেবল বুঝতে পারে না যে দক্ষতার আরেকটি ক্ষেত্র কী করছে। তিনি অন্য বিভাগে চলে যান, সেখানে দুই সপ্তাহ কাজ করেন নিজের জন্য এই বিভাগের সাথে ওরিয়েন্টেশন এবং মিথস্ক্রিয়ার মানচিত্র তৈরি করতে।

একটি পরিবর্তন কমিটি গঠন এবং জিনিস পরিবর্তন করা সম্ভব? নাকি সর্বোচ্চ ব্যবস্থাপনা ও নির্দেশনার বলিষ্ঠ হাতের প্রয়োজন? আমি সম্প্রতি Facebook এ লিখেছিলাম যে কীভাবে একটি স্বল্প পরিচিত ব্যাঙ্ক অর্ডারের মাধ্যমে সরঞ্জামগুলি বাস্তবায়ন করছে: আমরা একটি আদেশ লিখি, আমরা এটি এক বছরের জন্য বাস্তবায়ন করি এবং দেখুন কী হয়৷ এই, অবশ্যই, দীর্ঘ এবং দুঃখজনক.

কোম্পানির কৃতিত্ব বিবেচনা না করে ব্যক্তিগত কৃতিত্ব অর্জন করা পরিচালকদের জন্য কতটা গুরুত্বপূর্ণ?

আপনি যদি নিজের জন্য এই প্রশ্নের উত্তর দেন, তাহলে আপনার কোম্পানিতে এমন সমস্যা আছে কিনা তা পরিষ্কার হয়ে যাবে।

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

এই সমস্যাটি পাস হওয়ার পরে, প্রথম গুরুত্বপূর্ণ অনুশীলন, যা ছাড়া DevOps-এ আরও অগ্রসর হওয়া কঠিন কোড হিসাবে অবকাঠামো.

প্রায়শই, কোড হিসাবে অবকাঠামো নিম্নলিখিত হিসাবে অনুভূত হয়:

— চলুন ব্যাশে সবকিছু স্বয়ংক্রিয় করি, স্ক্রিপ্ট দিয়ে নিজেদেরকে ঢেকে রাখি যাতে প্রশাসকদের ম্যানুয়াল কাজ কম হয়!

কিন্তু তা সত্য নয়।

কোড হিসাবে অবকাঠামো মানে আপনি যে আইটি সিস্টেমের সাথে কাজ করেন সেটির অবস্থা ক্রমাগত বোঝার জন্য কোড আকারে বর্ণনা করেন।

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

সম্মেলনে, 2GIS-এর একজন সহকর্মী বলেছিলেন যে কীভাবে তারা কুবারনেটসের জন্য তাদের নিজস্ব অভ্যন্তরীণ জিনিস তৈরি করেছে, যা পৃথক সিস্টেমের গঠন বর্ণনা করে। 500টি সিস্টেম বর্ণনা করার জন্য, তাদের একটি পৃথক টুলের প্রয়োজন ছিল যা এই বিবরণ তৈরি করে। যখন এই বিবরণ আছে, প্রত্যেকে একে অপরের সাথে পরীক্ষা করতে পারে, পরিবর্তনগুলি নিরীক্ষণ করতে পারে, কীভাবে এটি পরিবর্তন করা যায় এবং এটিকে উন্নত করা যায়, কী নেই।

একমত, স্বতন্ত্র ব্যাশ স্ক্রিপ্ট সাধারণত এই বোঝাপড়া প্রদান করে না। আমি যেখানে কাজ করেছি তার একটিতে "শুধুমাত্র লিখুন" স্ক্রিপ্টের একটি নামও ছিল - যখন স্ক্রিপ্টটি লেখা হয়, তবে এটি আর পড়া সম্ভব নয়। আমি মনে করি এটি আপনার কাছেও পরিচিত।

কোড হিসাবে অবকাঠামো কোড যা অবকাঠামোর বর্তমান অবস্থা বর্ণনা করে. অনেক প্রোডাক্ট, ইনফ্রাস্ট্রাকচার, এবং সার্ভিস টিম এই কোডে একসাথে কাজ করে এবং সবচেয়ে বড় কথা, তাদের সবাইকে বুঝতে হবে এই কোডটি আসলে কিভাবে কাজ করে।

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

কোড সব ইঞ্জিনিয়ারদের জন্য একটি সাধারণ ভাষা হয়ে ওঠে।

কোডে পরিকাঠামো পরিবর্তন করতে বেশি সময় লাগে না. হ্যাঁ, অবকাঠামো কোডেও প্রযুক্তিগত ঋণ থাকতে পারে। সাধারণত দলগুলি এটির মুখোমুখি হয় দেড় বছর পরে তারা "কোড হিসাবে অবকাঠামো" প্রয়োগ করা শুরু করে একগুচ্ছ স্ক্রিপ্ট বা এমনকি অ্যান্সিবল আকারে, যা তারা স্প্যাগেটি কোডের মতো লেখে, এবং তারা ব্যাশ স্ক্রিপ্টগুলিকে মিশ্রণে ফেলে দেয়!

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

কোড হিসাবে অবকাঠামো হল অবকাঠামো কোডকে পৃথক স্তরে বিভক্ত করা।

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


ভিত্তি স্তর - এইভাবে ওএস, ব্যাকআপ এবং অন্যান্য নিম্ন-স্তরের জিনিসগুলি কনফিগার করা হয়, উদাহরণস্বরূপ, কীভাবে কুবারনেটস মৌলিক স্তরে স্থাপন করা হয়।

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

স্তর যেখানে অ্যাপ্লিকেশন তৈরি করা হয় এবং পূর্ববর্তী দুটি স্তরের উপরে কীভাবে তারা উন্মোচিত হবে তা বর্ণনা করে।

প্রশ্ন নিয়ন্ত্রণ করুন

আপনার কোম্পানির একটি সাধারণ অবকাঠামো সংগ্রহস্থল আছে? আপনি কি আপনার অবকাঠামোতে প্রযুক্তিগত ঋণ পরিচালনা করছেন? আপনি কি একটি অবকাঠামো সংগ্রহস্থলে উন্নয়ন অনুশীলন ব্যবহার করেন? আপনার অবকাঠামো কি স্তরে বিভক্ত? আপনি বেস-সার্ভিস-এপিপি ডায়াগ্রামটি পরীক্ষা করতে পারেন। পরিবর্তন করা কতটা কঠিন?

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

ক্রমাগত ডেলিভারি

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

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

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

ক্রমাগত অর্থ প্রদান

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

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

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

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

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

"সঙ্গতভাবে বিতরণ" এই মত দেখায়.

ডেলিভারি প্রসেস Dev, CI, Test, PreProd, Prod কোন আলাদা পরিবেশ নয়, এগুলো হল ফায়ারপ্রুফ সমষ্টি সহ স্টেজ বা স্টেশন যার মধ্য দিয়ে আপনার আর্টিফ্যাক্ট চলে যায়।

আপনার যদি অবকাঠামো কোড থাকে যা বেস সার্ভিস APP হিসাবে বর্ণনা করা হয় তবে এটি সাহায্য করে সব স্ক্রিপ্ট ভুলবেন না, এবং এই আর্টিফ্যাক্টের জন্য কোড হিসাবে তাদের লিখুন, শিল্পকর্ম প্রচার এবং আপনি যেতে হিসাবে এটি পরিবর্তন.

স্ব-পরীক্ষার প্রশ্ন

95% ক্ষেত্রে বৈশিষ্ট্য বর্ণনা থেকে উৎপাদনে মুক্তির সময় এক সপ্তাহের কম? পাইপলাইনের প্রতিটি পর্যায়ে আর্টিফ্যাক্টের গুণমান কি উন্নত হয়? এটা মাধ্যমে যায় যে একটি গল্প আছে? আপনি কি বিভিন্ন স্থাপনার কৌশল ব্যবহার করেন?

যদি সব উত্তর হ্যাঁ হয়, তাহলে আপনি অবিশ্বাস্যভাবে শান্ত! মন্তব্যে আপনার উত্তর লিখুন - আমি খুশি হবে)।

প্রতিক্রিয়া

এটি সব থেকে কঠিন অনুশীলন। DevOpsConf কনফারেন্সে, Infobip-এর একজন সহকর্মী, এটি সম্পর্কে কথা বলতে গিয়ে তার কথায় কিছুটা বিভ্রান্ত হয়েছিলেন, কারণ এটি আসলেই একটি খুব জটিল অনুশীলন যে আপনাকে সবকিছু পর্যবেক্ষণ করতে হবে!

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

- বন্ধুরা, আপনি কেন অস্পষ্ট কিছু দিয়ে সার্ভার ধর্ষণ করছেন?

কিন্তু তারপরে একটি ঘটনা ঘটেছিল যা দেখিয়েছিল যে এটি সত্যিই একটি দুর্দান্ত কৌশল।

একটি পরিষেবা ক্রমাগত ক্র্যাশ হতে শুরু করে। প্রাথমিকভাবে, এটি ক্র্যাশ হয়নি, যা আকর্ষণীয়, কোডটি সেখানে যোগ করা হয়নি, কারণ এটি একটি মৌলিক ব্রোকার ছিল, যার কার্যত কোন ব্যবসায়িক কার্যকারিতা ছিল না - এটি কেবল পৃথক পরিষেবাগুলির মধ্যে বার্তা প্রেরণ করে। পরিষেবাটি 4 মাস ধরে পরিবর্তিত হয়নি এবং হঠাৎ এটি "সেগমেন্টেশন ফল্ট" ত্রুটির সাথে ক্র্যাশ হতে শুরু করেছে।

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

- বন্ধুরা, দেড় সপ্তাহ আগে তোমার কি হয়েছিল?

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

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

ডেলিভারি প্রক্রিয়ার প্রতিটি পর্যায়ে আর্টিফ্যাক্টের কী ঘটে সে সম্পর্কে সমস্ত তথ্য সংগ্রহ করুন - উৎপাদনে নয়।

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

অন্যথায় এটি বের করা কঠিন হবে। আমি ইতিমধ্যে বলেছি যে DevOps আরও জটিল। এই জটিলতা মোকাবেলা করার জন্য, আপনার স্বাভাবিক বিশ্লেষণ থাকতে হবে.

আত্মনিয়ন্ত্রণের জন্য প্রশ্ন

আপনার মনিটরিং এবং লগিং আপনার জন্য উন্নয়ন টুল? কোড লেখার সময়, আপনি সহ আপনার ডেভেলপাররা কি ভাবেন কিভাবে এটি নিরীক্ষণ করবেন?

আপনি কি গ্রাহকদের কাছ থেকে সমস্যার কথা শুনেছেন? আপনি কি মনিটরিং এবং লগিং থেকে ক্লায়েন্টকে ভালো বোঝেন? আপনি কি মনিটরিং এবং লগিং থেকে সিস্টেমটি ভাল বোঝেন? আপনি কি কেবল সিস্টেম পরিবর্তন করছেন কারণ আপনি দেখেছেন যে সিস্টেমে প্রবণতা বাড়ছে এবং আপনি বুঝতে পেরেছেন যে আরও 3 সপ্তাহের মধ্যে সবকিছু মারা যাবে?

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

অবকাঠামো প্ল্যাটফর্ম

বিষয়টা এমন নয় যে এটা আলাদা আলাদা টুলের সেট যা প্রতিটি কোম্পানির আছে।

একটি অবকাঠামো প্ল্যাটফর্মের বিষয় হল যে সমস্ত দল এই সরঞ্জামগুলি ব্যবহার করে এবং তাদের একসাথে বিকাশ করে।

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

সমস্ত দল অবকাঠামো প্ল্যাটফর্ম তৈরি করে এবং যত্ন সহকারে তাদের নিজস্ব IDE হিসাবে বিবেচনা করে. আপনার IDE-তে আপনি সবকিছু সুন্দর এবং দ্রুত করতে এবং হটকি কনফিগার করতে বিভিন্ন প্লাগইন ইনস্টল করেন। আপনি যখন সাব্লাইম, অ্যাটম বা ভিজ্যুয়াল স্টুডিও কোড খোলেন, কোড ত্রুটিগুলি ঢেলে দেওয়া হচ্ছে এবং আপনি বুঝতে পারেন যে এটি মোটেও কাজ করা অসম্ভব, আপনি অবিলম্বে দুঃখ বোধ করেন এবং আপনি আপনার IDE ঠিক করার জন্য দৌড়ান।

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

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

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

এই প্রকল্পটি

এটি একটি অবকাঠামো প্ল্যাটফর্মের একটি মৌলিক চিত্র যা আপনাকে একটি DevOps কোম্পানিতে সমস্ত অনুশীলন এবং প্রক্রিয়া সেট আপ করতে সাহায্য করবে৷

এর এটা কি গঠিত তাকান.

রিসোর্স অর্কেস্ট্রেশন সিস্টেম, যা অ্যাপ্লিকেশন এবং অন্যান্য পরিষেবাগুলিতে CPU, মেমরি, ডিস্ক সরবরাহ করে। এইটার উপরে - নিম্ন স্তরের পরিষেবা: মনিটরিং, লগিং, সিআই/সিডি ইঞ্জিন, আর্টিফ্যাক্ট স্টোরেজ, সিস্টেম কোড হিসাবে পরিকাঠামো।

উচ্চ স্তরের পরিষেবা: একটি পরিষেবা হিসাবে ডাটাবেস, একটি পরিষেবা হিসাবে সারি, একটি পরিষেবা হিসাবে লোড ব্যালেন্স, একটি পরিষেবা হিসাবে চিত্রের আকার পরিবর্তন করা, একটি পরিষেবা হিসাবে বিগ ডেটা ফ্যাক্টরি৷ এইটার উপরে - পাইপলাইন যা আপনার ক্লায়েন্টকে ক্রমাগত পরিবর্তিত কোড সরবরাহ করে.

আপনার সফ্টওয়্যার ক্লায়েন্টের জন্য কীভাবে কাজ করে সে সম্পর্কে আপনি তথ্য পাবেন, এটি পরিবর্তন করুন, এই কোডটি আবার সরবরাহ করুন, তথ্য পাবেন - এবং তাই আপনি ক্রমাগত অবকাঠামো প্ল্যাটফর্ম এবং আপনার সফ্টওয়্যার উভয়ই বিকাশ করেন।

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

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

প্ল্যাটফর্ম তৈরি

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

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

তোমার কী আছে?

আবার, প্রশ্ন আপনি নিজেকে জিজ্ঞাসা করতে পারেন.

অবকাঠামো প্ল্যাটফর্ম নিবেদিত? এর উন্নয়নের জন্য দায়ী কে? আপনি কি আপনার অবকাঠামো প্ল্যাটফর্মের প্রতিযোগিতামূলক সুবিধা বোঝেন?

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

তাই, DevOps...

... এটি একটি জটিল সিস্টেম, এটি অবশ্যই থাকতে হবে:

• ডিজিটাল পণ্য।
• ব্যবসায়িক মডিউল যা এই ডিজিটাল পণ্য বিকাশ করে।
• পণ্য দল যারা কোড লেখে।
• ক্রমাগত ডেলিভারি অনুশীলন।
• একটি পরিষেবা হিসাবে প্ল্যাটফর্ম.
• একটি পরিষেবা হিসাবে পরিকাঠামো.
• কোড হিসাবে পরিকাঠামো।
• নির্ভরযোগ্যতা বজায় রাখার জন্য পৃথক অনুশীলন, DevOps-এ অন্তর্নির্মিত।
• একটি প্রতিক্রিয়া অনুশীলন যা এটি সমস্ত বর্ণনা করে।

আপনি এই ডায়াগ্রামটি ব্যবহার করতে পারেন, এটিতে হাইলাইট করে যে আপনার কোম্পানিতে আপনার ইতিমধ্যে কোন আকারে যা আছে: এটি কি বিকাশিত হয়েছে বা এখনও বিকাশ করা দরকার।

এটা কয়েক সপ্তাহের মধ্যে শেষ হয়ে যাবে DevOpsConf 2019. RIT++ এর অংশ হিসেবে। কনফারেন্সে আসুন, যেখানে আপনি ক্রমাগত ডেলিভারি, কোড হিসাবে পরিকাঠামো এবং DevOps রূপান্তর সম্পর্কে অনেক দুর্দান্ত প্রতিবেদন পাবেন। আপনার টিকিট বুক করুন, শেষ মূল্যের সময়সীমা 20 মে

উত্স: www.habr.com