Linux Crisis Tools
“क्राइसिस टूल्स” पहले से इंस्टॉल करना
- कई लोग एक मानक “क्राइसिस-एसेंशियल” पैकेज समूह के पक्ष में तर्क देते हैं, जो build-essential के समान हो, और जिसे सभी सर्वरों पर पहले से इंस्टॉल किया जाए।
- कुछ लोग ऐसे सूचियाँ config-management (Ansible/Salt/Chef) के जरिए, devops_tools जैसे नामों के तहत, पहले से बनाए रखते हैं।
- चिंता यह है कि “सुरक्षा” के लिए सिस्टम और कंटेनरों को काट-छाँट देना अक्सर ज़रूरी debugging tools हटा देता है, जिससे incidents को हल करना कहीं अधिक कठिन हो जाता है।
Cloud, cattle, और “बस मशीन को मार दो”
- एक पक्ष virtualized “cattle” (अक्सर cloud में) की तारीफ़ करता है, जहाँ failing nodes को जल्दी बदला जा सकता है, service बहाल की जा सकती है और offline debugging की जा सकती है।
- दूसरे लोग इसका विरोध करते हैं: replacement root causes को छिपा सकता है, troubleshooting skills को कमजोर कर सकता है, और कभी-कभी समस्या नई instances पर भी बनी रहती है।
- कई लोग नोट करते हैं कि यह “reboot/replace first” संस्कृति junior devs के git repos को समझने के बजाय बस reclone करने जैसी है।
- कुछ लोग short-term और long-term calculus में अंतर करते हैं: quick restarts वैध हैं, लेकिन अधिक उपयोग होने पर वे “technological mysticism” की ओर ले जाते हैं।
Storage, networking, और non-trivial failure modes
- टिप्पणियाँ बताती हैं कि complex storage (RAID, Ceph, MD, distributed filesystems) के साथ VMs को blindly replace करना जोखिम भरा है; rebuilds failure risk बढ़ा सकते हैं।
- Network और DNS issues अक्सर होती हैं और गलत diagnose भी की जाती हैं; “it’s never DNS… until it is” पर मज़ाक भी है।
- बड़े “big iron” या HPC clusters में failures orchestration layers (जैसे schedulers), tiered storage, और exotic interconnects से जुड़े हो सकते हैं।
Containers, Kubernetes, और serverless
- EC2 और containers के भीतर tools अभी भी उपयोगी रहते हैं, क्योंकि containers host पर सिर्फ processes हैं; host-level tooling फिर भी उन्हें introspect कर सकता है।
- Serverless (जैसे Lambda) जहाँ OS access नहीं होता, वहाँ लोग application-level observability/profiling पर लौटते हैं।
- Security-focused Kubernetes setups में अक्सर shells और tools नहीं होते; debug images या static binaries की volumes जोड़ने का सुझाव दिया जाता है, लेकिन management testing और scanning requirements के कारण इसका विरोध कर सकती है।
उल्लेखित विशिष्ट tools और approaches
- System और tracing tools: perf, eBPF tools, strace (as a “last resort”), lsof, fuser, sar family, atop (with caveats), tmux/screen.
- Network/disk/debug helpers: nmap, netstat, nc, tcpdump-in-Docker, ncdu, rsync, busybox, static rescue binaries.
- कुछ लोग package managers के टूट जाने पर Docker-delivered tools की वकालत करते हैं, जबकि अन्य बताते हैं कि air-gapped environments में यह विफल हो जाता है।
Security बनाम operability
- एक पक्ष को चिंता है कि शक्तिशाली tools पहले से इंस्टॉल करने से attack surface बढ़ जाती है।
- दूसरे जवाब देते हैं कि attackers आमतौर पर अपने tools खुद ला सकते हैं; असली लागत यह है कि crises के दौरान बार-बार tool-less environments में “locked in” रहना पड़ता है।