之前整理过一版系统权限开通的需求，抛开中间过程，总之，系统权限开通功能是正式使用了。之前的一些设计尝试可以参考。

比如防火墙权限的查看，是一个看起来很简单的功能，也是在做防火墙权限开通时顺手就做成的功能，但是从后期的使用来看，似乎这个功能给我的启示意义更大。

比如最开始的时候，防火墙权限查看是这样的一个界面。输入服务器端的IP和端口信息，就能够查看到所有连接的客户端信息。

    如果用做当前时髦的商业模式2B,2C来说，这个场景属于2C,我们可以基于这个场景来轻松查看到客户端信息的一些情况。比如之前同事无意中说了一个问题，有一个开发同学问他，他有没有某台服务器的访问权限，这类问题一般我们一开始都是拒绝的，因为我们也不知道开发同学的IP,我们也无从知晓更多服务端的信息，其实本质上，这类操作极其繁琐，所以我们排斥。有了这个接口，其实我们能够有一个基本可行的操作方法了。

    当然在这里要让数据产生价值，那一定得联系更多的关联数据，比如你得到了一个IP，其实对你来说，这个IP的业务含义你是不清楚的，这个信息哪里会关注，显然是系统部，IT部门，所以我们可以求助他们来得到这些辅助的信息，当然在不违反敏感信息的前提下。于是乎，下面的功能做了一些后台的迭代，我们申请了新的API查询需求，然后对输出结果进行过滤，能够结合IP输出对应的业务属性，比如这个IP对应的员工姓名，员工部门等，对指定vlan的IP进行API的访问。这样一来我们得到的数据就是一个相对更加具有业务价值的数据了，我们如果要知道这个环境有哪些业务同学在连接，就可以一目了然。

    当然在这个基础上持续改进，那就是我们明确了vlan的范围，那么在指定的范围内，如果没有匹配到员工信息，那么这个办公IP就是一个无效的IP,可能是之前的员工离职或者部门调整导致，没有对数据进行联动。所以我持续改进的就是筛选出哪些无效的IP.

    当然到了这个阶段，好像已经做了一些改进了，其实问题的解决才算走上了主流干道，还有很多的潜在问题需要修复。

    有的同学说，到这里就差不多了，还有什么要改进的，需要结合场景来看待。

    比如现在的权限信息查询，是通过实时查看系统层面的防火墙信息过滤得到。我们其实可以设计成一种表数据模型来存储，这样查询的逻辑会更加清晰，速度更快。

    对于权限接口的访问，目前是通过全量的方式，其实可以做到增量，那么我们就可以申请一个增量的队列，里面只有增量的数据变化，这样我们就不需要全量同步权限了。

    基于这个，我们可以设计一个权限总线系统。