Еще раз про запись всех разговоров
2012-05-18 08:25 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovВ комментариях к соседней записи опять стала муссироваться тема записи всех звонков без разбора, и мне захотелось сделать короткое резюме.
Для начала текущее положение вещей
Все известные мне законы (я в курсе про Россию-Украину, Евросоюз, UK, страны Балтии) обязывают операторов делать ровно две вещи:
* Хранить (много лет) и предоставлять метаданные о разговорах (кто кому когда звонил)
* По решению суда/прокуратуры записывать разговоры конкретного абонента или предоставлять техническую возможность вести такую запись с момента поступления к ним такого предписания. Список тех, кого слушают, "не резиновый" - нельзя взять и, грубо говоря, запихнуть туда все номера всех абонентов.
Записи разговоров и тексты СМС операторы сохранять не обязаны.
А если все же обяжут?
Если вдруг эти требования ужесточатся, оператору будет:
(1) Достаточно легко начать хранить тексты СМС. Так как SMS-центров мало, они расположены централизовано, SMS мелкий - возможно даже меньше, чем объем метаданных о том, кто кому и как его послал)
(2) Не очень легко начать хранить записи всех разговоров. Так как объемы солидные, коммутаторов много, они могут быть территориально разнесены, потребуется их апгрейд, плюс возможно понадобится пост-процессинг - в процессе разговоров звонки могут "кочевать" по узлам сети, и каждый отдельно взятый коммутатор может "слышать" только часть разговора. Плюс, если вдуматься, у оператора существующая базовая сеть рассчитана на определенную нагрузку. Если начать, грубо говоря, передавать тот же объем данных дважды (пусть и без жестких realtime-требований), то потребуется либо доп. каналы связи (чтобы сразу передавать куда-то в центр и там обрабатывать), либо процессорные мощности и каналы связи (жмем в mp3, а уже потом передаем), или какие-то другие инженерные решения. Естественно, это все решаемые проблемы. Все, что я хочу сказать - задача не сводится к "поставили винт побольше, и всего делов", как это многим кажется на первый взгляд.
А вдруг оператор сам ...?
А вдруг оператор сам хранит эти данные для каких-то своих нужд, и это делается для всех абонентов без разбора?
(3) Это справедливо в отношении метаданных - по ним производится биллинг, то есть определяется объем потребленных услуг и выставляются счета.
(4) Это может быть справедливо для СМС: они могут попадать в какие-то логи на SMS-центре, быть частью бэкапов, и т.п.
* Хранить записи всех разговоров оператору никакой необходимости нет
(5) При этом я вполне допускаю, что в процессе разбирательств с какой-то проблемой оператор вполне может выборочно сохранять как СМС-ы, так и звонки - но, скорее всего, критерием выборки будет не "для вот этих абонентов", а "для вот этого оборудования".
А вдруг все-таки оператор это делает?
Пофантазируем. Может ли все-таки получится, что оператор сохраняет все записи всех звонков? Может, он из этого извлекает какую-то выгоду? Честно говоря, как я ни старался, я не смог придумать подходящего сценария кроме "группа сотрудников вступила в сговор и продает данные криминальным элементам".
Ок, насколько это реально? Проблема в том, что сначала надо эти звонки где-то сохранять. Сделать это "на вот этом сервере вот тут в закутке" - не выйдет, не те объемы (если сохранять всё). Купить для этого отдельно железо - не выйдет, по понятным причинам. Да и потом, технически проще "торговать налево" чем-то, что имеет альтернативное легитимное применение - помогать спаммерам рассылать SMS, занижать суммы счетов, торговать распечатками метаданных или кодами пополнений баланса. И то, для этого, по моим прикидкам, потребуется соучастие не двух, и не пяти и даже не десяти человек в самых разных подразделениях, и подобная затея имеет очень большие шансы на провал даже при том, что можно попытаться сделать хорошую мину при плохой игре ("да мы тут просто ... это ... тестируем ...."). А большой склад записей звонков - это чистый криминал, никаких альтернативных объяснений ему быть не может, и любой безопасник с радостью съест всех замешанных без соли и перца.
А вот моего друга кума говорила, что ей показывали распечатки или записи звонков за 2006 год ...
У меня есть два гораздо более простых (по сравнению с "оператор пишет все") объяснения этому факту. Куму прослушивали в рамках оперативных мероприятий (см. выше), или же ее собеседника прослушивали точно таким же образом.
Для удобства восприятия информация сведена в табличку
Для начала текущее положение вещей
Все известные мне законы (я в курсе про Россию-Украину, Евросоюз, UK, страны Балтии) обязывают операторов делать ровно две вещи:
* Хранить (много лет) и предоставлять метаданные о разговорах (кто кому когда звонил)
* По решению суда/прокуратуры записывать разговоры конкретного абонента или предоставлять техническую возможность вести такую запись с момента поступления к ним такого предписания. Список тех, кого слушают, "не резиновый" - нельзя взять и, грубо говоря, запихнуть туда все номера всех абонентов.
Записи разговоров и тексты СМС операторы сохранять не обязаны.
А если все же обяжут?
Если вдруг эти требования ужесточатся, оператору будет:
(1) Достаточно легко начать хранить тексты СМС. Так как SMS-центров мало, они расположены централизовано, SMS мелкий - возможно даже меньше, чем объем метаданных о том, кто кому и как его послал)
(2) Не очень легко начать хранить записи всех разговоров. Так как объемы солидные, коммутаторов много, они могут быть территориально разнесены, потребуется их апгрейд, плюс возможно понадобится пост-процессинг - в процессе разговоров звонки могут "кочевать" по узлам сети, и каждый отдельно взятый коммутатор может "слышать" только часть разговора. Плюс, если вдуматься, у оператора существующая базовая сеть рассчитана на определенную нагрузку. Если начать, грубо говоря, передавать тот же объем данных дважды (пусть и без жестких realtime-требований), то потребуется либо доп. каналы связи (чтобы сразу передавать куда-то в центр и там обрабатывать), либо процессорные мощности и каналы связи (жмем в mp3, а уже потом передаем), или какие-то другие инженерные решения. Естественно, это все решаемые проблемы. Все, что я хочу сказать - задача не сводится к "поставили винт побольше, и всего делов", как это многим кажется на первый взгляд.
А вдруг оператор сам ...?
А вдруг оператор сам хранит эти данные для каких-то своих нужд, и это делается для всех абонентов без разбора?
(3) Это справедливо в отношении метаданных - по ним производится биллинг, то есть определяется объем потребленных услуг и выставляются счета.
(4) Это может быть справедливо для СМС: они могут попадать в какие-то логи на SMS-центре, быть частью бэкапов, и т.п.
* Хранить записи всех разговоров оператору никакой необходимости нет
(5) При этом я вполне допускаю, что в процессе разбирательств с какой-то проблемой оператор вполне может выборочно сохранять как СМС-ы, так и звонки - но, скорее всего, критерием выборки будет не "для вот этих абонентов", а "для вот этого оборудования".
А вдруг все-таки оператор это делает?
Пофантазируем. Может ли все-таки получится, что оператор сохраняет все записи всех звонков? Может, он из этого извлекает какую-то выгоду? Честно говоря, как я ни старался, я не смог придумать подходящего сценария кроме "группа сотрудников вступила в сговор и продает данные криминальным элементам".
Ок, насколько это реально? Проблема в том, что сначала надо эти звонки где-то сохранять. Сделать это "на вот этом сервере вот тут в закутке" - не выйдет, не те объемы (если сохранять всё). Купить для этого отдельно железо - не выйдет, по понятным причинам. Да и потом, технически проще "торговать налево" чем-то, что имеет альтернативное легитимное применение - помогать спаммерам рассылать SMS, занижать суммы счетов, торговать распечатками метаданных или кодами пополнений баланса. И то, для этого, по моим прикидкам, потребуется соучастие не двух, и не пяти и даже не десяти человек в самых разных подразделениях, и подобная затея имеет очень большие шансы на провал даже при том, что можно попытаться сделать хорошую мину при плохой игре ("да мы тут просто ... это ... тестируем ...."). А большой склад записей звонков - это чистый криминал, никаких альтернативных объяснений ему быть не может, и любой безопасник с радостью съест всех замешанных без соли и перца.
А вот моего друга кума говорила, что ей показывали распечатки или записи звонков за 2006 год ...
У меня есть два гораздо более простых (по сравнению с "оператор пишет все") объяснения этому факту. Куму прослушивали в рамках оперативных мероприятий (см. выше), или же ее собеседника прослушивали точно таким же образом.
Для удобства восприятия информация сведена в табличку
| Метаданные о звонке (кто, кому, когда, как долго, в какой соте, ...) | Тексты СМС | Запись разговоров | |
| Обязывает ли закон операторов хранить и предоставлять эти данные для всех абонентов? | Да | Нет | Нет |
| Если оператора обяжут, легко ли ему будет хранить эти данные в полном объеме? | -- | Да(1) | Нет(2) |
| Обязывает ли закон осуществлять выборочную запись этих данных (по предписанию прокуратуры, ...) | -- | Да | Да |
| Хранит ли оператор такие данные для всех абонентов независимо от требований закона? | Да(3) | Возможно(4) | Нет |
| Хранит ли оператор такие данные выборочно? | -- | Возможно(5) | Возможно(5) |
(no subject)
Date: 2012-05-20 07:43 pm (UTC)В данном случае задача отлично решается софтверно - поскольку нам достаточно eventual consistency.
Если вдруг потребуется делать on-line аналитику по этим данным - тогда я, конечно, буду голосовать за SAN, причем на SSD или вообще DDR.
Но сейчас вы пытаетесь забивать гвозди микроскопом.
Другой пример: до Google практически не было enterprise, которые бы пытались горизонтально масштабироваться. Они же - масштабируются горизонтально, и я что-то не слышал, чтобы у них был низкий аптайм или высокие расходы на обслуживание.
(no subject)
Date: 2012-05-20 08:37 pm (UTC)Кстати, вот эта фраза "SAN, причем на SSD или вообще DDR" это, извините, полный бред.
Давайте не будем сьезжать с темы на гугл, тут есть конкретная задача, которую вы предлагаете задешёво решить.
(no subject)
Date: 2012-05-20 09:10 pm (UTC)http://users.livejournal.com/_adept_/121187.html?thread=3276899#t3276899 тут вообще-то расписан алгоритм, в достаточных подробностях, чтобы его реализовать без дополнительных указаний.
> Кстати, вот эта фраза "SAN, причем на SSD или вообще DDR" это, извините, полный бред.
http://www.cybernetics.com/ssdsanstorage/iSAND20SSD.php
ок, как правильно называется это решение?
> Давайте не будем сьезжать с темы на гугл, тут есть конкретная задача, которую вы предлагаете задешёво решить.
Давайте вы напишете симулятор БС, а я - свое решение. Язык - Python, C#, да что угодно, в принципе. Интерфейс - TCP/IP (я открываю сокет, вы кидаете в него симулированные фреймы). Идет?
(Просто там, навскидку, больше кода на симулятор адекватной БС, чем на эту самую писалку, а мне не хотелось бы распинаться самому, если даже работающий код вас не убедит)
(no subject)
Date: 2012-05-20 09:19 pm (UTC)Расписан, расписан, правда потом кэш появился. потом ещё чтонибудь появится.
> ок, как правильно называется это решение?
А вы видите, что там написано? SAN storage - допустимо, SAN c SSD - бред полный. Вы в курсе, что такое SAN?
> Давайте вы напишете симулятор БС
Смысл тратить время на реализацию этого, если и так понятно, что нормально это работать не будет.
(no subject)
Date: 2012-05-20 10:46 pm (UTC)Где "потом"? Перечитайте еще раз http://users.livejournal.com/_adept_/121187.html?thread=3276899#t3276899 , ну?
> Вы в курсе, что такое SAN?
Комплекс, предоставляющий доступ к массиву устройств хранения как к единому виртуальному block device.
Соответственно, SAN с SSD - SAN, полностью опирающийся на SSD, либо использующий их как hot tier.
> Смысл тратить время на реализацию этого, если и так понятно, что нормально это работать не будет.
Я видел людей, которые клялись и божились, что один сервер не может держать 100K TCP-соединений. Или, что нельзя делать push-уведомления через HTTP. Потом мы показывали им этот сервер (несчастную 1U-коробочку в углу офиса), и они все равно не верили, искали, где же мы их обманываем :)
Ну, что ж поделать, когда-то и летательные аппараты тяжелее воздуха колдунством считали...
(no subject)
Date: 2012-05-21 11:39 am (UTC)Соответственно, SAN с SSD - SAN, полностью опирающийся на SSD, либо использующий их как hot tier.
SAN - storage area network. SAN это сетевые коробки, образующие сеть для storage и серваков. storage - эта та коробка с дисками, которая отдает через эту сеть блочные ресурс серверу.
В принципе уже можно завязывать с разговором, так вы не понимаете то, о чём говорите.
(no subject)
Date: 2012-05-21 12:02 pm (UTC)Заодно, расскажите, почему вы не считаете iSCSI SAN-протоколом. Мир на Fibre Channel не заканчивается.
(no subject)
Date: 2012-05-22 11:22 pm (UTC)(no subject)
Date: 2012-05-20 09:22 pm (UTC)И, кстати, они мухлюют, эта коробка будет работать по iSCSI, к SAN никакого отношения.
(no subject)
Date: 2012-05-20 09:13 pm (UTC)Давайте так: вы пишете симулятор БС, а я - эту самую систему. Интерфейс - tcp/ip (я открываю сокет, вы пишете туда фреймы звонков)
Почему так: боюсь, вас даже работающий код не убедит, а симулятор БС мне писать лень - там кода больше, чем в писалке звонков и аналитике.
(no subject)
Date: 2012-05-20 09:58 pm (UTC)