可视化智能IT运维系统课件.ppt

传统监控转向智能分析 操作系统磁盘使用率过高 服务器磁盘损坏 数据库表空间使用率过高 交换机端口流量异常 虚拟化资源池容量不足 HDFS磁盘使用率不足 ……. IT监控 应用性能监控 请求响应时间过长 SQL执行时间过长 代码执行效率低下 系统软件配置失当 ……. 硬件故障率分析 Top服务器硬盘故障分析 Top服务器电源故障分析 Top存储控制器故障分析 Top存储硬盘故障分析 虚拟化资源池分析 Top剩余量存储分析 Top停机时长vm分析 Top磁盘消耗vm分析 Top磁盘日均增长vm分析 Top 磁盘读写效率vm分析Top 内存使用vm分析 服务器性能分析 Top CPU使用率机器分析 Top 内存使用率机器分析 Top 磁盘使用率机器分析 Top 性能故障告警分析 Top 磁盘读写速率分析 数据库性能分析 Top 表空间剩余量分析 Top SQL性能分析 Top 缓存命中率分析 Top 日志日均增长分析 Top 磁盘读写速率分析 网络流量分析 Top 会话流量排行分析 Top 源IP流量排行分析 Top 源端口流量排行分析 Top 目标IP流量排行分析 Top 目标端口流量排行分析 Top 协议流量排行分析 各种统计报表，提升分析价值 提升运维能力积累 针对不同资源（服务器性能、硬件健康、日志状态、日志关键字、进程性能、数据库性能等）的告警处理，通过知识库可以实现运维方案的知识积累，方便知识的传递与故障的快速解决。 告警事件 告警时间 原因分析 处理方案 处理结果 告警资源 处理人 附件信息 告警类别 知识关键字 提升故障处理效率 知识共享 知识积累 知识转化 总结 支撑运维智能化升级 以大数据分析能力支撑的智能化IT监控运维平台 机器数据分析 传统 ITSM、 APM、 NPM、 SOC、 Cloud Management 效率提升 构建智能化运维体系 智能化 一体化 * 接着我再讲讲IT运维部门与业务部门的矛盾。 传统模式中，业务部门充当了故障的发现者，他们通知IT运维部门检查问题，而IT运维部门由于无法准确定位故障原因，无法判定责任归属（很多情况下就成了背锅侠），往往运维人员又在分析定位问题过程中花费了大量时间，低水平的故障处理效率很容易给业务系统造成负面影响（这个我们前面也刚刚讲过）。 IT运维部门作为支撑服务部门，在信息系统的战略规划和立项等工作中基本没有话语权，更谈不上决策权，往往是项目建设完成之后才介入系统的管理和维护，等到发现问题为时已晚。 另一层面，IT运维部门只能了解IT设施和业务系统的是否可用，而业务部门则希望业务系统不仅可用，而且要给用户很好的体验，这也给IT运维部门提出了更高的要求。（这就形成了中间交叉的部分，而这部分就是IT运维部门的能力天花板） * 我们把IT运维的现状比作一个密室（为什么拿密室来做比喻）：一是运维人员每天忙忙碌碌，到处在各个业务部门间解决和处理问题。虽然如此忙碌，但业务人员（局外）还是经常抱怨“找不到人”、“解决问题太慢”、“不知道TA们在忙什么”。IT运维服务人员的工作经常得不到业务部门的认可，而且自身工作也难以量化。二是运维人员的分工比较细，没有一个团队有全栈运维能力，也没有一个团队能够俯瞰完整技术运维领域的工作。对于运维队伍自身，整体的发展和成长被严重束缚，而大部分人都活在自己的微观世界中。 在这个IT运维密室之内，IT设备规模和种类繁多、业务系统数量繁多和环境异构、运维团队自身能力短板等问题都是现实存在的。 同样，在密室之外，由于业务形态的变化多样、信息技术的快速发展和革新，也进一步加剧了IT运维的难度。 业务方面： 1、业务流量峰值是一年比一年高，尤其是有特殊任务和紧急任务时； 2、业务形态越来越多，以前更多可能是我们自己内部用户在用的各种系统；现在出现各种面向直接的C端和B端的用户； 3、为了适应形式的变化，业务的调整也日趋频繁，传递到技术运维端体现为更加频繁的版本和变更。 技术方面： 1、云技术的成熟减少了企业对于自建技术运维团队的需求，市场需求这个池塘在逐渐干涸，而池塘中的很多鱼儿还没有感应到变化； 2、技术的全面开源和快速的演进让很多传统商用技术专业成为鸡肋，工程师挟一技之长吃到底基本不可能，来不及在池塘干涸前完成进化的职场鱼儿们可能会被提前淘汰； 3、DevOps的风行为运维开辟了另外一条更有效地路线，反过来也对现有运维人提出了新的素质要求，运维人需要有研发能力且能够应用这种能力来提高运维的效率和质量。 * IT运维团队大致分为三类角色：运维主管、应用运维工程师、IT（硬件）运维工程师。 * 每一类角色都有他们关注的核心问题，IT运维主管希望能从整体进行把控，为信息中心运转提供IT保障，并希望能让IT运维变得高效、IT运维工作可以度量。 IT运