Комментарии 5
Я чего-то не уловил. Взяли некий длинный по времени отчёт(ы) и покрутили его в Phyton (хотя в R такое делать удобнее). Увидели некие тренды и периодичность (сезонность). Сочли, что это мешает нам видеть истинное распределение ошибок. Убрали помеху. Что видим? Оказывается некие отчеты об ошибках не согласованы с «чистым» распределением. После этого предлагается поковыряться в отчетном механизме.
И тут у меня вопрос. А где работа с проверкой временного ряда. Как сводились шкалы отсчётов? Как контролировались и компенсировались пропуски значений? А не являются ли выбросы значений в реальности пропуском? Ну и прочая математическая статистика, присущая временным рядам.
Так и бывает, кто-то в подрядчиках/вендорах/поддержке изучит модную штуку на Питоне и брякнет менеджерам «мол там есть ошибки, я это по пи-валуе вижу», а потом телком инженеры делают тотальный аудит настроек оборудования пороги/уровни/адреса/критерии у нормально и бесперебойно работающего оборудования.
И тут у меня вопрос. А где работа с проверкой временного ряда. Как сводились шкалы отсчётов? Как контролировались и компенсировались пропуски значений? А не являются ли выбросы значений в реальности пропуском? Ну и прочая математическая статистика, присущая временным рядам.
Так и бывает, кто-то в подрядчиках/вендорах/поддержке изучит модную штуку на Питоне и брякнет менеджерам «мол там есть ошибки, я это по пи-валуе вижу», а потом телком инженеры делают тотальный аудит настроек оборудования пороги/уровни/адреса/критерии у нормально и бесперебойно работающего оборудования.
Уважаемый tvant!
1. «хотя в R такое делать удобнее» — небесспорное утверждение, скорее, субъективное мнение.
2. «Оказывается некие отчеты об ошибках не согласованы с «чистым» распределением.» — нет никакого «чистого» (и, кстати, «нечистого» — тоже) распределения. Есть несоотвествие данных в отчётах об ошибках наблюдаемому поведению системы.
3. «Как контролировались и компенсировались пропуски значений?» — никак, по причине отсутствия пропусков. Если в отчёте пришло 0 ошибок за какой-то день, то я не вижу оснований считать это пропуском и, тем более, интерполировать с помощью какого-либо алгоритма.
5. «А не являются ли выбросы значений в реальности пропуском?» — нет, не являются.
«Так и бывает, кто-то в подрядчиках/вендорах/поддержке изучит модную штуку на Питоне» — что в данном случае «модная штука»? Использованные методы анализа рядов уже 30-40 лет известны, как минимум. Python тоже не молод. Кстати, немолодой R становится модным в фарминдустрии, вытесняя понемногу немодный и небесплатный SAS.
6. «и брякнет менеджерам «мол там есть ошибки, я это по пи-валуе вижу»» — предлагаю обсуждать только то, что есть в статье, а не абстрактное общение кого-то «в подрядчиках/вендорах/поддержке» с какими-то менеджерами. В статье говорится о несоответствии между имеющимися данными и поведением системы. Оценка p-value («пи-валуе» в Ваших терминах) — это только часть процесса тестирования гипотез.
7. «а потом телком инженеры делают тотальный аудит настроек оборудования пороги/уровни/адреса/критерии у нормально и бесперебойно работающего оборудования.» Вы, по-видимому, плохо прочитали статью. Там сказано, что если нет жалоб от абонентов и отчёты об ошибках хотя бы приблизительно соответствуют поведению системы, то никто, включая «телком инженеров», ничего не делает. Если же достоверность отчётов вызывает сомнение, то мы ничего не знаем о качестве сервиса. Низкое качество сервиса, предоставляемого провайдером, может привести к юридическим, финансовым и пр. последствиям разной степени тяжести.
1. «хотя в R такое делать удобнее» — небесспорное утверждение, скорее, субъективное мнение.
2. «Оказывается некие отчеты об ошибках не согласованы с «чистым» распределением.» — нет никакого «чистого» (и, кстати, «нечистого» — тоже) распределения. Есть несоотвествие данных в отчётах об ошибках наблюдаемому поведению системы.
3. «Как контролировались и компенсировались пропуски значений?» — никак, по причине отсутствия пропусков. Если в отчёте пришло 0 ошибок за какой-то день, то я не вижу оснований считать это пропуском и, тем более, интерполировать с помощью какого-либо алгоритма.
5. «А не являются ли выбросы значений в реальности пропуском?» — нет, не являются.
«Так и бывает, кто-то в подрядчиках/вендорах/поддержке изучит модную штуку на Питоне» — что в данном случае «модная штука»? Использованные методы анализа рядов уже 30-40 лет известны, как минимум. Python тоже не молод. Кстати, немолодой R становится модным в фарминдустрии, вытесняя понемногу немодный и небесплатный SAS.
6. «и брякнет менеджерам «мол там есть ошибки, я это по пи-валуе вижу»» — предлагаю обсуждать только то, что есть в статье, а не абстрактное общение кого-то «в подрядчиках/вендорах/поддержке» с какими-то менеджерами. В статье говорится о несоответствии между имеющимися данными и поведением системы. Оценка p-value («пи-валуе» в Ваших терминах) — это только часть процесса тестирования гипотез.
7. «а потом телком инженеры делают тотальный аудит настроек оборудования пороги/уровни/адреса/критерии у нормально и бесперебойно работающего оборудования.» Вы, по-видимому, плохо прочитали статью. Там сказано, что если нет жалоб от абонентов и отчёты об ошибках хотя бы приблизительно соответствуют поведению системы, то никто, включая «телком инженеров», ничего не делает. Если же достоверность отчётов вызывает сомнение, то мы ничего не знаем о качестве сервиса. Низкое качество сервиса, предоставляемого провайдером, может привести к юридическим, финансовым и пр. последствиям разной степени тяжести.
Уважаемый iss_spb, я понимаю Вашу досаду. Но лид статьи говорит о том, что эта статья будет интересна инженерам из телекоммуникаций. Вам известно, что в этой отрасли мониторинг оборудования непрерывный и дашбоарды реального времени (включая визуализацию архивных данных) помимо центральных узлов контроля имеются и на локальных консолях у многих сотрудников. Этого механизма контроля за сетью вполне достаточно для оперативного управления. И я не знаю каким боком прикрутить Ваш вывод о несовершенстве механизма формирования отчётов об ошибках в инженерную практику телекома.
1. Конечно здесь субъективное мнение. Хотя, R — язык специально созданный для статистики, Phyton — универсальный язык с неплохими статистическими библиотеками.
2. Обратите внимание, слово чистый я взял в кавычки. Именно, об априори определённом состоянии анализируемой системы я и говорил.
3. Тут можно спорить, но не будем. В статистике отсутствие данных во временном ряде подразумевает какое-то вероятное значение. В телекоммуникациях означает одно из двух. Либо всё нормально, либо «авария» за наблюдаемый интервал времени самоустранилась. Поэтому, пропуск не означает, что alarm отсутствовал. Скорее всего Ваша система непрерывно сканирует оборудование и можно быть уверенными в качестве отчётов.
5. Я бы не был так уверен. Например, сигнал кабельного телевидения со 100% качеством может быть пустым. И поток E1 может быть распарован, при этом фреймы имеют полезную нагрузку. Или CRC-ошибки на стороне абонента коммутатор может и не фиксировать.
6. Я вынес этот пункт в преамбулу.
7. «Мы ничего не знаем о качестве сервиса». Как же так? Вы же в своём анализе и комментариях говорите о достоверной информации описывающей поведение системы (пусть и выведенное статистически) и исходя из этого делаете вывод о недостоверности отчётов об ошибках.
1. Конечно здесь субъективное мнение. Хотя, R — язык специально созданный для статистики, Phyton — универсальный язык с неплохими статистическими библиотеками.
2. Обратите внимание, слово чистый я взял в кавычки. Именно, об априори определённом состоянии анализируемой системы я и говорил.
3. Тут можно спорить, но не будем. В статистике отсутствие данных во временном ряде подразумевает какое-то вероятное значение. В телекоммуникациях означает одно из двух. Либо всё нормально, либо «авария» за наблюдаемый интервал времени самоустранилась. Поэтому, пропуск не означает, что alarm отсутствовал. Скорее всего Ваша система непрерывно сканирует оборудование и можно быть уверенными в качестве отчётов.
5. Я бы не был так уверен. Например, сигнал кабельного телевидения со 100% качеством может быть пустым. И поток E1 может быть распарован, при этом фреймы имеют полезную нагрузку. Или CRC-ошибки на стороне абонента коммутатор может и не фиксировать.
6. Я вынес этот пункт в преамбулу.
7. «Мы ничего не знаем о качестве сервиса». Как же так? Вы же в своём анализе и комментариях говорите о достоверной информации описывающей поведение системы (пусть и выведенное статистически) и исходя из этого делаете вывод о недостоверности отчётов об ошибках.
Уважаемый tvant!
1. «Вам известно, что в этой отрасли мониторинг оборудования непрерывный и дашбоарды реального времени (включая визуализацию архивных данных) помимо центральных узлов контроля имеются и на локальных консолях у многих сотрудников. Этого механизма контроля за сетью вполне достаточно для оперативного управления.» — для управления — достаточно, для контроля качества услуги — далеко не всегда. Примеры: эхо в разговоре, плохой рендеринг факса, недозаписанная голосовая почта. Проще говоря, для мобильного или фиксированного коммутатора 10-15 летней давности — да, достаточно, для сложной UCaaS-системы с десятками абсолютно разных по функциональности узлов — нет, совершенно недостаточно.
2. «И я не знаю каким боком прикрутить Ваш вывод о несовершенстве механизма формирования отчётов об ошибках в инженерную практику телекома.» — рад ознакомиться со столь авторитетным мнением по данному конкретному вопросу. К сожалению, не уверен, что другие специалисты имеют такое же мнение.
3. «В статистике отсутствие данных во временном ряде подразумевает какое-то вероятное значение.» — опять небесспорное утверждение — вот подходящий пример из [1].
4. «Либо всё нормально, либо «авария» за наблюдаемый интервал времени самоустранилась.» — Разовьём пример про недозаписанную голосовую почту: с т.з., скажем, SIP, всё нормально, а вот на сетевом хранилище кусок файла с записью потерялся, т.е. с т.з. потребителя услуги не всё нормально.
5. «Я бы не был так уверен.» — правильно, т.к. Вы не знаете архитектуры системы. А вот я уверен, т.к. проверял обмен между сетевыми узлами, которые предоставляют данную услугу, поэтому могу утверждать, что «нет, не являются».
6. «Вы же в своём анализе и комментариях говорите о достоверной информации описывающей поведение системы» — Вы опять плохо прочитали статью. Есть достоверная информация о количестве фактов успешного оказания услуги и наблюдаемое поведение системы, при этом есть сомнения в достоверности отчётов об ошибках.
1. «Вам известно, что в этой отрасли мониторинг оборудования непрерывный и дашбоарды реального времени (включая визуализацию архивных данных) помимо центральных узлов контроля имеются и на локальных консолях у многих сотрудников. Этого механизма контроля за сетью вполне достаточно для оперативного управления.» — для управления — достаточно, для контроля качества услуги — далеко не всегда. Примеры: эхо в разговоре, плохой рендеринг факса, недозаписанная голосовая почта. Проще говоря, для мобильного или фиксированного коммутатора 10-15 летней давности — да, достаточно, для сложной UCaaS-системы с десятками абсолютно разных по функциональности узлов — нет, совершенно недостаточно.
2. «И я не знаю каким боком прикрутить Ваш вывод о несовершенстве механизма формирования отчётов об ошибках в инженерную практику телекома.» — рад ознакомиться со столь авторитетным мнением по данному конкретному вопросу. К сожалению, не уверен, что другие специалисты имеют такое же мнение.
3. «В статистике отсутствие данных во временном ряде подразумевает какое-то вероятное значение.» — опять небесспорное утверждение — вот подходящий пример из [1].
4. «Либо всё нормально, либо «авария» за наблюдаемый интервал времени самоустранилась.» — Разовьём пример про недозаписанную голосовую почту: с т.з., скажем, SIP, всё нормально, а вот на сетевом хранилище кусок файла с записью потерялся, т.е. с т.з. потребителя услуги не всё нормально.
5. «Я бы не был так уверен.» — правильно, т.к. Вы не знаете архитектуры системы. А вот я уверен, т.к. проверял обмен между сетевыми узлами, которые предоставляют данную услугу, поэтому могу утверждать, что «нет, не являются».
6. «Вы же в своём анализе и комментариях говорите о достоверной информации описывающей поведение системы» — Вы опять плохо прочитали статью. Есть достоверная информация о количестве фактов успешного оказания услуги и наблюдаемое поведение системы, при этом есть сомнения в достоверности отчётов об ошибках.
iss_spb, приветствую!
Давайте по-простому. Качество сервиса в телекоммуникациях вообще — это громоздкий показатель, и главное значение имеет тайминг по SLA. Согласен, что аппаратный контроль качества услуг опирается на статистические методы. В традиционном телекоме методики контроля имеют отличные свойства, так как совершенствуются почти 100 лет.
В мире UcaaS-систем ещё только формируется свод правил для оценки качества. К тому же, эти системы, чаще всего, являются надстройкой над традиционным телекомом, Когда речь идёт, о коммутации пакетов (основе UcaaS) в противовес коммутации каналов (традиционный телеком), естественно требуются иные показатели и методики. Потеря пакета и потеря канала — принципиально разные вещи. Думаю, Ваши находки в сфере контроля качества могут быть полезны специалистам по Asterisk.
Транспортный уровень крупных и средних операторов связи всё равно, в той или иной мере, тяготеет к коммутации каналов. Каналы могут иметь разные названия: транки, линки, потоки, но суть одна. Даже современные оптические магистральные мультисервисные сети, содержащие в ядре пакетную передачу, в абстракции следующего уровня организованы в каналы (IP-трафик на Москву, ТВ-мультиплекс на регионы, телефония и т.п.) и управляются как каналы. Все пакеты юзеров (в т.ч. от локальной UcaaS-системы), даже имеющие адрес назначения через дорогу, всё-равно попадут в канал IP-трафика, доберутся до ближайшего узла обмена трафиком (который может быть в соседней области), и только там попадут в канал который ведёт к адресу назначения.
Давайте по-простому. Качество сервиса в телекоммуникациях вообще — это громоздкий показатель, и главное значение имеет тайминг по SLA. Согласен, что аппаратный контроль качества услуг опирается на статистические методы. В традиционном телекоме методики контроля имеют отличные свойства, так как совершенствуются почти 100 лет.
В мире UcaaS-систем ещё только формируется свод правил для оценки качества. К тому же, эти системы, чаще всего, являются надстройкой над традиционным телекомом, Когда речь идёт, о коммутации пакетов (основе UcaaS) в противовес коммутации каналов (традиционный телеком), естественно требуются иные показатели и методики. Потеря пакета и потеря канала — принципиально разные вещи. Думаю, Ваши находки в сфере контроля качества могут быть полезны специалистам по Asterisk.
Транспортный уровень крупных и средних операторов связи всё равно, в той или иной мере, тяготеет к коммутации каналов. Каналы могут иметь разные названия: транки, линки, потоки, но суть одна. Даже современные оптические магистральные мультисервисные сети, содержащие в ядре пакетную передачу, в абстракции следующего уровня организованы в каналы (IP-трафик на Москву, ТВ-мультиплекс на регионы, телефония и т.п.) и управляются как каналы. Все пакеты юзеров (в т.ч. от локальной UcaaS-системы), даже имеющие адрес назначения через дорогу, всё-равно попадут в канал IP-трафика, доберутся до ближайшего узла обмена трафиком (который может быть в соседней области), и только там попадут в канал который ведёт к адресу назначения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оценка достоверности отчетов об ошибках с помощью анализа временных рядов