运维体系研究

1. 概述

运维在IT领域中一个很宽泛的岗位，一般情况运维指的是互联网运维，随之互联技术的革新，对于运维体系也有了新的定义。新型运维和传统运维分界截然不同，本文将不过多的对新型运维和传统运维说明以基本运维展开对运维体系的深入研究。
运维，这里指互联网运维，通常属于技术部门，与研发、测试、系统管理同为互联网产品技术支撑的4大部门，这个划分在国内和国外以及大小公司间都会多少有一些不同。（百度百科）运维的工作方向比较多，随着业务规模的不断发展，越成熟的互联网公司，运维岗位会划分得越细，如：系统运维工程师、数据库运维工程师、网络运维工程师、安全运维工程师、桌面运维工程师、软件运维工程师、业务运维工程师、CDN运维工程师、IDC运维工程师、存储运维工程师、硬件运维工程师、游戏运维工程师。面临近些年企业对运维人员技能要求的象限化，技术更新快等特点。迫使运维人员不得不学习更多的技能且要有百步穿杨的本领，不仅如此还需要了解自己所处的阶段，更需要了解市场的需求，所谓知己知彼。我们在本文对体系做探索梳理，考虑到最佳实践通用性将着眼点放在运维工作内容、建设思想、技术架构实践。

1.1. 运维职责

1、保障企业数据安全
2、提供7x24小时业务持续性
3、评估产品需求及发展需求，设计网站架构
4、上线代码、配合研发搭建环境、调试、测试代码
5、监控硬件、软件及各种业务应用
6、配置收集日志和，根据日志信息报警及优化系统及服务
7、解决日常问题，如硬件（服务器、交换机、硬件、网络）、软件、各类业务服务故障
8、开发运维管理平台、及运维工具产品，提升服务效率
9、制定运维流程、规范、制度，并有序推进
10、采购服务器、选择IDC公司、云产品、CDN等产品。

1.2. 运维技能

常见技能：

• 系统安装
• Raid阵列
• 初化配置（网络、内核、iptables、服务、安全）
• 应用部署（LAMP、LNMP…）
• 监控调优（日志收集分析、流量分析、业务监控）
• 数据备份

技术点：
Linux、shell、python、LVS、Keepalived、HAProxy、Nginx、Apache、Tomcat、MemCache、Redis、MySQL、MongoDB、ELK、Zabbix、Ansible、Cobbler、Kubernetes、Docker、ZooKeeper、Hadoop...

1.3. 运维岗位

运维工程师比程序员（开发者）要少，但运维岗位的头衔可不少

• 运维实习生
• 系统管理员
• 网络管理员
• 运维工程师
• IT运维工程师
• Linux运维工程师
• 运维开发工程师
• 应用运维工程师
• 高级运维工程师
• 运维专家
• 运维主管
• 运维经理
• 高级运维经理
• 运维总监

新兴的运维头衔：

• 自动化运维开发工程师
• DevOps运维开发工程师
• 与业务强相关的岗位，如：直播运维工程师、中间件运维工程师

1.4. 运维管理

运维管理不仅是对设备应用的管理，更重要的还要对人进行管理，如何做到理想化、精细化管理可参照管理学的方法论、运维建设思路及行业标准。运维服务体系建设，应包含运维服务制度、流程、组织、队伍、技术和对象等方面的内容，整合运维服务资源，规范运维行为，确保服务质效，形成统一管理、集约高效的一体化运维体系，整合运维服务资源，规范运维行为，确保服务质效，形成统一管理、集约高效的一体化运维体系，从而保障业务、网络和应用系统安全、稳定、高效、持续运行。运维管理本身包括设备管理、应用/服务管理、数据/存储/容灾管理、业务管理、目录/内容管理、资源资产管理、信息安全管理和日常工作管理等子系统。

• 方法论：管理学、项目管理、沟通管理、质量管理
• 运维建设：监控、限流、SLA、LB、灾备、日志分析
• 规范性引用文件：
  ITIL3.0
  ISO20000
  ISO9000
  ISO27001
  ITSM（IT服务管理）
  BSM（业务服务管理）
  GB/T 28827.1《信息技术服务运行维护标准》
  GB/T 22080-2016《信息安全管理体系要求》

2. 运维体系

2.1. 运维发展阶段

• 运维1.0 石器时代
  这个阶段属于原始蛮荒运维时代，运维工作还是一个模糊的概念，负责从机房、服务器选型，软硬件初始化，服务上下线，配置监控等，运维和开发之间没有太明确的分工，基本是遇到什么问题解决什么问题。
• 运维2.0 自动化时代
  这个阶段基本属于工具时代，一般运维都是找各种开源或自己写的脚本工具来辅助日常运维工作。充分体现运维人员对业务的理解程度，一定程度上优化了运维工作。可以建立标准、规范、制度以形成体系。
• 运维3.0 平台化时代
  这个阶段主要是面向服务化统一管理的时代，云、虚拟化技术的盛行对运维技能要求发生了革新，对运维象现化突出分工变的明确，从单一运维工程师演化出多个头衔。运维对一套完整的解决方案的需求变得非常强烈。此时运维体系是建立标准、规范、平台化的最佳实践。
• 运维4.0 智能化时代
  这个阶段已经是一切旨指令的时代，人人旨开发接口管理，统一管理，正是容器技术盛行的时代，对云技术也产生了翻天腹地的变化。技能要求更是专一化，高标准化。工欲善其事，必先利其器，数据是一切智能运维的根基。当基础设施固定下来，运维模固定下来，这些模式会把包括可用性、扩容等场景的运维方案包含进来，平滑的把开发加入运维体系架构中。
  

自动化可以提高运维效率、提高系统弹性、降低管理成本、降低人为风险

2.2. 运维体系框架

企业IT部门面临越来越复杂的IT基础设施与架构,以及众多企业、地域、人员和品牌的管理。提升IT服务能力和业务组织保障能力的关键要素在于如何有效管理企业IT部门,充分整合IT部门资源、人员、技术、以及流程,并发挥最佳效力。下面是ITIL/ISO20000/ISO/27001的实践。

由公安部第三研究所等主办的我国网络安全等级保护制度2.0国家标准（简称“等保2.0标准”）网络安全等级保护制度2.0国家标准的发布，是具有里程碑意义的一件大事，标志着国家网络安全等级保护工作步入新时代。下面是ITIL/ISO20000/ISO/27001、等保2.0的设计。

2.3. 运维体系内容

运维体系的组成部分
• 资源管理
• 服务器、虚拟机、网络设备、存储、IP/VIP、域名…
• 配置管理
• 系统配置、网络配置、应用配置、应用分组、SLA级别配置…
• 监控
• 系统监控、网络监控、应用监控、安全监控、容量监控…
• 应用管理
• 上线、发布、下线
• 集群管理
• 扩容、缩容
• 事件管理、变更管理、问题管理、故障管理
• IDC管理、存储管理、数据库管理、采购管理

运维体系文件
• 运维文件管理规范
• 信息安全资产管理规范
• 信息安全事件管理规范
• 源代码安全管理规范
• 配置变更安全管理规范
• 运维流程、制度、标准文件
• 团队组织、规划、平台建设

运维服务流程
• 事件管理、工单管理、问题管理
• 变更管理、配置管理、
• 知识库管理
• 运维报告管理

2.4. 运维体系建设原则

运维体系的建设应该从大环境考量，结合企业实际情况去繁从简，从“容易使用、容易管理”的先后顺序，由重到轻的依次解决客观存在的问题，以便最大程度的加快运维体系的建设的目标。
• 以完善的运维服务制度、流程为基础。为保障运行维护工作的质量和效率，应制定相对完善、切实可行的运行维护管理制度和规范，确定各项运维活动的标准流程和相关岗位设置等，使运维人员在制度和流程的规范和约束下协同操作。
• 以先进、成熟的运维管理平台为手段。通过建立统一、集成、开放并可扩展的运维管理平台，实现对各类运维事件的全面采集、及时处理与合理分析，实现运行维护工作的智能化和高效率。
• 以高素质的运维服务队伍为保障。运维服务的顺利实施离不开高素质的运维服务人员，因此必须不断提高运维服务队伍的专业化水平，才能有效利用技术手段和工具，做好各项运维工作。

2.5. 运维体系建设之人员

运行维护队伍建设
• 队伍组建：针对目前信息系统IT资源现状以及对技术支持的需求，组成各类别维护人员的专家队伍，集中的开展运行维护工作。
• 人员管理：对各级运行维护人员尤其是高级运行维护人员的管理，应制定一套切实可行的管理办法，包括人员配置、职责划分、人才库建立、人员培训、人员考核、人员待遇等。通过科学的管理办法和有效的激励机制，充分调动各级运行维护人员的工作积极性和责任心，为做好信息系统运行维护工作打好基础。

2.6. 运维体系建设之技术

工单系统、知识库、监控系统、发布系统、任务系统
参考资料《运维体系建设介绍PPT》如下图：

自动化设计（git/svn代码查看模块、jek×××集成打包模块、docker仓库操作模块、k8s编排模块、cmdb资产管理模块、安全审核模块、运维服务模块、日志监控模块、网络安全模块、权限模块）

3. 运维实践

3.1. 运维架构

高性能设计
• 以用户为中心，提供快速的网页访问体验。主要参数有较短的响应时间，较大的并发处理能力，较高的吞吐量，稳定的性能参数。
• 可分为前端优化，应用层优化，代码层优化，存储层优化。
• 前端优化：网站业务逻辑之前的部分；
• 浏览器优化：减少Http请求数，使用浏览器缓存，启用压缩，Css Js位置，Js异步，减少Cookie传输；
• CDN加速，反向代理；
• 应用层优化：处理网站业务的服务器。使用缓存，异步，集群；
• 代码优化：合理的架构，多线程，资源复用（对象池，线程池等），良好的数据结构，JVM调优，单例，Cache等；
• 存储优化：缓存，固态硬盘，光纤传输，优化读写，磁盘冗余，分布式存储（HDFS），NOSQL等；

高可用架构
大型网站应该在任何时候都可以正常访问。正常提供对外服务。因为大型网站的复杂性，分布式，廉价服务器，开源数据库，操作系统等特点。要保证高可用是很困难的，也就是说网站的故障是不可避免的。

参考资料《小团队如何从零搭建一个自动化运维体系》如下图：

大型网站架构目标

• 高性能：提供快速的访问体验。
• 高可用：网站服务一直可以正常访问。
• 可伸缩：通过硬件增加/减少，提高/降低处理能力。
• 安全性：提供网站安全访问和数据加密，安全存储等策略。
• 扩展性：方便的通过新增/移除方式，增加/减少新的功能/模块。
• 敏捷性：随需应变，快速响应。

大型网站架构模式

• 分层：一般可分为，应用层，服务层，数据层，管理层，分析层；
• 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页，用户中心。
• 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。
• 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。
• 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。
• 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应，等服务端处理完毕后，使用通知或轮询的方式告知请求方。一般指：请求——响应——通知 模式。
• 冗余：增加副本，提高可用性，安全性，性能。
• 安全：对已知问题有有效的解决方案，对未知/潜在问题建立发现和防御机制。
• 自动化：将重复的，不需要人工参与的事情，通过工具的方式，使用机器完成。
• 敏捷性：积极接受需求变更，快速响应业务发展需求。

3.2. 运维实战

实战目的将以最快、最全面的思路建设高可用、高性能、自动化生产环境。提高网站的访问速度，容错性，冗余性。

准备相关工作
预估PV、带宽
服务器、IDC、CDN选型
批量安装系统（cobbler）
初始化系统（服务器时间同步、SSH-KEY打通、计算机命名、设置DNS、设置环境变量文件、优化内核参数、配置yum源、建立统一目录、部署统一应用、）
安全基线（关闭不启用的服务、ssh安全策略、密码策略、创建Ops操作用户、设置sudo文件权限、设置历史命令、删除不必要的用户、日志审计）
后续相关工作
自动化工具推送
代码上线部署
灰度发布
业务监控报警
日志收集分析

实验拓扑图

• 物理拓扑
  

• 逻辑拓扑
  可以使用nginx反向代理高可用的方式发布web服务，动静分层不分离的架构
  本次实验采用apache+php-mod
  

• 环境配置
  

可以使用haproxy负载均衡nginx+php-fpm动静分离的方式发布web服务
本次实验采用nginx+php-fpm

• 环境配置
  

• 数据走向
  用户请求动态资源时，通过LB（Master）将用户请求分发给后端的动态服务器，动态服务器接受请求并转发给php处理，php到共享存储中查找动态内容处理请求，将响应报文发送给动态服务器，由动态服务器将响应报文发送回LB，最后再发给用户。
  用户请求动态资源时，通过LB（Master）将用户请求分发给后端的静态服务器，静态服务器接受请求，到共享存储中查找静态内容处理请求，由静态服务器将响应报文发送回LB，最后再发给用户。

• 实验需求
  使用Keepalived实现高可用
  LB(LVS、HAproxy、Nginx)实现负载均衡
  Lamp(Lnmp)实现动静分离的资源请求
  使用手动更新发布，支持热部署
  灰度发布
  故障回滚
  自动监控

3.3. 常见架构方案

一般架构应该先做功能切割再做LB，数据同步很麻烦。小规模网站不建议直接上分布式(数据一致、服务可用、容错)较复杂。好的架构是通过迭代演变而来的，不是直接设计出来的。
单机升级--->系统分层--->业务切分（数据切分）技术达到上线--->最终选择分布式架构

Lnmp + wordpress 单台
wordpress代码发布：目录有多种方式1.单目录、2.多目录、3、共享目录（rsync）

• 单目录方式，代码发布没有问题显示正常

• 多目录方式，代码发布有问题显示不正常

Nginx 配置文件如下图：

• 共享目录方式，代码发布没有问题显示正常

• 方式一：使用共享存储的方式，将代码统一存放挂载至共享目录
• 方式二：使用rsync同步目录的方式，将代码目录文件同步更新
• 方式三：使用软链接的方式，将代码目录文件同步更新

Lamp + wordpress 多台（分离）
wordpress代码发布：apache和php分离的架构，代码放在不同主机上

构建分离式LAMP(LNMP)有两个问题：
•应用程序如wordpress，需要在apache(nginx)和php两台服务器上安装，浪费空间
•用户上传的文件，如图片无法显示，因为上传的文件是被放到PHP上，而客户端
访问读取时在apache上找不到
注意: apache服务器和php服务器的网站目录结构需要保持一致。

•解决方案：1.使用同步机制，如rsync+inotify，同步web和php服务器；2.使用共享存储，如NFS；3.对程序进行二次开发

4. 运维解决方案

4.1. 应急响应

当生产中心出现故障导致业务中断时，需启动应急响应预案，快速定位问题，解决问题，恢复业务；避免业务中断造成损失。
参考资料《运维制度及流程》如下表：

4.2. 业务连续性

BCP（业务持续性计划）在DRP的基础上增加了风险分析、业务影响分析、业务恢复预案、恢复策略与方案和人员架构组织保障的内容，它面向企业关键业务持续、有效动作是灾难事故的预防和反应机制。
BCM（业务持续性管理）又把BCP的外延内容扩大到了紧急时间的应急相应处理、危机通讯与危机公关、灾难事件应急响应处理和供应链或关联单位的危机管理，它面向企业潜在的风险，考虑内部风险控制及外部利益相关单位，建立一个完善的机制预防或减少损失。

4.3. 灾备

DRP（灾难恢复计划）的核心是IT的备份和恢复，还包括围绕IT备份与恢复的灾难恢复资源，灾备中心的运营管理和切换、重续运行与回退预案几部分内容，它面向信息系统及所支持的业务功能，从灾难造成的故障或瘫痪状态恢复到可接受状态。

5总结

1、通过对运维整个体系的概述对技架构我们要根据用户访问的路线，来考虑用户访问习惯，从而决定架构的部署；画出逻辑架构图，标记出数据包的走向
2、要有分析业务的能力，按照业务把应用进行对应如：在线交易、在线社交、在线游戏、在线视频、在线浏览
3、对架构知识有清晰的思路
架构分析--》业务压力模拟和计算---》带宽、网络设备、服务器、安全设备选型---》搭建测试环境---》压力模拟测试---》上线----》后续维护（监控、压力下的调试）
• 如果不做静态化
用户--》分发层---》应用层---》数据库---》数据库存查询缓存---》结果返回给应用服务器---》返回给用户。
• 做了静态化（被查询访问过的结果页面会被自动生成静态化文件，存在静态服务集群）
用户---》分发层（判断被访问页面哪些是静态）---》静态/应用层服务器

静态化：所有被访问页面的结果，生成一个单一的文件，存储在文件系统层
静态资源：静态内容，客户端从服务器获得的资源的表现形式与原文件相同
动态资源：程序文件，需要在服务器执行之后，将执行的结果返回给客户端

4、自动化ansible playbook

- host: 
  vars:
  remote_user: 
  tasks:
    -
    -
  variables:
    -
  handlers:
    -

安装php为例：

 - hosts: webapp
  remote_user: root
  gather_facts: no
  tasks:
    # 安装epel源
    - name: install epel-release repo
      yum: name=epel-release state=present
    # 安装remi源
    - name: install remi-release repo
      yum: name=http://rpms.famillecollet.com/enterprise/remi-release-7.rpm state=present
    # 安装php5.6
    - name: install php
      yum: name={{ item }} state=present enablerepo=remi enablerepo=remi-php56
      with_items:
       - php
       - php-fpm
       - php-devel
    # 开启php-fpm服务
    - name: start php-fpm
      service: name=php-fpm state=started enabled=yes
    # 复制index.php文件到网站根目录
    - name: copy index.php
      copy: src=index.php dest=/u01/www/nginx/html/index.php
      notify: restart nginx
    # 重启nginx

  handlers:
    - name: restart nginx
      service: name=nginx state=restarted

注意：ansible具有幂等性，因此会自动跳过没有变化的部分，即便如此，有些代码为测试其确实没有发生变化的时间依然会非常地长。还有一个问题当第一次执行成功了，再下一次不小心改错配置文件，一般情况是不容易发现的，所以一定要看执行过程验证结果。
错误配置如下：restartedd多写了一个d

# vim roles/lbsrvs/handlers/main.yml

报错信息如下

如果第一次执行成功，而第二次 # vim roles/lbsrvs/handlers/main.yml 不小心改错。
则不会报错，因为没有触发执行所以看不出roles/lbsrvs/handlers/main.yml 有问题。

5、运维过程中遇到问题的排错思路
第一步首先要检查服务存活

第二步telnet检查网络影响
第三步外部因素如系统负载、应用BUG、网络问题、域名解析

下面我们举例说明一下，如lnmp分离构建，nginx 调用 php-fpm报错问题
502 Bad Gateway

# tailf /var/log/nginx/error.log 查看日志报错如下

1）看到表面的报错信息大部分人会想到googel、baidu一下，但是即使你上网查到了相关资料但未必是你最需要，因此有良好基础是最关键的。
2）我们需要检查相关服务是否存活，通过排查没问题。
3）下面就是对问题的深度研究，需要理解正确的架构模型、服务间的调用关系、分析相关DEBUG日志、网络抓包分析，配置文件参数，TCP连接队列等。针对此问题经判断确认架构模型无问题；那么服务间调用是fastcgi协议，经分析不是协议特性的问题；再次展开分析，php-fpm默认是不打开子进程的日志输出的，手动打开：php-fpm的debug日志。

# vim /etc/php-fpm.d/www.conf
catch_workers_output = yes
# systemctl restart php-fpm

telnet php-fpm的9000端口发现Connection closed by foreign host.

通过tcpdump抓包分析我们发现报文中有rst标志位，首先会想到是网络问题，网络相关配置参数都需要注意，由其是在生产环境高并发的业务中。

# tcpdump -nn -vvv -s 1500 -i ens33 dst port 9000 and src 192.168.200.201 -w /tmp/php-fpm_502

接着打开php-fpm错误日志，发现确实是主机权限问题，调用IP不在访问列表内
# tailf /var/log/php-fpm/error.log

通过检查配置文件发现竟然配置成0.0.0.0会出现问题，由此证明了运维工作是一个小心小心再小心，谨慎谨慎再谨慎，仔细仔细再仔细，容不得一点马虎不光是配置错误的问题还有对影响问题要考虑全面，从安全角度看就不应该出现未受权访问的问题，设置权限太宽泛固然很不好的习惯，不管是测试还是生产一定要有良好的习惯与标准。
# vim /etc/php-fpm.d/www.conf

最后针对php-fpm配置文件问题除了语法错误外就是需要对服务器性能做指标计算（单台cpu、内存、io大小、网络），设置合理的参数值即可。

• 注意：Nginx有两份fastcgi配置文件，旧的「fastcgi_params」和新的「fastcgi.conf」，它们没有太大差异，后者比前者多了一行「SCRIPT_FILENAME」
  使用旧的fastcgi_params的方式，不推荐此方式

  /scripts$fastcgi_script_name;       需要改模板
  /var/www/foo$fastcgi_script_name;   硬编码的方式
  $document_root$fastcgi_script_name; 可以使用
  include        fastcgi_params;

推荐方式

fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
include             fastcgi.conf;

4）因此其它因素中出现的问题大家未必一样，但整体解决问题的思路是一样的，那么我们就不过对此进行阐述了,希望今后在踩坑的过程中能够帮到大家。

6、大规模自动化运维
• 1000台物理机怎么管理
• 1000台容器机怎么管理
先把ip密码对应写到一个文件里然后你遍历hosts 关联那个文件对应的密码

这是一个值得深入研究学习的话题，我们在此仅是对相关技术点进行一下罗列，今后会有专项的技术博客推出，敬请关注。随着流量变大，使用动静分离、读写分离、主从同步、垂直拆分、CDN、MVC 等方式不断提升网站的稳定性。面对更大的流量时，通过垂直拆分、服务化、反向代理、开发框架（站点/服务）等等，不断提升高可用。在面对上亿级的更大流量时，通过中心化、柔性化、消息总线、自动化（回归，测试，运维，监控）