gitlab 高可用

2022年

OKR回顾

整体聚焦三部分:

OKR	成果
Gitlab高可用与稳定性保障：维持可用性99.95%以上，不出现T1+/P2+故障，不出现影响时间在15分钟以上的单业务访问可用性故障	未出现评级故障。几次小问题（物理机故障、kgw影响），自身监控及时发现，并分钟级快速自愈恢复，影响时间和范围较小。
Gitlab自身能力建设与性能提升，版本升级，提升推拉代码等性能	Git关键操作**整体性能提升约30%版本升级时间和人力成本降低60%**对用户和平台研发交付效率的影响降低
KDev&Keep等研发效能工具和业务线研发需求能力支持，提升研发交付效率。	KDev&Keep等研发工具交付流程优化和效率提升支持游戏业务价值千万级高保密代码资产保护

工作总结

1.Gitlab能力建设与提升

1.1 行业怎么做（望远镜）

阿里、腾讯、字节、百度、京东	滴滴	Gitlab社区	快手
全自研代码托管平台（多为小团队维护、大的更新频率较低）	基于早期Gitlab改造，完全脱离社区（2~3人小团队维护、主要支持上层研发工具，无大的更新）	开源、版本不断更新迭代（60多个国家、3000+贡献者维护每月一个小版本，每年一个大版本）	两面开花跟随社区版本升级（2~3次/年），同时因地制宜的自研支持

1.2 做什么( 显微镜)

诉求或痛点？

普通研发视角	研发工具平台视角	安全视角	我的视角
代码库上传下载速度快、性能好，尤其是移动端主站等大仓库代码评审方便、高效、加载快、协作流畅	接口响应速度快、性能高大diff、大mr、大接口优化	无安全漏洞，代码安全	运维及oncall成本低系统稳定无bug，全年365*24*60不宕机

• Gitlab版本升级（13.12->14.0->14.4->14.10）

【背景或动机】：

1. 存在重大安全漏洞，基础服务代码资产安全重要性，公司安全部要求升级
2. 相信开源的力量，充分利用社区开源成果

【价值收益】：提升代码拉取和上传性能、接口性能，降低pg数据库和gitaly压力；安全漏洞修复

• 代码处理性能提升

1. 提升大库代码拉取性能（clone/pull/fetch），支持git v2协议，可减少拉取耗时67% （主站移动端仓库）
2. 大幅提升大库的push代码性能，其中批量push check阶段耗时可降低90+%
3. 提升底层**处理git对象性能30%**左右，降低gitaly内存压力
4. 提升底层**处理hook事件性能10%**以上，降低gitlay CPU压力

• 接口性能提升（尤其是大数据量的接口）

1. mr列表接口性能提升（大仓库3000个mr），接口耗时减少50%（1.5s降为700+ms）
2. compare diff接口性能提升（大diff比较），**接口耗时减少50%**（5.5s降为2.7s）
3. 项目列表、tag列表等大数据量获取接口性能提升

• 其他

1. pg表存储优化，减少大表的存储空间
2. 支持repo仓库增量备份，大幅减少备份耗时
3. 导入外部代码仓库的方式注入重大安全漏洞等修复

• Gitlab版本升级主要工作

【难点与挑战】

1. Gitlab社区连续小版本升级支持不停机（前提条件限制），跨版本升级必须要停机
2. 缺少行业参考和最佳实践指引，社区的帮助文档参考，不一定全面和适用
3. 我们的架构（高可用、多AZ部署）和自研代码改动与社区官方都有很大的差异，两面开花如何高效低成本的合并与适配兼容？
4. 每次版本升级都是一个庞大的工程，要投入大量的时间和精力去调研评估、环境准备、实践验证、回归测试、架构适配、自研改动兼容等等。

gitlab版本升级并非简单的按照文档可一键升级，很多问题是没有相关文档或文档也发现不了的，需要因地制宜、大量实践验证（比如最近升级14.10两个pg数据库混部署导致升级失败问题）

做了哪些工作？

【价值和收益】：

1. 用于支撑gitlab版本升级，获得上述版本升级的收益价值

2. 同时自身工作提效，降低gitlab版本升级成本（时间和人力）50%

3. gitlab升级停机时间减少60%（150min降为60min），降低对用户和平台研发交付效率的影响。

4. 1. Gitlab自身数据 ：500+/min拉取代码次数、1~2/min推送代码次数、API请求4000+/min、QPM 6000+
   2. CI-Pipeline影响：公司pipeline流水线执行次数110+/min，每次升级即可避免1w多次流水线拉取代码失败

注：以上数据为非工作日低峰期均值

时间	目标版本	停服不可用时长（分钟）	操作时长（分钟）	操作人力(人)	说明	图示
2020.12	13.6	30	30	2	逐步升高的原因：高可用架构复杂度，部署节点越来越多（36台服务器），笨办法、基本靠手动操作自研变更feature越来越多，代码复杂度提升使用数据量增加，升级DB迁移耗时长
2021.5	13.10	60	60	2
2021.8	13.12	90	90	2
2022.4	14.0.12	150	210	2
2022.7	14.4.5	120	180	1	开始下降的原因：1、准备工作、操作和验证实现自动化、流程化、并行化、可复用 2、灰度部署、降级预留升级部署方案
2022.11	14.10.5	60	120	1	多AZ多机房部署，架构进一步复杂

2.Gitlab高可用与稳定性建设

诉求或痛点？

• 多AZ建设，阻塞点：Gitlab对象存储不满足，不支持AZ逃生

• 依赖治理，降低三方依赖对gitlab稳定性影响

• 上线变更缺少规范化、流程化、标准化管控

• 缺少gitlab问题或故障标准快速处理流程，应急处理指导

• Gitlab多环境建设不规范，不完整，缺少线上模拟环境和数据

• 多AZ建设，依赖治理、降低三方依赖对gitlab稳定性影响

1. 对象存储迁移改造，由ceph s3迁移至blobstore。实现完成四种对象3.7TB数据的零停机、用户无感的迁移改造。对象存储依赖具备AZ逃生能力，降低依赖故障对gitlab影响
2. LB负载均衡依赖改造，gitlab内部组件改造为使用域名替换IP直连LB方式，降低单点故障影响，提升故障自愈能力。（曾出现过LB变更影响导致gitlab故障）

【高可用成果举例】：

• gitlab服务其中1台物理机故障（3次），机器宕机。gitlab服务10s自动检测故障节点并摘除。机器重启后服务自动恢复。故障造成影响单节点时长1min左右（冷启动时长）

• 上线变更管控，故障处理SOP等流程化、标准化实现。降低变更风险，提升故障应急处理能力。

【价值与收益】：gitlab上线变更引起的故障数为0

---

KDev命令行（15%）

OKR

（2022Q2）完善kdev命令行工具，支持较完整的从拉分支、commit、push到MR、提测等和kdev服务端交互功能，命令行工具支持完善灰度能力

完成情况

1. 功能需求方面，新增7个子命令，包括拉分支、mr等相关操作，交付了电商、移动端等使用方的多个需求。Kdev命令行使用文档

2. 技术优化方面：

3. 1. 支持了二进制灰度发布能力，提高交付质量。
   2. 改进了二进制升级方式，支持平滑升级，不再需要单独的升级步骤，提升用户体验。
   3. 支持了命令行本地埋点日志及上报能力，用于了解命令行使用情况，问题诊断等方面。
   4. 探索命令行自动补全（AutoComplete），支持了静态补全，动态补全方面还存在技术难点。

Gitlab（80%）

OKR

（2022Q2）问题定位与止损效率提升，目标单次问题15分钟内止损或恢复

（2022Q3）建立完备的Gitlab周期冷备机制，后续压缩恢复时间到1小时以内

（2022Q3）Gitlab双AZ建设，具备AZ逃生能力

（2022Q4）检测自身可用性，并通过停止或者摘除入口，或者切换DNS等方式自动恢复

（2022Q4）【愿景型】重构代码搜索功能，提升性能和体验

完成情况

1. 问题定位方面：Gitlab监控大盘

2. 首先尽量打通Gitlab内部各组件之间的correlation_id、username、client ip的传递。其次收集Gitlab日志到Clickhouse中，通过Clickhouse实现基于用户，仓库等粒度的监控及专项分析面板。对于常见类问题的定位（某个用户、仓库的突发大量调用、慢请求url提取）做到一眼看到，同时做了环比、同比分析，对于缓慢上升流量有预防监控的作用。

   • 补充e2e监控，从Gitlab集群外部进行拨测，对核心可用性进行监控，目前支持git clone、ssh连通性测试用例，后续待继续补充。

   • 对错误日志分析，通过日志规则匹配，对于已经明确原因的错误日志，进行原因打标。目标对所有错误日志进行自动化判别，对于不能识别的错误日志发出报警。（能力建设基本完成，规则完善中）

3. 可用性提升方面：

4. 已建立Gitlab冷备&恢复机制，仓库数据支持仓库级别增量备份，整体恢复时间压缩到1小时以内。

   完成双AZ建设，支持整体，单组件AZ逃生能力，后续需要随着AZ2.0的推进，进一步规范物理机部署方式，避免逃生演练中故障域不清晰导致的无法逃生问题。Gitlab跨AZ部署

   引入haproxy实现长连接限流与排队，达到削峰填谷的目的。

5. 能力建设：

   1. 实现Gitlab SMTP邮件代理服务，解决Gitlab邮件过多被限流，及sidekiq任务堆积问题。通过存储异步转发，分流发送等方式来解决，同时提供邮件通知转kim通知的能力，确保高优消息即使触达。gitlab smtp代理服务文档
   2. 代码搜索：Code Search
      1. 基于zoekt建立新的代码搜索服务，提供全量仓库代码快速搜索，时间上由当前版本的代码搜索的分钟级降到秒级，同时可以支持仓库粒度索引的即时更新，不再需要定期进行长达几个小时的重启以更新索引。（未上线）
      2. 探索Gitlab Advanced Search（收费功能）自研改造，基于ES实现代码、issue、mr、评论等信息的实时秒级搜索（进行中）。

SVN（5%）

OKR

（2022Q3）建立完备的SVN周期冷备机制

（2022Q4）完成SVN双AZ建设，具备AZ逃生能力

完成情况

1. 已建立SVN冷备&恢复机制，整体恢复时间压缩到30分钟以内。
2. 完成SVN双AZ建设，由于SVN无服务自身限制，无法自动逃生需要手动操作，逃生时间在10分钟以内。

总结思考

个别OKR完成情况不好。比如Gitlab的“单次问题15分钟内止损或恢复”：

1、对目标思考的不够深入。想到的解决方案比较片面，初期认为监控做全就可以缩短故障定位止损时间，于是不停地在加监控，grafana上的图表接近上百，结果真的出现问题的时候看不过来，需要某个指标的时候也找不到，并且还是会发现有些监控缺失，然后继续加监控，整体收效甚微。

2、缺乏对目标拆解，没有设立阶段性目标。这个目标不是一蹴而就的，需要一步步实现甚至长期演进。应该合理的划分阶段，定立里程碑，先达到什么效果，再做到什么程度，优先解决优先级较高的问题子域。

3、没有考虑指标量化。既然目标中本身就有量化数据，在开始之前就应该搞清楚当前处理时间是多久，每完成一阶段的工作，提升了多少，都应该有体现。无法实现量化的结果就是，可能做了很多工作，却连自己都不知道到底有没有起到正向作用，最后也不知道到底是否达成目标。