## 互联网运维规范建议

> 本建议是基于畅捷通运维部共享的运维规范修订而成，目标是帮助互联网团队建立起运维规范，规范化运维团队的各项工作，提高系统稳定性。本建议会持续完善并不断引入案例，以帮助团队更好的规范化自己的运维工作。

### 1. 运维方案的备案制度


1. 运维团队内部在解决某个问题时候经过讨论确定的一系列问题的统一解决方案，称为一个解决方案。
2. 所有解决方案必须整理成文，记录清晰并在团队内公开。
3. 所有公开的方案，未经充分讨论禁止擅自更改。
4. 所有公开的方案，团队内部必须严格遵守。
5. 所有对现有已确立的方案作出调整的需求，必须向运维负责人提出并同意后，重新讨论确认新方案，并更新为新方案，旧方案即刻废止。
6. 所有已确立的方案，在文档库（Wiki、SVN或者Git）中指定位置统一存放，保持最新。

### 2. 系统登录权限规范

1. 测试环境&开发环境（园区机房和阿里云）

	1. 不走堡垒机
	2. 使用ldap账户登录授权的服务器

2.	生产环境（外部机房和阿里云）
     1. 走堡垒机
     2. 运维组

     	可以登录主机，具有上传下载等所有权限，使用ldap账户。
     3. 研发组

      	* 命令限制，只能执行查看日志的相关命令，不具备删除，重启，sudo等命令操作权限。不能登录运维系统网段主机。
	  	* 使用ldap账号登录堡垒机，堡垒机机将以统一账号登录主机。

###  3. 操作系统规范

1.	操作系统版本
	* CentOS 6.4 64bit 2.6.32-358.el6.x86_64
	* Ubuntu 12.04 64bit 3.5.0-23-generic
	* Ubuntu 14.04 64bit 3.13.0-24-generic
	* Ubuntu 14.04.2 64bit 3.13.0-32-generic
2.	网卡配置
	* 物理机
		* eth0为内网
		* eth1，eth3绑定为bond0，为生产网
	* 虚拟机
		* eth0为生产网
		* 园区内无内网环境
	* 阿里云
		* eth0为生产网
		* 无内网
3.	主机名规范
	* 阿里云主机名规范
		* 采用默认实例名称做为主机名，不再进行主机名更改
	* 外部机房和园区机房的主机名规范
		* {环境}-{产品线}-{应用类型$主机序号}-{硬件类型}-{机房}
		* 环境：产品线，应用类型：参照cmdb。主机需要：为两位，如01,02,03
		* dev：开发环境
		* test：测试环境
		* stage：预发布环境
		* prod：生产环境
		* 硬件类型：
			* p，物理机，
			* v，虚拟机
		* 机房：
			* o，园区，
			* vnetz，世纪互联
		* 举例
			* prod-productname-rest01-p-vnetz

4.	机房ssh端口
	* 外部机房：10622 
	* 阿里云：10622 
	* 园区：22 

#### 4. CMDB信息规范
1. CMDB结构分级
	* 所有产品一级为产品线、二级为应用名称、三级为工程名、四级为环境名
	* 每一级都有英文名与中文名，中文名便于识别，英文名便于系统重用，英文名和中文名都是必填项

2. CMDB内容操作要求
	* 产品线、层级、英文名、中文名，由业务运维人员、DBA填充其负责产品或者数据库的内容
	* 信息要保持高度准确
	* 如果数据不完整或错误立即更正

#### 5. 事件管理

1. 事件管理的关键是树立流程意识，对流程的严格贯彻执行，需要某类任务的负责人把关自己所负责的服务，如DNS解析，DNS修改的负责人，要提醒申请人走hades流程申请。
2. 确立流程负责人制度，对流程责任人所负责的任务要求监管其合理性，是否可执行，对特殊hades无法填写清楚的需求及时与运维开发反映，通过修改hades程序完善已有流程。
3. 流程申请的好处在于公开、规范。
4. 外部请求类事件
	1.	外部请求指非运维人员对运维人员提出的服务需求，举例：申请DNS，开通服务器访问权限等。
	2.	常规外部请求全部走hades的流程系统
	3.	确立每个流程的责任人，责任人要提醒需求方走系统申请，同时责任人维护自己所负责的流程。
5. 内部事件管理
	1.	指运维部门内部人员之间的服务需求，举例：重装系统，维修机器，申请DNS等。
	2.	内部请求同样走hades流程系统。
	3.	对hades流程中不存在的流程，可以通过口头或者邮件的形式请求服务，可以不走hades系统。

#### 6. 故障报告制度
1.	由运维人员或者开发人员的过失导致的线上服务异常的情况称为故障。
2.	解决故障与编写故障报告是处理故障的两个基本步骤。
3.	故障报告制度有利于总结问题，优化原有服务避免类似问题再次出现。
4.	故障报告的编写人为处理故障的总负责人，报告对象根据影响情况分为内部通报与外部通报。
5.	故障报告的组成部分如下：
	1.	项目基本信息
	2.	故障现象描述
	3.	故障分析及处理过程
	4.	故障处理结果
	5.	遗留问题及改进方法

#### 域名使用规范
1.	公司正式使用域名

2.	二级域名管理要求
	1. 设置保留二级域名域
	2. 现已使用但未规划的二级域名进行逐步清退
	3. 新增二级域名需经过，产品、运维、运营确认后方可开通使用
3.	域名取名规范
	1. 域名中只能包含以下字符：
		* 26个英文字母
		* “0，1，2，3，4，5，6，7，8，9”十个数字
		* “-”（英文中的连词号，不得用于开头及结尾处）
	2. 域名中字符的组合规则：
		* 在域名中，不区分英文字母的大小写
		* 域名的长度保证在10个以内，自生成的随机域名在15个以内为佳
		* 整体长度不得超过26个字符（包括".")
4.	域名申请


6.	测试环境域名规划
	1. 命名规范：类型+(-)+产品名及域名
		* 研发环境：dev-XXX(产品名).yonyou.com
		* 测试环境：test-XXX(产品名).yonyou.com
		* 预发布环境：stage-XXX(产品名).yonyou.com
		* 生产环境：XXX(产品名).yonyou.com
	2. 例子：
		* 研发环境：dev-sdp.yonyou.com
		* 测试环境：test-sdp.yonyou.com
		* 模拟环境：stage-sdp.yonyou.com
		* 生产环境：sdp.yonyou.com

		
#### 自动化管理
1.	业务自动化
	
	运维人员根据自动化需求，自行建立自动化工具（rundeck）任务，执行日常管理任务（含升级任务）
2.	例行任务
	
	例行任务由自动化工具（rundeck）的自动执行功能例行执行
3.	自动化任务命名与层级要求
	

	所有自动化工具（rundeck）任务必须采用CMDB同等层级进行级别建立，对应第一、第二、第三级别建立一一对应的层级关系
4.	自动化任务信息采集要求
	
	使用层级方式通过API方式获取CMDB中对应层级的主机列表

#### 应用上线规范
一、	要求

1.	各研发团队部署上线应用所用操作系统、中间件、数据库、缓存等必须公司技术委员会公布目录内的产品。未目录内产品一率不接受上线申请。
2.	各研发部部署上线应用需经过产品管理部确认，并通过技术委员会审议。（新产品）
3.	应用上线、更新前，需提供安全验证报告。如有遗留安全问题需安全组长确认，才能进行更新部署
4.	各产品上线前需提前告知运维团队。
	* 新部署应用需增加服务器、或大版本更新，提前三天
	* 有系统、中间件调整、或中型版本更新，提前两天
	* 只代码更新的可当天上午申请
5.	更新时间与频率由各研发部与运营、运维商议确认。不设固定规则。
6.	发送更新申请前需准备完成更新代码并上传至上线SVN库中，数据库脚本发送至DBA邮箱
7.	运维人员会在收到更新申请，30分钟内确认上线时间。
8.	产品上线时需要有测试人员全程参与进行。

二、	规范

1.	每次应用更新，准备工作完成后，需由各部门指定人员，在工作圈运维协作中提出正式申请，运维同事会按发送更新申请前后顺序，依次进行更新。
	1. 测试
		* 在代码开发完毕后首先集成测试环境测试，然后上线模拟环境。
		* 开发人员对各自开发模块功能文档化并制定测试方案，特别注意临界点测试方案。
		* 开发人员相互交换测试方案并对系统进行交叉测试。
		* 记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试方案测试结果报告。
		* 内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。
2. 上线时间要求
	1. 可不停机的更新的应用，必须在工作日周一至周四下午3点半前提交更新申请。（周五及节假日前一天禁止应用上线、更新）
	2. 需停机更新的应用必须在晚上9点钟以后进行
	3. 除以上两种正常更新申请后，特殊申请上线，必须有各朵云总经理与技术负责人的确认后进行更新操作  
3.	上线过程
	1. 经技术开发以及业务需求测试完毕且确认无误后撰写上线方案，并提交相关技术负责人审核。
	2. 上线方案须包括旧应用程序、数据备份等等相关原系统的所有信息副本，以便在出现升级失败后能重新恢复至先前状态。制定合理的上线时间以及上线失败的回退步骤。
	3. 上线后再交由业务及需求人员进行正式环境测试，并记录测试结果及问题，提交至系统开发人员。如若出现问题不能在计划内时间解决，执行回退方案，并暂停应用更新24小时，第二次更新需研发部部门经理发送应用更新申请。应用更新失败两次，暂停3天应用更新。每三次更新，需研发部部门经理发送应用更新申请，并经云操作系统研发与运维部确认。应用更新失败三次，暂停应用更新，整改完成后，报研发中心总经理确认恢复。
	4. 技术开发及相关业务保持对上线后正式生产系统进行有计划地监测，及时发现问题处理问题。
4. 提交相关文档
5.	禁止在应用目录下生成任何日志文件或自增文件等不在SVN版本库控制的文件。违者暂停应用更新72小时。
6.	紧急、意外情况由各研发负责人确认。

三、	应用需遵循的开发规范

1.	禁止的工程目录中存放任何除必须程序文件以外文件，特别是自增文件，如有需要存放，请与运维人员联系，指定专用目录。保证应用完用依赖于SVN代码库中文件。不存在本地文件依赖、第三方库文件依赖。
2.	配置文件统一在工程目录的“config"目录中，里面一般存放有两个标准配置文件。db.config文件中，应用所配置数据库、缓存都在此配置（后面会通过技术手段对此文件进行加密）。api.config文件中配置所调用其它应用的地址信息
3.	应用自调不能使用域名，只能使用localhost本地调用。保证应用支持多域名，为灰度发布做准备。
4.	SVN中不能上传与线上环境冲突的文件。

四、	上线步骤（畅捷通）

1.	研发、测试完成后，通知各研发部QA。
2.	QA将研发代码与线上代码对比合并后，更新集成测试环境
3.	集成测试环境测试通过后，由QA发送更新上线申请邮件给运维同事。运维更新线上模拟环境，相关人员验证后，通知运维同事。
4.	在WIKI中编写应用上线更新申请4. 上线更新申请
5.	在工作圈——运维协作发出更新通知，通知中要有"更新内容简要说明""更新SVN版本号"“WIKI更新申请地址” 
6.	如果产品需要灰度，请标注需要先灰度
7.	灰度更新分支：（X3系统不适用于此规范）
8.	测试人员在模拟环境中验证通过后，告知运营的同事，可以进行灰度上线
9.	运营人员参考测试人员模拟环境测试的结果做出决定。
10.	如果确认进行灰度，在工作圈更新申请贴子里，回复，同意进行灰度
11.	运维人员灰度完成后回复贴子告知运营人员进行灰度验证。
12.	运营人员确认灰度成功后，回复更新线上环境
13.	运维同事进行线上正式环境更新。
14.	验证通过后，更新结束。

五、新应用第一次部署

1.	提供应用部署说明，应用部署架构图
2.	确认应用被哪些应用调用，自己调用哪些应用
3.	应用依赖的组件，如Redis等
4.	通过哪些监控确认应用是否正常

### 致谢

感谢畅捷通运维部共享此互联网运维规范，特别感谢熊昌伟和倪海涛为本规范做的努力。