ایک پچھلے مضمون میں، میں نے ایگزیکیوٹر کی آزادی کے خیال کی کھوج کی تھی، یعنی کہ مختلف عملدرآمد کے طریقہ کار کو ایک ہی آپریشنل تصریحات کو پورا کرنے کے قابل ہونا چاہیے۔
کی طرف سے عملدار کی آزادیاس کا مطلب یہ ہے کہ آپریٹنگ وضاحتیں مستحکم رہتی ہیں یہاں تک کہ اگر کام کرنے والے میکانزم بدل جائیں۔
یہ ہمیں ایک مفید فن تعمیر فراہم کرتا ہے۔
Specification
↓
Executor
↓
Evidence
لیکن اہم سوالات لا جواب ہیں۔ آپ اس بات کا تعین کیسے کریں گے کہ آیا پھانسی سے پیدا ہونے والے ثبوت درحقیقت وضاحتوں پر پورا اترتے ہیں؟
یہ مناسبیت کا مسئلہ ہے۔
ایگزیکٹو کے نقطہ نظر سے، یہاں تک کہ اگر تعیناتی کامیابی سے مکمل ہو جاتی ہے، تب بھی آپریٹنگ معاہدے کی خلاف ورزی ہو سکتی ہے۔
ایک اصلاحی ایجنٹ اس بات کو یقینی بنا سکتا ہے کہ تمام منصوبہ بند کاموں کو مکمل کرتے ہوئے نظام قابل قبول حد سے باہر رہے۔
بحالی کا عمل بغیر کسی غلطی کے مکمل ہو سکتا ہے اور پھر بھی آپ کے مطلوبہ ڈیٹا کو بحال نہیں کر سکتا ہے۔
یہی وجہ ہے کہ درج ذیل عام حالات ظاہر ہوتے ہیں۔
success = true
یہ کافی نہیں ہے۔
ہمیں اس بات کا موازنہ کرنے کے لیے ایک طریقہ درکار ہے کہ کیا ہونا چاہیے تھا جو حقیقت میں مشاہدہ کیا گیا تھا اور واضح، قابل وضاحت اور مفید نتائج پیدا کرتا ہے۔
اس آرٹیکل میں، میں آپ کو دکھاؤں گا کہ کس طرح آپریشنل کنفارمنس کو ماڈل کرنا ہے، انفرادی رکاوٹوں کا اندازہ لگانا ہے، پاسز، فیل اور نامعلوم نتائج کے درمیان فرق کرنا، رواداری کو سنبھالنا، گمشدہ شواہد کو ہینڈل کرنا، شدت کو تفویض کرنا، مفید موافقت کے خلاصے کی گنتی کرنا، اور موافقت کو گمراہ کن اسکور میں تبدیل کرنے سے گریز کرنا۔
مثالیں TypeScript اور تعیناتی کے منظرناموں کا استعمال کرتی ہیں، لیکن یہی نقطہ نظر بنیادی ڈھانچے کی تبدیلیوں، واقعے کے ردعمل، بیک اپ کی بحالی، ڈیٹا پائپ لائنز، اور AI آپریشنل سسٹمز پر لاگو ہوتا ہے۔
کلیدی خیال یہ ہے: مطابقت یہ نہیں ہے کہ آیا نافذ کرنے والا کہتا ہے کہ یہ کامیاب تھا۔ مطابقت یہ ہے کہ آیا مشاہدہ شدہ ثبوت آپریشنل تصریحات کو پورا کرتا ہے۔
شرطیں
آپ کو اس کے ساتھ آرام دہ ہونا چاہئے:
-
کلیدی سافٹ ویئر فن تعمیر کے تصورات
-
TypeScript یا اس سے ملتی جلتی زبان
-
بنیادی ٹیسٹ
-
مشاہدہ
-
CI/CD تصور
-
آپریٹنگ وضاحتیں
-
عملدار کی آزادی
کسی مخصوص تعیناتی پلیٹ فارم کی ضرورت نہیں ہے اور مثالیں جان بوجھ کر چھوٹی ہیں لہذا تشخیصی ماڈل نظر آتا ہے۔
انڈیکس
اس تناظر میں مطابقت کا کیا مطلب ہے؟
عام زبان میں، مطابقت کا مطلب قواعد، معیارات یا تقاضوں کی تعمیل ہے۔
ہم یہاں اس اصطلاح کو خاص طور پر استعمال کرتے ہیں۔
آپریشنل کافییت اس بات کی تشخیص ہے کہ آیا اور کہاں عملدرآمد کے مشاہدہ شدہ ثبوت آپریشنل تصریحات میں بیان کردہ ضروریات کو پورا کرتے ہیں۔
اس تناظر میں، ثبوت قابل مشاہدہ حقائق کا ایک مجموعہ جو ایک نظام سے جمع کیا جاتا ہے جس کا موازنہ وضاحتوں سے کیا جا سکتا ہے۔ یہ کامیابی کا امتحان نہیں ہے۔ اس فیصلے کو بنانے کے لیے استعمال ہونے والا ڈیٹا۔
تعریف کے تین حصے ہیں۔
1. وضاحتیں
یہ وضاحت کرتا ہے کہ کیا سچ ہونا چاہئے۔
مثال کے طور پر:
version = v42
available replicas >= 3
error rate <= 1%
p95 latency <= 400 ms
2. ثبوت
یہ دراصل اس بات کی وضاحت کرتا ہے کہ کیا مشاہدہ کیا گیا تھا۔
مثال کے طور پر:
version = v42
available replicas = 3
error rate = 0.4%
p95 latency = 280 ms
3. تشخیص
یہ تصریحات سے شواہد کا موازنہ کرتا ہے۔
مثال کے طور پر:
version PASS
available replicas PASS
error rate PASS
p95 latency PASS
لہذا موافقت ایک ایگزیکیوٹر پراپرٹی نہیں ہے۔ یہ تصریح کے خلاف شواہد کا جائزہ لینے کا نتیجہ ہے۔
تصوراتی طور پر:
Specification
+
Evidence
↓
Conformance Evaluation
↓
Result
وضاحتیں اور ثبوت کے ساتھ شروع کریں۔
فرض کریں کہ آپ کے پاس درج ذیل تعیناتی کی وضاحتیں ہیں:
type DeploymentSpec = {
version: string;
minReplicas: number;
maxErrorRate: number;
maxP95LatencyMs: number;
};
const spec: DeploymentSpec = {
version: "v42",
minReplicas: 3,
maxErrorRate: 0.01,
maxP95LatencyMs: 400,
};
اب ثبوت کی وضاحت کریں۔
type DeploymentEvidence = {
version: string;
replicas: number;
errorRate: number;
p95LatencyMs: number;
};
const evidence: DeploymentEvidence = {
version: "v42",
replicas: 3,
errorRate: 0.004,
p95LatencyMs: 280,
};
سب سے آسان جائزہ لینے والا بولین واپس کر سکتا ہے۔
function conforms(
spec: DeploymentSpec,
evidence: DeploymentEvidence
): boolean {
return (
evidence.version === spec.version &&
evidence.replicas >= spec.minReplicas &&
evidence.errorRate <= spec.maxErrorRate &&
evidence.p95LatencyMs <= spec.maxP95LatencyMs
);
}
یہ کام کرتا ہے، لیکن ایک مسئلہ ہے۔
نتائج درج ذیل ہیں:
false
تم نہیں جانتے کیوں؟ یہ آپریشنل کاموں کے لیے کافی نہیں ہے۔
انفرادی طور پر رکاوٹوں کا اندازہ کریں۔
ایک بولین کے بجائے انفرادی طور پر ہر رکاوٹ کا اندازہ کریں۔
type ConstraintResult = {
name: string;
passed: boolean;
};
function evaluateDeployment(
spec: DeploymentSpec,
evidence: DeploymentEvidence
): ConstraintResult[] {
return [
{
name: "version",
passed:
evidence.version === spec.version,
},
{
name: "replicas",
passed:
evidence.replicas >= spec.minReplicas,
},
{
name: "error-rate",
passed:
evidence.errorRate <= spec.maxErrorRate,
},
{
name: "latency",
passed:
evidence.p95LatencyMs <= spec.maxP95LatencyMs,
},
];
}
ConstraintResult ہر چیک کے لیے ایک نام اور ایک بولین نتیجہ فراہم کریں۔ کہ evaluateDeployment() فنکشن ایک وقت میں ایک مشاہدہ شدہ قدر کا موازنہ تصریح میں متعلقہ اصول سے کرتا ہے۔ یقینی بنائیں کہ تعینات کردہ ورژن بالکل مماثل ہیں، نقلوں کی تعداد کافی زیادہ ہے، اور غلطی کی شرح اور تاخیر حد سے نیچے رہیں۔
تمام چیکس کو ایک میں سمیٹنے کے بجائے true یا falseفنکشن فی رکاوٹ ایک نتیجہ دیتا ہے۔ یہ کال کرنے والے کو یہ دیکھنے کی اجازت دیتا ہے کہ کون سے تقاضے گزر گئے یا ناکام ہوئے۔
اب آؤٹ پٹ ہے:
version PASS
replicas PASS
error-rate PASS
latency PASS
یا:
version PASS
replicas FAIL
error-rate PASS
latency FAIL
یہ بہت زیادہ مفید ہے۔ آپ ناکام آپریشن کی وضاحت کر سکیں گے۔
پاس یا فیل ہونے کے لیے ہر چیز کو کم نہ کریں۔
ثنائی تشخیص اب بھی کبھی کبھی بہت آسان ہے.
فرض کریں کہ آپ کی تفصیلات کی ضرورت ہے:
error rate <= 1%
تاہم مشاہداتی نظام دستیاب نہیں ہے۔
نتیجہ کیا ہونا چاہیے؟
PASS یہ صریحاً غلط ہے۔
FAIL یہ گمراہ کن ہوسکتا ہے کیونکہ یہ دو حالات کو ملا دیتا ہے۔
the system violated the constraint
اور:
we do not know whether the system violated the constraint
بہتر ماڈل کم از کم تین ریاستوں کا استعمال کرتے ہیں۔
PASS
FAIL
UNKNOWN
مثال کے طور پر:
type ConstraintStatus =
| "PASS"
| "FAIL"
| "UNKNOWN";
نامعلوم شواہد کو خاموشی سے کامیاب نہیں ہونا چاہیے۔
گمشدہ شواہد کو نامعلوم ثبوت سمجھیں۔
فرض کریں ثبوت جزوی ہو جاتا ہے۔ یعنی، نظام کچھ، لیکن تمام نہیں، مشاہدات واپس کر سکتا ہے۔ تعیناتی کی تاریخ آپ کو بتاتی ہے کہ کون سا ورژن چل رہا ہے اور کتنی نقلیں دستیاب ہیں، لیکن خرابی کی شرح کی پیمائش عارضی طور پر دستیاب نہیں ہے۔
آپ ہر ثبوت کے فیلڈ کو اختیاری بنا کر اس کا اظہار کر سکتے ہیں۔
type DeploymentEvidence = {
version?: string;
replicas?: number;
errorRate?: number;
p95LatencyMs?: number;
};
اس کے بعد جائزہ لینے والے کو اصل خلاف ورزیوں اور یاد شدہ مشاہدات کے درمیان فرق کرنا چاہیے۔
function evaluateErrorRate(
spec: DeploymentSpec,
evidence: DeploymentEvidence
): ConstraintStatus {
if (
evidence.errorRate === undefined
) {
return "UNKNOWN";
}
return (
evidence.errorRate <= spec.maxErrorRate
)
? "PASS"
: "FAIL";
}
پہلی شاخ پوچھتی ہے کہ کیا غلطی کی شرح کی قدر بالکل بھی دیکھی گئی ہے۔ اگر نہیں، تو تشخیص کرنے والا واپس آتا ہے۔ UNKNOWN اندازہ لگانے کے بجائے۔ اگر قدر موجود ہے تو فنکشن اس کا موازنہ زیادہ سے زیادہ قابل اجازت غلطی کی شرح اور واپسی سے کرتا ہے۔ PASS یا FAIL.
یہ پیدا کرتا ہے:
errorRate = 0.004 → PASS
errorRate = 0.03 → FAIL
errorRate missing → UNKNOWN
یہ فرق اہم ہے۔ ٹیلی میٹری غائب ہے۔اس کا مطلب ہے کہ جن میٹرکس یا آپریشنل سگنلز کا ہم مشاہدہ کرنے کی توقع رکھتے ہیں وہ دستیاب نہیں ہیں۔ مثال کے طور پر، کیونکہ مانیٹرنگ سسٹم نے اس ایگزیکیوشن ونڈو کے لیے ایرر ریٹ ویلیوز کی اطلاع نہیں دی۔ اگر غائب ٹیلی میٹری کو کامیابی کے طور پر سمجھا جاتا ہے، تو فٹ خطرناک حد تک پر امید ہو جاتا ہے۔
صحیح موازنہ غلط ہونے پر رواداری کا استعمال کریں۔
کچھ رکاوٹوں میں عین مساوات کے استعمال کی ضرورت ہوتی ہے۔
مثال کے طور پر:
deployed version must equal v42
دوسروں کو نہیں کرنا چاہئے۔
عددی نظاموں کو رواداری کی ضرورت ہو سکتی ہے کیونکہ ماپا یا حساب شدہ اقدار بہت کم مقدار میں مختلف ہو سکتی ہیں چاہے وہ عملی طور پر ایک جیسی ہوں۔ فلوٹنگ پوائنٹ ریاضی، نمونے لینے، راؤنڈنگ، اور پیمائش کا شور سبھی اقدار پیدا کر سکتے ہیں جو رکاوٹوں کو پورا نہیں کرتے کیونکہ وہ بالکل ایک جیسے نہیں ہیں۔
function withinTolerance(
observed: number,
expected: number,
tolerance: number
): boolean {
return (
Math.abs(observed - expected)
<= tolerance
);
}
پھر:
withinTolerance(
1.9999999,
2,
0.0001
);
رپورٹ true.
یہ فنکشن مشاہدہ شدہ اور متوقع اقدار کے درمیان مطلق فرق کا حساب لگاتا ہے اور پھر یہ تعین کرتا ہے کہ آیا یہ فرق قبول شدہ رواداری کے اندر ہے۔ یہ اس وقت مفید ہے جب چھوٹے عددی فرق کی توقع کی جاتی ہے اور درست مساوات غلط ناکامی کا باعث بنتی ہے۔
تاہم، رواداری آپریٹنگ لفافے سے آنی چاہیے۔ ناکامی کو محض اس لیے پیش نہیں کیا جانا چاہیے کہ اسے دور کر دیا جائے۔
رکاوٹوں میں شدت شامل کریں۔
تمام رکاوٹوں کی ایک جیسی آپریشنل اہمیت نہیں ہے۔
فرض کریں کہ دو رکاوٹیں ناکام ہوجاتی ہیں:
p95 latency = 405 ms
replicas = 0
دونوں ناکام ہیں، لیکن برابر نہیں ہیں۔
تاخیر کی ایک چھوٹی سی رقم غائب ہونا فوری رول بیک کے بغیر توجہ دینے کی ضمانت دے سکتا ہے۔ دوسری طرف، اگر دستیاب نقلیں 0 ہیں، تو اس کا مطلب یہ ہو سکتا ہے کہ سروس دستیاب نہیں ہے اور ہنگامی بحالی شروع کی جانی چاہیے۔ شدت آپ کو تمام غلطیوں کو یکساں طور پر اہم سمجھنے کی بجائے تشخیص میں آپریشنل اختلافات کو محفوظ رکھنے کی اجازت دیتی ہے۔
type Severity =
| "INFO"
| "WARNING"
| "CRITICAL";
type ConstraintResult = {
name: string;
status: ConstraintStatus;
severity: Severity;
};
یہاں، status یہ آپ کو بتاتا ہے کہ آیا رکاوٹ گزر گئی، ناکام ہوئی، یا اس کا اندازہ نہیں لگایا جا سکا۔ severity یہ آپ کو بتاتا ہے کہ نتائج کتنے اہم ہیں۔
دونوں جہتیں الگ الگ ہیں۔ پابندیاں اس طرح ناکام ہو سکتی ہیں: WARNING شدت یا ناکامی۔ CRITICAL سنجیدگی۔
پھر:
latency
FAIL
WARNING
replicas
FAIL
CRITICAL
یہ فیصلہ کرتے وقت اہم ہے کہ آیا جاری رکھنا ہے، روکنا ہے، رول بیک کرنا ہے یا بڑھانا ہے۔
علیحدہ مشورے اور سخت پابندیاں
کچھ تقاضے اس بات کی وضاحت کرتے ہیں کہ آیا آپریشن کی اجازت ہے۔ دوسرے مفید سگنل ہیں لیکن ضروری نہیں کہ عملدرآمد کو روکیں۔
یہ شدت سے مختلف ہے۔ شدت نتیجہ کے اثرات کو بیان کرتی ہے، جب کہ رکاوٹ موڈ یہ بتاتا ہے کہ آیا اصول حتمی موافقت کے فیصلے میں حصہ لیتا ہے۔ کوئی راستہ نہیں REQUIRED کسی آپریشن کے اہل ہونے کے لیے، اسے رکاوٹوں سے گزرنا چاہیے۔ نہیں ADVISORY یہاں تک کہ اگر کوئی رکاوٹ ناکام ہوجاتی ہے، تو آپریشن اب بھی تعمیل رہ سکتا ہے۔ تاہم، ناکامیوں کو ابھی بھی رپورٹ کرنا ضروری ہے۔
type ConstraintMode =
| "REQUIRED"
| "ADVISORY";
اب آپ کے نتائج میں شامل ہو سکتے ہیں:
type ConstraintResult = {
name: string;
status: ConstraintStatus;
severity: Severity;
mode: ConstraintMode;
expected?: unknown;
observed?: unknown;
};
مثال کے طور پر:
version
REQUIRED
PASS
latency-target
ADVISORY
FAIL
آپریشن اب بھی مجموعی طور پر قابل قبول ہو سکتا ہے، لیکن انتباہات کے ساتھ۔ یہ ایک عالمی بولین سے زیادہ اظہار خیال ہے۔
دوبارہ قابل استعمال مطابقت کا جائزہ لینے والا بنانا
اب تک کی مثالیں ایک تعیناتی اور چند سخت کوڈ شدہ چیکوں سے منسلک ہیں۔ اگلا مرحلہ تشخیصی طریقہ کار کو انفرادی اصولوں سے الگ کرنا ہے، جس سے ایک ہی انجن کو مختلف آپریشنل تصریحات کا جائزہ لینے کی اجازت ملتی ہے۔
اس مقصد کے لیے، ہم ہر ایک اصول کو مندرجہ ذیل بیان کرتے ہیں: Constraint. ہر رکاوٹ کا ایک منفرد نام، شدت، موڈ، اور تشخیص کا فنکشن ہوتا ہے۔ نہیں OperationalSpec یہ پھر ان رکاوٹوں کا مجموعہ بن جاتا ہے۔
type Constraint = {
name: string;
severity: Severity;
mode: ConstraintMode;
evaluate(
evidence: T
): ConstraintStatus;
};
type OperationalSpec = {
name: string;
constraints: Constraint[];
};
پھر:
function evaluateConformance(
spec: OperationalSpec,
evidence: T
): ConstraintResult[] {
return spec.constraints.map(
(constraint) => ({
name: constraint.name,
status:
constraint.evaluate(evidence),
severity:
constraint.severity,
mode:
constraint.mode,
})
);
}
ایک تصریح ان اشیاء کی ملکیت رکھتی ہے جن کا جائزہ لیا جائے۔
جائزہ لینے والا نتائج جمع کرتا ہے۔ آپ کو یہ جاننے کی ضرورت نہیں ہے کہ ہر رکاوٹ کا کیا مطلب ہے۔ یہ آسانی سے تمام رکاوٹوں کی تشخیص کے کام کو انجام دیتا ہے اور نتیجے میں ہونے والی حالت، شدت اور موڈ کو محفوظ رکھتا ہے۔ یہ تشخیص کے انجن کو عام کرتا ہے جبکہ تصریح آپریٹنگ قواعد کے لیے ذمہ دار ہوتی ہے۔
کہ expected اور observed اگرچہ اس کم سے کم مثال میں فیلڈز اختیاری ہیں، پروڈکشن سسٹم ان کو آباد کرے گا یا بنیادی شواہد کا حوالہ محفوظ کرے گا تاکہ حتمی فیصلہ قابل وضاحت اور قابل سماعت ہو۔
اپنی مناسبیت کے خلاصے کا احتیاط سے حساب لگائیں۔
انفرادی نتائج مفید ہیں، لیکن بعض اوقات ایک خلاصہ ضروری ہوتا ہے۔
type ConformanceSummary = {
total: number;
passed: number;
failed: number;
unknown: number;
conformant: boolean;
};
پھر:
function summarize(
results: ConstraintResult[]
): ConformanceSummary {
const required =
results.filter(
(result) =>
result.mode === "REQUIRED"
);
const passed =
results.filter(
(result) =>
result.status === "PASS"
).length;
const failed =
results.filter(
(result) =>
result.status === "FAIL"
).length;
const unknown =
results.filter(
(result) =>
result.status === "UNKNOWN"
).length;
const conformant =
required.every(
(result) =>
result.status === "PASS"
);
return {
total: results.length,
passed,
failed,
unknown,
conformant,
};
}
اب، مجموعی تعمیل حاصل کرنے کے لیے، تمام مطلوبہ رکاوٹوں کو پورا کرنا ضروری ہے۔
نوٹ کریں کہ اس کا کیا مطلب ہے۔ UNKNOWN: کیونکہ every() ریاست رکھنے کے لیے، آپ کو لازمی رکاوٹوں کی ضرورت ہے۔ PASSگمشدہ ثبوت کے ساتھ مطلوبہ رکاوٹیں خود بخود مجموعی نتیجہ کو پاس کرنے کی بجائے غلط قرار دے گی۔
رپورٹ میں مشاورتی رکاوٹیں اب بھی ظاہر ہوں گی۔ وہ حتمی فیصلہ نہیں کرتے۔
ایک ہی سکور کیوں خطرناک ہو سکتا ہے۔
یہ ایک واحد سکور بنانے کے لئے پرکشش ہے.
conformance = 92%
لیکن یہ گمراہ کن ہے۔
فرض کریں:
9 low-risk constraints pass
1 critical security constraint fails
بولی سکور کہتا ہے:
90% conformant
عملی طور پر، یہ مکمل طور پر ناقابل قبول ہے.
اپنے سکور کا حساب لگاتے وقت، آپ کو یہ رکھنا چاہیے:
constraint-level results
severity
required/advisory status
unknown evidence
failure reasons
آپ اپنے اسکور کا خلاصہ کر سکتے ہیں، لیکن آپ کو ثبوت نہیں مٹانا چاہیے۔
اپنے فیصلوں کے پیچھے ثبوت کو محفوظ رکھیں
تعمیل کے نتائج کا صرف یہ مطلب نہیں ہونا چاہیے کہ: FAIL. اس حکم کے مواد کو محفوظ کیا جانا چاہیے۔
{
"constraint": "minimum-replicas",
"expected": ">= 3",
"observed": 2,
"status": "FAIL",
"severity": "CRITICAL"
}
اس طرح، کوئی اس طرح کچھ جواب دے سکتا ہے:
What did we expect?
What did we observe?
Which rule was applied?
Why did it fail?
یہ خاص طور پر اہم ہے جب تعمیل کا فیصلہ خودکار بحالی کو متحرک کرتا ہے۔
تعمیل دوبارہ پیدا کرنے کے قابل ہونا ضروری ہے۔
فرض کریں کہ کام 10:00 بجے چلتا ہے۔
غلطی کی شرح 10:01 ہے:
0.6%
14:00 پر، آپ کا ڈیش بورڈ ڈسپلے کرے گا:
2.1%
موجودہ ٹیلی میٹری کا استعمال کرتے ہوئے پچھلے کام کا دوبارہ جائزہ لینے سے مختلف نتائج برآمد ہو سکتے ہیں۔
اس لیے، پھانسی کی کھڑکی سے متعلق شواہد کی بنیاد پر مناسبیت کا اندازہ لگایا جانا چاہیے۔ کی طرف سے ونڈو چلائیںاس سے مراد وہ مدت ہے جس کے دوران آپریشن کو نافذ کیا جاتا ہے اور اس کے فوری اثرات کی تصدیق ہوتی ہے۔ مثال کے طور پر، 10:00 پر مکمل ہونے والی تعیناتی کے لیے، آپ 10:00 اور 10:05 کے درمیان جمع ہونے والی ٹیلی میٹری کا استعمال کرتے ہوئے اس کی صحت کا اندازہ لگا سکتے ہیں، بجائے اس کے کہ آپ کچھ گھنٹوں بعد ڈیش بورڈ میں دیکھیں۔
بات یہ ہے کہ فیصلے کو اس خاص پھانسی کے لیے دستیاب شواہد سے جوڑنا ہے۔ بصورت دیگر، نظام میں بعد میں ہونے والی تبدیلیاں پہلے سے ہونے والی کارروائیوں کے ظاہری نتائج کو سابقہ طور پر تبدیل کر سکتی ہیں۔
دوبارہ پیدا کرنے کے قابل ریکارڈ محفوظ کر سکتے ہیں:
specification version
execution ID
evidence snapshot
evaluation rules
timestamp
مثال کے طور پر:
{
"executionId": "deploy-812",
"specVersion": "3",
"evaluatedAt": "2026-10-06T10:01:00Z",
"evidence": {
"version": "v42",
"replicas": 3,
"errorRate": 0.006,
"p95LatencyMs": 290
}
}
اب فیصلہ بعد میں دوبارہ تشکیل دیا جا سکتا ہے۔
یہ ایک سے زیادہ ایگزیکیوٹرز پر کیسے لاگو ہوتا ہے۔
فرض کریں کہ دو قابل عمل پروگرام ایک ہی تفصیلات پر عملدرآمد کرتے ہیں۔
ایگزیکیوٹر A:
version PASS
replicas PASS
error-rate PASS
latency PASS
ایگزیکیوٹر بی:
version PASS
replicas FAIL
error-rate PASS
latency PASS
مزید سوالات نہیں:
کون سا نافذ کرنے والا بہتر ہے؟
فوری سوالات یہ ہیں:
کون سے پھانسیوں نے تصریحات کو پورا کیا؟
ہر ایک ایگزیکیوٹر اس کا جواب ایک ہی موزوں تخمینہ لگانے والے کو اپنے تیار کردہ ثبوت پر چلا کر دیتا ہے۔ نردجیکرن اور تشخیص کے قواعد وہی رہتے ہیں۔ صرف ثبوت بدلتے ہیں۔
مندرجہ بالا مثال میں، ایگزیکیوٹر A تفصیلات کو پورا کرتا ہے کیونکہ تمام مطلوبہ رکاوٹوں کا اندازہ اس طرح کیا جاتا ہے: PASS. ایگزیکیوٹر بی نہیں کرتا، کیونکہ نقل کی رکاوٹ کا اندازہ اس طرح کیا جاتا ہے: FAIL. یہ موازنہ کے لیے ایک مشترکہ بنیاد فراہم کرتا ہے بغیر دو عملداروں کو ایک جیسے داخلی اقدامات استعمال کرنے کے۔
وقت کے ساتھ ایگزیکیوٹر کی کارکردگی کا موازنہ فٹ ریٹ، ناکامی کے زمرے، تاخیر، لاگت، بازیابی کی فریکوئنسی، اور نامعلوم ثبوت کی شرح کا استعمال کرتے ہوئے کیا جا سکتا ہے۔ تاہم، مناسبیت اب بھی معاہدہ کی سطح کی تشخیص ہے۔
یہ AI ایجنٹوں پر کیسے لاگو ہوتا ہے۔
AI ایجنٹ واضح تعمیل کو خاص اہمیت دیتے ہیں۔
مشیران ایک ہی مقصد کے لیے مختلف منصوبوں کا انتخاب کر سکتے ہیں۔
Agent execution 1:
scale
deploy
observe
route
Agent execution 2:
deploy canary
observe
expand
Agent execution 3:
create parallel environment
switch traffic
ایجنٹ ہر بار ایک مختلف منصوبہ منتخب کر سکتے ہیں، اس لیے مرحلہ وار عملدرآمد کا موازنہ کرنا زیادہ مفید نہیں ہے۔ آپ ایک رن میں کینری رول آؤٹ استعمال کر سکتے ہیں اور دوسری رن میں متوازی ماحول بنا سکتے ہیں، اور دونوں ایک ہی مقصد کو حاصل کرنے کے لیے اب بھی درست طریقے ہو سکتے ہیں۔
جو چیز مستحکم رہتی ہے وہ تصریح ہے۔ اہداف، رکاوٹیں، اور ثبوت کے تقاضے تبدیل نہیں ہوتے ہیں اگر ایجنٹ کوئی مختلف راستہ چنتا ہے۔
ہر عمل کے بعد، نظام نتیجے میں ریاست کے بارے میں ثبوت جمع کرتا ہے۔ مطابقت کا جائزہ لینے والا پھر اس ثبوت کا موازنہ دیگر تمام رن میں استعمال ہونے والی اسی وضاحتوں سے کرتا ہے۔ یہ ایجنٹ کو اپنے عمل درآمد کے منصوبے کو تبدیل کرنے کی اجازت دیتا ہے جبکہ ایجنٹ کی بیرونی کامیابی کی تعریف کو برقرار رکھتا ہے۔
Specification
↓
AI Agent
↓
Dynamic Plan
↓
Execution
↓
Evidence
↓
Conformance
ایجنٹ کام تجویز کر سکتے ہیں۔ یہ تعین کرنے کا واحد اختیار نہیں ہونا چاہئے کہ آیا اس طرح کے اقدامات نے اپنے مطلوبہ نتائج حاصل کیے ہیں۔
چھوٹی مثال سے آخر تک
ثبوت کی وضاحت سے شروع کریں۔
type DeploymentEvidence = {
version?: string;
replicas?: number;
errorRate?: number;
p95LatencyMs?: number;
};
اب رکاوٹوں کی وضاحت کرتے ہیں۔
const constraints:
Constraint[] = [
{
name: "version",
severity: "CRITICAL",
mode: "REQUIRED",
evaluate: (evidence) => {
if (!evidence.version) {
return "UNKNOWN";
}
return (
evidence.version === "v42"
)
? "PASS"
: "FAIL";
},
},
{
name: "replicas",
severity: "CRITICAL",
mode: "REQUIRED",
evaluate: (evidence) => {
if (
evidence.replicas === undefined
) {
return "UNKNOWN";
}
return (
evidence.replicas >= 3
)
? "PASS"
: "FAIL";
},
},
{
name: "error-rate",
severity: "CRITICAL",
mode: "REQUIRED",
evaluate: (evidence) => {
if (
evidence.errorRate === undefined
) {
return "UNKNOWN";
}
return (
evidence.errorRate <= 0.01
)
? "PASS"
: "FAIL";
},
},
{
name: "latency-target",
severity: "WARNING",
mode: "ADVISORY",
evaluate: (evidence) => {
if (
evidence.p95LatencyMs === undefined
) {
return "UNKNOWN";
}
return (
evidence.p95LatencyMs <= 350
)
? "PASS"
: "FAIL";
},
},
];
وضاحتیں بنائیں۔
const deploymentSpec:
OperationalSpec = {
name: "deploy-orders-v42",
constraints,
};
اندازہ لگانا:
const evidence:
DeploymentEvidence = {
version: "v42",
replicas: 3,
errorRate: 0.004,
p95LatencyMs: 370,
};
const results =
evaluateConformance(
deploymentSpec,
evidence
);
const summary =
summarize(results);
نتائج درج ذیل ہیں:
version PASS REQUIRED
replicas PASS REQUIRED
error-rate PASS REQUIRED
latency-target FAIL ADVISORY
اور:
conformant = true
تمام مطلوبہ رکاوٹیں گزر چکی ہیں۔
کارروائی کو اب بھی ایک انتباہ دکھانا چاہئے کیونکہ تجویز کردہ تاخیر کا ہدف ناکام ہو گیا ہے۔
عملی کنفارمنس ورک فلو
اگر آپ موجودہ نظام میں مطابقت کی تشخیص کو متعارف کرانا چاہتے ہیں:
-
براہ کرم ایک کام منتخب کریں۔
-
وضاحتیں بیان کریں۔
-
ضروریات یا سفارشات کے مطابق رکاوٹوں کی درجہ بندی کریں۔
-
شدت کو تفویض کریں۔
-
ثبوت کے ماڈل کی وضاحت کریں۔
-
فیصلہ کریں کہ ثبوت غائب ہونے کا کیا ہوتا ہے۔
UNKNOWN. -
رکاوٹوں کا انفرادی طور پر جائزہ لیا جاتا ہے۔
-
ایک خلاصہ لکھیں۔
-
شواہد کے اسنیپ شاٹس کو محفوظ رکھیں۔
-
تفصیلات کے ورژن کی وضاحت کرتا ہے۔
-
ان قوانین کا دوبارہ جائزہ لیں جو غیر متوقع یا نامعلوم غلطیوں کا سبب بن رہے ہیں۔
صرف نتائج کو پاس کرنے کے لئے تفصیلات کو پانی نہ دیں۔
قابلیت ثابت کرنے میں ناکامی۔
مناسبیت آپ کو بتاتی ہے:
مشاہدہ شدہ شواہد تصریحات پر پورا اترتے ہیں۔
ہم خود بخود آپ کو نہیں بتا سکتے:
وضاحتیں درست ہیں۔
تصریح غلط ہو سکتی ہے اور ثبوت بھی غلط ہو سکتا ہے۔
لہذا، مناسبیت پر منحصر ہے:
specification quality
evidence quality
evaluation correctness
یہ ایک تصدیقی طریقہ کار ہے، قطعی سچائی نہیں۔
کامیاب عمل درآمد سے لے کر قابل تصدیق کارروائیوں تک
موجودہ آٹومیشن اکثر یہاں ختم ہو جاتی ہے۔
execute
↓
success / failure
مطابقت پر مبنی ماڈل مزید ڈھانچہ شامل کرتے ہیں۔
Specification
↓
Executor
↓
Execution
↓
Evidence
↓
Constraint Evaluation
↓
Conformance
اب آپ پوچھ سکتے ہیں:
کن تقاضوں کو پورا کیا گیا ہے؟
کون سا ناکام ہوا؟
کیا اندازہ نہیں کیا جا سکتا؟
کون سے شواہد فیصلے کی تائید کرتے ہیں؟
اگر سسٹم لانچ کے فوراً بعد موزوں ہے، تو اب آپ کے پاس ایک بیس لائن ہے۔
اس بیس لائن سے، آپ وقت کے ساتھ نظام کا مشاہدہ جاری رکھ سکتے ہیں۔
پھر سوال پوچھیں۔
کیا ہوتا ہے جب کام پہلے ہی کامیاب ہونے کے بعد حقیقت وضاحتوں سے ہٹنا شروع کر دیتی ہے؟
یہ آپریشنل ڈرفٹ ہے۔
نتیجہ
اکیلے ایک کامیاب عملدار ہونا کافی نہیں ہے۔ سبز پائپ لائنز یا مکمل شدہ ایجنٹ کے منصوبوں کے لیے بھی یہی ہے۔
اہم بات یہ ہے کہ آیا نتیجے میں آنے والا نظام آپریشنل تصریحات کو پورا کرتا ہے۔
اس کے لیے آپ کو تین چیزوں کی ضرورت ہے:
Specification
Evidence
Evaluation
ایک مفید فٹنس ماڈل کو برقرار رکھنا چاہیے:
constraint-level results
PASS / FAIL / UNKNOWN
severity
required vs advisory rules
observed values
expected values
evidence snapshots
specification version
ایگزیکیوٹر کام انجام دیتا ہے، شواہد اس بات کی وضاحت کرتا ہے کہ کیا ہوا، اور تصریح اس بات کی وضاحت کرتی ہے کہ کیا ہونا چاہیے تھا۔
مطابقت کا جائزہ لینے والا پھر دونوں کا موازنہ کرتا ہے۔
یہ روایتی آٹومیشن اور تیزی سے خود مختار نظاموں کے لیے ایک مضبوط بنیاد فراہم کرتا ہے۔
لیکن کسی خاص مقام پر موزوں ہونا کہانی کا اختتام نہیں ہے۔ سسٹم اب موافق ہوسکتا ہے اور بعد میں بڑھ سکتا ہے۔
اگلا سوال یہ ہے:
جب مشاہدہ شدہ حقیقت آپریشنل ارادے سے میل نہیں کھاتی ہے تو آپ کو کیسے پتہ چلے گا؟
اسی جگہ میں آگے جانا چاہتا ہوں۔