Gerade funktioniert etwas nicht
Schreiben Sie an den Support mit Ihrer Workspace-Adresse, was Sie gerade getan haben und ungefähr seit wann es auftritt. Über die Workspace-Adresse findet jemand die Organisation schnell.
support@enclessa.appDienststatus
Enclessa ist in der offenen Beta und veröffentlicht keinen Live-Status-Endpunkt, keinen Verfügbarkeitsprozentsatz und keine Störungshistorie, weil nichts davon gemessen würde – und eine Statusseite, die Zahlen meldet, die niemand erhebt, ist schlechter als keine. Was Enclessa veröffentlicht, ist die betriebliche Lage, und die Beta gehört dazu: wo der Dienst läuft, wie eine fehlerhafte Instanz aus dem Betrieb genommen wird, was als Störung gilt, wie sie kommuniziert wird und wo die Wiederherstellung spezifiziert, aber noch nicht umgesetzt ist. Solange es keinen Live-Status gibt, erreichen Sie über die Kontaktwege unten einen Menschen.
Aktualisiert
- Entwicklungsstand
- Offene Beta
- Live-Status
- Noch nicht veröffentlicht
- Verfügbarkeitszahl
- Keine – nicht gemessen, nicht behauptet
- Störungshistorie
- Keine geführt
- Verfügbarkeitszusage
- In keinem Tarif
- Hosting
- Eine Region der Europäischen Union
- Problem melden
- support@enclessa.app
Wo der Dienst läuft
Enclessa ist eine mandantenfähige Installation in einer einzigen Region der Europäischen Union, betrieben von einem deutschen Unternehmen, und jede Kundenorganisation ist unter einer eigenen Subdomain erreichbar. In den Standardtarifen gibt es innerhalb der Region keine Wahl des Landes und keine eigenen Domains.
- Eine Region der Europäischen Union, eine Installation, viele Kundenorganisationen
- Die Anwendung, das Echtzeit-Gateway und die öffentliche Website laufen hinter einem gemeinsamen Edge-Proxy
- Datenbank, Nachrichtenschicht, Objektspeicher und Medienserver laufen jeweils als einzelne Instanz, fest an einen Knoten gebunden
- Die Prozesse von Anwendung und Gateway laufen mit mehr als einem Replikat, sodass der Ausfall eines einzelnen Prozesses kein Ausfall des Dienstes ist
- Eine Organisation, die ein bestimmtes Land braucht, kauft unter Enterprise eine eigene Bereitstellung, die wir betreiben
Wie eine fehlerhafte Instanz aus dem Betrieb genommen wird
Jeder Dienst stellt zwei getrennte Prüfungen bereit statt einer, und der Unterschied zwischen ihnen macht ein rollierendes Deployment sicher. `/healthz` beantwortet, ob der Prozess lebt; `/readyz` beantwortet, ob das, wovon er abhängt, erreichbar ist. Der Orchestrator startet anhand der ersten neu, der Edge-Proxy leitet anhand der zweiten weiter – eine Instanz, die läuft, aber die Datenbank nicht erreicht, bekommt also keinen Verkehr mehr, statt Anfragen scheitern zu lassen.
- Der Edge-Proxy leitet nur an Instanzen weiter, deren Bereitschaftsprüfung besteht, und prüft laufend neu
- Der Orchestrator startet einen Prozess neu, dessen Lebendprüfung scheitert
- Datenbankmigrationen sind über genau eine Version hinweg abwärtskompatibel, sodass alte und neue Prozesse während eines Updates gegen dasselbe Schema laufen können
- Die Anwendung verweigert den Start gegen ein zu altes Schema und akzeptiert ein neueres
- Die Konfiguration wird vor dem Start geprüft, und unsichere Kombinationen werden abgelehnt statt nur protokolliert
Was als Störung gilt
Eine Störung wird dadurch bestimmt, was ein Kunde beobachten kann, nicht dadurch, was ein internes Dashboard zeigt. Eine überlaufende Warteschlange, die niemand bemerkt, ist ein technisches Problem; eine Nachricht, die nicht ankommt, ist eine Störung. Enclessa unterscheidet drei Stufen, und die Stufe entscheidet, wie schnell jemand informiert wird, nicht, wie dringend daran gearbeitet wird – an allem unten wird sofort gearbeitet.
- Schwer – der Dienst ist für einen erheblichen Teil der Organisationen unbenutzbar: Die Anmeldung scheitert, Nachrichten werden nicht gesendet oder die Anwendung lädt nicht
- Teilweise – eine Funktion ist nicht verfügbar oder deutlich beeinträchtigt, während der Rest funktioniert: Anrufe bauen sich nicht auf, Uploads werden abgelehnt, die Suche liefert nichts oder Benachrichtigungen werden nicht zugestellt
- Wartung – eine geplante Änderung mit erwarteter, für Kunden sichtbarer Auswirkung, die vorher angekündigt statt hinterher gemeldet wird
- Ein Sicherheitsvorfall, der personenbezogene Daten betrifft, wird gesondert und nach gesetzlichem Zeitplan behandelt und im Trust-Center beschrieben, nicht hier
- Eine verminderte Leistung, die die Arbeit nicht aufhält, ist keine Störung und wird auch nicht als solche gemeldet
Wie eine Störung kommuniziert wird
Solange es keinen öffentlichen Status-Endpunkt gibt, wird direkt kommuniziert statt öffentlich verbreitet. Das ist ein kleineres Versprechen als eine Statusseite, und eines, das sich bei der heutigen Größe tatsächlich halten lässt – das ist der Tausch, den diese Seite überall macht.
- Eine schwere Störung wird dem Inhaber und den Administratoren jeder betroffenen Organisation mitgeteilt
- Die Mitteilung sagt, was betroffen ist, was nicht und was getan wird – bevor sie sagt, was die Ursache war
- Eine Störung, die sich als kleiner herausstellt als zuerst gemeldet, wird im selben Kanal korrigiert, nicht stillschweigend fallengelassen
- [[ Benachrichtigungskanal und Zielzeit bis zur ersten Meldung bei einer schweren Störung bestätigen, dann diesen Satz ersetzen – keine Zeit veröffentlichen, zu deren Einhaltung sich niemand verpflichtet hat. ]]
- [[ Entscheiden, ob betroffenen Organisationen eine schriftliche Nachbetrachtung angeboten wird, und innerhalb welcher Frist. ]]
Die Lage bei der Wiederherstellung, genau benannt
Diesen Abschnitt würden die meisten Statusseiten weglassen. Die Architektur spezifiziert eine Wiederherstellung – regelmäßige vollständige und inkrementelle Datenbanksicherungen mit fortlaufender Archivierung des Write-Ahead-Logs in einen Objektspeicher, Replikation gespeicherter Dateien und eine verpflichtende vierteljährliche Wiederherstellungsübung. Diese Vorkehrung ist in der gehosteten Bereitstellung noch nicht umgesetzt, und so zu tun, als wäre sie es, wäre die schlimmste Art von Behauptung, bei der man falschliegen kann.
- Die fortlaufende Archivierung des Write-Ahead-Logs ist spezifiziert und in der Bereitstellung derzeit abgeschaltet, weil das Werkzeug, das sie ausführt, noch nicht Teil des Datenbank-Images ist
- Es wurde noch keine Wiederherstellungsübung durchgeführt, und eine ungetestete Sicherung ist keine Sicherung
- Die Nachrichtenschicht wird bewusst nicht gesichert: Sie trägt flüchtige Arbeit, der dauerhafte Bestand liegt in der Datenbank, ihr Verlust kostet also eine erneute Zustellung, keine Daten
- Clientseitige Schlüssel kann Enclessa überhaupt nicht sichern – die Wiederherstellungsphrase, die der Nutzer hält, ist die einzige Sicherung, die es für sie gibt
- Diese Lücke zu schließen, ist laufende Betriebsarbeit und der Grund, warum keine Verfügbarkeitszahl veröffentlicht wird
Was nicht zugesagt ist
In keinem Tarif ist eine Verfügbarkeitszahl vertraglich zugesagt, und Enclessa veröffentlicht nirgends auf dieser Website eine. Interne technische Zielwerte für Latenz und Verfügbarkeit gibt es; sie entscheiden, worauf alarmiert wird. Sie sind keine Zusagen an Kunden und werden hier bewusst nicht wiedergegeben, denn ein interner Zielwert auf einer Marketingseite wird in jedem folgenden Gespräch zu einem Service Level Agreement.
- Es wird kein Verfügbarkeitsprozentsatz veröffentlicht, weil keiner gemessen und veröffentlicht wird
- Kein Service Level Agreement, keine Gutschriften und keine Verfügbarkeitsgarantie in den Standardtarifen
- Eine Störungshistorie gibt es nicht, weil keine geführt wurde
- [[ Entscheiden, was Enterprise gegebenenfalls vertraglich zusagt – eine benannte Ansprechperson und einen Eskalationsweg oder eine Zahl – und das hier und in den AGB gleichlautend festhalten. ]]
Was Sie bis dahin tun können
Es gibt keinen Status zum Aktualisieren, also führt der Weg zu einer Antwort über einen Menschen. Diese Adressen werden betreut und sind dieselben wie auf der Kontaktseite.
Sie vermuten ein Sicherheitsproblem
Melden Sie es vertraulich statt öffentlich. Sie erhalten eine Bestätigung und einen Zeitplan, und eine Meldung wird nie dafür bestraft, dass sich am Ende nichts findet.
security@enclessa.appSie brauchen die Betriebsdetails für eine Einkaufsprüfung
Das Trust-Center behandelt Auftragsverarbeitungsvertrag, Unterauftragsverarbeiter, Datenresidenz und Meldung von Datenschutzverletzungen. Alles, was es nicht beantwortet, geht an die Enterprise-Adresse.
enterprise@enclessa.app
Warum diese Seite keine grünen Häkchen hat
- Eine Statusseite ist eine Messung, und Enclessa misst noch nicht, was sie melden würde. Ein Dashboard mit „Alle Systeme betriebsbereit“, das an nichts angeschlossen ist, ist Dekoration.
- Ein Verfügbarkeitsprozentsatz, der veröffentlicht wird, bevor er erhoben ist, wird zu einer Zahl, die Ihnen jemand während einer Störung vorhält. Es gibt keine Fassung dieses Gesprächs, die gut ausgeht.
- Eine vorab befüllte Störungshistorie – drei ordentlich gelöste Einträge aus dem letzten Quartal – ist das Einfachste, was sich auf einer Marketingseite erfinden lässt, und das Einfachste, was sich aufdecken lässt. Enclessa hatte keine Störungen im Produktivbetrieb zu melden, weil es keine Störungsaufzeichnung aus dem Produktivbetrieb hat.
Verwandte Seiten
Die Sicherheitsseite behandelt, was die Daten schützt und welche Zertifizierungen Enclessa nicht hat. Das Trust-Center behandelt Meldung von Datenschutzverletzungen, Unterauftragsverarbeiter und Datenresidenz für eine Einkaufsprüfung. Die Roadmap führt die Arbeit an der Hochverfügbarkeit und den öffentlichen Status-Endpunkt unter dem auf, was noch nicht gebaut ist.
Fragen
- Nein. Enclessa veröffentlicht keinen Live-Status-Endpunkt, keinen Verfügbarkeitsprozentsatz und keine Störungshistorie, weil das Monitoring, das sie liefern würde, noch keinen öffentlichen Endpunkt speist. Eine nicht gemessene Zahl zu veröffentlichen, wäre schlechter, als gar nichts zu veröffentlichen. Bis es einen echten Status gibt, dokumentiert diese Seite deshalb die betriebliche Lage, und support@enclessa.app ist der Weg zu einem Menschen.
- Keine, und der Dienst ist in der offenen Beta. In keinem Tarif ist eine Verfügbarkeitszahl vertraglich zugesagt, und nirgends auf dieser Website wird eine veröffentlicht. Interne technische Zielwerte gibt es, und sie entscheiden, worauf alarmiert wird – aber sie sind keine Zusagen an Kunden und werden bewusst nicht so zitiert, als wären sie es.
- Solange es keinen öffentlichen Status gibt, wird eine schwere Störung direkt dem Inhaber und den Administratoren jeder betroffenen Organisation mitgeteilt – mit dem, was betroffen ist und was nicht, bevor es um die Ursache geht. Das ist ein kleineres Versprechen als eine Statusseite, und eines, das sich bei der heutigen Größe halten lässt.
- Die Architektur spezifiziert regelmäßige Datenbanksicherungen mit fortlaufender Archivierung des Write-Ahead-Logs und Replikation gespeicherter Dateien, und diese Vorkehrung ist in der gehosteten Bereitstellung noch nicht umgesetzt – die Archivierung ist derzeit abgeschaltet, und es wurde noch keine Wiederherstellungsübung durchgeführt. Enclessa sagt das, statt eine Sicherung anzudeuten, die nie wiederhergestellt wurde. Ein vollständiger Export der Organisation steht Ihnen jederzeit in offenen Formaten zur Verfügung, und er ist der Wiederherstellungsweg, den Sie selbst in der Hand haben.
- In einer Region der Europäischen Union, als eine einzige mandantenfähige Installation, betrieben von einem deutschen Unternehmen, mit jeder Kundenorganisation auf einer eigenen Subdomain. In den Standardtarifen gibt es innerhalb der Region keine Wahl des Landes. Eine Organisation, die ein bestimmtes Land verlangt, kauft im Enterprise-Tarif eine eigene Bereitstellung, die weiterhin von Enclessa betrieben und aktualisiert wird.
Legen Sie in ein paar Minuten einen Workspace an. Er gehört Ihnen, erreichbar unter your-team.enclessa.app, betrieben in der Europäischen Union, mit Ende-zu-Ende-verschlüsselten Direktnachrichten ab der ersten.