Лучшие команды для владения

Эти передовые методы и советы по владению призваны помочь вам:

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

Передача владения

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

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

• Метки Kubernetes для объектов Kubernetes
• Метаданные для хостов
• Переменные среды для процессов
• Теги (ручные, автоматические и через API) для всех остальных сущностей

Kubernetes

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

• Всегда применяйте метки для развертывания .
• Мы рекомендуем указать владельца как минимум для объектов CLOUD_APPLICATION (например, Deployment, Job, CronJob или DaemonSet) и CLOUD_APPLICATION_INSTANCE (Pods).
• Уникальные ключи являются обязательными в парах ключ-значение в метках Kubernetes. Ключи должны начинаться с имен пользовательских ключей, которые вы определяете для информации о владельце. Например, вы можете использовать owner и dt.owner в качестве префиксов для создания уникальных ключей.

Пример файла развертывания Kubernetes с определенными правами собственности для развертывания, модуля и процесса.

apiVersion: apps/v1

kind: Deployment

metadata:

  name: demo

  labels:

    dt.owner-1: my-team-1 # Dual team ownership defined for the Deployment

    dt.owner-2: my-team-2

spec:

  replicas: 1

  selector:

    matchLabels:

      app: demo

  template:

    metadata:

      labels:

        app: demo

        dt.owner-1: my-team-1 # Ownership defined for the Pod

    spec:

      containers:

        - name: demo

          image: demo:1.0.0

          ports:

            - containerPort: 8888

          env:

            - name: DT_CUSTOM_PROP # Environment variable

              value: 'dt.owner-1=my-team-1' # Ownership defined for the process

Теги

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

Преимущества и использование тегов

• Теги подходят для назначения нескольких стабильных объектов (например, приложения и синтетических мониторов, работающих с ним) определенным группам владельцев.
• Ручная маркировка или API пользовательских тегов эффективны для применения владения к существующим (уже развернутым) объектам.
• Правила автоматического тегирования имеют преимущество захвата новых объектов, которые соответствуют вашим правилам тегирования. Автоматически примененные теги также не могут быть удалены вручную из отдельных служб, групп процессов, экземпляров групп процессов, приложений или хостов.
• В то время как API пользовательских тегов и правила автоматической маркировки используют мощный и гибкий селектор объектов для выбора сущностей, вызов API пользовательских тегов выполняется немедленно. Это является основным преимуществом по сравнению с правилами автоматической маркировки , которые планируются через процесс маркировки Ключ-АСТРОМ. Это помогает ускорить время выполнения, когда необходимы сложные правила маркировки.

Важные замечания при использовании тегов для определения владения

• Ручное тегирование не масштабируется адекватно для назначения владения в больших динамических средах мониторинга. Ручные теги также можно удалить вручную.
• Хотя (на основе веб-интерфейса) правила автоматических тегов разработаны для сложности, выполнение автоматических тегов может занять много времени в зависимости от сложности ваших правил и размера вашей среды. Между тем, критически важный объект, испытывающий проблему, может не быть помечен с владением.
• Хотя вызов API пользовательских тегов выполняется немедленно, недостаток заключается в том, что это одноразовая операция. В зависимости от частоты запусков тегирования новые или недолговечные объекты могут полностью не быть помечены информацией о владельце, что затрудняет поиск владельцев в случае уязвимостей или сбоев.
• Мы не рекомендуем использовать теги для применения владения к процессам или группам процессов.

Информация о командах

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

• При определении пользовательских ключей для идентификаторов собственности используйте конкретные, легко понятные имена, которые вряд ли будут использоваться для других целей тегирования.
• Всегда добавляйте описание команды — оно отображается вместе с названием команды на странице настроек Команды владения и помогает различать команды с первого взгляда. Команды без описания или с неудачным названием (команда 1) не дают никаких подсказок относительно их роли в вашей организации. Команды с описаниями (2 и 3) более идентифицируемы.
• Дополнительные идентификаторы (вы можете определить до трех для каждой команды) особенно полезны, когда:
  • Название вашей команды изменится — вы можете добавить дополнительный идентификатор, чтобы отразить изменение названия, оставив основной идентификатор команды без изменений. (После создания основной идентификатор команды нельзя будет редактировать или изменять.)
  • Вы хотите определить подкоманды. Создайте дополнительный идентификатор для каждой подкоманды — вы можете использовать основной идентификатор команды в качестве префикса. Например, для основного идентификатора команды team1 создайте дополнительные идентификаторы team1-taskforce и team1-planning. Дополнительные идентификаторы обеспечивают большую гибкость.
  • Независимо от того, применяете ли вы к объекту основной или дополнительный идентификатор команды, он помечается как принадлежащий к той же названной команде.
  • Дополнительные идентификаторы могут быть изменены и удалены.
  • Дополнительный идентификатор может совпадать с основным или дополнительным идентификатором другой команды. В таком случае обе команды отмечаются как владельцы, когда дополнительный идентификатор применяется к объекту.
• Всегда выбирайте Обязанности команды, даже если они не требуются. Обязанности отображаются на видном месте вместе с описаниями команды на карточке владельца объекта. Эти фрагменты информации о команде являются ключевыми индикаторами для добавления контактной информации для маршрутизации сообщений и эскалаций.
• Определите как минимум один адрес электронной почты или канал Slack для каждой команды в разделе Контактная информация, чтобы вы могли создать автоматизированный рабочий процесс с целевым уведомлением или просто извлечь контактную информацию любого отслеживаемого объекта, когда это необходимо.
• Для дополнительной информации , хотя вы можете определять пользовательские пары ключ-значение ad hoc, мы рекомендуем рационализировать ключи между командами, чтобы их можно было повторно использовать для тех же видов информации. Например, используйте те же или связанные ключи для определения информации о центрах затрат и другой набор ключей по всей организации для определения иерархий и отношений команд.