[WIP à compléter] Points d'attention ou d'amélioration dans l'architecture technique

[thbar]

Suite à une présentation "architecture tech" avec @maxime-siret @AntoineAugusti et @Brewennn ce matin, où on a abordé l'architecture mais aussi les enjeux derrière, je crée ce ticket des possibilités d'améliorations et des points d'attention associé.

Re:

j'ai demandé à Thibaut et Antoine de me faire une liste des chantiers d'améliorations de l'architecture, avec une petite estimation du temps de dev' associé. Cela me permettra de ne pas oublier ces chantiers dans la feuille de route du PAN et à présenter en board également

Diagramme simplifié

Points d'attention

• stockage S3 (historisation, validation...) -> pas de backup hors-site (et pas de backup tout court, sauf peut-être chez CleverCloud mais non vérifié). L'écosystème s'appuie sur nos fonctions d'historisation de plus en plus (https://github.com/etalab/transport-site/pull/4194)
• criticité par façon d'interagir:
  1. le site (5M de requêtes par mois, dont des "crawlers") -> impact navigation pour les utilisateurs
  2. l'API (160k requêtes par mois) -> impact intégration automatisées dans des pipelines de données (urgence plus forte)
  3. le proxy temps réel (70M de requêtes par mois) -> impact calculs d'itinéraires (urgence encore plus forte)
• il faudrait "objectiviser" les attentes actuelles de l'écosystème à notre égard (j'y reviens plus bas), pour mettre en face les moyens adaptés (pas + pas -)
• zones en vert (blog/normes/contribuer) -> stack technique différente, et dette technique forte
• conserver une autonomie au niveau équipe sur les choix d'outils (les outils de monitoring ou d'ops ne sont pas interchangeables)
• dépendances aux systèmes tiers (panne chez x ou y -> peut causer une panne chez nous)
• pas de structure RH adaptée actuellement, ni de "SLA" clair, pour gérer les éventuelles pannes (c'est "au volontariat")

Chantiers d'amélioration

à compléter / relire / estimer avant board, c'est un premier jet.

• Aller à la rencontre de nos réutilisateurs, évaluer (sondages) l'impact d'une indisponibilité chez nous, pour eux (site / API / proxy) -> important pour objectiviser la criticité, et pouvoir rendre des comptes à nos sponsors
• Solidifier les "restarts" chez CleverCloud : réunion à prévoir avec eux, j'envisage d'implémenter un système de redémarrage "automatique" chez nous avec la bonne heuristique, car c'est la source majeure de downtime aujourd'hui
• MCO : préparatifs pour être capable de redéployer ailleurs en cas d'incident majeur (type incendie), chez un autre hébergeur (avoir joué le jeu permet de gagner un temps considérable, et de répondre à ce qu'on a signé dans l'audit de conformité aussi)
• Envisager une séparation / redondance du proxy (https://github.com/etalab/transport-site/issues/4109)
• Créer un backup incrémental, "non effaçable", des buckets S3 (historisation etc)
• Réduction de la dette technique sur les éléments en vert (netlify / blog / normes / contribuer), éventuellement, homogénéisation technique (https://github.com/etalab/transport-normes-site/issues/9, https://github.com/etalab/transport-normes-site/issues/19)
• Créer une sauvegarde de nos dépendances directes (packages Elixir)
• La base de données grossit (https://github.com/etalab/transport-site/issues/2425), impact opérationnel, et aussi pratique pour le dév (https://github.com/etalab/transport-site/issues/3800)
• Liste non exhaustive : il y aurait des points d'amélioration sécu aussi à faire graduellement (comme partout)

[thbar]

Avant de faire des estimations, poke @etalab/transport-tech pour info, et on fera du tri / estimations rapides avant le board avec @AntoineAugusti

[thbar]

(j'ai des choses à ajouter, ça va me revenir 🍭)