No lo recreés todavía: cuándo abrir un ticket en Azure (y cuándo no)
Te cuento una anecdota cortita.
En una entrevista me tiraron la clásica: “¿Qué hacés si un recurso de Azure se rompe?”. Y yo, dije sin pensarlo dos veces : “Fácil, lo recreo y listo”.
El entrevistador me miró con cara de “ay no…” y me dijo: “¿Y el Soporte de Microsoft?”. Ahí entendí que no todo se arregla borrando y creando de nuevo. A veces lo mejor es frenar, mirar la salud del servicio y pedir ayuda como corresponde.
¿Cuándo conviene abrir un ticket? Cuando sospechás que el problema viene del lado de Azure y no del tuyo. Si Resource Health marca Degraded o Unavailable, si en Service Health hay un incidente justo en tu región, o si ves errores 5xx persistentes sin cambios recientes de tu parte, es señal de que no es un bug de tu app sino del servicio. También aplica si necesitás algo que solo Microsoft puede tocar, por ejemplo subir cuotas, destrabar límites, revisar metadatos del backend, o dudas de facturación y SLA. En esos casos, no lo dudes, andá a Help + Support y contá la historia con datos.
¿Cuándo no conviene abrirlo? Cuando todavía no revisaste lo básico. Mirá primero Service Health, Resource Health y el Activity Log, son un trucazo y tardás nada. Si hiciste un deploy hace cinco minutos, probá un rollback antes de culpar al universo. Si es una duda de configuración que está en la documentación, mejor armá un pequeño lab y validá. Y si estás usando una feature en Preview, recordá que puede comportarse raro por diseño. Abrir un ticket sin info clara, el famoso “no anda”, solo te va a hacer perder tiempo a vos y al ingeniero de soporte.
Para que el ticket sea útil, contá cuándo empezó el problema, en UTC por favor, en qué región, cuál es el recurso afectado, pegá el Resource ID, y copiá el mensaje de error exacto, sin traducciones creativas. Sumá logs crudos, métricas y, si es intermitente, cuántas veces pasa en X minutos. Decí el impacto real, ambiente prod o dev, usuarios, plata o KPIs afectados. Si inflás la severidad por que sí, la próxima nadie te va a creer. Mejor ser preciso que dramático.
El paso a paso es simple, casi sin misterio. Entrás al portal, Help + support, Create a support request, elegís tipo de problema, técnico o billing, la suscripción y el servicio o recurso. Después escribís la historia con todos los datos, desde cuándo, qué cambió, cómo se reproduce, qué ya probaste, reinicio, swap, rollback, etc. Elegís severidad acorde al impacto y adjuntás evidencia. Listo. Desde ese mismo lugar das seguimiento y hablás con el ingeniero que te asignen.
Algo que me sirvió un montón: antes de abrir, hago una mini checklist mental. Vi Service Health, revisé Resource Health, hay algo sospechoso en Activity Log, tengo timestamps en UTC y el error copiado textual, probé volver a la versión anterior. Si tacho esas casillas, el ticket sale más redondo y me responden mas rapido. Parece obvio, pero cuando hay presión uno se saltea pasos y después se arrepiente.
También aprendí a cerrar bien los casos. Cuando llega la solución, anoto lecciones aprendidas, alertas nuevas, métricas que faltaban, límites que ajustar, circuit breakers, lo que sea. Así la próxima no me agarra con la guardia baja. Y sí, a veces recrear el recurso es válido, pero solo cuando ya entendiste el problema y sabés que no vas a borrar la evidencia que podría ayudarte a vos o a Microsoft a entender que pasó.
Si te sentiste identificado con mi metida de pata, estamos en la misma. La próxima vez que algo falle, respirá hondo, mirá la salud del servicio, juntá pruebas y, si aplica, abrí soporte.
Te prometo que vas a ahorrar tiempo y vas a quedar mejor parado en tu equipo y en la próxima entrevista también.
Contame tu historia, cuándo pediste ayuda a tiempo y te salvó el dia.