![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovДискуссии про то, что можно, а что нельзя сделать определенным техническими средствами очень часто скатываются в унылый срач, в котором стороны по кругу повторяют одно и то же из-за того, что:
1)Технические проблемы обсуждаются на уровне самой простой возможной реализации
2)Фичи и возможности обсуждаются на уровне навороченного сервиса или коммерческого продукта
3)Разрыв в сложности и требованиях к качеству между (1) и (2) одной из сторон напрочь игнорируются.
Чем меньше человек шарит в обсуждаемом, тем больший разрыв между (1) и (2) у него получается, и тем охотнее он его игнорирует.
Что я имею в виду? Перефразируя "Мистический человеко-месяц" Брукса (см. напрмер раздел Tar pit вот тут), разные уровни сложности технического решения можно описать вот так:
Накодили: мы делаем что-то один раз "на колене".
Превратили в практику: мы можем повторить свой успех "на колене" много раз.
Сделали сервис: мы формализовали наш опыт и отгородились от ошибок. Спецификации на исходные данные и результат. Контроль потребления ресурсов.
Сделали продукт: может использоваться человеком с минимальной квалификацией. Документирован. Протестирован. Интегрирован.
(это одна из возможных классификаций, не претендующая на роль единственной истинной)
Время и усилия, необходимые на внедрение каждого следующего уровня, многократно возрастают. Чтобы сделать что-то быстро на колене, может уйти N (часов, дней, ...). На то, чтобы сделать этот успех повторяемым, понадобится в 3-10 раз больше времени и сил. На программный сервис - еще больше. На продукт - на порядки больше.
Этот грустный аспект всегда учитывается при рассчете потенциальной отдачи - стоит ли тратить столько-то времени и сил? Какого качества результат мы получим? Оправдывает ли выхлоп усилия? Какой угодно (точнее - best-effort) результат может быть приемлимым или оправданным при однократной деятельности, но если мы ставим что-то на поток - то best effort уже явно недостаточен, более того - он может быть вреден. Типичный пример - изымание жидкостей на входе в самолет, повсеместно практикуемое сейчас.
Попробую проиллюстрировать сказанное на примере из предыдущего поста.
Оповестить тех, кто находится в зоне (предполагаемого) стихийного бедствия используя возможности мобильной связи.
Пришла беда, а никакой системы оповещения нет. Допустим, кто-то деятельный из МЧС связывается с оператором и просит помочь. Оператору не пофиг, и происходит что-то такое:
* Кто-то решает: "давайте разошлем СМС!" (для обсуждения именно СМС как средства оповещения есть другой пост).
* Радиопланирование берет зону на карте и выдает базовые, которые ее покрывают
* Эксплуатация базовой сети берет базовые и выдает TMSI/MSISDN тех, кто там делал location update
* Кто-то дает текст SMS
* Эксплуатация сервисных платформ осуществляет рассылку SMS
При этом самым главным элементом процесса будет какой-то технически подкованный сотрудник, который при помощи sed, grep, sql и такой-то матери "заинтегрирует" все этапы процесса: например, возьмет XML, который умеет экспортировать система радиопланеров и выберет оттуда идентификаторы базовых в виде, понятном эксплуатации базовой сети. Возьмет список MSISDN и отделит абонентов других "домашних сетей" (но оставит роумеров). Набросает скрипт, сующий SMS-ы в SMS-центр. Побъет список рассылки на куски, если надо. Посидит рядом, пока он расыслается, устраняя возникающие проблемы.
Каждый шаг сам по себе технически не сложен, но на стыковку и координацию участников уйдет уйма времени и сил. Будет много ошибок, но поскольку на каждом шаге доступны специалисты узкого профиля, они будут оперативно устранятся.
Весь процесс идет в режиме best effort - если получилось, то хорошо; если не получилось - ну, по крайней мере мы старались. При наличии умных инициативных людей на местах реально все сделать за 3-6 часов (большая часть времени уйдет на ожидание и синхронизацию участников). Но вполне реально, что может не повезти - где-то новичок чего-то не знает, где-то кто-то в отгуле и т.п.
После первого успеха вместо того, чтобы строить нормальную систему оповещения, кто-то решает "ну, в прошлый же раз как-то справились? давайте так и делать". И вот Оператору вменено в обязанность осуществлять подобные рассылки. Деятельность, описанная выше, становится частью должностных инструкций. Оператор следит за тем, чтобы люди с нужными знаниями были доступны (не ушли вместе в отпуск, имели дублера и т.п.). Новые сотрудники обучаются необходимым навыкам. Вовлеченные технические специалисты пишут на колене скрипты, облегчающие им жизнь (определяющие и устраняющие типичные ошибки). Время от времени проводятся тестовые рассылки. При необходимости (и при возможности) у поставщиков железа заказываются дополнительные API и лицензии.
Технические сложности по-прежнему сглаживаются тем, что в процессе непосредственно участвуют узкие специалисты. Появляется ряд организацонных сложностей, они кодифицируются (преврщаются в процедуры и проч.).
Best effort уже недостаточно. Оператор гарантирует (или его обязывают гарантировать) определенный уровень сервиса - скорость, объем рассылки, время реакции и т.п.
Чтобы создать и отладить этот процесс, потребуется, допустим, 2-6 месяцев (не в последнюю очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).
После пары факапов или чтобы разгрузить людей Оператор создает или покупает систему, у которой есть API, позволяющее делать такие рассылки сравнительно небольшими усилиями. Одному-двум сотрудникам поручена ее эскплуатация. Система умеет фильтровать большинство типичных ошибок (кривые номера телефонов, сбои при доставке, ...) и ведет себя пристойно с точки зрения потребления разных ограниченных ресурсов (нагрузка на SMS, HLR/VLR, ...).
Чтобы сделать спецификацию на такую систему, разработать или купить и интегрировать ее, потребуется, допустим, 6-12 месяцев (в первую очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).
Сотрудник МЧС может выделить мышкой область на карте, ввести текст СМС, после чего произойдет рассылка, а он в реальном времени будет видеть ее ход.
Для этого государство в лице МЧС выбирает поставщика (не надо смеяться :), который говорит "СМС-ы?! Да вы все упоролись!" и выкатывает спеку на, допустим, сервис на основе cell broadcast + специфического sim toolkit. Потом поставщик интегрируется с операторами, операторы потихоньку меняют абонентам сим-карты (или через OTA обновляют toolkit), и сервис запускается. Если есть в принципе доступна - сервис будет работать и информировать всех, у кого включен телефон (т.е. качество будет максимально возможным для данной технологии).
Чтобы все это интегрировать и внедрить нужно 6-24 месяцев.
Какие можно из этого сделать выводы?
Рассуждения вида "ну, можно было бы все равно разослать СМС-ы - даже если бы 10% дошло, все равно было бы хорошо" - это best effort, и это справедливо только в случае "пришла беда, откуда не ждали, и мы делаем все возможное и невозможное, чтобы спасти ситуацию". Если же риск или потребность прогнизируемы (а система оповещения, очевидно, необходима), если это не одноразовая работа (а система оповещения, очевидно, не одноразова), то best effort никуда не годится (тем более что есть гораздо более надежные или простые или дешевые альтернативы: cell broadcast, машины с матюгальником, радиоточки, ...).
Да, СМС может быть вспомогательным средством (наряду с фейсбуком, твиттером и прочими слабо подходящими средствами) в какой-то 10 или 15 версии сервиса, но при отсутствии альтернатвных надежных методов слова "оповещение населения" и "СМС" не должны стоять в одном предложении. Усилия надо тратить на что-то реально полезное, а не на фигню.
Just saying.
1)Технические проблемы обсуждаются на уровне самой простой возможной реализации
2)Фичи и возможности обсуждаются на уровне навороченного сервиса или коммерческого продукта
3)Разрыв в сложности и требованиях к качеству между (1) и (2) одной из сторон напрочь игнорируются.
Чем меньше человек шарит в обсуждаемом, тем больший разрыв между (1) и (2) у него получается, и тем охотнее он его игнорирует.
Что я имею в виду? Перефразируя "Мистический человеко-месяц" Брукса (см. напрмер раздел Tar pit вот тут), разные уровни сложности технического решения можно описать вот так:
Накодили: мы делаем что-то один раз "на колене".
Превратили в практику: мы можем повторить свой успех "на колене" много раз.
Сделали сервис: мы формализовали наш опыт и отгородились от ошибок. Спецификации на исходные данные и результат. Контроль потребления ресурсов.
Сделали продукт: может использоваться человеком с минимальной квалификацией. Документирован. Протестирован. Интегрирован.
(это одна из возможных классификаций, не претендующая на роль единственной истинной)
Время и усилия, необходимые на внедрение каждого следующего уровня, многократно возрастают. Чтобы сделать что-то быстро на колене, может уйти N (часов, дней, ...). На то, чтобы сделать этот успех повторяемым, понадобится в 3-10 раз больше времени и сил. На программный сервис - еще больше. На продукт - на порядки больше.
Этот грустный аспект всегда учитывается при рассчете потенциальной отдачи - стоит ли тратить столько-то времени и сил? Какого качества результат мы получим? Оправдывает ли выхлоп усилия? Какой угодно (точнее - best-effort) результат может быть приемлимым или оправданным при однократной деятельности, но если мы ставим что-то на поток - то best effort уже явно недостаточен, более того - он может быть вреден. Типичный пример - изымание жидкостей на входе в самолет, повсеместно практикуемое сейчас.
Попробую проиллюстрировать сказанное на примере из предыдущего поста.
Задача
Оповестить тех, кто находится в зоне (предполагаемого) стихийного бедствия используя возможности мобильной связи.
"Накодили"
Пришла беда, а никакой системы оповещения нет. Допустим, кто-то деятельный из МЧС связывается с оператором и просит помочь. Оператору не пофиг, и происходит что-то такое:
* Кто-то решает: "давайте разошлем СМС!" (для обсуждения именно СМС как средства оповещения есть другой пост).
* Радиопланирование берет зону на карте и выдает базовые, которые ее покрывают
* Эксплуатация базовой сети берет базовые и выдает TMSI/MSISDN тех, кто там делал location update
* Кто-то дает текст SMS
* Эксплуатация сервисных платформ осуществляет рассылку SMS
При этом самым главным элементом процесса будет какой-то технически подкованный сотрудник, который при помощи sed, grep, sql и такой-то матери "заинтегрирует" все этапы процесса: например, возьмет XML, который умеет экспортировать система радиопланеров и выберет оттуда идентификаторы базовых в виде, понятном эксплуатации базовой сети. Возьмет список MSISDN и отделит абонентов других "домашних сетей" (но оставит роумеров). Набросает скрипт, сующий SMS-ы в SMS-центр. Побъет список рассылки на куски, если надо. Посидит рядом, пока он расыслается, устраняя возникающие проблемы.
Каждый шаг сам по себе технически не сложен, но на стыковку и координацию участников уйдет уйма времени и сил. Будет много ошибок, но поскольку на каждом шаге доступны специалисты узкого профиля, они будут оперативно устранятся.
Весь процесс идет в режиме best effort - если получилось, то хорошо; если не получилось - ну, по крайней мере мы старались. При наличии умных инициативных людей на местах реально все сделать за 3-6 часов (большая часть времени уйдет на ожидание и синхронизацию участников). Но вполне реально, что может не повезти - где-то новичок чего-то не знает, где-то кто-то в отгуле и т.п.
"Сделали процедуру"
После первого успеха вместо того, чтобы строить нормальную систему оповещения, кто-то решает "ну, в прошлый же раз как-то справились? давайте так и делать". И вот Оператору вменено в обязанность осуществлять подобные рассылки. Деятельность, описанная выше, становится частью должностных инструкций. Оператор следит за тем, чтобы люди с нужными знаниями были доступны (не ушли вместе в отпуск, имели дублера и т.п.). Новые сотрудники обучаются необходимым навыкам. Вовлеченные технические специалисты пишут на колене скрипты, облегчающие им жизнь (определяющие и устраняющие типичные ошибки). Время от времени проводятся тестовые рассылки. При необходимости (и при возможности) у поставщиков железа заказываются дополнительные API и лицензии.
Технические сложности по-прежнему сглаживаются тем, что в процессе непосредственно участвуют узкие специалисты. Появляется ряд организацонных сложностей, они кодифицируются (преврщаются в процедуры и проч.).
Best effort уже недостаточно. Оператор гарантирует (или его обязывают гарантировать) определенный уровень сервиса - скорость, объем рассылки, время реакции и т.п.
Чтобы создать и отладить этот процесс, потребуется, допустим, 2-6 месяцев (не в последнюю очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).
"Сделали сервис"
После пары факапов или чтобы разгрузить людей Оператор создает или покупает систему, у которой есть API, позволяющее делать такие рассылки сравнительно небольшими усилиями. Одному-двум сотрудникам поручена ее эскплуатация. Система умеет фильтровать большинство типичных ошибок (кривые номера телефонов, сбои при доставке, ...) и ведет себя пристойно с точки зрения потребления разных ограниченных ресурсов (нагрузка на SMS, HLR/VLR, ...).
Чтобы сделать спецификацию на такую систему, разработать или купить и интегрировать ее, потребуется, допустим, 6-12 месяцев (в первую очередь потому, что все участники процесса на стороне оператора уже имеют 100500 разных дел, которые им надо делать каждый день).
"Продукт"
Сотрудник МЧС может выделить мышкой область на карте, ввести текст СМС, после чего произойдет рассылка, а он в реальном времени будет видеть ее ход.
Для этого государство в лице МЧС выбирает поставщика (не надо смеяться :), который говорит "СМС-ы?! Да вы все упоролись!" и выкатывает спеку на, допустим, сервис на основе cell broadcast + специфического sim toolkit. Потом поставщик интегрируется с операторами, операторы потихоньку меняют абонентам сим-карты (или через OTA обновляют toolkit), и сервис запускается. Если есть в принципе доступна - сервис будет работать и информировать всех, у кого включен телефон (т.е. качество будет максимально возможным для данной технологии).
Чтобы все это интегрировать и внедрить нужно 6-24 месяцев.
Какие можно из этого сделать выводы?
Рассуждения вида "ну, можно было бы все равно разослать СМС-ы - даже если бы 10% дошло, все равно было бы хорошо" - это best effort, и это справедливо только в случае "пришла беда, откуда не ждали, и мы делаем все возможное и невозможное, чтобы спасти ситуацию". Если же риск или потребность прогнизируемы (а система оповещения, очевидно, необходима), если это не одноразовая работа (а система оповещения, очевидно, не одноразова), то best effort никуда не годится (тем более что есть гораздо более надежные или простые или дешевые альтернативы: cell broadcast, машины с матюгальником, радиоточки, ...).
Да, СМС может быть вспомогательным средством (наряду с фейсбуком, твиттером и прочими слабо подходящими средствами) в какой-то 10 или 15 версии сервиса, но при отсутствии альтернатвных надежных методов слова "оповещение населения" и "СМС" не должны стоять в одном предложении. Усилия надо тратить на что-то реально полезное, а не на фигню.
Just saying.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
just for fun
Date: 2012-07-11 10:44 am (UTC)пара комментариев для улыбки:
- после фразы "XML, который умеет экспортировать система радиопланеров" некий радиопланёр, скажем, Пьетро Ф. подавился чаем с булочкой и спросил сквозь кашель что такое "ехемель".
- ввиду всего вышесказанного будет принято решение о развёртывании силами ДНК лидерства МШУ о'Сколково национальной программы оповещения через национальную сеть радиоточек, представляющих из себя стационарный gsm-телефон с громкоговорителем).
Re: just for fun
Date: 2012-07-14 11:58 am (UTC)Re: just for fun
Date: 2012-07-14 06:12 pm (UTC)Re: just for fun
Date: 2012-07-14 07:33 pm (UTC)Но бывает разное. Мы так SQL-ем лазили в базу к планерам.
Re: just for fun
Date: 2012-07-15 10:10 am (UTC)Re: just for fun
Date: 2012-07-15 10:41 am (UTC)Ну поменяли железо, так по идее, лучше стать должно... По сравнению с тем, что там было раньше...
Re: just for fun
Date: 2012-07-15 12:07 pm (UTC)лучше - только по идее, каждый производитель в своём железе и ПО трактует стандарт и реализует алгоритмы по-своему).
Re: just for fun
Date: 2012-07-15 01:11 pm (UTC)Обычно "напрямок перевантажено" слышно в случаях, когда перегрузка возникает в межсвитчевых соединениях или на стороне второго абонента.
Описанная ситуация больше похожа на то, что опять продали больше, чем технари успевают обслужить :) - и перегрузки на соте.
По поводу разницы в трактовке стандартов - да, они существуют, но такие отклонения возникают редко. Для общепринятых стандартов в GSM я встречался с таким только дважды, и то, это касалось только крайне редко возникающих сценариев типа "абонент с балансом на счету меньшим порога нотификации звонит сам себе, поднимает трубку и ничего не слышит :)". Тестированиевсе же проводится довольно тщательно и, например, 5000 различных сценариев, проверенных при приемке нового свитча - вовсе не фокус. А если новой модели - так там счет тестовых сценариев идет на десятки тысяч.
В данном случае дело скорее в том, что стандарты не говорят, какой должен быть анонсмент, а что нужно сделать, чтобы он был проигран. И, соответственно, настройка таких деталей - это, как правило, некий компромисс между дефолтными настройками оборудования и пожеланиями оператора. Сильно похоже, что просто забыли попросить поставщика "включать три свистка" а этом сценарии. Да, и какая разница, по большому счету - были они или нет, если все равно не дозвонились :). А, кстати, это еще может и моделью телефона определяться. Так, мой старый сименс МЕ45 был в этом плане нааамного информативнее htc. Вот тут на 25-й странице видно, что часть тонов - optional. И может не генерироваться :(.
http://www.3gpp.org/ftp/Specs/archive/22_series/22.001/22001-430.zip
Re: just for fun
Date: 2012-07-15 07:20 pm (UTC)(no subject)
Date: 2012-07-11 10:50 am (UTC)Непонимание того, что из "один раз на коленке" нельзя сделать хороший продукт минимумом средств и сил - общее место большинства заказчиков со стороны бизнеса, да и ИТ-шники этим регулярно грешат.
(no subject)
Date: 2012-07-11 11:23 am (UTC)(no subject)
Date: 2012-07-11 11:43 am (UTC)(no subject)
Date: 2012-07-11 12:43 pm (UTC)(no subject)
Date: 2012-07-11 12:47 pm (UTC)Но по сути именно это и нужно - чтобы матюгальники врубались по команде на всей опасной территории и с нужным текстом, а в остальное время молчали. Проект по-любому убыточный.
(no subject)
Date: 2012-07-11 03:16 pm (UTC)(no subject)
Date: 2012-07-11 06:35 pm (UTC)(no subject)
Date: 2012-07-12 12:02 am (UTC)(no subject)
Date: 2012-07-12 10:44 am (UTC)(no subject)
Date: 2012-07-13 06:57 pm (UTC)Была аппаратура П-160/164/166 с огромной номенклатурой изделий для организации всего-всего касаемо оповещения на разных уровнях.
Первая попавшаяся цитата про систему:
(no subject)
Date: 2012-07-13 10:49 pm (UTC)(no subject)
Date: 2012-07-13 10:54 pm (UTC)(no subject)
Date: 2012-07-11 01:19 pm (UTC)Ерунда, значит всего лишь надо удалённо их включить, ггг!
(no subject)
Date: 2012-07-11 01:20 pm (UTC)(no subject)
Date: 2012-07-11 03:27 pm (UTC)(no subject)
Date: 2012-07-11 01:34 pm (UTC):D
(no subject)
Date: 2012-07-11 02:46 pm (UTC)(no subject)
Date: 2012-07-11 03:08 pm (UTC)Понятно, что на коленке нечто подобное соорудить за пару часов (или даже минут) можно, но для этого нужно работать в Голливуде.
Гораздо проще и дешевле вопрос решен там где я живу сейчас (торнадо-пояс в США) - старые сирены гражданской обороны в городах побольше, радио на аккумуляторах с автоматической настройкой на аварийную АМ-волну у людей живущих "в глуши". Ну и сеть аварийных автоматических АМ-радиостанций.
(no subject)
Date: 2012-07-11 03:17 pm (UTC)(no subject)
Date: 2012-07-11 09:47 pm (UTC)(no subject)
Date: 2012-07-11 11:56 pm (UTC)(no subject)
Date: 2012-07-12 02:39 am (UTC)и мартинсы... мартинсы ... мартинсы хочется.. ых..
(no subject)
Date: 2012-07-12 03:03 am (UTC)(no subject)
Date: 2012-07-12 03:15 am (UTC)но это жесткий офф, особенно если учесть сколько обувь вменяемая стоит в Киеве..
(no subject)
Date: 2012-07-13 09:50 am (UTC)P.S. да, кстати, Converse -- говно. Comverse чуть лучше. Кеды классные есть у, кто б подумал, Crocs.
--
just my 2c worth,
xrgtn
(no subject)
Date: 2012-12-26 09:29 pm (UTC)а в чем техническая сложность рассылки?
smpp или вообще тупо инсерт в базу rtbs.
по какой-либо аналитике тоже не вижу проблем: по релиз кодам из call history мы находили проблемы в сети, время когда народ едет с/на работу и обеденный перерыв. имея привязку lac/cell id к gps координатам можно куда более интересную аналитику делать. плюс, с появлением у операторов систем, пишущих весь сигнальный обмен - все еще проще.
(no subject)
Date: 2012-12-26 10:10 pm (UTC)я вообще-то не большой спец по телефонии, я IP сетями занимаюсь :)
насколько я помню там продукт (location-based SMS delivery) был заточен в основном на рекламу; соответсвенно куча кода поддерживала коммерческую часть процесса; сама доставка была не через SMPP (тогда это слово еще не все наши клиенты знали :) а напрямую в базу нашего SMSC итд итп.
опять таки, ничего сложного, но для надежной работы и соответсвия SLA нужен был толковый программер и 3-4 тестера на пару-тройку месяцев.
(no subject)
Date: 2012-07-11 08:07 pm (UTC)Машины со звуковой апаратурой кажутся раз в 100 надёжнее и полезнее. Оборудовать ими все машины экстренных служб?
(no subject)
Date: 2012-07-12 04:26 pm (UTC)(no subject)
Date: 2012-07-13 11:01 pm (UTC)(no subject)
Date: 2012-07-13 07:39 am (UTC)"Если есть в принципе доступна" - опечатка?
Всё так и есть, а фразу "при отсутствии альтернативных надежных методов слова "оповещение населения" и "СМС" не должны стоять в одном предложении." - в рамочку и на стену.
О технических решениях. Как оказалось, очень не очевид
Date: 2012-07-13 03:28 pm (UTC)(no subject)
Date: 2012-07-14 11:22 am (UTC)А в некой компании именно такой юз-кейс занимает 5 дней. Каждого же нужно по процедуре известить, выделить, написать запрос через SD на проведение выборки, согласовать его и т.д. Проверено лично. Причем именно на кейсе "оповестить область через СМС" :). При том, что есть вполне промышленная система "рассылки СМС по списку абонов".
А Израиль с тобой не согласен :)
Date: 2012-08-14 10:49 am (UTC)Re: А Израиль с тобой не согласен :)
Date: 2012-08-14 11:07 am (UTC)И кому верить - ленте.ру (которая пишет про смс) или поставщику (который пишет про CB)?
(no subject)
Date: 2012-09-17 09:36 pm (UTC)