IOSOR

IOSOR Gabay

SMS recovery week: muling buksan ang corridor gamit lamang ang sariwang patunay ng DLR

Ligtas na muling buksan ang isang SMS corridor pagkatapos ng insidente gamit ang mga heartbeat probe, sariwang pag-verify ng DLR, at kontroladong pag-scale sa IOSOR.

SMS recovery week: muling buksan ang corridor gamit lamang ang sariwang patunay ng DLR.

Bakit nabibigo ang mga bulag na pag-restart pagkatapos ng pag-freeze ng SMS

Ang muling pagpapatakbo ng trapiko sa buong volume kaagad pagkatapos ng isang Linggo ng Insidente sa SMS: I-freeze ang pagpadala bago magmukhang 'buhay pa'… ay isang karaniwang pattern ng kabiguan sa transactional messaging. Kapag ang isang upstream na ruta ay nakaranas ng tahimik na pagbagsak o pagharang ng carrier, ang pagtatapon ng libu-libong papalabas na mensahe ng OTP nang hindi bini-verify ang kalusugan ng ruta ay nagreresulta sa mataas na rate ng kabiguan, nasunog na balanse, at mga parusa sa account.

Hakbang 1: Magpadala ng mababang-volume na mga heartbeat probe

Ang isang heartbeat (HB) traffic sequence ay naghihiwalay sa mga isyu sa ruta nang hindi inilalagay sa panganib ang volume ng produksyon. Bago buksan ang buong pila, magpadala ng maliliit na solong-tatanggap na probe sa mga target na network ng carrier.

Yugto ng Probe Laki ng Sample Pangunahing Target Sukatan ng Tagumpay
HB 1 5 mensahe Pangunahing MNO 100% huling DLR
HB 2 20 mensahe Mga Sekundaryong MNO > 95% huling DLR
HB 3 100 mensahe Halo-halong Carrier Latency < 5s

Hakbang 2: I-validate ang sariwang patunay ng DLR bago mag-scale

Ang isang tugon ng tagumpay mula sa REST API endpoint ay nagpapatunay lamang na tinanggap ng gateway ang payload. Hindi nito pinatutunayan ang paghahatid sa handset. Upang muling buksan ang isang corridor nang ligtas, ang iyong engine ay dapat maghintay para sa kapani-paniwalang mga callback ng webhook ng DLR na naglalaman ng mga wastong status code.

Hakbang 3: Subaybayan ang latency ng paghahatid at mga signal ng webhook

Ang kalusugan ng corridor ay hindi binary. Kahit na ang mga mensahe ay sa wakas ay umabot sa handset, ang mga pagkaantala sa paghahatid na lumampas sa 15 segundo ay nagiging dahilan upang ang mga sensitibo sa oras na OTP code ay walang silbi.

Mag-set up ng awtomatikong pagsubaybay sa mga papasok na payload ng webhook. Subaybayan ang parehong estado ng DLR at ang delta time sa pagitan ng papalabas na timestamp ng pagsusumite at huling timestamp ng DLR. Kung tumaas ang latency, awtomatikong i-restrict ang daloy ng pila pabalik sa mga antas ng heartbeat.

Mga pinansyal na harang sa panahon ng pagbawi ng corridor

Ang pagbawi ng ruta ay may kasamang panganib sa pananalapi kung ang hindi na-verify na trapiko ay kumonsumo ng mga prepaid na balanse sa mga nasirang ruta. Nagpapatupad ang IOSOR ng mahigpit na mga panuntunan sa wallet upang maiwasan ang mabilis na pagkaubos ng balanse sa panahon ng pagsubok.

Magsimula sa IOSOR

Buksan ang konsol ng IOSOR at itakda ang apektadong koridor sa naka-gated na recovery mode bago i-unhold ang iyong mga production queue. Mag-configure ng mga low-volume heartbeat probe batch sa mga pangunahing target na network, na nangangailangan ng mga na-verify na DLR webhook callback para sa bawat test payload.

Buod ng IOSOR

Ang pagbubukas muli ng nagyeyelong SMS corridor batay lamang sa pagtanggap ng HTTP API ay nagdudulot ng mga tahimik na pagkawala at nasayang na balanse. Ang tunay na pagbawi ay umaasa sa mga sariwang DLR callback sa antas ng handset na nagkukumpirma ng positibong katayuan ng paghahatid sa mga tunay na subscriber endpoint.

Magtakda ng mahigpit na mga hangganan ng latency at maghintay para sa mga na-verify na DLR webhook bago palakihin ang trapiko lampas sa mga dami ng heartbeat. Huwag i-blast ang buong production traffic sa isang hindi na-verify na koridor kaagad pagkatapos ng pagyeyelo ng insidente.

Nakatulong ba ang gabay na ito?

Mga kaugnay na gabay