Comment limiter l'effet des modifications des clients aux systèmes de production

Question

Notre boutique a développé quelques solutions WEB / SMS / DB pour une douzaine d'installations de clients. Les applications ont des exigences de performance en temps réel, et sont juste assez bon pour fonctionner correctement. Le problème est que les clients (propriétaires des serveurs de production) utilisent le même serveur / base de données pour les personnalisations qui causent des problèmes avec les performances des applications que nous avons créé et déployé.

Quelques exemples de personnalisation des clients:

• Ajout de grandes tables avec de nombreux types de données de texte pour les colonnes qui se jettent à d'autres types de données dans les requêtes
• Pas de clés primaires, index ou contraintes FK
• Utilisation des scripts externes qui utilisent count(*) from table where id = x, dans une boucle à partir du script, afin de déterminer comment construire plus tard des requêtes dans le même script. (Aucune action en vrac que le planificateur peut optimiser ou tout simplement faire tout en une seule passe)
• Tous les nouveaux fichiers de code sur le serveur sont créés / appartenant à root, avec 0777 autorisations

Les clients ne prennent pas bien des suggestions / critiques. Si nous venons aller de l'avant et essayer de port / changer les scripts nous-mêmes, l'ancien code peut revenir, tout changement démolir que nous faisons! Ou avec des connaissances limitées de leurs cas d'utilisation, nous rompons la fonctionnalité tout en essayant d'optimiser leurs changements.

Ma question est la suivante: comment pouvons-nous limiter les ressources aux requêtes / applications autres que ce que nous créons et déployons? Y at-il des options pragmatiques dans des scénarios comme celui-ci? Nous étions fiers d'avoir une solution OSS, mais il semble qu'il est devenu une responsabilité.

Nous utilisons PG 8.3 en cours d'exécution sur une plage sous Linux Distos. Les clients préfèrent php, mais les scripts shell, perl, python et plpgsql sont tous utilisés sur le système sous une forme ou une autre.

Answer 1

Ce problème a commencé environ deux minutes après le premier client a eu un accès complet au premier ordinateur, et il n'a pas disparu depuis. Chaque fois que quelqu'un dont les priorités sont axées sur le travail se fait des affaires rapidement ils seront bâclée à ce sujet et visser les choses pour tout le monde. C'est tout simplement la façon dont les choses fonctionnent, parce que la conception et la mise en œuvre correcte sont plus durs que hacks bon marché. Tu ne vas pas à résoudre ce problème, tout ce que vous pouvez faire est de comprendre comment le rendre plus facile pour le client de travailler avec vous que contre vous. Si vous le faites correctement, il ressemblera à un excellent service plutôt que lancinante.

Tout d'abord, du côté de la base de données. Il y a maintenant moyen de contrôler les ressources de requête dans PostgreSQL. La principale difficulté est que des outils tels que l'utilisation du processeur de contrôle « agréable », mais si la base de données ne correspond pas dans la RAM, il peut très bien être l'utilisation d'E / S qui vous tue. Voir cette message développeur résumant les questions ici

Maintenant, si en fait, il est CPU les clients brûlent à travers, vous pouvez utiliser deux techniques pour améliorer cette situation:

• Installer une fonction C qui modifie la priorité de traitement ( exemple 1 , exemple 2 ) et assurez-vous chaque fois qu'ils courent quelque chose, il est appelé d'abord ( peut-être mis dans leur fichier de configuration psql, il existe d'autres moyens).
• Ecrire un script qui scrute les processus postmaster engendrés par leur userid et les renice, le faire tourner souvent cron ou comme un démon.

Il semble que votre problème ne sont pas les processus de requête en cours d'exécution particulières qu'ils, mais d'autres modifications qu'ils vous formulez à la structure plus grande. Il n'y a qu'une seule façon de faire face à cela: vous devez traiter le client comme ils sont un intrus et d'utiliser les approches de cette partie du domaine de la sécurité informatique pour détecter quand ils vis les choses. Sérieusement! Installer un système de détection d'intrusion comme Tripwire sur le serveur (il y a de meilleurs outils, c'est juste l'exemple classique), et l'ont vous alerter quand ils touchent quoi que ce soit. Nouveau fichier qui est 0777? Devrait sauter droit sorti d'un rapport IDS approprié.

Du côté de la base de données, vous ne pouvez pas détecter directement la base de données étant utilement modifiée. Vous devriez faire un pg_dump du schéma chaque jour dans un fichier ( pg_dumpall -g et pg_dump -s , puis diff que contre le dernier vous avez livré et alerte à nouveau lorsque vous il a changé. Si vous gérez bien que ce, le contact avec le client se transforme en « nous avons remarqué que vous avez changé sur le serveur ... qu'est-ce que vous essayez d'accomplir avec cela? » qui vous fait ressembler vous êtes vraiment y prêter attention. cela peut se transformer en une opportunité de vente, et ils peuvent cesser de jouer avec les choses autant que sachant que vous allez attraper immédiatement.

L'autre chose que vous devriez commencer à faire immédiatement est d'installer autant de logiciels de contrôle de version que vous pouvez sur chaque boîte client. Vous devriez pouvoir vous connecter à chaque système, exécutez l'outil d'état / diff approprié pour l'installation, et voir ce qui a changé. Obtenir que envoyé par la poste régulièrement aussi. Encore une fois, cela fonctionne mieux si elle est combinée avec quelque chose qui déverse le schéma en tant que composant à ce qu'il gère. Trop peu de gens utilisent des méthodes de contrôle de version sérieux sur le code qui vit dans la base de données.

C'est le principal ensemble d'approches techniques utiles ici. Le reste de ce que vous avez un problème de gestion de la clientèle de conseil classique qui est beaucoup plus d'un problème que les gens un ordinateur. Remonter le moral, ça pourrait être pire - EFM vous aider si vous leur donnez accès ODBC et eey découvrent qu'ils peuvent écrire leurs propres requêtes dans Access ou quelque chose de simple comme ça.