Name: Astervis
Availability: InStock
Author: Astervis

Asterisk asosidagi call-markazni boshqarish poyga avtomobilini sozlashga o'xshaydi. Dvigatel (Asterisk) juda kuchli, lekin to'g'ri optimizatsiyasiz siz ham unumdorlikni, ham pulni yo'qotasiz.

Asterisk call-markazlari haqidagi ko'pchilik qo'llanmalar yo tayyor o'rnatish bosqichini, yo tor doiradagi texnik sozlamalarni yoritadi. Bu qo'llanma boshqacha. Biz hammasini ko'rib chiqamiz: Asterisk'ning tizim darajasidagi unumdorlik sozlamalaridan tortib navbatlar konfiguratsiyasi, operatorlarni boshqarish, chaqiruvlar marshrutizatsiyasini optimallashtirish, monitoring strategiyalari va foydaga bevosita ta'sir qiladigan operatsion amaliyotlargacha.

10 ta operator bilan ishlaysizmi yoki 200 ta bilan — bu qo'llanma Asterisk call-markazingizdan maksimal unumdorlikni siqib olishga yordam beradi.

Asterisk call-markazini optimallashtirish nega muhim

"Qanday" degan savolga o'tishdan oldin "nega" degan savolni raqamlarda ko'rsatamiz:

Optimizatsiya yo'nalishi	Odatiy natija	Daromadga ta'siri
Navbatda kutish vaqtini qisqartirish	30-50% kamayish	Tashlab ketilgan chaqiruvlar 15-25% kam
Operatorlar bandligini oshirish	15-20% o'sish	Xuddi shu hajm, kamroq operator bilan
Birinchi chaqiruvda hal qilishni oshirish	10-15% yaxshilanish	Takroriy chaqiruvlar 20-30% kam
Tizim unumdorligini sozlash	Bir vaqtdagi chaqiruvlar sig'imi 2-3 barobar	Uskuna yangilash keyinga suriladi
Marshrutizatsiyani optimallashtirish	Masala 20-30% tezroq hal bo'ladi	CSAT yuqori, chiqib ketish past

50 operatorli, kuniga 500 chaqiruvni qayta ishlaydigan call-markaz uchun samaradorlikning atigi 10% oshishi yiliga $50 000-$150 000 tejamkorlikni anglatadi.

1-qism. Asterisk unumdorligini tizim darajasida sozlash

1.1 Uskuna va OS optimizatsiyasi

Asterisk konfiguratsiyasiga tegishdan oldin poydevor mustahkamligiga ishonch hosil qiling:

CPU bo'yicha e'tiborga olinadigan jihatlar:

—Asterisk chaqiruvlarni asosan bitta oqimda qayta ishlaydi, ammo PJSIP va Stasis uchun bir nechta oqimdan foydalanadi
—G.711 (ulaw/alaw) kodeklari CPU'ni deyarli yuklamaydi; G.729 transkodingi esa resurstalab
—Amaliy o'lchov: bitta zamonaviy CPU yadrosi taxminan 200 ta bir vaqtdagi G.711 chaqiruvni tortadi
—Suhbatlar yozuvi yoqilgan call-markazlarda CPU zaxirasiga 30% qo'shing

Xotira:

—Bazaviy Asterisk: ~50-100 MB
—Har bir bir vaqtdagi chaqiruv uchun: ~2-4 MB (yozuv bilan: ~8-10 MB)
—CDR/CEL qayta ishlash: ~50-100 MB bufer
—Tavsiya: 50 operator uchun kamida 4 GB, 100+ uchun 8 GB

Disk:

—Suhbat yozuvlari: yozuvning har bir soatiga 1 GB rejalashtiring (G.711)
—CDR bazasi: har bir chaqiruv yozuvi uchun ~1 KB
—CDR bazasi va aktiv yozuvlar uchun SSD ishlating
—Eski yozuvlarni HDD yoki bulutli xotiraga arxivlang

Linux yadrosini sozlash:

# /etc/sysctl.conf - Asterisk call-markazlari uchun asosiy sozlamalar

# Fayl deskriptorlari limitini oshiramiz
fs.file-max = 655350

# Tarmoq buferlarini optimallashtirish
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 65536
net.core.wmem_default = 65536

# SIP uchun conntrack hajmini oshiramiz
net.netfilter.nf_conntrack_max = 131072

# TIME_WAIT holatidagi soketlarni kamaytiramiz
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# Swap'ga moyillikni pasaytiramiz (Asterisk RAM'da qolsin)
vm.swappiness = 10

# /etc/security/limits.conf
asterisk  soft  nofile  65536
asterisk  hard  nofile  65536
asterisk  soft  nproc   8192
asterisk  hard  nproc   8192

1.2 PJSIP threadpool optimizatsiyasi

PJSIP threadpool Asterisk SIP-tranzaksiyalarni qanchalik tez qayta ishlashini bevosita belgilaydi:

; pjsip.conf - [system] bo'limi
[system]
type=system

; 50+ operatorli call-markaz uchun
threadpool_initial_size=20
threadpool_auto_increment=5
threadpool_idle_timeout=120
threadpool_max_size=100

; Nosozlikni tezroq aniqlash uchun SIP taymerini kamaytiramiz
timer_t1=100
timer_b=6400

Call-markaz hajmiga qarab o'lcham tanlash:

Operatorlar	Initial Size	Max Size	Auto Increment
10-25	10	50	5
25-50	20	100	5
50-100	30	150	10
100-200	50	200	10
200+	80	300	15

1.3 Stasis message bus sozlamalari

Stasis shinasi AMI hodisalarini, CDR qayta ishlashni va ARI'ni yuritadi — bularning bari call-markaz monitoringi uchun kritik:

; stasis.conf
[threadpool]
initial_size = 10
idle_timeout_sec = 120
max_size = 60

Maslahat: agar AMI kerak bo'lmasa (masalan, alohida analitika vositasidan foydalanayotgan bo'lsangiz), res_manager modulini o'chirish band tizimlarda CPU yukini 5-10% pasaytiradi.

1.4 Endpoint identifikatsiyasi tartibi

Kichik, ammo sezilarli optimizatsiya — avval ro'yxatdan o'tgan telefonlarni qayta ishlash:

; pjsip.conf - [global] bo'limi
[global]
type=global
; Telefonlar registratsiya qiladi (username), trunklar IP orqali ishlaydi
endpoint_identifier_order=username,ip,anonymous

Shunda Asterisk har bir ro'yxatdan o'tgan telefon uchun IP asosidagi qoidalarni ko'rib chiqmaydi va har tranzaksiyada millisekundlarni tejaydi — katta hajmda bu sezilarli farq beradi.

2-qism. Navbatlar konfiguratsiyasini optimallashtirish

Aynan navbatlar sozlamalarida ko'pchilik call-markazlarda eng katta optimizatsiya imkoniyati yashiringan. Noto'g'ri sozlangan navbat operatorlar vaqtining 20-30% ini yeb ketadi.

2.1 Navbat strategiyasini tanlash

To'g'ri tanlangan qo'ng'iroq strategiyasi ham operatorlar bandligini, ham mijozlarning kutish vaqtini keskin o'zgartiradi:

; queues.conf
[sales]
strategy = rrmemory        ; Xotirali doiraviy taqsimlash
timeout = 15               ; Operatorga 15 soniya qo'ng'iroq qilamiz
retry = 1                  ; Taymautdan keyin darhol takrorlash
wrapuptime = 10            ; Chaqiruvlar orasida 10 soniya yakunlash vaqti
maxlen = 50                ; Navbatda maksimum 50 ta mijoz

[support]
strategy = fewestcalls     ; Eng kam chaqiruv olgan operatorga yo'naltiramiz
timeout = 20               ; Support uchun biroz uzunroq qo'ng'iroq
retry = 1
wrapuptime = 30            ; Murakkab chaqiruvlar uchun ko'proq yakunlash vaqti
maxlen = 30

Call-markazlar uchun strategiyalar taqqoslovi:

Strategiya	Nimaga mos	Afzalliklari	Kamchiliklari
`ringall`	Kichik jamoalar (<5)	Eng tez javob	Notekis taqsimot
`rrmemory`	Umumiy navbatlar	Tekis taqsimot	Malakani hisobga olmaydi
`fewestcalls`	Support navbatlari	Muvozanatli yuk	Yangi operatorlar ko'mib tashlanadi
`leastrecent`	Yuqori hajmli sotuv	Chaqiruvlar orasida dam beradi	Malakali operatorlar bo'sh turishi mumkin
`random`	Overflow navbatlari	Tizimni "aldash" imkoni yo'q	Yuk oldindan bilib bo'lmas
`wrandom`	Malaka bo'yicha marshrutizatsiya	Vaznlar orqali nazorat	Sozlash murakkab

2.2 Taymaut va takrorlashni optimallashtirish

timeout, retry va wrapuptime parametrlarining o'zaro ta'siri hal qiluvchi ahamiyatga ega:

To'liq sikl = timeout + retry + wrapuptime

timeout=15, retry=1, wrapuptime=10 bo'lgan navbat uchun:

—Bitta operatorga urinish maksimum 26 soniya oladi
—3 ta bo'sh operator bilan bog'lashga urinilayotgan mijoz eng yomon holatda ~78 soniya kutadi

Navbat turlari bo'yicha maqsadli qiymatlar:

Navbat turi	Timeout	Retry	Wrapup	Sababi
Sotuv (kiruvchi)	12 s	1 s	5 s	Hammasini tezlik hal qiladi
Texnik support	20 s	1 s	30 s	Operatorga hujjatlashtirish vaqti kerak
Billing	15 s	1 s	15 s	O'rtacha murakkablik
VIP/prioritet	10 s	0 s	5 s	Imkon qadar tez javob
Overflow	25 s	1 s	0 s	Javob berish ehtimolini oshiramiz

2.3 Navbat vazni va prioriteti

Bir nechta navbatli muhitda vaznlar yuqori prioritetli navbatlar birinchi xizmat ko'rsatilishini kafolatlaydi:

; queues.conf
[vip-support]
weight = 10             ; Eng yuqori prioritet
strategy = ringall

[standard-support]
weight = 5
strategy = rrmemory

[overflow-support]
weight = 1              ; Eng past prioritet
strategy = leastrecent

Operator bir nechta navbatga a'zo bo'lsa, chaqiruvlar avval vazni kattaroq navbatlardan keladi. SLA'ni boshqarish uchun bu shart.

2.4 Navbatga dinamik a'zolik

Statik a'zolik sig'imni behuda sarflaydi. Dinamik a'zolik esa tarkibni real vaqtda optimallashtirishga imkon beradi:

; queues.conf
[support]
member => PJSIP/agent101,0,Agent 101,SIP/agent101  ; Statik (zaxira)
; Dinamik a'zolar quyidagi yo'llar bilan qo'shiladi:
; CLI: queue add member PJSIP/agent102 to support
; AMI: QueueAdd amali
; Dialplan: AddQueueMember()

Operator kirishi va chiqishi uchun dialplan:

; extensions.conf
[agent-controls]
; *51 = Navbatga kirish
exten => *51,1,Answer()
 same => n,AddQueueMember(support,PJSIP/${CALLERID(num)})
 same => n,Playback(agent-loginok)
 same => n,Hangup()

; *52 = Navbatdan chiqish
exten => *52,1,Answer()
 same => n,RemoveQueueMember(support,PJSIP/${CALLERID(num)})
 same => n,Playback(agent-loggedoff)
 same => n,Hangup()

; *53 = Pauza (tanaffus)
exten => *53,1,Answer()
 same => n,PauseQueueMember(support,PJSIP/${CALLERID(num)},,Break)
 same => n,Playback(beep)
 same => n,Hangup()

; *54 = Pauzani olib tashlash (tanaffusdan qaytdi)
exten => *54,1,Answer()
 same => n,UnpauseQueueMember(support,PJSIP/${CALLERID(num)})
 same => n,Playback(beep)
 same => n,Hangup()

2.5 Navbatdagi e'lonlarni optimallashtirish

Yomon sozlangan e'lonlar operatorlar vaqtini yeydi va mijozlarni asabiylashtiradi:

[support]
; Pozitsiya va kutish vaqti haqidagi e'lonlar
announce-frequency = 60          ; Har 60 soniyada
announce-holdtime = once         ; Taxminiy kutish vaqtini bir marta aytish
announce-position = yes          ; "Siz navbatda X-raqamdasiz"
min-announce-frequency = 30      ; 30 soniyada bir martadan tez-tez emas

; Davriy e'lonlar
periodic-announce = custom/thank-you-for-waiting
periodic-announce-frequency = 45

; Kutish paytidagi musiqa
musicclass = support-moh         ; Ushbu navbat uchun alohida MOH

; Ulanishda operatorga e'lon
announce-to-first-user = yes

Qochish kerak bo'lgan antipattern: e'lon uzunligi 10 soniya bo'lganda announce-frequency=15 qo'yish. Natijada mijoz e'lonlarni deyarli tinimsiz eshitadigan sikl hosil bo'ladi — bu tashlab ketilgan chaqiruvlar ulushini 20-40% oshiradi.

3-qism. Chaqiruvlar marshrutizatsiyasini optimallashtirish

3.1 IVR optimizatsiyasi: darajalar kam bo'lsa, hal qilingan murojaatlar ko'p bo'ladi

IVR'ning har bir darajasi sizga qo'ng'iroq qiluvchilarning bir qismiga tushadi. Soha ma'lumotlari shuni ko'rsatadi:

IVR chuqurligi	Oxirigacha yetib borganlar ulushi
1 daraja	95%
2 daraja	80%
3 daraja	60%
4+ daraja	<40%

Optimallashtirilgan IVR tuzilmasi:

; extensions.conf
[ivr-main]
exten => s,1,Answer()
 same => n,Set(TIMEOUT(response)=5)
 same => n,Background(custom/welcome-short)  ; 8 soniyadan uzun bo'lmasin
 same => n,WaitExten(3)

; To'g'ridan-to'g'ri bo'limga - BITTA daraja
exten => 1,1,Goto(queue-sales,s,1)        ; Sotuv
exten => 2,1,Goto(queue-support,s,1)      ; Support
exten => 3,1,Goto(queue-billing,s,1)      ; Billing
exten => 0,1,Goto(queue-reception,s,1)    ; Operator

; Taymaut/noto'g'ri tanlov → umumiy navbatga (siklga tushirmaymiz!)
exten => t,1,Goto(queue-support,s,1)
exten => i,1,Goto(queue-support,s,1)

IVR optimizatsiyasining asosiy qoidalari:

—Maksimum 2 ta IVR darajasi
—Salomlashish 8 soniyadan qisqa
—Har doim "operator uchun 0 ni bosing" varianti bo'lsin
—Taymautda navbatga o'tsin, menyu qayta o'ynatilmasin
—IVR'ni oxirigacha o'tish ulushini kuzating — 80% dan past bo'lsa, soddalashtiring

3.2 Malaka bo'yicha marshrutizatsiya

Chaqiruvlarni kerakli malakaga ega operatorlarga yo'naltiring — shunda o'tkazishlar kamayadi va ishlov berish vaqti qisqaradi:

; queues.conf
[support-english]
strategy = wrandom

; Penalty asosidagi malaka marshrutizatsiyasi:
; penalty 0 = asosiy malaka, penalty 5 = ikkilamchi, penalty 10 = zaxira
member => PJSIP/agent101,0     ; Ona tilida ingliz tilida gapiradi
member => PJSIP/agent102,0     ; Ona tilida ingliz tilida gapiradi
member => PJSIP/agent103,5     ; Ingliz tili o'rta daraja
member => PJSIP/agent104,10    ; Ingliz tili boshlang'ich (oxirgi chora)

[support-spanish]
strategy = wrandom
member => PJSIP/agent103,0     ; Ona tilida ispan tilida gapiradi
member => PJSIP/agent104,0     ; Ona tilida ispan tilida gapiradi
member => PJSIP/agent101,10    ; Ispan tili boshlang'ich (zaxira)

Penalty eskalatsiyasi bilan dialplan (bosqichma-bosqich marshrutizatsiya):

[queue-support]
exten => s,1,Answer()
 same => n,Set(QUEUE_MAX_PENALTY=0)         ; Avval asosiy operatorlarni sinaymiz
 same => n,Queue(support,,,,30)             ; Asosiylarni 30 s kutamiz
 same => n,Set(QUEUE_MAX_PENALTY=5)         ; Ikkilamchilarga eskalatsiya
 same => n,Queue(support,,,,30)             ; Yana 30 s kutamiz
 same => n,Set(QUEUE_MAX_PENALTY=10)        ; Barcha operatorlarni qo'shamiz
 same => n,Queue(support,,,,60)             ; Oxirgi urinish
 same => n,VoiceMail(support@default,u)     ; Ovozli pochtaga o'tish
 same => n,Hangup()

3.3 Vaqt bo'yicha marshrutizatsiya

Chaqiruvlarni ish vaqti, bayramlar va smena to'ldirilganligiga qarab yo'naltiring:

[inbound-handler]
exten => s,1,Answer()
 same => n,GotoIfTime(09:00-18:00,mon-fri,,?business-hours,s,1)
 same => n,GotoIfTime(09:00-13:00,sat,,?saturday-hours,s,1)
 same => n,Goto(after-hours,s,1)

[business-hours]
exten => s,1,Goto(ivr-main,s,1)

[saturday-hours]
exten => s,1,Set(QUEUE_MAX_PENALTY=0)   ; Shanba kuni faqat asosiy operatorlar
 same => n,Queue(support,,,,60)
 same => n,VoiceMail(support@default,u)
 same => n,Hangup()

[after-hours]
exten => s,1,Playback(custom/after-hours-message)
 same => n,VoiceMail(support@default,u)
 same => n,Hangup()

3.4 Caller ID bo'yicha prioritetli marshrutizatsiya

Qaytib qo'ng'iroq qilayotganlarni va VIP mijozlarni taniy oling:

[inbound-handler]
exten => s,1,Answer()
 ; VIP mijozmi, tekshiramiz (baza yoki fayl orqali)
 same => n,Set(VIP=${DB(vip/${CALLERID(num)})})
 same => n,GotoIf($["${VIP}" = "yes"]?vip-queue,s,1)
 ; Oxirgi 24 soat ichida qo'ng'iroq qilganmi, tekshiramiz
 same => n,Set(RECENT=${DB(recent/${CALLERID(num)})})
 same => n,GotoIf($["${RECENT}" != ""]?priority-queue,s,1)
 ; Odatiy marshrutizatsiya
 same => n,Goto(ivr-main,s,1)

[vip-queue]
exten => s,1,Queue(vip-support,,,,120)   ; Uzunroq taymautli VIP navbat
 same => n,Hangup()

4-qism. Operatorlar ish samaradorligini optimallashtirish

4.1 Operator statuslarini boshqarish

Statuslarni to'g'ri kuzatish "arvoh operatorlar" — tizimga kirgan, lekin aslida bo'sh bo'lmagan xodimlar paydo bo'lishining oldini oladi:

; pjsip.conf da qurilma holati monitoringini sozlash
[agent101]
type=endpoint
device_state_busy_at=1    ; 1 ta aktiv chaqiruvdan keyin band deb belgilash

Kuzatish zarur bo'lgan asosiy operator statuslari:

Status	Tavsifi	Optimizatsiya harakati
Bo'sh	Chaqiruvga tayyor	Tekis taqsimotni ta'minlash
Liniyada	Suhbat ketmoqda	Suhbat vaqtini nazorat qilish
Yakunlash	Chaqiruvdan keyingi ish	Vaqt chegarasini joriy qilish
Pauza (tanaffus)	Rejali tanaffus	Grafikka rioyani kuzatish
Pauza (o'quv)	O'qishda	Yuk kam bo'lgan soatlarga qo'yish
Bo'sh emas	Javob bermayapti	3 ta o'tkazib yuborilgan chaqiruvdan keyin avtochiqish

4.2 Javob bermaydigan operatorlarni avtomatik chiqarish

Trubkani ko'tarmaydigan operator navbatdagi har bir mijozning vaqtini o'g'irlaydi:

; queues.conf
[support]
autopause = yes           ; O'tkazib yuborilgan chaqiruvdan keyin avtopauza
autopausedelay = 0        ; Darhol
autopausebusy = no        ; "Band" holatida pauza qilmaymiz (boshqa navbatda gaplashayotgan bo'lishi mumkin)
autopauseunavail = yes    ; Mavjud emas holatida pauza qilamiz

Ilg'or variant: N ta o'tkazib yuborilgan chaqiruvdan keyin avtochiqish (dialplan + AGI):

; Har bir operator bo'yicha o'tkazib yuborilgan chaqiruvlarni sanaymiz
[queue-support]
exten => s,1,Queue(support,,,,30)
 same => n,ExecIf($["${QUEUESTATUS}" = "TIMEOUT"]?Set(DB(missed/${MEMBERINTERFACE})=$[${DB(missed/${MEMBERINTERFACE})} + 1]))
 same => n,ExecIf($[${DB(missed/${MEMBERINTERFACE})} >= 3]?PauseQueueMember(support,${MEMBERINTERFACE},,AutoPaused-3-missed))

4.3 Yakunlash vaqtini optimallashtirish

Yakunlash vaqti — sig'imni o'ldiruvchi 1-raqamli omil, lekin uni odatda payqashmaydi. Juda uzun bo'lsa — sig'im behuda ketadi. Juda qisqa bo'lsa — ma'lumotlar sifati tushadi.

Chaqiruv turlari bo'yicha me'yorlar:

Chaqiruv turi	Tavsiya etilgan yakunlash	Izohlar
Oddiy savol	5-10 s	Natija avtomatik belgilanadi
Sotuv chaqiruvi	10-15 s	CRM'ni yangilash kerak
Texnik support	20-30 s	Tiket yaratish
Murakkab eskalatsiya	45-60 s	Hujjatlashtirish kritik

Natija kodlari bilan amalga oshirish:

[post-call]
exten => s,1,Set(WRAPUP_START=${EPOCH})
 same => n,Read(DISPOSITION,,1,,,5)  ; Natija kodini kiritishga 5 soniya
 same => n,Set(CDR(disposition)=${DISPOSITION})
 same => n,Set(WRAPUP_TIME=$[${EPOCH} - ${WRAPUP_START}])
 same => n,UserEvent(WrapupComplete,Agent: ${CALLERID(num)},Duration: ${WRAPUP_TIME},Disposition: ${DISPOSITION})
 same => n,Hangup()

5-qism. Aloqa sifati va suhbatlar yozuvini optimallashtirish

Navbatlarda nima sodir bo'layotganini taxmin qilishdan charchadingizmi?

Astervis sizning Asterisk PBX'ingiz uchun 30+ realtime grafik, operator KPI va CRM-integratsiya beradi. On-premise. 5 daqiqada o'rnatiladi. $119/oydan flat — operatorlar soni cheklanmagan.

Bepul sinab ko'rish

5.1 Call-markaz uchun kodek tanlash

; pjsip.conf - call-markaz operatorlari uchun endpoint shabloni
[agent-template](!)
type=endpoint
allow=!all,ulaw,alaw       ; Faqat G.711 - eng kam CPU, LAN uchun eng yaxshi sifat
dtls_auto_generate_cert=yes

Kodek tanlash bo'yicha qo'llanma:

Kodek	Kanal kengligi	CPU	Sifat	Qayerda ishlatiladi
G.711 ulaw	87 kbit/s	Minimal	A'lo	LAN'dagi operatorlar, lokal trunklar
G.711 alaw	87 kbit/s	Minimal	A'lo	Yevropa standarti
G.722	87 kbit/s	Past	HD ovoz	Premium navbatlar
G.729	31 kbit/s	Yuqori	Yaxshi	Masofaviy operatorlar, WAN
Opus	O'zgaruvchan	O'rtacha	A'lo	WebRTC operatorlari

Call-markazlar uchun: LAN ichida (operatorlar) G.711 dan foydalaning, trunklar bilan esa ularning afzal kodegiga qarab kelishing. Imkon bo'lsa, transkodingdan qoching — u kechikish va CPU yukini qo'shadi.

5.2 Suhbatlarni yozib olish amaliyoti

; Support navbatidagi barcha chaqiruvlarni yozamiz
[queue-support]
exten => s,1,Set(MONITOR_FILENAME=/var/spool/asterisk/monitor/${STRFTIME(${EPOCH},,%Y/%m/%d)}/${UNIQUEID})
 same => n,MixMonitor(${MONITOR_FILENAME}.wav,b)
 same => n,Queue(support)
 same => n,StopMixMonitor()

Yozuvni optimallashtirish bo'yicha maslahatlar:

—WAV formatida yozing (CPU yuki past), kechasi cron orqali MP3'ga konvertatsiya qiling
—Sana bo'yicha tartiblang (/YYYY/MM/DD/) — arxivlash osonlashadi
—Yozuvlarga kirish huquqlarini sozlang, operator boshqalarning suhbatlarini eshitmasin
—Saqlash siyosatini joriy qiling: 90 kun aktiv, 1 yil arxivda, keyin o'chirish
—Disk joyini kuzating — 80% to'lganda ogohlantirish yuborilsin

# Konvertatsiya uchun tungi cron vazifasi
# /etc/cron.d/asterisk-recording-convert
0 2 * * * asterisk find /var/spool/asterisk/monitor/$(date -d yesterday +\%Y/\%m/\%d) -name "*.wav" -exec sox {} {}.mp3 \; -delete

5.3 Jitter buffer sozlamalari

Masofaviy operatorlar yoki kechikishi o'zgaruvchan SIP trunklar uchun:

; pjsip.conf
[remote-agent-template](!)
type=endpoint
allow=!all,g729,ulaw
; Barqaror aloqa sifati uchun fiksatsiyalangan jitter buffer
jbimpl=fixed
jbmaxsize=200           ; Bufer maksimum 200 ms
jbtargetextra=40        ; Qo'shimcha buferlash
jblog=no                ; Prodakshenda loglashni o'chiramiz

6-qism. Monitoring va analitika — butun optimizatsiyaning ko'paytiruvchisi

Ma'lumotsiz yuqoridagi barcha optimizatsiyalar taxminlarcha bo'lib qoladi. Monitoring taxminni aniq ilmga aylantiradi.

6.1 Call-markazning asosiy metrikalari

Bu ko'rsatkichlarni ham real vaqtda, ham tarixiy dinamikada kuzating:

Real vaqt dashboardi metrikalari:

Metrika	Maqsad	Ogohlantirish chegarasi	Harakat
Navbatdagi chaqiruvlar	<10	>15	Overflow'dan operator qo'shish
Eng uzoq kutish	<60 s	>120 s	Darhol eskalatsiya
Bo'sh operatorlar	Umumiy sonning >20%	<10%	Tanaffuslarni bekor qilish
Service Level	20 s ichida >80%	<60%	Shoshilinch ravishda odam chiqarish
Tashlab ketish ulushi	<5%	>8%	Qayta qo'ng'iroqni yoqish

Tarixiy tahlil metrikalari:

Metrika	Nima uchun kerak	Ko'rib chiqish chastotasi
O'rtacha ishlov berish vaqti (AHT)	Operator samaradorligi	Har kuni
Birinchi chaqiruvda hal qilish (FCR)	Sifat indikatori	Har hafta
Operatorlar bandligi	Sig'imni rejalashtirish	Har hafta
Bitta chaqiruv tannarxi	Moliyaviy salomatlik	Har oy
Mijozlar qoniqishi (CSAT)	Mijoz tajribasi sifati	Har oy

6.2 AMI asosida real vaqt monitoringi

Asterisk Manager Interface (AMI) real vaqtda hodisalar oqimini beradi:

; manager.conf
[monitoring]
secret = strong_password_here
permit = 127.0.0.1/255.255.255.255
read = call,agent,reporting
write = command
eventfilter = Event: QueueMember*
eventfilter = Event: QueueCaller*
eventfilter = Event: AgentConnect
eventfilter = Event: AgentComplete

Call-markaz monitoringi uchun asosiy AMI hodisalari:

Hodisa	Qanday ma'lumot beradi	Qayerda ishlatiladi
`QueueCallerJoin`	Navbat, pozitsiya, caller ID	Real vaqtdagi navbat chuqurligi
`QueueCallerLeave`	Sabab (javob berildi, tashlab ketildi, taymaut)	Tashlab ketishlarni hisobga olish
`AgentConnect`	Kutish vaqti, operator	Service level hisobi
`AgentComplete`	Suhbat vaqti, kutish vaqti	AHT tahlili
`QueueMemberPause`	Sabab, davomiylik	Tanaffus grafigiga rioya
`QueueMemberStatus`	Qurilma holati	Operator bandligi

6.3 CDR va CEL tahlili

CDR (Call Detail Records) va CEL (Channel Event Logging) — butun tarixiy hisobot uchun xomashyo:

; cdr.conf
[general]
enable=yes
unanswered=yes          ; Javobsiz chaqiruvlarni ham hisobga olamiz
congestion=yes          ; Congestion hodisalarini hisobga olamiz
endbeforehexten=no      ; CDR'ni h kengaytmasidan oldin yakunlash

; cdr_adaptive_odbc.conf (bazada saqlash uchun)
[asterisk-cdr]
connection=asterisk
table=cdr
alias start => calldate
alias clid => clid
alias src => src
alias dst => dst
alias dcontext => dcontext
alias channel => channel
alias dstchannel => dstchannel
alias lastapp => lastapp
alias lastdata => lastdata
alias duration => duration
alias billsec => billsec
alias disposition => disposition
alias uniqueid => uniqueid

CDR tahlili uchun so'rov namunalari:

-- Soatlik yuk profili (smenalarni rejalashtirish uchun)
SELECT
    EXTRACT(HOUR FROM calldate) AS hour,
    COUNT(*) AS total_calls,
    COUNT(CASE WHEN disposition = 'ANSWERED' THEN 1 END) AS answered,
    COUNT(CASE WHEN disposition = 'NO ANSWER' THEN 1 END) AS abandoned,
    ROUND(AVG(CASE WHEN disposition = 'ANSWERED' THEN billsec END), 1) AS avg_talk_time,
    ROUND(AVG(duration - billsec), 1) AS avg_wait_time
FROM cdr
WHERE calldate >= CURRENT_DATE - INTERVAL '7 days'
    AND dcontext LIKE 'queue-%'
GROUP BY EXTRACT(HOUR FROM calldate)
ORDER BY hour;

-- Operatorlarning natijadorlik reytingi
SELECT
    dstchannel AS agent,
    COUNT(*) AS calls_handled,
    ROUND(AVG(billsec), 1) AS avg_talk_time,
    ROUND(AVG(duration - billsec), 1) AS avg_wait_before_answer,
    MAX(billsec) AS longest_call,
    SUM(billsec) / 3600.0 AS total_hours
FROM cdr
WHERE disposition = 'ANSWERED'
    AND dcontext LIKE 'queue-%'
    AND calldate >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY dstchannel
ORDER BY calls_handled DESC;

-- Service level hisobi (20 soniyada javob berilganlar %)
SELECT
    DATE(calldate) AS day,
    COUNT(*) AS total_calls,
    COUNT(CASE WHEN disposition = 'ANSWERED'
               AND (duration - billsec) <= 20 THEN 1 END) AS within_sla,
    ROUND(
        100.0 * COUNT(CASE WHEN disposition = 'ANSWERED'
                           AND (duration - billsec) <= 20 THEN 1 END)
        / NULLIF(COUNT(*), 0), 1
    ) AS service_level_pct
FROM cdr
WHERE calldate >= CURRENT_DATE - INTERVAL '30 days'
    AND dcontext LIKE 'queue-%'
GROUP BY DATE(calldate)
ORDER BY day;

6.4 Nega tayyor analitika o'zi yozilganidan ustun

Xom CDR ustiga dashboard qurish mumkin, lekin uni sozlash va qo'llab-quvvatlashga 40-80 soat ketadi. Sizga quyidagilar kerak bo'ladi:

—SQL so'rovlarni yozish va qo'llab-quvvatlash (Asterisk versiyalari o'zgarganda yangilab turish)
—Vizualizatsiya dashboardlarini yig'ish (Grafana, o'zi yozilgan veb-ilovalar)
—Ogohlantirish qoidalarini sozlash
—Ma'lumotlarni saqlash va arxivlash bilan shug'ullanish
—Operatorlar ishi bo'yicha hisobotlar tayyorlash
—Real vaqt wallboardlarini yaratish

Shuning uchun jamoalar Asterisk uchun maxsus yaratilgan analitika vositalariga o'tmoqda — masalan, Astervis. Bitta o'rnatish buyrug'i bilan siz quyidagilarga ega bo'lasiz:

—30+ tayyor grafik: issiqlik xaritalari, operatorlar reytingi, trunklar bo'yicha analitika
—Real vaqt dashboardlari: navbat chuqurligi, kutish vaqtlari, operator statuslari — jonli
—Operatorlarni boshqarish: KPI kuzatuvi, natijadorlik bahosi, ish grafiklari
—CRM integratsiyasi: Bitrix24, AmoCRM — chaqiruvlar bitimlarga bog'lanadi
—Yozuvlarni tinglash: qidiruv va filtrlar bevosita dashboardda
—15 daqiqada o'rnatish: curl -sSL https://api.astervis.io/api/releases/install.sh | bash

Hech qanday SQL so'rov yozish shart emas. Grafana dashboardlarini qo'llab-quvvatlash shart emas. O'zi yozilgan kod ham kerak emas.

7-qism. Operatsion amaliyotlar

7.1 Sig'imni rejalashtirish tizimi

Xodimlarga bo'lgan ehtiyojni bashorat qilish uchun tarixiy ma'lumotlardan foydalaning:

Erlang C formulasi uchun kirish ma'lumotlari:

—Soatiga o'rtacha chaqiruvlar soni (CDR'dan)
—O'rtacha ishlov berish vaqti (suhbat + yakunlash)
—Maqsadli service level (masalan, 20 soniyada 80%)

Xodimlar soni bo'yicha tezkor jadval (SLA 80/20):

Chaqiruv/soat	AHT (daq)	Kerakli operatorlar	Bandlik
50	4	5	67%
100	4	9	74%
200	4	17	78%
300	4	25	80%
500	4	40	83%

Ogohlantirish: operatorlar bandligi 85% dan oshsa, bu charchashga olib keladi. Barqaror bandlikni maksimum 75-80% darajasida rejalashtiring.

7.2 Navbat overflow strategiyasi

Mijozlarni cheksiz kuttirmang. Bosqichma-bosqich overflow'ni joriy qiling:

0-30 s:    Asosiy navbat (kerakli malakali operatorlar)
30-60 s:   Ikkilamchi navbat (o'sha bo'lim, pastroq malaka)
60-90 s:   Overflow navbati (istalgan bo'sh operator)
90-120 s:  Qayta qo'ng'iroq taklifi
120 s+:    Qayta qo'ng'iroq va'dasi bilan ovozli pochta

; extensions.conf - bosqichma-bosqich overflow
[queue-support-overflow]
exten => s,1,Set(QUEUE_MAX_PENALTY=0)
 same => n,Queue(support,,,,30)          ; 30 s: asosiy operatorlar
 same => n,Set(QUEUE_MAX_PENALTY=5)
 same => n,Queue(support,,,,30)          ; 60 s: ikkilamchi operatorlar
 same => n,Set(QUEUE_MAX_PENALTY=10)
 same => n,Queue(support,,,,30)          ; 90 s: barcha operatorlar
 same => n,Goto(callback-offer,s,1)      ; Qayta qo'ng'iroq taklif qilamiz

7.3 SLA boshqaruvi

Har bir navbat bo'yicha SLA'ni belgilang va nazorat qiling:

Navbat	Maqsadli SLA	O'lchash
VIP support	10 s ichida 95%	Xatolikka o'rin yo'q
Sotuv	20 s ichida 80%	Daromadga bevosita ta'sir qiladi
Umumiy support	30 s ichida 80%	Soha standarti
Billing	45 s ichida 70%	Shoshilinchlik pastroq
Email/qayta qo'ng'iroq	24 soat ichida javob	SLA'ning boshqa turi

7.4 Uzluksiz yaxshilanish sikli

Optimizatsiya bir martalik loyiha emas. Haftalik ko'rib chiqish siklini yo'lga qo'ying:

Haftalik optimizatsiya tahlili (30 daqiqa):

—Service Level (5 daq): maqsadli SLA bajarildimi? Qaysi navbatlar uddalay olmadi?
—Operatorlar ishi (10 daq): eng yaxshi va eng zaif natijalar. Kimga kouching kerak?
—Chaqiruvlar profili tahlili (5 daq): yangi hajm sakrashlari bo'ldimi? Mavsumiy tendensiyalar bormi?
—Navbatlar konfiguratsiyasi (5 daq): timeout va wrapup sozlamalari hamon mantiqiymi?
—Tizim salomatligi (5 daq): CPU, xotira, disk dinamikasi. Sig'im bo'yicha xavf bormi?

8-qism. Optimizatsiyada tez-tez uchraydigan xatolar

1-xato: AHT ortidan haddan tashqari quvish

Operatorlarni ishlov berish vaqtini qisqartirishga majburlash odatda takroriy chaqiruvlarni ko'paytiradi. Buning o'rniga birinchi chaqiruvda hal qilish ko'rsatkichiga qarang.

2-xato: navbatda e'lonlar juda ko'p

Har 15 soniyada pozitsiya haqidagi e'lonlar mijozlarni asabiylashtiradi. announce-frequency ni kamida 45-60 soniyaga qo'ying.

3-xato: overflow strategiyasi yo'q

2 daqiqadan ortiq hech qanday muqobilsiz kutgan mijoz trubkani tashlaydi — va boshqa qo'ng'iroq qilmaydi. Har doim zaxira variant bo'lsin: qayta qo'ng'iroq yoki ovozli pochta.

4-xato: operatorlarni qat'iy biriktirish

Operatorlarni doimiy navbatlarda ushlab turish yuk o'zgarganda sig'imni behuda sarflaydi. Navbatga dinamik a'zolikni malaka bo'yicha marshrutizatsiya bilan birga ishlating.

5-xato: ish vaqtidan tashqari chaqiruvlarga e'tiborsizlik

Ko'plab kompaniyalar ish vaqtidan tashqari chaqiruvlarni qayta ishlamagani uchun potensial daromadning 15-20% ini yo'qotadi. Voicemail-to-email, qayta qo'ng'iroqqa yozilish yoki boshqa vaqt mintaqalaridagi masofaviy operatorlarga marshrutizatsiyani joriy qiling.

6-xato: monitoring yo'q

Ko'r-ko'rona ishlash — eng katta xato. O'lchamaydigan narsangizni optimallashtira olmaysiz. Hech bo'lmaganda service level, tashlab ketish ulushi va operatorlar bandligini har kuni kuzating.

Optimizatsiya cheklisti

Asterisk call-markazingizni audit qilish uchun ushbu cheklistdan foydalaning:

Tizim darajasi:

— Linux yadrosi sozlangan (fayl deskriptorlari, tarmoq buferlari, swap)
— PJSIP threadpool operatorlar soniga moslab hisoblangan
— Stasis threadpool sozlangan
— Endpoint identifikatsiyasi tartibi optimallashtirilgan
— Keraksiz modullar o'chirilgan

Navbatlar konfiguratsiyasi:

— Qo'ng'iroq strategiyasi navbat vazifasiga mos
— Timeout/retry/wrapup har bir navbat uchun tanlangan
— Navbat vaznlari prioritetga qarab sozlangan
— Dinamik a'zolik yoqilgan
— E'lonlar juda tez-tez eshitilmaydi

Chaqiruvlar marshrutizatsiyasi:

— IVR'da maksimum 2 daraja
— Malaka bo'yicha marshrutizatsiya joriy qilingan
— Vaqt bo'yicha marshrutizatsiya sozlangan
— Overflow strategiyasi mavjud
— Qayta qo'ng'iroq varianti bor

Operatorlarni boshqarish:

— O'tkazib yuborilgan chaqiruvlar uchun avtopauza yoqilgan
— Yakunlash vaqtlari har bir navbatga mos
— Operator statuslari to'g'ri kuzatiladi
— Natijadorlik metrikalari supervayzerlarga ko'rinadi

Monitoring:

— Real vaqt dashboardi ishlayapti
— Tarixiy hisobot sozlangan
— SLA buzilishlari uchun ogohlantirish qoidalari belgilangan
— Haftalik optimizatsiya tahlili rejalashtirilgan
— Suhbatlar yozuvi va sifat nazorati ishlayapti

Asosiy xulosalar

—O'lchashdan boshlang. Yaxshilanishni raqamlarda ko'rsata olish uchun monitoringni o'zgarishlardan oldin o'rnating.
—Tizim sozlamalari muhim. PJSIP threadpool va yadro sozlamalari bir vaqtdagi chaqiruvlar sig'imini 2-3 barobar oshira oladi.
—Navbatlar konfiguratsiyasi eng yuqori ROI beradi. Strategiya, taymautlar va vaznlar har bir mijoz tajribasiga bevosita ta'sir qiladi.
—Malaka bo'yicha marshrutizatsiya o'tkazishlarni 30-40% kamaytiradi, ham samaradorlikni, ham mijozlar qoniqishini oshiradi.
—Operatorlar bandligining optimal darajasi — 75-80%. Yuqorisi charchatadi, pasti esa ish haqi fondini behuda sarflaydi.
—Bosqichma-bosqich overflow tashlab ketishning oldini oladi. Mijozni hech qachon muqobilsiz kuttirmang.
—Bosqichma-bosqich yaxshilash bir martalik katta qayta qurishdan ustun. Haftalik 30 daqiqalik tahlillar vaqt o'tishi bilan jamlanib katta samara beradi.

Bugundan optimizatsiyani boshlang

Hammasini birdaniga joriy qilish shart emas. Eng katta samara beradiganlaridan boshlang:

—Monitoringni o'rnating va boshlang'ich nuqtani belgilang
—Navbat taymautlari va strategiyalarini optimallashtiring
—Malaka bo'yicha marshrutizatsiyani joriy qiling
—Overflow va qayta qo'ng'iroqlarni sozlang
—Haftalik optimizatsiya tahlillarini rejalashtiring

Asterisk call-markazingizda nima bo'layotganini bir zumda ko'rish uchun Astervis ni sinab ko'ring — 30+ real vaqt grafigi, operatorlar nazorati va CRM integratsiyasi. 15 daqiqada o'rnatiladi, sozlash talab qilinmaydi.

Bepul 14 kunlik sinov muddatini boshlang →

Taxmin qilishni bas qiling. Ko'rishni boshlang.

Asterisk call-markazingizning haqiqiy ko'rinishi: navbatlardagi kutish vaqti, operatorlar faolligi, trunk yuklamasi va 30+ grafik. Sizning serveringizda on-premise. 5 daqiqada o'rnatish. Kartasiz.

Bepul triаlni boshlash Demo so'rash

$119/oydan flat. Operatorlar soni cheklanmagan. 14 kunlik triаl.

Ulashish

Asterisk call-markazini optimallashtirish bo'yicha to'liq qo'llanma