L’intervenant négligé a.k.a, l’administrateur système

Question

Il y a quelque temps, j'ai réalisé que presque tous les projets clients sur lesquels j'ai travaillé jusqu'ici ont négligé un groupe important de parties prenantes: les administrateurs système.

Ces héros silencieux ne sont généralement impliqués qu'à la fin d'un projet et se retrouvent avec une boîte noire exécutable de bits qu'ils doivent installer, prendre en charge et entretenir pour les années à venir. Chaque fois qu'un problème survient avec cette boîte noire, ils doivent trouver un moyen de le résoudre en utilisant n'importe quel élément d'information aléatoire et le support d'outils mis à leur disposition par la boîte noire ou la plate-forme sous-jacente. Si cela ne suffit pas, ils doivent improviser .

S'ils avaient été impliqués dès le début en tant que parties prenantes dans le projet, ils auraient eu l'occasion de prédire les problèmes potentiels et d'en informer l'équipe du projet. Mais la réalité est différente et même si, en tant que développeur, j'aimerais impliquer l'administrateur système en tant que partie prenante supplémentaire, des facteurs externes peuvent empêcher cela.

Dans ces situations, je voudrais aider nos héros silencieux du mieux que je peux. Donc ma question est:

Qu'est-ce qu'un administrateur système souhaiterait de nous, développeurs, lorsque nous développons les systèmes qu'ils devront gérer?

Si vous êtes administrateur système , racontez une histoire de guerre à propos d'un problème difficile que vous avez rencontré auparavant et de ce que les développeurs auraient pu faire pour vous faciliter la tâche.

Answer 1

Diverses choses, y compris (mais il est peu probable qu'elles se limitent à) celles-ci, qui ne sont pas classées par ordre de priorité:

• Aucune obligation d'utiliser l'installation privilégiée
• Option d'utilisation de l'installation privilégiée
• Option d'installation distribuée (vous pouvez donc l'installer sur un serveur et l'utiliser sur d'autres ordinateurs)
• Nettoyer la désinstallation
• Modèles de mise à niveau sensibles
• Option permettant de choisir l'emplacement d'installation
• Dépendances minimales sur d'autres logiciels
• Dispersion minimale des données dans le système (ne pas vider de contenu dans / etc, / usr / lib, / var / adm, ...)
• Pas de bûches en croissance constante
• Installation silencieuse
• Installation par script
• Documentation en ligne (sur la machine et sur Internet)
• Pages de manuel peut-être
• Facile à configurer
• Facile à rendre accessible aux utilisateurs finaux
• Aucun risque de sécurité
• Pas d'utilisateurs ou de groupes spéciaux (ou nombre limité - au plus un utilisateur spécial, un groupe spécial est une cible, bien que ce ne soit pas toujours réalisable)
• Absence de fonctionnalité "Phone Home" ou uniquement si elle est explicitement configurée (ne doit pas être la valeur par défaut)
• Bonne journalisation des diagnostics en cas de problème
• Bon support technique disponible en cas de problème
• Aucune exigence d'obtenir un code d'activation lors de l'installation
• Aucune exigence de redémarrer la machine après une installation
• Possibilité d'exécuter en parallèle les anciennes et les nouvelles versions

Tout dépend du logiciel utilisé et de son utilisation. La configuration requise pour un programme graphique fonctionnant sous Windows, Linux et MacOS X est radicalement différente de celle requise pour un démon réseau. Toutefois, l'objectif doit toujours être un logiciel stable, fiable et facile à gérer.

N'oubliez pas qu'il existe de grandes différences entre les logiciels préparés par un service interne pour une utilisation au sein d'une entreprise et ceux conçus pour être utilisés par des clients externes à l'entreprise qui les développe.

Answer 2

Lorsqu'un problème survient inévitablement, faites attention à ce que dit l'administrateur système et croyez-le. Ne la négligez pas si elle ne correspond pas à votre évaluation initiale.

Récit de guerre: Il y a environ 6 ans, j'étais administrateur système pour une petite entreprise de fabrication. Ils ont décidé d'acheter un logiciel pour gérer la planification de la maintenance préventive de leurs équipements. L'une de ses fonctionnalités importait des demandes de maintenance depuis un courrier électronique, mais nous avions parfois des problèmes d'erreurs de communication avec le serveur de messagerie au cours de ce processus. J'ai ensuite été appelé pour l'examiner lors d'un appel téléphonique avec le développeur. La conversation a impliqué plusieurs itérations de

  

Développeur: je n'ai jamais entendu parler de personne   avoir ce genre de difficulté à parler à   le serveur de messagerie. Ça doit être un   problème de pare-feu.

     

Moi: je suis connecté au pare-feu,   exécuter un renifleur de paquets et regarder   le trafic de votre application passe sans aucune   problèmes. Il passe très bien à travers le pare-feu.

     

Développeur: Non, non - cela doit être un   problème de pare-feu.

(Finalement, il s’est avéré que le problème était que l’application ouvrait une connexion POP3, lisait tout le courrier, attendait que l’utilisateur planifie les tâches, puis envoyait une commande POP pour supprimer le courrier une fois que toutes les demandes avaient été envoyées. Si la planification de la planification demandait plus de 15 minutes à l'utilisateur, la connexion POP expirait et l'application n'était pas en mesure de récupérer, elle est donc morte. Ensuite, l'utilisateur devait répéter la planification, ce qui signifierait probablement prenez le temps nécessaire pour faire une pause ...)

Answer 3

Je pense une combinaison des éléments suivants:

1) Seuil de capacité - > Quelles machines faut-il pour exécuter ce logiciel et quelles mesures doivent être utilisées pour déterminer quand ce nombre peut changer, par exemple passer de 2 à 3 serveurs de base de données ou de 10 à 15 serveurs Web. À quel point le matériel doit-il être costaud et une partie importe-t-elle plus qu'une autre, par ex. le processeur importe-t-il plus que la mémoire vive, qu'en est-il de la configuration et de l'espace du disque dur?

2) Dépannage lié au style de livre de recettes - > Si quelque chose ne va pas, cela peut facilement être classé en code, données ou erreur réseau.

3) Schéma des environnements - > À quoi ressemblent les instances de développement, de test et de production de ce logiciel? Existe-t-il des environnements en cours actuellement?

4) Maintenance - > Existe-t-il des fichiers journaux à analyser dans des rapports, des journaux d’erreur hebdomadaires à envoyer, ou un type de maintenance à faire avec le logiciel, par exemple, redémarrez le serveur chaque semaine.

5) Sécurité - > Faut-il créer et gérer des comptes et une politique de sécurité précisant qui a quel niveau d’autorité sur le système?

Ce sont les principaux qui me viennent à l’esprit.

Answer 4

Les administrateurs système souhaitent généralement ce qui suit:

• Transparence dans le fonctionnement du système. Donc, une sorte d’interface graphique qui affiche les paramètres du système et peut-être un historique des problèmes rencontrés, ainsi que des listes de ce que le système a traité correctement.
• Un chemin d'escalade clair et contextuel pour les problèmes. J'entends par là que chaque type de problème comporte des remarques sur la résolution, ainsi qu'une personne ou une équipe qui peut être contactée si le problème ne peut pas être résolu rapidement et qu'une escalade est requise.
• Pour être proactif, c’est-à-dire pouvoir informer les utilisateurs finaux d’un problème système avant qu’un utilisateur final ne l’informe. Donc, une sorte d'alerte immédiate pour tout problème système où c'est faisable,
• Ne pas être inondé d'alertes. Donc, une fois qu'une alerte est arrivée, plus aucune alerte pour le même problème; juste un autre message lorsque le système est à nouveau opérationnel.
• Journalisation détaillée à l'aide de quelque chose comme le journal des événements (sous Windows) pour une analyse plus approfondie du problème.

Answer 5

Que le système fonctionne pour qu'il puisse rentrer chez lui avec ses enfants.

Answer 6

Dépendances bien documentées fournies avec le logiciel, si vos expériences d’administrateur local me manquent.

Answer 7

Eh bien, il s’agit plus d’une horreur que d’une histoire de guerre: maintenir une application qui, sans raison apparente, exige d’être exécutée sous un compte utilisateur administrateur.

Il serait bon d'avoir quelques éléments aléatoires dans une application:

• Arguments de ligne de commande significatifs
• Une sorte de fonctionnalité de script (le cas échéant)
• Tout type d'indicateur de progression pour les opérations de longue durée
• Erreur de journalisation
• Interface utilisateur cohérente

Answer 8

Maintenance facile des packages!

L’installation et la mise à jour du logiciel devraient être simples comme bonjour, et cela aussi pour les dépendances. S'il existe de nombreuses dépendances et sous-dépendances, et que vous n'êtes pas enclin à maîtriser les nuances de la méthodologie de gestion des packages de chaque système d'exploitation, il serait intéressant de proposer une version du package avec toutes les dépendances requises regroupées dans une archive obsolète. . Exécutez le script, transférez le tout dans / usr / local / yourproject et dites-leur où se trouve le script de démarrage / arrêt / redémarrage.

Answer 9

Chaque projet possède une "planification de la capacité" avec son architecture système. Les administrateurs système doivent être impliqués dans le processus de planification de la capacité ainsi que dans la révision finale de l'architecture système. Cela l'aidera à mieux comprendre le système et à se préparer au déploiement et à l'assistance.