Несколько вопросов админам

Им надо чтобы работало и они были готовы за это платить. Если я не могу решать их проблемы то зачем я им нужен? Как правило, когда ко мне обращаются люди они уже попытали счастья с другими сисадминами которые «не шмогли»

Еще год назад я тоже пытался так сделать, реально хотел помогать, входить в ситуацию. Но однажды моему терпению пришел конец. Дело было так. Закончили мы перевод системы в одном банке на x64 платформу. Полная копия прода, но стрелки еще не поменяли. И конечно это надо было протестировать, нагрузочное тестирование, функциональное. Вооружился я обезьянами из отдела тестирования, дал им jmeter и в бой. Написал кучу кейсов, около 30-50, что мы тестируем, как, обьем запросов, периодичность. Потом написал отчет на страниц 20, прогнозы. В общем, сделал конфетку. Довольный такой пошел к архитектору и отдал (они любили бамажки). Через минут 30 звонит архитектор со словами, «Ты чо о@#ел!?!?». В моих расчетах, на типовых задачах, кластер, до 70% загрузки нод, может пропустить через себя 14 запросов в секунду. Архитектор прямым текстом сказал что я нетрадиционной ориентации и пошел переделывать, мол в ТЗ шла речь о 10к пользователях. НУ ладно, пошел, выбил неделю. Сидел ночью и днем, выкурив кучу манов по оптимизации этой херни, добился 25 запросов в секунду, довольный и горд собой опять пошел к архитектору. И ситуация повторяется. Я начинаю психовать, подрывать других админов, другое начальство и все в ответ - ничо не знаю. Я начал анализировать текущий прод и выяснил час пики, так в них, на максимальной нагрузке было 1.3 запроса в секунду. Я опять с этими данными к архитектору, мол сейчас 1.3 а я сделал 25, а он опять что гомик. Надоело мне это дело, взял дорисвал пару нулей в результаты, уменьшил среднее время в откликах. И чудо! Мой доклад так понравился, даже премию дали нам за платформу.

И почему-то после этого весь мой энтузиазм пропал. Я не перестал делать хорошо, просто перестал проявлять инициативу.

А после этого была еще олимпиада по отказоустойчивости платформы, с физическим выдергиванием кабелей. Мы с напарником просидели пьяные и опять нарисовали результаты. Ибо все знали что проблемы есть, решить их на данном этапе невозможно без расширения бюджета и ошибок, сука, в изначальном проектировании.

Как-то так. А сколько раз мои попытки что-то улучшить и оптимизировать скатывались в то, что на меня кидали еще и обслуживать это. ТАк что не, я уже не помню как в не энтерпрайзе, но в нем радимом инициатива это дело плохое.

И как-то очень хорошо прокачался скил спихивания ответственности, написание документаций, обьяснений и скил защиты своей задницы. Твои проблемы может понять архитектор, другой админ, но не руководитель департамента, ему обьяснения до фигу, а вот официальный тикет в саппорт - аргумент и факт. Вот почему рулит RHEL, AIX, Oracle. Всегда вину можно спихнуть на них. Некрасиво, но иногда только так.

Ужас. В плане людей мне везло, я работал только с небольшими фирмами и индивидуальными предпринимателями, с ними такой бардак редко встречается.

Так что энтерпрайзу не легко живется, но со временем привыкаешь. Зато скил траблшутинга сразу раскачивается, когда гугл тебе помочь не может, документация тоже а саппорт по третьему кругу просит логи слать.

А то тут, на лоре, кажись, тех кто работает с Оракл, айбием и прочим, готовы на костре жечь :)

До боли знакомая фигня. Повезло с заказчиком, у меня с такого контракта нули в цене срезались бы пропорционально снижению показателей на тестовой инсталляции.

один я такой тут хамоватый

Причём здесь хамоватость? Если от системы требуется определенная надежность - извольте за это платить(деньгами на саппорт, временем на настройку и отладку и т.д.). Если денег нет и сделать надо вчера - жрите что дают.

Слушай, расскажи чего он не умеет?

Из потребного ежедневно...

Оно не умеет разные настройки на разные дестинейшены в callfork. Я хочу, допустим, с одним оператором работать без RTP-проксирования, чтобы клиент напрямую лил голос на оператора, а с другими - с проксированием, чтобы всё замыкалось на Яту (ну там фаерволы где-то рубят трафик с не того IP и т.п.). Ята так не может, только АОНы подставлять в форках и прочее. Ята не может нарезать линии даже по диалпирам, не говоря уж о том, чтоб нарезать вообще по любому критерию как в астериске, типа на мобильные 10 линий, а на Москву 50 линий. Можно только на диалпир нарезать, и то через процедуру в MySQL исключительно, но это даже не удаление гланд через анальное отверстие, это гнойная педерастия и изврат имхо. Ята не может в нормальное ДВО, даже на уровне «проиграть wav-файлик и перевести звонок на такой-то номер». Через callfork, что было бы логично, так нельзя, звонок умрёт на проигрывании вавки. Через API и скрипты теоретически можно, если бы разработчики рассказали как этим API вообще пользоваться - документация присутствует в лучшем случае в виде комментариев к конфигам, и то половину вещей надо узнавать в чате с разработчиками, ибо они тупо не написаны в каментах, а «по умолчанию» оно работает совершенно неочевидным образом, например пишет в CDR по желанию левой пятки то АОН до всех подстановок, то АОН уже на выходе, т.е. весь биллинг идёт покурить.

У нас параллельно яте стоит астериск, который легко и непринуждённо делает всё вышеописанное без этого садомазо, но зато в яте можно в случае фрода скриптом вплюнуть в начало regexroute что-нибудь типа «^810.*$=-;error=forbidden», а в астериске это невозможно.

Так это не тестовая, это миграция текущего прода была на новый, только с разрядностью другой. Годовой проект с 30-40 серверами в кластере. Текущий прод на пиках потреблял всего 1.3 запроса в секунду, это была его максимальная нагрузка. Мы же довели до 25, более чем в 12 раз повысилась его емкость. Так что работой все ок, просто цифры сначала рисовать нужно было правильные. Я когда смотрел такое же тестирование старого прода, видел там вообще нереальные значения. Когда я начал архитектору показывать эти значения и критиковать их, обозвав прошлого кто делал отчет дибилом, архитектор вообще перестал со мной говорить. Как оказалось этот отчет делал он :)

Ну и что, все что не текущий прод - тест. Ха, «Только» ! Поставь xp64 и огребешь размеры этого «только», даже в лине это не всегда _только_ пересобранные теже самые бинарники, всегда хз что может всплыть.
А представь как он за свою жопу трясется. :)

Особых проблем из-за смены архитектуры не было. Все что было написано, работало. Были проблемы с интеграциями, установкой, зависимостями, да. Но, в целом, терпимо.

Там заказчик вообще сам себя подставил. Кому-то пришла в голову идея заменить все системы (iscard, b2 и тому подобные) на одну огромную платформу. Выбор пал на вебсферу, то ли откаты, то ли брошюрки на главного так повлияли, хз. Но сказано - сделано.

Взяли все от IBM, сервера, шины, портал, процес, есб, веб сервер, даже дб2 и тиволи сраный. Ну и начали клепать. Пару сервисов переписали, начали новую систему выводить в прод, заменяя старые.

Делать было нереально сложно, даже наши официальные интеграторы IBM'а приезжали смотреть а чо такое кластерная вебсфера и как она выглядит.

Я там таки доработал до момента конца миграции, оставалось толкьо бизнес процесы перенести, но это очень долги процес. И свалил нафик. Теперь я ненавижу вебсферу.

P.S И желаю всем ее разрботчикам индусам гореть в аду.

Ынтырпрайз с большой буквы как он есть. :( Жесть, но всегда есть куда хуже - я видел людей, которые берут огромную кучу ненужного малосовместимого железа и ibm, чтобы на нем оракл крутить. А потом наступает ORA-600. Но щеки это всем вендорам надувать не мешает.

железа и ibm чтобы на нем оракл крутить. А потом наступает ORA-600

На сколько я помню 600 - херовая ошибка, вроде internal error. Но у нас oracle и aix замечательно дружат. Хотя может я не так понял.

про линии и анонс ты меня некисло удивил О_о

Но вот про астер не вполне понял - что мешает дать допустим busy на нужные in/out-маршруты (если вебморда) или просто поставить кастомный контекст проверки, который уже потом исполняет default, from-trunk или куда кто пихает вход?

поставить кастомный контекст проверки, который уже потом исполняет default, from-trunk или куда кто пихает вход?

У нас как на яте, у каждого диалпира свой отдельный inbound. Как потом после сливания в один контекст для проверки каждый диалпир обратно раскидать каждый в свою табличку, я не догоняю. На asterisk.org сказали, глобальный prerouting а-ля ята в астере без модификации исходников нереализуем.

5 раз прочел твой пост, пытался догнать что куда зачем. Ты имеешь ввиду биллинг? Обычные входы можно раскидать как общий вход-контекст по номеру, с него макрос проверки с параметрами А и Б-номерами (можно вообще извратиться и вызывать линуксовый скрипт для проверки по какой-нибудь табличке-csv если там разрешения хитро стоят), с него переход в общий контекст.

Если конечно биллинг идет - там да, сложнее, хотя фокус со скриптом все равно в игре. От попыток пробить можно использовать те же fail2ban и опять же скрипт с табличкой-счетчиком (но нужен будет timestamp последнего вызова), которая тоже участвует в проверке.

Или ты имеешь ввиду какой-то другой глобальный прероут? Просто с трудом представляю себе ситуацию, из которой нельзя выкрутиться макросом и вызовом скрипта с мускулом.

upd.:

Как потом после сливания в один контекст для проверки

зачем в один? макрос с параметрами, потом выходим обратно

upd2: хотя конечно соглашусь, что если идет вход с открытой внешки - астер не лучший фильтр. Слишком тормоз, лучше ser/sips

Смотри - у нас каждый диалпир из sip.conf направлен на свой отдельный контекст, там линии нарезаются, что ему вообще открыто и т.д.. Можно было бы сделать блокировку 810 для всех, направив всех в один контекст. Но - всё равно нужны разные правила для разных диалпиров. Как их после этого контекста обратно разделить? По АОНу - не вариант, у меня ещё куча операторов которые могут звонить с каких угодно.

Про биллинг это другое, просто ята по умолчанию пишет в CDR то исходный АОН, то после всех подстановок, т.е. половина звонков считается не так. Это обходится колдунством в regexroute, но всё равно такое поведение софта по умолчанию это маразм.

зачем их вообще пускать в один контекст блокировки? допустим у тебя есть таблица в csv/мускуле/где угодно, в которой грубо есть поля кому можно и куда можно. у каждого свой контекст, просто из этого контекста вызывается шелл-скрипт, который проверяет пир по таблице и возвращает 1 или 0 (типа разрешить-запретить). Потом продолжаем выполнение их контекстов на основании ответа. Мы не сводим их в один, если есть общие инструкции - вызываем макрос, после которого они опять продолжают свои контексты.

Просто ты же как-то разделяешь пиры. Если по АОНу нельзя - ну, переменных дофига, можно делить по контексту или каналу. Или вообще на основании нескольких переменных (например АОН+контекст+кодек+еще чего) делать свою переменную-идентификатор.

Хоть примерно в какую сторону будем смотреть?

На интегратора.

Админ не должен забивать себе голову чужими проблемами. Если считаешь что админ должен сам разбираться во всем - ну окай чо.

Дык к сожалению все верно. Тогда вопрос неясен. Впрочем это толксы же :)

Алсо, какой у вас трафик (линии) и какая загрузка CPU на яте?

Хз, ща даже глянуть не могу нормально. Я поставил ее как sip-h323 proxy примерно за неделю до первого коммента (потому и заинтересовался), а сейчас в отпуске. Звонков на этом направлении совсем ничего (транк между колл-центром и мелким филиалом, звонков 100 в день от силы). Стоит рядом с астером на двухпроцессорном ксеоне Е5000 (точную модель не помню) с 32 гигами мозгов. За все время пиковая загрузка проца 6% не превышала даже на левой фигне вроде сжатия бэкапа ;) звонки в сумме - 1-2%.

но думаю как всех на это перетащим с других станций, то будет около 8-12% загрузки и 150-180 одновременных вызовов на пике (понедельник, утро или вечер). Хотя можт и больше. Через яту пойдет в пике звонков 20-30, не больше (сейчас там всего 32 линии, пока не забивались)