重磅 | ONES加入DevOps标准工作组，CTO冯斌于DevOps国际峰会发表演讲

ONES

日前，DevOps 国际峰会（DOIS）2018 · 深圳站正式召开。会上，ONES获得由中国信息通信研究院云计算开源产业联颁发的DevOps标准工作组成员单位证书。该标准即《研发运营一体化(DevOps)能力成熟度模型》，由中国信息通信研究院云计算开源产业联盟、高效运维社区等机构联合发起，为全球首个DevOps标准。

《研发运营一体化（DevOps）能力成熟度模型》覆盖软件交付生命周期全流程，包含敏捷开发管理、持续交付、技术运营、应用设计、安全及风险管理、评估方法、系统和工具平台8个部分。该标准汇聚了国内互联网、通信、金融等行业顶级单位及专家联合编写。目前，DevOps标准已在国际电信联盟（ITU，联合国下属唯一官方标准化组织）正式立项。

基于对研发管理的理解、对ONES大量企业应用案例的分析，ONES联合创始人&CTO冯斌老师作为编写专家参与该标准撰写工作。同时，ONES目前上线的四款产品均已加入《研发运营一体化(DevOps)能力成熟度模型》产品标准工具图谱。

*高清大图请查看：http://i2.bvimg.com/667775/16...

本次大会上，冯斌老师也作为大会嘉宾进行了主题为《DevOps Best Practices》的分享。

冯斌，ID: kidfeng，EXIN DevOps Master，系统分析师；中国信息通信研究院研发运营一体化（DevOps）能力成熟度模型编写专家；TGO鲲鹏会成员，珠三角技术沙龙深圳组委会成员；具有11年研发管理经验，精通 Android、iOS、Web、后端 Java/Golang 等开发工作；曾任职于金山软件、网易邮箱、正点科技，现任ONES联合创始人&CTO，主要负责ONES企业级研发管理解决方案的技术、产品相关工作，致力于敏捷开发与DevOps的最佳实践。

以下为当天分享重点内容整理：

    背景    

现代化商业社会的变化速度非常快，不确定性很高，经常需要在信息不完备的情况下做商业决定，这已经是一个商业社会的常态。从软件的角度来讲，只有实现快速、可控、可预测的交付，才能更好的实现整个公司和商业组织的商业价值。

基于以上背景，我们认为目前国内缺少一个专业管理研发工作的软件，因此成立了ONES。ONES为企业提供专业研发管理解决方案，目标是覆盖研发全流程，帮助研发团队高质高效交付产品。

*VUCA是Volatility、Uncertainty、Complexity、Ambiguity的缩写

  01 敏捷开发实践原则  

敏捷是DevOps的一部分

敏捷工具的重要性

敏捷宣言中有一种思想是『工具并不重要』，但这是有问题的，并不适用大型团队的研发场景。从ONES的实践经验来看，工具在研发过程中可以发挥很大作用。如果整个团队的信息是记录在纸上或者在Excel上面，进行度量数据就会有很大难度。因此，研发团队需要结构化的方式去存储和管理相关的数据，这有利于团队进行信息分享、回溯、聚合决策总结等工作。

*ONES Project看板视图

所有任务和问题都应该被记录到系统中

在研发过程中使用系统的一个优点是不会有遗漏，所有想法都可以保存并得到跟进，所有问题的处理过程及结果都可以查询，这对于软件研发来说是很重要的。ONES在实践中发现，一些大型的公司（比如西山居、虎牙直播等）都愿意使用系统来管理研发过程。而也有一些公司在推进系统时觉得学习成本高、使用麻烦，依旧使用表格或其他手段记录数据。但这些方式容易遗漏信息，也不利于团队成员间的信息分享。

Story > Backlog > Sprint

在整个产品规划过程中，Story、Backlog、Sprint可能分别是由不同的人来负责的。Story可能指向产品总监，这是在产品上有一定决定权的人；Backlog可能需要产品经理、项目经理或者是研发负责人共同负责。这就需要一些工具来帮助团队进行研发协作。

*ONES Project迭代管理

沟通、总结、改进

产品迭代阶段结束，并不意味着研发工作结束了。版本发布上线以后，还需要及时做沟通、总结，并探讨如何改进。精益理念曾提到，发布不是结束，只有当用户真正使用到这个功能时，这个功能才算开发完成，才真正实现了它的商业价值。

  02 DevOps实践原则  

更小、更频繁的变更

不言而喻，更大的变更会积攒到一个更大的问题，修复成本可能更高，停机时间可能更长。在ONES内部，一周或者是三天是一个比较好的变更周期。

尽可能自动化

自动化的优点是可重复、更精准，无随机错误。人力无论做任何操作，下一次都可能是不一样的。而自动化会使工程师从枯燥的操作当中解放出来。更重要的一点是，自动化可以快速验证代码有没有问题，最好的状态是提交的代码可以在五分钟之内得到反馈。

尽快修复持续集成的问题

如果持续集成出现了问题，一个小时去修复与一周之后去修复，效率是完全不同的。同时，对于外部的业务部门来说，研发看起来几乎是黑箱的。所以使产品随时保持一个可用可演示的状态，对整个软件研发团队，对于公司内其他团队，都是一个非常重要的建立信心的手段。

分工是把双刃剑

分工使得每个人可以专注于更少的事情，效率有所提升，但是局部目标容易偏离整体目标。所以需要所有的团队成员从全局考虑，将“用户成功使用到这个功能”做为最终目标，这样每个人做出的决策在全局看来才是最优决策。

持续改进

DevOps不是一蹴而就的事情，必须坚持量化数据、做好对比、持续改进，这是需要长时间践行的事情。

    现场提问    

Q：DevOps的测试阶段，现在大部分是增量迭代上线，这些数据该如何准备呢？测试的数据是专门的数据库，数据的质量和体量达不到最终测试要求，但是又没有办法直接连接线上数据。

A：首先要看测试环境是否会像生产环境有一样的硬件投入，如果是，可以用一种简单的算法把线上数据脱敏后在内部使用。但很多时候线上运行的是一个大集群，可能是百千台服务器；而实际测试环境只有几十台服务器，只能是根据业务的需要降级去做。所以最好是从线上提取一部分数据来使用，但是如何取样要看产品本身的需要。

Q：我们做DevOps的过程中，因为团队职责不一样，大量的矛盾都在快速迭代的时候凸显，有什么方法能避免这个问题呢？

A：这可能是因为给团队定的目标有问题。之前有讲到，所有跟这个迭代有关的人，包括开发、运维都应该在一开始一起开需求沟通会。ONES的产品经理在需求沟通会的开始就会说我们想做功能A，会交代很长时间的背景。这是希望告诉其他成员，无论是开发还是运维，最终是想要达到同一个目标。如果这个目标有问题我们可以讨论；如果没有问题，我们就继续讨论如何执行。如果一开始给运维团队定的KPI是追求线上服务稳定，那么就割裂了不同职能之间的考核标准，就会使他们在想法、做法上有分歧。所以应该在更高的层面上解决问题，工作目标在开始的时候就定好。

- End -

点击下方“阅读原文”，马上免费使用 ONES！

↓↓↓