AiHummer прызначаны для завяршэння адказу нават у выпадку кароткага разрыву сувязі ці перазагрузкі інстанса. Гэтая старонка апісвае бачная паводзіна і дзеянні, якія адміністратара павінен прыняць. Наўмысна не патрабуецца разумець унутраную механіку дастаўкі платформы.
Што павінны бачыць карыстальнікі
Пасля таго, як карыстальнік адпраўляе паведамленне:
Сесія паказвае паведамленне, якое было прынята.
Агент апрацоўвае гэта і выдае адзін бачны адказ.
Калі канал часова недаступны, дастаўка спрабуецца зноў.
Калі канал вяртаецца, адказ з’яўляецца без неабходнасці карыстальніку адпраўляць яго.
той жа самы запыт зноў
Той жа запыт не павінен ствараць дубліраваныя відавочныя адказы. Калі кліент перападключаецца, можа быць загружана апошняя гісторыя, але сама размова застаецца адной бесперапыннай сесіяй.
Што адбываецца пасля перазапуску
Абнавіць інстанцыю, перазагрузіць хост або нечаканы перазапуск не павінны прымусіць знікнуць прыняты запыт. Праца, якую можна бяспечна працягнуць, аднаўляецца пасля таго, як інстанцыя стане здаровай. Карыстальнік павінен бачыць альбо завершаны адказ, альбо выразны стан памылкі, які можна паўтарыць.
[!NOTE]
Не паўтарайце просьбу адразу, пакуль сістэма яшчэ аднаўляецца.
Спачатку пачакайце, пакуль стан здароўя не вярнецца да нармальнага, і абнавіце сесію.
Гэта прадухіляе стварэнне сапраўды новага запыту разам з аднаўленым.
Калі адказ не прыйдзе
Адкрыць Статус і пацвердзіць, што экземпляр і пацярпелы канал з’яўляюцца
здоровы
Адкрыйце сесію і абнавіце яе адзін раз.
Праверыць Апавяшчэнні для дастаўкі або папярэджання канала
Адпраўляйце кароткае новае тэставае паведамленне толькі пасля таго, як папярэдні запыт будзе бачны
вынік паспяховасці або няўдачы
Калі праблема паўторыцца, запішыце час, сесію, канал і бачны код памылкі
затым звяжыцеся са службай падтрымкі. Ніколі не ўстаўляйце ключы API або сакрэты канала ў запыт.
Для аднаўлення канкрэтнага канала адкрыйце адпаведны даведнік па КаналыНапрыклад, медыцынскія агляды, глядзіце Systemd і праверкі стану.
Што павінны кантраляваць адміністратары
Назірайце за вынікамі, якія бачыць карыстальнік, а не за падрабязнасцямі рэалізацыі:
адказы спыняюцца на адным канале, у той час як іншыя каналы працуюць
сеансы працягваюцца выключна доўга
прыклад неаднаразова пераключаецца паміж здаровым і недаступным;
апавяшчэнні паведамляюць пра паўторныя няўдалыя дастаўкі
карыстальнікі бачаць дублікаты адказаў на адзін прыняты запыт
Гэтыя сімптомы разам з іх часовымі пазнакамі дастатковыя для таго, каб служба падтрымкі магла дыягнаставаць праблему.
AiHummer прызначаны для завяршэння адказу нават у выпадку кароткага разрыву сувязі ці перазагрузкі інстанса. Гэтая старонка апісвае **бачная паводзіна** і дзеянні, якія адміністратара павінен прыняць. Наўмысна не патрабуецца разумець унутраную механіку дастаўкі платформы.
## Што павінны бачыць карыстальнікі
Пасля таго, як карыстальнік адпраўляе паведамленне:
1. Сесія паказвае паведамленне, якое было прынята.
2. Агент апрацоўвае гэта і выдае адзін бачны адказ.
3. Калі канал часова недаступны, дастаўка спрабуецца зноў.
4. Калі канал вяртаецца, адказ з'яўляецца без неабходнасці карыстальніку адпраўляць яго.
той жа самы запыт зноў
Той жа запыт не павінен ствараць дубліраваныя відавочныя адказы. Калі кліент перападключаецца, можа быць загружана апошняя гісторыя, але сама размова застаецца адной бесперапыннай сесіяй.
## Што адбываецца пасля перазапуску
Абнавіць інстанцыю, перазагрузіць хост або нечаканы перазапуск не павінны прымусіць знікнуць прыняты запыт. Праца, якую можна бяспечна працягнуць, аднаўляецца пасля таго, як інстанцыя стане здаровай. Карыстальнік павінен бачыць альбо завершаны адказ, альбо выразны стан памылкі, які можна паўтарыць.
> [!NOTE]
> Не паўтарайце просьбу адразу, пакуль сістэма яшчэ аднаўляецца.
> Спачатку пачакайце, пакуль стан здароўя не вярнецца да нармальнага, і абнавіце сесію.
> Гэта прадухіляе стварэнне сапраўды новага запыту разам з аднаўленым.
## Калі адказ не прыйдзе
1. Адкрыць **Статус** і пацвердзіць, што экземпляр і пацярпелы канал з'яўляюцца
здоровы
2. Адкрыйце сесію і абнавіце яе адзін раз.
3. Праверыць **Апавяшчэнні** для дастаўкі або папярэджання канала
4. Адпраўляйце кароткае новае тэставае паведамленне толькі пасля таго, як папярэдні запыт будзе бачны
вынік паспяховасці або няўдачы
5. Калі праблема паўторыцца, запішыце час, сесію, канал і бачны код памылкі
затым звяжыцеся са службай падтрымкі. Ніколі не ўстаўляйце ключы API або сакрэты канала ў запыт.
Для аднаўлення канкрэтнага канала адкрыйце адпаведны даведнік па [Каналы](/be/v1.0/webui/channels)Напрыклад, медыцынскія агляды, глядзіце [Systemd і праверкі стану](/be/v1.0/operations/systemd-health).
## Што павінны кантраляваць адміністратары
Назірайце за вынікамі, якія бачыць карыстальнік, а не за падрабязнасцямі рэалізацыі:
- адказы спыняюцца на адным канале, у той час як іншыя каналы працуюць
- сеансы працягваюцца выключна доўга
- прыклад неаднаразова пераключаецца паміж здаровым і недаступным;
- апавяшчэнні паведамляюць пра паўторныя няўдалыя дастаўкі
- карыстальнікі бачаць дублікаты адказаў на адзін прыняты запыт
Гэтыя сімптомы разам з іх часовымі пазнакамі дастатковыя для таго, каб служба падтрымкі магла дыягнаставаць праблему.
## Куды далей
- [Шлюз і паваротны рухавік](/be/v1.0/architecture/gateway-turn-engine)
- [Назіральнасць](/be/v1.0/operations/observability)
- [Каналы](/be/v1.0/webui/channels)