What is DevOps?

ধরুন আপনি IT management বা operations নিয়ে কাজ করেন। অফিসে, কনফারেন্সে, LinkedIn-এ হঠাৎ করে বারবার “DevOps” শব্দটা কানে এসেছে। Twitter-এ #DevOps হ্যাশট্যাগ, চারদিকে DevOps meetup আর DevOpsDays conference। মনে হচ্ছে সবাই হঠাৎ করেই এই টার্মটা নিয়ে উচ্ছ্বসিত।

আমি নিজেও প্রথম দিকে একটু অবাকই হয়েছিলাম, এত বছর ধরে তো Dev আর Ops আলাদা আলাদা কাজ করেই এসেছে, হঠাৎ DevOps কেন? আসলে DevOps একটা নতুন buzzword না, বরং খুব পুরোনো একটা সমস্যার নাম-ঠিকানা পাওয়া। development আর operations-এর মধ্যে যে অদৃশ্য দেয়াল ছিল, DevOps সেই দেয়ালটা ভাঙার গল্প।

এই লেখায় আমরা একদম শুরু থেকে দেখবো: DevOps আসলে কী, কেন এটা দরকার, business-এর জন্য এর লাভ কী, আর practically কীভাবে DevOps-কে জীবন্ত করা যায়।

DevOps আসলে কী নিয়ে?

DevOps মূলত সেই বাস্তব সমস্যার একটা জবাব, যেখানে বছরের পর বছর ধরে development আর operations-কে দুটো আলাদা দুনিয়া হিসেবে দেখা হয়েছে। একদিকে যারা কোড লেখে, ফিচার বানায়, দ্রুত চেঞ্জ আনতে চায়; তাদের কাজকে বলা হয় development activity।

অন্যদিকে যারা সার্ভার সামলায়, production stable রাখে, downtime কমায়; তাদের কাজ operations activity। বাস্তবে দেখা যায়, এই দুই দিকের মধ্যে একটা বড় গ্যাপ থেকে যায়, আর সেই গ্যাপটাই অনেক সময় ঝগড়া, blame-game আর প্রচুর অদক্ষতার (inefficiency) জন্ম দেয়।

Lee Thompson আর Andrew Shafer খুব সুন্দর করে এই সমস্যাটাকে “Wall of Confusion” নামে ডেকেছেন। তাদের ভাষায়, development আর operations-এর মাঝখানে একটা অদৃশ্য দেয়াল দাঁড়িয়ে আছে। এই দেয়াল তৈরি হয় মূলত তিনটা জিনিস থেকে। দুই দিকের motivation এক নয় (developer change চায়, ops stability চায়), process আলাদা, আর ব্যবহার করা tools-ও আলাদা।

ফলে দুই টিম একই product নিয়ে কাজ করলেও, একে অপরকে partner না ভেবে অনেক সময় “অন্য টিম” হিসেবেই দেখে আর DevOps culture ঠিক এই দেয়ালটা ভাঙার চেষ্টা করে।

What DevOps Is Really About?

যারা development side-এ কাজ করে, তাদের মানসিকতা অনেকটাই এমন: “আমাকে টাকা দেওয়া হচ্ছে change আনার জন্য”। নতুন feature বানানো, bug fix করা, UI আপডেট করা, নতুন experiment সবই তো চেঞ্জ। Business-ও তাদের কাছে ঠিক এই expectation নিয়েই আসে।

মার্কেট বদলাচ্ছে, customer-এর need বদলাচ্ছে, competition বাড়ছে অতএব তুমি দ্রুত চেঞ্জ আনো। ফলে তারা practically এমন একটা incentive structure-এ থাকে যেখানে যত বেশি change deliver করতে পারবে, ততই তারা “successful” বলে গণ্য হবে।

অন্যদিকে operations টিমের দৃষ্টিতে ঠিক উল্টো ছবি। ওনাদের baseline mindset হলো “change মানেই ঝামেলা”। business আজকে যে টাকাটা কামাচ্ছে, সেটা আসছে stable system, reliable service, কম downtime আর smooth operation থেকে। মানে তাদের primary কাজ হলো লাইট যেন অন থাকে, সার্ভিস যেন না ভাঙে।

তাই তাদের জন্য সবচেয়ে বড় priority হলো stability, uptime আর reliability। স্বাভাবিকভাবেই তারা change-কে অনেক সময় সন্দেহের চোখে দেখে, কারণ ছোট্ট একটা ভুল change-এর জন্যই তো বেশিরভাগ incident হয়। আমরা প্রায়ই শুনি একটা কথা: সব downtime-এর প্রায় ৮০% নাকি “self-inflicted change” থেকে আসে। মানে আমরা নিজেরাই change এনে নিজের সিস্টেম ভাঙি।

এখন মজার বিষয় হচ্ছে, দুই টিমের কেউ-ই কিন্তু নিজেদের জায়গা থেকে ভুল না। development টিম ভাবে, “আমি তো business-এর future growth আর innovation-র জন্য কাজ করছি”। আর operations ভাবে, “আমি তো আজকের revenue, brand reputation আর customer trust বাঁচিয়ে রাখছি”।

দুই টিম-ই business-এর ভালোর জন্য কাজ করছে এবং আলাদা করে দেখলে, দুজনই ঠিক! সমস্যা হয় তখন, যখন এই দুইটা worldview একে অপরের সাথে কখনো properly align হয় না।

এর উপরে আরেকটা complication যোগ হয় organization structure থেকে। বেশিরভাগ কোম্পানিতেই development আর operations আলাদা department-এ পড়ে, আলাদা manager, আলাদা লক্ষ্য, আলাদা KPI, এমনকি অনেক সময় আলাদা শহর বা দেশে থাকে।

একদিকে different org chart আর internal politics, অন্যদিকে ভিন্ন ভৌগোলিক location সব মিলিয়ে collaboration-এর জায়গায় “আমরা VS ওরা” culture তৈরি হয়ে যায়। আর ঐ ভুল-বোঝাবুঝি আর দূরত্ব থেকেই ধীরে ধীরে সব বড় বড় DevOps সমস্যার সূত্রপাত হয়।

“Wall of Confusion” টা আরও পুরু হয়ে যায় আরেকটা কারণে তাহলো development আর operations সাধারণত একদম আলাদা ধরণের tools ব্যবহার করে। আপনি যদি একটু লক্ষ্য করেন, developer-রা প্রতিদিন যেসব popular tools চায় আর ব্যবহার করে, আর অন্যদিকে system administrator / ops টিম প্রতিদিন যেসব tools নিয়ে কাজ করে এই দুই তালিকা প্রায়ই একে অন্যের থেকে সম্পূর্ণ আলাদা।

Bug tracker বা SCM (git, ইত্যাদি) ছাড়া বাকি জায়গায় খুব কমই overlap পাওয়া যাবে। এমনকি যে ধরনের কাজের জন্য দু’পক্ষই tool ব্যবহার করছে, সেখানেও implementation আলাদা, integration নেই বললেই চলে। ফলে টুলিং-এর mismatch-ও “আমরা VS ওরা” মানসিকতাকে আরও শক্ত করে।

এই “Wall of Confusion” সবচেয়ে বেশি চোখে পড়ে যখন আসল কাজের সময় মানে application-এর change production-এ নেওয়া হয়। কেউ একে “release” বলে, কেউ “deployment” বলে, কিন্তু সবাই একমত যে এই phase-এ ঝামেলা হবার সম্ভাবনা খুব বেশি। নিচের scenario টা খুব generalized, কিন্তু আপনি যদি কখনও এই প্রক্রিয়ার অংশ হয়ে থাকেন, তাহলে একেবারে চেনা চেনা লাগবে।

সাধারণত গল্পটা এমনভাবে শুরু হয়, development টিম এক সময়ে তাদের software release-টা “ওয়ালের ওপাশে” operations টিমের দিকে ছুঁড়ে দেয় মানে “হয়ে গেছে, এবার তোমাদের কাজ” টাইপ হ্যান্ডওভার। Ops টিম release artifacts নিয়ে deployment-এর প্রস্তুতি শুরু করে।

তারা হয়তো developers-দের দেওয়া deployment script গুলো production-এর জন্য হাতে হাতে এডিট করে, নাহয় একেবারে নিজেরা নতুন script লিখে ফেলে। সেই সাথে production environment-এর জন্য configuration ফাইলগুলোও manually চেঞ্জ করে, কারণ production-এর setup অনেকটাই ভিন্ন হয় Development বা QA environment থেকে। Best case-এ তারা আগের environment-এ করা কাজ আবার নতুন করে duplicate করছে, আর worst case-এ এখানেই নতুন bug introduce হবে বা লুকানো bug বের হয়ে আসবে।

এরপর Ops যা বোঝে “current deployment process”, সেটা follow করে actual deployment শুরু হয়। কিন্তু আসল সত্যি হলো Development আর Operations-এর script, configuration, process আর environment-এর পার্থক্যের কারণে এই পুরো deployment process-টা practically প্রথমবারের মতোই execute হচ্ছে।

স্বাভাবিকভাবেই মাঝপথে একটা না একটা problem দেখা দেয়, আর তখনই developer-দের ডেকে আনা হয় issue troubleshoot করতে। Ops টিম বলে, “তোমরা যে artifacts দিয়েছো, ওটাতেই সমস্যা ছিল”। Developer পাল্টা বলে, “আমাদের environment-এ তো সব ঠিকঠাক চলছিল, নিশ্চয়ই তোমরা deployment-এর সময় কিছু গড়বড় করেছো”।

Developer-দের জন্য আবার আরেক ঝামেলা হয় debugging-এ। কারণ production-এর configuration, file location আর যে procedure follow করে এই current state-এ আসা হয়েছে; সবকিছুই তাদের known setup থেকে আলাদা। অনেক সময় তো security policy-র কারণে তাদের production server-এ লগইন করার অনুমতিই থাকে না। ফলে তারা যেন চোখ বেঁধে diagnose করতে বসে আছে এমন অবস্থা।

এরই মধ্যে change window-র সময় শেষ হয়ে আসছে, আর দুর্ভাগ্যবশত environment-টাকে একটা known good state-এ clean rollback করারও কোনো dependable উপায় নেই। ফলে যা হওয়ার তাই হয়; যেটা ideally হওয়া উচিত ছিল একদম quiet, eventless deployment, সেটা পরিণত হয় all-hands-on-deck ধরনের fire drill-এ।

সবাই মিলে রাত জেগে, trial & error করে, কখনো script পাল্টায়, কখনো সার্ভারে সরাসরি edit করে production environment-কে কোনোভাবে usable অবস্থায় এনে দাঁড় করায়।

Deployment-এর সময় এই কষ্টটাই সবচেয়ে বেশি চোখে পড়ে। কিন্তু DevOps-এর প্রয়োজনীয়তা শুধু deployment পর্যন্তই সীমাবদ্ধ না। John Allspaw খুব পরিষ্কার করে বলেন, development আর operations-এর মধ্যে cooperation আসলে deployment-এর অনেক আগে থেকেই শুরু হওয়া উচিত, আর deployment শেষ হওয়ার পরও অনেক দূর পর্যন্ত চলতে থাকে। মানে architecture design থেকে শুরু করে monitoring, incident response, feedback loop সব জায়গাতেই Dev আর Ops-এর alignment দরকার। শুধু “শেষ মুহূর্তের deploy নাইট” এ একসাথে হওয়া দিয়ে কাজ চলে না।

DevOps কেন এত শক্তিশালী একটা ধারণা?

DevOps-এর পাওয়ারফুল দিকটা হলো, এটা একসাথে অনেকগুলো লেভেলে মানুষের সাথে resonate করে। শুধু management-এর jargon না, যারা প্রতিদিন হাতে কলমে code লিখছে বা production সামলাচ্ছে সেই real-life developers আর operations engineers-দের জন্যও DevOps একটা আশার জায়গা।

Hands-on development বা operations role-এ যারা কাজ করেন, তাদের দৃষ্টিতে DevOps মানে হলো সেই সব ঝামেলার উৎসকে কমিয়ে আনা, যেগুলোর কারণে প্রতিদিনের কাজটা অকারণে কঠিন হয়ে যায়। এটা কোনো magic বা “এক রাতে সব বদলে যাবে” টাইপ solution না, কিন্তু DevOps নিয়ে properly কাজ করতে পারলে আপনি বড় বড় কিছু বাধা সরাতে পারবেন, যেগুলো একদিকে team-এর প্রচুর সময় নস্ট করে, আর অন্যদিকে morale বা motivation একেবারে শেষ করে দেয়।

সহজ হিসাব: যত বেশি DevOps reality বানাতে invest করতে পারবেন, ততই টিম হবে efficient, দ্রুত move করতে পারবে, আর ফালতু frustration কমবে। কেউ বলতে পারে DevOps খুব উচ্চাভিলাষী বা বাস্তবে করা মুশকিল তাই “চেষ্টা না করাই ভালো” এমন argument দাঁড় করানো খুব কঠিন।

Business-এর দিক থেকে দেখলে DevOps সরাসরি দুইটা স্ট্র্যাটেজিক গুণকে enable করে যেমন “business agility” আর “IT alignment”। IT-তে যারা trench-এ বসে কাজ করে, তারা হয়তো প্রতিদিন এসব শব্দ নিয়ে ভাবেন না, কিন্তু বাজেট approve করা আর cheque-এ সাইন করার সময় decision-makers / executives-দের জন্য এসব শব্দ খুবই গুরুত্বপূর্ণ।

IT alignment-কে সহজভাবে বলা যায় এমন এক অবস্থা, যেখানে কোনো organization তাদের IT (information technology)-কে ঠিক এমনভাবে ব্যবহার করতে পারে, যাতে সেটা business-এর মূল objective পূরণে সরাসরি সাহায্য করে যেমন better financial performance, আরও competitive হওয়া, market-এ টিকে থাকা ও এগিয়ে যাওয়া ইত্যাদি।

DevOps এখানে কীভাবে হেল্প করে? DevOps development আর operations-এর role আর process-গুলোকে এমনভাবে align করে, যাতে দুজনই বুঝতে পারে তারা actually একটা shared business goal-এর অংশ। DevOps mindset-এ development আর operations আলাদা আলাদা silo (সাইলো) না, বরং একটা unified business process-এর দুইটা critical অংশ।

ফলে organizational structure যাই হোক না কেন, decision আর action-গুলো সবসময় এই প্রশ্ন দিয়ে filter হয়: “এটা কি আমাদের পুরো business flow-টাকে better করছে?”

এখন আসি agility-তে। Business context-এ agility মানে হচ্ছে, “একটা organization কত দ্রুত আর কতটা effective উপায়ে market আর environment-এর change-এর সাথে নিজেকে মানিয়ে নিতে পারে”। মানে নতুন সুযোগ এলে তাড়াতাড়ি ধরতে পারা, ঝুঁকি এলে দ্রুত respond করতে পারা, আর সবকিছু করতে গিয়ে unproductive chaos তৈরি না করা।

Developers-দের কাছে আবার “Agile” শব্দটার আলাদা একটা technical মানে আছে যেমন Agile development methodologies, Scrum, iteration, feedback loop ইত্যাদি। এর মূল উদ্দেশ্য হলো software development-কে customer আর company-র real goal-এর সাথে aligned রাখা, আর changing requirements-এর মাঝেও high quality software deliver করতে পারা।

অনেক organization-এ Agile মানেই যেন Scrum। ছোট ছোট sprint, backlog, daily standup, review আর retrospective এগুলোই তাদের কাছে Agile-এর সবচেয়ে দৃশ্যমান অংশ।

Agile-এর প্রতিশ্রুতি কী?

খুব সহজ করে বললে, একটা ভালো Agile টিমে দুইদিকের মানুষকে খুব কাছে (communication, feedback, response) থাকতে হয়।

• একদিকে থাকে business stakeholder-রা, যারা সিদ্ধান্ত নেয় “আমরা কী বানাবো, কেন বানাবো”।
• আরেকদিকে থাকে developers, যারা সেই সিদ্ধান্তকে কোডে রূপ দেয়

এদের মধ্যে যদি দ্রুত feedback আদান-প্রদান আর নিয়মিত যোগাযোগ থাকে, তাহলে বাইরে থেকে টিমের কাজ দেখলে একটা জিনিস স্পষ্ট বোঝা যায়। আর তা হলো তাদের output ধীরে ধীরে কিন্তু ধারাবাহিকভাবে better হচ্ছে, আর সেটা business-এর আসল প্রয়োজনের সাথেই তাল মিলিয়ে চলছে।

কিন্তু একটু zoom-out করে যখন পুরো lifecycle-টাকে enterprise perspective থেকে দেখা হয় অর্থাৎ development থেকে operations পর্যন্ত পুরো application lifecycle তখন প্রায়ই দেখা যায় Agile-এর এই সুন্দর স্ট্রিম-টা মাঝপথে হারিয়ে যায়। “Wall of Confusion”-এর কারণে lifecycle-টা effectively দুই ভাগ হয়ে যায়। Development তাদের গতিতে দৌড়াচ্ছে, Operations আবার একেবারে আলাদা গতিতে হাঁটছে।

ফলাফল কী হয়?

Production release-এর gap অনেক বড় হয়ে যায়। Deployments হয় তিন মাস, ছয় মাস, এক বছর পর পর আর এই দীর্ঘ cycle Agile-কে practically আবার waterfall-এ ফিরিয়ে নিয়ে যায়। আপনি যতই বলুন “আমরা তো pure Agile করছি’, developer side-এ যতই sprint, backlog, demo থাকুক কিন্তু যদি production-এ code পৌঁছাতে মাসের পর মাস লাগে, তাহলে business-এর চোখে এটা আবার সেই পুরোনো ধীরগতির waterfall lifecycle-এর মতোই দেখাবে।

Wall of Confusion থাকলে একটা heavy, slow-moving business-কে সত্যিকার অর্থে Agile বানানো প্রায় অসম্ভব। Andrew Rendell-এর একটা সুন্দর গল্প আছে যেখানে তিনি দেখিয়েছেন কীভাবে org-এর heavy release process Agile development-কেই আবার waterfall-এর মতো করে ফেলেছিল।

DevOps-এর আসল beauty এখানেই। এটা Agile development-এর benefit-গুলোকে পুরো organization level-এ পৌঁছে দিতে পারে। DevOps এমন একটা operating model তৈরি করে, যেখানে operations team একদিকে fast আর responsive থাকতে পারে, অন্যদিকে stability আর reliability-ও বজায় থাকে।

আর এই operations-এর speed-টা development-এর innovation-এর সাথে sync থাকে। মানে Dev এর side থেকে যেই গতিতে নতুন চেঞ্জ আসছে, ops এর দিক থেকে ঠিক সেভাবেই তার সঙ্গে তাল মিলিয়ে deliver করতে পারছে।

তাই আপনি যদি নিজের organization-এ DevOps নিয়ে কাজ শুরু করতে চান বা নতুন করে DevOps initiative propose করতে চান, তাহলে “IT alignment” আর “business agility” এই দুইটা শব্দ কিন্তু মাথায় রাখতেই হবে। শুধু টুলের নাম, automation, pipeline-এর গল্পে আটকে থাকলে হবে না। Decision-maker-দের বোঝাতে হবে, DevOps আসলে তাদের business-কেই আরও aligned, আরও agile আর আরও competitive করে তুলতে পারে।

How Do We Bring DevOps to Life in Real Organizations?

বেশিরভাগ নতুন ধরণের টপিকের মতোই, DevOps-এর ক্ষেত্রেও একটা জিনিস খুব স্পষ্ট। সমস্যা নিয়ে প্রায় সবাই একমত, কিন্তু সমাধান নিয়ে পরিষ্কার consensus পাওয়া অনেক কঠিন।

আজকাল DevOps নিয়ে যে আলোচনা-বিতর্ক হচ্ছে, সেখানে সাধারণভাবে তিনটা বড় ফোকাস এরিয়া দেখা যায়, যেগুলোর চারপাশেই বেশিরভাগ DevOps solution ঘুরে ফিরে আসে।

১. Measurement – আর incentives দিয়ে culture change আনা

কোনো organization-এর culture বদলানো, আর তার সাথে reward system পাল্টানো কখনই সহজ কাজ না। কিন্তু এই পরিবর্তন না আনতে পারলে DevOps-এর আসল promise-টা পূরণ করা প্রায় অসম্ভব হয়ে যায়।

Business-এর ভিতরে culture-এ প্রভাব ফেলতে চাইলে প্রথমে আপনাকে খুব কেয়ারফুলি দেখতে হবে আপনি কীভাবে performance মাপছেন, আর কাকে কীভাবে judge করছেন। আপনি যা measure করেন, সেটাই আসলে লোকজনের behavior-কে drive আর incentivize করে।

Development থেকে শুরু করে Operations পর্যন্ত পুরো lifecycle-এ জড়িত সব টিমেরই পরিষ্কারভাবে বোঝা দরকার, তারা একটা বড় business process-এর অংশ। তাই individual আর team-এর success আলাদা silo-তে না মেপে, পুরো development-to-operations lifecycle কতটা সফল, তার context-এর ভেতরে measure করতে হবে।

অনেক organization-এর জন্য এটা একটা বড় shift। কারণ তারা আগে যেখানে প্রতিটা টিম আলাদা করে শুধু নিজের দৃষ্টিকোণ থেকে KPI আর success define করত, সেখানে এখন দরকার end-to-end view-এর ওপর ভিত্তি করে measure আর reward করা যেন সবাই একই shared flow-এর সফলতাকে নিজের সফলতা মনে করে।।

২. Unified processes – পুরো Dev থেকে Ops একটাই continuous প্রক্রিয়া

DevOps-এর আরেকটা গুরুত্বপূর্ণ থিম হলো development থেকে শুরু করে operations পর্যন্ত পুরো lifecycle-টাকে আলাদা আলাদা phase না ভেবে, একটা ধারাবাহিক end-to-end process হিসেবে দেখা।

এর মানে এই না যে সবাইকে একই methodology follow করতে হবে। Development দিক থেকে আপনি Agile বা Scrum follow করতে পারেন, আর operations দিক থেকে ITIL, Visible Ops বা অন্য কোনো ops framework ব্যবহার করতে পারেন, তাতে কোন সমস্যা নেই। শর্ত একটাই: আলাদা আলাদা এসব process যেন একে অন্যের সাথে plug হয়ে একটা unified flow তৈরি করতে পারে, আর সেই unified process-কেই যেন আপনি manage আর optimize করেন।

প্রতিটা organization-এর জন্য unified process ডিজাইন করার requirement আলাদা হবে; team structure, domain, risk, compliance ইত্যাদির ওপর ভিত্তি করে। কিন্তু end goal সবখানেই এক। এমন একটা common pipeline বা flow যেখানে planning, coding, building, testing, deploying, monitoring সবকিছুই একই business value stream-এর অংশ হিসেবে চলবে।

৩. Unified tooling – Dev আর Ops-এর মাঝে একই ভাষায় কথা বলা টুলচেইন

DevOps নিয়ে যত discussion, তার বড় একটা অংশ ঘোরে tooling নিয়ে। এটা খুব স্বাভাবিক, কারণ technologist হিসেবে আমরা problem দেখলেই প্রায়ই আগে tool নিয়েই কথা বলা শুরু করি।

Puppet, Chef, ControlTier-এর মতো community-গুলো ফলো করলে দেখবেন সেখানে অনেক ফোকাসই দেওয়া হচ্ছে কীভাবে development আর operations-এর মাঝের ফাঁকটা কমানো যায়। Infrastructure as code, model driven automation, continuous deployment এগুলো সবই DevOps mindset-এর ভেতরে পড়ে। এসব টুল আর প্যাটার্নের design নিয়ে toolsmith-দের আলাদা করে ভাবতে হয়, যাতে একদিকে flexibility থাকে, অন্যদিকে stability-ও নষ্ট না হয়।

এই প্রসঙ্গে Jake Sorofman DevOps tooling-এর জন্য যে তিনটা capability তুলে ধরেছেন, সেগুলো খুব কাজে দেয়:

A) Version-controlled software library
একটা central, version-controlled library থাকা দরকার, যেখানে system-এর সব ধরনের artifact (script, config, template, package ইত্যাদি) পরিষ্কারভাবে defined, শেয়ার করা আর up-to-date থাকে।

Development আর QA টিম একই platform version থেকে কাজ করবে, আর production-এ deploy হবে ঠিক সেই version-টাই যা QA already certify করেছে। এর ফলে ‘আমরা অন্য version-এ কাজ করছিলাম” টাইপ confusion কমে যায়, আর environment-এর মধ্যে consistency তৈরি হয়।

B) Deeply modeled systems
আরেকটা দিক হলো system-কে ভালোভাবে model করা। মানে একটা versioned system manifest থাকবে যেখানে পুরো software system-এর সব component, policy আর dependency clearly described।

এতে যেকোনো সময় পুরো system-টাকে আবার reproduce করা সহজ হয়, আর change introduce করার সময় conflict বা unexpected side-effect-এর ঝুঁকিও অনেক কমে যায়। নতুন environment সেটআপ করা হোক, নাকি existing system-এ change আনা হোক সবকিছু predictable আর repeatable থাকে।

C) Automation of manual tasks
Dependency discovery আর resolution, system construction, provisioning, update, rollback এসব জায়গায় যতটা সম্ভব manual কাজকে automation-এ নিয়ে আসা দরকার।

হাজার হাজার server বা container manage করার সময় “ম্যান পাওয়ার বাড়িয়ে নেওয়া” এর ওপর ভরসা না করে, automation-কেই command এবং control-এর মূল ভিত্তি করতে হবে। এতে high-velocity change, conflict-free deployment আর massive scale system administration একসাথে ম্যানেজ করা অনেক সহজ হয়ে যায়।

সবশেষে একটা ব্যাপার মনে রাখবেন: DevOps-এ যে টুলগুলো ব্যবহার করছেন, সেগুলোকে আলাদা আলাদা “একটা করে টুল” ভেবে দেখলে হবে না। প্রতিটা tool আসলে একটা বড় toolchain-এর অংশ, যেটা plan করা থেকে শুরু করে code করা, build, test, deploy হয়ে production-এ run করা পর্যন্ত পুরো Development-to-Operations lifecycle-এর ওপর দিয়ে একসাথে গেঁথে থাকে।

টুল নির্বাচন আর implementation-এর সিদ্ধান্ত (হোক সেটা পুরো toolchain লেভেলে, বা কোনো individual tool লেভেলে) সবসময় এই প্রশ্ন মাথায় রেখে দিতে হবে যে “এটা আমাদের end-to-end lifecycle-এ কী impact ফেলবে?”

মানে, শুধু “এই টুলটা cool লাগছে” বলে adopt করলে হবে না। পুরো Dev → Build → Test → Deploy → Run → Monitor flow-এর সাথে কতটা fit করে, সেটাই আসল DevOps success-এর জায়গা।

What DevOps Is Not: Common Myths and Misconceptions

একবার একটা OpsCamp ইভেন্টে OpsCode/Chef-এর Adam Jacob একধরনের frustration নিয়েই বলছিলেন, কিছু systems administrator নাকি এখন তাদের job title-টাই বদলে “DevOps” রাখতে চাইছে। প্রথমে সত্যি বলতে আমি একটু সন্দিহান ছিলাম, আসলেই নাকি এমন হচ্ছে! কিন্তু পরে দেখলাম, একাধিক জায়গায় সরাসরি মানুষজনকে বলতে শুনেছি তারা job title rewrite করতে চায়, বা organization-এর ভিতরে আলাদা করে “DevOps” নামে নতুন একটা role তৈরি করতে চায়।

উদাহরণ হিসেবে, Stephen Nelson-Smith DevOps নিয়ে দারুণ একটা লেখা লিখেছিলেন। তার বেশিরভাগ কথার সাথেই আমি একমত, কিন্তু একটা জায়গায় আমি জোর গলায় ভিন্ন মত দিই সেটা হলো, DevOps কোনো আলাদা ইউনিক পজিশন বা job title হওয়া উচিত এই ধারণাটা।

“DevOps”-কে যদি আপনি নতুন একটা job title বা special role বানিয়ে ফেলেন, তাহলে আসলে খুব ভুল একটা precedent সেট হয়ে যায়। তখন DevOps হয়ে যায় “অন্য কারও দায়িত্ব”। আপনি যদি DBA হন, সরাসরি বলতে পারবেন, “DevOps-এর চিন্তা আমার না, ওটা তো DevOps টিমের কাজ”। আপনি যদি security expert হন, তখনও আপনার সুবিধা, “DevOps তো ওদের issue, আমি শুধু security দেখি”। এইভাবে DevOps-এর মূল responsibility টা আস্তে আস্তে একটা আলাদা টিমের ঘাড়ে চাপিয়ে দেওয়া হয়, আর বাকি সবাই নিজ নিজ silo-তেই রয়ে যায়।

একটু অন্যভাবে ভাবুন: আপনি কি কখনো বলেন, “আমার একজন Agile ভাড়া করতে হবে”, বা “আমাকে একজন Scrum হায়ার করতে হবে”, বা “আমার একজন ITIL লাগবে”? নিশ্চয়ই না। আপনি বলেন “আমার এমন developer দরকার, যে Agile বোঝে”, “আমার এমন Project Manager দরকার, যে Scrum প্র্যাকটিস করতে পারে”, “আমার এমন systems administrator দরকার, যে ITIL-এর ধারণা রাখে”। মানে Concept আর methodology-গুলো মানুষের কাজের ভেতরে মিশে যায়, আলাদা job title হয়ে দাঁড়ায় না।

DevOps-ও ঠিক সেরকমই। এটা এমন একটা Mindset আর Practice Set, যেটা Developers, Testers, Project Managers, Sysadmins, Security Engineer সবার কাজের ভেতরে ঢুকে থাকা উচিত। DevOps আলাদা করে “একটা পজিশন” না, বরং পুরো টিমের কাজ করার ধরণ পাল্টে দেওয়ার একটা Culture।

Why Is It Called DevOps?

সম্ভবত “DevOps” নামটা এত জনপ্রিয় হওয়ার বড় কারণ এটা শুনতে catchy লাগে, আর মনে গেঁথে যায়। সবচেয়ে বড় কথা, আইডিয়াটার একটা সরল ভিজুয়াল চিত্র মাথায় উঠে আসে: Dev আর Ops-কে একসাথে আনলে যা দাঁড়ায়, সেটাই DevOps।

এই ধারণার জন্য কিন্তু আগে থেকেই অন্য নামও ব্যবহার করা হয়েছে যেমন Agile Operations, Agile Infrastructure, বা DevOps Squad (এই সাইটটি যেখানে আপনি এই বিষয়ক লেখা পড়ছেন)। অনেকে আবার একই ধারণায় পৌঁছেছেন কিন্তু “DevOps” নামটা ব্যবহার না করেই। Ernest Mueller-এর লেখালেখি বা John Allspaw আর John Hammond-এর বিখ্যাত টক “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr“ এগুলোর ভেতরেও DevOps চিন্তাধারাটা স্পষ্ট, যদিও তারা হয়তো তখন এই নামটা দিয়ে ডাকেননি।

ভালো হোক বা মন্দ, বাস্তবতা হলো “DevOps” নামটাই এখন মানুষের কল্পনায় জায়গা করে নিয়েছে। এই নামটাকে আসলে জনপ্রিয় করার পেছনে Patrick Dubois-এর অবদান অনেক বড়। উনিই “DevOps” টার্মটা জোরালোভাবে সামনে এনেছেন, প্রথম DevOps Days কনফারেন্স সফলভাবে আয়োজন করেছেন।

DevOps Engineer বলে লাভ কী, যদি DevOps না থাকে কাজে

শেষে একটা জিনিস পরিষ্কার করে বলি; সময়ের সাথে সাথে টার্ম বদলানো খুব নরমাল। আজকের বাস্তবতায় “DevOps Engineer” নামটাই বেশি প্রচলিত, অনেক কোম্পানি চাকরির বিজ্ঞাপনও দেয় এই টাইটেলেই। এতে পৃথিবী ধ্বংস হয়ে যায় না, কিন্তু খেয়াল না রাখলে ধীরে ধীরে DevOps-এর আসল উদ্দেশ্যটাই হারিয়ে যেতে পারে।

আমার কাছে ব্যাপারটা বরং এমন: আপনি নিজেকে DevOps engineer বলছেন কি না, তার চেয়ে অনেক বেশি গুরুত্বপূর্ণ হলো আপনি আসলে DevOps-এর mindset-টা follow করছেন কি না। মানে আপনি কি Dev আর Ops-এর মধ্যে দেয়াল কমানোর চেষ্টা করছেন? আপনি কি Automation, Continuous Delivery, Measurement আর Feedback-কে সিরিয়াসলি নিচ্ছেন? আপনি কি নিজের কাজকে “আমার টিম VS ওদের টিম” না ভেবে, একটাই Shared value stream হিসেবে দেখছেন?

তাই যদি কোনো কোম্পানি Role-এর নাম দেয় “DevOps engineer”, তাতে সমস্যা নেই। তাই টাইটেল নিয়ে holy war, flame war বা টেক যুদ্ধ শুরু করার দরকার নেই – আসল প্রশ্ন হলো, কাজের ভেতরে DevOps আছে কিনা। শুধু খেয়াল রাখবেন, DevOps যেন শুধু নামে না থাকে, কাজের মধ্যেও থাকে। আর যদি কখনও সুযোগ পান, টিমের মধ্যে এই কথাটাও ছড়িয়ে দিন: DevOps মূলত Culture আর Collaboration-এর নাম, আর Job Title হলো শুধু একটা লেবেল, এর উল্টোটা না হলেই হলো।