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

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

ان میں سے کچھ ممکنہ طور پر ایسی ہیں جن کے بارے میں ٹیم محتاط ہے۔ اس کا ایک حصہ اس بات کا ریکارڈ ہوسکتا ہے کہ پروڈکٹ ٹیم اب بھی کتنا بنیادی ڈھانچہ دیکھ رہی ہے۔

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

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

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

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

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

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

بنیادی ڈھانچے کے نصف کے لئے، ہر چیز اب بھی اہم ہے. سوال یہ ہے کہ انسان اسے کیوں چیک کرے گا، اور براہ راست جواب دیتے رہنے کی کیا قیمت ہے؟

ہم کیا احاطہ کریں گے:

ایک فہرست میں دو قسم کے خطرات

اپنی موجودہ چیک لسٹ کھولیں اور تمام اشیاء کو دو کالموں میں ترتیب دیں۔

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

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

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

یہ ایک بار بار چلنے والی پلیٹ فارم کی ذمہ داری ہے، ایپلیکیشن کے لیے مخصوص فیصلے کی کال نہیں۔ ہر پروڈکشن ٹیم کو ان مسائل کا سامنا ہے، اس لیے انہیں دستی طور پر دوبارہ چیک کرنے کے بجائے مسلسل نافذ کرنے کی ضرورت ہے۔

اصل فہرست میں اسپلٹ کیسا دکھتا ہے: فرض کریں کہ فی الحال آپ کے ویکی پیج پر ایک ساتھ 11 اندراجات ہیں۔ خلاصہ کرنے کے لئے، یہ مندرجہ ذیل ہے.

درخواست کا خطرہ (ہر تعیناتی کے ساتھ تبدیلیاں)	بنیادی ڈھانچے کا خطرہ (ہر تعیناتی کے لیے یکساں)
ہے full_name کیا ہجرت الٹ سکتی ہے؟	کیا میرا TLS سرٹیفکیٹ اگلے 30 دنوں کے لیے درست ہے؟
کیا پرانا انوائس ورکر نئے ٹاسک پے لوڈ کو پڑھے گا؟	کیا تصویر اس کمٹ سے بنی ہے جسے آپ تعینات کر رہے ہیں؟
Redis میں پہلے سے ہی سیشنز کا کیا ہوتا ہے؟	کیا آٹو اسکیلنگ کے اصول اس مثال کے سائز کے لیے موزوں ہیں؟
ہے PAYMENT_TIMEOUT_MS کیا یہ پیداوار میں جا رہا ہے؟	کیا نئی مثال پر لاگ اور میٹرکس دستیاب ہیں؟
کیا اس ہفتے اس سروس کے لیے رول بیک کا تجربہ کیا گیا ہے؟	کیا اب بھی پچھلی ریلیز ہیں جن پر آپ واپس جا سکتے ہیں؟
	کیا آپ نے پچھلی مثال کے ختم ہونے سے پہلے کنکشن ختم کر دیے تھے؟

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

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

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

پہلا کالم: اپنے کیس پر تعمیر کریں۔

آخری 10 واقعات کا انتخاب کریں۔ ہر ایک کے لیے، پوچھیں کہ کیا تعیناتی سے پہلے ایک ہی چیک نے اسے پکڑا تھا۔ ایک پیٹرن تیزی سے ابھرنا چاہئے.

زیادہ تر ٹیموں کو معلوم ہوتا ہے کہ زیادہ تر بندش کی تین یا چار وجوہات ہیں: غلط کنفیگریشنز، سکیما میں غیر محفوظ تبدیلیاں، غیر تیاری شدہ انحصار، اور غیر کام کرنے والے رول بیکس۔

آپ جو 4 اشیاء استعمال کرتے ہیں ان کا وزن ان 40 سے زیادہ ہے جنہیں آپ نظر انداز کرتے ہیں۔ گوگل کی SRE ٹیم ریلیز انجینئرنگ کے باب میں نکتہ بیان کرتی ہے۔ یہاں مقصد ایک محتاط، بہادری کی رہائی نہیں ہے، لیکن ایک بورنگ، دوبارہ قابل رہائی ہے.

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

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

سپورٹ سوالات پوچھنے کے قابل

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

• کیا میں اس کارروائی کو 2 منٹ میں منسوخ کر سکتا ہوں؟ یقین نہیں ہے کہ دستاویزات میں رول بیک پلان موجود ہے یا نہیں۔ آپ چیک کر سکتے ہیں کہ آیا آپ کا اس ہفتے اس سروس پر تجربہ کیا جا رہا ہے۔ غیر تجربہ شدہ رول بیکس امید ہیں، کنٹرول نہیں۔

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

• کیا ڈیٹا بیس کی تبدیلیاں خود محفوظ ہیں؟ اس کا اپنا حصہ ذیل میں ملتا ہے۔

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

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

درخواست کے تین خطرات جو شاذ و نادر ہی فہرست بناتے ہیں۔

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

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

اس کی وجہ بننے والی تبدیلیوں میں شامل ہیں: ڈویلپرز جاب کے پے لوڈ کو صاف کرتے ہیں۔

# NEW producer code. Looks harmless in review.
enqueue("send_invoice", {
    "customer": {"id": 42, "email": "ada@example.com"},
})

وہ صارفین جو اب بھی پیداوار میں چل رہے ہیں وہ پرانے صارفین ہیں اور وہ کلیدیں پڑھتے ہیں جو اب موجود نہیں ہیں۔

# OLD consumer, still live for the next few minutes
def send_invoice(payload):
    customer = db.get_customer(payload["customer_id"])  # KeyError

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

حل یہ ہے کہ ایک ریلیز کے لیے دونوں فارم بھیجے جائیں تاکہ صارف کے دونوں ورژن پیغام کو پڑھ سکیں۔

# Safe producer: old key stays until every consumer is new
enqueue("send_invoice", {
    "customer_id": 42,                                   # old consumers read this
    "customer": {"id": 42, "email": "ada@example.com"},  # new consumers read this
})

پھر ایک نیا صارف تعینات کریں، قطار کو خالی کریں، اور اسے حذف کریں۔ customer_id بعد کی ریلیز میں۔ ڈیٹابیس کالموں کی طرح ایک ہی اصول: انہیں شامل کیا جا سکتا ہے، منتقل کیا جا سکتا ہے اور ہٹایا جا سکتا ہے، لیکن بیک وقت نہیں۔

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

مسئلہ یہ ہے کہ منتقلی کی فائل موجود نہیں ہے، اس لیے کوئی انتباہی پیغام نہیں ہے۔

# Yesterday's code wrote this shape, and it's still sitting in Redis
cache.set(f"user:{user.id}", {"name": "Ada Lovelace"}, ex=86400)

# Today's code reads it
profile = cache.get(f"user:{user.id}")
first = profile["first_name"]   # KeyError on every object cached before the deploy

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

CACHE_VERSION = "v2"   # bump this whenever the stored shape changes

def cache_key(user_id):
    return f"user:{CACHE_VERSION}:{user_id}"

cache.set(cache_key(user.id), {"first_name": "Ada", "last_name": "Lovelace"}, ex=86400)

نیا کوڈ نئی کلید کو کھو دیتا ہے، اسے ڈیٹا بیس میں دوبارہ بناتا ہے، اور جاری رہتا ہے۔ قابل احترام user:* اشیاء خود ہی ختم ہو جاتی ہیں۔ ایک لائن والا ورژن ٹکرانا وقفے کی جگہ لے لیتا ہے۔

کولڈ سٹارٹ کی گنجائش تیسری ہے، اور یہ کنارے پر پڑا ہے۔ رولنگ تعیناتیاں مختصر طور پر کیڑے کی کم مثالوں کے ساتھ عام ٹریفک فراہم کرتی ہیں۔

اگر آپ کی ایپ کو کنکشن پول تیار کرنے کے لیے 40 سیکنڈز کی ضرورت ہے اور رعایتی مدت 30 سیکنڈ ہے، تو آپ کو بدترین ممکنہ وقت پر پتہ چل جائے گا۔ یہ ترتیب کاٹا ہوا ورژن ہے۔

readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  failureThreshold: 6      # gives up after ~30s. The app needs 40.

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

# Generous window for the first boot only
startupProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  failureThreshold: 18     # allows 90s to warm the pool

# Tight window once the app is up
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  failureThreshold: 3

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

ڈیٹا بیس کی منتقلی وہ جگہ ہے جہاں رول بیکس رک جاتے ہیں۔

آپ اپنے کوڈ کو چند سیکنڈ میں رول بیک کر سکتے ہیں، لیکن آپ حذف شدہ کالموں کو رول بیک نہیں کر سکتے۔

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

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

پیٹرن کو توسیع اور معاہدہ کہا جاتا ہے۔ نام تبدیل کریں users.name کو users.full_name یہ کام کی ایک لائن کی طرح لگتا ہے۔ اگر محفوظ طریقے سے مکمل ہو جائے تو چار تعیناتیاں مکمل ہو جائیں گی۔

ایک کو تعینات کرنے سے صرف کالم شامل ہو گا اور کچھ نہیں۔

-- Nullable, no default, so there is no table rewrite and no long lock
ALTER TABLE users ADD COLUMN full_name varchar(255);

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

def save_user(user, name):
    user.name = name          # still the source of truth
    user.full_name = name     # new column starts filling

پھر ہم ان قطاروں کو بیک فل کرتے ہیں جو دونوں کو تعینات کرنے سے پہلے موجود تھیں (بیچوں میں تالے کو زیادہ دیر تک رکھنے سے بچنے کے لیے)۔

-- Repeat until it reports 0 rows
UPDATE users SET full_name = name
WHERE full_name IS NULL
LIMIT 5000;

2 تعیناتیوں کے لیے رول بیک اب بھی محفوظ ہے کیونکہ نئے کالم پڑھنے کے لیے 3 تعیناتی فال بیک۔

display_name = user.full_name or user.name

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

ALTER TABLE users DROP COLUMN name;

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

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

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

علیحدہ تعیناتی اور رہائی

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

جھنڈے کے بعد ایک نیا رویہ شامل کرنا دونوں کو الگ کرتا ہے۔ آپ کے کوڈ میں، یہ ایک شاخ اور ایک مقام ہے جو تعین کرتا ہے:

def checkout(request, user):
    if flags.enabled("new_checkout", user=user):
        return new_checkout(request, user)
    return legacy_checkout(request, user)

اسے جھنڈے کے ساتھ رکھیں۔ نیا راستہ سرور پر ہے اور کوئی بھی اس تک رسائی حاصل نہیں کرسکتا۔

# flags.yaml — deploy 1: code is live, behaviour is not
new_checkout:
  enabled: false

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

new_checkout:
  enabled: true
  audience: internal      # your staff accounts only

پھر 1% حقیقی صارفین کے لیے اس سلائس میں غلطی کی شرح اور تاخیر کو دیکھیں۔

new_checkout:
  enabled: true
  audience: percentage
  percentage: 1

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

new_checkout:
  enabled: true
  audience: percentage
  percentage: 100
  remove_by: 2026-11-01   # delete the flag and legacy_checkout by this date

اگر کسی بھی مرحلے پر کچھ غلط معلوم ہوتا ہے، تو درج ذیل سیٹ کریں: enabled: false دوبارہ تعینات کرنے کے بجائے، بازیابی میں صرف سیکنڈ لگتے ہیں۔

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

یاد رہے کہ جھنڈوں پر بھی پیسے خرچ ہوتے ہیں، کیونکہ پرانے جھنڈے ڈیڈ کوڈ بن جاتے ہیں۔ لہذا اس بات کو یقینی بنائیں کہ آپ اسے شامل کرتے وقت ہٹانے کی تاریخ مقرر کرتے ہیں۔ کہ remove_by یہی وجہ ہے کہ میدان کسی کے سر میں نہیں کمپوزیشن میں ہے۔

شپنگ سے پہلے رول بیک ٹرگر کا تعین کریں۔

رول بیکس اکثر دیر سے ہوتے ہیں۔ کیونکہ کوئی بھی "برے” کی طرح نظر آنے پر پہلے سے متفق نہیں تھا۔ جب دباؤ ڈالا جاتا ہے، لوگ مذاکرات کرتے ہیں اور یہ دیکھنے کے لیے ایک منٹ اور انتظار کرتے ہیں کہ آیا غلطی دور ہو گئی ہے۔

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

1. 2 منٹ کے لیے غلطی کی شرح 1% سے زیادہ ہے۔

2. 95ویں پرسنٹائل پر تاخیر معمول کی قدر سے دو گنا زیادہ ہے۔

3. قطار کی گہرائی بحالی کے بغیر بڑھ جاتی ہے۔

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

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

دوسرا کالم: فہرست سے خارج کریں۔

اب انفراسٹرکچر کالم پر واپس جائیں اور ہر آئٹم کے بارے میں مختلف سوالات پوچھیں۔ نہیں "کیا یہ چیک کرنے کے قابل ہے؟” کہ اس کے بجائے، پوچھیں، "وہ شخص اسے کیوں چیک کر رہا ہے؟”

واضح جواب خودکار کرنا ہے۔ سرٹیفکیٹ کی تجدید خود بخود ہوتی ہے۔ تصویر کا ذریعہ ایک پائپ لائن کنٹرول بن جاتا ہے جو غیر مصدقہ تعمیرات کو فروغ دینے سے انکار کرتا ہے۔ کنفیگریشن ڈرفٹ تعیناتی کے وقت ایک چیک بن جاتا ہے۔

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

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

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

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

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

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

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

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

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

اسے مختصر رکھیں اور اسٹوریج میں رکھیں

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

یہاں قابل عمل ورژن ہیں:

• اس بات کو یقینی بنائیں کہ آپ جو بھی تبدیلیاں کرتے ہیں، بشمول ٹاسک پے لوڈز اور کیشڈ ڈیٹا، آپ کے چلا رہے ورژن کے ساتھ پیچھے کی طرف مطابقت رکھتے ہیں۔

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

• چیک کریں کہ آیا نئی کنفیگریشن پہلے سے ہی ہدف کے ماحول میں موجود ہے۔

• رول بیک ٹرگر کے لیے ایک نام بتاتا ہے۔

• بیان کریں کہ تبدیلیوں کو صارفین تک کیسے پہنچایا جائے گا۔

• ان لوگوں کے نام جنہوں نے پہلے 15 منٹ دیکھے۔

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

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

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

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

مجھے امید ہے کہ آپ نے اس مضمون کا لطف اٹھایا۔ آپ مجھ سے LinkedIn پر رابطہ کر سکتے ہیں۔