Créateurs, évènements, coups de coeur

Rôle du CTO et son évolution, levée de fond, start-up

publié le 15 octobre 2014 par dans Technique

Voici l’histoire de ALittleMarket sous 4 angles de vision :

– L’organisation de travail et des équipes (pyramidale, scrum, team)
– L’évolution des outils d’aide à la production
– L’évolution du poste de CTO, de fondateur « touche à tout » à un CTO gérant 14 personnes, 6 sites, 2 langues.
– Le cycle de vie de la société, de sa création sur fond propre à son rachat par Etsy.

Bonne lecture :

Loic

Commentaires fermés

Outils pour la gestion de la production d’un site web.

publié le 11 juin 2014 par dans Technique

Bonjour,

Nous souhaitons partager dans ce billet, les différents logiciels que nous utilisons pour la gestion de la production.

Au niveau de la surveillance des serveurs de production  :

Newrelic, je dirais que c’est un must to have, il est certes payant (mais négociable), mais apporte un plus très important sur tout ce qui se passe en production.
Notamment une note Apdex qui est la note de ressenti utilisateur.

Il permet de monitorer (delta de 1 min) :
– Les chargements de pages lentes, et permets de comprendre pourquoi (découpage du process, méthode, classe et requête sql)
– Les requêtes lentes
– Le hardware des serveurs cpu/mémoire/ios
– Les logiciels du type varnish, nginx etc.
– Le taux d’erreur (php system etc).
– Les erreurs javascripts côté client.
Il est possible de paramétrer des alertes mails suivant différents paliers.

Munin couplé à Nagios pour les alertes sms et mail côté hébergeur.

LogStash / Kibana pour le suivi en temps réel avec moteur de recherche sur les erreurs php sur l’ensemble des frontaux.

ELK. Elasticsearc, logstash et kibana pour les dashboard dynamiques.

Les A/B tests :
Nous utilisons une solution SAAS : Kameleoon
La solution est un peu onéreuse suivant vos volumes, mais elle permet de réaliser des AB test facilement sur la production.
Il est couplé à GA pour le reporting. La création de tests est assez aisée et peut être faite par des personnes non technique.

http://www.kameleoon.com/

Il en existe d’autre du type optimizely ou encore la solution native de google analytic.

Le tracking utilisateur :
CrazyEgg, pas très cher permet de savoir ou les visiteurs clics et/ou les visiteurs baladent leur souris sur une page précise.

En terme d’organisation nous avons essayé pas mal de logiciels :
Trello pour un fonctionnement Kanban, smartsheet pour la présentation par gant, mais nous utilisons finalement Jira.

Et vous qu’utilisez-vous ?

Super Loic
CTO A Little Market
https://www.alittlemarket.com & https://www.alittlemarket.it
https://www.alittlemercerie.com & https://www.alittlecraft.it

https://www.alittlemaman.com

https://www.alittleepicerie.com

Les tags : , ,
Commentaires fermés

Effet Capital M6 : Comment tenir la charge.

publié le 17 janvier 2014 par dans Technique

Effet Capital M6 : Comment tenir la charge.

Ce billet a pour vocation à partager notre expérience sur ce passage.
ALittleMarket est passé sur Capital le 12 janvier 2014 et nous avons tenus la charge.
Nous sommes passés de 2000 visites minute à 36 000 visites minute et le site était consultable pour sa partie front.


Voici notre expérience.

Début décembre, Camille nous annonce que nous allons faire le sujet d’un Capital.Le sujet est confirmé et les équipes viennent filmer dans nos locaux.
Du côté technique, c’est la panique, comment faire pour gérer cet afflux !

Nous avions 3 semaines devant nous.
La partie dynamique nginx ou apache sera le point qui cassera en premier.
Il faut donc diminuer au maximum ces appels. Il faut qu’ils approchent 0 pour les non connectés.
Nous prévoyons 2 modes, un site light et un site fermé avec une page statique.

La partie page statique ne représente pas de soucis, vous mettez un serveur varnish, sans asset et il sera capable d’afficher votre page d’erreur. Pensez à ajouter votre code GA sur la page et un champ pour laisser un email.
Soit vous écrivez l’email en local, soit vous prenez un S3 chez amazon et vous lisez les logs à posteriori.
Nous avons découpé le sujet en 3 domaines, que chaque équipe à gérer.

A – Coté applicatif

1- Préparer une version light du site afin de désactiver toutes les fonctions non utiles (suivre mes commandes, ma messagerie, forum, site mobile) activable ou désactivable sur demande.
2- Retirer des fonctionnalités sur les pages qui resterons ouvertes (retrait du tri, de certain filtre, de la barre de recherche). L’objectif est de restreindre le nombre d’url possible afin de favoriser le cache.
3- Pour le header qui est personnalisé si la personne est connectée un appel ajax est fait si le cookie de session existe (le tout en JS)

B – Coté hébergeur physique :

1 – Tous les assets et js/css sont mis en cache coté varnish.
2 – Tous les appels ajax sont mis en cache, avec hashage sur l’id de session
3 – Toutes les pages fronts sont mis en cache coté varnish (même si connecté) grâce à la modif coté applicatif.
4 – Nous prévoyons une configuration spéciale de varnish qui réalise une liste blanche des pages autorisées.
L’idée est d’éviter à tout prix les accès apache/nginx. Tout ce qui n’est pas whitelisté renvoi par varnish une page/error 503 qui appel en iframe une page statique coté S3 de amazon.
https://s3-eu-west-1.amazonaws.com/capital-alm/500_alm.html (iframe sinon pas de code erreur HTTP).
La liste blanche est composée de toutes les pages fronts, page d’inscription et le panier. Tout le reste est fermé.
5 – On prévoit également une configuration de varnish ou TOUS les appels rediriges vers la page 500 du S3 au cas ou.

C – Coté cache / CDN

Malgré tout cela, nous étions sur que cela ne suffirait pas.
Nous avons fait le choix de passer par cloudfront (cdn d’amazon) pour encaisser les pages front.
Ainsi même si l’infra physique tombait, on aurait toujours les pages du cdn qui fonctionnerait.
Il encaisserait ainsi tout le premier trafic direct.
Attention toutefois, l’accélération apportée par CloudFront est moindre sur les pages dynamiques. Il ne s’agit que d’accélération réseau pour la partie dynamique (POST, PUT, DELETE, etc.) et on pas de mise en cache complète comme c’est le cas pour les appels GET.
– Vous devez rediriger le DNS de votre NDD sur Cloudfront, puis cloudfront va utiliser une origin chez vous pour alimenter son cache. (www-cloudfront.alittlemarket.com) pour nous.
Ceci n’est pas sans conséquence :
– Vous allez perdre toute info coté applicatif concernant l’acheteur. plus d’ip, plus de referer, vous gardez cependant les cookies.
– Pensez à cocher la case POST, sinon tous vos formulaires ne marcherons plus.
– Le js continuera de marcher, notamment GA, pas de soucis sur ce point.
– Vous êtes limité à 10 regex (behavior) pour vos règles de cache coté cloudfront.

Ok, on est pret, lançons le test de charge !

Toute la partie sur le cdn tient sans limite, cloudfront est monstrueux.
Par contre coté panier cela tombe très rapidement, trop.
Le calcul des frais de port est quelque chose de très lourd chez nous car nous sommes une place de marché.
Réaction, nous prévoyons une autre version de la configuration de varnish avec le panier fermé qui redirige sur une page dédiée :
https://s3-eu-west-1.amazonaws.com/capital-alm/panier-alm.html qui va prendre l’id du produit mit au panier, et on demande le mail.
L’idée est de pouvoir lui envoyer un mail personnalisé le lendemain, c’est fort !

Plan d’action :
Samedi matin 6h, simulation réel sur production.
On déroule le plan, on note des anomalies du type le css de la page en cache coté cdn ne se charge pas si on ferme le site. Ce genre de chose.

Dimanche
17h : TTLl de 15 min chez Typhon, on migre le ndd www sur cloudfront. Conséquence => perte des informations du client (hors cookie) coté applicatif.
20h15 : Ajout des règles cotés cloudfront, 10 min de propagation. Conséquence => les liens mises en fav, contacter ne fonctionne plus sur les pages misent en cache (je ne redirige pas le cookie).
20h40 : Passage en mode light coté applicatif. Conséquence => Retrait des filtres, des tris, de la messagerie, du suivi de commande etc.
20h45 : Passage en white liste coté Varnish. Conséquence=> Les pages non front/panier/création de compte sont toutes fermées ! on coupe aussi logstash/kibana.
20h50 : Brief du capital, on est cité. 2200 users au leu de 2000. C’est calme. 120 requêtes dans le pull mysql.
21h00 : On retire la white liste. car le passage chaud est passé.
21h30 : Blablacar tombe, on a peur.
22h00 : On remet la white liste.
22h05 : On est cité, le compteur explose.
22h09 : 6600 users/minutes.
22h12 : 7500 users/minutes.
22h19 : 13 000 users/minutes.
22h20 : 20 000 users/minutes.
22h20 : On ferme le panier, les serveurs physiques ne tiennent plus.
22h22 : 30 000 users/minutes, 800 requêtes dans mysql.
22h24 : 36 600 users/minutes, 1000 requêtes dans mysql aucune de plus de 3 sec.
22h42 : 20 000 users/minutes, on réouvre le panier.
22h54 : 10 000 users/minutes, on retire la white liste.
23h30 : 6000 users, on remet le site normal.
00h00 : on rebascule le ndd coté typhon.

Lundi : 60% de croissance, 2500 users toutes la journée, avec un pic à 3100 users.
Optimsation de varnish dans la journée, toujours dans cette optique de limiter les accès apache.

Un challenge de plus réussi :)

Loic
CTO Alittlemarket !
Voyez grand, soyez ALittle.

 

regle_cloudfront

regle_cloudfront_boutique