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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


#практик #DevOps #для #повышения #надежности #приложений

Source link