Sigur vs Parsec vs PERCo & etc.

[ALEX_SE]

Я основную фирму в которой 2.5тыс и так же под 3 десятка приемов/увольнений/переходов в неделю синхронизировал с HR. Так что с продлением и прочей ерундой проблем нет.
Сейчас отпуска еще синхронизирую что бы открывались/закрывались.

[ALEX_SE]

а какой идиот придумал ставить сроки концом года вот этого я действительно не понимаю. И каждый год с вечера 31 или с начала 1-2 числа одно и то же.. срочно понадобились сотрудники у всех сроки покончались... Я лично такие заявки тепеь игнорю.

[ALEX_SE]

на сигуре нашел серьезную дыру в безопасности в части контроля доступа... надеюсь исправят.

[AlexR108]

на сигуре нашел серьезную дыру в безопасности в части контроля доступа...

Какую?

[AlexR108]

Почитал еще эту ветку. Я являюсь разработчиком Sigur.

> я серьезно рассматриваю вариант слезть с сигура в сторону парсека... если найду куда сбагрить 12 контроллеров

Да ладно, это не может быть серьезно.

Но, если вдруг - можем мы сами принять контроллеры назад.
Если у них сохранен товарный вид, то за полную стоимость. Иначе - за стоимость ремонта.

А что по-существу вам не нравится?

Я нашел тут только это:

1) "бекап раз в сутки". Да, встроенные средства резервирования делают backup только раз в сутки.

2) "нашел серьезную дыру в безопасности" - какую?

3) "что-то по цене сфинкса с функционалом апполло" - а что конкретно вы хотели бы по функционалу, что есть в Аполло, но нет в Сфинкс/Sigur?

---

По другим вопросам в ветке:

1) В некотором виде обход периметра есть, можем показать
2) Разблокировка по пожару есть. Отдельный аппаратный опторазвязанный вход или через интеграцию с Болид/Рубеж (последний вариант не рекомендуется т.к. создает зависимость работы на сеть)
3) "софт адекватный? заявки на пропуск есть/возможны?" - заявки есть, софт можем показать удаленно примерно за час.
4) "база на 40+гиг работает?" - нужно пояснить как такое возможно, но все равно "да", т.к. столько могут создать только какие-то редко нужные графические данные, типа кадров с камер, фотографий посетителей или сканов их паспортов или согласий на обработку ПД. Таких данных может быть сколько угодно, на работу это никаким заметным способом не влияет.
Более реальный вопрос же это как работает система когда много сотрудников и событий. 40 Гб так не наберешь, например 100К людей и 20 млн событий это меньше 3 Гб. Если у вас есть малейшие сомнения по скорости формирования отчетов или т.п., то можем вам сгенерировать базу какую хотите и попробуете.

[ALEX_SE]

Если для человека активирован оператор то при настроенной синхронизации в случае пропадания этого человека из внешней БД он в СКУД как был так и остается со всеми своими правами.
И в документации в разделе про синхронизацию ничего про это не написано.

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

Правда в ТП сказали что вроде исправят...
Типа это сделано на случай если не останется ни одного оператора - а администратор куда денется?

[AlexR108]

Установите обновление ПО отсюда - http://sigursys.com/download_current.php" onclick="window.open(this.href);return false;
и операторы будут удаляться

> Теперь кучу народу проверить надо.
не надо

> Типа это сделано на случай если не останется ни одного оператора - а администратор куда денется?
"администратор" ничем не примечателен, вы можете сделать себе другого в т.ч. в результате синхронизации, а оригинальному отключить права оператора, после же удалить его.

Вы менять-то Sigur будете на что-нибудь?
Давайте меняйте уже. Я давно хочу найти хоть одного клиента, кто бы заменил Sigur на что-нибудь. Пока не нашел при сотнях примеров обратных переходов и почти 10 тысячах внедрений. Лично приеду к вам выслушать что вам не понравилось в продукте.
Расскажите заодно как на Apollo у вас работает синхронизация кадров по внешней БД, техподдержка и пр.

[ALEX_SE]

Быстро обновились, благодарю! В четверг только пожаловался.

Могу сделать только зачем.

Лошадей на переправе не меняют. Пока не буду - не самоцель. Пока развиваемся - добавляем точек прохода. Парсек то же далеко не идеал. Чисто из-за СУБД. И скорости обновления данных но это давно решили в экспериментальной прошивки. Ну и пожелания я уже писал на почту. Что-то потихоньку делается что-то нет.

А вот сделать сохраняемые выборки и возможность более одного условия в выборке (частично второе есть но не сильно удобно) было бы не плохо. С доп. параметрами не шибко удобно.
У меня нет аполло, у знакомых есть. ТП работает если деньги есть ))

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

[AlexR108]

Меня пугает как это все звучит для стороннего слушателя, некоторые пояснения:

Чисто из-за СУБД

По СУБД мы отвечаем перед пользователями каким-то целевыми показателями. Такими как время формирования отчета, скорость отображения данных на экране при проходе и т.п. И с этим у нас нет абсолютно никаких проблем.
Также целевой функционал, за который мы отвечаем, это возможность брать кадровые данные из практически любой пользовательской СУБД (Oracle, MSSQL и др.), помещать туда события проходов и др.
При этом, чтобы гарантировать что-то относительно работы этих целевых вещей, нам желательно, чтобы никто не лез в то, как мы обращаемся с данными внутри себя. Поэтому, в частности мы сделали дороже наш софт для тех, кто хочет чтобы мы для внутреннего хранения использовали какие-то его собственные СУБД, которые он сам администрирует. Для нас такая ситуация является в общем случае более опасной и нежелательной.

скорости обновления данных но это давно решили в экспериментальной прошивки

Как я понимаю это про запись в контроллеры.
На сегодняшний день без всяких экспериментальных прошивок запись новых карт в контроллеры Sigur происходит быстро и полностью автоматически, передаются только изменившиеся данные, гарантируется сохранение целостности автономной базы контроллера в процессе, гарантируется автономное моментальное принятие им всех решений в т.ч. в процессе синхронизации баз, транзакционный переход со старых правил на новые и пр. Т.е. как-то еще лучше вряд ли можно сделать.
Да и когда этого не было, можно было включить одновременную запись в IP контроллеры, база 7000 ключей в 200 контроллеров писалась за 15 секунд. Сейчас же про этот вопрос запись баз можно вообще забыть. Наш идеальный пользователь не знает что такое база вообще.

[ALEX_SE]

1. Вопрос был не в том что обязательно лезть в БД (я так понимаю разговор про запись в БД, ибо доступ в БД на чтение из одной системы в другую является абсолютно нормальным на мой взгляд и распространенным явлением). Вопрос был в отказоустойчивости. Имея готовый кластер на нормальном железе, имея нормальный настроенный софт бакапа что позволяет ресторить хоть на час хоть на секунду, имея людей которые все это знают мне кажется как минимум не логично не воспользоваться такими возможностями. А единство форматов БД позволяет еще и простой доступ к данным сразу из разных систем и на мой взгляд это совершенно нормально. У меня еще не было случая когда хотелось бы на постоянной основе лезть на запись в БД напрямую. За исключением каких-то отдельных моментов когда надо было чохом поменять данные (ну например прописать идентификаторы внешней БД). Но такие моменты что куда писать я согласовывал с ТП. А вот взять данные бывает нужно частенько. Но вопрос основной опять же это наличие нормальной инфраструктуры хранения данных и бакапа на нормальном серверном железе.
2. Можно было правда не без глюков. Но сейчас с записью проблем нет. наоборот не хватает работающей кнопки "перечитать данные" что бы принудительно залить данные о режимах и сотрудниках. Когда это надо - ну например при вышеописанном сбое или когда глобально меняешь режимы (доступ всех через ТД был в одном режиме а сделал в другом и в настройках у одного режима убрал ТД а другого поставил). В этом случае контроллеры не сразу узнают об изменениях и 5-10 минут точка доступа отсеивает сотрудников с ошибкой запрета использования ТД или ошибкой повторного прохода.

[AlexR108]

Никакой задержки в 5-10 минут нет. Если вы поменяли что-то, что сказывается на доступ людей, то контроллеры об этом узнают примерно моментально.
Можете оставить ваш контакт, который я передам нашей техподдержке, чтобы они поняли что у вас происходит?

[ALEX_SE]

Контакты есть у них. chop.shield@gmail.com.
Сейчас ждут повторения ситуации с блокировкой проходов по причине "Повторный проход" тогда как контроль повторных проходов вообще был отключен. 6 контроллеров. 6 точек доступа. 2 одинаковых режима только с разными настройками времени (режим на первую ТД действует круглосуточно режим на остальне по расписанию). Первая точка доступа пускала всех. Остальные - чуть ли не через одного не пускали с ошибкой повторного прохода. Связь с сервером и контроллерами была.
При этом проблема не решалась ни перезапуском сервера ни принудительным включением и отключением повторного прохода не даже принудительной очистке, сохранении и внось прописыванию сотрудников в режим. А решилась она когда я а настройки первого режима (который работает для первой ТД) добавил остальные 5 ТД. Чуть позже убрал обратно. То есть остальные контроллеры потеряли местоположение сотрудников и забыли что контроль повторных проходов выключен.