Self Healing Code

In der Softwareentwicklung stellt sich manchmal das Gefühl ein, von Buzzwörtern umgeben zu sein. Auch Self Healing Code könnte ein solches sein. Doch trägt das Konzept einige interessante Eigenschaften mit sich und sollte nicht vorschnell verworfen werden.

Die grobe Idee hinter diesem Konzept ist es, dass die Anwendung Fehler erkennen und diese im Idealfall auch beheben kann. Dieser Prozess soll ohne menschliches Eingreifen stattfinden.

Neben der einzelnen Applikation kann, sich ein solches Verhalten auf komplexere Systeme und deren Zusammenspiel beziehen. Neben der Fehlerbehebung, während der Laufzeit einer solchen Software, wird der Begriff des Self Healing Code in letzter Zeit auch im Zusammenhang mit generativer KI genutzt.

Definition

Im Bereich der Softwareentwicklung ist Self Healing Code so definiert, dass ein Programm in der Lage ist, Fehler zu erkennen und zu korrigieren. Verwandt damit ist der Begriff der selbstheilenden Systeme, denen die Fähigkeit inhärent ist, aus einem defekten Zustand wieder in einen funktionalen Zustand zu wechseln.

Ein einfaches Model von Self Healing Code

Das Ziel des selbstheilenden Codes ist es, die Notwendigkeit menschlicher Eingriffe zu minimieren und die Betriebszeit und Effizienz der Software zu maximieren. Dies kann durch die Implementierung von Überwachungs- und Diagnosefunktionen erreicht werden, die auf Anomalien oder Fehler hin überprüfen. Sobald ein Problem erkannt wird, wird versucht darauf zu reagieren, indem entweder eine Korrekturmaßnahme ausgeführt oder auf einen vorherigen stabilen Zustand zurückkehrt wird.

Defensive Programmierung

Eng verwandt mit Self Healing Code ist defensive Programmierung. Beides sind Praktiken, die dazu dienen, die Robustheit und Zuverlässigkeit von Software zu verbessern, aber sie tun dies auf unterschiedliche Weisen.

Defensive Programmierung ist eine Methode, bei der der Entwickler davon ausgeht, dass Probleme auftreten werden und daher Vorkehrungen trifft, um diese zu bewältigen. Dies kann beinhalten, dass überprüft wird, ob Eingaben gültig sind, bevor sie verwendet werden, Ausnahmen ordnungsgemäß behandelt werden und der Code so geschrieben wird, dass er leicht zu verstehen und zu warten ist.

Das Ziel der defensiven Programmierung ist es, die Anzahl der Fehler zu reduzieren und sicherzustellen, dass die Anwendung auch bei unerwarteten Eingaben oder Bedingungen korrekt funktioniert.

Selbstheilender Code hingegen geht einen Schritt weiter. Anstatt nur zu versuchen, Fehler zu vermeiden, versucht er, Fehler zu erkennen und zu beheben, wenn sie auftreten.

Bei der Betrachtung von Self Healing Code sollte auch defensive Programmierung Berücksichtigung finden. Diese kann dazu beitragen, die Anzahl der Fehler zu reduzieren, die auftreten können. Self Healing Code kann anschließend dazu beitragen, die Auswirkungen der Fehler zu minimieren, die trotzdem auftraten.

Implementation

Natürlich muss die gewünschte Funktionsweise der Selbstheilung bei der Entwicklung und dem Design einer Applikation und entsprechender Systeme berücksichtigt und implementiert werden.

Der erste Schritt ist die Fehlererkennung. Das bedeutet, dass die Applikation in der Lage sein muss, eventuelle Fehler und Probleme selbstständig zu erkennen. Hier können Applikationslogiken, Logs oder auch Überwachungssysteme genutzt werden.

Wird eine Anwendung oder ein Teil eines Softwaresystems überwacht, so müssen Schwellwerte definiert werden, welche definieren, ab wann die Services sich in einem kritischen Zustand befinden, damit darauf basierend Maßnahmen ergriffen werden können.

Präventiv und reaktiv

Die Fähigkeit der Selbstheilung kann in präventives und reaktives Handeln unterschieden werden. Beim präventiven Handeln werden gewisse Schlüsselindikatoren von der Applikation ausgewertet und darauf basierend eine Handlung ausgelöst.

So könnte eine Server-Applikation keine neuen Verbindungen mehr zulassen, wenn die CPU-Auslastung auf dem eigenen System zu hoch ist und somit einer Überlastung vorbeugen.

Reaktives Handeln ist vonseiten der Applikation immer dann notwendig, nachdem es zu einem Fehler gekommen ist. In diesem Fall muss die Applikation reagieren, um wieder einen funktionsfähigen Ablauf herstellen zu können.

Fehlerbeseitigung

Wurde ein Fehler erkannt, sollte er im nächsten Schritt behoben werden. Hier sind unterschiedliche Möglichkeiten denkbar, wie der Neustart eines Services oder das Ausweichen auf andere Datenquellen.

Dieser Prozess der Erkennung und Beseitigung von Fehlern und Problemen sollte ebenfalls automatisiert sein, sodass er ohne menschliche Einwirkung auskommt. Wird der Mechanismus aktiv, sollte ein Logging vorgenommen werden, damit dies später nachvollzogen werden kann.

Test und Dokumentation

Neben der Implementierung sollten selbstheilende Funktionalitäten auch regelmäßig getestet und gut dokumentiert werden, um bei Bedarf eine schnelle und effiziente Fehleranalyse zu ermöglichen.

Auch auf Sicherheitsaspekte sollte achtgegeben werden. Es sollte sichergestellt werden, dass die Maßnahmen zur Selbstheilung nicht von außen manipuliert oder missbraucht werden können.

Ein einfaches Beispiel

Wie könnte die Anwendung dieses Konzeptes aussehen? Ein heruntergebrochenes Beispiel unter Java könnte sich wie folgt darstellen:

public Connection connectToDatabase() {

    Connection connection = null;

    while (connection == null) {
        
        try {
            connection = DriverManager.getConnection(URL, USER, PASSWORD);
        } catch (SQLException e) {

            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                // Ignore
            }
        }
    }

    return connection;
}

In der Methode connectToDatabase soll eine Datenbankverbindung erstellt und diese anschließend zurückgegeben werden. Tritt beim Aufbau der Verbindung eine Ausnahme auf, so wird versucht nach einer Wartezeit nochmals eine Verbindung aufzubauen, in der Hoffnung, dass der Fehler nur temporärer Natur war.

Damit wird dem Nutzer eine Alternative zu einem völligen Abbruch des Verbindungsversuches geboten. Im Idealfall, auch bei Auftreten eines Fehlers, wird ein verzögerter Aufbau der Verbindung ermöglicht. In der Praxis sollte dieses Beispiel allerdings in der vereinfachten Form nicht genutzt werden, da die Methode connectToDatabase niemals eine Antwort liefern würde, wenn die Datenbank nicht mehr antwortet. Hier ist es nötig, nach einer gewissen Zeit oder einer bestimmten Anzahl an Versuchen abzubrechen.

Methodiken und Pattern

Für die Bereitstellungen selbstheilenden Codes können unterschiedlichste Methodiken innerhalb einer Applikation genutzt werden, um dieses Konzept zum Erfolg zu führen.

Dies führt vom Einsatz von Entwurfsmustern wie dem Circut Breaker über die Möglichkeit zum Failover, den Neustart fehlerhafter Komponenten, oder die Nutzung von Read-Only-Mechanismen, bei verschlechternder Servicequalität.

Circut Breaker

Der Circuit Breaker ist ein Entwurfsmuster, welches verwendet wird, um Systeme zu schützen. Die Benamung ist nicht ohne Grund so gewählt, da er wie eine Sicherung die Verbindung zu einem System kappt, wenn bestimmte Kriterien erfüllt sind.

Dies kann z. B. eine definierte Fehlerrate in einem bestimmten Zeitraum sein. Ein Beispiel wäre ein Webservice, welcher wiederholt auf Anfragen nicht antwortet. Der Aufrufer könnte nun versuchen immer und immer wieder Anfragen zu senden, was dazu führen kann, dass das System im schlimmsten Fall unter der Last zusammenbricht.

Hier greift der Circut Breaker ein und unterbricht die Verbindung. Indessen kann in der Anwendung auf den Fehler reagiert werden, die Anfrage z. B. zu einem späteren Zeitpunkt wiederholt werden.

Meist wird nach einer Cooldown-Phase die Verbindung zum Service wieder aufgenommen. Treten hierbei wieder Fehler auf, so wird der Circut Breaker die Verbindung erneut trennen und der Prozess beginnt von vorn.

Auch in der Applikation selbst führt dies zu positiven Effekten, da nicht mehr auf die entsprechende Verbindung gewartet werden muss und eventuell dafür genutzte Threads und weitere Ressourcen für diesen Moment abgewickelt werden können.

Failover

Eine weitere Möglichkeit für Self Healing Code ist die Implementierung von Failover-Verfahren unter der Bereitstellung von Redundanz. Grundsätzlich bedeutet dies, dass auf andere Systeme umgeschaltet wird, wenn das angefragte System ausfällt.

Dies kann bedeuten, dass im Falle eines nicht oder fehlerhaft antwortenden Webservices, eine andere Instanz des Webservices genutzt wird.

Ein Rückfall auf einen alternativen Payment-Provider sichert den Geschäftsprozess ab

Daneben sind auch andere Szenarien denkbar. So konnte die eigene Applikation einen Payment-Provider nutzen. Bei einem Ausfall könnte dies ein geschäftskritisches Problem darstellen. Als Failover-Variante kann auf einen zweiten unabhängigen Payment-Provider umgeschwenkt werden, bis der primäre Provider wieder verfügbar ist.

Ziel ist es beim Failover, die Ausfallzeiten zu minimieren und die Verfügbarkeit zu gewährleisten. Aus Sicht eines Nutzers würde ein solcher Ausfall eines Service zu keinem veränderten Ergebnis führen.

Änderung in der Applikationslogik

Eine weitere Möglichkeit innerhalb einer Applikation auf Probleme zu reagieren, ist es Änderung in der eigentlichen Logik vorzunehmen. Beispielhaft könnte von einem externen Webservice eine Route anhand gewisser Parameter geliefert werden.

Fällt dieser Service aus, könnte die Anwendung stattdessen intern eine Route mit einem vereinfachten Algorithmus berechnen. Das Ergebnis ist qualitativ nicht unbedingt mit dem des externen Service zu vergleichen, allerdings kann es aus Sicht des Nutzers trotzdem ausreichend sein, falls der Webservice nicht zur Verfügung steht.

Limiter

Eine weitere Klasse nützlicher Methodiken sind Limiter. So begrenzt ein Rate Limiter die Anzahl der Anfragen, die ein Nutzer in einem bestimmten Zeitraum senden kann. Dies ist besonders nützlich in Szenarien, in denen Systemressourcen begrenzt sind oder um versehentliche Denial-of-Service-Angriffe zu verhindern.

Daneben existieren weitere Limiter, wie der Time Limiter welcher die Zeit begrenzt, die ein bestimmter Prozess zur Ausführung nutzen kann. Wenn der Prozess die zugewiesene Zeit überschreitet, wird er abgebrochen oder eine Ausnahme wird ausgelöst. Dies kann eine Möglichkeit darstellen, Timeouts zu realisieren.

Let It Crash

Aus einer übergeordneten Sicht kann es sinnvoll sein, Services abstürzen zu lassen, wenn es zu schwerwiegenden Problemen kommt. Je nachdem, wie das System gestaltet ist, wird der Service anschließend wieder gestartet und hochgefahren.

Erlang ist ein anschauliches Beispiel für diese Let It Crash-Philosophie. Sie führt dazu, dass sobald ein Prozess auf einen Fehler stößt, dieser beendet wird, anstatt den Fehler zu beheben. Andere, überwachende Prozesse können anschließend entscheiden, wie sie auf den Absturz reagieren, oft indem sie den fehlerhaften Prozess neu starten.

Hier gibt es im Service selbst keinen selbstheilenden Code, sondern es wird sich auf die Gesamtarchitektur des Systems verlassen, welche dafür sorgt, dass der Dienst wieder neu gestartet wird oder das Problem auf andere Art und Weise behoben wird.

Hier muss darauf geachtet werden, dass die Applikationen auf diesen Fall vorbereitet sein müssen. So müssen z. B. Verbindungen wieder aufgenommen werden, nachdem der jeweilige Service wieder verfügbar ist.

Caches

Auch Caches können im Rahmen selbstheilender Anwendungen nützlich sein. Wenn eine Information nicht vom externen Service bezogen werden kann, kann unter Umständen die letzte gecachte Antwort für die Anforderung genutzt werden.

Dies ist natürlich nur in solchen Fällen möglich, in denen der Cache für die gewünschte Anfrage vorhanden ist und sichergestellt werden kann, dass die gespeicherte Antwort den Anforderungen an die benötigte Aktualität gerecht wird.

Veränderung der Servicequalität

Wer Dienste entwickelt und betreibt, kann weitere Funktionalitäten implementieren, um zumindest ein Teil eines Dienstes noch funktionsfähig zu halten. So kann ein entsprechender Service z. B. in einen Read-Only-Modus gesetzt werden, wenn Schreibzugriffe aufgrund eines Fehlers aktuell nicht funktionieren.

Da in den meisten Fällen Lesezugriffe einem Schreibzugriff überwiegen, können in einem solchen Read-Only-Modus viele der Anfragen immer noch erfolgreich beantwortet werden.

Das dahinter liegende Konzept ist es, die Funktionalität, welche noch zur Verfügung steht, dem Aufrufer zur Verfügung zu stellen, anstatt den Betrieb komplett einzustellen. So können einzelne Features im Fehlerfall abgeschaltet werden, anstatt den kompletten Service zu deaktivieren.

Allerdings müssen die aufrufenden Applikationen hierauf vorbereitet sein und damit umgehen können.

Retry

Wie bereits im Beispiel oben demonstriert, können wiederholte Versuche einen Service aufzurufen, eine Möglichkeit sein, Systeme fehlertolerant und selbstheilend zu gestalten. Dies ist vorwiegend bei Problemen temporärer Natur wie kurzzeitigen Netzwerkausfällen oder einer Überlastung nützlich.

Dieses Muster kann jedoch komplexer werden, abhängig von den Anforderungen der Anwendung. Es kann unter anderem notwendig sein, die Wartezeit zwischen den Wiederholungsversuchen zu erhöhen oder bestimmte Arten von Fehlern von den Wiederholungsversuchen auszuschließen.

Auch zu häufige Wiederholungen sollten ausgeschlossen werden, damit z. B. im Falle einer Überlastung der aufgerufene Service nicht weiter belastet wird.

Timeouts

Ein weiterer wichtiger Punkt bei selbstheilendem Code und fehlertoleranten Architekturen sollten Timeouts sein. Operationen wie Netzwerk oder IO sollten immer mit einem Timeout versehen werden, damit niemals der Fall entsteht, dass auf unbestimmte Zeit auf Ressourcen gewartet wird.

Ähnliche Verfahren lassen sich in der Theorie auch anwenden, wenn längere Berechnungen getätigt werden. In einigen Fällen ist es hier sinnvoll, einen Timeout zu definieren.

Grundsätzlich sollte es immer das Ziel sein, endlose Warteschleifen zu vermeiden und Systemressourcen wie CPU oder Speicher wieder freizugeben. Auch erhält die Anwendung durch Timeouts eine gewisse Art an Kontrolle, da durch diese klar wird, wie lange bestimmte Prozesse maximal laufen dürfen.

Aus Sicht des Nutzers sind Timeouts hilfreich, da dieser nicht unnötige Wartezeiten in Kauf nehmen muss und eine zeitnahe Rückmeldung erhält, wenn auch im schlechtesten Fall in Form einer Fehlermeldung.

Ein interessanter Nebeneffekt ist, dass Timeouts teilweise zur Fehlersuche genutzt werden können. Wenn bestimmte Anforderungen ständig zu Timeouts führen, könnte dies auf ein tiefer liegendes Problem hinweisen, das analysiert werden sollte.

Tooling

Viele der beschriebenen Mechanismen können von Grund auf vom Entwickler implementiert werden. Allerdings existieren eine Reihe von Bibliotheken und Frameworks welche einen Teil dieser Arbeit abnehmen.

In der Java-Welt liefern Frameworks z. B. Spring Boot, Möglichkeiten für eine robuste Fehlerbehandlung. Bibliotheken, wie Resilience4j, bieten Lösungen für Selbstheilungsfunktionen und Fehlertoleranz. Sie ermöglicht es Entwicklern, selbstheilende Muster zu implementieren, wie Circut Breaker oder Fallback-Mechanismen, um Ausfälle effektiv zu behandeln.

Damit wird es einfacher und bequemer, selbstheilenden Code zu implementieren.

Self Healing Code in der Zukunft

Neben den klassischen Methoden, um selbstheilenden Code zu realisieren, werden in letzter Zeit immer mehr Varianten von Self Healing Code in Verbindung mit generativer KI postuliert, wie dem Large Language Model GPT-4.

Während die bisherigen Beispiele selbstheilender Systeme auf die Laufzeit abzielten, existieren auch Verfahren und Ideen, generative KI zu Nutzung bei der Entwicklung einzusetzen, um Quellcode „ohne Mitwirkung des Entwicklers“ zu realisieren.

Mittelfristig sind Systeme im breiten Einsatz denkbar, welche die Codebasis eines Projektes analysieren und basierend darauf Änderungen generieren, welche anhand von Pull-Requests dem menschlichen Entwickler vorgeschlagen werden können.

Ein Workflow zur Erzeugung automatisierter Änderungen via LLM

Damit bei den automatisiert erstellten Änderungen möglichst sichergestellt wird, dass sie auch funktionieren, können die Änderungen durch eine Continuous Integration-Pipeline entsprechenden Tests unterworfen werden. Nur wenn die Pipeline erfolgreich durchläuft, werden die Änderungen dem Entwickler vorgeschlagen.

So nutzt Microsoft mit InferFix ein System zur semiautomatischen Fehlerbehebung, um den Arbeitsablauf für interne Projekte zu verbessern. Auch andere Firmen, wie Stackoverflow, denken ebenfalls über die Nutzung von LLMs und generativer KI im Rahmen der Softwareentwicklung nach.

Automatisiertes Debugging

Solche „selbstheilenden Fähigkeiten“ können auch für die komplett automatische Fehlerbehebung genutzt werden. So existiert mit Wolverine ein Proof of Concept für ein solches System. Wolverine nutzt GPT-4 von OpenAI, um Fehler in einem Python-Skript zu reparieren.

Dabei werden Fehler im Skript in das Sprachmodell gegeben und anschließend die Lösung auf den Quelltext angewendet. Danach wird ermittelt, ob das Skript nach der Änderung funktioniert. Treten erneut Fehler auf, werden diese wieder an das LLM übermittelt und dessen Lösung wieder in das Skript übernommen.

Solche Verfahren könnten weitergedacht und direkt beim Nutzer, im Falle eines Fehlers, ausgeführt werden.

Auch in IDEs ziehen Plugins basierend auf generativer KI ein, wie das AI Assistant-Plugin von Jetbrains. Mit diesem können Fehlermeldungen und Codeteile analysiert und erklärt und eine weitere Interaktion mit den Sprachmodellen durchgeführt werden. Dazu zählen unter anderem das Generieren von Dokumentation, sowie von Namen.

Probleme

Im Idealfall können solche Systeme eine Arbeitserleichterung sein, allerdings führen sich auch zu Problemen. So ist nicht sichergestellt, dass die von der KI gefundenen Lösungen wirklich die geforderten fachlichen Spezifikationen erfüllen. Daneben kann sich die Codequalität verschlechtern, wenn solche Änderung ungeprüft übernommen werden.

Hier könnte es im Laufe der Zeit vorkommen, dass aus Bequemlichkeit dazu übergegangen wird, solche Änderungen automatisiert auf den Quellcode anzuwenden.

Auf lange Sicht kann dies dazu führen, dass die eigene Codebasis immer schlechter verstanden wird, wenn diese generativer KI „gepflegt“ wird und diese Änderungen ohne ein sinnvollen Reviewprozess übernommen werden. Es ist denkbar, dass sich die Verantwortlichkeit von der eigentlichen Implementation des Quellcodes immer mehr in Richtung des Reviews verschiebt.

Wenn es an den Einsatz generativer KI geht, müssen neben solchen Fragen auch datenschutzrechtliche und sicherheitstechnische Aspekte bedacht werden.

Auch sollte beachtet werden, dass generative KI, wie die meistgenutzten Modelle von OpenAI Kosten verursachen, welche meist je Token abgerechnet werden. Werden lokale Modelle genutzt, muss stattdessen Rechenleistung und dahinterstehende Infrastruktur bereitgestellt werden.

Daneben existieren Größenbeschränkungen. Modelle wie solche von OpenAI sind bezüglich der maximal verarbeitbaren Token beschränkt, sodass größere Quelltext auf diese Art und Weise nur schwer am Stück analysiert werden können.

In Bezug auf selbstheilenden Code und Systeme kann ein blindes Vertrauen zu erheblichen Problemen führen.

Beispielhaft könnte ein System nur bestimmte Datentypen verarbeiten. Wenn ein solches Datenfeld vom Typ Integer ist und der Nutzer nun stattdessen Zeichenketten sendet, würde die Anwendung dies ablehnen. In einem solchen Fall könnte ein auf KI basierendes System zur Behebung dieses Fehlers den Typ der Schnittstelle, so ändern, dass auch Zeichenketten erlaubt sind und somit weiteren Problemen die Tür öffnen.

Fazit

Self Healing Code bietet eine Reihe von Vorteilen, im Betrieb der Anwendungen und sollte beim Design entsprechender Applikationen und Systeme berücksichtigt werden.

So sind diese Systeme zuverlässiger, bieten erhöhte Verfügbarkeit, und verringern eventuelle Downtimes. Auch in der Wartung können solche Systeme günstiger sein.

Allerdings sollten die Schwierigkeiten bedacht werden. Die Entwicklung von selbstheilendem Code kann komplex sein. Es kann eine Herausforderung darstellen, effektive Mechanismen zur Fehlererkennung, Diagnosealgorithmen und Strategien zur Fehlerbehebung zu entwickeln, die reibungslos miteinander interagieren.

Daneben bedeutet Self Healing Code in vielen Fällen auch ein Overhead. Unter Umständen werden zusätzliche Systemressourcen, für die Erkennung und die Beseitigung von Problemen, benötigt.

Wenn fälschlicherweise Fehler erkannt werden und die selbstheilenden Mechanismen aktiv werden, kann dies problematisch sein. Dazu gehören die Schwierigkeit, solche Systeme zu testen und zu überprüfen, und die Möglichkeit, dass das System unvorhersehbare oder unerwünschte Änderungen vornimmt.

Neben dem klassischen selbstheilenden Code hält generative KI immer mehr Einzug in unseren Alltag und dies wird auch in Verbindung mit Self Healing Code keine Ausnahme sein. Allerdings sollte hier Vorsicht geboten sein und der Mensch nicht aus dem Loop genommen werden.

Self Healing Code hat das Potenzial, die Zuverlässigkeit und Verfügbarkeit von Systemen zu verbessern und dieses Potenzial sollte nicht brach liegen gelassen werden.

Who watches the Watchmen?

In die letzten Jahrzehnten nahm die Anzahl von Überwachungskameras stetig zu. Verzeichnet werden diese Kameras unter anderem im Datenbestand der freien Weltkarte OpenStreetMap. Auf Basis dieser OpenStreetMap-Daten gibt es nun eine dedizierte Karte welche die Überwachungskameras darstellt.

In einigen Regionen ist der Datenbestand noch verbesserungswürdig

In einigen Regionen ist der Datenbestand noch verbesserungswürdig

Zu finden ist diese Karte unter kamba4.crux.uberspace.de. Möchte man Kameras in seiner Nähe eintragen benötigt man einen OpenStreetMap-Account – anschließend können die Daten angetragen werden. Auf der Karte werden neben der Position der Kamera, auch der Typ und die Blickrichtung mit angezeigt.

Nein!

Auf Reddit erschien vor einiger Zeit ein Kommentar rund um die Überwachung. Diesen Kommentar übersetzte Alexander Bock ins Deutsche und stellte seine Übersetzung (wie das Original) gemeinfrei. Diesen Kommentar möchte hier unverändert weitergeben:

Ich lebe in einem Land, das allgemein als Diktatur betrachtet wird. Eines der Länder des arabischen Frühlings. Ich habe einige Ausgangsperren erlebt und auch gesehen, was eine Art Überwachung wie PRISM in den USA für Folgen hat. Die Leute, die hier (Anm.: auf Reddit) über Ausgangssperren reden, wissen nicht, wie sich das wirklich anfühlt. Es geht nicht darum, dass man hineingehen muss und die praktischen Folgen davon. Es geht darum, ein Gefühl zu schaffen, dass einfach jeder und einfach alles dich beobachtet. Ein paar Punkte:

1) der Zweck dieser staatlichen Überwachung ist es, Staatsfeinde zu kontrollieren. Nicht Terroristen. Menschen, die sich um Ideen scharen, die den Status Quo destabilisieren könnten. Das können religiöse Ideen sein. Das können Gruppen wie Anonymous sein, die sich besser mit Technik auskennen, als es dem Staat gefällt. Überwachung macht es leicht zu wissen, wer diese Menschen sind. Es macht es auch sehr leicht, diese Menschen zu kontrollieren.

Sagen wir du bist ein Student und triffst dich mit ein paar Leuten, die nicht-artgerechte Tierhaltung stoppen wollen. Also machst du einen Plan um gegen diese Art der Tierhaltung zu demonstrieren. Du kommst zur Demo und wow, sie ist riesig. Du hast das nicht erwartet, du hast doch nur rumgeblödelt. Nun, jetzt ist jeder, der dort war, verdächtig. Auch wenn du streng genommen das Recht hast, zu demonstrieren, wirst du von nun an als potentieller Gefährder betrachtet.

Mit dieser Technik müssen dich die Behörden nicht mehr ins Gefängnis werfen. Sie können etwas viel unheimlicheres tun. Sie können dir einfach ein schlüpfriges Foto, dass du mit deinem Partner aufgenommen hast, zuschicken. Oder dir eine Nachricht schicken, dass sie bei deinem Vater Steuerhinterziehung nachweisen können. Oder drohen, deinen Vater den Job verlieren zu lassen. Alles, was du tun musst, damit das nicht passiert, ist deine Freunde in der Gruppe zu verpfeifen. Du musst dich jede Woche melden, oder dein Vater verliert seinen Job. Also tust du es. Du verrätst deine Freunde und obwohl sie versuchen, unter dem Radar zu bleiben, berichtest du über ihre Aktivitäten um deinen Vater zu beschützen.

2) sagen wir mal, Nummer 1) geht einfach weiter. Das Land ist jetzt in einem eigenartigen Zustand. Wirklich eigenartig. Bald entstehen Bewegungen wie Occupy, nur noch größer diesmal. Die Menschen meinen es ernst, sie sagen sie wollen einen Staat ohne diese Macht. Wahrscheinlich sehen sie ein, dass das kein Spiel mehr ist. Du siehst in den Abendnachrichten, dass Tränengas eingesetzt wurde. Deine Freunde rufen dich panisch an. Sie erschießen Demonstranten. Oh Gott. Dafür hast du dich nie gemeldet. Du sagst, scheiß drauf. Mein Vater verliert vielleicht seinen Job, aber ich werde nicht verantwortlich dafür sein, dass Menschen sterben. Das geht zu weit. Du weigerst dich, weiter Bericht zu erstatten. Du hörst einfach auf, zu den Treffen zu gehen. Du bleibst zu Hause und versucht nicht mehr die Nachrichten zu schauen. Drei Tage später steht die Polizei vor der Tür und verhaftet dich. Sie konfiszieren deinen Computer und dein Handy. Sie verprügeln dich. Niemand kann dir helfen, also schauen sie alle still zu. Sie wissen, wenn sie etwas sagen, sind sie als nächstes dran. Das ist in dem Land passiert, in dem ich lebe. Es ist kein Witz.

3) Es ist schwer zu sagen, wie lange du drin warst. Was du gesehen hast, war schrecklich. Meistens hast du nur Schreie gehört. Menschen, die darum flehen, getötet zu werden. Geräusche, die du noch nie gehört hast. Du, du hattest noch Glück. Du wurdest jeden Tag getreten, wenn sie schimmelndes Essen nach dir geworfen haben, aber niemand hat dich mit Stromschocks traktiert. Niemand hat dich vergewaltigt, oder zumindest erinnerst du dich nicht. Manchmal haben sie dir Pillen gegeben, aber das war eigentlich der beste Teil des Tages, weil du dann wenigstens nichts gespürt hast. Du hast Narben von den Misshandlungen. Dir wird klar, dass Folter im Gefängnis mittlerweile normal ist. Aber jeder, der Videos oder Bilder der Folter hochlädt, ist ein “Leaker”. Es wird als Gefährdung der nationalen Sicherheit betrachtet. Bald schon sieht eine Wunde an deinem Bein richtig schlimm aus. Du denkst, sie ist entzündet. Es gab keine Ärzte im Knast. Und es war so voll, wer weiß was in die Wunde gelangt ist. Du gehst zum Arzt, aber er weigert sich, dich zu behandeln. Er weiß, die Regierung kann die Krankenakten sehen. Dass er dich behandelt hat. Ihn nur anzurufen hat schon dafür gesorgt, dass die örtliche Polizei ihn besucht hat.

Du entscheidest nach Hause zu gehen und deine Eltern zu sehen. Vielleicht können sie helfen. Das Bein wird immer schlimmer. Du kommst zu ihrem Haus, aber sie sind nicht da. Du kannst sie nicht erreichen, egal was du versuchst. Ein Nachbar nimmt dich zur Seite: sie wurden vor drei Wochen verhaftet und seitdem nicht mehr gesehen. Du erinnerst dich dunkel daran, ihnen am Telefon von den Protesten erzählt zu haben. Nicht mal dein kleiner Bruder ist da.

4) Passiert das wirklich? Du schaust die Nachrichten. Sport. Promis. Als ob nichts los wäre. Was zur Hölle geht vor? Ein Fremder grinst dich einfältig an, während du Zeitung liest. Du tickst aus. Du brüllst ihn an: “fick dich, Alter, kannst du nicht sehen, dass ich eine scheiß Wunde am Bein hab?”

“Sorry,” sagt er, “ich wusste einfach nicht, dass noch jemand die Zeitung liest.” Es gibt seit Monaten keine echten Journalisten mehr. Sie sind alle im Gefängnis.

Jeder um dich herum hat Angst. Sie können nicht reden, weil sie nicht wissen, wer für die Regierung spioniert. Scheiße, du hast mal für die Regierung spioniert. Vielleicht wollen sie nur ihr Kind durch die Schule kriegen. Vielleicht wollen sie ihren Job behalten. Vielleicht sind sie krank und wollen den Arzt besuchen können. Es ist immer ein einfacher Grund. Gute Menschen tun schlimme Dinge immer aus einfachen Gründen.

Du willst protestieren. Du willst deine Familie zurück. Du brauchst Hilfe für dein Bein. Das ist weit mehr, als du je wolltest. Es hat angefangen, weil du artgerechte Tierhaltung wolltest. Jetzt bist du praktisch Terrorist, und jeder um dich herum könnte dich ausspionieren. Du kannst sicher keine Telefone oder E-Mails benutzen. Du kriegst keinen Job. Du kannst nicht mal mehr Leuten von Angesicht zu Angesicht trauen. An jeder Ecke sind Menschen mit Waffen. Sie haben Angst wie du. Sie wollen einfach nicht ihre Jobs verlieren. Sie wollen nicht als Verräter gebrandmarkt werden.

Das ist alles in meinem Land passiert.

Willst du wissen, warum Revolutionen geschehen? Weil die Dinge Stück für Stück schlimmer und schlimmer werden. Aber was gerade geschieht, ist groß. Es ist die Schlüsselzutat. Es erlaubt ihnen alles zu wissen, was sie wissen müssen, um das oben beschriebene zu erreichen. Dass sie es tun, ist Beweis dafür, dass sie die Menschen sind, die Überwachung wie oben beschrieben einsetzen würden. In dem Land, in dem ich lebe, behaupteten sie auch mal, dass es zum Schutze der Menschen war. Genauso in der UdSSR. Genauso in der DDR. Es ist immer die selbe Ausrede, warum man alle überwachen müsse. Aber es war nie wahr!

Vielleicht wird Obama es nicht tun. Vielleicht wird es der nach ihm auch nicht tun, oder der nach ihm. Vielleicht geht’s hier nicht um dich. Vielleicht passiert es in 10 oder 20 Jahren, wenn ein großer Krieg tobt. Oder nach dem nächsten großen Anschlag. Vielleicht geht’s um deine Tochter oder deinen Sohn. Wir wissen es noch nicht. Aber was wir wissen: wir haben jetzt eine Wahl. Sind wir damit einverstanden oder nicht? Wollen wir diese Macht einräumen oder nicht?

Weißt du, warum mich das so aufregt? Weil ich in den USA groß geworden bin und dabei jeden Tag das Treue-Gelöbnis aufgesagt habe. Mir wurde beigebracht, dass die Vereinigten Staaten für “Freiheit und Gerechtigkeit für alle” standen. Du wirst älter und lernst, dass wir in diesem Land diesen Satz durch die Verfassung definieren. Sie sagt uns, was Freiheit und Gerechtigkeit sind. Nun, der Staat hat dieses Ideal verletzt. Also, wenn er nicht mehr für Freiheit und Gerechtigkeit steht, wofür steht er dann? Sicherheit?

Stell dir eine Frage: Klingt irgendwas in der Geschichte oben nach Sicherheit?

Ich habe mir nichts ausgedacht. Diese Dinge sind Menschen passiert, die ich kenne. Wir dachten, das könnte bei uns nicht passieren. Aber stell dir vor: Es hat angefangen zu passieren.

Es regt mich auf, wenn Leute sagen “ich habe nichts zu verbergen, lasst sie alles lesen”. Die, die das sagen, haben keine Ahnung was sie sich damit einbrocken. Sie sind naiv. Wir müssen auf die Leute in anderen Ländern hören, die uns klar sagen, dass das ein furchtbares Zeichen ist. Ein Zeichen, dass es Zeit ist aufzustehen und zu sagen: nein!