聊一下 IT 行业的发展和自己的一些体会。

作为一个经历复杂的中间件产品专家，综合能力给我的工作带来了很大的帮助。例如开发经验可以让我更好的和开发沟通，测试经验让我在诊断问题时可以考虑许多极端情况。但是这个工作本身其实还是比较单纯的，在 IBM 800 学习时，周围有不少同事就是没有研发经验的技术专家。他们大多有不错的教育背景，一毕业就学习软件产品，经过专业的训练，成为了一个优秀的产品专家。当时我的 Mentor 是一位非常专业的姐姐，每次接到问题都可以非常快速的反馈答案，而我很多时候都需要采取延迟策略，先接问题后反馈，因为确实不如她熟练。不过，当时我的 mentor 在一些与开发有关的复杂问题上也会找我讨论，我也觉得很开心。

可能是过去的软件本身就比较简单，亦或者是传统的软件厂商利用原厂优势刻意制造的一种“生态”，这种软件加服务的模式被业界所认可。原厂慢慢将更多的精力放到了产品，逐渐将利润较低的“服务”转给了其他合作伙伴。大量公司和人曾经也依然在这个生态中运转。

不过，随着业务压力越来越大，以及开源文化的发展，解决各类特定业务问题的开源中间件逐渐走向了舞台，这些软件将精力放在了解决问题上，与开发更加紧密，而且往往缺乏商业软件的包装，例如普遍缺乏精致的诊断工具和文档。也确实可能不需要这些，毕竟代码已经在这里了，有什么问题你不能自己解决？传统产品专家遇到了新挑战，或者说传统的软件服务的模式受到了挑战。此时，对一个产品最熟悉的专家可能是能改源代码的开发高手，或者是在自己的工作中有过大量实践的人。原先的产品专家失去了来自原厂的信息差优势，又缺乏足够多足够复杂的实践机会，所以想重新成为某个产品的专家，需要付出更大的努力。现实也是如此，做传统软件技术支持的专家，现在能比较好的转型到开源产品的，大多数本来就是开发出身，有比较强的动手能力。

说到 Kubernetes，问题更加复杂。首先，Kubernetes 可以看做是基础设施，所谓基础设施，就是一旦决定就不好改的东西，自然要考虑的更多，kubernetes 及其组件的复杂性，也决定了做出决策的困难性。第二，Kubernetes 是一个平台，但是很多人没有意识到这一点，还在按照传统的模式使用 Kubernetes，完全没有释放 Kubernetes 的能力。Kubernetes 已经改变了开发和运维的关系，工作方式必须有所改变，这里暂且放下，后面会详细介绍。

过去几年研发领域中的流行词一定会包括 DevOps 。每一种思想的产生，都不能离开其历史背景，显然 DevOps 也是如此。在软件开发早期阶段，或者许多初创公司，开发和运维并没有明确的界限。技术发展到了一定阶段，不管是有意还是无意，开发和运维变成了两个界限分明的工作。此时，随着交付的压力越来越大，界限分明的弊端显现，于是 DevOps 崛起，力图解决此问题。

如前所述，对于新兴的组织，采用 DevOps 的是没有任何负担的，因为根本还没有区分开发和运维。许多组织本身就是从一个开发者的应用开始的，所以 DevOps 天然的就是由开发主导的一种工作模式。

但对于已经建立起了开发和运维界限的企业，想要推行 DevOps ，无疑需要打破这种界限。但是，如康威定律所描述的，组织架构已经和开发运维架构匹配了，这种改变太难了。

所以，我们看到了许多怪异的现象。一方面，所有的人都在谈论 DevOps，新兴的企业自不必说，许多老套的企业也开始反复的提起 DevOps，可是实践中的 DevOps 支离破碎，也许个别项目获得了成功，但整个组织并没有发生特别大的变化。

几年之前，我还在 IBM ，也感受到了一种变化。一方面，我能体会到 IBM 有人早就看到了未来，当时学了很多内部课程，既有理论，也有实践，直到现在还很受用。但另一方面，不知道是哪方面的原因，我看不到客户的改变，或者说客户并不想和 IBM 一起改变，也可能是我当时的团队并不知道怎么改变，或者不想改变。

于是，我到了一家新兴的企业，期望有机会施展我所学到的东西。这家公司表面上是一个非常好的试验田。第一，这家公司利润不错，正处于成长期，所以有能力去尝试。第二，这家公司还是以开发主导的运维过程，与 DevOps 相同。第三，尽管存在所谓的 SRE 部门，但完全谈不上专业性，很被动，有很大的成长空间。虽然实际过程还有些波折，但我还是带领一个小团队，找到了一个能够紧密配合的研发团队，对应用进行了 Kubernetes 改造，设计了一个让开发很轻松的 CI/CD 过程，达到了 DevOps 的效果。

而此时，其他开发团队，也就是那些开发人员主导研发过程的团队，依然采用落后的模式。这种情况，很大程度上是因为这些开发人员对 Kubernetes 等产品认识的不足。当然，这种不足也是正常的，毕竟一个人的能力有限，并不是每个组织都有那种解决所有问题的天才程序员，DevOps 依然需要分工，需要专业人员。

许多组织还没来得及全面转向 DevOps ，结果就要回到老路吗？世界上有不少东西，会让人感到似曾相识，但其实已经发生了微妙的改变。经过 DevOps 洗礼过的运维开发者关系，发生了怎样的变化？

“人不能两次踏进同一条河流”，与上一次相比，许多东西都变了。交付速度的要求更高了，微服务让运维更复杂，Kubernetes 又简化了运维，CI/CD 将开发和运维串联了起来，我们应该有不一样的做法。

如前所述，在上家公司完成第一个项目的 DevOps 改造后，我发现了我们已经有了一个平台，还有许多最佳实践，很自然，我想将这种先进的生产力发扬光大。我们也发现，这个平台的“门槛”可能高了，每个开发者都需要了解一些 Kubernetes 的基本概念，需要了解 Jenkins ，也要对这个过程有清晰的认识，所以也才能在各个管理界面正确的切换。

因此，也许我们需要的是一个开发者平台。如果说以前开发和运维是通过工单来关联的，那么新时代将会是通过平台来沟通。这里借用一下 ThoughtWorks 的一张图：

这个图是按照 DevOps 的术语画的，但其实也有许多不同的表达方法。如果从传统运维改造的角度，可以认为是将原来的运维团队分成两部分，一部分构建上图所述”中心团队“，负责平台建设与赋能，而另一部分运维则转向业务和平台的结合，和不同的业务开发团队组合成各个”非中心团队“，帮助各个非中心团队用好平台，并能够反馈需求，提升平台的能力。

去年，怀着让自己的经验继续发挥的想法，我带领新公司完成了整个研发部门的云原生改造。又通过各种渠道了解了其他组织的情况，我的感受愈加的强烈，Kubernetes 不仅仅是一个技术问题。许多资源比我们丰富的团队，整个开发运维过程却没有我们顺畅。表面上看是因为没有释放 Kubernetes 和相关基础设施的能力，而更深层次的，则是组织架构与职责上，还没有调整到位。通过一些 DevOps 实践可以帮助我们理解这个过程，知道以后要怎么做，但这要付出许多成本。而实际上，平台工程这个想法本身就是许多 DevOps 实践的结果，如果说因为各种原因我们未能在 DevOps 尝试太多，那么直接借鉴其他组织的经验（平台工程）可能是一个好办法。相对来说，阻力会更小，组织结构依然分为开发与运维，只是开发与运维的界限有一些调整，沟通的方式有了一些变化。

欢迎大家关注我的网站 https://yylives.cc/，以及我们的公众号：