如何修正 OTP 交貨問題 （唔使重建你嘅訊息堆栈）
點解驗證訊息會失敗 — 同埋點樣用更好嘅路由、故障轉移同埋操作控制嚟提升傳送可靠性
快速解答
OTP 送達問題多數係路由問題，唔係程式問題：只有單一供應商線路、無故障切換、發送者標識未報備，或者在某個網絡被過濾。解決辦法係每個國家配置多條線路、在供應商同渠道之間自動切換，並保留逐次嘗試嘅可見度，令失敗可以查得到，唔使靠猜。
如果你嘅 OTP 訊息唔可靠噉傳送，其他所有嘢都會停止運作。
用戶登入唔到。交易失敗。支持加飛。
而且喺內部，通常都唔清楚咩係引起呢個問題嘅原因 — 或者點樣去解決呢個問題。
大部分團隊都假設 OTP 嘅交付係一個解決咗嘅問題。
事實上，呢個係現代訊息中其中一個最脆弱嘅部分。
點解 OTP 訊息失敗
OTP 交貨失敗好少係單一問題。
佢哋喺你嘅供應商、用緊嘅路線、接收訊息嘅流動網絡供應商同埋你傳送去嘅地區之間嘅某個位置。
你嘅供應商可能會接受訊息，但係會喺下游過濾。
一條路線可能喺一個國家表現好，喺另一個國家表現唔好。
喺交通高峰期間，如果冇任何明顯嘅警示，送貨可能會降低。
令到呢個困難嘅係，大部分團隊都冇任何可以睇到訊息嘅全部路徑。
所以當送貨失敗嗰陣，唔明顯問題其實係邊度。
最常見嘅設定（同埋佢嘅限制）
大部分商家都係由單一短訊供應商開始。
呢個方法一開始運作得好好。佢簡單，易於整合，而且需要好少嘅運作努力。
但係佢亦都會產生一種依賴關係。
當交付降級嗰陣，就冇後備。
當問題發生嗰陣，你會依賴嗰個服務供應商嚟調查同埋回應。
而且當性能因地區而異嗰陣，靈活性就會有限。
有啲團隊會嘗試加入第二個供應商嚟解決呢個問題。
噉樣可以改 善冗餘，但係會引入一個新嘅問題 — 複雜性。
路由決定變得更加難以管理。
後備唔係成日都配置得啱。
而內部團隊最後會協調多個供應商，但係冇明確嘅擁有權。
其實有咩可以改善 OTP 嘅交付
改善 OTP 嘅交付唔係關於轉供應商。
呢個係關於隨時間嘅推移，訊息係點樣路由同運作。
可靠嘅 OTP 交付通常取決於四樣嘢一齊運作。
首先，有多條路線可以用。
唔係所有供應商喺唔同地區嘅表現都係一樣，而且依賴單一路線會增加風險。
第二，有實際上有效嘅故障轉移。
如果送貨失敗或者降級，流量就需要移動，而唔係等。
第三，對發生緊嘅事有可見性。
如果唔監察交付行為同供應商嘅表現，通常會太遲先發現問題。
最後，有人負責運作佢。
因為就算係最好嘅設定都唔會自行維持。
Typical OTP Setup
Single route, no fallback
Resilient OTP Delivery
點解呢個係內部難以管理
大部分公司都冇電訊營運團隊。
訊息通常由產品、工程或者營運擁有 — 同埋其他所有嘢。
所以當交付問題發生嗰陣，團隊就會作出反應。
佢哋會檢查記錄，聯絡供應商，同埋嘗試將發生緊嘅事拼湊埋一齊。
呢個方法偶爾會有效，但係 唔會擴展。
因為 OTP 嘅交付唔係靜態嘅。
佢會根據供應商、路線、地區同交通條件而改變。
如果冇持續嘅管理，可靠性就會隨住時間嘅推移而自然下降。
一個更可靠嘅方法
而唔係將 OTP 嘅交付當成靜態設定，而係可以將佢當成一個操作層噉運行。
即係話路由唔係固定嘅。
表現唔係假設嘅。
而且問題唔係每次發生都會手動處理。
使用 Flowstates ，可主動管理訊息。
流量可以分佈喺唔同嘅供應商之間。
路由可以根據性能去調整。
後備可以正確配置同管理。
當問題發生嗰陣，佢哋會被識別同升級為服務嘅一部分。
你嘅團隊唔會再協調供應商或者診斷送貨路徑。
有咩變化
當 OTP 送貨操作正常時，差異係明顯嘅。
交付變得更加一致。
失敗係處理而唔係暴露。
而且內部團隊花少啲時間去排除疑難。
你唔係對問題作出反應，而係用一個旨在吸收問題嘅系統。
當呢件事重要嘅時候
當認證係你產品嘅核心嗰陣，呢個就變得至關重要。
如果用戶依賴接收代碼嚟登入、交易或者驗證身分，可靠性就唔係選擇性嘅。
當你喺多個地區營運嗰陣，呢個亦都會變得重要，
或者當送貨問題已經影響緊客戶體驗嗰陣。
總結
OTP 送貨唔單止係訊息問題。
呢個係路由同運作問題。
修正呢個問題需要多過唔同嘅供應商。
佢需要更好嘅路由、真正嘅故障轉移、持續監控同埋清晰嘅運作擁有權。