降本30%+增效40%，这样落地FinOps省钱又省力！

一、FinOps平台初期问题

新东方成立至今已有30年，但基于IT和运维平台的基础设施建设，近些年才逐渐形成规模。

1.面临困境

图片

• 烟囱效应：早期发展过程中，各个业务平台都有专门的研发方向，比如服务器部门专攻服务研发，网络部门专攻网络研发，安全部门专攻安全研发。这种“各个团队深挖自己擅长领域”的研发模式，导致内部系统烟囱林立，难以进行数据互联互通。
• 数据孤岛：新业务新市场的拓展过程中各内部系统没法直接复用和迭代，产生的新数据无法与原有的数据互通，加剧了数据孤岛的问题。
• 组织熵增：各个平台功能单一化，平台与平台之间的协调配合、数据交互异常混乱，随着企业核心业务增长，却带来了效率低下的问题。

基于以上三方面问题，产生了建立统一化对外平台的需求。

2.初期构想

问题1：哪些独立功能需要集成？

下图展示了平台初期的7项业务重点。

图片

• 资源申请：这是开发平台时设想的新功能，研发人员通过平台自助申请资源，同时资源支持自动纳管。
• 信息检索：当同业务线的人员检索服务器、PaaS类内容等信息，可获得精确数据。
• 流程操作：规划流程模式，用于资源申请、业务流程创建。
• 业务上线：即大家熟知的CI/CD。
• 成本控制：将在后文详述。
• 数据安全
• 高效稳定

问题2：集成后如何方便地进行资源成本分摊？

图片

根据上述概念，如何针对云教室、东方甄选、小课堂等应用项目，进行资源的成本分摊呢？

第一，申请流程。目前已经搭建起平台，就通过云主机、云盘或数据库资源等进行申请。流程创建的同时，这些资源挂载到对应的服务树上，相当于在数据库层面进行关联。

第二，通过平台分摊资源成本。

平台搭建前已有的数据，如何转移到平台呢？

• 资源获取：物理层面，通过数据纳管脚本，将物理层的数据中心、机架、服务器的物理机，以及硬件配置纳管；混合云层面，阿里云、腾讯云和微软云等公有云，以及VMware的VSphere和OpenStack等私有云的数据，通过API进行同步或官方SDK拉取。
• 资源位置：物理机是IDC，VSphere属于私有云，微软、阿里、腾讯属于公有云。
• 资源类型：目前支持通过平台（阿里ECS和RDS，腾讯CVM和CDB等），申请云主机、数据库、对象存储等资源类型。

图片

Redis、ES、Kafka、RocketMQ等中间件的资源，用于实现缓存或服务队列等辅助功能。

3.解决办法——服务树

如何将这些资源分配到各个业务线呢？这涉及到服务树的概念（前文介绍业务的成本分摊时亦有提及）。服务树与人力资源树不同，人力资源树更关注公司的部门关系和组织架构，而服务树更关注企业的业务应用。

经过长时间的整理工作，我们形成了新东方集团的服务树，共分为5个层级。

图片

• 第一级-集团：即新东方集团，它是所有业务的根节点；
• 第二级-业务线：包含地方校、机构和子公司等；
• 第三级-项目集：一类高度关联项目的集合；
• 第四级-项目：各类业务研发的立项；
• 第五级-应用：包含开发模块、 App组件、各种微服务等内容，这是服务树的最小粒度。

4.通过服务树关联集成业务功能

图片

根据上述5个层级，可以通过服务树数据，关联具体的应用功能，并为用户角色分配服务树节点。同时，服务树节点对应服务API，通过赋予角色不同的action权限，达成集中授权的功能。这是服务树结合应用的案例之一。

二、数据和安全建设

1.案例：实时计算平台

1）大数据实时计算架构

图片

第一个案例是数据平台中比较重点的项目——实时计算平台。实时计算，与在离线数据分析的概念相似。

如上图所示，左边是RDBMS和分布式数据库，基于CDC进行数据采集，中间是类似于Kafka的数据通道，右边是一个存算分离的架构、一个实时数仓，以及在离线计算的任务和存储。最终，数据到达数据分析平台，用于BI统计和计算。

我们负责研发实时计算平台的中间部分，其功能包括SQL任务和JAR包任务。

2）上下游通过流程串联

图片

我们希望业务用户进入平台之后，能够以一种简单的方式，发现、实时Job计算，故目前提供2种选择：

• 第一种方式：将Java程序打包后，用提交Jar包任务来提供计算服务。由于大数据和数分Java工程师比较多，他们会写基于Flink的Job；
• 第二种方式：直接在平台的在线Web IDE中，用SQL语句写DDL或DML语句，生成Source表或Sink表功能，用于处理实时计算的过程数据。这是整体的上下游关联流程架构，任务提交前通常由 DBA来审核。

3）数据处理能力升级-实时数据研发平台

下图呈现了实时计算平台中，任务SQL语句生成的表结构、Job实时任务的操作（可以进行Job暂停、重启、拉起、停止等操作，以及类似的模板功能等）、Source表和Sink表结构等。

图片

开发实时计算平台的预想目标是，建立一个自动化的研发的数据模型，集成原有割裂的实时计算存储和计算，通过服务树与业务库表关联，提升整体研发效率。

2.案例：安全项目驱动开发

第二个案例是安全类项目，我们曾参与6项安全类研发项目。

图片

• 红蓝对抗：并非内部人员组成红军蓝军，而是邀请外部安全公司，进行安全打击测试。
• 渗透测试：基于单个项目，针对某些平台进行安全类检测，用于输出和修复未处理的漏洞、事件和风险。
• 敏感数据检测：针对可能涉及到敏感数据的项目进行检测，比如用户真实姓名、身份证号、电话号码等等，利用定期扫描任务，通过敏感数据识别模板进行识别，来协调开发人员对敏感数据进行加密存储和传输。
• 安全中心：内部提供一些功能，比如说像安全管理、内部政策法规类的平台。

接下来我将重点说明后两个项目：安全 APP合规平台、内部CA认证。

1）案例：安全APP合规平台

图片

APP合规检测，是针对新东方自研APP，从管理和技术两方面，进行安全合规检测，以减少风险。我们对这些APP进行安全左移的第三方检测，并评分。如果未达到安全评分，比如检测到安全风险或漏洞，安全团队会在平台上提交APP漏洞，提示业务线安全加固，否则不能上架。

图片

安全合规检测项目对APP业务非常重要。针对东方甄选、托福等重点项目，我们会进行APP合规检测，并列出高危风险、低危风险等详细信息。

2）案例：CA认证中心

为什么要构建内部的CA中心？

平台具有在线终端功能，在浏览器页面通过调用web socket自动登录到服务器黑屏操作上（类似xshell和crt），自动登录需要进行登录认证。

图片

初期为了方便，使用了第一种方案：传统的密码认证，但由于密码非常容易拷贝和背诵，风险系数非常高。

所以改用第二种方案：公私钥的密钥对认证。它解决了密码易于拷贝和背诵的问题（公私钥包括好几百个字节，数据串很长，一般人难以背诵），但是这个方案忽略了一个问题——公私钥依然是可以传递的。

后来我们调研了第三种方案：CA认证，搭建了内部CA认证中心，实现了平台端的三方认证，即平台-用户-CA凭证。用户操作具体页面时，需要上传CA凭证（内含针对用户的算法哈希值）。

CA认证有效且通过用户hash验证后，下一步需判断CA凭证是否超期、与服务端凭证是否相符等，如有一项不满足，则判定为非法请求，拒绝后续操作。

图片

上图为我们开发的CA认证流程图。调研 CA认证时，曾考虑过采购商业版本的，但很多安全公司尚未具备CA认证的完整流程，所以只能自行搭建。

CA认证的详细流程：

• 第一步：用户登录之后，操作CA关联的应用时，判断用户凭证是否处于认证有效期内，有效期内（例如7天）则不用重复认证，否则需要重新认证。这种逻辑对关联的功能模块非常友好，用户不必反复登录认证，体验类似SSO。
• 第二步：判断服务端是否真实存在认证证书，如认证证书不存在，用户需申请并重新下载。
• 第三步：判断证书在服务端是否已经被吊销，如被吊销或删除，需重新认证。

图片

完成以上三步，用户即通过认证，可以进行下一步工作。由此可以理解为，我们将CA认证功能集成于一个请求的中间件。

三、成本中心一体化

1.FinOps的概念和本质

图片

FinOps基金会对FinOps的定义是，让研发、财务、业务等各个团队共同配合，从数据和资源层面，放大业务利用价值，实现降本增效。

图片

上图是我们目前的FinOps框架图，上面部分包括多云账单管理、预算管理、成本优化分析，报警等迭代功能；中间部分是云单元管理、云CMDB、权限管理等平台；下面部分是使用的混合公有云的基础设施（阿里、腾讯、微软）。

2.FinOps一体化平台组成

图片

DevOps平台和FinOps平台，通过服务树（节点）进行连接，由此判断服务树内存在哪些应用、资源，这些资源关联哪些账单，甚至细分到具体服务器的粒度层面。

3.FinOps云成本优化业务组成

图片

以上是业务图，上方是云课堂、东方甄选类似的业务应用，我们为其提供报表和业务账单；中间部分是成本中心和运维门户；下方是依赖，使用公有云官方的API，私有云就是各个厂商（比如VMware、OpenStack等）提供的SDK组件。

4.案例

1）案例：FinOps月账单

图片

上图是项目月度账单报表（已脱敏），包括现金账单和摊销账单。

• 现金账单：企业单位实际支出费用，财务与商务比较关心这部分内容。
• 摊销账单：多租户使用、不方便直接生成账单的部分，比如MySQL、Redis或存储，就按照主机使用率百分比，将使用支出分散到各个业务线上，以便业务通过使用率和摊销情况进行对账。

2）案例：阿里云RDS报表

图片

如上图所示，这份阿里云RDS报表（通过阿里公有云API获取）包含几个重要指标，比如涉及服务器的高开支项目集中于哪些部分，哪些是实例，实例规格配置如何（比如2C4G、4C8G等），实例规格花销如何，花销分摊对应项目的具体数目。

3）案例：移课通报表账单

图片

由于涉及课程的营销推广，所以新东方具有客服业务，分为短信和会话两种套餐。

新东方具有多个子公司和地方校，各个学校的通信费用、使用个数和开销构成了其套餐费用。我们重点关注移课通账单开销，使用逐步优化的FinOps分账算法，形成各地方校和子公司的账单优化闭环。

5.FinOps成本优化闭环

图片

账单闭环优化的逻辑如上图。

• 付费合理性预测：基于IT账单，判断目前消费环节的有效性、合理性，是否符合预期，是否存在超预算的必要支出。
• 降本节约性建议：基于合理性预测，结合算法检查付费方式（RDS 按月/按量、移课通 套餐一/套餐二）在不影响业务的前提下，选择更有助于优化成本的付费方式。
• 成本结果集观测：基于降本节约性建议，优化付费方式，生成业务月账单现金成本的结果集，实现成本支出的可观测性，作为预算参考。

具备预算参考后，需要基于生成的结果集账单，再次判断合理性预算，整体形成云成本优化的闭环。

1）案例：业务线月度费用报表-费用预算和最终账单参考

图片

上图是费用预算和最终账单的参考（已脱敏），内容包含具体日期、负责人部分花销、各项目和主机的分摊费用。云成本方面，内容则包括涉及的公有云类型，比如阿里 ECS、RDS、CDN的详细账单，以及服务器运行时长等。

2）案例：云实例规格配置管理

图片

因为不同云主机的规格配置有多个版本，一条配置可能包含几十条规格名称。用户在平台申请云主机或RDS数据库时，可能面对上千条规格配置，导致选择困难。

基于以上问题，我们设计了云实例规格的收敛方案，通过资源实例配置管理，进行自定义规格列表，同时支持配置优先级。处理人为错选或配置冗余的情况，优先提供更具性价比、目前线上应用更多的实例配置。

由此，提供给用户几个不同配置的定制化选项，并且使用人性化规格名称，用户可以根据需求选择，既节约时间，又避免了晦涩难懂的规格名称混淆用户选择。

3）案例：闲置率报表及成本黑名单

图片

2021年颁布的双减政策对教育业务打击很大，各大公司均收紧业务、裁员降本。以往未曾注意的资源浪费问题，如今越发凸显，加之裁撤业务和项目，作为运维重要开销的云成本问题较为棘手。

所以，我们利用长期运行但资源利用率闲置的主机，额外采集系统监控数据，列出由高到低排名前五的业务线黑名单，向每条业务线的负责人发送邮件报表，敦促业务负责人尽快处理。处理方式推荐以下三种：

• 退租：即机器无人使用、业务无人接手；
• 混布：CPU密集但内存消耗少的服务，可以与内存密集但CPU消耗少的服务进行混布，提高资源利用率；
• 迁移：将闲置资源转移给其他业务，变更机器所属服务树，盘活闲置资源。关于闲置率，并非关注节约多少成本，而是关注每种资源都实现其应用价值。

6.优化步骤与成本考核

图片

前文提到，根据业务成本分摊结果，统计并处理闲置率主机，优化云资源规格的优先级、包年或流量套餐选择。最终，结合业务线成本输出，形成一种考核模式，目的是提高利用率，确保各个业务线ROI处于较高的水平。

1）案例：年度IT各类费用趋势

图片

通过FinOps优化成本后，整体开销的趋势走向如上图（已脱敏）。相比以往总体成本最高的时期，当前成本下降近一半，这是FinOps平台最显著的效果。

四、经验沉淀

1.降本增效的经验：聚焦和成本控制

• 业务板块聚焦：和同行业公司一样，修剪业务线，甚至大比例裁员。砍掉以前的边缘业务，将更多的精力、资源、开支投入核心的业务板块，和新兴的、着力发展的业务板块，比如东方甄选。
• 精简申请流程：精简过往流程中的邮件往来、人为复杂操作或冗余选项等配置，提高工单流转效率。
• 上云及容器化：与传统的IDC服务器相比，上云的优势是无需关心物理服务器的采购环节、机架费用、电力费用、带宽费用、异地多活架构方案等，且能够提供更好的伸缩性，支持动态扩容、多副本和快照，具有自动灾难恢复、故障转移，避免供应商绑定等优势，所以整体来说是有降本和容灾的好处。
• 闲置资源回收
• 超额资源审核：用户申请资源时，无论是云主机、PaaS资源，还是对象存储类资源，在超过一定金额的话，会交由云管理员进行审核，这对于大环境非常不好情况下，是一个非常重要的成本卡口。

优化的最终结果是，集团整体降本百分比达30%，增效40%，实现业务在成本降低的情况下加速投产。

2.技术提效思维

• 复制牛人经验，提高作战能力：避免重复造轮子；
• 核心模块抽象，高内聚低耦合：提高代码抽象度，实现各研发模块能力通用；
• 架构微服务化，增加通用接口：使用网关或API接口封装，实现通用网关的接口路由；
• 文档定期沉淀，鼓励知识共享：在企业内部，通过内部的文档库进行知识沉淀；在企业外部，通过公众号和Gdevops等大会进行技术分享和沟通讨论。

3.运维业务研发精进过程

• 目标定义：沟通需求目标、业务重点，了解现有资源，熟悉现有运维流程，构建基本的研发架构（或体系）思路。
• 需求分析：明确需求方向，确认优先级和需求难度，规划实施方针。
• 目标拆解：基于确定的方向，按照难度和优先级，拆解细化需求，安排并推进团队的下一步开发工作。
• 阶段实现：根据需求优先级和产品目标，为用户提供阶段性产出，检验产品与用户的目标达成率。

Q&A

Q1：新东方战略主营业务条线推进降本增效，但IT费用属于IT基础资源，业务其实无感知，请问IT和业务之间如何配合，促进降本增效？

A1：服务树里包括项目、应用等维度，每个项目都具备对应的研发负责人、项目负责人，项目与服务树相关联，服务树同时与各项IT资源（比如云主机、PaaS等）关联，所产生的费用将联动到FinOps成本中心。由此，建立起IT成本与人的联系。

我们可以将IT资源涉及到的各种成本，通过邮件发送给各个业务线的负责人，形成了降本增效的提醒环节。

作者介绍

钟仕骏，首师大毕业，现就职于新东方教育，曾就职于搜狐、快手。搜狐大厦资深老烟民，曾在搜狗、搜狐视频移动端NO工作过，负责运维及后台数据研发。快手第一位SRE，曾负责快手「所有」运维基础化建设，规划并参与了2020年春晚红包项目。现任新东方教育运维研发高级经理，负责企业基础架构标准化体系研究、自动化平台研发等。

本文标题：降本30%+增效40%，这样落地FinOps省钱又省力！
URL标题：http://www.shufengxianlan.com/qtweb/news29/338929.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联