序
2019 年快过去了，从博客的更新上来看，就能够窥探到我这一年在工作上其实并没有太大起色。除了 2019 年世界经济本就不太平，还和目前的状态有关。
2019 年我更多做的是等待的工作，等待着 17 年提出的产品规划，在部门中慢慢得以实现；等待着同僚能够认识到事情真的会走到这一步，那我们就开始做吧。
等待途中会有各种各样的声音，除了自己触发的一次你不请我不愿的跳槽风波，还有来自身边朋友的忠告，以及自己强加给自己的所谓正确道路观念。
那么这篇文章，就算是在等待途中重新审视一下自己的工作，来为自己佐证等待的价值吧。
为什么会提出这个问题？
信息架构设计，是一个被反复提及的概念。无论是在初学交互设计，还是在今后实践工作中和同事意见相左时的拉扯。而我们在谈信息架构设计时，往往会把它和导航设计所挂钩。但是我们往往会忽略两点：
- 感知设计：也就是常说的 Affordance。让按钮像一个按钮，让用户明确我可以做什么，我该做什么。
- 信息设计：我们要暴露多少信息给用户是适合的，而哪些信息是噪音；有效信息又该如何展示给用户，如何规划重点与非重点。
而我的工作就是要做一个运维的中台，其中包括了部署、监控、机器管理、权限以及各种各样的网络、接口、负载等各种实体的管理。
其实在我接手之前，这个中台所需要涵盖的功能，就以各个子系统的形态存在，能够独立完成上述提到的所有功能。虽然彼此相互割裂，例如你申领了机器后，需要手动对机器挂载，然后再去部署系统创建个模块实体，关联代码和机器之间的关系，再部署代码，最后在对机器添加监控；但是，链接这一切系统，以及系统背后的人、代码、组织架构、业务，其实是有一套规范或者说一个实体的，就是服务树。
服务树，我们姑且就把它看成有不同属性的节点的树状结构，每个节点是某些人、某些权限、某些机器、某些代码、某些业务、某些逻辑的集合，并且是他们之间的关系。而这些节点之间又以树状结构彼此关联，也就意味着某些人、权限、业务之间的从属关系。
在 17 年刚接手的时候，我提出了改造的方案：
- 梳理出最常见的运维流程
- 融合现在的系统为两个平台：面向研发的运维平台，以及面向网站可靠性工程师的管理平台
- 改造当前的服务树，与用户个体建立联系，建立感知
但是事与愿违，这 3 个设想都没有实现，最后的方案定型为：
- 将目前的所有系统以 SDK、iFrame 或者其他一切可能的前端技术手段，摆放在一起
而我需要做的就是一个用户可以自定义，一目了然的导航设计。
为什么还是要再一次提出这个问题？
经过 18 年 1 年时间的改造，运维大平台真正上线并投入了生产；随之而来的，也是问题：
- 信息噪音：因为原先用户分布在各个不同的系统中，陡然需要面对一个功能庞大的平台时，信息量过于庞大
- 性能问题：部分系统和部分页面由于 iFrame 嵌入或其他技术问题，导致加载慢
- 彼此割裂：系统摆放在一起，系统之间的关系并没有梳理，导致系统间彼此割裂的问题更加突出
如果说以前不同系统就像是相机中的不同单元：测光、对焦、感光、打印；新的运维平台就像是推出了一个一体化相机，用户可以一次性完成所有的操作；但是，问题也随之而来，测光师傅、拍照师傅、冲印照片的师傅都要来使用这个系统，原有的分工带来的高效，在这个系统上却不存在了。
那么，我们要解决什么问题呢？我们要把这个一体化专业相机改造成一个傻瓜相机，用户不需要关注白平衡、对焦、测光、ISO、快门速度，就可以拍出一张不错的照片。
回到上一节提出的信息架构的概念中去，我们要做的事情，就转变为：
- 信息抽象
- 简化信息
- 彼此融合
信息抽象
原有的运维平台无论是在融合时期，还是在各自为政时期，都围绕着服务树。服务树并不是一个以人为本的设计，而是以成本为本的设计。
它极大地简化了沟通的成本、管理的成本，但是在使用时却存在问题：
- 学习成本：理解服务树本身就困难
- 出现率太高：在不同系统间切换时，用户需要实时关注所在的服务树节点位置
- 内容组织性差：内容与功能还是分散在各个系统中，服务树并没有把系统间本应彼此关联的功能和内容串联在一起
基于这些原因，我们希望设计出：
- 围绕着服务这个实体，用户就可以在这个实体上开展大部分的运维相关工作
而什么是服务？服务其实就是服务树的精简，我们将服务树中的 service 级的节点，定位为服务。这就极大的降低了服务树的复杂程度。
紧接着，我们围绕服务这个概念，将服务的相关信息：资源使用、人员信息、容量水位、发生的报警、部署事件、存在的风险点等等，融合在一起。不仅解决了内容组织性差的问题，也做到了各个系统彼此融合。
有关服务树出现率太高的问题，这个问题我们也尝试解决过。在另一个容器资源管理平台里，我们将更像是物理机时代产物的服务树进行了隐藏。
让用户直接和容器集群建立关系，通过收藏集群，自动选择服务树节点，隐藏服务树，改造服务树为类 URL 并且可以选择性收藏等多种多样的方式，来弱化服务树的概念。但是最后的实际效果并不好。服务树这个概念推广时间久，作为研发和网站可靠性工程师对话的桥梁，弱化它带来的效果并不被认同。所以这次，我们选择了简化：首推用户去了解 service 级的服务树节点。
那回到问题本身：为什么我们要做信息抽象呢？
相信每个看过苹果发布会的同学，都会发现苹果每年都会迸发出一些新概念：人像模式、Retina 屏幕，以及最近的 Deep Fusion。学习这个概念背后的技术细节，对于普通受众来说门槛太高，我们需要抽象，我们需要简化，来提高沟通效率。这个概念可能会造成认知偏差，可能会造成信息不准确，但这些代价远比用户不知道、不了解、不使用要来得好。
在运维平台上是一样的。信息分散在系统的各个角落：
- 我查看监控时，需要了解指标、大盘、选择机器节点等等
- 我开展部署任务时，我需要创建模块，建立代码、构建包和机器之间的关系等等
- 我管理我的机器时，我需要在服务树上创建节点，并建立节点和实体机器的对应关系等等
那么这些有没有一个抽象的概念，能够让这些所有信息都归置在一起又彼此联结：
- 我查看监控时，是要了解一个服务的性能、可用性，以及它所在机器的系统性能
- 我开展部署任务时，是要对一个服务进行更新，更新到我认为的最新版本
- 我管理机器时，是要查看这个服务的 IP、接口、机器可用性信息
那么服务就可以作为一个实体，来串联不同系统之间的功能，从而提高使用效率。并且激励系统设计人员，将重要信息提炼出来，与服务绑定在一起。也就意味着：
- 我查看监控时，你最好给我一个服务的默认大盘，在我不需要任何专业技能的情况下，对服务性能一目了然
- 我开展部署任务时，你最好告知我这个服务的上下文、部署历史，来辅导我决策
- 我管理机器时，初始化的动作可以自动化，我仅承担阅读机器信息的工作
这就是为什么要做信息抽象。便于用户理解的同时，也为之后的设计决策提到清晰的方向。
简化信息
其实在上图的「服务的信息概况页面」，我们就能发现简化信息的痕迹。这个页面集成了监控、服务可用性、权限、部署、风险量化、第三方系统中最重要的信息，并且将其他信息噪音去掉，等待用户通过此页面，链接到其他各个子系统中进行更高阶的信息阅读。
简化信息的目的其实很简单，我们希望：
- 信息以阶梯递进的方式，展现给用户
我们以资源（机器管理）来举例，在资源页面我们将会看到与这个服务关联的资源列表，包括它的名字、IP、运行情况等，能够对服务的资源整体情况有所了解。
如果用户对某个资源有进一步了解的需求，则可以展开详情进行查看。其中就包括了资源的挂载信息、监控信息，以及操作系统、CPU 等静态信息。
如果用户有对资源有更高阶的操作和信息查看需求，则可以点击【前往资源管理】按钮，跳转至资源管理系统中进行更高阶的操作。例如申领机器，查看网段分布，对机器重装系统等等。
除了系统级的信息简化工作，带来的信息阶梯型呈现体验；我们还在某些细节信息做了一些简化，例如：
- 部署模块信息，仅展现级别、名字和最新 CommitID
- 报警事件信息，仅展现级别、名字、触发值、触发实体、触发时间和通知情况
依赖于信息抽象实体：服务，这个概念的提出，我们还可以将以前复杂的操作都做到自动化。例如在监控系统中，我们需要手动来创建大盘来表征一个服务的性能，那么是否有可能我们就默认创建好一个服务大盘呢？
如果这块功能得以实现，原先用户需要了解哪些机器是属于一个业务逻辑，将它们的指标都归置在一张手动创建的监控大盘上，并且创建分组，使用聚合计算等多种方式来查看指标数据。这一系列稍显专业的操作，就无需用户参与，而交给系统去完成。用户只需要查看，和略微修改查看的视角。
彼此融合
简化信息也就意味着预留出更多的展示空间给彼此，就顺理成章地可以做到系统间的融合。
例如在上图「资源详细页面」中，我们可以看到资源的系统监控指标的数据，这就是机器管理系统和监控系统之间的融合。因为信息简化了、分层了，就会有更多展示空间留给彼此。
而我们认为在资源详细页面中，直接给出某个机器的 CPU、内存、磁盘的最近 24 小时趋势图，是比上级列表中的状态、瞬时值，能够更进一步地表征机器的运行情况的。
当然，彼此融合不限于不同系统之间的信息融合；当我们在完成一次异步的复杂操作时，原有的系统会打开多个页面。例如原部署系统就会将部署任务列表、详情、单台机器的日志，拆分成彼此独立的页面。虽然每个页面的信息夯实，但是用户在等待操作完成时，需要在各个页面间切换来阅读信息，从而决策下一次动作。
依仗于信息简化，我们能够将各个页面的信息都集中在一起；去掉了不常用的操作，隐藏掉机器名称改用小方格替代，折叠掉专业人士才能读懂的配置信息，我们才能给出一次部署任务的整体图景。并且给出一直在更新的日志信息，能够消除异步操作带来的心理上的不安全感。
下一步
目前这个项目正在执行过程中，我们还添加了服务的生命周期的管理，也算是侧面验证了信息架构改造后，会潜移默化改变设计人员在设计产品时的思路。除此之外，我们在面对原信息架构难以招架的需求时，也显得从容。
例如最近，用户提出要在服务树上加上虚拟产品线的概念。因为公司的组织架构重新划分，以及国际化业务的开展，原有的产品线划分难以满足用户需求了。那么在提出服务这个概念时，虚拟产品线的需求，就可以转变为服务集的概念。
注解：服务集，顾名思义，是一些服务的集合。而虚拟产品线，相当于是需要重新创建一个虚拟服务树，来对节点进行重新划分。
这也是新的信息架构区别于服务树的所在，新的信息架构更具灵活性。
