Quelles sont les choses que tout programmeur devrait connaître en tant qu'administrateur système ?

<inert big post disclaimer here>

Certaines de ces choses ont déjà été dites, mais cela vaut la peine de les répéter.

Documentation :

• Documentez tout. Si vous n'en avez pas, installez un wiki discret, mais assurez-vous de le sauvegarder. Commencez par rassembler des faits, et un jour, une image globale se formera.

• Créez des diagrammes pour chaque morceau logique et tenez-les à jour. Je ne pourrais pas compter le nombre de fois où une carte de réseau ou un diagramme de cluster précis m'a sauvé.

• Conservez les journaux de construction de chaque système, même s'il s'agit simplement de copier-coller les commandes de construction.

• Lorsque vous construisez votre système, installez et configurez vos applications, testez son fonctionnement et effectuez vos analyses comparatives. Maintenant, effacez les disques. Sérieusement. Supprimez le premier mégaoctet de l'avant des disques ou rendez la boîte non amorçable. L'heure tourne : prouvez que votre documentation peut le reconstruire à partir de zéro (ou, mieux encore, prouvez que votre collègue peut le faire avec rien 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 reprise après sinistre, documentez le reste : comment rétablir l'état de votre application (restaurer les fichiers à partir d'une bande, recharger les bases de données à partir des vidages), les détails concernant les fournisseurs et l'assistance, les exigences du réseau, comment et où obtenir du matériel de remplacement - tout ce qui vous vient à l'esprit et qui vous aidera à remettre votre système en état.

Automatisation :

• Automatisez autant que vous le pouvez. Si vous devez faire quelque chose trois fois, assurez-vous que la deuxième fois est consacrée au développement de votre automatisation afin que la troisième soit entièrement automatisée. Si vous ne pouvez pas l'automatiser, documentez-la. Il existe des suites d'automatisation - voyez si vous pouvez les faire fonctionner pour vous.

Surveillance :

• L'instrumentation d'application est de l'or pur. La possibilité d'observer les transactions qui passent par le système facilite énormément 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 qu'elle fait vraiment ce qu'elle est censée faire. Des points sont accordés si l'application peut être connectée au système de surveillance à des fins d'alerte. En plus de prouver que l'application fonctionne, cela facilite considérablement les mises à niveau du système (le système de surveillance affiche un rapport vert, la mise à niveau a fonctionné, il est temps de rentrer à la maison).

• Effectuez des analyses comparatives, surveillez et collectez des données sur tout ce qui est raisonnable pour le faire. Les points de repère vous indiquent quand vous pouvez vous attendre à ce que quelque chose dégage la fumée magique. Le suivi vous indique quand il l'a fait. Les mesures et les statistiques facilitent l'introduction de nouveaux kits (avec de la fumée magique fraîche) auprès de la direction.

• Si vous n'avez pas de système de contrôle, mettez-en un en place. Des points bonus si vous y intégrez les tests de bout en bout ci-dessus.

Sécurité :

• "chmod 777" (alias accorder tous les accès/privilèges) n'est jamais la solution.

• Souscrivez au principe du "moindre bit" ; s'il n'est pas installé, copié ou vivant sur le disque, il ne peut pas être compromis. "L'installation d'un système d'exploitation ou d'un logiciel dans un évier de cuisine peut vous faciliter la vie pendant la phase de construction, mais vous finirez par en payer le prix.

• Savoir à quoi sert chaque port ouvert sur un serveur. Vérifiez-les fréquemment pour vous assurer qu'aucun nouveau port 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 médias 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 dans un endroit isolé pour analyse afin de pouvoir 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 recourir à des voies légales. (Note : IANAL).

Matériel :

• Ne supposez jamais que quelque chose fera ce qui est écrit 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 "ça marche presque" plus souvent que vous ne le pensez.

• Ne lésinez pas sur la gestion à distance du matériel. Les consoles en série et la gestion de l'extinction des feux doivent être considérées comme obligatoires. Les multiprises contrôlées à distance sont un plus lorsque vous n'avez pas le choix.

(Aside : Il y a deux façons de résoudre un problème à 3 heures du matin, l'une implique d'être au chaud, de travailler sur un ordinateur portable via un VPN en pyjama, l'autre implique une veste épaisse et un trajet jusqu'au centre de données/bureau. Je sais laquelle je préfère).

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'approvisionnement en matériel et le temps de réflexion peuvent et vont surprendre, et il ne fait aucun doute qu'ils auront (devraient ?) 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 une fois que le projet aura été clôturé et que le système sera passé en phase de maintenance, alors assurez-vous qu'elle est incluse dans le calendrier dès le début.

• Mettez en œuvre l'obsolescence planifiée dans le projet dès le premier jour, et commencez le cycle de rafraîchissement six mois avant le jour d'arrêt que vous avez spécifié dans la documentation du projet.

Les serveurs ont une durée de vie définie lorsqu'ils sont aptes à être utilisés en production. La fin de cette durée de vie est généralement définie comme le moment où le fournisseur commence à facturer une maintenance annuelle supérieure au coût de renouvellement du kit, ou environ trois ans, selon la période la plus courte. Après cette période, ils sont parfaits pour les environnements de développement et de test, mais vous ne devez pas vous y fier pour gérer votre entreprise. En réexaminant l'environnement au bout de deux ans et demi, vous avez largement le temps de franchir 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 l'ancien kit chez le grand fournisseur du ciel.

Développement :

• Veillez à ce que vos systèmes de développement et de test ressemblent à des systèmes de production. Les VM ou d'autres techniques de virtualisation (zones, LDOM, vservers) facilitent les clones de production dans le monde réel, dans tous les sens du terme, mais avec des performances.

Sauvegardes

• Les données que vous ne sauvegardez pas sont des données dont vous ne voulez pas. C'est une loi immuable. Assurez-vous que votre réalité correspond à cette loi.

• Les sauvegardes sont plus difficiles qu'il n'y paraît ; certains fichiers seront ouverts ou verrouillés, tandis que d'autres doivent être mis sous tranquillisants pour avoir un espoir de récupération, et tous ces problèmes doivent être traités. Certains paquets de sauvegarde ont des agents ou d'autres méthodes pour traiter les fichiers ouverts/verrouillés, d'autres non. Le vidage des bases de données sur le disque et la sauvegarde de celles-ci constituent une forme de "quiescing", mais ce n'est pas la seule méthode.

• Les sauvegardes ne valent rien si elles ne sont pas testées. Tous les quelques mois, sortez une bande aléatoire des archives, vérifiez qu'elle contient bien des données et que celles-ci sont cohérentes.

Et le plus important...

Choisissez vos modes d'échec, ou Murphy le fera... et Murphy ne travaille pas selon votre calendrier.

Concevez en fonction des défaillances, documentez les points faibles de chaque système, ce qui les déclenche et comment les récupérer. Cela fera toute la différence lorsque quelque chose se passera mal.

Ne supposez 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 développement, ils peuvent gérer une ferme web. Comprenez ce que le travail implique et faites vos recherches et votre planification, ne pensez pas simplement que le travail d'administrateur système est la chose facile que vous pouvez faire en 10 minutes pour que votre application soit déployée.

• Réalisez que, pour le meilleur ou pour le pire, un grand nombre des serveurs et/ou des équipements de réseau dont ils s'occupent sont en quelque sorte les enfants d'une seconde famille. Ce sont leurs bébés. Ils les soignent, les aident lorsqu'ils sont malades et les surveillent de près pour détecter tout problème. Ce site ne devrait pas être de cette façon, mais après de nombreuses années, elle l'est souvent . Gardez cela à l'esprit lorsque vous leur faites part de vos préoccupations concernant un équipement qui ne fonctionne pas correctement ou qui ne répond pas aux attentes. Et si vous recevez une réponse que vous ne comprenez pas, essayez de la filtrer à travers cette vision du monde.
• Être en bons termes de travail. Ça a l'air ringard, 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 heureux de se mettre en quatre pour vous rendre la vie un peu plus facile, juste cette fois-ci.
• Cette relation de travail va dans les deux sens. Si l'administrateur système est très occupé et que vous pouvez lui 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 pensez.
• Soyez très clair. "Ça craint" n'est pas aussi clair que "avoir une connexion réseau intermittente est un peu ennuyeux, pouvez-vous y remédier ?".
• Si vous pensez que votre application va changer d'échelle, demandez à l'administrateur avant de l'utiliser. en supposant que il le fera. Ils peuvent "voir" quelque chose que vous ne voyez pas, ou connaître les limites de performance de l'équipement que vous allez déployer.
• Si votre application a besoin d'être optimisée, mais qu'il ne semble pas s'agir d'un problème de code, demandez gentiment comment les serveurs fonctionnent. Les administrateurs système s'occupent de leurs machines avec beaucoup d'attention et ne sont pas satisfaits lorsqu'elles sont "malades" ou "mal conduites". En demandant gentiment, vous pouvez faire fonctionner une machine malade (ou la faire réparer/remplacer).
• (comme mentionné ailleurs) documentez les paramètres que vous utilisez, et pourquoi vous les utilisez. Le simple fait d'avoir "activer la case à cocher X" ou "décommenter la ligne Y du fichier de configuration" n'aide pas. Vous pourriez être en train de définir l'option qui efface toutes vos données au prochain redémarrage pour 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 standard - chaque changement de paramètre devrait être daté, avec des initiales, l'effet attendu de ce paramètre et la raison. pourquoi il a été modifié (voir le point précédent). Cette petite habitude m'a sauvé la mise plus d'une fois en 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 du Cola. Ou même de l'eau. Les boissons sont toujours les bienvenues. Être un administrateur système est un travail qui donne soif.

La sécurité n'est pas une réflexion après coup. Si une application piratée peut faire passer le programmeur pour un incompétent, c'est (au moins) un week-end perdu à vérifier, nettoyer et/ou restaurer à partir de sauvegardes pour un administrateur système.

D'ailleurs, ne considérez pas les sauvegardes comme un contrôle de version. Elles sont destinées à la reprise après sinistre et ne sont pas vraiment conçues pour restaurer votre code parce que vous avez oublié ce que vous avez modifié.

Et arrêtez de blâmer aveuglément les mises à jour de Windows pour que votre code soit cassé. Je me fiche de savoir qu'il fonctionnait avant, dites-moi pourquoi il ne fonctionne plus maintenant - nous verrons alors à qui la faute.