本文是中文版《2019年加速度DevOps状态调查》问卷。如果你还没有填写该问卷的话，可以在线上填写英文版，点击这个链接 https://bit.ly/2UzLMH2 ，进入问卷调查网站。本文可以作为你的帮助文档。

译者团队：刘征、张晔、刘頲、朱婷、王英伟、王虹、李建芳、沈越飞、井建宇、申屠欣欣

本文由以上翻译团队经过两周的时间，在业余时间翻译完成，如果对本文有任何改进建议请发邮件到 martin AT DevOpsCoach.org

发布本文的另外一个原因：作为历时6年，被称之为DevOps界之科学的调查研究，我们可以透过这套问卷，洞察如何用问卷的方式定量的度量DevOps的现状。对于已经实施了多年DevOps企业，本问卷可谓是一道营养丰富的大餐。

历年来的DevOps状态报告

如果你需要下载学习的话，请点击下面的链接（扫码二维码），这里还有历年来英文版报告全集和部分中文版本。

下面是2019年DevOps状态调查问卷的简体中文版译文。

第一部分

欢迎参加2019年全球DevOps全球行业调查。

• 我们有兴趣了解您的工作方式以及工作环境。
• 答案并没有对错。
• 如果您不知道答案，可以选择“我不知道或不适用”，您的作答将被忽略。

非常感谢您花时间帮助我们去探索那些能使技术进步的秘密！

1. 您的组织主要属于哪个行业？

• 教育
• 能源
• 金融服务
• 政府
• 医疗保健和制药
• 工业与制造业
• 保险
• 媒体/娱乐
• 非盈利
• 零售/消费品/电子商务
• 技术
• 电信
• 其他。请明确说明： [____]

2. 有多少员工在您的组织里工作？

• 1-4
• 5-9
• 10-19
• 20-99
• 100-499
• 500-1,999
• 2,000-4,999
• 5,000-9,999
• 10,000+
• 我不知道

3. 你们的服务器上都部署了哪些操作系统？

• Windows 2003 / 2003R2
• Windows 2008 / 2008R2
• Windows 2012 / 2012R2
• Windows 其他
• Linux Debian / Ubuntu变种
• Linux Enterprise Linux变体（RHEL，Oracle，CentOS）
• Linux Fedora
• Linux SUSE Linux Enterprise Server
• Linux OpenSUSE
• Linux Arch
• Linux其他
• 其他的UNIX
• FreeBSD / NetBSD / OpenBSD系统
• AIX
• Solaris
• 其他

4. 在过去一年中，关于下列绩效指标，您的组织实现的程度如何？

• 您组织的整体表现
• 您组织的整体盈利能力
• 主要产品的相对市场份额
• 客户数量增加

（表现远低于目标 表现低于目标 略低于目标 达到了目标 略高于目标 表现高于目标 表现远高于目标 不适用或我不知道）

5. 我们也有兴趣了解其他一些目标。 选择指示您的组织在过去一年中如何针对以下目标执行的选项

• 产品或服务的数量
• 运营效率
• 消费者满意度
• 所提供的产品或服务的质量
• 实现组织的/使命的目标
• 通过其它的方面向外部各方证明了贵组织实现预期成果

（表现远低于目标 表现低于目标 略低于目标 达到了目标 略高于目标 表现高于目标 表现远高于目标 不适用或我不知道）

6. 我们有兴趣了解DevOps或敏捷方法是怎样在您组织的各个团队中传播的。

在这里，我们将描述我们看到过的那些常见的模式，并要求您从中选择出哪些在自己的组织中最常见方式（请选择所有适用的选项）

• 培训中心（有时也称为DOJO） - 让人们暂时脱离正常的工作惯例，以便在一段时间内学习新的工具或技术、实践甚至文化，然后再回到正常的工作环境中，目标（希望？）是：他们会坚持使用新的工作方式，甚至可能推广给其他的人。

• 卓越中心 - 一个所有专业知识都具足，然后为内部各方提供咨询的地方。

• 止步于概念证明 - 进行概念证明（PoC）项目，通常执行团队可以突破组织规范（通常是官方的规则）的羁绊，从而自由的按照所认为的最好的方式构建。然而，在PoC之后，那些付出就停滞不前了。

• 用概念证明当模板 - 也是从小规模的概念证明（PoC）项目（如上所述）开始，然后开始使用这个最初的模式在组织中的其它团队进行复制。

• 用概念证明做种子 - 也是从小规模的概念证明（PoC）开始，然后将PoC知识传播给其他团队。这是通过打散PoC（可以是第一个PoC团队，或是后续/并行的PoC团队）执行团队，并将他们派发到其他团队，去分享他们所学到的知识和实践的方式来完成的。也可以称此为轮岗，那些前PoC团队成员沉浸在其他团队中，发挥着传播新的实践和文化，并兼做导师的职责。他们可能会无限期地留在这个新的群体中，或者只是用足够长的时间来确保，他带来的新的做法是可持续的。

• 实践社区 - 在组织内培养对工具、语言或方法有共同兴趣的团体，以便在他们的彼此之间、团队之间，以及在组织内部分享他们的知识和专业技能。

• 大爆炸式 - 组织进行整体一次性的DevOps方法（当然他们要选择对其下的定义）转型，通常采用自上而下的指令。

• 自下而上或草根方式 - 那些在一线工作的小团队将资源整合在一起，然后在整个组织中，通过非官方的形式分享所取得的成功，并进行推广，而无需任何组织官方的支持或资源。

• 混搭型 - 组织实施过了上述的若干种方法，通常由于无法得到成功所需的资源和重视，只能是半途而废了。

第二部分

这部分涉及您的工作及其成果，以及它对您自身的影响。

1. 在你工作的过程中，你的感受是怎样的？

请评价您对以下陈述的同意或不同意程度。

• 我经常处于高水平的生产力
• 我经常能够进入一个良好的“流程”，在那里我可以完成复杂、耗时的任务，同时最大限度地减少干扰和中断。
• 我对我的工作很满意。
• 我有足够的工具和资源来完成我的工作。
• 我的工作很好地利用了我的技能和能力。

（强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）

2. 对于您工作的主要应用程序或服务，变更前置时间（即：从代码提交到在生产中成功运行的过程需要的时间）是多长？

• 超过六个月
• 一个月到六个月之间
• 一周到一个月之间
• 一天到一周之间
• 不到一天
• 不到一个小时
• 我不知道或不适用

3. 对于您工作的主要应用程序或服务，您的组织在生产环境进行代码部署或向最终用户做发布的频率是什么？

• 每六个月少于一次
• 每一到六个月一次
• 每周到每月一次
• 每天到每周一次
• 每小时到每天一次
• 按需（每天都要进行多次部署）
• 我不知道或不适用

4. 对于您工作的主要应用程序或服务，当服务中断或出现影响用户Bug时（如：计划外中断、服务受损），恢复服务通常需要多长时间？

• 超过六个月
• 一个月到六个月之间
• 一周到一个月之间
• 一天到一周之间
• 一天之内
• 一小时之内
• 我不知道或不适用

5. 对于您所工作的主要应用程序或服务，对于生产变更，或向最终用户发版的变更，百分之多少会导致服务质量下降（如：服务受损或服务中断），并需要进行后续的修复工作（需要热补丁、回滚，前向修复，打补丁修复）

• 0％-15％
• 16％-30％
• 31％-45％
• 46％-60％
• 61％-75％
• 76％-100％
• 我不知道或不适用

6. 接下来的问题会询问可靠性，以及您和您的团队如何看待它。

请评价您对以下陈述的同意或不同意程度。 对于您所工作的主要应用程序或服务：

• 定义了明确的可用性目标（如服务级别协议/服务级别目标），这些目标在团队和客户之间达成了清晰的共识。
• 我知道最近一段时间实际的可用性。
• 在最近一段时间内，我的团队达到或超过了可用性目标。
• 当我们未达成可用性目标时，就会进行改进工作，也或将对调整工作的优先级。
• 如果使用云服务，我的团队就会借助云计算的高可用性（如：使用多个可用区）来提高可靠性。

（强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）

7. 工作的可持续性很重要，而职场透支是一个相关的重要度量指标。您能否回答几个问题，让我们知道您的工作对您有何影响？

请评价您对以下声明的同意或不同意程度：

• 我感觉透支很严重。
• 我感到筋疲力尽。
• 我对所从事的工作无语或愤世嫉俗。
• 我觉得工作效率低下。
• 我觉得工作应对业余的正常生活产生负面影响。
• 我能够完成工作并保持良好的整体状态。
• 我能够有效应对与工作有关的压力。
• 我可以在业余时间中（即，当我选择不工作时）脱离工作。

（强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）

第三部分

当你回答以下问题的时候，请回想一下你在团队中的经历

1. 请评价您对以下声明的同意或不同意程度

• 如果我对我们的团队犯了错误，也不会有不良影响。
• 我们团队的成员能够发现问题和提出棘手的问题。
• 我们团队的成员不会因为差异性而互相拒绝。
• 对我们的团队而言冒风险是安全的。
• 想让我们团队的其人提供帮助并不困难。
• 我们团队中没有人会以任何形式故意破坏我的工作成果。
• 团队非常重视我独特的技术和才能。
• 我们的团队能够在出现冲突时解决冲突。
• 我们团队内部有很高的信任度。

（强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）

2. 当你回答以下问题时，回想你是如何和你的团队合作的

请评价您对以下声明的同意或不同意程度：

• 当我的团队成员之间存在相反的意见时，我们会互相尊重。
• 我可以依靠我的团队来产出高质量的成果。
• 我的团队提供了一个可以创新的环境。
• 我的团队有明确的角色和责任。
• 我的团队所承担的项目对我来说具有个人和专业意义。
• 我能够获得有效完成工作所需的必要的信息（例如，战略、新产品、组织变革，我们的优先事项和价值观）。

（强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）

3. 回想一下你的团队是如何工作和组织的

请评价您对以下陈述的同意或不同意程度。

对于您使用的主要应用程序或服务：

• 为了完成我自己的工作，我不需要与团队外的人沟通和协调。
• 在我的团队中，我们可以对系统的设计进行大规模更改，而无需为其他团队创建重要的工作。
• 在我的团队中，我们可以对系统的设计进行大规模更改，而不用依赖于其他团队的大量工作。
• 我的团队可以根据需要独立部署和发布我们的产品或服务，而不依赖于其依赖的其他服务。
• 我们可以按需的进行大部分的测试，而无需等待一个集成测试环境。
• 在我的团队中，我们在正常工作指端中执行部署，停机时间可忽略不计。

（强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）

4. 最后，我们想了解一下您的组织文化

请评价您对以下声明的同意或不同意程度：

• 我的组织氛围宜人，重视各种不同的观点。
• 我的组织是一个所有类型的员工（例如，所有性别，种族，文化背景）都能够完全发挥其能力的地方。
• 当我在组织中发言时，我的意见很受重视。

（强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用）

第四部分

这部分关于你所处环境中知识是如何供给和获取的。 让我们换个角度，告诉我们您的日常工作。

1. 当您工作时，您会在哪里寻找信息？

• 当我需要相关知识用于解决问题时，我会频繁访问外部信息（如Stack Overflow、百度等）。
• 当我遇到具有挑战性的问题，需要寻找类似问题的解决方案时，我经常访问外部信息 (如Stack Overflow、百度等)。
• 当我处理困难的任务时，我经常和可能遇到类似问题的人沟通。
• 当我需要工作相关主题或问题的知识时，我经常与其他人讨论。
• 在处理任务时，我经常会参考内部知识库或工具来帮助找到解决方案。
• 当我处理具有挑战性的问题时，我经常搜索内部工具或代码库以便找到类似问题或示例的解决方案。
• 当我有疑问或寻找代码示例时，我经常搜索组织的源代码库
• 当我有疑问或遇到有挑战的问题时，我会搜索内部文档

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

2. 当您遇到问题时，您会定期检查哪些信息来源？请选择所有适用项

• 内部(组织)知识库、论坛或文档
• 内部(组织)代码库
• Stack Overflow 网站
• 在线教程和视频
• 百度、Bing或其它类似的公开搜索引擎
• 外部(公共)参考文档
• 当面请教同事
• 通过电子邮件、文本或聊天工具请教同事
• 朋友或同行(如微信、网络兴趣组、微博等)
• 您自己的个人笔记
• 其它。请填写
• 以上都不是

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

第五部分

这部分关于你的角色，以及你们团队做变更的特征和模式等。

1. 现在让我们谈谈您工作时的感受

无论您的正式职位是什么，让我们谈谈您所做的工作。在您的日常工作中，您负责多少个不同的角色（或工作类型）？请选择所有适用项

• 软件开发
• 测试
• 基础设施/运营
• 数据库管理
• 信息/应用安全
• 人员管理
• 项目或产品管理
• 文档
• 需求分析
• 用户体验
• 随时待命/事件响应
• 其它。请列出您执行的其他角色

2. 您每天在这些角色之间切换多少次？

• 不想回应
• 0
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20或以上

3. 您现在正工作在多少个项目或产品上？

• 不想回应
• 0
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20或以上

4. 您通常在一周中工作在多少个项目上？

• 不想回应
• 0
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20或以上

5. 思考下你过去3个月的工作。 请以这些记忆里的工作对以下陈述进行回应

我遇到过的代码，脚本，配置或系统……

• 包含已知的错误，这些错误不支持新功能开发
• 没有足够的测试或测试覆盖率
• 与低下的代码质量或设计有关
• 取消或放弃项目后尚未进行清理
• 在我所在的团队中没有人有专业知识能够理解
• 有不完全或不正确的迁移
• 使用了过时的技术
• 文档和/或注释存在缺失、不完整或过时的情况

6. 现在思考在你的组织中的进行变更及相应流程是什么样的

在我的组织中……

• 在实施或部署之前，必须由外部机构（例如，变更审批委员会，经理等）批准生产变更
• 我的组织有一个正式的流程来批准在实施或发布之前对应用程序或生产系统进行变更。
• 我清楚地了解批准实施​​变更的流程
• 我相信我能够及时通过审批流程来实施变更
• 对于我通常所做的各类变更，我知道每次从“提交”到“已接受”所需的步骤。
• 我们依靠同事的同行评审（例如代码审查或结对编程）来管理或批准变更。
• 我的团队遵循基于风险的政策来批准变更，通过自动化方法推进低风险变更，只有高风险变更才需要人工批准。
• 所有重大变更必须在实施前由高级经理批准

第6部分

对于此页面上的问题，请思考你为测试生产系统的弹性所做的工作。

1.以下哪些活动用于测试我们的IT系统/服务的弹性？

• 未在真实系统上进行沙盘推演
• 基础设施（包括数据中心）故障转移
• 应用程序故障转移
• 模拟破坏类生产的测试系统（包括故障注入、如降级网络链路、关闭路由器等）
• 模拟破坏生产系统（包括故障注入，如降级网络链路，关闭路由器等）
• 创建自动化和系统，定期，持续地破坏生产系统
• 其他。 请明确说明：
• 以上都不是

2. 你所在的组织多久执行一次中断生产系统的模拟（包括故障注入，例如降级网络链路、关闭路由器等）

• 从不
• 仅在初次部署
• 按周
• 按月
• 按年
• 少于一年一次
• 不知道或不适用

3. 你所在的组织多久执行一次基础设施（包括数据中心）故障转移以测试弹性？

• 从不
• 仅在初次部署
• 按周
• 按月
• 按年
• 少于一年一次
• 不知道或不适用

4. 你所在的组织多久执行一次应用程序故障转移以测试弹性？

• 从不
• 仅在初次部署
• 按周
• 按月
• 按年
• 少于一年一次
• 不知道或不适用

5. 如果我的组织在灾备演习时发现了任何改进的机会，我们会创建行动任务并在下一次演习前修复这些改进项

• 非常同意
• 同意
• 有点同意
• 既不赞成也不反对
• 不太同意
• 不同意
• 强烈反对
• 不适用或我不知道

第七部分

此页将会询问您或您的组织关于云应用的一些问题

1. 我主要负责的产品或服务在哪运行？（请选择所有适用的选项）

• 公有云（包含多个公有云）
• 私有云
• 混合云（将公有云和私有云/数据中心/本地设施结合在一起）
• 在数据中心或本地（不是云）
• 我桌面下的一个小服务器
• 其他

2.采用多个云提供商的驱动因素是什么？（请最多选择3个）

• 我们只有一个云提供商, 或者我们没有使用公有云
• 法律合规性
• 灾备可用性
• 对一个供应商缺乏信任
• 利用每个提供商的独特优势
• 谈判策略或采购要求
• 其他

3.请评价您对以下陈述同意或不同意的程度

• 我主要负责的产品或服务最初是设计在云中运行或基于云设计架构的。
• 对于我主要负责的产品或服务, 环境配置和部署仅使用存储在版本控制库中的脚本和信息, 无需手动步骤 (审批除外)。

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

4.请评价您使用云服务时对以下陈述的同意或不同意程度

• 一旦我有了访问权限, 我就可以根据需要独立地配置和配置产品或服务所需的云资源和功能, 而无需提高票证或需要人工交互。
• 我主要负责的服务或产品设计为通过网络从各种设备 (如智能手机、平板电脑、笔记本电脑) 访问, 而不需要专有插件或协议。
• 我的产品或服务所运行的云，服务于多个团队和应用程序, 并根据需要动态分配和重新分配计算和基础架构资源。
• 我可以根据需求动态地增加或减少可用于主要支持的服务或产品的云资源。
• 我可以监视或控制我主要支持的服务或产品所使用的云资源的数量和成本。

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

5.换个主题，在您工作的时候，您是怎样看待成本的？

• 我的团队可以准确地估计操作我们软件的成本。
• 我的团队可以轻松识别我们运营成本最高的应用程序。
• 我的团队很少超出我们的成本费用或支出预算。

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

第八部分

关于版本控制系统、分支模型、自动化测试、持续集成、持续交付等一直到生产环境的反馈等等实践。 现在让我们谈谈您和您的团队所做的技术工作。

1.请介绍一下您和您的团队如何开发软件。我的团队

• 我们的组织将所有代码存储在一个单一庞大的版本控制存储库中

• 组织中所有工程师都可以查看和搜索组织中所有代码
• 我可以在自己之外的项目中编辑代码，并适时提交
• 我们将应用程序的所有依赖项源代码（例如软件库）都存储到版本控制存储库中
• 我们为发行版本创建的所有包，包括依赖项，都是在单个版本控制中创建的，而不是从多个版本或分支中创建的

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

2.我们关注您工作中使用什么代码，请评价您对以下陈述同意或不同意程度

• 如果需要，我们很容易更改其他团队维护的代码

• 我很容易在代码库中找到示例
• 我经常从团队之外的工程师那里收到项目的更新。
• 我很容易重新使用别人的代码
• 我很容易对我的项目增加新的依赖项
• 我很容易移动新的依赖项版本
• 我的依赖项是稳定的很少破坏我的代码

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

3.我们关注您在工作中遵循的开发实践和模式

• 我团队中的所有开发人员至少每天都会将代码推送到trunk / master

• 应用程序的代码库中不到三个活动分支
• 我们的应用程序团队从来没有代码锁定期，任何时候没有人可以签入代码或由于合并配置而执行请求。
• 在合并到master之前，分支和分叉的生命周期非常短（不到一天）。

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

4.下一组问题是关于在工作中提交代码、搭建和部署软件

对于您使用的主要应用程序或服务：

• 代码提交会自动生成软件
• 代码提交会运行一系列自动化测试
• 每天成功地执行自动化的构建和测试
• 当构建中断时，它通常在十分钟内修复

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

5.许多团队使用自动化测试来优化他们的软件

请评价您对以下陈述的同意或不同意程度 回答这些问题时，请考虑您自己的测试过程：

• 当自动化测试通过时，我确信软件是可发布的
• 自动测试失败可能表明存在真正的缺陷
• 开发人员很容易重现和修复验收失败的测试
• 我们测试必要的数据，以便每一步都能轻松运行自动化测试
• 我可以在十分钟内从自动测试中得到反馈
• 我们经常使用之前的测试运行数据来提高自动化测试套件的质量

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

6.请评价您对以下陈述的同意或不同意程度

对于您使用的主要应用程序或服务：

• 我们的软件在整个生命周期中都处于可部署状态
• 我的团队优先考虑保持软件可部署而不是处理新功能
• 团队中的任何人都可以获得系统在质量和可部署性方面的快速反馈
• 当人们得到系统不可部署的反馈时（例如构建或测试失败），他们将优先解决这些问题
• 我们可以根据需要随时将我们的系统部署到生产或最终用户

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

7. 请结合自己的测试过程回答以下问题

• 当通过自动化测试后，我相信软件是可发布的。
• 自动化测试失败表明存在真正的缺陷。
• 开发人员很容易重现并修复验收测试发现的缺陷。
• 我们有必要的测试数据，用于每个步骤中轻松地运行自动化测试。
• 我可以在10分钟内收到自动化测试反馈。
• 我们经常使用以前测试运行的数据来提高自动化测试套件的质量。

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

8. 对于您工作的主要应用或服务

• 我们的软件始终处于可部署的状态。
• 在我的团队中，保持软件处于可部署状态的优先级高于实现新需求。
• 任何团队成员都可以快速反馈系统的质量和可部署性。
• 团队成员将修复导致系统无法部署的问题（如编译失败、测试失败等）置于最高优先级。
• 我们可以随时根据需要将系统部署到生产环境或最终用户。

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

9. 对于您工作的主要应用或服务，实现完全自动化部署到生产环境或最终用户的比例是

• 0%-15%
• 16%-30%
• 31%-45%
• 46%-60%
• 61%-75%
• 76%-100%
• 我不知道或不适用

10. 对于您工作的主要应用或服务，部署过程需要多长时间才能使软件新版本可供用户使用

• 小于1小时
• 在1小时和1天之间
• 在1天和3天之间
• 在3天和1周之间
• 在1周和1个月之间
• 大于1个月
• 我不知道或不适用

11. 您如何监控和了解正在运行的系统

• 我的团队有一套技术解决方案用以报告系统的整体健康状况（如系统功能是否正常？系统是否有充足的可用资源等？）。
• 我的团队有一套技术解决方案用以报告基于用户使用情况的系统状态（如用户是否知道系统已关闭，是否有不良的体验等？）。
• 我的团队有一套技术解决方案用以监控主要业务和系统参数。
• 我的团队有工具用于协助我们了解和调试生产环境上的系统。

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

第九部分

这页面询问了一些细节关于您的技术环境和工作

请选择以下之一

1. 为了部署我们的软件解决方案，我的团队使用以下CI / CD /测试自动化工具链

• 主要是内部开发（自研）的，且所有权属于我的组织
• 混合使用专有工具，开源和商业现成软件
• 主要是开源和商用现货，高度定制
• 主要是开源和商用现货，很少定制
• 主要是商业现成的套装软件
• 主要是开源的，高度定制
• 主要是开源的，很少定制
• 其他
• 不适用或我不知道

2. 请评价您对以下说法的同意或不同意程度

• 在我的团队中，与组织中的其他团队相比，我们的CI/CD/自动化测试过程和工具是为我们的需求而定制的

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

3. 请评价您对以下说法的同意或不同意程度。 通过CI / CD工具链部署软件时

• 使用CI / CD工具链可以提高我的效率在我的工作中

• 使用CI / CD工具链在我的工作中提高我的生产力
• 使用Ci/CD工具链提高了我的工作效率
• 我发现CI / CD工具链在我的工作中很有用。

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

4. 请评价您对以下说法的同意或不同意程度。 通过CI / CD /测试自动化工具链部署软件时

• 我的交互在工具链是清晰易懂的

• 与工具链交互并不需要我的大量精力
• 我发现工具链容易使用
• 我发现容易让工具链做我想要做的事

(强烈反对 不同意 不太同意 既不赞成也不反对 有点同意 同意 非常同意 我不知道/不适用)

5. 选择最能代表谁负责创建和维护CI / CD /测试自动化工具链及其配置的选项

• 我们的团队有完全自治选择和配置自己的CI / CD /自动化测试的工具链。

• 我们需要使用一个统一工具链，但是我们为构建/测试/部署过程维护自己的脚本，并且在配置方式上有很多自主权。
• 我们需要使用一个统一工具链具有预配置脚本和构建步骤，测试和部署过程的步骤，我们可以根据需要重构或自定义。
• 我们需要使用带有预配置脚本和步骤的统一工具链，而我们几乎没有能力重构它
• 所有构建，测试和部署软件，都由我们建立的统一团队处理
• 不适用或我不知道

6. 我的工具链包括以下内容（请选择所有适用的选项）

• 自动化构建

• 自动化单元测试
• 自动化验收测试
• 自动化性能测试
• 自动安全测试
• 自动化配置和部署到测试环境
• 自动化部署到生产
• 与chatbots / Slack集成
• 与生产监控和可视化工具集成
• 以上都不是

第十部分

最后一页！请花几分钟时间告诉我们你自己。 请注意，此数据仅用于研究目的，此调查是匿名的，仅以匿名方式汇总报告。

1. 你的性别？

• 男
• 女
• 非二元
• 不想回应

2. 在您的团队中工作的女性比例是多少？

请输入0到100之间的数字。

• 女性团队的百分比： [___]
• 不想回应

3. 您是否认定为少数派群体的成员？

• 是
• 没有
• 不想回应

4. 你认定是残疾人吗？

包括与视觉，听觉，步行，记忆/集中，自我保健或沟通相关的残疾

• 是
• 没有
• 不想回应

5. 哪个最贴切地描述了你的工作角色？

• 开发或工程师
• DevOps或SRE
• 信息安全
• IT运营或基础设施
• 网络运营
• 产品管理
• 用户体验或软件分析
• 经理
• 专业服务
• 质量工程师或QA
• 发布工程师
• 销售工程师
• 销售或营销
• 我是顾问、教练或培训师
• 我是C级高管
• 我是学生
• 我不属于任何部门
• 其他
• 不想回答

6. 你有多少年的经验？

• 0-2
• 3-5
• 6-10
• 11-15
• 超过16
• 不想回应

7. ­­­­­请选择您所在的地理区域

• 非洲
• 亚洲
• 中美洲
• 东欧洲
• 欧洲联盟
• 中东
• 北美
• 大洋洲
• 南美洲
• 加勒比

总结

本文是否帮你解答了这样一个疑问：每年的DevOps状态报告中的参考数据是从哪里来的？是通过什么方式采集的？到目前为止，我们还不清楚这些数据是通过什么打分规则和算法处理的。如果你是这方面的专家，请和我们分享以下你的观点。