【私有化质量实践2】最“年轻”的云原生数据服务

春节快乐，干货来袭。QAPM（移动监控）在TMF中交付已经走过两个年头，两年的时间，我们也在不断成长。下面我们就来说说，在私有化交付的四个环节中，我们踩过的坑与解决方案。前言

随着云架构的不断普及，“未来的软件一定生长于云上”的理念被越来越多的人所接受。云提供了一种面向企业应用实现按需进行资源分配的模型，以一种全新的、高效的方式来部署应用。企业纷纷开始云化转型，希望将传统应用迁移到云端。基于云化架构的特点，定义一条能够让应用最大程度利用云的能力、发挥云的价值的最佳路径成为行业迫切的需求，“云原生”应运而生。云原生可以有效地缩短应用交付的周期，让需求更快地变成代码，代码更快地变成线上的应用，最终为用户服务，通过缩短“time to market”带来切实的业务价值。

而我们团队早在2016年后台应用就开始吃云原生容器化的硬壳螃蟹；大数据也在2018年实施容器化（Spark on k8s），并且还开源出来了，这些尝试早于很多团队。作为技术人，我们做这些尝试当然不仅仅是为了追求新技术，而是判断云原生势在必行，并且希望TKE（K8S）作为统一的底座，为私有化面对的各种兼容性问题做一层防护层。基于TKE，让我们的兼容性风险更为可控。

但是说实话，当时我们这个选择也让“年轻”的云原生数据服务的稳定性倍受挑战，QAPM在参与私有化项目TMF进行部署时，初期面临着严重的人力紧张的难题，在经过大半年的实践进行方案调整后，成功简化了部署流程，统一了公有/私有云的架构体系，节省了人力物力成本，达成了可观的优化成果。下面我们就来说说”年轻“的云原生数据服务在私有化交付上遇到的困难和我们的解决方案。

我们的实践

一般来说私有化部署有四个环节，它们分别是 构建制品-＞部署-＞ 验证-＞运维，我们一起来看一下在这四个环节QAPM是怎么做的呢。

１）制品产出

自动化一切，我们团队人非常少，告诉别人说我们做APM产品，仅投入了10个人不到，大家都用惊奇的眼光看着我们。别的不说，大家确实是拼着老命来做这个产品，还存活，我觉得是因为自动化一切的理念也贯穿始终。现在，QAPM能实现自动化镜像管理，自动拉取公有云线上稳定镜像，自动化推送到私有云环境的仓库中。也就是说，我们的镜像构建按照 开始-准备构建-构建安装包和文档-打包镜像-上传物料到cos-同步到TMF管理-发布-结束构建有序进行。你没有看错，我们连文档都是构建出来的，pydoc+简单的配置代码，再配合数据库文档生成工具tbls，我们可以自动化输出公有云与私有云的完整的文档.(附件也共享我们的一个小例子"docx自动化替换案例.zip"）

压缩镜像镜像大小出了决定构建快慢，还决定了在那个封闭的私有化环境下传镜像到生产环境的耗时。之前去交银部署，足足要耗费一天一夜上传镜像。因此，在镜像包的产出上，我们采用分阶段打包镜像，即使在增加ceph和kudu的情况下,我们的镜像包的大小依旧从32G减少到25G,使得传输和部署镜像的速度更快。

交付完整的文档，在文档的产出上，我们私有云文档共有33篇，文档版本迭代3次，培训3+次，按照内容的区别,文档可分为SDK、TBDS、产品、产品报告、运维、部署、验收等内容。（满满的干货，地址如下：(https://git.code.oa.com/tencent_cloud_mobile_tools/sop_doc/tree/master/%25E7%25A7%2581%25E6%259C%2589%25E4%25BA%2591)。

２）部署

软件运行在 SaaS 环境和私有化部署环境是截然不同的，SaaS 环境包含了所有租户的数据，SaaS 平台需要提供一种能力来隔离不同租户的数据。而私有化部署仅仅考虑自己就行了。这种差异导致系统设计之初就应该提早的考虑这些问题，同时保证运行在平台上的应用在开发的时候尽量关注业务逻辑并忽略这些差异。

传统部署方式操作流程复杂，费时费力，一到部署时开发同学们总是大敌将至般紧张，记得QAPM刚加入金融云服务产业互联网项目（TMF）进行私有化部署时，每次交付都需要开发同学去到银行总部现场部署，由于银行的安全隔离，镜像都不能直接部署，而是需要通过跳板机上传。记得我们在交通银行部署的时候，通常是早上的飞机过去，第二天才开始部署，那是因为光是传镜像包就要传一天一夜。面对着较落后的银行设备环境及不定因素影响，优化部署成为开发们迫切需要完成的内容。

基于云原生helm，构建一键部署

而我们的解决方案，就是通过一键部署，减少部署步骤，节省时间与人力资源，具体步骤如下:

以前部署需要21步，现在只需2步，即可实现私有云的一键部署，记得当时我们的产品落地到 TMF 之后，TMF 整体节约了 30% 的计算资源，而我们负责的产品在腾讯云和私有部署均为云原生架构，减少割裂，可以说是真正的 “双赢”。

３）验证

QAPM部署完成后的验证工作包括大数据指标类的验收、性能个例的验收以及报表看板的验收。整个流程按照

脚本的配置和调试->运行脚本->触发指标计算->页面检查（包括Android功能巡查、iOS功能巡查）->小程序功能巡查->移动分析->监控页面检查等步骤进行。

在验收过程中，我们需要在每一个步骤填写验收测试的CheckList，最后再填写项目测试验收报告。在一系列有序的流程过后，我们便完成了对QAPM部署的快速验证。可以看到，验收测试CheckList的验收点能基本覆盖我们部署的方方面面，确保部署验证的工作质量。

checklist1.PNG

未来规划，私有化验证这个部分，虽然我们有jmeter的自动化接口测试，但是端到端依旧需要人工验证。实在是不符合一切自动化的理念，未来我们会串联客户端自动化与后台自动化，打造一体化全自动的验证体系，减轻我们区技同学的工作量。

４）运维

公有云与私有云的运维是巨大的，任务越繁杂，大半年来团队没有休整喘息的机会，人力紧张到令人窒息。破局势在必行。

混沌工程，前置发现运维陷阱

使用chaosmesh，我们对于我们的测试环节进行充分的故障模拟和问题修复。尽力做到滴水不漏。

可观察，运维力持续提升

整体的可观察，我们分为三部分，分别是资源、组件、业务。基于TKE的导出，我们可以获取pod的资源使用。针对Kafka、web、hdfs等特定组件，借助普罗米修斯也配置了监控。最后业务上，我们从功能，产品，版本三个维度来观察数据处理的链路是否有问题。

写在最后

在云原生技术不断成熟和普及、国内开源文化和社区逐渐兴起、去IOE和自主可控的时代背景下，QAPM作为“年轻”的云原生数据服务平台，也在不断进行探索，构建发现、定位、解决、验证的闭环，助力客户高效率突破 App 的性能瓶颈，打造顺畅体验的产品口碑。