www.dns-fr.com : votre avis ?

Spyou wrote:

Ca depends pour quoi. Et meme si on compte 1/4 ingé, 3/4 tech, on
arrive a 3h et quelques ... ce qui risque de mener a un travail baclé,
in finé, si les gens sont surchargés de boulot.

Ça me laisse assez perplexe comme analyse. Ça ne tient absolument pas
compte du fait que la plupart des taches d'administrations sont
identiques pour tout un lot de clients en même temps (ie, la plupart des
clients, même en infogéré, veulent un serveur LAMP opérationnel sans
configuration particulière...)

Avec le module PHP machin qui, quand on met a jour PHP, ne marche plus
pareil (ou plus du tout) et paf le site du client est down.

Donc a moins d'ecrire dans le contrat "on se borne a faire des mises a
jour et vous vous occupez de verifier que votre site fonctionne
correctement" il faut *au moins* passer sur tous les sites hebergés par
la machine du client a chaque mise a jour de soft.

Si on compte 2 versions de PHP par mois et 20 sites par machine, on est
deja aux 2h de boulot précités ... sans compter tout le reste.

Donc avec un système de duplication de systèmes et/ou de commandes, on
arrive à économiser un temps considérable sur un parc de client donnés
en infogérance totale (et c'est bien de cela qu'il s'agit ici,
apparemment).

Donc c'est de l'overselling .. on vend une presta a un client en
croisant les doigt pour que la majorité ne l'utilise pas. Et quand tout
le monde commence a l'utiliser (voir les diverses histoires de bande
passante chez les FAI et FSI) on impose des limites idiotes pour essayer
de justifier son mauvais business plan.

Le 19-08-2007, Spyou <root@spyou.org> a écrit :

Spyou wrote:

Si on compte 2 versions de PHP par mois et 20 sites par machine, on est
deja aux 2h de boulot précités ... sans compter tout le reste.

Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!)
de php par mois.


Jacques

Spyou wrote:

Si on compte 2 versions de PHP par mois et 20 sites par machine, on est
deja aux 2h de boulot précités ... sans compter tout le reste.

Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!)
de php par mois.

Ah ? une bonne distrib est donc une distrib qui ne repercute pas toutes
les mises a jour du PHP Group, mais seulement une de temps en temps ?

J'aurais plutot tendance a dire qu'une bonne distrib propage toutes les
mises a jour en quasi temps reel, accompagné d'un petit changelog et
d'une liste de trous de sécurités corrigés depuis l'ancienne version
pour savoir si oui ou non il faut mettre a jour.

Spyou wrote:

Donc c'est de l'overselling

Ou, en prenant un terme moins négatif, de la mutualisation.

.. on vend une presta a un client en
croisant les doigt pour que la majorité ne l'utilise pas.

Non, en comptant sur une utilisation "raisonnable" du service.

Effectivement, on peut assez facilement se retrouver à perte sur l'un ou
l'autre client, et tous les business plans devraient aujourd'hui inclure
une série de cas "worst cases" d'utilisation du service pour montrer que
même si tout le monde utilise tout à fond, la survie du service est
possible.

Je ne peux évidemment pas défendre les cas de certains FAI/FSI, mais on
ne peut pas crier haro sur le principe de mutualisation de manière
générale (principe qui existe dans tous les domaines et à tous les
niveaux) juste parce que certains n'ont pas été capable de prévoir les
évolutions d'usages de leurs services par leurs clients et d'agir en
conséquence.

++

Le 19-08-2007, Spyou <root@spyou.org> a écrit :

Si on choisit une *bonne* distrib on n'a pas deux versions (versions!?!)
de php par mois.

Ah ? une bonne distrib est donc une distrib qui ne repercute pas toutes
les mises a jour du PHP Group, mais seulement une de temps en temps ?

Une bonne distrib a une politique de *sécurité* et répercute rapidement
les maj relatives à la sécurité et attend une de ses «releases» importante
pour répercuter les évolutions du produit concerné.

Jacques, Debian Ubuntu et toutes sortes de (bonnes) choses

Sat, 18 Aug 2007 09:59:54 -0700,
1187456394.157689.44280@a39g2000hsc.googlegroups.com:

A partir d'un certain nombres de machines des procédures internes et des
modèles de configurations permettent d'avoir une configuration assez
flexible
par client sans pour autant ré-inventer la roue pour la totalité du
travail
nécéssaire.

Tu dois avoir beaucoup de chance. Moi j'ai eu 3 clients successifs dont
un voulais absolument Postfix, le suivant Qmail sur une Debian, et le
dernier je sais plus, mais autre chose.
En fait il se demande pourquoi etre prisonniers de certains choix alors
qu'on est sur un serveur dédié.

On 19 août, 21:47, "Mihamina (R12y) Rakotomandimby"
<miham...@rktmb.org> wrote:

Tu dois avoir beaucoup de chance. Moi j'ai eu 3 clients successifs dont
un voulais absolument Postfix, le suivant Qmail sur une Debian, et le
dernier je sais plus, mais autre chose.
En fait il se demande pourquoi etre prisonniers de certains choix alors
qu'on est sur un serveur dédié.

Bonsoir,

Il ne faut pas confondre les deux possibilités suivantes :

* Prestation(s) ponctuelle(s) : Le client à besoin à un moment donné
que son serveur soit pré-installé et pré-configuré selon ses besoin s.
Il garde le root, il se "débrouille" seul, et il sait qu'en cas de
problème son prestataire "connait" sa configuration initiale et qu'il
va pouvoir éventuellement intervenir en cas de besoin. Ces prestations
là ne sont généralement pas applicables à des forfaits, mais à une
facturation à l'heure ou à la journée (ex: 80 e HT/heures)

* Serveur infogéré (Serveur avec contrat/forfait de maintenance) : A
ce moment là, - généralement - le client ne connait même pas ce qui se
trouve au niveau applicatif (qmail, postfix ou encore sendmail), il
sait uniquement qu'il veut du POP3, du SMTP et de l'IMAP. Le client
désire seulement du résultat et (préfère) ignore(r) le moyen par
lequel tu y arrives.

Il existe évidement des cas ou des clients se trouvent - entre les
deux - ces clients là rentrent dans ce cas dans le cadre des
prestations ponctuelles ou bien dans une sorte de troisième catégorie
qui se définit par un montant mensuel forfaitaire assurant les
interventions pour des applications/contextes plus ou moins listés
avec un plafond sur le nombre d'heures par mois.

Cordialement,
--
David CHANIAL
http://www.sd-france.com/

1Mbps vendu au client pour 20 euro ne peut pas etre provisionné sur 4
transitaires (ou alors, faut que tu m'explique comment tu fais pour
avoir le Mbps a 5 euro chez Telia :))

1) C'est faux :) Il est parfaitement possible d'avoir une garantie de
provisionnement de 400 Mb/s par exemple tout en achetant 250 Mb/s,
attention je ne parle pas de commit et de burst mais bien de transit
garanti contractuellement.

2) Ton calcul ne tient pas compte des coûts fixes d'infrastructure :
yu achetes, par exemple 4x500 Mb/s sur 4 opérateur, tu l'inclus dans
ton coût de base d'infrastructure, tu as donc 500 Mb/s de provisionné
sur l'ensemble de tes opérateurs. Ceci peut parfaitement être financé
par exemple, par une seule branche de services de la société
concernée, comme la sécurité par exemple. Il y a encore d'autres
solutions, comme d'acheter le Mb/s à 5 euro :) cependant, les
fournisseurs concernés n'aimeraient pas voir trainer ce genre
d'informations sur les forums :) Enfin, pour peu que tu es 4 Gb/s de
provisionné en coût global, et que tu t'en es vendu que 1 Gb/s, il te
reste beaucoup de marge, qui n'a rien de statistique :)

Ou comment payer quelqu'un un salaire fixe (100 Euro par mois) en lui
demandant de faire un nombre d'heures illimitées.

Du tout là encore, tu fais un mauvais calcul. Ce n'est nullement de la
statistique, il ne faut pas oublier que les opérations d'infogérance
ne s'appliquent qu'à un certain nombre de distributions/logiciels/
serveurs "supportés". Il ne faut pas non plus oublier que tu raisonnes
encore en mono-activités. Quand tu as une équipe payée à plein temps
pour faire de la veille 24/24 et 7/7, et dont l'activité n'occupe que
10 à 15 % du temps de travail réel (tempx fixe), tu te retrouve avec +
de 80% de temps disponible sur une seconde équipe. En clair, sur ces
80% de temps tu fais 100% de marge, puisque cela ne te coute rien. En
même temps, on ne va pas dévoiler toutes les méthodes (il y en a
beaucoup), on est pas là non plus pour donner des solutions aux
concurrents/confrères :)

C'est de la statistique .. aujourd'hui, ca marche .. Demain, une
nouvelle techno ultra a la mode sors mais ingérable en un temps tres
court et paf, le chateau de carte s'effondre.

Nouvelle techno ultra à la mode = non supportée. Tout ce qui est fait

doit être validé par la classique chaine dev/recette/prod, c'est la
contrepartie de la stabilité et de la sécurité. Enfin pour les mises à
jour que tu citais dans un autre post, il n'y a heureusement pas à
vérifier que les 300 sites du clients fonctionnent correctement, là
aussi on applique des procédés, et, en cas de problème (moins d'un cas
sur 1000) un downgrade se fait en moins de 40 secondes.


amicalement,

--
Christophe Casalegno | Groupe Digital Network | UIN : 153305055
http://www.dns-fr.com | http://www.intelink.info
TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX
Technical director | Security Intrusion techniques & infowar
specialist.

On 19 août, 21:47, "Mihamina (R12y) Rakotomandimby"
<miham...@rktmb.org> wrote:

Tu dois avoir beaucoup de chance. Moi j'ai eu 3 clients successifs dont
un voulais absolument Postfix, le suivant Qmail sur une Debian, et le
dernier je sais plus, mais autre chose.
En fait il se demande pourquoi etre prisonniers de certains choix alors
qu'on est sur un serveur dédié.

Il ne faut pas confondre : louer une machine infogérée, où l'on
maitrise soi même tous les processus par rapport à un besoin, (le
client ne choisit pas postfix ou qmail, il exprime un besoin et on y
réponds par la solution de son choix la plus adaptée) et faire de
l'infogérance de machines tierces (comme on en fait sur d'autres
hébergeurs et/ou infrastructure) qui se fait plus à la carte. Les
infogérances "totales" exprimées plus haut concernaient bien
évidemment que *nos* serveurs, ceux que l'on fournit et que nous
installons de "bout en bout" pour nos clients.

amicalement,

--
Christophe Casalegno | Groupe Digital Network | UIN : 153305055
http://www.dns-fr.com | http://www.intelink.info
TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX
Technical director | Security Intrusion techniques & infowar
specialist.

1Mbps vendu au client pour 20 euro ne peut pas etre provisionné sur 4
transitaires (ou alors, faut que tu m'explique comment tu fais pour
avoir le Mbps a 5 euro chez Telia :))

1) C'est faux :) Il est parfaitement possible d'avoir une garantie de
provisionnement de 400 Mb/s par exemple tout en achetant 250 Mb/s,
attention je ne parle pas de commit et de burst mais bien de transit
garanti contractuellement.

2) Ton calcul ne tient pas compte des coûts fixes d'infrastructure :
yu achetes, par exemple 4x500 Mb/s sur 4 opérateur, tu l'inclus dans
ton coût de base d'infrastructure, tu as donc 500 Mb/s de provisionné
sur l'ensemble de tes opérateurs. Ceci peut parfaitement être financé
par exemple, par une seule branche de services de la société
concernée, comme la sécurité par exemple. Il y a encore d'autres
solutions, comme d'acheter le Mb/s à 5 euro :) cependant, les
fournisseurs concernés n'aimeraient pas voir trainer ce genre
d'informations sur les forums :) Enfin, pour peu que tu es 4 Gb/s de
provisionné en coût global, et que tu t'en es vendu que 1 Gb/s, il te
reste beaucoup de marge, qui n'a rien de statistique :)

Donc c'est de la mutualisation .. "je me sers d'une branche de ma boite
ultra beneficiaire pour éponger une branche qui vend a perte"

Ou comment payer quelqu'un un salaire fixe (100 Euro par mois) en lui
demandant de faire un nombre d'heures illimitées.

Du tout là encore, tu fais un mauvais calcul. Ce n'est nullement de la
statistique, il ne faut pas oublier que les opérations d'infogérance
ne s'appliquent qu'à un certain nombre de distributions/logiciels/
serveurs "supportés". Il ne faut pas non plus oublier que tu raisonnes
encore en mono-activités. Quand tu as une équipe payée à plein temps
pour faire de la veille 24/24 et 7/7, et dont l'activité n'occupe que
10 à 15 % du temps de travail réel (tempx fixe), tu te retrouve avec +
de 80% de temps disponible sur une seconde équipe. En clair, sur ces
80% de temps tu fais 100% de marge, puisque cela ne te coute rien. En
même temps, on ne va pas dévoiler toutes les méthodes (il y en a
beaucoup), on est pas là non plus pour donner des solutions aux
concurrents/confrères :)

Les 80% de temps ne coutent pas rien ... essaie en ne payant pas les
salariés pendant qu'ils ne foutent rien, tu verra ce que tu économise :)

Encore donc, politique de tarif décorellée des couts ... ca ne
fonctionne qu'un temps.

C'est de la statistique .. aujourd'hui, ca marche .. Demain, une
nouvelle techno ultra a la mode sors mais ingérable en un temps tres
court et paf, le chateau de carte s'effondre.

Nouvelle techno ultra à la mode = non supportée. Tout ce qui est fait
doit être validé par la classique chaine dev/recette/prod, c'est la
contrepartie de la stabilité et de la sécurité.

Mais ca ne rentre pas dans ce qu'un client lambda apellerai "infogérance
totale" .. lui, il a un besoin, il l'exprime .. je vois bien la tete de
mes clients si je leur disait demain "ah non, désolé, horde c'est
vraiment la merde a maintenir, on l'a viré de votre machine" :)

Enfin pour les mises à
jour que tu citais dans un autre post, il n'y a heureusement pas à
vérifier que les 300 sites du clients fonctionnent correctement, là
aussi on applique des procédés, et, en cas de problème (moins d'un cas
sur 1000) un downgrade se fait en moins de 40 secondes.

Rhalala .. quand j'serais chomeur, faudra que j'aille me faire embaucher
dans ces boites ou tout est automatique et ou les admins n'ont plus qu'a
fumer leurs clopes en regardant le café couler :)