Je vous pose le scénario :

Un matin, votre hébergement tombe en panne, vous ne pouvez plus offrir le service pour lequel vos clients ont payé : votre startup ne sert plus à rien… zéro… nada…

À cela s’ajoute la classique loi de Murphy (dite “loi de l’emmerdement maximum”) : c’est un samedi au mois de juillet, le jour de votre mariage, et votre CTO est en vacances en train de faire du trekking dans l’Atlas… et évidement, vous n’avez pas de 3G parce que vous êtes dans un charmant petit coin de campagne (ah, les fameux quelques pourcents de couverture mobile qui manquent sur le territoire ! )

Comment gérez-vous cela ?

Ça va vous arriver, c’est certain

Vous être sûr d’avoir tout fait techniquement pour que ça n’arrive jamais : vous avez tort, cela vous arrivera. Demain ou dans cinq ans, vous aurez une panne majeure qui coupera votre service pendant un certain temps (5 minutes ? 5 heures ? 5 jours ?)

Quelques exemples :

• Google, le 19 aout 2015, dix minutes de panne
• Amazon, le 26 août 2013, une panne leur aurait couté 5 millions de $
• Facebook, le 24 septembre 2015, une heure de service indisponible
• Apple, le 2 juin 2016, l’App Store est tombé…

Les GAFA n’arrivent pas à éviter les arrêts de service, il serait très prétentieux d’imaginer passer au travers.

Le moins souvent possible, je l’espère

Là, c’est le boulot de votre CTO, prévoir une architecture qui va être résistante, le plus possible… en rapport avec vos moyens financiers.

Le grand principe, c’est d’avoir une architecture Non-SPOF. Un SPOF (Single Point Of Failure) est une faiblesse dans votre système informatique. Je vais vous donner quelques exemples, mais c’est un travail de spécialiste qui doit être réalisé de façon permanente. Et vous allez vite constater la difficulté de l’exercice : vous avez besoin de tout mettre en redondance.

Par exemple :

• sur votre serveur, vous allez avoir besoin de deux disques (c’est fragile un disque dur, ça tombe régulièrement en panne, quand c’est neuf et quand c’est vieux…) mais aussi d’une double alimentation électrique (et de deux sources différentes d’alimentation électrique…)
• le serveur pouvant lui même tomber en panne, il vous en faut au moins deux, et donc devant vos serveurs il faut répartir le trafic internet avec un load balancer,
• le load balancer pouvant lui même tomber en panne… vous avez compris le système, il en faut deux, connectés à Internet,
• la connexion Internet pouvant elle même tomber en panne… 2 aussi,
• la salle d’hébergement de vos serveurs pouvant elle même avoir divers problèmes… on passe en dual hosting !

Évidemment, plus on avance, plus l’addition est salée. La grosse difficulté étant de trouver à chaque étape le bon rapport risque/sécurité/coût.

Prévoir l’imprévisible fatalité, dès que possible

Je me rappelle avoir eu de longue discussion avec un responsable technique à propos de ça. A l’époque, j’étais dans une boite de service informatique qui avait quelques contrats de maintenance nécessitant une intervention rapide. Moi, je voulais que du temps soit réservé dans notre planning pour gérer ces contrats. Même si au final nous n’avions pas besoin. Lui son approche était : “on se démerdera, on bouleversera le planning s’il y a un problème chez nos clients sous contrat”

La méthode est particulièrement inefficace : l’homme gère mal les choses sous la pression ! Trop d’erreurs seront commises et cela prendra plus de temps que nécessaire.

Alors prévoyez ce que vous allez faire quand cela va arriver, mieux, testez et répétez, comme on le fait pour les alertes incendie dans les bureaux.

Il y a deux aspects à gérer, dans cet ordre :

1. la communication avec les clients,
2. la remise en route du service.

S’occuper de la communication avant la remise en route du système pourrait paraitre paradoxal, mais c’est la meilleure façon de faire car elle va vous permettre d’avoir du temps (et de la sérénité) pour le redémarrage.

Je vous invite à faire une liste de choses à faire à ce moment, vous n’aurez qu’à répartir les tâches aux forces en présence le moment venu.

Dès que vous aurez fait un diagnostic rapide du problème, soyez prêt à :

• informer l’ensemble de vos collaborateurs, beaucoup sont en frontal avec des clients et ont besoin d’information,
• envoyer un email à tous les clients (cela veut dire que vous devez avoir cette liste en dehors de votre plateforme),
• mettre à jour votre “status page” : une page web, hors de votre site, qui vous permet d’indiquer si le service est en ligne ou pas (en Saas : Statuspage, ou Status.io, en Open source : Cachet),
• diffuser un message sur vos réseaux sociaux (où sont les codes d’accès pour le faire ?).

Et multipliez les messages à chaque fois que vous en saurez un peu plus, et cela jusqu’à la fin de l’incident.

À la croisée de la communication et de la technique, pensez à mettre en place une page d’attente pour informer les utilisateurs qui essayeront de se connecter à votre service. (Pensez aussi à avoir l’équivalent pour vos API).

Et après, c’est le boulot des tech de remettre en route tout cela, en croisant les doigts pour que ce soit un cas prévu, et donc facile et rapide à corriger.

Bon courage pour le jour où ça vous arrivera… et je vous le dis en connaissance de cause, ça m’est arrivé plusieurs fois, de 1 minute à 1 journée d’arrêt de service.

Illustration de couverture Thomas Bryans