3 Punkte von GN⁺ 2025-10-21 | 1 Kommentare | Auf WhatsApp teilen
  • Postman erlebte aufgrund eines globalen Cloud-Problems vorübergehend eine Serviceunterbrechung
  • Die Störung wurde durch ein Problem des Cloud-Providers verursacht und führte bei vielen Nutzern zu Funktionsfehlern sowie vorübergehend nicht möglicher Verbindung
  • Das Engineering-Team führte Wiederherstellungsarbeiten in Echtzeit durch, und der Service erholte sich schrittweise
  • Störungen in einzelnen Suchfunktionen sowie ein Cross-Dependency-Problem wurden kontinuierlich überwacht und behoben
  • Der Ausfall ist behoben und der reguläre Service wurde wiederhergestellt; die zusätzliche Stabilitätsüberwachung läuft weiter

Zeitachse der Postman-Dienststörung und Wiederherstellung

Störungserkennung und Auswirkungen (20. Okt. 05:39 ~ 05:52 PDT)

  • Bei erhöhter Fehlerrate traten bei Postman funktionale Probleme auf
  • Die Ursache der Störung lag in einem schwerwiegenden Problem des Cloud-Service-Providers
  • Das Postman-Team arbeitete mit dem Cloud-Anbieter zusammen, um eine rasche Wiederherstellung zu erreichen

Teilweise Wiederherstellung und Überwachung (20. Okt. 05:56 ~ 17:17 PDT)

  • Wiedererholung einzelner Systeme wurde beobachtet
  • Mehrere Services wurden kontinuierlich mit Leistungsüberwachung überwacht, während umfassende Wiederherstellungsarbeiten fortgeführt wurden
  • Die Wiederherstellung der meisten Funktionen wurde bestätigt, und der Fokus lag auf kontinuierlicher Überwachung, um weitere Störungen zu vermeiden

Vollständige Wiederherstellung und Normalisierung des Dienstes (20. Okt. 19:00 ~ 20:51 PDT)

  • Bei einigen Services bestanden noch sporadische Probleme, aber die Mehrzahl der Systeme erholte sich stabil
  • Cross-Dependency-Fehler sowie Probleme mit der Suchfunktion wurden ebenfalls schrittweise behoben
  • Nach der vollständigen Behebung aller Probleme und der kompletten Dienstwiederherstellung wurde zusätzliche Überwachung zur Sicherung der Stabilität durchgeführt

Zusammenfassung und Implikationen

  • Postman ist stark von der Cloud-Infrastruktur abhängig, daher ist es direkt von globalen Ausfällen betroffen
  • Auch bei ähnlichen Tools oder scheinbar lokalen Diensten wird die Notwendigkeit betont, auf Cloud-Infrastruktur-Ausfälle vorbereitet zu sein
  • Bei einer Störung sind Echtzeit-Überwachung und Kommunikation entscheidend für Wartung und Kundenvertrauen
  • Während einer schrittweisen Wiederherstellung sind die schnelle Reaktion des Teams und transparente Mitteilungen entscheidend
  • Die Bedeutung eines Monitoring-Systems zur Sicherstellung des ordnungsgemäßen Betriebs aller Services wurde erneut hervorgehoben

1 Kommentare

 
GN⁺ 2025-10-21
Hacker News Kommentar
  • Ich frage mich, ob ich etwas verpasse, wenn ich Postman nicht nutze; als Alternative verwende ich die Funktion „Edit and Resend“ von Firefox und für wiederverwendbare Beispiele klassische curl-Skripte.
    • Bei uns im Unternehmen wird Postman etwas genutzt: Wir teilen eine Collection-Datei mit vielen Requests inklusive Headern und Body, sodass Entwickler sie einfach laden und auf ihren eigenen Servern testen können; der Serverwechsel geht mit einem Klick. Als Alternative kämen curl-Skripte mit Umgebungsvariablen in einem Git-Repository infrage, und auch Nicht-Entwickler führen Tests mit Postman aus.
    • Nicht nur Postman, sondern solche Clients können auch verschiedenste Requests vorbereiten und speichern, um Test-Suiten zu erstellen. Manche bieten zudem Skript-Erstellung, Request-Chaining usw. an. Es ist ein ähnliches Konzept wie der Unterschied zwischen Texteditor und IDE, also ist es letztlich eine Frage dessen, was man wirklich braucht.
    • Am bequemsten ist, dass beim Einfügen einer URL die Parameter automatisch geparst werden und sich in der UI alle Werte einfach bearbeiten lassen; außer dem ist es im Grunde nicht mehr als das bekannte curl.
    • Heutzutage arbeite ich mit Jupyter Notebook und requests; letztlich fühlt es sich selbst bei Postman wie Programmierung in einer eingeschränkten Sprache an, wenn man Requests in eine Collection kodiert.
  • Solche Apps auf Electron und Cloud zu setzen, überrascht mich ebenfalls; eine 10-MB-TUI-App hätte es im Terminal getan. Als Alternative gibt es übrigens posting.sh.
    • Die 10-MB-TUI-Argumentation kann ich gut nachvollziehen. Heute sind Electron-Apps im Bereich mehrerer Gigabyte groß. Zum Vergleich: Das vim-Paket ist 2,3 MB, curl 1,2 MB und Lua 362 KB.
    • Der Grund für Electron liegt darin, dass es oft als Chrome-Extension begann und sich dann zu einer Standalone-Lösung entwickelt hat.
    • Ich habe hurl (https://hurl.dev/) schon ein paar Jahre verwendet, aber die Dateien wurden nie aufgeräumt und es häuften sich nur Textdateien im Ordner an; diesmal will ich posting.sh einmal ausprobieren.
    • Ich habe nach einer Postman/Bruno/foo-Alternative gesucht, die ich auf SSH-Servern oder in Remote-Containern von VS Code nutzen kann; posting.sh passt da genau.
  • RubyMine und die zugehörigen JetBrains-IDEs (auch verwandte Produkte) haben im Menü einen starken HTTP-Client eingebaut (Tools -> HTTP Client), und seit Postman komplexer geworden ist, passt das gut, wenn man nur einfache Web-Requests braucht. Das soll keine Herabsetzung derjenigen sein, die Postman mögen, eher das Gefühl, dass es für meine Anforderungen zu viel geworden ist.
    • Der HTTP-Client von JetBrains ist wirklich gut: Wenn man curl-Befehle einfügt, werden sie automatisch umgewandelt und formatiert, und die geänderten Teile lassen sich wieder als curl kopieren.
  • Genau deshalb wurde Yaak (https://yaak.app) entwickelt: komplett offlinefähig, ohne Telemetrie, Open Source und mit Git-Integration.
    • Ich bin neugierig auf Yaaks kommerzielles Lizenzmodell: Wenn der Kauf der Pro-Lizenz auf einem „Good-Faith-Prinzip“ basiert, interessiert mich, wie stark es sich von der MIT-Lizenz unterscheidet. Ich beschäftige mich schon lange mit kommerziellen Open-Source-Lizenzen und frage mich immer, was in welcher Situation sinnvoller ist.
    • Ich nutze Yaak seit 6 bis 9 Monaten. Anfangs baute ich es direkt aus dem Source, inzwischen bin ich zu einem bezahlten Nutzer geworden. Als ich gesehen habe, dass Yaak kürzlich die Zahlen zu Abonnenten und Umsatz als Open Metrics offenlegt (open metrics), fand ich das als transparentes Betriebsmodell wirklich positiv.
    • Aktuell nutze ich Bruno und habe auch den Vergleich zwischen Bruno und Yaak gelesen. Wenn Bruno alle Funktionen bietet, die ich brauche, würde mich interessieren, was Yaak im Vergleich zu Bruno überhaupt noch unterscheidet.
    • Ich frage mich, ob nach dem Bau und Verkauf von Insomnia ein neues Konkurrenz-Tool entstanden ist, und ob es bei dem Deal irgendwelche Beschränkungen gab.
    • Ich habe Insomnia vor der Übernahme jahrelang sehr gemocht, daher freut es mich ungemein, dass Yaak als geistiger Nachfolger erscheint; ich drücke Greg die Daumen.
  • Je nach Verwendungszweck braucht man oft keine separate App. JetBrains (Info), Visual Studio (Info), VSCode (Info) unterstützen ebenfalls HTTP-Dateien.
    • Für VSCode ist das ein Plugin eines anonymen Entwicklers; als eingebaute Funktion wirkt es dadurch schwer nachvollziehbar.
    • In unserer Organisation nutzt auch QA nicht nur Entwickler häufig HTTP-APIs; daher erfüllt Bruno diese Rolle derzeit gut.
    • Da das HTTP-Dateiformat je nach Produkt nicht vollständig identisch ist, nutzt unser Team hurl, das QA-Team bevorzugt das Robot Framework, und einige nutzen Bruno.
    • Je größer eine Organisation wird, desto mehr werden umfangreiche Postman Collections für API-Dokumentation, Regressionstests und QA eingesetzt, insbesondere mit hoher Abhängigkeit von der Postman-JavaScript-Bibliothek und individuellem Custom Code.
  • Ich denke, die meisten Leute haben akzeptiert, dass Postman zunehmend ausufert, indem immer mehr Funktionen dazukommen und es online-abhängig wird.
    • In unserem Unternehmen wurde nach der Umstellung von Postman auf Online-Mode allen Mitarbeitenden ein Löschticket geschickt; in der aktuellen IT-Wikiseite ist es als verbotenes Softwareprodukt gelistet. Früher wurde es wirklich überall verwendet.
    • Da Postman zu einem Branchenstandard geworden ist, haben sich wohl alle angepasst: Auch Business-Seiten nutzen Postman und das Teilen von Collections ist Standard. Ich mag Postman nicht gern, aber wenn ich API-Arbeit teilen muss, muss ich es zwangsläufig nutzen. Es ist gut für das Postman-Geschäft, aber es kommt mir nicht so vor, als wäre es für jeden Nutzer gut.
  • Ich habe eine sehr einfache, schlanke YAML-basierte Postman-Alternative namens yapi (https://github.com/jamierpond/yapi) gebaut. So kann man sie wie folgt nutzen:
    yapi -c ./users.yapi.yaml
    
    Ein YAML-Dateibeispiel (einschließlich Schema, url, method, path sowie der Art der Angabe von Query-Parametern) und ein einfaches Ausführen von nur yapi, um mit fzf die Konfigurationsdatei zu finden, ist möglich.
    • Es ist ein wirklich interessantes Konzept und ich glaube, es lässt sich gut in den Workflow integrieren, wenn man sich daran gewöhnt hat. Warum die GitHub-Statistiken aber so niedrig sind, frage ich mich trotzdem; vermutlich, weil alle ohnehin Postman nutzen.
  • Ich habe lange Paw verwendet, aber es wurde vor einigen Jahren mit RapidAPI zusammengelegt. Für eine kleine App macht sie ihren Job ausgezeichnet. Aktuell kombiniere ich ein Phoenix LiveBook Notebook mit dem Req-Paket; dabei kann ich direkt meine gewünschte Sprache nutzen und Datenverarbeitung flexibel gestalten. Falls man Elixir nicht kennt, können Jupyter oder andere Notebook-Systeme eine Alternative sein.
  • Bruno plus Git passt zu unserem Team perfekt: Man kann Collections im Repository versionieren und ganz offline ohne externe Abhängigkeiten arbeiten; hätte ich das früher so gemacht, hätte ich es schon lange tun sollen.
    • Beim Import durch Einfügen von curl gab es zwar einen seltsamen Bug, aber der ist behoben; im Übrigen bin ich zu 100 % zufrieden.
  • Ich habe die Postman-Nutzung seit 2018 vollständig eingestellt. Dass man sich zur Ausführung von API-Abfragen anmelden muss, fand ich zu lästig; ehrlich gesagt war auch die Usability nicht besonders ansprechend.