Проектирование платформ

Gartner¹ прогнозирует, что к 2026 году 80% крупных организаций, занимающихся разработкой программного обеспечения, создадут группы по разработке платформ в качестве внутренних поставщиков повторно используемых сервисов, компонентов и инструментов для доставки приложений (по сравнению с 45% в 2022 году).

¹Gartner, Главные стратегические технологические тенденции 2024 года, Барт Виллемсен, Гэри Оллифф и Арун Чандрасекаран, 16 октября 2023 г. GARTNER является зарегистрированной торговой маркой и знаком обслуживания Gartner, Inc. и/или ее дочерних компаний в США и за рубежом и используется в настоящем документе с разрешения. Все права защищены.

Что такое платформенная инженерия?

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

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

Внутренняя платформа разработчика (IDP/ВПЛ) охватывает набор инструментов, сервисов и инфраструктуры, которые позволяют разработчикам создавать, тестировать и развертывать программные приложения. Эти платформы специально разработаны для нужд, потребностей и целей организации.

Благодаря разработке, развертыванию и обслуживанию этих IDP команды инженеров-платформенников обеспечивают:

• Увеличение скорости инноваций и развития
• Лучший опыт для разработчиков
• Более высокая производительность разработчиков
• Сокращение затрат на инфраструктуру
• И многое другое

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

Эффективность IDP

Большинство IDP контейнеризированы и построены на основе Kubernetes-ориентированной инфраструктуры с базовым набором технологий. На схеме ниже показано, что должен включать базовый IDP.

Характеристики сильного и эффективного IDP:

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

• Сервисы платформы (сервисная сетка, хранилище данных, хранилища безопасности, агенты политик)
• Службы доставки (непрерывная интеграция, непрерывная доставка, Git, GitOps)
• Услуги наблюдения для мониторинга, автоматизации и безопасности
• Шаблоны для рабочих пространств разработки, включая все вышеперечисленное

Проектирование платформ также предлагает возможности:

• Автоматизацию ключевых рабочих процессов, такие как проверка
• Достижение оптимальной производительности и безопасности
• Проверка, что платформа работает так, как ожидается, и ресурсы используются оптимальным образом.

Источник: https://tag-app-delivery.cncf.io/whitepapers/platforms/

Относитесь к своей платформе, как к продукту

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

Взгляд на IDP через призму управления продуктом

• Продукт : внутренняя платформа разработки (IDP), созданная для предоставления самообслуживания для инфраструктуры, услуг и поддержки групп разработчиков при создании, тестировании и развертывании приложений в больших масштабах.
• Клиент : Команды разработчиков, которые хотят ускорить производство высококачественных, отказоустойчивых приложений — с небольшими усилиями по адаптации новых приложений и новых разработчиков.

Развитие DevOps с помощью платформенной инженерии

Вы его создаете, запускаете, и он больше не масштабируется.

DevOps сам по себе не отвечает требованиям разработки программного обеспечения в облаке. Проектирование платформы — это DevOps, применяемый в масштабе, нативном для облака.

Эффективный DevOps поддерживает кросс-функциональное сотрудничество и повышает эффективность. Проектирование платформы основывается на традиционных практиках DevOps, но идет на шаг дальше.

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

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

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

Кроме того, подход к проектированию платформ позволяет организациям воспользоваться экономией масштаба, консолидируя разросшиеся технологические стеки для:

• Управления расходами
• Оптимизации использования ресурсов
• Улучшения управления

Облачные платформы требуют нового подхода к наблюдаемости

Для широкого внедрения внутренними командами разработчиков и выполнения обещания по масштабированию DevSecOps, IDP, ориентированному на Kubernetes, требуются другие службы и компоненты для решения задач, связанных с:

• Видимость
• Использование ресурсов
• Безопасность
• Оркестровка
• Сотрудничество

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

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

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

Выполнение

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

Преимущества

Ускорение разработки и поддержка производительности разработчиков

Более двух третей всех организаций (68%), внедряющих платформенную разработку, уже отметили увеличение скорости разработки.

Организации с командами по разработке платформ видят различные преимущества для их скорости и эффективности. Они сообщают о различных преимуществах, в частности:

1. Повышенная надежность системы
2. Повышение эффективности и производительности труда
3. Более быстрая доставка

Улучшение опыта разработчиков

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

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

Оптимизация ресурсов и снижение затрат

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

Стандартизирование технологического стека, чтобы минимизировать риски и улучшить управление

Эффективная разработка платформы позволяет командам поддерживать низкий уровень сложности, стандартизировать доставку и при этом сохранять независимость и свободу.

• Безопасность и соответствие требованиям заложены в конструкцию компонентов и сервисов платформы.
• Шаблоны Golden Path стандартизируют доставку, обеспечивая управление.
• Выявление и устранение проблем или неверных настроек в шаблонных и стандартизированных сервисах становится быстрым и простым.

Минимальная жизнеспособная платформа: BACK-стек + наблюдаемость

Если бы вы начинали с нуля, имея только Git и инструмент CI, простым началом могла бы стать работа со стеком BACK:

Backstage - Графический пользовательский интерфейс (веб-портал)

Argo - Доставка артефактов

Crossplane - API и CLI для автоматизации конфигурации

Kyverno - Сканирование артефактов и применение политик

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

Для передачи данных о наблюдаемости и безопасности разработчикам мы предлагаем интеграцию Backstage с поддержкой Kubernetes по умолчанию и настраиваемыми запросами.

OpenTelemetry предлагает возможность наблюдения с открытым исходным кодом, а Ключ-АСТРОМ можно использовать для наблюдения либо сразу после установки с нашим фирменным ЕдинымАгентом, либо путем простого приема и использования данных, предоставленных через OpenTelemetry.

Основные принципы наблюдаемости и безопасности платформы

Kubernetes — это хорошая отправная точка для создания платформы, позволяющая командам по разработке платформы предоставлять возможности и функции самообслуживания своим командам DevSecOps. Однако это также усложняет облачную среду.

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

Следуйте этим основным принципам при создании внутренней платформы разработки (IDP) для управления приложением или службой на протяжении всего жизненного цикла разработки программного обеспечения (SDLC).

1. Наблюдаемость основной платформы

Важнейшим первым шагом на пути к получению практических сведений о платформе является обеспечение мониторинга артефакта (службы или приложения), а также полного жизненного цикла разработки программного обеспечения и базового IDP:

• Артефакт : Как мой продукт ведет себя в различных условиях (подготовка, тестирование, производство)?
• Инструментарий платформы : Состояние и уровень использования используемых инструментов (например, стека BACK)?

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

Некоторые аспекты наблюдаемости основной платформы

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

2. Опубликование информации

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

3. Эффективность каналов

Хотя мониторинг стека инструментов платформы, описанный в предыдущем параграфе, охватывает работоспособность IDP, он пока не охватывает эффективность конвейера. Здесь вступают в дело логи, события и данные телеметрии от конвейера или выполнения рабочих процессов.

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

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

4. Информация о владельце

При рассмотрении артефактов ответственность является критической частью информации. Кто отвечает за приложение или службу в производстве, и кто владеет безопасностью?

Это часто поддерживалось в CMDB, таблицах Excel или активных каталогах. Однако разумно управлять этой информацией проактивно и автоматически в облачных средах с постоянными обновлениями и изменениями.

Один из способов сделать это — использовать метки и аннотации Kubernetes, обеспечивающие доступность этой критически важной информации «из коробки» на протяжении всего жизненного цикла.

5. Наблюдаемость ИИ

С развитием генеративного ИИ в порталах DevOps и инструментах IDP обеспечение наблюдаемости для этих систем становится все более эффективным, позволяя эффективно управлять предоставляемым ими опытом, одновременно контролируя расходы.

Варианты использования платформенной инженерии

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

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

Разработка - Выпуск - Эксплуатация - Прогнозирование - Предотвращение - Решение - Защита - Улучшение

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

Разработка

В эту категорию входят все виды деятельности, связанные с планированием, разработкой, созданием и тестированием сервисов и приложений на внутренней платформе разработки (IDP), предоставляемой командой инженеров платформы.

Тестирование наблюдаемости каналов

Цель - От миллионов тестовых событий к единому источнику истины.

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

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

Непрерывное тестирование и валидация

Цель - Сокращение времени оценки в 120 раз: с дней до минут.

Тестирование зачастую уже в значительной степени автоматизировано, но команды по-прежнему часто проводят тестирование изолированно.

Для автоматического и проактивного обеспечения высокого качества обслуживания клиентов:

• Объединяйте, непрерывно оценивайте и сопоставляйте результаты тестирования с помощью инструментов тестирования
• Включайте SLO, результаты проверки безопасности и синтетические тесты
• Сократить количество ручных операций, выполняемых инженерами для проверки качества нового релиза
• Простая интеграция конвейера доставки CI/CD с такими инструментами, как Ключ-АСТРОМ Synthetic Monitoring, для обеспечения того, чтобы новые выпуски, в которых все критически важные пользовательские пути работают так, как ожидается

Развитие, основанное на наблюдаемости

Цель - Сокращение среднего времени до наблюдаемости с часов до секунд.

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

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

Стандартизация в разных командах может:

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

Выпуск

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

Проверка релиза

Цель - Сокращение количества неудачных изменений и сокращение времени развертывания производства до 99%

Автоматически проверяйте новые релизы — принимая во внимание зависимости снизу вверх и снизу вверх — на основе базовых данных, данных о наблюдаемости, SLO и информации о безопасности. Используйте результаты для управления значимыми последующими действиями. Предоставление шаблонов проверки релизов как части каждого процесса поставки позволяет быстро получать обратную связь относительно любых негативных побочных эффектов новой версии. Более быстрая обратная связь приводит к лучшему опыту разработчиков, более высокому качеству релизов и более высоким темпам инноваций.

Прогрессивная доставка

Цель - На 90–99 % снижается подверженность проблемам благодаря постепенной доставке.

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

На основе данных о наблюдаемости, включая тенденции SLO и синтетические проверки, можно установить автоматизированный выпуск постепенной доставки, например, «канареечный» или «синий/зеленый».

• Автоматизированное выполнение рабочего процесса для контроля доставки программного обеспечения
• Прямое взаимодействие с Kubernetes для применения изменений конфигурации
• Управление процессом доставки путем использования событий
• Целевые уведомления для информирования команды, отвечающей за процесс доставки

Наблюдаемость каналов

Цель - 100% стандартизированное покрытие жизненного цикла вашего программного обеспечения в режиме реального времени.

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

Используя наблюдаемость конвейера, данные (например, неудачные сборки, время выполнения) можно вычислять и действовать автоматически. С автоматизированными данными эти метрики, такие как метрики DORA, время выполнения изменений, частота развертывания, частота отказов изменений и среднее время решения, легко доступны в нескольких измерениях, включая приложение/сервис, сервис платформы/конвейер, а также технологию и владение.

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

Эксплуатация

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

Оптимизация затрат на облако

Цель - Сократите межзональный сетевой трафик до 55%.

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

Наблюдаемость для инфраструктуры

Цель - MTTR сократился на 30% за счет устранения разрозненности данных.

Для ИТ-отделов основная проблема обеспечения работоспособности ИТ-инфраструктуры заключается в сложной задаче выявления точной первопричины проблем.

Применяя Golden Paths и шаблоны as-code, пользователи могут быстро отслеживать проблемы производительности до их источника, «следуя по красному» к проблемному объекту инфраструктуры. Этот подход позволяет немедленно понять, как объекты, такие как хосты, процессы и их связанные отношения, способствуют выявленной проблеме.

Мониторинг Kubernetes

Цель - Управляйте своей платформой с помощью более 30 готовых оповещений о состоянии здоровья.

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

Это централизованное представление:

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

Прогнозирование

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

Прогнозирование Kubernetes

Цель - Сокращение избыточного выделения ресурсов и потребностей в хранении до 75%.

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

Прогнозирование в аналитике данных

Цель - Никаких оповещений об изменении размера диска в нерабочее время для SRE.

Упреждающее управление облачными ресурсами в высокодинамичных ИТ-системах является критически важным фактором успеха для современных компаний. Операторы должны внимательно следить за критически важными для бизнеса ресурсами, такими как хранилище, ЦП и память, чтобы избежать простоев, вызванных нехваткой ресурсов.

Прогнозирование в автоматизации рабочих процессов

Цель - Сократите до 100% повторяющихся ручных операций с помощью автоматизации на основе прогнозирования.

ИИ в автоматизации рабочих процессов позволяет заблаговременно создавать заявки и автоматически действовать до возникновения проблем.

Предотвращение

Даже если ИИ не может предсказать проблемы, он часто может предотвратить их, используя данные наблюдения и безопасности.

Предотвращение ошибок, с которыми сталкиваются клиенты

Цель - Сокращение количества ошибок, с которыми сталкиваются конечные пользователи, до 36%.

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

Единая защита от воздействия

Цель - Сократите время устранения рисков с 96 до 4 часов — на 95% быстрее.

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

Постоянное состояние мер безопасности

Цель - Мгновенные отчеты о состоянии безопасности в режиме реального времени.

Получите унифицированное и приоритетное представление различных рисков на разных уровнях приложений, а также в производственных и предпроизводственных средах.

• Определите приоритеты уязвимостей с учетом индивидуальных рисков, характерных для вашей организации.
• Узнайте, какие восстановительные мероприятия имеют приоритетное значение для воздействия, и позвольте автоматизации справиться с этим
• Изучите подробную информацию об уязвимости, например, какие объекты затронуты и есть ли связь с базами данных.

Решение

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

Сортировка инцидентов и реагирование

Цель - Улучшите MTTR до 99%.

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

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

Решение критических проблем, влияющих на продукт

Цель - Связывание ИТ-оповещений с влиянием на продукт обеспечивает расстановку приоритетов.

Объединение данных о наблюдаемости IDP с влиянием IDP на бизнес-транзакции и следы позволяет организациям расставлять приоритеты, основываясь в первую очередь на проблемах с наибольшим влиянием.

Оповещение об ошибках в бюджете

Цель - Повышение эффективности сортировки на 90%.

Если у вас 99 проблем, как вы расставляете приоритеты?

Простой способ сосредоточиться на правильных проблемах — посмотреть на те, которые активно влияют на цели уровня обслуживания (SLO). Если количество проблем в среде все еще требует дальнейшей приоритизации, автоматически сортируйте и легко информируйте заинтересованных лиц, оповещая их о скорости сжигания бюджета ошибок SLO (насколько быстро расходуется бюджет ошибок SLO).

Защита

Все среды, инфраструктуры и приложения должны быть защищены — правильными мерами. Организации могут легче защитить свои активы с помощью согласованной платформы внутренних разработчиков (IDP), обеспечивающей управление и безопасность.

Снижение уровня шума в Центре безопасности операций

Цель - Сокращение количества событий безопасности на 99%

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

Автоматизируйте результаты проверки безопасности в любом масштабе

Цель - Стремитесь к нулю ложных срабатываний.

Поймите угрозу, которую представляет ваш код, сторонние библиотеки и библиотеки с открытым исходным кодом, и блокируйте вредоносные запросы, пытающиеся использовать уязвимости кода в них.

• Точное обнаружение и блокирование атак
• В то время как приложения продолжают обслуживать своих пользователей
• Интегрировано с ЕдинымАгентоми и доступно одним щелчком переключателя

Контекстное обнаружение угроз и реагирование на инциденты

Цель - От гипотезы об угрозе до реальных доказательств за считанные минуты.

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

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

Улучшение

Постоянное улучшение ресурсов стимулирует бизнес. Эти улучшения могут варьироваться от экономии затрат и времени до постоянного обеспечения лучшего в своем классе клиентского опыта.

Постоянное профилирование приложений

Цель - Устранение проблем с производительностью в 5 раз быстрее

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

Улучшение использования Kubernetes

Цель - Автоматизированное улучшение использования K8s сокращает расходы до 25%.

Постоянное автоматическое обновление и улучшение запросов и лимитов k8s, снижение когнитивной нагрузки на разработчиков и обеспечение спокойствия инженеров платформы.

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

Бизнес-выравнивание

Цель - Добавьте контекст в свои бизнес-процессы и ускорьте сотрудничество.

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

Показатели DORA

Команда Google по исследованию и оценке DevOps (DORA) разработала метрики DORA для предоставления ключевых показателей эффективности работы команды разработчиков программного обеспечения.

Установлены четыре ключа:

Частота развертывания	Измеряет, как часто команда успешно выпускает продукт в производство
Время на подготовку к изменениям	Измеряет время, необходимое для запуска готового кода в эксплуатацию.
Изменение частоты отказов	Измеряет процент развертываний, которые приводят к сбоям в производстве, требующим исправления ошибок или отката.
Среднее время восстановления обслуживания (MTTR)	Измеряет, сколько времени требуется организации для восстановления после сбоя в производстве.

Команда DORA расширила эти показатели, добавив пятый в 2021 году:

Надежность

Представление доступности, задержки, производительности и масштабируемости

Сравнительный анализ в режиме реального времени и по всем направлениям (таким как технологии и команды) обеспечивает важные преимущества для команды разработчиков платформы.

Опыт разработчиков

Разработка платформы в конечном итоге направлена ​​на повышение производительности разработчиков. Но как определить и измерить производительность и удовлетворенность разработчиков? Ее нельзя свести к одной метрике, но структура SPACE охватывает критические измерения производительности разработчиков:

• Удовлетворение
• Производительность
• Активность
• Коммуникация и сотрудничество
• Эффективность и поток

Фреймворк SPACE не предоставляет готовый к использованию список показателей, как метрики DORA, а вместо этого предлагает категории для рассмотрения.

Ключ-АСТРОМ и OpenTelemetry

OpenTelemetry (также известный как OTel) — это фреймворк наблюдения с открытым исходным кодом, состоящий из набора инструментов, API и SDK.

• OTel позволяет ИТ-отделам анализировать, генерировать, собирать и экспортировать телеметрические данные для анализа и понимания производительности и поведения программного обеспечения. Являясь частью проекта Cloud Native Computing Foundation (CNCF), OTel стремится предоставить унифицированные наборы независимых от поставщика библиотек и API, в основном для сбора данных и их передачи куда-либо.
• Ключ-АСТРОМ, которая стремится сделать наблюдение бесшовным для технических групп, является единственным решением для наблюдения, которое сочетает в себе высокоточную распределенную трассировку, видимость на уровне кода и расширенную диагностику в облачных архитектурах. Данные и контекст имеют решающее значение для суперзарядки наблюдения. Благодаря бесшовной интеграции данных OTel распределенная технология трассировки Ключ-АСТРОМ автоматически собирает данные OTel и предоставляет инструментарий для всех основных фреймворков, выходящих за рамки OTel.