रक्षात्मक इंजीनियरिंग: आपदा-प्रतिरोधी सिस्टम

मिड-साइज़ फिनटेक कंपनी के एक जूनियर इंजीनियर ने शुक्रवार दोपहर एक database migration script चलाई। स्क्रिप्ट का काम staging environment में orphaned records साफ करना था। लेकिन उसने production database से कनेक्ट होकर 42 लाख customer transaction records डिलीट कर दिए। बैकअप? वह तीन दिन पुराना था। कंपनी अगले 72 घंटे पूरी तरह incident response में रही और payment processor के logs से records हाथ से मिलाती रही। कुल खर्च इंजीनियरिंग समय, customer credits और regulatory reporting मिलाकर $400,000 से ज़्यादा रहा।

स्क्रिप्ट में कोई environment check नहीं था। कोई dry-run flag नहीं था। कोई confirmation prompt नहीं था जो दिखाता कि वह किस database से जुड़ी है। Connection string एक environment variable से आ रही थी, जो दो हफ्ते पहले एक debugging session के दौरान इंजीनियर के laptop पर संयोग से production पर सेट रह गया था। ये सारी गलतियाँ रोकी जा सकती थीं।

“क्या आप निश्चित हैं?” वाले Dialogs क्यों काम नहीं करते

Software में सबसे आम safety mechanism confirmation dialog है। और यही सबसे बेकार भी है। Confirmation fatigue पर हुए अध्ययन बताते हैं कि यूज़र “क्या आप निश्चित हैं?” वाले prompts को कुछ बार देखने के बाद लगभग 100% मामलों में बस क्लिक करके आगे बढ़ जाते हैं। वह prompt अदृश्य हो जाता है, बस उस रास्ते का एक और क्लिक बन जाता है जिस पर आप पहले ही जा चुके हैं।

समस्या यह नहीं कि confirmations एक बुरा विचार हैं। समस्या यह है कि generic confirmations में कोई जानकारी नहीं होती। “क्या आप आगे बढ़ना चाहते हैं?” यह नहीं बताता कि आप क्या करने जा रहे हैं। इसकी तुलना इससे करें: “आप prod-us-east-1 में transactions table से 4,217,893 rows डिलीट करने वाले हैं। पुष्टि के लिए database का नाम टाइप करें।” दूसरा संस्करण आपको मजबूर करता है कि सच में पढ़ें कि क्या हो रहा है। स्पीड बंप और molly guard के बीच यही फर्क है।

Molly Guard क्या है और यह क्यों मायने रखता है

“molly guard” शब्द mainframe computers के Big Red Button पर लगे उस भौतिक प्लास्टिक कवर से आया है, जो गलती से shutdown होने से रोकने के लिए लगाया जाता था। माना जाता है कि इसका नाम एक प्रोग्रामर की छोटी बेटी Molly के नाम पर पड़ा, जो बार-बार उस बटन को दबा देती थी। Software में molly guard कोई भी ऐसा तंत्र है जो विनाशकारी कार्रवाई को गलती से करना मुश्किल बनाता है, लेकिन जानबूझकर करने पर संभव रहने देता है।

Linux package molly-guard ठीक यही करता है। यह SSH sessions पर shutdown, reboot और halt कमांड को रोकता है और आपसे उस machine का hostname टाइप करने को कहता है, जिसे आप बंद करने वाले हैं। आप इसे बस ऑटोपायलट की तरह पार नहीं कर सकते। आपको साबित करना होगा कि आप जानते हैं कि आप किस machine पर हैं।

$ sudo reboot
Good grief! You're on a remote SSH session to prod-web-03.
Please type the hostname to confirm: prod-web-03
# Compare with the useless version:
$ sudo reboot
Are you sure? (y/n): y
# *types y without reading, muscle memory*

सिद्धांत सरल है: confirmation ऐसी जानकारी माँगे जो साबित करे कि ऑपरेटर कार्रवाई को समझता है। “y” टाइप करने से कुछ साबित नहीं होता। Hostname, table का नाम या प्रभावित records की संख्या टाइप करने से साबित होता है कि आपने चेतावनी पढ़ी है।

Dry-Run Modes: गोली चलाने से पहले देखें

हर विनाशकारी operation में dry-run mode होना चाहिए। “होना चाहिए” सिर्फ best practice के अर्थ में नहीं, बल्कि इस अर्थ में कि एक दिन आपको इसकी कमी पर पछतावा होगा। Dry run operation का पूरा logic चलाता है, लिखता है कि वास्तव में क्या होता, और फिर रुक जाता है। कोई side effect नहीं। पूरी पारदर्शिता।

इसे लागू करना सीधा है। यह एक migration script है जिसमें dry-run पहले से बना है:

#!/bin/bash
set -euo pipefail
DRY_RUN=${DRY_RUN:-true}  # Default to dry-run!
DB_HOST=$(get_db_host)
DB_NAME=$(get_db_name)
echo "Target: $DB_HOST / $DB_NAME"
echo "Mode: $([ "$DRY_RUN" = true ] && echo 'DRY RUN' || echo 'LIVE')"
ROWS=$(psql -h "$DB_HOST" -d "$DB_NAME" -t -c \
"SELECT count(*) FROM orphaned_records WHERE created_at < now() - interval '90 days'")
echo "Records to delete: $ROWS"
if [ "$DRY_RUN" = true ]; then
echo "Dry run complete. Set DRY_RUN=false to execute."
exit 0
fi
# Require explicit confirmation for live runs
read -p "Type '$DB_NAME' to confirm deletion: " CONFIRM
if [ "$CONFIRM" != "$DB_NAME" ]; then
echo "Aborted."
exit 1
fi
psql -h "$DB_HOST" -d "$DB_NAME" -c \
"DELETE FROM orphaned_records WHERE created_at < now() - interval '90 days'"
echo "Deleted $ROWS records."

ध्यान दें तीन बातों पर: डिफ़ॉल्ट dry-run है (विनाश में आपको शामिल होना पड़ता है, बाहर नहीं रहना), कुछ भी करने से पहले यह target database और row count दिखाता है, और live mode में भी database का नाम टाइप करना ज़रूरी है। तीन स्तर की सुरक्षा। इनमें से कोई भी एक, शुरू में बताई गई घटना को रोक देता।

Database Migration के Safety Nets

Database migrations किसी भी deployment pipeline के सबसे जोखिम भरे operations में से हैं। ये अक्सर अपरिवर्तनीय होते हैं, साझा state पर चलते हैं, और एक गलत migration पूरी application को ठप कर सकती है। फिर भी ज़्यादातर टीमें इन्हें बस एक और deploy step मानती हैं।

सबसे बुनियादी से लेकर सबसे पक्के तक, safety mechanisms की एक सीढ़ी यह रही:

1. Environment checks — Migration script execute होने से पहले जाँचती है कि वह सही environment को target कर रही है। सुनने में यह स्पष्ट लगता है। आप हैरान होंगे कि यह कितनी बार गायब रहता है।
2. Pre-migration snapshots — किसी भी migration से पहले अपने आप database snapshot बनाएँ। अगर migration फेल हो या समस्या पैदा करे, तो आप घंटों नहीं, मिनटों में restore कर सकते हैं।
3. Row count guards — अगर migration N से ज़्यादा rows पर असर डालेगी, तो स्पष्ट confirmation माँगें। जो migration अचानक लाखों rows छूती है, वह लगभग हमेशा एक bug होती है।
4. Statement timeouts — migration queries पर सख्त timeouts लगाएँ। जो migration 45 मिनट चलती है, वह tables को lock कर रही होती है और performance गिरा रही होती है। जल्दी फेल हो जाने दें।
5. Backward-compatible only — सुनिश्चित करें कि हर migration वर्तमान में deployed code के साथ backward-compatible हो। यानी कोई column rename नहीं, बिना default के NOT NULL नहीं जोड़ना, और ऐसे column नहीं गिराना जो अभी भी इस्तेमाल हो रहे हों।

# Rails example using strong_migrations gem
class AddPhoneToUsers < ActiveRecord::Migration[7.1]
def change
# This will raise an error with a safe alternative:
# add_column :users, :phone, :string, null: false
#
# Instead, do it in two steps:
add_column :users, :phone, :string
# Then in a separate migration after backfill:
# change_column_null :users, :phone, false
end
end

Rails में strong_migrations, PostgreSQL के लिए squawk, और MySQL के लिए skeema जैसे tools खतरनाक patterns को production तक पहुँचने से पहले पकड़ लेते हैं। अगर आप इनमें से कुछ इस्तेमाल नहीं कर रहे, तो आप subtle migration समस्याएँ पकड़ने के लिए code review पर निर्भर हैं, और code reviewers चीज़ें छोड़ देते हैं।

Soft Deletes और Undo Windows

Hard delete एक ऐसा स्थायी फ़ैसला है जो किसी ऐसे पल में लिया गया जब आप बहुत आश्वस्त थे। समस्या यह है कि वह आश्वस्ति अक्सर गलत होती है। Soft deletes, यानी records को असल में हटाए बिना deleted के रूप में चिह्नित करना, आपको गलतियों से उबरने की खिड़की देते हैं।

-- Hard delete: gone forever
DELETE FROM projects WHERE id = 4872;
-- Soft delete: recoverable
UPDATE projects
SET deleted_at = now(),
deleted_by = 'user:priya'
WHERE id = 4872;
-- Recovery is trivial
UPDATE projects
SET deleted_at = NULL,
deleted_by = NULL
WHERE id = 4872;

इस trade-off में सच्ची लागत है: soft deletes queries को जटिल बनाते हैं (हर जगह WHERE deleted_at IS NULL चाहिए), storage बढ़ाते हैं, और data की असली स्थिति को लेकर भ्रम पैदा कर सकते हैं। फिर भी जिस user-facing data में गलती से delete होना संभव है, वहाँ यह trade-off सार्थक है। GitHub आपकी repository को 90 दिन तक असल में डिलीट नहीं करता। Slack compliance के लिए deleted messages रखता है। Gmail का trash 30 दिन बाद खाली होता है। ये संयोग नहीं हैं, ये सोचे-समझे engineering फ़ैसले हैं।

यही सिद्धांत infrastructure पर भी लागू होता है। EC2 instance को terminate करने के बजाय पहले उसे stop करें। Database drop करने के बजाय उसका नाम बदलकर mydb_deleted_20260315 रखें और दो हफ्ते बाद उसे असल में drop करने के लिए calendar reminder लगाएँ। stopped instance या renamed database को कुछ दिन रखने की लागत backup से restore करने की लागत के मुकाबले नगण्य है।

Deployment Safety: Canaries, Circuit Breakers और Rollbacks

Deployments विनाशकारी कार्रवाई की एक और श्रेणी हैं, जिनसे ज़्यादातर टीमें पर्याप्त सावधानी से पेश नहीं आतीं। एक खराब deploy उतना ही असरदार तरीके से production ठप कर सकता है जितना गिराया हुआ database, और यह कहीं ज़्यादा बार होता है।

न्यूनतम व्यवहार्य deployment safety setup में ये शामिल हैं:

• Canary deployments — 1-5% traffic को नए version पर भेजें। अगर error rate बढ़े, तो blast radius बढ़ने से पहले अपने आप rollback करें।
• Automated rollback triggers — error rate, latency और health check failures की सीमाएँ तय करें जो अपने आप rollback शुरू करें। सुबह 2 बजे किसी इंसान के ध्यान देने पर निर्भर न रहें।
• Incidents के दौरान deploy freeze — अगर कोई active incident है, तो सभी deployments रोक दें। आग बुझाते समय आखिरी चीज़ जो आपको चाहिए, वह है कोई असंबंधित बदलाव deploy करे।
• One-click rollback — Rollback करना roll forward करने से आसान होना चाहिए। अगर आपकी rollback प्रक्रिया में servers पर SSH करके हाथ से कमांड चलाना शामिल है, तो आपके पास rollback प्रक्रिया है ही नहीं।

# Kubernetes progressive delivery with Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: error-rate-check
- setWeight: 25
- pause: { duration: 5m }
- setWeight: 50
- pause: { duration: 10m }
- setWeight: 100
# Auto-rollback if error rate exceeds 1%
abortScaleDownDelaySeconds: 30

यहाँ पैटर्न है progressive commitment। आप एक ही कदम में 0 से 100% नहीं जाते। छोटे कदम उठाते हैं, हर एक की पुष्टि करते हैं, और हर चरण पर पीछे हटने की क्षमता बनाए रखते हैं। यह सभी instances पर एक साथ yolo-deploy करने से धीमा है, लेकिन जिस पहली बार यह खराब deploy को सभी users तक पहुँचने से पहले पकड़ लेगा, तब आप उस हर अतिरिक्त मिनट के लिए शुक्रगुज़ार होंगे।

Architectural Prevention: गलत काम को असंभव बनाना

सबसे अच्छे safety mechanisms आपसे सावधान रहने को नहीं कहते। वे गलत काम को संरचनात्मक रूप से असंभव बना देते हैं। यही guardrail और चेतावनी के संकेत में फर्क है।

• Immutable infrastructure — अगर आप production servers पर SSH नहीं कर सकते, तो गलती से उन पर कमांड नहीं चला सकते। अगर deployments हमेशा किसी ज्ञात image से बने नए instances होते हैं, तो configuration drift नहीं हो सकता।
• Least-privilege access — इंजीनियरों के laptops पर production database credentials नहीं होने चाहिए। बस, बात खत्म। Just-in-time access tools इस्तेमाल करें जो audit trails के साथ अस्थायी credentials दें।
• हर environment के लिए अलग credentials — अगर staging और production अलग credential stores इस्तेमाल करते हैं, तो आप staging tooling से गलती से production से connect नहीं हो सकते।
• Deletion protection — AWS आपको EC2 instances पर termination protection और RDS databases पर deletion protection चालू करने देता है। जो भी ज़रूरी हो, उस पर ये चालू करें। यह पाँच सेकंड का configuration बदलाव है जो विनाशकारी गलतियों की एक पूरी श्रेणी को ही रोक देता है।

अगर कोई एक कमांड चलाकर गलती से production नष्ट कर सकता है, तो समस्या इंसान नहीं, बल्कि वह सिस्टम है जिसने एक ही कमांड को production नष्ट करने दिया।

मैंने देखा है कि टीमें production incidents के जवाब में और documentation, और checklists, और training जोड़ती हैं। ये मदद करते हैं, लेकिन ये सब इस पर निर्भर हैं कि इंसान परफेक्ट हों। इंसान परफेक्ट नहीं होते। बेहतर जवाब है सिस्टम को ऐसे बदलना कि गलती होने की गुंजाइश ही न रहे, या अगर हो भी जाए, तो उसका blast radius सीमित रहे और recovery तेज़ हो।

Safety-First Engineering संस्कृति बनाना

Tools और architecture मायने रखते हैं, लेकिन संस्कृति तय करती है कि उन्हें असल में लागू किया जाएगा या नहीं। जो टीमें safety mechanisms को overhead या नौकरशाही समझती हैं, वे deadline के दबाव में उन्हें छोड़ देंगी, और deadline का दबाव स्थायी होता है।

सबसे प्रभावी पैटर्न जो मैंने देखा है वह है safety mechanisms को nice-to-have नहीं, बल्कि first-class engineering requirement मानना। हर विनाशकारी operation का design review हो, जिसमें खास तौर पर पूछा जाए: अगर यह गलत target पर चला तो क्या होगा? अगर यह दो बार चला तो क्या होगा? अगर यह पुराने data के साथ चला तो क्या होगा? हम इसे कैसे वापस पलटेंगे?

Blameless post-mortems अब बुनियादी ज़रूरत बन चुके हैं। लेकिन एक कम आम प्रथा, जो मुझे और ज़्यादा ज़रूरी लगती है, वह है pre-mortem। किसी जोखिम भरे बदलाव को लॉन्च करने से पहले पूरी टीम को इकट्ठा करें और पूछें: “मान लीजिए यह बुरी तरह गलत हो गया। क्या हुआ?” जब आप इसे भविष्यवाणी के बजाय कल्पना के रूप में रखते हैं, तो लोग विफलता के तरीके पहचानने में हैरानी की हद तक अच्छे होते हैं। जो विफलताएँ वे पहचानते हैं, वही वे safety mechanisms बन जाते हैं जो आप बनाते हैं।

वह जूनियर इंजीनियर जिसने production database गिराया था? वह आज भी कंपनी में है। अब वह टीम में रक्षात्मक इंजीनियरिंग के सबसे मज़बूत समर्थकों में से एक है। वह घटना उसकी गलती नहीं थी, वह एक सिस्टम की विफलता थी। और अब वह सिस्टम तोड़ना कहीं ज़्यादा मुश्किल है।