{
  "format": "sf-survey-template-example",
  "version": 1,
  "order": 15,
  "slug": "dora-devops-performance",
  "name": "DORA: зрелость практик, влияющих на delivery performance",
  "description": "Самооценка зрелости поставки и эксплуатации по мотивам DORA. Шаблон сочетает фактические вопросы по ключевым delivery-метрикам с вопросами о практиках, которые влияют на результат; блок технических основ стоит интерпретировать отдельно от самих DORA-метрик.",
  "type": "custom",
  "blocks": [
    {
      "name": "Частота деплоя",
      "weight": 1,
      "questions": [
        {
          "text": "Как часто команда деплоит изменения в production?",
          "answer_type": "single",
          "options": [
            { "value": 5, "label": "Несколько раз в день" },
            { "value": 4, "label": "Примерно раз в день" },
            { "value": 3, "label": "Несколько раз в неделю" },
            { "value": 2, "label": "Раз в неделю" },
            { "value": 1, "label": "Раз в месяц или реже" }
          ]
        },
        { "text": "Команда регулярно и часто выкатывает изменения в продакшен.", "answer_type": "scale" },
        { "text": "Процесс деплоя автоматизирован и не требует значительных ручных действий.", "answer_type": "scale" },
        { "text": "Команда может задеплоить изменения в любой момент без привязки к фиксированному расписанию релизов.", "answer_type": "scale" },
        { "text": "Изменения поставляются в продакшен небольшими инкрементальными шагами, а не крупными батчами.", "answer_type": "scale" },
        { "text": "Деплойный пайплайн достаточно быстр и не тормозит ежедневную поставку.", "answer_type": "scale" }
      ]
    },
    {
      "name": "Время от коммита до продакшена",
      "weight": 1,
      "questions": [
        {
          "text": "Сколько обычно проходит времени от merge или commit до production?",
          "answer_type": "single",
          "options": [
            { "value": 5, "label": "До 1 часа" },
            { "value": 4, "label": "В течение дня" },
            { "value": 3, "label": "1-3 дня" },
            { "value": 2, "label": "До недели" },
            { "value": 1, "label": "Больше недели" }
          ]
        },
        { "text": "После коммита изменения быстро попадают в продакшен.", "answer_type": "scale" },
        { "text": "CI/CD-пайплайн запускается автоматически на каждый коммит и завершается за разумное время.", "answer_type": "scale" },
        { "text": "Код-ревью и процессы согласования не создают существенных задержек в поставке.", "answer_type": "scale" },
        { "text": "Команда использует trunk-based development или ветки с коротким временем жизни, которые часто вливаются.", "answer_type": "scale" },
        { "text": "Ручное тестирование и этапы согласования перед продакшеном сведены к минимуму.", "answer_type": "scale" }
      ]
    },
    {
      "name": "Доля неудачных изменений",
      "weight": 1,
      "questions": [
        {
          "text": "Какой процент production-деплоев обычно приводит к инциденту, откату или срочному исправлению?",
          "answer_type": "single",
          "options": [
            { "value": 5, "label": "Почти никогда или очень редко" },
            { "value": 4, "label": "Редко, но заметно" },
            { "value": 3, "label": "Иногда" },
            { "value": 2, "label": "Регулярно" },
            { "value": 1, "label": "Часто" }
          ]
        },
        { "text": "Большинство деплоев в продакшен проходит без инцидентов и откатов.", "answer_type": "scale" },
        { "text": "Автоматические тесты выявляют большинство дефектов до того, как изменения попадают в продакшен.", "answer_type": "scale" },
        { "text": "У команды есть понятная и отработанная стратегия отката или быстрого фикса.", "answer_type": "scale" },
        { "text": "Изменения кода и конфигурации проходят структурированное ревью перед каждым деплоем.", "answer_type": "scale" },
        { "text": "Тестовое покрытие достаточно, чтобы уверенно выполнять деплой в любое время.", "answer_type": "scale" }
      ]
    },
    {
      "name": "Восстановление после неудачного изменения",
      "weight": 1,
      "questions": [
        {
          "text": "Сколько времени обычно требуется, чтобы восстановиться после неудачного изменения или деплоя, потребовавшего вмешательства?",
          "answer_type": "single",
          "options": [
            { "value": 5, "label": "До 1 часа" },
            { "value": 4, "label": "В течение рабочего дня" },
            { "value": 3, "label": "До 1 дня" },
            { "value": 2, "label": "1-3 дня" },
            { "value": 1, "label": "Больше 3 дней" }
          ]
        },
        { "text": "После проблемного изменения команда быстро обнаруживает сбой и начинает реагировать.", "answer_type": "scale" },
        { "text": "Мониторинг и алертинг настроены и дают ранние сигналы о проблемах после деплоя.", "answer_type": "scale" },
        { "text": "Для типовых деплойных инцидентов есть задокументированные runbook'и или playbook'и.", "answer_type": "scale" },
        { "text": "Постмортемы по неудачным изменениям проводятся регулярно и приводят к конкретным улучшениям.", "answer_type": "scale" },
        { "text": "On-call дежурства четко распределены и не перегружают отдельных сотрудников.", "answer_type": "scale" }
      ]
    },
    {
      "name": "Технические основы и capability-практики",
      "weight": 1,
      "questions": [
        { "text": "Весь код и конфигурация инфраструктуры хранятся в системе контроля версий.", "answer_type": "scale" },
        { "text": "Команда использует feature-флаги или аналогичные подходы, чтобы разделить деплой и релиз.", "answer_type": "scale" },
        { "text": "Все окружения согласованы между собой, инфраструктура описана как код (IaC).", "answer_type": "scale" },
        { "text": "Изменения схемы БД автоматизированы и являются частью деплойного пайплайна.", "answer_type": "scale" },
        { "text": "Проверки безопасности и соответствия требованиям встроены в пайплайн, а не выполняются вручную.", "answer_type": "scale" }
      ]
    }
  ]
}