基于JWS的游戏运维服务化平台实现

经过一个多月的多方沟通和协调，这个平台（JAE，JWS App Engine）终于引来了多方合作的机会，本周也正是立项启动，进入开发者模式。虽然Q2还剩下短短一个月，但是开发团队还是制定了比较高的里程碑，相信这次开发、测试、运维联合的投入一定会有回报。

找到每个角色的诉求其实是这个项目能够在多方之间快速达成共识的一个直接原因。在平台沟通过程中，就设定了很多共性的目标。比如说提高测试每天版本数，要知道，当前依赖复杂的部署文档模式，一天只能有限支撑几个版本的部署和发布；进一步简化开发人员在提交版本时的文档和流程，降低工作量；运维能够更敏捷的应对变更，从之前每天6人都在参与多项目的发布，到未来平台化之后，可以一人应付整个中心的发布。简单的来说，我们用持续集成的观点来解决发布、部署的问题。另外一个不得不赞大家的合作精神，在讨论问题的过程中，大家都看着目标给整个中心带来的收益和价值，没有出现之前工作中相互推脱，非常棒，真正的DevOps文化。

从运维的角度来说，JAE平台体现的更多的是运维驱动因素。

1、业务碎片化导致运维成本高。游戏业务的机器数量不多，其次业务的个性化无法有效工作转移，这一点导致了必须专人专岗，没法有效的替代工作。

2、缺少对环境、项目、应用环境的管理。缺少这些基础信息的管理，就导致工作转移的代价非常高，很多工作没法可视化。

3、运维侧的数据积累太少。在当前还没有一个平台积累了面向服务的数据供日常运维工作参考，此时我们希望在一个一体化的平台中，承载这部分的数据，从而更好的驱动运维工作优化。

4、持续集成!。当前我们的部署模式和持续集成理念背道而驰，但我们有这么好的标准化基础，完全可以做到真正的持续集成部署。

5、业务架构的管理。缺少一个对业务架构的动态管理能力，用文档的方式记录架构一直是我个人不能接受的，而我们的配置标准化以后，业务之间的访问架构可以立等可现，只是缺少一个数据展现平台而已。

在之前的一篇文章中介绍过JWS框架，可以说这个开发应用框架让我在运维侧有了很多想象空间，比如说配置统一标准、数据库在框架层统一实现高可用、cache层统一接管等等。有了这些标准基础之后，在之上搭建自己的工具平台也就非常简单了。标准化非常重要！

JAE平台建设体现在四个方面（此处不一一解释），如下图所示：

其实对这个平台个人还有很多期望和想法需要沉淀进去，建设一个真正的运维服务化平台。在以上四个象限之外，我更希望能看到他未来和基础服务平台的整合能力，比如说云DB，云mecache、名字服务等等。在此之上，进一步构建自己的业务游戏私有云能力，实现真正的统一服务调度设想。

另外希望通过这个平台来减少更多大家的低成本付出，让大家未来有机会投入到真正的高运维价值活动中；最关键还是希望大家看看真正的运维服务化如何去体现，运维的服务如何产品化等等。

这样说完，小组的人都问我，未来我们做什么？要是你，你会怎么回答？