Jede Plattform fällt irgendwann aus. Ihre, die des Wettbewerbers, die des Hyperscalers unter beiden: Verfügbarkeit ist ein Prozentwert, kein Versprechen von Unsterblichkeit, und ein Managed Service Provider, der die schlechte Stunde nicht geplant hat, setzt die Kundenbeziehung auf Glück. Die Position des Resellers hat eine unbequeme Struktur: fällt die Plattform aus, ruft der Kunde Sie an und nicht den Anbieter, denn im Portal steht Ihr Logo. Doch gut gehandhabte Ausfallzeit ist mehr als Schadensbegrenzung. MSPs, die eine disziplinierte Störungsroutine fahren, kommen aus Ausfällen regelmäßig mit mehr Kundenvertrauen heraus als sie hineingingen, denn der Ausfall ist der eine Moment, in dem der Kunde Ihnen wirklich bei der Arbeit zusieht.
Die Routine unten reicht von vor der Störung bis nach ihr.
Vorher: zuerst davon wissen, und wissen, was “ausgefallen” heißt
Die unverzeihliche Variante von Ausfallzeit ist, davon von einem Kunden zu erfahren. Unabhängige Überwachung ist die Abhilfe: eine externe Prüfung, die den echten Kundenpfad durchläuft, Daten hinein, API-Abfrage, Portalaufruf, von außerhalb der plattformeigenen Infrastruktur, dazu ein Abonnement der Statusseite des Anbieters. TagoIO veröffentlicht den Status unter status.tago.io, und Ihre Überwachung sollte das automatisch einbeziehen. Die Erkennungsebene ist auch der Ort, an dem die Analytics und Zustandsprüfungen der Plattform selbst helfen: Anomalieerkennung auf Flottenebene unterscheidet “das Gateway eines Standorts hat Strom verloren” von “die Datenaufnahme ist überall gleichzeitig gestoppt”, zwei Störungen mit unterschiedlichen ersten Schritten.
Genauso wichtig ist zu wissen, was ausgefallen für Ihren Service konkret bedeutet. Ein IoT-Stack fällt in Schichten aus, Sensoren, Konnektivität, Network Server, Plattform, Integrationen, und die Geltungsklauseln Ihres SLA sollten längst abbilden, wem welche Schicht gehört. Wie sich diese Dokumente beim Übergang zu wiederkehrenden Services ändern, haben wir behandelt. Die meisten Tickets mit “Plattform ausgefallen” sind eigentlich Konnektivität oder Hardware, und die Schicht in den ersten zehn Minuten zu bestimmen entscheidet, ob Sie einen Ausfall kommunizieren oder einen Techniker losschicken.
Währenddessen: puffern, wo es geht, kommunizieren, als ob es zählt
Zwei Eigenschaften des IoT federn die meisten Plattformausfälle ab, und Ihre Architektur sollte beide nutzen.
Erstens puffern oder wiederholen LoRaWAN Network Server und die meisten Gateways Uplinks, und Geräte messen ohnehin weiter, sodass ein Ausfall der Speicherschicht meist verzögerte statt verlorene Daten bedeutet. Das tatsächliche Pufferverhalten Ihres Stacks zu kennen, wie lange und auf welcher Schicht, verwandelt “sind meine Daten weg?” in eine Frage, die Sie präzise beantworten können, und jeder Kunde stellt sie.
Zweitens halten Edge-Komponenten die lokale Logik am Leben: wo ein Anwendungsfall Cloud-Lücken wirklich nicht verträgt, hält eine lokale Schicht wie TagoCore Alarmierung und Steuerung vor Ort durch eine Cloud-Störung hindurch am Laufen, und das gehört bei kritischen Installationen ins Entwurfsgespräch, nicht in die Entschuldigung danach.
Dann der Teil, den MSPs unterschätzen: der Takt der Kommunikation schlägt ihren Inhalt. Die Routine, die funktioniert, ist fest und langweilig. Melden Sie sich innerhalb der ersten 30 Minuten bei allen betroffenen Kunden, bevor Tickets aufgehen, mit dem, was Sie wissen, was noch funktioniert und wann die nächste Meldung kommt. Melden Sie sich zum angekündigten Zeitpunkt, auch wenn die Meldung “keine Änderung” lautet. Spekulieren Sie nie über einen Behebungszeitpunkt, den Sie nicht kontrollieren; geben Sie die Schätzung des Anbieters weiter und kennzeichnen Sie sie als solche. Kunden verzeihen Ausfallzeit mit erstaunlicher Zuverlässigkeit. Schweigen verzeihen sie nicht.
Währenddessen: wofür Ihr SLA da war
Die Störung ist der Moment, in dem sich der Papierkram bezahlt. Schweregrade lenken die Reaktion, Geltungsklauseln bewahren Sie davor, sich für einen Ausfall beim Mobilfunkbetreiber zu entschuldigen, und die Deckungsgleichheit zwischen Ihrem Kunden-SLA und dem SLA Ihres Anbieters entscheidet, ob ein schlechter Monat Marge kostet oder nur Gutschriften, die sich oben ausgleichen. Legt eine Störung eine Lücke zwischen den beiden Dokumenten offen, ist das eine Vertragskorrektur und nicht bloß eine betriebliche Lehre.
Danach: die Routine, die Ausfälle in Verlängerungen verwandelt
Sobald der Betrieb wiederhergestellt ist, schließen drei Schritte den Kreis richtig.
Prüfen Sie die Datenintegrität, bevor Sie Erfolg melden: kontrollieren, ob die gepufferten Uplinks angekommen sind, Lücken auffüllen, wo der Stack es zulässt, und den Kunden sagen, was der Datenbestand für das Ausfallfenster tatsächlich zeigt. Senden Sie innerhalb von 48 Stunden eine kurze Nachbetrachtung, was passiert ist, welche Auswirkung es hatte, was sich ändert, in einfacher Sprache und unaufgefordert. Gewähren Sie Servicegutschriften von selbst, wenn das SLA sie auslöst; eine bereits korrigierte Rechnung bringt mehr Wohlwollen als die Gutschrift selbst.
Und dann führen Sie die Störung in die Maschine zurück: braucht die Überwachung eine neue Prüfung, braucht ein kritischer Kunde eine Edge-Komponente, spiegelt die Preisgestaltung der Supportstufen wider, wer die Störungsstunden tatsächlich verbraucht hat?
Der stille Schluss
Ein MSP kann nicht versprechen, dass eine Plattform nie ausfällt. Was ein MSP versprechen und sich bezahlen lassen kann, ist: der Fehler wird in Minuten erkannt, der richtigen Schicht zugeordnet, nach Zeitplan kommuniziert, gepuffert, wo die Architektur es erlaubt, und mit einer ehrlichen Abrechnung geschlossen. Das ist ein Produkt, und es zählt zu den stärksten Unterscheidungsmerkmalen, die ein Managed Service verkaufen kann, genau weil die meisten Wettbewerber improvisieren.
Es beginnt außerdem mit einem Anbieter, dessen Grundlage Sie trauen können: veröffentlichter Status, veröffentlichtes SLA, auditierter Betrieb. TagoIO gibt Resellern dieses Fundament. Demo buchen oder kostenlos starten.
