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

Comment déboguer les 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 étonné de voir à quel point de nombreux programmeurs deviennent impuissants lorsque le réseau "s'arrête".

• Wireshark pour regarder votre code s'exécuter en boîte noire, paquet par paquet.
• Outils permettant de se connecter directement aux services du 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 paquetage BIND 9) pour déboguer la résolution de noms
• Être capable de dire quelle partie de la pile réseau a échoué en se basant sur le timing et d'autres caractéristiques d'une connexion qui a échoué.
• Possiblement HTTPFox et/ou Firebug

Savoir comment résoudre les problèmes.

Il est très facile de se 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, en utilisant Google ou SO, peuvent révéler un problème dans la configuration d'une application.

Tout le monde aime rejeter la faute sur le matériel, le système d'exploitation ou le réseau. Si vous faites preuve d'un peu plus de diligence, vous ferez le bonheur de l'administrateur système. Si vous faites preuve d'un peu plus de diligence, vous ferez le bonheur de l'administrateur système. En effet, vous pourrez peut-être l'orienter vers une solution spécifique (au lieu de lui 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 juste entrer et sortir. Tout comme un programmeur doit laisser de bons commentaires, les sysadmins doivent documenter. Un diagramme de la topologie serait également bienvenu.

Plan B.

Ayez toujours à l'esprit un plan de reprise après sinistre lorsque vous concevez et développez une solution. Reconnaissez les points de défaillance uniques qui peuvent entraîner une panne.

Documentation : pas besoin de s'emballer, mais comment l'application fonctionne, un diagramme montrant comment les pièces s'emboîtent et les moyens de tester chaque composant lorsque tout va mal. Des échantillons de données et de résultats sont appréciés.

Exigences : sur quels modules repose-t-il ? Versions ? SYSTÈME D'EXPLOITATION ?

Suivi : idéalement, les développeurs devraient inclure des informations et des tests de suivi avec l'application.

En parlant d'emballage, EMBALLAGE ! Il n'y a rien de pire qu'un "déploiement" qui consiste à extraire une nouvelle révision d'un fichier de VCS et à la copier sur un ensemble de serveurs. Trop souvent, les programmeurs n'apprécient pas la complexité du déploiement d'un logiciel : il y a des raisons pour lesquelles les logiciels versionnés et empaquetés forment l'épine dorsale de la plupart des systèmes d'exploitation.

Si un développeur me proposait un RPM qui s'installe du premier coup avec une documentation concise et complète et quelques tests Nagios, il serait mon nouveau meilleur ami.