2018-03-21 14:05

　　萧田国：我主要分享的是研发运营一体化的体系以及模型。

　　今天讲五部分：

　　第一部分 Diango及缘起

　　第二部分Diango能力成熟度模型解读

　　Diango能力成熟性模型核心贡献者

　　Diango能力成熟度模型本次重磅发布

　　Diango能力成熟度模型撇故参与办法

　　DevOps起缘于2009年。DevOps是针对于敏态业务，如果你们的业务跟互联网相关，需要用DevOps的理念。作为DevOps而言首先它是技术的集大成者，DevOps没有发明任何技术，但是有一点，所有的技术归根到底都是为它所用的。为什么？因为DevOps是一个概念，它从技术上升到了整个业务层，包括它会建议你组织结构的变革。

　　DevOps一些比较实际的价值所在，第一，根据在国外的一些调查，它的部署频率高提高46倍，交付时间缩短440X，稳定性提高96，变更失败率降低。

　　所以作为我们一个社区组织有机会跟国内外顶级专家合作，我们提出一个观点就是DevOps道法术器，包括快速交付价值、灵活响应变化，全局打通敏捷开发、高效运维。还就是术，就是系统应用自导原则最佳实践，端到端工具链互联互通和整合。

　　今天重点是关于标准这块的，我们的标准是研发运营一体化能力成熟度模型，很多人说水是固定的形态，是最佳实践许多标准才对，不是这样的，水它是像DevOps，但是喝水是不是需要容器，所以DevOps在各个行业实施，至少行业里有很多共性存在的。这也是我们做这个事情价值所在。

　　DevOps的标准，它是能力成熟度模型。我们这个东西做出来用来企业内部自己评估的。我们运维就是如果你做到3.5级就是很好的水平了。我们称它为标准体系原因所在，在于总共有7个标准，第一是整体架构，第二过程这块有三个标准，敏捷开发感觉、持续交付以及技术运营。还有一些标准包括应用设计、分享管理以及组织结构这些。

　　敏捷开发管理的主笔是很多技术专家和国内顶级敏捷专家一起做的修正。持续交付里面很多专家都是来自于我们社区。技术运营标准，这里很多子模块都是国内最顶尖运维专家来做的，还包括电信行业等等。

　　最后是一个组织结构。

　　2017年11月份我们发布了一个初稿。 目前我们的标准现在已经是在工信部正式立项成功。

　　我们的标准有七个，总体架构、敏捷开发、持续交付、技术运营、应用设计、风险管理和交付。

　　首先是第一个大的模块敏捷开发管理：敏捷在国内是有流派之分的，我们集合了两三个主体流派和结合他们的理念，在新的敏捷开发管理里，一个是需求管理，一个是敏捷写作管理以及计划及交付管理，我们还有一个争论，标准本身是不是把敏捷两个字去掉，直接变成开发管理，我们这里会有这样的一个亮点，我们会强调的是最左上角的价值交付。然后这个图，这里特别强调的是协作，这种协作实际上还只是开发和测试之间的，关于这里面标准的很多内容我们希望能往运维侧做延伸。

　　协作里面包括敏捷和团队的合作，以及团队团队之间的合作。

　　第二个是持续交付的标准。有一个好消息，刚刚这个标准更新版已经做完了，待会儿会有一个正式发布链接出来。

　　还有一个持续交付标准，这个标准是我们这里做的最成熟的标准，首先包括配置管理和构建与持续，数据管理、环境管理、部署与发布，所有这些是我们标准的一个子域和子子域的内容。

　　还有一个标准就是技术运营标准。或者说它更多关注的是跟运维相关的。很多同学知道我们社区人在2000年的时候曾经做过互联网运维能力的成熟度模型，做完以后我们觉得很不错了，以为做好了，目前来看，真正跟DevOps融合的时候，把去年的那个运维模型全部推翻了，重新写了这些内容，这些内容关注到的不仅仅是互联网的技能，包括传统的厂商电信或者金融行业的。

　　往下看，首先是监控管理，我们是按照过程来做的，首先是指标采集、监控数据处理、日常识别和监控可视化通知，后面是事件管理，包括变更管理还有容量与性能管理。其实这里头大家看得到，事件管理和变更管理还是会存在的，因为这对于运维而言总是有很多工作不能被自动化的。这里还包括成本管理、用户体验和最最重要的运维一体化。

　　我们强调的是你能不能在运维侧，利用一个工具能够实现整个运维一体化。像刚刚郭老师提的一样，现在很多时候运维有很多工具，但是每个工具都是基于一两个页面做的，能不能串起来，能不能让它的赋予一个逻辑结构，赋予它们一个生命力。

　　这里有基于腾讯游戏很多经验和他们的实践，这时候把运营一体化分为四个阶段，首先是IaaS管控层，原子平台层SaaS层和运营层。

　　还有包括应用设计的标准，应用接口、应用伸缩和故障处理。

　　还有一个标准就是组织、结构这块，我们也分了一些类别。

　　所以刚才是我们这样的一些导图，再接下来是一些案例，我们会有具体的案例。在敏捷开发管理这块，会有一个敏捷计划管理，包括有一些交付与需求交付质量、交付反馈等等。我们首先的写法是会有一个格式，包括同上且同上，我们希望标准拿出去以后企业是能够落地评估的，这时候假设一个企业通过评估很遗憾只是二级，这时候如果说他要过三级，这时候会有很多评估项目。

　　我们看得到，利用说想到三级很不容易了，如果做到三级是同上且有稳定的交付节奏和产品和优先级持续交付，当发生产品情况的时候所有产品需求和交付计划统一完成。

　　第二部分是交付过程，交付过程目前列出来的只是第三级，我们说作为DevOps最酷的一点，它关心是价值流动，不仅仅只关心资源提升。以前开发部门是关心它的代码更多的被开发，测试部门关心BUB更多的被找到这种过渡的局部优化对于整体系统而言是有害的。过于强调了资源的提升。这时候我们强调的是价值的流动，也就是说流动性的提升，也就是你的需求能不能第一时间上线被用户发布，它在哪卡住了，所有开发测试运维一起攻关把那个问题解决掉。

　　第三个是持续交付标准，有一个部署发布的模式，看第三级，就比较难了，比如说要求你实现部署和发布实现全自动化，并且使用相同的过程和工具完成所有环境部署，一次部署过程中使用相同的构建产物，意味着你所产生的那个按键包是一个产物多个运转。现在很多测试环境测试完了还得重新做一个包做运维，这些都是不应该的。另外还有一些部署的策略，关系到部署的失败率的这些情况。

　　还有持续集成这块，如果说企业想要达到三级，不容易。要求研发人员至少每天想代码、主干集成一次。

　　还有包括组织形态、文化塑造、人员技能、创新管理、片个管理，

　　我们的标准编写有很多专家的参与，这只是说部分专家所在的公司，还有更多的时间关系没有把它们完全列出来。

　　我的部分就讲完了，谢谢。下面请大家掌声欢迎我们的同事、朋友、牛晓铃女士。

　　牛晓铃：大家下午好！我们有七个大项，能力项分为十四个项最终能力指标五十二项。我们为每一个能力项评估指标都分给它一个权重。因为我们是分为五个级别，一级1分、二级2分，五级就是5分。

　　我们会根据这个权重算一个得分，然后我会算出它的14个大项在它的权重算完分以后的总分进行一个统计。我们还会给出一个百分比，从这个百分比中，我们可以清晰的看出它在持续交付的评估过程中，哪一些是它的强项。比如说它可以达到70%的能力百分比，然后哪一些事它的弱项，比如它只有达到30%这些。

　　然后我们会给它一个总分，每一个级别有一个分数区间，根据算出来的总分看它的落在哪个分数区间就判定为几级。

　　通过判定浙江移动级别是3级。

　　本次重磅发布4个标准。第一个就是整体架构，第二个是敏捷开发管理，第三个是持续交付，第四个是组织结构。也欢迎大家如果有更好的意见和建议及时跟我们进行反馈，我们也希望越来越多的同道参加到我们的标准制定工作中来。谢谢大家！