缘起，促使我写这篇文章
对于devops这个她，这几年也是不断的在变化。
最近读了《Effective DevOps》一书，前言对于DevOps一词该如何断句另我对devops有了新的体悟。对于“devops”为什么都是小写，作者的解释：希望谈话时不再区分”你们“和”我们“，而应当更多的讨论和如何利用可持续的工作实践（强调认为因素）来支撑企业发展。
机缘巧合在2015年就初识devops，并主导了一个研发测试中心devops项目的始末。当初也满怀热情和希望，希望通过devops工具的方式改进研发过程和质量，最后发现如研发组织未能形成协作的共识，就算在先进的工具也是徒劳。回顾更早之前2012年虽没接触devops，我们当时值得怀念的团队，用shell脚本+ant等被视为”上一代工具“也可以不断的迭代和改进研发过程。现在回味也不乏感觉其中devops的味道，回味无穷。
关于devops的主流观点
现在主流观点基本上是DevOps<大部分认为这个是Dev和Ops的融合>，还有不少GitOps、DevSecOps、AIOps、MLOps等。在很长的一段时间内，自己也是被这个观点所困住了的人，把devops局限在去解决Dev和Ops之间的斗争，或者说是通过devops让两拨思维都不一样的人尝试的变得一样。近几年，随着云计算、云原生热度上升，devops也被反复提及。大量devops领域的工具的出现，大家获取对应工具软件也变得越来越简单，进而各个开源软件、商业软件也不断去挖掘devops领域里面不同角色的痛点并不断的强化，故在devops领域里面也不断的衍生出来以功能增强的新词汇，例如：AIOps，主要在运维领域采用AI技术提升运维人员运维难度，DevSecOps，专门解决devops领域里面代码安全、软件包安全、发布安全等。
相信如果devops还是DevOps，那今后这个词汇会被赋予更多的寓意，就像有人已经提到了XOps，想来这个词汇估计是运维人员创造的，不然为啥不是DevX呢。听上去这场没有硝烟的devops领域的工具们之间的战争还会不断继续。
devops的反思
在devops这个路上，我们一直在追逐，但是否得其精髓：
- 公有云+持续集成工具的使用，就说在DevOps有很好的应用。
- K8S+云原生的应用的实践，就对传统用虚拟化+单体应用的研发团队说：“现在DevOps+云原生我们已经用的很溜，怎么还老土的技术？”
- 团队用了GitOps的工具，我们应该是最先进的DevOps团队！
- 过了EXIN DevOps Master的认证，在DevOps领域我就是专家。
- 公司过了能力成熟度XX级，我们的研发体系在DevOps领域已经得到业界的认可。
- 现在我们在DevOps流水线里面已经应用了AI技术解决故障自愈，我们DevOps牛不牛哈！
- ……
回味这几年DevoOps扑面而来，确实让自己迷失devops的方向。在清醒时需时常提醒自己，软件本身是创造价值，而不是追逐新潮。时常用当年“Wintel”来提醒自己，当下的“云计算”+“云原生”这不正是当年“Wintel”吗？之前接触到一个朋友给我描述的一个场景：一套“云计算”+“微服务”架构下来，1个最高TPS和QPS不足200的业务系统所消耗的云主机资源至少在5个8C16G以上（看上去确实那个行业现在也不差这点云资源的费用）。
另外从devops工具链市场最近又开始流行FinOps，估摸着大家上了“云”之后也能从CFO的角度体会到IT成本的不断上升。
什么是devops？
什么是devops？一个可能大家都不需要回答，但对从业者来说不得不回答的问题。这几年自己不断的反思和学习新学科的知识，对于devops也有一些小的感悟：
从ITIL来看
从ITIL 4的角度来看，服务价值流是对我较有启发的一个维度：devops要做不正是找到创造价值的那个最短路径吗？
“价值流（Value Streams）”是根据特定的需求和场景，预先制定对应的活动和这些活动的执行顺序。如果需求和场景变化了，那么价值流做出相应的调整。但“服务价值链（SVC）”保持不变，以此既有性对稳定的模型和框架，又能够根据具体变化而变化，保持灵活。
虽然ITIL是一个起源于IT运维管理服务，但从其本质来看ITIL是一个不断的适应变化迭代形成的IT运维服务标准。其核心是根据当下的需求和特定场景通过运维服务实践来找到属于每个团队的那个价值流，并根据价值流对不断变化的世界对价值流进行调整，从而使价值最大化。回味devops不正是在变化的软件世界中不断追寻那条属于团队的最佳价值流吗？
从OKR来看
从OKR管理来看，有幸有机会去实践OKR，在从培训、工具选择到应用于日常管理，发现OKR和devops有这同样让人心碎的过程。OKR被应用于Intel、谷歌、字节跳动、百度、Uber等成功的公司，并获得了极大的成功。devops也被应用于这些公司，大家在应用devops时，都满怀希望的认为一切都会向“他们”靠近。事实是残酷，OKR/devops都不是万能的良药，重要的都是找到团队中那个合适的“他”，通过“他”影响更多的”他们“来应对当下不断变化的那个成就个人和公司的核心价值点。 然而不少团队，都认为自己上了OKR、上了devops就以为向优秀靠拢，然而并没有认真审视（或者回顾）自己和团队是否真的更接近目标还是偏离目标。从实践反思来看，在大多数情况下那仅仅是美好的愿望，实质并没有随之而改变。
从开源来看
还是学生时代，抱着《人月神话》那生动的例子总觉得那才是软件工程的痛。自己从使用开源软件到发起开源项目，这个过程让我对开源世界有了全新的认知，也颠覆对软件工程的片面理解。其实，软件的世界可以用开源的方式更加美好，特别对内向的程序员<最害羞的一群人>来说，用开源代码的方式无障碍的沟通，从而链接了有相同需求的软件从业人员。开源文化也从使命、愿景、价值观不断的普及，形成了不同项目各自的透明社区治理模式。通过用户共创，不断的吸纳、迭代和修正社区共识机制，达成了全球团队软件协作。在社区中，每个细分模块也形成了不同的SIG<来自于社区的共识机制>主动协同思考、创造价值。 开源协作过程中也形成了一些列devops工具，并形成了有机的结合。目前，在企业级devops应用过程汇总，从来不缺开源的工具，现在缺的是开源文化的渗透。devops本身需要借鉴开源的开放、共享、协作，从而才能不断的积累和持续迭代，最终创造价值和持续创新。
从管理来看
管理学诞生到现在总是想变成一门科学，但他确实是一门“艺术”，业界从来没有停止过对管理的研究。devops何尝不是一门软件工程的艺术，只是这门“艺术”要解决的问题是研发团队如何应对当下善变的用户创造不断变化的软件价值而已。在devops中已引入大家并没有感觉，但确实是不断在影响devops的经典管理学内容。
从管理的鼻祖制造业来看，pipeline流水线就是试图在软件领域重现工业生产线管理的辉煌<但你真要用管工厂工人的方法论去管理现在智力劳动者，一般会得不偿失>。从美好理想来看，大家往往期望软件的生产就像生产流水线一样不断的改进制造工艺生产出即快又高质量的软件产品。但工业4.0中有意思的现象是：现在工业制造业也都不断的强调”柔性”制造，未来的软件生产没准也还可以借鉴工业流水线的设计。
写在最后
一千个人心中有一千个“devops”，珍惜当下你发现的每一个价值点。发起或者寻找到那个你心目中的“devops”，并通过分享经验、建立同理心、让与众不同的你们<特别注意：让合适的“他”放到合适的位置，从而变得更加耀眼>通过有效而持久的实践和反省成就非凡devops。
欢迎加入建木这个非凡的devops体验，喜欢就给我们点个赞，建木
