Incident management — severity, ভূমিকা, runbook আর postmortem

১ · Incident কী, আর কতটা গুরুতর

রাত ৮টা। ঈদের সেল চলছে, হঠাৎ ক্রেতারা পেমেন্ট করতে পারছেন না। ফোন বাজছে, চ্যাটে দশজন একসাথে লিখছেন, কেউ জানেন না কে কী করছেন। সমস্যা শুধু সিস্টেমে নয়, মানুষের সমন্বয়েও। Incident management হলো এই বিশৃঙ্খলার জন্য আগে থেকে ঠিক করা নিয়ম।

Incident হলো এমন অপরিকল্পিত ঘটনা, যা সেবার ক্ষতি করছে বা করার ঝুঁকি তৈরি করেছে, আর যার জন্য এখনই সমন্বিত সাড়া দরকার। সংজ্ঞা প্রতিষ্ঠান-ভেদে একটু আলাদা। ITIL কাঠামো একে সেবার অপরিকল্পিত বিঘ্ন বা মান কমে যাওয়া বলে। সেখানে “problem” আলাদা জিনিস: incident-এর কাজ সেবা ফেরানো, problem-এর কাজ মূল কারণ দূর করা।

প্রতিটি bug incident নয়। প্রতিটি alert-ও নয়। Google-এর Site Reliability Engineering (২০১৬) বইয়ের ১৪তম অধ্যায় তিনটি প্রশ্ন দেয়: দ্বিতীয় কোনো দল লাগছে? গ্রাহক কি টের পাচ্ছেন? এক ঘণ্টা মন দিয়ে কাজ করেও কি সমাধান হয়নি? একটিরও উত্তর “হ্যাঁ” হলে ঘোষণা করা ভালো। দেরিতে ঘোষণার চেয়ে আগে ঘোষণা করে দ্রুত বন্ধ করা সস্তা। নিরাপত্তা-ঘটনায় একই ধরনের কাঠামোকে incident response বলা হয়, যা পর্ব ৩৪-এর সাথে মেলে।

নমুনা severity matrix

Severity-র কোনো সর্বজনীন মান নেই। কেউ চার স্তর রাখেন, কেউ পাঁচ, কেউ P1-P4 বলেন। নিচের matrix-টি একটি নমুনা। আপনার দল নিজের ব্যবসা অনুযায়ী এটি বদলাবে। তবে নিয়মটি লিখে রাখা জরুরি, যাতে রাত ৩টায় কেউ তর্ক না করেন।

নিচের simulator একই নীতিকে কোডে লিখেছে। ইনপুট বদলে দেখুন স্তর কীভাবে বদলায়। শেষের নিয়মটি খেয়াল করুন: নিশ্চিত না হলে এক স্তর ওপরে। Severity পরে নামানো সহজ, কিন্তু দেরিতে ডাকা মানুষ দেরির ক্ষতি ফেরাতে পারেন না।

// Severity classifier. A sample policy, not a standard: edit it for your team.
const ORDER = ['SEV-1', 'SEV-2', 'SEV-3', 'SEV-4'];

function classify(c) {
  let level = 3, why = 'no real user impact';
  if (c.users >= 1) { level = 2; why = 'some users hit, flow not core'; }
  if (c.core && (c.users >= 5 || c.err >= 5)) { level = 1; why = 'core flow hurt'; }
  if (c.core && c.users >= 25 && c.err >= 50 && !c.workaround) {
    level = 0; why = 'core flow down for many, no workaround';
  }
  if (c.data) { level = 0; why = 'data loss or leak suspected'; }
  if (c.unsure && level > 0) { level -= 1; why += ', raised: unsure'; }
  return [ORDER[level], why];
}

// users = % of users hit, err = % of requests failing in that flow
const cases = [
  { name: 'Checkout in Eid sale', users: 80, err: 62, core: true },
  { name: 'One payment gateway', users: 15, err: 100, core: true, workaround: true },
  { name: 'Search is slow',       users: 40, err: 3 },
  { name: 'Admin logo broken',    users: 0,  err: 0 },
  { name: 'Possible data leak',   users: 0.1, err: 0, data: true },
  { name: 'Reviews empty',        users: 30, err: 20, unsure: true },
];

for (const c of cases) {
  const [sev, why] = classify(c);
  console.log(sev + '  ' + c.name.padEnd(21) + why);
}

SEV-1  Checkout in Eid sale core flow down for many, no workaround
SEV-2  One payment gateway  core flow hurt
SEV-3  Search is slow       some users hit, flow not core
SEV-4  Admin logo broken    no real user impact
SEV-1  Possible data leak   data loss or leak suspected
SEV-2  Reviews empty        some users hit, flow not core, raised: unsure

২ · পাঁচ ধাপের জীবনচক্র: আগে ক্ষতি থামান

Incident-এর পথ মোটামুটি একই পাঁচ ধাপে চলে। নামগুলো বইভেদে বদলায়, ক্রম প্রায় বদলায় না।

1. Detect (ধরা): alert, গ্রাহকের অভিযোগ বা dashboard থেকে জানা গেল কিছু ভুল। পর্ব ৬৬-এর SLO alert এখানে কাজে আসে।
2. Triage (গুরুত্ব বিচার): প্রভাব কত, severity কত, কাকে ডাকতে হবে।
3. Mitigate (ক্ষতি থামানো): কারণ পুরো না জেনেও গ্রাহকের কষ্ট বন্ধ করা। Rollback, traffic সরানো, feature বন্ধ করা, বাড়তি capacity.
4. Resolve (মীমাংসা): সেবা স্থির, ঝুঁকি কেটে গেছে, incident বন্ধ ঘোষণা।
5. Learn (শেখা): postmortem, কাজের তালিকা, আর সেই শিক্ষা আবার detection আর runbook-এ ফেরত।

কেন কারণের আগে ক্ষতি থামানো

প্রকৌশলীর স্বভাব হলো কারণ খোঁজা। কিন্তু SRE বইয়ের Effective Troubleshooting অধ্যায় ঠিক উল্টো পরামর্শ দেয়: বড় outage-এ root cause খোঁজার তাড়না সামলে আগে সিস্টেমকে পরিস্থিতি অনুযায়ী যতটা সম্ভব সচল করুন। কারণ সহজ। প্রতিটি মিনিট গ্রাহক কষ্ট পাচ্ছেন, আর কারণ খুঁজতে অনেক সময় ঘণ্টা লেগে যায়। ট্রান্সফরমার পুড়লে আগে বিকল্প লাইনে বিদ্যুৎ দেওয়া হয়, তদন্ত পরে।

Mitigation মানে সমাধান নয়। সেটি একটি অস্থায়ী কৌশল, যার পরে আসল কাজ বাকি থাকে। সাধারণ হাতিয়ারগুলো হলো: আগের version-এ ফেরা, kill switch দিয়ে feature বন্ধ, অন্য zone বা region-এ traffic সরানো, capacity বাড়ানো, আর rate limit দিয়ে চাপ কমানো।

৩ · ভূমিকা: কে নির্দেশ দেন, কে হাত দেন

সবচেয়ে সাধারণ ভুল হলো সবাই মিলে সবকিছু করা। দুজন একই server restart করছেন, কেউ গ্রাহককে জানাচ্ছেন না, ম্যানেজার প্রতি মিনিটে ops প্রকৌশলীকে প্রশ্ন করছেন। ভূমিকা ভাগ করলে এই গোলমাল কমে। চারটি মূল ভূমিকা:

ছোট দলে একজনই দুই ভূমিকা নিতে পারেন। কিন্তু commander আর ops একই ব্যক্তি হলে মাথা কমান্ডে ডুবে যায়, পুরো ছবি কেউ দেখেন না। নিচে দেখুন একজন commander কীভাবে ধাপে ধাপে কাজ ভাগ করে দেন। ঘটনাটি অংশ ৮-এর ঈদ সেলের outage.

৪ · যোগাযোগ: channel, status page আর আপডেটের ছন্দ

গ্রাহকের কাছে নীরবতা মানে কেউ কিছু করছে না। ঠিক যেমন লঞ্চ দেরি হলে ঘাটে ঘোষণা না থাকলে যাত্রীরা অস্থির হন। মাইকে “আরও ৪০ মিনিট লাগবে, পরের খবর ৯টায়” বললে ভিড় অনেক শান্ত থাকে, যদিও লঞ্চ একই দেরিতে আসে।

• ভেতরের channel: প্রতিটি incident-এর একটি আলাদা chat channel, যেমন #inc-eid-checkout. কাজের সব কথা সেখানে, যাতে সময়সহ লেখা থাকে। প্রয়োজনে একটি voice call. সিদ্ধান্তগুলো আবার channel-এ লিখুন।
• Status page: গ্রাহকদের জন্য সেবার অবস্থা জানানোর পাতা। প্রচলিত ধাপ: Investigating, Identified, Monitoring, Resolved.
• আপডেটের ছন্দ: Sev-1-এ ধরা যাক প্রতি ৩০ মিনিটে, নতুন খবর না থাকলেও। “এখনো কাজ চলছে” নিজেই একটি খবর। প্রতিটি আপডেটে পরের আপডেটের সময় লিখুন।

চাপের মধ্যে ভালো লেখা কঠিন, তাই ছাঁচ আগে থেকে লিখে রাখুন। নিচের দুটি নমুনায় খেয়াল করুন: গ্রাহকের বার্তায় কারণের অনুমান নেই, নিজের দলের দোষ নেই, ব্যক্তির নাম নেই, কিন্তু প্রভাব আর পরের সময়টি স্পষ্ট।

# ভেতরের আপডেট (ছাঁচ)
[SEV-1] checkout, 20:30 আপডেট
প্রভাব: চেকআউটে প্রায় 62% চেষ্টা ব্যর্থ
এখন: v4.17-এ rollback চলছে, ops: রাফি
সন্দেহ: 19:40-এর release, এখনো নিশ্চিত নয়
দরকার: database on-call কে আছেন?
পরের আপডেট: 21:00

# গ্রাহকের জন্য (ছাঁচ)
Investigating, 20:22
পেমেন্টের সময় অনেকে সমস্যায় পড়ছেন। আমরা কারণ খুঁজছি।
আপনার কার্ট অক্ষত আছে। পরের খবর 20:52-এ।

৫ · Runbook, playbook আর rollback আগে

রাত ৩টায় ঘুমভাঙা মাথা ভালো করে ভাবতে পারে না। তাই ভাবনার কাজটি দিনের আলোয় সেরে কাগজে রাখা হয়। পরিবারের জরুরি নম্বরের খাতা বা বিদ্যুৎ গেলে জেনারেটর চালুর ছাপা নিয়মের মতো।

Runbook একটি নির্দিষ্ট সমস্যা বা alert-এর ধাপে ধাপে নির্দেশ। Incident playbook এক ধরনের ঘটনার সামগ্রিক পরিকল্পনা: কে থাকবেন, কী সিদ্ধান্ত, কাকে জানানো হবে, যেমন “region নষ্ট” বা “ডেটা ফাঁস”। শব্দ দুটির সীমা দলভেদে আলাদা, অনেকে উল্টোও বলেন। Ansible-এর playbook (পর্ব ৫৬) আলাদা জিনিস। Google-এর SRE বইয়ের ভাষ্যে আগে থেকে playbook লিখে রাখলে উপস্থিত বুদ্ধির তুলনায় MTTR প্রায় তিন গুণ ভালো হয়। এটি তাদের অভিজ্ঞতার কথা, সর্বজনীন মাপ নয়।

ভালো runbook-এর গুণ: alert থেকে সরাসরি link, মালিকের নাম, শেষ পরীক্ষার তারিখ, প্রতিটি ধাপে “কী দেখার কথা”, আর “কখন থেমে কাকে ডাকবেন”। নিচের নমুনাটি পড়ুন। এতে command-গুলো শুধু উদাহরণ।

# Runbook: checkout 5xx is high
Alert: CheckoutBurnRateHigh     Owner: payments team
Last tested: 2026-09-14 (game day)

1. Confirm impact (1 min)
   Dashboard: checkout-overview. Is 5xx above 5%?
   If not: write that in the channel and stop.

2. What changed in the last 60 minutes?
   kubectl rollout history deployment/checkout -n shop
   Recent release: go to step 3. None: go to step 4.

3. Roll back (not safe if the release changed the schema)
   kubectl rollout undo deployment/checkout -n shop
   kubectl rollout status deployment/checkout -n shop --timeout=5m
   Expect: 5xx falls within 5 minutes.

4. Check the database pool
   Dashboard: checkout-db. Pool above 90%?
   Turn on flag checkout_waiting_room.

5. Still bad after 15 minutes?
   Page database on-call. Tell the commander.

Rollback আগে, কিন্তু অন্ধভাবে নয়

SRE বইয়ের ভূমিকায় বলা হয়েছে, Google-এর অভিজ্ঞতায় প্রায় ৭০% outage চলমান সিস্টেমে পরিবর্তনের ফল। হার প্রতিষ্ঠানভেদে আলাদা হবে, তবে প্রথম প্রশ্নটি একই থাকে। সম্প্রতি কিছু বদলে থাকলে আগে সেটি ফেরান। “ঠিক করে নতুন release দিই” পথটিকে roll forward বলে, আর চাপের মধ্যে লেখা নতুন কোডে নতুন ভুল ঢোকার ঝুঁকি থাকে।

Rollback কখন নিরাপদ নয়? Release ডেটাবেসের schema বদলে দিলে (পর্ব ৫৯-এর expand and contract মনে করুন), নতুন version ইতিমধ্যে নতুন format-এ ডেটা লিখে থাকলে, অথবা নিরাপত্তা-patch ফেরালে ঝুঁকি ফিরে এলে। তাই rollback-এর পথ আগেই অনুশীলন করা উচিত, যাতে সেদিন প্রথমবার না হয়।

৬ · মাপ: MTTD, MTTA, MTTR আর MTBF

উন্নতি হচ্ছে কি না বুঝতে চারটি সংক্ষিপ্ত নাম চলে। প্রতিটি শুরু আর শেষের দুটি মুহূর্ত দিয়ে সংজ্ঞায়িত। মুহূর্ত দুটি না বলে সংখ্যা বলা অর্থহীন, কারণ দলভেদে সংজ্ঞা আলাদা।

সতর্কতা: MTTR-এর R কোথাও repair, কোথাও recover, restore, respond বা resolve. কেউ গণনা শুরু করেন ধরা পড়ার মুহূর্ত থেকে। MTBF-ও কেউ এক ব্যর্থতার শুরু থেকে পরের শুরু পর্যন্ত মাপেন। DORA-র মাপে একই ধারণা সময়ের সাথে নতুন নাম পেয়েছে। প্রতিবেদনে সংজ্ঞা লিখে দিন।

এক মাসের ছয়টি কাল্পনিক incident-এর CSV নিচে আছে। Runnable Bash block awk দিয়ে MTTA আর MTTR বের করে। INC-3 মধ্যরাত পেরিয়েছে, তাই সময়ের বিয়োগ ঋণাত্মক হলে ১,৪৪০ মিনিট যোগ করতে হয়।

#!/usr/bin/env bash
set -euo pipefail

cat > incidents.csv <<'CSV'
id,sev,start,detect,ack,restored
INC-1,SEV-3,09:10,09:22,09:30,09:52
INC-2,SEV-2,14:05,14:08,14:10,14:33
INC-3,SEV-2,23:50,23:56,00:03,00:40
INC-4,SEV-3,11:20,11:31,11:34,11:49
INC-5,SEV-1,02:15,02:19,02:36,07:27
INC-6,SEV-1,20:04,20:09,20:12,20:41
CSV

awk -F, '
function mins(t, p) { split(t, p, ":"); return p[1] * 60 + p[2] }
function gap(a, b, d) { d = mins(b) - mins(a); return d < 0 ? d + 1440 : d }
NR > 1 {
  ta = gap($4, $5); tr = gap($3, $6)
  printf "%s %s  ack %2d min  restore %3d min\n", $1, $2, ta, tr
  sum_a += ta; sum_r += tr; n++
  print tr > "ttr.txt"
}
END { printf "incidents=%d MTTA=%.1f min MTTR=%.1f min\n", n, sum_a / n, sum_r / n }
' incidents.csv

sort -n ttr.txt | awk '{ v[NR] = $1 }
END { m = (NR % 2) ? v[(NR + 1) / 2] : (v[NR / 2] + v[NR / 2 + 1]) / 2
      printf "median restore=%.1f min, worst=%d min\n", m, v[NR] }'

INC-1 SEV-3  ack  8 min  restore  42 min
INC-2 SEV-2  ack  2 min  restore  28 min
INC-3 SEV-2  ack  7 min  restore  50 min
INC-4 SEV-3  ack  3 min  restore  29 min
INC-5 SEV-1  ack 17 min  restore 312 min
INC-6 SEV-1  ack  3 min  restore  37 min
incidents=6 MTTA=6.7 min MTTR=83.0 min
median restore=39.5 min, worst=312 min

নিচের simulator একই ডেটা থেকে MTTD, MTBF আর availability বের করে, আর দেখায় একটি ঘটনা বাদ দিলে MTTR কতটা বদলায়। সংখ্যা বদলে পরীক্ষা করুন।

// Incident metrics from one sample month (30 days). Times are HH:MM.
const set = [
  ['INC-1', '09:10', '09:22', '09:30', '09:52'],
  ['INC-2', '14:05', '14:08', '14:10', '14:33'],
  ['INC-3', '23:50', '23:56', '00:03', '00:40'],
  ['INC-4', '11:20', '11:31', '11:34', '11:49'],
  ['INC-5', '02:15', '02:19', '02:36', '07:27'],
  ['INC-6', '20:04', '20:09', '20:12', '20:41'],
];  // id, impact start, detected, acknowledged, service restored

const mins = t => +t.slice(0, 2) * 60 + +t.slice(3);
const gap = (a, b) => (mins(b) - mins(a) + 1440) % 1440;  // survives midnight
const mean = a => a.reduce((x, y) => x + y, 0) / a.length;
function median(a) {
  const s = [...a].sort((x, y) => x - y), m = s.length >> 1;
  return s.length % 2 ? s[m] : (s[m - 1] + s[m]) / 2;
}

const ttd = set.map(r => gap(r[1], r[2]));
const tta = set.map(r => gap(r[2], r[3]));
const ttr = set.map(r => gap(r[1], r[4]));
console.log('TTR list:', ttr.join(' '));
console.log('MTTD', mean(ttd).toFixed(1), ' MTTA', mean(tta).toFixed(1),
            ' MTTR', mean(ttr).toFixed(1), 'min');
console.log('median TTR', median(ttr), 'min');

const noBig = ttr.filter(x => x < 300);
console.log('MTTR without the one long incident', mean(noBig).toFixed(1), 'min');

const month = 30 * 24 * 60, down = ttr.reduce((x, y) => x + y, 0);
const mtbf = (month - down) / set.length, mttr = mean(ttr);
console.log('downtime', down, 'min of', month);
console.log('MTBF', mtbf.toFixed(0), 'min =', (mtbf / 60).toFixed(1), 'h');
console.log('availability', (100 * mtbf / (mtbf + mttr)).toFixed(3) + '%');

TTR list: 42 28 50 29 312 37
MTTD 6.8  MTTA 6.7  MTTR 83.0 min
median TTR 39.5 min
MTTR without the one long incident 37.2 min
downtime 498 min of 43200
MTBF 7117 min = 118.6 h
availability 98.847%

গড় নিয়ে বিতর্ক

Incident-এর সময়কাল সাধারণত সমান ছড়ানো থাকে না: অনেক ছোট, অল্প কিছু খুব লম্বা। এমন ডেটায় গড় অস্থির। Štěpán Davidovič তাঁর Incident Metrics in SRE (২০২১) প্রতিবেদনে simulation দিয়ে দেখান, incident কম থাকলে MTTR-এর বদল অনেক সময় শুধু কাকতাল হতে পারে। Verica Open Incident Database (VOID)-এর প্রতিবেদনেও একই ধরনের সতর্কতা আছে।

এর মানে MTTR ফেলে দেওয়া নয়, পড়ার ধরন বদলানো। Median আর p90 পাশাপাশি রাখুন, severity আলাদা করুন, অল্প ঘটনায় সিদ্ধান্ত নেবেন না, আর সংখ্যাকে দলের লক্ষ্য বানাবেন না। লক্ষ্য বানালে মানুষ incident ছোট দেখাতে বা না ঘোষণা করতে শুরু করেন। Goodhart-এর সূত্র এই কথাই বলে: মাপ লক্ষ্য হলে মাপ হিসেবে দুর্বল হয়ে পড়ে।

৭ · Blameless postmortem: মানুষ নয়, ব্যবস্থা

Postmortem হলো ঘটনার পরের লিখিত পর্যালোচনা। Blameless মানে হলো ধরে নেওয়া: সেই সময়ের তথ্য নিয়ে মানুষটি তার বিবেচনায় ঠিক কাজই করছিলেন। John Allspaw-র Etsy ব্লগের লেখা “Blameless PostMortems and a Just Culture” (২০১২) এবং SRE বইয়ের ১৫তম অধ্যায় এই ধারণাকে প্রচলিত করে। শাস্তির ভয় থাকলে মানুষ তথ্য লুকান, আর লুকানো তথ্য থেকে কিছু শেখা যায় না।

একটি root cause, না একাধিক কারণ

কথায় বলি “root cause”, যেন এক শিকড় তুলে ফেললেই শেষ। জটিল সিস্টেমে ব্যর্থতা সাধারণত কয়েকটি শর্তের যোগফল। James Reason-এর Swiss cheese model (১৯৯০) বলে, প্রতিটি সুরক্ষা স্তরে ফুটো থাকে, ফুটোগুলো এক সারিতে পড়লে দুর্ঘটনা ঘটে। Richard Cook-এর “How Complex Systems Fail” (১৯৯৮) সোজাই বলে, ঘটনার পরে একটি root cause দাঁড় করানো মূলত ভুল। তাই অনেক দল এখন “contributing factors” বলে।

5 Whys Toyota-র উৎপাদন ব্যবস্থা থেকে এসেছে, Sakichi Toyoda আর Taiichi Ohno-র নামের সাথে জড়িয়ে। প্রতিটি উত্তরে আবার “কেন” জিজ্ঞেস করে গভীরে যাওয়া। শুরুর জন্য ভালো অভ্যাস। কিন্তু এর সীমা আছে: এটি একটিমাত্র সরল রেখায় হাঁটে, প্রশ্নকারী কোথায় থামবেন তাতে ফল বদলায়, দুজন আলাদা উত্তর পান, আর শেষে প্রায়ই “মানুষের ভুল”-এ পৌঁছায়। Allspaw তাঁর “The Infinite Hows” (২০১৪) লেখায় “কেন”-এর বদলে “কীভাবে” জিজ্ঞেস করতে বলেন। “কেন ভুল করলেন” কৈফিয়ত চায়, “কীভাবে কাজটি যুক্তিসঙ্গত মনে হলো” তথ্য খোঁজে। পেছন থেকে সব স্পষ্ট দেখায়, একে hindsight bias বলে।

নিচে একই ঘটনার একটি খসড়া দোষারোপ থেকে ব্যবস্থার ভাষায় বদলে যাচ্ছে। প্রতিটি ধাপে কী মুছে গেল, আর কী যোগ হলো, দেখুন।

রাফি খারাপ query deploy করেছে।
তার আরও সাবধান হওয়া উচিত ছিল।
action: রাফিকে সতর্ক করা

একজন developer v4.18 deploy করেন।
Review পাস, CI সবুজ, staging ঠিক।
প্রশ্ন: তখন কাজটি নিরাপদ মনে হলো কীভাবে?

Staging-এ coupon সারি ২ হাজার,
production-এ ২ কোটি।
Load test চলেছে ×২ চাপে, সেল ছিল ×৬.
সেলের ২০ মিনিট আগে release, আটকানোর নিয়ম নেই।

ক. ধীর query ধরার কোনো পরীক্ষা নেই
খ. Staging-এর ডেটা production-এর মতো নয়
গ. Sale-এর চাপে load test হয়নি
ঘ. Client retry-তে backoff নেই
যেকোনো একটি থাকলে ক্ষতি কমত

মুছল: “... করা উচিত ছিল”
যোগ হলো: সেই সময়ে দলের কাছে
query-র সময় দেখানোর কোনো dashboard
ছিল না। তাই ধীর হওয়া চোখে পড়েনি।

Detect: query সময়ের alert
  মালিক: payments · ১৫ দিন
Prevent: CI-তে ধীর query পরীক্ষা
  মালিক: platform · ৩০ দিন
Mitigate: runbook-এ waiting room
  মালিক: on-call lead · ৭ দিন

Timeline লেখাই postmortem-এর সবচেয়ে সময়খেকো কাজ। Scribe-এর নোট, alert আর chat মিলিয়ে সাজাতে হয়। নিচের timeline builder এলোমেলো chat লাইন পড়ে, অপ্রাসঙ্গিক কথা বাদ দেয়, সময় অনুযায়ী সাজায়, প্রভাব শুরু থেকে কত মিনিট তা লেখে, আর প্রতিটি লাইনের ধরন বসায়।

// Turn raw chat lines into a postmortem table. Lines arrive out of order.
const raw = `
20:12 rafi: ack, looking at checkout
20:09 pager: ALERT checkout burn rate high
20:13 mitu: who has the tea money? lol
20:15 rafi: declare SEV-1, channel inc-eid
19:40 ci: deploy checkout v4.18 done
20:18 nadia: commander: nadia, ops: rafi
20:22 mitu: status page: investigating
20:04 graph: checkout 5xx crossed 5 percent
20:26 rafi: rollback to v4.17 started
20:34 rafi: rollback done, errors 9 percent
20:38 nadia: waiting room on, retries cut
20:41 graph: checkout 5xx under 1 percent
20:52 mitu: status page: mitigated, monitoring
21:22 mitu: status page: still monitoring
21:40 nadia: all clear, closing incident`;
const RULES = [[/deploy/, 'change'], [/crossed/, 'impact'], [/ALERT/, 'detect'],
  [/\back\b/, 'ack'], [/declare/, 'declare'], [/commander/, 'roles'],
  [/status page/, 'comms'], [/rollback|waiting room/, 'action'],
  [/under 1 percent/, 'restored'], [/all clear/, 'resolved']];
const mins = t => +t.slice(0, 2) * 60 + +t.slice(3);
const events = [];
for (const line of raw.trim().split('\n')) {
  const m = line.match(/^(\d\d:\d\d) (\w+): (.*)$/);
  const rule = RULES.find(r => r[0].test(m[3]));
  if (rule) events.push({ t: m[1], who: m[2], kind: rule[1], text: m[3] });
  else console.log('dropped:', line);
}
events.sort((a, b) => mins(a.t) - mins(b.t));
const start = mins(events.find(e => e.kind === 'impact').t);
for (const e of events) {
  const d = mins(e.t) - start;
  console.log(e.t, String(d).padStart(4), e.kind.padEnd(9), e.text);
}

dropped: 20:13 mitu: who has the tea money? lol
19:40  -24 change    deploy checkout v4.18 done
20:04    0 impact    checkout 5xx crossed 5 percent
20:09    5 detect    ALERT checkout burn rate high
20:12    8 ack       ack, looking at checkout
20:15   11 declare   declare SEV-1, channel inc-eid
20:18   14 roles     commander: nadia, ops: rafi
20:22   18 comms     status page: investigating
20:26   22 action    rollback to v4.17 started
20:34   30 action    rollback done, errors 9 percent
20:38   34 action    waiting room on, retries cut
20:41   37 restored  checkout 5xx under 1 percent
20:52   48 comms     status page: mitigated, monitoring
21:22   78 comms     status page: still monitoring
21:40   96 resolved  all clear, closing incident

৮ · ঈদ সেলের outage: শুরু থেকে শেষ

এবার একটি কাল্পনিক অনলাইন বাজার অ্যাপের পুরো ঘটনা। ঈদের আগের সন্ধ্যায় ২০:০০-এ সেল শুরু, traffic স্বাভাবিকের ×৬। ১৯:৪০-এ checkout-এর v4.18 release হয়েছে, যাতে coupon যাচাইয়ের নতুন query আছে, কিন্তু index নেই। প্রতিটি অনুরোধ database connection pool-এর সংযোগ বেশি সময় ধরে রাখে। ঈদের আগে বাসের টিকিট কাউন্টারের মতো: একজন যাত্রী বেশি সময় নিলে পেছনের লাইন দ্রুত লম্বা হয়।

ক্ষতির হিসাব আর পরের কাজ

ধরে নিই সেলে মিনিটে ৩০০ চেকআউট চেষ্টা হয়। সবচেয়ে খারাপ হার ৬২% পুরো ৩৭ মিনিট ধরলে ৩০০ × ৩৭ × ০.৬২ = ৬,৮৮২টি ব্যর্থ চেষ্টা। এটি ওপরের সীমা, কারণ শেষ দিকে হার ৯%-এ নেমেছিল। অনেকে পরে আবার চেষ্টাও করেছেন, তাই এটি হারানো অর্ডারের সংখ্যা নয়।

৯ · অন্যের postmortem, game day আর on-call-এর ভার

নিজের ভুলের চেয়ে অন্যের প্রকাশিত ভুল থেকে শেখা সস্তা। নিচের সারাংশ প্রতিষ্ঠানগুলোর নিজের প্রকাশিত বিবরণের ওপর ভিত্তি করে, বিস্তারিত ও সংখ্যা মূল লেখায় মিলিয়ে নেবেন।

Game day: বিপদের আগে মহড়া

Game day হলো নির্ধারিত দিনে ইচ্ছা করে সমস্যা সাজিয়ে দলকে পরীক্ষা করা, যেমন ফায়ার সার্ভিসের মহড়া। Jesse Robbins Amazon-এ ২০০০-এর দশকের শুরুতে এমন অনুশীলন চালু করেন বলে জানা যায়, আর Google তাদের DiRT অনুশীলন নিয়ে লিখেছে (ACM Queue, ২০১২)। শুরু করতে কিছু ভাঙতেই হবে এমন নয়। Tabletop অনুশীলনে শুধু টেবিলে বসে বলা হয়: “ধরা যাক database চলে গেছে, এখন কী করবেন?” পরে staging-এ, তারপর সাবধানে production-এ। লক্ষ্য তিনটি: runbook কাজ করে কি না, নতুন মানুষ পারেন কি না, আর ভূমিকাগুলো জানা আছে কি না। ইচ্ছাকৃত ব্যর্থতার পদ্ধতি নিয়ে বিস্তারিত দেখবেন পর্ব ৬৮-তে।

On-call-এর ভার আর burnout

ঘুম ভাঙা মানুষ সিস্টেমের অংশ। SRE বইয়ের ১১তম অধ্যায় ভাগের একটি হিসাব দেয়: একটি incident সামলাতে, মূল কারণ খুঁজতে, ঠিক করতে আর postmortem লিখতে গড়ে প্রায় ৬ ঘণ্টা লাগে, তাই ৮-১২ ঘণ্টার পালায় সর্বোচ্চ প্রায় ২টি incident. একই বই on-call-কে SRE-র সময়ের ২৫%-এর মধ্যে রাখার কথা বলে। এগুলো Google-এর লক্ষ্য, আপনার দলের জন্য শুরুর একটি রেফারেন্স।

• ভার মাপুন: প্রতি পালায় page-এর সংখ্যা, রাতের page, আর কতগুলোর পেছনে আসল কাজ ছিল। অকাজের page-ই alert fatigue তৈরি করে।
• ঘুমের দাম দিন: রাতে জাগলে পরদিন ছুটি বা সময়-ক্ষতিপূরণের নিয়ম লিখে রাখুন। শ্রম আইন আর চুক্তি দেশভেদে আলাদা, প্রতিষ্ঠানের নিয়ম যাচাই করুন।
• পালা ন্যায্য রাখুন: অন্তত দুজনের সারি (primary, secondary), নতুনদের জন্য ছায়া-পালা, আর পালা বদলে ছোট handoff.
• বিশ্বজুড়ে দল থাকলে: Follow the sun ব্যবস্থায় দিনের আলোয় থাকা দল পালা নেয়, রাতের ডাক কমে। ছোট দলে সেটি সম্ভব নয়, তাই কম page-ই প্রধান পথ।
• বড় ঘটনার পরে: মানুষকে বিশ্রাম দিন। ক্লান্ত দলে পরের ভুলের ঝুঁকি বেশি, আর একই সমস্যায় বারবার page হওয়া toil, যা action item-এ নামা উচিত।

১০ · AI-এর যুগে incident সামলানো

AI incident-এ সত্যিই কাজে লাগে: লম্বা log সংক্ষেপ করা, chat থেকে timeline-এর খসড়া, status আপডেটের ভাষা, postmortem-এর প্রথম খসড়া। কিন্তু সে আপনার সিস্টেম দেখতে পায় না, আর ভুলও খুব আত্মবিশ্বাসে বলে। চাপের মুহূর্তে এটিই বড় বিপদ। সাধারণ ভুলগুলো হলো:

AI-এর incident পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Command চালানোর আগে অর্থ বুঝেছি, --dry-run বা terraform plan দেখেছি
• Destructive কিছু হলে commander-কে জানিয়েছি, দ্বিতীয় জন দেখেছেন
• Flag আর API version সরকারি নথিতে আছে, বানানো নয়
• সম্ভব হলে ফেলে দেওয়ার মতো পরিবেশে আগে পরীক্ষা করেছি, diff পড়েছি
• কোনো * permission, 0.0.0.0/0 বা public storage ঢোকেনি, আর latest tag নেই
• Prompt-এ কোনো secret, token বা গ্রাহকের তথ্য দিইনি
• Timeline-এর প্রতিটি সময় আর সংখ্যা আসল log বা chat-এ মিলিয়েছি
• Mitigation-এর খরচ ভেবেছি, budget alert চালু আছে