Dans ma carrière, j'ai été en mesure d'examiner un grand nombre d'entrepôts de données, à différents stades de leur cycle de vie. J'ai observé que, de façon générale, nous n'avions pas la même rigueur dans le fonctionnement du système d'entrepôt de données que les personnes en charge du système transactionnel peuvent attendre de leurs systèmes. En toute équité, un entrepôt de données n'est pas un système transactionnel, et peu d'entreprises peuvent justifier un contrat de service 24x7 pour l'accès à l'entrepôt de données. Mais Allez les gars, faut-il ressembler à des chiens fous en cas d'urgence? Comme nous le savons tous, les problèmes arrivent - surtout lorsqu'un entrepôt de données est en aval de tout autre système dans votre entreprise.
Exploiter un entrepôt de données de manière professionnelle n'est pas si différent des autres systèmes: Suivre les bonnes pratiques, prévoir les catastrophes, et s'entraîner. Voici quelques suggestions simples, basées sur mes observations des déploiements actuels.
Négociez un contrat de service avec les utilisateurs. L'important ici est de négocier, puis ensuite de prendre cet engagement sérieusement. la décision à propos du niveau de service doit être faite entre les sponsors métiers et le responsable de l'équipe en charge de l'entrepôt de données, basée sur une analyse approfondie des coûts et des avantages d'ajuster le contrat de service à la plus haute disponibilité. Les bases du contrat doivent être négociées tôt dans le projet, puisque le besoin d'une haute disponibilité peut changer significativement l'architecture physique de l'entrepôt.
Utilisez des comptes de services pour toutes les opérations de l'entrepôt de données. Vous pensez que c'est logique que tous les opérations de production devraient utiliser un compte de service spécial avec les autorisations appropriées, mais je ne comptes plus les fois où j'ai vu un chargement échouer parce que l'administrateur de base de données a quitté l'entreprise et que son compte personnel fut devenu inactif.
Isolez les développements des tests et de la production. Encore, même si c'est évident, ça ne l'est pas. J'ai observé deux barrières empêchant les équipes d'avoir cette rigueur: les coûts et la complexité.
Les coûts de matériel et de logiciel peuvent être importants, parce que la meilleure pratique consiste à configurer un environnement de test identique à celui de production. Vous pourriez être en mesure de négocier une réduction des coûts de licences logicielles pour l'environnement de test, mais les vendeurs sont rarement très serviable. Si vous devez rogner sur le matériel, commencez par réduire le stockage, testez avec un sous-ensemble des données. Ensuite, je réduirais le nombre de processeurs. Puis, en dernier recours, je réduirais la mémoire de la machine de test. Je déteste vraiment faire ces compromis, parce que les performances de traitement et d'interrogation pourraient changer de façon discontinue. En d'autres termes, le système de test pourrait se comporter différemment avec moins de données, de processeurs ou de mémoire. Les systèmes de développement sont généralement des machines de bureau ordinaires, bien que leurs logiciels devraient être pratiquement identiques ceux de test et de production. Négociez avec les fournisseurs de logiciels pour qu'ils fournissent autant de licences de développement que vous en avez besoin à un coût proche de zéro. Je pense que toutes les licences de développement devraient coûter moins de 100 $. (Bonne chance!)
Tout ce que vous faites pour l'environnement de production doit avoir été conçu dans l'environnement de développement et le script de déploiement testé dans l'environnement de test. Chaque opération sur le doit passer par des scripts et des tests rigoureux, que ça soit le déploiement d'un nouveau data-mart, l'ajout d'une colonne, la modification d'index, le changement de votre conception, la modification d'un paramètre de base de données, la sauvegarde ou la restauration. Centralisez l'administration des environnements, comme le déploiement de nouvelles requêtes et des outils de reporting, le déploiement de nouveaux rapports et l'évolution des plans de sécurité, devraient être tout aussi rigoureusement testés et scénarisés si vos outils le permettent.
Lorsque vous rédigez des scripts d'administration, paramétrez les informations de connexion comme le nom du serveur dans des fichiers de configuration, si vos outils le permettent. Faites des scripts pour tout ce que vous pouvez, puis vérifier ces scripts dans le contrôle de la source.
Les fournisseurs de logiciels d'entrepôts de données ne rendent pas les choses faciles pour vous aider à faire la bonne chose. Les outils frontaux et les serveurs OLAP sont particulièrement mauvaises pour aider - ou permettre même - le développement de scripts pour les opérations d'administration. Il est très difficile de coordonner le déploiement d'un nouveau composant à travers la base de données, l'ETL, et les outils d'analyse de reporting. Soyez très prudent, et testez, testez, testez!
Ajoutez à cela les service packs, les correctifs et les mises à jour des produits. Les personnes concernées dans l'équipe en charge de l'entrepôt de données devraient être responsables des mises à jour, y compris des correctifs pour tous les produits utilisés dans l'environnement de l'entrepôt de données. Fixez-vous un rendez-vous hebdomadaire récurrent pour parcourir les sites appropriés pour voir ce qui est disponible, et évaluez l'importance de chaque correctif ou mise à jour a sur votre projet. Vous ne devez pas installer tous les correctifs dès qu'ils sortent, mais vous devriez être informé à leur sujet. Si vous êtes proactif, vous pouvez garder vos appels coûteux au support pour des problèmes qui n'ont pas encore été résolus.
Rédigez une documentation pour toutes les opérations. Ce document doit contenir les instructions étape par étape pour effectuer une opération telle que la restauration d'une base de données ou une table, le déploiement d'un nouveau data-mart, l'ajout d'une nouvelle colonne dans une table. Vous devez avoir un document générique, puis personnalisez-le pour chaque opération que vous envisagez d'effectuer dans la production. Par exemple, si vous changez un paramètre de base de données, notez, de façon suffisamment détaillée, les étapes à suivre. Ensuite, testez la procédure sur le système de test avant de l'appliquer à la production. Ceci est absolument essentiel si vous effectuez une opération à travers l'interface graphique d'un outil plutôt que via un script.
L'administration n'est pas la partie la plus amusante de l'entrepôt de données, mais avec une bonne planification et de la pratique, vous pouvez répondre à la pagaille inévitable avec calme et réflexion.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #52: let's improve our operating procedures", publié le 4 mars 2004.
Aucun commentaire:
Enregistrer un commentaire