作者介绍：滕昭永，DevOps思想践行者，十年CI/CD、DevOps、容器云、基础架构和运维安全领域工作经验，曾带领团队完成多家公司企业级DevOps从0到1的落地，在云原生基础设施等领域具有丰富的实践能力，致力于混合云架构的最优化思路探索。现任职于北京汇通天下（G7）运维安全总监。作为一家智慧物联网公司，G7以IoT和大数据为核心技术支撑着公司的业务，帮助传统货运行业实现数字化转型。其中IoT和大数据服务是使用服务器资源要求最高的技术领域之二，加之服务已全面上云，各业务系统都是基于云原生的Spring Cloud微服务架构，如何精细化管控IT服务器成本成为公司比较关心的事件之一，也是对IT基础设施团队带来的挑战。
在进入主题前，先来了解一下公司的系统架构情况。
作为一家物联网公司，G7 大数据是以180万重卡运行数据为基础的车联网数据分析平台，日跟踪重卡里程超过1.3亿公里，每日上传数据超过7TB。基础数据类型包括卡车运行轨迹数据（定位、里程、时速、停留时长等等）、油耗数据、驾驶员风险数据等。
IoT方面，平台连接的总设备数达230万，设备种类224种。每秒处理设备上报数据2万条以上，每日产生的事件达7千万条。每天处理图片文件1000万个以上，视频文件150万以上。基于IoT能力的开放平台，接入客户数近4000家，每日调用量35000万次以上，每日消息推送近1.9亿条。
业务系统已全面上云，为中小客户提供SaaS化服务，为中大型客户提供独立部署和开放平台能力，服务范围几乎覆盖道路运输领域的方方面面。
而在基础架构层面，不同环境、不同业务分布在不同的云上，服务器规模3000+，K8S集群三十多个，服务容器化率接近80%，日均上线20+次。
(基于保密性原则， 编辑图一张)
01
—
如何管理众多云资源以及云成本
从上图可以看到，G7的基础架构是公有云+私有云，这种多云架构下的服务器资源管理，对运维团队来说是一种挑战。
于是，我们开发CDMB，通过API对接将多云之间的资源统一到CMDB进行管理，大概的架构是下面这样的。
通过公有云的事件能力，实时监听云资源的变更情况，然后将资源同步到CMDB进行统一管理，同时每日定时调用各云的API接口，完成资源的增量同步，确保其他无事件的资源也能同步到CMDB，实现资源统一管理。
云资源实现了统一管理，云成本自然也是相同的办法，每日同步云资源的同时将资源对应的订单同步下来，每个资源每个月花了多少钱一目了然。
与此同时，云厂商每个月初确定上个月的账单，所以我们每个月初也会同步一次云上的账单，确保云商出的账单和CMDB中的账单一致，也方便我们更好的进行对账。
02
—
如何核算云成本并分摊到业务上
站在企业或者管理者的角度，我们往往不是单看某一台服务器的成本，而是看某个月或者某年总共花了多少云成本，以及总的成本分别是哪些业务线花了，对应业务的投入和产出是否合理，也就是所谓的ROI。
基于这个考量，我们在DevOps的基础上设计了一套成本分摊模型，首先说一下DevOps的顶层设计框架。
首先是以业务为驱动的产研运闭环模型。
其次是以单一可信源原则拉通信息孤岛。
这里的单一可信源，可不仅仅是所谓的代码源或者制品包。任何研发输出物都应该做到单一可信源，同时做到每个可信源之间的关系串联，每个业务线下有多少产品，每个产品下有多少应用，每个应用下有多少环境，每个环境下有多少集群，每个集群下有多少资源，做到自下而上归集，至上而下管理。
最后是以应用为中心的平台设计
比如我们将应用部署的名称贯穿整个研发周期，并且做到全公司唯一，确保信息是唯一可信的。在任何地方都可以通过应用名称查询到唯一的信息。
曾遇到过这样一个小插曲，在没做单一可信源和应用为中心前，有一个业务团队部署了一个名叫truck的服务，另外一个业务团队也部署了一个truck的服务，两个业务团队之间没有交集，但因为服务都是运维团队维护，结果相互搞混了，差点没搞出事故。
有了上面的顶层设计框架，那么我们就能很好的将每个云服务资源绑定到对应的可信源上，从而实现层层关系串联，信息孤岛也由此被打通。
有了资源归属关系管理，那么我们的资源成本就可以逐层向上汇聚，得到业务线成本，同时也可以基于资源的使用率，逐层向上得到业务线的资源使用率（业务线资源使用率如何计算，我们后面介绍）。
成本分摊出来后，我们将分摊成本一键同步到财务系统，用于财务部门向各业务线结算的依据，实现系统线上化对接，大大降低了财务人员对分摊成本的计算和处理工作。
细心的朋友可能看出来了，上图中各成本单元的成本构成，有独享成本和分摊成本，那么他们之间是什么关系呢？
03
—
如何合理的分摊云成本
G7是一个平台型公司，组织架构上，运维安全团队负责所有业务的系统稳定性保障，IoT团队负责公司的所有IoT设备接入和处理，PaaS团队负责公司所有的PaaS能力提供，大数据团队服务所有业务的大数据处理。
所以运维安全团队、IoT团队、PaaS团队、大数据团队，他们是属于基础平台部门，架构有点像这样：
每个业务线自己研发的产品需要服务器资源，这类服务器资源所消耗的成本我们归属于独享成本。
除了独享成本以外，基础平台部门也要消耗服务器资源，而这部分资源也是为上层的业务服务的，所以我们将基础平台部门所消耗的服务器成本，按各业务线使用平台资源的情况进行分摊，于是有了分摊成本。
分摊成本的计算规则比较复杂，会跟进每个类型的服务来进行分摊，比如运维成本会跟进每个业务线独享成本占总成本的比例进行分摊，而IoT成本会根据接口调用占比和数据推送占比进行分摊，大数据成本会根据调度任务执行次数占比和数据存储量占比进行分摊，短信成本会根据发送短信条数占比进行分摊。
总之，都是先计算各业务线所使用的平台资源占比，然后使用占比乘以分摊单元的待分摊金额。
04
—
如何有效管控云服务成本
成本分摊到不同业务线了，但各业务线资源使用是否合理，是否存在浪费的情况，我们如何管控呢？
首先，因为资源都是绑定在对应的应用上的，而应用都是归属产品的，产品都是归属业务，所以每一个资源我们都知道是什么业务在使用，一旦发现没有绑定业务的资源并且没有人认领，那么它很可能是一个游离态资源，是可以进行资源回收的。
其次，每台服务器、数据库等资源，都有资源使用率监控，我们根据监控指标可以进行分析，找出使用率较低的资源，推动业务方进行降配，所以我们有了下面这个指标：
策略是首先取单台服务器近30天的资源使用率90线值，然后汇总一个应用下所有资源的使用率再取90线值，再往上取一个产品下所有应用的使用率90线值，直到取到业务线的资源使用率90线值，以此评估总体资源使用合理性。
最后，我们根据业务线看板，从多个维度分析，比如总成本趋势逐月上涨是为什么？上线应用频率很低甚至很久没有上线过的应用是否可以下线？
通过不同维度，不同策略，确保资源使用在合理范围。
往期推荐
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。
