Analyse

L'analyse IBM® watsonx™ Assistant fournit des statistiques de présentation sur le nombre d'interactions avec les utilisateurs et les taux de confinement. Les analyses ne cumulent pas les statistiques d'une région à l'autre. Avec une topologie active / passive, cette approche de l'analyse est suffisante. Toutefois, l'utilisation d'une topologie active / active nécessite probablement que vous utilisiez des webhooks pour collecter des données d'interaction et générer des entrepôts de données personnalisés et des rapports pour comprendre l'utilisation totale.

Historique des sessions pour la discussion Web et l'interface de programmation v2

L'historique de la session permet à vos discussions Web de conserver l'historique et le contexte de la conversation lorsque les utilisateurs rafraîchissent une page ou passent à une autre page du même site Web. Cette fonction ne fonctionne pas dans les instances, donc les conversations en cours doivent être redémarrées.

Facturation

IBM calcule votre facture en fonction du compte IBM Cloud. IBM® watsonx™ Assistant calcule les métriques de la moyenne mensuelle des utilisateurs (MAU) en les agrégeant dans une instance de service spécifique comme suit:

• La même unité d'accès multi-station utilisée dans 2 ressources assistantes différentes dans la même instance de service compte comme 1 unité d'accès multistation
• La même unité d'accès multi-station utilisé dans 2 ressources assistant différentes dans des différentes instances de service compte pour 2 unités d'accès multistation.

Pour une topologie active / active, dans le scénario le plus défavorable, le nombre de MAU peut être doublé pour une période de facturation.

Monitoring

Les fournisseurs de commutation automatique de canaux du protocole SIP peuvent être configurés pour procéder activement à un diagnostic d'intégrité des contrôleurs de bordure de session watsonx Assistant (SBCs) en envoyant des messages d'OPTIONS de protocoles SIP périodiques à chaque zone d'une région. Un échec de réception d'une réponse peut être utilisé pour fournir une notification d'échec de déclenchement d'une reprise en ligne manuelle ou pour automatiser le retrait de la zone ayant échoué de la liste des routes.

Reprise en ligne

Le fournisseur de commutation automatique de canaux de protocole SIP joue un rôle important dans la détection et la gestion d'une reprise en ligne, en particulier si une reprise en ligne automatique est attendue entre les régions. Généralement, les fournisseurs de liaisons SIP doivent être configurés pour traiter chaque zone d'une région comme active / active et deux régions où un assistant est configuré comme active / passive. Les fournisseurs de commutation automatique de canaux SIP doivent toujours être configurés pour équilibrer la charge et le basculement entre les zones d'une même région.

Indisponibilité complète

Les échecs d'intégration téléphonique ont deux types. Le premier type est une indisponibilité complète où les contrôleurs de bordure de session dans les 3 zones régionales deviennent inaccessibles. Ce type d'indisponibilité est plus facile à détecter et à gérer car le fournisseur de liaisons SIP est immédiatement informé par les délais d'attente SIP que l'appel échoue et peut être configuré pour basculer automatiquement ou le routage d'appel peut être reconfiguré manuellement au niveau du fournisseur de liaisons SIP pour diriger le trafic de la région ayant échoué vers la région de sauvegarde passive. Si une reprise en ligne est automatisée et qu'une sauvegarde régionale est activée, il est toujours préférable d'essayer d'abord une zone différente et de rediriger le trafic vers la région de sauvegarde passive uniquement si un nombre préconfiguré d'échecs se produit au cours d'une courte période. Cela empêche une reprise en ligne inutile entre les régions si une courte interruption se produit.

IBM® watsonx™ Assistant fournit un nom de domaine complet (FQDN) qui inclut les adresses IP de chaque zone de la région. De nombreux fournisseurs de commutation automatique de canaux de protocole SIP réessayent automatiquement chaque adresse IP dans le RQDN lorsque des défaillances se produisent. Pour prendre en charge la reprise après incident, le fournisseur de services peut avoir besoin de configurer deux liaisons SIP distinctes, une pour chaque région, et uniquement lorsque toutes les zones d'une même région échouent si l'appel est commuté vers la région de secours. Il est important de définir les dépassements de délai d'attente INVITE SIP au niveau du fournisseur de commutation SIP suffisamment bas pour éviter les temps d'attente de configuration des appels longs lorsqu'une reprise en ligne est en cours.

Indisponibilité partielle

Le deuxième type d'échec est une panne de service partielle dans la région. Une indisponibilité partielle est beaucoup plus difficile à détecter et à gérer en raison du grand nombre de variations dans les pannes de service qui peuvent se produire dans une région. Parfois, de petits problèmes affectent les caractéristiques de performance de l'appel mais ne provoquent pas l'échec de l'appel.

Pour les problèmes qui entraînent en fin de compte l'échec d'un appel, il existe deux manières dont votre assistant peut traiter l'appel. Le premier est d'accepter l'appel, puis de le transférer vers un identificateur URl de protocole SIP configuré par défaut. Vous pouvez configurer ce paramètre dans l'intégration téléphonique et il est également utilisé pour les échecs d'appel intermédiaire. L'URI SIP de la cible de transfert par défaut est défini dans la zone Cible SIP en cas d'échec d'un appel qui se trouve dans l'onglet Avancé de la configuration d'intégration téléphonique.

L'intégration téléphonique peut également être configurée pour répondre à un message SIP INVITE avec un message SIP 500 (service non disponible) si une indisponibilité est détectée lors de la configuration de l'appel au lieu de transférer un appel vers un agent actif. Un SIP 500 peut ensuite être utilisé pour rediriger l'appel vers une autre zone, ou si un grand nombre de SIP 500 sont reçus, dans une autre région. L'utilisation d'une erreur INVITE SIP 500 est une meilleure façon de signaler un échec à un fournisseur de commutation SIP en amont car il permet au fournisseur de réacheminer l'appel. L'utilisation uniquement de la cible de transfert par défaut pour gérer les échecs d'appel est acceptable pour les scénarios de faible volume d'appels, mais peut entraîner un grand nombre d'appels qui sont dirigés vers un centre de contact client lorsque des volumes d'appels plus importants sont gérés par votre assistant. Pour activer cette fonction de réponse aux erreurs 500 pour une instance spécifique, vous devez adresser une demande à IBM.

Vous devriez planifier à la fois des pannes de service complètes et partielles. Une première étape consiste à planifier un basculement manuel entre les régions avant d'activer l'automatisation. Vous avez besoin d'une réplique complète de watsonx Assistant dans les deux régions, y compris tous les entraînements de modèles vocaux personnalisés. Lorsque l'automatisation est activée, il est préférable de commencer par une stratégie de détection et de reprise sur la région de sauvegarde passive lorsqu'une indisponibilité régionale complète est détectée. Après l'implémentation, développez une stratégie pour gérer les indisponibilités partielles, qui doit couvrir la plupart des conditions d'échec pouvant se produire avec un déploiement d'intégration téléphonique.

Monitoring

La discussion Web fournit une fonction d'écoute onError qui permet à la page hôte de détecter des types d'erreurs d'indisponibilité spécifiques, en particulier les erreurs INITIAL_CONFIG, OPEN_CONFIG et MESSAGE_COMMUNICATION.

Pour plus d'informations, voir écoute des erreurs.

Reprise en ligne

La gestion d'une reprise en ligne pour la discussion Web est simple, en supposant que vous avez configuré une intégration de discussion Web supplémentaire dans une autre région. Lorsque la reprise en ligne doit être déclenchée manuellement, procédez comme suit :

• Le script d'imbrication qui contient votre ID d'intégration, votre région, votre ID d'instance de service et votre ID d'abonnement (le cas échéant) doit être modifié ou mis à jour pour utiliser les ID de la nouvelle intégration et de la nouvelle région.
• Si vous utilisez des intégrations Salesforce ou ZenDesk pour la connexion à des agents humains, mettez à jour la configuration dans ces systèmes pour vous assurer qu'ils peuvent communiquer avec l'intégration correcte. Suivez les instructions de l'onglet Agent actif dans la configuration de discussion Web pour configurer ces systèmes. Cette fonction n'est nécessaire que pour obtenir l'historique des conversations de l'agent.
• Si vous activez la sécurité de la discussion Web et que vous utilisez des contenus chiffrés, la clé publique fournie par IBMqui est utilisée pour le chiffrement peut être différente en fonction de la région. Si tel est le cas, vous devez mettre à jour le système qui génère le jeton Web JSON (JWT) pour utiliser la clé correcte.

Vous pouvez configurer une configuration active / active de la discussion Web en utilisant différents ID d'intégration dans vos scripts imbriqués, et en vous assurant que l'intégration de discussion Web est "collante" par l'utilisateur. Sinon, si l'utilisateur bascule sur une autre intégration, l'historique de la conversation peut être perdu.

Monitoring

Capturez et surveillez les codes de réponse des appels /message. Les codes de réponse du trafic /message actif doivent être capturés et agrégés.

Dans l'idéal, sauvegardez les statistiques du code de réponse dans un magasin de persistance externe. Ce magasin partagé peut agréger les résultats de code de réponse de toutes les instances déployées de votre application et fournir la plus grande fidélité pour déterminer si une reprise en ligne doit être déclenchée.

Les codes de réponse peuvent également être agrégés et évalués en mémoire pour une instance de votre application. Etant donné que seule une fraction du trafic contribue à la décision de reprise en ligne, cela peut affecter la fréquence à laquelle la décision de reprise en ligne est prise.

Avec l'une ou l'autre approche d'agrégation, le dépassement d'un seuil défini peut déclencher une reprise en ligne. Les approches générales pour déterminer une reprise en ligne sont les suivantes :

• Pourcentage basé: plus de X % des demandes renvoient un code de réponse non-200
• Consécutive: les appels X d'une ligne renvoient un code de réponse non-200
• Basé sur les limites: X appels renvoient une réponse non-200 dans un délai

Pour éviter une reprise en ligne inutile entre les régions, assurez-vous qu'un mécanisme de relance robuste est présent lors de l'appel du noeud final /message.

Reprise en ligne pour l'interface de programmation sans état v1 et v2

Pour une reprise en ligne réussie:

• Les changements de données de formation devraient être synchronisés entre les régions. Evitez d'envoyer des modifications retardées sur une longue période (par exemple, des jours) afin d'atténuer le risque de modifications d'algorithme déployées par watsonx Assistant entre les régions en cours de mise à jour.
• Le même compte IBM Cloud doit être utilisé pour les instances de service d'une région à l'autre afin de conserver une facturation globale unique pour les services.
• Les applications client doivent prendre en charge :
  • Nom d'hôte de l'API IBM® watsonx™ Assistant
  • Données de l'instance de service
  • v1: id_espace_travail
  • v2: id_assistant

Bien qu'il n'affecte pas le flux d'exécution de l'appel de /message, si vous utilisez un contrôle d'accès à granularité fine qui utilise IBM Identity and Access Management (IAM), assurez-vous que les règles IAM sont synchronisées entre les régions.  IAM est un service global, mais les ressources personnalisées (assistants et compétences) utilisées par le contrôle d'accès watsonx Assistant signifient que chaque région, qui possède des ressources spécifiques, requiert des règles spécifiques.

Pour une topologie Active / passive , une forme demodèle de rupture de circuit peut être utilisée. Une seule instance de service dans une région est utilisée exclusivement sauf si des erreurs sont détectées.A ce stade, le système peut répondre en mettant à jour les métadonnées de reprise en ligne appropriées pour acheminer le trafic vers l'instance de service dans l'autre région. Lorsqu'une reprise en ligne se produit, vous pouvez décider de continuer à utiliser la nouvelle région comme instance active ou si vous souhaitez reprendre l'utilisation de la région initiale lors de sa stabilisation.

Pour une topologie active / active, une certaine forme d'équilibrage de charge peut être utilisée, où deux ou plusieurs instances de service dans des régions différentes reçoivent toujours un pourcentage de trafic. Il faudrait établir une logique supplémentaire pour déterminer quand retirer une région de la rotation. Cette logique de surveillance peut utiliser un modèle de coupure de circuit similaire à la configuration active / passive ou s'appuyer sur une infrastructure de surveillance dédiée distincte qui détermine la santé de la région. À l'instar de la méthode active / passive, la détermination du moment où une région doit être réinsérée en rotation devrait également être prise en considération.

Reprise en ligne pour l'interface de programmation avec état de v2

La reprise en ligne pour l'interface de programmation avec état v2 est similaire à celle sans état, avec ces détails à prendre en compte :

• L'état d'une conversation est conservé par watsonx Assistant dans une base de données liée à une région particulière. Par conséquent, une reprise en ligne pour le v2 /message avec état peut être plus perturbante.
• Pour une topologie Active / passive, vous devez supposer que toutes les conversations en cours sont terminées.
• Pour une topologie active / active, compte tenu des contraintes de persistance verrouillées dans la région de l'architecture v2 stateful /message, tous les échanges (appels d'API /message ) d'une conversation (session) doivent se produire dans la même région.