UGC沙盒创意平台的基建建设之旅

来源：华为云确定性运维专刊（第四期）

      《迷你世界》的业务有其特殊性，从游戏角度看，每一个游戏是小规模（2人~30人不等）的房间制游戏。游戏之外又是一个平台，后端提供大量的业务服务支撑平台功能。因为发展速度很快，自然就不可避免的有技术历史债务，最明显的问题是基建的缺乏。体现在以下方面：
      » 没有专业的构建和发布系统，多靠人工完成。
      » 在线业务的指标告警通过埋点和通知消息来实现，缺乏系统性建设和完整告警生命周期管理。
      » 在线业务对应的微服务没有弹性支持，扩容和缩容的周期长，造成云成本的浪费。
      » 多团队协作自动化支持匮乏，多靠人工沟通完成，效率和准确性都难以保证。
      » 缺乏适配自身研发流程的工作流自动化的支持，多靠人工完成。
      结合上述业务发展过程中的遗留问题，需要制定符合适配当前情况及未来业务发展的基建建设。

      沙盒创意平台基建建设之旅

      针对平台建设成立开发团队，开发各类基建系统需要一支研发团队。团队规模由一个产品经理和三个研发组成。围绕存在的问题。先从发布系统入手，解决微服务更新手工操作的问题。因为发布就是变更，而风险的70%来源于变更，控制变更的质量，是服务高可用的重点。

      构建和发布

      以gitlab和jenkins为基础，做二次封装，规范构建流程，定制化构建界面，满足内部企业应用。

      开发系统过程中难度不在于系统开发本身，而是系统开发团队与各个业务团队的沟通协作。日常使用过程中遇到问题，通过快速响应和迭代产品功能，直到各业务团队习惯使用新发布系统，满足业务需求场景。

      监控和告警

      监控方案采用基于 Prometheus 和Grafana的开源方案，告警数据的存储采用Thanos方案，告警管理系统单独开发，进行告警的全生命周期管理，同时与通讯录打通，完成告警的交互操作。

      统一告警管理系统

      主要是汇集各种系统的告警事件，实现告警生命周期(触发、认领、升级、关闭)的集中管理，记录运维人员和开发人员的MTTA(平均恢复时间)、MTTR(平均响应时间)，提高告警处理效率。在功能上主要提供低成本、低门槛的告警源适配和告警分派策略，将不同类型的告警灵活分派给对应的运维人员和开发人员，进行告警压缩，告警聚合等降噪处理，实现告警准确和告警必达。目前平台已经打通通讯系统登录，并能够自动获取员工信息，方便进行告警通知分组和分派升级。目前支持的通知渠道包括（群，员工组，个人）、手机短信、手机语音。对于所有的微服务接入统一的API网关APISIX，实现RED指标的监控。系统上线后，存在告警噪音多、故障响应和处理速度慢两个问题，针对这两个问题，我们与华为深入交流，学习华为云混沌工程实践经验，结合“常态化运作组织”、“蓝军文化”、“FMEA分析法”等方法论，建立OnCall机制以及迷你世界业务的故障模式库。

      游戏房间扩缩容

      迷你世界的平台内产生的内容是几千万个小游戏，这些游戏的计算复杂度和对资源的需求都是不一样的。如下图：

      下图中对于房间的资源需求还是一个理论值，玩家动态的进入和离开，对于cpu和内存的消耗也是一个动态变化的过程。如何高效利用这些资源是一个重要的研究课题。我们采用不同的cgroup设置及不同的专区来解决，并逐步探索更好的解法。

      玩家的在线走势在工作日和周末都差别较大，同一天内的不同时段，变化也非常明显，高峰时段只有几小时，大部分时间是处于低负载的状态。

      我们通过使用华为云容器方案CCE来实现业务弹性扩缩容，进行游戏内业务的容器化改造，提升系统稳定性。

       FinOps

      《迷你世界》全部采用公有云资源，每年在公有云的支出是巨大的。对于云资源财务分析，存在认知不统一、成本观念薄弱、资源异常难发现等问题，解决这些问题，就是实现云资源财务管理系统，统一三方的视角，用量化的标准衡量云资源的使用，监控资源使用异常和及时预警。所以我们开发了自己的FinOps系统，进行低负载资源告警和费用支出告警：
      » 每周将业务的云资源成本报表的形式发送给业务对应的技术负责人。
      » 每天监控同比、环比的成本变化，变化幅度超过10%，则会通知到对应的技术负责人。

      工作流定制

      每个公司的工作流有其独特性，针对公司内的工作流做到自动化支持，是基建重要的目标。因为只要打通各个基建子系统并与实际工作流贯通，才可以实现更高的效率，在迷你世界，比如：
      » 构建的代码保密需求，要求构建系统作出支持。
      » 监控系统拉取现有子系统的数据，监控的接入提供HTTP API方式，最小化监控上报依赖。
      » 构建系统支持容器和K8S，为正在进行的容器化改造提供支持。
      » 构建系统支持不同的语言和环境。