在公司内部多多少少都会有一些公用基础框架等产品(ex:消息总线，rpc框架。web开发框架等)，随着业务部门使用越来越多，遇到的问题或者如何使用等问题也会接踵而来，公共基础部门要秉着“服务”意识，随时解决业务遇到的问题。但随着时间的推移越来越多的业务部门需要支持，维护成本越来越高，本文从工作中自身体会，遇到的问题出发来说明，介绍一些解决方案以及策略。
1、项目要保持优秀
要想项目平时问题较少(仅指bug)，大前提是我们项目的代码要相对比较优秀，稳定、较少的bug。这些是很多程序员追寻的目标。但还是那句话没有完美的方案，没有完美的程序，多多少少都可能有些bug，如果一个项目从出生到死亡一直没有bug，那只能说明两点，1、没人使用，2、神作品，但可能是第一种情况更多。我们要做得是让代码更稳定。
2、专职的维护人员
这点不需要特殊说明了，有项目研发人员就需要有项目维护人员，要解决和答复大家工作中越到的各种问题。这种是最原始的方式，也往往是最有效的方式，简单、高效、同时也很累，如果一个研发人员负责n个项目时，每天有很多人针对这n个项目有各种问题咨询，那比较悲剧，基本一天正常工作啥也别干了，光敲字、电话也够聊的了。(如果有很多问题每天需要答复，需要考虑我们项目本身是否有问题了，或者是否有哪些机制还不够完善)
3、成熟的文档
良好的项目要有成熟的文档。设计文档、说明文档、使用文档、demo、以及注意事项等。还要有各个升级版本说明，修改了那些bug，分别增、删、优化了那些功能等等。
4、定期培训、交流
针对新入职的员工要有培训机制，如何使用、编写代码，注意事项等。定期跟业务部门交流让大家更多得了解项目设计。
5、开源精神
5.1 把一些常用的公共基础框架开源，让更多得业务部门参与进来，使更多得人了解框架的原理和代码实现细节，从而降低公共框架研发部门维护成本。
5.2 业务参与 每个业务线让少部分人参与到项目开发，以点盖面，让业务线服务业务线。
5、自动化
针对一些配置、监控、自动化部署系统等，提供业务用户使用权限，业务用户登录平台添加自己业务的相关配置。
注意：需要做好权限控制，防止用户误操作。这个后果很严重。
6、建立平台
建立常见问题答复平台，用户遇到问题从平台获得答案，用户也可以参与提交问题以及解决方案，由公用框架研发人员负责review，提供标准答案。
总结： 1、没有一个很完美的方案就同做架构设计的时候一样，很多时候都没有完美方案，只有更好的权衡，尽可能多的解决常见得问题，8/2原则，优先解决80%人遇到的公用问题，剩余20%的特殊情况逐步解决。 2、充分利用业务人员的能动性，让大家都参与进来，但从现实情况来看这点也是比较困难的，大部分人是几分热度，真正愿意参与的很少，要找到志同道合的人参与进来，另外公司内部开源还要充分考虑代码安全等问题。
如何改变业务使用人员的习惯以及降低框架研发团队维护成本是一个深思的问题，如果你也遇到这样得问题，有更好的方法请留言，谢谢。