标签：DevOps JFrog Artifactory HERE Netflix
刚刚过去的2017年对于 DevOps 来说是里程碑式的一年，各个行业都开始结合自身的业务特点，在落地 DevOps 这件事情上有了一些规划、探索。虽然大家对于 DevOps 究竟是什么依然未能完全达成一致，但每个企业确实又能找到符合自身能力需求的部分。DevOps 带有很强的实践色彩，解决实际问题才是王道，既然那么多的 DevOps 工具、流程和方法无法一次性落地，那么先解决一部分问题总是好的，这也很符合 DevOps 的实践精神。2018年，容器技术和 DevOps 这对好兄弟会联手上演一场大戏，这是业内大家都认同的趋势。但具体落地的路径究竟如何，目前都还是经验积累阶段。闻道有先后、术业有专攻，在众多的工具、流程和方法中找到一个解决所有问题的“银弹”固然是不大可能，但总结一些经验和教训，对未来做一些预测总归是有备无患。
DevOps 最直观的一个价值就是自动化，自动化构建、自动化测试、自动化部署等等。自动化的价值自然是很清晰的，但目前的自动化还是各种工具、各种平台、各种语言独立在走自动化之路。比如，公司里的 Java 项目和 Node 项目，由于其私服都是各自搭建的，仓库也是各个团队在维护，自然各个团队直接都是烟囱式的结构。这种结构的问题在于很多协作变得不可能，比如 Java 项目团队将仓库分为了开发库、测试库和发布库，制定了一套机制很好地实现了发布流程自动化的机制，但其他项目还是得重新去构建自己的流程和规范。
未来的趋势肯定是一个仓库包含所有的语言类型，比如 Java、Node、Python 等等开发语言，统一提供高可用、负载均衡和容灾备份等问题，那么这些仓库都适用同一套自动化规则。DevOps 一个很重要的标准就是可度量，只有在流程统一的情况下才方便去持续度量，然后发现问题从而持续改进。
在规范了自动化的流程后，数据将会变得更有价值，而且随着时间的推移，历史数据将能提供更多的智能化决策建议。每一个数据点的背后，都带有一个基准数据作为参照系，企业可以根据自身的成熟度模型适当调整，但总体来说，数据不再只是反映当前的状态，更多地是实时与历史数据、基准数据做对比分析，动态提供建议、风险评估和预测。
如上图所示，在1月23日这段时间，与基准的运行轨迹差别很大，说明计划外的任务或者 Bug 比较多，那么意味着工作量评估存在一些问题，可能是 Buffer 设置不合理，或者是对人员的能力评估不准确等等。系统在这些异常点给出一些警示及可能的建议，那么在下一个 Sprint 开始时，对于用户的设置提出一些风险及建议。
数据变得有温度，这是数据应用的最佳实践，但这背后要有很多的数据分析能力的支撑，所以，DevOps 变得智能将是下一代 DevOps 的显著特点。
当然，数据决策最直观的方式还是可视化，在这方面 Capitalone 开源了一款 DevOps 可视化面板 -Hygieia。这款产品是支持高度自定义，且支持多种 DevOps 工具的可视化，如代码提交频率，构建情况及质量情况等等，从团队管理者提供快速的决策支持。
容器的兴起对 DevOps 有不小的促进作用，这也是未来的趋势。Mesos 与 Kubernetes 争雄的时候，很多人认为 Kubernetes 只是玩具，难以担当数据中心操作系统的大任。容器编排的意义不仅仅在于管理一堆容器，更重要的目的在于将整个数据中心抽象成一台服务器。好在 Kubernetes 发展迅猛，从应用运行的角度切入，最终赢得了大家的欢心。Mesos 只是做了更长远的事情，但未能知所先后，导致发展趋缓。
目前还有很多应用是通过脚本来部署的，当然大部分都采用了 Ansible 等工具，但只是提高了时效性，部署者依然需要关注应用运行的基础设施是什么样的。容器及容器编排技术使得完全可以不关注底层基础设施，将一个应用扔到服务器的×××大海里，可能在物理机上运行，也可能是虚拟机，可能是 CPU，也可能是 GPU 的，更加不用关心是什么样的操作系统。大有“只在此山中，云深不知处”的意味。
从最近流行的 Service Mesh 更加佐证了这一观点，应用和基础设施的剥离是大势所趋，只不过是一个循序渐进的过程。所以，Devops 和容器技术是互为因利乘便的关系，容器是未来应用运行的标准形式，DevOps 也将加速这个潮流。但这并不否认传统非容器应用的价值，但也一定是朝着与基础设施无关的方向发展。
如果前三个方面趋势成为现实，那么应用发布的速率将会呈指数上升，发布日将不再存在，随时随地上线，滚动升级将成为现实，然而大规模、复杂系统的上线靠什么来保证质量呢？ 最近比较流行的混沌工程可能是这方面的一个探索，通过引入一些扰动因素来逐步完善灰度的策略，这个过程就是一个持续学习、持续优化的过程，同样，历史数据起着至关重要的作用，大量的算法和机器学习开始登场了。
Netflix 公司的开源项目 Chaosmonkey 已经有这样的趋势，通过随机地关停虚拟机或者容器去看系统如何做出反应。目前来看，Kubernetes 的应用迁移、弹性扩容、副本集等特性具有很大优势。但单纯从应用层面处理肯定不够，还有一个很重要的层面需要关注，那就是应用的模板-镜像(或者二进制包)，未来的复杂场景肯定是多地域的，那么数据中心之间的快速自动分发，仓库高可用、容灾备份等也是确保整个灰度系统正常运转的关键要素。
正如第四点所述，更复杂的灰度场景，需要更多底层的支持。目前一时间还难以实现应用全部容器化，但多种语言、仓库的高可用、容灾和分发是必须满足的场景。既然应用可以在多个数据中心任意迁移，那么应用的"母体"也必须可以同步迁移，否则混沌工程必然发生混乱。
从目前的工具来看，很少可以达到这种要求，JFrog Artifactory 具有这种全球分发的案例，在2017年 AWS 技术峰会上，HERE Technology 分享了他们的案例，通过这种方式支撑了百万级别工件量级的分发，每天在系统里流转的数据超过 10TB，从市场上的情况来看，他们已经走在了前列。
标签：DevOps JFrog Artifactory HERE Netflix
原文地址：http://blog.51cto.com/jfrogchina/2091060
