Системный администратор №6 (июнь 2016) by uzzer

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

№06(163) июнь 2016

Перенос физической ИТ-инфраструктуры в виртуальную среду

Производительность SQL-запросов в Oracle

1С в контейнере Быстро и недорого

AMP от Google Ускоряемся и взлетаем в выдаче

Service Discovery для распределенных систем

Тест на проникновение Методы, используемые злоумышленниками Изучаем 1С

Мобильные приложения

Механизмы защиты

Под капотом платформы 1С 8.3

Широковещательные сообщения

Защита от DDoS. NTP Amplification

Рассмотрим, какие основные объекты метаданных существуют сейчас в 1С, а также расскажем об особенностях работы с ними платформы 1С на стороне СУБД

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

Чтобы сделать вклад в защиту киберпространства от DDoS, не обязательно покупать дорогостоящее оборудование или сервис. Проведем анализ атак типа «усиление» (amplification)

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

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

информация

№06(163) июнь 2016

Перенос физической ИТ-инфраструктуры в виртуальную среду

Бумажная

Производительность SQL-запросов в Oracle

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

1С в контейнере Быстро и недорого

AMP от Google Ускоряемся и взлетаем в выдаче

Service Discovery

5800 руб.

для распределенных систем

ние Тест на проникнове шленниками Методы, используемые злоумы Изучаем 1С Под капотом платформы 1С 8.3 х

Рассмотрим, какие основные объекты метаданны существуют сейчас в 1С, а также расскажем 1С об особенностях работы с ними платформы на стороне СУБД

Мобильные приложения

Механизмы защиты

Широковещательные сообщения

Защита от DDoS. NTP Amplification

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

ранства Чтобы сделать вклад в защиту киберпрост щее от DDoS, не обязательно покупать дорогостоя атак типа анализ Проведем оборудование или сервис. «усиление» (amplification)

Все подробности проведения акции – на сайте журнала: http://samag.ru/solutions2masses

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

В номере

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

Механизмы защиты

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

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

Защита от DDoS подручными средствами. Часть 2. NTP Amplification. Чтобы сделать свой вклад в защиту киберпространства от DDoS, совсем не обязательно покупать дорогостоящее оборудование или сервис. В первой части статьи рассматривались протокол DNS и варианты его защиты от использования в DDoS-атаках. Продолжим анализ атак типа «усиление» (amplification).

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

Андрей Дугин

Илья Вислоцкий

Аудит Хранение данных

24 09

Системы хранения данных. Часть 3. SAN. В статье дается общее представление о работе сетей хранения данных и особенностях взаимодействия с серверным оборудованием и другими сетями.

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

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

Андрей Бирюков

Автоматизация

Проводим пентест. Часть 3. Ищем уязвимости.

Мониторинг

Service Discovery для распределенных систем.

Как отследить расположение сервисов и их доступность в динамической сети? Выход – системы обнаружения сервисов. Сергей Яремчук

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

БЕЗОПАСНОСТЬ

Рашид Ачилов

БАЗЫ ДАННЫХ

Событие

Positive Hack Days VI CityF. Противостояние глазами Защитника. 17-18 мая в Москве прошла VI ежегодная конференция PHDays, посвященная практическим аспектам информационной безопасности. Кроме конференции, разделенной на бизнес- и технический потоки, мастер-классов и конкурсов, организаторы сделали акцент на соревновании, похожем на Capture The Flag (CTF), но гораздо более масштабном. Андрей Дугин

системный администратор июнь 2016

Инструменты

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

В номере

Изучаем 1С

Мобильные приложения

Использование SQL Profiler для поиска и исправления медленных запросов в 1С. Одной из основных

причин медленной работы 1С являются неоптимальные запросы. С помощью инструмента SQL Profiler можно находить медленные запросы и способы их исправления.

Широковещательные сообщения в Android. О важных системных событиях ОС информирует все заинтересованные приложения с помощью рассылки широковещательного сообщения. Разберем, как реагировать на системные сообщения и создавать свои.

Тимур Шамиладзе

Андрей Пахомов

Под капотом платформы 1С 8.3. Часть 2. Работа с СУБД. Рассмотрим какие основные объекты метаданных существуют сейчас в 1С, а также покажем особенности работы с ними платформы 1С на стороне СУБД.

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

рассмотрим новый механизм нативных переменных в CSS или, как правильнее, пользовательских свойств. Как они работают, какие особенности, примеры использования.

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

1С в контейнере. Быстро и недорого. Результаты тестирования локальной, файловой и клиент-серверной платформы 1С v8.3 в ОС Windows и Linux. Согласно тестам для групповой работы самой быстрой является клиент-серверная реализация 1С в Linux на базе контейнеров Docker.

Переменные в CSS без препроцессоров. В статье

Александр Майоров

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

Александр Тетюшев

РАЗРАБОТКА Событие

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

Грядет DevConf 2016. 17-18 июня в Москве, в Сколково, пройдет DevConf 2016 – профессиональная конференция, посвященная ведущим технологиям программирования и веб-разработки.

КАРЬЕРА/ОБРАЗОВАНИЕ Аlma mater российских ИТ

Кирилл Сухов

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

AMP от Google. Ускоряемся и взлетаем в выдаче. В наше время актуальна проблема медленного интернета и интернета в роуминге, про которую забывают порой веб-разработчики. Google решил кардинально данную проблему с помощью своей новой технологии AMP. Александр Майоров

Андрей Филиппович: «Профессионал – это человек, который не умеет делать плохо свою работу. Подготовка таких специалистов для ИТ-индустрии является главной целью нашего факультета». В гостях у «Системного администратора» – Андрей Филиппович, декан факультета информатики и систем управления Московского политехнического университета, сформированного на базе МАМИ и МГУП имени Ивана Федорова.

июнь 2016 системный администратор

В номере

Рынок труда

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

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

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

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

Работодатели-мошенники атакуют в сети. С января 2016 года увеличилось число обращений граждан на горячую линию Рунета, обманутых недобросовестными работодателями в сети. Более половины жалоб относится к работодателям, предлагающим соискателям, еще до трудоустройства, приобрести что-то для выполнения работы или пройти платное обучение.

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

Лабораторная работа. Исследуем сокеты. Часть 3 (окончание). В предыдущих двух номерах был описан инструментарий для проведения исследований. В данной части предлагается самостоятельно выполнить ряд практических заданий. Владимир Закляков

Хроники ИТ

Семьдесят лет компьютерной эры. Вторая декада: 1956 – 1965. Продолжаем публикацию хроник возникновения, становления и развития информационных технологий. Владимир Гаков

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

Утилиты в ПО MathCAD для уточненного расчета электрических полей при облучении полимерных пленок электронами низких энергий. В работе рассмотрена математическая модель Роуза-Фаулера-Вайcберга, которая анализирует радиационную электропроводность полимерных пленок при облучении электронами низких энергий. Звездов Д.С., Абрамешин Д.А., Грановский В.С.

системный администратор июнь 2016

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

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

Визитка ИЛЬЯ ВИСЛОЦКИЙ, руководитель центра архитектуры клиентских решений Stack Group, info@stackgroup.ru

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

Этапы миграции в облако Рассмотрим вопросы, возникающие при миграции в виртуальную инфраструктуру, построенную на решении VMware vSphere. Прежде всего правильным будет придерживаться практики индивидуального подхода при миграции, так как нет двух одинаковых компаний с одинаковыми бизнес-процессами, при этом все же существуют общие принципы миграции. Процесс миграции сервиса – это перенос операционных систем, отвечающих за работу этого сервиса, в виртуальную среду. Всю сложную архитектуру информационных систем компании лучше разделить на выполняющие определенные задачи сервисы, и первым шагом станет определение сервисов, которые будут мигрированы. Как правило, в облако перемещается все, за исключением сервисов, не допускающих работу в виртуальной среде. Причинами этого могут быть: аппаратная несовместимость (например, RISCархитектура), вопросы лицензирования и ряд иных редких случаев. Следующим этапом будет аудит информационных систем. На этом этапе определяется состав сервисов (какие экземпляры ОС относятся к тому или иному сервису) и их сетевая связность. На основе полученных данных составляется план миграции с учетом потребностей бизнеса: формируются требования к связности физической и виртуальной инфраструктур, определяется порядок миграции сервисов, задаются допустимые «окна миграции». Очень важное предостережение: не пытайтесь во время миграции производить обновления версий программных продуктов или операционных систем. Следует сначала мигрировать и проверить работоспособность, затем обновить и опять проверить, или наоборот. Единственное, что допускается одновременно с миграцией, – это пересмотр вычислительных ресурсов (CPU, RAM, HDD). Основная сложность заключается в многообразии исходных ОС и физической архитектуры серверов, на которых они работают. Обычно для миграции используется утилита VMware converter, которая эффективно работает в большинстве случаев. Однако из-за особенностей файловых

систем, используемых Linux, после завершения работы VMware converter виртуальная машина может не запуститься примерно в 40% случаев. Если в Linux используется LVM, то правильным решением будет развертывание в виртуальной среде нового экземпляра ОС из шаблона сервис-провайдера и последующий перенос данных, внутренних служб и программных продуктов. А вот сложностей при переносе ОС семейства Microsoft Windows практически не возникает, но есть особенности миграции работающих в этих ОС служб. Стоит отметить, что для любого типа ОС есть общие причины, делающие миграцию сложной или невозможной, – это способ хранения данных, будь то динамические диски в Windows или LVM в Linux, приводящие к невозможности прямой миграции, или различные сложности, вызванные использованием программных и аппаратных массивов RAID. Дело в том, что даже точный перенос данных сам по себе не гарантирует успешный запуск виртуальной машины. Работу виртуальных машин на физическом сервере обеспечивает гипервизор – это специализированная ОС, которая устанавливается непосредственно на физический сервер и разделяет его на несколько виртуальных машин, способных работать одновременно, используя одни и те же физические ресурсы. Набор виртуального оборудования у гипервизора отличается от оборудования физического сервера, на котором раньше работала ОС. Поэтому ввиду различия драйверов возникает много отличий доступа к этому оборудованию.

Миграция ADDS и MSSQL без остановки сервисов Зачастую бизнес предъявляет повышенные требования к доступности ряда сервисов в ходе миграции. Миграция возможна даже без остановки сервиса, к тому же такой способ часто является рекомендуемым и самым надежным. К подобной ситуации можно отнести отмеченные ранее особенности миграции наиболее популярных служб ОС Microsoft, таких как Active Directory Domain Services (ADDS или чаще просто AD) и Microsoft SQL (MSSQL). Главной целью особого

июнь 2016 системный администратор

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

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

Миграция – это не так сложно, главное – взвешенно подойти к вопросу выбора сервиспровайдера

подхода к миграции в этих случаях является минимизация простоя сервиса. Для миграции Active Directory без остановки службы применяет следующий алгоритм: > Организуется сетевая связность между физическим оборудованием и облаком. Обычно это site-to-site VPN, позволяющий организовать логическую сеть поверх другой сети (например, интернет). Трафик в такой сети может быть дополнительно защищен шифрованием с использованием протоколов IPsec. > В виртуальной среде разворачивается необходимое количество новых виртуальных машин из шаблона, в которых настраиваются контроллеры домена AD с добавлением их в имеющийся лес. > База данных Active Directory реплицируется по сети через VPN с уже работающих контроллеров на стороне физического оборудования в облачные. > После завершения репликации данных переназначаются мастера ролей операций на облачные контроллеры и убираются роли контроллеров домена с физических серверов. > После проверки исправной работы сервисов отключаются учетные записи старых контроллеров и само физическое оборудование. Для миграции MSSQL с минимизацией времени остановки службы применяется более сложный алгоритм, так как MSSQL, как правило, используется в многоуровневом сервисе в качестве бэкенда. В отличие от AD, где клиенты в подавляющем числе случаев находят доступные контроллеры AD автоматически, используя DNS, в приложениях, использующих базы данных (в клиентах MSSQL), приходится указывать новое расположение базы данных вручную. Поэтому полностью исключить простой нельзя, но его можно минимизировать. Если разбираться глубже, конечно, существуют механизмы безостановочной миграции MSSQL, такие как Mirroring и AlwaysOn, но применение этих механизмов не всегда оправдано. AlwaysOn доступен только в дорогих Enterprise-редакциях, а Mirroring должен

системный администратор июнь 2016

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

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

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

виртуализация гарантийного срока (обычно три года), вам потребуется продление поддержки, что равно внушительным затратам, анализируя которые, можно легко прийти к выводу, что покупка нового оборудования в трехлетней перспективе выглядит интереснее. Таким образом, можем повторить путь покупки избыточного оборудования. Приведу немного цифр из жизни: компания «К» решила не проводить обновление ИТ-инфраструктуры и вместо этого заключила контракт с сервисной компанией «С», которая поддерживает работоспособность серверов, но при этом любая поломка исправляется за счет компании «К» «руками» компании «С». Сервисная компания тут выступает в роли внешнего инженера и администратора, следит за сохранением баз данных, резервных копий серверов и в случае выхода из строя оборудования предлагает на подмену свое (но уже за дополнительную плату) с восстановлением резервных копий, физически заменяет вышедшее из строя оборудование на новое, закупленное компанией «К». Сроки восстановления работоспособности сервиса в рассматриваемом случае, как правило, не более суток. Собственный штат в таком варианте обычно сокращается на 1-2 человек. А теперь посмотрим на цифры: поддержка стоит 50 000 руб. в месяц (не так уж и много на первый взгляд), день простоя для компании обходится в 1,2 млн руб. Имеющееся оборудование выходит из строя 2-3 раза в год, таким образом, компания теряет 2,4-3,6 млн руб. только на простое сервисов из-за устаревания ИТ-инфраструктуры, 600 000 руб. в год компания «К» платит сервисной компании за инженерную поддержку, это не учитывая скрытые затраты (например, срыв сделки с ключевым клиентом в день «простоя»). Этой суммы вполне достаточно, чтоб оплатить качественный IaaS: в рассматриваемом примере среднерыночная цена за виртуальную инфраструктуру для работы всех сервисов была бы на 22-27% меньше с учетом резервного копирования. При этом в расчетах не учтены стоимость предоставления оборудования компанией «С» на время замены вышедшего из строя оборудования, стоимость нового оборудования для замены, стоимость рисков, связанных с длительной остановкой бизнеса, и все равно наблюдаем очевидное преимущество от использования современных сервисных решений. Подведя промежуточный итог, выделим основные причины, побуждающие к переходу в облако: > эффективное финансовое планирование и преобразование ИТ-затрат из капитальных в операционные, > возможность расширения текущих ИТ-ресурсов, > сокращение непрофильного штата персонала, > бизнес-ориентация ИT-подразделения. Компания не должна создавать внутри себя сервисную ИТ-компанию, так как эффективность такого подхода возможна только на большом объеме, хотя жизнь зачастую демонстрирует обратное – чем больше корпорация, тем больше она потребляет услуг от сервисных компаний. Можно даже утверждать, что чем больше сервисных услуг потребляет компания, тем она эффективнее и успешнее.

июнь 2016 системный администратор

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

Как выбрать надежное облако Взвесив все «за» и «против», руководство компании принимает решение о переходе в облако и сразу сталкивается с новыми вопросами. Появилось 1001 определение облака. Это может быть файловое хранилище, яркими представителями которого являются DropBox, Яндекс.Диск, облако@mail.ru, Google Drive, OneDrive и др., облаком могут назвать услугу по размещению сайта (хостинг) или услугу по предоставлению виртуального сервера (VPS – virtual private server), в последнее время мы стали слышать об облачных приложениях (иначе их часто называют веб-сервисы) – самым популярным типом облачного сервиса является почта, также вы часто можете слышать о популярных пакетах облачных продуктов – Office 365 и Google Apps. Не хотелось бы сильнее запутывать, делая 1002-е определение, но все же можно выделить одну общую черту всех определений: облако – это услуга, создаваемая в удаленном от точки ее потребления месте. Чтобы пояснить глубину такого обобщающего определения, облаком будет и домашний NAS (сетевое хранилище), предоставляющий услуги хранения файлов своим домочадцам, и инфраструктура Facebook, объединяющая около 200 тысяч(!) серверов и предоставляющая сервис социальной сети. И, конечно, облако неразрывно связано с виртуализацией. Итак, выбран путь от закупок оборудования к потреблению услуг. При выборе поставщика облачных услуг

системный администратор июнь 2016

Администрирование появляется ряд вопросов. Наверняка ключевым фактором будет надежность решения. Показателем надежности многие считают значение SLA, прописанное в договоре. Но это не так. SLA – это заявленный уровень доступности сервиса, опустившись ниже которого, сервис-провайдер будет нести финансовую ответственность (которая также отражена в договоре). Тут важно понимать, что поставщик ИТ-услуг не является страховой компанией и не примет на себя риски, связанные с ухудшением качества оказания услуг. В лучшем случае, размер ответственности будет сопоставим со стоимостью потребляемых услуг. Поэтому важно убедиться, чем именно обусловлено качество сервиса. Это прежде всего сам дата-центр, в котором размещена облачная инфраструктура. Вы можете не быть экспертами в области построения дата-центров. Чтоб лично оценить его качество, достаточно посмотреть на размер дата-центра, историю за несколько лет и наличие сертификатов. Наличие сертификатов является безусловным плюсом, но опыт работы будет более показателен. Следующим кирпичиком, определяющим надежность решения, будет оборудование. Тут есть два варианта. Первый – это использование унифицированного оборудования с минимальной стоимостью (например, использование недорогих серверов компании Supermicro или Huawei). В этом варианте выполнение SLA будет определяться в большей степени программным решением и в меньшей – объемом оборудования.

Администрирование Такое решение применимо, если сервисы хорошо масштабируются горизонтально, когда выход одного физического сервера из строя не приведет к остановке сервиса. Но на сегодня большинство сервисов являются вертикально масштабируемыми и в рассматриваемой ситуации остановятся. Можно применять различные технологи, так, например, у популярной СУБД MS SQL есть такие решения повышения доступности сервиса, как Mirroring и AlwaysOn. На самом деле у большинства производителей бизнес-критичных программных продуктов есть свои проприетарные решения повышения доступности. Как правило, использование подобных функций требует одновременного запуска нескольких экземпляров ПО на разных серверах, что приводит к дополнительным затратам. Для критичных сервисов такое решение оправдано, но для сервисов, допускающих временную остановку, оно будет избыточно. Второй вариант: использование надежных промышленных решений. Такое оборудование является высоконадежным и редко выходит из строя. Производители такого оборудования широко известны – это компании Hewlett-Packard Enterprise (HPE), Dell, IBM, NetApp, EMC, Juniper, Cisco и др. Выбор данного варианта обусловлен прежде всего требованием бизнеса к непрерывности сервисов и в то же время к оптимальному потреблению ИТ-ресурсов (финансовой обоснованности). В этом варианте любой сервис имеет высокую доступность и стоит ровно столько, сколько ему необходимо для работы, а в случае выхода из строя физического сервера автоматически запускается на исправном (но это уже технологии виртуализации, о которых поговорим далее). Применяя данный подход, сервис-провайдер минимизирует затраты клиентов на единицу ИТ-ресурса и в то же время гарантирует фактический высокий SLA. Аналогичный подход должен быть применен и к сетевой инфраструктуре – высокопроизводительные промышленные решения, построенные по принципу отсутствия единой точки отказа. В этом решении выход из строя единицы сетевого оборудования не приведет к остановке сервиса. Если требуется подключение к сети Интернет, то такое подключение также резервируется. Рисунок 1. Вклад компаний, участвующих в разработке OpenStack

виртуализация Следующим критерием надежности является уровень виртуализации. Он обеспечивается различными программными решениями. На рынке широко представлены как коммерческие, так и свободно распространяемые решения с открытым кодом. Наиболее популярные Open Source-продукты – это OpenStack, CloudStack, Proxmox VE, OpenNebula и другие OpenX-проекты. Преимущества очевидны: прежде всего они бесплатны; обладают неплохим функционалом; разрабатываются международным сообществом разработчиков. Зачастую одни и те же разработчики участвуют в нескольких проектах, в том числе и в коммерческих, в чем можно убедиться, посмотрев на сайте [1] список участвующих в разработке наиболее популярного Open Source-проекта – OpenStack (см. рис.1). Минусы такого решения также очевидны. Для внедрения и обслуживания этого решения компания должна содержать не только штат специалистов по администрированию системы, но и штат программистов (или привлекать сервисную компанию), но тогда продукт перестает быть бесплатным. Для бизнеса основным минусом открытых платформ будут их низкая стабильность и отсутствие функционала, имеющегося в коммерческих продуктах. Дело в том, что все открытые платформы динамично развиваются, и сообщество просто не успевает протестировать все нововведения, да и далеко не все новые функции документированы. Безусловно, есть и стабильные «доработанные» сборки продуктов, но опять же здесь либо свой штат разработчиков, либо, что разумнее, платная поддержка от производителя такой сборки. Продукты OpenX обладают большим потенциалом, но на сегодня их трудно назвать готовыми решениями. Выбирая надежное облако, правильно было бы выбрать надежного поставщика решений и в области виртуализации, поэтому стоит рассматривать только лидеров рынка, их не много. Несмотря на то что на рынке представлены такие решения по виртуализации, как HPE Helion, Oracle VM, Citrix XenServer, лидируют только два: VMware vSphere и Microsoft Hyper-V. Безусловно, оба решения высоконадежны.

Можно убедиться, что миграция – это не так сложно, главное – взвешенно подойти к вопросу выбора сервис-провайдера. При выборе сервис-провайдера стоит оценить ЦОД, инфраструктуру, используемое решение виртуализации и, конечно, историю. Плюсами так же будут дополнительные услуги, такие как возможность защиты от DDоS-атак, возможность размещения в территориально удаленных ЦОДах, индивидуальное обслуживание и другие важные для вас дополнения, как, например, физическое размещение информационных ресурсов на территории РФ для выполнения законодательства. Надеюсь, многие, увидев свою ситуацию в этой статье, с твердой уверенностью откроют «окна миграции» и устремятся в облака! EOF [1] Cписок компаний, участвующих в разработке OpenStack – http://stackalytics.com. Ключевые слова: миграция, виртуализация, облачные технологии.

июнь 2016 системный администратор

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

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

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

Системы хранения данных Часть 3. SAN В статье дается общее представление о работе сетей хранения данных и особенностях взаимодействия с серверным оборудованием и другими сетями

Вместо предисловия. Недостатки стандартных решений DAS и NAS В предыдущих статьях [1] и [2] читатели познакомились с весьма популярными ранее решениями по созданию систем хранения данных – DAS и NAS. Для лучшего понимания стоит напомнить, что DAS (Direct Access Storage), в дословном переводе означающее «хранилище с прямым доступом», является самым старым и заслуженным подвидом систем хранения данных. Любой сервер имеет в своем составе дисковую подсистему, доступ к которой осуществляется напрямую без посредников в виде какой-либо сети. Можно с уверенностью утверждать, что любой сервер содержит DAS. В итоге получается, что DAS может служить своего рода кирпичиком для построения более сложных систем. В последнее время ради удобства и большей масштабируемости стали разделять головной серверный модуль и подключаемое дисковое хранилище. Основным связующим звеном между этими компонентами является RAIDконтроллер, или дисковый адаптер (HBA), позволяющий связать дисковую «полку» с сервером. Однако системы Direct Access Storage не лишены ряда недостатков. Среди них: > Плохая масштабируемость. Любая такая система даже с разделяемыми дисковыми полками при наращивании объема очень скоро упирается в некий предел, заложенный конструктивными особенностями. В первую очередь это ограничение на количество подключаемых дисков к одному контроллеру, неспособность HBA или RAIDконтроллера работать с дисками большого объема, а также ограничение на количество подключаемых внешних хранилищ (дисковых «полок»). > Немалую роль также играет быстродействие всей компьютерной системы – при нехватке мощности процессора или оперативной памяти работа всей системы может замедлиться до критического уровня. > Недостаточная гибкость в распределении ресурсов. Какой бы объемной и мощной ни была дисковая подсистема, обычно она доступна для работы только одному

системный администратор июнь 2016

выделенному серверу. Поэтому если на одном сервере ощущается дефицит дискового пространства, а на другом присутствует в избытке, то с этим в данном случае нельзя ничего поделать. Примечание. Для агрегации дискового пространства на различных узлах сети можно использовать специальные распределенные файловые системы, например GPFS [3], но эти механизмы, по сути, являются сложными сетевыми структурами, работающими на нескольких уровнях, в отличие от рассматриваемых здесь стандартных СХД. Чтобы избежать подобных неудобств, были придуманы сетевые системы хранения данных – NAS (Network Attached Storage), которые позволяют работать с дисковыми хранилищами прямо из локальной сети. По сути, такая система упраздняет связку сервер + дисковая полка и позволяет получать доступ к данным по сетевым протоколам, при этом возможен доступ к одному и тому же дисковому тому со стороны нескольких клиентов (серверов и рабочих станций). Однако устройства NAS имеют ряд серьезных недостатков. > В первую очередь это относительно невысокая скорость при использовании стандартных сетевых протоколов и высокие накладные расходы. Для превращения блока данных, созданного прикладной программой, в набор Ethernet-кадров, пригодных к трансляции по локальной сети, приходится провести большое число преобразований. Эта процедура замедляет обмен информацией и требует достаточно большого количества системных ресурсов. > Еще одним недостатком Network Attached Storage является тот факт, что это именно сетевое устройство, предоставляющее файловый доступ. И даже смонтировав такой ресурс, как сетевой диск или папка в файловой системе, вы все равно не можете отформатировать устройство, выполнить дефрагментацию файловой системы, записать ее образ в виде файла и так далее. > В свою очередь, работа с дисками и другими устройствами DAS ведется методом блочного доступа, когда операционная система получает полный доступ

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

NAS (Network Attached Storage) позволяет работать с дисковыми хранилищами прямо из локальной сети Примечание. Прекрасным примером такого неприятного сюрприза со стороны производителей ПО может служить Microsoft Data Protector Manager [4], работающий только с устройствами блочного типа. Почему Microsoft в этот раз решилась предать забвению свое любимое детище – CIFS [5] протокол – и что побудило принять такое искусственное ограничение, пока остается неясным. Все это было бы смешно, если бы не было так грустно, ведь большинство систем резервного хранения использует либо файловый доступ (сетевые ресурсы), либо последовательный доступ (магнитные ленты). При этом стоит отметить, что программа ntbackup, используемая вплоть до Windows 2003 R2 SP2, прекрасно работает со всеми типами систем хранения. Решение отказаться от других методов доступа, кроме блочного, явилось очередной «головной болью» для сисадминов и администраторов резервного копирования, которые в итоге снова были вынуждены в срочном порядке искать замену продуктам Microsoft. Чтобы преодолеть все вышеуказанные ограничения, возникла необходимость создать устройства, которые, с одной стороны, подключались бы к некой сети передачи данных и позволяли более рачительно использовать дисковые ресурсы, с другой – дали возможность осуществить доступ блочным методом. Таким образом, мы подошли к идее создания сети хранения данных – SAN.

Что такое SAN Storage Area Network (SAN) – в переводе на русский «сеть хранения данных» – это высокопроизводительная сеть, связывающая серверные компоненты и хранилища данных. SAN – самодостаточная система передачи данных, не зависящая от локальной сети. Как уже говорилось выше, основная цель создания SAN – устранение недостатков NAS DAS. В первую очередь это утилизация и совместное использование свободного дискового пространства. Если перенести данные с отдельно стоящих серверов на специально созданные дисковые хранилища, можно не только более рачительно распорядиться объемами накопителей, но и значительно облегчить задачу модернизации системы хранения,

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

Компоненты и терминология SAN Итак, мы определились, что SAN состоит из клиентской части (серверов), сервисной части (хранилища) и собственно средств для связи этих узлов между собой. Соответственно, серверные, или клиентские, компоненты носят название «инициаторов» – initiators. Средства хранения (дисковые массивы), или «хранилища», – targets (английское слово target в дословном переводе означает «цель»). Примечание. Данные термины пришли из обозначения взаимодействия устройств посредством шины и протокола SCSI. Мы еще вернемся к роли наследия SCSI в дальнейшем, когда будем рассматривать протоколы взаимодействия. Что же касается собственно сетевых терминов SAN, то такие обозначения, как коммутатор, маршрутизатор, соединительный кабель (патчкорд), несут практически ту же смысловую нагрузку, что и при описании работы обычных локальных сетей. > Host Block Adapters (HBA) – для подключения клиентских устройств и хранилищ к SAN используются различные адаптеры, позволяющие обмениваться данными по специальным SAN-протоколам между собой и сетевым оборудованием. > Коммутаторы (и маршрутизаторы в сложных и распределенных системах) – для подключения нескольких серверов к одному хранилищу или, наоборот, одного сервера к нескольким хранилищам зачастую не обойтись без специальных устройств, позволяющих организовать такие множественные соединения. Ранее использовались еще и устройства типа HUB (повторители), но из-за ряда ограничений этот тип оборудования практически не применяется. > Кабели. В принципе SAN имеют определенное сходство с LAN. Если абстрагироваться от деталей, то общие принципы передачи данных будут одни и те же. Постепенный «спуск» посредством инкапсуляции от прикладного уровня к уровню канальной передачи, переключение портов, использование определенных механизмов контроля целостности передачи данных – все это так или иначе работает по одним и тем же правилам. Zoning (зонирование) – дословно означает разбиение на зоны взаимодействия (zones). Этот механизм очень похож на VLAN для локальных сетей. Цель данного мероприятия – ограничить количество портов устройств, взаимодействующих друг с другом, от доступа со стороны других. Но обычно данный механизм применяется в сетях Fibre Channel (о них речь пойдет ниже), хотя зонирование также применяется в SAS-коммутаторах. При построение SAN на базе протокола iSCSI применяются стандартные VLAN для локальных сетей, что тоже фактически является зонированием. Примечание. Часто создается впечатление, что сети хранения данных используются только для обслуживания дисковых систем хранения. На самом деле это не так. К SAN

июнь 2016 системный администратор

хранение данных могут быть подключены другие устройства, например ленточные библиотеки. Еще один вариант использования – построение сети передачи данных. Забегая вперед, можно упомянуть специальный протокол IP over FC (IPFC), позволяющий строить локальную сеть передачи данных (LAN) на оборудовании Fibre Channel.

Расширенный вариант многоступенчатой системы хранения В статье, посвященной DAS, был рассмотрен момент разделения обычной системы хранения на серверную часть и дисковую «полку». В случае с сетью SAN данный вариант значительно развивается и усиливается. При использовании DAS все процедуры обслуживания, включая сохранение целостности данных, выявление ошибок, мониторинг состояния системы и управление, полностью возложены на сервер, подключенный к дисковой системе. В работе SAN головной модуль системы хранения – Controller Enclosure – решает большую часть вышеупомянутых задач, при этом серверы-клиенты освобождаются от подобной рутины. При этом при выходе головного модуля из строя его можно заменить, не затрагивая Disk Enclosure (дисковую «полку»). Разумеется, понадобятся определенные усилия по настройке замененного устройства, но это не так сложно по сравнению с полной переустановкой сервера, включая восстановление всей информации из резервной копии.

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

системный администратор июнь 2016

Администрирование необходимость. Именно поэтому на сегодняшний момент топология типа «кольцо» признана далеко не самым удачным решением и применяется достаточно редко. В основном такую топологию можно встретить в устаревших системах. Централизация ресурсов накладывает дополнительные требования к резервированию и запасу оборудования на складе. В идеале необходимо иметь возможность в самые кратчайшие сроки заменить любой SAN-коммутатор, основные комплектующие системы хранения: вентиляторы, блоки питания, автономную кэш-память и многое другое. И, разумеется, всегда под рукой должно быть необходимое количество жестких дисков, хотя бы по одному на каждый массив. Иначе внезапный сбой системы заставит дорого заплатить за беспечность в вопросах резервирования и закупки запчастей.

Стандартные схемы SAN-подключений В зависимости от требований надежности, а также от размеров (и бюджета) проектируемой сети хранения данных различают несколько стандартных типов подключения.

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

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

Администрирование при построении недорогих виртуальных структур из нескольких хост-серверов с общим хранилищем.

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

хранение данных с традиционными решениями для сетей LAN (семейство Ethernet). Fibre Channel Protocol (FCP) – это протокол передачи данных (можно сравнить с TCP в IP-сетях), использующий модель SCSI в сетях Fibre Channel. В настоящее время это один из основных проколов для построения сетей хранения данных на основе FC. Примечание. В связи с большим объемом информации, требуемым для описания работы Fibre Channel и других стандартов и протоколов, более подробный рассказ об этом будет продолжен в следующих статьях этого цикла. А сейчас мы просто ограничимся кратким описанием.

FC на базе IP или Ethernet Подключение серверов через дублирующие коммутаторы к зеркальным хранилищам Это полностью отказоустойчивая схема с отсутствующими едиными точками отказа, максимально надежная, при этом максимально дорогая.

Используемые протоколы SAN Fibre Channel Fibre Channel (FC) – в дословном переводе с английского означает «волоконный канал» [6]. В основе технологии лежит стек протоколов, применяемых для передачи данных с более высокой скоростью. В отличие от TCP/IP данный набор протоколов изначально разрабатывался для сетей хранения данных. Разработка ведется под контролем комитета T11, который, в свою очередь, является частью Международного комитета по стандартам в сфере ИТ (InterNational Committee for Information Technology Standards – INCITS). Первоначально семейство Fibre Channel применялось исключительно в суперкомпьютерах, затем перешло в сети хранения данных, там FC применяется как стандартная возможность подключения к системам хранения данных. Получил широкое корпоративное использование. Как уже понятно из названия, первоначально основу для построения SAN на базе FC составляло оборудование для передачи данных посредством оптоволоконных соединений. Это позволяло добиться более высокой скорости при меньших накладных расходах по сравнению Рисунок 3. Вариант с подключением двух серверов к двум SAN-коммутаторам и одному хранилищу

В связи с высокой ценой на оборудование Fibre Channel были разработаны соответствующие стандарты и сетевые протоколы для организации сетей на основе FC посредством более дешевого оборудования, например коммутаторов и маршрутизаторов семейства Ethernet. Существует несколько направлений подобной эмуляции: IFCP [7] являет собой очередной стандарт для расширения сетей хранения данных Fibre Channel через интернет. Это сетевой протокол gateway-to-gateway. Официально ратифицирован Engineering Task Force Internet. Протокол IFCP обеспечивает возможность передачи данных от устройств хранения данных Fibre Channel в локальной сети хранения данных (SAN) или в сети Интернет с использованием протокола TCP/IP. TCP обеспечивает контроль, а также обнаружение ошибок и восстановление данных. IFCP позволяет переправить данные, обычно передаваемые с помощью SCSI и Fibre Channel, в IP-сеть. IFCP способен либо полностью их заменить или использовать в сочетании с другими протоколами Fibre Channel, такими как FCIP (Fibre Channel поверх IP). FCIP [8] (Fibre Channel over IP (FCIP или FC/IP) представляет собой IP-протокол, созданный организацией Engineering Task Force (IETF) для сетей SAN. Функцией FCIP является инкапсуляция кадров Fibre Channel и пересылка посредством IP-сети. Технология FCIP позволяет преодолеть ограничение расстояния традиционных решений на базе Fibre Channel, что дает возможность создавать географически Рисунок 4. Полное дублирование SAN-коммутаторов и хранилищ

июнь 2016 системный администратор

хранение данных распределенные сети хранения данных, подключаемые с помощью существующей IP-инфраструктуры. При этом данный функционал работает прозрачно для уровня Fibre Channel, и устройства FC даже не «подозревают» о наличии в сети уровня IP. FCoE [9] (Fibre Channel over Ethernet) представляет собой протокол, выполняющий роль транспорта для передачи фреймов Fibre Channel посредством Ethernet-каналов. Основой такого преобразования является инкапсуляция кадров Fibre Channel в jumbo frames Ethernet. Данный протокол был определен в качестве стандарта комитетом T11. (Комитет Е11 входит в состав International Committee for Information Technology Standards – INCITS, – в чьем ведении находится Fibre Channel.) Применение FCoE снижает стоимость инфраструктуры дата-центров благодаря унификации оборудования (вместо Etnerhet и Fibre Channel используется только Ethernet). В то же время существует iSCSI.

iSCSI Стандарт iSCSI [10] (включая соответствующий протокол) используется для работы в сетях хранения данных. Применение iSCSI дает возможность организовать доступ к блочным устройствам по протоколу SCSI, используя TCP/IP. Таким образом, можно создать относительно недорогую сеть хранения данных (SAN) с помощью обычных Ethernet-сетей. Основное отличие iSCSI от других стандартов, описанных выше, заключается в том, что он является полностью законченным независимым решением. Для его реализации не требуется протокол Fibre Cahnnel (или реализация определенных уровней). Все просто и ясно: данные транслируются от жестких дисков через поддержку SCSI и далее через сетевой стек вплоть до инкапсуляции в IP-пакеты и далее в кадры Ethernet. Из-за своей «самостоятельности», а также из-за простоты и доступности решения данный стандарт снискал себе массу поклонников. На сегодняшний день модули для поддержки iSCSI-initiators встроены практически во все известные операционные системы, а программное обеспечение для создания iSCSI-target существует для множества платформ.

InfiniBand InfiniBand (используется сокращение до IB) – стандарт для построения скоростных коммутируемых сетей [11]. По сути, это протокол и оборудование для работы на втором (канальном) уровне OSI ISO. Ближайший аналог – семейство протоколов и стандартов Ethernet. Однако решения на базе InfiniBand имеют более высокую пропускную способность и низкую задержку. Данный стандарт продвигается InfiniBand Trade Association (объединение Future I/O (IBM) и Next Generation I/O (Intel). Но, в отличие от Ethernet, InfiniBand куда менее известен и применяется значительно реже. В первую очередь в такую малой распространенности стоит винить высокую стоимость оборудования и всего решения в целом. Основной областью применения InfiniBand остаются вычислительные кластеры, высокопроизводительные системы виртуализации и другие отрасли, где финансовые вопросы отходят на второй план по сравнению с требованием высокого быстродействия и малых задержек.

системный администратор июнь 2016

Администрирование SAS-коммутация SAS-коммутаторы как внешние расширители первоначально рассматривались исключительно как интерфейс для прямого (DAS) подключения одного-двух серверов к дисковой полке. Со временем росла потребность в количестве портов SAS как на СХД, так и на серверах, и это привело к необходимости создания подобных устройств. Но со временем производители систем хранения на базе SAS задумались о применении такого рода коммутаторов и для организации систем хранения более высокого уровня, чем DAS, – сетей хранения данных, что позволило бы иметь возможность совместного использования дисковых ресурсов несколькими серверами, а также применения зонирования (деления на зоны) только средствами шины SAS, без применения дополнительного оборудования (Fibre Channel и так далее). SAS-коммутатор в этом случае позволяет получить максимальной выгоды от использования недорогих систем. Появление стандарта SAS-2 позволило внести некоторые улучшения в реализацию мультиплексирования соединений SAS, повысив надежность работы коммутаторов. А выход стандарта SAS-3.0 ознаменовал собой повышение скорости передачи данных до 12 Гбит/с, что уже сопоставимо с реализацией Fibre Channel. Таким образом, данная технология для небольших систем хранения в принципе готова заменить традиционные стандарты Fibre Channel и iSCSI.

К сожалению, невозможно объять необъятное и в рамках одной статьи осветить такие объемные вопросы. В следующих публикациях мы поближе познакомимся с особенностями работы перечисленных решений SAN, с их достоинствами и недостатками. EOF [1] Бережной А. Системы хранения данных. Часть 1. DAS. // «Системный администратор», №4, 2016 г. – С. 4-7 (http://samag.ru/ archive/article/3163). [2] Бережной. А. Системы хранения данных. Часть 2. NAS. // «Системный администратор», №5, 2016 г. – С. 4-8 (http://samag.ru/ archive/article/3185). [3] General Parallel File System. Раздел в IBM Knowledge Center – http://www.ibm.com/support/knowledgecenter/SSFKCN/ gpfs_welcome.html. [4] Data Protection Manager (DPM). Статья на Microsoft Tech Net – https://technet.microsoft.com/ru-ru/library/hh758173%28v= sc.12%29.aspx. [5] Common Internet File System (CIFS). Статья на Microsoft Tech Net –https://technet.microsoft.com/ru-ru/library/cc939973.aspx. [6] Официальный сайт Fibre Channel Industry Accociation – http:// fibrechannel.org. [7] Документ RFC 4172. iFCP – A Protocol for Internet Fibre Channel Storage Networking – https://tools.ietf.org/html/rfc4172. [8] Документ RFC 3821. Fibre Channel Over TCP/IP (FCIP) – https:// tools.ietf.org/html/rfc3821. [9] Сайт, посвященный протоколу FCoE – http://www.fcoe.com. [10] Документ RFC 3720 Internet Small Computer Systems Interface (iSCSI) – https://tools.ietf.org/html/rfc3720. [11] Сайт InfiniBand Trade Association – http://www.infinibandta.org. Ключевые слова: устройства хранения, SAN.

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

автоматизация

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

Service Discovery для распределенных систем Как отследить расположение сервисов и их доступность в динамической сети? Выход – системы обнаружения сервисов

Времена простых статичных конфигураций подходят к концу. Сегодня в тренде облачные сервисы, виртуализация, микроархитектура, распределенные системы. Все это по мере запуска новых систем становится все сложнее и сложнее. В итоге остро стоит вопрос о возможностях динамической конфигурации систем и обнаружении сервисов «на лету». Серверы могут перемещаться между ЦОД, меняя IP, контейнеры включаются и отключаются, сервисы стартуют и пропадают, один и тот же порт могут использовать разные приложения. Все эти изменения необходимо отслеживать как можно раньше, но традиционные инструменты мало подходят для решения этих задач. Можно эту задачу автоматизировать с помощью скриптов, отслеживая свой и чужой IP, настроить службу DNS, использовать прокси и т.д. При небольшом количестве и в более-менее статичной среде это работает, но по мере увеличения систем управлять всем этим становится сложнее. Будут возникать задержки в случае неработы службы и необходимости быстрого подключения к другому серверу. Проблема нашла решение в специальном классе приложений – системы обнаружения сервисов (Service Discovery).

Задача Service Discovery Системы обнаружения сервисов представляют собой базу данных, содержащих актуальную информацию о расположении и состоянии экземпляров службы, позволяющую, таким образом, автоматизировать процесс получения ответа на вопрос, на каком IP запущен нужный сервис, анонсировать в сети новый ресурс или быстро изменить настройки в случае неответа определенного приложения. Работает такая схема очень просто. Вся процедура состоит из двух фаз: регистрация сервиса (Service Registration) и обнаружение сервиса (Service Discovery). Запустившись, сервер, контейнер или виртуальная машина с помощью настроенного агента отсылают информацию в центральный реестр о том, какие сервисы обеспечивает. Опционально могут быть указаны порт, протоколы, версии, данные для аутентификации, параметры окружения, вспомогательные теги и в принципе любая другая информация.

Теперь любой клиент может обратиться к хранилищу с запросом, используя API или традиционные службы вроде DNS, и получить нужную информацию. То есть, грубо говоря, Service Discovery – это аналог DNS для распределенных сетей с часто меняющейся конфигурацией. Кроме хранения данных, центральный сервер обычно отслеживает состояние сервисов и отмечает те, которые не отвечают на запросы. Если сервис сообщает, что он отключается, он автоматически удаляется из каталога. Еще одна полезная функция – балансировка нагрузки между одинаковыми сервисами за счет выдачи разным клиентам разных IP. Также такие сервисы используются для хранения конфигураций с возможностью отслеживания изменений значения параметра. К слову, в Windows Server 2016 в Microsoft, в котором возможно использование контейнеров, для обнаружения служб не будет каких-либо встроенных инструментов, поэтому придется использовать сторонние разработки.

Service Discovery и Open Source Сегодня доступно несколько Open Source-проектов, реализующих хранение информации об инфраструктуре, но в чистом виде Service Discovery нигде не встречается и соседствует с функциями конфигурирования систем. Здесь есть как и относительно сложные решения, использующие Key/Value-хранилище, гарантирующие доступность (ZooKeeper, Consul, Etcd, OpenReplica), обеспечивающие множество дополнительных функций и работу в распределенных системах и разных ЦОД, так и, в общем-то, простые (SmartStack, Eureka, NSQ, Serf), имеющие только базовые функции, несложные в развертывании и подходящие для небольших сетей. И это далеко не весь список. И хотя здесь между ними поставлен знак равенства, на самом деле это совершенно разные проекты, между которыми не так уже и много общего. В зависимости от конкретной реализации проблемы Service Discovery решаются по-разному, например, задача обнаружения на стороне сервера или клиента, также у них различные алгоритмы работы с клиентами.

июнь 2016 системный администратор

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

автоматизация Ниже приводится более подробное описание перечисленных систем.

они развиваются не активно. Надстройка SkyDNS2 позволяет для доступа использовать DNS-запросы.

ZooKeeper

Doozer

ZooKeeper [1] позиционируется как распределенный сервис конфигурирования и синхронизации. Представляет собой распределенное Key/Value-хранилище с иерархической древовидной системой и двунаправленной связью между сервером и клиентом. Узлы виртуальной файловой системы совмещают файлы и директории. Каждый узел этого дерева может одновременно хранить данные и иметь подчиненные узлы. Значения могут содержаться в любом узле иерархии. Кроме обычных (persistent) узлов, которые сохраняются на диске, могут создаваться так называемые эфемерные узлы (ephemeral nodes), которые существуют, пока подключен клиент. Запись может выполнять только лидер, чтение можно производить с любого сервера. Все операции строго последовательны. Чтобы запись была успешной, ее должны подтвердить два узла. Функция Service Discovery лишь одна из его возможностей. Но дизайн, ориентированный на конфигурирование, делает эту функцию не очень надежной, т.к. клиенты узлов, являющихся частью раздела, который не может достигнуть кворума, могут потерять связь с ZooKeeper. Все данные хранятся в оперативной памяти. Это зрелый проект с большим сообществом, подходящий для больших сетей, но он относительно сложен в понимании и настройках, требует некоторого времени на понимание всех его особенностей. Написан на Java, поэтому требователен к ресурсам.

Doozer [4] можно назвать упрощенной версией ZooKeeper, он может использоваться для обнаружения служб, хранения конфигурации и другой нечасто меняющейся информации. Функция обнаружения служб аналогична ZooKeeper, то есть перечисляются все записи и отслеживаются изменения, но отсутствуют понятия эфемерных узлов. Если служба не отвечает, запись не удаляется, но есть возможность обойти эту проблему использованием меток времени и heartbeat, устаревшие записи игнорируются или удаляются. При изменении данных подключенные клиенты уведомляются. Минус – проект три года не развивается.

ОреnReplica OpenReplica [2] похож на ZooKeeper, но представляет собой объектно-ориентированный интерфейс для приложений. Вы определяете объект Python, инкапсулирущий необходимое состояние и методы, позволяющие его обновить и синхронизировать. Затем он отправляется на сервер OpenReplica, и мы получаем прокси, к которому могут обращаться остальные клиенты с любого узла в сети. Для приложений он по-прежнему выглядит, как объект Python, что упрощает к нему доступ. Для доступа к данным используются API и DNS. OpenReplica содержит свой DNS-сервер, также можно использовать субдомен openreplica.org.

Consul А вот Consul [5] ориентирован в первую очередь на обнаружение сервисов, функция Key/Value-хранилища – лишь удобное дополнение. Для настройки используются файлы в формате JSON, где прописываются параметры сервисов, отправляемые на центральный узел, или же анонс можно произвести с помощью API. К API можно обращаться с помощью агента или утилит, работающих с HTTP (например, curl). Также у Consul заложена функция мониторинга состояния и снятия метрик, есть возможность задавать свои проверки. Кроме API, возможно получение информации о сервисе посредством DNS, то есть запрос к Consul могут отправлять любые приложения, не используя специальный клиент. Управление возможно через веб-интерфейс. Работает под многими ОС: Windows, Mac OS X, FreeBSD, Solaris и Linux. В облаке устойчивость ко всяким сбоям одна из первоочередных задач, поэтому служба Service Discovery должна обладать высокой степенью готовности. Клиенты могут кэшировать некоторую информацию, но она в конечном итоге устаревает, что делает невозможным обнаружение экземпляров служб. Для обеспечения отказоустойчивости Service Discovery используется обычно три, пять или семь серверов, Рисунок 1. Получение информации о зарегистрированном сервисе

Etcd Etcd [3] позволяет организовать единое Key/Value-хранилище конфигурации, которое реплицируется на другие узлы и поддерживается в синхронизированном состоянии. В etcd могут сохраняться временные данные, для которых предусмотрена возможность определения времени жизни записи. Для этого используется TTL ключа вместе с отслеживанием доступности службы. Блокировка записей обеспечивается за счет надстройки etcd-lock. Доступ к конфигурации возможен через HTTP+JSON интерфейс с помощью любого HTTP-клиента (вроде сurl или wget) или специальной утилиты etcdctl. Использование HTTP позволяет применять «не закрывающиеся» соединения (long-polling), когда сервер, получив запрос, отвечает при наступлении события. Сторонними разработчиками написаны FUSE-модуль etcdfs, позволяющий получить доступ к хранилищу в виде файловой системы, и веб-интерфейс etcd-browser, дающий возможность наглядного управления базой данных. Правда,

системный администратор июнь 2016

Администрирование консенсус достигается использованием алгоритма Paxos (Zookeeper (упрощенная версия Paxos – ZooKeeper Atomic Broadcast), Doozer, OpenReplica) или Raft (Ectd, Consul) (алгоритмы требуют, чтобы узлов было 2N+1). Хотя, конечно, в простейших ситуациях возможно хранение данных на единственном сервере.

Описание работы Service Discovery на примере Consul Разберем, как работает Service Discovery на примере Consul. Построен Consul по клиент-серверной схеме, всем управляет агент, который устанавливается на все узлы и может работать в двух режимах – клиентском или серверном. Исполняемый файл один для всех. Чтобы запустить в режиме сервера, достаточно добавить параметр -server. Клиент собирает информацию об узле и отправляет серверу. Использована децентрализованная архитектура, приложения не обязаны знать расположение других узлов. Приложения обращаются к агенту через localhost, это удобно, ведь знать адрес сервера не нужно, все дальнейшие заботы лежат на Consul. Далее агент, получив запрос, обращается к любому узлу, который пересылает его к доступному серверу, если он не отвечает, то запрос пересылается следующему. Серверы образуют кластер и самостоятельно выбирают лидера, отвечающего за координацию. $ sudo consul agent -server -bootstrap-expect 5 ↵ -data-dir /var/consul -config-dir /etc/consul.d

Параметры, в общем, понятны. В bootstrap-expect указывается, сколько будет серверов, это требуется для установления кворума. Можно самому назначить лидера, использовав при его запуске параметр bootstrap. Описания сервиса, который реализует узел с установленным агентом, а также параметры работы агента, проверки и прочее можно задавать в конфигурационном файле или отправив определенный API-запрос. Файлы в формате JSON располагают в каталоге /etc/ consul.d, они удобнее, например, при клонировании виртуальных машин или контейнеров. Достаточно один раз прописать, и все будет работать. В простейшем случае указываются имя,

автоматизация порт и теги, можно добавить адрес (Consul может анонсировать не локальный сервис, например, Google), дата-центр, скрипт для проверки и прочую информацию. $ nano /etc/consul.d/web.json { "service": { "name": "web", "tags": ["apache"], "port": 80} }

Далее просто запускаем агента в режиме клиента, указав на каталог: $ sudo consul agent -config-dir /etc/consul.d

или используя API: $ curl -X PUT -d -d '{"Datacenter":"dc1","ID":"redis1", ↵ "Name":"redis","Port":8000}' ↵ http://127.0.0.1:8500/v1/catalog/register

Все обращения, как мы видим, происходят к localhost, это удобно, ведь знать адрес сервера не нужно, все дальнейшие заботы лежат на Consul. Теперь получим информацию о сервисе, используя API. Все доступные сервисы: $ curl http://127.0.0.1:8500/v1/catalog/services

Или смотрим конкретный сервис redis: $ curl http://127.0.0.1:8500/v1/catalog/service/redis

С помощью DNS можем получить запрос всех узлов, предоставляющих сервис web (см. рис.1, 2). $ dig @127.0.0.1 -p 8600 web.service.consul

Добавим тег: $ dig @127.0.0.1 -p 8600 apache.web.service.consul

При необходимости можем уточнить тип записи:

Рисунок 2. Просмотр сервисов через веб-интерфейс Consul

$ dig @127.0.0.1

+short redis.service.consul A

Системы обнаружения сервисов являются незаменимыми дополнениями в современной динамически изменяющейся среде. Выбор конкретного варианта зависит от решаемых задач, планируемой нагрузки и используемого языка. EOF [1] [2] [3] [4] [5]

Сайт проекта ZooKeeper – http://zookeeper.apache.org. Сайт проекта OpenReplica – http://openreplica.org. Страница Ectd на GitHub – https://github.com/coreos/etcd. Страница Doozer на GitHub – https://github.com/ha/doozer. Сайт проекта Consul – http://consul.io.

Ключевые слова: облачные сервисы, обнаружение сервисов, Service Discovery.

июнь 2016 системный администратор

событие

Безопасность

Positive Hack Days VI CityF Противостояние глазами Защитника 17-18 мая в Москве прошла VI ежегодная конференция PHDays, посвященная практическим аспектам информационной безопасности. Кроме конференции, разделенной на бизнес- и технический потоки, мастер-классов и конкурсов, организаторы сделали акцент на соревновании, похожем на Capture The Flag (CTF), но гораздо более масштабном Подготовил Андрей Дугин

События происходили в «виртуальном городе». Для участников состязания было подготовлено пять инфраструктурных объектов, которые нужно было одним – взломать, другим – защитить: > Банк 1 > Городской офис > Банк 2 > Электроэнергетическая компания > Телекоммуникационный оператор Сторон Противостояния было три: > Хакеры – участники соревнования, задачей которых было получение несанкционированного доступа к атакуемым объектам, выполнение злонамеренных действий,

системный администратор июнь 2016

компрометирующих защищаемую инфраструктуру и наносящих урон «виртуальному бизнесу»: отключение электростанции, снятие денег со счета и т.п. > Защитники – специалисты, чья задача была диаметрально противоположной: организация защиты вверенной инфраструктуры техническими средствами. > Security Operations Center (SOC) – экспертные центры безопасности, выполняющие оперативный мониторинг и устранение инцидентов безопасности. Поскольку автор статьи участвовал в составе команды Защитников телекоммуникационного сектора, ракурс обзора будет соответствующий.

Безопасность На каждый инфраструктурный объект для его защиты и оперативного реагирования назначалась пара Защитник + SOC. С нашей сборной командой телеком-защитников «You Shall Not Pass» из крупных операторов связи в тандеме работал Solar JSOC, команда «False Positive». За две недели до начала соревнований Защитникам и SOC был предоставлен удаленный доступ в свой сегмент инфраструктуры для его инвентаризации, установки и предварительной настройки средств защиты, а также интеграции защищаемых ресурсов с SIEM-системами.

Шоу с взломом ГЭС и затоплением города, переданное затем по новостным каналам, было эффектным Вычислительная инфраструктура, предоставленная для сражения, была полностью виртуализирована, поэтому средства обеспечения информационной безопасности также требовалось разворачивать в виде виртуальных машин. Аппаратные решения разрешались только переносные, не требующие установки в серверную стойку. На этом ограничения к самим средствам защиты заканчивались. Разрешалось использовать решение любого производителя, платное или бесплатное, на усмотрение команд. В случае необходимости организаторы оказывали содействие в получении временных лицензий на коммерческие средства обеспечения информационной безопасности. 17-18 мая на площадке команды обороняющего тандема и хакеров поместили в разные концы одного большого зала. Защитникам и SOC предоставили по одному столу на шесть человек каждой команде с возможностью подключения к сети электропитания и Ethernet в защищаемую инфраструктуру.

событие У атакующей и защищающей сторон были определенные ограничения в перечне действий. Ограничения для хакеров: > Доступ из интернета в сегмент напрямую невозможен, только локально либо через VPN. Цель очевидна: защита инфраструктуры «виртуального города» от DDoS, уверенность в том, что атаки проводят именно участники соревнований. > Запрещены DDoS на инфраструктуры участников и генерация паразитного трафика большого объема. DoS/ DDoS-атаки уровня приложения разрешены. > Запрещены атаки на элементы инфраструктуры, образующей «виртуальный город» (обеспечивающие работу сегментов участников и управляемые организаторами), рабочие места жюри и технической поддержки соревнований. Ограничения для Защитников и SOC: > Запрещена блокировка по IP-адресу атакующего. В целях определения подобных действий все атакующие, клиенты и система проверки доступности сервисов транслировались в один IP-адрес. > Запрещено закрывать доступ к серверам из DMZ со стороны интернета, в том числе и по управляющим протоколам (SSH, Telnet, RDP, SNMP) и базам данных (MySQL, Oracle). Разрешено применить списки доступа только на интерфейсы управления сетевым оборудованием. > Отсутствие доступа к интерфейсам управления сетевым оборудованием уровня L2-access. > Запрещена реконфигурация сетевого оборудования, если она вызывает потерю сервиса. > Кроме перечисленных команд, существовали группы статистов, эмулирующих работу пользователей корпоративной сети организации. Запрещалось входить с ними в контакт и инструктировать.

Началось Противостояние в 11:00 17 мая, закончилось в 16:00 18 мая. Запреты для Защитников и SOC, несмотря на заверения о «максимальном Сборная команда телеком-защитников «You Shall Not Pass» из крупных операторов связи и Solar JSOC, команда приближении к реальности» на офи«False Positive» циальном сайте конференции [1], делали уровень защиты сети намного ниже, чем принято в телекоме. Но организаторам необходимо было привлечь внимание общества, бизнеса и государства к необходимости защиты «Интернета вещей» и других подключаемых к публичным сетям систем управления критической инфраструктурой, а также соблюдения мер информационной безопасности при работе с банковскими сервисами. Для этого соревнования должны содержать элементы шоу с резонансными взломами [2], привлекающие внимание общественности к проблемам информационной безопасности современных систем. Поэтому

июнь 2016 системный администратор

событие в некоторых случаях понижение уровня безопасности защищаемых систем было беспрецедентным. Но стоит отдать должное – шоу с взломом ГЭС и затоплением города [3], переданное затем по новостным каналам, было эффектным. Краткий перечень мер, предпринятых командами Защитников и SOC для обеспечения безопасности защищаемых элементов: > Постоянная инвентаризация инфраструктуры. > Периодическое сканирование на наличие уязвимостей серверов и сетевого оборудования. > Устранение уязвимостей. > Мониторинг всех действий и запускаемых процессов на серверах и сетевом оборудовании. > Мониторинг событий с активного сетевого оборудования и анализ трафика NetFlow. > Использование in-line IPS. Кроме описанного выше краткого перечня мер, пришлось применить одно довольно нестандартное решение. Для того чтобы хакеры после неудавшихся попыток взлома не теряли интерес к атакуемому сегменту, организаторы периодически без предупреждения защищающих включали новые серверы, содержащие уязвимости в ПО и/или некоторые настройки по умолчанию. Дальше – кто быстрее: «найти и взломать» или «найти и обезвредить». Особенно высокая интенсивность появления уязвимых серверов была на второй день соревнований. Новые сервисы на базе различных UNIX-систем практически все были подвержены уязвимости CVE-2015-5600 SSH-сервиса, закрытую не во всех репозиториях. Уязвимость позволяет подключившемуся по SSH пользователю/машине выполнять перебор паролей либо вызвать отказ в обслуживании в связи с использованием ресурсов CPU. В нашей ситуации – более чем реальный вариант развития событий. Для того чтобы не выполнять обновление из исходных кодов в срочном порядке, трафик SSH и RDP, инициированный в сторону серверов DMZ из всех подсетей, кроме Защитников и SOC, настройками активного сетевого оборудования был перенаправлен через Balabit Shell Control Box. Как правило, данное решение используется для неотключаемого протоколирования действий пользователей, но в ситуации Противостояния ключевым фактором Объект защиты и нападения – участок железной дороги, частично взломанный хакерами

системный администратор июнь 2016

Безопасность оказались неуязвимость проксирующего модуля zorp-ssh уязвимости CVE-2015-5600 и возможность регулирования количества вводов пароля на стороне SCB. В результате Противостояния из элементов нашей инфраструктуры хакерами была проэксплуатирована уязвимость только одного веб-сервера без влияния на «виртуальный бизнес», за что хакеры получили единственный «флаг» в течение всего соревнования. Сервер был из числа «дырявых», включенных на второй день организаторами. Взлом был обнаружен через пять минут, после чего соответствующая сигнатура IPS была переведена из режима мониторинга в блокировку, проведено обновление сервера и изменены атрибуты доступа. В целом впечатления от соревнования положительные, особо хочется отметить профессионализм SOC, с которым мы плечом к плечу работали 29 часов подряд. Как всегда, в мероприятии, которое проводится впервые, есть что улучшать. Я бы обратил внимание организаторов на такие аспекты: > вычислительные ресурсы виртуальной инфраструктуры – на этапе подготовки довольно часто происходили перебои в работе, а во время соревнований периодически чувствовалось, что оборудование работает под высокой нагрузкой; > слишком близкое расположение к сцене и чрезмерно громкий звук. На следующий год необходимо будет как минимум провести конкурс на том же уровне, чтобы не разочаровать участников, зрителей и общественность. Более официальную информацию можете найти на сайте организатора [1], неофициальную – в моем блоге [4]. EOF [1] PHDays – Positive Hack Days. CityF Правила – http://www. phdays.ru/program/ctf. [2] На PHDays московский десятиклассник взломал электрическую подстанцию небольшого города – http://www.phdays.ru/ press/news/62000. [3] PHDays VI: нарушена работа ГЭС и затоплен город – http://www. securitylab.ru/news/482206.php. [4] Andrey Dugin @blog – http://aodugin.blogspot.ru/search/label/ PHDays.

Объект защиты и нападения – электроэнергетическая компания, у которой была нарушена работа ГЭС и затоплен город

Безопасность

механизмы защиты

Визитка

АНДРЕЙ ДУГИН, инженер по защите информации, CCNP Security andrew_dugin@ukr.net

Защита от DDoS подручными средствами Часть 2. NTP Amplification В прошлой статье [1] рассматривались протокол DNS и варианты его защиты от использования в DDoS-атаках. Продолжим анализ атак типа «усиление» (amplification)

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

NTP Аmplification Суть атаки в том, чтобы в ответ на NTP-запрос приходил ответ, в несколько раз больший, чем запрос. Поскольку протокол NTP, как и DNS, основан на UDP, в запросе подменяется адрес отправителя на адрес жертвы, но многократное увеличение ответа происходит не за счет рекурсии, а в связи с возможной уязвимостью сервиса ntpd. Естественно, не каждый запрос к серверу вызывает подобный эффект, а только команды REQ_MON_GETLIST и REQ_MON_GETLIST_1, которые изначально разрабатывались для того, чтобы администратор сервера мог вести учет клиентов, которые используют его NTP-сервер, и отслеживать обращения к серверам. Согласно CVE-2013-5211 это свойство признано уязвимостью, которая устранена в версии ntpd 4.2.7p26. Несмотря на то что с момента выхода обновленной версии NTP-сервера прошло два года, сейчас в интернете большое количество IPадресов, подверженных вышеописанной уязвимости. Как проверить, уязвим ли ваш NTP-сервер к подобной атаке? На самом сервере можно выполнить команду: # ntpd –version

Допустиим, сервер устарел, уязвим и показывает версию: ntpd 4.2.6p5

Контрольная проверка того, что данная версия действительно отвечает на MON_GETLIST и MON_GETLIST_1, производится командой: ntpdc -c monlist <server-address>

которую можно выполнить как непосредственно на сервере, так и со стороны клиента. Уязвимый ntpd выдаст приблизительно следующее: remote address port local address count m ver rstr avgint lstint ============================================================= ================== xx.xxx.12.217 123 192.168.10.128 6 4 4 1d0 9 44 xx.xxx.132.250 123 192.168.10.128 6 4 4 1d0 9 45 xxxx.yyyyy.ru 123 192.168.10.128 6 4 4 1d0 9 46 xx.xxx.205.75 123 192.168.10.128 6 4 4 1d0 9 47 xxxx.xxxxxxxx.ru 123 192.168.10.128 1 4 4 1d0 51 51 xxxx.yyyyyyyy.ru 123 192.168.10.128 1 4 4 1d0 52 52 xxxx.zzzzzzzz.ru 123 192.168.10.128 1 4 4 1d0 53 53 <skipped>

При этом tcpdump покажет, что для получения объемного ответа запрос нужен всего один, не требующий верификации источника: 13:31:13.403225 IP 192.168.10.129.38131 NTPv2, Reserved, length 192 13:31:13.440938 IP 192.168.10.128.ntp > NTPv2, Reserved, length 440 13:31:13.441190 IP 192.168.10.128.ntp > NTPv2, Reserved, length 440 ... 13:31:13.446861 IP 192.168.10.128.ntp > NTPv2, Reserved, length 440 13:31:13.447352 IP 192.168.10.128.ntp > NTPv2, Reserved, length 440 13:31:13.447620 IP 192.168.10.128.ntp > NTPv2, Reserved, length 440 Всего 15 пакетов.

> 192.168.10.128.ntp: 192.168.10.129.38131: 192.168.10.129.38131:

192.168.10.129.38131: 192.168.10.129.38131: 192.168.10.129.38131:

Попробуем посчитать коэффициент усиления данной атаки при заданном выше количестве пакетов. Он равен отношению объема ответа к объему запроса. Учитывая то, что tcpdump в значении length показывает только количество байт полезной нагрузки, добавляем

июнь 2016 системный администратор

механизмы защиты

Безопасность

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

к каждому пакету (и запросу, и ответу) по 42 байта заголовков: > 14 – Ethernet; > 20 – IP; > 8 – UDP. Получим, что в ответ на один запрос объемом 192 + 42 = 234 байта уязвимый сервер отдал 15 ответных пакетов по 440+42 = 482 байта, итого 482х15 = 7230 байт. Коэффициент усиления в данном случае равен 7230/234 = 30,9. Рассмотрим ответный пакет (см. рис. 1). Видим, что каждый ответ объемом 482 байт содержит 6 адресов из списка monlist. При этом команда: ntpdc -c monlist <server-address>

может вернуть до 600 записей. Несложная математика подсказывает, что ответных пакетов по 482 байта может быть до 100 на один 234-байтный запрос. Соответственно, коэффициент усиления может достигать значения: 482х100/234=206.

Несложно подсчитать, сколько при таком коэффициенте нужно запросов от подменного IP-адреса жертвы для того, чтобы осуществить атаку мощностью 1 Gbps. Сначала переведем байты в биты: > 234 байт (запрос) = 234х8 = 1872 бит; > 482 байт (ответ) = 482х8 = 3856 бит; > 1 гигабит = 1024х1024х1024 = 1 073 741 824 бит Для вытеснения легитимного трафика с канала в 1 Gbps необходимо такое количество ответов в секунду: 1 073 741 824 / 3 856 = 278 460. Притом что «правильно приготовленный» сервер может отдать 100 ответов на 1 запрос, количество необходимых запросов в секунду для получения 1 Gbps ответных пакетов должно быть: 278 460 / 100 = 2784,6, что совсем немного в масштабах интернета. Для осуществления эффективной DDoS-атаки NTPamplification злоумышленник будет использовать следующие особенности:

Рисунок 1. Ответный пакет NTP-сервера

системный администратор июнь 2016

Безопасность > Возможность подмены IP-адреса запроса на адрес жертвы. > Поиск и поддержание актуальной базы уязвимых NTPсерверов. > Генерация легитимных запросов к уязвимым серверам для поддержания объемных ответов на команду monlist. > Высокая интенсивность запросов зараженными ПК«зомби».

механизмы защиты

restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery # Указываем доверенные IP-адреса restrict 127.0.0.1 restrict 192.51.100.1 restrict 192.51.100.2 restrict 192.51.100.3

IPv6 (Unix)

Как защитить NTP-сервер?

Как и в случае с DNS, если IPv6 не используется на сервере, то лучше его отключить, указав в /etc/sysctl.conf строку:

ntpd.conf (Unix)

net.ipv6.conf.all.disable_ipv6 = 1

Естественно, для того, чтобы ваш NTP-сервер не принимал участия в DDoS-атаках, наиболее правильным будет обновить сервер до версии ntpd 4.2.7p26 и более свежих. Но даже если по какой-либо причине это не удается выполнить оперативно, отключение возможности использования команд REQ_MON_GETLIST и REQ_MON_GETLIST_1 производится одной строчкой в конфигурационном файле: disable monitor

с последующим перезапуском ntpd. После этого на запросы подобных команд NTP-сервер будет отвечать приблизительно следующее: $ ntpdc -c monlist 192.168.10.128 ***Server reports data not found

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

и выполнив команду: $ sudo sysctl -p /etc/sysctl.conf

Iptables (Unix) Как и в случае с DNS, запрос NTP, содержащий запрос MON_ GETLIST или MON_GETLIST_1, может быть описан правилом iptables. На рис. 2 показан формат пакета, содержащего подобный запрос. Как видно, байт под номером 45 содержит шестнадцатеричную последовательность 0x2a, идентифицируя NTP-запрос как содержащий MON_GETLIST_1. Составим последовательность команд iptables, которая: > пропускает NTP-запросы клиентов из подсети 192.0.2.0/24 iptables -v -A INPUT -s 192.0.2.0/24 -m state --state NEW ↵ -p udp --dport 123 -j ACCEPT

> дает возможность синхронизироваться с вышестоящими серверами 192.51.100.1-3 iptables -v -A OUTPUT -m iprange ↵ --dst-range 192.51.100.1-192.51.100.3 ↵ -m state --state NEW -p udp --dport 123 -j ACCEPT

Рисунок 2. Пакет, содержащий «вредоносный» NTP-запрос

июнь 2016 системный администратор

Безопасность

механизмы защиты > блокирует все запросы к серверу, содержащие MON_ GETLIST_1 iptables -v -A INPUT -p udp --dport 123 -m string --from 44 ↵ --to 46 --algo bm --hex-string '|2A|' -j DROP

Cisco

ios_router# show subsys name ntp

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

uRPF-check В соответствии с рекомендациями BCP38 и RFC2827, универсальными для предотвращения возможности быть орудием DDoS-атак, основанных на методике подмены IP-адреса, нетранзитный L3-интерфейс маршрутизатора, к которому подключаются потенциальные NTP-клиенты, должен быть сконфигурирован для проверки входящих пакетов на наличие в таблице маршрутизации: CE(config-if)# ip verify unicast source reachable-via rx

Не подверженные уязвимости версии покажут: Class Protocol

Version 4.000.000

Тем не менее даже если ПО неуязвимо, стоит обеспечить его дополнительную защиту, поскольку производитель указывает, что 100% защита от возможности эксплуатации подобной уязвимости состоит только в отключении NTP-сервера. Необходимо дополнить конфигурацию устройства Cisco следующим образом. Создать блокирующий список доступа: ios_router(config)# ip access-list standard DENY ios_router(config-std-nacl)# deny any

Применить его для блокировки запросов к устройству как к NTP-серверу: ios_router(config)#ntp access-group query-only DENY ios_router(config)#ntp access-group serve DENY

Если маршрутизатор выполняет роль NTP-сервера для легитимных клиентов, находящихся в подсети 192.0.2.0/24, список доступа будет иметь вид: ios_router(config)#ip access-list standard PERMIT_NTP_CLIENTS ios_router(config-std-nacl)#permit 192.0.2.0 0.0.0.255 ios_router(config-std-nacl)#deny any

и будет применяться только для предоставления возможности синхронизации времени: ios_router(config)#ntp access-group serve-only ↵ PERMIT_NTP_CLIENTS

Разрешить общение с вышестоящими NTP-серверами можно, добавив их в доверенный список:

системный администратор июнь 2016

и применив с помощью команды: ios_router(config)#ntp access-group peer PERMIT_NTP_PEER

Поскольку уязвимы не только Unix-серверы, но и не менее популярное в сети Интернет оборудование Cisco, рассмотрим, как защитить сетевые устройства от использования в DDoS-атаках NTP Аmplification. Перечень зарегистрированных Cisco Systems дефектов, связанных с CVE-2013-5211, в зависимости от типа ПО, показан в источнике [2]. На примере Cisco iOS рассмотрим предлагаемые производителем варианты диагностики и защиты устройства [3]. Согласно информации от поставщика, версии iOS начиная с 12.4(15)XZ, 12.4(20)MR, 12.4(20)T, 12.4(20)YA, 12.4(22)GC1, 12.4(22)MD, 12.4(22)YB, 12.4(22)YD, 12.4(22)YE и 15.0(1)M в соответствующих ветках неуязвимы, поскольку поддерживают NTP v4. Проверяется поддерживаемая версия NTP командой:

Name ntp

ios_router(config-std-nacl)#permit 198.51.100.1 ios_router(config-std-nacl)#permit 198.51.100.2 ios_router(config-std-nacl)#permit 198.51.100.3 ios_router(config-std-nacl)#deny any

Выводы Выполнив описанные настройки, мы напрямую не защитимся от атак на нашу сеть и серверы, но сделаем невозможным использование своих ресурсов для атак на других, а также минимизируем количество оснований для кричащих заголовков в прессе «Русские хакеры атаковали...». Итого: уменьшить количество DDoS-атак типа NTP Аmplification, минимизировать участие своего инфраструктурного сегмента можно с помощью следующих действий, не требующих дополнительных финансовых вложений: > Обновление NTP-сервера до версии не ниже 4.2.7p26. > Отключение IPv6, если данный протокол не используется. > Безопасная конфигурация NTP-сервиса на серверах и сетевом оборудовании, обеспечивающая отсутствие обработки запросов MON_GETLIST и MON_GETLIST_1. > Применение правил iptables, запрещающих входящие NTP-пакеты со значением 0x2a в 45-м байте. > Применение проверок uRPF на активном сетевом оборудовании. И если так поступит каждый администратор сервера либо сетевого оборудования с сервисом NTP, доступным из сети Интернет, цифровой мир приблизится еще на один шаг к совершенству. EOF [1] Дугин А. Защита от DDOS подручными средствами. Часть 1. DNS Amplification. // «Системный администратор», №5, 2016 г. – С. 22-26 (http://samag.ru/archive/article/3189). [2] Cisco Network Time Protocol Distributed Reflective Denial of Service Vulnerability – https://tools.cisco.com/security/center/ content/CiscoSecurityNotice/CVE-2013-5211. [3] Cisco IOS Software NTP Control Mode 7 vulnerability CSCtd75033 – https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtd75033. Ключевые слова: DNS, DDoS, DNS Аmplification, безопасность, BIND.

Безопасность

аудит

Визитка

АНДРЕЙ БИРЮКОВ, ЗАО «НИП Информзащита», системный архитектор, mex_inet@rambler.ru

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

В предыдущих двух статьях цикла [1, 2] мы собирали информацию об атакуемой сети и пытались проникнуть внутрь посредством беспроводных каналов связи. Будем считать, что находимся в атакуемой сети, нам известны подсети, адресация, маски, шлюзы, активные узлы и прочая полезная информация. Мы уже знаем, какие операционные системы и версии прошивок используются. Можем приступить к взлому. Я не случайно уделил столько внимания вопросам исследования сети. Дело в том, что при отсутствии этой информации, взлом превращается в блуждание с завязанными глазами. На то, чтобы провести это исследование, злоумышленнику нужны время и некоторые активные действия, по которым его можно обнаружить еще до того, как он начал наносить ущерб компании. Итак, мы знаем, какой хост является каким устройством. Теперь попробуем проникнуть на некоторые из них. Пока не будем искать и использовать уязвимости в программном обеспечении. Вместо этого внимательно посмотрим на собранную нашими сканерами и снифферами в предыдущей статье информацию об имеющихся в сети устройствах и программном обеспечении, используемом на них. С отчетами сканеров все понятно, для обнаруженных хостов нам сообщили то, что удалось определить. Что касается снифферов, то тут, даже если нам не удалось перехватить пароли пользователей, в перехваченном трафике наверняка есть приветственные сообщения (баннеры) различных устройств и приложений. Так или иначе, нелишним будет проверить содержимое cap-файла с перехваченным трафиком на наличие наименований наиболее распространенного ПО и оборудования. На рис. 1 представлен пример работы сниффера Wireshark. Кто-то обратился к веб-серверу, и в его ответе присутствует версия ПО IIS 7.5. В рамках статьи будем считать, что перехватить какие-либо учетные данные сниффером не удалось, и будем добывать доступ к узлам самостоятельно. А к теме перехваченных паролей вернемся, когда будем обсуждать поднятие привилегий (privilege escalation), в одной из следующих статей.

Итак, у нас есть некий список идентифицированного ПО. Алгоритм наших дальнейших действий в рамках данной статьи будет следующим: > Поиск учетных записей по умолчанию (если применимо). > Проверка данных аккаунтов. > Сканирование на наличие уязвимостей. > Эксплуатация данных уязвимостей и получение доступа.

Поиск учетных записей по умолчанию Начнем с самого простого, а именно попробуем подключиться к узлам в сети жертвы с помощью учетных записей по умолчанию. В данном контексте учетными записями по умолчанию мы будем называть технологические аккаунты, которые создаются при первичной инициализации устройства или ПО. Такие записи особенно актуальны для различного сетевого оборудования, прежде всего точек доступа к беспроводным сетям. Конечно, все вендоры настоятельно рекомендуют менять пароли после инициализации. Но мой опыт показывает, что особенно в сетях крупных организаций это правило совершенно не выполняется. Произведя первоначальную установку с паролями по умолчанию, администраторы потом просто забывают про свои устройства и вспоминают о них только в случаях сбоев. При этом сисадмины, как будет описано далее, судорожно ищут эти заводские пароли в документации вендоров. Для того чтобы узнать учетные записи по умолчанию, прежде всего необходимо обратить к руководству по установке, которое можно найти на сайте разработчика данного устройства. Так как модель устройства нам известна, поиск документации не должен составить большого труда. Зачастую, чтобы найти нужное, достаточно воспользоваться Google. Но когда в сети жертвы имеется целый «зоопарк» устройств, ускорить процесс поиска учетных записей по умолчанию можно с помощью ресурсов, подобных [3]. А что делать, если в сети несколько десятков различных сетевых устройств? Процесс подключения к каждому из них

июнь 2016 системный администратор

аудит

Безопасность

Узнаем, какие методы используют злоумышленники для поиска уязвимых машин, и как этому противостоять

двух статьях и в этой, не требуют высокой технической квадля проверки правильности учеток по умолчанию может залификации. Достаточно базовых знаний по сетевым технонять продолжительное время. Кроме того, такая активность логиям и умения читать документацию. До этого момента может быть обнаружена системами мониторинга. Здесь нам на помощь приходит утилита 56_RouterScan. нам не требовалось никаких глубоких знаний по программированию и устройству различных ОС. Она не входит в состав Kali Linux и работает под Windows. Однако тема уязвимостей, по моему мнению, является Эта программа позволяет автоматизировать описанные ранее действия. достаточно сложной, и поэтому я хотел бы сначала расОна сканирует сеть на наличие «живых» узлов и открысмотреть теоретические основы, а только затем переходить тых портов. Затем, в случае если удалось идентифицировать непосредственно к практике. В противном случае у читателя не будет целостной картины, без которой он не сможет сервисы на узле (например, модель сетевого устройства), утилита пытается подключиться к нему с паролем по умолсамостоятельно заниматься поиском и устранением уязвимостей. чанию. В случае успешного подключения мы получаем имя Термином «уязвимость» (по-английски – vulnerability) учетной записи по умолчанию. обычно называют недостатки в системе, с помощью которых Также RouterScan может производить попытки подключения с учетными записями, заданными пользователем. Это полезно тогда, Рисунок 1. Наименование веб-сервера IIS в перехваченном пакете когда нам известен пароль от одной учетной записи и мы хотим проверить, подойдет ли он к другим устройствам. Очень часто бывает, что администраторы используют единую учетную запись на большом количестве устройств. Итак, не запустив ни одного эксплоита, мы смогли получить доступ к нескольким устройствам, на которых администраторы забыли сменить пароли по умолчанию. В случае если для вашей сети это не так и ни на одном сетевом устройстве не осталось паролей по умолчанию, то это очень хорошо, однако как обычно, расслабляться не стоит, так как теперь мы переходим к более серьезной теме, а именно к поиску уязвимостей.

Поиск уязвимостей По большому счету все те действия, которые я описывал в предыдущих

системный администратор июнь 2016

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

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

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

аудит Классическим примером является семейство технологий пакетной передачи данных Ethernet, разработанное более 30 лет назад. В то время никто не задумывался о проблеме прослушивания трафика, в результате в стандарт не было заложено шифрование трафика. И теперь при использовании таких протоколов, как Telnet, FTP или HTTP, передаваемые данные не защищены от прослушивания. Именно уязвимости проектирования мы использовали, когда прослушивали сетевой трафик. Очевидно, что уязвимости проектирования крайне сложно устранить. Обычно проблему устраняют за счет расширения – HTTPS, FTPS. Однако добавить шифрование в Ethernet практически невозможно. Для этого придется выпускать новую версию Ethernet. Но уязвимости проектирования широко известны, и при внедрении своих решений можно своевременно принять меры по предотвращению их эксплуатации.

Уязвимости разработки Наиболее распространенными уязвимостями являются ошибки, допущенные программистами при написании исходного кода. Неаккуратная обработка вводимых пользователем или получаемых приложением по сети данных может привести к некорректной работе программы. Для лучшего понимания разберем классический пример. Пусть у нас имеется программа, которая получает данные в качестве аргумента из командной строки. #include <string.h> int main(int argc, char *argv[]) { char c[12]; // для переменной c зарезервировано // 12 байт strcpy(c, argv[1]); // копируем переданные // из командной строки данные // в переменную c return 0; }

Рисунок 2. Переполнение буфера

июнь 2016 системный администратор

Безопасность

аудит В случае если в качестве аргумента будет передано более 12 байт, программа аварийно завершится с ошибкой. Посмотрим, что при этом происходит в памяти компьютера (см. рис. 2). Слева показано содержимое памяти до получения данных от пользователя, в середине – программа получила корректные данные (строка Hello), а справа – результат передачи более 12 байт. Как видно, в этом случае затирается содержимое ячеек памяти, что в результате и приводит к аварийному завершению работы программы. Особое внимание стоит обратить на содержимое Return Address. Это адрес возврата, который тоже затирается при передаче большого объема данных. Однако в случае, если мы затираем его случайным значением, программа просто выходит из строя. Но если аккуратно подменить содержимое этих ячеек нужным адресом, то можно перенаправить программу на выполнение необходимого кода. Например, можно в качестве параметра командной строки передать набор машинных команд, выполняющих определенный код, а затем посредством подмены адреса возврата заставить программу выполнить данные команды. Следующая программа не подвержена уязвимости переполнения буфера: #include <string.h> int main(int argc, char *argv[]) { char buf[12]; strncpy(c, argv[1], sizeof(c)); return 0; }

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

Уязвимости внедрения Наконец, третий тип – это уязвимости внедрения и эксплуатации. Если предыдущий тип уязвимостей скрыт от инженеров и администраторов и обнаружить их без специальных средств довольно проблематично, то за некорректные настройки отвечают именно эти специалисты. Здесь типичных примеров можно найти множество. Например, сетевое оборудование с паролями по умолчанию, о котором мы уже говорили чуть выше, или с бесчисленными qwerty, p@ssw0rd и аналогичными простыми парольными фразами. В случаях с базами данных MS SQL это использование учетной записи sa для взаимодействия приложений и БД. Как известно, для этого необходимо создать отдельную учетную запись с ограниченным набором прав, а не использовать административный аккаунт. Уязвимости внедрения относительно легко обнаружить при проведении аудита безопасности, однако они не менее

Рисунок 3. Найденные уязвимости

системный администратор июнь 2016

Безопасность опасны, чем описанные выше ошибки при разработке программ. Ведь как бы хорошо ни было написано приложение, все его элементы защиты становятся бесполезными, если администратор использует простой пароль из «словаря». Уязвимости проектирования и внедрения мы уже рассмотрели: первые при использовании снифферов и вторые при проверке паролей по умолчанию. Теперь перейдем к наиболее сложным, но интересным уязвимостям разработки. Напомню, что на предыдущих этапах нам стали известны версии программного обеспечения, используемого на узлах атакуемой сети. На базе этой информации мы можем сделать предположение о том, какие пакеты обновлений установлены или, что более важно, не установлены на машинах. Если, к примеру, на компьютере с Windows 7 не установлен Service Pack 1, то система может содержать уязвимости, закрытые в SP1. Однако такой путь не слишком удобен, так как требует значительного времени на их поиск. Гораздо лучше поручить эту операцию специальному сканеру. Мы рассмотрим проведение сканирования на уязвимости с помощью Nessus и OpenVAS. Сканер Nessus не входит в состав Kali, однако разработчики из компании Tennable подготовили специальную сборку для данной ОС [4]: root@kali:/root# dpkg –i "Nessus-6.6.2-debian6_amd64.deb"

Запускаем службу:

аудит в разделе Discovery выбрать Scan Network Printers. Далее сохраним нашу политику. Далее нам необходимо запустить сканер. Для этого выбираем Scans в верхней части экрана, New scan -> User. Затем выбираем нашу политику. На следующем шаге указываем наименование задачи сканирования и в поле Targets указываем цели сканирования. Сохраняем созданную задачу. Теперь в разделе Scans у нас появилось новое сканирование. Запускаем эту задачу. После завершения напротив данного сканирования появится галочка. Теперь можно просто нажать на задачу и увидеть количество найденных уязвимостей (см. рис. 3). Уязвимости, помеченные красным цветом, наиболее опасны. Что со всем этим делать дальше, мы поговорим в следующей статье, а сейчас я рассмотрю работу со сканером OpenVAS. Многие могут задаться вопросом: зачем проверять вторым сканером, если мы уже использовали Nessus? Здесь все аналогично антивирусам: у каждого свое ядро, и то, что один пропустил, другой вполне может определить. Поэтому, если один сканер не нашел интересных уязвимостей, рекомендую «пройтись» другим – возможно, найдется чтото новое. OpenVAS является ответвлением от проекта Nessus. Для установки OpenVAS необходимо выполнить следующие действия: root@kali:~# apt-get update root@kali:~# apt-get dist-upgrade

root@kali:/root# /etc/init.d/nessusd start

Обновление пакетов будет не лишним. Далее вся работа со сканером будет осуществляться через браузер по адресу: https://127.0.0.1:8834. Первым делом нам необходимо указать пароль для учетной записи. Затем необходимо ввести серийный номер. Получить его можно по ссылке на странице ввода серийного номера. Далее начнется продолжительный процесс загрузки компонентов базы данных сканера Nessus. По завершении всех подготовительных действий можно переходить непосредственно к сканированию интересующих узлов. Для этого необходимо предварительно подготовить политику, в соответствии с которой будет производиться сканирование. Выбираем Policies, далее New policy, Advanced Scan. Далее присваиваем имя новой политике и настраиваем ее свойства в левой части окна. В принципе для начала все можно оставить по умолчанию, разве что в подразделе Permissions раздела Basic я разрешил Default работать с данной политикой (Can use). В случае если мы собираемся сканировать сетевые принтеры (очень часто содержат уязвимости), необходимо Рисунок 4. Найденные сканером OpenVAS уязвимости

root@kali:~# apt-get install openvas

После установки запускаем установку сканера. root@kali:~# openvas-setup

Открываем https://127.0.0.l1:9392. Вводим те учетные данные, которые нам выдали при установке. Для начала необходимо сконфигурировать задачу сканирования. Идем в раздел Configuration – Scan Configs. Далее выбираем политику Full and fast ultimate и клонируем ее, нажав на значок овечки. Теперь отредактируем клон, нажав на значок гаечного ключа. Прежде всего даем политике название, остальные опции оставляем без изменения, но учитываем, что safe_check – отключение данной опции позволит запускаться потенциально опасным NVT-тестам, выполнение которых может вызвать сбои в работе хоста. Далее устанавливаем цели сканирования в разделе Configuration – Target. Прописываем цели сканирования, диапазон портов можно оставить без изменения. Затем запускаем сканирование, выбрав раздел ScanManagement – Task. По окончании работы получаем отчет, аналогичный приведенному на рис. 4. Для более глубокого ознакомления с Nessus и OpenaVAS рекомендую почитать документацию на сайтах проектов.

июнь 2016 системный администратор

аудит

Делаем выводы Итак, мы проверили нашу сеть на наличие уязвимостей. Если на вашем оборудовании обнаружились пароли по умолчанию, то я бы категорически рекомендовал проверить всю конфигурацию данного устройства на предмет наличия закладок, например, учеток, которые мог создать злоумышленник, или произвольных открытых портов. Не лишним будет посмотреть журналы событий на устройстве на предмет того, кто и когда к нему подключался. Что касается работы со сканерами уязвимостей, то при проведении аудита я бы не рекомендовал использовать Nessus или OpenVAS для проверки сразу большого числа узлов, например целой подсети. Конечно, один раз это можно сделать, для того чтобы увидеть, как сетевые IDS, система управления событиями безопасности и другие средства защиты (если, конечно, они у вас есть) отреагируют на такое массовое сканирование-атаку. Однако не стоит рассчитывать, что так будет действовать злоумышленник. Обычно атаку разбивают на части и распределяют во времени. То есть, проникнув в корпоративную сеть, злоумышленник может в течение нескольких недель подключаться к сети и сканировать небольшие участки сети, выявляя интересующие хосты. А уже потом к этим хостам, также пошагово, будут применяться сканеры уязвимостей. В случае если злоумышленник сразу запустит сканирование на наличие уязвимостей хотя бы для нескольких десятков узлов, это сразу отразится на пропускной способности каналов, что само по себе привлечет внимание сетевых администраторов даже без помощи специализированных средств защиты. Поэтому рекомендую в качестве пентеста проводить сканирование отдельных наиболее критичных узлов с последующей проверкой реакции на эти атаки, как средств защиты, так и журналов событий самих атакуемых узлов. Возможно, в логах окажется больше полезной информации, чем на сетевом IDS, который пропустит данную атаку. А теперь поговорим о том, как бороться с уязвимостями. Абсолютно все разработчики настоятельно рекомендуют устанавливать обновления безопасности сразу после их выпуска. Но большинство администраторов критичных сервисов обычно не спешат это делать. Они объясняют свою нерасторопность тем, что установка обновлений может привести к недопустимым сбоям в работе. Это точка зрения имеет право на существование, и для таких сервисов я бы рекомендовал использовать решения класса Application Firewall, которые позволяют устанавливать «виртуальные» патчи, то есть блокировать попытки эксплуатации незакрытых на целевых узлах уязвимостей. А для рабочих станций и некритичных серверов должны быть развернуты тестовые машины с типовыми ОС и приложениями, на которых все обновления должны обязательно тестироваться перед установкой на боевые системы. Для сетей, содержащих большое количество машин под управлением ОС Windows, необходимо использовать бесплатный сервис Windows Server Update Services (WSUS) [5], который позволяет осуществлять централизованное управление обновлениями продуктов Microsoft. Групповые политики должны устанавливать обновления на пользовательские машины, но не перезагружать

системный администратор июнь 2016

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

В качестве пентеста проводите сканирование отдельных, наиболее критичных узлов с последующей проверкой реакции на эти атаки, как средств защиты, так и журналов событий атакуемых узлов Здесь можно воспользоваться как уже описанными Nessus и OpenVAS, так и полностью коммерческими решениями типа Max Patrol от Positive Technologies. Но здесь следует помнить, что Nessus для коммерческого использования также является платным. Для Windows сетей можно воспользоваться бесплатными анализаторами уязвимостей Microsoft Baseline Security Analyzer (MBSA) и Microsoft Security Assessment Tool (MSAT) [6].

В этой статье цикла я описал процесс поиска уязвимостей, следующим шагом будет непосредственное проникновение, сначала с помощью пакета Metasploit Framework, а затем мы отдельно рассмотрим основы фаззинга и реверс-инжиниринга, то есть самостоятельного поиска уязвимостей. По сути, на данном шаге мы «нашли лазейку» и дальше нам необходимо будет проникнуть в эту лазейку и закрепиться в ней. Сейчас же важно понимать, какие методы могут использовать злоумышленники для поиска уязвимых машин и как лучше этому противостоять. EOF [1] Бирюков А. Проводим пентест. Часть 1. Проникаем в беспроводную сеть. // «Системный администратор», №4, 2016 г. – С. 40-44 (http://samag.ru/archive/article/3171). [2] Бирюков А. Проводим пентест. Часть 2. Сбор необходимой информации. // «Системный администратор», №5, 2016 г. – С. 27-31 (http://samag.ru/archive/article/3190). [3] База паролей по умолчанию для различных устройств – http:// routerpasswords.com. [4] Страница Nessus – http://www.tenable.com/products/nessus/ select-your-operating-system. [5] Страница WSUS – https://technet.microsoft.com/ru-ru/security/ cc297183. [6] Страница MBSA и MSAT – https://technet.microsoft.com/ru-ru/ windowsserver/bb332157.aspx. Ключевые слова: безопасность, пентест, аудит, Kali.

Безопасность

мониторинг

Визитка РАШИД АЧИЛОВ, главный специалист по защите информации в компании, занимающейся автоматизацией горнодобывающей промышленности, shelton@sheltonsoft.ru

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

Включи Большого Брата

Закон суров, но это закон

Направление программ СМП (систем мониторинга пользователей) в настоящее время переживает просто взрывной какой-то рост. То ли технологический уровень подтянулся, то ли кризис вынудил руководителей оптимизировать использование рабочего времени, а может быть, и то, и другое, и еще какое-нибудь третье привело к тому, что на поле, где в 2014 -м играли только LanAgent да StaffCop – не самые, скажем так, сильные игроки (успех «Стахановца» тогда был еще впереди), – в настоящий момент начинается реальная конкуренция. Кроме уже упомянутых LanAgent, StaffCop и «Стахановца», здесь присутствуют зарубежные варианты на тему СМП – NetVizor, Veriato 360 и другие, практически в России не известные, а также «пост-Стахановцы» – проекты, основанные людьми, в разное время из команды разработки «Стахановца» ушедшими, – KickIdler и EagerBeaver. Правда, последний проект, похоже, так и не достиг первого релиза. Тем не менее «Стахановец» до сих пор умудряется держать баланс между функциональностью и ценой, и это притом что этот баланс все-таки был существенно поколеблен при переходе на версии 5.х и новую политику лицензирования. Общее описание – что такое СМП, из чего оно обычно состоит и достаточно беглое описание существовавшей тогда версии «Стахановца» – было приведено в [1]. Основной его функционал не изменился, появились некоторые дополнительные модули, далеко не все из них полезны, некоторые несут чисто маркетинговую нагрузку – отличают продукт от программ конкурентов. Мы рассмотрим более подробно порядок установки, настройки и особенности работы «Стахановца», а также юридические аспекты работы СМП вообще. При рассмотрении работы «Стахановца» будем исходить из того, что служба информационной безопасности отделена от службы ИТ и последняя не подозревает (и не должна) о том, что в сети работает система мониторинга пользователей.

Совершенно непонятно, откуда взялось убеждение «мой компьютер, и вы не можете мне указывать, что за ним делать». Но, как это ни странно, многие и многие пользователи почему-то до сих пор считают, что работодатель выделил им рабочее место, оснастил компьютером, а вот что они делают за этим самым компьютером – это не его, работодателя, дело. Возможно, корни этого убеждения восходят еще к тем временам, когда компьютеры были дорогим удовольствием, и увидеть их можно было только на рабочем месте. Те времена давно прошли, но с таким отношением, особенно по вопросу электронной почты, до сих пор постоянно приходится сталкиваться. Люди, искренне считающие, что работодатель не может контролировать собственную почту, обычно опираются на статью 23 Конституции РФ о тайне переписки и на статью 138 Уголовного кодекса, устанавливающую ответственность за нарушение тайны переписки, и упускают (или же нарочно замалчивают) один момент – тайна переписки распространяется на лиц, участвующих в ее процессе, только при оплате этих средств и услуг оператора связи самостоятельно. Работодатель же оплачивает услуги оператора связи и сам организовывает процесс чтения и доставки электронной почты, так что нарушения статьи 23 Конституции РФ здесь нет. Более того, согласно части 2 статьи 22 Трудового кодекса работодатель обязан обеспечить работника оборудованием, документацией и иными техническими средствами для выполнения им работы. Компьютер и корпоративный почтовый ящик – это такой же инструмент, как молоток, осциллограф, телефон, и использоваться он должен только для работы. При этом согласно части 1 статьи 22 Трудового кодекса работодатель имеет право контролировать целевое использование представленных сотруднику технических средств – будь то осциллограф или компьютер. 13 января 2016 года Европейский суд по правам человека (ЕСПЧ) принял прецедентное решение и фактически

июнь 2016 системный администратор

Безопасность

мониторинг разрешил работодателю читать переписку сотрудников в деле румынского инженера Богдана Барбулеску против его работодателя [2]. Это поставило окончательную точку в вопросе о законности чтения работодателем переписки сотрудника. При рассмотрении доказательств, полученных через СМП, как правило, суды встают на сторону работодателя – множество примеров содержится в [3]. Тем не менее сотрудник должен быть оповещен о том, что его деятельность за рабочим компьютером будет мониториться, и не использовать рабочее место для ведения личной переписки, потому что в случае непреднамеренного раскрытия персональных данных суд встанет на сторону работодателя.

Особенности установки Но довольно скучных юридических подробностей – мы все же не юристы. С сайта [4] скачивается дистрибутив stkh_setup.exe. Версий в названии нет, лучше всего его будет сразу переименовать. Несмотря на то что он назван демо-версией, на самом деле это версия полноценная, просто контролировать с ее помощью можно максимум один компьютер. Чтобы контролировать большее количество, нужно приобрести ключ, который генерируется индивидуально, в зависимости от числа купленных лицензий, и активируется через интернет. stkh_setup.exe – это комплексный установщик, и не только. Почему-то разработчики не стали делать отдельную программу администратора, возложив часть ее функций, например установку агентов, на программу установки. «Стахановец» – это классическая программа агентского наблюдения, когда существующий на компьютере агент периодически передает информацию в центральную базу, в которой проводит аналитику сервер или же оператор баз данных. Надо сказать, защите от обнаружения «Стахановца» уделено было достаточно внимания. Его агент до сих пор не обнаруживается «Лабораторией Касперского», несмотря на то что компания подписана на все последние обновления (а может, как раз и потому. – Прим. ред.). Ну а возможность переименования службы агента и еще некоторые другие приемы превращают его вообще в стопроцентный стелс. Для хранения данных может использоваться MS SQL либо MySQL. Версию с MySQL я не проверял, поскольку она предполагает, как обычно, ручное создание БД, пользователя, выдачу прав на БД и т.д. Использовалась раздаваемая с сервера «Стахановца» версия MS SQL Express. Отмечу сразу: если планируется контролировать больше 50 компьютеров при горизонте хранения месяца три и больше, не ставьте Express, только время потеряете. Ставьте либо платную версию, либо как минимум Express R2. Почему? Максимальный размер БД у Express – 4G, у Express R2 – 8G. Мне кажется, есть разница. Перед началом установки крайне желательно почитать документацию. По совершенно непонятным причинам документация устанавливается тем же инсталлятором, только при запуске инсталлятора нужно выбрать пункт «Документация» (последний). Установка «Стахановца» выглядит непритязательно. Сначала устанавливается Администратор. Он установит

системный администратор июнь 2016

собственно сервер, веб-сервер Apache, причем даже и не поинтересуется, а может, Apache уже стоит. После установки сервер будет запущен – там еще ничего нет, но пока и не надо. Если Apache уже установлен, то поставленный инсталлятором можно не трогать – пусть так и занимает место, а настраивать свой. Инсталлятор устанавливает Apache 2.2.17, мы же установим 2.4.4.

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

Особенности настройки Отдельной программы для установки агентов нет – этот функционал берет на себя инсталлятор. Да-да, установка агента – часть инсталлятора, несмотря на то что это, вообще говоря, постоянная рутинная работа. При запуске инсталлятора нужно выбрать «Клиентская часть (удаленная установка)». Для установки агента существует аж пять способов, но я всегда использовал первый, иногда второй. Почему? Факт установки агентов нужно скрыть ото всех, кроме тех, кому это должно знать, в том числе и от админов. А наличие какого-то странного MSI-пакета или команды в System Center скрыть вряд ли удастся. Перед тем, как начать устанавливать агенты, нужно провести некоторые настройки – в частности, настроить переименование службы и создать пользователей. Запускаем «Глобальные настройки». В версии 5.х появилась возможность войти в них с правами текущей учетной записи Windows – если она имеет права администратора. Обратите внимание: права текущей учетной записи Windows будут распространяться на возможность редактирования

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

мониторинг делает, но все его возможности реализуются только теми, кто знает. Практически все настройки на всех внутренних закладках самоочевидны и заполняются без проблем – если вы считаете, что их нужно заполнять. На закладке «Компьютеры» просто перечислены компьютеры, известные серверу, и дата последнего получения данных с них. Возможно, эта закладка планировалась в качестве средства установки агента на компьютеры, на которых его еще нет, но сделать тут ничего нельзя – информация о компьютерах без агентов все равно на эту страницу не попадает. И еще очень важное замечание: https придется настраивать самим. Хорошо уже и то, что модуль mod_ssl нынче поставляется с дистрибутивом – в первых версиях 4.х его попросту не было. То есть идем в C:\Program Files\ Apache Software Foundation\Apache2.4\conf и настраиваем там основной сайт «Стахановца»: Alias /stkh/ "C:/ProgramData/PBL/Stkh/Server/Web/" Alias /stkh "C:/ProgramData/PBL/Stkh/Server/Web/" <Directory "C:/ProgramData/PBL/Stkh/Server/Web"> AllowOverride None Options FollowSymLinks ExecCGI SSLRequireSSL Require all granted </Directory>

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

Особенности эксплуатации Первое и самое главное – нужно не забывать, что БД MS SQL Express имеет конечный размер и равен он 4 Gb. Это не такое уж и большое значение, при мониторинге достаточно большого количества пользователей, поэтому если число пользователей больше 50 – сразу ставьте Express R2, у которого максимальный размер БД 10 Gb. Не следует забывать и о свободном месте под хранение отчетов, снимков с веб-камер, файлов прослушки, теневых копий. Все это занимает достаточно много места – например, для 70 пользователей при частоте снятия копий экрана 10 минут размер каталога данных составляет порядка 150 Gb «Стахановец» не имеет никаких встроенных средств резервирования, поэтому БД нужно резервировать либо средствами MS SQL, либо средствами Windows, а каталог данных – средствами Windows ну или теми программами для резервирования, которые у вас используются. «Стахановец» не имеет средств обнаружения новых компьютеров и компьютеров, на которых агент исчез после переустановки Windows. А по условиям задачи мы не можем просто так взять и попросить ИТ оповещать нас о том, что появился новый компьютер. Это самый большой недостаток, в необходимости как-то решить который я убеждаю разработчиков уже года полтора. И только в последней версии был сделан контроль за наличием агента на компьютере. Правда, толку от него сейчас все равно нет – он постоянно выдает false positive,

июнь 2016 системный администратор

мониторинг то есть сообщает о возможном удалении агента, когда никакого удаления не было. Для себя я решил вопрос достаточно просто – написал скрипт на vbs, который просто проверяет все найденные в сетевом окружении компьютеры, если их имя не входит в специальный список, на наличие службы (причем используется ее настоящее имя, конечно же). Если служба не найдена, отправляется письмо. Второй крайне неприятной проблемой является проблема с чтением шифрованной почты. Если подключение от клиента (почтовой программы) к серверу выполняется с использованием SSL, то «Стахановец» не то, что письмо прочитать не может – он не видит самого факта того, что куда-то отправлялось письмо! Нормально почта перехватывается только тогда, когда почтовой программой является MS Outlook, если же это любая другая программа – увы. Об этой проблеме многократно ставилась в известность техподдержка «Стахановца», но все их ответы до сих пор, к сожалению, сводятся к одной бессмертной фразе «мы работаем над этим». Есть также проблема с захватом клавиатурного ввода – текст захватывается полностью, но при этом как-то странно перемешивается, так что читать его становится крайне затруднительно, хотя выделить пароль из всей этой массы вполне возможно. Версия 4.х была значительно адаптирована для использования непосредственно в помещении, где находятся наблюдаемые сотрудники – можно было отключить логотипы, а пункты в меню были без пояснений. В версии 5.х поначалу логотипы подписи к значкам почему-то были неотключаемые и цветовая гамма оставляла желать лучшего, и только после моих неоднократных просьб цветовая гамма была скорректирована, а подписи к значкам сделаны отключаемыми. То есть техподдержка «Стахановца» работает, но не всегда в том направлении, в котором хотелось бы. Если у вас один монитор, а у наблюдаемого пользователя – два, то захваченное изображение будет смасштабировано под один экран. Это довольно неудобно, но какого-либо решения, кроме как поставить монитор побольше, я не нашел. Ну и последнее, что может быть весьма неприятным сюрпризом, если для доступа к сайту используются https и персональные сертификаты. Версия 4.х могла показывать наблюдение за экраном только в Internet Explorer через надстройку на ActiveX. После неоднократных доказательств, что это неправильно, от надстройки отказались и написали вспомогательный модуль, работающий в трее. И, казалось бы, все хорошо – поставил модуль и работай в любом браузере. Но не тут-то было. Внезапно всплыла совершенно непонятно как относящаяся сюда ошибка: если в системе установлено больше одного персонального сертификата на одного человека (например, установлено два – действующий и просроченный), то вспомогательный модуль не подключается к серверу. Просто не подключается и все. Выдает некую ошибку, которую если расшифровать, то получается использование недействительного сертификата. На эту ошибку было указано техподдержке, но техподдержка ответила, что использует стандартные API для работы с хранилищем сертификатов Windows и ошибку возвращает

системный администратор июнь 2016

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

Есть ли жизнь после «Стахановца»? Рынок СМП сейчас набирает обороты. Сейчас он еще в значительной мере пуст, но появление «Стахановца» обозначило, можно сказать, некий барьер, уровень, стандарт, на который начинают ориентироваться другие российские производители. Я намеренно не упоминаю о зарубежных производителях, поскольку они рассчитывают в первую очередь на локальные рынки, а за рубежом в отношении СМП может быть все по-другому. StaffCop и LanAgent изначально проигрывали «Стахановцу», и в настоящий момент для более-менее серьезных установок (50 компьютеров и более) я бы не советовал их рассматривать даже в качестве проформы – по уровню они значительно недотягивают. Поскольку разработка продукта, такого как «Стахановец», – дело достаточно длинное, то неизбежно появляются люди, которые считают, что разработка проекта пошла «не туда», и попытаются создать аналогичный, но направленный «туда». То же было и со «Стахановцем». Сначала появился EagerBeaver. Он не дотянул даже до первого релиза, хотя возможности у него были прелюбопытнейшние. Потом появился KickIdler [5]. Проект был основан бывшим лидером команды разработки «Стахановца», но со своим собственным уклоном – основная ставка здесь делается на постоянную видеозапись всего, что происходит на мониторе, и аналитику этой видеозаписи. Аналитический модуль KickIdler – вещь чрезвычайно мощная, но в ней, к сожалению, пока отсутствует перехват электронной почты.

«Стахановец» – система непростая, да, собственно, она особо и не рассчитывалась на неграмотного пользователя. Для того чтобы ее запустить и получать реальную отдачу, придется приложить усилия, затратить время и весьма немалое количество денег на лицензии. Но, если вы вообще задумались о внедрении СМП, в настоящий момент по соотношению стоимости и возможностей «Стахановец» все еще далеко оставляет позади всех конкурентов. EOF [1] Ачилов Р. Большой Брат видит тебя. // «Системный администратор», №6, 2014 г. – С. 52-58 (http://samag.ru/archive/article/2716). [2] ЕСПЧ разрешил читать сообщения пользователей – http://www. bbc.com/russian/news/2016/01/160113_echr_employees_private_ messages. [3] К вопросу о слежке за сотрудниками – http://www.garant.ru/ia/ opinion/author/slesarev/704454. [4] Демо-версия «Стахановца» – http://stakhanovets.ru/poprobovatbesplatno. [5] Сайт программы KickIdler – https://www.kickidler.com/ru. Ключевые слова: контроль сотрудников, сети, безопасность.

Базы данных

инструменты

Визитка

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

Роль статистики таблиц и индексов в производительности SQL-запросов в Oracle Рассмотрим роль своевременного и качественного сбора статистики по таблицам и индексам для обеспечения эффективной работы SQL-запросов, а также средства диагностики и сбора статистики

Роль статистики таблиц и индексов в работе SQL-запросов Существует несколько базовых причин, знание которых позволяет понять, почему не эффективно работает SQLзапрос (т.е. почему запрос работает медленно с большими затратами ресурсов сервера). Среди этих причин можно выделить пять главных, определяющих эффективность работы SQL-запросов (далее запросов): > наличие и качество собранной статистики по таблицам и индексам, используемым в запросах; > наличие и качество индексов, используемых в запросах, а также их правильное применение; > эффективность хинтов (подсказки оптимизатору), используемых в запросах; > качество построения структуры запросов; > правильность настройки параметров инициализации базы данных. При этом многолетний опыт работы в области оптимизации запросов показывает, что порой достаточно создать или обновить статистику таблиц или индексов запроса, чтобы запрос стал работать эффективно. Таким образом, прежде чем добавлять хинты или новые индексы в таблицы запроса, нужно исследовать статистику таблиц и индексов, участвующих в запросе, и в случае необходимости произвести обновление их статистики. Кроме того, достоинством обновления статистики является то, что в этом случае не надо вмешиваться в запрос и хранимые процедуры (функции, процедуры и пакеты), в которых находится запрос, а обновить статистику можно, не мешая работе таблиц и индексов.

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

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

произойти, например, в случае создания новой таблицы и использования ее до момента, когда Oracle в определенные часы сам собирает статистику по таким таблицам. При этом отсутствие статистики может сказаться на производительности работы запроса, например, в случае, когда какая-то из таблиц, входящих во фразу from запроса, не имеет статистики. Увидеть отсутствие статистики, например по таблице his.agreement, позволяет запрос: Select global_stats from all_tables f where owner='HIS' ↵ and table_name = 'AGREEMENT';

где столбец global_stats принимает значение NO при отсутствии статистики и YES при ее наличии. Замечание. Oracle в определенные часы (в вечерние часы в обычные дни и в течение дня в выходные дни) автоматически проводит сбор статистики для таблиц с отсутствующей или устаревшей статистикой.

Вторая причина – это устаревшая статистика Время последнего сбора статистики определяется из столбца Last_analyzed для таблиц (из представлений all_tables или all_tab_statistics) и для индексов (из представлений all_indexes или all_ind_statistics). Oracle ежедневно в определенные часы сам собирает статистику по таблицам, при этом автоматический сбор статистики происходит, если в таблице изменилось (модифицировалось) не менее 10% строк таблицы. Вместе с тем, при интенсивной модификации строк в таблице может потребоваться, не дожидаясь, когда это сделает Oracle, оперативно пересобрать статистику по таблице и индексам. Статистику также целесообразно обновить в ручном режиме в больших таблицах (сотни миллионов строк), в этом случае модификация 10% строк таблицы произойдет за длительное время, а за это время статистика таблицы может для оптимизатора стать устаревшей. Например, в случае перехода на новую версию Oracle обновление статистики таблиц и индексов порой позволяет решить проблемы с производительностью запросов. Во всех этих

июнь 2016 системный администратор

Базы данных

инструменты

Достоинство обновления статистики – не надо вмешиваться в запрос и хранимые процедуры

случаях целесообразно заново собрать статистику вручную (команды сбора статистики будут приведены ниже). Увидеть интенсивность модификации строк по DMLоперациям (Insert, Update и Delete) позволяет диагностический запрос (как правило, за период с 00 часов до текущего времени или с момента сбора статистики таблицы, если ее сбор был в этот день): Select m.timestamp lasttime, u.name owner, ↵ o.name table_name, m.inserts, m.updates, ↵ m.deletes from sys.mon_mods$ m, sys.obj$ o, ↵ sys.user$ u where o.owner#=u.user# ↵ and o.obj#=m.obj# and u.name='HIS' ↵ and o.name='AGREEMENT';

где: > lasttime – показывает текущее время, когда последний раз обновились данные, извлеченные диагностическим запросам; > inserts, updates и deletes – показывают число вставляемых, изменяемых и удаляемых строк в таблице за весь период работы запроса (как правило, за текущий день).

Третья причина – это неудовлетворительная статистика таблиц и индексов Как показала практика, неудовлетворительной можно считать статистику, когда процент сбора статистики по таблице или индексу менее 0,1%. В этом случае рекомендуется обновить статистику. Процент сбора статистики (Percent) и дату последнего сбора статистики (Last_analyzed) для таблиц (например, таблицы his.agreement) позволяет увидеть запрос: Select owner, table_name, round(sample_size/decode( ↵ num_rows,0,100000000000,num_rows)*100,2) percent, ↵ last_analyzed, global_stats from all_tables ↵ where owner='HIS' and table_name = 'AGREEMENT';

Процент сбора статистики и дату последнего сбора статистики всех индексов таблицы позволяет увидеть запрос: Select owner, table_name, index_name, ↵ round(sample_size*100/nvl(decode(num_rows, 0, ↵ 100000, num_rows), 1000000), 2) percent, ↵ last_analyzed, global_stats from all_ind_statistics ↵ where owner='HIS' and table_name = 'AGREEMENT' ↵ order by 3;

Замечание. Целесообразно отслеживать статистику не только по таблице, но и по каждому индексу таблицы. При этом для небольших таблиц сбор статистики по таблице автоматически приведет к сбору статистики по индексам этой таблицы. Вместе с тем для больших таблиц целесообразно обновлять статистику (в режиме распараллеливания операции) по конкретному индексу с неудовлетворительной статистикой (в целях экономии времени и ресурсов процессора). Следует заметить, что одним из приемов, оправдавшим себя на практике, является блокировка сбора статистики. Блокировка используется при интенсивном изменении числа строк в таблице в течение дня (например, при многочисленных удалениях или вставках строк). Это позволяет избежать непроизводительных затрат процессоров на автоматический сбор статистики Oracle, а главное – дать оптимизатору более качественную статистику для выбора производительного плана выполнения запроса. Результаты ручного или автоматического сбора статистики, полученного на какой-то момент времени, закрепляется путем блокировки дальнейшего сбора статистики. Для блокировки сбора статистики используется команда: Execute dbms_stats.lock_table_stats('имя схемы', ↵ 'имя таблицы');

Для разблокировки: в данном диагностическом запросе может быть использовано вместо представления all_tables представление all_tab_ statistics.

системный администратор июнь 2016

Execute dbms_stats.unlock_table_stats('имя схемы', ↵ 'имя таблицы');

Базы данных Команды ручного сбора статистики

инструменты Или без degree:

Ручной сбор статистики по таблицам и индексам (на примере таблицы AGREEMENT в схеме HIS) производится указанными ниже командами. Для таблицы и всех ее индексов одновременно:

Execute dbms_stats.gather_table_stats ('his','agreement', ↵ null,20,null,'for all indexed columns size auto’,32);

Execute dbms_stats.gather_table_stats ('his', 'agreement', ↵ null, N, null, 'for all indexed columns size auto');

Если в таблице при ее создании указать фразу parallel со значением DOP, то степень параллелизма в команде сбора статистики можно не указывать, т.к. Oracle возьмет DOP из таблицы.

Для одного индекса (например, X_AGREEMENT) по команде: Execute dbms_stats.gather_index_stats ('his', ↵ 'x_agreement', null, N);

где число N в команде указывает на процент сбора статистики. Например, при 100% сборе статистики таблицы команда выглядит так: Execute dbms_stats.gather_table_stats ('his', 'agreement', ↵ null, 100, null, ↵ 'for all indexed columns size auto');

Для таблиц может использоваться также команда с автоматическим выбором процента сбора статистики: Execute dbms_stats.gather_table_stats ('his', 'agreement', ↵ null, dbms_stats.auto_sample_size);

При этом чем больше число N, тем качественнее статистика, но в то же время больше времени требуется на ее сбор. С учетом времени сбора статистики и числа строк в таблице (индексе) были выработаны рекомендации для таблиц (индексов) по проценту сбора статистики. Так, если число строк более 100 млн, процент сбора целесообразно устанавливать от 1 до 5, при числе строк с 10 млн до 100 млн процент сбора устанавливать от 5 до 10, менее 10 млн процент сбора можно устанавливать более высокий – от 20 до 100. Замечание. В команде сбора статистики имя схемы и имя таблицы (индекса) можно указывать как в верхнем, так и нижнем регистрах.

Сбор статистики таблиц и индексов в параллельном режиме Для ускорения сбора статистики таблиц и индексов используется распараллеливание операций.

Сбор статистики таблиц Для ускорения сбора статистики по таблице используется параллелизм. Для этого в команде сбора статистики в пакете dbms_stats.gather_table_stats указывается степень параллелизма (DOP) либо через фразу degree =>DOP, либо через установку в седьмом поле команды значения DOP. Например, команда по сбору статистики таблицы HIS.AGREEMENT c процентом сбора статистики 20% и степенью параллелизма DOP=32 имеет вид: Execute dbms_stats.gather_table_stats ('his','agreement', ↵ null,20,null,'for all indexed columns size auto’, ↵ degree=>32);

Сбор статистики для индекса Параллелизм позволяет ускорить сбор статистики по индексу. При этом в команде сбора статистики следует указать степень параллелизма DOP в пакете dbms_stats в поле degree=>DOP. Например, для индекса HIS.X_AGREEMENT с процентом сбора статистики 20% и степенью параллелизма DOP=32 команда сбора статистики выглядит следующим образом: Execute dbms_stats.gather_index_stats ('his', 'x_agreement, ↵ null,20, degree=>32);

Можно фразу degree не указывать, но тогда DOP следует указать в восьмом поле команды: Execute dbms_stats.gather_index_stats ('his', 'x_agreement', ↵ null,20, null, null, null, 32);

Замечание. Возможен вариант, когда в восьмом поле указывается фраза dbms_stats.default_degree (степень параллелизма по умолчанию) или dbms_stats.auto_degree (в последнем случае степень параллелизма регулируется автоматически). Если степень параллелизма указана при создании индекса, например: Create index his.x_agreement…parallel 32;

то степень параллелизма в команде сбора статистики можно не указывать, она возьмется из команды создания индекса. Если же индекс уже создан, то ввести параллелизм в индекс позволяет команда: Alter index his.x_agreement parallel 32;

Замечание. При указании степени параллелизма в индексе при автоматическом сборе статистики, выполняемой Oracle, будет ускорен сбор статистики путем распараллеливания в операции.

Статистика временных таблиц (temporary table) При всех достоинствах временных таблиц: возможность работать одновременно нескольким пользователям с одной и той же таблицей; возможность заполнять временную таблицу от транзакции к транзакции разным числом строк; генерация меньшего числа информации в журнальный файл для Update-операций; освобождение сегментов временной таблицы после закрытия сессии и т.д., у временных таблиц имеется недостаток – это отсутствие у таблицы и, следовательно, у оптимизатора истинных статистических данных.

июнь 2016 системный администратор

Базы данных

инструменты Если статистических данных нет, оптимизатор сам делает предположение о том, как распределены данные, каково их количество и по какому принципу работает индекс. Если эти его предположения неверны, то планы для запросов являются далеко не оптимальными. Вместе с тем существует несколько способов передать оптимизатору статистические данные по временной таблице. Для примера создадим временную таблицу his.account_ tmp и индекс к ней x_account_tmp: Create global temporary table his.account_tmp (isn number, ↵ parentisn number, datebeg date) ↵ on commit preserve rows; create index his.x_acccount_tmp on his.account_tmp(isn);

Первый способ передачи оптимизатору статистики – это использование Dynamic Sampling (динамического сбора статистики), который работает при наличии значения параметра инициализации optimizer_dynamic_sampling=2 (значение по умолчанию 2 для Oracle 11g и 12c). При этом для Oracle 12c автоматический динамический сбор статистики расширен. Так, для управления сбором динамической статистики добавлено специальное значение optimizer_ dynamic_sampling = 11 (доступное также в версии 11.2.0.4). Новое значение параметра инициализации дает оптимизатору возможность самому принимать решение о сборе динамической статистики. На уровне сессии параметр инициализации можно менять по команде: Alter session set optimizer_dynamic_sampling =11;

Второй способ – это перед выполнением запросов к временной таблице с уже заполненными данными собрать статистические данные по таблице с помощью пакета dbms_stats, как и для обычных таблиц и индексов (правда, этот метод малоэффективен для таблиц с ON COMMIT DELETE ROWS). Третий способ – это вручную подставить статистические данные во временную таблицу для принятия решения оптимизатору по команде: dbms_stats.set_table_stats(‘his’, ‘account_tmp', ↵ numrows => ‘1000’, numblks => 55, avgrlen => 22);

где: > numrows – число предполагаемых строк в таблице; > numblks и avgrlen – число блоков данных и средняя длина столбцов таблицы соответственно. В этих же целях можно использовать хинт кардинальности для явного указания оптимизатору предполагаемого объема выборки из временной таблицы /*+ cardinality(алиас таблицы N) */, где N – планируемое к вводу число строк. Например: Select /*+ cardinality (t 10000) */ from his.account_tmp;

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

системный администратор июнь 2016

Если в сессии в начале работы запроса поставить вместо 0 значение, например, 5 через команду: Alter session set "_optimizer_random_plan"=5;

то скорость SQL-запроса с временной таблицей может существенно вырасти. Вместе с тем после работы запроса следует вернуть параметр в исходное положение, т.е. прописать после запроса: Alter session set "_optimizer_random_plan"=0;

поскольку другие запросы сессии могут затормозиться. Увидеть результаты сбора статистики по временной таблице позволяет диагностический запрос: Select owner, table_name, last_analyzed, global_stats, ↵ num_rows, blocks, avg_row_len /*, scope*/ ↵ from all_tab_statistics where owner='HIS' ↵ and table_name= 'ACCOUNT_TMP';

Результаты сбора статистики по индексам временной таблицы позволяет увидеть запрос: Select owner, table_name, last_analyzed, global_stats, ↵ num_rows /*, scope from all_ind_statistics ↵ where owner='HIS' and table_name= 'ACCOUNT_TMP';

Замечание. В Oracle 12c появился новый столбец scope в представлениях all_tab_statistics и all_ind_statistics, который при значении session указывает, что статистические данные относятся к одной сессии, а значение shared показывает, что эти данные являются общими для всех сессий.

Выводы > Существенна роль статистики таблиц и индексов в обеспечении производительной работы SQL-запросов. При этом важными моментами являются наличие статистики, ее качество и актуальность. > Существуют диагностические запросы, приведенные в статье, позволяющие в случае неэффективной работы запроса, прежде чем его оптимизировать, выявить статистику таблиц и индексов, участвующих в запросе. Хотя Oracle в определенные часы и при определенных условиях осуществляет автоматический сбор статистики, однако в случае необходимости имеется возможность провести ручной сбор статистики. > Провести сбор статистики таблиц и индексов позволяют приведенные выше команды, при этом для ускорения сбора статистики можно использовать распараллеливание этой операции. Для больших таблиц, если какойто индекс имеет неудовлетворительную статистику, целесообразно собрать ее только для данного индекса. > Производительность работы запросов с временными таблицами существенно повышается, если ей обеспечить наличие статистики. Существуют как динамические методы сбора статистики временных таблиц (через настройку параметров инициализации), так и ручные методы обеспечения статистикой временных таблиц. EOF Ключевые слова: Oracle, СУБД, статистика, производительность.

Базы данных

изучаем 1С

Визитка

ТИМУР ШАМИЛАДЗЕ, руководитель, ООО «БухКонсалтинг», timurshamiladze@yandex.ru

Использование SQL Profiler для поиска и исправления медленных запросов в 1С Одной из основных причин медленной работы 1С являются неоптимальные запросы. С помощью инструмента SQL Profiler можно находить медленные запросы и способы их исправления

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

Понятие плана запроса Чтобы приступить к поиску и исправлению медленных запросов, нам необходимо ввести такое понятие, как план запроса. В процессе своего выполнения запрос, написанный на языке 1С, претерпевает следующие изменения: > Сначала запрос попадает на сервер 1С, где происходит подмена в запросе имен метаданных конфигуратора 1С на таблицы и поля терминологии СУБД, т.е. запрос заменяется на запрос SQL. > Затем сервер 1С посылает этот измененный запрос в СУБД, где он преобразуется в план. План запроса – это последовательность действий, которую необходимо выполнить, чтобы получить результат запроса. Построение плана запроса необходимо, т.к. один и тот же запрос можно получить разными способами: > сканировать таблицу или искать по индексу, > выбору способа соединения таблиц и т.д. Построение плана запроса в SQL Server занимается так называемый оптимизатор СУБД, который исходя из пришедшего текста запроса, статистики, существующих индексов и ограниченного времени (СУБД не может много времени тратить на выбор плана запроса) строит самый оптимальный план запроса, который сможет быстрее всего выполниться и с наименьшими затратами ресурсов. План запроса можно сравнить с таксистом: > Мы ловим такси и говорим, куда нам нужно ехать, – это был наш запрос. > Дальше таксист начинает в голове строить маршрут, по которому он поедет, чтобы быстрее добраться

до места назначения, – это работа оптимизатора СУБД, а выбранный маршрут является планом запроса. > При движении по выбранному маршруту таксист неожиданно оказывается в пробке и вместо того, чтобы быстро добраться до места, целый час в ней простоял – это ошибка оптимизатора СУБД, который построил неоптимальный план запроса (например, статистика была неактуальная). Поэтому медленно работающий запрос – это медленно работающий план запроса.

Почему план запроса может быть неоптимальным Основными причинами медленно работающего запроса являются: > Неактуальная статистика. Если у СУБД неактуальная статистика, то оптимизатор может ошибиться при выборе оптимальной операции для получения данных, в результате чего запрос может сильно замедлиться. Например, из-за неактуальной статистики СУБД посчитала, что вернется 100 строк, и выбрала операцию сканирования, а на самом деле вернулся 1 млн строк, и в результате вместо 0,5 с запрос выполнялся 10 с, что существенно снизило производительность. Всегда важно, чтобы статистика была актуальной. > Плохо написанный запрос. В самом тексте запроса, приходящем в оптимизатор СУБД, уже могут быть допущены ошибки, приводящие к его медленной работе. Например, не указаны условия отбора, в результате чего выборка происходила сканированием. > Отсутствие подходящих индексов. Даже отлично написанный запрос не сможет увеличить скорость работы запроса так, как это может сделать наличие подходящих индексов. Если запрос вначале быстро выполняется, то из-за проблем с неиспользованием индексов со временем производительность его будет уменьшаться, т.к. будет расти количество обрабатываемых запросом данных.

июнь 2016 системный администратор

Базы данных

изучаем 1С

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

Признаки неоптимального плана запроса

Шаг 2. Создание новой трассировки

Рассмотрим основные признаки неоптимального плана запроса. Какие основные операции, присутствующие в плане запроса, указывают на его возможную неоптимальность. > Nested Loops – означает операцию соединения вложенными циклами. Принцип работы вложенных циклов: это самый простейший способ соединения двух таблиц – когда перебираются записи первой таблицы и для каждой ее записи делается перебор записей второй таблицы на выполнение условия соединения. Nested Loops как способ соединения двух таблиц хорош, если ведущая таблица содержит мало данных (1-3 строки), в других случаях предпочтительны другие способы соединения. > Операции сканирования (Table Scan Index Scan Clustered Index Scan) – означают полный перебор данных таблицы или индекса. Сканирование хорошо, когда сканируемая таблица содержит мало записей либо сканируется большая таблица, но из нее возвращается значительное количество данных. Если сканируется большая таблица, а возвращается небольшое количество данных, то это считается неоптимальностью – здесь лучше бы было искать данные по индексу. > Index Seek …Where – означает сканирование не всего индекса, а его части. То есть сначала идет выборка данных по индексу, а оставшаяся часть сканируется по определенному условию. В принципе наличие этой операции всегда указывает на неоптимальность, а именно на отсутствие подходящего индекса, будет только отличаться степень этой неоптимальности (количество сканируемых данных).

Чтобы начать работу с SQL Profiler, необходимо выбрать меню «Файл → Создать трассировку». Прежде чем использовать SQL Profiler для решения задач, мы должны войти в SQL Server, чтобы убедиться, что у нас есть соответствующие права.

Как получить планы запросов в SQL Profiler Чтобы получить планы запросов в SQL Profiler, необходимо выполнить следующие шаги:

Шаг 1. Запуск SQL Profiler «Пуск → Все программы → Microsoft SQL Server → Средства обеспечения производительности → SQL Server Profiler».

системный администратор июнь 2016

Шаг 3. Установка свойства трассировки Нажав на кнопку «Соединить», открываем окно «Свойства трассировки». Первое, что необходимо сделать для настройки трассировки, – это задать «Имя трассировки» на закладке «Общие». Желательно, чтобы оно отражало суть тех данных, которые мы хотим собрать с помощью трассировки. На закладке «Выбор событий» для получения плана запроса нас будут интересовать следующие события (см. рис. 1): > Performance\Showplan Statistics Profile. Получение текстового представления плана запроса > Performance\Showplan XML. Получение графического представления плана запроса > Stored Procedures\RPC:Completed. Получение запроса, выполняемого хранимой процедурой > TSQL\SQL:BatchCompleted. Получение запроса, выполняемого как обычный запрос

Шаг 4. Установка фильтров Часто необходимо собрать информацию о конкретном событии, но только при наступлении определенных условий. Например, события определенного пользователя или для определенной базы данных. Фильтры позволяют отобрать те события, которые нас интересуют. При нажатии на кнопку «Фильтры столбцов» на закладке «Выбор событий» окна «Свойства файла трассировки» откроется окно «Изменение фильтра», в котором мы обязательно должны установить следующие отборы: > Отбор на столбец DatabaseName. Здесь мы ставим фильтр на имя базы данных, в которой мы хотим найти медленные запросы. Если мы не установим отбор на базу

Базы данных данных, то к нам в трассировку будут попадать все запросы по всем базам данных, находящимся на данном SQL Server (см. рис. 2). > Отбор на столбец Duration. Здесь мы ставим фильтр, чтобы получать только те запросы, которые выполнялись более 1 мс (см. рис. 3).

Шаг 5. Запуск, сбор данных и остановка трассировки После того как свойства файла трассировки установлены, нажимаем кнопку «Запустить» в нижнем правом углу интерфейса. Сейчас рассмотрим основные приемы работы с трассировкой (запуск, пауза, остановка и т.д.). > Старт трассировки. После нажатия нами кнопки «Запустить» уже начали собираться данные в трассировку (см. рис. 4). Экран сбора трассировки разделен на две части: в верхней части содержится список событий, а нижняя часть показывает содержимое поля TextData. В нижней левой части окна выдается сообщение

изучаем 1С «Трассировка выполняется», которая показывает текущее состояние трассировки. Другие сообщения, которые могут выводиться: «Трассировка приостановлена», «Трассировка остановлена». В нижней правой части окна показываются номер текущей строки и номер текущего столбца, на котором остановлен курсор, а также общее количество строк. > Приостановка трассировки. Мы можем приостановить сбор трассировки для того, чтобы в дальнейшем продолжить ее сбор. Для этого на панели необходимо нажать кнопку «Пауза». > Остановка трассировки. Чтобы остановить сбор данных трассировкой, необходимо нажать на кнопку «Стоп» на панели. > Очистка трассировки. Если мы сохранили данные трассировки и собранные данные нам уже не понадобятся, то мы можем очистить оперативную память от собранных данных. Для этого необходимо на панели нажать кнопку «Очистить трассировку».

Рисунок 1 . Выбор событий трассировки

Рисунок 2. Отбор базы данных

Рисунок 3. Отбор длительности запроса

июнь 2016 системный администратор

изучаем 1С

Базы данных

Шаг 6. Сохранение файла трассировки

Анализ полученного плана запроса

Сохранение данных трассировки в файл может понадобиться в очень многих случаях. Например, у вас нет времени именно сейчас расследовать причину либо собранные данные необходимо отправить другому человеку для дальнейшего анализа. Файл трассировки можно сохранить в формате .trc. Для этого необходимо просто остановить трассировку и выбрать пункт меню «Файл → Сохранить как → Файл трассировки».

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

Поиск плана запроса для медленных запросов После завершения сбора данных трассировки необходимо ее проанализировать. Если трассировка небольшая по размеру, то можно ее посмотреть вручную. Для этого необходимо смотреть строки с большим временем выполнения (Duration) и большим количеством чтений (Reads). План запроса для выделенной строки будет находиться над соответствующей строкой с текстом запроса (см. рис. 5).

Проверка плана запроса на признаки неоптимальности В данном плане запроса присутствуют вложенные циклы, что является подозрением на причину медленной работы. Но если присмотреться к этой операции плана запроса (см. рис. 6), то можно увидеть, что она занимает только 10% от всего времени выполнения запроса. И если навести курсор на входящую стрелочку, то видно, что ведущая таблица содержит мало данных (предполагаемое количество равно 1, а фактическое равно 0), поэтому вложенные циклы в данном плане запроса не являются проблемой. Следующим подозрительным элементом плана запроса является операция поиска по индексу Clustered Index Seek (см. рис. 6). Эта операция означает, что происходил поиск

Рисунок 4. Сбор данных в трассировки

Рисунок 5. Поиск медленных запросов вручную

Рисунок 6. Наличие Nested Loops и поиска по индексу

системный администратор июнь 2016

Базы данных по кластерному индексу. Поиск по индексу является «хорошей» операцией, но т.к. вес времени выполнения всего запроса очень высок (76%), то нужно проверить ее на дополнительное сканирование (Index Seek …Where). Для того чтобы проверить операцию на дополнительное сканирование, мы можем навести курсор на данную операцию и посмотреть во всплывающей подсказке, есть ли блок «Предикат», – это и будет условием дополнительного сканирования (см. рис. 7).

Важно помнить, что, исправив что-то в одном месте, можно ухудшить производительность в другом Также мы можем обратиться к текстовому плану запроса, который мы нашли событием Performance\Showplan Statistics Profile, и также увидеть, что в условии WHERE у нас будет участвовать содержимое «Предикат».

Нахождение соответствия таблиц SQL Server и метаданных 1С В итоге при анализе данного плана запроса мы получили, что по таблице [_AccumRgT11_ByDims_TRRR] идет поиск в индексе с дополнительным сканированием по полю [_AccumRgT11].[_Fld8RRef]. Теперь необходимо получить название метаданных в 1С, соответствующее этим полям и таблицам. В этом нам поможет специальная обработка (СтруктураХраненияМетаданных1С.epf), которую можно запустить в 1С, и она покажет соответствие метаданных 1С и таблиц СУБД (см. рис. 8). Обработка показала, что таблица [_AccumRgT11_ByDims_ TRRR] соответствует индексу по итоговой таблице регистра накопления «ТоварыНаСкладах», а поле [_AccumRgT11]. [_Fld8RRef] является измерением «Номенклатура».

Рисунок 7. Блок «Предикат» в поиске по индексу

изучаем 1С

Нахождение неоптимального запроса в коде конфигурации 1С Получив информацию о соответствии метаданных 1С, с помощью поиска в конфигураторе 1С можем найти нужный запрос (см. листинг 1). Листинг 1. Нахождение неоптимального запроса в коде конфигурации 1С Запрос.Текст = " |ВЫБРАТЬ | ТоварыНаСкладахОстатки.Номенклатура ↵ КАК Номенклатура, | СУММА(НеобходимыеТовары.Количество) КАК Необходимо, | СУММА(ТоварыНаСкладахОстатки.КоличествоОстаток) ↵ КАК Остаток |ИЗ | РегистрНакопления.ТоварыНаСкладах.Остатки( | , | (Склад, Номенклатура) В | (ВЫБРАТЬ РАЗЛИЧНЫЕ | Документ.Реализация.Товары.Склад, | Документ.Реализация.Товары.Номенклатура | ИЗ | Документ.Реализация.Товары | ГДЕ | Документ.Реализация.Товары.Ссылка = ↵ &Документ)) ↵ КАК ТоварыНаСкладахОстатки | | ЛЕВОЕ СОЕДИНЕНИЕ Документ.Реализация.Товары ↵ КАК НеобходимыеТовары | ПО НеобходимыеТовары.Ссылка = &Документ | И НеобходимыеТовары.Номенклатура = ↵ ТоварыНаСкладахОстатки.Номенклатура | |СГРУППИРОВАТЬ ПО | ТоварыНаСкладахОстатки.Номенклатура";

Исправление плохого запроса Исходя из текста запроса, структуры метаданных и плана запроса можно сделать вывод, что в запросе используется одновременно условие по полям «Склад» и «Номенклатура», а в индексе данной таблицы поля идут следующим образом: «Склад», «Характеристика», «Номенклатура», т.е. из-за разрыва полей в условии СУБД пришлось прибегнуть к дополнительному сканированию по полю «Номенклатура». Чтобы исправить работы этого запроса, мы изменим порядок полей индекса данной таблицы. Для этого в конфигураторе 1С поменяем местами порядок следования измерений «Номенклатура» и «Харакеристика» в регистре накопления «ТоварыНаСкладах» (см. рис. 9). Важно помнить, что, исправив что-то в одном месте, можно ухудшить ситуацию с производительностью в другом месте.

Рисунок 8. Структура метаданных 1С

июнь 2016 системный администратор

Базы данных

изучаем 1С

Проверка полученных результатов После исправления и запуска трассировки заново можно увидеть, что время выполнения запроса уменьшилось в пять раз (с 10 до 2 мс) и дополнительное сканирование по полю [AccumRgT11].[_Fld8RRef] тоже исчезло.

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

Выгрузить полученную трассировку в таблицу Чтобы сохранить трассировку в таблицу SQL Server надо: > Выбрать «Файл → Сохранить как → Таблица трассировки». > В открывшемся меню выбрать базу данных и название таблицы, в которую будет сохранена трассировка. Если работаете на тестовом оборудовании и работа носит разовый характер, то можно пользоваться базой данных master, но лучше создать отдельную базу данных для этих целей. В данном случае мы создадим таблицу PF2016 в базе данных master.

Решение: использовать параметры виртуальных таблиц. > Получение данных через точку от полей составного типа. Приводит к усложнению текста запроса, т.к. СУБД приходится делать соединение со всеми таблицами, входящими в это составное поле. Решение: использование «Выразить» для ограничения количества таблиц или не использовать получение данных через точку.

Использование SQL Profiler может серьезно помочь в поиске, анализе и исправлении медленно работающих запросов 1С > Использование логического «ИЛИ» в условии. Использование «ИЛИ» в условии может привести к неиспользованию индекса. Решение: заменить текст запроса на два отдельных с объединением результатов.

Получить запросы с максимальным временем Для этого мы должны открыть Microsoft SQL Server Management Studio и создать новый запрос (см. листинг 2). Листинг 2. Получение списка самых медленных запросов SELECT

[RowNumber] ,[Duration]/1000 AS Duration ,[Reads] ,[TextData] FROM [master].[dbo].[PF2016] Order by [Duration] desc

В результате мы получим отсортированный по убыванию список самых медленных запросов (см. рис. 10). Чтобы найти соответствующий запросу план, нам необходимо найти этот же запрос в файле трассировки. Зная значение номера строки (RowNumber) из полученного запроса, в окне трассировки выберем «Правка → Перейти к» (<Ctrl> + <G>), перейдем к соответствующему номеру строки, а план запроса будет располагаться выше этой позиции.

Использование SQL Profiler может серьезно помочь в поиске, анализе и исправлении медленно работающих запросов 1С. Важно научиться грамотно работать с этим инструментом оптимизации. EOF Ключевые слова: 1C, производительность, оптимизация, SQL Profiler.

Рисунок 9. Изменение структуры индекса из конфигуратора 1С

Список основных причин медленной работы запросов 1С Часто, глядя прямо на код запроса в 1С, можно понять причину его медленной работы. К основным причинам медленной работы относятся: > Соединения подзапросами или виртуальными таблицами. Приводит к использованию Nested Loops. Решение: переписать запрос с использованием временных таблиц. > Несоответствие индексов и условий запроса. Приводит к операциям сканирования. Решение: переписать текст запроса или создать подходящий индекс. > Неиспользование параметров виртуальных таблиц 1С. Приводит к неиспользованию индекса и, как следствие, к сканированию.

системный администратор июнь 2016

Рисунок 10. Список медленных запросов

Базы данных

изучаем 1С

Визитка

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

Под капотом платформы 1С 8.3 Часть 2. Работа с СУБД Рассмотрим основные объекты метаданных 1С и особенности работы с ними платформы 1С на стороне СУБД

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

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

представляет колонка _IDRRef. По этому полю у таблицы всегда существует кластерный индекс. Кроме этого, в таблице справочника есть еще следующие обязательные поля: > _Version – системное поле timestamp. Должно обновляться при каждой перезаписи объекта в соответствии с документацией 1С. > _Marked – пометка удаления объекта. > _PredefinedID – идентификатор объекта метаданных (для предопределенных элементов справочника). > _Code – код справочника. > _Description – наименование справочника. Достаточно несложно сделать вывод, какие поля справочника являются системными. Как видим, к ним относится и _Code (код), но оно не входит в основной кластерный индекс, следовательно, вполне может быть неуникальным.

Рисунок 1. Общий реквизит в 1С и его представление в физической модели БД

июнь 2016 системный администратор

Базы данных

изучаем 1С

Зная внутреннюю структуру таблиц СУБД, можно улучшить качество проектирования прикладных решений

А что же появится в SQL-профайлере после перезаписи элемента справочника? Примерно вот это:

У меня получился хороший пример, потому что в той же транзакции присутствуют еще и запросы вида:

UPDATE T1 SET _Marked = @P1, _PredefinedID = @P2, _Code = @P3, _Description = @P4 FROM dbo._Reference136 T1 WHERE (T1._IDRRef = @P5 AND T1._Version = @P6) AND (T1._Fld366 = @P7)

SELECT TOP 1 1.0 FROM dbo._Node12 T1 WHERE ((T1._Fld366 = @P1))

и SELECT T1._IDRRef FROM dbo._Node18 T1 WHERE ((T1._Fld366 = @P1))

Встречаем несколько неожиданных фактов: > При перезаписи элемента справочника, даже если в нем ничего не изменяли, происходит вызов update. > Update происходит всегда на все реквизиты справочника вне зависимости от того, какой менялся. > По полю _Version происходит отбор записей, а не их обновление. > Очень странный отбор по полю _Fld366 – это реквизит справочника. Почему же по нему происходит отбор? Он же должен обновляться по вышеописанной логике. Дело в том, что _Fld366 – это общий реквизит (см. рис. 1). По этому общему реквизиту включено разделение данных, и этот справочник разделен. Следовательно, его элемент может быть записан только в одну область данных, что и доказывает этот запрос. > Поле _PredefinedID тоже участвует в обновлении, следовательно, может быть обновлено. Не такие уж и предопределенные получаются «предопределенные элементы» справочника. Посмотрим, что еще происходит при записи элемента справочника. В той же транзакции видим: SELECT T1._PredefinedID FROM dbo._Reference136 T1 WHERE ((T1._Fld366 = @P1)) AND (T1._IDRRef = @P2)

Собственно, работа с предопределенными данными приводит к возникновению дополнительного запроса при каждой записи элемента справочника. Притом что в современной разработке на платформе 1С предопределенные элементы справочника стали, по сути, «дурным тоном».

системный администратор июнь 2016

А это что такое? Какое отношение имеет данная таблица к записи элемента справочника, да еще в одной транзакции? Это, конечно, будет не во всех базах, а только в тех, где существует действующий механизм регистрации изменений – так называемые планы обмена. Создание одного узла плана обмена в базе приведет к добавлению двух подобных запросов в транзакцию записи справочника. Поэтому нужно очень внимательно относиться к созданию новых узлов в плане обмена. Создание одной простой записи в таблице узлов планов обмена увеличивает транзакционную нагрузку на БД практически вдвое. Еще один запрос, который выполняется в транзакции обновления справочника: SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Params WHERE FileName = @P1 ORDER BY PartNo

где @P1 = ibparams.inf В официальной документации 1С, конечно, ничего не сказано о файле ibparams.inf, но путем нехитрых манипуляций можно посмотреть его содержимое и сравнить с окном «Администрирование – Параметры информационной базы» 1С (см. рис. 2). Итого, при каждой транзакции платформа 1С зачемто обращается к таблице Params к файлу ibparams.inf. Причины, почему эти параметры нельзя было бы хранить в кэше, неведомы. Можно только сделать простой вывод: таблицу Params нужно размещать на самые быстрые диски из доступных при разделении базы на файловые группы (вы же разделяете базу на файловые группы, правда?).

Базы данных Кроме перечисленных выше вызовов, при записи справочника мы увидим еще одну SQL-команду:

изучаем 1С

Табличная модель Регистр сведений

INSERT INTO dbo._UsersWorkHistory (_ID,_UserID,_URL,_Date, _URLHash,_DataSeparationUse367,_DataSeparationUse368,_Fld365, _Fld366) …

Это и есть то самое удобное нововведение – история работы пользователя. Технически это еще одна таблица, в которую происходит запись при любой модификации элемента справочника. Причем запись за два обращения (сначала update предыдущей записи, потом insert новой). Таким образом, при многопользовательской работе накладные затраты на поддержание данного механизма будут чудовищными. Отключить данный механизм никак нельзя. Радует одно, что он включается только при интерактивном изменении. С пониманием физической структуры БД приходит и понимание, что ничего особо хитрого нет и в прочих таблица на стороне СУБД.

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

Так же как справочник для объектной модели, регистр сведений является наиболее простым и понятным объектом метаданных объектной модели. В данном разделе речь пойдет сначала о непериодическом и не подчиненном регистратору регистре. Под табличной моделью в терминологии 1С подразумеваются все объекты, у которых нет системного реквизита «ссылка» и, как следствие, специфичного поля с GUID. Но кластерный индекс у регистров в 1С тем не менее обязательно присутствует. Для регистра он будет соответствовать набору его измерений. Что отличает регистр сведений от справочника – в таблице регистра сведений нет системных полей (не периодического, не подчиненного регистратору). Разве что то же самое поле общего реквизита, которое платформа 1С добавляет в любую таблицу, для которой этот реквизит прописан. Регистр сведений является, по сути, обычной таблицей СУБД. Измерения – первичный ключ и входящие в состав кластерного индекса поля, ресурсы и реквизиты – просто поля таблицы. Тем не менее, если мы откроем запись регистра и перезапишем ее (даже не изменяя), получим примерно следующую последовательность действий: > Читаем все поля из таблицы регистра – зачем это нужно, будет понятно далее. Я думаю, вы сильно удивитесь, узнав, зачем он нужен. SELECT T1._Fld6435, T1._Fld6436_TYPE, T1._Fld6436_L, ↵ T1._Fld6436_N,

Документ Документ интересен прежде всего своими дополнительными системными полями: > _Posted – проведен/не проведен. > _Date_time – дата документа. > _Number – номер документа. > _NumberPrefix – тип поля дата и время. Главным образом оно нужно для поддержки механизма МоментВремени в платформе 1С. В остальном поведение платформы при записи и проведении документа будет аналогично записи справочника.

План видов характеристик Работа платформы 1С с данным объектом метаданных, по сути, не отличается от работы с обычным справочником. Рисунок 2. Параметры информационной базы 1С и файл ibparams.inf

> Выбираем поле общего реквизита – нужно, видимо, для разделения данных. SELECT TOP 1 T1._Fld366 FROM dbo._InfoRg6434 T1

> Удаляем (!) запись из таблицы регистра. DELETE FROM T1 FROM dbo._InfoRg6434 T1

> Читаем параметры ИБ – ну а как же без них. SELECT Creation,Modified,Attributes,DataSize,BinaryData ↵ FROM Params

> Записываем прочитанные ранее данные во временную таблицу – непонятно, зачем временная таблица – может, дань последней моде 1С? INSERT INTO #tt2 (_Fld6435,_Fld6436_TYPE,_Fld6436_L

> Выбираем данные из временной таблицы. SELECT T1._Fld6435, T1._Fld6436_TYPE, T1._Fld6436_L, ↵ T1._Fld6436_N, T1._Fld6436_T, T1._Fld6436_S, ↵ T1._Fld6436_RTRef, T1._Fld6436_RRRef, T1._Fld366 FROM #tt2

июнь 2016 системный администратор

Базы данных

изучаем 1С > Делаем Insert – записываем данные в основную таблицу. INSERT INTO dbo._InfoRg6434 (_Fld6435, _Fld6436_TYPE, ↵ _Fld6436_L From #tt2

> Обновляем историю работы пользователя. Итого, запись регистра сведений происходит в восемь этапов, что намного больше чем у справочника. Несмотря на то что кластерный индекс у регистра составной, итоговое время на запись новой строки в регистр будет чуть меньше, чем время записи нового элемента в справочник. Кроме того, при записи регистра сведений в отличие от справочника не используется инструкция UPDATE, что делает перезапись элементов регистра несколько более трудоемкой операцией. При добавлении записи в регистр сведений последовательность действий происходит та же самая, но отсутствует конструкция DELETE, которая обычно бросается в глаза. Удаление записи происходит достаточно просто – всего три инструкции: выбрать общий реквизит, удалить запись, выбрать параметры ИБ.

ON T1._Period = T2._Period AND ↵ T1._Fld5951_TYPE = T2._Fld5951_TYPE…

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

Скорость создания и использования временных таблиц является решающим фактором производительности СУБД для платформы 1С:Предприятие Регистр бухгалтерии

Регистр накопления А вот перезаписать регистр накопления руками – это не очень просто. В отличие от регистра сведений все регистры накопления подчинены регистратору, поэтому записать их набор можно только программно или при проведении документа. Проделав это простейшее действие, посмотрим, что в итоге произойдет: > Первая фаза записи ничем особым не отличается от регистра сведений – несколько выборок, delete, insert – таким образом, происходит обновление записи регистра накопления. > Но в отличие от регистра сведений на этом транзакция не заканчивается, далее происходит следующее: » Получается наименьший период из записи регистра (через промежуточную временную таблицу, конечно): SELECT MIN(T1._Period) FROM #tt12 T1 WITH(NOLOCK)

» Создается отдельная временная таблица только с этим полем и кластерным индексом по нему. » Создается временная таблица с периодом рассчитанных итогов, если минимальный период текущей таблицы больше периода рассчитанных итогов. » Выбираются только те записи регистра, период которых больше периода рассчитанных итогов: …FROM #tt12 T1 WITH(NOLOCK) INNER JOIN #tt13 T2 WITH(NOLOCK) ON T1._Period < T2._Period

» Обновляется запись таблицы итогов примерно следующим образом: UPDATE T2 SET _Fld5957 = T2._Fld5957 + T1._Fld5957 FROM #tt14 T1 WITH(NOLOCK) INNER JOIN dbo._AccumRgT5958 T2

системный администратор июнь 2016

Отличается от регистра накопления, по сути дела, наличием еще двух видов таблиц: > _AccRgATxxxx – итоги по счетам с субконто. Этих таблиц будет столько же, сколько существует субконто у регистра бухгалтерии. Очевидным выводом будет, что по каждому субконто в регистре бухгалтерии итоги хранятся отдельно. > _AccRgEDxxxx – движения с субконто. В этой таблице просто записаны значения аналитики для каждой записи. Очевидно, что всю процедуру, описанную выше, в случае регистра бухгалтерии платформа 1С проделает столько раз, сколько определено субконто у регистра бухгалтерии, плюс обновление основной таблицы итогов, плюс обновление таблицы оборотов. Конечно, движения с субконто тоже будут записаны. В типовых конфигурациях, как правило, определено три субконто, соответственно при записи лишь одной строчки в регистр бухгалтерии будет произведена запись в шесть таблиц. Теперь, наверное, становится понятным, почему во всех рекомендациях 1С пишет о том, что запись в регистр бухгалтерии должна быть отложенной.

Таким образом, зная внутреннюю структуру таблиц СУБД, которую организует платформа 1С:Предприятие, и логику работы платформы с ними, можно существенно улучшить качество проектирования прикладных решений на платформе 1С:Предприятие, ориентируясь на увеличение их производительности и стабильности работы. EOF [1] Филиппов О. Под капотом платформы 1С 8.3. Часть 1. Работа с СУБД. // «Системный администратор», №5, 2016 г. – С. 3739 (http://samag.ru/archive/article/3192). Ключевые слова: 1C, СУБД, производительность, запросы.

Базы данных

изучаем 1С

Визитка

АЛЕКСАНДР ТЕТЮШЕВ, к.т.н., доцент кафедры АВТ Вологодского государственного технического университета (ВоГТУ), tetavv@gmail.com

1С в контейнере. Быстро и недорого Результаты тестирования локальной, файловой и клиент-серверной платформы 1С v8.3 в ОС Windows и Linux. Согласно тестам для групповой работы самой быстрой является клиент-серверная реализация 1С в Linux на базе контейнеров Docker

Вопрос о том, в какой конфигурации ставить новую версию 1С v8.3 для малого предприятия, мне задают столь часто, что в конце концов пришлось достать старый ноутбук и сделать несколько нагрузочных тестов производительности 1С в различных конфигурациях. Отмечу сразу, что для чистоты эксперимента ни в базах данных, ни на файловых системах не производились никакие оптимизирующие настройки. Тестирование производилось нагрузочным тестом Гилева – TPC-1С [1]. Результат этого небольшого эксперимента оказался не совсем ожидаемым. Согласно тестам для групповой работы самой эффективной стала клиент-серверная реализация 1C на базе контейнеров Docker.

Контейнерная виртуализация на основе Docker Немного теории о контейнерной виртуализации на базе Docker [2]. В реализации Docker следует различать четыре основных сущности. Первая сущность – образ. Для более легкого восприятия можно представлять образ как пакет или класс, на базе которого создаются готовые приложения (в нашем случае – контейнеры). Образ содержит окружение и необходимые библиотеки для запуска контейнера. Как правило, существует базовый образ, который скачивается с общедоступного регистра. На его основе создаются контейнеры или образы, которые формируют сами пользователи. Рисунок 1. Архитектура Docker

контейнер

Служба Docker (интерфейс управления) namespaces

cgroups

Драйвера ввода/ вывода

Linux ядро оборудование

selinux

Второй сущностью являются сами контейнеры. Сущность контейнера довольно интересна, поскольку часть окружения и доступ к системным библиотекам он получает от основной системы как обычный процесс, а часть окружения и библиотек получает из метаданных образа. Контейнер можно представить очень легкой «виртуальной машиной», без собственной ОС, поскольку все необходимые системные библиотеки он берет от основной системы, а вот внутри с помощью метаданных и библиотек образа создается специальное окружение для работы приложений, которые, в общем случае, отличаются от приложений основной системы. Таким образом, в контейнере могут работать программы, собранные и настроенные в другой ОС на базе Linux (с ядром не ниже 2.6). Более того, пользователи сами могут добавлять программы в работающий контейнер. Эти программы и настройки записываются «поверх» образа. Третья сущность – том. Грубо говоря, том – это смонтированная в контейнер директория основной системы, куда сохраняются все данные, полученные при работе контейнера. Если этого не сделать, после выключения контейнера вся информация, созданная в нем, будет потеряна. Четвертая сущность – линки. Это связь между контейнерами внутри сети. Отмечу, что все контейнеры запускаются в отдельной подсети и получают IP-адреса случайным образом. Линки позволяют прописать в связанных контейнерах их имена и IP-адреса для межсетевого взаимодействия. На рис. 1 показана архитектура контейнерной виртуализации на основе Docker. Служба Docker формирует и запускает по запросу пользователя контейнер с готовым системным окружением. Взаимодействие между клиентом на стороне пользователя и контейнером Docker осуществляется через сокеты или RESTful API [3]. При запуске контейнера служба Docker использует пространство имен (namespaces) для изоляции контейнера и назначения ему выделенного идентификатора (PID). Контрольные группы (cgroups) используются для раздельного доступа к аппаратным ресурсам хостовой системы и определения ограничений. SELinux контролирует доступ к данным контейнера.

июнь 2016 системный администратор

Базы данных

изучаем 1С

Причина победы Linux в нашем тесте кроется именно в контейнерной организации сервера 1C

Клиент-серверная реализация 1C в контейнере Установка Docker для CentOS 7 x86_64 ничем не отличается от установки обычных служб. Мы устанавливаем и запускаем сервис Docker и локальный регистр для сохранения созданных образов: # yum install docker docker-registry –y # systemctl enable docker; systemctl start docker

В том случае, если сеть предприятия находится за проксисервером, нужно дополнительно настроить Docker для работы по протоколам HTTP и HTTPS через прокси. Как оказалось, системные настройки им не подхватываются. Для работы Docker по протоколу HTTP создаем файл /etc/system/system/docker.service.d/http-proxy.conf с содержимым:

//база данных PostgreSQL для 1С # docker pull temrdm/1c_postgres //сервер 1с v8.3 # docker pull temrdm/1c_server

Просмотр скачанных образов: #docker images

Схема развертывания сервера 1C на основе контейнеров Docker показана на рис. 2. Порядок конфигурирования и запусков контейнеров следующий: первоначально конфигурируется и запускается контейнер базы данных – 1с_postgres. Далее запускается контейнер 1с_server, в котором собран готовый сервер 1С. Между контейнерами организуем линк.

Конфигурируем и запускаем контейнер 1с_postgres [Service] Environment="HTTP_PROXY=http://proxy.local.ru:3128/" ↵ "NO_PROXY=localhost,127.0.0.1"

и файл для работы по протоколу HTTPS /etc/system/system/ docker.service.d/https-proxy.conf с содержимым: [Service] Environment="HTTPS_PROXY=http://proxy.local.ru:3128/" ↵ "NO_PROXY=localhost,127.0.0.1"

#docker run -d --name 1c_postgres -p 5432:5432 ↵ --restart=always -v /var/lib/postgres/data: ↵

Рисунок 2. Схема развертывания контейнеров Docker

Сетевой стек хостовой операционной системы 1560‐1590

1540‐1541

Перегружаем system, чтобы принялись изменения: 1540‐1541

1c_server

link

# systemctl daemon-reload

5432

/var/lib/postgres/data

Скачиваем два базовых образа, на основе которых будем конфигурировать наши контейнеры:

системный администратор июнь 2016

volume

1c_postgres volume

# docker search 1с

1c_server_data

volume

Ищем готовые образы Docker на сервере по адресу www.docker.io:

1560‐1590

5432

/home/1cv8user

/var/log/1c

Хостовая операционная система

Базы данных

изучаем 1С

/var/lib/postgresql/data -e POSTGRES_PASSWORD=postgres ↵ -h data.local.ru temrdm/1c_postgres

В данном случае мы запускаем контейнер из образа temrdm/1c_postgres c опцией автоматической перезагрузки (--restart=always) в режиме службы (-d), пробрасываем порт 5432 между контейнером и хостовой машиной (-p 5432:5432), где первое значение – порт хостовой машины, второе – порт контейнера, создаем том /var/lib/postgres/ data и монтируем его в контейнер (теперь все данные базы данных сохраняются на хостовой машине и в случае выключения контейнера они не потеряются), задаем переменную среды POSTGRES_PASSWORD, определяющую пароль администратора postgres в базе данных и, наконец, даем имя контейнеру –h data.local.ru. Проверяем проброшенные порты:

в случае отказа (--restart=always), в режиме службы (-d) и окружением из ранее созданного контейнера (--volumes-from 1c_server_data), пробрасываем два пула портов между контейнером и хостовой системой (-p 1540:1541 и -p 1560:1591), создаем и монтируем в контейнер том в режиме только чтения (-v /etc/localtime:/etc/localtime:ro), связываем его с уже запущенным контейнером 1с_postgres и задаем имя srv.local.ru. Проверка всех работающих контейнеров: #docker ps

Подключение к работающему контейнеру 1c_server: #docker exec -it 1c_server /bin/bash

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

# docker port 1c_postgres

Проверяем работу базы данных PostgreSQL. Создаем тестовую табличку и смотрим, появилась ли она в списке таблиц базы данных: -h localhost -U postgres -d postgres ↵ -c "CREATE TABLE tmp (some_id serial PRIMARY KEY, ↵ some_text text);" //интерактивный вход в базу данных #psql -h localhost -U postgres // просмотр таблиц Psql> \l

# psql

Конфигурируем и запускаем контейнер 1c_server Создаем контейнер с именем 1с_server_data c данными окружения для сервера 1С: # mkdir /home/usr1cv8; mkdir /var/log/1c # docker create --name=1c_server_data -v /var/log/1c -v /home/usr1cv8/ temrdm/1c_server

↵

Это контейнер с окружением для сервера 1С и смонтированными томами /var/log/1c и /home/usr1cv8. В этих директориях хранятся информация о созданных базах 1С и логи сервера. Этот контейнер не запускается. Он служит хранилищем окружения сервера 1С. Конфигурируем и запускам контейнер 1с_server: #docker run --name=1c_server --restart=always -d ↵ --volumes-from 1c_server_data ↵ -v /etc/localtime:/etc/localtime:ro ↵ -p 1540-1541:1540-1541 -p 1560-1591:1560-1591 ↵ -h srv.local.ru --link=1c_postgres temrdm/1c_server

В данном случае мы запускаем контейнер из образа temrdm/1c_server с функцией автоматического рестарта

Тестирование производительности 1С Немного об оборудовании, на котором проводилось тестирование. В качестве испытательного полигона использовался ноутбук HP Pavilion dv2000 в конфигурации (см. таблицу 1). Жесткий диск ноутбука был разбит на два раздела. На первом установлена ОС MS Windows 2008 R2 x64, а на втором – CentOS 7 x64. Клиентами служили компьютеры под управлением MS Windows 7 и PCLinuxOS в локальной сети. Обе рабочие станции имели одинаковые характеристики. Как нетрудно заметить, слабым местом ноутбука является пропускная способность сетевого адаптера. Другими словами, производительность локальной конфигурации 1С теоретически должна быть существенно выше реализации на основе сетевого взаимодействия. Более того, ограничения сетевого адаптера могут привести к тому, что при тестировании производительность сетевых конфигураций 1С для различных конфигураций может оказаться практически одинаковой. Чтобы сгладить недостаточную пропускную способность сетевого адаптера, на основных системах были добавлены виртуальные машины VirtualBox [4], и все сетевые конфигурации еще раз тестировались в них. В этом случае сетевой адаптер практически не оказывал влияние на ход тестирования.

1. Локальная конфигурация Windows и Linux Отправной точкой послужили «классическая» схема установки толстого клиента 1С и локальная база данных. Скорость работы в однопоточном режиме, как и ожидалось, оказалась максимальной в среде Windows. Это достаточно легко объясняется более быстрой файловой системой NTFS в Windows по сравнению c XFS на Linux.

Таблица 1. Оборудовании, на котором проводилось тестирование Компонента

Центральный процессор

Оперативная память

Жесткий диск

Сетевой адаптер

Оборудование

Intel® Core™ 2 Duo T5500

2 x 2048 DRAM2 (2 потока)

SATA I

Ethernet 10/100BT

Теоретическая пропускная способность

1.5GHz * 64bit = 96000 Mbit/s

667MHz * 64bit * 2 = 85376 Mbit/s

SATA I = 1200 Mbit/s

LAN100 = 100 Mbit/s

июнь 2016 системный администратор

Базы данных

изучаем 1С

2. Сетевая файловая реализация Windows и Linux Тестирование проводилось с рабочей станции в локальной сети, на которой был установлен толстый клиент 1С. При этом ноутбук использовался как файловый сервер. При реализации сетевой конфигурации 1С для Windows 2008 использовался родной протокол SMB2, а для Linux – протокол CIFS (SMB1) (протокол NFS сразу был отброшен как «не надежный» в плане работы с 1С). Результат тестирования оказался интересным. Производительность 1С в случае Linux (SMB1) оказалась существенно выше Windows (SMB2). Более того, для Linux-сервера она превысила производительность локальной конфигурации, что вызвало дополнительное желание проверить эти конфигурации через VirtualBox.

3. Сетевая клиент-серверная реализация на базе MS SQL в Windows и PostgreSQL в Linux Для проверки клиент-серверного взаимодействия в Windows Server 2008 была установлена нативная база данных MS SQL 2008 R2 Express Edition, а в Linux – контейнеры Docker c базой данных PostgreSQL в конфигурации для работы с 1С и сервером 1С:Enterprise Server v8.3. Подключение к серверу проводилось с рабочей станции по локальной сети. Результат показал подавляющее превосходство реализации 1C на контейнерах Docker вне зависимости от операционной системы клиента (реально клиент на базе Windows оказался чуть производительнее).

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

Результат тестирования Результат тестирования показал, что производительность локальной реализации 1С на базе MS Windows не имеет себе равных.

С другой стороны, если говорить о групповой работе c выделенным сервером, предпочтительным будет реализация сервера 1С в контейнерах Docker на сервере Linux c рабочими станциями под управлением Windows. На самом деле это неожиданный результат. Производительность сервера Linux оказалась существенно выше классической реализации на Windows. Большинство источников показывает обратное. Например, [5] указывает на 45% превосходство нативной связки Windows + SQL над Linux + PostgreSQL. Но, возможно, основная причина победы Linux в нашем тесте кроется именно в контейнерной организации сервера 1C. Отличительной особенностью контейнеров Docker со стороны ОС заключается в том, что он полностью выполняется в одном процессе. В этом случае все процессы внутри контейнера заменяются потоками, и межпроцессное взаимодействие между процессами (потоками) приложения становится гораздо более быстрым. База данных внутри контейнера работает быстрее, чем при нативной установке. Такая же замена происходит с процессами сервера 1С. Возможно, «тест Гилева» не является достаточно точным и необходимо более глубокое тестирование по методике APDEX, но основное резюме этой статьи в том, что проект Docker постепенно перестает быть игрушкой и все больше напоминает универсальное средство корпоративного развертывания приложений. Основная идея Docker – развертывание контейнера в одном процессе существенно ускоряет «тяжелые» сервисы, такие как базы данных или серверы приложений. При этом накладные расходы виртуализации становятся просто ничтожными по сравнению с выигрышем от межпроцессного обмена внутри потоков контейнера. EOF [1] Конфигурация тестирования 1С 8.3 – http://www.gilev.ru/ tpc1cgilv. [2] Проект Docker – https://www.docker.com. [3] REST – https://ru.wikipedia.org/wiki/REST. [4] Oracle VirtualBox – https://www.virtualbox.org. [5] Сравнение производительности 1С при использовании СУБД PostgreSQL и MS SQL – http://efsol.ru/articles/performance-1spostgre-ms-sql.html Ключевые слова: Docker, 1C, Linux, тест, производительность.

Таблица 2. Тестирование 1С Реализация

Однопоточный синтетический тест производительности TCP-A-local Throughput

Рекомендованное количество пользователей

Локальная конфигурация Linux/Windows

18,87/24,64

Сетевая файловая реализация Linux+CIFS / Windows+SMB

21,83*/12,31

Сетевая файловая конфигурация Linux /Windows через VirtualBox

18,08/12,25

Сетевая клиент-серверная конфигурация Linux + PostgreSQL /Windows + MS SQL

13,11*/12,35

Сетевая клиент-серверная конфигурация Linux+PostgreSQL /Windows+MS SQL через VirtualBox

14,04 /11,88

Максимальная скорость 1 потока, Кб/с

Максимальная скорость обмена, Кб/с

56*/14

14 247*/16 054

28 865*/28 497

49/14

16 832/14 208

30 795/27 359

* Сервер CentOS 7 запускался без графического интерфейса

системный администратор июнь 2016

Разработка

событие

Визитка КИРИЛЛ СУХОВ, веб-программист в дистрибьюторской компании MICS. Занимается проектированием и разработкой различных интернет-сервисов. Круг интересов: веб-технологии, RIA, Framework-среды, sukhov-kirill@yandex.ru

Грядет DevConf 2016 17-18 июня в Москве, в Сколково, пройдет DevConf 2016 – профессиональная конференция, посвященная ведущим технологиям программирования и веб-разработки

Отраcль, в которой мы работаем, – веб-разработка – все еще довольно молодая. Но в ней уже успели сложиться некоторые добрые традиции, одной из которых, конечно, является ежегодно проводимая конференция DevConf. DevConf – конференция профессиональных веб-разработчиков – проходит с 2010 года. Впрочем, ее история начинается еще раньше – с PHPConf начала 2000-х. С тех пор этот форум стал, без всяких «пожалуй», самым заметным событием года для российских программистов, использующих самые разные средства (PHP, Ruby, Python, JavaScript, etc). На DevConf специалисты всегда имеют возможность пообщаться непосредственно с разработчиками используемых технологий, а зачастую прямо с их создателями. Среди докладчиков конференции были Расмус Лендорф (Rasmus Lerdorf, создатель языка PHP), Майкл «Монти» Видениус (Ulf Michael Widenius, основатель MySQL) и много других известных специалистов, приезжавших в Москву со всего мира. Самое ценное в DevConf – это, наверное, возможность разработчиков, работающих с разными технологиями, узнать, что нового и интересного происходит у коллег. Программисты на PHP и Ruby, на Golang и JavaScript, Python и Lua обмениваются здесь опытом и идеями. Команда DevConf ставит себе цель попытаться разрушить стены, выстроенные между платформами и их адептами. Участникам мероприятия предоставляется уникальная возможность получить доступ сразу ко всем лидирующим технологиям вебразработки! DevConf 2016 включает семь конференций: > DevConf::PHP(), DevConf::Python(), DevConf::Ruby() и DevConf::JavaScript() – «языковые». > DevConf::Storage() – посвящена хранилищам данных, > DevConf::DevOps() – интеграционной методологии разработки ПО, > DevConf::Common() – всему остальному. Что нас там ждет? Постараюсь частично объять необъятное и кратко рассказать о некоторых темах предстоящего мероприятия.

Секция PHP В секции PHP больше всего интереса вызывают доклады, посвященные новой ветке языка – php-7.*. Впрочем, не такая уж она и новая – с декабря прошлого года это уже стабильный релиз. Сейчас актуальна версия PHP 7.0.6, но вот с переходом на новую ветку, несмотря на все ее преимущества, большинство команд разработчиков не особо торопится. Причины этому очевидны – в основном это опасения по поводу стабильности работы и функциональности различных библиотек и расширений. В связи с чем многим будет интересен доклад Юрия Насретдинова, старшего разработчика социальной сети Badoo, с интригующем названием «Как Badoo перешли на PHP7 и сэкономили $1M». Будет рассказано, как одна из крупнейших социальных сетей перешла на PHP7, с какими трудностями столкнулись программисты, как с ними справились и какие результаты получили. Теперь серверы Badoo работают на PHP7, и он действительно готов к промышленному использованию, стабилен, потребляет значительно меньше памяти и дает хороший прирост производительности. Разработчики PHP не собираются останавливаться на достигнутом, и свидетельство тому – доклад Дмитрия Стогова, ведущего инженер Zend Technologies, лидера проекта PHPNG, легшего в основу PHP-7, «Развитие ветки PHP-7*». Дмитрий расскажет о новшествах в грядущем PHP-7.1 и о планах на PHP-7.2. Александр Макаров, один из основных разработчиков PHP-фреймворка Yii и его представитель в PHP-FIG, выступит с докладом «Безопасность: от базовых принципов до особенностей PHP». Он предназначен для разработчиков и построен Александром по результатам code review различных проектов, в которых встречались одни и те же проблемы с безопасностью. Планируется начать с общих принципов, углубиться в особенности PHP и пройтись по типичным ошибкам настроек окружения. Интересны доклады Кати Маршалкиной о новой версии CMS Drupal, теперь основанной на фреймворке Symfony, Александра Календарева «Hack – следующее поколение

июнь 2016 системный администратор

Разработка

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

Секция Storage В секции Storage в этом году, похоже, очередной виток дружеского противостояния MySQL vs PostgreSQL – и подтверждение тому предстоящий доклад «Крылья, ноги и хвосты: сильные стороны MySQL и когда PostgreSQL завоюет мир» известного специалиста Алексея Копытова. Его выступление обещает быть мощным ответом на критику некоторых аспектов работы MySQL со стороны PostgreSQLсообщества. Впрочем, MySQL помогают союзники. Сергей Петруня – разработчик, член команды MariaDB – представляет доклад «MariaDB 10.1 – что нового», в котором расскажет об основных нововведениях это участника MySQL-клана, таких как оптимистичная параллельная репликация или улучшения в оптимизаторе вроде EXPLAIN FORMAT=JSON. Подробнее о последнем формате расскажет в своем докладе Света Смирнова (Percona). О том, что нового в самой MySQL, мы узнаем из выступления Дмитрия Ленева (Oracle) «Новые возможности MySQL 5.7». Что касается PostgreSQL, то Александр Алексеев и Павел Лузанов из Postgres Professional и Фролков Иван расскажут о новых возможностях этой СУБД для разработчиков приложений. Хотя хранилища данных для веб-разработки – это не только MySQL и PostgreSQL, но два доклада – «Обзор Tarantool DB» Василия Сошникова и «Мастер-мастер репликация в Tarantool» Константина Осипова – расскажут об этой набирающей популярность разработке устами ее создателей.

Секция JavaScript Язык JavaScript верно и не очень медленно завоевывает мир. Ну, по крайней мере. мир веб-разработки. От этой технологии никуда не спастись – ни на клиенте, ни на сервере, ни на DevConv. Секция js на конференции очень сильная и насыщена интересными докладами: > «Инфраструктура распределенных приложений на nodejs» (Станислав Гуменюк, SEMrush), > «React Native, Relay и GraphQL – опыт в production» (Денис Измайлов, Startup Makers), > «Instant Content Everywhere» (Paul Bakaus, Google), > «Архитектура фронтенда в 2016» (Сергей Рубанов, MoscowJS), > и еще многими другими, не менее интересными.

Секция Common В секцию Common подано больше всего заявок на доклады. Будет разговор о таких языках программирования, как Lua, Rust, Golang, о таких интересных вещах, как Microsoft Bot Framework, Google AMPP, решение для мониторинга Prometheus, распределенная разработка, RabbitMQ, XDSD, HTTP/2, и обо всем, всем, всем… Ruby, Python, DevOps? Да, там тоже будет много интересного. Формат обзора не позволяет мне остановиться на этих секциях. С их содержанием можно ознакомиться на сайте DevConf : http://devconf.ru/ru/offers.

системный администратор июнь 2016

Мастер-классы Второй день конференции традиционно посвящен различным мастер-классам– решению какой-то конкретной задачи силами аудитории. Общение там, как правило, более живое, вопросы конкретнее, новую технологию можно попробовать и освоить под руководством опытных профессионалов. В этом году на мастер-классы поданы следующие заявки: «Производительность MySQL и работа с высокими нагрузками» Владимира Федоркова. Владимир – специалист по вопросам производительности LAMP-стека, в частности MySQL и Sphinx. Тема мастер-класса: конфигурация, тюнинг, построение запросов, работа с большими объемами данных и высокими нагрузками, поиск узких мест, тюнинг запросов и операционной системы, специфика эксплуатации MySQL в облаке. «Разработка кроссплатформенной библиотеки для iOS и Android» Sergey Lerg – разработчика из Corona Labs, участвует в разработке Corona SDK – фреймворка для создания кроссплатформенных 2D-игр и приложений. Решаемая задача – привести API выбранного SDK к универсальному виду, который бы одинаково работал с Objective-C и Java и идеально стыковался с уже написанным кроссплатформенным кодом. На этом мастер-классе будет показано, как создавать такие универсальные API и кроссплатформенные библиотеки, облегчающие жизнь разработчикам. «Построение эффективной команды и налаживание процесса разработки» Александра Смирнова – основателя клуба разработчиков PHPClub.ru, один из основателей DEVCONF. Будет откровенный разговор о командообразовании и налаживании процесса разработки. Опыт работы в компаниях FranceTeleсom, РБК, «Бегун», «ГдеЭтотДом» и других позволяет сказать: ему есть чем поделится. «Беспроблемная эксплуатация PostgreSQL» Дмитрия Васильева – инженера в компании Postgres Professional. Он собирается показать, как сделать так, чтобы PostgreSQL был производительным и отказоустойчивым. «GraphQL и Relay» Вячеслава Слинько. Этот мастеркласс поможет начать использовать GraphQL и Relay очень интересные, но довольно сложные технологии. Вячеслав – руководитель группы front-end-разработки в ЦИАН Групп, с большим опытом работы со стеком от компании Facebook – React, GraphQL, Relay, Flow, etc. «Модифицируем язык запросов MySQL и улучшаем производительность с помощью Query Rewrite Plugins» Светы Смирновой – инженера технической поддержки MySQL с более чем 10-летним стажем, автора книги «MySQL Troubleshooting». На мастер-классе Света научит инсталлировать и использовать Query Rewrite Plugins. Будет совершенно новая команда SQL, и MySQL ее выполнит! «Разработка крупного масштабируемого Web 2.0 проекта с нуля (соцсеть на 100 млн пользователей)» Дмитрия Бородина – одного из самых известных российских разработчиков высоконагруженных систем, программиста и архитектора ПО, одного из трех основателей компании Topface. Мастер-класс посвящен разработке архитектуры любого типичного большого проекта. На момент написания обзора окончательная программа DevConf 2016 еще не была утверждена. Возможны изменения и сюрпризы. Я уверен – исключительно приятные. Сайт конференции – http://devconf.ru/ru. EOF

Разработка

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

Визитка

АЛЕКСАНДР МАЙОРОВ, Tutu.ru, руководитель отдела Frontend-разработки, alexander@majorov.su

AMP от Google Ускоряемся и взлетаем в выдаче Сейчас все уже привыкли к широкополосному интернету без ограничений. Браузеры позволяют реализовывать сложные технологические решения. При этом актуальна проблема медленного интернета и интернета в роуминге, про которую забывают порой веб-разработчики. Разбираемся с новой технологией от поискового гиганта

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

Эти три магические буквы AMP расшифровывается как Accelerated Mobile Pages (AMP) – это новый формат открытого типа, созданный на базе существующих веб-технологий, позволяет создавать облегченные версии стандартных веб-страниц. Проще говоря, это технология ускорения работы веб-страниц на мобильных устройствах. В первую очередь для оптимизации и ускорения загрузки контентных страниц (т.е. статей, новостей, обзоров, фото/видео и т.д.). Это тот же самый HTML, но специально оформленный по определенным правилам. Рендеринг страницы осуществляется с помощью скрипта AMP runtime, который берет на себя оптимизацию рендеринга. AMP представляет собой специальную библиотеку для разработчиков, валидатор и технологию отображения страниц в выдаче Google. Разработчики в Google считают, что производительность веб-страницы существенно зависит от числа JavaScriptкода разнообразных библиотек, реализующих различную динамическую функциональность (и я с ними согласен в этом утверждении). Вместо явного или неявного использования JavaScript для таких элементов, как, к примеру, фотогалереи или блоки комментариев, разработчикам предлагается использовать готовые веб-компоненты, специально разработанные для библиотеки AMP HTML. Список таких компонентов пока не очень велик, но он будет дополняться. Они разрабатываются таким образом, что JavaScript-код этих компонентов не должен существенно влиять на производительность вебстраниц. Говоря другими словами, при использовании разметки AMP HTML на страницу накладывается ряд ограничений, таких как запрет на использование любых JavaScriptскриптов, кроме самой библиотеки AMP и ее расширений.

Также необходимо использовать особые элементы AMP вместо привычных. К примеру, для отображения изображений следует использовать тег amp-img вместо стандартного img. Нельзя вставлять свои слайдеры для фотографий – для этого же есть специальный компонент. А чтобы посмотреть полноразмерную фотографию при клике на картинку, надо использовать версию лайтбокса от Google, а не компоненты, написанные на всеми любимом jQuery. Это сделано для нас. AMP сам определит, какую картинку в каком разрешении нужно отдать пользователю, причем отдаст ее со своего CDN, а не с вашего сервера. Кстати, такой подход вполне может еще и снять нагрузку с вашего сайта, так как вместо того, чтобы зайти к вам на сервер, пользователь получит страницу с серверов Google. Вышеперечисленные ограничения проверяются специальным валидатором, включенным в библиотеку AMP. Добавив к адресу страницы #development=1, можно получить в браузерной консоли разработчика статус страницы и увидеть ошибки разметки.

Компоненты AMP Формат AMP – это не только высокая скорость загрузки страниц. Разработчики хотят, чтобы людям было приятно и удобно читать статьи. Публикации должны одинаково хорошо загружаться на всех устройствах и платформах. К примеру, статья, написанная в России, должна быть мгновенно доступна для чтения в Белоруссии или Казахстане. Google разработал новый подход к кэшированию, который позволяет размещать контент и в то же время эффективно распространять его, используя высокопроизводительные глобальные кэширующие CDN. Технология состоит из трех основных составляющих: > Библиотека компонентов AMP HTML > AMP JS Library > Google AMP Cache Попасть на AMP-версию можно двумя способами: > По прямой ссылке на AMP-версию > По поисковому запросу в Google

июнь 2016 системный администратор

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

От теории к действию Достаточно теории, давайте сделаем каркас AMP-страницы. Он может выглядеть так: <!doctype html> <html ⚡> <head> <meta charset="utf-8"> <link rel="canonical" href="hello-world.html"> <meta name="viewport" content="width=device-width,initial-scale=1, ↵ minimum-scale=1,maximum-scale=1, ↵ user-scalable=no,minimal-ui"> <script src="https://cdn.ampproject.org/v0.js" ↵ async></script> <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript> </head> <body> <h1>Hello World!</h1> </body> </html>

системный администратор июнь 2016

Разработка Что здесь необычного. Во-первых, мы используем нестандартное определение тега <html>. Можно использовать как версию с символом <html ⚡> , так и версию <html amp>. Кстати, молния – это логотип данной технологии. В поисковой выдаче страницы AMP помечаются таким символом. Основные требования к страницам: > Обязательное определение вьюпорта. > CSS содержится внутри HTML-страницы и только в одном месте. Размер CSS ограничен разработчиками размером до 50 Кб. > Отсутствие JavaScript (кроме разрешенного). > Для всех внешних ресурсов сразу задаются размеры. > Все скрипты должны загружаться асинхронно (атрибут async обязателен). > Нельзя использовать <script>, <base>, <frame>, <frameset>, <object>, <param>, <applet>, <embed>. > На сегодня нельзя использовать теги <form> и <input>, но, возможно, их поддержка будет добавлена в будущем. Можно использовать тег <button> для генерации событий через атрибут on. > Вместо <img>, <video>, <audio> и <iframe> следует использовать аналогичные <amp-img>, <amp-video> и так далее… > Тег <link> можно использовать только для микроразметки с атрибутом rel. > Тег <a> со ссылкой на внешнюю страницу обязан содержать target="_blank".

Разработка > Запрещено использовать условные комментарии. > Запрещено использовать атрибуты событий (onClick, onChange и так далее…). > Внутри стилей нельзя применять: » универсальный селектор * и :not() » overflow: scroll, overflow: auto » filter » !important > Нельзя делать автоматически скролящиеся блоки. В результате применения всех этих правил происходит минимум пересчетов расположения элементов на странице, что и влияет на скорость отображения страниц. Для правильной индексации требуется: > Обязательно наличие тега <link rel=”canonical”> на AMP-странице. > Теги <link rel=”amphtml”> на других версиях этой страницы (десктопной, мобильной). > Микроразметка (Schema.org).

АМР-компоненты Список основных AMP-компонентов: > amp-ad – контейнер для отображения рекламы; > amp-img – замена тега img; > amp-video – замена HTML5-тегу video; > amp-audio – замена HTML5-тегу audio; > amp-iframe – замена iframe; > amp-pixel – невидимый пиксель – счетчик посещений; > amp-anim – анимированное изображение (GIF); > amp-carousel – обыкновенная карусель (отображение превью картинок, выстроенных по горизонтали); > amp-fit-text – автоматическое уменьшение или увеличение размера шрифта текста, для того чтобы он поместился в ограниченную область; > amp-image-lightbox – полноразмерный просмотр большого изображения при клике на превью или ссылку; > amp-instagram – отображает пост в Instagram.com; > amp-twitter – отображает твит; > amp-youtube – отображает видео с YouTube.

Я хочу добавить свой JS, как быть? Тут есть только один выход на сегодня – это iframe-блоки. В них можете загрузить что угодно. Но есть одно важное «НО»! Показывать iframe на первом экране вы не можете. Этого делать нельзя. Также не получится сделать полностью AMP-страницу из одного фрейма. Такая страница не пройдет валидацию и не попадет в AMP Cache. Если вам нужно вставить рекламу, то для этих целей есть специальный тег – amp-ad. Он позволяет вставить рекламный блок на страницу, используя одну из поддерживаемых рекламных сетей: AdSense, Doubleclick, A9, AdReactor, AdTech. Таким образом, Google получает дополнительный контроль над рекламой на сайтах.

Работа с событиями без единой строчки на JavaScript AMP позволяет работать с событиями, но через свой собственный механизм. К примеру, вы хотите добавить кнопку, по нажатию на которую будет открываться картинка. Для этого добавляете на страницу тег кнопки и прописываете

веб-технологии атрибут on="…" , в котором указываете, какое событие надо вызвать (но не JavaScript). Добавим на страницу компонент Lightbox. Для этого нам нужно подключить компонент через тег <script customelement>. Если этого не сделать, валидатор обязательно сообщит об ошибке. Далее прописываем действие на кнопку в теге button: <button on="tap:my-lightbox">Show image</button>

Финальный код нашей страницы выглядит так: <!doctype html> <html ⚡> <head> <meta charset="utf-8"> <link rel="canonical" href="hello-world.html"> <meta name="viewport" content="width=device-width,initial-scale=1, ↵ minimum-scale=1,maximum-scale=1, ↵ user-scalable=no,minimal-ui"> <script async src="https://cdn.ampproject.org/v0.js"> ↵ </script> <script async custom-element="amp-lightbox" ↵ src="https://cdn.ampproject.org/v0/ ↵ amp-lightbox-0.1.js"></script> <style> </style> </head> <body> <h1>Hello World!</h1> <button on="tap:my-lightbox">Show </button> <amp-lightbox id="my-lightbox" layout="nodisplay"> <div class="lightbox"> <amp-img src="http://www.innovationmanagement.se/ ↵ wp-content/uploads/2014/08/image1.png" ↵ width=460 height=330 ↵ on="tap:my-lightbox.close"> </div> </amp-lightbox> </body> </html>

Без использования JavaScript мы написали событие и привязали его к действию. Так же добавили событие на закрытие прямо на саму картинку. Достаточно тапнуть/кликнуть на нее.

Какой профит? Для SEO это неоспоримое преимущество, так как AMPстраницы отображаются в верхнем «слайдере» в выдаче. Происходит улучшение позиций в выдаче Google (так называемый AMPing up). Пользователи охотно переходят по таким страницам. Как следствие, происходит увеличение конверсии и уменьшение показателя отказов (27% и 56% за 1 с, по данным исследования SOASTA). На сегодня в гугловскую карусель мобильной выдачи попадают категории сайтов Article и Video. Но эти категории планируется расширять. К примеру, сайт Samag.ru идеально подходит под эту технологию. Мы в нашей компании уже применили эту технологию на контентных страницах. EOF [1] Страница на GitHub – https://github.com/ampproject/amphtml. [2] Сайт проекта AMP – https://www.ampproject.org. Ключевые слова: google, amp, технологии, веб.

июнь 2016 системный администратор

Разработка

мобильные приложения

Визитка

АНДРЕЙ ПАХОМОВ, Android-разработчик, mailforpahomov@gmail.com

Широковещательные сообщения в Android О важных системных событиях ОС информирует все заинтересованные приложения с помощью рассылки широковещательного сообщения. Разберем, как реагировать на системные сообщения и создавать свои

Android – большая и сложная ОС с множественными компонентами, в которой всегда одновременно выполняется несколько процессов. В работающей системе постоянно происходят события, которые могут быть интересны другим приложениям, а в некоторых случаях информация о наступающем событии может быть критически важна – например, о том, что поступило новое СМС-сообщение или что устройство вообще будет выключено через несколько секунд. Для обработки таких системных широковещательных сообщений разработчику доступен компонент broadcast reciever – дословно «получатель широковещательных сообщений». В прошлый раз наш журнал писал о паттерне Наблюдатель, который позволяет проинформировать группу объектов о наступивших событиях [1]. Как видите, это достаточно распространенная задача, которая часто бывает уже наполовину решена создателями API-разработки: так, в Java есть специальные лассы Observer и Observable, а в Android существует механизм массовой рассылки сообщений (см. рис. 1). Рисунок 1. Компоненты Android-приложения

Системные сообщения В Android несколько десятков ситуаций, о наступлении которых ОС обязательно уведомит всех желающих широковещательным сообщением – от подключения наушников до отключения зарядного устройства. Чтобы понять, как с ними работать, разберем одно из них – добавим приложение в автозагрузку, подписавшись на рассылку соответствующего сообщения. В отличие от Windows или Linux в Android нет конфигурационных файлов, куда бы можно было прописать приложение для его автозагрузки при старте ОС. Это, конечно, было бы удобно, но противоречит существующей модели безопасности – приложения в Android максимально отделены друг от друга, поэтому наличие единого конфигурационного файла исключено. Тем не менее после того, как пользователь включит свой телефон или планшет на базе Android, часть приложений сразу же начинает свою работу без дополнительной команды от пользователя. Разработчики Android нашли элегантное решение проблемы отсутствия общих конфигурационных файлов – приложения теперь регулярно рассылают уведомления о наступающих событиях, позволяя немедленно на них реагировать. Установив Android SDK, разработчик найдет в нем весь список широковещательных сообщений. В случае когда устройство только-только будет загружено, ОС разошлет сообщение со следующим идентификатором: android.intent.action.BOOT_COMPLETED

Чтобы разработчики могли обрабатывать широковещательные сообщения, в стандартном AP создан класс BroadcastReceiver. Для его работы достаточно переопределить метод onRecieve, который и будет вызван системой после доставки сообщения о том, что ОС загружена. public class MyBroadcastReciever extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) {…}…

системный администратор июнь 2016

Разработка Как и в случае с любым другим Android-компонентом, получение сообщений начинается с внесения изменений в манифест-файл. Для получения возможности реагировать на загрузку ОС приложению необходимо получить соответствующее разрешение, оно указывается параметром usespermission. <uses-permission android:name= ↵ "android.permission.RECEIVE_BOOT_COMPLETED" />

Кроме этого, каждый компонент, получающий сообщение, должен быть также подписанным на рассылку. Самый простой способ – это внести запись там же, в манифесте. Компонент, обрабатывающий широковещательные сообщения, должен иметь соответствующую запись с тэгом intent-fitlter. <receiver android:name=".AutologinReciever" > <intent-filter><action android:name= ↵ "android.intent.action.BOOT_COMPLETED" /> </intent-filter></receiver>

Подписаться на сообщения можно и еще более элегантным способом – программно, без правки конфигурационных файлов. Это возможно сделать, сформировав объект класса Intent со строкой – идентификатором сообщения, на которое будет подписан компонент. Затем с помощью метода registerReceiver нужно связать необходимого получателя сообщений и созданный Intent. String SOME_ACTION = "broadcast.id"; IntentFilter intentFilter = new IntentFilter(SOME_ACTION); MyBroadcastReciever myReciever = new MyBroadcastReciever(); registerReceiver(myReciever, intentFilter);

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

Рисунок 2. Регистрация сервисов в манифест-файле

мобильные приложения Во избежание траты лишних ресурсов нужно быть внимательным к динамическому процессу регистрации и отписки от сообщений. Если метод registerReceiver вызывается в Activity.onResume(), то отписываться от сообщений стоит в методе Activity.onPause(). Нет смысла получать сообщения, если визуальные элементы, работающие с сообщениями, неактивны, а значит, не смогут их обработать.

Intent Работа с широковещательными сообщениями в полную силу связана с классом Intent, в чем мы сегодня убедимся. Это очень популярный в мире Android инструмент, помогающий создать запрос на запуск другого компонента приложения или стороннего процесса вообще. Объекты класса Intent используются повсеместно, например, для старта новых графических компонентов (Activity) или инструментов, предоставляемых ОС, – к примеру, фотокамер. Но при этом нужно помнить, что получение широковещательных сообщений и запуск Activity – принципиально разные механизмы, хотя и выполняются внешне очень похоже, с помощью вызовов одних и тех же методов. У получателей сообщений нет возможности «отловить» момент запуска новых элементов UI, а, в свою очередь, у Activity нет прямого доступа к сообщениям. Activity работают в главном потоке и взаимодействуют с пользователем, а широковещательные сообщения носят исключительно технический характер, и пользователь в идеале не должен о них знать.

Жизненный цикл Каждый получатель сообщений имеет свой жизненный цикл – объект этого класса будет жить ровно столько, сколько выполняется метод onReceive. На практике это означает, что в MyBroadcastReciever нет возможности организовывать многопоточные вычисления – новому потоку просто некуда будет вернуть результаты. То же самое распространяется и на процесс в целом. Если приложение было запущено автоматически при получении системного сообщения, то в созданном процессе не будет других объектов, кроме наследника BroadCastReciever. Поэтому процесс будет существовать ровно столько, сколько будет выполняться метод onReceive. Чтобы гарантированно выполнить полезные вычисления, компания Google рекомендует не экспериментировать, а просто запустить в методе onRecieve какой-нибудь сервис. Он позволит выполнить в фоне все необходимые операции – обновление почты, загрузку конфигурационного файла и многое другое. Сервис в Android создается несколькими способами – к примеру, с помощью одноименного класса Service. public class MyService extends Service { public MyService() {super();}

Каждый раз при инициализации сервиса выполняется метод onStartCommand, куда и следует разместить полезную нагрузку. Любопытно, что работать этот метод будет в том же потоке, который его и вызвал, поэтому для корректной работы хорошо бы самостоятельно создать новый поток. public int onStartCommand(Intent intent, int flags, ↵ int startId) {

июнь 2016 системный администратор

мобильные приложения

Разработка

Широковещательные сообщения – это удобный механизм коммуникации

new NewThread(); Toast.makeText(getApplicationContext(), ↵ "service started!",Toast.LENGTH_LONG).show(); stopSelf(startId); return super.onStartCommand(intent, flags, startId);}

Создание новых потоков в Android ничем не отличается от классических способов, давно применяемых Java-разработчиками. private class NewThread implements Runnable{ Thread t; public NewThread() {t=new Thread(this, "new thread"); t.start();}

Достаточно реализовать интерфейс Runnable, в нем – метод loadData и создать новый поток на основе класса Thread. После того как поток запустится методом start, он самостоятельно найдет метод run() и выполнит его. public void run() { loadData();} private void lo adData() { try {Thread.sleep(5000); Log.e("Service", "service was started!");...}

Сервисы – не менее важные компоненты в Android-мире, и каждый из них должен быть указан в манифесте приложения.

пользователем, тоже могут обмениваться ими (см. рис. 3). У каждого разработчика есть возможность самостоятельно генерировать сообщения как для компонентов внутри приложения, так и для других приложений, установленных на устройстве. Для отправки широковещательных сообщений, как и в случае с запуском сервиса или нового Activity, требуется сформировать Intent. В данном случае сформированный Intent будет содержать в себе только уникальный идентификатор сообщения и как опцию – полезную нагрузку в связке «ключ – значение». Intent intent = new Intent(); intent.setAction("com.sample.custom.broadcast"); intent.putExtra("Data", "string_from_broadcast");

Широковещательные сообщения на данный момент могут быть двух видов – обычные (normal broadcast) или управляемые (ordered broadcast). Совсем недавно, до API 21 версии, был доступен третий вид – привязанные сообщения (sticky broadcast), но они теперь считаются устаревшими и скоро окончательно не будут поддерживаться. Это связано с проблемами с безопасностью – к таким сообщениям доступ никак не ограничен. Рисунок 3. В Android более 150 системных широковещательных сообщений

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

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

системный администратор июнь 2016

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

мобильные приложения Работа с широковещательными сообщениями была бы не столь полезна без возможности самостоятельно «передвигать» компоненты в очереди на их получение сообщений. Для этого создан параметр android:priority, принимающий целочисленные значения в диапазоне от -999 до 999 включительно.

sendBroadcast(intent);

Управляемое сообщение придет каждому получателю по очереди, одно за одним. Главная особенность в том, что кто-то из цепочки получателей может модифицировать сообщение или вообще отменить рассылку. Таким образом, стоявшие за ним в очереди не увидят сообщения. Это может быть полезно: в приложении могут быть несколько получателей, и такой подход позволяет не тратить ресурсы зря, если сообщение не несет полезной нагрузки для остальных. Отправляется оно похожим способом, единственное отличие – наличие второго параметра, который будет указывать, какое дополнительное разрешение должно иметь приложение для получения таких рассылок. Но этот параметр можно не задавать, указав null. sendOrderedBroadcast(intent, "ordered_broadcast_permission");

Хорошим примером использования управляемых сообщений служит приложение – телефонный менеджер, которое при определенных условиях может менять номер вызываемого абонента. Когда пользователь стандартными средствами вызывает абонента, система создает управляемое сообщение с данными звонка. У разработчика есть возможность получить его первым среди других приложений и модифицировать вызываемый номер. Чтобы это осуществить, необходимо получить разрешение на получение таких сообщений и зарегистрировать получателя. <uses-permission android:name= ↵ "android.permission.PROCESS_OUTGOING_CALLS"/> <intent-filter> <action android:name= ↵ "android.intent.action.NEW_OUTGOING_CALL" /> </intent-filter>

Метод getResultData возвращает данные, которые возможно модифицировать в полученном сообщении, в случае с телефонным звонком это только номер вызываемого абонента, а для его перезаписи есть метод setResultData. String number =getResultData(); String newNumber="88005555550"; setResultData(newNumber);

Вся остальная информация о совершаемом звонке хранится в объекте intent, прочитать ее тоже несложно, но перезаписать эти данные, к сожалению, нельзя. Bundle resultExtras = intent.getExtras(); if (resultExtras != null) { for (String key : resultExtras.keySet()) { Log.i("OrdBrdc", "Result Extra key=" + key + ":" + ↵ resultExtras.get(key));}}

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

Безопасность При создании широковещательного сообщения нужно помнить, что оно распространится далеко за пределы выпустившего его приложения. Поэтому нужно быть очень внимательным при их построении. Вот несколько моментов, забыв о которых, можно получить приложение с очень серьезными уязвимостями. Класс Intent использует глобальное пространство имен. На практике это означает, что, создавая собственную рассылку, желательно задавать имя сообщения на основе названия пакета приложения. В противном случае велик риск случайно выпустить рассылку с именем, которое уже было использовано другим разработчиком в соседнем приложении. Как только компонент регистрируется на получение сообщений (в манифесте или с помощью метода registerReceiver), любое приложение, установленное на устройстве, может случайно доставить ему широковещательное сообщение. Поэтому разработчики Android предусмотрели несколько способов, позволяющих фильтровать отправителей и получателей сообщений.

Фильтрация получателей По умолчанию разосланное методом sendBroadcast(Intent) сообщение будет доставлено всем желающим, есть несколько способов, как можно сузить круг получателей. Формируя сообщение, разработчик указывает несколько критериев, которым в обязательном порядке должны соответствовать приложения-получатели.

июнь 2016 системный администратор

мобильные приложения Во-первых, сообщение можно адресовать только конкретному приложению, указав используя метод setPackage, в пакете с каким именем должен находиться объект-получатель. Intent intent2 = new Intent("broadcast.id"); intent2.putExtra("data", "test message"); intent2.setPackage("package.name"); sendBroadcast(intent2);

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

Разработка классом LocalBroadcastManager – это позволит урезать расход системных ресурсов. Локальные сообщения подходят для случаев, когда наступление событий маловероятно и не хочется нагружать код лишними связями во избежание утечек памяти из-за «забытых» объектов. Компонент, обрабатывающий сообщения, будет создан точно так же, как и раньше, – через класс BroadcastReceiver, только без указания идентификатора обрабатываемых сообщений. public class LocalReceiver extends BroadcastReceiver

sendBroadcast(intent, "permission_name"); sendOrderedBroadcast(intent, "permission name");

Регистрация в манифесте также обязательна, но указывать какие-либо параметры не нужно.

Подключаются такие разрешения абсолютно так же, как и системные, – с помощью тэга uses-permission.

<uses-permission android:name="permission_name"/>

Фильтрация отправителей Создавая получателя сообщений без указания каких-либо ограничений, разработчик получает компонент, который может быть вызван абсолютно любым сторонним приложением. Компонент можно сделать недоступным для любых рассылок от приложений извне (даже от ОС), поставив в манифесте соответствующую пометку. <receiver android:name=".OrderedBroadcast" android:exported="false">…

Если же все-таки необходимо получать сообщения от третьих лиц, то возможно ввести дополнительное разрешение. Компонент, получающий сообщение, нужно зарегистрировать, указав параметр android:permission. <receiver android:name=".ExternalBroadcastReciever" android:permission="com.localhost.more.restrictions">

Теперь приложения, которые захотят доставить широковещательное сообщение нашему компоненту, должны иметь вот такие разрешения в манифесте. Параметр permission указывает, что приложение будет обладать уникальным разрешением – такое разрешение может быть только у программ, подписанных одним и тем же сертификатом. Таким образом, широковещательное сообщение будет циркулировать только между приложениями одного издателя. <uses-permission android:name="com.localhost.more. ↵ restrictions"/> <permission android:name="com.localhost.more.restrictions"/>

Класс LocalBroadcastManager привяжет созданный компонент и ключ-идентификатор, по которому будет определяться отправитель сообщения. Теперь идентификатор может быть произвольным, поскольку сообщения гарантированно будут циркулировать только внутри приложения. LocalReceiver localReceiver = new LocalReceiver(); LocalBroadcastManager.getInstance(this). ↵ registerReceiver(localReceiver, ↵ new IntentFilter("com.example.localmessage"));

Сообщения создаются опять же с помощью класса Intent и его методов. Intent intent = new Intent("com.example.localmessage"); intent.putExtra("data", "local message"); LocalBroadcastManager.getInstance(getApplicationContext()). ↵ sendBroadcast(intent);

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

Мы достаточно подробно поговорили об одном из базовых компонентов в Android-мире, который незаменим при работе с системными событиями или созданными виджетами. Широковещательные сообщения – это удобный механизм коммуникации, позволяющий запускать длительные вычисления или информировать пользователя о новых событиях, разместив информацию в панели уведомлений. Для лучшего понимания материала на сайте журнала доступен более подробный исходный код рассмотренных в статье примеров. Если останутся какие-то вопросы, жду писем себе на почту. EOF

sendBroadcast(intent); LocalBroadcastManager

[1] Пахомов А. Пишем мобильные приложения быстрее. Паттерн Наблюдатель и реактивное программирование. // «Системный администратор», №5, 2016 г. – С. 44-47 (http://samag.ru/archive/ article/3194). [2] В папке с установленным SDK: platforms/android-Версия_API/ data/broadcast_actions.txt.

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

Ключевые слова: Android, широковещательные сообщения, разработка, мобильные приложения.

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

системный администратор июнь 2016

Разработка

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

Визитка

АЛЕКСАНДР МАЙОРОВ, Tutu.ru, руководитель отдела Frontend-разработки, alexander@majorov.su

Переменные в CSS без препроцессоров В статье рассмотрим новый механизм нативных переменных в CSS или, как правильнее, пользовательских свойств. Как они работают, какие особенности, примеры использования

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

Переменные или свойства? Официально они называются «Custom properties». Но также используется активно название «Native variables». Если вы программист, то точно хорошо знакомы с переменными и не можете себе представить жизнь без них. По определению переменная – это временное хранилище, которое содержит некое значение величины или информации. Переменной можно присвоить значение. Переменными можно оперировать и получать новые значения, которые, в свою очередь, присваиваются новой переменной. Идея использовать переменные для таблицы стилей была одной из тех причин, по которым появились препроцессоры LESSS, SASS, Compas… CSS-препроцессоры – замечательные инструменты, облегчающие работу верстальщиков, позволяя разбивать CSS на модули, задавать переменные и описывать пространства имен. Но переменные в них статичны, а на выходе препроцессора мы получаем все тот же статичный CSS с множеством повторяющихся кодов. К тому же переменные препроцессоров не каскадируются. А мы же работаем с каскадом стилей. При использовании переменных рано или поздно встает вопрос области видимости. Должна ли конкретная переменная быть глобальной, должна ли она ограничиваться своим файлом, модулем или блоком? Поскольку CSS оформляет HTML, то выходит, что лучший способ ограничивать область видимости – это на уровне DOM-элемента. А так как препроцессоры работают не в браузере и никогда не видят разметки, то им это недоступно.

Нативные CSS-переменные – совсем другой вид переменных. Главное их преимущество – они динамические, а их видимость привязана к DOM. Название «переменные» привычно для программистов, но оно сбивает с толку. На самом деле это CSS-свойства, что дает им совершенно другой спектр возможностей и позволяет им решать совсем другие задачи. Пользовательские CSS-свойства – такие же CSS-свойства, как и другие, и ведут себя они точно так же (с тем исключением, что они не применяют никакого оформления). Как и обычные CSS-свойства, пользовательские свойства динамичны: > можно менять во время выполнения; > можно обновлять в медиавыражении; > можно обновлять при добавлении нового класса в DOM > можно задавать inline; > можно перекрывать, пользуясь всеми правилами каскада; > они наследуются. Проще говоря, препроцессорные переменные ограничены статической областью видимости и после компиляции становятся статичными, в то время как видимость пользовательских свойств привязывается к DOM.

Синтаксис Синтаксис пользовательских свойств довольно прост, и освоить его не составит труда. Пример: --my-custom-property: #ff0a0c;

Важно помнить, что пользовательские свойства регистра зависимы, т.е. --my-custom-property и --My-Custom-Property – это два разных свойства. Простой пример использования пользовательских свойств: :root { --main-color: #ffa500; }

июнь 2016 системный администратор

Разработка

особенности языка #foo h1 { color: var(--main-color); }

--main-color – это определенное разработчиком пользовательское свойство со значением #ffa500 (оранжевый цвет). Все пользовательские свойства начинаются с двух дефисов. Функция var() возвращает значение свойства и заменяется им. Если свойство где-то определено в таблице стилей, оно будет доступно функции var. Хоть синтаксис прост, тем не менее он позволяет сделать довольно разнообразные вещи. К примеру, так выглядит пример валидного свойства: --some-condition: if(x > 8) this.width = 100;

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

Функция var() Как уже было сказано выше, чтобы получить значение пользовательского свойства, понадобится функция var(). Но эта функция принимает два аргумента. Ее полный синтаксис:

Доступ к свойствам через JavaScript Получить значение пользовательского свойства можно методом getPropertyValue() из объекта CSSStyleDeclaration. Аналогично, чтобы динамически менять значение, используется метод setProperty(). Также при задании значения можно использовать ссылку на другое свойство, вставив функцию var() в вызов setProperty().

Использование пользовательских свойств найдет широкое применение в динамической верстке и сделает работу вебразработчиков проще Пример манипуляции: <!doctype html> <html> <head> <style> :root { --primary-color: red; --secondary-color: blue; } p { color: var(--primary-color); } </style> </head>

var(<custom-property-name> [, <declaration-value> ]? )

Здесь > <custom-property-name> – имя определенного разработчиком пользовательского свойства > <declaration-value> – значение по умолчанию, которое будет использовано, если упомянутое пользовательское свойство не является валидным Значение по умолчанию может быть списком, разделенным запятыми. Оно будет преобразовано к единому значению. Краткая запись некоторых свойств (как в случае внешних и внутренних отступов) разделяется не запятыми, а пробелами, так что валидное значение по умолчанию для внутренних отступов будет выглядеть примерно так:

<body> <p>Hello world!</p> <button type="button">Set color blue</button> <script> document.querySelector('button'). ↵ addEventListener('click', () => { document .documentElement .style .setProperty('--primary-color', ↵ 'var(--secondary-color)'); }); </script> </body> </html>

Поддержка браузерами p { padding: var(--main-padding, 20px 25px 30px); }

Пользовательские свойства можно применять с функцией calc(), тем самым получая динамический CSS. Пример: .foo { --custom-margin: 20; margin-top: calc(var(--custom-margin) * 10px); }

системный администратор июнь 2016

На данный момент пользовательские свойства поддерживаются следующими браузерами: > Chrome 49 > Firefox 45 > Safari 9.1 > iOS Safari 9.3 > Opera 36 > Chrome for Android 49 Использование пользовательских свойств найдет широкое применение в динамической верстке и сделает работу веб-разработчиков проще. EOF

Разработка

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

Визитка

АЛЕКСЕЙ ВТОРНИКОВ, ЗАО КБ «Ростовский Универсальный», ведущий программист, pdp8dec@gmail.com

Lisp: маленький гигант Красота – неточное понятие. Но мы, по счастью, все же способны разглядеть истинную красоту, пусть даже в абстрактных идеях. Эта статья о языке программирования, который стал стартовой точкой целого направления в информатике, известного сегодня как функциональное программирование

Курица – это способ, которым яйцо создает другое яйцо. Сэмюэл Джонсон

Истоки В апреле 1960 года в журнале Communications of the Association for Computing Machinery (более известном как CACM) была опубликована 12-страничная статья «Recursive Functions of Symbolic Expressions and Their Computation by Machine. Part I» (часть II так никогда и не появилась). Автором статьи был математик Джон Маккарти, работавший в Массачусетском технологическом институте (Кембридж, США). В статье автор рассказал об итогах своей работы над новым языком для программирования искусственного интеллекта (кстати, именно Маккарти и был автором термина «искусственный интеллект», который в наши дни обезобразили до неудобоваримого «искин»). Справедливости ради нужно сразу же отметить, что Маккарти, являясь, безусловно, главным автором идеи, трудился не в одиночку: у него была небольшая лаборатория, в работе которой активное участие принимали его студенты, участвовавшие в реализации языка и предложившие ряд ценных нововведений. Структурно статья разделена на три части. В первой части описываются математические формализмы, положенные Маккарти в основу языка (рекурсивные функции и λ-исчисление, разработанное за 20 лет до этого Алонзо Черчем). Во второй части автор вводит т.н. S-выражения, служащие одновременно и для представления данных и для представления программ, написанных на этом языке. Здесь же вводятся основные операции над S-выражениями и описывается связь S-выражений с формализмами из предыдущей части статьи. Наконец, в последней части статьи описывается собственно сам язык (по состоянию на февраль 1960 года). Эта статья и описанный в ней язык стали стартовой точкой целого направления в информатике, известного сегодня

как функциональное программирование. Имя языка должно быть известно всякому, кто претендует на звание профессионала, – это, конечно же, Lisp. Замечание. Этимология названия языка забавна. Сам Маккарти образовал его из слов «LISt Processing», т.е. «обработка списков». Разумеется, это и есть официальное его название. Однако в английском языке слово «lisp» означает «шепелявить», «сюсюкать», что, конечно, послужило поводом для многочисленных, хотя и безобидных, шуток. Но есть еще одна и, надо признать, довольно едкая расшифровка «Lots of Irritating Superfluous Parentheses», т.е. «множество раздражающих лишних скобок» (слово «irritating» нередко заменялось куда более грубым «idiotic»). Причина столь резких нападок на скобки объясняется тем, что в программах на Lisp количество скобок непривычно велико по сравнению с традиционными языками программирования. На первых порах это действительно может раздражать, но очень скоро вы начинаете это ценить: скобки придают программам на Lisp особый стиль, удивительно ясный синтаксис и своеобразный интеллектуальный «аромат». Значимость Lisp хорошо иллюстрируется хотя бы тем, что он второй (после Fortran) по возрасту активно используемый язык программирования. Подавляющее большинство языков, появившихся в те или даже в более поздние годы, давно и надежно забыты (например, Algol или PL/1). А вот Lisp жив и не просто жив, а еще и весьма «плодовит» – он явился предтечей множества языков программирования, порой на него совершенно не похожих. Более того, многие концепции Lisp были заимствованы не родственными ему языками (например, замыкания, динамическая типизация, каррирование, сборка мусора, анонимные функции). Lisp как никакой другой язык обогатил информатику. С него и с его помощью начались интенсивные исследования семантики (смысла и значения) языков программирования. Даже если вы не будете использовать Lisp в практической деятельности, то все равно полезно хотя бы поверхностно с ним ознакомиться. Но для начала – несколько слов об авторе Lisp.

июнь 2016 системный администратор

Разработка

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

Об авторе Lisp Джон Маккарти родился в 1927 году в Бостоне в семье, далекой от математики: его отец был профсоюзным деятелем, мать – журналисткой. У мальчика рано проявились недюжинные математические способности. Будучи еще школьником, Джон приобрел университетские учебники и задачники, самостоятельно их изучил и перерешал все задачи, что позволило ему пропустить первые два курса по математике после поступления в Калифорнийский технологический институт (семья к этому времени переехала в Калифорнию). После недолгой военной службы он закончил обучение и многие годы занимался исследовательской работой и преподаванием в ряде ведущих американских университетов (причем в последнем из них – Стэнфордском – он проработал до 2000 года, вплоть до выхода на пенсию). Как и многие незаурядные личности, Джон Маккарти отличался некоторой чудаковатостью и даже эксцентричностью (вот, например, его ответ активистам по вопросам экологии: «Мое хобби – не посещать мероприятий в поддержку переработки отходов; это экономит больше энергии, чем ваше увлечение этой переработкой»). В молодости он даже увлекался идеями коммунизма (скорее всего под влиянием родителей), но довольно быстро к этому охладел. В зрелом возрасте, как он сам говорил, «для разнообразия» прыгал с парашютом и взбирался на горы. Не считал нужным слишком заботиться о приличиях: мог оборвать собеседника на полуслове, развернуться и уйти. Был убежденным пацифистом и вообще сторонником либеральных взглядов; призывал к немедленному окончанию войны во Вьетнаме. В 1971 году Джон Маккарти был удостоен самой престижной премии в области информатики – премии Тьюринга (с Аланом Тьюрингом, кстати, он был лично знаком). Его традиционная лекция на церемонии вручения премии была опубликована (после существенной переработки первоначального варианта) только в 1986 году, но достойна того, чтобы ознакомиться с ней. В ней Маккарти честно и открыто рассказывает о сложностях, возникших при попытках создания искусственного интеллекта (далее – ИИ), и признает, что «системы искусственного интеллекта страдают отсутствием общности». Кроме того, «никто не знает, как создать базу данных, содержащую общеполезные знания об окружающем мире (знания «здравого смысла»), которую могла бы использовать любая программа, нуждающаяся в этих знаниях». Хотя с той поры прошло уже 30 лет, вопросы, поднятые Маккарти продолжают оставаться актуальными. Кроме премии Тьюринга, Джон Маккарти был удостоен и ряда других престижных научных наград. Джон Маккарти сотрудничал с советскими математиками, а с А.П. Ершовым (1931-1988) состоял в многолетней переписке и личной дружбе; он неоднократно посещал Советский Союз с лекциями и участвовал в работе ряда проводившихся в СССР конференций и семинаров. Умер Джон Маккарти в сентябре 2011 года в возрасте 84 лет. Новость о его смерти стала распространяться только спустя несколько дней. Увы, так часто бывает: уход из жизни человека, создавшего одно из самых важных, продуктивных и полезных направлений в программировании, прошел практически незамеченным. Но наследие, оставленное Маккарти, продолжает жить и развиваться. Более того, все свидетельствует о том, что роль функционального

системный администратор июнь 2016

программирования будет только расти. Джон Маккарти сам, своими трудами и идеями, создал себе памятник.

Шапочное знакомство с Lisp Для решения сложных задач, которыми всю жизнь и занимался Джон Маккарти, нужны сильные инструменты. Давайте познакомимся с основными концепциями Lisp: именно здесь лежат все основные идеи. При этом мы будем ориентироваться на ANSI Common Lisp (часто используется сокращение «CL») – самую, пожалуй, распространенную версию языка. Но это не должно служить препятствием к изучению других реализаций (и прежде всего Scheme) – основные принципы остаются неизменными. Замечание. Справедливости ради необходимо отметить, что первым языком программирования, специально разработанным для решения задач ИИ, был язык IPL (Information Processing Language), сознанный в 1956 году А. Ньюэллом, К. Шоу и Г. Саймоном из RAND Corporation и Института Карнеги. IPL – это своего рода ассемблер для символьных вычислений. Мы не будем сейчас на нем останавливаться, но надо упомянуть, что IPL оказался удачной разработкой. На IPL был реализован ряд проектов ИИ (игра в шашки, первая экспертная система, программа для доказательства теорем и ряд других). Lisp испытал сильное влияние IPL (особенно в том, что касалось представления структур данных), но Маккарти в конечном счете выбрал иной путь; в итоге Lisp быстро вытеснил IPL, о котором сейчас почти никто не вспоминает (и, откровенно говоря, напрасно). Идея S-выражений очень проста, но, чтобы увидеть за этой простотой истинные возможности, нужно, чтобы появился гений. Название S-выражение происходит от symbol expression, что можно перевести как «символьное выражение». S-выражение – это всего лишь способ (или форма) записи данных и программ. S-выражения состоят из данных двух типов – атомов и списков. Математик Джон Маккарти

Разработка Атом – это либо число (например, 127, -88 или 3.1415926), либо алфавитно-цифровой символ (например, A, СОБАКА или B52), либо строка (последовательность символов, ограниченная кавычками, например, «Hello World»). Обратите внимание, что понятие символа в Lisp отличается от такового в Java или C, где символ – это действительно одиночный знак, например, 'A' или '*'. Список – это структура данных, состоящая из атомов и других списков (они называются подсписками или вложенными списками), разделенных пробелами и ограниченных скобками. Несколько примеров дадут достаточное представление о списках: (У ПОПА БЫЛА СОБАКА) (У (ПОПА (БЫЛА (СОБАКА))) (ПАПА ВАСЯ 35 МАМА Лена 30 СЫН МИША 8) ((ПАПА ВАСЯ 35)(МАМА ЛЕНА 30)(СЫН МИША 8)) ()

истоки программирования вычисляется в «New York». Однако только лишь самовычисляемых S-выражений для программирования не достаточно: нужны функции для обработки списков. Вызов функции в Lisp осуществляется в следующей форме: (<имя функции> <список аргументов, возможно, пустой>)

Обратите внимание, что вызов функции – это такое же Sвыражение, что и рассмотренные ранее; более того, синтаксически (т.е. по форме) вызов функции совпадает со списком. Вообще в Lisp список и функция – это проявления одной и той же сущности. Первый элемент в вызове функции – ее имя, остальные элементы – ее аргументы. Следовательно, такое S-выражение: (обработать 1 2 3 QWERTY)

Первый список – это пять (символьных) атомов, разделенных пробелами и заключенных в пару скобок. Второй список кажется аналогичным первому, но на самом деле это совершенно иной список. Он состоит из двух списков: > первый элемент списка – просто символ «У», > а второй – подсписок «(ПОПА (БЫЛА (СОБАКА))», включающий, в свою очередь, вложенный список. Третий список иллюстрирует, что список может содержать атомы различных типов. Четвертый список показывает, как может быть структурирована информация, заключенная в предыдущем списке. Наконец, пятый пример демонстрирует пустой список, т.е. список, не содержащий элементов. Этот список в программах на Lisp обозначается как NIL (т.е. «ничего» или «пусто»). Легко видеть, что с помощью S-выражений можно представить информацию любой степени сложности. Количество открывающихся скобок должно совпадать с количеством закрывающихся. Именно это «изобилие» скобок и послужило причиной нелестных эпитетов в адрес Lisp, но попробуйте предложить способ, как можно представить список еще проще и нагляднее. Следует иметь в виду, что порядок элементов в списке важен. Список (A B C) – это не то же самое, что список (B C A) и тем более (A (B C)): они имеют совершенно различные структуры. Так что список не следует смешивать с множествами, где порядок элементов безразличен. Раз у нас есть S-выражения, то должны быть и способы их обработки. Учитывая потенциальное многообразие S-выражений, можно ожидать, что их обработка должна быть не простой, но, оказывается, это не так. Обработка осуществляется посредством базовых (встроенных) функций. Давайте по порядку рассмотрим ряд таких функций (странные названия некоторых из них обусловлены историческими причинами и являются, как правило, аббревиатурами, употреблявшимися в 50-х годах прошлого века). Но для начала несколько слов о том, как Lisp производит вычисления. Некоторые S-выражения в Lisp являются самовычисляемыми. Таковы, например, числа и строки – они, если так можно выразиться, вычисляются сами в себя. Число 127 вычисляется в 127, строка «New York»

понимается как вызов функции с именем «обработать» и аргументами 1, 2, 3 и QWERTY. Таким образом, в Lisp принята префиксная нотация, в которой имя функции стоит первым. И тут немедленно возникает проблема. Как, к примеру, должно вычисляться S-выражение (1 2 3)? Следуя только что сказанному, Lisp должен использовать первый элемент (т.е. 1) как имя функции, а оставшиеся (2 и 3) как аргументы. Пытаясь вычислить это S-выражение, CL сгенерирует ошибку «1 не является именем функции» и перейдет в режим отладки. Если вдуматься, то все логично – мы пытаемся применить 1 к аргументам 2 и 3, что бессмысленно. Надо как-то защитить такое S-выражение от вычисления и указать Lisp, что это не функция, а просто список, который должен восприниматься как есть. Для этого в Lisp предусмотрена функция цитирования: QUOTE (1 2 3). Эта конструкция предотвращает вычисление списка. Часто используется сокращенная форма QUOTE – апостроф «’»: ’ (1 2 3). А теперь, поговорим об основных функциях. Имейте в виду, что, будучи ограничены рамками журнальной публикации, мы успеем только слегка коснуться всего многообразия возможностей Lisp. За подробностями, как обычно, следует обращаться к соответствующей документации и учебникам (см. библиографию).

Селектор CAR Эта функция выделяет из списка первый элемент. Несколько примеров дадут достаточное представление о том, как работает CAR: (CAR '(A B C)) = A (CAR '((A B 5)(C D 15)(E F 15))) = (A B 5)

Обратите внимание на цитирование списка. Таким образом первым элементом списка может быть или атом, или список. Если попытаться применить CAR к атому, то результат будет не определен.

Селектор CDR Эта функция возвращает список после удаления из него первого элемента:

июнь 2016 системный администратор

Разработка

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

(CDR '(A B C)) = (B C) (CDR '((A B 5)(C D 15)(E F 15))) = ((C D 15)(E F 15))

Для атома функция CDR не определена. Если применить CDR к списку, состоящему из единственного атома, то результатом будет специальный атом NIL:

Замечание. Столь частое использование цитирования может создать ложное впечатление, что программы на Lisp тяжеловесны. Поспешим успокоить: необходимость цитирования в настоящих программах возникает не так уж и часто, но помнить о нем нужно.

Арифметика (CDR ‘(A)) = NIL

Ранее мы говорили, что NIL представляет собой пустой список. Но по принятому в Lisp соглашению он же является и атомом. На первых порах это кажется необычным, но по мере освоение Lisp такое отождествление становится понятным, логичным и привычным.

Конструктор CONS Введенные ранее селекторы CAR и CDR выделяют («селектируют») части списка. Логично ожидать, что должна быть функция конструирования отдельных частей в единый список. Такая функция действительно существует – это CONS. Функция CONS получает в качестве аргументов два S-выражения и соединяет их в единое S-выражение. При этом второй аргумент CONS должен быть списком или NIL: (CONS 'A '(B C)) = (A B C) (CONS '(A B 5)'((C D 10)(E F 15))) = ((A B 5)(C D 10)(E F 15)) (CONS 'A ()) = (A)

Любой язык программирования будет не полным, если в нем нет хотя бы основных арифметических функций. Очевидно, что аргументами этих функций должны быть числа. Вот их список: > (+ a b c ... x y z) = a + b + c + ... + x + y + z > (* a b c ... x y z) = a * b * c * ... * x * y * z > (- a b c ... x y z) = a – b – c - ... – x – y - z > (/ a b c ... x y z) = a / b / c / ... / x / y /z > (REM a b) = остаток от деления a / b Первые четыре функции могут принимать любое количество аргументов, последняя – точно два.

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

Если теперь применить к полученному списку функции CAR и СDR, то должны получиться исходные аргументы функции CONS.

(COND (<условие1> действие1) (<условие2> действиеN) ... (<условиеN> действиеN))

Предикаты

Работает такая конструкция так. Проверяется условие1; если оно истинно, то выполняется действие1 и т.д. Если ни одно из условий не истинно (т.е. возвращает NIL), значением COND будет NIL. Часто используется более привычная, но не столь гибкая, конструкция IF (пример будет приведен далее).

При обсуждении функций CAR, CDR и CONS мы неоднократно говорили о том, что нужно быть внимательными, применяя эти функции к атомам. Но как понять: является ли заданное S-выражение атомом или списком? Для этого предусмотрена простая функция ATOM, проверяющая свой аргумент и которая возвращает логическое значение (функции, возвращающие логические значения «истина» или «ложь», называются предикатами). Итак: (ATOM (ATOM (ATOM (ATOM

'A) = T 3.1415926) = T '(A B C)) = NIL NIL) = T

«T», как легко догадаться, означает истину. Здесь мы видим, что NIL сигнализирует о том, что результат проверки ATOM возвращает ложь, но, в свою очередь, NIL как атом – это истина. Т.о. NIL един в трех лицах (атом, пустой список, логическое значение). Еще один предикат, который нам нужен, – предикат проверки на равенство. Понятие «равенство» на самом деле далеко не так просто определить, как это может показаться. В CL таких предикатов несколько. Наиболее общий EQ, но он используется редко. Чаще всего используется предикат EQL: (EQL 1 1) = T (EQL 'A (CAR '(A B C))) = T (EQL 1 1.0) = NIL

системный администратор июнь 2016

Определение новых функций Перечисленные ранее функции называются базовыми, т.е. встроенными в Lisp при его реализации. Нам необходим какой-то способ определения собственных функций из запаса имеющихся. Для этого используется конструкция DEFUN (от define function): (DEFUN <имя функции> (<список аргументов>) (<тело функции>) )

Чтобы увидеть как эта конструкция работает, запрограммируем парочку элементарных функций. Первой будет функция SQUARE, возводящая свой аргумент во вторую степень: (DEFUN square (x) (* x x) )

Мы определяем функцию с именем square. Этой функции в качестве аргументов передается x. Функция умножает

Разработка аргумент на самого себя и возвращает квадрат x. Понятно, что x должно быть числом, в противном случае работа функции не определена: (square 15)

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

225 (square 1.41) 1.9880999

Вторая (и чуть более сложная функция) – всем известный факториал: (DEFUN fact (n) (IF (= n 0) 1 (* (fact (- n 1)) n)))

Это типичная рекурсивная реализация. Вот как работает эта функция: (fact 5)

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

120

О чем мы умолчали (fact 10) 3628800

А теперь попытайтесь самостоятельно определить такие известные функции, как вычисление чисел Фибоначчи или нахождение НОД двух чисел. Это совсем несложно, надо только постараться.

А где же циклы... Циклов в Lisp Маккарти не вводил. В Lisp есть ряд конструкций, позволяющих организовать нечто подобное циклам, но на самом деле без них можно обойтись. Для этого есть рекурсия. Как говорится, «учите матчасть» и не капризничайте. Заметьте, мы говорим о т.н. чистом Lisp, а это достаточно идеализированная конструкция. Полезность и важность циклов неоспоримы и в современные версии Lisp они включены. Академическая чистота – это прекрасно, но практическая целесообразность тоже важна.

...и переменные? Нет циклов и ладно – обойдемся рекурсией. А что насчет переменных? Боимся разочаровать, но их тоже нет! Соответственно, нет и такой конструкции, как присваивание. Впрочем, тут следует оговориться. Lisp позволяет вводить переменные и присваивать им значения. Это в конце концов вопрос удобства, а им пренебрегать без нужды не следует. Правда, ставить знак тождества между привычным нам присваиванием, скажем, в Java или Pascal с присваиванием в Lisp нельзя. Причина в том, что это не столько присваивание, сколько связывание переменной со значением. Lisp-система функционирует в определенном окружении,

Будем краткими и честными – практически обо всем, что делает Lisp интересным и практически полезным. Мы умолчали о типах, замыканиях, λ-исчислении, недетерминированном программировании, ленивых вычислениях (вычислениях с задержкой), макросах и т.д. Мы ничего не сказали о таких языках программирования, как Prolog, Haskell, Erlang, Clojure, ML, и многих других. Мы не показали (да и не могли здесь показать) связь функционального, императивного и логического программирования. Мы ничего не сказали о функциях высших порядков, т.е. функциях, которые в качестве параметров могут принимать другие функции и результатом работы которых могут быть другие функции. Наша цель сводится к тому, чтобы заинтересовать читателя, побудить его попробовать. Поначалу это будет непросто – ваш предыдущий опыт станет препятствовать попыткам сменить привычку. Наш совет – не сдавайтесь. Что-то действительно новое часто кажется неудачным и даже глупым; не позволяйте минутной слабости одержать верх и потерять возможность прикоснуться к настоящему богатству – функциональному программированию. И не бойтесь математики – если вы занимаетесь только прикладными задачами, то она вам даже и не понадобится.

Реализации Lisp Количество доступных реализаций Lisp огромно. Конечно, существуют своего рода «канонические»; большинство из них свободно доступны. Мы использовали CL со следующего сайта: https://sourceforge.net/projects/clisp. Еще две популярные реализации CL: > https://common-lisp.net/project/slime > http://www.sbcl.org

июнь 2016 системный администратор

Разработка

истоки программирования Реализаций Scheme тоже достаточно много, но лучше всего обратиться к первоисточнику: http://www.gnu.org/ software/mit-scheme. А дальше, как обычно: скачивайте, читайте и пробуйте...

Библиография Невозможно даже пытаться перечислить все достойные упоминания книги, посвященные функциональному программированию в целом и Lisp в частности, но это и не нужно – начните с обзора Алекса Отта: http://alexott.net/ru/fp/books. По мере того, как будете приобретать опыт, вы, бесспорно, захотите погрузиться в предмет. Многочисленные сайты и форумы окажут вам в этом неоценимую помощь. От себя хотим порекомендовать сайт: http://fprog.ru/planet. Здесь далеко не все и далеко не сразу станет вам понятно, но это ценный ресурс – имейте его в виду. Все же мы выделим несколько книг, которые помогут начинающему познакомиться с Lisp и начать программировать на нем. По CL можно посоветовать книги: Пол Грэм. ANSI Common Lisp. Хотя книга была написана много лет назад, а ее перевод на русский вышел только в 2012 году, он является классическим введением в программирование на CL. Очень ясно и доступно описаны основные концепции языка, которые проиллюстированы множеством примеров и рядом нетривиальных программ. Книга содержит много упражнений и очень ценные (для знатока) приложения. Питер Сайбель. Практическое использование Common Lisp. Эта книга на протяжении ряда лет переводилась

группой энтузиастов. В 2014 году издательство «ДМК Пресс» издало ее бумажный вариант. Ценное руководство со множеством технических деталей, которые, бесспорно, будут очень полезны опытным программистам (что вовсе не умаляет значение книги и для начинающих). Детально показан процесс разработки ряда весьма сложных программ. Кроме CL, существует еще один распространенный вариант Lisp, о котором мы вкратце упоминали, – Scheme. Здесь безусловным «фаворитом» является книга: Харольд Абельсон, Джеральд Сассман. Структура и интерпретация компьютерных программ (обычно используется аббревиатура, образованная из первых букв английского названия SICP). Это не просто книга об одном из диалектов Lisp. Считать книгу только лишь учебным текстом, значит, не понять главного: это своего рода сакральный текст, откровение. Некоторые считают ее (и не без оснований) книгой книг, превосходящую по значению все остальные книги по программированию. Самое важное в ней – мысли, рассуждения, идеи, озарения. Причем независимо от того, с каким языком программирования вы работаете. Уже упомянутый Пол Грэм так сказал о ней: «Я впервые прочел ее 15 лет назад и до сих пор не уверен, что усвоил все, чему эта книга может научить». Если у вас на полке место только для одной книги, то пусть это будет именно эта. EOF Ключевые слова: функциональное программирование, язык Lisp, S-выражения, базовые функции, рекурсия, исчисления.

Заходите, выбирайте, покупайте! Вам нравится наш журнал? Вы можете с ним не разлучаться! Что для этого нужно сделать? В нашем интернет-магазине по адресу: http://samag.ru/catalogue можно приобрести отдельные номера журналов «БИТ», «Системный администратор» и книги наших авторов. Также там можно купить приятный глазу и душе и одновременно полезный в хозяйстве сувенир с фирменной символикой «Системного администратора»! Настольные игры «Локалка» и «Outsourcer», кружку «Солнечное настроение», футболки «Системный администратор» и «Программист», пятнашки-антистресс «Собери мозги» и многое другое. Самовывоз (Москва, 3-й проезд Марьиной рощи, дом 40, строение 1) или доставка Почтой России. Стоимость доставки 250 р. E-mail: sa@samag.ru

системный администратор июнь 2016

Tel.: (499) 277-12-41

Fax: (499) 277-12-45

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

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

Андрей Филиппович: «Профессионал – это человек, который не умеет делать плохо свою работу. Подготовка таких специалистов для ИТ-индустрии является главной целью нашего факультета» В гостях у «Системного администратора» – Андрей Филиппович, декан факультета информатики и систем управления Московского политехнического университета, сформированного на базе МАМИ и МГУП имени Ивана Федорова

– За последние два года в Московском политехническом университете (ранее МАМИ) произошли серьезные изменения. Сейчас он все чаще встречается в рейтингах лучших московских вузов. Чем обучение на факультете информатики и систем управления принципиально отличается от обучения на ИТ-факультетах других ведущих вузов? – На мой взгляд, формула отличного технического образования была выведена более 100 лет назад в так называемом русском методе подготовки инженеров и базируется на следующих трех принципах: > Серьезная практическая подготовка студентов на задачах и в условиях, максимально приближенных к будущей деятельности. > Глубокое изучение фундаментальных дисциплин – на уровне не ниже ведущих классических университетов. > Тесное взаимодействие с работодателями.

Андрей Юрьевич Филиппович, кандидат технических наук, профессор Научно-образовательного центра инфокогнитивных технологий и декан факультета информатики и систем управления Московского Политеха. С 2014 года возглавляет рабочую группу по актуализации образовательных программ Совета по профессиональным квалификациям в области ИТ, созданного на базе АПКИТ. Высшее образование получил в МГТУ им. Н.Э. Баумана по специальности «Автоматизированные системы обработки информации и управления», имеет более 150 научных и учебных публикаций. Область научных интересов связана с компьютерной лингвистикой, искусственным интеллектом, системами моделирования и ситуационными центрами

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

июнь 2016 системный администратор

alma mater российских ИТ В Московском Политехе было принято решение о кардинальном изменении образовательных программ в сторону усиления практикоориентированности методов и содержания подготовки. Методологической основой при этом стала концепция CDIO, разработанная в начале 2000-х в MIT и сегодня успешно реализуемая в более чем 130 университетах мира. Она направлена на формирование компетенции современного инженера через реализацию проектного обучения – участия студентов на всех этапах жизненного цикла изделий Conceive – Design – Implement – Operate («Задумай – Спроектируй – Реализуй – Управляй»). Для усиления прикладных компетенций, позволяющих студентам реализовывать проекты, мы уже с первого семестра активно внедряем в образовательные программы преподавание сертифицированных учебных курсов ведущих ИКТ-вендоров («1C», Cisco, Oracle, Microsoft и др.). Это обеспечивает решение сразу нескольких задач – гарантированно высокий уровень и современность учебно-методических материалов, авторитетность преподавателей, увеличение заинтересованности студентов и автоматическое признание результатов обучения ИТ-индустрией. Комбинация этих двух решений дает ощутимый результат – в первый год обучения студенты получают индустриальные сертификаты, подтверждающие их готовность к работе на начальных позициях в сфере ИКТ (специалист техподдержки, веб-верстальщик, 3D-моделлер и др.). За два года все хорошо успевающие студенты достигают уровня Juniorразработчика и получают уникальную специализацию согласно профилю образовательной программы. Как правило, к этому времени они уже имеют портфолио из трех-четырех проектов, опыт участия в нескольких хакатонах и конкурсах, а также навыки публичных выступлений и защит. На старших курсах бакалавриата мы повышаем квалификацию студентов до более высокого уровня, развивая профессиональные компетенции в области системного анализа, программной инженерии, проектирования сложных информационных систем, моделирования бизнес-процессов и сервисов. В конце обучения их ожидает основательный блок дисциплин в сфере экономики, интеллектуальной собственности и технологического предпринимательства, которые дают основу для оформления дипломной работы в виде стартапа. Наиболее способных и мотивированных выпускников мы приглашаем в проектно-технологическую магистратуру, где они не только получают углубленные знания в сфере искусственного интеллекта, машинного обучения, компьютерной лингвистики, больших данных, но и активно участвуют в перспективных R&D-проектах в рамках Национальной технологической инициативы (http://asi.ru/nti). – Расскажите подробнее о проектном обучении. В чем его плюсы? Какие возможности проектная деятельность дает студентам? – Существует много методик реализации проектного обучения. На нашем факультете оно реализуется как специальная дисциплина (или группа дисциплин), в рамках которой студенты обязаны выполнить индивидуальный или групповой ИТ-проект. При этом темы проектов и реальные задания предоставляют индустриальные партнеры – будущие работодатели. В течение семестра они выступают в роли

системный администратор июнь 2016

Карьера/Образование Образовательные программы Бакалавриат: «Интеграция САПР-решений в машиностроении», «Вебтехнологии», «Корпоративные информационные системы», «Большие и открытые данные», «Анализ информационной безопасности», «Киберфизические системы», «ИТ–менеджмент. Магистратура: «AutoDriver: Системы управления беспилотными транспортными средствами», «Big Data: Системная аналитика больших данных», «SurdoJet: Жестомимический интерфейс», «Cognizer: Моделирование сознания и мышления человека», «MedExpert: Интеллектуальные системы в медицине», «WebSecurity: Информационная безопасность веб-приложений и облачных технологий», «HCI *Net: Эргономический анализ интерфейсов и перспективных технических систем»

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

Карьера/Образование При создании новых программ были проанализированы наиболее востребованные и перспективные профессии, отечественные и международные профессиональные стандарты, и уже на их основе определено актуальное содержание учебных курсов и практик. Например, в интернет-индустрии в настоящее время распространено свыше 20 веб-профессий, каждая из которых требует значительного набора знаний и навыков. Наша образовательная программа «Веб-технологии» направлена на фундаментальную подготовку в области веба, формирует компетенции по каждой специализации, но делая основной акцент на проектировании и разработке веб-приложений. В рамках обучения все студенты осваивают профессии вебпрограммиста, разработчика мобильных приложений, администратора веб-сайтов, SEO-оптимизатора и специалиста по управлению интернет-проектами. Другим примером является образовательная программа «Интеграция САПР-решений в машиностроении», разработанная совместно с экспертами мирового лидера в области САПР – компании Autodesk. Бурное развитие информационных технологий в промышленности формирует необходимость подготовки ИТ-специалистов нового типа, которые, помимо универсальных навыков проектирования и программирования информационных систем, владеют фундаментальными инженерными знаниями и способны проводить системный анализ технологических процессов предприятия для внедрения широкого класса систем автоматизированного проектирования (САПР). В настоящее время машиностроительная отрасль и ИТ-рынок испытывают серьезный кадровый дефицит в квалифицированных САПР-консультантах и разработчиках, которые хорошо знают современные системы и могут при необходимости разрабатывать на их основе специализированные мобильные, облачные и веб-ориентированные приложения. Образовательная программа «Корпоративные информационные системы» ведет подготовку ИТ-консультантов в области моделирования и реинжиниринга бизнес-процессов, последующего внедрения и настройки КИС крупнейших ИТ-вендоров. В учебных курсах уделяется формированию навыков проектирования, разработки и тестирования настольных, веб и мобильных приложений для автоматизации широкого класса бизнес задач. В программу мы заложили реализацию требований профессиональных стандартов 130 студентов факультета в этом году получили сертификаты Cisco IT Еssential

alma mater российских ИТ и включили сертификационные курсы по разработке и внедрению ERP, CRM, BPM систем от ведущих лидеров рынка. В рамках программы «Кибер-физические системы» мы готовим инженеров по проектированию и разработке в области интернета вещей, мобильной робототехники, SMARTустройств, которые становятся с каждым годом все более «самостоятельными» и «разумными». Программа «Анализ информационной безопасности» направлена на подготовку специалистов по информационной безопасности, спрос на которых по данным крупнейших кадровых агентств активно растет. Аналитики ИБ обследуют технические устройства, изучают программные коды, бизнес-процессы и документы на предмет наличия в них потенциальных уязвимостей. В случае необходимости они тестируют и дорабатывают информационные системы, создают специализированные программы и веб-сервисы. – Факультет тесно сотрудничает с ИТ-отраслью. В чем находит отражение это взаимодействие? – На факультете открыты ИТ-академии ведущих вендоров: Учебный центр Autodesk, Центр сертифицированного обучения «1C», Сетевая академия Cisco, Академия Oracle, Microsoft Imagine Academy, Microsoft Dynamics Academy и др. В рамках сотрудничества с Apple по программе iOS Developer University Program (iDUP) обучено пять преподавателей. На базе программы Google Ambassadors работает студенческий клуб, где проводится обучение мобильной разработке под Android. В учебном процессе задействовано большое количество преподавателей-практиков. Например, по программе «Вебтехнологии» представители Ассоциации интернет-разработчиков (АИР) читают такие курсы, как «Проектирование веб-сайтов», «Поисковая оптимизация (SEO)», «Интернетмаркетинг», «Веб-райтинг», а представители Mail.Ru – курсы «Веб-технологии», «Веб-разработка на Python» и др. Мы регулярно проводим открытые лекции, семинары и мастер-классы, участвуем в хакатонах и профильных конкурсах. Кроме того, активно участвуем в разработке профессиональных стандартов, сотрудничаем с профильными ассоциациями – АПКИТ, СПК ИТ и др. – Сколько бюджетных мест будет у вас в 2016 году? Насколько сложно к вам поступить? – В 2016 году у нас свыше 250 бюджетных мест в бакалавриате и около 120 в магистратуре. По текущей статистике, в среднем у нас до 50% студентов, проживающих в общежитиях. Проходной балл на факультет в прошлом году составлял около 220, однако ситуация каждый год меняется, и, несмотря на демографический спад, мы рассчитываем на рост соответствующих показателей. Принимаем мы по экзаменам «Математика», «Информатика», «Русский язык». EOF Вся информация о вузе – на сайте http://www.mami.ru, и в соцсетях http://fb.com/ict.mami

июнь 2016 системный администратор

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

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

Иван Чикунов: «Наш студент получает несколько полноценных профессий с первых семестров обучения» Иван Михайлович Чикунов, руководитель образовательной программы «Веб-технологии», доцент, кандидат технических наук Уже сегодня Международная ассоциация веб-мастеров (http://iwanet.org) выделяет более 20 связанных с вебтехнологиями профессий, каждой из которых отводится своя, отличная от других роль. А значит, появляется потребность в сотруднике, который бы знал их все, умел эффективно организовывать и планировать работу каждого специалиста. Уже сейчас рынку необходимы инженеры со знаниями в области программной инженерии, системного анализа и т.д., которого, безусловно, должна готовить высшая школа. Наш выпускник не просто понимает основные веб-технологии, он получает несколько полноценных профессий уже на первых семестрах обучения. Встраивание в образование учебных

курсов от ведущих компаний отрасли, таких как Cisco, Oracle, «1C», дает возможность подготовить студентов к сдаче соответствующих профессиональных сертификаций, что позволяет им начать работать уже после первого курса. Концепция проектного обучения предусматривает постоянное применение полученных теоретических знаний на практике: студенты все время учебы непрерывно самостоятельно реализуют полноценные проекты, зачастую для реальных заказчиков. Особый формат практико-ориентированных экзаменов, сдавая которые студент должен за 6-8 часов решить реальную задачу, моделирует будущий рабочий день, готовит наших выпускников к трудовой деятельности.

Все это становится возможным за счет участия преподавателей, ведущих активную профессиональную деятельность в крупнейших ИТ-компаниях: mail.ru, «1С», «Лаборатория Касперского» и др., а также привлечения крупных профессиональных ассоциаций: АПКИТ, АИР и т.д. Как следствие, наши студенты участвуют в крупнейших профессиональных конкурсах и чемпионатах: Microsoft ImageCap, WorldSkills , выигрывают или занимают призовые места. EOF

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

системный администратор июнь 2016

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

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

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

рынок труда

Вакансия: программист Ruby Ruby является языком программирования, популярность которого в последнее время растет. Согласно индексу TIOBE в апреле 2016 года Ruby занимает девятую позицию (год назад – 18-ю). Популярен он и в России. Чтобы выявить общее и особенное в практике его использования, мы обратились к представителям компаний и проектов с рядом вопросов 1. 2. 3. 4. 5.

Какими знаниями и навыками должен обладать Программист Ruby? Каков инструментарий программиста Ruby? Каковы требования компании к уровню образования потенциальных сотрудников? Какие требования предъявляются к опыту работы? Есть ли особые требования, которые обусловлены спецификой деятельности компании?

Ярослав Маркин, основатель Evil Martians (http://evilmartians.com)

Узкая специализация на языке программирования или платформе ушла в прошлое: сейчас любой хороший программист не только знает несколько языков или платформ, но и за короткие сроки должен уметь освоить новый язык, фреймворк или базу данных. Именно благодаря неудовлетворенности от печально известного PHP или усталости от «энтерпрайзного» Java многие классные программисты когда-то открыли для себя Ruby; сейчас они не останавливаются и осваивают функциональные языки или программирование микроконтроллеров, уже имея Ruby в багаже. Поэтому поговорим о том, какими навыками и знаниями должен обладать хороший программист.

Главное – то, что обычно называют профессиональными качествами. Умение планировать собственное время и работать без напоминаний, умение давать оценку и отвечать за нее, умение выдавать качественный результат на высоком уровне – стабильно, а не как придется. Саморазвитие, самообразование и широкий кругозор. И язык, хороший технический английский: перед освоением любого языка программирования сначала нужно заняться своим английским. Хорошему программисту, особенно на Ruby, нужно каждый день продираться через гору информации: блогпосты, скринкасты, презентации с конференций. Если этого не делать, можно быстро потерять хватку: нужно постоянно расширять кругозор. Для программиста, основной язык которого – Ruby, владеть еще несколькими «серверными» языками – это норма. Кроме отличного знания самого языка, Ruby-программист должен разбираться в стандартной библиотеке, деталях реализации виртуальной машины (сборка мусора, треды), альтернативных интерпретаторах. Важно обладать всеми навыками грамотного объектно-ориентированного проектирования, уметь со вкусом рефакторить код, владеть инструментами для автоматического тестирования. Три главных инструмента программиста – консоль, редактор и система управления версиями. В подавляющем большинстве проектов на Ruby используется Git, который нельзя назвать простым в освоении, но знать особенности его работы и идеально работать по git flow – обязательное требование. Большинство проектов на Ruby – проекты на Ruby on Rails, поэтому хороший программист должен отлично разбираться в деталях работы реляционной СУБД, на которой работает проект (PostgreSQL или MySQL). План запросов, типы индексов и другие, казалось бы, «мелочи» – обязательные вопросы на хорошем собеседовании.

июнь 2016 системный администратор

рынок труда Отдельное частое требование – опыт с оптимизацией производительности. Нужно хорошо знать детали работы Ruby (треды и сборка мусора), HTTP-стек, уметь оптимизировать реляционные базы данных, работать с кэшированием и вообще выдерживать высокую внешнюю нагрузку. Главные черты, характерные для всего инструментария Ruby-программистов, это тяга к автоматизации во всем и упрощение, популяризация уже известных полезных инструментов и методов. Программист Ruby обычно работает на Linux или Mac OS X. Два из трех основных инструментов программиста – это, конечно, консоль и текстовый редактор. В мире Ruby программисты тяготеют к расширяемым редакторам (Vim, Sublime Text, Atom), пользователи интегрированных сред вроде RubyMine в меньшинстве. Крайне популярен Vim, несмотря на сложность в освоении, есть огромное количество обучающих ресурсов для новичков; вершина моды сейчас – использование Vim вместе с терминальным мультиплексором tmux. Конечно, для работы нужна классная система управления версиями, третий основной инструмент программиста. Git доминирует в Ruby-мире, равно как и GitHub.com для размещения Open Source и коммерческих проектов. Хотя иногда программисты пользуются другими распределенными системами версий или даже морально устаревшей Subversion. Ruby-программисты одними из первых ввели в моду использование менеджеров версий для рантаймов для легкого переключения между версиями интерпретатора – RVM (Ruby Version Manager), который часто заменяют на rbenv или chruby. Ruby-проект Capistrano первым популяризовал автоматическую выкладку (деплоймент) приложения в рабочее окружение. Сейчас вместо Capistrano зачастую используют окружения, построенные на Docker.

Даниил Жирнов, Team Lead и главный разработчик компании «Прогресс софт» Замечание: ответы отражают мое субъективное мнение и не являются официальной позицией компании, в которой я работаю.

1. Если ограничиться только данной спецификой языка, конечно же, знание профильного языка – Ruby. Помимо этого, опыт использования баз данных (реляционные и нереляционные), понимание принципов работы веб-сервера. Если проект в работе будет связан с автоматизированными рабочими местами, то потребуется знание HTML, JavaScript (и JS-фреймворки), CSS.

2. Linux или MacOS на выбор, RVM или rbenv, Git, любой удобный текстовый редактор или IDE (например, Sublime или RubyMine).

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

4. Эффективнее брать в команду человека с опытом работы в реальных проектах. Однако выпускники технических вузом зачастую имеют опыт своих проектов (не обязательно коммерческих), и это является плюсом для кандидата на вакансию. Если рассматривать в целом опыт работы в среде разработки под Ruby, то обязателен опыт использования популярных gem, а также желательно иметь один или несколько своих созданных gem.

5. Опыт работы с проектами госсектора, а также реальное участие в проектах с высокими нагрузками.

системный администратор июнь 2016

Карьера/Образование Александр Типугин, ведущий разработчик компании «Тематические Медиа»

1. Ruby чаще всего применяется в вебе, все благодаря Ruby on Rails. Поэтому потребуется знание именно этого фреймворка. Сюда же можно добавить более общие навыки – понимание принципов работы HTTP, устройства веб-серверов, навыки работы с СУБД. В Ruby-сообществе очень сильно развита культура тестирования, поэтому уметь и любить писать разнообразные тесты – одно из ключевых требований. Также не лишним будет понимание того, как вообще устроен Ruby под капотом. Хороший разработчик должен знать, как Ruby работает с тредами и что такое GIL, как устроена работа с памятью, и уметь профилировать ее утечки.

2. Инструментарий – вопрос исключительно индивидуальный. Кто-то использует RubyMine, кому-то нравится Vim. Мои инструменты – это Макбук, Sublime Text 3 (IDE неприемлю) в качестве редактора, SourceTree для работы с Git, iTerm.

3. Высшее образование желательно. Фундаментальные знания довольно сложно (хотя и возможно) приобрести самостоятельно. Однако это совершенно необязательно условие. Гораздо важнее предыдущий опыт работы. Правда, если вы вдруг захотите уехать работать в Европу или США, то там у вас обязательно попросят диплом.

4. Опыт важен, причем это не должен быть какой-то разовый фриланс, а полноценные реальные проекты. Совсем замечательно, если кандидату есть что показать в плане Open Source-проектов.

5. В целом никаких специфических требований нет.

Первые инструменты управления серверной конфигурацией (и движение DevOps в целом) тоже появились в Rubyсреде: Chef и Puppet остаются до сих пор крайне популярными. Такие инструменты нужны для того, чтобы единожды задать описание окружения сервера и в дальнейшем разворачивать его автоматически. Автоматизация фронтенд-разработки тоже когда-то началась с Ruby on Rails и плагинов, и только несколько лет назад полностью перешла на использование Node.js. До этого Ruby был пионером в использовании новых необычных шаблонизаторов (Haml, Slim), компилируемых в JavaScriptязыках (CoffeeScript), средств сборки (Rails Asset Pipeline и многие другие). Автоматизированное тестирование, конечно, существовало задолго до популяризации Ruby и Rails, но именно с развитием Rails-экосистемы удалось сделать его понастоящему красивым и выразительным с помощью RSpec (который стал возможен благодаря изумительным возможностям метапрограммирования Ruby), Cucumber (с помощью которого приемочные тесты можно описывать на естественном языке) и многих других инструментов. В стремительно меняющейся экосистеме Ruby и Railsпроектов зачастую используются не только самые последние возможности привычных СУБД, но и нереляционные СУБД. Самой популярной, «основной», СУБД для Rails-проектов остается PostgreSQL, и многие полезные нововведения, например JSONB, уже привычны в Rails-проектах. Redis используется повсеместно как основная нереляционная СУБД, часто для хранения очереди задач приложения. А использованием ElasticSearch, MongoDB и даже некоторых БД для работы с большими объемами данных уже никого не удивишь.

Карьера/Образование Как правило, Ruby-программист знает и активно использует сразу несколько серверных языков: с чем-то он был знаком еще до Ruby, что-то изучает для задач, где Ruby мало применим. Сейчас среди Ruby-разработчиков крайне популярны Go (из-за простоты и быстрого освоения), функциональные языки (Erlang, Clojure, даже Haskell), Elixir (напрямую вдохновленный Ruby язык для работы на виртуальной машине Erlang). Из альтернативных реализаций Ruby можно отметить JRuby – полностью реализованная поверх виртуальной машины Java-реализация Ruby, с каждой версией работающая все быстрее и быстрее. И, конечно, Ruby-разработчики пользуются инструментами для организации совместной работы. Работа во многих Ruby-проектах построена на гибких (Agile) методологиях разработки, для поддержки которых нужны соответствующие трекеры. Удаленная работа стала привычной для стартапов, поэтому общение через мессенджеры вроде Slack или аналоги давно стало частью работы. К уровню образования разработчиков в наше время особенных требований нет: в индустрии есть великолепные разработчики и без высшего образования, есть с образованием лингвистическим или юридическим. Конечно, отличное CS-образование (Физтех, ВМиК МГУ и другие достойные университеты) будет только кстати, особенно при дальнейшем профессиональном росте – работе с машинным обучением, например.

Ильдар Шайнуров, технический директор компании MetaStudio

1. В первую очередь, как и программисту на любом другом языке, нужно уметь думать. Говоря о программистах на Ruby, в большинстве случаев подразумевают Ruby on Rails и все сопутствующие навыки: Git, понимание принципов HTTP, хороший опыт работы с базами данных (обычно это MySQL и PostgreSQL), html/css/js.

2. Руки, Unix-подобная система (Mac OS или Linux), любой удобный программисту редактор (мы, например, используем Sublime Text). В работе постоянно приходится использовать терминал. Обязательно https:// www.ruby-toolbox.com для поиска нужных гемов. Код в основном храним на github.com либо bitbucket.com.

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

4. Зависит от того, на какую должность/зарплату приходит кандидат. Если для Senior, то минимум 3 года на Ruby. Если Junior, то можно и вообще без опыта работы. Но, кроме опыта работы, обязательно просим всех выполнить тестовое задание. Люди разные и учатся с разной скоростью, кто-то и 5 лет может проработать Ruby-программистом и не знать простейших вещей, а кто-то за пару лет до сениора дорастает. Также смотрим, на каких проектах до этого работал и в каких командах. Если 5 лет просидел на одном проекте в одиночку, то ни о каком опыте там речи быть не может. Поэтому предпочтение отдадим тому, кто работал на большом количестве проектов и в большой команде. Также будут интересны кандидаты, у которых есть опыт работы с Open Sourсe, есть какие-то свои проекты.

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

рынок труда

Евгений Родионов, сооснователь, программист KitchenCoders

1. Достаточно широкий портфель. Ruby – как опорный язык, Ruby on Rails – фреймворк. Желателен опыт с различными типовыми gem (библиотеки). Например, Devise – для работы с моделями пользователя, Capistrano – для деплоя приложения.

2. IDE (мне по душе Atom, Text mate), контроллер версий (Git), mac (на мой взгляд, удобен для развертывания тестовой среды). Интернет.

3. Практические навыки. Нам все равно, какое образование. Главное – выполнить поставленную задачу и сделать это максимально аккуратно и рационально. Умение работать в команде, потому что часто даже небольшие проекты пишутся 2-3 людьми, имеющими определенную специфику (скажем, классическое деление – бэкенд, фронтенд).

4. В зависимости от позиции. От года работы, желательны продакшнпроекты. Свой Git с примерами.

5. Особо нет.

Вклад потенциального сотрудника в Open Source, его выступления и статьи намного важнее, чем «корочка» университета. Формальные требования к опыту работы (вроде X лет работы с определенной технологией или Y лет в «статусной» должности) при найме в классные команды отошли в прошлое и остались только в арсенале компаний для массового найма сотрудников. Важно знать, чем именно кандидат был полезен на предыдущем месте работы, как лично он сделал компанию лучше. Должность тоже мало о чем говорит: зачастую бывшие технические директора или начальники разработки просто не могут пройти собеседование лучше, чем вчерашние новички, только что закончившие университет. Минимальное обязательное требование по опыту для работы в «Марсианах» – весомый интересный опыт работы в реальном коммерческом проекте или отличное Open Source-портфолио. Последнее обязательно для найма на позицию младшего (Junior) программиста. Специфических требований к работе в «Злых марсианах» два – это отличная способность к работе в распределенной команде и увлечение Open Sourceразработкой. В распределенной (удаленной) команде все недостатки в организации, особенно в самоорганизации сотрудников, становятся видны намного быстрее, чем в традиционной «офисной» команде. Требования к самодисциплине намного выше, чем в других командах: важно делать точные оценки, отвечать за поставку функционала в срок, всегда быть на связи и управлять ожиданиями как заказчика, так и членов своей команды. Особые требования предъявляются к коммуникации: важно не стесняться задавать вопросы, хорошо документировать свои решения, унылым часовым митингам предпочитать быстрые пятиминутные созвоны, быть дружелюбным и отзывчивым. Увлечение Open Source – не только кармическая особенность (если бизнес построен на использовании открытых продуктов, нужно поддерживать сообщество самому и делиться своим трудом). Участие в Open Source крайне важно для самообразования, особенно для начинающих программистов. Новые открытые проекты и развитие существующих помогают программисту самореализоваться, а компании – найти единомышленников в команду.

июнь 2016 системный администратор

рынок труда

Евгений Фатеев, инженерпрограммист в Instamotor Ruby – удивительный язык программирования. Он был создан в 1995 году в Японии и долгое время не покидал пределов этой страны. Со временем ситуация изменилась: стала появляться документация на других языках, а с выходом фреймворка Rails Ruby покорил сердца многих разработчиков. Тому есть множество причин, все же одна из основных, на мой взгляд, в том что «Ruby был создан для того, чтобы сделать программистов счастливыми». Это слова автора языка – Юкихиро Мацумото, которые в полной мере воплощаются в ядре и всей экосистеме языка. Ruby обладает невероятно элегантным синтаксисом и широчайшими возможностями, среди которых динамическая типизация, превосходная работа с блоками, итераторы и великолепная объектно-ориентированная модель. На сегодняшний день это развитая экосистема с огромным количеством проверенных задачами и временем библиотек, зрелыми фреймворками, большим количеством книг и блогов и крайне дружелюбным сообществом. Ruby находит применение не только в современных вебприложениях, но и в самых разных сферах, например: менеджер пакетов для Mac OS Homebrew или среда для создания музыки в реальном времени Sonic Pi. Ответить на этот вопрос можно по-разному. С моей точки зрения, знания и навыки программиста Ruby состоят из трех измерений. Первое измерение – конечно, знание языка. На первый взгляд Ruby очень прост (и это действительно так),

Станислав Герман, руководитель группы разработки Ruby-проектов Rambler&Co

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

2. Базы данных, как реляционные (PostgreSQL, MySQL), так и не очень (mongo). Различные сервисы для background job processing (Rescue, Sidekiq). Инструменты для тестирования: Rspec, minutest, capybara. В качестве системы контроля версии Git. Инструменты для деплоя (Сapistrano, Mina). Многопроцессные или многопоточные веб-серверы (unicorn, passenger).

3. Ценза по уровню образования нет, но мы ожидаем увидеть хорошую теоретическую подготовку.

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

5. На Ruby у нас реализуются контентные проекты, поэтому большим плюсом для кандидата будет опыт работы в электронных СМИ.

системный администратор июнь 2016

Карьера/Образование Серафим Ненароков, веб-разработчик в компании «Флант» (http://flant.ru)

1. Голова на плечах и хорошие знания языка и ООП. Остальное зависит от специализации. Обычно веб-разработчику необходимо владение Ruby on Rails и крайне желательны навыки TDD.

2. Удобный редактор (SublimeText/Atom/RubyMine/vim/...), Git, GitHub, Ruby-Gems, Rspec.

3. Не думаю, что отсутствие высшего образования может помешать адекватному программисту устроиться на работу.

4. Если человек талантливый и подает надежды, его можно взять и без опыта, все зависит от конкретной ситуации. Если говорить о вебразработке, то человек, хорошо знакомый с другими MVC-фреймворками, обычно быстро осваивается в Ruby on Rails.

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

но это лишь верхушка айсберга. Если погрузиться глубже, мы увидим продвинутую работу с блоками и прок-объектами, метапрограммирование и рефлексию, синглтон-объекты и еще множество возможностей. Какие-то из них используются чаще других, все же хорошее знание и понимание работы языка является необходимым. Второе измерение – парадигмы и техники программирования, в особенности ООП и SOLID принципы. Каким бы мощным ни был язык, если мы точно не представляем, что хотим создать, разрабатываемое нами ПО вряд ли получится надежным и хорошо расширяемым. Именно поэтому очень важно понимать концепции программирования. Например, если копнуть поглубже в ООП, мы обнаружим, что такой образ мышления очень близок тому, как думают люди. Мы часто взаимодействуем с объектами, посылаем им сообщения и ждем результат. Видеть эту связь между реальным миром и программным кодом, на мой взгляд, крайне важно. Это позволяет писать более понятный и легкий в сопровождении код. Паттерны программирования также являются превосходным вкладом в копилку знаний и навыков Ruby-программиста. Третье измерение – это окружение и смежные технологии. Под окружением я понимаю IDE и текстовые редакторы, SQL-клиенты и все прочие инструменты, которые используются в повседневной работе. Ведь чем совершеннее инструмент и чем лучше мы им владеем, тем более качественный результат можем получить. Смежные технологии также невероятно важны. Будем откровенны, современный мир программирования требует гораздо более обширных знаний, чем знания Ruby. Достаточно часто Ruby используется при написании веб-приложений, а это автоматически подразумевает знания в области JavaScript и HTML. С другой стороны, несмотря на мощную поддержку ActiveRecord для работы с СУБД, знание SQL крайне пригодится. Не стоит также забывать о самых Ruby-фреймворках (таких как Rails, Grape, Sinatra, Hanami) и системах управления исходным кодом (Git). Таким образом, третье измерение включает в себя рабочее окружение и любые смежные технологии, которые используются (или могут использоваться) в проекте.

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

Как мы уже успели сказать, конечно же, первым и самым основным инструментом является сам язык. Сюда же стоит отнести стандартную библиотеку Ruby, фреймворки и gem (сторонние библиотеки). Следующая категория инструментов – рабочее окружение. Сюда относятся IDE и текстовые редакторы, графические SQL-клиенты, различные расширения веб-браузера (например, REST клиент), средства для создания диаграмм, графические Git-клиенты. Иными словами, все то, что помогает в решении поставленных задач. На мой взгляд, рабочее окружение должно быть прозрачным, то есть таким, чтобы программист не тратил время на доступ к истории файла с исходным кодом, объединение Git-веток или другие сопутствующие решению задачи операции. Требования компаний, безусловно, зависят от уровня самих компаний. Например, если вы претендуете на должность Ruby/Rails-программиста, от вас могут потребоваться базовые (иногда более продвинутые) знания Rails, HTML, JavaScript (иногда JavaScript-фреймворка). Этого может оказаться вполне достаточно для написания относительно простых веб-приложений без высокой нагрузки и специфических требований. С другой стороны, если вы хотите работать над высоконагруженным проектом с большим количеством специфических требований и с применением смежных технологий, вам потребуется глубокое знание языка и фреймворка, знания и навыки в написании API, хорошие знания ООП, SOLID и других принципов программирования, знания паттернов программирования, умение выстраивать архитектуру

Анатолий Пронин, Ruby-разработчик, компания VoltMobi

1. Необходимые знания и навыки для веб-разработчика в нашей компании: фундаментальные знания по архитектуре компьютеров; принципы ООП, SOLID, GRASP, CQS и шаблоны проектирования; знание основных структур данных; оценка сложности алгоритмов; знание синтаксиса языка Ruby; мета-программирование в языке Ruby; тестирование (Minitest, Code Coverage).

2. Необходимый инструментарийдля веб-разработчика в нашей компании: компьютер/ноутбук под управлением Ubuntu или Mac OS; Vagrant/ Docker для разработки приложений, изолированно от основной системы; среда разработки – Vim (сборки), RubyMine.

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

4. Количество предыдущих лет – 1 год или 5 лет, не имеет значения. Важно то, насколько он грамотно подходит к решению любой задачи, какие навыки и знания демонстрирует при этом. Очень важен опыт анализа, декомпозиции и постановки задачи, так как это играет важную роль при ее решении. Также важен опыт командной работы, так как чаще всего на проектах трудится больше одного разработчика.

5. Основное направление компании – мобильная разработка, поэтому для Ruby-разработчика важны знания по проектированию архитектуры приложений, по устройству HTTP-протокола, по разработке API для мобильных приложений, то есть back-end-разработка.

рынок труда приложения и разбираться в предметной области. Может потребоваться знание инструментов поиска (например, ElasticSearch) или очереди сообщений (RabbitMQ), различных протоколов (HTTP, AMQP, MQTT). Этот список можно расширять и расширять, и он в большей степени зависит от специфики проекта и предпочтений компании. Если попробовать абстрагироваться от конкретных технологий, на мой взгляд, требования к сотруднику можно сформулировать так: умение думать и способность развиваться. Что касается именно требований к образованию, здесь также многое зависит от политики компании. Однако в моей практике, мне ни разу не потребовался диплом, поскольку знания и навыки оцениваются исходя из беседы с кандидатом, и их источник не имеет значения. С другой стороны, академическая среда положительно влияет на развитие и становление специалиста, поэтому, на мой взгляд, получение диплома стоит усилий и времени. Требования к опыту работы также зависят от политики компании и рассматриваемой должности. Если вы претендуете на позицию уровня Junior, вряд ли кто-то будет ожидать от кандидата участия в большом количестве проектов. Хотя в этом случае наличие собственных наработок, конечно же, необходимо. Иными словами, вы можете написать проект для решения собственной задачи (например, приложение для формирования плей-листа) и рассказать, с какими трудностями столкнулись, как их разрешили, какие технологии использовали и почему. Позиция уровня Middle, на мой взгляд, подразумевает хорошее знание языка, участие в нескольких проектах, собственное видение архитектуры приложений и умение работать автономно. Уровень Senior говорит сам за себя. Глубокие знания языка, парадигм и принципов программирования, опыт разработки большого количества проектов с различными специфическими требованиями, умение проектировать и реализовывать архитектуру проекта. Опыт на этом уровне не имеет ограничений и во многом зависит от индивидуального пути каждого программиста. Если оценивать опыт с позиции времени, я бы не рискнул давать какие-то оценки. Разные специалисты за одно и то же время могут достигнуть разных результатов. Это обуславливается как индивидуальными особенностями, так и средой, в которой работают специалисты. И все же, если попробовать дать оценки, на мой взгляд, их можно выстроить так: 1-3 года для Junior, 3-5 лет для Middle, 5-7...<настоящее_ время> для Senior. Да, безусловно, специфические требования есть. Они во многом зависят от предметной области, в которой работает компания. Например, платформа для обучения почти наверняка потребует разработки системы мгновенных сообщений. Приложение для работы с рынком ценных бумаг или в медицинской сфере скорее всего будет подразумевать глубокое знание предметной области. Приложения из сферы электронной коммерции (интернет-магазины), вероятно, потребуют продвинутую систему поиска, механизмы для реализации платежей и аналитики. Я бы сказал, что почти любая компания имеет свои специфические требования. Справиться с ними кандидату помогут хорошие позиции по трем рассмотренным измерениям знаний и навыков и принципиальное умение решать задачи.

июнь 2016 системный администратор

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

рынок труда

Илья Аверьянов, директор службы разработки в компании FunBox

Андрей Куманяев, Software Engineer (не имеет права разглашать своего работодателя)

ния Ruby и фреймворк Ruby on Rails. Иногда даже шутят по поводу того,

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

Как и любой разработчик, он должен в первую очередь быть любознательным, внимательным и сообразительным. Если говорить о конкретных знаниях по языку Ruby и смежным технологиям, то состоявшийся Ruby-программист должен: > знать сам язык Ruby и его стандартные библиотеки; > знать Ruby оn Rails в объеме как минимум http:// guides.rubyonrails.org (Ruby без Rails – это все еще очень узкая ниша); > знать принципы работы сетевых протоколов (TCP, HTTP, HTTPS, FTP...); > знать принципы работы веб-серверов и балансировщиков нагрузки (Nginx, HAProxy...); > знать принципы построения фронтенда для веб-приложений, иметь представление о хотя бы одном из популярных JS-фреймворков; > уметь работать в Linux shell на уровне опытного пользователя; > уметь работать с реляционными БД, знать SQL в чистом виде, понимать принципы индексации данных; > уметь работать с некоторыми из NoSQL БД; > уметь взаимодействовать с другими разработчиками, свободно обращаться с Git; > уметь работать с различными представлениями времени, таймзонами (это целый отдельный навык); > понимать уместность и необходимость тестирования кода; > владеть знаниями об архитектуре программных решений, плохих и хороших паттернах; > иметь адекватное представление о своих возможностях, о применимости различных технических средств к поставленным задачам. Инструменты для разработки, запуска и отладки решений на Ruby разнообразны, всевозможных библиотек также существует огромное количество, выделять какието конкретные нет особого смысла – все зависит от проекта и от задачи. Однако есть несколько стандартных для разработки действий, для которых нужны надежные, знакомые и отлаженные инструменты (хотя они могут и различаться): > инструмент для воспроизведения окружения для проекта, т.е. для работы с виртуальными средами (Docker, Vagrant, Amazon...) и их настройки (Ansible, Bash, SaltStack...); > инструмент для работы с кодом проекта (хорошо настроенный Vim, Emacs, Sublime, Atom или, например, IDE RubyMine), поиска по коду; > инструменты для работы с историей кода и ее анализа. В компании мы смотрим на реальный опыт и навыки; высшее образование желательно, но не обязательно. При этом системное мышление, техническая грамотность и аккуратность для нас часто намного важнее, чем пассивный багаж знаний в профильных для нас технологиях. Мы достаточно крупная компания, поэтому для нас вопрос стоит немного по-другому. От опыта работы зависит

что Ruby без Ruby on Rails умер бы. Да, я не просто так упомянул о них в самом начале. Потому что Ruby используется не только для веб-проектов. Как пример можно привести Chef, Capistrano и другие продукты и инструменты. Поэтому для ответа на этот вопрос стоит сначала определиться, в какой отрасли вы будете его использовать. Соответственно, в зависимости от отрасли необходимо удовлетворять определенным квалификационным требованиям. А теперь к тому, что должен уметь разработчик на Ruby (я намеренно не буду перечислять требования к Ruby как к объектно-ориентированному языку программирования, они для всех языков едины): > Дружить с головой. Увы, этот язык позволяет легко переметнуться на темную сторону силы и выстрелить себе в ногу из дробовика. Экосистема включает очень много «готовых» решений на все случаи жизни, но не каждое из них можно или стоит использовать. Вам нужно уметь отфильтровывать хорошее и плохое. > Уметь черпать информацию из многих источников. Если вы не будете следить за развитием языка и крупных проектов на нем – вы очень быстро станете аутсайдером. > Понимать работу основных продуктов, которые вы будете использовать (например, nginx, postgresql, redis и другие). Большая часть задач обычно выносится из Ruby, так как он не настолько быстр и не является серебряной пулей. > Понимание работы ОС и владение основами bash. > Придется учить еще какие-нибудь языки. Мне в своей работе пригодились и JavaScript, C, Java, Erlang, Clojure.

2. Большую часть работы разработчик на Ruby проводит в своем редакторе + консоли. Написание кода, проверка работы, тесты. Этих двух инструментов достаточно для большинства разработчиков. Дальше уже смотреть по задачам и специфике работы. При работе с большим проектом (особенно незнакомым) довольно сложно обойтись без IDE наподобие RubyMine. Вторая часть – это переиспользование трудов комьюнити, и тут без github и google никак не обойтись. В-третьих, хорошо бы уметь работать с инструментами виртуализации (Docker, Vagrant и т.п.) и хранить проекты изолированно. Все остальные задачи (например, профилирование Ruby-кода) могут потребовать использования отдельных инструментов, которые меняются и обновляются довольно часто (в зависимости от версии языка).

3. Потенциальный сотрудник должен обладать прокачанной смекалкой и иметь широкий кругозор. Фундаментальное понимание программирования, работа с Linux и командной строкой, написание автоматических тестов, алгоритмическое мышление, работа с базами данных, знание SQL, объектно-ориентированное программирование, понимание протокола HTTP, знание инструментов Configuration Management – так или иначе серьезный разработчик должен все это знать (или понимать, о чем идет речь) и не ограничиваться только этим списком.

4. Опыт работы – штука очень скользкая. Человек может отработать 10 лет в студии и не уметь ничего, а может не иметь опыта работы «на дядю» и быть гениальным разработчиком. Тут важнее навыки, чем запись в трудовой.

5. Все специфические требования обычно указываются в вакансиях.

3 4

системный администратор июнь 2016

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

Подготовил Игорь Штомпель 79

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

рынок труда

Работодатели-мошенники атакуют в сети С января 2016 года увеличилось число обращений граждан на горячую линию Рунета, обманутых недобросовестными работодателями в сети. Более половины жалоб относится к работодателям, предлагающим соискателям, еще до трудоустройства, приобрести что-то для выполнения работы или пройти платное обучение

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

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

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

3. Платное обучение или «что-то купить» Пример: Работодатели-мошенники предлагают купить методические материалы до начала работы, чтобы изучить их самостоятельно. Бывает, что работодатели просят зарегистрироваться на каком-либо платном образовательном ресурсе или приобрести сертификат/лицензию у конкретного продавца.

4. Дистанционная работа Пример: Соискателям предлагают оставить крупную сумму в залог того, что они действительно не подведут и выполнят порученную работу. Бывают случаи, когда работодатели-мошенники просят перевести некоторую сумму «для открытия электронного кошелька», на который якобы будут впоследствии переводить зарплату.

2. Платные звонки и смс

5. Выманивание паспортных данных

Пример: На электронную почту соискателя приходит письмо якобы от заинтересовавшегося работодателя. Суть письма в том, что соискателя приглашают на собеседование,

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

Признаки недобросовестного работадателя (взято из инфографики «Ищите работу? Избегайте мошенников!», созданной РОЦИТ совместно с SuperJob)

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

июнь 2016 системный администратор

рынок труда

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

«Предложили в интернете работу по распределению денег по счетам с оплатой 0,5% от общей суммы перевода. Для получения заработанных денег я должен приобрести карту для зачисления на нее. Сумма оплаты карты составляет $200, но компания компенсирует эти расходы 100%. Теперь ни каких денег не видно».

такие как superjob.ru, hh.ru и career.ru. Ими пользуются около 37% опрошенных. Чуть реже при поиске работы соискатели обращаются к друзьям, родственникам и знакомым. Об этом заявили 20% респондентов.

«Я живу в Питере. Высшего образования у меня нет, но для вакансии курьера в Финляндию это было не важно. Зарплату предлагали высокую, и работодатель показался мне добросовестным. Я общалась с будущим работодателем по электронной почте и сотовому телефону. Для создания для меня рабочей визы работодатель попросил оплатить 5 тыс. руб. и выслал номер яндекс-кошелька. Я перевела деньги. После этого мое общение с ним прекратилось – ни денег, ни работы».

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

В связи с увеличением жалоб и внимания к вопросу трудоустройства РОЦИТ совместно с SuperJob провел опрос населения и подготовил инфографику «Ищите работу? Избегайте мошенников!», которая станет подсказкой для соискателей в поиске честного работодателя. По данным РОЦИТ, самыми популярными ресурсами для поиска вакансий являются специализированные сайты,

Замыкают тройку поисковые системы (Яндекс, Google и др.), к их помощи в поиске прибегают 15% интернет-пользователей. Найти подходящую вакансию – это еще не все. Не менее важно изучить всю информацию о потенциальном работодателе. Чаще всего для этого пользователи просматривают официальный сайт организации-работодателя (28%) или вновь обращаются за помощью к поисковикам (22%). Однако наиболее достоверную информацию, по мнению 47% пользователей, можно найти на специализированных форумах с отзывами на работодателей. Бывает и так, что соискатели не обращают должного внимания на полноту наполнения сайта организации-работодателя. 23% считают, что на официальном сайте не обязательно должна быть новостная лента, 20% пренебрегают важностью информации о директоре и сотрудниках компании. Но наиболее критично, что 16% соискателей готовы рассматривать работодателя как потенциального, даже если на его сайте нет уставных и прочих организационных документов компании. РОЦИТ рекомендует соискателям ответственно и внимательно относиться к выбору работодателя, в первую очередь стараясь самостоятельно избегать мошенников в сфере трудоустройства. EOF

Правила для соискателей (взято из инфографики «Ищите работу? Избегайте мошенников!», созданной РОЦИТ совместно с SuperJob)

Жалобы соискателей на горячую линию Рунета (взято из инфографики «Ищите работу? Избегайте мошенников!», созданной РОЦИТ совместно с SuperJob)

«До момента зачисления в штат сотрудников и на последнем этапе интервью работодатель попросил меня пройти тест онлайн! Стоимость теста 5 тыс. рублей! Менеджер, с которым я связывалась, отправила мне в смс номер электронного кошелька, на который нужно перевести деньги, чтобы пройти тестирование. Стоит ли мне платить за тест?» «Работодатель попросил заплатить за уникальную методику по работе на фондовой бирже, разработанную их компанией. Работа предполагалась удаленная. Я заплатил, получил на почту методику, но она не является уникальной. В интернете полно схожих материалов! Теперь не могу дозвониться до работодателя. Заплатил за методику 3000 рублей и не работаю. Видимо, это мошенники».

системный администратор июнь 2016

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

лабораторная работа

Визитка

ВЛАДИМИР ЗАКЛЯКОВ, советник налоговой службы 2-го ранга, zaklyakov@samag.ru

Лабораторная работа Исследуем сокеты. Часть 3 (окончание) В предыдущих номерах [1, 2] был описан инструментарий для проведения исследований. В данной части предлагается самостоятельно выполнить ряд практических заданий

Начнём эксперименты Теперь, когда вам известны цели работы, схема исследований, устройство и подготовка лабораторного стенда (см. [1, 2]), в данной завершающей части вам предстоит почувствовать себя исследователем и выполнить несколько несложных практических заданий самостоятельно, после чего вы сможете оценить полученные результаты и связать свои теоретические знания с практикой. Возможно, не лишним будет программа TCP-сервер на языке Си, поэтому приводим её ниже. tcp_server1.с – простой TCP-сервер, обрабатывающий одновременно одно соединение #include #include #include #include #include #include #include #include

// номер порта для приёма входящих соединений сервером #define PORTNUM 1234 int main(void) { int listen_s, connected_s, nbytes; struct sockaddr_in serv_addr, clnt_addr; char buf[256]; // буфер для приёма сообщения unsigned long addr; if ( (listen_s=socket(PF_INET, SOCK_STREAM, 0) ) == -1 ) { perror("Ошибка вызова socket()"); exit(1); } /* Заполняем, предварительно обнулив, структуру serv_addr для описания «своего» конца коммуникационного канала: указываем семейство адресов AF_INET (то есть IP-адреса); входящий адрес сокета INADDR_ANY (0.0.0.0) означает принимать соединения на всех имеющихся у хоста адресах. */ bzero(&serv_addr, sizeof(serv_addr)); serv_addr.sin_family=AF_INET; serv_addr.sin_addr.s_addr=INADDR_ANY; serv_addr.sin_port=htons((u_short)PORTNUM);

/* Связываем сокет listen_s с адресом и портом, содержащимися в serv_addr, определяя локальную часть коммуникационного канала. */ if ( bind(listen_s, (struct sockaddr *)&serv_addr, ↵ sizeof(serv_addr)) == -1 ) { perror("Ошибка вызова bind()"); exit(2); } /* Переводим сокет в режим ожидания соединений – фактически в модуль TCP передаётся вызов PASSIVE_OPEN. Второй параметр задаёт максимальный размер, до которого может расти очередь ожидающих соединений у listen_s. */ if ( listen(listen_s,10)==-1 ) { perror("Ошибка вызова listen()"); exit(3); } printf("Сервер готов принимать соединения\n"); /* Обнуляем структуру clnt_addr, в которую будут записаны адрес и порт подсоединившегося клиента. */ int addrlen; bzero(&clnt_addr, sizeof(clnt_addr)); addrlen=sizeof(clnt_addr); /* Принимаем запрос. Возврат из функции accept() производится только после поступления запроса и установления соединения с клиентом. При этом на базе старого сокета listen_s создаётся новый сокет connected_s, у которого определены уже обе части соединения – локальная и удалённая. Таким образом, сокет connected_s уже может использоваться для передачи данных. Адрес и порт подсоединившегося клиента возвращаются в структуре clnt_addr. */ if ( (connected_s=accept(listen_s, ↵ (struct sockaddr *)&clnt_addr, &addrlen) ) == -1 ) { perror("Ошибка вызова accept()"); exit(4); } printf("Соединение от %s\n", inet_ntoa(clnt_addr.sin_addr)); nbytes=recv(connected_s, buf, sizeof(buf)-1, 0); if (nbytes>0) { buf[nbytes]='\0'; printf("Получено сообщение: %s\n", buf); }

июнь 2016 системный администратор

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

лабораторная работа printf("Завершаем работу, закрываем сокет.\n"); close(connected_s); close(listen_s); exit(0);

Шаг 6. Запустите команду: $ ps aux

}

Самостоятельная доработка программ Программа, реализующая серверную часть TCP-сокета, способна принимать лишь одно входное соединение одновременно. На практике же практикуются множественные клиентские подключения одновременно. Такую возможность можно добавить за счёт использования функции fork(). Она создаёт дубликат процесса, возвращая в родительский процесс идентификатор порождённого дочернего процесса, а в дочерний – ноль. Это позволит одновременно делать две вещи: работать с установленным соединением через сокет connected_s, а дубликату процесса продолжать принимать новые соединения через старый сокет listen_s. Также программа принимает лишь одно сообщение от клиента и завершает работу. На практике можно реализовать приём нескольких сообщений циклом. На сервере или на клиенте может иметься возможность автоответа, то есть автоматическое отправление противоположной стороне сообщения в ответ на приём какогото ключевого слова или команды.

Найдите среди списка всех процессов тот, что отвечает за работу серверного сокета. Шаг 7. Запустите сниффер. $ su -

(введите пароль для повышения своих прав, выход из этого режима – exit) # tcpdump -i lo -n

Он начнёт перехватывать данные на интерфейсе lo.

В результате выполнения заданий вы получите практические навыки работы с сокетами с помощью стандартных средств ОС Linux

Задания для пошагового выполнения Шаг 1. Войдите в систему. Шаг 2. Запустите три терминальных окна: для клиента, для сервера и для исследования. Шаг 3. Запустите прослушивать сокет на порту 1234 протокола TCP на серверной стороне:

Шаг 4. В окне для исследования просмотрите занятость портов для протокола TCP: $ netstat -t -a -n

0 0.0.0.0:1234

0.0.0.0:*

LISTEN

$ ss -t -a -n ... LISTEN ...

$ nc 127.0.0.1 1234

Обратите внимание на то, что после подключения в окне диагностики сниффер покажет информацию о прохождении нескольких пакетов.

$ nc -l 1234

... tcp ...

Шаг 8. Перейдите в окно клиента и подключитесь к серверу:

*:1234

*:*

Найдите в выводе строку, отвечающую за ваш прослушивающий сокет. Шаг 5. Запустите последовательно команды $ lsof $ lsof -i $ lsof -i TCP -n -P COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nc 2691 user 3u IPv4 20425 0t0 TCP *:1234 (LISTEN)

Сравните вывод и найдите PID процесса, ожидающего подключения на порту 1234 протокола TCP.

системный администратор июнь 2016

09:51:01.490961 IP 127.0.0.1.54908 > 127.0.0.1.search-agent: Flags [S], seq 1468622890, win 65495, options [mss 65495,sackOK, TS val 1444852 ecr 0,nop,wscale 7], length 0 09:51:01.490982 IP 127.0.0.1.search-agent > 127.0.0.1.54908: Flags [S.], seq 2911204310, ack 1468622891, win 65483, options [mss 65495,sackOK,TS val 1444852 ecr 1444852,nop, wscale 7], length 0 09:51:01.490994 IP 127.0.0.1.54908 > 127.0.0.1.search-agent: Flags [.], ack 1, win 512, options [nop,nop,TS val 1444852 ecr 1444852], length 0

Это клиент и сервер установили соединение. Шаг 9. Наберите на стороне клиента «Привет сервер! Hello server!» и отправьте его на сервер нажатием <Enter>. Сниффер покажет перехват ещё одного пакета. В окне сервера появится отправленное сообщение. 09:53:24.397337 IP 127.0.0.1.54908 > 127.0.0.1.search-agent: Flags [P.], seq 1:42, ack 1, win 512, options [nop,nop, TS val 1587758 ecr 1444852], length 41 09:53:24.397564 IP 127.0.0.1.search-agent > 127.0.0.1.54908: Flags [.], ack 42, win 512, options [nop,nop,TS val 1587758 ecr 1587758], length 0

Шаг 10. Выполните такую же операцию на стороне сервера, отправив клиенту сообщение «Привет клиент! Hello client!».

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

лабораторная работа

Клиент получит сообщение, а сниффер зафиксирует факт передачи данных.

Шаг 16. Запустите сниффер и сервер повторно, но с другими ключами:

09:54:37.185271 IP 127.0.0.1.search-agent > 127.0.0.1.54908: Flags [P.], seq 1:42, ack 42, win 512, options [nop,nop, TS val 1660546 ecr 1587758], length 41 09:54:37.185317 IP 127.0.0.1.54908 > 127.0.0.1.search-agent: Flags [.], ack 42, win 512, options [nop,nop,TS val 1660546 ecr 1660546], length 0

# tcpdump -i lo -n -nn -X -s 200 $ nc -l 1234 -v

Шаг 11. Прервите работу сниффера нажатием <CTRL> + <C>. Что означает «127.0.0.1.search-agent»? Внимательно просмотрите файл /etc/services (например используя cat и фильтр grep 1234) и вспомните, что у tcpdump есть также ключ -nn, используйте его в следующий раз. Шаг 12. Ответьте на вопросы: сколько пакетов было передано в результате информационного обмена клиента с сервером? Сколько пакетов было от клиента к серверу? Сколько пакетов было в обратном направлении? Какого размера (параметр length) были пакеты? Это размер с заголовками канального/сетевого уровня или нет? Шаг 13. В окне для диагностики выполните запуск команд: $ $ $ $ $ $

lsof -i TCP -n -P lsof -i TCP -n -P | grep 1234 ss -t -a -n ss -t -a -n | grep 1234 netstat -t -a -n netstat -t -a -n | grep 1234

Оцените, что изменилось по сравнению c выводом при выполнении команд из шагов 4 и 5. Поскольку вы видите статистику одновременно и для клиента и для сервера, то вы будете видеть сокет клиента в режиме установленного соединения (ESTABLISHED), сокет сервера в режиме установленного соединения (ESTABLISHED), а также сокет сервера в режиме прослушивания (LISTEN), поскольку команда nc может принять ещё одно соединение. Шаг 14. Если у серверной части nc имеется слушающий сокет, то сможет ли к нему подключиться ещё один nc-клиент и передать сообщение? Запустите ещё одно окно терминала и выполните команду по запуску второго клиента: $ nc 127.0.0.1 1234

Отправьте с обоих клиентов и с сервера сообщения и проследите, кто их получит. Может создаться впечатление, что соединение у второго клиента есть, но данные не передаются. Посмотрите список открытых файлов и сравните его с п.13: $ lsof -i TCP -n -P | grep 1234

Что поменялось? Обратите внимание на номера процессов (вторая колонка – PID) в выводе. Ответьте, является ли соединение второго клиента полноценно установленным? Шаг 15. Прервите выполнение серверов и клиентов, нажимая <CTRL> + <C>.

Шаг 17. Подключитесь клиентом. Повторите посылку сообщений «Привет сервер! Hello server!» и «Привет клиент! Hello client!». Видите ли вы среди перехваченных данных ваше сообщение? Видите ли вы байты, отвечающие за кириллицу? 10:33:08.363361 IP 127.0.0.1.54920 > 127.0.0.1.1234: Flags [P.], seq 1:42, ack 1, win 512, options [nop,nop,TS val 3971724 ecr 3949456], length 41 0x0000: 4500 005d a1ad 4000 4006 9aeb 7f00 0001 E..]..@.@....... 0x0010: 7f00 0001 d688 04d2 1b2f e225 7605 3290 ........./.%v.2. 0x0020: 8018 0200 fe51 0000 0101 080a 003c 9a8c .....Q.......<.. 0x0030: 003c 4390 d09f d180 d0b8 d0b2 d0b5 d182 .<C............. 0x0040: 20d1 81d0 b5d1 80d0 b2d0 b5d1 8021 2048 .............!.H 0x0050: 656c 6c6f 2073 6572 7665 7221 0a ello.server!.

Шаг 18. Оставьте сниффер включённым. Прервите выполнение клиента и сервера. Запустите сервер повторно. Запустите браузер Firefox. Возможно, вы увидите с помощью сниффера, что браузер уже во время своего запуска сгенерировал достаточно трафика. Сервер будет в это время «молчать», ожидая входящие соединения. Шаг 19. Обратитесь к серверу через браузер Firefox, введя в адресной строке http://127.0.0.1:1234. После сообщения от nc о подключении (в старых версиях nc может не показываться): Connection from 127.0.0.1 port 1234 [tcp/search-agent] accepted

вы увидите HTTP-запрос браузера: GET / HTTP/1.1 Host: 127.0.0.1:1234 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Accept: text/html,application/xhtml+xml,application/ xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive

Далее браузер, думая, что подключился к полноценному веб-серверу, будет ожидать ответ. Вероятнее всего, он захочет получить в ответ что-то вида Content-Type: text/html и два символа перевода строки – типичный HTTP-заголовок ответа сервера, а затем и запрошенный корневой файл с сервера – «/». Вы можете игнорировать эти правила обмена (рекомендуемые RFC 2616 и др.), ввести любой текст и закрыть соединение на стороне сервера нажатием <CTRL> + <С>. После этого браузер отобразит полученный от сервера текст.

июнь 2016 системный администратор

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

лабораторная работа Шаг 20. Запустите сервер заново и обратитесь к нему с помощью консольного браузера lynx.

$ nc 1234 -l

Шаг 26. Скомпилируйте программу tcp_client1.c (см. [1, 2]): $ lynx 127.0.0.1:1234 $ gcc tcp_client1.c -o tcp_client1

Обратите внимание, что запрос, передаваемый серверу, несколько отличается. GET / HTTP/1.0 Host: 127.0.0.1:1234 Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01 Accept-Encoding: gzip, bzip2 Accept-Language: en User-Agent: Lynx/2.8.6rel.5 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/1.0.0-fips

Шаг 27. Запустите клиент протокола TCP: $ ./tcp_client1

Дошли ли данные от программы клиента до сервера? Увидели ли вы их с помощью сниффера? Почему сервер закончил прослушивать соединение? Шаг 28. Запустите сниффер tshark и повторите шаги 25 и 27.

Шаг 21. Используйте для обращения wget: # tshark -i lo -n -x $ wget 127.0.0.1:1234

На сервер придёт, отобразившись в окне со сниффером, следующий запрос: GET / HTTP/1.0 User-Agent: Wget/1.12 (linux-gnu) Accept: */* Host: 127.0.0.1:1234 Connection: Keep-Alive

Шаг 22. Завершите выполнение сервера nc. Шаг 23. Обратитесь с помощью браузеров Firefox, lynx и программы wget на локальный веб-сервер на 80-м порту и IP – 127.0.0.1. Изучите информационный обмен клиентов с сервером в окне со сниффером для всех трёх случаев. Если надумаете обратиться к какому-либо серверу в локальной сети или в интернете, то обратите внимание, что сниффер у вас запущен на интерфейсе lo, а обращение в сеть идёт через eth0 (или иной). Шаг 24. Смоделируйте с помощью утилит nc и telnet работу браузера, для этого обратитесь к серверу с HTTP GETзапросом, передав ему строку GET / или GET / HTTP/1.0. В ответ вы получите тестовую страницу. Сниффер покажет прошедшие через интерфейс данные: $ telnet 127.0.0.1 80 Connected to 127.0.0.1. Escape character is '^]'. GET / <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <head> ... </html> Connection closed by foreign host. $ nc 127.0.0.1 80 GET / <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> ...

Шаг 25. Запустите nc как сервер для прослушивания порта 1234 протокола TCP:

системный администратор июнь 2016

Удалось ли вам увидеть переданное сообщение среди информации, перехваченной сниффером? 0.001907785 127.0.0.1 -> 127.0.0.1 TCP 1234 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=21 TSecr=6717340 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 ..............E. 0010 00 49 fe 1e 40 00 40 06 3e 8e 7f 00 00 .I..@.@.>....... 0020 00 01 d6 a9 04 d2 b7 af 81 81 35 b3 5e ..........5.^... 0030 02 00 fe 3d 00 00 01 01 08 0a 00 66 7f ...=.......f...f 0040 7f 9c d0 9f d1 80 d0 b8 d0 b2 d0 b5 d1 ..............! 0050 48 65 6c 6c 6f 21 0a Hello!.

87 54953 > TSval=6717342 00 45 00 01 7f 00 85 80 18 9e 00 66 82 21 20

Шаг 29. Повторите действия шага 28, добавив в строке запуска tshark ключ -V. Насколько больше полезной информации выдал сниффер? Шаг 30. Скомпилируйте TCP-сервер: $ gcc tcp_server1.c -o tcp_server1

Шаг 31. Запустите TCP-сервер, подключитесь к нему с помощью nc и пошлите сообщение «Привет!». $./tcp_server1 $ nc 127.0.0.1 1234 Привет Сервер готов принимать соединения. Соединение от 127.0.0.1 Получено сообщение: Привет Завершаем работу, закрываем сокет.

Шаг 32. Проверьте работу TCP-клиента и TCP-сервера вместе. Шаг 33. Повторите Шаг 32 с минимальной задержкой. Если между шагами 32 и 33 прошло менее минуты, то не получили ли вы при попытке запуска сервера сообщение об ошибке? Ошибка вызова bind(): Address already in use

Карьера/Образование Если да, то попытайтесь устранить ошибку, воспользовавшись советом ниже по устранению этой проблемы. Замечание. Можно заметить, что довольно часто при повторном запуске программы, использующей TCP-серверные сокеты, выдаётся сообщение вида «Ошибка вызова bind(): Address already in use». Однако через какое-то время та же самая программа запускается и работает без этого сообщения. Подробно эта ситуация описана в [3]. Коротко: ситуация происходит потому, что сокеты, установившие соединение, всё ещё «висят» в ядре ОС, и оно «держит» порт занятым. Решение либо подождать (минуту или около того), пока ядро не освободит порт, либо, что более правильно, добавить в программу вызов функции setsockopt(), что позволит повторно использовать уже свободный порт без ожиданий. Для программы tcp_server1.с строки, избавляющие пользователя от указанной ошибки и ожидания, будут выглядеть следующим образом: // избавляемся от ошибки bind(): Address already in use int opt = 1; if (setsockopt(listen_s, SOL_SOCKET, SO_REUSEADDR, &opt, ↵ sizeof (opt)) == -1) { perror("Ошибка вызова setsockopt()"); exit(5); }

лабораторная работа Шаг 39. Завершите клиентский nc нажатием <CTRL> + <C>. Шаг 40. Запустите клиента повторно и отправьте сообщение серверу: $ nc 127.0.0.1 1234 -u

Получил ли сервер сообщение? Был ли сетевой трафик (что зафиксировал сниффер)? Не выдал ли клиент похожую ошибку? nc: Write error: Connection refused

Почему так произошло? Шаг 41. Проанализируйте ситуацию, возникшую на шаге 40, с помощью lsof, netstat и ss, повторив шаги 4, 5, 6. Возможно ли из вывода этих программ понять, почему нет обмена трафиком между клиентским и серверным приложениями? Как решить проблему, чтобы была связь между сервером и клиентом? Шаг 42. Скомпилируйте UDP-клиент (см. [1, 2]): $ gcc udp_client1.c -o udp_client1

Шаг 43. Проверьте работу клиента с помощью сервера на nc. Для этого заново запустите UDP-сервер:

Добавьте вышеприведённый код в файл tcp_server1.c после вызова функции socket() перед вызовом функции bind(). Шаг 34. Перезапустите сниффер с параметрами:

$ nc -l 1234 -u

# tshark -i lo -n -x

а после этого запустите UDP-клиент.

Создайте UDP, слушающий сокет, на порту 1234:

$ ./udp_client1

Шаг 35. Исследуйте серверный сокет командами lsof, netstat и ss, повторив шаги 4, 5, 6. Запомните вывод команды lsof -i -n -P. Шаг 36. Поключитесь с помощью nc как клиент к UDPсерверу:

Была ли осуществлена передача данных клиентом? Увидел ли передачу данных сниффер? Получил и отобразил ли полученные данные сервер? Шаг 44. Обратите внимание, что сервер nc не завершился и продолжает ожидать следующие порции данных. Это явно можно увидеть, используя lsof. Шаг 45. Запустите повторно UDP-клиент:

$ nc 127.0.0.1 1234 -u

$ ./udp_client1

Показал ли сниффер какой-то трафик во время запуска клиента, как это было при установлении TCP-соединения? Шаг 37. Исследуйте открытые сокеты системы командами lsof, netstat и ss, повторив шаги 4, 5, 6. Как изменился после подключения вывод команды lsof -i -n -P? Видите ли разницу по сравнению с использованием TCP-сокетов? Шаг 38а. Пошлите сообщения от клиента серверу и обратно. Проанализируйте трафик, перехваченный сниффером. Как изменился вывод команды lsof -i -n -P? Шаг 38б. Пошлите сообщения от сервера клиенту и обратно. Проанализируйте трафик, перехваченный сниффером. Как изменился вывод команды lsof -i -n -P? Шаг 38в. В чём разница при выполнении между ветками 34-35-36-37-38а и 34-35-36-37-38б? Как изменился после подключения вывод команды lsof -i -n -P?

Была ли осуществлена передача данных клиентом? Увидел ли передачу данных сниффер? Получил и отобразил ли полученные данные сервер? Почему данные не дошли до сервера? Шаг 46. Скомпилируйте UDP-сервер (см. [1, 2]):

$ nc -l 1234 -u

$ gcc udp_server1.c -o udp_server1

Запустите UDP-сервер и UDP-клиент. Передал ли клиент серверу сообщение? $ ./udp_server1 $ ./udp_client1

Шаг 47. Обратите внимание, что сервер продолжает ждать подключения. Запустите UDP-клиент ещё раз.

июнь 2016 системный администратор

лабораторная работа Была ли осуществлена передача данных клиентом? Увидел ли передачу данных сниффер? Получил и отобразил ли полученные данные сервер? Почему данные дошли до сервера? Почему не повторяется ситуация, возникшая на шаге 43? Шаг 48. Поэкспериментируйте с кодом программ на Cи, сделайте доработки, предложенные ранее. Подключите к экспериментам соседние компьютеры и их пользователей. Организуйте обмен трафиком по локальной сети. Может ли UDP-клиент соединиться с TCP-сервером и передать данные? А наоборот? А если проверить экспериментально? Если увеличить значение размера массива buf в использовавшихся программах на Cи и перекомпилировать их, то какого максимального размера можно осуществить передачу данных на практике? Какие будут ограничения, и чем они будут вызваны? Шаг 49. Увеличиваются ли значения счётчиков iptables? Создайте правила и посмотрите, считается ли с помощью них проходящий между клиентом и сервером трафик? # iptables -L -v -x -n # iptables -I INPUT -p udp -s 127.0.0.1

Шаг 50. Запустите сниффер WireShark Network Analyzer и самостоятельно проведите несколько экспериментов.

системный администратор июнь 2016

Карьера/Образование Чем удобнее пользоваться графической средой или консолью?

Подготовьте отчёт, где отразите проделанные шаги. Какие практические моменты для вас оказались существенно новыми или неожиданными при работе с сокетами? Были ли расхождения теории с практикой во время проведения экспериментов, которые вы впоследствии не смогли объяснить? В результате выполнения заданий вы получили практические навыки работы с сокетами с помощью стандартных средств ОС Linux, а также имели возможность скомпилировать код программ на Си и проверить его работоспособность. EOF [1] Закляков В. Лабораторная работа: Исследуем сокеты. Часть 1. // «Системный администратор», №4, 2016 г. – С. 75-79 (http:// samag.ru/archive/article/3179). [2] Закляков В. Лабораторная работа: Исследуем сокеты. Часть 2 (продолжение). // «Системный администратор», №5, 2016 г. – С. 67-71 (http://samag.ru/archive/article/3199). [3] UNIX: разработка сетевых приложений /У. Стивенс. – СПб.: «Питер», 2003. – 1088 с. ISBN 5-318-00535-7. [4] Описание ошибки Bind: Address Already in Use – http://hea-www. harvard.edu/~fine/Tech/addrinuse.html. Ключевые слова: сокет, сетевые утилиты, CentOS, Linux.

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

хроники ИТ

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

Семьдесят лет компьютерной эры Вторая декада: 1956 – 1965 Продолжаем публикацию хроник возникновения, становления и развития информационных технологий*

Режим реального времени Эта декада стала поистине революционной как минимум в двух сферах – космической и интересующей нас компьютерной. Далее следовать тому же формату, в каком были написаны предыдущие статьи цикла, уже невозможно, поэтому приходится переходить к скороговорке, «штриховому» методу. Возникли многие компании, чьи имена сегодня у всех на слуху. В 1955-м слияние Remington-Rand и Sperry Gyroscope привело к образованию Sperry-Rand, а еще через два года от нее отпочковалась Control Data Corporation. В 1958 году Кен Олсен создал фирму Digital Equipment Corporation (DEC). А еще на рынок вышли I.P.Sharp Associates, International Research Corporation (ее создал Уэйн Пикетт для исследовательской деятельности в сфере компьютеризации образования), Intel, Advanced Micro Devices Inc., Micro Instrumentation Telemetry Systems (MITS), Центр исследования цифровой технологии компании Xerox в ПалоАльто (PARC)... Если говорить о компьютерном «железе», то необычайно урожайным оказался 1958 год. Судите сами: первый перцептрон (устройство для распознавания образов), построенный Розенблаттом, Фрэнком Джек Килби с микрочипом первые компьютеры с виртуальной памятью (Atlas, созданный в Манчестерском университете Р.М. Килберном) и первые ласточки из Страны восходящего солнца – модели 1101 и 1102 фирмы NEC. Статистика сообщает: к концу этого года в США в служебном пользовании находилась примерно тысяча ЭВМ, а в Англии – 160...

Занятно, что расцвет вычислительной техники вызвал и первые же судебные тяжбы между ее флагманами. Еще в 1952 году Министерство юстиции США возбудило против компании IBM уголовное дело по одной из статей антимонопольного законодательства (т.н. Закон Шермана). Компанию обвинили в том, что в своем компьютерном бизнесе (точнее, «в создании вычислительной техники, основанной на перфокартах») она превратилась в монополиста. Процесс шел долго, но в 1956-м суд вынес окончательный вердикт, обязав IBM слегка потесниться на рынке. А в 1961-м группа студентов MIT в свободное от учебы время изобрела первую популярную видеоигру – Spacewar!

Переход в виртуальный режим В интересующей нас теме тон по-прежнему задавали не компьютеры, а роботы. Мучимые извечным «франкенштейновым» комплексом по отношению к создателям, они все также вступают в конфликт с человеком в рассказах «СУЭМа» и «Крабы идут по острову» Анатолия Днепрова, а также в рассказах Филиппа Дика «Вторая разновидность» и «Защитники» (все четыре вышли в 1958-м). Есть и более мирные профессии для «стальных братьев наших меньших»: боксеры (рассказ Ричарда Мейтсона «Стальной человек», 1956), полицейские (рассказ Гарри Гаррисон «Робот-полицейский», 1958), садовники (рассказ Брайна Олдисса «Все слезы мира», 1957). А «разумность» роботов проверяется на судебных процессах, как это описано в рассказе Лестера Дель Рея «Присутствие роботов обязательно» (1958).

июнь 2016 системный администратор

хроники ИТ Из других примеров второй половины 1950-х годов можно отметить рассказы Брайна Олдисса «Но кто же заменит человека?» (1958) и Пола Андерсона «Зовите меня Джо» (1957) – последний представляет собой едва ли не первый пример фантастики о киборгах. А первые ласточки фантастики отечественной – роман Ивана Ефремова «Туманность Андромеды» (1957), трилогия Георгия Мартынова «Звездоплаватели» (1954 – 1959) и ранний рассказ братьев Стругацких «Испытание СКР» (1960). Медленно, но верно в конце пятидесятых на страницах научной фантастики занимают свою нишу и компьютеры – пока еще с неизбежной приставкой «супер». Гигантские «электронные мозги» начинают и выигрывают (или проигрывают – другому «лому», то есть еще более мощной ЭВМ!) войны, как это описали Джесси Боун в рассказе «Спуск курка» (1958) и немецкий писатель Генрих Гаузер в романе «Мозг-гигант» (1958). Или борются за пост... президента США – в романе Артура Хэдли «Веселая повозка» (1958)! С помощью суперкомпьютеров моделируется работа человеческого мозга (повесть Днепрова «Уравнения Максвелла», 1960) и решаются лингвистические проблемы контакта с инопланетянами (рассказ Бима Пайпера «Универсальный язык», 1957). И в год первого спутника – 1957-й – выходит философская книга Станислава Лема «Диалоги» (1957), посвященная системам управления и кибернетике.

Карьера/Образование декады, в 1959 году, при Президиуме АН Акселем Бергом был создан научный Совет по кибернетике. За десять лет было создано около десятка новых ЭВМ (возрастающей сложности и специализации), работавших и на «гражданку». Это первая в стране полупроводниковая универсальная ЭВМ с устройством связи с объектом, включающим аналогово-цифровые и цифро-аналоговые преобразователи («Днепр»), созданная в Киеве Виктором Глушковым, большие машины БЭСМ-2 и «Раздан», серийные ЭВМ «Минск-1», «Уралы» (модели с 4-й по 16-ю), «Восток», «Киев», многомашинный комплекс «Минск-222», «Наири» (первая ЭВМ с микропрограммным управлением), компьютеры для инженерных расчетов МИР-1 и МИР-2. А в 1965-м увидела свет (и спустя два года была внедрена) БЭСМ-6 – первая в СССР супер-ЭВМ с быстродействием 1 миллион операций в секунду (в том же году для этой машины создали и первую операционную систему). В 1962 году появились первые отечественные трансляторы. Годом позже – первая шахматная программа КАИССА-1. И тогда же – знаковое событие – состоялась первая защита докторской диссертации по программированию.

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

На фоне таких впечатляющих успехов практической кибернетики было бы странно, если б фантасты не приняли вызов ученых и инженеров. К середине 1960-х до того редкие «электронные мозги» стали едва ли не самой популярной темой мировой фантастики, Режим реального потеснив даже «безотказвремени ных» инопланетян! БЭСМ-6 – первая в СССР супер-ЭВМ с быстр В указанное десятилеПисатели-фантасты, одействием 1 миллион операций в секунду тие развивалась электронкак им и положено, особенно ная вычислительная техинтересовались вопросами, ника и за «железным занавесом». Ни для кого не секрет, для специалистов-электронщиков пока не актуальными. что заказчиком львиной доли отечественных разработок Например, обязательно ли для функционирования киберсистемы наличие «железа»? Станислав Лем в рассказе были военные. В те годы под руководством Сергея Лебеде«Доктор Диагор» (1964) предлагает жидкую основу, Илья ва и Михаила Шуры-Буры были созданы программы расчета Теплов в рассказе «Всевышний-1» (1961) – молекулы возатомного взрыва (для БЭСМ-1), а также взрыва термоядерного – для «военной» ЭВМ «Стрела» (методику разработали духа, организованные комбинацией электрических полей, ведущие советские математики – Константин Семендяев, Иза румын Раду Нор в рассказе «Живой свет» (1963) – микрораиль Гельфанд, Андрей Тихонов и Александр Самарский). организмы! К концу 1950-х появились первые отечественные системы Популярная идея будущей общепланетной «информадля наведения истребителей-перехватчиков («СПЕКТР-4»), ционной кладовой» закономерно трансформировалась опытные образцы ЭВМ для систем противовоздушной обов кошмар «электронного Большого Брата». Интересно, роны, мобильная полупроводниковая ЭВМ «Курс» для обрачто опасная тема проскочила в считанных произведениях ботки радиолокационной информации, система обработки и советских фантастов! Так, в рассказе Ларисы и Михаила информации в реальном времени для противоракетной обоНемченко «НМ-1» (1965) встроенные в мозг человека датчики, соединяющие индивидуума с Большой информационной роны (на базе ЭВМ М-40), микропрограммная специализимашиной, выполняют и «охранительную» функцию: при перрованная ЭВМ «Тетива» для системы ПВО... вом зарождении крамольной мысли немедленно «одергиваДля решения всех этих задач требовались кадры. Их ковали в НИИ электронных машин (создан в 1958 году на базе ют» диссидента болезненным ударом тока. Для советских СКБ-245) и НИИ электронных управляющих машин, в соавторов, согласитесь, смело! ответствующих институтах Алма-Аты, Пензы, Еревана, НоЕще одну опасность чрезмерной глобализации инвосибирска, Тбилиси, Киева, Таллина, Риги. Под занавес формационной сети разглядел Артур Кларк в рассказе

системный администратор июнь 2016

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

хроники ИТ

«Ф» – значит Франкенштейн» (1963): разветвленная сеть Параллельно строительству «гигантов» началась активорбитальной связи образует в результате систему, настольная разработка миникомпьютеров. В 1960 году Филип Керко сложную, что у нее появляются зачатки совершенного ли разработал первый мини-компьютер (PDP-1) для фирмы «разума». И когда «новорожденный» начинает потягиватьDigital Equipment Corporation. Спустя четыре года появилась первая серийная модель PDP-8, стоившая «всего» ся, на планете происходит светопреставление! $18 000. Разнообразно решалась в те же годы еще одна популярная тема фантастики: будущий электронный военный Прогресс наблюдался по всем направлениям. Телестратег. В романе Юджина тайпные системы клавиатуры M33 и терминалы с перБердика и Харви Уилера «Зафорированными лентами щита от сбоев» (1962) сбой и первая графическая система Sketchpad Айвена Сав компьютерной системе Пентагона привел к несанкзерленда (1962), первый ционированному старту аместандартный код обмена информацией ASCII (1963). риканской ракеты в сторону В том же году Дуглас ЭнгельСССР. Чтобы успокоить русбарт из Стэнфорда получил ских, президент вынужден патент на изобретение комотдать приказ... подвергнуть атомной бомбардировке пьютерной мыши. А спустя «свой» же Нью-Йорк! четыре года на Объединенной конференции по комА что будет со способными эволюционировать пьютерам в Сан-Франциско когда киберсистемами, он же демонстрировал колисчезнут с лица планеты легам систему клавиатуих создатели? Об этом инры, keypad, мыши и «окон», тересно размышляет тот же а также текстового процесЗнаменитая модель IBM 360 (семейство совместимых компьютеров на интегральны Лем в романе «Непобедих сора и гипертекста! схемах) мый» (1964). Рои электронRAND стала первооткрывателем графического планшета, International Research – ных мушек – чем не идеальное и абсолютно бессмысленное магнитной ленты с двумя дорожками (хотя заявка на патент завершение киберэволюции! была снята из-за приоритетных конфликтов с другими соисРежим реального времени кателями), IBM – флоппи-диска, а Bell Laboratories – памяти Второе послевоенное десятилетие по праву заслужило на цилиндрических магнитных доменах (bubble-memory). название компьютерного «железного века». Хотя на самом В 1965 году увидела свет первая операционная система деле ему больше подошло бы другое – «кремниевый». для одновременного выполнения нескольких задач – CTSS В 1958 году (как часто встречается эта дата!) сотрудник (Compatible Time-Sharing System). Texas Instruments Джек Килби пришел к идее интегральной Переход в виртуальный режим схемы (принесшей автору – хотя и по прошествии почти К середине шестидесятых роботы и компьютеры научной полвека – заслуженную «нобелевку»). И в том же году такая фантастики начали потихоньку избавляться от «франкенсхема – из пяти элементов на германиевой базе длиной чуть штейновых» комплексов. Стародавний (в этой литературе) более сантиметра и толщиной с зубочистку – была создана. конфликт Человека и Машины происходил теперь просто В следующем году Texas Instruments и Fairchild из-за несовпадающих систем мышления – машинной и чеSemiconductors независимо объявили об открытии, позволяющем в недалеком будущем перейти к промышленному ловеческой. массовому «выращиванию» интегральных схем на полупроВ повести Евгения Войскунского и Исая Лукодьянова «Формула невозможного» (1964) обезумевший компьютер водниковых кристаллах. останавливают с помощью старого трюка – знаменитой К концу декады первые серийные полностью транзисторные компьютеры выпустила в продажу компания IBM задачки «буриданова осла»: машина какой угодной сложности не в состоянии принять нелогичное, импульсивное (модели 1620 и 1790), и она же построила в Нью-Йорке перили просто интуитивное решение! Некоторые писатели вовую в мире фабрику по производству транзисторов. И уже обще не видели проблемы в общении человека и машины. в 1964 году появились первые ласточки: семейство совместимых компьютеров на интегральных схемах – знаменитая В рассказе Джеймса Макинтоша «С помощью гаечного ключа» (1963) машина не только не «отодвигает» человека модель IBM 360. от принятия решений, но постоянно нуждается в его приВ 1960 году Гордон Мур высказал предположение об удсутствии рядом с собой, поскольку именно так и запрограмвоении сложности интегральных схем каждые 18 месяцев мирована: она «знает», что только человек способен интер(Первый закон Мура), Texas Instruments получила патент претировать ее решения и проанализировать их на наличие на интегральную схему, а в Control Data Сеймур Крэй повозможных негативных последствий. строил суперкомпьютер CDC 6000 (использовавший 60-разА оператор из рассказа Айзека Азимова «Машина, вырядные слова и параллельную обработку), остававшийся игравшая войну» (1961), не доверяя упоминавшемуся в прена протяжении нескольких лет самой производительной ЭВМ в мире. дыдущем выпуске Хроник всесильному суперкомпьютеру

июнь 2016 системный администратор

хроники ИТ Мультиваку, подстраховывается: он принимает собственное решение... бросанием монетки! Наконец, в рассказах Генриха Альтова (одного из самых нетривиально мысливших фантастов той поры, автора теории алгоритмизации технических изобретений – ТРИЗ) «Опаляющий разум» (1966) и «Машина Открытий» (1964) описаны поистине неисчерпаемые возможности самоусовершенствования, открывающиеся перед человеком вместе с внедрением в его жизнь «умных» машин. Тут и мгновенное усвоение любого объема знаний, минуя трудоемкую процедуру чтения, и полная перестройка структуры памяти, и даже постановка «на поток» научных открытий. По контрасту с этими прорывами особенно отчетливо смотрятся «проколы» писателей-фантастов. К примеру, они практически полностью «зевнули» компьютеризацию банковского дела, финансов, вместе с такими проблемами, как хакерство и специфические преступления в обществе безналичного оборота. Зато впечатляют машины, занятые творческой деятельностью. В широчайшем спектре – от электронного философамудреца из повести Геннадия Гора «Гости с Уазы» (1963) до «словомельниц» из романа Фрица Лейбера «Серебряные яйцеглавы» (1962). В шестидесятые годы увидели свет и первые серьезные попытки разглядеть в недалеком будущем еще одну непредсказуемую по своим последствиям возможность: перспективу полного замещения окружающей нас реальности иной – виртуальной. Как это ни парадоксально, но проблему Первая компьютерная мышь «электронного наркотика», подсев на который, человечество уже никогда не захочет возвращаться в унылую повседневность, наиболее ярко и убедительно проанализировали авторы, жившие и творившие… в СССР! Братья Стругацкие в повести «Хищные вещи века» (1965) прозорливо угадали наступление «общества тотального наслаждения» (что быстро приведет к тотальному же оболваниванию и одичанию), когда труд, человеческое общение и творчество подменены «слегом» (электронным генератором, воздействующим непосредственно на центры наслаждения нашего мозга) и «дрожкой» (прототипом нынешних «кислотных» дискотек). Еще ближе подошел к «виртуальной реальности» Лем, описавший в романе «Возвращение со звезд» (1961) «реалы» – виртуальные театры будущего, где обеспечивается почти полная замена окружающего мира (лишенного агрессии и одновременно опасности, поиска, риска, инициативы!) миром выдуманным, где все это присутствует. Впрочем, такая точность прогноза неудивительна: Борис Стругацкий до прихода в литературу работал астрономом в Пулковской обсерватории и профессионально занимался программированием. А Лему так вообще принадлежат одни

системный администратор июнь 2016

Карьера/Образование из самых серьезных книг по философским проблемам кибернетики. Автору ли «Суммы технологии» (1964), творцу «фантоматики» не знать все наперед про «виртуальную» цивилизацию! Это только малообразованные американские фэны спустя 20 лет будут убеждены, что «киберпространство» и «виртуальную реальность» придумал их кумир Уильям Гибсон, автор «Невроманта»...

Режим реального времени Были свои подвижки и в «софте». Грейс Хоппер принимала активное участие в разработке многих языков программирования, в частности, COBOL (дебют его состоялся в 1959 году), достигла высочайшего ранга в ВМС США, которого когда-либо достигала женщина, – контрадмирал! – и стала примером для подражания для тысяч молодых американок, задумавшихся о «мужской» карьере. (Среди прочих достижений Хоппер можно отметить и обнаружение первого компьютерного «жучка» в машине Harvard Mark II – ныне это «ископаемое насекомое» хранится в Национальном музее американской истории.) За год до появления COBOL был создан еще более популярный язык ALGOL (тогда называвшийся IAL – International Algebraic Language), а также Lisp. Автору последнего, Джону Маккарти из MIT, принадлежала и идея систем с разделением времени, а также изобретение термина «искусственный интеллект» (к концу декады Маккарти вместе с Марвином Мински основал кафедру искусственного интеллекта в MIT). И в 1964 году Джон Кемени и Томас Курц создали язык BASIC (Beginners All-purpose Symbolic Instruction Code). В 1965-м Эдвард Фейгенбаум вместе с нобелевским лауреатом генетиком и биохимиком Джошуа Ледербергом создал первую программу медицинской диагностики Dendral. В том же году в Университете штата Пенсильвания была защищена первая диссертация по новой научной дисциплине – computer science. В указанную декаду увидели свет первое руководство по компьютерам, написанное Фредом Грюнбергом (в 1952м), и первый компьютерный журнал Datamation, начавший выходить в 1957-м. И в том же году американцы, напуганные запуском в СССР первого спутника, оперативно создали APRA (Агентство по перспективным исследовательским проектам министерства обороны). Именно в недрах этой засекреченной организации на закате века родится главный враг всех и всяческих секретов – интернет… EOF * Продолжение. Начало – см. «СА» №1-2, №3, №4, №5 2016. Продолжение следует

x (1) , ⎛ ⎞ eiN = ⎜ 0, , 0,1, 0, , 0 ⎟ ⎟ ⎜ i N −i ⎝ ⎠

(

, x(N )

)

OPT

Новый статус {x (

)

⎛ 1 ⎜N , ⎝

x(N )

−1 1 , N −1 , kN ,N ,

ША

e ( x ) = ∑ eiN χ ( x = x ( i ) )

domv

Ndomv

–

ваши

(x( )

журнала

x ( N )}

N ε

новые возможности! ( )

{

i =1

}

n1

ШАГ

www.samag.ru xn



x (i )

n

pn − γ n R ( xn pn

2, 3, 1, 4, 5

)

N ε

STAT

q πεN q Журнал «Системный администратор» вошел в перечень рецензируемых научных S ST S AT изданий Высшей аттестационной комиссии – ВАК! i −1

∑ p ( j) ≤ j =1

SεN

⎧ ⎨p = ( p ⎩

pN ) p

< ∑ pn ( j ) j =1

ERR

⎫ N )⎬ ⎭

R N , ∑ pi = 1 pi ≥ ε ( i i =1

Высокий уровень авторского контента «Системного администратора», давно ( ) ценимый нашими читателями, официально признан государством и российским научным сообществом. pn

N ε

{q}

Rn x

xn p

Мы получили статус издания, в котором публикуются основные научные результаты на соискание ученой степени кандидата наук, доктора наук. n R ( xn , pn ,ξ n )

q = mi m nN p q

γ >0

p S ⎧⎪ ⎫⎪ Редакция журнала приглашает к сотрудничеству всех тех, ξ −Δ p π ⎨p −γ e ( x )⎬ e (x ) p ⎩⎪ ⎭⎪ чьи профессиональные интересы связаны с научными изысканиями в сфере −1 ⎡ ε ∈ 0 , N N информационных технологий. n ⎣ ε

n +1

N ε n+1

pn +1

πε n+1 pn −

R xn pn

Требования к публикациям научных статей размещены на сайте журнала n  1, 2,  «Системный администратор»: http://samag.ru/main/part/49

ξn

ξ n xn ω pn +1

(−

−

⎧⎪ ⎨

⎛ ξ − ξn − Δ ξn − Δ πεNn+1 pn − γ n ⎜ T n e x + e x + e x ⎜ e ( x ) p ( n ) eT ( x ) p d ( n − ) eT ( x ) p d ( n n n n n n n ⎝ ⎩⎪

⎞⎫ ) ⎟⎟ ⎬⎪ ⎠ ⎭⎪

1 n ∑ ξt ; n t =1 lim Φ n → υ .

Φn = n →∞ →

)

Заявки на публикацию статей в раздел и технологии» OPT 1, 2, 1) (1, 2,«Наука присылайте на e-mail: vak@samag.ru N

FGUI

Наука и технологии Звездов Д. С., Национальный исследовательский университет «Высшая школа экономики», dzvezdov@hse.ru Абрамешин Д. А., Национальный исследовательский университет «Высшая школа экономики», dabrameshin@hse.ru Грановский В. С., Национальный исследовательский университет «Высшая школа экономики», manianell@mail.ru

Утилиты в ПО MathCAD

для уточненного расчета электрических полей при облучении полимерных пленок электронами низких энергий

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

Введение

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

системный администратор июнь 2016

В данной системе уравнений (1) приняты следующие обозначения: • N(t) – полная концентрация основных носителей заряда (в дальнейшем электронов); • g0 – скорость объемной генерации носителей заряда; • kr – коэффициент объемной рекомбинации подвижных электронов с дырками, выступающими в качестве центров рекомбинации; • kc – константа скорости захвата квазисвободных электронов на ловушки; • M0 – суммарная концентрация ловушек, экспоненциально распределенных по энергии (E > 0 и отсчитывается вниз от дна зоны переноса); • ρ(E,t) – энергетическая плотность распределения захваченных электронов;

Наука и технологии • ν0 – эффективный частотный фактор термического освобождения носителей заряда из ловушек; • E1 – параметр экспоненциального распределения ловушек по энергии. Как видно из системы уравнений модели РФВ, концентрация носителей заряда в проводящем состоянии N0(t) с микроскопической подвижностью μ0 вычисляется при решении системы уравнений РФВ. По определению плотность радиационного тока описывается следующим выражением:

где: • F – величина приложенного электрического поля [В/м]; • γr – радиационная электропроводность [Ом-1м-1];; • e – заряд электрона [Кл]. Заряд электрона и микроскопическая подвижность являются постоянными величинами, следовательно, на кинетику радиационной электропроводности и ее полевую зависимость влияет исключительно кинетика изменения концентрации носителей заряда в проводящем состоянии N0(t).

Генерация носителей заряда

Концентрация генерируемых носителей заряда определяется мощностью дозы ионизирующей радиации. Для случая электронного излучения имеет место специфическое распределение мощности поглощенной дозы по толщине образца. Нами экспериментально определено это распределение (см. рис. 1) для электронов с энергией (30...65) кэВ, которое аппроксимировано аналитической функцией:

В выражении (3) ξ – это отношение текущей толщины образца полимера к величине максимального пробега электронов данной энергии в рассматриваемом полимере lm. С помощью ПО MathCAD была создана программа расчета поглощенной дозы с учетом фактора ее накопления по глубине образца. Сам фактор накопления поглощенной дозы определятся выражением:

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

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

где

• Re – расчетная (усредненная) мощность дозы электронного излучения; • K – фактор накопления поглощенной дозы из выражения (4); • Ie – плотность тока облучающих образец электронов; • dE/dx – тормозная способность полимерного материала для электронов данной энергии (значение выбирается из таблиц), определяющая мощность дозы на облучаемой поверхности.

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

Полевая зависимость

Полевая зависимость РЭ полимеров обусловлена влиянием приложенного электрического поля на радиационно-химический выход зарядов, принимающих участие в переносе электрического тока. Вероятность Ω∞ того, что электронно-дырочная пара будет разделена, определяется начальным расстоянием разделения зарядов в ней, типичное значение которого составляет r0 = 6 нм. Вероятность разделения пары электрон – материнский ион является нелинейной функцией приложенного электрического поля. Это приводит к тому, что при увеличении поля в два раза электропроводность может возрасти в три, в четыре раза. Причем такое поведение РЭ характерно для сильных полей. В слабых полях зависимость РЭ от приложенного поля не зависит. Примем следующие обозначения: • ε0 – электрическая постоянная, [Ф/м]; • ε – относительная диэлектрическая проницаемость среды; • k – постоянная Больцмана, [Дж/К]; • e – заряд электрона, [Кл]; • T – температура, 290 [К]. Вероятность разделения в отсутствие внешнего электрического поля равна: Рисунок 1. Кривая распределения поглощенной дозы электронного излучения по глубине образца полимерного материала (полиэтилентерефталата)

июнь 2016 системный администратор

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

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

Для расчета полевой зависимости радиационной электропроводности полимера была разработана подпрограмма MathCAD. Результаты вычислений программы для случая средних и сильных полей наглядно представлены на следующем графике (см. рис. 2).

Захват и высвобождение электронов с ловушек

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

В настоящей работе рассмотрена полуэмпирическая модель РЭ Роуза-Фаулера-Вайсберга. При анализе данной модели установлено, что ее необходимо дополнить сторонним программным обеспечением для проведения расчетов объемного заряжения полимеров электронами. Это стороннее программное обеспечение должно учитывать три аспекта, которые отсутствуют в модели РФВ. Во-первых, это уточненный расчет генерации носителей заряда, который учитывает реальное распределение поглощенной дозы по глубине образца. Во-вторых, расчет электрических полей в полимере при их облучении электронами должен принимать во внимание сверхлинейную зависимость радиационного тока от электрического поля, которая в разработанной подпрограмме MathCAD дается в виде решения задачи Онзагера в области средних и сильных полей. Здесь следует отметить, что указанная сверхлинейность вольт-амперной характеристики радиационного тока способствует снижению максимально достижимого электрического поля в полимере при его облучении электронами. И, наконец, третья уточняющая процедура – это рост РЭ за счет сверхлинейной зависимости частотного фактора ν0, присутствующего в модели РВФ (1), от электрического поля за счет эффекта Пула-Френкеля. Предложенные утилиты предназначены в первую очередь для того, чтобы создать более комфортные условия при проведении экспериментальных испытаний в Учебно-исследовательской лаборатории Функциональной безопасности космических аппаратов и систем МИЭМ НИУ ВШЭ. Кроме того, эти утилиты планируется встроить в программу расчета электрических полей, возникающих при облучении полимеров электронами, для проведения более корректных расчетов этих полей. EOF [1]

[2]

[3]

Тютнев А.П., Саенко В.С., Пожидаев Е.Д., Костюков Н.С. Диэлектрические свойства полимеров в полях ионизирующих излучений. – М.: «Наука», 2005. – 453 с. Тютнев А.П., Ихсанов Р.Ш., Саенко В.С., Пожидаев Е.Д. Теоретический анализ модели Роуза-Фаулера-Вайсберга //. Высокомолек. соед. А. 2006. Т. 48. №11. – С. 2015-2022. Безродных И.П., Тютнев А.П., Семенов В.Т. Радиационные эффекты в космосе / Отв. ред.: А. П. Тютнев. Ч. 2: Воздействие космической радиации на электротехнические материалы. – М.: АО «Корпорация «ВНИИЭМ», 2016.

Ключевые слова: радиационная физика; программное обеспечение, MathCAD, полимерные материалы, полевая зависимость, частотный фактор, мощность поглощенной дозы. The MathCAD based mathematical packet for calculating electric ields in polymer ilms irradiated with low energy electrons D. S. Zvezdov, , D. A. Abrameshin, V. S. Granovsky National Research University Higher School of Economics Summary: The Rose-Fowler-Vaisberg model which analyzes polymer radiation conductivity at strong electric ields has been considered. Special software has been developed based on the MathCAD mathematical packet. We employed it to calculate the absorbed dose, the ield dependent conductivity and the frequency factor of the model as well as to analyze experimental data obtained in the Laboratory of Space Vehicles and Systems Functional Safety. Keywords: Radiation physics, software, MathCAD, polymers, ield dependency, absorbed dose, frequency factor.

системный администратор июнь 2016

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

Ископаемая интегральная

Издается с 2002 года

На сей раз очередным экспонатом нашего виртуального музея компьютерных и коммуникационных технологий стала первая интегральная схема, которой спустя два года стукнет шесть десятков годков – по меркам быстротекущей компьютерной эры настоящее ископаемое! Но именно от этого полупроводникового «динозавра» (если иметь в виду не только возраст, но и размеры) пошли все те микрочипы, которыми набиты известные каждому электронные гаджеты. На вопрос, кто был автором первой интегральной схемы, не только читатели журнала, но и все мало-мальски образованные люди, следящие за новостями из мира науки и техники, уверенно ответят: Джек Килби. Кто же еще – нобелевский лауреат и все такое прочее… Это же можно прочитать и в очередном выпуске моих Хроник, опубликованном в номере, который вы держите в руках. Там формат не позволил автору делать пространные отступления. Сейчас же есть возможность восстановить историческую справедливость. Не умаляя заслуг Килби, следует отметить, что у него был соавтор – правда, работавший независимо, в конкурирующей компании. В мае 1958 года инженер Джек Килби, до того работавший в небольшой компании Centralab (где он создал первый в мире миниатюрный слуховой аппарат на только что изобретенных транзисторах), перешел в Texas Instruments. Руководство сразу же нацелило нового сотрудника (назвать его «молодым» язык не поворачивается – Килби, участнику войны, уже стукнуло 35!) на решение задачи, сулившей богатые коммерческие перспективы: создание альтернативы микромодулям в виде сборных блоков (типа детских конструкторов). Начиналось лето – пора отпусков, но новичку отпуск не грозил, и Килби, кроме всего прочего, пришлось заниматься и такой скучной – для инженера-физика – рутиной, как расчетами ценообразования еще не созданного продукта. «Цена вопроса» и привела Килби к идее соединить все главные продукты компании – транзисторы, конденсаторы и сопротивления – на единой полупроводниковой базе: кристалле германия. Вернувшееся из отпусков начальство отнеслось к идее с энтузиазмом, но потребовало в кратчайшие сроки воплотить чертежи в работающее «железо». Килби быстро построил схему триггера из дискретных германиевых элементов и 28 августа продемонстрировал ее руководству Texas Instruments. После чего приступил к созданию первой настоящей монолитной интегральной схемы. К сентябрю были готовы три генератора с фазовым сдвигом, и 12 сентября они заработали на частоте 1.3 МГц. Вот он, этот электронный «динозаврик», на снимке. Счастливый автор изобретения не знал, что в другой конкурирующей компании – Fairchid Semiconductor – пытливая мысль тоже билась над решением аналогичной задачи. Тем более что там собралась блестящая команда специалистов под руководством Роберта Нойса – ученика одного из создателей транзистора Уильяма Шокли. Сам Нойс много думал над опять-таки коммерческим использованием недавно изобретенного планарного (плоского) транзистора и сформулировал идею интегральной схемы (на сей раз – на кремниевой основе) всего через месяц после изобретения Килби. В основе технологии, разработанной Нойсом, лежало сразу несколько революционных решений: диффузионные резисторы, изоляция pn-переходом (смещенным в обратном направлении), наконец, соединение элементов схемы с помощью напыляемого слоя алюминия. Как вспоминал позже сам Нойс, к главному изобретению жизни его подтолкнула… обычная лень. В то время для изготовления микромодулей пластины кремния сначала разрезали на отдельные транзисторы, после чего снова соединяли друг с другом в единую схему. И все вручную, припаивая элементы под микроскопом! На смену этому трудоемкому и, главное, дорогостоящему процессу Нойс и придумал свои знаменитые «лабиринты» из алюминиевых дорожек, отделенных друг от друга изолирующим материалом. С коммерческой точки зрения вариант Нойса оказался куда предпочтительнее того, что предложил Килби. И патент Нойс получил гораздо раньше коллеги-соперника (притом что заявку подал на полгода позже). Так что в 2000 году, когда до создателей микрочипов «добралась-таки» заслуженная Нобелевская премия, ее по праву должен был разделить и Роберт Нойс. Но, увы, до этого счастливого дня он не дожил, скончавшись от сердечного приступа в 1990-м. А покойников, как известно, Альфред Нобель премиями своего имени в знаменитом завещании обделил. EOF

МИЭМ НИУ ВШЭ, д.т.н., профессор, академик РАО

«Системный администратор» включен в перечень ведущих рецензируемых журналов ВАК Минобрнауки РФ Включен в Российский индекс научного цитирования www.elibrary.ru

Научный руководитель журнала – председатель Редакционной коллегии А.Н. Тихонов, научный руководитель, директор

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

Главный редактор Галина Положевец, chief@samag.ru Генеральный директор Владимир Положевец Шеф-редактор журнала «Системный администратор» Владимир Лукин, lukin@samag.ru Заместитель главного редактора Ирина Ложкина, lozhkina@samag.ru Заместитель главного редактора, официальный представитель редакции в Украине Сергей Яремчук, grinder@samag.ru Директор по развитию Ирина Пушкина, i.pushkina@samag.ru Главный бухгалтер Надежда Кан

Юридический отдел Владимир Столяров

buch@samag.ru

stolyarov@samag.ru

Распространение Олег Иванов

reklama@samag.ru

subscribe@samag.ru Дизайн обложки Михаил Лебедев

Дизайн-макет Марина Рязанцева, Дмитрий Бессонов

Иллюстрация Виктор Чумачев

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

Экспертный совет Рашид Ачилов, главный специалист по защите информации Сергей Барамба, эксперт по системным решениям Алексей Бережной, эксперт по администрированию и ИБ Андрей Бирюков, ведущий системный инженер по ИБ Алексей Вторников, эксперт по вопросам разработки ПО Константин Кондаков, старший директор по ИТ Кирилл Сухов, ведущий специалист направления интернетразработки Леонид Шапиро, эксперт по ИБ и инфраструктурным проектам Сергей Яремчук, эксперт по ИБ Издатель ООО «Издательский дом Положевец и партнеры» Адрес редакции 129075, г. Москва, 3-й пр-д Марьиной Рощи, д. 40, стр. 1, офис 606, тел.: (499) 277-12-41, факс: (499) 277-12-45 Сайт журнала: www.samag.ru Отпечатано в типографии OOO «Периодика»Тираж 17000 экз. Все права на материалы принадлежат журналу «Системный администратор». Перепечатка и использование материалов в любой форме, в том числе и в электронных СМИ, без разрешения запрещена. При использовании материалов ссылка на журнал «Системный администратор» обязательна. Материалы отмеченные знаком ADV публикуются на коммерческой основе. Редакция не несет ответственности за достоверность информации в материалах, опубликованных на правах рекламы.

июнь 2016 системный администратор

Акция «Заяви о себе!» Оформив редакционную годовую подписку на 2016 год на смешанную версию журнала «БИТ. Бизнес&Информационные технологии», вы получите редкий шанс рассказать о своей компании или своем продукте на страницах издания!

Все об ИТ

#5(58) июнь 2016

«Мобилизация» бизнеса: ее плюсы и минусы

в бизнесе и для бизнеса

Находка для шпиона? В России разработана система, позволяющая перехватывать разговоры по мобильному телефону

Бумажная

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

БИТ.Персона

5000 руб.

Леонид Бугаев, основатель и руководитель Nordic Аgency AB, бизнес-ментор, спортсмен

http://bit.sa mag.ru ISSN 2313-8718

Все подробности проведения акции – на сайте журнала http://bit.samag.ru

Подписывайтесь и раcсказывайте о себе! bit.samag.ru/subscribe