Как современная инженерная организация управляет быстрой непрерывной доставкой, поддерживая при этом высокую стабильность систем и минимизируя операционные риски?
Для высокоскоростных команд разработки это означает выход за рамки статических проверок перед фиксацией кода и внедрение управления функциями во время выполнения непосредственно вместе с телеметрией в реальном времени. Инженерные команды сталкиваются с высокой трудоемкостью для разработчиков и увеличением среднего времени восстановления (MTTR) при триаже инцидентов в продакшене в рамках сложных архитектур микросервисов. В то же время огромный объем кода, создаваемого агентами ИИ, привел к возникновению узких мест в конвейерах развертывания и при обзоре пулл-реквестов (PR), переключив фокус инженерной мысли с написания кода на безопасное управление его воздействием во время выполнения.
В нашей октябрьской беседе у камина New Relic Now Брайан Эмерсон (Chief Product Officer в New Relic) и Джонатан Нолен (Chief Product Officer в LaunchDarkly) рассказали о том, как объединение функциональных флагов времени выполнения с нейтральной телеметрией в реальном времени превращает поставку ПО в отказоустойчивый автоматизированный операционный рабочий процесс.
Вот что они обсудили.
Основные выводы
- Выйдите за рамки IDE: генеративный ИИ и автоматизированные помощники по написанию кода экспоненциально увеличивают объем кода, превращая ревью кода и развертывание в критические узкие места доставки. Скорость безопасных релизов требует элементов управления во время выполнения, а не только статических проверок.
- Замкните и автоматизируйте цикл обратной связи: связывание телеметрии New Relic напрямую с флагами функций LaunchDarkly создает четырехэтапный замкнутый цикл обратной связи (релиз, наблюдение, оценка, действие), превращая пассивный мониторинг в автоматизированную локализацию, которая сокращает время воздействия с часов до минут.
- Обогащайте трассировки с помощью OpenTelemetry: стандартизация телеметрии посредством OpenTelemetry (OTel) позволяет инженерным командам внедрять контекст функциональных флагов непосредственно в распределенные трассировки, устраняя слепые зоны во время сложных развертываний в продакшене.
Дилемма скорости и фабрика программного обеспечения
Появление инструментов разработки на базе ИИ радикально изменило цепочку поставок программного обеспечения. Разработчики пишут и генерируют код быстрее, чем когда-либо прежде. Однако ускорение создания кода внутри IDE создает дополнительное трение на этапах развертывания и верификации.
Поскольку производство программного обеспечения все больше напоминает автоматизированную фабрику, традиционные процессы ручного ревью и длинные очереди пулл-реквестов перестают масштабироваться. Когда объем растет без автоматизированных средств защиты времени выполнения, инженеры сталкиваются со сложным выбором: замедлить релизы или принять неконтролируемые риски в продакшене. Отделение развертывания кода от релиза для пользователей с помощью управления функциями позволяет организациям непрерывно выкатывать код, контролируя точный уровень его воздействия во время выполнения.
Интеграция управления функциями LaunchDarkly с телеметрией New Relic
Достижение высокой скорости релизов требует четкого разделения операционных обязанностей между платформами управления функциями и движками телеметрии:
- LaunchDarkly как плоскость управления во время выполнения: функционирует как движок выполнения во время выполнения (охватывающий CodeControl и AgentControl), динамически настраивая поведение ПО, управляя целевыми раскатками и служа основным механизмом экстренного отключения при аномалиях.
- New Relic как нейтральный движок телеметрии: обеспечивает комплексную, непредвзятую наблюдаемость производительности системы, частоты ошибок, метрик задержки и сигналов пользовательского поведения без предвзятости со стороны поставщика.
Интегрируя эти системы с помощью стандартов OTel, атрибуты флагов прикрепляются непосредственно к трассировкам транзакций. Когда возникает аномалия, телеметрия мгновенно определяет, вызвал ли конкретный статус функционального флага регрессию.
Замыкая цикл: от постепенного развертывания к автоматизированной локализации
Современная непрерывная доставка опирается на замкнутый операционный рабочий процесс, состоящий из четырех четких этапов:
- Релиз: изменения программного обеспечения развертываются в продакшене с отключенными функциональными флагами или с ограничением для крошечного процента пользователей (например, 1%).
- Наблюдение: New Relic собирает метрики в реальном времени, логи и распределенные трассировки, помеченные соответствующими идентификаторами флагов.
- Оценка: автоматизированные политики защитных барьеров постоянно оценивают поступающую телеметрию на предмет соответствия заранее определенным бюджетам ошибок и базовым показателям производительности.
- Действие: если метрики превышают допустимые пороги безопасности, автоматизированные триггеры немедленно предупреждают LaunchDarkly о необходимости мгновенного отката или отключения проблемного флага.
Эта автоматизация по замкнутому циклу помогает устранить задержки ручного триажа, потенциально сокращая продолжительность инцидентов и уменьшая зону поражения с часов влияния на клиентов до секунд автоматизированного устранения.
Технические рекомендации и безопасное масштабирование
В ходе беседы Джонатан Нолен изложил практические рекомендации для инженерных лидеров, платформ-команд и SRE, стремящихся безопасно масштабировать прогрессивную доставку:
- Начинайте с малого на критически важных сервисах: начните внедрение функциональных флагов и автоматизированных защитных барьеров на основных микросервисах уровня 1, где тревожность по поводу развертывания наивыслена.
- Раньше обогащайте распределенные трассировки: убедитесь, что метаданные функциональных флагов внедряются в заголовки трассировок OpenTelemetry для оптимизации анализа первопричин в сложных распределенных архитектурах.
- Установите четкие базовые показатели защитных барьеров: заранее определите явные пороги производительности и метрики ошибок, чтобы автоматизированные триггеры отката работали без двусмысленности ручного вмешательства.
Что дальше и как узнать больше
Интеграция LaunchDarkly и New Relic обеспечивает защитную сетку, необходимую современным командам разработки для соответствия требованиям скорости создания ПО на базе ИИ. Объединяя динамические элементы управления во время выполнения с нейтральной телеметрией, инженерные организации могут быстро внедрять инновации без ущерба для надежности систем.
New Relic и LaunchDarkly активно ищут партнеров по разработке в экосистемах Python, OpenTelemetry, Go и Java для доработки автоматизированных защитных барьеров релизов. Чтобы узнать больше об оптимизации вашего конвейера релизов, присоединяйтесь к нашему ограниченному предварительному просмотру здесь.
Гленвуд Барби (Glenwood Barbee) возглавляет направление маркетинга технических партнеров в группе маркетинга решений продуктов в New Relic и сосредоточен на интеграциях с агентами. Он рад возможности привнести мощь ИИ New Relic в рабочие процессы наших ключевых партнеров и клиентов. Вне офиса Гленвуд проводит большую часть свободного времени, пытаясь угнаться за своими двумя детьми (четырех и двух лет).
Мнения, выраженные в этом блоге, принадлежат автору и не обязательно отражают точку зрения New Relic. Любые решения, предлагаемые автором, зависят от конкретной среды и не являются частью коммерческих решений или поддержки, предлагаемых New Relic. Пожалуйста, присоединяйтесь к нам исключительно в Explorers Hub (support.newrelic.com) для вопросов и поддержки, связанных с этой публикацией в блоге. Этот блог может содержать ссылки на контент сторонних сайтов. Предоставляя такие ссылки, New Relic не принимает, не гарантирует, не одобряет и не поддерживает информацию, мнения или продукты, доступные на таких сайтах.
