کسی واقعہ کے پیش آنے سے پہلے آپریشنل ڈرفٹ کا پتہ لگانے کا طریقہ

پچھلے مضمون میں، میں نے آپریشنل کافییت کی کھوج کی تھی، یعنی یہ کیسے اندازہ لگایا جائے کہ آیا مشاہدہ شدہ شواہد آپریشنل تصریحات پر پورا اترتے ہیں۔

یہ مفید پوائنٹ ان ٹائم سوالات فراہم کرتا ہے۔

کیا نظام موجودہ تصریحات کو پورا کرتا ہے؟

لیکن پیداواری نظام ابھی تک کھڑے نہیں ہیں۔

نقل و حمل کی تبدیلیاں۔ انحصار کم ہوتا ہے۔ آپ کے سرٹیفکیٹ کی میعاد ختم ہو رہی ہے۔ ترتیب طے کر دی گئی ہے۔ خصوصیت کے جھنڈے منتقل ہو گئے ہیں۔ ڈیٹا بڑھتا ہے۔ لوگ اسے دستی طور پر تبدیل کرتے ہیں۔ ایجنٹ کارروائی کرتا ہے۔ انفراسٹرکچر کو تبدیل کیا جاتا ہے۔ وغیرہ

ایک نظام تعیناتی کے فوراً بعد مطابقت پذیر ہو سکتا ہے اور گھنٹوں یا دنوں بعد تعمیل کرنا بند کر سکتا ہے۔

یہ وہ مسئلہ ہے جسے میں یہاں دریافت کرنا چاہتا ہوں۔

آپریشنل ڈرفٹ آپریشنل تصریحات اور وقت کے ساتھ مشاہدہ شدہ حالت کے درمیان فرق ہے۔

یہ کنفیگریشن ڈرفٹ سے زیادہ وسیع ہے۔ کنفیگریشن ڈرفٹ پوچھتا ہے کہ آیا آپ کا انفراسٹرکچر یا کنفیگریشن اس کی اعلان کردہ حالت سے مختلف ہے۔

آپریشنل ڈرفٹ پوچھتا ہے کہ آیا کوئی نظام اپنی مطلوبہ حدود میں کام کرتا رہے گا چاہے اس کی ترتیب بالکل تبدیل نہ ہوئی ہو۔

کسی سروس کی بالکل وہی ترتیب ہو سکتی ہے جس طرح اس نے کل کی تھی، لیکن یہ بڑھتی ہوئی تاخیر، کم خرابی کی شرح، کم نقل کی دستیابی، انحصار غیر صحت مند ہونے، پالیسیوں کے مزید نافذ نہ ہونے، یا شواہد کے غائب ہونے کے ساتھ چلتی چلی جا سکتی ہے۔

اس آرٹیکل میں، ہم آپ کو دکھائیں گے کہ کس طرح آپریشنل ڈرفٹ کو ماڈل بنانا ہے، تعمیل کا معیار کیسے طے کرنا ہے، وقت کے ساتھ اپنے سسٹم کا دوبارہ جائزہ لینا، عارضی شور سے معنی خیز فرق کو الگ کرنا، بڑھے ہوئے شواہد کو محفوظ کرنا، شدت کی درجہ بندی کرنا، اور اس بات کا تعین کرنا کہ ڈرفٹ کب الرٹ، تفتیش، یا خودکار ردعمل کو متحرک کرے۔

بنیادی خیال یہ ہے۔ مطابقت ہمیں بتاتی ہے کہ آیا حقیقت وقت کے کسی خاص موڑ پر ہمارے ارادوں سے میل کھاتی ہے۔ ڈرفٹ آپ کو بتاتا ہے کہ آیا رشتہ بدل رہا ہے۔

شرطیں

آپ کو اس کے ساتھ آرام دہ ہونا چاہئے:

• سافٹ ویئر فن تعمیر

• TypeScript یا اس سے ملتی جلتی زبان

• مشاہدہ

• آپریٹنگ وضاحتیں

• ثبوت پر مبنی تشخیص

• مطابقت

• نگرانی کے بنیادی تصورات

کسی مخصوص انفراسٹرکچر پلیٹ فارم کی ضرورت نہیں ہے۔

اگرچہ مثالیں تعیناتی کے منظرناموں کا استعمال کرتی ہیں، لیکن یہی ماڈل انفراسٹرکچر، ڈیٹا پائپ لائنز، بیک اپ سسٹمز، ایکسیس کنٹرول، AI ایجنٹس، اور دیگر آپریشنل ورک فلو پر لاگو ہوتا ہے۔

انڈیکس

آپریشنل ڈرفٹ کا کیا مطلب ہے؟

فرض کریں کہ تعیناتی 10:00 بجے مکمل ہوتی ہے۔

آپریٹنگ وضاحتیں بیان کرتی ہیں:

version = v42
available replicas >= 3
error rate <= 1%
p95 latency <= 400 ms

تعیناتی کے فوراً بعد، شواہد بتاتے ہیں کہ:

version = v42
available replicas = 3
error rate = 0.4%
p95 latency = 280 ms

نظام موزوں ہے۔

اب فرض کریں کہ 14:00 پر شواہد درج ذیل ہیں:

version = v42
available replicas = 3
error rate = 0.8%
p95 latency = 370 ms

نظام اب بھی تعمیل ہے، لیکن کچھ بدل گیا ہے۔

خرابی کی شرح اور تاخیر اپنی حدود کو پہنچ رہی ہے۔

16:00:

version = v42
available replicas = 3
error rate = 1.4%
p95 latency = 460 ms

اب یہ نظام مناسب نہیں رہا۔

آپریٹنگ وضاحتیں تبدیل نہیں ہوئی ہیں۔ ایگزیکیوٹر کو دوبارہ چلانے کی ضرورت نہیں ہے۔ لیکن حقیقت بدل گئی ہے۔

یہ آپریشنل ڈرفٹ ہے۔

اس کے بارے میں سوچنے کا ایک مفید طریقہ یہ ہے:

Specification
      ↓
Expected operational boundaries
      ↓
Observed state at T0
      ↓
Observed state at T1
      ↓
Observed state at T2
      ↓
Drift evaluation

بنیادی خیال وقتی ہے۔ فٹ ایک سنیپ شاٹ ہے، جبکہ ڈرفٹ سنیپ شاٹس کے درمیان تعلق ہے۔

آپریشنل ڈرفٹ کنفیگریشن ڈرفٹ جیسا نہیں ہے۔

کنفیگریشن ڈرفٹ شاید ایک بنیادی ڈھانچے کا تصور ہے جس سے آپ واقف ہیں۔

کی طرف سے ترتیب بڑھےاعلان کردہ کنفیگریشن یا انفراسٹرکچر اسٹیٹ اور اس ریاست کے درمیان فرق جو حقیقت میں ماحول میں موجود ہے۔

مثال کے طور پر:

desired replicas = 3
actual replicas = 2

یہاں اعلان کردہ ریاست کہتی ہے کہ سروس میں 3 نقلیں ہونی چاہئیں، لیکن چلنے والے ماحول میں صرف 2 ہیں۔ کنفیگریشن اور اصل حالت اب مماثل نہیں ہے۔

یا:

Terraform state != deployed infrastructure

اس صورت میں، یا تو انفراسٹرکچر متوقع Terraform کے زیر انتظام ریاست سے باہر تبدیل ہو گیا ہے، یا Terraform کی تاریخ اصل تعیناتی کی تاریخ سے مماثل نہیں ہے۔

دونوں کنفیگریشن ڈرفٹ ہیں کیونکہ اعلان کردہ کنفیگریشن اور اس ماحول کے درمیان کوئی مماثلت نہیں ہے جس کی عکاسی کی جاتی ہے۔

مفید، لیکن تنگ۔

آپریشنل ڈرفٹ موجود ہوسکتا ہے یہاں تک کہ اگر کنفیگریشن تبدیل نہ ہوئی ہو۔

مندرجہ ذیل وضاحتیں پر غور کریں:

error rate <= 1%

آپ کی تعیناتی کی ترتیب اب بھی وہی ہو سکتی ہے جو کل تھی۔

تاہم، ٹریفک مکس تبدیل ہو سکتا ہے، ڈاؤن اسٹریم APIs سست ہو سکتے ہیں، ڈیٹا بیس کے اشاریہ جات میں کمی ہو سکتی ہے، سرٹیفکیٹس کی میعاد ختم ہونے کے قریب ہو سکتی ہے، یا قطار کے بیک لاگ میں اضافہ ہو سکتا ہے۔

تو:

configuration drift
=
declared configuration != actual configuration

جبکہ:

operational drift
=
observed operational state != intended operational boundaries

دونوں اوورلیپ ہو سکتے ہیں، لیکن وہ ایک جیسے نہیں ہیں۔

یہ فرق اہم ہے کیونکہ پیداواری ناکامیاں اکثر تعمیر سے پہلے عمل کی ناکامی ہوتی ہیں۔

تعمیل کے معیار کے ساتھ شروع کریں۔

ڈرفٹ کو ایک حوالہ نقطہ درکار ہے۔ سب سے آسان حوالہ تعمیل کی معلوم حالت ہے۔

مثال کے طور پر:

type DeploymentEvidence = {
  version?: string;
  replicas?: number;
  errorRate?: number;
  p95LatencyMs?: number;
};

ہم فرض کرتے ہیں کہ تعیناتی کے بعد نظام کا جائزہ لیا گیا ہے۔

const baseline: DeploymentEvidence = {
  version: "v42",
  replicas: 3,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

تمام مطلوبہ رکاوٹیں گزر چکی ہیں۔

یہ بیس لائن معلومات کے دو مفید ٹکڑے فراہم کرتی ہے۔

سب سے پہلے، آپ دیکھ سکتے ہیں کہ سسٹم نے اس وقت تصریحات کو پورا کیا ہے۔ دوسرا، آپ کے پاس شواہد کا ایک ٹھوس اسنیپ شاٹ ہے جس کا آپ بعد میں اپنے مشاہدات سے موازنہ کر سکتے ہیں۔

اس کا مطلب یہ نہیں ہے کہ بعد میں آنے والے شواہد کو بیس لائن سے بالکل مماثل ہونا چاہیے۔ یہ بہت سخت ہوگا۔

اس کا مطلب یہ ہے کہ بعد کے شواہد کو دو طریقوں سے جانچا جا سکتا ہے۔

Does it still satisfy the specification?

How is it changing relative to the baseline?

یہ ایک الگ سوال ہے۔ دونوں مفید ہیں۔

وقت کے ساتھ انہی رکاوٹوں کا مشاہدہ کریں۔

مان لیں کہ آپ ہر گھنٹے ثبوت جمع کرتے ہیں۔

type TimedEvidence = {
  timestamp: string;
  evidence: DeploymentEvidence;
};

مثال کے طور پر:

const observations: TimedEvidence[] = [
  {
    timestamp: "10:00",
    evidence: {
      version: "v42",
      replicas: 3,
      errorRate: 0.004,
      p95LatencyMs: 280,
    },
  },
  {
    timestamp: "12:00",
    evidence: {
      version: "v42",
      replicas: 3,
      errorRate: 0.006,
      p95LatencyMs: 320,
    },
  },
  {
    timestamp: "14:00",
    evidence: {
      version: "v42",
      replicas: 3,
      errorRate: 0.008,
      p95LatencyMs: 370,
    },
  },
];

ہر مشاہدے کا ایک ہی تصریح کے خلاف جائزہ لیا جا سکتا ہے۔

یہ مطابقت کا ایک سلسلہ فراہم کرتا ہے۔

10:00  PASS
12:00  PASS
14:00  PASS

پہلی نظر میں، سب کچھ صحت مند لگ رہا ہے. لیکن اگر آپ قریب سے دیکھیں تو آپ دیکھیں گے کہ شواہد ایک سمت میں بڑھ رہے ہیں۔

یہ وہ جگہ ہے جہاں بڑھے ہوئے کا پتہ لگانا عام حد کی نگرانی سے زیادہ دلچسپ ہو جاتا ہے۔

واضح طور پر بڑھے ہوئے ماڈل

کم از کم بہاؤ کا نتیجہ یہ ہے:

type DriftStatus =
  | "STABLE"
  | "DEGRADING"
  | "VIOLATED"
  | "UNKNOWN";

یہ جائزہ لینے والے کو چار واضح حالتیں دیتا ہے: STABLE اس کا مطلب یہ ہے کہ مشاہدہ شدہ سلوک متوقع حد کے اندر بغیر کسی خاص بگاڑ کے رہتا ہے۔ DEGRADING اس کا مطلب یہ ہے کہ نظام اب بھی قبول شدہ حدود کے اندر ہے، لیکن ایک ناموافق سمت میں آگے بڑھ رہا ہے۔ VIOLATED اس کا مطلب یہ ہے کہ موجودہ شواہد تصریح کی حد سے زیادہ ہیں۔ UNKNOWN اس کا مطلب ہے کہ ریاست کو محفوظ طریقے سے درجہ بندی کرنے کے لیے کافی ثبوت نہیں ہیں۔

پھر:

type DriftResult = {
  constraint: string;
  status: DriftStatus;
  baseline?: number;
  current?: number;
  limit?: number;
};

DriftResult درجہ بندی کو بیان کرنے والی اقدار کے ساتھ درجہ بندی کو برقرار رکھتا ہے۔ baseline ایک معروف اچھا حوالہ ہے۔ current یہ تازہ ترین مشاہدہ ہے، limit تصریح کے ذریعے بیان کردہ حدود۔ یہ فیلڈز اختیاری ہیں کیونکہ کچھ رکاوٹیں عددی نہیں ہوسکتی ہیں یا کچھ ثبوت غائب ہوسکتے ہیں۔

انتظار کے وقت کے لیے:

baseline = 280
current = 370
limit = 400

اس مثال میں، ہم کہتے ہیں کہ لیٹنسی 280ms کی معلوم اچھی قدر سے شروع ہوتی ہے، اب 370ms پر ہے، اور اسے 400ms سے کم رہنا چاہیے۔ رکاوٹ ناکام نہیں ہوئی ہے، لیکن موجودہ قدر حد کے بہت قریب ہے۔

یہ لیبل لگانے کے قابل ہو سکتا ہے.

DEGRADING

لہذا، بڑھے ہوئے ماڈل فٹ کا متبادل نہیں ہیں۔ یہ ایک اور جہت کا اضافہ کرتا ہے۔

آپ کے پاس ہو سکتا ہے:

conformance = PASS
drift = DEGRADING

یہ مجموعہ اکثر اکیلے سگنل استعمال کرنے سے زیادہ قابل عمل ہوتا ہے۔

عارضی اتار چڑھاؤ ہمیشہ نہیں بڑھتے ہیں۔

پیداواری نظام میں شور ہے۔

ایک سست درخواست کا مطلب یہ نہیں ہے کہ سسٹم بہتا ہے۔ ایک نمونہ غائب ہونے کا مطلب یہ نہیں ہے کہ سروس غیر معمولی ہے۔ اور ایک عارضی اضافہ ضروری نہیں کہ مداخلت کا جواز پیش کرے۔

فرض کریں کہ آپ کی تاخیر کا نمونہ ہے:

280
290
420
285
295

کہ 420 نمونہ حد سے تجاوز کر گیا۔ تاہم، نظام فوری طور پر معمول پر آ جاتا ہے۔

اس کا موازنہ کریں:

280
310
340
370
395

دوسرا سلسلہ حد سے تجاوز نہیں کر سکتا۔ تاہم، یہ مسلسل انحطاط کو ظاہر کرتا ہے۔

اسی لیے بڑھے کی تعریف اس طرح نہیں کی جانی چاہیے:

current != baseline

یا یہاں تک کہ:

one sample crossed threshold

استقامت اور سمت پر غور کرتے وقت بہاؤ زیادہ مفید ہے۔

کسی ایک نمونے کے بجائے ونڈوز کا استعمال کریں۔

ایک بہتر طریقہ یہ ہے کہ ونڈو کے ذریعے مشاہدات کا جائزہ لیا جائے۔

مثال کے طور پر:

function average(
  values: number[]
): number {
  return (
    values.reduce(
      (sum, value) => sum + value,
      0
    ) / values.length
  );
}

اب ہم کہتے ہیں کہ ہم آخری پانچ تاخیر کے مشاہدات کا جائزہ لینا چاہتے ہیں۔

const latencyWindow = [
  300,
  320,
  340,
  360,
  380,
];

const currentAverage =
  average(latencyWindow);

اس سے عارضی شور کم ہو جائے گا۔

آپ اس ونڈو کا پچھلی ونڈو سے موازنہ کر سکتے ہیں۔

const baselineWindow = [
  270,
  275,
  280,
  285,
  290,
];

const baselineAverage =
  average(baselineWindow);

پچھلی ونڈو مشترکہ کارروائیوں کے لیے ایک مختصر تاریخی حوالہ فراہم کرتی ہے۔ بعد کی ونڈوز سب سے حالیہ آپریٹنگ حیثیت کی نشاندہی کرتی ہیں۔ دو اوسطوں کا موازنہ کرنے سے اس بات کا تعین کرنے میں مدد ملتی ہے کہ آیا ایک غیر معمولی نمونے پر ردعمل ظاہر کرنے کے بجائے پورا سگنل بدل گیا ہے۔

پھر تبدیلیوں کا حساب لگائیں۔

const delta =
  currentAverage -
  baselineAverage;

اگر baselineAverage 280ms currentAverage 340ms اور ڈیلٹا ہے۔ +60 ms. اس کا مطلب یہ نہیں ہے کہ تاخیر کی رکاوٹ ناکام ہوگئی ہے، لیکن یہ ظاہر کرتا ہے کہ حالیہ تاخیر پچھلی ونڈوز سے کافی حد تک بدتر ہیں۔

یہ ثابت نہیں کرتا کہ کوئی مسئلہ ہے، لیکن یہ زیادہ مستحکم سگنل فراہم کرتا ہے۔

ونڈو کا درست سائز آپریٹنگ سیاق و سباق سے آنا چاہیے۔

5 منٹ کا انتظار کا وقت مناسب ہو سکتا ہے۔ اسٹوریج کی ترقی کے لیے ایک دن کا ٹائم فریم زیادہ مناسب ہو سکتا ہے۔

بڑھے ہوئے اور گمشدہ ثبوت کے درمیان فرق کریں۔

یہ مطابقت کے طور پر انہی اصولوں پر عمل کرتا ہے۔

فرض کریں کہ تاخیر کا ثبوت غائب ہو جاتا ہے۔

یہ ایک جیسا نہیں ہے:

latency is stable

اور یہ اس طرح نہیں ہے:

latency violated the threshold

کہ:

UNKNOWN

مثال کے طور پر:

function evaluateLatencyDrift(
  baseline: number | undefined,
  current: number | undefined,
  limit: number
): DriftStatus {
  if (
    baseline === undefined ||
    current === undefined
  ) {
    return "UNKNOWN";
  }

  if (current > limit) {
    return "VIOLATED";
  }

  if (current > baseline) {
    return "DEGRADING";
  }

  return "STABLE";
}

یہ فنکشن جان بوجھ کر کیسز کا جائزہ لیتا ہے۔ سب سے پہلے، اگر بیس لائن یا موجودہ مشاہدہ غائب ہے، تو یہ واپس آتا ہے: UNKNOWN اس کی وجہ یہ ہے کہ محفوظ موازنہ کرنے کے لیے کافی ثبوت نہیں ہیں۔ اگر ثبوت موجود ہے اور موجودہ قدر پہلے سے ہی اجازت شدہ حد سے تجاوز کر گئی ہے تو لوٹاتا ہے۔ VIOLATED. اگر قدر اب بھی حد سے کم ہے لیکن بیس لائن سے بدتر ہے تو واپس کیا گیا۔ DEGRADING. یہ صرف اس صورت میں واپس کیا جائے گا جب ان میں سے کوئی بھی شرط لاگو نہ ہو۔ STABLE.

یہ اب بھی آسان ہے کیونکہ بیس لائن کے اوپر اضافہ یہ ہے: DEGRADINGیہ درست ہے چاہے تبدیلی معمولی ہو یا عارضی۔ حقیقی دنیا کے نظام عام طور پر اسے رواداری، ونڈو، استقامت، یا رجحان کے اصولوں کے ساتھ جوڑتے ہیں۔ تاہم، یہاں ایک اہم اصول محفوظ ہے۔ ثبوت کی عدم موجودگی کا مطلب یہ نہیں کہ یہ مستحکم ہے۔

یہ خاص طور پر اس وقت اہم ہو جاتا ہے جب مشاہداتی نظام خود ہی خراب ہو جاتا ہے۔

شدت اور استقامت شامل کریں۔

ڈرفٹ زیادہ مفید ہو جاتا ہے جب آپ جانتے ہوں کہ رکاوٹیں کتنی اہم ہیں اور کتنی دیر تک بڑھی ہوئی ہے۔

مثال کے طور پر:

type DriftSeverity =
  | "INFO"
  | "WARNING"
  | "CRITICAL";

type DriftObservation = {
  constraint: string;
  status: DriftStatus;
  severity: DriftSeverity;
  consecutiveWindows: number;
};

یہاں، severity متاثرہ رکاوٹوں کے آپریشنل اثر کو بیان کرتا ہے۔ consecutiveWindows مشاہداتی کھڑکیوں کی تعداد ریکارڈ کریں جنہوں نے یکے بعد دیگرے ایک جیسے بڑھے ہوئے حالات پیدا کئے۔ ایک سادہ انتباہ آٹھ مسلسل وارننگوں سے مختلف ہے، اور ایک سنگین نقل کی خلاف ورزی کے لیے کارروائی کی ضرورت پڑ سکتی ہے چاہے یہ صرف دو بار ظاہر ہو، اس لیے دونوں مسائل کو برقرار رکھا جانا چاہیے۔

اب ہم ان میں فرق کر سکتے ہیں:

latency
DEGRADING
WARNING
1 window

پر:

latency
DEGRADING
WARNING
8 windows

اور:

replicas
VIOLATED
CRITICAL
2 windows

دوسرا سگنل زیادہ مستقل اور تیسرا زیادہ شدید ہے۔

اس سے آپ کو یہ فیصلہ کرنے میں مدد ملے گی کہ کون سا جواب مناسب ہے۔

حد کی ناکامی سے پہلے دشاتمک بڑھے کا پتہ لگائیں۔

بہاؤ کا پتہ لگانے کے سب سے زیادہ مفید پہلوؤں میں سے ایک دشاتمک حرکت کو پہچاننا ہے۔

فرض کریں کہ غلطی کی شرح کی حدیں ہیں:

1%

مشاہدات درج ذیل ہیں:

0.2%
0.4%
0.6%
0.8%

ابھی تک کوئی ناکامی نہیں ہوئی ہے، لیکن رجحان واضح ہے۔

ایک سادہ ڈھلوان اس سمت کو پکڑ سکتی ہے۔

مثال کے طور پر:

function slope(
  values: number[]
): number {
  if (values.length < 2) {
    return 0;
  }

  return (
    values[values.length - 1] -
    values[0]
  ) / (values.length - 1);
}

یہ مددگار سیریز میں پہلی اور آخری قدروں کو دیکھتا ہے اور فرق کو دو قدروں کے درمیان وقفوں کی تعداد سے تقسیم کرتا ہے۔ یہ جان بوجھ کر سادہ رجحان کا اشارہ ہے۔ مثبت نتیجہ کا مطلب ہے کہ ونڈو میں میٹرک بڑھ گیا ہے، منفی نتیجہ کا مطلب ہے کہ اس میں کمی آئی ہے، اور 0 کے قریب قدر کا مطلب ہے کہ تقریباً کوئی تبدیلی نہیں ہوئی۔

پھر:

const errorRates = [
  0.002,
  0.004,
  0.006,
  0.008,
];

const trend =
  slope(errorRates);

یہاں غلطی کی شرح اس طرح بڑھتی ہے: 0.002 کو 0.008تو trend مثبت کوڈ مستقبل کی پیشین گوئی کرنے یا مکمل شماریاتی تجزیہ کرنے کی کوشش نہیں کرتا ہے۔ خیال تبدیلی کی سمت کو واضح کرنا ہے تاکہ نظام جاری تحریک کو پہچان سکے۔ 1% یہ حد ہے اس سے پہلے کہ اسے عبور کیا جائے۔

مثبت رجحان کا مطلب خود بخود ناکامی نہیں ہے، لیکن یہ اس بات کی نشاندہی کرتا ہے کہ نظام ایک حد کی طرف بڑھ رہا ہے۔

یہ وہ جگہ ہے جہاں بڑھے کا پتہ لگانا بنیادی انتباہات سے مختلف ہے۔

ڈیفالٹ حد انتباہ:

tell me when error rate > 1%

بڑھے کا پتہ لگانا:

tell me when error rate is persistently moving toward 1%

دوسرا، یہ نظام کے غیر تعمیل ہونے سے پہلے تحقیقات کے لیے وقت فراہم کر سکتا ہے۔

آلگائے کے پیچھے ثبوت کو محفوظ رکھیں

بڑھے ہوئے نتائج قابل وضاحت ہونے چاہئیں۔

مثال کے طور پر:

{
  "constraint": "error-rate",
  "status": "DEGRADING",
  "baseline": 0.004,
  "current": 0.008,
  "limit": 0.01,
  "window": "10m",
  "consecutiveWindows": 4,
  "observedAt": "2026-10-13T18:00:00Z"
}

یہ اس سے بہتر ہے:

drift detected

کیونکہ کوئی اس طرح کا جواب دے سکتا ہے:

what changed?
compared with what?
how close are we to the limit?
how long has this been happening?
when was it observed?

یہ نہ صرف ڈیبگنگ کے لیے بلکہ آڈٹ ایبلٹی کے لیے بھی اہم ہے۔

دوبارہ قابل استعمال بڑھے کا تخمینہ لگانے والا

ماڈل کو عام کیا جا سکتا ہے۔

سب سے پہلے، ہم بڑھے ہوئے اصولوں کی وضاحت کرتے ہیں۔

type DriftRule = {
  name: string;
  severity: DriftSeverity;
  evaluate(
    baseline: T,
    current: T
  ): DriftStatus;
};

پھر ہم بڑھے ہوئے تفصیلات کی وضاحت کرتے ہیں۔

type DriftSpec = {
  name: string;
  rules: DriftRule[];
};

اور تشخیص کرنے والا:

type DriftRuleResult = {
  name: string;
  status: DriftStatus;
  severity: DriftSeverity;
};

function evaluateDrift(
  spec: DriftSpec,
  baseline: T,
  current: T
): DriftRuleResult[] {
  return spec.rules.map(
    (rule) => ({
      name: rule.name,
      status:
        rule.evaluate(
          baseline,
          current
        ),
      severity:
        rule.severity,
    })
  );
}

تشخیص کاروں کو تاخیر، غلطی کی شرح، نقل، یا سرٹیفکیٹس کو سمجھنے کی ضرورت نہیں ہے۔

ہر اصول کی اپنی موازنہ منطق ہوتی ہے۔ اس کے بعد انجن کو دوبارہ استعمال کیا جا سکتا ہے۔

چھوٹی مثال سے آخر تک

آئیے اپنی تعیناتی کے لیے ایک بڑھے ہوئے تفصیلات بنائیں۔

ثبوت کے ساتھ شروع کریں:

type DeploymentEvidence = {
  replicas?: number;
  errorRate?: number;
  p95LatencyMs?: number;
};

اب اپنے قوانین کی وضاحت کریں۔

const driftRules:
  DriftRule[] = [
    {
      name: "replicas",
      severity: "CRITICAL",
      evaluate: (
        baseline,
        current
      ) => {
        if (
          baseline.replicas === undefined ||
          current.replicas === undefined
        ) {
          return "UNKNOWN";
        }

        if (current.replicas < 3) {
          return "VIOLATED";
        }

        if (
          current.replicas <
          baseline.replicas
        ) {
          return "DEGRADING";
        }

        return "STABLE";
      },
    },
    {
      name: "error-rate",
      severity: "CRITICAL",
      evaluate: (
        baseline,
        current
      ) => {
        if (
          baseline.errorRate === undefined ||
          current.errorRate === undefined
        ) {
          return "UNKNOWN";
        }

        if (current.errorRate > 0.01) {
          return "VIOLATED";
        }

        if (
          current.errorRate >
          baseline.errorRate * 1.5
        ) {
          return "DEGRADING";
        }

        return "STABLE";
      },
    },
    {
      name: "latency",
      severity: "WARNING",
      evaluate: (
        baseline,
        current
      ) => {
        if (
          baseline.p95LatencyMs === undefined ||
          current.p95LatencyMs === undefined
        ) {
          return "UNKNOWN";
        }

        if (
          current.p95LatencyMs > 400
        ) {
          return "VIOLATED";
        }

        if (
          current.p95LatencyMs >
          baseline.p95LatencyMs * 1.25
        ) {
          return "DEGRADING";
        }

        return "STABLE";
      },
    },
  ];

بڑھے ہوئے تفصیلات بنائیں۔

const driftSpec:
  DriftSpec = {
    name: "orders-runtime-drift",
    rules: driftRules,
  };

اب ہم بنیادی اور موجودہ ثبوت کی وضاحت کرتے ہیں۔

const baseline:
  DeploymentEvidence = {
    replicas: 3,
    errorRate: 0.004,
    p95LatencyMs: 280,
  };

const current:
  DeploymentEvidence = {
    replicas: 3,
    errorRate: 0.007,
    p95LatencyMs: 360,
  };

اندازہ لگانا:

const drift =
  evaluateDrift(
    driftSpec,
    baseline,
    current
  );

ممکنہ آؤٹ پٹ:

replicas     STABLE      CRITICAL
error-rate   DEGRADING   CRITICAL
latency      DEGRADING   WARNING

سسٹم اب بھی موزوں ہو سکتا ہے، لیکن یہ بیس لائن کے مقابلے میں اب فعال طور پر مستحکم نہیں ہے۔

یہ قیمتی معلومات ہے۔

بڑھے ہوئے پتہ لگانے کا اطلاق متعدد ایگزیکیوٹرز پر کیسے ہوتا ہے۔

فرض کریں کہ دونوں ایگزیکیوٹرز نے ایک ہی سروس کو کامیابی کے ساتھ تعینات کیا ہے۔

تعیناتی کے فوراً بعد:

Executor A → conformant
Executor B → conformant

اس کا مطلب یہ نہیں ہے کہ طویل مدتی آپریٹنگ طرز عمل ایک جیسے ہوں گے۔

وقت کے ساتھ:

Executor A
error rate stable
latency stable
replicas stable

Executor B
error rate rising
latency rising
replicas stable

اگرچہ دونوں ایگزیکیوٹرز نے ابتدائی تصریحات کو پورا کیا، لیکن ان کا بہاو آپریشنل رویہ مختلف تھا۔

Drift موازنہ کی ایک اور جہت فراہم کرتا ہے۔

آپ پوچھ سکتے ہیں:

Which executor produces more stable outcomes?
Which one drifts more often?
Which one produces more unknown evidence?
Which one needs recovery more frequently?

یہ خاص طور پر مفید ہے جب ایگزیکیوٹر کا انتخاب متحرک ہو۔

بڑھے ہوئے پتہ لگانے کا اطلاق AI ایجنٹوں پر کیسے ہوتا ہے۔

AI ایجنٹس ایک اور قسم کی تغیرات کو متعارف کراتے ہیں۔

ایجنٹ ایک ہی مقصد کے لیے مختلف منصوبے بنا سکتے ہیں۔

مثال کے طور پر:

Run 1:
scale
deploy
observe

Run 2:
deploy canary
observe
expand

Run 3:
create parallel environment
switch traffic

ہر منصوبہ درست ہو سکتا ہے اور ہر منصوبہ کی ابتدائی طور پر تعمیل کی جا سکتی ہے۔

تاہم، طویل مدتی نتائج مختلف ہو سکتے ہیں۔

ایک منصوبہ ایک مستحکم نظام پیدا کر سکتا ہے، جبکہ دوسرا ایسا نظام پیدا کر سکتا ہے جو آہستہ آہستہ حد کی طرف بڑھتا ہے۔

یہ ہمیں ایک مفید علیحدگی دیتا ہے۔

agent chooses the execution path
specification defines acceptable boundaries
evidence describes the observed state
conformance evaluates the current state
drift evaluates how that state changes over time

یہ ایجنٹ کو اپنے نتائج کا واحد جج بنائے بغیر ایجنٹ کی خود مختاری کی اجازت دیتا ہے۔

جب بڑھے کو کارروائی کو متحرک کرنا چاہئے۔

تمام بڑھے ہوئے سگنل آٹومیشن کو متحرک نہیں کرتے ہیں۔

کچھ مفید جوابی ماڈلز میں شامل ہیں:

STABLE
→ no action

DEGRADING + low severity
→ observe

DEGRADING + persistent
→ investigate

VIOLATED + warning
→ alert

VIOLATED + critical
→ rollback / remediate / escalate

UNKNOWN
→ collect evidence / block risky automation

عین مطابق پالیسی کام پر منحصر ہے۔

مثال کے طور پر، خود بخود ایک سٹیٹ لیس سروس کو دوبارہ شروع کرنے کی اجازت دی جا سکتی ہے۔ تاہم، ڈیٹا بیس کی منتقلی خود بخود واپس نہیں ہوسکتی ہے۔

لہذا، بڑھے کا پتہ لگانے کے لئے ثبوت اور درجہ بندی پیدا کرنا ضروری ہے. پالیسیوں کو یہ طے کرنا چاہیے کہ کن کارروائیوں کی اجازت ہے۔ یہ مشاہدہ، تشخیص، فیصلہ، اور عمل کو الگ رکھتا ہے۔

کون سا آپریشنل ڈرفٹ آپ کو نہیں بتاتا

آپریشنل ڈرفٹ خود بخود آپ کو نہیں بتاتا کہ نظام کیوں بدل گیا ہے۔

فرض کریں کہ تاخیر اس طرح بڑھتی ہے:

280 ms

کو:

390 ms

بڑھے ہوئے پتہ لگانے سے آپ کو یہ کرنے کی اجازت ملتی ہے:

latency is degrading

وجہ خود بخود ثابت نہیں ہو سکتی۔

اس کی وجہ ٹریفک میں اضافہ، ڈیٹا بیس کا تنازعہ، بہاو پر انحصار، نیٹ ورک کی تنزلی، کوڈ ریگریشن، یا وسائل کی تھکن ہو سکتی ہے۔

تو بہاؤ ایک پتہ لگانے کا طریقہ کار ہے۔ یہ بنیادی وجہ تجزیہ نہیں ہے۔

بیس لائن بھی غلط ہو سکتی ہے۔

اگر بیس لائن غیر معمولی طور پر اچھی مدت کے دوران پکڑی جاتی ہے تو نارمل رویہ خراب کارکردگی کی طرح نظر آتا ہے۔

اس وجہ سے بڑھے ہوئے معیار کا انحصار اچھی وضاحتیں، اچھے ثبوت، اچھی بیس لائنز، مناسب ٹائم فریم، اور صحیح اصولوں پر ہوتا ہے۔

عملی بڑھے کا پتہ لگانے کا ورک فلو

اس ترتیب کو استعمال کریں جب آپ کسی موجودہ سسٹم میں آپریشنل ڈرفٹ کا پتہ لگانا چاہتے ہیں۔

1. تعمیل کے کاموں کے ساتھ شروع کریں۔

ان کاموں کا انتخاب کریں جن کے بارے میں آپ کو پہلے سے معلوم ہے کہ آپ کا سسٹم تصریحات کو پورا کرتا ہے۔

2. بنیادی ثبوت کا تحفظ

معلوم اچھی حالت سے وابستہ شواہد کو ذخیرہ کرتا ہے۔

3. بڑھے ہوئے حساس رکاوٹوں کی شناخت کریں۔

تمام رکاوٹوں کو رجحان کے تجزیہ کی ضرورت نہیں ہے۔

چیزوں کے ساتھ شروع کریں جیسے:

latency
error rate
capacity
queue depth
availability
certificate age
backup freshness

4. آبزرویشن ونڈو کی وضاحت کریں۔

ونڈو کو اس کے آپریشنل رویے کے مطابق منتخب کریں۔

5. استحکام، تنزلی، خلاف ورزی، اور نامعلوم کی تعریف کریں۔

اپنی ریاست کو واضح کریں۔

6. شدت شامل کریں۔

اہم بہاؤ سے الگ الگ معلومات بہاؤ۔

7. استقامت شامل کریں۔

کسی ایک شور مچانے والے نمونے پر ردعمل ظاہر نہ کریں۔

8. شواہد کا تحفظ

اسٹورز بیس لائنز، موجودہ حالتیں، حدیں، دورانیے، اور ٹائم اسٹیمپ۔

9. پتہ لگانے اور ردعمل کی علیحدگی

ہر بڑھے ہوئے سگنل کو خودکار کارروائی کو متحرک نہ ہونے دیں۔

10. ماڈل کا دوبارہ جائزہ لینا

اگر آپ کا سسٹم مستقل طور پر غلط مثبت پیدا کرتا ہے تو اپنے قوانین کو بہتر بنائیں۔ اگر آپ اصل تنزلی سے محروم ہیں تو ثبوت یا ونڈو کو بہتر بنائیں۔

صرف حد کو چوڑا نہ کریں جب تک کہ سب کچھ مستحکم نظر نہ آئے۔

پوائنٹ ان ٹائم تعمیل سے لے کر مسلسل تصدیق تک

مطابقت ہمیں دیتا ہے:

Specification
+
Evidence
↓
Evaluation
↓
PASS / FAIL / UNKNOWN

بہاؤ وقت کا اضافہ کرتا ہے۔

Specification
+
Evidence at T0
+
Evidence at T1
+
Evidence at T2
↓
Drift Evaluation
↓
STABLE / DEGRADING / VIOLATED / UNKNOWN

یہ آپریٹنگ ماڈل کو تبدیل کرتا ہے۔

ہم اب صرف یہ نہیں پوچھتے ہیں:

کیا سرجری کامیاب رہی؟

یا:

کیا نظام اب موزوں ہے؟

ہم یہ بھی پوچھ سکتے ہیں:

کیا نظام اپنی مطلوبہ حالت سے ہٹ رہا ہے؟

یہ آپریشنل کنٹرول کے لیے بہت مضبوط بنیاد فراہم کرتا ہے، خاص طور پر جب نظام زیادہ خود مختار ہو جاتا ہے۔

نتیجہ

آپریشنل کافییت ہمیں بتاتی ہے کہ آیا مشاہدہ شدہ شواہد وقت کے ایک خاص مقام پر تصریحات پر پورا اترتے ہیں۔

آپریشنل ڈرفٹ آپ کو بتاتا ہے کہ آیا یہ رشتہ بدل رہا ہے۔

ایک مفید بڑھے ہوئے ماڈل کو برقرار رکھنا چاہیے:

baseline evidence
current evidence
constraint boundaries
observation windows
direction of change
severity
persistence
unknown states
timestamps

یہ آپ کو عارضی شور، مسلسل کارکردگی میں کمی، اصل خلاف ورزیوں، اور گمشدہ ثبوتوں کے درمیان فرق کرنے کی اجازت دیتا ہے۔

عمل کرنے والے کو یہ جاننے کی ضرورت نہیں ہے۔ عمل کرنے والا کام کرتا ہے۔ تفصیلات مطلوبہ حدود کی وضاحت کرتی ہے۔

ثبوت ہمیں بتاتے ہیں کہ کیا ہو رہا ہے۔ موافقت ہمیں بتاتی ہے کہ کیا موجودہ حالت قابل قبول ہے۔ ڈرفٹ آپ کو بتاتا ہے کہ آیا سسٹم قابل قبول حالت سے ہٹ رہا ہے۔

اس مقام پر، ٹکڑے ایک بڑا آپریٹنگ ماڈل بنانا شروع کر دیتے ہیں۔

Intent
↓
Specification
↓
Executor
↓
Evidence
↓
Conformance
↓
Drift
↓
Governed response

اگلا مرحلہ واضح طور پر ان ٹکڑوں کو ایک ساتھ رکھنا ہے۔

یہ وہ جگہ ہے جہاں میں وضاحت کرنا چاہتا ہوں۔ تفصیلات پر مبنی آپریشنیا SDOps کو مکمل آپریٹنگ ماڈل کے طور پر استعمال کریں۔