Облачные Managed Services – часть 2 – технологические отличия от "традиционных"​ Managed Services


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

  • Поставщики облачных Managed Services выступают «головой», а не «руками» заказчика и концентрируются не на том, «чтобы все виртуальные машины работали», а на консультационной помощи заказчику по миграции в облака и модернизации приложений в формат «нативных» решений. Фактически, поставщик современных облачных Managed Services для заказчика – это, как модно говорить сейчас, «Trusted Advisor» по всему, что касается облаков.
  • Облачные Managed Services отвечают за SLA бизнес-процессов, а не за непонятный для бизнеса заказчика SLA времени ответа на запрос. Задача современных Managed Services обеспечить желаемый SLA для критического сервиса/приложения заказчика, используя все доступные средства облака и способствовать модернизации приложений.
  • Поставщик современных облачных Managed Services работает с заказчиком по принципу «непрерывного проекта миграции и модернизации», обеспечивая постоянное внедрение новых служб, решений и модернизацию существующих без переключения на «сторонние проекты».
  • Поставщик современных облачных Managed Services работает в непрерывном контакте с заказчиком, имея в команде технического менеджера, который поддерживает регулярную коммуникацию с заказчиком, знает о всех его планах и проблемах, обеспечивает координацию с различными командами и вендорами заказчика и управляет ресурсами своей команды и текущими проектами.
  • И, наконец, «цена вопроса» за услуги Managed Services, которая формируется не путем подсчета «виртуальных машин по головам», а в проценте от общей суммы утилизации Azure клиентом.

А в этой части мы поговорим о технологических и процедурных отличиях современных облачных поставщиков Managed Services по сравнению c «динозаврами» «традиционных» Managed Services.

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

Такой мониторинг и автоматизация в первую очередь должны быть направлены на обеспечение требуемого SLA для критических бизнес-сервисов и приложений заказчика, о котором говорилось в предыдущей части. И, учитывая специфику и возможности мониторинга в Azure и сервиса Azure Log Analytics – основной отличительной чертой современного провайдера Azure Managed Services является проактивный мониторинг с предсказанием тенденций по тем или иным показателям критических приложений и/или поиском аномалий в текущих показателях. Звучит красиво и непонятно, а в реальности – Azure Alert, который базируется на нескольких командах в запросе KUSTO к нужным данным, которые хранятся в таблицах Azure Log Analytics – и мы получаем, например, тенденцию уменьшения свободного места на диске исходя из показателей мониторинга последних 15-30 минут, часов, дней – в зависимости от того, насколько высоки требования к SLA решения и как «чутко» нам нужно реагировать на возможное отсутствие дискового пространства для серверов приложений и сколько за это готов платить заказчик. Напомню, что каждый такой Alert с запросом и собственно, время работы вызванной после процедуры Azure Automation стоит денег, пускай это идут центы, но при активном использовании с минутными интервалами – может набегать ощутимая сумма.

Сценарии применения такой «предсказательной» автоматизации – бесконечно обширны благодаря инструментарию управления в Azure. Конкретный пример с предсказанием окончания места на диске за несколько дней до критического значения (обычно 5-10%) в реальных инфраструктурах – это и оправка уведомлений всем заинтересованным лицам + создание «тикета» в системе управления того бизнес-приложения, у компонентов которого место на диске подходит к концу, и запуск Azure Automation runbook, который в ближайшее окно обслуживания остановит, если возможно, проблемную виртуальную машину и увеличит размер диска на ней. Другой сценарий – это предсказание изменения нагрузок (кол-ва запросов) на том же Azure Application Gateway, чтобы предварительно увеличивать/уменьшать количество работающих экземпляров App Gateway в зависимости от недельных/сезонных и общих тенденций, что позволяет обеспечивать и высокую доступность решения, и экономить деньги клиента, подстраивая количество экземпляров под реальные потребности. И да, я в курсе про autoscaling для App Gateway, но как показывает опыт – всегда стоит держать +1 экземпляр в горячем режиме про запас – потому что автоматическое масштабирование не успевает реагировать на те же атаки или даже просто резкий скачек нагрузки при каких-то онлайн событиях. А вот такие онлайн события по расписанию очень легко предсказывать на недельном форекасте и реагировать за 15-30 минут до их начала расширением пула и экземпляров App Gateway, и App Services, и SQL Database DTU, и прочих компонент приложения.

Интересной особенностью Azure Monitor и Azure Log Analytics является Azure VM Insights – возможность «заглядывать» в то, что происходит на уровне ядра OS виртуальных машин и получать информацию не только о показателях производительности базовых компонентов, но и, например (еще один реальный сценарий), мониторить и предсказывать «всплески» высокого уровня задержек сетевых соединений (outbound connection latency) процессов приложения при запросах между виртуальными машинами, на которых находятся компоненты приложения, или к базам данных. Опять же, зная суточные/недельные/месячные тенденции и текущие показатели – очень легко предсказывать возможные «залипания» соединений и быстро реагировать на проблемы путем увеличения количества виртуальных машин требуемого типа в пуле приложения. И да, заметьте, тут для масштабирования используются не стандартные показатели типа CPU/RAM/Disk или даже число запросов, а именно тот показатель, который может серьезно влиять на доступность и производительность приложения, не смотря на отсутствие явных признаков высокой утилизации конкретной виртуальной машины и всего решения в целом.

И чтобы не быть голословным (все-таки техническая часть) – вот вам небольшой пример того самого запроса KUSTO к Azure Log Analytics с визуальным предсказанием нагрузки App GW, который отображает общую почасовую тенденцию изменения трафика на App GW в следующие 3 дня исходя из истории предыдущих 5 дней:

let min_t = toscalar ( AzureDiagnostics | where TimeGenerated > ago(5d) | summarize min(TimeGenerated));

let max_t = toscalar ( AzureDiagnostics | where TimeGenerated > ago(5d) | summarize max(TimeGenerated));

AzureDiagnostics

| where TimeGenerated > ago(5d) and ResourceType == “APPLICATIONGATEWAYS” and OperationName == “ApplicationGatewayAccess”

| make-series Requests_H = count() on TimeGenerated from min_t to max_t+3d step 1h

| extend forecast = series_decompose_forecast(Requests_H, toint(3d/1h),0)

| render timechart

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

clip_image002

А дальше – выполняя такие запросы по расписанию (и помним о цене запроса) и оценивая тенденции или находя аномалии – запускаем в случае критических показателей требуемые скрипты Azure Automation или других продуктов, которые внедрены в процессы компании.

Проактивный мониторинг инфраструктуры – это отличное средство обеспечения требуемых SLA, но не стоит игнорировать и стандартные средства эффективной реакции на проблемы инфраструктуры и приложений в Azure, такие, как уведомления/предупреждения о проблемах (служба Azure Alerts, являющаяся частью Azure Monitor) и автоматической проверки здоровья (Health checks/auto-healing, опции различных служб), работающие в той же связке с Azure Automation для реакции на события путем запуска требуемых Azure Automation Runbook.

На рынке существует достаточно большое количество решений, обеспечивающих сбор и мониторинг данных по работающей инфраструктуре в Azure, но в большинстве своем – это универсальные системы, строящие «красивые отчеты» и «дашбоарды» для различных компонентов, в то время, как для современных облачных Managed Services важно гарантировать SLA клиентского сервиса в целом, что уже упоминалось в первой части статьи. Потому для доведения решения до требуемой кондиции – контроля за SLA и реакции на возможные проблемы – все равно требуется доводка таких универсальных систем «напильником». И, как показал опыт – подстраивать сторонние готовые универсальные мониторинга системы под задачи конкретного заказчика – весьма утомительно и, часто, очень проблематично ввиду особенностей архитектуры этих систем. Кстати, об архитектуре систем – практически эта архитектура требует в тенанте (даже не подписке) заказчика наличия учетных записей с такими правами, на которые служба безопасности заказчика категорически не согласна. Так что приходится все это решать средствами собственных скриптов, объединяя с упомянутыми выше очень даже функциональными сервисами Azure. Как работает такая связка – я постарался вкратце рассказать в ходе недавнего онлайн семинара по Azure Automation и Azure Monitor/Log Analytics – https://youtu.be/a6VGeDUNYt4


Azure AZ-900 – онлайн-семинар MUK – обзор Azure Automation, Monitor, Log Analytics, Logic Apps

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

Интересным аспектом является модный ныне DevOps, о котором столько разговоров. И да, вы правильно сделали выводы – если я не начал с самого начала нахваливать DevOps – он действительно не играет существенной роли в предоставлении Managed Services (если, конечно, вы не предоставляете DevOps, как одну из услуг Managed Services). Тот же практический опыт показал полное отсутствие каких-либо преимуществ применения DevOps перед традиционными средствами развертывания и управления инфраструктурой в Azure – типа шаблонов ARM, Azure Automation, DSC – для предоставления тех же услуг развертывания инфраструктуры в рамках Azure Managed Services. Почему так? – Да потому, что большинство инфраструктур заказчика стабильны и меняются не так часто, потому репозитория ARM шаблонов вполне достаточно и для начального развертывания, и для дальнейшей модификации/восстановления при сбоях. Что же касается программной части – тех же Azure Apps Services, Azure Data Platform, Kubernetes и прочих – в задачу Azure Managed Services входит их мониторинг и поддержка, а начальное «запиливание» кода в большинстве случаев – это ответственность команд разработчиков (причем, чаще – во множественном числе), которые работают над своим продуктом и со стороны поставщика Azure Managed Services им требуется готовая инфраструктура самой службы DevOps, настроенные системы мониторинга и реакции на проблемы со стороны Azure. Очень часто – разработчики вообще не представляют, какие функции управления инфраструктурой того, что они «наворотили», имеются в Azure и именно «обвес» мониторинга и высокой доступности всего решения в целом – куда входят и Application Gateway/WAF с CDN, и App Services с базами данных и хранилищами, и средства управления масштабированием и здоровьем, и репликации, а не отдельный экземпляр App Services – и является зоной ответственности команды Azure Managed Services и требует постоянного взаимодействия с командой разработчиков и разработки спецификаций, которые позволяют упростить процесс работы такой инфраструктуры и которым должны следовать разработчики в архитектуре своего решения.

Так что DevOps – это скорее нет, чем да… Или вы «подхватываете» у заказчика, а вернее – его поставщиков – функции разработки и DevOps по совместительству. Но это уже совсем не та история, которая про Azure Managed Services.

А вот следующая часть «той истории» современного облачного поставщика Azure Managed Services начинается в последних предложениях про DevOps о спецификациях – это называется Operational Excellence (OE) – по-русски звучит коряво – «Операционное Совершенствование» – потому буду использовать в тексте аббревиатуру OE. Operational Excellence я бы назвал одной из основных составляющих успеха после того, как вы наработали у себя в облачных Managed Services необходимый минимум репозитория шаблонов скриптов и дальше развиваете свой бизнес. Какие первоочередные задачи стоят перед OE в данном случае? Во-первых – это работа над спецификациями типа LLD benchmark checklist, Developers benchmark checklist и т.п. Все эти спецификации должны определять списки требования к архитектурам, которые планируют для ваших заказчиков либо ваши коллеги из Professional Services, либо разработчики заказчика, либо непосредственно ваши сотрудники, работающие в Managed Services. Такие OE спецификации для планирования решения чаще всего содержат в себе требования к наличию различных компонентов мониторинга и управления в дизайне по умолчанию. Например, для Azure LLD OE benchmark checklist это проверка архитектуры на:

· Наличие Azure Monitor Alert, который уведомляет о глобальных проблемах всех служб Azure

· Наличие Alert для критических значений вместимости и производительности для всех компонентов

· Наличие требуемых служб мониторинга – Azure VM Insights, Application Insights, Azure Log Analytics, Azure Security Center для критических компонентов

· Наличие карты требуемых процессов обслуживания

· Наличие автоматизации рутинных процессов с использованием Azure Automation

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

· Наличие плана восстановления после сбоев

· Наличие списка других объектов/процедур, которые являются критическими в инфраструктуре и т.п.

Следующая часть OE – это внутренние процессы, такие, как контроль за процедурными документами и их соответствию текущему статусу инфраструктуры, улучшение основных процессов поддержки SLA путем внедрения результатов анализа каждого сбоя – Root Cause Analysis (RCA), и, самое главное – это наличие процессов анализа обращений клиентов с целью обнаружения типовых обращений и создания на их основе новых автоматических процедур или решений, которые обеспечивают доступ к требуемой информации/операций посредством порталов или приложений самообслуживания.

И да, Operational Excellence – это моя «боль», поскольку даже при очень хорошо продуманных процедурах, особенно внутренних – надо еще научить коллектив соблюдать эти процедуры. И здесь, опять же – приходит на помощь и автоматизация бизнес-процессов, и, конечно же, правильные KPI. Но это уже тема следующей части про действительно современные и актуальные облачные Managed Services.

Зато есть еще одна, упомянутая выше, технологическая часть Azure Managed Services, которая существенно отличается от «традиционных» – поскольку мы работаем с облаками и, как уже говорилось в первой части, не блокируем полностью клиентский доступ к инфраструктуре – тут у нас открывается обширное поле деятельности для создание решений по самообслуживанию, особенно, если OE работает и вы быстро определяете базовые рутинные потребности в обслуживании для каждого клиента Azure Managed Services. Что дальше? Безусловно – автоматизация или применение современного удобного инструментария/платформ разработки решений, которые позволяют максимально ускорить взаимодействие заказчика с его же инфраструктурой.

К чему это я? Все очень просто – такими инструментами и платформой для создания решений самообслуживания являются и сам Azure с его Log Analytics, Logic Apps, Automation, Functions, Cognitive Services, и платформа Power Platform c Power Apps, Power Virtual Agents. Применение Power Apps позволяет очень легко и просто предоставить заказчику, особенно менеджменту, простое приложение-панель информации для мобильных платформ (телефонов и планшетов) – наиболее востребованная, как показывает опыт и анализ запросов, функциональность – «хотим видеть на телефоне прямо в реальном времени состояние всех приложений и их компонентов (светофорчики)». Используя Power Apps и средства типа Log Analytics и Functions, которые вызываются из Power Apps – создание такого приложения занимает считанные дни, модификация – часы, а публикация – минуты. При этом такое простое приложение имеет громадный позитивный эффект на лояльность и удовлетворенность менеджмента заказчика предоставляемыми Azure Managed Services.

Второй сценарий – это автоматизация стандартных технических запросов от инженеров заказчика, которые обслуживают непосредственно приложения, обычно – внутри виртуальных машин и лезть куда-то в незнакомый портал и отвечать за «поломанное» им совершенно не интересно. Опять же, как показала практика – самый эффективный способ быстрой реакции на запрос – это автоматизация обработки почтовых сообщений, в которых с простым синтаксисом описываются требуемые операции, такие, как создание виртуальных машин или команды к существующим, изменение конфигураций NSG, App Services, Application Gateway, запросы на отчеты и многое другое. А далее – используется Azure Logic Apps, которые управляют данным процессом, с запросом (если требуется) подтверждений операций как со стороны ИТ заказчика, так и инженера поддержки команды Azure Managed Services. И после прохождения всех формальностей – такое электронное письмо разбирается через Cognitive Services, проверяется на предсказание возможных последствий или наличие аномалий для SLA и сами операции выполняются средствами Azure Automation, Functions и Log Analytics. Подобные сценарии я рассматривал в упомянутом ранее видео про автоматизацию управления Azure – https://youtu.be/a6VGeDUNYt4

Опять же, как и в варианте с Power Apps, на разработку бизнес-процесса требуется несколько дней, после чего уже технические специалисты заказчика остаются очень довольными простотой взаимодействия. Сразу скажу, что особым хитом сезона являются всякие там запросы на отчеты по email – написал имя виртуальной машины или ресурсной группы и даты – и получил через минуту полный почасовой отчет утилизации ресурсов ВМ.

И тут возникает правильный вопрос – а как же Level 1 Support? А вот никак, поскольку в большинстве своем Azure Managed Services – это непрекращающийся постоянный процесс модернизации инфраструктуры из наследованных технологий в облачные. И если специалист L1 не в курсе процессов и зависимостей внутри инфраструктуры заказчика – он скорее не поможет, а навредит, и при этом – базовые операции типа пресловутой «перезагрузить ВМ» уже запросто могут быть делегированы системе со службой самообслуживания, поскольку вызывая такую операцию из приложения или почты – заказчик вызывает не команду перезагрузки ВМ, а достаточно сложный скрипт, проверяющий влияние такой операции на SLA бизнес-приложений и принимающий решение уже на базе сценариев «лучшего возможного SLA».

А Level 1 – разве что приятный женский голос, отвечающий по телефону + мы начали эксперименты с Power Virtual Agents для предоставления той же информации о статусе и отчетов. А «мальчикам» из Level 1 придется либо расти до инженеров (про требования к инженеру в Azure у меня есть серия публичных собеседований – см.ниже), либо искать другую работу.


ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.01

· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.01 – https://youtu.be/HmpgQoahXTA

· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.02 – https://youtu.be/cFzd62vlB9M

· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.03 – https://youtu.be/DECMirInQ2I

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

Облачные Managed Services – современная реальность "цифровой трансформации"​ и отличия от "традиционных"​ Managed Services


* Больше технических статей и постов на LinkedIn – https://www.linkedin.com/in/iwalker2000/
* Мой YouTube канал и технические видео на нем – https://www.youtube.com/iwalker2000
* Бесплатный курс по подготовке к экзамену Azure Fundamentals AZ-900 – http://bit.ly/Exam-Az-900

Как показывает личный опыт последних лет, красивые слова типа «диджитализация», «цифровая трансформация» и прочие расхожие фразы, которые должны подчеркнуть невероятную «продвинутость» компании на пути к новым вершинам «облачного» бизнеса – очень часто являются всего лишь красивой вывеской, за которой скрывается уровень бизнеса 20летней давности и косность менеджмента, по прошествии «20 лет успеха» не способного уже мыслить по другому, как раз критериями той самой «цифровой трансформации»… Нет, эта статья не будет про различные личные психологические практики «как принимать новое» и «читать больше и думать инновационно» – эта статья будет более практической – я постараюсь сформулировать собственное видение того, что является действительно «трансформированными» Managed Services для облака (в моем случае речь пойдет про Azure и базируется на личном опыте создания и руководства соответствующем департаментом) в отличие от «традиционных» Managed Services, к которым продолжают тяготеть «динозавры» бизнеса под вывеской «диджитализации».

Итак, чем же должны отличаться организации, которые предоставляют современные Azure Managed Services от организаций с «традиционными» Managed Services и какой путь должны пройти последние, чтобы предоставлять действительно современные Managed Services для облаков, а не уровень звонка в Level 1 типа «у нас не работает виртуалка – пожалуйста, перегрузите»?

Облака – это существенное изменение в управлении, поскольку они добавляют новый, не достижимый ранее, уровень гибкости для Managed Services благодаря своим сервисам уведомлений, мониторинга, автоматизации, автоматического поддержания здоровья и безопасности поверх таких возможностей облаков, как эластичность, масштабируемость и отказоустойчивость. Соответственно, клиенты Azure Managed Services ожидают от поставщика услуги, что все данные инструменты будут использованы для обеспечения беспрерывной работы уже не отдельных виртуальных машин, а их бизнес-сервисов и бизнес-процессов в целом и разговор «ой, у меня не работает виртуальная машина» просто не может произойти в рамках облачных Managed Services. Также клиенты ожидают от поставщиков Azure Managed Services, что их методологии и подходы к Operational Excellence тоже будут трансформированы и адаптированы к облачным условиям, где используются не только реактивные инструменты мониторинга и автоматизации здоровья решений и SLA, но и службы автоматического улучшения инфраструктуры бизнес-сервиса, исходя из возможностей аналитики, поиска аномалий и предсказаний средствами облачных сервисов типа Log Analytics или Sentinel. И, безусловно – клиенты ждут помощи в миграции в облако и дальнейшей адаптации их традиционных «наземных» решений – этот аспект даже не обсуждается – и если непосредственно миграция уже проведена – чаще всего это вариант с миграцией существующих «наземных» сервисов в виде виртуальных машин IaaS Azure – клиенты ожидают от поставщика Azure Managed Services дальнейших шагов по трансформации такой инфраструктуры в нативные сервисы Azure.

И здесь первая огромная разница между традиционными и облачными Managed Services – заказчик видит в поставщике Azure Managed Services не просто «аутсорсовые руки», которые он будет использовать для выполнения рутинных операций типа «перегрузить виртуальную машину», а именно доверенное лицо, которое в первую очередь предоставляет экспертизу по «движению в облако», причем заказчик ожидает, что получит возможность общения с высококлассным SME (Subject-Matter Expert) по всему возможному спектру сервисов Azure, который обозначен в контракте, и общение между заказчиком и поставщиком услуг будет проходить в стиле знаменитого диалога:

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

Пожалуй, повторюсь по поводу этого пункта, поскольку до многих руководителей «традиционных» Managed Services этот момент доходит, как до того диплодока с очень длинной шеей – в случае с публичным облаком типа Azure заказчик самостоятельно может выполнять большое количество базовых операций – благо, Azure существенно упрощает многие административные рутинные функции и предоставляет отличный инструментарий управления – будь то портал Azure или Azure PowerShell сотоварищи – и это не те местечковые «облака» с банальными виртуальными машинами, которые расплодились за последние 10-15 лет и так и не превратившиеся в настоящие облака, и которые не в состоянии предоставить нормальный инструментарий управления для клиентов и потом все «пляски с бубнами» вокруг каждой виртуальной машины должны выполняться исключительно персоналом провайдера Managed Services. В случае Azure заказчик не нуждается в столь плотной «опеке» и «залоченной» облачной инфраструктуре, к которой имеют доступ только сотрудники поставщика «традиционных» Managed Services – фактически, это создает промежуточное звено во внедрении решений и существенно замедляет процессы – что полностью противоречит задачам облаков – ускорению бизнеса путем быстрой адаптации и развертывания ИТ сервисов. Но Azure продолжает быть достаточно сложным для инженеров заказчика, в ответственность которых входят именно бизнес-сервисы, а не то, как их работа обеспечивается в Azure – потому именно экспертные услуги со стороны поставщика Azure Managed Services и являются главной отличительной чертой «нового» провайдера современных облачных Managed Services.

Вторая отличительная черта поставщика Azure Managed Services – это SLA. Нет, не тот SLA, о котором любят писать провайдеры Managed Services в контрактах – про гарантированное время ответа и восстановления, это в реальности мало кого интересует в облачных сервисах – облако Azure куда стабильнее всех этих «местечковых облачков» – а действительный доказанный SLA конкретных бизнес-сервисов. Именно так – заказчик дает запросы на предоставление требуемого уровня SLA для своих критических сервисов, а поставщик Managed Services – их обеспечивает. И здесь уже в дело вступает первый пункт – поcтавщик услуг Azure Managed Services предоставляет не «руки», а «головы», в задачу которых входит в том числе и совершенствование инфраструктуры заказчика (в рамках контракта Managed Services) для достижения необходимого уровня SLA конкретного критического бизнес-сервиса. Дальше уже исключительно техническая и финансовая часть задачи по достижению требуемого SLA – возможно ли такое технически в рамках Azure и конкретного бизнес-приложения заказчика и готов ли заказчик платить за все «хотелки» для достижения такого SLA. А поскольку в рамках Azure можно «наворотить» многое для достижения требуемой высокой доступности, надежности, защиты от сбоев и восстановления конкретного решения – то задача вполне решаемая для «настоящих» специалистов поддержки (а не L1, который «должен перегрузить ВМ») без особых проблем. Но самое интересное в данном случае с SLA – если само «наследованное» приложение не адаптировано к работе со средствами масштабирования и высокой надежности в Azure и требуется модификация или даже тотальное изменение архитектуры решения. И тут вступает в дело третья, и, по большому счету – самая важная – отличительная черта современного облачного поставщика Managed Services в отличие от «традиционных» Managed Services.

Итак, отличие третье – основные работы современные облачные провайдеры Managed Services выполняют для заказчиков не в рамках «тикетов» на «перегрузку ВМ» или «изменение размера ВМ», а в рамках постоянной адаптации и оптимизации клиентских сервисов в облаке. Рассматривайте это, как продолжительный непрекращающийся разбитый на фазы проект модернизации, внедрения новых компонентов, оптимизации существующих и т.п. Никаких устаревших бизнес-моделей, где в контракте оговорено количество виртуальных машин, сетей и прочего для обслуживания, а все новое – это отдельный «проект по планированию и развертыванию», который выполняют «Professional Services». В случае облачных Azure Managed Services все развитие инфраструктуры в облаке, возможно, с планами на год или даже несколько лет – это задачи и ответственность команды Azure Managed Services. Выглядит очень требовательно? Возможно, но речь не идет о «переписывании» приложений (хотя такие сервисы и предлагаются некоторыми поставщиками услуг облачных Managed Services), а о консультационной работе с разработчиками заказчика и рекомендациях по изменении кода приложения или архитектуры согласно лучшим практикам Microsoft для Azure. Фактически, специалисты из команды Azure Managed Services выступают и постановщиками задачи для разработчиков (совместно с заказчиком) и SME по архитектуре решения, поскольку одна из зон ответственности провайдера Azure Managed Services – это SLA приложений и сервисов и их архитектура должна быть спланирована под задачи соответствия договоренному SLA. А что насчет планирования и внедрения новых сервисов в облаке для заказчика – и это тоже работа команды Azure Managed Services. Во-первых, потому, что любая облачная инфраструктура – это в первую очередь следование лучшим практикам и они говорят о построении решений типа виртуального ЦОД с архитектурой HUB-SPOKE и после построения центрального хаба все дополнительные сервисы подключаются по типовым проектам, как spoke – и «городить» там что-то серьезное, с привлечением «Professional Services», вообще не требуется. А во-вторых – именно команда Managed Services обладает полной актуальной информацией по всей инфраструктуре клиента, возможных дополнительных ограничениях или требованиях, планах по развертыванию других сервисов и многой другой информацией – потому, фактически, проект подобных улучшений или будет связан с длительным процессом передачи знаний между командой Managed Services и командой «архитекторов» Professional Services c последующими согласованиями результатов и т.п. – что делает такой проект существенно громоздким и дорогостоящим, или может быть выполнен командой Managed Services с привлечением необходимых SME по каким-то специфическим решениям как раз из команды Professional Services. Хотя, как показывает опыт работы – инженер L2 Azure Managed Services после года активной работы в среде крупного корпоративного заказчика даст большую фору «архитектору» Professional Services по планированию и внедрению решений в обслуживаемой среде – поскольку имеет практический опыт и куда более глубокое понимание конкретной среды – так что в реальности, по личному опыту – привлечение SME от «Professional Services» вообще не требовалось – все планирование и внедрение новых решений и модернизация существующих для соответствия SLA выполнялись только силами L2 инженеров и L3 архитекторов Azure Managed Services, без привлечения сторонних «экспертов».

И здесь в дело вступает еще одно отличие – для нормального взаимодействия с клиентом требуется постоянный технический диалог, в рамках которого обсуждаются планы и проекты, а клиент может обратиться с соответствующими техническими вопросами типа «А нельзя ли сделать так?» к тому самому SME по Azure, который имеет полное представление об инфраструктуре клиента. И такой диалог должен быть постоянным, регулярным и проактивным со стороны поставщика Azure Managed Services, т.е. – команда Azure Managed Services, которая работает с конкретным заказчиком, должна иметь в своем составе кого-то, кто будет выполнять функции условного «Technical Account Manager» (TAM) для клиента. Практика показывает, что именно L3 support Azure Architect прекрасно справляется с регулярными техническими коммуникациями с заказчиками и является для них тем самым основным SME по Azure, единой точкой контакта по всем техническим вопросам и принимает участие во всех встречах/совещаниях по планированию и развитию инфраструктуры, и, конечно же – лидером команды Azure Managed Services для конкретного заказчика. Данный условный TAM должен обладать полным знанием об инфраструктуре заказчика, быть в курсе планов развития инфраструктуры, выделять и планировать ресурсы команды под будущие проекты и вести текущие проекты с точки зрения технической экспертизы и управления. И, опять же – как показывает практика – от персоналии такого вот TAM во многом зависит успешность работы с конкретным заказчиком, его удовлетворенность сервисом и многое другое. Так что регулярные созвоны пару раз в неделю и работы на опережение (все эти Operational Excellence – про это – в следующей части) очень даже требуется со стороны TAM.

Еще одним различием облачных Managed Services и «традиционных» является «цена вопроса» – переход от «подсчета по головам», т.е. по количеству обслуживаемых виртуальных машин с фиксированной ценой за одну ВМ, к проценту от цены утилизации в облаке. Согласитесь, считать стоимость облачных сервисов по «головам» ВМ, в то время, как одна из задач современных Azure Managed Services – оптимизация инфраструктуры, обеспечение SLA для бизнес-сервисов и приложений – требует модернизации «зашитых» в ВМ приложений в IaaS окружении в сервисы PaaS и что автоматически удаляет ВМ в будущем – крайне странно. Плюс в Azure масса сервисов, которые требуют управления и которые не посчитаешь «по головам». Потому – только процент от утилизации. Опять же – в зависимости от набора предоставляемых в рамках Managed Services услуг процент может варьироваться от 10% до 30% стоимости самих утилизированных ресурсов Azure. Это, ко всему прочему, двигает заказчика более пристально относиться к вопросам стоимости и оптимизации инфраструктуры (что упрощает и внедрение SLA бизнес-сервисов для команды Managed Services), а с другой стороны – Managed Services заинтересована в постоянном развитии инфраструктуры и драйвинге процессов миграции других сервисов заказчика из локальной инфраструктуры в облако. И показатель роста утилизации (и, соответственно, роста стоимости услуг Azure Managed Services) – отличный KPI для новой облачной команды (наряду с обновленным KPI по SLA – только не того, который представляет «непонятные тикеты» ответа, а SLA бизнес-приложений заказчика).

И вот про KPI и прочие шаги, которые надо предпринять провайдеру услуг (типа реализации облачного варианта Operational Excellence) для трансформации «традиционного залоченного» Managed Services в современный облачный/Azure Managed Services – мы поговорим в следующей статье на эту тему.

Продолжение – следует…

интересная серия видео, на которые рекомендую обратить внимание – это “открытое собеседование” на позицию Azure L2 support engineer (попросту “администратор Azure”) – которое поможет вам сориентироваться в требованиях к позиции и оценить свои знания:

  • * ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.01 – https://youtu.be/HmpgQoahXTA
  • * ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.02 – https://youtu.be/cFzd62vlB9M 
  • * ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.03 – https://youtu.be/DECMirInQ2I

Конференция SysAdmin Day.Kharkiv 2018–о чем будем говорить и мое интервью Lenovo в предверии этого интересного ИТ-мероприятия в Харькове 13 июня 2018 года


Article - Topic - LinkedIn

13 июня при поддержке лидеров рынка Lenovo в Украине и Microsoft Ukraine в Харькове состоится яркая IT-конференция SysAdmin Day 2018. На этой конференции я выступаю, как эксперт по ИТ-инфраструктуре и буду рассказывать про миграцию в облака средних и малых предприятий, а также про использование облачных сервисов для управления локальными и мобильными устройствами и защитой данных. Также меня попросили дать небольшое интервью о тех перспективах и особенностях применения облачных технологий, которые современные технологии предоставляют для средних и малых компаний, а также – для карьеры системных администраторов.

Первый мой доклад на SysAdmin Day.Kharkiv 2018 будет называться “Стратегия миграции инфраструктуры малых и средних предприятий в облачные сервисы”. Вкратце об этом докладе смотрите в трейлере к докладу:

Второй доклад на SysAdmin Day.Kharkiv 2018 будет посвящен управлению мобильными устройствами и безопасностью и называтеся “Использование облачных сервисов Microsoft для управления локальными и мобильными устройствами, управление безопасностью данных в облаке и на мобильных устройствах”. И также предлагаю ознакомиться с трейлером к докладу:

 

И, собственно, возвращаемся к интервью для Lenovo в Украине:

  1. Что на сегодняшний день нужно IT-специалисту, системному администратору, чтобы развивать карьеру? В одном из видео вы перечисляли три must have пункта: подтвержденные знания в профессии, практический опыт и умение на простом языке доносить свои идеи потенциальным заказчикам. Хотелось бы подробнее об этом узнать.
    1. Я думаю, что подробнее рассказать об это в рамках данной беседы не получится – ведь мне для раскрытия этого вопроса понадобилось минимум 5 видео с длительность по 30 минут каждое. Могу просто порекомендовать всем посмотреть внимательно серию этих видео про ИТ-карьеру у меня на канале:

  2. На сегодняшний день в сфере IT огромная скорость изменений. Не теряют ли актуальность полученные сертификаты? Как часто IT-специалисту имеет смысл подтверждать свои знания сертификацией?
    1. Честно говоря, сейчас переломный момент именно для ИТ-специалистов (не путать с разработчиками) – технологии управления ИТ-инфраструктурой меняются кардинально ввиду развития облаков и, вполне возможно, в ближайшие 3-5 лет от ИТ специалистов будут требовать совсем другие навыки. Потому мои собственные предпочтения в этой области – сначала знания и навыки, потом экзамены (обычно, это требуется только работодателю) и мой ответ на подобный вопрос – «могу запросто доказать, что я обладаю более широкими знаниями, чем требует сертификация, а если вам нужен именно сертифицированный специалист, чтобы получить какой-то партнерский статус – сдам экзамен сразу, как только вы это оплатите»
  3. Как быть в ситуации, когда знания есть, идеи есть, а заказчика на их разработку нет? Какие есть возможности реализовать свои знания в практических проектах?
    1. Мир сейчас стал очень маленьким, поэтому не проблема найти нужный проект на том же портале Upwork, особенно, если устроить демпинг с ценами. Там попадаются иногда очень «креативные» запросы по скрещиванию бульдога с носорогом, сейчас, качественно и дешево 😉
  4. Умение переводить свои IT-знания и идеи на общечеловеческий язык и язык бизнеса — это врожденный талант, или его можно освоить? Как этого добиться?
    1. Работать над собой, понимать, что люди совершенно разные и людям не интересно копаться в настройках также, как это интересно вам. Людям (не обязательно бизнесу) свойственно мышление «черного ящика» – «делаю вот это с одной стороны, с другой стороны – получаю результат». Потому, разговаривая с людьми или бизнесом – представляйте себя магом (можно темным злым колдуном) – не надо рассказывать, как работает заклинание, просто показывайте результат, который людям будет полезен.
  5. За какими ресурсами и событиями нужно следить IT-специалисту, чтобы постоянно оставаться в курсе происходящего в сфере? Где получать свежие идеи и знания? Какие сайты, каналы, офлайн-мероприятия и конференции вы можете посоветовать?
    1. Если мы говорим о русскоязычных ресурсах (а с украиноязычными вообще все плохо) – то наблюдается тенденция их критического сокращения. Все больше специалистов уезжает в Европу и США, все меньше рынок (кол-во смотрящих) для таких ресурсов – потому ИТ-специалисту, который хочет развиваться, придется учить английский и работать с англоязычными ресурсами. Такими, как, например, Microsoft Virtual Academy – https://mva.microsoft.com/ – сборником виртуальных учебных курсов и теми же бесплатными книгами и учебными пособиями – https://mva.microsoft.com/ebooks/ . Лично я тоже стараюсь внести свой вклад в развитие ИТ-специалистов бывшей родины – периодически выпуская обзорные и технические видеоматериалы у себя на YouTube канале – http://bit.ly/WindowsServer_overview . Что же касается регулярного обновления знаний – то тут очень хорошо подойдут блоги компаний-разработчиков тех продуктов, которыми вы пользуетесь. Так, например, свежие новости про технологии Azure, связанные с ним события и прочее я читаю на https://azure.microsoft.com/en-us/blog/ . И, конечно же, профессиональные социальные сети – например, LinkedIn – главное, правильно выбирать контакты, ленту которых будешь читать. Опять же, лично я стараюсь на LinkedIn давать выборку интересных мне новостей – https://www.linkedin.com/in/iwalker2000/ – желающие могут подписываться (рекрутеров без конкретных предложений – не приглашаю).
  6. Расскажите о конференции SysAdmin Day, где вы будете участвовать. Почему IT-специалистам стоит туда ехать (кроме обширной фановой программы J) Что они смогут вынести оттуда?
    1. В своих докладах я всегда стараюсь дать стратегическую перспективу развития того или иного продукта или направления. Сейчас, как я уже говорил ранее – переломный момент в развитии навыков и умений системных администраторов. В своем недавнем докладе на Стальном Бубне я уже рассказывал про то, какие навыки необходимы системному администратору в будущем. На SysAdmin Day я продолжу эту тенденцию, и расскажу, как облачные технологии и сервисы критически изменяют работу ИТ-специалистов.
  7. Большинство из тем, заявленных на SysAdmin Day, касаются облачного хранения данных. Почему эта тема приобретает такую популярность? Каковы тенденции в этой сфере? Не случится ли, что популярность достигнет пика и схлынет, сервисы закроются и придется искать новые решения?
    1. Я бы не сказал, что именно облачного хранения данных, скорее, мы будем говорить про то, как облачные сервисы позволяют эффективно решать вопросы обмена данными, резервного копирования и даже защиты от сбоев целой инфраструктуры. Именно сценарии защиты от сбоев начинают приобретать широкую популярность, поскольку позволяют быстро стартовать копии всех ваших серверов в облаке с актуальными данными в случае сбоя питания, катастрофы, изъятия всего парка оборудования. Что же касается закрытия сервисов – это облака – это новый тренд в индустрии, который будет актуален лет 20 минимум. Просто выбирайте правильного поставщика сервисов, например, Microsoft Azure.
  8. Что касается гибридных решений: какое расширение функций дает дополнительное использование облачных сервисов, вдобавок к локальным хранилищам? Каким бизнесам больше подходит гибридный вариант, а каким — полный переход в облако?
    1. Я бы не говорил об облаках, как о хранилищах. Да, резервное копирование и защита от сбоев, которые мы уже обсудили ранее – одна из наиболее востребованных функций облаков для гибридной работы. Но – облака интересны тем, что вы можете вынести туда (стартовать там) те функции, которые ранее обслуживались локально – так, облачный пакет офисных сервисов Office 365 включает в себя облачный Exchange, SharePoint, AD, OneDrive, а в Azure присутствуют сервисы управления безопасностью мобильных устройств Intune, защиты данных на платформе RMS – Azure Information Protection, сервисы мониторинга серверов OMS и антивирусной безопасности Defender Advanced Threat Protection – про их применение я и буду рассказывать в своих докладах. Что же касается перехода в облако или гибридных сценариев – то тут много нюансов, про которые можно говорить часами, но базовые концепции, которым обязательно надо следовать, готовя проект миграции в облако – я изложу в своих докладах. Также материалы по сценариям миграции есть у меня на канале среди технических докладов, и особенно хочу обратить внимания тех, кто уже сейчас планирует миграцию в облака, на доклад «Первые 15 шагов по переходу в облака – что сделать до того, как мы залогинимся в портал AZURE» –  рекомендуется просмотреть еще до начала проекта по миграции в облака.
  9. Насколько безопасно облачное хранение данных?
    Защищена ли информация от несанкционированных проверок, взлома, слива данных третьим лицам?
    Стоит ли опасаться «ковровых» блокировок, вроде истории с Телеграммом, когда за компанию с мессенджером пострадал огромный кусок интернета.
    Есть ли у облачных провайдеров услуги защиты от ДДОС?
    Что происходит с данными, если сервер облачного хранилища отключился или поврежден? Куда они перемещаются?
    Какие предусмотрены способы защиты на случай падения связи? Есть ли резервные каналы для таких ситуаций?
    1. Тема слишком обширна и пересекается с моими докладами. Вкратце могу сказать, что все инструменты для защиты от несанкционированного доступа к вашим данным в том же Azure есть – и по умолчанию, и расширенный набор – про тот же Azure Site Recovery я уже упоминал выше. Защита данных при отказе серверов самого облака обеспечивается тем планом, который вы выбрали для хранения – готовы ли вы платить за репликации данных внутри одного ЦОД облака или даже между разными континентами. За канал связи с вашей стороны, понятно, отвечаете вы сами. Но существуют также и продукты, обеспечивающие кеширование и репликацию локальных хранилищ в облако, что позволяет работать с такими данными в оффлайн режиме.
  10. По каким критериям бизнесу нужно выбирать облачного провайдера? Какие провайдеры есть сейчас в Украине? На что обратить внимание, составляя договор с провайдером о предоставлении данных, чтобы обеспечить их максимальную защиту?
    1. Критерии выбора облачного провайдера очень и очень обширны и это тема для отдельного разговорам минимум на 30 минут. Вкратце – это бизнес-здоровье компании и ее позиция на рынке, административная поддержка и SLA, технологии, которые требуются вам и предоставляются провайдером, безопасность и доверие к провайдеру и т.п. В Украине нет облачных провайдеров в полном смысле этого слова – фактически, это обычные хостеры, предоставляющие услуги виртуальных машин и IaaS (Infrastructure as a Service) с консолями управления для клиентов – и даже называть, а тем более сравнивать данные «облака» с настоящими публичными облаками типа Microsoft Azure – нельзя. Но, сейчас, с появлением такого продукта, как Microsoft Azure Stack – позволяющего «приземлить» большую часть возможностей Azure, которые и делают облако «облаком», на серверах локального провайдера – некоторые из провайдеров начали двигаться в направлении «настоящих облаков», а не просто хостинга виртуальных машин. Хотите понять, перед вами «просто хостер» или действительно «облачный провайдер» – задайте специалистам данной компании простой вопрос – а какие шаблоны описания облачных инфраструктур поддерживаются данным провайдером, например, формата ARM templates? Какие сервисы вы получаете для размещения ваших нагрузок – виртуальные машины, сервисные фабрики, базы данных, средства автоматизации? Есть ли у провайдера механизмы автоматического масштабирования выбранных вами сервисов – scale up/scale out? В 99% случаев вы услышите ответ – вы будете использовать наши «гибкие» виртуальные машины, которые сами настроите из предоставленных образов.
  11. Предоставляют ли облачные провайдеры услуги системного администрирования и начальной развертки серверов для компаний, которые только что сформировались и в принципе не знакомы с облаками? Есть ли решения “под ключ” для таких компаний?
    1. Вообще-то, если говорить о «настоящем облаке», то все эти «услуги по развертыванию» не требуется. Современная парадигма облаков и новый подход к администрированию таких систем не требует интенсивного вмешательства в управление и опирается на декларативные описания инфраструктур, что позволяет развертывать целые инфраструктуры одним кликом на взятый из магазина решений шаблон – про это я как раз и рассказывал в своем предыдущем докладе про новые принципы работы администраторов. Если компания все же хочет разработать подобный шаблон «под себя», то для этого существует достаточно обширное предложение по консалтингу – собственно, компания, которую я возглавляю, и занимается таким консалтингом. Кроме того, я лично провожу тренинги по данному направлению нового администрирования, если требуется в проекте иметь команду уже подготовленных специалистов, которые готовы будут обслуживать и развивать инфраструктуру после сдачи проекта.
  12. В прошлом году инновационные решения для ЦОД Lenovo были названы лучшими по 46 показателям. Какие серверные решения этого бренда можно рекомендовать малому и среднему бизнесу, и почему?
    1. Я бы начал с того, что мало кто знает, что Microsoft сертифицировала Lenovo среди нескольких производителей серверов, как поставщика оборудования для решений Microsoft Azure Stack – копии облака Azure для локальных провайдеров – https://www3.lenovo.com/us/en/data-center/ThinkAgile-SX-for-Microsoft-Azure-Stack/p/WMD00000272 . Это говорит об очень высоком уровне надежности и производительности серверных решений Lenovo, а также о том, что в проектировании своих серверов серии ThinkAgile Lenovo опирается на самые современные аппаратные технологии, которые использует и Microsoft для построения ЦОД «большого облака» Azure. Такая сертификация – высочайший знак качества аппаратной серверной платформы от Lenovo. Что же касается «обычных» серверов, то мне сложно выделить какую-то модель из линейки Lenovo ThinkServer – тут стоит правильно учитывать потребности компании и задачи при выборе серверов, особенно, с учетом того, что часть инфраструктуры может быть вынесена в сервисы облака. И на что бы я еще обратил пристальное внимание компаний, которые планируют миграцию в облака – это на то, что с переносом сервисов в облака – «на земле» остается клиентская часть, и здесь у Lenovo есть великолепная линейка надежных производительных тонких (и не очень) клиентов серии Tiny – ThinkCentre Tiny/ThinkCentre Thin Client и ThinkStation Tiny – которые позволят компании эффективно трансформировать рабочие места для работы с облаками.

Обязательно к прочтению и изучению для тех систеных администраторов, которые планируют развивать свою карьеру – и не только в направлении облаков – SysAdmin vs DevOps–что разного и что общего–будущее системных администраторов на примере автоматизации развертывания и конфигурирования VM в Azure–Infrastructure as Code и инструменты DevOps, которыми сисадмин должен будет владеть в ближайшем будущем

 

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

 

Видео об ИТ-карьере – как стать ИТ-специалистом и заработать много денег:

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

И смотрите другие видео для ИТ-специалистов у меня на канале:

Видео про новые возможности дисков и дисковых массивов:

 

Подписывайтесь на мой Youtube канал iWalker2000 – для подписки просто кликните сюда

 

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

 

Эмиграция для ИТ-профессионалов в Европу! Оформление ВНЖ в Словакии, возможность работы со всеми странами ЕС, открытие фирм, ЧП с соответствующими видами деятельности, оформление документов для членов семьи. Быстро, качественно, дешево и абсолютно легально ВНЖ в Словакии. www.slovakiago.com
Не упустите свой шанс жить и работать в Евросоюзе!

Видео обзор обновлений облачного сервиса хранения данных Microsoft SkyDrive…


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

Уважаемые нынешние пользователи SkyDrive, которые создали свои учетные записи на Microsoft SkyDrive до 22 апреля 2012 года – большая к вам просьба – не забудьте себе расширить хранилища до "старых" 25ГБ пространства хранилища, это предлагается сделать вам бесплатно, но предложение ограниченно по времени. Иначе вы останетесь с теми безплатними 7ГБ, которые сейчас по умолчанию предлагаются новым пользователям.

Как увеличить объем хранилища SkyDrive с 7ГБ до 25ГБ – смотрите в самом начале видео, представленного ниже. Кстати, для тех, у кого объем хранимых даннях на SkyDrive превышал 4ГБ на момент обновления сервисов SkyDrive – обновление к дополнительным 25ГБ произойдет автоматически.

Обзор новых возможностей облачного сервиса хранения данных Microsoft SkyDrive

Также в видео вы увидите обзор нового клиентского приложения Microsoft SkyDrive, которое предлагает пользователям Windows и Mac OS X новые интересные функции:

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

Кроме того, в видео представлено сравнение новой утилиты SkyDrive с уже существующей утилитой Windows Live Mesh (обзор предыдущей версии Live Mesh смотрите тут), которая также работает со SkyDrive – какие плюсы и минусы возможностей использования каждой из них со SkyDrive, а также – обзор новой версии утилиты SkyDrive для Windows Phone 7.5

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