Блог компании it-grad

В Москве семь часов вечера. Рабочий день подошел к концу. Коллеги прощаются, закрывают лэптопы и выходят из Zoomа. Город потихоньку засыпает, просыпаются айтишники. 19:00 по Москве это 08:00 в Сан-Франциско. Моя подруга из VMware Маша Шалдыбина делает утренний кофе, логинится и впрочем, обо всем по порядку.

Привет, Хабр. Меня зовут Катя Юдина, я руководитель контент-маркетинга облачного бизнеса МТС. Буквально на днях я взяла небольшое интервью у своей давней подруги, которая сейчас работает в центральном офисе хоум-офисе компании VMware. Под катом вас ждет интересный рассказ о карьере ИТ-специалиста в крупной международной компании. Поговорим о том, как происходит трудоустройство на западе, как устроена работа в VMware и почему мировой карантин почти никак не затронул отдел разработки.

Кстати, у нас отличная новость! Если у вас нет времени на чтение, можно прослушать подкаст-версию статьи по этой ссылке.

---

Маша, как начался твой путь в ИТ?

Скорее, не как, а когда в раннем детстве. Повлияла семья: оба родителя у меня физики. Так что у нас дома постоянно была разная электроника, даже компьютеры (что на тот момент было большой редкостью). Я достаточно рано освоила Бейсик. Помню, устраивала себе развлечение: писала программы, которые рисовали разные картинки на экране. Уже в школе заинтересовалась онлайн-играми, они как раз тогда только-только пошли. Когда я училась в 10 классе, была очень популярна Ragnark Online. Игрушка меня заинтересовала, но сам геймплей показался неторопливым. Нужно было постоянно фармить и ждать. Так что я развернула свою собственную версию и начала копаться в ее коде, чтобы настроить игру под свои хотелки.

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

Ты помнишь свое первое место работы?

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

Еще в ВУЗе я познакомилась с будущим мужем, Олегом. Дальше мы двигались вместе. Стало понятно: если мы хотим добиться большего, понадобится переезжать. Из Ташкента мы отправились в Санкт-Петербург. Там мы продолжили карьеру веб-разработчиков: я в Daxx, а Олег в Murano.

Тем не менее, мы все время находились в поисках лучшего. Через какое-то время муж прошел интервью в Microsoft, и его пригласили на работу в парижский офис. Но судьба распорядилась иначе. У компании, в которой он тогда работал, было много клиентов из США. Когда одному из них стало известно, что муж увольняется, он предложил ему дальше работать напрямую. Почему бы и нет?

Дальше началась маета с визами. После первого интервью в посольстве США на J-визу мы получили отказ. Пришлось штурмовать Америку заново. Наученные горьким опытом и добрым послом, мы подготовили новый пакет документов и подали на визу H1B. Шел 2008-й, год финансового кризиса, даже лотерея тогда не проводилась из-за недобора запросов (если в первый день подачи документов на визу, первого апреля, не набирается 65000 запросов, лотерею не проводят).

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

Эти же документы мы взяли с собой в Америку. Таможенник на границе проявил компетентность и долго расспрашивал нас про этот сайт. Нам показалось даже, что он украдкой зашел на него во время беседы. Когда очередь дошла до меня, я сказала, что работать не планирую виза не позволяет. Таможенника этот ответ устроил, и мы, наконец, услышали заветное: Welcome to the United States.

Ты сразу пошла на работу в VMware?

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

Самый главный документ США, SSN (номер социального страхования, который присваивается всем гражданам и резидентам США), мы оформили быстро и без проблем. Всю информацию в доступной форме можно найти на сайтах агентств.

Разумеется, сложа руки я не сидела. Постоянно решала задачи на всяких Topcoderах и CodeSprintах, готовилась к интервью. Есть такая хорошая книга Cracking the Coding Interview. В ней описано, как проходить собеседования в крупных ИТ-компаниях, таких как Google или Facebook. Много хороших задач с решениями, рекомендую. Еще я прошла сертификацию на знание языков программирования, создала приложение для iPhone то есть, всеми силами старалась сформировать хорошую базу для устройства на работу.

Cracking the Coding Interview

Когда через год я получила разрешение на работу, началась фаза активных поисков компании мечты. У меня были друзья в Facebook с их помощью удалось получить приглашение на интервью. Здесь важно понимать: в Америке как нигде сильно понятие leverage потенциальный работодатель может заинтересоваться тобой, если ты упомянешь о собеседовании в другой компании того же ранга. Так что интервью в Facebook мне помогло получить приглашение от VMware. Они устроили все очень быстро, предложили даже пропустить телефонный этап и сразу пригласили on-site в офис. Дальше все достаточно стандартно: мне дали несколько задач, после решения я лично поговорила с руководителями и получила оффер. Собственно, так я и попала в VMware.

Расскажи подробнее об интервью. Что требуется, какой бэкграунд нужен кандидатам? Как проходит собеседование в деталях?

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

Может быть беседа с HR спрашивают про карьеру, цели, почему именно к нам?. Еще одна интересная разновидность интервью на дизайн. Писать код уже не придется вам зададут некий общий вопрос из серии как бы вы построили подобное приложение? и попросят обосновать свой выбор.

А что после собеседования? Сразу в поле или есть какая-то адаптация?

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

Pivotal Tracker

Когда я присоединилась к VMware, мне поручили работу в проекте Cloud Foundry. На тот момент он существовал всего год. В двух словах, Cloud Foundry это система, которая позволяет разработчикам запускать свои приложения в облаке. Лично я работала над компонентами, отвечающими за корректную работу приложений, написанных на Node.js, он тогда как раз был на пике популярности.

Интересный момент как известно, основная деятельность VMware долгие годы была сосредоточена на решении достаточно низкоуровневых задач, близко к железу. А Cloud Foundry это уже software-level, он выбивался из концепции. Поэтому все высокоуровневые проекты решено было объединить в компанию Pivotal. То есть фактически это родная сестра VMware, обе находились в собственности Dell.

Таким образом, я перешла из VMware в Pivotal. Кто-то из моих коллег был против перехода, они остались в VMware, ушли на другие проекты. Дело было в экстремальном agile-подходе к написанию кода, принятом в Pivotal. Парное программирование, SCRUM-собрания. Мне это показалось интересной возможностью научиться чему-то новому, да и с людьми мне общаться легко. Почему бы и нет?

Так началась моя карьера в Pivotal. Спустя семь лет после начала моей работы компанию купила VMware, и я вернулась туда, откуда начинала (смеется).

На самом деле, все оказалось не так страшно. Сессии парного программирования устраиваются ежедневно с 9 утра до 6 часов вечера. Все очень хорошо организовано: на утреннем стендапе мы определяемся с пулом задач и выбираем себе пару. Садимся за один компьютер, работаем над одним и тем же кодом, но при этом у каждого свои монитор, клавиатура и мышь. Практика парного программирования обычно подразумевает, что один из нас драйвер, ведущий, а второй ведомый. Роли распределяются так: драйвер печатает код, фолловер проверяет и смотрит наперед, какие ошибки могут возникнуть в его работе. Идет постоянное обсуждение, как можно улучшить то или иное решение. Это очень помогает решать сложные задачи как известно, одна голова хорошо, а две лучше. Для продуктивности роли внутри пары меняются, обычно в середине дня. Кстати, у нас есть инстаграм, там можно посмотреть, как выглядят наши рабочие будни и праздники.

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

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

А как вы уходили на карантин? Были сложности с построением коммуникации с удаленным партнером по программированию?

Мы начали переход на удаленный режим работы еще до карантина. У нас было много офисов в Нью-Йорке, Лондоне, Мюнхене. Иногда члены одной команды могли жить в разных городах. Да мы и ранее занимались парным программированием удаленно. Например, в моей команде были ребята из Нью-Йорка. Утром мы все встречались в Zoom, обсуждали дела и разделялись на пары. Собственно, на карантине все происходит точно так же. Ведущий включает демонстрацию экрана, ведомый может делать аннотации и по необходимости перехватывает управление. С кодом работаем в основном в Visual Studio Code. При необходимости разворачиваем виртуальную машину и работаем на ней. В этом сценарии для совместной работы в терминале используем Tmux, а код пишем в Vim. Мы привыкли к такому формату, так что карантин не стал для нас шоком.

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

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

В двух словах: над какими продуктами ты работала/работаешь?

Над Tanzu Application Service. Я участвовала практически во всех командах разработки: различные бэкенд-подсистемы, фронтенд, интерфейс командной строки, непрерывная интеграция и релиз. Примерно раз в год в проекте происходит ротация, и команды перетасовываются. Это не только предотвращает выгорание, так как не приходится годами долбить одно и то же, но и не порождает новых проблем, что тоже важно. Наоборот, свежий взгляд на код помогает делать его лучше и чище.

Маша, спасибо! Надеюсь, следующий раз получится рассказать об одном дне из жизни разработчика Google :)

***

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

Не так давно мы публиковали интервью Один день из жизни разработчика VMware рассказ о карьере ИТ-специалиста в крупной международной компании.

А сейчас у нас возникла идея поискать в своем отечестве, и мы обратили внимание на российский офис VMware. Программистов в нем нет, но есть о чем поговорить с инженерами presales. Встречайте Михаил Михеев!

Если вы стояли у истоков использования виртуализации в России, то вы могли знать о нем как о человеке, который:

• вел блог по этой узкой тематике и обучающие курсы;

• участвовал в организации встреч сообщества;

• написал книгу Администрирование VMware vSphere.

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

Эксперт с форума

Пути, по которым ведет нас жизнь, не всегда поддаются логическому анализу. Порой даже случайности, которым не придаешь особого значения, становятся решающими. Итак, представьте: Казань. Я учусь на последнем курсе университета. Стажируюсь за еду бесценный опыт у местного интегратора. (Большое спасибо им, кстати: я в первые полгода действительно не умел делать ничего полезного, чтобы просить денег.) И вот передо мной поставили задачу разобраться с неподдавшимся с наскока продуктом, Microsoft SMS 2003. Мне удалось найти один админский форум: там я искал информацию и задавал тонны вопросов в основном как раз по этому продукту. В первое время я только спрашивал, затем осмелел и начал понемногу отвечать менее опытным товарищам. Как потом выяснится, потребность делиться знаниями это неотъемлемая часть моего характера.

Мои ответы заметил форумчанин, очень много помогавший мне на начальных этапах. Можно сказать, я рос на его глазах. Совпало, что в то же самое время к нему обратился один из московских учебных центров: мол, есть ли на примете тренер, который может прочитать курс по MS SMS? И он пришел с этим предложением ко мне.

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

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

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

Шел 2005 год. Товарищ с форума оставил мне контакты учебного центра. Представьте мое состояние: где я, студент Миша из Казани, а где это достойное заведение! Заметьте: я раньше не только лекции сам не вел, но даже слушателем подобных вендорских курсов мне бывать не доводилось. Я очень ОЧЕНЬ волновался перед звонком.

Но, как говорится, колени дрожат, а руки делают. Я согласился на этот вызов. Мы договорились о личной встрече, я съездил в Москву на собеседование, а дальше как в тумане. Чтобы я получил представление о том, как все это вообще происходит, учебный центр позволил мне принять участие в качестве слушателя на другом курсе. Затем предоставил trainer guide и назначил дату курса уже со мной в роли тренера.

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

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

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

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

(Сейчас душевная рана почти затянулась, поэтому расскажу: моя будущая жена смогла переехать лишь спустя целый год. Все это время я жил в Москве один, без нее. Это было отдельным вызовом.)

Со временем я начал читать и другие курсы по продуктам Microsoft немного, буквально две-три штуки. Учебный центр нашел еще одного нишевого вендора, и некоторые курсы по его продуктам тоже достались мне. Приблизительно в то же время (2006 год) на российский рынок вышла и VMware. Мой учебный центр оперативно заключил с ними соглашение, и я стал первым преподавателем по vSphere (тогда продукт носил немного другое название) на территории РФ. Наверное, достаточно долгое время я был вообще единственным. Как и сейчас, курс назывался Install, Configure, Manage (ICM). Добротный и весьма полный материал для подготовки молодых бойцов в сфере виртуализации.

Личный блог для самообучения

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

В первое время мне за глаза хватало и тренинг-гайда: я мог прочитать его 10 раз и каждый раз находил что-то новое. Много времени я проводил с лабораторными машинами: разворачивал продукты, воспроизводил лабы, крутил их по-разному. Эта практика тоже оказалась очень полезной, я восполнял пробелы в базовых знаниях. Сейчас уже не вспомню: возможно, я читал какие-то англоязычные книги, но привычки их искать и изучать еще не было. Это пришло немного позже. Может быть, я тогда вообще ничего профильного со стороны не читал (смеется).

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

Главная страница блога Михаила

Работа преподавателем, с одной стороны, заставляла меня постоянно получать новые знания, с другой оставляла много свободного времени на учебу. Либо тренинги удавалось закончить немного пораньше, либо выдавались свободные недели, и я мог активно постить в блог. Можно сказать, я тогда занимался на 90% именно переработкой: публиковал короткое резюме-выдержку со ссылкой на оригинальную заметку.

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

Огонь в глазах, дискуссии и споры

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

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

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

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

Мужики в свитерах: правда или вымысел?

Пару слов скажу о контингенте на моих курсах: на 98% процентов это были системные администраторы и инженеры заказчиков или интеграторов. Как правило, характеры у тех, кто представляет заказчиков, отличаются от тех, кто пошел на работу к интеграторам. Это, скорее, курьезное наблюдение, чем строгое. Что касается возраста были все, от молодежи до зрелых специалистов. Люди постарше приходили, конечно, реже.

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

Когда в 2008-ом у меня вышла собственная книга и в узких кругах я стал Тем-Самым-Михаилом-С-Книжкой, я даже дежурно шутил: жаль, что в ИТ мало девушек. Приятно, конечно, когда бородатые мужики в свитерах пожимают тебе руку и говорят, какую классную книгу ты написал. Это льстит. Но все равно это бородатые мужики в свитерах

(На всякий случай еще раз поясню: это дежурная шутка!)

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

Как писалась книга

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

Я хорошо запомнил день, с которого все началось. Меня тогда отправили в командировку в Хабаровск как раз таки с курсами по VMware. Время от времени я летал с учебными задачами, в основном по отдаленным от Москвы местам: Казахстан, Баку, Дальний Восток. А длительный перелет это смена часовых поясов и неминуемый джет лаг.

Представьте себе: 4 часа утра. Гостиница, сна ни в одном глазу. Чтобы занять руки, отвечаю на вопрос читателя моего блога. Гуглю, чтобы уточнить информацию и попадаю... правильно, в собственный блог! Выходит, я все это знал, даже писал об этом, но забыл. За пониманием пришло озарение: а что, если я возьму и зафиксирую свои текущие знания в виде книги? Под рукой как раз была программа для составления mind mapов, в ней я начал накидывать приблизительное содержание про что и в каком порядке можно рассказать. Это был первый подход: крупные мазки, обширные планы.

Запала хватило на то, чтобы написать начало, а потом я стал перегорать. Не знаю, продвинулся бы я дальше, если бы не очередное удивительное совпадение. Спустя короткое время я поехал на конференцию VMware. Во время перерыва ко мне подошел представитель нишевого издательства: Вы Михаил Михеев? Очень приятно. Мне посоветовали обратиться к вам по поводу написания книги по теме виртуализации. Звезды сошлись: мысли о книге одновременно пришли в голову и мне, и издателю.

(Только сейчас понял, что забыл спросить у представителя издательства, кто указал ему именно на меня!)

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

Есть несколько воспоминаний из той поры:

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

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

• Знали бы вы, как я стеснялся выложить анонс у себя в блоге. Очень сильно нервничал :)

Анонс книги в блоге

Всего было три релиза: первый по 4-ой версии vSphere, второй по 4.1, а последний был посвящён уже 5-ой версии. Бумажные издания оформлены в разных цветах, чтобы читатели не путались.

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

В свое время я шутил: мол, я написал самую лучшую книгу по VMware на русском языке. Знаете, почему? Потому что единственную, других нет.

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

Один писатель-фантаст сказал: автор [в случае пиратства] теряет не столько деньги, сколько право распоряжаться плодом своего труда. В правовом поле автор может убрать свое произведение из конкретного магазина или вообще изъять из продажи. С условным торрентом это не так, это обидно. Вне зависимости от того, будешь ты что-то такое делать или нет.

Меня часто спрашивают, пишу ли я новую книгу. Короткий ответ нет. Чаще всего отшучиваюсь: мол, куда, у меня уже двое детей!

А если серьезно я и блог-то уже лет 7 не веду. Когда я был занят преподаванием, и блог, и книга были частью моей работы. В том числе, над собой. Моя текущая работа в VMware оставляет намного меньше времени на такие проекты. Честности ради в какой-то момент я предпринял еще одну попытку обновить книгу, но буквально через неделю понял: нет, не стоит этим заниматься. На предыдущем жизненном этапе у меня была четкая цель: что я хочу сделать, для кого и зачем. А книга ради книги это никому не интересно.

Сам собой назревает дискуссионный вопрос: вот я молодой, горящий специалист, есть ли мне смысл заявить о себе, написав книгу? [не суть важно, но, допустим, по решению VMware].

Выскажу свое мнение.

С одной стороны, сейчас у VMware есть продукты, по которым нет русскоязычных материалов. Так что смысл написать по ним книгу имеется, у специалистов она будет востребована. Но насколько велика будет аудитория? Вопрос открытый. К примеру, первый тираж моей книги составил порядка 5 тысяч экземпляров (за давностью могу ошибаться).

Это много или мало?

C другой стороны, старая добрая книга это уже немного олдскул. Есть блоги, есть YouTube. Есть Telegram-каналы, в конце концов. Может, лучше в эту сторону копнуть?

Готовогоответа у меня нет, но мне кажется, что классическая книга по-прежнему имеет смысл. Все-таки, когда ты говоришь: я Миша, автор [например] Telegram-канала такого-то или я автор такой-то книги, эффект получится разным.

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

Как я попал в VMware

Наступил 2011 год. К тому моменту я уже имел около 6 лет преподавательского стажа. Популярность VMware и, соответственно, номенклатура курсов росли. Бывало так, что в течение месяца я мог читать один и тот же курс двум-трем разным группам.

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

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

Помнится, сижу я в больнице. Жду приема врача. Раздается звонок с незнакомого номера: оказалось, звонит руководитель пресейлов VMware. Предлагает пообщаться. Я тогда ничего не понял какую именно работу мне предлагают, чем я буду заниматься... Но все равно согласился на встречу.

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

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

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

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

Кстати: еще в задачи пресейл-инженера входит обучение заказчиков и партнеров, а также выступления на различных мероприятиях. Например, в этом году наши пресейлы проводят цикл весенних вебинаров VMware 2021, которые будут идти до июня. На них можно не только послушать экспертов, но и пообщаться с ними в чатах и Q&A. Зарегистрироваться на вебинары можно на сайте, а посмотреть онлайн-мероприятия в записи на нашем YouTube-канале. А для энтузиастов у нас есть канал в Telegram: там мы напоминаем о старте вебинаров и делимся видео.

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

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

Немного об изоляции

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

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

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

Кто востребован в VMware

Наверное, я сейчас скажу не самую очевидную вещь. Нам не особо важно, является ли человек экспертом в продуктах VMware. Этому мы как раз можем научить на месте: и ресурсов, и учебных материалов, и опыта у нас достаточно. Любые ИТ-продукты это не квантовая физика. Получить нормальную или даже отличную экспертизу в них можно. Главное воспринимать это не как проблему, а как задачу. Попробовал получилось. Поотвечал на вопросы и сам не заметил, как освоил тему.

Гораздо сложнее научить человека soft-скиллам и такому навыку, как доведение дел до конца. Работы больше, чем времени в сутках, поэтому всегда есть соблазн что-то здесь поделать, там поковырять, но до конца не доводить. Льется нескончаемый поток задач, и ты думаешь: я буду что-то отдельное выхватывать. Это не очень хорошая история. Если уж взялся делай. Не берешься скажи. Не оставляй повисшим в воздухе.

Один из главных soft-скиллов уметь говорить на языке собеседника. Отличным примером является известный в хаброкругах Milfgard. Помните шикарную статью про недочеты в унаследованной архитектуре живых существ? Огонь же! И в том числе потому, что материал подан на языке читательской аудитории.

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

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

Немного о Хабре

Хабр для меня один из главных источников информации из разных сфер.

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

Просто просмотр заголовков статей в RSS-клиенте позволяет составить мнение о событиях мира ИТ в целом.

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

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

Ну и нельзя не сказать, что именно с его статьи Настольные игры: во что играют в IT-офисах? от далекого 2011 года началось мое нынешнее увлечение настольными играми, в котором я весьма глубоко погряз :)

---

Друзья! Если вам интересен такой формат, будем рады вашим пожеланиям. Поделитесь в комментариях, интервью с представителями каких сфер и профессий вам бы хотелось видеть на Хабре.

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

Провайдеры же в качестве подтверждения соответствия требованиям регуляции демонстрируют на своих ресурсах два вида документов: аттестат или оценку эффективности. Сегодня вместе с Алексеем Афанасьевым ( #CloudMTS, ИТ-ГРАД), Дмитрием Пойгиным и Игорем Яковлевым (ООО НАЦ) разберемся, в чем отличия и какой вариант предпочтительнее и беспроблемнее.

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

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

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

Специфика работы с ПДн в облаке

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

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

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

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

• В аттестате фиксируется точное соответствие тому или иному уровню защищенности (УЗ) и классу защиты (К) с учетом всех требований ГОСТ, а ОЭ может лишь обозначать данное соответствие.

• Если сервисы провайдера аттестованы, разграничение зон ответственности можно, как правило, провести более четко.

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

Когда без аттестата не обойтись

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

• Если клиент планирует размещать в облаке ГИС. Оценка эффективности здесь не подойдет при прохождении процедуры аттестации самой информационной системы сослаться на ОЭ будет проблематично.

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

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

Оценка эффективности vs. аттестат

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

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

Как выбрать между аттестованным решением и сервисом с оценкой эффективности и не пожалеть о своем решении в будущем? Сравним оба документа.

Оценка эффективности

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

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

Говоря грубо любая компания может выбрать набор критериев безопасности и провести внутреннюю оценку своих систем на предмет соответствия этим критериям. Будет ли ее результат иметь юридическую силу в глазах регулятора? Едва ли. Важно ли для конечного заказчика наличие у провайдера проведенных оценок эффективности? Давайте разберемся.

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

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

Ситуация чем-то похожа на старую-добрую сказку.

Владелец ИС спрашивает:

Свет мой, зеркальце, скажи: я ль на свете самый облачный и защищенный?

Его собственное отражение отвечает:

Ты, конечно, спору нет. Вот тебе оценка эффективности. Твои клиенты будут рады;)) Аттестатом здесь и не пахнет, но в целом все надежно и утечь ничего не должно. Ну, по идее...

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

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

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

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

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

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

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

Аттестат

Чем же отличается аттестат?

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

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

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

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

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

Подведем итоги:

Итак, что дает наличие аттестата клиенту:

• возможность сослаться на него при аттестации собственной ИСПДн и при подключении к ГИС;

• гарантию неизменности системы на период действия аттестата;

• отсутствие вопросов при проверке со стороны регулятора.

Изучаем аттестат

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

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

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

Важен и срок действия аттестата. Он может быть и ограниченным (обычно 3 года), и бессрочным. К примеру, при аттестации в рамках 17-го приказа ФСТЭК РФ (от 11.02.2013) аттестат действует в течение всего периода эксплуатации системы.

Облачный провайдер, как правило, является лицензиатом ФСТЭК и ФСБ. Соответственно, предлагая рынку аттестованные сервисные решения, провайдер не захочет рисковать ни своей репутацией, ни доверием со стороны регуляторов.

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

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

Современные облачные технологии позволяют любому пользователю получать безграничный доступ к огромным вычислительным мощностям из любой точки мира. Однако ключевой принцип этой концепции был разработан еще в конце 1950-х, за десятилетия до появления таких понятий, как кибербезопасность и облако. Его пионером была не крупная технологическая компания вроде IBM, а один амбициозный молодой ученый с испанскими корнями. Сейчас его принято именовать отцом компьютерного пароля. Но на этом заслуги Корбато не заканчиваются.

Очередь на вычисления

Еще в 1950-х годах прошлого века молодой ученый Фернандо Корби Корбато защитил докторскую степень по физике в Массачусетском Технологическом Институте. На правах доктора наук он был допущен к вычислениям на одном из самых мощных и перспективных компьютеров того времени Whirlwind. Через какое-то время, разобравшись с принципом работы компьютера, Корбато пришел в восторг: это устройство могло делать гораздо более интересные вещи, чем банальное решение физических задач одна за другой. Но времени на детальное изучение возможностей компьютера у физика не было. Дело в том, что компьютер делили между собой сразу несколько факультетов MIT. Никто не желал уступать законное время сомнительным проектам молодого доктора. В лучшем случае Корбато оставалось довольствоваться тридцатью минутами работы с компьютером в день притом в самые ранние утренние часы. Приходилось, скрепя сердце, вставать спозаранку и экспериментировать считаные минуты, пока не придут коллеги с серьезными лицами и расчетами.

Компьютер Whirlwind

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

Позднее Корбато вспоминал:

Это была настоящая борьба! Во мне видели не более чем худощавого профессора с галстуком-бабочкой. Ничего больше. В то время компьютеры не раздавали направо-налево всяким Томам, Дикам и, простите, Фернандо. А архитекторы и слышать не хотели ни о каких прорывных идеях с улицы. У каждого было собственное представление о том, что такое компьютер. И уж точно компьютер не та вещь, которую можно разделить с друзьями!.

Ранние годы и начало карьеры

Фернандо Хосе Корбато родился 1 июля 1926 года в Окленде, штат Калифорния. Его отец, Эрменегильдо Корбато, был мигрантом из Испании и в молодости работал учителем в римско-католической школе в Китае. Позже он переехал в США, чтобы поступить в аспирантуру калифорнийского университета в Беркли. Там он познакомился со своей будущей женой Шарлоттой Дженсен. С рождением сына Эрменегильдо Корбато устроился преподавателем испанской литературы в Калифорнийском университете в Лос-Анджелесе.

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

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

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

Оборудование было очень капризным и сложным вспоминал Фернандо. В среднем, компьютеры ломались каждые 20 минут.

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

Первая ОС с разделением времени

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

В 1961 году Корби вместе со своими коллегами (Бобом Дейли и Марджори Мервин-Даггет) в стенах MIT продемонстрировал первую версию операционной системы с разделением времени CTSS. Система была реализована на базе IBM 709. Пользователям предлагалось подключаться к машине с помощью модифицированных терминалов Flexowriter. Для сохранения программ, выполнение которых было приостановлено, использовались четыре ленточных накопителя.

В 1962-1963 гг. разработка CTSS продолжилась. На смену ламповому IBM 709 пришла новая машина IBM 7090. Компьютер был специально модифицирован IBM для работы в режиме разделения времени. Подключение к нему все так же реализовывалось через терминалы, установленные в офисах MIT и даже у некоторых сотрудников института дома.

Презентация CTSS

Кстати, с руководством по использованию CTSS от MIT Press до сих пор можно ознакомиться здесь.

CTSS стала той искрой, которая убедила MIT открыть Project MAC, предтечу Лаборатории компьютерных наук (LCS), которая позже станет Лабораторией компьютерных наук и искусственного интеллекта (CSAIL). На первом крупном мероприятии Project MAC Summer Study компьютерные специалисты из различных научно-исследовательских институтов, правительственных организаций и промышленности смогли лично познакомиться с CTSS. Этот практический опыт не только убедил участников в эффективности таймшеринга, но и позволил сформировать вокруг CTSS сообщество первых пользователей.

Стало ясно, что CTSS вышла за рамки экспериментального проекта. Осенью 1963 года лаборатория Project MAC благодаря финансированию ARPA приобрела собственный IBM 7094, и CTSS сделала ресурсы научной машины доступной участникам всех исследовательских проектов MIT.

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

В 1963-1964 гг. доктор Корбато и его команда начали работу над гораздо более амбициозным проектом. Новая операционная система получила название Multiplexed Information and Computing Service, или Multics. Для такого серьезного проекта требовалась соответствующая аппаратная поддержка, и Корбато принялся обивать пороги крупных технологических компаний. К своему удивлению он обнаружил, что IBM, бесспорный лидер на рынке компьютеростроения, совсем не заинтересована в тайм-шеринге. Пришлось обратиться к General Electric Co. В отличие от IBM, GE всячески угождала разработчикам программного обеспечения. Таким образом она пыталась получить конкурентное преимущество перед IBM, которая, по заявлению Корбато всеми силами заставляла клиентов покупать еще один новый компьютер вместо того, чтобы как-то модернизировать старый.

ОС Multics

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

Логотип Multics

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

Кроме того, именно в Multics была впервые реализована концепция dynamic linking (динамическое связывание) между исполняемой программой и библиотеками кода, хранящимися в памяти компьютера.

Всем заинтересованным рекомендуем посмотреть короткое видео, в котором объясняется работа виртуальной памяти в Multics:

Проект просуществовал вплоть до середины 1970-х годов. Коммерческого успеха ОС не снискала: сравнительно небольшой рынок, железная политика IBM в отношении собственных мейнфреймов и масса других факторов не позволили Multics обрести популярность.

Однако годы спустя доктор Корбато не раз говорил, что сама концепция Multics положительно повлияла на развитие компьютеров в целом. Именно Multics вдохновила исследователей из Bell Labs на создание UNIX и стала тренировочным полигоном для многих известных программистов Денниса Ричи, Кена Томпсона, Дэна Бриклина и Боба Френкстона.

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

Корбато о Multics:

В 1990 году Фернандо Хосе Корбато получил премию Тьюринга Ассоциации вычислительной техники за свою работу над компьютерными системами с разделением времени. Скончался 12 июля 2019 года на 94-ом году жизни.

Не будет преувеличением сказать, что работа Корби по разделению времени коренным образом повлияла на то, какими мы знаем компьютеры сегодня, говорит директор CSAIL Даниэла Рус. Цифровая революция уходит своими корнями в проекты, которые он возглавлял в МТИ почти 60 лет назад.

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

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

По статистике, 100% населения Марса роботы.

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

Сегодня мы немного сменим акценты и поговорим о вещах более приземленных. Какие технологии обеспечивают работу марсохода? Как задействованы в изучении космоса облачные компании? И в целом каковы планы человечества на марсианские земли в рамках амбициозной миссии.

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

Не так давно Amazon Web Services (AWS) рассказала, какую роль облачные вычисления играют в обработке данных, поступающих с Perseverance.

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

Представитель AWS Хайме Бейкер вручает царь-билет на мыс Канаверал победителю конкурса Name the Mars Rover 2020 Алексу Мэзеру и его семье. Фото: (НАСА / Обри Джеминьяни)

Напомним, в течение 2020 года в США проводился конкурс на самое удачное имя для новой марсианской миссии.

Изучить фотографии, сделанные аппаратом, можно на официальном сайте NASA.

В частности, в облаке AWS обрабатываются данные о перемещении Perseverance и том, как он справляется с рельефом. А все фотографии, поступающие с Марса, в необработанном виде отправляются в облако AWS и становятся доступны пользователям по всему миру. Благодаря облачным технологиям NASA удалось всего за несколько часов транслировать 150 ТБ медиаданных и справиться с обработкой до 80 000 запросов в секунду. Впечатляющие цифры, которые совершенно невозможно представить в рамках классической инфраструктуры.

Но трансляцией фотографий дело не ограничивается. Облачные мощности задействованы и для продвинутой системы поиска пути. За прошедшие дни Perseverance смог передать на землю информацию более чем о 200 миллионах точек поверхности Марса. По заявлению NASA, эти данные помогут скорректировать пути перемещения будущих марсоходов и увеличат их скорость на 40%.

Кадр из сериала Теория большого взрыва. Воловиц загнал марсоход в канаву.

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

Приблизительная программа миссии. Информация с сайта NASA.

После благополучной посадки 18 февраля марсоход пробудет на планете как минимум один марсианский год (порядка 687 земных дней).

В его задачи входит:

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

• собрать образцы грунта и камней, в которых могли сохраниться химические следы (биосигнатуры) древних живых организмов, если они вообще существовали;

• высверлить пробы в 30 перспективных точках планеты и законсервировать их на поверхности для дальнейшего изучения;

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

Здесь вы сможете посмотреть разнообразные видеоматериалы о миссии.

Микрофоны на Марсе

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

Но зачем на Марсоход повесили микрофон? Вряд ли ученым удастся подслушать разговоры зеленых человечков речь идет о поиске следов микроорганизмов. AWS объясняет это так:

Различные датчики марсохода собирают массу научных данных: состав атмосферы, скорость ветра и погода на Марсе. Микрофоны же записывают звуки планеты. Предполагается, что NASA обработает медиатеку, собранную Perseverance, и выложит её в открытый доступ. Это даст простым пользователям подключиться к изучению Марса наравне с учеными.

Выше местоположение марсохода на момент публикации статьи. Интерактивная карта доступна на сайте NASA.

Послушать аудиозаписи, сделанные во время миссии, можно здесь.

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

Космические вертолеты

Чуть выше мы сравнили медиа-возможности марсохода с функционалом смартфона. Разумеется, на практике все гораздо сложнее. Perseverance это сложная научная лаборатория весом в целую тонну. Кроме того, у марсохода есть крошечный (менее 2 кг) летающий дрон-компаньон Ingenuity.

Крошка-вертолет на базе открытого ПО и компонентов, находящихся в свободной продаже

Если всё пойдет по плану, Ingenuity станет первым вертолетом на Марсе. Но важно понимать: расстояние от Земли до Марса составляет 11 световых минут. Это очень много. Если марсоход еще может делать перерывы, чтобы дождаться новых управляющих команд, у летающего аппарата такой возможности нет. Добавьте сюда еще и более разреженную, чем на Земле, атмосферу, и пониженную гравитацию, и летательная миссия покажется и вовсе невыполнимой.

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

Ingenuity в реальном размере

Поскольку управлять Ingenuity вручную невозможно, инженеры NASA разработали для него специальную программу на базе Linux и своего фирменного фреймворка F (F prime). Главная задача проекта доказать, что комбинация современного стокового железа и программного обеспечения с открытым кодом может поднять летательный аппарат над поверхностью Марса.

Под капотом у дрона четырехъядерный ARM-процессор Qualcomm Snapdragon 801 на частоте 2,2 ГГц. К слову, это более мощный процессор, чем тот, что установлен на самом марсоходе. NASA важна в первую очередь не производительность, а стабильность: чипы, используемые в космических миссиях, должны соответствовать стандарту High-Performance Spaceflight Computing (HPSC). Разработка таких процессоров и их доскональное тестирование занимают годы. Так как подпроект Ingenuity менее важен, чем Perseverance, ученые решились использовать в нем стандартный земной CPU.

Подробнее о вертолете на сайте NASA.

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

В качестве ОС специалисты остановились на Linux. Здесь ничего удивительного: уже много лет космическое агентство использует в своих проектах модифицированные версии этой ОС. Так, на базе Linux работают компьютеры NASA на МКС.

Что касается фреймворка любой энтузиаст может бесплатно скачать и использовать его в домашнем проекте. Притом без необходимости закупать дорогое и редкое железо всё заточено под стандартные off-the-shelf компоненты.

F включает:

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

• Базовый фреймворк C++ с поддержкой основных возможностей, таких как очереди сообщений и потоки.

• Инструменты для определения компонентов и связей.

• Постоянно развивающийся набор готовых к использованию компонентов.

• Инструменты для тестирования летного программного обеспечения.

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

В заключение приведем несколько интересных ссылок от NASA и информационных агентств

• График мероприятий и прямые трансляции

• Свежие новости о миссии

• Загружаемые материалы о миссии

• Полная оптимизма статья о партнерстве между AWS и NASA

• Детализированный обзор марсохода

В мае 2015 года стало известно, что актер озвучивания мультсериала Симпсоны Гарри Ширер, чьим голосом говорят несколько ключевых персонажей, например, мистер Бернс и его ассистент Смитерс, покидает проект.

Причин тому сразу несколько. Во-первых, на тот момент сериал продолжался уже более 25 лет. Гонорары актеров все эти годы росли с 30 000 долларов за серию в 1998 году до 400 000 долларов с 2008 года. Однако такой расклад не устроил студию Fox: она пригрозила отменить подшефный сериал, если продюсеры не сократят оплату актеров хотя бы на 30%.

Нельзя просто так взять и уйти из Симпсонов

Почти все согласились с таким положением дел и продолжили работу. Однако Гарри Ширер, ранее уже критиковавший качество новых серий, отказался продлевать контракт. Двадцать лет в этой золотой клетке практически не оставляли ему свободного времени на собственные проекты. По словам шоураннера Эла Джина, на место Ширера планировалось нанять других актеров. На минуточку: рекасту могли подвергнуться в том числе директор Скиннер, Нед Фландерс и Отто Манн.

Но нельзя просто так взять и уйти из Симпсонов. Несколько месяцев спустя Ширер уступил студии и подписал новый контракт. Сериал и без того периодически ломает четвертую стену, а с экрана летят гэги о замене голосов озвучки. Но шутки шутками, а Симпсонам уже 32 года. Срок немалый, большая часть актеров уже перешагнула рубеж пенсионного возраста: большинству из них уже минуло 60, а то и 70 лет. Самому Ширеру уже 77. Есть вероятность, что в ближайшие годы он окончательно покинет проект уже по состоянию здоровья. То же самое может произойти и с другими голосами героев. Деньгами их не удержать: благодаря отчислениям за трансляции старых серий и озвучивание новых каждый из них сколотил состояние в десятки миллионов долларов.

Но может статься, что необходимость в содержании большого числа живых актеров вскоре отпадет сама собой. Не так давно персонаж Эдна Крабаппл (учительница Барта, была выведена из шоу после кончины актрисы Марсии Уоллес в 2013 году), снова появилась в сериале, на сей раз, чтобы окончательно проститься со зрителями. Для озвучки персонажа были использованы реплики, записанные при создании прошлых эпизодов.

Заменят ли актеров дипфейки

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

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

Безусловно создать эпизод Симпсонов, правдоподобно озвученный при помощи ИИ, возможно говорит Тим МакСмитурс, исследователь ИИ и медиа-продюсер, построивший речевую модель, которую можно обучить имитировать любой голос. Но будет ли интересно его смотреть это уже другой вопрос.

На своем YouTube-канале, Speaking of AI, МакСмитурс переделал культовую сцену из фильма Ноттинг-Хилл: в роли героини Джулии Робертс выступает Гомер.

В другом видео на канале МакСмитурса голосом Дональда Трампа говорит глуповатый Ральф Виггам.

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

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

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

Всё зависит от набора обучающих данных говорит МакСмитурс. Если в модель не заложен широкий спектр эмоций, она не сможет их произвести из ничего. Так что искусственный Гомер звучит гораздо менее энергично, чем настоящий.

Эмоции для дипфейков

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

Мы знаем, в чем заключается разница между сарказмом и искренним участием, умеем обрабатывать крошечные нюансы звука говорит Джон Флинн, соучредитель и технический директор Sonantic. Мы научились качественно считывать и масштабировать естественные особенности и акценты живой речи. По словам Флинна, количество данных, необходимых для обучения, удалось сократить с 30-50 часов до 10-20 минут на человека.

Видео от Sonantic с демонстрацией возможностей технологии искусственного интеллекта по имитации человеческих эмоций:

Компании Replica Studios из Брисбена удалось построить модель для воссоздания голоса, которую можно обучить на 20 записях конкретных предложений. Чем больше исходных данных, тем качественнее результат. Но кое-что интересное можно сделать и за пару-тройку минут говорит Шреяс Нивас, соучредитель и генеральный директор Replica.

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

Распространенная панграмма для английского языка выглядит следующим образом: The beige hue on the waters of the loch impressed all, including the French queen, before she heard that symphony again, just as young Arthur wanted.

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

Технология генерации голоса из текста кое-где уже применяется. Хороший пример видеоигры. Sonantic сотрудничает с компанией Obsidian, создателем некоторых игр серии Fallout и The Outer Worlds, а к услугам Replica прибегают и AAA-студии, и инди-разработчики. В частности, синтезированные фоновые диалоги позволяют наполнить открытый игровой мир гораздо большим количеством контента и сделать его живее. Подобный объем живых записей с участием актеров озвучивания стоил бы непомерно дорого и замедлил бы процесс производства игры.

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

В спортивных играх ИИ-голоса часто отдаются комментаторам (например, такой подход используется в FIFA для живого комментирования матчей). Существует также модификация для Cyberpunk 2077, которая позволяет изменить имя главного героя и заставить ключевых персонажей, которые обращаются к игроку, произносить его.

Так что там с Симпсонами?

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

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

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

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

Например, создатель Family Guy (Гриффины) Сет МакФарлейн озвучил и Брайана, и Стьюи. Притом своим естественным голосом он говорит от имени пса. Голос младенца Стьюи же был придуман им специально для этого образа. Так что технически прав на Брайана у актера несколько больше. Тем не менее, поскольку МакФарлейн также является создателем сериала, очень сомнительно, что его голос кто-то может заменить на искусственный без согласия автора.

Еще один сходный прецедент имел место в 1993 году. Два актера из сериала Cheers, Джордж Вендт и Джон Ратценбергер, подали в суд на Paramount за использование своих образов в качестве промо в барах аэропортов. Актеры утверждали, что право на публичность дает им контроль над собственным имиджем, Студия же утверждала, что закон об авторском праве позволяет создавать и эксплуатировать производные работы на основе ситкома. Дело рассматривалось в суде восемь лет, и студия в конечном итоге согласилась выплатить актерам гонорар за несанкционированную рекламу. Сумма не раскрывается.

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

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

МакСмитурс также проводит параллели с компьютерной графикой. По его словам, уже на данный момент возможно снять и озвучить эпизод Симпсонов без участия актеров озвучивания. Это будет долго, сложно, понадобится не одна сотня дублей. Тем не менее, вряд ли полученный результат выдержит испытание временем. Компьютерная графика начала 1990-х кажется современному зрителю неубедительной, устаревшей. То же самое произойдет с голосами. Тем не менее, можно использовать эту технологию во благо: например, для создания коротких фрагментов, призванных ненадолго вернуть умершего актера, чтобы он мог попрощаться со зрителем.

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

Мы встречаемся с ними всюду: на водосточных трубах жилых массивов и поручнях метро. В рекламных роликах крупных брендов и сервисах регистрации. Даже в видеоигре Alan Wake QR-коды, простите за каламбур, засветились в качестве пасхалок с дополнительным контентом.

Чуть ли не ежегодно возникают убийцы QR-кодов, а им самим предрекают скорую гибель. Но уже не одно десятилетие люди продолжают пользоваться этими черно-белыми квадратиками. Зачем? Почему? Кто их придумал? Попробуем разобраться под катом.

Япония издавна славится разного рода изобретениями, призванными сделать бизнес-процессы и производственные задачи как можно более компактными и эффективными. В начале 1990-х годов перед инженерами крупной машиностроительной компании Denso стояла нетривиальная задача: создать унифицированный штрих-код (или нечто подобное) для маркировки деталей и компонентного сканирования. На тот момент внутри компании были приняты более 10 кодов разного назначения, и сотрудники завода жаловались на то, что работа с кодами требует большой концентрации, а сами коды содержат чрезвычайно мало полезной информации.

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

Китайские шашки и японская смекалка

Масахиро Хара, сотрудник отдела разработки Denso Wave, в 1992 году взялся за решение этой задачи. Новые коды должны были отвечать следующим требованиям:

• объем информации, которую возможно хранить в коде, должен существенно возрасти;

• процесс считывания должен быть как можно более точным и быстрым;

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

• считывающее устройство должно быть простым и дешевым.

По легенде, вдохновение пришло к Масахиро за обедом, во время игры в го. Что ж, очень похоже на правду: QR-код действительно напоминает доску для игры с расставленными на ней камушками, а игровая ситуация это те же закодированные данные.

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

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

К 1994 году новый формат кода (Quick Response Code) был повсеместно внедрен на заводах производственной цепочки автоконцерна Toyota, но быстро перетек из цехов в другие бизнес-сферы. Масахиро Хара вспоминает, что вплоть до презентации нового формата кода он не был уверен, что его детище приживется в компании. Да, скорость считывания данных и надежность формата не вызывали сомнений, однако 2D-сканеры могли стать серьезным препятствием на пути внедрения технологии. Тем не менее код был воспринят и главами, и рядовыми сотрудниками корпорации очень тепло. В течение следующего месяца удалось успешно внедрить его в собственную Kanban-программу Toyota.

Не секрет, что японцы любят свои изобретения и не выпустят любимую игрушку из рук, пока не появится её более технологичный наследник. То же произошло с QR-кодами: с 2002-2003 года их стали применять в ресторанах для маркировки контейнеров, в делопроизводстве. Известны также случаи применения QR-кодов в школах, музеях и на кладбищах.

QR-коды захватывают мир

Простота и удобство кода понравились людям и за пределами Японии. К середине-концу 2000-х годов о японском изобретении узнал весь мир. При этом фраза-обозначение QR code является зарегистрированным товарным знаком, принадлежащим компании-изобретателю, однако использование самих кодов не облагается отчислениями.

Говорить о версиях QR-кодов можно достаточно долго: существуют и маленькие версии (21х21px), и более крупные 177х177px. Вот основные принятые во всем мире кодировки данных:

• цифровая кодировка, до 7089 цифр;

• алфавитно-цифровая кодировка, до 4296 символов (или до 2953 символов с поддержкой кириллицы);

• байтовая кодировка, до 2953 байт;

• кодировка кандзи, до 1817 иероглифов.

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

Опустим технические моменты, лежащие в основе принципа QR-кода: этой информации и на Хабре, и за его пределами предостаточно. Гораздо интереснее сконцентрироваться на том, как эти коды используются вне рамок бизнес-задач.

Примечание: QR-коды ниже представлены исключительно для демонстрации технологии. Автор статьи не несет ответственности за их содержание сканируйте на свой страх и риск :)

Двумерный креатив

Игра с цветом

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

Игра с формой

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

Особняком здесь стоят дизайнерские варианты QR-кодов: это не просто вписывание квадратика с изображением в поле кода, это целое произведение искусства. Ну, почти искусства.

Коды с нестандартной ориентацией в пространстве также не новы.

Кроме того, периодически можно встретить анимированые QR-коды, однако это, скорее, модная диковинка, нежели оправданное использование технологии.

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

Игры с применением

Открытки, футболки, бижутерия с памятными шифровками даже сюда добрались QR-коды.

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

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

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

Сомнительное решение наручные часы, которые показывают время в зашифрованном варианте.

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

Японская виза здесь без комментариев. :)

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

Татуировки опять же, без комментариев. Главное, чтобы мастер ничего не напутал. Агент 47 шлет пламенный привет.

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

Проект бизнес-центра в ОАЭ

Киса и Ося были тут: QR-коды используются также в так называемой психогеографии. Люди записывают свои мысли, ассоциации и воспоминания, связанные с разными местами, и распространяют их в виде QR-кодов.

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

Игры с содержанием

Пароли от гостиничного Wi-Fi, географические координаты, ссылки на меню это весьма традиционные варианты использования кода. Как насчет чего-то более интересного?

Сервис QRInfoPoint предлагает достаточно забавное решение для передачи музыки, фото или видео через QR-код. Задумка проста и элегантна: разумеется, вместить целый аудио-файл в код не получится, однако вполне возможно залить его на сервер (или воспользоваться уже существующей ссылкой, например, на YouTube), а в код интегрировать адрес html-странички с соответствующим тегом и атрибутом src, по которому будет загружена и проиграна композиция.

Симпатичные QR-коды использует Nintendo в играх серии Pokemon (и некоторых других) для передачи информации, обмена покемонами и многого другого.

Совершенно сумасшедший, но работающий QR-код. Опять же, в стилистике Nintendo.

Попытка зашифровать в QR-коде целую игру:

Убийцы и прочие родственники QR-кода

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

Приложение PhonoPaper позволяет зашифровать аудио до 10 секунд в изображении или произвести расшифровку.

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

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

Clickable paper проект, нацеленный на получение дополнительной информации из печатных материалов.

Убийца QR-кодов SnapTag обведи логотип кружком, и дело в шляпе.

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

Какая ежедневно используемая ИТ-система удалена от нас дальше всех? Марсоход Perseverance. Пожалуй, дальше пока что некуда. Под катом поговорим о технической начинке миссии, особенностях связи с Землей и других насущных проблемах и задачах, которые стоят перед марсоходом Perseverance и его маленьким крылатым другом Ingenuity.

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

Марсоход Perseverance взаимодействует с окружающим миром в реальном времени, но время прохождения сигнала с Марса в ЦУП NASA составляет порядка 12 минут. Но задержки это лишь полбеды. Само качество связи на таком расстоянии оставляет желать лучшего. Соответственно, единственный выход возложить принятие некоторых решений на сам Perseverance.

При этом технологически марсоход весьма скромен: его бортовые системы работают на базе процессора PowerPC 750, точно таком же, что и в компьютере Apple Bondi Blue iMac 1998 года.

Напомним, на Марсе уже имеется развернутая ранее база марсоход Curiosity. Он приземлился на поверхность планеты еще в 2012 году. К слову, работает он все на том же процессоре: в силу ряда особенностей марсианской среды это едва ли не самый подходящий вариант.

А знаменитый дрон-коптер Ingenuity, судьба которого вызывала у ученых наибольшие опасения, оснащен уже гораздо более современным железом: так, его сердцем является процессор Snapdragon 801, применявшийся в смартфонах ~2014 года, например, в Sony Xperia Z3.

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

Все эти процедуры (вход в атмосферу, снижение и посадка) были полностью автономны. Марсоход вошел в атмосферу Марса на скорости 20112.5 километров в час, а максимальная температура на поверхности теплового экрана составила 1300C. Спуск занял меньше 7 минут, поэтому инженеры NASA никак не могли вмешаться в процесс и внести корректировки. Строго говоря, информация о начале посадки долетела до Земли уже после того, как марсоход успешно приземлился.

Вход в атмосферу

Perseverance это уже пятый марсоход NASA. Но первый, который пошел на посадку самостоятельно.

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

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

Таким образом, все будущие миссии на Марс будут комплектоваться щитами и иным оборудованием, построенным на основе данных о реальной посадке, а не моделируемой. Специалисты NASA предполагают, что в ближайшем будущем им удастся создать более эффективные и более легкие (на 35%) тепловые экраны.

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

Что касается компактности приземления Perseverance был нацелен на область 7,72 х 6,6 км. Это на порядок меньше, чем посадочная цель Curiosity (24,94 x 19,96 км). Благодаря данным, полученным в феврале, следующему зонду достаточно будет еще более скромного участка поверхности для приземления.

Контролируемый спуск

Когда парашют раскрылся, радар Perseverance измерил текущую высоту. Без теплозащитного экрана камеры марсохода смогли просканировать землю на предмет ровной площадки для приземления.

Когда скорость падения упала до ~320 км/ч, парашют отстегнулся и включились посадочные двигатели. На этом этапе в дело вступила система обзора (LVS) и при помощи подсистемы относительной навигации по местности (TRN), сопоставившей изображение с камер и карту Марса, направила Perseverance на плавную посадку в кратер Езеро.

К слову, перед боевым запуском систему многократно тестировали на земле с помощью вертолетов и суборбитальных ракет, но, разумеется, на результаты этих тестов нельзя было полагаться на 100%.

Незадолго до посадки руководитель разработки системы TRN Свати Мохан говорила: Без системы относительной навигации вероятность благополучной посадки в кратере Езеро составляла от 80 до 85 процентов. Но теперь мы можем довести вероятность успешной посадки в кратере Езеро до 99 процентов в каждой последующей миссии.

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

Научная миссия

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

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

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

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

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

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

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

Звонок из космоса

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

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

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

Данные передаются в пакетах, определенных стандартом телеметрии Международного Консультативного Комитета по космическим системам передачи данных (CCSDS). Каждый пакет содержит переменный объем данных от 7 до 65 542 байта, включая заголовок. Исправление ошибок также в наличии.

Мозг марсохода

Марсоход управляется чипом, разменявшим третий десяток лет: Power PC 750.

Это не самый современный процессор: в нем содержится 10.4 млн транзисторов, что примерно в тысячу раз меньше, чем у чипов современных смартфонов. При этом, несмотря на то что CPU может работать 233 МГц, в Perseverance частота понижена до 133 МГц.

У инженеров есть основания использовать такие старые технологии. Во-первых, на борту марсохода стоит не стоковый CPU, а особая его версия стоимостью $20000. Процессор встроен в одноплатный компьютер RAD750 по лицензии BAE Systems, оснащенный резервирующими модулями и логикой устранения ошибок в памяти, а также средствами защиты от радиации: всего одного луча достаточно, чтобы вся начинка выгорела в одночасье.

Джеймс ЛаРоса, BAE Systems: Итак, у вас есть космический корабль ценой в несколько миллиардов. И если что-то в нем икнется, то миссия будет провалена. Всего одна частица, бороздящая галактики, может пролететь через устройство и нанести ему вред.

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

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

Ящик с инструментами

Марсоход несет на борту следующее оборудование:

• Mastcam-Z панорамная стереоскопическая камера с функцией масштабирования, которая может помочь в навигации и изучении минералов.

• SuperCam прибор для химического анализа и анализа минералов на расстоянии.

• PIXL (Planetary Instrument for X-ray Lithochemistry) рентгеновский флуоресцентный спектрометр, который распознает элементный состав марсианской почвы.

• SHERLOC (Scanning Habitable Environments with Raman & Luminescence for Organics and Chemicals) первый рамановский спектрометр на Марсе, использует ультрафиолетовый лазер для анализа минералогических и органических соединений.

• MOXIE (Mars Oxygen In-situ Resource Utilization Experiment) комплект для проведения эксперимента по получению кислорода из углекислого газа в атмосфере Марса. Кислород понадобится будущим космонавтам для дыхания и сжигания ракетного топлива, которое доставит их домой.

• MEDA (Mars Environmental Dynamics Analyzer) датчики, измеряющие температуру, скорость и направление ветра, давление, относительную влажность, а также размер и форму частиц пыли.

• RIMFAX (Радиолокационный формирователь изображения недр Марса) георадар для изучения местной геологии.

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

• Три антенны, работающие в UHF (до 2 Мбит/с) и X-диапазоне.

• Блок питания мощностью 110 Вт в виде MMRTG (многоцелевой радиоизотопный термоэлектрический генератор).

Марсианская миссия 2020, без сомнения, является беспрецедентным прорывом в области изучения Марса. К счастью, пока что нет повода беспокоиться о судьбе марсохода: свои текущие задачи он выполняет и перевыполняет. Даже экспериментальный дрон Ingenuity, построенный на базе магазинных компонентов и открытого ПО, ведет себя в точности так, как было запланировано на Земле. Периодически мы будем держать вас в курсе событий миссии Perseverance, а пока что, если вам интересна эта тема, предлагаем вам ознакомиться с предыдущим, более детализированным материалом по этой теме.

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

В облаках ИТ-ГРАД и #CloudMTS мы развернули сразу три сервиса резервного копирования: на базе Veeam, Acronis Infoprotect и Commvault. С их помощью можно собрать решение под любую задачу. Под катом поговорим о причинах появления такого разнообразия и разберем, какие задачи пользователь может решать с помощью того или иного сервиса.

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

Veeam

Veeam стал первым внедренным нами сервисом резервного копирования данных в рамках IaaS. Сейчас порядка 70% наших клиентов пользуются именно им. С его помощью можно бэкапить как инфраструктуру в облаке, так и локальные площадки.

Резервное копирование IaaS

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

• ежедневная инкрементная резервная копия;

• еженедельная полная копия;

• срок хранения 14 дней.

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

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

Если базового бэкапа мало, можно перейти на Veeam Self-Service и управлять всеми задачами резервного копирования и восстановлением через веб-портал самообслуживания, интегрированный с vCloud Director

Через портал Self-Service можно настраивать:

• наименования заданий, количество точек восстановления и глубину хранения;

• график запуска заданий, количество попыток выполнения и время между попытками, окно для резервного копирования;

• ВМ/vApp, которые нужно бэкапить в рамках конкретного задания;

• папки и файлы, который нужно включить или исключить из заданий;

• уведомленияи многое другое.

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

Резервное копирование с площадки клиента

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

1. C помощью Veeam Cloud Connect Backup, если у клиента уже есть сервер Veeam Backup & Replication не ниже версии Enterprise в рамках собственной инфраструктуры.

   VCC позволяет бекапить:

   • физические серверы с ОС Windows и Linux;

   • виртуальные машины на базе VMware и Hyper-V;

   • рабочие станции на Windows и Linux.

2. С помощью Veeam Agent, если сервер Veeam B&R отсутствует. Агенты также позволяют бэкапить физические сервера, ВМ и клиентские машины, но только с Windows.

Дополнительные фичи

Если на стороне клиента есть Veeam B&R, можно реализовать DR-сценарии. Veeam Cloud Connect Replication позволяет быстро переключаться как на уровне отдельных виртуальных машинам, так на уровне всей площадки. После активации реплик в облаке запустятся копии ВМ, соответствующие по состоянию последним репликам.

Для кого подходит: Veeam Enterprise Manager позволяет закрыть сразу множество типовых клиентских задач: полноценная интеграция сервиса резервного копирования с облаком, копирование с площадки клиента в облачный репозиторий, DR и т.п. Это весьма практичное и универсальное решение, которое подходит подавляющему большинству заказчиков.

Тем не менее, Veeam не позволяет осуществлять кроссплатформенную миграцию и в рамках агентского бэкапа ОС поддерживает только Microsoft Windows.

Acronis Infoprotect

При всей своей гибкости и универсальности решение Veeam подходит не всем заказчикам. Если в крупном и среднем сегменте его использование оказывалось выгодным, то небольшим компаниям требовалась альтернатива с хорошим соотношением цена/качество. Мы проанализировали запросы таких клиентов и добавили в свой пул решение Acronis Infoprotect.

По возможностям копирования БД и приложений продукт Acronis близок к описанному выше Veeam. Однако Acronis Infoprotect:

• дешевле;

• без агента бэкапит ВМ множества платформ (VMware, Hyper-V, Virtuozzo, KVM, RHEV, Citrix XenServer, Nutanix AHV, Oracle VM при наличии доступа к гипервизору);

• в рамках агентского бэкапа работает не только с Windows, но и с Linux и macOS;

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

• поддерживает кроссплатформенную миграцию.

Для кого подходит: Acronis Infoprotect закрывает практически все задачи малого и среднего бизнеса. Заказчики могут без проблем бэкапить данные с собственных площадок в облако, даже если в компании нет выделенного специалиста под эти задачи с веб-интерфейсом Acronis Infoprotect легко подружиться, имея минимум технический знаний.

Кроссплатформенная миграция

Очень часто клиенты после некоторого времени использования нашего облака в качестве площадки для хранения данных переносили к нам свою инфраструктуру. На такой случай в арсенале Acronis имеется одна полезная функция Universal Restore. С ее помощью можно переводить физические серверы в облачные или мигрировать между разными гипервизорами. Для миграции заказчику достаточно сделать резервную копию и восстановиться в облаке.

Commvault

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

Commvault позволяет восстанавливать любые элементы инфраструктуры (от отдельных файлов до платформ и ИС), реализовать DR-сценарии, мигрировать между платформами.

Отдельно стоит рассказать о том, с чем умеет работать Commvault:

• базы данных: Oracle, Microsoft SQL, MySQL, IBM DB2, MongoDB, PostgreSQL, Cassandra, DB2, Documentum, Hadoop, Informix, SAP for HANA, SAP MaxDB, SAP for Oracle, SQL Server, Sybase.

• ОС (в рамках агентского бэкапа): Windows, Linux, Mac, Unix, FreeBSD, Solaris, NetWare;

• платформы: VMware, Hyper-V, Azure Stack, OpenStack-KVM, Citrix XenServer, Huawei FusionCompute, Nutanix AHV, Oracle, Red Hat Virtualization;

• приложения: Microsoft: Exchange, Active Directory, SharePoint, Office 365, Skype for Business; Lotus: Notes Database/Document, Domino; SAP; EMC Documentum, Cloud Apps.

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

Для кого подходит: Enterprise-продукт, в арсенале которого найдется всё для решения бизнес-задач крупных компаний.

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

Итог

В рамках собственного BaaS-пула мы постарались собрать инструменты, которым под силу решить практически любую задачу вне зависимости от масштаба компании.

Стартапам и малому бизнесу, в котором вопрос хранения резервных копий практически не стоит, подойдет базовый пакет на основе решения Veeam.

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

Если у компании уже есть сервер Veeam Backup and Replication резервные копии для большей надежности могут дополнительно храниться в облаке провайдера. Либо они полностью перенесены в облачный репозиторий для минимизации трат на закупку оборудования для локального хранения бэкапов.

Полнофункциональный продукт на основе Veeam Enterprise Manager подойдет среднему и крупному бизнесу с серьезными бэкап-запросами, уже перенесшего инфраструктуру в облако провайдера.

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

Нередко наши клиенты, уже использующие облака для работы с персональными данными, задаются вопросом: а подходят ли облачные сервисы для бэкапов ПДн? Сегодня мы на собственном опыте покажем, какие требования к резервному копированию ПДн и данных ГИС предъявляют регуляторы, как их выполняет сервис-провайдер в облаке и как мы решаем насущные задачи клиентов по обеспечению доступности персональных данных при использовании распределенной инфраструктуры.

Требования со стороны регуляторов

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

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

Если как следует ознакомиться с основным регулирующим законом, 152-ФЗ О персональных данных, а именно со ст. 19, можно увидеть следующее:

Статья 19. Меры по обеспечению безопасности персональных данных при их обработке

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

2. Обеспечение безопасности персональных данных достигается, в частности:

7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;

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

Вывод 1, очевидный. Бэкапы не являются задачей на усмотрение оператора ПДн, а, согласно требованиям 152-ФЗ, лежат в его зоне ответственности: резервное копирование ПДн его прямая обязанность.

Строя свою ИС, работающую с ПДн и ГИС, важно учитывать требования приказов ФСТЭК 17 и 21, которые относят средства резервного копирования к средствам защиты информации.

Приказ ФСТЭК 17:

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

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

Приказ ФСТЭК 21:

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

ОДТ.4 Периодическое резервное копирование персональных данных на резервные машинные носители персональных данных

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

Вывод 2. Клиент, работая с ПДн в облаке, обязан решить вопрос доступности информации и, как следствие, регулярно выполнять резервное копирование.

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

• Приказ ФСБ 416, ФСТЭК 489 от 31.08.2010

• Постановление Правительства от 18.05.2009 424

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

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

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

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

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

Как решаются вопросы бэкапа со стороны провайдера

Наше облако аттестовано по требованиям УЗ-1 и К1, соответственно, в нем уже решены два типа задач:

• резервное копирование непосредственно облачной инфраструктуры и обеспечение высокой доступности данных;

• предоставление бэкап-сервисов пользователям этого облака.

В части обеспечения доступности информации (ОДТ) мы как провайдер решаем следующие задачи:

• Периодическое резервное копирование конфигурации компонентов инфраструктуры защищенного сегмента на резервные носители информации (ОДТ.4).

• Обеспечение возможности восстановления конфигурации компонентов инфраструктуры защищенного сегмента облака с резервных носителей (т.е. из резервных копий) в течение установленного временного интервала (ОДТ.5).

В части защиты среды виртуализации (ЗСВ):

Резервное копирование данных, резервирование технических средств, программного обеспечения виртуальной инфраструктуры, а также каналов связи внутри виртуальной инфраструктуры защищенного сегмента облака (ЗСВ.8).

Технически эти требования по резервному копированию облачной инфраструктуры реализуются на базе продуктов Veeam. Они хорошо зарекомендовали себя в системах виртуализации. Но это не единственная причина, почему для сегмента 152-ФЗ мы выбрали именно это решение:

• Veeam Backup & Replication имеет сертифицированную версию с классификацией по 4-му уровню отсутствие декларированных возможностей;

• благодаря наличию сертификата с ним легко проходить аттестацию.

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

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

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

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

Бэкап персональных данных с собственной локальной площадки в облако

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

Рассмотрим каждый из этих вопросов подробнее на практике.

1. Как выполнить безопасный обмен данными между площадкой клиента и облаком?

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

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

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

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

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

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

3. Реализация отказоустойчивой архитектуры решения

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

Своим клиентам мы предлагаем решение на базе продуктов С-Терра. Этот инструмент решает все задачи организации высоконадежной и защищенной связности двух площадок для передачи бэкапов ПДн. В линейке продуктов С-Терра имеются различные варианты программно-аппаратных и виртуальных криптошлюзов. Благодаря широкой линейке можно подобрать оптимальное решение как по производительности, так и по и отказоустойчивости. Производительность шлюзов С-Терра в зависимости от модификации варьируется от 100 Мбит/c до 10 Гбит/с, поэтому и клиент, и мы как провайдер всегда сможем подобрать наиболее оптимальное для своих задач решение.

Варианты подключения локальной площадки клиента к BaaS-сервису

Обмен данными между площадками может быть организован двумя способами.

1. Veeam Cloud Connect Backup

   Схема используется в том случае, когда у клиента есть сервер Veeam Backup & Replication. Он выполняет резервное копирование объектов со своей площадки, а облако используется как репозиторий. Связь организуется между самим Veeam Backup & Replication и репозиторием через описанный выше защищенный канал связи.

   

2. С использованием агентов

   В случае, когда у клиента отсутствует сервер Veeam Backup & Replication на своей площадке, вместо него для резервного копирования используются агенты на серверах и ВМ. Управление осуществляется через Veeam Service Provider Console.

   

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

• Восстановление в облако провайдера

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

• Миграция инфраструктуры

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

Этим материалом мы начинаем цикл статей о решении VMware SD-WAN. Сегодня поговорим о том, какие рыночные предпосылки сформировали его появление, какие задачи решает SD-WAN и каковы технические особенности решения VMware.

Появление SD-WAN

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

Чуть позже компании, наконец, распробовали облачные технологии. Бизнес стал размещать свои приложения в облаках, а доступ к ним организовывать через интернет, без использования выделенных каналов. Требования к пропускной полосе и скорости обмена информацией постоянно росли. Если со старыми корпоративными приложениями, не относящимися к медиа или ПО реального времени, традиционный подход еще работал, то по мере появления видеохостингов и сервисов видеосвязи, взрывной рост популярности которых пришелся на начало 2010-х, стало очевидно: нужно что-то менять.

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

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

Иными словами, те, кто отвечают за канал связи, не отвечают за приложения, и наоборот. Заказчик оказывается между Сциллой и Харибдой.

Решения SD-WAN долгое время оставались уделом стартапов. В стадию зрелости технология перешла всего несколько лет назад, когда крупные компании начали активно приобретать специализированные проекты. VMware выкупила стартап Velocloud, который делил первое место на рынке с аналогичным проектом Viptela, примерно в то же время купленным Cisco. Еще пару лет заняла консолидация: одни стартапы разорялись не всем удавалось сохранить нужные темпы роста и найти свое место на рынке, наиболее перспективные и успешные переходили под крыло крупных вендоров.

Чтобы нарастить конкурентные преимущества, каждой компании пришлось найти собственную уникальную нишу. Решение Velocloud создавалось для того, чтобы бизнес мог получать надежный и качественный доступ к приложениям независимо от того, где они находятся: в локальном дата-центре или в облаке, доступ в которое осуществляется через интернет. Спойлер: реализовать это удалось благодаря архитектурному компоненту решения SD-WAN Cloud Gateways. Идея состоит в том, что облачные технологии можно использовать и в мире сетевых подключений.

Как работает SD-WAN

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

Этот неудобный подход просуществовал вплоть до появления SDN. Технология программно-определяемых сетей позволила централизовать control plane и management plane, что дало существенный выигрыш в плане управляемости и масштабируемости сети. Стало возможным без труда управлять распределенной сетью из сотен и даже тысяч устройств, выросла скорость внесения изменений, а также появилась возможность более интеллектуальной обработки потоков данных.

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

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

Далее мы подробно рассмотрим все компоненты VMware SD-WAN и поговорим о каждом из них отдельно.

Компоненты решения

VMware SD-WAN Orchestrator

SD-WAN Orchestrator это облачный портал управления, мониторинга и диагностики сети. С его помощью можно буквально в один клик запустить виртуальные сетевые службы в филиале, облаке или в корпоративном ЦОДе. Фактически, это веб-портал управления сетью SD-WAN, который можно получить как SaaS или развернуть в локальном ЦОД.

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

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

• Zero-Touch Provisioning (ZTP). Активация оконечного устройства в филиале не требует выезда отдельного специалиста на площадку. Весь процесс укладывается в несколько простых шагов. Сотрудник в удаленном офисе подключает к устройству все кабели и включает его. Через интерфейс оркестратора создается новый Edge и высылается email со ссылкой для активации. Там зашиты нужные параметры для настройки WAN-интерфейса оборудования. Сотрудник в филиале, подключившись через провод или WiFi с планшета, переходит по этой ссылке, а устройство получает автоматически связность с оркестратором, вне зависимости от типа подключения к интернету.

• Диагностика сети. В панели управления можно посмотреть состояние протоколов маршрутизации, портов, таблиц ARP и NAT, запустить Ping или Traceroute и многое другое без необходимости подключения к устройствам через CLI/SSH.

• Журнал событий. Изменения и уведомления со всех устройств доступны для поиска и просмотра на SD-WAN Orchestrator.

• Автоматизация через API. SD-WAN Orchestrator предоставляет REST API, примеры использования можно посмотреть на SD-WAN Dev Center.

Посмотрим, как это выглядит.

SD-WAN Dashboard общий вид на всю сеть:

Список филиалов и их расположение на карте:

Статистика по приложениям и клиентам:

Информация о качестве каналов Quality of Experience:

Детальные характеристики каналов:

VMware SD-WAN Gateway

SD-WAN Gateways это сетевые шлюзы, развернутые в высоконадежных ЦОД по всему миру. В первую очередь, они выполняют функцию Control Plane, но в зависимости от задачи могут брать на себя сразу обе плоскости и control plane, и data plane. Эти шлюзы позволяют соединить между собой разрозненные офисы и обеспечивают оптимальный путь от филиала к данным и приложениям в ЦОД и облаках. Потребность в установке мощных концентраторов или устройств координации непосредственно в филиалах отпадает.

На уровне Control Plane обеспечивается и обмен маршрутной информацией между филиалами, так как Gateway выполняет роль рефлектора маршрутов. Филиалы получают обновления маршрутов от Control Plane, благодаря чему настраивать протоколы маршрутизации между устройствами Edge не требуется.

Ещё одна важная роль SD-WAN Gateway помощь в определении характеристик каналов связи. При активации устройства Edge выполняется подключение к Gateway и замер полосы пропускания канала, также автоматически определяется MTU.

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

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

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

Хороший пример использование облачных сервисов совместной работы, например, Microsoft Office 365, Dropbox, Zoom, Skype for business и других. В месте их фактического расположения установить SD-WAN Edge невозможно,но получить преимущества SD-WAN Overlay (подробнее в разделе о протоколе VCMP) нужно. SD-WAN Gateway выполняет функцию шлюза в большой интернет с балансировкой между каналами, компенсацией ошибок и выбором наиболее оптимального канала для передачи пакетов конкретного приложения.

VMware SD-WAN Edges

VMware SD-WAN Edge это физическое или виртуальное устройство с функциями безопасности. Фактически, это маршрутизатор, который может как заменить уже размещенные в филиалах устройства, так и работать с ними в тандеме. Он поддерживает функции сетевого шлюза, Site-to-Site VPN, DHCP-сервера, NAT и файрвола, а также различные протоколы маршрутизации для интеграции с физической сетью.

SD-WAN Edge в виртуальном исполнении подойдет тем, кто планирует использовать концепцию Software-Defined Branch или обеспечивать доступ к своим приложениям в ЦОД через SD-WAN. Виртуальный Edge в ЦОД подходит как в качестве связующего звена ресурсов ЦОД и удаленных площадок, так и в роли хаба для агрегации и распределения трафика внутри сети SD-WAN.

SD-WAN Edge поддерживает основные варианты резервирования есть возможность объединения в отказоустойчивую пару или подключение по протоколу VRRP.

И если компоненты решения руки, ноги и голова технологии VMware SD-WAN, то его сердце технология DMPO. Именно она и позволяет реализовать уникальные фишки по обработке сетевых пакетов при передаче данных (между филиалами и ЦОД, филиалами и облаками) и обеспечивает высокое качество связи. Поговорим о ней подробнее.

Технология DMPO

Технология DMPO (Dynamic Multi-Path Optimization) позволяет нам за счет гибкого управления трафиком на уровне приложений агрегировать потоки и обеспечивать высокое качество связи. DMPO работает на уровне отдельных пакетов, однако учитывает, к каким приложениям эти пакеты относятся. Транзакционным приложениям, таким как веб-сайты, инструменты передачи файлов, не принципиально, придет пакет вовремя или чуть позже, главное, чтобы он вообще дошел. А приложениям реального времени (стриминговые сервисы, приложения для голосовых вызовов и т.п.) очередность пакетов важна. Из-за мелких неполадок может рассыпаться картинка на экране или собеседник не расслышит слово. Поэтому важно, чтобы SD-WAN устройства понимали, что это за приложение. В этом помогает движок распознавания приложений (Deep Application Recognition), работающий на каждом устройстве SD-WAN Edge.

Приложений существует огромное множество, 3000+ из них есть во встроенной базе DPI VMware SD-WAN. Кроме того, можно добавить и кастомные (самописные) сигнатуры, если вдруг какого-то приложения не хватает. Посмотрим, какие функции выполняет DMPO.

Непрерывный мониторинг качества каналов

Для мониторинга состояния WAN-каналов в реальном времени стандартные сетевые технологии вроде BFD или ICMP Probes не совсем подходят, т.к. тестовые пакеты отличаются от пользовательского трафика (другие классы DSCP, другой размер пакетов), а интервал проб слишком высок, чтобы достоверно и быстро определить ухудшение качества. Например, даже при замерах BFD или ICMP каждую секунду за время между этими замерами у обычного пользователя с ноутбуком передается 200+ пакетов (проверьте сами, сняв дамп трафика). Чтобы зафиксировать уровень потери в 2%, потребуется не менее 50 BFD пакетов (50 с). Если использовать более агрессивные значения, например, 100 мс, все равно потребуется не менее 5 секунд, чтобы обнаружить потери в 2% на канале. За это время тысячи пакетов с пользовательскими данными могут быть потеряны.

Поэтому в решении Velocloud используется собственный протокол инкапсуляции Velocloud Multipath Protocol (VCMP), который добавляет к каждому пакету специальные заголовки, помогающие отследить время его прохождения (Latency, Jitter) и факт доставки. Это позволяет обнаружить ухудшение качества каналов практически мгновенно, а затем перенаправить пакеты на канал с лучшими показателями незаметно для пользователя.

За точное время в сети отвечает Control Plane уже известные нам SD-WAN Gateways. Устройства SD-WAN Edge синхронизируют свое время с центром управления сетью. Таким образом можно гарантировать, что все временные метки будут достоверны. В стандартных сетевых протоколах такие возможности отсутствуют.

Состояние каналов отслеживается даже в том случае, если пользовательского трафика на данный момент нет. Ведь когда этот трафик появится, его нужно сразу же отправить по оптимальному пути. Для этого устройства SD-WAN Edge обмениваются служебными пакетами VCMP, только без User Payload, каждые 100 или 500 мс. Как только появляется пользовательский трафик, система снова начинает отслеживать SLA для каждого пакета.

Динамическая балансировка трафика и агрегация каналов

DMPO позволяет определять, какие приложения используют сеть, при помощи политик манипулировать поведением SD-WAN и настраивать приоритеты.

Решение VMware умеет автоматически (за счет работы overlay-протокола VCMP) выбирать наилучший способ обработки и доставки трафика приложений. К примеру, если конкретному приложению требуется ускорить передачу данных, то есть агрегировать несколько каналов, умное SD-WAN устройство начнет передавать данные сразу по нескольким путям. Для балансировки используются все доступные подключения.

В ряде случаев стандартная балансировка не имеет смысла, они сильно отличаются между собой по характеристикам: на одном задержка 5 мс, на другом 100). Соответственно, балансировать трафик между ними бесполезно. Однако если быстрый канал окажется забит под завязку и на нем скопится большая очередь из пакетов, система определит, что каналы сравнялись по времени доставки пакетов. В этом случае в рассылке пакетов будут задействованы оба канала таким образом, чтобы пакеты по обоим доходили до точки назначение в одно и то же время. На принимающей стороне пакеты выстраиваются в порядке очереди так, чтобы клиенту или серверу за пределами сети SD-WAN не приходилось пересобирать их в требуемой последовательности. Соответственно, еще одна из функций, которую способно обеспечить устройство SD-WAN автоматический реордеринг.

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

Из-за особенностей каналов связи трафик между точками А и В может идти неравномерно: в одну сторону с задержкой 10 мс, обратно 20 мс. В то же самое время канал работает наоборот: туда 20 мс, сюда 10 мс задержки. По сети VMware SD-WAN такая сессия будет передаваться по обоим каналам сразу, в одну сторону по каналу с задержкой 10 мс, и так же обратно по каналу с наилучшими характеристиками.

За счет того, что каждый пакет обрабатывается индивидуально алгоритмами DMPO, система выбирает наилучший путь для каждого пакета автоматически, принимая решения в реальном времени.

Раньше администраторам приходилось вручную определять эту логику, либо настраивать схемы вида: каждые N секунд проверяем, какой канал и в какую сторону работает лучше и перестраиваемся при необходимости. Реализовать такую схему без разрывов пользовательских сессий практически невозможно. Ценность SD-WAN заключается в том, что вся эта запутанная логика делегирована алгоритмам они быстрее и точнее, чем даже самые сложные проверочные скрипты. Логика VMware SD-WAN работает на разных типах сессий и на разных транспортных протоколах, никак не нарушая логику работы TCP/IP.

Технологии корректировки ошибок

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

Получатель: Так, к нам идут пакеты. Первый, второй, третий, пятый Стоп. Почему пятый? Требую выслать мне пакет 4 как можно скорее! Прием!

Отправитель: Посмотрим, к какому приложению относился этот ваш пакет. Ага, вот оно! Высылаю компенсацию, подтвердите получение!

В случае транзакционного приложения устройству-отправителю будет достаточно найти в буфере нужный пакет и повторить отправку так работает технология NACK (Negative Acknowledgement). В устройствах SD-WAN используется серверная память гораздо большего объема, чем в обычных маршрутизаторах. Самая младшая модель имеет на борту 4 Гб, на старших 32 Гб и выше. Это позволяет держать буфер данных и по необходимости досылать потерявшиеся пакеты.

С realtime-приложениями ситуация обстоит иначе. Повторно отправлять пакеты не имеет смысла, важно предотвратить потери в будущем. Поэтому устройство-отправитель включает упреждающую коррекцию ошибок (Forward Error Correction, FEC), и каждый пакет начинает передаваться в двух экземплярах. Таким образом повышается вероятность успешной доставки пакетов, а лишние автоматически отбрасываются на принимающей стороне. На практике это позволяет использовать телефонию и видеоконференции на каналах с потерями до 30-40%.

Под капотом у провайдера

Некоторые компании пытаются внедрять SD-WAN самостоятельно, что приводит к необходимости решать множество не относящихся к сетевым технологиям задач (проектирование и развертывание управляющих компонентов, резервирование, масштабирование и дальнейшая поддержка, защита от атак, обеспечение доступности и т.д.). Согласно мировому опыту, большинство компаний все же выбирают SD-WAN как услугу от облачного провайдера или оператора связи. Давайте посмотрим, в чем плюсы использования SD-WAN от провайдера.

Разделение зон ответственности

Первая задача, с которой столкнется компания при самостоятельном внедрении построение облачной инфраструктуры SD-WAN: деплой контроллеров, виртуальных машин, выделение ресурсов, администрирование и многое другое. Построение такой инфраструктуры повлечет за собой значительные расходы в виде выделения или покупки дополнительных серверов и ПО, а также обеспечения условий Disaster Recovery. Эти сложности и расходы особенно трудно обосновать при постепенном внедрении SD-WAN. Во-вторых, для построения надежной отказоустойчивой сетевой связности требуется детально проработать целевую схему подключения, определить движение потоков данных, настроить политики безопасности.

Когда вы обращаетесь к провайдеру, все эти задачи ложатся на него. Он обеспечивает инфраструктуру, круглосуточный мониторинг, администрирование сети и защищенных распределенных ЦОД, уровень доступности и выполнение SLA. Провайдер поможет выбрать оптимальное оборудование и даст рекомендации по модернизации сети, чтобы она соответствовала всем требованиям качества и надежности. При этом клиенту остается только запросить доступ к облачному порталу управления сетью и создать учетные записи для администраторов. На любые вопросы по использованию услуги и настройке сервисов SD-WAN поможет ответить круглосуточная русскоязычная техническая поддержка.

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

Распределенная инфраструктура провайдера

Общая инфраструктура ИТ-ГРАД и #CloudMTS насчитывает 10 ЦОД в СНГ и множество точек присутствия по всему миру. Где бы ни находился филиал, он будет подключен к ближайшему SD-WAN Gateway, что позволит минимизировать задержки и оптимизировать доступ к любым приложениям в локальных ЦОД и любых облаках. Наличие распределенной инфраструктуры также позволяет обеспечивать георезервирование для сети SD-WAN любого масштаба.

Инфраструктура ИТ-ГРАД и #CloudMTS на территории РФ

В каждом ЦОД резервируются каналы, обеспечивается высокопроизводительная связность шлюзов SD-WAN с внешним миром. Дата-центры подключены к глобальной опорно-магистральной сети МТС, которая обеспечивает доступ к мировым публичным точкам обмена трафиком DE-CIX (Франкфурт), AMS-IX (Амстердам), HK-IX (Гонконг), LINX (Лондон), Equinix, NY-IX и т.д.

Кроме того, в распоряжении наших заказчиков:

• PNI (Private Network Interconnect) с гиперскейлерами и крупными генераторами трафика. Среди них Amazon AWS, Microsoft, Google Cloud, Apple, Facebook, Valve, Twitch, Netflix, Twitter и прочие.

• CDN-сети: Akamai, Google Cash и Google CDN, Cloudflare, Gcore labs, Microsoft и прочие.

Интеграция с IaaS и другими сервисами

Использование SD-WAN позволяет получить надежный доступ к сервисам, расположенными в инфраструктуре облачного провайдера. Какие преимущества это дает:

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

• Резервное копирование SD-WAN позволяет наладить максимально быструю и надежную транспортировку бэкапов по сети (с агрегацией каналов и обеспечением отказоустойчивости) по всем доступным каналам до облака.

• S3 хранилище, облачный диск при использовании сервисов блочного, объектного и файлового хранилищ подключение по SD-WAN позволяет передавать большие файлы на максимальных скоростях. Это достигается за счет отсутствия ретрансмитов при передаче данных и агрегирования каналов связи, подключенных к устройству SD-WAN.

• GPU Super Cloud высокоскоростная передача больших объемов данных для обработки в облачной среде.

Все чаще наши клиенты для подключения своих офисов к виртуальным дата-центрам ИТ-ГРАД и #CloudMTS вместо выделенных каналов выбирают SD-WAN и интернет-каналы. Клиенты, уже использующие выделенные каналы, применяют SD-WAN для агрегации существующих каналов, многократно повышая производительность и надежность подключения к облаку.

Будем рады пообщаться с вами в комментариях! В следующей статье мы проведем тестирование сервиса и на практике посмотрим, какие преимущества дают технология DMPO и протокол VCMP.

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

Как раз об этом мы поговорим под катом: лунный ЦОД, проекты по поддержанию жизни на Луне и пилотируемый облет Луны в рамках миссии Artemis.

NASA

Thales Alenia: 16 концептов для жизни человека на Луне

Совсем недавно, в апреле 2021 года компания Thales Alenia Space выиграла контракт Итальянского Космического Агентства (ASI) на проведение технико-экономического обоснования 16 концепт-проектов по поддержке присутствия человека на Луне в рамках программы NASA Artemis. Эти исследования могут лечь в основу общего плана ASI на участие в мировых лунных программах.

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

К участию в исследованиях Thales Alenia Space планирует привлечь множество итальянских компаний, как уже имеющих космический опыт, так и молодых, которым только предстоит раскрыть свой потенциал.

Применяя подход взаимообмена [информацией и ресурсами], Thales Alenia Space будет координировать всех своих партнеров в рамках проведения всестороннего анализа требований для поддержания жизни человека на Луне и исследования Луны в соответствии со стратегическим видением итальянского космического агентства.

По словам Массимо Компарини, генерального директора Thales Alenia Space, инновации это ключ в Thales Alenia Space к повышению конкурентоспособности при решении новых задач. Выигранный контракт является прекрасным примером того, как развитие перспективных технологий может усилить синергию и стимулировать вклад других секторов [науки и частного бизнеса].

Thales Alenia Space также возьмется за изготовление модулей для лунной космической станции Gateway, ключевого элемента программы Artemis NASA. Планируется, что на лунной орбитальной станции разместят жилые модули, модули материально-технического снабжения, роботизированный манипулятор и стыковочные модули. Она не будет предназначена для постоянного пребывания космонавтов, но небольшие экипажи (до четырех человек) смогут жить на станции от одного до трех месяцев. Специалисты NASA считают, что такой опыт позволит лучше подготовиться к отправке первых людей на Марс, и Gateway будет играть ключевую роль в этом процессе.

Однако на этом планы TAS и NASA не заканчиваются.

Лунный дата-центр

Мы видели треш-ЦОДы, подводные, антарктические, замурованные в горную твердь дата-центры. Похоже, на Земле попросту закончились креативные локации, где было бы можно разместить ИТ-ресурсы. Некоторое время назад пальму первенства в этом вопросе удерживала компания Microsoft с подводным дата-центром Natick.

Специалисты TAS в рамках NASA Artemida также планируют разработать концепт лунного дата-центра. Они приводят следующие доводы о целесообразности этой затеи:

• Место на Земле ограничено. Леса, поля, реки их можно будет сохранить, если удастся вывести ИТ-мощности за пределы нашей планеты.

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

• Проблема физической безопасности оборудования также отпадает сама собой (если не брать в расчет прочие, не связанные с человеческим фактором риски).

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

Специалисты TAS объясняют, что будущим колонистам не обойтись без вычислительных мощностей, но использование земных ЦОДов неизменно приведет к проблемам из-за задержек при передаче сигнала. Именно поэтому дата-центр предлагается разместить прямо на Луне. Никакой информации о том, как будет выглядеть лунный ЦОД, пока нет это будет зависеть от задач, которые лягут на плечи внеземного дата-центра.

Если все пойдет по плану, лунный дата-центр введут в эксплуатацию уже в этом десятилетии, а сам объект станет частью LunaNet и будет подключаться к лунной сети Nokia.

На разговоры скептиков о том, что решение выглядит крайне дорогой авантюрой, которая может выйти из строя в любой момент, специалисты Thales Alenia Space отвечают так: взгляните на спутники, они вращаются на орбите уже не первое десятилетие и успешно справляются с задачами по вещанию, навигации и доступу в интернет!. По их словам, дата-центр на Луне только кажется сумасшедшей затеей. Всё покажут результаты более серьезных лунных миссий в рамках проекта Артемида (Artemis), а пока можно смело поддерживать, критиковать и обсуждать эту идею.

Туда и обратно: пилотируемый облет Луны

Пока Китайский микроспутник изучает обратную сторону Луны, NASA планирует запустить сразу два возвращаемых космических корабля. В рамках уже упомянутой миссии Artemis анонсирован запуск корабля Orion. Его цель достичь Луны, сделать облет и вернуться на Землю.

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

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

Общее описание миссии

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

Распространение коронавируса нового типа, тем не менее, внесло свои коррективы: разработка ракеты-носителя SLS существенно замедлилась, и изначальные сроки сдвинулись почти на год.

На этом список лунных инициатив ближайшей декады не заканчивается. Если тема покажется Хабру интересной, мы подготовим цикл статей об ИТ-составляющей миссий и всём, что с ними связано. А пока остается надеяться, что всего через несколько лет выражения а-ля Ты что, с Луны свалился? или Привет лунатикам! потеряют комический подтекст и получат связь с действительностью.

Этой небольшой статьей-заметкой мы хотели бы завершить серию публикаций, посвященных истории виртуализации в Enterprise-сегменте рынка. Сегодня поговорим о VMware, компании, которая на сегодняшний день является фактическим законодателем в мире виртуализации. Давайте посмотрим, как выглядели одни из самых ранних продуктов VMware: GSX и ESX.

VMware была основана в 1998 году. Её первым коммерчески успешным продуктом считается VMware Workstation, выпущенный в 1999 году и предназначенный для работы на клиентском железе.

Для серверных рабочих нагрузок в следующие 2 года был с нуля разработан продукт VMware GSX Server. Его название это сокращение от более длинного рабочего имени Ground Storm X. Первая коммерческая версия 1.0 датируется 2001-м годом. Устанавливалась она поверх Windows Server или SUSE Linux, что характеризует ее как гипервизор 2-го типа.

Усовершенствованная версия GSX Server 2.0 увидела свет через год, летом 2002-го. Под своим оригинальным именем продукт просуществовал вплоть до декабря 2005-го, когда была выпущена последняя коммерческая версия 3.2.1.

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

Затем GSX Server был переименован в VMware Server и стал распространяться совершенно бесплатно. В списке поддерживаемых гостевых систем появились и 64-битные ОС, а гипервизор получил возможность выделять машинам несколько vCPU. VMware Server появилась 12 июля 2006-го и официально поддерживалась вплоть до 2011-го.

Сладкий плод виртуализации понравился инженерами VMware. Гипервизоры 2-го типа это хорошо, но 1-й тип способен дать гораздо больше возможностей!

Параллельно с GSX Server шла разработка нового гипервизора типа 1. В отличие от предшественника, его уже можно было установить на голое серверное железо без ОС-посредника.

Продукт получил рабочее название VMware Scalable Server. В настоящее время он известен уже под именем ESXi. Ниже приводим скриншот, приблизительно датированный 1999-2000 годом.

Уже совсем скоро, к 2000-му, проект получил новое название: VMware Workgroup Server. А в марте 2001-го компания официально выпустила VMware ESX 1.0 Server. ESX это аббревиатура от Elastic Sky X. Забавно, но придумали его вне стен VMware. Сотрудники компании прекрасно разбирались в компьютерах, но ничего не смыслили в рекламе и маркетинге. Специально нанятое агентство предложила лаконичный вариант Elastic Sky. Инженеры взбунтовались: как это, новый коммерческий продукт, в названии которого нет ни малейшей технарской изюминки?!

И добавили в конце загадочный X. Почему? Вероятно, чтоб никто не догадался!. Да и звучит более круто. Забавно, как точно это имя попало в цель: вряд ли в далеком 2001-м кто-то придумывал его с оглядкой на облачные вычисления.

Впоследствии вокруг нового продукта сформировался целый отдел, самым известным сотрудником которого был Джон Аррасджид, один из авторов и ведущий архитектор vCloud Architecture Toolkit (vCAT).

VMware ESX Server стал первым на рынке гипервизором 1-го типа для Intel x86. В нем были впервые реализованы многие функции, ставшие едва ли не стандартом: живая миграция виртуальных машин, High Availability, автоматический балансировщик нагрузки, инструменты управление питанием и т.п.

В течение нескольких лет ESX и GSX были одновременно доступны широкой аудитории. GSX целился в более приземленную аудиторию: малый бизнес, небольшие государственные учреждения, в то время как ESX стал флагманским продуктом для Enterprise-сектора. Однако по-настоящему серьезно ESX начал использоваться лишь к 2006 году.

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

Еще до того, как ESX начал серьезное распространение в бизнес-среде, началась разработка его преемника, уже без сервисной консоли. К сентябрю 2004-го внутри компании состоялась презентация первой полнофункциональной версии продукта под названием VMvisor (VMware Hypervisor). Через 3 года этот продукт появится на рынке под общеизвестным именем ESXi.

На выставке VMworld 2007 компания представила VMware ESXi версии 3.5. Прошлые версии программы существовали только в недрах VMware и не демонстрировались широкой публике.

ESXi занимает гораздо меньше места, чем ESX, и может быть установлен во флэш-память. Фактически, его уже можно рассматривать как часть сервера на это намекает буква i в его названии. Она означает Integrated, интегрированный.

Вплоть до выхода vSphere 4.1 VMware предлагала клиентам два варианта: VMware ESX с Linux-консолью и ESXi с меню настройки сервера. Поддержка ESX официально завершилась с выпуском vSphere 5.

Программное обеспечение, как и гипервизор, несколько раз меняло названия. Например, VMware VMcenter настолько редко и давно использовалось, что по нему даже толком ничего не гуглится. Разумно предположить, что это одно из внутренних наименований продукта. Оно фигурирует, например, на этом скриншоте:

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

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

Сегодня мы поговорим о по-настоящему знаковой машине, Altair 8800, и о ее создателе. Этот компьютер смог доказать всему миру: за устройствами на микропроцессорах будущее.

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

Продавались компьютеры в те годы через почту: компания дала рекламное объявление в Popular Electronics и прочих специальных изданиях, а покупателям предлагалось отправить по указанному адресу письмо с заказом. К покупке были доступны и полностью собранные юниты, и наборы для сборки.

Altair 8800 по праву считается первой искрой, из которой разгорелся пожар микрокомпьютерной революции. Компьютерная шина, разработанная для Altair, де-факто задала стандарт целой отрасли. А Altair BASIC, первый язык программирования для этой машины, был разработан небезызвестной компанией Micro-Soft (тогда ее название еще писалось через дефис).

Появление MITS

В 1969 году молодой и амбициозный инженер Генри Эдвард Робертс (он родился в 1942 году) работал в специализированной лаборатории ВВС в Нью-Мексико. Вместе с тремя своими коллегами он решил применить знания в области электроники для организации производства небольших наборов для любителей моделей ракет.

Эд Робертс в 80-е

Друзья организовали компанию Micro Instrumentation and Telemetry Systems (MITS) по тогдашней традиции, прямо в гараже Робертса в Альбукерке. Вскоре они выпустили первую партию радиопередатчиков и наборов для сборки ракет. Продукт не снискал особого успеха на рынке, и вскоре MITS перешла на выпуск DIY-наборов для сборки калькуляторов. Этот проект оказался чуть более удачным и позволил компании перейти на более серьезные товары.

Первый продукт компании мигалка для ракетКалькуляторы MITS

С выходом процессора Intel 8080 в апреле 1974 года рынок микропроцессоров по-настоящему взлетел. Новый CPU мог адресовать до 64 КБ ОЗУ, и его мощностей хватало на построение полноценного компьютера. Поэтому вслед за комплектами для сборки калькуляторов Робертс принялся разрабатывать нечто более интересное. Первый компьютер на базе Intel 8080 в качестве прототипа появился на свет поздней осенью 1974 года. Робертсу удалось добиться интервью с журналом Popular Electronics (там уже знали, что MITS работает над созданием компьютера на базе Intel 8080) и таким образом прорекламировать свою разработку. Предполагалось, что интервью и обзор компьютера будут опубликованы в горячем январском номере журнала. Что касается названия, слово Altair было предложено Робертсу издательством.

Обложка журнала Popular Electronics, январь 1975 г., с изображением Altair 8800

Altair 8800 появился на рынке в самый подходящий момент. MITS успела обзавестись достаточной клиентской базой школы, колледжи, домашние любители электроники. И все они хотели заполучить собственный компьютер. Киллер-фичей Altairов по сравнению с прочими компьютерами на базе Intel 8080 стал высокоуровневый язык BASIC: в отличие от традиционного в то время языка ассемблера, он был гораздо проще в освоении и понижал порог входа для новичков. К тому же Altair был достаточно мощным, чтобы оказаться действительно полезным. Предполагалось, что машину можно будет расширять и, соответственно, приспосабливать под решение самых разных задач.

Реклама Altair 8800

Первые продажи

Придя в банк за ссудой, Робертс оптимистично заявил, что за год сможет продать 800 компьютеров. А чтобы выйти в плюс, достаточно реализовать всего 200 единиц. Каково же было его удивление, когда после публикации рекламы в Popular Electronics на митс сошла целая лавина заказов. Пришлось нанять в штат дополнительных людей только для того, чтобы отвечать на звонки потенциальных покупателей. Уже к концу февраля MITS получила 1000+ заказов на Altair. Это не могло не сказаться на времени поставки: заявленных 60 дней не хватало на то, чтобы подготовить и выслать все заказы. Лишь к середине года Робертсу и его коллегам удалось наладить процесс подготовки и отправки компьютеров. В мае того же года MITS отчиталась, что ей удалось успешно поставить уже 2500 штук Altair 8800. А к августу их число превысило 5000. Это не могло не сказаться и на устройстве компании: если в январе в MITS работало менее 20 человек, то к октябрю их число возросло до 90.

Линия сборки Altair 8800

Компьютер оказался крайне прибыльным, а шина расширения позволила MITS продавать дополнительную память и интерфейсные платы. В Altair использовался CPU Intel 8080A (реже 8080), работавший на частоте 2 МГц (каждая инструкция занимает 4 такта). Объем оперативной памяти составлял всего 256 байт (память 1024 слова), а плата с ней продавалась отдельно. Язык BASIC, о котором было объявлено в июле 1975 года, требовал наличия одной или двух плат памяти на 4096 слов, а также интерфейсной платы. Сам комплект Altair стоил 439 долларов. Платы памяти на 1024 слова (176 долларов) и 4096 слов (264 доллара) докупались по мере необходимости. Позднее Робертс представил также платы параллельного интерфейса (92 доллара) и 2 типа плат последовательного интерфейса: для загрузки программ с аудиокассет и для работы с телетайпом.

Altair 8800

Программировать на первой версии Altair было сущей пыткой: подключение клавиатуры не было предусмотрено, и инструкции вводились в машину сугубо механическим путем. Пользователь должен был переключать переключатели-рычажки на корпусе машины в положения, соответствующие инструкциям микропроцессора 8080 или коду операции в двоичном формате, а затем загружать код в память машины переключателем ввода. Этот алгоритм требовалось повторять до тех пор, пока вся программа не окажется введена в память. Сейчас сложно это представить, но в первой версии Altair единственным пользовательским интерфейсом была панель с лампочками. Собственно, на мигании лампочками функционал компьютера и заканчивался. Но продажи все росли и росли. Робертс в поте лица трудился над созданием дополнительных карт-модулей, среди которых были устройство для чтения перфолент, дополнительные платы RAM, последовательный интерфейс RS-232 для подключения к телетайпу, видеокарта и 8-дюймовый дисковод для дискет объемом до 300 КБ.

Фронтальная панель Altair 8800Внутренности компьютера

Двое взволнованных мужчин

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

Перфолента с Altair BASIC

Первый запуск программы оказался неудачным: интерпретатор выводил сообщение Altair Basic на экран и неминуемо вылетал. Что-то было не так с бумажным носителем. Тем не менее, Робертс согласился немного подождать и дать BASICу шанс. Уже на следующий день Аллену доставили новую, протестированную ленту, и она, слава богу, запустилась без проблем.

Первая когда-либо введенная программа на BASIC выглядела так:

10 print 2 + 2

После ввода команды run она вернула правильный ответ. Робертс сразу же предложил Аллену должность директора отдела по разработке программного обеспечения (который состоял из единственного сотрудника, других разработчиков ПО у MITS еще не было). Гейтс, тогда еще не ушедший в академический отпуск ради создания собственной компании, также устроился в MITS на полставки. Лишь спустя некоторое время Гейтс и Аллен покинули MITS и основали Micro-Soft.

Теперь скажем пару слов о важности Altair для всей компьютерной промышленности. Altair 8800 вдохновил энтузиастов по всем США на создание Клуба любителей домашних компьютеров. Позднее из этой организации появилось более двух десятков компьютерных компаний, включая Apple Computer.

В 1977 году MITS была куплена Pertec Computer Corp. за $6 млн, а Робертс поступил в медицинский институт Университета Мерсера. Неизвестно, по какой причине он решил сменить сферу деятельности, но, так или иначе, компьютеры для него остались в прошлом. Надо сказать, Робертс не единственный человек, ушедший из технологического бизнеса после реализации единственного успешного проекта. Что-то подобное произошло и с небезызвестным Клайвом Синклером, этой темы мы уже касались в одной из прошлых статей.

Всю оставшуюся жизнь Робертс проработал сельским врачом в Кокране, штат Джорджия, и скончался 1 апреля 2010 года.

Видео с демонстрацией работы Altair 8800:

Основной источник