SysAdmin & Developer: Responsabilités [fermé]

En ce qui concerne quelque chose comme un serveur Web de production, quelle est la meilleure pratique pour les responsabilités du sysadmin et du développeur? Plus précisément, je pense à mettre à jour / installer des logiciels. (À ma connaissance, le développeur ne devrait pas avoir un accès root sur le serveur de production.)

Un serveur Web de production exécute donc Wordpress et doit être mis à jour vers la dernière version. Qui est responsable de sa mise à jour?

Que faire si les développeurs ont des plugins piratés personnalisés ou des fichiers de base personnalisés sur l'application (dans cet exemple, WP)?

J'ai constaté que dans la plupart des cas, si VOUS êtes le responsable du serveur physique, il vaut mieux NE PAS donner aux développeurs un accès root.

C'est un peu un débat sur la "guerre sainte" car je suis sûr que vous trouverez des développeurs en désaccord. J'ai personnellement été des deux côtés de ce débat.

Mon principal raisonnement pour ne pas donner aux développeurs (même les développeurs de confiance à 100%) un accès root est parce que le plus souvent, il y a un paquet dont ils ont besoin pour faire fonctionner XYZ correctement. Ils vont de l'avant et l'installent ... ou reconfigurent quelque chose qui est déjà en place pour que cela fonctionne ... ou ... eh bien ... vous avez l'idée.

Des mois passent ... le serveur doit être réinstallé ou recréé ... et soudain, personne ne sait pourquoi "Cela fonctionne sur l'ancien serveur mais pas sur le nouveau".

La réponse est bien sûr que la documentation que vous regardez n'inclut pas tous ces petits packages et réglages que les développeurs ont faits pour faire fonctionner le système la première fois.

Cela peut être pénible pour les deux parties ... mais si l'administrateur système est responsable du serveur, des packages et de la documentation ... et que le développeur est responsable du développement et du logiciel ... je pense que vous ' ll trouvera que cela en valait la peine à la fin.

Si le développeur a besoin d'un plugin, d'un module, d'une configuration, d'une modification personnalisés ... pas de problème ... faites-le pour eux ... mais DOCUMENTEZ-le pour que vous puissiez le reproduire la prochaine fois.

Règle d'or : ne laissez pas les non-administrateurs toucher à tout ce que vous ne voulez pas casser et dont vous serez tenu responsable.

Les développeurs doivent avoir accès à un environnement de test. Une fois que leur travail est prêt à être placé sur la machine de production, il doit être remis à l'administrateur système. Si les développeurs ont fait leur travail et correctement documenté la procédure, tout ira bien. Si ce n'est pas le cas, ils ont besoin de coups de pied à l'arrière pour ne pas effectuer les tests de manière adéquate.

J'ai également participé à cette bataille. Ma réponse est que quiconque est responsable de la disponibilité du serveur est celui qui devrait être responsable de toutes les mises à jour, modifications, etc., etc. Nobodoy autrement devrait avoir la capacité d'effectuer ces types de fonctions sur le serveur. Si c'est votre travail de vous assurer que le serveur est opérationnel et si le patron vous tient pour responsable et responsable du serveur, il est de votre responsabilité de le maintenir et de le sécuriser.

La plupart des développeurs vont vous dire qu'ils ont besoin d'un accès de niveau administrateur au serveur et la plupart d'entre eux ne seront pas d'accord avec moi, mais je suis celui qui doit le redémarrer à 2 heures du matin quand il raccroche, doit le reconstruire après une mise à jour a échoué, le temps d'arrêt est facturé à mon service, etc., etc. Je dois répondre au CIO pour tout ce qui a un impact sur notre SLA, donc je suis le seul à avoir un accès de niveau administrateur au serveur et je ' m responsable de tous les composants, mises à jour, modifications, etc.

Je suis d'accord à 100%. Les développeurs ne sont généralement pas conscients du fonctionnement des syadmin. S'ils ont besoin de quelque chose, ils vous demandent, c'est tout. Vous pensez comment et quand et vous leur livrez un colis utilisable. (comme ils ont besoin d'envoyer des e-mails, VOUS êtes celui qui doit configurer postfix). De plus, ils auront tendance à penser que dans la plupart des cas, l'accès root fera fonctionner les choses s'ils ne sont pas en mesure de le faire avec un accès normal. Je suis d'accord avec les autres ici, ils ne seront pas avec vous à 2 heures du matin quand vous verrez un problème. J'ai eu le cas il y a quelques semaines, un développeur voulait mettre à jour son wordpress. Je lui ai dit de changelog RTF, pour lui, c'était inutile, le processus de mise à jour se fait via une belle interface. Et bien la mise à jour n'a pas fonctionné, j'ai fait enregistrer son application, j'ai fait le script de sauvegarde pas lui. Sans moi, il n'aurait pas pu restaurer le site.

Il y a une tendance à brouiller la distinction entre dev et opérations. Rendez vos développeurs administrateurs système et vos développeurs administrateurs système.

En ce sens, wordpress pourrait bénéficier de quelques travaux sur la création de blogs automatisée (et programmatique). De nombreux utilisateurs de wordpress maintiennent plus de quelques instances WP / WPMU et les mettre à jour en temps opportun est au moins fastidieux.

Vous pouvez trouver un aperçu agréable (et amusant) de la philosophie sur les diapositives Agile Infrastructure d'Agile 2009

Les développeurs ne devraient pas avoir racine sur la production; tout le monde sauf les développeurs est d'accord sur ce point. Mais les développeurs peuvent en quelque sorte avoir leur gâteau et le manger aussi. Je suis quelque peu surpris que personne n'ait explicitement mentionné cela:

Un de mes très petits clients de longue date possède un site Web avec une installation Drupal, plusieurs sites WordPress, un forum SMF et quelques autres petites applications Web aléatoires. Je suis l'administrateur du contrat (et pour des raisons historiques, je mets également à jour / pirate WordPress et SMF si nécessaire) et mon client a son propre contrat de développeurs Drupal. L'environnement est constitué de plusieurs machines virtuelles VMware sur un fournisseur de cloud public.

Les développeurs veulent vraiment avoir un accès root et en ont besoin. C'est leur responsabilité d'écrire les règles de réécriture de nginx pour faire fonctionner tous leurs trucs Drupal personnalisés, par exemple. Mais en aucune façon je ne leur donne un accès root sur le serveur de production, et mon client est d'accord avec moi à ce sujet.

Nous avons donc compromis: ils obtiennent un accès root sur le serveur Web de test (qui est généralement identique à la production à l'exception de son adresse IP et se trouve sur le même cloud). Qui, comme la production, a etckeeper pour que je puisse voir les changements à apporter et les packages installés. Je peux alors soit mettre les changements en production ou leur dire ce qui ne va pas avec ce qu'ils veulent faire. Et s'ils ont vraiment foiré (ils ne l'ont pas encore fait, merci gawd) je peux facilement revenir sur leurs changements.

Ils n'ont aucun accès au serveur de base de données de production; ils n'ont même pas de connexion utilisateur. Seul mon client et moi le faisons.

(L'application Web elle-même, elle se déploie directement avec git, et si elle la casse, elle peut la réparer et expliquer à mon client pourquoi ils devraient continuer à être ses développeurs. Bien que mon client me CC sur un tel e-mail pour que je puisse soit rire d'eux ou facepalm.)

Root == Administrateur système.

Utilisateurs == Développeurs, DBA ou utilisateurs.

Root ne connaît pas de sommeil lorsqu'un serveur est en panne, root protège les utilisateurs d'eux-mêmes, root protège les données des utilisateurs du net, root place la santé du serveur au-dessus de tous les utilisateurs. Le cul de Root est en ligne lorsque le serveur est hors ligne. Serveur heureux, root heureux!

Raisons courantes des temps d'arrêt non planifiés: utilisateurs, modifications non documentées de l'environnement et rétrocaveuses. Les serveurs font exactement ce qu'on leur dit de ne pas simplement interrompre au hasard. Les pirates vous demandent, ce n'est pas si, c'est quand ... d'où le besoin d'une "racine".

00:33 CDT savez-vous où se trouvent vos sauvegardes et documents de reprise après sinistre? :-p

Les administrateurs système doivent avoir un accès administrateur (comme le dit le titre). Personne d'autre n'a besoin d'accéder aux serveurs de production. Si les développeurs doivent résoudre un problème sur un système de production, ce problème doit être reproductible dans l'environnement de développement. Si ce n'est pas le cas, ils peuvent s'asseoir avec l'administrateur système et regarder à travers le système.

Les développeurs n'aiment pas ne pas pouvoir toucher à la production, mais ce n'est pas leur travail. Le travail consiste à écrire le logiciel et à le remettre aux administrateurs système pour une version de production. S'ils ont tout documenté (et gardez à l'esprit que dans la plupart des magasins, la documentation est un gros mot), alors les versions devraient bien se passer.

Aux États-Unis, dans les sociétés ouvertes, vous devez gérer SOX, HIPPA, etc. La plupart de ces réglementations abandonnées aident réellement avec cet argument. SOX dicte la séparation des tâches, ce qui oblige les développeurs à ne pas toucher aux systèmes de production.