Как и почему подход «Разработчик прежде всего» меняет ландшафт наблюдаемости

​Разработчики играют решающую роль в современных компаниях. Узнайте от специалистов компании DST Global больше о необходимости подхода, ориентированного на разработчиков, и обеспечения наблюдаемости с первого дня.
Разработчики играют решающую роль в современных компаниях. Если мы хотим, чтобы наш продукт был успешным, нам необходимо использовать подход, ориентированный на разработчиков, и обеспечить возможность наблюдения с первого дня. Читайте дальше, чтобы понять, почему.
Мир изменился
За последнее десятилетие многое изменилось. В нашем стремлении к большей масштабируемости, устойчивости и гибкости в цифровой инфраструктуре нашей организации произошел стратегический поворот от традиционных монолитных архитектур приложений к использованию современных методов разработки программного обеспечения, таких как архитектура микросервисов в сочетании с облачными приложениями. Этот сдвиг подтверждает, что в сегодняшнем быстро меняющемся технологическом ландшафте создание изолированных и независимо развертываемых сервисов дает значительные преимущества по сравнению с наследием переплетенных кодовых баз, характерных для монолитных систем.
Более того, приняв облачные принципы, адаптированные для общедоступных или гибридных облачных сред, мы еще больше оптимизировали процесс разработки и доставки наших приложений, обеспечивая при этом оптимальное использование ресурсов с помощью инструментов оркестрации контейнеров, таких как Kubernetes, которые облегчают масштабируемые шаблоны развертывания, такие как горизонтальное масштабирование для соответствия колебания спроса. Этот сдвиг парадигмы не только позволяет нам более эффективно использовать облачные ресурсы, но также поддерживает культуру DevOps , создавая среду, в которой непрерывная интеграция и доставка становятся неотъемлемыми компонентами, ускоряющими вывод на рынок новых функций или усовершенствований, соответствующих нашим бизнес-целям.
Чтобы справиться с быстро меняющимся миром, мы изменили наш подход, чтобы уменьшить сложность развертывания; они стали частыми ежедневными задачами, а не редкими сложными событиями, благодаря переходу от трудоемких ручных процессов к оптимизированным конвейерам CI/CD и созданию инструментов развертывания инфраструктуры. Этот переход существенно усложнил системную архитектуру в различных аспектах, включая, помимо прочего, инфраструктуру, настройки конфигурации, протоколы безопасности, интеграцию машинного обучения и т. д., где мы приобрели навыки управления этими сложностями посредством наших развертываний.
Тем не менее, сложная сложность баз данных не была решена должным образом ; оно резко возросло, поскольку каждое приложение теперь использует несколько типов баз данных — от систем SQL и NoSQL до специализированных настроек для конкретных задач, таких как машинное обучение или расширенные операции векторного поиска, из-за регулярных частых развертываний. Поскольку эти изменения часто внедряются асинхронно, изменения в схеме баз данных или фоновых заданиях могут произойти в любое время без предупреждения, что оказывает каскадное влияние на проблемы с производительностью во всех наших взаимосвязанных системах.
Это не только напрямую влияет на бизнес, но и усложняет усилия разработчиков и DevOps-инженеров, которым не хватает опыта для устранения этих проблем, связанных с базами данных, в одиночку, что требует внешней помощи со стороны экспертов по эксплуатации или специализированных администраторов баз данных (администраторов баз данных). Отсутствие автоматизированных решений делает процесс уязвимым из-за зависимости от ручного вмешательства . Раньше мы возлагали бремя повышенной сложности на специализированные команды, такие как администраторы баз данных или операторы. К сожалению, это больше невозможно. Сложность развертываний и приложений значительно возросла из-за сотен баз данных и сервисов, которые мы развертываем каждый день. Сегодня мы сталкиваемся с мультитенантными архитектурами с сотнями баз данных, тысячами бессерверных приложений и миллионами изменений, проходящих через конвейеры каждый день. Даже если бы мы захотели справиться с этой сложностью с помощью специализированных команд администраторов баз данных или инженеров DevOps, это просто невозможно.
Думать, что это не имеет отношения к основным бизнес-приложениям, очень далеко от истины. Давайте читаем дальше, чтобы понять, почему.
Разработчики оценивают ваш бизнес
Многие компании осознали, что оптимизация работы разработчиков неизбежно приносит многочисленные выгоды всей компании. Это происходит в основном по двум причинам: улучшение производительности и новые домены.
Автоматизация в областях разработки может значительно сократить MTTR и повысить скорость. Все бизнес-проблемы современного мира должны решаться с помощью цифровых решений, которые в конечном итоге разрабатываются и поддерживаются разработчиками. Если разработчики останутся далеко от конца воронки, это приведет к более высокому MTTR, большему количеству ошибок и более длительному устранению неполадок. С другой стороны, если мы реорганизуем среду, чтобы позволить разработчикам работать быстрее, они могут напрямую повлиять на все организационные показатели. Поэтому наша цель — вовлечь разработчиков во все действия и максимально сместить влево. Ставя больше задач непосредственно командам разработчиков, мы влияем не только на технические показатели, но и на бизнес-KPI и OKR, ориентированные на клиентов.
Вторая причина — появление новых областей, особенно связанных с машинным обучением. Решения искусственного интеллекта существенно меняют наш сегодняшний мир. Благодаря большим языковым моделям, системам рекомендаций, распознаванию изображений и интеллектуальным устройствам мы можем создавать более качественные продукты и быстрее решать проблемы наших клиентов. Однако ИИ меняется настолько быстро, что только разработчики могут справиться с этой сложностью. Это требует от разработчиков понимания не только технической стороны решений искусственного интеллекта, но и знаний предметной области бизнеса, над которым они работают. Разработчикам необходимо знать, как создавать и обучать системы рекомендаций, а также почему эти системы рекомендуют конкретные продукты и как работают общества. Это превращает разработчиков в экспертов в области социологии, политики, экономики, финансов, коммуникации, психологии и любой другой области, где ИИ приносит пользу.
Обе эти причины приводят к тому, что разработчики играют решающую роль в управлении нашим бизнесом. Времена, когда разработчики просто брали свои задачи с доски Jira, давно прошли. Разработчики не только ведут бизнес от начала до конца, но и эффективность бизнеса во многом зависит от производительности разработчиков. Поэтому нам необходимо изменить наши решения, чтобы они были более ориентированы на разработчиков, чтобы снизить среднее время восстановления, повысить скорость и дать разработчикам возможность двигаться быстрее.
Разработчики все чаще выступают за экосистему, в которой каждый компонент, от изменений конфигурации до процессов развертывания, инкапсулирован в код — философия, известная как инфраструктура как код (IaC). Такой подход не только упрощает настройку, но и обеспечивает согласованность в различных средах. Переход к полной автоматизации еще больше подчеркивает эту тенденцию; Разработчики заинтересованы в реализации конвейеров непрерывной интеграции и доставки, которые автоматически создают, тестируют и развертывают программное обеспечение без вмешательства человека, когда это возможно. Они верят в необходимость устранения ручных действий, чтобы уменьшить количество ошибок, вызванных человеческим фактором или недосмотром, и ускорить общий цикл разработки. Более того, они стремятся к тому, чтобы эти автоматизированные процессы были настолько прозрачными и обратимыми, насколько это необходимо, позволяя разработчикам быстро получать обратную связь при возникновении проблем на этапах тестирования, а также гарантировать, что любой откат может произойти беспрепятственно, если это необходимо из-за неудачного развертывания или неожиданного поведения в производственных средах. В конечном счете, цель — эффективный, устойчивый к ошибкам рабочий процесс, в котором код не только определяет функциональность, но также управляет изменениями инфраструктуры и протоколами автоматизации — концепция разработки, в значительной степени зависящая от программного обеспечения для своих операционных нужд, а не от традиционных ручных процессов.
Разработчики критически оценивают каждый инструмент, находящийся в их компетенции — будь то платформы для управления инфраструктурой, такие как Puppet или Chef, системы непрерывной интеграции, такие как Jenkins, среды развертывания, включая Kubernetes, решения для мониторинга (возможно, Prometheus или Grafana) или даже приложения искусственного интеллекта и машинного обучения. Они исследуют, насколько удобен в обслуживании продукт: может ли он обрабатывать частые обновления без простоев? Позволяет ли его архитектура легко обновляться до более новых версий с минимальными изменениями конфигурации, требуемыми самими разработчиками? Уровень автоматизации, встроенный в эти продукты, становится в центре внимания: автоматически ли обновления или изменения запускают задачи, оптимизируя рабочие процессы и уменьшая необходимость ручного вмешательства в рутинные операции по техническому обслуживанию?
Помимо простой функциональности, насколько хорошо он интегрируется в существующие конвейеры? Легко ли доступны его API, чтобы разработчики могли при необходимости расширять возможности с помощью пользовательских сценариев? Например, интеграция инструментов мониторинга в процессы CI/CD для автоматического оповещения в случае сбоя или отката выпуска из-за критических проблем является важной функцией, которую оценивают опытные разработчики, которые понимают каскадные последствия простоев в современной взаимосвязанной цифровой инфраструктуре.
Их внимание сосредоточено не только на немедленной полезности, но и на перспективности: они ищут системы, конструкция которых предполагает рост, как с точки зрения сложности инфраструктуры, так и с точки зрения огромного объема данных, обрабатываемых инструментами мониторинга или приложениями искусственного интеллекта, развернутыми в их стеках, гарантируя, что то, что сегодня может быть передовым, остается жизнеспособным на долгие годы. Разработчики стремятся не только создавать продукты, но и курировать компоненты экосистемы, предназначенные для бесперебойного обслуживания с минимальным ручным вводом, необходимым для выполнения повседневных задач, и одновременно максимизируя производительность с помощью интеллектуальных встроенных механизмов, которые прогнозируют, предотвращают или быстро устраняют проблемы.
Разработчики играют важную роль в формировании технологий внутри организаций , сотрудничая с командами на разных уровнях — менеджментом, разработкой платформ и высшим руководством — чтобы представить свои выводы, предлагаемые улучшения или инновационные решения, направленные на повышение эффективности, безопасности, масштабируемости, удобства пользователей и т. д. или другие критические факторы. Такое сотрудничество имеет решающее значение для обеспечения тесного соответствия технологических стратегий бизнес-целям и одновременного использования опыта разработчиков в создании и обслуживании программного обеспечения. Активно обмениваясь своими идеями посредством структурированных встреч, таких как обзоры кода, ежедневные стендапы, ретроспективы или специальные стратегические сессии, они помогают принимать обоснованные решения на всех уровнях руководства для более надежной технологической экосистемы, которая способствует успеху бизнеса. Это говорит о том, что для достижения успеха системы должны помнить о разработчиках.
Ваша система должна быть прежде всего разработчиком
Компании все чаще переходят на платформенные решения, чтобы повысить скорость своей работы, что позволяет ускорить циклы разработки и сократить время выхода на рынок. Используя интегрированные инструменты и услуги, платформенные решения оптимизируют рабочие процессы, уменьшают сложность управления несколькими системами и способствуют более тесному сотрудничеству между командами. Такой консолидированный подход позволяет компаниям ускорять инновации, быстро реагировать на изменения рынка и более эффективно приносить пользу клиентам, в конечном итоге получая конкурентное преимущество в быстро меняющейся бизнес-среде. Однако для повышения скорости работы решения должны быть ориентированы на разработчиков .
Давайте посмотрим на несколько примеров продуктов, в которых приоритет отдается разработчикам. Первое — это облачные вычисления. Ручное развертывание осталось в прошлом . Разработчики теперь предпочитают управлять всем как кодом, обеспечивая повторяемые, автоматизированные и надежные развертывания. Облачные платформы приняли этот подход, предлагая ориентированные на код механизмы для создания инфраструктуры, мониторинга, вики-сайтов и даже документации. Такие решения, как AWS CloudFormation и Azure Resource Manager, позволяют разработчикам представлять состояние системы в виде кода, который они могут легко просматривать и изменять с помощью предпочитаемых ими инструментов.
Другим примером являются внутренние платформы разработчиков (IDP), которые позволяют разработчикам самостоятельно создавать и развертывать свои сервисы . Разработчикам больше не нужно координировать свои действия с другими командами для создания инфраструктуры и конвейеров. Вместо этого они могут автоматизировать свои задачи посредством самообслуживания, устраняя зависимость от других. Задачи, которые раньше требовали ручного ввода от нескольких команд, теперь автоматизированы и доступны через самообслуживание, что позволяет разработчикам работать более эффективно.
Еще один пример — инструменты искусственного интеллекта. Искусственный интеллект значительно повышает эффективность разработчиков за счет плавной интеграции с их инструментами и рабочими процессами. Автоматизируя повторяющиеся задачи, такие как генерация кода, отладка и тестирование, ИИ позволяет разработчикам больше сосредоточиться на творческом решении проблем и инновациях. Инструменты на базе искусственного интеллекта также могут предоставлять предложения в режиме реального времени, обнаруживать потенциальные проблемы до того, как они станут проблемами, и оптимизировать производительность кода — и все это в среде разработки. Такая интеграция не только ускоряет процесс разработки, но и повышает качество кода, что приводит к более быстрому и надежному развертыванию и, в конечном итоге, к более продуктивному и эффективному циклу разработки. Многие инструменты (особенно в Microsoft) теперь оснащены помощниками искусственного интеллекта, которые упрощают работу разработчиков.
Наблюдаемость 2.0 спешит на помощь
Мы увидели пару решений, учитывающих опыт разработчиков. Давайте теперь посмотрим на пример области, в которой отсутствует такой подход — мониторинг и базы данных.
Системы мониторинга часто отдают приоритет необработанным и общим метрикам, поскольку они легко доступны и применимы в различных системах и приложениях. Эти метрики обычно включают данные, которые можно измерить универсально, например использование ЦП или потребление памяти. Независимо от того, использует ли приложение много ресурсов ЦП или памяти, эти основные метрики всегда доступны. Аналогичным образом, такие показатели, как сетевая активность, количество открытых файлов, количество процессоров и время выполнения, можно последовательно отслеживать в различных средах.
Проблема с этими показателями заключается в том, что они слишком общие и не дают глубокого понимания. Например, может наблюдаться всплеск загрузки ЦП, но что это значит? Или, возможно, приложение потребляет много памяти — это указывает на проблему? Без более глубокого понимания приложения сложно интерпретировать эти показатели осмысленно.
Еще одним важным моментом является определение того, сколько метрик нужно собирать и как их группировать . Простого отслеживания «использования ЦП» недостаточно: нам необходимо классифицировать показатели на основе таких факторов, как тип узла, приложение, страна или другие соответствующие параметры. Однако этот подход может создать проблемы. Если мы объединим все показатели под одной меткой «ЦП», мы можем пропустить критические проблемы, затрагивающие только часть источников. Например, если у вас 100 хостов и только на одном из них наблюдается всплеск загрузки ЦП, это не будет заметно в агрегированных данных. Хотя такие показатели, как p99 или tm99, могут дать больше информации, чем средние значения, они все равно не соответствуют действительности. Если на каждом хосте в разное время наблюдается всплеск загрузки ЦП, эти метрики могут не обнаружить проблему. Когда мы осознаем эту проблему, мы можем попытаться собрать дополнительные измерения, создать больше информационных панелей для различных подмножеств и установить пороговые значения и сигналы тревоги для каждого из них индивидуально. Однако такой подход может быстро привести к получению огромного количества метрик.
Существует несоответствие между тем, чего хотят разработчики, и тем, что евангелисты или архитекторы считают правильным. Архитекторы и руководители высшего звена продвигают решения для мониторинга, которые разработчики просто терпеть не могут . Решения для мониторинга просто неправильны, потому что они заваливают пользователей необработанными данными вместо того, чтобы предоставлять тщательно подобранные агрегаты и действенные идеи. Чтобы улучшить ситуацию, решениям для мониторинга необходимо перейти на наблюдаемость 2.0 и защиту баз данных.
Прежде всего, разработчики стремятся вообще избежать проблем . Они ищут современные решения для наблюдения, которые могут предотвратить проблемы до того, как они возникнут. Это выходит за рамки простого мониторинга показателей: оно охватывает весь жизненный цикл разработки программного обеспечения (SDLC) и каждый этап разработки внутри организации. Производственные проблемы не начинаются с внезапного увеличения трафика; они возникают гораздо раньше, когда разработчики впервые реализуют свои решения. Проблемы начинают проявляться по мере того, как эти решения внедряются в производство и клиенты начинают их использовать. Решения для наблюдения должны перейти к мониторингу всех аспектов SDLC и всех действий, которые происходят на протяжении всего процесса разработки. Сюда входит производственный код и его работа, а также конвейер CI/CD, действия по разработке и каждый отдельный тест, выполняемый с базой данных.
Во-вторых, разработчики ежедневно имеют дело с сотнями приложений . Они не могут тратить время на настройку оповещений для каждого приложения отдельно. Решения для мониторинга должны автоматически обнаруживать аномалии, устранять проблемы до их возникновения и настраивать сигналы тревоги на основе реального трафика. Они не должны выдавать сигналы тревоги на основе жестких ограничений, таких как 80% загрузки ЦП. Вместо этого они должны понять, является ли высокая загрузка ЦП ненормальной или, возможно, она присуща домену приложения.
И последнее, но не менее важное: решения для мониторинга не могут просто отслеживать файлы . Им необходимо устранять проблемы по мере их появления. Многие проблемы, связанные с базами данных, можно решить автоматически путем введения индексов, обновления статистики или изменения конфигурации системы. Эти действия могут выполняться автоматически системами мониторинга. Разработчиков следует вызывать тогда и только тогда, когда необходимо принять бизнес-решения. И когда это произойдет, разработчикам должен быть предоставлен полный контекст того, что происходит, почему, где и какой выбор им нужно сделать. Им не следует ничего отлаживать, поскольку все устранение неполадок должно выполняться автоматически с помощью инструментов.
Оставайтесь в курсе событий, помня о разработчиках
За последнее десятилетие произошли существенные изменения. В стремлении повысить масштабируемость, отказоустойчивость и гибкость цифровой инфраструктуры нашей организации мы стратегически отошли от традиционных монолитных архитектур приложений. Вместо этого мы внедрили современные методы разработки программного обеспечения, такие как архитектура микросервисов и облачные приложения. Этот сдвиг отражает признание того, что в сегодняшней быстро развивающейся технологической среде создание изолированных, независимо развертываемых сервисов дает существенные преимущества по сравнению с тесно связанными базами кода, типичными для монолитных систем.
Чтобы завершить этот переход, нам необходимо сделать все наши системы ориентированными на разработчиков. Это смещает акцент на то, что мы создаем, и как учитывать разработчиков и интегрироваться с их средами. Вместо того, чтобы загружать их данными и заставлять выполнять тяжелую работу, нам нужно предлагать решения и ответы. Многие продукты уже перешли на этот подход. Ваш продукт не должен оставаться позади.
#dst #dstglobal #дст #дстглобал #ИИ #Облачныевычисления #Машинноеобучение #Разработка #программноеобеспечение #искусственныйинтеллект #Наблюдаемость #базаданных #Разработчики #MTTR #SDLC #CICD #Kubernetes #Prometheus #IaC #DevOps #SQL #NoSQL
Источник: https://dstglobal.ru/club/975-kak-i-pochemu-podhod-razrabotchik-prezhde-vsego-menjaet-landshaft-nablyudaemosti