Connect with us

Entwicklung & Code

Aus Softwarefehlern lernen – Teil 5: 440 Millionen Dollar Verlust in Minuten


In modernen Softwareprojekten ist das Deployment längst keine einmalige Aktion mehr, sondern ein kontinuierlicher Prozess. Anwendungen bestehen aus Dutzenden oder Hunderten von Services, laufen in Containern und erhalten oft mehrmals am Tag ein Update. Um neue Funktionen schrittweise zu aktivieren, greifen Teams auf Feature Flags oder Konfigurationsschalter zurück. Diese Flexibilität ist ein Segen – und gleichzeitig eine erhebliche Gefahrenquelle.

Weiterlesen nach der Anzeige


Golo Roden

Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Die Teile der Serie „Aus Softwarefehlern lernen“:

Muster 5: Deployment, Konfiguration und Flags: Wenn ein Schalter Millionen kostet

Ein eindrückliches Beispiel liefert der Fall Knight Capital aus dem Jahr 2012. Das Unternehmen war ein Schwergewicht im elektronischen Handel an der US-Börse und wickelte täglich Millionen von Transaktionen ab. Am 1. August 2012 spielte Knight ein neues Softwareupdate aus, das eine Funktion namens „Retail Liquidity Program“ unterstützen sollte. Die Bereitstellung lief jedoch schief: Ein Feature Flag, das ursprünglich für Testzwecke existierte, wurde auf einem von acht Servern nicht korrekt aktualisiert.

Was folgte, war ein Paradebeispiel für die Kaskade aus Konfigurationsfehlern und fehlender Deployment-Sicherheit: Auf sieben Servern lief die neue Logik wie geplant, ein einzelner Server führte beim Start jedoch alten Code aus, der längst nicht mehr produktiv sein sollte – weil das Flag dort nicht korrekt gesetzt war.

Dieser alte Code enthielt eine Legacy-Routine, die fälschlicherweise massenhaft Kaufaufträge generierte. Innerhalb von nur 45 Minuten verursachte Knight Capital rund 440 Millionen US-Dollar Verlust. Das Unternehmen stand am Rand der Insolvenz, nur eine schnelle Übernahme und externe Finanzierung retteten es vor dem Aus.

Die Lehren aus diesem Vorfall sind für jede Organisation relevant – ob Börsenhandel, E-Commerce oder SaaS-Betrieb:

Weiterlesen nach der Anzeige

  1. Feature Flags brauchen einen Lebenszyklus: Ein Schalter, der nicht dokumentiert, nicht versioniert und nicht befristet ist, wird irgendwann zum Risiko. Flags müssen ein Ablaufdatum, einen Owner und eine Entfernungsperspektive haben.
  2. Deployments müssen atomar und konsistent sein: Es reicht nicht, acht Server irgendwann nacheinander zu aktualisieren. Ohne Sicherstellung, dass alle Instanzen dasselbe Release und dieselbe Konfiguration fahren, entstehen Split-Brain-Situationen. Moderne CI/CD-Pipelines oder Kubernetes-Rollouts lösen dieses Problem durch atomare Deployments und Health-Checks. „Atomar“ bedeutet hier nicht, dass alle Instanzen gleichzeitig umgestellt werden, sondern dass innerhalb eines Deployments keine Mischzustände existieren.
  3. Immutable Infrastructure ist die beste Versicherung: Systeme, die man nicht nachträglich verändert, sondern bei Änderungen komplett neu instanziiert, vermeiden Zombiecode. Wer ein neues Image ausrollt, kann sicher sein, dass kein Server alten Code im RAM behält.
  4. Staged Rollouts und Kill-Switches reduzieren den Schaden: Große Änderungen sollten zunächst bei einem Bruchteil der Instanzen aktiviert werden, am besten begleitet von automatisierten Metriken. Ein zentraler Schalter zum sofortigen Abschalten (Kill-Switch) kann Milliardenverluste verhindern. Jede Stufe eines Rollouts ist dabei für sich konsistent, aber die Ausweitung auf alle Instanzen erfolgt schrittweise.
  5. Runbooks und Übung unter Realbedingungen: Selbst die beste Technik hilft wenig, wenn im Ernstfall niemand weiß, wie man reagiert. Unternehmen, die Notfallprozeduren für fehlerhafte Deployments proben, reagieren schneller und souveräner.

Interessant ist, dass Knight Capital nicht am Fehlen von Technologie scheiterte. Die Tools für sichere Deployments existierten längst. Es war vielmehr ein Organisations- und Prozessversagen, bei dem technische Schulden (wie Legacy-Code und Flag-Wildwuchs) und menschliche Routine („haben wir immer so gemacht“) zusammenkamen.

Für moderne Cloud- und Webprojekte gilt übrigens dasselbe Muster: Wer Feature Flags einsetzt, ohne Lifecycle und Dokumentation zu etablieren, erzeugt unbemerkt eine tickende Zeitbombe. Und wer Deployments manuell oder halbautomatisch ausrollt, nimmt Inkonsistenzen in Kauf, die sich irgendwann rächen.

Die Lösung ist eine Kombination aus Disziplin und Automatisierung:

  • Feature Flags werden wie Code behandelt, mit Versionierung, Owner und Entfernungspflicht.
  • Deployments laufen atomar und reproduzierbar, am besten als Infrastructure as Code.
  • Ein zentraler Kill-Switch schützt vor irreversiblen Schäden.

Knight Capital ist das prominenteste Beispiel, aber ähnliche Zwischenfälle gab es seither mehrfach – von falschen Cloudkonfigurationen bis zu versehentlich aktivierten Debug-Modi in der Produktion. Und jedes Mal zeigt sich erneut: Ein einziger vergessener Schalter kann ausreichen, um ein Unternehmen ins Wanken zu bringen.


(who)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Entwicklungsumgebung Eclipse IDE 2025-12: Java 25, JUnit 6, Multi-Release-JAR


Eclipse, die quelloffene und frei verfügbare Entwicklungsumgebung für Java, C/C++, PHP und weitere Programmiersprachen, ist in der Version 2025-12 erschienen. Für Windows, macOS und Linux stehen verschiedene eigenständige, erweiterbare IDE-Pakete zur Verfügung. Die Java-Sprachunterstützung von Visual Studio Code und dessen Forks, wie dem KI-Code-Editor Cursor, basiert zwar auf Eclipse, ist aber nicht Teil des Eclipse-IDE-Releases.

Weiterlesen nach der Anzeige

Neben dem Support für Java 25, JUnit 6 und Multi-Release-JAR-Dateien gibt es in der Java-IDE sogenannte Lambda Entry Breakpoints. Damit lassen sich selbst dann gezielt Breakpoints in Lambda-Ausdrücken setzen, wenn mehrere verkettete Lambda-Ausdrücke in einer Zeile stehen. Auch hinsichtlich anderer Programmiersprachen gibt es Verbesserungen, beispielsweise um die jeweils aktuelle Version TypeScript 5.9 und PHP 8.5 nutzen zu können.

Mit Java 21 im Gepäck, reif für Java 25

Die Java-IDE unterstützt zwar Java 25 und die in Java implementierte IDE lässt sich auch mit Java 25 ausführen. Dennoch werden, obwohl Java 25 eine LTS-Version ist, für die die Hersteller Long-Term-Support (LTS) versprechen, die Eclipse-Pakete weiterhin mit der vorherigen LTS-Version Java 21 ausgeliefert. Der Grund: In der von Eclipse verwendeten Java-Distribution Eclipse Temurin ist Java 25 noch nicht für Windows on ARM verfügbar. Wer also Java 25 nutzen will, muss es separat installieren.

In Java 25 gibt es zwei neue Sprachfeatures, „Flexible Constructor Bodies“ und „Module Import Declarations“. Ersteres erlaubt in Konstruktoren Anweisungen vor dem Aufruf von super() oder this(). Bei Verwendung einer älteren Java-Version zeigt Eclipse einen Fehler mit dem Hinweis an, dass dies erst ab Java 25 möglich ist. Beim Schreiben einer Modulimportdeklaration kann per Codevervollständigung ein Modul aus einer Liste der verfügbaren Module ausgewählt werden. Die Funktion Organize Imports entfernt unnötige Modulimportdeklarationen, fügt aber weiterhin nur Importdeklarationen auf Klassenebene hinzu.

Java-IDE: Debugging-Optionen und Erstellen von Multi-Release-JARs

Zum Debuggen von Java-Code kann im Editor in der entsprechenden Zeile per Rechtsklick auf den linken Rand und Auswahl des Menüpunkts „Toggle Lambda Entry Breakpoint“ ein Breakpoint für einen Lambda-Ausdruck gesetzt oder wieder entfernt werden. Befinden sich mehrere Lambda-Ausdrücke in der Zeile, erscheint ein Dialog, in dem der Gewünschte aus einer Liste vorhandener Lambda-Ausdrücke ausgewählt werden kann. Im „Open Type“-Dialog lässt sich nun per Camel Case filtern, beispielsweise „outMem“ anstelle von „out*mem“ für OutOfMemoryError. Für die seit Java 23 verfügbaren Markdown-Javadoc-Kommentare können projektspezifische Vorlagen erstellt werden. Außerdem lässt sich einstellen, ob bei der Code-Generierung Markdown- oder klassische Javadoc-Kommentare verwendet werden sollen. Beim Formatieren werden Markdown-Javadoc-Kommentare nun standardmäßig mitformatiert, was sich deaktivieren lässt.

Weiterlesen nach der Anzeige

Neu ist die Option zur Erstellung von Multi-Release-JAR-Dateien. Diese enthalten einige der kompilierten Klassen zusätzlich in einer für eine höhere Java-Version kompilierten Variante, die nur dann verwendet wird, wenn die JAR-Datei mit mindestens dieser Java-Version ausgeführt wird. In der IDE legt man dazu zusätzliche Quellcodeordner an und bestimmt dann im Java Build Path über die neue Release-Option die Java-Version, entweder „project default“ oder eine höhere Java-Version. Bei Maven-Projekten müssen die Einstellungen nicht manuell vorgenommen werden, stattdessen werden sie automatisch mit denen des Maven-Compiler-Plug-ins in der pom.xml-Datei synchronisiert.

TypeScript, JavaScript und PHP

Beim Tooling für Webtechnologien bedient sich Eclipse, genauer gesagt Eclipse Wild Web Developer, bei Visual Studio Code und unterstützt damit TypeScript, einschließlich der aktuellen Version 5.9. Bei den Eclipse PHP Development Tools (PDT) wurden diese nach längerer Pause aktualisiert und bieten nun Support für PHP 8.4 und 8.5.

Upgrade oder Download

Für Windows, Linux und macOS werden jeweils zehn erweiterbare Basispakete der Eclipse-Entwicklungsumgebung für unterschiedliche Einsatzzwecke angeboten. Sämtliche Pakete enthalten alles, was zum Ausführen von Eclipse und zum Entwickeln notwendig ist: Java 21 und Git, sowie in den Java-IDE-Paketen zusätzlich Maven und Gradle.

Die Eclipse-IDE-Pakete können über den Eclipse Installer installiert oder als ZIP-Dateien heruntergeladen werden. Eine bestehende Eclipse IDE lässt sich über Help | Check for Updates aktualisieren. Weitere Informationen und die Neuerungen von den an diesem Release beteiligten Eclipse-Projekten finden sich auf der Eclipse-IDE-Webseite.


(map)



Source link

Weiterlesen

Entwicklung & Code

Jira-Alternative: Plane 1.2.0 migriert von Next.js zu React Router und Vite


Die Entwickler des quelloffenen Projektmanagement-Tools Plane haben mit Version 1.2.0 eine umfassende Migration vollzogen: Sämtliche Web-Anwendungen laufen nun auf React Router (Framework Mode) und Vite statt Next.js. Die Umstellung betrifft über 1200 Dateien und mehr als 20.000 neue Codezeilen in den Repositories makeplane/plane, plane-ee und der Air-gapped-Deployment-Variante. Gleichzeitig schließt die neue Version kritische Sicherheitslücken in Next.js und React.

Weiterlesen nach der Anzeige

Der Wechsel erfolgte, weil Plane auf eine „client first“-Architektur ohne Server-Side-Rendering setzt und die Next.js-spezifischen Features wie Hybrid-Routing oder spezielle Data-Fetching-Mechanismen nicht nutzt. Die Entwickler berichten in einem Blogbeitrag, dass die Hot-Reload-Zeiten von 20 bis 30 Sekunden auf Millisekunden sanken. Auch der Dev-Server startet deutlich schneller. Zudem konnten die Build-Pipelines vereinfacht werden, da Tests und Produktiv-Builds jetzt auf demselben Tooling basieren.

Für Betreiber bestehender Self-Hosted-Instanzen gibt es laut der Entwickler keine Breaking Changes. Auch für Endnutzer ändert sich durch den Wechsel nichts am Erscheinungsbild oder Verhalten von Plane. Die Migration erfordert lediglich ein Docker-Update oder einen neuen Build der Container. Das Projekt hat die neue Architektur in Cloud-, Self-Hosted- und Air-gapped-Umgebungen getestet. Ein dediziertes Migrationsskript veröffentlicht Plane nicht, die Standard-Upgrade-Prozedur via Git-Pull und docker-compose up genügt.

Neue Navigation und Keyboard-Shortcuts

Neben der technischen Migration bringt Version 1.2.0 auch sichtbare Änderungen: Eine neue Top-Bar mit globaler Suche und Inbox ersetzt Teile der bisherigen Seitenleiste. Projekt-Features wie Cycles, Modules, Epics und Pages erscheinen als horizontale Tabs. Die linke Navigation lässt sich auf einen Icon-only-Modus reduzieren. Mit „Power K“ führt Plane erweiterte Keyboard-Shortcuts ein, die Navigation, das Erstellen von Work-Items, Cycles und Modules sowie das Umschalten von Sidebars und Kopieren von Links umfassen.

Die Intake-Funktion erhält einen neuen „Triage“-Status für eingehende Requests, der isoliert von den regulären Projekt-States arbeitet. Weitere Änderungen umfassen vereinfachte User-Filtering-Endpunkte, neue APIs für Workspace-Invitations und Projekt-Member-Management sowie eine automatische Icon-Zuweisung bei Projekterstellung über einen externen Endpunkt. Das Limit für Projekt-Identifier wurde auf 10 Zeichen erhöht.

Sicherheits-Updates gegen RCE-Lücken

Weiterlesen nach der Anzeige

Ein wichtiger Bestandteil des Release sind Security-Patches: Plane behebt CVE-2025-66478 in Next.js und CVE-2025-55182 in React, beides Schwachstellen mit unauthenticated Remote Code Execution. Außerdem wurde Django auf Version 4.2.27 aktualisiert, um eine SQL-Injection-Lücke in Column-Aliases zu schließen. Auch die Nginx-Version erhielt ein Upgrade. Self-Hosted-Betreiber sollten Plane zeitnah aktualisieren, um diese kritischen Lücken zu schließen.

Die Enterprise-Edition (plane-ee) und Helm-Pakete erhalten dieselben Änderungen wie die Community-Edition. Unterschiede bestehen lediglich in zusätzlichen Cloud- und Analytics-Features der Enterprise-Variante. Quantitative Performance-Metriken zu Bundle-Größe oder Runtime-Latenz vor und nach der Migration veröffentlicht Plane nicht, betont aber die deutlich schnelleren Build- und Entwicklungs-Workflows.

Plane positioniert sich als Open-Source-Alternative zu Jira, Linear, Monday und Asana. Details zu Version 1.2.0 finden sich im GitHub-Release.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Neu in .NET 10.0 [1]: Start der neuen Blogserie


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Mit diesem Beitrag beginnt die neue Blogserie zu .NET 10.0. Wie in letzten Jahren zu .NET 8.0 und zu .NET 9.0 werde ich in zahlreichen kleineren Beiträgen die Neuerungen in .NET 10.0 vorstellen.

Weiterlesen nach der Anzeige


Der Dotnet-Doktor – Holger Schwichtenberg

Der Dotnet-Doktor – Holger Schwichtenberg

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

.NET 10.0 steht seit dem 11. November 2025 auf der Downloadseite kostenfrei zur Verfügung. Für .NET 10.0 benötigen Entwicklerinnen und Entwickler die Entwicklungsumgebung Visual Studio in der Version 2026 (alias 18.0), die ebenfalls am 11. November 2025 erschienen ist.

Entwicklung von .NET 10.0

Entwickelt wurde .NET 10.0 in den letzten 12 Monaten. Seitdem hat Microsoft sieben Preview-Versionen und zwei Release-Candidate-Versionen veröffentlicht:

  • Preview 1: 25.02.2025
  • Preview 2: 18.03.2025
  • Preview 3: 10.04.2025
  • Preview 4: 12.05.2025
  • Preview 5: 10.06.2025
  • Preview 6: 15.07.2025
  • Preview 7: 12.08.2025
  • Release Candidate 1: 09.09.2025
  • Release Candidate 2: 14.10.2025
  • Release to Manufacturing (RTM): 11.11.2025

Inhalt dieser Blogserie

Weiterlesen nach der Anzeige

Meine Serie wird in den kommenden Wochen und Monaten über folgende Aspekte von .NET 10.0 berichten:

  • Neue Sprachfeatures in der Programmiersprache C# 14.0
  • Neue Funktionen im .NET 10.0 Software Development Kit (SDK)
  • Neue und erweiterte Klassen in der .NET 10.0-Klassenbibliothek

Ziele der Blogserie

Meine Beiträge erheben dabei nicht den Anspruch, die Dokumentation zu ersetzen oder zu überbieten. Leserinnen und Leser können meine Beiträge als Impulsgeber verstehen, sich zu entscheiden, ob eine Neuerung für ihre Anwendungsfälle Sinn ergibt und sie sich damit dann näher beschäftigen wollen.

Ich werde die Beiträge der Serie jeweils so weit im Voraus schreiben, dass eine wöchentliche Veröffentlichung gewährleistet ist.


(rme)



Source link

Weiterlesen

Beliebt