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