قابل عمل آپریشنل نردجیکرن کے ساتھ سافٹ ویئر آٹومیشن کی توثیق کیسے کریں۔

جدید سافٹ ویئر سسٹم تیزی سے خودکار ہوتے جارہے ہیں۔ ہم تعیناتیوں، بنیادی ڈھانچے کی تبدیلیوں، اسکیلنگ، واقعہ کے ردعمل، اور ڈیٹا پائپ لائنوں کو خودکار بناتے ہیں۔

اور اب، ہم AI ایجنٹوں کے ذریعے بھی آپریشنل فیصلوں کو خودکار کرنا شروع کر رہے ہیں۔ یہ ترقی کی طرح لگتا ہے، لیکن یہ مسائل پیدا کرتا ہے جو یاد کرنا آسان ہے.

ہم ان اہداف کو بہتر طور پر بیان کیے بغیر کاموں کو انجام دینے میں بہتر ہو رہے ہیں جو ان کاموں کو حاصل کرنے چاہئیں۔

یہاں تک کہ اگر ایک تعیناتی پائپ لائن کامیابی سے چلتی ہے، تب بھی یہ اہم کاروباری رکاوٹوں کی خلاف ورزی کر سکتی ہے۔

یہاں تک کہ اگر بنیادی ڈھانچے کے اسکرپٹ بغیر کسی غلطی کے مکمل ہوتے ہیں، تو وہ سسٹم کو غلط حالت میں چھوڑ سکتے ہیں۔

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

بہت سے نظاموں میں، آپریشنل ارادہ اب بھی ہے:

runbooks
tickets
Slack messages
CI/CD configuration
Terraform files
dashboards
monitoring rules
human memory

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

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

جیسے جیسے عملدرآمد تیز، زیادہ تقسیم، اور زیادہ خود مختار ہوتا جاتا ہے، یہ امتیاز تیزی سے اہم ہوتا جاتا ہے۔

اس مضمون میں ہم دیکھیں گے:

• اکیلے آٹومیشن کیوں کافی نہیں ہے۔

• عملدرآمد کی منطق اور آپریشنل ارادے کے درمیان فرق؛

• قابل عمل آپریشنل وضاحتیں کیا ہیں؛

• مشاہداتی صلاحیت اس مسئلے کو خود ہی کیوں حل نہیں کرتی ہے۔

• وضاحتیں کس طرح آپریشنل رویے کو قابل تصدیق بنا سکتی ہیں؛

• یہ CI/CD، انفراسٹرکچر، واقعے کے ردعمل، اور AI ایجنٹوں پر کیسے لاگو ہوتا ہے؛

• کم از کم چشمی کیسی نظر آئے گی؟

• اور معلوم کریں کہ اس نقطہ نظر سے ابھی تک کون سے مسائل حل نہیں ہوئے ہیں۔

بنیادی خیال سادہ ہے۔

اگر کوئی نظام کسی کام کو خود بخود انجام دے سکتا ہے، تو اسے یہ بھی بتانے کے قابل ہونا چاہیے کہ اس کام کو انجام دینے والے ٹول سے قطع نظر، کامیاب عمل درآمد کا کیا مطلب ہے۔

شرطیں

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

ایک مخصوص کلاؤڈ فراہم کنندہ، تعیناتی پلیٹ فارم، یا آرکیسٹریشن ٹول استعمال کرنے کی ضرورت نہیں ہے۔

اس مضمون کے خیالات جان بوجھ کر ٹول سے آزاد ہیں۔

انڈیکس

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

اپنی تعیناتی پائپ لائن پر غور کریں۔ درج ذیل ہو سکتے ہیں:

build the application
run tests
build an image
push the image
deploy it
wait for readiness
mark the pipeline as successful

تمام مراحل مکمل ہونے پر پائپ لائن سبز ہو جاتی ہے۔ لیکن پائپ لائن نے اصل میں کیا ثابت کیا؟

یہ عام طور پر اس طرح ہے:

the configured steps completed successfully

یہ مفید ہے۔ لیکن یہ اس طرح نہیں ہونا چاہئے:

the intended operational outcome was achieved

فرض کریں کہ تعیناتی تکنیکی طور پر کامیاب تھی، لیکن:

the wrong image version was deployed
only two replicas are running instead of three
the error rate increased
a required feature flag is disabled
the service is healthy but cannot reach a dependency
the rollout violated a regional constraint

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

آٹومیشن ہمیں بتاتا ہے:

قدم پر عمل ہو چکا ہے۔

یہاں ہمیں اکثر جاننے کی ضرورت ہے:

کیا نتیجہ خیز نظام مطلوبہ شرائط پر پورا اترا؟

یہ ایک الگ سوال ہے۔

آپریشنل علم عام طور پر بکھرا ہوا ہے۔

زیادہ تر پیداواری نظاموں میں پہلے سے ہی آپریشنل علم شامل ہے۔ مسئلہ یہ ہے کہ وہ بکھرے ہوئے ہیں۔

مثال کے طور پر، درج ذیل جگہ پر تعیناتی کا اصول جزوی طور پر موجود ہو سکتا ہے:

GitHub Actions
Terraform
Kubernetes manifests
Grafana dashboards
PagerDuty alerts
a runbook
a ticket
a senior engineer's memory

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

ایک بھی نمائندہ نہیں کہتا:

This is the operation we intend to perform.

These are its constraints.

This is the evidence we require.

This is how we determine whether it succeeded.

اس سے اس کام کو استدلال کرنا زیادہ مشکل ہو جاتا ہے۔ یہ آٹومیشن کو بھی کمزور بناتا ہے۔

جب قواعد ایک سے زیادہ ٹولز میں پھیلے ہوتے ہیں، تو قابل عمل پروگرام اکثر ڈی فیکٹو تفصیلات بن جاتا ہے۔

اور جب ایسا ہوتا ہے، تو یہ پوچھنا مشکل ہو جاتا ہے کہ کیا عمل کرنے والے نے صحیح طریقے سے کام کیا ہے۔

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

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

ایک تعیناتی اسکرپٹ کا تصور کریں۔

kubectl set image \
  deployment/orders \
  orders=registry.example.com/orders:2026.09.19

یہ Kubernetes کو بتاتا ہے: یہ کیسے کرنا ہے. اس کی پوری وضاحت نہیں کی گئی ہے۔ یہ رویہ قابل قبول کیوں ہے؟.

آپریشنل ارادہ اس کے قریب ہو سکتا ہے:

Deploy version 2026.09.19 of the Orders service.

Constraints:

- production must keep at least 3 available replicas
- the error rate must remain below 1%
- p95 latency must stay below 400 ms
- deployment is allowed only in us-east-1
- rollback must remain possible for 30 minutes

حکم اور ارادے کا تعلق ہے۔ لیکن وہ ایک جیسے نمونے نہیں ہیں۔

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

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

Kubernetes
Nomad
a cloud deployment service
a custom deployment controller
an AI-operated platform

جب آپریشنل اہداف کا آزادانہ طور پر اظہار کیا جاتا ہے، نافذ کرنے والے قابل بدل جاتے ہیں۔

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

ایک قابل عمل آپریشنل تفصیلات کیا ہے؟

ایک قابل عمل آپریشنل تصریح آپریشنل مقاصد کی مشین کے ذریعے پڑھنے کے قابل وضاحت ہے جس کا مشاہدہ شدہ شواہد کے خلاف جائزہ لیا جا سکتا ہے۔

کم از کم، آپ کو درج ذیل سوالات کا جواب دینا چاہیے:

What are we trying to achieve?

What constraints must hold?

What evidence should be collected?

How do we determine whether the operation conforms?

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

operation: deploy-orders-service

target:
  service: orders
  version: 2026.09.19
  environment: production

constraints:
  minAvailableReplicas: 3
  maxErrorRate: 0.01
  maxP95LatencyMs: 400
  region: us-east-1

evidence:
  - deployedVersion
  - availableReplicas
  - errorRate
  - p95Latency
  - region

یہ جان بوجھ کر آسان ہے۔ اہم حصہ YAML نحو نہیں ہے۔

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

یہ ہمیں مندرجہ ذیل ڈھانچہ فراہم کرتا ہے:

Operational intent
        ↓
Specification
        ↓
Executor
        ↓
Execution
        ↓
Evidence
        ↓
Evaluation

وضاحتیں ایک مستحکم حوالہ نقطہ فراہم کرتی ہیں۔

سادہ تعیناتی کی مثال

ہم کہتے ہیں کہ آپ ایک ورژن تعینات کرنا چاہتے ہیں۔ 2026.09.19 یہ ہماری آرڈرنگ سروسز میں سے ایک ہے۔

آپریشن صرف اس صورت میں کامیاب ہوگا جب:

the correct version is running
at least three replicas are available
error rate stays below 1%
p95 latency stays below 400 ms

ہم اسے اس طرح بیان کر سکتے ہیں:

type DeploymentSpec = {
  service: string;
  version: string;
  minAvailableReplicas: number;
  maxErrorRate: number;
  maxP95LatencyMs: number;
};

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

const spec: DeploymentSpec = {
  service: "orders",
  version: "2026.09.19",
  minAvailableReplicas: 3,
  maxErrorRate: 0.01,
  maxP95LatencyMs: 400,
};

اب مان لیں کہ پھانسی ثبوت پیش کرتی ہے۔

type DeploymentEvidence = {
  deployedVersion: string;
  availableReplicas: number;
  errorRate: number;
  p95LatencyMs: number;
};

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

const evidence: DeploymentEvidence = {
  deployedVersion: "2026.09.19",
  availableReplicas: 3,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

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

function conforms(
  spec: DeploymentSpec,
  evidence: DeploymentEvidence
): boolean {
  return (
    evidence.deployedVersion ===
      spec.version &&
    evidence.availableReplicas >=
      spec.minAvailableReplicas &&
    evidence.errorRate <=
      spec.maxErrorRate &&
    evidence.p95LatencyMs <=
      spec.maxP95LatencyMs
  );
}

پھر:

console.log(
  conforms(spec, evidence)
);

رپورٹ:

true

اب تصور کریں کہ آپ کی پائپ لائن تکنیکی طور پر کامیاب ہے، لیکن صرف دو نقلیں دستیاب ہیں۔

const evidence: DeploymentEvidence = {
  deployedVersion: "2026.09.19",
  availableReplicas: 2,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

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

تفصیلات یہ نہیں کرتی ہیں:

conforms → false

یہ وہی فرق ہے جو ہم چاہتے ہیں۔

کامیابی کے معیار کو ثبوت کی ضروریات میں تبدیل کریں۔

وضاحتیں اس وقت کارآمد ہو جاتی ہیں جب ان کے دعووں کا جائزہ لیا جا سکے۔

فرض کریں کہ وضاحتیں بیان کرتی ہیں:

error rate must remain below 1%

سسٹم کو پھر اس کے ثبوت کی ضرورت ہے:

error rate

درج ذیل صورتوں میں:

at least 3 replicas must remain available

پھر آپ کو اس کے ثبوت کی ضرورت ہوگی:

available replica count

یہ واضح لگ سکتا ہے، لیکن یہ ایک اہم اصول متعارف کراتا ہے۔

تمام آپریشنل ضروریات میں قابل مشاہدہ ثبوت شامل ہونا چاہیے۔

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

تقاضے	ثبوت
درست ورژن تعینات کر دیا گیا ہے۔	امیج/ورژن چل رہا ہے۔
کم از کم نقل دستیاب ہے۔	نقل کی تعداد
حد سے نیچے خرابی کی شرح	درخواست/خرابی میٹرکس
حد سے نیچے تاخیر	لیٹینسی میٹرکس
درست علاقہ	رن ٹائم تعیناتی۔
کوئی اسکیما ریگریشن نہیں ہے۔	اسکیما کی توثیق کے نتائج

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

غور کریں:

Deploy safely.

کیا ثبوت یہ ثابت کرتا ہے؟

بیان بہت مبہم ہے۔

ایک بہتر تصریح کو ان شرائط میں تحلیل کیا جاتا ہے جنہیں "محفوظ طریقے سے" چیک کیا جا سکتا ہے۔

تنہا مشاہدہ کیوں کافی نہیں ہے۔

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

کیا یہ صرف مشاہدہ نہیں ہے؟

بالکل نہیں۔ مشاہدہ آپ کو جواب دینے میں مدد کرتا ہے:

یہ کیا ہو رہا ہے؟

وضاحتیں آپ کو جواب دینے میں مدد کر سکتی ہیں:

کیا ہونا چاہیے؟

یہ ایک تکمیلی سوال ہے۔

آپ کا ڈیش بورڈ آپ کو بتا سکتا ہے:

error rate = 1.4%

یہ ایک مشاہدہ ہے۔

لیکن شاید 1.4% یہ قابل قبول ہے یا نہیں اس کا انحصار متوقع حالات پر ہے۔

تفصیلات کے بارے میں کہا جا سکتا ہے:

maxErrorRate = 1%

اب آپ اندازہ کر سکتے ہیں:

observed: 1.4%
expected: <= 1%

result: non-conformant

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

تصوراتی طور پر:

Specification
     +
Observed evidence
     ↓
Evaluation

تصریحات کے ذریعے خودکار تصدیق ممکن ہے۔

آزاد وضاحتوں کے بغیر آٹومیشن کی تصدیق کرنا مشکل ہے۔

ایک اسکرپٹ پر غور کریں جو درج ذیل کرتا ہے:

scale service
restart pods
change routing
wait
finish

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

آپ مؤثر طریقے سے پوچھ رہے ہیں:

کیا آٹومیشن نے وہی کیا جو اس نے کہا کہ اسے کرنا چاہئے؟

ایک علیحدہ تصریح ایک اور حوالہ نقطہ فراہم کرتی ہے۔

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

What was intended?

What did the executor do?

What evidence did execution produce?

Did the evidence satisfy the specification?

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

بجائے:

deployment failed

آپ ممکنہ طور پر کہہ سکتے ہیں:

deployment execution completed

but specification failed because:

availableReplicas:
expected >= 3
observed = 2

یہ بہت زیادہ مفید ہے۔

تصریحات کو ایگزیکیوٹرز سے آزاد رکھیں

اس ماڈل کی سب سے طاقتور خصوصیات میں سے ایک ایگزیکیوٹر کی آزادی ہے۔

فرض کریں کہ وضاحتیں بیان کرتی ہیں:

Deploy Orders version 2026.09.19

Keep:
- >= 3 replicas
- error rate <= 1%
- p95 latency <= 400 ms

ایک ایگزیکیٹر Kubernetes استعمال کر سکتا ہے۔ دوسرا ایک منظم کلاؤڈ پلیٹ فارم استعمال کر سکتا ہے۔ دوسرے حسب ضرورت آرکیسٹریٹرز استعمال کر سکتے ہیں۔

صرف اس وجہ سے تصریح کو تبدیل کرنے کی ضرورت نہیں ہے کہ ایگزیکیوٹر بدل گیا ہے۔

تصوراتی طور پر:

                 ┌── Kubernetes Executor
Specification ───┼── Cloud Executor
                 ├── Custom Executor
                 └── AI Agent

ہر عمل کرنے والا ثبوت پیش کرتا ہے۔ ہر پھانسی کا ایک ہی ارادے کے خلاف جائزہ لیا جاتا ہے۔

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

what should happen

پر:

how it happens

سافٹ ویئر انجینئرنگ کے دیگر شعبوں میں یہ علیحدگی عام ہے۔ انٹرفیس الگ کال کرنے والوں اور نفاذ کو۔ ایس کیو ایل استفسار اور اسٹوریج میکانزم کو الگ کرتا ہے۔ مطلوبہ ریاستی مشینیں گول ریاست کو کوآرڈینیشن منطق سے الگ کرتی ہیں۔

آپریشنل وضاحتیں آپریشنل ورک فلو پر اسی طرح کے خیالات کا اطلاق کرتی ہیں۔

کم سے کم ٹائپ اسکرپٹ ماڈل

ایک سادہ عام ماڈل ہے:

type Constraint = {
  name: string;
  evaluate(
    evidence: T
  ): boolean;
};

type OperationalSpec = {
  name: string;
  constraints: Constraint[];
};

تقسیم کے ثبوت کے لیے:

type Evidence = {
  version: string;
  replicas: number;
  errorRate: number;
};

آپ وضاحت کر سکتے ہیں:

const deploymentSpec:
  OperationalSpec = {
    name: "deploy-orders",
    constraints: [
      {
        name: "correct-version",
        evaluate: (evidence) =>
          evidence.version ===
          "2026.09.19",
      },
      {
        name: "minimum-replicas",
        evaluate: (evidence) =>
          evidence.replicas >= 3,
      },
      {
        name: "error-rate",
        evaluate: (evidence) =>
          evidence.errorRate <= 0.01,
      },
    ],
  };

اس کے بعد تمام رکاوٹوں کا جائزہ لیا جاتا ہے۔

function evaluate(
  spec: OperationalSpec,
  evidence: T
) {
  return spec.constraints.map(
    (constraint) => ({
      constraint: constraint.name,
      passed:
        constraint.evaluate(
          evidence
        ),
    })
  );
}

کے لیے:

const evidence: Evidence = {
  version: "2026.09.19",
  replicas: 2,
  errorRate: 0.003,
};

آپ حاصل کر سکتے ہیں:

correct-version    PASS
minimum-replicas   FAIL
error-rate         PASS

یہ ایک عام کامیابی یا ناکامی کے جھنڈے سے زیادہ مفید ہے۔ یہ آپ کو بتاتا ہے کہ مطلوبہ کام کے کس حصے پر عمل نہیں کیا گیا تھا۔

یہ CI/CD پر کیسے لاگو ہوتا ہے۔

CI/CD سسٹمز پہلے ہی کچھ اعلاناتی عناصر پر مشتمل ہیں۔

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

steps:
  - test
  - build
  - deploy

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

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

Deployment objective:
release version X

Constraints:
tests passed
artifact digest matches approved build
minimum replicas remain available
error rate stays below threshold
rollback remains possible

پائپ لائن اب بھی کام کرتی ہے۔ تفصیلات ان شرائط کی وضاحت کرتی ہے جو پائپ لائن کو پورا کرنا ضروری ہے۔ یہ پائپ لائن کی تبدیلی کو بھی آسان بناتا ہے۔

اگر آپ یہاں سے جا رہے ہیں:

GitHub Actions

کو:

GitLab CI

یا:

Argo

ایگزیکیوٹر بدل جاتا ہے۔

ضروری نہیں کہ آپریشنل اہداف اس طرح ہوں۔

یہ انفراسٹرکچر پر کیسے لاگو ہوتا ہے۔

بنیادی ڈھانچہ بطور کوڈ پہلے ہی مطلوبہ حالت فراہم کرتا ہے۔ اس کا اس خیال سے گہرا تعلق ہے۔

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

resource "aws_instance" "app" {
  instance_type = "t3.medium"
}

تاہم، آپریشنل ارادہ اکثر کنفیگریشن حالت سے آگے بڑھتا ہے۔

آپ کو اس میں بھی دلچسپی ہو سکتی ہے:

service availability
cost limits
regional restrictions
security controls
capacity
latency
backup freshness

یہ رکاوٹیں IaC کی تعریف سے باہر ہو سکتی ہیں۔ ایک آپریشنل تصریح اس کو جوڑنے میں مدد کرتی ہے۔

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

Provision application environment

Required:
3 instances
region = us-east-1
monthly projected cost < $500
encryption enabled
backup age < 24h

ایگزیکیوٹرز Terraform استعمال کر سکتے ہیں۔

شواہد اس سے مل سکتے ہیں:

cloud APIs
cost systems
security scanners
backup metadata

وضاحتیں ان ذرائع کے لیے ایک مشترکہ مقصد فراہم کرتی ہیں۔

یہ واقعہ کے ردعمل پر کیسے لاگو ہوتا ہے۔

وقوعہ کا ردعمل ایک اور شعبہ ہے جہاں عملدرآمد اور ارادے اکثر مل جاتے ہیں۔

ایک رن بک کچھ اس طرح کہہ سکتی ہے:

restart service
clear cache
scale replicas

تاہم، آپ کے اصل آپریشنل اہداف یہ ہو سکتے ہیں:

restore checkout availability

while:
avoiding duplicate payments
preserving order state
keeping error rate below threshold

فرق اہم ہے۔

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

ایک قابل عمل تصریح بحالی کے حالات کا اظہار کر سکتی ہے۔

checkout success rate > 99%
payment duplication = 0
queue backlog < threshold
error rate < 1%

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

یہ AI ایجنٹوں پر کیسے لاگو ہوتا ہے۔

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

AI ایجنٹ متحرک طور پر اپنے عمل کے راستے کا انتخاب کر سکتے ہیں۔ مثال کے طور پر، ایک آپریشن ایجنٹ فیصلہ کر سکتا ہے:

inspect metrics
restart a service
change capacity
modify a feature flag
reroute traffic

عین مطابق ترتیب واقعہ کے لحاظ سے مختلف ہو سکتی ہے۔ یہ ایگزیکیوٹر لیول کی تصدیق کو مزید مشکل بنا دیتا ہے۔

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

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

Objective:
restore API availability

Constraints:
do not disable authentication
do not lose queued requests
error rate < 1%
p95 latency < 500 ms
cost increase < 20%

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

یہ ایک مفید کنٹرول ڈھانچہ بناتا ہے۔

Human / organizational intent
        ↓
Operational specification
        ↓
Agent
        ↓
Actions
        ↓
Evidence
        ↓
Evaluation

جتنا زیادہ خود مختار عمل درآمد ہوتا ہے، یہ علیحدگی اتنی ہی قیمتی ہوتی جاتی ہے۔

آپریٹنگ وضاحتیں میں کیا ہونا چاہئے؟

مفید خصوصیات میں اکثر متعدد زمرے شامل ہوتے ہیں۔

مقصد

کیا حاصل کرنے کی ضرورت ہے؟

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

Deploy Orders service version 2026.09.19

رینج

کام کہاں لاگو ہوتا ہے؟

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

environment: production
region: us-east-1
service: orders

فارماسیوٹیکل

کیا سچ رہنا چاہیے؟

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

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

مطلوبہ ثبوت

مجھے کیا مشاہدہ کرنا چاہئے؟

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

running version
replica count
error rate
latency

تشخیص کے قوانین

آپ یہ کیسے طے کرتے ہیں کہ آیا کوئی پریکٹس مطابقت رکھتی ہے؟

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

version must match exactly
replicas must be >= 3
error rate must be <= 0.01

بحالی کے حالات

اگر فٹ نہ ہو جائے تو کیا ہوگا؟

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

stop rollout
restore previous route
require human approval

تمام وضاحتیں ان تمام اشیاء کی ضرورت نہیں ہیں۔

لیکن ان کو الگ کرنے سے آپریشنل ارادے زیادہ واضح ہو جاتے ہیں۔

تصریح سے کیا خارج ہونا چاہئے؟

ایک تصریح ایک اور نفاذ کا اسکرپٹ نہیں ہونا چاہئے۔ اس کا مطلب ہے کہ غیر ضروری ایگزیکیوٹر کے مخصوص میکانزم سے گریز کریں۔

مثال کے طور پر، یہ بہت زیادہ نفاذ کے لیے مخصوص ہو سکتا ہے۔

run kubectl command X
wait 10 seconds
call endpoint Y
run shell command Z

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

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

service version = 2026.09.19
available replicas >= 3
health checks passing

کچھ مفید قواعد میں شامل ہیں:

اگر ایگزیکیوٹیبل میں تبدیلیوں کے لیے تصریح کو دوبارہ لکھنے کی ضرورت ہوتی ہے تو تصریح میں بہت زیادہ نفاذ کی تفصیلات شامل ہوسکتی ہیں۔

کچھ ایگزیکیوٹر کے لیے مخصوص رکاوٹیں ناگزیر ہیں۔ تاہم، پہلے سے طے شدہ ارادے اور طریقہ کار کو الگ رکھنا ہے۔

عملی ورک فلو

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

1. ایک اہم کام کا انتخاب کریں۔

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

deploy service
rotate certificate
restore backup
scale worker pool

2. اپنے مقاصد کو لکھیں۔

پوچھیں:

کامیابی کا اصل مطلب کیا ہے؟

نہیں:

مجھے کونسی کمانڈ چلانی چاہئے؟

3. رکاوٹوں کی شناخت کریں۔

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

minimum availability
maximum error rate
security requirements
regional restrictions
cost limits

4. ثبوت چیک کریں۔

ہر رکاوٹ کے لیے، پوچھیں:

کیا مشاہدات اس شرط کو ثابت یا غلط ثابت کر سکتے ہیں؟

5. عمل کرنے والوں کی علیحدگی

تصریحات سے آزادانہ طور پر آپریشن کرنے کے طریقہ کار کو برقرار رکھیں۔

6. نفاذ کے بعد کی تشخیص

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

7. مطابقت کی اطلاع دیں۔

ترجیح دیں:

3 constraints passed
1 constraint failed

اوپر:

operation failed

8. تفصیلات میں بہتری

گمشدہ ثبوت اور مبہم رکاوٹیں جلد ہی عیاں ہو جاتی ہیں۔

یہ مفید ہے۔

جیسا کہ آپریشنل علم واضح ہوتا جاتا ہے، وضاحتیں بہتر ہوتی جاتی ہیں۔

کیا قابل عمل وضاحتیں حل نہیں کرتی ہیں۔

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

درج ذیل خود بخود حل نہیں ہوں گے:

bad requirements
incorrect metrics
missing observability
distributed transactions
security failures
poor executor implementations
organizational ownership
conflicting business goals

یہ اپنے خطرات بھی لاتا ہے۔

• ایک خراب تصریح غلط مقصد کو انکوڈ کر سکتی ہے۔

• نامکمل وضاحتیں غلط اعتماد پیدا کر سکتی ہیں۔

• پرانی وضاحتیں بڑھنے کی ایک اور وجہ ہو سکتی ہیں۔

• اور تمام آپریشنل فیصلوں کو سادہ حد تک کم نہیں کیا جا سکتا۔

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

خودکار آپریشنز سے لے کر قابل تصدیق آپریشنز تک

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

آپ کو کیسے پتہ چلے گا کہ آپ کی آٹومیشن نے صحیح نتائج حاصل کیے ہیں؟

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

یہ ہمیں دیتا ہے:

intent
↓
constraints
↓
evidence requirements
↓
execution
↓
observed evidence
↓
evaluation

ڈھانچہ مندرجہ ذیل کاموں کو تبدیل کرتا ہے:

something happened

میں:

something happened,
we know what was expected,
we collected evidence,
and we can evaluate the result.

یہ آٹومیشن کے لیے بہت مضبوط بنیاد ہے۔

نتیجہ

آپ جتنے زیادہ سافٹ ویئر کے کاموں کو خودکار بناتے ہیں، اتنا ہی اہم ہو جاتا ہے کہ انہیں الگ کر دیا جائے۔ ہم کیا چاہتے ہیں سے ٹول یہ کیسے کرتا ہے۔.

پائپ لائنز ایگزیکیوٹرز ہیں۔

انفراسٹرکچر ٹولز، اسکرپٹس، اور AI ایجنٹس ایگزیکیوٹرز ہیں۔ وہ سب کام کروا سکتے ہیں۔

تاہم، آپریشنل مقاصد کو ان میکانزم سے آزادانہ طور پر موجود ہونا چاہیے جو انہیں انجام دیتے ہیں۔

قابل عمل آپریشنل وضاحتیں ان اہداف کو ان شرائط میں بیان کرنے کا ایک طریقہ فراہم کرتی ہیں:

desired outcome
constraints
required evidence
evaluation rules

پھانسی پھر ایسی چیز بن جاتی ہے جو محض مشاہدہ کرنے کے بجائے تصدیق کی جاسکتی ہے۔

یہ آج کی تعیناتیوں، بنیادی ڈھانچے، اور واقعے کے ردعمل کے لیے اہم ہے۔

یہ تیزی سے اہم ہو جائے گا کیونکہ آپریٹنگ سسٹم تیزی سے خود مختار ہوتے جائیں گے۔

کیونکہ آٹومیشن آپ کو بتا سکتی ہے کہ ایک کام انجام دیا گیا ہے۔

ہمیں واقعی یہ جاننے کی ضرورت ہے کہ کیا نظام وہیں ہے جہاں اسے ہونا چاہئے۔