Fly.io-Störung behoben

 (status.flyio.net)
1 Punkte von GN⁺ 2024-11-27 | 1 Kommentare | Auf WhatsApp teilen
  • Die Fly.io-Statusseite steht derzeit auf All Systems Operational, und zentrale Komponenten wie App-Ausführung, Dashboard, Machines API und regionale Verfügbarkeit sind in Betrieb
  • Die Elevated API Errors vom 1. Juli 2026 wurden um 07:50 UTC behoben, nachdem Fehler in der GraphQL API und bei der Verarbeitung von Hintergrundaufgaben korrigiert worden waren
  • Delayed Metrics vom 30. Juni führten in den Dashboards auf fly-metrics.net bei einigen Kunden zu verzögerten oder fehlenden Metriken und normalisierten sich nach dem Abarbeiten des Backlogs und dem Kapazitätsausbau
  • Diese Statusseite ist für Updates zu globalen Störungen gedacht und umfasst daher keine Hardwareausfälle mit begrenzter Auswirkung oder isolierte Infrastrukturereignisse
  • App-spezifische Auswirkungen sollten auf der personalized status page im Fly-Organization-Dashboard geprüft werden; für interne Incidents und Aktivitäten wird auf das Infra Log verwiesen

Aktueller Servicestatus

  • Die Fly.io-Statusseite befindet sich derzeit im Status All Systems Operational
  • Als betriebsbereit markierte Hauptpunkte sind Customer Applications, Dashboard, Machines API, Regional Availability, Persistent Storage (Volumes), Deployments, Remote Builds, Logs, Metrics, SSL/TLS Certificate Provisioning, UDP Anycast, Fly Machine Image Registry 1·2, Extensions, Upstash for Redis, DNS, Billing und Managed Postgres
  • Auch die Regionalstatus sind als betriebsbereit markiert; betroffen sind die Regionen AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD und YYZ

Geltungsbereich der Statusseite

  • Diese Seite dient Updates zu global incidents
  • Updates zu alltäglichen Hardwareausfällen mit begrenzter Auswirkung oder isolierten Infrastrukturereignissen sind nicht enthalten
  • Eine personalisierte Ansicht aller Ereignisse, die sich auf Apps auswirken können, sollte auf der personalized status page im Fly-Organization-Dashboard geprüft werden
  • Für interne Incidents und andere Aktivitäten wird auf das Infra Log verwiesen

1. Juli 2026: Elevated API Errors

  • Elevated API Errors wurden am 1. Juli um 07:50 UTC als Resolved markiert
  • Um 06:14 UTC begann die Untersuchung von elevated errors in der GraphQL API und bei der Verarbeitung von Hintergrundaufgaben
  • Um 06:27 UTC wurde die Ursache identifiziert und die Behebung eingeleitet
  • Um 07:05 UTC wurde der Fix ausgerollt, und es waren keine elevated API errors mehr zu sehen
    • Einige Dashboard-Aktionen konnten verzögert sein, während die Hintergrundverarbeitung aufholte
  • Um 07:26 UTC hatten die Hintergrundaufgaben aufgeholt, und die API wurde bei voller Betriebsfähigkeit weiter überwacht

30. Juni 2026: Delayed Metrics und Egress-IP in SIN/NRT

  • Delayed Metrics wurden am 30. Juni um 22:19 UTC behoben
  • Es gab ein Problem mit kundenbezogenen Metriken in den Dashboards auf fly-metrics.net, wodurch Nutzer verzögerte oder fehlende Metriken sehen konnten
  • Probleme auf mehreren Hosts verzögerten die Metrikerfassung; als Ursache wurde resource contention auf einigen metrics ingestion hosts behandelt
  • Zur Abarbeitung des Backlogs wurde der Durchsatz des Metrics-Clusters erhöht; außerdem wurden Ingestion-Traffic neu ausbalanciert und zusätzliche Verarbeitungskapazität bereitgestellt
  • Am 30. Juni um 19:58 UTC hatten fast alle Metriken aufgeholt, nur wenige Metriken aus sin und syd standen noch aus
  • Egress IP issues in SIN and NRT wurden am 30. Juni um 14:03 UTC behoben
    • Einige Machines mit Egress-IP in SIN und NRT konnten vorübergehend Verbindungen verlieren oder Leistungseinbußen erfahren

26.–25. Juni 2026: Netzwerk-, Deployment- und Control-Plane-Vorfälle

  • IPv6 Connectivity Issues in EWR wurden am 26. Juni um 23:48 UTC behoben
    • Ein Problem mit der IPv6-Netzwerkkonnektivität beim Upstream-Provider trat in EWR auf
    • Apps mit Machines auf betroffenen Hosts konnten bei Verbindungen zu bestimmten IPv6-Zielen beeinträchtigt sein
  • Network maintenance in YYZ war eine geplante Wartung vom 26. Juni, 08:00–09:00 UTC, und wurde abgeschlossen
    • Innerhalb des Wartungsfensters wurde mit bis zu 15 Minuten Verbindungsverlust gerechnet
  • Deploys defaulting to Fly-hosted Builders wurden am 25. Juni um 15:38 UTC behoben
    • Während der Untersuchung verzögerter Bereitstellung von Depot backed builders wurde die Standardstrategie von fly deploy auf Fly-hosted builders umgestellt
    • Nutzer konnten mit fly deploy --depot=true Depot-basierte Deployments erzwingen; später waren mit fly deploy --depot=false auch Fly-builder-basierte Deployments möglich
  • Elevated control plane latency wurden am 25. Juni um 15:18 UTC behoben
    • Es kam zu erhöhter Control-Plane-Latenz und Sättigung mit Auswirkungen auf die Regionen BOM und NRT
    • Apps mit Machines in diesen Regionen konnten längere Antwortzeiten und mögliche 502 errors erleben

24.–17. Juni 2026: Nordamerika-, SIN/NRT-Netzwerk und Log-Suche

  • Degraded networking in North America wurde am 24. Juni um 06:57 UTC behoben
    • Eine Verschlechterung der Netzwerkleistung zwischen nordamerikanischen Standorten wurde aufgrund eines Upstream-Incidents untersucht
    • Einige Machines konnten auf bestimmten Routen Paketverlust und höhere Latenz sehen
    • Einige 6PN Private Networking-Verkehre von und nach der Region LAX waren weiterhin betroffen
  • Network issues in SIN, NRT wurden am 22. Juni um 21:56 UTC behoben
    • Der Upstream-Provider hatte Netzwerkprobleme in den Regionen SIN und NRT; Apps in diesen Regionen konnten nicht erreichbar sein oder hohen Paketverlust erleben
  • SIN, NRT network issues wurden am 22. Juni um 19:48 UTC behoben
    • Zunächst wurde ein Upstream-Netzwerkproblem in der Region SIN untersucht; später konnten auch Apps in der Region NRT Probleme beim Erreichen bestimmter Ziele haben
  • Log search unavailable wurde am 19. Juni um 21:53 UTC behoben
    • Betroffen waren die Fly-Metrics-Log-Suchpanels und die zuerst zurückgegebenen historischen Application-Logs im Befehl fly logs
    • fly logs-Streaming, die Seite Live Logs im Dashboard und die Fly Log Shipper services funktionierten normal
    • Nach dem Fix wurden historische Logs per Backfill ergänzt, und die meisten in der Warteschlange befindlichen historischen Logs wurden durchsuchbar
  • Network Issues in SIN wurden am 17. Juni um 04:55 UTC behoben
    • Es gab ein Problem mit der Netzwerkkonnektivität in der Region SIN, und gehostete Apps konnten nicht verfügbar sein
    • Einige Machines waren nicht erreichbar, und einige Managed-Postgres-Cluster konnten bei Fail-over oder Update scheitern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-27
Meinungen auf Hacker News

  • Meine auf fly.io gehostete Website war vor etwa 6 Stunden 5 Minuten lang down, kam dann sofort wieder hoch und läuft seitdem durchgehend normal.
    Ein kostenloser Monitoring-Dienst prüft nur alle 5 Minuten, daher könnte er kürzere Ausfälle übersehen haben, aber insgesamt war es ziemlich stabil.

    • Daten über mehrere Monate hinweg wären interessant.
      Auch die Uptime der Anwendung ist instabil, aber schlimmer waren Fehlschläge bei fly deploy, die ohne erkennbaren Grund auftraten. Manchmal blieb ein Layer einfach hängen und schlug schließlich fehl; wenn man 1–2 Stunden später denselben Befehl ohne Änderungen erneut ausführte, funktionierte es.
      Ich würde gern einen Monitoring-Dienst sehen, der alle 5 Minuten eine Standard-App deployt, also regelmäßig den Befehl fly deploy ausführt, um zu sehen, wie oft Deployments fehlschlagen oder hängen bleiben. Ich schätze, dass etwa 5 % ohne Erklärung fehlschlagen; wenn man nicht viel Zeit hat, ist das ziemlich nervig.
    • Ich überwache fly.io und die Dokumentation extern: https://flyio.onlineornot.com/
      Nach deren Messung scheint es 16 Minuten gedauert zu haben.
    • Bei uns war es ähnlich: etwa 5 Minuten Ausfall, danach wiederhergestellt und seitdem in Ordnung; der Fehler war 501.

  • fly.io hat die Postmortems hier veröffentlicht: https://fly.io/infra-log/
    Die jüngsten Postmortems sind ziemlich interessant und sehr detailliert. 2016 war eine Kernkomponente der Betriebsinfrastruktur von fly.io ein hochsicherer TLS-Server namens consul, der gemeinsamen Zustand nachverfolgte und sowohl Server- als auch Client-Zertifikate authentifizieren musste.
    Wegen der zentralisierten Architektur gab es Skalierungsprobleme, und fly.io entwickelte 2020 als Ersatz corrosion und vergaß consul schnell wieder, konnte es aber nie vollständig entfernen.
    Dann lief im Oktober 2024 der Signaturschlüssel des Root-Keys von consul ab, wodurch alle Verbindungen ausfielen. Da gegenseitige Authentifizierung verwendet wird, ließ sich der Betrieb nicht wiederherstellen, bevor neue SSL-Zertifikate auf der gesamten Hardware verteilt waren. Irgendwie gelang das in 30 Minuten, aber der Dominoeffekt hatte bereits begonnen und legte weitere Schwachstellen der Infrastruktur offen.
    Ein weiterer interner Dienst hatte einen unabhängigen Satz von TLS-Keys, der schon lange abgelaufen war; das fiel jedoch erst auf, als er im Zuge der Neuausstellung der consul-Keys neu gestartet wurde. TCP-Verbindungen, die noch zu Zeiten gültiger Zertifikate aufgebaut worden waren, wurden durch den Neustart getrennt und machten das Problem sichtbar. Währenddessen bombardierte ein Logging-Tool den Netzwerkprovider wie bei einem DDoS. Die Leute, die das Unternehmen gerettet und dabei auch noch die Kunden geschützt haben, als so viel auf einmal schiefging, sind wirklich beeindruckend.

    • Zu diesem Consul-Ausfall zog Fly Infra das Fazit: „Die Lektion ist, dass es keine halben Sachen mehr geben darf.“
      Auf der Karriereseite [1] heißt es dagegen: „Wir glauben nicht wirklich an technische Schulden.“
      Von außen liest sich das wie ein Chor der Widersprüche.
      [1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...

  • Fly.io wirkt wie ein ziemlich zwiespältiger Dienst
    https://news.ycombinator.com/item?id=41917436
    https://news.ycombinator.com/item?id=35044516
    https://news.ycombinator.com/item?id=34742946
    https://news.ycombinator.com/item?id=34229751
    Wenn eine Cloud-Plattform Zuverlässigkeit nicht richtig liefern kann, ist sie meiner Meinung nach ihr Geld nicht wert. Es kann besser sein, einfach einen virtuellen Server zu mieten und die Cloud-Steuer zu sparen

    • Für Experimente oder Hobbyprojekte ist das Wertversprechen hervorragend. Wo sonst kann man für $1.94 im Monat eine unabhängige Instanz starten?
      Allerdings gilt dieser Preis für eine Instanz mit 256 MB RAM (https://fly.io/docs/about/pricing/). Trotzdem kann man darauf durchaus sinnvolle Projekte betreiben. Ein Rust-basierter Webserver wie Rocket benötigt nur etwa 10 MB RAM, und soweit ich gesehen habe, passt auch ein einfacher PHP-Server hinein
    • Die Zuverlässigkeit ist wirklich sehr schlecht. Dass in den letzten Monaten während meiner Demos das Haupt-Dashboard zweimal ausgefallen ist, war einfach absurd
      Ganz zu schweigen von Deployment-Problemen: Fast jeden Tag funktionierte irgendetwas zufällig nicht oder war verzögert
      Wegen der Preiserhöhungen und weil mein Chef mehrmals Probleme bei einem Projekt gesehen hat, das ich auf Fly gehostet hatte, musste ich vor ein paar Monaten wegziehen
      Außerdem haben sie auch den sqlite-Backup-Dienst eingestellt und entfernt. Jetzt bin ich wieder bei GCP und muss mir keine Sorgen mehr über unzählige Ausfälle machen
    • Ich verstehe das Wertversprechen von fly.io nicht wirklich. Trotz der Ausfälle ist das Engineering-Team beeindruckend, aber brauchen wirklich 99,9 % der Entwickler Edge Computing?
      Es gibt viele Services großer Unternehmen, die in einer einzigen AWS-Region laufen und von Millionen Menschen weltweit genutzt werden. Es fühlt sich an wie etwas, das voreilige Optimierung schon als Default ermöglicht
    • Diese Sichtweise ist völlig vernünftig, und ich werde ihr nicht widersprechen. Wir bauen etwas sehr Schwieriges, sind ein relativ neues Unternehmen und haben nicht einmal einen winzigen Bruchteil der Ressourcen der Hyperscaler. Das gilt selbst im Vergleich zu AWS, GCP und OCI zu deren Anfangszeiten
      Wenn man auf maximale Zuverlässigkeit optimiert, ist auch das eine völlig vernünftige Entscheidung. Ich würde nicht behaupten, dass wir 2024 in UE1 besser sind
      Falls es als Kontext hilft: Es können viele Dinge schiefgehen, und das tun sie auch tatsächlich, aber die Art von Ausfall, die man hier am wahrscheinlichsten häufiger sieht, sind Zeiträume, in denen Deployments nicht funktionieren. Dieser Ausfall war ein Deployment-/Orchestrierungs-Ausfall. Vor ein paar Monaten sind wir auf eine Rust-Concurrency-Tretmine getreten und hatten einen kompletten Ausfall des Request-Routings, aber so etwas ist sehr selten
      Ausfälle bei Deployments und Status-Updates sind ebenfalls gravierend, und wenn man, wie wir es empfehlen, fortlaufend auf verschiedene Fly-Machines-Gruppen deployt, kann das die Verfügbarkeit beeinträchtigen, zumal es eine der großen Funktionen der Plattform ist. Ich will das nicht kleinreden
    • fly.io hat in puncto Zuverlässigkeit einen sehr schlechten Ruf, und außerhalb von Hacker News sieht man kaum Bemühungen, dieses Image zu reparieren. Selbst hier scheint der Konsens ungefähr zu sein: „Keine kritischen Workloads auf fly.io betreiben und keine Datenredundanz erwarten“
      Tatsächlich kann man mit Firecracker auf eigenen Bare-Metal-Servern fast dasselbe machen wie fly.io, und das sogar günstiger
      Die öffentliche Wahrnehmung von fly.io scheint bereits so beschädigt zu sein, dass sie kaum noch zu reparieren ist. Ich kann inzwischen nicht mehr zählen, wie oft sie sich entschuldigt haben

  • Entgegen dem Titel des Beitrags ist die Fly.io API weiterhin nicht erreichbar. Das bedeutet, dass Nutzer weiterhin keinen Zugriff auf Deployments, Datenbanken usw. haben
    Genaue Updates gibt es unter https://community.fly.io/t/fly-io-site-is-currently-inaccess...

  • Nach meiner persönlichen Erfahrung mit sowohl Fly.io als auch Railway.com ist Railway der klare Sieger. Auch der Support von Railway ist im Vergleich hervorragend
    Fly.io hat auf meine Anfrage zur Datenlöschung per Support-E-Mail bis heute nicht geantwortet
    Die Railway-App war bisher ohne größere Downtime online. Wer nach einer brauchbaren Alternative sucht, dem würde ich empfehlen, Railway auszuprobieren

    • Ich habe das Railway-Control-Panel insgesamt vielleicht 10-mal in meinem Leben benutzt, und in der Hälfte der Fälle gab es irgendein seltsames Problem. Die UI des Control-Panels wurde nicht geladen oder funktionierte nicht, Aktionen schlugen fehl, Deployments scheiterten zufällig
      Die Idee ist gut, aber in der Praxis möchte ich es nicht für ernsthafte Zwecke nutzen
    • Fly baut auf eigener Hardware auf. Macht Railway das auch so? Falls nicht, erklärt das teilweise, warum Railway relativ weniger Ausfälle hat: Es gibt weniger zu engineerieren
      Ich verstehe, dass Endnutzer Zuverlässigkeit wollen, und ich weiß auch, dass Fly in den letzten zwei Jahren ziemlich viel darin investiert hat und trotzdem einen schlechten Ruf hat. Aber solche Ausfälle sind nicht etwas, das nur bei einem Anbieter vorkommt und bei einem anderen nicht. Cloud-Infrastruktur aufzubauen ist für niemanden einfach

  • Allein von dem, was ich selbst gesehen habe, ist das vermutlich schon der fünfte oder sechste größere Ausfall von Fly.io. Es gab viele weitere Ausfälle, und einige habe ich wahrscheinlich einfach nicht mitbekommen
    Ich habe den Dienst einem Freund empfohlen, und innerhalb von zwei Tagen hatte er zwei Ausfälle
    Fly.io muss wirklich aufwachen. Warum das immer noch nicht passiert ist, ist mir ein Rätsel. Das Produkt ist gut, aber wenn es ein Hosting-Dienst ist, muss Stabilität absolut oberste Priorität haben. Alles andere ist zweitrangig

    • Ich verstehe das, aber wenn die Leute GitHub durchgehen lassen, obwohl es alle zwei Wochen heftig ausfällt, könnte man Fly meiner Meinung nach auch ein gewisses Maß an Wohlwollen zugestehen. Ich habe keinerlei Verbindung zu Fly, aber wenn selbst riesige Unternehmen das nicht richtig hinbekommen, muss man die Erwartungen wohl senken
      Das Geheimnis scheint zu sein, ein etablierter Anbieter ohne wirklich passende Alternativen zu sein. Dann sehen alle über Betriebsversagen hinweg, selbst wenn die Zuverlässigkeit komplett katastrophal ist
    • Ich bin vor etwa einem Jahr wegen Zuverlässigkeitsproblemen weggegangen. Jetzt nutze ich DigitalOcean Apps, und das funktioniert sehr gut. Bei DO hatte ich 0 Downtime
    • Wenn das Traffic-Volumen exponentiell wächst, ist es schwierig, die Zuverlässigkeit aufrechtzuerhalten
    • Nutzt das überhaupt jemand wirklich über den Free Tier hinaus? Bei Vercel ist es genauso

  • Auffällig ist, dass auch Turso fast zur gleichen Zeit Probleme bekam. Der CEO bestätigte auf Discord, dass es wegen der Fly-Störung sei.

    Ok.I caught up with our oncall and This seems related to the Fly.io incident that is reported in our status page. Our login does call things in the Fly.io API
    we are already in touch with Fly and will see if we can speed this up

    • Es ist nicht das erste Mal, dass Turso wegen eines Fly-Problems ausfällt. Wenn man einen Datenbankdienst baut und es dann zu solcher Downtime kommt, muss das wirklich schmerzhaft sein.
      Turso scheint irgendwann einen AWS-Tier anbieten zu wollen.

  • Das überrascht mich nicht. Vor etwa einem Jahr habe ich mir fly.io wegen der niedrigen Preise angesehen und mich gefragt, wo sie Kosten einsparen, um Geld zu verdienen. Die Antwort fand ich schließlich in der technischen Dokumentation: Dort stand klar, dass eine Fly-Instanz an einen einzelnen physischen Server gebunden ist und kein Failover möglich ist, wenn dieser Server stirbt. Ich weiß nicht, ob dieser Abschnitt noch in der offiziellen Doku steht.
    In der Praxis bedeutet das: Wenn ein Server ausfällt, muss man den letzten Snapshot der betreffenden Instanz aus dem Backup laden, ihn auf einem neuen Server starten, die Netzwerkpfade aktualisieren und hoffen, dass nicht mehr Server ausfallen, als freie Kapazität vorhanden ist. Andernfalls muss man mit der Wiederherstellung warten, bis das Rechenzentrum ein paar weitere Server ins Rack steckt.
    Das erklärt auch ziemlich gut, warum die Störungsmeldungen zufällig wirken: Manche Apps sind ausgefallen, andere laufen weiter; manche sind nach fünf Minuten wieder da, andere brauchen deutlich länger.
    Für ein Unternehmen mit knappem Budget wäre eine andere Option, etwa ein kleiner Civo-Cluster, wahrscheinlich besser.

    • Fly.io kann VMs und Volumes inzwischen migrieren: https://fly.io/docs/reference/machine-migration/ / https://archive.md/rAK0V
      Bei der Aussage „eine Fly-Instanz ist an einen einzelnen physischen Server gebunden und kein Failover ist möglich“ verstehe ich nicht ganz, wie es sonst sein sollte. Ich weiß, dass es Live-Migration gibt, aber auch dann ist eine VM letztlich doch an irgendeinen physischen Server „gebunden“, oder nicht?
    • Auch die meisten EC2-Instanztypen hatten bis vor Kurzem keine Live-Migration. Bei einigen ist es vermutlich immer noch so. Es ist auch nicht klar dokumentiert, wann und wie das funktioniert.
      Und kostenlos ist es ebenfalls nicht. Bei GCP zum Beispiel gibt es während der Migration einer VM spürbare temporäre Performance-Einbußen.
    • Wenn man bei Fly Hochverfügbarkeit will, muss man die App in mehreren Regionen bereitstellen, also auf mehreren Maschinen.
      Wenn die Proxy-Schicht ausfällt, kann Fly insgesamt trotzdem noch ausfallen, aber das ist deutlich seltener.
    • Sieht man sich die Statusseite an, wirkt es wie ein Ausfall eines Hochverfügbarkeits-/Clustering-Systems. Diesmal scheint es eher ein Fall gewesen zu sein, in dem die Komplexität der Hochverfügbarkeits-Infrastruktur der Systemverfügbarkeit geschadet hat, statt einer simpleren VPS-ähnlichen Konfiguration.

  • Ein wiederkehrendes Muster scheint zu sein, dass es in Wochen mit großen US-Feiertagen häufig zu Ausfällen kommt.
    MS 365/Teams/Exchange hatten am Morgen kurz Probleme, Fly.io hatte einen vollständigen Ausfall, und anschließend wurden mehrere Websites und Dienste durch die Auswirkungen ins Wanken gebracht.
    Normalerweise bin ich gegen „Change Freezes“, aber rund um große Feiertage halte ich einen Change Freeze für sinnvoll. So bekommen alle Teams Zeit zum Auftanken, Abschalten und für Wartung.
    Man sollte dem B-Team, das zufällig Bereitschaft hat, nicht zu viel Druck aufbürden.

    • Ausfälle dieser Größenordnung werden selten durch schlechten Code verursacht. Der Übeltäter ist fast immer eine Konfigurationsänderung.
      Man kann versuchen, solche Änderungen in der Urlaubszeit ebenfalls zu reduzieren, aber was ist, wenn Zertifikate erneuert werden müssen? Wenn ein wichtiger Security-Patch eingespielt werden muss? Wenn eine Gruppe von Servern neu provisioniert werden muss? Wenn der Festplattenspeicher knapp wird?
      Operative Zwickmühlen lassen sich zu keiner Jahreszeit allein durch Planung vermeiden.
    • Dass solche Feiertagswochen anders sind als sonst, lässt sich nicht vermeiden. Wenn man einen „Change Freeze“ verhängt, werden meist auch die kleinen Korrekturen und Performance-Tunings im gesamten System blockiert, weil sie „nicht wichtig“ seien.
      Dann kommt am Ende doch eine besondere Marketing-/Produktinitiative, die spezielle Preislogik braucht neuen Code und neue UI-Widgets, Traffic und Last steigen stark an, und obwohl Freeze ist, muss das Ganze sofort raus. Weil es um Umsatz geht, ist es für die Geschäftsführung wichtig.
      Die meisten Engineering- und Infrastrukturteams wussten davon nichts, weil das Produktteam bis zur letzten Minute Druck gemacht und es einigermaßen im Geheimen vorangetrieben hat. Am Ende kann man hochwertige kleine Korrekturen einfrieren, instabile neue Features aber nicht richtig.
      Es ist schwierig; trotzdem würde ich empfehlen, den Freeze zu vergessen und vor, während und nach dem Zeitraum einen vernünftigen Betrieb ohne Überlastung zu fahren.
    • Kurzes Problem? Bei 365 läuft nach europäischer Zeit seit gestern Morgen ein andauernder Ausfall. Ich habe es gemerkt, weil ich in einem großen Insolvenzfall Compliance-Tools nutze, um Informationen zu schützen.
    • Dann werden Entwickler Änderungen nur hastig noch vor dem Freeze hineindrücken.
    • Was genau bedeutet „Freeze“? Hört man auf, Zertifikate zu erneuern? Nimmt man keine Software-Sicherheitsupdates mehr an?
      „Unnötige“ Änderungen kann man vielleicht blockieren, aber diese Grenze wird sehr schnell zur Grauzone.

  • Auch bei der Ausfallserie Anfang 2023 gab es Schmerzen rund um Corrosion: https://community.fly.io/t/reliability-its-not-great/11253

    • Die Entscheidung, einen eigenen Datenspeicher zu bauen, scheint eine schlechte Wette gewesen zu sein.
      Ich kenne die Randbedingungen nicht besonders gut, aber ScyllaDB unterstützt Eventual Consistency und ist insgesamt recht flexibel. Für Multi-Leader-Replikation wäre auch CouchDB eine Option.