学习目标

• 1、了解运维的基本概念
• 2、了解企业的运行模式
• 3、了解操作系统发展史以及作用
• 4、掌握虚拟机软件安装
• 5、新建虚拟机以及centos系统安装
• 6、运维规范

一、运维概述

1、运维岗位收入情况（职友集）

2、运维岗位的定义

什么是运维？

在技术人员（写代码的）之间，一致对运维有一个开玩笑的认知：运维就是修电脑的、装网线的、背锅的岗位。

IT运维管理是指为了保障企业IT系统及网络的可用性、安全性、稳定性，保障业务的连续性，通过专业技术手段，对计算机网络、应用系统、电信网络、软硬件环境及运维服务流程等进行的综合管理。

随着企业数字化转型升级进程加快，企业IT系统架构越来越复杂，软件更新迭代越来越快。企业信息化建设使得大量业务和数据需要依靠信息系统来完成，稳定可用的IT系统是企业业务发展的基础条件，IT运维管理随之成为企业信息化建设的重要环节。

近年来，因为IT系统突然出现故障导致业务瘫痪甚至造成巨额损失的现象频出不穷。而大型数据中心由于对系统、数据的高度依赖，IT风险更大，对IT运维管理的重视也就更高。

运维领域经常看到的技术及概念

1）云计算

云服务器是由云服务厂商提供的性能卓越、稳定可靠、弹性扩展的IaaS（Infrastructure as a Service）级别云计算服务。云服务器免去了采购IT硬件的前期准备，让企业像使用水、电、天然气等公共资源一样便捷、高效地使用服务器，实现计算资源的即开即用和弹性伸缩。

2） DevOps

DevOps（Development和Operations的组合词），它是一组过程、方法与系统的统称，主要用于促进开发和运营保障团队之间的协作与沟通，从而提高应用程序和服务的交付响应速度。

DevOps把原本独立的开发和运营工作融合到一起，运营团队时刻了解开发人员的进展，并与他们形成互动，共同监控IT业务进展。在运维方面，DevOps可以打通从需求到结果运行的所有环节，以提高业务价值为目标

3） AIOps

2016年，Gartner提出利用AI技术的新一代IT运维，即AIOps（智能运维），可以解决未来企业可能遭遇的因IT故障而导致的业务中断，AIOps是ITOM的升级和进步，它结合了大数据和机器算法、机器学习技术，通过海量信息的搜集和处理，发现、预测、解决故障，进一步推动了IT运维自动化，减少了人力成本。

4）CI/CD

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题

5）Docker

Docker 是一个开源的应用容器引擎，通常包括客户端、守护进程、镜像、容器，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，再发布出去。类似于一个集装箱，可以把货物规整的摆放起来。

3、运维的诞生

从最早的网管开始，九十年代初期，互联网欠发达的时候，还少有服务器的概念，电脑价格昂贵，大多数人并不具备在家上网的条件，网吧应运而生。

网吧的电脑、猫等设备需要进行日常维护，于是"网管"岗位应运而生，这就是早期运维的雏形。

4、90年代初网吧图

5、运维行业背景

① 从行业角度来看，随着中国互联网的高速发展(BAT)、网站规模越来越来大、架构越来越复杂，对专职网站运维工程师、网站架构师的要求会越来越急迫，特别是对有经验的优秀运维人才需求量大，而且是越老越值钱。

② 从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人，越来越得到重视。

③ 运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，优秀的运维工程师具备很好的各层面问题的解决能力及方案提供、全局思考的能力等。

④ 由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家。

⑤ 当前国内外对运维人才的需求非常迫切，运维工程师的薪资也水涨船高，与研发、测试等技术部门持平，甚至超出。

二、企业运行模式

1、铁三角

铁三角 = 产品 研发 运维

流程走向：产品设计 → 项目研发 → 项目测试 → 项目上线 → 系统运维

2、部门与部门职责

产品部门（PM、UI、UE，3-5 个）：设计产品的需求，确定需要做的项目的功能和细节问题

研发部门（5-7 个）：根据产品部门/测试部门提供的项目模块需求进行编程

测试部门（2 个左右即可）：对于研发部门提供的代码进行运行测试，检查是否存在bug和一些需要改善的体验

运维部门（3-4 个）：负责项目环境部署、上线、架构的搭建等等

3、上线与生产

成熟企业中的系统环境：

开发环境： 根据系统要求，设计和搭建系统环境

测试环境：搭建系统环境，实现自动化发布

准生产环境：搭建系统环境，沟通第三方厂商，自动化发布，监控

生产环境：搭建系统环境，沟通第三方厂商，自动化发布，监控，发起持续改进

上线：发布项目的过程，包含准生产上线，生产上线等。内测/公测 → 开服

生产：正式提供对外服务的环境，叫生产环境，需要运维重点关注。

在项目的从无到有的过程中，可以将其分为两个阶段：研发/测试阶段、生产运行阶段。

运维工作贯穿了开发，测试，生产的各个阶段，是其中重要的一环。

4、网站的概念

简单地说，网站是一种沟通工具，人们可以通过网站来发布自己想要公开的资讯，或者利用网站来提供相关的网络服务。人们可以通过网页浏览器来访问网站，获取自己需要的资讯或者享受网络服务。

扩展：了解网站的分类根据网站所用编程语言分类：例如ASP/PHP/JSP网站等；根据网站的用途分类：例如门户网站、行业网站、娱乐网站等根据网站的功能分类：例如单一网站（企业网站）、多功能网站（网络商城）等根据网站的持有者分类：例如个人网站、商业网站、政府网站、教育网站等根据网站的商业目的分类：营利型网站（企业/行业网站）、非营利性型网站（政府网站/教育网站）根据网站的面向终端的分类：Web网站（电脑端或PC端）和 WAP网站（手机端）

5、网站运行模式（重点）

从上图中可以看出如果一个网站项目需要正常的运行，则需要的前提条件有：

① 域名（方便用户记忆）

② 需要对域名和ip 的关系进行关联（DNS 服务器）

③ 服务器

④ 服务器的项目运行环境

6、几个重要概念

① 服务器

就是给用户提供服务的机器（电脑）。服务器可以分为四大类：塔式服务器、机式服务器、刀片服务器、柜式服务器。

问题一：普通台式机/笔记本能否充当服务器来使用？

标准的回答：如果从提供服务的实现角度来考虑的话的确是可以，但是如果要想稳定、高效的提供服务，则在这个角度考虑家用电脑和笔记就无法取代服务器地位。

家用台式机/笔记本从系统角度来看，一般都会使用Windows 系统（易用），并不适合作为服务器来使用。

家用台式机/笔记本硬件和专门的服务器相比标准不统一。

问题二：服务器有哪些特性？

高性能特性 标准化统一特性。

② IP地址

形式ipv4（常见）、ipv6（不考虑）。Ipv4 形式：x.x.x.x，x 有取值范围（第1 位x取值1-223，从第二位开始0-255）。由于资源有限为了保证全球这么多台电脑都可以使用，ip 可以分为公网/外网ip 和私网/内网ip 地址。

0.0.0.0，表示任意地方，anywhere…

③ 域名

就是在浏览器地址栏中输入的那一串字母和数字的组合，例如：www.baidu.com，这个就是域名，域名主要是方便用户记忆。

问：www.baidu.com 这个域名是几级的域名？二级域名，看域名的级别只要看有几个"."，日常所说的注册域名指的是注册顶级域名（一级）】

④ 公网

www（万维网），全世界都可以互相访问的网。

⑤ 局域网

局域网/内网/私网：在某个单元内部（家庭/教室/公司）能够进行互相访问的网络，红色警戒游戏对战平台。

7、服务器的重要结构组成

家用电脑组成： CPU、主板、内存条、显卡、硬盘、电源、风扇、网卡、显示器、机箱、键盘鼠标等等。

1）CPU

CPU是电脑的大脑，如下图所示：

CPU发展史：

32 位CPU：最大的内存寻址地址2^32，大约4G的大小。

聊聊2的32次方怎么算？

1T = 1024GB 1GB = 1024MB 1MB = 1024KB 1KB = 1024B

2^32B = 2^32 /1024/1024 /1024 = 4GB

2）内存

内存也是电脑必需组件之一。

计算机是一个商铺：CPU相当于人，内存相当于仓库。商品必须上架才能显示。

3）风扇

4）电源

5）硬盘

硬盘的作用：存储数据。

硬盘可以分为机械硬盘、固态硬盘。

6）主板

主要的作用：

自身包含了一些集成电路，负责各个不同的功能和数据通信。

主板上有很多空的插槽，插槽的作用在于扩展外部的硬件设备。

三、操作系统概述

1、计算机发展史

第一台计算机是1946 年2 月14 日诞生日，第一台名称ENIAC。体积一间屋子的大小，重量高达28t。

第一代：1946 – 1958 => 12 年 （电子管）

第二代：1958 – 1964 => 6 年 （晶体管）

第三代：1964 – 1970 => 6 年 （集成电路）

第四代：1970 – 至今 （大规模集成电路）

2、计算机组成

CPU、内存、风扇、硬盘、显示器、主板、电源、声卡、网卡、显卡、鼠标、键盘等

3、计算机资源（重点）

计算机资源分为2 部分：硬件资源、软件资源

硬件：一般硬件是指计算机的物理组成，由真实（看得见，摸得着）的设备组成的

软件：软件一般是指应用程序，应用程序程序是由开发人员去按照编程语言的特定的规则去

编写的程序。除了上述的应用程序之外，操作系统也属于软件资源的范畴，它属特殊的软件。

问题：为什么在打开一个应用程序之后（吃鸡游戏），当玩家在敲击键盘和移动鼠标的时候里

面人物会有对应的行为表现呢？

答：用户敲击键盘/移动鼠标（硬件操作） → 硬件的驱动（软件资源） → 操作系统（软件） → 硬件支持（cpu） → 操作系统（软件） → 驱动（显卡驱动） → 显示在屏幕上（硬件）

所以由此可知，操作系统是软件资源与硬件资源之间的桥梁。

4、操作系统

常见操作系统有：Windows、MacOS、Unix/Linux。

Windows：其是微软公司研发的收费操作系统（闭源）。

Windows 系统体系分为两类：用户操作系统、Server 操作系统。

用户操作系统：win 95、win 98、win NT、win Me、win xp、vista、win7、win8、win10。

MacOS：其是由苹果公司开发的一款收费（变相收费，买电脑送系统）操作系统。该系统从

终端角度来看分为：watch OS、IOS、MacOS。其表现突出的地方：底层优化实现的很好、安

全性要更加高点（闭源）。

Linux：Linux 是目前全球使用量最多的服务器操作系统（开源）。其体系很强大，其分支有

很多（数不胜数），其目前主要的分支有：redhat（红帽）、Debian、乌班图（ubuntu）、CentOS

等等。其在世界范围最大的使用分支是安卓。

闭源：不开放源代码，用户是没有办法看到软件的底层实现（闭源≠收费）。

开源：表示开放源代码（开源≠免费）。

5、为什么需要Linux操作系统

问题：windows 既然可以使用傻瓜式的方式进行操作，例如使用ctrl c 表示复制，ctrl v 表示粘贴等，为什么还需要使用/学习Linux 系统？

① 性能问题，Windows 服务器操作系统不如Linux 高；

② 稳定性问题：

底层架构：Linux 更加稳定，其开机时间可以达到好几年不关机；

开源：因为开源，人人都可以看到源代码，就可以为其提供自己的补丁，补丁可以提高 稳定性和安全性；

③ 安全性问题：

Linux 操作系统，相对于windows 操作系统要更加安全；

④ 远程管理方面：

Windows 不及Linux 操作高效。

⑤ 服务器价格昂贵的，需要对资源进行充分利用，充分把计算机资源用到项目上（访问并发、性能），而不是把资源浪费在图形化界面或者方便程度上；

四、Linux发展史

1、Linux 起源

##

2、Linux 的含义

狭义：由Linus 编写的一段内核代码。

广义：广义上的Linux 是指由Linux内核衍生的各种Linux发行版本。（CentOS、Ubuntu）

注意：以后提及到的Linux 都是广义上的Linux

3、Linux特点

开放性（开源）、多用户、多任务、良好的用户界面、优异的性能与稳定性

多用户多任务：

单用户：一个用户，在登录计算机（操作系统），只能允许同时登录一个用户；

单任务：一个任务，允许用户同时进行的操作任务数量；

多用户：多个用户，在登录计算机（操作系统），允许同时登录多个用户进行操作；

多任务：多个任务，允许用户同时进行多个操作任务；

Windows 属于：单用户、多任务。

而Linux系统则属于：多用户、多任务。

4、Linux分支(Linux衍生版：Linux厂商基于Linux内核)

分支：Linux 分支有很多，现在比较有名的redhat、ubuntu、debian、centos（Community Enterprise Operating System）、suse 等等。

中国Linux系统：红旗（Redflag）、麒麟、深度OS

CentOS6.9

CentOS7.5

五、Linux系统安装

1、Linux系统安装方式

目前安装操作系统方式有2 种：真机安装、虚拟机安装。

真机安装：使用真实的电脑进行安装，像安装windows 操作系统一样，真机安装的结果就是替换掉当前的windows 操作系统；

虚拟机安装：通过一些特定的手段，来进行模拟安装，并不会影响当前计算机的真实操作系统；

如果是学习或者测试使用，强烈建议使用虚拟机安装方式。

2、虚拟机概念

什么是虚拟机？

虚拟机，有些时候想模拟出一个真实的电脑环境，碍于使用真机安装代价太大，因此而诞生的一款可以模拟操作系统运行的软件。

虚拟机目前有2 个比较有名的产品：vmware 出品的vmware workstation、oracle 出品的virtual Box。

3、虚拟机的安装

第一步：双击打开VMware安装程序

第二步：进行下一步安装

第三步：同意许可协议，单击下一步

第四步：根据需要决定是否需要更改软件的安装位置（建议放置于除C盘以外任意盘符下）

第五步：更改成功后，单击确定，下一步继续安装：

注意：所有软件的安装目录最好在安装的时候是空的

第六步：用户体验设置，如下图所示，单击下一步继续安装

第七步：快捷方式设置，单击下一步继续安装。单击安装按钮、安装结束后，单击完成按钮

注意事项：最重要的地方，在安装完之后需要检查，检查虚拟机软件是否有安装2 个虚拟网卡

Windows7与Windows10可能显示网络名称有所不同，但是底部虚拟机网络是一致的。

4、Linux系统环境部署

Linux系统版本选择：CentOS7.6 x64，【镜像一般都是CentOS*.iso文件】

问题：为什么不选择最新版的8 版本？

7.x 目前依然是主流

7.x 的各种系统操作模式是基础

官网：https://www.centos.org/ ，从官网下载得到的镜像文件：

Centos7.6版本下载地址：

http://vault.centos.org/7.6.1810/isos/x86_64/CentOS-7-x86_64-Everything-1810.iso

第一步：新建虚拟机，点击"文件"菜单，选择"新建虚拟"选项，选择"自定义"点击下一步：

第二步：选择兼容性，默认即可，选择镜像文件的时候选择"稍后安装操作系统"，单击下一步：

第三步：设置虚拟机的名称（名称将会后期出现在左侧）和设置虚拟系统的安装位置

第四步：CPU设置，提示：根据自身电脑配置选择CPU设置，一般默认即可，1*1

第五步：分配虚拟机内存

第六步：选择虚拟机网络类型，默认选择NAT即可。

NAT：配置好之后windows 即可和虚拟机进行互相通信，但是教室内的其他同学是访问不了的，只有自己可以访问虚拟机中的操作系统。

桥接：配置好之后其他同学也可以访问你的虚拟机操作系统。

第七步：后续默认的步骤，直接下一步，安装完毕后，单击完成：

5、CentOS系统安装配置

第一步：选择CentOS系统安装镜像【*.iso文件】

第二步：开启虚拟机，进行系统安装

特别注意：如果在启动时候出现下述错误，则说明电脑没有开启cpu 的虚拟化，如果需要开启，则需要重启计算机，并且在开启的时候进入主板的BIOS 设置开启虚拟化，然后保存设置重启电脑：

第四步：选择安装centos7（通过↑ 或 ↓方向键进行选择），确认后，按下回车

第五步：等待一会儿后，将弹出欢迎使用CENTOS 7的界面，选择中文，简体中文（中国），点击继续

第六步：在安装信息摘要界面，点击软件安装，进入软件选择界面

第七步：在软件选择界面，选中左侧GNOME Desktop，勾选右侧所有项目，点击完成，回到安装信息摘要界面。

点击INSTALLATION DESTINATION

进入磁盘配置页面，直接点Done，不需要做其他更改，只是确认使用自动分区

第八步：点击开始安装

第九步：进入安装进度页面

第十步：点击ROOT密码，进入密码设置页面，输入两次ROOT账户的密码，例如1234。第一次点击完成，会提示Too short，密码太短，再点击一次完成，确定使用简单密码。（生产环境要设置足够复杂的密码）

第十一步：回到安装进度页面，显示已经设置了ROOT密码，等待安装完成即可。

第十二步：安装完成后，右下角会出现重启按钮，点击重启

第十三步：重启之后，来到初始设置页面，点击license information

第十四步：勾选我同意许可协议，点击左上角完成，回到初始设置页面

第十五步：网络和主机名，创建用户都不用操作，直接点击右下角完成配置

第十六步：进入到欢迎页面，点击前进

第十七步：输入页面，默认汉语，点击前进

第十八步：隐私，位置服务，默认开启，点击前进

第十九步：时区，在对话框中输入shanghai，会自动联想出对应时区，点击右上角前进。

第二十步：在线账号，选择跳过

第二十一步：全名任意填写，用户名默认和全名一致，此处的用户名，是一个普通的账户，区别于ROOT账户。点击前进。

第二十二步：填写密码，注意需要包含数字，字母，特殊字符，此处密码是前面创建的itheima这个账户的密码

6、安装后配置

为了试验方便，取消centos的屏幕锁定

点击桌面右上角的电源标志，在弹出菜单下方，点击设置按钮

选择左侧的Power（电源）按钮，右侧选择Never（从不），这样Centos就不会每五分钟自动锁屏了，方便大家操作。

注意：自动锁屏是出于安全考虑，工作环境尽量不要关闭。

选中后，直接点击右上角关闭即可，系统会自动保存配置

六、运维规范

1.1 运维不简单

前阵子，跟一个项目经理沟通能否提前半天将变更申请提交过来时，这位项目经理很不理解的问我，“你们运维不就是在生产环境部署个程序这么简单的工作吗？你们又不懂程序，评审不出什么吧？”。

运维多年，对运维的这类认识听过很多，它反映了企业里不同的组织团队对运维的认识往往仅限于一些简单操作性的工作，比如生产应用系统在故障时的重启、应用变更时敲敲命令、平时增删改查数据，或者是办公室和电有关的所有软硬件的使用问题等等。

那么如何理解运维呢？百度百科对运维的解释为：企业 IT 部门采用相关的方法、手段、技术、制度、流程和文档等，对IT 软硬运行环境(软件环境、网络环境等)、IT 业务系统和 IT 运维人员进行的综合管理。从百度百科的解释看，运维岗位需要一个综合性的技术与管理能力，需要掌握大量的方法论与技术栈。

运维狭义“运维技术与资源”可以定义为“监、管、控”，技术与资源主要是支撑运维/运营的质量、效率、成本的平衡。以下简单摘录了运维的一些能力要求：

• 运维规范的落地：以ITIL、ISO20000、ITSS.1等方法论，结合外部监管及内部规范的落地；
• 监管机构的要求落地：理解、快速响应、落地监管机构的管理要求；
• 基本保障：配置、监控、应用发布、资源扩容、事件、问题等；
• 基础能力：网络、服务器、操作系统、数据库、中间件、JVM、应用等基本使用与调优；
• 业务服务能力：SLA，服务台、业务咨询、维护、经验库、等支持能力；
• 可用性管理能力：巡检、业务系统连续性、可用性，基础架构及应用系统的高可用、备件冗余资源；
• 风险、安全管理能力：操作、审计、监管风险，漏洞、攻击管控；
• 故障管理能力：事件、问题管理水平与能力；
• 持续交付能力：应用变更、基础资源、办公服务交付能力；
• 主动优化能力：架构优化、性能响应效率、客户体验等
• 应急演练：架构高可用、突发事件、业务故障的架构、方案、文档、人员熟练程度等
• 业务支撑：数据维护、数据提取、参数维护等；
• 运行分析能力：容量、性能、可用性分析等；
• 运营能力：促进业务痛点的发现与解决、客户及业务业务体验等；
• 成本控制：更好的评估人力、硬件、带宽、软件，节省成本；
• 运维开发：运维自动化工具的建设，运维开发能力的培养；
• 其它

不同的企业需要运维的能力会有不同的扩展，同进上述能力要求每一点扩散出来都将是一个复杂的技术栈，比如“基础能力”中的LINUX操作系统的内核关系图（摘自互联网见，图1.1），或再深入一些关于mysql优化（摘自互联网见，图1.2），需要运维人员对技术能力深度的要求。

讲到这，肯定会有人说上述的技术栈的能力要求通常是由于某个运维组织的仍处于专家式运维，自动化程度不够高导致。

的确，理论上所有运维操作性、命令的工作都可以整合为经验，并通过自动化落地实现，现在互联网企业对外都宣称自动化在运维工作覆盖面很高，己经开始迈向智能化，AIOps，甚至提出了NoOps的解决方案。

关于这些互联网企业的自动化对日常运维工作真实的覆盖面暂时无法考究，但以我的经验看，至少金融企业的自动化覆盖面还有很长的路要走，且肯定还会很大一部份工作很难自动化，毕竟工作类型太多，在有限的投入上只能集中力气去做投入产出比更高的运维自动化。

这里再以一个运维工具思维导图（图1.3）简单列示一些常规的运维操作，可以看出其实很难有一套能解决所有运维操作的工具平台。

所以我觉得，随着业务要求越来越高、规模越来越大、监管要求越来越高，纵使外部如何宣称自动化、智能化对运维人员经验、技术、管理能力替代，金融企业内的运维还需要认清实际情况，结合企业的整体战略定位，强调运维团队在运维管理与技术能力的广度与深度，再有侧重、有先后的实现自动化水平。

在未来一段时间里，金融企业的运维岗位仍是一个复杂的、综合性技能的工作岗位。

1.2运维之痛

近年来，随着运维技术的快速发展，各行业的运维水平在得到了较大的提升同时，运维圈的分享也越来越开放，从国外google的SRE理念，到国内新技术领跑者腾讯游戏的蓝鲸、织云，以及借助于各种运维专题的公众号、运维大会有大量的互联网、传统企业的运维组织进行分享。

1.2.1组织之痛

前面讲过，在企业内部其它团队对运维的认识通常是简单操作，出故障时才会找的同团队，随着信息技术的发展与业务的发展，运维组织痛点越来越明显，企业内对运维组织的不满的声音越来越多，反思一下原因，分外部客观因素和内部因素。

1）外部客观因素

在当前大数据时代，金融企业的运维面临业务规模的不断扩大，业务竞争越来越激烈，监管要求越来越高，数据中心的规模也越来越高，大量新技术、开源架构的引入取代了传统稳定的系统架构等等因素影响。

• 运维组织的角色：绝大部份运维组织都是一个成本部门，企业对运维组织的重视程度通常不如开发组织，更不用说是前台业务部门。这方面造成了运维部门的规模通常增长很慢，以 Google 为例，在《Google SRE 运维解密》一书中提到，由于Google的数据中心规模急剧扩大，系统越来越复杂，而运维人员规模又跟不上，所以他们的运维组织采用组建 SRE 的运维开发团队实现自救。
• 业务对运维服务质量的要求：越来越多的金融业务己从线下走到线上， 为了赢得更多用户的青睐，一方面，业务要求更多、体验更佳的业务性能；另一方面业务对应用发布的交付速度有了更高的要求。前者会产生更复杂的系统设计，后者需要更高效的应用发布支持，两者都会对系统响应效率、稳定性带来影响。
• 外部监管要求：长期以来，为了防范金融风险，监管机构对金融企业保持强监管的方式，十九大之后，监管对金融企业的信息技术的稳定性、规范性有增无减。在强监管下，信息系统的稳定性有了进一步保证，但也给运维组织带来更高的要求，客观上也加大了工作量，并由于规范流程带来的工作效率的下降。
• 业务并发要求：用户量的增加，营销活动不断推出，需要系统具备更高的并发处理能力要求，企业不断引入大量分布式、开源架构替代传统相对成熟稳定的架构来满足业务需要，这些变化都给运维能力带来挑战。
• 数据中心规模增大：数据中心的多中心建设，云化，去IOE，分布式架构的引入使得应用系统规模成倍的增大。

2）内部因素

网上有一个调查数据，在整个运维成本的分配中，软硬件和网络设备的维护成本占 30%，维护服务成本占30%，内部运维人力成本则占了40%。

这里的人力成本包括现在维护、培训、流失与引入等成本，如果将维护服务成本也纳入到人力成本之上，则人力这一块的成本将上升为70%，影响这个人力成本的因素主要有：

• 运维能力模型：ITIL、ISO20000、ITSS.1是运维领域中比较成体系化的方法论（目前更为火爆的 DevOps 更倾向于是一种思路），其中只有ITSS.1提出了运维能力模型的概念，但在量化运维人员具体能力的实际操作上也比较难落地。也就是说你很难评价一个运维人员如何做才是做得优，如何是中，如何差，这些评价通常比较主观，这也客户观影响了运维人员不断增加技能、优化工作效率的动力。
• 运维规范化：组织扩大到一定规模，以口口相传的传授，结合个体责任心、工作习惯为主的方式容易出现操作风险，且无法进行量化绩效管理，管理规范无法落地。
• 运维精细化程度：组织通常是从纵向职能型的方式形成，这种方式能培养全能型、经验丰富的专家式人才，这些专家式人才利用经验能快速解决职责下的常规问题，且效率比较高，适合小型的组织。
• 随着组织的不断壮大，面对的问题越来越复杂，技术要求越来越多，一方面很多人不能满足这种专家式人才的要求；一方面也会产生很多重复性的工作；同时对于人员流失带来的影响比较大。这时候就需要将纵向工作精细化，再辅助横向人员对工作进行持续的优化。
• 运维目标：运维的目标往往以被动式的目标为主，被动处理故障、被动解决问题、被动提供应用交付、被动节省成本等，这种被动式的运维目标导致计划性工作不够，缺乏持续不断的自我优化，主动提高效率、质量，降低成本，并由运维向主动运营目标去转变。
• 自动化能力：IT软硬件体量庞大，且增长迅速，手工操作的机器任务太多；运维数据越来越多；故障定位越来越难，人工经验依赖高；监控手段不够及时、全面；应用发布、资源交付效率低下；没有主动的容量、性能分析、体验分析能力……这些都是常见的一些痛点。
• 个体之痛作为运维组织中的运维人员同样面临不少痛点，有来自工作时间、工作压力、学习压力、职业发展等等，以下简单罗列：
• 7*24小时制的工作时间：运维人员的节假日是不完整的，通常节假日需要运维值班保障或在家通过VPN远程操作、或和家人团聚时还远程指导进行故障应急；运维人员上班时间不同普通工作，为了不影响业务，应用发布、基础设施变更、演练等工作都会放到晚上，对客的业务系统还可能要安排到深夜。这种随时可能发生，随处理可能要处理的工作状态是其它行业所不具备的痛点。
• 高度压力的工作：“如履薄冰”很好的形容了运维的工作状态，因为任务一个生产操作都可能对业务带来影响，所以运维的操作必须十分谨慎。同时在运维故障处理过程中，运维人员需要面临着来自业务、客户、开发、领导的各层的压力下，冷静的完成故障处理，是一个高压的工作状态。
• 被动的工作：经常会有人形容运维就是一个“消防员”的工作，也就是被动救火的工作，这个形容很贴切，在缺乏一些主动分析、优化、预测性的工作的背景下，运维组织的大部份工作是以被动为主，是负责应急救火、打扫战场、负责收尾的那群默默的人。
• 对工作的认识：运维的人通常会认为自己就是一个背锅的角色，开发程序问题、硬件问题、系统软件问题、业务需求问题都需要运维去解决，而且这些问题对可用性的影响还要运维来承担，这是运维特有的痛点。
• 职业压力：运维工作一方面主要是和机器或系统软件打交道，所以相对于开发、项目管理等IT岗位，转型机会的面比较窄；同时，运维岗位中重复操作性的工作占比多，如缺乏引导容易让运维人员产生麻木的状态，失去持续改善的动力；另外，前面也提到运维需要掌握的技能和管理理念很多，对于运维人员的学习能力要求很高。

1.3 自救

1.3.1 SRE

SRE这个名词最早是从《Google SRE 运维解密》一书中获得，全称是Site Reliability Engineering，翻译过来就是：站点可靠性工程师。

Google 对 SRE 的职责描述为：确保站点的可用，为了达到这个目的，一方面他需要对站点涉及的系统、组件熟悉，也要关注生产运行时的状态，为此，他需要自开发并维护很多工具和系统支撑系统的运行，比如自动化发布系统，监控系统，日志系统，服务器资源分配和编排等。SRE是一个综合素质很高的全能手，如果对他的能力进行分解主要有三块：

• 熟悉系统架构与运行状态：SRE需要懂服务器基础架构、操作系统、网络、中间件容器、常用编程语言、全局的架构意识、非常强的问题分析能力、极高的抗压能力（以便沉着高效地排障），他们还需要懂性能调优理论。为了保证系统架构的高可用，SRE甚至会有意识的破坏自己的系统，以提高系统可用性。
• 熟悉运维涉及的管理方法：SRE需根据企业自身发展需要，清楚运维涉及的各项工作的流程方法论，比如故障处理、应用发布、可用性管理等等，SRE十分重视运维流程的持续改善，比如对故障的追根溯源，怀疑一切的方式持续改进。
• 运维开发 产品经理：SRE 在运行保障过程中的手段更加自动化，更高效，这种高效来源于自动化工具、监控工具的支撑，且他们还需要是这些工具的主要开发者，他们要不断优化和调整，使整个工具箱使起来更加得心应手。为此SRE有一个50%的理念，就是50%用于日常保障，50%用于项目性的工作，这个项目性的工作主要体现在运维开发与运维产品经理的角色。
• 运维开发关于运维开发的理解主要体现在运维工具层面，不同的组织有不同的理解，通常有三类：
• 完全自建：运维开发团队利用开源技术结合自身需要进行一定的二次开发，这种方式在互联网企业比较流行，具体的成效大小与何时能起来收效与对这个运维开发团队的整体规划或资源投入有关；
• 外购开发资源或工具产品：运维开发团队主要是结合企业痛点承担产品经理的角色，设计、跟进、推广工具，这种方式常出现在传统的企业，尤其适用于投入运维开发人员比较少的企业，这种方式是投入收效快，但是对外部资源依赖比较大，不利于后续持续建设；
• 外购与自建相结合：运维开发团队在整个工具体系下，针对部份组件选择性的引入一些成熟的工具体系，同时要求这类成熟的工具需要开放一定的接口或源码支持，对于一些与公司个性强的环节采用自研的方式。这种方式目前逐渐被运一些传统企业，比如金融企业所接受。

总的来说，不管选用上面哪一种方式，运维开发团队都应该有一个整体、统一的一体化工具建设规划，并在建设过程中始终保持对运维工具体系的掌控能力，并在工具体系的上层为其它运维人员提供简易的、可创造性的“开发能力”，比如所见即所得的工具可视化、可定制的运维报表、拖拉拽方式的流程及脚本组件的拼装等运维开发方式。

1.3.3 DevOps

1.3.3.1 DevOps 概述

DevOps 一词的来自于 Development 和 Operations 的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠，他是一种方法论，包含一套基本原则和实践，工具是为有效落实这套方法论提供支持。

在软件全生命周期管理过程中，包括开发，构建，测试，发布，运营，在这个全生命周期管理过程中出现了开发组织与运维组织的部门墙，这是因为开发组织关注需求的实现，希望尽快实现变更；运维组织关注系统运行稳定，而变更又往往是生产应用不稳定的原因。

DevOps 方法论的出现主要是为了解决这个协作问题，以让软件交付更加高效，质量更高，生产端更加敏捷，生产运行过程中的问题能更加高效的反馈到开发，形成一个全生命周期的闭环。随着业务对运维交付能力的时效性要求越来越高，运维组织面临“吃力不讨好”的问题：

• 吃力：花费大量时间在应用部署的操作性工作中。这部份部署变更包括新功能的上线以及修复功能BUG两方法。
• 不讨好：操作性的工作越来，带来的操作风险越大，有这样一个统计，如果手工运行5条命令的情况下，成功部署的概率就已跌至86%；如需手工运行55条命令，成功部署的概率将跌至 22%；如需手工运行100条命令，成功部署的概率将趋近于0（仅2%）。

DevOps 鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化，借此有助于改善双方在交付软件过程中的速度和质量。侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性，以及可维护性。

1.3.3.2运维实践中的DevOps

可以从工具链、组织文化、自动化、敏捷看板等角度讲DevOps，比如在目前比较活跃的 DevOps36计中，基本覆盖了运维领域很大的一块：

从 DevOps 的落地效率来看，需要将 DevOps 进行聚焦，聚焦到交付能力上，这方面，行业里比较标准化的评估是去年底由中国信息通信研究院，联合一些互联网企业、运维社区，以及一些金融、传统企业联合进行编制的 DevOps 标准（券商行业中华泰参加了编制）。

从这个能力模型公布出来的一些介绍看，标准对 DevOps 范围比较克制，主要以交付能力来分解敏捷开发、持续交付、技术运营、应用架构、组织架构，这和最早的 DevOps 能力环比较吻合：

从运维的交付场景看，主要是资源交付与应用交付，其中资源交付以IAAS、PAAS云的建设为主，通过云管平台的工具链将基础设施、网络、硬件、虚拟化、容器、运行中间件等系统软硬件交付能力自动化，并通过CMDB整合DevOps能力环之上的应用场景，实现资源的快速交付。

资源交付能力主要在于IAAS、PAAS层的云平台标准化、自动化、平台扩展性等方面的建设程度。

应用的快速交付比资源交付更为复杂，应用交付涉及全链路的整合，链路上的节点越多落地的难度越大，因为它不仅涉及技术，还涉及理念的认同与聚焦。应用交付能力要实现，最简单的技术栈工具需要CMDB、应用发布工具、应用版本库、监控工具，上述工具对内要与云平台对接，对外要提供接口给开发、测试工具。

当然如开发、测试也能和运维使用同一套发布工具、应用版本库则效果更好，不过，实际实施过程中组织之间还是会有不少冲突，比如开发关注源代码版本管理，测试、运维关注运行版本的管理，需各个组织共同付出共建技术链。

1.3.4 运营

关于运维圈里运营的概念，以转型口号喊得比较多，我对运维当中的运营有业务运营与技术运营两个维度的理解。业务运营是通过功能优化或工具开发等方式解决业务工作痛点，或通过运行分析发现影响业务开展的因素，并推动相关的优化，最终提升业务能力。技术运营则主要从技术角度去降低IT成本，提升IT服务质量与效率。具体的实施内容可以考虑如下：

从上述概括可以看出，当前运维里面的运营，与运维数据密切相关，需要基于运维大数据平台来提升运营质量。

为了进一步说明运营，这里举两个例子：

1）理论：

优锘科技CEO的陈傲寒在2016年写过一篇文章《IT：从运维到运营》，虽然己过去1年多，仍是我读过最好的一篇。全文从企业、运维组织角度出发分析什么是运维、什么是运营，再将运营分解到不同角色上的理解与落地的方向，全文均是干货，值得通读，这里只列出一个思维导图。

2）实战

去年参加了一场腾讯QQ关于 DevOps 的培训，对于它们提到的一个自救方式的运营手段很有印象。那就是在腾讯QQ逐渐被微信团队替代过程中，QQ技术运维团队是如何通过各种方式去为企业带来效益，比如他们通过运维分析，得到如何更加合理的使用带宽、资源，大大减少了公司在基础设施方面的投入。

在金融企业中，也同样有很多空间可以去尝试，比如分析业务痛点，为业务提供快速的策略性的工具来替代重复操作性的业务操作；通过运维数据分析，发现客户体验方面的痛点，推动业务功能的优化等等。

1.3.5 AIOps

AIOps这个词最早是在2016年由Gartner提出（当然国内很多厂商也提出它们早几年也提出了这个理念）。

AIOps是Algorithmic IT Operations的缩写，是基于算法的IT运维，即通过使用统计分析和机器学习的方法处理从各IT设备、业务应用、运维工具收集的数据，从而加强增强运维自动化能力，以便更快、更有效、更全面的实现自动化效果。

Gartner通过使用图1中的图解释了AIOps平台的工作原理.AIOps有两个主要组件：大数据和机器学习。它需要从孤立的IT数据中移除，以便将大量数据平台内的观察数据（例如监控系统和作业日志中发现的数据）与参与数据（通常在故障单，事件和事件记录中找到）相结合。

然后针对组合的IT数据实施全面的分析和机器学习（ML）策略。期望的结果是持续的见解，通过自动化产生持续的改进和修复。AIO可以被认为是核心IT功能的持续集成和部署（CI / CD）。

• 广泛和多样化的IT 数据源：如日志类的设备日志、系统日志，应用日志、运维操作日志；指标类的监控性能指标、事件。
• 具备针对海量数据处理与分析的运算平台，能够从现有的IT数据生成新的数据和元数据、计算和分析还消除噪音，识别模式或趋势，隔离可能的原因，揭示潜在问题，并实现其他IT特定目标。
• 算法，充分利用IT领域的专业知识，更适当，高效的处理数据。
• 机器学习，从根据算法分析的输出和引入系统的新数据自动更改或创建新的算法。
• 可视化，以易于消费的方式向IT行动提供洞察和建议，以促进理解和行动。
• 自动化，其使用分析和机器学习产生的结果自动创建和应用响应或改进已识别的问题。

1.3.5 AIOps 与自动化的关系

AIOps很火，所以对AIOps和自动化做了一些对比。暂以一句话作个区别：AIOps 是基于对运维数据（日志类、指标类数据等）的机器学习，进一步解决自动化成本高或无法解决的问题，属于运维自动化的优化，细化一下区别有：

• 概念：
• 狭义的自动化则提运维“监、管、控”的工具。AIOps是将AI技术应用到IT运维领域，需要有学习、类人交互、主动决策的特征。
• 实现思路：
• 自动化往往以过程为导向，AIOps则以目标为导向，通过对数据进行学习，得到如何实现目标。
• 门槛高度：
• 自动化手段有丰富的落地解决方案，适合作为替代标准化的运维操作性工作，即“面”的问题。AIOps目前仍处起步阶段，不是适合替代现有的自动化，而是应该用于解决自动化不能解决或解决成本很高的问题，即“点”的问题。
• 如何整合：
• AIOps并非是要取代现有的自动化运维体系，而是赋予现有体系智能。AIOps就要“学习，了解”自动化工具，并且更好的“使用”这些工具，这个过程就是深度集成，它的核心是对这些工具API的自主认知和自主使用。

虽然行业内的智能运维理念十分火热，但实际落地成效上还主要处于研究阶段。从运维工具技术解决方案的角度看，对于智能的解读也有差别，如果将智能的特点解读为具备”模拟人，具备自学习，能够从数据中获取知识，进而进行预测/决策“来判断是否智能，智能是自动化的一个辅助手段，自动化才是终态。

建立在这个认识下，我们首先需要通过自动化手段解决痛点，提高工作效率，控制风险；利用运维数字化的建设为运维智能化提供数据、数据计算的能力；在自动化、数字化水平得到一定程度后，再通过人工智能的技术去解决自动化手段解决起来费力或无法解决的局部问题，让自动化具备智能的水平。

1.4 体系

1.4.1 运维的可持续改进

在管理领域，戴明推出的PDCA循环可以解释运维体系需要具备的可持续改进的能力条件。PDCA循环为四个阶段，即计划（plan）、执行（do）、检查（check）、调整（Action），即在实际工作开展过程中，把各项工作按照作出计划、计划实施、检查实施效果，然后将成功的纳入标准，并不断循环改进的过程。

将这个思路引入到企业的运维体系中则是针对企业业务发展的需求，制定运维体系的整体发展目标，通过不断改进的措施提高运维工作效率、控制风险，以达到高效、更优化的资源配置，进而推动业务的发展。要做到运维体系的可持续改进，需要做到以业务导向，整体布局；组织、流程、工具三位一体；不断审视优化。

1）P：以业务导向、整体布局

运维的最根本作用是保障IT数据的连续性，这里的IT数据包括业务，以及反映业务的数据，或者换句话可以表达为：网络不断、系统不瘫、数据不丢。随着业务对IT系统依赖程度越来越高，运维又会承担更高的期望，也就是运维向运营的转化，这就需要从业务角度去不断完善运维，以促进业务为大目标，要明白“IT for IT”是为了更好的“IT for Business”。

有了这个目标，那我们的运维体系的构建就需要与企业业务的发展保持同步，要让运维体系具备可持续改进的能力。

另外，可持续改进的过程不应该是大拐弯的方式进行改进，而应该不断的小调整，这就需要确保首先要建立一个整体、全局的运维体系，对运维各项工作做一个整体的规划，把眼光看得更远，往往可以更好的把控当前。

2）D：组织、流程、工具的三位一体

可持续改进的运维体系需要让运维的组织、流程、工具三位一体的作用，比方说：提高工作效率，需要组织的专业化分工、流程的标准化、工具的自动化配合作用；推动业务的发展，既需精细化运维分析、业务服务、运营等维度的工作资源投入，也需要有工具的建设来减少操作性的工作来释放人力，需要工具提供更高效的数据来源。

这里说的组织主要是从运维人力资源的分工、团队建设、工作目标导向、运维KPI等；流程是指以成熟的运维方法论为主体，结合企业和外部监管的规章制度、企业业务发展需要，而落地的标准化工作方法；工具既包括狭义运维的“监、管、控”，也包括运营体系所需要数字化、智能化的工具平台。

3）C A : 不断审视优化

在实际工作过程中，审视检查的过程很容易被忽略，但实际上最大的收获可能就来自于这个总结、归纳的过程中，这也是可持续改进的运维体系的关键所在。比方说，运维组织可以考虑在必要环节增加横向的优化团队；运维流程也需要定期对流程的落地进行分析，并对规章制度进行查漏补缺、删减不合理的流程规范、调整无法执行的规范要求；工具的建设要不断的分析工具的使用覆盖率，如何提高覆盖率，分析是否提高了运维的效率，还是带来了反作用等分析，并不断调整优化工具的建设。

1.4.2 转型思路

在提出可持续的运维体系前，我们先归纳一下运维组织常见的运维痛点，以提出运维转型的思路，再看看如何构建一个可持续改进的运维体系来支撑运维转型。前面的运维之痛中提到了“救火”、“背锅”、“低价值”、”重复操作“等标签，我们归纳下己有特点再看转型：

1）特点

• 被动救火式，以被动保障业务系统运行，日常计划性工作容易被打断、搁置；
• 问题驱动式，以系统可用性、可靠性、业务请求等问题驱动运维工作；
• 操作运维，重复性、操作类点主要工作量的运维模式；
• 经验式运维，由人工经验驱动的运维模式，尤其是一些经验丰富的老员工的离职在短期内会对运维质量带来一定的冲击。

2）转型

• 从被动救火式向主动精细化转型，专业化分工、主动分析，主动优化，驱动开发，促进DEVOPS的落地；
• 从问题驱动向价值驱动转型，以企业业务发展目标为主线，业务体验、服务满意度、促进业务更好发展；
• 从操作运维向运维开发转型，通过为运维人员提供运维开发平台，降低运维开发门槛，快速落地一些紧迫的运维工具，降低操作性、重复性的运维工作；
• 从依靠经验向智能化驱动运维转型，结合数据分析、知识库、机器学习技术促进运维智能化。

1.4.3 构建运维体系

上二节提到运维体系以业务导向，整体布局，组织、流程、工具三位一体，不断审视优化的建设思路，也提出了”主动精细化“、”价值驱动“、”运维开发“、”智能化运维“的转型目标，我们再将这些思路分解到组织、流程、工具的建设中，并归纳为：三大建设，十个文化的实践方法：

• 组织建设：专业化、精细化、运营化

我们将运维实施主体运维组织理解为组织，理想情况下，优秀的组织应该具备有合适的工作、合适的时间、合适的人、合适的行为四个要素组成。即组织要结合企业实际发展方向，制定符合企业、运维组织、个人发展的工作内容，并选择具备合适的知识、技能、认知、能力的人去完成工作，去实际个人的自我价值。

前面也提到，目前的运维织是一个被动保障业务系统运行，日常计划性工作容易被打断、搁置的工作，这种工作状态下的运维组织往往工作效率不高、容易出现操作风险。为了让运维组织具备可持续改进的能力，需要提高运维组织的工作效率，我们需要将运维工作专业化，整合通用性、操作性的工作，提高工作效率，在释放运维人员工作量后，引导运维人员有计划、可量化的去做更多分析类、优化类、业务运营的主动性工作。

• 流程建设：标准化、可视化、可量化

大部份运维组织会以内部企业积累的规章制度、外部监管机构的监管要求为基础，依照ITIL、ISO20000、ITSS.1、DevOps的方法论中的一个或多个组合的方式开展运维工作。这些规章制度、监管要求、方法论的整合、落地、持续改进的过程即为流程建设的过程。

流程建设首先需要标准化流程，要先梳理好己有的流程制度，约定工作的流转方式，再通过可视化将流程整合在日常工作中，最后通过流程落地数据的分析与工具建设，持续改善提高流程落地的效率，控制操作风险。

• 工具建设：自动化、数字化、智能化、服务化

工具的建设也以可持续改进的思路构建，以整合存量资源、引入成熟或开源技术为主，建立一体化的运维工具体系，通过体系化的思路实现运维工具（“监、管、控”）的互联互通，有序建设，实现自动化运维，全面控制风险、提高工作效率、释放人力；通过建立运维数据分析平台，实现数字化运营，提供运维数据集中与治理、主动分析的能力；在数字化运营的基础上通v