Al post anterior sobre MeteoTrail em vaig centrar en el perquè: els directors de cursa no necessiten una predicció regional, necessiten saber què passarà al quilòmetre 43, a 2.400 metres, d'aquí a quatre hores, perquè és allà on seran els seus corredors. Aquest post va del com: el problema d'enginyeria real que hi ha darrere de convertir què passa exactament en aquest punt de la muntanya en alguna cosa en què un director de cursa pugui confiar prou com per actuar-hi. Part del que ve a continuació són decisions que vam prendre de manera deliberada; altres parts s'apropen més a "aquesta és la mena d'arquitectura que necessita un sistema com aquest", raonades a partir de les restriccions més que no pas un relat línia per línia de cada detall intern.
1. Moltes fonts, un sol checkpoint
Un checkpoint en una ultra de muntanya no és una ubicació única i estable com ho és una ciutat. És un punt de la ruta que l'organització defineix amb mesos d'antelació, que de vegades cau just sobre una frontera nacional —les curses de la Val d'Aran creuen cap a França, i de vegades cap a Andorra, dins la mateixa etapa— i que cal resoldre, en temps real, contra la font meteorològica oficial que realment cobreix aquell tros de terreny.
Per a cada checkpoint cal esbrinar, abans de la cursa, en quina zona d'avís de quina agència cau, quines webcams públiques de la ruta són prou a prop i ben orientades cap a aquell punt, si hi ha una estació meteorològica privada o semioficial a prop amb millor resolució que l'oficial més propera, i d'on cal mostrejar les dades de detecció de llamps per a aquell radi exacte. Això són quatre o cinc sistemes diferents darrere l'escena, cadascun amb la seva pròpia forma d'API, el seu propi interval d'actualització i la seva pròpia manera de fallar.
- APIs oficials d'agències meteorològiques (condicions actuals, previsions a 48 hores i 7 dies, avisos) — per exemple AEMET, Météo-France, IPMA, Aeronautica Militare
- Feeds de webcams públiques al llarg de la ruta
- Detecció de llamps en temps real
- Estacions meteorològiques privades o semioficials a prop del checkpoint
El checkpoint, dit d'una altra manera, no és la dada en brut en si mateixa: és la vista reconciliada que construïm al voltant d'un punt geolocalitzat, obtinguda de la combinació de feeds que realment estiguin disponibles i siguin fiables en aquell moment. La predicció a 48 hores que veu un director de cursa per a un checkpoint concret ja és el resultat de triar, per tipus de dada, la font en què confiem més en aquell moment per a aquella ubicació concreta — no un únic feed reenviat sense tocar.
2. Decidir què és prou important com per avisar
Agregar dades és només la meitat del problema. La meitat difícil és decidir quan un canvi val la pena per despertar algú. Un director de cursa no vol un correu cada vegada que la lectura de vent es mou mig quilòmetre per hora, però sí que en vol un en qüestió de minuts si s'emet un avís oficial de tempesta per a un checkpoint al qual els seus corredors arribaran d'aquí a tres hores.
La forma aproximada de la solució és un motor de regles per llindars que s'executa a cada actualització rellevant per checkpoint, no només amb un temporitzador: creuar un llindar de vent o temperatura, un avís oficial nou que apareix on abans no n'hi havia cap, llamps detectats dins d'un radi al voltant del checkpoint, o una caiguda brusca de temperatura en una finestra curta. Una cosa així, molt simplificada respecte al que necessitaria un conjunt de regles real:
def evaluate_checkpoint(checkpoint, previous_state, current_reading):
triggers = []
if crosses_threshold(previous_state.wind_kmh, current_reading.wind_kmh, threshold=60):
triggers.append(Alert("wind", severity="high"))
if current_reading.has_new_agency_alert and not previous_state.has_agency_alert:
triggers.append(Alert("agency_alert", severity=current_reading.alert_level))
if current_reading.lightning_strikes_last_10min(radius_km=15) > 0:
triggers.append(Alert("lightning", severity="critical"))
if current_reading.temperature_drop_c(last_hours=3) > 8:
triggers.append(Alert("temp_drop", severity="medium"))
if not triggers:
return None
return build_notification(checkpoint, triggers, previous_state)
El realment difícil no és escriure regles com aquestes, sinó ajustar la severitat i el radi perquè el sistema escali la tempesta que baixa cap al quilòmetre 40 sense enviar també un correu a cada organitzador cada vegada que una webcam falla o una estació dona una lectura sorollosa. Aquest ajustament ha de tenir en compte que una sola cursa pot tenir checkpoints sota la jurisdicció de tres països alhora, cadascun amb un vocabulari d'avisos i una escala de severitat diferents.
3. Deixar que una persona substitueixi l'automatització
Res d'això substitueix el criteri humà. El backoffice de MeteoTrail permet que un meteoròleg contractat vegi tot el que el pipeline automàtic està veient per a una cursa i publiqui un informe manual que s'envia a tota l'organització, substituint el que mostra el feed automàtic per a aquell checkpoint.
El problema de disseny interessant és què passa just després de publicar aquell informe: el pipeline automàtic no s'atura. Així que el sistema necessita una regla de precedència clara i visible: un informe humà ha de prevaler sobre la vista automàtica per a aquell checkpoint mentre hagi de seguir sent la paraula autoritzada, sense desaparèixer en silenci tan bon punt arriba la següent actualització automàtica, i sense que tots dos es mostrin mai costat a costat com si tinguessin el mateix pes. A la pràctica això significa que un informe necessita un abast explícit, una procedència clara i una regla de caducitat o de substitució, perquè un informe manual desfasat de fa sis hores no bloquegi per sempre una lectura automàtica nova i materialment diferent.
4. El que encara és difícil
Algunes coses d'aquest problema encara no tenen una resposta neta. Les fonts discrepen entre elles més del que voldríem, i triar un guanyador per tipus de dada i per checkpoint continua sent en part heurístic. Els checkpoints fronterers són la seva pròpia categoria de mal de cap — una etapa que comença sota la zona d'avís d'una agència i acaba sota la d'una altra necessita totes dues. La fiabilitat de les webcams està completament fora del nostre control. I un sol meteoròleg cobrint diverses curses simultànies durant un cap de setmana d'estiu molt carregat ha de prioritzar, cosa que significa que la capa de substitució manual ha de ser genuïnament opcional i l'automatització ha de ser prou bona per sostenir-se sola la major part del temps.
Res d'això és treball exòtic de sistemes distribuïts, i no cal que ho sigui. Però sí que és un problema d'integració real disfressat d'app del temps. Si el post de març anava de per què els directors de cursa necessitaven això, aquest va del que cal, per sota, perquè "quin temps fa ara mateix al checkpoint 7" sigui una pregunta amb una resposta fiable.