Bien sûr, ce cas d'usage ne s'applique qu'à CozyCloud, qui a mis les moyens de faire une belle réplication. Pour l'artisan d'élagage qui a son site à un seul endroit, géré par un webmestre indépendant qui fait ça sur son temps libre, c'est pas pareil…
J'encouragerai bien l’artisan à avoir un backup chez lui, un autre dans son local commercial (s'il est dissocié).
Et à prendre un datacenter à l'autre bout de la france, surtout pas celui d'a côté.
Ceci permettant de se rapprocher de l'excellente analyse de ce lien.
Pour un webmestre indépendant : le coût de l'indispo est quasi nul, il a ses backup (chez lui! Ou du moins pas chez le même hébergeur) et remet en ligne sur une autre machine en pas très longtemps (être webmestre indépendant ne légitime pas faire de la merde).
Perso, ce qui me fait rire (jaune) sont les gens qui disent avoir perdu des milliers d'Euros du fait de la panne : si tu as des milliers d'Euros en jeu, ben tu as 2 serveurs sur 2 hébergeurs (ou DC si tu penses ton hébergeur assez fiable) différents, mini et tu peux te le permettre, tu as des milliers d'Euros qui transitent et un serveur c'est quelques €/mois… (l'admin un peu plus mais pas trop non plus pour ce 2ème serveur).
Bref, il faut arrêter de dire que la réplication ça coûte cher, ce n'est pas le cas, et un webmestre indépendant peut largement le faire, de nos jours les machines coûtent quasi rien et les logiciels (DB etc) sont assez prévu pour. Plus cher oui, mais pas beaucoup, si c'est trop cher c'est que l'indispo de quelques semaine ne te dérange pas donc pas un problème non plus.
Perso, ce qui me fait rire (jaune) sont les gens qui disent avoir perdu des milliers d'Euros du fait de la panne
OVH a mis combien de temps à rendre les backups disponible (quand ils ne les ont pas simplement perdu) ?
Je suis sûr que les clients PCC (qui est un service entièrement géré par OVH, backups compris) ont pu perdre « des milliers d’euros » rien qu’en temps de rétablissement.
Tu as tout à fait raison sur le fait que cela ne correspond pas à l'attente que les gens ont.
Après, une autre chose qui me paraît sûre, c'est que le Disaster Recovery Plan étant pudiquement traduit "Plan de Reprise d'Activité (après incident)", cela n'aidait probablement pas à imaginer le pire. Un désastre, ce n'est pas perdre quelques disques ou une paire de VM.
Maintenant, on sait qu'un désastre, c'est perdre plusieurs centres de données (certes, géographiquement au même endroit) avec une partie des sauvegardes et n'avoir qu'un accès erratique à ta console d'administration. Tout ça en quelques instants et pour de nombreuses heures.
Le plan de reprise d’activité (disaster recovery plan) est sensé être ajusté à ton besoin personnel. L’évaluation de l’adéquation des moyens aux besoins a pour but de déterminer la maturité du système d’information.
Si perdre quelques disques ou une parie de VM met en péril ton activité, alors c’est un désastre.
L’évaluation du désastre est relatif à ce que toi ou ton entreprise subissent personnellement, le plan de reprise d’activité (ou disaster recovery plan) devant donc être personnellement adapté à ce qui serait un désastre pour toi ou pour ton activité.
Par exemple un étudiant qui rate son train pour l’examen d’un diplôme, ça n’est pas comparable à l’éruption du Vésuve, et à l’échelle de la société ça n’aura probablement aucun impact, mais pour cet étudiant le reste de sa vie pourra être impactée négativement et de manière irrémédiable. Donc, oui, ce serait un désastre alors que ce ne serait qu’un train raté. C’est pourquoi cet étudiant par exemple préférera investir dans la location d’une chambre d’hôtel ou d’aller squatter chez des copains pour se donner le temps de prendre le train suivant si quelque chose d’imprévu se produit.
Disaster Recovery Plan et Plan de Reprise d’Activité, ce sont des termes du métier, OVH n’a pas inventé (ni traduit) ça. Et si quelqu’un a besoin de reprendre son activité, c’est qu’elle est interrompue, et si elle est interrompue alors qu’elle est sensée ne pas l’être (d’où la « reprise d’activité »), cette interruption est nécessairement l’effet de quelque chose qui est désastreux pour la continuité de l’activité.
ce commentaire est sous licence cc by 4 et précédentes
Au contraire, la problématique est la même quelque soit la taille de l'entreprise. Ce qui change c'est le temps de remise en service que tu es prêt à accepter en cas de panne.
Si le problème n'est que de la réplication des données, c'est relativement simple et pas cher[1]. Si le problème c'est d'avoir de la haute disponibilité (rare chez un artisan), là c'est différent car on veut une infra haute dispo.
[1] à 5€ le TB par mois, ça fait le prix d'un 6 pack de Goudale 25cl ou un 33cl de Heineken en bouteille chez Carrefour.
OVH n'est pas low cost. Ce qui est low cost, c'est de mettre des Kimsufi dans le même emplacement que ses propres serveurs dédiés haut de gamme (dans le même emplacement que les onduleurs…).
On lâchait plus de 1 000 EUR par mois chez OVH, avec des engagements sur 2 ans sur des machines dédiées (5), ça ne me posait pas de problème. Mais la communication d'OVH suite à l’incident, à coup de "Ah, maintenant c'est le PRA qu'il faut mettre en place les rigolos", ou "C'est de la faute du client si il perd des données", ou "C'est l'intervenant extérieur" … ça m'énerve. J'aurais bien aimé avoir une communication axée sur des faits : savoir ce qu'il s'est réellement passé, ce qui a défailli… Ok pour faire des datacenters économiques, qui se refroidisse par convection naturelle, peut-être plus écologique, ils ont certainement plein d'arguments, c'est ça que j'aurais aimé entendre de leur part.
Si on veut rester en France, je suis persuadé qu'il y a d'autres fournisseurs proposant un service plus respectueux de leurs clients, avec une qualité équivalente.
Si on veut rester en France, je suis persuadé qu'il y a d'autres fournisseurs proposant un service plus respectueux de leurs clients, avec une qualité équivalente.
Juste un truc : avec OVH tu as ce pour quoi tu as payé. Si tu veux mieux, ça te coutera plus cher. C'est la vie. De plus, un autre fournisseur ne te dispensera pas de mettre en place un PRA ou autre solution de rempli. Alors là, soit tu le fais toi-même, soit tu le fait faire par ton provider. Mais d'un sens comme dans l'autre ça aura un cout.
En parlant de Kimsufi et de low cost, Online/Scaleway propose généralement des dedibox au prix des Kimsufi, mais avec un service qui répond dans la minute et compétent avec ça (j’ai souvent eu des problème de compétence avec des interlocuteurs OVH et des attentes assez longue, même en dehors de leur offre Kimsufi). Concernant le matériel, par contre, c’est kif-kif.
Cela dit je ne recommande pas Scaleway plus qu’OVH pour une raison très simple, il est prudent de mettre ses données dans deux endroits géographiques différents mais aussi chez deux fournisseurs différents, si jamais l’incident serait administratif par exemple.
Ainsi j’ai tendance à recommander de mettre les serveurs chez l’un et les sauvegardes sur l’autre, et si la disponibilité des données est aussi important que la conservation des données, de répartir les services chez l’un et l’autre. Donc préferer OVH sur Scaleway ou l’inverse n’a pas de sens, il y a un besoin pour les deux. Ça n’empêche que toute amélioration chez OVH est plus que bienvenue, justement parce que préférer l’un à l’autre n’a pas de sens.
ce commentaire est sous licence cc by 4 et précédentes
Posté par totof2000 .
Évalué à 9.
Dernière modification le 29 avril 2021 à 13:23.
Le RAID (initialement Redundant Array of Inexpensive Disks ) est une technologie de répartition des données sur disques avec gestion logicielle (même si on peut avoir des contrôleurs matériels) permettant d'assurer une haute dispo et une amélioration de perfs dans certains cas avec des disques "pas cher". Mais c n'estpas parce qu'on a un RAID qu'on ne doit pas avoir de sauvegardes …. et de plan de test restauration de données, de crash test, etc …
Est-ce qu'on va cesser d'utiliser le RAID parce qu'à un instant T on a perdu l'ensemble des disques qui constituent notre volume ? Je ne pense pas …. Parce que même si on utilise pas le RAID, l'autre solution ne sera pas 100% infaillible, et nécessitera de toute façon de mettre en place un système de sauvegarde (pour rappel, le RAID ne se substitue pas aux sauvgardes …).
Après, si, lorqsque tu entends qu'un datacenter est en feu, tu attends le feu vert de tn fournisseur pour activer le PRA, il y a potentiellement un problème si tu as besoin de très haute dispo. Dans ce cas, soit tu as ton service en actif/actif, ou alors tu anticipes, quitte à activer ton PRA pour rien … PRA que tu es censé tester régulièrement. Et si tu ne sais pas ou ne veut pas faire, il faut déléguer à un presta (potentiellement OVH), avec les contrats qui vont bien.
(je ne dis pas qu'OVH est complêtement clean dans l'affaire, on trouvera certainement des failles chez eux, par contre beaucoup de critiques émises sont du même ordre que celles qu'on pourrait faire à un assureur qui ne rembourse pas les dégats causés sur une voiture pour un accident responsable alors qu'on est au tiers, ou alors parce que la franchise est trop élevée, alors que celle-ci aparaît clairement dans les contrats).
maintenant qu'ils ont perdu un datacenter dans un incendie ovh à acquis de l'expérience et ils vont apprendre de ce accident.
Je pense qu'ils vont venir plus fiable.
Après ceux qui ont mis en danger leur business moi j'ai un principe, on fait pas des économies de bout de chandelle sur ce qui nous fait vivre.
Il est inconcevable que en 2021 certain soit étranger à la notion de sauvegarde.
Et la, a la lecture des ces articles de blog (il y en a un autre du meme acabit) défendant bec et ongles OVH, on se souvient que Cozy a signe un partenariat avec OVH, pour proposer des hébergements cle en main: https://www.ovh.com/fr/cloud-apps/cozy.xml
Bref, je sais pas quel est la nature de leur relation avec OVH, mais il me semble que ca va au dela de la simple fourniture de service. Et que cet activisme a defendre OVH consiste principalement a rassurer leurs propres clients qui s’inquiètent de la securite de leurs données.
Tu pose la question légitime de nos motivations, de notre "biais".
Quelques éléments :
a) Dans l'essentiel tu as raison : nous avons écrit cet article pour rassurer. Déjà nous rassurer nous même, refaire le point sur notre stratégie. Se remettre en question, même quand l'incident est bien géré, c'est la base. Ensuite pour rassurer nos utilisateurs et clients qui sont légitimement inquiets suite à cet accident majeur. Etre transparent sur notre stratégie nous parait être la bonne approche.
b) Pour ce qui est de "défendre bec et ongle OVH" : nous insistons très explicitement sur leur niveau de service qui n'est pas le meilleur du marché et sur la fréquence des incidents que l'on rencontre chez eux. Les noms d'oiseaux fusent régulièrement à leur encontre sur notre messagerie interne…
D'autre part, on a essayé d'étayer précisément nos arguments : vraiment du "bec et ongle" ?
c) "quel est la nature de leur relation avec OVH" : nous sommes :
i) client : comme tu le pointe dans ton post, notre offre publique est hébergée chez eux, OVH est notre fournisseur. De là à parler de "partenariat pour proposer des hébergements"…
ii) membre d'un même écosystème. Car oui, comme nombre d'acteur de l'écosystème numérique français, nous avons intérêts à ce qu'il existe en France de bons hébergeurs (OVH ou d'autres). Les raisons sont listées dans l'article : emploi et développement des compétences, reconnaissance d'une filière numérique d'excellence, impôts payés en France…
iii) nous avons bien sûr des connaissances qui travaillent chez eux (ça reste un petit monde), ce qui facilite les interactions (également cité dans l'article).
iv) nous avons fait du "lobbying" ensemble, autour du RGPD, ça remonte à quelques années maintenant, et honnêtement on a fait un bon boulot à l'époque, notamment sur le droit à la portabilité (qui reste imparfait mais c'est une autre histoire…)
Et rien de plus : si tu savais comme depuis des années j'essaye d'obtenir des remises sur leur tarif catalogue… Perso je trouve assez anormal qu'ils n'aient jamais fait un geste commercial envers nous (car mensuellement on leur fait un beau virement…).
D'ailleurs on conclut l'article sur "ce n'est pas un incendie qui nous fera changer d'avis" : c'est vrai car nous sommes organisés pour (mais bon, faut pas non plus tenter le diable…), mais si leur tarif ou réseau devaient se dégrader par rapport à la concurrence, là pour le coup l'article que l'on écrira sera "Comment on a quitté OVH" :-)
Posté par wilk .
Évalué à 3.
Dernière modification le 30 avril 2021 à 12:29.
Je ne comprends trop l'intérêt de calculer en terme de datacenter. Autant qu'un datacenter parte en fumé c'est assez rare, autant qu'une machine ou encore mieux qu'une vm parte en fumée ça arrive tous les jours. Et pour l'utilisateur c'est ce qui compte, peu importe que les serveurs d'à côté partent en fumée aussi, il en suffit d'un et que ce soit le notre…
L'article met bien l'accent sur le fait de gérer plus ou moins soit-même la redondance.
Il me semble que c'est à ce niveau qu'il faut faire des comparaisons et quitter ou non OVH. C'est à dire dans les services disponibles sur l'infrastructure proposée pour pouvoir gérer cette redondance.
Hors c'est bien à ce niveau que le leader distance complètement les suivants, ça me semble même sans commune mesure.
Eventuellement on peut palier à ça avec des compétences internes, mais on ne compare plus du tout la même chose et encore moins le coût final.
En tout cas bravo à Cozy pour avoir réussi cet exploit, et on peut préciser "en particulier chez OVH" ! Chez l'autre il n'y aurait eu aucun mérite !
edit: pour ceux qui voudraient se rendre compte, regardez les possibilités d'une BDD Aurora par ex, et imaginez faire la même chose chez OVH (ou autres)…
C'est du PostgreSQL ou MySQL. On peut faire exactement la même chose chez soit ou chez OVH mais c'est un sacré boulot et on se rend compte que ce que l'on paye ça n'est pas seulement la probabilité que ça prenne feu ou pas mais le service fourni tout autour au cas où ça prendrait feu à un endroit.
# Cas d'usage
Posté par Glandos . Évalué à 10.
Bien sûr, ce cas d'usage ne s'applique qu'à CozyCloud, qui a mis les moyens de faire une belle réplication. Pour l'artisan d'élagage qui a son site à un seul endroit, géré par un webmestre indépendant qui fait ça sur son temps libre, c'est pas pareil…
[^] # Re: Cas d'usage
Posté par blobmaster . Évalué à 5.
J'encouragerai bien l’artisan à avoir un backup chez lui, un autre dans son local commercial (s'il est dissocié).
Et à prendre un datacenter à l'autre bout de la france, surtout pas celui d'a côté.
Ceci permettant de se rapprocher de l'excellente analyse de ce lien.
[^] # Re: Cas d'usage
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 4.
Parce que, de toute façon, quel que soit l'hébergeur, les risques ne sont pas à zéro. Donc, si c'est essentiel, il faut une solution de repli.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Cas d'usage
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 29 avril 2021 à 11:37.
Pour un webmestre indépendant : le coût de l'indispo est quasi nul, il a ses backup (chez lui! Ou du moins pas chez le même hébergeur) et remet en ligne sur une autre machine en pas très longtemps (être webmestre indépendant ne légitime pas faire de la merde).
Perso, ce qui me fait rire (jaune) sont les gens qui disent avoir perdu des milliers d'Euros du fait de la panne : si tu as des milliers d'Euros en jeu, ben tu as 2 serveurs sur 2 hébergeurs (ou DC si tu penses ton hébergeur assez fiable) différents, mini et tu peux te le permettre, tu as des milliers d'Euros qui transitent et un serveur c'est quelques €/mois… (l'admin un peu plus mais pas trop non plus pour ce 2ème serveur).
Bref, il faut arrêter de dire que la réplication ça coûte cher, ce n'est pas le cas, et un webmestre indépendant peut largement le faire, de nos jours les machines coûtent quasi rien et les logiciels (DB etc) sont assez prévu pour. Plus cher oui, mais pas beaucoup, si c'est trop cher c'est que l'indispo de quelques semaine ne te dérange pas donc pas un problème non plus.
[^] # Re: Cas d'usage
Posté par Anonyme . Évalué à 3.
OVH a mis combien de temps à rendre les backups disponible (quand ils ne les ont pas simplement perdu) ?
Je suis sûr que les clients PCC (qui est un service entièrement géré par OVH, backups compris) ont pu perdre « des milliers d’euros » rien qu’en temps de rétablissement.
[^] # Re: Cas d'usage
Posté par bbo . Évalué à -1.
Tu as tout à fait raison sur le fait que cela ne correspond pas à l'attente que les gens ont.
Après, une autre chose qui me paraît sûre, c'est que le Disaster Recovery Plan étant pudiquement traduit "Plan de Reprise d'Activité (après incident)", cela n'aidait probablement pas à imaginer le pire. Un désastre, ce n'est pas perdre quelques disques ou une paire de VM.
Maintenant, on sait qu'un désastre, c'est perdre plusieurs centres de données (certes, géographiquement au même endroit) avec une partie des sauvegardes et n'avoir qu'un accès erratique à ta console d'administration. Tout ça en quelques instants et pour de nombreuses heures.
[^] # Re: Cas d'usage
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 10 mai 2021 à 09:50.
Le plan de reprise d’activité (disaster recovery plan) est sensé être ajusté à ton besoin personnel. L’évaluation de l’adéquation des moyens aux besoins a pour but de déterminer la maturité du système d’information.
Si perdre quelques disques ou une parie de VM met en péril ton activité, alors c’est un désastre.
L’évaluation du désastre est relatif à ce que toi ou ton entreprise subissent personnellement, le plan de reprise d’activité (ou disaster recovery plan) devant donc être personnellement adapté à ce qui serait un désastre pour toi ou pour ton activité.
Par exemple un étudiant qui rate son train pour l’examen d’un diplôme, ça n’est pas comparable à l’éruption du Vésuve, et à l’échelle de la société ça n’aura probablement aucun impact, mais pour cet étudiant le reste de sa vie pourra être impactée négativement et de manière irrémédiable. Donc, oui, ce serait un désastre alors que ce ne serait qu’un train raté. C’est pourquoi cet étudiant par exemple préférera investir dans la location d’une chambre d’hôtel ou d’aller squatter chez des copains pour se donner le temps de prendre le train suivant si quelque chose d’imprévu se produit.
Disaster Recovery Plan et Plan de Reprise d’Activité, ce sont des termes du métier, OVH n’a pas inventé (ni traduit) ça. Et si quelqu’un a besoin de reprendre son activité, c’est qu’elle est interrompue, et si elle est interrompue alors qu’elle est sensée ne pas l’être (d’où la « reprise d’activité »), cette interruption est nécessairement l’effet de quelque chose qui est désastreux pour la continuité de l’activité.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Cas d'usage
Posté par Psychofox (Mastodon) . Évalué à 8.
Au contraire, la problématique est la même quelque soit la taille de l'entreprise. Ce qui change c'est le temps de remise en service que tu es prêt à accepter en cas de panne.
Si le problème n'est que de la réplication des données, c'est relativement simple et pas cher[1]. Si le problème c'est d'avoir de la haute disponibilité (rare chez un artisan), là c'est différent car on veut une infra haute dispo.
[1] à 5€ le TB par mois, ça fait le prix d'un 6 pack de Goudale 25cl ou un 33cl de Heineken en bouteille chez Carrefour.
# OVH High Cost
Posté par YBoy360 (site web personnel) . Évalué à 0.
OVH n'est pas low cost. Ce qui est low cost, c'est de mettre des Kimsufi dans le même emplacement que ses propres serveurs dédiés haut de gamme (dans le même emplacement que les onduleurs…).
On lâchait plus de 1 000 EUR par mois chez OVH, avec des engagements sur 2 ans sur des machines dédiées (5), ça ne me posait pas de problème. Mais la communication d'OVH suite à l’incident, à coup de "Ah, maintenant c'est le PRA qu'il faut mettre en place les rigolos", ou "C'est de la faute du client si il perd des données", ou "C'est l'intervenant extérieur" … ça m'énerve. J'aurais bien aimé avoir une communication axée sur des faits : savoir ce qu'il s'est réellement passé, ce qui a défailli… Ok pour faire des datacenters économiques, qui se refroidisse par convection naturelle, peut-être plus écologique, ils ont certainement plein d'arguments, c'est ça que j'aurais aimé entendre de leur part.
Si on veut rester en France, je suis persuadé qu'il y a d'autres fournisseurs proposant un service plus respectueux de leurs clients, avec une qualité équivalente.
[^] # Re: OVH High Cost
Posté par totof2000 . Évalué à 8.
Juste un truc : avec OVH tu as ce pour quoi tu as payé. Si tu veux mieux, ça te coutera plus cher. C'est la vie. De plus, un autre fournisseur ne te dispensera pas de mettre en place un PRA ou autre solution de rempli. Alors là, soit tu le fais toi-même, soit tu le fait faire par ton provider. Mais d'un sens comme dans l'autre ça aura un cout.
[^] # Re: OVH High Cost
Posté par Jean-Baptiste Faure . Évalué à 6.
Comment veux-tu qu'ils le sachent tant que les enquêteurs n'ont pas rendu leurs conclusions ?
[^] # Re: OVH High Cost
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
En parlant de Kimsufi et de low cost, Online/Scaleway propose généralement des dedibox au prix des Kimsufi, mais avec un service qui répond dans la minute et compétent avec ça (j’ai souvent eu des problème de compétence avec des interlocuteurs OVH et des attentes assez longue, même en dehors de leur offre Kimsufi). Concernant le matériel, par contre, c’est kif-kif.
Cela dit je ne recommande pas Scaleway plus qu’OVH pour une raison très simple, il est prudent de mettre ses données dans deux endroits géographiques différents mais aussi chez deux fournisseurs différents, si jamais l’incident serait administratif par exemple.
Ainsi j’ai tendance à recommander de mettre les serveurs chez l’un et les sauvegardes sur l’autre, et si la disponibilité des données est aussi important que la conservation des données, de répartir les services chez l’un et l’autre. Donc préferer OVH sur Scaleway ou l’inverse n’a pas de sens, il y a un besoin pour les deux. Ça n’empêche que toute amélioration chez OVH est plus que bienvenue, justement parce que préférer l’un à l’autre n’a pas de sens.
ce commentaire est sous licence cc by 4 et précédentes
# Ca me fait penser aux problématiques que le RAID, mais à une autre échelle ....
Posté par totof2000 . Évalué à 9. Dernière modification le 29 avril 2021 à 13:23.
Le RAID (initialement Redundant Array of Inexpensive Disks ) est une technologie de répartition des données sur disques avec gestion logicielle (même si on peut avoir des contrôleurs matériels) permettant d'assurer une haute dispo et une amélioration de perfs dans certains cas avec des disques "pas cher". Mais c n'estpas parce qu'on a un RAID qu'on ne doit pas avoir de sauvegardes …. et de plan de test restauration de données, de crash test, etc …
Est-ce qu'on va cesser d'utiliser le RAID parce qu'à un instant T on a perdu l'ensemble des disques qui constituent notre volume ? Je ne pense pas …. Parce que même si on utilise pas le RAID, l'autre solution ne sera pas 100% infaillible, et nécessitera de toute façon de mettre en place un système de sauvegarde (pour rappel, le RAID ne se substitue pas aux sauvgardes …).
Après, si, lorqsque tu entends qu'un datacenter est en feu, tu attends le feu vert de tn fournisseur pour activer le PRA, il y a potentiellement un problème si tu as besoin de très haute dispo. Dans ce cas, soit tu as ton service en actif/actif, ou alors tu anticipes, quitte à activer ton PRA pour rien … PRA que tu es censé tester régulièrement. Et si tu ne sais pas ou ne veut pas faire, il faut déléguer à un presta (potentiellement OVH), avec les contrats qui vont bien.
(je ne dis pas qu'OVH est complêtement clean dans l'affaire, on trouvera certainement des failles chez eux, par contre beaucoup de critiques émises sont du même ordre que celles qu'on pourrait faire à un assureur qui ne rembourse pas les dégats causés sur une voiture pour un accident responsable alors qu'on est au tiers, ou alors parce que la franchise est trop élevée, alors que celle-ci aparaît clairement dans les contrats).
# non
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 8.
maintenant qu'ils ont perdu un datacenter dans un incendie ovh à acquis de l'expérience et ils vont apprendre de ce accident.
Je pense qu'ils vont venir plus fiable.
Après ceux qui ont mis en danger leur business moi j'ai un principe, on fait pas des économies de bout de chandelle sur ce qui nous fait vivre.
Il est inconcevable que en 2021 certain soit étranger à la notion de sauvegarde.
# Partenariat
Posté par flagos . Évalué à 10.
Et la, a la lecture des ces articles de blog (il y en a un autre du meme acabit) défendant bec et ongles OVH, on se souvient que Cozy a signe un partenariat avec OVH, pour proposer des hébergements cle en main: https://www.ovh.com/fr/cloud-apps/cozy.xml
Ils ont également leur offre cloud qui est base sur les serveurs d'ovh https://www.nextinpact.com/article/27926/105762-cozy-cloud-ouvert-a-tous-on-a-teste-plateforme-stockage-et-reprise-en-main-donnees
Bref, je sais pas quel est la nature de leur relation avec OVH, mais il me semble que ca va au dela de la simple fourniture de service. Et que cet activisme a defendre OVH consiste principalement a rassurer leurs propres clients qui s’inquiètent de la securite de leurs données.
A prendre avec une pincee de sel donc.
[^] # Re: Partenariat
Posté par Benibur (site web personnel) . Évalué à 10.
[note : je suis un des auteurs de l'article]
Tu pose la question légitime de nos motivations, de notre "biais".
Quelques éléments :
a) Dans l'essentiel tu as raison : nous avons écrit cet article pour rassurer. Déjà nous rassurer nous même, refaire le point sur notre stratégie. Se remettre en question, même quand l'incident est bien géré, c'est la base. Ensuite pour rassurer nos utilisateurs et clients qui sont légitimement inquiets suite à cet accident majeur. Etre transparent sur notre stratégie nous parait être la bonne approche.
b) Pour ce qui est de "défendre bec et ongle OVH" : nous insistons très explicitement sur leur niveau de service qui n'est pas le meilleur du marché et sur la fréquence des incidents que l'on rencontre chez eux. Les noms d'oiseaux fusent régulièrement à leur encontre sur notre messagerie interne…
D'autre part, on a essayé d'étayer précisément nos arguments : vraiment du "bec et ongle" ?
c) "quel est la nature de leur relation avec OVH" : nous sommes :
i) client : comme tu le pointe dans ton post, notre offre publique est hébergée chez eux, OVH est notre fournisseur. De là à parler de "partenariat pour proposer des hébergements"…
ii) membre d'un même écosystème. Car oui, comme nombre d'acteur de l'écosystème numérique français, nous avons intérêts à ce qu'il existe en France de bons hébergeurs (OVH ou d'autres). Les raisons sont listées dans l'article : emploi et développement des compétences, reconnaissance d'une filière numérique d'excellence, impôts payés en France…
iii) nous avons bien sûr des connaissances qui travaillent chez eux (ça reste un petit monde), ce qui facilite les interactions (également cité dans l'article).
iv) nous avons fait du "lobbying" ensemble, autour du RGPD, ça remonte à quelques années maintenant, et honnêtement on a fait un bon boulot à l'époque, notamment sur le droit à la portabilité (qui reste imparfait mais c'est une autre histoire…)
Et rien de plus : si tu savais comme depuis des années j'essaye d'obtenir des remises sur leur tarif catalogue… Perso je trouve assez anormal qu'ils n'aient jamais fait un geste commercial envers nous (car mensuellement on leur fait un beau virement…).
D'ailleurs on conclut l'article sur "ce n'est pas un incendie qui nous fera changer d'avis" : c'est vrai car nous sommes organisés pour (mais bon, faut pas non plus tenter le diable…), mais si leur tarif ou réseau devaient se dégrader par rapport à la concurrence, là pour le coup l'article que l'on écrira sera "Comment on a quitté OVH" :-)
Bonne journée, Benjamin
# Le service
Posté par wilk . Évalué à 3. Dernière modification le 30 avril 2021 à 12:29.
Je ne comprends trop l'intérêt de calculer en terme de datacenter. Autant qu'un datacenter parte en fumé c'est assez rare, autant qu'une machine ou encore mieux qu'une vm parte en fumée ça arrive tous les jours. Et pour l'utilisateur c'est ce qui compte, peu importe que les serveurs d'à côté partent en fumée aussi, il en suffit d'un et que ce soit le notre…
L'article met bien l'accent sur le fait de gérer plus ou moins soit-même la redondance.
Il me semble que c'est à ce niveau qu'il faut faire des comparaisons et quitter ou non OVH. C'est à dire dans les services disponibles sur l'infrastructure proposée pour pouvoir gérer cette redondance.
Hors c'est bien à ce niveau que le leader distance complètement les suivants, ça me semble même sans commune mesure.
Eventuellement on peut palier à ça avec des compétences internes, mais on ne compare plus du tout la même chose et encore moins le coût final.
En tout cas bravo à Cozy pour avoir réussi cet exploit, et on peut préciser "en particulier chez OVH" ! Chez l'autre il n'y aurait eu aucun mérite !
edit: pour ceux qui voudraient se rendre compte, regardez les possibilités d'une BDD Aurora par ex, et imaginez faire la même chose chez OVH (ou autres)…
[^] # Re: Le service
Posté par Pol' uX (site web personnel) . Évalué à 2.
Quel possibilité on a de l'installer chez soi ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Le service
Posté par wilk . Évalué à 2.
C'est du PostgreSQL ou MySQL. On peut faire exactement la même chose chez soit ou chez OVH mais c'est un sacré boulot et on se rend compte que ce que l'on paye ça n'est pas seulement la probabilité que ça prenne feu ou pas mais le service fourni tout autour au cas où ça prendrait feu à un endroit.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.