作者：彭冬,朱伟
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
智能运维：从0搭建大规模分布式AIOps系统试读：
前言
为什么要写这本书
中国互联网发展非常迅速，一方面得益于互联网基础设施的不断完善；另一方面得益于中国巨大的用户人群和消费市场。网络从PC到移动互联网时代过渡非常快，2017年微博用户中移动端占比已经达到92%，移动互联网的兴起带来了前所未有的新格局，围绕手机移动端的应用生态逐渐形成，大量PC时代的公司已经将产品的主战场转移到移动端。
据中国互联网络信息中心（CNNIC）发布的第41次《中国互联网络发展状况统计报告》，截至2017年12月，中国网民规模达到7.72亿，手机网民占比97.5%，手机支付用户规模增长迅速，达到5.27亿，网络直播用户规模达到4.22亿，中国拥有人工智能企业592家，占全球总数的23.3%。
互联网尤其是移动互联网的发展，也给企业带来了极大的技术挑战，如何保障线上产品各个服务和系统的稳定性、如何快速高效地诊断问题和定位问题等成为企业所面临的核心问题，而这些问题通过传统的运维方式已经无法有效得到解决。尤其是在大数据复杂场景下，对运维有了新的期待，也对运维有了更高的要求。
首先，系统产生的数据在很大程度上反映了系统状态和产品逻辑，监控系统需要具备快速搜集和处理数据的能力，能经过复杂的数据清洗并从大规模数据中抽取监控需要的指标，尤其是能对时序数据进行ETL及存储分析，将异构数据转化成监控系统能够理解的结构化数据。在这个阶段，如何保证数据的一致性和准确性、如何降低时延提高数据吞吐、如何降低监控系统对业务资源的影响等，都是在大数据环境下要解决的问题。
其次，监控系统要与报警系统融合，报警系统承载的是系统风险提示，对准确率要求很高，然而在现实环境下，大部分报警系统都存在报警项繁多、报警次数频繁、报警不准确等问题。
再次，智能化故障诊断、异常点检测、根因分析等是智能运维要解决的核心问题，然而智能化系统要建立在高效的平台化基础上，目前极大一部分公司还没有真正进入平台化阶段，这就为智能运维带来了极大的阻力。
最后，智能运维需要运维工程师具备一定的人工智能、机器学习及深度学习等算法和建模能力，然而就目前来讲，运维工程师在这方面的技能是比较欠缺的。
国内在智能运维技术上，百度、阿里巴巴、腾讯和微博都有相当程度的经验积累，也得益于这些企业的运维平台化的体系逐渐成熟，在跟这些团队交流的时候，大家都有一个共识，就是希望能将智能运维技术应用到运维的各个维度，也相信智能运维将彻底改变运维的现有体系，并将极大丰富和完善传统运维，提高运维效率。
目前市面上与运维相关的书籍更多的是介绍某个单一技术的运维方法，少有对智能运维进行全面介绍的书籍，因此，我们觉得非常有必要梳理编写一本大数据场景下的智能运维技术的书籍，全面完整地为读者介绍智能运维的技术体系，以及在大企业的运维实践经验，让读者更加了解运维的技术方向，在实践中能够有所借鉴。同时，也能帮助运维工程师在一定程度上了解机器学习的常见算法模型，以及如何将它们应用到运维工作中。
读者对象
本书面向的读者主要包括：
○运维工程师
○运维开发工程师
○运维架构师
○大数据工程师
○对运维和大数据，以及AIOps感兴趣的工程师
如何阅读这本书
本书主要分4篇：第1篇运维发展史，重点阐述当前运维的发展现状及面临的技术挑战。第2篇智能运维基础设施，重点讲述大数据场景下的数据存储、大数据处理和分析的方法与经验，以及海量数据多维度多指标的处理分析技术。第3篇智能运维技术详解，重点关注在新时期大数据时代下智能化的运维技术，包括数据聚合与关联、数据异常点检测、故障诊断和分析、趋势预测算法；第4篇技术案例详解，为大家梳理了通过开源框架ELK快速构建智能监控系统的整体方案，还将分享微博平台和微博广告两个不同业务场景下智能监控系统的技术实践。
具体而言，每篇和章节的主要内容如下：
第1篇 开门见山：运维发展史
○第1章运维现状，主要介绍运维职责、传统运维、运维分类等，我们将从运维发展的四个阶段：人工、工具和自动化、平台化、智能化来介绍运维的发展现状。
○第2章智能运维，主要介绍运维面临的挑战，传统运维在海量数据存储、分析、处理，多维度多指标及复杂业务等方面都有一定的局限性，随着运维新时代的到来，智能运维（AIOps）将为运维带来新的机会。
第2篇 站在巨人肩上：智能运维基础设施
○第3章开源数据采集技术，重点介绍Filebeat、Logstash等开源数据采集工具。
○第4章分布式消息队列，重点介绍以Kafka为代表的分布式消息队列及相关技术。
○第5章大数据存储技术，重点介绍大数据的存储相关技术，这也是大数据场景下的智能运维基础。
○第6章大规模数据离线计算分析，通过大数据ETL技术、Hadoop技术生态讨论在大数据场景下如何进行离线计算和分析。
○第7章实时计算框架，重点介绍在实时流计算方面的相关技术和框架，将探讨如何在监控系统中选择和使用实时计算框架。
○第8章时序数据分析框架，实时监控系统处理的是时序数据，本章介绍常见的时序数据分析框架及使用方法。
○第9章机器学习框架，智能化是运维、大数据和AI的结合，本章简单介绍机器学习框架，并以TensorFlow为例介绍如何进行模型训练和实践。
第3篇 运维新时代：智能运维技术详解
○第10章数据聚合与关联技术，在数据聚合方面讨论聚合方法、多维度数据聚合技巧，以及如何降低维度；在数据关联方面介绍如何在实时流场景下进行时序数据的关联。
○第11章数据异常点检测技术，本章结合运维面临的如异常点检测、动态阈值等常见问题，共同讨论解决这些问题的一些相关模型和算法。
○第12章故障诊断和分析策略，故障诊断是智能运维的一个很重要的研究方向，本章讨论智能运维在故障诊断、决策树模型、关联分析等方面的策略和模型。
○第13章趋势预测算法，主要介绍走势/趋势预测方面的常见模型和方法，包括ARIMA及基于机器学习的LSTM预测技术。
第4篇 智能运维架构实践：技术案例详解
○第14章快速构建日志监控系统，以ELK为例介绍如何使用开源框架快速搭建日志监控系统。
○第15章微博广告智能监控系统，全面介绍微博广告智能监控系统架构和设计原理。
○第16章微博平台通用监控系统，以微博平台监控系统为例，全面介绍通用监控系统的设计思路和具体架构。
需要注意的是，本文提到的智能运维即指AIOps，后续篇章将不再进行说明和区分。
勘误和支持
由于笔者的水平有限，编写时间仓促，同时本书在创作过程中参考了大量的国内外技术，并结合实践经验进行了系统性总结。由于技术的发展非常迅速，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。
智能运维技术在发生着翻天覆地的变化，我们希望更多的人能参与到这个过程中，共同推动智能运维技术的普及，欢迎通过微信或者邮件与我们进行讨论。你可以通过微信justAStriver、微博@AndrewPD或者电子邮件contact@andrewpd.com联系到我们，期待能够得到你们的真挚反馈，在技术之路上互勉共进。
特别致谢
我们花费了大量的时间总结智能运维方面的技术并整理成书，在此非常感谢微博广告基础架构团队的各位同事，尤其感谢车亚强、刘俊、陆松林、王莉、朱伟（按姓氏拼音排序）等人的辛勤付出，他们在工作之余，挤出宝贵的时间为本书贡献了知识，共同完成了本书部分章节的内容梳理。感谢车亚强在实时流计算的基本概念和关键技术方面，尤其是对分布式消息队列和 Spark 相关技术贡献的内容；感谢刘俊对智能运维的全面介绍，以及在故障诊断技术方面的贡献，同时结合微博平台的应用场景整理了通用监控系统的设计方案；感谢陆松林在分布式存储和离线计算方面提供的案例；感谢王莉在预估模型及异常点检测模型方面的研究；感谢朱伟在运维及智能运维相关技术上的研究和内容贡献。
感谢李东升的大力支持和鼓励，感谢微博广告团队的各位同事、朋友的支持和帮助。
感谢张志强和TimYang两位老大抽出宝贵时间为本书写序，感谢裴丹博士、王鹏云、梁定安、饶琛琳、钟华、陈晓峰、陆沛等业界朋友，感谢大家一起推动智能运维行业的普及和发展。
感谢电子工业出版社的编辑张春雨，他的敬业精神令我由衷敬佩，他的反馈、建议、鼓励和帮助引导我们克服诸多困难完成全部书稿。
在此特别感谢我的父母对我的培养，感谢我的太太Kathy长期以来对我的默默支持，感谢我刚满1岁的女儿小洋葱，因为工作和写作牺牲了很多陪伴她的时间。
技术交流
智能运维技术热潮刚刚开始，希望读者朋友能够跟我们一起多多交流，共同推动中国智能运维技术的发展。你可以通过以下方式联系到我们。（1）微信：justAStriver（2）微博：@AndrewPD（3）GitHub:https://github.com/justastriver（4）邮箱：contact@andrewpd.com第1篇开门见山：运维发展史中国互联网从20世纪90年代开始形成，随即进入了快速发展阶段。第一阶段是以新浪、搜狐和网易为代表的门户网站时期，解决了信息尤其是新闻信息的传播问题。第二阶段是以腾讯、百度和阿里巴巴为代表的科技型时代，解决了社交、信息获取及电商等需求问题。第三阶段进入一个新的时期，从直播、网红到短视频类公司，以及人工智能公司的兴起，足以说明要解决的是心理需求。短短二十年，中国互联网发生了翻天覆地的变化，网民数量已经增长到9亿，其中使用手机的用户量已经达到7亿，中国也被称为具有全球最大消费能力的国家，很多企业只要做好中国市场，就能与其他做全球市场的企业比肩。科技的进步需要技术的支撑，运维技术也在不断地发生着变化。运维的技术体系伴随着互联网的发展而愈加完善，从最开始的纯人工运维到脚本和开源工具的使用，再到平台建设，运维也紧跟时代的步伐，逐渐向智能化方向发展，通过应用机器学习的一些算法和模型将极大简化运维对数据的理解，大幅度提升效率。与此同时，运维工作也面临着非常大的挑战，在大数据场景下信息过载、多维度和更加复杂的业务环境，以及故障的定位、检测等工作，都已经超过了单凭人工能够完成的极限，新的技术需要被引进和普及。近年来，人工智能技术备受关注，开始将AI引入IT运维领域，AIOps的概念由此应运而生。Gartner的报告宣称，到2020年，将近50%的企业将会在他们的业务和IT运维方面采用AIOps，智能化已是大势所趋。本篇主要展现运维的发展历史和经历的不同历史阶段，以及运维工作的现状。本篇主要分两个章节：○第1章 运维现状○第2章 智能运维第1章运维现状1.1 运维工程1.1.1 认识运维
运维，通常指IT运维（IT Operations），是指通过一系列步骤和方法，管理与维护线上服务（Online Service）或者产品（Product）的过程。运维有着非常广泛的定义，在不同的公司不同的阶段代表不同的职责与定位，没有一个统一的标准。尤其是随着互联网的发展，运维的含义也在逐渐互联网化。互联网运维通常属于技术部门，与研发、测试、系统管理同为互联网产品的技术支撑，这种划分在国内和国外以及大小公司之间都会多少有一些不同。
运维的重点在于系统运行的各种环境，从机房、网络、存储、物理机、虚拟机这些基础的架构，到数据库、中间件平台、云平台、大数据平台，偏重的也不是编程，而是对这类平台的使用和管理。运维的水平可以成为衡量一个公司（IT公司）技术实力的标准。
运维工程师（Operation Engineer），是指从事运维工作的工程师。运维工程师的工作范围非常广泛，包括服务器购买、租用和上架等基本管理，调整网络设备的配置管理和部署，服务器操作系统安装调试，测试环境和生产环境的初始化与维护，代码部署和管理（Git和SVN等），设计和部署线上服务的监控与报警，服务安全性检测（防止漏洞和攻击），数据库管理和调优等。在大型公司中，运维工程师根据工作内容被细化为网站运维、系统运维、网络运维、数据库运维[1]（DBA）、IT运维、运维开发（DevOps）、运维安全等方向。
运维的工作内容决定了对运维工程师的要求会非常高，运维工程师需要对服务器资源（CPU、内存、磁盘、网络IO等）非常了解，对Linux系统和常见的开源框架、工具非常熟悉，因此在运维工程师中更容易诞生架构师，因为他们知道如何优化服务、如何使得资源利用最大化。[2]
运维工程在国内也被称作SRE（Site Reliability Engineering，来自Google），直接翻译为网站可用性工程。SRE工程师需要具备算法、数据结构、编程能力、网络编程、分布式系统、可扩展架构、故障排除等各方面技能，其核心工作包括容量规划与实施、服务集群维护、系统容错管理、负载均衡、监控系统以及值班等，最终为产品上线后服务的稳定性负责，但是不负责具体的机器运维。
SRE工程师的首要工作任务是保障SLA（Service-Level Agreement，服务等级协议），它定义了对服务有效性的保障，比如对故障解决时间、服务超时等的保障。根据这个协议标准可以定义系统的可用性（Availability），这里需要掌握如下几个衡量指标。
1.平均故障间隔时间（MTBF）
平均故障间隔时间（MTBF,Mean Time Between Failure），指相邻两次故障之间的平均工作时间。MTBF通常是衡量一个产品可靠性的指标，这个间隔时间越短说明系统可靠性越差。
2.平均修复时间（MTTR）
平均修复时间（MTTR,Mean Time To Repair），指产品由故障状态转为工作状态时修复时间的平均值，即故障修复所需要的平均时间。MTTR值越低说明故障修复越及时。
3.可用性（Availability）
可用性是系统架构设计中很重要的衡量指标。根据 GB/T3187—97对可用性的定义，可用性是指在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。它是产品可靠性、维修性和维修保障性的综合反映，如公式（1-1）所示。
业界一般通过N个9来对可用性进行量化。如表1-1所示为对可用性的量化及描述。表1-1 系统可用性量化指标续表
可以看出，当系统可用性超过3个9时，全年停机状态持续时间低于8.8小时，此时一般可以称作高可用性系统，可用性越高，对系统的设计要求就越高。需要注意的是，在分布式系统中，可用性和性能应该遵循CAP原则，即数据一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）三者通常只能满足其中两者，无法兼得。1.1.2 主要职责
运维的主要职责是在产品生命周期的各个阶段，维护系统的稳定性。运维的职责覆盖了产品从设计到发布、运行维护、变更升级及至下线的生命周期，在产品生产环境各个阶段的职责也不同，如表1-2所示。表1-2 运维在产品研发的生命周期中的主要职责
可以看出，运维工作贯穿于产品研发的各个环节。因此，运维工程师的日常工作主要包括：
○产品技术方案评估。
○资源预估、申请和管理。
○环境部署、环境准备。
○产品上线、下线及回滚，服务在线发布/升级产品。
○监控线上的服务质量。
○响应异常/处理突发故障。
○和相应产品线的研发和测试团队协调处理产品问题。
○与产品、技术、测试等团队沟通协作。
○对系统实时数据进行分析。
○建立工具或平台，保障系统的稳定性和可靠性。1.1.3 运维技术
在产品的整个生命周期中运维工作重要而广泛，但运维工程师的职责不局限于这部分工作，还需要总结工作中遇到的问题，抽取出相关的技术方向，研发相关的工具和平台，以支持/优化业务的发展并提高运维的效率。
运维工程师所需的技术体系根据其专业方向而异，但对计算机系统架构、操作系统、网络技术的掌握是基本要求。例如，可能需要熟练掌握 Linux 操作系统的使用，熟练使用各种脚本工具来处理日常工作任务，精通TCP/IP协议栈以排查一个大规模网络系统中的流量异常问题等。更进一步的，需要形成一套软件可运维性方面的经验，以此作为后续工作的指导。
一个运维工程师在初期阶段的目的是掌握、维护一套系统所需的所有软硬件知识和经验。在进阶阶段需要能够设计开发一套基础的体系软件，以支撑业务系统的稳定可靠运行，即开发服务于软件的软件，以支持更大规模的业务系统，提高运维生产力。在最高阶段要能反作用于软件系统的构建和运行阶段，使得系统从诞生阶段起即具有天然的可运维性，以最大化系统的生产力，同时最小化对外部支撑资源的依赖。
运维以技术为基础，通过技术保障产品提供更高质量的服务。运维工作的职责及在业务中的位置决定了运维工程师需要具备更加广博的知识和深入的技术能力，需要掌握的技术非常广泛，表1-3中列出了一些运维涉及的常见技术和框架。表1-3 运维涉及的常见技术和框架1.2 运维发展历程
伴随着互联网、移动互联网的发展，运维的发展大致经历了如下四个重要阶段。1.2.1 人工阶段
早期运维处于人工阶段，这个时候的运维是一个通称，负责从机房、服务器选型，软硬件初始化，服务上下线，配置监控，盯监控等，运维和开发之间没有太明确的分工，基本是遇到什么问题解决什么问题。在这个阶段，因为服务器少、业务需求简单，只需要少数几个运维工程师就能完成运维工作，运维也基本不会成为企业发展的瓶颈。1.2.2 工具和自动化阶段
通过人工维护和管理的方式，比较适合简单的业务，随着IT尤其是互联网的迅速发展，企业所承担的业务愈发复杂，运维也进入了第二阶段，即工具和自动化阶段。为了提升运维工作效率，简化操作流程，运维工程师开始将部分运维操作及重复性工作流程编写成脚本自动执行。
工具的产生是运维自动化的一个典型的标志，尤其是开源项目的逐渐兴起，大量工具被开源，很多项目都可以在GitHub上找到。随着容器技术的兴起，许多新的专门运行容器的Linux发行版本也出现了。Docker及相关虚拟化技术的不断发展、K8s（Kubernetes，自动化容器管理工具，具备集群管理、任务调度等强大的功能）等技术的发展、助力云服务（Cloud，包括私有云、公有云）的快速发展，也进一步为运维自动化带来了极大的便利。
在工具和自动化阶段，运维工程师有一部分掌握了一定的开发能力，将日常的工作通过自动执行程序来完成，以替代人工，效率也逐渐比单纯人工运维更高，同时出错的概率逐渐降低。此时已经有掌握Python、shell等开发语言和工具的运维工程师逐渐转向运维开发的角色。1.2.3 平台化阶段
在平台化阶段前，脚本和工具是分散的，不易管理，同时也需要人工干预，随着业务变得更加复杂，对大量脚本的管理是低效和复杂的。之后，将自动化脚本和工具进行整合，从系统层面构建更加易用和高效的运维管理工具，已经成为趋势，这也就是运维平台化。
围绕开源工具、开源平台，大中型企业开始结合业务构建自己的运维平台，包括监控平台、报警平台和自动化平台等，这些平台在一定程度上提高了产品开发效率和测试效率，降低了运维成本，并且降低了系统出风险的概率，提高了系统可用性。
在表1-4中简单描述了企业围绕开源框架构建运维体系的各类平台。表1-4 运维平台示例
可以看出，具有平台化思想的开源工具几乎覆盖了运维的全部维度，从监控系统、报警系统到自动化平台都有非常优秀的开源技术框架。1.2.4 智能运维阶段
这个阶段是智能化的，当基础设施固定下来后，运维模式最终也会固定下来，这些模式会把可用性、扩容等场景在内的诸多运维方案包含进来，把开发平滑地加入运维架构。AIOps （Algorithmic IT Operations）最早由Gartner定义为采用人工智能算法（AI和机器学习），利用机器解决已知的问题和潜在的运维问题的一种技术解决方案。这里值得注意的是，根据 Gartner定义，AIOps中的AI并不是Artificial Intelligence（人工智能），而是广义的算法。本书中也将遵从此定义，并且不严格区分智能运维与AIOps。
AIOps 使用分析理论和机器学习等方法，分析和处理各种操作工具、服务和设备产生的大量数据。它能够自动发现问题，并且能够实时对问题做出反应。AIOps 建立在大数据与机器学习（Machine Learning）基础之上，如图1-1所示。图1-1 基于大数据与机器学习的AIOps
举一个简单的例子。通常的报警策略是设置一个阈值范围（上、下界），当某个指标超出这个阈值范围时，则触发报警。这也是最直接、最简便的办法。然而，对于一些特定场景下的报警，设置可能没有这么简单。如图1-2所示是微博广告某产品某天的广告曝光次数走势图，从图中可以看出，每天早上4点到6点达到一天的最低，上午将近11点达到一天的最高。如果依然按照固定的阈值设置报警是非常不准确的，我们需要通过历史数据智能化地拟合出一条趋势线，以这条线的上、下界一定范围作为动态的报警阈值，以达到更加准确的报警。
另外，智能运维可以被用于故障分析，以快速定位问题，降低企业的损失。在AI中我们使用到的各类算法，比如基于指数平滑的二次平滑、三次平滑算法，基于 ARIMA 的算法，基于深度学习的前馈神经网络、循环神经网络（RNN）算法等，已经比较成熟，并大量使用在其他研究领域，比如图形图像处理、语音识别等领域。所以，在算法上，我们在很早之前就应该具备了这方面的理论基础。图1-2 微博广告某产品某天的广告曝光次数走势图
在计算能力上，目前我们看到，基于大数据技术的数据处理能力已经足够，Hadoop、Spark等生态，包括时序数据的处理能力，都已经能够支撑智能化的复杂计算场景。
就目前来看，国内的百度、搜狗、宜信、阿里巴巴、微博等都已经探索尝试了 AIOps，并且取得了不错的收益。在2017年 InfoQ 举办的 QCon 全球架构大会上，已经有不少与 AIOps相关的议题，感兴趣的读者可以关注。1.3 运维现状1.3.1 故障频发
快速解决故障、降低故障率、不断提高系统可用性是运维的非常关键的职责，然而在大数据场景下，系统越来越复杂，系统维护成本越来越高。Gartner Group 有一个调查显示，在 IT项目经常出现的问题中，源自技术或产品（包括硬件、软件、网络、电力失常及天灾等）的问题只占20%，但流程失误方面却占40%，人员疏失方面也占到了40%。这些年来，企业通过自动化运维平台，以及DevOps等协作理念，逐步解决了Gartner Group提到的与流程失误和人员疏失相关的80%的问题，但企业系统故障带来的损失也是非常大的。
表1-5统计了在2015年到2017年间，国内外知名互联网企业出现的故障。可以看出，即使是顶级的企业，也面临着各类故障导致的用户流失、财产损失等巨大的风险。表1-5 国内外知名互联网企业故障列表（部分）1.3.2 系统复杂性
当前的IT项目基础设施环境与5年前已经无法同日而语，更不用说10年前了。近几年，随着云计算、微服务等技术的流行，以及互联网业务的迅速发展，运维人员要关注的服务数量也呈现指数级增长，自动化运维虽然提升了效率，解决了一部分问题，但也遇到了新的难题，比如面对繁多的报警信息，运维人员应该如何处理；当故障发生时，又如何能够迅速定位问题。
系统的复杂性是业务复杂性的结果，我们可能无法直接评估当前互联网企业的系统有多复杂，但可以从客观数据反映出来。
从代码量角度看，Linus Torvalds最初发布的Linux内核版本源码大概1万行，而随着操作系统的发展，当前Linux内核源码在千万行级别，完整的Linux操作系统的代码量过亿行。2015年Google披露全部代码量大概为20亿行，按Google工程师每天编写150行代码估算，每天新增约百万行代码；国内一线企业的代码量也达到10亿行级别。这样庞大的代码量，从侧面反映了系统的复杂性。
从产品和业务角度看，仅仅微博广告系统中的业务监控指标就已经超过10万个，微博的监控指标量达百万级，这样量级的背后是一套非常庞大的业务系统支撑。BAT（百度、阿里巴巴、腾讯）这样的一线互联网企业，产品线非常多，系统就更加庞大了。如图1-3所示是百度首页展示的一部分产品列表，全部产品超过105个。图1-3 百度产品大全（部分）
如图1-4所示是某云服务平台包括的产品列表，有超过100个复杂的产品服务。这样庞大的产品系列背后的业务逻辑会非常复杂，对系统稳定性有非常苛刻的要求。图1-4 某云服务平台包括的产品列表（部分）1.3.3 大数据环境
随着大数据政策环境和技术手段的不断完善，大数据行业应用持续升温，中国企业级大数据市场进入了快速发展时期。互联网、电信、金融等开始实际部署大数据平台并付诸实践，带动了软件、硬件和服务市场的快速发展。
中国信息通信研究院公布的《中国大数据发展调查报告（2017）》显示，2016年约70%的企业拥有的数据资源总量在50～500TB之间，18.4%的企业数据量在500TB以上，与2015年相比，企业资源总量呈增长趋势。
数据规模的增大，一方面反映了系统的复杂程度；另一方面也反映了监控系统、自动化系统等运维平台的复杂程度。在大数据场景下，运维面临的主要挑战有以下几个方面。
1.数据采集
数据采集是大数据分析处理的基石，其核心一是要保证数据的完整性；二是要保证数据的准确性；三是要保证数据的实效性。数据完整性要求采集系统能够尽可能搜集到足够多和完整的信息，在采集过程及预处理过程中都不能丢数据。数据准确性要求在数据采集过程中，不能因为预处理而导致数据不一致，影响后续的分析和决策。数据实效性一方面要求数据采集要做到实时或者准实时，采集系统导致的延时率尽可能低，性能尽可能高；另一方面要求在数据预处理阶段，保留数据尤其是时序数据时间效应。这里的时序数据时间效应是指某个指标以某个固定时间间隔的波动变化情况，这个波动在一定程度上反映出系统的运行状态，数据采集器要在系统承载能力允许的前提下缩小时间间隔。比如对于请求量的走势，采集器可以1秒、5秒、15秒甚至1分钟采集一次数据，这样的时间间隔会带来不同的计算误差，最理想的情况是时间间隔越小越好，但带来的问题是数据规模的成倍增长，以及对后续数据分析的极大挑战。
2.数据存储
目前大数据的原始数据及数据仓库存储介质一般在HDFS上，为了提升数据分析能力，部分数据也存储在HBase、Hive、Redis等集群上。
各个业务系统不断在产生和制造大量的数据，数据被分析和处理再加工再存储，在每个环节数据都会被复制，一般情况下，原始数据规模最大，越接近数据业务分析层，数据规模越小。
如表1-6所示是微博广告某产品线2016年数据仓库各层的存储规模。表1-6 微博广告某产品线2016年数据仓库各层的存储规模
如表1-7所示是微博广告某产品线存储1.5年总体数据规模。表1-7 微博广告某产品线存储1.5年总体数据规模续表
可以看出，数据存储规模是一个非常大的挑战。其中为了保证数据的可用性，一般都会有至少3个数据副本（设置HDFS副本数是为了保证数据可用性），同时为了节约存储资源，通常采用特定的数据压缩算法来降低存储量。
3.分析和建模
数据分析和建模体现在数据集的大规模计算上，模型的训练是非常消耗资源的，数据需要在不同的计算节点之间进行复制和传播，都要耗用存储资源和网络带宽，而对数据的处理则需要耗用CPU和内存资源。1.4 本章小结
在大规模、复杂架构的催生下，运维技术不断变化和发展。自动化运维被推到一个新的高度，给传统企业带来了福音，给基础运维带来了巨大的挑战与机遇，同时也给越来越多的企业带来了新的抉择；开源技术的飞跃发展、脚本语言的进化等，也给运维行业带来了革命性的影响。1.5 参考文献
[1]DevOps维基百科定义：https://en.wikipedia.org/wiki/DevOps
[2]SRE维基百科定义：https://en.wikipedia.org/wiki/Site_reliability_engineering第2章智能运维
得益于IT外包服务的发达，现在的运维已经不包括搬机器上架、接网线、安装操作系统等基础工作，运维人员一般会从一台已安装好指定版本的操作系统、分配好IP地址和账号的服务器入手，工作范围大致包括：服务器管理（操作系统层面，比如重启、下线）、软件包管理、代码上下线、日志管理和分析、监控（区分系统、业务）和告警、流量管理（分发、转移、降级、限流等），以及一些日常的优化、故障排查等。
随着业务的发展、服务器规模的扩大，以及云化（公有云和混合云）、虚拟化的逐步落实，运维工作就扩展到了容量管理、弹性（自动化）扩缩容、安全管理，以及（引入各种容器、开源框架带来的复杂度提高而导致的）故障分析和定位等范围。
听上去每一类工作都不简单。不过，好在这些领域都有成熟的解决方案、开源软件和系统，运维工作的重点就是如何应用好这些工具来解决问题。
传统的运维工作经过不断发展（服务器规模的不断扩大），大致经历了人工、工具和自动化、平台化和智能运维（AIOps）几个阶段。如前文所述，这里的AIOps不是指Artificial Intelligence for IT [1]Operations，而是指Algorithmic IT Operations（基于Gartner的定义标准）。
基于算法的IT运维，能利用数据和算法提高运维的自动化程度和效率，比如将其用于告警收敛和合并、Root分析、关联分析、容量评估、自动扩缩容等运维工作中。
在Monitoring（监控）、Service Desk（服务台）、Automation（自动化）之上，利用大数据和机器学习持续优化，用机器智能扩展人类的能力极限，这就是智能运维的实质含义。
智能运维具体的落地方式，各团队也都在摸索中，较早见效的是在异常检测、故障分析和定位（有赖于业务系统标准化的推进）等方面的应用，后面的章节会具体涉及。智能运维平台逻辑架构如图2-1所示。
试读结束[说明：试读内容隐藏了图片]