Продолжаю тему «цифровой трансформации» в отношении к современным облачным 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 дня:

А дальше – выполняя такие запросы по расписанию (и помним о цене запроса) и оценивая тенденции или находя аномалии – запускаем в случае критических показателей требуемые скрипты 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 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 — 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 – будет третья часть данной статьи.

* Больше технических статей и постов на 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