关于DT研发过程改进的建议

下面我要说的话完全是肺腑之言，但可能是错误的。

结论：当前DT的敏捷方向是错的

把世界变得更简单，就能够让世界更美好。

简单会拥有所有优势。单一大系统拆分成多个微服务，每个微服务就更简单。从体量上看，如果系统产品是一个单体系统的话，那DT的规格型号就是微服务。我们学系统产品研发模式有点造孽，比如发版流程：把多个微服务用一个月的时间聚集在一起，共赴前线。如果能够一个排行军，为什么要十万大军一起行军呢？我们为此付出的代价是极其惨痛的。

在一个微服务上开发、测试、上线，从灰度到所有用户使用，这是简单而愉快的事情，thoughWorks，腾讯、亚马逊都是如此。我们却学了运营商系统产品，本来可以一个排上前线，变成了十万大军上前线，路上各种协调、指挥投入巨大，十万人吃个饭都是难度极大的事情，我们DT现状就是如此，发个版一大堆人看着。本质上DT产品是可以做到小而美的，和系统产品在体量、交付要求是不同的。

我认为DT要快。DT痛点是质量差，我们的思路是通过快速修复来达到质量要求。所以快不等于放弃质量，只是维持质量的方式不一样。如果只写一行代码，然后提交流水线自动测试自动灰度，过程中任何环节发现问题，几分钟就能快速定位和解决，因为只有一行代码。然而同样的问题发生在几十个微服务当中，那将需要几十倍上百倍的投入，多数还形成恶性循环。

金钟罩很美好，而DT要的是独孤九剑。

把ci/cd持续集成持续部署、自动化测试、自动预警做好，让需求-代码-上线闭环变得越简单、越快是DT研发的方向。