Как сломать работу 1С, будучи пользователем

Безумие

Ранее в нескольких хардкорных публикациях мы говорили о работе с журналом регистрации нестандартными способами:

• Работа с журналом регистрации. Выходим за границы платформы

• Экспорт журнала регистрации. Набор инструментов (приложения + исходный код)

Настало время поговорить о чем-нибудь простом, приземленном. Поговорим о теме, актуальной для всех. Как разработчикам и администраторам, так и простым пользователям. О том, как случайными (или не всегда случайными) действиями можно уронить информационную систему на платформе 1С. Причем это могут сделать почти все, кто работает с ней, не только божественные администраторы и разработчики.

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

Итак, поехали!

Полный рандом

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

Трэш и угар

Практически все случаи, которые будут описаны далее, не являются проблемами самой платформы 1С, а лишь являются результатом непродуманной разработки конфигураций, решений на ее основе, ошибками внедрения, сделанными настройками и так далее. Но давайте уже к делу :)

Мой личный номер

Теплым летним днем на линию поддержки прилетает ошибка при записи заказа клиента.

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

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

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

Выводы:

• Сломать нумерацию в документах 1С просто, если разрешено ручное изменение номера. А в большинстве случаев это именно так.
• Аналогичные проблемы распространяются на все объектные сущности: документы, справочники и т.д.
• Необходимо серьезно подходить к вопросу ручного изменения номеров и кодов объектов, даже если таких проблем у Вас еще не возникало.
• Будьте бдительны, возможно такая бомба уже есть в Вашей системе. Ведь она есть во многих типовых и отраслевых решениях.

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

Следующий!

Отфильтруй мне это

Представьте, с теми же заказами клиентов работает менеджер, у которого свои собственные задачи. Например, руководство поставило ему задачу найти все заказы со статусом "Ожидается согласование", у которых сумма заказа в диапазоне от 10 тыс. руб. до 50 тыс. рублей или более 500 тысяч. Не важно почему такие условия, просто нужно и все тут. При этом попросили исключить нескольких клиентов из этого списка. Исполнительный менеджер идет в список заказов, далее "Еще -> Настроить список". Тут задает условия точно так, как нужно.

Если количество заказов не большое, то все будет хорошо и система обработает такой запрос. Но если их сотни тысяч, миллионы? Ну, Вы понимаете о чем я? ;-)

Подобный отбор в списке еще не самый изощренный с которым можно столкнуться. В результате применения подобных отборов на большой базе могут появиться серьезные тормоза не только в работе сеанса этого пользователя, но и всей информационной базы. Ситуация может усложниться еще и тем, что они могут быть установлены несколькими сотрудниками. Что на это скажет Ваш сервер баз данных? Правильно, ему может быть очень нехорошо и всеобщие "тормоза" в системе в таких случаях не редкость.

Еще интересный момент - это автоматическое сохранение пользовательских настроек в динамических списках. По умолчанию в новых версиях платформы эта опция включена. В конфигураторе она указывается в свойствах динамического списка.

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

В обычных ситуациях сотрудник, который столкнулся с таким поведением, старается таких отборов больше не ставит и даже не пишет в службу ИТ для исправления ситуации (у них и так много проблем :)). В других же случаях функционал используют далее не смотря на медленную работу, тем создавая другие проблемы производительности.

Выводы:

• Динамические списки с произвольными отборами - это тоже медленные бомбы как и нумерация.
• Чем больше возможностей, тем больше ответственность. Но пользователи программы не догадываются о ней.
• Простой вариант решения - отключить возможность гибких отборов через "Настроить список" и через Ctrl+F. Добавить ограниченный набор отборов на форму для основных вариантов поиска. Но это нужно постараться сделать, потребуются доработки конфигурации.
• Сложный вариант - полностью изменить логику поиска в списках. Можно использовать стандартный полнотекстовый поиск или реализовать свой внешний сервис. Но это другая история.

Динамические списки периодически могут становиться причиной падений и замедления работы. По опыту именно запросы в списках чаще всего попадают в ТОП по нагрузке сервера СУБД, даже обгоняя тяжёлые отчеты. Да, именно так. Ведь отчет запускают один раз, а динамический список используют постоянно. А если вспомнить отборы "По вхождению строки", то...

Отчет на все времена

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

Решение простое - в динамический список добавить нужные колонки через "Изменить форму", поставить нужные фильтры через "Еще -> Настроить список" и выгрузить весь сформированный список в Excel, предварительно нажав Ctrl+A. Profit!

Добавляем поля от ссылки через "Еще -> Изменить форму" от ссылки (если такое доступно, конечно).

Далее нажимаем Ctrl+A (выделяя все записи) и выгружаем все что подготовили.

Что может пойти не так? Да очень многое:

1. При выделении записей в списке платформа выполнит огромное количество служебных запросов, особенно если записей в базе очень много.
2. Если установлены "тяжелые" отборы как в предыдущем примере, то это может создать значительную нагрузку на сервер баз данных.
3. Выгрузка списка в Excel может значительно увеличить размер сеансовых данных на сервере 1С. Вплоть до использования всего свободного пространства на диске.
4. Подобная выгрузка может выполняться очень долго. В том числе и не завершиться никогда.

Выводы:

1. Это еще одна пасхалка от динамических списков.
2. Встретить подобное использование списков можно во многих компаниях. Многие разработчики даже не подозревают, что вытворяют их коллеги от бизнеса.
3. Решить проблему можно либо запретом гибких настроек списков и отборов, либо реализацией выгрузки данных специализированными отчетами со строго ограниченными настройками.

Как умеем, так и выгружаем :)

Мой справочник, мой!

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

Например, вот сформированная печатная форма заказа клиента.

Тут выяснилось, что "ЗАО "Торговый дом Комплексный" - не то что нужно для заказа клиента. Но у пользователя были закрыты права на редактирование содержимого печатной формы, а вот, о чудо, изменять справочник "Организации" было разрешено. Ответ очевиден! Нужно изменить наименование организации.

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

Все было бы хорошо, но:

1. Это же многопользовательская система. Все кто формировал печатные формы после этой манипуляции тоже получат это название. Всех ли оно устроит? Будет ли кто-то опять переименовывать справочник?
2. Даже если исходное наименование вернут обратно, ошибок и вопросов в системе за короткий промежуток времени может накопиться порядочно.
3. Также могу сломаться большое число "костылей", если Вы их практикуете в работе. Речь идет о поиске по наименованию, синхронизации организаций в конвертации по наименованию и прочее.
4. Риск нарушения работы будет присутствовать постоянно. А если пользователи будут менять не наименование, а ИНН, КПП, платежные реквизиты?

В общем, права доступа вещь серьезная.

Вывод: проверьте, нет ли таких "пасхалок" в Вашей системе. Только грамотная настройка прав доступа сможет от такого защитить.

Нужно больше сеансов

Еще одним особенным случаем является множественный запуск сеансов 1С одним пользователем. Причин может быть несколько:

1. Есть тяжелые операции, которые проще запускать сразу в нескольких сеансах, чтобы ускорить работу с программой:
   1. Тяжелые отчеты, которые не выполняются в фоновом режиме.
   2. Проведение некоторых документов занимает очень много времени.
   3. Поиск в динамических списках не отличается быстрым откликом. Почему бы тоже не запустить несколько сеансов.
2. Просто удобно в нескольких окнах открывать разные отчеты или другие формы, чтобы визуально сравнивать.
3. Операция какая-нибудь подвисает, а запущу ка я еще несколько сеансов, чтобы наверняка в одном из них все хорошо заработало.

К чему это может привести:

• Дополнительная нагрузка на сервер 1С и СУБД, если тяжелый отчет запускается многократно в разных сеансах. Даже если отчет выполнится, и пользователь его просто не дождался, то все равно излишняя нагрузка будет присутствовать.
• Бесконтрольное выполнение тяжелых алгоритмов в информационной базе.
• Излишнее использование лицензий при определенной конфигурации сервера и настроек лицензирования.
• Ошибки прикладного решения, которые может никогда бы и не всплыли в обычной работе. Все ли в порядке с установкой блокировок при параллельной работе сеансов / пользователей?

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

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

А как обстоят дела у Вас?

Перепровести все!

Еще немного про динамический список. Может случиться так, что пользователь через Ctrl+A выделит большое количество документов и нажмет "Провести" (или отмена проведения, или пометка на удаление - не важно). Что в этом случае будет? Правильно - на сервере начнется настоящее "веселье", ведь эта операция явно не самая легкая по использованию ресурсов. А если были выделены все документы за месяц?

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

Какое может быть решение по запрету таких действий? Тут тоже все зависит от контекста, свою систему Вы знаете лучше. Но можно предложить:

1. Запрет проведения документов предыдущих дней в зависимости от прав доступа.
2. Сделать мониторинг массовых операций пользователями. В случае появления любой большой операции отправлять уведомление администратору.
3. Организационные решения вопроса :)

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

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

Я скачал с Инфостарта!

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

Повезет, если права доступа все же остановят работу неизвестного инструмента. Но всегда ли такое будет? А сгенерированные ошибки в данных могут "всплыть" только спустя пару месяцев... 

Тут можно сразу и закончить.

Вывод: закрывайте доступ на открытие внешних отчетов и обработок из файлов. Альтернативы просто нет.

Я у мамы программист

Еще один хардкорный случай - это когда с правами доступа совсем беда, а главный бухгалтер - бывший программист или консультант. Даже если с правами все ОК, то для такого высокопоставленного сотрудника они могут быть полные. Что может пойти не так? Правильно! Сотрудник для решения своих проблем зайдет в конфигуратор и запрограммирует все что ему нужно. Или выгонит всех пользователей по середине рабочего дня и начнет формировать выгрузку DT'шника, чтобы с ней работать отдельно. Что Вы говорите, база 1 ТБ? Ну на выходных запущу...

Какое здесь решение? Даже говорить об этом не хочется :)

Вне закона

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

Решается это построением продуманных прав доступа всем пользователям системы. Добавить тут нечего. 

Вы в безопасности

Конечно, часть информации выше имеет шуточный характер. Но в шутке есть только доля шутки. Часть случаев, но в некотором измененном виде, встречал на практике. Иногда хотелось смеяться, иногда плакать.

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

Другие ссылки

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

Авторские разработки

• Транслятор запросов 1С в SQL - инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.

• Просмотр и анализ структуры базы данных (отчет на СКД) - отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.

• Просмотр и анализ журнала регистрации (отчет на СКД) - отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации.

• История работы пользователей (отчет на СКД) - отчет для просмотра истории работы пользователей (СКД, просмотр для любого пользователя).

• Экспорт журнала регистрации. Набор инструментов (приложения + исходный код) - набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux. Готовые приложения и исходный код.

• Технические проверки данных регистров бухгалтерии (отчет на СКД) - отчет для технических проверок данных бухгалтерских регистров.

• Путеводитель по истории релизов - отчет по истории выпуска релизов продуктов фирмы "1С" и анализа информации по обновлениям.