Для всех, кто не очень любит читать, сразу предложу вместо большого количества букв посмотреть видеоролик, наглядно демонстрирующий, каким образом мы принудительно завершаем активные сеансы пользователей и временно блокируем соединение с информационными базами при применении «1С:Предприятия» 8.1 и 8.2.
Это еще одно интересное решение, которое применяется нашим коллективом на практике с 2007 года. Оно может быть интересно всем, кто применяет «1С:Предприятие» 8.х на динамично развиваемых высоконагруженных информационных базах (когда обновления работающих баз проводятся почти каждый день или по нескольку раз в день, когда количество пользователей исчисляется десятками, сотнями или тысячами).
Речь об управлении запретом на соединение пользователей с информационной базой и принудительном завершении активных сеансов пользователей.
Конечно, всё это можно делать с помощью стандартных средств 1С:Предприятия 8.х (например, консоли управления серверами 1С) или механизмов, имеющихся в некоторых типовых конфигурациях. Однако удобство применения повсеместно доступных средств, всё же, ограничено, затраты времени на управление блокировкой соединений можно сократить, а администраторы и разработчики при использовании стандартных механизмов вполне могут позволить себе не вполне корректно информировать пользователей о причинах и времени недоступности информационной базы. И позволю высказать своё мнение, что всё это вполне исправимо?
Итак, иногда разработчикам или администраторам необходимо обеспечить монопольный доступ к информационной базе. Например, при обновлении базы в случае изменения структур хранения или для резервного копирования в ночное время средствами конфигуратора «1С:Предприятия», а не сервера баз данных (размеры копии всё же очень значимо отличаются при применении этих подходов).
Для запрета установки новых соединений пользователями и начала завершения активных сеансов мы применяем вот такую форму:
Вызвать её — это один клик мышки, заблокировать информационную базу — еще один (по большой красной кнопке «Заблокировать»).
После установки блокировки форма немного меняется и выглядит вот так:
Как видно, разрешить пользователям работать — это тоже один клик мышкой. В каком состоянии сейчас информационная база на форме видно, как разблокировать — тоже вроде понятно. Сделать что-то некорректное не то чтобы трудно, скорее невозможно.
Для простейших ситуаций установки/снятия запрета на использование информационной базы удобство администратора мы обеспечили. А как же пользователи? Ведь сотни людей в этот момент могут работать с информационной базой. Они просто увидят сообщение о разрыве соединения? Нет. Все сеансы будут завершены максимально корректно и так, чтобы все пользователи понимали, что, почему и как быстро от них требуется.
За 10 минут до времени, с которого нам необходимо обеспечить монопольный доступ к информационной базе, все пользователи получат первое уведомление:
Еще через 3 минуты те пользователи, что продолжают работать, получат второе уведомление:
Еще через 3 минуты те, кто не понимает, что такое завершить текущий сеанс или не смотрит на экран монитора, получат третье, последнее предупреждение:
Ну а через минуту, как и написано в уведомлении, сеанс будет корректно автоматически завершен клиентом «1С:Предприятия» (именно клиентом, а не будет разрорван в одностороннем порядке со стороны сервера).
Смысла дублировать в описании логику трех этапов предупреждения нет. Все сообщения на окошках сформулированы так, чтобы любой сотрудник вне зависимости от образования, квалификации, времени года или настроения понимал, что от него требуется и что надо сделать.
Таким образом, полный цикл завершения активных сеансов составляет не более 10-ти минут (конечно, это время настраивается, и в экстренных ситуациях может быть сокращено вплоть до 2-х минут за счет сокращения времени отображения всех уведомлений и установки времени начала действия запрета).
На время, пока установка соединения с базой запрещена, при попытке запустить программу (установить соединение с информационной базой) пользователи увидят вот такое сообщение:
Оно очень похоже на стандартное окно уведомления о запрете установки соединения с информационной базой. Но в нем дополнительно выводится пояснение, что использование системы недоступно временно и по причине проведения регламентных работ.
Часто ли администраторы удосуживаются писать подобные пояснения, запрещая подсоединение к информационной базе? Нет. Если это делать на десятках баз по несколько раз в день, то их вполне можно понять. А ведь уместным в разных ситуациях может быть разный текст уведомления, что стоит обсудить отдельно.
Пару слов про время недоступности, которое можно задать на форме в полях «с» и «по».
По умолчанию в поле «с» указывается время на Х минут больше от текущего времени, где Х — время, которое требуется для корректного поэтапного информирования пользователей и завершения сеансов. 15, 10, 7, 4 минут. Мы чаще всего используем 10-ти минутный интервал завершения сеансов.
При необходимости в этом поле можно задать любое другое время, с которого будет действовать запрет. Например, днем можно установить запрет на 23:00, т.е. на время, когда будет проводиться резервное копирование.
Но и заполнение времени ожидаемого завершения обслуживания (в поле «по») также является важным. При использовании стандартных средств администраторы редко удосуживаются его заполнять, т.к. пользы от этого не много. Угадать точное время завершения сложно, всё равно обычно уместно по завершению обслуживания не затягивая снять запрет использования информационной базы.
Но указание окончания времени недоступности крайне полезно. Почему? Потому что не корректно, информируя пользователей о том, что информационная база будет недоступна, не сообщать, с какого времени они смогут продолжить работать. Ведь указать ожидаемое время завершения регламентных работ не сложно, а подсистема в этом случае сможет информировать пользователей в другом, расширенном виде.
Благодаря заполненному времени, до которого планируется обслуживание информационной базы, мы имеем возможность более детально проинформировать пользователей о своих планах. На примерах уведомлений ниже видно, как изменятся некоторые уведомления и сообщения, основные изменения выделены.
Но и это еще не всё. Часто мы проводим шаблонные операции. Типовое обновление в обед, которое обычно занимает 10 минут. Или резервное копирование, которое займет около часа. Даже указание ожидаемого времени завершения обслуживания можно избежать. Для самых отъявленных лентяев мы применяем шаблоны:
Т.е., если, например, нам нужно быстренько обновить информационную базу, что займет не более 5-ти минут, достаточно вызвать окно шаблонов и нажать на кнопке «ВКЛ» напротив первого шаблона. Картинки обычно помогают нашим администраторам осознать суть предлагаемых шаблонов без слов 😉
Когда мы брались за разработку этих механизмов, я выставлял 2 главных требования:
- человечность и простота восприятия, ориентация на применение без необходимости глубоких познаний или интеллектуальных способностей (всё должно быть просто и удобно, как применять должно быть понятно и без инструкции);
- ориентация на минимизацию трудозатрат админов в сочетании с требованием корректного информирования при ограничении доступа пользователей к базам (промышленные объемы требуют отработки там, где при разовом применении можно было бы проделать на пару лишних действий).
Как думаете, получилось ли сделать то, что хотелось?
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Интересно, но где же сами файлы обработок???
Ничего себе недавнего )))
Возник вопрос — как отключаются сеансы пользователей? — то что у Вас написано, что они отключаются клиентом, а не сервером приводит к тому что не выбрасываются зависшие сеансы либо сеансы в которых выполняется какое либо продолжительное действие.
Если вы все делали через обработчик ожидания, то в ситуации когда пользователь запустит какую то обработку (например, перепроведение документов, которое будет выполняться Х часов) он отключен не будет!
(1) Alex1Cnic,
Всё это не только обработками реализуется. Это еще и обработчики ожидания на клиенте. Для интеграции с базами требуется сведение баз. Точнее будет сказать — подсистема, для интеграции с другими конфигурациями. Она актуальна только в случае, если конфигурация снята с поддержки.
(2) Agapov_Stas,
Хороший вопрос, видно что в теме )
Сеансы завершаются последовательно в два этапа: первый — со стороны клиента обработчиком ожидания, второй — через com-соединение с сервером. Второй начинает выкидывать соединения по завершению указанного времени, т.е. когда все, кто мог, уже вышли. Именно вторая часть рубит зависшие сеансы.
(2) Agapov_Stas,
Я писал о недавнем выходе ядра 8.3, а эта штуковенция уже 100 лет у нас применяется )
(3) так к чему статья то не пойму?
Без файлов и без кода она ничего не дает — просто показать какие вы классные?) и как вы рубите пользователей ?)
Не увидел новаций. Использованы стандартные механизмы, только доработаны для «одного нажатия мышкой». Исходя из заголовка публикации «вместо стандартных механизмов» ожидал увидеть нечто новое. Расстроился 🙂
(7) gubanoff,
Я постарался показать не альтернативный код, а альтернативный интерфейс управления запретом использования, потому этот материал в статьях, а не обработках ))
Моё мнение было выше — на крупных базах иногда мельчайшая тонкая доработка может сэкономить уйму времени и нервов. Вот это пример одной из таких доработок, которая для нас оказалась крайне полезной.
(6) Agapov_Stas,
Даже без файлов виден вариант организации достаточно удобного интерфейса управления и показана корректная схема информирования пользователей. Уверен, что и это может многим быть интересным 😉
(1) Alex1Cnic, поддерживаю.
(5)
1) у вас при установке блокировки все ли пользователи будут «выброшены» из базы? Просто со стандартной обработкой такое случается. Всё время ожидания прошло, основная часть пользователей вышли, а пару пользователей осталось, хотя время ожидания парой превышает 10-15 минут.
2) С информационными сообщениями конечно не удивили — в стандартных обработках можно добиться такого же и даже проще.
3) Но ради удобства вы молодец все же! Плюс.
(10) bashirov.rs,
По вопросу, все ли будут выброшены. Да, за очень редким исключением, все. Там, где пользователи отказались выйти — клиент закроется по таймеру. Если по каким-либо причинам клиент не закроется (модальные окна, диалоги, зависшие сеансы, …) — сеансы разрываются через com-объекты сервера 1С. Исключение — это мертво висячие сеансы, которые вылазят 1-2 раза в год, и которые не снимаются даже через консоль управления серверами. Для таких помогает только перезапуск сервера 1С, тут никакой код не спасает.
Я мог что-то упустить по стандартным обработкам. А есть такие, где можно настроить поэтапное предварительное информирование пользователей о необходимости завершения сеанса, чтобы успел сохранить все изменения? Буду благодарен за подсказку, где можно поглядеть, будет интересно сравнить реализацию.
За «+» спасибо )
(11) стандартная обработка называется «Блокировка соединений с информационной базой» это в Бухгалтерии КОРП, в УТ и УПП вроде тоже так же называется. Поэтапное информирование есть, но более подробного, как у вас, конечно нет. Там возможно просто написать сообщение при завершении работы пользователей и никаких доработок не требуется. Подробно я сейчас не опишу конечно, только в вкратце:
1. Просит выйти (несколько раз предупреждает в определенном интервале времени);
2. Окончательное предупреждение с закрытием сеанса (с возможностью сохраниться);
3. При попытке войти в базу говорит что база заблокирована;
Автоматически снимается блокировка при истечении времени, которое вы установили (возможно снять самостоятельно).
Одним словом это тот же стандартный механизм который вы используете как я предполагаю.
(12) bashirov.rs,
Да, понял о каком речь. Он еще в ряде конфигураций, я в УПП прошлых поколений видел раньше. У нас администраторы крайне ленились при таком варианте закрытия на обслуживание впечатывать корректные уведомления пользователей, как и ленились прогнозировать время завершения обслуживания. Но уж точно эта обработка лучше, чем через окно консоли управления серверами закрывать. Точнее там не только обработка. Она также тесно связана с рядом обработчиков, тикающих по таймеру на клиентах.
Без демонстрационной конфигурации с реализацией упомянутых механизмов вся статья — пустое «бла-бла-бла», полезный эффект от которого стремится к нулю.
меня больше вот это порадовало) явно что то не то в консерватории.
(15) Babuin,
А что смущает?
Одна из идей данной статьи – минимизировать влияние человеческого фактора на корректную работоспособность программного комплекса. При стандартных механизмах есть все риски как не до конца понятно описать сообщение, так и в принципе не предупредить о том, что мы «выбрасываем» пользователя из системы. Это если говорить только со стороны пользователя.
Теперь если со стороны администратора… Основная то суть оптимизации либо-какой системы не только в том, чтобы была отработана видимая часть для пользователя. Качество реализации так раз кроется «за ширмой». А как же драгоценное время на поддержку? Порой мы тратим слишком много времени на вещи, которые повторяем ежедневно. А что, если можно оптимизировать и эту часть? Ведь сэкономленные 5 минут на лишний вход в Конфигуратор, описание сообщения для пользователя при закрытии базы ежедневно (а может быть и несколько раз на день!) смогут накопить часы свободного времени! Ну а куда потратить это время — всегда найдется;) Даже продлить время на выполнение более интересных задач и повысить производительность в связи с переключением с задачи на задачу — уже позитив.
Так что как не крути – автору 5!
(14) IgorS,
Порой толковая идея — это нечто большее, чем просто кусок кода. Как минимум — логику данного механизма можно применять не только при блокировке соединений… Здесь описаны вещи более глобального характера;) Если бы еще суметь применить такой подход при подготовке к свиданию=) Ведь по сути — повторяю те же самые действия! А вот нажать бы кнопку — и все готово! Не нужно огромный алгоритм держать в голове!)
А с другой стороны — по себе сужу… Человек — ленивое существо) Если получаю готовый работающий механизм — я до конца не вникаю в концепцию реализации, а иногда и совсем не задумываюсь о глубине проработки! А ведь можно так многие полезные идеи упустить;)
Тот же принцип и тот же функционал был реализован в данной обработке , которая была сделана уже очень давно (2011 год). Не понимаю, что нового/необычного в данной обработке.
(17), спасибо за внятный комментарий )
(18), по реализации столько отличий, что можно предложить найти 12 отличий 😉
а как обстоят дела с уведомлением пользователя если 1С свернута? или включилась заставка?
(20) — выводятся модальные окна в окне 1С. Т.е. на свернутой 1С помигает несколько раз приложение 1С, но само не развернется. Если пользователь не заметил и не закрыл сам, после 3-го уведомления приложение будет закрыто.
Автор как теоретическая статья ну просто на 5+. Как практически ничего нет, а картинками сыт не будеш. Выложите пожалуйста теперь практическую часть. Зарание спасибо
Вот и я не сдержался чтобы не высказать свое недовольство — а почему без куска кода. Да я читал что идея важна, но идейных много, это не эксклюзивная реализация, это субъективное мнение.
(16) по несколько раз в день прерывать работу сотен и тысяч пользователей.
И резервное копирование в таких базах точно нужно делать не так.
(24), это от ситуации зависит. Например, мы обслуживаем 3 активно используемых программных комплекса, где количество пользователей находится как-раз между сотнями и тысячами. Но специфика их такова, что ночью с ними не работают. При размере баз около 200Гб, резервное копирование средствами SQL, конечно, возможно, но не позволяет хранить длительную историю копий, что иногда полезно. Резервные копии средствами 1C при этом в зависимости от конфигурации составляют от 2 до 10Гб. Обновление на этих комплексах проводится 1 или 2 раза в день. В 22:00 и, в экстренных ситуациях, в 12:00 (обеденное время работников предприятия). Вот в таком случае всё сказанное верно )
Конечно, если речь о круглосуточно используемых высоконагруженных комплексах, то обслуживание проводится не так. Но доработки и обновления всё равно нужны. Пусть и в середине ночи, но если есть шанс, что кто-то работает — надо пользователей попросить выйти корректно.
(17)
В корне неверное убеждение. Есть мнение, что любая самая гениальная идея, ничто без реализации, в то время как реализация в любом случае несет в себе и саму идею и код в том числе, если он нужен для реализации. Картинки в статье для 99% прочитавших ее так и останутся картинками. А значит статья как таковая не имеет смысла, ну кроме как похвастаться.
(26), как думаете, почему software-архитекторы оплачиваются в разы больше, чем кодеры? Сколько людей сможет сделать программу по ТЗ, а сколько может спроектировать программу так, чтобы на ее разработку ушло минимум времени, она решала все поставленные задачи и всем устраивала заказчика? Это я к тому, что к фразе «В корне неверное утверждение» корректнее было бы добавить «По моему мнению, …».
Вместо того чтобы ругаться со всеми и мерится заработком, выдавая философские тезисы, лучше бы выложили .cf или четко отказали людям.
(28) vslimv, не стоит так перекручивать сказанное. И ругани не было, и заработками никто не мерялся. Но девушка выше написала умную мысль, поэтому я и попросил критикуя быть корректными.
По cf. Это публикация в разделе статей. Когда появится возможность запостить конфигурацию — она появится в другом разделе.
Примерно то-же самое на упр формах:
Жаль, что 1с-не понимает важности данного направления и не стремиться реализовать это в платформе.
(19) ах, ну да. Тут все увидели Ваш код и смогли сравнить его с другими вариантами. А судя по возможностям, то почти ничем не отличается от Вашей. Мы же сравниваем функционал и идеологию подхода? Тогда отличий меньше чем 12.
(25) когда обслуживаются такие комплексы как правило существуют такие понятия как SLA, время доступности систем, управление изменениями, релизами.т.д. Организовываается различные процессы и регламенты их регулирующие. Когда есть работающий процесс как правило достаточно работы консоли сервера и суперперделки по выгону пользователю нах не нужны.
Бэкап таких комплексов опять же только SQL. У sql есть замечательная фича сжатия бэкапа,если уж нужно организовать архив с большой глубиной хранения.
Итого такая фича по выгону пользователей нужна в небольших конторах, базах. Когда нет смысла организовывать процессы, обновлять конфу хоть ежечасно.
Настоящий такой велосипед, блестящий и яркий, с лампочками и звоночками, почти как штатный одинесовский..
только зачем в одной базе 2 велосипеда — не понимаю
(33) Babuin, В бекапе средствами SQL есть одно бо-о-ольшое отличие от бекапа, сделанного средствами 1С. Понять его можно изучив в профайлере размер наиболее крупных таблиц базы данных. Это таблицы остатков и оборотов регистров накопления, расчета, бухгалтерии. При качественной отработке производительности эти таблицы в сотни и тысячи раз превосходят по размеру таблицы самих регистров. Угадайте, попадают ли таблицы остатков и оборотов в бекап средствами SQL? Попадают. А в бекап средствами 1C не попадают. Благодаря этому в ряде случаев, например, как на наших базах, размер бекапа средствами 1С составляет примерно 2Гб, а средствами SQL — 200Гб. Всего 100-кратная разница. Разве она не стоит того, чтобы использовать доступный функционал, если специфика работы организации или предприятия позволяет на час ночью закрыть базу?
(35)
Т.е если вы из этого dt файла загрузите базу, у вас этих таблиц не будет?)
200 ГБ бэкап сиквельный это уже со сжатием? т.е у вас база порядка 500 ГБ? и dt такой базы получается 2ГБ? что то где то несходится.
Самая главная причина почему не стоит делать DT для хранения информации, это то что есть вероятность невозможности загрузить этот dt.
Ну если уж на то пошло и dt нужны позарез, можно организовать промежуточную базу в которую средствами SQL загружать бэкап и оттуда уже выгружать dt не выгоняя пользователей.
(36) Babuin, да, базы около 500Гб. Размер dt от 2 до 8Гб в зависимости от метода хранения истории изменений.
А таблицы остатков не попадают в dt-файлы, так как в этом нет необходимости. При поднятии базы остатки рассчитываются, а не загружаются.
С проблемами поднятия базы из dt файлов за 10 лет применения 1С на предприятии проблем не наблюдалось ни разу, а делается это ежедневно.
И дабы не впадать в пустую полемику, очень прошу обратить внимание, что для оговоренного варианта конкретно указаны условия, когда он полезен. В нашем случае такая схема обслуживания наиболее удачная, так как ночью базы не испльзуются, экономия дискового пространства значима и размер sql-копий не позволяет их записывать на ленточные носители. Если для Вас эти преимущества не значимы или нет возможности на час в сутки ограничивать работу с базой — конечно остается делать монстрокопии силами сервера баз данных. Но я точно знаю, что как минимум для ряда организаций описанная схема оказалась очень удобной.
Самая главная причина почему не стоит пить водку, это то что есть вероятность стать алкоголиком. 🙂