越来越来多的组织开始搞敏捷和 DevOps 转型，打造了很多的 DevOps 基础设施，比如有管理需求的 Jira， 有持续集成的 Jenkins，有容器编排的 K8S 等等。可是这纷繁复杂的 DevOps 工具链，同时也给企业带来新的困扰。
在数字化高速发展的 VUCA 时代下满足企业高效、高质量的交付目标，企业需要一个能够贯穿整个研发生命周期，覆盖从提出想法到生产上线的全过程的企业级的一站式综合研发平台。
行业内有不少公司提供一站式综合研发平台的产品，企业在采购这类产品的时候尤其要小心，避免陷入又给众多工具链中增加一个成员的尴尬。
在通过研讨会（快速启动会议）来开发项目/产品待办事项并确定项目范围之后，通常会使用带有评估和团队速度度量的看板（Scrum 板），可以观察到
那么看板应该层现哪些内容：
能力：
示例：
来源 《DevOps 架构师行动指南》
| 跨功能需求 | 质量关注点 |
|---|---|
| 可重复性 | 重复相同操作的可能性的程度 |
| 性能 | 执行 DevOps 操作所需要的时间和资源 |
| 可靠性 | 在一定时间周期内，DevOps 流水线及其内部各个软件保持服务状态的程度 |
| 可恢复性 | 失败的 DevOps 操作可以恢复到期望状态的程度，而仅对它所操作的应用千万极小的影响 |
| 互操作性 | 在特定环境下，不同 DevOps 工具通过接口有效地交换信息的程度 |
| 可测试性 | 通过测试，DevOps 运维软件能够很容易地展示其错误 |
| 可修改性 | 修改 DevOps 软件、过程或者应用程序运维环境所需要的工作量 |
实现这种质量的技术总结：
| 跨功能需求 | 实现这种质量的技术 |
|---|---|
| 可重复性 | 维护活动的踪迹；版本控制一切；使用配置管理数据库来维护参数；在需要的地方执行 |
| 性能 | 测量以判断过程中的瓶颈；在它未使用时拆解环境；在云上执行尽可能多的操作，因为云上的资源在未使用时可以释放 |
| 可靠性 | 识别不同服务的故障率；对高故障率的服务建立镜像；通过工具尽可能快地检测故障，这些工具的任务是监控组件以发现其执行时间处在正常范围以外 |
| 可恢复性 | 在脚本中内置异常处理；为监控服务提供信息；保证生成合成的诊断信息以支持更快地调度 |
| 互操作性 | 选择那些具有稳定接口和灵活脚本能力的工具；保证流水线的不同阶段的数据模型是一致的 |
| 可测试性 | 为专用工具使用单元和集成测试；协调测试用例与监控规则 |
| 可修改性 | 基于对工具的预期变化来更新模块化脚本；将运维运作封装到小模块中，这些小模块之间是松耦合的 |
示例：
通用能力：
如 ChatOps
通用能力：
—— 《Java 持续交付》
一个部署平台应该提供以下功能：
容器平台组件：
Serverless 架构是指大量依赖第三方服务（也叫做后端即服务，即“BaaS”）或暂存容器中运行的自定义代码（函数即服务，即“FaaS”）的应用程序，函数是无服务器架构中抽象语言运行时的最小单位。在这种架构中，我们并不看重运行一个函数需要多少 CPU 或 RAM 或任何其他资源，而是更看重运行函数所需的时间，我们也只为这些函数的运行时间付费。 ——《Serverless 架构应用开发指南》
通用能力：
Riemann + InfluxDB + Ganglia + Graphite
InfluxDB 提供一个线协议来收集测量数据，而 Ganglia 和 Graphite 则正好适合作为它的测量数据输入，下一步还需要一个将各个节点数据以最小耗费资源的方式收集到一起，使用 Riemann, 它是一个从各个安装Riemann 客户端节点聚合事件的工具，它是基于 TCP 和 UDP 的 Protocol Buffer 协议，因此轻量且快速。
最后，是图形化显示测量数据，推荐使用 Grafana, 它非常流行强大，可配置界面，能很好支持 InfluxDB 和 Elasticsearch 。
现在，我们有了一个集中化监控服务器系统， Riemann 能发送各种我们需要收集的信息，使用 Riemann 工具发送 cpu, 磁盘disk, 内存memory 和 网络状态等。
架构基于 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 度量。
通用能力：
MeterSphere 是一站式的开源企业级持续测试平台，涵盖测试跟踪、接口测试、性能测试、团队协作等功能，兼容JMeter 等开源标准，有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试，加速高质量软件的交付。