Si on vous demandait si un système pouvait maintenir une double croissance, quelles seraient les 3 choses que vous feriez pour répondre?

Question

Disons au travail, votre patron dit:

  

Ce système là-bas, qui a perdu tout son savoir institutionnel mais semble fonctionner assez bien à l’heure actuelle, pourrions-nous y doubler les données et survivre?

Vous ne connaissez pas le système.

Il s'agit de SQL Server 2000 (principalement une application de base de données).

Il n'y a pas d'environnement de test.

Vous pourrez peut-être le pirater le week-end si vous devez exécuter un test de performance.

Quelles seraient les 3 choses que vous feriez pour vous convaincre, puis votre manager, de supporter cette charge supplémentaire? Et si vous ne pouviez pas le faire, sur le même matériel ... le matériel supplémentaire (mesuré en dollars) qu'il faudrait pour satisfaire cette demande.

Pour répondre à la réponse de Doofledorfer, vos hypothèses sont quasiment toutes à 180 degrés. Mais c’est ma faute pour une question ambiguë.

1. L'un des serveurs principaux exécute 7x24 à 70% de la base et génère des pics à partir de là et personne ne sait ce qu'il fait.

2. Ce n’est pas une question de buy-in ou de gémissement ... Notre entreprise n’a peut-être pas beaucoup de choix en la matière.

3. Parce que cela est imposé par une autorité externe, des retards dans la mise en œuvre pourraient entraîner de lourdes amendes. Si grande réunion pour évaluer le risque est presque impossible. Il y a un risque, que doubler les données en déchargeant le système prenne le système pour les clients existants.

J'espérais que quelqu'un dirait quelque chose du genre "Vérifiez si vous mettez le système hors ligne dimanche soir à minuit et exécutez des tests SQLIO pour vérifier si le sous-système de stockage est proche de la saturation. Des choses comme ça.

Answer 1

1. Configurez un environnement de test, même si je dois le faire sur mon ordinateur portable.

2. Activez une sorte de journalisation sur le système de production pour avoir une idée du volume des transactions en plus du volume de données.

3. Lisez le code source alors que je lance des tests de contrainte sur mon ordinateur portable avec des quantités de données croissantes.

Cela dit, je sympathise avec cette mission, car elle est injuste. C'est comme demander à quelqu'un dans un bateau si le bateau peut flotter avec deux fois la cargaison - mais vous ne pouvez pas sortir du bateau ou le retirer de son service régulier.

Answer 2

Vous venez de décrire un projet Agile typique. Votre réponse devrait être:

1. Je ne sais pas et je ne pourrai pas le dire sans faire d’essais.
2. Outre le volume de données, des problèmes peuvent survenir avec les modèles d'utilisation, les interactions entre applications, le réglage de la base de données et du serveur, etc.
3. Voyons maintenant une liste de base des facteurs de risque et la manière de les résoudre.
4. Une fois cela fait, examinons-les par ordre de risque inverse. et prendre une décision d'arrêt / de poursuite à mesure que nous développons les résultats.
5. etc.

Sans l’adhésion et la participation de la direction au moins à ce niveau, toute autre réponse que vous pourriez donner correspond à un souhait à haut risque et au "3 le plus important". est un non séquentiel.

Je serais optimiste à moins que votre système actuel soit déjà chargé en grande partie. La plupart des serveurs doivent fonctionner à moins de 50% de leur capacité sur toutes les ressources, ou bénéficier de la vie. Et je suppose que vous n'auriez pas la conversation si le serveur existant traitait déjà des problèmes de charge; bien que " semble fonctionner plutôt bien en ce moment " est assez imprécis pour être inquiétant.

Answer 3

cela dépend principalement de son niveau actuel. Si le doublage passe de 2 Go à 4 Go, faites-le. Si vous passez de 1 To à 2 To, vous avez un peu de planification à faire.

Je collectais des informations à l'aide de l'Analyseur de performances et les transmettais pour vous aider à prendre une décision éclairée.

Answer 4

Cela dépend de ce que vous entendez par "doubler les données".

Si cela ne concerne qu'une table (par exemple, la table product), vous êtes probablement en sécurité, car la plupart des requêtes faisant référence à cette table risquent de doubler le temps d'exécution (cela suppose que vous ne référencez pas le même temps deux fois dans une requête).

Le problème se posera si vous doublez la quantité de données dans toutes les tables car le temps d’exécution risque alors d’augmenter de façon exponentielle, ce qui risque de poser de sérieux problèmes.

Mais en général, je soutiendrais le répondre par un imbécile