开发测试管理和运行管理是DevOps平台实践中常见的两大问题。前者一般表现为开发效率低、版本质量差、环境交付慢、无统一工具设置和研发运维过程管控不足等，需要通过DevOps平台进行流程化管理。另一方面，随着云计算的发展，企业需要管理和维护的基础设施规模扩大，在混合云、多地域等各种异构网络环境下需要一套调度系统来管理和控制各类资源，解决运行管理问题。
7月2日，京东智联云和英特尔联合举办了「DevOps平台高可用架构与实践」线上公开课，来自京东智联云的云产品研发部架构师陈尧，和来自博云的售前解决方案架构师伞亚朋，分别介绍了大规模任务调度系统的架构设计与DevOps平台的流程化管理方法。
以下内容整理自两位老师的分享。
1大规模任务调度系统的架构设计——基于IM的分布式控制系统原理解析 DevOps平台为何需要任务调度系统企业上线DevOps平台，本质上是为了以较低的成本高效处理运维需求。同样，任务调度系统的初衷也是为了控制成本、提高效率。当企业的线上业务规模逐渐扩大，单纯靠增加人手来解决系统升级、维护、部署、监控等事务的成本是很难承受的，这时就轮到自动化的任务调度系统登场了。
在实践中，业务规模较大的企业开发任务调度系统时会面临很多问题：机器规模庞大，分布地域广泛，甚至跨越全球；资源种类繁多（物理机/虚拟机/容器等）；公有云/私有云环境并存；操作系统多样化；VPC/子网等网络问题等等。要设计出能够从容应对这些挑战的任务调度系统绝非易事，因此我们就需要参考行业中已有的成熟经验和实践。
向黑客学习：设计大规模任务调度系统自年熊猫烧香病*事件后，整个黑客产业链开始将重心转向了通过DDoS等攻击手段获取不法收益上。随着攻击技术不断发展，如今一次大规模的DDoS的流量可达数以Tbps的惊人水平。
DDoS的本质是黑客控制互联网上的大批机器向目标发送流量。这种技术要克服的障碍与任务调度系统有诸多相似点，例如规模巨大、网络不稳定、机器所在区域分散、系统版本众多等等。
为了解决这些问题，黑客选择的技术方案就是基于IM聊天协议的系统架构。作为控制方的黑客实际上是IM网络中的一个节点，被控制的机器等效于客户端，前者向后者发送消息，即可达成控制的目的。
在DDoS攻击活动中，黑客普遍使用的协议是IRC：
在IRC模型中，攻击者自己建一个master，再加一个控制服务器来控制僵尸网络中的节点；攻击者通过master连接到控制服务器上即可操纵僵尸节点发起攻击。需要注意的是IRC是匿名聊天协议，系统不关心连上控制服务器的是什么身份，只要能连上就可以实施控制。
但在典型的聊天应用场景中，更合适的选择是基于登录账号体系的XMPP协议：
在XMPP中，通信的各方都有自己的账号/身份，进而就可以发展出权限控制体系。如上图所示，XMPP是对等互联网络，网络中的各节点都可以互相通信。由于各节点都有自己的身份，当某个节点收到其他节点发来的要求时，就可以根据对方的身份来选择是否遵从。
正因如此，XMPP更适合作为任务调度系统的主协议。参照黑客使用的IRC网络模型，很容易得出基于XMPP模式的任务调度模型：
由于master/agent都有自己的账号/身份，就可以避免agent假冒master发送命令的攻击行为，确保系统的安全性。
另一方面，控制系统的目的并非单纯地控制机器本身，而是要对外提供服务。所以在上述模型的基础上还需要一个api-server，用来包装业务需求，将其变为可执行的任务通过master分发给agent。加入api-server后模型也比较简单：
系统对外开放的是上图中api-server账号。系统接收一个新任务（例如执行某个脚本）时，api-server账号将任务以消息的形式发送给master，之后master通过xmppserver再将任务分发给各个agent。这里的权限设计是，agent只听命于master，而master只听命于api-server。这样就得出了整个调度系统的业务逻辑模型。
上述业务模型是理论化，较为简单的模型。在现实应用中，任务调度系统使用的模型会复杂许多。
如前所述，现实中的大规模任务调度系统是需要满足跨地域和复杂网络环境的需求的。为了解决跨地域问题，需要搭建一个XMPP的server网络，其中每一个地域都有一个独立的分发网络，该地域的agent只连接到本地域的XMPPserver，以此类推。
更为复杂的是master的设计。对于小公司而言，只需一个master可能就足以管理所有机器，那么系统只需单个master作为调度器即可。但对于京东这样大规模的企业来说，需要多个master来分担庞大的任务负载，就需要将它们放在多个网络下面。
存在多个master时就需要考虑是否拆分api-server。京东的选择是不做拆分，而api-server承接的业务逻辑最终形成一个Redis数据库作为一个中间件。负责不同地域的master启动后从中间件获取数据并分发任务，任务完成后也保存在中间件内。当外部用户查询api-server，想要获得当前的任务状态时，api-server会直接查询中间件，而非某个master。
这个模型的最大优点是高可用性，某个节点出问题后并不影响整个网络继续运行。例如某个master发生故障后，当它重启后还能从中间件继续获取任务并分发下去，以此类推。
基于XMPP的这套系统模型解决了以下几个问题：1.适应各类网络模型。
使用UUID作为资源标识，不依赖机器名/IP，可以应对复杂环境下的资源冲突情况；
公有云/私有云、VPC、子网均可用，不同的网络只需连接到固定的server上就能接入整个XMPP网络。
网络传输容忍度高，不同地域的子网不需要实时在线或低延迟。
2.适配不同的硬件/系统环境。XMPP库有大量开源实现，因而可以轻松解决各种环境的兼容性需求。
3.系统性能高。
网络中的调度和分发模块拆分，内部是多节点组合，因而性能表现优异。
XMPP本身性能强劲，单个集群可以应付百万客户端规模，实现秒级调度、执行。
总体而言，参考IM的架构设计，基于XMPP就可以打造出高性能、高可用性、可以适应复杂环境变量的大规模任务调度系统。
2从开发到测试，如何通过DevOps平台进行流程化管理DevOps可以被理解是一个体系，其中的过程、方法和系统都是具体的表现形式。它更像是一把钥匙，打开了一扇大门，赋予团队无穷的想象。在本次分享中，伞亚朋老师介绍了企业应用DevOps平台进行流程化管理过程中需要