Existe-t-il des anti-schémas bien connus dans le domaine de l'administration système? [fermé]

Je connais quelques modèles courants qui semblent perturber presque tous les projets à un moment donné de leur cycle de vie:

1. Incapacité à prendre des arrêts
2. Composants tiers bloquant les mises à niveau
3. Environnements non uniformes
4. Manque de surveillance et d'alerte
5. Redondance manquante
6. Manque de capacité
7. Mauvaise gestion du changement
8. Politiques d'accès trop libérales ou strictes
9. Les changements organisationnels brouillent la propriété des infrastructures

J'espérais qu'il existe une bibliothèque bien articulée de ces anti-modèles résumée dans un livre ou un site Web. Je suis presque certain que de nombreuses organisations apprennent par des méthodes d'essai par le feu. Sinon, commençons-en un.

Laisser des tâches automatisables à automatiser jusqu'à ce qu'elles soient effectuées manuellement prend suffisamment de temps pour ne pas pouvoir être automatisé, car l'exécution manuelle des tâches consomme tout le temps.

Inversement, automatisation prématurée. Il n'est absolument pas nécessaire de passer 3N heures à automatiser une tâche en une seule fois qui prend N heures à faire manuellement (même si c'est plus amusant d'automatiser que de parcourir les choses à la main).

A. ne teste pas la restauration - une sauvegarde peut être vérifiée et ok, mais comment restaurer?

Combien de temps cela prend, ce qu'il faut? Il faut savoir le faire en situation de stress ...

B. pas de gestion de configuration, pas d'uniformité - juste un changement ici et là et je pense que j'en ai réglé quelques-uns ici ...

Qui sait comment répliquer un serveur bien fait si toutes les bizarreries ne sont pas écrites et qu'il n'y a pas de configurations identiques dans la boutique? Et si vous réussissez à restaurer des données, mais pas la configuration, des applications?

C. pas de surveillance - sans savoir comment et quelles boîtes font

Ceci est double: a) vous devez surveiller les alarmes pour réagir à temps avant de manquer de ressources ou de comportements étranges et b) vous devez surveiller la tendance à long terme pour gérer la capacité (disque, CPU, RAM, réseau, etc.). ..).

D. pas de redondance dans votre cfg - que se passe-t-il lorsque XX meurt

Cela signifie planifier à l'avance ce que vous voulez de votre administrateur système.

Pour moi, ce sont les plus importants.

Le schéma le plus meurtrier est lorsque le service d'administration système (ou l'ensemble de l'informatique) devient un participant passif de l'entreprise. Autrement dit, ils sont considérés comme un libre-service où tout le monde vient avec des idées déjà formées sur la façon de faire les choses, qui prend exclusivement en compte les besoins des utilisateurs et non les besoins de l'écosystème informatique complet dans son ensemble.

Le deuxième modèle le plus destructeur est lorsque le département d'administration système se transforme en un groupe de boutons poussoirs, c'est-à-dire que tous les logiciels / outils sont achetés ou développés et installés par des tiers et que l'administration système reçoit une formation officielle et un manuel, puis ne suit que les manuels d'utilisation et transmettre au fournisseur tout ce qui n'est pas explicitement dans le manuel. Cette situation peut être très confortable pour (certains sinon la plupart) des administrateurs système, mais il s'agit d'un désastre qui attend de se produire lorsque le fait que personne ne sache vraiment comment fonctionne l'ensemble du système l'amènera au sol (pensez à des interactions subtiles entre les composants et le jeu du blâme entre les vendeurs).

1) trop prometteur et sous-performant (c.-à-d. Garder les attentes des utilisateurs réalistes)

2) Ne vérifie pas les sauvegardes avant qu'elles ne soient nécessaires.

edit: je voulais que le numéro 2 inclue la restauration des fichiers / données

Ne surveille pas les modèles d'utilisation du compte AD comme la dernière connexion> 30 jours

(Nous devons le faire pour des raisons d'audit, mais les résultats sont assez choquants)

• Conserver les informations clés dans le dossier tête / boîte de réception / documents d'une personne. Si c'est important, comme les coordonnées du fournisseur, les clés de licence, les instructions de configuration, il doit être disponible pour tous les membres du service qui ont le pouvoir et peuvent avoir besoin d'y accéder, et dans un endroit standard.

• Demander à la personne qui connaît quelque chose de le documenter. Cela sonne bien parce que c'est la personne qui a les connaissances, mais c'est en fait mauvais parce qu'ils ne peuvent pas facilement dire quelles sont les connaissances importantes. Mieux vaut avoir une nouvelle entente avec quelqu'un, en demandant à la personne bien informée toutes les informations dont elle a besoin et en la faisant documenter au fur et à mesure.

• Documentation peu claire. Tout le monde peut résoudre un problème de priorité moyenne pendant la journée avec l'ensemble du service informatique disponible pour parler. C'est une autre question de résoudre un problème hautement prioritaire tard dans la nuit lorsque vous êtes presque seul et que vous ne savez pas pourquoi le système est configuré comme il est ou pourquoi il ne correspond pas à ce que dit la documentation.

• Ne suit pas bien les mots de passe. Vous avez donc rapidement besoin d'un compte, créez-en un avec un mot de passe aléatoire, puis 18 mois plus tard, il est toujours utilisé et personne ne connaît le mot de passe ou les services qui se briseront s'il est modifié.

• Ne pas acheter le support des fournisseurs pour les systèmes clés car c'est "trop ​​cher".

• Priorités inappropriées. Les informaticiens doivent être guidés par la direction - un accord sur les projets prioritaires ou, en cas d'urgence, sur les systèmes requis doit être en place. Si le service informatique essaie de réparer le système d'entreprise, la direction exige des e-mails et les utilisateurs exigent le traitement des commandes, c'est une recette pour le bordel.

• Solutions inappropriées - il est très facile pour l'informatique de rester coincé dans la mentalité de "pour le réparer, le système informatique doit fonctionner comme il était auparavant", quand il peut être plus approprié d'avoir un accord de gestion et informatique pour "essayer pour 2" heures, si ce n'est pas résolu, arrêtez même si cela semble prometteur et passez à la récupération à partir d'une sauvegarde. "

• Des copies des fichiers de test partout. Vous ne voulez pas ouvrir un dossier qui exécute un système d'entreprise ou un site Web et voir "site Web nouveau /, site Web actuel /, site Web copie /, site Web de test /, site Web de test-dave /, site Web d'utilisation - this-one /, website-from-feb /, etc.) Le développement, la production et les tests devraient exister et devraient être séparés avec chaque département impliqué (informatique, développement, gestion de projet, etc.) sachant ce qui devrait être où et convenu de la façon dont les changements sont également approuvés pour les fichiers de configuration.

• Modifiez l'approbation - même si vous avez d'abord une discussion verbale, ne changez pas la façon dont les choses importantes fonctionnent sans que personne d'autre ne le sache. A vous de décider de ce qui est "important" pour votre situation.

• Des solutions solides laissées en place à long terme. Je sais que vous avez patché ce serveur sur ce réseau avec un vieux fil téléphonique très rapidement afin que vous puissiez résoudre un problème urgent. Je sais que vous n'avez pas le temps de le refaire correctement. Prenez le temps.

• Mauvaises relations avec le reste de l'entreprise. L'informatique est un service qui aide le reste de l'entreprise à faire son travail. S'ils ont besoin d'énormes fichiers rapidement, faites-le. Si vous avez besoin de l'approbation de la direction pour acheter du matériel, procurez-vous-le. Si vous ne pouvez pas l'obtenir, communiquez clairement que les fichiers volumineux ne peuvent pas bouger rapidement car la direction a priorisé certaines autres dépenses. Si vous avez besoin d'archivage pour des raisons juridiques mais que vous n'avez pas de budget, vous devez adapter l'archivage à votre système du mieux que vous le pouvez.