标签：服务 运维 系统 介绍 工作 监控 服务器

一、运维的主要工作内容

1.1 运维介绍

首先，对于运维人员来说，核心任务就是用尽各种手段保证业务系统的稳定性、可用性、安全性等。具体工作就是天天盯着系统、服务器或模块内的东西，查看日志、调整参数、性能调优、配置更改、开会讨论、响应需求等等。主要包括如下三个阶段：

• 产品发布前负责参与并审核架构设计的合理性和可运维性
• 产品发布阶段负责用自动化的技术或者平台确保产品可以高效的发布上线
• 产品运行维护阶段负责保障产品7*24H稳定运行

其次，现在的运维已经不是传统的机房运维，所有的问题都能在机房解决，在云时代，所有对物理设备的操作都变成了代码，IT异构网络环境日趋复杂，单靠之前的小工具很难去支撑我们的运维工作，比如：主机资源申请、创建、交付、运维以及最终的释放销毁的全生命周期管理，还有应用程序和支持软件的安装部署/交付和升级，集群性能负载均衡调配、服务器的批量脚本操作、数据库维护、主机的监控、运维日常工作的审计等等

原文链接：https://blog.csdn.net/xingyunguanjia/article/details/122922898

1.2 基础运维常见工作内容

服务监控技术：包括监控平台的研发、应用，服务监控准确性、实时性、全面性的保障

服务故障管理：包括服务的故障预案设计，预案的自动化执行，故障的总结并反馈到产品/系统的设计层面进行优化以提高产品的稳定性

服务容量管理：测量服务的容量，规划服务的机房建设，扩容、迁移等工作

服务性能优化：从各个方向，包括网络优化、操作系统优化、应用优化、客户端优化等，提高服务的性能和响应速度，改善用户体验

服务全局流量调度：接入服务的流量，根据容量和服务状态在各个机房间分配流量

服务安全保障：包括服务的访问安全、防攻击、权限控制等

服务自动发布部署：部署平台/工具的研发，及平台/工具的使用，做到安全、高效的发布服务

服务集群管理：包括服务的服务器管理、大规模集群管理等

服务成本优化：尽可能降低服务运行使用的资源，降低服务运行成本

数据库管理(DBA)：通过设计、开发和管理高性能数据库集群，使数据库服务更稳定、更高效、更易于管理

平台化的开发：类docker等平台的开发管理，及服务接入技术

二、运维的分类

1、应用运维(SRE)

　　应用运维负责线上服务的变更、服务状态监控、服务容灾和数据备份等工作，对服务进行例行排查、故障应急处理等工作

　　工作职责如下：设计评审、服务管理、资源管理、例行检查、预案管理、数据备份。

2、系统运维(SYS)

　　负责IDC、网络、CDN和基础服务的建设(LVS、NTP、DNS);

　　负责资产管理，服务器选型、交付和维修，网络建设、LVS负载均衡和SNAT建设

3、运维开发（DEV)

　　是给应用运维开发运维工具和运维平台的

　　主要包含的平台：工单系统、CMDB、监控系统、ELK日志系统、CI/CD、LDAP、FAQ、培训系统、OpenStack平台

4、数据库运维(DBA)

　　数据库运维负责数据存储方案设计、数据库表设计、索引设计和SQL优化，

　　对数据库进行变更、监控、备份、高可用设计等工作，详细的工作内容如下

　　设计评审、容量规划、数据备份与灾备、数据库监控、数据库安全、数据库高可用和性能优化

　　自动化系统建设、运维研发、运维平台、监控系统、自动化部署系统

5、运维安全(SEC)

　　运维安全负责网络、系统和业务等方面的安全加固工作

　　进行常规的安全扫描、渗透测试，进行安全工具和系统研发以及安全事件应急处理

　　工作内容如下：安全制度建立、安全培训、风险评估、安全建设、安全合规、应急响应。

三、Linux运维工作发展过程

1、手工管理阶段

　1)业务规模

　业务流量不大，服务器数量相对较少，系统复杂度不高。对于日常的业务管理操作，大家更多的是逐台登录服务器进行手工操作，属于各自为战。每个人都有自己的操作方式，缺少必要的操作标准、流程机制，比如业务目录环境都是各式各样的。

　2)工作职责

　早期的运维团队在人员较少的情况下，主要是进行数据中心建设、基础网络建设、服务器采购和服务器安装交付工作。几乎很少涉及线上服务的变更、监控、管理等工作。这个时候的运维团队更多的属于基础建设的角色，提供一个简单、可用的网络环境和系统环境即可。

2、工具批量操作阶段

1)业务规模

• 随着服务器规模、系统复杂度的增加，全人工的操作方式已经不能满足业务的快速发展需要。因此，运维人员逐渐开始使用批量化的操作工具，针对不同操作类型出现了不同的脚本程序。此时，虽然效率提升了一部分，但很快又遇到了瓶颈，操作的质量并没有太多的提升。

• 开始建立大量的流程规范，比如复查机制，先上线一台服务器观察10分钟后再继续后面的操作，一次升级完成后至少要观察20分钟等。这些主要还是靠人来监督和执行，但在实际过程中执行往往不到位，反而降低了工作效率。

2)工作职责

• 这个时候的运维团队还会承担一些服务器监控的工作，同时会负责LVS、Nginx等与业务逻辑无关的4/7层运维工作。这个时候服务变更更多的是逐台的手工操作，或者有一些简单批量脚本的出现。

• 监控的焦点更多的在服务器状态和资源使用情况上，对服务应用状态的监控几乎很少，监控更多的使用各种开源系统如Nagios、Cacti等。

3、平台管理阶段

　1)业务规模

　在这个阶段，我们决定开始建设运维平台，通过平台承载标准、流程，进而解放人力和提高质量。这个时候对服务的变更动作进行了抽象，形成了操作方法、服务目录环境、服务运行方式等统一的标准。通过平台来约束操作流程，如上面提到的上线一台服务器观察10分钟，程序的启停接口必须包括启动、停止、重载等。在平台中强制设定暂停检查点，在第一台服务器操作完成后，需要运维人员填写相应的检查项，然后才可以继续执行后续的部署动作。

　2)工作职责

• 由于业务规模和复杂度的持续增加，运维团队会逐渐划分为应用运维和系统运维两大块。应用运维开始接手线上业务，逐步开展服务监控梳理、数据备份以及服务变更的工作。随着对服务的深入，应用运维工程师有能力开始对服务进行一些简单的优化。

• 同时，为了应对每天大量的服务变更，我们也开始编写各类运维工具，针对某些特定的服务能够很方便的批量变更。随着业务规模的增大，基础设施由于容量规划不足或抵御风险能力较弱导致的故障也越来越多，迫使运维人员开始将更多的精力投入到多数据中心容灾、预案管理的方向上。

4、系统自调度阶段

1)工作环境

　　更大规模的服务数量、更复杂的服务关联关系、各个运维平台的林立，原有的将批量操作转化成平台操作的方式已经不再适合。需要对服务变更进行更高一层的抽象，将每一台服务器抽象成一个容器，由调度系统根据资源使用情况，将服务调度、部署到合适的服务器上。

　自动化完成与周边各个运维系统的联动，比如监控系统、日志系统、备份系统等。通过自调度系统，根据服务运行情况动态伸缩容量，能够自动化处理常见的服务故障。运维人员的工作也会前置到产品设计阶段，协助研发人员改造服务使其可以接入到自调度系统中。

2)工作职责

　　业务规模达到一定程度后，开源的监控系统在性能和功能方面，已经无法满足业务需求;大量的服务变更、复杂的服务关系，以前靠人工记录、工具变更的方式不管在效率还是准确性方面也都无法满足业务需求;在安全方面也出现了各种大大小小的事件，迫使我们投入更多的精力在安全防御上。

　　逐渐的，运维团队形成之前提到的5个大的工作分类，每个分类都需要有专精的人才。这个时候系统运维更专注于基础设施的建设和运维，提供稳定、高效的网络环境，交付服务器等资源给应用运维工程师。应用运维更专注于服务运行状态和效率，数据库运维属于应用运维工作的细化，更专注于数据库领域的自动化、性能优化和安全防御

标签：服务,运维,系统,介绍,工作,监控,服务器
From： https://www.cnblogs.com/fjh0517/p/16668652.html