Mejore la disponibilidad en su organización ☁️

Piense en un momento en el que su solución no funcionó como se esperaba. Tal vez sus usuarios experimentaron un rendimiento deficiente al actualizar un registro que tenía numerosos activadores de Apex, o una integración con la API REST de Salesforce se vio abrumada por un gran volumen de llamadas debido a un evento. Estas experiencias pueden ser desde inconvenientes menores hasta una interrupción total del servicio para sus usuarios. La buena noticia: a menudo, estos incidentes de disponibilidad limitada se pueden prevenir pensando en el futuro y codificando de manera eficiente con la disponibilidad y la resiliencia como prioridad.

¿Qué es la disponibilidad?

La disponibilidad es el porcentaje de tiempo que un servicio maneja con éxito las solicitudes. Salesforce mide y rastrea este porcentaje para asegurarse de que nuestros servidores y servicios estén altamente disponibles para cada cliente.

Si bien la disponibilidad del servidor y del servicio es fundamental para Salesforce, la disponibilidad experimentada por el cliente lo es aún más, lo que se relaciona directamente con la forma en que los usuarios experimentan Salesforce. Por ejemplo, ¿pueden los usuarios iniciar sesión en su organización y actualizar registros de forma rápida y confiable? ¿Se actualizan los datos a través de las API de manera eficiente y sin errores?

La disponibilidad experimentada por el cliente es difícil de medir, ya que cada organización, usuario y empresa es única. La experiencia de un usuario puede variar mucho según muchos factores, como el código Apex y el diseño del componente Lightning, la región geográfica y la conexión de red. A pesar de la variabilidad de estos factores, Salesforce considera que la disponibilidad es una prioridad principal como parte de nuestro valor central de confianza.

¿Por qué debería importarme la disponibilidad?

La disponibilidad, o la falta de ella, afecta a todos: a usted, a sus usuarios ya su empresa. Una organización de alta disponibilidad significa que sus usuarios pueden continuar con sus responsabilidades mientras respaldan el crecimiento de su empresa. Una organización que se desempeña de manera deficiente o poco confiable crea frustraciones y, en casos extremos, podría afectar financieramente o en la reputación de su empresa.

Como desarrollador, la forma en que codifica su solución de Salesforce tiene un impacto directo en la experiencia de sus usuarios. Es importante que su código no solo satisfaga los requisitos funcionales y comerciales, sino que sus usuarios puedan interactuar con confianza y ejecutar el código que escribió, siempre que lo necesiten.

¿Qué antipatrones de disponibilidad común debo evitar?

Como desarrollador, esté atento a estos antipatrones comunes y haga preguntas críticas para evitarlos.

Anti-patrón #1: Diseños de integración frágiles

Si bien es fácil concentrarse en el "camino feliz" de una integración y codificar algo simple, ¿cómo resiste su integración las excepciones o la presión? Aquí hay algunas preguntas comunes para hacer antes de codificar una integración:

• ¿Cuál es el volumen esperado de datos que pasarán por la integración y a qué velocidad? La API REST de Salesforce puede insertar o actualizar 200 registros a la vez. Realizar una llamada a la API para actualizar 200 registros es mucho más rápido y utiliza mucha menos capacidad del servidor que tener 200 llamadas a la API para actualizar un registro cada una.
• ¿Puede su integración cambiar entre REST y Bulk API según el volumen y la velocidad de los datos que ingresan?
• ¿Qué sucede si la lógica de validación, activación o Flujo cambia en Salesforce en el futuro y luego rechaza la actualización del registro en la API?
• ¿Qué pasa si Salesforce está fuera de servicio por mantenimiento? ¿Puede la integración retener llamadas API pendientes y reprocesarlas cuando Salesforce está disponible? ¿Puede el backlog manejar eficientemente el alto volumen de transacciones?
• ¿Cómo se manejan los errores inesperados? ¿Se registran y notifican los errores de la API de Salesforce para que su equipo los investigue?

Aborde estas preguntas desde el principio en el diseño de la integración y garantice una integración más confiable, resistente y adaptable durante situaciones imprevistas.

Antipatrón n.º 2: falta de visibilidad lógica de Apex en su "marco de activación"

Es fantástico que tantos desarrolladores estén adoptando el concepto de un marco de activación para modularizar y administrar fácilmente la lógica de Apex. Sin embargo, hemos visto que este tipo de framework también puede ser un arma de doble filo, por ejemplo:

• Múltiples equipos de desarrollo están trabajando en la lógica de Apex que recurre al disparador antes/después del mismo objeto. Sin embargo, los equipos no tienen visibilidad del trabajo de los otros equipos. Como resultado, la lógica de Apex combinada consume una mayor parte de los límites de Apex y supera los límites del regulador.
• Organizaciones que tienen lógica repartida entre flujos, Process Builders, flujos de trabajo y código Apex. Esto consume una cantidad significativa de la capacidad del servidor cuando se ejecuta y puede causar conflictos lógicos e infracciones del límite del gobernador, sin mencionar una pesadilla de mantenimiento con una deuda tecnológica considerable.

Para evitar conflictos, haga las siguientes preguntas cada vez que usted o su equipo planeen agregar nueva lógica o procesos a su marco de activación:

• ¿Qué otra lógica se ejecutará junto con lo que estoy a punto de codificar? ¿Cuánto de los límites del gobernador están consumiendo ya y cuánto puedo usar?
• ¿Se puede combinar mi lógica con otra lógica? Por ejemplo, ¿podemos compartir consultas SOQL existentes y agregar uno o dos campos más a la consulta? ¿Se pueden agrupar las actualizaciones de campos de registro en otra lógica que tenga declaraciones DML existentes?
• ¿Agregarán otros desarrolladores o administradores más lógica a la organización, con o sin disparadores o flujos? ¿Cómo nos coordinamos para que la lógica adicional no entre en conflicto con lo que hago?
• ¿Puedo hacer más con menos? Guardar una consulta SOQL o una declaración DML puede no parecer mucho. Sin embargo, si su organización tiene miles de transacciones en una hora, puede guardar miles de consultas a la base de datos y liberar capacidad del servidor, lo que significa que es menos probable que su organización experimente una degradación del rendimiento.

Antipatrón n.º 3: Despliegue no estructurado durante las horas pico

La mayoría de los incidentes de disponibilidad ocurren cuando se realizan cambios en la configuración de su organización en producción. Puede pensar que se deben a cambios no probados. Sin embargo, el problema más común causado por la implementación proviene de los trabajos en segundo plano que se ejecutan debido a un cambio de metadatos. Por ejemplo:

• El cambio de campos personalizados en objetos con millones de registros hace que toda la tabla de la base de datos se active en esos registros en segundo plano.
• La implementación de código nuevo invalida el código de Apex compilado existente y activa un trabajo en segundo plano en la recompilación de Apex.

Estos trabajos en segundo plano también consumen capacidad del servidor que podría usarse para atender las interacciones de los usuarios y las llamadas a la API. Cuando se ejecutan durante las horas de trabajo pico de su organización, aumenta el riesgo de sobrecargar el servidor y perjudicar la experiencia de sus usuarios.

Este problema se puede agravar aún más con los cambios de metadatos no estructurados, como cambiar manualmente un campo personalizado a través de la interfaz de usuario de configuración y luego pasar a realizar otro cambio manual en un campo personalizado diferente.

La próxima vez que planee implementar código, considere cómo puede hacerlo de manera más eficiente y formule las siguientes preguntas:

• ¿Cuál es el mejor momento para implementar código que minimice el riesgo de interrupción del usuario?
• ¿Cómo puedo agrupar todos mis cambios para implementarlos al mismo tiempo? (Sugerencia: ¡ Salesforce DX y DevOps Center !)
• ¿Hay también otras implementaciones de otros equipos? ¿Podemos trabajar para implementar de manera eficiente sin entrar en conflicto entre nosotros?

Antipatrón n.° 4: falta de registros o alertas de depuración significativos

Al desarrollar una solución de Salesforce, está atendiendo las necesidades de los usuarios comerciales, los administradores y el equipo de operaciones de TI. Están ejecutando y administrando su organización, y es fundamental que sepan cómo funciona la organización y cuándo responder si se producen errores. Necesitan visibilidad de cualquier lógica compleja que introduzca en la organización. La mejor manera de proporcionar eso es a través del registro de depuración y garantizar que las alertas de error lleguen a ellos.

Hágase estas preguntas para dar a sus administradores y personal de operaciones de TI visibilidad de las operaciones de su código:

• ¿Cómo pueden saber si mi código funciona como se espera y cuánto utilizan los usuarios?
• ¿Qué tipo de errores pueden ocurrir en mi código? ¿Cómo puedo alertar de esos errores a los administradores y al equipo de operaciones de TI de manera efectiva?
• Si quieren clasificar y diagnosticar problemas potenciales, ¿cómo pueden ver cómo se ejecuta mi código sin abrumarlos con cada línea de código?

Anti-patrón #5: Mentalidad de “Arreglarlo primero” durante emergencias

Los desarrolladores a menudo reciben un aviso cuando una organización encuentra un problema que impide que los usuarios realicen funciones comerciales clave. Por lo general, se enfocan en "solucionar el problema" para devolver el servicio a los usuarios. Sin embargo, durante un incidente de disponibilidad de emergencia, esto puede ser perjudicial.

Durante un incidente, el orden de prioridad de las operaciones debe ser minimizar el impacto comercial, recuperar las operaciones del sistema y luego encontrar y corregir la causa raíz.

Cuando se le pida que analice un problema durante un incidente, pregúntese:

• ¿Cómo se ven afectados los usuarios por el incidente en este momento? ¿Cómo puedo minimizar rápidamente su impacto?
• ¿El incidente es causado por un cambio reciente? En caso afirmativo, ¿puedo revertir el cambio?
• ¿Cómo permito que los administradores y el equipo de operaciones de TI evalúen el incidente? ¿Pueden recopilar detalles valiosos sobre el incidente, de modo que pueda abordar directamente el problema y poner las operaciones en línea?

No olvide realizar una autopsia después de un incidente para investigar la causa raíz y solucionar el problema. Esto debería suceder después de que se solucione un incidente.

Más sugerencias para mejorar la disponibilidad en su organización

Es un curso intensivo sobre cómo usted, como desarrollador y su código, pueden mejorar la disponibilidad de su organización. No esperamos que se convierta en un experto de inmediato, pero puede comenzar a mejorar la disponibilidad hoy:

• Tener curiosidad acerca de su organización y su diseño. Si ve una ineficiencia existente, agréguela al trabajo pendiente para investigar.
• Haciendo preguntas. Si se le asignan requisitos para el código, pero implicaría soluciones que podrían crear problemas de escalabilidad en el futuro, sea proactivo al señalar los posibles riesgos de disponibilidad durante la revisión del diseño para asegurarse de que estén cubiertos mientras escribe su código.
• Manténgase actualizado sobre las mejores prácticas utilizando la Ayuda de Salesforce y el sitio web de desarrolladores de Salesforce . Si no puede encontrar una respuesta, consulte Trailblazer Community .
• Seguir aprendiendo. Utilice Trailhead para mantenerse actualizado y familiarizarse con lo último y lo mejor que sale de Salesforce.

Tenemos varios recursos para ayudarlo en el camino. Consulte Disponibilidad de Salesforce , un nuevo sitio web lanzado para ayudarlo a mejorar la disponibilidad de su implementación. Además, la nuevaAyuda y capacitación sobre disponibilidad cubre las mejores prácticas de disponibilidad con más detalle. También estamos trabajando en estrecha colaboración con Well-Architected para garantizar que estos conceptos estén bien integrados en un marco único para que todos los profesionales de Salesforce los sigan. Esté atento a medida que implementamos más herramientas y recursos para ayudar a mejorar la disponibilidad en el futuro cercano.

Sobre el Autor

Jsun Pe es director de gestión de productos en servicios de ingeniería de disponibilidad e infraestructura en Salesforce, y se enfoca en permitir que los clientes de Salesforce construyan soluciones de Salesforce resistentes y de alta disponibilidad. Desde que comenzó en el ecosistema de Salesforce en 2009, fue testigo del crecimiento de la Plataforma de Salesforce mientras obtenía su credencial de Arquitecto técnico certificado de Salesforce. Jsun ayudó a desarrollar prácticas técnicas para los principales socios de consultoría en Australia y Nueva Zelanda, luego se unió a Salesforce en 2016. Durante este tiempo, descubrió su interés en las consideraciones de arquitectura avanzada en el rendimiento y la disponibilidad de la plataforma, lo que finalmente lo llevó a su puesto actual.