मुझे लगा था कि Postman सिर्फ मेरे कंप्यूटर पर ही काम करता है, लेकिन अभी सेवा में बाधा आई है

 (status.postman.com)
3 पॉइंट द्वारा GN⁺ 2025-10-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Postman में एक वैश्विक क्लाउड समस्या के कारण अस्थायी सेवा बाधित होने की स्थिति देखी गई।
  • यह आउटेज क्लाउड प्रोवाइडर की समस्या के कारण था, जिससे कई उपयोगकर्ताओं को फीचर त्रुटियों और बीच-बीच में कनेक्शन फेल होने की स्थिति का सामना करना पड़ा।
  • इंजीनियरिंग टीम ने रियल-टाइम में रिकवरी कार्य जारी रखा और सेवा धीरे-धीरे बहाल हुई।
  • कुछ सर्च फीचर में गड़बड़ी और क्रॉस-डिपेंडेंसी मुद्दों की भी लगातार मॉनिटरिंग व समाधान किया गया।
  • वर्तमान में आउटेज सुलझ चुका है और सेवा सामान्य रूप से बहाल है; अतिरिक्त स्थिरता मॉनिटरिंग जारी है।

Postman सेवा आउटेज टाइमलाइन और रिकवरी प्रक्रिया

समस्या की पहचान और प्रभाव (Oct 20, 05:39 ~ 05:52 PDT)

  • Postman में त्रुटि दर बढ़ने के कारण फीचर-स्तरीय समस्या दिखी।
  • इस घटना का कारण क्लाउड सेवा प्रदाता में एक बड़ा मुद्दा था।
  • Postman टीम ने क्लाउड वेंडर के साथ मिलकर तेज सामान्यीकरण के लिए तुरंत कार्रवाई की।

आंशिक सेवा पुनर्प्राप्ति और मॉनिटरिंग (Oct 20, 05:56 ~ 17:17 PDT)

  • कुछ सिस्टमों के रिकवर होने का रुझान देखा गया।
  • कई सेवाओं की लगातार परफॉर्मेंस मॉनिटरिंग करते हुए व्यापक रिकवरी प्रयास जारी रखे गए।
  • अधिकांश फीचरों के ठीक होने की पुष्टि हो गई और लगातार मॉनिटरिंग से अतिरिक्त गड़बड़ियों की रोकथाम पर फोकस किया गया।

पूर्ण रिकवरी और सेवा सामान्यीकरण (Oct 20, 19:00 ~ 20:51 PDT)

  • कुछ सेवाओं में इंटरमिटेंट इश्यू अभी बाकी थे, लेकिन कई सिस्टम स्थिर रूप से बहाल हो चुके थे।
  • क्रॉस-डिपेंडेंसी एरर और सर्च फीचर से जुड़ी समस्याएँ भी क्रमशः हल की गईं।
  • सभी मुद्दे सुलझाने और पूर्ण सेवा पुनर्स्थापन के बाद, स्थिरता सुनिश्चित करने के लिए अतिरिक्त मॉनिटरिंग की गई।

सारांश और मुख्य निष्कर्ष

  • Postman की क्लाउड निर्भरता अधिक होने के कारण यह सीधे वैश्विक आउटेज से प्रभावित होता है।
  • भविष्य में ऐसे टूल्स या लोकल-आधारित सेवाओं के लिए भी क्लाउड इंफ्रास्ट्रक्चर फेल्योर के प्रति तैयारी की जरूरत स्पष्ट होती है।n- किसी भी आउटेज के दौरान रियल-टाइम इश्यू मॉनिटरिंग और कम्युनिकेशन मेंटेनेंस तथा ग्राहक भरोसे के लिए बेहद अहम हैं।
  • जब सेवा रिकवरी चरणबद्ध तरीके से हो रही हो, तब टीम की तेज़ प्रतिक्रिया और पारदर्शी अपडेट बहुत महत्त्वपूर्ण हैं।
  • यह फिर याद दिलाता है कि सभी सेवाओं का सही ऑपरेशन सुनिश्चित करने के लिए एक मजबूत मॉनिटरिंग फ्रेमवर्क स्थापित करना आवश्यक है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-21
Hacker News टिप्पणी
  • Postman नहीं इस्तेमाल करने पर शायद मैं कुछ मिस कर रहा हूँ, इसलिए पूछना चाहता हूँ; विकल्प के तौर पर मैं Firefox की "Edit and Resend" फीचर का उपयोग करता हूँ और reuse उदाहरणों के लिए पारंपरिक curl scripts का इस्तेमाल करता हूँ
    • हमारी कंपनी में Postman थोड़ा-सा उपयोग होता है; headers और bodies वाली बहुत-सी requests वाली collection फाइल शेयर करके developers आसानी से load कर लेते हैं और अपने-अपने servers पर टेस्ट रन कर सकते हैं, server बदलना भी एक क्लिक में हो जाता है। विकल्प के रूप में environment variables के साथ curl scripts वाली एक git repository हो सकती है, और non-developer लोग भी Postman से टेस्ट रन कर लेते हैं
    • Postman ही नहीं, ऐसे clients मौजूद हैं जो कई requests को एक साथ तैयार करके सेव कर test suite बना सकते हैं। कुछ में script writing, request chaining जैसी capabilities भी मिलती हैं। यह text editor और IDE के बीच का वही concept है; आख़िरकार यह आपकी जरूरत के स्तर पर निर्भर करने वाला चयन है
    • सबसे सुविधाजनक फीचर शायद यही है कि URL paste करने पर parameters स्वतः parse होकर सीधे UI में आसानी से बदलने लायक हो जाते हैं; बाकी में यह अंततः familiar curl से अलग नहीं लगता
    • आजकल मैं jupyter notebook और requests के साथ काम करता हूँ; यानी Postman में भी जब requests को collection के रूप में codefy करने लगते हैं तो लगता है कि सीमित language में programming कर रहे हैं
  • मुझे यह देखकर हैरानी होती है कि ऐसे app भी Electron और cloud पर चले गए; शायद terminal में 10MB का TUI app ही पर्याप्त होता, वैसे posting.sh नाम का एक विकल्प मौजूद है
    • 10MB वाले TUI app की बात से मैं भी सहमत हूँ; आजकल Electron apps की दुनिया में size कई gigabytes तक जा चुका है। उदाहरण के लिए vim package 2.3MB, curl 1.2MB और lua 362KB है
    • Electron उपयोग करने का कारण शायद यही है कि ये शुरुआत में Chrome extension थे और बाद में standalone form में evolve हुए
    • मैंने hurl(https://hurl.dev/) को कई साल use किया, लेकिन फाइलें organize नहीं होने से फोल्डर में केवल text files ही जमा हो रही हैं; इस बार posting.sh को एक बार try करने की सोच रहा हूँ
    • SSH server या VS Code के remote container में use करने के लिए Postman/Bruno/foo replacement खोज रहा था, posting.sh बिल्कुल ठीक बैठता है
  • RubyMine तथा JetBrains IDEs (related products) में मजबूत HTTP client (Tools -> HTTP Client) built-in है; Postman जितना complex हो गया है, उससे पहले सिर्फ simple web requests चाहिए हों तो यह बेहतर फिट होता है। यह Postman पसंद करने वालों को हतोत्साहित करने के लिए नहीं है, बस मुझे लगता है मेरे use case की तुलना में थोड़ी ज्यादा चीज़ें हैं
    • JetBrains का HTTP client सच में बढ़िया है; curl कमांड paste करने पर auto convert और formatting हो जाती है, और बदला हुआ हिस्सा फिर से curl के रूप में copy भी किया जा सकता है
  • शायद इसी कारण Yaak(https://yaak.app) बनाया गया है, पूरी तरह offline सक्षम, telemetry नहीं, open source और Git integration सपोर्ट करता है
    • Yaak की commercial license structure को लेकर जिज्ञासा है; अगर pro license खरीदना 'good-faith principle' पर based है तो MIT license से फर्क क्या है? Open source commercial licensing में कौन-सा मॉडल कब बेहतर काम करता है, यह हमेशा जानना चाहता हूँ
    • मैं 6-9 महीने से Yaak उपयोग कर रहा/रही हूँ; शुरुआत में source से सीधे build किया था, अब paid user बन गया हूँ। हाल ही में जब Yaak ने अपने subscribers और revenue को open metrics के रूप में सार्वजनिक किया, तो transparent operating तरीका देखने में अच्छा लगा
    • अभी मैं Bruno use कर रहा हूँ और Yaak vs Bruno comparison material भी पढ़ी है; यदि Bruno में मेरी सभी ज़रूरत की features पहले से हैं, तो Bruno की तुलना में Yaak का अलग फर्क क्या होगा, सुनना चाहूँगा
    • Insomnia को बना कर बेचने के बाद क्या उन्होंने नया competitor tool बनाया? पूछना चाहता हूँ कि deal के समय कोई restriction थी या नहीं
    • Insomnia acquisition से पहले मैं उस product का बड़ा fan था, इसलिए Yaak का spiritual successor की तरह आना बहुत अच्छा लगा; Greg को support करता हूँ
  • उपयोग के हिसाब से अलग app की ज़रूरत नहीं भी पड़ती, JetBrains(जानकारी), Visual Studio(जानकारी), VSCode(जानकारी) सभी http file support करते हैं
    • VSCode वाला plugin एक anonymous developer ने बनाया है, इसलिए उसे built-in feature की तरह देखना आसान नहीं
    • हमारे संगठन में developers के अलावा QA भी बहुत बार http api use करती है, इसलिए अभी Bruno वही role अच्छी तरह निभा रहा है
    • प्रत्येक product का http file format पूरी तरह समान नहीं होता, इसलिए हमारी team में hurl का उपयोग करते हैं, QA टीम robot framework को ज्यादा पसंद करती है, और कुछ Bruno का उपयोग करते हैं
    • organization बड़ा होने पर बड़ी पोस्टमैन collections को API documentation, regression testing और QA के लिए बहुत use किया जाता है, खासकर postman javascript library और custom code पर dependency बड़ी होती है
  • अधिकांश लोगों को लगता है कि Postman धीरे-धीरे बढ़ते features के कारण bloated और online-dependent बन गया है और वे इसे accept कर चुके हैं
    • कंपनी में Postman online shift होने के बाद सभी कर्मचारियों को Postman हटाने का मेल गया, और वर्तमान IT टीम ने इसे wiki में banned software के रूप में list कर दिया; पहले यह सच में हर जगह use होता था
    • जैसे-जैसे Postman industry standard tool बन रहा है, सभी ने उसे adopt कर लिया है; business side के लोग भी Postman इस्तेमाल करते हैं और collection sharing default बन गया है। मुझे Postman पसंद नहीं, लेकिन जब API काम share करना हो तो मजबूरी में use करना पड़ता है। Postman का business शायद अच्छा चल रहा हो, लेकिन मुझे लगता नहीं कि यह हर user के लिए अच्छा है
  • एक बहुत ही सरल lightweight yaml-based Postman alternative के रूप में मैंने yapi(https://github.com/jamierpond/yapi) बनाया है, नीचे की तरह use कर सकते हैं 
    yapi -c ./users.yapi.yaml
    yaml फाइल उदाहरण (schema, url, method, path, query parameters specify करने का तरीका शामिल), सिर्फ yapi चलाने पर fzf से config file आसानी से खोजी जा सकती है
    • concept सच में दिलचस्प है और workflow में आराम से अभ्यस्त हो जाएँ तो शायद बढ़िया काम करेगा, लेकिन देखना चाहूँगा कि GitHub पर इसके आंकड़े इतने low क्यों हैं—शायद सब अभी भी Postman ही use करते हैं
  • कई साल तक मैंने Paw का इस्तेमाल किया, लेकिन पिछले कुछ वर्षों पहले RapidAPI में merge हो गया; छोटा app होते हुए भी अपना role बढ़िया ढंग से संभालता था। अभी मैं Phoenix LiveBook notebook और Req package का combo use कर रहा हूँ, अपनी चुनी हुई language सीधे handle कर सकता हूँ और data transformation भी स्वतंत्रता से कर सकता हूँ। अगर Elixir नहीं आता तो jupyter या अन्य notebook systems विकल्प बन सकते हैं
  • Bruno + git का combo हमारी team के लिए perfect है, collections को repo के अंदर version control करते हैं और बिना external dependency के offline run हो जाते हैं, wish हमने पहले ही यह कर लिया होता
    • curl import में एक अजीब bug था, लेकिन resolve हो गया; बाकी सबमें मैं 100% satisfied हूँ
  • हमने 2018 के बाद Postman का पूरा उपयोग बंद कर दिया, क्योंकि API query करने के लिए login करना पड़ता था—बहुत असुविधाजनक लगा। सच कहूँ तो usability भी खास आकर्षक नहीं लगी