职业探索-运维体系-运维对象的识别和应用场景-运维职责-建设运维基础平台事项-云运维

参考来源：
极客时间专栏：赵成的运维体系管理课
极客时间专栏：深入浅出云计算

来自蓝桥云课的岗位介绍，运维工程师：https://www.lanqiao.cn/employment/job-detail/10/

工作内容
负责计算机系统和网络平台服务的运维保障，参与并审核架构设计、安全规范设计等的合理性和可运维性；
负责保障产品或服务 7×24 小时稳定运行，及时响应和处理严重、复杂应用故障，参与突发事件管理；
开展系统问题跟踪，能够运用技术手段和工具进行复杂问题定位；
推动产品或服务整体框架升级和技术版本迭代，参与故障演练设计与实施，持续优化线上技术架构和各类技术的开发维护；
编写运维技术文档，协助完善运维制度和流程，持续优化运维实践。

运维对象的识别和应用场景

标准化的过程实际上就是对运维对象的识别和建模过程。形成统一的对象模型后，各方在统一的认识下展开有效协作，然后针对不同的运维对象，再抽取出它们所对应的运维场景，接下来才是运维场景的自动化实现。

总结一下标准化的套路：
第一步，识别对象；（它是什么东西）
第二步，识别对象属性；（从哪来，能吃吗）
第三步，识别对象关系；（它和其他东西是否可以搭配使用，大饼卷葱还要加酱）
第四步，识别对象场景。

从基础设施层面和应用层面应该识别出哪些运维对象。
第一步，识别实体对象，主要有服务器、网络、IDC、机柜、存储、配件等。

第二步，识别对象的属性，比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置（如 CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等；网络设备如交换机也会有厂商、型号、带宽等信息。

第三步，识别对象之间的关联关系，比如服务器所在的机柜，虚拟机所在的宿主机、机柜所在 IDC 等简单关系；复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系等，这些相对复杂一些，也就是我们常说的网络拓扑关系。

把以上信息梳理清楚，通过 ER 建模工具进行数据建模，再将以上的信息固化到 DB 中，一个资源层面的信息管理平台就基本成型了。(CMDB)

第四步，还是以服务器为例，我们针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等等。另外，可能还会有可视化和查询的场景，如拓扑关系的可视化和动态展示，交换机与服务器之间的级联关系、状态（正常 or 故障）的展示等，这样可以很直观地关注到资源节点的状态。（场景，操作场景）

应用层面的标准化

一个应用应该具备哪些基本的运维属性。

• 应用的元数据属性，也就是简单直接地描述一个应用的信息，如应用名、应用 Owner、所属业务、是否核心链路应用以及应用功能说明等，这里的关键是应用名；
• 应用代码属性，主要是编程语言及版本（决定了后续的构建方式），GitLab 地址；
• 应用部署模式，涉及到基础软件包，如语言包 Java、C++、Go 等；容器如 Tomcat、JBoss 等；
• 应用目录信息，如运维脚本目录、日志目录、应用包目录、临时目录等；
• 应用运行脚本，如启停脚本、健康监测脚本；
• 应用运行时的参数配置，如运行端口、Java 的 JVM 参数 GC 方式、新生代、老生代、永生代的堆内存大小配置等。

从应用属性的视角，应该是下面这样一个视图（简单示例，不完整）：

对于客户的交付场景中，项目资料的交接内容中，也可以根据这个应用属性，提供材料。

应用与外部的关系（三类）：

第一类是应用与基础设施的关系，包括应用与资源、应用与 VIP、应用与 DNS 等等的关系；
第二类是平行层面的应用与应用之间的关系，这里再细分下去就是应用服务或 API 与其它
应用服务和 API 的依赖关系。如果你有相关的经验，应该会联想到全链路这样的工具平台了，没错，这样的平台就是用来处理应用间关系管理的。
第三类是应用与各类基础组件之间的关系，比如应用与缓存，应用与消息、应用与 DB 等等之间的关系。

应用的运维场景。

这个就会比较多了，比如应用创建、持续集成、持续发布、扩容、缩容、监控等；再复杂点的比如容量评估、压测、限流降级等。

运维的职责是什么？

总结上面的过程，我们要做的事情，可以归纳为两步：
第一步是基础架构标准化，
第二步是基础架构服务化。

所以这个时候，运维必须要有意识去做的两件事情。

1. 参与制定基础架构标准，并强势地约束。在这里运维作为线上稳定的 Owner，发挥约束作用有可能会比业务架构师这样的角色更为有效。另外，由于历史原因或其他种种因素造成的已有架构标准不统一的问题，是需要开发和运维共同合作去改造的。这里面如何保持良好的协作，制定统一的路线图也是非常重要的。所以这里强制约束是一方面，同时也要提供工具化的手段来支持开发的改造，也就是下面这个动作。

2. 基础架构的服务化平台开发，目标是平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人。这个事情是驱动运维转型和改进的动力，也是运维能够深入了解架构组件细节的有效途径。同时，要注意到，如果不朝着服务化方向发展，运维将始终被拖累在这些基础组件的运维操作上。

建设运维基础管理平台的事项

第 1 步，把服务器、网络、IDC、机柜、存储、配件等这几大维度先定下来；
第 2 步，把这些硬件的属性确定下来，比如服务器就会有 SN 序列号、IP 地址、厂商、
硬件配置（如 CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等等；网络设备如交
换机也会有厂商、型号、带宽等等；
第 3 步，梳理以上信息之间的关联关系，或者叫拓扑关系。比如服务器所在机柜，虚拟
机所在的宿主机、机柜所在 IDC 等简单关系；复杂一点就会有核心交换机、汇聚交换
机、接入交换机以及机柜和服务器之间的级联关系；
第 3.5 步，在上面信息的梳理过程中肯定就会遇到一些规划问题，比如，IP 地址段的规
划，哪个网段用于 DB，哪个网段用于大数据、哪个网段用于业务应用等等，再比如同步
要做的还有哪些机柜用于做虚拟化宿主机、哪些机柜只放 DB 机器等。

以上信息梳理清楚，通过 ER 建模工具进行数据建模，再将以上的信息固化到 DB 中，一个
资源层面的信息管理平台就基本成型了。

第 4 步，基于这些信息进行流程规范的建设，比如服务器的上线、下线、维修、装机等流程。同时，流程过程中状态的变更要同步管理起来；

第 5 步，拓扑关系的可视化和动态展示，比如交换机与服务器之间的级联关系、状态（正常 or 故障）的展示等，这样可以很直观地关注到资源节点的状态。

至此，从资源维度的信息梳理，以及基于这些信息的平台和流程规范建设就算是基本成型了。

云端需要运维吗？

既然要谈运维，我们得先回答这个必要性的问题。许多人都觉得，因为云服务大多都具有了非常高的可靠性和自动化程度，所以在云时代，运维就不那么重要了，甚至是可以省略的事情了。

这种观点有意无意地散播，其实会造成一些负面的影响。开发者会容易轻视运维工作的重要性，忽略架构设计中运维友好性问题；而从事运维方向的工程师们，可能更会有点儿焦虑，甚至于担心未来的职业生涯。

但很显然，这是一种误解。云端当然需要运维，而且云上运维很重要。因为不管在什么样的运行环境下，运维的本质和需求都没有消失，一样要为业务保驾护航，要保证系统的正常运作、应对突发情况等等。

云时代的运维，正确的理解应该是这样的：云不但没有消灭运维，反而是助推了运维的发展。

这是因为，云的引入能够让我们在更高的层面去思考和解决问题。比如说，云端基础设施的存在，可以让运维从偏硬件服务器、偏物理机房的日常繁琐工作中解脱出来，更多地基于云在软件的层面，进行部署、监控、调整。而云上的高质量、高可用的服务，也能避免我们重
复建设，不用自己造轮子，也大大减轻了运维负担。

注意：底层的机房运维、基础架构运维仍然会继续存在（风、水、电），但会向头部的云供应商大规模集中。这属于云厂商的运维视角，是另一个宏大的话题，我们这里不多做讨论。

所以，云其实是提高了运维的效率，改变了运维的形态。

与此同时，由于云上运维的软件属性显著增强了，它就自然地和研发会有更强的融合。近期DevOps 理念和云原生热潮的兴起，就说明了这一点。许多工作，你慢慢地会分不清它究竟是属于运维还是研发，因为两者的界限正在模糊。

另外，由于云独有的一些特点，它也会带来一些新的运维工作。比如我们课程中一直在涉及
的成本控制，这也是云时代新运维所应当关注和包含的重要事项。因为云的成本消耗是动
态、时刻发生着的，这和传统运维中的各类实时监控的对象，在形态上非常接近。

所以，云端需要运维吗？答案已经不言而喻了。

云运维由哪些工作组成？

有了趁手的工具之后，我们下一个需要讨论的问题就是，云时代的运维具体有哪些重要的工
作呢？哪些是和传统运维一脉相承的事情，哪些又是在云环境下所特有的内容呢？

现在，我就和你一起来简单梳理一下。

【监控工作(监控指标、大屏联动报警)、定时备份、迁移、和云厂商的对接、运维操作的监控和审计】

首先，在云端，传统的运维工作仍然存在，其中包括你所熟知的监控、部署、升级、备份等
等。只是操作手段会有所不同，比如在云上，我们可以利用前面说到的命令行工具和资源模
板来进行部署。

监控一直是运维最核心的工作之一。几乎所有的云端服务都自带有一定的监控功能，默认提供了不少内置的维度指标和可视化图表，这些开箱即用的图表你要充分利用好，它们能够很好地帮助你了解相关服务的状态。

那么，如果自带的监控不够用怎么办？其实这些默认的统计监控的背后，往往都是由云的一个大型统一监控服务来支撑的，如 AWS 的 CloudWatch 和 Azure 的 Monitor 等等。你可以好好研究一下这类统一监控服务，通过它可以满足你更深度的自定义监控需求。

另外，这些你精心选择和设置的监控项，还能够和云上的仪表盘服务，以及报警服务联动，轻松实现运营监控的“大屏”和问题的实时报警。

这里我还想再多谈一谈备份。

备份是一个简单但又很容易被我们忽视的事项。即便是在云端，尽管云厂商已经做了许多如三副本之类的防护措施，但还是会存在出故障的可能，所以我们仍然需要做好备份，尤其是重要数据的备份。总之，我们在云上需要创造多层次的冗余，而备份在创造冗余方面也承担着重要的角色，有的时候，它会是我们的最后保障。

在 IaaS 的虚拟机层面做备份，你的得力助手会是镜像和快照。

镜像它可以用来恢复虚拟机；快照则是云磁盘级别对应的备份概念，它可以帮助你将某块磁盘某一时刻的状态进行封存和恢复，你还可以定期定时为一些重要磁盘自动生成快照。

注意：不要小看镜像和快照这样简单基础的操作，像创业公司严重事故(2018年热点新闻-删库跑路)，就完全可以通过简单的磁盘快照进行避免。因为快照的存储本身不依赖于云盘，这就是额外的冗余。

除了虚拟机和磁盘层面，文件层面的备份同样重要而有效。而且文件的备份最好还能以异地的方式来存储。云上的对象存储可以在这方面肩负重任，我在 PaaS 篇中会做专门讲解。

其次，你的运维工作中很可能包含迁移。

这是带有云端特色的运维任务，因为只要不是在云上创建的全新业务，传统业务在逐步上云的过程中一定会面临迁移工作。

迁移显然是非常大的一个话题，有些复杂的迁移项目，持续的时间可能长达几个月。这里我
想告诉你两点最核心的建议：

第一，在生产业务切换过来之前，一定要对云上的新架构、新方案进行充分而深入的POC 测试，不可操之过急。对于复杂场景，可能要通过不断地实践，才能够逐步进化出完善的云上解决方案。

第二，对于一些虚拟机、数据库等独立的软硬件单元，许多云厂商都提供了官方的迁移服务或工具，支持离线甚至在线迁移，妥善使用可以事半功倍。比如 AWS 的主机迁移服务 SMS（Server Migration Service）、数据库迁移服务 DMS（Database Migration Service）和阿里云的数据传输服务 DTS（Data Transmission Service）等。

所以，当你遇到一些迁移场景时，不妨先查一查云厂商是否有官方的支持。由于迁移类服务能够直接为厂商导流获客，所以云厂商一般都会比较重视，往往能给你提供相当好的用户体验。

再次，云上的运维会包含和云厂商进行对接的工作。

毕竟我们的大厦是建立在云厂商所提供的基础设施之上的。云虽然已经高度成熟，但作为一个高度复杂的系统，也总难免会有不按你所期望进行工作的时候，或者极为偶尔也会出些小Bug，这时和云厂商的对接渠道就显得尤为重要了。

所以，我们的运维团队中需要有相应的角色对云的工单机制，以及技术支持侧的对接方式了然于胸，以备不时之需。你也要熟读文档，要吃透云计算的许多特性，这样才能更准确地与客服沟通，更快地寻求到对口的帮助，最后解决好问题。

最后，云上运维会具有很强的管理属性。

这里的管理，指的不仅仅是对云上资源的管理，更要深入到流程和制度的管理层面。比如对于云资源的命名、开通、清理等日常操作的规范，各类云上安全的控制和最佳实践，所有云资源的负责人、所属资源组和权限体系等等。这些都需要有效的管理手段，才能避免资源在
云上的野蛮生长。

所以，高明的云上运维，既要为应用开发赋能，要足够高效，也要有适当的管理和约束。我们团队的组织架构和分工，最好也能够配合和适应这个需要。

好在云厂商也在不断推出和完善与云上管理相关的配套服务，比如说，Azure Policy 能够限定只有某类型号的资源可以被创建，还可以扫描和检查各种最佳实践是否得到了应用；再比如，AWS CloudTrail 能够对账户内的操作进行监控和审计。如果你的组织内用户（团队成员）较多，就值得好好探索研究一下这一类的云服务。

当然，管理层面还有一项重要事务，就是我们多次提到的成本管理。公司或团队中，应当有专人对成本进行监控和分析，以此提升每一位用户的成本意识。我自己曾使用的实践，是按月来组织资源的使用方进行成本消耗的回顾，分析资源使用的上升、下降趋势及其主要原因，同时还会检查月度账单明细，以杜绝成本浪费。