Еще раз про запись всех разговоров
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-18 09:37 pm (UTC)20м абонентов по полчаса в сутки = 60 тб/сутки.
Учитывая, что реалтайм не нужен, и особые требования к надежности - тоже, можно хранить на каждой соте или каком-то роутинг-узле rolling log, скажем, на 5-10 тб обьемом, длительностью суммарно по всем таким узлам выйдет где-то от нескольких суток до месяца.
Стоимость, по сравнению с остальными узлами - минимальна - можно даже эти данные никуда не передавать, пока люди в погонах или кто-то еще не попросят ("записи за вчерашний день"), а для них - гонять запрос параллельно на всех узлах.
Так что, по-моему, вполне реально. Но в нынешних реалиях намного проще и беспалевнее троянить смартфоны, чем отдельные товарищи (вроде CarrierIQ) успешно и занимаются.
(no subject)
Date: 2012-05-18 09:43 pm (UTC)(no subject)
Date: 2012-05-18 09:54 pm (UTC)Но даже если дописать к бюджету нолик, то это все равно вкладывается в суммы, выделяемые украинским спецслужбам. Штатам, соответственно, можно приписать три нолика к выделенным деньгам и один нолик к количеству абонентов :)
(no subject)
Date: 2012-05-19 01:32 am (UTC)(no subject)
Date: 2012-05-28 03:58 pm (UTC)Написано же вон прямым текстом, что руководство было в курсе. Я уверен, что и CEO про реактор докладывали загодя, и дело было примерно так:
- Мы тут собрались ставить реактор, чтобы им облучать опытные образцы пленки и бла-бла-бла. В результате мы получим новые крутые рентгеновские (или какие еще) пленки, без реактора каждая новая версия тестируется хз где, долго и дорого. Цена вопроса - X миллионов, окупится за Y лет.
- Ну ок, покупайте
Сравним с:
- Мы тут собрались записывать все разговоры. Цена вопроса - Х миллионов. Оно никому не надо, но мы потом отчитаемся типа как за сделанный проект, еще и премию попросим. Да, и пока над этим будем работать, остальные проекты (А, B, C) чуток затянутся, ок?
- ???!!!
Или:
- Мы тут собрались записывать все разговоры. Цена вопроса - Х миллионов. Записи будем продавать налево, леваком поделимся. Если что, сядем или уволимся все вместе, ок?
- ???!!!
(no subject)
Date: 2012-05-18 09:47 pm (UTC)(no subject)
Date: 2012-05-18 09:52 pm (UTC)(no subject)
Date: 2012-05-19 01:36 am (UTC)(no subject)
Date: 2012-05-19 01:38 am (UTC)(no subject)
Date: 2012-05-19 12:46 pm (UTC)(no subject)
Date: 2012-05-19 06:15 pm (UTC)(no subject)
Date: 2012-05-20 08:47 am (UTC)(no subject)
Date: 2012-05-20 09:02 am (UTC)(no subject)
Date: 2012-05-20 09:16 am (UTC)Для хранения rolling log'a не требуются десятки терабайт и гарантированное электропитание, поскольку мы делаем best-effort, не реалтаймовый сервис.
(no subject)
Date: 2012-05-20 11:16 am (UTC)Надёжность хранения стораджа впрямую зависит от электропитания. Поставили сторадж - обеспечь гарантию. Кстати, сторадж ещё та энергопотреблялка.
Плюс винты ездить менять, мониторить их. Еще надо решить проблему дублирования разговора, если абоненты, ведущие разговор, на разных базовых сидят.
Итого: при распределённом решении - огромные потери на эсплуатации.
PS. "скажем, на 5-10 тб обьемом" = десятки терабайт.
(no subject)
Date: 2012-05-20 12:51 pm (UTC)Берем 100 мбайт RAM. Складываем туда эти звонки. 16 мбайт\сек.
Каждые 5 сек сбрасываем блок в сторейдж, с указанием, кто кому звонил в данном блоке. <1 IOPS, 20 мб\c. Под блок номеров выделяем еще 10 мбайт, сбрасываем каждую минуту, gzip'аем, естественно.
Когда приходит запрос "выдать звонки таких-то абонентов", проводим линейный скан по блокам с номерами и грепаем их на предмет нужного номера. Вычитываем нужные блоки с звонками. Фильтруем прочитанное в RAM. Передаем ответ. ~2-5 IOPS, 160 мбайт\сек, ориентировочное время выполнения запроса "за сутки" - <1 минуты.
На сутки хватит ОДНОГО SATA-диска (180 мбайт\с, 2 тб, 60 IOPS). С дублированием - двух. Pooling не нужен. Если рейд софтверный, то мы спрашиваем, какие части зеркал отвалились, и по возможности на развалившиеся зеркала не пишем. Хотя, нагрузка никакая, выдержат, имхо.
Проблема дублирования разговора решается на клиентской машине, на которую приходит свалка результатов ото всех базовых.
Винты, на которые не производится запись, тупо отключаем, экономя электроэнергию. Пришел запрос? замечательно, включаем столько, сколько сможем отпарсить read bandwidth.
Кстати, можно вообще на кассетках делать, благо, ТЗ позволяет - будет слегка дороже, но намного проще, и, возможно, дешевле в эксплуатации.
Ну кто здесь строил high-load системы, в самом деле?
Я так, рядом стоял, самое сложное что было - 30м хитов в сутки на 1 сервер стоимостью 2k$ (аналитика от датчиков и сбоев софта), и у нас вполне себе soft realtime получалось, с окном задержки в 10 секунд...
(no subject)
Date: 2012-05-20 07:34 pm (UTC)(no subject)
Date: 2012-05-20 07:36 pm (UTC)Нет, не жесткого диска, и не ОС. Свой собственный, в приложении.
(no subject)
Date: 2012-05-20 08:34 pm (UTC)PS. Или мы кэш одним потоком сливать будем, сплошняком, вперемешку.
PPS. Я как представлю - 1000 ПАКов (2 сервера, 40 дисков, софтварный рэйд, ПО на коленке) по всему региону 500 км на 500 км. Без нормального мониторинга и самовосстановления.
PPPS. Кстати, ещё обычно предлагают забабахать RAID на базе Intel Matrix :D
(no subject)
Date: 2012-05-20 08:51 pm (UTC)Там приведены цифры, между прочим :)
100 мб RAM пишущему потоку, где-то столько же, или даже меньше - читающему.
> PS. Или мы кэш одним потоком сливать будем, сплошняком, вперемешку.
Да, выше достаточно подробно описан алгоритм, как сделать это одним потоком на запись и одним потоком на чтение. Почитайте внимательно.
> И не забудьте, вам ещё БД нужна, куда будет инфа укладываться, какому файлу какой звонок соответствует.
Зачем нам коммитить каждый фрейм звонка отдельно, да даже каждый звонок?
(no subject)
Date: 2012-05-20 08:06 pm (UTC)(no subject)
Date: 2012-05-20 08:38 pm (UTC)