Уважаемый подписчик!

Данное соглашение подписчика (далее – «Соглашение») является официальным

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

Подписчиками являются определенные ранее в соответствии с договоренностями лица, которым

предоставляется доступ к электронной версии журнала. 

Ваше соглашение с ООО «Синдикат 13» вступает в силу после того, как вы получаете доступ к
информации, содержащейся в новом номере журнала «Системный Администратор»,
предварительно приняв условия Соглашения.

Информация предоставляется в электронном формате PDF, предназначается для использования на

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

Настоящим Соглашением запрещается продавать, переуступать, давать в пользование,

экспортировать или любым другим способом передавать права пользования материалами,
представленными на страницах журнала «Системный Администратор».

Любые текстовые материалы и графические элементы, использованные в новом номере журнала,

являются авторскими, все права на них принадлежат ООО «Синдикат 13». Запрещается любое
использование таких текстовых материалов и графических элементов на любых ресурсах, за
исключением прямой рекламы, специально одобренной ООО «Синдикат 13».

Все материалы в журнале или его электронной версии в формате PDF, передаваемые подписчикам
с помощью электронных почтовых систем, являются авторскими и охраняются Законом.

Все права на авторские материалы, созданные Редакцией журнала «Системный Администратор»,

принадлежат ООО «Синдикат 13». Права на остальные материалы, принадлежат их
правообладателям.

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

Любая информация, доставленная подписчику путем использования электронных сообщений,

предназначена только для персонального использования.

Любое профессиональное использование информации из журнала, в том числе копирование,

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

Редакция журнала «Системный Администратор»

 Вакансия: администратор Linux

№3(136)
март 2014

ZEN Load Balancer

Построение отказоустойчивых сервисов

Настраиваем работу SCCM с WSUS

Управляем обновлениями

Ускоряем запуск 1С
В помощь разработчику

Ruby и многозадачность
Потоки и процессы

Мобильная торговля
Автоматизация работы

10 формул
для эффективного сисадмина

Проектирование Тестирование Изучаем 1С

Концепции моделирования CamStudio в руках тестировщика РАУЗ в 1С – друг или враг?

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

От Москвы до самых
до окраин. И даже дальше
Конкурс «СА» – ПрофИТ, 2013» завершен, итоги
подведены. Мы сделали это! Нам удалось привлечь
в свои ряды ИТ-специалистов со всей России, а также
из‑за рубежа. Ближнего и дальнего

Нам очень хотелось, чтобы наш конкурс помог выявить мо-
лодых, перспективных и талантливых ИТ-специалистов, при-
влечь к ним внимание работодателей и открыть перед ребя-
тами новые возможности в карьере и образовании.
Потому и придуман был такой девиз: «Есть призвание?
Будет признание!»
Мы объявили об открытии «СА» – ПрофИТ, 2013» 2 сен-
тября 2013 года. Завершение конкурса планировалось в де-
кабре, но по просьбам участников мы продлили его еще
на месяц, до 13 января 2014 года.
Когда мы подводили итоги, то были приятно удивлены
масштабами географии территорий, где читают «Систем-
ный администратор». Наши читатели и участники конкурса
живут не только в самых разных городах и селах России,
но и в странах зарубежья, как близкого, так и далекого. Бело-
руссия, Украина, Киргизия, Казахстан, Таджикистан, Латвия,
Испания, Америка, Израиль, Норвегия – вот далеко не полный
перечень государств, где живут и работают наши читатели.
Над заданиями трудились и будущие ИТ-специалисты,
и специалисты состоявшиеся, и студенты, и люди уже не-
молодые, и, что интересно, немало представительниц пре-
красного пола.
Неожиданно, но заслуженно первый приз получила Еле-
на Мезенцева – инженер-программист из города Асбест
(Свердловская область). Мы лишний раз убедились в том,
что представление о том, что айтишник – мужская профес-
сия, не вполне верное.
Огромное спасибо нашим экспертам и членам жюри. Они
создали всю «подводную» часть айсберга – придумали и на-
писали задания, а потом перелопатили все ответы.
Сердечно благодарим наших партнеров. Компании
«ИнфоТекс», SuperJob, «Лаборатория Касперского»,
PentestIT , РАЭК поверили в нас и поддержали наш кон-
курс. Мы надеемся на продолжение сотрудничества и на то,
что к победителям нашего конкурса уважаемые компании
проявят профессиональный интерес.
И самые добрые слова – нашим конкурсантам. Пусть
далеко не каждый из вас смог одолеть мудреные зада-
ния, но вы старались, и вам было интересно, значит, в ИТ-
профессии вы – не случайно. А мастерство и опыт – дело
наживное.
Мы окончательно убедились в том, что конкурсы для ИТ-
специалистов нужны и важны.
И мы обязательно будем проводить их еще не раз.

Наши призеры фикат компании «ИнфоТекс» на обучение по курсу «Администрирование системы

Главным призером конкурса «СА» – ПрофИТ, 2013» стала Елена Мезенцева
из города Асбест Свердловской области. Члены нашего жюри отметили, что Еле-
на не только прекрасно разбирается в ИТ, но и внимательно читает «Системный
администратор», что помогло ей ответить на вопросы специальной викторины.
Елена Мезенцева получает недельный туристический тур в Прагу (Чехия), по-
дарочный сертификат компании «ИнфоТекс» на дистанционный курс «Защита
персональных данных и другой конфиденциальной информации с использованием
шифровальных средств», электронную подписку на журнал «Системный админи-
стратор» на 2014 год и креативные часы «Управляй своим временем» от компании
SuperJob.
Второй приз получил Теймур Хеирхабаров из города Красноярск. Ему вруча-
ются смешанная годовая подписка на журнал «Системный администратор», фир-
менная футболка от «Системного администратора» и настольные игры «Локалка»
и «Аутсорсер», подарочный сертификат компании «ИнфоТекс» на дистанционный
курс «Пользователь системы защиты информации ViPNet» и часы «Управляй своим
временем» от компании SuperJob.
Другие призеры конкурса получают электронную подписку на журнал
«Системный администратор» на 2014 год, а также креативные часы «Управ-
ляй своим временем» от компании SuperJob. И это далеко не все.
Артур Еналиев (Москва) и Евгений Веселов (Ярославская область) смогут
повысить свою и без того высокую квалификацию, использовав подарочный серти-
защиты информации ViPNet».
Дмитрий Мясников (Пермь), Анатолий Иванов (Чебоксары) и Сергей Бабу-
рин (Челябинск) получают подарочный сертификат компании «ИнфоТекс» на дис-
танционный курс «Защита персональных данных и другой конфиденциальной ин-
формации с использованием шифровальных средств».
Михаил Калинин (Москва) и Александра Александрова (Ярославль) награж-
даются подарочным сертификатом компании «ИнфоТекс» на дистанционный курс
«Администрирование системы защиты информации ViPNet».
Виктор Алюшин (Москва), Артем Гаркуша (Таганрог) и Омар Ганиев (Мо-
сква) награждаются подарочным диском компании «ИнфоТекс» с продуктами
ViPNet Safe Disk, ViPNet PersonalFarewall, ViPNet Password Generator.
Cпециальным призом от компании «Лаборатория Касперского» – про-
граммным обеспечением Kaspersky Small Office Security на 5 ПК на один год
награждаются:
Сергей Яремчук (Украина), Сергей Барамба (Санкт-Петербург), Андрей Би-
рюков (Москва)
Дипломами компании PentestIT награждаются:
Омар Ганиев, Виктор Алюшин (Москва), Теймур Хеирхабаров (Красноярск).
А также будет много поощрительных призов от компании SuperJob – часы
«Управляй своим временем».
Подробная информация – на нашем сайте samag.ru.

системный администратор март 2014 1

 В номере

08 14 19

КОНКУРС Автоматизация

01 От Москвы до самых до окраин. И даже дальше. 26 Мобильная торговля. Рассмотрим как можно автоматизиро-
Конкурс «СА» – ПрофИТ, 2013» завершен, итоги подведены. вать работу торговых представителей.
Дмитрий Андриенко
СОБЫТИЕ
БЕЗОПАСНОСТЬ
04 FOSDEM 2014. Впечатления о крупнейшей Open
Source-конференции в Европе. Что представляет собой европей- Угрозы
ское сообщество Open Source, чем живет, и велико ли оно?
Денис Силаков 30 Кому уходят СМС? Угрозы для мобильных устройств гораздо
опаснее своих собратьев, созданных для обычных компьютеров.
Администрирование Вячеслав Медведев

Балансировка нагрузки Продукты и решения

08 ZEN Load Balancer. Построение отказоустойчивых
сервисов. Рассмотрим основы балансировки сетевой нагрузки, а также
практическую ее часть на примере ZEN Load Balancer – продукта с открытым
исходным кодом.
Александр Руденко
Управление
14 Сладкая парочка, или Как настроить работу SCCM
с WSUS. Рассмотрим основные настройки, возможности, достоинства
и недостатки SCCM 2012 SP1 по управлению обновлениями.
Сергей Болдин
Новый дистрибутив
19 Microsoft Excel 2013. Работаем быстро и создаем
отчеты наглядно. Поговорим о тех преимуществах, которые получили
пользователи, применяющие программу Microsoft Excel из пакета Microsoft
Office 2013 или Office 365, по сравнению с предшественником – Excel 2010.
Ольга Кулешова
Бэкап
22 Резервное копирование для больших и маленьких.
Сравним различные типы архитектуры систем резервного копирования.
Алексей Бережной
34 BYOD и безопасность: мифы и реальность. Активное
распространение стратегии Bring Your Own Device во всех секторах экономики
существенно ускоряет темпы «мобилизации» бизнес-процессов.
Сергей Вахонин
базы данных
Изучаем «1С»
36 Ускоряем запуск 1С (для разработчика). Несколько
приемов, которые позволяют в десятки раз ускорить время запуска 1С,
особенно после обновления конфигурации.
Олег Филиппов
39 РАУЗ в 1С – друг или враг? Часть 1. Развенчание
мифов и поиск правды. Взглянем на новый режим учета затрат в 1С
беспристрастно, основываясь на реальной практике.
Игорь Чуфаров
Разработка
Проектирование
46 Концепции моделирования MongoDb на примере
разработки социальных игр. Подходы к проектированию данных
в документно-ориентированных БД и в традиционных СУБД отличаются.
Александр Календарев

2 март 2014 системный администратор

 В номере

22 74 80

Веб-технологии 72 От каждого – по труду, или Каким сисадминам

50 Меньше кода, больше дохода. Часть 2. Разработка
back-end слоя. Продолжаем изучать веб-фреймворк Tapestry для соз-
дания Java EE-приложений. Рассмотрим некоторые вопросы, связанные
с разработкой back-end слоя (серверная часть веб-приложения). Этот слой
включает в себя систему для работы с базами данных, инструменты для ау-
дита (логирование и т.д.) и многое другое.
Михаил Ушаков
Особенности языка
56 Ruby и многозадачность. В статье рассматриваются основ-
ные средства работы с потоками (threads) и процессами в языке и стандарт-
ной библиотеке Ruby.
Иван Шихалев
Тестирование
60 CamStudio в руках тестировщика. Применение
видеофайлов на этапе разработки и отладки ПО. Предлага-
ется улучшение менеджмента ИТ-проекта: на этапе разработки и отладки ПО
документацию о прохождении тестирования сохранять в форме видеомате-
риалов.
Анна Сергеева
больше платят. Исследовательский центр рекрутингового портала
Superjob.ru изучил предложения работодателей и ожидания претенден-
тов на позицию «Системный администратор UNIX» в Москве и Санкт-
Петербурге.
Валерия Чернецова
Вектор роста
74 10 формул для эффективного сисадмина. Путь
из падаванов в гуру лежит через шрамы ошибок. Формулы
есть не только в учебниках по химии или физике, но и в ИТ!
Сергей Барамба
77 Чему и как у нас учат. Разговор о преподавании
информатики в школе.
Сергей Ильичев
Пятая пара
80 Качество программного кода. От выявления
стилистических огрехов к поиску ошибок. Автоматизированные
инструменты проверки кода не ограничиваются синтаксическим анализом
и поиском нарушений, связанных со стилем и форматированием.
Денис Силаков

Наука и технологии 85 Лабораторная работа. Представление текстовой

информации в ЭВМ. Часть 1. Теоретические сведения о способах
66 Программная реализация редуцированной вычис- представления текстовой информации в памяти ЭВМ, в том числе и кирил-
лительной схемы численного интегрирования системы лицы.
линейных дифференциальных уравнений на основе Владимир Закляков
методов Эйлера.
Жадов А.Д., Востриков А.В., Борисов Н.И., Тумковский С.Р. Ретроспектива

Карьера/Образование 92 Леди-адмирал виртуальных морей. В этом мартовском

номере журнала естественно представить читателю не героя, а героиню
Рынок труда «компьютерного фронта».
Владимир Гаков
70 Вакансия: системный администратор Linux. Про-
должаем публикацию цикла статей в помощь ИТ-специалистам, начинающим Зал славы «СА»
и опытным, которые озабочены проблемой своего трудоустройства.
Игорь Штомпель 96 Гарвардская марка

системный администратор март 2014 3

 Событие
Визитка
Денис Силаков, кандидат ф.-м. н., ЗАО «РОСА», член рабочей
группы LSB, старший архитектор, занимается автоматизацией
разработки ОС «РОСА», denis.silakov@rosalab.ru
FOSDEM 2014
Впечатления о крупнейшей Open Source-конференции в Европе
Что представляет собой европейское сообщество Open Source, чем живет, и велико
ли оно? Мне выпала возможность оценить все это, побывав в феврале в Брюсселе
на FOSDEM 2014
История движения свободного программного обеспече-
ния (СПО) насчитывает уже три десятилетия – возраст
по меркам ИТ очень солидный. За это время сторонники
СПО  сумели создать и развивают достаточно много из-
вестных продуктов – ядро ОС Linux и системные компо-
ненты  от проекта GNU, браузер Firefox, офисный пакет
LibreOffice и многое  другое. Несмотря на поддержку ком-
мерческих компаний, эти проекты никогда не состоялись
бы без участия огромного числа энтузиастов, занимаю-
щихся их развитием на досуге, в свободное от основной
работы время.
Немаловажную роль в развитии СПО играет Интернет,
позволяющий объединить усилия разработчиков со всего
света. Однако никакая сеть полностью не заменит лично-
го общения. Для разработчиков СПО из Европы отличным
шансом встретиться сразу с большим количеством коллег
является FOSDEM – крупная конференция, посвященная
исключительно СПО, ежегодно проводимая в Брюсселе.
Возможность посетить FOSDEM в этом году выпала
и мне – вместе с коллегами из дистрибутива OpenMandriva,
в разработке которого принимают участие и многие сотруд-
ники РОСЫ, используя его в качестве своеобразной тесто-
вой площадки для обкатки различных новшеств.
Организация конференции
В отличие от крупных индустриальных конференций
FOSDEM организуется преимущественно силами добро-
вольцев из рядов сторонников свободного ПО. Посильную
помощь оказывают организации, так или иначе причастные
к миру открытых и свободных продуктов. Основным спон-
сором в этом году выступила компания Red Hat, немалую
техническую помощь оказали Cisco (благодаря которой
все участники были обеспечены Wi-Fi) и Google (видеотран-
сляция выступлений). Кстати, организаторы решили прове-
сти небольшой эксперимент и сделали основную Wi-Fi-сеть
(точнее, ее DHCP-сервер) доступной только по IPv6. Судя
по упорной борьбе, которую вели многие участники при под-
ключении к Интернету, далеко не все настольные ОС оказа-
лись готовы к такому повороту событий.
4 март 2014 системный администратор
Финансовую поддержку оказали Elasticsearch, Google,
HP, InnoGames, Oracle, O'Reilly, Qualcomm и Samsung. Раз-
меры помощи не раскрываются, но вряд ли она была очень
уж велика – запросы организаторов FOSDEM скромны,
здесь нет никаких бесплатных фуршетов/банкетов, куль-
турных мероприятий или хотя бы сувениров. Даже наобо-
рот – всем желающим предлагается лично поучаствовать
в спонсировании конференции, получив за это футбол-
ку с соответствующей надписью, если вы пожертвова-
ли 25 евро. Если раскошелились на 50 евро, то вдобавок
к футболке можно было получить одну из книг O'Reilly в мяг-
кой обложке, а 100 евро давали право на книгу в твердой
обложке. Продажей сувениров и атрибутики занимались
на своих стендах и другие открытые проекты и некоммер-
ческие организации – KDE, Gnome, Debian, Free Software
Foundation, Mozilla и т.д.
Главным же нефинансовым помощником вот уже кото-
рый год является Брюссельский свободный университет
(Universite Libre de Bruxelles, ULB), на выходные практически
полностью отдающий свои учебные помещения под нуж-
ды FOSDEM. Университет немаленький (насчитывает бо-
лее 20 тысяч студентов), и больших лекционных аудиторий
у него хватает. А поскольку университет еще и современ-
ный, то в каждой аудитории имеются экран и прочие при-
надлежности для показа презентаций (правда, кроме ком-
пьютера, докладчикам все-таки приходилось использовать
свои ноутбуки, и не всегда их системы хорошо дружили
с проекторами).
Масштабность университета обусловливает и размах
конференции – доклады шли параллельно в 23 аудиториях,
и всего за два дня выступили более 500 докладчиков. Сколь-
ко всего человек посетили конференцию, сказать сложно,
поскольку вход был абсолютно свободный и не требовал ни-
какой регистрации. На сайте FOSDEM организаторы скром-
но пишут «5000+». Но по моим наблюдениям в некоторых
аудиториях присутствовали по крайней мере несколько де-
сятков человек, а кое-где – и более двух сотен. Так что чис-
ло 5000 может оказаться и заниженным – в кулуарах говори-
ли о 7000 посетителей.
 Событие

Самое главное – практически все посетители действи- Тот факт, что новые продукты полностью открыты
тельно имели определенное отношение к свободному и не завязаны на закрытые компоненты типа СУБД Oracle,
ПО, являясь либо участниками разработки, либо пользо- делает их привлекательными и для других разработчиков.
вателями. Конечно, встречались и просто любопытствую- Более того, сотрудники компании на FOSDEM выражали
щие, желающие посмотреть, как выглядят Linux и другие активную заинтересованность в реализации поддержки си-
свободные приложения. Однако доклады были все-таки стем, отличных от Red Hat. В частности, они с энтузиазмом
рассчитаны на разработчиков и людей, участвующих в соз- восприняли предложение попробовать добавить поддерж-
дании и развитии открытых проектов (дизайнеров, популя- ку систем на основе Mandriva – в частности, десктопной
ризаторов и прочих нетехнических специалистов, состав- версии РОСЫ и OpenMandriva (которые также используют
ляющих немаловажную часть сообщества). пакеты формата RPM, но при этом имеют свой собствен-
В итоге конференция получилась крупной, очень на- ный формат метаданных для репозиториев). Собственно,
сыщенной и без «лишних» людей, зашедших просто по- для РОСЫ мы уже сделали пробную поддержку десктопных
глазеть. Зато стоящих докладов хватало – было что послу- версий в Katello и Pulp (для серверной версии доработок
шать. Давайте к ним и перейдем. не требуется, поскольку она основана на Red Hat). И могу
сказать, что особых проблем это не вызвало – компонен-
Red Hat ты нового стека RHN следуют духу открытого ПО, и дора-
Являясь основным спонсором, Red Hat представила доста- батывать их под свои нужды достаточно реально. С точки
точно много презентаций по своим продуктам и процессам зрения функционала все они уже вполне работоспособны,
разработки. Доклады, посвященные развитию существую- хотя еще есть над чем поработать, – например, заявленная
щих и созданию новых продуктов для корпоративного сек- на FOSDEM интеграция Katello и Foreman на данный мо-
тора, вызвали большой интерес системных администрато- мент сводится к наличию ссылки в веб-интерфейсе одного
ров и всех тех, кто имеет отношение к использованию Linux на веб-интерфейс другого.
на предприятиях. В частности, инженеры компании расска- Популярной темой являлись облачные технологии
зывали о будущих направлениях развития Red Hat Network и средства виртуализации – и на стенде, и в презентациях
(RHN) – набора инструментальных средств для управления можно было узнать немало интересного об oVirt, OpenStack,
компьютерным парком компании. Сейчас для развертыва- Xen и сопутствующих продуктах. Интересно, что на стенде
ния полноценной среды управления жизненным циклом Xen демонстрировалась машина с Qubes OS – операцион-
большого набора машин (включая развертывание и обнов-
ление на них ОС, инвентаризацию, мониторинг и прочее)
Рисунок 1. Логотип конференции FOSDEM
используется RHN Satellite Server, который можно развер-
нуть на предприятии и локально. Одним из спорных мо-
ментов во внутреннем устройстве Satellite Server является
использование Oracle в качестве СУБД, что не в лучшую
сторону сказывается на его стоимости.
Назвать Satellite Server полностью открытым решением
сложно, но компания последние годы движется в сторону
сообщества. Код компонентов Satellite Server был открыт
еще в 2008 году; открытая версия, развиваемая с помощью
сообщества, получила имя Spacewalk. В 2012-м в Spacewalk
появилась возможность избавиться от Oracle и использо-
вать PostgreSQL в качестве альтернативы. Однако в обо-
зримом будущем в RHN возможны более радикальные
Рисунок 2. Открытие FOSDEM – и это далеко не все участники! (Фото из галереи FOSDEM
изменения, а именно переход от Satellite/Spacewalk к со- в Google+)
вершенно новым продуктам, изначально открытым и ори-
ентированным на свободные технологии.
Одним из таких продуктов должен стать Foreman [1].
Он сейчас позиционируется как инструментарий для управ-
ления пулом реальных или облачных серверов, поддержива-
ющий все стадии их жизненного цикла. Foreman предостав-
ляет средства развертывания ОС на множество серверов
и интегрируется с системами управления конфигурацией –
такими, как Puppet и Chef, он уже сейчас вполне работоспо-
собен и может быть использован в реальной жизни.
Наряду с Foreman в новую линейку RHN должны во-
йти система управления репозитариями Pulp [2], инстру-
ментарий управления подписками Candlepin [3], а также
Katello [4], интегрирующий все эти компоненты в приятный
унифицированный веб-интерфейс и предоставляющий ряд
дополнительных возможностей по управлению и монито-
рингу большого парка машин.

системный администратор март 2014 5

 Событие
ной системой, позволяющей запускать приложения раз-
личных типов в изолированных доменах. Домен – факти-
чески виртуальная машина Xen, так что крах приложения
из одного домена не приведет к проблемам в остальных.
Впрочем, пользователю о ВМ знать не обязательно – при-
надлежность конкретного приложения тому или иному до-
мену можно определить только по цвету его окна. Конечно,
для запуска Qubes OS желательно иметь машину помощ-
нее, да и скорость запуска временами оставляет желать
лучшего. Но если вы готовы пойти на такие жертвы ради
увеличения безопасности и стабильности, то эта ОС впол-
не может быть вам полезна.
Помимо информации о продуктах для конечных поль-
зователей, сотрудники Red Hat делились некоторыми
подробностями внутренней кухни компании – рассказы-
вали о процессах разработки, процедурах тестирования
и обеспечения качества. Так что разработчики могли по-
заимствовать что-то для себя – как процессы, так и гото-
вые технологии для их воплощения в жизнь. Например,
инструментарий Nitrate для управления тестами, Dogtail
для автоматизации тестирования приложений с графиче-
ским интерфейсом, cwrap для автономного тестирования
клиент-серверных программ.
Все рассматривавшиеся инструменты открыты
и бесплатны. К тому же инженеры компании и сами лю-
бят использовать свободные инструменты от других ко-
манд – например, для инспекции исходного кода они приме-
няют Gerrit, а при автоматизации тестирования приложений
с графическим интерфейсом – наработки проекта AT-SPI
(Assistive Technology Service Provider Interface), изначально
предназначенного для обеспечения комфортного взаимо-
действия людей с ограниченными возможностями и графи-
ческой среды ОС.
Другие дистростроители
Представительство других производителей дистрибу-
тивов Linux выглядело скромно. А жаль, ведь наверняка
SUSE и Ubuntu тоже могут рассказать немало интересно-
го об опыте промышленного использования и внедрения
Linux. Однако Ubuntu своего стенда не имела, а из пре-
зентаций были только общий рассказ об Unity и пове-
ствование о взаимодействии с сообществом и обычными
пользователями. OpenSUSE, наоборот, была представлена
только стендом, а о коммерческой версии дистрибутива
и ее корпоративных функциях даже не у кого было поин-
тересоваться.
Debian также был представлен стендом и несколькими
докладами. Один из них, посвященный воспроизводимости
сборки пакетов под эту систему, на мой взгляд, должен
дать повод задуматься администраторам, использующим
Debian в промышленных масштабах. Проблема дистрибу-
тива и его мейнтейнеров заключается в отсутствии центра-
лизованной сборочной инфраструктуры, которая бы слу-
жила единственным источником пакетов в официальных
репозиториях.
В ситуации, когда каждый мейнтейнер собирает пакеты
на своей машине, на основе одного и того же исходного
кода у разных разработчиков могут получиться несколь-
ко различные результаты. Штатные инструменты Debian
решают эту проблему лишь частично. И есть ненулевой
6 март 2014 системный администратор
шанс, что мейнтейнер при исправлении одной ошибки
может случайно внести в пакет ряд непреднамеренных из-
менений (по сравнению с предыдущей версией), обуслов-
ленных изменением сборочного окружения. Или потра-
тит некоторое время, разбираясь, как этот пакет вообще
должен собираться. Как следствие, подготовка обновле-
ний может немного затянуться, а вместе с обновлениями
дистрибутива можно получить изменения, не описанные
ни в каких комментариях. Справедливости ради отметим,
что вероятность натолкнуться на подобную проблему до-
статочно мала, но лучше бы ее не было совсем. В конце
концов почти все более-менее крупные команды давно пе-
решли на использование специализированных сред сбо-
рок – Open Build Service, Koji, Launchpad или ABF (про ис-
пользование которой для сборки ARM-порта OpenMandriva
мы рассказывали на FOSDEM вместе с коллегами из этого
дистрибутива).
В завершение рассказа о представленных на FOSDEM
дистрибутивах нельзя не отметить предназначенный
для детей DoudouLinux – ОС с простым интерфейсом, соот-
ветствующим набором приложений и основным разработ-
чиком, который явно знает о нуждах детей не понаслышке
и сам временами был похож на большого ребенка.
Офисные пакеты…
Интересной и разнообразной оказалась секция, посвящен-
ная свободным текстовым редакторам. На ней рассказыва-
лось не только о возможностях соответствующих приложе-
ний (прежде всего Libre- и OpenOffice), но и особенностях
их разработки. Не секрет, что Libre- и OpenOffice являются
одними из самых крупных и сложных открытых приложе-
ний. И не удивительно, что создатели средств разработки
под Linux ориентируются именно на эти проекты.
На FOSDEM можно было услышать рассказ одного
из разработчиков, отладчика GDB, об улучшениях, реа-
лизованных в этом инструменте по запросу участников
LibreOffice, а команда Eclipse поведала, как они изменяют
свой продукт по аналогичным запросам из OpenOffice. Надо
сказать, что специфика проектов заключается не только
в размере кода, но и в любви разработчиков к различным
новшествам и редко используемым возможностям языков
и библиотек. В частности, оба проекта активно используют
C++, включая новшества C++11. Для упрощения отладки
такого кода разработчикам GDB пришлось немало потру-
диться; впрочем, судя по активным дискуссиям в кулуарах,
у GDB есть еще много направлений для развития в этой
области.
Что касается новшеств для конечных пользовате-
лей, то их тоже хватает – помимо традиционных работ
по улучшению поддержки различных форматов файлов
от Microsoft, разработчики LibreOffice предлагают и неко-
торые изюминки, например, возможность использовать
графический сопроцессор при вычислениях в электрон-
ных таблицах LibreOffice Calc. Не забыты и корпоративные
клиенты – современный LibreOffice может использовать
реестр Windows для хранения пользовательских настро-
ек (коих насчитывается несколько тысяч) и предоставля-
ет администраторам возможность управлять настройками
свободного офисного пакета на машинах пользователей
посредством групповых политик.

Для управления конфигурациями LibreOffice на Linux-
машинах докладчики рекомендуют использовать пакеты
с конфигурационными файлами, а для управления пакета-
ми на множестве машин рекламировали открытую утилиту
Remote Root [5]. Теоретически Remote Root представляет
собой удобный веб-интерфейс, взаимодействующий с кли-
ентскими машинами по SSH. Однако на момент написания
статьи (равно как и на момент доклада) скачать инструмент
с сайта все еще было нельзя. Видимо, авторы еще не соч-
ли свое творение достаточно работоспособным, чтобы вы-
ложить его на всеобщее обозрение. Что же, подождем.
…и прочее, прочее, прочее
Существенный минус наличия большого количества парал-
лельно идущих секций – это физическая невозможность
посетить все интересные презентации. Впрочем, большин-
ство презентаций и видеозаписи выступлений можно найти
на сайте fosdem.org.
Помимо рассмотренных выше докладов проходили сек-
ции «по интересам»: для разработчиков Java, Ada, Perl
и Smalltalk, для администраторов и пользователей MySQL,
PostgreSQL и BSD. Обсуждалась очередная серия попыток
решить вопросы междистрибутивного взаимодействия –
например, предоставить вендорам способ собрать прило-
жение, пригодное для работы сразу во многих дистрибути-
вах (в принципе ничего нового – основные рекомендации
сводятся к помещению всех имеющихся зависимостей
внутрь приложения).
Много внимания уделили нетехническим обсуждени-
ям – рассмотрению юридических вопросов, различных
аспектов взаимодействия с сообществом и т.п. Немало до-
кладов имело научный уклон и рассматривало алгоритмы
и инструменты для решения вполне практических задач –
например, целая секция была посвящена обработке гра-
фов. Наконец, был стенд Google Summer of Code, активно
агитировавший студентов и разработчиков участвовать
в этой программе.
Рисунок 3. Qubes OS: для каждого рода задач – свой домен
системный администратор март 2014
Событие
Но главное – это общий позитивный настрой всех участ-
ников конференции и заряженность на работу, а также
очень доброжелательная атмосфера и вежливое отноше-
ние друг к другу, что, к сожалению, не всегда встречается
в мире СПО, особенно при удаленном общении.
***
Тот факт, что на организуемое преимущественно энтузи-
астами мероприятие уже не первый год съезжаются не-
сколько тысяч человек, активно увлеченных разработкой
свободного ПО, наглядно демонстрирует большой интерес
к этой сфере в Европе (подчеркну, что конференция прежде
всего европейская, участников из других частей света было
немного). Поражает и количество докладов: более 500 вы-
ступлений – очень серьезная цифра, а ведь организаторы
одобряли далеко не все поступавшие заявки.
Достаточно контрастно FOSDEM смотрится на фоне
отечественного мира СПО, да и ИТ в целом. По масшта-
бу до FOSDEM сильно не дотягивают даже крупнейшие
российские ИТ-мероприятия, такие как «Форум Тех-
нологий» от Mail.ru, Yet another Conference от Yandex
или CEE-SECR. Что уж там говорить о конференциях
для сторонников СПО –  о сотнях докладов и тысячах по-
сетителей нам пока можно только мечтать. Будем надеять-
ся, что в будущем движение  СПО в нашей стране станет
только набирать обороты. А пока что приятно отметить,
что в аудиториях Брюссельского университета можно было
встретить и представителей нашей страны, пусть и немно-
гочисленных. EOF
1. Проект Foreman – http://theforeman.org.
2. Проект Pulp – http://www.pulpproject.org.
3. Проект Candlepin – http://candlepinproject.org.
4. Проект Katello – http://www.katello.org.
5. Сайт Remote Root – http://remoteroot.org.
Ключевые слова: FOSDEM, СПО, форум.
Рисунок 4. Сторонники СПО – совсем не обяза-
тельно суровые бородатые админы
7
 Администрирование
Визитка
Александр Руденко, администратор информационной
безопасности, ЗАО «Молдавская ГРЭС», a.rudikk@gmail.com
ZEN Load Balancer
Построение отказоустойчивых сервисов
Рассмотрим основы балансировки сетевой нагрузки, а также практическую ее часть
на примере ZEN Load Balancer – продукта с открытым исходным кодом
Когда нужна балансировка
Что есть балансировка нагрузки? Это распределение вхо-
дящих сетевых подключений между несколькими вычис-
лительными узлами. При этом использование аппаратных
или программных решений, а также применяемый алгоритм
распределения сути совершенно не меняют.
Но благодаря ей можно решить две достаточно серьез-
ные проблемы.
>> Во-первых, это распределение нагрузки между вычис-
лительными узлами в ситуации, когда ресурсов одного
сервера недостаточно и вертикальное наращивание
его мощности уже невозможно. В таком случае необхо-
димо добавление еще одной вычислительной единицы
и применение одного из видов балансировки.
>> Во-вторых, обеспечение доступности. Как известно,
отказоустойчивость любой системы, будь то реше-
ние аппаратное или программное, достигается путем
дублирования основных компонентов. К сожалению,
не существует абсолютно надежных жестких дисков,
RAID-контроллеров и прочего оборудования, а совре-
менный уровень программирования не гарантирует от-
сутствие сбоев в ПО.
По этой причине при построении отказоустойчивых сер-
висов дублируется все: сетевые контроллеры, коммутаторы
и даже сами вычислительные узлы.
Например, нагрузка, создаваемая на один сервер, может
быть небольшой, но при этом хочется, чтобы выход из стоя
одного или нескольких узлов не привел к простою сервиса.
Поможет балансировщик нагрузки.
Основные виды и техники балансировки
Все существующие виды балансировки можно разделить
на три глобальные группы, отличающиеся между собой
«глубиной» анализа входящих запросов и степенью провер-
ки доступности серверов.
Примитивные методы
В эту группу входят способы балансировки, которые ника-
ким образом не анализируют входящий трафик и не про-
8 март 2014 системный администратор
балансировка нагрузки
веряют доступность вычислительных узлов. Самый яркий
представитель данной группы – это распределение запро-
сов с помощью DNS, о котором ниже.
Round robin DNS (циклический перебор). Пожалуй,
самый распространенный метод. Основан на том, что спец-
ификация DNS позволяет создавать несколько одинаковых
А-записей с отличными IP-адресами.
Например, можно завести две записи для одного узла
srv‑01.company.com с различными IP-адресами, принад-
лежащими разным серверам. Дополнительно должна
быть включена специальная опция (Round robin) на DNS-
сервере. В результате при каждом новом запросе записи
srv‑01.company.com будут отдаваться разные IP-адреса,
что приведет к равномерному распределению подключений
между узлами.
Но при всей легкости и дешевизне данного решения име-
ется ряд ограничений:
>> Во-первых, нет никаких методов проверки доступности
узлов. То есть сервер может выйти из строя, но DNS
все равно будет отдавать его IP-адрес клиентам.
>> Во-вторых, не учитывается число текущих сессий
на том или ином узле. Может получиться ситуация, ког-
да на одном из серверов открытых сессий значитель-
но больше, чем на остальных, при этом подключения
все равно будут распределяться равномерно.
>> Ну и, в-третьих, DNS не учитывает, к какому серверу
был подключен пользователь в прошлый раз. Возмож-
но, что при каждом новом подключении, например,
к терминалу или к веб-серверу, будет открываться
новая сессия на другом узле, что может быть нежела-
тельно.
Отдельно хочется выделить сервисы типа Amazon
Route 53 [1]. Это облачный DNS-хостинг, позволяющий,
кроме стандартных функций, указывать «вес» одинаковых
А-записей, что позволяет распределять входящие запросы
более гибко. Кроме этого, возможна интеграция с облачным
балансировщиком нагрузки Elastic Load Balancing, доступ-
ным в Amazon Web Services, что позволяет добиться еще
более тонкой балансировки.
 балансировка нагрузки
Также к примитивным методам можно отнести баланси-
рование вручную. Суть метода в разделении всех пользо-
вателей на несколько групп и подключение их к различным
серверам.
Например, в организации работает два терминальных
сервера одинаковой производительности. Половине поль-
зователей на рабочем столе создается ярлык для подключе-
ния к первому серверу, а оставшимся – ко второму. Допол-
нительно, на случай отказа текущего узла, создается ярлык
для подключения к другому серверу, который будет являться
резервным.
Пожалуй, подобный метод применим лишь в неболь-
ших организациях, причем целью такого распределения
является именно отказоустойчивость, а не балансировка.
При этом нет необходимости в дополнительном оборудова-
нии и программном обеспечении, но придется немного по-
работать руками.
Балансировка на транспортном уровне (L4)
Это самый универсальный и распространенный механизм.
Одинаково применим для TCP и UDP-протоколов, соответ-
ственно им можно распределять трафик практически любо-
го сервиса.
На этом уровне во входящих пакетах проверяется лишь
IP-адрес и номер порта назначения. В случае совпадения
с одним из правил трафик будет попросту перенаправлен
на указанные серверы с помощью механизма sNAT в уста-
новленном порядке. Содержимое пакетов не проверяется.
Также нет никаких особых техник проверки доступности
вычислительных узлов. Выполняется простая проверка до-
ступности адреса и порта. В случае если порт открыт, сер-
вер считается доступным и к нему продолжают отправлять-
ся запросы.
По такому механизму работает большинство популярных
программных и аппаратных балансировщиков, в том чис-
ле Network Load Balancing (NLB), используемый в Windows
Server. Также к этой категории можно отнести популяр-
ные нынче облачные сервисы типа Elastic Load Balancing
от Amazon, упомянутого выше.
системный администратор март 2014
Администрирование
Штатные средства кластеризации
и резервного копирования
делают работу с этим продуктом
приятной и беззаботной
Балансировка на прикладном уровне (L7)
Динамично развивающийся вид распределения нагрузки
на уровне приложений. Такие балансировщики еще назы-
вают контроллерами доставки приложений. Ориентированы
на работу с высокоуровневыми протоколами. В основном
HTTP/HTTPS.
Здесь, как и в случае с предыдущим видом, описывают-
ся правила. При установке соединения на некотором порту
пакеты перенаправляются на указанные адреса и порты вы-
числительных узлов. Но при выборе конкретного сервера
для ретрансляции на него трафика учитываются тип клиен-
та, URL, содержимое cookie, запрашиваемый контент и не-
которые другие параметры.
Кроме этого, проверка доступности сервиса на вычисли-
тельных узлах выполняется значительно интеллектуальнее.
Например, может запрашиваться некоторый URL и прове-
ряться его содержимое.
Еще одной отличительной чертой этого типа от L4 явля-
ется то, что серверы в кластере могут быть не идентичными.
Например, одни узлы могут поставлять статические данные
типа фото и видео, а другие серверы доставляют контент
с помощью скриптов, HTML и CSS. В таком случае могут
быть созданы правила для каждого типа контента с особы-
ми алгоритмами перенаправления трафика на различные
группы серверов.
В этой категории также существует еще один класс
профильных балансировщиков типа Citrix NetScaler [2].
Это решение специализируется на распределении нагрузки
и повышении производительности продуктов Citrix (XenApp,
XenDesktop), а также веб-приложений. Кроме продвинутой
балансировки, он умеет выполнять компрессию контента,
мощное кэширование, обеспечивает шифрование, а также
анализ трафика и его фильтрацию. Это лишь небольшая
часть его возможностей, которые заслуживают отдельной
статьи.
Почему ZEN
Прежде чем мой выбор остановился на ZEN Load Balancer,
я опробовал еще несколько кандидатов, среди которых
9
 Администрирование
были классический HAProxy и не менее известный Linux
Virtual Server.
Все трое являются проектами с открытым исходным ко-
дом. Касательно функционала они практически равны. Ос-
новными требованиями были легкость настройки и удобство
управления.
Во время установки и в процессе настройки дистрибути-
ва Zen LB присутствует чувство целостности, все работает
слаженно и предсказуемо. Именно благодаря этому пункту
выбор был сделан в его пользу.
Что собой представляет Zen LB
Это дистрибутив Linux, в его основе лежит переработанный
Debian 6, от которого, по сути, оставлена лишь базовая сис-
тема. Добавлены собственный балансировщик и средства
управления им.
Первая версия была выпущена в 2011 году, текущий
стабильный релиз 3.03. Обновления дистрибутива выходят
по нескольку раз в год.
Данный продукт представлен в двух редакциях:
>> Бесплатная версия существует, к сожалению, только
в 32-битном варианте, не имеет технической поддерж-
ки.
>> Платная 64-битная версия, стоит порядка 850 долла-
ров. В стоимость также включается техническая под-
держка.
Получается, что единственным техническим ограничени-
ем бесплатной версии является предел по производитель-
ности и пропускной способности.
У меня не было возможности произвести нагрузочное те-
стирование, но по тем данным, что я нашел в сети, 32-битный
Zen LB с легкостью справляется с тысячей пользователей
Exchange, а также с несколькими сотнями терминальных
сессий.
Рисунок 1. Схема работы балансировщика нагрузки
10
балансировка нагрузки
Конкретно в моем случае пользователей почты и терми-
нального сервера было немного меньше. Но главной за-
дачей являлось прозрачное переключение на резервный
сервер в случае выхода из строя основного, и с ней Zen LB
справляется отлично.
Основные возможности Zen LB
>> Классическая балансировка на транспортном (L4)
уровне для протоколов TCP, UDP. Несколько алгорит-
мов распределения: по кругу, по весу (Weight), по при-
оритету (Priority) или по хешу.
>> Продвинутая балансировка на прикладном (L7) уровне
для HTTP/HTTPS.
На обоих уровнях (L4, L7) возможен возврат пользовате-
ля в открытую сессию.
Идентификация уникальной сессии клиента возможна
по нескольким алгоритмам:
>> по IP-адресу клиента;
>> по данным cookie;
>> по основному заголовку при базовой аутентификации;
>> по запрашиваемому URL;
>> по настраиваемому полю заголовка HTTP.
Возможна SSL-акселерация. В этом режиме Zen LB будет
выполнять роль SSL-прокси. Это означает, что канал станет
шифроваться от клиента и до балансировщика, а взаимо-
действие самого Zen LB с реальными серверами фермы бу-
дет проходить без шифрования.
>> Поддерживаются VLAN.
>> Допускается работа нескольких балансировщиков
в кластерном режиме.
>> Есть встроенная система резервного копирования
и восстановления конфигурации.
>> Присутствует система мониторинга и отображения на-
грузки в виде графиков.
март 2014 системный администратор
 балансировка нагрузки
Также стоит отметить фирменный механизм проверки
доступности реальных серверов – FarmGuardian. Эта техно-
логия позволяет использовать специальный скрипт для про-
верки работоспособности сервисов, нагрузка на которые
должна быть распределена балансировщиком.
Профили балансировки
По сути, это выбор уровня балансировки. TCP и UDP балан-
сируются классически на транспортном уровне, а HTTP со-
ответственно на прикладном.
Помимо этого, присутствует вариант L4xNAT. Это та же ба-
лансировка на транспортном уровне, только тут не учитыва-
ются номера портов. То есть трафик принимается на любых
портах и перенаправляется к реальным серверам. Это сво-
его рода труба. Все, что влетело, в том же виде и отправля-
ется дальше.
Еще один профиль, не имеющий почти ничего общего
с классической балансировкой нагрузки, – это DATALINK.
Это новая функция в арсенале Zen LB. С его помощью мож-
но осуществлять балансировку нагрузки между нескольки-
ми каналами связи.
Например, когда организация имеет два канала в Ин-
тернете от различных провайдеров. Будучи в роли шлюза,
Zen LB может прозрачно для пользователей переключаться
между несколькими каналами или разделить по ним весь
трафик.
Информацию о том, как этим воспользоваться, можно
с легкостью найти в Интернете [3].
Алгоритмы выбора сервера
Round-Robin: equal sharing – равное распределение.
Примитивный алгоритм, используемый по умолчанию.
Входящие подключения равномерно распределяются
между всеми реальными вычислительными узлами. Та-
кие  параметры серверов, как Weight, Priority, не учиты-
ваются.
Hash: sticky client – привязка клиента к одному серверу.
Механизм работает следующим образом. Для каждого
клиентского IP-адреса создается хеш-строка, которая
помещается в специальную таблицу. В дальнейшем кли-
ент идентифицируется по этой строке, а все принятые
от него пакеты перенаправляются на один и тот же сер-
вер.
Weight: connection linear dispatching by weight – рас-
пределение по весу. Этот алгоритм учитывает значение
параметра Weight, заданного (или не заданного) для каж-
дого реального сервера. В зависимости от значения
этого числового параметра будут распределены под-
ключения. Это дает возможность более гибко настроить
балансировку при разных по мощностям серверах.
Priority: connections to the highest priority
available – распределение по приоритету (параметр
сервера Priority). Этот алгоритм позволяет постро-
ить кластер по типу активный-пассивный. Например,
есть три узла. У первого значение приоритета выстав-
лено 12, у второго – 8 и у третьего – 4. В таком случае
все входящие подключения будут направлены к серверу
с наивысшим приоритетом, то есть к первому. В случае
его отказа трафик будет перенаправляться на следую-
щий. И так далее.
системный администратор март 2014
Администрирование
Как это работает
Базовая архитектура выглядит следующим образом. Zen LB
располагается между клиентом и сервером. В идеале ре-
альные серверы доступны только ему и закрыты сетевым
экраном от прямых клиентских подключений. Для получения
доступа к тому или иному сервису пользователю необходи-
мо знать только адрес балансировщика. Собственно, к нему
и направляется весь сетевой трафик.
Далее, в зависимости от отписанных правил, пакеты пе-
ренаправляются на наиболее подходящие серверы. В каж-
дом конкретном случае сервер определяется в зависимости
от выбранного алгоритма.
Далее вся магия реализуется по средствам механизма
sNAT, который занимается подменой IP-адресов, а также
портов отправителя и получателя. В результате сервер при-
нимает пакеты, как будто бы от самого балансировщика.
Ему же он и возвращает ответ, в котором аналогичным об-
разом заменяются IP-адреса и пакеты отправляются конеч-
ному клиенту.
Таким образом, распределение трафика происходит со-
вершенно прозрачно для конечных пользователей и серве-
ров, его обрабатывающих.
Если откажет реальный сервер
Если по какой-то причине реальный сервер не отвечает
на указанном порту в течение времени, определенном в па-
раметре Backend response timeout (пять секунд по умолча-
нию), то на этот сервер перестанут поступать новые под-
ключения.
В веб-консоли неотвечающий узел будет помечен крас-
ной отметкой. Все активные сессии, естественно, разорвут-
ся, а повторное подключение клиента будет уже выполнено
к другому, рабочему, серверу.
По умолчанию через каждые пять секунд выполняется
повторная проверка доступности отказавшего ранее узла
(параметр Frecuency to check resurrected backends). Если
сервер вновь начинает отвечать, то его ввод в эксплуата-
цию происходит автоматически.
Что собой представляют правила
В правилах описывается, на каких интерфейсе и порту ожи-
дать подключения и на какие адреса и порты их нужно от-
сылать. Это очень похоже на перенаправление портов – Port
Riderect. Интерфейсов, на которых ожидаются подключе-
ния, может быть много.
Например, за балансировщиком находятся несколько
веб-серверов, нагрузку на которые необходимо распреде-
лить равномерно. Для этого создается специальный вирту-
альный сетевой интерфейс, которому присваивается про-
извольный IP-адрес. Это обычный псевдоним (Alias), ничем
не отличающийся от такового в любой системе. Далее гово-
рится, что необходимо слушать на этом интерфейсе и в кон-
кретном порту.
Например, на том, что используется по умолчанию на веб-
сервере, – 80. Затем следует список узлов, находящихся
за балансировщиком (адреса и порты реальных серверов),
на которые нужно направлять поступающий трафик. В тер-
минологии Zen группа реальных серверов, обслуживающих
один сервис, называется фермой (farm).
Все можно увидеть на рис. 1.
11
 Администрирование
Практика
Давайте перейдем непосредственно к практике.
Развертывание
Образ дистрибутива может быть развернут как на физиче-
ский сервер, так и в качестве виртуальной машины без ка-
ких-либо сложностей.
Требования дистрибутива к оборудованию самые демо-
кратичные. Подойдет любой Debian-совместимый компью-
тер или платформа виртуализации. Для работы Zen LB до-
статочно одного сетевого интерфейса. В идеале неплохо,
чтобы их было два: один для управления, а второй для при-
ема клиентских подключений.
Установка Zen LB ничем не отличается от таковой про-
цедуры у любого другого дистрибутива Linux.
На первом шаге мастер предложит выбрать язык для про-
цесса установки. В списке присутствует русский, что зна-
чительно упростит это мероприятие для неопытных специа-
листов.
Единственное, чем выделится дистрибутив, так это тем,
что после выбора языка и страны он автоматически под-
ставляет доступные для этой местности часовые пояса.
Это, пожалуй, логично, но очень неудобно для тех, кто гово-
рит по-русски, но проживает не в России.
Поэтому на последнем шаге установщика необходимо
перейти в пункт «Другие» и из полного списка выбрать нуж-
ный часовой пояс.
После установки управление всеми параметрами балан-
сировщика осуществляется с помощью веб-интерфейса,
который, стоит отметить, выполнен качественно, приятен
глазу и работает быстро и безотказно.
Настройка правил
Основная часть настроек балансировщика производится
из веб-консоли, доступной по HTTPS/81. Учетные данные
по умолчанию admin, и такой же пароль.
Интерфейс крайне прост. Доступно всего четыре разде-
ла, в одном из которых (About) текст лицензии GNU/GPL, по-
этому реально полезных остается три. Кратко пробежимся
по каждому.
Раздел Settings. Тут общие настройки. Параметры NTP,
DNS, смена пароля администратора, резервное копирова-
ние конфигурации сервера. Наиболее важные пункты здесь:
>> Interfaces – создание виртуальных интерфейсов;
>> Cluster – где можно собрать кластер из нескольких сер-
веров Zen.
Раздел Monitoring. Содержит различные графики и дает
возможность просмотреть лог балансировщика.
Ну и, наконец, раздел Manage. Здесь можно загрузить
сертификат, подписанный доверенным центром сертифика-
ции, который будет использоваться при работе по HTTPS.
Также тут расположен, пожалуй, главный пункт – Farms.
Именно здесь указываются адреса реальных серверов,
а также описываются правила распределения трафика.
Для более наглядной демонстрации механизма работы
приведу пример настройки балансировки для терминальных
серверов Windows.
Допустим, что у нас их два:
>> первый 10.200.77.45 порт 3389;
>> второй 10.200.77.46 порт 3389.
12
балансировка нагрузки
Терминальные службы могут работать и на других портах,
отличных от стандартных, это не принципиально.
Первое, что нам необходимо сделать, – создать новый
виртуальный интерфейс, на котором Zen LB будет прини-
мать подключения к терминальным серверам.
Идем в Settings → Interfaces и в строке с нашим фи-
зическим интерфейсом в колонке Action находим пункт
Add  new  virtual network interface. В появившейся новой
строке указываем произвольный порядковый номер ин-
терфейса и задаем ему IP-адрес. Фактически будет создан
обычный Alias.
Теперь нужно настроить новую ферму. Ферма – это свое-
го рода группа реальных серверов и описание того, где бу-
дет приниматься и по какому алгоритму пересылаться тра-
фик конкретного сервиса.
Итак, идем Manage → Farms и в поле Farm Description
Name пишем произвольное описание нашего сервиса.
Далее в выпадающем поле Profile необходимо выбрать
тип балансировки:
>> TCP;
>> UDP;
>> HTTP;
>> L4xNAT;
>> DATALINK.
Так как терминальный сервер Windows работает по про-
токолу TCP, то его и оставляем. После нажатия Save появит-
ся новый пункт Virtual IP.
Это интерфейс, на котором балансировщик будет при-
нимать входящие подключения. Выбираем из списка ранее
созданный Alias и в поле рядом указываем порт, на котором
будем слушать. Я указываю стандартный (3389), но при же-
лании можно указать произвольный. Тогда клиенты должны
будут использовать при подключении именно его.
Теперь, когда ферма создана, в поле Action новой фермы
находим пункт Edit и переходим к списку параметров балан-
сировки. Тут и алгоритм, и параметры проверки серверов,
и различные количественные ограничения. Но самое глав-
ное – это таблица внизу Edit real IP servers configuration – спи-
сок реальных серверов.
Выбираем Add real server и указываем адрес реаль-
ного сервера, порт, а также такие параметры, как Max
connections, Weight, Priority. В список можно добавить сколь-
ко угодно серверов.
Теперь в настройках терминального клиента указыва-
ем адрес нашего виртуального интерфейса и порт, если
он не стандартный, и прозрачно попадаем на один из терми-
нальных серверов из списка добавленных.
Отказоустойчивость балансировщика
Естественно, что в приведенных выше примерах единой точ-
кой отказа является сам балансировщик. В случае его отка-
за доступ к сервисам будет невозможен. Поэтому в идеале
необходимо обеспечить резервирование.
Для этого разработчики в дистрибутив Zen LB включены
средства кластеризации. Возможно построение двухуз-
лового кластера, без каких-либо дополнительных сетевых
адаптеров и прочих сложностей. Делается это следующим
образом.
На одном из двух хостов Zen LB в разделе Setings →
Interfaces необходимо создать новый виртуальный сете-
март 2014 системный администратор
 балансировка нагрузки
вой  интерфейс, как в примерах выше. Это интерфейс уп-
равления кластером. По этому адресу всегда будет досту-
пен текущий мастер.
Далее в разделе Setings → Cluster из выпадающего
списка выбираем созданный ранее виртуальный интер-
фейс. Жмем Save VIP, и становятся доступными поля Local
hostname и Remote hostname.
Во втором поле  указываем имя второго хоста Zen LB
и его IP-адрес.
Далее вводим на втором хосте пароль суперпользо-
вателя (root). После указания пароля необходимо выпол-
нить Сonfigure RSA Connection between nodes для установ-
ки соединения между хостами.
И последним действием выбираем из выпадающего спи-
ска тип кластера (Cluster type):
node1 master and node2 backup automatic failback –
это режим, в котором текущий хост будет являться ма-
стером, и все подключения будут проходить через него.
Второй же хост будет находиться в резерве и станет
мастером только при отказе первого, при возвращении
в строй которого, он вновь станет резервным.
node1 or node2 can be masters – все так же, как и в пер-
вом варианте. Единственное отличие в том, что резерв-
ный хост, став мастером, им и останется, даже если
первый хост вернется в строй. Этот вариант подходит
в случае, если оба хоста равны по производительности,
и кто из них будет мастером в тот или иной момент, не-
важно.
Жмем Configure cluster type, и менее чем через минуту
в поле Cluster status появятся сообщения об успешной сбор-
ке кластера и о доступности его членов. После этого все на-
Рисунок 2. Интерфейс консоли управления
системный администратор март 2014
Администрирование
стройки и параметры, включая созданные ранее фермы,
будут воссозданы на втором хосте.
Управлять кластером в дальнейшем необходимо через
созданный для этого виртуальный интерфейс. При отказе
мастера переключение на резервный хост будет выполнено
в течение одной-двух секунд.
***
Подробно изучив существующие сегодня механизмы ба-
лансировки сетевой нагрузки, а также способы обеспече-
ния беспрерывной доступности сервисов, протестировав
на практике возможности программного продукта Zen Load
Balancer и оценив его работоспособность, могу сказать,
что этот продукт является достойнейшим представителем
своего класса. Его бесплатной версии с головой хватит
многим предприятиям для обеспечения доступности корпо-
ративных сервисов.
Удобное и простое управление, а также штатные сред-
ства кластеризации и резервного копирования делают ра-
боту с этим продуктом приятной и практически беззабот-
ной. EOF
1. Домашняя страница Amazon Route 53 – http://aws.amazon.com/
route53.
2. Обзор возможностей Citrix NetScaler – http://habrahabr.ru/
post/177329.
3. Балансировка up-линков с помощью Zen LB – http://michael.
bizow.com/zen-load-balancer.
Ключевые слова: отказоустойчивость, балансировка нагрузки,
кластер.
13
 Администрирование
Визитка
Сергей Болдин, системный администратор
НЭК Укрэнерго, bsergey2@gmail.com
Сладкая парочка,
или Как настроить работу SCCM с WSUS
Рассмотрим основные настройки, возможности, достоинства и недостатки
SCCM 2012 SP1 по управлению обновлениями
Обновление ПО парка компьютеров предприятия играет
важную роль в стабильности и безопасности работы ИТ-ин-
фраструктуры. Здесь основным помощником является роль
WSUS в Windows Server, но такая возможность реализова-
на и в SCCM, которая хотя полностью и не заменяет WSUS,
но расширяет его возможности дополнительным функцио-
налом. WSUS находится уже в долгой эксплуатации на пред-
приятиях, поэтому не будем заострять на нем внимание,
а рассмотрим его совместную работу с SCCM.
SCCM vs WSUS. Достоинства и недостатки
Основная задача WSUS заключается в подмене сервера
Microsoft Update. Процесс обновления можно разделить
на два этапа: получение необходимых данных c Microsoft
Update и предоставление «добытого» материала клиент-
ским компьютерам. Однако не все так гладко, как хотелось
бы. Например, в данной роли отсутствуют функция поиска
по скачанному контенту (для подробного анализа), а также
установка обновлений без ведома пользователя с примене-
нием функции пробуждения компьютера (Wake on Lan).
В свою очередь SCCM получил немалый функционал,
который расширяет возможности и устраняет слабые сто-
роны WSUS. Но, чтобы понять, насколько Configuration
Manager превосходит своего «младшего брата», рассмот-
рим его преимущества:
>> сотрудники компании имеют возможность принимать
участие в обновлениях системы или ПО, при этом про-
стой и удобный пользовательский интерфейс не вызы-
вает у них каких-либо сложностей;
>> поддерживается NAP (Network Access Protection) [1] –
набор правил для дополнительной безопасности кор-
поративной сети, компьютеры, не прошедшие провер-
ку NAP, могут направляться на обновление;
>> предоставление загруженных файлов пользователь-
скому ПК в нерабочее время;
>> функция сохранности устаревших обновлений, чтобы
в дальнейшем по каким-либо причинам возвратиться
к ним;
>> реализован удобный поиск по скачанному контенту;
14
управление
>> обновления могут устанавливаться стороннему софту
совместно с SCUP (System Center Update Publisher) [2].
Выбрав работу с SCCM, мы отказываемся от управления
контентом с помощью WSUS. Так как Configuration Manager
умеет скачивать обновления и предоставлять их клиентским
ПК, эти обязанности он берет на себя. И тут всплывает один
важный недостаток – в SCCM отсутствует возможность по-
лучения метаданных. Поэтому полностью о WSUS забыть
нельзя, и Configuration Manager «сотрудничает» с ним в этом
направлении. Несмотря на имеющиеся минусы, возможнос-
ти SCCM дают более эффективное управление обновлени-
ями, нежели WSUS, поэтому разберемся с основными прин-
ципами работы и настройками некоторых функций.
Требования к SCCM
Для управления обновлениями с помощью Configuration
Manager необходимо выполнить некоторые условия:
>> сервер WSUS должен быть версии 3.0 SP2 или выше [3].
Например, для Windows Server 2008 и выше с ролью
устанавливается версия 3.0 SP1;
>> необходима консоль администратора WSUS, которая
является указателем его местонахождения;
>> должна быть включена служба автоматического обнов-
ления;
>> наличие двух ролей: SUP (Software Update Point), запу-
скающей WSUS и разрешающей использовать его ка-
талог SCCM для сканирования клиентов, а также RSP
(Reporting Service Point), которая отвечает за отчет-
ность;
>> на сервере должно быть достаточно свободного диско-
вого пространства под файлы обновлений. Также нуж-
но учитывать рост папки winsxs [4] на системном диске.
Принцип работы
Сразу отметим, что, отказавшись от управления с помощью
WSUS, ранее созданные GPO использоваться не будут, и не-
которые настройки переопределятся новыми. Итак, для по-
лучения метаданных первым делом Configuration Manager
обращается к WSUS. Каждый сервер имеет свою базу дан-
март 2014 системный администратор
 управление
ных, поэтому для актуальности контента между ними проис-
ходит синхронизация. А чтобы о новинках узнал и клиент-
ский ПК, SCCM (роль Management Point) предоставляет ему
информацию о месте расположения WSUS. Между пользо-
вательским компьютером и WSUS происходит сверка вер-
сий обновлений. Информация о недостающих данных по-
мещается в репозиторий WMI, и формируется отчет. Далее
он отсылается в SCCM (в Management Point), где и попадает
в базу. После этого консоль отображает список доступных
Рисунок 1. Список метаданных
системный администратор март 2014
Администрирование
Возможности SCCM 2012 SP1
предоставляют новый уровень
управления системными
и программными обновлениями
и требуемых обновлений. По одобрению системного адми-
нистратора SCCM скачивает их (ответственность на роли
SUP) и подготавливает для дальнейшего распространения
(занимается роль Distribution Point), а клиенту сообщает-
ся о необходимости «обновиться». После установки нуж-
ных файлов клиент снова отсылает отчет в Configuration
Manager. И только теперь системному администратору мож-
но понять новое состояние софта и операционной системы
пользовательского ПК.
15
 Администрирование
В SCCM реализовано два типа раздачи скачанных дан-
ных. Первый происходит в ручном режиме, который при-
меняется в случае небольшого количества обновлений
или при необходимости тщательного контроля каждого
из них. При этом время работы требуется гораздо большее,
нежели со следующим типом распространения. Ко второ-
му относится автоматический режим, который не требует
к себе особого внимания и времени.
Теперь перейдем от теории к практике. Будем считать,
что WSUS уже функционирует, и разберемся с основными
настройками Configuration Manager.
Подготовка рабочей среды
Сначало инсталлируем роль SUP: заходим в Administration →
Sites → Add Site System Role, заполняем необходимые поля
и активируем Software Update Point. Далее следует настрой-
ка параметров роли, что делается в разделе Configure Site
Components. На вкладке Sync Settings определяем сервер
синхронизации (WSUS или Microsoft). В Classification нужно
указать все или только необходимые типы обновлений (кри-
тические и накопительные, драйверы и сервис-паки и дру-
гие). Products содержит перечень программных продуктов
(Windows 7, Office 2010, Skype и прочие). Затем во вклад-
ке Sync Schedule устанавливаем расписание для синхро-
низации, а в Languages – языковые версии обновлений.
Supersedence Rules позволяет переопределить старые об-
новления новыми, при этом первые будут вычищаться.
Чтобы пользовательский компьютер узнал и в дальней-
шем получил самые «свежие» файлы, нужно произвести
настройку клиентской части. Она включает в себя актива-
цию агента (значение True) и установку расписания скани-
рования обновлений. Для этого заходим в раздел Software
Update, пройдя путь Administration → Client Settings → Default
Client Settings.
Рисунок 2. Отчет
16
управление
Обновления скачиваются не сразу, чтобы не загружать
ненужные файлы, первоначально «добываются» метадан-
ные, которые представляют собой «ссылку» (их характери-
стику).
Получение метаданных происходит при синхрониза-
ции баз между серверами SCCM и WSUS. Данный процесс
происходит автоматически по расписанию либо вручную,
по нажатию кнопки Synchronize Software Updates, кото-
рая находится на панели меню Software Library→ Software
Updates→All Software Updates.
После этого в списке появятся метаданные с разным цве-
товым оформлением иконок. Зеленые относятся к новым
актуальным обновлениям. Оранжевый цвет означает начало
процесса старения. Происходит перекрытие более «свежи-
ми» файлами, устаревающие удаляются не сразу, а имеют
небольшой цикл жизни. Это реализовано для того, чтобы
была возможность их сохранить. Черный говорит о полной
неактуальности существующих данных (см. рис. 1).
По каждому обновлению, выделив его, можно просмо-
треть краткую информацию (ID, описание, дату релиза
и другое), а по второму щелчку мыши в появившемся окне
о нем отобразится исчерпывающая информация.
Об удобствах управления скачанным контентом
Что делать, когда имеется огромное количество записей
и требуется среди них найти необходимые? В этом случае
удобно воспользоваться:
>> поиском по одному или нескольким критериям (по дате,
типу, производителю, продукту, языковой версии, мо-
дели и многим другим), выбор которых появляется
при нажатии на кнопку Add Criteria. А чтобы каждый раз
не создавать один и тот же критерий поиска, его мож-
но сохранить (на панели инструментов кнопка Saved
Searches) и в дальнейшем только вызывать;
март 2014 системный администратор
 управление
>> параметрами отображения, которые несут дополни-
тельную и полезную информацию. Например, скача-
ны файлы или нет, установлены ли дата релиза, тип,
группировка, имя модели и так далее (см. рис. 1). Вклю-
чение их происходит просто: нужно нажать правой
кнопкой мыши, наведя курсор на панель отображения,
и в списке выбрать нужный параметр.
>> группировкой контента для работы только с требуемым
объемом данных. Для этого выделяем найденные мета-
данные и в контекстном меню выбираем пункт Create
Software Update Group.
Теперь нужно получить обновления. Для этого необходи-
мо нажать правой кнопкой мыши на группе и выбрать пункт
Download. По окончании процесса скачивания они будут
иметь статус Yes. На этом подготовка завершена, перейдем
к следующему этапу – распространение.
Управление обновлениями вручную
В контекстном меню группы обновлений выбираем пункт
Deploy. Появляется окно, где нужно ввести большое коли-
чество данных. Рассмотрим самые необходимые парамет-
ры. В разделе General вписываем понятное имя распростра-
нения и выбираем коллекцию компьютеров. В Deployment
Settings особое внимание нужно уделить типу раздачи.
При выборе параметра Required обновления будут уста-
навливаться по требованию системы или ПО, а Available
означает доступность и инсталляцию по необходимости.
После этого настраиваем расписание (раздел Scheduling).
Тут нужно иметь в виду такое понятие, как крайний срок
(deadline time), на основании которого содержимое группы
инсталлируется принудительно. Так, в SCCM обновления
распространяться в открытом виде не могут, они «заворачи-
ваются» в пакет, создание которого происходит в разделе
Deployment Package, присвоив ему имя и указав путь к ска-
чанным файлам. Далее выбираем точку распространения
в Distribution Point и языковые версии в Language Selection.
Некоторые разделы (User Experience, Alerts, Download
Settings, Download Location) с настройками по умолчанию
Рисунок 3. Консоль пользователя
системный администратор март 2014
Администрирование
можно оставить нетронутыми, а при необходимости внести
в них изменения.
Заполнив все необходимые данные,мы с помощью цве-
товой индикации (статус в виде кружка) можем наблюдать
за состоянием процесса раздачи контента: желтый цвет оз-
начает распространение, зеленый – удачное завершение,
а красный свидетельствует о сбое.
Автоматическое распространение
Устранения ручной работы при раздаче обновлений можно
добиться с помощью автоматического режима. Создание
такого правила происходит в разделе Software Library  →
Software Updates → Automatic Deployment Rules вызовом
контекстного меню и выбором пункта Create Automatic
Deployment Rule. В появившемся окне выполняется ряд
тех же настроек, которые производились для ручного режи-
ма, только «все в одном». Таким образом, создается группа
для обновлений, пакет и правило их раздачи.
Troubleshooting
После всех проделанных настроек на сервере SCCM убе-
диться в правильности их работы позволяют отчеты и жур-
налы. Отчет создается в разделе Monitoring → Reporting →
Reports → Software Updates. Задав необходимые парамет-
ры, получаем исчерпывающую информацию (см. рис. 2)
об инсталляции как по всем, так и по каждому обновлению
в отдельности. Количество отчетов гораздо больше, нежели
в WSUS, и они более наглядны. В журналах Windows Server
можно увидеть только поверхностную (общую) информа-
цию серверов WSUS и/или SCCM. Поэтому, пройдя путь
C:\Program Files → Microsoft Configuration Manager → Logs,
файлы SUPSetup.log, WCM.log, wsyncmgr.log, WSUSCtrl.
log помогут увидеть полную картину работы Configuration
Manager относительно обновлений.
Полномочия пользователя
Сотруднику компании доступна консоль SCCM («Пуск →
Microsoft System Center 2012 → Software Center»), в кото-
17
 Администрирование
рой виден перечень необходимых обновлений (см. рис. 3),
что позволяет устанавливать их самостоятельно. Весь про-
цесс заключается в фиксации и нажатии кнопки Install
при ранее выбранном параметре Available. Если был выбран
тип Required, то в консоли для пользователя дополнительно
появится кнопка Scheduling, которая позволяет составить
расписание инсталляции файлов на любое удобное время.
При этом отсутствуют лишние окна с вопросами и настрой-
ками, что позволяет пользователю быть более уверенным
в своих действиях. Если сотрудник не будет устанавливать
обновления, то они применятся сами на основании крайнего
срока. По завершении работы чаще всего требуется пере-
загрузка компьютера, которую можно принять сразу либо
отложить на более подходящий момент. Если установка сис-
темных и программных обновлений не требует временных
рамок, то на этом этапе основные настройки сервера SCCM
можно считать завершенными. Однако такие действия могут
привести к замедлению работы компьютеров в течение тру-
дового дня. Но, подобрав удобное время инсталляции фай-
лов, можно предотвратить эту проблему.
Тихо! Идет работа
В том случае, когда сотрудники компании не принимают уча-
стия в установке обновлений, раздать новинки компьютерам
можно и без их ведома. В этом системному администратору
помогают окна обслуживания [6], которые относятся к од-
ной из функций Configuration Manager. Они позволяют уста-
навливать обновления в заданный период времени и имеют
приоритет (если случаются накладки по времени) перед ра-
ботой без их использования. В ситуации с несколькими ок-
нами обслуживания при отсутствии между ними интервала
происходит их слияние в одно целое.
Настройка приоритетного типа раздачи файлов выполня-
ется в свойствах группы компьютеров во вкладке Maintenance
Windows раздела Asset and Compliance → Overview → Device
Collections. Тут жмем кнопку создания окна обслуживания,
вводим имя, ставим дату старта и начальное/конечное вре-
мя, а также определяемся с расписанием. Например, мож-
Рисунок 4. Создание окна обслуживания
18
управление
но сделать, чтобы операция обновления происходила еже-
дневно в обеденный перерыв (см. рис. 4).
Функция Wake On Lan [7] позволяет произвести «про-
буждение» компьютера, находящегося в режиме сна
или в выключенном состоянии. Данной функцией полезно
воспользоваться при необходимости инсталлировать фай-
лы в нерабочее время. Активация ее происходит в разделе
Deployment Settings фиксацией галочки Use Wake-on-Lan to
wake up clients for required deployment при настройке рас-
пространения обновлений для типа Required.
***
Возможности Configuration Manager 2012 SP1 предоставля-
ют новый уровень управления системными и программными
обновлениями, более гибкую и комфортную работу, нежели
только развернутый WSUS. А системному администрато-
ру будет удобно воспользоваться данным преимуществом.
В результате он получит не только защищенность корпора-
тивной сети, но и повысит свою квалификацию ИТ-специа-
листа. EOF
1. Описание NAP – http://www.winblog.ru/net/1147765128-
07030805.html, http://www.xakep.ru/magazine/xa/120/116/1.asp.
2. Описание SCUP – http://technet.microsoft.com/ru-ru/library/
bb531022.aspx.
3. Требования WSUS – http://www.wikiznanie.ru/ru-wz/index.php/
Wsus_faq.
4. Уменьшение размера папки WinSxS – http://www.outsidethebox.
ms/15272.
5. Описание и установка WUA 3.0 – http://technet.microsoft.com/ru-
ru/library/bb932139.aspx, http://support.microsoft.com/kb/949104.
6. Описание окон обслуживания – http://technet.microsoft.com/ru-
ru/library/bb694295.aspx.
7. Описание Wake on Lan – http://technet.microsoft.com/ru-ru/
library/bb693668.aspx.
Ключевые слова: роль, метаданные, обновления, синхронизация,
распространение, настройки, параметры.
март 2014 системный администратор
 новый дистрибутив Администрирование

Визитка

Ольга Кулешова, МСТ, старший преподаватель центра

компьютерного обучения «Специалист»
при МГТУ им. Н.Э. Баумана, kuleshova@specialist.ru

Microsoft Excel 2013

Работаем быстро и создаем отчеты наглядно
В статье речь пойдет о тех преимуществах, которые получили
пользователи, применяющие программу Microsoft Excel из пакета Microsoft
Office 2013 или Office 365, по сравнению с предшественником – Excel 2010

Microsoft Office 2013 доступен с февраля 2013 года, однако
и сегодня не так часто можно встретить пользователя, ра-
ботающего в этой версии программного обеспечения. В ос-
новном встречается Office 2010 или Office 2007. Возможно,
это связано и с тем, что Office 2013 требователен к версии
операционной системы Windows и может работать только
в Windows 7 или Windows 8, а может, и с низкой информиро-
ванностью о возможностях новой версии, так как многим ка-
жется, что и старые неплохо справляются с поставленными
задачами. Но следует помнить, что нет предела совершенству!
Диаграммы – быстрый способ построения диаграмм
по выделенному диапазону ячеек.
Итоги – по выделенным данным произвести различные
вычисления как по строкам, так и по столбцам: сумма, сред-
нее количество (счетчик), процент от итога, нарастающий
итог. При необходимости для данных одной таблицы можно
делать вычисления как по строкам, так и по столбцам, при-
меняя нужные средства анализа поочередно (см. рис. 1).
Рисунок 1. Расчет процента от итогов с помощью быстрого анализа

Мгновенное заполнение
Для обработки данных по принципу текстовых функций, таких
как объединение, разбиение, извлечение, можно применять
«Мгновенное заполнение». Пользователем задается образец
дальнейшего заполнения путем ввода данных с клавиатуры
в одну ячейку, и после применения мгновенного заполнения
будут получены результаты в остальных ячейках.
Например, если есть три ячейки, в которых располагают-
ся Фамилия Имя и Отчество, то, задавая в четвертой ячейке
образец «Фамилия И.О.», применим команду «Мгновенное
заполнение», и программа все строчки заполнит аналогич-
но. В большинстве случаев такое заполнение позволяет
Рисунок 2. Фильтр значений рядов и категорий
получить результат быстро и без применения каких-либо
формул. Однако не всегда программа может правильно по-
нять задаваемый образец, тогда придется, как и прежде, ис-
пользовать текстовые функции.

Мгновенный анализ
Быстрый анализ таблиц (экспресс-анализ) – это новая
возможность Excel 2013, которая позволяет с легкостью
увидеть, как будут выглядеть данные, если к ним приме-
нить условное форматирование, спарклайны, диаграммы
или расчет итогов.
Форматирование – возможность применения к выделен-
ным ячейкам элементов форматирования, таких как гисто-
грамма, набор значков, цветовая шкала. Быстро выделять
значения больше указанного, а также первых (наиболь-
ших) 10% от количества данных.

системный администратор март 2014 19

 Администрирование
Таблицы – автоматически происходит преобразование
диапазона ячеек в таблице с применением стиля оформле-
ния таблиц, установки кнопок фильтра для удобства выбора
данных и выполнения сортировки.
Спарклайны – построение миниатюрных графиков, рас-
полагающихся в одной ячейке. Позволяют выявить тен-
денции изменения данных, однако не могут заменить пол-
ноценные диаграммы, так как показывают лишь общую
закономерность, без указания конкретных значений.
Как правило, каждый из типов быстрого анализа под-
разумевает его использование с параметрами, заданными
разработчиком. Для более тонких настроек требуется более
детальное изучение каждого вида анализа данных.
Формулы
В процессе написания формул, выделяя ячейки или диапа-
зоны исходных данных, теперь стало легче увидеть данные,
так как границы ячейки или диапазона выделяются более
толстой линией, а сама область заполняется прозрачным
цветом оттенка границы.
Рисунок 3. Пузырьковая диаграмма с подписями данных
Рисунок 4. Отчет PowerView по данным одной таблицы
20
новый дистрибутив
Новинки в диаграммах
Реализована новая возможность – просмотр получаемой
диаграммы до момента ее построения. Это позволяет мно-
гим пользователям быстрее сделать выбор для наглядности
отображаемых данных.
Можно строить диаграммы, как и ранее, выбирая опре-
деленный вид диаграммы, а можно воспользоваться коман-
дой «Рекомендуемые сводные таблицы» и просмотреть,
как будут выглядеть данные в различных графических
представлениях. Улучшена возможность создания комбини-
рованных (смешанных) типов диаграмм – уже на этапе по-
строения можно выбрать для каждого ряда желаемый тип,
а также решить, по какой оси будет идти построение: ос-
новной или вспомогательной. Теперь настройка происходит
по принципу «все под рукой». Стоит только выделить диа-
грамму, как в правом верхнем углу появляются три кнопки:
«Элементы диаграммы», «Стили диаграммы» и «Фильтры
диаграммы».
В прошлых версиях для работы с различными элемента-
ми диаграммы использовались команды с вкладки «Макет»,
в 2013-й версии ее убрали и заменили кнопкой «Элементы
диаграммы». С помощью кнопки «Стили диаграмм», можно
быстро изменить как стиль самой диаграммы, так и выбрать,
какие цвета используются для отображения рядов.
Впервые в диаграммах реализована возможность филь-
трации значений рядов и категорий (см. рис. 2).
Теперь при построении пузырьковых диаграмм средст-
вами программы можно сделать подписи для пузырьков
(см. рис. 3).
Поскольку для построения пузырьковых диаграмм не-
обходимы три ряда данных: значения горизонтальной
и вертикальной осей и значения пузырьков, то ранее
не было возможности отобразить подписи рядов (названия).
В 2013‑й версии Excel реализована возможность указать ди-
апазон ячеек, на основании которых нужно сделать подписи
на диаграмме.
Новинки в таблицах
Преобразуя обычный диапазон ячеек в «Таблицу», можно
получить новый вид фильтра – «Срезы». Это интерактивные
фильтры для полей таблицы, которые размещаются на ли-
сте и позволяют быстро и наглядно выполнять фильтрацию
данных, а также показывать связь данных одного поля
(столбца) с другими. Срезы ускоряют и упрощают филь-
трацию данных, но полностью ее не заменяют. Впервые
их можно было встретить при работе со сводными таблица-
ми в Excel 2010-й версии, теперь же их можно использовать
и при работе с таблицами.
Новинки в сводных таблицах
Те, кому выбор подходящих полей при создании отчета ка-
жется трудной задачей, теперь могут воспользоваться ко-
мандой «Рекомендуемые сводные таблицы». Excel анализи-
рует исходные данные и рекомендует несколько способов
подведения итогов – предоставляя их для анализа и позво-
ляя предварительно просмотреть макеты отчетов, чтобы вы-
брать подходящий.
Добавился новый инструмент фильтрации дат – это «Вре-
менная шкала» с возможностью выбора группировки дат
в годы, кварталы, месяцы, дни. Из минусов – можно выби-
март 2014 системный администратор
 новый дистрибутив
рать одно значение или смежные значения, произвольный
выбор значений невозможен.
Появился анализ табличных данных с использованием
«Модели данных». Источником может быть любой диапазон
данных, но лучше применять именованный диапазон или таб-
лицу. Модель данных расширяет возможности анализа.
Получив результат расчета, порой необходимо его проа-
нализировать по составляющим. В этом случае можно изме-
нить макет отчета самостоятельно или при использовании
модели данных применить новый инструмент – «Экспресс-
просмотр» (экспресс-тенденции) с детализацией данных.
Например, получив отчет с суммами продаж по каждому
наименованию, можно быстро выбрать интересующее поле
для детализации до региона, дилера и т.д.
Добавилась операция при обработке с применением мо-
дели данных – «Число различных элементов». С ее помощью
подсчитывается, сколько уникальных значений есть в исход-
ной таблице при каких-нибудь критериях. Например, можно
рассчитать по каждому товару, сколько всего единиц было
поставлено, сколько всего было поставок, а также узнать
количество уникальных поставок (заказов) – т.е. заказов
с различным количеством единиц по каждому товару.
Использование моделей данных позволяет строить отчеты
по нескольким моделям (таблицам) с созданием связей в про-
цессе работы в отчете. Нет необходимости предварительно
«связывать» несколько таблиц между собой с применением
формул, увеличивая как размер самих таблиц, так и размер
файла. В самой программе Excel при построении отчетов ре-
ализованы принципы реляционных баз данных – информация
хранится в плоских таблицах, которые между собой могут
быть связаны. Однако в отчетах с использованием моделей
есть и ряд ограничений: нельзя будет применять группировку
полей и создавать вычисляемое поле.
PowerView и PowerPivot
В Excel 2013 можно выделить несколько инструментов
для бизнес-аналитики – это PowerPivot и PowerView, кото-
рые позволяют хранить, обрабатывать и наглядно представ-
лять огромные массивы данных.
системный администратор март 2014
Администрирование
В Microsoft Office 2013 новые
возможности делают работу
более удобной по сравнению
с предыдущей версией
PowerPivot сначала появился в Excel 2010 как надстрой-
ка, которую было необходимо дополнительно скачивать
и устанавливать. В 2013-й версии он уже является над-
стройкой в программе, поэтому его нужно будет всего
лишь подключить. PowerPivot позволяет обрабатывать дан-
ные из внешних источников, в которых количество записей
в таблицах значительно превышает возможности по коли-
честву строк в Excel. Источников может быть множество,
между ними можно создавать связи, а также выполнять
различные вычисления. Сама обработка может показаться
пользователю более сложной на фоне работы с таблицами
Excel, ибо используется множество подходов, как и при ра-
боте с базами данных.
PowerView – это отчеты (см. рис. 4), которые можно по-
строить по данным одной или нескольких таблиц с созда-
нием связи; также он дает информацию как в табличном,
так и в графическом виде. В одном отчете можно построить
множество вариаций, причем при фильтрации получается
прекрасная визуализация данных. Например, выбирая
на линейчатой диаграмме название «набор «Прелесть»,
можно сразу увидеть в таблицах, сколько каждый клиент
потратил денег на этот товар, а также суммы продаж в каж-
дом представленном городе. При этом круговая диаграм-
ма показывает общие суммы продаж всех наименований
(фон) в каждом городе, и яркий фрагмент в центре – значе-
ния для выбранного товара.
Такую прекрасную визуализацию данных можно по-
строить в считанные мгновения! Это не может не радовать
пользователя, постоянно тонущего в огромных массивах
данных, которые требуют наглядности и легкости пони-
мания.
***
Я выбрала Office 2013 сразу, поскольку новые возможно-
сти позволяют сделать работу в программе более удобной
по сравнению с предыдущей версией, и чем больше ты ра-
ботаешь, тем лучше это понимаешь. EOF
Ключевые слова: Office 2013, Excel 2013, офисный пакет.
21
 Администрирование
Визитка
Алексей Бережной, независимый консультант, системный
архитектор, специалист по системам виртуализации
и резервного копирования, alexey.berezhnoy@tech-center.com
Резервное копирование
для больших и маленьких
Сравним различные типы архитектуры систем резервного копирования
для предприятий разного масштаба и выдадим рекомендации для построения
и модернизации систем сохранения данных
Очень часто возникает ситуация, когда существующая сис-
тема резервного копирования по тем или иным характери-
стикам не отвечает нуждам предприятия. Проблема либо
кроется в «первородном грехе», то есть в том, что с самого
начала были допущены промахи в разработке архитектуры,
либо в прошлом система удовлетворяла всем нуждам ИТ,
но требуются определенные изменения, чтобы привести
в соответствие быстрорастущую инфраструктуру и кон-
сервативную по своей природе систему резервного копи-
рования.
Основная цель статьи – рассказать о различных типах
архитектуры и о том, какую топологию лучше выбирать
и на что ориентироваться при модернизации.
Еще раз о топологии резервного копирования
Топология резервного копирования является системообра-
зующим фактором, который накладывает отпечаток на вы-
бираемые архитектуру и метод работы.
Как я уже ранее писал в статье [1], существуют два ос-
новных типа топологии систем резервного копирования:
Рисунок 1. Децентрализованная топология резервного копирования
22
бэкап
>> децентрализованная;
>> централизованная.
Децентрализованная топология представляет собой ар-
хитектуру, при которой на каждый объект резервного копи-
рования (например, сервер, содержащий ценные данные)
устанавливается полная самостоятельная копия программы
для сохранения данных.
Прекрасным примеров такой топологии является ис-
пользование встроенных средств в операционную систе-
му Windows: ntbackup для Windows Server 2003 и Windows
Backup Service для Windows Server 2008 и выше. Эти реше-
ния предполагают, что предустановленное программное
обеспечение собирает с сервера данные, указанные в на-
стройках задания и создает их копию на удаленном храни-
лище (см. рис. 1).
Централизованная схема более сложна. На выделенный
сервер устанавливается центральный программный модуль,
через который осуществляется управление сбором данных,
а на объекты, подлежащие резервному копированию, – спе-
циальные программы-агенты (см. рис. 2). Для хранения мо-
Рисунок 2. Централизованная топология резервного копирования
март 2014 системный администратор
 бэкап Администрирование

Цель статьи – рассказать какую

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

гут использоваться и файловый сервер, и сетевое храни- серверу напрямую. Кроме того, необходимость избегать
лище. Если ИТ-инфраструктура строится на базе решений одновременной работы большого числа заданий приводит
от Microsoft, то очень хорошим выбором будет файл-сер- к тому, что расчет времени и выявление таких «наложений»
вер на бесплатной UNIX-like ОС, например, Linux или BSD, в расписании заданий вручную при большом количестве
с установленным Samba или FTP-сервером. В этом случае объектов практически невозможно. В этом случае потре-
различие в платформах может послужить дополнительной буется использование некоей единой консоли управления,
гарантией безопасности в случае вирусного заражения что означает переход на централизованную топологию.
или инсайдерской атаки.
Также применяется смешанная топология, когда исполь- Архитектура системы резервного копирования
зуются элементы централизованной и децентрализованной крупного предприятия
составляющей. Обычно это происходит, когда специали- Сейчас мы вместо того, чтобы рассматривать так называе-
зированные агенты не в состоянии обеспечить резервное мый средний или «middle» уровень, сразу перейдем к рас-
копирование данных всех сервисов и приходится использо- смотрению системы резервного копирования уровня боль-
вать некоторые ухищрения. Классическим примером явля- шого предприятия (Enterprise). Будет легче зайти с другого
ются предварительная выгрузка данных базы SQL-сервера полюса, чтобы показать принципиальное различие между
в промежуточный файл и его последующее копирование начальной и конечной ступенью.
обычными средствами резервирования файл-сервера. Естественно, решения масштаба крупного предприятия
принципиально отличаются от начального уровня. Поэтому,
Архитектура для небольших инфраструктур если на малых инфраструктурах часто применяется децен-
У небольших ИТ-инфраструктур малого и среднего бизне- трализованная топология, то на уровне Enterprise – обяза-
са как раз и применяется децентрализованная схема. Чаще тельно централизованная. Нет смысла экономить на лицен-
всего применяют схему с единой точкой сбора данных, на-
пример, некое сетевое хранилище, куда программы резерв-
Рисунок 3. Схема резервного копирования небольшого предприятия
ного копирования, установленные на серверах, складывают
копии (см. рис. 3). Функции администратора резервного ко-
пирования, как правило, ограничиваются установкой и на-
стройкой специализированного программного обеспечения
на серверах, подготовкой сетевого хранилища, вниматель-
ным составлением расписания, чтобы задания по возмож-
ности не пересекались между собой по времени.
У этой схемы есть единственное преимущество: деше-
визна и возможность создания подобной системы резерв-
ного копирования из подручных средств. При этом суще-
ствует немало минусов, таких как трудности организации
транспортировки резервной копии для хранения за терри-
торию предприятия (off-site), а также сложности управления
и масштабирования. Когда объектов станет слишком мно-
го, администратор резервного копирования уже не сможет
управлять данной системой, просто подключаясь к каждому

системный администратор март 2014 23

 Администрирование
зиях программ-агентов резервного копирования, потому
что потеря данных обойдется колоссальными убытками.
Изменяется и сама идеология построения системы.
Обычно применяется трехуровневая схема. На самом верх-
нем уровне находятся объекты управления системой ре-
зервного копирования: выделенный сервер со специализи-
рованным ПО и консолью управления. Копия консоли может
быть установлена на компьютер администратора резервно-
го копирования для удобства работы. Именно с этого уровня
обычно начинается установка системы резервного копиро-
вания по принципу сверху вниз (см. рис. 4).
Следующий «слой» – это уровень хранения резервных
копий. На нем находятся так называемые медиасерверы,
или серверы хранения данных. Они используются для трех
целей: подключение внешних накопителей и управление
ими, непосредственное хранение резервных копий в режи-
ме файл-сервера, а также в качестве промежуточного, или,
как его еще называют, кэш-сервера для временного хране-
ния копии перед ее постоянной записью на ленту. Исполь-
зование такого сервера ускоряет процесс записи и восста-
новления данных и позволяет более экономно использовать
Рисунок 4. Система резервного копирования крупного предприятия
Рисунок 5. Система резервного копирования среднего предприятия
24
бэкап
«окно бэкапа» (предпочтительное время для запуска зада-
ний резервного копирования). В рамках Enterprise-решения
управление резервными копиями, временными носителями
производится через консоль управляющего сервера. Под-
черкну: все операции, включая такие задания, как форма-
тирование носителей, извлечение ленточных картриджей
из считывающих механизмов и так далее. При этом даже
если используемое оборудование позволяет самостоятель-
но управлять носителями, делать это не рекомендуется,
за исключением аварийных ситуаций. Проблема заключает-
ся в том, что программа управления резервным копирова-
ние может «не знать» о производимых действиях непосред-
ственно на оборудовании и выдавать ошибку или выполнит
нежелательные действия, например, сотрет ценную резерв-
ную копию.
На самом нижнем – третьем – уровне находятся програм-
мы-агенты резервного копирования. Именно они собирают
данные, которые мы хотим сохранить, и заботливо склады-
вают их на системах хранения медиауровня. А само управ-
ление агентами производится опять же из системы управле-
ния системой резервного копирования, то есть из консоли
предприятия.
Для чего нужен весь этот «огород»? Дело в том,
что при разрастании инфраструктуры администратор ре-
зервного копирования не в состоянии вручную отследить
все задачи, политики, номера носителей и другую информа-
цию касательно всей системы резервного копирования. Вся
эта рутина перекладывается на управляющую часть backup-
системы. В ведении администратора остаются только функ-
ции настройки заданий и мониторинг событий. Все осталь-
ные задачи, включая управление носителями, оповещение
о результатах выполнения заданий или восстановления,
проверки целостности копии (и даже антивирусной провер-
ки для некоторых систем) и так далее, возлагаются на ав-
томатизированный центр управления системой резервного
копирования уровня предприятия.
При такой организации можно легко делегировать полно-
мочия, например, назначив роль оператора резервного ко-
пирования, который может поменять записанные носители
на подлежащие перезаписи, запустить-остановить задание,
восстановить данные из копии, но не имеет прав на полное
управление системой. Таким образом, можно решить мас-
су проблем начиная с тех, что связаны с уходом в отпуск
или на больничный администратора резервного копирова-
ния, и заканчивая освобождением квалифицированных спе-
циалистов для более эффективного использования челове-
ческих ресурсов.
Иногда используются некоторые дополнительные эле-
менты, например, специализированные серверы для раз-
вертывания программ-агентов под ту или иную платформу,
сетевые хранилища, серверы для мониторинга и построе-
ния отчетов, но их присутствие просто расширяет данную
архитектуру в плане удобства использования и повышения
эффективности. В основе так или иначе все равно остается
трехуровневая схема и централизованная топология.
На очень крупных предприятиях встречается распреде-
ленная система резервного копирования, при которой от-
дельные трехуровневые структуры объединены между собой
в одну сеть взаимодействия. При этом один из управляющих
серверов может стать центральным узлом, через который
март 2014 системный администратор
 бэкап
администратор контролирует всю распределенную инфра-
структуру. Такая схема применяется при наличии у пред-
приятия филиалов, а также при использовании резервного
центра обработки данных (ЦОД). В этом случае можно даже
говорить о некоей четырехуровневой модели управления.
Но такие «монстры» встречаются нечасто в первую очередь
из-за высоких затрат на подобную архитектуру.
Архитектура для среднего уровня
Архитектура среднего уровня предполагает двухуровневую
структуру. В отличие от крупных предприятий здесь управ-
ление совмещено с медиасервером, а программы-агенты
так и остаются на своем нижнем уровне (см. рис. 5).
На среднем уровне предполагается использовать цен-
трализованную топологию, но часто из-за неполноты
или недоработки программных продуктов приходится вы-
кручиваться, организуя смешанный вариант. Эти системы
получили довольно широкое распространение в первую
очередь из-за ошибочной оценки их возможностей в бо-
лее отдаленной перспективе. Получается, что на стартовом
уровне внедрение такой архитектуры вводит предприятие
в ощутимые затраты, что побуждает его держаться до по-
следнего за уже внедренное решение, даже в ущерб акту-
альности и эффективности.
На мой взгляд, применение систем резервного копирова-
ния среднего уровня уместно, когда есть некая уверенность,
что бизнес не вырастет больше определенного «потолка».
Например, отдельный самостоятельный филиал крупной
компании со своим штатом управления и специфичными
бизнес-процессами. Или торговая сеть в небольшом горо-
де вдали от транспортных артерий и крупных населенных
пунктов.
Рассмотрим наиболее перспективный вариант для посте-
пенного развития системы резервного копирования по прин-
ципу «от простого к сложному».
Проблема выбора при организации системы
резервного копирования
Разумеется, идеальный вариант – с самого начала приобре-
сти специализированное решение резервного копирования
от известного производителя, с централизованной тополо-
гией, возможностью делегирования полномочий бэкап-опе-
ратору и так далее.
К сожалению, бизнес, находящийся в стадии первона-
чального развития, может не располагать необходимыми
финансовыми средствами для приобретения такой серьез-
ной и дорогой системы.
Поэтому чаще всего используют некую систему началь-
ного уровня с децентрализованной или смешанной тополо-
гией, построенную на бесплатном решении. Впоследствии
планируется переход на систему более высокого уровня
развития уже с централизованной топологией.
Если же говорить о выборе системы на момент такой
модернизации, то я настоятельно рекомендую сразу пред-
почесть Enterprise-решение. Да, вот так сразу: от систе-
мы резервного копирования начального уровня до уровня
Enterprise. Дело в том, что переход от решения среднего
уровня до уровня крупного предприятия не менее сложен,
чем любой другой. При этом нахождение на данном этапе
может затянуться на непростительно долгий срок из-за рас-
системный администратор март 2014
Администрирование
плывчатой границы между этими уровнями. Если уход от ре-
шений начального уровня происходит, когда администратор
резервного копирования начнет терять управление своей
системой, то пограничную дату жизненно необходимо-
го перехода от среднего уровня до крупного предприятия
определить довольно трудно. Чаще всего администраторы
резервного копирования и руководство ИТ-инфраструкту-
рой руководствуются принципами «работает – не трогай»
и «пока вроде все устраивает». К сожалению, ждать, когда
решение само себя исчерпает, чревато переходом систе-
мы в нерабочее состояние. Чем дольше затягивается ожи-
дание, тем вероятнее, что ИТ-ифраструктура останется
без рабочей резервной копии в момент аварии.
Помимо всего прочего, такие переходы обходятся не-
дешево и в финансовом плане. В итоге все происходит
по принципу «скупой платит дважды».
В то же время при покупке Enterprise-решения обычно
не требуется производить некую массовую закупку лицен-
зий для программ-агентов «на вырост», большого количе-
ства медиасерверов и так далее. Можно вначале купить
ядро системы резервного копирования из управляющей
части, одного медиасервера и небольшого числа программ-
агентов для критичных сервисов, а уже потом постепенно
расширять архитектуру по мере роста ИТ-инфраструктуры
в целом.
В этом случае стоимость полноценного Enterprise-
решения будет ненамного выше, чем системы среднего
уровня. Мало того, на данном этапе можно, скрепя сердце,
пойти на компромисс и организовать вначале смешанную
топологию, при которой копирование критичных сервисов
выполняли бы специализированные агенты, а некритич-
ных – встроенные средства резервного копирования. Глав-
ное – заложить нормальную масштабируемую архитектуру
с учетом дальнейшего развития бизнеса.
Поэтому лучше не искушать судьбу и внедрять систему
уровня крупного предприятия сразу, как только бизнес по-
казал устойчивый рост и вышел из состояния стартапа.
***
В этой статье мы рассмотрели классификацию систем ре-
зервного копирования по уровням. Очевидно, что рассма-
тривать организацию сохранения данных можно только
в привязке к нуждам бизнеса и специфике предприятия.
В то же время нельзя идти на поводу «экономии на спичках».
Своевременная модернизация способна предотвратить бу-
дущие проблемы, а бесконечное откладывание принятия
решения о переходе на систему, адекватную растущему
предприятию, может стать причиной ситуации, когда бизнес
остался без резервных копий и потерял крупные суммы де-
нег из-за необходимости проводить миграцию уже разрос-
шейся инфраструктуры. EOF
1. Бережной А. Резервное копирование. Теория и практика. Кра-
ткое изложение. //«Системный администратор», №2, 2010 г.,
приложение «БИТ» –http://bit.samag.ru/archive/article/1074.
2. Бережной А. Учебный фильм «Некоторые вопросы резервно-
го копирования» – http://www.youtube.com/watch?v=KciuKreyM
3w&feature=youtu.be.
Ключевые слова: резервное копирование, архитектура.
25
 Администрирование
Визитка
Дмитрий Андриенко, инженер-программист,
ООО «Ютел», г. Иркутск, andrienco.dmitry@gmail.com
Мобильная торговля
Рассмотрим на примере компании, занимающейся оптовой торговлей соками,
как можно автоматизировать работу торговых представителей
Компании, занимающейся оптовой торговлей, необходимо
реализовывать закупленную у производителей продукцию,
иначе залежавшийся на складах товар будет приносить за-
траты.
Классическая схема оптовой торговли подразумевает
найм менеджером торговых представителей, которые обхо-
дят розничные торговые точки и предлагают товары в соот-
ветствии с прайсом. Если клиента удалось уговорить кпить
товар, торговый представитель делает заявку, которую при-
носит оператору, вносящему данные в информационную
систему.
Обзор рынка и конкурентных преимуществ
С развитием информационных технологий некоторые оп-
товые компании начали прибегать к автоматизации, заку-
пая программное и аппаратное обеспечение и интегрируя
их в свою ИТ-инфраструктуру. Совокупность же технологий,
программ и аппаратного обеспечения для автоматизации
называется мобильной торговлей или реже мобильными
продажами.
Рисунок 1. Мобильное приложение Рисунок 2. Мобильное приложение
26
автоматизация
Давайте кратко рассмотрим причины, по которым мо-
бильная торговля стала доступна оптовым компаниям:
>> Появление на рынке относительно недорогих смарт-
фонов и планшетов, которыми можно «вооружить»
каждого торгового представителя.
>> Унификация мобильных ОС и появление доступных ин-
струментов разработки приложения под такие ОС, сей-
час на рынке имеются три мобильные ОС – это Google
Android, Apple iOS и в меньшей доле Microsoft Windows
Mobile.
>> Удешевление доступа в сеть Интернет операторами се-
тей GSM, что дает возможность выходить в Интернет
с мобильного устройства без больших денежных зат-
рат.
>> Развитие поддержки технологии глобального позицио-
нирования GPS в мобильных устройствах.
>> Повышение общей компьютерной грамотности руково-
дителей и работников торговли.
Рассмотрим преимущества, которые дает мобильная тор-
говля оптовой компании.
Рисунок 3. Мобильное приложение Рисунок 4. Служба обмена данными
март 2014 системный администратор
 автоматизация Администрирование

>> Просмотр списка цен на товары – экономия на печати Разработчик также заявляет о скорой доступности при-
прайсов, необходимости поддержки их актуальном со- ложения под iOS, но на момент написания статьи у него
стоянии. были проблемы по добавлению приложения в App Store,
>> Просмотр свободных остатков товаров на складе – так что приложение работает только под ОС Android.
нет необходимости уточнять это по телефону. После установки запускаем приложение, вводим лицен-
>> Возможность просмотра задолженности конкретного зионный код.
розничного покупателя. Видим «вкладочный» интерфейс, мы находимся
>> Руководитель продаж может отслеживать на карте пе- на вкладке «заказы», переключения осуществляются
ремещение торговых представителей. сверху на панели вкладок. Состав вкладок можно выбирать,
>> Возможность сократить расходы на операторов, вво- как в настройках мобильного устройства, так и расширения,
дящих заявки клиентов в вашу информационную сис- интегрированного в 1С (см. рис. 1- 3).
тему.
Сегодня мобильная торговля образовала свой неболь-
Рисунок 5. Конфигурация с префиксами
шой рынок, на котором действует несколько компаний, под-
держивающих определенные технологии и схемы. Наибо-
лее популярные:
>> Ассистент торговли от antirius.org.
>> Мобильный менеджер от компании «Автоматизация
бизнеса».
>> TopLine Мобильная торговля.
>> Smartup.
>> Агент Плюс.
>> Агентоид.
>> Айагент.
>> АСУМТ ОПТИМУМ CDC (группа компаний).
>> АСМТ Наполеон.
>> Меркурий.
>> Моби-С.
>> Пан Агент.
>> Флюгер-Продажи.
>> AkiTorg.
>> SalesWorks.
>> ST-Мобильная Торговля (ГК Системные Технологии).
>> PalmOrder.
>> Remote Sales Agent (RSA).
>> «Мобильный Агент» на Android и Windows Mobile от ком-
пании «9Бит».
>> I-MARKT на Android и Windows Mobile от компании
«АЙМАРКТ».
>> Assistex. Облачный сервис мобильной торговли.
Сегодня мы будем рассматривать вариант с внедрением
от «Агент Плюс» [1].

Установка и настройка системы

Обмен данными между информационной системы и кли-
ентом мобильной торговли проходит через сеть Интернет
по специальному протоколу, использующему сетевой порт
TCP/5555.
Для корректного обмена необходимо настроить роутер
и брандмауэр, то есть пробросить порт 5555 и открыть со-
единения до сервера с установленной информационной
системой.
Рисунок 6. Новое меню в интерфейсе
Также требуется реальный статический IP-адрес для сети,
который будет вводиться в настройках на каждом мобиль-
ном устройстве.
Теперь устанавливаем на каждое мобильное устройство
приложение от «Агент Плюс». Распространяется оно в виде
*.apk-файла. Это можно сделать через диспетчер файлов,
предварительно скопировав его на внутреннюю память
или SD-карту.

системный администратор март 2014 27

 Администрирование
Подробные скриншоты мобильного приложения можно
посмотреть на сайте «Агент Плюс» [2], разработчик также
предоставляет демоверсию мобильного приложения с огра-
ниченным функционалом, ее также можно скачать с сай-
та [3].
На серверную часть устанавливается специальное при-
ложение «Агент Плюс: Служба обмена данными», которое
можно скачать с [4], после установки у нас появляется уста-
новленная служба, которая будет отвечать за обмен данны-
ми с мобильными устройствами.
Рисунок 7. Настройка параметров приложения
Рисунок 8. Настройка торговых агентов и представителей
28
автоматизация
Служба прослушивает порт 5555, так что напоминаю вам
еще раз, необходимо создать соответствующие правила
для брандмауэра.
Настройка правил производится через панель управ-
ления (см. рис. 4), в пункте «Папка обмена» указываем от-
дельную папку, в нее будет происходить выгрузка и загрузка
файлов обмена для каждого мобильного устройства в фор-
мате xml.
Интеграция с информационной системой, в нашем слу-
чае – «1С:Предприятие 7.7 конфигурация. Комплексная вер-
март 2014 системный администратор
 автоматизация
сия 4.5», происходит путем установки расширения в теку-
щую конфигурацию.
Чтобы выполнить процесс установки, необходимо с сай-
та разработчика [4] скачать тестовую конфигурацию, взять
*.md-файл (для 1С 8 *.cf) и через функцию «Сравнить/
Объединить» в режиме конфигурации добавить объекты
от «Агент Плюс», в моем случае они имеют префикс кпк
(см. рис. 5).
Разработчик готовит расширение под конфигурацию
«Управление торговлей для платформы 8.2» и «Торгов-
ля и склад для платформы 7.7», но данные модули можно
успешно интегрировать и с другими, например, комплекс-
ной для 7.7, как в нашем случае, сделав небольшие дора-
ботки.
После интеграции запускаем 1С в режиме предприя-
тия и видим новый пункт меню в интерфейсе (см. рис. 6),
для платформы 8.1 и «Управления торговлей версии 10»
меню будет выглядеть примерно так же, для «Управления
торговлей 11 на платформе 8.2» с управляемыми формами
это будет отдельная плитка.
Настройка расширения мобильной торговли начинается
с пункта «Настройка параметров для мобильного приложе-
ния» (см. рис. 7). Пристальное внимание нужно обратить
на настройки обмена, где требуется указываем порт и IP-
адрес приложения обмена данными, которое мы устанавли-
вали ранее.
Остальные настройки не так важны для работоспособно-
сти системы, они уточняют, какие данные выгружать из ин-
формационной системы, а какие нет.
При изменении настроек необходимо каждый раз гене-
рировать файл для службы обмена, это делается с помо-
щью обработки «Генерация файла настроек для «Агент
Плюс СОД», чтобы открыть ее, переходим в «Меню →
Агент Плюс → Обработки → Генерация настроек для Агент
Плюс СОД».
После этого в папку обмена добавляется требуемый нам
xml-файл с настройками.
Теперь необходимо ввести в систему все мобильные уст-
ройства, на которые мы установили приложения от «Агент
Плюс» и которые закрепили за торговыми представите-
лями. Для этого переходим в пункт «Меню → Справочни-
ки  → Агенты» и добавляем всех торговых представителей
(см. рис. 8).
Со всех мобильных устройств вам нужно собрать иден-
тификаторы, без них обмена данными не будет, чтобы
это сделать, переходим в настройки мобильного прило-
жения и выбираем пункт «Информация», там выписываем
идентификатор.
Выглядит он примерно так: 1C9B5F71-2E9D-0976-3836-
353530393031, далее все просто: в настройках переходим
в пункт «Мобильное устройство» и создаем для каждого
агента мобильное устройство с соответствующим иденти-
фикатором.
Теперь для обмена необходимо произвести настрой-
ку-выгрузку по «Фирмам», «Типам цен», «Номенклатуре»
и «Складам», для этого переходим в «Меню → Справочни-
ки  → Настройки фирм», указываем в поле таблицы «Вы-
гружать» галочку для нужных позиций. На этом базовые на-
стройки закончены, можно переходить к процессу обмена
данными.
системный администратор март 2014
Администрирование
Для обмена запускаем обработку «Обмен данными
с мобильным устройством», которая находится в пункте
«Меню  → Агент Плюс → Обработки → Обмен данными»
(см.  рис. 9).
Нажимаем на кнопку «Выгрузить», и начинается выгруз-
ка данных в формате xml, файлы попадают в папку обмена
в подпапку агента.
Для загрузки данных от мобильных приложений необхо-
димо нажать на кнопку «Загрузить», после окончания про-
цесса в мобильном приложении произвести настройки об-
мена данными.
Для этого вызываем контекстное меню, переходим в пункт
настройки, настройки обмена данными, вводим внешний ре-
альный IP-адрес, порт и сохраняем.
Далее загружаем данные в мобильное устройство пунк-
том «Загрузить» (в мобильном приложении), процесс может
продолжаться до 10 минут в зависимости от скорости кана-
ла и размера базы данных, для выгрузки данных нажимаем
пункт меню «Выгрузить».
***
Технологии автоматизации в большинстве решений
по мобильной торговле не отличаются от приведенной
выше, как и, собственно, процесс настройки.
Развертывание системы трудоемкое, и требует от специ-
алиста знаний в области системного администрирования,
программирования, а также принципов торговли для кон-
сультации заказчика и обучения работе с системой торго-
вых представителей. EOF
1. Компания Агент Плюс – http://www.agentplus.ru.
2. Скриншоты мобильного приложения – http://www.agentplus.ru/
agentplus/android/screens.
3. Демоверсия мобильного приложения – http://www.agentplus.ru/
downloads/apmtdemo.
4. Агент Плюс: Служба обмена данными – http://www.agentplus.ru/
downloads/#ms.
Ключевые слова: мобильная торговля, обмен данными, мобильные
приложения.
Рисунок 9. Обработка – обмен данными
29
 Безопасность
Визитка
Вячеслав Медведев,
старший аналитик отдела развития компании «Доктор Веб»
Кому уходят СМС?
Разговоры о том, что Интернет все больше входит в нашу жизнь, наверное, уже давно
набили оскомину. Но, хотим мы этого или нет, это реальность
Возможность получения нужной информации, легкость об-
щения, покупки в один клик, управление своими финанса-
ми – никто не будет отрицать, что все это не только удобно,
но и приятно. Но вот беда: не все, что продается под видом
меда, действительно им является. Рост удобства не сопро-
вождается ростом безопасности. Статистика безжалостна:
большинство сайтов и приложений так или иначе содержит
уязвимости.
Вредоносные программы для платформы Android –
это не миф. При этом можно утверждать, что угрозы для мо-
бильных устройств по целому ряду причин гораздо опаснее
своих собратьев, созданных для обычных компьютеров.
>> Операционные системы для мобильных устройств,
создававшиеся изначально исключительно для мак-
симально удобного личного пользования и работы
на достаточно слабых аппаратных конфигурациях,
не имеют в своем составе развитых средств без-
опасности – возможности разделения прав доступа
к различным объектам, ограничения по установке при-
ложений, иных ограничений из обязательного для без-
опасности списка родительского контроля.
>> Смартфоны (да и многие планшеты) снабжены виде-
окамерой, микрофоном, средствами позиционирова-
ния. Это позволяет злоумышленникам контролировать
каждый шаг жертвы и следить за ее личной жизнью –
большинство домашних компьютеров не дают таких
возможностей для слежки. Более того, опасность мо-
жет предоставлять даже аккумулятор: еще в 2011 году
исследователь Чарли Миллер сообщал о возможно-
сти перепрограммирования аккумуляторного микро-
контроллера в целях перегрева батареи.
>> Как правило, смартфоны подключаются к сети Ин-
тернет (а для чего они еще нужны?), не имея даже
средств защиты, которые считаются необходимыми
для обычных компьютеров, и это тоже не усиливает
их безопасность.
Добавим к списку проблем и то, что пользователи
устройств, как правило, не являются специалистами по без-
опасности (а специалисты по безопасности, к сожалению,
30
угрозы
не представляют себе масштаб проблемы – но это особый
разговор) и игнорируют даже элементарные требования
безопасности и осторожности при работе с веб-ресурсами,
позволяющие избежать серьезных проблем при действиях
в Интернете или в процессе обмена данными со своими
знакомыми. В итоге мы получаем большой интерес крими-
нальных структур (именно структур, а не только отдельных
хакеров) к мобильным устройствам.
Согласно статистике основное внимание вирусописа-
телей направлено на Android – число вредоносных про-
грамм для других мобильных ОС исчисляется единицами.
В 2013 году количество вредоносных программ для Android
увеличилось на 122%. А по сравнению с уровнем распро-
странения мобильных угроз в 2010-м, когда первые вре-
доносные приложения для Android только появились, рост
составил 9280% (см. рис. 1).
На графике можно увидеть любимую всеми состави-
телями отчетов параболу – так что велика вероятность,
что в 2014-м количество вредоносных программ увеличит-
ся более чем в два раза: период поиска, когда вирусопи-
сатели нащупывали возможности для внедрения троян-
цев в мобильные устройства, давно миновал, и наработки
прежних лет сейчас активно используются на практике.
При этом злоумышленники не только воспроизводят
старые идеи: идет активный поиск новых путей отъема де-
нег. Число семейств вредоносных программ достигло 331 –
за прошедший год их рост составил 185%. Выше мы уже
говорили, что мобильные телефоны дают хакерам много
возможностей, но большая часть троянцев покушается
исключительно на денежные средства – случаи использо-
вания вредоносных программ в террористических целях
или ради шантажа если и есть, то исчисляются единица-
ми. И самым популярным семейством троянцев является
Android.SmsSend (он же Trojan-SMS.AndroidOS в термино-
логии другого отечественного разработчика антивирусных
решений), занявший без малого половину рынка мобиль-
ных угроз (см. рис. 2).
Троянцы появившегося еще в 2010 году семейства
Android.SmsSend предназначены для скрытой отправки
март 2014 системный администратор
 угрозы
дорогостоящих СМС-сообщений на короткие номера, рас-
сылки сообщений по адресной книге и подписки пользо-
вателей на платные контент-услуги. В отдельных случаях
троянцы SmsSend могут проторить дорогу иным угрозам,
перенаправляя пользователя на зараженные веб-страницы
или внедряя в устройство другие вредоносные программы,
в том числе утилиты скрытого удаленного управления. Сей-
час в семейство входит 1377 модификаций.
Троянцы могут распространяться как в виде самостоя-
тельных приложений (.apk), например, под видом обновле-
ний (как правило, браузера или флеш-плеера) или инстал-
ляторов известных приложений, так и внутри бесплатных
легитимных программ, модифицированных злоумышлен-
никами. После запуска зараженных приложений пользо-
ватель получает ожидаемый функционал, поэтому неже-
лательные действия, такие как отправка СМС-сообщений,
обычно остаются незамеченными.
В качестве примера обертки, в которую заворачивались
для маскировки Android.SmsSend, можно привести попу-
лярные мультимедийные проигрыватели, сборники изобра-
жений (в этом случае число загрузок превысило 12 тысяч!),
а также приложения для составления диет и гороскопов.
При запуске вредоносные приложения предлагали пользо-
вателям получить доступ к запрошенному контенту, после
чего извлекали скрытых внутри самой программы троян-
цев и начинали процесс их установки.
На развитие семейства Android.SmsSend (как и иных
вредоносных программ) сильно повлияла коммерциали-
зация рынка киберпреступности. Зачастую вредоносные
файлы создаются с учетом конкретных интересов зло-
умышленников – например, они могут собирать данные
жителей определенного региона. Так, маскировка под ле-
гитимные программы все еще остается наиболее популяр-
ным методом на территории Китая, о чем свидетельствует
появление в 2013 году целого ряда модификаций троянцев,
угрожавших китайским пользователям и, по сообщениям
в сети Интернет, попавших и в Россию.
Рисунок 1. Динамика роста количества описаний Android-угроз в вирусной базе Dr.Web
в период с 2010 по 2013 год
системный администратор март 2014
Безопасность
Заметным событием, связанным с троянцами Android.
SmsSend в прошлом году, стало обнаружение в сентябре
самого крупного за последнее время мобильного ботнета,
состоящего из Android-устройств. По оценкам специалис-
тов компании «Доктор Веб», в состав бот-сети входило
более 200 тысяч смартфонов и планшетных компьюте-
ров. Для заражения мобильных устройств использовалось
сразу несколько СМС-троянцев, которые маскировались
под инсталляторы легитимного программного обеспече-
ния, такого как веб-браузеры и клиенты для работы с со-
циальными сетями (см. рис. 3).
Основным предназначением Android.SmsBot является
все та же несанкционированная отправка премиум-сооб-
щений в целях получения злоумышленниками незаконного
заработка. Однако в данном случае параметры работы тро-
янца не указываются заранее в конфигурационных файлах
или в самом коде – SmsBot получает указания к действию
непосредственно с принадлежащего киберпреступникам
управляющего сайта, что в значительной мере расширяет
их возможности. Многие версии троянцев Android.SmsBot
способны по команде выполнять и другие действия, на-
пример, загрузку прочих вредоносных программ, удале-
ние определенных СМС, сбор и отправку информации
о мобильном устройстве на удаленный сервер, соверше-
ние звонков. Отдельные модификации могут запрашивать
состояние баланса мобильного счета с помощью USSD-
или СМС-запросов и в зависимости от результата получать
от управляющего сервера указание отправить на номер
сообщения определенной стоимости.
Возможность перехвата СМС-сообщений роднит SmsBot
с более опасными программами, например, Android.Spy.
Такие приложения либо имитируют интерфейс настоящих
мобильных банковских клиентов и обманным способом за-
ставляют пользователей предоставить свои персональные
данные, либо устанавливаются под видом важных про-
граммных обновлений или сертификатов и в дальнейшем
позволяют злоумышленникам перехватывать все входящие
Рисунок 2. Наиболее многочисленные Android-угрозы согласно объему записей вирусной
базы компании «Доктор Веб»
31
 Безопасность
СМС-сообщения, в которых может содержаться различная
секретная информация, например, одноразовые mTAN-
коды систем «Банк-Клиент», что в свою очередь дает воз-
можность сокрытия или модификации СМС-подтверждений
о совершении платежа или перевода.
В известных случаях вредоносная программа распро-
странялась по следующей схеме: потенциальная жертва,
пытавшаяся воспользоваться услугами банка через веб-
браузер на уже зараженной машине, получала уведомле-
ние о необходимости авторизации по номеру мобильного
телефона, для чего на мобильное устройство предлага-
лось установить специальное приложение, размещенное
в официальном каталоге Google Play. Это приложение
представляло собой банковского троянца для мобильной
платформы Android.
Мало просто создать вредоносную программу, ее нужно
внедрить на мобильное устройство жертвы. В случае с мо-
бильными приложениями еще совсем недавно для этой
цели жертве нужно было разлочить устройство, теперь
в этом нет необходимости: вредоносные программы про-
никают и в официальный каталог приложений ОС Android –
Google Play. Более того, при этом зачастую даже отсутству-
ет необходимость получения на инфицируемом смартфоне
или планшете администраторских привилегий – современ-
ным троянцам для успешной работы достаточно стандарт-
ных пользовательских прав. Злоумышленники, загрузив-
шие такие приложения в систему Google Play, составляют
описания с учетом содержания самых популярных запро-
сов, что облегчает их попадание в результаты выдачи по-
исковой системы Google Play.
Регистрация аккаунта разработчика обходится кибер-
преступникам всего в 25 долларов. Эти скромные затра-
ты окупаются с лихвой, поскольку до изъятия программы
из Google Play ее успевают скачать десятки тысяч пользо-
вателей.
Нужно отметить, что в случае загрузки троянца с Google
Play заражение как таковое может и не произойти. После
Рисунок 3. Географическое распределение зараженных устройств по оценкам специалистов компании «Доктор Веб»
32
угрозы
запуска вредоносного приложения пользователю демон-
стрируется лицензионное соглашение, в конце которого
расположена незаметная гиперссылка на правила, где
говорится о том, что при согласии с предложенными ус-
ловиями с устройства будут отосланы СМС на короткие но-
мера  и с баланса пользователя будут списаны денежные
средства.
Троянец Android.SmsSend мог проникать к жертве с по-
мощью Android.Androways.1.origin, обнаруженного в ми-
нувшем апреле. Данный вредоносный модуль был создан
злоумышленниками под видом вполне обычной рекламной
системы, демонстрирующей разнообразные информаци-
онные сообщения и позволяющей создателям игр и при-
ложений зарабатывать на своих программных продуктах,
интегрируя в них данный модуль. Как и многие легальные
рекламные платформы, Android.Androways.1.origin был
способен демонстрировать push-уведомления, выводи-
мые в панель состояния операционной системы, однако
в этих сообщениях нередко отображались заведомо лож-
ные предупреждения о необходимости загрузки обновле-
ний для тех или иных программ. Согласившись на загрузку
такого «обновления», пользователи подвергались риску
стать жертвой мошенников (см. рис. 4).
Общее число пострадавших пользователей могло пре-
высить 5,3 млн человек, что стало одним из крупнейших
случаев заражения Android-устройств вредоносными при-
ложениями, которые распространялись с использованием
каталога Google Play за все время его существования.
Особо опасным нужно признать распространение тро-
янцев через QR-код, который содержит ссылку, ведущую
на вредоносную программу.
Опасность заключается в том, что содержимое QR-
кода может быть никак не связано с описанием его на-
значения – пользователи и не подозревают, что последует
за попыткой отсканировать код. Это увеличивает потенци-
ал распространения, так как такой код можно разместить
на любом сайте, а содержащаяся в нем ссылка все равно
Рисунок 4. Ложное предупреждение, выдавае-
мое Android.Androways.1.origin
март 2014 системный администратор
 угрозы Безопасность

будет вести на вредоносный объект. С использованием А как всему этому безобразию могут противостоять
данного способа распространялся, например, троянец антивирусные программы? К сожалению, на ситуацию
Android.SmsSend.15. с антивирусной защитой сложно смотреть с оптимизмом.
Если вредоносная программа была установлена Да, количество загрузок самого популярного антивируса –
без разрешения пользователя, злоумышленникам нужно Dr.Web для Android – превысило 30 миллионов. Но если
скрыть ее на инфицируемом устройстве либо максималь- даже среди стационарных компьютеров, необходимость
но усложнить ее удаление. И в 2013 году значительно уве- антивирусной защиты которых признается всеми, число
личилось число случаев применения вирусописателями незащищенных машин по некоторым оценкам достига-
специальных приемов, затрудняющих проведение анализа ет 30%, то что говорить о мобильных устройствах, если
вредоносных Android-приложений, а также усложняющих большинство пользователей считают мифом существова-
процесс их обнаружения и удаления на мобильных устрой- ние вредоносных программ для них.
ствах. Техника обфускации может существенно затруднить Не облегчает ситуацию и фрагментация рынка мобиль-
обнаружение вредоносной программы не только антивиру- ных устройств – производители антивирусных средств
сами, но и системой входного контроля Bouncer, предна- не могут ориентироваться только на мощные устройства
значенной для предотвращения попадания таких программ с топовой конфигурацией: необходимо обеспечить защиту
в Google Play. всех устройств, в то время как знания обо всех известных
Одной из наиболее распространенных методик самоза- вредоносных программах реализуются десятками мега-
щиты в Android-троянцах стало использование стандарт- байт антивирусных баз.
ной системной функции администратора устройства, ког- Усугубляет проблему и то, что для мобильных устройств
да приложению даются расширенные полномочия, такие антивирус зачастую является единственным средством за-
как возможность управления блокировкой экрана, запроса щиты, обязанным взять на себя оборону от всех угроз.
пароля при выходе из ждущего режима и даже выполне- Единственным выходом из сложившейся ситуации яв-
ние сброса параметров к заводским установкам с потерей ляется опора на продукты, создаваемые на основе инно-
всех имеющихся данных – при использовании преступни- вационных разработок – ПО, сочетающее традиционную
ками этой возможности попытка стандартным способом устойчивость к воздействию вредоносных программ с при-
удалить входящую в список администраторов вредоносную менением технологий, открывающих возможность исполь-
программу приводит к ошибке. зования компактных вирусных баз. Например, технология
И если в общем случае такая ситуация не является Origins Tracing™ for Android позволяет определять новые
проблемой для опытных пользователей (троянца всего семейства вирусов или перекомпилированные варианты
лишь необходимо лишить соответствующих полномочий), уже известных семейств на основе базы знаний о преды-
то большинство обычных владельцев мобильных устройств дущих угрозах и, безусловно, может сделать пользование
с этой проблемой справиться не могут. мобильным телефоном, смартфоном и планшетом гораздо
Но в ряде случаев для того, чтобы обезопасить свое более безопасным. ADV
мобильное устройство, простого отключения полномочий
администратора может быть недостаточно. Создатели вре-
Рисунок 5. Пример киберкриминальных услуг
доносных приложений идут дальше и вносят в их функци-
онал контроль активности данного режима, и, если поль-
зователь пытается его отключить, троянцы предпринимают
попытки не допустить этого. Например, они могут препят-
ствовать открытию системных настроек или выводить за-
прос на получение нужных прав до тех пор, пока пользова-
тель не согласится это сделать.
Не облегчает жизнь пользователей и наличие ошибок
в системе, позволяющих вредоносным программам (на-
пример, Android.Obad) скрывать свое присутствие в соот-
ветствующих списках, а также распространение на рынке
коммерческих систем для защиты Android-приложений
от декомпиляции, взлома и модификации (например, об-
фускации), поскольку подобные механизмы могут быть
использованы не только разработчиками легитимных про-
грамм, но и злоумышленниками (Android.Spy.67 и Android.
Tempur.5.origin).
Семейства Android.SmsSend и Android.SmsBot активно
продаются на нелегальном рынке. Их авторы зачастую
предлагают своим клиентам не только сами вредоносные
приложения, но и сопутствующие им готовые решения
в виде удаленных панелей управления, а также программ-
ных средств для построения вредоносных сетей и партнер-
ских программ. Цены на данные услуги варьируются от нес-
кольких сотен до нескольких тысяч долларов (см. рис. 5).

системный администратор март 2014 33

 Безопасность
Визитка
Сергей Вахонин, директор по решениям ЗАО «Смарт Лайн Инк»
BYOD и безопасность: мифы и реальность
Активное распространение стратегии Bring Your Own Device (BYOD, использование
персональных устройств в рабочих целях) во всех секторах экономики существенно
ускоряет темпы «мобилизации» бизнес-процессов
Это значит, что многие компании поставлены перед необхо-
димостью искать баланс между мобильностью сотрудников
и информационной безопасностью бизнеса, решая ряд но-
вых задач, связанных с эффективностью управления пер-
сональными устройствами и обеспечением безопасности
их применения
Для решения ряда задач безопасности BYOD-устройств
рынку было предложено множество самых разных BYOD-
стратегий, но вследствие ложного маркетингового «шума»,
генерируемого конкурирующими производителями, многие
BYOD-стратегии, представляемые рынку как наиболее эф-
фективные, таковыми не являются. В частности, в области
BYOD-управления был популяризован целый ряд мифов
и заблуждений относительно того, что делает программу
внедрения BYOD-устройств в бизнес-практику предприятия
безопасной и успешной.
Перечислим наиболее распространенные мифы
в стратегиях BYOD:
>> Системы класса Mobile Device Management (MDM)
предоставляют полное решение проблем безопас-
ности в BYOD.
>> Важные корпоративные данные могут безопасно
храниться и создаваться непосредственно на пер-
сональных устройствах.
>> Решения класса Mobile Device Management (MDM)
равноценны решениям класса Data Leak Prevention
(DLP).
Действительно, системы класса Mobile Device
Management (MDM) позволяют удаленно (централизованно)
управлять множеством мобильных устройств, будь то устрой-
ства, предоставленные сотрудникам компанией, или соб-
ственные устройства сотрудников. Это управление обычно
включает в себя такие функции, как удаленное обновление
политик безопасности (без подключения к корпоративной
сети), распространение приложений и данных, управление
конфигурацией для обеспечения всех устройств необходи-
мыми ресурсами.
Некоторые MDM-решения содержат встроенную
«мину» – способность самоуничтожения всего программно-
34
продукты и решения
го обеспечения и данных с мобильного устройства в слу-
чае злонамеренного неавторизованного удаления с него
MDM-приложения. Однако до того момента, пока на BYOD-
устройствах не появятся полностью независимые операци-
онные среды (бизнес, персональная, среда производителя
и т.п.), сегментированные на физическом уровне и снаб-
женные низкоуровневыми интерфейсами для доступа СЗИ
независимых производителей, ограниченность возможно-
стей MDM-решений по контролю исходящих потоков данных
на мобильных устройствах останется принципиальной про-
блемой, обсуждения которой MDM-вендоры старательно
избегают. А для имитации решения проблемы они исполь-
зуют «заплатки» типа вышеупомянутых встроенных «мин».
Сильными сторонами MDM-систем являются такие функ-
ции, как надежная парольная защита устройства, шифро-
вание встроенной памяти и карт хранения данных, либо
«контейнеризация» данных приложений, управляемое унич-
тожение данных с устройства в случае потери или кражи.
Однако же на практике по крайней мере функцию удален-
ного уничтожения данных можно реализовать только при ус-
ловии, что устройство появится в Сети и будет обнаружено
управляющей частью MDM-системы. То есть приходится по-
лагаться на удачу – низкую техническую квалификацию вора
или человека, нашедшего такое «защищенное» мобильное
устройство, и на то, что сработают функции шифрования
и парольной защиты.
Рассматривая миф о безопасности хранения и создания
данных на BYOD-устройствах, стоит помнить, что задача
обеспечения безопасности корпоративной информации
на персональных устройствах стоит не только в связи с ком-
мерческой необходимостью защиты корпоративных нара-
боток, сведений, персональных данных сотрудников и т.п.,
но и в силу требований законодательных и нормативных
актов. В реальности уже сама практика хранения данных
на BYOD-устройствах порождает риск утечки данных не-
зависимо от наличия на устройстве агента MDM-системы.
Данные ограниченного доступа могут быть отправлены не-
посредственно с устройства по сетевым каналам или на под-
ключаемые внешние устройства печати и хранения.
март 2014 системный администратор
 продукты и решения
Некоторые разработчики MDM-систем заявляют,
что их решения обеспечивают полноценную защиту от уте-
чек данных в силу наличия функций шифрования и унич-
тожения данных на устройстве. Однако же рассматривать
MDM-системы как равноценные DLP-системам некорректно
уже в силу существования довольно четкого определения
термина Data Leak Prevention, установленного отраслевы-
ми аналитиками. DLP-решение должно быть способно
анализировать данные в состояниях «Передаваемые
данные» (data-in-motion), «Используемые данные»
(data-in-use) и/или «Хранимые данные» (data-at-rest)
по их содержимому. Указанные виды анализа данных, име-
ющие решающее значение для выполнения задач контроля,
мониторинга и обеспечения целостности данных, попросту
отсутствуют в современных MDM-системах.
Наиболее эффективным решением безопасности
данных для устройств BYOD является предоставление
доступа к информационным активам компании через
удаленное подключение BYOD-устройств через терми-
нальные сессии к виртуальным Windows-средам, ко-
торые, в свою очередь, защищены функционирующей
на хосте DLP-системой, обеспечивающей предотвраще-
ние неконтролируемых утечек данных. Такой подход
называется Virtual Data Leak Prevention (vDLP). Коротко
говоря, технология Virtual DLP предлагает контролируе-
мое предоставление удаленного доступа к корпоратив-
ным данным в отличие от локального хранения данных
на BYOD-устройствах в подходе MDM.
Подход Virtual DLP подразумевает выполнение ключевых
задач безопасности:
Безопасная обработка данных – сотрудники при под-
ключении к корпоративному порталу по безопасной сес-
сии не используют приложения для локальной обработки
данных на устройстве BYOD, либо возможность исполь-
зования данных блокируется на контекстном уровне. Та-
ким образом, гарантируется, что корпоративные данные
компании не будут распространены далее контролируе-
мого устройства.
Безопасное хранение данных – защищаемые корпора-
тивные данные могут быть доступны только в виртуальной
среде, и в случае редактирования или иного изменения
могут сохраняться только на сервере или быть распеча-
таны на принтерах в корпоративной сети. При этом не до-
пускаются локальное сохранение данных во встроенной
памяти BYOD-устройств, подключаемых съемных накопи-
телях, печать на неконтролируемых принтерах вне корпо-
ративной сети.
Контроль передачи данных – DLP-система, функци-
онирующая в виртуальной среде Windows, обеспечи-
вает контентную фильтрацию содержимого файлов
и данных, проходящих через коммуникационные каналы,
и контекстный контроль каналов (электронная почта,
веб-сайты, мессенджеры и т.д., канал печати, перена-
правленные диски и сетевые файловые ресурсы, а также
съемные носители).
Безусловно, MDM-системы играют значительную роль
в обеспечении безопасности стратегии BYOD, но следует
вновь четко обозначить, что при этом они не выполняют за-
дачи предотвращения утечек данных. Для создания пол-
ноценного и эффективного решения по обеспечению
системный администратор март 2014
Безопасность
безопасности в стратегии BYOD MDM-системы должны
работать совместно с резидентными DLP-системами.
Любая MDM-система будет эффективна только в качестве
компонента в более широкой комплексной стратегии обес-
печения безопасности данных на мобильных устройствах.
MDM-системы следует применять для решения задач обще-
го управления и контроля мобильных устройств, шифрова-
ния данных как одну из «линий обороны».
Всеобъемлющая и оптимальная стратегия безопасности
BYOD описывается упрощенной формулой:
Безопасность BYOD = MDM + App + VPN + VM + DLP
где комплексно применяются:
>> MDM-система для контроля локальных приложений
на устройствах, удаленного уничтожения данных,
обеспечения надежной парольной защиты устройства
и шифрования данных и т.п.;
>> приложение (App) для удаленного подключения мо-
бильного устройства через Интернет к виртуальной
среде (например, Citrix Receiver);
>> защищенный VPN-туннель;
>> виртуальная рабочая Windows-среда (VM), в которой
опубликованы и доступны необходимые для работы
приложения и данные;
>> и, наконец, DLP-система предотвращения утечек дан-
ных, интегрированная в виртуальную рабочую среду
Windows и обеспечивающая контроль доступных в этой
виртуальной среде каналов передачи данных (элек-
тронная почта, веб-сайты, мессенджеры, канал печати,
перенаправленные в виртуальную среду локальные
USB-устройства) для предотвращения утечек данных
с BYOD-устройства.
Такой DLP-системой с успехом выступает программный
комплекс DeviceLock DLP Suite, обеспечивающий полный
контроль разнообразных вариантов применения персо-
нальных мобильных устройств в различных моделях исполь-
зования решений виртуализации (BYOD, home office, облач-
ные корпоративные серверы), построенных на платформах
виртуализации и терминального доступа от Microsoft, Citrix,
VMware и других производителей.
При наличии заданных DLP-политик, определяющих
допустимость использования корпоративных данных,
DeviceLock, будучи установленным на стороне компании –
в виртуальной среде или на терминальном сервере, – га-
рантирует, что передача данных пользователем находится
строго внутри границ виртуальной среды (терминальной
сессии), и данные, утечка которых недопустима, не попа-
дают на личную часть персонального устройства (от тон-
кого клиента или домашнего компьютера до мобильного
устройства любого типа), оставаясь при этом доступными
для эффективного выполнения бизнес-задач.
Таким образом, службы ИБ могут полностью контроли-
ровать обмен данными между корпоративной средой и пер-
сональным устройством, а также подключенными к нему
периферийными устройствами и буфером обмена – что осо-
бенно важно, учитывая, что все эти каналы передачи дан-
ных вне корпоративных границ становятся небезопасными
и должны рассматриваться как угроза корпоративной ин-
формационной безопасности. ADV
35
 Базы данных
Визитка
Олег Филиппов, заместитель начальника отдела
разработки, АНТ-Информ, comol@mail.ru
Ускоряем запуск 1С (для разработчика)
Рассмотрим несколько приемов, которые позволяют в десятки раз ускорить время
запуска 1С, особенно после обновления конфигурации
Почему 1С запускается долго?
«Загрузка 1С – процесс длительный, и это нормальная си-
туация» – такое популярное мнение можно нередко услы-
шать на просторах Интернета. На самом деле запуск 1С
в пользовательском режиме при нормальных настройках
и хорошем оборудовании – дело нескольких секунд. Боль-
шинство пользователей, опираясь на свой опыт, со мной
не согласятся.
Действительно, на запуск 1С у пользователя уходит куда
больше времени. Почему? Да тут все просто: бОльшую
часть времени при загрузке 1С тратит не на старт клиент-
Рисунок 1. Альтернативный стартер 1С
36
изучаем 1С
ского приложения и подключение к серверу, а на запуск
некой программки 1CEStart.exe, которая прочитает на-
стройки, определит версию сервера, получит список баз
и т.п.
Но и на этом все не закончится – далее будут прочитан
список пользователей из базы, загружены настройки поль-
зователей и в списке выбран последний пользователь, ко-
торый заходил в систему. При этом открывается диалого-
вое окно, предлагающее выбрать учетную запись и ввести
пароль. И только после успешного ввода пароля наконец
начнется запуск 1С, который в общем объеме потраченного
времени займет не самую большую долю.
Для пользователя время запуска 1С не настолько кри-
тично, если оно не превышает определенного порога. Дан-
ную операцию ему необходимо проделать, как правило,
всего несколько раз в день, следовательно, потери време-
ни на запуск будут небольшими и существенно не скажутся
на работе.
А вот для разработчика ситуация уже совсем другая: за-
пуск 1С происходит регулярно, особенно на стадии отладки
решения. Архитектура платформы 1С позволяет разработ-
чику при первой необходимости пользоваться отладкой,
что,  кстати, положительно сказывается на времени разра-
ботки.
Кроме того, 90% работы программиста 1С – это скорее
доработка уже существующего решения, поэтому отлад-
ка используется даже на начальных этапах. Это приводит
к тому, что в процессе работы программиста запуск 1С и об-
новление конфигурации будут очень частыми операциями,
и, конечно, длительное их выполнение станет существенно
тормозить разработку.
Архитектура новых версий решений 1С основана на ис-
пользовании большого количества объектов метаданных
типа «роль». Поскольку от ролей зависит возможность дос-
тупа к объектам конфигурации, все правила, описанные
для ролей, система кэширует при старте. После обновле-
ния конфигурации этот кэш надо переинициализировать.
Соответственно при большом их количестве время запуска
может существенно вырасти.
март 2014 системный администратор
 изучаем 1С Базы данных

Подводя итог, можно выделить следующие факторы, ко-

торые приводят к замедлению запуска 1С:
>> При первом запуске – чтение списка информационных
баз, чтение списка пользователей, определение вер-
сии сервера.
>> Повторная инициализация кэша метаданных после об-
новления информационной базы.
>> Большое количество ролей в конфигурации.
>> Чтение метаданных при запуске.
Теперь давайте попробуем разобраться, как мы можем
уменьшить негативное влияние этих факторов на время за-
пуска 1С.

Альтернативный стартер
По умолчанию 1С создает ярлыки, которые запускают про-
грамму 1СEStart.exe. В первых версиях платформы 8.2 коли-
чество ошибок в этом небольшом стартере едва ли не пре-
восходило их количество в остальной части платформы.
Теперь ситуация, конечно, лучше, но вряд ли можно назвать
данную программу удачным решением 1С. Поэтому я насто-
ятельно рекомендую выбирать альтернативные методы за-
пуска.
Для пользователей самым оптимальным будет «батник»
с картинкой 1С или заданная в самом ярлыке командная
строка. Возможные параметры командной строки можно
посмотреть в документации, или, к примеру, на infostart.ru
есть описание [1].
Но для разработчика лучше использовать другой вари-
ант – сторонний стартер для 1С [2] (см. рис. 1).
Чем он полезен для скорости запуска:
>> Стартер сворачивается в трей, оттуда его можно выз-
вать одним кликом. При этом не происходит его по-
вторного запуска, анализа файлов и прочих затратных
процедур.
>> В приложении можно указать пользователя и пароль
для каждой базы, с которыми он будет их запускать
по умолчанию.
>> Исполняемый файл для запуска можно указывать
не 1CEStart.exe, а уже 1Cv8c.exe, ну или 1сv8.exe.
Первый указывается, если нужен только клиентский
доступ, при этом в режиме тонкого клиента. Второй –
в остальных случаях.
>> Ну и наконец, если в списке баз так 50 (как я писал
ранее в одной из статей, разработчику лучше иметь
под рукой бОльшую часть типовых конфигураций, что-
бы при необходимости переносить нужный функцио-
нал в разрабатываемое прикладное решение), то воз-
можность «последние запущенные ИБ» будет очень
полезна.

Размещение кэша метаданных на RAM-диске

Как было отмечено выше, кэш метаданных обновляет-
ся при обновлении ИБ. Он представляет развернутую
для удобства чтения информацию о метаданных конфигура-
ции. Объем его может варьироваться от 3-5 Mб до 500 Мб.
При этом дисковых обращений к кэшу метаданных очень
много. Из-за них дисковая подсистема часто бывает пере-
гружена. Когда к небольшому объему данных происходит
много дисковых обращений, решение напрашивается само
собой – RAM-диск.

системный администратор март 2014 37

 Базы данных
Можно вместо RAM-диска использовать SSD, но спец-
ифика состоит в том, что половина обращений – на запись,
а потеря этих данных ничего не уничтожит. Это всего лишь
временные файлы.
В случае большого количества ролей в конфигурации
от скорости работы кэша время запуска будет существенно
варьироваться.
Для создания RamDisk можно использовать программу
Superspeed RamDisk+ [3] (см. рис. 2).
Из преимуществ данной программы я бы отметил следу-
ющее:
>> Популярность
>> Сохранение данных RAM-дисков при выключении ПК
и восстановление их при включении
>> Простота использования
>> Большое количество поддерживаемых архитектур
Главный недостаток состоит в том, что эта программа
все-таки платная. Но $60-80 может позволить себе даже
рядовой пользователь, если, конечно, лицензия уже не ку-
плена на организацию (около 22 000 руб.), ведь быстрый
запуск 1С – это не единственная сфера применения ПО
класса RamDisk. Конечно, существуют и бесплатные ана-
логи.
Создать RAM-диск – это одно, а заставить 1С записывать
на него кэш метаданных – это другая задача. Самое простое
решение – использовать «батник» для запуска 1С примерно
следующего содержания:
SET Temp=G:\Temp
SET Tmp=G:\Temp
start C:\Snegopat\core\starter.exe
Этот «батник» устанавливает временные каталоги
для конкретного приложения (1С) в папку Temp, располо-
женную на диске G.
Диск G соответственно создан в оперативной памяти.
В качестве исполняемого файла указан файл «Снегопата».
Для использования стороннего стартера или классического
стартера 1С можно просто заменить путь к файлу.
Рисунок 2. Программа создания RAM-дисков
38
изучаем 1С
Уменьшение количества ролей в конфигурации
Новая концепция разработки прикладных решений на плат-
форме «1С:Предприятие» предполагает использование
отдельных групп ролей на каждый объект метаданных. Та-
кая архитектура очень удобна с точки зрения функционала
и гибкости настройки прикладных решений. Но с произ-
водительностью, к сожалению, у нее пока некоторые про-
блемы.
Рекомендация тут может быть одна: если вы планируе-
те переработку своего прикладного решения под данную
схему или разработку нового под конкретного заказчика,
оцените необходимость такой гибкости в управлении права-
ми доступа. За нее, к сожалению, придется «платить» уве-
личением объема потребляемой памяти, кэша метаданных
и временем запуска 1С, особенно после обновления конфи-
гурации базы.
Размещение всей информационной базы
на RAM-диске
Основным режимом работы платформы «1С:Предприятие»
сейчас уже является клиент-серверный. Несмотря на за-
явление компании 1С об одинаковой работе приложения
в клиент-серверном и файловом режимах, технологические
различия все-таки существуют, но связаны они в основ-
ном со скоростью работы прикладного решения. Поэтому
на этапе разработки основной функциональности допусти-
мо использовать файловый вариант. Конечно, при условии,
что после окончания разработки тестирование и нагрузоч-
ные испытания будут производиться в клиент-серверном
режиме.
При разработке в файловом варианте исключаются
временные затраты на клиент-серверное взаимодействие,
за счет чего скорость запуска 1С возрастает. При старте
основная нагрузка приходится на файловую систему, по-
тому что необходимо прочитать определенный объем дан-
ных для работы системы. Для разработчика к этому объему
данных добавляется еще и конфигурация (около 100 Мб),
которую платформа считывает заново при запуске после
обновления БД, чтобы обновить кэш имеющихся у нее ме-
таданных.
Тут ничего нового придумать не получится – только раз-
местить базу данных на RAM-диске или на диске SSD.
***
В результате этих действий можно уменьшить время запу-
ска в 10-15 раз. В моей практике конфигуратор, который за-
пускался две минуты, начинал запускаться за пять секунд.
На первый взгляд это незначительная экономия времени,
но двухминутные затраты на запуск отладки делают прак-
тически невозможной разработку решений в нормальном
режиме. EOF
1. Параметры командной строки 1С – http://infostart.ru/
public/104654.
2. Альтернативный стартер 1С – http://infostart.ru/public/201394.
3. Домашняя страница Superspeed RAMDisk+ – http://www.
superspeed.com/desktop/ramdisk.php.
лючевые слова: 1C, производительность, ускорение запуска, оп-
К
тимизация.
март 2014 системный администратор
 изучаем «1С»
РАУЗ в 1С – друг или враг?
Часть 1. Развенчание мифов и поиск правды
С момента введения нового режима учета затрат в 1С прошло достаточно времени,
чтобы взглянуть на него беспристрастно, основываясь на реальной практике
Rein raus.
Припев одноименной песни группы Rammstein
Так ли страшен черт?
Несмотря на уже солидную историю, режим расширенной
аналитики учета затрат (РАУЗ) в программах 1С до сих пор
вызывает множество споров и противоречивых мнений.
Для многих бухгалтеров его название звучит так же угрожаю-
ще, как брутальные строки из песни, вынесенной в эпиграф.
Да и, чего греха таить, многие специалисты 1С до сих
пор считают РАУЗ неким сферическим конем в вакууме,
черным ящиком, шайтан-машиной. Например, из разговора
с одним из сотрудников франчайзи-фирмы «1С», я узнал,
что отдел поддержки клиентов у них занимается сопрово-
ждением, только если не используется расширенная ана-
литика. В противном случае поддержку осуществляет отдел
разработки – с более квалифицированными сотрудниками,
готовыми решать сложные задачи. Это о чем-то да говорит!
Но ведь в момент появления этого нововведения утверж-
далось, что оно должно упростить жизнь, а не наоборот. Не-
ужели все настолько плохо, и для работы в данном режиме
нужно обладать какими-то недюжинными способностями?
Сегодня попробуем разобраться, так ли страшен РАУЗ,
посмотрим, как в этом режиме отрабатываются различные
хозяйственные операции, а также узнаем, какими домысла-
ми и мифами он успел обрасти, и выясним, что из этого –
правда, а что – нет.
Историческая ретроспектива
РАУЗ появился начиная с версии «Управление производ-
ственным предприятием 1.2.15». Стоит отметить, что с самого
начала расширенная аналитика позиционировалась как при-
оритетный режим; рекомендовалось подготавливать и осу-
ществлять переход; сообщалось, что все дальнейшее раз-
витие функционала будет осуществляться исключительно
под него.
системный администратор март 2014
Базы данных
Визитка
Игорь Чуфаров, начальник ИТ-отдела
ООО «Кыштымский огнеупорный завод», igorchufarov@mail.ru
Более того, если процедура перехода с партионного уче-
та на РАУЗ является штатной и достаточно подробно описа-
на [1], то обратный переход стандартными средствами си-
стемы невозможен (если быть точным, то возможна отмена
перехода на РАУЗ, но при этом требуется полное перепро-
ведение всех документов; нет и речи о том, чтобы перейти
на партионный учет с определенной даты, как это происхо-
дит при включении расширенной аналитики).
Главная особенность режима – учет себестоимости всех
запасов и затрат ведется только в двух регистрах «Учет
затрат (бухгалтерский и налоговый учет)» и «Учет затрат
(управленческий учет)». Это касается запасов в производ-
стве и на складе, производственных и непроизводственных
затрат, выпуска продукции и структуры ее себестоимости.
Ведь принципиальной разницы с методологической точки
зрения между запасом и затратой нет.
Получается, что практически вся информация о произ-
водственной деятельности предприятия учитывается только
по двум регистрам. Но как тогда удается отследить, на какой
стадии в данный момент находятся затрата или запас? Ведь,
как уже неоднократно было сказано, в разные моменты вре-
мени одна и та же сущность может быть как запасом (в мо-
мент, когда она находится на складе), так и затратой (когда
передана в производство).
Именно с этой целью используются ключи аналитики,
которые представляют собой некоторый набор однород-
ных аналитических сведений. Применяются они только
в регистрах; в отчетах, которые используют конечные поль-
Рисунок 1. РАУЗ для многих специалистов до сих пор остается «черным ящиком»,
который выдает результат по одному ему известным формулам
39
 Базы данных
зователи программы, фигурируют отдельные аналитики.
И это правильно. Те, кому доводилось анализировать струк-
туру регистров «Учет затрат (бухгалтерский и налоговый
учет)» и «Учет затрат (управленческий учет)», поймут, о чем
я, – непосредственный анализ ключей аналитики весьма за-
труднителен.
Казалось бы, к чему такие усложнения? Однако сделано
все это не зря, так как обратной стороной использования
ключей является упрощение добавления собственных ана-
литик, которых изначально не было в УПП. Поскольку се-
бестоимость рассчитывается для ключей, а не отдельных
аналитик, при этом не будет необходимости переписывать
алгоритмы проведения по регистрам первичных документов
и расчета себестоимости.
Одна из основных задач, которую РАУЗ призван был
решить, – обеспечение корректности учета при наруше-
нии хронологии ввода первичных документов. Дело в том,
что окончательная картина в данном случае складывается
по завершении месяца, и неважно, в каком порядке вво-
дились документы изначально. Например, требование-на-
кладная о передаче материала в производство может быть
оформлено раньше, чем его поступление на склад. Главное,
чтобы все это было внутри одного месяца.
С одной стороны, непосвященным не понятно, для чего
это собственно нужно. Ведь документы вводятся строго по-
следовательно, и не бывает расхода раньше, чем приход.
Но, как говорится, «гладко было на бумаге, да забыли про
овраги». На практике в российских реалиях восстановле-
ние правильной последовательности может отнимать про-
сто грандиозное количество времени, растущее в геоме-
Рисунок 2. Первая партия, поступившая по цене 100 рублей за штуку, сразу же передается в производство документом «Требование-накладная»
40
изучаем «1С»
трической прогрессии относительно общего количества
документов. Типичные примеры: бумажные документы
на поступающие материалы были переданы с опозданием,
и в результате поступление оформлено после того, как ма-
териалы уже ушли в производство. Конечно, это не дело,
и должно решаться другими способами, но, повторюсь,
в российских условиях может получиться так, что времен-
ные затраты на исправление всех подобных моментов будут
совершенно несоизмеримы с экономической эффективно-
стью и возникающими рисками.
Например, не единожды сталкивался с тем, что орга-
низации ведут учет ручными проводками просто потому,
что не могут оперативно восстанавливать последователь-
ность документов, а значит, закрывать месяц с помощью
регламентных операций. Это, конечно, ужасно. При таком
раскладе РАУЗ реально поможет «цивилизовать» ситуацию
относительно малой кровью. Более подробную информа-
цию об этом и других парадоксах учета в 1С вы можете по-
черпнуть из [2].
Другая цель, которую должен был преследовать РАУЗ, –
сокращение времени на расчет себестоимости. Надо ска-
зать, что людей, пытающихся оспорить этот факт, практиче-
ски нет. Действительно, прогрессивная методика решения
системы линейных уравнений сделала свое дело, значи-
тельно увеличив скорость расчета.
Следующий момент, который был заявлен как серьезное
улучшение, – автоматический расчет встречного выпуска.
Если на производстве практикуется циклическое исполь-
зование выпущенной продукции в качестве сырья (напри-
мер, брак выпуска кирпича перемалывается до состояния
март 2014 системный администратор
 изучаем «1С»
глины и используется при формовке новых изделий), если
распространено взаимное оказание услуг подразделения-
ми (транспортный цех подвозит уголь в котельную, которая
отапливает транспортный цех), то РАУЗ будет просто спаса-
тельным кругом. Одним словом, достоинств режима предо-
статочно, для некоторых организаций он просто незаменим.
Цена вопроса
Поскольку любые недостатки есть продолжения достоинств
(а любые достоинства суть продолжения недостатков),
за все приходится платить. Сразу же после появления РАУЗ
развернулись очень активные обсуждения того, чем придет-
ся пожертвовать, и так ли существенны его преимущества
в сравнении с недостатками.
Основными претензиями стали:
>> Отсутствие поддержки партионного учета товарно-ма-
териальных ценностей.
>> Себестоимость выбытия материально-производствен-
ных запасов по всем направлениям считается одина-
ковой и рассчитывается (корректируется) в конце ме-
сяца.
>> Метод ФИФО использует другой алгоритм, нежели
при партионном учете.
>> Снижение прозрачности учета.
>> Не работают привычные отчеты.
На самом деле каждый пункт из приведенного списка до-
статочно тесно переплетен со всеми остальными. Об этих
и других особенностях РАУЗ я рассказывал в [2] и [3], а так-
же в цикле статей [4-12], который, к слову сказать, еще
не окончен – ждите продолжения.
Рисунок 3. Материалы вошли в состав готовой продукции 3 февраля, до второго поступления по новой цене
системный администратор март 2014
Базы данных
Если последние два пункта во многом субъективны и свя-
заны скорее с нежеланием менять сложившиеся привычки
(ведь, к примеру, никто не мешает использовать новые от-
четы вместо старых), то остальные три требуют к себе повы-
шенного внимания и осмысления.
Основным камнем преткновения стоит считать все же
отсутствие в режиме РАУЗ партионного учета. Вокруг этой
особенности было развернуто большое обсуждение. Более
того, весь негатив, который впоследствии проявился, чаще
всего преподносился под вывеской «РАУЗ vs Партионный
учет». На самом деле такое противопоставление не совсем
корректно, так как отсутствие партионного учета – всего
лишь одна из особенностей РАУЗ.
Сами разработчики компании «1С» не раз говорили,
что правильным можно считать разделение на традици-
онную и расширенную аналитику. Но поскольку термин
«партионный учет» уже прочно укоренился именно в плане
противопоставления РАУЗ, не станем занудствовать и до-
говоримся, что и то и другое название имеет свое право
на жизнь.
Война миров
Есть ли принципиальные отличия между режимом расши-
ренной аналитики и партионным учетом? Безусловно, есть.
Если быть кратким, то резюме таково: да, РАУЗ, как и любой
другой алгоритм, имеет свои особенности. Нужно ли их на-
зывать именно недостатками? Очень сомневаюсь. Я даже
думаю, что, если бы был способ развернуть историю вспять
(то есть если бы изначально в программах был РАУЗ, а за-
тем вдруг перешли на партионный учет, мотивируя это повы-
41
 Базы данных
шением детализации складского учета, например), споров
было бы не меньше.
Как я уже говорил выше, многие до сих пор считают РАУЗ
некой вещью в себе, «черным ящиком», который выдает
результат по одному ему известным формулам. В противо-
вес партионному учету, где все четко и ясно с точностью
до партии, РАУЗ что-то там постоянно усредняет, решает
какие-то уравнения, и в результате получается что-то при-
мерное, далекое от правды (рис. 1). Главный довод против-
ников РАУЗ: «Да вы посчитайте на бумажке – у вас сойдется
с партионным учетом, а не с расширенной аналитикой».
Квинтэссенцией этого отношения к РАУЗ как к некоторой
шайтан-машине можно считать высказывание на профиль-
ном форуме infostart.ru [13]:
«Да, РАУЗ устраивает торгово-шарашечные конторы,
которым плюс минус лапоть, а то и сапог – не страшно,
хотя бы знать примерно (и представители которых и кри-
чат о «такой же примерности» результатов у них в партион-
ном учете). Если у вас реальное производство, и вы хотите
знать, сколько чего затрачено и как вписалось в стоимость
конечного товара, то РАУЗ даст такую среднюю темпера-
туру, что будет, как в советское время, на бумаге одно,
а в цеху прямо противоположное, не говоря уже о каком-
либо актуальном планировании материалов, только вот
финансовых вливаний для закрытия дыр, как в советское
время, уже не будет».
Обращаю внимание, что это форум профессионального
сообщества специалистов 1С, данное мнение поддержали
другие специалисты, как мне представляется, не первый год
работающие с учетными системами.
Рисунок 4. Вторая партия пришла по цене 200 рублей за штуку и была израсходована только наполовину
42
изучаем «1С»
И тем не менее все сказанное выше не более чем миф,
который я сегодня собираюсь опровергнуть. Для этого мне
потребуется ответить на два вопроса:
>> Так ли нужен партионный учет для корректного расчета
себестоимости изделий, выпускаемых производствен-
ным предприятием?
>> Насколько расходятся результаты расчета себестои-
мости при использовании РАУЗ и партионного учета?
А что на деле?
Как и в ранее опубликованных статьях [1-10], договорим-
ся, что используется конфигурация «Управление про-
изводственным предприятием 1.3» на базе платформы
«1С:Предприятие 8.2» (далее по тексту УПП). Однако если
ранее всегда режим РАУЗ был включен, то сейчас будет сде-
лано сравнение одинаковых операций в партионном учете
и в режиме расширенной аналитики. Также стоит добавить,
что как при включенном РАУЗ, так и в режиме партионно-
го учета будет использоваться ФИФО (от аббревиатуры
FIFO – First-In-First-Out – вариант, при котором со склада пар-
тии списываются в том же порядке, в котором поступали).
Если в партионном учете реализовать подобный меха-
низм проще простого, то в случае с расширенной аналити-
кой, где отсутствует понятие «партиобразующий документ»,
расчет делается в несколько этапов.
Сначала определяется, какие именно партии остались
на складе после всех выбытий. Затем рассчитывается
их стоимость. После этого вычисляется стоимость выбы-
тия всех остальных партий, причем она устанавливается
одинаковой (усредненной) для всех направлений выбытия.
март 2014 системный администратор
 изучаем «1С»
Несмотря на ряд критических замечаний по поводу тако-
го алгоритма на различных форумах, он не противоречит
требованиям законодательства и вполне может называться
именно ФИФО, а не как-либо иначе. Подробнее об особен-
ностях, в том числе с наглядными примерами, вы можете
прочитать в [4].
Сейчас же перейдем от складского учета (к которому от-
носится алгоритм ФИФО) к рассмотрению простейшей це-
почки, характерной для учета производственного процесса
в целом.
>> 1 февраля на склад поступил материал «Материал
№1» в количестве 10 штук по цене 100 рублей за шту-
ку, на общую сумму 1000 рублей (см. рис. 2, сверху).
>> 2 февраля 10 штук материала «Материал №1» пере-
даны в производство документом «Требование-наклад-
ная» (см. рис. 2, снизу).
>> 3 февраля выпущено 10 штук готовой продукции «Про-
дукт №1», на которую затрачено 10 штук материала
«Материал №1» (оформлен документ «Отчет произ-
водства за смену», как показано на рис. 3).
>> 10 февраля на склад поступил тот же материал «Мате-
риал №1» в количестве 10 штук, но уже по цене 200 руб-
лей за штуку на общую сумму 2000 рублей (см. рис. 4,
сверху).
>> 12 февраля 5 штук материала «Материал №1» пере-
даны в производство документом «Требование-наклад-
ная» (см. рис. 4, снизу).
>> 13 февраля выпущено 5 штук готовой продукции «Про-
дукт №1», на которую затрачено 5 штук материала
«Материал №1» (см. рис. 5).
Рисунок 5. 13 февраля оформлен выпуск продукции, для которой использовалась только вторая партия материала
системный администратор март 2014
Базы данных
В чем смысл рассматриваемой последовательности дей-
ствий? Один и тот же материал приходит в разное время
(1 и 10 февраля) по разной стоимости. На следующий день
после поступления на склад материал забирают в произ-
водство, и еще через день он входит в состав готовой про-
дукции.
Во второй раз со склада забирают не весь поступивший
материал, а только половину. Соответственно он должен
остаться на складе в количестве 5 штук. При использова-
нии партионного учета в методике ФИФО по идее со склада
сначала должны списаться партии стоимостью 100 рублей
за штуку и только потом по 200 рублей.
Разумеется, такое значительное различие в цене сдела-
но намеренно для примера, чтобы показать, как работает
расчет себестоимости при производстве из разных посту-
плений.
Согласно этой логике первый выпуск готовой продукции
должен быть в два раза дешевле, чем второй (так как он сде-
лан из первой партии материала). Ожидаемая себесто-
имость первого выпуска при партионном учете – 100 руб-
лей за штуку, второго – 200 рублей. В то же время, если
верить тому, что говорят о РАУЗ, в этом режиме мы должны
получить некий усредненный результат. Посмотрим, так ли
это на самом деле. Кроме того, интересно будет увидеть
суммовую оценку материала, оставшегося на складе.
Проведем расчет себестоимости выпуска и сформи-
руем отчет «Ведомость по партиям товаров на складах»
(см. рис. 6).
Что же мы видим? Как это ни странно, но себестоимость
выпущенной продукции оказалась усредненной по отно-
43
 Базы данных
шению к партиям материла. Может быть, при передаче
в производство получилась неправильная суммовая оцен-
ка? Но ведь из этого же отчета видно, что расход материала
был 1 февраля в количестве 10 штук стоимостью 1000 ру-
блей и 10 февраля в количестве 5 штук стоимостью 1000 ру-
блей.
В то же время продукция, выпущенная 3 февраля цели-
ком и полностью из первого поступления материала, рас-
ценена так, как будто для ее производства использовались
обе партии.
Действительно, если сложить общую стоимость всех
переданных в производство материалов (1000 рублей
+ 1000 рублей = 2000 рублей) и разделить на их коли-
чество (10 штук + 5 штук = 15 штук), получится средняя
цена 133 рубля 33 копейки. Умножив полученное значение
на 10 и на 5 штук, получим себестоимость первого и второго
выпуска соответственно (1333 рубля 33 копейки и 666 руб-
лей 67 копеек).
Нетрудно видеть, что именно такие результаты выводятся
в ведомости по партиям товаров на складах. И это, обращаю
ваше внимание, при партионном учете в режиме ФИФО.
Но хоть остаток-то на складе получил ту суммовую оцен-
ку, которую мы ожидали? Да, поскольку на складе остались
только материалы из второй партии, то и оценка у них соот-
ветствующая (по 200 рублей за штуку, в итоге 5 штук общей
стоимостью 1000 рублей). То есть по складу механизм сра-
ботал ровно так, как и ожидалось.
Что же касается производства, то здесь мы видим яв-
ное усреднение суммовых оценок. Еще раз подчеркну: вы-
пуск 3 февраля был осуществлен в тот момент, когда на-
личествовало только одно поступление по цене 100 рублей
за штуку. И при этом он оценен как 133 рубля 33 копейки
за единицу выпущенной продукции.
Теперь рассмотрим результат выполнения аналогичной
последовательности действий с включенным РАУЗ. По-
скольку в режиме расширенной аналитики не применяется
партионный учет, использовать отчет «Ведомость по парти-
ям товаров на складах» нельзя. Вместо него используется
ведомость по учету МПЗ, в которой показываются все дви-
жения материально-производственных запасов (см. рис. 7).
Рисунок 6. Из ведомости по партиям товаров на складах видно, что суммовая оценка выпущенной продукции является усредненной
44
изучаем «1С»
Что сразу бросается в глаза? РАУЗ, который, по мнению
многих, должен был показать менее точную картину, на са-
мом деле позволил получить абсолютно идентичный резуль-
тат: выпущенная продукция в количестве 15 штук оценена
в 2000 рублей, на складе остаток материала имеет суммо-
вую оценку 1000 рублей за 5 штук.
Беспартийное производство
Почему получены такие странные на первый взгляд резуль-
таты? Все дело в том, что независимо от того, какой режим
учета выбран (партионный или РАУЗ), он относится лишь
к складскому учету и никак не затрагивает производствен-
ный.
Что это значит? Это значит, что все партии, пришедшие
в производство в течение месяца, рассматриваются доку-
ментом «Расчет себестоимости» исключительно совокупно.
Иными словами, если в течение месяца было несколько по-
ступлений одного и того же материала с разной стоимост-
ной оценкой, в результате будет рассчитана их средняя
суммовая, и именно она войдет в конечную себестоимость
готовой продукции.
А теперь самое интересное: если в производстве затра-
ты все равно будут усреднены, нужно ли убиваться и вос-
станавливать последовательность для поддержания парти-
онного учета?
Еще один важный вопрос, который следует себе задать:
а соответствует ли партионный учет на складе по методи-
ке ФИФО реальному положению вещей в принципе? Дей-
ствительно ли фактически первым передается на склад ма-
териал, поступивший раньше? Если ответ отрицательный,
не стоит и раздумывать, при учете по средней результат
будет одинаков для обоих режимов даже в складском учете.
Возвращаясь к вопросам, заданным в начале статьи,
можно заключить:
>> На вопрос, так ли нужен партионный учет для коррект-
ного расчета себестоимости изделий, выпускаемых
производственным предприятием, ответ таков: нет,
значимость партионного учета сильно переоценена,
так как в производстве все равно стоимостная оценка
будет усреднена.
март 2014 системный администратор
 изучаем «1С»
>> На вопрос, насколько расходятся результаты расчета
себестоимости при использовании РАУЗ и партионного
учета, можно ответить: в большинстве случаев резуль-
таты расчета себестоимости абсолютно идентичны,
что было явно продемонстрировано на примере.***
Говорить о менее точном или неправильном расчете се-
бестоимости в режиме расширенной аналитики учета запа-
сов и затрат по меньшей мере некорректно. Отсутствие точ-
ной суммовой оценки по каждому документу, конечно, ведет
к некоторым ограничениям детализации учета, но не несет
в себе настолько далеко идущих последствий, чтобы ста-
вить под сомнение результат производственных операций.
На самом деле в большинстве случаев отрицательные от-
зывы относительно РАУЗ продиктованы в большей степени
страхами, нежели реальным негативным опытом.
Как было показано в статье, и РАУЗ, и партионный учет
на корректных входных данных дают идентичные результа-
ты. Основная причина этого в том, что сам производствен-
ный учет в УПП не является партионным вне зависимости
от выбранного режима. Не столь важно, каким образом
были рассчитаны суммовые оценки при передаче материа-
лов со склада в производство. При расчете себестоимости
выпуска все равно будет осуществлено усреднение суммо-
вых оценок.
Хотя данный факт не является секретом и указывается
в документации, думаю, для многих он станет откровением
именно после публикации данной статьи. В противном слу-
чае не было бы столько обсуждений и ошибочных выска-
зываний, утверждающих, будто бы РАУЗ дает менее точные
результаты, чем партионный учет.
Может быть, у кого-то возникнет вопрос: а возможно ли
в приведенном примере обеспечить детализацию, при кото-
рой суммовая оценка выпущенной продукции будет опреде-
ляться реальной, а не усредненной стоимостью материала,
из которого фактически она сделана?
Да, это возможно. И именно этому будет посвящена вто-
рая часть статьи, которую вы сможете прочитать в одном
из следующих номеров. EOF
Рисунок 7. В режиме РАУЗ получилась ровно такая же картина, как и в партионном учете
системный администратор март 2014
Базы данных
1. Абрашина Е.В., Емельянов И.М. Использование механизма рас-
ширенной аналитики в «1С:Управление производственным пред-
приятием». – М.: Издательство «1С-Паблишинг», 2011. – 177 с.
2. Чуфаров И. Парадоксы учета в 1С. //«Системный администра-
тор», №11, 2012 г. – С. 68-71.
3. Чуфаров И. Особенности учета бракованной продукции в 1С.
//«Системный администратор», №12, 2012 г. – С. 72-76.
4. Чуфаров И. Как избежать ошибок учета в 1С. Часть 1. Выбы-
тие запасов. //«Системный администратор», №1-2, 2013 г. –
С. 72-76.
5. Чуфаров И. Как избежать ошибок учета в 1С. Часть 2. Учет
прямых материальных затрат. //«Системный администратор»,
№3, 2013 г. – С. 62-66.
6. Чуфаров И. Как избежать ошибок учета в 1С. Часть 3. Рас-
пределение косвенных материальных затрат. //«Системный
администратор», №5, 2013 г. – С. 46-53.
7. Чуфаров И. Как избежать ошибок учета в 1С. Часть 4. Нема-
териальные затраты: услуги. //«Системный администратор»,
№6, 2013 г. – С. 52-59.
8. Чуфаров И. Как избежать ошибок учета в 1С. Часть 5. Зацикли-
вание затрат. //«Системный администратор», №7-8, 2013 г. –
С. 46-52.
9. Чуфаров И. Как избежать ошибок учета в 1С. Часть 6. Спец-
одежда, спецоснастка и инвентарь. //«Системный администра-
тор», №10, 2013 г. – С. 46-53.
10. Чуфаров И. Как избежать ошибок учета в 1С. Часть 7. Учет
оборудования. //«Системный администратор», №11, 2013 г. –
С. 73-79.
11. Чуфаров И. Как избежать ошибок учета в 1С. Часть 8. Объекты
строительства. //«Системный администратор», №12, 2013 г. –
С. 38-43.
12. Чуфаров И. Как избежать ошибок учета в 1С. Часть 9. Аморти-
зация основных средств. //«Системный администратор», №1-
2, 2014 г. – С. 76-82.
13. Что лучше: РАУЗ или партионный учет? // Обсуждение на фо-
руме infostart.ru – http://forum.infostart.ru/forum36/topic46669.
Ключевые слова: 1C, партионный учет, РАУЗ, себестоимость.
45
 Разработка
Визитка
Александр Календарев, программист, РБК Медиа,
akalend@mail.ru
Концепции моделирования MongoDb
на примере разработки социальных игр
Подход к проектированию данных в документно-ориентированных БД немного
отличается от подобной работы в традиционных СУБД. Суть этих отличий мы сегодня
и рассмотрим
MongoDb – яркий представитель документно-ориентиро-
ванной базы данных, реализованой на С++, являющийся
Open Source-продуктом, что еще больше повышает ее по-
пулярность, распространяется под лицензией GNU AGPL
v3.0. Название составлено из части слова «humongous»,
что значит «большой», «значительный», а Db – сокращение
от «DataBase».
Первый релиз был выпущен фирмой 10 Gen в 2008 году.
Текущей версией является 2.4. В настоящее время MongoDb
используют более 10 миллионов компаний и стартапов, в том
числе такие гиганты ИТ-индустрии, как SourceForge.net,
foursquare (социальная сеть), the New York Times, MTV, Cisco
и многие другие.
В отличие от традиционных СУБД MongoDb не может
делать операции объединения, JOIN-таблицы или, в терми-
нологии MongoDb, коллекции. Поэтому MongoDb подходит
в случае слабосвязанных или слабоструктурированных
данных. Если схема данных представляет сложные семанти-
ческие связи, то лучше использовать другой класс NoSQL-
хранилищ: «графовые БД».
Основные концепции
В основе концепции MongoDb лежит понятие документ. До-
кумент представляет набор поименованных полей, где каж-
дое поле выглядит как пара «ключ-значение».
Внешнее представление документа сделано в виде
формата JSON (Java Script Object Notation), а внутренняя
организация хранения и передачи данных между клиентом
Таблица 1. Сравнение традиционной РСУБД и MongoDb
РСУБД MongoDb
База данных, Схема данных База данных
Таблица Коллекция
Строка данных, Таблицы Документ
Колонка строки Поле документа
Курсор Курсор в хранимых процедурах
46
проектирование
и сервером осуществляется в его бинарном представле-
нии: BSON (Binary-encoded serialization of JSON).
Пример JSON-документа:
{
"user_id" : 1,
"nickname" : "Bob",
"level" : 3,
"pvp_level": 17 ,
"awards" : ["hero-I","gold star"]
}
Документ содержит множество поименованных полей
с их содержанием. По сути, каждый документ содержит
в себе схему описания. Это позволяет хранить «гибкие»
структуры данных, что является некоторым преимуществом
перед традиционными РСУБД.
Множество документов сгруппированы в коллекции. Так,
например, множество данных о пользователях может быть
объединено в коллекцию users. А каждый элемент коллек-
ции users является документом, описывающим конкретного
пользователя.
Все документы в пределах коллекции проиндексированы
по первичному ключу в BTree-индекс. BTree-индекс позволя-
ет делать выборки по условию «больше и меньше». Также
MongoDb позволяет индексировать документы по вторично-
му индексу.
Множество коллекций должно быть объединено в одну
из баз данных. Один запущенный экземпляр MongoDB мо-
жет поддерживать несколько разных баз данных. Концеп-
туально база данных соответствует понятию базы данных
в MySQL или схемы в Oracle.
Для лучшего понимания мы можем сделать сравнение
в терминах традиционных РСУБД (см. таблицу 1).
Документ. Схема документа
Документ – это основная единица, которой манипулирует
MongoDb, она представляет собой упорядоченный набор
полей с их значениями.
Представим документ с традиционным для компьютерной
сферы приветствием: «Hello, world!»:
март 2014 системный администратор
 проектирование
{"greeting" : "Hello, world!"}
Этот простой документ содержит одно поле с именем
«greeting» и со значением «Hello, world!». Большинство до-
кументов будет намного сложнее, но все они должны содер-
жать множество поименованных полей.
В MongoDb все документы должны иметь уникальный
первичный ключ _id, который автоматически индексируется
базой данных.
Если это поле при вставке данных не задавать, то его зна-
чение сформируется системой автоматически и будет со-
держать следующие 12 байт:
0-3 байт – временная метка (время, когда объект был соз-
дан).
4-6 байт – идентификатор экземпляра БД MongoDB.
Это необходимо для того, чтобы _id документа был уни-
кальным, в случае же если БД разбита на несколько
частей, которые распределены на несколько разных
машин.
7-8 байт – pid процесса.
9-11 байт – инкрементный счетчик, который у каждого
следующего документа увеличивает число на 1.
Такой алгоритм формирования первичного ключа гаран-
тировано предполагает, что в БД не будет двух документов
с одинаковым _id даже в случае большого потока ввода но-
вых данных на некотором количестве распределенных сер-
веров.
Для каждого документа должны выполняться следующие
правила:
>> Расположение полей в документе может быть неупоря-
доченным, то есть документы {"foo" : "bar", "baz" : "quux" }
и {"baz" : "quux", "foo" : "bar"} для MongoDb идентичны.
>> Имена полей регистронезависимые, документы {"foo" :
"bar"} и {"Foo" : "bar"} идентичны.
>> Название поля не может содержать нулевой символ
«\0» (null). Этот символ используется для разделения
полей.
>> Символы «.» (точка) и «$» (доллар) зарезервированы
системой и не могут использоваться в названии полей,
так как имеют специальное назначение, о котором бу-
дет рассказано ниже.
>> Имена полей, начинающиеся с «_», как правило, ис-
пользуются системой, поэтому не рекомендуется вно-
сить в название данный символ. Например, как упо-
миналось ранее, каждый документ имеет уникальное
поле «_id».
>> Каждый документ может содержать вложенный доку-
мент.
Как мы видим, в отличие от традиционных РСУБД, в кото-
рых схема документа строго определена до начала исполь-
зования данных, в документно-ориентированных хранили-
щах она содержится в самом документе и может меняться
от одного к другому.
Поле в документе содержит имя и данные, в нем самом
уже заложена его структура. Поля могут иметь следующие
типы:
string – строка;
int – целое число;
double – двойное число с плавающей запятой;
DateTime – дата;
системный администратор март 2014
Разработка
byte[] – массив байт (бинарные данные);
bool – булевые (Истина и Ложь);
null – Ноль;
Object – BSON-объект;
Array[]– массив объектов;
UUIDs – уникальные идентификаторы;
IDRefs – ссылочные типы.
Коллекция
Для более гибкого манипулирования данными множество
документов сгруппированно в коллекции. Аналогом кол-
лекции в РСУБД может являться таблица БД, а документа –
строка данных.
Для более быстрого извлечения документов по опреде-
ленному признаку мы можем создать индекс на них по не-
которым полям или сразу по группе полей (составной ин-
декс).
Индекс накладывается только на коллекцию, которая
должна содержать логически сгруппированные документы.
Например, если мы имеем коллекцию пользователей игро-
ков онлайн-игры (см. текст 1), то для выборки участия в «ран-
домных боях» по одинаковым силам нам лучше проиндекси-
ровать игроков по их игровому уровню «level» или боевым
навыкам «pvp_level». Поэтому будет произведено наложе-
ние индекса на поле «level» коллекции users.
Коллекции идентифицируются по именам, которые могут
содержать любые UTF-8 символы с некоторыми ограниче-
ниями:
>> Имя коллекции не может быть пустой строкой.
>> Имя коллекции не может содержать нулевой символ
«\0» (null).
>> Имя коллекции не может содержать префикс «system».
>> Имя коллекции не может содержать символ «$» (дол-
лар), который зарезервирован системой.
Имя коллекции может содержать символ «.» (точка),
например, «user.tanks», «user.angars». Такие наименова-
ния (составные имена) коллекций несут лишь логическую
смысловую нагрузку для большей информативности. Так-
же они используются служебными утилитами, например,
протокол GridFS применяет составные имена коллекций
для метаданных.
База данных
База данных – это самый верхний уровень абстракции
в MongoDb. Она содержит множество коллекций. Как и в тра-
диционных СУБД, на уровне баз данных организованы раз-
ные уровни доступа для разных пользователей. По умолча-
нию в MongoDb находится служебная БД.
Каждая база данных расположена на диске в собствен-
ном файле, поэтому на имя БД наложены те же ограниче-
ния, что и на имена файлов. Дополнительными ограничени-
ями являются:
>> Имя БД не может быть пустой строкой.
>> Имя БД не может содержать нулевой символ «\0» (null).
>> Имя коллекции не должно содержать символов «$.,/\»
и пробел.
>> Имена БД должны быть только в нижнем регистре.
>> Зарезервированные имена БД: local, admin и system,
в которых сохранены все настройки, разрешения и ме-
таданные.
47
 Разработка
Имена БД могут использовать префикс, по аналогии
с именами БД MySQL. Если используется коллекция users
в БД test, то можно написать: test.users.
Паттерны моделирования
Если связанность данных небольшая, то можно использо-
вать их денормализацию – процесс, обратный процессу
нормализации. То есть развертывание структуры данных
в одну плоскую таблицу за счет увеличения избыточности.
Пример простой денормализации – это схема хране-
ния данных о наградах или наличии оружия. Пусть у нас
есть игровая учетная запись – Пользователь (user). Каж-
дый пользователь (user) может быть в ходе игры награжден
и иметь одну или несколько наград (awards).
Мы имеем отношение многие ко многим между множе-
ством пользователей (users) и множеством наград (awards).
Такое отношение в РСУБД обычно реализуют через проме-
жуточную таблицу: userAwards (награды пользователя).
Но в нестрогой системе мы можем использовать масси-
вы. Ниже представлен пример представления отношения
множества многие ко многим:
>db.users.insert({"nick": "Иван Бровкин", ↵
"level":20, "pvp_level" : 621, ↵
"awards": ["Silver star","Hero"] })
>db.users.insert({"nick": "Иван Чёлкин", ↵
"level":25, "pvp_level" : 749, ↵
"awards": ["Silver star","Victory "] })
>db.users.insert({"nick": "Швейк", ↵
"level":25, "pvp_level" : 794, ↵
"awards": ["Gold star","Hero"] })
> db.users.insert({"nick": "Василий Теркин", ↵
"level":23, "pvp_level" : 659, ↵
"awards": ["Gold star","Victory"] })
>db.users.find();
"_id" : ObjectId("530bb68d0af670a3356dfa02"),
"nick" : "Иван Бровкин", "level": 20, "pvp_level" : 621,
"awards" : [ "Silver star", "Hero" ] }
"_id" : ObjectId("530bb68d0af670a3356dfa03"),
"nick" : "Иван Чёлкин", "level":25, "pvp_level" : 749,
"awards" : [ "Silver star", "Victory " ] }
"_id" : ObjectId("530bb68d0af670a3356dfa04"),
"nick" : "Швейк", "level" : 25, pvp_level" : 794,
"awards" : [ "Gold star", "Hero" ] }
"_id" : ObjectId("530bb68d0af670a3356dfa05"),
"nick" : "Василий Теркин", "level" : 23, "pvp_level" : 659,
"awards" : [ "Gold star", "Victory" ] }
Но чаще всего объекты имеют более сложную структуру,
а не только одно поле «наименование», как в случае с при-
Рисунок 1. Пример простой денормализации
48
проектирование
мером о наградах. Поэтому используются так называемые
вложенные объекты. Пусть награды имеют некоторый рей-
тинг, который определяет их «ценность», например, орде-
на ("type" = 1) и медали ("type" = 2) имеют разную ценность
(«rating»). Существуют медали «боевые», а есть медали
«юбилейные». Тогда данные по наградам можно предста-
вить как массив вложенных объектов: {award: {name, rating,
type}}:
{"nick": "Василий Теркин", "level":23, "pvp_level" : 659, ↵
"awards": [ "award": {"name":"Gold star", ↵
"rating": 10, "type": 1} , ↵
"award": {"name":"Victory", ↵
"rating": 7, "type": 1} }] }
В данном примере вложенным объектом выступает под-
документ «award», состоящий из полей: {"name", "rating",
"type"}.
Такое применение оправдано в случае, если количество
пользователей большое (миллионы), а количество разных
типов наград невелико (десятки или сотни).
Другой паттерн представления данных в MongoDb – ис-
пользование ссылочных типов. Ссылочные типы – это ана-
лог внешних ключей РСУБД. Однако надо всегда помнить,
что MongoDb никаких объединений и пересечений не про-
изводит. Все операции по пересечению данных и объеди-
нению таблиц производятся исключительно на клиентской
стороне.
Пусть нам для отображения на игровом поле предстоит
использовать список друзей friendList. Ниже на рис. 2 пред-
ставлено классическое отношение один ко многим при реа-
лизации для СУБД.
«Друзья» имеют то же логическое отношение, что и «дру-
зья» в социальных сетях. Это те же пользователи (игроки),
с которыми у тебя есть «отношение дружбы», пользователи,
с которыми можно строить «коалиции» против врага при ор-
ганизации групповых боев.
Мы можем денормализовать данные и поместить в поле
«friendList» как массив вложенных объектов user со всеми
данными этого пользователя. Однако в этом случае у нас
встает проблема актуализации, то есть в случае любого из-
менения у пользователя необходимо сразу произвести ана-
логичные действия у всех его друзей, что очень накладно.
Как вариант, используется объект friend, который име-
ет основные «не изменяемые» поля объекта user, такие
как «nick», «avatar» и ссылочное поле id = ObjectId("52cc24
62d47566cbb0e20ff6") и ссылается на объект пользователя-
друга:
friend: {"nick":"Василий Теркин", ↵
Рисунок 2. Классическое соотношение один ко многим при реализации для СУБД
март 2014 системный администратор
 проектирование
"avatar": "27AE/271.jpg", ↵
" id" : ObjectId("52cc2462d47566cbb0e20ff6") }
friend: {"nick":"Иван Ченкин", ↵
"avatar": "23EB/743.jpg"," ↵
id" : ObjectId("52cae653d47566cbb0e20fed") }
Данные поля «id» представляют содержание первичного
ключа _id на ссылаемый объект. При необходимости мы сле-
дующим запросом выбираем всю требуемую информацию
по «другу», например, для отображения его «базы».
Подведем краткий итог. В первом примере, с наградами,
ответственность за изменение информации закреплена
за объектом user, который является «хозяином» этих наград.
Поэтому целесообразнее использовать массив вложенных
объектов.
Во втором примере, со списком друзей, ответственность
за изменение информации закреплена за пользователем-
другом. Поэтому целесообразнее использовать ссылочный
тип. Однако можно использовать комбинированный вари-
ант, где неизменяемые данные, такие как «nick» или ссылка
на картинку с аватаром, можно представить во вложенном
документе вместе со ссылкой на документ самого друга-
пользователя («user»).
Также в виде вложенных документов удобно представить
агрегированную информацию. Например, наш пользова-
тель имеет некое оружие, которое задается номером, ха-
рактеризуется ударной силой (power), имеет запас зарядов
(reserve), у игрока есть некоторый опыт его использования
(eхperience). Также пользователь находится на поле c коор-
динатами (x, y):
Данная информация может быть представлена следую-
щим образом:
{ ли является их избыточность, лишние байты информации
"_ id" : ObjectId("52cc2462d47566cbb0e20ff6") ,
"nick" :"Василий Теркин",
"avatar" : "27AE/271.jpg",
"weapon" : {
"id" : 27,
"power" : 127,
"reserve" : 10
"experience" : 10
},
"position" : {
"x" : 453,
"y" : 74
},
} лизовывать самостоятельно в клиентском приложении. EOF
Как мы видим, в документе пользователя присутствуют
составные объекты: weapon, position.
Еще один паттерн – это использование ссылочных данных
на коллекции документов. Например, каждый пользователь
имеет некое сложное оружие, к примеру, танки. Как один
из вариантов, можно использовать массив сложных объек-
тов tanks. Каждый из танков характеризуется параметрами:
>> подвижность;
>> мощность двигателя;
>> максимальная скорость;
>> скорость поворота;
>> скорость поворота башни;
>> бронирование/защищенность корпуса;
>> бронирование/защищенность башни;
>> оружие;
>> боекомплект;
системный администратор март 2014
Разработка
>> урон;
>> скорострельность;
>> броненепробиваемость.
Параметров для одного танка вполне достаточно, и если
использовать вложенные объекты в одном документе user,
то он может быть слишком большим по объему. И мы при-
дем к антипаттерну – глобальному объекту. Использование
очень больших объектов может отрицательно сказаться
на производительности БД.
Мы можем все танки выделить в одну коллекцию и ис-
пользовать ссылки на документ tank. Однако можно завести
на каждого пользователя по индивидуальной коллекции, на-
пример, tanks_user_123, и давать ссылку на эту коллекцию:
{
"_ id" : ObjectId("52cc2462d47566cbb0e20ff6"),
"nick" : "Василий Теркин",
"avatar" : "27AE/271.jpg",
"weapon" : {
"id" : 27,
"power" : 127,
"reserve" : 10
"experience" : 10
},
"position" : {
"x" : 453,
"y" : 74
},
// ссылка на коллекцию документов с танками
"tanks" : ObjectId("52cae653d47566cbb0e20fed")
}
***
Необходимо напомнить, что денормализация увеличивает
скорость доступа к данным, но оборотной стороной меда-
могут занимать много памяти, в частности, оперативные бу-
феры БД, занятость которых взаимосвязана со скоростью
исполнения запроса. Слишком громоздкие объекты созда-
вать и хранить не стоит, особенно если планируется исполь-
зовать не весь объект, а только какие-то незначительные
его части. Для этого можно использовать ссылочные типы.
Но следует помнить, что MongoDb не является реляционной
СУБД и операции объединения и соединения таблиц не про-
изводит. Эту функциональную возможность придется реа-
1. Календарев А. Индексы в MongoDb. //«Системный админист-
ратор», №1-2, 2014 г. – С. 94- 97.
2. Официальный сайт MongoDB – http://www.mongodb.org.
3. Документация (русский) MongoDb – http://ru.wiki.mongodb.org/
display/DOCS/Home.
4. Интерактивное обучение от 10Gen (англ.) – http://
www.10gen.com/what-is-mongodb.
5. Karl Seguin. The little MongoDb book. – http://openmymind.net/
mongodb.pdf.
6. Karl Seguin. The little MongoDb book. Перевод на русский –
http://jsman.ru/mongo-book.
7. Kristina Chodorow, Michael Dirolf. MongoDb: The Definitive
Guide – http://books.google.com.
8. Кайл Бэнкер. MongoDb в действии. – ДМК «Пресс», 2012 г.
Ключевые слова: MongoDb, СУБД, денормализация.
49
 Разработка веб-технологии

Визитка

Михаил Ушаков, разработчик электронной аппаратуры и программного

обеспечения для ядерной гаммарезонансной спектроскопии, Уральский
федеральный университет, um.nix.user@gmail.com

Меньше кода, больше дохода

Часть 2. Разработка back-end слоя
Продолжаем изучать веб-фреймворк Tapestry для создания Java EE-приложений.
Рассмотрим некоторые вопросы, связанные с разработкой back-end слоя (серверная
часть веб-приложения). Этот слой включает в себя систему для работы с базами
данных, инструменты для аудита (логирование и т.д.) и многое другое

В прошлой части [1] мы научились создавать Java EE- <property name="hibernate.connection.pool_size">10 ↵

приложения с использованием веб-фреймворка Tapestry, </property> (файл hibernate.cfg.xml).

собирать веб-приложение с использованием Apache Maven,

добавлять отдельные компоненты или даже фреймворки
с помощью файла pom.xml, а также рассмотрели базовые
вопросы, связанные с конфигурированием веб-приложе-
ний с Tapestry. Теперь рассмотрим, как можно использовать
ORM (object relation mapping) Hibernate для работы с MySQL
базами данных и систему логирования Log4j (логгер) в ка-
честве back-end слоя (см. рис. 1). Конечно, в качестве слоя
для работы с базой данных можно использовать и другие
варианты, например, использование JDBC-драйвера на-
прямую, Spring Framework, db4o и т.д. Однако с помощью
Hibernate в подавляющем большинстве случаев можно
обойтись без конструирования SQL-запросов, а передавать
объекты методам Hibernate.
Объекты и их связь с базой данных
В [1] мы сконфигурировали Hibernate таким образом, чтобы
веб-приложение запускалось, теперь потребуется выпол-
нить более детальную конфигурацию. В частности, настро-
ить размер пула соединений с базой данных (число заранее
установленных соединений).
Поскольку общие настройки hibernate уже были выпол-
нены, остается описать объекты, с которыми будет работать
Hibernate. Для этого hibernate.cfg.xml необходимо добавить
ссылки на xml-файлы, описывающие отображение объектов
на таблицы баз данных:
<!-- 1. Entities for working with users -->
<mapping resource="./db/entities/users/User.hbm.xml"/>
<mapping resource="./db/entities/users/Token.hbm.xml"/>
<!-- 2. Entities for working with helpdesk -->
<mapping resource="./db/entities/helpdesk/Product.hbm.xml"/>
<mapping resource="./db/entities/helpdesk/ ↵
ProductAttachment.hbm.xml"/>
<mapping resource="./db/entities/helpdesk/ ↵
ProductIssue.hbm.xml"/>
<mapping resource="./db/entities/helpdesk/ ↵
IssueAttachment.hbm.xml"/>
<!-- 1. Entities for working with forum -->
<mapping resource="./db/entities/forum/ ↵
ForumSection.hbm.xml"/>
<mapping resource="./db/entities/forum/ ↵
ForumTopic.hbm.xml"/>
<mapping resource="./db/entities/forum/TopicPost.hbm.xml"/>

Рассмотрим на примере сущности User (файл User.hbm.

Рисунок 1. Представление веб-сервиса в виде двух слоев front-end и back-end
xml). Сущность User проецируется на таблицу Users, ко-
торая была создана с помощью следующего sql-скрипта
(структура таблицы не претендует на идеальность):

CREATE TABLE `Users` (

`Id` INT NOT NULL AUTO_INCREMENT,
`Login` VARCHAR(100) NOT NULL,
`FirstName` VARCHAR(100) NOT NULL,
`LastName` VARCHAR(100) NOT NULL,
`City` VARCHAR(100) NOT NULL,
`Email` VARCHAR(100) NOT NULL,
`PasswordHash` VARCHAR(1000) NOT NULL,
`GroupMembershipMask` INT NOT NULL,
`RegistrationDate` DATETIME NOT NULL,
`Activated` BIT NOT NULL,
`Avatar` BLOB NULL,
`AvatarFileName` VARCHAR(260) NULL,

50 март 2014 системный администратор

 веб-технологии Разработка

CONSTRAINT `PK_UserId` PRIMARY KEY (`Id`) public String getLogin()

) {
COLLATE='utf8_general_ci' return login;
ENGINE=InnoDB; }
public void setLogin(String login)
{
Файл User.hbm.cfg описывает соответствие между типа-
this.login = login;
ми данных сущности (Java-классов) и типами данных в таб- }
лице, а также какие поля являются первичными ключами public String getFirstName()
{
таблицы и при наличии связей с другими таблицами. Содер- return firstName;
жимое файла User.hbm.cfg: }
public void setFirstName(String firstName)
<?xml version="1.0" encoding="UTF-8"?> {
<!DOCTYPE hibernate-mapping PUBLIC ↵ this.firstName = firstName;
"-//Hibernate/Hibernate Mapping DTD 3.0//EN" ↵ }
"http://www.hibernate.org/dtd/ ↵ public String getLastName()
hibernate-mapping-3.0.dtd"> {
<hibernate-mapping package="org.hibernate.tutorial.domain"> return lastName;
<class name="com.mushakov.uralsmessbauerportal. ↵ }
db.entities.users.User" table="Users"> public void setLastName(String lastName)
<id column="Id" name="id" type="java.lang.Integer"> {
<generator class="increment"/> this.lastName = lastName;
</id> }
<property column="Login" name="login" ↵ public String getCity()
type="java.lang.String"/> {
<property column="FirstName" name="firstName" ↵ return city;
type="java.lang.String"/> }
<property column="LastName" name="lastName" ↵ public void setCity(String city)
{
type="java.lang.String"/>
this.city = city;
<property column="City" name="city" ↵
}
type="java.lang.String"/>
public String getEmail()
<property column="Email" name="email" ↵
{
type="java.lang.String"/>
return email;
<property column="PasswordHash" name="passwordHash" ↵
}
type="java.lang.String"/>
public void setEmail(String email)
<property column="GroupMembershipMask" ↵
{
name="groupMembershipMask" type="java.lang.Integer"/>
this.email = email;
<property column="RegistrationDate" ↵
}
name="registrationDate" type="java.util.Date"/>
public String getPasswordHash()
<property column="Activated" name="activated" ↵
{
type="java.lang.Boolean"/>
return passwordHash;
<property column="Avatar" name="avatar" type="binary"/>
}
<property column="AvatarFileName" ↵
public void setPasswordHash(String passwordHash)
name="avatarFileName" type="java.lang.String"/>
{
</class>
this.passwordHash = passwordHash;
</hibernate-mapping>
}
public int getGroupMembershipMask()
В свойстве name поля class указано полное имя Java- {
return groupMembershipMask;
класса (все Java-классы должны быть POJO-классами с гет- }
терами и сеттерами). public void setGroupMembershipMask( ↵
Тэг id описывает поле первичного ключа, в данном случае int groupMembershipMask)
{
у нас первичный ключ генерируется базой данных путем ав- this.groupMembershipMask = groupMembershipMask;
томатического инкрементирования. }
Свойства column указывают имя колонки в таблице базы public Date getRegistrationDate()
{
данных, а свойство name – имя поля Java-класса. Обяза- return registrationDate;
тельно для каждого отображения необходимо указать тип }
данных, т.к. в процессе работы Hibernate использует приве- public void setRegistrationDate(Date registrationDate)
{
дение типов. Отображение типов SQL на типы данных Java this.registrationDate = registrationDate;
можно найти в [2]. }
public boolean getActivated()
Так выглядит класс User.java: {
return activated;
package com.mushakov.uralsmessbauerportal. ↵ }
db.entities.users; public void setActivated(boolean activated)
import java.util.Date; {
public class User this.activated = activated;
{ }
public int getId() public Byte[] getAvatar()
{ {
return id; return avatar;
} }
public void setId(int id) public void setAvatar(Byte[] avatar)
{ {
this.id = id; this.avatar = avatar;
} }

системный администратор март 2014 51

 Разработка веб-технологии

public String getAvatarFileName() Также методы Hibernate требуют, чтобы первичный ключ
{ был сериализуемым, поэтому я добавил ограничения на TId
return avatarFileName;
} в виде extends Serializable.
public void setAvatarFileName(String avatarFileName) Ключевым для работы Hibernate является понятие фабри-
{
ки сессий. Для использования Hibernate в Java-приложении
this.avatarFileName = avatarFileName;
} потребуется создать собственную фабрику сессий из кон-
private int id; фигурации Hibernate, однако в контексте Tapestry фабрика
private String login;
private String firstName;
сессий уже создана, и попытка повторного создания будет
private String lastName; приводить к вбрасыванию исключений.
private String city; За создание сессий в Tapestry отвечает интерфейс
private String email;
private String passwordHash;
HibernateSessionManager. Для использования этого встро-
private int groupMembershipMask; енного сервиса Tapestry можно сконструировать объект
private Date registrationDate; типа HibernateSessionManagerImpl (с набором специфичных
private boolean activated;
private Byte[] avatar = new Byte[0]; параметров в конструкторе) или воспользовавшись IoC:
private String avatarFileName;
} @InjectService("HibernateSessionManager")
private HibernateSessionManager sessionManager;

Слой для взаимодействия классов сущностей

с Hibernate Этот подход (использование IoC) реализован
Теперь нам понадобится слой для работы с объектами в моем классе DatabaseManager, реализующем интерфейс
(управление транзакциями и т.д.). IdatabaseManager:
В Java используют парадигму DAO (Data access object),
согласно ей есть интерфейс DAO, у которого имеются ме- public class DatabaseManager implements IDatabaseManager
{
тоды для непосредственной работы с базой, эти методы вы- public boolean open()
полняют SQL-операции SELECT, INSERT, UPDATE, DELETE {
// session we are getting from IoC
и т.д. И есть класс, имплементирующий этот интерфейс, ко-
session = sessionManager.getSession();
торый работает с методами Hibernate или методами другого return true;
слоя для работы с базой данных. }
public void close()
Соответственно на каждую сущность мы получаем 1 класс {
интерфейса и 1 класс имплементации, а если классов сущ- sessionManager.commit();
ностей, например, 10, то таких классов будет 20. Эти классы }
public <TEntity, TId extends Serializable> ↵
будут усложнять структуру проекта. TEntity getEntityObject (Class entityClass, TId id)
Не нужно плодить лишние DAO! Для решения за- {
дачи достаточно создать интерфейс (давайте назовем if(session != null && session.isOpen())
{
его IDatabaseManager) с обобщенными (generic) методами try
и имплементацию этого интерфейса DatabaserManager. {
Интерфейс IDatabaseManager может быть, например, та- TEntity entityObject = null;
entityObject = (TEntity) ↵
ким: session.get(entityClass, id);
return entityObject;
public interface IDatabaseManager }
{ catch(Exception any)
public boolean open(); {
public void close(); sessionManager.abort();
public <TEntity, TId extends Serializable> ↵ throw new UnknownError("An exception ↵
TEntity getEntityObject (Class entityClass, TId id); occurred during reading object " ↵
public <TEntity> List<TEntity> ↵ + any.getMessage());
getEntityObjectsList(Class entityClass);
public <TEntity> boolean ↵ }
updateEntityObject(TEntity entityObject); }
public <TEntity> boolean ↵ return null;
addEntityObject(TEntity entityObject); }
public <TEntity, TId extends Serializable> boolean ↵ public <TEntity> List<TEntity> getEntityObjectsList ↵
deleteEntityObject(Class entityClass, TId id); (Class entityClass)
} {
if(session != null && session.isOpen())
{
Данный интерфейс является универсальным и позволя- try
ет методам интерфейсов передавать объекты любых типов {
за счет использования generic-методов. List<TEntity> entityObjectsList = ↵
session.createCriteria(entityClass). ↵
К сожалению, в Java довольно плохо (отсутствуют ана- list();
логи оператора typeof в C#) с отражениями (Reflection), тип return entityObjectsList;
данных можно получить, используя свойство getClass(), }
catch(Exception any)
к которому нет доступа из обобщенного типа, т.е. нельзя {
сделать entityObject.getClass(), поэтому в некоторые методы sessionManager.abort();
throw new UnknownError("An exception ↵
потребовалось передавать тип данных объекта.

52 март 2014 системный администратор

 веб-технологии Разработка

occurred during reading list of ↵ occurred during adding object " + ↵

objects " + any.getMessage()); any.getMessage());
} }
} }
return null; return false;
} }
public <TEntity> boolean updateEntityObject(TEntity ↵ public <TEntity, TId extends Serializable> boolean ↵
entityObject) deleteEntityObject(Class entityClass, TId id)
{ {
if(session != null && session.isOpen()) if(session != null && session.isOpen())
{ {
try try
{ {
if(entityObject != null) Object entityObject = ↵
return false; getEntityObject(entityClass, id);
session.saveOrUpdate(entityObject); if(entityObject == null)
sessionManager.commit(); return false;
return true; session.delete(entityObject);
} return true;
catch(Exception any) }
{ catch(Exception any)
sessionManager.abort(); {
throw new UnknownError("An exception ↵ sessionManager.abort();
occurred during updating object " + ↵ throw new UnknownError("An exception ↵
any.getMessage()); occurred during deleting object " + ↵
} any.getMessage());
} }
return false; }
} return false;
public <TEntity> boolean addEntityObject( ↵ }
TEntity entityObject) private Session session;
{ @InjectService("HibernateSessionManager")
if(session != null && session.isOpen()) private HibernateSessionManager sessionManager;
{ }
try
{
if(session.contains(entityObject))
return false;
Данный класс заменяет все классы DAO, которые мог-
session.save(entityObject); ли бы потребоваться для работы с сущностями, конечно,
return true; в случае потребности в дополнительной функциональности
}
catch(Exception any) IDatabaseManager может быть с легкостью расширен. Те-
{ перь наш слой для работы с сущностями полностью готов,
sessionManager.abort(); добавим для него опцию для получения экземпляра сущно-
throw new UnknownError("An exception ↵
сти через IoC. В AppModule.java (опции развертывания app)

Рисунок 2. Отображение списка пользователей в Grid

системный администратор март 2014 53

 Разработка веб-технологии

в методе public static void bind(ServiceBinder binder) необхо- Поскольку в Tapestry все переменные класса при каждой
димо добавить следующую строку: перезагрузке страницы очищаются, а при загрузке вызыва-
ется метод onActivate(), то именно в нем мы получаем спи-
binder.bind(IDatabaseManager.class, DatabaseManager.class); сок пользователей, применяя databaseManager, помеченный
аннотацией @Inject. Tapestry генерирует Java-код по взаимо-
Теперь с помощью аннотации Inject мы можем добавлять действию компонента gtid на основе значений свойств дан-
наш сервис на страницы. ного компонента (следует отметить, что grid может быть раз-
Для тестирования сервиса создадим простую страницу мещен в Java-классе), и можно работать с компонентом Grid
с CRUD (Create-Read-Update-Delete) компонентом, постро- через его интерфейс, но для компактности Java-кода стра-
енным на базе Tapestry Grid, назовем страницу Users. Users. ницы я вынес все значения свойств Grid в разметку Users.tml:
java выглядит следующим образом:
<html t:type="layout" title="Users management tool"
public class Users xmlns:t="http://tapestry.apache.org/schema/ ↵
{ tapestry_5_3.xsd"
public void onActivate() xmlns:p="tapestry:parameter">
{ <p> Users management tools with CRUD! </p>
databaseManager.open();
currentUser = new User(); <table t:type="grid" t:source="servicesUsers" ↵
servicesUsers = databaseManager.↵ t:row="currentUser" rowsPerPage="5"
getEntityObjectsList(currentUser.getClass()); include="id, firstName, lastName, login, ↵
if(servicesUsers != null && ↵ city, email, groupMembershipMask,
servicesUsers.size() > 0) registrationDate, activated" ↵
currentUser = servicesUsers.get(0); t:add="action">
databaseManager.close(); <p:actionCell>
} <a t:type="pageLink" t:page="management/ ↵
public void onActionFromDeleteUser(int id) ViewUser" t:context="currentUser.id"
{ href="#">View user</a><br/>
databaseManager.open(); <a t:type="pageLink" t:page="management/ ↵
databaseManager.deleteEntityObject( ↵ EditUser" t:context="currentUser.id"
currentUser.getClass(), id); href="#">Update</a><br/>
databaseManager.close(); <a t:type="actionLink" t:id="deleteUser" ↵
} t:context="currentUser.id">Delete</a><br/>
@Inject </p:actionCell>
private IDatabaseManager databaseManager; </table>
@Property </html>
private List<User> servicesUsers = new ↵
ArrayList<User>();
@Property В Grid есть свойство t:source, указано имя коллекции эле-
private User currentUser; ментов из Java-класса (но данная коллекция должна быть
}
помечена аннотацией @Property или должен быть метод

Рисунок 3. Редактирование пользователя с помощью BeanEditForm-компонента

54 март 2014 системный администратор

 веб-технологии
List<User> getServicesUsers()), а t:row строка, с которой идет
работа в данный момент (здесь также используется поле
Java-класса: currentUser). Результат отображения списка
пользователей на странице Users.java представлен на рис. 2.
Аналогичным образом IDatabaseManager используется
на страницах CreateUser, EditUser и ViewUser. Страницы
Create и Update я реализовал с помощью стандартного
Tapestry-компонента BeanEditForm (см. рис. 3), а ViewUser –
с помощью BeanDisplay (см. рис. 4).
Логирование
Для логирования необходимо добавить с помощью IoС
Tapestry логгер (log4j):
@Inject
private Logger logger;
Необходимо вызывать методы logger.info(), logger.warn(),
logger.error() или logger.debug() для логирования на соот-
ветствующем уровне. По умолчанию вывод будет осущест-
вляться в консоль контейнера сервлетов Apache Tomcat.
Для записи журнала в файл потребуется настроить аппен-
деры в файле конфигурации log4j (log4j.properties) [3].
Логирование в файл циклический перезаписываемый
после превышения его размера (RollingFileAppender) может
быть настроено следующим образом:
log4j.rootCategory=INFO, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=[%p] %c{1} %m%n
log4j.category.org.apache.tapestry5.TapestryFilter=info
log4j.category.org.apache.tapestry5=error
log4j.category.tapestry5=error
#### Second appender writes to a file
Рисунок 4. Просмотр данных о пользователе с помощью BeanDisplay-компонента
системный администратор март 2014
Разработка
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=${catalina.home}/logs/testsecurity.txt
# Control the maximum log file size
log4j.appender.R.MaxFileSize=10MB
# Archive log files (one backup file here)
log4j.appender.R.MaxBackupIndex=1
log4j.appender.R.layout=org.apache.log4j.PatternLayout
#log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
log4j.appender.R.layout.ConversionPattern=%p [%t] ↵
%d{dd MMM yyyy HH:mm:ss} (%F:%L) - %m%n
***
Мы рассмотрели некоторые моменты, связанные с настрой-
кой back-end для Java веб-приложений, использующих
фреймворк Apache Tapestry. Я хотел показать, как наибо-
лее компактно и эффективно организовать взаимодействие
Java-классов с ORM Hibernate. Для демонстрации было
создано несколько страниц со стандартными компонента-
ми фреймворка Tapestry. Следующие статьи, посвященные
Tapestry, будут о настройке front-end (передача данных меж-
ду страницами, создание и использование компонентов,
поддержка REST), подключение современных JavaScript
и CSS-фреймворков, а также, возможно, тестировании Java
EE-приложений на примере Tapestry-приложения. EOF
1. Ушаков М. Меньше кода, больше дохода. Часть 1. Основные
особенности, создание проекта и конфигурирование. //«Сис-
темный администратор», №1-2, 2014 г. – С. 98-101.
2. Отображение типов SQL на типы данных Java – http://www.
tutorialspoint.com/hibernate/hibernate_mapping_types.htm.
3. Документация по log4j – http://logging.apache.org/log4j/1.2/
publications.html, http://www.javaworld.com/article/2076243/java-
se/log4j-delivers-control-over-logging.html.
Ключевые слова: Tapestry, фреймворк, back-end, Java.
55
 Разработка особенности языка

Визитка

Иван Шихалев, фрилансер, специализируется

на веб-разработке и Ruby, shikhalev@gmail.com

Ruby и многозадачность
В статье рассматриваются основные средства работы с потоками (threads)
и процессами в языке и стандартной библиотеке Ruby

Прежде чем перейти к описанию инструментария отмечу, ресурсов – нам остается вполне доступен, таким образом,
что Ruby создавался не как специальный язык параллель- польза от использования потоков в Ruby, безусловно, есть.
ного программирования, хотя в это время многозадачность Работа с потоками в Ruby в основном сосредоточена
уже стала привычной и необходимой. Из этих двух посылок, в классе Thread – в самом простом случае мы создаем объ-
в общем-то, можно вывести текущую картину: никаких спец- ект этого класса из блока (или множество объектов) и ждем
ифических концепций мы в нем не увидим, только поддерж- завершения [1].
ку привычной для всех языков общего назначения модели
с некоторыми нюансами реализации. puts 'begin'
th = Thread.new do
Немного о терминологии: англоязычный термин «thread» (1..3).each { |i| puts i }
на русский переводится в двух вариантах – как «поток» end
# sleep 0
и как «нить». Второй вариант точнее и не вызывает неод-
puts '---'
нозначности с потоками данных (streams), однако первый th.join
уже прижился в качестве основного. Кроме того, есть еще puts 'end'
производные термины и варианты вроде «многонитевость»
(или «многонитность»), но они мне не встречались и, честно Результат будет такой:
говоря, режут глаз. Поэтому я буду использовать «поток».
begin
---
Многопоточность 1
Потоки позволяют программисту распараллелить выполне- 2
3
ние задачи в рамках одного процесса. Это дает заметный
end
выигрыш в двух основных случаях: во-первых, когда есть ап-
паратные ресурсы для параллельных вычислений, т.е. мно- Если же мы раскомментируем строчку «sleep 0», то по-
гоядерная или многопроцессорная архитектура. Во‑вторых, ложение строки с дефисами относительно цифр станет не-
когда какие-то подзадачи вынуждены тратить время на ожи- предсказуемым, а если вместо ноля напишем «1» или даже
дание внешних ресурсов, будь то дисковая подсистема, «0.1», то дефисы будут стабильно выводиться после тройки,
сеть или действия пользователя. поскольку поток полностью отработает раньше.
Плохая новость в том, что в действительности потоки Что еще можно сделать с потоком, кроме как запустить
Ruby не параллельны, и выигрыша от многоядерности нам его и дожидаться завершения (именно это делает метод
получить не удастся. Несмотря на то что актуальные версии join)? Можно его приостановить (метод класса Thread.stop,
интерпретатора используют потоки операционной системы, вызываемый внутри потока), «разбудить», т.е. продолжить
управление ими построено так, что в определенный момент выполнение с момента остановки (wakeup), прекратить,
времени выполняется только один поток. В старых версиях не дожидаясь окончания работы (terminate)... Такой пример:
(по 1.8.7 включительно) использовались так называемые зе-
леные потоки, исполняющиеся в рамках одного системного, th = Thread.new do
puts 'started'
в новых действует механизм GIL (global interpreter lock). Thread.stop
Хорошая новость то, что этот механизм защищает от не- puts 'continued'
sleep 100
которых (но не всех) потенциальных конфликтов между по-
puts 'finished'
токами. Ниже о синхронизации еще поговорим, а пока от- end
метим, что второй выигрыш – в случае ожидания внешних sleep 0.1

56 март 2014 системный администратор

 особенности языка Разработка

puts 'wakeup' end

th.wakeup end
sleep 0
puts 'terminate'
th.terminate В более сложных случаях, когда у нас, например, две пе-
th.join
ременные, обращение к каждой из которых нужно синхро-
низировать независимо друг от друга, следует использовать
Даст следующий вывод: объекты класса Mutex и их метод synchronize.

started alpha = true

wakeup alpha_m = Mutex.new
continued beta = true
terminate beta_m = Mutex.new
5.times do
Thread.new do
Причем, если мы закомментируем строку «sleep 0», alpha_m.synchronize do
то до «continued» дело может и не дойти. puts 'alpha' if alpha
alpha = false
end
Обмен данными между потоками beta_m.synchronize do
Во-первых, мы можем передавать блоку аргументы при соз- puts 'beta' if beta
beta = false
дании потока: end
end
Thread.new 1, 2, 3 { |a, b, c| ... } end

Во-вторых, в Ruby любой код возвращает какое-то значе-
ние, и результат выполнения блока мы вполне можем полу-
чить – для этого нужно использовать метод value вместо join.
В-третьих, блок, из которого создается поток, как и лю-
бой другой, образует замыкание, т.е. в нем можно обращать-
ся к любым данным, доступным в месте его объявления [2].
Однако нужно помнить о том, что разные потоки могут об-
ращаться к одним и тем же данным в произвольном порядке.
От одновременного обращения двух потоков к одной
переменной нас защищает GIL, о котором было сказано
выше, он же делает многие (но не все) стандартные методы
стандартных классов атомарными, но этого недостаточно.
Сколько раз выведет «true» следующий код?
Thread.exclusive делает то же самое, но при этом исполь-
зует один и тот же объект класса Mutex на все случаи.
Кроме такой безусловной синхронизации, объекты Mutex
позволяют и более гибко работать с блокировками – в каких-
то случаях не дожидаться освобождения заблокированного
объекта, а выполнить другие действия (например, вывести
сообщение об ошибке). А еще ручное блокирование/раз-
блокирование дает простор для глупых ошибок по невнима-
тельности, поэтому я бы не рекомендовал им пользоваться
без особой на то необходимости.
В-четвертых, мы можем получать и устанавливать так на-
зываемые переменные потока посредством методов thread_
variable_get/set.

flag = true th = Thread.new do

5.times do sleep 0.1
Thread.new do p Thread.current.thread_variable_get 'alpha'
puts 'true' if flag end
flag = false th.thread_variable_set 'alpha', :alpha
end th.join
end
Thread.list.each do |th| Сюда же отнесем обращение к переменным, принадле-
if th != Thread.current
th.join
жащим текущему «волокну» (fiber) потока – пример выше
end можно переписать так:
end
th = Thread.new do
sleep 0.1
Правильный ответ: непредсказуемо, если запустить p Thread.current['alpha']
скрипт достаточно много раз, можно увидеть все вариан- end
th['alpha'] = :alpha
ты от одного до пяти. Хотя проверка флага и присвоение
th.join
ему значения сами по себе атомарны и не вызывают кон-
фликтов, между ними легко может произойти переключение Это короче и нагляднее, но надо помнить, что в общем
между потоками. случае «волокна» могут меняться.
Самый простой способ обеспечить синхронизацию – ис- И, в-пятых, для потоков применимы описываемые ниже
пользовать метод Thread.exclusive, в предыдущем примере способы взаимодействия между процессами.
это бы выглядело так:
Отступление о «волокнах»
5.times do «Волокна» (fibers) имеют косвенное отношение к теме
Thread.new do
Thread.exclusive do статьи, но не упомянуть их нельзя, хотя бы из-за вышео-
puts 'true' if flag писанного обращения к fiber-local переменным. По сути,
flag = false
это сопрограммы, переключение между которыми проис-
end
ходит не средствами системы (или виртуальной машины),

системный администратор март 2014 57

 Разработка
а вручную. Еще их можно охарактеризовать как подпро-
граммы, выполнение которых при каждом вызове начинает-
ся с того момента, на котором было остановлено в прошлый
раз. Поясню примером:
f = Fiber.new do
current = Time.new
loop do
last = current
current = Time.new
Fiber.yield [last, current]
end
end
5.times do
p f.resume
sleep 1
end
В результате получим последовательность пар значений
времени предыдущего вызова и текущего. В целом это до-
вольно экзотический инструмент, которому в явном виде
не так-то просто найти практическое применение.
Дополнительно о потоках
Для группировки потоков существует класс ThreadGroup,
который не предоставляет никакой особой функциональ-
ности, кроме контроля над тем, чтобы каждый поток принад-
лежал одной и только одной группе. Не добавленный ни в ка-
кую группу явно поток принадлежит ThreadGroup::Default.
Все классы, упомянутые выше, принадлежат ядру языка
и загружаются автоматически, однако есть другие возмож-
ности, которые дают уже модули стандартной библиоте-
ки [3]. Так, «require 'thread'» предоставит нам классы Queue
и SizedQueue с функциональностью очереди, как ясно
из названия. Во втором случае объем очереди ограничен,
и при достижении ограничения помещение нового элемента
будет дожидаться, пока другой поток освободит место.
Еще одна полезная библиотека («require 'thwait'» и класс
ThreadsWait) позволяет ожидать завершения некоего набо-
ра потоков, как всех вместе, так и по очереди.
Процессы в Ruby
Собственно запуск программы на Ruby, как и на любом
другом языке, – есть запуск процесса. Он, в свою оче-
редь, может порождать дочерние и общаться как с ними,
так и с совершенно независимыми от него процессами.
Ключевое отличие дочернего процесса от потока – незави-
симое адресное пространство – разные процессы не могут
никаким образом обращаться к переменным друг друга.
С точки зрения программиста дочерние процессы де-
лятся на два принципиально разных вида: подпроцессы,
порождаемые из того же кода посредством fork, и внешние
программы. Как работает fork? В привычных языках типа
C это функция, в родительском процессе возвращающая
идентификатор дочернего, а в дочернем – ноль. В Ruby мож-
но ее использовать точно так же, однако более элегантно
воспользоваться вариантом с блоком, который и станет вы-
полняться в дочернем процессе.
pid = fork do
3.times do |i|
sleep 0.01
puts "Child [#{Process.pid}]: #{i}"
end
end
58
особенности языка
3.times do |i|
sleep 0.01
puts "Parent [#{Process.pid}]: #{i}"
end
Process.waitpid pid
Должен получиться примерно такой вывод:
Parent [9032]: 0
Child [9034]: 0
Parent [9032]: 1
Child [9034]: 1
Parent [9032]: 2
Child [9034]: 2
Что здесь важно помнить, так это то, что, хотя блок
при fork и является замыканием, он получает доступ
не к тому же окружению, в котором определен, а к его копии
на момент запуска. Таким образом, обмен данными посред-
ством внешних переменных невозможен, а вопрос о синхро-
низации не имеет смысла. Что касается внешних программ,
то для их вызова служит несколько методов:
spawn – асинхронный вызов, который нас и будет инте-
ресовать, возвращает идентификатор процесса;
system – синхронный вызов (т.е. метод дожидается за-
вершения), возвращает индикатор успешности вызова;
exec – синхронный вызов, в случае неудачи вызывает ис-
ключение;
`command` или %x{command} – самая простая фор-
ма – синхронный вызов, возвращает строку, соответству-
ющую выводу программы.
Таким образом, теме данной статьи соответствует только
spawn как асинхронный. Замечу лишь, что system и exec ис-
пользуют те же аргументы. Аргументы описываются так:
spawn(‹env,› command ‹, args›*, ‹options›) → pid
Вначале идет необязательный параметр, устанавливаю-
щий дополнительные переменные окружения, затем коман-
да, затем произвольное количество необязательных аргу-
ментов и, наконец, если последний параметр – хеш, из него
берутся опции, позволяющие управлять правами доступа,
текущим каталогом и, самое главное, перенаправлениями
ввода-вывода. В самом же простом случае достаточно ука-
зать только команду.
Сигналы
Процессы могут посылать друг другу сигналы и как-
то на них реагировать. Вообще сигналы – это скорее ме-
ханизм для общения операционной системы с процессами,
и большинство из них зарезервировано под специальные
нужды, однако кое-что можно задействовать и в прикладных
целях. Выглядит это, например, так:
child = fork do
count = 0
Signal.trap :USR1 do
count += 1
puts "Signal USR1: #{count}"
end
Signal.trap :TERM do
puts 'Signal TERM'
exit
end
sleep 1000
puts 'Ooops!'
март 2014 системный администратор
 особенности языка Разработка

end Можно создавать произвольное количество каналов и на-

Signal.trap :CHLD do значать их как выводу, так и вводу.
puts 'Child died.'
end
Process.kill :USR1, child Сокеты
sleep 0.01
Сокеты – это универсальный механизм взаимодействия про-
Process.kill :USR1, child
Process.kill :TERM, child извольных программ между собой, в том числе и по сети.
Process.wait Здесь уже неважно, как и где запускается процесс-собе-
седник, нужно только знать адрес и протокол обмена (фор-
В результате должно получиться: мат данных). Сам по себе стандарт сокетов довольно низко-
уровневый, так что подробное описание и примеры заняли
Signal USR1: 1 бы слишком много места. Отмечу лишь, что инструменты
Signal USR1: 2
Signal TERM работы с сокетами находятся в модуле «socket» стандарт-
Child died. ной библиотеки.
Кроме того, на сокетах основано взаимодействие уже
Метод Process.kill посылает сигнал, а Signal.trap устанав- максимального уровня – готовыми Ruby-объектами в биб-
ливает обработчик сигнала. При этом мы видим, что сигнал лиотеке dRuby, о которой я писал в одной из предыдущих
CHLD мы не посылали – его отправила система, уведомляя статей [4]. Здесь же стоит сказать, что dRuby позволя-
родительский процесс о завершении дочернего. Стоит об- ет обращаться к объекту в другом процессе (и, возможно,
ратить внимание на строку «sleep 0.01» между двумя от- на другой машине) как к локальному объекту Ruby со всеми
правками. Если ее закомментировать, то сигнал USR1 будет его методами, свойствами и т.д.
получен дочерним процессом только один раз, поскольку
на момент второй отправки первый еще не будет обрабо- Применение
тан – сигналы поступают в очередь и уже имеющиеся там Подведем итоги. При использовании потоков мы остаем-
не добавляются. ся в рамках одного процесса, что определяет как плюсы,
К сожалению, посредством сигналов мы можем сооб- так и минусы: с одной стороны, возможность использова-
щить процессу только о наступлении некоторого события, ния общих переменных, с другой, взаимная зависимость.
без подробной информации. А всю информацию между Дополнительный минус именно Ruby-реализации – глобаль-
процессами нужно передавать средствами ввода-вывода. ный блокировщик, из-за которого реально в любой момент
времени выполняется только один поток. Следует, однако,
Каналы ввода-вывода понимать, что GIL – это именно особенность реализации,
Общим способом для любых дочерних процессов будет пе- а не языка, независимые реализации, такие как, например
ренаправление ввода-вывода посредством каналов (pipes). JRuby и Rubinius, его не имеют, не исключено, что и будущие
Для внутренних подпроцессов это выглядит так: версии «эталонного» Ruby изменят свое поведение.
Оптимальный сценарий использования – распараллели-
rd, wr = IO.pipe вание ожидания: работа с сетью, фоновые действия, когда
child = fork do
rd.close один из потоков ждет и обрабатывает общение с пользова-
wr.write 'From Child' телем, файловые операции. Основным средством взаимо-
wr.close
действия между потоками является использование общих
end
wr.close переменных (не забывая про синхронизацию).
msg = rd.read При запуске нескольких процессов получаем полный
rd.close
p msg
параллелизм, а вот средства коммуникации приходится
Process.wait прописывать отдельно. Соответственно лучше всего такой
сценарий поведет себя на максимально независимых зада-
Здесь существенно, что оба процесса первым делом за- чах, мало связанных, обмен данными между которыми мож-
крывают ненужные «концы» канала. Если этого не сделать, но свести к нескольким точкам. Взаимодействие строится
то возможны проблемы с некорректным определением кон- на каналах ввода-вывода для дочерних процессов и соке-
ца файла. тах/dRuby для независимых. EOF
В случае внешних команд все похоже, а «пишущий ко-
нец» канала передаем в специальном хеш-значении в по- 1. Полные тексты примеров находятся по адресу – https://gist.
следнем параметре spawn: github.com/shikhalev/9198544.
2. Шихалев И. Блоки и контекст в Ruby. //«Системный админист-
rd, wr = IO.pipe ратор», №1-2, 2014 г. – С. 111-115.
child = spawn "echo 'External Child'",
[ STDERR, STDOUT ] => wr 3. Подробную документацию на стандартную библиотеку можно
wr.close найти по адресу – http://rubydoc.info/stdlib (англ.).
msg = rd.read 4. Шихалев И. Распределенный Ruby. Прозрачный RPC для взаи-
rd.close
p msg модействия Ruby-программ. //«Системный администратор»,
Process.wait №12, 2013 г. – С. 58-61.

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

системный администратор март 2014 59

 Разработка
Визитка
Анна Сергеева, старший инженер службы обеспечения
качества Alloy Software Inc., annserge@rambler.ru
CamStudio в руках тестировщика
Применение видеофайлов на этапе разработки и отладки ПО
Предлагается улучшение менеджмента ИТ-проекта: на этапе разработки и отладки
ПО документацию о прохождении тестирования сохранять в форме видеоматериалов.
Это будет полезно программистам при фиксировании ошибок, обнаруженных
тестировщиками, и для создания презентаций и видеоинструкций
К слову о бережливом производстве
Есть два пути развития технологии:
Первый – экстенсивный. Он характеризуется миниму-
мом затрат, помноженным на максимум ручного труда.
Но так или иначе неизбежны затраты на зарплату, ком-
пьютерный ресурс, длительность процесса.
Второй – интенсивный. Здесь ручной труд сокращается
за счет привлечения вспомогательных программных ин-
струментов. Часть затрат идет на их приобретение, часть
на повышение зарплаты более квалифицированным со-
трудникам. Выигрыш такого подхода в сокращении чис-
ла ошибок и времени работы над проектом. Называется
это «бережливое производство» (Lean Manufacturing) [1].
В «правильных» ИТ-компаниях, разрабатывающих прог-
раммное обеспечение, руководство сосредотачивает силы
на том, чтобы на выходе получить продукцию наиболее вы-
сокого качества, насколько это возможно и целесообразно,
с наименьшими затратами времени, финансов и труда на-
емных работников. Поэтому автоматизации процессов про-
изводства уделяется все больше внимания.
При этом автоматизация бывает разная:
>> новостные корпоративные рассылки о запланирован-
ных мероприятиях и совещаниях;
>> оповещение работников о назначенных задачах и сро-
ках исполнения;
>> составление автоматических отчетов о проделанной
работе.
Разумеется, затрагиваются и сами процессы выполнения
рабочих задач программистов, технических писателей, те-
стировщиков, релиз-инженеров и далее по списку.
Все это призвано не только повысить качество готового
программного продукта, но и в значительной мере облег-
чить ежедневный труд команды специалистов, а также улуч-
шить их взаимодействие. Однако практика зачастую имеет
тенденцию расходиться с теорией.
Взгляд изнутри
Достаточно много лет я занимаюсь тестированием и часто
сталкиваюсь с такой ситуацией.
60
тестирование
Тестировщик в ходе своей работы находит тот или иной
дефект в исследуемой программе. Добавляет в багтрекер
новый тикет, где детально описывает проблему, настройки
и шаги по воспроизведению, при необходимости снабжая
тикет поясняющими скриншотами.
Далее тикет обрабатывается менеджерами проекта
и передается в разработку программистам. Результаты ис-
правлений попадают в новую сборку проекта, и менеджеры
возвращают тикет в тестирование. В соответствии с планом
работ, ориентируясь на описание тикета, а также на при-
мечания программистов по исправлениям, тестировщик
спокойно выполняет свою работу по проверке устранения
дефекта.
Теоретически до этого момента от тестировщика ника-
ких действий по данной конкретной проблеме не требует-
ся. В ожидании устранения дефекта он благополучно о нем
забывает и переключается на решение совершенно других
задач.
А что же на практике?
С момента создания тикета проходит время – в зависимости
от планирования проекта от пары дней до нескольких не-
дель, а иногда и того дольше.
Тестировщик уже давно сосредоточенно трудится
над очередной задачей или расслабленно отдыхает от вы-
полнения своего титанического самоотверженного труда,
и тут... И тут к нему приходит программист, которого менед-
жер проекта щедро назначил добровольцем по устранению
того самого дефекта, о котором у нас велась речь ранее.
И программист просит тестировщика наглядно воспро-
извести дефект еще раз, по шагам, показать, что и как тот
делал, какие диалоги вызывал, какие кнопки нажимал и т.д.
Возможно, описание проблемы в тикете было несовер-
шенным, или последовательность шагов описана не полно-
стью, или в не достаточно доходчивой форме, или этот про-
граммист – новичок в данном проекте. Мало ли что.
Вот и получается, что тестировщик вынужден терять кучу
времени, приостановив решение той задачи, над которой
он в настоящий момент трудится, вспомнить и понять, о чем
март 2014 системный администратор
 тестирование
конкретно его просит программист. Ну и воспроизвести,
разумеется...
Частично этих проволочек можно избежать, если к тикету
добавить скриншот с ошибкой, снабдив его поясняющими
надписями и выделив проблемный блок. Или если макси-
мально формализовано описать шаги по воспроизведению.
Но случается, что первого бывает недостаточно, второе же
отнимает неоправданно много сил и времени.
Разумеется, это актуально не для всех дефектов пого-
ловно, однако для описания наиболее проблемных из них
и в целях экономии времени можно записать последова-
тельность действий с программой, приводящих к ошибке,
с помощью видеоролика. А затем при описании проблемы
прикрепить его к создаваемому тикету.
Это помогает программистам понять суть ошибки, за-
меняет печать текста на полстраницы и сокращает время
работы, избавляет от необходимости бегать за разъяснени-
ями, а тестировщикам не придется лишний раз отвлекаться
от текущих дел. И вот именно здесь возникает переломный
момент. Ибо, имея такую технологию, можно шагнуть гораз-
до дальше. Перейти на качественно новый уровень работы
над всем проектом.
Поясним, в чем тут дело.
Видеоинструкции как замена текстовой
документации
Это раньше в комплекте с выпускаемыми программами шли
многотомные печатные инструкции. Их изучение было дол-
гим, муторным и неудобным. Да и к тому же, что скрывать,
мало кому интересным.
Рисунок 1. Профессиональный программный пакет Camtasia Studio
системный администратор март 2014
Разработка
Затем Интернет стал общедоступным и наполнился мас-
сой руководств в электронном виде. Все, что требовалось,
это запросить у поисковой системы описание нужной про-
граммы и выбрать наиболее подходящий текст: от беглых
обзоров для «чайников» до подробных технических доку-
ментов для специалистов.
Теперь же активно развивается новая тенденция.
Все больше и больше поставщиков программ размещает
в глобальной сети видеоинструкции и презентации своей
продукции.
Вот, например, на сетевом ресурсе [2] размещена бога-
тая коллекция демонстрационных видеозаписей по всевоз-
можным тематикам, связанным с ИТ: безопасность, сетевые
технологии, хранение данных, использование мобильных
устройств и т.д. Их легко найти, удобно просматривать,
и в сравнении с текстом они значительно выигрывают с точ-
ки зрения подачи материала и его восприятия.
Разумеется, современный пользователь, ограниченный
во времени и достаточно ленивый, охотнее потратит пару
минут на просмотр видео, нежели часами будет напряжен-
но листать скучный «талмуд», отчаянно пытаясь в нем ра-
зобраться. Почему бы запись видеоинструкций не начать
гораздо раньше, например, на этапе разработки и тестиро-
вания продукта?
И если прежде документом, фиксирующим ошибки про-
граммы, был текстовый файл, то теперь эти функции будут
переданы видеофайлу. А сопровождающий его текст боль-
ше не придется снабжать детальным описанием ошибки,
а лишь указывать в основном только ключевые моменты,
время возникновения и «симптомы» ошибки.
61
 Разработка
Что имеется в виду?
Во время тестирования тех или иных частей программы
можно использовать средства для видеозаписи действий,
происходящих на экране компьютера. Например, тести-
ровщик во время проверки какого-либо тикета включает
рекордер и фиксирует свои действия. Далее, вне зависи-
мости от исхода проверки, подключает к тикету небольшой
видеоролик. Таким образом, на сервере будет храниться
большой набор видеозаписей, которые можно использо-
вать по-разному.
Записи, связанные с тикетами со статусом Test Failed
(неуспех теста), могут использоваться программиста-
ми для понимания шагов воспроизведения ошибки. За-
писи же, связанные с тикетами со статусом Test Passed
(успех теста), принимаются службой маркетинга для мон-
Рисунок 2. Настройка формата выходных файлов для Demo Builder
Рисунок 3. Программа записи видео с экрана CamStudio
62
тестирование
тирования в различные видеоинструкции, презентации
и обучающие курсы.
Кстати, по желанию менеджеров проекта можно даже
настроить бизнес-логику багтекера таким образом, чтобы
при открытии тикета тестировщиком, запускался рекордер,
а при открытии программистом – проигрыватель с соответ-
ствующим видео.
Обзор рынка видеорекордеров
Для записи видеороликов, отражающих работу с компью-
терными программами, существует великое множество ин-
струментов. Тут уж есть из чего выбрать, и каждый наверня-
ка найдет то, что по душе именно ему.
Так, например, профессионалы, занимающиеся созда-
нием различных видеопрезентаций, чаще всего пользуют-
ся такими программными пакетами, как Camtasia Studio [3].
Он снабжен встроенным видеоредактором, который обла-
дает понятным и удобным интерфейсом для создания ви-
деороликов (см. рис. 1) с большим числом разнообразных
функций.
Также среди платных программ стоит отметить Demo
Builder. Разработчики программы [4] позиционируют
ее как вполне профессиональный инструмент для созда-
ния презентаций и обучающих курсов. Программа включает
различные средства редактирования, эффекты и средства
визуализации для создания флеш (см. рис. 2), добавления
примечаний, склеивания и разрезания роликов на отдель-
ные сцены и т.д. Готовые файлы сохраняются в формате
SWF или AVI.
Среди свободно распространяемых аналогов популярна
Fraps [5]. Сама по себе программа неплоха, однако имеет
несколько другой профиль. Она предназначена для съемки
роликов в видеоиграх и изначально ориентирована на ви-
део высокого разрешения и большой длительности (под-
держивает масштабные AVI-файлы размером более 4 Гб).
Скорее подойдет для тестирования качества отрисовки
графики исследуемой программой.
И это далеко не весь список. В общем, есть из чего выб-
рать. Есть и профессиональные инструменты с большим
числом функций, и относительно простые программы, с ко-
торыми справится даже новичок. Право выбора оставляю
за заинтересованным читателем.
И все же для начала стоит опробовать технологию в деле
и уж потом определиться с приобретением платного про-
граммного пакета или с установкой какого-либо свободно
распространяемого аналога.
Посему на первом, ознакомительном, этапе предлагаю
воспользоваться бесплатной программой CamStudio. Хотя
она не снабжена встроенным видеоредактором, однако
с записью видео с экрана вполне успешно справляется.
CamStudio
Программа CamStudio [6] (см. рис. 3) записывает все про-
исходящее на экране монитора в видеоролик формата AVI,
MP4 или SWF (флеш).
Основным ее достоинством является то, что для работы
совсем не нужно обладать какими-либо специальными про-
фессиональными знаниями по компьютерной анимации,
видеомонтажу и так далее. Человек, в нашем случае – те-
стировщик, совершенно далекий от мира компьютерной ки-
март 2014 системный администратор
 тестирование
ноиндустрии, в состоянии быстро и успешно начать с ней
работать.
Тем более это существенно, поскольку для тестировщи-
ка само создание ролика является вовсе не прямой целью,
а лишь удобным и быстрым вспомогательным средством,
которое должно существенно сэкономить его силы и время
в определенные моменты рабочего дня.
Перечислим предоставляемые возможности.
File. Главные кнопки рекордера: запись, пауза, стоп.
Region. Выбор области экрана для записи: фиксирован-
ная часть экрана, конкретное окно какого-либо приложе-
ния (подходит для записи работы различных визардов,
небольших диалогов, окон настройки), полноэкранный
режим.
Options. Опции для записи и настройки программы.
»» Video Options. Опции записи видео: выбор коде-
ка и параметров сжатия, частота кадров, привязка
аудио.
»» Cursor Options. Опции курсора: выбор его типа
и подсветки на записи, а также возможность скрыть
курсор.
»» Audio Options. Настройка параметров динамиков
и микрофона для записи звука, настройка синхро-
низации аудио и видеокадров.
»» Record audio from... Группа опций для выбора ис-
точника записи аудио: от микрофона, от динамиков,
без аудио. В стандартной ситуации работы в офисе,
системный администратор март 2014
Разработка
как правило, нет возможности снабжать записывае-
мое видео голосовыми комментариями, поэтому оп-
цию стоит отключить.
»» Autopan. В этом режиме область захвата следует
за указателем мыши, скорость следования также
настраивается.
»» Automatically Stop Recording. Автоматическая
остановка записи ролика по таймеру. Удобно для за-
писи серии нескольких коротких однотипных роли-
ков.
»» Program Options. Настройки программы. Здесь
можно задать характер поведения окна программы
во время и после записи; изменить формат имен,
создаваемых готовых и временных файлов, и ка-
талог их размещения; настроить горячие клавиши
на какие-либо действия с программой и т.д. Так, на-
пример, опция Minimize program on start recording
(минимизировать программу при старте записи)
удобна при записи полноэкранного видео, а также
если монитор не отличается большим разрешением.
Play AVI file when recording stops позволяет воспро-
извести ролик сразу после его записи, с выбором
из перечня доступных проигрывателей: системный
или встроенный CamStudio PlayerPlus.
»» Record To Flash Options. Опции, связанные с пре-
образованием записи из формата AVI в SWF.
»» Language. Выбор языка интерфейса программы.
63
 Разработка тестирование

Tools. Набор инструментов для работы над видеороликом.
Screen Annotations. Возможность добавления при-
мечаний на экран непосредственно во время записи
(см. рис. 4). Примечания отображаются в виде цветных
картинок с редактируемым текстом. Шаблоны этих кар-
тинок загружаются из библиотек, поставляемых вместе
с CamStudio. При желании можно изменять их размер
и прозрачность и даже сохранять в виде пользователь-
ских библиотек шаблонов. Готовое изображение с тек-
стом остается только расположить в нужной части экра-
на и снять на видеоролик. Здесь удобно использовать
горячие клавиши.
Video Annotations. Возможность добавления видеопри-
мечаний. Их источником служит изображение с веб-ка-
меры компьютера. Величина разрешения видео настра-
ивается.
Рисунок 4. Текстовые примечания на видео улучшают восприятие
»» CamStudio Movie Player. Вызов встроенного про-
игрывателя видеороликов.
»» SWF Producer. Вызов встроенной утилиты для пре-
образования видеозаписи из формата AVI в SWF.
Окно настройки параметров преобразования при-
ведено на рис. 5. Как правило, в результате полу-
чается файл меньшего размера, который удобно
передавать через Интернет и хранить на сервере.
Разработчики CamStudio заявляют, что в среднем
для файлов AVI небольшого разрешения размер
файла SWF составит около 30%, а для файла AVI
большого разрешения размер SWF будет около 5%.
Также есть возможность преобразования в флеш
без потерь (без снижения качества изображения
или частоты кадров).
Effects. Настройки эффектов для ролика: временных ме-
ток, водяных знаков и заголовков.
View. Выбор внешнего вида окна программы CamStudio.
На мой взгляд, удобен компактный режим (Compact), ког-
да отображаются только набор кнопок и главное меню
программы.
Help. Подробная помощь и информация о программе.

***
Использование видеорекордеров в ходе проектов разра-
ботки программного обеспечения решает сразу несколько
задач.
Во-первых, облегчается труд тестировщиков при опи-
сании обнаруженных дефектов. Также это помогает про-
граммистам вникнуть в суть ошибки, которую им требуется
исправить. В более широком смысле решается задача взаи-
модействия между подразделениями проекта: нет необхо-
димости в их непосредственном визуальном и вербальном
контакте, нет потерь по тайм-менеджменту.
Во-вторых, проект получает большой набор исходных
Рисунок 5. Настройка опций конвертации AVI/SWF
материалов для создания разноплановых видеоинструк-
ций, презентаций и обучающих курсов по продукту на бо-
лее ранних этапах работы над проектом (на стадии раз-
работки и тестирования) и от технически осведомленных
работников.
Грамотно составленные видеоинструкции весьма инфор-
мативны, полезны и удобны для восприятия. Размещение
таких роликов на специализированных или общих сетевых
ресурсах привлекает необходимую дополнительную целе-
вую аудиторию и положительно сказывается на рейтинге
проекта. EOF

1. О бережливом производстве – Monden Y. Toyota Production

System: An Integrated Approach to Just-In-Time //CRC
Press, 2011. – 4th Edition – 566 с.
2. Сайт видеосервера Demos On Demand – http://www.
demosondemand.com/it.
3. Сайт программы Camtasia – http://www.techsmith.com/camtasia.
html.
4. Сайт программы Demo Builder – http://demo-builder.com.
5. Сайт программы Fraps – http://www.fraps.com.
6. Сайт программы – CamStudio http://camstudio.org.

Ключевые слова: тестирование, автоматизация, бережливое про-

изводство, менеджмент проекта, видеозапись, видеоинструкция.

64 март 2014 системный администратор

 Наука и технологии

Жадов А.Д., Востриков А.В., Борисов Н.И., Тумковский С.Р.

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

Одними из важнейших проблем длительной эксплуатации
космических аппаратов (КА) являются электризация и связанные
с этим процессом электростатические разряды (ЭСР). В 30%
случаев потеря КА происходит из-за электризации. ЭСР порождают
токи на поверхности КА, которые наводят в бортовой кабельной
сети наводки величиной до 10 В. Помехи такой величины способны
привести к отказам бортовой радиоэлектронной аппаратуры.
Для сведения: к минимуму возможных сбоев электроники КА
необходимо смоделировать картину растекания тока по поверхности
КА. Далее проводится расчет наводок в кабелях и даются
рекомендации по их экранированию или оптимальному маршруту
прокладки. С этой целью в МИЭМ были разработаны структурная
электрофизическая модель (СЭМ) КА [1] и программное
обеспечение ПО «Satellite-MIEM» для ее реализации.
ПО «Satellite-MIEM» синтезирует структурную
электрофизическую модель (СЭМ) на базе заданной полигональной
3D-модели КА (см. рис. 1). Полигональная модель состоит
из совокупности элементарных фигур – треугольников
или прямоугольников, преобразуемых средствами программы
в поверхностную сетку: совокупность связанных узлов. Сетка
является равномерной, то есть шаги по всем координатам равны
Рисунок 1. Преобразование полигональной модели в СЭМ
между собой. Ячейка сетки представляется прямоугольником или
треугольником. Количество узлов СЭМ крупногабаритного КА
будет равняться (1…2)х105. Каждая связь (ветвь) представляется
в виде элементов электрической цепи (R, L, C), в целом образующих
эквивалентную электрическую схему поверхности КА. При этом
номиналы элементов одного типа одинаковы.
С помощью ПО «Satellite-MIEM», зная место электрического
разряда, можно получить картину растекания тока. Для расчета
переходных токов используется наиболее производительная
программа расчета электрических схем LTSpice, однако для анализа
схемы из 150 000 узлов требуется 83 часа (эксперимент проводился
на ЭВМ с двуядерным процессором с тактовой частотой 1,8 ГГц
на каждом ядре, объем оперативной памяти равняется 2 Гб) [2],
что неприемлемо для предприятий космической отрасли.
Используемые в ПО численные методы хорошо показывают себя
только при расчете небольших моделей [3]. Поэтому возникает
необходимость в создании новых методов расчета больших
электрических схем. Ранее в [4-6] был предложен новый подход
редукции модели линейной схемы, основанный на исключении
из модели подвекторов, содержащих в себе фазовые переменные,
значения которых не превышают 1-2% от величины приложенного
к месту разряда тока. В данной работе авторы разрабатывают
программу для реализации редуцированной вычислительной схемы
и проверяют теоретические оценки эффективности вычислительной
схемы на практике.

1. Построение редуцированной вычислительной схемы

Модель ЭЭС КА может быть сформирована в расширенном
однородном координатном базисе (РОКБ) и записана в виде
системы линейных обыкновенных дифференциальных
уравнений [4]:

, , (1)

где С, G – числовые матрицы порядка , – вектор

искомых фазовых переменных (напряжений во всех узлах схемы

66 март 2014 системный администратор

 Наука и технологии

и токов, протекающих через индуктивные элементы), – вектор Будем считать, что исходная задача имеет следующий вид:
входных сигналов.
Отметим специфику модели схемы. , . (11)
1) Матрица C является диагональной и вырожденной. Диагональ
состоит из двух групп коэффициентов и коэффициенты внутри При использовании численных методов процесс решения (11)
каждой группы одинаковы. заключается в вычислении вектора решения в моменты времени
2) Матрица G – невырожденная, симметричная и разреженная , т.е. , ,…, .
матрица. Рассмотрим одношаговый метод Эйлера для решения
3) Вектор содержит только один или два ненулевых задачи (11). Явный метод Эйлера решения системы уравнений
коэффициента вида , где i может быть любым числом от 1 до n. с учетом конкретного вида системы уравнений (11):
Необходимо с минимальными временными затратами выполнить
решение системы уравнений в момент времени t*, т.е. вычислить . (12)
числовой вектор .
Рассмотрим неявный метод Эйлера. С учетом конкретного вида
2. Редукция вычислительной схемы методов Эйлера системы уравнений (11) получим следующую формулу метода
Для решения задачи (1) формируется модель схемы в РОКБ Эйлера:
следующим образом:
. (13)

Для построения новой вычислительной схемы необходимо

, (2) преобразовать задачи (12) и (13) в некоторую редуцированную
модель (макромодель) КА, количество уравнений в которой
будет равно (второй этап редукции модели), что снижает
Отметим, что матрицы – симметричные, подматрицы C11, L22, трудоемкость вычислений на два-три порядка. Для этого запишем
G33 – диагональные, при этом: оба вида вычислительных процессов в блочной форме:
– подвектор напряжений в узлах, к которым подсоединены
конденсаторы;
– подвектор токов, проходящих через индуктивные , (14)
элементы;
– подвектор напряжений в узлах, к которым
не подсоединены конденсаторы. , (15)
Модель (2) записывается в виде:

, (3) где , .
, (4)
, (5) Пусть подвекторы и содержат по искомых
коэффициентов решения. Получим на базе выражений (14) и (15)
Исключаем из модели подвектор . Из (5) получим: редуцированную вычислительную схему, из которой исключим
подвекторы и .
, (6)

Подстановка из (6) в (3) и (4) приводит к следующим

выражениям: (16)

(7) или
(8)

или
.
(9),

3. Программная реализация редуцированной

где r – сопротивление резисторов в схеме.
Модель может быть записана в виде системы дифференциальных
уравнений, заданной в явной форме:
, (10)
где
вычислительной схемы
Для реализации редуцированной вычислительной схемы для
расчета линейных ЭЭС большой размерности нами было
разработано программное обеспечение, которое позволяет:
1) На первом этапе строить редуцированную вычислительную
схему.
2) На втором этапе проводить расчет картины растекания токов
по поверхности КА с помощью вычислительной схемы.

системный администратор март 2014 67

 Наука и технологии
Рисунок 2. Иерархическая структура разработанной программы
Рисунок 3. Пример результата конвертирования файла LTSpice в удобный для дальней-
ших преобразований матричный вид согласно (2)
68
Иерархическую структуру разработанной программы покажем
на рис. 2.
Разработанное ПО для получения требуемого результата
выполняет ряд этапов:
1. Конвертирование ЭЭС КА из программы LTSpice в удобный
для дальнейших преобразований матричный вид.
2. Преобразование матриц для ускорения скорости расчета
по редуцированной вычислительной схеме.
3. Расчет ЭЭС с помощью вычислительной схемы.
4. Трансляция файла полученных результатов и построение
модели КА с учетом картины растекания токов.
Рассмотрим алгоритм конвертирования файла LTSpice в удобный
для дальнейших преобразований матричный вид и результат его
выполнения (см. рис. 3):
1. Объявление и обнуление переменных и массивов, выделение
памяти.
2. Открытие файлов ввода данных и вывода результата (вывод
ошибки при невозможности открытия).
3. Построчное чтение файла и запись его в символьный массив.
4. Поиск в файле величины и узла включения источника
возмущающего воздействия.
5. Проход по всему массиву, нахождение в нем C-переменных
и запись их номиналов в массив С в порядке возрастания по
диагонали, подсчет количества С, фиксирование новых позиций
для С-переменных, поставить источник возмущающего воздействия
в узел включения первого из элементов С.
6. Проход по всему массиву, нахождение в нем L-переменных
и запись их номиналов с отрицательным знаком в массив С
в порядке возрастания по диагонали, после позиций элементов С.
7. Проход по всему массиву, нахождение в нем R-переменных
и узлов их включения. Если узел связан с фиксированной позицией
С, заменить его на номер этой позиции, иначе присвоить номер:
сумма всех элементов С + сумма всех элементов L + порядок
вставки. Порядок вставки увеличить на 1.
8. Заполнение массива G: считываем номиналы текущих
R и по данным из шестого шага узлам включения ставим их
Рисунок 4. Результат преобразования матрицы
март 2014 системный администратор
 Наука и технологии

на соответствующие позиции в матрице симметрично – На современном компьютере (ЭВМ с двуядерным процессором

G[узел1][узел 2]=-1/номинал; G[узел2][узел1]=-1/номинал, а также
заполнение диагонали соответствующих узлов (прибавление
к элементу диагонали величины, обратной номиналу).
Преобразования матрицы А (16) отличаются от предложенных
в [5], где была получена треугольная матрица с окаймлением
с помощью метода определяющих величин. Предложенный
алгоритм позволяет получить более выгодную с точки зрения
дальнейших вычислений треугольную матрицу, но посредством
арифметических операций со строками матрицы, вследствие чего
может быть потеряна точность вычислений. Алгоритм и пример
результата (см. рис. 4) приведены ниже:
1. Редукция матриц С и R.
2. Получение матрицы А путем перемножения матрицы G и C^-1.
3. Поиск в матрице А строк и столбцов, содержащих наибольшее
количество ненулевых элементов.
4. Нулевые строки поместить в низ матрицы.
5. Остальные строки расположить в порядке возрастания
количества элементов.
6. Расположить в порядке возрастания столбцы слева направо
в матрице А так, чтобы максимальные по модулю элементы
попадали на главную диагональ.
7. Нулевые элементы на диагонали исключить посредством
сложения строки с нулевым элементом на диагонали и строки
с максимальным элементом по модулю в этом же столбце.
8. Исключить ненулевые элементы над главной диагональю
посредством вычитания текущей строки от нижестоящей строки,
содержащей элемент диагонали в этом же столбце, и умножения
на коэффициент, равный отношению текущего элемента и найденного
ниже (идти по матрице необходимо с нижнего правого угла).
Рисунок 5. Время анализа модели ЭЭС разными методами
с тактовой частотой 1,8 ГГц на каждом ядре, объем оперативной
памяти равняется 2 Гб) проведены исследования временных
затрат на анализ модели ЭЭС, содержащей до 3000 обыкновенных
дифференциальных уравнений. Время анализа неявным методом
Эйлера, явным методом Эйлера и по предложенной новой
вычислительной схеме с учетом времени построения самой
вычислительной схемы показано на рис. 5. Для модели, состоящей
из 100 уравнений, неявному методу Эйлера потребовалось
0,16 с для анализа, расчет по новой вычислительной схеме
при размерности подматрицы (10х10) занял 0,012 с, что в 13 раз
быстрее (таблица 1). Для модели из 3000 уравнений расчет неявным
методом Эйлера потребовал 28397 с для анализа, вычисления по
новой схеме при размерности подматрицы (10х10) затратили 387,5 с,
что в 75 раз быстрее. В случае больших систем использование
редуцированной схемы оказывается выгоднее на два-три порядка
других неявных численных методов. При этом результат расчета
в выбранной локальной области традиционными численными
методами и по редуцированной вычислительной схеме совпадает.
Существенно отличается время анализа явным методом
Эйлера и по предложенной новой вычислительной схеме без учета
времени построения самой вычислительной схемы (такой вариант
используется при многократном использовании макромодели).
Для модели из 3000 уравнений явному методу Эйлера потребуется
51,3 с для анализа, вычисления по новой схеме при размерности
подматрицы (10х10) потребуют 0,005 с, что в 10 260 раз быстрее,
в случае подматрицы (100х100) вычисления по новой схеме
потребуют 2,9 с, что в 17,7 раза быстрее. На практике подматрица
будет содержать менее 1% коэффициентов от их общего количества
модели, поэтому выгода может достигать четырех порядков по
сравнению даже с явными численными методами.
Таким образом, результат тестирования подтвердил полученную
теоретически в [4] эффективность редуцированной схемы.
Практика показала, что расчет по вычислительной схеме больших
математических моделей происходит на два-три порядка быстрее
используемых в специализированном программном обеспечении
методов. EOF

Ключевые слова: алгоритм, редукция, система дифференциальных

уравнений, преобразование матрицы.

Software implementation of the reduced computational

schemes for the numerical integration of the system of linear
differential equations based on the methods of Euler

Jadov A.D., Vostrikov A.V., Borisov N.I, Tumkovskiy S.R.

The paper considers the implementation of the basic algorithms

Таблица 1. Результат тестирования численных методов на ПК for constructing the reduced computational schemes for the
numerical integration of the system of linear differential equations
Количество Время анализа Время анализа Время анализа модели by Euler's method. Shows the time and construction costs reduced
уравнений модели явным модели неявным по редуцированной by calculation scheme as compared with conventional numerical
модели методом методом Эйлера, с вычислительной
Эйлера, с схеме, с methods. Payment scheme for computing large mathematical models
100 0,11 0,16 0,012 occurs at 2-3 orders of magnitude faster used in specialized software
500 1,3 118,9 0,83 techniques.
1000 4,44 811 13,26
Keywords: algorithm, the reduction of the system of differential equations,
1500 9,6 4099 45,34
matrix transformation
3000 51,3 28697 387,5

системный администратор март 2014 69

 Карьера/Образование рынок труда

Вакансия: системный администратор Linux

Продолжаем публикацию цикла статей в помощь ИТ-специалистам, начинающим
и опытным, которые озабочены проблемой своего трудоустройства. На этот
раз мы обратились к представителям компаний, чьи сотрудники занимаются,
в частности, и администрированием операционной системы Linux. Расспросили,
какие требования они предъявляют к соискателям

1. Какими знаниями и навыками должен обладать системный администратор Linux?

2. Каков инструментарий системного администратора Linux?
3. Каковы требования компании к уровню образования потенциальных сотрудников?
4. Какие требования предъявляются к опыту работы?
5. Есть ли особые требования, которые обусловлены спецификой деятельности компании?

Кирилл Ковалев, (возможно, не имея опыта работы в хостинге вовсе) и далее

старший технический специалист FastVPS LLC прошли весь путь до незаменимого члена коллектива.

1 Такой сотрудник должен обладать значительным тех-

ническим кругозором, так как сетевые взаимодействия
подразумевают использование самых разных технологий,
относящихся к разным уровням OSI. Надо быть и немного ин-
женером-сетевиком, и веб-мастером. Однако так как знать
все попросту невозможно, то, пожалуй, самый важный на-
вык – это навык поиска необходимой информации.
5 Мы высоко ценим любовь к работе и стараемся подби-
рать именно таких людей в команду. Как правило, имен-
но увлеченные люди имеют в активе множество полезных
качеств – например, возможность работать в любое время
и в любом состоянии.
Если человек по-хорошему «болеет» своим делом,
то это несомненный плюс, мы требуем от наших сотрудни-
ков именно такого настроя.

3 На текущий момент дипломы иностранных учебных за-

ведений и просто специализированные сертификаты
рассматриваются, увы, с несколько большим вниманием,
чем полученные в странах бывшего СНГ. Впрочем, опыт по-
казывает, что любой диплом далеко не всегда говорит о на-
личии соответствующих знаний либо навыков.
По этой причине мы не ставим жестких требований по на-
личию профильного образования. При приеме на работу мы
в обязательном порядке стараемся разобрать устно какие-
то типичные задачи, а также предлагаем выполнить практи-
ческую часть повышенной (для неподготовленного челове-
ка) сложности.
Замечу также, что часть наших сотрудников имеет образо-
вание, вовсе далекое от IT, – например, бухгалтер-счетовод,
инженер по проектированию вентиляционных систем и т.д.
Юрий Трухин,
эксперт по облачным технологиям InfoboxCloud
1 «Сферический администратор в вакууме» должен вы-
брать одну определенную область и развиваться только
в ней. Чем меньше зона ответственности, тем глубже мож-
но погрузиться в тонкости. Однако подобное – фантастика,
так как, помимо кучи направлений, которые приходится за-
крывать, есть еще смежные области, без знания которых
работать крайне проблематично (например, связанные с се-
тью). Так что главными и основными особенностями являются
умение гибко мыслить («Ты же не Windows-администратор,
мысли вне рамок!»), желание учиться и развиваться, умение
быстро искать информацию и понимать, что ты находишь.

4 Основной упор при приеме на работу мы делаем на же-

лание осваивать предлагаемый фронт работ и резвость
мышления в целом, а не на практический опыт (хотя и ценим
его!).
Надо сказать, что намного удобнее для работодателя
растить своих сотрудников, хорошо понимающих тонкости
работы компании, чем устранять взаимные трения с уже
состоявшимся специалистом, привыкшим к иному порядку
работы.
У нас многие ключевые должности занимают люди, кото-
рые когда-то приходили на должность рядового сотрудника
И иметь огонь в глазах и море желания стать отличным про-
фессионалом. Главное – постоянно учиться и совершен-
ствовать результаты своей работы.
А базовые знания… Можно было бы назвать Apache,
MySQL и т.д., но мы часто склоняемся к мысли, что базо-
вых знаний не существует. Есть только то, с чем человек
работал и что знает сам, а подходит это для задачи или нет,
зависит от самой задачи.
2 Голова, консоль и поисковая система (именно в такой
последовательности). Все остальное опционально.
Разные задачи – разные инструменты. И даже для одной

70 март 2014 системный администратор

 рынок труда
и той же задачи разные админы могут выбрать разные ин-
струменты.
3 Обучаемость и общая адекватность. Плюс желание ав-
томатизировать максимальное количество процессов,
чтобы работать эффективнее. Хороший администратор
Linux – немного программист.
4 Желателен опыт работы в хостинге, но не принципиа-
лен. Мы легко сможем проверить ваш уровень знаний
в боевых условиях и сделать выводы.
5 Админ должен разбираться во всем. Понимать, как устро-
ен технологический стек с самых основ. Практически все,
где есть консоль, ложится на плечи Linux-админа – почтовые
серверы, LAMP, DNS, Perl, OpenVZ, ZFS, RAID и т.д. Список
можно продолжать долго. Вся сложность заключается в том,
что, помимо внутренних проектов, мы работаем с клиентами,
и зачастую клиенты генерируют весьма странные запросы,
с которыми тоже приходится разбираться. Поэтому умение
находить решения ранее нерешенных проблем важно.
Татьяна Бахаревская, заместитель руководителя
департамента эксплуатации Яндекса
1 Главные навыки системного администратора в Яндек-
се – быть ответственным и аккуратным, иметь желание
работать в команде, расти и развиваться. Без этого набора
качеств у нас работать сложно. Как говорилось в «Алисе
в Зазеркалье»: «Нам надо очень быстро бежать вперед, что-
бы оставаться на месте». Да и перед соседом по лестничной
клетке за неработающий сервис краснеть тоже не хочется.
Технически системный администратор должен знать, чем
команда top отличается от команды ps и зачем нужны файло-
вые системы /proc и /dev, то есть быть знакомым с операци-
онной системой Linux. Еще хорошо понимать, чем отличаются
протоколы tcp и udp и зачем нужна команда tcpdump, и не бо-
яться написать скрипт на bash. Это минимальный набор зна-
ний для начала работы системным администратором.
Если он у вас есть, то его можно и нужно наращивать, ре-
шая все более и более сложные задачи. Сейчас у нас в ком-
пании работает много специалистов, которые несколько лет
назад приходили новичками с базовым пониманием, а сейчас
стали гуру мирового уровня. Могут и ядро похачить, и про-
ектировать сервисы с учетом того, что нагрузка на них мо-
жет вырасти в несколько раз за год, предотвращать аварии
и быстро их устранять. Знают многое о сетевых протоколах
и современном оборудовании, программируют на C++, по-
нимают, когда применить Nginx и зачем нужны транзакции
в базах данных.
2 Наши любимые вопросы на собеседованиях: «Как быстро
проапгрейдить ядро и операционную систему на 100 оди-
наково настроенных серверах? А как быстро разложить про-
грамму, которую написал разработчик, на 100 серверах?
А если серверов 1000? А если больше, и они в разных да-
тацентрах, и пользователи не должны ничего заметить?
А как проверить, что новое ядро или новая программа рабо-
тает корректно на этих сотнях тысяч серверов?»
Это мы не для того придумали, чтобы жизнь потенциаль-
ным кандидатам усложнить. Это ежедневные и ежечасные
задачи, которые необходимо решать. Понятно, что все при-
ходится автоматизировать, автоматизировать и еще раз ав-
томатизировать. Есть опенсорсные продукты, которые у нас
системный администратор март 2014
Карьера/Образование
тоже используются (например, тот же Chef), но очень мно-
го инструментов написано внутри компании – для установки
серверов, обновления программного обеспечения на них,
мониторинга и аналитики работы сервисов.
3 Особых требований к уровню знаний нет. Главное, что-
бы было желание и опыт. Для тех, кто только хочет стать
системным администратором, у нас есть курсы информа-
ционных технологий. Мы открыли их несколько лет назад,
так как поняли, что готовых специалистов, умеющих работать
с такими сервисами, как наши, на рынке труда мало. И по-
нятно, почему так происходит. Систем, которые работают
по схеме 24х365, располагаются в нескольких датацентрах,
умеют при этом переживать отключение одного из них неза-
метно для пользователей и работать с большими объемами
данных на различных Open Source-технологиях, не так много.
Получить опыт работы с ними непросто. К тому же студенты
не особо идут в системные администраторы, так как думают,
что это в лучшем случае только поддержка офиса. Сложи-
лось так, что профессию программиста выбирают чаще, по-
тому что она понятнее.
Мы решили действовать и организовали для студентов
и молодых специалистов бесплатные курсы, где на лекциях
и практических занятиях можно многое узнать о системном
администрировании, операционной системе Linux и о том,
как с ее помощью мы решаем задачи в Яндексе. За все время
проведения курсов мы взяли на стажировку более 50 чело-
век. При этом мы не обязываем выпускников работать в Ян-
дексе, а растим кадры для всей индустрии.
Также мы проводим олимпиаду по системному админи-
стрированию Root (root.yandex.ru). Ее задачи – популяризи-
ровать профессию системного администратора и повышать
их квалификацию. Задания мы стараемся придумать послож-
нее – хотим, чтобы и наши студенты, и участники олимпиады
поняли, что работа администратора сложная, важная и инте-
ресная.
5 Конечно! Наш системный администратор – это не угрю-
мый нелюдим в грязном свитере с пивом, который нена-
видит всех пользователей, пришедших к нему с просьбой
«компьютер починить». Требований к дресс-коду у нас, ко-
нечно, нет, но при этом системный администратор – это часть
команды сервиса. Он регулярно общается с разработчиками,
инженерами по тестированию и менеджерами. Помогает раз-
рабатывать – обеспечивает команду разработческими и те-
стовыми средами. Думает о том, какое оборудование нужно
использовать в проекте, разрабатывает SLA для сервиса,
занимается установкой нового программного обеспечения
на продуктивные среды, автоматизирует свою работу, зани-
мается поиском неисправностей, резервированием и бэка-
пами, а главное – понимает, про что тот сервис, с которым
он работает, и постоянно думает о том, как его улучшить. EOF
Подготовил Игорь Штомпель
В номере 1/2 нашего журнала на стр.118
была допущена ошибка. На самом деле
должность Дениса Якубовича – руководитель
отдела персонала компании Promwad.
Мы приносим извинения нашему эксперту
и читателям.
71
 Карьера/Образование
Визитка
Валерия Чернецова, руководитель отдела аналитики
рекрутингового портала Superjob.ru
От каждого – по труду,
или Каким сисадминам больше платят
Исследовательский центр рекрутингового портала Superjob.ru изучил предложения
работодателей и ожидания претендентов на позицию «Системный администратор
UNIX» в Москве и Санкт-Петербурге
Компетенции системных администраторов включают
в себя конфигурацию, настройку и администрирование
серверов под управлением операционной системой UNIX/
Linux, а также персональных компьютеров и периферий-
ных устройств.
Системные администраторы отвечают за установку, на-
стройку и обновление операционной системы и программ-
ного обеспечения, поддержку локальной (LAN), глобальной
(WAN) и телефонной сетей.
Они осуществляют резервное копирование и восстанов-
ление данных, обеспечивают сохранность служебной ин-
формации, ведут техническую документацию и консультиру-
ют пользователей.
Операционная система UNIX распространена не так ши-
роко, как Windows. Работодателям сложнее найти соответ-
ствующих специалистов. Поэтому заработок системных
Типичный функционал
>>администрирование серверов под управлением ОС UNIX/Linux;
>>конфигурация, настройка и администрирование серверов;
>>конфигурация, настройка и администрирование персональных
компьютеров и периферийных устройств;
>>инсталляция, настройка, обновление ОС, прочего ПО;
>>поддержка локальной (LAN), глобальной (WAN), телефонной
сетей;
>>резервное копирование и восстановление данных;
>>обеспечение конфиденциальности и сохранности служебной
информации;
>>ведение технической документации;
>>консультирование пользователей;
>>взаимодействие с интернет-провайдерами и поставщиками
оборудования.
Портрет соискателя
>>33 года – средний возраст
>>100% – мужчины
>>73% – высшее образование
>>2,6 года – средний срок работы на последнем месте
>>22% – готовы к переезду
>>44% – на момент размещения резюме не имели работы
72
рынок труда
администраторов UNIX превышает доходы их коллег, адми-
нистрирующих Windows.
Одними из самых щедрых работодателей для сис-
темных администраторов являются компании сферы ИТ
и телекоммуникаций: средние рыночные зарплатные пред-
ложения в Москве составляют 83 000 руб., в Санкт-
Петербурге – 66 000 руб. в месяц.
Пробовать силы в качестве системного администратора
UNIX могут выпускники и студенты вузов (профильных либо
технических). Соискатели, впервые претендующие на эту
позицию, должны иметь хорошую теоретическую подготовку
в области защиты информации, знать серверное и сетевое
оборудование, принципы организации сетей и сетевых про-
токолов. Пригодится и знание «технического» английского.
ИТ и телекоммуникационные компании обещают на-
чинающим системным администраторам ОС UNIX
Зарплатный Требования и пожелания к профессиональным навыкам
диапазон
Диапазон I >>Высшее/неполное высшее образование (техническое, ИТ)
>>Базовые знания в области защиты информации
>>Знание принципов организации сетей и сетевых протоколов
>>Знание серверного и сетевого оборудования
>>Знание английского языка на уровне чтения технической
документации
Диапазон II >>Опыт администрирования UNIX/Linux-систем
>>Опыт работы системным администратором/помощником
системного администратора UNIX от одного года
Диапазон III >>Высшее образование (техническое/ИТ)
>>Уверенные знания в области защиты информации
>>Наличие профессиональных сертификатов
>>Знание основных типов сетевых атак и методов
противодействия им
>>Навыки программирования (Perl/PHP/C++/Shell и др.)
>>Опыт администрирования веб-серверов
>>Опыт администрирования MySQL/PostgreSQL
>>Опыт работы системным администратором UNIX от двух лет
Диапазон IV >>Опыт администрирования серверного оборудования
и серверного обеспечения в крупных компаниях
>>Опыт работы с оборудованием Cisco
>>Опыт работы системным администратором UNIX от трех лет
март 2014 системный администратор
 рынок труда Карьера/Образование

Одними из самых щедрых

работодателей для сисадминов
являются компании сферы
ИТ и телекоммуникаций

зарплату от 40 000 до 50 000 руб. в месяц в Москве,
от 32 000 до 40 000 руб. – в Санкт-Петербурге.
Рассчитывать на прибавку к окладу или рассматривать
вакансии с более высокими зарплатными предложениями
могут специалисты с опытом администрирования ОС UNIX/
Linux не менее года. Их доход достигает 60 000 руб. (Мо-
сква) и 48 000 руб. (Санкт-Петербург).
Наличие профессиональных сертификатов, стаж работы
более двух лет – таковы основные требования следующего
зарплатного диапазона.
Соискатели также должны быть компетентны в области
защиты информации, знать методы противодействия сете-
вым атакам, иметь опыт администрирования веб-серверов
и MySQL/PostgreSQL, навыки программирования.
Кандидатам, соответствующим этим требованиям, ИТ-
отрасль предлагает зарплату до 100 000 руб. в Москве
и до 80 000 руб. в Санкт-Петербурге.
Наиболее высоки зарплатные предложения крупных
предприятий. Такие работодатели требуют от кандидатов
наличия опыта администрирования серверного оборудова-
ния и серверного обеспечения в аналогичных компаниях.
Стаж работы системным администратором UNIX должен
составлять не менее трех лет. Максимальная величина
зарплатных предложений по данной вакансии составляет
в Москве 150 000 руб., в Санкт-Петербурге – 120 000 руб.
Чаще всего на должность системного администратора
UNIX претендуют молодые мужчины с высшим образовани-
ем. Женщин среди соискателей не набралось и 1%.
Средний возраст – 33 года.
73% специалистов имеют профильное либо техническое
высшее образование.
Системные администраторы – достаточно мобильные
специалисты: каждый пятый (22%) готов к переезду ради
работы в компании своей мечты.
Средний срок работы системных администраторов на по-
следнем месте составляет 2,6 года.
Менее половины соискателей являются безработными
на момент размещения резюме (44%), остальные ищут под-
работку либо новую работу на полную занятость, не уволь-
няясь со старого места. EOF

Строительство
Город / ИТ Промышленность
З/п диапазон Управление Услуги B2B Продажи В2В Продажи В2C
Отрасль Телекоммуникации Производство
недвижимостью
I Москва 40 000 – 50 000 40 000 – 50 000 35 000 – 45 000 35 000 – 50 000 35 000 – 50 000 40 000 – 50 000

СПб 32 000 – 40 000 32 000 – 40 000 28 000 – 36 000 28 000 – 40 000 28 000 – 40 000 32 000 – 40 000

II Москва 50 000 – 60 000 50 000 – 58 000 45 000 – 55 000 50 000 – 60 000 50 000 – 65 000 50 000 – 68 000

СПб 40 000 – 48 000 40 000 – 46 000 36 000 – 44 000 40 000 – 48 000 40 000 – 52 000 40 000 – 54 000

III Москва 60 000 – 100 000 58 000 – 95 000 55 000 – 90 000 60 000 – 100 000 65 000 – 100 000 68 000 – 95 000

СПб 48 000 – 80 000 46 000 – 76 000 44 000 – 72 000 48 000 – 80 000 52 000 – 80 000 54 000 – 76 000

IV Москва 100 000 – 150 000 95 000 – 150 000 90 000 – 130 000 100 000 – 140 000 100 000 – 140 000 95 000 – 130 000

СПб 80 000 – 120 000 76 000 – 120 000 72 000 – 105 000 80 000 – 110 000 80 000 – 110 000 76 000 – 105 000

Среднее Москва 83 000 77 000 75 000 75 000 82 000 76 000

(медиана)
СПб 66 000 62 000 60 000 60 000 66 000 61 000

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

системный администратор март 2014 73

 Карьера/Образование
Визитка
Сергей Барамба, начальник отдела системных решений
Департамента ИТ, ООО «БФТ», sbaramba@yandex.ru
10 формул для эффективного сисадмина
Путь из падаванов в гуру лежит через шрамы ошибок
Формулы есть не только в учебниках по химии или физике, но и в ИТ! Сегодня я хочу
поделиться теми, которые помогают мне работать и облегчают решение сложных задач
С чего все началось
Материал для статьи я начал собирать чуть больше месяца
назад. Каждая формула была отловлена и сформулирована
в ежедневной сутолоке дел, специально, потому что за этот
промежуток времени я ей воспользовался. Надо сказать,
они (формулы) так естественно вжились в мой повседнев-
ный уклад, что я как-то и не задумываюсь, просто пользу-
юсь…
Их оказалось чуть больше десятка, но я выбрал свои са-
мые любимые, заслуженные и полезные. Они работают!
Первая формула. Личное общение эффективнее
почтовой переписки
Эта формула помогает мне быть эффективнее коллег, ко-
торые решают абсолютно все рабочие вопросы, общаясь
через почту или СЭД. Время, которое потребуется для до-
стижения результата, при живом общении будет гораздо
меньшим. Если возникает проблема, решение которой мо-
жет затянуться, я беру трубку или встаю и иду к человеку
для того, чтобы ее обсудить. Это всегда сокращает путь
к достижению цели.
Конечно, для того, чтобы остались «следы» и докумен-
ты, никто не отменял проверенные механизмы, но количест-
во «транзакций» по согласованию вопросов уменьшается
в разы. Стиль изложения коллег зачастую оставляет желать
лучшего, порой письмо трактуется по-разному, и, если без-
думно приступить к выполнению просьбы, можно сделать
ненужную работу или пойти неправильным путем.
Проговорить и согласовать производственные моменты
проще, чем писать письмо и каждый раз нажимать кнопки
клавиатуры, изображая кипучую деятельность. При непо-
средственном общении разговор приобретает личност-
ную окраску, и, используя ее, можно склонить чашу весов
в свою сторону.
Ведь главное – получить результат, который устраивал
бы все заинтересованные стороны, занял минимум времени
и принес максимум пользы.
Эта формула имеет небольшое дополнение: сначала
письмо, потом звонок «в голову». Если я являюсь иници-
74
вектор роста
атором задачи, то сначала отправляю письмо, даю «вменя-
емое» время ознакомиться с ним, после чего обязательно
звоню или прихожу для личного обсуждения проблемы.
И обязательно начинаю с вопроса, все ли понятно в моем
запросе. Это помогает осуществлять «санитарный кон-
троль» моих писем, узнать какую информацию я упустил,
где возникли сложности с пониманием.
В разговоре я использую следующий алгоритм. Возник-
ший вопрос сразу же устно обсуждается после получения
письменного запроса. Далее – четкие устные договорен-
ности, затем они переносятся на бумагу или в электронный
вид и идут по маршруту на юридически значимое согласо-
вание.
Системные администраторы, которые избегают разго-
воров с коллегами, пользователями, на самом деле много
теряют. Теряют коммуникативные навыки, возможность сло-
вами «на лету» изложить свое видение вопроса, доказать
свою правоту или выдвинуть план действий.
Если личное общение не помогает достигнуть цели, я ис-
пользую вторую формулу.
Вторая формула. Говорите языком документов
Иногда мне приходится включать «режим юриста», дотошно
следуя буквам регламентов, инструкций, приказов и других
документов. Конечно, обязательно их внимательно изучить
и уметь цитировать. Такое бывает не только в случаях, когда
не удалось найти общий язык с коллегами. По неизведан-
ному пути порой лучше идти именно согласно требованиям
документов, по правилам.
Вероятность допустить ошибку, таким образом, меньше,
а если что-то пошло не так, то вас нельзя будет упрекнуть
в непрофессионализме. В горячих спорах я тоже переклю-
чаюсь в такой режим, стараясь максимально следовать
требованиям приказов и положений. Тогда почва для кон-
фликта улетучивается, и удается строить диалог конструк-
тивно.
Еще такой подход может оказаться полезным для выявле-
ния нестыковок и ошибок в документах, они могут устареть
или быть неактуальными. После того как обнаружены недо-
март 2014 системный администратор
 вектор роста
статки, обязательно надо приложить усилия, чтобы все ис-
править и актуализировать.
Третья формула. Все телепаты в отпуске,
вечном и не оплачиваемом
Там, где запрос вырван из контекста, не понятен и порож-
дает море вопросов, я применяю эту формулу и требую
разъяснений. Так уж устроен человек, что считает; если
все понятно и известно ему, то и соседи по цеху в курсе
всех мелочей. Но это отнюдь не так.
Общаясь с коллегами, я стараюсь повторить несколько
раз одни и те же тезисы обсуждаемой проблемы. В конце
диалога обязательно произношу фразу «А теперь подыто-
жим» и повторяю главное. Мне просто хочется быть уверен-
ным, что меня поняли правильно, что я не упустил из виду
какие-то мелочи или важный пункт в алгоритме.
А прежде чем отправить письмо, думаю, как меня поймут
и хватает ли в нем информации. Если вставить ссылку на до-
кумент или страницу портала, откуда следует начать поиски,
передать максимальное количество необходимой инфор-
мации, то будет минимум вопросов ко мне за уточнениями,
получится двойная экономия. Я не буду отвлекаться, мой
коллега сможет максимально правильно и четко выполнить
поставленную задачу.
Четвертая формула. Никаких «вроде»,
«возможно», «может быть», только проверенные
факты. Все свои «вроде бы» оставляем при себе!
Настоящий профессионал редко произносит подобные
слова. У него за спиной опыт, прежде чем дать ответ, все бу-
дет проверено, посчитано, несколько раз обдумано. Наши
знания и умения – это набор фактов, четкого понимания
сути явления. Тут незачем колебаться, это неэффективно
и наносит вред нашей репутации. Услышав подобные сло-
ва от своих коллег, я воспринимаю их как способ избежать
ответственности, нежелание думать и лишний раз все про-
верить.
Общение с подобной неуверенностью в профессиональ-
ных вопросах – признание собственной некомпетентности,
системный администратор март 2014
Карьера/Образование
Как мы думаем, как оцениваем
себя и окружающий мир,
в такой реальности и живем
а значит, необходимо, чтобы такие «слова-паразиты» по-
кинули ваш лексикон. Если хотим быть профессионалами
и эффективно работать, то придется брать на себя ответ-
ственность. А еще придется уметь отстоять свои слова, на-
учиться их ценить.
Итог: отвечаем четко, последовательно и следуем фак-
там.
Пятая формула. Делай вид, что у тебя
есть добродетель, даже если у тебя ее нет
Этот постулат вошел в список моих формул уже давно.
Слова принадлежат Шекспиру, и я часто озвучиваю их себе
и подчиненным. Формула на самом деле универсальна,
всегда можно убрать слово «добродетель» и заменить
на любое другое. В ней скрывается очень мощный инстру-
мент качественного решения новых задач и мотивирования
самого себя. «Делай вид, что ты высококлассный систем-
ный администратор, мыслящий о будущем, знающий от-
веты на все сложные вопросы, даже если ты не такой».
Примерив на себя такой образ, уже не захочется с ним
расставаться, уже не будет дороги назад. Это очень сти-
мулирует не расслабляться, двигаться вперед, всегда быть
в тонусе.
«Делай вид, что ты знаешь Linux, даже если ты его ни разу
не видел». «Делай вид, что ты умеешь программировать
на PowerShell, даже если никогда ничего не писал». Каждый
день жизнь подкидывает нам различные задачки, большие
и маленькие. ИТ достаточно сложно, и всего знать невоз-
можно.
А формула «Делай вид...» помогает нам стать и быть зна-
ющим и профессиональным системным администратором.
Это стимул думать, учиться, искать и побеждать, не отсту-
пать перед трудностями. Бороться с самим собой, со своим
неумением, слабостями в форме такой «театральной игры»
легче.
Сегодня вы примеряете такую успешную маску, но со вре-
менем маска вам уже не понадобится. Тут главное – иметь
здравый смысл, вовремя остановиться и не переиграть са-
мого себя.
75
 Карьера/Образование
Шестая формула. Успехи никто не оценит,
зато ошибку будут долго еще вспоминать
при удобном случае
Таков наш несправедливый мир. Надо просто с достоин-
ством принять это. Если постоянно себя грызть за ошибки
прошлого, то будет страх делать что-то новое, бороться.
Всегда проще тихонько отсидеться в уголке с 9 до 6 и ниче-
го нигде не сломать.
ИТ позволяет остановиться в развитии и существовать
в некотором стабильном состоянии, когда ничего нигде
не меняется и не происходит. А вот для того, чтобы разви-
ваться и двигаться вперед, необходимы мужество и опреде-
ленная смелость. Через шрамы ошибок и лежит путь из па-
даванов к гуру.
Седьмая формула. Обновляйте договоренности.
Забывчивость – стандартный диагноз каждого
сотрудника
Так уж устроена наша память, что старается не перегру-
жаться. Вот и установленные когда-то среди коллег догово-
ренности по качественному взаимодействию друг с другом,
если они не выполняются по несколько раз за день, доста-
точно быстро стираются из памяти.
Поэтому регулярно, раз в два-три месяца, я подстегиваю
и свою память, и память коллег, рассылая одно и то же пись-
мо с договоренностями, которое я бережно храню для таких
случаев. Благодаря ему я сам вспоминаю, что же необхо-
димо соблюдать. Пример таких договоренностей вы може-
те прочитать в №7-8 журнала «Системный аминистратор»
за прошлый год [1]. Ну и, конечно же, у меня не будет мо-
рального права требовать от коллег пунктуальности, если
я сам ничего не помню.
Я пересматриваю, не устарели ли положения данного
письма, не нужно ли что-либо подправить. Так я поддер-
живаю его актуальность, проводя «санитарный контроль».
В конце письма я обязательно добавляю: «Есть ли предло-
жения или дополнения?» Вдруг кто-нибудь увидел то, чего
не заметил я, или предложит новый пункт.
Ну и достраивать новое и вычеркивать устаревшее легче,
чем коллективно вспоминать, как мы договаривались, и кто
виноват, что все оказалось забыто.
Восьмая формула. Живой айтишник – это всегда
движение. Остановка смерти подобна
Не устаю повторять, что изменения в ИТ происходят на-
столько быстро, что нужно просто бежать, чтобы оста-
ваться в тренде и быть квалифицированным сотрудником,
а не пыльным мешком устаревших знаний. Такой «драйв»
подстегивает к изучению самых современных технологий,
тестированию и выбору наиболее новых приложений и ап-
паратных платформ.
А еще новейшие ИТ-технологии требуют наличия несла-
бых коммуникативных навыков и знаний эффективных прин-
ципов работы в команде. Поэтому часть свободного и даже
рабочего времени я обязательно бюджетирую для чтения
книг, ИТ-новостей и обзоров, ознакомления с новыми техно-
логиями. Новые дорогие железки нет нужды покупать, чтобы
пощупать.
Производители и вендоры регулярно дают возможность
бесплатно взять на тестирование почти любое оборудова-
76
вектор роста
ние. Достаточно только проявить интерес, договориться
и написать гарантийное письмо. И пару недель у вас будет
возможность все внимательно изучить и даже попробовать
использовать в боевой обстановке.
Обязательно, хотя бы раз в месяц, я выбираюсь на очные
мероприятия, где кратко и емко расскажут о новинках в об-
ласти ИТ.
Таким образом, я внутри себя поддерживаю некий уро-
вень «современности и актуальности» окружающих техно-
логий.
Девятая формула. Материализация мысли –
первый шаг к достижению результата
Все идеи и мысли, которые мне показались правильными
и полезными, я стараюсь занести на материальный носи-
тель. Бумажка, заметка в сотовом, схема на доске – где угод-
но, только не просто в памяти.
Я заметил за собой, что если оставить пришедшее в го-
лову только в мыслях, то со временем яркие и правильные
идеи гаснут, мысль становится не столь четкой. Вокруг
нас столько способов сохранить наши идеи, главное – по-
вторить себе формулу и не рассчитывать на свою память.
Если хорошая мысль пришла про сложную задачу, которой
не захочется заниматься, но сделать надо, сразу необходи-
мо отрезать мосты к отступлению. Лучше всего подойдет
«материализация» в виде почты руководителю. Теперь уже
не сослаться на свою забывчивость, а значит, первый шаг
к достижению результата будет сделан.
А еще я где-то прочитал поговорку: «Тупой карандаш луч-
ше острой памяти», и стараюсь не лениться и материализо-
вывать свои мысли.
Десятая формула. Помни о своих пользователях.
Сделай для них больше, чем они ждут
Пользователи – это не назойливые мухи, отвлекающие
своим жужжанием нас от важных проектов. Пользовате-
ли – это наши клиенты, из их мнения о нашей работе скла-
дывается общее впечатление о нас как сотрудниках. Ча-
сто и премиальный фонд и лояльность руководства очень
сильно зависят от оценки нашей деятельности. Да и само-
му приятно работать, понимая, что в нашей памяти ничего
не теряется и пользователи довольны. Это даст возмож-
ность сосредоточиться на сложных рабочих проектах. Уме-
ние строить с пользователями деловые отношения поможет
им более лояльно относиться к нашим промахам и невоз-
можности быстро удовлетворить запросы всех. А это край-
не полезно.
***
Каковы мысли в душе человека, таков и он (Библия, Прит-
чи 23:7). Как мы думаем, как оцениваем себя и окружающий
мир, в такой реальности и живем. Если пытаться в кругово-
роте рутинных событий выискивать пути лучше и качествен-
нее делать свою работу, это обязательно скажется на по-
следующих событиях нашей жизни.
Ищите себя, свои формулы, совершенствуйтесь –
это ведь так интересно. EOF
1. Барамба С. Ты-я-он-она. Вместе – целое ИТ-подразделение!
//«Системный администратор», №7-8, 2013 г. – С.110-113.
март 2014 системный администратор
 вектор роста
Разговор о преподавании информатики в школе
Однажды со мной произошел такой случай: накануне сессии знакомый попросил
объяснить своему сыну, студенту первого курса одного московского вуза, как работать
со ссылками на языке Си…
Студент, как оказалось, не понимал основополагающих
принципов хранения информации в памяти компьютера и,
как следствие, смысла адресации. На вопрос: «А что же
вы на информатике в школе проходили?» – ответом было:
«Да учитель по географии вел информатику».
И вот чуть больше года назад мне довелось окунуть-
ся в школьную жизнь. Вначале помогал в обслуживании
школьных компьютеров, а с 1 сентября 2013 года меня
представили коллективу как преподавателя информати-
ки и информационно-коммуникационных технологий (ИКТ)
старших классов.
Не буду расписывать, почему и как я оказался у школь-
ной доски. Проработав 15 лет на государственном пред-
приятии программистом/системным администратором
(как хотите, но на нашем предприятии приходилось делать
и то и другое), я познакомился с применением информаци-
онных технологий на практике, приобрел некоторый опыт,
однако никогда не пытался работать преподавателем. Но та-
кой эксперимент мне показался интересным.
Итак, вашему вниманию предлагаются заметки о том,
что же увидел человек, поработавший достаточное вре-
мя айтишником, в преподавании нашего с вами предме-
та в школе. Оговорюсь, что это чисто мое мнение, совсем
не претендующее на непререкаемую истину.
Заинтересованность государства
в ИТ‑грамотности школьников
Да, да. Она есть. Всем понятно, что нашей стране не хочется
быть сырьевым придатком. Еще 5 сентября 2005 года Пре-
зидент Российской Федерации Владимир Путин объявил
о старте четырех приоритетных национальных проектов, од-
ним из которых является проект «Образование».
Для тех, кто, может быть, еще не знает, – в России
с 2007 года в образовании действуют Федеральные государ-
ственные образовательные стандарты (ФГОСы). Как разъ-
ясняется на сайте Министерства образования и науки, об-
разовательные стандарты – это совокупность требований,
обязательных при реализации основных образовательных
программ начального общего, основного общего, среднего
системный администратор март 2014
Карьера/Образование
Визитка
Сергей Ильичев, ЧОУ «ТПКГ» г. Тула, системный
администратор и учитель информатики, sergil68@mail.ru
Чему и как у нас учат
(полного) общего, начального профессионального, средне-
го профессионального и высшего профессионального об-
разования образовательными учреждениями, имеющими
государственную аккредитацию [1].
Принципы построения Федерального базисного учебно-
го плана для 10-х-11-х классов основаны на идее двухуров-
невого (базового и профильного) федерального компонен-
та государственного стандарта общего образования. Таким
образом, предметы, в том числе и информатика, в школе
согласно стандарту изучаются на базовом и профильном
уровне. Также для учащегося есть возможность пройти
так называемый элективный курс, который тоже позволяет
изучать предмет углубленно.
Позволю себе процитировать Федеральный государ-
ственный образовательный стандарт среднего (полного)
общего образования (10-11 кл.) касательно углубленного
изучения предмета [2]:
«Информатика» (углубленный уровень) – требования
к предметным результатам освоения углубленного курса
информатики должны включать требования к результатам
освоения базового курса и дополнительно отражать:
1) владение системой базовых знаний, отражающих
вклад информатики в формирование современной научной
картины мира;
2) овладение понятием сложности алгоритма, знание ос-
новных алгоритмов обработки числовой и текстовой инфор-
мации, алгоритмов поиска и сортировки;
3) владение универсальным языком программирования
высокого уровня (по выбору), представлениями о базовых
типах данных и структурах данных; умение использовать ос-
новные управляющие конструкции;
4) владение навыками и опытом разработки программ
в выбранной среде программирования, включая тестирова-
ние и отладку программ; владение элементарными навыка-
ми формализации прикладной задачи и документирования
программ;
5) сформированность представлений о важнейших видах
дискретных объектов и об их простейших свойствах, алго-
ритмах анализа этих объектов, о кодировании и декодиро-
77
 Карьера/Образование
вании данных и причинах искажения данных при передаче;
систематизацию знаний, относящихся к математическим
объектам информатики; умение строить математические
объекты информатики, в том числе логические формулы;
6) сформированность представлений об устройстве со-
временных компьютеров, о тенденциях развития компью-
терных технологий; о понятии «операционная система»
и основных функциях операционных систем; об общих
принципах разработки и функционирования интернет-при-
ложений;
Государство заинтересовано
в ИТ-грамотности,
это подкреплено законодательно
и выглядит хорошо на бумаге.
А что на практике?
7) сформированность представлений о компьютерных се-
тях и их роли в современном мире; знаний базовых принци-
пов организации и функционирования компьютерных сетей,
норм информационной этики и права, принципов обеспе-
чения информационной безопасности, способов и средств
обеспечения надежного функционирования средств ИКТ;
8) владение основными сведениями о базах данных,
их структуре, средствах создания и работы с ними;
9) владение опытом построения и использования компью-
терно-математических моделей, проведения экспериментов
и статистической обработки данных с помощью компьюте-
ра, интерпретации результатов, получаемых в ходе модели-
рования реальных процессов; умение оценивать числовые
параметры моделируемых объектов и процессов, пользо-
ваться базами данных и справочными системами;
10) сформированность умения работать с библиотека-
ми программ; наличие опыта использования компьютерных
средств представления и анализа данных».
Впечатляет, не правда ли? Требования к изучению пред-
мета на базовом уровне, конечно, не столь глубоки, но тоже
На экскурсии в гостях у разработчиков промышленной электроники
ООО «Тулапромприбор»
78
вектор роста
достаточно обширны. Таким образом, согласно ФГОС в на-
шем государстве молодой человек, изучивший информатику
в средней школе, должен обладать неплохим начальным ба-
гажом знаний для применения информационных технологий
в своей будущей деятельности и для продолжения изучения
ИТ в их широком спектре в высшем учебном заведении.
Итак, заинтересованность государства, подкрепленная
законодательно, есть, и все выглядит хорошо на бумаге.
А что на практике?
Учебники и методическая литература
Понятно, что в процессе образования без дидактического
материала никак не обойтись. Преподавателю мало знать
самому предмет, надо еще и объяснить школьникам тот
или иной вопрос, да и без самостоятельного обучения вряд
ли можно говорить о глубоком изучении предмета.
Учебников по информатике для школы в России – масса.
Стоит лишь зайти в книжный магазин или посмотреть в Ин-
тернет. Между тем для того, чтобы выбрать учебник и мето-
дический материал к нему для конкретного курса (базового,
профильного или элективного), мне пришлось приложить
некоторые усилия. Однако с уверенностью скажу, что даже
при отсутствии опыта подобрать подходящий учебник, соот-
ветствующий ФГОС, сложно, но не невозможно.
Есть отличные примеры творческого и ответственного
подхода к своему делу. Можно отметить учебники для 8-го
и 9-го классов «Информатика и ИКТ» Л.Л. Босовой и А.Ю.
Босовой – прекрасно изложенный материал с использова-
нием различных, в том числе и свободных, программ, кото-
рый обильно снабжен тестами и контрольными вопросами,
да еще и презентациями для изложения материала на уро-
ках и самостоятельного изучения, выложенными в Интер-
нет [3].
Отдельного внимания и благодарности заслуживают учи-
теля, которые выкладывают свои наработки в свободный
доступ. При подготовке к занятиям много интересного мате-
риала нашлось на персональных страничках К.Ю. Поляко-
ва [4] и А.И. Козлова [5].
Говоря о методике преподавания, нельзя не отметить Ку-
Мир («Комплект Учебных Миров»), созданный для обучения
школьников программированию [6]. В учебной литературе
также активно продвигается так называемый школьный
алгоритмический язык, составляющий основу КуМира, ко-
торый является русскоязычным алгоритмическим языком,
очень похожим на Паскаль. Вообще нужно отметить, что вся
система обучения информатике в школе сильно ориенти-
рована на Паскаль, от учебников до заданий на экзаменах,
что, может быть, совсем неплохо для обучения на базовом
уровне. На профильном уровне и занятиях по выбору необ-
ходимо все-таки хотя бы начинать знакомить учеников с дру-
гими языками программирования, например, с Си или Java,
а может быть, и Python.
Хотелось бы также отметить учебно-методический жур-
нал для учителей «Информатика» издательского дома
«Первое сентября», в котором постоянно ведется обмен
методическими разработками, обсуждаются различные во-
просы преподавания информатики в школе.
Таким образом, можно с уверенностью сказать,
что в настоящее время в российской школе есть все сред-
ства в плане обучающих программ и методических разра-
март 2014 системный администратор
 вектор роста
боток для подготовки учителей и преподавания предмета
информатики на любом уровне
Оснащение
Не знаю, как в других регионах, но мне достался отлично
оборудованный класс с интерактивной доской и широкопо-
лосным доступом в Интернет. Компьютеры не самые совре-
менные, но для решаемых задач вполне пригодные.
Кроме аппаратной части порадовало наличие лицензи-
онного программного обеспечения. На всех компьютерах –
лицензионная ОС Windows 7, Microsoft Office 2010, антиви-
рус Касперского. В кабинете информатики был обнаружен
также пакет программных продуктов национального про-
екта «Образование», куда вошли продукты фирм Microsoft,
Adobe, Corel, «1C», ABBYY, Embarcadero (Borland). Хотя
в сопровождающих документах сказано, что часть продук-
тов для образовательных учреждений предоставляется бес-
платно (не требует активации), мне так и не удалось уста-
новить, например, Borland Developer Studio 2006 из этого
комплекта – нужна лицензия. Как стало понятно из информа-
ции на форумах, срок лицензии закончился еще в 2010 году.
Получилось, что нельзя сбрасывать со счетов свободное
ПО, которое, как оказалось, является неплохим подспорьем
еще и в деле обучения премудростям информатики и ин-
формационных технологий. То, что не вышло с BSD2006,
при знакомстве со средствами проектирования пробуем
компенсировать с помощью набирающей обороты свобод-
ной среды для быстрой разработки Lazarus.
О попытке перехода на свободное ПО
Кстати, несколько слов о якобы неудавшейся попытке
перехода на свободные программы в российских школах.
Проблема, конечно же, не в отсутствии подключения к Ин-
тернету и нехватке литературы. Она скорее всего в непод-
готовленности кадров.
Разговаривая с учителями других школ, я задавал вопро-
сы о Linux и OpenOffice.org. В ответ слышал: «Все это ин-
тересно. А когда изучать?» Представим себе среднестати-
стического учителя информатики. При нагрузке 1,5-2 ставки
(что в школах совсем не редкость) он проводит 27-36 часов
в неделю у доски (4-6 уроков ежедневно). Прибавить сюда
подготовку к занятиям. И получается, что действительно
для кого-то временной фактор в этом вопросе является на-
стоящим барьером!
С учетом того, что я знаком с Linux с 2006 года и приме-
нял его на практике для решения различных задач автома-
тизации на предприятии, практически сразу после начала
занятий в компьютерном классе на машины учеников был
установлен Linux Mint второй системой (вместе с Windows).
Когда мы проходим, например, OpenOffice.org, ребята ис-
пользуют эту операционную систему спокойно, хотя, надо
сказать, что и без особого энтузиазма.
Исключение составляют выбравшие углубленное изуче-
ние информатики (элективный курс), где мы пробуем изу-
чить азы построения веб-систем: программирование на PHP
с помощью связки LAMP (Linux-Apache-MySQL-PHP). Эти ре-
бята по достоинству оценили возможности свободного ПО.
Тема веб-программирования остается одной из наиболее
интересных для молодых людей, изучать которую без UNIX
и свободного ПО достаточно сложно.
системный администратор март 2014
Карьера/Образование
Заинтересованность детей
Говорят, наших детей трудно сейчас чем-то удивить – смарт-
фон даже у школьника уже не редкость. Тем более компью-
тер, который уже совсем не в новинку.
Конечно, трудно и скорее всего невозможно сделать
так, чтобы все дети в обычной школе углубленно изучали
информатику. Однако, в любом случае, найдется молодой
человек (и, наверное, не один), который захочет разо-
Почему не удался переход
на свободные программы
в школах? Из‑за неподготовлен-
ности кадров
браться, как работает компьютер или как можно сделать
какого-то робота, программу или веб-сервер своими рука-
ми. За небольшой срок моей работы в школе только самые
пассивные ученики не спросили, как сделать самому игру
для планшета или телефона.
Создание в нашей школе по выбору ребят и при под-
держке руководства элективного курса по изучению веб-
технологий – прекрасный пример заинтересованности уче-
ников в изучении ИТ.
А чего же не хватает?
Как я уже говорил, очень многое значат кадры. Хотя день-
ги решают не все, однако, предполагаю, вряд ли даже
средний айтишник рискнет сменить профессию на пре-
подавательскую. Всем известно, что есть заинтересован-
ность фирм, занимающихся ИТ, в выпускниках вузов. Од-
нако вложение усилий и средств в создание компьютерных
центров и преподавание информатики и информационных
технологий для школьников в настоящее время – явление
достаточно редкое. Исключение составляют платные про-
екты, такие как «Роботландия» или различные проекты
на базе Arduino. А ведь тем ребятам, которые хотели бы
изучать информатику углубленно, просто необходим опыт
профессионалов. Похоже, что пока это остается уделом
энтузиастов.
Не знаю, насколько серьезно выглядит такое предложе-
ние, но могла бы помочь поддержка государства в этом во-
просе (хотя бы в виде налоговых льгот для компаний, помо-
гающих школам в процессе обучения). И тогда, возможно,
где-то не придется учителю географии преподавать инфор-
матику. EOF
1. http://минобрнауки.рф.
2. http://минобрнауки.рф/документы/2365.
3. http://metodist.lbz.ru/authors/informatika/3 – издательство «Би-
ном». Лаборатория знаний. Авторская мастерская Л.Л. Босо-
вой.
4. http://kpolyakov.spb.ru – сайт К. Полякова «Преподавание, на-
ука и жизнь».
5. http://www.somit.ru – информатика в анимациях – персональ-
ный сайт учителя физики и информатики А.И. Козлова.
6. http://www.niisi.ru/kumir – система программирования КуМир.
79
 Карьера/Образование
Визитка
Денис Силаков, кандидат ф.-м. н., ЗАО «РОСА», член рабочей
группы LSB, старший архитектор, занимается автоматизацией
разработки ОС «РОСА», denis.silakov@rosalab.ru
Качество программного кода
От выявления стилистических огрехов к поиску ошибок
Автоматизированные инструменты проверки кода не ограничиваются синтаксическим
анализом и поиском нарушений, связанных со стилем и форматированием. Многие
из них способны отлавливать реальные ошибки, которые не всегда удается выявить
с помощью обычных тестов
В предыдущей статье [1], посвященной качеству кода,
мы  рассмотрели ряд инструментов, помогающих разра-
ботчикам улучшить читаемость исходных текстов программ
и облегчить тем самым их поддержку и развитие. Досто-
инством подобных утилит является простота и легкость
использования – достаточно указать, какие правила необ-
ходимо проверять, и запустить инструмент. Этот фактор
обусловил большую популярность таких средств анализа
кода, особенно при использовании систем CI.
В то же время рассмотренные инструменты способны
выявить очень ограниченный класс ошибок. Безусловно,
проблемы плохого форматирования кода или неговорящих
названий переменных неприятны, но на функциональность
программы напрямую они не влияют.
Однако не стоит думать, что это все, на что способны
автоматизированные средства анализа программ. Рынок
таких инструментов постоянно развивается и предлагает
все более совершенные и изощренные способы прове-
рить ваши приложения на корректность, позволяя находить
все большее количество потенциальных проблем, не затра-
чивая на это особых усилий.
В этой статье я предлагаю вам обзор наиболее популяр-
ных и функциональных средств автоматического анализа
приложений, которые активно используются как в промыш-
ленных проектах, так и разработчиками небольших про-
грамм.
Анализаторы семантической корректности кода
Начнем с простого. Многие утилиты, проверяющие соот-
ветствие кода определенным правилам, не ограничивают-
ся требованиями к структуре и оформлению. Часто такие
структурные проверки дополняются семантическим анали-
зом, в рамках которого инструменты пытаются определить,
нет ли в программе конструкций, потенциально ведущих
к проблемам с производительностью, безопасностью, логи-
кой работы и прочими аспектами, непосредственно влияю-
щими на функционал приложения.
Типичным представителем таких инструментов в мире
Java является PMD (см. рис. 1), позволяющий выявлять:
80
пятая пара
>> мертвый код (неиспользуемые переменные, приватные
методы и параметры функций);
>> пустые тела циклов и условий;
>> излишне усложненные циклы;
>> некорректное или неэффективное использование
стандартных классов Java и так далее.
Достойной альтернативой является FindBugs, который
содержит более четырехсот правил для проверки, относя-
щихся преимущественно к семантике программы и исполь-
зованию тех или иных конструкций в коде.
В мире .NET аналогичные возможности предоставляет
FxCop, анализирующий промежуточный код на языке CLI
(в который компилируются все .NET-приложения, неза-
висимо от конкретного языка программирования). Наряду
с проверкой следования правилам именования и другим
аспектам, влияющим на простоту поддержки кода, FxCop
позволяет выявлять проблемы с надежностью, переноси-
мостью и безопасностью приложений. Анализ на основе
FxCop встроен в некоторые редакции Visual Studio.
Другие языки тоже не обделены вниманием – для C++
существует мощный cppcheck (интегрирующийся с Visual
Studio, Eclipse, Code::Blocks и другими популярными IDE),
для Python – PyChecker и Frosted, для Groovy – CodeNarc
и так далее.
Детекторы уязвимостей
Среди различных видов проблем, выявляемых семанти-
ческими анализаторами, необходимо отдельно отметить
ошибки работы с оперативной памятью, которые уже долгие
годы являются головной болью большого количества при-
ложений.
Традиционные языки программирования (прежде всего
C и C++) оставляют задачи по управлению памятью про-
граммистам. И, как показывает практика, даже в небольших
программах часто встречаются опасные ошибки, связанные
с обращением к памяти по некорректным адресам – напри-
мер, выход за границы массива или присвоения указателю
на функцию неверного значения, указывающего совсем
не туда, куда хотелось бы разработчикам.
март 2014 системный администратор
 пятая пара Карьера/Образование

Ошибки работы с оперативной

памятью долгие годы являются
головной болью большого
количества приложений

Опасными такие ошибки являются не только потому, тью достаточно сложно. Для более полного анализа необ-
что приводят к «падению» программы и возможной потере ходимо так или иначе проэмулировать работу программы
результатов труда пользователя, но и потому, что представ- или ее конкретного участка и посмотреть, как код ведет
ляют собой потенциальные бреши в безопасности системы. себя в реальной жизни.
Зная о наличии в программе некорректного обращения к па- Подобный подход используют инструменты от Coverity –
мяти, злоумышленник с помощью специально сформиро- в частности, Static Analysis Verification Engine (Coverity SAVE),
ванных входных данных может заставить программу сделать использующий абстрактную интерпретацию для частичного
то, что нужно ему для вторжения в ОС, – например, открыть исполнения различных участков программы и позволяющий
сессию удаленного доступа. Впрочем, это большая тема, находить утечки памяти, обращение к неинициализирован-
и она освещалась на страницах Open Source [2]. ным областям и ряд других потенциальных ошибок, которые
Частично проблемы были решены созданием языков могут привести к серьезным последствиям. При этом весь
и фреймворков с автоматическим управлением памятью – анализ происходит статически – то есть Coverity работает
таких, как Java, .NET, Perl, Python и другие. Однако полного исключительно с кодом и не требует запуска приложения.
перехода всех приложений на такие языки пока не пред- Инструменты Coverity не бесплатные, но для ознакомле-
видится. Традиционные подходы с ручным управлением ния компания предлагает пробную версию. Открытые про-
памятью по-прежнему остаются на ведущих позициях, и по- екты могут воспользоваться сервисом Coverity SCAN, по-
иск  потенциальных ошибок в них остается актуальной за- зволяющим загружать на сайт компании свои приложения
дачей. и получать результаты анализа. Есть у Coverity и достойные
За десятилетия борьбы с некорректным использованием аналоги – например, Klockwork и отечественные PVS-Studio
памяти появилось немало инструментов, помогающих раз-
работчикам в решении этой нелегкой задачи. Во-первых,
Рисунок 1. Отчет плагина PMD в Eclipse (изображение с eclipsezone.com)
современные ОС и средства разработки предоставляют
ряд возможностей для определения некорректной рабо-
ты с памятью, предотвращая использование таких ошибок
злоумышленниками – об этом также подробнее рассказано
в статье [2].
Имеются и инструментальные средства для анализа при-
ложений на предмет возможных нарушений. Часть таких
инструментов использует статический анализ кода – так,
уже упоминавшийся cppcheck способен выявлять утечки
памяти и некоторые другие ошибки (например, с помощью
этой утилиты не так давно была обнаружена потенциальная
уязвимость в библиотеке libXfont, входящей в состав исполь-
зуемой в Linux и многих UNIX-системах графической систе-
мы X.Org).

Статические анализаторы
Посредством исключительно синтаксического разбора
и анализа кода обнаружить многие ошибки работы с памя-

системный администратор март 2014 81

 Карьера/Образование
и CppCat, позволяющие выявлять нетривиальные пробле-
мы. Реальный пример анализа исходного кода программы
Crypto++ от разработчиков CppCat – для следующего участ-
ка кода:
void CAST256::Base::UncheckedSetKey()
{
word32 kappa[8];
...
memset(kappa, 0, sizeof(kappa));
}
CppCat выдаст предупреждение о том, что большинство
оптимизирующих компиляторов удалят завершающий вы-
зов memset, поскольку переменная kappa локальная и пос-
Как показывает практика, даже
в небольших программах часто
встречаются опасные ошибки,
связанные с обращением
к памяти по некорректным
адресам
ле вызова memset нигде не используется. Однако вполне
возможно, что массив kappa содержит какие-то приватные
данные, и вызов memset был призван принудительно их очи-
стить. Так что удаление вызова memset делает приватные
данные потенциально доступными нежелательным участкам
кода, то есть мы имеем потенциальную брешь в безопас-
ности.
Динамический анализ – Valgrind
Наиболее известные и мощные инструменты статическо-
го анализа являются коммерческими и не всегда дешевы-
ми. Мир свободного ПО предлагает альтернативу в лице
Valgrind – программе с открытым исходным кодом, доступ-
ной для Linux, Mac OS X и BSD-систем.
Valgrind в отличие от Coverity использует динамический
анализ – исследует поведение приложения в ходе его ра-
боты. Для запуска приложения Valgrind транслирует его би-
нарные файлы в промежуточное представление для соб-
ственной виртуальной машины, которая затем и выполняет
программу.
Такой подход позволяет инструменту контролировать
все аспекты выполнения приложения, в частности, отсле-
живать вызовы функций выделения/освобождения памяти
и обращения к ней. Это дает возможность в любой момент
времени знать, какие участки памяти приложение зарезер-
вировало для своих нужд и не выходят ли инструкции обра-
щения к ней за пределы выделенных приложению областей.
Заодно Valgrind может отслеживать утечки памяти, что тоже
немаловажно для программ, работа которых не прерывает-
ся в течение долгого времени.
Valgrind – инструмент многогранный, позволяющий так-
же выявлять состояния гонки в многопоточных програм-
мах и осуществлять профилирование программы. С точки
82
пятая пара
зрения разработчика, пользоваться им очень просто – до-
статочно всего лишь запустить программу с его помощью,
указав необходимые опции (например, что именно нужно
отслеживать/профилировать).
Вот так, например, выглядит небольшой кусок результата
работы Valgrind при запуске через него IM-клиента Kopete
из командной строки:
$ valgrind kopete
<...>
34,370 bytes are definitely lost
=at 0x4029CFA: operator new(unsigned int)
=by 0x5E93A40: KEmoticons::theme() (in /usr/lib/
libkemoticons.so.4.11.4)
=by 0x805D343: ??? (in /usr/bin/kopete)
Здесь Valgrind нам подсказывает, что после выхода
из Kopete не освободилась память, выделенная операто-
ром new() в методе Kemoticons::theme(). Если бы Kopete был
собран с отладочной информацией, то мы бы увидели еще
и функцию в исполнимом файле kopete, из которой вызвал-
ся этот метод.
Несмотря на свою мощь и простоту использования,
Valgrind не является панацеей от всех бед.
Во-первых, Valgrind только осуществляет мониторинг
работы приложения. Процесс использования инструмента
подразумевает активное участие человека, который «гоня-
ет» приложение всеми возможными способами, и качество
проверки во многом зависит от того, насколько полно были
покрыты возможные сценарии работы. Конечно, в промыш-
ленных проектах человека часто заменяют автоматическими
тестами, но эти тесты ведь тоже надо написать и обеспечить
хорошее покрытие кода и сценариев. А для приложений
с графическим интерфейсом это не всегда просто.
Во-вторых, побочным эффектом применения промежу-
точного представления программы, используемого Valgrind,
является медленная скорость работы приложений. Замед-
ление работы приложения в Valgrind по сравнению с обыч-
ным запуском на порядок – явление вполне обычное. Если
на небольших программах это не очень заметно, то в случае
больших и сложных продуктов тестирование с помощью
Valgrind может затянуться на сутки и более. Так что запу-
скать этот инструмент после каждого коммита в инструмен-
тарий CI вряд ли разумно.
Наконец, используемые в Valgrind средства анализа
не совсем идеальны и не всегда способны дать однознач-
ный вердикт – имеется ли в том или ином месте утечка памя-
ти или нет. И анализ результатов работы этого инструмента
также требует некоторого времени и напряжения ума.
В ряде специфических ситуаций Valgrind и другие рас-
смотренные выше инструменты могут оказаться не у дел.
Например, при тестировании ядра ОС и его модулей –
в частности, драйверов устройств. Но такое тестирование
очень востребовано (ведь ошибка в модуле ядра приве-
дет к краху ОС или ее компрометации злоумышленником),
и средства для его проведения существуют как в Windows,
так и в Linux.
Для первой это динамический Driver Verifier, а так-
же статический SLAM, входящий в состав Windows Driver
Development Kit. Для Linux прежде всего необходимо от-
метить отечественные разработки – динамический KEDR
март 2014 системный администратор
 пятая пара
и инструменты проекта Linux Driver Verification (LDV), прово-
дящие статическую верификацию. Эти средства объектив-
но являются одними из лидеров в области автоматического
тестирования модулей ядра Linux; мы активно использу-
ем их при разработке дистрибутивов РОСЫ и исправили
с их помощью ряд достаточно хитрых проблем.
В заключение констатируем, что ошибки работы с памя-
тью остаются одной из насущных проблем современного
ПО. Выявлять их непросто, но и цена таких ошибок велика.
Как следствие, нацеленные на их обнаружение инструмен-
ты достаточно нетривиальны и по сложности существенно
превосходят инструменты форматирования кода и прочие
косметические анализаторы.
Однако в плане сложности Valgrind, Coverity и компания –
далеко не все средства для тестирования кода. Пора пере-
йти к самому наукоемкому классу таких инструментов, осно-
ванному на строгой математике.
Формальная верификация кода
Программирование исконно очень близко математике,
и развитый математический аппарат активно использует-
ся в разных областях, имеющих отношение к разработке
ПО, например, в теории алгоритмов и теории компилято-
ров. Вполне ожидаемо, что уже несколько десятилетий
в воздухе витают идеи применить математические методы
и к тестированию программ, то есть подойти к вопросу про-
верки качества приложений как к математической задаче.
Такой  подход получил общее название формальной вери-
фикации.
Классическое тестирование может только находить
ошибки, но не способно гарантировать их полное отсут-
ствие – ведь для этого необходимо было бы перебрать
все возможные входные данные и сочетания внешних ус-
ловий. Формальная же верификация как раз позволяет
доказать, что программа обладает или не обладает теми
или иными свойствами – в частности, что в ней отсутствуют
те или иные ошибки.
Например, можно проверить, что та или иная перемен-
ная не обнуляется в ходе работы, что переменная инициа-
лизируется до ее использования или что выходное значение
функции sqrt() действительно возвращает квадратный ко-
рень своего аргумента. Правда, нельзя проверить, что оши-
бок нет вообще, ведь вряд ли такое требование можно опи-
сать математически.
Часто используемым видом формальной верификации
является Model Checking («проверка моделей»). Он под-
разумевает построение математической модели программы
(возможно, абстрактной модели, отражающей не все харак-
теристики программы, а только те, которые важны для про-
верки того или иного свойства). Такая модель может быть
построена с использованием конечных автоматов, сетей
Петри и аналогичных математических объектов.
Далее необходимо сформулировать требования для про-
верки на модели; обычно для этого используются времен-
ные (или темпоральные) логики, добавляющие к «обычной»
логике понятия времени и причинно-следственных связей.
Проверка выполнения требования на модели – занятие
очень трудоемкое, но рутинное, и для него существуют
соответствующие автоматические инструменты – такие,
как BLAST, CPAchecker или SPIN.
системный администратор март 2014
Карьера/Образование
Казалось бы, вот оно, счастье! Конечно, надо еще сфор-
мулировать требования в формальном виде, но это не очень
большая проблема. Но есть более существенная слож-
ность, с которой сталкиваются автоматизированные инстру-
менты, использующие формальную верификацию, – это по-
требность в огромном количестве ресурсов. Более точно:
используемые в этих инструментах алгоритмы страдают
от эффекта комбинаторного взрыва, и победить эти про-
блемы в общем случае пока не представляется возможным.
Зная о наличии в программе
некорректного обращения
к памяти, злоумышленник
с помощью специально
сформированных
входных данных может
заставить программу
сделать то, что нужно
ему для вторжения в ОС
Как следствие, применять формальную верификацию полу-
чается либо для небольших программ, либо для проверки
достаточно узких и специфических требований. Либо про-
водить тестирование на мощных кластерах, но и это спаса-
ет ненадолго.
По этой причине использование инструментов формаль-
ной верификации в промышленности довольно ограничено,
несмотря на большой интерес многих вендоров к строгим
математическим подходам. Тем не менее есть и вполне по-
лезные инструменты формальной верификации, используе-
мые для реальных проектов.
Так, уже упомянутый ранее мною LDV, который мы ис-
пользуем в РОСЕ, основывается на статических анализа-
торах BLAST и CPAchecker (более того, в последние годы
BLAST и развивается в основном разработчиками LDV).
Также достаточно известным является инструмент Java
Path Finder, позволяющий находить в многопоточных Java-
программах тупики, необработанные исключения и некото-
рые другие ошибки.
В целом интерес к формальной верификации не угасает,
и исследования в этой области ведутся как научными цен-
трами, так и крупными корпорациями. При этом инструменты
формальной верификации сейчас применяются не только
к программам, но и к аппаратным средствам – в частности,
к процессорам.
Немаловажен и тот факт, что год от года растет произ-
водительность компьютеров и увеличиваются вычисли-
тельные мощности, доступные для проведения статической
верификации. Хотя и приложения не отстают в своем раз-
витии, все более усложняясь и разрастаясь.
Программы-комбайны
Как вы уже наверняка подметили, многие рассмотренные
в этой статье (а также в предыдущей статье про качество
83
 Карьера/Образование
кода) инструменты зависят от языка программирования.
Если вы работаете над крупным проектом или репозитори-
ем из нескольких проектов, использующих разные языки
и технологии, то вам могут помочь фреймворки, поддержи-
вающие сразу множество платформ и языков.
Кроме того, даже в рамках одного небольшого проекта
не всегда удобно применять много разрозненных инстру-
ментов – хочется каким-то образом их интегрировать. Безус-
ловно, здесь могут помочь инструменты Continuos Integration
(CI) – например, Hudson и Jenkins предлагают плагины
для многих рассмотренных выше утилит.
Однако некоторые вендоры предлагают комбинирован-
ные решения, сразу покрывающие несколько направлений.
Так, тот же Coverity предоставляет целый набор продуктов
под общим названием Coverity Platform, включающий разно-
образные инструменты проверки качества кода и обеспе-
чения контроля качества программного продукта в целом.
Имеются у Coverity и инструментальные средства, которые
очень пригодятся в крупных проектах – например, Coverity
Connect предоставляет средства обработки ошибок, най-
денных инструментами Coverity Platform, и поддерживает
базу знаний о возможных ошибках.
Есть у Coverity и аналоги – например, достаточно извест-
ны статические анализаторы кода QA-C и QA-C++ от PRQA,
позволяющие выявлять широкий класс проблем и недоче-
тов и при этом представлять результаты в удобной и понят-
ной форме.
Из свободных инструментов хорошим выбором будет
SonarQube (см. рис. 2), поддерживающий более 20 языков
программирования и способный проверять соответствие
кода имеющимся требованиям, находить дублирующие-
ся участки программ, потенциальные ошибки, а также за-
пускать все ваши тесты для приложений. Для SonarQube
существует более полусотни плагинов, еще больше рас-
ширяющих его функциональность, а сам он может быть ин-
тегрирован в инструменты CI.
Сложные инструменты – для сложных проектов!
Итак, качество кода отнюдь не сводится к его оформлению,
а автоматизированные инструменты проверки качества по-
зволяют исправлять более серьезные ошибки, чем некра-
сивые отступы. Однако в отличие от lint и ему подобных,
дающих однозначный ответ, соответствует ли программа
заданным требованиям или нет, многие из рассмотренных
Рисунок 2. Sonar умеет анализировать даже программы на Коболе
(пример с sonarsource.com)
84
пятая пара
в этой статье инструментов скорее дают пищу для размыш-
лений – нет ли в тех или иных местах программы потенци-
альной ошибки, которая может проявиться в самый непод-
ходящий момент. Иными словами, для продвинутых средств
автоматизированного тестирования и анализа велика веро-
ятность ложного срабатывания.
Определить, является ли срабатывание ложным, не всег-
да легко. По этой причине не все упомянутые выше инстру-
менты используются на регулярной основе в рамках не-
прерывной интеграции. А если и используются, то далеко
не всегда результатам их работы уделяется должное вни-
мание. Ведь если вы из раза в раз получаете одни и те же
предупреждения и уверены, что все они являются ложными
срабатываниями, то вскоре вы просто перестанете обра-
щать внимание на отчеты этих инструментов и можете не за-
метить появления реальных проблем.
Конечно, многие программы позволяют составлять спи-
сок известных ложных срабатываний, которые будут игно-
рироваться при последующих запусках, а многие средства
CI предоставляют плагины, позволяющие отслеживать по-
явление новых ошибок в отчете тех или иных инструментов
тестирования, так что после очередной сборки вы можете
сконцентрироваться только на ошибках, которые привнесли
последние изменения кода. Это несколько облегчает жизнь,
но в условиях часто изменяющегося кода список известных
ошибок необходимо постоянно обновлять, а, занимаясь
только новыми ошибками, можно забыть исправить старые,
но отнюдь не ложные.
Помножьте эти проблемы на ресурсоемкость многих ин-
струментов и на немаленькую стоимость некоторых из них,
и вы придете к выводу, что для небольших проектов, тре-
бования к качеству которых относительно невелики, вполне
хватит и простых утилит. Когда же сложность кода возрас-
тает настолько, что держать его весь в голове не пред-
ставляется возможным, а требования к качеству при этом
становятся все более серьезными, пора вспомнить и о про-
двинутых автоматизированных средствах. Но главное – что-
бы было, что вспомнить, ведь на срочное изучение новых
технологий времени, как всегда, не окажется.
***
К сожалению, в процессе обучения в вузах подобным авто-
матизированным инструментам редко уделяется много вни-
мания; однако ничто не мешает любознательным студентам
проявить инициативу и самостоятельно попробовать неко-
торые из них, благо здесь имеется и богатый выбор свобод-
ных программ.
Такая инициатива наверняка будет по достоинству оце-
нена не только преподавателями, но и работодателями,
а оценка последних ничуть не менее важна. EOF
1. Силаков Д. Качество программного кода. Позаботьтесь о дол-
гой жизни ваших программных продуктов. //«Системный адми-
нистратор», №1-2, 2014 г. – С. 128-133.
2. Силаков Д. Ошибки сегментации и безопасность,
или Как «упавшая» программа может привести к взлому сис-
темы. //Open Source, №125. – С. 22-31.
Ключевые слова: тестирование, верификация, корректность кода,
динамический анализ.
март 2014 системный администратор
 пятая пара
Представление текстовой информации в ЭВМ. Часть 1
Теоретические сведения о способах представления текстовой информации
в памяти ЭВМ, в том числе и кириллицы
В теоретической части работы рассматриваются вопросы
кодирования текстовой информации и некоторые полезные
свойства кодировок. Вопросы упаковки, сжатия и оценки
количества информации не затрагиваются.
В последующей, практической, части предлагается са-
мостоятельно выполнить несколько заданий посредством
общения с компьютером через интерфейс командной стро-
ки (CLI), что поможет закреплению теоретических знаний
и получению соответствующих навыков работы в консоли.
Описание лабораторного стенда
Для работы требуется ОС Linux, имеющая в своём составе
командный интерпретатор bash, утилиты и команды iconv
(обычно пакет glibc-common), cat, od, echo, cp, mv, rm, dd
(пакет coreutils), dos2unix и unix2dos (пакет dos2unix). Для до-
полнительного задания повышенной сложности понадобит-
ся утилита strings (пакет binutils). Фактически это может быть
любой Linux, UNIX или совместимая с ними ОС.
Краткие теоретические сведения
Так как большинство современных ЭВМ (если не сказать,
что почти все) удовлетворяет принципам вычислительной
машины фон Неймана, то логично предположить, что ин-
формация, которую они хранят, обрабатывают и передают
по сетям, удовлетворяет принципу двоичного кодирования,
а именно представима в виде двоичных чисел.
Существуют международные стандарты и методы коди-
рования текстовой, числовой, изобразительной, звуковой
и видеоинформации. Сегодняшний список видов инфор-
Таблица 1а. Семибитная кодовая таблица ASCII (ANSI)
0 1 2 3 4 5 6 7 8 9 A B C D E F
системный администратор март 2014
Карьера/Образование
Визитка
Владимир Закляков, советник налоговой службы
2-го ранга, zaklyakov@samag.ru
Лабораторная работа
мации, существующих стандартов и методов, несомненно,
может быть расширен в будущем.
Если вопросы представления чисел в памяти ЭВМ были
рассмотрены в [1], то данная работа посвящена пробле-
мам хранения текстовой информации. Понимание принци-
пов кодирования и знание основных кодовых таблиц важно
не только системным администраторам, но и пользователям
для правильного чтения как информации, добытой из Интер-
нета, электронной почты, так и файлов, полученных через
внешние носители и др.
Зарождение кодировок
Чтобы лучше понять принципы кодирования текстов, перене-
сёмся во времена, когда ЭВМ только появлялись, а их базо-
вые принципы ещё не были чётко сформулированы. А если
их нет, то давайте их и придумаем вместе. Итак, исходные
условия: мы имеем несколько букв (алфавит) и желание
представить его в виде цифр, так как цифры [2] «хранить»
в памяти ЭВМ мы уже научились. Первое, что обычно при-
ходит на ум, – закрепить за каждым символом алфавита
числовой номер – код. Например, 1 для буквы «а», 2 пусть
обозначает букву «б», 3 – букву «в» и т.д. Наверняка среди
читателей найдутся те, кто в детстве играл подобным обра-
зом.
Хоть мы великая страна с наибольшим числом часовых
поясов, и нам есть, чем гордиться, всё же мы не были первы-
ми, кто использовал ЭВМ и придумывал способы представ-
ления текстов, поэтому первично кодированию подверглись
латинские символы, цифры и различные знаки препинания,
0 1 2 3 4 5 6 7 8 9 A B C D E F
85
 Карьера/Образование
а не кириллица. Так, в англоязычных странах используют-
ся 26 прописных и 26 строчных букв (A… Z, a… z), девять
знаков препинания (. , : ! " ; ? ( ) ), пробел, 10 цифр, пять зна-
ков арифметических действий (+, -, *, /, ^) и ряд специаль-
ных символов (№, %, _, #, $, &, >, <, |, \); все они и были за-
кодированы – в итоге набралось чуть больше 100 символов.
(Дефис, тире, длинное тире и минус были закодированы
как «чёрточка» одного вида.) Для кодирования такого числа
вариантов можно ограничиться семиразрядным двоичным
числом (от 0000000 до 1111111, в десятичной системе счис-
ления – от 0 до 127), что и было сделано.
Кодовые таблицы
Для кодирования букв и других символов, используемых
в печатных документах, необходимо закрепить за каждым
символом числовой номер – код.
Первой семиразрядной кодовой таблицей была ASCII
(American Standard Code for Information Interchange), опу-
бликованная как стандарт ASA X3.4-1963 в июне 1963 года
американской организацией по стандартизации American
Standards Association (ASA), которая позднее стала име-
новаться ANSI [3]. (Поэтому данную семибитную кодовую
таблицу по появлении называли также ANSI, однако на се-
годня термин «кодировка ANSI» не устоялся, в ряде случаев
под ним могут пониматься совсем другие кодировки, вплоть
до ISO/IEC 8859-1.) Таблица содержала 32 кода команд
или управляющих символов (от 0 до 31), большая часть ко-
торых сегодня не применяется пользователями, и 95 кодов
(от 33 до 127) для различных знаков, достаточных для рабо-
ты с английскими текстами, как показано в таблице 1 (а,б).
Там же (таблица 1а) символы построчно имеют следую-
щие коды в шестнадцатеричной системе счисления (в скоб-
ках – в десятичной):
>> 1-я строка с 00 по 0F и далее (правая колонка) с 10 по 1F
(0–15, 16–31);
>> 2-я строка с 20 по 2F и 30 – 3F (32–47, 48–63);
>> 3-я строка с 40 по 4F и 50 – 5F (64–79, 80–95);
>> 4-я строка с 60 по 6F и 70 – 7F (96–111, 112–127).
Интересное свойство
a + 3210 = A, b + 3210 = B, … , z + 3210 = Z
A - 3210 = A, b - 3210 = B, … , z - 3210 = Z
Таблица 1б. Семибитная кодовая таблица ASCII (ANSI)
x0 x1 x2 x3 x4 x5 x6
0x
1x
2x
3x
4x
5x
6x
7x
86
пятая пара
В таблице 1а для преобразования прописных букв в строч-
ные достаточно к коду буквы прибавить 3210 (1000002)
и, наоборот, для преобразования строчных в пропис-
ные из кода буквы вычесть 3210. На практике чаще ис-
пользуют не сложение и вычитание, а «побитовое
ИЛИ» с числом 001000002 или «побитовое И» с чис-
лом 110111112 соответственно. Повторное применение
побитовых операций не оказывает никакого влияния
на результат, чего не скажешь об операциях сложения
и вычитания. Наглядно это можно увидеть, если сделать
таблицы с символами в 32 колонки. Тогда вышестоящие
символы от нижестоящих будут отличаться ровно на 32 по-
зиции (см. таблицу 1а).
Однако на практике использовать такую таблицу для пре-
образований шестнадцатеричных значений в вид символа
и обратно не очень удобно, поэтому чаще можно увидеть
таблицу с 16 колонками (таблица 1б).
В последующем данная ASCII таблица была принята
как стандарт ведущими международными организациями
по стандартизации [1]:
>> ISO/IEC 646:1991 [8];
>> ITU-T Recommendation T.50 (09/92) [9], ECMA-
6 (European Computer Manufacturers Association).
Русификация
Однако для нашей страны и многих других стран необходи-
мо было добавить в кодовую таблицу символы националь-
ных алфавитов. Для этого было предложено использовать
восьмибитную кодовую таблицу, которая могла содержать
дополнительно ещё 128 символов (с 128 по 255).
В дальнейшем был принят стандарт на восьмибитную та-
блицу ASCII – ISO/IEC 8859, в которой первые 128 символов
оставались теми же, что и в семибитной таблице, а символы
с 128 по 255 отводились для неанглийских символов [1].
Существует несколько частей этого стандарта:
>> ISO/IEC 8859-1:1998 – Part 1: Latin alphabet № 1;
>> SO/IEC 8859-5:1999 – Part 5: Latin/Cyrillic alphabet;
>> ISO/IEC 8859-6:1999 – Part 6: Latin/Arabic alphabet;
>> ISO/IEC 8859-7:2003 – Part 7: Latin/Greek alphabet;
>> ISO/IEC 8859-8:1999 – Part 8: Latin/Hebrew alphabet и т.д.
В таблице 2 представлена вторая половина кодовой та-
блицы (коды 128–255) для стандарта ISO 8859-5.
Первые русские ЭВМ использовали семибитную коди-
ровку символов КОИ-7 (Код Обмена Информацией семибит-
x7 x8 x9 xA xB xC xD xE xF
пробельный символ
март 2014 системный администратор
 пятая пара
ный, см. таблицу 3), в которой присутствовали прописные
латинские буквы, а на месте строчных латинских были рус-
ские прописные буквы (кириллица).
Позднее на первых отечественных персональных ком-
пьютерах использовалась так называемая «Основная коди-
ровка ВЦ Академии наук СССР», в руководствах к старым
матричным принтерам обозначаемая просто как «ГОСТ» –
восьмибитная кодовая таблица, вторая половина которой
содержала символы псевдографики, русские прописные
и строчные буквы (коды с 128 по 255 – см. таблицу 4).
В дальнейшем основной кодировкой русских букв
для первой операционной системы ПК – MS DOS стала
«Альтернативная кодировка ВЦ Академии наук СССР»
(вторая половина таблицы для кодов 128–255 приведена
в таблице 5). Содержит псевдографику (позволяющую
в текстовом режиме рисовать рамки из одинарных и двой-
ных линий). Существует несколько модификаций, отличаю-
щихся символами в последних 14 позициях. Зарегистриро-
вана в IANA [5] как IBM 866 или CP866.
С широким распространением операционной системы
Microsoft Windows и появлением её национальных локали-
заций для второй половины таблицы ASCII было введено
Таблица 2. Кодовая таблица ISO 8859-5 (коды с 12810 по 25510)
Таблица 3. Семибитная таблица символов КОИ-7
Таблица 4. Кодировка символов «ГОСТ» (коды с 12810 по 25510)
Таблица 5. Таблица символов DOS Cyrillic (CP866, коды с 12810 по 25510)
системный администратор март 2014
Карьера/Образование
понятие «кодовая страница» (code page, CP). Полная та-
блица кодовых страниц Microsoft Windows велика, поэтому
в таблице 6 приведено лишь несколько наиболее важных
кодировок.
Кодировка русских букв в операционной системе
Microsoft Windows – CP1251 – показана в таблице 7.
В операционной системе Linux (как и в большинстве
UNIX) для представления русских букв исторически ис-
пользовалась кодировка КОИ-8R (таблица 8), зарегистри-
рованная в IANA как KOI8-R и описанная в RFC 1489 (см.
дополнительную информацию [10]), однако на сегодня
большинство дистрибутивов Linux по умолчанию использу-
ют кодировку UTF8, о которой будет рассказано ниже.
Стандартизован и зарегистрирован также украин-
ский клон КОИ-8 – KOI8-U (таблица 9), имеющий отличия
от KOI8-R во второй строке символов псевдографики.
О том, как его утверждали осенью 1997 года, можно узнать
из фотографий Тараса Гейченко [11].
Кириллица Macintosh (компьютеров фирмы Apple),
она же CP10007, довольно близка к CP1251. Не зареги-
стрирована в IANA, но часто обозначается как x-mac-cyrillic
(таблица 10).
87
 Карьера/Образование пятая пара

Таблица 6. Некоторые национальные кодовые страницы (CP – code page) операционной

ческих символов в текстах было невозможно, так как они
системы Microsoft Windows кодировались одними и теми же кодами. Для решения про-
блемы в 1991 году в Калифорнии была создана некоммер-
ческая организация Unicode Consortium, в которую вошли
Локализация ANSI Mac DOS (OEM) DOS (OEM)
представители многих зарубежных компьютерных фирм
CP CP Primary CP Secondary
CP (Borland, IBM, Lotus, Microsoft, Novell, Sun, WordPerfect
и др.) и которая занимается развитием и внедрением стан-
English (United 1252 10000 437 850 дарта The Unicode Standard.
States) После этого стандарт кодирования символов Unicode
English (Britain, 1252 10000 850 437 становится доминирующим в интернациональных про-
Canada и др.) граммных многоязычных средах. Microsoft Windows NT
French (Standard) 1252 10000 850 437 и его потомки Windows 2000, 2003, XP, Vista, 7, 8, 8.1 ис-
German 1252 10000 850 437 пользуют Unicode, точнее, UTF-16, как внутреннее пред-
(Standard) ставление текста. UNIX-подобные операционные системы
Russian 1251 10007 866 855 типа Linux, BSD и Mac OS X, iOS, Android и др. приняли
Unicode (UTF-8) как основное представление многоязыч-
ного текста.
Продолжение истории Unicode резервирует 1 114 112 (220+216) символов кода,
Развитие обмена текстами через дискеты и модемы (BBS, в настоящее время используются более 96 000 символов.
эхоконференции FidoNet, электронная почта через UUCP) Первые 256 кодов символов точно соответствуют таковым
показало недальновидность придуманной ранее схемы. ISO 8859-1, наиболее популярной восьмиразрядной таблицы
Например, использование одновременно кириллицы и гре- символов «западного мира»; в результате первые 128 сим-

Таблица 7. Таблица символов CP1251 (коды с 12810 по 25510)

Таблица 8. Таблица символов KOI8-R (коды с 12810 по 25510)

Таблица 9. Таблица символов KOI8-U (коды с 12810 по 25510)

Таблица 10. Macintosh Cyrillic, CP10007 (коды с 12810 по 25510)

88 март 2014 системный администратор

 пятая пара Карьера/Образование

волов также идентичны таблице ASCII. В таблице 11 пока-
зан русский блок Unicode (коды от 040016 до 04FF16).
Кодовое пространство стандарта Unicode разделено
на 17 планов («planes») от 0 до 16, и каждый план име-
ет 65 536 (= 216) точек кода. Также планы ещё называют пло-
скостями.
Первый план (план 0), Основной многоязычный план
(BMP – Basic Multilingual Plane) – тот, в котором описано
большинство символов. BMP содержит символы почти
для всех современных языков и большое количество специ-
альных символов.
Ещё три плана (1, 2, 3) используются для «графических»
символов.
План 1. Дополнительный многоязычный план (SMP –
Supplementary Multilingual Plane), главным образом исполь-
зуется для исторических символов, а также для музыкаль-
ных и математических символов.
План 2. Дополнительный иероглифический план (SIP –
Supplementary Ideographic Plane), используется для прибли-
зительно 40 000 редких китайских иероглифов.
План 3. Третичный иероглифический план (TIP – Tertiary
Ideographic Plane), используется (зарезервирован) для ар-
хаичных китайских иероглифов.
Планы 4 – 13, временно не используются.
План 14. Дополнительный план особого назначения
(SSP – Supplementary Special-purpose Plane), отведён

Таблица 11. Кириллица в Unicode (фрагмент плана 0)

040 041 042 043 044 045 046 047 048 049 04A 04B 04C 04D 04E 04F

системный администратор март 2014 89

 Карьера/Образование
для символов, используемых по особому назначению (теги,
селекторы написания и др.).
Планы 15 и 16 открыты для любого частного использо-
вания.
Однобайтное и многобайтное кодирование,
кодировки переменной длины
Для кодирования одного символа может использовать-
ся один или несколько байтов. Если для любого символа
достаточного одного байта – кодировка считается одно-
байтовой, если требуется несколько – многобайтовой.
Все существующие текстовые кодировки могут быть клас-
сифицированы по данному признаку.
Кодировки переменной длины используют для разных
групп символов разную длину. В них одни символы могут
быть однобайтовыми, а другие двух-, трёх- и даже четырёх-
байтовыми.
Недостатки многобайтовых кодировок
К недостаткам многобайтовых кодировок можно отнести
следующее:
1. Излишнюю избыточность (один символ кодируется б
льшим числом битов).
2. Низкую помехоустойчивость (в случае потери одно-
го байта из многобайтового кода все последующие байты
смещаются, и весь последующий текст перестаёт правиль-
но читаться).
3. Использование байтов с кодами 0-31 (служебные
коды). Подобно двоичным файлам, например, кодировка
Unicode мало подходит для непосредственной передачи
по сети – байты в тексте вполне могут приходиться на об-
ласть управляющих символов.
4. Может использоваться разный порядок байт: LITTLE_
ENDIAN и BIG_ENDIAN.
Для нивелирования указанных недостатков обычно
применяются две другие основанные на Unicode кодиров-
ки переменной длины, обозначаемые как UTF (Unicode
Transformation Format): семибитная UTF-7 (последний
пересмотр – RFC2152, 1997 г., зарегистрирована в IANA
как UTF-7) и восьмибитная UTF-8 (RFC 2279, 1998 г., заре-
гистрирована в IANA как UTF-8).
Замечание. UTF-7 и UTF-8 в каком-то смысле уже не яв-
ляются языковыми кодировками, а являются программно-
распознаваемым кодом относительно исходного Unicode,
но зарегистрированы они именно как кодировки, наравне
с ISO 8859-5 или KOI8-R.
Таблица 12. Принцип кодирования символов в UTF-8
Диапазон кодов UTF-8 (binary) Комментарии
(hexadecimal)
000000–00007F 0aaaaaaa Первый бит 0, следующие 7 соответствуют таблице ASCII
000080–0007FF 110xxxxx 10xxxxxx Первые 3 бита 110 – всего используется 2 байта, второй байт начинается с 10
000800–00FFFF 1110xxxx 10xxxxxx Первые 4 бита 1110 – всего используется 3 байта, второй и третий байты начинаются
10xxxxxx с 10
010000–10FFFF 11110xxx 10xxxxxx Первые 5 бит 11110 – всего используется 4 байта, второй, третий и четвёртый байты
10xxxxxx 10xxxxxx начинаются с 10
90
пятая пара
Естественно, обе не являются специфически «русски-
ми», а пригодны для написания «сколько угодно»-язычного
письма.
UTF-8
В UTF-8 [4] все символы разделены на несколько групп
по значению первых битов. Символы с кодами ме-
нее 12810 кодируются одним байтом, первый бит которого
равен нулю, а последующие 7 бит в точности соответству-
ют 128 символам седьмой таблицы ASCII (см. таблицу 12),
следующие 1920 символов – двумя байтами (Greek, Cyrillic,
Coptic, Armenian, Hebrew и Arabic-символы). Последующие
символы кодируются тремя и четырьмя байтами.
Наиболее наглядно правила записи кода одного симво-
ла в UTF-8 сформулированы в [6]:
1. Если размер символа в кодировке UTF-8 = 1 байт,
то его код имеет вид (0aaa aaaa), где «0» – просто ноль,
остальные биты «a» – это код символа в кодировке ASCII.
2. Если размер символа в кодировке в UTF-8 > 1 байт
(то есть от 2 до 6):
2.1. Первый байт содержит количество байтов символа,
закодированное в единичной системе счисления:
2 — 11
3 — 111
4 — 1111
5 — 1111 1
6 — 1111 11
2.2. Затем следует «0» – бит-терминатор, означающий
завершение кода размера.
2.3. Затем идут значащие биты до конца текущего байта.
2.4. Далее идёт один или несколько значащих байтов,
которые имеют вид (10xx xxxx), где «10» – биты признака
продолжения, а x – значащие биты.
В общем случае варианты представления одного симво-
ла в кодировке UTF-8 выглядят так:
(1 байт) 0aaa aaaa
(2 байта) 110x xxxx 10xx xxxx
(3 байта) 1110 xxxx 10xx xxxx 10xx xxxx
(4 байта) 1111 0xxx 10xx xxxx 10xx xxxx 10xx xxxx
(5 байт) 1111 10xx 10xx xxxx 10xx xxxx 10xx xxxx 10xx xxxx
(6 байт) 1111 110x 10xx xxxx 10xx xxxx 10xx xxxx 10xx
xxxx 10xx xxxx
Рассмотрим на примере как закодировать русскую бук-
ву «а» в UTF-8.
1. Смотрим в таблицу 11 и определяем Unicode код бук-
вы «a» – 043016.
март 2014 системный администратор
 пятая пара Карьера/Образование

2. Переводим число 043016 в двоичный вид:

Таблица 13. Вспомогательный материал для конвертирования символов из одной
0000 0100 0011 0000.
кодировки в другую
3. Так как русские буквы кодируются двумя сим-
волами, то исходя из определения длины кода
UTF‑8 получаем 11 значащих бит (см. [6]) и выделяем Буква CP1251 UTF16 UTF16→ UTF8 UTF8→
CP1251 CP1251
их с конца 0000 0100 0011 0000.
4. Перегруппируем биты из 100 0011 0000 в 10000 110000. Ё A8 04 01 byte1== D0 81 byte1==
0x04 && byte2== 0xD0 &&
5. Соотнесём данные биты с местом, куда они будут за-
0x01 ? 0xA8 byte2==
писаны в двухбайтовой записи 0x81 ? 0xA8
110x xxxx 10xx xxxx получим 110x xxxx 10xx xxxx
ё B8 04 51 byte1== D1 91 byte1==
10000 110000 → 1 0000 11 0000 0x04 && byte2== 0xD1 &&
6. Запишем результат 1101 0000 1011 0000. 0x51 ? 0xB8 byte2==
7. Переведём в шестнадцатеричный вид, результат готов: 0x91 ? 0xB8
D0 B0. А C0 04 10 D0 90 byte1 ==
Совершать подобные манипуляции вручную для каждой Я DF 04 2F D0 AF
0xD0 ? byte2 +
буквы неудобно, поэтому прибегают к различным упрощаю- 0x30
а E0 04 30 byte1 == D0 B0
щим жизнь таблицам. Зачастую они очень просты, и разъ-
п EF 04 3F 0x04 ? D0 BF
яснять, как ими пользоваться, не имеет смысла. Например, byte2 + 0xB0
таблица 13 создана Stanislav Borutsky [7]. р F0 04 40 D1 80 byte1 ==
0xD1 ? byte2 +
Автор таблицы 14 мне неизвестен. я FF 04 4F D1 8F
0x70

***
На данный момент вы получили первичное представление
о способах кодирования текстовой информации.
Некоторое количество дополнительной информации
и практические задания для самостоятельного выполнения
читатели найдут в следующем номере. EOF
1. Грошев А. С. Информатика: учеб. для вузов/А. С. Грошев. – Ар-
хангельск: Арханг. гос. техн. ун-т, 2010. – 470 с. ISBN 978-5-
261-00480-6.
2. Закляков П. Представление чисел в памяти ЭВМ. Ча-
сти 1 и 2.//«Cистемный администратор», 2012 г.: №3, с.90-96;
№5, с.88-91; №6, с.84-89; №7-8, с.112-121.
3. American National Standards Institute http://www.ansi.org.
4. UTF-8, a transformation format of ISO 10646 http://tools.ietf.org/
html/rfc2279.
5. Internet Assigned Numbers Authority – организация, отвечающая
за административное управление в Интернете – http://www.
iana.org.
6. Примеры ошибок (абракадабра, крякозябры) – http://
ru.wikipedia.org/wiki/UTF-8.
7. Конвертируем русские буквы из UTF8/UTF16 в CP1251 и об-
ратно – http://cax.livejournal.com/59592.html.
8. ISO – http://www.iso.org/ – International Organization for
Standardization; IEC – http://www.iec.ch/ – International
Electrotechnical Commission – ведущие международные орга-
низации по стандартизации, в области электротехники – со-
вместные стандарты.
9. The International Telecommunication Union http://www.itu.int.
10. Дополнительная информация по кодировке KOI8-R – http://koi8.
pp.ru.
11. Как утверждали кодировку KOI8-U, фотографии с места собы-
тия – http://www.net.ua/index.php/ru/koi8umenu/12-lavra, 1997 г.

Таблица 14. Вспомогательная таблица для ручного преобразования кодировок символов

системный администратор март 2014 91

 Карьера/Образование ретроспектива

Визитка

Владимир Гаков, журналист, писатель-фантаст, лектор. Окончил физфак МГУ. Работал в НИИ.
С 1984 г. на творческой работе. В 1990-1991 гг. – Associate Professor, Central Michigan University.
С 2003 г. преподает в Академии народного хозяйства. Автор 8 книг и более 1000 публикаций

Леди-адмирал виртуальных морей

В мартовском номере журнала естественно представить читателю не героя, а героиню
«компьютерного фронта» – их тоже хватает в сравнительно недолгой, но уже славной
истории компьютерной техники и ИТ

Заслуженная «пионерка» молодой науки информати- Хоппер – фамилия мужа, с которым Грейс (урожденная
ки, американка Грейс Марри Хоппер прославилась тем, Марри), прожила в браке полтора десятилетия. Зато геро-
что была одним из первых программистов для одно- иня азимовского цикла не совершила такого карьерного
го из первых компьютеров – Harvard Mark I (см. заметку взлета в сфере, казалось бы, столь далекой от киберне-
в «Зале Славы СА»). И разработала первый компилятор тики, – на флоте!
для компьютерного языка программирования. И пустила Грейс Брюстер Марри родилась в 1906 году в Нью-
в широкий оборот термины «bug» и «debugging» (у нас Йорке и с раннего детства обнаружила редкий для девоч-
прижились, соответственно, «глюк» и «разглючивание»). ки интерес ко всему механическому. Больше радости, чем
И – что самое удивительное – первой в Штатах дослужи- куклы, маленькой Грейс доставляли разборки домашних
лась до адмиральских погон! будильников («чтобы посмотреть, как там все устроено»).
Собрать их обратно, к сожалению, получалось не всегда –
Прообраз Сьюзен Келвин за что родители устраивали дочери выволочку. Однако за-
Кто такая Сьюзен Келвин, для читателей – любителей на- тем, поняв, что это, видимо, призвание Грейс, специально
учной фантастики – долго объяснять не надо. Вспомнят эту покупали ей дешевые часы – пусть себе возится с ними
фамилию и те, кто этих книжек не читал, но хотя бы смо- на здоровье! В общем, чем бы дитя ни тешилось…
трел недавний фильм «Я, робот». Сьюзен Келвин – главная После окончания средней школы в штате Нью-
героиня знаменитого цикла рассказов (а затем и романов) Джерси 16-летняя Грейс попыталась поступить в престиж-
Айзека Азимова о роботах, специалист-робопсихолог, ный колледж Вассар, но не прошла конкурс (помешали
много сделавшая для того, что свести к минимуму недопо- низкие оценки по латыни). Пришлось повторять попытку
нимания и конфликты, связанные годом позже – и на сей раз
с появлением в человеческом мире удачно. В 1928 году талантли-
искусственных разумных существ. вая девушка закончила этот
Умная и талантливая – но одино- колледж с отличием и сразу
кая, суховатая и внешне непри- двумя дипломами – математи-
влекательная женщина, полностью ка и физика. А двумя годами
посвятившая жизнь своей науке. позже защитила магистер-
И своим роботам. скую диссертацию в еще
Выдающийся американский пи- более престижном высшем
сатель-фантаст признавался (в том учебном заведении – зна-
числе лично – автору этих строк), менитом Йельском уни-
что свою Сьюзен Келвин он частич- верситете. За докторской
но «списал» с Грейс Хоппер, о кото- дело также не задержа-
рой к началу 1950-х годов знали все, лось – в том же университе-
кто интересовался наукой. Особенно те в 1934 году Грейс защи-
передним ее краем – в частности, тила диссертацию на тему
кибернетикой. Хотя реальная «Сью- «Новые типы критериев
зен Келвин» в жизни, может быть, неприводимости». К тому
и не блистала красотой, но и ученым- времени она уже носила
шины карьеры еще впереди
«сухарем», и «синим чулком» не была: Вер фамилию мужа – профес-

92 март 2014 системный администратор

 ретроспектива Карьера/Образование

сора из Нью-Йоркского университета – и преподавала

математику в своей alma mater – колледже Вассар. С му-
жем Грейс Хоппер развелась в 1945-м и с тех пор больше
замуж не выходила.
Можно предположить, что у нее уже просто не было
свободного времени ни на что, кроме науки. И службы
на флоте, где Хоппер блистательно доказала, что давняя
морская примета «баба на корабле – быть беде» – суе-
верие, и ничего больше.
Служить на флоте молодая женщина-математик по-
шла добровольцем уже во время Второй мировой во-
йны. А точнее, в 1943 году – спустя год, как в структу-
ре американского ВМФ было создано специальное
подразделение для женщин-добровольцев – WAVES
(Women Accepted for Volunteer Emergency Service). Нет,
разумеется, капитанские мостики и даже матросские
каюты представительницам слабого пола тогда еще
не доверяли (время воинствующего – во всех смыс-
лах – феминизма было впереди), но на флоте хватало
и «наземной» работы. В частности, в научно-исследо-
вательских центрах, которые у нас назывались «по-
чтовыми ящиками». В один из таких пришла работать
и Грейс Хоппер – после того, как прошла подготовку
в военно-морском училище. Кстати, на флот Хоппер Мар
т 1946 г. Хоппер уже лейтена
приняли в виде исключения: ее вес – чуть более 47 ки- нт
лограммов явно не дотягивал до установленной ниж-
ней планки – 54 кг…
И в 1944 году она уже – младший лейтенант флота Со- ров» обгорелые останки мотыльков и прочей мошкары,
единенных Штатов. А по совместительству – научный со- слетавшейся, как ей и положено, на свет и тепло. Резуль-
трудник Гарвардского университета, в котором разраба- татом такого самоубийственного вторжения насекомых
тывался один из первых в своем роде секретных проектов становились, как и следовало ожидать, короткие замыка-
для нужд обороны. Один из первых, потому что проект ния. Об этом Хоппер не уставала рассказывать в лекциях
был – компьютерным. и многочисленных интервью – и термин прижился! А спустя
короткое время вслед за «жучками» (bugs) в словари ан-
Бизнес-перевод глийского языка перешел и глагол-неологизм «разжучи-
Возглавлял проект ученый-физик Говард Эйкен, под руко- вание» (или «ужучивание») – debugging. У нас известный,
водством которого была создана электромеханическая вы- как «разглючивание».
числительная машина ASCC (Automatic Sequence Controlled А в 2003 году, в день 107-летия Грейс Хоппер компа-
Calculator – Автоматический вычислитель, управляемый ния GOOGLE отметила своей фирменной анимационной
последовательностями). По мнению некоторых историков «заставкой-к-дате» (GOOGLE DOODLE), изобразив Хоп-
компьютерной техники, это и был первый компьютер – в на- пер за компьютером, из которого вылетала… Правильно,
шем сегодняшнем понимании. Впоследствии, из-за тре- мошка!
ний, возникших между Эйкеном и спонсором – компанией Обеим этим сферам деятельности – информатике
IBM, ученый переименовал свое детище в Harvard Mark I, и службе на флоте – Хоппер не изменила до конца дней.
продолжив в Гарварде работу над следующими моделями В самом конце войны она еще порывалась перевестись
«университетской фирменной марки». А первые програм- из резерва (где и числились все эти «яйцеголовые», ра-
мы к «первой марке» написала как раз сотрудница Эй- ботавшие на Пентагон и ВМФ) на действующий флот,
кена – морской офицер Грейс Хоппер. Она же написала но ее туда не пустили. Из-за возраста – рвавшейся в бой
в соавторстве с «шефом» три основополагающие статьи, «математичке с погонами» было тогда 38… Так всю остав-
посвященные архитектуре первого компьютера. шуюся жизнь Хоппер провела в резерве ВМФ, а закончила
Примерно тогда же, с легкой руки Хоппер, пошел гулять службу, как уже говорилось, с адмиральскими погонами
по миру профи-компьютерщиков, а позднее – и «чайников»- (или что там у них, на американском флоте, служит знака-
юзеров, популярный ныне слэнговый термин «bug» («глюк» ми отличия). А параллельно, начиная с 1949 года, занимала
по-нашему). Вообще-то его изобрела не Хоппер, еще рань- профессорскую должность в своей alma mater – коллед-
ше его употребляли английский специалисты, разрабаты- же Вассар, совмещая ее с работами по контрактам с ВМФ
вавшие первые радары во время войны. «Жучками» они в том же Гарварде.
называли непредвиденные сбои в работе электросхем, Впрочем, энергии женщины-математика хватало
однако в первых ламповых компьютерах термин получил и на прочие «совмещения». В том же 1949 году она,
неожиданное буквальное толкование. Хоппер и ее сотруд- не прекращая своей службы на флоте и академической
ники замучились выметать из недр ламповых «динозав- деятельности в колледже, открыла для себя новую сфе-

системный администратор март 2014 93

 Карьера/Образование ретроспектива

ру деятельности. На сей раз это был бизнес. Причем, ции по языкам систем обработки данных – CODASYL
не обычный – молодой, компьютерный. Хоппер устроилась (Conference on Data Systems Languages).
на работу в Eckert-Mauchly Computer Corporation (назва- Главным достоинством нового языка была его макси-
ние которой много говорит тем, кто хотя бы в общих чер- мальная приближенность к разговорному английскому –
тах знаком с историей компьютерной техники: ну, конечно, в отличие от тех, что были ближе к машинному коду (на-
Экерт и Мокли – создатели легендарного ENIAC!), где вме- пример, ассемблеров). На этом всегда настаивала Хоппер,
сте с другими создавала первый американский (и третий и COBOL стал венцом творения ее философии програм-
в мире) коммерческий компьютер – UNIVAC I. Эта работа мирования. А его создательница удостоилась прозвища
была завершена в 1951 году – спустя год, как фирма Экер- Grandma COBOL, что можно – с достаточной степенью
та и Мокли была куплена корпорацией Remington Rand, вольности – перевести, как «бабушка-домовая» (добро-
продавшей первый UNIVAC американскому Бюро по пере- душных домовых в северной мифологии звали кобольдами,
писи населения. что созвучно названию данного языка).
Уже будучи сотрудницей Remington Rand, Грейс Хоппер Параллельно продолжался и карьерный рост «морячки»
создала первый в истории компилятор – то есть средство Хоппер. В период с 1967 по 1977 годы она занимала пост
перевода компьютерной программы с «проблемно-ориен- директора группы программирования в департаменте ин-
тированного» языка на «машинно-ориентированный». Пер- формационных систем ВМФ США, дослужившись до чина
вый компилятор носил лаконичное название A, а его первая капитана. Тогда же она разработала валидационное про-
версия, вопреки ожидаемому, – A-0. Тогда это была своего граммное обеспечение для COBOL и его компилятора.
рода маленькая революция. «Никто не верил, – вспомина- А затем «пробила» в Пентагоне свой план децентрали-
ла Хоппер, – что у меня есть такой «переводчик» с одного зации всей оборонной компьютерной техники – переход
машинного языка на другой. Все убеждали меня, что этого от громоздких централизованных систем на базе «боль-
просто не может быть – компьютеры способны произво- ших» машин к децентрализованным сетям распределен-
дить лишь арифметические операции и ничего сверх того». ных компьютеров. Хоппер разработала также первые
стандарты тестирования компьютерных систем и отдель-
Бабушка-домовая – и водяная ных компонентов, а также ранних языков программирова-
Не прошло и двух лет, как – поверили. Выражением «до- ния – того же COBOL, к примеру, или FORTRAN). Позже
верия широких руководящих масс» стало назначение эта система стандартизация была принята на вооружение
Хоппер в 1954 году первым в истории компании начальни- Национальным бюро стандартов США (ныне – Националь-
ком отдела автоматизации и программирования. Из недр ный институт стандартов и технологий).
этого отдела вышли одни из первых т.н. компилируемых А бабушке было уже немало лет, и она все никак не мог-
языков программирова- ла расстаться с полюбившейся
ния – такие, как MATH- ей морской формой! В отставку
MATIC и FLOW-MATIC. По- морской офицер в юбке (пусть
следний, к слову, уже был и форменной) отправлялась
способен «понимать» два не раз. Впервые это произо-
десятка фраз, написанных шло по достижении положен-
на английском – не машин- ного шестидесятилетнего воз-
ном! – языке. раста – то есть, в 1966 году.
А еще спустя пять лет Однако не прошло и года,
под руководством Хоппер как флоту снова понадобилась
был создан новый язык дама-командор (соответствует
программирования – один нашему капитану второго ран-
из первых т.н. «высокоуров- га) с талантами математика,
невых»: COBOL (аббревиа- и Грейс Хоппер вновь призва-
тура от Common Business- ли на службу. Сначала вроде
Oriented Language – Общий бы на полгода, которые в итоге
бизнес-ориентированный обернулись без малого двумя
язык). При разработке десятилетиями…
COBOL были использова- Второй выход в отставку со-
ны как идеи FLOW-MATIC, стоялся в 1972 году – и снова
так и достоинства другого краткосрочный. Уже в сле-
языка – COMTRAN, разра- дующем году Грейс Хоппер
ботанного специалистами снова носила форму, на сей
IBM. Презентация ново- раз – капитанскую (соответ-
го языка, который обещал ствует нашему капитану пер-
стать универсальным «язы- вого ранга).
ком общения» бизнесме- И наконец, в 1983 году тог-
нов с компьютерами, со- дашний президент Рональд
стоялась весной 1959 года Рейган специальным ука-
детище Грейс Хоппер
на двухдневной конферен- COBOL – зом произвел Грейс Хоппер

94 март 2014 системный администратор

 ретроспектива Карьера/Образование

в коммодоры – иначе говоря, командую- ди-профессор» с дурацкими

щего уже целой эскадрой (у нас аналога вопросами: почему, мол, при-
этого звания нет, зато существовал ана- ходится так долго ждать от-
лог в дореволюционном российском – ка- ветного сигнала со спутника
питан-командор). Это звание и в амери- на орбите… Тот же, провод,
канском ВМФ просуществовало недолго кстати, хорошо иллюстриро-
и в 1985 году было заменено званием вал один из постоянных те-
контр-адмирала (Rear Admiral). В адми- зисов Хоппер-лектора: чтобы
ральском звании Грейс Хоппер в третий добиться большего быстро-
раз вышла в отставку – на сей раз окон- действия компьютера, его нуж-
чательно. но уменьшать до пределов
возможного.
Жизнь после службы Своим самым главным
Во время торжественной церемонии достижением в жизни, кро-
проводов на пенсию, состоявшейся ме создания компилятора,
в Бостоне в августе 1986 года, на бор- Грейс Хоппер считала сво-
ту крейсера Constitution контр-адмиралу их учеников: «Они подходят
Хоппер была вручена высшая воинская ко мне, спрашивая, получится
награда для американца, не прини- ли у них. А я всегда отвечаю:
мавшего участия в боевых действиях: пробуйте. И, как могу, под-
медаль за заслуги в обороне страны Коммодор Хоппер держиваю их во всех начи-
(Defence Distinguished Service Medal). наниях. Им это необходимо.
Любопытно, что на тот момент «бабуш- Я слежу за своими учениками,
ка-адмирал» была старейшим действующим офицером за их успехами, время от времени подталкивая их на риск,
американского флота! Как заметил экс-сотрудник Apple без которого не ответишь на многие вызовы, которые ста-
и автор книги о Стиве Джобсе Джей Эллиот: «Внешне Хоп- вят перед каждым жизнь и профессия».
пер всегда держалась, как подобает морскому офицеру, Грейс Хоппер закончила свой жизненный путь
но если бы вы копнули вглубь, то под личиной морского в 1992 году, когда заслуженному профессору и адмиралу
офицера сразу же обнаружили бы пирата, умиравшего в отставке шел 86-й год. Похоронили ее со всеми воински-
от желания вырваться наружу». ми почестями на национальном военном кладбище в сто-
Однако, и, выйдя в отставку, «бабушка-адмиральша», личном пригороде Арлингтоне.
судя по всему, на покой уходить не собиралась. Она тут же Список ее почетных дипломов и званий, включений
устроилась старшим консультантом в известную тогда ком- в не менее почетные списки, орденов и медалей и прочих
пьютерную компанию Digital Equipment Corporation (DEC), военных, гражданских и научных наград займет добрых пол-
активно разъезжала по стране с лекциями – бывало, что де- листа. Есть забавные – все эти «человеки года», которые
лала по 200 лекций в год! Неизменно вызывая фурор сво- тогда по-английски звучали совсем не политкорректно (фе-
ей адмиральской формой, которую продолжала надевать министки сказали бы – «гендерно-шовинистически»): «Man
«для особых случаев». of the Year»… Но среди всех наград выделяются две – дей-
Так Грейс Хоппер успела прославиться еще раз – теперь ствующий эсминец ВМФ США и один из серии знаменитых
уже как талантливый лектор-популяризатор. В частности, суперкомпьютеров компании Cray. Оба носят имя Hopper.
пожилая дама-лектор в адмиральской форме поражала ау- В общем, не жизнь – фантастика! Куда там писателю
диторию оригинальным визуальным «подручным материа- Азимову… EOF
лом» – 30-сантиметровым обрезком
телефонного кабеля производства
компании Bell. Именно такое рас-
стояние, поясняла ошеломленным
слушателям Хоппер, свет в вакуу-
ме проходит за одну миллионную
долю секунды (одну наносекунду).
А в проводе, соответственно, чуть
медленнее… Утверждается, что по-
пуляризации самого этого терми-
на – наносекунда – немало поспо-
собствовала как раз Грейс Хоппер.
А наглядный «лекционный матери-
ал» (тот самый обрывок провода)
она впервые успешно испытала
на самой неблагодарной категории
слушателей – высоких военных чи- Эсминец «Хоппер»
нах. Те постоянно приставали к «ле-

системный администратор март 2014 95

 Зал славы «СА»

Гарвардская
Издается с 2002 года

Включен в Российский индекс

марка
научного цитирования www.elibrary.ru

Генеральный директор
Владимир Положевец
Главный редактор
Галина Положевец, chief@samag.ru
Очередной экспонат создаваемого на страницах
Исполнительный директор
журнала виртуального музея компьютеров и ИТ Владимир Лукин, maker@samag.ru
стоит в ряду претендентов на звание первого ком- Заместитель главного редактора
Ирина Ложкина, lozhkina@samag.ru
пьютера в истории. Ответ на вопрос, почему разные источники называют «первым компьюте- Заместитель главного редактора,
ром» разные вычислительные машины (с некоторыми читатели уже смогли познакомиться), пря- официальный представитель редакции в Украине
Сергей Яремчук, grinder@samag.ru
мо вытекает из точного наблюдения кого-то из великих: «Все споры начинаются либо потому, Обозреватель
что одну и ту же вещь называют разными именами, либо потому, что разные вещи называют Aндрей Степанов, stepanov@samag.ru
одним и тем же именем». Иначе говоря, корень всех этих приоритетных споров – в определении, Главный бухгалтер
что же считать компьютером. Надежда Кан, buch@samag.ru
Громоздкая вычислительная машина, созданная во время Второй мировой войны (в первый
Главный редактор приложения «Open Source»
год войны для Штатов – 1941-й) специалистами Гарвардского университета и корпорации IBM, Дмитрий Шурупов, osa@samag.ru
весила около четырех с половиной тонн и занимала в указанном университете несколько поме-
Реклама
щений. Первоначально этот компьютерный «динозавр» назывался скучно, но точно: Automatic Лариса Говорченко, govorchenko@samag.ru
Sequence Controlled Calculator (ASCC) – Автоматический вычислитель, управляемый после-
Распространение
довательностями, но позже получил краткое название Harvard Mark I. Под каковым и вошел Олег Иванов, subscribe@samag.ru
в историю. По сути, это был увеличенный до невообразимых размеров и усовершенствованный
Юридический отдел
до пределов, которые ставила тогдашняя техника, арифмометр. Но – и это самое важное! –
Владимир Столяров, stolyarov@samag.ru
программируемый. А отсюда и претензии на право называться первым компьютером. Причем
Дизайн обложки Дизайн-макет
первым американским, так как двумя годами ранее аналогичная машина была создана в стра- Михаил Лебедев Марина Рязанцева,
не-противнице – Германии (о ней и о ее создателе Конраде Цузе – разговор особый). Иллюстрация Дмитрий Бессонов
Виктор Чумачев
В Гарварде работы по созданию этой махины возглавил сорокалетний инженер Говард Хата-
уэй Эйкен, к тому времени работавший в IBM. За два года до того он защитил в Гарварде доктор- Редакционная коллегия
Д. Ю. Гудзенко, кандидат технических наук, директор Центра
скую диссертацию, во время работы над которой столкнулся со всем знакомой (в «докомпьютер- компьютерного обучения «Специалист» при МГТУ
им. Н.Э.Баумана
ную» эру) проблемой – численными решениями дифференциальных уравнений. Эта проблема Д. Ю. Динцис, доктор технических наук, ведущий
и послужила своего рода «триггером» для рождения вычислительной техники – сначала элек- преподаватель Центра компьютерного обучения «Специалист»
при МГТУ им. Н.Э.Баумана
тромеханической, а затем уже и электронной. Одной из первых работающих моделей (электро- А. С. Крюковский, доктор физико-математических наук,
профессор, лауреат Государственной премии СССР, декан
механической) и стал ASCC. факультета информационных систем и компьютерных
технологий Российского нового университета
Помощь в решении поставленной задачи была оказана Эйкену как интеллектуальная (чет- Э. С. Клышинский, кандидат технических наук, доцент,
зам. декана по научной работе факультета информационных
веро коллег, включая Грейс Хоппер – см. о ней статью в этом номере журнала), так и материаль- технологий и вычислительной техники МИЭМ НИУ «Высшая
ная (полмиллиона долларов, выделенных лично президентом IBM Томасом Уотсоном-старшим). школа экономики»
В. Е. Синицын, кандидат физико-математических наук, доцент
По утверждению самого Эйкена, за основу он взял идеи нереализованной «дифференциальной Уральского федерального университета
Д. В. Силаков, кандидат физико-математических наук, старший
машины» английского «компьютерного предтечи» – математика и изобретателя Чарлза Бэббид- архитектор российского Центра разработки решений на основе
СПО «РОСА»
жа. К февралю 1944 года прошедшая первые тесты машина переехала в корпуса Гарвардского С. Р. Тумковский, доктор технических наук, профессор,
университета, где в августе состоялась ее официальная презентация. зав. кафедрой факультета информационных технологий
и вычислительной техники МИЭМ НИУ «Высшая школа
По тем временам компьютерное чудо – первая полностью автоматическая вычислительная экономики»
А. В. Тетюшев, кандидат технических наук, доцент
машина, работавшая без вмешательства человека в рабочий процесс, – казалось чем-то не- Вологодского государственного технического университета
виданным. И великим – во всех смыслах. Корпус из стекла и нержавеющей стали скрывал бо-
Экспертный совет
лее 700 тысяч деталей и около 800 километров проводов. Что касается работоспособности Рашид Ачилов, администратор телекоммуникационных систем
Сергей Барамба, эксперт по системным решениям
лампового «монстра», то ASCC мог оперировать 72 числами (каждое из 23 десятичных раз- Алексей Бережной, эксперт по администрированию и ИБ
Андрей Бирюков, ведущий системный инженер по ИБ
рядов) с быстродействием 3 операции сложения или вычитания в секунду. Операция умножения Алексей Вторников, эксперт по вопросам разработки ПО
занимала 6 секунд, деления – чуть более 15 секунд. А вычисление логарифма или тригономе- Константин Кондаков, старший директор по ИТ
Иван Коробко, эксперт по автоматизации процессов в Windows-
трической функции – вообще целую вечность: более минуты. Все инструкции последователь- доменах
Кирилл Сухов, ведущий специалист направления интернет-
но считывались и выполнялись с перфорированной бумажной ленты, а петли из нее служи- разработки
Леонид Шапиро, эксперт по ИБ и инфраструктурным проектам
ли для выполнения циклических вычислений (по-английски loops – это и «циклы», и «петли»). Сергей Яремчук, эксперт по ИБ
А Mark компьютер был окрещен самим Эйкеном после того, как между создателем и руко-
Издатель
водством IBM возник конфликт. Дело в том, что на церемонии передачи машины в собственность ООО «Синдикат 13»
Гарвардского университета Эйкен в своей речи совсем «забыл» о вкладе IBM. Главу компании Адрес редакции
129075, г. Москва, Шереметьевская ул., д. 85, стр. 2, офис 405,
это сильно покоробило, и Уотсон сразу же прекратил сотрудничество с Эйкеном. И следующую тел.: (499) 277-12-41, факс: (499) 277-12-45
Сайт журнала: www.samag.ru
модель SSEC компания разрабатывала уже без него.
Но и Эйкен не остался без работы. Окрестив свое детище Harvard Mark I, он уже в качестве Отпечатано в типографии
ООО «Периодика» Тираж 17000 экз.
сотрудника вышеозначенного университета разработал собственные «апгрейды» – модели Mark
II, III и IV. В третьей модели уже имелась кое-какая электронная начинка, а «четверка» была Все права на материалы принадлежат журналу «Системный
администратор». Перепечатка и использование материалов в любой
полностью электронной вычислительной машиной (в которой наряду с магнитными бобинами форме, в том числе и в электронных СМИ, без разрешения запре-
щена. При использовании материалов ссылка на журнал «Системный
были и новомодные элементы памяти на магнитных сердечниках). Дело пошло! EOF администратор» обязательна. Материалы отмеченные знаком Adv
публикуются на коммерческой основе. Редакция не несет ответствен-
Собрал Владимир Гаков ности за достоверность информации в материалах, опубликованных
на правах рекламы.

96 март 2014 системный администратор