DevOps इंजीनियर इंटरव्यू के सवाल और जवाब (हिंदी में)

एक fintech startup की Node.js API के लिए feature branch पर push होते ही GitHub Actions dependencies install करता था, linting और unit tests चलाता था और dependencies का vulnerability scan करता था। Main branch में merge होने पर Docker image बनती थी, उस पर commit का tag लगता था और वह registry में जाती थी। फिर staging पर अपने आप deploy होता था और कुछ बुनियादी smoke tests चलते थे। Production के लिए manual approval ज़रूरी था। Deploy के बाद health check fail होने पर पिछली image पर rollback अपने आप होता था।

Image एक read-only template है, जो Dockerfile से layers में बनती है और उसमें application और उसकी dependencies होती हैं। Container उसी image का चलता हुआ रूप है, जिसकी अपनी writable layer होती है। Image छोटी रखने के लिए मैं slim या alpine जैसी छोटी base image लेता हूं, multi-stage build करता हूं ताकि build tools आख़िरी image में न जाएं, और .dockerignore से फ़ालतू files बाहर रखता हूं। जो चीज़ें कम बदलती हैं, उन्हें Dockerfile में ऊपर रखता हूं ताकि cache काम आए।

CrashLoopBackOff का मतलब है कि container बार-बार शुरू होकर बंद हो रहा है। मैं पहले kubectl describe pod से events, पिछली state, exit code और कारण देखता हूं। अगर exit code 137 और OOMKilled है, तो memory limit कम है या app में memory leak है। फिर kubectl logs में previous flag लगाकर बंद हुए container के logs देखता हूं, जहां अक्सर कोई missing environment variable या config की गलती दिखती है। Liveness probe भी जांचता हूं, क्योंकि बहुत जल्दी चलने वाला probe ठीक app को भी बार-बार restart करवा सकता है।

Rolling deployment में instances धीरे-धीरे कुछ-कुछ करके बदले जाते हैं। यह Kubernetes का default है और extra capacity नहीं चाहिए, पर कुछ समय पुराना और नया version साथ चलते हैं। Blue-green में पूरा नया environment तैयार करके traffic एक साथ बदला जाता है, इसलिए rollback बहुत तेज़ है, पर दोगुनी capacity लगती है। Canary में पहले थोड़े से users को नया version मिलता है और metrics ठीक रहें तो धीरे-धीरे बढ़ाया जाता है। Payments जैसे जोखिम वाले बदलाव के लिए मैं canary चुनता हूं।

Secrets कभी Git, Docker image या pipeline logs में नहीं जाते। मैं इन्हें AWS Secrets Manager या Vault जैसे secrets manager में रखता हूं, और हर service को IAM role से सिर्फ़ अपने secrets पढ़ने की अनुमति होती है। Development, staging और production के secrets अलग रहते हैं, ताकि एक environment की चूक दूसरे तक न पहुंचे। Pipeline में secrets masked रहते हैं। जहां हो सके, database passwords की automatic rotation रखता हूं, और Git में गलती से कोई key चली जाए तो उसे तुरंत बदलता हूं।

मैं df -h से देखता हूं कि कौन सा filesystem भरा है, और df -i से कि कहीं inodes तो ख़त्म नहीं हुए। फिर du से बड़े directories ढूंढता हूं। अक्सर वजह बड़ी log files, पुराने Docker images या core dumps होती हैं। अगर df भरा दिखाए पर du में उतना न मिले, तो lsof से वे files देखता हूं जो delete हो चुकी हैं पर कोई process उन्हें खुला रखे है, और उस service को restart करता हूं। स्थायी हल के लिए log rotation और disk usage का alert लगाता हूं।

एक रात हमारी payments API लगभग एक तिहाई requests पर errors देने लगी। मैंने alert acknowledge किया, incident channel खोला और support के लिए हर पंद्रह मिनट पर update देना शुरू किया। Dashboards से पता चला कि errors उसी समय शुरू हुए जब database connection pool भर गया था, और कुछ घंटे पहले एक release हुआ था जिसने connections ठीक से बंद नहीं किए। मैंने पिछले version पर rollback किया और errors रुक गए। अगले दिन postmortem में हमने connection pool की monitoring और load test जोड़ा।

शुरुआती दिनों में मैंने terraform apply उस workspace पर चला दिया जिसे मैं staging समझ रहा था, और उससे production की एक queue delete हो गई। एक background job fail होने लगा। मैंने तुरंत अपने lead को बताया, queue दोबारा बनाई और रुके हुए messages फिर से भेजे। असर कुछ घंटों का रहा। इसके बाद हमने production के लिए अलग credentials रखे, plan की review के बिना apply पर रोक लगाई और pipeline के ज़रिये ही apply करना शुरू किया। मैंने उसी दिन सीखा कि भरोसा सिर्फ़ सावधानी पर नहीं, व्यवस्था पर होना चाहिए।

हमारे developers servers पर SSH करके scripts से deploy करते थे, और containers व pipelines को अतिरिक्त काम मानकर मना करते थे। मैंने सबको एक साथ बदलने के बजाय एक ऐसी टीम चुनी जो सबसे ज़्यादा deploy करती थी, और उनके लिए पूरी pipeline ख़ुद बनाई। कुछ हफ़्तों में उनका deploy का समय काफ़ी घट गया और रात की गड़बड़ियां कम हुईं। उसी टीम ने बाकी टीमों को demo दिया। उसके बाद दूसरी टीमें ख़ुद पूछने लगीं, और मैंने एक template बनाया ताकि बदलाव आसान हो।

मुझे इसमें कोई दिक्कत नहीं है। पिछले दो साल से मैं हर चौथे हफ़्ते on-call पर रहता हूं। मैं इसे गंभीरता से लेता हूं: laptop और charger साथ रहता है, तय समय में जवाब देने की स्थिति में रहता हूं और उस हफ़्ते लंबी यात्रा नहीं रखता। मेरा मानना है कि अच्छा on-call वह है जिसमें बार-बार बेकार alerts न आएं, इसलिए मैं हर incident के बाद runbook और alerts सुधारने पर ध्यान देता हूं। बस यह जानना चाहूंगा कि रात के incidents के बाद आराम या compensation की क्या नीति है।

मैंने आपके engineering blog पर पढ़ा कि आप virtual machines से Kubernetes पर जा रहे हैं और एक internal developer platform बना रहे हैं, ताकि product टीमें बिना ticket के ख़ुद deploy कर सकें। यही काम मुझे सबसे ज़्यादा पसंद है। अपनी मौजूदा कंपनी में मैंने deployment templates और self-service environments बनाए, जिससे developers का इंतज़ार काफ़ी कम हुआ। यहां यह काम बड़े स्तर पर और कई टीमों के लिए होगा। मैं ऐसी टीम में सीखना चाहता हूं जहां platform को product की तरह बनाया जाता है।

मेरे पास DevOps में कुछ साल का अनुभव है, ज़्यादातर AWS और Kubernetes पर, जिसमें production systems का on-call भी शामिल है। इस भूमिका में Kubernetes platform और observability stack की पूरी ज़िम्मेदारी जुड़ती है। इसलिए मैं अपनी current CTC से उचित बढ़ोतरी चाहता हूं, जो इस स्तर की भूमिकाओं के आम दायरे में हो, और current CTC की जानकारी दे सकता हूं। मेरा notice period तीस दिन का है, और handover की योजना मैंने पहले से सोच रखी है।