本帖最后由 adminlily 于 2018-10-17 16:46 编辑
DevOps目标在于加快软件发布和部署流程速度，加强自动化，降低系统出错频率，并且能更快地消除宕机和错误的影响，提高企业的业务敏捷性，降低IT成本。
我们采访了涉及DevOps领域的300位专业IT人员，他们是如何又为何使用DevOps的？通过这些观点，我们发现：
采用率正在增长：18%的受访者表示已经部署DevOps实践，而且有32%的人计划在未来12个月内部署。只有20%的人表示无意采用DevOps。
现如今，敏捷开发方法已经被广泛采纳，他能促进开发者更快更多的更新迭代，从而发现其他应用部署和售后流程中的瓶颈。发现瓶颈并突破它对公司或者开发者来说都是好事，这也正是DevOps试图去做的。DevOps实际上可以被看作是敏捷开发到所有基层后开发活动的延伸。我们的报告中，有60% IT行业的专业人员都表示正在使用敏捷开发的方法，38%的表示正在混合使用敏捷开发和其他开发方法。只有4%的受访者表示这些都没用过。（如下图）
随着敏捷开发理念的愈发清晰和明确，DevOps的部署变得并不那么容易了。比如我们2014年做采访时，100%的IT专业人员表示自己或多或少对DevOps都有所了解，现在有15%的人承认他们根本不了解。而且与14年相比对DevOps非常熟悉的人也减少了4%。这个现象出现的原因一部分是由于早期对DevOps的误解，还有一部分是DevOps参与者的角色在近几年发生了变化。
DevOps的角色和结果
根据调查得出，80%的受访者表示自己参与程序开发，而且担任IT、开发和系统管理的人数都差不多。64%的受访者是IT管理层或者IT/IS员工，23%担任主管或其他的公司领导角色。
当被问到IT团队管理的应用数量时，62%的受访者表示正在管理1-20个应用，22%的在20-40个之间，16%的表示管理了40-60个甚至更多的应用。
(F17)其中46%的人表示只要10个甚至更少的应用在每年更新，24%的人表示有10-20个，接近有10%的人表示有超过60个。
（F18）对新的应用而言，63%的人表示每年新部署的应用不超过10个，21%的人表示在10-19个之间，剩下的16%表示会部署超过20个新应用。
DevOps采用率
相比过去，今年的DevOps的采用率正在增加。例如，相比2014年近30%的受访者没有采用DevOps的意愿，16年仅剩20%。
（F4）
当然，随着需要管理的应用越来越多，采用率上升不足为奇。DevOps采用的关键因素包括提升产品质量、减少复杂度和减少整体IT成本。（F5）将近有一半的受访者表示移动化和云的部署也驱动了DevOps的采用。
并不是一个公司的每一个开发团队都会采用DevOps，实际上，只有不到5%的人表示就他们自己用DevOps，50%多的表示他们开发团队的DevOps采用率在25%到50%之间。而且虽然有35%的人表示虽然现在没有开发团队采用DevOps，但是最近已经有了采用计划。
（F25）DevOps采用的最大阻碍包括：业务需求缺失、专家缺失或者时间和资源缺失。
(F6)
另外，也有一少部分开发和运营团队合作的兴趣缺失的原因。这也表明脱离了业务和领导的支持，而且没有培训的情况下，IT部门自己采用DevOps并没有那么容易。
根据咨询师Dan North在2016年虚拟DevOps峰会上的讲话，一方面成功的考量在于缩短开发工作的排队时间。当被问到从提出提出请求到实施之间的时间间隔时，不到25%的人表示时间会少于一个小时。30%多的人表示时间会在一个小时到一天之间，45%的人表示会超过一天，或者他们不知道（或者他们并没有计算过）。
更精确一点的话，20%的受访者表示从开发周期完成到产品成型的时间超过一周，只有7%的人表示他们可以在一个小时之内完成。更糟糕的是，有接近10%的人表示会花费超过一个月。
（F7）DevOps并不单单只能缩短时间，而且还能衡量所有改变和结果、建立反馈回路并持续增加运营效率。其中还包括对开发、IT团队和整体公司文化之间的关系提升。43%的受访者表示运营人员的意见也被采用到未来产品功能加强的考虑中来，41%的人说开发团队与应用部署关系更加密切了。其他文化的改变包括运营团队参与开发团队会议和与工作人员沟通机会的增加。更重要的是，25%的人表示我了更好的匹配开发和IT部门的目标，公司的管理结构也发生了变化。
（F26）
真实的好处
已经有25%的受访者表示DevOps的采用已经为公司节约了成本，同时有20%的人表示收入增加了。其他排名高的DevOps好处还包括增强协作（46%）、更高频次的软件部署（39%），应用维护时间减少（39%）以及应用质量和表现提升（38%）。
（F27）
结合上述结果，我们有追问了几个其他可能带来的利好，大多数的受访者都表示提升不是特别明显。（F8）但是在对业务重要的几个利好因素（质量提升、收入增加、面市时间减少等等），表示DevOps提升明显的就比较多。
有接近80%的的受访者表示已经或者期待看到DevOps对产品稳定性有所提升（15%表示谈这个为时尚早），78%的人表示已经或者期待看到对应用表现的提升。
（F28）但是，在安全性问题上，有一小部分人表示产品安全性会降低，这也是DevOps现在提升不明显的地方。（F9）这也许不是DevOps本身的错，安全性增强需要专业的工具去做，这也可能会是工具供应商的一个机会。 工具和自动化
DevOps相比起工具，更应该被看成是一种流程和理念（使开发者在运营活动中发挥更大作用，IT团队更多参与到产品定义中），以及为容易出错的人工活动实现自动化。当被问到哪些工具最重要时，功能测试、表现测试和发布自动化排名前三。
（F10）关于协作方面，36%的受访者选择GitHub，35%选择Microsoft Teams，选择Slack的占24%，选择Confluence的也占24%。在DevOps管理工具上，PowerShell、Docker、Puppet和Chef毫无疑问的霸占着前四名，Ansible紧随其后排名第五。
很意外的是，居然有26%的受访者承认并没有使用任何DevOps管理工具。
在发布自动化工具上也有着类似的结果。比如，在Microsoft、IBM、CA科技和BMC占据前列的同时，也有很大一部分的受访者表示现阶段没有购买计划。（F32）其中一部分原因可能是开源工具在商业授权和支持协议上没有要求。另一部分是大家可能更倾向于自己DIY。
举例来说，把要做的事通过API和脚本构建在软件产品中是实现自动化发布的一种方式。实际上，像command line、Python、PowerShell和PERL也排在使用量的顶端。
（F11）70%的受访者表示现在一般由IT人员为API集成写脚本来实现自动化部署，只有11%的人没有计划自己做。
(F24)DIY风潮的兴起也可能会导致自动化工具的成熟度确实，或者他也可能只是IT人员的一种文化。无论如何，任何DIY都会面临专有的、解决方案容易出错的风险，而且这也可能是未来DevOps的发展方向。
当错误出现的时候
受访的超过一半的IT专业人员每月会经历1-5次应用报错，14%的会遇到6次甚至更多。
(F12)
虽然有很大一部分受访者表示已经通过监测报警系统得知程序发生了故障，但仍有59%的人是通过客户的投诉得知的。（F20）好的DevOps不仅要帮助消除BUG，还得能够帮IT部门及时发现和补救。
确实现在没有不发生BUG的东西，所以及时恢复系统稳定变得十分重要。我们采访的绝大部分人都表示恢复稳定只需要不到半天。
（F13）但是，只有34%的人可以做到30分钟以内，而且还有需要一整天甚至更多的。无论时间长短，让用户忍受宕机或任何类型的故障都会造成糟糕的体验。
避免这种情况的发生需要经过大量的部署过程和故障恢复过程的测试。我们调查发现，只有69%的受访者承认有在测试。
（F21）
我们对DevOps的调查旨在帮你发现DevOps在行业实践的现状。其中一些结果也能够给予DevOps在其他公司额发展方向。 例如，受访的大部分人都表示未来计划加大DevOps的投入，只有12%的人表示未来没有投资计划。
（F14）
我们的调查还发现项目管理、问题追踪、协作和自动化工具的投资占据未来DevOps投资计划的头几名。
（F31）
另外，62%的受访者表示计划招募DevOps的转件。
（F36）
DevOps和公有云部署时有很多相似的事情，例如对自动化部署的需求、管理和监管工具的增加、为运行中断和恢复做的规划以及对安全性的需求增加。实际上，超过一半的受访者表示他们正在或已经计划使用公有云的平台或基础设施部署应用了。另外，大多数人表示云自动化和云管理技术对他们的DevOps计划很重要。
（F15） 发展时遇到的困难
尽管在持续成熟，IT公司在DevOps使用时仍然面临许多挑战。安全性、成本、缺少企业级的合作和支持以及技术不足是面临的首要挑战。（F16）幸运的是，未来的投资和发展计划将会帮助公司客服这些问题。另外，新的IT趋势（例如公有云）也可能为DevOps的采用带来帮助。
如果通篇报告读下来你只能记住两点的话，请记住：好的DevOps方法可能带来的好处就已经值得投资了，但是，在DevOps部署前一定要仔细考虑和评估需求。
原创： T客汇
| 
转播
分享
淘帖
()