DevOps আর SRE — culture, CALMS, three ways আর দলের গঠন

১ · দেয়ালের দুই পাশ — Dev বনাম Ops

এতক্ষণ আপনি cloud-এর যন্ত্র দেখেছেন: service model, region, CLI. এই পর্বে যন্ত্র নয়, মানুষ। কারণ cloud শুধু server ভাড়া দেয়; সেই server-এ কে কোড পাঠাবেন, রাতে সমস্যা হলে কে উঠবেন, ভুল হলে কী ঘটবে, তা ঠিক করে দল আর সংস্কৃতি।

Software Engineering ও Git কোর্সের Continuous delivery আর DevOps পর্বে deployment pipeline আর চারটি DORA metric পড়ানো হয়েছে; এক লাইনে, pipeline হলো পরিবর্তন যাচাইয়ের স্বয়ংক্রিয় পথ, আর DORA metric delivery-র গতি আর স্থিতি মাপে। এখানে আমাদের প্রশ্ন আলাদা: কোন দল কী করবে, কাজ কীভাবে হাতবদল হবে, আর operating model (দল চালানোর নকশা) কেমন হবে।

Software প্রতিষ্ঠানে একই ঘটনা। Development (Dev) দলের সাফল্য মাপা হয় নতুন feature দিয়ে। Operations (Ops) দলের সাফল্য মাপা হয় system চালু থাকা দিয়ে, আর পরিবর্তনই ঝুঁকির বড় উৎস। তাই Ops পরিবর্তন আটকাতে চান, Dev ঠেলতে চান। প্রতিটি দল আলাদা একটি silo (নিজের গণ্ডিতে আটকে থাকা দল) হয়ে যায়। এই পরিস্থিতিকেই প্রচলিত ভাষায় “wall of confusion” বলা হয়।

২ · হাতবদল আর অপেক্ষা — lead time হলো কাজ + সারি

দেয়ালের দামটি কোথায় দেওয়া হয়? সময়ে। Lead time মানে একটি পরিবর্তনের কাজ শেষ হওয়া থেকে ব্যবহারকারীর হাতে পৌঁছানো পর্যন্ত সময়। (কেউ কেউ কাজ শুরুর মুহূর্ত থেকে গোনেন; সংজ্ঞা লিখে রাখা জরুরি।) সরকারি অফিসের ফাইলের কথা ভাবুন। একটি সই করতে লাগে দুই মিনিট, অথচ ফাইল ঘোরে তিন সপ্তাহ, কারণ প্রতিটি টেবিলে সেটি স্তূপের নিচে অপেক্ষা করে। Software-এও প্রতিটি handoff (এক দল থেকে আরেক দলে কাজ যাওয়া) মানে আরেকটি সারি।

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

কেন ব্যস্ত দলে সারি এত লম্বা হয়? The Phoenix Project বইয়ে একটি সহজ নিয়ম আছে: অপেক্ষা ব্যস্ততার হারের সাথে বাড়ে, আর খালি থাকার হারের সাথে কমে। সারি-তত্ত্বের (queueing theory) সরল একটি মডেলে, এলোমেলোভাবে কাজ আসা একজন কর্মীর জন্য:

এই সূত্র মোটা হিসাব, নির্ভুল পূর্বাভাস নয়। তবু আকারটি সত্য: ব্যস্ততা ১০০%-এর কাছে গেলে অপেক্ষা হঠাৎ লাফিয়ে বাড়ে। Flow efficiency মানে মোট সময়ের কত ভাগ আসল কাজ। নিচের simulator-এ সংখ্যা বদলে নিজে দেখুন।

// Lead time = work + queues. Change the numbers and press Run again.
// Rough queue model: wait = work * busy / (1 - busy), 8-hour working day.
const silos = [
  { step: "Code review",  work: 2, busy: 0.80 },
  { step: "QA team",      work: 4, busy: 0.90 },
  { step: "Security",     work: 2, busy: 0.85 },
  { step: "Ops ticket",   work: 1, busy: 0.95 },
];
const oneTeam = [
  { step: "Peer review",  work: 1.0, busy: 0.60 },
  { step: "Auto pipeline", work: 0.5, busy: 0.50 },
  { step: "Self deploy",  work: 0.2, busy: 0.30 },
];
function report(title, steps) {
  let work = 0, wait = 0;
  console.log("--- " + title + " ---");
  console.log("step           work  busy    wait");
  for (const s of steps) {
    const q = s.work * s.busy / (1 - s.busy);
    work += s.work; wait += q;
    console.log(s.step.padEnd(14) + s.work.toFixed(1).padStart(4) +
      (Math.round(s.busy * 100) + "%").padStart(6) + q.toFixed(1).padStart(8));
  }
  const lead = work + wait;
  console.log(`lead ${lead.toFixed(1)} h = ${(lead / 8).toFixed(1)} days, ` +
    `flow efficiency ${(100 * work / lead).toFixed(0)}%`);
}
report("Separate silos", silos);
report("One product team", oneTeam);
console.log("--- QA queue alone (4 h of work) ---");
for (const b of [0.5, 0.7, 0.8, 0.9, 0.95, 0.98]) {
  const q = 4 * b / (1 - b);
  console.log(`busy ${Math.round(b * 100)}% -> wait ${q.toFixed(0)} h`);
}

৩ · CALMS আর three ways — প্রতিষ্ঠানকে পড়ার দুটি চশমা

“আমরা DevOps করি” কথাটি যাচাই করবেন কীভাবে? দুটি প্রচলিত কাঠামো কাজে লাগে। CALMS হলো পাঁচটি দিকের একটি তালিকা। প্রচলিত বর্ণনায় John Willis আর Damon Edwards ২০১০-এর দিকে CAMS বলেন, পরে Jez Humble Lean-এর L যোগ করেন। সূত্রভেদে কৃতিত্বের বর্ণনা একটু আলাদা।

দ্বিতীয় চশমাটি three ways (তিন পথ)। Gene Kim ২০১২-র দিকে এটি লেখেন, আর Kim, Kevin Behr ও George Spafford-এর উপন্যাস The Phoenix Project (২০১৩) ও Kim, Humble, Debois ও Willis-এর The DevOps Handbook (২০১৬) একে ছড়িয়ে দেয়।

এখানে প্রশ্নটি ব্যবস্থাপনার। প্রথম পথে জিজ্ঞেস করুন: কাজ কোথায় আটকে থাকে? দ্বিতীয় পথে: production-এর সমস্যা ডেভেলপার কত দ্রুত জানেন? তৃতীয় পথে: উন্নতির জন্য কি নির্দিষ্ট সময় রাখা আছে, নাকি শুধু “সময় পেলে”? উত্তরগুলো tool নয়, সিদ্ধান্ত।

৪ · SRE — error budget দিয়ে গতি আর স্থিতির ভারসাম্য

DevOps বলে দেয়াল ভাঙুন, কিন্তু ঠিক কীভাবে, তা বলে না। SRE (Site Reliability Engineering) তার একটি নির্দিষ্ট উত্তর। Ben Treynor (পরে Ben Treynor Sloss) ২০০৩ সালে Google-এ এর শুরু করেন বলে প্রচলিত, আর তাঁর বিখ্যাত বর্ণনা: একজন software engineer-কে একটি operations দল নকশা করতে বললে যা হয়, SRE তাই। Google-এর বই Site Reliability Engineering (২০১৬, সম্পাদনা Betsy Beyer ও সহকর্মীরা) ধারণাগুলো প্রকাশ্যে আনে। নিচের নিয়মগুলো Google-এর নিজের বর্ণনা; সব প্রতিষ্ঠানে হুবহু খাটে না।

প্রথম ধাপে দল ঠিক করে “যথেষ্ট ভালো” কত। সেটি হলো SLO (service level objective), যেমন মাসে ৯৯.৯% সময় ঠিক সাড়া। ১০০% লক্ষ্য নয়, কারণ ব্যবহারকারীর ফোন আর network-ই ততটা ভালো নয়, আর শেষ কয়েকটি ৯ খুব দামি। বাকি অংশটিই error budget, অর্থাৎ ভুলের অনুমোদিত পরিমাণ।

সূত্রটি শুধু হিসাব নয়, একটি চুক্তি। Google-এর The Site Reliability Workbook (২০১৮) একটি উদাহরণ নীতিতে বলে, budget শেষ হলে গুরুতর সমস্যা আর নিরাপত্তা সংশোধন ছাড়া পরিবর্তন থামবে। নিচের simulator-এ একটি কাল্পনিক দলের সরল নীতি চলছে। এই সীমাগুলো কোনো মান নয়, উদাহরণ।

// Error budget: release or hold? SLO 99.9% over a 30-day window.
const SLO = 0.999, WINDOW_MIN = 30 * 24 * 60;
const BUDGET = (1 - SLO) * WINDOW_MIN;         // allowed bad minutes
// Toy policy for this fictional team, not a standard:
// used under 50% normal; 50-100% only low-risk; 100%+ reliability fixes only.
const log = [                                  // day, what happened
  { day: 3,  bad: 6,  ask: "new search page", risk: "high", cost: 8 },
  { day: 9,  bad: 12, ask: "new cart page",   risk: "high", cost: 8 },
  { day: 14, bad: 5,  ask: "text fix",        risk: "low",  cost: 1 },
  { day: 18, bad: 9,  ask: "payment rewrite", risk: "high", cost: 8 },
  { day: 22, bad: 14, ask: "text fix",        risk: "low",  cost: 1 },
  { day: 25, bad: 3,  ask: "db timeout fix",  risk: "fix",  cost: 1 },
];
let used = 0;
console.log(`budget = ${BUDGET.toFixed(1)} bad minutes in 30 days`);
console.log("day  used   used%  pace%  request            decision");
for (const e of log) {
  used += e.bad;
  const pct = 100 * used / BUDGET, pace = 100 * e.day / 30;
  const left = BUDGET - used;
  let verdict;
  if (e.risk === "fix") verdict = "RELEASE (reliability fix)";
  else if (pct >= 100) verdict = "HOLD (budget gone)";
  else if (pct >= 50 && e.risk === "high") verdict = "HOLD (only low risk now)";
  else if (e.cost > left) verdict = "HOLD (could burn the rest)";
  else verdict = "RELEASE";
  console.log(String(e.day).padStart(3) + String(used).padStart(6) +
    pct.toFixed(0).padStart(7) + pace.toFixed(0).padStart(7) + "  " +
    e.ask.padEnd(17) + "  " + verdict);
}
const bad10M = (1 - SLO) * 10_000_000;
console.log(`same SLO by requests: ${bad10M.toFixed(0)} failures allowed per 10M`);

৫০% সীমা আর “class SRE implements DevOps”

SRE বইয়ের আরেকটি পরিচিত নিয়ম: Google তার SRE-দের সামগ্রিক ops কাজে (ticket, on-call, হাতের কাজ) ৫০% সীমা রাখে, যাতে বাকি সময় প্রকৌশলে যায়। বই অনুযায়ী এই সীমা বারবার ভাঙলে বাড়তি ops কাজ ফেরত যায় ডেভেলপার দলের কাছে, যাতে তাঁরাও নিজের কোডের ঝামেলা টের পান। ৫০% সংখ্যাটি Google-এর নিয়ম, প্রকৃতির সূত্র নয়, তবে “সীমা থাকতে হবে” ভাবনাটি সব জায়গায় খাটে।

২০১৮ সালের দিকে Google-এর Seth Vargo আর Liz Fong-Jones একটি কথা জনপ্রিয় করেন: class SRE implements DevOps. প্রোগ্রামিংয়ের ভাষায়, DevOps যেন একটি interface (কী করতে হবে তার তালিকা), আর SRE তার একটি নির্দিষ্ট implementation. কথাটি Google-এর দৃষ্টিভঙ্গি; সবাই এই সম্পর্কটি এভাবে দেখেন না, আর SRE-র কিছু চর্চা DevOps শব্দটির আগেই শুরু হয়েছিল।

৫ · Toil — মাপা, বাজেট রাখা আর কমানো

SRE বইয়ে toil-এর ছয়টি লক্ষণ আছে: হাতে করতে হয় (manual), বারবার ফেরে (repetitive), যন্ত্র করতে পারত (automatable), শুধু তাৎক্ষণিক আগুন নেভায় (tactical), স্থায়ী কোনো উন্নতি রেখে যায় না (no enduring value), আর service বড় হলে সমানুপাতে বাড়ে (scales with growth). সব বিরক্তিকর কাজ toil নয়: সভা বা ফাইলপত্র হলো overhead, আর নকশা বা postmortem লেখা প্রকৌশল।

মাপার উপায় সহজ। ভেতরের ticket আর on-call log-এ একটি tag দিন, আর প্রতি তিন মাসে দলের কাছে সংক্ষিপ্ত হিসাব নিন। একটি toil খাতা রাখুন: কাজের নাম, কী কারণে শুরু হয়, কতবার, প্রতিবার কত মিনিট। Google-এর SRE বইয়েও নিয়মিত জরিপে toil মাপার কথা আছে। সূত্র একটিই: toil% = toil-এর ঘণ্টা ÷ দলের মোট ঘণ্টা। যেমন ৪ জন × ১২ সপ্তাহ × ৪০ ঘণ্টা = ১,৯২০ ঘণ্টা, এর মধ্যে ৮০০ ঘণ্টা toil হলে প্রায় ৪১.৭%.

খাতায় দুটি কাজ উঠল। কোনটি আগে automate করবেন? হিসাব ছাড়া সিদ্ধান্ত নিলে প্রায়ই মজার কাজটি জেতে, দামি কাজটি নয়।

একটি কাজের হিসাব তো হলো; পুরো দলের কয়েক ত্রৈমাসিকে কী হয়? ধরুন ৪ জনের দল, toil শুরুতে ৮০০ ঘণ্টা, আর ট্রাফিকের সাথে প্রতি তিন মাসে ১০% বাড়ে। দল প্রথম তিন ত্রৈমাসিকে তিনটি automation কাজ করে; প্রতিটির একটি বানানোর খরচ আর রক্ষণাবেক্ষণের খরচ আছে।

// Toil budget: 4 engineers, 8 quarters. Does automation pay back?
const CAPACITY = 4 * 12 * 40;     // 4 people x 12 weeks x 40 h = hours a quarter
const TOIL_START = 800;           // manual hours in quarter 1
const GROWTH = 1.10;              // toil grows 10% a quarter with traffic
const UPKEEP = 0.05;              // upkeep per quarter, as a share of build cost
const projects = [                // built in quarter q, works from q + 1
  { q: 1, cost: 300, cut: 0.30 },
  { q: 2, cost: 240, cut: 0.25 },
  { q: 3, cost: 200, cut: 0.20 },
];
function simulate(plan) {
  const rows = [];
  let left = 1, sunk = 0;         // share of toil still manual, total built
  for (let q = 1; q <= 8; q++) {
    const toil = TOIL_START * GROWTH ** (q - 1) * left;
    const build = plan.filter(p => p.q === q).reduce((a, p) => a + p.cost, 0);
    const upkeep = sunk * UPKEEP;
    const free = Math.max(0, CAPACITY - toil - build - upkeep);
    rows.push({ q, toil, free });
    sunk += build;
    for (const p of plan) if (p.q === q) left *= 1 - p.cut;
  }
  return rows;
}
const none = simulate([]), auto = simulate(projects);
let gain = 0, payback = null;
console.log("Q   toil% none   toil% auto   free none   free auto   total gain");
for (let i = 0; i < 8; i++) {
  gain += auto[i].free - none[i].free;
  if (payback === null && gain >= 0) payback = i + 1;
  const pc = r => (100 * r.toil / CAPACITY).toFixed(0).padStart(9) + "%";
  console.log(String(i + 1) + pc(none[i]) + "   " + pc(auto[i]) +
    none[i].free.toFixed(0).padStart(12) + auto[i].free.toFixed(0).padStart(12) + gain.toFixed(0).padStart(13));
}
console.log("Automation has paid for itself by quarter " + payback);

৬ · DevOps, SRE আর platform team — কে কী করে

তিনটি শব্দ প্রায়ই গুলিয়ে যায়। সংজ্ঞা প্রতিষ্ঠানভেদে আলাদা, চাকরির বিজ্ঞপ্তিতে তো আরও। তবু একটি কাজ চালানোর মতো তুলনা:

Platform team pipeline, cluster আর monitoring-কে একটি ভেতরের পণ্যের মতো বানায়, যাতে product দল ticket না খুলে নিজেই কাজটি করতে পারে। বিস্তারিত পর্ব ৬২-তে।

“You build it, you run it” — আর তার দাম

২০০৬ সালে ACM Queue-এর একটি সাক্ষাৎকারে Amazon-এর CTO Werner Vogels এই কথাটি বলেছিলেন বলে বহুল-উদ্ধৃত: you build it, you run it. যে দল service বানায়, সেই দলই production-এ চালায় আর alert পায়। রাত ৩টায় নিজের ফোন বাজলে ডেভেলপার হঠাৎ log আর timeout নিয়ে যত্নবান হন। এটিই সবচেয়ে সরাসরি feedback.

দামও আছে। On-call ক্লান্তি আনে, প্রত্যেকের ওপর বাড়তি জ্ঞানের বোঝা পড়ে, আর ৩ জনের দলে সাপ্তাহিক পালা মানে প্রতি তৃতীয় সপ্তাহে ঘুম নষ্ট। ছোট দলে তাই on-call-এর সময়, ক্ষতিপূরণ আর alert-এর মান নিয়ে নিয়ম লাগে। বিস্তারিত পর্ব ৬৬ আর ৬৭-তে।

৭ · Team Topologies আর Conway's law — দলের নকশাই system-এর নকশা

১৯৬৮ সালে Melvin Conway Datamation পত্রিকায় “How Do Committees Invent?” প্রবন্ধে একটি পর্যবেক্ষণ লেখেন, যা পরে Fred Brooks-এর The Mythical Man-Month বইয়ের মাধ্যমে Conway's law নামে ছড়ায়: যে প্রতিষ্ঠান একটি system নকশা করে, সেই নকশা হয় প্রতিষ্ঠানের যোগাযোগের কাঠামোর নকল। একটি পরিচিত রসিকতা আছে: চারটি দল মিলে compiler বানালে চার ধাপের compiler পাবেন। Frontend, backend আর database দল আলাদা থাকলে ছোট একটি feature-ও তিন দলের সারি পার হয়।

এর উল্টো প্রয়োগকে বলে inverse Conway maneuver: যে system চান, আগে সেই আকারে দল সাজান। Matthew Skelton আর Manuel Pais-এর বই Team Topologies (২০১৯) এই ভাবনাকে একটি ব্যবহারিক কাঠামো দেয়। মূল শব্দ cognitive load: একটি দল একসাথে কতটা মাথায় রাখতে পারে। দলের দায়িত্ব সেই সীমার মধ্যে রাখতে হবে। বইটি চার ধরনের দল বলে:

বইটি তিন ধরনের মিথস্ক্রিয়াও বলে: collaboration (কিছুদিন একসাথে কাজ), X-as-a-Service (একটি পরিষ্কার সেবা ব্যবহার) আর facilitating (শিখিয়ে সরে যাওয়া)। দল গঠনের বিস্তারিত আছে Software Engineering কোর্সের দলগত কাজ পর্বে। এই পর্বে মূল কথাটি হলো: দল ভাগ করার সিদ্ধান্ত একটি architecture-এর সিদ্ধান্ত।

৮ · Blameless culture — দোষী নয়, কারণ খোঁজা

তৃতীয় পথের প্রাণ হলো ব্যর্থতা থেকে শেখা। আর মানুষ তখনই সত্য বলেন, যখন সত্য বললে শাস্তি হয় না। John Allspaw ২০১২ সালে Etsy-র একটি লেখায় postmortem-কে “blameless” করার যুক্তি দেন, Sidney Dekker-এর “just culture” ভাবনার ওপর দাঁড়িয়ে। Blameless culture মানে দায়হীনতা নয়। দল দায় নেয়, কিন্তু প্রশ্নটি “কে?” থেকে সরে “ব্যবস্থাটি কেন এটি হতে দিল?”-তে যায়।

নিচের কাল্পনিক ঘটনাটি দুই রকম প্রতিষ্ঠানে দেখুন।

কয়েকটি ব্যবহারিক নিয়ম: লেখায় মানুষের নামের বদলে ভূমিকা ব্যবহার করুন (“on-call প্রকৌশলী”); “মূল কারণ একটি” ধরে নেবেন না, জটিল system-এ কারণ অনেক (contributing factors); প্রতিটি কাজের মালিক আর তারিখ রাখুন; আর কাজগুলো শেষ হলো কি না পরে দেখুন। Blameless মানে ইচ্ছাকৃত ক্ষতি মেনে নেওয়া নয়; “just culture”-এ অসাবধান ঝুঁকি আর সৎ ভুল আলাদা করে দেখা হয়। Ron Westrum-এর সংস্কৃতির তিন ধরন (pathological, bureaucratic, generative) Accelerate বইয়েও উদ্ধৃত। Incident চালানোর পূর্ণ নিয়ম পর্ব ৬৭-তে।

৯ · একটি সরল maturity view — আপনি এখন কোথায়

নিচের ছকটি এই কোর্সের একটি সরল দৃষ্টি, কোনো মান বা সনদ নয়। একই প্রতিষ্ঠানের ভিন্ন দল ভিন্ন ধাপে থাকতে পারে, আর ছোট দলের জন্য সবচেয়ে ওপরের ধাপ জরুরিও নয়। লক্ষ্য নম্বর পাওয়া নয়, পরের একটি উন্নতি বেছে নেওয়া।

ছোট দলের জন্য শুরুটি সহজ। এক মাস toil খাতা রাখুন। একটি service-এর জন্য একটি SLO লিখুন। পরের outage-এ একটি blameless postmortem করুন। তিনটির কোনোটিতেই tool কিনতে হয় না, cloud account-ও লাগে না।

১০ · AI-এর যুগে — DevOps-এর পরামর্শে AI-কে যাচাই

AI একটি postmortem-এর খসড়া বা toil-এর তালিকা দ্রুত বানাতে পারে। কিন্তু AI আপনার দল, প্রতিষ্ঠানের চাপ আর ইতিহাস জানে না। তার ওপর এই বিষয়ে সে প্রায়ই আত্মবিশ্বাসে ভুল বলে।

AI-এর পরামর্শ কাজে লাগানোর আগে

• প্রতিটি পরিসংখ্যান আর উদ্ধৃতির মূল সূত্র খুঁজে পেয়েছি
• হিসাবের অন্তত একটি সংখ্যা হাতে মিলিয়েছি
• Script আর runbook পরীক্ষার environment-এ, dry-run বা plan দিয়ে চালিয়েছি
• Prompt-এ কোনো secret, key বা গ্রাহকের তথ্য দিইনি
• অনুমতি, খোলা port আর খরচের প্রভাব নিজে পড়েছি
• Postmortem-এর ভাষায় কোনো ব্যক্তিকে দোষ দেওয়া হয়নি