Le pipeline nocturne a échoué et le tableau de bord de la direction est vide à 8h. Décrivez votre réponse.

Communiquez d'abord : dites aux parties prenantes que le tableau de bord n'est pas à jour et donnez une heure estimée, parce que le silence transforme un problème de données en problème de confiance. Ensuite, trouvez la première tâche en échec plutôt que l'erreur la plus bruyante, puisque les échecs en aval sont en général des symptômes. Choisissez entre relancer la tranche en échec et servir les données d'hier avec un bandeau. Corrigez, relancez de façon idempotente, vérifiez les volumes de lignes, puis rédigez l'analyse de cause.

Avant de déboguer quoi que ce soit, je poste dans le canal des parties prenantes que le tableau de bord affiche des données périmées, ce qui est concerné, et quand je donnerai la prochaine mise à jour. Ce seul message évite une dizaine d'interruptions et préserve la confiance, même si le correctif prend deux heures. Ensuite je remonte en haut du DAG, parce que dans une chaîne de quinze tâches en échec, quatorze ne sont que l'aval d'un seul vrai problème. En général, la vraie cause tombe dans trois cases : les données amont ont changé, l'infrastructure a eu un raté, ou quelqu'un a mergé un changement. Un coup d'oeil aux déploiements de la veille tranche vite. La dernière fois que cela m'est arrivé, le système source avait livré un renommage de colonne dans la nuit sans prévenir, donc le modèle de staging échouait sur un champ manquant. J'ai patché le modèle, relancé les partitions concernées, et comme le pipeline est idempotent, c'était sans risque et sans nettoyage. Puis j'ai vérifié les volumes de lignes contre la veille avant de dire à qui que ce soit que c'était réglé, et j'ai ouvert une discussion de contrat avec l'équipe source.