您的位置：首页 > 其它

干货 | 云时代企业IT智能诊断实践与探索

2019-04-12 11:46 162 查看

长按下图二维码关注拜托了王教授，回复 “王教授” 领取PPT和视频

本文根据2019年4月11日，驻云科技CEO蒋烁淼在阿里云MVP直播课堂的演讲《云时代企业IT诊断实践与探索》整理。

蒋烁淼 | 阿里云MVP、驻云科技CEO、马云湖畔大学第一期学员，在云计算领域深耕多年，对可视化云架构管理平台、智能云诊断监控工具等有多年产品设计经验。

全文 7258 字 | 10 分钟阅读

1、云时代的大背景

AWS 2006年发布了第一款云计算产品，阿里云2009年成立，屈指算来，云计算已经进入了第二个十年。随着下一代技术如数字业务、物联网和人工智能的实现，云计算已然是业务和IT的关键组成部分。云技术正在从一个市场颠覆者演变为传统和下一代IT中的主力军。

需要强调的一点是，真正意义上的云计算就是公有云。为什么呢？

先从5G说起。展望未来，5G时代很快到来。大家都在展望伴随5G时代的物联网、边缘计算、人工智能、AR/VR的大变革。而更为实际的，5G时代会发生的事情，是固定网络逐步退出市场，正如之前固定电话慢慢从市场中退出那样。每个人的手机电脑都会以无线网络的方式接入到互联网中。那个时候企业局域网就会消失，局域网消失以后，可能企业内网就消失了，或者说内网就是今天我们在云上看到的VPC、虚拟私有云或者虚拟私有网络，到那个时刻，没有局域网，又何来私有云呢？

随着5G的进入，云计算的发展还是会非常长久的进行下去，直到大部分IT都转入到云计算时代，而那个时候可能会有新的东西出现。

今天对于整个世界改变最大的力量是互联网。未来每一个企业都是互联网企业，云就是互联网基础设施。所以说掌握云计算的技术是非常重要的，未来不懂云计算就没有办法在这个市场上生存，如果你是一个IT工程师的话。

长按图片保存可分享至朋友圈

2、云时代IT从业者的挑战

云时代的到来给IT从业者带来了极大的变革和挑战。云计算大数据技术迭代更新，IT从业者需要掌握的技能更广，还需跟上工作节奏。

传统会把工程师分成开发人员、运维工程师、测试工程师，开发工程师又包括前端工程师，后端工程师等。而现在这样的职业分工也产生了变化的趋势。

前几天有一篇文章说阿里云是不是会杀死运维，有个耳熟能详的词语叫DevOps。这也说明了一个问题：云计算厂商把IT基础设施运营起来了，带来了一个重大的变化：企业内部并不需要单纯的运维工程师了。一是因为DevOps的发展，二是因为云计算带来的极大便利使得很多运维工作被大大简化。

举例来说，绝大多数尚未建立完备开发体系的公司，它的开发工程师就可以通过RAM授权的子账号，甚至主账号进入云的控制台修改关键云资源配置，比如对象存储Bucket的修改。

由于云的分布式的变化，每一个工程师都可以通过API或者控制台，快速的改变云的现状，包括配置信息的变更。这使得传统的运维工作离散化了。某种程度上说，不是不需要运维工程师，而是人人皆运维。

在这样的大背景下，传统的运维工程师又何去何从呢？他们的职业发展也面临着巨大的变化。

传统意义上的运维工程师的主要工作，我们经常开玩笑说是搬箱子，插网线和装系统三大件。而今天面对云，这三件事情都不用做了，因为你使用ECS镜像服务器就装好了，甚至你都不需要自己安装MySQL，直接使用RDS就够了。

因此传统意义上运维工程师本身知识结构面临着更新，传统运维工程师应该要变成企业内部的云管理员或者成为企业内部云架构师。大家也可以到百度百科上看到云管理员这个新职业的描述。

长按图片保存可分享至朋友圈

3、云时代企业IT管理的挑战

为应对市场快速变化，企业业务的复杂与变动并存，还需保障IT系统的稳定可靠。

1）除了故障，还有什么更值得我们考虑？

企业将基础设施甚至中间件使用了云计算厂商提供的服务之后，如果云服务出现了故障，可以根据SLA的条款，向云厂商索赔。在云上，我们最需要担心的不是云服务的故障。在云上除了故障其实还有更多问题需要考虑。

举两个例子：

前段时间宝马发生了数据泄漏，原因是它的开发工程师对AWS上存储Bucket没有进行任何安全限制，导致数据可以被任何人读取，甚至包括Google搜索引擎。
系统本身并没有出现故障，但是发现某些应用连接数或者是进程内存占有快速上升，存储量快速上升，很可能是因为开发工程师的BUG，导致你要为云计算厂商一个月多付好多钱，浪费了带宽或者浪费了存储。

为什么这些问题不能提早发现呢？有以下几个原因：

这些云资源的管理本身非常繁琐，往往因为工程师出差或者管理不善等原因，导致域名证书或者主机本身忘了续费，从而引起了业务的中断。
工程师并不具备财务权，传统职责在故障的发现和处理，而上述这些问题的管理并没有得到足够的重视。

因此，重要的问题不是故障，当你到故障那一刻的时候，那个问题已经不小了。

2）复杂、大量数据的挑战

现今我们处在一个复杂的世界中。这个世界的数据不仅仅包含云上的数据，还有物理机房、外部的数据，甚至还有IOT，数字化的POS机等持续不断产生的数据。

对一个企业来说，所面对的数据并不一定只是IT数据，大趋势是所有数据最终都可能被汇聚到云上。

3）信息孤立和不对称性带来的挑战

传统IT环境中通常会有一个IT部门负责技术保障，维护管理整个企业内部所有系统，但是随着云的时代到来，任何一个有开发能力或者有系统需求的业务团队，都可以轻松买一两台云主机，装一个软件或者开发一个小程序，就可以不再依赖公司统一的IT管理，快速的将自己的业务跑起来。所以云不仅仅是一个分布式系统，它也使得企业的IT团队，尤其在一些大企业，开始有了分布式的倾向和趋势。

这就可能会造成信息相对孤立和不对称。每个企业的IT管理可能会随时随地变化，因为它有可能开在不同云账号下，有的一个企业有1000台ECS，可能分布在10个团队，每个团队有100台ECS，这种情况也会有大量的出现。

4）多云和云计算产品迭代更新快带来的挑战

很多企业都慢慢的开始上云，甚至上多个云。但是实际上不管是从大的产品功能角度小到API、备份功能或者一个主机的编码，甚至一些非常非常小的控制参数，比如说备份或者是磁盘拍照等等东西，其实都是不太一样的。其次，各个云计算厂商的产品迭代更新都非常快，要管理的要素更多，甚至包括费用。

为了适应多云环境和云产品的迭代更新，需要企业投入更多的力量进行统一管理。比方说公司需要用多个云账号，多朵云，分别管理维护开发环境、测试环境、预发环境、生产环境，甚至要从费用角度考虑有没有资源浪费。

在没有合适工具和管理手段的情况下，管理成本相当高。人工的方法是记住不同的用户密码，登陆不同的账号，然后去挨个看。高级点的自己有能力去维护一套连接了这些平台的API，然后通过API的方式去解决。但这个成本同样很高，要对云产品有足够的了解，万一云厂商某个API改了或者是返回结构改了，还得同步学习更新和修正。

5）企业IT管理对象的复杂度带来的挑战

企业IT管理的对象从传统的物理主机、存储、网络、数据库、中间件变成了云计算服务商提供的一台台虚拟主机、云数据库，甚至是云中间件，包括RDS、OTS、KAFKA，这些都是以云服务的形式提供，云厂商把IT软硬件资源、中间件都服务化了。企业关心的不仅包括虚拟主机，还有云中间件、应用层的情况，管理对象更加复杂。

以上各种云时代对于IT管理的挑战，也正是为什么我们提出来需要云时代企业IT智能诊断。

4、云时代企业IT智能诊断

传统情况下，客户通过监控的方式来发现系统问题、解决问题。在云计算的大背景下，传统监控力不从心。表现在：

监控对象范围有限：比较适合本地硬件与服务监控，不太适合对云原生环境的支持。
监控告警具有滞后性：往往是系统发生严重故障的时候，维护或管理人员才收到相应的警告。而此时可能服务器已经宕机，只能被迫宕机才能解决问题、恢复业务。

随着云时代的到来，智能诊断则是针对传统监控的一场革命，表现在：

诊断范围对象扩大：不仅可以诊断传统IT环境，同时可以诊断多种云环境；不仅可以诊断底层系统，还可以诊断中间件、应用业务层。
诊断领域扩大：突破传统监控限制，不仅可以监控，还可以从安全、费用、架构、架构和性能的优化的角度给予诊断。
诊断的预见性：在云计算或IT系统故障之前有效改变你自己系统中的一些问题，从而避免实际出现故障等等因素。
解决问题的建议：不仅可以指出问题，同时给出解决方法的建议。

长按图片保存可分享至朋友圈

5、云计算时代IT智能诊断专家——CloudCare

CloudCare是驻云科技旗下的一站式云计算IT服务品牌。这么多年CloudCare本身也经过了多次的发展。之前的CloudCare更像一个智能工单系统，就是通过员工或者专家去帮助客户解决IT在使用云过程中的问题。

久而久之发现一个问题，很多客户对云的理解和认知各不相同。很多用户对于云的产品或者是某些特性不了解，他也无法描述清楚他今天需要什么或者如何解决他遇到什么问题。实际上我们很难帮助客户真正解决问题。

在云计算时代，发现问题是提升IT管理一个最重要手段。因此现在CloudCare新推出一个最大的功能就是帮客户做检测和诊断，也就是说你不知道发生了什么问题，就像360一样，我来帮你发现问题，而不需要你自己发现和准确描述问题。

通过将多年的云服务经验数字化，结合基于人工智能的诊断平台，CloudCare针对企业的IT资源进行检测与诊断，从云平台、云主机、到集群，为用户提供监控、安全、费用、优化等多方位的提醒、告警及实施方案，帮助用户大幅缩短IT的平均诊断时间，提升IT系统管理效率。

长按图片保存可分享至朋友圈

Cloudcare有什么作用和特点呢？

1）已经支持大部分的主流云平台

2）超过1000项检测项，并且还在不断更新：把工程师从2013年起所有对于云的认知不断的算法化，变成检测项，帮助用户去诊断检测他的云上IT系统中各种各样的问题。所以检测项的数量，未来是一个没有上限的概念。

3）支持百万级探测点：允许客户将他的云中的大量大量数据可供检测的数据收集上来，所以在这种情况下本身无论有多少用户还是客户有多少云资产，有多少主机，有多少数据库都没有关系，从我们角度来说你有多少我们就能帮你诊断多少。

Cloudcare的核心价值：

1）发现问题、解决问题：不仅是故障，还会从性能、安全、费用都会帮助客户发现问题，而不仅仅是纯粹的故障问题。比如预先发现ECS证书到期并进行提醒，看起来是件小事，而实际上即便是Google、阿里历史上也犯过类似的错误。

2）大量的诊断和知识库内容：驻云从2013年开始成为云计算的使用者并赋能给其他云计算的企业，积累了大量的客户、经验和文档。除了把知识和经验转换成算法写到了平台上，内部积累经过实践验证的文档也全部公开，所有用户都可以查阅。

3）实时的诊断：传统方式是发现问题，解决问题。就像去医院，总是不舒服了才去看病。但是最好的情况是什么呢？即使你身边没有大碍，也要去做定期体检，这样就可以动态追踪你身体的变化，不要到了非常严重的情况才去处理。而我们的诊断几乎是平均一个多小时就可以帮客户做一次全面的云上的IT的体检，基于OpenAPI收集这些IT关键性的数据点，实时反馈数据，实时将客户的问题暴露出来。

4）通过移动终端助力被动IT管理：如果用户需要通过电脑查看的话，实际上也没解决问题，因为需要用户主动去打开查看。CloudCare除了web端，还提供了Android、iOS端，支持用户通过移动方式被动的获得IT诊断信息，避免主动管理的心理和负担。比如之前泛微的OA需要主动打开电脑查看信息，未来它的实时诊断信息可以通过我们的移动终端反馈。

5）支持团队协作：围绕一个问题汇聚成的一条条信息称之为情报，相当于自动建了一个群组，大家就可以围绕这些问题进行讨论，并且这些讨论都会记录在日历里面，而且是以日历维度保存的，就有点像钉钉，但又不像钉钉。因为钉钉群是不会因为问题解决而消灭，而CloudCare当一个问题被解决以后，它所有上下文都会固定在具体时间表里。大家通过这种协同的方式去解决问题。

6）广泛的数据源接入：兼容了各家云厂商的API，帮助各家云厂商用户去做诊断分析，同时也对云厂商以外的数据源进行接入，统一诊断。比如中间件和应用软件的诊断分析，助力IT团队保障系统使用。

6、基于诊断互联网的技术架构

整个平台，我们称之为诊断互联网（Internet of Diagnosis，IoD），是一个完全标准的数据处理平台。

为什么叫诊断互联网呢？我们是受IoT启发，IoT是所有的东西都连接到互联网上，今天可以将世界上所有能够产生数据的对象连接到我们诊断平台进行诊断。

诊断的对象首当其冲的是云，我们可以从云平台中通过OpenAPI将大量的数据导入到我们云网关。之后所有各个平台或者数据源收集的数据进入我们自己研发的流式处理平台。

1、通过流式处理和诊断算法，生成各式各样的结论，回流到流式平台，并且会做一份快照，展现给APP端，或者移动端、PC端等等。

2、也可以将这些数据，和其他业务系统集成，比方说可把业务报表和分析的结果数据，展示成数字大屏。

数据快照有什么作用呢？它相当于我们保存下来的事故现场。比方说系统4月10日出现了什么问题，ECS宕掉了、或者中木马了，就会抓下ECS当时的数据，比如CPU多高，内存占用多高，有多少进程。这样事后可以还原事故现场。而传统的报警是无法还原的。功能上我们称之为情报日历。

系统整体是SaaS形态，对客户来说简单易用。对于云的数据，可以通过RAM系统去生成一个只读账号，分析只读账号下云的资产，当然如果有的东西不想让我们分析，可以设置相应的RAM Policy，进行相应处理。

而对于其他对象的数据处理和诊断分析，可以通过Forehought，另一个平台，实现对于其他对象的数据收集，进行整体的诊断和业务支撑。

整个系统在云端，是24小时、一刻不停的为云和IT进行诊断和分析的平台，对本地来说是一个非常轻量级的状态，整个系统是非常高可用的、非常安全的，部署很简单。

长按图片保存可分享至朋友圈

7、智能诊断体系

从诊断角度分为以下层次：

1）汇聚层：

诊断对象的元数据：比方说以云资源、主机，操作系统的关键信息：进程、进程占用的内存数据等等。
状态数据：时间维度的数据，比如CPU的变化率、内存、磁盘的变化率等。
事件数据：日志数据，事件、消息数据。

2）分析层：汇聚接入平台的数据，通过自研的分析层进行存储、处理，做算法模型，并做关联分析。

3）诊断层：根据分析层所得出的结论，对目标对象进行各种维度的检测，比如应用、中间件、操作系统等，云作为基础设施的安全、费用、架构等。前面讲的检查项是分布在各种各样的对象中的。

4）展现层：展现给客户问题及建议，并且会智能的压缩相似的问题，自动的归并一个问题的多个状态。同时还会进行预测，告诉你可能会发生什么问题；并进行优化建议，提供这个问题的建议解决方法。比如说存储空间不足，告诉你怎么删除历史文件，比如说按量付费服务器开的太多或时间太久，会告诉你怎么操作来换成包年包月以节省费用。这也是相对于传统告警的优势。

从安全性的角度说，我们需要一个只读key，不会向用户环境、云平台、配置信息中写一个字节的数据。也就意味着并不介入用户系统的恢复、远程运维的概念，所以优化建议更多是以我们的文本、经验方式展现给客户，而不直接帮助客户恢复系统、进行操作。

5）用户层：通过App、Web或者短信、邮件的方式，告知用户层，并且可以将你公司所有参与云平台的人员协同起来。

8、智能诊断系统架构

先见（Forethought）数据平台是驻云基于开源监控平台 Prometheus 开发的，针对集群环境，部署在用户的本地用于收集系统和应用相关数据指标的监控服务平台，同时先见数据平台会在用户允许的范围内将部分数据指标上报到诊断系统进行分析诊断并产生相关情报。

CNCF毕业的四个项目里面，第二个就是Prometheus，它是一个时序数据库，K8S的监控就是用的Prometheus。

Forethought是Prometheus的一个发行版，我们在Prometheus上做了大量的修改和增强，使它的数据和采集适应于我们的诊断，可以对其他IT系统、软件、中间件进行诊断。

比如将普罗米修斯的缓存层Trickster打包，同时集成了Grafna，实现了增强型普罗米修斯的UI。此外还有一个组件叫做Forethought Agent，可以把需要诊断的数据送到Cloudcare的云环境中进行分析诊断。

同时Forethought在Prometheus基础上增强了服务发现，增强了exporter，使得其在支持时序数据库的基础上也支持了对于与时间无关的配置数据的获取。

如果你已经是一个Prometheus用户，可以联邦模式，将原有Prometheus的部分数据送到Forethought来，由其再将部分可支持诊断的数据送到我们的云端来进行诊断。

另外Forethought也提供了非常强大的集成能力，将各式各样其他监控，比如 Zabbix 的告警接入到我们的云端，把各种各样其他的告警，包括日志的告警，甚至各种各样的安全报告，也可以通过这种Alert的数据结构通知到云端。

最后云端形成了配置型数据，也就是KV数据、时序数据、日志数据这三种数据。通过自由的情报引擎，去读取这些数据，做预处理，并生成我们要计算的数据集，并通过智能分析引擎，将这些从各处，无论是云，还是Forethought、容器、中间件或者主机拿到的数据，或者报警数据，通过综合的分析，生成在用户前端所能看到的情报。这就是整体的工作流程。

在这个过程中要强调的是：

1）在多维数据收集以后，进行处理的平台是无限可扩展的平台，也就是说，无论用户侧收集的数据有多少。作为诊断服务的提供商，我们会根据用户的情况不断的去增加、减少服务器，来保证对客户数据的有效分析和处理。

2）不断更新智能分析引擎中的算法，来给客户提供更多、更高维度、更有效的问题发现能力和诊断能力。

3）所有关键数据，都会用脱敏的方式，因为我们只需要知道分析诊断问题，并不需要知道数据背后的业务，因此可以把数据脱敏后提交。

4）对于Forethought 来说，export可以收集的数据，并不只限于IT数据。IoT的数据、门店库存、交易量等等数据，都可以收集起来，既可以做业务型的集成展示，同时也可以实现业务诊断，这是另一个话题。

以上就是我们智能诊断的整体技术架构。

9、混合IT环境下的数据采集

在混合IT架构下的数据采集，如果客户能够脱敏将他的库存、订单、交易量数据同步到云端，把打印机、办公电脑、门禁的数据也脱敏后同步到云端，或者脑电波收集每个人的集中度、放松度，等等类似场景同步，其实我们可以监控一切、诊断一切。

只要能够有效的数据采集上来，我们都能进行有效的分析、诊断。这是我们这个平台为什么叫做IoD的核心原因。