转载

DevOps，关于一致性(C)、可用性(A)和距离(D)的表达！

谈起 DevOps ，涉及到的东西太多，有文化，有工具、有架构、有组织、有思维、有过程、有度量等。之前看了一个DevOps模型，它从持续交付的过程来看，包含源代码管理，持续集成、持续测试等等，涉及到的点大概有十几项。

最近我们（优维）和又拍云一起搞了次小范围私享会，为了保证效果，我们都是控制了人群的数量（20人以内）和质量（总监级或者运维负责人）。连续两次的分享，效果还不错。

在上周六的广州分享会上，我们的主题是【运维与架构之美】。其中谈到了DevOps，我极度简化了我过去对DevOps的理解，总结成三个词语：一致性（Consistency）、可用性（Availablity）和距离（Distance）。

说到一致性，DevOps表达的一致性路径首先是理念的一致性，然后才是技术的一致性，最后是环境的一致性。

关于一致性。DevOps取的是Dev、Test、Ops三个团队的交集部分，其实这里面隐含的意思就是大家的思维、目标都需要达到绝对的一致。研发要考虑后续的可测试性和可运维性，而运维也要考虑你的服务能力和后续的生产状态如何快速回馈到研发侧，从而持续优化。

我记得Martin Fowler有一个图很形象的表达了过去软件组织中几类角色存在的问题---单一化思维。研发之关注自己的功能实现，对于非功能性需求，基本上优先级很低或者不考虑；对于测试来说，我只考虑在Dead Line之前版本测试完成，找到一定的Bug，完成KPI；对于运维来说，只剩下背锅部署，死扛的结果了。在DevOps下，不能如此了，要把彼此的思想放到对方的脑子中。这也是为什么DevOps一直在强调组织和文化的核心原因了。

DevOps，关于一致性(C)、可用性(A)和距离(D)的表达！

从这个理念的一致性出发，接下来要解决技术的一致性问题，在涉及到多产品的研发组织中，该问题尤其复杂。大到架构类型的选择，小到一个技术组件的考虑，都需要有一致性的要求，始终紧扣对业务的高质量支撑。有了技术的一致性要求，就避免了技术的失控。

接下来解决一个交付过程中，一直没有有效解决的问题。只要做过手工部署的人都知道，在测试环境明明是好的，怎么到生产环境就出问题了？有人说这是环境不一致导致的，为什么不一致？是因为我们一直手工部署导致，并且还是不同团队部署的，难免会产生不一致。

的确如此，所以我们实践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，关于一致性(C)、可用性(A)和距离(D)的表达！