Zum Hauptinhalt springen

Einführung

Warum eine Flotte von Telefonanlagen eine eigene Oberfläche braucht.

Ein Systemhaus betreut selten eine Anlage. Es betreut dreißig, hundert oder vierhundert – bei verschiedenen Kunden, in verschiedenen Netzen, mit verschiedenen Versions- und Modulständen. Dieses Kapitel erklärt, welches Problem StarfleetController dabei löst, wie die Plattform aufgebaut ist und was sie heute leistet.

Es beschreibt Zusammenhänge, keine einzelnen Schalter. Wie Sie eine Anlage konkret anbinden, steht unter Anlage anbinden; worauf die Absicherung im Einzelnen beruht, im Kapitel Sicherheit.

Das Problem: Jede Anlage einzeln aufzurufen skaliert nicht

Eine STARFACE steht beim Kunden. Sie hängt hinter einem Router mit NAT, hat meist keine feste öffentliche Adresse, oft kein VPN zu Ihnen und ein Zertifikat, das irgendwann wechselt. Wer etwas wissen will, meldet sich an – einzeln, Anlage für Anlage.

Drei Fragen kosten dadurch täglich Zeit:

Heute: nachsehen

  • „Auf welchen Anlagen läuft noch die alte Version?" – jede einzeln aufrufen.
  • „Wo ist das Modul installiert, aber nicht lizenziert?" – jede einzeln aufrufen.
  • „Ist Kunde X gerade erreichbar?" – ausprobieren.

Mit StarfleetController: nachschlagen

  • Eine Liste über alle betreuten Anlagen, durchsuchbar und filterbar.
  • Je Anlage Module, Lizenzen, Zustand und Fähigkeiten – mit Zeitstempel.
  • Online-Zustand ohne Ausprobieren, weil die Anlage die Verbindung hält.
Anwendungsbeispiel

Ein Sicherheitshinweis zu einer STARFACE-Version erreicht Sie am Freitagnachmittag. Statt 120 Anlagen einzeln aufzurufen, filtern Sie in StarfleetController nach der betroffenen Version, sehen in zwei Minuten die 14 betroffenen Kunden und wissen zugleich, welche davon gerade online sind. Aus einem halben Tag Recherche werden zwei Minuten – und die Kundenliste für das Anschreiben fällt dabei ab.

Der Kerngedanke: Die Anlage ruft heraus, nicht wir hinein

Alles an der Architektur folgt aus einer Entscheidung: Die Verbindung wird immer von der Anlage aufgebaut, nach außen. Der Controller kann von sich aus keine Anlage erreichen.

Das löst die Netzwerkprobleme – NAT, fehlendes VPN, wechselnde Zertifikate – und es löst noch etwas, das auf den ersten Blick nicht danach aussieht: Ein Modul, das sich selbst aktualisiert, kann seinen Erfolg nur über einen bestehenden ausgehenden Kanal melden. Über einen eingehenden Aufruf endet die Antwort zwangsläufig im Nichts, weil die Route verschwindet, bevor das Ergebnis zurückkommt.

Der zweite Kerngedanke betrifft die Rechte: Die Autorisierung entsteht auf der Anlage, nicht in der Cloud. Dass Sie eine Anlage in Ihrer Liste sehen, heißt nicht, dass Sie dort etwas tun dürfen. Das entscheidet ein Administrator vor Ort. Beides zusammen beschreibt das Kapitel Sicherheit.

So lesen Sie dieses Kapitel

Der geführte Weg
  1. Aufbau und Ebenen – Konsole, Controller und Agent, und wer mit wem spricht.
  2. Funktionsumfang – was StarfleetController heute kann, ehrlich getrennt nach fertig und in Arbeit.
  3. Betriebsmodelle und Kosten – gehostet oder im eigenen Haus, und warum die Plattform kostenlos ist.