AiFault是我们AIoT SRE团队研发的插件化智能运维中台，旨在用DevOps思想和工具化思维，系统全面的解决应用运维的各种问题，目标是能够承载一套完整的运维体系，最终实现一站式智能运维。
作为当初刚到小爱的SRE工程师，倍感痛苦，每天花大量时间处理告警定位问题，但似乎总是摸不到小爱同学的全貌，在老工程师的指导下被动的处理和排查各种指标，疲于奔命，但系统的故障定位时间总降不下来，随之故障恢复时间也降不下来，想好好学习一下架构，但由于模块多、依赖关系复杂、架构迭代快，加上不同同学讲解的也不尽一样，总也没有一个系统结构化的记忆，痛苦越大，越想通过新的方法解决。
因此展开了思考，后面经过和兴耀（王兴耀）同学的努力，总算是把这个痛苦化解掉了，再次感谢兴耀同学的付出，先上一张做出来的效果图（老架构，现在也已经不是这个版本了）。
一、DevOps背景
小爱同学有400+个服务，分布在全国各个机房，当出问题瞬间，大量的告警蜂拥而至，无法快速定位到底是哪个模块在哪个机房出了问题，因此就无法快速锁定故障点和故障影响范围，进而无法快速执行预案止损，即使做了很多的告警聚合分析，但由于一个模块或接口出问题，会影响一系列关联模块告警，单纯报表方式的聚合，无法很快的判断出真正的故障点，而且分析过程耗时长，对用户影响大。
小爱同学依然处于快速成长期，功能迭代快，架构变化快，加之微服务的设计方式，模块多、模块间相互依赖复杂，急需使用一种便捷的方式更新和共享架构知识，同时能够查看各模块的核心指标，特别是新加入的工程师，如果没有一个便捷快速学习架构的途径，一时半会融入不到工作，讨论问题由于知识不对称带来的痛苦，经历过的人都很清楚，不但崩溃而且会浪费大量的时间。
二、思考设计
对上述背景分析后，第一个其实是个故障快速定位的问题，第二个其实是个架构图问题，那么如何将两个问题合在一起解决呢？
继续思考，两者结合其实可以理解成把监控画到架构上，或者说把架构画到监控上，虽然不知道怎么做，但脑子里已经有了雏形，做出来后应该是小爱架构的一张鸟瞰图，在节点上和连线上标记了各种核心指标，指标数据可以动态实时更新，出故障时对应模块有异常提醒。
那么系统该如何设计分解呢，抽象考虑后其实可以将功能解耦成两部分，1是用什么技术将架构画出来，并可以方便的更新，2是如何定义并获取模块和模块间关系的核心指标，想到这里其实已经有这个东西做好的样子了。
开始调研，公司有很多的系统，是否有现成的轮子可以使用，避免重复建设，在公司内部找了一圈，放弃了，发现确实没有，类似cat、skywalking这种性能分析工具也达不到想要的效果，看来只有一条路了，自己开发。
自己开发就牵涉到一个如何做的问题，如何用好现有资源以最小成本做出最好的效果？首先人力是有限的，绝不能设计一个大而全的系统，其次是如果需要在服务器或程序埋点获取指标，在技术评审环节是否能得到开发的支持？因为目前在falcon和数据工厂里已经存储了各种指标，重新收集计算不但会浪费服务器资源，而且还会造成指标的重复建设，而且开发的同学肯定也不想改代码，牵涉到程序的改动，工期也就变得不可控了。
思来想去，指标只能用已有falcon或者数据工厂里现成的数据，否则这个事情肯定会黄掉，为了减少接入的成本，方便将来其他产品线也可以快速接入，最好用falcon的指标，因为小米内部几乎所有的程序都会做falcon的埋点，这样数据源就确定了。
接下来就是找人了，团队里的几个同学，各有所长，就SRE这个工作而言，是一个比较综合的个工种，所有人代码都能写点，但是找到一个有意愿、代码功底扎实、有DevOps发展潜力的还是需要想想的，和兴耀同学共事儿几个月，脑子里第一个浮现出来的就是他了，平时的工作中就展现出了用工具思维解决业务问题的潜力，在团队里也乐于为大家开发各种小工具，有想法有能力有冲劲，跟预想的一样，聊完后一拍即合，一个之前想要废弃的项目AiFault就这样重新起航了。
三、功能设计
做之前我就在考虑，一定不能做成小爱的一个个性化系统，也就是说代码不能写死，一定要从功能化的角度设计这个工具，方便其他业务遇到类似痛点时，可以直接使用，也是为了给这个工具留足发展空间，而且做出来的效果一定要超预期，目前业务上普通的监控琳琅满目，我们做出来这个一定要让其他同学看到后眼前一亮，原来故障定位和架构传承还可以这么做、这么酷炫、这么方便。
这些点和兴耀同步后，我们很快达成了共识，我心里想的是，如果能做出这个工具，对业务、团队、公司、个人都是正向收益，而且目前看对业务以及我和兴耀两个人而言，都是刚需，我们各自也有想要燃烧一把自己的动力，多赢和共识就这样建立了，这个特别的重要。
再是技术选型，最终敲定使用百度echart的图形库，它让这个工具有了大数据和酷炫的属性，前端使用vue结合蚂蚁的组件库，后改成了element，开发语言肯定是python，调研后选定了tornado的web框架，由于没有前端资源的支持，我们只能全栈自己上了，对兴耀而言也是向一个全栈工程师进化和挑战的开始，后面不负众望，项目做成了随之也成全了自己，现在前后端都OK，统筹AIoT SRE团队的效能工具建设。
继续对功能抽象分类，系统就变成了对画布、节点、关系、指标的管理，每个点牵涉到增删改查和属性的配置，详细的不讲了，从用户角度诠释一下我们设计功能时遇到的几个典型问题。
- 一个服务要定义哪些核心指标，分别标记在哪里，节点和线的指标怎么划分？
答：服务的核心指标抽象成可用性、QPS、时延3个，节点下方标记可用性和QPS，线上标记时延，线的动态箭头方向定义为请求的方向，否则都是双向的就没有意义了，节点建立的时候填写部署系统的job名称，便于将来和部署系统打通拿到变更信息，做故障智能诊断使用。
2. 模块如何告警，如何找出第一个告警的模块？
答：模块告警表现为节点的红色闪动，用户可以根据核心指标配置告警表达式，触发告警时自动生成当前指标告警持续时间的宏变量，用户可自行配置放在什么位置，通过告警持续时间可以判断出第一个告警的模块。为了满足个性化需求，用户可自定义样式，当指标满足条件时，节点和线上的信息使用自定义样式显示。
3. 同类模块服务众多，无法全部显示，这个要怎么处理？
答：画布大小有限，像小爱400+个服务全部显示肯定是没法看的，因此我们引入了服务组的概念，同类服务可以显示top，比如小爱显示了top4，在这top4的选择上遵循三个优先级算法，先按照故障持续时间排序取最长top4，如果选不出来再按照可用性最低排序取top，如果还选不出来就按QPS最高取top，优先级依次递减，按照这个算法，页面上显示的一定是最需要关注的服务。
4. 如何以鸟瞰图为中心，关联更多的信息，同时做到简单配置？
答：这个是设计很赞的一个点，对于节点，我们单击可以跳到配置好的超链接，例如可以直接跳到模块对应的dashboard，可以节省很多找dashborad的时间，双击显示节点的配置页面，悬停将会显示模块的详细信息，例如最近变更、机房分布、服务器规模、故障诊断等，这个还在开发中，可以说我们把鼠标的单击、双击、悬停事件做了充分的利用。
5. 链路监控在设计上只支持falcon的数据源？
答：在设计上，我们对数据源做了单独的封装解耦，falcon只是其中一个数据源，只要有需要mysql、zabbix、prometheus、ES都可以作为数据源接入，项目做完找同事聊，才知道这个东西在业界也可以叫全链路监控，我们之前内部都叫架构鸟瞰图监控。
6. 如果减少服务指标的建设成本，让业务上甚至不需要做指标标准化？
答：这个也是花功夫最大的一个点，线上业务的打点千差万别，有的是错误率、有的是可用性，有的可用性是按1算的，有的是100，有的聚合过有的没聚合过，为了避免用户falcon指标的操作，我们做了一个全兼容的功能，指标可以选择可用性也可以使用错误率，可以在算出来的结果上做二次计算，同时falcon可以按照tag和endpoint做各种自动聚合，聚合可以求和可以求平均，可以说用户只要把架构图画出来，对于指标的建设做到了零成本，用户只需要把已有的metric配上就可以了。
四、建设效果
上面放了一张小爱同学老架构的gif图，可以看到出故障时的告警效果，故障模块红色闪动，也可以很快判断出这次故障是最里面的模块造成的，故障依次从内到外慢慢恢复，每个模块的告警持续时间在指标后面有明确标记。
同时因为设置成了AiFault首页，每天打开系统都会看到，日子长了自然而然就把系统的骨干架构和逻辑记住了。后面感谢欧老师帮忙申请了大屏电视，我们将两个电视一个放在架构leader荣堂那，一个放在SRE团队这，已经成为我们日常故障排查、架构学习的一个基础工具了，现在小爱99%的故障都是在这张全链路监控里报出来的，上一张拍的电视大屏效果（也是一张老架构）。
写文章时，群里简单收集了一些用户评价，可以侧面反应出大家看到这个系统时的第一印象，我认为项目是超预期的。
截取了一下当前AiFault的用户数量，300多看似不多，不过对于一个内部技术系统而言，也是挺OK的了。
五、系统延伸
我们后来果然做了多产品线和多用户的改造，把这个监控变成了一个通用工具，并在公司内部开放接入，并做了一个云标签展示，晒一下，目前已经有建设了几十个产品线的链路监控，发现画链路监控其实是个艺术工作，有画的像飞机的，有画的跟坦克似的........如果想看看的可以给小米投简历哈，加入小米后让你一饱眼福。
更多文章微信搜索 ShiLiangBit 关注【运维网咖社】
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
