Sysadmin 01 02 2017 by batmanzorro2000

Журнал входит в перечень ВАК Минобрнауки РФ

№01-02(170-171) январь-февраль 2017

Virtuozzo Automator Управляем Virtuozzo через веб‑интерфейс

Нестандартный back‑end для веб‑приложений

«Тихая» установка программ в SCCM

Kubernetes Управление большим количеством контейнеров

Современная веб‑архитектура

Быстрее некуда

Яндекс ClickHouse: что это такое и зачем оно нужно? Наука и технологии

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

Низкоуровневая оптимизация производительности на примере функции хеширования по ГОСТ Р 34.11‑2012

Влияние запаздывания сигналов в виртуальном сетевом пространстве на точность и устойчивость систем автоматического управления

Разработка веб‑конструктора графических пользовательских интерфейсов для системы управления «умного» здания

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

Только полезная

информация

№01-02(170-171) январь-февраль 2017

Virtuozzo Automator Управляем Virtuozzo через веб-интерфейс

Бумажная

Нестандартный back-end для веб-приложений

электронная версии

«Тихая» установка программ в SCCM

Kubernetes

5800 руб.

Управление большим количеством контейнеров

Современная веб-архитектура

е некуоеда Быстре и зачем оно нужно? use: что это так Яндекс ClickHo Наука и технологии

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

Низкоуровневая оптимизация производительности на примере функции хеширования по ГОСТ Р 34.11-2012

Разработка веб-конструктора графических пользовательских интерфейсов для системы управления «умного» здания

Бумажная версия – 4800 руб. Электронная версия – 2000 руб.

Подписывайтесь прямо на сайте! samag.ru/subscribe

В номере

ЗАКОН ЕСТЬ ЗАКОН

Виртуализация

Как будет развиваться ИТ-право в ближайшем будущем? В последнее время все чаще звучат разговоры о приня-

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

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

Virtuozzo Automator. Управляем Virtuozzo через веб-интерфейс. До сих пор в статьях про Virtuozzo мы ограничивались описанием утилит командной строки. Но, несмотря на множество возможностей этого инструментария, было бы слишком опрометчиво ограничиваться исключительно им. Денис Силаков

Работа с контейнерами Docker. Часть 1. Основы. Узнаем, как на практике управлять контейнерами Docker, об организации взаимодействия между ними и управлением кластерами контейнеров. Андрей Маркелов

АДМИНИСТРИРОВАНИЕ

Знакомимся с Kubernetes. Управление большим количеством контейнеров на нескольких серверах штатными инструментами Docker – не очень простая задача. Google предлагает эффективное решение.

Хранение данных

Сергей Яремчук

Особенности построения SAN на базе протокола Fibre Channel. Мы продолжаем разговор о сетях SAN протокола и стандарта Fibre Channel. В этот раз речь пойдет о методах организации взаимодействия устройств в таких сетях хранения данных.

Облачные технологии

Алексей Бережной

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

«Тихая» установка программ в SCCM. Специальные

Леонид Шапиро

Инструменты

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

IP-ТЕЛЕФОНИЯ Внедрение

Сергей Болдин

Собираем планшет своими руками. Поговорим о том, как на основе микрокомпьютера Raspberry Pi собрать планшет под управлением ОС Linux. Андрей Бирюков

Доставка приложений в корпоративном ЦОДе и облачных средах. Часть 3. Отказоустойчивость ADC.

Настройка MS Lync 2013. Часть 3. Настройка дополнительных функций. Рассмотрим следующие функции: парковка и перехват звонков, собрание с применением ПИН-кода. Сергей Болдин

январь-февраль 2017 системный администратор

В номере

БАЗЫ ДАННЫХ

РАЗРАБОТКА

Новый дистрибутив

Истоки программирования

Яндекс ClickHouse. Быстрее некуда. Недавно в свободный доступ попала Open Source СУБД компании Яндекс – ClickHouse, которая обслуживает Яндекс.Метрику. Посмотрим, что это такое?

Философский камень программирования: язык С. Недавно минуло пять лет, как ушел из жизни один из наиболее влиятельных людей современности. Он не был бизнесменом. Он не был звездой шоу-бизнеса. И уж тем более он не был политиком. Он был программистом, и звали его Деннис Макалистер Ритчи (Dennis M. Ritchie).

Олег Филиппов

Инструменты

Алексей Вторников

Теория управляемого хаоса в Oracle. Часть 3. Практика применения в Oracle. Во второй части статьи рассматривались вопросы применения теории хаоса к Oracle, содержащему процессы объективного хаоса. В третьей части рассматриваются подсистемы Oracle с субъективным и искусственным хаосом.

Владимир Тихомиров, Валерий Михеичев

Александр Календарев

КАРЬЕРА/ОБРАЗОВАНИЕ

Нестандартный back-end для веб-приложений. Практическое применение HTTP-сервисов в 1С:Предприятие 8. Слово «back-end» у современных разра-

Аlma mater российских ИТ

ботчиков невольно ассоциируется с мейнстримовыми технологиями вроде Java, ASP .NET, PHP, Node.js. Популярный стек технологий для веб-приложений прочно укрепился в умах разработчиков, и, кажется, новичкам на этом поприще нет места. Отнюдь! Новые инструменты приходят с неожиданных сторон и занимают уверенные позиции в новых нишах. Игорь Антонов

Современная веб-архитектура. От монолита к микросервисам. Микросервисы – это небольшие самодостаточные программы или сервисы, которые выполняют одну маленькую задачу. Они работают совместно с другими программами (сервисами).

Изучаем 1С

Веб-технологии

Применение в 1С индуктивного вычисления функций. Использование в программах на внутреннем языке програм-

Арутюн Аветисян: «Для талантливых и трудолюбивых студентов у нас созданы все условия». В гостях у «Системного администратора» доктор физико-математических наук, член-корреспондент Российской академии наук, директор Института системного программирования Российской академии наук Арутюн Аветисян. Галина Положевец

Кадровая политика по «физтеховской» модели. Ка-

мирования 1С индуктивного вычисления функций на пространстве последовательностей.

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

Кирилл Ткаченко

Анна Новомлинская

системный администратор январь-февраль 2017

В номере

Рынок труда

НАУКА И ТЕХНОЛОГИИ

Вакансия: программист .NET. Платформа .NET позволяет реализовывать настольные приложения для ОС Windows и мобильные для Windows Phone. Языки программирования, ориентированные на использование вместе с платформой .NET, демонстрируют устойчивую популярность (C# – 4-е место) и даже рост (Visual Basic .NET – с 6-го на 7-е место). Об этом свидетельствовал индекс TIOBE на момент написания данной статьи. Мы попросили представителей компаний рассказать о знаниях, навыках, опыте, актуальных для программиста .NET сегодня.

Раздел для научных публикаций

111

невой оптимизации производительности для архитектуры x86 на примере хеш-функции по ГОСТ Р 34.11-2012. Проанализированы результаты использования оптимизирующих компиляторов, встроенных функций и ассемблерных вставок на распространенных микроархитектурах процессорах Intel и AMD. Показана существенная зависимость достигнутого с применением методов низкоуровневой оптимизации увеличения производительности от особенностей процессорной микроархитектуры.

Игорь Штомпель

Лабораторная работа

Северин П.А., Гольчевский Ю.В.

Лабораторная работа: исследование сетевого трафика. Можно ли как-то увидеть сетевой трафик? Напри-

120

мер, подобно тому, как тестер «показывает» электрический ток, напряжение, а осциллограф – форму? Ответ – можно.

Особое мнение

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

Ретроспектива

106

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

Павел Закляков

101

Низкоуровневая оптимизация производительности на примере функции хеширования по ГОСТ Р 34.11-2012. В статье исследуются возможности низкоуров-

Клименкова О.Д.

124

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

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

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

Владимир Гаков

Туманов М.П.

Сумрачный славянский гений. В следующем году ис-

январь-февраль 2017 системный администратор

БИК 044525225 Сч. № 30101810400000000225

ПАО СБЕРБАНК Г. МОСКВА Банк получателя

КПП 771701001 ИНН 9717008803 ООО "ИЗДАТЕЛЬСКИЙ ДОМ ПОЛОЖЕВЕЦ И ПАРТНЕРЫ"

Сч. № 40702810138000086304

Получатель

Счет на оплату № 2017СА Поставщик ООО "ИЗДАТЕЛЬСКИЙ ДОМ ПОЛОЖЕВЕЦ И ПАРТНЕРЫ", ИНН 9717008803, КПП 771701001, (Исполнитель): 129515, Москва г, Академика Королева ул, дом № Дом 13, корпус Строение 1, квартира Пом. Ii Ком. 63, тел.: 8(499)2771241 Покупатель (Заказчик): Основание: № 1 2 3 4 5 6 7 8 9 10

Счет 2017СА Товары (работы, услуги)

Журнал "Системный администратор" № 1-2/2017 (январь-февра Журнал "Системный администратор" № 3/2017 (март) Журнал "Системный администратор" №4/2017 (апрель) Журнал "Системный администратор" №5/2017 (май) Журнал "Системный администратор" №6/2017 (июнь) Журнал "Системный администратор" № 7-8/2017 (июль-август) Журнал "Системный администратор" № 9/2017 (сентябрь) Журнал "Системный администратор" № 10/2017 (октябрь) Журнал "Системный администратор" № 11/2017 (ноябрь) Журнал "Системный администратор" № 12/2017 (декабрь)

Кол-во

1 1 1 1 1 1 1 1 1 1

Ед.

шт шт шт шт шт шт шт шт шт шт

Цена

800,00 400,00 400,00 400,00 400,00 800,00 400,00 400,00 400,00 400,00

Итого: Без налога (НДС) Всего к оплате:

Всего наименований 10, на сумму 4 800,00 руб. Четыре тысячи восемьсот рублей 00 копеек

Сумма

800,00 400,00 400,00 400,00 400,00 800,00 400,00 400,00 400,00 400,00

4 800,00 4 800,00

Оплата данного счета означает согласие с условиями поставки товара. Товар отпускается по факту прихода денег на р/с Поставщика. Руководитель

Положевец Г.В.

Бухгалтер

Положевец Г.В.

Чтобы оформить редакционную подписку на журнал "Системный администратор" 2017 г.: Оплатите данный счет. Пришлите точный почтовый адрес доставки на e-mail: subscribe@samag.ru с указанием наименования подписчика и реквизитов (если юр. лицо) или Ф,И.О. и точный почтовый адрес доставки (если физ. лицо). Ваша подписка будет оформлена. Дополнительная информация на сайте: samag.ru тел. 8 (499) 277-12- 41

Шаг 1. Шаг.2

С уважением, Издательский дом "Положевец и партнеры".

БИК 044525225 Сч. № 30101810400000000225

ПАО СБЕРБАНК Г. МОСКВА Банк получателя

ИНН 9717008803 КПП 771701001 ООО "ИЗДАТЕЛЬСКИЙ ДОМ ПОЛОЖЕВЕЦ И ПАРТНЕРЫ"

Сч. № 40702810138000086304

Получатель

Счет на оплату № 2017БИТ Поставщик ООО "ИЗДАТЕЛЬСКИЙ ДОМ ПОЛОЖЕВЕЦ И ПАРТНЕРЫ", ИНН 9717008803, КПП 771701001, (Исполнитель): 129515, Москва г, Академика Королева ул, дом № Дом 13, корпус Строение 1, квартира Пом. Ii Ком. 63, тел.: 8(499)2771241

Покупатель (Заказчик): Основание: № 1

2 3 4 5 6 7 8 9 10

Счет 2017БИТ Товары (работы, услуги)

Журнал «БИТ. Бизнес&Информационные технологии» №1/2017 (февраль) Журнал «БИТ. Бизнес&Информационные технологии» №2/2017 (март) Журнал «БИТ. Бизнес&Информационные технологии» №3/2017 (апрель) Журнал «БИТ. Бизнес&Информационные технологии» №4/2017 (май) Журнал «БИТ. Бизнес&Информационные технологии» №5/2017 (июнь) Журнал «БИТ. Бизнес&Информационные технологии» №6/2017 (август) Журнал «БИТ. Бизнес&Информационные технологии» №7/2017 (сентябрь) Журнал «БИТ. Бизнес&Информационные технологии» №8/2017 (октябрь) Журнал «БИТ. Бизнес&Информационные технологии» №9/2017 (ноябрь) Журнал «БИТ. Бизнес&Информационные технологии» №10/2017 (декабрь)

Кол-во

Ед.

1 шт

Цена

400,00

Сумма

400,00

1 шт

400,00

1 шт

400,00

1 шт

400,00

1 шт

400,00

1 шт

400,00

1 шт

400,00

1 шт

400,00

1 шт

400,00

1 шт

400,00

Итого: Без налога (НДС) Всего к оплате:

4 000,00 4 000,00

Всего наименований 10, на сумму 4 000,00 руб. Четыре тысячи рублей 00 копеек Оплата данного счета означает согласие с условиями поставки товара. Товар отпускается по факту прихода денег на р/с Поставщика. Руководитель

Положевец Г.В.

Бухгалтер

Положевец Г.В.

Чтобы оформить редакционную подписку на журнал "БИТ.Бизнес&Информационные технологии" 2017 г.: Шаг 1. Оплатите данный счет. Шаг.2 Пришлите точный почтовый адрес доставки на e-mail: subscribe@samag.ru с указанием наименования подписчика и реквизиты (если юр. лицо) или Ф,И.О. и точный почтовый адрес доставки (если физ. лицо). Ваша подписка будет оформлена. Дополнительная информация на сайте: samag.ru тел. 8 (499) 277-12-41 С уважением, Издательский дом "Положевец и партнеры".

В номере

127

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

139

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

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

Николаев П.Л.

130

Программное приложение кластеризации данных. Рассматривается технология создания веб-ресурса, реализующего алгоритмы кластерного анализа с максимально простым и понятным пользовательским интерфейсом, а также возможностью дальнейшего расширения выполняемых функций. Описываются структура и алгоритм работы такого приложения. Результат работы продемонстрирован на разобранном в статье примере. Бучацкая В.В., Бучацкий П.Ю., Гущин К.А.

134

Агрегирование и декомпозиция статистических данных и ключевых показателей в процессе управления социально-экономическим развитием Субъектов РФ. Часть 2. Расширение предложенного варианта модели подготовки данных и принятия решения ОГВ Субъекта РФ с использованием средств бизнес-аналитики на весь цикл управления. В статье описывается расширенный ва-

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

Казакова Н.А., Дун И.Р.

ЗАЛ СЛАВЫ «СА»

144

риант принятия решений цикла и исполнения в органах государственной власти с помощью КПЭ и BI, а также показывается его связь с PDCA-циклом. Продемонстрированы дополнительные возможности работы с OLAP-кубами в рамках государственного управления.

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

Маничев С.В.

Владимир Гаков

системный администратор январь-февраль 2017

Закон есть закон

Как будет развиваться ИТ-право в ближайшем будущем?

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

В нашей стране до определенного момента вопрос обеспечения информационного права и безопасности особо остро не стоял, по крайней мере законодательная и исполнительная власть не спешила с принятием мер регулятивного характера в данной сфере правоотношений. Но в последние пять лет ситуация кардинальным образом изменилась. В 2016 году мы стали свидетелями постоянных споров и дискуссий в отношении ИТ-права, вызванных принятыми или разрабатываемыми депутатами законами. Немало споров и обсуждений касательно нарушений прав и свобод человека и гражданина вызвал, например, пресловутый законодательный акт с поэтичным названием «пакет Яровой», который требует поэтапного сбора гигантского объема информации для обеспечения информационной безопасности. Эксперты ИТ-индустрии и юридического сообщества никак не могут прийти к единому мнению по поводу нововведений, предлагаемых «пакетом Яровой», и того, как они отразятся на жизни граждан – нас с вами. Действительно, сегодня самым молодым, перспективным и активно развивающимся видом правоотношений можно с уверенностью назвать информационное право в сфере ИТ. Формирование данного юридического института происходит на наших глазах, неуловимо и стремительно, подобно скорости устройств с поддержкой технологии LTE. Итак, что же такое информационное право? По сути, это комплексная отрасль права, представленная совокупностью социальных норм и отношений, возникающих в информационной сфере – сфере производства, преобразования и потребления информации. Информационное право своими корнями уходит в основополагающие и как бы образующие это право информационно-правовые нормы, закрепляющие основные информационные права и свободы и отражающие отношения информатизации. В первую очередь это права на свободу поиска, получения и распространения информации, отраженные в одном из главных нормативных источников всех стран – Всеобщей декларации прав человека, провозглашенной Генеральной Ассамблеей Организации Объединенных Наций 10 декабря 1948 года.

С развитием ИТ-отрасли для российской правовой системы стало ясно, что традиционные юридические методы не учитывают особенностей поведения субъектов и правовые свойства объектов ИТ-отношений, потому, учитывая быстрорастущие темпы информатизации общества, не всегда являются приемлемыми для решения проблемы правового регулирования отношений в информационной сфере. С проблемой правового регулирования информационного права столкнулись многие государства, в том числе и наша страна. Государственные органы действительно не сразу начали реагировать на изменения в области информатизации общества, несмотря на то что процент активных пользователей сети Интернет неуклонно растет в геометрической прогрессии. ИТ-право касается почти всех аспектов современного общества и будет еще долго играть главенствующую роль. Любая сфера жизнедеятельности человека теперь неразрывно связана с применением информационных технологий: от онлайн-покупки товаров до подачи заявки на запись ребенка в детское учреждение. В принципе в российском законодательстве нет недостатка в правовых нормах, но при этом достаточно большая часть информационных правоотношений не до конца проработана и не закреплена на государственном уровне. От опасений и недоверия к информационно-правовому институту общества, вызванных неточными и неполными положениями закона и отсутствием его кодификации, органы власти перешли к активному обсуждению и принятию пусть не совершенных, но все-таки решений данного вопроса. На Западе, например, в силу более раннего развития информатизации общества попытки интегрировать сеть Интернет в правовые механизмы предпринимались и до того, как такая проблема встала перед нашими законодателями. Сегодня можно констатировать, что и наши государственные органы все-таки стали обращать более пристальное внимание на информационное право. Как уже было сказано выше, принятие резонансных ИТ-законов вызывает бурную дискуссию в обществе. Так, например, ввиду возрастающей популярности криптовалют государственными органами

январь-февраль 2017 системный администратор

Закон есть закон

Этот цикл статей поможет лучше узнать законодательные нормы в области информационного права

были оглашены планы по разработке в скором будущем пакета мер регулятивного характера, призванных обеспечить безопасное применение электронных взаиморасчетов. В Государственной думе РФ уже давно хотели издать пакет мер, направленных на регулирование в сфере информационной безопасности, но до реальных инициатив дело дошло только в последнее время. Например, можно вспомнить о разработке единой законодательной концепции, которая может позволить России стать первой страной в мире, принявшей закон о той же самой криптовалюте. В других странах единой правовой системы по данному вопросу, как ни странно, не существует. Есть некоторые приказы и рекомендации, но не более того. Для России первенство в данном вопросе – весьма положительный момент, учитывая отсутствие государственного контроля над этим институтом информационного права в мире. В том, что современные ИТ-отношения требуют соответствующего правового регулирования, у государства уже не осталось никаких сомнений. Юридическое признание и поддержка развития информационных технологий в России, как и во всем мире, очень важны и должны быть закреплены полноценным законодательным актом, а не только приказами, рекомендациями и распоряжениями органов Правительства РФ. Государственные органы подтолкнула к подобным рассуждениям объективная реальность. Информатизация общества обладает колоссальными масштабами и постепенно размывает границы между государствами. Каждый день мировая сеть принимает десятки тысяч новых пользователей. Следовательно, сегодня задача государственных органов – создать оптимальные правовые условия для развития информационного права в России. В то же время новые законы никоим образом не должны тормозить экономический и социальный сегменты правоотношений. В противном случае это может привести к негативным последствиям для экономического положения нашей страны, ее политического статуса, к оттоку капитала и значительному отставанию от мировой правовой системы. Есть надежда, что новые законы будут исключать риски использования информа-

системный администратор январь-февраль 2017

ционных технологий для легализации преступных доходов и финансирования террористической деятельности. В Госдуме рассматривается множество возможных форм законодательного обеспечения в сфере информационной безопасности. Первый вариант – внесение отдельных изменений в действующее законодательство. Дополнительной доработки при этом потребуют законы и кодексы, уже действующие на территории нашей страны. Второй рассматриваемый вариант – разработка и принятие специального закона, в котором должны будут отражены законодательное определение многих аспектов информационного права, его основные признаки, субъекты отношений, принципы регулирования, меры противодействия использованию сети Интернет в преступных целях. В любом случае активизация усилий государственных органов, безусловно, повлияет на модель нормативного регулирования ИТ-правоотношений, что в свою очередь вызывает немалый интерес со стороны граждан. Для того чтобы наши читатели могли лучше понимать тонкости информационного права, журнал «Системный администратор» начинает цикл юридических статей юриста, постоянного ведущего рубрики «Спроси юриста» на сайте samag.ru Владимира Столярова. Что будет обсуждаться? Например, как соотносится деятельность разного рода интернет-СМИ с правовым регулированием в данной области и многочисленными изменениями в российском законодательстве? Как возможные изменения повлияют на понятие «свобода слова» в сети и на блогеров? Мы постараемся также затронуть как можно больше информационно-правовых тем, которые интересны широкому кругу читателей. Расскажем о юридических аспектах трудовых отношений в сфере информационных технологий и безопасности. Для этого проанализируем виды трудовых договоров и выясним все особенности рабочих контрактов деятельности на удаленном доступе. Надеемся, что этот цикл статей поможет читателям лучше узнать законодательные нормы в области информационного права. EOF

Закон есть закон Визитка

ВЛАДИМИР СТОЛЯРОВ, юрисконсульт ИД «Положевец и партнеры», law@samag.ru

Реальное удобство фриланса

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

Люди, им занимающиеся, называются фрилансеры. Данный институт удаленной организации труда сам по себе не новый, но свое широкое распространение получил только с развитием информационных технологий. В качестве примера развитости фриланса в мире можно привести статистику по Соединенным Штатам Америки: там удаленным способом работают 5,8% населения, практически 17 миллионов человек. Причем их доходы почти в два раза превышают оклады не занятых во фрилансе людей: 50 тыс. долларов в год против 30 тыс. долларов. В конце 1990-х – начале 2000-х дистанционные рабочие места в США и ЕС занимали примерно 30 млн человек. Сегодня, по разным оценкам, количество специалистов, сделавших свой дом работой, достигает примерно 55-60 млн человек. Лидерами в развитии технологий и удаленных офисов являются США, Канада, Финляндия, Дания и Швеция. В Финляндии количество людей, находящихся на дистанционных рабочих местах, составляет примерно треть от всего работающего населения. Следует отметить, что на Западе в системе фриланса трудятся только уже состоявшиеся профессионалы, действительно лучшие специалисты в своих областях. В России же часто совсем наоборот: телеработа может стать стартом к большим доходам и славе. В возрасте 18-22 лет доля работающего населения составляет 7%, фрилансеров – 20%. В возрасте 23-26 лет доля работающих – 11%, доля фрилансеров – 20%. По данным официальной статистики, в нашей стране «свободных художников» всего 200 тыс., что составляет 0,3% от всех работающих россиян. Однако многие эксперты считают, что в действительности их в несколько раз больше, просто большинство отечественных фрилансеров предпочитают не распространяться о своей деятельности, опасаясь претензий налоговых органов. Итак, для того чтобы иметь более полное представление о юридических основаниях такого вида работ, нужно разобраться во всех аспектах оформления необходимых документов. Чтобы избежать трудностей, выбрав удаленный вид трудовой деятельности, рассмотрим природу таких договоров.

Фриланс в России Работодатели фрилансеров довольно часто находятся на другом конце страны, а потому множество работников раздумывают над тем, как обезопасить себя от возможной невыплаты вознаграждения за свой труд. Для того чтобы быть более спокойным за свои доходы, необходимо заключить трудовой или гражданско-правовой договор. Заключение трудового договора подразумевает запись в трудовую книжку, неотъемлемое право работника на отпуск и больничный и все остальные гарантии, установленные трудовым законодательством Российской Федерации. Такой вариант подходит, если работодатель у фрилансера всего один, но если заказчиков много и они время от времени меняются, то лучше заключить договор подряда или оказания услуг. Договор подряда заключается на какой-то конкретный проект – скажем, на создание веб-сайта. Договор возмездного оказания услуг обычно применяется в случаях, если услуги оказываются в течение какого-то периода времени (например, продвижение сайтов). Важно заметить, что при сотрудничестве по гражданско-правовым договорам трудовая книжка на работника не ведется, больничные и ежегодные отпуска не предоставляются и не оплачиваются, иные гарантии и компенсации для работника, предусмотренные трудовым законодательством, также не предусматриваются. Но во многом с такими договорами работать легче – заказчику не надо вести кадровое делопроизводство (и, соответственно, платить зарплату работнику кадровой службы), а достаточно лишь раз в месяц подписывать акты. Акты можно не отправлять ежемесячно по почте, а передавать по факсу или по электронной почте, и только время от времени направлять заказчику оригиналы – их может потребовать Межрайонная инспекция ФНС для проверки налоговой отчетности. Да и расторгается такой договор намного проще – на условиях, прописанных в самом договоре, поэтому никаких дополнительных поводов и причин для расставания искать не надо. Есть еще один немаловажный момент, который следует уяснить: в случае если заказчикам предпочтительнее

январь-февраль 2017 системный администратор

Закон есть закон

Составить Трудовой договор вы запросто сможете сами, скачав шаблон на нашем сайте samag.ru

работать с юридическими лицами из-за существенной разницы в налогообложении (скажем, только взносов в различные фонды работодатель обязан уплатить до 34% от зарплаты работника), то можно зарегистрироваться и в качестве индивидуального предпринимателя, уплачивая всего 6% с дохода вместо 13%, но плюс примерно 10 тыс. рублей в год взносов в Пенсионный фонд России. Если заказчик (работодатель) и фрилансер работают не через биржи фриланса (специализированные сайты для поиска удаленной работы), также желательно предварительно оформить трудовой договор. В том случае, если условия выполнения работ не будут оговорены заранее, между фрилансером и заказчиком (работодателем) могут возникнуть разногласия, взаимные претензии – вплоть до невыполнения обязательств любой из сторон. Поэтому лучше зафиксировать все важные моменты в письменной форме – в Трудовом договоре. Как правило, законопослушного заказчика (ни организацию, ни частное лицо) не смущает заключение договора между ним и фрилансером. Правильно заключенный договор поможет организовать работу, прояснить вопросы оплаты и послужит гарантией и для заказчика (работодателя), и для фрилансера. Итак, для оформления отношений между заказчиком и фрилансером необходимо заключить Временный трудовой договор, регулирующий все производственные обязанности и права. Договор подписывается двумя сторонами – Работодателем и Работником. Экземпляры договора пересылаются в электронном виде, распечатываются и подписываются. Часто какой-либо из сторон недостаточно сканированной версии договора, в этом случае можно воспользоваться услугами почты.

Новые положения Теперь же давайте рассмотрим недавние изменения и поправки в Трудовой кодекс Российской Федерации и как они повлияли на юридическое оформление удаленного вида работ.

системный администратор январь-февраль 2017

Благодаря новой главе 49.1 (ТКРФ) теперь фрилансеры получат те же права и гарантии, что и штатные работники, занятые в офисе. В принципе логика всей гл. 49.1 Трудового кодекса соответствует логике гл. 49 ТК РФ «О надомных работах», но сформулирована с использованием современной терминологии. То есть гл. 49.1 позволяет перенести сложившийся опыт взаимоотношений с надомными работниками в современные условия. А значит, фрилансеры, в которых действительно будут заинтересованы те или иные заказчики, получают те же права и гарантии, что и штатные работники, находящиеся на стационарных местах на территории работодателя. Дистанционные работники – лица, заключившие Трудовой договор о дистанционной работе (ч. 2 ст. 312.1 ТК РФ). С момента заключения (подписания) такого договора с работодателем: >> работник считается дистанционным работником; >> на него распространяется действие трудового законодательства и иных актов, содержащих нормы трудового права, правда, с учетом особенностей, установленных гл. 49.1 (ч. 3 ст. 312.1 ТК РФ).

Трудовой договор с дистанционным работником Новеллой является возможность заключить Трудовой договор дистанционно, не требуя от его сторон личной встречи. Поэтому новая глава Трудового кодекса подробно разъясняет порядок обмена документами, порядок подписи и т.д. В качестве места заключения Трудового договора указывается место нахождения работодателя (ч. 1 ст. 312.2 ТК РФ).

Документы, необходимые для заключения Трудового договора Перечень документов, представляемых работодателю при трудоустройстве дистанционным работником, не отличается от общеустановленного. Различие только в форме представления документов. Все документы дистанционный работник может представить работодателю в электронном виде – отсканировать оригинал и передать по электронной почте.

Закон есть закон В соответствии со ст. 65 ТК РФ такими документами являются: >> паспорт; >> страховое свидетельство государственного пенсионного страхования; >> документы об образовании (где они требуются) и др. Работодатель вправе потребовать от работника прислать нотариально заверенные копии указанных документов заказным письмом с уведомлением (ч. 3 ст. 312.2 ТК РФ).

Закон регламентирует, что записи в трудовую книжку могут не вноситься по взаимной договоренности сторон При этом страховое свидетельство государственного пенсионного страхования работник может получить в Пенсионном фонде России самостоятельно, если он заключает Трудовой договор впервые (ч. 4 ст. 312.2 ТК РФ).

Оформление документов При оформлении трудовых отношений сохраняются требования к оформлению надлежащим образом основных документов. Подписанный на бумажном носителе со стороны работодателя трудовой контракт о дистанционном труде направляется по почте заказным письмом с уведомлением сотруднику, притом не позднее трех календарных дней с момента заключения данного договора. В случае же, когда фирме при оформлении соглашения требуются документы не в электронном виде, фрилансер обязан направить по почте заказным письмом с уведомлением нотариально заверенную копию на бумажном носителе. Это продиктовано нормами о приеме на работу, в частности ст. 65 Трудового кодекса. Проводя параллели дистанционной работы с надомной, стоит отметить, что труд вне офиса все-таки подразумевает использование трудовой книжки. Однако новый Закон регламентирует, что записи в нее могут не вноситься по взаимной договоренности сторон. Более того, если контракт о дистанционной работе заключается с лицом, впервые поступающим на службу, то трудовая книжка такому работнику может не оформляться вовсе. В этих случаях подтверждением занятости (с указанием даты начала, должности и структурного подразделения) и стажа может выступать сам контракт. В этой связи характер Трудового договора о дистанционной работе может быть срочным, что позволит указать точные даты окончания дистанционной деятельности специалиста. Когда одна из сторон трудовых отношений выражает желание оформить надлежащим образом записи в трудовой книжке (или создать новую книжку), то применяется ранее указанный сценарий направления документов по почте заказным письмом с уведомлением.

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

Электронная подпись Неотъемлемыми атрибутами дистанционного труда являются современные виды телекоммуникации (электронная почта, веб-интерфейсы, программные продукты для взаимодействия онлайн). В отношениях с фрилансерами предлагается к использованию так называемая усиленная квалифицированная электронная подпись. В тех ситуациях, когда необходимо прибегнуть к цифровому автографу для подтверждения принятия условий того или иного официального документа, использование усиленной квалифицированной электронной цифровой подписи предусмотрено как со стороны сотрудника, так и со стороны работодателя. Именно поэтому использование интернета является одним из основных условий применения удаленного труда (ст. 312.1 ТК РФ). Поскольку дистанционный работник может находиться на большом удалении от работодателя, между ними осуществляется обмен документами в электронной форме. При этом каждая из сторон обязана направлять другой стороне подтверждение получения электронного документа в сроки, установленные договором о дистанционной работе (ст. 312.1 ТК РФ). Документы, которыми обмениваются работник и работодатель, должны быть подписаны электронной подписью. Статьей 312.1 ТК РФ установлено, что для подписания электронных документов должна использоваться усиленная квалифицированная подпись. Это относится и к лицам, которые только поступают на дистанционную работу. Информация в электронном виде, подписанная квалифицированной электронной подписью, признается электронным документом, который равнозначен документу на бумажном носителе, подписанному собственноручной подписью и содержащему печать. Следовательно, при наличии квалифицированной электронной подписи электронный документ может заменить документ на бумажном носителе. Одной электронной подписью могут быть подписаны несколько связанных между собой электронных документов (пакет электронных документов). При этом каждый из электронных документов, входящих в этот пакет, считается подписанным. Созданием и выдачей сертификатов ключей электронных подписей и ключей проверки электронных подписей занимается удостоверяющий центр.

январь-февраль 2017 системный администратор

Закон есть закон Дистанционный работник практически всегда имеет право использовать электронные документы во взаимодействии с фирмой, исключая те случаи, когда компании требуются оригиналы бумаг. Например, необходимость предоставления обязательного страхового обеспечения по социальному страхованию на случай временной нетрудоспособности или в связи с материнством. Значит, фрилансеру необходимо будет выслать оригинал документа (больничный лист). Законом предписано высылать бумаги по почте заказным письмом с уведомлением. Вопрос оплаты таких расходов также решается по договоренности между работником и организацией. До подписания Трудового договора работодатель обязан ознакомить работника под роспись с правилами внутреннего трудового распорядка, иными локальными нормативными актами, непосредственно связанными с трудовой деятельностью работника, коллективным договором (ч. 5 ст. 312.2 ТК РФ). Если это дистанционный работник, ознакомление производится путем обмена электронными документами с использованием усиленной квалифицированной электронной подписи дистанционного работника. Каждая из сторон такого обмена обязана направлять в форме электронного документа подтверждение получения электронного документа от другой стороны в срок, определенный Трудовым договором о дистанционной работе (ч. 4 ст. 312.1 ТК РФ). Также путем обмена электронными документами между работодателем и дистанционным работником может быть заключено соглашение об изменении определенных сторонами условий Трудового договора о дистанционной работе. Путем обмена электронными документами дистанционный работник может быть ознакомлен в письменной форме, в том числе под роспись: >> с принимаемыми работодателем локальными нормативными актами, непосредственно связанными с его трудовой деятельностью; >> приказами (распоряжениями) работодателя; >> уведомлениями, требованиями и иными документами. Если работник намеревается обратиться к работодателю с каким-либо заявлением, представить ему объяснения либо другую информацию, он может сделать это также в форме электронного документа (ч. 5 и 6 ст. 312.1 ТК РФ).

Электронный документооборот Путем обмена электронными документами работодатель может: >> заключить Трудовой договор о дистанционной работе с работником (ст. 312.2 ТК РФ); >> до подписания Трудового договора ознакомить работника с локальными нормативными актами, которые предусмотрены ст. 68 ТК РФ. Обязательными для ознакомления являются (ст. 312.2 ТК РФ): »> правила внутреннего трудового распорядка; »> коллективный договор и положение об оплате труда; »> иные локальные нормативные акты, непосредственно связанные с работой дистанционного сотрудника; >> внести изменения в Трудовой договор путем составления дополнительного соглашения (ст. 312.2 ТК РФ);

системный администратор январь-февраль 2017

>> знакомить работника с приказами (распоряжениями), уведомлениями, требованиями или иными документами. Речь идет о тех документах работодателя, с которыми работник должен быть ознакомлен в письменной форме под роспись (ст. 312.1 ТК РФ). В свою очередь работник может направлять в виде электронных документов различные заявления, объяснения, обращения к работодателю и другую информацию, которую он должен или вправе передавать ему.

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

Страховое свидетельство государственного пенсионного страхования Если работник заключает Трудовой договор впервые и не имеет страхового свидетельства государственного пенсионного страхования, то работодателю придется зарегистрировать его (ч. 4 ст. 65 ТК РФ). Для этого в течение двух недель с момента трудоустройства работодатель должен подать в Пенсионный фонд Российской Федерации: >> заявление в произвольной форме от работника о выдаче свидетельства; >> анкету застрахованного лица по форме АДВ-1, утвержденной Постановлением ПФР от 31.07.2006 №192п; >> опись передаваемых документов по форме АДВ-6-1. На основании указанных документов Пенсионный фонд Российской Федерации открывает физическому лицу индивидуальный лицевой счет, оформляет страховое свидетельство и передает его через работодателя работнику. В отношении дистанционных работников, которые заключили Трудовой договор путем обмена электронными документами, законодатели сделали исключение. Если у дистанционного работника нет страхового свидетельства государственного пенсионного страхования, то ему придется получать свидетельство в Пенсионном фонде Российской Федерации самостоятельно (ст. 312.2 ТК РФ). Соответствующая поправка внесена в абз. 1 п. 2 ст. 7 Закона №27-ФЗ.

Трудовая книжка Трудовая книжка является основным документом о трудовой деятельности и трудовом стаже работника (ст. 66 ТК РФ).

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

При заключении Трудового договора работодатель определяет, какое оборудование, программнотехнические средства, средства защиты информации и иные средства необходимы для дистанционного работника В отношении дистанционных работников предусмотрено исключение. По соглашению между работником и работодателем сведения о дистанционной работе могут не вноситься в трудовую книжку (ст. 312.2 ТК РФ). Следовательно, передавать работодателю трудовую книжку дистанционному работнику не придется. Таким образом, если никаких записей в трудовую книжку о работе дистанционного работника сделано не было, то основным документом о трудовой деятельности дистанционного работника, подтверждающим его трудовой стаж, для дистанционного работника будет являться Трудовой договор о дистанционной работе. Что делать, если работник хочет, чтобы запись о его дистанционной работе была внесена в трудовую книжку? В этом случае он должен передать трудовую книжку работодателю лично или направить ее по почте заказным письмом с уведомлением (ст. 312.2 ТК РФ). Запись о приеме на работу будет стандартной – например, «Принят на должность ИТ-специалиста, программиста». Указывать на дистанционный характер работы не нужно. Трудовую книжку с записью работодателя о дистанционной работе работник получит по почте заказным письмом с уведомлением.

Обязанности работодателя Обеспечить условия труда, предусмотренные трудовым законодательством. В ст. 15 Трудового кодекса РФ дано определение трудовых отношений, в котором, в частности, говорится, что работодатель обязан обеспечивать работнику условия труда, предусмотренные трудовым законодательством и иными нормативными правовыми актами, содержащими нормы трудового права, коллективным договором, соглашениями, локальными нормативными актами, Трудовым договором. При дистанционной работе работодатель за обеспечение таких условий не отвечает (ч. 2 ст. 312.3 ТК РФ). Зона его ответственности определена в ч. 2 ст. 312.3 ТК РФ. В ней установлено, что работодатель в целях

обеспечения безопасных условий и охраны труда дистанционных работников исполняет обязанности, предусмотренные абз. 16, 19 и 20 ч. 2 ст. 212 ТК РФ, а именно: >> ведет расследование и учет несчастных случаев на производстве и профессиональных заболеваний; >> выполняет предписания должностных лиц федерального органа исполнительной власти, уполномоченного на осуществление федерального государственного надзора за соблюдением трудового законодательства, в законодательно установленные сроки; >> обеспечивает обязательное социальное страхование работников от несчастных случаев на производстве и профзаболеваний. Другие обязанности работодателя по обеспечению безопасных условий и охраны труда, перечисленные, в частности, в ст. 212 ТК РФ, на дистанционных работников не распространяются, если это не предусмотрено Трудовым договором о дистанционной работе.

Оборудование и программно-технические средства При заключении Трудового договора работодатель определяет, какое оборудование, программно-технические средства, средства защиты информации и иные средства необходимы для дистанционного работника. Обязанность использовать указанные средства при выполнении трудовых функций должна быть включена в Трудовой договор с дистанционным работником (ст. 312.2 ТК РФ). При этом работодатель решает, либо он предоставит такое оборудование и средства дистанционному работнику, либо работнику придется использовать свое оборудование и средства. В первом случае в Трудовом договоре необходимо установить порядок и сроки передачи указанных средств дистанционному работнику (ст. 312.3 ТК РФ). Во втором случае в Трудовом договоре следует указать, какое собственное оборудование, программно-технические средства, средства защиты информации и иные средства дистанционный работник может применять для выполнения трудовых обязанностей (ст. 312.2 ТК РФ). За использование в служебных целях оборудования и средств работодатель обязан выплачивать дистанционному работнику компенсацию, а также возмещать расходы, связанные с таким использованием (ст. 188 ТК РФ). Если работник использует в служебных целях, например, автомобиль, которым он управляет по доверенности, то с суммы компенсации ему придется заплатить налог на доход физических лиц, поскольку льгота по НДФЛ на основании п. 3 ст. 217 НК РФ предоставляется только при возмещении расходов работника, связанных с использованием личного имущества (Письмо Минфина России от 08.08.2012 №03-04-06/9-228). Дистанционный работник может использовать оборудование и средства как принадлежащие ему на праве собственности, так и арендованные (это установлено новой ст. 312.3 ТК РФ). Следовательно, вне зависимости от того, кому принадлежит имущество, используемое дистанционным работником, платить НДФЛ с этой суммы ему не придется. Размер, порядок и сроки выплаты компенсации за использование дистанционным работником оборудования

январь-февраль 2017 системный администратор

Закон есть закон и средств, а также порядок возмещения других расходов, связанных с дистанционной работой, устанавливаются Трудовым договором (ст. 312.3 ТК РФ).

Охрана труда В связи с тем, что рабочее место фрилансера находится вне офиса, то на компанию не распространяется, а значит, не возлагается большинство требований по обеспечению безопасных условий и охране труда. В отношении дистанционных работников на работодателя возлагаются только три обязанности по обеспечению безопасных условий и охраны труда, которые установлены абз. 16, 19 и 20 ч. 2 ст. 212 ТК РФ (ст. 312.3 ТК РФ): >> расследование и учет несчастных случаев на производстве и профессиональных заболеваний в установленном порядке; >> выполнение предписаний должностных лиц Федеральной инспекции труда; >> уплата страховых взносов на обязательное страхование от несчастных случаев на производстве и профессиональных заболеваний. Кроме того, работодатель должен ознакомить дистанционного работника с требованиями охраны труда при работе с оборудованием и средствами, которые предоставлены работодателем или рекомендованы к применению. Другие обязанности работодателя по обеспечению безопасных условий труда и охраны труда на дистанционных работников не распространяются (ст. 312.3 ТК РФ), но только в случае, если иное не установлено Трудовым договором.

Режим рабочего времени и отдыха. Отпуска Ввиду того что рабочее место фрилансера находится вне территории компании, правомерным будет сделать вывод, что общие требования Правил внутреннего трудового распорядка не распространяются на такого специалиста. Исходя из этого удаленный работник сам вправе определять для себя время труда и отдыха, перерывы и выходные дни. Фактически характер таких деловых отношений приближен к работе со специалистами, с которыми заключен договор возмездного оказания услуг, когда оплачивается результат работы, а не время, затраченное на ее исполнение. Статьей 312.4 Трудового кодекса РФ установлено, что режим рабочего времени и отдыха дистанционный работник определяет самостоятельно, если иное не установлено Трудовым договором. Написанное означает, что режим работы дистанционного работника определяется при заключении Трудового договора с работником. Работодатель может предоставить дистанционному работнику свободный график работы или обязать его работать в определенном режиме. В первом случае у работника есть право выполнять свои трудовые обязанности в удобное для него время, в том числе вечером, ночью, в субботу или воскресенье, в праздничные дни. Такой режим работы подойдет людям творческих профессий – IT-специалистам, журналистам, дизайнерам, переводчикам и т.д. В этом случае работодателю не придется вести учет рабочего времени, отработанного дистанционным работником, а значит, не будет необходимости дополнительно оплачивать сверхурочную работу, работу в выходные и нерабочие праздничные дни, работу в ночное время.

системный администратор январь-февраль 2017

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

У дистанционного работника есть право на ежегодные оплачиваемые работодателем основной и дополнительный отпуска Здесь следует обратить внимание на то, что в Трудовом договоре должны быть установлены порядок и сроки представления дистанционным работником отчетов о выполненной работе (ст. 312.3 ТК РФ). В Трудовом договоре о дистанционной работе указывается, что на работника распространяются: >> все условия коллективного договора; >> локального нормативного акта; >> правила внутреннего трудового распорядка (в части графика отпусков).

Дистанционный работник и правила внутреннего трудового распорядка В Трудовом договоре с дистанционным работником не может быть условия о подчинении последнего правилам внутреннего трудового распорядка, поскольку режим рабочего времени и времени отдыха такой работник устанавливает по своему усмотрению (ч. 1 ст. 312.4 ТК РФ). Но это не означает, что работодатель не должен решать, например, вопрос, может ли работник уехать в отпуск (в деревню, где нет интернета, или за границу, где дорогой роуминг) именно сейчас. Поэтому в Трудовой договор он может внести одну из формулировок: >> «Работник подчиняется правилам внутреннего трудового распорядка в части, не противоречащей заключенному Трудовому договору»; >> «Работник подчиняется правилам внутреннего трудового распорядка в части графика отпусков».

Гарантии и компенсации, которые полагаются дистанционным работникам Дистанционный работник самостоятельно организует процесс выполнения работы и имеет право на те гарантии и компенсации, которые установлены ТК РФ (ст. 312.1 ТК РФ). В частности, у дистанционного работника есть право на ежегодные оплачиваемые основной и дополнительный отпуска. Порядок предоставления отпуска дистанционному работнику определяется Трудовым договором с ним с учетом положений ТК РФ (ст. 312.4 ТК РФ). Следовательно, работодатель должен регулярно отправлять дистанционного

Закон есть закон работника в отпуск, поскольку ст. 124 ТК РФ запрещается отказ в предоставлении ежегодного оплачиваемого отпуска в течение двух лет подряд. Если дистанционный работник заболел, то за период временной нетрудоспособности ему полагается пособие (ст. 183 ТК РФ). Поскольку выплата пособия по временной нетрудоспособности возможна только на основании листка нетрудоспособности, дистанционный работник должен направить работодателю оригинал больничного по почте заказным письмом с уведомлением (ст. 312.1 ТК РФ). Таким же образом дистанционный работник должен направить документы, если он претендует на получение иных социальных пособий.

Увольнение дистанционного работника Основания, по которым работодатель может расторгнуть Трудовой договор с дистанционным работником, прописываются в Трудовом договоре (ч. 1 ст. 312.5 ТК РФ). Такими основаниями могут быть: >> соглашение сторон (ст. 78 ТК РФ); >> истечение срока Трудового договора (ст. 79 ТК РФ), кроме случаев, когда трудовые отношения фактически продолжаются и ни одна из сторон не потребовала их прекращения; >> инициатива работника (ст. 80 ТК РФ); >> инициатива работодателя (ст. ст. 71 и 81 ТК РФ); >> перевод работника по его просьбе или с его согласия на работу к другому работодателю или переход на выборную работу (должность); >> отказ работника от продолжения работы в связи со сменой собственника имущества организации, с изменением подведомственности (подчиненности) организации либо ее реорганизацией (ст. 75 ТК РФ); >> отказ работника от продолжения работы в связи с изменением определенных сторонами условий Трудового договора (ч. 4 ст. 74 ТК РФ); >> обстоятельства, не зависящие от воли сторон (ст. 83 ТК РФ); >> нарушение правил заключения Трудового договора, если это исключает возможность продолжения работы (ст. 84 ТК РФ). Приказ о прекращении Трудового договора о дистанционной работе работодатель направляет дистанционному работнику в форме электронного документа, а его копию на бумажном носителе – в день прекращения Трудового договора по почте заказным письмом с уведомлением (ч. 2 ст. 312.5 ТК РФ).

Страховые взносы и НДФЛ с выплат в пользу работника – гражданина РФ Если дистанционный работник является гражданином РФ и выполняет работу по Трудовому договору, он признается застрахованным лицом: >> на случай временной нетрудоспособности и в связи с материнством (п. 1 ст. 2 Закона №255-ФЗ); >> на случай травматизма (п. 1 ст. 5 Федерального закона от 24.07.1998 №125-ФЗ); >> по обязательному пенсионному страхованию (п. 1 ст. 7 Федерального закона от 15.12.2001 №167 ФЗ);

>> по обязательному медицинскому страхованию (ч. 1 ст. 10 Федерального закона от 29.11.2010 №326-ФЗ). С выплат в пользу такого работника работодатель должен начислять страховые взносы в ПФР, ФФОМС и ФСС РФ (по двум видам страхования – по временной нетрудоспособности и в связи с материнством и от несчастных случаев на производстве и профессиональных заболеваний). Страховые взносы он будет уплачивать по тарифу: >> в ПФР – в зависимости от категории плательщика страховых взносов и года рождения дистанционного работника; >> в ФСС РФ на случай временной нетрудоспособности и в связи с материнством – в зависимости от категории плательщика страховых взносов; >> в ФСС РФ на случай травматизма – по тарифу, установленному для организации; >> в ФФОМС – в зависимости от категории плательщика страховых взносов. Страховые взносы в ФСС РФ и ПФР не нужно начислять на суммы компенсации расходов дистанционного работника по оплате счетов за интернет, телефон, использование личного оборудования, программно-технических средств, средств защиты информации и иных средств, рекомендованных работодателем, в служебных целях, если в Трудовом договоре: >> предусмотрена такая компенсация; >> указан ее конкретный размер. Это следует из пп. «и» п. 2 ч. 1 ст. 9 Федерального закона от 24.07.2009 №212-ФЗ и пп. 2 п. 1 ст. 20.2 Федерального закона от 24.07.1998 №125-ФЗ. Обязательное условие – указанные расходы должны быть экономически обоснованны и документально подтверждены (Письма Минфина России от 11.04.2013 №03-0406/11996, ФСС РФ от 17.11.2011 №14-03-11/08-13985, ПФР от 29.09.2010 №30-21/10260). Размер возмещения таких расходов должен быть определен соглашением сторон Трудового договора, выраженным в письменной форме, и иметь экономическое обоснование. Компенсация расходов на оплату услуг связи с использованием сотовых (мобильных) телефонов в производственных целях также не облагается НДФЛ (Письмо Минфина России от 13.10.2010 №03-03-06/2/178). Документальным подтверждением таких затрат будут счета оператора связи, их детализация с указанием номеров абонентов (Письмо УФНС России по г. Москве от 21.01.2008 №28-11/4115).

Составить Трудовой договор вы запросто сможете сами, скачав шаблон на нашем сайте samag.ru, который представлен в качестве образца. При необходимости в него можно легко внести недостающие пункты, потому что, как правило, заказы имеют свои особенности, которые лучше всего дополнительно отражать в каждом конкретном договоре. Надеемся, информация, которую мы предоставили, поможет вам в будущем избежать ошибок при заключении договоров как со стороны работника, так и со стороны работодателя. Новые обзоры Законодательства вы найдете в следующих номерах журнала «Системный администратор». EOF

январь-февраль 2017 системный администратор

Прокачайте вашу АТС Сократите расходы, Увеличьте прибыль

3CX Phone System Переходите на 3CX - программную IP АТС на открытых стандартах, предлагающую простое управление и Объединенные коммуникации по доступной цене. • Программное решение - простое внедрение и сопровождение • Недорогое приобретение и расширение • Виртуализация Hyper-V или VMware • Сократите расходы - используйте SIP транки • Увеличьте мобильность с клиентами для смартфонов • Интегрированные видеоконференции WebRTC

WWW.3CX.RU

+7 495 204 29 37

Администрирование

хранение данных

Визитка АЛЕКСЕЙ БЕРЕЖНОЙ, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, alexey.berezhnoy@tech-center.com

Особенности построения SAN на базе протокола Fibre Channel

Мы продолжаем разговор о сетях SAN протокола и стандарта Fibre Channel [1]. В этот раз речь пойдет о методах организации взаимодействия устройств в таких сетях хранения данных

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

Уровни Fibre Channel Протокол Fibre Channel условно подразделяется на пять уровней. Само понятие «уровень» берет начало от семиуровневой модели, предложенной International Organization for Standardization Open Systems Interconnection (ISO/OSI). Такое разделение позволяет сосредоточиться на разработке того или иного уровня взаимодействия, абстрагировавшись от других факторов. В таблице 1 указаны сходства и различия в организации уровней Fibre Channel и сетевой модели ISO/OSI. Приведу более подробное описание каждого уровня.

Physical and signaling layer – физический и сигнальный Все пять уровней условно можно разделить на две группы: физические и сигнальные уровни и прикладные уровни. Таблица 1. Сравнение уровней Fibre Channel и сетевой модели OSI ISO

Физические и сигнальные уровни включают три нижних уровня: FC-0, FC-1 и FC-2.

Physical interface and media: FC-0 Нижний слой FC-0 спроектирован для физических соединений систем хранения и обработки данных, включая кабели, коннекторы (разъемы), электрические параметры и другие аспекты среды передачи данных. Этот уровень создан с учетом требований максимальной гибкости, чтобы иметь возможность реализовать среду передачи данных различными способами. Взаимодействие между двумя узлами может осуществляться даже в том случае, если они спроектированы с использованием различных технологий. Например, в одной и той же инфраструктуре используются оптоволокно и медные кабели. Разумеется, для этого потребуется оборудование, позволяющее сочетать оба варианта среды передачи. Подобная гибкость позволяет использовать Fibre Channel как для новейшего, так и для несколько устаревшего оборудования, а также избегать необходимости глобальных изменений в ИТ-инфраструктуре. В оборудовании Fibre Channel (одномодовое оптоволокно) используется лазерный источник светового сигнала, который может нанести вред здоровью. В FC-0 применяется система open fiber control (OFC), которая использует безопасное соединение point-to-point и в качестве источника света – полупроводниковый лазерный диод. Если оптоволоконное соединение разрывается, порт посылает серию импульсов, пока физическое соединение снова не будет восстановлено.

Name of level

LAN (OSI ISO)

SAN (Fibre Channel)

Transmission protocol: FC-1

Level 5-7

Application

CIFS (SMB), NFS, iSCSI, FTP etc

SCSI-command, FCIP etc

Level 4

Transport

TCP, UDP

FC-4

Level 3

Network

IP, ICMP etc

FC-3

Level 2

Data link

Ethernet etc

FC-1, FC-2

Level 1

Physical

Hardware, cables

FC-0 (Hardware, cables)

Протокол передачи данных FC-1 предоставляет адаптированный метод 8B/10B кодирования для увязывания максимальной длины кода, выполнения DC-балансировки (DCbalance) и выравнивания слов. Все данные по методу 8B/10B кодируются с помощью 10 бит. 10-битовые символы, которые не используются в контексте данных, применяются для отделения фреймов

январь-февраль 2017 системный администратор

хранение данных

Администрирование

Инфраструктуры на базе Fibre Channel используются долго и «уходить на покой» из мира ИТ пока не собираются

и сигналов, например сигналов о готовности порта для принятия данных. Следует также отметить особую роль, которая отводится обнаружению и исправлению ошибок на этапе передачи. Этот слой служит для преобразования цифровой информации в вид, пригодный для передачи по последовательным каналам. Данные Fibre Channel транслируются блоками по 4 байта, которые носят название «transmission words».

Framing and signaling protocol: FC-2 FC-2, третий уровень Fibre Channel Physical and Signaling interface (FC-PH), предоставляет метод транспортировки, что, в свою очередь, определяет следующие факторы: > Топологию. > Коммуникативную модель. > Классы сервисов, которые предоставляются узлам со стороны fabric. > Последовательность и обмен идентификаторами. > Сегментацию и повторную сборку. > Данные передаются четырехбайтными блоками, которые включают собственно данные и контрольные символы. Надежность соединений Fibre Channel во многом является заслугой работы уровня FC-2, на котором выполняются работы по разделению и упорядочиванию информации, а также перевод их в формат, пригодный для передачи данных по оптоволоконному и электрическому соединению. FC-2 можно обозначить как механизм передачи данных, независимый от протоколов верхнего уровня. FC-2 поддерживает различную топологию: Point-to-Point, Arbitrated Loop и Fabric. В Fibre Channel передача данных осуществляется с помощью кадров (frame). Кадр (или фрейм) является в своем роде эквивалентом IP-пакета семейства протоколов TCP/ IP. В свою очередь, несколько кадров группируются вместе и составляют последовательность, а несколько последовательностей образуют «обмен» (exchange).

системный администратор январь-февраль 2017

Все три первых слоя – FC-0, FC-1 и FC-2 – формируют Fibre Channel Physical and Signaling interface (FC-PH).

Upper layers – верхние уровни Fibre Channel Включают два оставшихся уровня: FC-3 и FC-4.

Common services: FC-3 Краткое описание: уровень базовых служб. В свое время был зарезервирован для новых функций, которые могут быть внедрены в Fibre Channel в будущем. На данном уровне обеспечиваются шифрование и сжатие данных перед отправкой. FC-3 также определяет функционал нескольких портов на одиночном узле или сетевом пространстве (описание портов приводится ниже в соответствующем разделе). В настоящий момент поддерживаются следующие функции: > Hunt groups – набор объединенных портов N_ports, которые могут быть присоединены к одиночному узлу. Этот набор получает дополнительное имя (an alias identifier), что позволяет любому фрейму быть переадресованным на любой порт данного набора. Этот процесс уменьшает задержки и повышает производительность. > Striping – применяется для расширения полосы пропускания с использованием параллельного включения N_ports для передачи информации через множество подключенных каналов. > Multicast – можно определить как одиночную передачу множеству портов. Этот метод включает возможность передачи на узлы (broadcast).

Upper-layer protocol mapping: FC-4 Самый верхний уровень FC-4, по сути, является ретранслятором для протоколов более высокого уровня. Он служит для точной передачи сетевой и транспортной информации и осуществляет передачу протоколов обоих типов через транспортный канал в конкурентном режиме. Проще говоря, несколько протоколов верхнего уровня различных типов могут передаваться по одному каналу связи в конкурентном режиме.

Администрирование Типы портов Основой построения сетей Fibre Channel является порт. Возвращаясь к сравнению FC и Ethernet, можно отметить следующее сходство: > одно устройство может иметь несколько портов; > каждый порт имеет свой собственный уникальный адрес – WWPN для FC аналогично MAC для Ethernet (об адресации WWN речь пойдет ниже в соответствующем разделе). Однако в отличие от Ethernet, где не принято различать порты согласно функционалу, в Fibre Channel существует такое разделение для более точного описания взаимодействия частей сети хранения данных. Ниже идет описание общеизвестных типов портов в Fibre Channel. Существуют также специализированные типы портов, например используемые для оборудования передачи данных, к примеру, от компании Cisco Systems.

Порты устройств > N_port: этот тип порта располагается на отдельном узле (конечном устройстве), но не подключенном по топологии Arbitrated Loop. Это конечный порт, который используется для связи с fabric switch. > NL_port: в отличие от предыдущего типа данный порт применяется исключительно в топологии Arbitrated Loop. Он используется для соединения с портом оборудования, работающего в топологии Arbitrated Loop (L_port или FL_port).

Порты коммуникационного оборудования > F_port: этот порт можно описать как «порт подключения». То есть это порт коммутатора, маршрутизатора, который соединяется с портом отдельного узла (N_port) в режиме point-to-point. > FL_port: это тип порта кольцевого соединения, используется в оборудовании Arbitrated Loop и служит для соединений с портами конечных устройств кольца (NL_port) для перевода в режим «открытого кольца» (Arbitrated Loop, подключенного к fabric switch). Рисунок 1. Адресация WWN

хранение данных > E_Port: порт расширения для подключения других коммутаторов для расширения switch fabric. > G_port: универсальный тип порта, который может использоваться либо как порт расширения (E_port), либо как порт подключения F_port. Однако данный порт нельзя использовать в схемах с Arbitrated Loop. > U_port: это еще более универсальный порт (если так можно выразиться) по сравнению с G_port, который может быть использован как E_port, F_port или FL_port. Порт, определяемый как U_port, в данный момент не подключен и не имеет назначенной роли. > L_port: своего рода универсальное название для всех портов кольцевых соединений (Arbitrated Loop).

Некоторые дополнительные типы портов > EX_Port: входит в семейство E_Port и используется для соединения с мультипротольным маршрутизатором на границе switched fabric. EX_Port отвечает стандартам протоколов E_Port. Поддерживает Fibre Channel Network Address Translation (FC-NAT), что позволяет взаимодействовать различным фабрикам без слияния. > VE_Port: виртуальный E_Port, который эмулирует E_Port Fibre Channel через Internet Protocol (FCIP) link. VE_Port поддерживает подключение point-to-point. > VEX_Port: по аналогии с EX_port, VEX_Ports является маршрутизируемым VE_Ports. VE_Ports и VEX_Ports имеют в принципе тот же функционал, что и EX_Port. > TE_port: предоставляет стандартный функционал E_port, а также служит для маршрутизации множества виртуальных SAN (VSANs). Эта способность возможна благодаря модификации стандартного фрейма Fibre Channel (VSAN tagging) на входах и выходах VSAN-оборудования. Так же известен, как Trunking E_port.

Система адресации Для определения устройств в сети используется специальный идентификатор, называемый World Wide Name (WWN). Реже можно встретить другое название – World Wide Identifier (WWID), но все это разные имена одного и того же. Примечание. Согласно правилам английского языка аббревиатура «WWN» произносится как «дабл-ю-дабл-юэн». Не стоит употреблять закрепившийся сленговый оборот «вэ-вэ-эн». Помимо того, что это некрасиво звучит, вас просто не поймут в службе поддержки многих вендоров, где сотрудников обучают произносить все названия правильно. Для обозначения каждого такого идентификатора служит восьмибайтовое число (см. рис. 1). Его значение определяется производителем оборудования. На самом деле существует целых два формата WWN, в свое время определенных IEEE [2]: > Основной или оригинальный формат, когда адреса назначаются производителям комитетом IEEE и встраиваются в устройство на этапе изготовления. Первые 2 байта шестнадцатеричные 1x:xx или 2x:xx (где x зависит от производителя), после этого следует трехбайтовый идентификатор производителя и только потом 3 байта для серийного номера, определяемого производителем, которые в принципе и создают необходимую уникальность.

январь-февраль 2017 системный администратор

хранение данных > Есть еще так называемая новая схема: под идентификатор производителя выделяется 3 байта, в котором первые четыре двоичных разряда – шестнадцатеричное 5 или 6, далее следует серийный номер от производителя размером в 36 бит. Очень часто WWN сравнивают с MAC-адресом. MAC и WWN действительно служат схожим целям – определить уникальный адрес, по которому коммутатор может слать пакеты данных. Но есть и отличия. Например, существует два типа WWN: > WWNN (World Wide Node Name) – который служит для идентификации устройства, > WWPN (World Wide Port Name) – который служит для идентификации порта. На практике обычно приходится иметь дело именно с WWPN. WWNN может понадобиться, например, при вводе лицензионного ключа для активации устройств некоторых производителей SAN-оборудования. В повседневной работе администратор чаще всего оперирует с портами устройств. Поэтому, когда речь идет о WWN, как правило, имеют в виду именно WWPN, то есть адрес порта.

Зонирование – Zoning Данный термин (Zoning) можно дословно перевести как «зонирование». Как следует из названия, данный функционал позволяет выполнять сегментацию Switched Fabric на меньшие разделы. Zoning может быть использовано для создания барьеров между различным оборудованием. Внутри одной зоны только ее члены могут осуществлять коммуникации друг с другом, остальные устройства находятся за ее пределами и трафик от них отбрасывается. Например, можно отделить трафик серверов под управлением Microsoft Windows от UNIX-like-операционных систем, потому что методика работы Windows-систем предполагает опрос всех доступных систем хранения. Поскольку не все устройства хранения могут защитить свои ресурсы от такого всеобъемлющего поиска со стороны некоторых серверов-клиентов, лучшей практикой будет защита окружения другим способом. Zoning может использоваться не только для защиты от подобной «бесцеремонности» некоторых участников обмена, но и для повышения уровня безопасности. Простое разделение участников информационного обмена согласно заранее определенным правилам является весьма эффективным средством как против предотвращения утечки информации, так и от ошибок, вызванных «человеческим фактором». Например, давно стало нормой подразделять ИТ-инфраструктуру на тестовую область и production. С современной системой хранения данных на основе коммутаторов Fibre Channel подобное разделение не составит труда.

Методы зонирования Существует два распространенных метода зонирования: > Hardware zoning > Software zoning

системный администратор январь-февраль 2017

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

Аппаратное зонирование – Hardware zoning Аппаратное зонирование базируется на физическом номере порта. Члены зоны определяются как физические порты на fabric switch. Аппаратное зонирование может применяться в следующих конфигурациях: > One-to-one (один-к-одному) > One-to-many (один-ко-многим) > Many-to-many (многие-ко-многим) В аппаратно организованной зоне оборудование FC-коммутатора выполняет проверку на наличие данных, пересылаемых между не авторизованными членами зоны. Если выявлены подобные нарушения, передача данных блокируется. В то же время устройства могут передавать данные между портами одной и той же зоны. Поэтому аппаратное зонирование предоставляет более высокий уровень безопасности. Сложность использования аппаратного зонирования состоит в том, что устройства могут быть подключены только через специфичные порты, и вся конфигурация зон становится непригодной, если устройство по какой-то причине подключено в другой порт. В случае когда имеет место подобное непостоянство, программное зонирование может значительно облегчить процесс конфигурирования. Преимуществом аппаратного зонирования является то, что это может использоваться в составе основы фильтрации при маршрутизации. (О фильтрации при маршрутизации будет сказано ниже.) В большинстве случаев этот тип зонирования оказывает небольшое влияние на производительность в процессе маршрутизации. При желании в процессе проектирования можно заранее включать некоторые неиспользуемые порты в ту или иную аппаратную зону. С одной стороны, это упрощает процесс использования, с другой – может создавать проблемы, особенно при недостаточно подробной документации. Поэтому, если отдельный порт оказывается недоступен, вероятная причина может состоять в том, что этот порт просто-напросто включен в другую зону.

Программное зонирование – Software zoning Программное зонирование применяется в коммутируемых SAN посредством использования операционных систем SAN-коммутаторов. Программное зонирование почти всегда применяется в виде комбинации сервера имен и протокола Fibre Channel. Когда порт отправляет запрос серверу имен, сервер имен передает в соответствующую зону только разрешенную информацию о портах. Программная зона не зависит от конкретного аппаратного обеспечения. Поэтому если некий фрейм создан с некорректным адресом назначения, он все равно будет доставлен нужному порту. Это представляет весьма очевидный контраст с правилами работы аппаратного зонирования.

Администрирование При использовании программного зонирования, члены зоны могут быть определены посредством их WWNs: > Node WWN (WWNN) > Port WWN (WWPN) Обычно при программном зонировании есть возможность создать символические имена для членов зоны и собственно самой зоны. Работа с символическими именами или псевдонимами (aliases) для устройств часто выглядит несколько проще, чем использование WWN-адресов. Количество возможных членов в зоне ограничено только объемом памяти в SAN-коммутаторе. Устройства могут быть включены в несколько зон (см. ниже). Есть возможность заранее определить набор зон в пространстве SANинфраструктуры на базе Fibre Channel. Также можно активировать другой набор зон в любое время без необходимости перезагружать коммутатор. С программным зонированием нет нужды беспокоиться о точных физических соединениях. Если вы используете WWNs для членов зоны, даже когда устройство подключено к другому физическому порту, WWNs порт для этой зоны останется тот же самый. Проще говоря, настройки зоны привязаны к WWN. Важно! Нет особой необходимости беспокоиться о физических подключениях при использовании программного зонирования. Однако эта особенность вовсе не означает, когда системный администратор отключил работающее устройство, например дисковую систему хранения, и потом подключил его в другой порт коммутатора в надежде, что доступ к дискам будет сохранен. В подобных случаях для восстановления нормальной работы понадобится либо перезагрузить сервер-клиент, либо каким-то другим образом сообщить операционной системе о произошедших изменениях. Правильность соединения зависит от множества факторов, в том числе от настроек операционной системы или другого программного обеспечения, например ПО для поддержки MultiPath [3]. Стоит отметить, что программному зонированию присущи определенные слабые места в плане безопасности. Когда определенный сервер-клиент подключается к SANинфраструктуре и запрашивает список доступных устройств хранения, служба серверных имен (SNS) просматривает таблицу программного зонирования, чтобы увидеть допустимые устройства. Рисунок 2. Использование одного устройства в двух зонах на примере резервного копирования

хранение данных Сервер-клиент видит только устройства хранения данных, которые определены в таблице программного обеспечения зонирования. Но сервер может подключаться непосредственно к устройству хранения данных с помощью обнаружения устройств, без участия SNS и соответствующих запросов о предоставлении информации. Устройство может определить WWN, используемый в данном случае, либо WWN, который был определен производителем HBA. Данная концепция заключается в подмене WWN. А неизвестный сервер может маскироваться под правильный сервер и получить доступ как обычное доверенное устройство. Тщательно настроенная операционная система SAN коммутатора позволяет администратору избежать подобного риска. Любое устройство, которое выполняет процедуру тестирования WWNs, способно находить устройства и устанавливать с ними контакт. Простая аналогия – неопубликованный телефонный номер. Даже если номер телефона не находится в публичном доступе, например его нет в телефонном справочнике, все равно нет особых препятствий, чтобы просто набрать этот номер. Некоторые устройства случайно проверяют WWNs, чтобы увидеть, могут ли они начать диалог с ним. Много вендоров, поставляющих коммутаторы, предлагают аппаратно определяемое WWN-зонирование, которое помогает предотвратить возникающие проблемы безопасности такого рода. Если используется зонирование, могут быть видимы только устройства именно этой зоны. Другие устройства будут скрыты от запросов сервера имен. Усиленное аппаратными методами зонирование использует аппаратный механизм для ограничения доступа, что гораздо эффективнее, чем полагаться на серверные службы Fibre Channel. Когда используется программное зонирование «в чистом виде», коммутатор не контролирует передачу данных и нет гарантии, что данные не будут переданы не авторизованным членам. Использование современных методов программного зонирования обеспечивает гибкость и безопасность в совместной работе устройств.

Фильтрация фреймов – Frame filtering Зонирование – это сервис управления инфраструктурой FC SAN, который может быть использован для создания логических наборов устройств SAN. Этот сервис также может разрешать разделение ресурсов для управления и контроля доступа. Фильтрация фреймов – Frame filtering – это другая функция, которая позволяет устройствам предоставлять зонирование с более мелким разделением. Фильтрация фреймов может использоваться для установки зонирования на уровне портов, зонирования WWN, зонирования на уровне устройства, на уровне протокола и даже на уровне отдельных логических томов (LUN). Разумеется, данный вариант является более сложным с точки зрения настройки и особенностей применения, но в то же время такое усложнение позволяет расширить функционал.

Одно устройство в нескольких зонах Для обеспечения определенной гибкости одно устройство может иметь доступ в несколько зон одновременно.

январь-февраль 2017 системный администратор

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

Мы познакомились с основными понятиями и особенностями устройства SAN на базе протокола и стандарта Fibre Channel. Инфраструктуры на базе Fibre Channel используются достаточно долго и «уходить на покой» из мира ИТ пока не собираются. Если проследить эволюцию устройств начиная с ранних – с шириной пропускания 1 GB/s – и заканчивая современными – с каналом в 16 GB/s, – то становится очевидно, что именно поэтапное развитие, позволяющее более старым моделям работать одновременно с последними новинками, и является основным секретом долголетия Fibre Channel.

системный администратор январь-февраль 2017

Администрирование И, несмотря на появление других интересных разработок, например iSCSI или InfiniBand, Fibre Channel пока остается основной «рабочей лошадкой» при организации сетей с блочным доступом. EOF [1] Бережной А. Построение SAN на базе протокола Fibre Channel. //«Системный администратор», №12, 2016 г. – С. 4-7 (http:// samag.ru/archive/article/3329). [2] Официальная страница организации IEEE – https://www. ieee.org/index.html. [3] Описание системы Multipath на сайте Microsoft Tech Net – https://technet.microsoft.com/en-us/library/cc725907(v=ws.11). aspx. [4] J. Tate, P. Beck, H.H. Ibarra, S. Kumaravel, L. Miklas Introduction to Storage Area Networks // IBM RedBooks. January 2016. ISBN: 0738441430 – http://www.redbooks.ibm.com/abstracts/ sg245470.html. [5] C. Poelker, A. Nikitin Storage Area Networks For Dummies // Published by Wiley Publishing, Inc., Indianapolis, Indiana ISBN: 978-0-470-38513-5. [6] M. Lippitt, E. Smith Networking Storage Concepts and Protocols TechBooks // EMC TechBooks version 3.0 – https://www.emc.com/ collateral/hardware/technical-documentation/h4331-networkedstorage-cncpts-prtcls-sol-gde.pdf. Ключевые слова: Fibre Channel, долговременное СХД, масштабирование.

Администрирование

инструменты

Визитка

СЕРГЕЙ БОЛДИН, системный администратор НЭК Укрэнерго, bsergey2@gmail.com

«Тихая» установка программ в SCCM Специальные ключи позволяют произвести установку программ без всплывающих окон и лишних вопросов пользователя. Рассмотрим примеры командных файлов

Каждому системному администратору приходится устанавливать различного рода программное обеспечение и каждый раз активировать флажки, выбирать путь или пункты из выпадающих списков, настраивать вид и язык интерфейса и многое другое. Естественно, со временем хочется максимально упростить данный процесс за счет автоматизации, ведь почти все установочные файлы имеют специальные ключи, которые делают процесс установки скрытым, более простым и легким. Применяться «тихая» установка программного обеспечения может вручную c командной строки непосрественно на компьютере сотрудника или подключившись удаленно, задействовав групповые политики, а также с помощью Configuration Manager. На нашем предприятии давно внедрен продукт SCCM 2012, поэтому рассматривать развертывание программ с использованием командных файлов и ключей автоматической установки будем на его примере.

В SCCM существует два способа автоматической инсталляции программного обеспечения: >> Package (пакетный); >> Application (приложений). Самое главное отличие между ними – в пакетном варианте не нужно указывать ключи тихой деинсталляции в отличие от второго варианта. В нашем случае применяется развертывание программ с помощью пакетов. Хотя в настройках пакетного распространения программ имеется режим Hidden (крытый) (см. рис. 1), однако не всегда получается скрыть или подавить все всплывающие окна. Поэтому лучше использовать ключи «тихой» установки прямо в мастере SCCM или отдельно создать CMD-файл [1]. Перечислим часто используемые ключи для автоматической установки программ: /silent, /s, /quiet, /q, /qn, /verysilent. %~dp0 – означает, что использовать запускаемый файл нужно из текущей папки.

Рисунок 1. Создание пакета в SCCM для распространения

январь-февраль 2017 системный администратор

инструменты Если необходимо указать точное место установки, то применяется /D или /DIR, которые пишутся после /silent, /quiet, /s /q. Например:

Администрирование ABBY> FineReader> 11 – и/или распознавания текста.

программа

сканирования

%~dp0Setup.exe /q install.exe /s /q /D="C:\NewFolder\123\"

Ключ /LANG=language применяется при явном указывании языка программы. Например:

FSViewer> 51 – программа просмотра и редактирования графических файлов формата jpeg, png, bmp и др. %~dp0FSViewerSetup51.exe /S /I

Setup.exe /LANG=Русский

либо: Setup.exe /LANG=RU

Наличие /NOICONS запрещает создание ярлыков в меню «Пуск». Пример: Setup.exe /NOICONS

Acrobat> Reader> 11 – программа просмотра документов в PDF-формате. %~dp0AdobeReader11.0.9.exe /S /Q rem exit /B 0 exit /B %EXIT_CODE%

AutoCad2013 – продукт для проектирования моделей, объектов, схем и т.д.

Некоторым приложениям после завершения установки требуется перезагрузка компьютера. Но этого можно избежать (и перегрузиться позже), используя ключи /norestart или /noreboot, REBOOT=ReallySuppress вместе с /qn, заключая выражение в кавычки. Например:

%~dp0AdminImage\Setup.exe /W /Q /I ↵ %~dp0AdminImage\AutoCAD2013x32.ini /language en-US exit /B %EXIT_CODE%

setup.msi "/qn REBOOT=ReallySuppress"

%~dp0Far3_x64.msi /qn xcopy "\\sccm03\SMS_DDD\Source\Far3\Addons" ↵ "C:\Program Files\Far Manager"/q/e/s/y rem exit /B 0 exit /B %EXIT_CODE%

Наличие программ с ключами «тихой» установки в сети Интернет – большое множество, но в моем личном списке они отсутствуют, при несоответствии версий программ могут применяться другие ключи, а также есть небольшие отличия при установке с SCCM и вручную, поэтому хочу поделиться своими примерами командных файлов для таких программ.

Far>3 – файловый менеджер.

Oracle>Client – клиентская часть базы данных Oracle. start /b /wait %~dp0setup.exe -silent -noconsole -force ↵ -nowait -responseFile "%~dp0serv6\oracleclient10203"

Рисунок 2. Настройка подавления модальных окон MS Office

системный администратор январь-февраль 2017

Администрирование exit /b

Mozilla> Firefox> 50.0.2 – один из популярных браузеров, устанавливается незаметно с помощью ключа -ms: %~dp0Firefox_Setup_50.0.2.exe -ms

При желании можно создать четыре файла (override.ini, local-settings.js, mozilla.cfg, install.cmd) [2] и прописать полный список настроек (установить стартовую страницу, отключить встроенный просмотрщик PDF-файлов, проверку плагинов, отправку отчетов, разрешить обновление браузера и многое другое), так как автоматическая установка использует настройки по умолчанию, а они не всегда соответствуют корпоративным требованиям и все равно придется их вносить вручную. MS>Office. Версию 2003 можно устанавливать без проблем, указав лишь ключ /qn: %~dp0Setup.exe /qn)

однако версии 2010/2013/2016 так просто не поддадутся. Их тонкая настройка происходит в Microsoft Office Customization Tool (Центр развертывания Microsoft Office) [3]. Для его запуска нужно в командной строке набрать: setup.exe /admin

В появившемся мастере настроек нам необходимо лишь два пункта: >> Licensing>and>user>interface>(Лицензирование>и>пользовательский> интерфейс).> Тут выбираем способ активации, Display Level (Отображать уровень), выбираем None (Нет) и активируем галочку Suppress modal (Подавлять модальные окна) (см. рис. 2);

инструменты >> Set> feature> installation> states> (Задание> режимов> установки>компонентов).>Здесь среди всего перечня указываем нужные компоненты для установки, а лишние отключаем (см. рис. 3). Затем необходимо сохранить настройки в файле .MSP в папке Updates, а в командном файле прописать обычный запуск exe-файла без ключей: %~dp0Setup.exe

Adobe>Flash>Player – плеер для отображения видео в интернете. %~dp0flash_player_IE.exe /install rem exit /B %EXIT_CODE% exit /B 0

Внесение изменений в реестр происходит также с использованием CMD-файла. Например, нужно изменить язык ввода по умолчанию с русского на английский: reg add "HKU\.DEFAULT\Keyboard Layout\Preload" ↵ /v 1 /t REG_SZ /d 00000409 /f reg add "HKU\.DEFAULT\Keyboard Layout\Preload" ↵ /v 2 /t REG_SZ /d 00000419 /f

После того как созданы CMD-файлы в Configuration Manager, создаются пакеты (или приложения) для дальнейшего распространения на компьютеры сотрудников. Для большего удобства пакеты можно добавить и в TasqSequence (Последовательность задач) (см. рис. 4), чтобы инсталляция ОС Windows и ряда программ прошла за один этап. При развертывании программ с консоли клиента SCCMпакет сначала скачивается с Distribution Point (Точка распространения) на локальный компьютер в папку C:\Windows\

Рисунок 3. Выбор устанавливаемых компонентов MS Office

январь-февраль 2017 системный администратор

инструменты ccmcache, затем запускается командный файл, в процессах ОС появляется процесс установки, при этом сотрудника от рутинной работы ничего не отвлекает. Для более опытных пользователей можно сказать, что имеется возможность самим установить программу из консоли, которая находится в «Пуск → Microsoft System Center → Software Center» (см. рис. 5), лишь нажав одну кнопку Install (Установить), при этом никаких ошибок при выборе предлагаемых мастером настройках он допустить не сможет. Достоинства: пользователь не допустит ошибок при установке ПО, экономия времени. Недостатки: изначально тратится много времени на поиск нужных ключей, написание и тестирование CMDфайлов, папка ccmcache не очищается автоматически.

Администрирование [2] Автоматическая установка Mozilla Firefox – https:// 4sysops.com/archives/deploy-firefox-with-sccm, https://www. itsupportguides.com/configmgr-sccm/install-and-configure-firefoxsilently. [3] Настройка MS Office – http://winitpro.ru/index.php/2015/12/09/ razvertyvanie-office-2016-s-pomoshhyu-sccm-2012-r2. Ключевые> слова: программы, пакеты, автоматическая инсталляция, «тихая» установка, ключи, командная строка, CMD-файл, настройки, процесс.

Рисунок 4. Настройка последовательности задач

«Тихая» установка программного обеспечения не позволяет пользователю принимать активное участие в процессе инсталляции, а значит, он не допустит никаких ошибок и не будет звонить с лишними вопросами. В Configuration Manager такую возможность можно использовать как при переустановке операционной системы, добавив пакеты в последовательность задач, так и распространив на работающий компьютер. Данный вид автоматизации устраняет немалое количество хлопот и экономит время системного администратора. EOF [1] Примеры «тихой» установки, ключи, описание – http:// tunedevice.ru/silent-install.html, http://sccm-12.blogspot.com/2012/ 12/ms-office.html, http://www.oszone.net/display.php?id=2766, http://www.dvorec.ru/raznoe/bat-files.php.

Рисунок 5. Клиентская консоль Configuration Manager

системный администратор январь-февраль 2017

Администрирование

инструменты

Визитка

АНДРЕЙ БИРЮКОВ, системный архитектор по информационной безопасности, abiryukov@samag.ru

Собираем планшет своими руками Поговорим о том, как на основе микрокомпьютера Raspberry Pi собрать планшет под управлением операционной системы Linux

Многим системным администраторам часто приходится сталкиваться с ситуацией, когда срочно необходимо диагностировать какую-либо проблему в сети, а под рукой только мобильный телефон или планшет. Вот тут нам приходится сталкиваться с массой ограничений и неудобств, которые возникают при работе с этими устройствами. И маленький экран зачастую не является главным из них, так как достаточно взять устройство с экраном формата А4. Например, для того чтобы понять, какие пакеты идут по сети или какие порты открыты на межсетевом экране, необходимы сниффер и другие инструменты. А для полноценной работы сколько-нибудь серьезных из них необходимы права root на устройстве, что уже не слишком хорошо. Со средствами разработки на Android/iOS дела обстоят еще хуже. Все эти ограничения натолкнули меня на мысли о сборке собственного планшетного компьютера на базе Raspberry Pi 3. Так как я занимаюсь информационной безопасностью, то собирался собрать мобильный компьютер для проведения пентестов. На просторах интернета нашлось несколько Рисунок 1. Разъемы на «правильном» дисплее

решений подобной задачи [1, 2]. В них авторы также подключали Touchscreen к Raspberry и разворачивали ОС Linux с утилитами для пентеста. Однако их существенным недостатком, на мой взгляд, была необходимость использовать для ввода информации дополнительные устройства, прежде всего клавиатуру и мышь. В одном из приведенных выше примеров получившееся собранное устройство пришлось поместить в железный чемодан. И это притом что Raspberry Pi размером с пластиковую карту! В общем, меня подобные решения не устроили, поэтому ключевым требованием для моего устройства являлось отсутствие необходимости обязательного использования дополнительной периферии для ввода информации, такой как клавиатура и мышь. Вся работа с устройством должна вестись с помощью Touchscreen. Что касается программного обеспечения, то на устройстве должны работать основные инструменты пентестера, такие как Aircrack-ng, nmap и другие.

Элементная база Определившись с требованиями к новому устройству, поговорим о том, из каких элементов оно будет состоять. Аппаратных элемента, по сути, только три: микрокомпьютер, Touchscreen и аккумулятор (мы же хотим сделать портативное устройство). В качестве микрокомпьютера, как уже упоминалось ранее, будет выступать Raspberry Pi 3-й версии. В принципе можно использовать и предыдущие, но третья имеет на борту Wi-Fi и Bluetooth, которые просто необходимы любому мобильному устройству. Теперь самое сложное – это Touschscreen. Дело в том, что при поиске в интернете вам будут упорно предлагать экраны для Raspberry Pi 2. Однако не все из них подходят для версии 3. Визуально отличительной чертой экранов, совместимых с 3-й версией, является наличие параллельно длинной стороне двух рядов из 20 контактов каждый (см. рис. 1). Для своего устройства я использовал модель [3]. Дисплей, размером 3,5 дюйма идеально подходит к плате Raspberry Pi 3, хотя есть варианты с большим размером.

январь-февраль 2017 системный администратор

инструменты

Администрирование

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

Третьим важным элементом нашего устройства является аккумулятор. Здесь есть определенные требования не только по выдаваемой силе тока. Для того чтобы устройство могло стабильно работать, выдаваемая аккумулятором сила тока должна быть не менее 2А. Попытки использовать источники питания с меньшей силой тока могут привести к нестабильной работе дисплея. На сегодняшний день, к сожалению, такую силу тока могут выдавать только аккумуляторы, геометрические размеры которых сопоставимы с размерами Raspberry с подключенным экраном. Поэтому половину объема нашего устройства будет занимать аккумулятор. Думаю, с развитием техники размеры Power bank станут уменьшаться, что позволит сделать меньше и наш самодельный планшет. Определившись с деталями, перейдем к сборке.

Сборка для ленивых Процесс установки дисплея на плату Raspberry достаточно прост, необходимо лишь правильно совместить контакты и аккуратно соединить дисплей и плату. При этом микрокомпьютер, естественно, должен быть отключен от питания. Здесь не получится что-либо перепутать. Более интересной является настройка программного обеспечения. Здесь возможны два варианта: >> Первый – это скачать специальную версию ОС Raspbian, в которой уже установлены необходимые драйверы экрана. >> Второй – устанавливать все необходимое ПО на свою операционную систему. Каждый из них имеет свои достоинства и недостатки. Первый вариант для новичков и ленивых. Предлагаемая версия ОС является не самой последней, в связи с чем, возможно, что не все те программы, которые вы станете впоследствии устанавливать, будут корректно работать. Выполнение sudo apt-get update не приведет к каким-либо проблемам с работой экрана. А вот выполнять sudo aptget upgrade нельзя ни в коем случае, так как после такого обновления при первой же перезагрузке ваш Raspberry

системный администратор январь-февраль 2017

«забудет» о подключенном экране, так как будут обновлены все драйверы. Второй вариант требует выполнения определенных действий для установки необходимого ПО, которые я опишу чуть ниже. Процесс установки ОС на Raspberry, думаю, известен всем поклонникам данного микрокомпьютера. Однако для новичков я кратко его опишу. Для работы Raspberry Pi 3 использует MicroSD-карту памяти. Я советую не экономить и установить сразу карту не менее 8 Гб. Cкачиваем iSOобраз специализированной ОС Raspbian [4] и с помощью WinImage записываем его на карту памяти. Далее просто устанавливаем ее в микрокомпьютер и подключаем питание. Экран должен несколько секунд быть белым, затем вывести несколько строк диагностической информации о состоянии загрузки, и затем должен высветиться оконный интерфейс. О том, что с ним делать дальше, мы поговорим чуть позже. Прежде мы рассмотрим вариант с установкой драйверов. На этом этапе нам потребуются клавиатура и мышь для выполнения команд, так как дисплей будет пока недоступен. В качестве альтернативы можно воспользоваться доступом по SSH. Прежде всего обновим список пакетов: $sudo apt-get update

Далее скачиваем обновления для ядра: $curl -SLs https://apt.adafruit.com/add-pin | sudo bash

Далее установим загрузчик, которым затем будем считывать файлы из SD-карты в L2 кэш для их последующего выполнения: $ sudo apt-get install raspberrypi-bootloader

Данный процесс займет около 20 минут. В результате мы получим два ядра (версии 6 и 7 arm) и два каталога с модулями данных ядер. Не используйте rpi-update!

Администрирование

инструменты

Далее правим /boot/config.txt:

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

$ sudo nano /boot/config.txt

и добавляем в него следующие строки: [pi1] device_tree=bcm2708-rpi-b-plus.dtb [pi2] device_tree=bcm2709-rpi-2-b.dtb [all] dtparam=spi=on dtparam=i2c1=on dtparam=i2c_arm=on dtoverlay=pitft28r,rotate=90,speed=32000000,fps=20

В первых четырех строках мы указываем системе, в каком файле искать драйверы в зависимости от версии микрокомпьютера. Далее: >> dtparam=spi=on>– разрешает использование последовательного периферийного интерфейса, >> dtparam=i2c1=on> и> dtparam=i2c_arm=on> – разрешает работу с i2c-интерфейсом.

$ sudo mv /usr/share/X11/xorg.conf.d/99-fbturbo.conf ~ $ export FRAMEBUFFER=/dev/fb1 $ startx

На дисплее должен появиться X Window. Далее необходимо включить поддержку дисплея при каждой загрузке. Для этого нажмем Control-C на консоли для выхода из оконного интерфейса и продолжим настройку. $ sudo nano /etc/modules

Добавим в конец файла строку: stmpe-ts on

Обратим внимание на содержимое последней строки. В ней rotate определяет, на сколько градусов можно поворачивать экран: 0 для портретного расположения, 90 для альбомного, 180 и 270 соответственно для перевернутого варианта работы экрана. Значение speed определяет скорость обмена драйвера с экраном. 32 MHz (32 000 000) – это хорошая скорость, однако в случае проблем ее можно снизить, указав 16 MHz (16 000 000). Далее сохраняем файл и перезагружаемся.

Сохраним изменения в файле и снова перезагрузим наш Raspberry. Теперь нам доступен функционал Touchscreen, однако вам, вероятно, необходимо его откалибровать. Сделать это можно следующим образом: $sudo mkdir /etc/X11/xorg.conf.d $sudo nano /etc/X11/xorg.conf.d/99-calibration.conf

В данный файл необходимо добавить следующие строки: $ sudo reboot

После перезагрузки экран должен сначала несколько секунд быть белого цвета, а затем стать черным. Переключение цветов будет означать, что ядро обнаружило дисплей. В случае если экран так и остался белым, значит, у вас либо проблемы с физическим подключением экрана, либо Рисунок 2. Wireshark в работе

Section "InputClass" Identifier "calibration" MatchProduct "stmpe-ts" Option "Calibration" "3800 200 200 3800" Option "SwapAxes" "1" EndSection

Снова запускаем X Window, но на этот раз на «втором мониторе» с помощью команды: FRAMEBUFFER=/dev/fb1 startx

Проверяем калибровку экрана. Как видно, эти действия не очень сложны и вполне под силу даже новичку. Итак, мы получили карманный компьютер с дисплеем. Но неотъемлемой частью любого планшетного устройства является экранная клавиатура. Здесь по умолчанию ее нет, поэтому нам придется ее установить. Для установки выполним следующую команду: $ sudo apt-get install matchbox-keyboard

Запускаем установленную клавиатуру: $ matchbox-keyboard

январь-февраль 2017 системный администратор

инструменты Теперь у нас с вами есть полноценный планшет под управлением Linux. Напомню, что, помимо Wi-Fi и Bluetooth, в Raspberry Pi 3 имеется также RG-45-интерфейс (редкость даже на ноутбуках), и все эти интерфейсы можно использовать для решения различных задач системного администрирования. В качестве примера установим Wireshark с помощью следующей команды: $ sudo apt-get install wireshark

Теперь можно осуществлять мониторинг передаваемого трафика (см. рис. 2). Дальнейшая область применения собранного устройства зависит только от вашей фантазии. Так, в состав ОС Raspbian уже входит офисный пакет Open Office, так что те, кого не пугает необходимость вводить текст с помощью экранной клавиатуры, вполне могут использовать его для работы с документами. Лично я использую данное устройство для пентестов. И хотя в рамки данной статьи не входит описание процесса установки пентесторского софта, скажу, что такие средства аудита, как Aircrack-ng, nmap и даже монстр Metasploit, без проблем устанавливаются на ОС Raspbian и относительно легко управляются через Touchscreen. Единственное дополнение, которое я бы рекомендовал сделать для оптимизации работы по беспроводным

системный администратор январь-февраль 2017

Администрирование сетям, – это подключить внешнюю антенну. ОС Raspbian прекрасно работает с недорогой антенной ALFA AWUS036NH 2000.

На этом я завершаю свою небольшую статью, посвященную сборке собственного планшета на базе Raspberry и ОС Linux. Собранное устройство вполне можно использовать для различных задач, не имея тех ограничений, которые накладывают «классические» мобильные операционные системы. При этом замечу, что стоимость микрокомпьютера, экрана и аккумулятора в сумме не превышает 7-8 тысяч рублей, что не больше стоимости сколько-нибудь приличного смартфона или планшета, но дает гораздо больший функционал. EOF [1] Видео планшета на базе Rapsberry Pi – https://www.youtube.com/ watch?v=ibpcxcHd_jQ. [2] Видео планшета на базе Rapsberry Pi – https://www.youtube.com/ watch?v=zOsix3vvsoY. [3] 3,5-дюймовый Touchscreen – https://www.adafruit.com/products/ 2441. [4] Специализированные дистрибутивы ОС Raspbian – https://learn. adafruit.com/adafruit-pitft-28-inch-resistive-touchscreen-displayraspberry-pi/easy-install. Ключевые>слова: Linux, Rapsberry Pi, Open Source, планшет.

Администрирование

виртуализация

Визитка

ДЕНИС СИЛАКОВ, к.ф.-м.н., старший системный архитектор Virtuozzo, dsilakov@virtuozzo.com

Virtuozzo Automator

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

Во-первых, есть немало действий, выполнять которые с помощью графического интерфейса эффективнее, чем посредством ввода длинных команд. Во-вторых, утилиты Virtuozzo в основном рассчитаны на работу с виртуальными окружениями в рамках одного компьютера, а если у вас множество машин под управлением этой системы виртуализации, то придется выстраивать поверх утилит (или Virtuozzo SDK) дополнительный набор инструментов. Наконец, традиции – традициями, но многие современные системные администраторы отнюдь не отвергают графический интерфейс – естественно, при условии его эффективности. В статье мы рассмотрим Virtuozzo Automator – инструментарий, позволяющий контролировать как серверы Virtuozzo, так и развернутые на них виртуальные окружения с помощью веб-браузера.

Структура и установка Для развертывания Virtuozzo Automator (сокращенно – VA) необходимо установить агентов (VA Agent) на каждый из физических серверов с Virtuozzo, а также отдельно развернуть управляющую машину (VA Management Node, MN), которая станет этими агентами руководить и на которой будет работать центр управления VA (VA Control Center, CC – он и будет предоставлять веб-интерфейс для управления вашей инфраструктурой). Учтите, что поставить MN на машину, где уже есть VA Agent, нельзя. Поскольку функции виртуализации для работы MN не нужны, то для развертывания MN рекомендуется завести отдельный сервер или контейнер под управлением Virtuozzo Linux 7 либо CentOS 7. Для установки компонентов VA MN можно воспользоваться готовым скриптом, который подключит репозитории VA, установит необходимые пакеты (группы пакетов VA Management Node и VA Control Center) и запустит соответствующие сервисы (va-mn и va-cc): # wget http://repo.virtuozzo.com/va-mn/deploy-va-mn/ ↵

deploy-va-mn # chmod 755 deploy-va-mn # ./deploy-va-mn

Если скрипт обнаружит работающие сервисы firewalld либо iptables, то он попробует модифицировать их настройки так, чтобы открыть необходимые VA порты. Однако при этом установщик не будет модифицировать те правила, которые задал системный администратор в дополнение к имеющимся по умолчанию в Virtuozzo Linux или CentOS. Так что если конфигурация firewalld или iptables очень хитрая, рекомендуем обратиться к руководству VA и удостовериться, что все необходимые порты действительно открыты. В случае если установка прошла успешно, открываем веб-браузер и переходим на адрес сервера, где установлена MN. По умолчанию веб-интерфейс доступен на порту 4648. Впрочем, скрипт установки сам сообщит нужные данные. Для входа в VA Control Center необходимо использовать параметры учетной записи root того сервера, где установлена MN. Ряд действий в центре управления VA можно производить через контекстное меню, доступное при правом клике мышкой на том или ином элементе. В Firefox при правом клике, помимо контекстного меню VA, может отобразиться и контекстное меню браузера. Чтобы оставить только меню VA, необходимо выполнить следующие действия: >> Откройте в Firefox новую вкладку, введите в адресной строке about:config и нажмите Enter. >> Выставите значение параметра dom.event.contextmenu. enabled parameter в true. Обновлять VA MN до актуальной версии можно через центр управления, а можно обновлять его пакеты непосредственно на сервере: # yum groupupdate "VA Management Node" "VA Control Center"

Для удаления VA MN достаточно удалить эти группы пакетов.

январь-февраль 2017 системный администратор

Администрирование

виртуализация Для установки агентов VA также существует готовый скрипт, действующий аналогично установщику MN:

И, естественно, создание виртуальных окружений (Virtual Environment, VE).

# wget http://repo.virtuozzo.com/va-mn/deploy-va-agent/ ↵ deploy-va-agent # chmod 755 deploy-va-agent # ./deploy-va-agent

Работа с виртуальными окружениями

Этот скрипт добавит в систему репозитории VA, установит группу пакетов VA Agent, откроет необходимые порты и запустит сервис va-agent. Скрипт необходимо запустить на каждой машине с Virtuozzo, которую вы собираетесь контролировать. В ближайшем будущем разработчики обещают интегрировать процесс установки VA непосредственно в инсталлятор Virtuozzo, но указанным скриптом по-прежнему можно будет пользоваться для доустановки агента VA на машины с уже развернутой системой.

Настройка VA и регистрация агентов Основной интерфейс VA CC предоставляет доступ к нескольким секциям, расположенным в меню слева. Содержимое правой части интерфейса изменяется в зависимости от того, в какой секции вы находитесь и с каким объектом работаете. При первом входе рекомендуем обратиться к секции Setup, где осуществляется основная настройка VA. Здесь производится управление пользователями и группами, имеющими доступ к VA, их правами и ролями. Также настраиваются оповещения по электронной почте о различных событиях, происходящих на подконтрольных VA серверах, и параметры создания резервных копий виртуальных окружений. В этой же секции указывается лицензионный ключ (см. рис. 1), необходимый для полнофункциональной работы VA. Далее необходимо зарегистрировать все машины Virtuozzo, которыми будете управлять. Производится это в соответствующем разделе секции Infrastructure. Для регистрации машины достаточно ввести ее адрес, логин и пароль пользователя root (см. рис. 2). После добавления сервера он появится в левой панели, в подменю секции Infrastructure. Для каждого сервера доступен ряд базовых действий: установка лицензии, перезагрузка, мониторинг потребления ресурсов и тому подобное.

Создание VE производится на вкладке New Virtual Environment секции Infrastructure либо в контекстном меню физического сервера, на котором требуется создать окружение. Процесс развертывания VE крайне прост (см. рис. 3) – необходимо выбрать тип окружения (контейнер или виртуальная машина), физический сервер для его размещения (при этом VA автоматически выбирает наиболее подходящее расположение с точки зрения имеющихся ресурсов), шаблон [1], а также количество окружений данного типа, которое нужно создать. В секции Infrastructure производятся и другие действия с созданными окружениями – запуск, остановка, удаление, клонирование, изменение сетевых настроек и пароля администратора, перенос на другой физический сервер, управление резервными копиями – то есть практически все действия, которые доступны для контейнеров и виртуальных машин через консольную утилиту prlctl [2]. Все они доступны в контекстом меню, достаточно сделать правый клик на имени ВМ или контейнера. Набор действий, доступных для окружения, зависит от его типа. Для всех VE доступны все операции, включая доступ по VNC с использованием встроенного клиента. Однако в силу специфики реализации контейнеров, обуславливающей их полный контроль со стороны серверной ОС без каких-либо дополнительных манипуляций (типа установки гостевых утилит), для этого типа окружений предоставляются некоторые расширенные возможности. Так, помимо доступа через VNC, вы можете работать с файловой системой контейнера с помощью файлового менеджера, который позволит перемещать файлы между сервером и VE и управлять сервисами, запущенными внутри контейнера. А если используются шаблоны ОС и приложений, то доступно и управление установленным внутри контейнера программным обеспечением. В частности, можно устанавливать и удалять шаблоны приложений, а также обновлять и удалять пакеты из заданных шаблонов. Кроме того, доступна функция Reinstall, которая переустановит все относящиеся к заданному шаблону пакеты, что может быть полезно для восстановления работы

Рисунок 1. Без ввода лицензионного ключа в секции Setup многие функции VA будут недоступны

системный администратор январь-февраль 2017

Администрирование программ внутри контейнера, если их файлы оказались повреждены. Для починки контейнера есть и другая команда – Repair. При ее вызове создается временный контейнер с такими же параметрами, как исходный, а корневая директория «сломанного» контейнера монтируется в папку /repair этого временного окружения. После чего администратор может зайти во временный контейнер и произвести любые необходимые с его точки зрения действия над сломавшимся окружением. Как и для физических серверов, для виртуальных окружений доступен мониторинг используемых ресурсов (процессора, оперативной памяти, дискового пространства, а также входящего и исходящего сетевого трафика). При этом можно настроить ограничения на потребление тех или иных ресурсов и оповещения о приближении реальных значений к предельно допустимым. На страницах мониторинга использования ресурсов VA применяет цветовую градацию: >> зеленый>цвет> – использовано менее 90% от разрешенного значения; >> желтый> – использовано 90% или больше, предельное значение еще не достигнуто; >> красный>– ресурс исчерпан.

Рисунок 2. Для регистрации сервера в VA достаточно задать его адрес и пароль root

Рисунок 3. VA позволяет создать множество VE на имеющихся серверах несколькими кликами мыши

виртуализация Еще одна возможность, на которой хотелось бы остановиться, – это управление резервными копиями виртуальных окружений. Управление резервными копиями осуществляется на двух уровнях: >> глобально (настройки – в разделе Configure Backups секции Setup, а непосредственное управление резервными копиями сразу множества машин – в разделе Backups секции Infrastructure); >> в меню конкретного физического сервера или VE. Создание резервных копий может осуществляться автоматически по расписанию (и может быть настроено как для отдельных VE, так и для их наборов – например, для всех окружений, находящихся на одном физическом сервере) либо вручную. Также можно варьировать вид резервирования (инкрементальный либо полный) и сервера для хранения создаваемых копий.

Работа с группами серверов и VE Принципиальным отличием VA от консольных утилит, помимо графического интерфейса, является возможность оперировать группами серверов и виртуальных окружений – пользователь VA может выбрать сразу несколько контейнеров либо ВМ и произвести некоторую операцию сразу над всеми ими. Безусловно, не все операции имеет смысл выполнять для групп VE. Например, переименовывать контейнеры логичнее по одному, а вот выбрать шаблон ОС, настроить автоматический запуск при старте сервера, установить дисковые квоты и прочие ограничения можно и для множества контейнеров. Возможность выбрать сразу несколько окружений для осуществления той или иной операции предоставится вам в том разделе веб-интерфейса, из которого эта операция запускается. Помимо выбора множества VE для конкретной операции, можно визуально объединять как физические, так и виртуальные машины. На визуальном уровне объединение машин в группу заключается в создании папок для каждой группы в и «перетаскивании» машин в эти папки. Помимо зрительного удобства и гибкости управления, группы могут служить для ограничения доступа пользователей VA к тем или иным машинам, о чем мы расскажем ниже. Группировка производится двумя способами – в меню Infrastructure и Logical View. В Infrastructure производится только группировка по физическому принципу. Здесь можно объединять физические серверы в группы (например, завести отдельные группы для серверов в разных зданиях), а в рамках физического сервера создавать группы виртуальных машин и контейнеров. При этом здесь нельзя нарушать порядок наследования (первый уровень – реальное «железо», а внутри каждого реального сервера – группы виртуальных) и мешать в одной группе физические и виртуальные серверы. Секция Logical View предоставляет больше гибкости и дает возможность производить группировку серверов так, как вам угодно. При этом сервер или виртуальное окружение может присутствовать сразу в нескольких логических группах. Перемещать машину из одной группы в другую можно, просто перетаскивая ее имя мышкой между соответствующими папками.

январь-февраль 2017 системный администратор

виртуализация

Продвинутая настройка VA Помимо настроек в секции Setup, управление VA осуществляется посредством инструментов в секции Management. Здесь присутствуют следующие подменю: >> Scheduler> – настройка расписания создания резервных копий (можно настраивать бэкапы для конкретных виртуальных окружений либо для всех окружений на заданном сервере). >> Task>Log>– журнал задач, выполняемых VA. >> Support>– перечень ошибок, встречающихся в ходе работы VA, и возможные пути их исправления. >> Updates> – инструментарий обновления программного обеспечения Virtuozzo. Напомним, что даже обновление ядра в Virtuozzo обычно происходит без перезагрузки машины благодаря сервису ReadyKernel [3]. Также отметим, что обновление не приносит на машину новые шаблоны контейнеров, которые появились в официальных репозиториях Virtuozzo; их необходимо устанавливать с помощью инструментария управления ресурсами, речь о котором пойдет ниже. >> Alerts> and> Events> – сведения о потреблении ресурсов и информация об изменении статуса виртуальных окружений (остановлено, запущено и тому подобное). >> Audit> – просмотр текущих сессий на серверах и виртуальных окружениях. Еще один немаловажный аспект – это управление пользователями. Создание и управление пользователями выполняется через веб-интерфейс, доступен импорт из существующих LDAP-совместимых баз. Наиболее важный момент в этом процессе – настройка прав пользователей, которые (права) регулируются при помощи механизма ролей. С каждым пользователем ассоциируется одна или несколько ролей, каждая из которых дает права на выполнение тех или иных действий с объектами определенного типа. Типы объектов включают в себя физические серверы, виртуальные окружения, а также их группы. Пользователи объединяются в группы, роли ассоциируются с группами, а не с конкретными пользователями. Набор возможных типов действия зависит от объекта, к которому они применяются. При этом практически каждое действие требует отдельной привилегии – например, привилегия на запуск/остановку контейнера или ВМ, привилегия на изменение настроек виртуального окружения, привилегия на осуществление его миграции и так далее. С полным перечнем привилегий можно ознакомиться в Руководстве администратора VA [4]. Каждый пользователь может выполнить и индивидуальные настройки веб-интерфейса «под себя» в своем профиле – например, разрешить или запретить всплывающие подсказки, настроить отображаемые пункты меню и их содержимое, включить динамическое обновление информации о статусе VE и так далее. Пользователям рекомендуется ввести корректный адрес электронной почты на случай утери пароля – в такой ситуации восстановить пароль можно будет без участия администратора VA.

Администрирование использоваться в контейнерах и ВМ. В этой секции можно настраивать хранилища файлов и шаблонов, которые будут доступны всем зарегистрированным в VA серверам, и управлять их содержимым. Здесь же можно создавать собственные шаблоны ОС и приложений для контейнеров, если вам не хватает шаблонов Virtuozzo. Кроме того, можно создавать шаблоны ВМ – любую ВМ можно сохранить как шаблон и использовать в будущем для создания новых ВМ. Единственным отличием шаблона от реальной ВМ является то, что его нельзя запустить.

Главным достоинством Virtuozzo Automator является возможность работы сразу с множеством объектов, включая как реальные, так и виртуальные серверы Непосредственное управление установленными на серверах шаблонами (просмотр, установка, удаление, обновление, создание кэшей) осуществляется либо на страничках соответствующих серверов либо на страницах группы, в которые входят все нужные серверы. Аналогично для каждого контейнера можно установить или удалить шаблон приложения и обновить входящие в него пакеты. Resource Library также позволяет настроить виртуальные подсети и диапазоны IP-адресов, доступные виртуальным окружениям. Как и в случае с шаблонами, сетевые настройки серверов и виртуальных окружений задаются на страничках соответствующих машин или групп, в которые они входят.

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

Управление ресурсами

[1] Силаков Д. Шаблоны контейнеров в Virtuozzo. // «Системный администратор», №5, 2016 г. – С. 9-11 (http://samag.ru/archive/ article/3186). [2] Силаков Д. Промышленная виртуализация с помощью Virtuozzo 7. // «Системный администратор», №12, 2015 г. – С. 4-6 (http://samag.ru/archive/article/3083). [3] Силаков Д. Обновление ядра Linux без перезагрузки. // «Системный администратор», №10, 2016 г. – С. 7-11 (http:// samag.ru/archive/article/3285). [4] Virtuozzo Automator Administrator's Guide – http://docs. virtuozzo.com/virtuozzo_automator_7_administrators_guide.

Еще одна секция основной панели VA – Resource Library – служит для управления различными ресурсами, которые могут

Ключевые>слова: виртуализация, OpenVZ, контейнеры, Virtuozzo.

системный администратор январь-февраль 2017

Администрирование

виртуализация

Визитка АНДРЕЙ МАРКЕЛОВ, RHCA, старший менеджер архитектурных решений компании Ericsson, автор книг об облачных технологиях, andrey.markelov@ericsson.com

Работа с контейнерами Docker

Часть 1. Основы

Узнаем, как на практике управлять контейнерами Docker, об организации взаимодействия между ними и управлением кластерами контейнеров

Архитектура Docker Читатели журнала уже знакомы с технологиями контейнеров и проектом Docker [1, 2]. Начнем с того, что опишем базовый функционал, который пригодится в дальнейших статьях цикла, и кратко напомним об архитектуре Docker. Docker использует клиент-серверную архитектуру и состоит из клиента – утилиты docker, которая обращается к серверу при помощи RESTful API, и демона в операционной системе Linux (см. рис. 1). Хотя Docker работает и в отличных от Linux ОС, в этой статье они не рассматриваются. Основные компоненты Docker: >> Контейнеры> – изолированные при помощи технологий операционной системы пользовательские окружения, в которых выполняются приложения. Проще всего дать определение контейнеру Docker как запущенному из образа приложению. Кстати, именно этим идеологически и отличается Docker, например, от LXC (Linux Containers), хотя они используют одни и те же технологии ядра Linux. Разработчики проекта Docker исповедует принцип: один контейнер – это одно приложение. >> Образы>– доступные только для чтения шаблоны приложений. Поверх существующих образов могут добавляться новые уровни, которые совместно представляют файловую систему, изменяя или дополняя предыдущий уровень. Обычно новый образ создается либо при помощи Рисунок 1. Архитектура Docker в GNU/Linux

сохранения уже запущенного контейнера в новый образ поверх существующего, либо при помощи специальных инструкций для утилиты dockerfile. Для разделения различных уровней контейнера на уровне файловой системы могут использоваться AUFS, btrfs, vfs и Device Mapper. Если предполагается использование Docker совместно с SELinux, то требуется Device Mapper. >> Реестры> (registry),> содержащие> репозитории> (repository)>образов,>– сетевые хранилища образов. Могут быть как приватными, так и общедоступными. Самым известным реестром является Docker Hub [3]. Для изоляции контейнеров в операционных системах GNU/Linux используются стандартные технологии ядра Linux, такие как: >> Пространства имен (Linux Namespaces). >> Контрольные группы (Cgroups). >> Средства управления привилегиями (Linux Capabilities). >> Дополнительные, мандатные системы обеспечения безопасности, такие как AppArmor или SELinux. Рассмотрим перечисленные технологии чуть более подробно. Механизм>контрольных>групп>(Cgroups) предоставляет инструмент для тонкого контроля над распределением, приоритизацией и управлением системными ресурсами. Контрольные группы реализованы в ядре Linux. В современных дистрибутивах управление контрольными группами реализовано через systemd, однако сохраняется возможность управления при помощи библиотеки libcgroup и утилиты cgconfig. Основные иерархии контрольных групп (их также называют контроллерами) перечислены ниже: >> blkio>– задает лимиты на операции ввода-вывода и на доступ к блочным устройствам; >> cpu> – используя планировщик процессов, распределяет процессорное время между задачами; >> cpuacct>– создает автоматические отчеты по использованию ресурсов центрального процессора. Работает совместно с контроллером cpu, описанным выше;

январь-февраль 2017 системный администратор

виртуализация

Администрирование

Docker использует клиентсерверную архитектуру и состоит из клиента – утилиты docker и демона в ОС

>> cpuset> – закрепляет за задачами определенные процессоры и узлы памяти; >> devices> – регулирует доступ задачам к определенным устройствам; >> freezer>– приостанавливает или возобновляет задачи; >> memory> – устанавливает лимиты и генерирует отчеты об использовании памяти задачами контрольной группы; >> net_cls> – осуществляет тегирование сетевых пакеты идентификатором класса (classid). Это позволяет контроллеру трафика (команда tc) и брандмауэру (iptables) учитывать эти тэги при обработке трафика; >> perf_event> – позволяет производить мониторинг контрольных групп при помощи утилиты perf; >> hugetlb>– позволяет использовать виртуальные страницы памяти большого размера и применять к ним лимиты. Пространства> имен, в свою очередь, контролируют не распределение ресурсов, а доступ к структурам данных ядра. Фактически это означает изоляцию процессов друг от друга и возможность иметь параллельно «одинаковые», но не пересекающиеся друг с другом иерархии процессов, пользователей и сетевых интерфейсов. При желании разные сервисы могут иметь даже свои собственные loopbackинтерфейсы. Примеры пространств имен, используемых Docker: >> PID,>Process>ID>– изоляция иерархии процессов. >> NET,>Networking>– изоляция сетевых интерфейсов. >> PC,> InterProcess> Communication> – управление взаимодействием между процессами. >> MNT,>Mount>– управление точками монтирования. >> UTS,>Unix>Timesharing>System>– изоляция ядра и идентификаторов версии. Механизм> под> названием> Capabilities позволяет разбить привилегии пользователя root на небольшие группы привилегий и назначать их по отдельности. Данный функционал в GNU/Linux появился начиная с версии ядра 2.2. Изначально контейнеры запускаются уже с ограниченным набором привилегий.

системный администратор январь-февраль 2017

При помощи опций команды docker можете разрешать и запрещать: >> операции монтирования; >> доступ к сокетам; >> выполнение части операций с файловой системой, например изменение атрибутов файлов или владельца. Подробнее ознакомиться с привилегиями можно при помощи man-страницы CAPABILITIES(7).

Установка Docker Рассмотрим установку Docker на примере CentOS. При работе с CentOS у вас есть выбор: использовать последнюю версию из upstream или версию, собранную проектом CentOS с дополнениями Red Hat. Описание изменений доступно на странице [4]. В основном это обратное портирование исправлений из новых версий upstream и изменения, предложенные разработчиками Red Hat, но пока не принятые в основной код. Наиболее заметным различием на момент написания статьи было то, что в новых версиях сервис docker был разделен на три части: демон docker, containerd и runc. Red Hat пока не считает, что это изменение стабильно, и поставляет монолитный исполнимый файл версии 1.10. Настройки репозитория для установки upstream-версии, как и инструкции для инсталляции в других дистрибутивах и ОС, приведены в руководстве по инсталляции на официальном сайте Docker [5]. В частности, настройки для репозитория CentOS 7: # cat /etc/yum.repos.d/docker.repo [dockerrepo] name=Docker Repository baseurl=https://yum.dockerproject.org/repo/main/centos/7 enabled=1 gpgcheck=1 gpgkey=https://yum.dockerproject.org/gpg

Устанавливаем необходимые пакеты и запускаем и включаем сервис:

Администрирование

виртуализация в официальной документации), то необходимо создать группу docker и добавить в опции запуска демона:

# yum install -y docker-engine # systemctl start docker.service # systemctl enable docker.service

OPTIONS='--selinux-enabled --log-driver=journald ↵ --group=docker'

Проверяем статус сервиса:

После чего рестартуем сервис и проверяем, что файл сокета docker принадлежит группе docker, а не root:

# systemctl status docker.service

Также можно посмотреть о Docker и окружении:

системную

информацию

# docker info

При запуске аналогичной команды в случае установки Docker из репозиториев CentOS увидите незначительные отличия, обусловленные использованием более старой версии программного обеспечения. Из вывода docker info можем узнать, что в качестве драйвера для хранения данных используется Device Mapper, а в качестве хранилища – файл в /var/lib/docker/: # ls -lh /var/lib/docker/devicemapper/devicemapper/data -rw-------. 1 root root 100G Dec 27 12:00 /var/lib/docker/ devicemapper/devicemapper/data

Опции запуска демона, как это обычно бывает в CentOS, хранятся в /etc/sysconfig/. В данном случае имя файла docker. Соответствующая строчка /etc/sysconfig/docker, описывающая опции: OPTIONS='--selinux-enabled --log-driver=journald'

Для того чтобы пользоваться командой docker без применения sudo, необходимо добавить пользователя, с правами которого вы работаете, в группу docker: # usermod -aG docker andrey

Если бы вы запустили команду docker не пользователем root и не пользователем, входящим в группу docker, вы бы увидели подобную ошибку: $ docker search mysql Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon. Is the docker daemon running on this host?). Using system default: https://index. docker.io/v1/ Cannot connect to the Docker daemon. Is the docker daemon running on this host?

Обратите внимание, что фактически включение пользователя в группу docker равносильно включению этого пользователя в группу root. У разработчиков RHEL/CentOS несколько иной подход к безопасности демона Docker, чем у разработчиков самого Docker из upstream. Подробнее о подходе Red Hat написано в статье разработчика дистрибутива RHEL Дэна Уолша [6]. Если же вы хотите «стандартное» поведение Docker, установленного из репозиториев CentOS (т.е. описанное

# ls -l /var/run/docker.sock srw-rw----. 1 root docker 0 Dec 27 13:32 /var/run/docker.sock

Поиск образов и тэги Попробуем найти контейнер на Docker Hub. $ docker search haproxy NAME DESCRIPTION haproxy HAProxy - The Reliable, High Perf... eeacms/haproxy HAProxy Docker image with docker ... million12/haproxy Fully customisable HAProxy load b... STARS OFFICIAL AUTOMATED 607 [OK] 17 [OK] 14 [OK] ...

В данном выводе мы получили список ряда образов HA Proxy. Самый верхний элемент списка – это HA Proxy из официального репозитория. Такие образы отличаются тем, что в имени отсутствует символ «/», отделяющий имя репозитория пользователя от имени самого контейнера. В примере за официальным показаны два образа haproxy из открытых репозиториев пользователей eeacms и million12. Образы, подобные двум нижним, можете создать сами, зарегистрировавшись на Docker Hub. Официальные же поддерживаются специальной командой, спонсируемой Docker, Inc. Особенности официального репозитория: >> Это рекомендованные к использованию образы, созданные с учетом лучших рекомендаций и практик. >> Они представляют собой базовые образы, которые могут стать отправной точкой для более тонкой настройки. Например, базовые образы Ubuntu, CentOS или библиотек и сред разработки. >> Содержат последние версии программного обеспечения с устраненными уязвимостями. >> Это официальный канал распространения продуктов. Чтобы искать только официальные образы, можете использовать опцию --filter "is-official=true" команды docker search. Число звезд в выводе команды docker search соответствует популярности образа. Это аналог кнопки Like в социальных сетях или закладок для других пользователей. Automated означает, что образ собирается автоматически из специального сценария Dockerfile средствами Docker Hub. Обычно следует отдавать предпочтение автоматически собираемым образам вследствие того, что его содержимое может быть проверено знакомством с соответствующим файлом Dockerfile. Скачаем официальный образ HA Proxy:

январь-февраль 2017 системный администратор

Администрирование

виртуализация

Полное имя образа может выглядеть следующим образом:

В качестве одной из опций можно было бы задать уникальное имя контейнера, на которое можно для удобства ссылаться, помимо ID-контейнера. Она задается как --name <имя>. В случае если опция опущена, имя генерируется автоматически. Автоматически генерируемые имена контейнеров не несут смысловой нагрузки, однако как интересный факт можно отметить, что имена генерируются случайным образом из прилагательного и имени известного ученого, изобретателя или хакера. В коде генератора для каждого имени можно найти краткое описание того, чем известен данный деятель. Посмотреть список запущенных контейнеров можно командой docker ps. Для этого откроем второй терминал:

[URI репозитория][имя пользователя]имя образа[:тэг]

$ docker ps

Просмотреть список скаченных образов можно командой docker images:

CONTAINER ID d7402d1f7c54 STATUS Up 4 seconds

$ docker pull haproxy Using default tag: latest

Обратите внимание, что в выводе была указана загрузка образа с тэгом latest. Использование тэгов позволяет обращаться к конкретной версии. Помимо самого образа haproxy, был скачен базовый образ и все промежуточные, от которых зависит скачиваемый. Чтобы скачать конкретную версию, используем: $ docker pull haproxy:1.5

IMAGE ubuntu PORTS

COMMAND CREATED "/bin/bash" 9 seconds ago NAMES romantic_heisenberg

$ docker images REPOSITORY docker.io/haproxy

TAG latest

IMAGE ID c0a3eb080707

CREATED 13 days ago

SIZE 138 MB

Команда docker images с опцией -q вернет только идентификаторы образов, что может быть полезным для использования идентификаторов в качестве входных значений для другой команды. Например, команды docker rmi, которая удаляет образ. Для того чтобы удалить все имеющиеся в локальном кэше образы, можно воспользоваться такой командой:

В случае если необходимо запустить контейнер с процессом, не предполагающим интерактивное взаимодействие, например с демоном, используется опция -d. Так и поступим со следующим контейнером: $ docker run -d mysql

Однако если отдать команду docker ps, контейнера, созданного из образа mysql, мы не обнаружим. Воспользуемся опцией -a, которая показывает все контейнеры, а не только запущенные:

$ docker rmi $(docker images -q) $ docker ps -a

Запуск контейнеров Для запуска контейнера не обязательно предварительно скачивать образ. Если он доступен, то будет загружен автоматически. Давайте попробуем запустить контейнер с Ubuntu. Мы не будем указывать репозиторий, и будет скачан последний официальный образ, поддерживаемый Canonical. $ docker run -it ubuntu root@d7402d1f7c54:/#

Помимо команды run, мы указали две опции: -i – контейнер должен запуститься в интерактивном режиме и -t – должен быть выделен псевдотерминал. Как видно из вывода, в контейнере мы имеем привилегии пользователя root, а в качестве имени узла отображается идентификатор контейнера. Последнее может быть справедливо не для всех контейнеров и зависит от разработчика контейнера. Проверим, что это действительно окружение Ubuntu: root@d7402d1f7c54:/# cat /etc/*release | grep DISTRIB_DESCRIPTION DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

Команду uname -a для подобных целей использовать не получится, поскольку контейнер работает с ядром хоста.

системный администратор январь-февраль 2017

CONTAINER ID IMAGE COMMAND d454844325da mysql "docker-entrypoint.sh" d7402d1f7c54 ubuntu "/bin/bash" CREATED STATUS About a minute ago Exited (1) About a minute ago 32 minutes ago Up 32 minutes NAMES peaceful_jones romantic_heisenberg

PORTS

В качестве статуса значится Exited. Для того чтобы разобраться с причиной, можно обратиться к журналу: $ docker logs peaceful_jones error: database is uninitialized and password option is not specified You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD

Очевидно, что при запуске контейнера не были указаны обязательные параметры. Ознакомиться с описанием переменных среды, необходимых для запуска контейнера, можно, найдя официальный образ MySQL на Docker Hub. Повторим попытку, используя опцию -e, которая задает переменные окружения в контейнере: $ docker run --name mysql-test ↵ -e MYSQL_ROOT_PASSWORD=docker -d mysql

Администрирование

виртуализация

При помощи следующей команды можно подключиться к работающему контейнеру:

командной строки, мы бы модифицировали команду запуска уже известным вам образом:

$ docker exec -it mysql-test bash

$ docker run -it --name mysql-test2 -e MYSQL_ROOT_PASSWORD=docker mysql /bin/bash

root@b8fda6aac249:/#

Последним параметром выступает команда, которую мы хотим исполнить внутри контейнера. В данном случае это командный интерпретатор Bash. Опции -it аналогичны по назначению использованным ранее в команде docker run. Фактически после запуска этой команды в контейнер mysql-test добавляется еще один процесс – bash. Это можно наглядно увидеть при помощи команды pstree. Сокращенный вывод до команды docker exec: # pstree -p systemd(1)─┬ ├─docker-current(879)─┬─mysqld(3026)─┬─{mysqld}(3124) │ │ ├─{mysqld}(3125)

И после команды docker exec:

После чего можно было бы изучить стартовый скрипт: root@5c31ad53edb1:/# cat $(which docker-entrypoint.sh)

Обратите внимание на одинаковый для двух контейнеров вывод в столбце COMMAND команды docker ps: $ docker ps -a CONTAINER ID 5c31ad53edb1 d3d4c9281249 STATUS Up 2 minutes Up 13 minutes

IMAGE COMMAND mysql "docker-entrypoint.sh" mysql "docker-entrypoint.sh" PORTS NAMES 3306/tcp mysql-test2 3306/tcp mysql-test

CREATED 2 minutes ago 13 minutes ago

Однако команда pstree, запущенная в контейнере, покажет нам разницу в запуске контейнеров. Для mysql-test:

# pstree -p

root@d3d4c9281249:/# pstree -p

systemd(1)─┬ ├─docker-current(879)─┬─bash(3163) │ ├─mysqld(3026)─┬─{mysqld}(3124) │ │ ├─{mysqld}(3125)

mysqld(1)-+-{mysqld}(93) |-{mysqld}(94) ...

и для mysql-test2: Также можно воспользоваться командой docker top, поскольку из полученного вывода pstree не очевидно, что процессы mysqld и bash принадлежат одному и тому же контейнеру: # docker top mysql-test UID systemd+

PID 3026

PPID 879

C 0

STIME 11:03

TTY ?

TIME 00:00:00

CMD mysqld

Вывод после запуска команды docker exec: # docker top mysql-test UID systemd+ root

PID 3026 3163

PPID 879 879

C 0 3

STIME 11:03 11:09

TTY ? pts/2

TIME 00:00:00 00:00:00

CMD mysqld bash

Теперь посмотрим на вывод команды docker ps, которая покажет список запущенных контейнеров: $ docker ps CONTAINER ID d3d4c9281249 STATUS Up 4 minutes

IMAGE COMMAND mysql "docker-entrypoint.sh" PORTS NAMES 3306/tcp mysql-test

CREATED 4 minutes ago

Мы видим, что в качестве команды, запущенной при старте контейнера, использовался скрипт docker-entrypoint.sh. Это достаточно распространенный способ инициализации программного обеспечения в контейнере. Если бы мы хотели в отладочных целях запустить контейнер, но вместо скрипта просто получить приглашение

root@5c31ad53edb1:/# pstree -p bash(1)---pstree(17)

Отсюда мы видим, что во втором случае база данных MySQL запущена не была.

В первой статье цикла мы познакомились с внутренними механизмами контейнеров и запустили первый контейнер Docker. В следующем номере журнала мы рассмотрим такие темы, как управление состоянием контейнеров, обмен данными с контейнером по сети и подключение к контейнеру постоянного хранилища. EOF [1] Силаков Д. Проект Docker. Управляем виртуальными окружениями. // «Системный администратор», №3, 2015 г. – С. 4-7 (http:// samag.ru/archive/article/2887). [2] Силаков Д. Open Containers Initiative. Стандартизация в мире контейнеров. // «Системный администратор», №7-8, 2016 г. – С. 6-8 (http://samag.ru/archive/article/3229). [3] Docker Hub – https://hub.docker.com. [4] Описание изменений версии Docker от Red Hat – http://www. projectatomic.io/docs/docker_patches. [5] Официальный сайт Docker – https://www.docker.com. [6] Статья Дэна Уолша об установке Docker в CentOS – http://www. projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-rundocker-in-centos-fedora-or-rhel. Ключевые>слова: виртуализация, Linux, контейнеры, Docker.

январь-февраль 2017 системный администратор

виртуализация

Администрирование Визитка

СЕРГЕЙ ЯРЕМЧУК, автор более 1000 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС, yaremchuk@samag.ru

Знакомимся с Kubernetes Управление большим количеством контейнеров на нескольких серверах штатными инструментами Docker – не очень простая задача. Google предлагает эффективное решение

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

Управление контейнерами Практически одновременно несколько компаний предложило решения, схожие по задаче, но отличающиеся реализацией. В первую очередь это Docker Swarm [1], который позволяет создать кластер, объединять Dockerконтейнеры и запускать их одной командой. В сочетании с Docker Compose это очень удобный инструмент для планирования контейнеров. Он очень прост в развертывании. Для управления используется REST API-интерфейс, совместимый с Docker API. Все инструменты, совместимые с API Docker, – Dokku, DockerUI,Krane, Flynn и многие другие – могут работать с кластером Docker Swarm, как с обычным хостом. В 1.12 в штатном Docker появился режим swarm mode, позволяющий в удобной форме разворачивать кластер, запускать приложение, менять количество реплик, балансировать нагрузку, обновлять контейнеры без остановки, откат обновлений и многое другое. Nomad [2] представляет собой несколько более глобальное решение для управления кластером машин и запуском приложений на них, которое может быть использовано для большого круга задач. Поддерживает несколько ЦОД и мультирегиональные конфигурации. По утверждению разработчиков он тестировался на кластерах до 5000 узлов, разворачивая до 3500 контейнеров в секунду, но работает и на гораздо более крупных кластерах. Сочетает менеджер ресурсов и планировщик собственной разработки,

системный администратор январь-февраль 2017

определяющий, на каком узле развернуть по указанным ресурсам. Для Docker-контейнеров можно задавать ограничения, указывать регион, количество реплик. Серверная и клиентская части реализованы в одном бинарнике, для координации или хранения не требуется других внешних служб. Разработанная в Twitter платформа Marathon [3] – также несколько более глобальное решение. Представляет собой надстройку над менеджером кластера Apache Mesos, расширяя его возможности по управлению приложениями и контейнерами в нескольких ЦОД. Реализованы функции масштабирования, восстановления работоспособности, балансировки, установки ограничений. Поддерживается формат контейнера Docker и свой Mesos, плюс приложения JBoss, Jetty, Sinatra, Rails и т.д. В работе использует другие решения Apache Software Foundation для организации обнаружения приложений, планирования и т.д.: ZooKeeper, Chronos, Kafka, Hadoop и т.д. Самостоятельная установка Marathon – не самое простое дело.

Проект Kubernetes Разработки Kubernetes [4] (сокращенно K8S) официально стартовали в Google в 2014 году, а первая публичная версия 0.1 появилась через год – в июле 2015-го. Хотя разработка не начиналась совсем с нуля. В основе K8S лежит Borg, проект управления кластерами в Google, переориентированный теперь на управление Docker-контейнерами. Многие проблемы, с которыми разработчики столкнулись при создании Borg, были уже опробованы и решены, поэтому проект так быстро стартовал. Чуть позже совместно с Linux Foundation для выработки единого стандарта и взаимодействия была сформирована Cloud Computing Native Foundation (CNCF), в которую вошли сама Google, Cisco, IBM, Docker и VMware. Забегая наперед, отмечу две вещи. И хотя текущей стабильной версией является уже 1.5.1, многое еще в API не реализовано и находится в официальном бета- и даже альфа-статусе. Даже мастер установки кластера честно предупреждает: «WARNING: kubeadm is in alpha, please do

Администрирование not use it for production clusters». Но тем не менее решение работает стабильно, есть уже много субпроектов, дополняющих K8S, и легко можно найти сообщения об успешном использовании в продакшен, так как в нем реализованы все функции, необходимые для запуска приложений на основе Docker в конфигурации с высокой доступностью, – деплой, обнаружение сервисов, планирование, мониторинг и многое другое. Для реализации всего этого могут использоваться сторонние услуги и аддоны [5], которые, взаимодействуя с API более высокого уровня, обеспечивают требуемую функциональность. Так, за координацию и хранение настроек отвечает etcd, за создание сетей между контейнерами или нодами – Flannel, Weave Net, Calico, за мониторинг – cAdvisor. И многие другие. При этом, даже учитывая, что эти компоненты устанавливаются дополнительно, особых проблем (в последних релизах) с их интеграцией нет, все ставятся буквально одной командой, и можно собрать среду под конкретные задачи. Все обычно работает и без особого вмешательства и фактически скрыто от сисадмина (приходится специально разбираться, как оно все работает). После установки он размещает контейнеры, все остальное полностью на плечах K8S. Забегая наперед, скажу, что отсутствие внятной документации, явно не успевающей за проектом и часто вводящей в заблуждение, требует большего времени, чтобы во всем действительно разобраться. К тому же проект быстро развивается, и функции, недоступные в текущем релизе, уже реализованы и работают в master ветке Git. Но важно понимать, что Kubernetes хотя и использует Docker, но именно из-за своей нацеленности на работу в кластерах, когда контейнер будет запущен неизвестно на каком сервере, многие моменты здесь чуть отличаются. И если единичный контейнер запускается без дополнительных изменений и практически такой же командой, то группа контейнеров, обменивающихся данными между собой, работает чуть по-другому. Например, Docker запускается так, что контейнеры на одном хосте могут общаться между собой как по сети, так и брать файлы из volume на локальном диске. Если нужен доступ к контейнерам на другом хосте, придется уже как-то проксировать информацию. В K8S изначально исходят из того, что контейнеры могут находиться не только на разных хостах, но и в разных дата-центрах. А поэтому сетевая модель несколько изменена, чтобы упростить настройку сети, а возможность обмена данными через локальный volume присутствует, но лишь для тестовых целей для запуска на однокластерной системе. Kubernetes представляет собой систему с несколькими специфическими концепциями, с которыми нужно познакомиться, прежде чем идти вперед. Единицей планирования (и масштабирования) ресурсов здесь является Pods. По сути, это один контейнер или группа контейнеров, работающих вместе. Контейнеры внутри Pods могут обмениваться данными через localhost, IPC, использовать общие разделы и т.п. Также все контейнеры из одного Pod всегда будут запускаться на одном сервере. Основная идея сети в K8S состоит в том, чтобы контейнеры общались между собой напрямую без NAT, гарантировано получая сетевые ресурсы. Это реализовано в концепции IP-per-Pod, упрощающей обмен информацией

виртуализация и распределение сетевых ресурсов, не привязываясь к порту (как это было в Borg, сервисы использовали одно IP), в K8S каждому Pod назначается отдельный IP-адрес из серого диапазона. К этому адресу можно подключаться и работать, как в Docker, но при перезапуске Pod он мало того, что может стартовать на другом сервере, так и скорее всего получит совсем другой PodsIP, и закрепить его никак нельзя. Каждый объект получает свое уникальное имя (задается пользователем) и UID (генерируется автоматически). Для обмена информацией между объектами используется внутрикластерная служба DNS, поэтому вместо IP достаточно указать его имя и порт. Также по имени можно обращаться к некоторым ресурсам, в настоящее время доступно 19 типов ресурсов, все они описаны в документации. Pod можно стартовать командой, как это делается в Docker, но обычно создается YAML-файл (ранее поддерживался и JSON), в котором прописываются все настройки. Чтобы обеспечить работу приложения, используется следующая абстракция – сервис (Services), определяющий набор Pods и политику их применения. Метки (Labels) – пары ключ/значение, которые прикрепляются к Pod и любому объекту, позволяя легко группировать, отбирать, назначать задания и привязывать к сервисам при помощи селектора (selector). Также к сервисам можно назначить и внешнюю службу. Для проксирования информации внутри кластера сервисы получают clusterIP, доступный только внутри кластера. Кластер логически делится на несколько виртуальных при помощи Namespaces. Каждая Namespaces существует в изолированном пространстве, ограниченном квотами, не влияя на других. По умолчанию в кластере создается Namespaces – default, в которую будут помещаться поды и служебная kube-system. Кластер содержит мастер сервер и minion. Уже реализованы работа нескольких мастеров в кластере и мультикластерная установка (Cluster Federation или Ubernetes), позволяющая несколькими кластерами из одной точки. Правда, в отличие от Docker swarm mode настройка не так проста и ужасно плохо описана в документации. На мастере по умолчанию запускаются следующие службы: >> kubelet (основная программа), >> kube-apiserver, >> kube-controller-manager (менеджер сервисов), >> kube-discovery, >> kube-dns, >> kube-proxy (прокси балансировщик), >> kube-scheduler (планировщик), >> etcd, >> сетевая служба weave-net/flannel. На minion устанавливаются агенты kubelet, kube-proxy и сетевая служба. Прокси обеспечивает перенаправление потоков между Pod. Также на всех узлах запускается служба мониторинга cAdvisor (при стандартной установке, порт 4194). Доступ к API управления, кроме программного способа, можно получить при помощи консольной утилиты kubectl и веб-интерфейса. Они помогут просматривать текущую

январь-февраль 2017 системный администратор

виртуализация

Администрирование

В основе K8S лежит Borg, проект управления кластерами в Google, переориентированный на управление Dockerконтейнерами

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

Варианты установки Kubernetes В зависимости от задач установить Kubernetes можно разными способами. Нужно предупредить, что руководства в интернете работают не всегда, в первую очередь потому, что проект быстро развивается и многие вопросы давно упрощены. Для локальной установки рекомендуется Minikube [6], реализующий однокластерную систему, используя системы виртуализации. Другой вариант – использование исходных текстов мастер ветки [7] или bash-скрипт [8]. В случае исходных текстов тоже есть варианты: можно установить систему или, распаковав архив, просто запустить ее в однокластеровом варианте (при остановке все данные теряются): $ KUBE_ENABLE_CLUSTER_DNS=true API_HOST_IP=0.0.0.0 ↵ hack/local-up-cluster.sh

Перед этим понадобится установить Go (на нем написан K8S), etcd, cfssl и некоторые другие компоненты (баз настройки). Сам мастер кластер работает и с 2 Гб ОЗУ, но во время такого развертывания скрипт может потребовать больше памяти, даже на ПК с 8 Гб. В Linux это можно разрешить при помощи: $ sudo sysctl -w vm.overcommit_memory=1 $ sudo sysctl -w vm.swappiness=1

Процесс установки из исходных текстов рассматривать не будем, развернем кластер из репозитория. В качестве ОС используем Ubuntu 16.04 LTS.

Установка Docker Кроме специфических операций, о которых пойдет речь отдельно, все действия производятся на master и minion.

системный администратор январь-февраль 2017

Обновляем систему: $ sudo apt update $ sudo apt upgrade

Устанавливаем Docker. Добавляем официальный репозиторий Docker: $ sudo apt-key adv --keyserver ↵ hkp://ha.pool.sks-keyservers.net:80 ↵ --recv-keys 58118E89F3A912897C070ADBF76221572C52609D $ sudo vi /etc/apt/sources.list.d/docker.list deb https://apt.dockerproject.org/repo ubuntu-xenial main

Обновляем список пакетов: $ sudo apt update $ apt-cache policy docker-engine $ sudo apt install docker-engine

Здесь есть нюанс, о котором нужно знать. Текущая версия Kubernetes не поддерживает storage-driver = overlay2, и инициализация мастера в этом случае выдает ошибку. А Docker 1.13 устанавливает именно в таком варианте, если обновлять с Docker 1.11+, то все нормально. Проверить текущие настройки Docker можно командой: $ docker-engine info | grep -i storage Storage Driver: aufs

Если в ответ получили overlay2, то нужно изменить параметры запуска Docker и перезапустить сервис: DOCKER_OPTS="--storage-driver=aufs"

Вероятно, понадобится удалить подкаталог overlay. Устанавливаем дополнительные пакеты: $ sudo apt-get install linux-image-extra-$(uname -r) ↵

Администрирование linux-image-extra-virtual

Разрешаем автозапуск сервиса при загрузке ОС: $ sudo systemctl enable docker && sudo systemctl start docker

виртуализация Kubernetes master is running at https://localhost:6443 KubeDNS is running at https://localhost:6443/api/v1/proxy/ namespaces/kube-system/services/kube-dns

Настройки в консоли производятся при помощи утилиты kubectl. Например, смотрим настройки и статус кластера:

Чтобы выполнять команды Docker без привилегий администратора, добавляем текущего пользователя в группу docker:

$ kubectl cluster-info $ kubectl cluster-info dump $ kubectl get cs

$ sudo usermod -aG docker $USER

Устанавливаем add-on network, выбор зависит от ситуации, мы же используем один из самых популярных:

Устанавливаем Kubernetes Самый простой и правильный способ развертывания боевого кластера – это использование из официального репозитория Google. На всех системах кластера (master + minion) добавляем репозиторий Kubernetes:

$ kubectl apply -f https://git.io/weave-kube

После этого обязательно проверяем, что служба kubedns находится в рабочем состоянии: $ kubectl get pods --all-namespaces | grep kube-dns

$ curl -s https://packages.cloud.google.com/ ↵ apt/doc/apt-key.gpg | sudo apt-key add $ sudo vi /etc/apt/sources.list.d/kubernetes.list deb http://apt.kubernetes.io/ kubernetes-xenial main

Устанавливаем пакеты: $ sudo apt update $ sudo apt-get install -y kubelet kubeadm kubectl ↵ kubernetes-cni

Устанавливаем автозагрузку сервиса: $ sudo systemctl enable kubelet && sudo systemctl start kubelet

Инициализируем мастер (см. рис. 1). Это делается всего одной командой: $ kubeadm init

Рисунок 1. Инициализируем мастер

Опционально устанавливаем веб-интерфейс. Все настройки прописаны в YAML-файле, и его нужно лишь активировать традиционным для K8S способом: $ kubectl create -f https://rawgit.com/kubernetes/ ↵ dashboard/master/src/deploy/kubernetes-dashboard.yaml

Веб-интерфейс будет доступен на 8080-м порту: http:// localhost:8080/api/v1/proxy/namespaces/kube-system/ services/kubernetes-dashboard. Для удобства его можно пробросить iptables или настроить прокси на этот адрес (не забыв закрыть доступ паролем, если он доступен извне). Для управления кластером с другого комьютера необходимо установить kubectl и скачать файл /etc/kubernetes/ admin.conf: $ scp root@<master ip>:/etc/kubernetes/admin.conf . $ kubectl --kubeconfig ./admin.conf get nodes

Еще важный момент. По причинам безопасности в настройках по умолчанию мастер вообще не запускает ноды, чтобы разрешить это, нужно выполнить команду: $ kubectl taint nodes --all dedicated-

Подключаем minion. В процессе установки мастера будет получен токен, который используется в команде kubeadm join для подключения minion --token=4f539...0978. В качестве IP указывается адрес мастер сервера. $ sudo kubeadm join --token=f539...0978 <master ip>

Аналогично поступаем на остальных minion. Подключенные ноды на мастере можно увидеть командой: $ kubectl get nodes

Подробности (см. рис. 2): $ kubectl describe nodes

январь-февраль 2017 системный администратор

виртуализация

Управляем кластером Для управления всеми настройками K8S, а также pods, сервисами и прочим используется утилита kubectl. Все операции реализуются указанием одного из 20 ключей, список которых можем получить, введя --help или на сайте проекта [9]:

Администрирование $ kubectl create -f nginx.yaml

Если файлов много, то просто указывается каталог, в котором они находятся. Утилиты Docker при работе с K8S использовать не рекомендуется. Для выполнения команды внутри контейнера применяем kubectl exec.

$ kubectl --help

В самом простом случае настройки можно указывать в командной строке. Запустим контейнер с nginx: $ kubectl run -mynginx --image=nginx --port=80 --hostport=80

K8S сам загрузит и установит образ. Через время к nginx можно обратиться, подключившись на 80-й порт. Список IP, выданных подам:

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

В команде kubectl expose возможно использование ресурсов: pod (po), service (svc), replicationcontroller (rc), deployment (deploy), replicaset (rs). Масштабирование:

[1] Проект Docker Swarm – http://docker.com/products/dockerswarm. [2] Проект Nomad – http://nomadproject.io. [3] Проект Marathon – http://mesosphere.github.io/marathon. [4] Проект Kubernetes – https://kubernetes.io. [5] Дополнения Kubernetes – https://kubernetes.io/docs/admin/ addons. [6] Страница Minikube – https://kubernetes.io/docs/getting-startedguides/minikube/. [7] Исходные тексты Kubernetes – https://github.com/kubernetes/ kubernetes. [8] bash-скрипт для установки Kubernetes – http://get.K8S.io. [9] Параметры kubectl – https://kubernetes.io/docs/user-guide/ kubectl-overview.

$ kubectl scale deployment my-nginx --replicas=2

Ключевые>слова: Docker, контейнеры, Google, Kubernetes.

Текущее состояние репликации выводится командой kubectl get rc или kubectl get services, если создавался сервис. Выведем в расширенном формате список нодов и сервисов:

Рисунок 2. Информация о нодах

$ kubectl get pods -o yaml | grep podIP

Выставляем в качестве сервиса: $ kubectl expose deployment my-nginx --target-port=80 ↵ --type=LoadBalancer

$ kubectl get rc,services -o=wide

Отбор с учетом меток (labels): $ kubectl get services -l "app=nginx,role=master,tier=frontend"

Информация о конкретном сервисе: $ kubectl describe svc frontend

Удалить pod нельзя, он сразу восстановит работу. Нужно вначале остановить сервис, deployment ..., а потом уже удалить сам под: $ kubectl delete deployment my-nginx $ kubectl delete my-nginx-5489078-xt4 --now

Но обычно используют заранее подготовленный YAMLфайл, который позволит быстро запускать, останавливать и обновлять контейнеры. Возможно заранее прописать настройки контейнера в файле, который затем использовать при развертывании командой create:

системный администратор январь-февраль 2017

Администрирование

облачные технологии

Визитка

ЛЕОНИД ШАПИРО, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M, RCSS, RCAS-AL, shapiro_leonid@yahoo.com

Доставка приложений в корпоративном ЦОДе

и облачных средах. Часть 3. Отказоустойчивость ADC

В предыдущих статьях [1, 2] мы рассмотрели некоторые вопросы доставки приложений в корпоративном центре обработке данных, теперь имеет смысл поговорить о надежности, отказоустойчивости и высокой доступности

Этот аспект крайне важен с точки зрения обеспечения непрерывности сервиса ЦОД. ADC также может являться точкой отказа, а раз так, то необходимо предусмотреть метод обеспечения его резервирования. Традиционной схемой является использование технологии VRRP [3], поскольку ADC может рассматриваться в определенном смысле в качестве устройства L2-L3 [4], однако такой метод требует глубокого погружения в сетевые технологии от группы, занимающейся прикладными вопросами, и более сложной настройки контроллера доставки приложений. Поэтому многие производители предлагают другие варианты обеспечения непрерывности сервиса с точки зрения балансировки и нагрузки и доставки приложений. Примером такого подхода является новая технология высокой доступности, представленная компанией Radware [5], настройку которой мы и разберем в этой статье.

Технология высокой доступности Radware Alteon Любая технология высокой доступности реализуется за счет дублирования работающих устройств или виртуальных машин, то есть отказ одного компонента решения не приводит к общему отказу за счет использования второго устройства или виртуальной машины. Radware Alteon, разумеется, не исключение. Предусматривается совместная работа двух устройств, при которой одно является основным (Active), второе – резервным (Standby). Надо иметь в виду, что возможны два режима отказоустойчивости: >> Switch>Mode>– режим коммутатора; >> Service>Mode>– режим отказоустойчивости сервисов. Сравнивая традиционный метод на основе технологий VRRP с HA, можно заметить ряд преимуществ предлагаемой новой технологии, хотя, разумеется, на выбор того или иного

Рисунок 1. Включение HA и выбор режима работы

январь-февраль 2017 системный администратор

облачные технологии

Администрирование

Технология высокой доступности реализуется за счет дублирования работающих устройств

подхода также будут влиять текущая сложившаяся ситуация в ЦОДах компании и возможности по кратковременному прерыванию сервисов в период перенастройки ADC.

Switch HA mode – режим коммутатора Этот вариант характеризуется тем, что все сервисы, балансировка работы которых обеспечивается ADC, рассматриваются как единое целое, и при отказе основного устройства осуществляется полное переключение на резервное. В этом случае не рассматривается возможность индивидуального перевода какой-то задачи с активного на резервное устройство, скажем, при недоступности линии связи одного из устройств с каким-либо из серверов приложений. Мы видим четкое разделение ролей: Active, Standby, которые никогда не могут быть совмещены в рамках одного аппаратного устройства или виртуальной машины.

Еще одним важным аспектом работы в этом режиме является поведение при восстановлении в исходное состояние (Failback). Здесь возможны два подхода. >> В первом случае вернувшееся в строй исходное устройство становится резервным, и все сессии, которые были переведены на второе устройство, а также новые сессии, на нем же и остаются (режим on failure). >> Во втором случае все сессии переводятся на устройство, которое было активным на момент сбоя, или на то, чей приоритет выше (always). В общем случае первый вариант оказывается наиболее востребованным, поскольку не подразумевает дополнительного повторного переключения. Следует отметить, что рассматривать эти варианты можно только при работе балансировщика в режиме коммутатора.

Рисунок 2. Назначение floating IP

системный администратор январь-февраль 2017

Администрирование Становясь активным, резервное устройство посылает пакет Gratuitous ARP [6], тем самым сообщая о своей новой роли.

Service HA mode – режим отказоустойчивости сервисов Здесь появляется возможность группировки сервисов и рассмотрения каждой такой группы в качестве единой сущности с точки зрения высокой доступности. Разумеется, группа может состоять и из одного сервиса.

Если мы используем режим Service HA, то перевод задачи на резервное устройство произойдет только для проблемной группы сервисов, остальные останутся на исходном ADC Таким образом, в случае возникновения сбоя в составе одной группы на резервное устройство переводится только тот сервис или сервисы, которые с ней связаны. Например, на некотором ADC балансируется какая-та задача, и вдруг этот сервер теряет связь со своими серверами (real servers), в то время как другой ADC из пары такой проблемы не испытывает. Причем эта история касается лишь одной группы сервисов и никак не затрагивает другие. Что произойдет в этом случае? Если мы используем режим Service HA, то перевод задачи на резервное устройство произойдет только для проблемной группы сервисов, остальные останутся на исходном

облачные технологии ADC. То есть для части задач одно устройство может быть активным, а для другой – резервным и наоборот. Здесь также используется Gratuitous ARP, что и в предыдущем варианте.

Как это работает… и как настроить… Алгоритм настройки режима высокой доступности состоит из нескольких этапов: >> Включение режима HA, выбор режима отказоустойчивости и настройка floating IP. >> Настройка интерфейсов для информационного обмена между устройствами или виртуальными машинами. >> Настройка зеркалирования сессий (session mirroring) при необходимости. >> Настройка триггеров аварийного переключения (failover triggers) при необходимости. >> Настройка синхронизации. Включение режима высокой доступности или HA выполняется на обоих устройствах или виртуальных машинах, здесь же назначается плавающий или floating IP-адрес – виртуальный адрес, который используется совместно на обоих устройствах для обеспечения маршрутизации между клиентами и серверами, если они находятся в разных сетевых сегментах. С точки зрения настройки конфигурации это выглядит так, как показано в примере ниже (см. рис. 2). /c/l3/hamode switch /c/l3/ha/floatip 1 ena ipver v4 addr 172.16.1.210

Также выбираются роль ADC и механизм перехода в исходное состояние при восстановлении аварийной системы (см. пример в листинге 1 и на рис. 1, 2).

Рисунок 3. Зеркалирование сессий

январь-февраль 2017 системный администратор

облачные технологии Листинг 1. Выбор режима работы ADC и настройка возврата в исходное состояние при восстановлении #Настройка 1-го устройства /c/l3/ha/switch failback always pref active def 2 #Настройка 2-го устройства /c/l3/ha/switch failback always def 2

Для обеспечения возможности информационного обмена между ADC потребуется определить интерфейсы, используемые для этих целей. Минимально достаточным будет один интерфейс с каждой стороны, однако с точки зрения надежности стоит использовать по крайней мере два, что позволит резервировать heartbeat- или advertisement-интерфейс и повысить надежность работы системы. Ниже мы видим пример настройки, где в качестве peerадреса указан адрес другого устройства в отказоустойчивой паре (см. листинг 2). Обычно эта настройка выполняется еще на этапе назначения IP-интерфейсов и до включения режима высокой доступности. Листинг 2. Настройка IP-адресов #Настройка 1-го устройства /c/l3/if 2 ena ipver v4 addr 172.16.1.112 mask 255.255.255.0 broad 172.16.1.255 vlan 12 peer 172.16.1.113 descr "Interface for VLAN 12" #Настройка 2-го устройства /c/l3/if 2 ena ipver v4 addr 172.16.1.113

Администрирование mask 255.255.255.0 broad 172.16.1.255 vlan 12 peer 172.16.1.112 descr "Interface for VLAN 12"

Зеркалирование сессий возможно только при настройке работы в режиме коммутатора (см. рис. 3). В этом случае достигается Stateful Failover, то есть переключение на резервное устройство при аварии с сохранением состояния, или режим, гарантирующий прохождение трафика без какого-либо прерывания даже в случае отказа любого одного устройства или виртуальной машины в отказоустойчивой паре. В этом случае сессии активного балансировщика синхронизируются на резервном. Обычно это рекомендуется для продолжительных сессий, например для протокола FTP. Как уже упоминалось выше, в режиме сервисной отказоустойчивости этот вариант не поддерживается.

Зеркалирование сессий возможно только при настройке работы в режиме коммутатора Триггеры аварийного переключения позволяют выбрать критерии, в соответствии с которыми система определяет наступление аварийной ситуации и переключается на резервное устройство. Таковыми могут быть IP-интерфейсы, шлюзы по умолчанию, серверы, порты. Настройка по умолчанию предполагает использование только IP-интерфейсов (см. пример ниже, см. рис. 4). /c/l3/ha/switch/trigger/ifs add 2

Рисунок 4. Настройка триггеров аварийного переключения

системный администратор январь-февраль 2017

Администрирование И, наконец, финальный этап – настройка синхронизации конфигурации между устройствами или виртуальными машинами в отказоустойчивой паре. Синхронизация может осуществляться как в автоматическом, так и в ручном режимах. Часть объектов для синхронизации определена по умолчанию, другая подразумевает их включение администратором. В представленном примере настроена автоматическая синхронизация следующих модулей: фильтров, портов, шлюзов, прокси-адресов и статических маршрутов (см. листинг 3 и рис. 5). Листинг 3. Настройка параметров синхронизации #Настройка 1-го устройства /c/slb/sync autosync e prios d pips e bwm d state e gw e ddstore ena /c/slb/sync/peer 1 ena addr 172.16.1.113 #Настройка 2-го устройства /c/slb/sync autosync e prios d pips e bwm d state e gw e ddstore ena

облачные технологии /c/slb/sync/peer 1 ena addr 172.16.1.112

Как мы можем видеть, настройка режима высокой доступности для ADC Radware Alteon выполняется интуитивно понятно и не требует серьезной подготовки от администратора системы. Мы рассмотрели пример настройки в режиме коммутатора как с помощью интерфейса командной строки, так и с помощью графической консоли управления. Более подробно с настройкой высокой доступности на ADC Radware Alteon можно познакомиться в руководстве по эксплуатации системы [7]. EOF [1] Шапиро Л. Доставка приложений в корпоративном ЦОДе и облачных средах. Часть 1. Выбор ADC. // «БИТ», №3, 2016 г. – С. 30-34 (http://bit.samag.ru/archive/article/1632). [2] Шапиро Л. Доставка приложений в корпоративном ЦОДе и облачных средах. Часть 2. Основные принципы настройки ADC. // «БИТ», №9, 2016 г. – С. 40-42 (http://bit.samag.ru/archive/ article/1762). [3] Virtual Router Redundancy Protocol (VRRP) – https://tools.ietf.org/ html/rfc3768. [4] The OSI Model's Seven Layers Defined and Functions Explained – https://support.microsoft.com/en-us/kb/103884. [5] www.radware.com. [6] Gratuitous ARP – https://wiki.wireshark.org/Gratuitous_ARP. [7] Alteon Command Line Interface Application Guide. Ключевые>слова: ЦОД, ADC, Radware Alteon.

Рисунок 5. Настройка параметров синхронизации

январь-февраль 2017 системный администратор

внедрение

IP-телефония Визитка

СЕРГЕЙ БОЛДИН, системный администратор НЭК Укрэнерго, bsergey2@gmail.com

Настройка MS Lync 2013

Часть 3. Настройка дополнительных функций Рассмотрим следующие функции: парковка и перехват звонков, собрание с применением ПИН-кода

В прошлой [1] статье мы произвели основные настройки системы MS Lync 2013 для осуществления аудиовидеопереговоров, ведения переписки, обмена файлами с помощью программной клиентской части. Также осуществили интеграцию с традиционной АТС, чтобы дозваниваться сотрудникам отдаленных филиалов и не имеющим ПК или мобильных устройств. Но система Lync включает в себя немалое количество функций, которые настраиваются не в первую очередь, но могут быть очень полезны. Основные термины: > Парковка – установка звонка на паузу на одном телефоне и его восстановление на другом. > Орбита – пул номеров, из которого формируется и выдается код для снятия вызова с парковки. > Собрание – запланированная видеоконференция, особенностью которой является подключение по ссылке.

Парковка звонка Как и в традиционной телефонии, в системе Lync имеется функция Call Parking (парковка звонка), которая позволяет сотруднику поставить звонок на паузу на своем компьютере, а на другом – продолжить разговор. В этом случае придется набрать дополнительный код, который формируется случайным образом из диапазона номеров (по документации MS Lync это называется «орбита»). Звонок на выданном номере находится до тех пор, пока не будет восстановлен или не превысит время ожидания. Чтобы настроить парковку звонков [2], нужно сначала на сервере Lync 2013 в разделе Voice Routing (маршрутизация звонков), во вкладке Voice Policy (политика голосовой связи) установить флажок Enable call park (разрешить парковку вызовов), так как по умолчанию данный параметр не активирован. Затем необходимо создать диапазон номеров (орбит). Для этого заходим в раздел Voice Features (голосовые функции), вкладку CallPark (парковка вызова), жмем кнопку New (создать) и заполняем четыре поля: Name (имя), Number range (диапазон номеров), FQDN of destination server (полное доменное имя Lync-сервера), а после этого

системный администратор январь-февраль 2017

применяем настройки по нажатию на Commit (зафиксировать) (см. рис. 1). При создании диапазона номеров следует учитывать некоторые тонкости: > диапазон орбит должен быть уникальным; > первый номер диапазона не может быть больше последнего, но они могут быть равны; > первыми символами могут быть «*» или «#», в этом случае диапазон орбит должен быть больше 100; > вводимые администратором цифры должны соответствовать регулярному выражению ([\*|#]?[1-9]\d{0,7})| ([1-9]\d{0,8}). Опишем более подробно, какие номера могут попадать в диапазон относительно данного регулярного выражения [3]. Начальные символы могут быть «*» или «#» либо от 1 до 9, но не могут начинаться на 0. Если первым символом является «*» или «#», то за ним будет следовать цифра от 1 до 9, все следующие цифры могут попадать в диапазон от 0 до 9 длиною не более 7, то есть максимальная длина значения будет из 9 символов. Например, #3300, *88088, *16664444. Рисунок 1. Создание пакета в SCCM для распространения

IP-телефония Если же первым символом являться цифра, то она попадает в диапазон от 1 до 9, за которой следуют любые цифры, включая 0, длиною до 8 цифр, то есть максимальная длина значения будет из 9 цифр. Например, 4444, 200, 8880080, 123456789. После этого пользователь на десктопном клиенте может поставить звонок на парковку таким образом: в нижней части подвести мышь ко второй кнопке в виде трубки микрофоном, в появившемся окне перейти на закладку «Переключение звонка» и нажать кнопку «Приостановка» (см. рис. 2). Сформированный номер отображается непосредственно в окне разговора. Зная данный код, любой сотрудник с любого компьютера может его набрать и забрать звонок себе, а передать этот код можно, например, при помощи чата или почты. Также будет видно ФИО работника, которым был восстановлен звонок. На мобильном устройстве не получится ни припарковать звонок, ни забрать его себе, даже зная код, так как данный функционал не поддерживается. Помимо консольного управления, администратор Lync может управлять различными настройками средствами командной строки PowerShell. Например, создание нового диапазона номеров орбиты происходит, когда используется командлет NewCsCallParkOrbit: New-CsCallParkOrbit -Identity "Range Parking1" ↵ -NumberRangeStart 1 -NumberRangeEnd 9 ↵ -CallParkService b-lync01.es

а для изменения существующей орбиты поможет командлет Set-CsCallParkOrbit: Set-CsCallParkOrbit -Identity "Range Parking1" ↵ -NumberRangeStart 3 -NumberRangeEnd 28

За удаление орбиты отвечает командлет RemoveCsCallParkOrbit: Remove-CsCallParkOrbit -Identity "Range Parking1"

внедрение В командной строке PowerShell происходит и задание длительности нахождения звонка на парковке, адреса для перенаправления звонка по умолчанию, смена мелодии во время удержания звонка, чего нельзя сделать с помощью консоли и мыши. За эти действия отвечают командлеты New-CsCpsConfiguration (создание новых настроек) или Set-CsCpsConfiguration (изменение существующих настроек): New-CsCpsConfiguration -Identity site:<sitename to apply ↵ settings> [-CallPickupTimeoutThreshold <hh:mm:ss>] ↵ -[EnableMusicOnHold <$true | $false>] ↵ [-MaxCallPickupAttempts <number of rings>] ↵ [-OnTimeoutURI sip:<sip URI for routing ↵ unanswered call>]

Например, воспользуемся возможностью смены мелодии по умолчанию, при этом необходимо знать, что звуковые файлы должны быть в формате Windows Media Audio 9, 44 кГц, иметь 16-разрядность, моно, скорость 32 кбит/с. Указать иной музыкальный файл поможет командлет SetCsCallParkServiceMusicOnHoldFile (значение по умолчанию равно True): Set-CsCallParkServiceMusicOnHoldFile -Service <ServiceID where the Call Park application resides> ↵ -Content <Byte[]> $a = Get-Content -ReadCount 0 -Encoding byte ↵ "c:\share\superzvuk1.wma" Set-CsCallParkServiceMusicOnHoldFile -Service b-lync01.es ↵ -Content $a

Рассмотрим, как назначается звуковой файл более детально. Сначала с помощью командлета Get-Content считывается содержимое файла superzvuk1.wma и присваивается переменной $a. (Параметр ReadCount=0 означает, что файл нужно считать за один раз, а не строка за строкой; Encoding=byte означает, что содержимое является массивом байтов, а не звуковым файлом.) Затем командлет SetCsCallParkServiceMusicOnHoldFile указывает службу приостановки вызовов и передает содержимое переменной $a параметру Content.

Рисунок 2. Установка звонка на парковку

январь-февраль 2017 системный администратор

IP-телефония

внедрение

Подключение к ВКС по нажатию на ссылку стало более предпочтительным, нежели создание конференции

Неназначенные номера

Перехват звонка

Когда работник компании набирает номер телефона, который никому еще или уже не присвоен, то он услышит просто короткие гудки. В этом случае лучше настроить звуковое сообщение об ошибке [4] для информирования звонящего, например: «номер временно не обслуживается», «ошибка при наборе номера» и тому подобное. Такая процедура основывается только на использовании командлетов PowerShell. Если уже имеется готовый звуковой файл, то его подключить нужно так:

Данная функция позволяет переключить на себя вызов, предназначенный иному сотруднику, набрав специальный номер, и полезна, когда отсутствующему сотруднику звонят нечасто, иначе лучше настроить переадресацию. Перехват вызова основан на работе парковки звонка, но главным отличием является то, что перехват происходит до снятия трубки (без присутствия абонента-получателя), а парковка – после ее поднятия. Чтобы было проще запомнить код перехвата, его удобнее приравнять к номеру телефона сотрудника и добавить специальный символ в его наборе – «*» или «#». Например, если у коллеги из вашего кабинета внутренний номер телефона 777, то забрать себе звонок во время его отсутствия, не вставая с кресла, можно с помощью кода *777 или #777. Весь процесс настройки номеров перехвата вызова [5] происходит только средствами PowerShell и в консоли сервера Lync не отображается (см. рис. 4). Понадобится еще и утилита SEFAUtil (secondary extension feature

New-CsAnnouncement -Identity ApplicationServer:b-lync01.es ↵ -Name Range1 -AudioFilePrompt superzvuk2.wav

Если же нет такого файла, то можно указать текст, который будет воспроизведен голосом. Делается это следующим образом: New-CsAnnouncement -Identity ApplicationServer:b-lync01.es ↵ -Name Range1 -TextToSpeechPrompt "Вы ошиблись, ↵ номер набран неверно" -Language "ru-RU"

Рисунок 3. Настройка неназначенных номеров

Далее необходимо указать диапазон номеров, а также имя сервера Lync: New-CsUnassignedNumber -Identity Range1 ↵ –NumberRangeStart 200 –NumberRangeEnd 699 ↵ -AnnouncementService ApplicationServer:b-lync01.es ↵ -AnnouncementName Range1

Теперь наш результат будет отображен в консоли управления в том же самом разделе Voice Features во второй вкладке Unassigned Number (неназначенный номер) (см. рис. 3). Следует помнить, что пул номеров Call Park не должен пересекаться с пулом номеров Unassigned Number, иначе все звонки будут «поглощаться» функционалом Unassigned Number и выдаваться уже настроенное сообщение об ошибке.

системный администратор январь-февраль 2017

IP-телефония activation) [6], она устанавливается в \Program Files\Microsoft Lync Server 2013\Reskit. Стоит помнить, что диапазон номеров не должен пересекаться с уже имеющимися, абоненту можно присвоить только один код для перехвата, забирать звонок может любой пользователь Lync (даже если он не включен в группы перехвата звонков). Функция перехвата обладает рядом ограничений, она не применима к: > вызовам контакта с уровнем конфиденциальности «Друзья и семья»; > видеозвонкам; > звонкам, направляемым в группу ответа;

внедрение > звонкам, направляемым делегату; > вызовам по частной линии. Теперь перейдем от теории к практике. После установки утилиты SEFAUtil создается орбита (действия описывались в начале статьи). Для перехвата звонков используются те же параметры, как и для стандартной орбиты, но с применением -Type GroupPickup: New-CsCallParkOrbit -Identity "СallPickup" ↵ -NumberRangeStart *710 -NumberRangeEnd *790 ↵ –CallParkService b-lync01.es -Type GroupPickup

Рисунок 4. Настройка перехвата звонков

Рисунок 5. Настройка собрания в Lync Web Scheduler

январь-февраль 2017 системный администратор

IP-телефония

внедрение Вывести результат на экран можно при помощи командлета Get-CsCallParkOrbit (см. рис. 4). Далее нужно пользователю c SIP-адресом dudkin.sf@es присвоить код *777, делается это так: SEFAUtil.exe dudkin.sf@es /server:b-lync01.es ↵ /enablegrouppickup:*777

Завершающим действием является проверка работоспособности описанной функции. Для этого на цифровой панели Lync-клиента во время звонка вашему коллеге набираем *777.

Собрание Собрание – по сути, это такой же способ ведения видеопереговоров, как и конференция, но с небольшими отличиями. Самое главное, что собрание – это заранее запланированное явление, а конференция не включает в себя календарь. При создании собрания генерируется ссылка для подключения, а при создании конференции необходимо выделить участников или группу и выбрать пункт в контекстном меню. К собранию можно дозвониться со стационарного телефона, зная ПИН-код, а вот у конференции такой возможности нет. При наличии MS Exchange планирование собрания происходит с помощью почтового клиента Outlook. В нашем региональном представительстве почта не от Microsoft, но планировать собрания все же есть возможность – с помощью Lync Web Scheduler. Для этого в браузере мы набираем адрес https://b-lync01.es/scheduler, вводим учетные данные и попадаем на страницу настроек. Здесь мы заполняем основные данные – тему собрания, дату и время проведения, затем получаем сгенерированную ссылку для подключения (см. рис. 5) и рассылаем ее сотрудникам по почте или чату. Также можно выбрать выступающего (организатор, выбранные пользователи, сотрудники из моей компании, все, включая сотрудников вне моей организации) и тех, кто минует «зал ожидания» (список тот же).

Подключение к собранию с помощью телефона К собранию могут присоединиться, позвонив со стационарного или мобильного телефона, сотрудники, не имеющие установленных десктопных клиентов Lync либо находящиеся за пределами компании, либо собрание проводится с особой безопасностью, а также если участник конференции является ведущим (руководителем, организатором). Для таких случаев необходимо иметь идентифицирующий код (см. рис. 5) [7]. Такой запрос происходит из-за отсутствия в системе Lync информации о телефоне (и сотруднике). Для настройки ПИН-кода системному администратору нужно зайти в Conferencing (конференция) → Dial-in Access Number (номер для телефонного подключения), нажать кнопку New (создать) и заполнить обязательные поля: Display Number (отображаемый номер), Line URI, SIP URI, Pool (пул), Primary language (основной язык), Associated Regions (связанные регионы) (см. рис. 6). Для подключения к собранию в качестве рядового пользователя достаточно набрать указанный в приглашении номер телефона и дождаться подключения, а для организатора – нажать еще «#» и ввести ПИН-код.

системный администратор январь-февраль 2017

Достоинства: расширение возможностей видеоконференцсвязи. Недостатки: часто применяется командная строка без наличия наглядных настроек в консоли.

Мы настроили несколько полезных функций в системе видеоконференций. Для системного администратора настройка парковки и перехвата звонка может вызывать сложность из-за применения командной строки вместо дружелюбного консольного интерфейса. В крупных организациях при регулярном использовании MS Lync важность функций парковка и перехват звонка среди сотрудников только возрастает. Подключение к ВКС по нажатию на ссылку стало более предпочтительным, нежели создание конференции. EOF [1] Болдин С. Настройка MS Lync 2013. Часть 1. // «Системный администратор», №9, 2016 г. – С. 52-57 (http://samag.ru/archive/ article/3273). [2] Описание и настройка парковки вызова – http://www. useto.ru/index.php/project/177-call-parking-lync-2010, https:// technet.microsoft.com/ru-ru/library/gg399014(v=ocs.15).aspx, http://windowspbx.blogspot.ru/2012/08/step-by-step-enablinglync-server-2013.html. [3] Регулярные выражения – https://rmamyshev.wordpress.com/ 2014/02/19/outbound-routing-lync-2013. [4] Настройка неназначенных номеров – https://blog.eaglenn.ru/ nastrojka-unassigned-number-v-lync-2013, https://technet. microsoft.com/ru-ru/library/gg398522.aspx. [5] Настройка перехвата звонков – https://technet.microsoft.com/ en-us/library/jj945645.aspx, https://blogs.technet.microsoft.com/ ucru/2013/03/29/lync-2013-cu1. [6] Описание утилиты SEFAUtil – https://technet.microsoft.com/ru-ru/ library/jj945604(v=ocs.15).aspx. [7] Настройка ПИН-кода – https://technet.microsoft.com/ru-ru/library/ gg398126(v=ocs.15).aspx. Ключевые слова: функции, звонок, номер, символы, регулярное выражение, командлеты, диапазон, парковка, орбита, вызов, собрание, ПИН-код.

Рисунок 6. Настройка ПИН-кода

Базы данных

новый дистрибутив

Визитка

ОЛЕГ ФИЛИППОВ, АНТ-Информ, заместитель начальника отдела разработки, comol@mail.ru

Яндекс ClickHouse. Быстрее некуда Недавно в свободный доступ попала Open Source СУБД компании Яндекс – ClickHouse, которая обслуживает Яндекс.Метрику. Посмотрим, что это такое?

Что это такое и зачем оно нужно? Достаточно заманчивый заголовок, который говорит о чемто быстром и бесплатном, вызывает два традиционных вопроса: «Что это такое?» и «Как я могу это использовать?». Ответы на них могут быть разными в зависимости от того, к чему привык читатель. Начнем, пожалуй, с самого далекого от ClickHouse варианта – «мира Windows и MS SQL Server». Популярное мнение «чем дороже СУБД, тем она быстрее», мягко говоря, неверно в общем случае. Как минимум СУБД бывают OLAP и OLTP. Первые ориентированы на скорость получения данных, вторые – на параллельность работы при согласованности данных. Часто наиболее сложными механизмами в СУБД являются как раз функции многопользовательского доступа к общим данным. При этом данные должны в каждый момент времени оставаться согласованными. Поддержание этих механизмов требует существенных затрат. В то же время в большинстве случаев такая «защитная» согласованность данных не требуется. Если вы пишете систему обмена сообщениями или собираете информацию о кликах пользователей, или загружаете товар с ценами на сайт, у вас, по сути, и нет общего ресурса, к которому нужно разделять доступ, да и пишете вы в каждый момент времени только в одну таблицу. Для этих целей проще всего использовать более простые и быстрые OLAP СУБД. Но под OLAP мы привыкли понимать кубы, «in memory», перестроение, предварительную агрегацию данных… В современном мире все не совсем так.

В мире Big Data существуют совсем другие СУБД. И это не Microsoft SQL Server Enterprise, естественно, не PostreSQL, не IBM DB2, не Teradata и даже не Oracle Database. Большую часть Big Data-инфраструктуры (речь идет не о гигабайтах и даже не о терабайтах, скорее, ближе к петабайтам данных) обслуживают такие СУБД, как Facebook Presto [1], Google BigQuery [2], Apache Hive [3] и, конечно, HP Vertica [4]. В эту же категорию можно отнести и ClickHouse. Яндекс в своем блоге очень долго рассказывал о том, чем же их Open Source СУБД лучше других [5]. В частности, провели сравнение с HP Vertica как наиболее близким по производительности [6]. Часть этого теста приведена на рис. 1. Даже если не обращать внимания на сам Benchmark (он все-таки проведен Яндексом), обратите внимание на количество данных в датасете для анализа – 1 биллион. При этом примерное время выполнения запроса к данным – секунды. То есть выборка из таблицы, в которой биллион данных, занимает в среднем не более нескольких секунд! Теперь вспомните, на каких объемах у вас начинались проблемы при использовании СУБД MS SQL? Таблица с несколькими десятками миллионов записей уже часто требует отдельного обслуживания, секционирования и совсем нетривиальных действий. При этом вам вряд ли удастся достичь времени выборки в одну секунду. Конечно, у вас, как правило, не биллионы данных, и не нужна распределенная архитектура из десятков

Рисунок 1. Benchmark СУБД Яндекс ClickHouse и HP Vertica

январь-февраль 2017 системный администратор

новый дистрибутив или сотен серверов. Но уже на таблицах из миллионов записей разница в скорости будет весьма ощутимой. И не нужно никаких кубов, предварительной агрегации, данные попадают в выборку сразу после записи. И самое главное, если ранее подобные решения были «для избранных», потому что были или дороги, или сложны во внедрении, Яндекс сделал шаг к нам навстречу и решение для Big Data сделал «для всех». Чем же ClickHouse уникальна: > прежде всего она бесплатна. Существующие Big Dataрешения, как правило, не дешевы, что ограничивало область их применения именно в Big Data; > ClickHouse поддерживает SQL. Конечно, где-то она расширенная, а где-то урезанная, но базовые конструкции соответствуют стандарту ANSI; > ClickHouse проста в установке и настройке (есть сборка под Linux Debian); > ClickHouse достаточно хорошо документирована, что, как правило, является редкостью для открытых проектов, рожденных внутри компании [7]. Разобравшись с тем, что такое ClickHouse и зачем она нужна, дальше, наверное, нужно рассмотреть

Основные особенности СУБД ClickHouse по сравнению с «обычными» СУБД Итак, по логике вещей ClickHouse должна бы относиться к так называемым NoSQL СУБД – это определенные категории СУБД, предназначенные для решения определенного круга задач, к числу которых принято относить Big Data – работу с большими массивами данных. Но, как это ни странно, ClickHouse таки поддерживает основные конструкции языка SQL, и громко NoSQL-решением ее назвать нельзя. ClickHouse можно назвать нереляционной СУБД, т.к. реляционной модели, в классическом смысле этого слова, она не соответствует, но таблицы и связи между ними в ClickHouse есть. ClickHouse относится к так называемым столбцовым СУБД, где данные хранятся не построчно, а по столбцам. Для чего это нужно? Элементарно – в случае аналитических систем, как правило, вы имеете достаточно большие «таблицы» с аналитикой, которая доступна к использованию, но по факту в запросах используете лишь несколько конкретных аналитических разрезов. При этом в случае строковых СУБД будут выбраны все данные нужных вам строк (излишние), а в случае столбцовых – фактически только те данные, которые вам нужны (см. рис. 2). Самое интересное, что нормализация как таковая, призванная уменьшить количество читаемых в одной строке данных, в случае со столбцовыми СУБД не нужна. Это означает, что таблица из 50 и более колонок – абсолютно нормальное явление. Весьма удобно, не правда ли? Итак, ClickHouse быстрая и позволяет очень быстро обрабатывать аналитические запросы. А еще какие «плюшки» есть в этой СУБД?

Базы данных которая изначально позиционируется как присутствующая только в «крутых и дорогих» СУБД, в данном случае доступна абсолютно бесплатно. > Поддержка SQL. Для Big Data открытых решений это очень большая редкость. Как правило, в них собственный язык, который требует отдельного изучения. > Сжатие данных. Еще одна фича из мира Enterprise. Аналитическая СУБД, данные в которой к тому же могут не занимать чудовищного количества места на диске, что мы привыкли считать нормальным для OLAP-решений. Конечно, много еще чего «вкусного», но остальные возможности, так или иначе, пожалуй, присутствуют в других СУБД, в том числе и в Open Source.

Установка и настройка ClickHouse Сама установка ClickHouse проблем не вызывает. На сайте ClickHouse есть пакет для установки для Linux Ubuntu 12/14/16 [8]. Конечно, собрать из исходных кодов можно под любую ОС семейства Linux. Команды самой установки приведены ниже: $ sudo apt-key adv --keyserver keyserver.ubuntu.com ↵ --recv E0C56BD4 # optional $ sudo mkdir -p /etc/apt/sources.list.d $ echo "deb http://repo.yandex.ru/clickhouse/trusty ↵ stable main" | $ sudo tee /etc/apt/sources.list.d/clickhouse.list $ sudo apt-get update $ sudo apt-get install clickhouse-server-common ↵ clickhouse-client $ sudo service clickhouse-server start $ clickhouse-client

После установки нужно запустить сервер. Сервер автоматически использует порт 9000, естественно, это можно поменять, если нужно. По умолчанию разграничений прав доступа нет, СlickHouse вполне работает и без них. Вовне эту СУБД открывать, конечно, ни в коем случае нельзя. Имеющиеся ограничения доступа скорее нужны для ограничения собственных сотрудников, чем как защита от злоумышленника. Настройки пользователей находятся в файле users.xml, все прочие установки находятся в файле config.xml. Итак, более-менее разобрались с тем, что это такое, зачем нужно, установили, настроили – самое время попробовать что-нибудь сделать в этой СУБД. Конечно, Яндекс предлагает некоторые «Sample Data», но интереснее это сделать собственными руками.

Рисунок 2. Отличие столбцовых СУБД от строковых

Основные фичи ClickHouse > Репликация/кластеризация. Еще одной мощной и нужной особенностью ClickHouse является репликация/кластеризация, т.е. данные могут «легким движением руки» реплицироваться на произвольное количество серверов, можно даже выполнять распределенные запросы. То есть фича,

системный администратор январь-февраль 2017

Базы данных Работа с ClickHouse Для примера практической задачи давайте попробуем выгрузить в ClickHouse какой-либо существенный объем данных. У меня достаточно немного идей, в какой таблице данных могло бы оказаться реально много, – самое обширное это, пожалуй, журнал регистрации 1С. Если он включен полностью, да еще с некоторыми расширениями, то объем его за несколько месяцев уже может превысить объем самой базы. В 1С 8.3 журнал регистрации хранится в SQLite, что делает его чтение достаточно простым. В ClickHouse создается таблица: CREATE TABLE EventLog ( RowID UInt32, DataBaseName String, EventDate Date, EventDateTime DateTime, Severity UInt8, UserCode String, User String, App String, Computer String, Event String, Comment String, Metadata String, DataPresentation String, DataType Int32) ENGINE = MergeTree(EventDate, (RowID, DataBaseName, ↵ EventDate, EventDateTime), 8192);

Обратите внимание на последнюю строчку:

новый дистрибутив Стоит лишь отметить, что для работы с ClickHouse из Python сообществом разработана библиотека [9]. Но, к слову сказать, для СУБД также есть HTTP-клиент, поэтому перечень ПО, где ее можно использовать, достаточно широк.

Недостатки ClickHouse Конечно, ClickHouse, как и любой Open Source-продукт, рожденный в недрах крупной корпорации, не лишен определенных недостатков. К ним, пожалуй, можно отнести следующие: > Нет поддержки транзакционной модели. Даже на уровне отдельных движков таблиц. ClickHouse – это аналитическая СУБД, где при конкурентном доступе теоретически возможны конфликты и проблемы. В случае если потеря одной строчки из биллионной таблицы не приведет к катастрофе, это не важно, в другом случае, конечно, нужно использовать транзакционные СУБД (Oracle, DB2, MS SQL). > СУБД из мира Linux. Из Windows легким движением руки работать с ней не получится, нет даже ODBC-драйвера. В недрах проекта, конечно, рождается какое-то его подобие, но пока еще очень в зачаточном варианте. > Нельзя удалять и обновлять строки. Просто нет операций Delete и Update – ClickHouse фиксирует определенные события, которые уже потом нельзя изменять. Это, конечно, несколько ограничивает ее применение в аналитических системах, но там, где нельзя удалять, можно ведь сторнировать.

ENGINE = MergeTree

Это определение движка таблиц с параметрами. Первый параметр – указание столбца типа «Дата», который обязательно должен быть для использования данного движка. Второй – первичный ключ таблицы. Третий – гранулированность индекса, если с трудом понимаете, что это такое, оставьте значение по умолчанию – 8192. Если у вас меньше нескольких биллионов строк в таблице, вряд ли понадобится этот параметр менять. Остальные инструкции по созданию таблицы более-менее просты и ничем не отличаются от стандартного SQL. Заметьте, таблица создана одна, а не восемь, как в SQLite журнале 1С. Почему? Правильно – нормализация же не нужна. Для СУБД ClickHouse возможны разные так называемые движки таблиц, это значит, что данные в этих таблицах будут обрабатываться абсолютно по-разному. Я бы назвал данную возможность скорее наличием нескольких СУБД в одной. Так вот, то, чем Яндекс хвалится – что показывает в тестах и т.п., – это движки MergeTree и DistrbutedMergeTree, последний предназначен для реплицируемых таблиц, как следует из названия. Есть также другие производные от MergeTree движки таблиц, но они уже достаточно узкоспециализированы и предназначены скорее для использования внутри Яндекс.Метрики. Теперь осталось заполнить базу данными. Для этого проще всего написать небольшую программку, к примеру, на том же Python, которая будет читать данные из SQLite и записывать в ClickHouse. Полный исходный код данного скрипта я оставлю, пожалуй, за рамками данной статьи, потому как никакой теоретической ценности он не составляет.

Итого, СУБД ClckHouse – продукт, только недавно появившийся в Open Source, – с ним не очень просто работать, у него есть определенные недостатки, но на текущий момент времени это самая быстрая СУБД, по своим возможностям в некоторых моментах многократно превосходящая крупные промышленные СУБД. ClickHouse – не СУБД общего значения. Чем более схожа ваша задача с задачами Яндекс.Метрики, тем больше преимуществ для вас будет в использовании СУБД ClickHouse. EOF [1] Facebook Presto СУБД – https://prestodb.io. [2] Big Data СУБД от Google – https://cloud.google.com/bigquery. [3] Apache Hive – Big Data СУБД, используемая совместно с Hadoop – https://hive.apache.org. [4] HP Vertica – СУБД для анализа Big Data – http://www8.hp.com/ru/ ru/software-solutions/advanced-sql-big-data-analytics/index.html. [5] Заметка в блоге компании Яндекс о презентации ClickHouse – https://habrahabr.ru/company/yandex/blog/303282. [6] Benchmark СУБД Clickhouse и HP Vertica – https://clickhouse. yandex/benchmark.html#[1000000000,["ClickHouse","Vertica","Infin iDB","Hive"],["0","1"]]. [7] Руководство пользователя ClickHouse – https://clickhouse. yandex/reference_ru.html. [8] В разделе Download команды установки для Ubuntu – https:// clickhouse.yandex. [9] Библиотека для работы с ClickHouse из языка Python – https:// github.com/Infinidat/infi.clickhouse_orm. Ключевые слова: база данных, ClickHouse, СУБД.

январь-февраль 2017 системный администратор

инструменты Визитка ВЛАДИМИР ТИХОМИРОВ, директор по информационным технологиям СПАО «Ингосстрах», Vladimir.Tikhomirov@ingos.ru

Базы данных Визитка ВАЛЕРИЙ МИХЕИЧЕВ, эксперт Oracle, СПАО «Ингосстрах», Valery.Mikheitchev@ingos.ru

Теория управляемого хаоса в Oracle

Часть 3. Практика применения в Oracle

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

Во второй части статьи была приведена классификация хаоса на четыре вида: абсолютный хаос, искусственный хаос, объективный хаос и субъективный хаос [1], даны базовые положения по теории управляемого хаоса. Их кратко можно свести к следующим положениям: >> Сложные системы чрезвычайно зависимы от первоначальных условий, и небольшие изменения в окружающей среде могут привести к непредсказуемым последствиям, усиливая или создавая хаос. >> Управление хаосом требует затрат ресурсов. Неграмотное и не просчитанное управление искусственным хаосом может привести к негативным последствиям, в том числе к появлению нового хаоса и даже более высокого порядка. >> Грамотное управление хаосом требует наличия обратной связи на реакцию хаоса по воздействию на него ресурсов, стремящихся упорядочить хаос. Рассматривались также вопросы применения математического аппарата к теории управляемого хаоса. При этом для описания динамических хаотических процессов используются понятия фракталов и аттракторов. Фрактал (fractus – дробный) – математическое множество, обладающее свойством самоподобия, в точности или приближенно совпадающее с частью себя самого, т.е. если целое имеет ту же форму, что одна или более частей целого. В ИТ-системах фракталы находят применение для сжатия изображений (на основе существующих алгоритмов сжатия изображения с помощью фракталов), а также в системе назначения IP-адресов в сети Netsukuku и т.д. Более подробно о фракталах можно прочитать во второй части статьи [1]. В Oracle некоторой фрактальностью обладают его объекты, которые могут быть подвергнуты существенной степени сжатия, например составные индексы, таблицы, LOB (большие) объекты и т.д. Аттракторы – это состояния системы, в которые она стремится попасть из любого своего состояния. Аттракторами также часто называют предельную траекторию

системный администратор январь-февраль 2017

в фазовом пространстве, к которой стремится со временем эволюция динамической системы. То есть имеем как бы возможные варианты развития процесса, а предельная траектория (аттрактор) – это состояние системы, к которому приходит процесс в конечном итоге. Одним из важных положений управляемого хаоса является то, что сложные системы чрезвычайно зависимы от первоначальных условий и небольшие изменения в окружающей среде могут привести к непредсказуемым последствиям. При этом подчеркивается, что неустойчивость траекторий хаотических систем делает их чрезвычайно чувствительными к управлению и в силу этого существенной становится роль правильного управления хаотической системой и наличия обратной связи на реакцию управления хаотическими системами. В силу вышесказанного одно из применений указанного положения по управляемому хаосу и аттракторов в ИТсистемах – это тестирование программного обеспечения (ПО). Это может быть реализовано через создание разных вариантов работы ПО при различных начальных условиях входных переменных, а также разных внешних воздействий на ПО (например, изменения параметров инициализации, версий Oracle и т.д.). В результате моделирования множества вариантов (траекторий) будет создана программа (процедура или SQL-запрос), работающая устойчиво в реальных условиях (некий аттрактор). В перспективе аттракторы – это также шаг к автоматическому созданию ПО. Рассмотрим зависимость сложных систем (в том числе и Oracle) от первоначальных условий и изменений в окружающей среде.

Зависимость Oracle от входных параметров и условий функционирования Казалось бы, что Oracle – стройная система, в которой все упорядочено. На самом деле во Вселенной на все объекты без исключения воздействует множество сторонних сил. В частности, это положение применимо и к Oracle, в котором на процессы, как правило, воздействуют изменяющиеся

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

Применительно к Oracle к системе с субъективным хаосом можно отнести систему связей (в том числе информационных) между таблицами В силу указанных выше причин нередки случаи, когда в зависимости от вариантов значений входных данных и изменения версии Oracle могут появиться далеко не оптимальные планы выполнении SQL-запросов. Например, практика показала, что в период перехода с версии Oracle 11.2.0.3 на 11.2.0.4 или на Oracle 12c планы выполнения запросов, которые были оптимальны в предыдущей версии, порой становятся крайне не оптимальными. Особенно это проявляется при наличии во входных данных null значений. Вместе с тем null значения во входных параметрах хотя порой и создают проблемы, но могут быть использованы, например, на этапе тестирования запроса для выявления неэффективной работы запроса в случае появления во входных переменных запроса null значений. Это может быть реализовано, например, вводом в запрос в качестве переменных различных комбинаций нулевых и ненулевых значений. После каждого запуска запроса с очередной комбинацией переменных c null значениями анализируется план выполнения запроса. При этом в случае отличия плана в худшую сторону от плана, в котором все входные значения не null, производят либо модификацию запроса, либо в запрос вводится хинт (подсказка оптимизатору) для стабилизации плана выполнения. Такой подход позволяет еще на этапе создания запроса выявить неэффективную работу запроса в случае ввода в него null значений и заранее принять меры для стабилизации плана выполнения. Добавление хинта в запрос для улучшения (стабилизации) его плана выполнения может быть произведено как путем записи его в запрос с дальнейшей перекомпиляцией процедуры, в которой находится запрос, так и путем загрузкой хинта в запрос без перекомпиляции процедуры. Последнее особенно важно, когда компиляция запроса недоступна или нет на это времени, при этом могут использоваться различные приемы, например SQL plan baseline, SQL profiles и т.д. [2]. Может быть также применен хинт в запросе, возвращающий работу оптимизатора к предыдущим версиям Oracle, в которых планы выполнения были оптимальными.

инструменты Как показала практика, в Oracle 11g в этом могут помочь хинты /*+ optimizer_features_enable(’10.2.0.5’) */

или /*+ optimizer_features_enable ('11.1.0.7') */.

В целом плохо написанные SQL-запросы могут привести к хаосу в базе данных. Во второй части рассматривались вопросы применения теории хаоса к подсистемам Oracle, содержащим объективные хаотические процессы. В третьей части статьи будет продолжено рассмотрение объективных хаотических процессов, а также субъективных хаотических процессов в Oracle и искусственного хаоса в Oracle.

Объективный хаос в Oracle Ранее рассматривалась подсистема объективного хаоса, обусловленного хаотическим запуском сессий. Рассмотрены методы устранения проблем блокировок, вызванных хаотичностью запуска сессий. В продолжение темы предлагается один из подходов уменьшения влияния на Oracle хаотичности запуска сессий. Данный подход можно применять при массовом подключении сессий, например, после перезагрузки сервера Oracle. В этот момент множество сессий одновременно выполняют действия по инициализации: читают параметры, фиксируют свой статус и т.п., что может привести к взаимным блокировкам сессий, избыточной загрузке ресурсов и даже зависанию сервера. Для борьбы с этим эффектом может использоваться так называемая рандомизация, заключающаяся в случайной временной задержке запуска каждой сессии, с тем, чтобы более плавно распределить нагрузку и снизить вероятность блокировок. Одной из подсистем Oracle, где происходят объективные хаотические процессы, являются табличные>пространства> (ТП). Так, ТП основной массы таблиц и индексов постоянно изменяются, поскольку таблицы и индексы пополняются, очищаются и модифицируются. Уменьшение хаотичных процессов в ТП позволяет оптимизировать назначение данным, LOB (большие объекты) и индексам таблицы различных ТП, при этом (по возможности) с размещением их на различных носителях. Снижению хаотичных процессов в ТП способствует также использование секционирования таблиц, когда разным секциям (например, архивным и оперативным) могут назначаться разные ТП. При этом они могут находиться на разных устройствах ввода-вывода, так архивные секции – на более медленных устройствах, а оперативные – на более быстрых и более дорогих носителях. Контролировать свободное табличное пространство позволяет запрос: Select tablespace_name,round(sum(bytes/1024/1024)) free_mb ↵ from dba_free_space group by tablespace_name ↵ order by 1;

Хаотичность процессов происходит также во временных> табличных> пространствах (ВТП). Эти пространства

январь-февраль 2017 системный администратор

инструменты

Базы данных

Наличие обратной связи (через постоянный мониторинг) позволяет снизить влияние хаотичных процессов в Oracle

используются для размещения временных таблиц, выполнения сортировок, hash-операций и т.д. При этом если план выполнения запроса не эффективный, то Oracle может использовать ВТП, обращаясь в этом случае к дискам (что существенно увеличивает время выполнения запроса). Ограничить хаотичность процессов в ВТП позволяют более эффективные планы выполнения запросов, обращающихся к ВТП (например, используя сбор статистики и индексы). Рекомендуется также осуществлять контроль наличия свободного временного пространства, например, запросом: Select tablespace_name, round(free_space/1024/1024) free_mb ↵ from dba_temp_free_space;

Другой подсистемой Oracle с хаотичными процессами являются процессы, происходящие в памяти, отведенной> под> PGA: область памяти процесса, которая создается Oracle для каждого пользователя при открытии пользовательского сеанса. Поскольку PGA связана с сессий, то в силу хаотичности запуска сессий имеет место хаотичность загрузки памяти PGA. В отсутствии контроля (обратной связи) для версий Oracle ниже Oracle 12c значение PGA может в несколько раз превысить заданный параметр инициализации pga_target. Однако в Oracle 12c его рост ограничивается через параметр pgq_target_limit, отсекая процессы, у которых будет превышено лимитное значение. В любом случае целесообразно контролировать объем памяти, занимаемый всеми сессиями и конкретно каждой сессией, чтобы выявить сессии, активно поглощающие память PGA, например, через запрос: Select s.username, s.sid, s.serial#, s.osuser, ↵ round(v.value/1024/1024) pga_mb ↵ from sys.v_$sesstat v, v$statname n,v$session s ↵ where v.sid=s.sid and s.username<>'SYS' ↵ and s.username is not null ↵ and v.value/1024/1024>100 ↵ and n.name in ('session pga memory') ↵ and v.statistic#=n.statistic# ↵ order by v.value desc;

системный администратор январь-февраль 2017

Субъективный хаос в Oracle Субъективный (относительный) хаос предполагает наличие субъекта, оценивающего степень хаотичности процесса (события). Во второй части статьи приводился пример, когда на рабочем столе ученого посторонний наблюдатель может видеть только непорядок (хаос), в то время как сам ученый знает, где что находится. При этом знание о порядке размещения предметов на столе может быть как в памяти ученого, так и в виде других носителей информации. Таким образом, при субъективном хаосе имеем налицо две системы: одна содержит субъективный хаос, а вторая – это информационная система, содержащая информацию, позволяющую «увидеть» в хаосе порядок. Применительно к Oracle к системе с субъективным хаосом можно отнести систему связей (в том числе информационных) между таблицами. В этом случае, с одной стороны, имеем систему, в которой находятся объекты Oracle (таблицы), которых может быть множество и они могут быть связаны между собой каким-то образом, например первичными или вторичными ключами и т.д. При этом таблицы, как правило, имеют разное число и тип столбцов, разный занимаемый таблицей объем в байтах и могут быть расположены в разных табличных пространствах (т.е. иметь разнообразные характеристики). С другой стороны, можем иметь информационную систему, в которой будет отражена информация о связях таблицы с другими таблицами, о наименовании столбцов таблицы и их типе, а также указанные выше другие характеристики таблицы. При этом эта информационная система относительного хаоса, где указаны связи между таблицами и их характеристики, может иметь нескольких уровней. Первый уровень – это полное знание о связях всех таблиц с информацией по каждой таблице. Такой уровень информации может быть получен, например, при использовании Oracle Designer или других аналогичных инструментов. Так, программа Oracle Designer представляет собой графическую систему, отображающую связи таблиц, содержащую информацию о столбцах таблицы и прочее.

Базы данных При наличии таких инструментов типа Designer информация о таблицах содержится на магнитных носителях и может быть оперативно востребована специалистами Oracle для просмотра системы с субъективным хаосом. В этом случае тот, кто смотрит на эту систему, увидит не хаос, а упорядоченную систему.

Мониторинговая программная система Alertmonitor позволяет в круглосуточном режиме контролировать основные процессы, происходящие в Oracle Второй уровень – это более низкий уровень, когда информацию о связях таблиц и их характеристиках знают только некоторые специалисты, которые постоянно работают с этими таблицами (например, создавая процедуры и SQL-запросы). Для них остальные таблицы, кроме знакомых таблиц, будут представлять субъективный хаос. В целом в этом случае формируются группы специалистов, работающих с определенной группой таблиц, для которых эта группа таблиц составляет фрагменты упорядоченности системы, а все остальное представляет субъективный хаос. Опасность второго уровня в том, что с уходом долго работающих с группой таблиц специалистов может появиться хаос, разрушающий какую-то подсистему или даже приводящий к стагнации в работе всего Oracle.

Применение искусственного управляемого хаоса в Oracle Одним из примеров использования искусственного хаоса в Oracle является секционирование>таблиц>по>методу>hash. Как правило, если не получается секционировать по диапазону Range или List, то применяется хеш-секционирование Hash, основанное на хеш-функции (например, partition by hash (…) partitions 16). В этом случае строки таблицы равномерно распределяются между секциями на основании внутренних алгоритмов хеширования Oracle. При этом чем уникальнее значение столбца в таблице, по которому идет секционирование, тем эффективнее будет распределение данных по разделам. Таким образом, имеем алгоритм некоторого хаотичного распределения данных по секциям таблицы. При этом положительным эффектом этого метода является уменьшение вероятности блокировок, что было успешно реализовано нами. Так, одна из таблиц давала довольно много блокировок сессий между собой, а хеш-секционирование по 16 секциям существенно сняло проблему блокировок. Другие методы использования искусственного хаоса: Распараллеливание> DML> и> DDL-операций. Распараллеливание операций (в первую очередь таких, как Select, Insert, Delete, Update, а также сбор статистики по таблицам или индексам) приводит к увеличению числа сессий минимум на число заданных параллельных процессов и,

инструменты как следствие, ведет к увеличению хаотичности использования процессоров за счет привлечения при распараллеливании дополнительных процессоров. С другой стороны, это позволяет в несколько раз ускорить выполнение указанных выше операции (об этом можно прочитать в [3]). Распараллеливание>обработки>данных>через>потоки> (цепочку). Выигрыш в производительности работы процедур можно получить, если выполнять обработку данных параллельно несколькими потоками. При этом хотя мы увеличиваем число хаотичных процессов, однако получаем выигрыш в производительности. Это реализуется, например, при помощи пакета DBMS_JOB и его процедур: >> dbms_scheduler.create_program> – определяет программу в цепочке, >> dbms_scheduler.create_chain>– создает цепочку, >> dbms_scheduler.define_chain_step> – формирует шаги цепочки, >> dbms_scheduler.define_chain_rule>– определяет правило, >> dbms_scheduler.run_chain> – запускает параллельное выполнение программ.

Роль обратной связи при управлении хаосом Одно из базовых положений теории управляемого хаоса гласит, что для эффективного управления им требуется наличие обратной связи. Исходя из этого в целях уменьшения влияния хаотических процессов на работу базы данных (БД) Oracle и в целях оперативного реагирования на процессы в Oracle нами была разработана мониторинговая программная система Alertmonitor. Данная система позволяет в круглосуточном режиме контролировать основные процессы, происходящие в Oracle, при этом решать следующие задачи: >> Оперативно выявляет ошибки (в первую очередь критические) и нарастающие проблемы в БД (которые могут привести к серьезным проблемам в работе БД) с выдачей предупреждающих сообщений по электронной почте соответствующим специалистам. >> В автоматическом режиме выполняет расшифровку причин возникновения ошибок в БД с выдачей рекомендаций (по электронной почте) соответствующим специалистам для их оперативного устранения. >> В автоматическом режиме устраняет возникшие проблемы по множественным и длительным блокировкам сессий, возникших в заданный период (в основном в ночное время). >> Фиксирует результаты мониторинга в специальных таблицах для дальнейшего анализа причин возникновения ошибок (проблем) в целях выработки мер по их дальнейшему предупреждению. Система занимает небольшие ресурсы процессоров и памяти, обладая возможностью довольно быстро наращивать новые диагностические средства, при этом система проста в обращении и не требует специальной подготовки. Мониторинговая система базируется на Job Sheduler, который в автоматическом режиме запускается каждые 5 минут на всех БД. Этот Job, в свою очередь, запускает базовую процедуру, в которой находится более двух десятков мониторинговых процедур (с набором входных параметров). В силу чего для модификации или добавления новой мониторинговой процедуры достаточно скорректировать

январь-февраль 2017 системный администратор

Базы данных

инструменты и перекомпилировать только одну базовую процедуру, не останавливая работу Job. Мониторинговые процедуры решают следующие задачи: >> Первая и наиболее важная из процедур осуществляет считывание информации из файла Alert.log (файл, содержащий информацию о текущих ошибках Oracle). Ошибки и их трассировки расшифровываются (на основе специального словаря ошибок) и посылаются по электронной почте в виде рекомендации по их оперативному устранению. >> Другая важная группа процедур диагностирует наличие свободного места в табличных пространствах и при достижении минимального значения выдает администраторам по электронной почте предупреждающее сообщение (с пометкой, что это критичная ошибка). В этой же группе находится процедура, сообщающая о появившихся на данный момент «инвалидных» объектах. >> Следующая группа процедур формирует информационные сообщения: об изменениях в параметрах инициализации (очень важный момент, требующий контроля); о создании новых и удалении существующих объектов Oracle. >> Особое место занимают процедуры, информирующие о блокировках сессий и принимающие решение на автоматическое снятие взаимных блокировок [4]. Имеется так же группа процедур, которая анализирует превышение значений, заданных в параметрах инициализации, или значений, заданных на основе опыта эксплуатации БД. К ним относятся информация о превышении числа открытых курсоров и сессий, о наличии большого числа параллельных операций, повышенной интенсивности работы дисков на чтение или запись, о превышении порогового значения redo, информация о попадании схемы owner таблицы или индекса в табличное пространство system, а также об не эффективных SQL-запросах. Все процедуры пишут информацию в центральную таблицу Alertlog_error (для рассылки сообщения по электронной почте), а также пишут информацию в свои собственные таблицы для анализа ошибок в работе БД. При этом информация (в зависимости от важности и специфики) направляется различным специалистам от администраторов БД до разработчиков ПО.

Хаос и специалисты Для Oracle целесообразно также отметить, что на объективный и субъективный хаос в Oracle влияет не только уровень квалификации специалистов, обслуживающих Oracle, но и организация их работы. Как было отмечено выше, неустойчивость траекторий хаотических систем делает их чрезвычайно чувствительными к управлению. При этом если некий коллектив специалистов, работающий с Oracle, генерирует достаточное количество идей и активно их реализует, то ему труднее навязать извне какую-то другую линию поведения, и тем менее хаотичны и более качественно управляемы системы, сопровождаемые и разрабатываемые таким коллективом. О роли специалистов по уменьшению влияния хаоса на работу ИТ-систем говорит закон Уатсона: «Надежность

системный администратор январь-февраль 2017

оборудования обратно пропорциональна количеству и должности лиц, которые за это отвечают». Стоит заметить, что этот закон можно распространить не только на администраторов баз данных и технический персонал, но и на разработчиков ПО, когда надежность ПО обратно пропорциональна числу разработчиков, отвечающих за один участок. Кроме того, не только к техническому персоналу, но и к разработчикам ПО можно, вероятно, применить постулат Хорнера: опыт растет прямо пропорционально выведенному из строя оборудованию (пожалуй, и программных модулей). Замечание. Практика последних лет показала, что с появлением более мощных серверов и новых версий Oracle стало меньше проблем с блокировками сессий и обработкой ресурсоемких запросов. В этом случае у разработчиков ПО может сформироваться мнение, что мощный сервер обработает, в том числе, и «коряво» написанный запрос с плохим планом выполнения. Это может привести к ухудшению качества написания запросов и снижению квалификации разработчиков ПО и, как следствие, к увеличению вероятности хаоса с соответствующими негативными последствиями в работе Oracle. При этом, несмотря на рост мощностей Oracle, с годами растет число обращений (сессий) к Oracle и, как следствие, хаотичность запуска сессий, процедур и SQL-запросов. В силу этого вопросы исследования, анализа и контроля хаотических процессов на основе обратной связи в Oracle и ИТ-системах не потеряли и в дальнейшем не потеряют свою актуальность.

Выводы >> Теория хаоса применительно к Oracle позволяет посмотреть на проблемы в нем с системных позиций, выделяя в процессы с объективным и субъективным хаосом. >> Применение теории искусственного хаоса в Oracle позволяет повысить производительность процессов, при этом эта область еще должным образом не изучена. >> Наличие обратной связи (через постоянный мониторинг процессов, происходящих в Oracle) позволяет снизить влияние хаотичных процессов в Oracle. EOF [1] Тихомиров В., Михеичев В. Теория управляемого хаоса в Oracle. Часть 2. Вопросы применения. // «Системный администратор», №12, 2016 г. – С. 48-52 (http://samag.ru/archive/article/3339). [2] Михеичев В. Практика использования хинтов в Oracle. Подстановка хинтов в SQL-запрос без модификации запроса // «Системный администратор», №9, 2016 г. – С. 58-61 (http://samag.ru/ archive/article/3274). [3] Тихомиров В., Михеичев В. Распараллеливание операций в Oracle. Часть 1. // «Системный администратор», №4, 2016 г. – С. 48-52 (http://samag.ru/archive/article/3173). [4] Михеичев В. Мониторинг блокировок в Oracle. Часть 2. Практический опыт диагностики блокировок. // «Системный администратор», №12, 2015 г. – С. 41-43 (http://samag.ru/archive/ article/3095). [5] Михеичев В. Теория управляемого хаоса в Oracle. Часть 1. Условия и принципы применения. // «Системный администратор», №10, 2016 г. – С. 50-53 (http://samag.ru/archive/article/3294). Ключевые>слова: Oracle, ИТ-системы, теория хаоса.

Базы данных

изучаем 1С

Визитка

ИГОРЬ АНТОНОВ, руководитель отдела разработки ПО, страховая компания АО «ДальЖАСО», a@iantonov.me

Нестандартный back-end для веб-приложений

Практическое применение HTTP-сервисов в 1С:Предприятие 8 Слово «back-end» у современных разработчиков невольно ассоциируется с мейнстримовыми технологиями вроде Java, ASP .NET, PHP, Node.js. Популярный стек технологий для веб-приложений прочно укрепился в умах разработчиков, и, кажется, новичкам на этом поприще нет места. Отнюдь!

Новые инструменты приходят с неожиданных сторон и занимают уверенные позиции в новых нишах. Взять, к примеру, известную всем платформу 1С:Предприятие 8 – современная среда разработки бизнес-приложений различного масштаба. Платформа развивается не первый год, и за это время с ее помощью было создано большое количество конфигураций, успешно решающих различные задачи бизнеса. Платформа относительно недорога в лицензировании, обладает богатым инструментарием для разработки и хорошо подходит как для небольших проектов, так и для огромных, ориентированных на автоматизацию крупнейших корпораций. Если раньше 1С:Предприятие больше ассоциировалось со словом «бухгалтерия», то сегодня это в первую очередь платформа-конструктор для разработки самых разнообразных приложений, нацеленных на работу в гибридной среде. Под гибридной средой подразумевается стек поддерживаемых операционных систем, способных выполнять решения, разработанные с помощью платформы 1С:Предприятие. Если раньше вариант был по факту один – Windows (шаманства с Wine считать не будем), то сегодня список систем назначения существенно расширился. За годы развития платформа научилась работать в Web, Linux, macOS, Android и iOS. На страницах журнала мы поднимали вопрос разработки мобильных приложений с помощью платформы 1С:Предприятие, а также разбирали смежные технологии. В рамках этого материала мы рассмотрим вопросы применения платформы в роли серверной части (back-end) для создания веб-приложений. Это может звучать странно, особенно для разработчиков, привыкших к типичному набору технологий для решения подобных задач, однако практика показывает, что не всегда требуется падать в омут популярных технологий, чтобы разработать корпоративное веб-приложение, ориентированное на строго определенную категорию пользователей.

1С:Предприятие на сервере Что представляет собой серверная платформа для разработки веб-приложений? Как правило, это язык

программирования, веб-сервер и СУБД. Веб-сервер принимает пользовательские запросы, перенаправляет их на соответствующее приложение, которое, в свою очередь, знает, как их обработать. Одним из популярных решений подобного класса задач давно является LAMP (Linux, Apache, MySQL и PHP). А что мешает нам использовать вместо MySQL и PHP возможности платформы 1С? Она прекрасно дружит с вебсервером Apache: проверенный годами веб-клиент – лишнее тому подтверждение. О системе хранения данных говорить и вовсе не приходится – платформа изначально была ориентирована для решения задач хранения и обработки данных. С языком программирования тоже все ясно – он развивается и пригоден для решения самых разнообразных задач. Пожалуй, вопрос упирается лишь в обработку клиентских http-запросов. Платформа должна уметь принимать клиентские запросы, разбирать их и возвращать ответы. Актуальные версии платформы 1С:Предприятие 8 позволяют элегантно решать подобные задачи с помощью объекта метаданных типа HTTP-сервисы.

Все «за» и все «против» При рассмотрении платформы 1С:Предприятие в качестве серверной части веб-приложения возникает резонный вопрос: «Зачем?» Для чего заморачиваться с еще одним инструментом, если их и так уже много? Замечание уместное, но ответ всегда зависит от контекста применения. Да, платформа 1С:Предприятие научилась решать изначально не свойственные для нее задачи, но никто не говорит, что пора забросить в чулан другие решения и уж тем более переписывать существующую кодовую базу. К новому инструменту стоит приглядеться при решении новых специфичных задач. Расскажу немного о своем опыте. В нашей компании небольшая команда разработчиков, и все специализируются на разработке под платформу 1С:Предприятие 8. Ребята знают стек технологий от 1С, прекрасно ориентируется в MS SQL-сервере, но не имеют весомого багажа знаний по веб-технологиям.

январь-февраль 2017 системный администратор

Базы данных

изучаем 1С

Платформа 1С:Предприятие 8 позволяет элегантно решать задачи обработки клиентских http-запросов

За годы работы создано несколько корпоративных решений как для совместного применения с партнерами (географически распределенные приложения), так и для внутренних нужд компании. В свое время мы отдали предпочтение платформе от 1С за ее распространенность, доступность и гибкость. Мода на веб-сервисы и предоставление услуг в электронном виде продолжает набирать обороты, и компании, специализирующиеся целиком на офлайн-услугах, хотят плавно войти в веб. Учитывая специфичность предоставляемых услуг и отсутствие общего понимания трансформации бизнеса в интернет, компании бывают не готовы сразу инвестировать в разработку полноценного веб-приложения. Это рискованное и чересчур затратное мероприятие. Совсем другое дело, когда команда может создать прототип будущего приложения, протестировать его на реальных пользователях и после этого принять решение о целесообразности разработки актуальных для веба технологий. Не стоит думать, что функционал платформы (в контексте веб-приложения) ограничивается лишь быстрым прототипированием серверной части. Вовсе нет, созданные прототипы вполне могут превратиться в полноценные приложения и успешно решать поставленные задачи 24/7. К тому же это не единственный вариант применения механизма HTTPсервисов платформы.

Применяемый в качестве стандарта формат выгрузки CommerceML сильно раздут и не совсем пригоден для оперативных обменов. HTTP-сервисы легко оптимизируют подобные процессы и предоставят возможность вебприложению самостоятельно запрашивать необходимую информацию из базы 1С. Например, после оформления продажи интернет-магазин может делать запрос к 1С и получать порцию необходимой информации в лаконичном JSON-формате. Удобно и быстро. Я уже молчу, что на разбор JSON требуется значительно меньше системных ресурсов на сервере в отличие от монструозного XML.

Модернизация обменов

Рисунок 1. Дизайн формы записи

Отказ от стандартных клиентов Типовой веб-клиент – далеко не самое быстрое и удобное решение. Стандартный фронт, генерируемый вебклиентом 1С, очень тяжел как в плане ресурсов, так и трафика. Он подходит к использованию далеко не во всех случаях. HTTP-сервисы элегантно решают подобные проблемы – 1С:Предприятие остается жить на сервере, а клиентская часть переезжает на актуальные для веба технологии (HTML/CSS/JavaScript). В некоторых случаях HTTP-сервисы могут стать единственной возможностью для предоставления доступа

За свою карьеру работы разработчиком мне довелось написать десятки «переносок» данных для всевозможных информационных систем. Технологий и форматов для обмена данными множество, но в мире 1С долго господствовали обмены через файлы выгрузки/OLE. Появление Web/HTTPсервисов существенно расширяет сценарии создания обменов с внешними информационными системами. Представьте, вам требуется оперативно обмениваться данными (например, остатками) с интернет-магазином. По умолчанию обмен с интернет-магазином выполняется в стандартном режиме – через формирование файлов с информацией для обмена и последующей их выгрузкой на север.

системный администратор январь-февраль 2017

Базы данных к информационным базам, работающим в режиме обычного приложения. Их нельзя опубликовать в вебе стандартными средствами, поэтому организация доступа через легкие самописные клиенты может остаться единственной возможностью переноса ИБ в онлайн. Нужны примеры? Хорошо, представим, что вам потребовалось вынести определенный функционал конфигурации в онлайн. Формирование специфичных отчетов, оперативный мониторинг показателей – все это легко решить посредством HTTP-сервисов. В нашей компании мы смогли таким образом предоставлять удаленным сотрудникам всевозможную отчетность без полного доступа к базе. Избавили коллег от необходимости устанавливать отдельные клиенты, а просто сверстали адаптивный сервис, напрямую обращающийся к корпоративной ИБ.

Практическая сторона вопроса Для демонстрации возможностей HTTP-сервисов создадим небольшое приложение – отдельную конфигурацию, умеющую принимать и отправлять HTTP-запросы/ответы. Внутренние механизмы платформы развиваются крайне быстро, поэтому рекомендую для демонстрации использовать актуальную версию 1С:Предприятие. На момент написания статьи таковой была 8.3.9.2033. При необходимости обновляйте версию платформы и создавайте новую информационную базу данных. В рамках статьи разработаем приложение для ведения корпоративной новостной ленты, позволяющей пользователям компании заходить на внутренний сайт и читать новую корпоративную информацию. Сделаем упор на серверную часть и создадим многофункциональный HTTP-сервис. Он будет отвечать за формирование новостной ленты на сервере и предоставлять дополнительное API (добавление новостей, передача ленты в JSON и т.д.). Полную версию приложения, а также вспомогательные файлы вы найдете в исходниках в статье.

Конфигурация Создадим новую конфигурацию и добавим в нее несколько объектов метаданных.

изучаем 1С Потребуются: >> Подсистема>«Новости».> Активируем для нее отображение в командном интерфейсе. Подсистема необходима для служебных целей, в нее будут входить все остальные объекты метаданных. >> Справочник> «КатегорииНовостей».> Дополнительные реквизиты у справочника делать не будем. Просто включим в единственную подсистему. Его роль будет ограничиваться определением новостных разделов (категорий). >> Регистр>сведений>«НовостиКомпании».> Регистр будет хранить всю новостную ленту. Для удобства ввода информации рекомендуем уделить немного внимания дизайну формы записи (см. рис. 1). Для регистра «НовостиКомпании» потребуется определить два измерения: >> ИдентификаторНовости>(Строка,>36>символов)> – уникальный идентификатор отдельно взятой записи. >> НовостнойРаздел> (СправочникССылка.КатегорииНовостей)> – ссылка на элемент справочника «Категории новостей». Заголовок новости, содержание и дату публикации будем хранить в ресурсах: >> Заголовок (Строка, 150 символов). >> ДатаПубликации (Дата и время). >> Содержание (Строка, 800 символов). Установим флаг «Многострочный режим». Конфигурация в работе продемонстрирована на рис. 2. Для удобства тестирования сразу добавим в регистр демонстрационные публикации (см. рис. 3, 4). Вернемся в конфигуратор и добавим в соответствующий раздел дерева метаданных первый объект типа HTTPсервис. Назовем его «Новости» (см. рис. 5) и укажем «Корневой URL». Поскольку сервис отвечает за отдачу новостной ленты, корневым URL определим news. В окне конфигурирования HTTP-сервиса (см. рис. 5) перейдем на вкладку «Шаблоны URL» и добавим новый шаблон. Шаблоны URL позволяют определить пути действиям.

Рисунок 2. Конфигурация в режиме Предприятие

январь-февраль 2017 системный администратор

Базы данных

изучаем 1С Первый шаблон назовем «ПоследниеНовости», в свойстве «Шаблон» (описываем адрес ресурса) укажем /api/list/{count}. Таким образом, путь к получению последних n-новостей будет выглядеть так: http://<АдресСервера>/ sysadm/hs/news/api/list/10. Разберем ссылку по сегментам: >> Адрес>сервера.>В рамках примера применяется Apache, установленный на localhost. >> sysadm> – имя опубликованной информационной базы. Задается во время публикации веб-клиента/HTTP-сервисов в разделе «Администрирование → Публикация на веб-сервере». >> hs> – служебный атрибут, позволяющий системе определить, что обращение идет именно к HTTP-сервису. >> news>– корневой URL HTTP-сервиса. >> api/list/10>– заданный шаблон URL.

Листинг 2. Реализации функции «ПреобразоватьСтруктуруДанныхВJSON»

Особое внимание следует обратить на последний сегмент URL – шаблон. Помните, при создании шаблона мы указали api/list/{count}? Фигурные скобки относятся к специальным символам формирования шаблона и подразумевают наличие непустых символов между ними. В нашем случае мы требуем от пользователя указания числа – количество выводимых новостей. При обработке пользовательского запроса мы сможем получить значение этого параметра, обратившись по идентификатору count. Фигурные скобки – не единственные специальные символы для формирования шаблонов. Вы также можете использовать символ «*». Он используется только в конце строки описания шаблона и подразумевает возможность указания любого количества сегментов url или их отсутствия. Например: шаблон /api/* будет соответствовать и /api/main, и /api/ superapi/, и т.д. Теперь добавим к созданному шаблону метод и реализуем в нем обработчик события для обработки запроса клиента. Именовать метод обработки запроса можно как угодно, но рекомендуется в качестве имен использовать название HTTP-методов. Например: GET, POST, PATCH, DELETE и т.д. Итак, добавляем к шаблону «ПоследниеНовости» метод GET, в свойствах задаем HTTP-Метод (GET) и создаем обработчик события. Платформа автоматически сгенерирует заготовку функции с именем «ПоследниеНовостиGET». Вполне удобное название, позволяющее быстро сориентироваться в модуле с кучей однотипных функций. В тело функции переписываем код из листинга 1.

Рисунок 3. Заполнение справочника «Категории новостей»

Функция ПреобразоватьСтруктуруДанныхВJSON(СтруктураДанных) ↵ Экспорт ЗаписьJSON = Новый ЗаписьJSON; ЗаписьJSON.УстановитьСтроку(); ЗаписатьJSON(ЗаписьJSON, СтруктураДанных); РезультатКонвертацииВJSON = ЗаписьJSON.Закрыть(); Возврат РезультатКонвертацииВJSON; КонецФункции

В начале первого листинга выполняется выборка новостей в соответствии с запросом клиента. Желаемое количество новостей определяется параметром count (мы указали его при создании шаблона). Все параметры передаются в виде строк, поэтому не забываем перед использованием привести к нужному типу.

Рисунок 4. Добавление новой публикации

Листинг 1. Реализация функции «ПоследниеНовостиGET» КоличествоНовостей = Число(Запрос.ПараметрыURL["count"]); КонтекстРегистра = РегистрыСведений.НовостиКомпании; СписокНовостей = КонтекстРегистра.ПолучитьПоследниеНовости( ↵ КоличествоНовостей);

Рисунок 5. Создание нового HTTP-сервиса

СписокНовостейJSON = Хелперы. ↵ ПреобразоватьСтруктуруДанныхВJSON(СписокНовостей); Ответ = Новый HTTPСервисОтвет(200); Ответ.Заголовки.Вставить("Content-Type", "application/json"); Ответ.УстановитьТелоИзСтроки(СписокНовостейJSON, ↵ КодировкаТекста.UTF8, ↵ ИспользованиеByteOrderMark.НеИспользовать); Возврат Ответ;

системный администратор январь-февраль 2017

Базы данных Стоит обратить внимание, что параметры передаются «как есть», т.е. никаких встроенных механизмов проверки на опасное содержимое нет. В реальных проектах необходимо обязательно планировать фильтрацию входящих данных и принудительно отсекать опасное содержимое, способное привести к различным атакам (SQL Inj и т.д.). Далее обращаемся к функции «ПолучитьПоследниеНовости()», описанной в модуле менеджера регистра сведений «НовостиКомпании». Функция запросом выбирает из регистра требуемое количество новостей и возвращает результат в виде массива структур. Я не стал приводить код этой функции, т.к. это типичная выборка данных в 1С, можете посмотреть его в исходниках к статье. Хорошо, массив данных получен. Теперь требуется преобразовать его в JSON, вставить в объект типа «HTTPСервисОтвет» и вернуть клиенту. В платформе 1С:Предприятие уже давно имеются встроенные методы для работы с JSON. Для большего удобства и создал в конфигурации общий модуль и в нем описал функцию-обертку «ПреобразоватьСтруктуруДанныхВJSON» (см. листинг 2). На вход она принимает структуру или массив структур и возвращает строку в JSON-формате. Выполнив преобразование в JSON, эстафетную палочку перенимает объект типа «HTTPСервисОтвет». Во время инициализации объекта мы передаем код состояния HTTP. Спецификация протокола выделяет пять групп кодов состояния: >> 1ххх (информационные), >> 2ххх (успешно),

изучаем 1С >> 3ххх (перенаправление), >> 4ххх (ошибки клиента), >> 5ххх (ошибки сервера). Каждая группа включает несколько кодов состояний, и подробнее с ними вы сможете ознакомиться в соответствующем RFC. Поскольку мы готовы отдать клиенту документ (JSON), за которым он обратился, передаем код 200 – запрос выполнен успешно. Болванка HTTP-ответа готова, и остается указать тип контента, который будет передан клиенту. По этому параметру браузер клиента сможет определить и выбрать правильную стратегию обработки полученных данных. Для JSONконтента применяется application/json. Последним действием перед отправкой ответа клиенту будет вызов метода «УстановитьТелоИзСтроки» у объекта ответа. В качестве параметра он принимает данные, которые требуется вставить в HTTP-ответ.

Рендеринг на сервере С получением и обработкой простых запросов мы разобрались. Теперь рассмотрим еще один полезный кейс – рендеринг на сервере. Представим, что нам требуется отдавать данные не просто в JSON, а в виде полноценно сверстанной веб-страницы. Рассмотрим наиболее простое решение. Для начала необходимо подготовить заготовки html/css-файлов – сделать верстку. Подробно рассматривать этот процесс не будем, т.к. тема выходит за рамки статьи.

Рисунок 6. Результат передачи данных в JSON-формате

январь-февраль 2017 системный администратор

Базы данных

изучаем 1С Для ускорения процесса верстки я воспользовался CSSфреймворком skeleton [1] и без лишних изысков накидал структуру страницы будущей новостной ленты (см. рис. 7). Все необходимые внешние ресурсы (CSS, JS) размещены в соответствующей директории веб-сервера. Мы договорились, что будем формировать страницу на сервере, поэтому каким-то образом нам надо перенести разметку HTML-документа на сервер. Опять же есть несколько способов: скопировать HTML-код страницы и поместить его в общем макете или брать напрямую из доступной директории. Выбор способа зависит от окружения. В примере будем ориентироваться на первый вариант – создадим общий макет типа «Текстовый документ» и назовем его «НовостнаяЛента». Поместим в этот макет разметку страницы и в области вывода новостной ленты вставим условную метку {{news}} (см. рис. 8). При формировании html-документа мы будем искать метку и вместо нее вставлять сгенерированный html-код. Листинг 3. Разметка новостной публикации <div class=""news-item""> <h3 class=""news-item__title"">%1 / %2</h3> <div class=""news-item__text""><p>%3</div> <div class=""news-item__date"">%4</div> </div> <hr>";

Листинг 4. Функция «ПримерРендерингаНаСервереGet» МакетСтраницы = ПолучитьОбщийМакет("НовостнаяЛента"); СодержимоеМакета = МакетСтраницы.ПолучитьТекст(); ДокументДляПодстановки = Новый ТекстовыйДокумент; // Получение публикаций в СписокНовостейДляПубликации //ШаблонЭлемент = см. листинг 3. Для Каждого ЭлементНовости Из СписокНовостейДляПубликации Цикл НоваяНовость = СтрШаблон(ШаблонЭлементаНовость, ЭлементНовости.НовостнойРаздел, ЭлементНовости.Заголовок, ЭлементНовости.Содержание, ЭлементНовости.ДатаПубликации ); ДокументДляПодстановки.ДобавитьСтроку(НоваяНовость); КонецЦикла; СодержимоеМакета = СтрЗаменить(СодержимоеМакета, ↵ "{{news}}", ДокументДляПодстановки.ПолучитьТекст()); Ответ = Новый HTTPСервисОтвет(200); Ответ.Заголовки.Вставить("Content-Type","text/html; ↵ charset=utf-8"); Ответ.УстановитьТелоИзСтроки(СодержимоеМакета, ↵ КодировкаТекста.UTF8, ↵ ИспользованиеByteOrderMark.НеИспользовать); Возврат Ответ;

Из-за объема кода мне пришлось оптимизировать листинг 4, поэтому при переписывании кода обращайте внимание на комментарии и исходный код примеров.

Рисунок 7. Базовая верстка страницы

системный администратор январь-февраль 2017

Базы данных В листинге 3 приведена разметка одной новостной публикации. Я ее поместил в строковую переменную и расставил метки (%1, %2 и т.д.) для дальнейшей подстановки значений с помощью встроенной функции «СтрШаблон()». Подготовив шаблон, можно приступать к получению данных из базы для вывода и начинать компоновку нашей страницы. Поскольку объем новостных публикаций может быть совсем немалым, все сформированные шаблоны одной публикации помещаются в отдельный текстовый документ. Как только текстовый документ с шаблонами будет полностью готов, нам необходимо заменить им метку {{news}}, определенную в макете (заменяем с помощью «СтрЗаменить()»). Отправку полностью сформированного HTML-документа выполняем с помощью уже знакомого объекта типа «HTTPСервисОтвет». Единственное отличие от прошлого примера – в отправляемом заголовке. Для HTML-документов указываем text/html. Посмотреть получившуюся страницу можно на рис. 9.

Рендеринг на клиенте Рендеринг на самом сервере удобен далеко не всегда. Рано или поздно может возникнуть необходимость собирать страницы прямо на клиенте. С точки зрения программирования решать подобные задачи проще и сложнее одновременно. Легче в плане написания кода на 1С – достаточно подготовить данные в JSON и отправить их клиенту. Сложность заключается в написании кода клиентской части. Тут одними знаниями HTML/CSS не обойтись и придется прибегнуть к помощи JavaScript. Рисунок 8. Переносим верстку в макет

изучаем 1С Вторая сложность – развертывание решения. Разработчик должен написать клиентский код для отправки запросов в информационную базу данных. Задача достаточно тривиальная, но при разнесении на разные домены/хосты придется решить ряд встречных вопросов: кроссдоменные запросы, авторизация в 1С и т.д. Полный пример формирования страницы на клиенте (он достаточно большой) вы сможете посмотреть в исходниках к статье. Здесь же, в листинге 5, я привел код обработки JSON-массива с последующим формированием DOMдерева. Листинг 5. Пример рендеринга на клиенте function renderNews(data) { var newNewsItemContainer = ↵ document.createDocumentFragment(); data.forEach(function(item) { renderNewsItem(item, newNewsItemContainer); }); }

newsContainer.appendChild(newNewsItemContainer);

function renderNewsItem(item, container) { var newElement = cloneElement.cloneNode(true); newElement.querySelector('.news-item__title'). ↵ textContent = item.НовостнойРаздел + " / " + item.Заголовок; newElement.querySelector('.news-item__text p'). ↵ textContent = item.Содержание; newElement.querySelector('.news-item__date'). ↵ textContent = item.ДатаПубликации; container.appendChild(newElement); return newElement; }

Листинг 6. Описание шаблона в HTML <template id="news-item-template"> <div class="news-item"> <h3 class="news-item__title"></h3> <div class="news-item__text"><p></p></div> <div class="news-item__date"</div> </div> <hr> </template>

Процесс формирования страницы на клиенте условно можно разбить на несколько этапов: отправка запроса к серверу, получение данных в формате JSON и последующая их обработка. Перед тем как просить данные у сервера (в нашем случае им выступает 1С:Предприятие), в HTMLдокументе необходимо подготовить разметку. Правильнее всего сделать это в шаблоне (см. листинг 6). Данные с сервера запрашиваются при помощи Ajaxзапроса. Он выполняется либо стандартными средствами JavaScript, либо через какую-нибудь обертку в виде jQuery. Получив данные с сервера, в бой вступает функция renderNews. Ее цель – перебрать все элементы массива (новости), сформировать новый html-элемент и вставить его в дерево DOM. Эту операцию удобнее вынести в отдельную функцию – renderNewsItem. В ней происходит копирование шаблона и вставка данных из полученного элемента.

январь-февраль 2017 системный администратор

изучаем 1С

Передача данных с клиента на сервер Теперь посмотрим на обратную задачу, представим, что нам потребовалось предоставить пользователю возможность заполнения форм и отправку их на сервер. Со стороны платформы действия сводятся к получению и записи данных от клиента в информационную базу. Все подобные задачи решаются аналогичным путем – создается либо отдельный сервис, либо дополнительные шаблоны. В демонстрационной конфигурации создан отдельный шаблон для обработки данных методом POST. Со стороны клиента достаточно описать html-форму (см. тег <form>) или, если требуется нестандартная отправка, реализовать все с помощью Ajax. Пример обработки запросов для добавления новых новостей приведен в исходниках к статье.

Проксирование запросов При активном применении технологии HTTP-сервисов в 1С:Предприятие у вас рано или поздно возникнет вопрос разнесения серверных компонентов. Вполне логично, что серверная часть может располагаться в ЦОД компании, а клиентская – где-то на бескрайних просторах интернета. Повысить безопасность и разделить нагрузку поможет проксирование запросов. Решить подобную задачу возможно как с помощью готовых программных средств (например, при помощи функции перенаправления в nginx), так и самостоятельно, написав необходимые обертки на каком-нибудь альтернативном языке.

Базы данных Выбор решения зависит от задачи, и зачастую проще воспользоваться возможностями готовых продуктов. Если использовать готовый продукт по условиям задачи невозможно, то следует посмотреть в сторону различных оберток для обработки HTTP-запросов. Они есть для каждого языка программирования, ориентированного на вебразработку. Например, в PHP для этого прекрасно подходит пакет GuzzleHttp [2]. В его арсенале есть все необходимое для обработки и отправки HTTP-запросов/ответов. Если ваш выбор – серверный JavaScript, то в этом случае стоит обратить внимание на Express.js [3].

Платформа 1С:Предприятие с каждым годом становится все более универсальным инструментом для разработки бизнес-приложений. Горизонт применения платформы расширяется, и это не может ни радовать. Да, не все новинки дотягивают до уровня продвинутых инструментов, но зачастую их возможностей хватает для закрытия потребностей средних компаний. Простота применения и количество кейсов использования технологии HTTP-сервисов – лишнее тому подтверждение. EOF [1] CSS-фреймворк Skeleton – http://getskeleton.com. [2] Пакет GuzzleHttp – https://github.com/guzzle/guzzle. [3] Проект Express.js – http://expressjs.com/ru. Ключевые>слова: разработка, HTTP, 1C, веб-приложение.

Рисунок 9. Формирование страницы на сервере

системный администратор январь-февраль 2017

Базы данных

изучаем 1С

Визитка

КИРИЛЛ ТКАЧЕНКО, инженер 1-й кат., ассистент, аспирант ФГАОУ ВО «Севастопольский государственный университет», tkachenkokirillstanislavovich@gmail.com

Применение в 1С

индуктивного вычисления функций

Использование в программах на внутреннем языке программирования 1С индуктивного вычисления функций на пространстве последовательностей

Как верно отмечает Алексей Вторников [1], «только решение сложных задач способно поднять профессиональный уровень программиста». В частности, в процессе обработки больших объемов финансово-экономической информации часто требуется выполнять повторяющиеся действия, а именно накопление и последующий алгебраический расчет. Например, в тех случаях, когда при увеличении объема на один элемент необходимо повторить трудоемкие, затратные операции накопления. Для решения некоторых таких задач подходят методы функций на пространстве последовательностей. В учебнике [2] дается описание мощного формального аппарата этих функций. В задачнике [3] этот способ применяется для решения ресурсоемкой олимпиадной задачи за один проход.

Рассмотрим решение ряда логически взаимосвязанных задач на встроенном языке 1С Метод индуктивного вычисления функций на пространстве последовательностей нашел свое отражение в ряде учебных пособий, монографий, изысканий отечественных и зарубежных авторов (в частности, например, [4]). Но применительно к системам 1С, платформам и конфигурациям он представлен слабо. Малоизвестны решения задач обработки информации с использованием в 1С функций на пространстве последовательностей. Рассмотрим решение ряда логически взаимосвязанных задач на встроенном языке 1С методом функций на пространстве последовательностей.

Краткие теоретические сведения об индуктивном вычислении функций В открытых источниках в подавляющем большинстве случаев используется следующая система обозначений [2, 4]:

>> A+> – подмножество неотрицательных чисел базового множества A; >> X – дискретное множество, называемое алфавитом; > – простран>> ство всех конечных последовательностей множества X; >> Δ ∈ Ω>– пустая последовательность; >> Ωk(X) ≡ Ωk>– Ω в случае n≥k; >> Ω*X → Ω> – добавление элемента в конец последовательности. Функция F:Ω → Y называется индуктивной, если для вычисления F(ω*x) необходимо знать F(ω) и x.

Программные реализации вычисления индуктивных функций в 1С Например, F(ω) = «количество элементов последовательности», то есть F:Ω → Z+, и вычисляется как F(ω*x) = F(ω)+1. Программно вычисление количества элементов последовательности может быть оформлено следующим образом: Листинг 1. Вычисление количества элементов последовательности Функция ЧислоЭлементовПоследовательности(ω) Перем fω, i; fω = 0; Для i = 0 По ω.Количество() - 1 Цикл fω = fω + 1; КонецЦикла; Возврат fω; КонецФункции

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

январь-февраль 2017 системный администратор

Базы данных

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

а затем происходит циклическое повторение:

Иначе

fω2 = ω[1];

fω1 = ω[1]; fω2 = ω[0]; КонецЕсли; Для i = 2 По ω.Количество() - 1 Цикл x = ω[i]; Если (fω1 <= fω2) И (fω2 <= x) Тогда fω2 = x; ИначеЕсли (x <= fω1) И (fω1 <= fω2) Тогда fω1 = x; КонецЕсли; КонецЦикла; Возврат Новый Структура("Минимальное, ↵ Максимальное", fω1, fω2); КонецФункции

Далее в листинге 3 приводится решение второй обозначенной задачи. Вновь вначале выполняется начальная инициализация: Используются скалярные переменные для хранения и обработки кортежа 〈f(ω)1, f(ω)2〉, а именно fω1 и fω2. Возвращаемый функцией результат оформляется в виде структуры, чтобы существовала возможность обращения к отдельным полям структуры как именованным свойствам объекта. Листинг 2. Нахождение минимального и максимального значений последовательности Функция МинимальноеИМаксимальноеЗначения(ω) Перем fω1, fω2, x, i; Если ω[0] <= ω[1] Тогда fω1 = ω[0];

системный администратор январь-февраль 2017

а затем происходит повторение расчетов в цикле:

Базы данных

изучаем 1С Сообщить("ЧислоЭлементовПоследовательности " + ↵ ЧислоЭлементовПоследовательности(ω)); Рез = МинимальноеИМаксимальноеЗначения(ω); Сообщить("МинимальноеИМаксимальноеЗначения " + ↵ Рез.Минимальное + " " + Рез.Максимальное);

Опять используются скалярные переменные для хранения и обработки кортежа 〈f(ω)1, f(ω)2, f(ω)3〉, а именно fω1, fω2, fω3. В свою очередь, возвращаемый функцией результат также оформляется в виде структуры. Листинг 3. Нахождение трех наибольших значений последовательности Функция ТриНаибольшихЗначения(ω) Перем fω1, fω2, fω3, x, i; Если (ω[0] <= ω[1]) И (ω[1] <= ω[2]) Тогда fω1 = ω[0]; fω2 = ω[1]; fω3 = ω[2]; ИначеЕсли (ω[0] <= ω[2]) И (ω[2] <= ω[1]) Тогда fω1 = ω[0]; fω2 = ω[2]; fω3 = ω[1]; ИначеЕсли (ω[1] <= ω[0]) И (ω[0] <= ω[2]) Тогда fω1 = ω[1]; fω2 = ω[0]; fω3 = ω[2]; ИначеЕсли (ω[1] <= ω[2]) И (ω[2] <= ω[0]) Тогда fω1 = ω[1]; fω2 = ω[2]; fω3 = ω[0]; ИначеЕсли (ω[2] <= ω[0]) И (ω[0] <= ω[1]) Тогда fω1 = ω[2]; fω2 = ω[0]; fω3 = ω[1]; Иначе fω1 = ω[2]; fω2 = ω[1]; fω3 = ω[0]; КонецЕсли; Для i = 3 По ω.Количество() - 1 Цикл x = ω[i]; Если (fω1 <= x) И (x <= fω2) Тогда fω1 = x; ИначеЕсли (fω2 <= x) И (x <= fω3) Тогда fω1 = fω2; fω2 = x; ИначеЕсли fω3 <= x Тогда fω1 = fω2; fω2 = fω3; fω3 = x; КонецЕсли; КонецЦикла; Возврат Новый Структура("Первое, Второе, Третье", ↵ fω1, fω2, fω3); КонецФункции

Рассмотренные выше функции могут быть записаны в модуль управляемого приложения конфигурации (в случае, если он пуст) через меню «Конфигурация → Открыть конфигурацию», а затем «Конфигурация → Открыть модуль управляемого приложения». Для отладки используется последовательность операторов из листинга 4. Листинг 4. Отладочная часть модуля ω = Новый Массив(); ГСЧ = Новый ГенераторСлучайныхЧисел(); Для i = 1 по 15 Цикл ω.Добавить(ГСЧ.СлучайноеЧисло(0, 300) - 50); КонецЦикла;

Рез = ТриНаибольшихЗначения(ω); Сообщить("ТриНаибольшихЗначения " + Рез.Первое + " " + ↵ Рез.Второе + " " + Рез.Третье);

Приведу примеры запуска программы. а) Результаты работы, 1-й прогон: ЧислоЭлементовПоследовательности 15 МинимальноеИМаксимальноеЗначения -25 226 ТриНаибольшихЗначения 162 200 226

б) Результаты работы, 2-й прогон ЧислоЭлементовПоследовательности 15 МинимальноеИМаксимальноеЗначения 23 246 ТриНаибольшихЗначения 225 232 246

Понятный практический пример использования данных разработок, в частности решения задачи о трех наибольших, может быть заключен в следующем. Необходимо произвести упрощенный по числу факторов в целях ускорения ABC-анализ очень большого объема входных данных, но по единственному критерию. Согласно этому критерию большему значению входной величины соответствует большая предпочтительность. Кроме прочего, исходные данные задаются в форматированном текстовом документе (либо в исключительной ситуации, в файле формата XML). Для ЛПР (лица, принимающего решения) будет достаточно трех наиболее предпочтительных величин. В том случае, если ЛПР заинтересует величина разброса (диапазон), можно оценить наибольшее и наименьшее значение последовательности.

Разработанные примеры демонстрируют применение элементов языка Если … Тогда … ИначеЕсли … Иначе … КонецЕсли, Для … По … Цикл … КонецЦикла, работу с объектами типов Структура() и Массив(). Полученные функции могут найти применение в конфигурациях, послужить образцом для значительно более сложных индуктивных конструкций. Использование подхода подойдет для тех случаев, которые «заставят оцепенеть профессионала» [1]. EOF [1] Вторников А. Трудный путь наверх. // «Системный администратор», № 12, 2015 г.– С.84-87 (http://samag.ru/archive/article/3105). [2] Кушниренко А.Г. Программирование для математиков / А.Г. Кушниренко, Г.В. Лебедев. – М.: Наука, 1988. – 384 с. [3] Арсак Ж. Программирование игр и головоломок / Ж. Арсак. – М.: Наука, 1990. – 224 с. [4] Щвец А.Н. Perl. Примеры программ [Электронный ресурс] / А.Н. Щвец. – Режим доступа: http://mech.math.msu.su/~shvetz/ 54/inf/perl-problems, свободный. – Загл. с экрана. Ключевые>слова: 1С, индуктивное вычисление функций.

январь-февраль 2017 системный администратор

Разработка

истоки программирования

Визитка

АЛЕКСЕЙ ВТОРНИКОВ, независимый разработчик ПО, консультант, atues62@gmail.com

Философский камень программирования: язык С

Недавно минуло пять лет, как ушел из жизни один из наиболее влиятельных людей современности. Он не был бизнесменом. Он не был звездой шоу-бизнеса. И уж тем более он не был политиком. Он был программистом, и звали его Деннис Макалистер Ритчи (Dennis M. Ritchie)

Богатый урожай вырастает из горстки семян, а сдержанность рождает наслаждение. Лиз Бреннан-Джобс

Трудно найти выдающегося ученого, изобретателя или новатора, чья биография уместилась бы в одном абзаце. О жизни Денниса Ритчи известно удивительно мало. Вернее будет сказать, что о ней неизвестно почти ничего. Ритчи родился в сентябре 1941 года в Бронксвилле (штат Нью-Йорк) в семье исследователя из компании Bell Labs Алистера Ритчи, одного из авторов теории переключательных схем. Деннис получил образование в Гарварде (физика и прикладная математика). В 1967 году стал сотрудником той же компании, где раньше трудился его отец. Ритчи вел очень замкнутый образ жизни и тщательно скрывал ее ото всех. Его коллега Роб Пайк как-то сказал о нем: «Более 20 лет я проработал на противоположной стороне зала и все же считаю, что не знал его хорошо». 12 октября 2011 года Пайк обнаружил тело Ритчи в его доме. Точная дата смерти осталась неизвестной: он скончался в период с 8 по 12 октября. Смерть Стива Джобса, случившаяся несколькими днями ранее, совершенно затмила собой уход Ритчи. В отличие от личной профессиональная жизнь Ритчи сверкает ярче бриллианта. Ритчи в полной мере вкусил признание при жизни, что, правда, никак не отразилось на его привычной замкнутости. Вот только некоторые из полученных им наград и премий. Он – лауреат премии Тьюринга (1983) (совместно с Кеном Томпсоном) за разработку общей теории операционных систем и, в частности, за операционную систему UNIX. Он – лауреат медали Ричарда Хемминга (1990) (и вновь вместе с Кеном Томпсоном). В 1999-м он (как и прежде, с Кеном Томпсоном) получил из рук президента США Билла Клинтона Национальную медаль США за достижения в области технологий и инноваций,

системный администратор январь-февраль 2017

которые согласно официальной формулировке «закрепили лидерство Америки в информационном веке». Профессиональная жизнь Д. Ритчи удивительно богата свершениями. Чтобы подробно рассказать о том, что он сделал для информатики и программирования, нужна большая книга. Может быть, когда-нибудь такая книга и появится. Мы, конечно, даже не будем пытаться объять необъятное, а расскажем лишь об одном факте его профессиональной биографии.

Откуда ноги растут? Если спросить любого программиста, какой язык он считает самым важным, то он скорее всего назовет тот из них, с которым работает или которым владеет лучше всего. Счет таких языков пойдет на десятки. Но если поставить вопрос в другой форме, а именно какой язык оказал наибольшее влияние на современное программирование, то круг претендентов резко сужается. Хотя следующий перечень весьма субъективен, но, вероятно, 90% специалистов согласятся с тем, что список, состоящий из C++, Java и C#, является ответом на поставленный вопрос. Сегодня модно оценивать популярность чего-либо по рейтингам. Языки программирования – не исключение. Один из наиболее известных и широко цитируемых – т.н. индекс TIOBE [1]. Если вы зайдете на указанный сайт, то убедитесь в том, что наш список очень похож на правду. Конечно, всякий рейтинг – не более чем приближение к истине, так что не будем придираться. Но внимательно приглядевшись к рейтингу, вы, безусловно, обратите внимание на то, что в пятерку ведущих языков программирования стабильно входит еще один язык, которого нет в нашем перечне, а именно язык программирования C. По большому счету наш первоначальный список никуда не годится – он должен состоять только из одного элемента, а именно C. Ведь именно C является предком всех языков из нашего shortlist. А места его потомков, как это ни покажется кому-то обидным, – во втором эшелоне.

Разработка Почему C? А действительно, почему? Что в нем есть такого, что позволило C просуществовать больше 40 лет? И не просто просуществовать, но и продолжить активно использоваться. Мало того, что C является основой трех основных «монстров»; он прародитель множества других языков программирования. Разумеется, наследники C отличаются от своего предка и внешне (т.е. синтаксически) и внутренне. Но, немного покопавшись, мы найдем явные следы C практически в большинстве из них.

BCPL получился на редкость элегантным языком: исходный код программ, написанных на нем, удобно и даже приятно читать, что немаловажно для удобства работы Главная причина, по-видимому, в том, что C был создан программистом и для программистов. Автор языка не был связан маркетинговыми и рекламными обязательствами. Он делал инструмент для себя. Ему ничего и никому не надо было доказывать. Он был волен использовать то, что ему нравилось, изменять то, что не нравилось, добавлять то, что он считал необходимым, и выбрасывать то, что считал не нужным. Его не волновали «ленточки и колокольчики» (выражение Эдсгера В. Дейкстры). Он сделал ВЕЩЬ, не будучи обремененным никакими обязательствами, соглашениями и конъюнктурными соображениями. Такое не часто случается, но если случается, то в результате получается шедевр «на все времена» (аналогичные истории произошли с языками Lisp и Forth). Автор языка не помышлял о вселенской славе, а просто сотворил гениальное детище, без которого сегодняшнее программирование было бы совсем другим. Конечно, «свято место пусто не бывает» – не было бы C, было бы что-то другое. Но история не оперирует сослагательным наклонением, в ней важны точный контекст и проверенные факты. Давайте к ним и обратимся.

Сначала контекст... Все началось в 1961 году, когда Массачусетский технологический институт (MIT) приступил к разработке самой первой операционной системы разделения времени CTSS (Compatible Time-Sharing System). Что такое «разделение времени»? Молодым читателям, привыкшим к тому, что практически все современные операционные системы являются многозадачными, покажется, возможно, диким то, что так было не всегда. Первые 15-20 лет компьютерной эры доминировали операционные системы, построенные на совершенно иных принципах. Все существовавшие до 1961 года операционные системы были предназначены для пакетной обработки информации: программист писал программу, эта программа передавалась в машинный зал, оператор машинного зала готовил программу (обычно путем ее переноса на перфокарты)

истоки программирования и ставил в очередь ожидающих задач (которые, собственно, и составляли собой пакет). Когда приходило время, программа отправлялась на обработку: подготовленная ранее колода перфокарт поступала в считывающее устройство. Информация загружалась и шла на обработку. Таким образом, между программистом и компьютером не было прямой связи: все, что программист мог, – это дождаться того момента, когда его программа будет поставлена на компьютер, и, скрестя пальцы, ждать, завершится ли все удачно или нет. Элементарная опечатка или брак перфокарты – и время вышло. На прогон элементарной задачи порой уходили часы и сутки. И все потому, что время работы компьютера было дороже времени работы программиста. Благодаря развитию технологической базы (появление сначала транзисторов, затем микросхем, а также новых устройств хранения информации) и конкуренции производителей ситуация начала меняться: компьютерное время и оборудование стали дешеветь, а стоимость работы программистов расти. Их количество увеличивалось, и все большему числу пользователей стал необходим прямой доступ к компьютеру. Наконец наступил момент, когда время работы программиста стало дороже времени работы компьютера и эффективность использования последних стала падать. Заставлять пользователей ждать, когда машина освободится для решения их задач, стало экономически невыгодным. Нужно было найти способ нагрузить компьютер, а для этого прежде всего нужно было обеспечить одновременный доступ к компьютеру сразу нескольким пользователям. Так появилась концепция систем разделения времени: множество пользователей могли одновременно работать за одним компьютером. Каждому из них операционная система предоставляла небольшой промежуток (квант) времени, и у каждого из них складывалось впечатление, что вся вычислительная система принадлежит ему одному. Операционная система должна была следить за распределением ресурсов (процессора, памяти, устройств ввода/вывода), предотвращать конфликты и обеспечивать иллюзию единоличного владения компьютером. Кроме того, нужно было обеспечить интерактивность работы и избавиться наконец от миллионов перфокарт и бесконечных очередей в машинном зале. CTSS, хотя и была экспериментальной разработкой (просуществовавшей тем не менее до 1972-го), показала, что за системами разделения времени будущее. В 1964 году MIT, компании General Electric (GE) и Bell Labs (BL) сформировали консорциум для разработки новой операционной системы разделения времени, получившей название MULTICS (MULTiplexed Information and Computing Service). Поскольку опыта разработки и эксплуатации таких систем в середине 60-х годов было мало, то неудивительно, что для разработки MULTICS потребовались усилия трех крупных «игроков». Никто из участников поначалу не мог даже представить, какие проблемы их ожидают. Задача оказалась сложной. Первопроходцы потратили на эту работу пять лет, и к 1969 году консорциум начал распадаться: из проекта вышли MIT и BL, а в 1970-м GE продала свой компьютерный бизнес. По счастью, история MULTICS на этом не закончилась. Новый владелец (компания Honeywell) все-таки довел операционную систему

январь-февраль 2017 системный администратор

истоки программирования

Разработка

Язык программирования C – это пример исключительно удачной разработки

до работоспособного состояния, и она работала в некоторых организациях (преимущественно в военных министерствах и университетах) до конца 2000 года. В 2007-м исходный код и документация MULTICS были переданы MIT и опубликованы на его сайте. Несмотря на то что не все цели, поставленные разработчиками MULTICS, были достигнуты, она оказала решающее влияние на дальнейшее развитие операционных систем. Фактически MULTICS послужила предтечей семейства операционных систем UNIX. В MULTICS был предложен и реализован ряд фундаментальных концепций: плоские файлы, иерархическая файловая система, разделяемое адресное пространство, виртуальная память, динамическое связывание библиотек. В MULTICS были окончательно оформлены концепции процесса и мультизадачности. Были опробованы различные стратегии планирования, синхронизации и блокировки пользовательских и системных процессов. MULTICS, хотя и ограниченно, допускала переконфигурирование системы «на ходу». Большое внимание уделялось вопросам безопасности и разграничения доступа. Немаловажно также и то, что значительная часть MULTICS была написана на языке программирования высокого уровня (PL/1). Общий размер MULTICS в откомпилированной и готовой к запуску форме составлял менее 140 килобайт, что по нынешним временам просто пустяк (хотя в те годы считалось, что система чересчур громоздка).

...а потом факты Но вернемся к 1969 году. Со стороны BL в проекте участвовала группа под руководством Кена Томпсона (да-да, того самого Кена Томпсона, о котором мы упоминали ранее). Когда BL вышла из проекта, Томпсон решил, что будет глупо не воспользоваться знаниями, полученными в процессе работы над MULTICS. Одним из участников группы был Деннис Ритчи. В распоряжении группы Томпсона оказался бесхозный компьютер PDP-7 (от Digital Equipment Corporation, DEC).

системный администратор январь-февраль 2017

Он был оснащен 8К памяти, состоящей из 18-битных слов (в те годы производители компьютеров активно экспериментировали с размером слова памяти). По признанию Д. Ритчи, сделанному в 1993 году, это было более чем спартанское оборудование даже по тем временам. Томпсон решил реализовать некоторые из концепций MULTICS на PDP-7 и довольно быстро написал прототип операционной системы. Вот перечень того, что им было сделано: ядро операционной системы, редактор, ассемблер, простой интерпретатор команд, несколько основных утилит. Да-да, все это было реализовано на тех самых «несчастных» объемах памяти! Сегодня нам, привыкшим к гигабайтам и терабайтам, это кажется нереальным, но это так. Чуть позже, когда были реализованы загрузчик и линкер, появилась возможность связывать пользовательские программы с библиотеками, и операционная система Томпсона из исследовательского проекта стала превращаться в настоящий рабочий инструмент. Одним словом, Томпсон с сотрудниками создали на пустом месте практически полноценную среду программирования и исполнения программ. Это было тем, что впоследствии получило название UNIX. Но Томсону пришлось очень нелегко – до реализации своего ассемблера он фактически программировал в машинных кодах. Да и после появления своего ассемблера легче не стало – ассемблер есть ассемблер и, как ни старайся, им и останется. Это ему не очень нравилось (а кому бы, интересно, это могло понравиться), и Томпсон стал подыскивать подходящий язык высокого уровня, тем более что опыт MULTICS доказал – это возможно. PL/1 был отвергнут сразу. Несмотря на мощную поддержку со стороны владельца языка (корпорации IBM), этот язык был слишком велик, слишком сложен и не слишком удачен. Томпсон попробовал FORTRAN, но быстро убедился в том, что этот выбор еще хуже. Нужно было что-то иное: более удобное, чем ассемблер, но не такое примитивное. Довольно скоро Томпсон нашел, как ему казалось, то, что нужно, – язык BCPL, созданный несколькими годами ранее Мартином Ричардсом (MIT). BCPL получился на редкость элегантным

Разработка языком: исходный код программ, написанных на нем, удобно и даже приятно читать, что немаловажно для удобства работы. Кстати, популярный однострочный комментарий, начинающийся с последовательности «//», появился именно в BCPL.

По словам Брайана Кернигана, «C – это инструмент, острый как бритва. С его помощью можно создать и шедевр, и кровавое месиво» Томпсон, по словам Д. Ритчи, «отфильтровал своими мозгами» BCPL (т.е. выбросил из него все, что только можно было выбросить) и буквально втиснул то, что осталось, в имевшиеся 8К. Язык получил имя B. Этимология названия языка осталась неясной: то ли Томпсон назвал его в честь своей жены, то ли в честь древней тибетской религии Бон (Bon), в которой практиковались магические ритуалы, заклинания и прочая эзотерика (что, кстати, больше похоже на правду). Вот пример программы на языке B из руководства, составленного Кеном Томпсоном: /* The following function will print a non-negative number, n, to the base b, where 2<=b<=10. This routine uses the fact that in the ANSCII character set, the digits O to 9 have sequential code values. */ printn(n,b) { extrn putchar; auto a;

}

if(a=n/b) /* assignment, not test for equality */ printn(a, b); /* recursive */ putchar(n%b + '0');

Краткое пояснение для тех, кто плохо владеет английским языком. Эта функция решает важную задачу: представление неотрицательных целых чисел в системах счисления от 2 до 10. Обратите внимание, что решение задачи опирается на тот факт, что в ASCII-кодировке символам от 0 до 9 соответствуют последовательные значения числовых кодов. Язык B допускал рекурсию. Благодаря этому функция получилась на удивление краткой и в то же время понятной. Но язык B, несмотря на свою очевидную полезность, оставался языком экспериментальным и не слишком удобным. Его надо было, как говорят инженеры, «довести». Этой доводкой и занялся Деннис Ритчи.

Начало Начало работ по переделке языка B относится к 1971 году. Почему не раньше? Причина состояла в том, что у Томпсона и Ритчи попросту не было подходящего компьютера. Они «выжали» из PDP-7 все, что только могли, и подошли к пределу его возможностей. Но в 1971-м у них появился новый компьютер PDP-11 (исключительно удачная разработка корпорации DEC), и с этого времени мир стал другим.

истоки программирования Не следует думать, что все было придумано и реализовано сразу, легко и быстро. Язык C – это результат эволюции, постепенного приближения к идеалу. Два года понадобилось Ритчи для того, чтобы появился тот C, который мы привыкли видеть и использовать. Лишь в 1973 году, после многочисленных попыток, экспериментов, переделок и опробования различных вариантов, C как язык программирования явил себя миру в полной красе. Деннис Ритчи полностью спроектировал новый язык: это был действительно новый язык, а не «причесанный» вариант BCPL и B.

Явление C миру Все три языка (BCPL, B, C) генеалогически относятся к той же группе языков программирования, что PL/1 и FORTRAN. К этой же группе, но только «приукрашенные» объектами, относятся также C++, Java и C#. Все это императивные языки программирования, ориентированные на вызовы функций и поддержку структур данных, которые могут быть непосредственно или без существенной потери эффективности отображены на память компьютера (переменные различных типов, массивы, строки и биты).

Почему Томпсон и Ритчи не ограничились языком B? Во-первых, память в B рассматривалась как массив адресуемых слов памяти. С аппаратной точки зрения так оно и есть (и именно так память рассматривается при программировании на ассемблере), но с точки зрения программиста это было очень неудобно. Приходилось следить за тем, как интерпретировать содержимое ячейки памяти: это число, символ, адрес, строка или просто набор битов? Терялось главное преимущество языка программирования высокого уровня – абстрагирование от аппаратуры. Иными словами – в языке B отсутствовала типизация. Во-вторых, в языке B была неразвитая адресная арифметика. Программисты на языке C прекрасно знают, что истинная мощь этого языка заключается в указателях (для тех, кто подзабыл или не знает, напомним: указатель – это просто адрес памяти). В сущности, указатель – это эквивалент косвенной адресации в ассемблерах. При косвенной адресации ячейка памяти содержит не сами данные, но адрес, по которому хранятся данные. Изменяя только лишь указатель, мы можем «одним движением руки» переходить от одних данных к другим. Указатели – это суть языка программирования C. Но неумелое обращение с ними может породить и серьезные проблемы. Могут, например, появиться т.н. висячие ссылки, которые никуда не указывают. Неаккуратное обращение с указателем может привести к тому, что данные могут потеряться. Возможны утечки (leak) памяти. Вторая опасность указателей в том, что они позволяют получить доступ к памяти, которая принадлежит другой программе или ядру операционной системы. По словам Брайана Кернигана, «C – это инструмент, острый как бритва. С его помощью можно создать и шедевр, и кровавое месиво». На самом деле в указателях нет ничего сложного – это просто способ доступа к данным, привнесенный из языка ассемблера и машинных кодов. В-третьих, в языке B предусматривались либо отдельные переменные, либо области памяти, но не было ничего

январь-февраль 2017 системный администратор

истоки программирования подобного структурам (записям), которые позволяли объединять переменные, указатели и массивы в композитный объект и манипулировать им как некой сущностью. Значение структур особенно ценно, если вспомнить, что именно они были положены в основу определения классов в объектно-ориентированном программировании. В-четвертых, проблемы с компиляцией и связыванием отдельных модулей в единую исполняемую программу. Для решения этого Ритчи ввел препроцессор, который просматривал исходные коды программ и «собирал» нужную информацию перед тем, как программы будут компилироваться. К концу 1973 года язык C приобрел знакомые нам сегодня черты. Главная цель была достигнута – появился полноценный язык программирования высокого уровня, пригодный для программирования операционных систем. И это было сделано – UNIX была переписана на C.

UNIX на C Появление операционной системы, практически полностью написанной на языке программирования высокого уровня, произвело среди программистов эффект разорвавшейся бомбы. Лишь считанные проценты кода требовали программирования на языке ассемблера (например, обработка прерываний); все остальное было написано на C. Появилась реальная возможность не только ускорить процесс написания новых операционных систем, но и переноса существующих на новые аппаратные платформы. Так вскоре и случилось, и клоны UNIX стали множиться как грибы после дождя. Разумеется, параллельно это привело к распространению языка программирования C. Из лабораторной разработки он становился промышленным стандартом. К началу 80-х годов прошлого века C стал первым среди равных, оттеснив практически все императивные языки на второй план. Язык программирования C – это пример исключительно удачной разработки. Он не без недостатков (а где их нет?), но в целом это не умаляет его ценности. Он – действительно базовый элемент, на котором и по сей день держится все системное программное обеспечение. Операционные системы, базы данных, системы управления объектами (в том числе военными и космическими), обработка больших объемов данных, численные расчеты, реализация новых языков программирования... Список можно продолжать и продолжать. Конечно, со временем появились и другие языки программирования. Но C по-прежнему остается единственным и неповторимым. И пока не видно, кто или что могло бы отодвинуть C. Попытки были, да толку?

K&R По мере распространения UNIX программисты были вынуждены знакомиться с языком C по весьма кратким и порой неточным описаниям. Единственными авторитетными источниками знаний по языку служили исходные тексты программ UNIX и компилятор. Благодаря университетам (особенно университету в Беркли, штат Калифорния) операционная система стремительно совершенствовалась. Назрела необходимость дать программистам полноценное руководство.

системный администратор январь-февраль 2017

Разработка В 1978 году Д. Ритчи в соавторстве с Б. Керниганом написали книгу «Язык программирования C». По первым буквам фамилий авторов на эту книгу обычно ссылаются как на K&R. Без сомнения, K&R стала одной из самых важных книг по программированию в истории информатики. Несмотря на солидный возраст, K&R остается, пожалуй,

Появление операционной системы, практически полностью написанной на языке программирования высокого уровня, произвело среди программистов эффект разорвавшейся бомбы лучшим введением в язык программирования C, и каждый, кто программирует на этом языке, обязан ее прочесть. Эта небольшая книга служит своего рода эталоном при описании других языков программирования. Деннис Ритчи очень взвешенно подходил к просьбам расширить язык. На них он обычно отвечал так: «Если тебе нужен PL/1, ты знаешь, где его взять». Это не консерватизм и не ревность создателя, а его осторожность и мудрость, которые позволили сохранить язык C небольшим, эффективным и популярным. Конечно, современный C несколько отличается от варианта, описанного в K&R, но если нужно изучить основы языка, понять его философию, проникнуться духом C, то лучшего введения не найти. EOF [1] Индекс TIOBE – http://www.tiobe.com/tiobe-index. [2] Б. Керниган и Д. Ритчи «Язык программирования C». Самая важная и главная книга по языку. Ищите второе издание, в котором отражено современное состояние языка. [3] Домашняя страница Денниса Ритчи – https://www.bell-labs.com/ usr/dmr/www. Оригинальные работы, доклады и руководства, написанные Д. Ритчи. Обратите внимание на статью «The Development of the C Language». [4] Дж. Лайонс «Commentary on the Sixth Edition UNIX Operating System» – http://www.lemis.com/grog/Documentation/Lions/book. pdf и http://v6.cuzuco.com/v6.pdf. Возможно, вторая по значимости после K&R книга о языке. Это полная распечатка исходных кодов ядра UNIX и комментарии к ним. Книга сыграла выдающуюся роль в распространении UNIX и являлась настольной книгой хакеров (в изначальном понимании этого слова). [5] Руководство М. Ричардса по BCPL – http://www.cl.cam. ac.uk/~mr10/bcplman.pdf. Несмотря на то что BCPL по современным меркам совсем уж «древний» язык программирования, его автор продолжает поддерживать язык по сей день. [6] Андрей Богатырев «Руководство полного идиота по программированию (на языке C)». Доступный, интересный и качественный учебник. Его можно найти по адресу: http://www.lib.ru/ CTOTOR/starterkit.txt. Ключевые слова: язык программирования C, UNIX, системы разделения времени, Деннис Ритчи, Кен Томпсон.

Разработка

веб-технологии

Визитка

АЛЕКСАНДР КАЛЕНДАРЕВ, OTG, руководитель группы (ТимЛид), akalend@mail.ru

Современная веб-архитектура

От монолита к микросервисам

Микросервисы – это небольшие самодостаточные программы или сервисы, которые выполняют одну маленькую задачу. Они работают совместно с другими программами (сервисами)

Современные тенденции развития веб-архитектуры ведут к постоянному усложнению. При разработке, улучшении и дальнейшем развитии успешного веб-приложения наступает такой момент, что становится тяжело поддерживать существующий код, тяжело внедрять новые решения. И тут архитектор задумывается о разделении проекта на небольшие части. Это и есть первый шаг к микросервисам. Стиль разработки микросервисов – это подход, при котором единое приложение строится, как набор небольших сервисов. При этом каждый из них работает в собственном окружении и общается с остальными. Практически это могут быть крон-задачи, небольшие сетевые демоны, HTTPсервисы. Сами по себе эти сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных. Основные преимущества микросервисной архитектуры: >> автономные сервисы позволяют быстрее локализовать неисправность; >> скорость разработки маленького проекта, где минимальная связанность компонент выше; >> масштабирование проще; >> технологическая разнородность позволяет внедрять сервис с использованием тех технологий, которые наилучшим образом подходят для решения данной подзадачи; >> лучше устойчивость, как в маленьких проектах; >> простота развертывания; >> быстродействие, простой маленький проектик дает более быстрый отклик, чем монструозное приложение.

Принципы рефакторинга Один из первых шагов – это уменьшение связанности, выделение и обособление общих частей. Когда я работал в проекте «Война танков», там у нас, кроме основного игрового сервера приложений, использовалась микросервисная архитектура, в которой были выделены специальные сервисы: >> сервис авторизации, он позволял авторизироваться в разных соцсетях;

>> сервис начальных установок, используемый разными микросервисами на стадии запуска; >> сервис биллинга игровых валют; >> сервис сбора игровой статистики. При таком подходе разработка новых игр позволяла нам сосредоточиться только на разработке и внедрении игровой логики в сервере приложений и использовать уже существующую инфраструктуру ранее внедренных проектов с минимальными издержками. Еще один пример из практики. При эксплуатации одной службы знакомств мы заметили, что нагрузка на сообщения превышает в несколько раз нагрузки остальных служб. Сервер сообщений вынесли в отдельный микросервис и запустили на нескольких машинах. В общем итоге после некоторой оптимизации серверов у нас освободилось две машины. Как это все происходит? Например, в текущем проекте мы разрабатываем проект сайта доставки еды. У нас админпанель реализовывалась на Laravel как эффективный фреймворк для разработки СRM и общей архитектуры с механизмами миграций БД. А API был реализован на Phalcon как наиболее производительный фреймворк. Это особенно видно, когда идет разработка под мобильные устройства. В нашем проекте API был реализован единым для веби мобильной разработок. А вот сам фронтенд, веб-часть реализованы на Node.js. И так у нас появились три независимые части проекта, которые лежат в трех репозиториях и разрабатываются отдельно. Тут появляется задача – необходимо держать три раздельных, но в то же время практически одинаковых конфигурационных файла. А можно добавить еще один микросервис – раздачи конфигурационных данных. Предыдущий проект тоже был связан с доставкой и отслеживанием курьеров. Какая-то часть одного проекта может быть использована для реализации второго. Повторное использование кода – это часто применяемая практика. Так вот, эту часть можно выделить как специальный

январь-февраль 2017 системный администратор

веб-технологии

Разработка

Разработка микросервисов – это подход, при котором единое приложение строится, как набор небольших сервисов

микросервис. Например, микросервис баннеров акций, проводимых на сайте, и учета их эффективности, т.е. сколько покупок сделали по этому баннеру. Также в рамках проекта можно выделить специальный сервис по расчету цены доставки. Цена на доставку в конечный адрес может меняться от разных условий: день недели, время суток, наличие бонусной карты. Цена доставки зависит от зоны, которая определяется по полигонам, которые рисуются на карте контент-менеджером, а цену устанавливает экономический отдел в собственной системе CRM или даже в 1С, экспортирующей данные в микросервис. Для лучшего сбыта товаров есть такая функция «с этим товаром чаще всего покупают...». Я просмотрел реализацию: в большинстве случаев сделана привязка конкретного товара к определенному списку товаров. Но было бы интересно анализировать каждую корзину и на основе статистики строить такие рекомендации. Также, если мы вручную «рекомендуем» тот или иной товар, то как часто люди «следуют» этой рекомендации? Это очень интересная аналитическо-статистическая задача, и ее хорошо решать в рамках отдельного микросервиса. Такой рекомендательный сервис с разными стратегиями на основании учета статистики можно будет использовать в похожих проектах с возможностью экономии на внедрении.

Как должны быть реализованы микросервисы? Основной принцип построения микросервисной архиетктуры – это изолированность. Микросервис должен быть изолирован и самодостаточен. Он может быть реализован как сетевой демон или HTTP-сервис. Он может быть даже реализован как небольшой внедренный в nginx Lua скрипт. Микросервис должен решать одну небольшую задачу. Насколько она должна быть небольшой – это уже решать вам. Например, для защиты API я в рамках nginx реализовал на Lua микросервис, который сравнивал токены и валидировал запросы. С какой стороны подойти к рефакторингу монолита? Вопервых, нужно четко выделить границы в коде между модулями. Обычно это происходит по функциональному принципу. Второе: надо иметь ясное понимание того, что необходимо вынести в отдельный микросервис. Необходимо продумать свою систему хранения данных для каждого микросервиса. И еще надо помнить основной принцип рефакторинга – это разработка через тестирование: пишем тесты и еще раз тесты.

Коммуникация микросервисов Разбиение монолитной системы на части предполагает, что эти самодостаточные части начнут обмениваться информацией. Для обмена микросервис может использовать как REST-Full API + JSON поверх HTTP-протокола,

Рисунок 1. Принцип pipe-line-архитектуры

системный администратор январь-февраль 2017

Разработка так и разные бинарные протоколы: BSON, msgpack, protobuf при сокетном обмене. Например, в одном из проектов, где я работал, все наши микросервисы общались по текстовому memcached-протоколу. Но, как показала впоследствии практика, он не полностью удовлетворял нашим потребностям, и приходилось его расширять. Использование стандартных протоколов имеет свои плюсы: нет необходимости специально разрабатывать стыковочные (интерфейсные) части программ. Уже есть готовые клиенты под множество языков, реализующие данный протокол. Один из используемых приемов построения архитектуры называется pipe-line-архитектура. На рис. 1 изображен общий принцип pipe-line-архитектуры. Есть один сервис, который отправляет в «канал» сообщение для второго сервиса, а второй сервис отправляет в следующий «канал» сообщение для третьего сервиса. Третий сервис, в свою очередь, может отправить в канал сообщение следующему сервису. И таким образом строится обмен, который проходит через брокеры (серверы) сообщений. Такими брокерами могут выступать либо общие middleware, такие как redis, tarantool, MongoDB или даже PgQueue, либо специализированные: MemcacheQ, ZMQ, RabbitMQ, Kafka, Qpid, IronMQ, ActiveMQ, Beanstalkd, Gaerman и др. Каждый из них имеет свою нишу. Передача данных через сообщения позволяет асинхронно взаимодействовать между элементами архитектуры, сохраняет слабую связанность между элементами архитектуры и дает возможность взаимодействовать с разными частями, реализованными на разных языках: PHP – Python – Java – Go – JS -Scala – Erlang... Когда-то я работал в проекте Tradebox, который был аналогом Yandex-Market. Что у нас творится под капотом витрины: сервис должен загрузить YML-данные о товарах из нескольких тысяч магазинов. Проанализировать данные и разобрать их по каталогам. Привязать данные к основному каталогу, который отображается на веб-витрине. Загрузить отсутствующие картинки товаров. А не привязанные данные – отобразить контент-менеджеру для последующей «ручной» привязки к данной категории. В данном проекте напрашивается как минимум пять микросервисов: Рисунок 2. Паттерн «Подписка/Публикация»

веб-технологии >> загрузка контента; >> анализ контента; >> загрузка картинок; >> отображение веб-витрины; >> CMS-контент менеджера. Архитектуру взаимодействия между первыми тремя микросервисами можно организовать через сервер очередей, например RabbitMQ. Так как контента требуется загрузить много и процесс загрузки занимает достаточно времени, то данную задачу было бы логично распараллелить между несколькими микросервисами. Для этого нам лучше всего использовать паттерн «Подписка/Публикация» (см. рис. 2). Приложение «Публикатор» или «Продюсер» генерирует сообщения и отправляет их в канал. На этот канал «подписывается» несколько приложений «слушателей» или «подписчиков» (в разных интерпретациях этого паттерна термины трактуются по-разному). При поступлении сообщения в брокер оно передается одному из активных подписчиков (это особенность RabbitMQ). Активный подписчик (микросервис) выполняет некоторые действия и далее отправляет результат в другой канал сообщений. Какие проблемы могут возникнуть при распараллеливании процесса? Во-первых, это конкурентный доступ к ресурсам. Каждый из процессов требует обращения к хранилищу данных, к общим областям памяти. При запуске большого числа однотипных микросервисов потребуется их балансировка, необходим механизм равномерного распределения нагрузки заданий на микросервисы.

Виртуализация В микросервисной архитектуре разработчику приходится использовать одновременно сразу несколько микросервисов. Осуществлять сборку и разворачивание на одной разработческой машине не всегда удобно, особенно когда таких микросервисов много. Для более быстрого разворачивания системы лучше использовать виртуализацию: виртуальные машины или контейнеры. Один из недостатков использования виртуальных машин заключается в том, что запуск их большого количества может привести к перегрузке машины разработчика. Если в нашей архитектуре заложено так, что у нас на каждой отдельной виртуальной машине разворачивается по одному сервису, то может случиться так, что разработчик на своей локальной машине просто не сможет настроить инфраструктуру всей системы. Docker представляет собой платформу, являющуюся надстройкой над облегченными контейнерами, и по сравнению с виртуальными машинами требует меньше системных ресурсов. Часто при развертывании используется собственный docker-репозиторий, в котором хранятся образы с уже готовыми микросервисами. Разработчику для настройки локальной инфраструктуры всего лишь требуется «поднять» несколько docker-образов с уже готовыми микросервисами.

Мониторинг Если у нас микросервис запущен как отдельная служба, то необходимо отслеживать работоспособность этой

январь-февраль 2017 системный администратор

веб-технологии службы. Брать ее отдельные параметры, например накапливать микросервисом статистику о количестве обработанных заданий в период заданного времени или с начала запуска. Обязательно мониторить такой микросервис, как память на наличие утечек. Отвечает ли микросервис? Не завис ли он? Если приходится мониторить одновременно несколько однотипно запущенных микросервисов на одной физической машине, то тут в метриках надо обязательно указывать, с какого сервиса (pid, id или уникальный номер запущенного микросервиса) снимались метрики. В этом случае мы можем выяснить общую картину по равномерности нагрузки и работоспособности каждого отдельного микросервиса. Если микросервис запущен как отдельное веб-приложение, то необходимо отслеживать наличие 500 и 400 ошибок. Если в архитектуре используются очереди, то обязательно необходимо мониторить количество элементов в каждой очереди. Идеально если длина очереди равна нулю. Среднее значение длины очереди может быть и больше нуля, но прироста быть не должно. Если очередь явно растет, то где-то что-то не обрабатывается. По мере роста очереди мы можем понять, что обработчик (получатель) сообщений не успевает с их обработкой, и мы можем добавить (запустить) еще один экземпляр микросервиса. В 2014 году Баттери Вентура представил основные правила мониторинга микросервисов:

системный администратор январь-февраль 2017

Разработка >> Работайте больше над кодом, который анализирует значение метрик, чем над кодом, который их собирает, переносит и показывает. >> Снижайте задержки ключевых бизнес-метрик не более чем продолжительность концентрации внимания человека (до ~ 10 с). >> Система измерения должна иметь достаточную точность. Осуществляйте сбор гистограмм времени отклика. >> Системы мониторинга должны быть более доступными и масштабируемым, чем системы, которые мониторятся. >> Осуществляйте мониторинг распределенных, облачных и контейнерных микросервисов. >> Установите метрики для моделей, чтоб понимать «физику отношений». Есть «промышленные» решения, которые осуществляют мониторинг запущенных микросервисов в контейнерах (vagrant, docker), анализируют длину очередей, при необходимости сигнализируют потребность запуска «новых» контейнеров: Loggly, Dynatrace, Prometheus. EOF [1] Сэм Ньюман. Создание микросервисов. – O'Reilly, 2016. [2] Грогор Хоп, Бобби Вульф. Шаблоны интеграции корпоративных приложений. – М.: Вильямс, 2007. Ключевые>слова: микросервисы, разработка, архитектура.

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

alma mater российских ИТ

Арутюн Аветисян:

«Для талантливых и трудолюбивых студентов у нас созданы все условия» В гостях у «Системного администратора» доктор физико-математических наук, член-корреспондент РАН, директор Института системного программирования РАН Арутюн Аветисян Беседовала Галина Положевец Чтобы восполнить кадровый дефицит, формально можно увеличивать число студентов, выпускать гораздо больше ИТ-специалистов, но ИТ-инженерия – это элитарное образование по определению, оно очень трудно масштабируется. Дело в том, что молодых ученых или инженеров-исследователей должны готовить наставники, люди, которые сами уже прошли этот путь, специалисты-практики, а не просто преподаватели. Однако подобных наставников, которые могут подготовить новые кадры, крайне мало. Их недостаток ощущается во всем мире. Поэтому можно, конечно, предложить: «Давайте начнем готовить в три раза больше ИТспециалистов». Но где взять людей, которые их будут учить?

Арутюн Аветисян, доктор физико-математических наук, членкорреспондент РАН, директор Института системного программирования РАН

– О проблеме дефицита ИТ-кадров в России говорят сегодня многие и много. С чем она связана, как вы считаете? – Это глобальная проблема. Дефицит ИТ-кадров существует и в развитых странах Запада, но в каждой стране есть свои причины, почему он возникает. У нас, например, на стандартный недостаток ИТ-кадров накладывается большая «утечка мозгов», отток специалистов из страны, соответственно, это влияет на подготовку кадров, в том числе университетскую.

– Отчасти их дефицит восполняют разработчики, которые преподают в вузах. – Отчасти, да. Но утечка кадров не позволяет полностью решить эту проблему. Многие думают, что американские компании нанимают специалистов из других стран только потому, что они дешевле. Это далеко не так. Компании берут иммигрантов, потому что им катастрофически не хватает квалифицированных кадров, и они готовы платить любые деньги, лишь бы их получить. Поэтому я думаю, что импорт специалистов в США идет не только потому, что они дешевле, а в силу того, что американцы стараются перетянуть самых лучших и талантливых людей к себе и таким образом решить свои проблемы. Для нас вряд ли подобное возможно, поэтому мы должны иметь свои модели образования, свои институты, которые на постоянной основе растят собственные кадры. Примером может являться наш Институт – несмотря на все сложности 90-х годов, мы не только выжили, но и продолжаем поступательно развиваться и влияем на образование ИТ-индустрии. – А как вы это делаете? – Процесс налажен следующим образом. У нас есть кафедры системного программирования в МФТИ, МГУ и Высшей

январь-февраль 2017 системный администратор

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

alma mater российских ИТ школе экономики с полным циклом обучения – от бакалавриата до магистратуры, мы там читаем лекции с первого курса. На третьем курсе студенты приходят в Институт. Продолжая учиться у себя в вузе, они вовлекаются в научно-исследовательскую деятельность, мы их включаем в команды реальных ИТ-проектов. Сначала студент выбирает специализацию. У нас в Институте есть пять семинаров по различным направлениям – например, управление данными и информационные системы, системы программирования и так далее. Если, посещая семинар, студент видит, что не совсем правильно выбрал свою область знаний, то он может поменять направление, поняв, что ему нужно. Мы очень внимательно относимся к ребятам, которые к нам приходят, как к своим будущим сотрудникам. Ежегодно ИСП РАН принимает порядка 60 студентов с трех кафедр. Хотя обычно желающих больше, чем мы можем взять, поэтому ребят приходится отбирать. Но реальный отбор начинается, когда они уже здесь, в Институте, начинают работать.

Справка Институт системного программирования РАН – научно-исследовательское учреждение Отделения математических наук РАН Российской академии наук, ведущее фундаментальные и прикладные исследования в области информатики. Основан 25 января 1994 года на базе бывшего Института проблем кибернетики РАН. Отделы – архитектуры вычислительных систем, инструментальных средств разработки программ, информационных систем, компиляторных технологий, системного программирования, теоретической информатики, технологий программирования. В институте действуют ученый совет и диссертационный совет. Одно из структурных подразделений – Центр верификации ОС Linux. Среди разработок института – СУБД Sedna и технология тестирования программного и аппаратного обеспечения UniTESK. Образовательное направление: > Аспирантура ИСП РАН > Кафедра СП ФУПМ МФТИ > Кафедра СП ВМК МГУ > Кафедра СП НИУ ВШЭ Сайт института: http://www.ispras.ru.

– Почему студентов так тянет в ИСП РАН? – Много компонентов срабатывает – и мотивация, и талант, и желание студента серьезно заниматься. Для Института это тоже полезное общение: мы имеем постоянную подпитку, приток талантливых ребят из лучших вузов страны. С самого начала для Института была выбрана известная и апробированная в советское время «физтеховская» модель – интеграция исследовательского института с вузом и индустрией. Время доказало, что эта модель вполне дееспособна и в условиях рыночной экономики. В 90-е годы, когда утечка научных кадров в стране достигала 70-80%, мы смогли выжить. Прежде всего потому, что была научная школа, вокруг которой создавался Институт. Вот за счет нее, за счет того, что у нас всегда был поток студентов, что в самое тяжелое время мы смогли найти заказчиков, которым нужны были реальные результаты, мы и устояли.

С самого начала для Института была выбрана известная и апробированная в советское время «физтеховская» модель – интеграция исследовательского института с вузом и индустрией В 2000-е годы ситуация стабилизировалось. А в последние пять лет, могу сказать, что ситуация не просто улучшилась, люди стали гораздо реже уезжать, но и появилась сильная внутренняя конкуренция. Сегодня в Институте сложился хороший костяк – 75-80% сотрудников моложе 40 лет. Это возраст, когда человек молод и может все, а при этом у него есть опыт, которого не хватает в 20 лет. Благодаря нашему учителю и основателю ИСП

системный администратор январь-февраль 2017

РАН Виктору Петровичу Иванникову мы смогли решить важную проблему преемственности поколений, которая сегодня в нашей стране особенно актуальна. Да, в Институте много молодых, они востребованы, они хотят решать задачи, и у нас есть задачи, которые надо решать, есть достаточно много хороших контрактов. Но мы уже столкнулись с нехваткой кадров. Потому что студент, чтобы стать суперспециалистом или техническим руководителем, должен пройти бакалавриат, потом магистратуру, потом аспирантуру – на все это уйдет не меньше пяти лет. Обычно проходит немало времени, прежде чем первокурсник дорастет до руководства. Но у нас этот путь сокращен, так как молодой человек начинает работать фактически на втором или третьем курсе. – Модель развития ИСП РАН кажется простой. Ее могут позаимствовать и другие? – Да, модель относительно простая, но, чтобы ее реализовать, необходимо учитывать несколько очень важных моментов. Во-первых, она должна базироваться на серьезном техническом бэкграунде. Научную школу меньше, чем за 10 лет, невозможно создать. А реально времени понадобится еще больше. Например, научная школа Виктора Петровича Иванникова формировалась еще в 60-е годы, то есть должна быть хорошая научная составляющая. Во-вторых, должен быть качественный приток молодых кадров, который обеспечивают кафедры университетов, случайным образом это нельзя сделать. В-третьих, необходим качественный приток денег, привязанных к конкретным проектам. Но даже когда все эти компоненты есть, все равно модель может оказаться неэффективной. Чтобы все получилось, необходимы люди – команда единомышленников во главе со своим лидером. Нужны пассионарии, которые друг другу доверяют, усилий одного человека, даже великого, здесь недостаточно.

Карьера/Образование Академик РАН Виктор Петрович Иванников Крупнейший российский ученый, академик Российской академии наук, доктор физико-математических наук, профессор, главный редактор журнала «Программирование», заведующий кафедрами

системного

программирования

факультета ВМК МГУ, МФТИ и ВШЭ, основатель и научный руководитель Института системного программирования, человек, стоявший у истоков создания российских ИТ и посвятивший всю жизнь их развитию. Основатель отечественной научной школы системного программирования, объединяющей ученых – разработчиков системного программного обеспечения вычисли-

alma mater российских ИТ Мы стараемся, чтобы ребята, которые хорошо работают в наших проектах, получали достойную зарплату. Потому что нормальная зарплата – это дополнительная мотивация для любого сотрудника. Если он захочет, мы можем послать его на любую конференцию, опубликовать его научную статью в журнале, главное, чтобы она была интересной. В своей работе мы часто используем свободное программное обеспечение – это тоже очень сильная мотивация, потому что, если студент написал код, отдал в СПО, его сразу увидят многие. Если молодой человек хочет заниматься наукой, то он может учиться в аспирантуре ИСП РАН, защитить диссертацию. Хочу отметить, что у нас издается два научных журнала, которые внесены в список Высшей аттестационной комиссии.

тельных систем. Со дня образования Института системного программирования РАН (25 января 1994 года) и до последних дней жизни В.П. Иванников руководил работой его коллектива по широкому спектру актуальных направлений: в области разработки операционных систем, систем программирования, в том числе для параллельных вычислительных систем, информационных систем и баз данных, средств машинной графики и систем визуализации, средств моделирования, анализа и верификации ответственных систем.

Как говорил Виктор Петрович, «нужен круг единомышленников, костяк людей, которые живут ради созданного дела». Постепенно этот круг расширялся, вместо 50 сотрудников, как было когда-то, сегодня в Институте работают 200 человек, для которых системное программирование очень важно и не является бизнесом. Они, безусловно, профессионалы в своей области. И, конечно, важна постоянная работа с людьми, с командами, воспитание новых руководителей, талантливых разработчиков. Все эти компоненты – научная школа, лучшие вузы, сильный лидер, креативная команда, хорошие проекты, грамотное управление – и создают ту питательную среду, в которой рождаются великие идеи и великие дела. Но, как я говорил, на все нужно время – 10-20 лет. Поэтому модель простая, а создавать настоящую научную школу, живой, реально работающий институт сложно. Я сейчас назвал лишь некоторые из дополнительных, но необходимых для этого компонентов. – У вас могут учиться или работать выпускники только МФТИ, МГУ и ВШЭ? – Институт системного программирования – не учебная, а научная организация. Но у нас есть собственная аспирантура. Конечно, мы принимаем талантливых ребят из других вузов, однако надо понимать, что все претенденты проходят довольно жесткий отбор. Поэтому лучший вариант, если парень поступает либо в магистратуру, либо в аспирантуру к нам, неважно из какого он вуза. Мы ко всем студентам относимся одинаково хорошо и создаем для них максимально комфортные условия. Для аспирантов у нас есть общежитие. А всем студентам уже на третьем курсе платим стипендию по 10 тысяч рублей, чтобы они учились и наращивали свои знания. Когда они начинают участвовать в одном из наших проектов, платим им зарплату.

– Чем еще ИСП РАН привлекает молодежь? – По примеру государственной целевой программы «Молодежи – доступное жилье» мы сделали свою собственную программу для наших молодых сотрудников и аспирантов. Человек получает беспроцентную ссуду, покупает себе однокомнатную квартиру в Москве, где-нибудь рядом с метро и, работая в Институте, постепенно отдает деньги. За пять лет работы нашей программы было куплено таким образом примерно 50 квартир. Понятно, что это тоже сильный стимул для сотрудников. Хочу подчеркнуть, что все, что мы делаем, не накладывает ни на кого из них никаких обязательств. Любой волен уйти из Института работать туда, куда ему захочется. Все это знают, возможно, поэтому от нас редко уходят. Для творчества очень важно ощущение свободы. Она позволяет решать сложные технические задачи на совершенно другом уровне эффективности. За все годы работы Института ни разу не было случая, чтобы мы провалили про-

Для талантливого молодого человека в Институте системного программирования РАН созданы все условия. Главное, что от него требуется, – хорошо учиться и стать суперспециалистом ект! Это тоже важный показатель. Потому что в своей работе мы очень гибкие, можем адаптироваться под разные требования любой компании. Можно сказать, что наша цель – это создание такой атмосферы в институте, чтобы всем членам команды хотелось приходить сюда, чтобы они чувствовали себя здесь хорошо, как в родной семье, – генерировали идеи, обсуждали их, принимали участие в решении институтских проблем. Иными словами, для талантливого молодого человека в Институте системного программирования РАН созданы все условия. Главное, что от него требуется, – хорошо учиться и стать суперспециалистом. EOF

январь-февраль 2017 системный администратор

alma mater российских ИТ

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

Андрей Белеванцев: «Основной принцип, которому я научился в Институте: только завершенная работа (пусть и неидеальная) делает тебя профессионалом» Андрей Белеванцев, ведущий научный сотрудник ИСП РАН, руководитель направления анализа и оптимизации программ Я стал студентом нашей кафедры на ВМК МГУ на третьем курсе в 2000 году, занимался компиляторными технологиями – это очень разнообразная область, включающая оптимизацию программ, статический анализ кода и многое другое.

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

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

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

времени на творчество. Так же старался делать и я, когда вел свои проекты. Еще через пять лет наша группа выросла до 30-40 человек, выполняющих контракты с компаниями Samsung, Intel, HP и другими. Но и сейчас больше трети моего времени – это работа обычного инженера-исследователя. Основной принцип, которому я научился в Институте: только завершенная работа (пусть и неидеальная) делает тебя профессионалом. Перескакивая между идеями, как только сделана самая интересная часть, ничего не добьешься. Тяжелее всего довести работу до конца. Но только так можно получить реальный опыт и продвинуться вперед, и так мы стараемся жить в Институте. EOF

Алексей Хорошилов: «В ИСП РАН я, можно сказать, попал с университетской скамьи на передовой край науки» Алексей Хорошилов, ведущий научный сотрудник ИСП РАН, директор Центра верификации ОС Linux ИСП РАН Я пришел в ИСП РАН весной 1998 года студентом второго курса и сразу после короткого, но интенсивного обучения на спецсеминаре под руководством А.К. Петренко попал в проект по верификации операционной системы канадской компании Nortel Networks. Можно сказать, попал с университетской скамьи на передовой край науки, поскольку в рамках того проекта развивались новые методы

системный администратор январь-февраль 2017

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

ведущих зарубежных ученых в области формальных методов, которых удостаивались результаты нашей работы. EOF

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

alma mater российских ИТ

Вартан Падарян: «Выбор конкретного пути и скорости движения по нему – дело самого студента» Вартан Падарян, ведущий научный сотрудник ИСП РАН, руководитель направления обратной инженерии бинарного кода Мне посчастливилось оказаться в Институте весной 1997 года. В тот момент я был студентом второго курса ВМК МГУ и стремился распределиться на кафедру системного программирования, что было очень непросто из-за высокого конкурса. Было не-

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

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

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

не давали старшие товарищи, аспиранты, которым было 25-30 лет и которые всегда готовы были прийти на помощь хорошим советом. Коллективная работа доходчиво учит взрослой жизни, в небольших командах заметен вклад каждого, даже если он студент. За прошедшие 20 лет Институт преобразился, но принципы, заложенные Виктором Петровичем Иванниковым, остаются прежними. Каждому приходящему студенту предлагают понятные пути развития, включающие в себя научную работу, разработку программ, доведенную до уровня искусства, образовательную деятельность. Выбор конкретного пути и скорости движения по нему – дело самого студента. EOF

Денис Турдаков: «Благодаря Институту системного программирования мне посчастливилось начать свою трудовую деятельность в команде лучших выпускников факультета ВМК МГУ» Денис Турдаков, заведующий отделом информационных систем ИСП РАН Благодаря Институту системного программирования мне посчастливилось начать свою трудовую деятельность в команде лучших выпускников факультета ВМК МГУ. Моя работа была связана с созданием открытой XMLсистемы управления базами данных Sedna, а тема моего диплома была посвящена оптимизации выполнения запросов для этой СУБД. В аспирантуре тематика исследований сместилась

в сторону анализа данных. С несколькими коллегами мы стали и одной из первых команд в мире, которая начала использовать знания из Википедии для автоматического построения онтологий и дальнейшего семантического анализа текстов. При этом наш опыт разработки СУБД помог сделать эффективную систему управления знаниями, которая позволила анализировать данные в десятки раз быстрее,

чем появлявшиеся в то время аналоги, не уступая им в качестве анализа. Эти разработки легли в основу моей кандидатской диссертации и стали частью технологии Текстерра, которая сегодня используется в индустриальных проектах ИСП РАН. EOF

январь-февраль 2017 системный администратор

alma mater российских ИТ

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

Кадровая политика

по «физтеховской» модели Кадровая база – самое слабое место любой отрасли. Стремительно развивающиеся технологии, меняющиеся быстрее, чем учебные планы, утраченные в годы распада СССР связи между учебными и исследовательскими институтами, не говоря уже о связях первых и вторых с производством, – вот те препятствия, которые неизбежно встают на пути роста и процветания, наносят удар по мечтам о конкурентоспособности и перспективах на рынке. Это традиционные и пока что неизлечимые болезни российской экономики. Между тем выход из этой ситуации известен уже давно, еще с советских времен. Это так называемая модель физтеха, опыт создания структуры, включающей в себя образовательный, научный и производственный процессы Подготовила Анна Новомлинская

Пример внедрения такой модели сегодня можно найти и в ИТ-сфере. Думается, никому не нужно рассказывать, что эта отрасль в России была практически лишена возможности развития в 1990-е в результате «утечки мозгов» на Запад. Однако на Первой научно-практической конференции ИСП РАН, прошедшей в декабре минувшего года, можно было наблюдать картину, полностью противоположную. Картину настоящего, подлинного торжества отечественной ИТ-отрасли. И речь идет даже не только и не столько о программных продуктах высочайшего уровня, представленных гостям конференции, хотя многие из этих разработок и технологий производили впечатление фантастическое. Скорее здесь нужно вести речь о кадровой базе российского программирования, о том, сколько молодых ученых выступало на конференции. О том, что Институту системного программирования удалось не только сохранить кадровую базу, но и наладить ее расширение и воспроизводство. Причем, похоже, гостей это поразило не меньше, чем показанные им ИТ-новинки. «Очень большая команда воспитана, – отметил по итогам конференции Марат Гуриев, GR-директор российского офиса Samsung. – Очень хороший коллектив, который пережил все искусы тяжелых времен и представляет собой первоклассный по мировым меркам коллектив. Первоклассный!» «Я думаю, они очень умные, – вторит ему Чул Джо Ким, представитель Software Research Centre Samsung. – Я думаю, что инженеры ИСП РАН одни из лучших в мире».

системный администратор январь-февраль 2017

Вид на институт ИСП РАН со стороны Коммунистического переулка

Карьера/Образование Удивительно в этой ситуации то, что ИСП РАН был основан в самое нестабильное и тревожное время за последние четверть века – в 1994 году. Забота о формировании кадровой базы и, более того, о генерации новых кадров для отрасли выглядела на ту пору делом странным, поскольку делать какие бы то ни было прогнозы на будущее далее, чем на месяц вперед, было просто невозможно. Однако основатель Института – академик Виктор Иванников с самого начала взял курс на развитие по классической «физтеховской» модели.

На третьем-четвертом году обучения в ИСП РАН многие студенты имеют научные публикации и уже становятся реальными специалистами по системному программированию в своей области исследований Первое десятилетие после создания Института было самым тяжелым: речь шла буквально о выживании, о сохранении научной школы, сохранении способности к воспроизводству кадров высшей квалификации. 1990-е стали эпохой не просто упадка экономики, это было время распада и деструкции. «Утечка мозгов» среди представителей высокотехнологичных отраслей была настолько велика, что за тот период почти полностью – до 80% – сменился состав сотрудников института. И тем не менее ИСП РАН не только сохранил основные направления исследований, но и создал заделы для дальнейшего развития. Именно тогда были созданы новые технологии верификации ПО, проведены фундаментальные исследования по технологиям анализа ПО на выявление уязвимостей безопасности и так далее. И именно в этот период сложилась существующая сегодня система подготовки новых кадров для института. «Я был одним из первых студентов новой кафедры системного программирования МФТИ, созданной на базе ИСП РАН, – вспоминает Владимир Рубанов, бывший студент кафедры, а ныне вице-президент Parallels и управляющий директор компании «Росплатформа», – Виктор Петрович Иванников был моим научным руководителем по диплому, впоследствии – по диссертации. Самое примечательное – с первых дней обучение на кафедре переплеталось с практической работой в реальных проектах с живыми заказчиками в лице передовых технологических компаний мира. Руководством Института поощрялась работа именно на мировом «переднем крае» по своей специализации начиная от публикаций и выступлений на ведущих международных конференциях до работы с лидерами индустрии в рамках совместных проектов. Виктор Петрович говорил очень просто: «Нужно быть лучшим в мире по своей теме, а для этого нужно общаться с лучшими». И в ИСП РАН эта модель отлично работала». Именно созданной в этот период системе Институт обязан своим дальнейшим процветанием в последующие годы, когда экономическая ситуация в стране начала меняться

alma mater российских ИТ и на рынке труда началась настоящая «борьба за головы» – за человеческие ресурсы в отрасли, подстегиваемая ростом конкуренции со стороны отечественных высокотехнологичных компаний: ABBYY, 1C, Яндекса, Mail.ru, Acronis, «Лаборатории Касперского» и других. К этому времени на фоне значительного увеличения объема работ с отечественными организациями, направленных на технологическую независимость, вырос и престиж профессии в частности и отрасли в целом. В результате число сотрудников ИСП РАН, вовлеченных в образовательную деятельность, увеличилось более чем в два раза, было разработано свыше 10 новых учебных курсов и значительно переработаны существующие. Надо отметить, что фактическое финансирование всех этих работ ведется за счет Института. При этом с учетом высокого приоритета образовательной деятельности, стремясь повысить эффективность учебных курсов, наряду с сотрудниками института, официально участвующими в преподавании, руководство ИСП РАН привлекает к этой деятельности примерно столько же дополнительных «внешних» сотрудников. «Физтеховская» модель работы института, нацеленная на образование через исследование, на интеграцию с индустрией, показала себя успешной еще в советские времена, а практика нашей работы в последние два десятилетия показала ее действенность и в условиях рыночной экономики, – говорит Арутюн Аветисян, директор ИСП РАН. – Все это время мы развивались именно в этой парадигме, в результате чего институт заработал прочную и достойную репутацию как в России, так и за ее пределами. Одни из основных ее компонентов – генерация и сохранение кадров, причем кадров высшей квалификации, способных обеспечить создание и ускоренное внедрение новых технологий. Основная цель такого подхода – решение проблемы разрыва между образованием и промышленностью. Особенность модели развития ИСП РАН – нацеленность на инновации как ключевой механизм удержания передовых позиций в науке и в подготовке кадров, создание экосистемы, обеспечивающей постоянную генерацию инноваций в области системного программирования». Как же работает эта экосистема? Один из важнейших и необходимых ее компонентов – образовательная деятельность, а это значит собственная аспирантура и интеграция ИСП РАН с ведущими вузами: с кафедрой системного программирования на факультете ВМиК МГУ, такая же кафедра в МФТИ на факультете ФУПМ, лаборатория системного программирования на факультете компьютерных наук ВШЭ. Каждый год на эти кафедры в институт приходят 40-50 студентов. В первый год обучения в ИСП РАН (третий курс) они начинают слушать дополнительные лекции специалистов института, посещать спецсеминары и знакомиться с исследовательской тематикой по научным направлениям. Причем не просто знакомиться, а вовлекаться в реальные проекты. Во второй год обучения студенты уже вовсю участвуют в научных работах, а к пятому-шестому курсу университета (то есть на третьем-четвертом году обучения в ИСП РАН) многие из них имеют научные публикации и уже становятся реальными специалистами по системному программированию в своей области исследований.

январь-февраль 2017 системный администратор

alma mater российских ИТ Для тех, кто поступает в аспирантуру, годы учебы – это одновременно накопление практического опыта и изучение новых технологий. Кроме того, аспиранты активно вовлекаются в процессы обучения. Они ведут семинарские и практические занятия со студентами, руководят подготовкой курсовых и дипломных работ. Накопив такой опыт, выпускник аспирантуры, как правило, становится руководителем небольшой исследовательской группы. Это очень серьезная мотивация, привлекающая молодых специалистов в созданную Институтом экосистему. Исследовательская работа подразумевает, что научная проблема или задача, которую предстоит решить, является настоящим вызовом, она требует не только владения самыми передовыми технологиями, но и выхода за границы известных методов решений подобных задач. Кроме того, настоящее научное исследование подразумевает открытость научного результата и «видимость» его автора. Для ИСП РАН открытость результатов исследования, в частности активное использование возможностей модели открытого программного кода, является одновременно и стимулом к работе, и инструментом продвижения как Института, так и технологий, которые в нем разрабатываются. Открытость приводит к тому, что каждый молодой исследователь, даже если он работает в большом коллективе, «виден» в международном сообществе ИТ-специалистов. Его вклад, его репутация – это его капитал, а Институт делает все возможное, чтобы этот капитал рос максимально быстро. Кстати, необходимо отметить, что с первого года обучения в ИСП РАН студенты начинают получать стипендию, а со второго года зарплату, которая к нынешнему дню сопоставима с зарплатами в ведущих высокотехнологичных ИТ-компаниях. Постепенно созданная в рамках института экосистема становится достоянием не только ИСП РАН. В последние годы под научным руководством ИСП РАН были созданы две лаборатории, по образу и подобию действующих в институте, на базе других организаций – Ереванского государственного университета и Университета имени Ярослава Мудрого в Великом Новгороде. Их сотрудники выполняют совместные с ИСП РАН промышленные и исследовательские проекты, образуя распределенную среду разработки и исследований, работают над совместными публикациями и выступлениями на конференциях, читают современные курсы в своих университетах, молодые специалисты лабораторий проходят в ИСП РАН очную стажировку, в том числе семестровые стажировки для подготовки бакалаврских и магистерских дипломных работ. Помимо этого Институт ведет большое число научных и образовательных программ в тесной кооперации с ведущими российскими и зарубежными научными и университетскими центрами, в частности с университетами Кембриджа, Карнеги-Меллон, INRIA, Пассау и другими. Существующая модель Института обеспечивает создание долгосрочных отношений с ведущими исследовательскими организациями – университетами, исследовательскими группами крупных частных компаний – по конкретным направлениям исследований. Долговременные отношения чрезвычайно важны для образования в сфере системного программирования:

системный администратор январь-февраль 2017

Карьера/Образование несмотря на всю инновационность, эта область знаний очень консервативна. Таким образом, созданная в институте экосистема обеспечивает сегодня системную ускоренную подготовку и отбор молодых специалистов высшей квалификации как за счет реальной исследовательской работы, так и в результате достаточного уровня финансирования. Это, во-первых, дает возможность решать задачу обеспечения стабильного, поступательного развития коллектива ИСП РАН, а во-вторых, создает кадровый задел для ИТ-отрасли России в целом.

Созданная в институте экосистема обеспечивает сегодня системную ускоренную подготовку и отбор молодых специалистов высшей квалификации как за счет реальной исследовательской работы, так и в результате достаточного уровня финансирования В заключение необходимо отметить, что с нуля, без определенного задела и в первую очередь профессиональной репутации, создание такой экосистемы крайне затруднительно, а может, и невозможно. Ядром созданной экосистемы являлась и является научная школа, которая создавалась в 60-70 годы еще в ИТМиВТ при поддержке академика Лебедева на базе разработок системного ПО для отечественных вычислительных систем. Институт системного программирования РАН, созданный в 1994 году, фактически стал организационной формой этой научной школы. «Можно иметь замечательную модель развития, но не суметь ее реализовать, если за ней нет соответствующей движущей силы, – отмечает Арутюн Аветисян. – Двигатель – это люди, команда. Двигатель – это личность и авторитет руководителя. Поэтому все, чего мы достигли, – это результат многолетней работы единомышленников. Виктор Петрович Иванников, сплотивший вокруг себя команду ИСП РАН, был человеком целеустремленным, постоянно нацеленным на работу, и во многом именно его личность, его энергия определяли развитие Института. Мы будем придерживаться заданного им вектора движения, будем продолжать строить Институт, делать его еще сильнее». Что же в итоге? А в итоге мы видим, что «физтеховская» модель в Институте оказалась жизнеспособной и может быть принята за образец для реализации в других отраслях. Курс на научно-производственные объединения, о котором много говорят, – стремление к налаживанию не просто связей между образовательной, научной и производственной деятельностью, а созданию жестких отраслевых «спаек» – оказался действительно перспективным. Как видно на примере ИСП РАН, на него можно и даже следует опираться. EOF

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

рынок труда

Вакансия: программист .NET Платформа .NET позволяет реализовывать настольные приложения для Windows и мобильные для Windows Phone. Языки программирования, ориентированные на использование вместе с платформой .NET, демонстрируют устойчивую популярность (C# – 4-е место) и даже рост (Visual Basic .NET – с 6-го на 7-е место). Об этом свидетельствовал индекс TIOBE на момент написания статьи. Мы попросили представителей компаний рассказать о знаниях, навыках, опыте, актуальных для программиста .NET сегодня. 1. Программист на .NET: какими знаниями и навыками он должен обладать? 2. Инструментарий программиста на.NET? 3. Каковы требования компании к уровню образования потенциальных сотрудников? 4. Какие требования предъявляются к опыту работы? 5. Есть ли особые требования, которые обусловлены спецификой деятельности компании?

Александр Шилин, старший инженер-программист, Группа компаний РЕЛЭКС

Программист .NET должен обладать такими же знаниями и навыками, как и любой другой разработчик: принципы разработки программного обеспечения SOLID, DRY, KISS; умение работать с исходным кодом, написанным другим программистом; знание основных паттернов проектирования; понимание и опыт работы с реляционными базами данных; английский язык на уровне чтения технической документации. В нашей компании большинство проектов, в которых используются технологии .NET, разрабатываются на языке C#, поэтому и инструментарий соответствующий. Стандартный стек для C#: ASP.NET MVC, ADO.NET, WCF, WPF, Silverlight, SQL и так далее. Приветствуется умение самостоятельно разрабатывать архитектуру отдельных блоков системы и организацию их взаимодействия. Понимание, как можно оптимизировать производительность системы, также пригодится программисту .NET, равно как и навык быстрой локализации ошибок. Полезным будет опыт разработки высоконагруженных масштабируемых систем, а также знакомство с такими продуктами, как Redis, SignalR, ElasticSearch, RabbitMQ. Пока еще не было случаев, чтобы на вакансию разработчика в нашу компанию откликался человек без высшего образования. В свою очередь, мы уже долго проводим

3 92

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

Приветствуется умение самостоятельно разрабатывать архитектуру отдельных блоков системы и организацию их взаимодействия

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

январь-февраль 2017 системный администратор

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

рынок труда

Николай Добровольский, вице-президент Parallels

К общим требованиям можно отнести знание английского языка на уровне чтения технической документации. Также важны умение работать в команде, самостоятельность, ответственность и коммуникативные навыки. Если говорить про узконаправленные навыки, то программистам .NET сегодня требуется владение технологией ASP.NET MVC. Также можно считать must have навыки работы с SQL Server и использования Transact-SQL. Кроме того, потребуется знание WCF, XML, XSLT и LINQ. Нужен навык объектно-ориентированного программирования. В целом можно сказать, что хорошие специалисты, пишущие на Java, .NET или другом языке, всегда востребованы.

Хорошие специалисты, пишущие на Java, .NET или другом языке, всегда востребованы

Если вам хочется писать веб, то лучше попробовать Python или Ruby и еще JavaScript. Если писать системные утилиты, алгоритмы, то лучше попробовать C или C++. Под мобильные системы можно выбирать между Java, Objective-C, .NET (можно также подумать о JavaScript, но совет спорный). Если хочется писать десктопные приложения, то лучше попробовать C++, .NET. Если в планах сидеть не на «винде» и писать не только под Windows, то лучше не думать о .NET. По поводу IDE: у Java есть Eclipse, Net Beans, но я бы посоветовал idea. У нас в компании есть несколько человек без профильного технического образования. Это скорее исключение, но подтверждающее гипотезу, что увлеченный человек может самостоятельно добиться успеха в программировании. В основном же к нам приходят выпускники ведущих технических вузов страны: МФТИ, МГТУ им. Баумана и других. Также у Parallels есть собственная базовая кафедра и научные лаборатории по подготовке инженеров на базе Физтеха, «Бауманки», Университета Мальты и других. Все зависит от позиции, на которую приходит разработчик. Если речь идет о старте карьеры, то глубокое знание конкретного языка не потребуется. Конечно, знать и понимать, чем отличается List от Vector и что в каких случаях быстрее работает, нужно. Не помешает также знание того, какая хеш-функция вам кажется хорошей, как работает Map, что такое функция сложности, чем отличается, на ваш взгляд, хороший код от плохого, и тому подобные вещи. Но понимание глубины специфики придет к вам по мере практики. Мы заведомо стараемся набирать людей, которые имеют большой потенциал и готовы развивать свой профессионализм в данной области.

системный администратор январь-февраль 2017

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

Кирилл Скрыган, руководитель команды Rider в JetBrains

С технической точки зрения нужно хорошо разбираться в самом языке C#, понимать, как работает платформа .NET, уметь обращаться с основными инструментами для нее. Важно понимать принципы многопоточного программирования, знать, как работают структуры данных. Социальная часть тоже очень важна: нужно уметь слушать/убеждать других членов команды. Даже в начале, просто чтобы понять, что и как работает, нужно плотно пообщаться как минимум с половиной команды. Неотъемлемая часть разработки ReSharper/ Rider – пользоваться этим же продуктом в повседневной работе. Поэтому, конечно, в инструментарий входят Visual Studio + ReSharper или Rider. Очень желательно умение пользоваться профиляторами (dotTrace, dotMemory), бывает, что нужны в работе декомпиляторы и дазассемблеры (dotPeek, Ildasm). Но, понятное дело, всеми этими инструментами можно научиться пользоваться достаточно быстро, главное – уметь быстро осваивать новое. Здесь нет какого-то четкого закона: с одной стороны, у нас есть талантливые сотрудники из далеко не самых сильных математических вузов, с другой – чисто среднестатистически большая часть людей у нас все же с матмеха СПбГУ. Самое главное, чтобы человек умел быстро обучаться новому.

Всеми инструментами можно научиться пользоваться достаточно быстро, главное – уметь быстро осваивать новое

Здесь нет особых требований. Например, у меня в проекте есть несколько студентов, начавших работать непосредственно у нас, и они прекрасно себя проявляют и приносят огромную пользу продукту. Да, есть. Нужно сочетание, с одной стороны, хорошей технической базы, с другой – важны активность, инициативность, находчивость, изобретательность. В наших продуктах мы постоянно придумываем что-то новое, постоянно пытаемся улучшить любимое детище. Конечно, важно, чтобы у всех членов команды горели глаза от того, чем они занимаются, чтобы им было действительно интересно. EOF

Подготовил Игорь Штомпель 93

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

лабораторная работа

Визитка

ПАВЕЛ ЗАКЛЯКОВ, ИТ-специалист

Лабораторная работа:

исследование сетевого трафика

Можно ли как-то увидеть сетевой трафик? Например, подобно тому, как тестер «показывает» электрический ток, напряжение, а осциллограф – форму? Ответ – можно

Если стоит задача «увидеть» на практике, во что выливается использование стека сетевых протоколов и закрепить теоретические знания, то данная работа с минимумом усилий позволит выполнить эту задачу. Для исследования трафика будет использован такой инструментарий, как анализатор трафика (он же сниффер). Чтобы пользователи не смогли испортить что-то в системе, работа проводится от учётной записи с минимальными правами. При выполнении понаблюдаем, как работает сеть Ethernet, и посмотрим, как выглядит трафик протоколов IP, TCP, UDP, ICMP, HTTP и HTTPS. Цель работы – произвести перехват сетевого трафика сниффером и в его «сыром шестнадцатеричном виде» понять, какие байты за что отвечают.

Описание лабораторного стенда Работа проводится на компьютере с ОС Linux CentOS 6.8 (64-bit), подключённом к сети Интернет по Ethernet (без создания VPN, интерфейс eth0). Для проведения работы используются (требуются) браузер Mozilla Firefox и снифферы tcpdump и Wireshark Network

Analyzer (пакеты tcpdump, wireshark, wireshark-gnome, плюс браузер firefox). Пользователь выполняет действия по созданию сетевой активности с помощью браузера, перехватывает сниффером трафик, после чего его изучает. В зависимости от уровня подготовленности тех, кто выполняет работу, она может проводиться двумя сценариями: > в первом стенд заранее готовится администратором, > во втором обучаемые выполняют предварительную настройку стенда самостоятельно.

Подготовка стенда 1. Установите вышеуказанные операционную систему с графической средой и программы (браузер и снифферы). В процессе установки добавьте пользователя guest с паролем guest. 2. Настройте сетевое подключение. Убедитесь, что из браузера от указанного пользователя возможно просматривать сайты в интернете. 3. Настройте возможность запуска снифферов Wireshark Network Analyzer и tcpdump с правами обычного пользователя.

Рисунок 1. Соотнесение уровней сетевых моделей

январь-февраль 2017 системный администратор

лабораторная работа В образовательных целях в данной работе запуск сниффера с правами суперпользователя не производится. При таком ограничении запуск программы сниффера возможен с помощью механизма sudo, но тогда при сохранении трафика в файл владельцем последнего будет суперпользователь. Обычный пользователь не сможет его удалить, а значит, будет расходоваться дисковое пространство. Лучше использовать тонкую настройку «возможностей» для программ, работающих напрямую с сетевыми интерфейсами (/usr/sbin/dumpcap и /usr/sbin/tcpdump). Первая программа входит в состав RPM-пакета wireshark и используется графической оболочкой Wireshark Network Analyzer (wireshark-gnome). Файлам следует добавить способности CAP_NET_RAW и CAP_NET_ADMIN со списком действий, определяемых флагами «e», «i» и «p». Указанные привилегии дают возможность использования сырых и пакетные сокетов; предоставляют различные операции, связанные с сетью и сетевыми интерфейсами, а флаги определяют настройки Effective, Inheritable и Permitted («эффективный», «наследственный» и «разрешённый» соответственно). Подробнее о возможностях или способностях см. man 7 capabilities (пакет man-pages), о действиях (флагах) – man 3 cap_to_text (пакет libcap-devel). Добавление необходимых возможностей осуществляется командами:

Карьера/Образование Краткие теоретические сведения Перед выполнением работы рекомендуется повторить устройство стека протоколов TCP/IP, распределение протоколов по уровням модели и вспомнить предназначение сетевых уровней [2-5]. Наиболее наглядными картинками, «освежающими» память, будут рис. 1-3.

Задания для самостоятельного выполнения Результаты выполнения заданий и свои наблюдения заносите в отчёт, например, в следующем формате: номер задания и знак «+» – если пункт выполнен и не требует комментариев, либо ставьте напротив номера иные понятные значки, слова или текст. Шаг 1. Войдите в систему от имени пользователя guest. Запустите сниффер tcpdump в окне терминала: $ tcpdump -i eth0 -n -nn

Рисунок 2. Основные протоколы различных уровней и их взаимодействие

# setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' ↵ /usr/sbin/dumpcap # setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' ↵ /usr/sbin/tcpdump

В результате любой пользователь, имеющий права на запуск указанных программ, сможет просматривать трафик, проходящий через сетевые интерфейсы системы. Замечание 1. В файловой системе ext4 способности хранятся в блоках файловой системы и «привязаны» к inode файла. Увидеть увеличение числа блоков, занимаемых файлом за счёт добавления способностей, можно с помощью команды stat /usr/sbin/dumpcap. Просмотреть и удалить способности можно следующими командами: $ getcap /usr/sbin/dumpcap

Рисунок 3. Инкапсуляция данных при их продвижении вниз по стеку протоколов TCP/IP

/usr/sbin/dumpcap = cap_net_admin,cap_net_raw+eip # setcap -r /usr/sbin/tcpdump

соответственно. Аналогично для /usr/sbin/tcpdump. Замечание 2. Не следует путать «возможности» («способности») с атрибутами файлов в файловой системе ext*, меняемыми командой chattr, расширенными атрибутами (Extended Attributes) и списками контроля доступа ACL (Access Control Lists). О них можно прочитать в man 5 attr и в [1]. Замечание 3. Программа tcpdump является стандартом de facto среди снифферов, но для просмотра трафика в режиме «на лету» она не всегда подходит, поскольку не умеет расшифровывать https-трафик. В основном по этой причине на практике она часто заменяется консольной версией программы Wireshark Network Analyzer – tshark. Программу tcpdump удобно использовать для сохранения всего трафика в бинарный файл (с ключом -w), а затем полученный файл открывать с помощью Wireshark и других программ.

системный администратор январь-февраль 2017

Карьера/Образование Ключ -i указывает сетевой интерфейс, где будет производиться перехват сетевого трафика. Ключи -n и -nn говорят о том, чтобы сниффер не производил преобразование IPадресов в доменные имена и номера портов (для протоколов TCP и UDP) в имена сервисов, поскольку первое генерирует дополнительные обращения к DNS-сервису, что затратно по времени и трафику. Шаг 2. Расположите окно терминала так, чтобы его было видно во время работы браузера. Возможно, к этому моменту в нём уже будут появляться какие-то записи, соответствующие порциям перехваченного сетевого трафика. Шаг 3. Запустите браузер Mozilla Firefox и перейдите к какому-либо сайту, увидите, что в окне терминала при этом генерируется большое число строк. Обратите внимание, что браузер генерирует собственный трафик ещё до того, как пользователь введёт свой адрес-запрос. Шаг 4. Установим условия фильтрации трафика. Для этого остановите выполнение сниффера нажатием <CTRL> + <C> и запустите его повторно, но с другими параметрами:

лабораторная работа Шаг 6.3. Также будет виден ICMP-трафик: 11:54:01.527325 IP 192.168.1.8 > 192.168.1.7: ICMP echo request, id 60205, seq 1, length 64 11:54:01.527542 IP 192.168.1.7 > 192.168.1.8: ICMP echo reply, id 60205, seq 1, length 64

Шаг 6.4. Информация из ARP-ответов попадает в локальную ARP-таблицу (ARP-кэш, таблицу соседей, neighbour table), откуда она используется компьютером по прямому назначению. Просмотрите свою ARP-таблицу любой из нижеприведённых команд, все они идентичны. Первые две легче запомнить, последнюю короче писать. $ $ $ $ $ $

ip ip ip ip ip ip

neighbour show neighbor show neigh show neigh ne n

Записи с пометкой «FAILED» вида: $ tcpdump -i eth0 -n -nn arp or icmp 192.168.1.42 dev eth0

В результате применения фильтра (запись «arp or icmp») будет отображаться информация, относящаяся лишь к протоколам arp и icmp. Шаг 5. Запустите ещё одно окно терминала и определите в нём свой IP-адрес (тот, что присвоен сетевому интерфейсу eth0) и его подсеть с помощью команды: $ ip address show

Шаг 6. Придумайте несколько IP-адресов, «соседних» с вашим (из той же подсети). Обычно для этого достаточно немного изменить последний разряд. Шаг 6.1. Произведите отправку по два ICMP-запроса типа echo request придуманным получателям с помощью системной утилиты ping, например: $ ping -c 2 192.168.1.8

Шаг 6.2. При отправлении запросов, возможно, вы сможете увидеть строки, показывающие ARP-запросы: 11:38:39.475006 ARP, Request who-has 192.168.1.8 tell 192.168.1.4, length 28

и в зависимости от того, доступен указанный хост или нет, – ARP-ответы: 11:39:48.062291 ARP, Reply 192.168.1.1 is-at XX:XX:XX:XX:XX:XX, length 46

где вместо XX:XX:XX:XX:XX:XX будет содержаться реальный MAC-адрес удалённого узла. Поскольку информация о связи IP-адреса с MACадресом полезна всем хостам (компьютерам) в локальной сети, то она распространяется по локальной сети с использованием широковещательных адресов на канальном уровне. В результате при наличии нескольких хостов в вашей локальной сети вы можете увидеть и «чужой» ARP-трафик.

FAILED

говорят о том, что информации о том, какой MAC-адрес соответствует IP-адресу (в данном случае 192.168.1.42), в таблице нет. Обычно такие записи появляются после попыток обратиться к несуществующим (не отвечающим) узлам подсети. Замечание. Записи в ARP-таблице бывают двух видов: статические и динамические. Первые могут быть добавлены администратором вручную через команду: # ip neigh add 192.168.1.222 lladdr 00:11:22:33:44:55 dev eth0

Впоследствии при отображении ARP-таблицы они будут помечены словом «PERMANENT». Динамические записи попадают в таблицу «из сети». Все записи таблицы периодически проверяются сборщиком мусора (garbage collector), и если долгое время с каким-то IP-адресом нет сетевого обмена или из сети не приходят более свежие ARP-данные, то запись считается устаревшей и удаляется. (Время старения записей можно просматривать и менять через псевдофайловую систему proc: $ cat /proc/sys/net/ipv4/neigh/eth0/gc_stale_time

На каждом сетевом интерфейсе могут быть свои параметры. Подробнее о работе ядра с протоколом ARP см. man 7 arp.) Шаг 7. Остановите выполнение сниффера нажатием <CTRL> + <C> и запустите его повторно, добавив ключ -X (он говорит программе о том, чтобы она выводила содержимое пакетов (первые несколько байт, определяемые параметром -s): $ tcpdump -i eth0 -n -nn -X arp or icmp

Повторите действия шага 6 по отправке ICMPзапросов с помощью утилиты ping. Обратите внимание, что теперь можете видеть не только строчки с сообщениями о получении ICMP- и ARP-запросов и ответов сниффером,

январь-февраль 2017 системный администратор

лабораторная работа но и их шестнадцатеричное содержимое, то есть так, как они передавались по сети. Для удобства восприятия информации байтам с десятичными кодами от 32 до 127 сопоставляются их символы из ASCII-таблицы, которые отображаются в той же строке справа, иные байты (с другими кодами) отображаются как «.». В случае передачи данных (команд) с использованием текстовых сообщений, составленных из латинского алфавита (например, при использовании протокола HTTP), они будут сразу видны. Шаг 7.1. Повторите действия шага 7, добавив при запуске сниффера ключ -e, это отобразит заголовки канального уровня. В результате вы сможете видеть MAC-адреса отправителя и получателя у Ethernet-кадров. В ряде случаев эта информация может быть полезной. Шаг 8. К сожалению, просматривать большие сообщения, как HTTP-трафик, выше описанным способом в окне терминала не предоставляется удобным, поскольку буфер вывода у окна с терминалом ограничен. Для наглядного изучения трафика лучше всего произвести сохранение нужного или всего сетевого трафика в файл, а затем открыть этот файл для анализа в программе с удобным графическим интерфейсом. Запустите сниффер со следующими параметрами: $ tcpdump -i eth0 arp or icmp -w /home/guest/traffic1

Ключ -w с параметром /home/guest/traffic1 указывает программе, в какой файл сохранять трафик. Ключи -n, -nn, -X и -e убраны, поскольку они влияют лишь на отображение информации при выводе её на окно терминала, то есть бессмысленны при сохранении. Шаг 8.1. Повторите отправку ICMP-запросов с помощью утилиты ping из другого окна. Шаг 8.1. Завершите работу сниффера, нажав в его окне комбинацию клавиш CTRL+C. В результате вы увидите результирующую информацию о захваченных пакетах. Шаг 8.1. Убедитесь, что трафик успешно записался в файл /home/guest/traffic1.

Карьера/Образование «веток» используйте интуитивно понятный маленький значок «треугольника» (иногда размер этого поля при отображении равен нулю, то есть его не видно, в этом случае следует воспользоваться мышкой и увеличить отображаемый размер, разделив две слившиеся воедино разделительные линии); > с непосредственным двоичным содержимым полученных Ethernet-кадров (в виде таблицы со строками, в каждой из которых содержатся адрес смещения и 16 шестнадцатеричных значений). Замечание. Полезным свойством такого интерфейса является то, что с его помощью возможно изучать сетевой стек. Совсем не обязательно знать все RFC в части строения сетевых заголовков для того, чтобы ответить на простой вопрос, например: «За что отвечает та или иная группа байт со смещением XX от начала кадра?» Достаточно выделить интересующие байты в третьем поле, как автоматом, во втором поле, будет выделено значение, за которые они отвечают, и наоборот (см. рис. 6). Шаг 10. С помощью Wireshark и файла с дампом трафика ответьте на вопросы: Шаг 10.1. Что идёт первым в Ethernet-кадре: MAC-адрес отправителя или MAC-адрес получателя? Шаг 10.2. С каким смещением от начала Ethernet-кадра в нём содержится IP-адрес получателя ICMP-сообщения типа echo request? Рисунок 4. Окно запроса, появляющееся при запуске программы Wireshark Network Analyzer от обычного пользователя, на запуск программы с привилегиями администратора

$ ls -l /home/guest/traffic1 -rw-rw-r--. 1 guest guest 198 Янв

4 13:32 /home/guest/traffic1

Шаг 9. Запустите Wireshark Network Analyzer из меню «Приложения → Интернет». На запрос запуска программы с административными привилегиями (см. рис. 4) выберите пункт «выполнить без привилегий». Если «возможности» при настройке стенда были настроены правильно, то в появившемся окне программы будет доступен для выбора сетевой интерфейс eth0 (см. рис. 5). Шаг 9.1. Находясь в окне программы, нажмите <CTRL> + <O> или выберите пункты меню File → Open... Шаг 9.2. Откройте файл /home/guest/traffic1, созданный на шаге 8. Шаг 9.3. В результате вы увидите три поля (см. рис. 6): > со списком полученных Enternet-кадров (подобно списку почтовых сообщений, выбор этого поля влияет на содержимое двух последующих полей); > с разобранными значениями полученного содержимого в виде нескольких иерархических деревьев. Деревья обычно «свёрнуты», для разворачивания их и просмотра

системный администратор январь-февраль 2017

Рисунок 5. Фрагмент окна программы Wireshark Network Analyzer, где виден список доступных сетевых интерфейсов (под словом «Start»)

Карьера/Образование Шаг 11. Уберём из логической цепочки сетевой интерфейс – tcpdump – файл_с_дампом – Wireshark два средних звена. Для этого запустите перехват трафика на интерфейсе eth0 непосредственно из программы Wireshark (меню программы → Capture → Interfaces... → Поставить галочку напротив eth0 → Start). Шаг 12. Запустите браузер Mozilla Firefox и по протоколу HTTP обратитесь к какому-нибудь сайту, работающему по этому протоколу, например http://samag.ru. Шаг 12.1. Совершите несколько переходов по ссылкам внутри сайта. Шаг 12.2. Перейдите на сайт https://www.yandex.ru. Шаг 12.3. Введите в поиске какое-нибудь слово. Шаг 13. Остановите перехват трафика (меню программы → Capture → Stop). Шаг 14. Изучите перехваченный сетевой трафик. Шаг 14.1. Найдите в трафике HTTP GET-запрос к серверу, обслуживающему сайт http://samag.ru (передаваемая строка GET / HTTP/1.1). Шаг 14.2. Какое значение параметра User-agent было передано серверу? Шаг 14.3. Найдите другие GET-запросы. Шаг 14.4. Найдите в ответах сервера фрагменты HTMLстраниц. Шаг 14.5. Найдите обращения к серверу, обслуживающему сайт www.yandex.ru. Шаг 14.6. Возможно ли среди запросов найти то слово, по которому вы запросили поиск у Яндекс на шаге12.3? На поставленный вопрос (шаг 14.6) однозначный ответ – «нет», поскольку протокол HTTPS подразумевает шифрование трафика между клиентом (браузером) и веб-сервером. Дешифрованием собственного трафика в целях его изучения, поскольку это не тривиальная задача, мы заниматься не будем, как и не будем использовать mitmproxy, SSLstrip (SSLStrip+) и иные подобные программы, а воспользуемся

лабораторная работа более простым методом. Не вдаваясь в нюансы работы браузера с протоколами HTTPS, TLS, SSL, мы сделаем следующее: через переменную окружения SSLKEYLOGFILE [6] укажем браузеру (а точнее, набору библиотек NSS, которыми пользуется браузер) вести журнал, куда будет сохраняться необходимая ключевая информация (RSA pre-master secrets) при использовании протокола TLS. Впоследствии мы передадим эту информацию программе Wireshark. Указанная схема довольно неплохо описана на различных страницах в интернете [7-9]. Она не работает с некоторыми версиями Firefox от ~ 48 и до 50 (не включительно), где использование указанной переменной окружения отключено при компилировании [10]. Возможное решение – использование отладочной сборки или перекомпиляция. Вроде бы осталось дело за малым – повторить хорошо расписанную схему, но, увы, независимо от версии браузера и системы с большинством сайтов (в том числе и с используемым нами https://www.yandex.ru) она не работает. Для того чтобы успешно просмотреть трафик, необходима ещё одна хитрость. Дело в том, что ведение SSL-журнала работает для стандартной схемы HTTPS, которая предполагает выработку открытых ключей с использованием алгоритма RSA. При таком подходе браузер клиента выбирает случайный ключ для сессии, зашифровывает его с помощью открытого ключа сервера, подписывает своим закрытым ключом и отправляет на сервер. При этом клиент может сделать копию ключа в файл SSL-журнала. Сессия связи с сервером считается безопасной, но она оказывается не защищена от будущей потери секретного ключа сервера. Многие сайты сейчас всё чаще вводят защиту от будущей потери секретного ключа (функция называется perfect forward secrecy или сокращённо PFS). При этой новой схеме используются недолговечные («эфемерные») сеансовые ключи, которые обмениваются по схеме ECDHE

Рисунок 6. Три поля в окне программы Wireshark Network Analyzer, синхронное выделение в нескольких полях

январь-февраль 2017 системный администратор

лабораторная работа («эфемерный алгоритм Диффи-Хеллмана с использованием эллиптических кривых») [11], гарантирующей, что даже в случае компрометации секретного серверного ключа злоумышленник не сможет расшифровать ранее перехваченный и записанный HTTPS-трафик. На практике это выливается в то, что не клиент, а сервер для каждой сессии генерирует новый открытый ключ и подписывает его своим закрытым ключом. Естественно, что с сервера этот ключ никоим образом не может попасть в файл-журнал на стороне клиента, что и усложняет жизнь для анализа трафика. Поэтому на шаге 15 прибегнем к небольшой хитрости, обязав браузер клиента, а вместе с ним и сервер, использовать схему, при которой сеансовый ключ вырабатывается на стороне клиента. Шаг 15. Зайдите в браузере на адрес about:config. Шаг 15.1. На появившееся предупреждение ответьте согласием, что вы «обещаете, что будете осторожны». Шаг 15.2. В строке поиска введите ssl3 (см. рис. 7). Шаг 15.3. Измените состояние значений параметров следующим образом. Для параметров: > security.ssl3.rsa_aes_128_sha > security.ssl3.rsa_aes_256_sha > security.ssl3.rsa_rc4_128_md5 > security.ssl3.rsa_rc4_128_sha установите значение в true, для всех остальных – false. Запишите первоначальные настройки, чтобы после можно было вернуть систему в исходное состояние. Шаг 15.4. Закройте браузер. Шаг 16. Убедитесь, что все окна браузера firefox закрыты и все браузерные процессы завершены. После закрытия окон для завершения случайно оставшихся процессов с именем firefox выполните команду: $ killall firefox

Шаг 17. Создайте файл /home/guest/ssl.log, который будет журналом для SSL-сессии:

Карьера/Образование Шаг 21. Зайдите на сайт https://www.yandex.ru и произведите поиск каких-нибудь ключевых слов. Если слова будут набраны латинскими буквами, то это упростит последующий их визуальный поиск среди перехваченного трафика.

Вы сможете правильно соотнести указанные протоколы с их уровнями в сетевой модели и лучше поймёте строение пакетов, дейтаграмм и кадров, а также механизма добавления заголовков при «опускании» данных с верхних уровней на нижние Шаг 22. Остановите перехват трафика в сниффере Wireshark и изучите перехваченный трафик. Шаг 22.1. Найдите среди перехваченного трафика обращения к DNS-серверу и ответ от него. Шаг 22.2. Обратите внимание, что при просмотре записей первого окна у тех записей, у которых в поле Protocol записано HTTP, и у некоторых других в третьем поле, а точнее, под ним, возможно появление дополнительных вкладок: Frame, Reassembled TCP, Decrypted SSL data, Decrypted SSL record и Reassembled SSL. Шаг 22.3. В целом исследование расшифрованного HTTPS-трафика не сложнее анализа обычного HTTP. Попытайтесь найти переданные поисковой системе запросы. При использовании формата URL encoded format русские буквы (кириллица) сначала кодируются с помощью UTF-8, а затем перед шестнадцатеричными значениями байтов прописывается знак %. Знак пробела – %20.

$ touch /home/guest/ssl.log

Шаг 18. Перейдите в свойства программы Wireshark (меню программы → Edit → Preferences...) или нажмите <Shift> + <Ctrl> + <P>. Шаг 18.1. В появившемся окне выберите в пункте Protocols протокол SSL. Шаг 18.2. В группе элементов Security Socket Layer в поле (Pre)-Master-Secret log filename пропишите имя /home/guest/ ssl.log либо выберите этот файл мышкой через кнопку «Browse...» (см. рис. 8). Шаг 18.3. Нажмите «Ok» для закрытия окна настроек. Шаг 19. Запустите в сниффере перехват трафика на интерфейсе eth0. Весь ранее перехваченный трафик можно не сохранять (Continue without Saving). Шаг 20. Запустите браузер из окна терминала командой:

Рисунок 7. Настройка браузера Firefox, выбор алгоритмов, разрешённых к использованию

$ SSLKEYLOGFILE=/home/guest/ssl.log firefox &

Шаг 20.1. Обратите внимание, что браузер ещё до ввода адреса пользователем осуществляет сетевой обмен.

системный администратор январь-февраль 2017

Карьера/Образование Шаг 23. Верните систему к состоянию «до начала работы». Шаг 23.1. Запустите браузер Mozilla Firefox и зайдите по адресу about:config. В поле поиска введите ssl3. У всех параметров, отключённых на шаге 15.3, пропишите true. Закройте все окна браузера. Шаг 23.2. Зайдите в настройки сниффера и удалите имя файла, добавленное на шаге 18.2. Шаг 23.3. Если интересно, то просмотрите содержимое файла /home/guest/ssl.log $ cat /home/guest/ssl.log

Шаг 23.4. Удалите файлы, созданные в процессе работы: $ rm -f /home/guest/traffic1 $ rm -f /home/guest/ssl.log

В результате вы получили первичные навыки работы со средствами визуальной диагностики сети – снифферами, которые использовались для просмотра передаваемого трафика. Увидели на практике, как выглядит трафик протоколов ARP, IP, ICMP, DNS, HTTP и HTTPS. Теперь сможете правильно соотнести указанные протоколы с их уровнями в сетевой модели и должны лучше понимать строение пакетов, дейтаграмм и кадров, а также механизма добавления заголовков при «опускании» данных с верхних уровней на нижние. EOF [1] Яремчук С. Расширяем права доступа в Linux с помощью ACL.// «Системный администратор», №11, 2005 г. – С. 54-59 (http:// samag.ru/archive/article/582). [2] Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. – 4-е изд. – СПб.: Питер, 2010. – 944 с.: ил., ISBN 978-5-49807-389-7, с.113-123. [3] Грошев А.С., Закляков П. В. Информатика: учеб. для вузов. – 3-е изд., перераб. и доп. – М.: ДМК Пресс, 2015. – 588 с., ISBN 978-5-97060-304-8, с. 462-464.

лабораторная работа [4] TCP/IP illustrated. – 2nd ed. / Kevin R. Fall, W. Richard Stevens, Adison-Wesley, 2011, ISBN 978-0-321-33631-6, с. 8-19. [5] Стивенс У.Р. Протоколы TCP/IP. Практическое руководство/ пер. с англ. и коммент. А.Ю. Глебовского. – СПб.: Невский Диалект – БХВ-Петербург, 2003. – 672 с.: ил., ISBN 5-7940-0093-7, ISBN 5-94157-300-6, с. 30-33. [6] NSS environment variables – https://developer.mozilla.org/enUS/docs/Mozilla/Projects/NSS/Reference/NSS_environment_ variables. [7] Decrypting TLS Browser Traffic With Wireshark – The Easy Way! – https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-withwireshark-the-easy-way. [8] Анализ SSL/TLS-трафика в Wireshark – https://habrahabr.ru/ company/billing/blog/261301. [9] Как легко расшифровать TLS-трафик от браузера в Wireshark – https://habrahabr.ru/post/253521. [10] Bug 1188657 - Keep SSL/TLS key logging working with all Firefox builds from Mozilla – https://bugzilla.mozilla.org/show_bug. cgi?id=1188657. [11] Google улучшает защиту SSL-сессий – https://habrahabr.ru/ post/133268. [12] NSS Key Log Format – https://developer.mozilla.org/en-US/docs/ Mozilla/Projects/NSS/Key_Log_Format. [13] Как запустить сниффер wireshark от обычного пользователя – http://askubuntu.com/questions/74059/how-do-i-run-wiresharkwith-root-privileges, http://packetlife.net/blog/2010/mar/19/sniffingwireshark-non-root-user. [14] Decoding TLS with PHP – https://www.adayinthelifeof.nl/2013/12/30/ decoding-tls-with-php. [15] Psst. Your Browser Knows All Your Secrets (формат файла SSLKEYLOGFILE) – https://isc.sans.edu/forums/diary/Psst+Your+B rowser+Knows+All+Your+Secrets+/16415. [16] SSL/TLS: What's Under the Hood – https://www.sans.org/readingroom/whitepapers/authentication/ssl-tls-whats-hood-34297. Ключевые слова: SSL, сниффер, Linux, перехват трафика, лабораторная работа.

Рисунок 8. Указание программе-снифферу при работе с протоколом SSL для расшифровки трафика использовать ключи из файла

100

январь-февраль 2017 системный администратор

особое мнение

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

ВЛАДИМИР ИВАНОВ, специалист по информационной безопасности. Увлекается психологией, историей, философией

Приближающаяся смерть организации

Как ее распознать и как избежать последствий?

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

Обычно срок жизни российской фирмы не превышает трех лет. При этом не всегда следует винить именно экономические или политические факторы. Два, максимум три года – это как раз тот самый промежуток времени, когда можно успеть «снять сливки» в виде высоких доходов, вывести деньги из оборота и бросить организацию медленно умирать. Большинство предприятий на территории бывшего СССР занято так называемым обезьяньим бизнесом, проще говоря: «Схватил и – на дерево!» Такие экономические смерти очень больно ударяют по благополучию наемных работников. Поэтому важно иметь возможность узнать заранее о предстоящей кончине и успеть к ней подготовиться. Разумеется, сами по себе признаки, описанные в данной статье, поодиночке не могут послужить основой для «далеко идущих выводов». Но в совокупности это верный признак предстоящей ликвидации. Стоит также напомнить, что описанные в статье явления сами по себе имеют разрушительную силу. Например, постоянные неплатежи наносят урон репутации компании, ненужный дополнительный контроль демотивирует сотрудников, бесполезные затраты подтачивают и без того слабые финансовые основы, а провальная кадровая политика толкает организацию в пропасть. Часто причина подобных «мероприятий» кроется в неспособности улучшить финансовую ситуацию и судорожных попытках «сделать хоть что-то» для того, чтобы оправдаться перед вышестоящим начальством или учредителями. Поэтому, если вы встретили три и более приводимых ниже признака, – это верный знак того, что настало время подыскивать новую работу. Если вы обратили внимание, то я по большей части использую термин «организация». Дело в том, что рассматривать только частные коммерческие организации будет не совсем верно. В эпоху политической нестабильности соответствующее «судьбоносное решение» может быть принято и по отношению к субъектам, традиционно являющимся государственными.

системный администратор январь-февраль 2017

Например, закрытие института, имеющего статус государственного образовательного учреждения, ликвидация общественной организации и т.д. Но тем не менее предвестниками скорой гибели являются практически те же признаки, что и в случае с частными коммерческими компаниями. Надо отметить, что предсмертное состояние российских организаций сильно отличается от своих зарубежных аналогов. Например, состояние «Непризавит, или болезнь Паркинсона» [1], описанное в книге журналиста, порой сильно отличается от ситуации, когда российское предприятие уже бьется в предсмертных судорогах. Организация, пораженная «непризавитом», может существовать достаточно долго, и этот вариант сильно отличается от нашей действительности, когда от появления первого из предсмертных признаков до фактической ликвидации может пройти всего лишь две недели. В то же время появление смертельных признаков может быть следствием серьезных проблем, но организация, как и случай, описанный Паркинсоном, может прожить достаточно долго. Да, она никогда не вернет себе былую славу и величие, но сможет влачить жалкое существование довольно длительное время. Все, что описано в этой книге, я имел честь лично наблюдать в организациях, где довелось работать. Срок от появления первого признака из данного списка до полной ликвидации организации – в среднем примерно один год. Но это именно средняя величина. Многое зависит от размера компании. Большая организация, как большой корабль, может достаточно долго оставаться на плаву, даже после того как большинство членов команды его покинет. Еще важное значение имеют внешние факторы. Например, если организация имеет военную специфику, то ее могут время от времени подкармливать финансовыми вливаниями просто так, на всякий случай. Одинаковых ситуаций, как и готовых рецептов, не бывает, но всегда стоит в очередной раз подумать над вопросом: «А что я здесь делаю?»

101

Карьера/Образование Признаки скорой смерти организации Усиленный контроль дисциплины Трудовая дисциплина – один из успехов благополучия. Осуществлять определенный контроль, например вовремя вернуть ту или иную «заблудшую овцу» на «путь истинный», совсем неплохо.

Нужно быть более гибким и не упускать возможности перейти туда, где больше платят, лучше условия труда, больше перспектив на повышение… Другое дело, когда повышенный контроль начинается вопреки здравому смыслу. Например, регистрируется время прихода на работу с точностью до минуты. Вводится система штрафов за любое опоздание, в том числе по причинам, ранее считавшимся если не уважительными, то «простительными», например автомобильные пробки. Запрещается прием пищи в рабочее время, даже чашка чая с бутербродом возводится в разряд страшного нарушения трудовой дисциплины. Устанавливается программа контроля за действиями сотрудника на компьютере. Тщательно анализируется интернет-трафик на предмет «посторонних» сайтов. Сюда же можно отнести требования по дресс-коду, «корпоративной культуре» и прочим любым «игрушкам» для отдела персонала. При этом все нововведения преподносятся с большим апломбом – например, собирается общее собрание или собрание всех руководителей подразделений, делается общая почтовая рассылка и прочее, прочее, прочее… Подобное закручивание гаек происходит без особых поводов. Мне приходилось сталкиваться с ситуациями, когда начальство впадало в «праведный гнев», например, после выявления коллективного распития спиртных напитков в рабочее время. Но даже в таких «тяжелых» ситуациях вполне можно обойтись обычными мерами, указанными в Трудовом кодексе, без лишнего шума и истеричных распоряжений. Самое интересное, что наличие подобных мер само по себе способно приблизить крах организации. Такие «улучшения» приводят только к одному результату – мощной демотивации всего персонала. Когда мысли большинства членов коллектива заняты не рабочим процессом, а стремлением избежать очередного «нарушения», плачевный результат не заставит себя долго ждать.

Мелочный контроль за рабочим процессом Попытка контролировать «все и вся» берет свое начало от тотального недоверия и стремления судить о людях исходя из собственных пороков.

102

особое мнение Возьмем, к примеру, требование составлять краткосрочные планы и отчитываться за их исполнение. Сама по себе идея планирования очень хорошая, но вопрос: для чего это нужно и сколько времени это отнимает? Например, высчитывание с точностью до минуты, сколько времени займет переустановка операционной системы или замена комплектующих, без какого-либо запаса по времени на непредвиденные ситуации и сбои. Или сколько времени должно занять сведение годового баланса у бухгалтерии. Но особенно впечатляют попытки точного планирования творческих задач. Например, сколько времени с точностью до получаса уйдет на формирование новой маркетинговой стратегии предприятия? Или разработки новой комплексной системы корпоративной безопасности с учетом изменяющихся факторов? Другой вариант: написание отчетов о проделанной работе. Разумеется, тоже дело нужное, но только когда речь идет о чем-то большом. Например, отчет о внедрении комплексной системы безопасности. Или отчет о проделанной работе службы технической поддержки. С цифрами, фактами, вопросами для размышления… Когда начальство начинает вводить практику кратковременной отчетности наподобие: «Я, имя-фамилия-отчество, за прошедший месяц потратил столько-то времени на это, столько-то времени на то…» – очевидно, что особенной практической пользы это не имеет. При этом затрачивается довольно ощутимая часть рабочего времени. Мне приходилось иметь дело с организацией, в которой каждое подразделение три последних дня в месяц отводило под написание ежемесячных отчетов. Остальная работа в это время практически не выполнялась, так как все были заняты написанием подробных отчетов. За «плохой» (с точки зрения начальства) отчет можно было лишиться премии. А потерянный клиент – вещь не такая страшная… Понятное дело, что, кроме общего раздражения всех участников бизнес-процессов, подобная практика ни к чему не приведет. И, разумеется, демотивация и безумные растраты самого драгоценного ресурса – времени – не заставят долго ждать результата.

Попытка внедрения новой управленческой программы Рано или поздно начальству приходит в голову мысль, что все проблемы в организации – от неправильного управления. И это, по большей части, верно. Только выводы делаются абсолютно противоположные. В конце концов кто-то из руководства выдвигает идею, что если купить чтото такое «для современного управления», то все вопросы отпадут сами собой. Срабатывает очередная вера в чудо: «Вот купим, внедрим, настроим и заживем!» В итоге приобретается очередная суперсистема электронного документооборота и контроля исполнения поручений, планирования, отчетности и еще много-много чего. И начинается мучительный процесс внедрения. Далеко не все сотрудники рады подобным нововведениям. Как правило, это добавляет им дополнительной работы и требует повышенного внимания. В ход идут различные методы противодействия вплоть до саботажа и прямого вредительства. Сотрудники ИТ-подразделений оказываются между двух

январь-февраль 2017 системный администратор

особое мнение

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

Повышать профессиональный уровень, несмотря ни что, иначе потеря рабочего места болезненно скажется на вас

огней: надо бы и продукт новый внедрить, и с коллективом не поссориться. В итоге все происходит, как в известной басне: «…а воз и ныне там…» При этом затраты на эту чудесную систему отнюдь на маленькие: помимо непосредственно стоимости при покупке, деньги уходят на обслуживание программного решения, модернизацию серверного оборудования и так далее. Но самые ощутимые потери – совокупные затраты рабочего времени сотрудников как во время внедрения (обучение, адаптация, устранение ошибок), так и во время самой эксплуатации. Для организации, которая и так одной ногой в долговой яме, внедрение подобной системы в итоге оказывается тем самым последним ударом лома по голове, после которого шансы на выживание уже равны нулю.

Изменение системы мотивации О негативных последствиях внедрения различных «мотивационных схем» можно прочесть в моих предыдущих статьях [2, 3]. В данном случае стоит рассматривать самую простую и опасную для работников схему – разделение заработной платы на «постоянную» и «премиальную» части с перспективой невыплаты «премиальной» части по любому «удобному» поводу. Разумеется, наемным сотрудникам расскажут красивую легенду о том, что это делается ради их же блага, что теперь появилась возможность выделить лучших, и много других умных слов. Но гораздо более точно происходящее можно охарактеризовать двумя словами – «позолоченная виселица». На самом деле идет планомерная подготовка нормативной базы для резкого снижения затрат на выплату зарплаты, а также уменьшения обязательных выплат при банкротстве.

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

системный администратор январь-февраль 2017

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

Вводится повышенный режим секретности Разумные меры по обеспечению информационной безопасности не просто очень желательны, но и жизненно необходимы в любой организации. Соблюдение простых правил, например использовать сложные пароли и никому их не сообщать, не перемещать информацию за пределы информационного периметра, не посещать подозрительные сайты и не использовать программы сомнительного происхождения, позволит избежать серьезных проблем, связанных с утечкой ценных данных. Но мы говорим о ситуации, когда руководство внезапно посещает своеобразная паранойя. Например, в срочном порядке заменяются все административные пароли, часть сотрудников ИТ-отдела, ранее по служебной необходимости имевших доступ к различным ресурсам, его лишается. На рядовых работников сваливается масса новшеств вроде запрета на просмотр писем на бесплатных почтовых ресурсах. Запрещается многое из того, что ранее было разрешено – например, использовать Skype даже для рабочих целей, личные мобильные телефоны и так далее. Зато вводится множество средств контроля, слежения, прослушивания и других «приятных неожиданностей». Важны и повышенные требования к работе ИТ-отдела – хранить информацию только на зашифрованных разделах, использовать дополнительные средства аутентификации и так далее.

103

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

Безумная экономия и просто отказы платить Перебои с деньгами могут быть замаскированы различными способами. Например, бухгалтерия (чаще всего главный бухгалтер) начинает придираться к каждой мелочи. Не так оформлена служебная записка, цены в служебной записке и запрошенном сете отличаются (даже если цена по факту меньше – все равно нельзя). Под предлогом «высокой загруженности» бухгалтерии нельзя приносить счета на оплату чаще одного раза в день, неделю, месяц… В общем, ставятся любые условия, лишь бы в очередной раз отсрочить, а то и вовсе проигнорировать любой «не своевременный» платеж. Происходит возвеличивание роли бухгалтера. Общение с этим подразделением становится непростым занятием. Теперь к его сотрудникам нужно «уметь найти подход», «знать, когда лучше обратиться», и все с одной-единственной целью – чтобы оплатили «без проволочек». Еще одна попытка подобной маскировки – требование «экономического обоснования». Например, просьба установить новую материнскую плату в компьютер, потому что время от времени происходит сбой и приходится перезагружать компьютер. Для ее закупки нужно привести анализ трудозатрат сотрудника, количество потерянных человеко-часов в месяц в сравнительном пересчете на стоимость материнской платы. Одновременно с этим происходят попытки экономить на всем, что можно: на закупке расходных материалов, на ремонте и профилактике работы оборудования, на уборке офиса… Со стороны отдела персонала появляются замечательные «инициативы» о проведении добровольно-принудительного «субботника» в качестве «подарка ко дню компании» или просто «по уборке территории», «подготовке к зиме», «наведению порядка в документах» и тому подобное. Сюда же можно отнести внезапное пропадание мыла из туалетов, сломанные и не ремонтируемые смесители и сушилки для рук, не прочищаемые засоры канализации, вечно ломающаяся старая техника, изношенные клавиатуры и мыши и другие прелести предбанкротного состояния.

Непонятные траты На фоне экономии «на скрепках» в организации начинают осуществляться довольно загадочные затраты, идущие порой вразрез со здравым смыслом. Например, зачем-то делается дорогостоящий ремонт в офисе, расположенном в арендуемом (!) помещении.

104

особое мнение Или приобретается новая компьютерная техника (чаще всего топовые модели ноутбуков) для руководства и «лиц, допущенных к столу».

Закупается новая дорогая мебель в кабинеты И все это на фоне общих финансовых «затруднений». В общем, ситуация во многом начинает напоминать «пир во время чумы». Честно говоря, я сам не всегда знаю, зачем это делается. Возможно, руководство организации и «дружественные персоны» получат с этого «откаты» или оставят дорогую технику себе. Порой это происходит на фоне желания внушить окружающим и самим себе мысль, что все не так уж и плохо. Важно только одно: если на фоне общей не слишком впечатляющей обстановки имеют место подобные затраты – жить организации осталось недолго.

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

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

январь-февраль 2017 системный администратор

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

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

Ну, хорошо, узнали о скором крахе. И что теперь делать? Избавиться от предрассудков На самом деле ни работа в какой-то компании, ни профессия, ни образ жизни, ни место проживания в конечном итоге не имеют никакой ценности. Нужно быть более гибким и не упускать возможности перейти туда, где больше платят, лучше условия труда, больше перспектив на повышение… Порой приходится слышать: «Я работаю в этой фирме уже… лет», «Моя профессия – моя жизнь», «Где родился, там и пригодился», «Это мое призвание, я должен быть тем, для чего я создан» и самое страшное: «Нас нигде не ждут». В таких ситуациях мне просто хочется крикнуть: «Послушайте, но ведь когда ваша жизнь подойдет к концу, к вам не прилетит ангел и не скажет: «Твоя жизнь была прожита по чужим правилам, вот тебе еще 10 лет, поживи в свое удовольствие!» Внушая мысли о «преданности», «лояльности», «призвании», «долге» и тому подобных возвышенных словах, общество и власти предержащие просто манипулируют людьми. Важно понимать, где кончается манипуляция и начитаетесь лично вы. И нравится ли вам такая жизнь? Нравится ли это вашим родным? Какое будущее вы уготовили своим детям? Что вы оставите своей семье после смерти? Сможет ли оставшееся после вас наследство прокормить вашу стареющую «вторую половинку»? Что вы будете делать, когда один из членов вашей семьи заболеет тяжелым недугом? Может ли ваша работа, ваша профессия, ваше так называемое призвание обеспечить нужную сумму для его лечения?

системный администратор январь-февраль 2017

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

Нужно постоянно изучать «работные сайты», не только в своей стране, но и зарубежные, чтобы иметь правильное представление о текущем состоянии дел на рынке труда Нежелание изменить свою жизнь – порой не более чем слабость духа. Те, кто остался, зачастую просто трусливее и слабее. Они могут сколько угодно кидать упреки: «Ушел, бросил, спасовал перед трудностями…» Но это всего лишь очередная завистливая мантра, направленная на самоуспокоение тех, кто не смог решиться на перемены.

Внимательно следить за ситуацией на рынке труда Нужно постоянно изучать «работные сайты», не только в своей стране, но и зарубежные, чтобы иметь правильное представление о текущем состоянии дел на рынке труда. Но не стоит полностью доверять различным исследованиям, мнениям экспертов, результатам опросов и так далее. Помните, что у любой такой акции есть заказчик, который может пытаться искусственно вводить в заблуждение аудиторию. Например, сгущать краски относительно сложности трудоустройства в «кризис» с целью удержать людей, работающих за копейки. Или, наоборот, скрыть за бравурными отчетами реальные показатели безработицы и нищеты населения.

Повышать свой профессиональный уровень, несмотря ни на что Да, бывает трудно, и денег нет, в том числе на новое оборудование, дорогостоящие курсы и просто на пособие по интересующему предмету, но надо поддерживать профессиональный уровень. Иначе потеря рабочего места очень болезненно скажется на вашем положении. Поиск работы займет больше времени, а постепенно деградирующий специалист никому особо не нужен. EOF [1] Паркинсон С. НЕПРИЗАВИТ, или Болезнь Паркинсона – https:// psy.wikireading.ru/48395. [2] Иванов В. Безопасное трудоустройство. Часть 3. Что помогает или мешает работать и зарабатывать. //«Системный администратор», № 1-2. 2014 г. – С. 120-123 (http://samag.ru/archive/ article/2625). [3] Иванов В. Люди – не белки!// «Бизнес и информационные технологии», № 7, 2016 г. – С. 42-48 (http://bit.samag.ru/archive/ article/1732).

105

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

ретроспектива

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

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

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

Ударенный молнией с рождения И сегодня до конца не ясно, что на самом деле изобрел и открыл гениальный серб. А что ему лишь приписывают любители конспирологии, ссылаясь на сенсационные заявления самого Теслы, впоследствии ничем не подкрепленные. Его заслуги в «приобщении» всего цивилизованного мира к переменному току неоспоримы. Как не вызывают споров открытие им вращения магнитного поля, разработка многофазных электрических машин, генераторов, трансформаторов и других приборов. А вот был ли Тесла также и «отцом» радио, роботехники, радара, компьютера, лазерного оружия, единой теории поля и много чего еще – одно фантастичнее другого! – попрежнему большой вопрос. Карьера Теслы-бизнесмена столь же путана и экстравагантна, что и Теслы-ученого. Автор десятков патентов, сделавший свой первый миллион в сорокалетнем возрасте, он почти не интересовался деньгами, инвестируя все свои доходы от патентов в научные разработки. Один только контракт с компанией Westinghouse мог бы превратить Николу Теслу в первого в мире долларового миллиардера (раньше Рокфеллера). Но гордый серб расторг контракт – по причинам, о которых будет рассказано ниже. К концу жизни великий изобретатель, неоднократно выдвигавшийся на Нобелевскую премию и так ее и не получивший, оказался в долгах, а его компании неизменно лопались. Зато сегодня как минимум три европейские компании, к которым Тесла не имел никакого отношения, с гордостью носят его имя. Как же – бренд! Самый выдающийся серб в истории родился в 1856 году в хорватской деревушке Смилян, входившей в состав Австро-Венгрии, в семье православного священника. По семейной легенде мальчик появился на свет ровно в полночь – вместе с ударом молнии. Начальную школу-четырехлетку

106

вундеркинд закончил за три года, потом учился в гимназии, а затем поступил в Австрийский политехнический институт в Граце. На третьем курсе Тесла, успевший заинтересоваться переменным током, бросил институт и по необъяснимым причинам (таковых в его жизни наберется великое множество) покинул Грац, ничего не сообщив семье. Позже Тесла объявился в словенском Мариборе, где поступил на работу помощником инженера-электрика. Успев за год работы пережить нервное потрясение, «парень со странностями» по настоянию отца поступил в пражский Университет Карла-Фердинанда, где, в частности, слушал лекции знаменитого австрийского физика и философа Эрнста Маха. А всего через год, после получения известия о смерти отца, бросил и это учебное заведение и в 1881м перебрался в Будапешт, где получил место в Национальной телефонной компании. Там он сделал недурную карьеру, покинув компанию уже главным инженером-электриком и автором первого изобретения – по мнению некоторых авторов, первого в мире громкоговорителя. Затем изобретателя ждал Париж, где Тесла, работая в европейском отделении компании Эдисона, увлекся проблемой получения переменного электрического тока с помощью помещенного в магнитное поле механического генератора с вращающейся деталью – ротором. В эти же годы впервые дали себя знать определенные странности в поведении Теслы. Обладая фотографической памятью, он часто жаловался на различные видения и галлюцинации. Любопытно, что все свои будущие изобретения Тесла сначала мысленно «видел» – целиком, до последней детали. После чего реализовывал эти мысленные образы сразу в окончательном виде, без проб и доводок (это и называется образным мышлением). Тяжело пережив смерть матери в 1882-м, Тесла спустя два года объявился в Нью-Йорке, имея в кармане лишь рекомендальное письмо к Томасу Эдисону от руководителя его европейского филиала. Бывший начальник Теслы писал своему собственному боссу: «Я знаю всего двух великих людей, и вы один из них. А второй – тот юноша, что передаст вам это письмо». В компании Edison Machine Works

январь-февраль 2017 системный администратор

ретроспектива новичок быстро прошел путь от рядового инженера-электрика до главного специалиста. В частности, ему было поручено создать новые, более мощные и коммерчески более выгодные генераторы тока вместо тех, что разработал сам Эдисон. По утверждениям Теслы, за эту работу Эдисон посулил ему аж $50 тыс. – в те времена огромные деньги (эквивалентные нынешнему $1 млн). Однако когда Тесла, в процессе работы «подаривший» компании несколько прибыльных патентов, заикнулся об оговоренной сумме, то услышал в ответ: «Тесла, вы не поняли – это американская шутка!» Многие авторы считают, что все это Тесла просто придумал (сумма бонуса уж больно запредельная – превышала более чем полувековую зарплату Теслы, составлявшую $18 в неделю) для оправдания своего ухода из компании Эдисона. Зато достоверно известно, что последний отказался повысить еженедельный оклад Теслы до $25. Как бы то ни было, их взаимную антипатию, продолжавшуюся до конца дней обоих и порой перераставшую в открытую ненависть, трудно объяснить простым соперничеством двух великих изобретателей.

Перемена участи В чем еще категорически не сошлись Эдисон с ТесНикола Тесла в своей лаборатории лой, так это в представлениях о том, за каким электрическим током будущее. Эдисон (как и подавляющее большинство специалистов и предпринимателей) считал, что за «проверенным» – постоянным, а Тесла еще со студенческих лет «запал» на переменный ток. Создав в 1886 году собственную компанию Tesla Electric Light & Manufacturing в целях разработки генераторов переменного тока, упрямый серб натолкнулся на тотальную обструкцию со стороны инвесторов. В результате они добились смещения Теслы с руководящих постов в его же компании, и целый год он не гнушался работать поденщиком, копя деньги на дальнейшие эксперименты. В 1887 году он построил первый индуктор переменного тока, год спустя продемонстрировав его работу в Американском электроинженерном институте (ныне Институт инженеров электротехники и электроники – IEEE). И в том же 1888-м разработал принципы «именного» трансформатора, который теперь называют «катушкой Теслы», и поступил на работу к Джорджу Вестингаузу – коллеге-изобретателю и главе Westinghouse Electric & Manufacturing Company. Вестингауз оказался одним из немногих, кто поверил в идеи Теслы (и, между прочим, без колебаний купил четыре десятка патентов последнего, заплатив за каждый по $25 тыс.). Особенно «приглянулись» предпринимателю идеи Теслы насчет многофазных систем, частным случаем которых является хорошо всем знакомая трехфазная. Любопытно, что за год до этого Тесла начал экспериментировать с излучением, которое пять лет спустя независимо

системный администратор январь-февраль 2017

Карьера/Образование откроет Вильгельм Рентген, именем которого они и названы! Он даже послал, по его словам, Рентгену первый сделанный рентгеновский снимок кисти руки. Однако свои результаты Тесла не опубликовал, а записи его экспериментов погибли в пожаре, который случился в его нью-йоркской лаборатории на Пятой Авеню в марте 1895-го. В результате вся слава вкупе с Нобелевской премией досталась немецкому физику. Впрочем, вся эта история – как и множество других таких же – известна лишь со слов самого Теслы. В 1891 году он получил наконец американское гражданство. А спустя год – свой первый патент на изобретение многофазных электрических систем. Затем последовали генератор переменного тока (впечатляющая демонстрация его состоялась на Всемирной выставке 1893 года, где Тесла с Вестингаузом обеспечили грандиозную иллюминацию сразу нескольких павильонов), гипнограф (прибор, погружающий пациента в сон), беспроводные разрядные лампы. К концу 1880-х изнурительная конкурентная война между компаниями Вестингауза (который продвигал на рынок приборы переменного тока) и Эдисона (всячески этому противившегося) чуть было ни привела обе компании к банкротству. Видя такое развитие событий, Тесла совершил свой самый экстравагантный поступок – благородно разорвал контракт с Westinghouse, отказавшись от всех отчислений, которые ему полагались от будущих продаж своих генераторов. Когда победил все-таки Вестингауз и приборы переменного тока начали триумфальное шествие по миру, по самым скромным подсчетам Тесла мог заработать более миллиарда долларов. И стать первым миллиардером в истории. Но лавры снова достались другому – на сей раз Рокфеллеру.

Радиопомехи Работая у Вестингауза, неутомимый Тесла сделал едва ли не главное изобретение в жизни, но снова славу снискали другие. В 1880-х годах он не только сформулировал основные принципы передачи информации с помощью радиосигналов, но и создал один из первых практичных радиопередатчиков. И даже продемонстрировал коллегам и военным первую в мире радиоуправляемую лодку, попутно изобретя и первый в мире дистанционный пульт. И снова его обошли – второй раз подряд изобретатель «пролетел» мимо Нобелевки! Дело в том, что к созданию радио независимо шли сразу несколько исследователей в разных странах, включая нашего Александра Попова. Но официально, как известно, лавры и Нобелевскую премию снискал американец итальянского происхождения Гульельмо Маркони. А среди неудачников гонки, как всегда, оказался и Никола Тесла.

107

Карьера/Образование Борьба за признание его «отцом радио» заняла у Теслы последние сорок лет жизни. Начиная с 1904 года, когда Патентное бюро США, получившее заявку и от Теслы, все-таки решило передать патент на изобретение радио Маркони, и до последних дней. Та же американская служба восстановила справедливость лишь в 1943 году, официально объявив Николу Теслу изобретателем радио и выдав тому долгожданный патент. Беда в том, что получить его и даже узнать о своей победе Тесла уже не смог бы при всем желании – за несколько месяцев до желанного известия он скончался на 87-м году жизни. Маркони умер еще раньше – в 1937-м. Нобелевским лауреатом и «единоличным» изобретателем радио. Любопытно, что в списке номинантов на премию 1915 года значились и Тесла, и Эдисон. Но оба остались без Нобелевки – по слухам, из-за своего упрямства и вышедшей за всякие рамки научной полемики яростной вражды. Якобы оба независимо заявили, что откажутся от присужденной им премии, если прежде ее получит соперник! И, разумеется, оба не желали разделить премию. Но до этого еще много чего успело произойти. Начиная с 1899 года Тесла обосновался в Колорадо-Спрингс, где продолжил свои эксперименты с высокочастотным излучением и беспроводной передачей электроэнергии на значительные расстояния. Он выдвинул гипотезу Демонстрация работы башни Тесла (впоследствии подтвердившуюся), что земной шар вместе с атмосферой является гигантским естественным проводником, и даже подсчитал его резонансную частоту. Продемонстрировал журналистам огромную искусственную молнию в миллионы вольт и длиной до четырех метров. Утверждал, что успешно осуществил беспроводную передачу телеграфного сообщения через Атлантику с помощью ионосферы и даже смог поймать радиосигналы искусственного происхождения из космоса! О двух последних сенсационных открытиях «затворника из Колорадо-Спрингс» наперебой писали газеты, но сколько-нибудь убедительных подтверждений научный мир не дождался.

У гениев свои причуды Покинув Колорадо-Спрингс в начале 1900 года, Тесла продал свою лабораторию, чтобы расплатиться с долгами. Но в том же году собрал $150 тыс. (половину которых получил от Джона Пьерпонта Моргана) для постройки трансляционной башни на Лонг-Айленде в Нью-Йорке («Башня Уорденклиффа» или «Башня Теслы»), с помощью которой в очередной раз намеревался поразить мир, на сей раз организовав регулярную беспроводную трансатлантическую телефонную связь. Неизвестно, состоялась бы сенсация – за полвека до появления спутников связи и сотовых телефонов! – или нет, но изобретатель снова оказался на грани банкротства,

108

ретроспектива и недостроенная башня с началом Первой мировой войны была разобрана из-за боязни «использования ее немецкими шпионами». Аналогичная судьба постигла и вторую «беспроводную телефонную станцию», которую Тесла начал строить с помощью компании Telefunken на том же ЛонгАйленде. Впрочем, к этому времени за Николой Теслой уже успела закрепиться репутация человека, несомненно, гениального, но, мягко говоря, со странностями. Все чаще давали себя знать симптомы психического заболевания – обсессивно-компульсивного расстройства (ОКР), каковым, кстати, страдал и упомянутый выше Говард Хьюз. Такого больного, с одной стороны, постоянно преследуют обсессии – нежелательные представления, опасения, мысли, образы или побуждения. А с другой – жизнь наполняется стереотипно повторяющимися поступками (компульсиями), призванными подавить тревогу, вызываемую обсессиями. Во времена Теслы это заболевание еще было мало изучено, и к тем, у кого наблюдались подобные симптомы, и медики, и общественное мнение относились как к безусловным «психам». А какие иные мысли мог вызвать ученый, известный всей стране человек, который испытывал фанатическую, болезненную привязанность к числу 3? Прежде чем войти в здание, трижды обходил его по периметру, в ресторане всегда требовал три салфетки, ни за что не останавливался в гостиничном номере, если число на двери не делилось на три, и т.п. Или испытывал непонятное физическое отвращение к драгоценностям (особенно «доставали» Теслу серьги на дамах!). Как и Хьюз, Тесла был буквально помешан на чистоте и гигиене, смертельно боялся микробов (до состояния фобии). Зато обожал голубей (часто приносил их в гостиничный номер) и вообще животных. Нет нужды говорить, что он не только всю жизнь прожил закоренелым холостяком, но и не скрывал, что дал обет целомудрия, благодаря которому его мозг мог работать в полную силу. Хотя вокруг него было немало женщин, страстно влюбленных в харизматичного серба, но, увы, без взаимности. О его патологической, доходящей до безумия ненависти к Эдисону (взаимной) уже было сказано. Вместе с тем Тесла свободно чувствовал себя на людях, был остроумен и убедителен, свободно говорил на восьми (!) языках, любил музыку, живопись, поэзию, знал толк в гастрономии и винах. Хотя под конец жизни перешел к вегетарианству, а до того увлекался индийской философией, пацифизмом, евгеникой. Лучшим другом Теслы был Марк Твен, а тому хватало знания человеческих слабостей и пороков, чтобы с толком выбирать себе друзей. А еще Никола Тесла был великий, как бы сегодня сказали, «самопиарщик». Лишенный ложной скромности

январь-февраль 2017 системный администратор

ретроспектива

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

по отношению к самому себе, он и свои научные демонстрации обставлял, как сегодня обставляют свои шоу Дэвид Копперфилд или Ури Геллер. Принимая гостей в своей лаборатории, «повелитель молний» обычно завершал встречу демонстрацией этих самых молний, предварительно убедив перепуганных посетителей, что все это абсолютно безопасно. Подобные «световые шоу» убеждали инвесторов, военных и газетчиков лучше всяких лекций и презентаций. Что до масс-культуры, то для нее Никола Тесла был и остается одной из главных «икон» первой половины ХХ века.

Это же относится к идеям телепортации (с именем Теслы связывали и знаменитый «Филадельфийский эксперимент», впоследствии признанный, как бы сейчас сказали, «фейковым»), антигравитации, «фотографирования мыслей» и путешествий во времени, которыми Тесла увлекался в последние десятилетия жизни. После смерти великого ученого и великого мистификатора от сердечного приступа на все его бумаги и чертежи тут же наложило лапу ФБР. Но сейф, в котором агенты Гувера ожидали найти разработки «лучевого оружия» и даже действующие модели, оказался пустым – притом что последние дни жизни Тесла провел в полном одиночеКод Теслы стве в нью-йоркском гостиничном номере. Тем не менее К сожалению, все эти странности в поведении ученого все бумаги были засекречены, а многие остаются таковыми и изобретателя, а также его манера бросаться громкими по сей день. Разумеется, это только прибавило дров в конспирологический «костер», раззаявлениями без последующего подтверждения сказангоравшийся еще при жизни ного, привели к нагромождеТеслы. Вероятно, в истонию легенд и мифов вокруг рии науки нового времени его имени. не найдется другого такого По части напустить тугения, которому было бы помана Никола Тесла не знасвящено столько книг (вклюет себе равных в истории чая художественную литературу и научную фантастику), науки прошлого столетия. Другой вопрос, фильмов, музыкальных произведений, ролевых и комчто туман сгущали и СМИ пьютерных игр, как Никола без его ведома – но ведь Тесла. Тесла ни разу публично Что до более серьезных не опроверг ни одну связанную с ним сенсацию. примеров признания его научных достижений, то памятИ мы по сей день не моБашня Уорденклиффа, Лонг-Айленд, Нью-Й орк (1904) жем точно и однозначно отники Тесле стоят в его родной ветить, разработал ли Тесла деревне, а также в Загребе принципы радара (и даже будто бы построил примитивную и по обе стороны Ниагарского водопада (американской и канадской). Потому что никто модель) еще в 1917 году? иной, как Тесла, своим изобретением двухфазного (а чуть И создал ли примерно в то же время действующую модель «лазерной пушки», стреляющей хорошо известными позже трехфазного) генератора переменного тока немало тогда любителям научной фантастики «лучами смерти»? поспособствовал строительству Ниагарской ГЭС – в то время самой мощной в Северной Америке (если не в мире). Во всяком случае, попытки ученого заинтересовать своим изобретением военных успеха не имели (любопытно, Начиная с 1960 года в Международной системе физических единиц (СИ) «теслой» обозначается единица магчто сам он считал свои смертоносные лучи «лучами мира», нитной индукции. Авторитетная международная некоммерсчитая, что это оружие вообще положит конец войне). ческая организация Институт инженеров электротехники А оставленные наброски и чертежи (многие документы сгорели во время пожара в 1915 году) не дают возможности и электроники (IEEE), вице-президентом которой в свое время был Тесла, ежегодно присуждает премию его имени в обсделать однозначный вывод – решил ли Тесла поставленную задачу или нет. ласти использования электроэнергии. Именем Теслы названы Белградский международный аэропорт, кратер на Луне Зато точно известно, что еще в 1928 году Тесла получил и малая планета под номером 2244. патент на прообраз летательного аппарата вертикального Но главная ирония состоит в том, что портрет человека, взлета и посадки. Но что помешало ученому продолжить который еще при жизни мог стать первым миллиардером разработки и стать еще и гением авиастроения, остается в истории, а закончил жизнь, опутанный долгами, представтолько гадать. лен на старых югославских банкнотах и на нынешних сербИ уже совсем загадочными выглядят заявления Теслы, ских достоинством в 100 динаров. И три компании – чешская сделанные им незадолго до смерти. Он, в частности, утверждал, что создал «динамическую теорию гравитации» электротехническая (бывшая чехословацкая Electra), Tesla (единую теорию поля, над которой по сей день бьются лучMotors, Incorporated из Силиконовой долины (производство шие умы) и собирается в скором времени сделать ее доэлектромобилей, ныне компанию возглавляет столь же хастоянием научного сообщества. Однако ожидаемые публиризматичный Илон Маск) и хорватский филиал телефонной кации так и не появились. Поэтому к претензиям Теслы компании Ericsson (бывшая Nikola Tesla) – носят имя того, на авторство единой теории поля научный мир относится чьи собственные компании и бизнес-проекты, как правило, более чем скептически. терпели крах. EOF

системный администратор январь-февраль 2017

109

НАУКА И ТЕХНОЛОГИИ 111 Низкоуровневая оптимизация

производительности на примере функции хеширования по ГОСТ Р 34.11‑2012

120 Оптимальное управление

распространением вирусов: аналитические и численные результаты

124 Влияние запаздывания сигналов

в виртуальном сетевом пространстве на точность и устойчивость систем автоматического управления

127 Разработка веб‑конструктора

графических пользовательских интерфейсов для системы управления интеллектуального здания

130 Программное приложение кластеризации

данных

134 Агрегирование и декомпозиция

статистических данных и ключевых показателей в процессе управления социально‑экономическим развитием Субъектов РФ. Часть 2

139 Программные средства оптимизации

ресурсного потенциала как инструмент управления рисками и планирования финансовой политики компании

Наука и технологии Северин П.А., аспирант кафедры радиофизики и электроники Сыктывкарского государственного университета имени Питирима Сорокина, г. Сыктывкар, pav9687@yandex.ru Гольчевский Ю.В., к.ф.-м.н., доцент кафедры информационной безопасности Сыктывкарского государственного университета имени Питирима Сорокина, г. Сыктывкар, yurygol@mail.ru

Низкоуровневая оптимизация производительности

на примере функции хеширования по ГОСТ Р 34.11‑2012 В статье исследуются возможности низкоуровневой оптимизации производительности для архитектуры x86 на примере хеш‑функции по ГОСТ Р 34.11‑2012. Проанализированы результаты применения таких способов оптимизации, как использование оптимизирующих компиляторов, встроенных функций и ассемблерных вставок на распространенных микроархитектурах процессорах Intel и AMD. Показана существенная зависимость достигнутого с применением методов низкоуровневой оптимизации увеличения производительности от особенностей процессорной микроархитектуры. На основе полученных в ходе исследования результатов выделены характеристики оптимизируемых программ, которые необходимо учитывать при выполнении низкоуровневой оптимизации, охарактеризованы ее общие возможности и перспективы применения

1. Введение

Несмотря на практическую актуальность, тематика низкоуровневой оптимизации зачастую вызывает дискуссионные вопросы: насколько оправданы усилия, затраченные на оптимизацию производительности в каждом конкретном случае? От чего зависит эффективность применения тех или иных методик и инструментов? Существует ли универсальная стратегия оптимизации? Ответ на первый вопрос сравнительно прост: минимальный уровень увеличения производительности, при котором усилия, затраченные на осуществление низкоуровневой оптимизации, имеют смысл, нельзя рассматривать отдельно от сферы применения разрабатываемого программного продукта. В качестве примера специализированных областей, в которых низкоуровневая оптимизация наиболее востребована, можно привести криптографические приложения, где область использования может варьироваться от встраиваемых систем (например, криптомаршрутизатор, одной из основных характеристик которого является скорость передачи шифрованного трафика) до криптографических библиотек и криптопровайдеров, используемых в пользовательских приложениях на различных процессорах в 32или 64-битных режимах. Ответы на последующие вопросы невозможны без ознакомления с наиболее распространенными способами низкоуровневой оптимизации (использование оптимизирующего компилятора, применение встроенных функций компилятора – intrinsics, методика оптимизации «горячих точек» [17], использование ассемблерных вставок [4], реализация на ассемблере).

системный администратор январь-февраль 2017

Вместе с тем разнообразие существующих методов оптимизации приводит к усложнению поиска оптимального способа (или их комбинации), необходимых для достижения наилучшего практического результата. Работы в области методологии низкоуровневой оптимизации позволяют сократить временные и финансовые затраты путем выбора способов увеличения производительности, соответствующих специфике оптимизируемого алгоритма. Целью статьи является рассмотрение методики осуществления низкоуровневой оптимизации с учетом предлагаемых в работе характеристик оптимизируемой программы на конкретном практическом примере – реализация хеш-функции по ГОСТ Р 34.11-2012 для архитектуры x86. В разделах 2-4 приводятся теоретические аспекты низкоуровневой оптимизации, формулируются классификационные критерии оптимизируемых программ и их связь с распространенными методами оптимизации. В разделах 5-7 рассматривается пример низкоуровневой оптимизации хеш-функции с учетом выделенных классификационных критериев, описывается методика тестирования производительности и получения результатов, демонстрации и обсуждению которых посвящен раздел 8.

2. Декомпозиция общей задачи низкоуровневой оптимизации

Классическим подходом к решению задач низкоуровневой оптимизации является выделение «горячих точек» – то есть наиболее

111

Наука и технологии ресурсоемких фрагментов программы – и их дальнейшая оптимизация путем указания специальных директив компилятора или замена на фрагменты кода с применением встроенных функций компилятора или ассемблерные вставки. Однако само понятие «горячей точки» довольно условно – для вычислительного приложения таковыми могут являться лишь несколько отдельных циклов, а для объемного приложения с графическим интерфейсом пользователя, выполняющего, например, хеширование данных по ГОСТ Р 34.11-2012 в качестве «горячей точки» может рассматриваться весь алгоритм хеш-функции. Сформулируем более строгое определение оптимизируемого участка программы, на которое будем ссылаться в дальнейшем. Будем называть оптимизируемый участок кода программы, в котором локализована наибольшая часть вычислений, функциональным фрагментом (под ним может подразумеваться функция или процедура на языке высокого уровня, цикл или только его внутренняя часть). Функциональный фрагмент можно рассматривать как синоним устоявшегося в программировании и теории компиляторов понятия «базовый блок» [2]. Таким образом, при оптимизации с использованием техники ассемблерных вставок программисту приходится выполнять рутинные задачи компилятора по выделению базовых блоков, поскольку сам компилятор при выполнении оптимизации всего остального кода не анализирует содержимое ассемблерных вставок, что может нивелировать результат их применения. Теперь задача оптимизации производительности программного кода может быть декомпозирована следующим образом: • оптимизация обмена данными между функциональными фрагментами; • оптимизация самих функциональных фрагментов. Решение первой задачи «ручным» способом затруднительно ввиду большого объема высокоуровневого исходного кода, который требуется проанализировать. Даже при ее успешном выполнении полученный код может потерять в гибкости модернизации и переносимости, а затраты на подобную оптимизацию (фактически «переписывание» кода на ассемблере) велики. Решение второй задачи вполне осуществимо для эксперта, что обусловлено сравнительно небольшим объемом высокоуровневого исходного кода, оптимальное отображение которого в эквивалентную последовательность машинных инструкций требуется найти. Как показывает практика, современные компиляторы достаточно эффективно справляются с данной задачей, однако возможность улучшения полученных компилятором решений все же существует [4]. Методы типа стохастической оптимизации позволяют увеличить производительность отдельных функциональных фрагментов на величину порядка десятков процентов [9]. Своеобразным компромиссом при решении обеих задач можно назвать использование встроенных функций компилятора (intrinsics). С одной стороны, их применение позволяет эксперту использовать наиболее оптимальные последовательности машинных инструкций для функциональных фрагментов, с другой стороны, за эффективное осуществление обмена данными между ними отвечает компилятор.

3. Оптимизация функциональных фрагментов

Ускорение выполнения программы осуществляется современными процессорами в том числе за счет параллелизма на уровне команд и векторизации. Помимо распространенных векторных расширений команд MMX, SSE и SSE2, существуют и те, которые поддерживаются

112

только некоторыми процессорами или определенными производителями (причем часть инструкций в них доступна лишь в 64-битном режиме). Вместе с тем с точки зрения удобства низкоуровневой оптимизации и повышения переносимости получаемых программ рекомендуется использование в функциональных фрагментах наиболее распространенных векторных расширений. Таким образом, при оптимизации функциональных фрагментов необходимо стремиться к сбалансированному выполнению следующих требований, заключающихся в минимизации: • количества и сложности используемых команд (понижение силы операций, векторизация); • количества условных переходов (развертка циклов, использование адресации памяти со смещением при обращении к данным); • обращений к памяти (путем помещения наиболее часто используемых значений в регистры); • числа используемых регистров. Так как современные процессоры x86-64 используют довольно сложный набор команд, каждый оптимизированный функциональный фрагмент может быть записан на машинном языке многими способами. Предпочтение необходимо отдавать тем способам, которые более успешны с точки зрения динамического планирования и конвейеризации. На этапе оптимизации функциональных фрагментов становится возможным задействование микроархитектурных ресурсов увеличения производительности. Адаптацию функциональных фрагментов к микроархитектурным особенностям конкретного процессора можно осуществить, анализируя механизм выполнения команд на конкретной микроархитектуре [4], путем использования статических анализаторов или профилировщиков (Intel Architecture Code Analyzer, Intel VTune Amplifier, AMD CodeXL). Другой подход – тестирование имеющихся вариантов реализации оптимизированного функционального фрагмента и выбора наиболее производительного. Как правило, оптимизация функциональных фрагментов, удовлетворяющая приведенным выше четырем условиям, уже дает увеличение производительности на широком спектре микроархитектур. Но, как показано далее, такое утверждение верно не для всех программ. В ходе выполнения оптимизации возникает задача измерения скорости выполнения оптимизируемого функционального фрагмента программы, а также достигнутого уровня быстродействия для всего приложения в целом. С учетом внеочередного выполнения команд, состояния кэшей, взаимовлияния вычислительных ядер многоядерного процессора и влияния сторонних приложений решение данной задачи нетривиально. Подход, в котором для сглаживания негативных последствий указанных факторов используется многократный вызов функционального фрагмента на исполнение, а для измерения производительности используется инструкция считывания счетчика тактов процессора, назовем микротестированием производительности [6]. В этом случае наблюдается пропускная способность участка машинного кода на полностью кэшированных данных. Микротестирование может быть выполнено с помощью статического анализатора. Для наиболее распространенных архитектур Intel доступен Intel Architecture Code Analyzer, который не только оценивает ресурсоемкость участка кода в тактах, но и предоставляет аналитическую информацию (загрузку исполнительных блоков и граф выполнения).

январь-февраль 2017 системный администратор

Наука и технологии Назовем макротестированием производительности измерение увеличения времени быстродействия всей программы в секундах после модификации функционального фрагмента. В данном случае имеют место высокая достоверность результата (так как функциональный фрагмент выполняется в реальных условиях), сравнительно высокие сложность и временные затраты. При работе с функциональными фрагментами удобнее иметь дело с микротестированием – но как только будут получены данные об увеличении производительности, они должны быть подтверждены макротестированием. Оптимизируемые функциональные фрагменты могут быть классифицированы как «преимущественно векторизуемые» и «преимущественно конвейеризируемые». Для последних микроархитектурные особенности конкретного процессора имеют гораздо большее влияние на производительность, нежели поддерживаемый процессором набор расширений, особенно если выполняются условия: • специализированные инструкции, предназначенные для выполнения оптимизируемых вычислений (например, AES-NI для одноименного алгоритма шифрования), отсутствуют; • для реализации достаточно команд наиболее распространенных векторных расширений (MMX, SSE или SSE2); • векторизация осуществляется относительно сравнительно быстрых операций (например, логических или загрузки значений из памяти), поэтому выигрыш от нее не столь существенен; • команды работы с памятью составляют значительную долю в общем числе инструкций. Таким образом, для низкоуровневой оптимизации, эффективной на различных процессорах, в ряде случаев необходим подход, основанный на анализе микроархитектуры используемого процессора в целях последующего запуска соответствующих специализированных версий функциональных фрагментов. В качестве имеющихся средств можно привести функцию __builtin_cpu_is() компилятора GCC. Практику ускорения вычислений путем анализа имеющихся векторных расширений и запуска специализированных версий программы для наиболее функциональной из присутствующих наборов инструкций можно считать уже устоявшейся и имеющей поддержку даже на уровне компилятора. Примером использования данного подхода являются следующие возможности современных компиляторов: опция /Qax компилятора ICL (генерация специальных версий машинного кода программы для указанных расширений и встраивание диспетчера, управляющего их запуском), функция __builtin_cpu_supports() компилятора GCC (определение имеющихся векторных расширений) и атрибут ifunc (динамическое «переопределение» вызываемой функции). Следует помнить, что данная стратегия эффективна для программы, подавляющее большинство функциональных фрагментов которой относится к «преимущественно векторизуемым». Как правило, это программы, выполняющие математические операции над вещественными числами.

4. Оптимизация обмена данными между функциональными фрагментами

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

системный администратор январь-февраль 2017

можно характеризовать как содержащие несколько функциональных фрагментов, на которые приходится основная доля вычислений, или как состоящие из большого числа функциональных фрагментов, примерно одинаковых по времени выполнения. Последние, очевидно, менее удобны для оптимизации посредством использования ассемблерных вставок и других аналогичных техник. По характеру активности функциональных фрагментов можно выделить программы с постоянной активностью функциональных фрагментов (например, алгоритмы, обрабатывающие однотипные блоки данных) и изменчивой активностью, то есть существенно зависящей от обрабатываемых данных – как правило, подобные программы чувствительны к техникам оптимизации типа Profile-guided optimization. С точки зрения локализации вычислений в пределах функциональных фрагментов можно выделить два класса программ, называемых далее «поточными» и «сегментированными». В поточной программе большинство вычислений осуществляется в функциональных фрагментах, время вычисления которых сопоставимо со временем на их вызов. Как правило, такая ситуация характерна для программ, в которых преобладают функции, выполняющие сравнительно быстрые однопроходные операции с данными (например, логические, а также операции с памятью). При этом время «полезных» вычислений сопоставимо со временем накладных расходов на вызов самой функции (передача аргументов, выполнение пролога и эпилога функции и другие). Таким образом, для «поточной» программы оптимизация обмена данными между функциональными фрагментами становится существенным фактором увеличения быстродействия. Для сегментированной программы ситуация прямо противоположна – практически все вычисления локализованы в функциональных фрагментах, а затраты на их вызов несущественны по сравнению с общим временем выполнения. Примером алгоритма первого класса является рассматриваемая в настоящей работе хеш-функция (при первоначальном выделении функциональных фрагментов, см. раздел 6), примером второго – электронная подпись по ГОСТ Р 34.10-2012 (при выделении в качестве функциональных фрагментов операций целочисленной арифметики). Выполнение таких функциональных фрагментов, как умножение чисел величиной 256-1024 бит, занимает значительно больше тактов, чем «накладные расходы» на вызов функции с несколькими аргументами-указателями. Можно заметить, что множеству алгоритмов поточных с точки зрения низкоуровневой оптимизации условно соответствует множество потоковых алгоритмов в общепринятом смысле (потоковым называется алгоритм обработки данных, в котором входные данные представляют собой последовательность элементов, каждый из которых необходимо рассмотреть за малое число проходов). Хотя потоковые алгоритмы изначально проектируются с высокими требованиями к быстродействию, не стоит забывать, что актуальность низкоуровневой оптимизации в конечном счете определяется именно в контексте практического использования. Поскольку высокоуровневая структура программы (функции, циклы и другие функциональные фрагменты) в результате выполнения компилятором межпроцедурной оптимизации может не соответствовать фактической на языке машинных команд, то в качестве практического критерия отнесения программы к одному из указанных классов может выступать сравнение быстродействия двух версий анализируемой программы (функциональные фрагменты в которой вычленены в отдельные функции на языке высокого уровня), компилируемой с высоким уровнем оптимизации

113

Наука и технологии и принудительной подстановкой всех функций или подстановкой на усмотрение компилятора. Если быстродействие первой версии существенно меньше, чем второй, то это говорит о преимущественно поточном характере алгоритма. В сущности, поточные алгоритмы не являются удобными для низкоуровневой оптимизации, поскольку значительно ускорить их быстродействие «точечным» применением ассемблера не удастся. Для успешного выполнения низкоуровневой оптимизации поточный алгоритм необходимо сделать сегментированным путем выделения новых функциональных фрагментов, представляющих более крупные объединения уже существующих, что продемонстрировано далее на примере рассматриваемой хеш-функции. Выделенные классы названы выше условными, поскольку путем изменения разбиения программы на функциональные фрагменты можно варьировать ее характеристики в рамках предложенных классификационных критериев. Вместе с тем данные критерии позволяют указать такое направление структурных преобразований программы, которое позволит повысить эффективность ее оптимизации с помощью ассемблерных вставок и иных аналогичных методов. Существенным недостатком рассмотренных способов низкоуровневой оптимизации (за исключением применения оптимизирующих компиляторов) является их слабая степень автоматизации. Перспективные подходы, например метод двухэтапной компиляции, позволяют задействовать микроархитектурный ресурс повышения производительности без снижения степени автоматизации, однако для их применения требуется использование специальной информационной инфраструктуры [11, 13].

5. Программные средства

Наиболее удобный и распространенный способ низкоуровневой оптимизации – использование оптимизирующего компилятора. Заметим, что практически все современные компиляторы являются оптимизирующими и в общем случае выдают эффективный с точки зрения производительности код, поэтому оптимизацию выделенных функциональных фрагментов легче производить, «отталкиваясь» именно от решений, сгенерированных компилятором. В качестве оптимизирующих компиляторов использовались: компилятор языка С из GNU Compiler Collection 4.9.2 – далее компилятор GCC [10] и Intel C++ Compiler из набора Intel Parallel Studio XE 2015 – далее компилятор ICL [5]. Оба компилятора поддерживают создание программ как с универсальной оптимизацией (то есть исполняемых на любых процессорах x86), так и с оптимизацией для набора расширений конкретного процессора (опции –march=native для GCC и /QxHost для ICL). Для возможности выполнения компилятором интенсивной межмодульной оптимизации все функции помещались в один файл исходного кода на языке Си (опции -fwhole-program и /Qipo для компиляторов GCC и ICL соответственно). Выбор алгоритма хеширования по ГОСТ Р 34.11-2012 обусловлен тем, что вопросы его высокоуровневой оптимизации достаточно полно раскрыты в существующих работах [14], кроме того, имеются эффективные низкоуровневые реализации, с которыми можно проводить сравнение: в качестве примера использования встроенных функций компилятора была рассмотрена доступная по BSD-подобной лицензии реализация хеш-функции [3] (основанная на использовании встроенных функций компилятора – intrinsics – далее версия INT), а в качестве примера полностью ассемблерной реализации использованы данные работы [14]. Первоначально была разработана тестовая версия для проверки корректности реализации, в которой все функциональные

114

фрагменты остаются реализованными на языке высокого уровня (далее SRC-версия), а затем версии с их реализацией в виде ассемблерных вставок с инструкциями архитектуры x86 и использованием векторных регистров и команд не выше уровня MMX или SSE (далее MMX и SSE разновидности версии inline – далее INL). Данная версия является результатом практического применения описанного выше подхода и подробно рассматривается в следующем разделе. Для SRC-версии были осуществлены два варианта компиляции: с встраиванием функций на усмотрение компилятора и полным встраиванием – спецификаторы static __attribute__ ((always_inline)) и __forceinline для компиляторов GCC и ICL соответственно.

6. Низкоуровневая оптимизация функции хеширования ГОСТ Р 34.11‑2012

В соответствии с разделом 8 ГОСТ Р 34.11-2012 реализация хешфункции предполагает три основных этапа: инициализация, многократное выполнение функции сжатия, дополнение оставшегося вектора исходных данных и финальные вычисления. Первоначально выделенные в программной реализации хешфункции функциональные фрагменты представляли собой наиболее часто используемые функции второго этапа, такие как операция lpsпреобразования из упомянутого выше стандарта, операция исключающего ИЛИ над 512-битными векторами – xor() и т.п. Данные функциональные фрагменты используются в высокоуровневых функциях сжатия и функции вычисления хеш-суммы. В INL-версии каждая ассемблерная вставка, реализующая соответствующий функциональный фрагмент, оформлялась в виде одноименной void-функции. Исследуемая хеш-функция обладает сравнительно небольшим числом «высоконагруженных» функциональных фрагментов и относится к блочным алгоритмам (постоянная активность функциональных фрагментов) и с этой точки зрения удобна для низкоуровневой оптимизации. С другой стороны, тестирование производительности согласно [6] показывает, что для большинства функциональных фрагментов, например xor(), количество тактов, требуемых для вызова функции (помещения аргументов в стек, выполнения пролога и эпилога функции), сравнимо или даже превышает время выполнения самой функции. В связи с этим становится понятным, почему при первоначальном выделении функциональных фрагментов отношение скоростей хеширования для SRC-версии, скомпилированной с принудительным полным встраиванием и подстановкой функций на усмотрение компилятора, оказывается существенно меньше единицы – 0,28 (процессор Intel Core2 Duo E5500, компилятор ICL, уровень оптимизации /O2). Эти факты, а также преобладание в выделенных функциональных фрагментах логических операций и операций загрузки значений из памяти, свидетельствуют о «потоковом» характере самой программы и «преимущественно конвейеризируемом» характере функциональных фрагментов. Первое указывает на необходимость выделения новых функциональных фрагментов на основе существующих, а второе – на необходимость рассмотрения различных вариантов их реализации для осуществления эффективной оптимизации на разных микроархитектурах. Для рассматриваемой хеш-функции найти оптимальное «совмещение» функциональных фрагментов не составляет особого труда. «Узким местом» является функция сжатия, содержащая 24 последовательных lps-преобразования. После выделения функции сжатия в качестве нового самостоятельного функционального фрагмента

январь-февраль 2017 системный администратор

Наука и технологии и изменения соответствующих атрибутов встраивания функций в пробной SRC-версии отношение скоростей хеширования, скомпилированное с полным встраиванием функций и встраиванием на усмотрение компилятора, оказывается близким к единице – 0,9. Оптимизируемая программа стала носить характер «сегментированной», то есть функциональные фрагменты выделены надлежащим образом, и теперь стоит переходить к их оптимизации, анализируя ассемблерный вывод компиляторов. Поиск опций компиляции для компилятора GCC, при которых максимально эффективны векторизация и внеочередное выполнение для наиболее ресурсоемкой функции lps-преобразования, не увенчался успехом, поскольку данный компилятор не смог задействовать векторные регистры при генерации машинного кода, и все его решения остались в рамках использования регистров общего назначения. Компилятор ICL смог сгенерировать решение, использующее векторные регистры. Лучшее решение, которое удалось обнаружить, имеет место при настройках компиляции с уровнем оптимизации по умолчанию и архитектурным ограничением использования инструкций не выше SSE2. Но векторизация как таковая здесь не наблюдается, поскольку задействованы только младшие 64 бита 128-битных регистров XMM. Таким образом, останется возможность «ручной» доводки ассемблерной реализации, в результате которой, согласно данным Intel Architecture Code Analyzer, имеет место более равномерная загрузка портов, а также четырехкратное увеличение пропускной способности. Подробное рассмотрение этой оптимизации выходит за пределы задач настоящей статьи.

системный администратор январь-февраль 2017

Стоит заметить, что для ускорения вычислений применяют YMM-регистры и специализированные команды AVX [8]. Однако при реализации хеш-функции переход к регистрам YMM даже на уровне функциональных фрагментов типа xor() и использование специализированных команд табличной подстановки, например таких, как vpgatherqq в lps-функции, не приводит к увеличению производительности – данная команда требует восстановления регистра-маски и связывает одновременно три разных регистра YMM при выполнении. Поэтому реализация с использованием AVX-регистров в тестировании не использовалась. Множество вариантов реализации функциональных фрагментов хеш-функции можно ограничить рассмотренными версиями тестовых реализаций, поскольку существуют лишь два «принципиально» разных способа извлечения байтов в наиболее ресурсоемкой функции lps-подстановки – расширение 8-битных регистров посредством команды movzx (MMX и SSE разновидности версии INL) или использование инструкций pextrw (pextrd) – указанные далее версии INT. Оптимальная реализация на языке машинных команд остальных функциональных фрагментов не представляет особой сложности ввиду их простоты и опускается из рассмотрения.

7. Тестирование производительности

В процессе тестирования были изучены реализации хеш-функции, полученные: • компилятором GCC при компиляции SRC-версии с опциями -Ofast -m32 -s -mtune=generic -fwhole-program (вариант GCC);

115

Наука и технологии • компилятором ICL при компиляции SRC-версии с опциями /QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2,AVX,CORE-AVXI,CORE-AVX2 /Qipo /O3 (вариант ICL-Qax) или опциями /QxSSE2 /O2 (вариант ICL-SSE2) в 32-битном режиме. Целью включения данных реализаций в тестирование является демонстрация уровня производительности, которого можно достигнуть с помощью одного лишь оптимизирующего компилятора без использования иных способов низкоуровневой оптимизации; • путем компиляции компилятором GCC исходных текстов реализации хеш-функции с использованием встроенных функций компилятора [3] для наборов команд MMX и SSE2 (INTSSE2-версия); MMX, SSE2 и SSE4.1 (INT-SSE4.1-версия) в 32-битном и 64-битном режимах; • с применением ассемблерных вставок, использующих только MMX или только SSE наборы команд (версии INL-MMX и INL-SSE), скомпилированные с использованием компилятора GCC с опциями -O0 -m32 -s -mtune=generic -fwhole-program -fomit-frame-pointer -mmmx -mno-sse -mnosse2 и -O0 -m32 -s -mtune=generic -fwhole-program -fomitframe-pointer -mnommx -msse -mno-sse2 соответственно (в обоих случаях использовано принудительное встраивание всех void-функций, содержащих ассемблерные вставки). Данные реализации включены в тестирование в целях демонстрации уровня производительности, которого можно достигнуть с применением методик использования встроенных функций Рисунок 1. Скорость хеширования на процессорах микроархитектуры Nehalem

Рисунок 2. Производительность реализаций хеш-функции на основе использования разных векторных расширений (по возрастанию значений категории SSE, SSE2)

116

компилятора и ассемблерных вставок соответственно. Применение компилятора GCC для версий INL и INT, так же как и уровень оптимизаций O0, не случайно – при использовании компилятора ICL и высоких уровней оптимизации наблюдается снижение характеристик производительности. Объяснение заключается в том, что попытки «помочь» оптимизирующему компилятору (особенно при использовании ассемблерных вставок) усложняют анализ программы последним и приводят к прямо противоположному результату. В силу специфики рассматриваемой хеш-функции (отсутствие команд условного перехода в выделенных функциональных фрагментах, работа с блоками данных постоянной длины 512 бит) применение технологии Profile-guided optimization для обоих компиляторов не привело к увеличению производительности на величину более 2%. Итоговое тестирование проводилось путем измерения скорости хеширования случайного массива данных (усредненной по многим испытаниям таким образом, что абсолютная погрешность составляет порядка 1%). В большинстве случаев тестирование производилось на 64-разрядных операционных системах Windows 7. Поскольку размер данных существенным образом влияет на скорость хеширования, на первом этапе проводилось вычисление хеш-функции от всего объема тестовых данных – 8 Мб, затем от его половины и т.д. – до размера блока. С уменьшением размера хешируемых данных скорость снижается, поскольку начиная с границы 4096-2048 бит в общем времени выполнения хеш-функции повышается удельный вес наименее оптимизированных процедур инициализации, дополнения вектора данных и финальных вычислений (представленных во всех версиях стандартными функциями memset и memcpy, а также кодом на языке высокого уровня).

8. Результаты тестирования на микроархитектурах Intel и AMD

Рассмотренные решения (SRC, INT и INL) протестированы на процессорах микроархитектур Intel (Atom, NetBurst, Nehalem, Core, Sandy Bridge, Haswell, Skylake) и AMD (K8, K10, K10.5, Bulldozer, Piledriver). Устаревшие архитектуры были задействованы для того, чтобы максимально расширить «временную шкалу», необходимую для анализа динамики эффективности низкоуровневой оптимизации. Тестирование проводилось на процессорах для рабочих станций, серверов (Xeon) и портативных (с литерами B, M, P, U в названиях). Данные о спецификации микропроцессоров и поддерживаемых наборах векторных расширений команд получены с помощью утилиты CPU-Z. Представленные далее на рис. 1-3 результаты тестирования продемонстрированы в целях ответа на следующие последовательные вопросы: • является ли изменение производительности разных методов низкоуровневой оптимизации на разных процессорах одной и той же микроархитектуры существенным? (В случае положительного ответа встает проблема оптимизации «под конкретный процессор», что более трудоемко, чем рассматриваемая оптимизация «под конкретную микроархитектуру»); • приводит ли увеличение функциональности используемых векторных расширений к безусловному увеличению производительности использующих их программ? (При положительном ответе ставится под сомнение сама концепция преимущественно конвейеризируемых вычислений); • значительны ли вариации производительности разных методов низкоуровневой оптимизации на разных микроархитектурах? (При отрицательном ответе необходимость анализа производительности на уровне микроархитектуры становится сомнительной).

январь-февраль 2017 системный администратор

Наука и технологии Конечно, исследуемая хеш-функция не претендует на роль «эталонного теста производительности», позволяющего дать исчерпывающие ответы на поставленные вопросы (хотя и основана на использовании наиболее универсальных операций работы с памятью и логических операций), но вместе с тем она является удачным примером (или, соответственно, контр-примером) при поиске ответов на поставленные вопросы. На рис. 1 представлены графики скорости хеширования для тестовых реализаций на процессорах Intel микроархитектуры Nehalem. Близость графиков друг к другу позволяет сделать вывод: несмотря на различия в типе процессоров, рабочих частотах, размерах кэшей и других характеристиках, именно особенности организации конвейера, присущие конкретной микроархитектуре, являются наиболее существенным фактором, определяющим соотношение эффективности тестируемых способов низкоуровневой оптимизации (для рассмотренных микроархитектур Intel ситуация аналогична). Применительно к полученным данным для процессоров, выпускаемых компанией AMD, заметим, что процессоры AMD в целом демонстрируют еще большее «однообразие». Рассмотрим скорости хеширования для 32-битных реализаций, базирующихся на использовании разных наборов векторных инструкций (для каждой из четырех категорий выбраны наиболее производительные решения, если одна и та же группа расширений используется для разных тестовых программ – например, ICLSSE2 или INL-SSE). Данные представлены на рис. 2. Тестирование показывает, что производительность хешфункции «не пропорциональна» версии используемых векторных расширений команд (что является следствием ее принадлежности к классу «преимущественно конвейеризируемых» программ). Решения SSE2 или SSE в целом наиболее оптимальны. Более того, версии SSE3 или SSSE3, запускаемые тестовой программой ICLQax, демонстрируют в ряде случаев существенное снижение производительности.

Решения INT и INL формально являются «кроссмикроархитектурными» поскольку используют универсальные приемы низкоуровневой оптимизации. Поэтому преимущество одного метода над другим на разных процессорах обусловлено особенностями микроархитектуры последних. Не углубляясь в особенности микроархитектуры, которыми обусловлены различия производительности тестируемых версий, заметим, что в ряде случаев процессоры AMD уступают по характеристикам быстродействия сопоставимым процессорам Intel, несмотря на более высокую тактовую частоту. Одна из основных причин заключается в более низкой ассоциативности кэша процессора (например, AMD FX-8320 – 4-way по сравнению с Intel i5-4440 – 8-way), что приводит к снижению эффективности кэширования, поскольку одни и те же кэш-линейки вынуждены попеременно замещать свое содержимое данными из разных участков памяти [4]. На рис. 3 показаны приросты производительности (обозначим α) в процентах (относительно лучшего из решений компиляторов: GCC, ICL-SSE2 и ICL-Qax) для методов ассемблерных вставок и использования встроенных функций. Для каждой микроархитектуры выбран наиболее производительный процессор из участвовавших в тестировании. Из приведенных данных следует, что фактор зависимости от особенностей микроархитектуры является существенным. Потери в случае использования программы, «неподходящей» для конкретной микроархитектуры, могут достигать порядка 25% для процессоров Intel и 61% для AMD (от максимального наблюдаемого уровня производительности на данной микроархитектуре; архитектуры NetBurst и K8 на рис. 3). При этом усредненный по всем рассмотренным микроархитектурам прирост производительности (относительно решений компиляторов) для INL-версий составил в среднем 40%, для INT-версий – 12%. Комбинация этих методов дает прирост около 44% и позволяет избежать потерь в указанных выше

Рисунок 3. Процентные приросты производительности INL- и INT-решений относительно лучшего из SRC-решений для процессоров Intel (a) и AMD (b) в 32-битном режиме

Рисунок 4. Эффективность низкоуровневой оптимизации для процессоров Intel (a) и AMD (b) в 32-битном режиме

системный администратор январь-февраль 2017

117

Наука и технологии пределах для отдельных микроархитектур. Отставание метода вставок на архитектурах Atom, Core и Nehalem компенсируется более существенным выигрышем на иных архитектурах, в особенности AMD. Практическая значимость проведенного сопоставления несколько условна, поскольку в анализе не учитывается реальное количество используемых на сегодняшний день процессоров указанных микроархитектур. Вместе с тем сравнение с применением усредненного по рассмотренным микроархитектурам прироста производительности вполне приемлемо для общей оценки качества реализаций. На рис. 4 представлена динамика эффективности низкоуровневой оптимизации, выраженной как отношение производительности лучшего из INL- или INT-решений к лучшему из решений компиляторов (обозначим β), по мере появления новых микроархитектур. Линейные тренды показывают уменьшение эффективности оптимизации по мере развития микроархитектур. Это может быть объяснено повышением эффективности динамического планирования и иных технологий увеличения производительности и большей «взаимной адаптацией» новых процессоров и современных компиляторов. Таким образом, для поколений процессоров Intel старше Skylake можно прогнозировать прирост быстродействия от техник «ручной» низкоуровневой оптимизации (методы, аналогичные INL) менее 20%. Это меньше порогового значения, при котором усилия, потраченные на оптимизацию, имеют смысл согласно [12]. Более высокие значения показателя эффективности низкоуровневой оптимизации для процессоров AMD могут быть объяснены тем, что в отличие от процессоров Intel, для которых был использован компилятор ICL, при вычислении данного показателя использованы решения компилятора GCC. Применение специализированных компиляторов, поддерживающих оптимизацию для данных микроархитектур, например AMD Open64, может снизить данный показатель, но вряд ли изменит тенденцию. Ответ на вопрос о том, почему даже в пределах одной архитектуры ускорение вычислений, полученное в результате низкоуровневой оптимизации, варьируется в столь широких пределах (от 1,16 до 3,15 раза), заключается в самом их устройстве – CISCпроцессоры x86 начиная с Intel486DX производятся с использованием RISC-ядра, таким образом, непосредственно перед исполнением сложные CISC-инструкции преобразуются в более простой набор внутренних инструкций RISC [16]. Исходя из этого можно объяснить, почему разные наборы высокоуровневых инструкций, выполняющих, по сути, одни и те же Рисунок 5. Сравнение наиболее производительных реализаций для 64и 32-битного режимов

118

операции, обладают различной производительностью – последняя зависит от успешности упомянутого выше преобразования CISCинструкций, которое, в свою очередь, влияет на успешность динамического планирования и конвейеризации. Очевидно, что у современных процессоров рассмотренный механизм более совершенен, отсюда и наблюдаемое уменьшение эффективности низкоуровневой оптимизации по мере появления новых микроархитектур. Также следует заметить, что при публикации данных, посвященных вопросам низкоуровневой оптимизации, необходимо осуществлять контроль зависимости достигнутого увеличения производительности от особенностей микроархитектуры конкретного процессора. Например, вопрос о том, насколько переносимы на другие процессоры оптимизационные решения, полученные в работах [1, 7], остается открытым. Для полноты картины необходимо ознакомиться с результатами в 64-битном режиме – быть может, при его использовании будет наблюдаться столь высокая производительность, что работа по оптимизации для архитектуры x86 покажется напрасной? На рис. 5 приведено сравнение характеристик производительности для лучших из 64-битных решений INT-SSE2 или INTSSE4.1 и лучшего из 32-битных решений SRC или INL (данные упорядочены по возрастанию значений категории х64). Существенным преимуществом в производительности 64-битные решения по сравнению с 32-битными не обладают, хотя и являются наиболее эффективными из рассмотренных для многих процессоров. Вместе с тем количество регистров общего назначения, SSE и AVX, для архитектуры x86-64 в два раза больше (16 вместо 8) по сравнению с 32-разрядной архитектурой x86. Благодаря этому на первой достигается большее быстродействие – поэтому тесты производительности коммерческих программ [15] и оригинальных ассемблерных решений [14], как правило, даются именно для нее. Отдельного упоминания заслуживает реализация, приведенная в работе [14], отмеченная на рис. 5 треугольным значком (94 Мб/с) для процессора Intel Core i7 920. Ее можно рассматривать как пример низкоуровневой оптимизации, использующей экстремальный прием повышения производительности – почти все константные и промежуточные значения находятся в регистровом файле, обмен с памятью минимален. Подобные решения наиболее актуальны для встраиваемых и иных, требовательных к производительности систем, но они возможны не для всех оптимизируемых алгоритмов.

9. Заключение

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

январь-февраль 2017 системный администратор

Наука и технологии производительности от особенностей микроархитектуры конкретного процессора (до 60% от максимального наблюдаемого уровня производительности на данной микроархитектуре). С одной стороны, это может рассматриваться как негативное явление, способное нивелировать усилия, потраченные на низкоуровневую оптимизацию для отдельных микроархитектур, с другой – как своеобразный ресурс увеличения производительности, если требуется повышение характеристик быстродействия для широкого спектра микроархитектур ценой «точечной» адаптации оптимизируемого алгоритма для каждой из них. Поскольку для многих микроархитектур инструменты типа Intel Architecture Code Analyzer отсутствуют, для анализа быстродействия преимущественно конвейеризируемых алгоритмов можно выполнить тестирование нескольких вариантов реализации оптимизированных функциональных фрагментов – по результатам настоящей статьи вполне достаточно одного процессора для каждой учитываемой микроархитектуры. Более того, для стабильного прироста производительности вовсе не обязательно иметь столько же версий оптимизированной программы, сколько и учитываемых микроархитектур – для рассматриваемой хеш-функции оказалось достаточным использование всего двух версий INL-SEE и INT-SSE2. В общем случае при выполнении низкоуровневой оптимизации необходимо контролировать специфику программы (состоит ли она из преимущественно конвейеризируемых или векторизуемых функциональных фрагментов и т.д.) и применять соответствующую стратегию увеличения производительности. Подводя итог обзору методов низкоуровневой оптимизации, можно сказать, что техника оптимизации с использованием ассемблерных вставок хотя и обладает большими возможностями использования различных машинных команд по сравнению с методом применения встроенных функций компилятора, но вместе с тем для своей эффективности требует структурных преобразований оптимизируемой программы в соответствии с выделенными классификационными критериями. Низкоуровневая оптимизация с полностью ассемблерной реализацией сохраняет свою актуальность для тех программ, в которых возможны экстремальные методы увеличения производительности, основанные на специфике конкретного алгоритма. Одним из актуальных направлений повышения эффективности решений современных оптимизирующих компиляторов по результатам проведенных исследований видится поддержка реализации «кросс-микроархитектурных» решений для программ, состоящих из преимущественно конвейеризируемых функциональных фрагментов – по аналогии с тем, как это уже реализовано для приложений, быстродействие которых зависит преимущественно от функциональности доступных векторных расширений (например, опция /Qax компилятора ICL). EOF [1]

[2] [3] [4]

Ansel J., Kamil Sh., Veeramachaneni K., Ragan-Kelley J., Bosboom J., Una-May O'Reilly, Amarasinghe S. OpenTuner: An Extensible Framework for Program Autotuning. http://groups.csail.mit.edu/commit/papers/2014/ ansel-pact14-opentuner.pdf. Basic Blocks – GNU Compiler Collection Internals http://gcc.gnu.org/ onlinedocs/gccint/Basic-Blocks.html. Degtyarev A. GOST R 34.11-2012: Streebog Hash Function. https://www. streebog.net. Fog A. Optimizing Subroutines In Assembly Language: An Optimization Guide For x86 Platforms. http://www.agner.org/optimize/optimizing_ assembly.pdf.

системный администратор январь-февраль 2017

[5] [6] [7]

[8] [9] [10] [11]

[12] [13]

[14]

[15] [16] [17]

Intel C++ Compilers https://software.intel.com/en-us/c-compilers. Kankowski P. Performance measurements with RDTSC. http://www. strchr.com/performance_measurements_with_rdtsc. Kensler A., Shirley P. Optimizing Ray-Triangle Intersection via Automated Search. Proceedings of the IEEE Symposium on Interactive Ray Tracing, September 2006. http://www.cs.utah.edu/~aek/research/triangle.pdf. Neves S., Aumasson J.P. BLAKE and 256-bit advanced Vector Extensions. https://131002.net/data/papers/NA12.pdf. Schkufza E., Sharma R., Aiken A. Stochastic Superoptimization. https:// cs.stanford.edu/people/sharmar/pubs/asplos291-schkufza.pdf. TDM-GCC. http://tdm-gcc.tdragon.net. Аветисян А.И. Двухэтапная компиляция для оптимизации и развертывания программ на языках общего назначения. Труды Института системного программирования РАН. 2012. Том 22. №. С. 11-18. DOI: 10.15514/ISPRAS-2012-22-1. Касперски К. Техника оптимизации программ. Эффективное использование памяти. СПб.: БХВ-Петербург, 2003. 446 с. Курмангалеев Ш.Ф. Методы оптимизации Cи/Cи++ - приложений распространяемых в биткоде LLVM с учетом специфики оборудования. Труды Института системного программирования РАН.2013. Том 24. С. 127-144. DOI: 10.15514/ISPRAS-2013-24-7. Лебедев П.А. Сравнение старого и нового стандартов РФ на криптографическую хеш-функцию на ЦП и графических процессорах NVIDIA. http://paco2012.ipu.ru/procdngs/F108.pdf. Пара слов о КриптоПро CSP 4.0. http://www.cryptopro.ru/ blog/2013/09/03/para-slov-o-kriptopro-csp-40. Проект «Все о Hi-Tech». http://all-ht.ru/inf/pc/cp_struct.html. Простая методика оптимизации с использованием Intel System Studio. https://software.intel.com/ru-ru/articles/simple-optimizationmethodology-with-intel-system-studio-vtune-c-compiler-cilk-plus.

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

The low-level performance optimization on the example of the hash function GOST R 34.11-2012 Severin P.A., graduate student of Radio Physics and Electronics of the Syktyvkar State University named after P. Sorokin., Syktyvkar, pav9687@ yandex.ru Golchevskiy Yu.V., Ph.D., associate professor of the department of information security behalf of the Syktyvkar State University named after P. Sorokin., yurygol@mail.ru Abstract: The article concerns the possibilities of a low-level performance optimization for x86 architecture on the example of the GOST R 34.11-2012 hash function. The results of applying optimization methods such as optimizing compilers using, built-in functions and assembler code inserts on the common microarchitectures for Intel and AMD processors were analyzed. The article contents a demonstration of the achieved performance increase using a low-level optimization techniques significant dependence from the processor microarchitecture features. On the basis of results obtained in the study the optimized programs characteristics that needed to be considered when performing a low-level optimization were determined, its general features and application prospects were described. Keywords: Optimization, computational acceleration, assembler, processor micro-architecture, compilation.

119

Наука и технологии Клименкова О.Д., бакалавр МИЭМ НИУ ВШЭ, Москва, по направлению «прикладная математика», odklimenkova@edu.hse.ru

Оптимальное управление распространением вирусов:

аналитические и численные результаты В работе рассматривается задача управления для SIR-модели эпидемий с переменным количеством узлов. Изучается задача минимизации затрат для модели SIR, управлениями в которой выступают «вакцинация» и «лечение» узлов. Исследуются два различных функционала и обсуждаются их особенности. На основе принципа максимума Понтрягина получена структура оптимального управления для каждого функционала. Найдены численные решения с использованием методов пристрелки и Рунге-Кутта 4-го порядка. Исследуется зависимость решения от параметров задачи Одним из основных подходов к изучению процесса заражения компьютерной сети вирусом является использование математических моделей, аналогичных моделям распространения вируса среди населения. Существуют различные модели эпидемий, применимые для людей, они могут учитывать, например, инкубационный период для вируса, появление естественного иммунитета, естественную смертность и рождаемость индивидуумов. Использование этих моделей для исследования заражения компьютерных сетей накладывает свой отпечаток, например для компьютера невозможно появление естественного иммунитета, подобные особенности нужно учитывать при применении математических моделей и их модификаций. В связи с тем, что математические модели распространения вирусов описываются системами нелинейных дифференциальных уравнений, многие результаты удается получить только численно. Компьютерное моделирование очень часто проводят с использованием пакета Matlab [1]. Однако следует иметь в виду, что одной из проблем при моделировании процессов заражения остается не выбор среды, где будет проходить моделирование, а корректность поставленной задачи и выбора способа решения. В настоящей работе рассматривается SIR-модель. В данной модели узлы в сети делятся на три группы: > Восприимчивые (S) − это те узлы, которые могут быть заражены вирусом. > Зараженные (I) − это уже пораженные вирусом узлы. > Восстановленные (R) − это узлы, которые были «вылечены», то есть был удален вирус и установлена антивирусная программа. Предполагается, что период функционирования системы достаточно мал, так что установленный антивирус не успевает устаревать. Мы рассматриваем однородную сеть, то есть каждый узел может установить контакт с любым узлом сети, количество узлов в сети не меняется [6].

120

Такая модель описывается следующими уравнениями:

Здесь: • u – интенсивность «лечения» Зараженных узлов, • β – интенсивность передачи вируса от Зараженных узлов в системе Восприимчивым узлам. В данной работе рассматривается модель SIR с возможностью «вакцинирования», а именно предполагается, что, кроме «лечения» зараженных, т.е. удаления на них вирусов и установки антивирусной программы, имеется возможность установки антивирусной программы на незараженные (Восприимчивые) узлы. Обозначим: • u1 − интенсивность «вакцинирования» Восприимчивых, • u2 − интенсивность «лечения» Зараженных узлов. Кроме того, добавим условие, что под действием вируса узлы выходят из строя с интенсивностью α. Тогда процесс распространения вирусов в сети можно описать следующими дифференциальными уравнениями: (1) (2) (3) Ниже мы перечислим лишь некоторые недавние результаты, которые были получены для аналогичной модели. В [1] изучается модель SIR. Особенность этой работы в том, что в модели учитывается, что количество узлов в системе может

январь-февраль 2017 системный администратор

Наука и технологии меняться: появляются новые узлы, выходят из строя старые узлы. В работе проведен анализ устойчивости решений. В [2] модель SIR применяется для исследования распространения ВИЧ-инфекции. В работе доказана теорема о существовании оптимального решения, для поиска минимума функционала используется принцип максимума Понтрягина. Найдена структура оптимального управления. Выведенные уравнения решаются численно. На основе полученных данных был сделан вывод о том, что лечение и вакцинация очень существенно влияют на быстрое угасание эпидемии.

3) Выполнено условие максимума для функции H:

Заметим, что для данной задачи λ0 ≠ 0. В дальнейшем положим λ0 = 1.

Анализ условия максимума

Рассмотрим подробнее условие максимума:

Постановка задачи

Мы будем рассматривать задачу оптимального управления для описанной выше модели: минимизировать функционал (4) на траекториях системы (1)-(3) с начальными условиями S(0) = S0, I(0) = I0, R(0) = R0. Функционалы такого вида типичны для задач управления распространением вирусов в сетях [1]-[2]. В этом функционале, с одной стороны, учитывается число «зараженных» узлов (и связанные с этим затраты), с другой стороны, затраты на «лечение» и «вакцинацию» узлов. В качестве управления рассмотрим параметры u1(t) и u2(t). Будем предполагать, что u1(t) и u2(t) – измеримые, ограниченные на отрезке [0;T] функции: (5) С использованием теоремы Филиппова [5] можно показать, что решение в задаче (1)-(5) существует. Заметим, что целевой функционал не зависит от переменной R, правая часть уравнений (1) и (2) также не содержит переменную R. Поэтому можно уменьшить размерность задачи, исключив из рассмотрения уравнение (3).

Необходимые условия оптимальности

Применим к задаче принцип максимума Понтрягина [3]. Запишем функцию Понтрягина:

Выпишем отдельно слагаемые с управлением u1 и управлением u2.

Функции F(u1) и G(u2) являются вогнутыми, следовательно, максимум достигается в стационарных точках функции F и G, если эти точки являются допустимыми. Если стационарная точка не является допустимой, то минимум надо искать на границе области. Найдем стационарные точки функций F и G.

Отсюда: и Получаем следующую структуру оптимального управления:

Пусть (S*(t), I*(t)) − оптимальное решение в задаче (1)-(5), (u1 (t), u2*(t)) − соответствующие оптимальные управления. Тогда согласно принципу максимума Понтрягина найдутся постоянная λ0 ≥ 0 и кусочно-непрерывно дифференцируемая вектор функция ψ(t) = (ψ1(t), ψ2(t)), такие, что: 1) ψ(t) удовлетворяет системе дифференциальных уравнений: *

(6)

(7)

2) Выполнены условия трансверсальности: ψ1(T) = 0, ψ2(T) = 0 системный администратор январь-февраль 2017

Заметим, что в силу условий трансверсальности управления . в заключительный момент времени Т равны 0:

121

Наука и технологии Алгоритм численного решения задачи

Выпишем систему уравнений принципа максимума Понтрягина:

(8)

где u1(t), u2(t) определяются из (6), (7). Имеем следующие краевые условия для системы (8): S(0) = S0, I(0) = I0, ψ1(T) = 0, ψ2(T) = 0 Таким образом, мы перешли от задачи оптимального управления к краевой задаче для системы четырех дифференциальных уравнений первого порядка. При интегрировании получим 4 неизвестных постоянных интегрирования, для определения которых есть 4 начальных условия. Для численного решения краевой задачи принципа максимума будем применять итерационный процесс − метод стрельбы, который заключается в последовательном решении задач Коши. Для решения задачи Коши применим метод Рунге-Кутты 4-го порядка. Система (8) решается численно в обратном времени начиная с момента Т. Задаются некоторые начальные условия S(T) и I(T). Рисунок 1. Оптимальные решения системы при значениях α = 0.1, β = 0.75, С1 = 1, С2 =0.4, С3 =0.5, T = 1

Затем задача Коши для системы уравнений с начальными условиями на правом конце решается численно и сравниваются полученные S(0) и I(0) с заданными, если они совпали с нужной нам точностью, то процесс завершается, если нет, то процесс повторяется с новыми S(T) и I(T), вычисленными по особому правилу [4].

Влияние параметров на оптимальные решения

Анализ зависимости оптимального значения функционала от параметров задачи выявил следующую особенность: с ростом α (интенсивность фатального выхода из строя узлов под действием вируса) оптимальное значение функционала уменьшается. Хотя интуитивно ясно, что интенсивный выход из строя узлов должен играть «отрицательную» роль. Очевидно, что такое влияние параметра α на функционал не является адекватным. Таким образом, нужно изменить функционал так, чтобы на оптимальном решении уменьшить число сломанных узлов и увеличить число восстановленных узлов.

Задача максимизации числа восстановленных узлов с учетом затрат

Рассмотрим следующую задачу оптимального управления: минимизировать функционал: (9) на траекториях системы: ,

с начальными условиями: S(0) = S0, I(0) = I0, R(0) = R0, и ограничениями на управления (5). Запишем функцию Понтрягина:

Пусть (S*(t), I*(t), R*(t)) − оптимальное решение в задаче, − оптимальное управление. Тогда согласно принципу максимума Понтрягина найдутся постоянная λ0 ≥ 0 и кусочно-непрерывно дифференцируемая вектор-функция ψ(t) = (ψ1(t), ψ2(t), ψ3(t)), такие, что: 1) ψ(t) удовлетворяет системе дифференциальных уравнений:

Рисунок 2. Зависимость функционала от параметра α

2) Выполнены условия трансверсальности: ψ1(T) = 0, ψ2(T) = 0, ψ3(T) = 0 3) Выполнено условие максимума для функции H:

122

январь-февраль 2017 системный администратор

Наука и технологии Заметим, что в данной задаче также можно положить λ0 = 1. По аналогии с предыдущим случаем найдем структуру оптимального управления.

(10)

(11)

Алгоритм численного решения задачи

Выпишем систему уравнений принципа максимума Понтрягина:

(12)

из строя под действием вируса. Выясним, как функционал (8) и управления реагируют на изменения параметра α. На рис. 3 показана зависимость функционала от α. Видно, что с ростом α функционал уменьшается, как и предыдущий функционал, это означает, что и новый функционал (8) имеет тот же недостаток.

Заключение

В работе изучается SIR-модель распространения вирусов в компьютерных сетях. Рассматриваются задачи управления для данной модели: • минимизация числа зараженных узлов с учетом затрат, где управление − интенсивность «вакцинации» и интенсивность «лечения»; • максимизация числа восстановленных узлов с учетом затрат, где управление − интенсивность «вакцинации» и интенсивность «лечения». Для каждой из задач найдена структура оптимального управления. Найдены численные решения. Проведен анализ зависимости решений от параметров задачи. Показано, что рассматриваемые целевые функционалы имеют существенный недостаток − принимают лучшие значения при возрастании интенсивности поломки, что не отражает реальные цели пользователя. В дальнейшем предполагается построить функционал, который имеет «правильное» поведение, то есть уменьшается с ростом α. EOF [1]

[2]

[3]

где u1(t), u2(t) определяются из (10), (11). Краевые условия для (12): S(0) = S0, I(0) = I0, ψ1(T) = 0, ψ2(T) = 0, ψ3(T) = 0. Из этих условий можно сразу аналитически найти ψ3(t) = C0(T – t). Строим численное решение задачи с использованием метода пристрелки. Напомним, с предыдущим функционалом возникла проблема при увеличении параметра α − интенсивности выхода узлов

[4]

[5]

[6] Рисунок 3. Зависимость функционала от параметра α

Yusuf T. T., Benyah F. Optimal control of vaccination and treatment for an SIR epidemiological model.// World Journal of Modelling and Simulation, Vol. 8(2012) No. 3, pp. 194-204. Bakare E. A., Nwagwo A., Danso-Addo E. Optimal control analysis of an SIR epidemic model with constant recruitment.// International Journal of Applied Mathematical Research, 3 (3) (2014) 273-285. Понтрягин Л.С. Математическая теория оптимальных процессов. − М.: Наука, 1976. Григорьев К.Г., Григорьев И.С., Заплетин М.П. Практикум по численным методам в задачах оптимального управления. Дополнение I. – М.: Издательство Центра прикладных исследований при механико-математическом факультете МГУ, 2007. Филиппов А. Ф., О некоторых вопросах теории оптимального регулирования. // Вестник МГУ, сер. матем., мех., астрон., физ., хим., 1959, №2, с. 25-32. Sun Zh. Epidemic spreading survey// [Электронный ресурс]: 8 February 2009. – Режим доступа: http://www.ccs.neu.edu/home/ austin/writeups/epispread.pdf, свободный (дата обращения: 14.10.16).

Optimal control for virus spreading: analytical and numerical results Klimenkova O.D., Bachelor MIEM NRU HSE, Moscow «applied mathematics», odklimenkova@edu.hse.ru Abstract: In this work, optimal control problem for a SIR model with variable size of population is considered. Our goal is to solve a problem of costs minimization. We investigate a SIR model with «vaccination» and «treatment» as controls. We consider two different functional and discuss their characteristics. Structures of optimal control are defined for every functional. Pontryagin’s maximum principle is used to characterize the optimal levels of controls. The optimality system is solved numerically. Then we analyze the dependence of solutions on parameter of problems. The simulation results are discussed. Keywords: SIR-model, optimal control, Pontryagin’s maximum principle.

системный администратор январь-февраль 2017

123

Наука и технологии Туманов М.П., к.т.н., профессор (НИУ ВШЭ, МИЭМ), Москва, mtunanov@hse.u

Влияние запаздывания сигналов в виртуальном сетевом пространстве

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

Современные распределенные системы управления реального dhtvtyb функционируют в виртуальном сетевом пространстве, что накладывает существенный отпечаток на динамику процессов в них. Запаздывание при распространении сигналов в таком пространстве является практически неизбежным злом, с которым приходится считаться и бороться. Особенно значительных величин это запаздывание достигает при использовании большого числа маршрутизаторов и связанного с этим буферирования. Основной особенностью систем управления с наличием сетевого компонента Ethernet является то, что этот компонент вносит дополнительное запаздывание, влияющее на качество переходных процессов. Таким образом, эти системы являются системами с запаздыванием. Классы сетевого QoS, задающие ограничения для значений рабочих характеристик сети, приведены в таблице 1 [1]. Таблица 1. Классы QoS Характеристики доставки IP‑пакетов

Классы качества передачи информационных потоков QoS (ITU‑T Recommendation Y.1541. Network performance objectives for IP‑based servicies. 2006) 0

Задержка доставки IP‑пакета – IPTD

100 мс

400 мс

100 мс

400 мс

1000 мс

Не опр.

Вариация задержки доставки IP‑пакета – IPDV

50 мс

Не опр.

Доля потерянных IP‑пакетов – IPLR

10-3

Не опр.

Доля переданных с ошибкой IP‑пакетов – IPER

10-4

Не опр.

124

Таким образом, не гарантируется время задержки менее 0,1 с в сети Ethernet даже в рамках использования сервиса QoS. Таково реальное положение дел, и оно означает, что при наличии сетевой компоненты затруднительно управлять объектом с характерной постоянной времени ~ 0,1 c и менее. Кроме того, такое запаздывание обычно является переменным, но в данной статье будет нами рассмотрен эффект, не связанный с переменностью времени запаздывания, а возникающий при плохо определенном (недостаточно точно известном) времени запаздывания. В таком контексте обычно либо используют экстраполятор функций на время запаздывания, либо встроенную модель объекта управления с запаздыванием [2]. Причем оба этих подхода плохо работают при неточно известном запаздывании. Будем предполагать (это реалистично), что выход объекта без запаздывания физически получен быть не может, поэтому будем предполагать наличие в системе компенсации запаздывания (см. рис. 1). Ограничимся случаем линейной системы с постоянными коэффициентами, так как даже в такой системе рассмотренный ниже эффект проявляется в полной мере. Пусть W(p)рег, W(p)о и W(p)ос – соответственно передаточные функции регулятора, объекта управления и обратной связи. Передаточная функция разомкнутой системы: (1) (и соответствующая частотная характеристика W(jω)рc определяет величину ошибки слежения в системе по следующей формуле [2]: (2)

январь-февраль 2017 системный администратор

Наука и технологии В частотной области получим оценку спектральных составляющих ошибки, поэтому стремятся к тому, чтобы |W(jω)рc| ‑ 1 < ε – требуемой точности системы. Будем предполагать, что это требование выполнено, если отсутствует (поэтому и не учитывается) запаздывание. Теперь введем компенсацию запаздывания, для чего добавим в систему модели объекта, помехи и, наконец, запаздывания, которые входят в виде программных модулей в ПО регулятора. Мы не можем заранее предполагать, что все эти модели точны, кроме того, помеха может иметь стохастическую природу и поэтому точно не воспроизводится. Будем для определенности считать, что модель объекта достаточно точна, а вот модель запаздывания отличается от реального запаздывания. Все это отражено на рис. 2. Очевидно, если модель запаздывания точна, то происходит его (запаздывания) полная компенсация и ЛАЧХ разомкнутой скомпенсированной системы не отличается от ЛАЧХ системы вообще без запаздывания. Но, к сожалению, точная компенсация невозможна. Типичный вид логарифмической амплитудно‑частотной характеристики (ЛАЧХ) такой системы (в разомкнутом виде) приведен ниже (см. рис. 3). ЛФЧХ, проходя на достаточно высоком уровне, обеспечивает малую ошибку (в соответствии с формулой (2)). Этот эффект хорошо виден на рис. 3, где приведено несколько случаев неточной компенсации запаздывания. В некоторых случаях провалы ЛАЧХ достигают ‑60 дб, но это наблюдается далеко не всегда. Точными нулями будут частоты, удовлетворяющие уравнению:

Рисунок 1. Типовая распределенная система автоматического управления

Рисунок 2. Компенсация запаздывания

Рисунок 3. ЛАЧХ разомкнутой системы без запаздывания и с последующей неточной компенсацией запаздывания

(3) Наличие или отсутствие корней этого уравнения связано с соотношением между τ и τм. Если эти числа рационально соизмеримы (n·τ = m·τм), то (3), являясь в этом случае периодической функцией, может иметь решение, но может и не иметь. Примеры приведены на рис. 4. Здесь отображен годограф F(ω) [2] при неотрицательных частотах на комплексной плоскости. Обращать внимание следует на прохождение годографа вблизи точки 0. Также приведены графики ЛАЧХ этой функции (по оси ординат – децибелы). Очевидно, что имеются глубокие провалы ЛАЧХ на некоторых частотах, препятствующие высокой точности замкнутой САУ. При этом при точной компенсации запаздывания таких провалов нет (так же, как и в системе без запаздывания). Ниже на рис. 5‑7 приведены переходные процессы в этой системе при различной степени компенсации запаздывания. Поэтому даже малое изменение параметров модели запаздывания может оказать сильное влияние на точность системы на некотором множестве частот. Если эти частоты лежат вне рабочего диапазона, то это не оказывает существенного влияния. В противном случае качество работы системы автоматического управления ухудшается. Выходом из этого положения была бы более точная модель запаздывания в сетевой компоненте, что труднореализуемо в силу того, что само это запаздывание может меняться очень динамично и в широких пределах. Целесообразно будет рассмотреть два крайних случая реализации системы с компенсацией запаздывания в сетевой компоненте:

системный администратор январь-февраль 2017

Рисунок 4. Случай соизмеримых запаздываний: годографы F(ω) и соответствующие ЛАЧХ

125

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

от локального контроллера, находящегося на самом объекте управления. При этом в силу ограниченных возможностей такого контроллера качество регулирования скорее всего окажется ниже, чем в исходной системе. Главной проблемой при таком подходе является решающее правило, в соответствии с которым принимается решение о переходе на локальное регулирование и обратно. Время срабатывания этого правила также должно быть соизмеримо с постоянной времени объекта управления. Это означает, что должен вестись постоянный и адекватный мониторинг работы сети с предсказанием возможных скачков времени передачи информации, что является довольно сложной задачей. • Случай меняющегося запаздывания, не выходящего за границы отказа сети. В этом случае в соответствии с общими принципами адаптивного управления требуется построение адекватной модели меняющегося запаздывания. Очевидно, что эта модель будет подстраиваемой под реально изменяющееся запаздывание. Схема такой адаптивной системы приведена на рис. 5. Здесь используется отклонение выхода модели запаздывания от реального сигнала в цепи обратной связи с запаздыванием. Утолщенной линией показан контур настройки модели запаздывания. В качестве алгоритма подстройки запаздывания в реальном времени можно использовать градиентный алгоритм общего вида:

Рисунок 5. Переходный процесс при τ = 2 и τм = 1.5

Рисунок 6. Переходный процесс при τ = 2 и τм = 2

(4) где новая текущая оценка времени запаздывания в модели запаздывания вычисляется через градиент целевой функции с текущим шагом. Уточнить текущий шаг можно через матрицу вторых частных производных (метод Ньютона) или воспользоваться иным (менее точным) методом выбора этого шага. Важно, чтобы процедура (4) достаточно быстро сходилась к истинному значению запаздывания. EOF

Рисунок 7. Переходный процесс при τ = 2 и τм = 2.5 [1] [2]

http://certificate.net/Portals/1/standards/itu/y‑1541‑rus.pdf. Колмановский В.Б. Устойчивость и периодические режимы регулируемых систем с последействием./ В.Б. Колмановский, В.Р. Носов. – М.: Наука, Главная редакция физико‑математической литературы, 1981. – 448 с.

Ключевые слова: распределенная система управления, запаздывание, компенсация.

Рисунок 8. Компенсация запаздывания с адаптацией

The influence of the delay of the signals in the virtual network space on the accuracy and stability of automatic control systems Tumanov M.P., Cand. of Techn. Sciences, professor (MIEM HSE), Moscow, mtunanov@hse.u Abstract: The article shows that in a typical automatic control system that contains the network component may be a significant drop in control accuracy due to network lag. The article describes a case of lag compensation using inaccurate delay model in the case when the model of the control object is considered sufficiently accurate. It is shown that the possible emergence of such dips of the frequency response with compensation. Keywords: distributed control system, delay compensation.

126

январь-февраль 2017 системный администратор

Наука и технологии Николаев П.Л., преподаватель, Московский авиационный институт (национальный исследовательский университет), Москва, npavel89@gmail.com

Разработка веб-конструктора

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

В последнее время при проектировании управляющих систем интеллектуальных зданий (умных домов) становится тенденцией внедрение функции удаленного мониторинга и управления через специализированный облачный сервис. При этом пользователи получают возможность удаленного взаимодействия со своим домом из любого места c помощью доступного под рукой устройства с выходом в сеть Интернет. Со смартфона, планшета, ноутбука или стационарного компьютера через специальные клиентские приложения можно не только быстро и оперативно получать данные о состоянии различных систем в доме, следить за показаниями датчиков, но и удаленно управлять работой устройств и приборов. Кроме того, при возникновении аварийных ситуаций или неполадок возможно мгновенное оповещение пользователей, где бы они ни находились. В рамках своей научно-исследовательской работы автором ведется разработка специализированного программного комплекса, позволяющего интегрировать в облако систему управления интеллектуального здания (СУИЗ). На одном из этапов возникла необходимость в создании клиентского приложения для СУИЗ. В данной статье будет рассмотрена разработка одного из компонентов подобного клиентского приложения – модуля настройки интерфейса, представляющего собой веб-конструктор графических пользовательских интерфейсов (GUI) для управляющей системы интеллектуального здания.

Структура клиентского приложения

Разрабатываемое автором клиентское приложение для СУИЗ состоит из следующих компонентов: графический пользовательский интерфейс и модуль для настройки интерфейса (конструктор), модуль настроек (привязка виджетов к устройствам) и модуль создания сценариев [1]. Наиболее важными частями приложения являются графический пользовательский интерфейс и модуль

системный администратор январь-февраль 2017

для его настройки. Удобный, максимально оптимизированный и интуитивно понятный интерфейс позволит конечным пользователям максимально эффективно взаимодействовать c умным домом. Конструктор должен обеспечить создание такого интерфейса. При этом инструмент для создания интерфейса также должен быть максимально простым и понятным, у пользователей не должно возникать никаких трудностей при работе с ним. Конструктор пользовательских интерфейсов должен обладать следующими особенностями: • полноценное функционирование на устройствах с сенсорными экранами; • возможность зонирования автоматизируемого объекта (создание помещений); • наличие библиотеки виджетов (модулей, отображающих состояния разных устройств и датчиков); • наличие функции сортировки помещений и виджетов с помощью перетаскивания.

Выбор типа приложения

При создании клиентского приложения для управляющей системы интеллектуального здания было решено разрабатывать его в виде веб-приложения, ориентированного на мобильные устройства. Веб-приложения по сравнению с нативными (под конкретную платформу) и десктопными позволяют обеспечить кроссплатформенность. Они могут функционировать на любых устройствах, обладающих современными браузерами, вне зависимости от их операционной системы. В ином случае потребуется разрабатывать отдельные приложения под каждую существующую платформу (iOS, Android, Windows и другие). При этом придется использовать разные языки программирования и средства разработки. Кроме того, нативные приложения должны размещаться в специализированных магазинах приложений (Apple App Store или Google Play), прежде пройдя рецензирование.

127

Наука и технологии Также отметим, что, «работая с веб-приложениями, проще выстраивать процесс сборки и итерации» [2]. Вносить изменения в приложения можно в любой момент, минуя процесс рецензирования. Среди недостатков веб-приложений можно выделить то, что они не позволяют использовать системные ресурсы устройств, на которых работают. Однако в нашем случае это не играет существенной роли, т.к. для мониторинга систем умного дома необходимо только получать данные из облачного сервиса, а для управления устройствами – отправлять в облако команды.

Технологии, использовавшиеся при разработке веб-конструктора

Разработанный конструктор пользовательских интерфейсов представляет собой одностраничное приложение, использующее единственную html-страницу. Для его разработки были использованы технологии HTML 5, CSS и JavaScript. На языке JavaScript для вебконструктора были реализованы функции создания и редактирования помещений и виджетов. Также в проекте применялся CSS/ HTML фреймворк UIkit, использующий библиотеку jQuery. Применение фреймворка UIkit было обусловлено необходимостью создания кроссбраузерного адаптивного веб-приложения, способного полноценно функционировать на различных устройствах. Одной из проблем, с которой пришлось столкнуться при разработке конструктора, явилась реализация функции сортировки элементов перетаскиванием (drag and drop). Перетаскивание можно было реализовать с помощью HTML 5. Однако, к сожалению, данная функция не поддерживается современными мобильными браузерами (iOS Safari, Opera Mini, Android Browser, Chrome for Android), функционирующими на сенсорных устройствах [3]. Отличительной особенностью фреймворка UIkit являются модули nestable.js и sortable.js, которые позволяют организовать сортировку элементов перетаскиванием, работающую на мобильных устройствах с сенсорными экранами.

Область «Помещения» предназначена для зонирования автоматизируемого объекта путем создания его составных частей (помещений, комнат). Каждое помещение можно отредактировать: изменить расположение, переименовать и удалить. Также предусмотрена кнопка «Удалить все», предназначенная для удаления всех созданных помещений и всех привязанных к ним виджетов. Вторая область («Виджеты») предназначена для добавления виджетов из встроенной библиотеки. При добавлении осуществляется привязка к определенному помещению. Виджет – это графический модуль, выполняющий одну из следующих функций: • отображение показаний датчиков (сенсоров) и состояния устройств (например, вывод значений с температурных датчиков, отображение состояний окон и дверей и т.п.); • управление конечным оборудованием (например, управление устройствами освещения, розетками, шторами и т.п.). Соответственно, библиотека содержит два типа виджетов: сенсорные и актуаторные. Аналогично помещениям, виджеты также можно отредактировать: изменить расположение, переименовать и удалить. Нажатие кнопки «Удалить все» в области «Виджеты» приведет к удалению всех виджетов только для одного конкретного помещения.

Хранение данных

Разработанный веб-конструктор графических пользовательских интерфейсов для управляющей системы интеллектуального здания (см. рис. 1) представляет собой визуальный редактор. Конструктор состоит из двух основных областей: «Помещения» и «Виджеты».

В процессе проектирования графического интерфейса данные о созданных помещениях и виджетах хранятся в объекте JavaScript. Структура объекта представлена на рис. 2. В объекте JavaScript содержится массив rooms, хранящий объекты с данными о каждом помещении: уникальный идентификатор (id), название (name), позиция (порядок расположения элемента, position) и массив виджетов (widgets). В массиве widgets, в свою очередь, хранятся объекты с данными о каждом виджете: уникальный идентификатор (id), название (name), тип (type) и позиция (position). После окончательного формирования интерфейса объект JavaScript по нажатию на кнопку «Сохранить» будет преобразован в JSON-строку с помощью метода JSON.stringify(). Формат JSON был выбран в связи с тем, что по сравнению с другими форматами для хранения и передачи данных (например, XML) он имеет ряд преимуществ, среди которых:

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

Рисунок 2. Структура объекта JavaScript для хранения информации о помещениях и виджетах

Описание функционала конструктора

128

январь-февраль 2017 системный администратор

Наука и технологии • более простая структура данных; • более простая обработка данных ввиду наличия встроенных средств кодирования и декодирования JSON-данных в языках программирования; • меньший размер, вследствие чего передача данных осуществляется быстрее. Пример сформированной JSON-строки из объекта JavaScript:

автором, но его можно встроить и в сторонние программные комплексы для управления умными домами. EOF [1]

[2] [3]

{"House":[ {"id": "R1","name": "Комната 1","position": 0, "widgets":[ {"id": "W1", "name": "Люстра", "type": "light", ↵ "position":0} ] }, {"id": "R2","name": "Комната 2","position": 1, "widgets":[ {"id": "W2","name": "Розетка 1", "type": "light", ↵ "position":0}, {"id": "W3", "name": "Лампа 1", "type": "light", ↵ "position":1}, {"id": "W4", "name": "Температура в комнате", ↵ "type": "temperature_sensor", "position":2} ] } ] }

Далее эта JSON-строка будет отправлена в облачный сервис.

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

системный администратор январь-февраль 2017

Николаев П. Разработка веб-сервиса для системы управления интеллектуального здания на основе архитектуры REST. // «Научное обозрение», №8, 2015 г. – С. 238-241. Вейл. Э. HTML5. Разработка приложений для мобильных устройств. – СПб.: Питер, 2015. – 480 с. Drag and Drop. URL: http://caniuse.com/#feat=dragndrop (дата обращения: 01.11.2016).

Ключевые слова: умный дом, интеллектуальное здание, веб-конструктор, веб-приложение, пользовательский интерфейс, JavaScript, JSON.

Development of the web-designer of graphical user interfaces for intelligent building management system Nikolaev P.L., Lecturer of Moscow Aviation Institute (National Research University), Moscow, npavel89@gmail.com Abstract: The article describes the development of web application which is the designer of graphical user interfaces for intelligent building management system (IBMS). The technologies and tools used for application development are considered. The author provides the description of functionality, opportunities and features of the web designer. It also describes the organization of storage and data representation obtained after completion of design of the graphical user interface by using the designer. Keywords: smart home, intelligent building, web designer, web application, user interface, JavaScript, JSON.

129

Наука и технологии Бучацкая В.В., к.т.н., доцент, доцент кафедры прикладной математики, информационных технологий и информационной безопасности Адыгейского государственного университета, buch_vic@mail.ru Бучацкий П.Ю., к.т.н., доцент, заведующий кафедрой автоматизированных систем обработки информации и управления Адыгейского государственного университета, butch_p99@mail.ru Гущин К.А., магистрант Адыгейского государственного университета, sargos92@gmail.com

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

В современной жизни человек постоянно сталкивается с необходимостью анализа совокупностей объектов, будь то некие наблюдения, результаты опытов или характеристики объектов. Полученные данные необходимо обработать и систематизировать. Особенно сложно это сделать, если исследователь не знает точно, на какие группы надо разбить объекты, сколько их и надо ли вообще разбивать. В таком случае на помощь приходит кластерный анализ. Он представляет собой инструментарий для группировки многомерных объектов, основанный на представлении результатов отдельных наблюдений точками подходящего геометрического пространства с последующим выделением групп как «сгустков» этих точек (кластеров, таксонов). Данный метод исследования получил развитие в последние годы в связи с возможностью компьютерной обработки больших баз данных. Кластерный анализ предполагает выделение компактных, удаленных друг от друга групп объектов, отыскивает «естественное» разбиение совокупности на области скопления объектов. В настоящее время кластерный анализ применяется во многих сферах деятельности человека: в маркетинге, менеджменте, медицине, социологии, информатике и других [4]. Преимущество данного метода заключается в том, что он работает даже тогда, когда данных мало или не выполняются требования нормальности распределений случайных величин и другие требования классических методов статистического анализа [1, 4]. Программная реализация алгоритмов кластерного анализа на сегодняшний день разнообразна. Большинство статистических пакетов предоставляет такую возможность, однако имеет один существенный недостаток – они требуют специальных знаний для реализации разбиения. Но и совершать такие операции вручную необоснованно сложно и долго. Таким образом, возникает необходимость разработки приложения, которое реализует алгоритмы кластерного анализа и предоставляет их результаты в наглядном виде, но при этом не требует от пользователя специальных знаний и имеет понятный интерфейс. Например, наличие у подобного приложения веб-интерфейса сделает его максимально

130

доступным для пользователей. В связи с этим реализация алгоритмов кластерного анализа для обработки многомерных данных в форме веб-ресурса является актуальной задачей. Формальная постановка задачи кластеризации следующая. Пусть X – множество объектов, Y – множество номеров (имен, меток) кластеров. Задана функция расстояния между объектами ρ(x, x'). Имеется конечная обучающая выборка объектов Xm = {x1, ..., xm} ⊂ X. Требуется разбить выборку на непересекающиеся подмножества, называемые кластерами, так, чтобы каждый кластер состоял из объектов, близких по метрике ρ, а объекты разных кластеров существенно отличались. При этом каждому объекту xη ∈ Xm приписывается номер кластера yη. Алгоритм кластеризации реализует построение функции a: X → Y, которая любому объекту x ∈ X ставит в соответствие номер кластера y ∈ Y. Множество Y в некоторых случаях известно заранее, однако чаще ставится задача определить оптимальное число кластеров с точки зрения того или иного критерия качества кластеризации [1]. При написании программного приложения актуальной задачей является выбор языка программирования. Однако в настоящее время этот выбор не является очевидным. Практически все современные языки программирования высокого уровня приспособлены для решения сложных задач. При этом у них имеются достаточно серьезные отличия. Некоторые производят вычисления быстрее, некоторые медленнее. Для некоторых существуют уже готовые решения тривиальных подзадач. Предсказать заранее, какой язык будет лучше для решения той или иной задачи, достаточно проблематично. Но существует ряд параметров, по которым можно оценить каждый из современных языков и подобрать оптимальный. При написании программного веб-приложения стоит задача подобрать такой язык программирования, который будет отвечать следующим требованиям: 1. Прост в освоении и имеет понятный синтаксис. 2. Имеет широкие возможности для расширения программы. 3. Имеет средства для визуализации многомерных данных.

январь-февраль 2017 системный администратор

Наука и технологии Исходя из данных требований основными претендентами для написания студенческих работ являются Java, C++, Python, PHP. Проанализировав соответствие указанных технологий требованиям задачи, был выбран язык программирования Python. Он обладает широким набором мощных библиотек для решения достаточно сложных математических задач, имеет возможности для визуализации (построение графиков, схем), а также свой собственный фреймворк Django, который существенно упрощает разработку веб-приложений [2, 3, 6]. При написании программного приложения были использованы следующие библиотеки: Matplotlib (для визуализации данных средствами двумерной (2D) и трехмерной (3D) графики), NumPy (реализует поддержку больших многомерных массивов и матриц, вместе с большой библиотекой высокоуровневых математических функций для операций с этими массивами), SciPy (содержит модули для решения задач оптимизации, интегрирования, обработки специальных функций, сигналов, изображений, генетических алгоритмов, решения обыкновенных дифференциальных уравнений и других задач), Django (позволяет увеличить скорость решения однотипных задач, возникающих при разработке вебприложений) [4]. В основе принципов работы созданного веб-приложения лежат правила работы фреймворка Dhango. Он основан на широко распространенной модели программных приложений MVC (Model, View, Controller), которая позволяет легко вносить изменения в одну конкретную часть приложения без изменения остальных частей (см. рис. 1). Основные файлы, обеспечивающие работу данного приложения, условно разбиты на три блока: Model, Template, View (см. рис. 1). Блок Model содержит стандартный файл models.py, который автоматически создается в любом Django-проекте, а также файл k_means_app.py, в котором прописаны все основные процедуры для процесса кластеризации данных. В этом блоке происходят обработка данных и возвращение результатов работы в блок View. Блок View содержит стандартный файл views.py, в котором описан алгоритм выполнения действий, необходимых для загрузки данных, рендера шаблонов пользовательского интерфейса, представления результатов работы программы. Блок Template включает несколько файлов, которые являются шаблонами и представляют собой модифицированные htmlдокументы – main.html и some_template.html. Первый служит для отображения начальной страницы, где представлены некоторые общие сведения о кластеризации, форма для ввода данных, а также требования к ним. Второй же необходим для отображения результатов работы алгоритмов. Созданное веб-приложение содержит программную реализацию двух методов кластерного анализа: алгоритма к-средних и иерархического агломеративного алгоритма. В качестве входных данных для алгоритмов выступает двумерный массив из n записей, содержащий в себе пользовательские данные. Данный массив передается в процедуры из блока Views, где он был получен из пользовательского Excel-файла с помощью стандартной процедуры языка Python xlrd. Схема работы алгоритма к-средних представлена на рис.2. Он позволяет разбить исходное множество на группы, в каждой из которых находятся максимально «похожие» объекты. Сами группы при этом должны быть как можно «дальше» друг от друга. Мерой для определения наиболее схожих объектов является евклидово расстояние, для вычисления которого служит процедура evkl (k,p), где k – порядковый номер центра кластера, до которого вычисляется расстояние от точки с порядковым номером p.

системный администратор январь-февраль 2017

В начале работы алгоритма происходит инициализация данных. Создается массив центроидов, расстояний между объектами и центрами кластеров, ближайших к точке центроидов. Заполняется массив объектов – tochki. В качестве центроидов в данной реализации алгоритма выбираются первые k точек. После этих действий алгоритм готов к запуску итераций, все основные действия которых происходят в процедуре find_min(). Первым шагом итерации является нахождение ближайших к центроидам точек. Для этого заполняется массив евклидовых расстояний mas_rasst при помощи процедуры evkl. Затем для каждой точки определяется ближайший кластер и записывается в массив mas_min. Следующим шагом является перерасчет координат центроидов как среднее принадлежащих им точек. Для этого служит массив sr_znach. Первые две записи каждого из его элементов служат для суммирования соответствующих координат точек, последняя представляет собой общее количество дочерних объектов. Итоговые координаты центроидов являются результатом простых вычислений: каждое из первых двух чисел разделить на значение, содержащееся в третьей ячейке. Если в результате работы полученные новые координаты центроидов (sr_znach) отличаются от старых (centri), то алгоритм запускается заново, иначе результат получен. Для проверки этого условия служит процедура check(). Кроме описанных основных процедур в составе реализации этого алгоритма, есть еще несколько вспомогательных. Это процедура main(), из которой происходит запуск итераций, процедура gmain(), которая служит для визуализации результатов работы программы, а также процедура res(), которая необходима для оценки качества проведенной кластеризации. Она вычисляет коэффициенты межкластерного и внутрикластерного расстояний, которые были упомянуты в разделе описания алгоритма кластерного анализа. Схема работы иерархического агломеративного алгоритма представлена на рис. 3. В отличие от к-средних он не является итеративным, выполняется до того момента, пока не останется один Рисунок 1. Модель MVT

Рисунок 2. Схема работы алгоритма к-средних

131

Наука и технологии кластер, с учетом того, что изначально каждый объект считается отдельным кластером. Первым шагом алгоритма является заполнение матрицы расстояний между объектами – mas_rasst. Мерой расстояния, как и в к-средних, является евклидово расстояние. Для его вычисления применяется процедура evkl(i,j), где i,j – номера элементов, между которыми вычисляется расстояние. Далее в процедуре none() выбираются два элемента с минимальным расстоянием (процедура minimum()), которые еще не находятся в одной группе, и происходит объединение тех кластеров, которым они принадлежат. Алгоритм выполняется до тех пор, пока все объекты не будут объединены. У данного алгоритма также существуют вспомогательные процедуры. Check() проверяет, не находятся ли выбранные объекты в одном кластере. Процедура main() служит для запуска всех основных шагов алгоритма. Процедура dendogram() нужна для визуального представления результатов работы программы. Таблица 1. Коэффициенты оценки качества кластеризации Количество кластеров

Среднее межкластерное расстояние, F0

Среднее внутрикластерное расстояние, F1

F1/F2

64 227

24 680

2,60

53 291

21 820

2,44

45 804

16 794

2,72

45 040

14 869

3,02

Рисунок 3. Схема работы иерархического алгоритма

Рисунок 4. Иерархический кластерный анализ

132

Реализованное программное приложение использовано для кластеризации множества клиентов банка. Из общей таблицы, содержащей сведения о клиентах банка, была сформирована выборка из 50 записей, для которых известны данные о текущей сумме их кредита и ежемесячном доходе. У банка имеется несколько предложений по выдаче кредитных карт, которые отличаются предлагаемой суммой. Задача заключается в разбиении множества клиентов на несколько групп, каждой из которых будет соответствовать наиболее подходящее кредитное предложение. Для запуска алгоритмов кластерного анализа необходимо запустить приложение и выбрать Excel-файл с исходными данными, определить количество кластеров для алгоритма к-средних в соответствующем поле ввода и нажать кнопку «Загрузить». Произойдет запуск алгоритма, после чего посетителя перенаправят на страницу с итогами. Первое изображение на данной странице представляет дендограмму – результат работы иерархического агломеративного алгоритма. Это изображение имеет один существенный недостаток – чем больше объектов были выбраны для анализа, тем менее читаемая схема получается на выходе. Эта проблема может быть решена в дальнейшем специальным форматным выводом дендограммы. В нашем примере иерархическая кластеризация пятидесяти объектов предоставляет в результате приемлемое изображение (см. рис. 4). В данном случае на изображении с результатами иерархического кластерного анализа достаточно четко выделяются две группы объектов (см. рис. 4). Это позволяет сделать вывод о том, что «естественным» разбиением данного массива объектов является разбиение на два кластера, но данное утверждение нужно проверить. Для этого необходимо запустить программу несколько раз с тем же файлом данных, меняя вводимое значение в поле «количество кластеров» от двух до пяти и фиксируя параметры оценки качества кластерного анализа, результаты которых приведены в таблице 1. Как уже говорилось выше, качество кластерного анализа тем лучше, чем больше межкластерное расстояние и чем меньше внутрикластерное расстояние. Их частное при этом должно быть максимальным. Таким образом, наиболее качественным разбиением исходного множества является разбиение на пять кластеров. Однако требуемое разбиение на две группы обладает максимальным средним межкластерным расстоянием, а значит, также возможно для использования. На изображении (см. рис. 5) отчетливо видны как минимум два элемента, которые были причислены ко второму кластеру, однако они достаточно близки и к первому. Еще один элемент второго кластера лежит в отдалении от его центра. Похожие элементы есть и у первого кластера. Разбиение исходного множества на пять групп визуально выглядит более естественно (см. рис. 6), каждый из кластеров обособлен и не имеет элементов со спорной принадлежностью, что может служить подтверждением полученных результатов оценки качества кластерного анализа. Однако задачей стояло разбиение множества на две группы, а значит, анализировать необходимо именно результаты кластерного анализа методом k-средних с k=2. По условию поставленной задачи у банка имеется два предложения по кредитным картам, которые отличаются предлагаемой суммой кредита. При этом у клиентов уже имеются кредиты на некоторую общую сумму, отмечаемую по оси абсцисс. Ось ординат показывает среднемесячный доход каждого клиента. Изучая результаты кластерного анализа, можно отметить, что в первой группе находятся те клиенты, у которых низкий среднемесячный доход или средний доход, но большая сумма текущего кредита. Этим клиентам банку нецелесообразно предлагать дополнительные кредитные карты с большой суммой.

январь-февраль 2017 системный администратор

Наука и технологии Второй кластер содержит в себе клиентов с высоким среднемесячным доходом или средним доходом и небольшой текущей суммой кредита. Таким клиентам банк может предложить дополнительные кредитные карты на определенных выгодных условиях. Однако есть по крайней мере один объект, который был отнесен в первый кластер, но при этом имеет высокую сумму текущего кредита и средний доход, его оттуда следует исключить. Итоговый список принадлежности клиентов кластерам: • первый кластер: 1, 3, 4, 5, 6, 7, 8, 10, 11, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 41, 42, 46, 47, 48, 49, 50, 40; • второй кластер: 2, 9, 12, 23, 24, 43, 44, 45. Таким образом, была решена задача разбиения множества, состоящего из пятидесяти клиентов на две максимально однородных группы. Однако необходимо отметить, что данное решение не является единственным и может меняться в зависимости от выбора начальных точек, метрики и ряда других параметров. Необходимо отметить, что реализованное программное приложение не связано с какой-либо конкретной предметной областью. Основным требованием к входным данным является их четко определенная структура. Поэтому приложение может быть использовано в любых сферах деятельности, где необходимо решить задачу разбиения на группы. Рисунок 5. Разбиение методом к-средних на два кластера

Приложение позволяет проводить кластерный анализ больших массивов данных без использования крупных пакетов анализа данных, которые, кроме высоких требований к специальным знаниям, также обладают достаточно серьезной стоимостью. Разработанное приложение, в свою очередь, предоставляет сервис для кластеризации на бесплатной основе в веб-интерфейсе и имеет, конечно, несколько другую аудиторию, которая ранее не была охвачена существующими сервисами. Также стоит отдельно отметить язык реализации Python. Реализованное приложение, конечно, имеет массу возможностей для расширения – начиная от увеличения размерности входных данных, заканчивая добавлением новых алгоритмов как кластеризации, так и вообще анализа данных. Средства языка Python в связке с фреймворком Django позволяют производить подобную модернизацию. EOF [1] [2] [3] [4]

[5] [6] [7]

[8]

Дюран, Б. Кластерный анализ / Б. Дюран, П. Оделл. – М.: Статистика, 2007. – 128 c. Маккинни, Уэс. Python и анализ данных / У. Маккинни. – М.: ДМК Пресс, 2015. – 482 c. Прохоренок Н.. Python 3 и PyQt. Разработка приложений / Прохоренок Н. – Петербург: БХВ, 2012. – 378 c. Свидетельство о государственной регистрации программы для ЭВМ №2016660108 Программный комплекс информационно-аналитического обеспечения технологий прогнозирования («КлаД 1.0») / В.В. Бучацкая, П.Ю. Бучацкий, К.А Гущин. Кластерный анализ. [Электронный ресурс]. – Режим доступа: http:// www.statlab.kubsu.ru/sites/project_bank, свободный. – Загл. с экрана. Методы кластерного анализа. [Электронный ресурс]. – Режим доступа: http://biznes-prost.ru/analiz-klasternyj.html, свободный. – Загл. с экрана. Научная графика в Python. [Электронный ресурс]. – Режим доступа: http://pythonworld.ru/novosti-mira-python/scientific-graphics-in-python. html, свободный. – Загл. с экрана. Официальный сайт Python. [Электронный ресурс]. – Режим доступа: https://www.python.org, свободный. – Загл. с экрана.

Ключевые слова: кластерный анализ, язык программирования Python, иерархический алгоритм, алгоритм k-means, программное приложение кластеризации данных.

Software application for data clustering Рисунок 6. Разбиение методом к-средних на пять кластеров

Buchatskaya V.V. Candidate of Technical Sciences, Associate Professor of Department of Applied Mathematics, Information Technology and Information Security. Adyghe State University, Maikop. buch_vic@mail.ru Buchatskiy P. Yu. Candidate of Technical Sciences, Head of Department of Automated Systems of Processing Information and Control. Adyghe State University, Maikop. butch_p99@mail.ru Gushchin K.A. Undergraduate student. Adyghe State University, sargos92@gmail.com Abstract: Consider the technology for creating web-resource, implements cluster analysis algorithms with the most simple and intuitive user interface, and possibility of further expansion of the functions. Describe structure and algorithm of this application. Result of the work is demonstrated by this example. Keywords: cluster analysis, the Python programming language, the hierarchical algorithm, k-means algorithm, software, data clustering application.

системный администратор январь-февраль 2017

133

Наука и технологии Маничев С.В., аспирант Федерального государственного бюджетного образовательного учреждения высшего образования «Московский технологический университет», mgupi.mgupi2010@yandex.ru

Агрегирование и декомпозиция статистических данных и ключевых показателей в процессе управления социально-экономическим развитием Субъектов РФ

Часть 2. Расширение предложенного варианта модели подготовки данных и принятия решения ОГВ Субъекта РФ с использованием средств бизнесаналитики на весь цикл управления В статье описывается расширенный вариант принятия решений цикла и исполнения в органах государственной власти с помощью КПЭ и BI, а также показывается его связь с PDCA-циклом. Продемонстрированы дополнительные возможности работы с OLAPкубами в рамках государственного управления

1. Введение

В предыдущей публикации автором была затронута одна из ключевых проблем государственного управления в РФ − проблема принятия решений в государственных органах и организациях, в частности: • определены признаки некачественных управленческих решений; • приведен краткий обзор состояния OLTP-систем в госсекторе РФ; • выделены условия для принятия качественных решений, в том числе за счет использования средств бизнес-аналитики (BI); • предложен вариант адаптации и наложения теории OLAPанализа на процесс принятия решений в органах государственной власти (далее − ОГВ) Субъектов РФ и ОГВ других уровней государственного управления. В публикации автор ставит своей целью продемонстрировать: • дополнительные возможности адаптации теории OLAP-анализа для решения задач государственного управления в Российской Федерации, в том числе для решения задач социально-экономического развития Субъектов РФ; • вариант расширения предложенной модели на весь цикл Шухарта-Деминга.

134

2. Методическая и информационная база

В качестве методической и информационной базы исследования выступили открытые источники [1-4] по проектам бизнес-аналитики для государственного сектора в России, а также административные регламенты государственных услуг и государственных функций различных регионов, таких как Москва, Санкт-Петербург и других [5]. Также в процессе подготовки данной статьи автор ориентировался на опыт крупных отечественных системных интеграторов, работающих с государственным сектором [6-9], на существующие практики (организационные и технологические) взаимодействия между различными уровнями государственной власти в России и за рубежом.

3. Агрегирование и декомпозиция данных и ключевых показателей в рамках процесса принятия и реализации решений 3.1. Вариант модели принятия решения в ОГВ Субъекта РФ с использованием системы BI и OLAP Автор в предыдущей публикации предложил один из вариантов модели принятия решения в ОГВ Субъекта РФ с использованием систем бизнес-аналитики на основе теории OLAP-анализа,

январь-февраль 2017 системный администратор

Наука и технологии а также эксплуатации систем BI при осуществлении государственных функций. Напомним основные этапы данной модели. В соответствии с моделью процесс подготовки данных для принятия решения начинается с формирования потребности в данном управленческом решении (первое инициирующее действие в соответствии с блок-схемой последовательности действий исполнения государственной функции). Далее лицо, принимающее решение (ЛПР), либо аналитик формирует запрос к таблицам фактов, в которых собираются исторические данные от Поставщиков данных (более низких уровней государственного управления или других ведомств и организаций, обеспечивающих формирование данных для BI). Запрос формируется с помощью «искусственного языка», т.е. представляется в структурированном виде. К сожалению, не все данные могут присутствовать в таблицах фактов. Причин этому множество − наиболее распространенным объяснением выступает отсутствие физического места на серверах и СХД, где можно было бы размещать исторические данные. К счастью, налаженная система получения информации от Поставщиков данных (задокументированная в административных регламентах или других НПА) позволяет оперативно получать данные, т.е. заполнять строчки в нужных таблицах фактов. Таким образом, оптимальным поведением системы бизнес-аналитики, если она не смогла в достаточной степени удовлетворить запрос лица, принимающего решение, является формирование электронных форм для сбора первичных данных. Ссылки на данные формы можно было бы размещать в сети Интернет (если только данные не содержат служебной и секретной информации), а подлинность предоставляемой информации (так же, как и идентификация организации − Поставщика данных) осуществлялась бы с помощью квалифицированной электронной подписи. Необязательно, чтобы Поставщики данных осуществляли ручное заполнение данных. В BI-системе могут быть за каждым из Поставщиков данных закреплены определенные «объекты» и «процессы» (государственные функции), по которым Поставщик владеет актуальными сведениями. Информационная система Поставщика (не важно, будет ли это ведомственная или корпоративная ИС) может собирать сведения в автоматическом режиме и с помощью веб-сервисов передавать их в BI-систему. Примером построения такого автоматизированного взаимодействия может выступать сбор информации Банком России об Управляющих компаниях паевыми инвестиционными фондами [10, 11]. После того как с помощью системы бизнес-аналитики ЛПР организовал проведение мониторинга (т.е. выслал форму для заполнения всем Поставщикам данных), а Поставщики заполнили требуемые формы, необходимо обеспечить возможность проверки данных на корректность. И снова теория бизнес-анализа подсказывает оптимальное решение для государственного сектора, а именно сочетание: • ручной верификации (специалисты по стороны ЛПР могут вручную проверять данные и допускать их в обработку с помощью собственной КЭП); • автоматической верификации («очистка данных» или cleaning, или refinement). Использование автоматической и ручной верификации подводит нас к необходимости определения качества данных. 3.2. Качество данных и ADQ Понятие «качество данных» в бизнес-анализе не имеет однозначного определения, но [12] определяет качество данных

системный администратор январь-февраль 2017

как совокупность свойств и характеристик данных, определяющих их пригодность для анализа и, соответственно, для дальнейшего принятия решения. «Очистка данных» помогает повысить качество данных, но ее применение должно начинаться с ADQ (Assessment Data Quality или «Оценка качества данных»), иначе могут реализоваться риски слишком сложной и ресурсозатратной очистки данных или же качество данных будет только снижено. Правильнее было бы сказать, что «автоматическая верификация» данных от Поставщиков в государственном секторе − это ADQ + refinement. Для ручной верификации могут применяться способы визуализации первичной информации не в виде строчек в конкретных таблицах фактов, а в виде графиков, диаграмм и т.п. В таком представлении эксперту предметной области легче зафиксировать аномальные отклонения, некорректные данные и т.п., в том числе заведомые искажения данных Поставщиками. Автоматическая верификация должна предусматривать: • поиск орфографических ошибок (путем сравнения со словарем предметной области или даже административным регламентом); • поиск пропущенных, дублирующих, логически неверных, противоречивых и фиктивных значений на уровне записей и таблиц (проверка нарушений в структуре данных, наименований таблиц и атрибутов; проверка на наличие значений для обязательных полей; проверка соответствия значения формату и кодировке; проверка на уникальность и устранение дубликатов). Методы бизнес-аналитики позволяют (при невозможности получения дополнительной информации от Поставщика данных) в условиях ограниченного времени для подготовки данных для ЛПР осуществить заполнение пропусков с помощью аппроксимации (для упорядоченных данных, таких как временные ряды) или метода максимального правдоподобия (для неупорядоченных данных: определяется плотность распределения вероятностей и отсутствующие данные заменяются значениями, соответствующими ее максимуму) [13]. 3.3. Принятие решения в области государственного управления на основе предложенной модели После успешной подготовки данных достаточного качества аналитик или сам ЛПР может принимать решение на основе визуализации актуализированных данных. Концептуально решения в области государственного управления на уровне Субъектов РФ можно условно разделить на две категории: • стратегические решения (для принятия которых потребуется определение общих трендов в исторических данных); • «оперативные» финансовые решения (решения о выделении или распределении финансовых средств на определенную деятельность определенным ведомствам и организациям). Для принятия стратегически решений ЛПР необходимо увидеть либо показатели процесса за значительный временной интервал (т.е. агрегацию данных по измерению «Время»), либо на территории Субъекта РФ или даже страны (т.е. агрегацию по измерению «Административно-территориальная единица»). Также могут использоваться методы построения трендов, факторный и корреляционный анализ (для установления того, какие факторы на какие влияют, чтобы воздействовать на причину, а не на следствие), методы прогнозирования и т.п.

135

Наука и технологии С «оперативными» финансовыми решениями возможностей бизнес-аналитика предоставляет гораздо больше. По своей сути, стратегические решения означают все большую консолидацию («движение вверх», иерархическую агрегацию) данных, тогда как «оперативные» решения по распределению финансовых средств представляют собой drill-down фактов («движение вниз», детализацию и декомпозицию данных). Здесь могут приняться методы ABC- и XYZ-анализа, методы кластеризации и т.п. 3.4. Расширение предложенной модели на весь цикл управления Приведенная выше модель может быть расширена и укрупнена, если включить в нее не только процесс сбора данных для подготовки решений, но весь цикл управления («Планирование» − «Организация» − «Исполнение» − «Контроль»). В таком случае фактами становятся не только фактические данные (данные о текущем состоянии процесса / объекта деятельности), но целевые показатели (данные о плановом состоянии процесса / объекта деятельности) (см. рис. 1). Цикл принятия и исполнения решений в государственном управлении согласно нижеприведенной интерпретации представляет собой: 1. Формулирование цели (основного стратегического показателя, например, «90% исполнение годового бюджета» или «достижение 85% наполняемости школьных зданий от их проектной мощности за 3 года») на верхнем уровне управления в критериях SMART (цель должна быть конкретной, измеримой, достижимой, актуальной и ограниченной во времени [14]). 2. Декомпозиция основного стратегического показателя на отдельные ключевые показатели (в зависимости от цели это могут быть плановые показатели результата либо KPI осуществляемого процесса). 3. Исполнение процесса на оперативном уровне управления приводит к созданию новых данных (фактических результатов деятельности). 4. Исполнение процесса сопровождается непрерывным мониторингом (который выражается в получении «моментальных снимков» − срезов KPI), что позволяет идентифицировать

отклонения и аномалии в процессе осуществления деятельности, а не после получения результата, не соответствующего сформулированным целям. 5. Данные с нижних уровней иерархически консолидируются на верхние уровни, где происходит сравнение их с плановыми/целевыми. 6. На основании сравнения данных и ключевых показателей ЛПР принимает новое решение, формируя новую цель, запуская новый виток цикла. Интересно, что BI обычно представляется ИТ, ключевыми пользователями которой являются стратегические руководители, однако в предлагаемой модели BI выступает связующим звеном и фактически инструментом кросс-взаимодействия уровней управления государственной власти. В рамках данной публикации фактически автор предлагает использовать BI + OLAP как средства постоянного и непрерывного мониторинга и сравнения показателей целевых (плановых) и фактических. Подобное построение процесса принятия и исполнения решений полностью накладывается на цикл Шухарда-Деминга (PlanDo-Check-Act) [15], однако имеет ряд недостатков, таких как: 1. При декомпозиции целевых показателей не учитывается доля того или иного объекта деятельности в достижении общего результата. 2. При агрегации данных не учитывается доля того или иного объекта деятельности в достижении общего результата. 3. Проблема соответствия KPI начальных подразделений KPI конечных подразделений. 3.5. Проблема учета доли конкретного объекта деятельности в достижении общего результата при декомпозиции целевого показателя и дополнительные возможности OLAP-анализа в государственном управлении Остановимся подробнее на первой проблеме при декомпозиции целевых показателей. Чтобы пояснить, что имеется в виду, рассмотрим условный пример: в Субъекте РФ есть только два административных района – А и Б. В этом регионе орган исполнительной власти, отвечающий за агропромышленный комплекс (ИОГВ

Рисунок 1. Цикл принятия и исполнения решений в государственном управлении с использованием KPI и систем бизнес-аналитики

136

январь-февраль 2017 системный администратор

Наука и технологии АПК), имеет цель на год – произвести как минимум 100 тонн зерна. Этот целевой показатель распределен поровну между двумя районами, т.е. и А, и Б должны произвести по 50 тонн зерна за год. Допустим, что район А произвел 80 тонн зерна, а район Б – 30 тонн зерна. Используя целевой показатель «Как минимум 50 тонн зерна для одного административного района Субъекта РФ», легко сделать вывод: район А смог достигнуть поставленной цели, а район Б – нет. Но этот вывод легко сделать на нижнем уровне управления, где есть доступ к детализации данных. С формальной точки зрения целевой показатель для ИОГВ АПК выполнен – Субъектом РФ произведено 110 тонн зерна. То есть на верхний уровень управления (например, на федеральный уровень) придет информация, что Субъект РФ смог достигнуть поставленной цели и даже превысил плановое производство зерна на 10 тонн. Лицо, принимающее решение, получив такой показатель, в следующий раз будет увеличивать плановый показатель со 100 тонн, к примеру, до 108 тонн. Этот показатель снова спуститься на уровень административных районов: на этот раз им «придется» произвести не 50, а 54 тонны зерна. Для района Б (который не может произвести 50 тонн в силу природных причин – размера посевных площадей) подобное управленческое решение покажется более чем странным и необоснованным. Фактически «простая» (без учета доли в общем результате) агрегация и декомпозиция данных и целевых показателей потенциально приводит к неправильным управленческим решениям. Автор предлагает в качестве решения данной проблемы внедрение в информационно-аналитические системы необходимого инструментария для определения и фиксации доли конкретного объекта деятельности в общем результате. Впоследствии такой инструментарий должен использовать рассчитанные доли для корректировки показателей при трансляции их на нижние уровни управления и тем самым повышать качество планирования. Причем чем чаще будет выполняться описанный выше цикл (т.е. чем короче будет период измерения либо чем больше итераций будет совершено), тем точнее будет декомпозиция целевых показателей. При этом данный инструментарий не должен заменять изучение причин отклонений (как положительных, так и отрицательных) от целевых показателей. Для нашего условного примера государственным служащим все равно необходимо получить информацию о том, что район Б не имеет соответствующей посевной площади либо такой технологии производства зерна, которая даже в существующих условиях позволила бы ему достигнуть целевого показателя. Но эта проблема лежит в плоскости управления коммуникациями между различными уровнями государственного управления, а не в плоскости систем бизнес-аналитики. В завершение представления возможностей применения такого метода бизнес-аналитики в госуправлении, как OLAP-анализ, необходимо также отметить, что этот метод обеспечивает ЛПР // аналитика дополнительными возможностями работы с данными и восприятия данных, гораздо большими, чем обычные методы предоставления данных в текстовом или табличном виде. При работе с измерениями OLAP-куба извлечение нужной информации можно получить с помощью: > сечения (среза) − т.е. выделения подмножества ячеек гиперкуба при фиксировании значения одного или нескольких измерений (пример: имеются данные по всем государственным закупкам Субъекта РФ, а ЛПР должен оценить потенциальные «подозрительные» ИТ-сделкам конкретного ОГВ − для удобства назовем его «Министерством государственных закупок». Для этого он может выполнить сечение по значению «Министерство государственных закупок» измерения «Заказчик» − полученный

системный администратор январь-февраль 2017

срез можно представить в виде таблицы, которая содержит все сделки этого ОГВ, а затем выполнить еще одно сечение по измерению «ОКПД», например по «Производство готового программного обеспечения и предоставление прав на его использование» и «Консультации системного и технического характера». Два этих среза позволят ему увидеть ряд ИТ-сделок с указанием организаций, выигравших конкурсы за определенные периоды, причем результат запроса представляет собой кросс-таблицу и воспринимается даже неспециалистом); > изменения порядка следования измерений; > частного случая изменения порядка следования измерений: » транспонирования (вращения) − используется для того, чтобы сделать плоские таблицы более наглядными путем измерения порядка представления измерений таким образом, что измерения, бывшие в столбцах, будут отображаться в строках и наоборот; » свертки (группировки) − применяется в случае иерархической подчиненности данных, подразумевает замену одного или нескольких подчиненных значений измерений теми значениями, которым они подчинены (что очень удобно для широкой сети подведомственных ведомствам бюджетных, муниципальных и автономных организаций); » операции, обратной операции группировки − детализации (декомпозиции), − применяется в случае иерархической подчиненности данных, подразумевает замену значений измерений более высокого иерархического порядка одним или несколькими значениями более низкого порядка (например, вместо категории учреждений «Льготные аптеки» отображаются конкретные наименования льготных аптек в том или ином районе Субъекта РФ); » замены измерений − подразумевает замену одних измерений другими − например, измерения «Количество работников» на измерение «Количество государственных служащих» (чтобы оценить, сколько людей работает в ведомстве на государственной службе, а не просто задействовано в проектной деятельности и т.п.); » добавления измерений − увеличение числа измерений (например, добавление рядом с измерением «Размер очереди в МФЦ» измерений «Количество окон приема» и «Среднее время ожидания в очереди» − и увидеть более объективную картину); » удаления и скрытия измерений − уменьшение числа измерений (например, если значения измерения не проясняют картину, а лишь вносят дополнительный «информационный шум»); » фильтрации значений измерений. Подводя итог, отмечу, что системы бизнес-аналитики, правильно применяемые, способны обеспечить исполнение государственных функций условиями принятия качественных управленческих решений, о которых говорилось в начале данной публикации: • BI-системы используют научные подходы, основанные на математическом анализе, методах оптимизации и аналитических методах решения задач, а также теории систем и системном анализе и моделирования и прогнозирования экономических систем; • постоянная актуализация данных обеспечивается с помощью SOA-интеграции с учетными ведомственными и корпоративными системами Поставщиков данных и применении КЭП для подтверждения данных;

137

Наука и технологии • использование иерархии измерений обеспечивает структуризацию предметной области (т.е. объекта деятельности ОГВ); • возможность манипулирования измерениями OLAP-куба позволяет обеспечить сравнительный анализ в процессе принятия управленческого решения; • предварительная верификация обеспечивает соответствие данных для принятия решения действующим нормативноправовым актам; • BI-системы, КЭП и веб-сервисы обеспечивают автоматизацию процессов сбора и обработки информации, а также процесса по разработке и реализации решения.

4. Выводы и перспективы будущей работы

В данной статье рассмотрена одна из ключевых проблем государственного управления в РФ − принятие решений в государственных органах и организациях. Автором был предложен расширенный вариант цикла принятия и исполнения решений в государственном управлении с использованием KPI и BI, а также показана его взаимосвязь с циклом PDCA. Также были продемонстрированы на примерах дополнительные возможности работы с OLAP-кубами в рамках госуправления. В последующих публикациях автор планирует подробнее рассмотреть следующие проблемы: • учет долей объектов деятельности при агрегации данных; • соответствие целевых показателей для взаимосвязанных объектов деятельности (например, начальной школы и основной школы). EOF [1] [2] [3] [4] [5]

[6] [7] [8] [9] [10] [11]

[12]

[13] [14] [15]

138

http://www.idc.com – международная исследовательская и консалтинговая компания IDC (дата обращения: 01.11.2016). http://www.cnews.ru – ИТ-обозреватель CNews (дата обращения: 01.11.2016). http://www.tadviser.ru – ИТ-обозреватель Tadviser (дата обращения: 01.11.2016). http://www.crn.ru/research – ИТ-обозреватель CRN (дата обращения: 01.11.2016). http://docs.cntd.ru – электронный фонд правовой и нормативнотехнической документации. Консорциум «Кодекс» (дата обращения: 01.11.2016). http://www.prognoz.ru – ЗАО «Прогноз» (дата обращения: 01.11.2016). http://bars-open.ru – «Барс-Груп» (дата обращения:01.11.2016). https://basegroup.ru – ООО «Аналитические технологии» (дата обращения: 01.11.2016). http://www.fors.ru – Группа компаний «ФОРС» (дата обращения: 01.11.2016). Информационное письмо Банка России от 15.08.2014 исх. № 06-572/6659 «О представлении отчетности и уведомлений». http://www.cbr.ru/finmarkets/print.aspx?file=files/account/edocs/ programma-anketa_arch2.htm − электронная анкета ФСФР России (Банк России), которую заполняют УК паевыми инвестиционными фондами (дата обращения: 01.11.2016). Паклин Н.Б., Орешков В.И. Бизнес-аналитика: от данных к знаниям. Учебное пособие. 2-е издание, исправленное [Текст]. − М.: Питер, 2013. − ISBN 978-5-459-00717-6. Тюрин Ю.Н., Макаров А.А. Статистический анализ данных на компьютере [Текст]/ Под ред. В.Э. Фигурнова. − М.: ИНФРА-М, 1998. − 528 с. Друкер Питер. Практика менеджмента [Текст]. − М.: МИФ, 2015. − 416 с. – ISBN 978-5-00057-332-7. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. − М.: РИА «Стандарты и качество», 2008. − 408 с. − ISBN 978-5-94938-063-5.

[16] Барсегян А.А., Куприянов М.С., Степаненко В.В., Холод И.И. Методы и модели анализа данных: OLAP и Data Mining [Текст]. − Спб: БВХПетербург, 2004. − 336 с. Ключевые слова: бизнес-аналитики, государственные функции, интерактивная аналитическая обработка (OLAP), обработка транзакций в реальном времени (OLTP), измерения, качество управленческих решений, цикл Деминга-Шухарта, оценка качества данных (ASQ).

Aggregation and decomposition of statistical data and key performance indicators in the management of socio-economic development of subjects of the Russian Federation. Part 2. Expansion of the proposed variant model for data preparation and decision-making by public authorities of the subjects of the Russian Federation using the means Business Intelligence to the entire management cycle Manichev S.V., graduate student of Federal State Institution of Higher Education «Moscow Technological University», mgupi.mgupi2010@yandex.ru Abstract: The article describes an expanded version of the cycle decision making and execution in public authorities using of KPI and BI, and also shows its relationship with the PDCA-cycle. There have also been demonstrated by the additional opportunities to work with OLAP-cubes in the framework of public administration. Keywords: business intelligence, government functions, Online Analytical Processing (OLAP), Online Transaction Processing (OLTP), measurements, quality of management decisions, Deming-Shewhart cycle, Assessment Data Quality (ASQ). References: [1] http://www.idc.com (date: 01.11.2016). [2] http://www.cnews.ru (date: 01.11.2016). [3] http://www.tadviser.ru (date: 01.11.2016). [4] http://www.crn.ru/research (date: 01.11.2016). [5] http://docs.cntd.ru (date: 01.11.2016). [6] http://www.prognoz.ru (date: 01.11.2016). [7] http://bars-open.ru (date: 01.11.2016). [8] https://basegroup.ru (date: 01.11.2016). [9] http://www.fors.ru (date: 01.11.2016). [10] Information Letter of the Bank of Russia from 15.08.2014 ref. № 06-57-2 / 6659 «On reporting and notifications». [11] http://www.cbr.ru/finmarkets/print.aspx?file=files/account/edocs/ programma-anketa_arch2.htm (date: 01.11.2016). [12] Paklin N.B., Oreshkov V.I. Business Intelligence: from data to knowledge. Tutorial. 2nd edition, revised [Text]. − M.: Piter, 2013. − ISBN 978-5-459-00717-6. [13] Tyurin Yu.N., Makarov A.A. Statistical analysis of the data on the computer [Text] / Ed. V.E. Figurnova. − M.: INFRA-M, 1998. − 528 p. [14] Drucker P. Practice of Management [Text]. − M.: MYTH, 2015. − 416 p. − ISBN 978-5-00057-332-7. [15] Repin V.V., Eliferov V.G. Process approach to management. Business Process Modeling. − M.: RIA «Standards and quality», 2008. − 408 p. − ISBN 978-5-94938-063-5. [16] Barseghyan A.A., Kupriyanov M.S., Stepanenko V.V., Holod I.I. Methods and data analysis model: OLAP and Data Mining [Text]. − St. Petersburg: CVS-Petersburg, 2004. − 336 p.

январь-февраль 2017 системный администратор

Наука и технологии Казакова Н.А., д.э.н., профессор, директор Центра финансовых исследований Российского экономического университета им. Г.В. Плеханова, axd_audit@mail.ru Дун И.Р., к.э.н., доцент кафедры финансового контроля, анализа и аудита Российского экономического университета им. Г.В. Плеханова, irina-dun@mail.ru

Программные средства оптимизации ресурсного потенциала как инструмент управления рисками и планирования финансовой политики компании

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

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

системный администратор январь-февраль 2017

бизнес постоянно обновлять основные средства. Однако лизинговый бизнес сегодня также находится не в лучшем положении. В сложных международных условиях продолжается сокращение количества лизинговых компаний как результат процессов укрупнения бизнеса вследствие банкротства или продажи активов контрагентам. Несмотря на это, лизинговая деятельность в Российской Федерации активно развивается, о чем свидетельствует рост стоимости активов по новым лизинговым сделкам, в то время как по большинству видов деятельности в российской экономике наблюдается стагнация. Перспективы развития рынка лизинговых услуг связаны прежде всего с положительным влиянием государственных мер нормативного характера и субсидий, государственных целевых программ поддержки лизинговых компаний в транспортной сфере (обновление основных средств авиа, автомобильных и железнодорожных компаний на основе механизмов государственно-частного партнерства) [3].

139

Наука и технологии Экономическая эффективность лизингового метода обновления основных фондов промышленными компаниями по сравнению с альтернативными методами финансирования сводится к двум основным аспектам. Для крупных компаний, имеющих достаточный доступ к различным формам кредитования, лизинг эффективен по причине возможности забалансового финансирования, обеспечивающего оптимальный риск-менеджмент, гибкого управления денежными потоками, а также наличия налоговых и амортизационных льгот. Для малых и средних предприятий главным критерием использования лизинга являются его доступность и наличие эффективного стимула вывода своей деятельности «из тени» при получении лизингового финансирования [1, 2, 4]. Среди объективных факторов использования лизинга следует назвать: • во-первых, ускорение темпов обновления техники и технологии и, следовательно, сокращение сроков морального старения оборудования и увеличение их отрыва от периода полного физического износа; • во-вторых, усложнение и удорожание сервисного обслуживания новой техники, ограничивающие выполнение его самими пользователями; • в-третьих, усиление дифференциации выпускаемой продукции и расширение потребности не постоянного, а временного использования дорогостоящей специализированной техники; • в-четвертых, возрастание сложности оптимального выбора наиболее эффективных моделей (марок) машин в увеличивающемся их ассортименте на рынке средств производства; • в-пятых, прогрессирующую нехватку капитала на финансовом рынке и распространенную недоступность традиционных источников инвестирования для малого и среднего бизнеса. Любой лизинговой компании нужны стабильные источники финансовых средств для закупок лизингуемой техники. Поэтому из всего многообразия функционирующих лизинговых компаний подавляющее большинство создано при участии коммерческих банков. Преимущества лизинговой деятельности для коммерческих банков связаны с наличием у лизинговых операций реального материального обеспечения; сравнительно высокой доходностью лизинговых операций за счет комиссионных выплат, а также возможностью диверсификации операционной деятельности; повышением устойчивости за счет инвестирования материального производства и расширения сферы влияния в регионе [5, 7]. Положительной предпосылкой развития лизинга является участие в крупных промышленных проектах и взаимодействие с региональными органами власти. В связи с этим нами разработана полезная модель, которая относится к моделированию специальных процессов и систем и может быть использована для управления процессом лизинга в промышленности, что будет способствовать повышению эффективности и финансовой устойчивости бизнеса в целом. Существующая модель управления процессом лизинга в промышленности, послужившая прототипом (свидетельство на полезную модель РФ №28558, 2003 г.), предназначена для оптимизации финансовых процессов при нарушении условий лизингового договора, изъятии имущества у недобросовестного лизингополучателя или при наступлении страховых случаев. Существенным недостатком известной модели управления процессом лизинга в промышленности является отсутствие анализа

140

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

январь-февраль 2017 системный администратор

Наука и технологии задания условий договора купли-продажи, блоком, моделирующим условия договора поставки, и блок определения финансовой эффективности сделки, который соединен с блоком, моделирующим поведение лизингодателя, и блоком моделирования схем формирования лицензионных платежей. Наличие большого количества различных методов расчета лизинговых платежей, их непрозрачность, а также неадекватность текущему налоговому и бухгалтерскому законодательству приводит к проблемам во взаимоотношениях лизинговых компаний с лизингополучателями, а также к сложностям обоснования эффективности лизингового метода обновления основных производственных фондов и, соответственно, заключения договора лизинга. Для решения данных проблем предназначена разработанная нами программа для ЭВМ «ЛизингМастер», автоматизирующая расчеты лизинговых платежей, на которую в 2015 году получено авторское свидетельство. Подход, предложенный нами, учитывает вышеизложенные особенности лизингового проекта, позволяет корректно учитывать финансовую эквивалентность лизинговых платежей, не противоречит основным экономическим интересам основных субъектов лизинговых отношений, дает возможность экономически верно и прозрачно рассчитывать вознаграждение лизингодателя, правильно учитывать все возможные налоговые потоки в рамках лизингового проекта, а также, что зачастую наиболее важно, является гибким в расчете и прозрачным при обосновании перед лизингополучателем [9].

системный администратор январь-февраль 2017

Погашение задолженности по лизинговым контрактам может осуществляться на основе различных схем (способов оплаты). Лизингодатель и лизингополучатель выбирают и согласовывают наиболее удобный для них по срокам и размерам платежей способ. Как правило, задолженность по лизингу погашается периодическими лизинговыми платежами. Иногда вносится аванс. Выплаты по лизингу различаются: • по размеру платежей: постоянные, переменные; • по применяемой процентной ставке: простая – для очень коротких платежей, сложная – для средних и долгосрочных, постоянная или переменная; • по моменту производства платежей: пренумерандо – в начале периода, постнумерандо – в конце периода; • по периодичности выплат. Обычно лизинг предусматривает ежемесячные платежи, редко ежеквартальные или полугодовые. Расчет лизинговых платежей можно вести по двум схемам. Программа для ЭВМ «ЛизингМастер» помогает автоматизировать расчеты погашения задолженности по лизинговым контрактам на основе различных схем (способов оплаты): • первая схема проводит расчеты размера процентных платежей и суммы погашения долга, затем определяется общая и средняя величина лизинговых платежей; • вторая схема определяет величину лизинговых платежей, далее распределяет эту величину на процентные платежи и суммы погашения долга.

141

Наука и технологии Рисунок 1. Окно программы по расчету размера процентных платежей и суммы погашения долга

Рисунок 2. Окно программы для определения величины лизинговых платежей

Рисунок 3. Окно расчета финансовой эффективности лизинговых платежей

142

Первая схема проводит расчеты размера процентных платежей и суммы погашения долга, затем определяется общая и средняя величина лизинговых платежей (см. рис. 1). Вторая схема определяет величину лизинговых платежей, далее распределяет эту величину на процентные платежи и суммы погашения долга (см. рис. 2). Кроме того, приложение позволяет рассчитать финансовую эффективность лизинговых платежей (см. рис. 3). Результатами применения данной программы «ЛизингМастер» являются как количественные, так и качественные показатели-индикаторы. Количественными показателями оценки эффективности лизинговых операций можно назвать: • сокращение времени расчетов по погашению задолженности по лизинговым контрактам до 20 минут; • привлечение меньшего количества людей, которые будут вовлечены в процесс расчетов по лизинговым операциям (один человек, который забивает данные в программу); • проведение лабораторных занятий с использованием разработанной программы для студентов в целях закрепления материала по лизинговым операциям. Качественные характеристики – преимущества использования программы заключаются в автоматизации расчетов, уменьшении трудоемкости расчетов, быстром получении результатов [4]. Программа «ЛизингМастер» проста в эксплуатации, не требует специальных настроек и технических знаний. Поэтому разработчики рекомендуют использовать программу всеми лизингополучателями, заинтересованными в определении выгодности сделки (покупать или арендовать имущество), лизингодателями, которым необходимо определить размер лизинговых платежей и финансовую эффективность сделки [8]. На сегодняшний день существует ряд других программ, которые помогают произвести расчеты погашения задолженности по лизинговым контрактам, но они не в полной мере раскрывают всю необходимую информацию по лизинговым сделкам, которая могла бы быть полезна для пользователей, более того, они не проводят анализ эффективности использования лизинговой схемы. Результаты исследования свидетельствуют, что расчет лизинговых платежей должен одновременно учитывать экономические интересы всех сторон лизингового проекта. По этой причине расчет платежей необходимо осуществлять с учетом его влияния на финансовое состояние как лизингополучателя, так и лизингодателя [6, 9]. Расчет финансовой эффективности лизинговых операций определяют по разности между лизинговой ставкой и нормой амортизации (без учета расходов на обслуживание и ремонт имущества, сдаваемого в лизинг) для всех вариантов и выбирают наиболее выгодный и приемлемый. Потребности финансового планирования требуют, чтобы расчеты лизинговых платежей обеспечивали сбалансированность бюджетов доходов и расходов и движения денежных средств, а также позволяли учитывать экономическую сущность лизинга и наилучшим образом формировать финансовые показатели как лизинговой компании, так и лизингополучателя. В этом случае при расчете лизинговых платежей необходимо соблюдать корректные источники погашения кредита: амортизацию предмета лизинга и налог на добавленную стоимость, возмещаемый из бюджета.

январь-февраль 2017 системный администратор

Наука и технологии При таком подходе к расчету лизинговых платежей в каждый период времени у лизинговой компании будет прибыль, соответствующая остатку денежных средств на ее счетах. Кроме того, в этом случае в бухгалтерском и налоговом учете основных субъектов лизинговых отношений отсутствуют проблемные моменты. На основе полученных результатов выбирают наиболее удобную и гибкую схему финансирования лизинговых операций и заключают необходимые договора. Полезная модель относится к моделированию специальных процессов и систем и может быть использована для моделирования управления процессом лизинга в промышленности, а также на практических занятиях студентов при изучении экономической устойчивости, эффективности деятельности, безубыточности финансовых вложений компаний. Отдельные блоки программы «ЛизингМастер» можно использовать на лабораторных занятиях в компьютерных классах высших учебных заведений для автоматизации процесса расчетов погашения задолженности по лизинговым контрактам на основе различных схем: от определения результатов по лизинговым сделкам до анализа эффективности по конкретным операциям [4]. EOF [1] [2] [3]

Казакова Н.А. Анализ, сравнительная оценка и прогнозирование эффективности лизинговых операций. // «Лизинг», №8, 2014 г. – С. 61-69. Казакова Н.А., Дун И.Р. Анализ прогнозирования остаточной стоимости лизингового имущества. // «Лизинг, № 5, 2014 г. – С. 8-15. Иванова А.Н., Казакова Н.А. Оценка риска неоптимального состояния основных фондов для компаний нефтегазовой отрасли. // «Лизинг», №2, 2016 г. – С. 29-36.

Software optimization resources as a tool for risk management and financial planning company policy Nataliya Kazakova, Plekhanov Russian University of Economics, Professor, Doctor of Economic Science, Irina Dun, Plekhanov Russian University of Economics, PhD, Associate Professor Abstract: In conditions of insufficient financial resources for business development companies are forced to update technology, equipment and other fixed assets for production of competitive goods with borrowed sources either use leasing as a more affordable way to update the production funds. This increases the level of risk and the extent of their impact on the financial results of the company, increasing the uncertainty of the economic situation. In this regard, we propose the use of software and tool supply, allowing you to reduce risks when planning the financial policies of the company. We offer leasing management model in the industry provides an optimization tool company resources when using financial leasing as a source of business development. Development refers to special processes and systems modelling and unlike existing prototype allows you to quickly analyze the structure of leasing payments, evaluate cost-effectiveness of leasing operation that gives her an advantage when planning the financial policies of the company and used as a tool to optimize resources and risk management. Keywords: program, a utility model, optimization, planning, resources, finances, efficiency, leasing, risk, financial policies. References:

системный администратор январь-февраль 2017

[4]

Казакова Н.А., Дун И.Р. Информационная программа для анализа и оценки эффективности лизинговых операций «ЛизингМастер». // «Лизинг», №2, 2016 г. – С. 48-52. [5] Казакова Н.А. Развитие компетентностного подхода к подготовке кадров в системе высшего экономического образования: опыт Российского экономического университета имени Г.В. Плеханова. // «Современные проблемы науки и образования», №5, 2016 г. – С. 234. URL: http://www.science-education.ru/article/view?id=25269 (дата обращения: 10.10.2016). [6] Когут Е.А., Иванова А.Н., Казакова Н.А. Анализ влияния амортизационной политики на финансовые результаты хозяйственной деятельности лизинговой организации. // «Лизинг», №1, 2015 г. – С. 32-35. [7] Дун И.Р., Дун И.В. Лизинг как механизм развития предпринимательской деятельности. //Saarbrucken, 2011. [8] Казакова Н.А., Дун И.Р. Программа анализа и оценки эффективности лизинговых операций «ЛизингМастер». // «Системный администратор», №1-2, 2016 г. – С.141-143. URL: http://samag.ru/archive/ article/3138 (дата обращения: 16.01.2017). [9] Казакова Н.А., Кисничян М.Б., Сивкова А.Е., Казаков А.Ю. Учет, анализ и оценка рисков предпринимательской деятельности на рынке лизинговых услуг. // «Лизинг», №4, 2015 г. – С. 53-61. [10] Дешин В.Е., Дун И.Р. Эффективность лизинговых операций. // «Все для бухгалтера», №8, 2009 г. – С. 47-52. Ключевые слова: программа, полезная модель, оптимизация, планирование, ресурсы, финансы, эффективность, лизинг, риск, финансовая политика.

[1] Analysis, comparative evaluation and prediction of effectiveness of leasing operations. /Kazakov N.A.//Leasing. 2014. # 8. P. 61-69. [2] Analysis of prediction of the residual value of the leased property. / Kazakov N.A., Dun I.R. Leasing. 2014. # 5. P. 8-15. [3] Ivanova A.N., Kazakova N.A. Risk assessment of suboptimal state of the main funds for companies in the oil and gas industry. Leasing. 2016. No. 2. P. 29-36. [4] Kazakov N.A., Dun I.R. Information programme for the analysis and assessment of the effectiveness of leasing operations "Lizingmaster". Leasing. 2016. # 2. P. 48-52. [5] Kazakova N.A. Development of competence-based training approach in higher economic education: experience of Russian economic University named after G.v. Plehanov. Modern problems of science and education. 2016. # 5. P. 234. URL: http://www.science-education.ru/ article/view?id=25269 (date: 10.10.2016). [6] Kohut E.A., Ivanova A.N., Kazakova N.A. Depreciation policy impact analysis on the financial results of economic activity of the leasing organization. Leasing. 2015. # 1. P. 32-35. [7] Leasing as a mechanism for the development of entrepreneurship. / Dun I.R., Dun I.V.//Saarbrucken, 2011. [8] Program analysis and evaluation of the effectiveness of leasing operations "LIZINGMASTER". Kazakov N.A., Dun I.R. System administrator. # 0102 (158-159), 2016. P. 141-143. [9] Accounting, analysis and risk assessment of entrepreneurial activity in the leasing market. Kazakova N.A., Kisnichjan M.B., Sivkova A.E., Kazakov A.Y.//Leasing. 2015. # 4. P. 53-61. [10] Efficiency of leasing operations/Deshin V.E., DUN I.R. All for accountant. 2009. # 8. P. 47-52.

143

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

Тесла о себе, о науке, о вечности

Издается с 2002 года «Системный администратор» включен в перечень ведущих рецензируемых журналов ВАК Минобрнауки РФ http://vak.ed.gov.ru/87 Включен в Российский индекс научного цитирования www.elibrary.ru

Сегодняшний экспонат нашего виртуального музея – высказывания человека, которого все считали гением. Все, включая его самого. О Николе Тесле читайте статью в этом номере журнала, а здесь подобраны некоторые из откровений одной из самых противоречивых и загадочных фигур прошлого века. Распространение цивилизации можно сравнить с огнем, сначала это слабая искра, затем мерцающий огонек, а потом могущественное пламя, наделенное скоростью и силой. Несмотря на свободу воли и действия, мы удерживаемся вместе, подобно звездам на небесном своде, соединенные неразрывными узами. Эти узы незримы, но мы можем их ощущать. Я порезал палец, и он кровоточит: этот палец – часть меня. Я вижу боль друга, и эта боль ранит меня тоже: мы с другом едины. И наблюдая поверженного врага, даже такого, о ком я сожалел бы меньше всего во всей Вселенной, я все равно испытываю скорбь. Разве это не доказывает, что мы все лишь частица единого целого? Говоря о человеке, мы также представляем и человечество в целом, и, применяя научные методы к отдельной личности, следует учитывать этот физический факт. Но может ли кто-либо сомневаться, что все эти миллионы индивидуальностей, бесконечные типы и характеры составляют единое целое? В беспрерывном одиночестве ум становится все острее. Для того чтобы думать и изобретать, не нужна большая лаборатория. Идеи рождаются в условиях отсутствия влияния на разум внешних условий. Секрет изобретательности в одиночестве. В одиночестве рождаются идеи. Не думаю, что вам удастся назвать множество великих изобретений, сделанных женатым мужчиной. Нет ничего, что в большей степени могло бы привлечь внимание человека и заслужило бы быть предметом изучения, чем природа. Понять ее огромный механизм, открыть ее созидательные силы и познать законы, управляющие ею, – величайшая цель человеческого разума. Не будет большим злом, если студент впадет в заблуждение; если же ошибаются великие умы, мир дорого оплачивает их ошибки. Мой мозг – только приемное устройство. В космическом пространстве существует некое ядро, откуда мы черпаем знания, силы, вдохновение. Я не проник в тайны этого ядра, но знаю, что оно существует. Если передо мной стояла какая-то изнурительная задача, я набрасывался на нее снова и снова, пока не решал ее. Так я практиковался день за днем, с утра до ночи. Сначала это требовало сильного умственного усилия, направленного против склонностей и желаний, но шли годы, и это противоречие ослабевало, и наконец мои воля и желание стали одним и тем же. Таковы они и сегодня, и в этом лежит секрет всех моих успехов. Интуиция – это нечто такое, что опережает точное знание. Наш мозг обладает, без сомнения, очень чувствительными нервными клетками, что позволяет ощущать истину, даже когда она еще недоступна логическим выводам или другим умственным усилиям. Мне не нужны модели, рисунки, эксперименты. Когда у меня рождаются идеи, я в воображении начинаю строить прибор, меняю конструкцию, совершенствую ее и включаю. И мне совершенно безразлично, проводятся испытания прибора у меня в мыслях или в мастерской – результаты будут одинаковыми. Наш мир погружен в огромный океан энергии, мы летим в бесконечном пространстве с непостижимой скоростью. Все вокруг вращается, движется – все энергия. Перед нами грандиозная задача – найти способы добычи этой энергии. Тогда, извлекая ее из этого неисчерпаемого источника, человечество будет продвигаться вперед гигантскими шагами. Современные ученые мыслят глубоко вместо того, чтобы мыслить ясно. Чтобы мыслить ясно, нужно обладать здравым рассудком, а мыслить глубоко можно и будучи совершенно сумасшедшим. Вам знакомо выражение «выше головы не прыгнешь»? Это заблуждение. Человек может все. Парадоксально, однако, истинно то, что чем больше мы узнаем, тем более невежественными мы становимся – в абсолютном измерении. Потому что только благодаря просвещению мы осознаем ограниченность наших знаний о мире. Один из самых благодарных результатов интеллектуальной эволюции – постоянное открытие новых, все более грандиозных перспектив. Лишь будущее рассудит, чего стоил конкретный человек, если говорить о его работе и достижениях. Настоящее принадлежит окружающим меня людям, будущее, на которое я только и работал, принадлежит мне. В недалеком будущем можно будет вывести на экран любой образ, созданный в нашем мозгу, чтобы затем этот образ смогли увидеть везде, где заблагорассудится. Совершенствование такого способа чтения мыслей вызовет настоящую революцию, которая улучшит наши социальные отношения. Во мне постоянно растет ощущение того, что я был первым человеком, услышавшим приветствие, посланное с другой планеты. Наши достижения и неудачи неразделимы, как сила и материя. Если их разделить, не останется человека. Для меня Вселенная представляет собой просто гигантский механизм, который, будучи однажды запущенным, будет работать вечно. Человеческое существо не является исключением из правил. Человек, как и Вселенная, – просто механизм. Человек науки не рассчитывает на немедленный результат. Его работа – та же, что у садовника: рассчитана на будущее. Дело ученого – заложить основы для тех, кто придет ему на смену. И наметить для них правильный путь. В 2035 году министры гигиены или физической культуры будут намного полезнее в правительстве Соединенных Штатов, чем министр обороны. Хочется верить, что передовые газет XXI века будут посвящены новым научным достижениям и гипотезам, а не криминальной хронике и не политике, которым будут отведены колонки на последних страницах. EOF

Владимир Гаков

144

Научный руководитель журнала – председатель Редакционной коллегии А.И. Аветисян, директор ИСП РАН, д.ф.-м.н., член-корреспондент РАН

Главный редактор Галина Положевец, chief@samag.ru Генеральный директор Владимир Положевец Шеф-редактор журнала «Системный администратор» Владимир Лукин, lukin@samag.ru Заместитель главного редактора Ирина Ложкина, lozhkina@samag.ru Заместитель главного редактора, официальный представитель редакции в Украине Сергей Яремчук, grinder@samag.ru Главный бухгалтер Надежда Кан

Юридический отдел Владимир Столяров

buch@samag.ru

stolyarov@samag.ru

Распространение Олег Иванов

reklama@samag.ru

subscribe@samag.ru Дизайн обложки Михаил Лебедев

Дизайн-макет Марина Рязанцева, Дмитрий Бессонов

Иллюстрация Виктор Чумачев

Редакционная коллегия Д. Ю. Гудзенко, к.т.н., директор Центра компьютерного обучения «Специалист» при МГТУ им. Н.Э. Баумана Д. Ю. Динцис, д.т.н., ведущий преподаватель Центра компьютерного обучения «Специалист» при МГТУ им. Н.Э.Баумана О.В. Китова, д.э.н., доцент, зав. кафедрой информатики РЭУ им. Г.В.Плеханова, директор Академического центра компетенции IBM «Разумная коммерция» в РЭУ им. Г.В.Плеханова А. С. Крюковский, д.ф-м.н., профессор, лауреат Государственной премии СССР, декан факультета информационных систем и компьютерных технологий Российского нового университета Э. С. Клышинский, к.т.н., доцент департамента компьютерной инженерии НИУ ВШЭ С. Р. Тумковский, д.т.н., профессор департамента компьютерной инженерии НИУ ВШЭ, лауреат Премии Правительства РФ в области науки и техники А. В. Сарафанов, д.т.н., профессор, лауреат премии Правительства РФ в области науки и техники, директор по развитию бизнеса ЗАО «Ай-Теко». А. В. Тетюшев, к.т.н., доцент Вологодского государственного технического университета

Экспертный совет Рашид Ачилов, главный специалист по защите информации Сергей Барамба, эксперт по системным решениям Алексей Бережной, эксперт по администрированию и ИБ Андрей Бирюков, ведущий системный инженер по ИБ Алексей Вторников, эксперт по вопросам разработки ПО Кирилл Сухов, ведущий специалист направления интернетразработки Леонид Шапиро, эксперт по ИБ и инфраструктурным проектам Сергей Яремчук, эксперт по ИБ Издатель ООО «Издательский дом Положевец и партнеры» Адрес редакции 128017, г. Москва, 3-й пр-д Марьиной Рощи, д. 40, стр. 1, офис 606, тел.: (499) 277-12-41, факс: (499) 277-12-45 Сайт журнала: www.samag.ru Отпечатано в типографии Типография «Практика». Тираж 17000 экз. Все права на материалы принадлежат журналу «Системный администратор». Перепечатка и использование материалов в любой форме, в том числе и в электронных СМИ, без разрешения запрещена. При использовании материалов ссылка на журнал «Системный администратор» обязательна. Материалы отмеченные знаком ADV публикуются на коммерческой основе. Редакция не несет ответственности за достоверность информации в материалах, опубликованных на правах рекламы.

январь-февраль 2017 системный администратор

Весь мир ИТ – в журнале «БИТ» Оформив редакционную подписку на журнал «БИТ. Бизнес&Информационные технологии», вы получите возможность узнавать о событиях в мире информационных технологий из первых уст!

Все об ИТ

#01(64) февраль 2017

Мобильные технологии

Обзор платформ мобильной разработки

Люди и роботы »? Есть ли права у «электронной личности

в бизнесе и для бизнеса

Бумажная

электронная версии

5000 руб. БИТ.Персона Валентин Макаров, президент НП «РУССОФТ»

Бумажная версия – 4000 руб.

Индустрия разработки ПО: противоречия роста ISSN 2313-8718

http://bit.sa mag.ru

Электронная версия – 2000 руб.

Подписывайтесь прямо на сайте! bit.samag.ru/subscribe