DevOps 数字化转型框架

企业一站式综合研发平台

企业为什么需要一站式综合研发平台？

越来越来多的组织开始搞敏捷和 DevOps 转型，打造了很多的 DevOps 基础设施，比如有管理需求的 Jira， 有持续集成的 Jenkins，有容器编排的 K8S 等等。可是这纷繁复杂的 DevOps 工具链，同时也给企业带来新的困扰。

• 首先是软件研发的不同生命阶段，有着不同的工具，不同职能部门偏重的工具不同，与 DevOps 倡导的透明、协作的文化冲突，久而久之将会产生组织竖井文化，阻碍效率提升。
• 其次不同团队对工具的掌握程度、使用习惯都会造成企业内对工具的使用千差万别。难免会有的团队觉得工具好用而有的觉得难用，有的觉得简单易用而有的觉得难用、学习门槛高。对于规模化企业来说如何沉淀、推广企业最佳工程实践、赋能一线开发团队成为新的难题。
• 还有各个工具之间数据孤立且模型不一致，难以形成统一的研发过程数据，不利于进一步的研发效能度量与改善。

企业需要什么样一站式综合研发平台？

在数字化高速发展的 VUCA 时代下满足企业高效、高质量的交付目标，企业需要一个能够贯穿整个研发生命周期，覆盖从提出想法到生产上线的全过程的企业级的一站式综合研发平台。

• 通过企业级一站式综合研发平台把各个阶段的研发数据打通、可视化研发价值流，从而可以识别效能瓶颈、优化流程。同时把企业内部总结沉淀的最佳实践固化到平台上，以减少各团队探索工具链的学习成本，确保一线团队专注业务系统交付。
• 一站式综合研发平台把企业内部众多的工具链进行整合，提供一致的用户体验，统一的数据模型。平台用户覆盖业务需求分析人员、开发人员、测试人员、运维人员、项目管理等。

为什么不建议企业直接采购产品型一站式综合研发平台？

行业内有不少公司提供一站式综合研发平台的产品，企业在采购这类产品的时候尤其要小心，避免陷入又给众多工具链中增加一个成员的尴尬。

• 首先企业需要考虑一下，企业内部是否都是主流的工具链，比较少的定制化工具。这类产品化的一站式平台往往集成了一些主流的 DevOps 工具，一旦是非主流工具或客户自研的工具，就得加价采购定制化开发。
• 其次是需要评估当前企业是否存在多种研发形态。产品化的一站式平台厂家往往宣称他们在平台里集成了业界先进的某大厂的实践，这就导致企业采购该平台后要么按大厂的实践转型，要么加价采购定制化开发。
• 最后还要想想今后平台的维护与开发。DevOps 讲究的是持续改善，通过不断的优化研发流程来提升组织研发效能，如果产品扩展性不够，每次流程优化又得要定制开发。
• 直接采购一站式综合研发平台的产品，短期来说也许能够快速构建起整个平台，比较适合企业研发流程标准、工具统一的中小型研发组织，而对于一些规模型研发组织通常选择自研。自研的方式既可以最大化复用当前企业研发资产，又可以为企业量身定制适合的实践与流程。

研发服务平台

看板

在通过研讨会（快速启动会议）来开发项目/产品待办事项并确定项目范围之后，通常会使用带有评估和团队速度度量的看板（Scrum 板），可以观察到

• 确定预计完成时间（发布计划）
• 了解范围的添加将如何影响发布计划
• 未来/额外工作的规模
• 了解故事/工作如何在开发过程中移动
• 清晰地看到并识别生产力的瓶颈

那么看板应该层现哪些内容：

• 要完成的故事列表/项目的一般积压
• 任务的一般优先级（排序…通常越靠前优先级越高）
• 项目状态的高层次视图（是否已提取、正在处理或已完成）

持续交付平台

能力：

• 持续构建
• 持续测试
• 持续部署
• 持续发布
• 持续反馈

流程

示例：

DevOps 流水线的跨功能需求

来源 《DevOps 架构师行动指南》

实现这种质量的技术总结：

示例：

DevOps 服务平台

通用能力：

• 分布式缓存服务
• 数据库服务
• 消息队列服务
• 消息通知服务
• 秘钥管理服务

协同服务平台

如 ChatOps

通用能力：

• 即时消息工具
• 操作机器人
• 工具集成服务

部署平台

PAAS 平台

—— 《Java 持续交付》

一个部署平台应该提供以下功能：

• 一个用于托管应用程序的、用户可以访问的物理位置
• 编程语言运行环境（如 Java）
• 持久化存储，可以是块存储或者数据库
• 能够访问（或者）安装所需要的中间件，如 ESB 或者消息队列
• 自我修复或自愈的，即可以自动重启失败的应用程序
• 服务发现，一种用来查找应用程序和其他服务和第三方服务的机制
• 基本的安全控制，包含经过案例加固的机器镜像、受限的端口访问，以及访问控制面板时要求提供强身份验证
• 了解运维方面产生的成本

容器管理平台

容器平台组件：

• 容器技术
• 容器调度 / 编排器。该组件负责启动、停止和管理容器进程，如 Docker Swarm 或者 Kubernetes。
• 存储。
• 网络。
• 服务。
• 持续交付服务。

持续交付容器

FAAS 平台

Serverless

Serverless 架构是指大量依赖第三方服务（也叫做后端即服务，即“BaaS”）或暂存容器中运行的自定义代码（函数即服务，即“FaaS”）的应用程序，函数是无服务器架构中抽象语言运行时的最小单位。在这种架构中，我们并不看重运行一个函数需要多少 CPU 或 RAM 或任何其他资源，而是更看重运行函数所需的时间，我们也只为这些函数的运行时间付费。 ——《 Serverless 架构应用开发指南》

统一监控平台

通用能力：

• 基础设施监控服务
• 系统及组件监控服务
• 应用级监控服务
• 服务级监控服务
• 用户侧监控服务

设计

监控平台案例

监控平台示例 1

Riemann + InfluxDB + Ganglia + Graphite

来源： 如何使用开源建立一个分布式系统监控系统？

InfluxDB 提供一个线协议来收集测量数据，而 Ganglia 和 Graphite 则正好适合作为它的测量数据输入，下一步还需要一个将各个节点数据以最小耗费资源的方式收集到一起，使用 Riemann, 它是一个从各个安装Riemann 客户端节点聚合事件的工具，它是基于 TCP 和 UDP 的 Protocol Buffer 协议，因此轻量且快速。

最后，是图形化显示测量数据，推荐使用 Grafana, 它非常流行强大，可配置界面，能很好支持 InfluxDB 和 Elasticsearch 。

现在，我们有了一个集中化监控服务器系统， Riemann 能发送各种我们需要收集的信息，使用 Riemann 工具发送 cpu, 磁盘disk, 内存memory 和 网络状态等。

监控平台示例 2

来源： Robinhood 工程团队是如何实现度量的收集和监控的

架构基于 OpenTSDB + Grafana + Kafka + Riemann，其中 Kafka 作为代理层，实现将度量流数据推送给 Riemann 处理，并推送到 OpenTSDB 存储。

度量汇集数据库 OpenTSDB 是实现度量收集的主要手段，它不仅针对各类软件栈分别提供了多种标准度量收集器（称为 tcollectors ），而且还支持自定义的收集器。自定义收集器可使用 OpenTSDB 的 telnet 或 HTTP 访问接口收集度量，并将收集到的数据推送到 OpenTSDB 中。对于 Robinhood 应用，度量数据首先被发送到 Kafka 代理。

对于各个服务器，可以使用标准的或自定义的 tcolloctor 发送度量数据给 Kafka。对于应用的性能监测，使用了 statsd 库。应用度量发送到在各服务器本地运行的 statsd 进程。statsd 服务器的实现采用了 C 语言编写的 statsite 。在转化 statsd 度量为本地 tcollector 度量时，采用了自定义的适配器。此后，本地 tcollector 度量由 Kafka 发送给 OpenTSDB。tcollector 进程将度量输出在标准输出上，并调用一个 Python 脚本将输出推送给 Kafka。

Grafana 是一个可视化的度量查看工具，它支持 Graphite、InfluxDB 和 OpenTSDB 后端。还可以在仪表盘中插入 CloudWatch 度量。

工具

收集相关

• collectd 是 Unix 守护程序，它收集，传输和存储计算机和网络设备的性能数据。
• Cube + Cubism.js。Cubism.js 是时间序列化的一个 D3 插件，使用 Cubism 能构建更好的实时指示板，它可以从 Graphite,Cube 和其他的资源中拉拉取数据。
• Ganglia
• Munin 是一款类似RRD tool 的优秀系统监控工具，它能提供给你多方面的系统性能信息，例如磁盘、网络、进程、系统和用户。
• StatsD
• Diamond
• Fullerite
• PCP + Vector。Vector 是美国 netflix 公司用来监控性能的工具，这个工具主要是解决工程师需要登录到各个服务器器上来执行各种命令来查看系统的一些信息。
• Fluentd 是一个完全免费且开源的日志收集系统，性能敏感的部分用 C 语言编写，插件部分用 Ruby 编写，500 多种插件，只需很少的系统资源即可轻松实现 ”Log Everything”。一般叫 Fluentd 为 td-agent。

度量分析平台

通用能力：

• 日志分析服务
• 数据可视化服务
• 分布式跟踪服务
• 大数据分析服务

测试平台

自动化测试环境

Zalenium

Selenium Docker

MeterSphere

MeterSphere 是一站式的开源企业级持续测试平台，涵盖测试跟踪、接口测试、性能测试、团队协作等功能，兼容JMeter 等开源标准，有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试，加速高质量软件的交付。

• 测试跟踪: 远超 TestLink 的使用体验；
• 接口测试: 类似 Postman 的体验；
• 性能测试: 兼容 JMeter，支持 Kubernetes 和云环境，轻松支持高并发、分布式的性能测试；
• 团队协作: 两级租户体系，天然支持团队协作。

https://github.com/metersphere/metersphere

测试即服务

Test as a Service