Best Practices per Connettori su Larga Scala

Definiamo una strategia di connettore su larga scala come quella che produce oltre 5000 Unità di Lavoro in Bureau Works per richiesta di sincronizzazione. Un'unità di lavoro in Bureau Works è una combinazione di un file + fase del flusso di lavoro + coppia linguistica. Quindi un progetto con 5 file, 2 fasi del flusso di lavoro (Traduzione + Revisione) e 5 lingue si tradurrà in 50 unità di lavoro. Puoi vedere come non sia così difficile superare 5000 Unità di Lavoro quando inizi a moltiplicare queste variabili. È allettante voler centralizzare tutto in un singolo progetto, ma la nostra esperienza dimostra che con i Connettori su larga scala, raggruppare i progetti per coppia linguistica è la soluzione migliore. Questo può sembrare semplicemente una questione di come scegli di definire un progetto, ma va molto più in profondità di così. In questo articolo analizzeremo l'impatto di questa decisione in termini di:

1. Intermediazione dei messaggi
2. Risoluzione dei problemi
3. Mitigazione del rischio
4. Accodamento/prestazioni
5. Potenziale di Automazione
6. Facilità di gestione
7. Scalabilità

Intermediazione dei messaggi1) La messaggistica cresce esponenzialmente con i connettori su larga scala. Abbiamo visto connettori che creano oltre 1 milione di messaggi per richiesta di sincronizzazione. Questo comporta un'enorme attività del server e problemi di prestazioni che possono essere mitigati dividendo i progetti per località. Problem Solving2) Questo è direttamente legato alla mitigazione del rischio. Tuttavia, nella localizzazione si riscontrano spesso problemi limitati a una determinata impostazione locale e al modo in cui ciò influisce sull'analisi, segmentazione e pre/post elaborazione di un determinato insieme di file. Suddividendo tra le località, puoi Crea espressioni regolari specifiche per località, regole di elaborazione, segmentazione che offre molta più flessibilità per quanto riguarda l'architettura complessiva. Piuttosto che lavorare con correzioni limitate che funzionano in modo uniforme, puoi iterare in base al locale e raggiungere infine un modello di comportamento più maturo e prevedibile quando lavori basandoti sui locali. Mitigazione del Rischio 3) Decouplando i progetti in uno per locale, mitigherai i rischi di gestione perché se qualcosa va storto in un dato locale, ciò non significa che l'intero meccanismo di pull-request/consegna sia compromesso. Puoi isolare e compartimentare naturalmente i problemi. Questo potrebbe non sembrare un problema durante le SOP, ma quando si presentano problemi imprevisti (e succede sempre nella localizzazione), sarai grato di aver costruito una casa di mattoni invece di una fatta di paglia. Accodamento/Prestazioni: invece di allineare 150.000 elementi per l'elaborazione, ad esempio, puoi allineare 15.000 elementi dieci volte. Ancora una volta, questo non sembra una grande differenza poiché alla fine dovrai elaborare gli stessi 150.000 elementi, ma avere la flessibilità di elaborare in serie rispetto a in parallelo o opportunisticamente come desiderato ti offre molta più flessibilità oltre a una maggiore larghezza di banda delle prestazioni. Potenziale di automazione 5) Tipicamente le decisioni di progetto e i flussi di lavoro saranno asimmetrici tra le località. Separare i progetti per località ti offre una flessibilità molto maggiore per quanto riguarda il potenziale di automazione a lungo termine. Puoi avere uno scenario in cui hai parametri interamente diversi così come set di dati quando li separi per località invece di consolidare tutti gli elementi insieme. Management6) Anche questo è controintuitivo. Dal punto di vista della gestione, in genere il consolidamento è la best practice per una migliore governance. Ma nei connettori su larga scala è vero il contrario. Un progetto si filtrerà naturalmente per locale, permettendo ai diversi Responsabili di progetto di gestire più facilmente le diverse parti del progetto, riducendo l'uso di filtri per generare report e creando una maggiore semplicità nel monitorare cosa sta accadendo per locale. Scalabilità7) Con i Connettori su larga scala, si raggiungerà un punto in cui diventa semplicemente ingestibile scalare raggruppando tutte le unità di lavoro in un unico progetto. Separando si stabilisce la struttura per un programma che è più facile da scalare a lungo termine. Ricorda che le cose si moltiplicano quando si tratta di unità di lavoro e messaggi. Separando per impostazione locale, si elimina una delle grandi variabili moltiplicatrici, consentendo di scalare molto più facilmente. Conclusione: c'è l'illusione che il consolidamento sia migliore. Una richiesta pull per progetto semplifica la vita di tutti. Mentre ciò è vero per i connettori su piccola scala, non vale per quelli su larga scala. Il nostro obiettivo è sempre fornire le Soluzioni più eleganti e affidabili ai nostri clienti e abbiamo visto più e più volte che, con situazioni su larga scala, dividere e conquistare è la strada da seguire.

Consolidamento in un Singolo ProgettoSeparazione per localitàL'intero Progetto ha uno stato di 0 o 1Lo stato può essere stratificato per localitàParsing singolare, filtraggio e Framework RegExFramework flessibile per localitàCoda a corsia singola per progettoCoda e elaborazione flessibili che distribuiscono naturalmente l'elaborazioneFiltraggio per località all'interno del progettoUn passaggio di filtraggio in menoRegole di Automazione che funzionano su tutta la lineaParametri e dati di automazione specifici per localitàTutte le uova in un paniere da una prospettiva di rischioRischio distribuito tra le localitàComplesso da isolare e risolvereUn'enorme variabile in meno che rende più facile la risoluzione dei problemi