铭熙 置顶2019-10-12雪峰帅哥，既然你说人加流程等于文化，展开下说如何从人和流程下手，有什么变化？作者回复: 铭熙帅哥，特别好的问题，由于专栏篇幅限制，很多内容不好展开，正好在留言区大家一起讨论。
DevOps倡导职责共担的文化，但实际情况是，如果你的绩效目标跟我的半毛钱关系没有，我凭什么跟你共担责任呢？
人固然有自身的问题，到我觉得更多的还是流程和机制的设计和导向问题。
举个实际的例子，比如在梳理发布流程的时候，发现测试回归周期长，完整一次回归要两天时间，请问怎么办？
第一种就是给测试团队加人，这显然不够DevOps。
第二种就是做回归测试的自动化，这能解决一些问题，但是自动化成本，技术成熟度，自动化结果的可信度都需要时间，更何况如果自动化出了问题，责任还是人的，那么人的意愿肯定会打折扣。
第三种，就要多问几个为什么，原来回归周期长的原因是研发没有给出准确的修改范围，因为当前的流程研发提交完代码，连测试包都是测试人员自己来打，服务意识固然不错，但是问题就是你压根不知道改了啥，会影响啥，结果就是全跑一遍，因为即便出了问题，也要各种甩锅，测试责任怎么也跑不开。
所以缺陷问题只有流程上约定由研发测试一起承担，同时加入测试辅助的研发自测，将测试能力通过平台化赋能，再加上各种DevOps中的自动化手段打通变更信息，进行变更影响分析，这才能根本上解决测试和开发之间的问题。 16
2019-10-15石老师好， 我们是运维团队，如果从运维团队去主导这种devop的推进，有什么好的思路？因为毕竟和开发是两个团队，所以我们之间的工作职能和理念其实不一样，如何能够统一两者，如何能在运维的角度，去让devops能够在所有团队推进起来？作者回复: 你好，DevOps倡导开发和运维的沟通和协作，但这并不是一句空话，原因不仅在于部门职责划分的问题，还在于技术能力的不对等。我一直信奉一个选择，想要拯救别人，就先要拯救自己，所以运维内部过的怎么样，是否还有大量的手工操作和线上问题，这些首先是要解决的。
接下来的核心就是通过平台能力赋能研发团队，转变运维工作的重心向平台化自动化智能化发展。
简单罗列几个常见的手段供你参考: 1. 将运维的能力通过自动化运维平台开放出来 2. 建立部署流水线 3. 在开发环境打通持续集成和部署过程 4. 将相同的过程先其他环境延伸 5. 根据业务需求共建监控系统，收集埋点数据 ，支持AB测试等6. 简化环境申请流程和初始化成本 7. 试点云容器技术，并和开发团队一起试点 8. 定义标准化环境配置 9
2019-10-12石老师好，我是一个运维，公司开发部门还是比较传统的方式，推动DevOps是否一定需要CTO级别的人来推动作者回复: 你好，这也要看公司的规模，我只能说，管理层的支持至关重要，否则你能影响的范围有限，尤其对于大公司来说，至少是一把手工程。但是管理层的支持仅仅是条件之一，具体怎么实施，试点，给予管理层反馈和数据量化，证明这个事情的价值和可行性，这些都是我们要做的事情哈。
3
2019-10-12老板对这事儿还没有一个直观的考量，虽说有老板的加持，但他们总觉得现在这种传统手工作业的形式还挺好。所以我需要系统的知识进行引导，很荣幸遇到您。作者回复: 你好，其实大多数老板，如果你说他能听得懂的语言，他是能听得进去的，但是，老板需要看得见摸得着的效果，这也是很多改进项目能否持续下去的重要因素。
关于这一点，我的建议还是需要有量化指标来展现，比如你们公司目前的研发效率有哪些指标，具体的数值又是怎样的，只要能把这一点说清楚，后面的事情会容易很多。
至于选择哪些指标，我在后面会专门来分享，简单来说，至少参考业界公认的DevOps四个结果指标，是不会错的，只不过还要结合公司实际，细化指标定义哈。 2
2019-10-14标准化都还没做好，路太长。对于如何推动公司技术栈的标准化，石总有何高见?作者回复: 你好，坦率的说，技术栈的标准化是公司CTO要解决的问题，我关心的是，现在因为不标准带来的问题是什么呢？
其实DevOps搞了这么多年，各种平台技术栈或多或少都有涉及过，不知道你怎么看哈。 1
2019-10-14我们公司现在就在做DevOps的转型，我个人感觉到最大的阻碍，不是流程，而是人。一些老的员工不愿学习新的流程和工具，让转型变得很困难。我自己的实践方法就是，在各个部门中（开发/测试/运维/DBA）找到那个最积极、最愿意改善的人，然后推进新流程和新工具的落地，等有了实际案例流程打通之后，再去和其他人推广。真心感觉人的积极主动才是一切变革的核心和内在驱动力作者回复: 看来你很有新得呀，有没有一个案例可以跟我们分享呢，我在计划整理优秀用户留言，让学习和分享成为同学之间的事情，期待👍
2 1
2019-10-12老师您好，这句话不是很理解，平台的一些基础设施比如服务器，使用方增多了自然会增值，如何理解不线性增长呢？
规模效应：平台的成本不会随着使用方的扩展而线性增加，能够实现规模化作者回复: 你好，我是这么理解这个问题的。作为一个平台，不应该随着接入的服务方的增加，建设成本也随之增加。那最简单的构建打包这个事情来说，如果每接入一个新的应用，都要定制化的开发页面，数据结构，那就不能叫做一个平台。平台的做法是，通过高度的能力抽象，可以通过简单的配置就能实现业务的扩展。不仅如此，平台的服务成本也是一个道理，如果接入一个用户就要投一个人支持，这就是线性增长的，应该努力避免，这一点我会在平台设计的章节展开来说。
1
2019-10-12看了有段时间devops，但感觉一直在门外转来转去，文化工具都有了解，可能还是实践差了一些作者回复: 那就找一个力所能及的领域，脚踏实地开始实践吧👊
1
2020-02-04老师这篇文章的高度蛮高的，不仅仅适用于DevOps，更像一篇理论指导，很多内容在工作中都是可以借以思考和学习的。- 2019-12-30对的，我十八岁之前都还不知道这世界上还有咸豆浆……
2019-10-29按照老师文章的定义，流程之下的人形成自身的行为准则，而准则的集合体构成文化；这么看起来，我们公司也没什么流程，我们的准则看起来就是别搞得太难看，谁都别太过分，那么我们形成的文化就是互相尊重，允许自由发挥，崇尚自我约束，就是自律啊...这么看起来我们的文化很高级啊，应该能让我们有了一个宽松的空间来实施devOps啊作者回复: 互相尊重，自由发挥，自我约束，请问你是哪家公司的，能做到这种程度，还不出问题并且非常高效，我觉得可以出来分享分享是怎么做到的了😝
2019-10-28喜欢那句 “真正的高手，比拼的不是武功，而是思想”，如果想法不对，手里攥一堆工具也是白搭。
总结起来就是 对的人+对的流程+对的平台作者回复: 没错，再好的工具也要有人来使用哈
2019-10-19这两年来一直在推动内部研发体系的建设，平台从无到有，自主投入研发。但是在平台推广过程中遇到了很多问题，总结一下几点感受：
1、首先需要有一个认可的部门大领导支持，而且一定是要当成一项重点工作来推进；
2、平台开发团队的成员也需要形成统一的认识，是为整个公司研发体系服务，是先行者，改革者，同时我们也是平台用户，要坚信通过平台化、自动化、标准化是能够改善现状，提高效率，提升软件质量的；
3、要长期给项目业务线的核心骨干人员“洗脑”，宣传devops的理念，培训平台的功能点，指导依赖工具的使用，主动帮助梳理他们现有不合理的流程，尽量通过平台来帮助改造；
平台的建设推广，无论是领导，还是平台开发者，项项目业务线人员，更多的是人的认知的改变。作者回复: 我觉得你说的特别好，感同身受，赞一个，如果编辑看到的话，请帮忙置顶，谢谢！
关于你提出的3点内容，稍微补充一些我的想法：
1. 大领导的支持不是长期的，无限的，领导也需要及时的反馈，尤其是看得见的数据和成果，以证明这个事情是正确的，有效的，这点非常重要。
2. 对于平台开发成员来说，如果只是一个纯开发的想法，是很难做好这个事情的，要具有业务思维，努力了解业务现状，并且有独立创新的想法，才能激发内部的创造力，当然认可效率工作的重要性也不容忽视。
3. 业务线的重心毕竟还在业务上，同时他们也不是工程效率方面的专家，如果期望他们给出解决方案，那显然没有理解这个工作的含义，所以正确的方式的确是识别痛点，给出解决方案，达成一致，快速试点，反馈和推进。
2019-10-15DevOps 由人+流程+平台工具构成一个有机整体，其中最主要的还是人。推动需要一个说得上话的人，推进需要一群志同道合的人，实现则是服务一帮人。把人搞定了，什么都好搞了😄作者回复: 哈哈，精妙啊精妙，说的太好啦！话说回来，啥事不是人的问题呢？
2019-10-14看完老师文章，自己总结下。
1.人的主观意愿 + 制度 = 文化
2.流程的抽象 + 平台的落地 = 工具
3.人的诉求 + 平台的推广 = 培训
平台的定义：
1.可扩展，纵向扩展或横向扩展（不一定必须要很自由）
2.横向扩展，聚合多个工具或服务，助力某一大类工作的所有工作诉求，解决一个更大问题域的问题。
3.纵向扩展，从单体工具或服务，往多租户的工具或服务演变，提供配置化的定制能力。展开作者回复: 很棒的扩展理解，我应该把这段加到文稿中😄
其实平台是随着场景的拓展而拓展的，所以需要把人还原到具体的场景之中，思考人和事之间的关系是怎样的，服务化就是一种最好的诠释。- 2019-10-14石老师好，
devops 看起来虽好，可以提高开发效率，目前又有Aiops出现，如果需要转化到Aiops，devops文化会不会阻碍呢，devops是否有灵活性，可以转化或者可以添加其他技术 丰富devops平台。
回答问题：
我们公司 在很多最新的技术方面 比如devops 基本上一张白纸，所以有很大的上升空间，所以我们个人机会也很多，展开作者回复: 你好，AIOps更多的还是Ops领域的一种探索，解决的还是Ops所面对的问题，而DevOps已经突破了单一领域，成为软件交付整体的方法论。
其实，无论是AIOps，还是DevOps，其实就是个热门词汇，技术进步终将不断革新，所以有人问工程效率和DevOps有什么区别。我的理解是，效率这件事是永恒的，而DevOps可能会被一种新的技术和方法所取代。 
2019-10-12谈不上吸引吧：部门文化比较自由，不违法公司规定的事情基本不管-适合自己完成当下并做些技术钻研和探索；本地其它企业都会管理的偏严而忽视了效率。
学习是为了自己的未来去探索和实践：明白怎么做了当机会来临时把握了就好。就像二叉树视频中鸟哥所说：“机会来临前你已做好了准备，机会来临时抓住就好”😀作者回复: 哈哈，罗胖也说过类似的话，这一波机会没赶上怎么办，做好准备，争取赶上下一波呗😄
我之前所在的公司风格也比较自由，但我现在看来，这还不够，公司有没有一种渠道，让局部创新全局化，说白了如果一个团队一个人摸索出来的新方法很有效，能不能发挥规模效应，让更多人受益，这种激励机制非常重要，否则你做了很多创新，很多想法，但没有用武之地，这对自由来说也是一种打击吧，不知道你怎么看这个问题？