En tant que programmeur, nous avons tendance à prendre les administrateurs système pour acquis. Les quelques fois où je me suis trouvé sans un bon administrateur système m'ont vraiment fait apprécier ce que vous faites. Lorsque nous nous aventurons dans un environnement sans administrateur système, quels mots de sagesse pouvez-vous nous dire?
Réponses:
Je commencerais par:
<insérez ici le grand disclaimer>
Certaines d'entre elles ont déjà été dites, mais il convient de les répéter.
Documentation:
Tout documenter. Si vous n'en avez pas, installez un wiki sous le radar, mais assurez-vous de le sauvegarder. Commencez par recueillir des faits et un jour, une vue d'ensemble se formera.
Créez des diagrammes pour chaque bloc logique et maintenez-les à jour. Je ne pouvais pas compter le nombre de fois où une carte réseau précise ou un diagramme de grappes m'a sauvé.
Conservez les journaux de construction de chaque système, même s'il ne s'agit que de copier-coller des commandes expliquant comment le construire.
Lors de la construction de votre système, installez et configurez vos applications, testez-le et effectuez votre analyse comparative. Maintenant, essuyez les disques. Sérieusement. 'dd' le premier mégaoctet à l'avant des disques ou rend la boîte non amorçable. Le temps presse: prouvez que votre documentation est capable de la reconstruire à partir de zéro (ou, mieux encore, que votre collègue ne peut rien faire de plus que votre documentation). Cela constituera la moitié de votre plan de reprise après sinistre.
Maintenant que vous avez la première moitié de votre plan de récupération après sinistre, documentez le reste; comment récupérer l'état de votre application (restaurer des fichiers sur une bande, recharger des bases de données à partir de sauvegardes), informations sur le fournisseur / le support technique, la configuration réseau requise, comment et où trouver du matériel de remplacement - tout ce à quoi vous pouvez penser contribuera à la sauvegarde du système.
Automatisation:
Surveillance:
L'instrumentation d'application est en or pur. Le fait de pouvoir surveiller les transactions transitant par le système facilite beaucoup le débogage et le dépannage.
Créez des tests de bout en bout qui prouvent non seulement que l’application est active, mais qu’elle fait ce qu’elle est censée faire. Les points vous appartiennent si vous pouvez les connecter au système de surveillance à des fins d'alerte. Cela sert un double devoir; En plus de prouver que l'application fonctionne, cela facilite considérablement les mises à niveau du système (surveillance des rapports du système en vert, mise à niveau travaillée, temps de rentrer à la maison).
Analysez, analysez et collectez des métriques sur tout ce qui est sain pour le faire. Les repères vous indiquent quand il faut s'attendre à quelque chose qui laissera sortir la fumée magique. La surveillance vous indique quand cela se produit. Les statistiques et les statistiques facilitent l'obtention d'un nouveau kit (avec de la fumée magique fraîche) par le biais de la direction.
Si vous n'avez pas de système de surveillance, implémentez-en un. Des points bonus si vous réalisez les tests de bout en bout ci-dessus.
Sécurité:
"chmod 777" (c'est-à-dire accorder tous les accès / privilèges) n'est jamais la solution.
Abonnez-vous au principe du «moindre bit»; s'il n'est pas installé, copié ou autrement installé sur le disque, il ne peut pas être compromis. Les éviers de cuisine et les logiciels installés peuvent rendre la vie plus facile pendant la phase de construction, mais vous finissez par en payer le prix par la suite.
Sachez à quoi sert chaque port ouvert sur un serveur. Auditez-les fréquemment pour vous assurer qu'aucun nouveau n'apparaît.
N'essayez pas de nettoyer un serveur compromis. il doit être reconstruit à partir de zéro. Reconstruisez sur un serveur disponible avec un support fraîchement téléchargé, en ne restaurant que les données des sauvegardes (car les fichiers binaires peuvent être compromis) ou clonez l'hôte compromis dans un emplacement isolé pour analyse afin que vous puissiez reconstruire sur le même kit. Il y a tout un cauchemar juridique à ce sujet, alors privilégiez la préservation au cas où vous auriez besoin de poursuivre en justice. (Note: IANAL).
Matériel:
Ne présumez jamais que quelque chose fera ce qui est écrit sur la boîte. Prouvez que cela fait ce dont vous avez besoin, au cas où ce ne serait pas le cas. Vous constaterez que cela «fonctionne presque» plus souvent que prévu.
Ne lésinez pas sur la gestion matérielle à distance. La gestion des consoles série et des lumières éteintes devrait être considérée comme obligatoire. Points bonus pour les barrettes d'alimentation télécommandées pour les moments où vous êtes à court d'options.
(A part: il y a deux façons de régler un problème à 3h du matin, l’un implique d’être chaud, de travailler sur un ordinateur portable via un VPN en pyjama, l’autre implique une veste épaisse et un lecteur pour le centre de données / bureau. Je sais lequel préférer.)
Gestion de projet:
Impliquez les personnes qui assureront la maintenance du système dès le premier jour du cycle de vie du projet. Les délais de livraison du kit et du temps passé par le cerveau peuvent et vont surprendre, et il ne fait aucun doute qu'ils auront (devrait?) Des normes ou des exigences qui deviendront des dépendances du projet.
La documentation fait partie du projet. Vous n'aurez jamais le temps de tout rédiger après la fermeture du projet et le passage à la maintenance du système. Veillez donc à ce que cela soit inclus dans le planning au début.
Mettez en œuvre l'obsolescence planifiée dans le projet dès le premier jour et démarrez le cycle d'actualisation six mois avant le jour d'extinction spécifié dans la documentation du projet.
Les serveurs ont une durée de vie définie lorsqu'ils conviennent à une utilisation en production. La fin de cette durée de vie est généralement définie comme étant chaque fois que le fournisseur commence à facturer plus d’entretien annuel qu’il en coûterait pour actualiser le kit, ou environ trois ans, la durée la plus courte étant retenue. Après cette période, ils sont parfaits pour les environnements de développement / test, mais vous ne devez pas compter sur eux pour gérer l'entreprise. Revisiter l'environnement à 2 ans et demi vous laisse amplement le temps de parcourir les étapes de gestion et de financement nécessaires à la commande d'un nouveau kit et de mettre en œuvre une migration en douceur avant d'envoyer le kit au grand vendeur dans le ciel.
Développement:
Des sauvegardes
Les données que vous ne sauvegardez pas sont des données que vous ne voulez pas. C'est une loi immuable. Assurez-vous que votre réalité correspond à cela.
Les sauvegardes sont plus difficiles qu'elles ne le paraissent; certains fichiers seront ouverts ou verrouillés, tandis que d'autres doivent être suspendus pour laisser un espoir de récupération, et tous ces problèmes doivent être résolus. Certains packages de sauvegarde ont des agents ou d'autres méthodes pour traiter les fichiers ouverts / verrouillés, d'autres non. Déposer des bases de données sur disque et les sauvegarder est considéré comme une forme de "mise au repos", mais ce n'est pas la seule méthode.
Les sauvegardes ne valent rien à moins d'être testées. Tous les quelques mois, extrayez une bande au hasard des archives, assurez-vous qu'elle contient bien des données et qu'elles sont cohérentes.
Et, surtout...
Choisissez vos modes d'échec, ou Murphy le fera ... et Murphy ne travaillera pas avec votre emploi du temps.
Concevoir en cas d'échec, documenter les points faibles conçus de chaque système, ce qui les déclenche et comment les récupérer. Cela fera toute la différence quand quelque chose ne va pas.
Ne présumez pas que c'est facile. Je connais beaucoup de programmeurs qui pensent que, juste parce qu'ils peuvent configurer IIS ou Apache sur leur boîte de dev, ils peuvent gérer une ferme Web. Comprenez en quoi consiste le travail et faites vos recherches et votre planification. Ne vous contentez pas de penser que le travail de l'administrateur système est une chose facile à faire en 10 minutes pour le déploiement de votre application.
La sécurité n'est pas une réflexion après coup. Alors qu'une application piratée peut rendre le programmeur incompétent, c'est (au moins) un week-end perdu passé à vérifier, nettoyer et / ou restaurer des sauvegardes pour un administrateur système.
Par ailleurs, ne considérez pas les sauvegardes comme un contrôle de version. Ils sont destinés à la récupération après sinistre et ne sont pas vraiment conçus pour restaurer votre code car vous avez oublié ce que vous avez modifié.
Et arrêtez de blâmer aveuglément les mises à jour Windows pour la rupture de votre code. Je me fiche de savoir que cela a bien fonctionné, dites-moi pourquoi cela ne fonctionne pas maintenant - alors nous pouvons voir à qui la faute.
Comment déboguer des problèmes de réseau et regarder votre programme s'exécuter avec les outils sysadmin. En tant que programmeur ayant débuté dans l'administration système, je suis émerveillé par l'impuissance de nombreux programmeurs lorsque la mise en réseau "s'arrête".
openssl s_client -connect target-host:porttemps en temps), pour se connecter manuellement aux services réseauSavoir comment résoudre les problèmes.
Il est très facile de renvoyer la balle (par exemple, votre réseau bloque ma communication avec la base de données). C'est peut-être la faute du réseau, mais vous devriez avoir des journaux d'application avec des erreurs qui, à l'aide de Google ou de SO, peuvent révéler un problème dans la configuration d'une application.
Tout le monde aime blâmer le matériel, le système d'exploitation ou le réseau. Par conséquent, si vous pratiquez un peu plus de diligence raisonnable, l'administrateur système est une personne heureuse. Parce que, si rien d’autre, vous pourriez être en mesure de leur indiquer ce qui pourrait ne pas être correct (au lieu de dire «votre réseau est nul» ou quelque chose d’aussi utile).
Documentez tout ce que vous pouvez. Je ne peux pas vous dire combien de fois le dernier administrateur système a pensé qu'il serait mignon de ne pas documenter quelque chose pour la "sécurité de l'emploi" ou que quelqu'un veuille simplement entrer et sortir. Tout comme un programmeur devrait laisser de bons commentaires, les administrateurs système devraient documenter. Un diagramme de la topologie serait bien aussi.
Documentation: inutile de fou, mais comment fonctionne l'application, un diagramme illustrant l'adaptation des bits et les moyens de tester chaque composant lorsque tout va mal. Échantillon de données et de sortie, c'est bien.
Conditions requises: sur quels modules s'appuie-t-il? Versions OS?
Surveillance: idéalement, les développeurs incluent des informations de surveillance et des tests avec l’application.
En parlant de packaging, PACKAGING! Rien de pire qu'un "déploiement", qui consiste à extraire une nouvelle révision d'un fichier de VCS et à la copier sur un groupe de serveurs. Trop souvent, les programmeurs n'apprécient pas la complexité du déploiement de logiciels: il existe des raisons pour lesquelles les logiciels versionnés et packagés constituent la colonne vertébrale de la plupart des systèmes d'exploitation.
Si un développeur m'arrivait avec un RPM installé pour la première fois avec une documentation complète et concise et des tests Nagios, il serait mon nouveau meilleur ami.
Je suis surpris de voir qu'aucune des 17 réponses données jusqu'ici n'inclut quoi que ce soit à propos de garantir que votre application s'exécute lorsque vous êtes connecté en tant qu'utilisateur standard.
Outre le processus d'installation, l'application doit fonctionner correctement si vous êtes connecté avec un compte d'utilisateur standard.
Cela peut s’appliquer uniquement aux programmeurs débutants, mais je traite quelques points dans chaque projet avec certains programmeurs.
"Cela fonctionne sur ma machine" n'est pas une déclaration valide. Il incombe au programmeur de créer un programme d’installation à utiliser sur le serveur ou au moins de documenter toutes les connexions, dll et add-in nécessaires sur le serveur.
(J'ai entendu cela plusieurs fois, alors s'il vous plait, ne riez pas.) Je lance l'exécutable sur le serveur depuis ma machine et ça marche. Mais, lorsque je l'exécute sur le serveur (Citrix, Terminal Server, etc.), cela ne fonctionne pas. Veuillez comprendre les dll, les ocx et tout ce dont votre programme a besoin, où et comment il est enregistré, et comment votre programme les utilise.
Celles-ci peuvent sembler simples, mais je les traite constamment.
Brian
OK c'est un peu déclamé mais:
a) Lors du codage, supposons que l’infrastructure sous-jacente puisse échouer et ne provient pas d’atterrissage heureux-heureux. Ou Google.
b) Nous n’avons probablement pas les ressources nécessaires pour mettre en œuvre une infrastructure semblable à celle dont vous avez parlé, alors ne vous gênez pas pour autant. Nous savons probablement ce qu'il faut faire, mais pour une raison quelconque, cela ne s'est pas encore produit. Nous sommes vos partenaires!
c) Comme jhs dit ci-dessus, cela vous aiderait vraiment si vous maîtrisiez bien les outils de dépannage de l’infrastructure, tels que ping, traceroute (ou la combinaison des deux - mtr), fouiller, etc.
d) Si vous programmez un ordinateur, vous devez vraiment savoir comment il se connecte au réseau et connaître les bases, comme pouvoir analyser la sortie de ipconfig / all ou ifconfig. Vous devriez pouvoir obtenir votre connexion Internet opérationnelle avec une aide minimale.
Sinon, je pense qu'Avery a très bien réussi. Les développeurs qui font un peu administrateur système valent leur pesant d'or! Mais également, les administrateurs système qui comprennent comment les développeurs agissent (y compris la gestion des versions, etc.) sont à peu près essentiels à notre époque.
Cela semble être dans l'air pour le moment, j'ai remarqué plus de discussions sur la relation dev / ops dans les blogs - consultez
Qu'aucun groupe ou fonction ne soit «meilleur» qu'un autre et qu'aucun n'exige un «cerveau plus grand» l'un que l'autre. J'ai vu les deux parties se faire toutes prima-donaish dans l'entreprise de l'autre - vous essayez toutes d'atteindre les mêmes objectifs - concentrez-vous sur ces similitudes et non sur le fait que vous utilisez des outils différents.
Architecte d'infrastructure devenu programmeur, vous voudrez peut-être annuler cette transaction ultérieurement :)
En tant qu’administrateur système pour les développeurs, et moi-même développeur, les conseils donnés ici ne sont pas seulement de l’or, mais doivent faire partie de la documentation d’embauche de nouveaux développeurs pour les entreprises du monde entier.
Ce que je n’ai pas encore vu, c’est que les développeurs doivent vraiment connaître les produits qu’ils utiliseront pour créer les programmes pour lesquels ils sont payés. Le nombre de fois où j'ai eu à expliquer et à configurer des serveurs Apache, des installations eclipse et Visual Studio et une base de données sur des machines de développement est un peu inquiétant.