DevOpsForum 2019। আপনি DevOps বাস্তবায়নের জন্য অপেক্ষা করতে পারবেন না

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

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

Raiffeisenbank, Alfastrakhovanie, অটোমেশন বাস্তবায়নে ম্যাঙ্গো টেলিকমের অভিজ্ঞতা এবং কাটের অধীনে অন্যান্য বিবরণের বক্তৃতার একটি অংশ।

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

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

Raiffeisenbank এ পাইপলাইনের শেষে আলো

সাধারণত, আমি সাইডলাইনে স্পিকার খুঁজি যা আমার আগ্রহের। DevOpsForum 2019-এ, Raiffeisenbank-এর একজন স্পিকার, Mikhail Bizhan, আমার আগ্রহ নিয়েছিলেন। তার বক্তৃতার সময়, তিনি কীভাবে ধীরে ধীরে তাদের দলগুলিকে DevOps-এ আবদ্ধ করে চলেছেন, কেন তাদের এটি প্রয়োজন এবং কীভাবে DevOps রূপান্তরের ধারণাটি ব্যবসায় বিক্রি করা যায় সে সম্পর্কে কথা বলেছেন। ঠিক আছে, সাধারণভাবে, আমি পাইপলাইনের শেষে কীভাবে আলো দেখতে হয় সে সম্পর্কে কথা বলেছি।

মিখাইল বিজান, রাইফিজেনব্যাঙ্কের অটোমেশন ডিরেক্টর

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

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

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

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

ম্যাঙ্গো টেলিকমে পরীক্ষার অটোমেশন

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

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

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

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

উপস্থাপনাগুলির মধ্যে, আমি সম্মেলনের অংশীদারদের বুথের চারপাশে হেঁটেছি এবং প্রচুর জিনিস চুরি করেছি/জিতেছি। ওহ, আমি হ্যান্ডআউট ভালোবাসি!

Alfastrakhovanie-এ উন্নয়ন পরিচালকের সাথে গোল টেবিল এবং DevOps সমস্যা

আমার জন্য DevOpsForum 2019 কেকের আইসিং ছিল DevOps বিশেষজ্ঞদের সাথে ঘন্টাব্যাপী পূর্ণাঙ্গ অধিবেশন। চারজন সেশনের অংশগ্রহণকারীকে বিভিন্ন কোণ থেকে DevOps দেখার জন্য আমন্ত্রণ জানানো হয়েছিল: আন্তন ইসানিন (আলফাস্ট্রাখোভানি, ডেভেলপমেন্ট ডিরেক্টর), নাইলিয়া জামাশকিনা (ফিনটেক ল্যাব, অপারেটিং ডিরেক্টর), ওলেগ এগোরকিন (রোস্টেলেকম, এজিল কোচ) এবং অ্যান্টন মার্টিয়ানভ (স্বাধীন বিশেষজ্ঞ, ডেভঅপস দেখেছেন) ব্যবসায়িক দৃষ্টিকোণ থেকে)।

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

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

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

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

উত্স: www.habr.com