vlambda博客
学习文章列表

自动化测试体系不完善、缺少自助式的持续交付平台、系统间耦合度高服务拆分难度大、成熟的 DevOps 工程师稀缺，缺少敏捷文化……这些都是 DevOps 在落地过程中，或多或少会碰到的问题，DevOps 发展任重道远，不断学习前人经验完善自身是很好的选择。

11 月 23 日，京东云开发者社区和英特尔联合举办的「京东云 DevOps 自动化运维技术实践」沙龙在上海落地，为开发者们分享京东云在 DevOps 上的经验。

（京东云工具产品研发部副总监 井亮亮）

在行业内，每年 DevOps 现状调查报告里，都会去衡量 DevOps 对于一个组织的生产活动的影响，定义出“高效的组织？”，会从 4 个方面去衡量，分别是：部署频率、软件交付周期、变更失败率、平均修复时长。持续交付目标是提升交付效率和确保交付质量，但交付是线上变更，那么有变更就意味着会有风险，那么，如何降低软件交付的失败率，控制风险，就变成了企业持续交付考核的一个重要目标。

“我统计了一下，京东云在今年的线上软件变更失败率控制在在 0.46%，但，我们仍然有4成的故障是由变更操作引起的，实施持续交付，对于确保整个软件交付质量来说是至关重要的。”井亮亮说。

很多公司在内部实施交付都曾或多或少产生过这样问题：开发说"我想更快的开发，但构建系统却频繁出问题！”，测试说“我需要更快测试，但没有环境！”、运维说“我有太多环境需要管理！”……京东云也不例外，那么持续交付如何解决跨团队合作的一些问题呢？

2013 年之前是”HumanOps“，通过脚本手工上线，无法做到自动化；

2014 年到 2016 年是 Jone(京东持续交付平台) 时期，在 Jone1.0 交付采用 Rsysnc 的方式进行，上线过程经常会线上排队；16 年启动了 2.0 的迭代，Jone 采用了 ansible 作为发布的工具。

2017 年京东云推出京东云翼，云翼是一整套的 DevOps 平台，不仅包含持续交付，还包含了智能监控、智能运维、门神等能力。

• 统一的部署规范

• 灵活的部署流水线

• 企业文化策略协助

在部署规范上，部署规范的统一，是企业实施持续交付的基础，在京东云内部会要求如下：

1. 我们有统一的控制系统去操作线上，减少操作的渠道，减少风险，因为我们的控制系统可做到秒级回滚。

2. 会提供统一的基础镜像，这样不会因为操作系统不一致的问题造成的风险，服务都是用统一的账户去启动。

3. 会统一部署路径和日志路径，利于排查问题，以及查询日志。

4. 线上服务的启停命令，都是我们提供的统一的模板，防止不同人员自己编写导致的健壮性不够的故障。

5. 禁止手工，所有的构建都必须走系统去把控质量。

6. 系统会控制没有上预发的 app 是不允许上线的。

7. 另外会控制避免上线导致全流量丢失的上线操作。

部署流水线可以帮助解决如何在企业内部推动各个团队用你的标准规范和平台，流水线是搭台子，各个业务可以在上面进行唱戏。

在做好规范和部署流水线的前提下，企业内部的落地推动，需要企业文化的支撑，持续交付不仅仅工具的支持，仍然需要文化的支撑。

• 首先第一步要构建了 CMDB 的建设，关键是 CMDB 模型的建设，并要确保 CMDB 数据的准确性。

• 利用容器技术提升持续交付的能力，容器要做扩缩容，可提高运维的效率，极大节约了资源的成本。

• 复杂业务场景，需支持编排部署，如一次几十个应用的发布，这时就需要编排能力的建设，编排主要分为 3 步：模版编写、设置策略、一健发布。

（京东云工具产品研发部总监 颜志杰）

监控目标就是降低损失，通过发现、定位、解决问题，期望缩短异常出现的 MTTR （平均修复时间）。

为了实现缩短 MTTR 的目标，监控系统应该具有这些能力：

1. 数据采集能力，获取可观测的数据

2. 数据能够方便加工，比如把相关的数据汇聚起来，得到我们需要关注的数据

3. 对这些关注的数据，做异常检测，及时产生告警

4. 收到告警后，通过 Dashbord 查图定位，专家诊断推荐平台，加速定位

5. 定位问题后，通过预案平台进行快速止损

6. 整个监控系统需要做到高可用，监控就是为了发现异常，如果由于异常导致自身不可用，肯定是减分的

典型监控系统从功能模块分为采集、计算、存储、告警、算法、业务端等。从数据视角去理解，监控系统就是一个数据处理系统，便于我们简化系统设计以及更好理解监控系统。那么从数据视角分析监控系统，还需要优先考虑以下这几个部分：

1. 数据模型先行，不同模型代表着不同的数据描述及处理能力，进而会对监控产品的形态产生影响

2. 监控采集就是数据标准化的过程

3. 监控数据存储具有读写正交、meta 的灵活查询、最新时间热点查询需求，京东云采用列式存储 + 倒排 +Gorilla 的方案选型

4. 聚合计算就是对数据进行范围圈定，进行算子处理

5. 报警通路做好“质检员”工作，同时完成通知用户这件事情

监控需要覆盖基础 - 存活 - 性能 - 业务四个层面，从而保证采集数据的全面，进而避免监控遗漏。那么如何按照监控标准去指导监控产品的落地呢？看京东云如何从发现问题、定位问题和解决问题三个方面来减少 MTTR：

在发现问题阶段，分别面向管理者和运维人员设置监控系统的打分机制及推荐系统，给予管理者一个直观的总分和每个维度的细分得分，使得管理人员对整体监控有个量化的指标，另一方面，对于运维人员，则提供配置推荐、一键启用，可以快速地根据标准去完善监控，达到监控变‘全’。

在定位问题阶段京东云推进了变更可视化项目，将上线、配置更改、第三方的变更事件，都接入到变更事件中，用户可以根据时间去查询时间段的变更，跟报警做关联，京东云也会根据一些相关性的算法推荐，将变更推荐给用户，加速问题定位过程。

处理问题阶段京东云可提供预案平台，对预案进行标准化分类，指导用户管理预案。

这就需要首先数据量化，先统计各个渠道的告警总数，然后分两步走，对于产品线负责人，需要让产品线的负责人知道自己部门的情况，另一路出分析数据，拆解产品线发送多的原因，给运维同学提供数据指导，分析各种有可能导致发送告警多的原因，如：一条短信平均接收人、哪些告警规则发送较多等。

基于这些统计数据，监控团队去成立告警收敛项目：在面对接收人过多的情况（一个短信原来需要 10 几个人接收），京东云推出值班表计划，在产品设计上保证告警规则设置的合理性，对于一些大规模触发情况，比如网络故障，京东云默认会按照规则、应用进行合并，同时为了在合并之后让用户能看的更清楚，京东云也推出了移动端程序。

（京东云平台质量部总监 丁超）

“质量也是一份事业，向做质量的同学致敬”

京东云的形态包含公有云、专有云、混合云、多云形态，基于京东云产品的特性，质量服务应关注如下 4 个维度的内容：

1. 标准化流程建设，及配套的 check 服务。流程覆盖从需求、设计、编码、测试、发布、监控到工单。以解决需求不明确、设计后期频繁变更、代码分支混乱、测试无准入准出标准、发布无标准、线上运行时数据无观测等问题。丁超建议人工先把事情做起来，先有再深入，再自动化。

2. 垂直方向上业务能力和场景的建设。质量部门更关注产品的能力验证、能力评测。以解决测试目标及内容不明确、无准入标准、准出标准、业务场景的模拟(用户是怎样使用产品的)、产品能力及局限性、对标评测等问题。

3. 横向视角上的平台能力建设。质量部门需要需要解决的问题是：持续集成、效率问题、性能及安全评测能力、资源及环境快速获取能力。

4. 作为云厂，或者作为企业，如何从云获得专业服务的能力。需要解决的问题包括：针对客户场景的质量解决方案；让客户无需分神质量专业性的建设；保证使用门槛低，效果好。

衡量质量的指标，一是看服务可用性 SLA，二是考核线上的故障数，三是要给用户交付功能清单，四是有性能测试指标 QPS，五是数据持久性，六是安全性，七是兼容性，根据以上指标，通过 4 个维度的质量建设，最终需要给用户交付极致的体验。

传统企业中的 CMM 标准，其对质量控制是非常细致的，如果既想实现互联网快速迭代，又想要传统企业中丰富的过程控制，该如何做呢？京东云用了现代和传统结合的方法，即持续交付的思想加入打点服务：1. 需求和设计上，采用“模板+人工”的方式，保证事情的发生和效果。2. 编码环节，提供 JDCCheck 服务， 代码仓管理、静态代码检查、安全检查、UT、代码评审等方面。提供打点服务，该环节通过，才可以进入测试环节。

在测试环节，京东云提供 JDCCase 测试管理平台，包含 Case 库、测试计划、测试执行、测试报告等，覆盖了测试任务的各个方面，保证了测试的准入和准出。同时与 DevOps 团队合作，发布 PipeLine 服务，保证测试规范，主要保证以下效果：

• 整体流程清晰

• 子服务做成 plugin，随需调用卡点

• 用户使用成本低，无感知接入

• 通过数据度量做改进，关注过程数据，和线上效果

丁超提到：“研发自测不足、推 UT 难、缺乏敏捷教练、流程落地难、人力不足、唯快不破（关注快，忽略质量），都使得持续交付在互联网的落地更难。所以，非常提倡“通用打点” 的方式，求同存异，统一流程和平台，又给团队最大的自由。在过程和结果上进行考核。”

Netflix《混沌工程》书中说到：在接受“系统越复杂，越脆弱”的事实之后，让系统在每一次失败中获益，然后不断进化，这是混沌工程的核心思想。即通过模拟故障，来验证系统的可用性。

对于京东云来说，做混沌工程困难重重，机器规模大，地域范围广，涉及产品多，上下游依赖复杂，涉及人员多，而且担心线上出故障影响客户。但是从平台层面看问题，需要有人整体把控系统情况，保证故障的及时恢复，混沌工程又是必须要做的事情。

既然不能在线演练，京东云另辟蹊径，最终选择在隔离区重新搭建一套仿真环境。模拟多Region、多 AZ。并在 AZ1 实现了与线上的 1:1 建设。同时，为保证该环境与线上版本的一致性，把该仿真环境作为“预发环境”使用，放在发布流程中，作为上线前的系统集成环境。只有通过该预发的集成，验证变更内容对云整体无影响，才可以继续后续的灰度流程。这样，还同时解决了日常运维问题。

丁超介绍道：“第一次演练大约在 1 年半前，命名为“AZ故障”。目标是：测量 AZ1 整体断电时，云服务全部恢复的时间（即全部迁移到 AZ2 恢复可用的耗时）。再重启 AZ1，测量 AZ1、AZ2 同时恢复流量负载的耗时。之后，针对 AZ2 重复如上的步骤。

结果光 AZ1 断电的场景，就用了数个小时，这其中包括故障定位、执行预案、恢复验证等。非常直接客观地表明，在问题发现和定位、预案有效性、系统级验证方面，都亟待改进。不难得出结论：破坏性演练，是推动服务治理、架构升级的有效助力！“

第一次演练之后，京东云开始了不断的迭代改进，包括：

• 依赖治理：服务的 RING 级别梳理。将服务按照依赖顺序、部署顺序进行梳理，同一 RING 上的服务，不能有相互依赖。不同 RING 上的服务，有明确的监控项（KEY）状态呈现，有助于问题的逐层定位。

• 预案自动化：将所有预案收录到监控系统，实现自动化。触发方式定义为：检测到问题直接触发，和预警后人工确认触发。并对每个预案的生效时间进行严格的耗时检查，不断精进。

• 数据面要求对用户无损（即用户无感知），控制面可适当放宽。

• 服务治理：引入微服务架构和调用链治理。

• 触发及验证自动化：将故障的触发和云功能的验证，进行平台化。现已实现无成本的触发、秒级验证，这使破坏性演练可日常常态触发，不必大动干戈。

“时至一年半后的今天，我们已经从单场景故障恢复时间数个小时，降低到了分钟内，大部分故障场景用户无感知。微服务化、3AZ 建设等云的高可用性改造也在持续进行中。对于未来，京东云更有信心！”丁超老师对混沌工程的迭代有更强的信心。

（BoCloud博云 售前总监 刘欣雨）

开篇，刘欣雨分析了中国云市场现状提出：中国云市场规模在逐年增加，增幅领跑全球，呈现特点是越来越多用户愿意同时采用公有云和私有云这种多云管理模式。随着国内更多云服务商的参与，为云市场提供更好、更完善服务，我们相信中国的云市场规模将会更加庞大，那么多云管理的需求也将会越来越强烈，范围越来越广，这为多云管理服务商提供更大的市场机会。

博云多云平台总体建设思路围绕“七化”：管理统一化、资产精细化、业务流程化、服务自助化、运营计量化、响应自动化，管理智能化。刘欣雨主要分享了一体化运维管理方案，其中包含的多云管理方案、自动化运维和金融行业实践等内容。

关于其一体化运维管理方案，刘欣雨说：“一体化运维包含五个方面，统一纳管，统一运维，统一运营，统一服务门户和统一监控管理，实现异构资源集中纳管，统一资源按需分配；支持自动化运维，支持通过服务编排实现不同运维场景的自动化服务；提供统一服务门户，实现自助自主服务门户，让业务人员自助获取自己所需要的服务，我们的平台可以自动执行，为用户提供资源，同时提供集中监控管理，实现资源、应用和服务一站式管理”

同时刘欣雨也提到，对自动化运维场景的支持主要体现资源自动化、应用自动化、网络自动化和业务场景自动化。包括资源交付、系统安装，应用上下线、应用变更、补丁管理、网络配置管理和业务场景管理（如灾备切换和跑批业务自动化处理）。刘欣雨提到云管平台还需要开放的集成模式，要匹配多服务管理方式，提供开放接口，方便对接客户现有系统（如多厂商云平台、ITSM、CMDB、监控等），这个也是对云管平台的要求。

最后刘欣雨分享了博云在某大型股份制银行多云管理平台项目建设内容，多云管理平台帮助该股份制银行实现了资源统一化、服务标准化、运维自动化和服务智能化的 IT 管理目标，提高了资源利用率，减轻了运维人员工作量，提升了运维工作效率，保障了运维工作质量，增强了 IT 服务体验，节约了 IT 建设和运营成本。

👇点击「阅读原文」观看视频及下载讲师 PPT