经过多年的业务发展，SEE 小电铺的应用数量非常多，缺乏体系化的流水线建设。少部分比较完善的项目工程使用 GitLab CI，还有一部分用 Jenkins 来做构建打包，大部分的应用还在使用 shell 脚本拉取 jar 包进行发布，已有的自动化部署耦合在 CI 里，环境与配置复杂以后难以维护，不够规范且效率低容易出错。因此 SEE 小电铺首先制定了 CI 流水线的规范，包括根据不同的技术栈设计符合的流水线流程，根据分支模型和 MR 流程划分全量集成和增量集成，以及各个流程的耗时标准；之后把工具统一切换到 CODING 支持的 Jenkins，做好构建节点的资源规划，确保每次流水线都会触发自动化测试，包括代码格式检查，代码规范和静态分析，以及单元测试、集成测试和 E2E 测试的自动化执行。最终执行的一个结果会通过企微机器人同步到专门的工作群。
持续部署的流水线设计，主要是借助 Spinnaker 来进行编排，配置好 Bake 和部署流程，这里面的交付制品统一使用 Helm Chart，并且借助 CODING 的持续部署功能来进行发布单的管理，包括创建提单，并行部署，人工审批等。
云原生基础架构除了以上这四步以外，SEE 小电铺的 DevOps 实践还贯穿了很多其他理念。首先在基础架构方面，SEE 小电铺贯彻云原生的理念，把整个应用进行了 K8s 容器改造，直接使用腾讯云 TKE 产品来托管集群，帮助快速完成容器化改造，进行微服务和 BFF 架构风格下的高效容器编排，实现应用的标准化交付，确保资源隔离性和高效的利用率，并能保证环境的一致性。同时在面对流量潮汐时，也能够基于 HPA 和 Cluster AutoScaler 实现 Pod 和节点灵活快速的扩缩容，从容应对业务的各种活动和大促。同时借助 K8s 的 Readiness Probe 和 Liveness Probe，能够比较好地实现服务的自愈和容错。在把 K8s 引入基础架构以后，SEE 小电铺通过引入服务网格技术 Service Mesh 实现了更加精细化的服务治理。通过 Istio 服务治理中核心的 Virtual Service 和 Destination Rules 这两个 CRD 结合 CODING 的持续部署可以实现自动化灰度发布，取代原有的集群蓝绿发布策略，把资源利用和流量控制做到一个相对比较极致的水平，并且把微服务架构里难以落地的服务治理固化成了一个标准的基础设施，让开发能够更加关注应用本身。
在上图中，根据 Istio 里面的配置规则可以实现按百分比把 10% 的流量打到新的应用里，最终通过校验以后可以把整个流量进行完全切换，实现精细化的流量转移。
可靠性 & 可观测性SRE 方法论被 SEE 小电铺引入指导可靠性建设。首先，SLO 可靠性建模包括三个维度：Availability 可用性、Latency 延迟和 Ticket 人工干预。这三个维度分别对前后端应用进行了白盒和黑盒监控指标采集，模型计算公式最终可以输出整个服务指标。SRE 团队基于此模型搭建了内部所有服务的可靠性看板，能够实时对生产环境的服务可靠性指标进行查看和跟进。SRE 方法论中还有一个非常好的概念，就是错误预算。基于 SLO 的模型，可以计算出一段周期内错误预算消耗了多少，从而决定是否调整这个周期内的版本发布频率以及节奏。比如说要维持 99.9% 的可靠性，那一个月内的不可用窗口期就是 43.2 分钟。
可观测性基于 EFK 日志平台做了所有服务的日志收集与聚合，帮助做 K8s 改造后所有容器的收集；指标监控方面基于 Prometheus 和 Grafana 搭建了监控平台，帮助进行发布盯盘和对 Pod 异常指标进行记录和告警。
质量内建质量内建方面，SEE 小电铺遵循了一些 DevOps 社区内较为流行的原则来实施。首先是质量门禁，内部的指标所有单元测试模块覆盖率都必须大于 80%，老的系统也会在项目排期里面不断补充完善，web、小程序、iOS、Android 和 React Native 等应用要求要有 100% 的 E2E 测试来覆盖所有的应用场景，质量门禁还需要管控合并请求，开发的 MR 需要通过 CI 自动化测试，CODING 远程提供的代码静态扫描以及结对代码 Review 以后才会被合并到主干。其次，CODING 的测试管理成功将 SEE 小电铺从原始的 Excel 管理测试用例中解放出来，支持用例的在线评审并制定迭代的测试计划。DogFooding 自测允许在集成环境上进行冒烟测试，通过测试管理中的测试计划进行追踪，并组织提测前的 demo 演示。
成果