Quelles sont les fonctionnalités d'administrateur système que chaque programmeur doit connaître?
En tant que programmeur, nous avons tendance à tenir les administrateurs système pour acquis. Les quelques fois où j'ai été 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, quelles paroles de sagesse pouvez-vous nous offrir?
Je commencerais par:
- Toujours avoir un système de sauvegarde quelconque. Encore mieux s'il a une histoire.
- Considérez les points de défaillance uniques et la façon de les traiter en cas d'échec.
- Selon la quantité d'ordinateurs impliqués, chercher un moyen de créer et de créer une image standard sur tous les ordinateurs facilitera la vie de chacun - pas de "ça marche sur le mien" car ils ont tel ou tel programme qui n'est pas normalement installé.
- Documentez tout, ne serait-ce que parce que vous allez oublier comment vous avez configuré quelque chose.
- Restez au courant des mises à jour de sécurité.
<insérer le grand avertissement ici>
Certaines d'entre elles ont déjà été dites, mais cela vaut la peine d'être répété.
Documentation:
Documentez tout. Si vous n'en avez pas, installez un wiki sous le radar, mais assurez-vous de le sauvegarder. Commencez par collecter des faits, et un jour, une grande image se formera.
Créez des diagrammes pour chaque bloc logique et tenez-les à jour. Je n'ai pas pu compter le nombre de fois où une carte réseau ou un diagramme de cluster précis m'a sauvé.
Conservez les journaux de construction pour chaque système, même s'il ne s'agit que de copier-coller des commandes pour savoir comment le créer.
Lors de la construction de votre système, installez et configurez vos applications, testez son fonctionnement 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. L'horloge tourne: prouver que votre documentation peut la reconstruire à partir de zéro (ou, mieux encore, prouver que votre collègue ne peut rien de plus que votre documentation). Cela constituera la moitié de votre plan de reprise après sinistre.
Vous avez maintenant la première moitié de votre plan de reprise après sinistre, documentez le reste; comment récupérer l'état de votre application (restaurer des fichiers à partir d'une bande, recharger des bases de données à partir de vidages), les détails du fournisseur/du support, les exigences du réseau, comment et où obtenir du matériel de remplacement - tout ce que vous pouvez penser qui vous aidera à récupérer votre système.
Automatisation:
- Automatisez autant que vous le pouvez. Si vous devez faire quelque chose trois fois, assurez-vous que le second est consacré au développement de votre automatisation afin que le troisième soit entièrement automatisé. Si vous ne pouvez pas l'automatiser, documentez-le. Il existe des suites d'automatisation - voyez si vous pouvez les faire fonctionner pour vous.
Surveillance:
L'instrumentation d'application est en or pur. Être en mesure de regarder les transactions passant par le système facilite le débogage et le dépannage.
Créez des tests de bout en bout qui prouvent non seulement que l'application est vivante, mais fait vraiment ce qu'elle est censée faire. Les points vous appartiennent si vous pouvez les intégrer 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 (le système de surveillance signale vert, la mise à niveau a fonctionné, le temps de rentrer à la maison).
Comparez, surveillez et collectez des mesures sur tout ce qui est sensé pour le faire. Les repères vous indiquent quand vous attendre à ce que quelque chose libère la fumée magique. La surveillance vous indique quand c'est le cas. Les mesures et les statistiques facilitent l'obtention d'un nouveau kit (avec de la fumée magique fraîche) grâce à la gestion.
Si vous n'avez pas de système de surveillance, installez-en un. Des points bonus si vous effectuez des tests de bout en bout ci-dessus.
Sécurité:
"chmod 777" (alias 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 vivant sur le disque, il ne peut pas être compromis. Les installations d'OS et de logiciels "évier de cuisine" peuvent vous faciliter la vie pendant la phase de construction, mais vous finissez par payer pour cela.
Sachez à quoi sert chaque port ouvert sur un serveur. Vérifiez-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 de rechange avec des supports fraîchement téléchargés, en ne restaurant que les données des sauvegardes (car les binaires peuvent être compromis) ou clonez l'hôte compromis vers un endroit 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 recourir à des voies légales. (Remarque: IANAL).
Matériel:
Ne présumez jamais que quoi que ce soit fera ce qui est indiqué sur la boîte. Prouvez qu'il fait ce dont vous avez besoin, juste au cas où il ne le ferait pas. Vous vous surprendrez à dire "cela fonctionne presque" plus fréquemment que vous ne le pensez.
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 multiprises contrôlées à distance pour les moments où vous n'avez plus d'options.
(À part: Il y a deux façons de résoudre un problème à 3 heures du matin, l'une consiste à être au chaud, à travailler sur un ordinateur portable via un VPN dans votre pyjama, l'autre implique une veste épaisse et un lecteur vers le centre de données/bureau. Je sais lequel je 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 d'exécution sur le kit et le temps du cerveau peuvent surprendre et surprendront, et il ne fait aucun doute qu'ils auront (devraient?) Avoir des normes ou des exigences qui deviendront des dépendances du projet.
La documentation fait partie du projet. Vous n'aurez jamais le temps d'écrire le tout après la fermeture du projet et le passage du système à la maintenance, alors assurez-vous qu'il est inclus comme effort dans le calendrier au début.
Implémentez l'obsolescence planifiée dans le projet dès le premier jour et lancez le cycle de rafraîchissement six mois avant le jour de désactivation 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 à chaque fois que le fournisseur commence à facturer plus de maintenance annuelle qu'il n'en coûterait pour actualiser le kit, ou environ trois ans, la période 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 donne amplement le temps de passer à travers les cadres de gestion et de financement nécessaires pour commander un nouveau kit et de mettre en œuvre une migration en douceur avant d'envoyer l'ancien kit au grand fournisseur dans le ciel.
Développement:
- Assurez-vous que vos systèmes de développement et de mise en scène ressemblent à la production. Les VM ou autres techniques de virtualisation (zones, LDOM, vservers) facilitent la production de clones de production réels dans tous les sens, mais performants.
Sauvegardes
Les données que vous ne sauvegardez pas sont des données dont vous ne voulez pas. Il s'agit d'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 mis au repos pour avoir 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 gérer les fichiers ouverts/verrouillés, d'autres non. Vider les bases de données sur le disque et les sauvegarder compte comme une forme de "mise au repos", mais ce n'est pas la seule méthode.
Les sauvegardes ne valent rien sauf si elles sont testées. Tous les quelques mois, retirez une bande aléatoire des archives, assurez-vous qu'elle contient bien des données et que les données sont cohérentes.
Et, surtout...
Choisissez vos modes de défaillance, ou Murphy le fera ... et Murphy ne fonctionne pas selon votre horaire.
Concevoir pour l'échec, documenter les points faibles conçus de chaque système, ce qui les déclenche et comment récupérer. Cela fera toute la différence en cas de problème.
Ne présumez pas que c'est facile. Je connais de nombreux programmeurs qui pensent que juste parce qu'ils peuvent configurer IIS ou Apache sur la boîte de développement là-bas, ils peuvent exécuter une ferme Web. Comprenez ce que le travail implique et faites vos recherches et votre planification, ne faites pas '' Je pense simplement que le travail d'administrateur système est la chose facile que vous pouvez faire en 10 minutes pour déployer votre application.
- Sachez que, pour le meilleur ou pour le pire, de nombreux serveurs et/ou équipements de mise en réseau qu'ils ont tendance à ressembler à 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 tout problème. Cela ne devrait pas être ainsi, mais après de nombreuses années, c'est souvent le cas . Gardez cela à l'esprit lorsque vous leur communiquez vos préoccupations concernant le mauvais fonctionnement de l'équipement ou les attentes. Et si vous obtenez une réponse que vous ne comprenez pas, essayez de la filtrer à travers cette vision du monde.
- Soyez en bonnes conditions de travail. Ça a l'air effrayant, mais ça vaut son pesant d'or. Un jour, vous aurez besoin d'une faveur spéciale. Et un jour, cet administrateur système sera ravi de faire tout son possible pour vous faciliter la vie, juste cette fois.
- Cette relation de travail va dans les deux sens. Si l'administrateur système est très occupé et que vous pourriez vous faciliter la vie en écrivant un petit script ou programme, faites-le! Ils l'apprécieront plus que vous ne le pensez.
- Soyez très clair. "Cela craint" n'est pas aussi clair que "avoir une connexion réseau intermittente est un peu ennuyeux, avez-vous une chance de le regarder?"
- Si vous pensez que votre application évoluera, demandez à l'administrateur avant de supposer qu'elle le fera. 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, demandez-lui si les serveurs fonctionnent. Les administrateurs système soignent leurs machines avec soin et ne sont pas satisfaits lorsqu'ils sont "malades" ou "mal comportés". Demander gentiment fera tourner une machine malade (ou la fera réparer/remplacer).
- (comme mentionné ailleurs) documenter les paramètres que vous utilisez et pourquoi vous les utilisez. Le simple fait de "définir la case à cocher X" ou de "décommenter la ligne de fichier de configuration Y" n'aide pas. Vous pourriez définir l'option qui efface toutes vos données au prochain redémarrage pour tout ce que vous savez.
- Si vous n'avez pas le temps de documenter le paramètre sur papier, essayez de le documenter dans le système si possible. Avec les fichiers de configuration, cela devrait presque être une pratique standard - chaque changement de paramètre doit être horodaté, avec les initiales, l'effet attendu de ce paramètre et la raison pourquoi il a été changé (voir puce précédente). 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 politique X, et le paramètre Y nous donne le comportement dont nous avons besoin pour la politique X".
- Bière. Ou Cola. Ou même de l'eau. Les boissons sont toujours les bienvenues. Être administrateur système est un travail assoiffé.
La sécurité n'est pas une réflexion après coup. Bien qu'une application piratée puisse rendre le programmeur incompétent, c'est (au moins) un week-end perdu passé à vérifier, nettoyer et/ou restaurer à partir de sauvegardes pour un administrateur système.
D'ailleurs, ne traitez 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 que votre code soit brisé. Peu m'importe que cela ait fonctionné avant, dites-moi pourquoi cela ne fonctionne pas maintenant - alors nous pouvons voir de qui il s'agit.
Comment déboguer les problèmes de mise en réseau et regarder votre programme s'exécuter avec les outils sysadmin. En tant que programmeur qui a débuté dans l'administration système, je suis étonné de voir à quel point de nombreux programmeurs deviennent impuissants une fois que la mise en réseau "s'arrête".
- Wireshark, pour regarder votre code s'exécuter à la manière d'une boîte noire, paquet par paquet
- Outils pour se connecter directement aux services réseau:
- Telnet, netcat ou socat pour les connexions simples sur TCP ou UDP
- OpenSSL pour la même chose avec le cryptage (indice: essayez
openssl s_client -connect target-Host:portparfois), pour une connexion manuelle aux services réseau
- Dig (dans le package BIND 9) pour le débogage de la résolution de nom
- Être capable de dire quelle partie de la pile réseau a échoué en fonction du timing et d'autres caractéristiques d'une connexion défaillante
- Peut-être HTTPFox et/ou Firebug
Sachez comment résoudre les problèmes.
Il est très facile de passer la balle (par exemple, votre réseau arrose 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, en utilisant Google ou 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, donc si vous pratiquez un peu plus la diligence raisonnable, vous ferez du sysadmin 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 (par opposition à 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 quelqu'un voulait simplement entrer et sortir. Tout comme un programmeur doit laisser de bons commentaires, les administrateurs système doivent documenter. Un diagramme de la topologie serait bien aussi.
Plan B.
Ayez toujours un plan de reprise après sinistre à l'esprit lors de la conception et du développement d'une solution. Reconnaître les points de défaillance uniques pouvant entraîner une panne.
Documentation: pas besoin de devenir fou, mais comment fonctionne l'application, un diagramme montrant comment les bits s'ajustent et les moyens de tester chaque composant quand tout va mal. Des exemples de données et de sortie sont Nice.
Exigences: sur quels modules s'appuie-t-il? Versions? OS?
Surveillance: idéalement, les développeurs devraient inclure des informations de surveillance et des tests avec l'application.
En parlant d'emballage, d'EMBALLAGE! Rien de pire qu'un "déploiement" qui signifie vérifier une nouvelle révision d'un fichier de VCS et le copier sur un tas 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 l'épine dorsale de la plupart des systèmes d'exploitation.
Si un développeur venait à moi avec un RPM installé pour la première fois avec une documentation concise et complète et des tests Nagios, il serait mon nouveau meilleur ami.
Je suis surpris qu'aucune des 17 réponses fournies jusqu'ici n'inclue quoi que ce soit sur le fait de garantir que votre application s'exécute lorsqu'elle est connectée en tant qu'utilisateur standard.
Outre le processus d'installation, l'application doit fonctionner correctement lorsqu'elle est connectée avec un compte d'utilisateur standard.
- parlez à votre administrateur de manière formelle et informelle de ce que vous faites. Ils seront généralement intéressés et pourront exprimer très tôt les éventuels impacts sur la production. Vous n'avez pas à être d'accord, mais cela aide à identifier les points chauds.
- Non, vous ne pouvez pas avoir l'intégralité du serveur pour vous ... Si vous en avez besoin, c'est une décision politique, quelle que soit sa technicité. Si vous voulez travailler la politique, allez-y.
- Le matériel de production est souvent différent de celui de votre serveur de développement, et même au sein des batteries de serveurs, les spécifications des machines sont différentes.
- Découvrez comment la production est configurée, car vous ne pouvez probablement pas la répliquer sur votre bureau, cela vous empêche de faire de mauvaises hypothèses.
- Ce n'est pas parce que vous pouvez mettre en cache des éléments en mémoire que vous le devriez, attendez d'abord le goulot d'étranglement (lors des tests unitaires ou des tests de performances de pré-production)
- si vous collez des données dans une base de données, réfléchissez à la façon dont vous pouvez diviser les données en données en lecture seule (qui pourraient être mises à l'échelle horizontalement) et en données en lecture-écriture (qui ne sont généralement mises à l'échelle que verticalement).
- si vous collez des données dans une base de données, doit être vraiment un SGBDR? il existe d'autres systèmes de paires clé-valeur qui évoluent mieux (netcache).
- ne pensez pas AJAX est la solution finale, elle a l'air cool, mais elle limite les possibilités de surveillance et d'automatisation. Je ne dis pas de ne pas l'utiliser, réfléchissez-y à deux fois.
OK c'est un peu délirant mais:
a) Lors du codage, supposez que l'infrastructure sous-jacente pourrait échouer et ne provienne pas d'un terrain toujours heureux. Ou Google.
b) Nous n'avons probablement pas les ressources pour mettre en œuvre quelque chose comme l'infrastructure que vous avez lue, alors soyez tranquille avec nous lorsque les choses vont mal. Il est probable que nous savons ce qui doit être fait, mais pour une raison quelconque, cela ne s'est pas encore produit. Nous sommes vos partenaires!
c) Comme jhs l'a dit ci-dessus, cela vous aiderait vraiment si vous aviez une connaissance passagère des outils pour dépanner l'infrastructure, tels que ping, traceroute (ou combiner les deux - mtr), Dig, etc. Des points bonus massifs pour même connaître Wireshark.
d) Si vous programmez un ordinateur, vous devez vraiment savoir comment il se connecte au réseau et les bases comme pouvoir analyser la sortie de ipconfig/all ou ifconfig. Vous devriez être en mesure de mettre en place votre connexion Internet avec un minimum d'aide.
Sinon, je pense qu'Avery l'a bien compris. Les développeurs qui font un peu d'administrateur système valent leur pesant d'or! Mais également, les administrateurs système qui comprennent comment les développeurs font les choses (y compris la gestion des versions, etc.) sont à peu près essentiels à l'heure actuelle.
Cela semble être dans l'air en ce moment, j'ai remarqué plus de discussions sur la relation dev/ops dans les blogs - consultez
Sauvegarde Sauvegarde Sauvegarde .... Testez la sauvegarde .... Soyez toujours prêt à revenir en arrière
Cela peut s'appliquer uniquement aux programmeurs débutants, mais je traite de certaines choses sur chaque projet avec certains programmeurs.
"Ça marche sur ma machine" n'est jamais une déclaration valable. Il est de la responsabilité du programmeur de créer un programme d'installation à utiliser sur le serveur, ou au moins de documenter chaque connexion et DLL et complément qui seront nécessaires sur le serveur.
(J'ai entendu cela plusieurs fois, alors ne riez pas) Je lance l'exe sur le serveur depuis ma machine et cela fonctionne. Mais, lorsque je l'exécute sur le serveur (Citrix, Terminal Server, etc.), cela ne fonctionne pas. Veuillez comprendre les dll et ocx et tout ce dont votre programme a besoin et où et comment ils sont enregistrés, et comment votre programme les utilise.
Cela peut sembler simple, mais je m'en occupe constamment.
Brian
Qu'aucun groupe ou fonction n'est "meilleur" qu'un autre et qu'aucun n'a besoin de "cerveaux plus gros" les uns que les autres. J'ai vu les deux parties obtenir tous les prima-dona'ish en compagnie de l'autre - vous essayez tous d'atteindre les mêmes objectifs - se concentrer sur ces similitudes et non sur le fait que vous utilisez des outils différents.
L'architecte de l'infrastructure est devenu programmeur, mais pourrait vouloir annuler cette transaction à l'avenir :)
- Parlez-vous tôt et souvent. Examinez les conceptions avec les gars qui géreront l'infrastructure sur laquelle votre application sera déployée (si vous savez qui ce sera).
- Aucune perte de données n'est possible, mais c'est une responsabilité partagée par les développeurs et les administrateurs système. Encore une fois, parler les uns aux autres peut aider ici.
- Votre personnel d'infrastructure aurait dû être impliqué dans la détermination des exigences non fonctionnelles.
- Organisez la bière (lorsque le travail est terminé) et la pizza (pendant que nous travaillons). D'une certaine manière, la présence de ce type de nourriture a un impact sur notre capacité à faire en sorte que nos jolies petites boîtes de 32 processeurs fassent ce que vous voulez qu'elles fassent :)
En tant que personne qui a été administrateur système pour les développeurs et développeur moi-même, les conseils donnés ici ne sont pas seulement d'or, mais devraient faire partie de la documentation d'embauche de nouveaux développeurs pour les entreprises du monde entier.
Quelque chose que je n'ai pas (encore) expliqué est que les développeurs devraient vraiment connaître les produits qu'ils utiliseront pour créer les programmes pour lesquels ils sont payés. Le nombre de fois que j'ai eu à expliquer et à configurer des serveurs Apache, des installations Eclipse et Visual Studio et des bases de données sur des machines de développeur est un peu inquiétant.