传统架构云化后的运维，维护的是什么？
【作者】昆仑银行 许中华
背景
在云时代我们完全看不到任何物理设备，也不再关心硬件的稳定性和可靠性，因为当我们的硬件发生故障时，业务会第一时间切换到其他的节点，甚至切换到其他的数据中心，这样我们的硬件维修完全可以等到方便的时候再进行。运维自动化是整个云运维的核心。要面对成千上万台的服务器，产生的运维已经是人工方式不可能完成的任务，这就需要一整套高效自动化的运维管理工具，来帮我们实现运维的自动化。当运维的自动化程度越来越高的时候，我们会发现其实云运维维护的是代码，而传统运维维护的是硬件。最后，云运维对我们维护能力的要求也越来越高，我们不但要掌握操作系统，还要不停学习各种云计算相关的知识和理论，还要掌握一些开源的工具，同时还要具备开发定制的能力，要不停的去开发定制自动化的运维工具和脚本。
一、现状和面临的挑战
传统的IT架构使用了这么多年，所有的监控设备以及网络架构都是基于此打造，那么在传统架构虚拟化、云化后的今天，如何针对虚拟化、云计算的环境如IAAS、PAAS进行运维？
传统监控系统主要是基于传统的环境构建。主要是针对基础的硬件设备、业务系统的监控，对于虚拟化环境的覆盖是不足甚至可以说是零覆盖的，特别是在虚拟化技术引入之后，每台宿主机里面的众多虚拟机怎么去运维？众多的容器 、微服务 、APP怎么运维 ?如何监控是云化后运维监控面临的挑战。
当前主要面临的问题：
1.虚拟机配置变化更快，数据不准确，很难做到及时更新。
配置变化更频繁，因此对其配置状态的跟踪更复杂，整个系统范围内的资产信息更难掌握，运用老套的统计办法不及时也不准确，耗费人力、物力。
2.容量性能评估难，难以有效分配资源。
虚拟机不同于物理机，一台宿主机上的各个虚机之间的关系是即争用又共享，虚拟机对于CPU、内存不仅仅是占用、很大一部分是共享的关系。对此特殊的分配机制，传统的系统级CPU、内存的占用已失去绝对指导意义，并不能完全代表虚拟机是否存在瓶颈。同样的道理，难以判断物理服务器资源是否得到了充分利用、是否有必要优化、虚拟机密度是否恰当，从而导致多数组织内部存在较广泛的资源闲置情况。
3.管理缺乏标准和规范
虚拟化在整个IT系统构建中占的位置越来越重要，但与操作系统相比，IT系统级的加固和检査机制相对薄弱，成熟度及普及度都不高，存在系统缺陷、安全漏洞、管理不规范等薄弱环节，容易成为新的短板现象。
4.系统状态边界化模糊，难以准确评估状态。
云计算环境涉及IT基础硬件、操作系统以及业务系统等，传统的设备边界不再那么清晰，承载的VM对资源既共享又竞争，所以系统处于不断地动态调整中，故障域的耦合更加紧密，针对问题根源的判断更加困难。
5.容器
由于不需要为每个容器加载操作系统和内核，因此与传统的虚拟化环境相比，容器化环境能够在给定数量的基础架构内实现更高的工作负载密度。因此，在整个生产环境中创建、监视和销毁的组件需求总量呈指数级增长，从而显著增加了基于容器的管理环境的复杂性。Docker的生态系统复杂多变。在过去几年中，第三方工具和服务大量出现，帮助开发人员在开发过程中部署、配置和管理他们的容器化工作流程。基于开源技术，这些工具和服务的变化之快以及新文档的数量之多，使构建稳定的技术栈以实现在生产中运行容器变得充满挑战。容器的主要优点之一就在于它们是可移植的——一个应用程序，其所有的依赖关系可以捆绑到一个独立于Linux内核、平台分布或部署模型的主机版本的单个容器中。因此利用容器使应用程序跨不同基础设施需要的不仅仅是一个用于运输代码的标准化单元，它还需要基础设施服务，包括：
运行Docker容器的主机（CPU、内存、存储和网络连接），包括在本地以及云上运行的虚拟机 或物理机器；协调好端口映射或软件定义的网络，使不同主机上的容器能够相互通信；向Internet提供负载均衡器服务；DNS，通常用于实现服务发现；集成的健康检查，确保应对请求的使用的都是健康的容器服务；某些事件触发执行操作时的应对措施，例如在主机发生故障后重新启动新容器，确保可用的正常容器始终维持一个固定的数量，或者创建新主机和容器以响应增加的负载；通过现有容器创建新容器来扩展服务；借助存储快照和备份功能以备份状态容器，从而进行灾难恢复；
微服务是一系列职责单一、细粒度的服务，是将我们的业务进行拆分为独立的服务单元，伸缩性好，耦合度低，不同的微服务可以用不同的语言开发，每一个服务处理的单一的业务。微服务可以划分为前端服务（也叫边缘服务）和后端服务（也叫中间服务），前端服务是对后端服务做必要的聚合和剪裁后暴露给外部不同的设备（PC、Phone等），所有的服务启动时都会到Eureka服务器进行注册，服务之间会有错综复杂的依赖关系。
二、云化架构采取的应对措施
计算和虚拟化环境缺乏有效深入的监控措施，导致管理被动，无法及时发现问题，无法有效分析问题，安全管理上缺乏对虚拟化环境的管理规范、手段及工具，安全短板问题较明显。
针对于以上几大问题，在云化后的运维，应该注重以下领域：
1、容量管理
容量管理分为容量优化和容量规划。容量优化关注优化资源配置，提高现有资源利用率。发现并回收低效、未使用的资源，以便合理调整虚拟机大小、回收闲置资源，在不影响性能的情况下优化整合率和虚拟设备密度。容量规划关注容量不足和超额配置情况，以提前规划资源扩容，指导采购，并规避资源风险。
（1） 业务处理量：反映在对外接口部分，主要评估响应时间要求内的最大并发能力， 由于对外接口可能提供的服务是多个，按实际场景分析最大和最小容量；典型的服务接入 如WEB 集群、 Web service（集群）、 socket 等；服务接入后一般交后台程序进行处理，处 理结果最终返回服务接入端，因此可以每个服务（交易）的响应时间作为容量评估的一个 参数，其反映的是后台程序的处理能力，表现的是一段时间内的服务通过量；处理量相关部分容量指标：交易量、TPS，系统响应时间、响应率。
（2） 业务承载量：承载能力相对静态，表示该应用系统能够容纳的数据量，在交易 型系统中，存量数据多少会影响服务处理的效率，进而影响处理能力，为了保障对外能力， 存量数据必然有所限制，比如数据库中存放的历史交易信息一定不能是无限制的；大部分 系统都有批处理，批处理大部分会读写文件或数据库，作为整体处理能力的一部分，批处 理也需要纳入容量管理范围，允许的批处理时间窗口内，能够处理的数据量就是容量管理 的一部分指标；承载量相关部分容量指标：最大用户数，数据保留周期，活动数量。
（3）业务容量指标对应的系统性能容量参数：无论业务承载量还是业务处理量，最终在系统上反映的，都是系统的软硬件配置、参数等实际对应值，从业务容量指标到系统容量指标的翻译非常困难，与各应用系统的复杂程度相关，主要的系统容量或性能指标包括：
A、网络性能及容量：带宽、网速；
B、网络设备：端口数、背板带宽等；
C、服务器：网卡、光纤卡、 CPU、内存、磁盘；
D、存储：IO、容量；
E、数据库：最大连接数、表空间；
F 、文件系统：空间、类型；
G、应用服务器（WAS、Weblogic）：连接池数量、 JVM 大小、端口连接数；
H、 Web 服务器：端口数
I、消息中间件（MQ）：队列深度
J、应用程序：处理速度
K、批处理：作业的窗口
2、闲置资源回收、调整虚拟比
由于云计算环境的资源共享和动态配置特性，云计算环境下的资源管理变得更加复杂难控，资源的惊人浪费和局部资源的紧张情况同时存在。如何判断充分利用这些资源，配置合理的虚拟设备比例是新环境下的运维能力的硬性要求。
3、配置及资产管理
运用专业的监控工具进行批量全面化的信息采样，收集虚拟化层面的所有信息（包含计算资源的信息、网络信息以及存储存储）。
具体包含：部署的 vSphere 版本、模板数量、 CPU 与内存使用情况、网卡数量、 HBA 卡数量、是否处于维护模式、是否打开了 vMotion 、启动运行时间、对应的 vSwitch 收集各种网络配置信息、 Datastore 的相关信息、 VM 配置信息、包括名称、 IP 地址、 CPU 预留、内存预留、内存 limit 、内存扩展预留、总的 CPU 请求、是否安装了 VMware Tools 等等。
4、安全及合规管理
在云计算环境中，有很多比较容易忽略的安全隐患，可能被恶意利用。而且云计算环境是一个高度动态的环境，一两次的检查工作并不能保证整个 IT 环境的持续合规，必须要高频的扫描检测才能减少安全风险。常见的安全检测策略：拒绝 MAC 被更改、确保密码复杂度、配置宿主机防火墙、配置 NTP 服务、设施 Shell 超时策略、不容许安装未签名的 VIB 、关闭 ESXi 与互联网的通信、补丁安装升级、集中保存 core dumps 日志等。
5、存储管理、对虚拟化主机、虚机、网络和存储计算资源的全面监控
全面将各个厂家的存储设备纳入存储监控进行统一管理，实时监控存储容量以及其他设备如光纤交换机的性能。可以对VMware虚拟机，虚拟机上安装的不同操作系统，操作系统上运行的各种应用和业务系统进行深度监控，及时发现IT系统的运行故障，降低企业在虚拟化和云计算过程中的风险。
6、容器和微服务管理
组织需要一种更便捷的方法来编排容器，以及管理多容器、多主机应用程序的底层基础架构服务。这对于具有微服务体系结构的应用程序尤为重要，例如，一个Web应用程序，包括一个容器集群运行Web服务器前端的多个实例的主机（故障转移和负载均衡）以及多个后端服务，是各自运行在不同的容器中的。搭建基于容器和微服务监控平台。
7、用户体验监控
App 性能监控是将 App运行时产生的性能数据进行获取及处理和分析, 通过平台发现应用对用户影响最大的性能问题并通过云端对性能数据进行存储、分析, 以邮件、微信方式推送。让行业经验沉淀成为一个完整的闭环, 使应用的性能可以得到持续的监控与提升。APP性能监控是模拟用户真实操作场景对APP在实际运行中的性能数据（响应耗时，数据流量，CPU/内存占用率等）进行持续性监控。
网站业务拨测是一种网络链路质量的测试手段。拨测，非常类似于爬虫，更准确地讲，非常类似于黑客控制“肉鸡”发起DDos攻击。这里的“肉鸡”，就是某个互联网服务的客户端，比如PC端、手机端。目的：探测各地区用户到各个服务接入点的链路状况，这样，服务调度系统就可以根据探测结果为用户提供最佳的接入点。
呼叫中心业务拨测，模拟用户的业务操作过程，获得完成业务的操作过程性能数据和操作结果数据。
8、APM监控
全称 Application Performance Management ， 提供分布式追踪功能。
被用于追踪、监控和诊断分布式系统，特别是使用微服务架构，云原生或容积技术。提供以下主要功能：
分布式追踪和上下文传输
应用、实例、服务性能指标分析
根源分析
应用拓扑分析
应用和服务依赖分析
慢服务检测
性能优化
9、统一日志管理和监控
日志监控可以采用大数据技术实现，大致可以分为两大模块：
离线数据处理：比如说电商、运营商出现的大批量的日志，可以由flume、sqoop或者其他路径，导入到HDFS中，然后经过数据清洗，使用Hive进行分析和处理，对于优化服务器资源等有很好的作用；
实时数据处理：对于有些业务需要，可能第二天或者更晚的时候进行分析无关紧要，但对于一些高频的金融交易来说，实时性就太重要了。
主要模块：日志收集模块、日志处理模块
主要工具：
Filebeat：Filebeat就是一个完美的替代者，它基于Go语言没有任何依赖，配置文件简单，格式明了，同时，filebeat比logstash更加轻量级，所以占用系统资源极少，非常适合安装在生产机器 。
kafka：消息缓冲队列，大数据处理中常用的缓冲队列，用于数据爆炸的时候，避免拖垮后续的处理逻辑，将消息先存放到队列中，延迟一定的时间进行处理。
Apache Flink：具有真正的流处理特性以及低延迟和高吞吐量流处理功能，非常适合CEP工作负载。
Spring boot：构建数据配置服务，方便用户配置自己的日志数据，比如邮件发给何人，短信发给何人，都可以自由指定。
zookeeper：数据配置中心，在本项目用途中，主要是用于配置数据的管理。
1：日志收集模块
在日志收集模块中，针对我们自身的业务，可以分为两大部分：
Nginx日志和数据库运行日志：首先是Nginx，作为业内比较强大的负责均衡工具，其性能比较优良，我们在日常的服务中，也是使用该工具来进行负载均衡的功能实现。对于Tomcat类型的服务，选择使用log4j内置的flume-appender方式来实现。对于收集到的日志，统一采用kafkaSink的方式，输送到后续的kafka中，以备后续的处理。
2：日志处理模块
对于收集到的日志的处理，我们采用的是Apache Flink工具，将其与kafka对接，对于收集到的每一条数据进行处理。
10、大胆尝试使用AIOPS
AIOPS可以实现历史数据分析 、 毛刺检测 、 指标预测 、 异常判定 。
通过海量数据源 （性能指标、日志、告警）、使用TensorFlow等成熟算法库、轻量化计算可以实现告警准确率提升到80%，告警覆盖率提升到95%、告警配置人力下降60%，一句话：降本增效体质。
AIOPS在深度上可以实现智能故障发现，更一步实现日志异常检测、告警压缩和关联、告警根因分析以及容量预测；在广度上让AIOPS在更多运维领域落地开花。
随着云的普及，IT环境表现出三个特征：规模更大，产生的数据更多 ；动态，云的弹性决定了IT环境是不断变化的 ；更复杂，从主机层面有物理机，虚拟机，云主机，容器等，从形态上有私有云、公有云、混合云等。越来越多的数据，复杂环境频繁的警报，大量重复工作，要求提升自动化水平，AIOps是解决这些问题的利器，使用AIOps只是时间问题。
三、总结
云化环境运维应该以交易监控和APM项目为抓手，以业务质量和客户体验为核心，以可管控、可视化、可度量为目标，从用户体验出发，建立端到端全链路监控、告警 投诉预警 客服联动形成完整闭环管理。在强化基础设施监控的基础上，补充和完善应用性能监控和业务质量监控能力，保障业务的稳定性和客户感知。引入自动化手段，封装标准模板，通过自动化配置打通CMDB、监控、告警数据流，实现一键批量创建监控、告警策略的功能，实现自动化提速；通过使用ETL工具如Kattle等开发抽取告警平台历史数据，最终装载到大数据分析平台中，进行多维度的数据分析，实现数据化赋能；建立丰富、多样、灵活的视图与报表，提供直观高效的巡检、定位工具，结合智能化手段提升监控预警能力，实现智能化增效。
原题：新信息时代面临的挑战及应对措施——传统IT架构面临云化后的运维挑战