FinOps — rightsizing, tagging, showback আর unit economics

১ · FinOps কী — খরচকে কারও না কারও কাজ বানানো

একটি কাল্পনিক অনলাইন বাজার অ্যাপ ধরি, নাম “হাটঘর”। এই পর্বের সব সংখ্যা এই অ্যাপেরই, আর সব দাম ধরে নেওয়া। গত বছর হাটঘরের cloud বিল ছিল মাসে $৩,০০০। এ বছর তা $১০,০০০। হিসাব বিভাগ জিজ্ঞেস করলেন, “বাড়ল কেন?” প্রকৌশল দল বলল, “অর্ডার তো বেড়েছে।” কত বেড়েছে, কার কারণে বেড়েছে, কেউ বলতে পারলেন না।

FinOps শব্দটি Finance আর DevOps জুড়ে তৈরি। FinOps Foundation-এর সংজ্ঞার সারকথা হলো: এটি একটি কাজের কাঠামো ও সংস্কৃতি, যেখানে প্রকৌশল, অর্থ আর ব্যবসা দল একসাথে বসে প্রযুক্তির (মূলত cloud-এর) খরচ থেকে ব্যবসার সর্বোচ্চ মূল্য বের করে, সময়মতো তথ্য দেখে সিদ্ধান্ত নেয়, আর খরচের জবাবদিহি ভাগ করে নেয়।

পুরোনো data centre-এ খরচের সিদ্ধান্ত হতো বছরে একবার, কেনাকাটা বিভাগের টেবিলে। পর্ব ০৪-এ দেখেছেন, cloud-এ খরচ হয়ে গেছে OpEx. এখন একজন প্রকৌশলী একটি Terraform line বদলালেই মাসে কয়েকশো ডলারের সিদ্ধান্ত হয়ে যায়। সিদ্ধান্ত যেহেতু প্রকৌশলীর হাতে এসেছে, খরচের তথ্যও তাঁর হাতে আসা দরকার। এটাই FinOps-এর মূল কথা।

২ · Inform → Optimize → Operate লুপ

FinOps Framework কাজকে তিন phase-এ ভাগ করে। এগুলো একবার করে শেষ করার ধাপ নয়, একটি চলমান লুপ। আলাদা আলাদা service বা দল একই সময়ে আলাদা phase-এ থাকতে পারে।

লেখার সময়ে Framework-এর ছয়টি নীতি মোটামুটি এই: দলগুলো একসাথে কাজ করবে; সিদ্ধান্ত হবে ব্যবসার মূল্য দেখে; নিজের প্রযুক্তি-ব্যবহারের দায় প্রত্যেকে নেবে; তথ্য হবে সহজলভ্য, সময়মতো ও সঠিক; FinOps-এর চর্চা কেন্দ্র থেকে সহায়তা পাবে; আর cloud-এর পরিবর্তনশীল খরচের সুবিধা কাজে লাগানো হবে। Framework নিয়মিত হালনাগাদ হয়। Domain আর capability-র নাম বদলায়, আর সাম্প্রতিক সংস্করণে আওতা শুধু public cloud-এ নেই, SaaS বা data centre-এর খরচও আসছে। তাই নামগুলো FinOps Foundation-এর ওয়েবসাইটে মিলিয়ে নিন।

Framework পরিপক্বতাকে তিন নামে ডাকে: Crawl, Walk, Run. শুরুতে সব কিছু নিখুঁত করার দরকার নেই। হাটঘরের প্রথম লক্ষ্য ছিল শুধু খরচের ৮০% কোনো দলের নামে আনা।

৩ · দেখা: tag, allocation, showback আর chargeback

না দেখে কমানো যায় না। পর্ব ৩৫-এ আপনি tag নীতি, tag coverage আর unallocated খরচ দেখেছেন। সংক্ষেপে: ৪–৬টি দরকারি tag, নির্দিষ্ট মানের তালিকা, আর হিসাব খরচের অঙ্কে। এই পর্বে সেই tag থেকে দলের হাতে বিল পৌঁছানো দেখব। একে বলে cost allocation.

কাঁচা তথ্য আসে billing export থেকে: প্রতিটি resource-এর ঘণ্টা বা দিনভিত্তিক লাইন, যা warehouse-এ ঢোকানো যায়। Provider-এর console-এর চেয়ে এটিই নির্ভরযোগ্য উৎস। মনে রাখবেন, অনেক provider-এ tag-কে আলাদাভাবে “খরচের tag” হিসেবে চালু করতে হয়, আর চালু করার আগের খরচে তা সাধারণত দেখা যায় না।

এবার হাটঘরের $১০,০০০ বিলটি ধাপে ধাপে ভাগ করা যাক। এখানে “পরে” চেপে দেখুন, প্রতিটি ধাপে টেবিল কীভাবে বদলায়।

vm-web        compute    checkout   2600
db-orders     database   checkout   1400
vm-search     compute    search     1500
cache-search  cache      search      500
wh-reports    warehouse  data       1100
lake-raw      storage    data        400
nat-main      network    shared      800
logs-all      logging    shared      500
support-plan  support    shared      500
vm-old-test   compute    (empty)     450
disk-orphan   storage    (empty)     250

checkout       4000
search         2000
data           1500
shared         1800
(empty)         700

450 vm-old-test   last login 4 months ago
250 disk-orphan   attached to nothing

checkout  1800 x 4000/7500 = 960
search    1800 x 2000/7500 = 480
data      1800 x 1500/7500 = 360
                     sum = 1800

team           direct  shared  showback  share
checkout         4000     960      4960  49.6%
search           2000     480      2480  24.8%
data             1500     360      1860  18.6%
(unallocated)     700       0       700   7.0%

Showback না chargeback?

Shared খরচ ভাগের চার উপায়

নিচের Bash block ওপরের পুরো হিসাবটি করে। CSV থাকে block-এর ভেতরেই। awk-এ ভাগের কাজটি দেখুন, আর শেষের unallocated লাইনটি খেয়াল করুন।

#!/usr/bin/env bash
set -euo pipefail
cat > bill.csv <<'EOF'
resource,service,team,usd
vm-web,compute,checkout,2600
db-orders,database,checkout,1400
vm-search,compute,search,1500
cache-search,cache,search,500
wh-reports,warehouse,data,1100
lake-raw,storage,data,400
nat-main,network,shared,800
logs-all,logging,shared,500
support-plan,support,shared,500
vm-old-test,compute,,450
disk-orphan,storage,,250
EOF
awk -F, 'NR > 1 {
  key = ($3 == "") ? "(unallocated)" : $3
  c[key] += $4; total += $4
}
END {
  direct = c["checkout"] + c["search"] + c["data"]
  printf "%-14s %7s %7s %9s %6s\n", "team", "direct", "shared", "showback", "share"
  n = split("checkout search data", teams, " ")
  for (i = 1; i <= n; i++) {
    t = teams[i]; s = c["shared"] * c[t] / direct
    printf "%-14s %7d %7d %9d %5.1f%%\n", t, c[t], s, c[t] + s, 100 * (c[t] + s) / total
  }
  u = c["(unallocated)"]
  printf "%-14s %7d %7d %9d %5.1f%%\n", "(unallocated)", u, 0, u, 100 * u / total
  printf "%-14s %7d\n", "bill total", total
}' bill.csv
echo "--- unallocated, biggest first:"
awk -F, 'NR > 1 && $3 == "" { print $4, $1 }' bill.csv | sort -rn

দুটি হিসাবের ফাঁদ: amortization আর FOCUS

ধরুন, জানুয়ারিতে এক বছরের একটি commitment কিনতে একসাথে $১,২০০ দিলেন। বিলে জানুয়ারিতে $১,২০০, বাকি এগারো মাসে শূন্য। এতে দলের খরচের গ্রাফ অর্থহীন হয়ে যায়। Amortized cost সেই টাকাকে ব্যবহারের সময়ে ছড়িয়ে দেয়: মাসে $১০০। অর্থ বিভাগ নগদ হিসাব চান, প্রকৌশলীর দরকার amortized হিসাব। Showback সাধারণত দ্বিতীয়টিতেই করা হয়।

আরেকটি সমস্যা, প্রতিটি provider-এর বিলের column আলাদা। FOCUS (FinOps Open Cost and Usage Specification) হলো বিলের ডেটার একটি উন্মুক্ত নির্দিষ্টকরণ, যা FinOps Foundation-এর আওতায় তৈরি হচ্ছে। ১.০ সংস্করণ এসেছে ২০২৪ সালে, পরে আরও সংস্করণ এসেছে। ভাবনাটি হলো একই নামের column সব provider-এ: যেমন BilledCost আর EffectiveCost, যা ঠিক ওপরের দুই হিসাবের পার্থক্য ধরে। লেখার সময়ে কয়েকটি বড় provider FOCUS-ধাঁচের export দিচ্ছে। Column-এর নাম আর সমর্থন version-ভেদে আলাদা হতে পারে, তাই হালনাগাদ নথি মিলিয়ে নিন।

নিচের কমান্ডটি শুধু পড়ে, কিছু বদলায় না। তবু কিছু provider-এ cost API-র প্রতিটি ডাকের সামান্য দাম থাকতে পারে। এটি এখানে শুধু উদাহরণ, চালানোর দরকার নেই।

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=TAG,Key=team

৪ · Rightsizing — ব্যবহারের তথ্য দেখে আকার ঠিক করা

এখন Optimize phase. খরচ কমানোর দুটি হাতল আছে। Usage optimization মানে কম জিনিস ব্যবহার করা। Rate optimization মানে একই জিনিস কম দরে কেনা। বিল = ব্যবহার × দর, তাই আগে ব্যবহার কমান। নইলে অপচয়ের ওপরই ছাড় কিনে ফেলবেন।

গড় utilisation দেখলে চলে না, কারণ গড়ে চূড়া হারিয়ে যায়। তাই p95 দেখা হয়। সূত্রটি সহজ:

লক্ষ্য ১০০% নয়, কারণ headroom লাগে। এখানে ধরা হলো CPU ৬০% আর memory ৭০%. সংখ্যা দুটি নীতি, নিয়ম নয়। CPU আর memory আলাদা হিসাব করে যে আকারে দুটোই আঁটে, সেটি বেছে নিতে হয়। নিচের simulator ছয়টি service-এ এটি করে। সব আকার ও দাম ধরে নেওয়া, আসল দাম provider-এর pricing পাতায় মিলিয়ে নিন।

// Rightsizing from sample p95 metrics. All sizes and prices are assumed.
const sizes = [
  { name: 'S',  vcpu: 2,  gib: 8,  usd: 60 },
  { name: 'M',  vcpu: 4,  gib: 16, usd: 120 },
  { name: 'L',  vcpu: 8,  gib: 32, usd: 240 },
  { name: 'XL', vcpu: 16, gib: 64, usd: 480 },
];
const CPU_TARGET = 0.60, MEM_TARGET = 0.70, MIN_DAYS = 14;

// service, current size, days of data, p95 CPU %, p95 memory %
const fleet = [
  ['web',        'L',  30, 18, 30],
  ['search-api', 'XL', 30, 20, 30],
  ['report-job', 'L',  30,  9, 62],
  ['cache-a',    'M',  30, 70, 81],
  ['admin-new',  'L',   5, 12, 20],
  ['old-tool',   'M',  30,  1,  6],
];

let net = 0;
console.log('service     now  need vCPU/GiB  to  $/mo  note');
for (const [svc, now, days, cpu, mem] of fleet) {
  const cur = sizes.find(s => s.name === now);
  const needCpu = cur.vcpu * cpu / 100 / CPU_TARGET;
  const needMem = cur.gib * mem / 100 / MEM_TARGET;
  let fit = sizes.find(s => s.vcpu >= needCpu && s.gib >= needMem) ?? cur;
  let note = fit.usd < cur.usd ? 'downsize' : fit.usd > cur.usd ? 'UPSIZE' : 'keep';
  if (days < MIN_DAYS) { fit = cur; note = `wait, only ${days} days of data`; }
  else if (cpu < 3 && mem < 10) note = 'idle? ask owner, maybe delete';
  const change = fit.usd - cur.usd;
  net += change;
  const need = `${needCpu.toFixed(1)}/${needMem.toFixed(1)}`;
  console.log(`${svc.padEnd(11)} ${now.padEnd(4)} ${need.padEnd(14)} ${fit.name.padEnd(3)} ${String(change).padStart(5)}  ${note}`);
}
console.log(`net change: ${net} USD per month`);

একটি rightsizing, সাথে rollback পরিকল্পনা

কাগজের হিসাব একটি অনুমান মাত্র। বদলটি production-এ একটি deployment, তাই পর্ব ৫৯-এর শৃঙ্খলা এখানেও লাগে। হাটঘরের search-api-তে ৩টি XL instance, instance-প্রতি $৪৮০। ওপরের হিসাবে L যথেষ্ট, তাই মাসে $৭২০ বাঁচার কথা। আগে থেকে লেখা শর্ত দেখুন, আর ধাপ ৫-এ কী হয় খেয়াল করুন।

size now      3 x XL (16 vCPU, 64 GiB)  $1440/mo
p95 CPU       20%      max CPU    39%
p95 memory    30%      max memory 33%
p95 latency   180 ms   SLO        300 ms
need          5.3 vCPU, 27.4 GiB  ->  L (8, 32)

change      one reviewed IaC pull request
window      weekday 11:00, no sale that week
go on if    p95 latency < 250 ms
            p95 CPU     < 65%
            errors      < 0.1%
rollback    revert the PR, back to XL in 15 min
owner       search on-call

fleet        1 x L  +  2 x XL
on the L     p95 CPU 41%   memory 61%
p95 latency  186 ms   (limit 250)
errors       0.02%    (limit 0.1%)
verdict      go on

fleet        3 x L     $720/mo
p95 CPU      42%
p95 latency  192 ms
verdict      looks fine, keep watching 7 days

event        weekly full reindex starts
p95 CPU      78%       limit 65%
p95 latency  340 ms    limit 250, SLO 300
action       revert the PR
02:14        back to 3 x XL, latency 190 ms

cause        reindex used 12 parallel workers
             39% on XL means 78% on half the CPU
             a few hours a week, so below p95
fix          reindex limited to 6 workers
next try     3 x L, reindex CPU p95 58%

vm-search     $1500  ->  $780
saved         $720/mo
SLO breach    14 min, inside error budget
new rule      batch jobs listed before any resize

Kubernetes: request বনাম আসল ব্যবহার

Kubernetes-এ টাকা যায় node-এর জন্য, আর node ভরে request দিয়ে, আসল ব্যবহার দিয়ে নয় (পর্ব ৪৮). তাই একটি Pod ১ vCPU বুক করে ০.৩ ব্যবহার করলেও scheduler-এর চোখে পুরো ১ vCPU দখল। Request আর ব্যবহারের এই ফাঁককে বলে slack.

হিসাবটি সরল। সিস্টেমের Pod আর headroom বাদ দেওয়া হয়েছে, আর node-এর দাম ওপরের M আকারের। চারটি জিনিস মনে রাখুন:

• টাকা বাঁচে node সরলে। Request কমালেই বিল কমে না। Cluster Autoscaler বা Karpenter ফাঁকা node সরালে তবেই কমে।
• Memory-তে p95 নয়, সর্বোচ্চ মান দেখুন। CPU কম পড়লে ধীর হয়, memory কম পড়লে OOMKilled. তাই এখানে সর্বোচ্চ ১১০০Mi-র ওপর প্রায় ২০% যোগ করা হয়েছে।
• HPA-র হিসাব বদলে যায়। HPA-র CPU লক্ষ্য request-এর শতাংশে। লক্ষ্য ৭০% থাকলে আগে সীমা ছিল ৭০০m, request ৫০০m করলে তা ৩৫০m. অর্থাৎ Pod সংখ্যা আগের চেয়ে তাড়াতাড়ি বাড়বে, আর সাশ্রয় উবে যেতে পারে। লক্ষ্যও একসাথে নতুন করে ঠিক করুন।
• Pod-এর খরচ ভাগ। বিলে Pod থাকে না, থাকে node. OpenCost-এর মতো tool Pod-কে সাধারণত request আর ব্যবহারের যেটি বড়, সেই অনুযায়ী খরচ ধরে, আর খালি node-এর অংশ আলাদা “idle” লাইনে দেখায়।

VPA-কে শুধু পরামর্শের জন্য চালানো যায়। updateMode: "Off" মানে সে Pod ছোঁবে না, শুধু status-এ সুপারিশ লিখবে। VPA আলাদা component, তাই আগে cluster-এ আছে কি না দেখে নিন।

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: search-api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: search-api
  updatePolicy:
    updateMode: "Off"

৫ · অপচয় বন্ধ: off-hours, idle resource আর storage lifecycle

Off-hours সূচি

রাতে অফিস বন্ধ হলে কেউ বাতি জ্বালিয়ে রাখেন না। অথচ dev আর test environment প্রায়ই সারা সপ্তাহ চালু থাকে। সপ্তাহে ১৬৮ ঘণ্টা। রবি থেকে বৃহস্পতিবার সকাল ৯টা থেকে রাত ৯টা চালু রাখলে ঘণ্টা হয় ১২ × ৫ = ৬০, অর্থাৎ ৩৫.৭%. এটি হলো off-hours schedule. বন্ধ VM-এ compute-এর বিল থামে, তবে disk-এর বিল চলতে থাকে। হিসাবে এটি বাদ দিলে সাশ্রয় বেশি দেখাবে।

// Off-hours schedule savings. Prices are assumed; month = 720 hours.
const VMS = 10, USD_PER_VM_HOUR = 0.10;
const DISK_GB = 500, USD_PER_GB_MONTH = 0.08;  // disks bill even when stopped
const MONTH_H = 720, WEEK_H = 168;

const disk = DISK_GB * USD_PER_GB_MONTH;
const fullCompute = VMS * USD_PER_VM_HOUR * MONTH_H;
const before = fullCompute + disk;

const schedules = [
  ['always on',        24 * 7],
  ['Sun-Thu 09-21',    12 * 5],
  ['Sun-Thu 09-18',     9 * 5],
  ['Sun-Thu 09-21+Sat', 12 * 5 + 6],
];

console.log('schedule           h/week  on%    compute  disk  total  saved');
for (const [name, weekHours] of schedules) {
  const share = weekHours / WEEK_H;
  const compute = fullCompute * share;
  const total = compute + disk;
  const saved = before - total;
  console.log(name.padEnd(18), String(weekHours).padStart(6),
    (share * 100).toFixed(1).padStart(5), compute.toFixed(2).padStart(9),
    disk.toFixed(0).padStart(5), total.toFixed(2).padStart(7), saved.toFixed(2).padStart(7));
}

// Same 12x5 schedule, but 4 of the 10 VMs are under a commitment:
// a commitment is paid for every hour, running or not.
const COMMITTED = 4;
const free = VMS - COMMITTED;
const savedFree = free * USD_PER_VM_HOUR * MONTH_H * (1 - 60 / WEEK_H);
console.log(`12x5 with ${COMMITTED} committed VMs: saved ${savedFree.toFixed(2)}`);

বাস্তবে সূচি চলে পর্ব ১০-এর মতো script বা provider-এর scheduler দিয়ে, tag দেখে: schedule=office-hours. দুটি জিনিস রাখুন: একটি “আজ রাতে চালু রাখুন” ব্যবস্থা, আর সকালে ধাপে ধাপে চালু করা। Production-এ এটি নয়, সেখানে আছে scheduled scaling. কিছু managed database কয়েক দিন পর নিজে থেকে আবার চালু হতে পারে, তাই provider-এর নিয়ম দেখে নিন।

Idle resource মোছা

Idle resource বিলে আসে, কিন্তু কোনো কাজে লাগে না। সাধারণ তালিকা: কোনো VM-এ না লাগানো disk, পুরোনো snapshot, target-হীন load balancer, ব্যবহার না হওয়া public IP, ফেলে রাখা test database, আর orphaned resource. নিরাপদ পথটি এমন:

1. তালিকা তৈরি আর tag দেখে মালিক খোঁজা।
2. মালিককে জানিয়ে নির্দিষ্ট তারিখ দেওয়া।
3. বন্ধ করা বা সরানো, মোছা নয়। Disk-এর একটি শেষ snapshot রাখা।
4. ৩০ দিন অপেক্ষা। কেউ খোঁজ না করলে মোছা।

“বছরে একবার চলে” এমন একটি কাজ ৩০ দিনের metric-এ idle-ই দেখায়। তাই শুধু metric দেখে মোছা বিপজ্জনক। নতুন test resource-এ expires-on tag লাগানো আরও ভালো উপায়, তাতে মোছার দায় শুরুতেই ঠিক হয়।

Storage lifecycle: একটি হিসাব

হাটঘরের log জমে দিনে ১০০ GB, রাখতে হয় ৩৬৫ দিন। স্থির অবস্থায় মোট ৩৬,৫০০ GB. ধরে নিই দর প্রতি GB-মাসে hot $০.০২, cool $০.০১ আর archive $০.০০২। পর্ব ২১-এর lifecycle rule বসালে:

সব hot রাখলে ৩৬,৫০০ × $০.০২ = $৭৩০। তাই সাশ্রয় $৫৫৫, প্রায় ৭৬%. তবে ঠান্ডা ধাপে পড়ার ফি, ন্যূনতম রাখার সময়, আর object-প্রতি সরানোর ফি থাকতে পারে। লক্ষ লক্ষ ছোট ফাইলে এই ফি লাভ খেয়ে ফেলতে পারে। আর ৩৬৫ দিনের পরে মোছার নিয়মটিও থাকা চাই। সবচেয়ে সস্তা ডেটা সেটিই, যা রাখা হয়নি। পর্ব ৬৪-এ log-এর খরচ কমানোর আরও উপায় দেখেছেন।

৬ · Commitment coverage — কতটা অঙ্গীকার করবেন

Commitment discount কী, তা পর্ব ৭২ (Cloud-এর বিল)-এর বিষয়। এখানে প্রশ্ন শুধু কৌশলের: কতটা কিনবেন? দুটি মাপ গুলিয়ে ফেলবেন না। Coverage মানে মোট ব্যবহারের কত ভাগ ছাড়ের আওতায়। Commitment utilisation মানে কেনা অঙ্গীকারের কত ভাগ সত্যিই কাজে লাগল।

ধরি, on-demand দরে দিনে ১৬ ঘণ্টা $১০০/ঘণ্টা আর ৮ ঘণ্টা $৬০/ঘণ্টা ব্যবহার হয়। ছাড় ৩০% (ধরে নেওয়া)। Commitment-এর দাম প্রতি ঘণ্টায় দিতেই হবে, ব্যবহার হোক বা না হোক।

সবচেয়ে সস্তা ৬৯% coverage, ১০০% নয়। কারণটি একটি সুন্দর নিয়ম। অঙ্গীকারের প্রতিটি বাড়তি ডলারে আপনি সব সময় $০.৭০ দেন, আর লাভ হয় শুধু যে ঘণ্টায় সেটি ব্যবহার হয়, ঘণ্টায় $১ করে। তাই বাড়তি অংশটি লাভজনক তখনই, যখন সেটি মোট সময়ের অন্তত (১ − ছাড়) ভাগ ব্যবহার হয়।

এখানে ওপরের স্তরটি ৬৬.৭% সময় চলে, যা ৭০%-এর কম। তাই সেটি কেনা লোকসান, যদিও অল্প। আরও ক’টি কৌশল:

• আগে ছোট করুন। Rightsizing আর সূচি শেষ করে যে স্থির ভিত্তি থাকে, তার ওপর কিনুন।
• সিঁড়ির মতো কিনুন। সবটা একদিনে না কিনে প্রতি মাসে অল্প অল্প। তাহলে মেয়াদও একসাথে ফুরোয় না, সিদ্ধান্ত বদলের সুযোগ থাকে।
• নমনীয়টি আগে। নির্দিষ্ট VM-ধরনে বাঁধা ছাড়ের চেয়ে মোট খরচে বাঁধা ছাড় কম, তবে আকার বদলালেও কাজে লাগে। Provider-ভেদে নাম ও শর্ত আলাদা।
• ভবিষ্যৎ দেখুন। বড় migration বা architecture বদল আসছে কি না জেনে নিন, নইলে এক বছরের অঙ্গীকার পড়ে থাকবে।

৭ · Budget, forecast আর cost anomaly

মাস শেষে বিল দেখা মানে মাস শেষে ব্যাংক হিসাব দেখা। তখন আর কিছু করার থাকে না। তাই দরকার আগাম সংকেত।

Budget alert সীমা ছাড়ালে জানায়, তবে সাধারণত খরচ থামায় না (পর্ব ০৬). শুধু আসল খরচে নয়, পূর্বাভাসের ওপরও alert রাখুন। Run rate সবচেয়ে সরল পূর্বাভাস। মাসের ১২ দিনে $৪,৩২০ খরচ হলে দিনে $৩৬০, আর ৩০ দিনে $১০,৮০০। Budget $১০,০০০ হলে ১২ তারিখেই জানা গেল, প্রায় ৮% ছাড়াবে। তবে মনে রাখবেন, বিলের তথ্য কয়েক ঘণ্টা থেকে এক-দুই দিন দেরিতে আসতে পারে, আর সপ্তাহের শেষে ব্যবহার কম হলে সরল গড় ভুল বলবে।

Budget মাসের মোট দেখে। Anomaly detection দেখে “আজকের খরচ আজকের মতো কি না”। Cloud খরচে seasonality আছে: হাটঘরে শুক্র-শনিবার খরচ কম। তাই একটি স্থির সীমা দুই দিকেই ভুল করে। নিচের simulator ৩৫ দিনের একটি seeded series নেয়, প্রতিটি দিনকে আগের তিন সপ্তাহের একই বারের median-এর সাথে মেলায়, আর স্থির $৪৮০ সীমার সাথে তুলনা করে।

// Cost anomaly detector on a seeded daily series. Day 1 is a Sunday.
function mulberry32(a) {
  return () => {
    a = (a + 0x6D2B79F5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rnd = mulberry32(73);
const cost = [null];                         // cost[d] = USD on day d
for (let d = 1; d <= 35; d++) {
  const weekend = d % 7 === 6 || d % 7 === 0;  // Friday, Saturday
  let usd = (weekend ? 250 : 400) * (0.97 + 0.06 * rnd());
  if (d === 25) usd += 100;                  // planned sale day
  if (d >= 28 && d <= 29) usd += 120;        // leak starts on a Saturday
  cost.push(Math.round(usd));
}

const median = a => [...a].sort((x, y) => x - y)[Math.floor(a.length / 2)];
const known = { 25: 'planned sale' };
const FIXED_LIMIT = 480;

console.log('day  actual  expected  excess  seasonal      fixed-limit');
for (let d = 22; d <= 35; d++) {
  const expected = median([cost[d - 7], cost[d - 14], cost[d - 21]]);
  const excess = cost[d] - expected;
  const seasonal = excess > Math.max(0.15 * expected, 20);
  const fixed = cost[d] > FIXED_LIMIT;
  if (!seasonal && !fixed) continue;
  const flag = !seasonal ? '-' : known[d] ? `known: ${known[d]}` : 'ALERT';
  console.log(String(d).padStart(3), String(cost[d]).padStart(7), String(expected).padStart(9),
    String(excess).padStart(7), ' ' + flag.padEnd(13), fixed ? 'ALERT' : '-');
}
console.log('days checked: 22..35');

Provider-দের নিজস্ব anomaly সুবিধাও আছে। সেগুলো চালু রাখুন, তবে alert যেন বিলের মালিক দলের কাছে যায়। এবার সেই শনিবারের সংকেতটি অনুসরণ করা যাক।

actual    376
expected  249
excess    127  (limit: 15% of 249 = 37.35)

service         expected  actual  change
compute              120     122      +2
database              60      60       0
data transfer         34     158    +124
other                 35      36      +1
total                249     376    +127

resource   nat-main (processed bytes)
extra      $124 at $0.05/GB = about 2.5 TB
source     job wh-sync, team=data
target     object storage, same region
started    Friday night, new release

day 29   actual 521, expected 399, excess 122
fix      private endpoint for object storage
day 30   data transfer back to normal
total    127 + 122 = $249 extra

if missed   about $120 a day x 30 = $3600
owner       alert now goes to team data
guard       cost check in design review
template    new VPCs get the endpoint by default

৮ · Unit economics — খরচকে ব্যবসার ভাষায় আনা

“বিল বেড়েছে” কথাটি একা অর্থহীন। ৫০% বেশি অর্ডার সামলাতে ২০% বেশি বিল হলে সেটি সাফল্য। Unit economics খরচকে ব্যবসার একটি এককে ভাগ করে: unit cost = মোট খরচ ÷ ব্যবসার একক। একক হতে পারে অর্ডার, active user, API call, বা শিক্ষার্থী। যে একক ব্যবসা নিজে গোনে, সেটিই ভালো।

সেপ্টেম্বরে বিল ২০% বেড়েছে, তবু খরচ/অর্ডার কমেছে ২০%. ভালো মাস। অক্টোবরে বিল বেড়েছে মাত্র ৪%, অথচ অর্ডার কমেছে, খরচ/অর্ডার ২৫% বেড়েছে। শুধু বিল দেখলে অক্টোবরকে শান্ত মাস মনে হতো। আগস্টে active user ৮০,০০০ হলে খরচ/user $০.১২৫।

গড়ের ভেতরে স্থির আর পরিবর্তনশীল খরচ মিশে থাকে। আগস্ট ও সেপ্টেম্বর ধরে একটি মোটা সরলরেখা টানা যায়: ১,০০,০০০ অর্ডার বাড়লে বিল $২,০০০ বাড়ে, তাই পরবর্তী এক অর্ডারের খরচ, বা marginal cost, $০.০২। বাকি স্থির অংশ $৬,০০০। মাত্র দুই মাসের তথ্য, তাই এটি মোটা অনুমান। এই সূত্রে অক্টোবরের প্রত্যাশা $৬,০০০ + ২,৫০,০০০ × $০.০২ = $১১,০০০। আসল বিল $১২,৫০০। অর্থাৎ $১,৫০০-এর ব্যাখ্যা দরকার।

খরচ যখন architecture-এর একটি metric

Latency আর availability-র মতো খরচও নকশার একটি শর্ত। Amazon-এর CTO Werner Vogels ২০২৩ সালে “The Frugal Architect”-এ প্রথম নিয়মই বলেন: খরচকে non-functional requirement বানান। কাজের কথায় এর অর্থ:

• নকশা পর্যালোচনায় একটি প্রশ্ন: “১০ গুণ traffic-এ এই নকশার খরচ/অর্ডার কত হবে?”
• PR-এ খরচ: Infracost-এর মতো tool Terraform diff-এর আনুমানিক খরচ দেখাতে পারে।
• লুকানো খরচ: Zone পেরোনো chatty call, NAT দিয়ে ডেটা, উচ্চ cardinality-র metric, অসীম log. কোনোটিই diagram-এ দেখা যায় না, সবই বিলে দেখা যায়।
• মাপ: প্রতিটি service-এর dashboard-এ SLO-র পাশে খরচ/অনুরোধ।

Cloud-এ সুন্দর নকশা আর সস্তা নকশা সব সময় এক নয়। নকশার পরের ধাপ পর্ব ৭৪ (Well-Architected)-এ দেখবেন, যেখানে খরচ একটি পুরো স্তম্ভ।

৯ · মাসিক FinOps review আর সাধারণ ফাঁদ

এককালীন পরিষ্কারে বিল এক মাস কমে, তারপর ফিরে আসে। অভ্যাসের জন্য দরকার নিয়মিত সময়। হাটঘর প্রতি মাসের ৫ তারিখে ৪৫ মিনিট বসে, যখন আগের মাসের তথ্য স্থির হয়েছে। থাকেন প্রতিটি দলের একজন প্রকৌশলী, অর্থ বিভাগের একজন, পণ্য ব্যবস্থাপক আর FinOps-এর দায়িত্বে থাকা মানুষটি।

তিনটি লাইনের যোগ $৯০০ + $৩৫১ + $২৪৯ = $১,৫০০, অর্থাৎ অক্টোবরের ব্যাখ্যাহীন অংশ পুরোপুরি ব্যাখ্যা হলো। সভার শেষ প্রশ্নটি হলো, আগের মাসের কাজগুলো কি বিলে সত্যিই দেখা গেল? দোষারোপ নয়, যে কারণে পর্ব ৬৭-এর postmortem-ও blameless.

তিনটি বড় ফাঁদ

১০ · AI-এর যুগে FinOps

AI একটি billing export-এর সারাংশ করতে পারে, আর সন্দেহজনক লাইন খুঁজে দিতে পারে। কিন্তু সে জানে না কোন “idle” VM বছরে একবার চলে, বা কোন replica কেন আছে। সে সাধারণত খরচই ভাবে না, আর ভাবলে এমন কিছু মুছতে বলে যা মোছা উচিত নয়।

AI-এর FinOps পরামর্শ হাতে পেলে — চেকলিস্ট

• একটি লাইনের হিসাব হাতে মিলিয়েছি, আর দাম pricing পাতায় দেখেছি
• CPU, memory, disk, network আর batch কাজ, সব দেখেছি
• প্রতিটি বদলের মালিক, rollback আর SLO-র প্রভাব লেখা আছে
• কিছু মোছার আগে মালিক ও snapshot নিশ্চিত করেছি, কমান্ড --dry-run বা plan-এ দেখেছি
• Prompt-এ কোনো secret, account id বা আসল গ্রাহকের তথ্য দিইনি
• নিজের পরীক্ষার account-এ budget alert চালু রেখেছি, কারণ আসল cloud-এ পরীক্ষার টাকা লাগতে পারে