分享 | 王津银
Tech Minds是又拍云主办的高端技术领导人私享会系列活动，每个月在全国不同城市巡回举办。为了保障私享会的分享效果，我们对参会人数进行了控制（15人以内），参会者主要是互联网公司技术负责人（C-Level、总监级或运维负责人）。
Tech Minds的第一、第二期分别在深圳、广州举办期，第三期Tech Minds将于8月27日移师北京。
优维科技创始人、CEO王津银，参加了Tech Minds的第一期、第二期活动，并在公众号“互联网运维杂谈”（公众号：waynewwang_ops）上总结了在8月6日第二期Tech Minds上的技术分享，将其对DevOps的理解，总结成三个词语：一致性（Consistency）、可用性（Availablity）和距离（Distance）。
又拍云获得了王津银的授权，特将整理内容共享给各位技术爱好者。以下是分享内容：
谈起DevOps，涉及到的东西太多，有文化，有工具、有架构、有组织、有思维、有过程、有度量等。之前看了一个DevOps模型，它从持续交付的过程来看，包含源代码管理，持续集成、持续测试等等，涉及到的点大概有十几项。
在上周六的广州分享会上，我们的主题是【运维与架构之美】。其中谈到了DevOps，我极度简化了我过去对DevOps的理解，总结成三个词语：一致性（Consistency）、可用性（Availablity）和距离（Distance）。
关于一致性
说到一致性，DevOps表达的一致性路径首先是理念的一致性，然后才是技术的一致性，最后是环境的一致性。
DevOps取的是Dev、Test、Ops三个团队的交集部分，其实这里面隐含的意思就是大家的思维、目标都需要达到绝对的一致。
1.研发要考虑后续的可测试性和可运维性
2.运维要考虑服务能力和后续的生产状态如何快速回馈到研发侧，从而持续优化
我记得Martin Fowler有一个图很形象地表达了过去软件组织中几类角色存在的问题——单一化思维。研发之关注自己的功能实现，对于非功能性需求，基本上优先级很低或者不考虑；对于测试来说，我只考虑在Dead Line之前版本测试完成，找到一定的Bug，完成KPI；对于运维来说，只剩下背锅部署，死扛的结果了。
在DevOps下，不能如此了，要把彼此的思想放到对方的脑子中。这也是为什么DevOps一直在强调组织和文化的核心原因了。
从这个理念的一致性出发，接下来要解决技术的一致性问题。在涉及到多产品的研发组织中，该问题尤其复杂。大到架构类型的选择，小到一个技术组件的考虑，都需要有一致性的要求，始终紧扣对业务的高质量支撑。有了技术的一致性要求，就避免了技术的失控。
接下来解决一个交付过程中，一直没有有效解决的问题。只要做过手工部署的人都知道，在测试环境明明是好的，怎么到生产环境就出问题了？有人说这是环境不一致导致的，为什么不一致？是因为我们一直手工部署导致，并且还是不同团队部署的，难免会产生不一致。
的确如此，所以我们实践DevOps，实践持续交付，不就是要解决这个不一致的问题么？让我们看看12factor，里面有一条核心准则：Dev/Prod Parity，Keep development, staging, and production as similar as possible。这条准则很好地说明了环境之间的一致性的重要性，而问题的核心是需要把人工部署变成自动化部署的模式。
基于应用包的交付一定程度上解决应用交付的一致性问题，如果要彻底解决，此时需要建立以应用为中心的完整资源管理，才能确保交付过程不会有遗漏。这始终还不是有效解决方案，终极方案应运而生——Docker。Docker提出的Immutable(不可变）概念，彻底的解决了这类不一致问题，可以确保Dev到达Prod过程中，整个交付过程是绝对不可能被变更的。
关于可用性
DevOps实现了团队之间的容错性和高可用，这个和技术原理类似。
以前总是想着在运维内部备份，是否可以实现一些能力在跨团队之间备份。当运维需要故障自愈的能力，研发是否可以考虑从技术实现？当研发需要实时的了解服务现状，运维是否可以提供一个统一看板供研发了解。
其次才是业务上的可用性，此时这个词很好理解，但不好理解的是为什么这个指标只是某个团队的职责，而其他的IT团队则可以不关注？非常的不合理。难道质量是能靠运维或者测试出来的，与研发无关？
其实可用性应该是所有团队共同承担的指标，特别是要和研发有关，不能只生不养。DevOps需要大家一起为它负责！
关于距离
这个时候，我会把DevOps思想和精益思想完全做个映照，精益思想强调了拉动式快速、自动化的交付价值链；而关于IT的DevOps思想其实何尝不是在讲IT交付价值链？
这套价值链的高效运转就是持续交付。通过持续交付各种技术手段：持续集成、持续测试、持续代码审查、持续部署、持续反馈等等，不断突破部门的障碍，打通部门障碍的同时，也是在拉近内部的IT能力到达用户的距离，特别是时间上的距离。
IT系统不再是一个支撑系统，而是一个真正的创造价值系统，价值在IT链条上流动（Flow）的快与慢，也是企业的核心竞争力的表现。
此时距离其实就是效率的表现，高效可以表现空间和时间的缩短，低效则反之。
DevOps的确是一个很复杂的体系，有人看到了驱动因素，有些人看到了过程因素，有些人看到变革因素，有些人看到了业务因素.....太多太多，且把CAD算是我对DevOps一个另类的思考吧。
网友评论