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

А когда инциденты влияют на производительность, стабильность и надежность, могут ли они быстро определить основную причину и решить проблемы с минимальным влиянием на бизнес?

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

А как насчет служб управления данными и аналитики, которые работают в общедоступных и частных облаках? Как ИТ-специалисты получают оповещения, просматривают сведения об инцидентах и ​​решают проблемы, связанные с интеграцией данных, dataops, озера данных и т. д., а также модели машинного обучения и визуализации данных, которые развертывают специалисты по данным?

Это ключевые вопросы для ИТ-руководителей, развертывающих больше приложений и аналитики в рамках цифровые преобразования. Кроме того, как Команды DevOps обеспечивают более частое развертывание при использовании CI / CD и автоматизации инфраструктуры как кода (IaC) вероятность того, что изменения вызовут сбои, возрастает.

Что должны делать разработчики, специалисты по обработке данных, инженеры по обработке данных и ИТ-специалисты, чтобы повысить надежность? Должны ли они отслеживать приложения или повышать их наблюдаемость? Являются ли мониторинг и наблюдаемость двумя конкурирующими реализациями, или их можно развернуть вместе, чтобы повысить надежность и сократить среднее время разрешения инцидентов (MTTR)?

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

Разработайте единый источник операционной правды между разработчиками и операторами

В течение последнего десятилетия ИТ-специалисты пытались сократить разрыв между разработчиками и производителями с точки зрения мышления, целей, ответственности и инструментов. Девопская культура и изменения процессов лежат в основе этой трансформации, и многие организации начинают этот путь с внедрения Конвейеры CI / CD и IaC.

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

Мохан Компелла, вице-президент по маркетингу продуктов BigPanda, соглашается, отмечая важность разработки единого оперативного источника истины. «Agile-разработчики и команды DevOps используют свои собственные разрозненные и специализированные инструменты наблюдения для глубокой диагностики и криминалистической экспертизы, чтобы оптимизировать производительность приложений», – говорит он. «Но в процессе они могут потерять видимость в других областях инфраструктуры, что приведет к выявлению пальцем и методам проб и ошибок при расследовании инцидентов».

Решение? «Становится необходимым расширить ориентированную на приложения видимость разработчиков за счет дополнительной 360-градусной видимости сети, хранилища, виртуализации и других уровней», – говорит Компелла. «Это устраняет трение и позволяет разработчикам быстрее устранять инциденты и простои».

Понять, как проблемы с приложениями влияют на клиентов и бизнес-операции

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

Джаред Блитцштейн, технический директор компании Boomi, подразделение Dell Technologies, подчеркивает, что контекст клиента и бизнеса имеет ключевое значение для разработки стратегии. «Мы сосредоточили внимание на наших клиентах и ​​их способности собирать информацию и действия, необходимые для работы своего бизнеса», – говорит он. «Разница в том, что мы используем мониторинг, чтобы понять, как наши системы ведут себя в определенный момент времени, но используем концепцию наблюдаемости, чтобы понять контекст и общее влияние, которое эти элементы (и другие) оказывают на бизнес наших клиентов».

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

Улучшение телеметрии с помощью мониторинга и наблюдения

Если вы уже отслеживаете свои приложения, что вы получите, добавив к этому миксу наблюдаемость? В чем разница между мониторингом и наблюдением? Я задал эти вопросы двум экспертам. Ричард Уайтхед, главный евангелист в Moogsoft, предлагает такое объяснение:

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

И Крис Фаррелл, стратег по наблюдению в компании Instana, компания IBM, пролила дополнительный свет на разницу:

Наблюдаемость – это не просто получение данных о приложении, это понимание того, как связаны различные фрагменты информации о вашей прикладной системе, будь то метрики из мониторинга производительности, распределенной трассировки пользовательских запросов, событий в вашей инфраструктуре или даже профилировщиков кода. Чем лучше платформа наблюдения понимает эти отношения, тем эффективнее становится любой анализ на основе этой информации, будь то внутри платформы или нижестоящий поток, используемый инструментами CI / CD или платформой AIops.

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

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

Автоматизировать действия для реагирования на отслеживаемые и наблюдаемые проблемы

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

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

«Собирайте, объединяйте и анализируйте самые разные источники данных, чтобы получить ценную информацию и помочь ИТ-командам понять, что на самом деле происходит в сложных гибридных облачных средах», – говорит Ребело. Но этого мало.

«Очень важно связать эти идеи с автоматизацией для преобразования ИТ-операций», – добавляет Ребело. «Сочетание автоматизации с наблюдаемостью и AIops является ключом к максимальному увеличению ценности аналитических данных и преодолению растущей сложности ИТ-сред сегодня».

Оптимизация мониторинга и наблюдения за доставкой потока создания ценности

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

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

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

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

Авторские права © 2021 IDG Communications, Inc.


#Как #повысить #надежность #приложения #помощью #наблюдаемости #мониторинга

Source link