حادثاتي پيداوار جي بندش، ليڪ ٿيل API ڪيز، يا ختم ٿيل ڪلائوڊ انفراسٽرڪچر¶

هر سافٽ ويئر انجنيئر، سسٽم ايڊمنسٽريٽر، ۽ ٽيڪنيڪل ريموٽ ورڪر آخرڪار پيٽ ڇڏڻ واري لمحي کي منهن ڏئي ٿو جڏهن هڪ حڪم جو مطلب آهي localhost يا staging خلاف عمل ڪري ٿو production: اڻ ترتيب ڏنل DELETE بغير a WHERE شق، الف DROP TABLE يا terraform destroy، الف git push --force جيڪو مين برانچ کي اوور رائٽ ڪري ٿو، يا عوامي ڪمٽ جنهن ۾ لائيو AWS يا Stripe secret keys شامل آهن. ڪيريئر ختم ٿيڻ واري ڊيٽا جي تباهي کان هڪ 15 منٽ جي معمولي هچڪي کي ڇا ڌار ڪري ٿو توهان جي هٿن کي فوري طور تي روڪي ٿو، اسٽوريج بلاڪ کي ختم ٿيڻ کان اڳ لکڻ جي ٽرئفڪ کي منجمد ڪرڻ، ۽ صحيح وصولي پروٽوڪول تي عمل ڪرڻ.

ھاڻي ھي ڪر¶

1. پنهنجا هٿ منجمد ڪريو ۽ جلدي نه هلو ”فيڪس“ ڪمانڊ، ڊيٽابيس سرور کي ٻيهر شروع ڪريو، يا پنهنجي ٽرمينل ونڊو بند ڪريو. توهان جو موجوده ٽرمينل اسڪرول بيڪ بفر، شيل تاريخ، ۽ مقامي .git/logs reflog ۾ صحيح ٽرانزيڪشن ٽائم اسٽيمپ شامل آهن، SHA هيشز، ۽ وسيلن جي IDs کي نقصان پهچائڻ جي ضرورت آهي. نقل ڪريو پنھنجي پوري ٽرمينل اسڪرول بيڪ کي محفوظ ٽيڪسٽ فائل ۾ پھريون.
2. ** 2 منٽن اندر پنھنجي ٽيم جي واقعن ۾ Slack/Teams چينل ۾ ھڪڙي شدت-1 (SEV-1) واقعي جو اعلان ڪريو. ** ڪڏھن به 45 منٽ خرچ نه ڪريو ڳجھي طور تي ھڪڙي ٽوٽل پروڊڪشن ڊيٽابيس کي درست ڪرڻ جي ڪوشش ڪريو جڏھن ته گراهڪ 500 غلطيون ڪري رھيا آھن ۽ خودڪار پس منظر جون نوڪريون باقي جدولن کي خراب ڪري رھيون آھن. صفحي تي ڪال ڪريو ڊيٽابيس ايڊمنسٽريٽر (DBA) يا سائيٽ ريليبلٽي انجنيئر (SRE) کي فوري طور تي.
3. جيڪڏهن توهان هڪ API چاٻي لڪي، .env فائل، يا ڪلائوڊ راز عوامي GitHub ريپو ڏانهن، سڀ کان پهريان فراهم ڪندڙ ڊيش بورڊ ۾ ڪنجي کي رد ڪريو (گٽ جي تاريخ کي ٻيهر لکڻ جي ڪوشش ڪرڻ کان اڳ). خودڪار بوٽنيٽس عوامي GitHub Firehose API کي اسڪريپ ڪري ٿو ۽ چوري ٿيل AWS، OpenAI، Stripe، ۽ GCP چاٻين کي انجام ڏئي ٿو ** 3 کان 5 سيڪنڊن جي اندر. git push. ٻي ڪمٽ ۾ فائل کي حذف ڪرڻ يا زور ڀرڻ سان نه روڪيو حملو ڪندڙ جيڪو اڳ ۾ ئي ڪلون ڪري چڪو آهي.
4. ** جيڪڏهن توهان هڪ حادثاتي طور تي ڀڄي ويا آهيو DELETE, UPDATE، يا DROP پروڊڪشن ڊيٽابيس تي، ايپليڪيشن WRITE ٽرئفڪ کي فوري طور تي ڪٽيو.** ويب ايپليڪيشن کي مينٽيننس موڊ ۾ وجھو يا ايپ استعمال ڪندڙ جي لکڻ جي اجازتن کي رد ڪريو ته جيئن نيون ايندڙ ٽرانزيڪشنز غير محفوظ ٿيل ڊيڊ ٽوپلز کي اوور رائٽ نه ڪن يا پوائنٽ-ان-ٽائم ريڪوري (PITR) کي پيچيده نه ڪن.
5. ** ڪڏهن به نه هلو VACUUM, OPTIMIZE TABLE، يا git gc --prune=now هڪ حادثاتي حذف ٿيڻ کان پوءِ.** ٻئي تعلقي ڊيٽابيس (PostgreSQL MVCC, MySQL InnoDB) ۽ Git ڊليٽ ٿيل قطارون ۽ يتيم ڪميٽ ڊسڪ تي برقرار رکندا آهن جيستائين ڪو گاربيج ڪليڪشن/ويڪيوم پاس جسماني طور تي صفحن کي ٻيهر دعويٰ نه ڪري.
6. ** جيڪڏهن هڪ terraform destroy يا ڪلائوڊ ڊيليشن اسڪرپٽ اڃا تائين توهان جي ٽرمينل ۾ هلي رهي آهي، پريس ڪريو Ctrl + C هڪ ڀيرو (ٻه ڀيرا نه) يا IAM سيشن ٽوڪن کي ماريو.** دٻايو Ctrl + C هڪ دفعو هڪ شاندار رياست فلش کي متحرڪ ڪري ٿو، تنهنڪري Terraform جزوي کي بچائيندو آهي .tfstate جيڪي اڃا تائين موجود آهن؛ دٻائڻ Ctrl + C ٻه ڀيرا هڪ بي رحم خاتمي کي مجبور ڪري ٿو جيڪو خراب ڪري سگهي ٿو يا توهان جي مقامي رياست جي فائل کي وڃائي سگھي ٿو.

ايمرجنسي ٽريج ورڪ فلو: ڊيٽابيس ڊراپ، گٽ فورس-پش، يا ڳجهي ليک¶

هن فيصلي واري وڻ جي پيروي ڪريو توهان جي پهرين 5 منٽن جي ٽيڪنيڪل ڪنٽينمينٽ کي روٽ ڪرڻ لاءِ.

flowchart TD
    A["پيداوار انجنيئرنگ ايمرجنسي"] --> B{"ڪهڙي ناڪامي صرف واقع ٿي؟"}
    B -->|"حادثاتي SQL DROP / DELETE / UPDATE Prod ۾"| C["اسٽاپ ايپ لکن / سار سنڀال موڊ؛ VACUUM نه هلايو"]
    B -->|"ليڪ ٿيل API Key / .env / Git ۾ پرائيويٽ ڪي"| D["60 سيڪنڊن اندر ڪلائوڊ ڊيش بورڊ ۾ راز کي رد ڪريو ۽ گھمايو"]
    B -->|"حادثاتي گٽ پش --force / ڊليٽ ٿيل برانچ"| E["مقامي طور تي گٽ ريفلاگ کي هلائڻ؛ ڪاپي آخري سٺي ڪميٽ SHA"]
    B -->|"حادثاتي ٽرافارم تباهه / ختم ٿيل S3 يا VM"| F["IAM سيشن کي ماريو يا پريس ڪريو Ctrl+C هڪ ڀيرو؛ محفوظ ڪريو .tfstate"]
    C --> G["Record Exact UTC Timestamp; ٽرگر ڪلائوڊ PITR ڪلون يا بنلاگ فليش بيڪ"]
    D --> H["CloudTrail / Access Logs جي آڊٽ ڪريو غير مجاز اسپن اپ لاءِ؛ گٽ-فلٽر-ريپو سان ريپو صاف ڪريو"]
    E --> I["GitHub واقعن / ريفلاگ ۽ بحال برانچ کي گيٽ پش سان سوال ڪريو --force-with-lease"]
    F --> J["چيڪ ڪريو S3 ورزننگ ڊيليٽ مارڪرز، اي بي ايس سنيپ شاٽ، يا ڪلائوڊ ريسائيڪل بن"]

حصو 1: حادثاتي پيداوار ڊيٽابيس DROP, TRUNCATE، يا DELETE بغير WHERE¶

جڏهن هڪ تباهي وارو SQL سوال هڪ لائيو پروڊڪشن ڊيٽابيس کي ماريندو آهي، صحيح وصولي جو طريقو منحصر هوندو آهي توهان جي ڊيٽابيس انجڻ (PostgreSQL، MySQL/MariaDB، SQL Server، MongoDB، يا DynamoDB) ۽ ڇا بيان هڪ DML (DELETE / UPDATE) يا ** ڊي ڊي ايل (DROP TABLE / TRUNCATE)** آپريشن.

قدم 1: صحيح UTC ٽائم اسٽيمپ کي رڪارڊ ڪريو سيڪنڊ تائين¶

ڪنهن به بيڪ اپ ڪنسول کي ڇڪڻ کان اڳ، لکو ** صحيح موجوده UTC وقت** (date -u Linux/macOS ٽرمينل ۾، يا SELECT NOW(); SQL پرامپٽ جي اندر) ۽ صحيح سيڪنڊ جو اندازو لڳايو صرف کان اڳ توهان جي تباهي واري سوال تي عمل ڪرڻ شروع ڪيو. پوائنٽ-ان-ٽائم ريڪوري (PITR) ڊيٽابيس جي Write-Ahead Log کي ريپلي ڪندي ڪم ڪري ٿو (WAL PostgreSQL ۾) يا بائنري لاگ (binlog MySQL ۾) تائين T_minus_1_second توهان جي خراب سوال جي اچڻ کان اڳ.

مرحلا 2: پس منظر جون نوڪريون ۽ ايپليڪيشن لکڻ بند ڪريو (ايم وي سي سي ٽوپلز کي محفوظ ڪريو)¶

PostgreSQL ۾، عمل ڪرڻ DELETE FROM users; يا UPDATE orders SET status = 'cancelled'; ڇا نه اصل ۾ ڊسڪ تي ٽيبل فائل مان ڊيٽا جي هڪ بائيٽ کي ختم ڪري ٿو. ڇاڪاڻ ته PostgreSQL استعمال ڪري ٿو ملٽي ورزن ڪنورينس ڪنٽرول (MVCC)، a DELETE صرف ترتيب ڏئي ٿو xmax ٽرانزيڪشن ID هيڊر هر قطار جي ٽوپل تي ان کي نشان لڳڻ لاءِ ان کي پوشيده طور تي مستقبل جي سوالن لاءِ، مڪمل قطار ڊيٽا کي بيٺو رکي base/ هيپ فائل تيستائين آٽوواڪيوم سان گڏ اچي ٿو جڳهه کي ٻيهر استعمال جي قابل نشان ڪرڻ لاءِ.

• جيڪڏهن توهان خود ميزباني ڪيل يا VM PostgreSQL تي آهيو ۽ توهان وٽ تازو بيڪ اپ ناهي: فوري طور تي ڳنڍيو جيئن superuser ۽ ان ٽيبل تي آٽو ويڪيوم کي بند ڪريو (ALTER TABLE table_name SET (autovacuum_enabled = false);)، يا PostgreSQL سروس کي روڪيو ۽ خام بلاڪ-سطح فائل سسٽم سنيپ شاٽ وٺو (LVM / EBS اسنيپ شاٽ) جو /var/lib/postgresql/data ڊاريڪٽري. خاص PostgreSQL فارنزڪ ايڪسٽينشن (pg_dirtyread) پڙهي ۽ بحال ڪري سگھي ٿو 100 سيڪڙو حذف ٿيل يا اڳ-اپڊيٽ قطارون سڌو سنئون بغير خالي ٿيل هيپ ٽيبل مان منٽن ۾.

انجڻ ۽ ڪلائوڊ پليٽ فارم ذريعي ڊيٽابيس جي وصولي ميٽرڪس¶

حصو 2: ليڪ ٿيل API چابيون، .env راز، يا خانگي چابيون Git سان وابسته آهن¶

جيڪڏهن توهان غلطيء سان ڪيو آهي .env فائل، هڪ id_rsa SSH چيڪ، هڪ فائر بيس/GCP سروس اڪائونٽ JSON فائل، هڪ پٽي ڳجهي چيڪ (sk_live_...)، يا AWS AKIA... گِٽ تائين رسائي ڪنجي، هن صحيح ٻن مرحلن جي ترتيب جي پيروي ڪريو: مرحلو A (ڪلائوڊ ۾ ڪنجي کي ماريو) پهريون، ۽ مرحلو بي (گٽ جي ذخيري کي ڇڪايو) ٻيو.

مرحلو A: فوري طور تي 60-سيڪنڊ ڪلائوڊ سندي ڪنٽينمينٽ (اهو پهرين ڪريو)¶

1. AWS (AKIA... رسائي ڪيئي ID + ڳجهي رسائي ڪي)¶

جڏهن بوٽس GitHub مان AWS ڪيچ چوري ڪندا آهن، انهن جي خودڪار اسڪرپٽ توهان جي اڪائونٽ کي 10 سيڪنڊن اندر وڌ ۾ وڌ GPU EC2 مثالن کي اسپن ڪرڻ لاءِ هٽائي ٿو (p4d.24xlarge / g5.48xlarge) سڀني 30+ عالمي AWS علائقن ۾ (بشمول آپٽ-ان علائقا جهڙوڪ جڪارتا، اوساڪا، ۽ مڊل ايسٽ) مائنس ڪرپٽو ڪرنسي لاءِ، يا ان سان گڏ هڪ پٺتي پيل IAM استعمال ڪندڙ ٺاهي ٿو. AdministratorAccess ان کان اڳ جو توھان اصل چيڪ کي ختم ڪريو.

1. ليڪ ٿيل رسائي ڪيئي کي فوري طور تي غير فعال ۽ حذف ڪريو:
   • کوليو AWS ڪنسول -> IAM -> استعمال ڪندڙ -> [Compromised User] -> Security credentials -> Access key -> ڪلڪ ڪريو Deactivate، پوءِ Delete (يا CLI ذريعي: aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name MyUser).
2. ** واضع ڳنڍيو DenyAll عارضي غير جانبدار ڪرڻ جي پاليسي aws sts سيشن ٽوڪن:**
   • ** نازڪ ٽريپ: ** ايستائين جو توهان کي حذف ڪرڻ کان پوءِ AKIA... IAM رسائي چاٻي، جيڪڏهن حملو ڪندڙ اڳ ۾ ئي سڏيو آهي sts:GetSessionToken يا sts:AssumeRole پهرين 30 سيڪنڊن دوران، انهن جي عارضي ASIA... سيشن ٽوڪن 1 کان 12 ڪلاڪن تائين صحيح رهي ٿو جيستائين توهان هڪ واضح ان لائن ** انڪار** پاليسي جوڙيو (جهڙوڪ AWSCompromisedKeyQuarantineV2 يا موجوده ٽائم اسٽيمپ کان اڳ جاري ڪيل ٽوڪن لاءِ رد-سڀ پاليسي) استعمال ڪندڙ يا ڪردار کي.
3. آڊيٽ ڪريو AWS CloudTrail پٺئين دروازي لاءِ:
   • کوليو AWS CloudTrail -> واقعي جي تاريخ ۽ فلٽر ڪريو سمجھوتي ٿيل Access Key ID يا صارف جو نالو گذريل 2 ڪلاڪن دوران.
   • انهن 5 مسلسل ڪالن لاء خاص طور تي چيڪ ڪريو: CreateUser, CreateAccessKey, AttachUserPolicy, AssumeRole، ۽ RunInstances. چيڪ ڪريو AWS Cost Explorer ۽ EC2 Global View سڀني علائقن ۾ ڪنهن به بدمعاشي کي ختم ڪرڻ لاءِ، ۽ هڪ فوري AWS سپورٽ ڪيس کوليو (اڪائونٽ ۽ بلنگ -> سمجهوتو ٿيل کاتو). AWS باقاعده طور تي دوکي جي حسابن جي بلن کي معاف ڪري ٿو جڏهن توهان هڪ اهم ليک جي رپورٽ ڪريو ۽ مثالن کي فوري طور تي ختم ڪريو.

2. پٽي (sk_live_...)، OpenAI (sk-...)، SendGrid، Twilio، ۽ Slack Tokens¶

• پٽي: ڏانهن وڃو ** ڊولپرز -> API ڪيز -> معياري ڪيز / پابنديون چابيون -> ٽن نقطن تي ڪلڪ ڪريو (...) -> رول ڪي **. چونڊيو "هاڻي ختم ٿيو" (يا صرف 1-ڪلاڪ فضل واري ونڊو سيٽ ڪريو جيڪڏهن توهان فعال طور تي نئين ڪيئي کي پنهنجي پيداوار جي ماحول جي متغيرن ۾ هن وقت ترتيب ڏئي رهيا آهيو).
• OpenAI / Anthropic: API Keys جي ڊيش بورڊ تي وڃو ۽ ڪلڪ ڪريو رد ڪريو/خارج ڪريو فوري طور تي پوءِ خودڪار پراڪسي اسڪراپر هزارين ڊالرن جي LLM ٽوڪن ڪريڊٽ کي منٽن ۾ خارج نه ڪري سگھندا.
• GitHub Personal Access Tokens (PATs)، Fine-grained Tokens، and Deploy Keys: ڏانھن وڃو GitHub سيٽنگون -> ڊولپر سيٽنگون -> ذاتي رسائي ٽوڪن ۽ ڪلڪ ڪريو خارج ڪريو/رد ڪريو ليڪ ٿيل ٽوڪن تي، پوءِ چيڪ ڪريو پنھنجي تنظيم جي ** آڊٽ لاگSettings -> Audit log) لاء repo.clone, repo.access، يا ايڪسپوزر ونڊو دوران غير مجاز ويب هِڪ ٺاھڻ.
• ** ڊيٽابيس ڪنيڪشن اسٽرنگ (DATABASE_URL / postgres:// / mongodb+srv://) ۽ Redis URLs:** ڊيٽابيس انجڻ جي اندر ڊيٽابيس استعمال ڪندڙ جو پاسورڊ تبديل ڪريو (ALTER USER app_user WITH PASSWORD 'new_random_secret';)، ۽ پوءِ ** ختم ڪريو سڀ في الحال کليل TCP ڪنيڪشن** جن جو تعلق پراڻن سندن سان (SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'app_user' AND pid <> pg_backend_pid(); PostgreSQL ۾)، ڇاڪاڻ ته PostgreSQL يا MySQL ۾ ڊيٽابيس پاسورڊ تبديل ڪرڻ صرف نئين لاگ ان کي بلاڪ ڪري ٿو ۽ حملو ڪندڙ جي اڳ ۾ ئي کليل ڪنيڪشن کي لائيو ڇڏي ٿو جيستائين لات نه ڪيو وڃي.

مرحلو B: گٽ جي تاريخ مان راز کي صاف ڪرڻ (git filter-repo ۽ GitHub ڪيش ڪڍڻ)¶

هڪ دفعو ليڪ ٿيل ڪيچي مئل آهي ۽ پيداوار ۾ گھمائي وئي آهي، پنهنجي گٽ ڪمٽ جي تاريخ مان ڳجهي تار کي صاف ڪريو ته جيئن سيڪيورٽي اسڪينر خبردار ڪرڻ بند ڪن:

1. ** استعمال ڪندي مخزن جي تاريخ کي ٻيهر لکو git filter-repo (يا BFG ريپو-ڪلينر):**
   • پنھنجي مخزن جو ھڪڙو نئون بيئر آئيني ڪلون وٺو ۽ لڪايل فائل کي هٽايو (مثال طور، .env) سڀني شاخن ۽ ٽيگ جي وچ ۾ هر تاريخي وابستگي کان:

     # 1. Remove a specific file (.env) from all commits in history:
     git filter-repo --invert-paths --path .env
     
     # OR 2. Replace a specific secret string with ***REMOVED*** everywhere:
     echo "sk_live_YOUR_SECRET_STRING==>***REMOVED***" > replacements.txt
     git filter-repo --replace-text replacements.txt
     

2. زور زور سان صاف ڪيل تاريخ کي دٻايو ۽ ڪيش ڪيل GitHub پل جي درخواست کي صاف ڪريو / نظرن جو عزم ڪريو:
   • صاف ڪيل تاريخ کي اصل ڏانھن واپس آڻيو (git push origin --force --all ۽ git push origin --force --tags).
   • ** اهم GitHub ڪيشڊ-ڪمٽ قدم: ** توهان جي صاف ڪيل تاريخ کي زور ڏيڻ کان پوءِ به، جيڪو به ڄاڻي ٿو ته پراڻي 40-ڪردار ڪمٽ SHA URL (github.com/org/repo/commit/abc1234...) اڃا GitHub جي ويب UI تي پراڻي ناپاڪ ڪمٽ کي ڏسي سگھي ٿو جيستائين GitHub سرور-سائڊ گندگي گڏ ڪرڻ کي هلائي ٿو. GitHub سپورٽ سان رابطو ڪريو (يا ريپوزٽري جي سيڪيورٽي ايڊوائيزري / سپورٽ پورٽل کي استعمال ڪريو) بلڪل پراڻي ڪمٽ SHA سان ۽ انھن کان پڇو ته ** ڊيري ريفرنسڊ / ڊانگنگ ڪمٽ کي ويب ڪيش مان ڪڍي ڇڏيو ۽ ھلايو git gc ريموٽ مخزن تي**.

حصو 3: حادثي کي ختم ڪرڻ git push --force, git reset --hard، يا ختم ٿيل شاخ¶

جيڪڏهن توهان حادثي سان ڀڄي ويا آهيو git push --force ۽ پنهنجي ٽيم جي ساٿين جي ڪمن کي ختم ڪري ڇڏيو main، يا ڀڄي ويو git reset --hard HEAD-5 ۽ مقامي ڪم جو پورو ڏينهن وڃائي ڇڏيو، گھبرايو نه، ڇاڪاڻ ته گيٽ تقريبن ڪڏهن به ڪم ٿيل شيون فوري طور تي حذف نه ڪندو آهي.

الاءِ ڇو تنهنجو ”گم ٿيل“ ڪمال اڃا تائين اندر سلامت بيٺو آهي .git/logs (The Reflog)¶

جڏهن به توهان هڪ ڪمٽ ٺاهيو ٿا، شاخن کي تبديل ڪريو، ريبيس ڪريو، يا ري سيٽ ڪريو، Git اڳوڻو رڪارڊ ڪري ٿو HEAD ۽ شاخ ٽپ SHA-1/SHA-256 پوائنٽر مقامي ليجر جي اندر جنهن کي ** ريفرنس لاگ (git reflog)**، ۽ اصل يتيم ٿيل شيون ڊسڪ تي رکي ٿو ** گهٽ ۾ گهٽ 14 کان 90 ڏينهن ** ان کان اڳ جو ڪچرو گڏ ڪرڻ انهن کي هٽايو وڃي.

قدم قدم Git ايمرجنسي بحالي جي ترڪيبون¶

منظر 1: توهان ڀڄي ويا git push --force ۽ مٿي لکيو origin/main¶

1. ** صحيح ڪمٽ SHA کي ڳولھيو origin/main توهان جي زور جي زور کان اڳ ساڄي طرف اشارو ڪيو ويو:**
   • طريقو A (پنهنجي مقامي ريموٽ ٽريڪنگ ريفلاگ کي چيڪ ڪريو): هن حڪم کي ٽرمينل ۾ هلايو جتي توهان ڌڪيو آهي:

     git reflog show origin/main
     

     توھان ڏسندا ٻاھر نڪرڻ جھڙو آھي:

     a1b2c3d (HEAD -> main, origin/main) refs/remotes/origin/main@{0}: update by push
     9f8e7d6 refs/remotes/origin/main@{1}: fetch: fast-forward
     

     هتي، 9f8e7d6(origin/main@{1}) صحيح ڪمٽ آهي origin/main ساڄي پاسي هو ان کان اڳ جو توهان جي زور زور ان کي اوور رائٽ ڪيو.
   • ** طريقو B (ڪنهن به ٽيم جي ساٿي کان پڇو جيڪو نه هليو آهي git pull اڃان تائين):** ڪو به همراهه جيڪو کڻي آيو main ان کان اڳ اڄ تائين اڃا تائين برقرار آهي عزم جي تاريخ انهن جي مقامي ۾ ويٺي آهي origin/main شاخ.
   • طريقو C (GitHub REST API واقعن جي لاگ کان سوال ڪريو): جيڪڏهن توهان جي مقامي ريفلاگ ۾ ريموٽ اسٽيٽ نه آهي، سوال ڪريو GitHub جي push events API کي ڏسڻ لاءِ "before" SHA hash of the force-push event:

     gh api /repos/OWNER/REPO/events --jq '.[] | select(.type=="PushEvent") | {actor: .actor.login, before: .payload.before, head: .payload.head, time: .created_at}'
     

2. ** بحال ڪريو origin/main اڳئين ڪمٽ SHA کي محفوظ طور تي:**
   • تصديق ڪريو ته ڪمٽ صحيح نظر اچي ٿو (git log -n 5 9f8e7d6)، پوءِ ان صحيح SHA کي واپس ريموٽ ڏانھن دٻايو main شاخ استعمال ڪندي --force-with-lease:

     git push --force-with-lease origin 9f8e7d6:refs/heads/main
     

منظر 2: توهان ڀڄي ويا git reset --hard يا زور ڏيڻ کان اڳ مقامي شاخ کي ختم ڪيو¶

1. ** ڀڄڻ git reflog توهان جي مقامي مخزن ۾:**

   git reflog --date=iso
   

2. ** ڪمٽ SHA کي درست ڪريو کان اڳ reset: داخلا** (مثال طور، HEAD@{2}: commit: feat: add payment webhook)، ۽ هڪ نئين بچاء واري شاخ ٺاهي سڌو سنئون انهي SHA ڏانهن اشارو ڪندي:

   git switch -c rescue-branch HEAD@{2}
   

3. جيڪڏهن توهان هڪ غير پابند فائل وڃائي ڇڏيو ته توهان git added (اسٽيج) ۽ پوءِ ختم ڪيو ويو git reset --hard؟
   • جنهن لمحي توهان هلندا آهيو git add myfile.ts، Git ان فائل جي مڪمل مواد کي دٻائي ٿو ۽ لکي ٿو .git/objects/ جيئن ته هڪ جنگل بلب، جيتوڻيڪ توهان ڪڏهن به نه ڊوڙيو git commit. ترميمي وقت جي ترتيب سان ترتيب ڏنل سڀني ڊنگنگ بلب کي لسٽ ڪندي ان کي حاصل ڪريو:

     git fsck --lost-found
     # Inspect the recovered blobs written into .git/lost-found/other/
     

حصو 4: حادثاتي terraform destroy يا ختم ٿيل ڪلائوڊ اسٽوريج (S3، EBS، VMs)¶

جيڪڏهن هڪ انفراسٽرڪچر-جي-ڪوڊ (IaC) پائپ لائن يا دستي CLI ڪمانڊ پيداوار جي بادل وسيلن کي ختم ڪرڻ شروع ڪري ٿو:

1. محفوظ طريقي سان عمل کي روڪيو:
   • جيڪڏهن توهان جي ٽرمينل ۾ مقامي طور تي هلندي، پريس ڪريو Ctrl + C ONCE تنهنڪري Terraform پنهنجي موجوده API ڪال ختم ڪري ٿو ۽ تازه ڪاري لکي ٿو .tfstate صاف فائل. جيڪڏهن GitHub Actions، GitLab CI، يا Terraform Cloud جي اندر ڊوڙي رهيا آهيو، Cancel Run تي ڪلڪ ڪريو ۽ CI رنر جي AWS/GCP IAM ڪردار کي فوري طور تي ڪلائوڊ ڪنسول ۾ غير فعال ڪريو ته جيئن ان فلائيٽ API کي ڊليٽ ڪرڻ سان ناڪام ٿئي. AccessDenied.
2. ** موجوده کي بيڪ اپ ڪريو .tfstate فوري طور تي فائل:**
   • توهان جي ريموٽ اسٽيٽ فائل جي مقامي ڪاپي ڊائون لوڊ ڪريو (terraform state pull > emergency-backup.tfstate) ۽ چيڪ ڪريو S3 بالٽ ورزننگ پنھنجي Terraform اسٽيٽ بالٽ تي 10 منٽ اڳ کان پوئين اسٽيٽ ورزن کي پڪڙڻ لاءِ.
3. ڪلائوڊ فراهم ڪندڙ چيڪ ڪريو "نرم-ڊيليٽ" ۽ ريسائيڪل بن حفاظت جا نيٽ:
   • Amazon S3 (بڪٽ ورجننگ فعال ٿيل سان): فائلن کي ڊليٽ ڪرڻ واري نسخي واري S3 بالٽ ۾ (aws s3 rm --recursive) ** نه ** هڪ اعتراض کي حذف ڪري ٿو؛ اهو صرف هر اعتراض جي چوٽي تي هڪ صفر-بائيٽ ** مارڪر کي ختم ڪريو ** داخل ڪري ٿو. هٽايو مارڪرز کي هٽايو (ذريعي S3 Batch Operations يا 5-line Python boto3 اسڪرپٽ) توهان جي 100 سيڪڙو فائلن کي فوري طور تي بحال ڪرڻ لاء.
   • AWS EBS حجم ۽ RDS اسنيپ شاٽ (ري سائيڪل بن): چيڪ ڪريو AWS ريسائيڪل بن ڪنسول ۾ جيڪڏهن ترتيب ڏنل آهي، ۽ چيڪ ڪريو AWS بيڪ اپ والٽس.
   • گوگل ڪلائوڊ پليٽ فارم (GCP) ۽ Microsoft Azure: حذف ٿيل GCP پروجيڪٽس ۽ Azure Resource Groups / Key Vaults / Storage Accounts with Soft Delete فعال آهن **7 کان 30 ڏينهن لاءِ بحال ٿيڻ لائق ** ڪنسول ۾ هڪ واحد بحالي ڪلڪ ذريعي.

ٽٽل ٽيرافارم کي ڪيئن بحال ڪجي .tfstate رياستي فائل يا ٻيهر درآمد يتيم زيربنا¶

جڏهن هڪ terraform apply يا حادثاتي terraform destroy وچ ۾ اڏام ۾ رڪاوٽ آهي، يا جڏهن ڪو غلطي سان S3/GCS ۾ ريموٽ اسٽيٽ فائل کي حذف ڪري ٿو، توهان جو ڪلائوڊ انفراسٽرڪچر هڪ خطرناڪ تقسيم دماغ واري حالت ۾ داخل ٿئي ٿو جتي ڪجهه وسيلا اڃا تائين AWS/GCP ۾ موجود آهن جڏهن ته ٻيا غائب آهن. .tfstate:

1. ** هڪ اوور رائٽ يا ختم ٿيل ريموٽ کي بحال ڪرڻ .tfstate فائل S3 / GCS ورزننگ مان:**
   • ڪڏهن به دستي طور JSON ايڊٽ نه ڪريو .tfstate فائل هٿ سان ٽيڪسٽ ايڊيٽر ۾ جيستائين هر ٻيو آپشن ناڪام ٿي ويو آهي، ڇاڪاڻ ته هڪ ئي بي ترتيب آهي "serial" يا "lineage" UUID اسٽرنگ Terraform کي ٻيهر لاڳو ڪرڻ کان روڪيندو.
   • پنھنجي S3 بڪيٽ (يا Google Cloud Storage bucket / Terraform Cloud Workspace States ٽئب) کوليو جتي ريموٽ پس منظر رھندو آھي، ڪلڪ ڪريو شو ورجن ڏيکاريو ٽوگل S3 ڪنسول جي چوٽي تي، ڳولھيو terraform.tfstate نسخو ٽائم اسٽيمپ صحيح خراب ٿيڻ کان اڳ، ان کي ڊائون لوڊ ڪريو، ۽ ان کي محفوظ طور تي واپس دٻايو جيئن نئين موجوده حالت:

     # Push a recovered historical state file back to the remote backend safely
     terraform state push recovered-pre-incident.tfstate
     

2. ** هڪ پڪي رياستي تالا ٽوڙڻ (Error acquiring the state lock):**
   • جڏهن توهان هڪ خراب کي ختم ڪيو terraform destroy سان Ctrl + C يا ھنگ سي آءِ رنر کي ماريو، ريموٽ DynamoDB ٽيبل يا GCS لاڪ فائل مئل پروسيس آئي ڊي سان بند رھي ٿي.
   • پهرين پنهنجي CI ڊيش بورڊ ۾ ۽ پنهنجي ٽيم جي ساٿين سان تصديق ڪريو ته صفر ٻيا Terraform عمل اصل ۾ اڃا تائين ان ورڪ اسپيس جي خلاف هلي رهيا آهن، پوءِ غلط پيغام ۾ ڇپيل Lock ID UUID استعمال ڪندي يتيم بند کي ڇڏايو:

     terraform force-unlock <LOCK_ID_UUID>
     

3. ** جزوي طور تي تباهه ٿيل ماحول کي ٻيهر تعمير ڪرڻ بغير بقايا ڊيٽابيس کي ٻيهر ٺاهڻ (terraform import):**
   • جيڪڏهن هڪ terraform destroy توهان جي بي رياست ايپليڪيشن لوڊ بيلنسرز کي ختم ڪيو (aws_lb) ۽ ECS/EKS ورڪر نوڊس ان کي بند ڪرڻ کان اڳ، جنهن کي درست ڪرڻ آسان آهي: بس هلايو terraform apply ۽ Terraform 5 منٽن ۾ شروع کان سڀني اسٽيٽ بيس نيٽ ورڪنگ ۽ پرت کي ڪمپيوٽ ڪندو جڏهن ته توهان جي بچيل RDS ڊيٽابيس کي اڻ ڇهيو ڇڏي.
   • جيڪڏهن توهان جي رياستي فائل هڪ بچيل رياستي ڊيٽابيس يا S3 بالٽ جو ٽريڪ وڃائي ڇڏيو، هڪ ** استعمال ڪريوimport {} ٺاھ جوڙ بلاڪ** (Terraform 1.5+) يا terraform import aws_db_instance.prod_db my-rds-instance-id موجوده ڪلائوڊ ريسورس کي پابند ڪرڻ لاءِ واپس پنهنجي اسٽيٽ فائل ۾ ان کي تباهه ڪرڻ کان سواءِ، ۽ هلايو terraform plan تصديق ڪرڻ "0 to destroy" درخواست ڏيڻ کان اڳ.

حصو 5: توهان جي مئنيجر کي هڪ آئوٽيج ڪيئن ٻڌايو ۽ هڪ بي قصور پوسٽ مارٽم جي اڳواڻي ڪريو¶

جڏهن توهان دور کان ڪم ڪرڻ دوران هڪ پيداواري واقعي جو سبب بڻجندا آهيو، توهان جي پيشه ورانه شهرت جي تعريف ڪئي ويندي آهي **نه ** غلطي سان، پر توهان جي رفتار جي شفافيت، پرسکون رابطي، ۽ منظم طريقي سان.

واقعا مواصلات جا 3 گولڊن اصول¶

1. ** لڪائڻ، دير ڪرڻ يا الزام لڳائڻ کان سواءِ حقيقتون، اثر، ۽ ETA بيان ڪريو:** دريافت جي 2 منٽن اندر غلطي جي رپورٽ ڪريو.
2. ** ”روٽ ڪاز فڪس“ کان الڳ ”مٽائيگيشن“ (خون وهڻ کي روڪڻ):** ايمرجنسي ۾، توهان جو واحد مقصد سروس بحال ڪرڻ آهي (خراب ڊيپلائي کي واپس ڪرڻ، PITR ڊيٽابيس جي ڪلون تي ناڪام ٿيڻ، يا خصوصيت جي پرچم کي فلپ ڪرڻ). سڀاڻي لاءِ ڊيپ ڪوڊ ريفيڪٽرنگ محفوظ ڪريو.
3. ** باقاعده 15 منٽن جي دل جي ڌڙڪن جي تازه ڪاريون ** واقعا چينل ۾ پوسٽ ڪريو ته جيئن ايگزيڪيوٽوز ۽ ڪسٽمر سپورٽ کي خبر پوي ته ڪو ماڻهو ڪنٽرول ۾ آهي.

ڪاپي پيسٽ سست / ٽيمن واقعن جو اعلان اسڪرپٽ¶

[SEV-1 واقعو] پيداوار [سروس / ڊيٽابيس جو نالو] اثر - ڇا ٿيو: تي [HH:MM UTC]، عمل ڪرڻ دوران [brief technical action, e.g., a data migration script]، اڻڄاتل [DELETE / config change / force-push] پيداوار تي لاڳو ڪيو ويو [database / service]. - موجوده ڪسٽمر اثر: [e.g., Checkout API is returning 500 errors / User profile updates are paused]. - ** فوري طور تي گھٽتائي ۾ پيش رفت:** 1. ٽريفڪ ڏانهن لکو [table/service] ڊيٽا جي سالميت کي بچائڻ لاءِ روڪيو ويو آهي. 2. Point-In-Time Recovery (PITR) ڪلون تائين [HH:MM:SS UTC] (واقعي کان 10 سيڪنڊ اڳ) في الحال گھمائي رهيو آهي [AWS RDS / GCP]. - ** واقعا ڪمانڊر:** @[Your Name] (مدد ڪئي وئي @[DBA/On-Call SRE]). - اڳيون اپڊيٽ: 15 منٽن ۾ ([HH:MM UTC]) يا جيترو جلدي وصولي ڪلون آن لائن اچي ٿو.

پوسٽ-حادثي جي انجنيئرنگ حفاظتي چيڪ لسٽ (توهان جي بي قصور پوسٽ مارٽم لاءِ)¶

پيداوار ۾ هر انساني غلطي اصل ۾ هڪ سسٽم ڊيزائن گيپ آهي (جيڪڏهن هڪ واحد ڪاپي پيسٽ ٿيل ٽرمينل ڪمانڊ بغير ڪنهن گارڊ جي پيداوار کي ڇڏي سگهي ٿو، سسٽم ناڪام ٿيڻ جو انتظار ڪري رهيو هو). ايندڙ ڏينهن توهان جي پوسٽ مارٽم دستاويزن ۾ انهن ڪنڪريٽ ٽيڪنيڪل گارڊن جو تجويز ۽ عمل ڪريو:

• رنگ-ڪوڊ ۽ پريفڪس پيداوار جي اشاري (kube-ps1, psql .psqlrc): پنهنجي شيل ۽ SQL ڪلائنٽ کي ترتيب ڏيو ته جيئن ڪو به ڪنيڪشن PRODUCTION هڪ روشن لال ڏيکاري ٿو [PROD-DB] فوري طور تي ۽ هر انٽرايڪٽو PostgreSQL سيشن کي شروع ڪري ٿو BEGIN; ٽرانزيڪشن بلاڪ ڊفالٽ طرفان (يا سيٽ SET default_transaction_read_only = on;).
• ** چالو ڪريو safe-updates (--i-am-a-dummy) MySQL/MariaDB ڪلائنٽ ۾:** شامل ڪريو safe-updates ڏانهن [mysql] ۾ -/.my.cnf تنهنڪري MySQL مڪمل طور تي ڪنهن به عمل ڪرڻ کان انڪار ڪري ٿو UPDATE يا DELETE بيان جنهن ۾ a جي کوٽ آهي WHERE اهم شق يا الف LIMIT.
• ** چالو ڪريو DeletionProtection = true سڀني پيداوار تي RDS ڊيٽابيس، S3 بالٽ، ۽ Terraform رياستي وسيلن** (lifecycle { prevent_destroy = true }).
• ** Git برانچ جي تحفظ جي ضابطن کي لاڳو ڪريو main / production:** غير فعال Allow force pushes ۽ Allow deletions GitHub/GitLab ۾ محفوظ شاخن تي پوءِ به مخزن جا منتظم نٿا ڪري سگهن git push --force ڏانهن main.
• ** انسٽال ڪريو اڳ-ڪمٽ راز اسڪيننگ ٿلهو (gitleaks يا trufflehog) ۽ GitHub پش تحفظ: ** بلاڪ ڪمٽس تي مشتمل آهي AKIA, sk_live_، يا .env مقامي نموني اڳ git commit جيتوڻيڪ ڪامياب.

اڪثر پڇيا ويا سوال¶

ڇا مون کي برطرف ڪيو ويندو غلط طور تي هڪ پيداوار ڊيٽابيس ٽيبل کي ڇڏڻ يا سائيٽ جي بندش سبب؟¶

صحتمند انجنيئرنگ تنظيمن ۾ جيڪي بي عيب حفاظت ڪلچر (معياري جديد ٽيڪنالاجي، DevOps، ۽ SRE ٽيمن ۾) تي عمل ڪن ٿا، انجنيئرن کي پيداوار ۾ ايماندار انساني غلطين لاءِ برطرف نه ڪيو ويو آهي، بشرطيڪ اهي فوري طور تي واقعي جي رپورٽ ڪن ۽ خدمت بحال ڪرڻ ۾ مدد ڪن. انجنيئرنگ ليڊر تسليم ڪن ٿا ته جيڪڏهن هڪ جونيئر يا سينئر ڊولپر وٽ خام اجازتون هيون ۽ هڪ پروڊڪشن ٽيبل کي هڪ واحد غير نظرثاني ٿيل ڪمانڊ سان ڇڏڻ لاءِ گارڊن جي کوٽ هئي، بنيادي سبب رسائي ڪنٽرول ۽ ڊيپلائيمينٽ ٽولنگ ۾ هڪ نقص آهي، نه ڪي بدانتظامي. عملي طور تي، انجنيئر جيڪو صرف اهو تجربو ڪيو آهي ته پهرين هٿ کان ٻاهر نڪرڻ هاڻي هن سسٽم جي حوالي سان ٽيم تي واحد محفوظ شخص آهي. صرف اهو رويو جيڪو مسلسل ختم ٿيڻ جو سبب بڻجندو آهي ڊيٽا جي نقصان واري واقعي کي لڪائڻ جي ڪوشش، آڊٽ لاگز کي حذف ڪرڻ، يا واقعي جي جاچ دوران ڪوڙ ڳالهائڻ.

مون کي فوري طور تي پنهنجي لائيو پروڊڪشن ٽريفڪ کي نئين بحال ٿيل پوائنٽ-ان-ٽائم ريڪوري (PITR) ڊيٽابيس مثال تي ڇو نه بدلائڻ گهرجي؟¶

جيڪڏهن توهان صرف اتفاقي طور تي هڪ ٽيبل تان قطارون ختم ڪيون (مثال طور، `user_preferences` ٽيبل) 14:00 UTC تي، ۽ 13:59:50 UTC تي بحال ٿيل PITR ڪلون کي گھمڻ ۾ 20 منٽ لڳن ٿا، توھان جي لائيو پروڊڪشن ڊيٽابيس شايد ھزارين جائز ڪسٽمر آرڊرن ۽ ادائيگين جي پروسيسنگ جاري رکي سگھي ٿي. `orders` 14:00 ۽ 14:20 UTC جي وچ ۾ ٽيبل. جيڪڏهن توهان انڌا ڪري پنهنجي پوري پيداوار جي ڊي اين ايس جي آخري پوائنٽ کي 13:59:50 PITR ڪلون تي ڦيرايو ٿا، ته توهان انهن 20 منٽن کي صاف ڪري ڇڏينداسين برانڊ-نئين ڪسٽمر آرڊر. ان جي بدران، مکيه ڊيٽابيس کي آن لائن رکو (صرف ٽٽل خصوصيت تي لکڻين کي روڪيو) ۽ 13:59:50 PITR ڪلون مان صرف غائب قطارن کي واپس لائيو پروڊڪشن ٽيبل ۾ برآمد ڪريو.

جيڪڏهن مان هڪ عوامي GitHub مخزن نجي ڪريان ٿو ٻه منٽن کان پوءِ حادثاتي طور تي هڪ کي ڌڪ ڏيڻ .env فائل، ڇا مون کي اڃا تائين سڀني API چابين کي گھمڻ جي ضرورت آهي؟¶

ها، انهن چابين جو 100 سيڪڙو اڃا به رد ڪيو وڃي ۽ فوري طور تي گھمايو وڃي. عوامي GitHub مخزن ڏانهن ڌڪيل هر ڪم کي حقيقي وقت ۾ نشر ڪيو ويندو آهي عوامي GitHub Events API ("The Firehose") ۽ سيڪنڊن اندر ٻنهي جائز سيڪيورٽي آرڪائيو سروسز (جهڙوڪ GHArchive) ۽ بدسلوڪي خودڪار سندي-حاصل ڪرڻ واري بوٽس ذريعي ترتيب ڏنل آهي 24/7 ڪلائوڊ نيٽ ورڪن تي. مخزن جي نمائش کي ٻن منٽن بعد پبلڪ کان پرائيويٽ ڏانهن فلپ ڪرڻ سان ڪاپي ختم نه ٿيندي جيڪا خودڪار اسڪراپر اڳ ۾ ئي ڊائون لوڊ ٿيل آهي.

ڪيئن ٿو git push --force-with-lease جي ڀيٽ ۾ outages کي روڪڻ git push --force؟¶

جڏهن توهان معياري هلائيندا آهيو `git push --force`، Git غير مشروط طور تي ريموٽ برانچ کي توهان جي مقامي برانچ سان اوور رائٽ ڪري ٿو، خاموشيءَ سان ڪنهن به ڪمٽٽ کي تباهه ڪندي هڪ ٽيم جي ساٿي کي انهي شاخ ڏانهن ڌڪايو ويو آهي. جڏهن توهان استعمال ڪريو `git push --force-with-lease` (۽ اڃا به بهتر، `--force-if-includes`)، Git پهرين ريموٽ سرور کي چيڪ ڪري ٿو تصديق ڪرڻ لاءِ ته ريموٽ برانچ ٽپ اڃا تائين صحيح ڪمٽٽ SHA سان ملندو آهي جيڪو توهان جي مقامي مشين کي آخري ڀيرو آندو ويو آهي. جيڪڏهن ڪو همراهه يا سي آءِ پائپ لائن توهان جي آخري آڻڻ کان وٺي ريموٽ برانچ ڏانهن هڪ نئين ڪمٽ کي دٻايو، `--force-with-lease` انهن جي ڪم کي ختم ڪرڻ جي بدران "باڻي معلومات" وارننگ سان محفوظ طور تي ختم ڪري ٿو.

ذريعن جي چڪاس ڪئي وئي¶

• نيشنل انسٽيٽيوٽ آف معيار ۽ ٽيڪنالاجي (NIST, United States): NIST SP 800-61 Rev. 2 / Rev. 3 ڪمپيوٽر سيڪيورٽي حادثو هينڊلنگ گائيڊ ۽ سندي سمجھوتي ڪنٽينمينٽ.
• Amazon Web Services (AWS)، Google Cloud Platform (GCP)، ۽ Microsoft Azure Documentation (United States): RDS Automated Point-In-Time Recovery (PITR) آرڪيٽيڪچر، AWS IAM سمجھوتي ڪيل ڪي قرنطين پاليسيون (AWSCompromisedKeyQuarantineV2)، ۽ S3 ورزننگ ڊيليٽ مارڪر ريڪوري.
• PostgreSQL گلوبل ڊولپمينٽ گروپ ۽ MySQL / Oracle Documentation (International): PostgreSQL Write-Ahead Logging (WAL), MVCC Tuple Visibility, and MySQL Row-based Binary Log Flashback Recovery.
• Git SCM سرڪاري دستاويز ۽ GitHub سيڪيورٽي ليب (انٽرنيشنل): * Git Reflog (git-reflog)، ڊنگلنگ آبجیکٹ جي بحالي (git-fsck)، تاريخ ٻيهر لکڻ (git-filter-repo)، ۽ ڳجهي اسڪيننگ پش تحفظ*.
• USENIX ايسوسيئيشن / SREcon ۽ گوگل سائيٽ ريليبلٽي انجنيئرنگ (SRE) ڪتاب (انٽرنيشنل): منيجنگ حادثا، ايمرجنسي رول بيڪ ٽريج، ۽ بي قصور پوسٽ مارٽم ڪلچر.

لاڳاپيل ھدايتون¶

• ايمرجنسي ريموٽ ڪم سيڪيورٽي ۽ ڊيٽا رازداري
• ڪمپيوٽر جو بيڪ اپ 3-2-1 حڪمت عملي ۽ آفت جي بحالي
• حادثي واري فائل کي ختم ڪرڻ ۽ فارميٽ ٿيل ڊرائيو وصولي
• ويب هوسٽنگ بحران لڏپلاڻ ۽ بيڪ اپ بحالي
• فشنگ ۽ سمجهوتو اڪائونٽس
• ايمرجنسي نمبر