> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2021/w05-risk-exposure-of-the-payment-sdk.md).

# W05-La exposición al riesgo del SDK de pagos

En el proyecto de mejora de la experiencia de pagos B2B de Kuailv, redefinimos un conjunto de métricas por sesión de usuario para medir mejor el cambio antes y después de las mejoras. Queríamos describir de forma más objetiva la experiencia del usuario y el rendimiento del servicio B2B. Una de las tareas consistía en completar los datos reportados por la versión actual del SDK de JavaScript de acuerdo con la nueva estructura de métricas.

El SDK de JavaScript es una pieza fundamental de la caja. La gran mayoría de su tráfico utiliza los servicios de pago a través de él, con un volumen estimado de unas 500 000 llamadas diarias. Por su enorme alcance, siempre he mantenido un umbral alto para modificarlo. Su lógica es también muy estable: en el año que llevo trabajando en pagos B2B no había recibido ninguna actualización.

Añadir los datos de instrumentación requería poco desarrollo y un cambio pequeño. Sin embargo, cuando llegó el momento de publicar, lo retrasé una semana. No fue procrastinación, sino miedo. La exposición al riesgo durante todo el proceso de despliegue era tal que necesitaba tiempo para prepararme mentalmente.

La publicación del SDK se siente fuera de control: hay poca visibilidad y faltan medios de actuación en los puntos clave. El SDK está alojado en Burst. Tras ver su dashboard y su planificación, da la impresión de llevar años sin el mantenimiento necesario. Después de enviar el código, la publicación depende únicamente de un comando que ofrece Burst. Su ejecución es una caja negra. Cuando termina, significa que las máquinas de origen de Burst han actualizado los recursos. Después hay que refrescar manualmente la CDN. Es como soplar un diente de león: no sabes cómo volarán las semillas ni dónde acabarán. El progreso de la actualización en cada nodo de la CDN, si ya se ha completado y cuándo recibirán los usuarios la nueva versión pese a las cachés locales se deducen por experiencia. No hay despliegue gradual ni una forma rápida de revertir. Más importante aún, todo ocurre en silencio, sin aprobación ni notificación a las personas implicadas.

Después de publicar, solo podemos monitorear los errores internos del SDK. Para parámetros técnicos como el volumen de llamadas o la estabilidad del servicio dependemos de la información de Burst y del proveedor de CDN, cuya integridad y precisión son dudosas.

Consulté estos problemas con owl y lx. Nadie tiene una solución perfecta, pero la conversación nos dio ideas para mejorar la gestión de las publicaciones. Una gran diferencia entre un SDK de JavaScript y uno nativo es el reto de gestionar versiones cuando todo se actualiza dinámicamente. Si la URL con la que el equipo de negocio incorpora el SDK no puede cambiar, en la práctica se le oculta el concepto de versión.

Dentro del SDK hay otros problemas, como la contaminación del objeto global window. Este año incluiremos su mejora y control en la planificación frontend de B2B. Con cientos de miles de pedidos diarios todavía puede parecer un problema menor; cuando lleguemos a un millón de pedidos, será un riesgo considerable.