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?

Je commencerais par:

1. Toujours avoir un système de sauvegarde de quelque sorte. Encore mieux si cela a une histoire.
2. Pensez aux points d’échec uniques et à la manière de les traiter 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 le mien" car ils ont tel ou tel programme normalement installé.
4. Documentez tout, ne serait-ce que parce que vous allez oublier comment vous organisez quelque chose.
5. Restez au courant des mises à jour de sécurité.

<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:

• 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 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:

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

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.

• 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. Cela ne devrait pas être comme ça, mais après plusieurs années, c'est souvent le cas . Gardez cela à l'esprit lorsque vous leur faites part de vos préoccupations concernant le mauvais fonctionnement ou les 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, avez-vous une chance de la regarder?"
• Si vous pensez que votre application évoluera, demandez à l'administrateur avant de le supposer . 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 gentiment comment les serveurs fonctionnent. 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 d'avoir "la case à cocher X" ou la "ligne de fichier de configuration Y sans commentaire" n'aide pas. Vous pourriez éventuellement 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 pour laquelle il a été modifié (voir le 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.

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

• Wireshark , pour regarder votre code s'exécuter dans une 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 (astuce: essayez de openssl s_client -connect target-host:porttemps en temps), pour se connecter manuellement aux services réseau
• dig (dans le package BIND 9) pour la résolution de noms de débogage
• Être capable de déterminer quelle partie de la pile réseau a échoué en fonction du minutage et d'autres caractéristiques d'une connexion défaillante
• Éventuellement HTTPFox et / ou Firebug

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

Plan B.

Ayez toujours en tête un plan de reprise après sinistre lorsque vous concevez et développez une solution. Identifiez les points de défaillance uniques pouvant conduire à une panne.

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.

Sauvegarde Sauvegarde Sauvegarde .... Testez la sauvegarde .... Soyez toujours prêt à restaurer

Cela peut s’appliquer uniquement aux programmeurs débutants, mais je traite quelques points dans chaque projet avec certains programmeurs.

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

2. (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

• 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 impacts possibles sur la production. Vous n’êtes pas d’accord, mais cela aide à identifier les points problématiques.
• Non, vous ne pouvez pas avoir le serveur entier pour vous ... Si vous en avez le besoin, c'est une décision politique, indépendamment de sa technicité. Si vous voulez travailler la politique, allez-y.
• Le matériel de production a souvent un aspect différent de celui de votre serveur de développement. Même dans les batteries de serveurs, les spécifications sur les machines sont différentes.
• Découvrez comment la production est configurée, car vous ne pourrez probablement pas la répliquer sur votre bureau, ce qui vous évitera 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 devriez le faire, attendez d'abord le goulot d'étranglement (lors des tests unitaires ou des tests de performance de pré-production)
• Si vous collez des données dans une base de données, réfléchissez à la manière dont vous pourriez les scinder en données en lecture seule (pouvant être mises à l'échelle horizontalement) et 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, faut-il vraiment être un SGBDR? il existe d'autres systèmes de paires clé-valeur qui évoluent mieux (netcache).
• Ne pensez pas qu'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 ne l'utilisez pas, réfléchissez-y à deux fois.

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

Garder Twitter Twitter

Partitions et guerre

Testez d'abord dans les opérations

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 :)

1. Parlez-vous tôt et souvent. Passez en revue les conceptions avec les responsables de l'infrastructure sur laquelle votre application sera déployée (si vous savez de qui il s'agit).
2. Aucune perte de données n'est possible, mais il s'agit d'une responsabilité partagée par les développeurs et les administrateurs système. Encore une fois, se parler peut aider ici.
3. Votre personnel d'infrastructure aurait dû être impliqué dans la détermination des exigences non fonctionnelles.
4. Organisez de la bière (lorsque le travail est terminé) et de la pizza (pendant que nous travaillons). D'une certaine manière, la présence de ce type de nourriture a une incidence sur notre capacité à faire en sorte que nos jolies petites boîtes de 32 unités centrales fassent ce que vous voulez. :)

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.