Signes précoces d'un mauvais sysadmin

À mon avis, cela ressemble à ce que votre instinct vous a déjà dit que vous avez fait une mauvaise embauche et que vous recherchez des preuves pour renforcer cet instinct.

Voici quelques mauvaises habitudes SQL Server qui, à mon avis, peuvent être le signe d'un DBA inexpérimenté.

• redémarrer le serveur ou redémarrer le service sql server pour 'corriger' les problèmes
• ajouter des fichiers journaux de transactions supplémentaires sur différents lecteurs, car le journal actuel est en train de manquer d'espace disque
• rétrécir le journal des transactions est une partie régulière de la maintenance pour contrôler la taille du journal (rétrécir les fichiers de données est encore pire)
• utiliser l'option table ouverte dans SSMS (points bonus triples pour l'utiliser en production)
• être entièrement dépendant de l'interface graphique SSMS pour effectuer des sauvegardes et des restaurations
• ne pas comprendre la différence entre une connexion sql server et un utilisateur sql server

Incapacité de prioriser et de gérer plusieurs tâches à la fois.

Gestion du temps.

Planifie les activités autour d'un plan de travail. Sait que la maintenance doit avoir lieu pendant les temps morts. Gère les sauvegardes. Teste les sauvegardes/restaure. A un plan actif de récupération - ce n'est pas une question de "si" mais de "quand" le matériel tombera en panne. Doit être intéressé à savoir si les choses se cassent ou dégénèrent avant que vous ne le remarquiez. Pense que Nagios ou Solarwind est un must pour savoir si les systèmes sont vivants ou morts.

Documentation.

Devrait travailler avec un système de billetterie. Dépose des billets au nom des utilisateurs qui ne sont pas en mesure ou disposés à le faire pour suivre les problèmes.

Attitude.

Totalement ouvert à aider l'entreprise. Il n'y a pas de "je ne peux pas", ouvert. Dit "Je peux le faire si vous me fournissez ces ressources".

Regardez les questions qu'ils posent. Il semble que vous ayez un système assez complexe (de multiples serveurs SQL), donc si j'étais à votre place, la première chose que je ferais serait de déranger tout le monde pour qu'ils me parlent de ce qu'ils font tous, qui dépend d'eux et pourquoi, et de prendre des notes abondantes. Je ferais cela aussi près d'un tableau blanc que possible.

Il faudrait essayer de trouver et de tester les sauvegardes. S'il y a des problèmes de performance, j'exécuterais le profileur et perfmon (ou des outils similaires) pour essayer de comprendre quelles requêtes les causent. Je vérifierais le matériel pour m'assurer que les multiples serveurs SQL ont au moins un miroir matériel chacun.

Vérifiez s'il y a un système de surveillance, et mettez-en un en place s'il n'y en a pas. Nagios et cacti/rrdtool/mrtg me viennent à l'esprit.

Above all, if you see someone starting to take action to change your actual SQL servers (with the exception of measurement) before they have a thorough understanding... well, this is more inexperience than lack of skill, but it would scare me.

Il y aura des douleurs de croissance, tout comme les bagues dentaires sont douloureuses mais elles tirent progressivement les dents dans un alignement correct. L'administrateur devra s'installer et ensuite il y aura quelques ajustements lorsqu'il mettra les choses en place.

Le plus grand signe d'un bon ou mauvais administrateur est la façon dont les changements se produisent. Implique-t-il les utilisateurs dans la discussion sur CE et POURQUOI les choses doivent changer? Y a-t-il une raison pour laquelle il veut exclure certaines personnes d'un système particulier? Comme pour tout dans une entreprise, il faut avoir une raison et un vague "pour des raisons de sécurité" ne suffit pas. Quels sont les risques de laisser les choses telles qu'elles sont? Pourquoi ce que lui/elle veut faire est-il mieux?

Si les utilisateurs se sentent impliqués dans le processus, et ont la possibilité d'expliquer pourquoi les choses sont telles qu'elles sont et peuvent explorer les alternatives, ils seront beaucoup plus enclins à aider et peuvent offrir des perspectives sur les raisons historiques des choses étranges dans le système. Je consulte souvent certains de nos financiers qui sont dans mon entreprise depuis des décennies sur pourquoi diable quelque chose est configuré de manière si étrange.

En fait, cela s'applique à n'importe quel poste même en dehors de l'informatique.