牢记！成功实践 DevOps 的5个关键因素
本帖最后由 陈小宝 于 2020-8-3 16:28 编辑今天我要给大家讲的主题是“成功实践DevOps的五个关键因素。”
主要分为四部分内容，第一是VUCA时代如何应对灰犀牛，第二是成功实现DevOps的五个关键因素，第三是企业如何开始实施DevOps，相信这个会给各个企业带来参考意见，最后是给大家回顾。
一、VUCA 时代如何应对灰犀牛
首先，我们引入VUCA这个概念，VUCA是指组织处于一种易变性、不确定性、复杂性、模糊性状态之中。这个概念最早是美军在20世纪90年代提出来的，引用描述冷战结束之后的越来越不稳定、不确定的、模棱两可的、复杂多边世界的关系，在2001年911的恐怖事件之后这个概念被确定，VUCA被战略性和商业领袖来描述成为这种新常态的混乱和快速变化的商业环境。
为什么现在要提到VUCA这个词？一些案例都是证明了，明天颠覆你的对手并不在今天的视野之中，这个怎么理解？全球市场需求的高速变化，企业如果无法升级，就会面临衰退或者灭亡，就像苹果手机取代诺基亚，滴滴快车取代出租车，微信和钉钉取代短信，外卖取代方便面等等，都是说颠覆我们的对手通常不是我们能看见的，这是在大行业跨领域的行业。
另外一个原因是我们现在不能骑自行车追汽车和火箭。麻省理工学院的研究员曾经发表过一个文章，一个AI改变2020年的效率法则。文章里提到，在全球这种发达的经济体当中，前沿公司和落伍公司之间的差距在持续性的增大。比如在财富独角兽榜单中的这些企业基本上都是指数型增长的组织，像小米、滴滴、今日头条、蚂蚁，都是超过行业平均水平十倍以上的速度在增长。
还有一个原因是科技现在越来越重要，大家都在说科技以无形的资产超越有形的资产。像微软市值，据说1%都是实体资产，99%是公司代码。所以说在新型科技上投入越来越多，便会保持领先优势。
但是这里要提出一点，高科技企业和实体产业中的企业正好相反，对科技的投资是比较谨慎的态度。谨慎态度表现为否认事实避重就轻，得过且过盲目乐观，听信一些诊断延误，推卸责任，同时也缺乏相关的经验，也担心引起一些消极的逃避。
客观原因就是非高科技企业尤其是实体产业的试错成本通常高于互联网行业，也有主观因素，担心看不懂，学不好学不会。
这一块通常在工程学上有一个定义：在一次重大事故发生之前，已经有超过99次小事故发生，但通常是人们忽视小事故的信号和警示，等到真正灾难发生的时候通常就比较晚了。人们习以为常不加防范的小风险引起的大事故，就是我们常常说的“灰犀牛”的事件，就是指概率极大、冲击率特别强的风险。
灰犀牛的事件无论在工作还是在生活中都是特别常见，比如项目中的灰犀牛，没有签合同就开工；还有一些环境上的，无论是发达国家还是发展中国家，GDP的高速增长通常以牺牲环境为代价；还有最新的例子，新冠疫情对美国来说也是灰犀牛事件，就是无作为的美国政府任由风险的厚积薄发，酿成大祸。所以就是说应了那句话，出来混终究是要还的。
从客观来说体制机制的这种惯性、管理结构的盲点、结构程序的无效或者低效，还有技术平台相对的成就也会拖延人们行动的脚步，从而耽误我们的处理和控制风险的最佳时机，我们应该如何去应对这些？首先我们要承认危机的存在，要承认灰犀牛危机事件的存在，不仅能帮助我们做机会，也能帮助我们把危机事件转换成机遇。
[*]第二，我们要确定灰犀牛事件的性质。
[*]第三，是不要静止不动。
[*]第四，不要浪费机会，要想办法把危机转换成机遇。
[*]第五，站在顺风处，最好的领导是在危险还没有靠近的时候采取行动。
我们发现灰犀牛事件的人，我们要成为控制灰犀牛事件的人，带领大家躲避相关的风险。基于以上体制的惯性、管理机构的盲点、决策程序的低效，这些问题恰好就是我们当前很多公司在实施 DevOps 过程中面临阻碍我们前进的、急需解决的问题。因此这里回归到的正题，给大家分享我们在各大企业中调查研究后总结出来的关键因素，这五个因素分别是目标、人员和文化、流程、平台还有技术。
二、成功实践 DevOps 的 5 个关键因素
1. 目标对齐
第一个关键因素是业务目标要对齐。IT的部门通常做了很多事情，为什么业务部门依然不高兴？通过了解，业务部门认为有四个方向。
第一是IT和业务面积无法适配的问题，就是说我们依然有一些科技官僚主义的存在，企业架构师和技术管理者把大部分精力放在技术层面，与业务部门的沟通不是很顺畅，缺乏一些系统化的运营管理思维，因此导致业务部门认为我们双方的愿景无法适配。
第二是IT部门聚焦在过程而不是结果。
第三，IT总是在解决自己的问题，永远看不到一些产出，同时有新的问题出现，我们就会针对性的补充相应的，比如说ID产品和服务还有采购，久而久之造成内部的问题会越来越多，因为我们基本某一些点，没有从整个面。
第四，对于业务来说，IT内部就是像个黑盒子。因为管理部门通常说IT是无法控制的黑盒，就是专注于技术，缺乏沟通，同时IT人员越来越贵，设备、服务、产品非常贵，同时IT功能不是很透明，而且跟业务的协作和通信比较差。所以业务部门认为通常反馈的几个问题。
为什么IT部门做了这么多事，业务部门还不满意？其实IT部门也有不爽，因为业务部门总是在办公室想一些需求，或者提出的需求不够清醒，刚刚开始开发就要改，甚至说开发完成上线最后还要改。另外一个经常碰到，业务提出最高优先级，没有最低优先级，不知道哪个到底是最高优先级；永远不知道业务的指标和收益，就是我们开发出来的功能有没有效果，完全是不知道的状态。
所以目标对齐，IT部门和业务部门之间一定要做充分的联合，聚焦客户价值；对业务的要求聚焦在客户价值里面，客户满意度，关注于业务指标，研发不能仅仅聚焦在按时交付，业务也不能仅仅聚焦在上线，要关注用户的实际需求。分享一个实际案例，昨天是收到一个大型企业 DevOps 通信小组的反馈，他们很高兴告诉我业务也加入他们的站会了，现在氛围特别好，做到了真正的敏捷，他还特意强调一下真敏捷，什么意思？就是两周一迭代，两周一个投产，整个团队现在非常有成就感。
我们也了解了一下原因，首先是双方部门领导的重视，给了大量的支持，还有前期一起进行了相关的敏捷实践，业务部门一起完成了相关的标准事件，同时请有经验的人员给业务团队做相关的指引和培训，也请了外部的教练来做指导。因此业务已经逐渐接受了这种思维，通过这个案例再次印证了聚焦业务价值的快速交付，减少了业务概念从交付到反馈的流程，就是一定要关注全链路的协同工作，不断改进，有时间不断做创新的事情。
2. 人员和文化
接下来是给大家介绍第二个关键要素，是人员和文化。
这一方面传统的开发模式有以下的显著特点，一般是项目制，同时把项目分割成各个开发阶段，比如说需求、定义、设计、编码、单测等等，同时使用里程碑的方式，严格定义了开发阶段的输出，如果一旦达不到相应的输出下一个阶段不能展开。
这个工作模式就是把开发阶段定义为黑盒，希望每个阶段的人员只关心自己阶段的工作，责任非常分散，各自负责各自的一部分。
好处在于可以让各种角色的相关人员可以专注于本职工作，提高阶段的效率。但是坏处也非常明显，主要表现在出了问题大家就会相互推诿责任。另外在每一个开发阶段，都会有一些信息，可能其他阶段的人员没有办法了解到，所以就会造成大面积相互理解的偏差等。
其实这正好是 DevOps 尝试要去解决的问题，即如何让企业内部的开发运维和其他组织高效协作，达到一系列共同的目标，更快、更可靠向客户还有终端用户去提交软件和相应的服务。
所以通常会演变为两个团队，以前项目制的团队通常演变为多功能的产品开发团队，就像屏幕右下角所示，大家聚集在一起，团队里面有开发、测试、运维，甚至还有我们的业务人员，在互联网公司也是叫产品经理，大家一起共同为整个产品和服务的承办去承担相应的责任，因此大家的积极性相对比较高，这是一块。
另外之后大家会组成一个新的 DevOps 平台的团队，为什么组建这样的平台团队？我们对于多功能开发团队来说是负责某一个产品或者服务的开发，甚至服务的交付，你不可能在这个团队里面要做 CI/CD，自己安装配置，甚至是维护这些相应的工具平台，因此会得不偿失。在这样的背景之下会成立一个新的DevOps平台团队，这个团队一般会负责公司相关产品的整个端到端的工具链的贯穿，还有流程和工具的结合相关的工作。
因此类似于右下角的图，他们给相关的产品开发团队提供一些工具或者平台甚至是自助式的服务，让这些开发团队很容易去介入到，因此这是一个非常巨大的转变，尤其是对于很多传统的企业，他们还没有开始做敏捷和DevOps实践之前，是很难想象的一个事。同时无论对于多功能产品开发团队，一般的建议人员是在九人左右，也有个别组织在15人左右，但不超过15人。
另外相信有很多人看到有一些学习型的组织，这样的组织一般会建议说大家通过相应的组织结构的转变，人员团队之间相互学习，通过重组的方式充分释放团队和人员的力量。之前的模式主要是分层特别明显的组织架构，从控制型转变为虚拟化或者网络状的组织，达到相关的事情对齐，还有足够的授权方式，因此之前可能是谦虚合作的模式，后续可能是大家形成一个高度合作的小组去承担整个产品的承办。
刚才讲了一些理论，现在是给大家具体的案例，这个案例有一个大的背景，就是说某个企业他已经对 DevOps 相关实践探索了一段时间，可能一到两年，根据网上的建议也组建了产品开发团队和 DevOps 平台的小组，也开发了 DevOps 流水线平台，但产品开发团队、运维团队和 DevOps 平台小组之间依然没有办法很好地去合作得顺畅。
常见的问题比如说平台貌似有一些自动化的功能，但是用起来很别扭，要用平台要先申请资源自己再配置进去，很麻烦，或者要上线投产的时候需要大量的沟通，或多或少每次上线都会遇到一些问题，这是大概的背景。经过和相关的管理者做商量和讨论，我们就用学习型组织的建议，比如说建立共同的愿景，团队一起学习，同时逐渐改变团队的模式，最后从系统化思考怎么样优化这些事。最后我们想到一个办法，就是说设置一个轮岗，轮岗的目标就是增进团队的协作，最终达到上线。
这里说到非常关键的点，首先设置短期的轮岗机制。一开始是志愿者的模式，大家自愿报名，为期两个月，其中第一周是相关的学习，比如说开发人员会学习怎么样对产品和服务做部署上线，那么第一周去学习，后面的八周轮岗，我们有需要做上线的时候由开发同学做相应的操作，因此整个达到开发测试运维责任共享的情况。
同时对于运维同学来说也会更好了解产品、系统和流程，因此会让运维同学做相应的测试类型的工作，这样比较好了解我们的业务模式。另外就是要创建一个好的环境，大家在良好的氛围里面相互学习，同时最后是庆祝每一次的成功，也庆祝每一次的失败，对于成功比较常见，对于失败也会采取一些措施，比如说会让有问题的相关人员，买一些吃的请大家，通常来说吃人嘴短，你吃了人家的东西后续遇到问题的时候不会逃避，而是真诚帮助大家把事情做好，因此这是轮岗的案例，里面融合了大量文化的一些理论在里边，最后取得了一个比较好的效果。
3. 流程
接下来我们看第三个要素，就是流程。我们先看一下四个趋势图，非常直观展现了敏捷开发模式和传统开发模式的不同，虚线表示传统的，实线是敏捷的开发模式。对于项目能见度来说，在项目立项之初，大家对项目的关注度和期望很高，因此一开始是比较高的能见度，但是在执行的过程中非常明显。
对于传统的开发模式，它的能见度会越来越低，直到一两年之后说能发布了，就是 的宣传，这时候大家很激动，说上一任老板在的时候采购的工具终于要交付了，会有这些感觉。那么在敏捷项目实践中会采用一些迭代开发的方式，一开始我们相关的项目的能见度就比较高，一直会跟客户层面做协助，去探讨相关的需求还有实现不断做反馈和改进，最后我们的业务价值也是持续稳步上升，同时风险也被很好的控制。
这里举个在融资界的例子，就是传统的融资界的融资周期基本每年一次，但是根据我们的截图显示的，他们在很早以前，在2016年的时候开始做敏捷化的融资，比如说去通过一些周期性的融资，以前是一年一次，现在是按季度或者更短，做相关的投资，因此这种风险相对来说比较可控。
那除了这些因素存在明显的差别之外，其他还有项目的拨款周期、交付周期、反馈周期等等也存在着巨大的不同，在传统的开发模式下通常大批量一次性这种方式去交付，但是在新的 DevOps 的模式下，项目的拨款周期类似于融资界或者小批量迭代的交付，收益或者收视率比较好了，我们就继续投，如果效果不好我们就暂停，可以及时做止损。
4. 平台
接下来给大家分享一下，第四个关键要素—平台，刚才王洋老师也介绍了DevOps平台相关的事情，这里给大家一些建议，对于平台这一块有三个需要注意的方向，分别是自动化、自主服务、可视化，自动化一定要做标准化还有相应的版本，另外对于平台这一块去实现自助服务，我们认为也是很关键的，另外是可视化，端到端流水线的可视化，还有度量的可视化，业务数据、研发的效能、质量、速度、满意度等等，都可以通过可视化的方式去改进出来。
这一页给大家举个例子，我一直在想一个例子，这是从网上找到的一系列的照片，这个例子就是在现实生活中或者项目中通常会遇到类似的问题。比如牙膏快用完了，很多人说扔了，再买一个。但在疫情下，大家会觉得这些东西会变得越来越珍贵，因此会想尽一切办法怎样更高效运用，那应该怎么做？有些人就说我特别擅长做自动化，就做了一个这样的自动化方式，特别独特的一次性的自动化，没有办法做重用，大家会觉得这个例子可能很可笑。但是这个例子在企业里面或者项目里面是非常常见的，为什么大家回用这个耳机线绑牙膏？因为可能这个人手里只有这个东西，或者他的理解范围内认为这个线是最好的工具，所以在他的知识范围内这是能想到的最好的办法。
但也有一些人会去买非常高大上的工具，像自动挤牙膏还有自动感应的工具，大家觉得非常好。也有这样一种场景，尤其对于大型的企业，存在一定的年头之后会有大量的不同的业务模式，类似于家里有晚年、中年、青年、少年、婴儿，那在这样的复杂环境下买这样的工具是否能很好的解决问题，这是大家需要关心的。
还是以挤牙膏为例，可能小孩用牙膏的量特别少，对于年轻人来说一次性要挤满整个牙刷才行。那用标准化的工具怎样满足不同的用户的需求？所以大家会说通常有一些公司开发得特别好，是否能解决我们的问题？所以这是大家需要提前考虑的点，如果通过一些调研发现工具比较适合，满足目前的情况，在资金允许的范围下鼓励大家买这些工具。
对于这个例子也是一样，我们要考虑牙膏的形状，后续的清洁维护，还有电源等等的情况也要做相应的考虑。其实对于这样的例子在工作和生活中非常常见，一般是给到的建议是一定要与领域相对比较专业的人做沟通和交流，因为他对这个领域的关注点可能超越公司内部的开发、测试、运维人员，也许可以通过小工具可以解决这样的问题，同时又非常经济。所以回过头来看看各个企业的内部，首先建议大家做改进的流程，对现有的流程做梳理，再看如何在现有的流程做删改和相关的优化。
第二是促进内部和外部的开源之间的概念，还有相关的合作和协作，公司越来越大，或多或少存在重复的事，所以要不断重复开源的机制。还有一个是要快速失败，对于失败来说我们要快速试错。最后还有一个关于自动化，它的三个前提条件非常关键，第一是标准化，一定要做标准，要在相应的流程和规范的梳理，只有形成流程和规范的标准，才能用脚本实现，这样实现之后才有自动化，那后续相关的维护和功能的拓展才有相关的版本化的管理方式。
第二个方面，对于平台化建设的自助服务，这一块最关键的是一定要去给大家打造一个尽量的傻瓜式的自助服务平台，相关的好处和优点都有列举出来，首先解决大家把流程融入工具平台的最佳做法，我们定义了一些流程规范，公司说有自己的流程规范但是没有办法落地，做法很不一样，这其实是很多公司常见的问题，我们推荐的做法就是找到特殊的突破口，同时结合现有的工具，把流程融入到工具，同时也有统一的配置可以统一管理，还有自助服务可以带来更高程度的敏捷性等等，这样同时有利于我们最佳实践的推广，同时减少风险，也有利于安全和审计。
比如说组织级这边可以定义最基础的规范，比如说安全的规范，质量的门禁式规范，对于基础的规范我们可以把它植入我们的自助平台里面去，不管什么业务，如果符合相应的要求就会给你自动的开通相应的任务，或者对对应的任务做强制执行，这样就比较有利于相关的风险控制，同时后续对于自动化的平台会不断做相应的审计的工作，这样会更好的督促大家使用的规范化，有利于平台更多功能的开发。
第三个方面就是关于平台是度量可视化，这个非常关键，前面还有一个流水线的可视化不做重点讲解，今天重点讲度量可视化，通常来说分为四大块，
第一是合规的展示，安全的合规、开源的合规尤其是软件产品服务要出口，出口到欧美的时候大家一定要关注开源的合规，否则会被重罚。另外还有可靠性展示，偏运维，就是我们服务的时长，监控预警。今天重点说的是左边这两个指标，
第一是CI/CD指标，就是开发过程中相关的比较关键的指标，用得比较多也比较有效果的就是交互时长，就是出了问题多长时间可以修复，直接关系到整个团队的开发文化还有规范的执行还有DevOps的落地，都有直接间接的影响。另外变更覆盖率，测试覆盖率，测试健康度的检查，同时还有公司会做CI/CD的免测率，会根据免测率的情况给你的产品质量打分，你产品质量相关的分数越高，免测率越高，类似于国家提出的质量免检的手段，这样会更加有利于产品开发团队去不断提升他们内部的质量，同时要不断解决我们的技术栈，关注于质量或者开发提交的打回率，做到有问题及时发现。
还有大家现在越来越关注业务价值指标，通常体现在业务的流动速度、流动时长，其他的比如说交付周期，现在还有一些公司也会关注创新的时长，说最宝贵的研发测试人员他们最主要的工作到底是在做创新类的事，还是解BUG，还是开会？所以这一块是大家越来越关注的指标。接下来是给大家分享一下我们在各大公司走访之后梳理出来的DevOps的度量模型，这一块也是目前很多公司都在准备做的事情，给大家做一个初步的分享。
首先度量体系的目标我们是要打造一个相关的度量平台，同时对生产率、交付质量、速度、满意度提出一个可视化的展示，所以度量指标的意义就是能帮助我们全面评估我们 DevOps 相关实践落地的情况，同时根据这样的可视化的体系，能够给我们合理指引我们哪里做得好，哪里做得不好，哪里还没有开始，同时达到一个快速达成，不断做持续相关优化改进的事。
另外对于度量体系建设，很多公司都觉得是特别困难的事，这也是一个现状，就是分析建设难点主要表现为这几个，第一是高复杂度，贯穿整个阶段，产品的研发、测试等等，同时还会涉及到业务。
第二是度量体系没有现成的工具，当然市面也有一些工具，很多公司也花大价钱买了，但是拿回来用不了，没有专业的人做相关的配置，造成了巨大的浪费。
因此度量体系需要高度的定制化，同时需要比较好的应急，首先你要能把所有的工具链贯穿才能收集到这样的数据，如果连工具链还没有贯穿，或者没有引入相应的数据，那这些数据从哪里获取，因此是有一些基础在里面，就像刚才说的现在有各种各样的工具，同时这些工具存在于各种部门团队里面，因此我们想去把数据收集过来存在相关的复杂度。
最后一个我们一定要有相关的理论模型支撑，这个模型是非常困难的事，那这里面给大家分享右边这几个我们作为 DevOps 度量模型的设想。
最上面这个度量体系分为三个维度，个人、团队和系统，对于个人来说这一块最常用的场景就是工程师画像，大家用得比较多，这个通过个人的经验、能力、专业知识、意愿和工作来做相应的模型，再结合相关工程师的过去、现在、未来做相关的计算、学习，得出一些相应的数据。团队这一块是充分利用每个团队里面工程师人员，各种角色，同时对于团队所承接的业务或者产品的复杂度、收益做综合的计算，画出团队的画像。
另外系统也是大家关注的，也有一个示意图，是产生系统的画像，这个画像里面是展示了两个系统的能力成熟度，A系统68分，B系统72分，就是每个方向的强弱是非常直观的展示，如果我们想对哪一个系统想更进一步的了解，都可以点进去，对相关的进行了解。
5. 技术
第五个关键要素就是技术，大家应该非常关注，从开发的模式的转变、应用架构的转变还有打包，还有托管机房的转变，都逐渐转换到 DevOps 微服务、容器和云化。这里给大家提的一点，对于有不同的开发模式，我们会有不同的部署频率，因此左边是列了一些相关的部署频率。还有一点不见得一定要从单体转换到微服务，这个一定要根据实际的业务情况做相应的判断和分析，那么如果你的业务情况就是非常稳态，需求变化就是没有那么快，同时需求也被很早确定下来，可能这种情况下没有必要做强迫性微服务的转换，这是给大家的一个建议，包括其他的开发模式，虚机到容器到上云都是类似的。最后关于技术这一点大家通常会忘记一个非常关键的点就是我们跑得太快没有功夫或者没有时间修我们的技术栈，这一点非常关键，导致你的系统跑到一定的程度会产生大量的问题，所以在技术这一块给大家重点强调，我们一定要定期修复技术栈。三、企业如何开始实施 DevOps说了这么多关键的要素，大家可能会比较关注的就是对于不同的企业，DevOps 落地应该如何开始？现在各种业务系统越来越复杂，甚至已经不是一个产品或者一家公司的多个产品之间有关联，已经是整个生态之间的关联关系，那这种怎么做？
还有一个是各种传统的企业在拼命招一些自有的科技人员，以前可能说大家都是外采一些软件和服务，现在都是从几百人的规模逐渐发展到上千人自有的科技人才，人员增加之后对于我们内部的IT的工具平台系统带来的业务的挑战性，也是越来越严重。对于工具系统这一块，我们人员的扩张之后势必会产生大量的工具系统，是技术的不断迭代，有一些团队可能会积极引入新技术，那复杂的系统我们应该如何考虑，怎么推广 DevOps，DevOps 对于复杂的场景是否还有效？我们是否应该寻找一些帮助？
比如说对外去寻找一些咨询的力量，对内向其他做的好的部门取经，因此我们强烈建议，通过这种方式，我们左手是用 DevOps 的标准，右手是 DevOps 平台，通过两手开展 DevOps 相关实践的落地。
这里快速介绍一下研发运营一体化（DevOps）能力成熟度模型，DevOps 标准2018年在联合国 ITU-T 立项。它分为几大块，
第一主要是在敏捷开发管理，对需求还有价值流相关的梳理；
第二是持续交付，也是我们目前大家所熟知的标准三，包括了七个能力子域，14个能力项，49个能力子项，是覆盖了整个持续交付端到端的过程，对大家在实施 DevOps 的过程之中非常有参考借鉴的意义。
很多的研发或者测试人员来说他的知识范围受限，不可能考虑那么多，因此这是大家理论参考的依据。剩下的几个标准是应用架构设计，安全和风险管理，同时还有系统和工具。除了以 DevOps 能力成熟度模型为理论基础，另外一件事就是公司内部的 DevOps 平台建设，通常来说这个平台建设分为三个阶段，从无到有到引入工具。
工具多了之后，应该进入哪一个工具，怎么办？就做半自研，把以下相关的工具以连接的方式连接起来，或者页面的方式切入进来。第三个就是无论是开源还是商业可能没有办法支撑或者更好的支撑业务模式的时候我们一般会采取做自研，以及前面说的从开源那些大量的经验我们可以从小到大逐渐把我们平台建设起来。
四、回顾和展望最后一块回顾和展望，前面说了成功实践DevOps的因素有五个。
[*]第一就是目标对齐；
[*]第二是人员和文化，非常关键，也是需要各位领导逐渐做的事情，通过潜移默化的方式让大家去了解；
[*]第三是流程做相应的改造，平台做相应的建设；平台里面又有三个方向：自动化、流水线、度量，
[*]第四是技术，这一块非常关键。
对于后续的展望，目前业界也做了大量的讨论，就是主要我们认为几个方向是在DevOps相关的展望是在以下几个方面：
第一是项目到产品的研发模式。
第二是为 DevOps 平台建设结实有效的防护栏，就是打造一个 DevOps 平台，这个平台要有自服务的属性，自助的属性，让大家自助，也就意味着要有相应的防御的措施，不要随便越界获取相应的权限；相应的审批功能，这是很多公司做自助平台的时候缺乏考虑的。
第三是新的部署模式，一般是开发部门做，最后执行上线的时候虽然是在某一个 DevOps 平台里面做上线，但是这个时候依然是由运维人员做执行上线，后续我们觉得会逐渐转变为自助平台建设越来越完善，因此提供足够的监控和相关的审计功能，这样当我们的项目制到产品制之后，产品开发团队就完全可以做到自助式的变更流程，甚至说代码提交，通过各种自动化的有效检测手段自助上线了。
第四个也是非常关键要关注用户体验，大家非常熟知的用户体验一般说是对外部用户的体验，通常我们做 DevOps 平台的时候通常忽略了内部的用户体验，比如说有很多公司认为我招一个 JAVA 工程师就可以开发 DevOps 平台，是可以，但是对于开发测试运维人员的体验都是非常糟糕的，所以我们一定要关注用户的体验。
对于自动化部署平台我们要关注运维相关的体验，对于 DevOps 平台关注研发测试的体验，这是大家一定要关注的，否则很多公司开发了 DevOps 平台，最后推广的时候遇到很多问题，大家觉得不好用，因此处处碰壁，没有办法做下一步。
以上这几个点是我认为是在今年比较重点的发展方向，我的分享就到这里，谢谢大家。（雷涛）
页:
[1]