Ein Zeitlimit ist kein Stoppknopf

Jeder entfernte Befehl braucht eine Frist. Das ist unstrittig: Ein Prozess, der ewig warten kann, wird irgendwann ewig warten, und eine einzige hängende Anfrage hält einen Worker, eine Verbindung und eine Zeile in Ihrer Warteschlange fest, bis jemand irgendetwas neu startet.

Viel weniger offensichtlich ist, was die Frist tatsächlich bewirkt. Sie beendet das Warten auf Ihrer Seite. Sie beendet im Regelfall nicht die Arbeit auf der anderen Seite. Alles Schwierige an langlaufenden Vorgängen wohnt in dieser Lücke.

Wir betreiben einen Agenten auf den Hypervisoren unserer Kunden und schicken ihm Befehle. Das Backup einer virtuellen Maschine ist der Befehl, der uns diese Lücke ernst nehmen ließ, denn ein Backup darf ehrlich eine Stunde dauern, und eine Stunde ist genau dort, wo unsere eigenen Grenzen liegen.

Die Obergrenze ist keine Vorliebe

Unser Agent begrenzt jede Befehlsfrist auf eine Stunde. Die Plattform darf mehr verlangen; sie bekommt es nicht. Die Begrenzung ist ein einziges min() auf den Wert, der in der Anfrage ankommt, wobei null als „nicht gesetzt“ gilt und ein Rückfallwert von zwei Minuten greift, wenn das Feld fehlt.

Diese Begrenzung hat eine Folge, die man übersieht, wenn man Zeitlimits in einer Konfigurationsdatei setzt. Glaubt die Plattform an eine Frist, an die der Agent nicht glaubt, haben Sie zwei Systeme, die sich uneinig sind, wann ein Befehl tot ist, und diese Uneinigkeit zeigt sich als schlimmstmögliches Symptom: Der Agent gibt auf, meldet und macht weiter, während die Plattform die Zeile weiterhin offen hält und auf eine Antwort wartet, die nie in der erwarteten Form kommen wird.

Die Regel, bei der wir gelandet sind, ist langweilig und trotzdem wert, aufgeschrieben zu werden. Jedes Zeitlimit auf der Plattformseite wird mit der Decke des Agenten im Raum gewählt. Unsere Fristen für Backup und Wiederherstellung liegen bei genau einer Stunde, weil das die Decke ist, und von mehreren Dutzend Befehlsfristen sind sie die einzigen beiden, die sie berühren.

Fristen sind keine Geschmacksfrage

So sehen unsere Befehlsfristen tatsächlich aus, und hier steht, warum jede einzelne ist, was sie ist.

Zwei dieser Zeilen sind eher Geschichten als Zahlen.

Die mit der Cloud-Maschine fiel früher auf den Standardwert von zwei Minuten zurück. Zwei Minuten reichen für ein Abbild, das zufällig aktuell ist, und für nichts anderes; also meldete die Plattform einen Fehlschlag, während die Installation innerhalb der Maschine weiterlief und wenige Minuten später fertig wurde. Die Bestellung wurde als gescheitert markiert. Die Maschine lief. Das ist die schlimmste Art von falsch: kein Fehler, sondern ein Widerspruch, und auflösen muss ihn der Kunde.

Die mit der Migration ist die längste Frist, die nicht die Obergrenze des Agenten ist, und die Begründung dahinter ist eine Zählung und kein Gefühl. Der Migrator macht einen API-Aufruf je Benutzer und einen je Server gegen das Zielpanel. Bei tausend Servern sind das tausend Aufrufe hinaus und tausend Antworten zurück, davor ein vollständiges Auslesen beider Seiten und danach eine Nachzählung.

Die Kosten eines Irrtums sind nicht symmetrisch

Das ist das Prinzip unter beiden Geschichten. Eine zu kurze Frist und eine zu lange Frist scheitern auf völlig verschiedene Weise, und wer sie als zwei Seiten desselben Reglers behandelt, bekommt jedes Mal die falsche Zahl.

Zu lang: Ein Vorgang, der wirklich gestorben ist, hält eine Zeile eine Weile länger offen. Jemand wartet. Nichts wird beschädigt, nichts wird verdoppelt, und das spätere Aufräumen verläuft ereignislos.

Zu kurz: Sie verzeichnen einen Fehlschlag für Arbeit, die gelungen ist. Jetzt widersprechen sich Ihre Aufzeichnungen und die Wirklichkeit, und jeder Erholungsweg, den Sie haben (erneut versuchen, neu anlegen, erstatten, alarmieren), zielt auf ein Problem, das es nicht gibt, und erzeugt ein zweites.

Das ist nicht gleich schlimm, also sollten beide nicht gleich große Sicherheitsabstände bekommen. Für alles, was echte Ressourcen anlegt, verschiebt oder löscht, wählen wir bewusst die großzügige Seite und schreiben auf, warum.

Zwei Uhren, die zu verschiedenen Zeitpunkten starten

In jedem System mit einer Befehlswarteschlange steckt eine Feinheit, die man leicht übersieht und leicht messen kann. Unsere Plattform berechnet die Frist als absoluten Zeitpunkt, in dem Augenblick, in dem die Befehlszeile geschrieben wird. Der Agent berechnet seine Frist als Dauer, beginnend mit dem Start der Ausführung.

Das sind verschiedene Uhren. Ist der Agent offline oder beschäftigt, oder liegt der Befehl dreißig Sekunden in der Warteschlange, hat die Plattform bereits dreißig Sekunden ihres Budgets ausgegeben und der Agent nicht. Die Plattform gibt zuerst auf.

Das ist die richtige Reihenfolge, und es lohnt sich, ausdrücklich zu sagen, warum. Die Frist der Plattform beantwortet die Frage, die der Kunde tatsächlich stellt: Wie lange ist es her, dass ich geklickt habe? Die des Agenten beantwortet eine andere: Wie lange darf dieses Stück Arbeit laufen? Die verstrichene Zeit ab dem Klick ist die Zahl, um die es in einem Supportgespräch geht. Beide gleich zu machen wäre ordentlicher und würde die falsche Frage beantworten.

Eine dritte Uhr versteckt sich dort ebenfalls. Auf unserem Agenten geschieht das Warten auf eine Nebenläufigkeitserlaubnis außerhalb der Ausführungsfrist. Ein Befehl, der hinter einem anderen Befehl gegen dieselbe Integration wartet, verbrennt währenddessen nicht sein eigenes Budget. Sind Ihre Fristen knapp, prüfen Sie, welche Ihrer Uhren die Wartezeit einschließt; die Antwort steht selten in der Dokumentation.

Was die Frist tatsächlich abbricht

Läuft die Frist des Agenten ab, signalisiert er einen Abbruch und hört auf zu warten. Was dieser Abbruch erreicht, ist Ihr eigener Code: die Abfrageschleife, die den Hypervisor gefragt hat, wie es der Aufgabe geht.

Er erreicht den Hypervisor nicht. Das Backup läuft weiter. Es wird fertig, oder es scheitert, vollständig ohne uns. Nichts vom Abbruch ist bis zum Speicher-Array gereist.

Das ist keine Einschränkung, die man wegkonstruieren sollte. Es ist die ehrliche Form des Problems, und der nützliche Zug besteht darin, das Ergebnis wahrheitsgemäß zu verzeichnen, statt so zu tun als ob. Die Einteilung, die den Kontakt mit der Produktion überlebt hat, hat drei Ausgänge und nicht zwei.

• Fehlgeschlagen. Wir wissen, dass nichts passiert ist. Der Kunde kann es erneut versuchen, und es gibt nichts aufzuräumen.
• Unbekannt. Wir haben aufgehört zuzuhören, bevor es eine Antwort gab. Möglicherweise existiert etwas.
• Abgleich nötig. Wir haben positiven Grund zu der Annahme, dass etwas existiert, für das wir nicht Rechenschaft ablegen können.

Eine Wiederherstellung, die in ein Zeitlimit läuft, ist der schärfste Fall. Möglicherweise läuft am Hypervisor jetzt eine Maschine, für die unsere Datenbank keine Zeile hat. Sie als gescheitert zu markieren wäre eine Lüge, die eine Maschine verbirgt; sie als gelungen zu markieren wäre eine Lüge, die eine erfindet. Sie wird als prüfbedürftig markiert, und das Panel bittet den Kunden nachzusehen, statt ihm einen Knopf für einen erneuten Versuch anzubieten, der eine zweite Maschine neben die erste bauen würde.

Diese Regel steht im Code als Liste der sicheren Fälle, nicht der unsicheren. Vier bestimmte Fehlercodes bedeuten, dass die Arbeit nie begonnen hat, denn alle vier stammen aus Prüfungen, die der Agent ausführt, bevor er den ersten Aufruf macht. Alles andere, einschließlich jedes Fehlercodes, den wir später hinzufügen und einzuordnen vergessen, gilt standardmäßig als unsicher. Die Richtung zählt: Ein vergessener Code, der still als Fehlschlag verbucht wird, lässt eine vorhandene Maschine aus den Aufzeichnungen verschwinden, und ein vergessener Code, der als unsicher verbucht wird, kostet jemanden nur einen Blick.

Ein unsicheres Ergebnis braucht einen Weg, sicher zu werden

Ein Status, der „jemand sollte nachsehen“ bedeutet, ist nur dann ehrlich, wenn jemand oder etwas tatsächlich nachsieht. Unserer ist ein Worker, der regelmäßig jede Maschine mit Backup-Vergangenheit bittet, ihre Wiederherstellungspunkte erneut aufzulisten, damit ein Archiv, das beim Anbieter still verschwunden ist, zu einer Benachrichtigung wird und nicht zu einer Liste, die an dem Tag kürzer war, an dem ein Kunde zufällig hinsah.

Auf dieser Schleife liegt eine bewusste Sparsamkeitsauflage, denn jede Auflistung ist ein Befehl, der auf dem Host von jemand anderem läuft. Sie besucht nur Maschinen, die eine Richtlinie oder mindestens einen bekannten Wiederherstellungspunkt haben, und nimmt je Runde eine begrenzte Menge. Wenn das nicht mehr reicht, ist der richtige Umbau ein Cursor und keine größere Zahl.

Die Schleife muss außerdem überleben, dass zwei Ihrer eigenen Server sie in derselben Sekunde ausführen wollen. Wir lösen das mit einem dauerhaften Idempotenzschlüssel aus der Maschine und der Fensternummer, nicht aus einem Zeitstempel: Zwei Server ticken nie in derselben Millisekunde, aber sie liegen mit Sicherheit im selben Sechs-Stunden-Fenster, ein Zeitstempel würde also nichts entdoppeln.

Was wir Ihnen zu notieren raten würden

Wenn Sie Fristen für entfernte Arbeit wählen, bringen vier Fragen Sie fast ans Ziel.

1. 01Was ist die harte Decke, und wer setzt sie durch? Sind sich zwei Bestandteile uneinig, gewinnt in der Praxis der kleinere, und der größere ist Fiktion.
2. 02Wann startet jede Uhr? Die Wartezeit ist entweder im Budget oder nicht, und beide Antworten sind vertretbar. Es nicht zu wissen ist es nicht.
3. 03Was bricht der Ablauf ab? Lautet die Antwort „unser eigenes Warten“, sagen Sie es laut, denn der Rest des Entwurfs folgt daraus.
4. 04Auf welche Seite fällt ein nicht eingeordnetes Ergebnis? Machen Sie die Unsicherheit zum Standard und lassen Sie die Sicherheit das sein, was Sie aufschreiben müssen.

Nichts davon macht ein langes Backup kürzer. Es macht die Aufzeichnung darüber wahr, und das ist der Teil, den Sie um zwei Uhr nachts lesen werden.