Уважаемый tvant!
1. «Вам известно, что в этой отрасли мониторинг оборудования непрерывный и дашбоарды реального времени (включая визуализацию архивных данных) помимо центральных узлов контроля имеются и на локальных консолях у многих сотрудников. Этого механизма контроля за сетью вполне достаточно для оперативного управления.» — для управления — достаточно, для контроля качества услуги — далеко не всегда. Примеры: эхо в разговоре, плохой рендеринг факса, недозаписанная голосовая почта. Проще говоря, для мобильного или фиксированного коммутатора 10-15 летней давности — да, достаточно, для сложной UCaaS-системы с десятками абсолютно разных по функциональности узлов — нет, совершенно недостаточно.
2. «И я не знаю каким боком прикрутить Ваш вывод о несовершенстве механизма формирования отчётов об ошибках в инженерную практику телекома.» — рад ознакомиться со столь авторитетным мнением по данному конкретному вопросу. К сожалению, не уверен, что другие специалисты имеют такое же мнение.
3. «В статистике отсутствие данных во временном ряде подразумевает какое-то вероятное значение.» — опять небесспорное утверждение — вот подходящий пример из [1].
4. «Либо всё нормально, либо «авария» за наблюдаемый интервал времени самоустранилась.» — Разовьём пример про недозаписанную голосовую почту: с т.з., скажем, SIP, всё нормально, а вот на сетевом хранилище кусок файла с записью потерялся, т.е. с т.з. потребителя услуги не всё нормально.
5. «Я бы не был так уверен.» — правильно, т.к. Вы не знаете архитектуры системы. А вот я уверен, т.к. проверял обмен между сетевыми узлами, которые предоставляют данную услугу, поэтому могу утверждать, что «нет, не являются».
6. «Вы же в своём анализе и комментариях говорите о достоверной информации описывающей поведение системы» — Вы опять плохо прочитали статью. Есть достоверная информация о количестве фактов успешного оказания услуги и наблюдаемое поведение системы, при этом есть сомнения в достоверности отчётов об ошибках.
Уважаемый tvant!
1. «хотя в R такое делать удобнее» — небесспорное утверждение, скорее, субъективное мнение.
2. «Оказывается некие отчеты об ошибках не согласованы с «чистым» распределением.» — нет никакого «чистого» (и, кстати, «нечистого» — тоже) распределения. Есть несоотвествие данных в отчётах об ошибках наблюдаемому поведению системы.
3. «Как контролировались и компенсировались пропуски значений?» — никак, по причине отсутствия пропусков. Если в отчёте пришло 0 ошибок за какой-то день, то я не вижу оснований считать это пропуском и, тем более, интерполировать с помощью какого-либо алгоритма.
5. «А не являются ли выбросы значений в реальности пропуском?» — нет, не являются.
«Так и бывает, кто-то в подрядчиках/вендорах/поддержке изучит модную штуку на Питоне» — что в данном случае «модная штука»? Использованные методы анализа рядов уже 30-40 лет известны, как минимум. Python тоже не молод. Кстати, немолодой R становится модным в фарминдустрии, вытесняя понемногу немодный и небесплатный SAS.
6. «и брякнет менеджерам «мол там есть ошибки, я это по пи-валуе вижу»» — предлагаю обсуждать только то, что есть в статье, а не абстрактное общение кого-то «в подрядчиках/вендорах/поддержке» с какими-то менеджерами. В статье говорится о несоответствии между имеющимися данными и поведением системы. Оценка p-value («пи-валуе» в Ваших терминах) — это только часть процесса тестирования гипотез.
7. «а потом телком инженеры делают тотальный аудит настроек оборудования пороги/уровни/адреса/критерии у нормально и бесперебойно работающего оборудования.» Вы, по-видимому, плохо прочитали статью. Там сказано, что если нет жалоб от абонентов и отчёты об ошибках хотя бы приблизительно соответствуют поведению системы, то никто, включая «телком инженеров», ничего не делает. Если же достоверность отчётов вызывает сомнение, то мы ничего не знаем о качестве сервиса. Низкое качество сервиса, предоставляемого провайдером, может привести к юридическим, финансовым и пр. последствиям разной степени тяжести.
Уважаемый agafox!
Пример оптимизации: перенос обмена FIR из control plane в media plane, т.е. из SIP в RTCP. Иными словами, поддерживать не только RFC 5168, но и RFC 5104.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
1. «Вам известно, что в этой отрасли мониторинг оборудования непрерывный и дашбоарды реального времени (включая визуализацию архивных данных) помимо центральных узлов контроля имеются и на локальных консолях у многих сотрудников. Этого механизма контроля за сетью вполне достаточно для оперативного управления.» — для управления — достаточно, для контроля качества услуги — далеко не всегда. Примеры: эхо в разговоре, плохой рендеринг факса, недозаписанная голосовая почта. Проще говоря, для мобильного или фиксированного коммутатора 10-15 летней давности — да, достаточно, для сложной UCaaS-системы с десятками абсолютно разных по функциональности узлов — нет, совершенно недостаточно.
2. «И я не знаю каким боком прикрутить Ваш вывод о несовершенстве механизма формирования отчётов об ошибках в инженерную практику телекома.» — рад ознакомиться со столь авторитетным мнением по данному конкретному вопросу. К сожалению, не уверен, что другие специалисты имеют такое же мнение.
3. «В статистике отсутствие данных во временном ряде подразумевает какое-то вероятное значение.» — опять небесспорное утверждение — вот подходящий пример из [1].
4. «Либо всё нормально, либо «авария» за наблюдаемый интервал времени самоустранилась.» — Разовьём пример про недозаписанную голосовую почту: с т.з., скажем, SIP, всё нормально, а вот на сетевом хранилище кусок файла с записью потерялся, т.е. с т.з. потребителя услуги не всё нормально.
5. «Я бы не был так уверен.» — правильно, т.к. Вы не знаете архитектуры системы. А вот я уверен, т.к. проверял обмен между сетевыми узлами, которые предоставляют данную услугу, поэтому могу утверждать, что «нет, не являются».
6. «Вы же в своём анализе и комментариях говорите о достоверной информации описывающей поведение системы» — Вы опять плохо прочитали статью. Есть достоверная информация о количестве фактов успешного оказания услуги и наблюдаемое поведение системы, при этом есть сомнения в достоверности отчётов об ошибках.
1. «хотя в R такое делать удобнее» — небесспорное утверждение, скорее, субъективное мнение.
2. «Оказывается некие отчеты об ошибках не согласованы с «чистым» распределением.» — нет никакого «чистого» (и, кстати, «нечистого» — тоже) распределения. Есть несоотвествие данных в отчётах об ошибках наблюдаемому поведению системы.
3. «Как контролировались и компенсировались пропуски значений?» — никак, по причине отсутствия пропусков. Если в отчёте пришло 0 ошибок за какой-то день, то я не вижу оснований считать это пропуском и, тем более, интерполировать с помощью какого-либо алгоритма.
5. «А не являются ли выбросы значений в реальности пропуском?» — нет, не являются.
«Так и бывает, кто-то в подрядчиках/вендорах/поддержке изучит модную штуку на Питоне» — что в данном случае «модная штука»? Использованные методы анализа рядов уже 30-40 лет известны, как минимум. Python тоже не молод. Кстати, немолодой R становится модным в фарминдустрии, вытесняя понемногу немодный и небесплатный SAS.
6. «и брякнет менеджерам «мол там есть ошибки, я это по пи-валуе вижу»» — предлагаю обсуждать только то, что есть в статье, а не абстрактное общение кого-то «в подрядчиках/вендорах/поддержке» с какими-то менеджерами. В статье говорится о несоответствии между имеющимися данными и поведением системы. Оценка p-value («пи-валуе» в Ваших терминах) — это только часть процесса тестирования гипотез.
7. «а потом телком инженеры делают тотальный аудит настроек оборудования пороги/уровни/адреса/критерии у нормально и бесперебойно работающего оборудования.» Вы, по-видимому, плохо прочитали статью. Там сказано, что если нет жалоб от абонентов и отчёты об ошибках хотя бы приблизительно соответствуют поведению системы, то никто, включая «телком инженеров», ничего не делает. Если же достоверность отчётов вызывает сомнение, то мы ничего не знаем о качестве сервиса. Низкое качество сервиса, предоставляемого провайдером, может привести к юридическим, финансовым и пр. последствиям разной степени тяжести.
Пример оптимизации: перенос обмена FIR из control plane в media plane, т.е. из SIP в RTCP. Иными словами, поддерживать не только RFC 5168, но и RFC 5104.