服务端内部管理系统的质量一直是个痛点。
比较重要的业务系统，会有一个团队来开发维护。这类的管理系统因为涉及核心业务，投入资源比较大，会配置PM，UI，前端，服务端，质量和完成度会比较好。
随着服务端涉及的功能越来越复杂以及各个功能的服务化，服务端团队需要很多内部管理系统，例如短信服务，图片上传服务，权限服务等。这类系统的特点是：每个功能都比较简单，整体上看需求比较杂，数量比较庞大。开篇所说的内部系统主要指的就是这类系统。
在实际的开发过程中，由于这类系统的特点，不会投入过多资源，往往都是这个服务的开发自己做。一般会产生以下情况：
不做管理系统
如果不做管理系统，那有一些配置管理的需求怎么办？答案是直接修改数据库，实际上这种情况占比不小。这么做的主要问题：一个是运营需求得找开发，效率低；另一个是直接改数据库，可能会改错，导致服务出问题。
只做接口
服务端开发往往不愿意写前端代码，主要是因为服务端写前端的效率不高，而且一般服务端并不了解前端UI框架，写出来也比较丑。这么做的主要问题：运营需求跟开发依然不能分离。
做个简单页面
如果运营需求很频繁，即使服务端开发前端效率低，也得做。总结一下这么做的主要问题：完成度差，UI风格不统一，系统分散，安全相关的账号、权限、操作记录等都不具备。
做个完整的系统
如果每个系统都投入UI，前端，服务端去开发，也会有如下问题：系统分散杂乱；UI，交互不统一；账号，权限，历史记录等功能重复开发。
以上总结了内部管理系统的问题，间接的得出了一个结论：高质量的内部系统是可以提升团队的开发效率的。既然在高质量的问题上可以达成共识，下面需要讨论的是如果构建一套流程高效的完成，实现服务开发、前端开发、管理系统维护的平衡。
统一管理系统架构
管理系统页面二级结构
服务端：只负责编写管理相关的API接口，涉及到账号、权限的部分，接入统一的账号服务，权限服务。
统一管理系统：所有管理系统的统一入口，负责账号登录，系统级别的权限管理，操作历史记录等。
前端：账号、权限和操作历史与统一管理系统对接；业务功能与具体的服务端对接。
页面二级结构：一级页面中可以配置子系统，系统模块多时，只展示当前账号具有权限的系统，一级页面可配置，只开发一次即可。
二级页面独占一个页面，方便系统功能开发。
备注：
账号、权限需要有统一的服务。
业务服务端和统一管理系统在账号、权限等公共问题的接口是一致的。
新增管理系统，只需要前端页面与具体的服务端管理api对接。
前端页面统一在一起，方便UI风格，交互方式统一。
这套流程已经在团队中实践一段时间了，目前已经接入多个系统，取得了一定的效果。