1、容器环境下智能运维架构技术创新，变革未来容器SEL实验室容器环境下智能运维的挑战容器环境下智能运维研发实践 智能运维发展展望容器SEL实验室2009年， 性能建模 与容量规2001年， 划研究 浙大道富技术中心 成立2011年， 成 立SEL实验 室2013年起， 重心转到容 器云及其运 维2016年至今， 公司化研发 容器技术和 容器平台智 能运维SELZhejiang University实验室团队SEL实验室团队团队 教授/副教授/讲师20人博士硕士100+人研究研究容器云技术企业级应用运维模型机器学习及其应用大规模信息系统件开发模型300余篇高水平论文工程工程完成超过100个海外合作工
2、程项目，掌握世界一流的大型信息系统建设核心工程技术丰富的大型金融信息系统开发、云计算、大数据实践经验具备全球化金融领域业务知识拥有美国道富、DST、IFDS、路透社、中国外汇交易中心等合作伙伴强劲的 科研团队科研团队丰富的 工程经验工程经验丰硕的 研究成果研究成果媒体声音：被美国CIO杂 志 誉 为 “ 一 朵 在 中 国 开 放 的 金 融IT奇葩 Kubernetes 项目的代码贡献, 按照贡献行数统计,截止2017/8/30- by http:/ 核心代码200多万行，贡献度国内第，全球第五， 并出版了国内第本深度解析容器技术的专业书籍Docker容器与容器云 。实验室容器管理平台201
3、6年7月推出以来，迅速在电 信，银行，电商，智能制造，智慧城市等行业服务于20多个合作伙伴。开源项目国内排名全球排名Kubernetes15Docker524Cloud Foundry3265实验室容器云贡献我们为什么做容器平台 的智能运维深耕容致力智 器云能运维扎实研业界广 究基础泛合作容器SEL实验室容器环境下智能运维的挑战容器环境下智能运维研发实践智能运维发展展望传统运维挑战事故报警以投诉为主客服记录故障描述故障诊断定位现场跟踪处理容器环境特点容器化是IT架构*要发展趋势之一组件和服务数量众多部署模式多样化自带服务治理功能容器环境下智能运维挑战监控复杂调度 滞后故障定 位困难容器SEL实
4、验室容器环境下智能运维的挑战容器环境下智能运维研发实践智能运维发展展望智能运维技术研发与实践1. 容器统 监控 容器监控 链路数据跟踪 曰志数据汇聚2. 故障根源 定位 动态拓扑分析 因果关系提取 变更影晌分析3. 智能调度 性能瓶颈分析 资源利用率估算 资源调度1. 容器统一监控案例场景为某政务数据中心，采用IaaS+容器技术方案*要业务：支撑各部门单位应用系统发布运维特点：系统托管在数据中心，发现问题后，应用方请求 数据中心提供相关数据进行故障诊断目标：提供适合应用的监控数据，供运维运行分析设计思路应用集群数据预处理容器Agentflume容器AgentflumeElasticSearch
5、数据索引、酌合Spark Streaming时间、曰志等 级、错误信息等Kafaka运维数据可视化 可视化组件Spark SQL存储集群HBase HDFS容器监控方案如何监控容器镜像Option1: 镜像提前做好，tomcat，jetty等启动命令提前 加好Option 2: 脚本Batch 批量更新镜像但： 根据只跟踪service ip， 没有pod ip，如何对应到podAgent与K8SAgent如何识别自己是哪个service？哪个POD？ETCD维护着service与pod关系Agent启动时查询自己所属的service如何获取链路对代码掌控能力较强采用OpenTracing对代
6、码进行插裝实现Google Dapper的原理origin.classClass LoaderJavaagentnew classTomcat监控数据RequestResponse用 户JVMGoogle Dapper链路跟踪TraceID : 识别用户一次请求，所有全链路上的节点共 用一个TraceIDSpanID：正在处理用户请求的节点ParentSpanID：正在处理用户请求节点的上一个节点2. 故障根源分析案例场景为某在线教育平台提供各类教育资源分享，用户广泛，IT技术能力差异显著客服经常接到比较奇葩的投诉，很难给出合理建议发生故障后，IT团队修复问题需要花费较长时间定位问题根 源目标
7、：减轻客服和运维工作量，快速定位故障或投诉根由分析流程数据采集监控数据、曰志数据特征提取数据清洗、特征选取动态拓扑分析Trace技术、动态链路 跟踪等根由分析因果关系分析、根由 概率分析等反馈反馈故障村主人工村签、机器学习动态拓扑结构基于拓扑的异常检测WEBLogicLogicDB 1DB 2构建执行链正常模型资源访问性能基线异常行为检测行为异常性能异常访问量异常因果关系分析定义构建数据中心服务拓扑结构图，如右图A调用B触发B调用C，A-B称为B的因边，B-C称为B的果边如何判定因果关系果边应发生在因边之后的一个特定的时间段，即服务延时服务延时不能超过超时时间也不能低于服务处理时间通过关联分析
8、，判断潜在因果关系因果关系分析故障根由定位对故障相关容器节点的可能性进行量化分 析形成故障因果关系链，执行链的历史执行频度将 作为该链路上节点权重计算因果链上每个节点的影响以右图D为例，影响D的节点为E，F等，受D 影响的节点为C，B，A量化单个节点对其他节点影响FP(D|F)=P(DF)*w /P(F)P(C|F)=P(C|D)*P(D|F)，其中权重由节点历 史执行频率决定异常发生时，可快速计算出其他节点的嫌疑 程度E 0.5B 0.90C 0.88F 0.4A 0.850.90.80.9510.880.98G 0.60.8D 0.84H 0.78I 0.8H 0.860.90.80.63
9、. 智能调度案例场景为智慧物流信息共享和监控管理 平台支持个地级市范围内，10+万物流车辆， 数百家物流决递公司秒级实时信息更新和发布采用云平台增强其弹性伸缩能力设计思路性能瓶颈定位工作负荷特性：到达率、到达间隔分布、分类系统特性：调度策略、负载均衡策略性能指村：晌应时间、吞吐量和资 源的利用率性能瓶颈定位资源利用率服务时间估算 多元线性回归）资源利用率预测响应时间预测MVA队列模型BP神经网络 + 遗传算法应用容量估算相关方法负载模型 基于资源需 求的事务分 类，CPU密 集型、IO密 集型等流量分析 隐马尔科夫 模型 自适应平滑 Holt- Winters资源利用率 估算 Regressi
10、on Analysis晌应时间预 测 Neural network Queue network容量估算 基于性能和 资源利用率 的估算，资 源满足应用 需求的同时 应性能不会 明显下降5 13 21 29 37 45 53 61 69 77 85 931 9 17 25 33 41 49 57 65 73 81 89 970.80.60.40.20utilbrowsingsearchshoppingorderingDB Disk DB CPUWeb CPU024681012demand(mills)Transaction2Access logResource logTransaction pr
11、ofileETL1Regression AnalysisTransaction resource demand应用资源需求估算 MySQL 节点CPU利用率 vs 负载容器动态资源调度Kubernetes容器资源调度：Predicates和Priority业务指标驱动资源调度容器业务访问量预测 容器资源需求 / 应用性能分析 如可能过载，容器弹性伸缩或迁移应用流量分析资源利用率估算性能模型构建动态资源调度负载模型容器SEL实验室容器环境下智能运维的挑战 容器环境下智能运维实践案例智能运维发展展望智能运维展望被动故障告警到 主动预防 用预测代替传 统的单纯监控 实时高性能运 维数据处理用户行为分析到 服务行为分析 服务资源访问 服务性能基线 人工故障恢复到 自动故障恢复 改变传统人工or规则修复故 障的模式 通过机器学习， 不断完善故障 恢复知识库
