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

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

Entwicklung & Code

software-architektur.tv: Modelle und Modularisierung mit Alistair Cockburn


Auf dem jüngsten Software Architecture Gathering hielt Eberhard Wolff einen Vortrag über Modelle, Modularisierung und Bounded Contexts, während Alistair Cockburn in Gesprächen mit den Teilnehmenden ähnliche Themen beleuchtete. In dieser englischsprachigen Episode des Videocasts kommen die beiden zusammen, um die zentralen Konzepte hinter diesen Themen zu diskutieren, ihre Perspektiven zu vergleichen und Fragen aus dem Publikum zu beantworten.

Weiterlesen nach der Anzeige

Das Duo spricht über verschiedene Konzepte – beispielsweise über die ursprünglichen Arbeiten von Parnas zur Modularisierung, die hexagonale Architektur beziehungsweise „Ports and Adapters“ (die von Alistair Cockburn entwickelt wurde) oder auch Domain-driven Design.

Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 12. Dezember

Die Ausstrahlung findet am Freitag, 12. Dezember 2025, live ab 15:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.

Weiterlesen nach der Anzeige


(mdo)



Source link

Weiterlesen

Entwicklung & Code

Kommentar: Anthropic verschenkt MCP – mit fragwürdigen Hintertüren


close notice

This article is also available in
English.

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

.

Fürchte die Danaer, wenn sie Geschenke bringen! So steht es bei Vergil und bei Asterix. Gemeint sind die Achaier vor Troja mit ihrem heldeninfizierten Holzpferd. Jetzt verschenkt Anthropic das Model Context Protocol (MCP) – und zwar der Linux Foundation, genauer gesagt, der zu diesem Zweck neu gegründeten Tochter, der Agentic AI Foundation (AAIF).

Weiterlesen nach der Anzeige

Das Geschenk ist zwar sicher kein Trojaner, aber ganz so selbstlos, wie die Ankündigung von Anthropic und die jubelnde Entgegennahme seitens der Foundation es gerne vermitteln möchten, ist es auch nicht. Vielmehr zieht sich Anthropic damit aus der Verantwortung für die vernachlässigte Absicherung von Server und Clients im Protokoll.

Großzügig zeigten sich neben Anthropic auch Block und Open AI, die das goose-Framework beziehungsweise die Spezifikation AGENTS.md der AAIF überreichten. Im Netz tauchte schnell die Vermutung auf, dass die Firmen ihr jeweiliges Produkt als Standard sichern wollen, um der Konkurrenz zuvorzukommen. „Selbst, wenn das großzügig aussieht, schau zweimal hin. Es geht mehr darum, einen Claim abzustecken, bevor andere es tun“, schreibt Nerd.xyz. Das mag im Fall von Block vielleicht zutreffen, für Anthropic mit MCP aber sicher nicht. MCP ist jetzt bereits ein Quasistandard, Konkurrenz weit und breit nicht in Sicht.

MCP war auch schon immer Open Source, die Community hat mitgewirkt. Das betont auch die Ankündigung von Anthropic: „Die Projekt-Maintainer werden damit fortfahren, den Community-Input und eine transparente Entscheidungsfindung zu priorisieren.“ Davon, dass die bisherigen unternehmensnahen Projektverantwortlichen ausgetauscht werden sollen, ist nirgendwo die Rede.

Die Foundation bietet Schutz vor rechtlicher Verfolgung

Warum verschenken Firmen Software an eine Stiftung wie die Linux Foundation? Darüber gibt der elegische Blogbeitrag von GitHub zur Feier der MCP-Schenkung Auskunft:

  1. Langfristige Stabilität: Firmen und Entwickler können sich darauf verlassen, dass die Software unter dem Dach der Stiftung dauerhaft fortexistiert.
  2. Gleichberechtigte Teilhabe: Der offene Zugang zum Projekt ist für alle garantiert.
  3. Kompatibilitätsgarantie: Die Plattform lässt sich für alle Systeme und Anwender nutzen.
  4. Die Sicherheit eines offenen Standards: neutrale Governance in regulatorischen Zeiten als sichere Basis für Projekte in Unternehmen.

Weiterlesen nach der Anzeige

Wenn wir die Punkte 1 bis 3 in Hinblick auf die MCP-Schenkung betrachten, kommen sie schnell als Gründe dafür nicht infrage. Ein viel genutzter Standard, auch von den Googles und Microsofts dieser Welt, wird, solange er relevant ist, einen Pfleger finden. Als Open-Source-Projekt ist auch die Teilhabe kein Problem und Kompatibilität spielt bei einem offenen Protokoll ebenfalls keine große Rolle.

Bleibt als Argument einzig die neutrale Governance: Anthropic schleicht sich mit der Schenkung aus der Verantwortung, die insbesondere auch durch europäische Regulatorien auf den MCP-Betreiber fallen. Das ist nicht unbegründet: Andere Firmen haben ebenso gehandelt und es ist unter Expertinnen und Experten bekannt, dass MCP ein Einfallstor für die gesamte Fülle der digitalen Büchse der Pandora ist.

In einem Interview mit heise developer sagt Mirko Ross, Gründer und CEO der Sicherheitsfirma asvin: „MCP wurde in einem aufgeheizten Markt unter hohem Zeitdruck konzipiert. Dabei spielt der Gedanke des MVP – Minimal Viable Product – eine Rolle. Also die schnelle Einführung von Grundfunktionen, die von Anwendern angenommen werden. Aus Sicht der Cybersecurity bedeutet MVP allerdings ‚Most vulnerability possibilities‘“.

Der Siegeszug von MCP auf der einen und die vernachlässigte Sicherheit auf der anderen Seite geben dieser Vermutung recht. Und jetzt, wo der Standard durch Anthropic gesetzt ist, kann sich die Firma pompös zurückziehen.

Softwareprojekte unter dem Dach einer Stiftung zu betreiben, ist an sich nichts Schlechtes. Im Gegenteil: Die KI-Welt kann jetzt hoffen, dass die Community zügig und verantwortungsvoll die Sicherheit von MCP erhöht. Ansonsten werden autonome Agenten, die sich selbstständig MCP-Server suchen und anzapfen, darin versteckte Aggressoren hinter die Firewall holen, die dem Feind alle Sicherheitstore öffnen.


(who)



Source link

Weiterlesen

Beliebt