Comment tester et optimiser lorsque vous ne pouvez pas reproduire l'environnement?

Dans le passé, j'ai travaillé dans une variété d'environnements. Applications de bureau, jeux, éléments intégrés, services Web, travaux en ligne de commande, sites Web, rapports de base de données, etc. Tous ces environnements partageaient le même trait: quelle que soit leur complexité, quelle que soit leur taille, je pouvais toujours avoir un sous-ensemble ou une tranche de l'application sur ma machine ou dans un environnement de développement à tester.

Aujourd'hui non. Aujourd'hui, je me retrouve dans un environnement dont l'objectif principal est l'évolutivité. La reproduction de l'environnement est d'un coût prohibitif. Prendre une tranche de l'environnement, bien que plausible (certaines pièces devraient être simulées ou utilisées dans un mode à instance unique qu'elles ne sont pas faites pour faire), va un peu à l'encontre du but car il obscurcit la concurrence et le chargement qui le vrai système rencontre. Même un petit système de "test" a ses défauts. Les choses se comporteront différemment lorsque vous aurez 2 nœuds et que vous en aurez 64.

Mon approche habituelle de l'optimisation (mesurer, essayer quelque chose, vérifier l'exactitude, mesurer les différences, répéter) ne fonctionne pas vraiment ici car je ne peux pas faire efficacement les étapes 2 et 3 pour les parties du problème qui importent (robustesse de la concurrence et performances sous charge). Ce scénario ne semble cependant pas unique. Quelle est l'approche commune pour effectuer ce genre de tâche dans ce type d'environnement?

Il y a quelques questions connexes:

• cette question a à voir avec le matériel (comme les analyseurs de spectre) étant indisponible, qui peut être (relativement) facilement émulé.
• cette question concerne le suivi des bogues qui n'existent que dans les environnements de production, ce qui est utile - mais d'un type d'activité différent.

En fait, c'est difficile, mais je suis sûr que dans de nombreuses situations comparables, c'est principalement un problème d'organisation. La seule approche viable est probablement un mélange de mesures combinées, et pas seulement "une solution miracle". Certaines choses que vous pouvez essayer:

• la journalisation: comme je l'ai déjà écrit dans un commentaire, une journalisation excessive du temps et des ressources (qui est une sorte de profilage) peut vous aider à identifier les véritables goulots d'étranglement en production. Cela peut ne pas vous dire si une implémentation alternative fonctionnera mieux, mais cela vous aidera sûrement à éviter d'optimiser la partie complètement incorrecte de votre application.

• tester ce que vous pouvez tester à l'avance - de manière approfondie, avec beaucoup de planification initiale. Bien sûr, les choses se comporteront différemment en production, mais pas toutes . L'exactitude d'une implémentation différente peut souvent être vérifiée à l'avance - si une implémentation évolue bien, c'est une question différente. Mais la planification peut beaucoup aider. Réfléchissez bien aux problèmes que votre environnement de test peut résoudre pour vous, et lesquels ne le sont pas. Il y a presque toujours des choses où vous croyez à première vue "cela ne peut pas être testé au préalable", mais si vous y réfléchissez à deux fois, il y a souvent plus de possibilités.

• Travaillez en équipe. Lorsque vous essayez une nouvelle approche ou idée, discutez-en avec au moins une autre personne de votre équipe. Lorsque vous implémentez un algo différent, insistez sur les inspections de code et l'assurance qualité. Plus vous pouvez éviter de bugs et de problèmes au préalable, moins vous devrez résoudre de problèmes graves en production.

• Comme vous ne pouvez pas tout tester à l'avance, attendez-vous à des problèmes de production. Essayez donc de préparer une très bonne stratégie de secours lors de la mise en production d'un nouveau code. Lorsque votre nouveau code présente le risque d'être plus lent que l'ancienne solution, ou s'il présente un risque de plantage, assurez-vous de pouvoir passer à la version précédente dès que possible. S'il a le risque de détruire les données de production, assurez-vous d'avoir une bonne sauvegarde / récupération en place. Et assurez-vous de détecter de tels échecs en ajoutant un mécanisme de validation dans votre système.

• tenir un journal de projet ou un journal de solution - sérieusement. Chaque jour, vous découvrez quelque chose de nouveau sur l'environnement, écrivez-le - des réussites aussi bien que des échecs. Ne faites pas deux fois le même échec.

L'essentiel est donc - lorsque vous ne pouvez pas faire d'essais et d'erreurs, votre meilleure option est une planification initiale conservatrice et des techniques d'assurance qualité.

Si vous ne pouvez pas reproduire l'environnement en direct, la réalité inconfortable est que quoi que vous fassiez, il n'aura pas été suffisamment testé.

Alors que peux-tu faire?

Eh bien, tout ce qui doit évoluer, que ce soit un processus, un cluster de serveurs ou un volume de base de données doit être testé avec la règle zéro, un, infini à l'esprit pour déterminer où les goulots d'étranglement / limitations potentiels sont les E / S, les processeurs, la charge du processeur, inter - communication de processus, etc.

Une fois que vous avez cela, vous devriez avoir une idée du type de test affecté. S'il s'agit de tests unitaires, cela appartient traditionnellement au développeur, s'il s'agit de tests d'intégration / système, il peut y avoir des points de contact avec d'autres équipes qui peuvent être en mesure d'aider avec une expertise supplémentaire ou, mieux encore, des outils.

En parlant d'outils, il n'est pas vraiment du ressort du développeur de tester en charge un système au-delà de ce qui est possible dans leur environnement de développement. Cela devrait être poussé vers le département de test ou un autre tiers.

L'éléphant dans la pièce est bien sûr que les systèmes ne évoluent pas toujours de manière prévisible!

Dans une ancienne vie, j'étais DBA pour les bases de données bancaires avec des milliards de lignes et armé de plans d'exécution, nous pouvions généralement prédire combien de temps les requêtes prendraient sur une base de données inactive compte tenu des volumes d'entrée. Cependant, une fois que ces volumes atteindraient une certaine taille, le plan d'exécution changerait et les performances se détérioreraient rapidement à moins que la requête / base de données ne soit réglée.

Je suggérerais des expériences.

La journalisation trouvera des goulots d'étranglement. Vous pouvez ensuite essayer une implémentation alternative sur certaines machines, ou même sur toutes les machines avec une certaine probabilité, ou pour une période de temps limitée. Comparez ensuite les journaux pour vérifier les améliorations.

C'est le même cycle théorie-expérience-mesure auquel vous êtes habitué, mais plus coûteux à mettre en place - car les hypothèses doivent être exécutées en production - et selon votre volume, la réception de données importantes de la production peut également être lente.