ڈی او اوپس کی عام غلطیاں اور ان سے کیسے بچنا ہے - اسٹارٹ اپس کے لیے نکات

زیادہ تر DevOps انجینئرز ٹول کے علم کی کمی کی وجہ سے ناکام نہیں ہوتے ہیں۔ وہ ناکام ہو جاتے ہیں کیونکہ کسی نے انہیں نہیں بتایا کہ کیا کرنا ہے۔ ~ نہیں پیداوار میں جانے سے پہلے آپ کو کیا کرنے کی ضرورت ہے۔

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

یہ مضمون 10 انتہائی مہنگی DevOps غلطیوں کا پہلا تجزیہ ہے جو انجینئرز اپنے کیریئر کے آغاز میں ابتدائی طور پر کرتے ہیں۔ ہر غلطی کے لیے، آپ کو حقیقی زندگی کا منظرنامہ، کاروباری اثرات، اور مخصوص اصلاحات ملتی ہیں جنہیں آپ فوری طور پر درخواست دے سکتے ہیں۔

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

انڈیکس

یہ مضمون کس کے لیے ہے؟

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

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

اسٹارٹ اپ ایک مختلف ماحول کیوں ہیں۔

غلطیاں کرنے سے پہلے، آپ کو یہ سمجھنے کی ضرورت ہے کہ سٹارٹ اپ انہیں کیوں کرتے ہیں۔

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

یہ چار مخصوص پریشر پوائنٹس بناتا ہے۔

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

غلطی #1: یہ سمجھے بغیر تعینات کرنا کہ آپ کس چیز پر تعینات کر رہے ہیں۔

منظر نامہ

ایک جونیئر انجینئر سے کہا جاتا ہے کہ وہ AWS پر کمپنی کے Node.js API کو تعینات کرے۔ اگر آپ Elastic Beanstalk کے لیے ٹیوٹوریل تلاش کرتے ہیں اور اس پر عمل کرتے ہیں، تو اسے کام کرنا چاہیے۔ دو ہفتوں کے بعد، آپ کی ٹریفک بڑھ جائے گی۔ وہ اسے "ٹیوٹوریل کی طرح” بڑھانے کا ارادہ رکھتے ہیں۔ ایپلیکیشن کریش ہو جاتی ہے۔ وہ اسے ڈیبگ نہیں کر سکے کیونکہ وہ نہیں سمجھتے تھے کہ تعیناتی اصل میں کیا کرتی ہے۔

کاروباری اثر

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

ٹھیک کرتا ہے۔

پیداواری ماحول میں تعینات کرنے سے پہلے، آپ کو تحریری طور پر درج ذیل پانچ سوالات کا جواب دینے کے قابل ہونا چاہیے:

میرا کوڈ کس قسم کی کمپیوٹ پر چل رہا ہے؟ (EC2، Lambda، Fargate، کنٹینرز؟)
نیا ورژن پچھلے ورژن کی جگہ کیسے لے گا؟ (رولنگ؟ بلیو/سبز؟ سب ایک ساتھ؟)
ترکیب اور راز کہاں سے آتے ہیں؟ (SSM؟ راز مینیجر؟ ماحولیات فائل؟)
اس پر کون سی ڈاون اسٹریم سروسز کا انحصار ہے؟ (ڈیٹا بیس کنکشن؟ دیگر API؟ کیشے؟)
اگر یہ ٹوٹ جاتا ہے تو میں 5 منٹ میں واپس کیسے جا سکتا ہوں؟

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

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

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

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

اس منظم انداز نے ہمیں نئی ٹیکنالوجیز کو تیزی سے سیکھنے، تیزی سے اپنانے، اور حقیقی دنیا کے ماحول میں حل کو مؤثر طریقے سے نافذ کرنے میں مدد کی۔

غلطی 2: پیداوار کو ترقیاتی ماحول کے طور پر استعمال کرنا

منظر نامہ

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

یہ منظر آپ کی توقع سے زیادہ کثرت سے ہوتا ہے۔ استدلال ہمیشہ ایک جیسا ہوتا ہے۔ "اس میں صرف ایک منٹ لگتا ہے۔”

کاروباری اثر

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

ٹھیک کرتا ہے۔

آپ کو کم از کم تین الگ الگ ماحول کی ضرورت ہوگی، مثالی طور پر تین الگ الگ AWS اکاؤنٹس۔

ماحول	مقصد	رسائی کی سطح
ڈویلپر	چیزوں کو توڑنے کے لئے آزاد محسوس کریں۔ کوئی حقیقی ڈیٹا نہیں ہے۔	انجینئرز کو وسیع رسائی حاصل ہے۔
ڈرامہ کاری	پیداوار کا آئینہ۔ حتمی تصدیق۔	رسائی کنٹرول
پیداوار	حقیقی گاہکوں. اصلی ڈیٹا۔	MFA کی ضرورت ہے۔ کوئی دستی تعیناتی نہیں ہے۔

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

بنیادی ڈھانچہ بطور کوڈ (Terraform یا CloudFormation) کم مہنگا ہے کیونکہ آپ کنفیگریشن کو ایک بار لکھ سکتے ہیں اور مختلف متغیر فائلوں کا استعمال کرتے ہوئے اسے تین بار لاگو کر سکتے ہیں۔

# terraform/environments/prod/main.tf
module "app" {
  source      = "../../modules/app"
  environment = "production"
  instance_type = "t3.medium"
  db_instance_class = "db.t3.medium"
  multi_az          = true
}

# terraform/environments/staging/main.tf
module "app" {
  source      = "../../modules/app"
  environment = "staging"
  instance_type = "t3.small"
  db_instance_class = "db.t3.small"
  multi_az          = false
}

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

غلطی 3: ہارڈ کوڈنگ راز اور اسناد

منظر نامہ

ایک نیا انجینئر اسٹارٹ اپ میں شامل ہوتا ہے اور ذخیرہ کو کلون کرتا ہے۔ اس میں وہ .env Git سے وابستہ ایک فائل جس میں آپ کے پروڈکشن ڈیٹا بیس کا پاس ورڈ، سٹرائپ سیکرٹ کلید، اور ایڈمنسٹریٹر کے مراعات کے ساتھ AWS رسائی کلید شامل ہے۔ مخزن 6 ماہ سے عوامی ہے۔

GitHub کی خودکار خفیہ بازیافت نہیں چلی کیونکہ راز اندرونی تھا۔ .env آپ کے کوڈ میں غیر مقامی فائلیں۔ اسناد درست اور فعال طور پر کم از کم 6 ماہ کے لیے استعمال کی گئی ہیں۔

کاروباری اثر

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

کریپٹو کرنسی کان کنی کے کام کا بوجھ راتوں رات کلاؤڈ بلوں میں ہزاروں ڈالر پیدا کرتا ہے
تمام S3 بالٹیوں سے گاہک کے ڈیٹا کا مکمل اخراج
استحقاق میں اضافہ: حملہ آور ایک نیا ایڈمنسٹریٹر بناتا ہے اور آپ کے اکاؤنٹ کو لاک کر دیتا ہے۔
AWS اکاؤنٹ معطل تحقیقات زیر التواء

GitHub کی سالانہ سیکورٹی رپورٹ کے مطابق، ہر سال لاکھوں راز عوامی ذخیروں کے سامنے آتے ہیں۔ سمجھوتہ شدہ کلاؤڈ اسناد کا پتہ لگانے کا اوسط وقت 197 دن ہے۔

ٹھیک کرتا ہے۔

مرحلہ 1: گٹ کے رازوں کا ارتکاب نہ کریں۔ یہ عارضی نہیں ہے۔ شاخوں میں نہیں۔ یہ میرے ذاتی ذخیرے میں نہیں ہے۔

مرحلہ 2: شامل کریں۔ .gitignore پہلی فائل بنانے سے پہلے۔ چیک ان .gitignore کسی بھی کوڈ سے پہلے پہلی لائن کا استعمال کریں۔ .env فائل موجود ہے۔

# .gitignore
.env
.env.*
*.pem
*.key
secrets/

مرحلہ 3: تمام پروڈکشن رازوں کے لیے AWS سیکرٹس مینیجر یا SSM پیرامیٹر اسٹور کا استعمال کریں۔ ایپلیکیشن رن ٹائم کے وقت راز کو پڑھتی ہے۔

# Python example — fetch secret at runtime, never at build time
import boto3
import json
 
def get_secret(secret_name: str, region: str = "us-east-1") -> dict:
    client = boto3.client("secretsmanager", region_name=region)
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response["SecretString"])
 
# Usage
db_config = get_secret("prod/myapp/database")
DATABASE_URL = db_config["connection_string"]

مرحلہ 4: اپنے موجودہ ذخیرہ کو فوری طور پر اسکین کریں۔ ہو سکتا ہے آپ کو پہلے ہی کوئی مسئلہ ہو۔

# Install trufflehog to scan for exposed secrets in your repo history
pip install trufflehog
 
# Scan the entire commit history of your repository
trufflehog git file://.
 
# Or scan a remote GitHub repo
trufflehog github --repo https://github.com/your-org/your-repo

مرحلہ 5: مستقبل کے واقعات کو روکنے کے لیے ایک پری کمٹ ہک شامل کریں۔

pip install pre-commit

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/awslabs/git-secrets
    rev: master
    hooks:
      - id: git-secrets
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets

pre-commit install
# Now the hook runs before every commit and blocks detected secrets

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

غلطی 4: اوور انجینئرنگ ایک ایسا مسئلہ جو ابھی تک حل نہیں ہوا ہے۔

منظر نامہ

200 صارفین کے ساتھ پانچ افراد کے اسٹارٹ اپ نے Kubernetes پر ایک مائیکرو سروسز آرکیٹیکچر بنانے کا فیصلہ کیا کیونکہ "Netflix اسے استعمال کرتا ہے۔” وہ Kubernetes، Istio سروس میش، ArgoCD، Vault، Prometheus، اور Grafana کو ترتیب دینے میں تین ماہ گزارتے ہیں۔ ان کی مصنوعات نے تین مہینوں میں کوئی نئی خصوصیات جاری نہیں کیں۔ ایک واحد EC2 مثال پر ہمارے یک سنگی حریف نے اسی مدت میں 12 نئی خصوصیات جاری کیں۔

کاروباری اثر

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

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

ٹھیک کرتا ہے۔

اپنے بنیادی ڈھانچے کو حقیقی دنیا کے اقدامات کے ساتھ سیدھ کریں۔

پیمانہ	صحیح بنیادی ڈھانچہ	لاگت کی حد
1 سے 1,000 صارفین	سنگل EC2 + RDS + Nginx ریورس پراکسی	$20~50/ماہ
1,000 سے 50,000 صارفین	آٹو اسکیلنگ گروپ، RDS ملٹی-AZ، ALB، بنیادی CI/CD	$200-500/ماہ
50,000 سے 500,000 صارفین	ای سی ایس فارگیٹ، آر ڈی ایس ریڈ ریپلیکس، ایلسٹی کیچ، مکمل مشاہدہ	$1K-5K/مہینہ
500,000+ صارفین	ملٹی ریجن، منظم Kubernetes، وقف SRE	$10,000+/مہینہ

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

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

اگر ممکن ہو تو، منظم خدمات کا استعمال کریں، جیسے کہ خود میزبان پوسٹگریس کے بجائے RDS، خود سے منظم Kubernetes کے بجائے Fargate، اور خود میزبان Redis کے بجائے ElastiCache۔ منظم خدمات آپ کی ٹیم کو بنیادی ڈھانچے کے بجائے مصنوعات پر توجہ مرکوز کرنے کی اجازت دیتی ہیں۔

غلطی 5: کوئی پری لانچ آبزرویبلٹی نہیں۔

منظر نامہ

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

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

کاروباری اثر

کوئی مشاہدہ نہیں:

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

ٹھیک کرتا ہے۔

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

چھپا: درخواست مکمل کرنے میں لگنے والا وقت (p50, p95, p99)
ٹریفک: سسٹم کی طرف سے کارروائی کی گئی فی سیکنڈ درخواستوں کی تعداد
غلطی: ناکام درخواست کی شرح (5xx جوابات فی منٹ)
سنترپتی: سسٹم اپنی حدود سے کتنا قریب ہے (سی پی یو، میموری، کنکشن پول)

ذیل میں AWS CLI کا استعمال کرتے ہوئے ایک کم سے کم CloudWatch الارم سیٹ اپ ہے۔

# Alert when error rate exceeds 1% for 5 consecutive minutes

aws cloudwatch put-metric-alarm 
  --alarm-name "high-error-rate-production" 
  --alarm-description "Error rate exceeded 1% for 5 minutes" 
  --metric-name "5XXError" 
  --namespace "AWS/ApplicationELB" 
  --statistic "Average" 
  --period 60 
  --evaluation-periods 5 
  --threshold 0.01 
  --comparison-operator "GreaterThanOrEqualToThreshold" 
  --alarm-actions "arn:aws:sns:us-east-1:123456789:pagerduty-production" 
  --dimensions Name=LoadBalancer,Value=app/my-alb/1234567890abcdef

تمام درخواستیں بھی /health واپسی کا اختتامی نقطہ 200 OK صحت مند ہونے پر:

# FastAPI example

from fastapi import FastAPI
from sqlalchemy import text
 
app = FastAPI()
 
@app.get("/health")
async def health_check():
    # Check database connectivity
    try:
        db.execute(text("SELECT 1"))
        db_status = "healthy"
    except Exception:
        db_status = "unhealthy"
 
    return {
        "status": "healthy" if db_status == "healthy" else "degraded",
        "database": db_status,
        "version": os.getenv("APP_VERSION", "unknown")
    }

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

آپ یہ نہیں کہہ سکتے کہ کوئی سسٹم ڈیٹا کے بغیر اسے ثابت کرنے کے لیے کام کر رہا ہے۔ "کسی نے شکایت نہیں کی” "کچھ نہیں ٹوٹا” جیسا نہیں ہے۔

غلطی 6: سیکیورٹی کو آخری قدم سمجھنا

منظر نامہ

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

S3 بالٹیاں جو پہلے سے طے شدہ طور پر عوامی طور پر قابل رسائی ہیں۔
EC2 مثال کے ساتھ پورٹ 22 کھلا ہے۔ 0.0.0.0/0
IAM صارف AdministratorAccess پوری ٹیم کے لیے
باقی ڈیٹا بیس پر کوئی خفیہ کاری نہیں ہے۔
ماحولیاتی متغیرات میں ہارڈ کوڈ کردہ JWT رازوں کا آڈٹ ناکام ہو جاتا ہے۔ $120,000 مالیت کے کارپوریٹ سودے ہر سال گرتے ہیں۔ اس مسئلے کو حل کرنے میں انجینئرنگ کا چار ہفتے کا وقت لگتا ہے۔

کاروباری اثر

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

ٹھیک کرتا ہے۔

آپ کے پروڈکشن کوڈ کی پہلی لائن جاری ہونے سے پہلے ان چھ حفاظتی کنٹرولز کا اطلاق کریں۔

1. کم سے کم استحقاق کا اصول، جہاں IAM کے تمام کرداروں کو صرف وہی ملتا ہے جس کی انہیں ضرورت ہے:

AWS میں سیکیورٹی کی سب سے عام غلطیوں میں سے ایک کردار کو سہولت کے مطابق ضرورت سے زیادہ اجازت دینا ہے (s3:*) یا اس بارے میں غیر یقینی صورتحال جو خدمت کو درکار ہے۔ یہ غیر ضروری خطرہ پیدا کرتا ہے۔ اگر کسی کردار سے سمجھوتہ کیا جاتا ہے، تو حملہ آور آپ کی دی گئی تمام اجازتوں کا وارث ہوگا۔

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

اگر آپ کی ایپ کسی مخصوص S3 بالٹی سے فائلیں اپ لوڈ اور پڑھتی ہے، تو پالیسی کو بالکل یہ بیان کرنا چاہیے:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    }
  ]
}

توجہ فرمائیں Resource رینج یہ ہے: my-app-uploads/* تمام S3 بالٹیاں نہیں۔ اور Action فہرست کا احاطہ صرف GetObject اور PutObject ~ نہیں DeleteObjectنہیں s3:*. اگر سروس سے سمجھوتہ کیا جاتا ہے، تو حملہ آور اس بالٹی کو پڑھ اور لکھ سکتا ہے۔ بس۔ آپ کا باقی اکاؤنٹ وہی رہے گا۔

2. تمام S3 عوامی رسائی کو بطور ڈیفالٹ مسدود کریں۔

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

سب سے محفوظ طریقہ اکاؤنٹ کی سطح پر "عوامی رسائی کو مسدود کریں” کی ترتیب کو فعال کرنا ہے۔ یہ دیگر تمام ترتیبات کو اوور رائیڈ کر دیتا ہے اور آپ کی بالٹی کو عوامی ہونے سے روکتا ہے اگر کوئی یہ کرنے کی کوشش کرتا ہے:

aws s3api put-public-access-block 
  --bucket my-app-bucket 
  --public-access-block-configuration 
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

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

3. انٹرنیٹ پر SSH نہ کھولیں، اس کے بجائے AWS سسٹمز مینیجر سیشن مینیجر استعمال کریں۔

پورٹ 22 کھلا ہے۔ 0.0.0.0/0 یہ ایک حملے کی سطح ہے جو فی الحال ہزاروں AWS مثالوں پر موجود ہے۔ بروٹ فورس بوٹس کھلی SSH پورٹس کے لیے انٹرنیٹ کو مسلسل اسکین کرتے ہیں۔ یہاں تک کہ اگر آپ کے پاس مضبوط کلیدیں ہیں، کوئی نمائش ضروری نہیں ہے کیونکہ AWS ایک بہتر متبادل فراہم کرتا ہے۔

AWS سسٹمز مینیجر سیشن مینیجر آپ کے سیکیورٹی گروپ میں ایک بھی ان باؤنڈ پورٹ کھولے بغیر تمام EC2 مثالوں تک مکمل شیل رسائی فراہم کرتا ہے۔ اسکین کرنے کے لیے کوئی بندرگاہیں نہیں ہیں، حملہ کرنے کے لیے کوئی بندرگاہیں نہیں ہیں، اور تمام سیشنز خود بخود CloudTrail میں ریکارڈ ہو جاتے ہیں۔

# Start a session on an EC2 instance without port 22 open
aws ssm start-session --target i-0123456789abcdef0

سیشن مینیجر کو استعمال کرنے کے لیے، آپ کو اپنے EC2 مثال پر SSM ایجنٹ انسٹال ہونا چاہیے (یہ Amazon Linux 2 اور Ubuntu 20.04+ میں بطور ڈیفالٹ شامل ہے)۔ AmazonSSMManagedInstanceCore پالیسی منسلک ہے۔ سیٹ اپ مکمل ہونے کے بعد، آپ اپنے سیکیورٹی گروپ میں پورٹ 22 کو مکمل طور پر بند کر سکتے ہیں۔

4. تمام IAM صارفین کے لیے MFA کو فعال کریں اور اسے پالیسی کے ذریعے نافذ کریں۔

ایم ایف اے کے بغیر ایک لیک IAM صارف نام اور پاس ورڈ ایک مکمل طور پر سمجھوتہ شدہ اکاؤنٹ ہے۔ کثیر عنصر کی توثیق اسناد کی چوری کے خلاف سب سے مؤثر کنٹرول ہے اور اسے فعال کرنے کے لیے کچھ بھی خرچ نہیں ہوتا ہے۔

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

AWS دستاویزات MFA کے بغیر مکمل انکار کی پالیسی فراہم کرتی ہیں اور اسے آپ کے اکاؤنٹ میں کسی بھی IAM صارف یا گروپ سے منسلک کرتی ہے۔ یہ ایک بار کی ترتیب ہے جو مستقل طور پر آپ کے اکاؤنٹ کے سیکیورٹی معیارات کو بڑھاتی ہے۔

5. تمام علاقوں میں CloudTrail کو فعال کریں۔

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

CloudTrail ہر AWS API کال کو ریکارڈ کرتا ہے: کس کے ذریعے، کس IP سے، کب، اور کس جواب کے ساتھ۔ اسے تمام خطوں میں فعال کریں تاکہ یہ یقینی بنایا جا سکے کہ آپ جن علاقوں کو فعال طور پر استعمال نہیں کر رہے ہیں ان میں بھی سرگرمی کیپچر کی گئی ہے۔

aws cloudtrail create-trail 
  --name production-audit-trail 
  --s3-bucket-name my-cloudtrail-logs 
  --is-multi-region-trail 
  --enable-log-file-validation

کہ --enable-log-file-validation پرچم ہر لاگ کے لیے ایک ڈائجسٹ فائل بناتا ہے جو آپ کو تصدیق کرنے کی اجازت دیتا ہے کہ لاگ کے ساتھ چھیڑ چھاڑ نہیں کی گئی ہے۔ اگر آپ کو حفاظتی تفتیش یا تعمیل آڈٹ میں ان لاگز کو استعمال کرنے کی ضرورت ہو تو یہ اہم ہے۔ جب یہ چلایا جاتا ہے، ہر بار AssumeRoleہر DeleteBucketاور ہر RunInstances کالز مستقل طور پر آپ کے اکاؤنٹ پر ریکارڈ کی جائیں گی۔

6. پہلے دن سے AWS سیکیورٹی حب چلائیں۔

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

اسے فعال کرنے کے لیے ایک کمانڈ کی ضرورت ہے۔

aws securityhub enable-security-hub

منٹوں کے اندر، سیکیورٹی ہب آپ کے اکاؤنٹ کو تعمیل سکور اور ترجیحی نتائج کی فہرست فراہم کرتا ہے۔ نتائج اس بات کی نشاندہی کر سکتے ہیں کہ آپ کے سیکیورٹی گروپ میں پورٹ 22 دنیا کے لیے کھلا ہے، آپ کی S3 بالٹی پر لاگنگ غیر فعال ہے، یا یہ کہ آپ کے روٹ اکاؤنٹ کی اسناد حال ہی میں استعمال ہوئی ہیں۔ ہر تلاش میں متاثرہ وسائل اور ریزولوشن گائیڈ شامل ہوتا ہے۔

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

غلطی 7: پیداوار میں دستی تعیناتی۔

منظر نامہ

سٹارٹ اپ کی تعیناتی کا عمل اس کے نوشن پیج پر درج ہے، جو چار ماہ پرانا ہے۔ اس میں سرور سے ایک SSH کنکشن شامل ہے۔ git pullچل رہا ہے npm installPM2 عمل کو دوبارہ شروع کریں۔ ہر انجینئر اسے قدرے مختلف طریقے سے کرتا ہے۔ ایک انجینئر جو رات گئے ریلیز میں جلدی کر رہا تھا اسے چھوڑ دیا۔ npm install. ایپلیکیشن کریش ہونے لگتی ہے کیونکہ نئی انحصار غائب ہیں۔

کاروباری اثر

دستی تعیناتی کے عمل فطری طور پر ناقابل اعتبار ہیں۔ دباؤ کے تحت انسان قدموں کو چھوڑ دیتے ہیں، غلط ترتیب سے اقدامات کرتے ہیں، اور طریقہ کار کو مختلف طریقے سے یاد رکھتے ہیں۔ پیداوار کی تعیناتی کے عمل میں ہر دستی قدم ایک منصوبہ بند حادثہ ہے جو صحیح دباؤ والے لمحے کا انتظار کر رہا ہے۔

ٹھیک کرتا ہے۔

اگر آپ ایک سے زیادہ بار دستی طور پر تعیناتی کا مرحلہ انجام دیتے ہیں، تو آپ کو اسے خودکار کرنا چاہیے۔ ذیل میں ECS Fargate سروس کے لیے ایک کم سے کم لیکن مکمل GitHub ایکشنز کی تعیناتی کا ورک فلو ہے۔

# .github/workflows/deploy.yml
name: Deploy to Production
 
on:
  push:
    branches:
      - main
 
permissions:
  id-token: write   # Required for OIDC authentication with AWS
  contents: read
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
 
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
 
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
          aws-region: us-east-1
 
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
 
      - name: Build and push Docker image
        id: build
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t (ECR_REGISTRY/my-app:)IMAGE_TAG .
          docker push (ECR_REGISTRY/my-app:)IMAGE_TAG
          echo "image=(ECR_REGISTRY/my-app:)IMAGE_TAG" >> $GITHUB_OUTPUT
 
      - name: Deploy to Amazon ECS
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: task-definition.json
          service: my-app-service
          cluster: production
          wait-for-service-stability: true

نوٹس wait-for-service-stability: true. اس کے بغیر، ورک فلو اس وقت کامیابی کی اطلاع دے گا جب ای سی ایس کنٹینر کے صحت مند حالت میں ہونے سے پہلے ایک نئی ٹاسک تعریف کو قبول کرے گا۔ اگر آپ اسے استعمال کرتے ہیں، نئے کنٹینر کے کریش ہونے پر ورک فلو ناکام ہو جائے گا۔ میں فوراً جاننا چاہتا ہوں، ایسا کچھ نہیں جس کے بارے میں مجھے 30 منٹ بعد صارف کی رپورٹ میں پتہ چلا۔

غلطی 8: ڈیزاسٹر ریکوری پلان نہیں۔

منظر نامہ

سٹارٹ اپ کا پروڈکشن ڈیٹا بیس ملٹی AZ کنفیگریشن کے بغیر واحد RDS مثال پر چلتا ہے۔ خودکار بیک اپ فعال ہیں لیکن ان کا تجربہ نہیں کیا گیا ہے۔ مثال کی حمایت کرنے والا EBS حجم ناکام ہوجاتا ہے۔ AWS آخری سنیپ شاٹ سے نئی مثالیں فراہم کرتا ہے جو 18 گھنٹے سے زیادہ پرانا ہے۔ 18 گھنٹے کا کسٹمر ڈیٹا مستقل طور پر ضائع ہو جاتا ہے۔

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

کاروباری اثر

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

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

ٹھیک کرتا ہے۔

کسی بھی چیز کو ڈیزائن کرنے سے پہلے RTO اور RPO کی تعریف کریں۔

ریکوری ٹائم مقصد (RTO): اس نظام کے بغیر کمپنی کب تک زندہ رہ سکتی ہے؟ ادائیگیوں کے API کے لیے RTO 15 منٹ کا ہو سکتا ہے۔ اندرونی تجزیاتی ڈیش بورڈ میں 4 گھنٹے کا RTO ہوسکتا ہے۔
ریکوری پوائنٹ کا مقصد (RPO): کتنا ڈیٹا ضائع کرنا قابل قبول ہے؟ 0 کا مطلب ہے حقیقی وقت کی نقل۔ 1 گھنٹہ کا مطلب ہے کہ فی گھنٹہ اسنیپ شاٹس کافی ہیں۔ یہ براہ راست آپ کے بیک اپ فریکوئنسی اور فن تعمیر کا تعین کرتا ہے۔

تمام پروڈکشن ڈیٹا بیسز کے لیے RDS Multi-AZ کو فعال کریں۔

# Terraform
resource "aws_db_instance" "production" {
  identifier        = "prod-postgres"
  engine            = "postgres"
  engine_version    = "15.4"
  instance_class    = "db.t3.medium"
  allocated_storage = 100
 
  # Multi-AZ: automatic failover to standby in a different AZ
  # No data loss. Automatic failover in ~60-120 seconds.
  multi_az = true
 
  # Encryption at rest — non-negotiable
  storage_encrypted = true
 
  # Automated backups with 7-day retention
  backup_retention_period = 7
  backup_window           = "03:00-04:00"
 
  # Enable deletion protection in production
  deletion_protection = true
 
  tags = {
    Environment = "production"
  }
}

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

# Restore a snapshot to a test instance and verify
aws rds restore-db-instance-from-db-snapshot 
  --db-instance-identifier recovery-test 
  --db-snapshot-identifier rds:prod-postgres-2025-01-15 
  --db-instance-class db.t3.medium 
  --no-multi-az
 
# Connect and verify row counts
psql -h recovery-test.xxxx.rds.amazonaws.com -U admin -d mydb 
  -c "SELECT COUNT(*) FROM users; SELECT COUNT(*) FROM orders;"

RDS بیک اپ اور بحالی کے بارے میں سرکاری ہدایات کے لیے، AWS RDS بیک اپ اور بحال دستاویزات دیکھیں۔

غلطی 9: کوئی دستاویزات یا رن بکس نہیں۔

منظر نامہ

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

کاروباری اثر

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

ٹھیک کرتا ہے۔

انجینئرنگ ٹیموں کے لیے دستاویزات کے تین مخصوص مضمرات ہیں:

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

# Runbook: Production Database Connection Exhaustion
 
## Symptoms
- Application logs: "too many connections" errors
- 500 error rate spike on database-dependent endpoints
- pg_stat_activity shows max connections reached
 
## Diagnosis
# Check current connection count
psql -h (DB_HOST -U )DB_USER -c "SELECT COUNT(*) FROM pg_stat_activity;"
 
# See connections by application
psql -h (DB_HOST -U )DB_USER 
  -c "SELECT application_name, COUNT(*) FROM pg_stat_activity GROUP BY 1 ORDER BY 2 DESC;"

## Resolution
1. Identify and restart the service causing the connection leak
2. If immediate relief needed: kill idle connections older than 10 minutes
3. Long-term: review connection pool settings in application config

## Escalation
If unresolved in 30 minutes: page the on-call backend engineer.

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

غلطی #10: کاروبار کو سمجھے بغیر تکنیکی مسائل کو حل کرنا

منظر نامہ

شروع ہونے پر صفحات آہستہ آہستہ لوڈ ہو رہے ہیں۔ DevOps انجینئرز نے افقی پوڈ آٹو اسکیلنگ کے ساتھ Kubernetes میں ہجرت کرکے اس مسئلے کو حل کرنے کا فیصلہ کیا۔ ہجرت میں 6 ہفتے لگتے ہیں۔ اس سے صفحہ کے بوجھ میں قدرے بہتری آئے گی۔ تاہم، 80% سست روی بنیادی ڈھانچے کی تہہ سے غیر متعلق ڈیٹا بیس کے سوالات کی وجہ سے ہوئی تھی۔ ہجرت کے 6 ہفتوں میں 20% مسائل حل ہو گئے۔

کاروباری اثر

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

ٹھیک کرتا ہے۔

اپنے بنیادی ڈھانچے کے فیصلے کرنے سے پہلے ان چار سوالوں کے جواب دیں:

اصل ماپا رکاوٹیں کیا ہیں؟ کام کرنے سے پہلے اوزار استعمال کریں۔ رکاوٹیں شاذ و نادر ہی واقع ہوتی ہیں جہاں آپ ان کی توقع کرتے ہیں۔
کامیابی کیسی نظر آتی ہے اور آپ اس کی پیمائش کیسے کریں گے؟ "صفحہ تیز ہے” کی پیمائش نہیں کی جا سکتی۔ "p95 صفحہ لوڈ ٹائم 1.2 سیکنڈ سے کم رہ جاتا ہے” قابل پیمائش ہے۔
اس حل کی مجموعی قیمت کیا ہے؟ عمل درآمد کا وقت، جاری آپریشنل بوجھ، اور ٹیم سیکھنے کا وکر۔ کیا ماپا اثر اس لاگت کا جواز پیش کرتا ہے؟
کیا کوئی آسان حل 80% مسئلے کو 20% وقت میں حل کر سکتا ہے؟

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

# Check slow queries in PostgreSQL before any infrastructure changes
psql -h (DB_HOST -U )DB_USER -d $DB_NAME -c "
SELECT
  query,
  calls,
  total_exec_time / calls AS avg_ms,
  rows / calls AS avg_rows
FROM pg_stat_statements
ORDER BY avg_ms DESC
LIMIT 10;
"

10 میں سے 9 بار، سست ایپلی کیشنز میں سست سوالات، گمشدہ اشاریہ جات، یا N+1 سوالات کے مسائل ہیں، جن میں سے کسی کو بھی ٹھیک کرنے کے لیے نئی انفراسٹرکچر پرت کی ضرورت نہیں ہے۔

سسٹم سوچنے کا فریم ورک ہر DevOps انجینئر کو درکار ہے۔

مندرجہ بالا غلطیوں میں سے اکثر ایک مشترکہ بنیادی وجہ کا اشتراک کرتے ہیں. انجینئرز نے پورے نظام کے بجائے تنہائی میں ایک جزو کے بارے میں سوچا۔

نظام کے مفکرین پیداوار میں تبدیلی کرنے سے پہلے یہ چھ سوالات پوچھتے ہیں:

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

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

پیداوار کی تیاری کی چیک لسٹ

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

بنیادی ڈھانچہ

بنیادی ڈھانچے کی تعریف کوڈ (Terraform یا CloudFormation) اور Git میں کنٹرول شدہ ورژن کے طور پر کی گئی ہے۔
الگ الگ ترقی، سٹیجنگ، اور پروڈکشن کے ماحول ہیں جو الگ الگ اسناد استعمال کرتے ہیں۔
تمام پیداواری تبدیلیاں ایک خودکار CI/CD پائپ لائن سے گزرتی ہیں اور اس کے لیے دستی SSH کی تعیناتی کی ضرورت نہیں ہوتی ہے۔
آپ کوڈ سے اپنے پورے پیداواری ماحول کو دو گھنٹے سے بھی کم وقت میں دوبارہ بنا سکتے ہیں۔

سیکورٹی

گٹ ریپوزٹریز میں کوئی راز، اسناد، یا API کیز نہیں ہیں۔
پروڈکشن کے تمام راز راز مینیجر یا SSM پیرامیٹر اسٹور میں رہتے ہیں۔
IAM کے تمام کردار کم از کم استحقاق کے اصول پر عمل کرتے ہیں۔
S3 بالٹیاں بطور ڈیفالٹ عوامی رسائی سے مسدود ہیں۔
پورٹ 22 کھلا نہیں ہے۔ 0.0.0.0/0 تمام سیکورٹی گروپوں میں
CloudTrail تمام علاقوں میں فعال ہے۔
تمام IAM صارفین نے MFA کو فعال کیا ہے۔
AWS سیکیورٹی حب فعال ہے اور نتائج کا ہفتہ وار جائزہ لیا جاتا ہے۔

مشاہدہ

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

قابل اعتماد

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

دستاویزات

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

نتیجہ

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

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

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

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

گہرائی میں جانا چاہتے ہیں؟

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

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

انڈیکس

یہ مضمون کس کے لیے ہے؟

اسٹارٹ اپ ایک مختلف ماحول کیوں ہیں۔

غلطی #1: یہ سمجھے بغیر تعینات کرنا کہ آپ کس چیز پر تعینات کر رہے ہیں۔

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی 2: پیداوار کو ترقیاتی ماحول کے طور پر استعمال کرنا

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی 3: ہارڈ کوڈنگ راز اور اسناد

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی 4: اوور انجینئرنگ ایک ایسا مسئلہ جو ابھی تک حل نہیں ہوا ہے۔

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی 5: کوئی پری لانچ آبزرویبلٹی نہیں۔

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی 6: سیکیورٹی کو آخری قدم سمجھنا

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی 7: پیداوار میں دستی تعیناتی۔

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی 8: ڈیزاسٹر ریکوری پلان نہیں۔

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی 9: کوئی دستاویزات یا رن بکس نہیں۔

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

غلطی #10: کاروبار کو سمجھے بغیر تکنیکی مسائل کو حل کرنا

منظر نامہ

کاروباری اثر

ٹھیک کرتا ہے۔

سسٹم سوچنے کا فریم ورک ہر DevOps انجینئر کو درکار ہے۔

پیداوار کی تیاری کی چیک لسٹ

بنیادی ڈھانچہ

سیکورٹی

مشاہدہ

قابل اعتماد

دستاویزات

نتیجہ

گہرائی میں جانا چاہتے ہیں؟

Related Posts