注意
本文档适用于 Ceph 的开发版本。
Ceph Dashboard 设计目标
注意
本文档旨在为讨论 mgr/dashboard 的整体设计原则提供一个焦点
简介
大多数分布式存储架构天生复杂，可能给通常负责多个产品和平台的操作团队带来管理挑战。一般来说，任何解决方案的复杂性都会直接影响管理它所产生的运营成本。答案很简单……让它简单化 :)
本文档旨在强调 Ceph Dashboard 的设计目标，这些目标可能有助于
降低复杂性
提高生产力
改善价值实现时间
提高可观测性
了解目标用户的画像
Ceph 历史上一直通过 CLI 进行管理。CLI 过去是、将来也永远是安装和管理 Ceph 集群的最丰富、最灵活的方式。需要并要求这种控制级别的管理员不太可能采用 UI，除非出于技术好奇心。
因此，UI 的相关性对于新的系统管理员更为关键，它可以帮助技术采用并减少实施新解决方案时通常会遇到的操作摩擦。
因此，了解目标用户画像是设计中根本性的第一步。试图设计一个既能满足“经验丰富”的 Ceph 管理员或开发人员需求，又能满足相对较新的系统管理员需求的 UI，不太可能让任何一个用户群体满意。
设计原则
关键原则
清晰度和一致性。UI 应确保所显示的数据是明确的，并且在不同视图之间保持一致
数据及时性。UI 中显示的数据必须及时。状态信息必须足够新近，才能具有相关性并被自信地采纳行动。此外，数据的时效应显示为时效（例如 20 秒前），而不是 UTC 时间戳，以便管理员更容易立即理解。
通过工作流实现自动化。如果管理员必须按照“操作指南”来执行任务，那么仪表板 UI 的目标就应该是实现这个流程。
提供自然的下一步。UI 是专家系统，因此不应期望用户知道下一步该去哪里，而是应该由 UI 来引导他们。这意味着将组件连接在一起以建立流程，并深化 alertmanager 实现与仪表板元素之间的集成，使管理员能够高效地从警报过渡到受影响的组件。
平台可见性。平台（操作系统和硬件配置）是解决方案的基本组成部分，因此提供平台级别的洞察力有助于提供对 Ceph 集群更全面的视图。
消除术语障碍。术语是大多数系统中不可避免的一部分。然而，一个好的系统会包含内联帮助，以支持新用户和不常使用 UI 的用户。
常见陷阱
不要在 UI 中重新实现 CLI 命令。系统管理员可能会在脚本中使用 CLI 原语来自动化任务，因此简单地添加 CLI 功能会错过工作流并增加复杂性，这可能会使 UI“臃肿”。
不要以开发人员的方式思考……尝试采用管理员的心态，他们只是兼职使用 Ceph 集群 - 这就是当今操作团队的现实。
关注用户体验
最终目标必须是避免通过多步骤工作流（例如 iSCSI 配置或按特定顺序设置特定的集群标志）将复杂性推给 GUI 用户。简单性应该是 UI 的目标……让我们把复杂性留给 CLI。