方案原则上是建立在统一日志管理平台之上，分析对象的数据源是基础，首先要做好数据的治理和管理，然后再构建业务的服务模型。在逻辑上，方案从业务聚焦到了组成业务的关键服务，再定位到影响服务的KPI，最终下钻到提供KPI的实体，整个方案是一个从全局业务到局部系统再到具体指标的过程。
规划路径如下：
- 用户业务梳理：面向用户IT和业务流程，做业务建模。梳理IT和业务的流程，把重点关注的业务链路梳理出来，进行业务建模；
- 服务建模：面向每个IT设备和业务，做服务建模。业务链路中的每一个IT设备和业务，对设备和业务做关键服务拆分，例如一个门户网站可以拆分为一个中间件服务、一个数据库服务、一个基础设施资源服务，这是服务建模的过程；
- 服务KPI定义：面向每个关键服务，确定该服务的关键KPI和权重配置。对拆分出来的每个关键服务做KPI指标和权重定义，以拆分的数据库服务为例，定义他的健康度，一般包括数据库的死锁数、连接数、TPS、QPS等，因为这些指标是直接影响数据库提供的服务；
- 服务分析器：面向服务和KPI，关联对应的实体：把这些KPI和对应的实体关联起来，例如数据库的死锁数，这个指标可能是集群环境中的，把这个跟每一个主机对应起来，便于做平均值或者最大最小值计算；
- 告警规划：对关键的服务和KPI指标做告警配置。对这些服务和指标做告警，在做健康度打分的时候，定义了分数值和严重程度的对应关系，根据严重性程度做告警通知；
- 业务全景图规划：在用户处呈现的有业务全景图、服务分析器和深度分析，帮助运维团队构建业务全链路分析，实时监控服务健康度，并在分析问题时，把多个指标做联动分析。方案在多个维度引入机器学习算法，充分利用算法的优势，把数据的价值呈现出来；
- SLO定义：定义服务质量目标，即服务某个SLI的目标值或者目标范围。
用户业务梳理
目标：面向业务流程建模，展示IT和业务的流程关系。
帮助用户对重点关注的业务流程进行建模，这个流程中可能包括网络设备、业务系统、云平台、认证系统等，而业务之间也可能有相互的依赖关系。梳理好一个完整的业务链路是做智能运维的基础。
服务建模
对应用系统进行建模，根据业务模块或者服务模块进行拆分，同时支持业务的基础设施也应该被关联在内，因为这都是影响业务正常运行的关键因素。
例如以爱数的文档云为例，用户正常使用该平台的前提是该业务平台的Office Online在线预览、Nginx web服务、数据库服务以及一些文档权限、全文检索等系统服务都是正常运行的，如果他们出现报错或者直接停止服务了，那用户侧一定无法正常使用AnyShare。
因此对AnyShare的服务建模可以拆分为如上图所示的结构。
SLO服务可用性定义
通过定义影响关键IT服务的主要指标，可以及时获知服务的健康度。
给拆分的服务定义KPI指标，这里的逻辑就与企业部门负责人给每个成员定义季度或者年度绩效指标是一样的。
继续以AnyShare为例，这里的KPI指标定义分为两类，一类是技术指标，一类是业务指标。技术指标类，以数据库服务为例，数据库的请求数、死锁数、QPS、TPS等，每一个指标都是影响数据库的服务的，继而影响业务健康度的，同时也是企业DBA重点关注的。
业务指标类，以AnyShare自身为例，像在线人数、登录失败次数、主页响应时间等，这些是反应出业务是否正常的，假如在线人数突变，对于业务系统的负责人来说，就应该要重点关注。
服务分析器
面向服务和KPI，关联对应的实体；在业务做逻辑拆分建模后，以功能的方式，把业务的逻辑展示出来，同样以AnyShare为例，服务分析器的效果如图所示。
KPI告警规划
对关键的服务和KPI指标做告警配置。基于前面实现的业务健康度评分，每个服务的分数也都有了，如果分数低，也就意味着这部分的运行风险非常高，因此用户需要及时收到风险提醒。
AnyRobot的方案在这部分不仅仅有对于服务和KPI指标的实时告警，还有基于历史数据的趋势，做数据趋势预测，对超出安全范围的预测值也做告警。
业务全景图规划
对关键的服务和KPI指标做业务全景图配置，建立全局视角，展示各业务系统之间的关联关系，打破信息孤岛，以全局化的角度，掌握业务系统全貌，实现全局化运维管理。
业务全景图可通过基本图形及服务组件自定义运维体系关联图谱，满足不同业务场景需求，支持各服务健康状态及KPI 严重性可视化展示，快速定位上游异常故障点。