Платформенная инженерия: Обзор

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

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

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

История Platform Engineering

Чтобы понять, почему платформенная инженерия стала важной, нужно рассмотреть её развитие за последние 20-25 лет. За эти годы произошёл переход от работы с bare-metal к облачным решениям. Облака, конечно, дороже, но они обеспечивают гибкость, которая является ключевым свойством современных систем и подходов к их разработке.

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

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

Разумеется, DevOps не были единственной значимой идеей. В начале 2000-х годов в недрах Google развивался подход SRE (Site Reliability Engineering). Задачи SRE заключались в разработке методов построения надежных и масштабируемых систем. В 2016 году Google выпустила книгу, посвященную задачам SRE. До этого времени информация о SRE была представлена лишь фрагментарно на конференциях. С момента выпуска книги практики SRE были внедрены во многих компаниях.

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

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

Платформенная инженерия объединяет в себе идеи SysOps, DevOps и SRE, при этом часть этих практик перекладывается на плечи разработчиков, а за платформенными инженерами остается ответственность за платформу, инфраструктуру, стандарты и абстракции. Разработчики продолжают применять методологии DevOps (CI/CD, GitOps) и SRE (Observability, OnCall, Incident management, SLA/SLO/SLI), но им предоставляются инструменты, абстракции и гарантии, упрощающие этот процесс и позволяющие сосредоточиться на написании кода.

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

Внедрение платформенной ижненерии

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

Это будет соответствовать основному подходу к разработке, когда используются инструменты общего назначения (Kubernetes, облака, базы данных, CI/CD) для создания частных абстракций, решающих конкретные задачи. Например, задачи Kubernetes кластера заключаются в оркестрации, но при реализации собственных средств можно получить решение, которое обеспечивает управление нашими сервисами и их устойчивое выполнение с определёнными SLA/SLO/SLI.

Рекомендуется опираться на Lean подход в разработке и строгий Change Management. Вот шаги для эффективного внедрения:

1. Определение ценности и потребностей: понять, кто наши пользователи и потребители, и какую ценность наша платформа создает для них как продукт. Для разработчиков это может быть связано с упрощением доставки, улучшением обсервабилити и понятными абстракциями. Для бизнеса — это надежность и стоимость. Также, мы сами можем быть пользователями нашей платформы, практикуя “dogfooding”.
2. Построение цепочки ценностей: Анализ текущих процессов для понимания их структуры и выявления возможных потерь. Это поможет понять, как именно выглядят процессы сейчас и какие типы потерь (например, избыточные действия, ожидания, дефекты) могут быть устранены.
3. Создание потока: Минимизировать потери и внедрить автоматизацию там, где это возможно. Это основной этап, на котором происходит разработка и настройка инструментов. То, что было создано, становится зоной ответственности команды платформенной инженерии.
4. Непрерывное улучшение: После выделения определенной области для команды платформенной инженерии, эта область включается в процесс непрерывного улучшения. Постоянное совершенствование процессов и инструментов помогает поддерживать высокое качество и эффективность.
5. Участие команды и обучение: Обучение команды для понимания необходимых технических навыков и правильного использования платформы. Разработчикам нужно объяснять, как корректно пользоваться новой платформой, поскольку абстракции и инструменты могут быть новыми для них.
6. Мониторинг и оценка: Оценка изменений с точки зрения улучшения метрик. Важно понимать, что улучшение одних метрик может негативно повлиять на другие, поэтому необходимо регулярно мониторить и анализировать данные для корректировки стратегии.

Нам также требуется чёткий change management, в который будут вовлечены другие разработчики и бизнес. Использование этого подхода в сочетании с Lean методологией позволяет укрепить качество работы команды. Поскольку этап формирования и оценки ценности уже выполнен, нам остаётся сосредоточиться на процессе управления изменениями, раскрывая подходы к пунктам 3 и 4.

1. Планирование изменений:
   • Описываем, как будут проводиться изменения, указываем ответственных лиц, сроки и ожидаемые результаты.
2. Обсуждение изменений:
   • Поскольку изменения будут внедряться разработчиками, важно обсудить их с разработчиками. Если в компании много разработчиков, можно использовать фокус-группы для понимания того, как они смогут имплементировать изменения. Это может включать создание RFC, проведение совещаний и презентаций.
3. Поддержка при внедрении изменений:
   • На этапе внедрения изменений необходимо обеспечить всестороннюю поддержку разработчикам, которые могут столкнуться с проблемами. Важно следить за тем, чтобы метрики, оценивающие качество работы разработчиков, не ухудшались.

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

Конкретные примеры

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

Деплой

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

1. Определение Ценности Деплоймента:
   • Ценность заключается в надёжном разворачивании кода, что повышает значение бизнес-метрик. Это также упрощает менеджмент ресурсов, позволяет отделить инфраструктурную часть конфигураций от продуктовой, а следовательно, снизить когнитивную нагрузку на разработчиков.
   • Однако надо понимать, что если мы меняем среду исполнения, это может привести к непредвиденным задержкам и ошибкам, поэтому мы должны анализировать метрики типа error rate и P99 latency.
2. Текущая Цепочка Ценности:
   1. Разработчик создает образ сервиса, обычно используя Docker.
   2. Разработчик пишет конфигурацию для деплоя в продакшн, указывая необходимые ресурсы, параметры оборудования, количество ресурсов, параметры для подключения к трейсингу.
   3. Разработчик применяет созданную конфигурацию вручную на несколько кластеров. Это может быть деплой через контейнеры в облачную среду (например, ECS) или на отдельной машине через Docker Compose.
3. Модификация Цепочки для Оптимизации Деплоймента:
   1. Инструменты:
      • Решаем, какие инструменты будем использовать: Kubernetes (или другой оркестратор), Helm-чарты для определения базовых конфигураций сервисов, GitHub Actions для реализации CI, ArgoCD для CD, Vault для управления секретами, ETCD для конфигураций.
      • Секреты и конфигурации будут доставляться в Kubernetes кластер через операторы из Vault и ETCD.
   2. Требования к разработчикам:
      • Описываем требования к разработчикам, чтобы их сервисы могли быть интегрированы в разработанную методологию. Например, каждый сервис должен содержать Makefile в корне репозитория, параметры должны быть в service.yaml, и использовать единый Helm-chart.
   3. Вовлечение и обучение:
      • Обсуждаем план внедрения с разработчиками, создаем минимально жизнеспособный продукт (MVP) для демонстрации процесса.
      • Проводим обучение для разработчиков по использованию новых инструментов и конфигураций.
   4. План Внедрения:
      • Определяем сроки, метрики успеха, обязанности и ожидания. Устанавливаем SLA для деплоя и мониторинга.
      • Определяем дедлайны для внедрения изменений и гарантируем поддержку в процессе перехода.
   5. Поддержка и улучшение:
      • Оказываем поддержку разработчикам в процессе перехода на новые инструменты и конфигурации. Собираем обратную связь и вносим изменения на лету по необходимости.
      • Используем гибкие методологии для непрерывного улучшения системы деплоя.
4. Обучающие Материалы и Поддержка:
   • После завершения внедрения собираем и распространяем обучающие материалы, такие как документация, инструкции, видеоуроки.
   • Настраиваем процессы поддержки, такие как чат-боты, каналы в мессенджерах, и выделяем ответственных за поддержку пользователей.
5. Оценка и Улучшение:
   • Оцениваем метрики, такие как количество успешных развертываний, среднее время развертывания, количество инцидентов после деплоя.
   • Проводим опросы среди пользователей для получения обратной связи.
   • Анализируем узкие места и вносим необходимые улучшения. Собираем данные о стабильности системы и удовлетворенности пользователей.

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

Мониторинг

Предположим, что у нас уже есть компания, в которой существует несколько подходов к мониторингу, и мы хотим упорядочить этот процесс. Команды могут использовать разные инструменты и методы мониторинга, например, Prometheus, CloudWatch, Nagios, или ELK Stack.

1. Определение Ценности Мониторинга:
   • Ценность заключается в надёжном и своевременном обнаружении и уведомлении о проблемах, что позволяет минимизировать простои и оптимизировать работу сервисов. Это также упрощает управление ресурсами и снижает когнитивную нагрузку на разработчиков и операторов.
   • Мы должны анализировать метрики, такие как uptime, response time, error rate, P99 latency, чтобы оценить эффективность изменений и оперативно реагировать на возникающие проблемы.
2. Текущая Цепочка Ценности:
   1. Разработчик или оператор настраивает мониторинг для своих сервисов. Это может включать создание и настройку метрик, алертов и дашбордов.
   2. Разработчик вручную добавляет конфигурации мониторинга в систему, указывая необходимые параметры, такие как целевые узлы, порты, метрики и т.д.
   3. Конфигурации применяются вручную или через CI/CD инструменты, и метрики начинают собираться и отображаться в дашбордах. Алерты настраиваются для уведомления ответственных лиц.
3. Модификация Цепочки для Оптимизации Мониторинга:
   1. Инструменты:
      • Определяем набор инструментов для стандартизации мониторинга: Prometheus для сбора метрик, Grafana для визуализации, Alertmanager для управления уведомлениями, Loki для сбора логов, и Thanos для долгосрочного хранения данных.
      • Конфигурации и секреты будут храниться и управляться с использованием Vault и ConfigMap/Secrets в Kubernetes.
   2. Требования к разработчикам и операторам:
      • Описываем требования к разработчикам для интеграции их сервисов в систему мониторинга. Например, метрики должны быть экспортированы в формате Prometheus, логирование должно быть централизованным через Loki.
      • Создание стандартных шаблонов конфигураций для Prometheus и Grafana, которые можно использовать для новых сервисов.
   3. Вовлечение и обучение:
      • Обсуждаем план внедрения с командами разработчиков и операторов. Создаём MVP (минимально жизнеспособный продукт) для демонстрации процесса.
      • Проводим обучение для пользователей, чтобы объяснить, как использовать новые инструменты и конфигурации.
   4. План Внедрения:
      • Определяем сроки, метрики успеха, обязанности и ожидания. Устанавливаем SLA для мониторинга и уведомлений.
      • Определяем дедлайны для внедрения изменений и гарантируем поддержку в процессе перехода.
   5. Поддержка и улучшение:
      • Оказываем поддержку пользователям в процессе перехода на новые инструменты и конфигурации. Собираем обратную связь и вносим изменения на лету по необходимости.
      • Используем гибкие методологии для непрерывного улучшения системы мониторинга.
4. Обучающие Материалы и Поддержка:
   • После завершения внедрения собираем и распространяем обучающие материалы, такие как документация, инструкции, видеоуроки.
   • Настраиваем процессы поддержки, такие как чат-боты, каналы в мессенджерах, и выделяем ответственных за поддержку пользователей.
5. Оценка и Улучшение:
   • Оцениваем метрики, такие как количество инцидентов, среднее время восстановления (MTTR), стабильность метрик.
   • Проводим опросы среди пользователей для получения обратной связи.
   • Анализируем узкие места и вносим необходимые улучшения. Собираем данные о стабильности системы и удовлетворенности пользователей.

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

Менеджмент ресурсов

Мы хотим сократить затраты на облако, оптимизировать использование ресурсов, таких как базы данных, кэши, Kubernetes ноды, которые недоиспользуются, и заменить их на более дешёвые альтернативы. Также необходимо более точно определить requests и limits для Kubernetes workload.

1. Определение Ценности Оптимизации Ресурсов:
   • Снижение затрат на облачные услуги и оптимизация использования ресурсов.
   • Повышение эффективности работы приложений за счет правильного распределения ресурсов.
   • Снижение когнитивной нагрузки на разработчиков и операторов за счет автоматизации процессов определения и необходимых ресурсов.
   • Определение стоимости облака для каждого конкретного подразделения.
2. Текущая Цепочка Ценности:
   1. Разработчики и операторы создают ресурсы, такие как базы данных, кэши и Kubernetes ноды, с предполагаемыми параметрами.
   2. Ресурсы используются приложениями, но их эффективность и утилизация редко отслеживаются.
   3. Недоиспользованные ресурсы продолжают потреблять ресурсы и увеличивать затраты на облако.
3. Модификация Цепочки для Оптимизации Ресурсов:
   1. Инструменты:
      • Используем инструменты для мониторинга и анализа утилизации ресурсов, такие как Prometheus, Grafana, и Kubernetes Metrics Server.
      • Внедряем автоматизированные решения для анализа и оптимизации ресурсов, такие как KubeCost или CloudHealth для анализа затрат и утилизации.
   2. Процесс Анализа:
      • Собираем данные об использовании всех ресурсов, включая базы данных, кэши и Kubernetes ноды.
      • Анализируем данные для выявления недоиспользованных ресурсов и определяем их текущую утилизацию.
      • Определяем возможные альтернативы и стратегии для оптимизации, такие как масштабирование вниз, замена на более дешёвые альтернативы или реорганизация ресурсов.
   3. Оптимизация Kubernetes Workload:
      • Определяем текущие requests и limits для всех workloads в Kubernetes кластере.
      • Используем исторические данные для определения оптимальных значений requests и limits для каждого workload.
      • Внедряем автоматические рекомендации и корректировки через инструменты, такие как Vertical Pod Autoscaler и Resource Quotas.
   4. Вовлечение и обучение:
      • Обсуждаем план внедрения с командами разработчиков и операторов. Создаём минимально жизнеспособный продукт (MVP) для демонстрации процесса.
      • Проводим обучение для пользователей по использованию новых инструментов и конфигураций.
   5. План Внедрения:
      • Определяем сроки, метрики успеха, обязанности и ожидания. Устанавливаем SLA для мониторинга и управления ресурсами.
      • Определяем дедлайны для внедрения изменений и гарантируем поддержку в процессе перехода.
   6. Поддержка и улучшение:
      • Оказываем поддержку разработчикам и операторам в процессе перехода на новые инструменты и конфигурации. Собираем обратную связь и вносим изменения на лету по необходимости.
      • Используем гибкие методологии для непрерывного улучшения управления ресурсами.
4. Обучающие Материалы и Поддержка:
   • После завершения внедрения собираем и распространяем обучающие материалы, такие как документация, инструкции, видеоуроки.
   • Настраиваем процессы поддержки, такие как чат-боты, каналы в мессенджерах, и выделяем ответственных за поддержку пользователей.
5. Оценка и Улучшение:
   • Оцениваем метрики, такие как количество оптимизированных ресурсов, снижение затрат на облако, улучшение утилизации ресурсов.
   • Проводим опросы среди пользователей для получения обратной связи.
   • Анализируем узкие места и вносим необходимые улучшения. Собираем данные о стабильности системы и удовлетворенности пользователей.

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

Заключение

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

Платформенная инженерия развилась из объединения концепций SysOps, DevOps и SRE. При этом часть ответственности из этих концепций была перенесена на разработчиков, как владельцев сервисов.

Внедрение платформы должны происходить постепенно и с учётом требований разработчиков, бизнеса и лучших практик в данной области. Для этого можно использовать Lean фреймворк и Change-Management

В зависимости от типа изменений могут требоваться разные типы действий и инструменты, но общий подход остаётся прежним.

Удачи вам в ваших шагах при созданию лучшей платформы для разработчиков и бизнеса!