Комментарии / Профиль netangels

21.07.2017 06:50:54

Fri, 21 Jul 2017 06:50:54 GMT

Мы надеемся, что статья позволит сэкономить время тем, кто только разрабатывает подобные системы.

Мы не установили готовое решение, а создали его своими силами. Почему бы и не рассказать об этом?

19.07.2017 08:53:04

Wed, 19 Jul 2017 08:53:04 GMT

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

19.07.2017 08:50:42

Wed, 19 Jul 2017 08:50:42 GMT

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

К слову, не только МТС таким хвастается. Ещё банки и даже некоторые государственные учреждения.

18.07.2017 14:07:12

Tue, 18 Jul 2017 14:07:12 GMT

Да даже не один. Есть точно один красненький и один какой-то цветастый. Они умеют.

18.07.2017 11:28:15

Tue, 18 Jul 2017 11:28:15 GMT

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

18.07.2017 11:27:12

Tue, 18 Jul 2017 11:27:12 GMT

Ой, это точно не про нас. Мы таким не балуемся.

18.07.2017 10:50:51

Tue, 18 Jul 2017 10:50:51 GMT

Это, примерно, из серии «Чем я вам могу помочь?»)

Обязательным условием пользования нашими услугами, так как мы подчиняемся отечественному законодательству, является заполнение паспортных данных [эта норма у нас будет действовать ещё месяц-два до релиза нового сайта и новой регистрации]. Часто, если клиент физлицо, имя в анкете и есть имя звонящего.

Но юморины с «мойповелитель» встречаются оооочень редко и отрабатываются в ручном режиме. Пусть это будет исключением)

18.07.2017 10:47:25

Tue, 18 Jul 2017 10:47:25 GMT

Чем они вам не угодили?(

13.04.2017 16:15:27

Thu, 13 Apr 2017 16:15:27 GMT

Согласны с Вами, тоже рабочий вариант.

Однако, на наш взгляд, при таком варианте могут возникнуть потенциальные сложности с настройками персистентности в будущем. Например, в самом простом случае не получится отправлять каждый отдельный IP на один и тот же конечный сервер с приложением. Т.е., в зависимости от работы DNS, запрос может уходить на разные конечные сервера, проходя через разные балансеры. Если при этом конечные сервера ничего друг про друга не знают, могут появиться ошибки с сессиями и т.п.

В предлагаемом нами решении можно включить настройки персистентности на уровне LVS и на уровне Nginx, что в итоге позволит закрепить каждый отдельный IP за конкретным конечным сервером.

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

13.04.2017 16:13:19

Thu, 13 Apr 2017 16:13:19 GMT

Нагрузка там минимальная. В пиковые моменты, когда запускаются всякие "ночные" скрипты по крону, бывает около 150-200 запросов в секунду.

13.04.2017 11:51:44

Thu, 13 Apr 2017 11:51:44 GMT

Немного непонятно из вашего комментария, о чём конкретно вы говорите. Давайте вы уточните и мы продолжим беседовать? А проблемы могут возникнуть и не только из-за VRRP.

13.04.2017 11:46:42

Thu, 13 Apr 2017 11:46:42 GMT

Спасибо, будем иметь их ввиду.

Если говорить про наш внутренний DNS, то основное, что нам был нужно — это чтобы DNS продолжал работать, если один их backend серверов упадет или мы сами его выключим. Нам оказалось достаточно возможностей Nginx.

13.04.2017 11:00:26

Thu, 13 Apr 2017 11:00:26 GMT

Пока мы не встречали никаких проблем именно с работой протокола VRRP и его реализацией в Keepalived.

Были некоторые нарекания именно к работе Keepalived. Не всегда корректно отрабатывал механизм reload (версия 1.2.2, в wheezy). Приходилось именно перезагружать, со всеми вытекающими.

А с сетевым оборудованием проблем не было. Тот сегмент сети, где обитает VRRP трафик, состоит из обычных коммутаторов (L2). Плюс мы помещаем трафик разных VRRP групп в разные vlan'ы.

Будем признательны, если Вы сможете поделиться с нами опытом касательно возможных проблем.

18.10.2016 08:12:34

Tue, 18 Oct 2016 08:12:34 GMT

Можем подискутировать о преимуществах и недостатках бесплатных сертификатов.

10.10.2016 22:37:02

Mon, 10 Oct 2016 22:37:02 GMT

Мы уже готовим новый сайт. Структуру и наполнение переиначим и будет все читабельно и удобно.
Нельзя не согласиться, что на сайте много лишнего на самых видных местах и нет нужного там, где это действительно нужно.
Может, ещё что будет из замечаний? Свежий взгляд для нас очень важен.

10.10.2016 21:38:20

Mon, 10 Oct 2016 21:38:20 GMT

Это ценообразование. Мы часто сталкиваемся с вопросом о том, что и сколько стоит.
Кому нужно готовое решение, тот в панели просто жмёт «Создать VDS». Кто интересуется экономикой, тому всегда можно сходить в маны.

10.10.2016 20:23:56

Mon, 10 Oct 2016 20:23:56 GMT

«Tiny» в окне с ползунками ~295р
https://habrastorage.org/files/65f/442/f73/65f442f734274e0c9d761a0cae2c870b.PNG

«Tiny» в списке конфигураций ~130р
https://habrastorage.org/files/523/59c/36d/52359c36d1344a1c831f86ce7a8ed7e5.PNG

В последнем случае цена — это стоимость «голой» машины без диска и без IP.
То есть, в вашем случае

Стоимость машины с тарифом «TINY»: 1х129.60 рублей
+
SSD диск 5Gb: 5х18.72 рублей
+
выделенный IP-адрес: 1х72 рубля
=
Итого: 295.20 рублей

10.10.2016 19:56:31

Mon, 10 Oct 2016 19:56:31 GMT

Можем допустить, что вы сначала посмотрели тарифы виртуального хостинга , а затем тарифы облачных VDS.
Это две разных услуги и стоят они по-разному.

10.10.2016 19:08:42

Mon, 10 Oct 2016 19:08:42 GMT

Опция включается из панели.
Для пользования вам необходимо создать виртуальную машину, подключить диск и в разделе управления ВМ и дёрнуть переключить в соответствующем разделе в положение «ВКЛ»

06.04.2013 06:03:57

Sat, 06 Apr 2013 06:03:57 GMT

Почему хостеры не предлагают подобное ПО у себя на shared-хостингах остается загадкой.

Вы какими-то не теми хостерами пользуетесь. Нормальные хостеры предлагают git/svn/mercurial из коробки в составе базового набора ПО.