صارف کو نظر آنے والے فنکشن کی نگرانی کریں، اس کی تشخیص کے لیے کافی وسائل اور ایپلیکیشن ثبوت شامل کریں، اور صرف ان حالات کے لیے پیج کریں جن کے لیے بروقت انسانی کارروائی درکار ہو۔ ہر الرٹ کے ساتھ ایک ذمہ دار، پہلا قدم اور ایسکلیشن جوڑیں۔ واقعے کے دوران تخفیف کو مربوط کریں، ثبوت کی حفاظت کریں اور اصل صارف سفر کے ذریعے بحالی کی تصدیق کریں۔
اس فنکشن سے شروع کریں جو اہم ہے
سرور کا پنگ کا جواب دینا یہ ثابت نہیں کرتا کہ اس کی ایپلیکیشن کام کرتی ہے۔ ایک نمائندہ، بے ضرر صارف سفر منتخب کریں، جیسے کوئی عوامی صفحہ حاصل کرنا یا کنٹرول شدہ ٹیسٹ اینڈ پوائنٹ تک رسائی۔ کامیابی کی تعریف کریں اور ایسے مصنوعی چیکس سے بچیں جو ہر رن کے دوران حقیقی آرڈر بنائیں، مواد شائع کریں یا گاہک اطلاعات بھیجیں۔
ایپلیکیشن کے اندر کے ساتھ ساتھ ایک مناسب بیرونی نقطہ نظر سے بھی نگرانی کریں۔ بیرونی مشاہدہ رسائی یا روٹنگ کے مسائل ظاہر کر سکتا ہے جو سرور نہیں دیکھتا۔ داخلی پیمائشیں بتا سکتی ہیں کہ سفر کیوں ناکام ہوا۔ دونوں نظریات کو فنکشن سے منسلک رکھیں، بجائے اس کے کہ صرف اس لیے بڑا ڈیش بورڈ جمع کیا جائے کہ ہر میٹرک دستیاب ہے۔
تشخیصی قدر والے سگنلز منتخب کریں
گوگل کی SRE رہنمائی صارف کے سامنے آنے والے نظاموں کے لیے لیٹنسی، ٹریفک، غلطیاں اور سیچوریشن کو مفید سگنلز کے طور پر نمایاں کرتی ہے۔ انہیں رویے کی وضاحت کے لیے استعمال کریں: جواب کا وقت، درخواست کا حجم، ناکام درخواستیں اور محدود وسائل پر دباؤ۔ ایسی پیمائشیں منتخب کریں جو ایپلیکیشن کے مطابق ہوں، بجائے اس کے کہ ایک میٹرک تعریف کو ویب سائٹ، ٹرانسفر سروس اور بیک گراؤنڈ ورکر سب کے لیے یکساں فرض کیا جائے۔
جہاں اہم ہو وہاں کامیاب اور ناکام درخواست کے رویے کو الگ کریں، اور صرف اوسط کے بجائے سست دم کے نتائج کا جائزہ لیں۔ میموری پریشر، ڈسک اسپیس، قطار کی گہرائی یا ایپلیکیشن سے متعلق مخصوص حدود شامل کریں جب وہ سروس کی وضاحت کریں۔ مفید بیچ کام کے دوران CPU کی بلند ریڈنگ معمول ہو سکتی ہے؛ صارف کو نظر آنے والا اثر طے کرتا ہے کہ فوری کارروائی درکار ہے یا نہیں۔
ہر الرٹ کو ایک عمل اور ایک ذمہ دار دیں
الرٹ میں متاثرہ فنکشن، مشاہدہ شدہ حالت اور مفید پہلا چیک بتایا جانا چاہیے۔ اسے تعینات کرنے سے پہلے ایک ذمہ دار اور ایسکلیشن راستہ تفویض کریں۔ فوری مداخلت طلب کرنے والی حالتوں کو شیڈول شدہ جائزے کے لیے موزوں اشیاء سے الگ کریں۔ بار بار کم قیمت پیجز آپریٹرز کو سسٹم نظر انداز کرنا سکھاتے ہیں اور اہم سگنلز کی شناخت مشکل بنا دیتے ہیں۔
ابہام دور کرنے کے لیے ایک مختصر الرٹ جائزہ استعمال کریں۔ یہ مثالی جدول ممکنہ مانیٹرنگ فیصلوں کی وضاحت کرتا ہے، نہ کہ SwissOctet سپورٹ کوریج یا دستیابی کے عہد کی۔ حدوں کو اصل ایپلیکیشن کی بیس لائن کے خلاف جانچنے کی ضرورت ہے۔ بحالی کی شرط شامل کریں تاکہ آپریٹر جان سکے کہ الرٹ کب ختم ہوا اور کس چیز کی تصدیق باقی ہے۔
| مشاہدہ شدہ حالت | مفید جواب | شامل کرنے کے لیے سیاق و سباق |
|---|---|---|
| نمائندہ صارف سفر ناکام ہوتا ہے | اثر کا جائزہ لیں اور تخفیف کریں | متاثرہ اینڈ پوائنٹ، دورانیہ اور حالیہ تبدیلی |
| ڈسک منصوبہ بند حد کے قریب | گروتھ اور برقراری کا جائزہ لیں | حجم، گروتھ ریٹ اور محفوظ ہیڈ روم |
| بیک اپ کی تصدیق ناکام | بحالی کے راستے کی حفاظت کریں | جاب، آخری قابل استعمال نقطہ اور خرابی |
| ریلیز کے دوران لیٹنسی بڑھتی ہے | تبدیلی کا معائنہ کریں یا اسے واپس کریں | بیس لائن، ریلیز کا وقت اور متاثرہ درخواستیں |
ایک چھوٹا واقعہ ڈھانچہ تیار کریں
جواب کا عمل دباؤ میں قابل فہم ہونا چاہیے۔ ایک کوآرڈینیٹر، تکنیکی کام سنبھالنے والا شخص اور اپ ڈیٹس کا ذمہ دار شخص نامزد کریں جب واقعہ اتنا بڑا ہو کہ الگ کردار درکار ہوں۔ چھوٹا پروجیکٹ کرداروں کو یکجا کر سکتا ہے، مگر اسے بھی ایک واضح فیصلہ نقطہ سے فائدہ ہوتا ہے۔ سروس ناکام ہونے سے پہلے مواصلاتی چینل طے کریں۔
گوگل کا واقعہ جواب کا مواد ہم آہنگی اور تخفیف کو ترجیح دینے پر زور دیتا ہے۔ اسے پروجیکٹ کے مطابق پیمانے پر لاگو کریں: اثر قائم کریں، محفوظ اقدامات منتخب کریں اور کئی آپریٹرز کو متضاد تبدیلیاں کرنے سے روکیں۔ ٹائم لائن اور فیصلے ریکارڈ کریں۔ مکمل وضاحت کی تلاش کو کسی محفوظ اقدام میں تاخیر نہیں کرنی چاہیے جو متاثرہ فنکشن بحال کرے۔
ایک ٹھوس کمی کا جائزہ لیں
فرض کریں کہ ریلیز کے بعد کوئی سائٹ سست ہو جاتی ہے۔ بیرونی چیک مکمل ہونے کا وقت بڑھا ہوا دکھاتا ہے، جبکہ داخلی پیمائشیں ایپلیکیشن کی غلطیاں اور بڑھتا ڈیٹا بیس کام دکھاتی ہیں۔ کوآرڈینیٹر ایک محدود واقعہ قرار دیتا ہے، ثبوت کی حفاظت کرتا ہے اور ایک شخص کو ریلیز کا بیس لائن سے موازنہ کرنے کا کام دیتا ہے۔ دوسرا غیر متعلقہ انفراسٹرکچر تبدیلیاں کرنے کے بجائے آزمودہ رول بیک راستہ تیار کرتا ہے۔
اگر رول بیک ایپلیکیشن کے ڈیٹا کی حالت کے لیے محفوظ ہو تو اسے استعمال کریں اور نتیجہ دیکھیں۔ اگر محفوظ نہ ہو تو آپریٹنگ پلان کی تائید یافتہ کوئی زیادہ محدود تخفیف منتخب کریں۔ دستاویز کریں کہ کیا اور کب تبدیل ہوا۔ بڑا VPS یا پورٹ بعد میں جانچنے کے قابل ہو سکتا ہے، مگر فوری فیصلہ ثبوت کو حل کرنا چاہیے، بجائے اس کے کہ انفراسٹرکچر کے سائز کو وجہ فرض کیا جائے۔
ثبوت کی حفاظت کریں اور بحالی کی تصدیق کریں
آپریشنل لاگز اور واقعہ نوٹس میں پتے، شناخت کنندہ اور گاہک کی معلومات ہو سکتی ہیں۔ تحقیق کے لیے درکار چیزیں جمع کریں، رسائی محدود کریں اور اسناد یا نجی آرڈر ٹوکن مشترکہ رپورٹس سے باہر رکھیں۔ مشتبہ سیکیورٹی واقعے کے لیے مناسب ثبوت محفوظ کریں اور پروجیکٹ کی جواب پالیسی کی پیروی کریں، بجائے اس کے کہ جلد بازی میں صفائی کے ذریعے معلومات تباہ کر دی جائیں۔
NIST کی واقعہ جواب رہنمائی جواب کو وسیع تر سائبر سیکیورٹی رسک مینجمنٹ کے اندر رکھتی ہے۔ بحالی میں مطلوبہ فنکشن کی جانچ اور اس حالت کو حل کرنا شامل ہے جس نے واقعہ ممکن بنایا۔ جواب بند کرنے سے پہلے صارف سفر کی جانچ کریں، وسائل کے رویے کا جائزہ لیں اور بیک گراؤنڈ کام چیک کریں۔ صرف الرٹ ختم ہونا یا عمل ری اسٹارٹ ہونا مفید سروس کی مکمل واپسی کا مظاہرہ نہیں کر سکتا۔
واقعے کو ایک قابل پیمائش بہتری میں بدلیں
اثر، ٹائم لائن، معاون حالات اور کیے گئے اقدامات کا مختصر جائزہ لکھیں۔ ان تبدیلیوں پر توجہ دیں جن کی تصدیق ہو سکے: کوئی چیک بہتر کریں، اجازت درست کریں، رول بیک کی مشق کریں یا غائب بحالی انحصار شامل کریں۔ ذمہ دار اور تکمیل کے معیار تفویض کریں۔ مبہم ارادوں کی لمبی فہرست سے بچیں جنہیں بعد میں کوئی تصدیق نہ کر سکے کہ لاگو ہوئے تھے۔
SwissOctet پر تعیناتی کرتے وقت، مانیٹرنگ اور جواب کو ایپلیکیشن کے آپریشن کے حصے کے طور پر منصوبہ بند کریں، منتخب ہارڈویئر اور کسی تصدیق شدہ انتظامی انتظام سے الگ۔ کیٹلاگ کسی مستقل واقعہ ٹیم یا مسلسل سپورٹ اوقات کو قائم نہیں کرتا۔ پروڈکشن ماحول پر انحصار کرنے سے پہلے فیصلہ کریں کہ الرٹس کون وصول کرتا ہے، کون کارروائی کر سکتا ہے اور اصل سروس کی شرائط کیا احاطہ کرتی ہیں۔
آپ کی عملی چیک لسٹ۔
- ایک بے ضرر نمائندہ صارف سفر کی نگرانی کریں۔
- ایسے سگنلز منتخب کریں جو ایپلیکیشن کے رویے کی وضاحت کریں۔
- الرٹس کو ایک عمل، ذمہ دار اور بحالی کی شرط دیں۔
- واقعے سے پہلے ہم آہنگی اور ایسکلیشن طے کریں۔
- ثبوت کی حفاظت کریں اور مکمل بحالی کی تصدیق کریں۔
- جائزے کے بعد قابل جانچ بہتریاں تفویض کریں۔
وہ تفصیلات جو اہم ہیں۔
کیا سرور اپ ٹائم مانیٹرنگ کافی ہے؟+
نہیں۔ قابل رسائی مشین خراب ایپلیکیشن کی میزبانی کر سکتی ہے۔ صارفین کے انحصار والے فنکشن کی نگرانی کریں اور ناکامیوں کی تشخیص کے لیے وسائل کا ثبوت شامل کریں۔
کیا ہر میٹرک حد کو فوراً کسی کو پیج کرنا چاہیے؟+
نہیں۔ فوری مداخلتیں ان قابل عمل حالتوں کے لیے مخصوص رکھیں جن پر بروقت توجہ درکار ہو۔ کم ترجیحی کام کو واضح ذمہ دار کے ساتھ جائزے کے عمل میں بھیجیں۔
واقعہ کب ختم ہوتا ہے؟+
متاثرہ فنکشن اور متعلقہ بیک گراؤنڈ کام کی تصدیق، فوری خطرات کی نمٹانے اور فالو اپ اقدامات ریکارڈ کرنے کے بعد۔ صرف عمل ری اسٹارٹ کرنا ناکافی ہے۔
ماخذ پر جائیں۔
یہ حوالہ جات اس گائیڈ میں تکنیکی تصورات کی حمایت کرتے ہیں۔ پروڈکشن سسٹم تبدیل کرنے سے پہلے موجودہ دستاویزات کی پیروی کریں۔
- گوگل SRE: تقسیم شدہ نظاموں کی نگرانی sre.google
- گوگل SRE ورک بک: واقعہ جواب sre.google
- NIST SP 800-61 Rev. 3: واقعہ جواب csrc.nist.gov
SwissOctet کی طرف سے ادارتی رہنمائی۔ مثالیں مثالی ہیں۔ سروس کی تفصیلات، دستیاب اختیارات اور معاہدے کی شرائط الگ سے تصدیق شدہ ہونی چاہئیں۔