Cuando las capacidades del servicio en la nube ya se están volviendo escasas, y la transición a la versión en caja se considera el siguiente paso lógico para un mayor desarrollo del portal corporativo y el sistema CRM, surge la pregunta para las empresas, cómo hacerlo, qué les espera y ¿se conservará todo después de la transferencia?
Parece que todo es bastante simple:
- Expande el host con el cuadro;
- Estamos escribiendo soporte técnico;
- Pedimos una copia de seguridad;
- Esperamos recibirlo;
- Implementamos la copia de seguridad y disfrutamos de las amplias posibilidades de la versión en caja.
Pero la práctica muestra que la transición de la nube a la versión en caja está lejos de ser trivial y requiere un plan de acción claro, análisis de posibles riesgos y preparación para el hecho de que todo saldrá mal.
Nos contactó un gran desarrollador con un sistema CRM altamente cargado basado en la nube Bitrix24. Los gerentes de ventas de varias sucursales de la compañía trabajaron activamente en CRM, el portal se integró con la telefonía IP de Asterisk para crear automáticamente clientes potenciales, grabar conversaciones con clientes y registrar hechos de llamadas en una tarjeta de cliente en CRM. Se crearon más de 100 leads por día en CRM a través de varios canales.
Estaba claro que cualquier simple en el tiempo durante la transferencia a la versión en caja amenaza al cliente con grandes pérdidas. Habiendo hablado con el Cliente sobre la seriedad de la transición y los posibles riesgos, nos pusimos a trabajar.
En primer lugar, analizamos los casos y publicaciones existentes sobre la transferencia de la nube a la caja, e hicimos una lista de verificación detallada de los errores que podemos encontrar:
- Las aplicaciones que se ejecutan en la nube no están en la caja;
- El costo de las licencias para aplicaciones para la versión en la nube y la caja puede variar;
- El riesgo de perder algunos datos debido a un retraso de tiempo durante la transferencia;
- Algunos usuarios de diferentes sucursales continuarán trabajando en el servicio en la nube después de la transferencia, y será necesario buscar y transferir adicionalmente las entidades que crearon en CRM;
- En el portal cerrado, la aplicación móvil del servicio no funcionará;
- Después de la transferencia, algunos usuarios no podrán iniciar sesión con su contraseña anterior;
- Puede haber un mal funcionamiento en los bots de chat;
- Restablecimiento de autorización frecuente cuando se trabaja en el portal;
- Solo se puede mostrar una parte de los comentarios de la tarea;
- La base de datos estará sin un índice de búsqueda.
A continuación, se compiló un algoritmo claro de acciones con un desglose por roles, que tuvo que realizar tanto el Contratista como el Cliente:
1 fase (medio de urgencia)- Despliegue del entorno de producción (contratista);
- Prueba del entorno implementado (Contratista);
- Despliegue de la versión en caja en hosts (Contratista);
- Compra e instalación de un certificado SSL para telefonía (compra del cliente, instalación del contratista);
- Prueba de la versión en caja: rendimiento, parámetros, pruebas internas (Contratista).
- Implementación del entorno de Preproducción: una copia completa de Producción (Contratista).
2 fases (urgencia alta)- Solicitud de descarga de respaldo. Coordinación con el soporte técnico del servicio de la fecha de respaldo (Cliente);
- Informar a los usuarios sobre la fecha de la copia de seguridad y elaborar un plan para el almacenamiento temporal de información de CRM (Cliente);
- Implementación de una copia de seguridad en Producción (Contratista);
- Configuración del portal después de la copia de seguridad (Contratista);
- Configurar un servidor de telefonía para trabajar con el portal (Cliente);
- Configuración de un módulo de telefonía (Contratista);
- Prueba de telefonía inicial (Cliente);
- Pruebas en profundidad de CRM, telefonía, procesos comerciales de CRM (departamento de ventas al cliente);
- Declaración de salud. Eliminación de datos de prueba (Cliente);
- Detener a los gerentes de ventas en el servicio en la nube (Cliente);
- Transferencia de transacciones, clientes potenciales, contactos desde el momento de crear la copia de seguridad desde la versión de la nube a la caja (Contratista);
- Inicio del trabajo de los gerentes de ventas en la versión en caja (Cliente).
3 fases (urgencia baja)- Probar la versión en caja dentro de 2-3 días (Cliente);
- Aprobación de rendimiento completo (Cliente);
- Actualización de preproducción: transferencia de una copia completa de producción (contratista).
Después de elaborar este plan y tener una lista de verificación con posibles errores, nos dimos cuenta de que tenemos demasiados riesgos debido a la gran cantidad de incertidumbres:
- ¿Qué tan rápido proporcionará el servicio de respaldo?
- ¿Cuánto tiempo lleva implementar una copia de seguridad, dado que la base de datos CRM es enorme?
- ¿Qué tan rápido puedo reconfigurar el módulo y el servidor de telefonía para que funcionen correctamente con CRM?
- ¿Qué errores específicos pueden aparecer en el portal, qué tan críticos serán para que los usuarios trabajen y cuánto tiempo puede tomar solucionarlos?
Nos dimos cuenta de que tenemos un retraso de tiempo indefinido que, a medida que aumenta, traería más y más pérdidas para el cliente. Para minimizar el retraso de tiempo, era necesario comprender cuánto tiempo pasamos en portar el portal y depurarlo.
Así que llegamos a la conclusión de que una copia de seguridad desde la nube no será suficiente, y para minimizar las pérdidas es necesario implementar una copia de seguridad: para identificar todos los riesgos posibles y estimar el retraso, y luego una segunda copia de seguridad que podríamos planificar de manera de minimizar las pérdidas .
Bitrix proporciona solo una copia de seguridad y solo una vez, ya que el proceso de transferencia de la nube a la caja es técnicamente complicado. En cuanto al soporte técnico y conectar al Cliente con este problema, todavía tenemos el visto bueno para proporcionar dos copias de seguridad de la nube en diferentes momentos. Se acordó el momento de la primera copia de seguridad y comenzó el trabajo de transferencia.
Volumen, velocidad y piezas rotas.
Para entender cuánto y qué nos llevará tiempo, comenzamos a llevar un diario en el que registramos cada paso.
Entonces, el portal comenzó el servicio de respaldo el jueves por la noche, es decir, el CRM tenía los últimos datos al final del jueves y nos proporcionó un enlace al respaldo el viernes por la tarde. Aquí enfrentamos la primera dificultad: la copia de seguridad pesaba unos 30 GB y la velocidad de descarga de los servidores de Amazon.com que alojaban la nube distaba mucho de ser ideal (un promedio de 800 Kb / s). Habiendo calculado aproximadamente el tiempo durante el cual se cargaron varias partes de la copia de seguridad, nos dimos cuenta de que en total tomaría aproximadamente 10 horas descargar solo la copia de seguridad.
El siguiente problema fue la aparición de errores durante el bombeo de varias partes de la copia de seguridad, que se detectó solo cuando se implementó. Estas partes, como regla, también causaron un error de discrepancia de hash, debido a esto fue necesario identificar la parte rota del archivo en el texto de error y transferirlo manualmente a través de SSH, después de lo cual se reinició el desempaque desde cero de toda la copia de seguridad.
Después de descargar e implementar con éxito una copia de seguridad en nuestros hosts, recibimos una copia de trabajo de la nube en la caja y pasamos al siguiente paso: probar y depurar el portal.
Errores menores y empuje y atracción insidiosos
Para nuestra sorpresa, las pruebas de caja fueron relativamente fluidas. Probamos CRM, revisamos todas las herramientas del servicio, verificamos la funcionalidad del messenger, realizamos pruebas internas y revelamos solo 3 errores:
- El icono de archivo adjunto en el messenger desapareció y el envío de archivos en el messenger en su conjunto no funcionó;
- Los enlaces en las notificaciones tenían una dirección sin dominio, por ejemplo: empresa / personal / usuario / 1250 / tareas / tarea / vista , respectivamente, no funcionaban;
- Algunos usuarios no pudieron iniciar sesión en el portal con un error de inicio de sesión / contraseña incorrecto.
Sabíamos de la imposibilidad de iniciar sesión después de la transferencia por adelantado, el servicio nos advierte de inmediato al proporcionar una copia de seguridad. Desafortunadamente, este problema solo puede ser resuelto por los usuarios que recuperan la contraseña o cambian manualmente las contraseñas para cada usuario por el administrador, ya que las contraseñas de Bitrix24.Network no se almacenan en el portal.
El error con los enlaces en las notificaciones se resolvió lo suficientemente rápido, al registrar el dominio del portal en la configuración del sitio y en la configuración del módulo principal.
Pero el ícono de archivo adjunto que falta en el messenger generó bastantes preocupaciones. La tarea tomó un par de horas de intentos fallidos para entender la razón del ícono perdido. Como resultado, descubrimos que la razón estaba lejos de estar en el módulo de disco, como se suponía originalmente. La razón radicaba en el servidor push desconectado en la configuración del módulo push & pull, que desactivaba automáticamente la transferencia de archivos en el messenger.
Prueba final
Después de una prueba y depuración exitosas del portal, se preparó un informe detallado para el Cliente y el siguiente paso fue una prueba exhaustiva por parte del departamento de ventas del Cliente de CRM, así como configurar el servidor de telefonía para trabajar con la caja y probar las llamadas.
Durante las pruebas, no se identificaron problemas significativos. Implementamos un host de prueba y lanzamos una copia completa del portal de combate, en caso de que tuviéramos una versión 100% funcional del portal y de acuerdo con el cual pudiéramos hacer una comparación en la configuración si ocurrieran errores no estándar que no se detectaron al probar la primera copia de seguridad.
Después de desplegar una copia del portal, procedimos al análisis de la revista, en el que reparamos los errores y el tiempo para resolverlos. Después de analizar la revista en detalle, actualizamos el plan para transferir la segunda copia de seguridad, nos dimos cuenta de cuánto podemos perder leads durante la transferencia final y reservamos tiempo adicional para la importación manual de leads perdidos desde la versión en la nube. Todos los detalles y riesgos también se discutieron con el Cliente y se envió una carta al soporte técnico del servicio con una solicitud para preparar una segunda copia de seguridad.
Segunda copia de seguridad y ¿por qué puede salir todo mal?
Habiendo acordado la hora de creación de la copia de seguridad también el jueves, preparamos al equipo para acciones operativas antes de las 12 del mediodía del viernes. En la región de 12-13 horas, recibimos el enlace tan esperado y comenzamos a descargar. Unas horas más tarde, estaba claro que el archivo no se eliminaría durante 10 horas, ¡sino alrededor de 14! El ancho de banda del canal de nuestro proveedor y los servidores de Amazon.com en este día dejó mucho que desear. Nos estábamos preparando para el trabajo nocturno, ya que los cables seguían cayendo, y el Cliente estaba esperando un informe para comenzar a configurar el servidor de telefonía.
Como suele suceder, no todo salió según el plan. El siguiente paso fue transferir los leads acumulados de la versión de la nube a la caja: el proceso es simple y claro, pero tiene sus propios matices. Si en la lista de clientes potenciales selecciona aquellos clientes potenciales que necesitan exportarse y hace clic en "Exportar a CSV", todos los clientes potenciales existentes en CRM se descargarán, no solo los seleccionados. Es lógico que con una gran base de datos de clientes potenciales, la nube cayó en error. La solución fue usar un filtro, solo en este caso los cables se descargaron correctamente.
Otras pruebas pasaron sin sorpresas, como ya sabíamos: qué no funcionará, cómo solucionarlo y dónde. Después de haber conectado y probado con éxito la telefonía, el lunes los gerentes de ventas ya trabajaron completamente con CRM en la versión en caja. Y ya en funcionamiento durante una semana, sintonizamos el portal, hicimos una copia de seguridad, hicimos una copia final del portal para el host de prueba.
Todo el proceso de transferencia tomó aproximadamente una semana de trabajo desde el momento de la planificación hasta la configuración final.
Como resultado, me gustaría señalar la importancia de planificar proyectos tan complejos y riesgosos, la participación obligatoria del Cliente en el proceso y expresar los posibles riesgos, aunque, como muestra la práctica, las desviaciones del plan no son una excepción.