目录
一、导语
三、CI/CD工具
1.代码托管
2.集成流水线
3.服务注册
四、持续监控工具
五、企业评估模型
2.研发团队规模
3.质量与稳定性要求
1.初创型小微公司
2.中型腰部公司
3.大型头部公司
一、导语
今天的中国互联网，正加速从消费互联网向产业互联网转型，数字化变革逐渐渗透到每一个具体产业，弹性算力已变成各行各业的水电煤，从底层驱动产业变革。以区块链、IoT、人工智能、大数据等先进技术为代表，新的云原生基础设施已经就绪并将继续演进，同时也会伴随着与之配套的技术和管理范式的演进。DevOps 作为数字化时代 IT 研发和管理范式，是企业数字化转型重要的组成部分。
当前互联网组件生态中，DevOps 工具和系统林林总总，令人眼花缭乱。选用与当前企业发展阶段不适配的 DevOps 组件会导致：
1.工具能力溢出，大量功能闲置，同时增加使用人员的上手成本；
2.工具能力不足或功能过于泛化，无法满足企业研发体量需求或无法灵活定制细节；
3.工具本身质量欠佳，后续相应的社区支持或服务保障缺失，导致稳定性风险。
基于以上问题，本文致力于为企业提供 DevOps 工程效率和运维环节（后续简称效维）工具说明及全景图，并结合典型中国互联网研发场景，提出适配不同体量和阶段的企业的效维工具链选型，希望能帮助企业快速满足数字化变革的要求，加速业务发展，引领业务创新。
二、什么是DevOps及其工具链
完整的 DevOps 生命周期一般包括以下六个阶段：
其中集成、部署、监控三个环节属于 DevOps 生命周期中核心环节，是本文主要关注点。贯穿云原生 DevOps 整个生命周期的工具链全景图如下：
三、CI/CD工具
持续集成可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“主干"中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用
造成破坏。持续集成的输入是代码，所以一个好的代码托管工具是必不可少的。
持续部署指的的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。它主要为了解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题。部署过程中可能还会涉及到平滑迁移新老版本流量的过程，所以对服务发现工具也有一定的依赖。
要实现持续集成和持续部署，自动化的流水线是基础。本节将从代码托管工具、集成流水线工具、服务发现工具三个方面进行工具对比介绍。
1.代码托管
在选择代码托管工具的时候，主要关注以下三点：
1.可协同：在功能层面要包含仓库管理、分支管理、权限管理、提交管理、代码评审等代码存储和版本管理等功能，让开发者更好的协同工作；
2.可集成：好的代码托管服务应该具备灵活和简易的三方工具集成能力，降低 DevOps 的实施落地成本 ;
3.安全可靠：这是最重要的一点，对于个人开发者可能无感，但是对于企业而言，代码的安全性、服务的稳定性、数据是否存在丢失的风险，是会最被优先考量的点。
2.集成流水线
集成流水线就像传统的工业流水线一样，在经历构建、测试、交付之后，生产出一代一代更新迭代的软件版本。实现了软件产品小步迭代、高频发布、适时集成、稳定的系统演进线路图。
3.服务注册
服务发现为 Deploy 的最后环节，缺一不可。无论是四七层负载均衡，还是微服务、RPC 服务框架，服务发现都是产品投产的临门一脚。服务注册发现工具选型需要从生态发展、便利性、语言无关性等角度来综合考量。
四、持续监控工具
服务的稳定性离不开监控系统的保驾护航。监控系统为服务稳定运行提供数据可视化、异常报警、异常定位、故障追踪等能力；同时监控系统还为服务持续优化升级提供依据和考量标准。
监控系统有三大基石：指标、日志、分布式追踪。
1.指标体系：聚焦于故障发现环节，服务以数字形式评估出服务 QPS、成功率、延迟、容量等关键指标，搭配报警系统可以保证当核心指标异常时及时通知开发 / 运维人员。除了核心指标外，服务还可以将各模块 / 阶段的瓶颈点、外部依赖指标量化，建立更加完善服务状态概览，以便服务开发 / 运维人员快速定位异常，完成根因分析。指标系统优势是聚合能力，用较少的存储资源和计算资源表达系统内部状态。
常用工具：Prometheus、Openfalcon、Nightingale、Cat、CudgX、Codesense、Binsearch
2.日志系统：用于记录服务内发生的各类事件。日志系统聚焦故障定位环节，与指标系统相比，日志系统具有更强的描述性，但也伴随着更大的存储空间和计算存储资源要求。日志是常用的监控方法，比如在具有外部依赖系统的服务中，一般会将外部系统发生的错误和错误原因以日志形式记录下来，以便在故障定位和复盘时恢复异常现场环境。
常用方案为：ELK（Elasticsearch、Logstash 和 Kibana ）。
3.分布式追踪系统：用于分析服务调用关系。在微服务盛行的今天，服务之间调用关系越来越复杂，微服务之间相互影响也更加难以定位和排查。分布式追踪系统聚焦于故障定位环节，与指标体系和日志体系不同，分布式追踪系统可以提供服务之间依赖拓扑信息，对于梳理系统调用拓扑、追踪下游依赖导致的异常意义重大。
常用工具：Jaeger、SkyWalking
五、企业评估模型
1.DevOps成熟度
DevOps 成熟度是评估效维工具选择的首要参考维度。不同企业 DevOps 发展阶段不一，为了更好地选择适配企业实际情况的效维工具，我们需要从多维度进行评估：
1.组织与文化：DevOps 需要文化与组织的变革，包括研发与运维、IT 与业务之间的隔阂及部门墙的打破。组织支持 DevOps 的力度，以及现阶段文化与 DevOps 的匹配程度是这个维度的关键。
2.敏捷开发：DevOps 是敏捷开发理念的更科学的实践体系，因此前期敏捷做得好不好直接影响到 DevOps 的效果，两者是相辅相成的。
3.CI/CD：CI/CD 不仅仅是工具或流程，更是一种方法论，“持续"是其核心。CI/CD 管控从代码提交那一刻到代码运行在生产环境的整个过程。
4.可视化与自动化：可视化是让 DevOps 人性化的重要一环，通过良好的可视化看板，可以快速发现 DevOps 流程中的阻塞点和风险点。自动化一方面是为了更快推动价值流从左向右流动，另一方面也为了将人为失误的风险降到最低。
5.运维监控与预警：开发与运维紧密合作，甚至是一个团队，对于运维的监控和预警对所有相关方可见。
6.持续度量与改进：DevOps 的效果也是需要度量的，“如果你无法度量它，你就无法改进它”。DevOps 提倡更频繁的直面问题，度量则是一种很好的方式帮助我们发现问题，并持续改进。
2.研发团队规模
效维团队的人员规模，也会影响 CI/CD 及监控工具链的选择。我们把 20 人以下的效维团队定义为中小团队，20 至百人以上定义为大型团队。正常来说，效维团队的规模也同比研发团队的规模。对于中小团队来说，选择学习曲线低、能快速搭建且有较完备社区或官方服务提供后续支持的工具为主，容忍功能相对单一。大型团队因为有较充足的人力及技术实力，有条件选用有一定上手成本，但功能全面且支持深度定制甚至重构的工具。
3.质量与稳定性要求
业务对运维服务质量的要求，也深度影响效维工具链的选择和搭建。比如金融业务，对稳定性和精确性有极高的要求，并且面临外部强合规性的监管，效维质量要求较高。而其它类似推荐的业务，即使出现问题也只是降低客户体验，比如展现相关度不高的商品或新闻，整体并不造成灾难性的后果，效维质量就相对要求不高。
针对于效维质量要求较高的项目，工具链的选择倾向于功能覆盖率较全，有大厂背书或业界口碑，历史 bug 率不高的工具，整个的效维流程的时延以及效率相对较重。针对要求较低的项目，工具链的选择倾向于能快速搭建，能覆盖基本功能的工具链条。
4.服务治理标准化程度
企业的服务治理标准化程度也会影响效维工具链的选择。服务治理标准化包括硬件的标准化、OS 的标准化、语言栈的标准化、通信协议的标准化、框架的标准化等。标准化程度较高的企业，效维工具功能可以相对比较聚焦，不需要覆盖各层级多种标准导致的技术复杂度。标准化程度较低的企业，效维工具的体系和结构会比较庞杂，甚至在有些链路环节无法做到完全统一和自动化，需要效维人员深度参与修改与定制。
六、典型的几种企业形态
结合以上的评估维度，我们认为典型的公司型态包括以下三种：
1. 初创型小微公司
创业型企业一般选择此种模型，此时公司以快速迭代服务、提升开发效率为第一个原则，运维能力有限。
2.中型腰部公司
此模型适合于业务稳定性要求较高的企业，此时企业一般有稳定的服务和客户群体，服务质量至关重要，需要完善的 DevOps 流程保障服务更新 / 发布过程中稳定性要求，并满足提高开发效率的诉求。
3.大型头部公司
此模型企业内各服务和组件都趋于成熟，企业有高稳定性要求的核心服务，有专业的运维团队，需要完善的 DevOps 平台来保障复杂的微服务体系下的服务质量。企业更关注于系统平台化，将各类组件分门别类组合成为系统平台，并搭建 CMDB 管理服务元数据，按组织架构管理服务。
资料来源：
- 《星汉未来综合运维解决方案》白皮书
- DevOps技术栈：23 款 DevOps 工具建设云原生时代
1409
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
