So begrenzen Sie die Auswirkung von Kundenänderungen auf Produktionssysteme

Question

Unser Shop hat einige Web-/SMS/DB -Lösung für ein Dutzend Client -Installationen entwickelt. Die Anwendungen haben einige Echtzeit-Leistungsanforderungen und sind gerade gut genug, um ordnungsgemäß zu funktionieren. Das Problem ist, dass die Clients (Eigentümer der Produktionserver) dieselbe Server/Datenbank für Anpassungen verwenden, die Probleme mit der Leistung der von uns erstellten und bereitgestellten Anwendungen verursachen.

Einige Beispiele für Anpassungen der Kunden:

• Hinzufügen großer Tabellen mit vielen Textdatenatypen für die Spalten, die in den Abfragen auf andere Datentypen gegossen werden
• Keine Primärschlüssel, Indizes oder FK -Einschränkungen
• Verwendung externer Skripte, die verwendet werden count(*) from table where id = x, in einer Schleife aus dem Skript, um zu bestimmen, wie weitere Abfragen später im selben Skript erstellt werden. (Keine Massenaktionen, die der Planer optimieren oder einfach alles in einem einzigen Pass machen kann)
• Alle neuen Codedateien auf dem Server werden mit 0777 Berechtigungen erstellt/gehören

Die Kunden nehmen keine Vorschläge/Kritik gut. Wenn wir einfach weitermachen und versuchen, die Skripte selbst zu portieren/zu ändern, kann der alte Code zurückkommen und alle Änderungen, die wir vornehmen, klopft! Oder ohne begrenzte Kenntnis ihrer Anwendungsfälle brechen wir die Funktionalität, während wir versuchen, ihre Änderungen zu optimieren.

Meine Frage lautet: Wie können wir die Ressourcen auf Abfragen/Anwendungen einschränken, was wir erstellen und bereitstellen? Gibt es pragmatische Optionen in solchen Szenarien? Wir waren stolz darauf, eine OSS -Lösung zu haben, aber es scheint, dass es zu einer Haftung geworden ist.

Wir verwenden PG 8.3, das auf einem Bereich auf Linux -Distos ausgeführt wird. Die Clients bevorzugen PHP, aber Shell -Skripte, Perl, Python und PLPGSQL werden in der einen oder anderen Form auf dem System verwendet.

Answer 1

Dieses Problem begann ungefähr zwei Minuten, nachdem der erste Client den ersten Computer vollen Zugriff erhielt und seitdem nicht mehr verschwunden ist. Jedes Mal, wenn jemand, dessen Prioritäten schnell geschäftorientiert werden, schnell erledigt werden, werden sie schlampig darüber sein und Dinge für alle vermasseln. So funktionieren die Dinge, denn das ordnungsgemäße Design und die richtige Implementierung sind schwieriger als billige Hacks. Sie werden dieses Problem nicht lösen. Alles, was Sie tun können, ist herauszufinden, wie es dem Kunden es einfacher macht, mit Ihnen zu arbeiten, als gegen Sie. Wenn Sie es richtig machen, sieht es eher nach einem hervorragenden Service als nach Nörgeln aus.

Zunächst einmal die Datenbankseite. Es gibt jetzt Möglichkeit, Abfragebressourcen in PostgreSQL zu kontrollieren. Die Hauptschwierigkeit besteht darin, dass Tools wie "schöne" CPU -Nutzung der CPU -Steuerung, aber wenn die Datenbank nicht in RAM passt, kann sie sehr gut die I/A -Nutzung sein, die Sie tötet. Sieh dir das an Entwicklernachricht Zusammenfassung der Probleme hier.

Wenn es tatsächlich eine CPU ist, die die Kunden durchbrennen, können Sie zwei Techniken verwenden, um diese Situation zu verbessern:

• Installieren Sie eine C -Funktion, die die Prozesspriorität ändert (Beispiel 1, Beispiel 2) und stellen Sie sicher, dass wenn sie etwas ausführen, das zuerst aufgerufen wird (vielleicht in ihre PSQL -Konfigurationsdatei eingeben, es gibt andere Möglichkeiten).
• Schreiben Sie ein Skript, das nach Postmasterprozessen sucht, die von ihrer BenutzerID hervorgebracht werden, und renice sie, lassen Sie es häufig in Cron oder als Daemon laufen.

Es hört sich so an, als ob Ihr Problem nicht die jeweiligen Abfrageprozesse sind, die sie ausführen, sondern auch andere Modifikationen, die sie an der größeren Struktur vornehmen. Es gibt nur eine Möglichkeit, damit fertig zu werden: Sie müssen den Kunden so behandeln, als würden sie ein Eindringling sind, und die Ansätze dieses Teils des Computersicherheitsfeldes verwenden, um zu erkennen, wenn sie Dinge vermasseln. Ernsthaft! Installieren Sie ein Intrusionserkennungssystem wie Tripwire auf dem Server (es gibt bessere Tools, das ist nur das klassische Beispiel), und lassen Sie es Sie aufmerksam machen, wenn sie etwas berühren. Neue Datei, die 0777 ist? Sollte direkt aus einem ordnungsgemäßen IDS -Bericht herausspringen.

Auf der Datenbankseite können Sie die Datenbank nicht direkt erkennen, die nützlich geändert wird. Sie sollten jeden Tag einen PG_DUMP des Schemas in eine Datei machen (pg_dumpall -g und pg_dump -s, Dann differenzieren Sie das gegen die letzte, die Sie geliefert haben, und alarmieren Sie erneut, wenn es sich geändert hat. Wenn Sie dies gut verwalten, wird der Kontakt mit dem Client in "Wir haben festgestellt, dass Sie sich auf dem Server geändert haben ... Was versuchen Sie damit zu erreichen?" Das lässt Sie so aussehen, als würden Sie wirklich darauf achten. Das kann zu einer Verkaufsmöglichkeit werden, und sie können möglicherweise aufhören, mit Dingen genauso zu fummeln, nur zu wissen, dass Sie es sofort fangen werden.

Die andere Sache, die Sie sofort durchführen sollten, ist so viel Versionskontrollsoftware wie möglich in jedem Client -Box. Sie sollten in der Lage sein, sich bei jedem System anzumelden, das entsprechende Status/Diff -Tool für die Installation auszuführen und zu sehen, was sich geändert hat. Holen Sie sich das auch regelmäßig an Sie. Dies funktioniert wiederum am besten, wenn es mit etwas kombiniert wird, das das Schema als Komponente für das, was es verwaltet, abgelegt hat. Nicht genügend Menschen verwenden ernsthafte Versionskontrollansätze für den Code, der in der Datenbank lebt.

Das ist der Hauptsatz von technischen Ansätzen, die hier nützlich sind. Der Rest von dem, was Sie haben, ist ein klassisches Problem mit Beratungskunden -Kundenmanagement, das weitaus ein Problem mit Menschen ist als ein Computer. Machen Sie sich auf, es könnte schlechter sein-FSM helfen Ihnen, wenn Sie ihnen ODBC-Zugriff gewähren, und sie stellen fest, dass sie ihre eigenen Fragen in Zugriff oder so einfachem so einfach schreiben können.