людей с дырявой памятью. Потому что таких людей у них нет. А под конец песни под гитару попели. Варианты были, разумеется, разные, но в целом песни оказались общими. Разве что в Лехином варианте в них обычно оказывалось на несколько куплетов больше.
Первое, что я увидел, проснувшись на следующее утро, была моя родная книжная полка. Ни Лехи, ни каких-либо следов его пребывания в доме не было. Только на кухонном столе лежала записка, на первый взгляд написанная моим почерком. Но лишь на первый, ибо выглядела она так:
И жизнь пошла по-прежнему. Время от времени некоторые книжки у меня куда-то деваются, а потом находятся. Так было всегда, но мне кажется, что теперь это происходит чаще, чем прежде. Не знаю, впрочем, может быть, только так кажется...
Новости. С 15 по 15
Обучение
Учебный центр «Сетевая Академия ЛАНИТ» (www.academy.ru) совместно с факультетом «Информационной безопасности» Московского инженерно-физического института (МИФИ) при поддержке компаний «КриптоПро» и «Актив» разработал учебный курс для руководителей подразделений, ИТ- специалистов и системных администраторов.
Он посвящен внедрению и развертыванию инфраструктуры открытых ключей (PKI) на уровне организации, ориентирован на специалистов, которые не сталкивались с этой задачей ранее.
В программу курса входят вопросы от правовых аспектов, связанных с использованием электронно- цифровой подписи (ЭЦП) в России, до изучения основ криптографических алгоритмов, хэш-функций, сертификатов стандарта Х.509, технологий аутентификации.
Особое внимание в программе уделяется электронному идентификатору Rutoken. Рассматриваются назначение, технические характеристики, архитектура и современные технологии двухфакторной аутентификации.
Слушатели, помимо освоения теоретического материала, представленного преподавателями кафедры № 42 («Криптология и дискретная математика» МИФИ), будут выполнять практические и лабораторные работы, из которых они узнают о роли криптопровайдеров и удостоверяющих центров на примере «КриптоПро CSP» и «КриптоПро УЦ».
«1С: Предприятие»
«1С: Предприятие 8»: многопользовательские конфигурации
Никита Зайцев
Любая информационная система, созданная на базе технологической платформы «1С: Предприятие 8», ориентирована на параллельную работу нескольких пользователей. Количество пользователей, одновременно работающих с информационной системой, зависит от масштаба предприятия и функциональных возможностей конфигурации и на крупных предприятиях может достигать нескольких сотен. Поддержка информационных баз, в которых работает большое число пользователей, требует от специалистов умения распознавать, выявлять и решать специфические проблемы многопользовательской среды.
В рамках статьи будут рассмотрены технологические аспекты многопользовательских информационных систем, влияющие на стабильность и производительность их работы, а также будет дан обзор инструментальных средств и методик, позволяющих диагностировать и оптимизировать узкие места конфигураций «1С: Предприятие 8» в реально работающих системах.
При подготовке статьи использовались материалы базы знаний «Технологические вопросы крупных внедрений» фирмы «1С» (http://kb.1c.ru).
Самое узкое место любой многопользовательской системы – конкурентная борьба пользователей за ресурсы. Что имеется в виду? Проще всего показать это на каноническом примере: складской учет с контролем остатков. На складе хранятся какие-то предметы, например мобильные телефоны, или садовые грабли, или что-то другое – неважно. Бизнес-процесс включает в себя ровно две операции – «положить предмет на склад» и «забрать предмет со склада». Понятно, что материальный мир накладывает на бизнес- процесс ограничение: забрать можно не больше чем сейчас есть в наличии. И когда грузчик, явившийся за очередным предметом, обнаружит пустую складскую ячейку, ничего страшного не произойдет (если не считать потерянного покупателя и упущенную прибыль, но нас сейчас интересуют только технологические аспекты процесса). Материальный мир поддерживает свою целостность автоматически, но совсем другая картина наблюдается в информационной системе. Там хранятся не физические предметы, а всего лишь информация о них – вполне реальная коробка с мобильным телефоном представлена в информационной базе безликим набором единиц и нулей. Что будет, когда цифровой грузчик (транзакция) явится за несуществующим предметом? Если разработчик информационной системы не предусмотрел контрольных механизмов, в базе данных образуется черная дыра – отрицательный остаток в соответствующем учетном регистре. А поскольку информационная система представляет собой совокупность взаимосвязанных процессов, сбой одного из них непременно воздействует на другие, «–13 комплектов садовых грабель» попадут в подсистему планирования закупок, внесут свою лепту в расчет себестоимости и т. д.
Чтобы не допустить возникновения черных дыр, разработчик информационной системы использует блокировки – набор данных, прочитанный транзакцией, должен гарантированно оставаться неизменным до завершения транзакции. Пока разные транзакции работают с разными наборами данных (один менеджер списывает со склада телефоны, а другой грабли, или два менеджера списывают телефоны разных моделей) – все отлично, никто никому не мешает. Но как только две транзакции претендуют на один набор данных, им приходится конкурировать, т. е. вставать в очередь. Конкурентная борьба транзакций за ресурсы при одновременной работе большого числа пользователей может породить «длинную очередь», ожидание на блокировке. На практике это означает либо замедление запрошенной конкретным пользователем операции (например, операции проведения документа), либо отказ от выполнения операции (время ожидания превысило предельно допустимое). В особо запущенных случаях возникают взаимные блокировки – транзакция А ждет, пока транзакция Б завершится и отпустит заблокированную ею запись, а транзакция Б ждет того же самого от транзакции А. В этом случае СУБД, прождав положенное время, сбросит одну из транзакций – одному из конфликтующих пользователей повезет больше (его операция будет выполнена), а вот второй пользователь получит отказ.
В приведенном примере с торговым складом конкурентная борьба за ресурсы была обусловлена бизнес- процессом предприятия, т. е. объективной необходимостью. Но в реальной жизни, к сожалению, встречаются и яркие примеры внесения в информационную систему избыточных блокировок – их порождает сон разума, а именно «некомпетентность специалистов по внедрению». Например, на предприятии внедрена типовая конфигурация, абсолютно неважно, какая именно. В процессе эксплуатации возникает новое бизнес-требование – руководство хочет собирать и отслеживать некоторые статистические показатели, в том числе «общее количество операций проведения документов». Техническая реализация выполняется «на коленке» и выглядит следующим образом:
Процедура ОбработкаПроведения(Отказ,
РежимПроведения)
Счетчик = Константы. КоличествоДокументов.
Получить();
Константы. КоличествоДокументов.
Установить(Счетчик + 1);
// далее – штатная бизнес-логика
// проведения документа
