Alexandr N
-
Публикации
125 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем Alexandr N
-
-
7 часов назад, taf_321 сказал:
Вот и сравнивайте сравнимое. Когда у каждого оператора на 5-15к абонентов будет по департаменту по уходу за MySQL численностью до 1к, вот тогда и приходите с этим примером.
меня вполне устраивает мой пример и сравнить сравнимое, спасибо
В 22.06.2021 в 13:09, product manager CB5 сказал:Нет, у нас другие планы :)
вчера опять кстати были приключения, этот раз по авторизации VoIP, биллинг неожиданно забыл как их авторизовать откидывая Reject, поддержка чинила-чинила и починила, сказала какие то процедуры в бд
-
В 21.06.2021 в 07:48, taf_321 сказал:
Для начала мыскль там крутится на весьма узких задачах, за ним ухаживает целый департамент и все равно ни одной недели без факапа. А уж после недавнего выпуска с фиксом 40 (!!!!!) CVE смотреть на мыскль как на серьезную платформу это от великого ума. Мария и перкона проблем не решает, а добавляет во весь этот лядский цирк тонкий аромат прогрессирующей фрагментации.
узкая задача fb по сравнению с оператором с 5-15к активных абонентов это как сравнить Солнце и Плутон :) и кстати они там кучи презентаций делали как они "пылающей тропой" перешли на 8.0
-
В 19.06.2021 в 07:32, Kolunchik сказал:
статья рассказывает про MySQL 5.5 дата выхода которой 2010 год
дата релиза Centos 6 на которой работает карбон 2011 год.
ну то есть около 10 лет прошло как бы :)
В 19.06.2021 в 10:11, Andrei сказал:Еще в далеком 2009-м, когда мы "сдавали" надзору биллинг на MySQL, инспектор поморщился, что мол mysql - это несерьезно, но биллинг конечно принял в эксплуатацию, ибо сертификат на него был.
fb.com надо было рассказать который использует MySQL что это не серьезно :)
-
1 час назад, product manager CB5 сказал:
Неприятная ситуация, соглашусь. Но жизнь продолжается и решение проблем находится - в общем, уже нашли, в следующей версии с багфиксами (еженедельная) будет.
ну жизнь продолжается то да, только когда техпод с криками все пропало поднимает среди ночи, ну так себе сценарий. это опять же вопрос к использованию устаревшего ПО, был бы Fb 3 вероятно мы бы об этом и не узнали никогда, а так получается
что выбран за основу продукт такой базы данных который не только такие приколы имеет, но и имеет крайне узкий круг специалистов который умеет с этой бд нормально работать.
-
18 часов назад, product manager CB5 сказал:
Соглашусь, тут нужно предупредить.
Думаю, это лучше обсудить с поддержкой в тикете.
Связки чрутов + init.d + нашей платформы достаточно для администрирования/обслуживания. Соглашусь, что докер может быть удобней, но менять одно на другое просто ради изменения - мне кажется, не лучшее решение. Можно тот же ресурс использовать для решения других задач - модуль новый написать, зарефакторить что-то и тд.
Допускаю, что со временем мы можем поменять платформу, но это перспектива 3-5 лет.
Обсудили из того что сказали и из того что было почитано мною про firebird (в группах) оказывается из-за устаревшего софта (firebird версии 2) на кол-ве транзакций к базе данных равное 2147483648 бд самоумирает и биллинг ломается. для firebird 3 это чисто 281474976710656 (что в 131072 больше). Напоминает логическую бомбу.
-
57 минут назад, product manager CB5 сказал:
Полагаю, восстановили всё в работу и передали проблему на анализ ведущему разработчику. Анализ сложных кейсов действительно может занимать больше пары дней.
Если у Вас при этом всё лежит или постоянно падает - тут нам не жалко и весь Carbon Soft поставить на уши и заставить систему работать как должно. Если же ситуация не столь плачевна, предлагаю дождаться что ответит отдел разработки.
Если бы докер был панацеей для решения проблем резервирования и любых других, возникающих в процессе эксплуатации - мы бы безусловно перешли на него. Факт в том что и он потребует обслуживания и привлечения инженеров.
Так надо же сказать об этом в тикете/звонком или как то еще, а то сижу и жду. Бекапы есть, инструкцию нашел как восстановить, сам сделал, сам молодец.
Вопрос: как так произошло? (Жесткий диск не убился), Вопрос: данные за день потерялись, как бы восстановить?
Я не про докер как систему резервирования, а про то что докер и был придуман для того что бы такие "зоопарки" (когда внутри живет очень много разного софта/языков/баз данных) упорядочивать имея адекватную систему управления, тогда как chroot выполняя те же задачи не имеет ее, точнее почти ничего не имеет :)
-
6 часов назад, product manager CB5 сказал:
Звучит как фатальная проблема. Что наши инженеры говорят?
Да, мы слышали про Docker. Но это не единственное средство контейнеризации. Каких-то весомых аргументов переходить на него с чрутов пока не видно.
Что ответят через пару дней, но прошло пять.
С учетом того что у вас очень много разного софта докер вероятнее всего бы наоборот помог бы содержать основную систему в актуальном состоянии, а контейнеры могли бы частично работать и на более старых версиях.
upd. ответили что займутся
-
55 минут назад, vop сказал:
Докер хорош репозиторием готовых образов. Для своего решения есть еще заметная кучка контейнеризаторов. :)
присунуть эластик, фаирберд, заббикс, кабинет на вордпресе, админку на джанго... я наверное многое не упомню что еще туда засунули. и все это натянуть через chroot на centos 6 (который кстати все).
ну такое да... удовольствие :)
-
биллинг взял себе и сломал базу данных, работал-работал и потом сказал что у вас файл бд кривой :)
отлично!
разрабы кстати раз уж поставили все что только можно было в биллинг из софта, то может они хотя бы слышали что есть docker
-
-
16 часов назад, product manager CB5 сказал:
WordPress достаточно гибкая CMS и используется многими известными сайтами, на рынке просто найти веб-студию работающую с этим движком.
На чём ЛК сделали бы Вы?
Вы сами пишете "CMS", ответ - не на CMS :) С таким походом скоро и на Битриксе можно будет делать.
Смотри в сторону фреймворков, например Yii2
-
про кабинет на WordPress я молчу, а чего уж сразу не на phpBB ?
-
Шел третий день рассмотрения тикета, закономерно в конце рабочего дня CB5 сообщение... "Извините, сегодня мы не смогли решить Вашу задачу, продолжим завтра."
(Представьте что я прикрепил картинку ждуна)
-
8 часов назад, product manager CB5 сказал:
Проанализировав конкретные случаи и реальные данные мы сможем найти решение, поэтому я и уточняю номер тикета.
По тикетной системе. Мы над этим работаем) Пока можете позвонить в поддержку, попросить их закрыть задачу/задачи.
Ну вы сами понимаете что говорите?)
Ситуация из жизни: Звоню, говорю - вопрос в стиле "мне лень прочитать мануал". Отвечают, "хорошо, но пишите тикет" - иду пишу.
Написали тикет, а у вас там что-то еще открыто и что бы побыстрее закрыть, а текущее приподнять ? "Звоните" ! хорошо, иду звоню :)
-
26 минут назад, product manager CB5 сказал:
Добрый день. Давайте попробуем разобраться в ситуации. Скажите, пожалуйста, номер тикета.
а какая разница? ну я вам напишу например - вы кого-то там разово помучаете или поставите мне галочку что "этому дураку отвечать побыстрее".
если указанные вещи происходили разово то было бы пофигу, но это на постоянной основе!
закрытие заявок это вообще просто косяк тикетной системы, ну глупости какие, что бы закрыть заявку со стороны обратившегося нужно ждать что-то.
начните уже менять подход, посмотрите как техподы у конкурентов работают, проверьте какой хвост у ваших тикетов
-
отвратительно, невероятно!
Почему я лютую? Я познакомился с работой поддержки биллинга, за которую идет плата и понимаю поддержка не в состоянии ответить на бытовые вопросы в разумные сроки.
1. Если у вас осталась открытая заявка, и вы создали другую - то она не будет обрабатываться тк есть созданная другая,
хорошо, зайду в старую и нажму "закрыть". Но "закрыть" в понимании поддержки CB5, это отправить обращение на закрытие, которое может рассматриваться... ну хз сколько.
2. Вы создали заявку, но всем на нее по...фигу, робот будет вам писать в заявке в конце рабочего дня поддержки вот что:
"Извините, сегодня мы не смогли решить Вашу задачу, продолжим завтра.".
- это вообще бесит!
Почему бы не вычитать тогда те дни из платы месячной поддержки, если поддержка не была оказана?
-
помогали в срочном вопросе по адресам, все замечательно. хвалю!
Илье отдельное спасибо.
-
https://gist.github.com/avelardi/1338d9d7be0344ab7f4280618930cd0d
закройте пакеты на L7 в которых содержится запрос "GET /current_config/passwd"
-
2970 очень специфичное устройство, сделаное на отдельной платформе/софте от остальных 29хх.
Прошивка свежая?
Сделай обход всего дерева в файл, а потом смотри, че там есть, че нет.
# snmpwalk -v2c -On -Cc -c private 192.168.10.1 .1
мне кажется что в общем дереве не найду, но поищу :)
Alexandr N, обратитесь к нам в support, приложите к обращению вывод `show version` и уточните перечень данных lldp, которые необходимо собирать с этого коммутатора.
обращусь, но тут собственно есть стандартный для всех mib : LLDP-MIB
прошивка то что у вас на data.nag.ru последнее.
-
Подскажите, lldp нормально работает, включен, но по snmp нет такой ветки, может быть есть какая то специфическая или нужно отдельно что-то активировать?
# snmpwalk -v2c -On -Cc -c private 192.168.10.1 .1.0.8802.1.1.2.1.4 .1.0.8802.1.1.2.1.4 = No Such Object available on this agent at this OID
-
-Cc Do not check whether the returned OIDs are increasing. Some agents (LaserJets are an example) return OIDs out of order, but can complete the walk anyway. Other agents return OIDs that are out of order and can cause snmpwalk to loop indefinitely. By default, snmpwalk tries to detect this behavior and warns you when it hits an agent acting illegally. Use -Cc to turn off this behaviour.
Спасибо, такой вариант вполне работает
-
Подскажите как можно снять таблицу соответствия mac -> port.
Не может walk считать next oid.
# snmpwalk -v2c -On -c test 192.168.100.2 .1.3.6.1.2.1.17.7.1.2.2.1.2 .1.3.6.1.2.1.17.7.1.2.2.1.2.1.0.12.66.198.228.88 = INTEGER: 1 .1.3.6.1.2.1.17.7.1.2.2.1.2.1.0.12.66.198.228.54 = INTEGER: 1 Error: OID not increasing: .1.3.6.1.2.1.17.7.1.2.2.1.2.1.0.12.66.198.228.88 >= .1.3.6.1.2.1.17.7.1.2.2.1.2.1.0.12.66.198.228.54
-
Переход проплачен сообществом PG, негоже специалистам PG в стороне стоять
-
info@netorn.ru
Carbon billing 5, обсуждение
в Программное обеспечение, биллинг и *unix системы
Опубликовано · Жалоба на ответ
Из моего опыта работы с Carbon Billing и работы с другими биллингами, если у моих друзей появится желание - я буду отговаривать всех. Моими словами будет: Этот биллинг ДНОО!!
1. Раз в год умирает база данных так как транзакции к сожалению лимитизированы на Firebird 2 - ответ? исправим через 3-5 лет. Раз в год итого совет техподдержки - восстановитесь из бекапа.
2. Идея разделения на микросервисы загнала в тупик всю разработку которая основана на chroot, когда люди давно делают API и раскидывают по докерам (это удобно даже с точки зрения обновления). Я уж помолчу про зоопарк в клетках, какого там только софта не живет.
3. Базовые функции могут произвольно умереть, причины могут быть исправлены только в рабочее время или покупайте иной SLA, и это не шутка, код никто не копает, сервер не ломает, места хватает - а сервисы какие то просто умирают.
При условии коробочного продукта мне почему то кажется оно должно работать, а уж если есть ошибка разрабов и косяк то оно должно быть исправлено оперативно невзирая на SLA - мы платим не за опыты над нами, а за работающий продукт
Я уже промолчу что Centos вообще прекратил свое существование как ОС - а мы еще на Centos 6, зато стабильно скажут мне. Было стабильно и в 7-й и в 8-й ветке где еще репозитории не доумерли.
Я понимаю что на мой пост, а уж простите накипело, ответит product manager CB5, свой же продукт принято защищать.
Но мы как вынужденные пользователи продукта, оставляем информацию чтобы в сознании овнеров продукта что-то поменялось, что есть проблемы, но когда техпод отвечает на вопрос о базовом функционале что "ждите завтра", тем временем сервис должен лежать, как мне не закипеть?
(и еще раз замечу что я не прошу поддержки, я не прошу доработок, мне нужно что бы то что заявлено - работало).
ps. когда заявку делать на сайте:
Fatal error: Cannot use string offset as an array in /var/www/portal/HelpDesk/TicketDetail.php on line 64