در قسمت اول از مقالهی Call Quality Dashboard یا به اختصار CQD، این راهکار، ویژگیها، اهداف طراحی و اجزای آن معرفی شد. در ادامه معماری کلی آن که شامل دو دیتابیس، یک SSAS Cube و یک Portal است شرح داده شد. علاوه بر این، مزایای این راهکار در مقابل Lync 2013 بررسی و اطلاعاتی که از طریق CQD در دسترس قرار میگیرد نام برده شدند و در نهایت به شرح نمایش داده از طریق Portal و APIهای REST در CQD پرداخته شد. در این قسمت به شرح زمان و دلیل پیادهسازی CQD، توپولوژی آن و پیکربندیهای Single Server و Multiserver از CQD پرداخته خواهد شد.
تعریف الزامات سازمان برای CQD
CQD قابلیت آرشیو دادهی QoE و تجزیهوتحلیل سریع و عمیق از دادههای کیفیت تماس را فراهم مینماید. راهنمای زیر به کاربر کمک میکند تصمیم بگیرد که در چه زمان و به چه دلیل CQD را پیادهسازی کند.
زمان پیادهسازی CQD
حتی اگر سازمانی تجربهی مشکلات کیفیت تماس را نداشته باشد، میتوان جهت اندازه گیری کیفیت تماس اولیه، CQD را پیادهسازی نمود. اندازهگیری کیفیت تماس اولیه به این دلیل اهمیت دارد که هر سازمانی دارای ترکیبی متفاوت از Wi-Fi در قیاس با Wired و کارمندان از راه دور در قیاس با کارمندان دفتری است. وقتی مشکلی در مورد کیفیت تماس ایجاد میشود، میتوان آخرین مقیاس کیفیت تماس را با بازههای زمانی پیشین مقایسه نمود. ویژگیهای روند CQD شناسایی سادهی تغییرات در کیفیت تماس را در طول زمان ممکن میسازد.
میتوان CQD را پیادهسازی نمود تا مشکلاتی که ممکن است روی کیفیت تماس تاثیر بگذارند، به صورت فعال و آیندهنگرانه شناسایی گردد. حتی اگر میانگین کیفیت تماس برای سازمانی به اهدافی که توسط سازمان تعیین شده است دست یافته باشد، ممکن است مشکلات کیفیت تماس بسیاری وجود داشته باشد که پشت میانگین معیارهای سنجش مخفی شده باشند. CQD دارای توانایی ارائهی جزئیاتی از معیارهای سنجش کیفیت تماس مشابه Pivot Table، توسط بعدهای بسیاری در دیتابیس QoEMetrics است. شناسایی دادههای خارج از محدوده در گروههای Peer، راهی سریع برای شناسایی آیندهنگرانهی مشکلات کیفیت تماس میباشد.
در صورتی که مشکلات کیفیت تماس در سازمان وجود داشته باشد، CQD باید با این هدف که زمان مورد نیاز برای عیبیابی مشکلات کاهش یابد، پیادهسازی گردد. CQD میتواند با ارائهی عملکرد گزارشگیری سریع و قابلیتهای عملیاتهایی برای بررسی دقیق دادهها به صورت پویا، بررسیهای کیفیت تماس موجود را تسهیل نماید. CQD برای انواع بسیاری از جریانهای کاری در بررسیهای کیفیت تماس جهت تایید تعمیرات در محیط، مورد استفاده قرار میگیرد.
مشاوره رایگان راهاندازی سرویس ویدیو کنفرانس توسط کارشناسان شرکت APK – تماس با شماره 5 ,88539044-021
دلایل استفاده از CQD
درصورتی که لازم باشد گزارشگیری QoE برای بیش از سه ماه از داده رخ دهد، باید CQD پیادهسازی گردد. گزارشات دیتابیس QoE Metrics و سرور مانیتورینگ طراحی شدهاند تا مجموعهی کوچکی از داده را نگهداری و گزارشگیری کنند. دیتابیس QoE Metrics برای الحاقهای سریع بهینهسازی شده است و در نتیجه حجم بزرگی از تماسها یا دسترسی گزارشگیری رقابتی به دیتابیس میتوانند مانع عملکرد گزارشگیری شوند. دیتابیس QoE Archive متعلق به CQD، نسخهی دومی را از دادههای QoE Metrics، با قابلیتهای نگهداری (Retention) بسیار طولانیتری فراهم مینماید. Portal نیز بهینهسازی شده است تا 7 ماه از داده را نمایش دهد و میتواند در مورد تمامی دادههای درون QoE Archive، به میزان لازم گزارش دهد.
در صورتی که گزارشات QoE سفارشی مورد نیاز باشند، CQD باید پیادهسازی گردد. Portal برای ایجاد و نمونهسازی گزارشات به سرعت و به آسانی، دارای یک ویژگی Report Editor میباشد و همچنین APIهای REST را برای دسترسی برنامهریزیشده به دادههای Cube، قابلدسترسی مینماید و در نتیجه ارائهی سفارشی را با استفاده از HTML/JavaScript یا بسیاری از چهارچوبهای دیگر ممکن میسازد. دیگر ایجاد Queryهای SQL جدید با هدف ایجاد نماهای دادههای سفارشی برای گزارشگیری، ضروری نیست.
در صورتی که عملکرد گزارشگیری موجود QoE پاسخگوی سرعت یا عمق موردنیاز سازمان نباشد، CQD باید پیادهسازی گردد. CQD دارای گزارشات Built-In بسیاری است. این گزارشات بلافاصله کارآمد هستند و نشان میدهند که بررسی دقیق دادههای به طور تصاعدی میتواند در هر سطح، دیدگاههای بیشتری را ارائه دهد. سلسله مراتب گزارشات همچنین به مدیریت چندین گزارش به صورت منطقی کمک کرده و توانایی ایجاد گزارشات بیشتری را که به سادگی قابل دسترسی و قابل درک هستند، افزایش میدهد. CQD نه تنها سرعت و انعطافپذیری را فراهم مینماید، بلکه همچنین برای جریانهای کاری توسعه داده شده توسط Call Quality Methodology، بهینهسازی شده است.
اجزا و توپولوژیهای CQD
CQD دارای چندین جزء است و درک الزامات هر جزء و رابطهی آنها با یکدیگر برای دستیابی به سادهترین پیادهسازی ابزار، که دارای بهترین عملکرد نیز باشد، مفید است. جدول زیر اجزاء را برای هر بخش CQD نمایش میدهد.
Component name | Dependent component |
QoE Archive | Microsoft SQL Server |
Cube | Microsoft SQL Server Analysis Services |
Portal | Microsoft Information Services |
Repository Service (بخشی از نسخهی Portal) | Microsoft SQL Server |
تنظیمات Single Server
تمامی اجزای CQD و اجزای وابسته را میتوان روی یک ماشین نصب نمود. پیکربندی Single Box، سادهترین پیکربندی است و به CQD اجازه میدهد که به صورت مستقل عمل کند. CQD تنها نیازمند دسترسی به دیتابیس QoE Metrics در مانیتورینگ سرور میباشد. CQD Server میتواند یک ماشین Standalone یا ماشین مجازی باشد و یا حتی میتواند سرور مانیتورینگ باشد و این بستگی به منابع قابل دسترسی ماشین Host و الزامات عملکرد دارد.
در طول نصب، کاربری که فرآیند نصب را انجام میدهد تنها باید Instanceهای SQL Server و Microsoft SQL Server Analysis Services را فراهم نماید که روی ماشینی که CQD قرار است در آن نصب گردد، نصب شده باشند.
پیکربندی Multiserver
در یک پیکربندی Multiserver، QoE Archive، Cube و Portal همگی میتوانند روی ماشینهایی متفاوت باشند. دو کاربرد اساسی برای پیکربندی Multiserver وجود دارد:
- Host کردن CQD Web Portal و CQD Cube روی سرورهای متفاوت.
- Host کردن یک Portal توسعه، به صورت جداگانه از Portal تولید.
Host کردن CQD Web Portal و CQD Cube روی ماشینهای متفاوت
ممکن است الزامات سازمانها به گونهای باشد که CQD Portal را از نسخهی SQL Server جداسازی کنند یا ممکن است بخواهند نسخههای SQL Server را برای SQL Server Instance ترکیب کنند و SQL Server Analysis Services Instance میتواند نصب CQD Portal و CQD Cube را روی ماشینهای متفاوتی انتخاب نماید. اگر سازمان فقط بخواهد روشی پایدار برای آرشیو کردن دادههای QoE بدون نزدیک شدن به محدودیتهای عملکرد روی Monitoring Server داشته باشد، جزء QoE Archive همچنین میتواند تنها جزء نصبشدهی CQD باشد.
Host کردن یک Portal توسعه، به صورت جداگانه از Portal تولید
سازمانهایی که از طریق APIهای REST، گزارشات سفارشی خودشان را ایجاد میکنند ممکن است ترجیح دهند که Instanceهای (CQD) Portal بیشتری را در کنار Portal تولیدی که کاربران عادی برای مانیتورینگ کیفیت تماس یا بررسیها، به آن دسترسی دارند، پیادهسازی کنند. Portal توسعه میتواند هر اصلاحی را برای Portal از محیط تولیدی جداسازی نماید. پورتالهای وب اضافی را میتوان روی ماشینهای متفاوت، که در شکل زیر نشان داده شدهاند، پیادهسازی کرد و یا روی دایرکتوریهای وب متفاوت روی ماشینی یکسان، که در شکل نمایش داده نشدهاند، پیادهسازی نمود. برای دستیابی به مورد دوم، پورتال وب CQD اضافی باید به صورت دستی روی ماشین تولیدی کپی گردد، زیرا فرایند نصب CQD، همیشه CQD Web Portal را در وبسایت پیشفرض با نامهای برنامه کاربردی وب از پیش تعیینشده پیادهسازی مینماید.
ــــــــــــــــــــ
بررسی Call Quality Dashboard در Skype for Business Server – قسمت اول
بررسی Call Quality Dashboard در Skype for Business Server – قسمت دوم (پایانی)