In , ich sprach über die Hintergrundgeschichte der Entstehung von Veliam und über die Entscheidung, es als SaaS-System zu verbreiten. In diesem Artikel werde ich erklären, was nötig war, damit das Produkt nicht lokal, sondern öffentlich wurde. Ich werde darüber berichten, wie wir mit der Verbreitung begannen und welche Probleme wir dabei begegneten.
Planung
Der aktuelle Server für die Benutzer läuft unter Linux. In fast jeder Organisation gibt es Windows-Server, was für Linux nicht gesagt werden kann. Die große Stärke von Veliam ist der Remote-Zugriff auf Server und Netzwerkgeräte hinter NAT. Allerdings war diese Funktionalität sehr stark davon abhängig, dass der Router unbedingt ein MikroTik sein musste. Offensichtlich würde das viele unzufriedenstellen. Zunächst dachte ich darüber nach, die Unterstützung für Router der gängigsten Anbieter hinzuzufügen. Aber ich wusste, dass das ein endloser Wettlauf wäre, um die Liste der unterstützten Firmen zu erweitern. Zudem können die bereits unterstützten Modelle von Gerät zu Gerät unterschiedliche Befehle zur Änderung von NAT-Regeln haben. Die einzig praktikable Lösung erschien mir ein VPN.
Da wir beschlossen haben, das Produkt nicht als Open Source zu verbreiten, war es nicht mehr möglich, verschiedene Bibliotheken mit offenen Lizenzen wie GPL in unser Produkt aufzunehmen. Das ist an sich ein großes Thema. Nach der Entscheidung, das Produkt zu verkaufen, mussten wir die Hälfte der Bibliotheken überprüfen, da sie GPL waren. Als wir es für uns selbst geschrieben haben, war das in Ordnung. Aber für die Verbreitung war das nicht geeignet. Das erste VPN, das einem in den Sinn kommt, ist OpenVPN. Aber das ist GPL. Es gab auch die Option, SoftEther VPN aus Japan zu verwenden. Seine Lizenz erlaubte es, in unser Produkt integriert zu werden. Nach ein paar Tagen verschiedener Tests, um es so zu integrieren, dass der Benutzer nichts konfigurieren oder über SoftEther VPN wissen musste, entstand ein Prototyp. Es war alles in Ordnung. Aber aus irgendeinem Grund beunruhigte uns dieses Konzept trotzdem, und letztendlich haben wir uns davon verabschiedet. Natürlich haben wir das erst gemacht, nachdem wir eine andere Lösung gefunden hatten. Letztendlich haben wir alles über gewöhnliche TCP-Verbindungen realisiert. Ein Teil der Verbindungen läuft über einen Koordinator, ein anderer Teil direkt über die Technologie Nat Hole Punching (NHP), die ebenfalls in Free Pascal implementiert wurde. Ich muss sagen, dass ich zuvor noch nie von NHP gehört hatte. Es war mir nicht in den Sinn gekommen, dass man zwei Netzwerkgeräte, die sich beide hinter NAT befinden, direkt verbinden könnte. Ich habe das Thema durchstudiert, den Arbeitsprinzip verstanden und angefangen zu schreiben. Das Geplante wurde umgesetzt, der Benutzer verbindet sich mit einem Klick mit dem gewünschten Gerät hinter NAT über RDP, SSH oder Winbox, ohne Passwörter einzugeben oder VPN zu konfigurieren. Zudem läuft der Großteil dieser Verbindungen an unserem Koordinator vorbei, was sich positiv auf die Latenz und die Kosten für die Wartung dieser Verbindungen auswirkt.
Übergang der Serverkomponenten von Linux auf Windows
Es gab mehrere Probleme beim Umstieg auf Windows. Das erste war, dass das integrierte wmic in Windows keine WQL-Abfragen ermöglicht. In unserem System war jedoch alles darauf aufgebaut. Ich kann mich nicht mehr genau erinnern, warum wir letztendlich von seiner Nutzung Abstand genommen haben. Möglicherweise liegen die Unterschiede zwischen den Windows-Versionen. Das zweite Problem war die Multithreading. Nachdem ich keine geeignete Drittanbieteranwendung mit einer für uns akzeptablen Lizenz gefunden habe, startete ich erneut die IDE Lazarus und schrieb das benötigte Tool. Als Eingabe erhalten wir die benötigte Liste von Objekten und die genau auszuführenden Abfragen, und als Antwort erhalte ich die Daten. Und das alles im Multithreading-Modus. Hervorragend.
Nachdem ich pthreads für PHP unter Windows eingerichtet hatte, dachte ich, es würde sofort funktionieren, aber dem war nicht so. Nach einiger Zeit des Debuggens wurde mir klar, dass pthreads zwar zu funktionieren schien, jedoch in unserem System nicht funktionierte. Es stellte sich heraus, dass es eine Besonderheit im Umgang mit pthreads unter Windows gab. Das wurde bestätigt. Ich las die Dokumentation und stellte fest, dass die Anzahl der Threads für Windows begrenzt ist, wobei ich meine, dass dies implizit war. Das stellte ein Problem dar. Denn als ich begann, die Anzahl der Threads, bei denen die Anwendung funktionierte, zu reduzieren, wurde die Verarbeitung extrem langsam. Ich öffnete erneut die IDE und fügte der gleichen Anwendung die Funktionalität zur Multithreading-Pingüberprüfung von Objekten hinzu. Außerdem wurde auch das Port-Scanning integriert. Tatsächlich verschwand danach die Notwendigkeit für pthreads in PHP, und es wird nicht mehr verwendet. Anschließend wurden dieser Anwendung weitere Funktionen hinzugefügt, und sie funktioniert bis heute. Daraufhin wurde ein Installer für Windows erstellt, der Apache, PHP, MariaDB, die PHP-Anwendung selbst sowie eine Sammlung von Hilfsprogrammen zur Interaktion mit dem System, die in Free Pascal geschrieben wurden, enthielt. Was den Installer betrifft, so dachte ich, dass ich dieses Problem schnell lösen könnte, da es sich um ein äußerst verbreitetes und für fast jede Software notwendiges Element handelt. Entweder suchte ich nicht richtig oder es lag an etwas anderem. Mir begegneten ständig Produkte, die entweder nicht flexibel genug waren oder zu teuer und dabei ebenfalls unflexibel. Schließlich fand ich jedoch einen kostenlosen Installer, bei dem sämtliche Anpassungen vorgesehen werden können. Das ist InnoSetup. Ich schreibe darüber, weil ich etwas suchen musste und vielleicht jemandem damit Zeit sparen kann.
Abkehr vom Plugin zugunsten des eigenen Clients
Ich habe bereits erwähnt, dass der Client ein Browser mit einem 'Plugin' war. Es gab Zeiten, in denen entweder Chrome aktualisiert wurde und das Layout leicht fehlerhaft war, oder Windows aktualisiert wurde und der benutzerdefinierte URI-Schema verloren ging. Solche Überraschungen wollte ich in der öffentlichen Produktversion vermeiden. Zudem fielen die benutzerdefinierten URIs nach jedem Windows-Update aus. Microsoft hat einfach alle nicht eigenen Verzweigungen im entsprechenden Abschnitt entfernt. Auch Google Chrome erlaubt nicht mehr, die Auswahl zum Öffnen oder Nichtöffnen einer Anwendung aus einem benutzerdefinierten URI zu speichern und stellt diese Frage bei jedem Klick auf das Überwachungsobjekt. Generell war es notwendig, eine vernünftige Interaktion mit dem lokalen System des Benutzers zu haben, die der Browser nicht bietet. Die einfachste Lösung in einem solchen Schema erschien, einfach einen eigenen Browser zu erstellen, wie es viele heutzutage über Electron machen. Aber viele Dinge waren bereits in Free Pascal geschrieben, auch im Serverteil, daher entschieden wir uns, auch den Client in derselben Sprache zu erstellen, um keinen Zoo zu schaffen. So wurde der Client mit Chromium an Bord geschrieben. Danach begann er, mit verschiedenen Bindungen zu wachsen.
Release
Endlich haben wir einen Namen für das System gewählt. Wir haben ständig verschiedene Optionen in Betracht gezogen, während wir von der lokalen Version auf SaaS umschwenkten. Da wir ursprünglich nicht nur auf den Inlandsmarkt abzielen wollten, war ein Hauptkriterium bei der Namensfindung die Verfügbarkeit einer freien oder nicht allzu teuren Domain in der Zone ".com". Einige Funktionen/Module waren noch nicht von der lokalen Version nach Veliam portiert, aber wir entschieden, dass wir mit den derzeit verfügbaren Funktionen starten und den Rest über Updates nachliefern würden. In der allerersten Version gab es keinen HelpDesk, keinen Veliam Connector, man konnte die Trigger-Schwellen für Benachrichtigungen nicht ändern und vieles mehr. Wir haben ein Code Sign Certificate gekauft und sowohl die Client- als auch die Server-Komponenten signiert. Eine Website für das Produkt wurde erstellt, und wir haben die Registrierung der Software, der Marken usw. begonnen. Kurz gesagt, wir sind bereit zu starten. Ein leichtes Gefühl der Euphorie über die geleistete Arbeit und über die Möglichkeit, dass jemand unser Produkt nutzen könnte, obwohl wir diesbezüglich keine Zweifel hatten. Und dann kam der Stopp. Der Partner sagte, dass der Markteintritt ohne Benachrichtigungen in Messenger nicht möglich sei. Man kann auf vieles andere verzichten, aber nicht darauf. Nach einigem kurzen Streit wurde die Integration mit Telegram hinzugefügt, was für uns in Ordnung war. Von allen verfügbaren Messengern ist dies der einzige, der kostenlosen Zugang zu seinen APIs gewährt, ohne komplizierte Genehmigungsverfahren. WhatsApp hingegen verlangt, dass man sich an Anbieter wendet, die viel Geld für die Inanspruchnahme ihrer Dienste verlangen, alle Anfragen nach einem Zugang ohne Umwege wurden ignoriert. Und Viber... ich weiß nicht, wer das momentan noch nutzt, da Spam und Werbung dort überhandnehmen. Ende Dezember, nach einer Reihe interner Tests und Tests im Freundeskreis, haben wir die Registrierung für alle geöffnet und die Software zum Download bereitgestellt.
Markteinführung
Von Anfang an wussten wir, dass wir einen konstanten Nutzerstrom benötigen, damit die Systeme im Echtbetrieb getestet werden und wir ein erstes Feedback erhalten. Einige bezahlte Beiträge in VK haben Früchte getragen. Die ersten Registrierungen sind eingegangen.
Hier muss erwähnt werden, dass es sehr schwierig ist, auf den Markt zu treten, wenn Ihr Unternehmen keinen bekannten Namen hat und gleichzeitig eine funktionale agentenlose Überwachung anbietet, bei der die Anmeldedaten für eigene Server und Arbeitsstationen eingegeben werden müssen. Viele Menschen schreckt das ab. Wir wussten von Anfang an, dass wir mit diesen Herausforderungen konfrontiert werden würden und waren sowohl technisch als auch moralisch darauf vorbereitet. Alle Remote-Verbindungen, auch wenn RDP und SSH standardmäßig verschlüsselt sind, werden zusätzlich durch unsere Software nach AES-Standard verschlüsselt. Alle Daten von lokalen Servern werden über HTTPS in die Cloud übertragen. Die Anmeldedaten werden in verschlüsselter Form gespeichert. Die Verschlüsselungsschlüssel für alle Subsysteme sind individuell für jeden Kunden. Für remote Verbindungen werden sogar Sitzungsschlüssel zur Verschlüsselung verwendet.
Alles, was wir in dieser Situation tun können, um den Menschen ein besseres Gefühl zu geben, ist, möglichst transparent zu sein, an der Sicherheit zu arbeiten und unermüdlich auf die Fragen der Menschen zu antworten, die sie beschäftigen.
Für viele überwiegen die Benutzerfreundlichkeit und die Funktionen der Software die Bedenken, und sie melden sich an. Einige Personen haben in veröffentlichten Beiträgen in VK geschrieben, dass diese Software nicht verwendet werden kann, da sie ihre Passwörter sammelt und das Unternehmen im Allgemeinen unbekannt ist. Es sei gesagt, dass diese Meinung nicht nur von einer Person stammt. Viele verstehen einfach nicht, dass, wenn sie eine andere proprietäre Software auf ihrem Server installieren, die als Dienst läuft, diese ebenfalls volle Rechte im System hat und sie keine Anmeldedaten benötigen, um etwas Illegales zu tun (es ist klar, dass man den Benutzer ändern kann, unter dem der Dienst läuft, aber hier ist es dasselbe, jede beliebige Anmeldung kann verwendet werden). Tatsächlich sind die Bedenken der Menschen verständlich. Die Installation von Software auf einem Server ist eine gewohnte Sache, aber die Eingabe von Anmeldedaten ist bereits etwas Angst einflößend und intim, da viele Menschen ein Passwort für alle Dienste verwenden und es ihnen zu lästig erscheint, für Tests ein separates Konto zu erstellen. Aber momentan gibt es eine enorme Anzahl von Diensten, denen die Menschen ihre Anmeldedaten und mehr anvertrauen. Und wir streben danach, einer von ihnen zu werden.
Es gab viele Kommentare dieser Art, die besagten, wir hätten das irgendwo gestohlen. Das hat uns etwas überrascht. Nun, die Meinung einer Person ist das eine, aber solche Kommentare tauchten in verschiedenen Veröffentlichungen von unterschiedlichen Personen auf. Zunächst wussten wir nicht, wie wir darauf reagieren sollten. Ob wir traurig darüber sein sollten, dass einige Menschen denken, in Russland könne niemand etwas selbst machen, sondern nur stehlen, oder ob wir uns darüber freuen sollten, dass sie glauben, so etwas könne man nur stehlen.
Wir haben jetzt den Prozess zur Erlangung des EV Code Sign Certificate abgeschlossen. Um dieses zu erhalten, muss man eine Reihe von Prüfungen durchlaufen und eine Menge Dokumente über das Unternehmen einreichen, von denen einige von einem Anwalt beglaubigt werden müssen. Der Erhalt des EV Code Sign-Zertifikats unter pandemiebedingten Bedingungen ist im Übrigen ein eigenes Thema für einen Artikel. Der Prozess hat einen Monat gedauert. Und das war ein Monat voller Anfragen nach zusätzlichen Dokumenten, nicht des Wartens. Vielleicht hat die Pandemie hier nichts mit zu tun, und bei allen dauerte der Prozess so lange? Teilen Sie Ihre Erfahrungen.
Einige sagen, dass wir es nicht nutzen werden, weil es kein FSTEK-Zertifikat gibt. Es ist notwendig zu erklären, dass wir es nicht erhalten können und auch nicht wollen, da für den Erhalt dieses Zertifikats die Verschlüsselung nach GOST erfolgen muss, während wir planen, die Software nicht nur in Russland zu verbreiten und AES verwenden.
All diese Kommentare haben ein gewisses Misstrauen hervorgerufen, dass es möglich ist, ein Produkt zu bewerben, bei dem Benutzerkonten eingerichtet werden müssen, ohne dabei wirklich im Gespräch zu sein. Selbst unter Berücksichtigung der Tatsache, dass wir wussten, dass es Menschen geben würde, die sehr negativ eingestellt sind. Nachdem die Anzahl der Registrierungen die tausend überschritten hatte, hörten wir auf, darüber nachzudenken. Besonders nachdem neben den negativen Stimmen von denen, die das Produkt nicht einmal ausprobiert hatten, auch sehr positive Rückmeldungen kamen. Man muss sagen, dass diese positiven Rückmeldungen die größte Motivation für die Entwicklung des Produkts sind.
Hinzufügen der Funktionalität für den Fernzugriff für Mitarbeiter
Eine häufige Anfrage von Kunden ist: "Machen Sie es möglich, dass Ivan von zu Hause aus auf seinen Computer zugreifen kann." Wir haben ein VPN auf einem MikroTik eingerichtet und Konten für die Benutzer erstellt. Aber das ist eine echte Herausforderung. Die Benutzer sind oft nicht in der Lage, die Anleitung zu lesen und die Schritte zu befolgen, um sich mit dem VPN zu verbinden. Es gibt verschiedene Versionen von Windows. In einer Version klappt die Verbindung gut, in einer anderen ist ein anderer Protokolltyp erforderlich. Generell war das immer mit der Neuanpassung der Netzwerkausrüstung verbunden, die als VPN-Server fungierte. Nicht alle Mitarbeiter haben Zugang dazu, und das war oft unpraktisch.
Wir verfügen bereits über Remote-Zugriffe auf Server und Netzwerkgeräte. Warum nicht einen vorhandenen Transport nutzen und ein kleines, eigenständiges Tool erstellen, das wir einfach den Nutzern für die Verbindung bereitstellen? Dabei wollten wir sicherstellen, dass der Nutzer keine komplizierten Eingaben tätigen muss. Nur ein Knopf mit der Aufschrift „Verbinden“. Aber wie soll dieses Tool wissen, zu welchem Server es sich verbinden soll, wenn es nur einen Knopf gibt? Eine Idee war, eine Online-Zusammenstellung der benötigten Anwendung auf unseren Servern anzubieten. Der Systemadministrator drückt den Knopf „Verknüpfung herunterladen“, und wir erhalten einen Befehl in unsere Cloud, um ein individuelles Binärpaket mit installierten Verbindungsinformationen zu dem gewünschten Server/Computer via RDP zu erstellen. Grundsätzlich wäre das machbar gewesen. Es würde jedoch lange dauern, da der Administrator erst auf die Kompilierung des Binärpakets warten müsste, bevor er es herunterladen kann. Man könnte natürlich einfach eine zweite Datei mit einer Konfiguration hinzufügen, aber das wären dann schon zwei Dateien, und der Nutzer benötigt zur Vereinfachung nur eine. Eine Datei, ein Knopf und keine Installer. Nach ein wenig Recherche bei Google bin ich zu dem Schluss gekommen, dass man einfach am Ende einer kompilierten „.exe“ einige Informationen hinzufügen kann, ohne dass sie beschädigt wird (na ja, fast). Man könnte sogar Krieg und Frieden hinzufügen, und sie würde weiterhin funktionieren wie zuvor. Es wäre eine Sünde, dies nicht zu nutzen. Jetzt können wir direkt im Client die Anwendung entpacken, die übrigens Veliam Connector heißt, und einfach die benötigten Verbindungsinformationen am Ende hinzufügen. Das Programm selbst weiß, was damit zu tun ist. Warum habe ich oben in Klammern „na ja, fast“ geschrieben? Weil wir für diesen Komfort einen Preis zahlen müssen: die Anwendung verliert ihre digitale Signatur. Aber wir betrachten das in diesem Stadium als einen kleinen Preis für diesen Komfort.
Lizenzen für Drittanbieter-Module
Ich habe bereits erwähnt, dass es nach der Entscheidung, das Produkt öffentlich zugänglich zu machen und nicht nur für den internen Gebrauch, viel Arbeit erforderte, um einige Module zu ersetzen, die nicht in unser Produkt integriert werden konnten. Doch nach der Veröffentlichung entdeckten wir zufällig eine unangenehme Sache. Im Veliam Server, der auf der Kundenseite verwendet wurde, befand sich die Datenbank MariaDB. Diese steht unter der GPL-Lizenz. Die GPL-Lizenz erfordert, dass die Software Open Source ist. Wenn MariaDB, die diese Lizenz hat, in unser Produkt integriert ist, muss auch unser Produkt unter dieser Lizenz stehen. Glücklicherweise verfolgt diese Lizenz das Ziel des Open Source und nicht die Bestrafung von denen, die versehentlich einen Fehler gemacht haben. Wenn der Rechteinhaber einen Anspruch erhebt, muss er den Verletzer schriftlich benachrichtigen, und dieser hat dann 30 Tage Zeit, um den Verstoß zu beheben. Wir haben unseren Fehler selbst entdeckt, keine Benachrichtigungen erhalten und sofort begonnen, Lösungen für das Problem zu prüfen. Die Lösung schien offensichtlich — der Umstieg auf SQLite. Diese Datenbank hat keinerlei Lizenzbeschränkungen. Die meisten modernen Browser verwenden SQLite und viele andere Programme ebenfalls. Ich fand im Internet Informationen, dass SQLite als die verbreitetste Datenbank der Welt gilt, insbesondere aufgrund der Browser, aber ich habe keine Beweise gesucht, daher ist dies ungenaue Information. Ich begann zu recherchieren, welche Risiken der Umstieg auf SQLite mit sich bringt.
Es wird bereits zu einer anspruchsvollen Aufgabe, wenn es mehrere Hundert bei Kunden installierte Server mit MariaDB und deren Daten gibt. Einige Funktionen von MariaDB sind in SQLite nicht verfügbar. Zum Beispiel wurden im Code Abfragen wie
Select * FROM `table` WHERE `id` > 1000 FOR UPDATE
Diese Konstruktion führt nicht nur die Auswahl aus der Tabelle durch, sondern sperrt auch die betreffenden Datenzeilen. Einige weitere Konstruktionen mussten ebenfalls umgeschrieben werden. Neben dem Umstand, dass viele Abfragen umgeschrieben werden mussten, war es notwendig, einen Mechanismus zu entwickeln, der bei der Aktualisierung des Veliam Servers beim Kunden alle Daten in die neue Datenbank migriert und die alte entfernt. Außerdem funktionierten Transaktionen in SQLite nicht, und das war ein echtes Problem. Allerdings fand ich nach etwas Recherche im Internet schnell heraus, dass Transaktionen in SQLite aktiviert werden können, indem man beim Verbinden den einfachen Befehl übergibt
PRAGMA journal_mode=WAL;Letztendlich wurde die Aufgabe erledigt und jetzt läuft der Serverbereich bei den Kunden auf SQLite. Von Änderungen in der Systemfunktionalität haben wir nichts bemerkt.
Neues HelpDesk
Bei der Portierung des HelpDesk-Systems von einer internen Version auf eine SaaS-Version mussten bestimmte Anpassungen vorgenommen werden. Das erste Ziel war die Integration mit der Domain des Kunden, um eine nahtlose Authentifizierung der Nutzer im System zu gewährleisten. Der Benutzer kann jetzt einfach auf das Desktop-Symbol klicken, um auf HelpDesk zuzugreifen und eine Anfrage zu hinterlassen; es wird automatisch ein Browser geöffnet. Der Nutzer muss keine Anmeldedaten eingeben. Das Apache SSPI-Modul, das zum Veliam Server gehört, authentifiziert den Nutzer automatisch mit dem Domain-Konto. Um eine Anfrage außerhalb des Unternehmensnetzwerks zu erstellen, klickt der Nutzer auf eine Schaltfläche, und erhält eine E-Mail mit einem Link, über den er sich ohne Passwort im HelpDesk-System anmelden kann. Wird der Nutzer im Netzwerk deaktiviert oder gelöscht, so funktioniert auch sein Konto im HelpDesk nicht mehr. Damit muss der Systemadministrator die Konten im Domain- und HelpDesk-System nicht manuell überwachen. Kündigt ein Mitarbeiter, genügt es, das Konto in der Domain zu deaktivieren, und schon hat er keinen Zugriff mehr auf das System, weder im Unternehmensnetzwerk noch über den Link. Für die Implementierung dieser Integration muss der Systemadministrator eine GPO erstellen, die und .
Das Zweite, was wir für HelpDesk-Systeme als äußerst notwendig erachten – zumindest für uns selbst – ist die Möglichkeit, mit einem einzigen Klick direkt aus dem Ticket heraus auf den Anfragenden zuzugreifen. Darüber hinaus sollten die Verbindungen auch dann funktionieren, wenn der Systemadministrator sich in einem anderen Netzwerk befindet. Für Outsourcing ist das unerlässlich, und auch für interne Systemadministratoren oft sehr wichtig. Es gibt bereits mehrere Produkte, die hervorragend mit der Aufgabe der Remote-Verbindungen umgehen. Daher haben wir beschlossen, Integrationen dafür zu schaffen. Momentan haben wir eine Integration für VNC entwickelt, und in Zukunft planen wir, Radmin und TeamViewer hinzuzufügen. Mit unserem Netzwerktransport für Remote-Verbindungen zur Infrastruktur haben wir es ermöglicht, dass VNC zu Remote-Workstations hinter NAT verbindet. Dasselbe wird auch für Radmin gelten. Jetzt muss der Systemadministrator nur in dem Ticket auf die Schaltfläche "Mit Anfragenden verbinden" klicken. Der VNC-Client öffnet sich und stellt die Verbindung zum Anfragenden her, unabhängig davon, ob Sie sich im selben Netzwerk befinden oder zuhause in Pantoffeln sitzen. Vorausgesetzt, der Systemadministrator hat mithilfe von GPO VNC Server auf allen Arbeitsstationen installiert.
Wir steigen jetzt selbst auf das neue HelpDesk um und nutzen die Integration mit der Domain und VNC. Das ist für uns sehr praktisch. Jetzt müssen wir nicht mehr für TeamViewer bezahlen, das wir über drei Jahre lang für unseren Support verwendet haben.
Was planen wir als Nächstes?
Als wir unser Produkt veröffentlicht haben, haben wir keine kostenpflichtigen Tarife eingeführt, sondern einfach das kostenlose Konto auf 50 Monitoring-Objekte beschränkt. Fünf Dutzend Netzwerkgeräte und Server sollten für alle ausreichen, dachten wir. Doch dann begannen die Anfragen zur Erhöhung des Limits einzutreffen. Zu sagen, dass wir etwas überrascht waren, wäre eine Untertreibung. Haben tatsächlich Unternehmen Interesse an unserer Software gezeigt, die so viele Server betreiben? Wir haben das Limit kostenlos für diejenigen erweitert, die solche Anfragen stellten. Bei einigen haben wir als Antwort auf ihre Anfrage sogar gefragt, warum sie so viele benötigen, ob sie wirklich so viele Server und Netzwerkgeräte haben. Und es stellte sich heraus, dass Systemadministratoren das System in einer Weise nutzen, die wir überhaupt nicht vorgesehen hatten. Alles war ganz einfach — unsere Software wurde nicht nur zur Überwachung von Servern, sondern auch von Arbeitsstationen eingesetzt. Daher gab es viele Anfragen zur Erhöhung der Limits. Mittlerweile haben wir bereits kostenpflichtige Tarife eingeführt, und die Limits können nun auch selbständig erweitert werden.
Server arbeiten fast immer entweder mit SAN oder mit lokalen Festplatten in einem RAID-Verbund. Unser Produkt wurde ursprünglich dafür entwickelt. Der SMART-Monitoring war für diese Aufgabe uninteressant. Da jedoch die Leute Software zur Überwachung von Arbeitsstationen angepasst haben, gab es Anfragen für die Implementierung von SMART-Monitoring. Bald werden wir das umsetzen.
Mit dem Veliam Connector ist es nicht mehr nötig, einen VPN-Server im Unternehmensnetzwerk zu implementieren, RDGW bereitzustellen oder Ports zu den erforderlichen Maschinen für RDP-Verbindungen weiterzuleiten. Viele nutzen unser System nur für diese Remote-Verbindungen. Der Veliam Connector ist derzeit nur für Windows verfügbar, während einige Firmenanwender von ihren privaten MacOS-Laptops aus auf Arbeitsstationen oder Terminals im Unternehmensnetzwerk zugreifen. Das bedeutet, dass der Systemadministrator wegen einiger Benutzer immer wieder auf das Thema Portweiterleitungen oder VPN zurückkommen muss. Daher sind wir jetzt dabei, eine Version des Veliam Connectors für MacOS zu beenden. Auch die Nutzer ihrer geliebten Apple-Technik werden so die Möglichkeit haben, mit nur einem Klick auf die Unternehmensinfrastruktur zuzugreifen.
Es gefällt mir sehr, dass wir mit einer großen Anzahl von Benutzern nicht rätseln müssen, was die Menschen benötigen und was am praktischsten ist. Sie äußern selbst ihre Wünsche, sodass wir aktuell viele Entwicklungspläne haben.
Außerdem planen wir, das System jetzt ins Englische zu übersetzen und international zu verbreiten. Wir wissen noch nicht, wie wir das Produkt außerhalb unseres Landes vertreiben werden, und suchen nach Möglichkeiten. Vielleicht wird es später einen eigenen Artikel dazu geben. Möglicherweise kann jemand, der diesen Artikel gelesen hat, den richtigen Weg aufzeigen, oder kennt sich aus und bietet seine Dienste an. Über Hilfe würden wir uns freuen.
Quelle: habr.com
