Archives pour l'étiquette Mondadori France

Départ et management des erreurs

Départ

La direction technique digital et de la DSI de Mondadori à trouvé un moyen sympathique de me remercier à la veille de mon départ de l’entreprise (oui je change de crèmerie). Ce remerciement à pris  la forme d’un MOTD placé sur tout les serveurs. Merci, c’est touchant

Sécateur

Pourquoi un sécateur ?

Justement c’est là que c’est touchant.

J’ai pris l’habitude de faire remettre un sécateur rouge à la personne ayant fait la dernière boulette au standup meeting scrum du matin. Façon totem de « Koh Lanta », tu a l’immunité mais explique nous ton erreur que nous en profitions tous. Charge au détenteur de le remettre au prochain maladroit, toujours durant un standup meeting.

  • Cela permet de casser le cycle à la con : erreur -> engueulade -> dissimulation d’erreur -> stress
  • Quand tu fais une erreur tu a tout intérêt à toi même réclamer le sécateur et ainsi rentrer dans une démarche positive ou de fautif de passe au statut de celui qui à une expérience à apporter aux autres. C’est quand même plus valorisant pour soi et plus bénéfique pour le produit.
  • Autre avantage, tu rentres de vacances, tu vois que X possède le sécateur c’est donc lui qu’il faut interviewer pour avoir un retour d’expérience de ce qui est vraiment notable.
  • La critique fait pas ces paires sur son erreur est parfois plus facile à entendre que celle faite par sa hiérarchie.
  • Si l’erreur ce répète chacun est à même de le voir et de le signaler, même en cas d’absence de la hiérarchie. La vision globale est possible par tous.
  • Moins de jeux politicien dans les réunions car il n’est plus possible d’agiter les casseroles de quelqu’un et de le culpabiliser.

Je n’ai pas eu cette idée ex nihilo mais en lisant les deux tomes de « Les décisions absurdes: Sociologie des erreurs radicales et persistantes » de Christian Morel.  L’auteur y explique que l’impunité des erreurs est utilisé dans le monde de l’aviation et la sûreté nucléaire afin d’encourager leurs analyses et éviter les dissimulations, c’est comme cela que les procédures et la réglementation avance.

Attention à ne pas confondre erreur et faute. Cette dernière appel une réponse ferme de la hiérarchie.

Oui mais pourquoi le sécateur et pas un entonnoir ou une noix de coco ?

Un jour Kathryl m’a offert un sécateur car j’avais l’habitude de passer les développeurs à la question pour comprendre d’où venait l’erreur. Mon coté un peu trop insistant lui à fait penser que pour l’étape suivante j’aurais besoin d’un sécateur pour leur couper une phalange si besoin.

Moi et mon sécateur

Vous avez compris que j’ai moi même admis ma propre erreur et que la « coercition » pour le management des erreurs n’est pas la solution.

Preuve que les développeurs de mondadori ne m’en veule pas trop ils m’ont offert ceci

Hachette

Site web média et presse : Le stockage et l’espace disque

Question matutinal

Si je reformule les deux interrogations  du matin je poserais la question suivante : Quel est l’impact financier le plus important du stockage (news et archive) pour un site web de presse ou média. Est-ce l’espace disque pour le stockage lui même ou la bande passante pour exploiter ce qui à été stocké ?

Je n’ai pas le temps ni l’envie de faire des statistiques, des benchmarck ou de compiler des données. Je vais donc donner mon humble avis en me basant sur mes souvenirs de Prisma-Presse, sur mon actualité chez Mondadori et plus largement sur mon expérience.

L’espace disque

L’espace disque brut en 2014 n’est plus un problème. Je parle bien d’espace disque brut, c’est à dire le disque lui même et pas forcément les moyens de l’exploiter.

Sur Amazon Web Service, qui de par sa position de leader donne la température, 13To de disque magnétique de performance moyen coût légèrement moins de 800$ HT par mois. Chez OVH, leader en France, un NAS incluant les moyens de partager l’espace disque et de l’administrer (cif / nfs / etc) c’est 1000€ HT par mois

13To c’est à peu moins d’un tiers de l’espace disque total nécessaire à un groupe presse de la taille de Prisma Presse ou Mondadori pour faire fonctionner l’ensemble des services.

On vois que les coûts d’espace disque brut sans être négligeable ne sont pas insurmontable.

La bande passante

La bande passante en 2014 n’est pas un problème sauf ponctuellement et encore.

Si ont rependre comme référence Amazon Web Service , OVH ou d’autre (ikoula, Oxalid, iliad etc..) vous aurez à votre disposition des gros tuyaux capable de compenser le pire des complexes phalliques du plus minable des machistes. Bref de l’énorme.

Sur Amazon Web Service, sans optimisation des coûts, 10Go de transfert vers l’internet par jour vous coûtera  35$ par mois. C’est un peu près le volume de donnée pour trois sites web féminin majeur français (je ne cite personne)

Ponctuellement, un scoop, un buzz, un événement peux engendrer une surcharge à l’entré du tuyau :

  • Si vous êtes encore dans une infrastructure dédier et cantonné dans un data center en général la couche firewall et / ou répartiteur de charge est taillé pour assurer à 120 ou 130% de consommation courante.  Payé 30% de plus de capacité et ne pas l’utiliser 99% temps est, financièrement, une sécurité suffisamment coûteuse pour la plupart des dirigeants.  Donc, 24h ou 48h par ans, un scoop tombe et engendre un pic d’audience. Malgré le cache http et les CDN vous n’avez pas la qualité de service optimum et ça râle à l’édito. Vous rappeler le prix du service up a 100% quel que soit les conditions, tout le monde tousse et on passe à la question suivante.
  • Et encore si êtes dans un vrai cloud type IaaS (et pas juste de la virtualisation) vous avez la capacité d’être élastique, agile et réactif. Vous augmenterez votre capacité le temps de la tempête médiatique. Cela peux coûter un peu, mais cela dure juste le temps de la vague.

Il est ou le vrai coût du stockage ?

Le vrais coût du stockage est dans le stack applicatif utilisant le stockage, c.a.d votre site web.

Si votre développement ne sais que écrire ou lire dans un répertoire sans la moindre intelligence vous ne pourrez jamais tirer parti des systèmes de stockages qu’invente les acteurs de l’hébergement web, du cloud et des évolutions en général.

Une stack applicatif capable de changer de backend de storage pour passer d’un disque, à un NAS, puis à du AWS S3 cela a un coût bien supérieur au volume de disque ou à la BP brute. C’est du travail d’architecte web et de développeur, du jus de cerveaux qui à un coût. Soit ponctuellement par un grand big bang pour changer de paradigme de stockage, soit en continu.

Une stack applicatif applicative qui n’est pas économe des ressources de stockage. Qui ne prend pas en compte son propre auto-nettoyage. Qui ne vide pas automatiquement la poubelle, ne supprime pas les versions obsolètes. Un stack applicative de ce type va entasser. En dernier lieu plus personne ne maîtrise, personne ne veut prendre le risque de supprimer du contenu et c’est l’explosion du stockage.

Un autre partie, très souvent négligé, c’est les opérations d’exploitation et de sysadmin. Plus votre stockage augmentent et reste monolithique (cf: lire et écrire dans un répertoire)  plus sa manipulation  devient problématique. Déplacement, duplication, backup, restaurations, migration, synchronisation prendrons un temps précieux et tuerons toute réactivité.

La également votre  stack applicatif doit être capable d’adresser les objets stocker de façon répartie et modulaire (sharding, hachage, migration continue etc.), un peu sur disque et beaucoup dans le cloud. Et nous en revenons au jus de cerveaux et au code.

Le stockage ne coûte plus grand chose. Le tuyau de bande passante, moyen d’origine pour utiliser le stockage ne coûte pas non plus beaucoup. Mais le moyen d’utiliser les différents stockages, voir plusieurs en même temps; de passer de l’un l’autre, de façon répartie et modulaire repose sur le code de votre application. Et ça c’est du jus de cerveau qui à un prix.

Autant du stockage brut doit être considéré comme un coût. Un peu comme de l’essence pour une voiture. Autant la création d’une voiture capable d’utiliser indifféremment carburant est un investissement. Même chose pour vos applications.