`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Облачные Managed Services — часть 2 — технологические отличия от «традиционных» Managed Services

+11
голос

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

Облачные Managed Services — часть 2 — технологические отличия от «традиционных» 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 дня:

Облачные Managed Services — часть 2 — технологические отличия от «традиционных» Managed Services

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

+11
голос

Напечатать Отправить другу

Читайте также

 
 

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT