Aviate, navigate, communicate

Le 20 février 2021, le vol United 328 s'est envolé de l'aéroport de Denver à destination d'Honolulu.

Quelques minutes après le décollage, le réacteur droit (n° 2 ) du Boeing 777-220 explose et s'enflamme. Vous avez peut-être vu ces images filmées par les passagers dont je n'envie pas la place à ce moment-là.

Les pilotes sont formés à la gestion de ce type d'incident, et s'appuient sur des procédures d'urgence pour guider la marche à suivre.

A cette occasion, j'ai découvert une loi, un mantra intangible qui guide un pilote d'avion en cas de problème : “Aviate, Navigate, Communicate”.

Piloter, naviguer, et communiquer.

Pourquoi ce trio de verbes ?

Des études d'accident aérien ont montré que sous l'effet du stress, les pilotes peuvent parfois accorder tellement d'attention au problème technique qu'ils en oublient parfois de ... faire voler l'avion.

Ca semble surréaliste, mais c'est pourtant déjà arrivé en 1972 : les pilotes du vol Eastern Airlines 401 étaient focalisés sur l'absence d'une lumière verte signalant la sortie et le verrouillage du train d'atterrissage. Ils n'ont pas remarqué la descente de l'appareil qui s'est finalement écrasé.

C'est humain. Avec un moteur en feu et 241 personnes à bord, on a envie de faire demi-tour et d'atterrir au plus vite.

Mais non.

Le plus urgent n'est pas pas “naviguer” vers la piste d'atterrissage. Le plus urgent c'est de maintenir l'intégrité de l'avion en appliquant la check-list.

D'ailleurs, lorsque le contrôleur aérien demande au pilote tout proche de l'une des pistes d'atterrissage :

"You want a left turn into the airport right now or you want delay vectors for anything else you may need ?"

Le pilote répond :

"We need delay vectors. We need to still run a few checklists to get some landing data".

Quand le contrôleur lui donne la possibilité d'atterrir tout de suite, le pilote préfère prendre l'option de dérouler sa check-list afin de sécuriser son atterrissage.

Et vous dans votre projet ?

Quand un truc va mal ?

On fait tout l'inverse !

D'abord on communique. On appelle tout le monde pour signifier que c'est la crise.

“Les utilisateurs ne peuvent plus charger leur photo de profil sur leur compte !!!!. Il y a un bug !!!!”

Après on cherche frénétiquement une solution au problème : le patch miraculeux qui va nous sortir de la crise.

Et éventuellement, quelqu'un s'intéresse enfin à l'état de fonctionnement global du logiciel.

On fait tout l'inverse parce que l'enjeu est différent. On met rarement la vie de quelqu'un en danger à cause d'un bug logiciel (même si cette assertion est probablement de moins en moins vraie).

Pourtant, le pilotage d'un avion en situation incidentelle pourrait parfois nous inspirer lorsqu'on cherche à résoudre un problème technique.

La semaine dernière, j'ai passé du temps à traquer ce bug d'upload d'une image de profil. Un bug incompréhensible, car les tests unitaires étaient OK, et ça fonctionnait sur la plateforme de développement.

Ah si j'avais commencé par regarder l'état global du système ! J'aurais vu que le backend s'arrêtait après chaque upload, pour redémarrer ensuite ! En cause ? Une directive watch de pm2 mal paramétrée...

Avant de chercher la réponse détaillée à un problème précis, mieux vaut souvent commencer par se représenter correctement le système.

Ce qui facilite la démarche :

• placer des signaux vitaux aux endroits "stratégiques" du logiciel. Un coup d'oeil à ces quelques données nous fournit immédiatement cette représentation globale. En bonus, on y associe des triggers qui vont nous alerter automatiquement pour détecter le problème avant les utilisateurs.
• Analyser les logs en continu. Ils contiennent souvent les données nécessaires, mais elles sont diluées parmi une foule de détails. Pour faire le tri, on peut s'appuyer sur un outil d'APM (Application performance Monitoring). Mon préféré : ElasticSearch APM.

Une check-list pour contrôler rapidement l'état général de votre application est une bonne opportunité de réfléchir à la fiabilité de son architecture. Et peut-être de mettre en évidence un point de fragilité qui pourrait trop facilement conduire au crash.