2. 发现异常后，打开监控大盘查找异常的曲线，并通过各种查询/统计找到异常的模块（Metrics）
3. 对这个模块以及关联的日志进行查询/统计分析，找到核心的报错信息（Logging）
4. 最后通过详细的调用链数据定位到引起问题的代码（Tracing）
环境动态性增强：无论是微服务的架构还是容器化的部署模式，带来的一个特性是环境的动态性会增强，每个实例的生命周期会更短，出现问题后往往现场已经被破坏，登录机器排查问题的方式已经不复存在。
人工智能可以自动化各种管理任务，为教育工作者腾出大量时间。他们越来越多地在许多在线评估任务中使用它。人工智能使他们能够快速地评估论文、考试和评分，以及批改学生作业。
·第二层是业务安全，这一层会更关注在流程机制安全上，如何杜绝删库跑路。比如内部人员，因为本身流程不规范，出现了业界最常说的删库跑路行为，是业务安全的属性，需要运维人员去完善。
数据库安全问题，70%甚至80%以上都是由人祸造成的。不管是外在或者是内部的人，不管是因为客观性攻击数据库，或者是主观性破坏数据库，人祸都占了很大部分。整体上做数据库的安全防护时，技术往往是一方面，更多的行为是在于人冶上面，怎样通过这种流程跟手段有效的控制，在技术之外，把安全性的防护做好，是在整个数据库安全领域里，面临的最为头疼的一个问题。
第二个案例：在年初发生的事情，业内有一家比较大的企业出现了实实在在版的删库跑路行为，最后跑路没有成功又被抓回来了。这个行为产生的影响是，这家业务整个服务废掉36个小时左右，一天多的时间之内都服务不了。
·事中：在攻击的过程当中，对整个访问链路加密、数据落盘加密、备份文件加密。
·事后：一旦被攻破了之后，整体攻击电路都能做到攻击行为上的审计，全量操作日志审计。
第一层：数据安全性，阿里云的MyBase云数据库，专属集群上面已经做到相对比较多的防护，包括白名单控制、返回电路SSL加密、TDE加密以及开源软件连带的内核漏洞修复，阿里云都有自己的团队在做。
上云引入了两个新的问题：
第一个问题，云厂商是否可信？
第二个问题，云计算属于共享性质的资源部署，通过隔离机制跟其他业务部署在同一台物理机上面，这样一来，共享机制会不会放大被别入侵的可能性？
整体上看，云厂商的可信度建议大家上云时，从两个方向去看，
第一，是看云厂商本身有没有足够多的第三方可信度认证。
第二，是否有很多比较大的行业企业已经选择这家云厂商，作为上面的基石标准。如果满足这两条，是可以放心上云的。
