Облачные 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 – будет третья часть данной статьи.

Напишіть відгук

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out /  Змінити )

Google photo

Ви коментуєте, використовуючи свій обліковий запис Google. Log Out /  Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out /  Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out /  Змінити )

З’єднання з %s