Für eine Webagentur oder Marketingagentur ermöglicht ein VDS-Server das Zusammenstellen von Kundenwebsites in einer verwalteten Umgebung. Hier können Arbeitsprojekte, Testkopien, Datenbanken und interne Teamwerkzeuge untergebracht werden, ohne separate Infrastrukturen für jede kleine Bestellung zu schaffen. Aber ein gemeinsamer Server sollte nicht gemeinsame Passwörter, Verzeichnisse und Ressourcen ohne Einschränkungen bedeuten. Andernfalls kann ein misslungenes Update eines Plugins, eine infizierte Datei oder ein umfangreicher Produktimport nicht nur eine Website, sondern die gesamte Gruppe betreffen.
Das Problem entsteht häufig nicht durch unzureichende VPS-Leistung. Websites werden von einem Systembenutzer gestartet, verbinden sich über ein gemeinsames Konto mit Datenbanken und gelangen in ein großes Backup-Archiv. Zunächst scheint dieses Schema bequem zu sein. Im Laufe der Zeit stellt sich heraus, dass ein separates Projekt nicht sicher gestoppt, wiederhergestellt oder an einen anderen Entwickler übergeben werden kann, ohne die restliche Infrastruktur zu berühren.
Wie man Kundenprojekte innerhalb eines VPS trennt
Jede Website sollte von Anfang an als separates Objekt betrachtet werden. Sie sollte eigene Dateien, eine Datenbank, Protokolle, Einstellungen und Ressourcengrenzen haben. Dann kann sie unabhängig von benachbarten Projekten aktualisiert, verschoben oder wiederhergestellt werden.
Das grundlegende Hosting-Schema sollte standardisiert und auf alle neuen Kunden angewendet werden:
-
einen separaten Systembenutzer, ein Verzeichnis und einen PHP-Pool für jede Website erstellen;
-
eine separate Datenbank und ein Konto ohne Zugriff auf fremde Tabellen verwenden;
-
Speicher-, CPU-, Prozess- und Speicherplatzlimits festlegen;
-
Arbeits- und Testumgebungen trennen;
-
separate Fehler- und Anfrageprotokolle für jedes Projekt führen;
-
Passwörter und Zugangsschlüssel nicht in offenen Dateien oder gemeinsamen Tabellen des Teams speichern.
Ein separater Systembenutzer ist nicht nur für die Ordnung in den Verzeichnissen erforderlich. Wenn mehrere Websites mit denselben Rechten gestartet werden, kann ein schädliches Skript auf einer von ihnen Dateien benachbarter Projekte lesen oder ändern. In den Empfehlungen zur Sicherheit von WordPress wird ebenfalls geraten, die Berechtigungen des Dateisystems einzuschränken und Prozessen das Schreiben dort zu verweigern, wo es nicht erforderlich ist.
Es ist ebenso gefährlich, alle Websites über einen Benutzer mit weitreichenden Rechten mit Datenbanken zu verbinden. Die Kompromittierung einer Konfigurationsdatei würde in diesem Fall den Zugriff auf die Daten anderer Kunden öffnen. Für jedes CMS sollte ein eigenes Konto erstellt werden, das nur mit der entsprechenden Datenbank arbeiten darf.
Lesen Sie auch: Infrastructure as Code auf VPS: Wie man das Management der Infrastruktur vereinfacht
Begrenzen Sie die Ressourcen einzelner Websites
Ein Shop kann während eines nächtlichen Imports den gesamten verfügbaren Speicher beanspruchen oder so viele Prozesse starten, dass die anderen Websites langsam reagieren. Der Shop selbst kann dabei weiterhin verfügbar sein, weshalb die Ursache des Problems nicht immer sofort gefunden wird.
Die Limits sollten nicht zu streng sein. Ihre Aufgabe ist es, das Projekt nicht zu bremsen, sondern zu verhindern, dass ein Prozess unkontrolliert den gesamten Server nutzt. Nach dem Start einer neuen Website sollte man einige Wochen die Last beobachten und dann Grenzen mit einem angemessenen Puffer festlegen.
Zugriff nur auf das benötigte Projekt gewähren
Ein gemeinsames Root-Passwort, das allen Entwicklern und Auftragnehmern bekannt ist, entzieht der Agentur die Kontrolle. Es ist unmöglich festzustellen, wer Änderungen vorgenommen hat, schnell den Zugang einer Person zu sperren oder ihre Arbeit auf eine bestimmte Website zu beschränken.
Für das Zugriffsmanagement sollten einige Regeln eingeführt werden:
-
persönliche SSH-Schlüssel anstelle eines gemeinsamen Passworts für das gesamte Team ausgeben;
-
keinen Root-Zugriff gewähren, wenn dem Spezialisten die Rechte auf ein bestimmtes Verzeichnis ausreichen;
-
eine Liste aktiver Zugriffe mit Ausgabedatum und verantwortlicher Person führen;
-
Konten und Schlüssel nach Abschluss der Arbeiten löschen;
-
einmal pro Quartal überprüfen, wer noch Zugriff auf den Server und die Verwaltungsoberflächen hat;
-
Zwei-Faktor-Authentifizierung für Konten mit erweiterten Rechten verwenden.
Ein externer SEO-Spezialist benötigt normalerweise CMS, Analytik und Suchkonsolen, aber nicht die Dateiumgebung des gesamten VPS. Ein Content-Manager benötigt keinen Zugriff auf die Datenbank, und ein Entwickler einer Website sollte die Verzeichnisse anderer Kunden nicht sehen. Dies entspricht dem Prinzip der geringsten Privilegien: Der Benutzer erhält nur die Rechte, die er benötigt, um seine Arbeit auszuführen.
Schützen Sie die Staging-Umgebung nicht weniger als die Produktionswebsite
Wenn die Staging-Umgebung in einem Konto mit anderen Websites gehostet wird, kann ein Hack Zugriff nicht nur auf die Testkopie öffnen. Ein Angreifer kann auf benachbarte Verzeichnisse zugreifen, Konfigurationsdateien mit Passwörtern finden oder Dateien anderer Projekte ändern.
Daher sollte der Zugriff auf die Staging-Umgebung durch ein Passwort, IP-Adressen oder ein privates Netzwerk eingeschränkt werden. Das Verbot der Indizierung in robots.txt für externe Besucher schützt nicht.
Überprüfen Sie auch die Integrationen: Die Testversion sollte keine echten E-Mails senden, Zahlungen durchführen, Geschäfte in CRM erstellen oder Lagerbestände ändern.
Wie man die Infrastruktur nach dem Start aufrechterhält
Es reicht nicht aus, die Websites zu Beginn gut zu trennen. Die Anzahl der Kunden wächst, in Projekten kommen neue Module hinzu, Auftragnehmer und Update-Zeitpläne ändern sich. Ohne regelmäßige Kontrolle verwandelt sich selbst ein ordentlich organisierter VPS allmählich in einen digitalen Dschungel, in dem niemand weiß, welche Prozesse laufen und wem die Zugriffe gehören.
Richten Sie separate Backups für jede Website ein
Ein Backup des gesamten VPS ist praktisch für die Wiederherstellung des Servers nach einem vollständigen Ausfall, eignet sich jedoch schlecht für die tägliche Arbeit der Agentur. Wenn durch ein misslungenes Update ein Projekt beschädigt wird, können nicht gleichzeitig fünfzehn funktionierende Websites zurückgesetzt werden.
Das Arbeitsbackup-Schema sollte Folgendes berücksichtigen:
-
separate Kopien von Dateien und Datenbanken für jeden Kunden;
-
die Häufigkeit der Sicherung entsprechend dem Aktualisierungstempo der Informationen;
-
mindestens eine Kopie außerhalb des Haupt-VPS aufbewahren;
-
Archive mit persönlichen Daten verschlüsseln;
-
automatische Kontrolle des Abschlusses von Aufgaben und der Dateigröße;
-
periodische Testwiederherstellung in einer sauberen Umgebung.
Die Häufigkeit der Sicherung wird nicht nach der Größe der Website, sondern nach dem Umfang der Informationen bestimmt, die verloren gehen dürfen. Ein Unternehmensressource, bei dem Nachrichten mehrmals im Monat veröffentlicht werden, kann mit einem täglichen Backup auskommen. Für einen Shop mit ständigen Bestellungen bedeutet ein Backup pro Tag bereits das Risiko, einen erheblichen Teil der Transaktionen zu verlieren.
Verfolgen Sie, welche Website die Spitzenlast erzeugt
Eine ressourcenintensive Website kann alle Projekte auf dem Server verlangsamen. Häufig sind Produktimporte, Backups, Cron-Jobs, Bot-Traffic oder Plugin-Fehler die Ursache.
Richten Sie Benachrichtigungen über CPU- und Speicherspitzen, Festplattenspeicher, 5xx-Fehler und steigende Antwortzeiten ein. Wenn Sie die Quelle der Last gefunden haben, stoppen Sie den problematischen Prozess und überprüfen Sie die Protokolle, Plugins, Cron und Datenbankabfragen.
Wenn die Last durch einen Fehler verursacht wird, muss dieser behoben werden. Wenn die Website tatsächlich mehr Ressourcen benötigt, begrenzen Sie ihren Verbrauch oder verschieben Sie sie auf einen separaten virtuellen Server, damit sie andere Kunden nicht beeinträchtigt.
Führen Sie ein technisches Blatt für jedes Projekt
Wenn die Agentur viele Websites betreut, sollten wichtige Informationen nicht nur im Kopf eines Entwicklers bleiben. Für jedes Projekt sollten die PHP-Version, der Standort der Datenbank, angeschlossene externe Dienste, der Backup-Zeitplan, verantwortliche Spezialisten und der Notfallwiederherstellungsprozess festgehalten werden.
Es ist auch nützlich zu vermerken, welche Prozesse die größte Last erzeugen. Wenn bekannt ist, dass der Shop täglich um 03:00 Uhr einen Katalog importiert, muss das Team nicht jedes Mal einen kurzen Anstieg der CPU-Nutzung untersuchen. Wenn die Last zu einem anderen Zeitpunkt auftritt, kann sie bereits als Abweichung betrachtet werden.
Lesen Sie auch: Virtuelle Server in der Entwicklung: Wie man das Leben von Programmierern erleichtert
Das technische Blatt sollte nach Änderungen an der Serverkonfiguration, der Anbindung neuer Integrationen oder der Übergabe des Projekts an ein anderes Team aktualisiert werden. Dies vereinfacht die Wartung und verkürzt die Wiederherstellungszeit nach einem Fehler.
Wann eine Kundenwebsite auf einen separaten Server verschoben werden sollte
Die Konfiguration des gesamten VPS aufgrund einer einzigen ressourcenintensiven Website zu erhöhen, ist nicht immer rentabel. Die Agentur beginnt, zusätzliche Ressourcen für die gesamte Gruppe zu bezahlen, obwohl sie hauptsächlich von einem Kunden genutzt werden. In einer solchen Situation ist es logischer, das Projekt zu trennen.
Die Ausfallzeit eines Projekts hat hohe Kosten
Eine kleine Visitenkarte-Website und ein Online-Shop, über den der Großteil der Verkäufe des Unternehmens abgewickelt wird, sollten nicht das gleiche Hosting-Modell haben, nur weil beide auf WordPress laufen. Für einen kritischen Dienst sind separates Backup, eigene Ressourcen und die Möglichkeit, technische Arbeiten unabhängig von anderen Kunden durchzuführen, wichtig.
Für einen großen Shop, ein Portal oder ein System mit erheblichen Datenmengen kann der nächste Schritt die Miete eines dedizierten Servers sein. Allerdings sollte die Entscheidung nicht an die Anzahl der Domains gebunden sein. Dutzende einfacher Websites benötigen manchmal weniger Ressourcen als ein Katalog mit komplexen Filtern, Suche, Synchronisierung von Beständen und ständiger Verarbeitung von Dateien.
Das Projekt zieht regelmäßig einen erheblichen Teil der Ressourcen ab
Wenn ein Shop an einem normalen Tag die Hälfte des VPS-Speichers nutzt, wird während eines Verkaufs, einer Werbekampagne oder eines massiven Lagerimports nicht mehr genug vorhanden sein. Der Umzug sollte besser vor der Spitzenzeit geplant werden, um Zeit für Tests, Datenbanksynchronisation und DNS-Updates zu lassen.
Vor der Migration sollte überprüft werden, ob die Last durch Caching, Optimierung von Abfragen, Warteschlangen oder Änderung des Zeitplans für Hintergrundaufgaben verringert werden kann. Ein separater Server wird den langsamen Code nicht beheben, obwohl er ihm mehr Ressourcen gibt.
Die Website benötigt eine spezielle Softwareumgebung
Ein Kunde kann eine andere Version von Systembibliotheken, einen eigenen Webserver, nicht standardisierte Module oder einen separaten Update-Zeitplan verlangen. Es ist riskant, einen gemeinsamen VPS für ihn anzupassen: Eine Änderung der Konfiguration könnte die Funktionalität der anderen Websites beeinträchtigen.
Eine separate Umgebung ist auch angebracht, wenn der Kunde administrativen Zugriff haben möchte. Es ist nicht möglich, ihm Zugriff auf einen Server zu gewähren, auf dem sich externe Projekte befinden, selbst bei guten Beziehungen und unterzeichneten Vereinbarungen.
Ein VPS kann über Jahre hinweg ein bequemer Mittelpunkt für Kundenwebsites bleiben. Die Stabilität hängt nicht von der maximalen Leistungsreserve ab, sondern von den Regeln, nach denen die Agentur Projekte erstellt, Zugriffe gewährt, Backups einrichtet und auf Lastspitzen reagiert. Wenn diese Prozesse beschrieben und nacheinander ausgeführt werden, verwandelt sich das Problem eines Kunden nicht in eine gemeinsame Katastrophe.