bin autant « capitaliser » sur le problème rencontré, tant techniquement que pour tenter d'obtenir d'avoir au minimum une pré-production, à l'identique de la prod', histoire d'éviter que ça se reproduise... Quand je dis capitaliser c'est aussi en profiter pour identifier combien a coûté le souci rencontré :
temps d'indisponibilité, ce que ça a empêché de faire... (et ce que ça a généré comme coût)
différence de chiffrage du temps évalué à y passer avant et temps que cela a effectivement pris
nombre de fois où il est acceptable que ce genre de souci se reproduise...
Si on te répond que doubler l'infra pour des environnements qui ne serviront qu'une fois par an voire mois, bin indiquer les points notés ci-dessus :-) Garder comme autres arguments sous le coude que :
l'environnement en double pourrait servir de fail-over ou de remplacement si problème sur le serveur principal (les disques ça pète régulièrement, une carte réseau peut griller...)
dans le cas idéal, ce n'est pas un environnement supplémentaire qu'il faudrait mais un pour le "développement" (s'il y en a), un pour la qualification technique, un pour la qualification fonctionnelle (pour une appli), un pour la recette utilisateur, un pour les benchmarks, un pour la maintenance, un autre pour les montées de version, bon je dois en oublier :-) Il est possible de mutualiser pour optimiser un peu... mais bon généralement c'est tout de même 3 environnements au mini - en comptant la prod' - qui sont recommandés.
évaluer ce que la virtualisation peut apporter (pour pouvoir créer des environnements à la volée, sans avoir à acheter trop de matériel à chaque fois...), prévoir plus de place disque ça aide, doubler ou tripler le volume envisagé initialement (il y a toujours besoin de plus :/).
Dans l'admin, il y a le volet technique effectivement, mais il y a aussi tous les argumentaires pour justifier de pouvoir bosser correctement et dans de bonnes conditions plutôt qu'avec des bouts de ficelle.
Pour ta vingtaine de serveurs, puppet pour gérer les déploiements peut sembler overkill, mais bon ça permet aussi de scripter une mise en production et de la répéter sur un environnement amont à la prod' sans rien casser, sachant qu'il restera toujours un cas de plus non prévu (sinon spa drôle).
Sinon, comment ça des versions variées de debian ? Tout n'est pas en Squeeze ?
[^] # Re: une recherche avec ces memes questions
Posté par BAud (site web personnel) . En réponse au message Bonne pratique administration système. Évalué à 3.
bin autant « capitaliser » sur le problème rencontré, tant techniquement que pour tenter d'obtenir d'avoir au minimum une pré-production, à l'identique de la prod', histoire d'éviter que ça se reproduise... Quand je dis capitaliser c'est aussi en profiter pour identifier combien a coûté le souci rencontré :
Si on te répond que doubler l'infra pour des environnements qui ne serviront qu'une fois par an voire mois, bin indiquer les points notés ci-dessus :-) Garder comme autres arguments sous le coude que :
Dans l'admin, il y a le volet technique effectivement, mais il y a aussi tous les argumentaires pour justifier de pouvoir bosser correctement et dans de bonnes conditions plutôt qu'avec des bouts de ficelle.
Pour ta vingtaine de serveurs, puppet pour gérer les déploiements peut sembler overkill, mais bon ça permet aussi de scripter une mise en production et de la répéter sur un environnement amont à la prod' sans rien casser, sachant qu'il restera toujours un cas de plus non prévu (sinon spa drôle).
Sinon, comment ça des versions variées de debian ? Tout n'est pas en Squeeze ?