陈军--原腾讯高级项目经理、华为精益敏捷专家
DevOps是现在非常流行的一个词，很多人都在提DevOps，在往那个方向去转，但转的时候坑特别多。
现实是很理想的，大家都觉得做了DevOps之后就会非常快了，业务就会非常好了，但其实做了DevOps之后，你的业务也不一定会非常好。在很多公司内部也有共识，工程跟业务没有任何关系，但做了总比没做好。
这是转型的J型曲线，这个曲线出现在DevOps2018的报告里，但这个曲线在很多变革当中都会出现，这个是Model的原型，做任何一场组织变革，DevOps也好，敏捷也好，都会经过这样的曲线，这中间有一个非常大的坑要过，经历过这个痛苦的过程之后，你的绩效会变得越来越好。
转型的时候我们希望大家有一个思考的逻辑。这个思考逻辑从上到下是Values、Principles、Methods、Tools&activities。不要一心铺到工作上，要想清楚价值是什么，采用的是什么原则，要用什么样的方法，再取决于用什么样的工具跟活动。
敏捷价值观就是敏捷宣言那四句话，那四句话是我们的价值观，价值观下面有原则、工具、实践活动，这是思考转型的逻辑，DevOps也是一样的。
DevOps里面有敏捷、精益、持续集成、持续交付 ，里面包括很多东西，你在真正解决问题的时候要得到什么样的好处，你用的是什么原则，用的是什么方法，然后再配相应的工具，这是你转型的原则。我觉得这样非常重要，如果思考不清楚就不要去用。
所以我们在做一件事情的时候，你要获得的价值是什么？这是你要思考的逻辑。
1-DevOps是个坑
这个图大家可以看得很清楚，第一个是Dev&Ops，原来的Dev和Ops是分开的。当我们用了DevOps之后，它还是一个坑。最怕的是把这个坑丢给客户了，所以我们这里非常重要的原则就是坑谁都不要坑客户，你不要把不好的东西给客户。
在华为有一个团队，领导意识到在转型的过程当中肯定会有坑，所以领导帮团队去承担了处分，最后处分的是领导。这个也是在DevOps转型时非常重要的点，团队一定会犯错，但作为领导要帮团队创造容错氛围，不要一犯错就指责团队，坑谁都不要坑客户，这是非常重要的点。
这是DevOps的模型，可以看到最底层的东西是精益管理。
精益的来源是谁？丰田。
丰田最重要的两个原则是自生产和自动化。但这两个原则其实是冲突的，这个厂讲流动要快，另一个厂讲出了问题要停下来，所以这两个是冲突的，丰田不仅要快而且质量要好。
最早丰田是做织布机的，把手动织布机改成了自动织布机。一开始的版本有问题，一旦织布机的线断了之后织布机不会停，跑着跑着出来的布是有问题的，因为里面的线断了，所以出来的是残次品，质量非常不好。后来丰田做了改进，一旦线断了织布机会停掉，需要人把线接起来再跑，这就是丰田注重质量的原则和方法。
建立以下游为中心而优化，做到质量内建。不能把问题留在下游，一旦这个过程出了问题，整个生产都要停下来，这是持续集成、持续交付非常重要的原则，一旦流水线出问题断了，你第一时间要处理流水线，而不是填新的代码，这是非常重要的原则。
2-技术债务拖后腿是一个坑
这是目前非常隐形的问题，虽然大家不是很在乎，但如果你的产品想长期发展，想速度越来越快，这是很重要的事情。我们可以从漫画里看到，这两个人一直在挖坑，发现自己挖到一定程度就出不去了。我们现在就是这样，我们是在给自己挖坑，虽然看起来还觉得很快，但回过头会发现，那些坑已经填不了了。
质量分外部质量和内部质量。外部质量是用这个产品时体会到的，通常是通过测试去覆盖的，内部质量是指代码。从这个系统思考图，可以看到有很多的恶性循环。如果外部质量差，测试信息会受到影响，测试周期会越来越长，因为不知道哪里会出问题，会影响到交付周期。可能会尽快交代码，交代码会乱写，内部质量会越来越差，这是恶性循环。内部质量和外部质量之间的影响是有实质的，不会那么快的反映出来，所以很多时候我们重视外部质量，但忽略了内部质量。内部质量差的时候，会发现核心功能会越来越慢。
怎么减少技术债务？ 我们说衡量代码质量的唯一标准是你在做代码检视的时候每分钟说了多少个F词。我在一个关于DevOps的网站上看到一篇非常火的博文，推荐了DevOps相关的十本书。推荐的第一本书其实跟DevOps并不相关。要把DevOps做好，基础代码质量是非常重要的事情。
怎样减少技术债务？代码的规范是非常重要的。为什么代码的规范非常重要？首先你的代码是写给人看的，不是写给机器的，这是非常重要的事情。读代码和写代码的比例时间是10：1，你的代码一定要先写给人看再写给机器。你想想如果要看别人写的代码，如果你很痛苦，怎么改这个代码？很多的遗留代码我们不敢去改，因为看不懂，所以代码规范非常重要。在谷歌专门有一种人是做代码规范review的，他们内部有一个可读性的证书，有了这个证书才能review别人的代码，而且有权利把别人的代码打回去。如果他的代码没有通过，是没办法提交的，谷歌做的就是这么严格，可读性是非常重要的事情。
规范与度量包括代码规范、代码质量度量。谷歌的code review做的非常严格，一定要通过code review才能提交代码。工具辅助包括规范检查、代码质量检查。重构这个事很重要，比较重要的是童子军规则，在出营地的时候要比进营地时的这块地更干净。如果我看了这一段代码，当我关闭这段代码的时候，一定要改。重构不是运动，不是临时想起来就要大范围搞一下，一定是平时就要去做的习惯，看到代码不爽就要去改。
3-团队的一个案例中的坑
某实施DevOps的团队遇到下面的问题，一开始他们采用主干开发，但是频繁提交代码集成无法保证主干的质量（主干健康度的度量），QA会经常找团队，团队觉得非常烦，慢慢他们不再那么频繁提交，做完一堆需求再一起提交。后来PM抗不住了，改变策略采用分支开发，大量的问题在集成测试时爆发，导致集成测试时间很紧。如果是你，你会怎么给他建议？
我给的建议是，其实他们采用分支开发是往后退的，在持续集成里有一个非常重要的原则，他们绕过痛苦的事情就会更痛苦，频繁提交是ok的，他们要解决的问题是怎样把主干集成度做起来，而不是往后退。当时他们也有做单元测试，但他们的单元测试是后补的，不是跟代码一起提交的，所以主干健康度比较差。他们要改变的是把单元测试和代码同时提交，一定要跑过单元测试代码才能往上提。现在华为提交代码到主干的时候，都会有一个所谓的门禁，门禁里面要检查很多东西，包括代码、规范、质量指标、单元测试都要跑通才能提交代码。
这里面有两个，一个是机器检查，一个是Code Review，这两个都提交才可以。但不能说主干质量不好就往后退，要解决主干质量的问题，而不是往后退，所以越痛苦的事情越要经常做，越要频繁去做，痛苦的点才是你要改进的点。
让代码流动起来，并快速获得反馈。一定要小批量频繁提交代码，但提交代码是有前提的，要过门禁才行。
4-微服务是个坑
微服务也是我们现在提的比较多的东西，到底要不要做？很多人都在说。这里的理念是什么？如果你的代码是一坨shit，切成微服务就是N坨shit，是管理一坨还是N坨？你做微服务的基础是系统要比较好，微服务架构要紧的是如何正确划定边界，微不微其实不重要。我们最近有一个上海的团队，他们切了微服务尝到了一些甜头，但更痛苦的是服务间的耦合以及服务与硬件的耦合，这让他们非常痛苦，改一个地方要改好多服务。这个团队在跟南大教授合作，一个是微服务密度的问题，一个是微服务拆分的问题，其实很多服务不用拆，既然耦合度这么高干嘛要拆？微服务改了之后其他的都要动，干嘛还要改？
这是Martin Fowler2015年提出的 单体优先 。微服务本身在做的时候有很大成本，它的成本能不能给你带来更多的收益？这是我们在做一项决策时会考虑的，就是投资回报率的问题。
Martin Fowler强调单体优先，如果一开始做微服务很多的基础设施都要跟上，这个成本蛮高，所以他提到微服务溢价的问题，要看微服务的好处能不能抵消成本。
构建演进式的架构，地球以前的大陆是在一块地，随着时间的推移和环境的变化才慢慢演进出了各个洲、各个块，我们的架构也是一样的，不一定一开始就要创建合适的架构，可以创建演进式的架构，可以在特定的时间进行转换。我们要注意几个原则，讲的都是解耦的问题。
一是将大型的域分割成变更孤岛；
二是针对可替代性进行设计。可替代性是什么？原来很多的系统跟模块不敢去改，虽然这块可能很多人没用，但我们也不敢改，因为有耦合性，我们不敢动。如果针对可替代性做服务，这个服务如果不用了，随时可以停掉，把服务直接杀死接新服务就可以了；
三是最小化共享依赖，重点关注自治和冗余，而不是重用。
5-度量是个坑
度量我们听到的最多反馈是什么？这玩意儿就是给上面看的，没什么用。没有这些指标，我咋知道下面的人干的咋样？这是我们听到最多的说法。包括有人说为了确保数据的真实性，需要加上考核指标。有一些团队是分布式的，在很多地方，他们想知道异地团队在干什么事。我们有一个IT系统，怎么确保他们更新的数据是真实的？是不是要加一些考核指标去考核他？保证他更新的数据是真实的。这些都是我们常见的对度量的误解。
有哪些度量的误区？一是数据的生产者不是数据的消费者，数据生产者不关心数据的价值，也不关心数据准确与否。很多时候数据是给领导看的，不是给我们看的；二是数据的生产者关心是佛会对自己带来惩罚或受益，不关心数据跟软件开发的关系。这会产生什么问题？数据造假；三是数据等于控制，一定要看到数据才知道下面的人在干什么。
度量的意义到底是什么？我们觉得度量的意义是改进。改进在于什么？自己跟自己比，不要横向比较，每个团队都不一样，横向比较是非常痛苦的一件事情，我们在华为是踩过坑的，这个事我就不太好讲了。横向比较和晾晒的原因，导致很多团队的数据造假，这是华为真正踩过的坑，曾经是华为内部很轰动的事情。度量会告诉我们离目标还有多远，现状是什么，进展如何。
这是一个度量指标的体系，非常多，大家可以参考一下。
度量是一个系统工程，需要不断演进。首先你要知道度量不是免费的，有成本，需要有效性和可靠性，我们收集的数据最好是机器产生的，而不是人去填的，这个很重要。第二个是OMTM，这是精益数据分析的概念，叫单一关键指标。选择适合当前的产品阶段的指标，重点优化该指标。最好是这一段时间就优化这一两个指标，不要分得太散。第三个是随时审视，做加法也要做减法，不要让度量成为团队的负担。最重要的一点，不要跟考核挂钩，不要横向比较，这是华为踩过的非常大的一个坑，一旦跟考核挂钩，一旦横向比较，数据一定会造假。
6-缺乏全局视角，阻碍进一步提升是一个坑
这是DevOps三步工作法中的内容，第一步是持续流动，第二步是持续反馈，第三步是持续学习。今天我们要讲的是持续学习。
这里有一个案例，数据大屏让团队拥有全局视角。我们在华为内部看团队数据是否做好，就要看数据大屏是否做起来了，研发所有的数据在这个屏上都能看到。这是一个微服务团队的分数，包括服务得分、服务告警、API访问次数TOP等等都有，可以根据自己的情况去做。消费者那边的数据才多，今天现场的左屏一直延伸到右屏都是数据。这个用处是什么？让研发团队看到全局，知道我这个东西发出去之后有多少人在用，有没有问题，有问题要及时解决。
这是其中一个案例，这个接口原来有性能问题，就是在没有大屏之前。运维也跟团队讲了，但没人管，大家都在做新的需求。后来有了大屏之后，这个就很前沿的，因为它的性能很差，团队和领导看了安排人员去优化，接口性能提升了9倍。
通过大屏数据挖掘用户潜在需求，提升满意度。这也是一个真实案例，通过服务发出去，关注运营指标，他们看到在9月份访问量突然增加，但用户数又没有变。他们进一步分析，找到用户去问，为什么这个时段的访问量这么大？后来发现是因为用户定期会有巡检，然后就挖掘了更多用户的需求。这对于开发团队来讲也是很重要的一点，很多时候东西发出去不知道用户的满意度怎样，有没有人在用。
最后再回顾一下这张图，我们转型的思考逻辑，首先是价值，做这个事情对我们的价值是什么？我们需要的原则是什么？我们应该用什么样的方法？对应的工具和时间活动到底是什么？DevOps不只是工具，转型应该是更高维度的思考，自上而下。
Worktile官网：www.worktile.com
内容整理：Worktile
文章首发于「Worktile官方博客」，转载请注明来源。