> но там всего пара сотен событий в секунду в пиках при более чем 100К абонентов, далеко не самая нагруженная часть биллинга.
В этом и приемущество: задержки минимальны. При синхронизации у вас происходят тяжелые выборки на обоих концах, а разница реплицируется. Это опять таки приводит к необходимости держать именно sql базу под радиусом (поскольку так удобнее).
Но я так понимаю, что все таки полная синхронизация у вас есть? На случай потери консистетности этого ААА сервиса из-за не дошедших, ошбочных событий, должна быть.
А статистику вы как обратно в ядро загоняете? Например логи радиус сервера, статусы сессий, флоу. Или это отдельный сервис?
Я имел ввиду синхронизацию внутри биллинга, когда данные синхронизируются между центральным ядром и базами над которыми крутится радиус сервер. А у вас тут похоже очереди, что несколько быстрее, чем синк по расписанию.
Как раз слепок и был кривой, судя по статье. Вообще вопрос быстрой доставки статуса на авторизующие сервера (которые ещё обычно шардятся и реплицируются в хороших биллингах) это один из самых горячих вопросов последних лет, но мой взгяд. Конкуренция провайдеров усилилась и если раньше абонент не растраивался, когда интернет у него после оплаты появлялся минут через 10 (а то и через час), то нынче это считается уже как-то не современно. Абонент ожидает, что он махнул карточкой на сайте провайдера и интернет в тот же момент появился. Отсюда, наверное, использование диспетчера очередей в Гидре.
Хотя многие по-прежнему делают синхронизацию с ядром по расписанию. И типичный шаг там 5-10 минут.
Это не про провайдеров. Удивительно, но там даже админов на билинге может не быть. Т.е. просто нет человека, который поддерживает машину и все. Только менеджеры, которые, когда припечет, пойдут по офису и выдернут кого-нибудь занимающегося сетевыми вопросами, чтоб он попробовал реанимировать машину с Linux и Oracle.
Хорошо, конечно, но что делать с паролями и аккаунтами? Пропускать всех? Или использовать устаревшую базу? А если телефония, то пропускать всех не стоит. Много вопросов тут.
Ещё одна проблема с GOPATH — это форк проектов на github. Решил ты помочь в разработке foo/bar, делаешь форк к себе moi/bar и клонируешь на локальную машину. И все, проект не собирается, поскольку в коде куча мест с import foo/bar/, ну и приходится либо делать симлинк, либо работать с двумя remote в git.
Ну, вот у меня тоже Saas и существенных проблем не было. Вообще, возможно, объемы не те (до 70 000 в день во все стороны). Процент не активных ящиков там велик, но мы стараемся такие вещи отслеживать и чистить базу от мертвяков, хотя это затруднительно с юридической точки зрения. При этом клиенты, которые с головой дружат и используют SPF на своих доменах вообще проблем не испытывают.
Эм. А подскажите мне где вы работаете, я ваши блоки адресов тоже занесу в персональный блок лист. Правильно mail.ru делает. Если вы не хотите бороться со спамом с вашего ip, не подписаны на FBL, то чего вы жалуетесь?
Шаред хостеры с их безобразным отношением к безопасности и непрофессиональными разработчиками сайтов это второй по объему источник спама. Первый (зомби из клиентских сетей) рубится PBL, а вот на вас управы нет ибо можно с водой ребенка выплеснуть.
Да я имелл ввиду, что в принципе никто не включает SPF в стрикт: только что проверил: Гугл, Яндекс, Майлру, все в ~all. SPF у этих ребят уж сколько лет, а все ~. На DMARC конечно есть надежда, поскольку есть репортинг.
Из своих наблюдений я бы сказал, что опытных админов, безопасников и вообще технических спецов, отличает не привычка использования mutt (это редкость), а привычка отключать html отображение писем и нелюбовь к почтовым веб интерфейсам в принципе.
«p=none» просто делает всю эту историю бесполезной. Так же как в SPF все пишут "~all".
Если бы крупные игроки договорились, набрались мужества и поставили p=reject, -all, то это бы дало существенный буст борьбе со спамом. Да, ценой небольших потерь писем, но оно того стоило.
Немного не то. TTL это вещь понятная: наступило событие, если через n секунд не наступило ещё раз, значит дело труба. Во многих системах мониторинга это называется heart beat — отслеживаение периодических событий. В случае бэкапа дело сложнее. Во-первых, расписание не имеет четкого периода. Логика расписания намного сложнее и завязана на бизнес нагрузку (днем легкие инкременталы, ночью полный бэкап, но не в каждую ночь). Во-вторых, нужно анализировать не только время запуска, но и длительность, которая тоже разная в разные периоды месяца, и нужно уметь отследить аномалии в длительности или объеме бэкапа.
Кто-нибудь может подсказать что можно ли подобный софт использовать для мониторинга предопределённых событий? Ну например, каждую ночь идет бэкап определённого хоста. При этом, сутуация, когда он закончился фейлом ловится любой системой мониторинга хорошо, а вот ситуация, когда он вообще в тихую не начался, требует сопоставления с эталонным расписанием. И вот этот случай я как-то не знаю чем можно покрыть. Читаешь о всех этих модных средствах и аж глаза разбегаются.
Ну как бы на данный момент, как я уже говорил, уже есть релиз, который уже работает, в котором есть подсветка синтаксиса, все базовые кнопки, макросы, визуальный мод, множественные курсоры (новшество, относительно вим).
Им уже можно пользоваться как редактором. Что я и делаю последние два дня.
Ну я не могу говорить за авторов, но лично я бы не отказался от vim подобного редактора с хорошим RPC, чтоб писать плагины на том языке, который удобен в данном, конкретном случае.
Насколько я понимаю, существенная проблема современного vim, в том, что полностью кодовую базу уже никто не понимает и, как следствие, существенные проблемы (например подсветка синтаксиса) не могут решится уже много лет.
Т.е. грубо говоря цель это проекта редактор и ничего более.
Кому любопытно, появился проект написания с нуля редактора цель которого выполнять 80% команд vim, при размере кодовой базы в 1%.
Полная совместимость не планируется, но цель сделать нечто очень похоже. Vim Script, продвинутое управление окнами, GUI реализовываться не будут принципиально. Нормальная подстветка синтаксиса уже сделана. В качестве внутреннего языка используется Lua. Запланирован RPC для внешнего управления (это вместо плагинов).
На данный момент работоспособен в качестве замены vi, но с подсветкой и визуальным режимом.
Проект находится вот здесь: github.com/martanne/vis
Пока у тебя нет монопольного положения на рынке, безусловно можешь, поскольку недовольный твоими действиями клиент уйдет к другому. Как только ты стал монополистом, дело меняется. Монополия опасная вещь: американцы с ней настрадались сильно, поэтому антимонопольное законодательство в целом несправедливо по отношению к монополисту, но зато эффективно избавляет рынок от куда более сложных проблем.
В этом и приемущество: задержки минимальны. При синхронизации у вас происходят тяжелые выборки на обоих концах, а разница реплицируется. Это опять таки приводит к необходимости держать именно sql базу под радиусом (поскольку так удобнее).
Но я так понимаю, что все таки полная синхронизация у вас есть? На случай потери консистетности этого ААА сервиса из-за не дошедших, ошбочных событий, должна быть.
А статистику вы как обратно в ядро загоняете? Например логи радиус сервера, статусы сессий, флоу. Или это отдельный сервис?
Хотя многие по-прежнему делают синхронизацию с ядром по расписанию. И типичный шаг там 5-10 минут.
Шаред хостеры с их безобразным отношением к безопасности и непрофессиональными разработчиками сайтов это второй по объему источник спама. Первый (зомби из клиентских сетей) рубится PBL, а вот на вас управы нет ибо можно с водой ребенка выплеснуть.
Если бы крупные игроки договорились, набрались мужества и поставили p=reject, -all, то это бы дало существенный буст борьбе со спамом. Да, ценой небольших потерь писем, но оно того стоило.
Им уже можно пользоваться как редактором. Что я и делаю последние два дня.
Насколько я понимаю, существенная проблема современного vim, в том, что полностью кодовую базу уже никто не понимает и, как следствие, существенные проблемы (например подсветка синтаксиса) не могут решится уже много лет.
Т.е. грубо говоря цель это проекта редактор и ничего более.
Полная совместимость не планируется, но цель сделать нечто очень похоже. Vim Script, продвинутое управление окнами, GUI реализовываться не будут принципиально. Нормальная подстветка синтаксиса уже сделана. В качестве внутреннего языка используется Lua. Запланирован RPC для внешнего управления (это вместо плагинов).
На данный момент работоспособен в качестве замены vi, но с подсветкой и визуальным режимом.
Проект находится вот здесь: github.com/martanne/vis