vault backup: 2026-08-05 18:03:09
This commit is contained in:
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: meeting
|
||||
date: 2026-07-31
|
||||
source: MeetMic
|
||||
status: inbox
|
||||
duration: 37m
|
||||
meetmic_id: A106504E-6E4F-4CA1-9E14-0C2AEF16C361
|
||||
---
|
||||
|
||||
# Recording
|
||||
|
||||
## Résumé
|
||||
- Le problème concerne un cache Redis non purgé depuis des jours, avec des symptômes de ralentissement et des erreurs de recherche, notamment pour des filtres d’années et de matière.
|
||||
- La cause semble liée à une gestion du TTL (Time To Live) dans Redis : certaines clés sont conservées indéfiniment, d'autres ont un TTL de 365 jours, ce qui provoque une pression mémoire et des problèmes de performance.
|
||||
- Le problème est récurrent depuis le 14 mai, avec sept tickets similaires, et semble lié à des modifications de TTL ou de paramètres Redis non documentés.
|
||||
- Les équipes du projet Idéal et Libéo ont des stratégies de cache différentes, avec des implémentations non synchronisées entre les systèmes (algolia, Directus, Redis).
|
||||
- Les logs sont absents, et la responsabilité est contestée : les équipes affirment qu’elles ont modifié le TTL, mais aucun document ou log n’est disponible pour prouver la cause.
|
||||
|
||||
## Décisions
|
||||
Aucune
|
||||
|
||||
## Actions
|
||||
- [ ] Vider le cache Redis – Responsable : non identifié – Échéance : non définie
|
||||
- [ ] Analyser les logs et métriques du cache Redis – Responsable : non identifié – Échéance : non définie
|
||||
- [ ] Réexaminer les configurations TTL et paramètres Redis – Responsable : non identifié – Échéance : non définie
|
||||
- [ ] Tester la solution de vider le cache en staging – Responsable : non identifié – Échéance : non définie
|
||||
|
||||
## Blocages / Risques
|
||||
- Absence de logs et d’historique pour prouver la cause du problème.
|
||||
- Manque de documentation sur les changements effectués par les équipes Libéo.
|
||||
- Risque de réapparition du problème si les modifications de TTL ne sont pas revues.
|
||||
- Pression mémoire sur Redis, sans stratégie d’éviction claire.
|
||||
- Évolution du problème en production sans trace des changements effectués.
|
||||
|
||||
## À suivre
|
||||
- Analyser les changements effectués depuis le 14 mai, en particulier les déploiements ou modifications de TTL.
|
||||
- Tester la solution de vider le cache en staging.
|
||||
- Réunir les équipes pour discuter des configurations TTL et de la gestion du cache Redis.
|
||||
- Évaluer les métriques et logs pour identifier la cause du problème.
|
||||
- Planifier une réunion avec le chef de projet pour le 17 mai.
|
||||
@@ -0,0 +1,19 @@
|
||||
## 1. Contexte et Objectif
|
||||
L'objectif est d'intégrer la diffusion d'événements en direct (shows) sur la nouvelle application OTT, tout en minimisant les coûts et en évitant une complexité opérationnelle (comme la création de flux temporaires).
|
||||
|
||||
## 2. Contraintes Techniques et Financières (JWP)
|
||||
* **Règle technique :** Un point d'ingestion (*ingest point*) ne peut recevoir qu'un seul signal vidéo à la fois.
|
||||
* **Coût d'un 2ème flux 24/7 :** Avoir un deuxième point d'ingestion permanent diffusant en parallèle coûterait **1 800 $/mois** (pour 720h d'ingestion).
|
||||
* **Ingest ponctuel :** Créer des points d'ingestion temporaires uniquement pour la durée des événements est complexe car cela demande de la gestion manuelle et complexifie les opérations (corus, etc).
|
||||
* Une autre option est de stream du studio, alors ce n'est pas trop complexe à gérer, mais on perd les sous-titres.
|
||||
|
||||
## 3. Solution Recommendé : Bouton "Live" sur le flux existant
|
||||
L'approche la plus simple et la plus efficace a été choisie :
|
||||
* **Réutilisation du flux actuel :** Le point d'ingestion 24/7 déjà existant sera réutilisé pour l'application OTT.
|
||||
* **Rôle de Tring (Développement App) :** Tring intégrera un bouton permanent "En direct" / "Live" directement dans l'interface de l'application OTT, pointant vers ce flux existant.
|
||||
* **Rôle de JWP :** Maintien de la configuration actuelle du flux 24/7 en arrière-plan.
|
||||
|
||||
## 4. Impacts et Avantages
|
||||
* **Impact Financier :** **0 $ de frais additionnels** liés à l'ingestion. La consommation d'heures est globale au compte. Diffuser le même flux sur le web et sur l'OTT ne double pas les frais d'ingestion.
|
||||
* **Impact Opérationnel :** Simple et automatisé. Aucune ouverture ou fermeture de canal technique n'est requise lors des jours de direct.
|
||||
* **Impact sur la Programmation :** Lors d'un événement en direct, l'utilisateur utilisera le même feed disponible sur tfo.org. Il remplacera donc la programmation régulière et sera diffusé simultanément sur le site web et l'application OTT.
|
||||
@@ -0,0 +1,5 @@
|
||||
2027-07-31
|
||||
Email d'Amazon pour dire que l'app OTT est retirée faute de texte en anglais. Trings fut contacté et ont refait une soumission
|
||||
|
||||
2027-08-04
|
||||
Demande à JC de tester la possibilité d'utiliser le feed live de tfo.org sur OTT. Si concluant, on voit ce que cela prend du coté Trings d'avoir juste un nouveau onglet "en direct"
|
||||
@@ -0,0 +1,129 @@
|
||||
---
|
||||
type: project
|
||||
project: Strategic KPI Framework
|
||||
status: active
|
||||
owner: Amadou
|
||||
start_date: 2026-08-05
|
||||
target_date:
|
||||
last_reviewed: 2026-08-05
|
||||
stakeholders: CDD
|
||||
---
|
||||
|
||||
- 🟢 **On track / Healthy:** no intervention required
|
||||
- 🟡 **Attention:** issue exists, but currently manageable
|
||||
- 🟠 **At risk:** intervention or decision required; commitment is likely to slip
|
||||
- 🔴 **Critical / Off track:** commitment missed, major blocker, or immediate intervention required
|
||||
- ⚪ **Unknown:** insufficient information to assess
|
||||
|
||||
**Status:** ⚪ Unknown
|
||||
**Owner:**
|
||||
**Start Date:** 2026-08-05
|
||||
**Target Date:**
|
||||
**Last Reviewed:** 2026-08-05
|
||||
**Stakeholders:**
|
||||
|
||||
---
|
||||
|
||||
## Objective
|
||||
|
||||
What are we trying to accomplish?
|
||||
|
||||
<% tp.file.cursor() %>
|
||||
|
||||
## Business Value
|
||||
|
||||
Why are we doing this?
|
||||
|
||||
-
|
||||
|
||||
## Success Criteria
|
||||
|
||||
How will we know the project succeeded?
|
||||
|
||||
-
|
||||
-
|
||||
|
||||
## Scope
|
||||
|
||||
### In Scope
|
||||
|
||||
-
|
||||
|
||||
### Out of Scope
|
||||
|
||||
-
|
||||
|
||||
## Deliverables
|
||||
|
||||
These are project outputs, not personal reminders.
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Milestones
|
||||
|
||||
| Milestone | Owner | Target | Status |
|
||||
|---|---|---|---|
|
||||
| | | | ⚪ Unknown |
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | Impact | Probability | Mitigation | Owner |
|
||||
|---|---|---|---|---|
|
||||
| | | | | |
|
||||
|
||||
## Dependencies
|
||||
|
||||
| Dependency | Owner | Needed By | Status |
|
||||
|---|---|---|---|
|
||||
| | | | ⚪ Unknown |
|
||||
|
||||
## Decisions
|
||||
|
||||
Link only to actual decision notes.
|
||||
|
||||
- [[]]
|
||||
|
||||
## Current Status
|
||||
|
||||
**Overall:** ⚪ Unknown
|
||||
|
||||
### Latest Update
|
||||
|
||||
**Date:** 2026-08-05
|
||||
|
||||
-
|
||||
|
||||
### Completed
|
||||
|
||||
-
|
||||
|
||||
### In Progress
|
||||
|
||||
-
|
||||
|
||||
### Blockers
|
||||
|
||||
-
|
||||
|
||||
## Next Commitment
|
||||
|
||||
**Commitment:**
|
||||
**Owner:**
|
||||
**Due:**
|
||||
**Status:** ⚪ Unknown
|
||||
|
||||
## Actions
|
||||
|
||||
> Execution is tracked in **Monday or Jira**.
|
||||
> Personal actions belonging to me are tracked in **Twos**.
|
||||
|
||||
-
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
_To be completed during and after the project._
|
||||
|
||||
## Related
|
||||
|
||||
- [[]]
|
||||
Reference in New Issue
Block a user