运维工程师必须知道的基础有哪些？（详解）

最新推荐文章于 2024-10-02 10:00:00 发布

hsw Come on

最新推荐文章于 2024-10-02 10:00:00 发布

阅读量5.1k

点赞数 11

分类专栏：运维开发文章标签：运维

本文链接：https://blog.csdn.net/weixin_46451496/article/details/104906470

版权

运维开发专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Linux运行是什么？(What)

1.什么是linux运维？

在这里插入图片描述

运维是指大型组织已经建立好的网络软硬件的维护，就是要保证业务的上线与运作的正常。
在他运转的过程中，对他进行维护，他集合了网络、系统、数据库、开发、安全、监控、应用架构、存储 于一身的技术。
运维分类：
- 运维开发：是给应用运维开发运维工具和运维平台的
- 应用运维：是给业务上线、维护和做故障排除的，用开发运维开发出来的工具给业务上线、维护、做故障排查
- 系统运维：是给应用运维提供业务上的基础设施，比如：系统、网络、监控、硬件等等
- 数据库运维: 负责数据存储方案设计、数据库表设计、索引设计和SQL优化
- 安全运维: 进行常规的安全扫描、渗透测试，进行安全工具和系统研发以及安全事件应急处理

2，运维的职责

保证服务的稳定运行；
考虑服务的可扩展性；
从系统的稳定性和可运维性的角度，提出开发需求；
定位系统的问题，甚至可以直接修正bug；
对突然出现的问题做到快速响应和处理；

工作中运维应用场景？（Where）

1. Devops交付环常识普及

我们把开发交付划分为: 计划 --> 编码 --> 构建 --> 测试 --> 版本 --> 部署 --> 运维 --> 监控的一个闭环
DevOps的目标是通过建立并不断完善持续交付的流水线
运维的职责覆盖了产品从设计到发布、运行维护、变更升级及至下线的生命周期

2.产品发布前

注：这个阶段运维工程师的职责是参与设计并把关运维准入，主要包括下面类容

产品的业务熟悉；
产品架构设计的合理性评估，包括是否存在单点，是否可容错，是否有强耦合等，
资源评估，包括所需的服务器资源、网络资源以及资源的分布等，同时把相关产品对资源预算申请的合理性，控制服务成本；
资源就位，将申请的服务器及基础环境/域名准备就位。

3,产品发布过程中

监控：
- 对服务运行的状态进行实时的监控，随时发现服务的运行异常和资源消耗情况；
- 输出重要的日常服务运行报表以评估服务/业务整体运行状况，发现服务隐患；
故障处理：
- 对服务出现的任何异常进行及时处理，尽可能避免问题的扩大化甚至中止服务。
- 这之前运维工程师需要针对各类服务异常，如机房/网络故障、程序bug等问题制定处理的预案，问题出现时可以自动或手动执行预案达到止损的目的。
容量管理：
- 包括服务规模扩张后的资源评估、扩容、机房迁移、流量调度等规划和具体实施。

5.产品性能/成本优化

产品对外提供服务最重要的一点是用户体验，用户体验中非常重要的是产品的可用性和响应速度。
而如何用最**合理的资源（如机器、带宽等）**支持产品提供高可用和高速度的用户体验，这也是运维工程师的重要职责。

6.产品下线

发展良好的互联网产品将始终在线对外提供服务，但互联网产品快速迭代，也存在相当多孵化的产品最后被淘汰的情况
这些产品都需要做下线处理，这个过程运维工程师主要做好资源回收的工作，将机器/网络等资源回收后纳入资源池中供其它服务使用

运维的发展过程–为什么需要运维?（Why）

在这里插入图片描述
1.手工管理阶段

业务规模（几十台机器）
- 业务流量不大，服务器数量相对较少，系统复杂度不高。
- 对于日常的业务管理操作，大家更多的是逐台登录服务器进行手工操作，属于各自为战。
- 每个人都有自己的操作方式，缺少必要的操作标准、流程机制，比如业务目录环境都是各式各样的。
职责
- 早期的运维团队在人员较少的情况下，主要是进行数据中心建设、基础网络建设、服务器采购和服务器安装交付工作。
- 几乎很少涉及线上服务的变更、监控、管理等工作。
- 这个时候的运维团队更多的属于基础建设的角色，提供一个简单、可用的网络环境和系统环境即可。

2.工具批量操作阶段

业务规模（几百台机器）
- 随着服务器规模、系统复杂度的增加，全人工的操作方式已经不能满足业务的快速发展需要。
- 因此，运维人员逐渐开始使用批量化的操作工具，针对不同操作类型出现了不同的脚本程序。
- 此时，虽然效率提升了一部分，但很快又遇到了瓶颈，操作的质量并没有太多的提升。
- 我们开始建立大量的流程规范，比如复查机制，先上线一台服务器观察10分钟后再继续后面的操作，一次升级完成后至少要观察20分钟等。
- 这些主要还是靠人来监督和执行，但在实际过程中执行往往不到位，反而降低了工作效率。
工作职责
- 这个时候的运维团队还会承担一些服务器监控的工作，同时会负责LVS、Nginx等与业务逻辑无关的4/7层运维工作。
- 这个时候服务变更更多的是借助saltstack、ansible批量管理工具工操作。
- 监控的焦点更多的在服务器状态和资源使用情况上，对服务应用状态的监控几乎很少，监控更多的使用各种开源系统如Nagios、Cacti、openfalcon、等。

3.平台管理阶段

业务规模( 几千台机器)
- 在这个阶段，我们决定开始建设运维平台，通过平台承载标准、流程，进而解放人力和提高质量。
- 这个时候对服务的变更动作进行了抽象，形成了操作方法、服务目录环境、服务运行方式等统一的标准。
- 通过平台来约束操作流程，如上面提到的上线一台服务器观察10分钟，程序的启停接口必须包括启动、停止、重载等。
- 在平台中强制设定暂停检查点，在第一台服务器操作完成后，需要运维人员填写相应的检查项，然后才可以继续执行后续的部署动作。
工作职责
- 由于业务规模和复杂度的持续增加，运维团队会逐渐划分为应用运维和系统运维两大块。
- 应用运维开始接手线上业务，逐步开展服务监控梳理、数据备份以及服务变更的工作。
- 同时，为了应对每天大量的服务变更，我们也开始编写各类运维工具，针对某些特定的服务能够很方便的批量变更。
- 随着业务规模的增大，基础设施由于容量规划不足或抵御风险能力较弱导致的故障也越来越多，
  运维人员开始将更多的精力投入到多数据中心容灾、预案管理的方向上。

4.系统自调度阶段

工作环境（上万台机器）
- 更大规模的服务数量、更复杂的服务关联关系、各个运维平台的林立，原有的将批量操作转化成平台操作的方式已经不再适合。
- 需要对服务变更进行更高一层的抽象，将每一台服务器抽象成一个容器，由调度系统根据资源使用情况，将服务调度、部署到合适的服务器上。
- 自动化完成与周边各个运维系统的联动，比如监控系统、日志系统、备份系统等。
- 通过自调度系统，根据服务运行情况动态伸缩容量，能够自动化处理常见的服务故障。
- 运维人员的工作也会前置到产品设计阶段，协助研发人员改造服务使其可以接入到自调度系统中。
工作职责
- 业务规模达到一定程度后，开源的监控系统在性能和功能方面，已经无法满足业务需求；
- 大量的服务变更、复杂的服务关系，以前靠人工记录、工具变更的方式不管在效率还是准确性方面也都无法满足业务需求；
- 在安全方面也出现了各种大大小小的事件，迫使我们投入更多的精力在安全防御上。
- 逐渐的，运维团队形成之前提到的5个大的工作分类，每个分类都需要有专精的人才。
- 这个时候系统运维更专注于基础设施的建设和运维，提供稳定、高效的网络环境，交付服务器等资源给应用运维工程师。
- 应用运维更专注于服务运行状态和效率，数据库运维属于应用运维工作的细化，更专注于数据库领域的自动化、性能优化和安全防御。
- 运维研发和运维安全提供各类平台、工具，进一步提升运维工程师的工作效率，使业务服务运行得更加稳定、高效和安全。