Question Qu'est-ce que l'administrateur système doit savoir sur les problèmes d'administration système?


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?


96


origine




Réponses:


Je commencerais par:

  1. Toujours avoir un système de sauvegarde de quelque sorte. Encore mieux si cela a une histoire.
  2. Considérez les points d’échec uniques et la façon de les gérer en cas d’échec.
  3. En fonction de la quantité d'ordinateurs impliqués, rechercher un moyen de créer et de créer une image standard sur plusieurs ordinateurs facilitera la vie de tout le monde - non, "cela fonctionne sur la mienne" car ils ont tel ou tel programme normalement installé.
  4. Documentez tout, ne serait-ce que parce que vous volonté oubliez comment vous organisez quelque chose.
  5. Restez au courant des mises à jour de sécurité.

70



la documentation de toutes les étapes est quelque chose que j'ai vu de bons administrateurs système faire, et j'ai commencé à le faire moi-même. Très utile, en effet. - Nathan DeWitt
Envisagez des systèmes auto-documentants. Par exemple, pourquoi conserver une liste de noms d'hôtes dans un fichier texte ou un wiki quelque part lorsqu'un fichier Zone bien commenté est la source canonique d'informations. - Dave Cheney
Dave, ce fichier Zone bien commenté est-il accessible à tous? Si je suis une nouvelle personne arrivant à bord, n'est-il pas plus facile de se faire dire "allez sur ce wiki pour toutes vos réponses" plutôt que "tout est documenté partout. DNS est documenté dans les paramètres DNS. Le whozit est documenté dans le whozit fichier de configuration. La base de données est documentée dans le fichier de configuration de la base de données. " Cela me semble très ... hostile. - Nathan DeWitt
Nathan, Dave: L'astuce consiste bien sûr à utiliser un script pour mettre à jour le wiki à partir de la source canonique. Cela a fonctionné à merveille pour moi, je suis vraiment désolé de ne pas pouvoir l'utiliser là où je travaille maintenant. - Anders Eurenius
J'ajouterais à cela: Construisez un système de test. Vous avez besoin d'un environnement où l'échec est une option. J'ai un serveur exécutant VirtualBox pour cela, mais j'ai utilisé mon poste de travail personnel lorsque les serveurs ne sont pas disponibles. - Mark Porter


<insérez ici le grand disclaimer>

Certaines 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), les détails relatifs au fournisseur / à la maintenance, aux exigences du réseau, comment et où trouver du matériel de remplacement - tout ce à quoi vous pouvez penser contribuera à la sauvegarde du système.

Automatisation:

  • Automatisez autant que vous le pouvez. Si vous devez faire quelque chose trois fois, assurez-vous que la seconde est passée à développer votre automatisation pour que la troisième soit entièrement automatisée. Si vous ne pouvez pas l'automatiser, documentez-le. Il existe des suites d'automatisation sur le marché - voyez si vous pouvez les faire fonctionner pour vous.

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 transférer dans le 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, le 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'il n'en existe pas de nouveaux.

  • N'essayez pas de nettoyer un serveur compromis. il doit être reconstruit à partir de zéro. Reconstruisez sur un serveur de secours 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 autour de cela, 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 écrire après la fermeture du projet et le passage de la maintenance du système à la maintenance. Assurez-vous donc que cela est 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, selon la durée la plus courte. 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. En revisitant l’environnement à 2 ans et demi, vous disposez de suffisamment de temps pour parcourir les étapes de gestion et de financement nécessaires à la commande d’un nouveau kit et pour mettre en œuvre une migration en douceur avant d’envoyer l’ancien kit au plus gros vendeur du ciel.

Développement:

  • Assurez-vous que vos systèmes de développement et de transfert ressemblent à ceux de la production. Les machines virtuelles ou autres techniques de virtualisation (zones, LDOM, vservers) facilitent la création de clones de production du monde réel dans tous les sens du terme, mais sans performances.

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.


44



+1 C'est comme si quelqu'un m'avait regardé dans la tête - et c'était magnifique; p - Oskar Duveborn
"Testez, analysez et collectez des métriques sur tout ce qui est sain d'esprit. Les benchmarks vous indiquent quand il faut s'attendre à ce que quelque chose laisse échapper de la fumée magique. Le suivi vous indique quand il en est ainsi. Les métriques et les statistiques facilitent l'obtention d'un nouveau kit fumée) par le biais de la direction. "  Or pur - T.J. Crowder


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.


43



+1 pour cela. Ce n'est pas parce qu'on le fait Regardez facile que c'est réellement. - Gert M
En tant que généraliste travaillant à la fois comme administrateur et comme programmeur, je comprends parfaitement votre situation. +1 - Avery Payne
Bien entendu, j'ai trouvé quelques types d'administrateurs système qui ne comprennent vraiment pas la différence entre les types de scripts et les petits programmes utilitaires que nous pouvons tous bricoler et la programmation "réelle". - Rob Moir
+1 Robert: Ou l'administrateur système disant "c'est une simple déclaration if" pour contourner une architecture réseau mal conçue. Le respect mutuel et la compréhension est la clé. - Steven Evers


  • Réalisez que, pour le meilleur ou pour le pire, de nombreux serveurs et / ou équipements de réseau auxquels ils ont tendance ressemblent beaucoup à des enfants d'une deuxième famille. Ce sont leurs bébés.  Ils les soignent, les aident quand ils sont malades et les surveillent avec vigilance pour détecter les problèmes. Ce ne devrait pas être de cette façon, mais après de nombreuses années, c'est souvent. Gardez cela à l’esprit lorsque vous leur faites part de vos préoccupations au sujet du mauvais fonctionnement ou des attentes de l’équipement. Et si vous obtenez une réponse que vous ne comprenez pas, essayez de la filtrer à travers cette vue du monde.
  • Soyez en bons termes de travail. Ça sonne bien, mais ça vaut son pesant d'or. Un jour, vous aurez besoin d'une faveur spéciale. Et un jour, cet administrateur système se fera un plaisir de tout mettre en œuvre pour vous rendre la vie un peu plus facile, ne serait-ce qu'une fois.
  • Cette relation de travail va dans les deux sens. Si l'administrateur système est très occupé et que vous pourriez rendre la vie un peu plus facile en écrivant un petit script ou programme, faites-le! Ils l'apprécieront plus que vous ne le savez.
  • Soyez très clair. "Ça craint" n'est pas aussi clair que "avoir une connexion réseau intermittente est un peu gênant, y a-t-il une chance que vous puissiez la regarder?"
  • Si vous pensez que votre application va évoluer, demandez à l'administrateur avant en supposant ce sera. Ils peuvent «voir» quelque chose que vous ne voyez pas ou connaître les limites de performances de l'équipement sur lequel vous allez déployer.
  • Si votre application a besoin d'être optimisée, mais que cela ne semble pas être un problème de code, posez des questions sur le fonctionnement des serveurs. Les administrateurs système soignent leurs machines avec amour et ne sont pas contents quand ils sont "malades" ou "mal conduits". En posant bien, vous retournerez une machine en difficulté (ou vous la ferez réparer / remplacer).
  • (comme mentionné ailleurs) documentez les paramètres que vous utilisez, et Pourquoi vous les utilisez. Le simple fait de "définir la case à cocher X" ou de "supprimer la mise en commentaire de la ligne de fichier de configuration Y" n'aide pas. Vous pourriez définir l'option qui efface toutes vos données lors du prochain redémarrage pour tout ce que vous savez.
  • Si vous n'avez pas le temps de documenter le réglage sur papier, essayez de le documenter dans le système, si possible. Avec les fichiers de configuration, cela devrait presque être une pratique courante - chaque changement de paramètre doit être horodaté, avec les initiales, l’effet escompté de ce paramètre et la raison Pourquoi il a été changé (voir point précédent). Cette petite habitude a sauvé mon bacon plus d'une fois pendant la période de crise. "Pourquoi avons-nous fait ça?" "Parce que nous avons mandaté la stratégie X et que la configuration Y nous donne le comportement nécessaire pour la stratégie X".
  • Bière. Ou cola. Ou même de l'eau. Les boissons sont toujours les bienvenues. Être administrateur est un travail soif.

27



Pour le problème de documentation / modification du fichier de configuration, je vous recommande de placer tous les fichiers de configuration dans un système de contrôle de version. Cela devrait être très facile à faire pour les programmeurs, car ils utilisent déjà, espérons-le, un tel système pour leur code source. S'ils ajoutent également un commentaire chaque fois qu'ils commettent un changement, il sera facile de revenir en arrière dans l'historique et de voir ce qui a été changé quand et pourquoi. - Anders Sandvig
+1 pour cela, car il "ferme la boucle" sur la gestion des modifications. Grande suggestion. - Avery Payne
Excellente suggestion pour donner des rapports d'erreur clairs. Rien ne me frustre davantage qu'après avoir été informé qu'il y avait un problème et, sachant qu'il pourrait potentiellement toucher un grand nombre de personnes, je dois donner des détails à un programmeur désintéressé. - Dave Cheney


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.


23





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".

  • Wireshark, pour regarder votre code fonctionner en mode boîte noire, paquet par paquet
  • Outils pour se connecter directement aux services réseau:
    • Telnet, netcat ou socat pour les connexions simples via TCP ou UDP
    • OpenSSL pour la même chose avec le cryptage (indice: essayez openssl s_client -connect target-host:port parfois), pour se connecter manuellement aux services réseau
  • dig (dans le package BIND 9) pour le débogage de la résolution de noms
  • Être capable de dire quelle partie de la pile réseau a échoué en fonction du minutage et d'autres caractéristiques d'une connexion défaillante
  • Peut-être HTTPFox et / ou Firebug

17



+1 Tout développeur écrivant une application dépendant de performances réseau solides devrait lire «TCP / IP Illustrated v1», écrit par le regretté W. Richard Stevens, avant de commencer à coder. - Murali Suriar
Merci pour tous les gars upvotes. Pendant des années, j'ai été bouleversé de voir les programmeurs bouleversés lorsque le réseau sous-jacent échoue. Et ces jours-ci, presque toute la programmation est en réseau. - jhs


Savoir comment résoudre les problèmes.

Il est très facile de renvoyer la balle (par exemple, votre réseau met en place 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 devient une personne heureuse. Parce que, si rien d'autre, vous pourriez être en mesure de les orienter dans une direction spécifique quant à ce qui pourrait être faux (au lieu de dire "votre réseau est nul" ou quelque chose d'aussi utile.)


14



Absolument. Je ne peux pas commencer à compter les heures que j'ai passées à chercher des problèmes aux mauvais endroits à cause des gens qui me dirigeaient vers faux direction - Gert M