是我们AIoT SRE团队研发的插件化智能应用运维中台，从0到1孵化自小米小爱的一线运维实战，旨在用思想和工具化思维，系统全面的解决应用运维的各种问题，目标是能够承载一套完整的运维体系，最终实现一站式智能运维。
插件中心一、背景
方案都是由问题驱动的，问题越痛苦，方案需要的越迫切！
摆在我们团队面前的有几个现实问题，每个SRE在解决自己业务问题时，都会写一些脚本或者工具，但是复用度极低，即使定了各种共享方式，但依旧没有效果，如何解决团队内工具的共享？很多业务上的运维需求是迫切的、个性的，需求变化快，依赖外部力量研发工具时间不可控、沟通成本大，而且外部团队也不想接这种一天变N次的个性化小需求，那么SRE只有撸起袖子自己上了，如何把这些个性化工具科学的管理起来？
每个SRE的代码标准都不一样，搞不搞就弄个web管理页面，最后一堆域名一堆系统，如何把大家的力量打到一个点上，不要在基础平台上浪费时间，大家只管开发自己的业务逻辑就可以，如何为团队内每个同学提供一个技术展示的舞台？
二、思考设计
问题就是阻碍发展的矛盾，我们团队内一直在鼓励工具化思维解决业务问题，SRE已经演变成Ops和Dev的混合工种，Dev作为重复琐碎Ops的效率沉淀，在一线Ops的同学做出Dev工具是真的既接地气又实用，既然SRE研发的工具这么重要，而且大都又是一些刚需小工具（大的轮子公司都造好了），如果不解决这些矛盾，团队生产力很难有质的提升，低层次的重复建设也会周而复始层出不穷，如何破解？
绞尽脑汁，终于想到了把运维平台插件化的设计想法，具体的技术方案是团队共用基础平台，其余功能作为插件向基础平台注册，每个插件相对独立，最后大家像拼积木一样拼凑成一个运维平台，大小插件通过插件中心进行管理，化整为零形成一个共享共建的运维工具生态。
插件化改造完成后，的产品架构应该是这样的。
产品架构体系
看上图，团队SRE复用基础平台，以插件中心为根基，大家各自开发自己的运维插件，放到一起就形成了一个工具群，然后再将插件根据运维全生命周期分类抽象成体系，画的时候我是根据故障前、故障中、故障后、效率做了一个分类，绿色的代表已经完成的插件，虚线的代表规划开发中的插件。
三、平台挑战
看似美好，但问题也顺应而生，各种各样的插件形形色色，并不是每个插件自己都能用到，如果工作台包含所有插件，很快就会被各种没用的菜单淹没。
如果这个问题不解决，用户侧的体验随着插件的增加会越来越烂，例如米家的SRE就是不会用到小爱的巡检插件，就没有必要在米家SRE的菜单里显示，所以用户最好能够自定义安装的插件，并能自定义工作台。
和王墉、兴耀沟通后，我们决定做一个可以从每个用户角度自定义安装、卸载插件的插件中心，并且首页工作台菜单也可以自定义，这样团队内部矛盾解决的同时，对用户侧的体验也能做到完美，运维平台对每个工程师千人千面，大家才能更愿意使用。
另外，如何考虑一个新用户的插件和工作台呢？总不能给一个空的工作台吧，拿手机做类比（因为手机是目前用户体验最好的产品，人手一部、千人千面），出于各种目的，一部新手机交付时会预装一些推荐应用，提供一个默认的桌面，我们思考后，决定在设计上使用同样的方法，对每个新注册的用户，系统会默认安装一些通用插件，设置一套默认的工作台，用户设置乱了后，可以自行恢复默认，用户之间互不影响，这样新工程师的问题也解决了。
四、产品效果
项目最终敲定由王墉同学编码，兴耀同学提供基础平台的支持。
王墉同学是第一版的核心开发，也是我们团队第二个牛掰的全栈工程师（兴耀来的早是第一个），经验丰富，代码能力极其扎实，果然不负期望，最终漂亮的完成了的插件化改造，这一步为团队将来的共享共建奠定了夯实的基础，再次感谢王墉和兴耀的付出，来看一下效果。
（1）插件的注册、审核、上线
插件中心
插件中心
（2）插件的安装、卸载（每个用户）
插件中心
（3）自定义工作台（已安装插件）
插件中心
插件中心
这里只讲一下概要设计，还有很多很多的细节，就不展开说了。
相关文章
