(Мы продолжаем цикл очерков из истории нашего университета под названием «Красный Хогвартс»).

В НИТУ «МИСиС» сейчас очень активно отмечается 75-летие Великой Победы. Это будет первый большой юбилей без ветеранов. Еще на 70-летие в университете были живы четверо, если не путаю, участников войны, за эти пять лет они все ушли.

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

Как и все интересные исторические расследования, оно началось с малого. Я бы даже сказал — с малого и скучного. Со скучного наследия бюрократов — протокола заседания Правления Московской горной академии в июне 1924 года:

«Параграф 25. Слушали: Заявление топографов геодезистов С. Лобик, В. Федорова, Румянцева, Орешкина о зачислении их на службу в состав топогр. геодезич. партии Комитета по Грозненским разведкам при М.Г.А. Постановили: Зачислить».

Скучный документ валялся в столь же скучном архивном деле топографа Федорова Василия Андреевича. Мало того, что скучном, так еще и худом как велосипед — всего 18 листочков. Работая в архиве, пролистать я его решил исключительно из чувства долга и ничего интересного не ожидал.

Заявление о приеме на работу, уведомление о приеме, дежурные справки о праве работников ВТУЗов на дополнительную жилплощадь в 20 квадратных аршин и запрещении «уплотнения», командировочное в Чечню…

Что это?

25 июня 1924 года начальник административно-хозяйственного управления Мирон Чередниченко отправляет телеграмму в Грозный ректору Московской горной академии, знаменитому академику Ивану Губкину: «ФЕДОРОВ БЫВШИЙ ОФИЦЕР БЕЛОЙ АРМИИ НЕОБХОДИМО ПОРУЧИТЕЛЬСТВО Я ЕГО НЕ ЗНАЮ ТЕЛЕГРАФИРУЙТЕ».

Губкин молниеносно отправляет из Грозного ответ: ФЕДОРОВУ ПОРУЧИТЕЛЬСТВО ДАНО БЫТЬ НЕ МОЖЕТ ПРИШЛИТЕ НЕМЕДЛЕННО ДРУГОГО ТОПОГРАФА ГУБКИН».

Реакция Губкина неудивительна — 1924 год, Гражданская война только-только закончилась, какие могут быть белые офицеры в первом советском техническом вузе? Но из оставшихся в деле документов становится понятно, что из МГА «недобитое офицерье» почему-то не выгнали. Он еще несколько лет работал в академии, ежегодно отправляясь в Чечню на топографические съемки, а уволился только в 1928 году «в виду прекращения топографических работ в Комитете».

В написанной Губкиным характеристике значилось: «В.А. Федоров проработал в Комитете МГА в качестве геодезиста и топографа четыре года (1924-28) и высказал себя знающим свое дело и весьма добросовестным работником». Изрядно сказано «красным академиком» о белом офицере.

Итак, что мы имеем? Мы имеем каких-то странных топографов, четыре фамилии с инициалами и… И ничего больше.

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

Первый

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

На обороте была полустертая надпись карандашом «Надя и B… я». Две буквы стерты, читаются только «В» и «Я», что невероятно расширяет варианты — это может быть и «Ваня», и «Вася» и даже «Валя». Снимок сделан в Виленской губернии в ателье фотографа Александра Штраусcа. Больше не знают о нем ничего, как писал Маршак.

Но военные историки — народ азартный. Примерно два месяца они просеивали всех офицеров в своих картотеках, которые могли оказаться в этом месте в это время. И методом исключения вычислили все-таки военного топографа Федорова Василия Андреевича, капитана, производителя работ. Вот справка

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

На обороте была надпись: «Дорогой и милой Надечке от Васи. Рига, 15 февраля 1903 года».

Пасьянс сложился. «Первый» установлен. Имея всю эту информацию, биографию «Васи» вытащить было не трудно.

Кадровый офицер, «военная косточка» — это, впрочем, и по фотографиям видно. Родился в Смоленске в 1866 году, закончил Военно-топографическое училище, много лет работал на съемке Северо-Западного пограничного пространства, в 1906 году был командирован на 3-ю Маньчжурскую съемку. С 1912 года прикомандирован к Военно-топографическому управлению Главного штаба. Дальше так и служил в Генштабе — до 1918 года.

После революции в 1921 году ненадолго обнаруживается в Иркутске, но потом вновь возвращается в Генштаб, но теперь это уже Генштаб Рабоче-Крестьянской Красной армии. Последняя должность — старший топограф для поручений при главном инспекторе работ Управления картографии и военной топографии.

Полковник русской армии (с 6.12.1915 г.), кавалер орденов Св. Станислава III степени, Св. Анны III степени, Св. Равноапостольного Князя Владимира IV-й степени.

Справка в биографическом словаре завершалась фразой «Уволен со службы 1 декабря 1923 года, дальнейшая судьба неизвестна». Что ж, получается, я хоть немного порадел отечественной истории, на несколько лет продлил биографию человека. Мелочь — а приятно.

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

Дело в том, что именно 1923-24 года — это начало масштабной чистки Рабоче-Крестьянской Красной армии от подозрительных «военспецов-золотопогонников». А началось все именно с Корпуса военных топографов.

Офицеры Корпуса военных топографов.

Еще весной 1923 года были отданы под суд начальник корпуса военных топографов бывший полковник Дитц, его помощник Иванищев, начальник аэрофотографического отряда Животовский и комиссар Цветков. Еще несколько офицеров выгнали из РККА.

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

Запомните фамилию Аксенова, она нам еще пригодится.

Подполковник Порфирий Петрович Аксёнов, 1883-1930.

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

И вот тут-то академик Губкин, которому всегда было позволено несколько больше других, и воспользовался ситуацией. Незадолго до этого его Московская Горная академия совместно с «Грознефтью» запустили масштабный и по деньгам и по задачам проект под названием «Комитет по грозненским разведкам МГА». Главной задачей были широкие поисковые и детальные разведочные работы в Чечне и на Кубани. В следующем году появится «Комитет по бакинским нефтяным разведкам», потом они сольются в единый «Комитет по нефтяным разведкам МГА», а масштабные исследования продлятся четыре года и закончатся только в 1928-м.

Знающие топографы и геодезисты нужны были позарез, а тут — такая удача, сразу четверо специалистов, да каких! Overqualified — это еще мягко сказано.

А что военные — так это даже лучше. Чечня — регион неспокойный, в этом «краю абреков» всегда пошаливали, а уж после Гражданской войны — тем вообще невесть что творилось. А с офицерами хоть студентов на практике не перережут.

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

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

Второй

Впрочем, старшим Федоров был только по возрасту, но не по должности. Самую впечатляющую карьеру в этой четверке сделал Сергей Павлович Лобик, который перед увольнением (9.11.1923 г.) занимал должность начальника Управления Корпуса военных топографов.

Это был человек другого поколения — на 20 лет младше Федорова, 1887 года рождения. Родился в Шлиссельбурге, происхождением «из простых» — сын народного учителя. Блестяще закончил все то же Военно-топографическое — с изучением дополнительного геодезического класса — и после выпуска был занесен на Доску почета училища.

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

С ноября 1914 года по июнь 1916-го он получил шесть орденов. За полтора года — шесть (!) орденов — Станислава, Анны и Владимира разных степеней. За бой 12 октября 1914 года Лобика представляли к Георгиевскому оружию, но «Георгия» не дали, заменив орденом Св. Равноапостольного Князя Владимира IV-й степени с мечами и бантом.

Несмотря на ранение, а, может, и благодаря ему — было время на подготовку — исполнил, наконец, давнюю месту. Поступил в Академию Генштаба, которую закончил ускоренным выпуском в 1917 году.

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

В деле Лобика, кстати, нашелся и финал истории с белогвардейцем Федоровым. Как выяснилось, была еще и третья телеграмма. Звучала она так:

ГРОЗНЫЙ, ГРОЗНЕФТЬ, ГУБКИНУ. ТОПОГРАФ ЛОБИК ВЫЕЗЖАЕТ СУББОТУ СКОРЫМ ПОЕЗДОМ ФЕДОРОВ ВЫЕЗЖАЕТ ВТОРНИК ПОРУЧИТЕЛИ ЕСТЬ ЯЗЫКОВ (тот самый Языков, с которого и начался этот цикл очерков)

Лобик и Федоров ушли из МГА они одновременно, в середине 1928 года. Лобик, как и его старший коллега, также получил справку-рекомендацию от Губкина о том, что "добросовестно исполнял все возлагаемые на него служебные поручения и специальные работы. Выдано на предмет представления к месту новой службы".

Что это было за место новой службы и было ли оно — истории пока неведомо.

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

От всего этого осталась ровно одна строчка в книге. В мало кем читаном сборнике трудов Московского нефтяного института им. Губкина издания 1969 года. Там один из тех самых студентов, которых они водили по Чечне, ставший ректором Московского нефтяного института и основателем кафедры геологии, уже на излете жизни напишет в своей вышедшей посмертно статье о Комитете по грозненским разведкам,: «К работе Комитета были привлечены бывшие военные топографы В. П. Румянцев, В.А. Федоров, Г. П. Орешкин, С.П. Лобик»…

Михаил Михайлович Чарыгин, бывший студент Московской горной академии, профессор, ректор Московского нефтяного института им. И. М. Губкина в 1939-42 гг.

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

Впрочем, уволились тогда не все. Владимир Петрович Румянцев остался.

Третий

Опять кадровый офицер, опять топограф, опять генштабист. Как и Федоров — из «довоенного» поколения топографов. Уроженец села Большие Березняки Симбирской губернии, 1879 года рождения. Помладше Федорова, но много старше Лобика, поэтому на фронт не попал — знающих топографов с хорошим опытом берегли, и в мясорубку без нужды старались не отправлять. С Федоровым явно знаком задолго до войны, вместе работали на съемке Северо-Западной границы, потом вместе в Маньчжурии, затем Румянцева переводят на Киевскую съемку. С 1914 года и вплоть до революции Владимир Петрович Румянцев — преподаватель в alma mater, Военно-топографическом училище.

В.П. Румянцев (в форме) с братьями и сестрой

После революции работал начальником теодолитного отделения астрономо-геодезического отряда Корпуса топографов, по итогам чистки уволен в октябре 1923-го, принят Губкиным в Горную академию, вместе с сослуживцами несколько лет мотался по Чечне, Кубани и Азербайджану.

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

Как выяснилось — на беду.

Потому что чистки Красной армии вовсе не закончились.

В октябре 1929 г. в конфликтную комиссию Политического управления РККА поступила жалоба от бывшего военного комиссара Военно-аэротопографического отдела Л. Ф. Гайдукевича на начальника военно-топографического отдела ГУ РККА А. И. Артанова. По жалобе была назначена проверка, а по результатам проверки…

По результатам проверки в военно-топографическом управлении Генштаба чекистами был раскрыт заговор, возглавляемый бывшим подполковником Порфирием Петровичем Асеновым — помните фамилию?

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

Аксенов Порфирий Петрович, русский, б/п, обр. высшее, пом.нач. Военно-топографического управления Красной Армии.

Мельников Георгий Петрович, русский, б/п, обр. среднее, нач.архива Военно-топографического управления Красной Армии.

Карпекин Николай Алексеевич, русский, б/п, обр. высшее, нач. Военно-топографического отдела Красной Армии в г. Ташкенте.

Ершов Дмитрий Сергеевич, русский, б/п, обр. высшее, профессор, зам. зав. фотогеодезич. отд. Московского геодезического ин-та, нач. Военно-аэрофототопографического отдела Военно-топографич. управления Красной Армии.

Румянцев Владимир Петрович, русский, б/п, обр. высшее, топограф Моск. горной академии и нач. топографических работ «Грознефти» Сулакского р-на…

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

Приговор приведен в исполнение 30 сентября 1930 года, место захоронения — Москва, Ваганьковское кладбище. Реабилитирован 16 января 1989 года.

Четвертый

Остался последний — Орешкин Григорий Петрович, самый младший в этой четверке, 1889 года рождения, на момент поступления в МГА ему было 35 лет.

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

Григорий Петрович был потомственный казак, родившийся в станице Урюпинской Хоперского округа области Войска Донского. Поэтому стезя казачьего офицера была написана ему на роду. Он закончил Военно-училищные курсы Новочеркасского казачьего юнкерского училища, и 6 августа 1910 года был выпущен «из портупей-юнкеров» в хорунжие в Первый Донской казачий полк.

Казармы 1-го Донского казачьего полка

Уже на службе в полку заинтересовался топографией и с 1912 по 1914 год обучался в геодезическом отделении Николаевской военной академии. Но тут начинается война и сразу же после выпуска сотник Орешкин уходит на фронт, в «родной» 18-й Донской казачий полк, формировавшийся из казаков станиц Хоперского округа, сборный пункт – станица Урюпинская.

Как и Лобик, всю войну прошел на переднем крае. Воевал не менее геройски, и по количеству полученных орденов Орешкин если и уступал товарищу, то незначительно — пять вместо шести: Станислав III и II степени, Анна IV (Аннинское оружие «за храбрость») и III степени, орден Святого Равноапостольного Князя Владимира IV-й степени с мечами и бантом.

В 1915 году был ранен, лечился в Киеве и в Москве, газеты зафиксировали: "Больные и раненые офицеры, прибывшие в Москву: сотник Орешкин Григорий Петрович в 12-й эвакуационный госпиталь…" (Газета «Русское слово» Пятница, 17-го апреля 1915 г. N 87.)

Из списков награжденных орденами

С 1916 года подъесаул Орешкин служит в Генеральном штабе, в 1917 году накануне революции — старший адъютант по службе Генерального штаба 47-го армейского корпуса 6-й армии Румынского фронта.

После революции, как и все четверо, принял сторону красных, в 1921 году — слушатель геодезического отделения Академии ГШ РККА и в Пулковской обсерватории. Последняя должность перед увольнением со службы — начальник 1-го отделения знаменитого астрономо-радиотелеграфного отряда. Уволен со службы 5 декабря 1923 г. согласно постановления все той же «особой комиссии по пересмотру личного состава военных топографов».

Дальше — как у тех троих: предложение Губкина, МГА, экспедиции, студенты, сокращение в 1928 году. Но в отличие от друзей Орешкин не исчезает бесследно.

Его фамилия вновь появляется в документах времен Великой Отечественной войны. Причем в личном деле Орешкина фигурирует примечательная фраза: "1889 года рождения. В РККА с 1941 года. Место призыва: Бауманский райвоенкомат, Московская обл., г. Москва, Бауманский р-н".

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

Никогда.

С началом войны, 23 июня 1941 года была объявлена мобилизация военнообязанных 14 возрастов, с 1905 по 1918 года рождения. После страшных поражений первых дней войны 10 августа Государственный комитет обороны издал постановление о мобилизации военнообязанных 1904—1890 годов рождения и призывников 1922—1923 годов рождения на территории Кировоградской, Николаевской, Днепропетровской областей и районов западнее Людиново — Брянск — Севск Орловской области. Позже это положение было распространено и на другие территории, в том числе 16 октября — на Москву и Московскую область.

Но и здесь, как мы видим, верхняя граница — 1890 год. Как же Орешкин оказался в армии?

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

Туда и ушел тем страшным летом 1941 года 52-летний Григорий Орешкин. Ушел делать свою работу — защищать Родину.

Ополченцы Москвы. 1941 г.

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

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

И попал наш Григорий Орешкин из огня — да в полымя. Из-под Москвы — в Сталинград.

Наверное, мы уже никогда не узнаем, что он вынес в ту войну, свою вторую мировую войну. Но, как или иначе, а первый документ, который имеется в нашем распоряжении — это его представление к медали «За оборону Сталинграда».

Как он выжил в том аду на Волге — не могу даже предположить. Но факт остается фактом — вот его фамилия среди других бойцов, находившихся на службе в управлении и частях 156 укрепрайона МЗО. Воинское звание – инженер-капитан. Должность — начальник топогруппы.

Дорога, начавшаяся в Бауманском военкомате, оказалась долгой.

Бывший лихой казачий сотник, ставший геодезистом и астрономом, прошел всю войну. От начала и до конца, с 1941-го по 1945-й.

Приказом командующего артиллерией Центральной группы войск от 6 сентября 1945 года «за образцовое выполнение боевых заданий Командования на фронте борьбы с немецкими захватчиками и проявленные при этом доблесть и мужество» преподаватель топографии курсов младших лейтенантов артиллерии Центральной группы войск, инженер-капитан Орешкин Григорий Петрович награжден орденом Красной Звезды.

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

И курсантов, знаете ли, можно понять. Бывшего подъесаула, а ныне инженер-капитана Григория Петровича Орешкина действительно было за что уважать.

Сильный был человек, и офицер — настоящий.

«От героев былых времен не осталось порой имен — те, что приняли смертный бой, стали просто землей, травой…»

Привет.

Собрал игрушку, делюсь с вами.

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

Каждая тяга «сухожилие» сделаны из 2мм стальной проволоки, на кончике просверлены, и крепится в пальце проволокой от скрепки. Саморезы 2.5мм 16мм (причем при сборке пальцев укорачивал) покупал в Леруа.

3Д модели лежат тут.

Изначально хотел сделать пальцы более «человечные», и печатать за раз целиком палец (печатал HIPS), но в итоге не получилось, склеились у меня детали. Разрезал каждый палец чтобы печатать по отдельности, но сборка получалась сложной. Были и другие варианты, в том числе и с шприцами, точнее с них я и начинал. Были и из металла. С мягкими сухожилиями и резинками для возврата в разогнутое положение. Не все 3Д модели остались, поудалял за ненадобностью.

Больше всего проблем доставил большой палец руки: сделаешь чтобы лучше складывался в кулак — захват уменьшается, увеличиваешь захват — кулак не собирается. То что получилось это компромисс. Дальше по-моему только добавлять еще один сустав.

Никакого отношения к протезам не имеет!

18 ноября Telegram запустил соревнование по кластеризации данных: Data Clustering Contest. Нужно было за две недели сделать свой новостной агрегатор. Ограничения, которые были установлены в этом соревновании отпугнули кучу людей, но не меня и моих коллег. Я расскажу от том, каким путём мы прошли, какие выборы сделали и с какими сложностями столкнулись. Решение, которое мы заслали в соревнование обрабатывало 1000 документов за 3,5 секунды, занимало 150 Мб, заняло 6 место на публичном голосовании и 3 место в итоговых результатах. Мы допустили много ошибок, из-за которых не заняли место повыше, большинство из них сейчас исправлены. Весь код и все модели можно найти в репозитории. Все скрипты для обучения моделек перенесены на Colab.

Топ из публичного голосования

Задача

Официальное описание соревнования лежит здесь.

Там 5 подзадач:

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

Подзадачи конкурса в порядке выполнения

Это не слишком далеко от того, как работают реальные новостные агрегаторы. Из этого неясно, как именно будут работать итоговое решение в Телеграме: раз в минуту/час/день, будет ли оно каждый раз заново запускать все этапы. Также было неясно, в каком формате будут запускаться эти 5 подзадач: по отдельности, все вместе для одного языка, все вместе для разных языков. Про публичное голосование тоже не было ничего известно во время самого соревнования.

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

Ограничения:

• максимальный вес архива с решением: 200 Мб (а позже 1.5 Гб)
• минимум 1000 документов в минуту
• 2 недели со старта до конца соревнования
• запускается через бинарник на Debian GNU/Linux 10.1, можно устанавливать любые пакеты для этой конфигурации

Ограничение на скорость довольно слабое, 1000 документов в минуту можно получить практически для любой системы, кроме совсем уж тяжёлых и неповоротливых моделей. Главным тут является ограничение на вес архива: изначальные 200 Мб отсекали многие свежие наработки в области обработки естественных языков, в том числе почти любые предобученные векторы (готовые word2vec, fasttext, GloVe, для русского тут) и предобученные ULMFiT/ELMo/BERT. Это не означает, что их вообще нельзя использовать. Их нужно было бы учить с нуля с урезанным числом параметров или дистиллировать текущие модели, что за 2 недели та ещё задачка.

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

Выбор стека

Начнём с языка. В теории, можно было бы всё написать на Python (и многие так в итоге и сделали). Нас остановили ограничение по скорости и ограничение на запуск из бинарника. Ни одно из них в итоге бы не помешало, но мы и не знали, какой объём данных будет скармливаться алгоритму. Я предполагаю, что решения на Питоне не смогли бы корректно обработать все новости за месяц разом.

Я знаю, что некоторые писали на Go, и это, вероятно, хороший выбор. Мы же люди привычные к C++, к тому же многие библиотеки для машинного обучения вроде как имеют версии под него, поэтому мы остановились на нём. При этом никто не мешает обучать модели на Питоне, что мы тоже сделали. Использовали C++11, выше не брали из-за зависимостей.

C точки зрения NLP, мы решили застрять в 2016 году и ограничиться FastText’ом. Могли бы застрять и ещё раньше, используя только TF-IDF, но это, как ни парадоксально, было бы даже сложнее и, скорее всего, не так эффективно. FastText — это такой word2vec с добавкой из буквенных n-грамм, которые позволяют ему получать осмысленные векторы для слов не из словаря. Предобученная ELMo для русского весит 197 Мб, предобученный BERT — 632 Мб, поэтому это неподходящие варианты для этого соревнования (по крайней мере так было в начале). Кроме того, FastText доступен под C++ и без проблем статически линкуется.

По-хорошему нам бы нужен был хороший токенизатор. Но лёгких решений на момент соревнования как будто бы не было, в итоге мы просто делили по пробелам (что неправильно, не делайте так!). Уже после контеста мы нашли токенизатор из OpenNMT, и сейчас его используем. Его главная особенность в том, что он поддерживает и C++, и Python, а значит не будет никакой разницы между обучением и применением. А ещё он достаточно быстрый.

Кроме того, нам нужны были алгоритмы кластеризации, в идеале агломеративная кластеризация или DBSCAN, потому что с ними мы уже работали. DBSCAN нашёлся в MLPack, MLPack нашёлся как пакет для Debian’а. Параллельно с этим мы написали свою агломеративную кластеризацию. В итоге для того, чтобы не затаскивать такую большую зависимость, от DBSCAN’а решили отказаться. Но в целом с MLPack был не самый плохой опыт.

У нас была мысль попробовать использовать какой-нибудь фреймворк для глубокого обучения: TensorFlow, Torch, MXNet. “TensorFlow написан на C++, это будет легко” — думали мы. Во-первых, это легко до тех пор, пока вы не попытаетесь его статически влинковать. Во-вторых, итоговый бинарник банально не влезет в 200 Мб. Есть ещё Tensorflow Lite, но до него уже руки не дошли. Примерно такие же разочарования ждали нас со всеми фреймворками.

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

В итоге вышло так:

• Применение: C++, FastText, OpenNMTTokenzer, Eigen
• Обучение: Python, FastText, OpenNMTTokenzer, Keras

Для разметки использовали Яндекс.Толоку.

Решение

Для определения языка использовали готовую модель от команды FastText’а почти без изменений.

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

Для определения категорий собрали разметку в Толоке. Собирали обучающую и тестовую выборку. Для этого написали инструкцию, завели обучение, экзамен и ханипоты. Обучающая выборка собиралась с перекрытием 3 и согласованностью 2/3, тестовая с перекрытием 5 и согласованностью 4/5. Скрипты для агрегации умеют считать согласованность толокеров, она вполне приличная. К примерам на английском добавляли машинный перевод на русский. Потратили 60$ на всё. Данных получилось не очень много, для русского языка было 327 примеров в тестовой разметке и 1176 примеров в обучающей, категории были не сбалансированы. Для хорошей разметки стоило бы потратить в 3-4 раза больше денег.

Кроме нашей разметки, использовали категории из внешних датасетов. Для русского брали категории и теги Ленты, для английского BBC и News categories. При этом категории из этих внешних датасетов нужно было отобразить в категории соревнования.

Посчитав размеры на коленке, решили сделать свои предобученные FastText векторы. Предобучали на части данных из соревнования и на открытых новостных корпусах: Лента и РИА для русского; BBC, All the news, News categories для английского. Так сделано, чтобы словарь и сама модель не были завязаны на конкретный временной период.

На разметке обучили классификатор через supervised режим FastText’а с использованием предобученных векторов и заданного размера классификатора (опции семейства autotune). Supervised режим — это просто линейная модель над усреднением всех векторов слов, можно было бы сделать сложнее, и в этом месте получить качество чуть лучше.

Данные для обучения классификаторов категорий

Для хорошей кластеризации принципиально нужны 2 вещи: хорошие векторы и хороший алгоритм. В качестве векторов сначала пробовали просто усреднение векторов всех слов текста, получалось не очень. В итоге учили линейную сиамскую сеть над усреднением (а также покомпонентным минимумом и максимумом) векторов слов на задаче предсказания следующего кусочка текста. То есть брали доступные тексты, делили их пополам, над каждой половинкой делали линейный слой с связанными весами, делали скалярное произведение получившихся векторов, а потом домножали на циферку и прогоняли через сигмоиду. Использовали логлосс, в качестве единиц брали половинки одного текста. А в качестве ноликов левую половинку от одного текста, а правую — от хронологически предшествующего текста того же источника (такие вот hard-negative примеры). Вот таким способом получились уже более адекватные (на глаз) векторы. Ещё адекватнее было бы делать более сложную архитектуру половинок и использовать triplet loss. Модель строили и учили на Keras’е, но ничего не мешало это делать и на Torch’е. Веса линейного слоя экспортировали в применялку через обычный текстовый файлик.

Модель обучения векторов для кластеризации

Ежели вы спросите, а как бы мы это делали, если бы ограничений не было, так тут всё просто. Тут применимы все модели, которые обычно используют для определения парафраз, например дообученный BERT. Это бы работало, будь у нас разметка. А вот в наивном unsupervised варианте я бы ставил на ELMo. Более того, с ELMo у нас есть эксперимент.

В качестве алгоритма взяли SLINK: агломеративную кластеризацию за O(n^2) и вычислением расстояния как минимума между точками двух кластеров. У такого способа есть свои недостатки, самый главный из них — подклейка по транзитивности: первая точка склеивается со второй, вторая с третей, а в итоге первая и третья в одном кластере, хотя сами по себе далеко друг от друга.

Агломеративная кластеризация. Кого клеить первым выбираем по расстоянию между векторами.

При этом O(n^2) для всех документов за месяц — это слишком долго. Есть несколько вариантов решения этой проблемы, нам известны два: отбор кандидатов и склейка. Мы пошли вторым путём, отсортировали по времени весь массив входных документов и разбили на чанки из 10000 документов с перехлёстом в 2000 документов. Кластеризовали чанки по отдельности, по перехлёсту склеивали. Это работает только потому, что вряд ли далеко отстоящие по времени документы принадлежат одному кластеру.

Заголовочный документ кластера выбирали по 3 факторам: свежести, похожести на остальные документы кластера, весу источника. Свежесть — функция от возраста кластера, отмасштабированная сигмоида в нашем случае. Возраст кластера считаем от 99 процентиля дат всех документов. Похожесть считаем через те же векторы, что и в кластеризации. Вес источника считаем как PageRank по ссылкам, которые нашли в тексте.

Ранжировали кластера тоже по 3 факторам: свежести, весу источника, размеру кластера.

Ошибки

1. Опечатались в названии одной из категорий.
2. Неправильно выбрали процентиль для “текущего” момента времени, из-за чего на первом английском тестовом датасете вперёд выходили документы из “будущего”.
3. Плохо обучили категории для английского, из-за чего была низка полнота для некоторых категорий, в частности для науки.
4. Не парсили вложенные теги, из-за чего тексты некоторых документов были неполными.
5. При обучении линейного преобразования для векторов кластеризации мы изначально использовали только тексты из датасетов соревнования, из-за чего модель хуже обобщала, и много кластеров распадалось.
6. Закрутили в точность порог кластеризации
7. В некоторых местах некорректно обращались с числами с плавающей запятой, из-за чего немного разъехалось ранжирование документов внутри кластера и ранжирование кластеров.
8. Использовали std::sort вместо std::stable_sort, из-за чего получались невоспроизводимые результаты.
9. Не сделали нормальную токенизацию сразу, из-за чего потеряли пару процентов точности в категоризации и немного в качестве кластеризации.
10. Не написали тесты вовремя, из-за чего произошла часть из описанных выше ошибок.

Итоги

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

Чего же не хватает этой штуке до полноценного новостного агрегатора?

Во-первых, rss-качалки или любого другого способа получить документы на вход. Telegram в этом плане очень сильно считерил — вероятно всё, что проходит через его Instant View, сохраняется у него же на серверах. Данные соревнования получены именно таким образом. Вопрос о правовом статусе таких действий остаётся открытым.

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

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

На текущую версию можно посмотреть вот тут, на версию с контеста вот тут.

Системы ИБП с изолированно-параллельной шиной (IP-Bus) – ответ разработчиков на рост мощностей дата-центров. В мире уже построено много ЦОДов с IP-Bus, в том числе с сертификатом Tier IV Uptime Institute. К таким решениям присматриваются и российские заказчики.

В практике строительства ЦОДов наблюдается устойчивый тренд на их укрупнение. В мире появились объекты мощностью 100 МВт. Россия так же не остается в стороне, хотя и следует в данном направлении с некоторой задержкой. Еще 10 лет назад в нашей стране крупным считался дата-центр мощностью 5 МВт, а сегодня несколько ведущих операторов заявили о планах строительства объектов на 2000 и более стоек, что соответствует энергопотреблению 15 МВт и выше.

Для организации инженерных систем большой мощности, как показала мировая практика, наиболее целесообразной с экономической точки зрения является схема с параллельным N+x (N+1, N+2…) подключением устройств. Причем, единичная мощность самых больших в мире установок ИБП — динамических, которые можно применять в таких решениях, ограничивается мощностью (и стоимостью) самых больших дизельных двигателей, используемых для работы с ИБП.

Однако прямое параллельное включение ИБП, обеспечивая возможность создания эффективных конфигураций N + x, обладает рядом существенных недостатков:

• Низковольтные установки можно применять только в системах до 5 МВт. Это связано как с ограничениями по доступным номиналам низковольтных комплектных устройств (6300 А), так и с высокими токами короткого замыкания, значения которых могут превышать 150 кА.
• Решения на средневольтном напряжении, дающие возможность строить системы свыше 5 МВт, увеличивают стоимость энергосистемы и не всегда устраивают заказчиков в части эксплуатации.
• Общие компоненты системы – входная и выходная шины, байпас – являются общими точками отказа.

Схема N + N (2N), отвечающая уровню отказоустойчивости Tier IV Uptime Institute, дает возможность путем строительства отдельных энергомодулей уйти от основных недостатков классических параллельных систем. Но такой подход обладает другими очевидными недостатками:

• 100%-ное дублирование оборудования, т.е. высокие капитальные затраты;
• большая занимаемая площадь;
• максимальный уровень загрузки – 50% (на практике – не выше 40%);
• высокие затраты на эксплуатацию.

В силу указанных причин конфигурация N + N (2N) редко применяется для объектов мощностью свыше 10 МВт.

В 2005 г. было найдено решение, позволившее при сохранении основного преимущества параллельной схемы – оптимального числа модулей ИБП в схеме N + x – реализовать на практике системы мощностью до 20 МВт, оставаясь на низком напряжении 0,4 кВ. Это решение, получившее название конфигурация с изолированно-параллельной шиной (IP-Bus), отвечает самому высокому уровню отказоустойчивости (Tier IV Uptime Institute). В основе идеи IP-Bus – использование кольцевой шины для соединения отдельных модулей ИБП, каждый из которых изолирован с помощью дросселя (рис. 1).

Рис.1. Изолированно-параллельное включение ИБП

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

• позволяет перераспределять активную мощность между ИБП – модуль ИБП с меньшей нагрузкой «помогает» другим модулям, передавая избыток мощности через IP-шину (рис. 2);
• обеспечивает бесперебойное электроснабжение нагрузки в случае отключения ИБП для сервисных работ или при аварии (рис. 3, рис. 4);
• замедляет обмен реактивными токами между установками ИБП, за счет импедансов дросселей, так что отпадает необходимость в управлении реактивной мощностью внутри системы.

• эффективно ограничивает токи короткого замыкания в различных сценариях КЗ (рис. 5).

  Благодаря возможности естественного распределения нагрузки без какого-либо внешнего управления системы IP-Bus, как правило, реализуются в конфигурациях с резервированием N + х (N + 1, N + 2…). Сокращение количества избыточных ИБП до минимума позволяет обеспечить загрузку установок ИБП в системе на высоком уровне — свыше 70%, что делает такие системы очень энергоэффективными.

<img src="" alt=«image»/>
Рис. 2. Пример распределения нагрузки в системе из 16 установок ИБП

В отличие от «прямой» параллельной конфигурации, в системе IP-Bus каждая установка ИБП управляет своим напряжением на выходе независимо от других – отсутствует централизованное устройство управления и исключается общая точка отказа. Если предположить, что поток мощности от одного ИБП по какой-либо причине внезапно пропадает, его нагрузка остается подключенной к IP-Bus с помощью IP-дросселя, который теперь работает в качестве резервного источника питания. При таком сценарии нагрузка будет автоматически и бесперебойно получать питание из шины IP-Bus (см. рис. 3).

Рис. 3. Пример резервирования системы при отказе/выключении одной установки ИБП

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

Рис. 4 Пример работы нагрузки №2 напрямую от резервной шины IP Bus

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

При коротком замыкании на стороне нагрузки ИБП (см. рис. 5) воздействие такого замыкания на всю систему относительно незначительно в силу того, что остающиеся в работе нагрузки изолированы от ИБП посредством двух последовательно включенных дросселей. С другой стороны, ток КЗ, отдаваемый ИБП на общую IP-шину, ограничен сопротивлением IP-дросселя. Поэтому изменения в напряжении на не пострадавших нагрузках незначительны и остаются в безопасной области кривой ITI (CBEMA).

Рис. 5. Пример распределения и величин токов КЗ в системе IP-Bus при КЗ на шине питания нагрузки, подключенной к ИБП 2

В случае короткого замыкания на шине IP-Bus, между точкой КЗ и ИБП или нагрузкой расположен только один IP-дроссель. Поэтому провал напряжения на нагрузках при таком сценарии будет намного больше, по сравнению со случаем КЗ в системе распределения нагрузки. При низком переходном сопротивлении ИБП начальное падение напряжения на нагрузке составит 30%. Для чувствительных блоков питания серверов, в соответствии с кривой ITI (CBEMA), такое падение напряжения допустимо в течение максимум 500 мс. Применение сегментированной направленной защиты, специально адаптированной к требованиям системы IP-Bus, позволяет очищать КЗ на шине IP-Bus в течение 60 мс путем выборочной изоляции очага КЗ и одновременно позволяет той части системы IP-Bus, на которую это непосредственно не влияет, оставаться полностью работоспособной.

Система IP Bus состоит из нескольких установок ИБП, количество которых определяется заданным уровнем резервирования N+x и включает следующие основные компоненты: ИБП с устройством накопления энергии, IP-дроссель для подключения установки ИБП к IP-шине и выключатели, необходимые для безопасной работы системы.

На рис. 6 показан один из вариантов системы IP Bus на базе роторного ИБП.

Элементы системы:

1. Внешняя сеть
2. Шина IP-Bus
3. Возвратная шина IP-Return-Bus
4. Роторный ДИБП с маховиком
5. ДГУ на длительный перерыв сети (опционально)
6. IP-дроссель
7. Обходной переключатель
8. IP-выключатели
9. Нагрузка

Рис. 6. Пример системы IP-Bus с применением роторного ИБП Piller UNIBLOCK и внешнего ДГУ с «нижним» включением

Согласно практическому опыту компании Piller, динамические ИБП с маховиками (рис. 6) в качестве устройств хранения резервной энергии являются идеальным решением для систем IP Bus поскольку кинетические накопители в составе ДИБП могут работать в режиме как мгновенного поглощения энергии, так и мгновенного разряда, что важно для стабилизации рабочих параметров системы IP-Bus при изменениях нагрузки.

Кроме того, мотор-генераторы в составе ДИБП обладают способностью поставлять высокие токи КЗ – до 20 х Inom, что позволяет системам IP-Bus за очень которое время справляться с очисткой КЗ, не подвергая соседние нагрузки негативным воздействиям короткого замыкания.
Статические ИБП с аккумуляторными батареями имеют ограниченные возможности мгновенно отдавать и принимать большие токи, а кроме того, токи КЗ самих ИБП относительно невысоки. По этим причинам решения IP-Bus на статических ИБП – это скорее эксперименты, и в действующих ЦОДах они практически не встречаются.

Первая в мире система IP-Bus была реализована в 2007 г. для ЦОДа мощностью 36 МВт в Эшберне (Вирджиния, США). На объекте были установлены две отдельные системы IP-Bus, каждая из которых включает 16 ИБП Piller UNIBLOCK UBT 1670 кВА с маховиками в конфигурации 14 + 2. На случай длительных пропаданий внешней сети каждый ДИБП резервируется отдельным дизельным генератором 2810 кВА с «нижним включением», который работает как на нагрузки бесперебойного, так и гарантированного электропитания
После успеха реализации первой системы IP-Bus такая конфигурация стала быстро набирать популярность в индустрии ЦОДов. Очередной важной вехой в развитии и признании технологии IP-Bus стало получение австралийским ЦОДом NEXTDC B2 с системой электропитания IP-Bus N + 1 сертификата Tier IV Design & Facility Uptime Institute в сентябре 2017 г.

Российский рынок ЦОДов только входит в этап строительства крупных объектов мощностью свыше 10 МВт. По результатам первых расчетов концепций и бюджетных оценок решений IP-Bus на нескольких проектах ЦОДов в России (в диапазоне мощностей 5—15 МВт) можно сделать следующие выводы. В сравнении с конфигурацией 2N на статических ИБП решения IP-Bus на базе ДИБП не дороже в начальных капитальных затратах, дают выигрыш 30—60% в занимаемой площади, более чем на 50% выгоднее по стоимости владения (ТСО) на отрезке 10 лет. В сравнении с распределенно-резервной конфигурацией N + 1 (DR 3/2, 4/3), реализуемой как на статических, так и на динамических ИБП, решения IP-Bus на базе ДИБП не дороже в начальных капитальных затратах (для ЦОДов мощностью 10 МВт и более), дают выигрыш 20—50% в занимаемой площади, выгоднее на 50% по ТСО на отрезке 10 лет.

Таким образом, уверен, что внедрение систем IP-Bus в российских ЦОДах – лишь вопрос времени.

Мобильный телефон в рабочем процессе – это зло или благо? Гаджет позволяет сотруднику оперативнее решать задачи? Или помогает работодателю жестче контролировать подчиненного? Создает креативную обстановку? Или напрягает в 23:00 сообщениями в мессенджере и письмами? Способствует утечке корпоративных секретов или, наоборот, дает страховку от неожиданностей? 

Что такое корпоративная мобильность, каково текущее ее состояние и в чем история этого понятия, разбираемся с нашими партнерами из Научно-испытательного института систем обеспечения комплексной безопасности (НИИ СОКБ).

Источник

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

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

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

Чтобы сделать повествование более предметным, мы взяли интервью у наших коллег из НИИ СОКБ, которые имеют большой опыт в подобного рода проектах и готовы поделиться примерами, историями и наблюдениями из своей практики (теория теорией, но в жизни всё всегда сложнее и интереснее ).

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

Расскажите, как мобильные устройства пришли в российский бизнес и как менялись взгляды на их применение?

«Мобильной» тематикой мы занимаемся достаточно давно (уже более 10 лет — можно сказать, стояли у истоков), поэтому в становлении данного IT-направления мы участвовали с самого начала.

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

Переломный момент, на мой взгляд, произошёл в середине нулевых, и связан он с двумя событиями: покупкой в 2005 году Google Android, Inc. с последующим запуском одноимённой платформы и анонсом в 2007 первого iOS-устройства (тогда ещё с iPhone OS). Обе эти платформы сразу предлагали богатый функционал помимо звонков и SMS и быстро начали вытеснять классические кнопочные телефоны.

Естественно, счастливые обладатели этих устройств начали использовать их и в работе: иногда с одобрения руководства, иногда «подпольно». Это привело к возникновению тенденции, при которой устройство постепенно накапливает важную корпоративную информацию (подключили почту – появилась конфиденциальная корпоративная переписка, разрешили доступ к CRM – к переписке добавился список клиентов и т.д.). Потеря или кража гаджета становится всё более значимым риском для компании. Именно в этот момент и начинается история систем централизованного управления корпоративной мобильностью, в том числе и нашей платформы SafePhone.

Какова роль мобильного устройства в бизнесе в настоящий момент?

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

Источник: Broadcom

Вообще, сейчас наблюдается интересная картина. С момента зарождения IT считалось, что для полноценной работы сотрудникам нужен настоящий, большой компьютер или ноутбук, но обязательно с полноценным x86-процессором. Попытки сдвинуть эту ситуацию с мёртвой точки всегда упирались в железобетонный аргумент из серии: «у нас есть системы, работающие только под DOS (Windows 95/98, Java 5 — нужное подчеркнуть), вы всё нам поломаете». Надо понимать, что корпоративная среда достаточно консервативна (программисты на COBOL до сих пор востребованы).

Первые подвижки начались с повсеместного внедрения виртуализации и появления VDI (Virtual desktop infrastructure). Внезапно выяснилось, что работать с Legacy-системами можно вообще с любого устройства, лишь бы было защищенное подключение к сети. Сеть, кстати, долгое время и была сдерживающим фактором для развития данной технологии, но, похоже, что и это ограничение скоро будет снято. С появлением нового поколения 5G, не в последнюю очередь благодаря Samsung, предоставляющих связь на скоростях от 1 Гбит/с, через мобильную сеть можно с минимальной задержкой «прогонять» фактически любые корпоративные  типы данных (документы, звук, видео хорошего разрешения). Ещё одним следствием такого «ускорения» также является всеобщая тенденция отказа от «толстых клиентов». Большинство современных бизнес-систем имеет нормальный веб-интерфейс, многие в дополнение к этому выпускают мобильного клиента или мобильную версию веб-интерфейса (которую также можно «завернуть» в приложение с помощь Progressive Web App).

Таким образом, получается, что сейчас, по сути, ничто не мешает работать только на смартфоне или планшете. Это, конечно, пока некоторая перспектива (помним про консерватизм ), но её реализация уже не за горами.

Т.е. получается, что мобильные устройства в будущем могут заменить классические ПК в корпоративной среде?

Постепенно бизнес уходит от системных блоков в сторону чего-то более мобильного. Сначала это были достаточно громоздкие пятикилограммовые лэптопы, работавшие на батарее не более полутора часов (старожилы вспомнят страшные выпирающие части расширенной батареи, которые давали один час к работе и полкило к весу), потом мы перешли на ультрапортативные ноутбуки весом 1,5-1,7 килограмм и временем работы шесть – семь часов, а сейчас уже повсеместно распространены аппараты меньше одного килограмма с 12 часами автономной работы. 

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

Конечно, самый главный вопрос – это софт. Тут всё неоднозначно. Многие производители пробовали адаптировать десктопный интерфейс к использованию в мобильном окружении (touch, сравнительно небольшие экраны и прочие атрибуты мобильности), но идеальных решений пока, к сожалению, нет: возвращаемся к той самой пресловутой консервативности; никто не будет переписывать интерфейс на Delphi двадцатилетней давности. Вместе с тем в нативные мобильные приложения гораздо проще добавить поддержку «резиновых»/перетаскиваемых окошек, что, собственно говоря, и сделала компания Google в Android Nougat. Если интересен пример такого подхода, то можно обратить внимание на Samsung DeX.

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

Как внедрение мобильных технологий влияет на рабочий процесс?

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

Источник: Dilbert, перевод наш

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

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

Ещё одним стимулом для сотрудников может служить предоставление мобильного устройства. На практике в компаниях распространены различные модели, от предоставления корпоративного гаджета с возможностью персонального использования смартфона (Corporate Owned, Personally Enabled, COPE), до персонального смартфона или планшета с рабочими приложениями (Bring Your Own Device, BYOD). Кстати, BYOD ведет свое происхождение от достаточно известной для тусовщиков аббревиатуры BYOB – bring your own beer – то есть «приходить со своим алкоголем» в описании вечеринки.

Человек, который перепутал BYOD с BYOB. Источник: Timo Elliott

Также возможны некоторые промежуточные варианты, при которых сотрудник может выбрать себе рабочее устройство с частично корпоративной оплатой и перспективой перехода гаджета в собственность через некоторое время (Choose Your Own Device, CYOD).

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

Что такое управление корпоративной мобильностью, и зачем это нужно?

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

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

На заре отрасли выбор всегда делался в сторону ограничений. Это порождало курьёзные ситуации. Сотруднику в качестве поощрения давали возможность установить на своё устройство корпоративную почту. Делалось это с условием применения всех правильных политик безопасности и установки агента для мониторинга потенциальных угроз. Этот агент безальтернативно устанавливал 12-значный цифро-букво-символьный пароль (в особенно изысканных случаях там был ещё словарь запрещённых комбинаций и ограничение по ротации паролей) на всё устройство и начинал собирать всю доступную ему информацию. Помучившись так неделю (при каждой попытке прочитать SMS нужно вводить этот самый пароль), пользователь со злостью удалял почту и забывал про это «поощрение» как страшный сон.

Источник: Dilbert, перевод наш

Сейчас ситуация кардинально поменялась. Хорошей практикой считается, когда система безопасности прозрачна и максимально незаметна для пользователя. Ей следует быть как замок из известной загадки, который «не лает, не кусает, а в дом не пускает». Пользователю должно быть максимально удобно работать с устройством, всю грязную работу на себя берёт система управления мобильностью.

Существует большое количество аббревиатур для систем управления корпоративной мобильностью — MDM, EMM, UEM. Расскажите в двух словах, в чем их различие и как это укладывается в единую концепцию?

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

Mobile Device Management (MDM) – термин, появившийся в конце 1990-х – начале 2000-х, обозначает системы, которые отвечают за управление жизненным циклом мобильных устройств. Под этим обычно понимают следующий функционал:

• инвентаризация устройств,
• настройка параметров ОС,
• управление подключением и отключением устройств от системы (provisioning and deprovisioning) 

Со временем чистого MDM-функционала стало не хватать, и к нему часто стали добавлять следующие возможности:

• Mobile Application Management (MAM) – управление приложениями.
• Mobile Identity (MI) – управление учётными данными и доступом.
• Mobile Content Management (MCM) – управление контентом.

К середине 2010-х данный набор стал стандартом для рынка, и уже не было смысла делить решения на отдельные модули. Тогда появился термин Enterprise Mobility Management (EMM), который обозначал совокупность MDM, MAM, MI и MCM. Данное изменение было зафиксировано отчётом Gartner, опубликованным в 2014 году.

Далее возникла тенденция, о которой мы говорили раньше. Мобильные устройства стали точно таким же рабочим местом, как и классические десктопы и лэптопы, и стало понятно, что управлять ими нужно в едином контуре: больше нет деления на стационарное и мобильное. Это было отправной точкой для появления нового термина Unified Endpoint Management (UEM). Появление UEM было зафиксировано в отчёте Gartner 2018 года.

Источник: ITSMDaily

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

Мы обсудили историю и теорию, давайте перейдём к практическим вопросам. Как теперь мобильное рабочее место может появиться на предприятии? Поделитесь, пожалуйста, опытом в данной сфере.

Любое внедрение – это всегда комплексная история, и двух одинаковых проектов не бывает. Но попробуем сформулировать некоторые общие моменты.

Инициатива по внедрению часто идёт снизу, от рядовых сотрудников. Сейчас мобильные устройства есть почти у всех, и это только вопрос времени, когда их станут применять для работы. Должна набраться критическая масса из людей с подобными гаджетами, после чего в сторону IT-отдела идёт запрос на предоставление подобной услуги. 

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

Сначала это, как правило, почта (возможность «забирать» её мобильным клиентом), далее идут документы и различные рабочие системы (корпоративный портал, ERP, CRM и пр.). После «укоренения» технологии (когда становится отчётливо понятна тенденция), проектирование внутренних сервисов уже идёт с расчётом на их использование на различных платформах (в т. ч. мобильных).

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

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

•  Проведение аудита и обследование текущего состояния инфраструктуры до начала внедрения. Это может быть мониторинговое ПО, установленное на конечные устройства с согласия пользователей и собирающее статистику по используемым приложениям и посещаемым сетевым ресурсам. Важна максимальная открытость и корректность в вопросах соблюдения анонимности и неприкосновенности частной жизни сотрудника. Конечная цель данной активности — получить комплексную картину текущей ситуации, а не выявить нарушителей. Хорошо работают разъяснительные семинары с наглядной демонстрацией функционала мониторингового ПО и вовлечение в процесс сбора статистики руководства.
• Обратная связь. Важно понимать, что происходит с проектом на стороне конечных пользователей. Это может дать ценную информацию об особенностях работы системы и положительно сказывается на отношении сотрудников. Форматы обратной связи могут быть различны: от очных встреч с обсуждением текущих проблем до некоторого опросника, возможно, анонимного, т.к. не все готовы свободно делиться своими впечатлениями. 
• Рассчитывать ресурсы на итеративный процесс разработки и внедрения. Всё учесть на этапе старта проекта невозможно, поэтому всегда нужно закладывать дополнительные ресурсы на доработку. Многие при внедрении этого не учитывают, из-за чего проекты обрываются где-то в середине.

Два главных вопроса, которые всегда задают при внедрении:

•  «Я ставлю систему на своё личное устройство, работодатель может читать мои файлы/переписку и будет следить за мной»

  Нет, это не так. На сегодняшний день единственный вариант установки агента системы управления на ваше личное устройство – рабочий профиль (Work Profile). Рабочий профиль – это изолированная область, по сути — контейнер, аналогичный защищенной папке в телефонах Samsung. Приложения, установленные в ней, не имеют доступ к вашим личным данным и файлам, соответственно, они никак не могут повлиять на них. 

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

•  «ИТ-специалист тратит 10 минут на настройку одного корпоративного устройства. Получается, что наш парк в 300 устройств он будет настраивать неделю, больше вообще ничего не делая. Это невозможно»

  Если решать эту задачу «в лоб», то цифры получаются примерно такие (всё, конечно, сильно зависит от каналов связи и других внешних условий). Но есть и альтернативные подходы. В семействе Samsung Knox есть микросервис, называющийся Knox Mobile Enrollment (KME), который позволяет при первом подключении к сети «из коробки» устанавливать на устройство клиент управления и передавать ему настройки для подключения к серверу. Пользователю при этом не требуется совершать никаких действий. Таким образом мы можем существенно сократить участие IT в процедуре развёртывания. Из приятного – сервис бесплатный и он интегрирован в нашу систему.

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

Это стереотип, но он достаточно устойчивый. Особенно печально, что его влиянию подвержены не только простые пользователи, но и некоторые работники IT и информационной безопасности. 
Нет, сейчас ОС Android достаточно безопасна и очень распространена в корпоративном сегменте. Об этом говорит недавнее исследование, проведённое компанией IDC. Согласно нему 78% мобильных устройств, использующихся в различных компаниях по всему миру, работают под управлением ОС Android.

Отдельно про защищённость устройств Samsung. Согласно последнему рейтингу Gartner, платформа Knox получила рейтинг «strong» в 27 из возможных 30 позиций, что является одним из самых высоких результатов (примечание Samsung: более подробно про платформу Knox мы рассказывали в данной статье).

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

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

    

  • Вирусы/троян. Одной из особенностей платформы Android является её открытость (написать приложение может любой). Этим, к сожалению, могут пользоваться злоумышленники. На корпоративных устройствах, имеющих доступ к важным данным, имеет смысл запрещать некоторые потенциально опасные приложения через чёрные списки. При работе с особо важными данными используется и более жёсткая политика белых списков — только включенные в него приложения могут быть установлены на устройство.

    

• Data-in-transit (передача данных). Сюда включаются все угрозы, связанные с передачей данных. Тут могут быть следующие примеры:
  
  • Незащищённый трафик. Публичные Wi-Fi точки доступа бывают полезны по время командировок или когда вы далеко от рабочего места, но нужно поработать с большим объёмом данных. При этом, к сожалению, нельзя гарантировать, что канал безопасен, и его не отслеживают злоумышленники. Для борьбы с данным типом угроз обычно используют VPN с автоматической активацией по запуску определённых приложений.
    

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

• Управление обновлением ОС. Обновления обязательно нужно ставить (примечание Samsung: по этой тематике у нас также была статья), но в корпоративной среде есть нюанс: приложения обычно модернизируются медленно, и очередной апдейт может повлечь за собой сбои в работе критически важной для бизнеса системы, а это означает финансовые потери. Поэтому к обновлениям ОС нужно подходить аккуратно, всегда анализируя нововведения и проводя тестирование на предмет совместимости с текущей инфраструктурой.

  

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

  

• Отчётность. Для понимания, куда развиваться, требуется комплексная картина. Чем детальнее эти данные будут, тем лучше мы можем проанализировать текущую ситуацию и перспективы. При этом получение данных не должно нарушить личную жизнь сотрудников (никакой персональной информации).

  

В принципе, это очевидные запросы. Но реализовать их удаётся не всегда в силу ограниченных возможностей разных платформ. В своё время в решении данных задач нам очень помог Knox Platform For Enterprise — разновидность платформы Knox для корпоративных задач. KPfE — это набор инструментов (SDK, утилиты, веб-сервисы и аппаратные механизмы устройств), расширяющий возможности стандартной ОС Android в части управления и мониторинга. Удобно, что для использования функционала не обязательно писать много кода, есть вариант использования Knox Service Plugin, который настраивается с помощью OEMConfig (стандартный механизм Android for Enterprise).

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

Напоследок хотелось бы поговорить про российский рынок. Есть ли у проектов, реализованных у нас в стране, какая-то специфика?

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

Ярчайшим примером таких предубеждений является облако. Часто заказчики категорически отказываются от использования этого подхода, аргументируя решение отсутствием доверия к безопасности и надёжности подобных систем. Эта точка зрения, на наш взгляд, сегодня уже неактуальна. «Облачный» не значит «ненадёжный» и «небезопасный». Это доказывается опытом многих крупных компаний, доверивших облакам существенную часть своих бизнес-процессов — Netflix, Spotify, и целый ряд других. 

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

Отдельно стоит отметить требования сертификации решений, предъявляемые регуляторами, например, для работы с персональными данными. Бытует мнение, что такое на Android невозможно. Наш опыт показывает, что в сочетании с сертифицированными средствами обеспечения безопасности это возможно даже в организациях с жёстким регламентом.

(от автора) Мы надеемся, что нам удалось развеять некоторые «страшилки», и уж по крайней мере теперь станет ясно, что в жизни всё несколько сложнее, чем в этом комиксе:

Источник: Dilbert

Задавал вопросы:
Владимир Карачаров,
Manager, B2B Pre/Post Sales
Business Development Team
Samsung R&D Institute Russia

Отвечал:
Олег Ассур, 
Главный инженер
НИИ СОКБ