DevOps vs Programming 🤔

“DevOps Engineer হতে গেলে প্রোগ্রামিং/কোডিং জানা লাগে না।”

এই ধারণাটা ইদানীং শুনতে পাচ্ছি মাঝে মাঝে। শেষ গত সপ্তাহেও সরাসরি আবার একটা প্রশ্ন পেলাম এরকম, “ভাই আমার কোডিং/প্রোগ্রামিং করতে ভাল লাগে না। কিন্তু শুনেছি DevOps হতে গেলে এইসব কিছু লাগে না। আমাকে সাজেশন দেন কিভাবে DevOps Engineer হতে পারব।” তার প্রতি আমার প্রথম সাজেশন ছিল, “যে কোন একটা প্রোগ্রামিং ল্যাঙ্গুয়েজ ব্যাসিক শিখে আসেন, তারপর বাকি সাজেশন দিব।” :)

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

DevOps টার্মটা প্রথম আলোচনায় আসে ২০০৭-২০০৮ এর দিকে। সেই সময়কার আগ পর্যন্ত মাঝারি থেকে বড় কোম্পানিগুলোতে নতুন সফটওয়্যারে কাজ শেষ হলে অথবা চলমান সফটওয়্যারে নতুন ফিচারের কাজ সম্পন্ন হলে সেই পরিবর্তন সার্ভারে আপলোড বা ডেপ্লয় করার জন্য আলাদা IT specialist মানুষ থাকত। যাদেরকে সাধারণত সিস্টেম/অপারেশন ইঞ্জিনিয়ার বা সংক্ষেপে Ops বলা হত। যাদের প্রোগ্রামিং না জানা থাকলেও চলত। তারা মুলত লিনাক্স/ইউনিক্স অথবা অন্যান্য অপারেটিং সিস্টেম সম্পর্কে ভাল ধারণা রাখত এবং কমান্ড লাইন ইন্টারফেসে সাবলীলভাবে কাজ করতে পারত। নতুন সফটওয়্যার ডেপ্লয় দেয়ার সময় সফটওয়্যার ডেভেলপার আর অপারেশন পার্সনদের সাথে এক রকমের দ্বন্দ্ব চলত। কারণ স্বাভাবিকভাবেই সফটওয়্যার ডেভেলপার নতুন একটা কাজ শেষ করলে সে চাইবে তার করা নতুন কাজটা যেন খুব দ্রুত প্রোডাকশন সিস্টেমে চলে যায়। নিজের কাজ করা সফটওয়্যার কাস্টমাররা ব্যবহার করা শুরু করলে একটা আনন্দদায়ক অনুভূতি আসে। এবং আগের কাজ প্রোডাকশন সিস্টেমে না যাওয়া পর্যন্ত নতুন কাজ শুরু করার জন্য অপেক্ষা করা লাগত। অন্যদিকে, অপারেশন পার্সনদের দায়িত্ব ছিল পুরো সিস্টেম যাতে সব সময় সচল থাকে। তাই নতুন একটা পরিবর্তন ডেপ্লয় দিতে গেলে তারা অনেক সতর্ক থাকত বা সহজে ডেপ্লয় দিতে চাইত না। কারণ সফটওয়্যার ডেভেলপারদের কাজ করা পরিবর্তনে যদি নতুন কোন সমস্যা আসে তাহলে অপ্স পার্সনকেই সব হ্যান্ডল করতে হবে, যেহেতু সার্ভারের দায়িত্ব তাদের হাতে। এদিকে নতুন সমস্যা আসবে নাকি আসবে না সেই ব্যাপারে অপ্স পার্সনের কোন ধারণাই নেই, কারণ কোড তো লিখেছে সফটওয়্যার ডেভেলপার। নিরাপত্তার কথা ভেবে আবার সফটওয়্যার ডেভেলপারদের কাছে সার্ভারের অ্যাক্সেস থাকত না, তাই তারা সহজে জানতে পারতো না কোথায় সমস্যা আর কি সমাধান করতে হবে। ফলে দুই পক্ষের মধ্যে এক রকমের সংঘর্ষ লেগেই থাকত। সফটওয়্যারের অজানা সমস্যা দ্রুত খোঁজার জন্য, দুই পক্ষের দ্বন্দ্ব আর নির্ভরতা দূর করার জন্যই আসলে DevOps টার্মের জন্ম। এখানে Development and Operations কে সংক্ষেপে DevOps বলা হয়।

DevOps এর কয়েকটা নীতির মধ্যে একটা হচ্ছে “সহযোগিতা”। এক পক্ষ কাজ শেষ করে যাতে বলতে না পারে, “আমার কাজ শেষ, এইবার তোমারটা তুমি সামলাও“। এই ধরনের অবস্থা দূর করার জন্য DevOps মাইন্ডসেট অনুশীলন করা যায়। যিনি সিস্টেম নিয়ে কাজ করছেন যে যদি ডেপ্লয়মেন্ট প্রসেসটা অটোমেট করতে পারে, যাতে সফটওয়্যার ইঞ্জিনিয়ারদের কাজ শেষ হলে কিছু ইভেন্ট এর উপর ভর করে ডেপ্লয়মেন্টটা যাতে অটোমেটিক হয়ে যায়। এই “অটোমেশন” হচ্ছে DevOps এর আরেকটা নীতি। যে সব কাজ বারবার একই ধাপে করতে হয় সেটা করার জন্য যাতে কোন ব্যাক্তির উপর নির্ভর করা না লাগে। যত সম্ভব অটোমেশন করতে হবে, আর এই অটোমেশন করতে গেলে কোডিং দক্ষতা লাগবেই। এই রোলে যিনি কাজ করছেন তার আরো দায়িত্ব হচ্ছে সফটওয়্যার ডেভেলপারদের তাদের প্রোজেক্টের সম্পূর্ণ স্বত্ব গ্রহণ করতে সাহায্য করা। পুরো সিস্টেমকে নিরাপদ রেখে সমস্ত লগ, ইভেন্ট ও অন্যান্য আচরণ যেন ডেভেলপাররা দেখতে পায় সেটা অটোমেশন করে তাদেরকে সহযোগিতা করা। যাতে যে কোন বাগ/সমস্যা হলে ডেভেলপাররা কোন অপ্স পার্সনের উপর নির্ভর না করেই নিজেরা সমস্যা চিহ্নিত করতে পারে। সমস্যা খুঁজে পেলে এবং ফিক্স করা হলে অটোমেটেড সেই ইভেন্ট এর উপর ভর করে আবার প্রোডাকশন সিস্টেমে সমাধান চলে যাবে। এই সমস্ত সত্ত্ব ডেভেলপারদের দিতে গেলে, অথবা পুরো পাইপলাইনটা অটোমেট করতে গেলে সেই কাজগুলো একজন DevOps/SRE/Platform Engineer অবশ্যই সেটা কোডিং এর মাধ্যমে সম্পাদন করবে। এছাড়া সমস্ত সিস্টেমের বর্তমান অবস্থা, পরিবর্তন ইত্যাদি সংরক্ষণ করার জন্যও কোডিং করা লাগে যেটা IaC (Infrascture as Code) নামে পরিচিত।

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

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

আশা করি DevOps সম্পর্কে আমি কি ধারণা পোষণ করি সেটা বুঝাতে পেরেছি। এই DevOps কালচার/মাইন্ডসেট অনুশীলন করতে পারলে অনেক গতানুগতিক সমস্যা সমাধান করা সম্ভব। এবং প্রাসঙ্গিক কোন রোলে (DevOps/SRE/Platform Engineer) কাজ করতে গেলে কোডিং এর বিকল্প নেই। আমার ব্যক্তিগত পরামর্শ হবে আগে ব্যাক-এন্ড সিস্টেমের সাথে অন্তত ২-১ বছর কাজ করা। তাহলে ওয়েব অ্যাপ্লিকেশন, নেটওয়ার্ক, সিস্টেম আর্কিটেকচার সম্পর্কে ভাল ধারণা হবে। এর পরে DevOps প্রাসঙ্গিক কোন জবে কাজ করতে গেলে সফটওয়্যার ডেভেলপমেন্ট টীমকে খুব ভাল সাপোর্ট দেয়া যাবে। আর যারা অপারেটিং সিস্টেম কিভাবে কাজ করে এই সম্পর্কে ব্যাসিক ধারণা রাখে আর কমান্ড লাইন ইন্টারফেসে কাজ করতে পারে তাদের জন্য প্রোগ্রামিং শিখা খুব সহজ ব্যাপার। তাই প্রোগ্রামিং না শিখে নিজেকে পিছনে ফেলে রেখে লাভ কি?

প্রোগ্রামিং না শিখে যদি কেউ DevOps ইঞ্জিনিয়ার হতে চায় তাহলে বুঝতে হবে তারা ১৫ বছর আগের সেই Ops রোলটা নিতে চাচ্ছে, যেখানে সব সময় একটা দ্বন্দ্ব বিরাজ করত। তবে সত্যি কথা বলতে যেই কোম্পানিগুলো DevOps টার্ম সম্পর্কে ভাল ধারণা রাখে তারা ১৫ বছর পিছনে গিয়ে প্রোগ্রামিং না জানা কাউকে এই সম্পর্কিত রোলের জন্য হায়ার করবে না। অনেক টিউটোরিয়াল ইদানীং বের হচ্ছে.. যেখানে শুধুমাত্র ডকার, কুবারনেটিস, CI/CD ব্যাসিক নিয়ে ধারণা দিয়েই DevOps Engineer বানিয়ে দেয়ার স্বপ্ন দেখানো হয়। কিছু কোম্পানি হয়ত এরকম রোল অফারও করতে পারে যেখানে ক্যান্ডিডেটের প্রোগ্রামিং জ্ঞান না থাকলেও চলবে। এরকম প্রচুর কোম্পানিতে অল্প কয়েক মাসের কাজের অভিজ্ঞতাতেই “সিনিয়র” টাইটেলও দিয়ে দেয়া হয়। তাই আপনাকে সিদ্ধান্ত নিতে হবে আপনার কি এমন লোভনীয় “DevOps Engineer” রোল বা টাইটেল দরকার? নাকি ভাল, শক্ত, মজবুত ও ফিউচার-প্রুফ একটা ক্যারিয়ার দরকার?

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