Im , ich habe die Vorgeschichte der Entstehung von Veliam und die Entscheidung über seine Verbreitung im SaaS-System erzählt. In diesem Artikel werde ich erläutern, was getan werden musste, damit das Produkt nicht lokal, sondern öffentlich wurde. Ich werde darüber berichten, wie wir mit der Verbreitung begonnen haben und mit welchen Problemen wir konfrontiert waren.
Planung
Der aktuelle Serverteil für die Benutzer lief auf Linux. In fast jeder Organisation gibt es Windows-Server, was man von Linux nicht sagen kann. Die Hauptstärke von Veliam ist der Remote-Zugriff auf Server und Netzwerkgeräte hinter NAT. Aber diese Funktion war stark davon abhängig, dass der Router unbedingt ein MikroTik sein musste. Das würde viele offensichtlich nicht zufriedenstellen. Zuerst dachte ich darüber nach, Unterstützung für Router von den gängigsten Anbietern hinzuzufügen. Aber ich wusste, dass dies ein endloser Wettlauf mit der Erweiterung der Liste unterstützter Firmen sein würde. Darüber hinaus können diejenigen, die bereits unterstützt werden, von Modell zu Modell unterschiedliche Befehle zum Ändern der NAT-Regeln haben. Der einzige Ausweg aus der Situation schien ein VPN zu sein.
Da wir beschlossen haben, das Produkt zu vertreiben, jedoch nicht als Open Source, dürfen wir keine verschiedenen Bibliotheken mit offenen Lizenzen wie GPL einbeziehen. Das ist ein eigenes Thema, denn nach der Entscheidung, das Produkt zu verkaufen, mussten wir die Hälfte der Bibliotheken durchsehen, weil sie GPL waren. Als wir für uns selbst schrieben, war das in Ordnung. Für den Vertrieb passt es jedoch nicht. Der erste VPN, der mir in den Sinn kommt, ist OpenVPN. Aber das ist GPL. Eine andere Möglichkeit wäre, das japanische SoftEther VPN zu verwenden. Seine Lizenz erlaubte es, es in unser Produkt einzubeziehen. Nach ein paar Tagen verschiedener Tests, wie wir es so integrieren können, dass der Benutzer überhaupt nichts einstellen oder über SoftEther VPN wissen muss – entstand ein Prototyp. Alles war wie gewünscht. Aber irgendwie störte uns dieses Schema dennoch, und letztendlich haben wir darauf verzichtet. Natürlich haben wir erst dann aufgegeben, als wir eine andere Variante erfunden hatten. Schlussendlich machten wir alles über herkömmliche TCP-Verbindungen. Ein Teil der Verbindungen läuft über einen Koordinator, ein Teil direkt über die Technologie Nat Hole Punching (NHP), die ebenfalls in Free Pascal realisiert wurde. Ich muss sagen, dass ich zuvor überhaupt nichts über NHP gehört hatte. Und mir konnte nicht in den Sinn kommen, dass man zwei Netzwerkgeräte, die beide hinter NAT stehen, direkt verbinden kann. Ich habe das Thema intensiv studiert, den Arbeitsprinzip verstanden und begann zu schreiben. Das Angedachte wurde verwirklicht, der Benutzer kann sich mit einem Klick mit dem gewünschten Gerät hinter NAT über RDP, SSH oder Winbox verbinden, ohne Passwörter eingeben oder ein VPN einrichten zu müssen. Zudem läuft der Großteil dieser Verbindungen direkt an unserem Koordinator vorbei, was sich positiv auf die Latenz und die Kosten für die Wartung dieser Verbindungen auswirkt.
Übersetzung des Serverteils von Linux auf Windows
Es gab mehrere Probleme beim Wechsel zu Windows. Das erste – das integrierte wmic in Windows erlaubt keine WQL-Abfragen. In unserem System basierte schon alles darauf. Und es gab noch etwas, aber ich habe jetzt vergessen, warum wir am Ende entschieden haben, es nicht mehr zu verwenden. Möglicherweise unterscheiden sich die Versionen von Windows. Das zweite Problem war die Multithread-Fähigkeit. Als ich keine gute externe Utility mit einer für uns „akzeptablen“ Lizenz fand, startete ich erneut die IDE Lazarus. Und schrieb die notwendige Utility. Als Eingabe erhält man die benötigte Liste von Objekten und welche Anfragen zu stellen sind, und im Gegenzug erhält man Daten. Und das alles im Multithread-Betrieb. Ausgezeichnet.
Nachdem ich pthreads für PHP unter Windows konfiguriert hatte, dachte ich, dass alles sofort funktionieren würde, aber das war nicht der Fall. Nach einiger Zeit des Debuggens stellte ich fest, dass pthreads zu funktionieren scheint, aber genau in unserem System nicht lief. Es wurde klar, dass es eine besondere Eigenheit bei der Verwendung von pthreads unter Windows gab. Und genau so war es auch. Ich las die Dokumentation und dort stand, dass die Anzahl der Threads unter Windows begrenzt ist, und zwar, soweit ich mich erinnere, implizit. Das wurde zu einem Problem. Denn als ich begann, die Anzahl der Threads zu reduzieren, bei denen die Anwendung funktionierte, arbeitete sie sehr langsam. Ich öffnete wieder die IDE und die gleiche Utility erhielt eine Funktion zur mehrsprachigen Ping-Überprüfung von Objekten. Und zusätzlich auch die Port-Scans. Tatsächlich fiel nach diesem Punkt die Notwendigkeit für pthreads in PHP weg und es wurde nicht mehr verwendet. Danach wurden weitere Funktionen in diese Utility eingefügt, und sie funktioniert bis heute. Anschließend wurde ein Installer für Windows zusammengestellt, der Apache, PHP, MariaDB, die PHP-Anwendung selbst und eine Reihe von Tools für die Interaktion mit dem System, die in Free Pascal geschrieben wurden, beinhaltete. Was den Installer betrifft, so dachte ich, dass ich dieses Problem schnell lösen könnte, da es ein äußerst verbreitetes und für fast jede Software notwendiges Tool ist. Entweder suchte ich nicht richtig oder etwas anderes war der Fall. Aber ich stieß ständig auf Produkte, die entweder nicht flexibel genug oder teuer und dabei auch nicht flexibel waren. Dennoch fand ich einen kostenlosen Installer, der alle gewünschten Funktionen berücksichtigen kann. Das ist InnoSetup. Ich schreibe hier darüber, weil ich etwas suchen musste; vielleicht spare ich jemandem Zeit.
Verzicht auf das Plugin zugunsten des eigenen Clients
Ich habe bereits geschrieben, dass der Client ein Browser mit einem „Plugin“ war. Es gab Zeiten, in denen entweder Chrome aktualisiert wurde und das Layout ein wenig verzerrt war, oder Windows aktualisiert wurde und das benutzerdefinierte URI-Schema verloren ging. Solche Überraschungen in der öffentlichen Version des Produkts wollte ich unbedingt vermeiden. Dabei begannen die benutzerdefinierten URIs nach jedem Windows-Update zu verschwinden. Microsoft hat schlichtweg alle nicht eigenen Zweige im entsprechenden Abschnitt gelöscht. Außerdem erlaubt Google Chrome jetzt nicht mehr, die Auswahl zu speichern, ob die Anwendung aus dem benutzerdefinierten URI geöffnet werden soll oder nicht, und stellt diese Frage bei jedem Klick auf das Überwachungsobjekt. Insgesamt war ein reibungsloses Zusammenspiel mit dem lokalen System des Benutzers notwendig, was der Browser nicht bietet. Die einfachste Lösung in einem solchen Schema scheint, einfach einen eigenen Browser zu erstellen, wie es derzeit viele über Electron tun. Aber viele Dinge wurden bereits in Free Pascal geschrieben, auch im Serverbereich, weshalb wir beschlossen haben, auch den Client in derselben Sprache zu erstellen, um keinen Zoo zu schaffen. So wurde ein Client mit Chromium an Bord in Auftrag gegeben. Danach begann er, verschiedene Rahmen zu entwickeln.
Veröffentlichung
Endlich haben wir einen Namen für das System gefunden. Wir haben ständig verschiedene Optionen durchgespielt, während wir den Prozess der Umwandlung von der lokalen Version in SaaS durchführten. Da wir ursprünglich geplant hatten, nicht nur auf den Binnenmarkt zu gehen, war das Hauptkriterium für die Namenswahl die Verfügbarkeit einer unbesetzten oder nicht allzu teuren Domain in der „.com“-Zone. Einige Funktionen/Module waren noch nicht von der lokalen Version in Veliam portiert, aber wir entschieden, dass wir mit der aktuellen Funktionalität starten würden und den Rest später in Form von Updates nachholen. In der allerersten Version gab es keinen HelpDesk, keinen Veliam Connector, man konnte die Auslöseschwellen der Benachrichtigungstrigger nicht ändern und vieles mehr. Wir haben ein Code Sign Certificate gekauft, die client- und serverseitigen Teile signiert. Eine Website für das Produkt erstellt, die Verfahren zur Registrierung der Software, des Markennamens usw. begonnen. Insgesamt sind wir bereit zu starten. Eine leichte Euphorie über die geleistete Arbeit und die Möglichkeit, dass jemand unser Produkt nutzen wird, obwohl wir diesbezüglich keine Zweifel hatten. Und hier ein Stopp. Der Partner sagte, dass wir ohne Benachrichtigungen in Messenger nicht auf den Markt gehen können. Man kann auf vieles andere verzichten, aber nicht darauf. Nach kurzen Diskussionen wurde die Integration mit Telegram hinzugefügt, die uns zusagte. Von allen aktuellen Messengern ist dies der einzige, der kostenlosen Zugang zu seinen APIs bietet, ohne komplizierte Genehmigungsverfahren. Dasselbe WhatsApp empfiehlt, sich an Anbieter zu wenden, die ein gutes Geld für die Nutzung ihrer Dienste verlangen, alle Anfragen nach Zugang ohne Zwischenschaltung wurden ignoriert. Tja, und Viber… Ich weiß nicht, wer es jetzt nutzt, da Spam und Werbung dort überhandnehmen. Ende Dezember, nach einer Reihe interner Tests und Tests unter Freunden, haben wir die Registrierung für alle geöffnet und die Software zum Download bereitgestellt.
Beginn der Verbreitung
Von Anfang an wussten wir, dass wir einen kleinen Nutzerstrom für das System brauchen, damit sie das Produkt im Echtbetrieb testen und ein erstes Feedback geben können. Einige gekaufte Posts in VK haben Früchte getragen. Die ersten Registrierungen gingen ein.
Es ist wichtig zu sagen, dass es sehr schwierig ist, auf den Markt zu treten, wenn Ihr Unternehmen keinen bekannten Namen hat und dabei eine Funktionalität für agentenloses Monitoring anzubieten, bei der Benutzerkonten von eigenen Servern und Arbeitsstationen eingegeben werden müssen. Dies erschreckt viele Menschen. Von Anfang an waren wir uns bewusst, dass wir auf Probleme stoßen würden und waren sowohl technisch als auch moralisch darauf vorbereitet. Alle remote Verbindungen, obwohl RDP und SSH standardmäßig bereits verschlüsselt sind, werden zusätzlich von unserer Software nach dem AES-Standard verschlüsselt. Alle Daten von lokalen Servern werden per HTTPS in die Cloud übertragen. Die Benutzerkonten werden in verschlüsselter Form gespeichert. Die Verschlüsselungsschlüssel für alle Subsysteme sind für alle Kunden individuell. Für remote Verbindungen werden sogar Sitzungsschlüssel zur Verschlüsselung verwendet.
Alles, was wir in dieser Situation tun können, um den Menschen mehr Sicherheit zu geben, ist maximale Offenheit, an der Sicherheit zu arbeiten und die Fragen der Menschen, die sie beschäftigen, unermüdlich zu beantworten.
Für viele überwiegen der Komfort und die Funktionalität der Software die Ängste, und sie registrieren sich. Einige Personen haben in veröffentlichten Posts in VK geschrieben, dass diese Software nicht genutzt werden kann, da sie ihre Passwörter sammelt und es sich um ein anonymes Unternehmen handelt. Man muss sagen, dass diese Meinung nicht die einzige war. Viele verstehen einfach nicht, dass, wenn sie eine andere proprietäre Software auf einem Server installieren, die als Dienst arbeitet, sie genau die gleichen vollen Rechte im System hat und keine Benutzerkonten braucht, um etwas Illegales zu tun (es ist klar, dass man den Benutzer ändern kann, unter dem der Dienst läuft, aber hier gilt das Gleiche, man kann jedes Benutzerkonto eingeben). In der Tat sind die Bedenken der Menschen verständlich. Die Softwareinstallation auf einem Server ist eine vertraute Sache, aber die Eingabe eines Benutzerkontos ist schon ein wenig angsterregend und intim, da viele Menschen ein Passwort für alle Dienste haben und es zu faul ist, ein separates Konto sogar nur für Tests zu erstellen. Aber derzeit gibt es eine Vielzahl von Diensten, denen Menschen ihre Zugangsdaten und mehr anvertrauen. Und wir streben danach, einer von ihnen zu werden.
Viele Kommentare hatten einen solchen Tenor, dass wir das irgendwoher gestohlen hätten. Das hat uns etwas überrascht. Nun, die Meinung eines Einzelnen ist das eine, aber solche Kommentare kamen in verschiedenen Veröffentlichungen von verschiedenen Personen vor. Zuerst wussten wir nicht, wie wir darauf reagieren sollten. Sollten wir traurig sein über die Meinung mancher Leute, dass in Russland niemand etwas selbst tun kann, sondern nur stehlen kann, oder sollten wir uns freuen, dass man glaubt, dass man sowas nur stehlen kann?
Jetzt haben wir das Verfahren zur Erlangung des EV Code Sign Certificate abgeschlossen. Um dieses zu erhalten, sind eine Reihe von Überprüfungen und das Einreichen einer Menge von Unternehmensdokumenten erforderlich, von denen einige von einem Anwalt beglaubigt werden müssen. Der Erhalt des EV Code Sign Zertifikats unter Pandemiebedingungen ist überhaupt ein eigenes Thema für einen Artikel. Das Verfahren dauerte einen Monat. Und das war ein Monat nicht des Wartens, sondern ständiger Anfragen nach zusätzlichen Dokumenten. Vielleicht hat die Pandemie hiermit nichts zu tun, und bei allen dauerte das Verfahren so lange? Teilen Sie Ihre Erfahrungen.
Einige sagen, dass wir nicht nutzen werden, weil es kein FSTEC-Zertifikat gibt. Wir müssen erklären, dass wir es nicht erhalten können und nicht werden, da für den Erhalt dieses Zertifikats die Verschlüsselung nach GOST erfolgen muss, und wir planen die Verbreitung der Software nicht nur in Russland und verwenden AES.
All diese Kommentare weckten ein gewisses Unbehagen darüber, dass es möglich sein könnte, ein Produkt zu bewerben, für das Konten eingerichtet werden müssen, ohne dabei in der Öffentlichkeit zu stehen. Selbst in Anbetracht der Tatsache, dass wir wussten, dass es Leute geben würde, die dies sehr negativ bewerten. Nachdem die Anzahl der Registrierungen die Tausend überschritt, hörten wir auf, darüber nachzudenken. Besonders nachdem neben der negativen Resonanz von denen, die das Produkt nicht einmal ausprobiert haben, auch sehr positive Bewertungen aufkamen. Man muss sagen, dass diese positiven Bewertungen der größte Motivator für die Produktentwicklung sind.
Hinzufügen der Funktionalität für den Fernzugriff für Mitarbeiter
Eine häufige Anfrage von Kunden ist: „Geben Sie Wanja Zugriff auf seinen Computer von zu Hause aus“. Wir haben VPN auf MikroTik eingerichtet und Benutzerkonten für die Nutzer erstellt. Aber das ist wirklich ein Problem. Die Benutzer sind nicht in der Lage, die Anleitung zu lesen und sie Schritt für Schritt zu befolgen, um sich über VPN zu verbinden. Es gibt verschiedene Versionen von Windows. In einer Windows-Version funktioniert die Verbindung gut, in einer anderen ist ein anderer Protokoll erforderlich. Insgesamt war das immer mit einer Neukonfiguration der Netzwerkausrüstung verbunden, die als VPN-Server fungierte, und nicht alle Mitarbeiter haben Zugriff darauf, was unpraktisch war.
Wir haben bereits entfernte Verbindungen zu Servern und Netzwerkgeräten. Warum nicht den vorhandenen Transport nutzen und ein kleines, separates Tool erstellen, das wir einfach dem Benutzer zum Verbinden geben können? Ich wollte nur sicherstellen, dass der Benutzer dort nichts Kompliziertes eingeben muss. Einfach nur ein Button „Verbinden“. Aber wie soll dieses Tool wissen, wo es sich verbinden soll, wenn es nur einen Button hat? Es gab die Idee einer online Zusammenstellung der benötigten Anwendung auf unseren Servern. Der Systemadministrator drückt die Taste „Verknüpfung herunterladen“, und bei uns in der Cloud wird ein Befehl zur Zusammenstellung eines individuellen Binaries mit den verschlüsselten Verbindungsinformationen für den benötigten Server / Computer über RDP gesendet. Im Grunde hätte man das umsetzen können. Aber das dauert lange, der Administrator müsste zunächst warten, bis das Binary kompiliert ist, und dann bis es heruntergeladen ist. Man könnte natürlich einfach eine zweite Datei mit einer Konfiguration hinzufügen, aber das wären dann schon 2 Dateien, und für die Einfachheit braucht der Benutzer nur eine. Eine Datei, ein Button und keine Installer. Nachdem ich ein wenig im Internet recherchiert habe, bin ich zu dem Schluss gekommen, dass, wenn man am Ende des kompilierten „.exe“ zusätzliche Informationen hinzufügt, es nicht beschädigt wird (na ja, fast). Man könnte sogar Krieg und Frieden hinzufügen, und es würde weiterhin funktionieren wie zuvor. Es wäre eine Sünde, dies nicht auszunutzen. Jetzt kann man einfach unterwegs direkt im Client die Anwendung entpacken, die übrigens Veliam Connector heißt, und einfach die benötigten Verbindungsinformationen am Ende ergänzen. Und die Anwendung selbst weiß, was sie damit machen soll. Warum ich weiter oben in Klammern „na ja, fast“ geschrieben habe? Weil man für diesen Komfort damit bezahlen muss, dass die Anwendung ihre digitale Signatur verliert. Aber wir glauben an dieser Stelle, dass dies ein kleiner Preis für diesen Komfort ist.
Lizenzen von Drittanbietermodulen
Wie bereits erwähnt, nachdem wir beschlossen hatten, das Produkt öffentlich zugänglich zu machen und nicht nur für den eigenen Gebrauch, mussten wir beträchtliche Anstrengungen unternehmen und alternative Module suchen, die es uns ermöglichten, Teil unseres Produktes zu sein. Doch nach der Veröffentlichung trat zufällig ein recht unangenehmes Problem auf. Im Veliam Server, der auf der Clientseite installiert war, befand sich die Datenbank MariaDB. Und diese hat eine GPL-Lizenz. Die GPL-Lizenz besagt, dass Software mit offenem Quellcode bereitgestellt werden muss, und wenn unser Produkt die MariaDB enthält, die diese Lizenz hat, muss auch unser Produkt unter dieser Lizenz stehen. Glücklicherweise liegt das Ziel dieser Lizenz in der Bereitstellung von offenem Quellcode und nicht in der rechtlichen Bestrafung derjenigen, die einen Fehler gemacht haben. Wenn der Rechteinhaber eine Beschwerde hat, wird der Verletzer schriftlich informiert und muss innerhalb von 30 Tagen das Problem beheben. Wir entdeckten unseren Fehler selbst, erhielten keine Schreiben und begannen sofort, Optionen zur Lösung des Problems zu prüfen. Die Lösung war offensichtlich: Der Wechsel zu SQLite. Diese Datenbank hat keine Lizenzbeschränkungen. Die meisten modernen Browser verwenden SQLite, ebenso viele andere Programme. Im Internet fand ich Informationen, dass SQLite die am weitesten verbreitete Datenbank der Welt ist, gerade wegen der Browser, aber ich suchte keine Beweise, daher könnte das ungenau sein. Ich begann zu untersuchen, welche Risiken der Wechsel zu SQLite birgt.
Dies wird zu einer nicht trivialen Aufgabe, wenn es mehrere Hundert installierte Server bei Kunden mit MariaDB und den darin gespeicherten Daten gibt. Einige Funktionen von MariaDB sind in SQLite nicht verfügbar. Zum Beispiel wurden im Code Abfragen vom Typ verwendet,
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Diese Konstruktion führt nicht nur eine Auswahl aus der Tabelle durch, sondern sperrt auch die betreffenden Datenzeilen. Und einige andere Konstruktionen mussten ebenfalls umgeschrieben werden. Aber abgesehen davon, dass viele Abfragen umgeschrieben werden mussten, musste auch ein Mechanismus erdacht werden, der beim Update des Veliam Servers bei den Kunden alle Daten in die neue Datenbank portiert und die alte löscht. Außerdem funktionierten Transaktionen in SQLite nicht, was ein echtes Problem darstellte. Aber nachdem ich die Weiten des World Wide Web durchstöbert hatte, stellte ich problemlos fest, dass man Transaktionen in SQLite aktivieren kann, indem man beim Verbindungsaufbau einfach den Befehl übergibt,
PRAGMA journal_mode=WAL;Am Ende ist die Aufgabe abgeschlossen und nun funktioniert der Serverbereich bei den Kunden mit SQLite. Irgendwelche Änderungen in der Systemleistung haben wir nicht bemerkt.
Neuer HelpDesk
Es war notwendig, das HelpDesk-System von der internen Version zur SaaS-Version zu portieren, jedoch mit einigen Änderungen. Das erste, was wir umsetzen wollten, war die Integration mit der Domain des Kunden bezüglich der transparenten Authentifizierung der Nutzer im System. Der Benutzer muss jetzt, um in den HelpDesk zu gelangen und eine Anfrage im System zu hinterlassen, einfach auf das Symbol auf dem Desktop klicken und der Browser öffnet sich. Der Benutzer gibt keine Anmeldedaten ein. Das Modul für Apache SSPI, das Teil des Veliam Servers ist, authentifiziert den Benutzer automatisch mit dem Domänenbenutzerkonto. Um eine Anfrage im System zu hinterlassen, wenn der Benutzer außerhalb des Unternehmensnetzwerks ist, klickt er auf einen Button, und ihm wird ein Link per E-Mail gesendet, über den er sich ohne Passwörter im HelpDesk-System authentifizieren kann. Wird der Benutzer in der Domain deaktiviert oder gelöscht, funktioniert auch das Benutzerkonto im HelpDesk nicht mehr. Damit muss der Systemadministrator nicht selbst die Konten sowohl in der Domain als auch im HelpDesk überwachen. Ein Mitarbeiter hat gekündigt – das Benutzerkonto in der Domain wurde deaktiviert und alles, er kann das System weder aus dem Unternehmensnetzwerk noch über den Link betreten. Für die Umsetzung dieser Integration muss der Systemadministrator eine GPO erstellen, die und .
Was wir für HelpDesk-Systeme als äußerst notwendig erachten, ist die Möglichkeit, aus einem Antrag heraus mit einem Klick eine Verbindung zum Antragsteller herzustellen. Darüber hinaus sollten die Verbindungen auch dann funktionieren, wenn der Systemadministrator sich in einem anderen Netzwerk befindet. Dies ist für die Outsourcing-Dienste unerlässlich, wird aber auch häufig von internen Systemadministratoren benötigt. Es gibt bereits mehrere Produkte, die hervorragend mit der Aufgabe der Remote-Verbindungen umgehen. Deshalb haben wir beschlossen, Integrationen für diese zu erstellen. Momentan haben wir eine Integration für VNC umgesetzt und planen in Zukunft, Radmin und TeamViewer hinzuzufügen. Mithilfe unseres Netzwerktransports für Remote-Verbindungen zur Infrastruktur haben wir es ermöglicht, dass sich VNC mit Remote-Workstations hinter NAT verbindet. Das gleiche wird auch für Radmin funktionieren. Um sich jetzt mit einem Benutzer zu verbinden, genügt es, in der Anfrage auf die Schaltfläche „Mit Antragsteller verbinden“ zu drücken. Der VNC-Client öffnet sich und verbindet sich mit dem Antragsteller, unabhängig davon, ob Sie sich im selben Netzwerk befinden oder zu Hause in Pantoffeln sitzen. Zuvor muss der Systemadministrator über die Gruppenrichtlinie den VNC-Server auf allen Arbeitsstationen installieren.
Jetzt wechseln wir selbst zu einem neuen HelpDesk und nutzen die Integration mit der Domäne und VNC. Das ist sehr praktisch für uns. Jetzt müssen wir nicht mehr für TeamViewer bezahlen, das wir mehr als drei Jahre für unsere Support-Dienste genutzt haben.
Was wir als Nächstes planen
Als wir das Produkt veröffentlichten, hatten wir keine kostenpflichtigen Tarife eingerichtet, sondern unseren kostenlosen Tarif auf 50 Monitoring-Objekte beschränkt. Fünf Dutzend Netzwerkgeräte und Server sollten für alle ausreichen, dachten wir. Und plötzlich kamen die Anfragen zur Erhöhung des Limits. Zu sagen, dass wir etwas geschockt waren, wäre eine Untertreibung. Hatten sich wirklich Unternehmen für unsere Software interessiert, die so viele Server besitzen? Wir haben das Limit kostenlos für diejenigen erhöht, die solche Anfragen stellten. Einige fragten wir im Gegenzug, warum sie so viele benötigen, ob sie wirklich so viele Server und Netzwerkgeräte haben. Und es stellte sich heraus, dass die Systemadministratoren begannen, das System so zu nutzen, wie wir es überhaupt nicht geplant hatten. Es stellte sich als ganz einfach heraus – unser Softwaremonitoring begann nicht nur für Server, sondern auch für Arbeitsstationen verwendet zu werden. Daher kamen auch viele Anfragen zur Erweiterung der Limits. Inzwischen haben wir bereits kostenpflichtige Tarife eingeführt und die Limits können nun selbstständig erweitert werden.
Server arbeiten fast immer entweder mit SAN oder mit lokalen Festplatten in RAID-Konfigurationen. Und ursprünglich haben wir ein Produkt für diese konzipiert. Das Monitoring von SMART war für diese Aufgabe nicht relevant. Aber da die Leute die Software für das Monitoring von Arbeitsstationen angepasst hatten, kamen die Anfragen zur Implementierung des SMART-Monitorings. Bald werden wir es umsetzen.
Mit dem Erscheinen von Veliam Connector war es nicht mehr notwendig, einen VPN-Server im Unternehmensnetzwerk zu implementieren oder RDGW einzurichten, oder einfach Ports zu den notwendigen Maschinen für die RDP-Verbindung weiterzuleiten. Viele nutzen unser System ausschließlich für diese Fernverbindungen. Der Veliam Connector ist nur für Windows verfügbar, und einige Unternehmensnutzer verbinden sich von ihren privaten Laptops mit MacOS zu Arbeitsstationen oder Terminals im Unternehmensnetzwerk. Daher sieht sich der Systemadministrator gezwungen, aufgrund einiger Benutzer doch wieder das Thema Portweiterleitungen oder VPN aufzugreifen. Deshalb beenden wir jetzt die Version des Veliam Connectors für MacOS. Benutzer ihrer geliebten Apple-Technik werden ebenfalls die Möglichkeit erhalten, sich mit einem Klick mit der Unternehmensinfrastruktur zu verbinden.
Ich mag es sehr, dass, wenn man eine große Anzahl von Nutzern im System hat, man sich nicht den Kopf darüber zerbrechen muss, was die Menschen brauchen und was bequemer wäre. Sie äußern selbst ihre Wünsche, so dass es für die nahen Entwicklungspläne sehr viele gibt.
Parallel planen wir jetzt die Übersetzung des Systems ins Englische und dessen Verbreitung im Ausland. Wir wissen noch nicht, wie wir das Produkt außerhalb unseres Landes vertreiben werden, suchen nach Möglichkeiten. Vielleicht wird es später einen eigenen Artikel darüber geben. Möglicherweise kann uns jemand, der diesen Artikel gelesen hat, den notwendigen Weg aufzeigen oder weiß selbst, wie das geht, und bietet seine Dienste an. Wir wären dankbar für die Hilfe.
Quelle: habr.com
