Я может что-то не понимаю, поправьте меня пожалуйста:
— данные между автором и банком идут шифрованные (https / tls)
— траффик всё равно идёт через Yota, то есть тот же самый траффик они могут поснифить и без клиента, только им придётся сидеть и ждать пока он в банк полезете или анализировать гораздо более крупный дамп, что совсем не ускорит процесс.
Принимая во внимание эти 2 пункта, я совсем не понял про " и уж тем более не заставляя их предоставлять sensitive data." — разве они просили что-то, что им и так технически не доступно? Другое дело, что это вообще не должно быть головной болью клиента, но это уже другой вопрос.
Достаточно сказать, что в линуксе существует 12 разных алгоритмов контроля заторов в сети (congestion), которые предназначены для разных ситуаций. И есть около 20 параметров ядра, каждый из которых может радикальным образом повлиять на попугаи на выходе (пардон, результаты теста).
А не подскажете, где можно об этом подробнее почитать?
В статье я писал:
1. «Я буду намеренно немного утрировать, дабы сделать разницу несколько более наглядной.»
2. «Рассмотрим оба варианта на реальном (слегка упрощённом, дабы не тратить время на несущественные но трудоёмкие детали)»
То есть:
Это всего лишь упрощённая и несколько преувеличенная илюстрация, хоть и основанная на виденной мною реальной ситуации. Хотите — предложите более удачную, с благодарностью вставлю в статью. ИМХО, оценивать действия людей из такого примера — это всё равно что вести диалог с телевизором…
Цель этой статьи — показать что есть разные подходы со своими плюсами и минусами, и разные люди чувствуют себя более комфортно в рамках одного из них (что я тоже многократно наблюдал). При этом часто на тех кто более склонен к другому подходу смотрят как на неадекватов.
Судя по вашему коментарию, вам более интересен и близок white box. Ответьте себе честно, будете ли вы довольны своей работой, если вам придётся 99% времени заниматься «вытиранием воды» а не «починкой труб»? А есть люди которые этим занимаются с удовольствием и ничего другого им не надо. В гробу они видали разбираться с этими трубами. Они лучше просто вытрут то что натекло пока кто-то другой чинит трубу.
Задачи бывают разные, системы бывают разные, люди нужны и те и другие. И каждый на своём месте.
ИМХО то что вы сейчас описали есть ка раз разные уровни Black Box'a. Точнее BlackBox-матрёшка. Ни на одном из описанных вами этапов нет стадии выяснения как система реально устроена, как работает и что может приводит к проблеме. Впрочем, конечно же это и не всегда возможно. Как я уже упоминал, есть масса систем, для которых White Box подход или невозможен (недоступность информации, лимиты по времени, сложность системы) или нецелесообразен.
И ещё момент. Как правило, рано или поздно знаний не хватает. И ключевой момент, что человек сделает в этот момент первым: будет дополучать недостающие знания и доразбираться (если это конечно возможно) или будет искать готовое заклинание на просторах гугля не вникая в суть происходящего. Я встречал и тех и других.
Шорошо, давайте переформулируем немного иначе. Есть 2 категории решения задач. И большинство админов (не все) тяготеют к использованию приемущественно одной из них и будучи поставлены в условия необходимости использовать приемущественно другую категорию — становятся менее эффективны и менее довольны собой и своей работой.
Имхо всё правильно. Если человек способен сам себя мотивировать — он не будет жаловаться, а будет менять ситуацию. Если же не способен — будет ныть как всё плохо, как его не ценят, и как весь мир против него. И вот тут-то уже нужно его мотивировать извне, ибо, пока он сидит и жалеет себя, толку от него немного. Дешевле и проще найти кого-то, кто заставит плакальщиков работать, чем искать и вводить в курс дел тех кто способен работать сам, без внешних пинков, как автор статьи — последних значительно меньше.
За это, вероятно, можно сказать спасибо школе, которая за 10 лет старается вытравить всякую инициативу и желание что либо делать самостоятельно, без указания свыше, а любую инициативу и инакомыслие жёстко наказывает.
Подробней это реально долго… Полный дебаг лог астериска + куча дополнительной отладки и дампа переменных и состояний в каждом agi-скрипте — это 3-5 MB лога на каждый звонок.
Технически — ничто не мешает. Но это отдельное направление бизнеса, на это нужны ресурсы. А таковых и так нехватка. Так что получается, что приоритеты мешают. Да и потом, без интеграции с нашими системами это будет просто кластеризованный астериск с фантиками, а таких решений и без нас хватает.
Сайт есть и не один, один из них я даже упомянул в статье. К сожалению не совсем понял суть Вашего вопроса, Вы хотите связаться или посмотреть другие проекты или что-то предложить или что-то ещё?
~600 операторов «наготове». Одновременно говорящих в пиковое врема около 200. Ещё около 100 клиентов может быть во всяки Voice-Menu или очередях под музыку — а это куда более ресурсоёмко чем все разговоры вместе с Jitter-Buffer-ом.
Операторы работают с нашим VoIP proxy, а там у нас есть все логи, как на оператор<->прокси, так и на прокси<->сервера. Из полного дебаг-лога астериска довольно много можно надёргать. Кроме того, операторы сами жалуются на качество, так как они не на зарплате, а на проценте + надбавки/убавки за эффективность и плохое качество весьма мешает им зарабатывать, а вовремя заявленное плохое качество может быть принято во внимание при рассчётах.
Jitter-buffer используем всегда на линке прокси<->сервера и сервера<->провайдер потому как там почти всегда есть и неравномерные задержки и частенько перестановка пакетов. Дешевле платить за ресурсы, чем терять клиентов из-за «А? Что? Не расслышал!», а при его размере в 50ms задержка голоса всё ещё небольшая.
— данные между автором и банком идут шифрованные (https / tls)
— траффик всё равно идёт через Yota, то есть тот же самый траффик они могут поснифить и без клиента, только им придётся сидеть и ждать пока он в банк полезете или анализировать гораздо более крупный дамп, что совсем не ускорит процесс.
Принимая во внимание эти 2 пункта, я совсем не понял про " и уж тем более не заставляя их предоставлять sensitive data." — разве они просили что-то, что им и так технически не доступно? Другое дело, что это вообще не должно быть головной болью клиента, но это уже другой вопрос.
А не подскажете, где можно об этом подробнее почитать?
1. «Я буду намеренно немного утрировать, дабы сделать разницу несколько более наглядной.»
2. «Рассмотрим оба варианта на реальном (слегка упрощённом, дабы не тратить время на несущественные но трудоёмкие детали)»
То есть:
Это всего лишь упрощённая и несколько преувеличенная илюстрация, хоть и основанная на виденной мною реальной ситуации. Хотите — предложите более удачную, с благодарностью вставлю в статью. ИМХО, оценивать действия людей из такого примера — это всё равно что вести диалог с телевизором…
Цель этой статьи — показать что есть разные подходы со своими плюсами и минусами, и разные люди чувствуют себя более комфортно в рамках одного из них (что я тоже многократно наблюдал). При этом часто на тех кто более склонен к другому подходу смотрят как на неадекватов.
Судя по вашему коментарию, вам более интересен и близок white box. Ответьте себе честно, будете ли вы довольны своей работой, если вам придётся 99% времени заниматься «вытиранием воды» а не «починкой труб»? А есть люди которые этим занимаются с удовольствием и ничего другого им не надо. В гробу они видали разбираться с этими трубами. Они лучше просто вытрут то что натекло пока кто-то другой чинит трубу.
Задачи бывают разные, системы бывают разные, люди нужны и те и другие. И каждый на своём месте.
За это, вероятно, можно сказать спасибо школе, которая за 10 лет старается вытравить всякую инициативу и желание что либо делать самостоятельно, без указания свыше, а любую инициативу и инакомыслие жёстко наказывает.
Jitter-buffer используем всегда на линке прокси<->сервера и сервера<->провайдер потому как там почти всегда есть и неравномерные задержки и частенько перестановка пакетов. Дешевле платить за ресурсы, чем терять клиентов из-за «А? Что? Не расслышал!», а при его размере в 50ms задержка голоса всё ещё небольшая.