运维部门日常工作SOP操作指导手册

前言

为推行工作标准化作业, 加强标准化作业的管理, 规范作业指导书的编制, 实施全过程控制, 特制订本指南.

本指南的附录A、附录B为举例资料.

本指南由运维部提出并归档.

本指南起草单位: 运维部.

本指南由运维部负责解释.
范围

本指南规定了作业指导书的编制原则、依据、结构内容、格式、文本要求及应用管理的基本内容.

本指南适用于公司总部及各子公司, 并在运维部进行试点.
术语和定义

下列术语和定义适用于本指南

标准化作业

SOP(Standard Operation Procedure)即标准作业程序, 就是将某一事件的标准操作步骤和要求以统一的格式描述出来, 用来指导和规范日常的工作.

全过程控制

针对现场作业过程中每一项具体的操作, 按照工作有关法律法规、制度、标准、流程规定的要求, 对现场作业活动的全过程进行细化、量化、标准化, 保证作业过程处于“可控、在控”状态, 不出现偏差和错误, 以获得最佳秩序与效果.

作业指导书

对每一项作业按照全过程控制的要求, 对作业计划、准备、实施、总结等各个环节, 明确具体操作的方法、步骤、措施、标准和人员责任, 依据工作流程组合成的执行文件.

模块归属

对每一项作业归属模块, 目前模块分为几大类,配置变更/运维诊断/运维应急响应/项目审核/监控处理/数据中心变更

SOP文件架构

作业指导书的编制原则

以事实为基础, 考虑自身能力和可用资源.

带有一颗持续改善的心, 逐步提升运行标准.

可视化、标准化、行为化

作业指导书的编制依据

法律、法规、制度、流程.

质量管理相关文件.
作业指导书的结构内容及格式

结构

由封面、范围、引用文件、修前准备、流程图、作业程序和标准、验收记录、指导书执行情况评估和附录九项内容组成.

内容及格式

封面

内容

由作业名称、文件编号和版本号、编写人及时间、审核人及时间、批准人及时间、作业负责人、作业工期、编写部门、变更记录、建立时间(变更时间)十项内容组成.

作业名称

包含: 部门名称、工作具体流程.如: “×××部门×××工作标准作业指导书”.

文件编号和版本号

应具有唯一性和可追溯性, 便于查找.可采用企业标准编号, SOP/×××, 位于封面的右上角.

编制人及时间

负责作业指导书的编写.在指导书编写人一栏内签名, 并注明编制时间.

审核人及时间

负责作业指导书的审核, 对编写的正确性负责.在指导书审核人一栏内签名, 并注明审核时间.

批准人及时间

作业指导书执行的许可人.在指导书批准人一栏内签名, 并注明批准时间.

作业负责人

组织执行作业指导书, 对作业的进程、质量负责.在指导书作业负责人一栏内签名.

作业工期(标准工时)

现场作业具体工作时间.

编制部门

指作业指导书的具体编制单位.

变更记录

建立变更日期

格式

见附录B

范围

对作业指导书的应用范围做出具体的规定.如: 本作业指导书针对

×××部门×××组×××工作, 仅适用于该环节工作.

引用文件

明确编写作业指导书所引用的法规、制度、标准、及企业管理规定和文件.
作业指导书的应用与管理

应用

各部门按照本指南, 参照范本, 结合现场实际, 具体编写现场作业指导书.

凡常态化工作应使用作业指导书.

作业指导书须进行专题学习, 作业人员应熟练掌握工作程序和要求.

应严格执行指导书, 逐项打勾或签字,并做好记录, 不得漏项.

指导书在执行过程中, 如发现不符合实际及有关规定等情况, 应立即停止工作, 作业负责人根据实际情况及时修改指导书, 履行审批手续并做好记录后, 按修改后的指导书继续工作.

作业过程中如发现异常, 应立即汇报工作负责人, 并进行详细分析, 制定处理意见后方可进行下一项工作.异常情况及处理结果, 详细记录在指导书内.

流程发生变更, 应根据工作实际情况修改作业指导书, 并履行审批手续.建立新的工作内容, 应提前编制作业指导书.

管理

标准化作业归xxxxx, 负责全过程的推广应用和监督检查.

公司及各部门应制定标准化作业管理制度, 严格按照要求执行.管理制度每年修订一次.

使用过的作业指导书, 经主管部门审核后存档.

作业指导书实施动态管理, 应及时进行检查总结、补充完善.作业人员应及时填写使用评估报告, 对指导书的针对性、可操作性进行评价, 对可操作项、不可操作项、修改项、遗漏项、存在问题做出统计, 并提出改进意见.工作负责人和归口管理部门应作业指导书的执行情况进行监督检查, 并定期对作业指导书及执行情况进行评估, 将评估结果及时反馈编写人员, 指导以后的编写.

作业指导书的操作流程配置

配置变更

运维部-配置变更-puppet操作git-标准操作流程

运维操作SOP文档模板.xlsx

运维部-配置变更-项目下线-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-项目缩容申请-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-虚拟机转容器-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-外网端口映射-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-域名修改-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-项目配置修改-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-基础组件配置修改-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-流量切换流程-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-批处理作业流程-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-配置变更-项目扩容申请-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-数据库变更-工作标准作业指导

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-复制 mysql 实例-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-mysql 主备切换-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-上线mysql从实例-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-下线mysql从实例-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-新增数据库实例-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-初始化 mysql 实例-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-项目数据迁移-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-大表变更-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.
故障排查

运维部-故障排查-运维诊断/DNSPOD大量域名告警-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-故障排查-域名5XX-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-故障排查-网站样式异常-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.
应急响应

运维部-应急响应-流量切换-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-应急响应-数据库-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-应急响应-RabbitMQ 异常-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-应急响应-调度任务平台异常-流量切换-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-应急响应-专线中断-流量切换-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-应急响应-网络攻击-流量切换-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-应急响应-专线中断-数据库切换-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.
数据中心变更

运维部-数据中心变更-物理服务器迁移-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-数据中心变更-物理服务器上架-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-数据中心变更-物理服务器下架-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.

运维部-数据中心变更-服务器巡检-标准操作流程

流程模板图上,只是具体的操作步骤不一样而已,根据具体的实际情况做相应修改即可.
运维规范

权限管理和控制规范

• 原则上密码权限专人专用, 不共享密码
• 密码要求符合复杂度要求, 定期修改
• 权限申请要进行有效的有效期管理, 要求人员离职或调动后, 立即取消旧权限
• 对于影响系统安全的权限, 一定要在安全部门备案
• 对密码进行建档管理, 人员离职要留下秘钥, 保证对运维系统的访问权限
• 运维人员和其他具有高级权限的人员(如安全)需要签订安全保密协议
• 尽量使用堡垒机等工具来管理权限, 维护权限更新
• 注册三方工具时, 需要使用公司邮箱, 在员工离职或调动后, 接收交接工作方需要把密保手机改为自己的.

数据库规范

注意:以下规范根据个人经验情况及互联网实践整理而成,可能不是很适用,仅供参考…切勿生搬硬套,如引起的不良后果请自行负责,与本站无关…

数据库库表设计规范

• 所有的数据库、表原则上统一使用utf8编码, 如果需要使用emoji表情请使用utf8mb4编码.
• 所有数据库名以 xx_打头(便于识别和记忆及搜索,例如公司名称简写,业务类型等,当然被撞库等情况发生几率可能提升,视公司实际业务开展需求决定,仅供参考), 库名、表名必须使用下划线分割开, 全部用小写字母, 表名以库名的首字母缩写作为前缀, 以保证该表的全局唯一性.
• 库名表名都是用名词, 不使用动词, 能见名知意.
• 数据库引擎请使用 innodb 存储引擎, 不能使用 myisam.
• 存储精度浮点数必须使用decimal替代float和double.
• 非负值的数字统一使用unsigned类型存储.
• 必须使用int unsigned存储IPV4.
• 整形定义中, 不添加字段长度, 比如使用int而不是int(5), 即便定义了对字段长度、占用空间也没有意义.
• 能使用短数据类型的尽量使用短数据类型.比如取值范围是0-255时, 使用tinyint unsigned.
• 使用tinyint类型代替enum类型(记录状态).
• 禁止使用blob类型.如果必须使用text和blob类型, 建议把该字段拆分独立成一个表.大于 varchar(20000) 变为 mediutext
• 新版本的varchar(N)其中N是字符数而不是字节数.控制在255内.
• 存储年使用year类型.
• datetime类型字段, 默认值禁止使用”0000-00-00 00:00:00”, 正确的应该使用linux最小时间戳”1970-01-01 00:00:01”, 或者当前时间戳CURRENT_TIMESTAMP.
• 使用精确时间戳(精确到秒)尽量使用timestamp类型, 因为timestamp使用4字节, datetime使用5字节.
• 必须将字段定义为not null, 需要null时设置默认值(除text之外).
• 禁止在数据库中使用varbinary、blob存储图片、文件等.
• 新建表必须添加create_time(创建时间)、update_time(更新时间), 类型为timestamp, 默认值为CURRENT_TIMESTAMP.

例如: 
`create_time` timestamp DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',

• 创建表必须设置唯一主键, 推荐使用UNSIGNED自增列作为主键.
• 表结构增加字段, 字段个数不允许超过50个尤其是有text等字段的情况下,严禁使用after, 从中间添加字段, 必须从最后添加字段.
• 建表语句示例(以下为示例,不具有任何生产环境意义)

CREATE TABLE `gift_test` (
  `id` int UNSIGNED NOT NULL AUTO_INCREMENT,
  `gift_id` int(11) DEFAULT NULL COMMENT '礼品类别id',
  `gift_number` varchar(100) DEFAULT NULL COMMENT '券号',
  `gift_isdelete` int(11) DEFAULT '2' COMMENT '是否删除【1是, 2否】',
  `gift_sendstatus` int(11) DEFAULT '1' COMMENT '礼品发送状态【1待发送, 2已发送, 3发送失败】',
  `create_time` timestamp DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT '礼品发放';

建表语句engine必须设置为innodb, DEFAULT CHARSET建议设置为utf8mb4.

索引设计规范

• 索引的命名统一以index_开头, 后面包括索引字段名字, 分别以下划线分隔, 每一个字段只能占用一个名字位.如index_id_name(这是一个符合索引, 包含了id和name两个字段)
• 索引名称必须使用小写.
• 复合索引的字段数不能超过5个.
• 单表的索引数量尽量控制在5个以内.
• 必须设置唯一主键, 推荐使用UNSIGNED自增列作为主键.
• 联合索引的字段排列顺序以去重后字段的数值的个数大小排序先后顺序.比如表gift_test有id,gift_number, id有50000个独立值, gift_number有5000个独立值, 那么, 顺序是id在name前面, 建立的索引是index_id_name.
• rder by、distinct、group by后的字段尽量建立索引.
• 对于区分度不大的字段没有必要使用索引, 比如性别字段(只有2个选项).
• 根据update、delete的where尽量使用有索引的字段或主键.
• 超过20字节的varchar字段建议建立前缀索引.
• 合理创建联合索引(避免冗余), (a,b,c)相当于(a)、(a、b)、(a、b、c).
• 不能使用数据库外键, 由程序保证.
• 联表查询时, join列的数据类型必须相同, 并且要建立索引.
• Text类型字段不能使用索引.
• where语句中必须使用合适的数据类型, 避免mysql进行隐式类型转换.如id列定义成了varchar(20), 我们的sql写成select name from table where id=100;这样的sql会发生隐式类型转换.
• 尽量不使用mysql函数, 把逻辑实现在应用程序里.
• 禁止使用整表count.
• 禁止使用存储过程、视图、事件、触发器.

SQL语句开发规范

• 用in代替or, 控制sql的in列表值小于1000个.
• where语句中必须使用合适的数据类型, 避免mysql进行隐式类型转换.
• 禁止使用select *, select只获取需要的字段.
• 避免使用join和子查询, 必要时推荐用join代替子查询, join表数量不能超过3个.
• 避免在mysql中进行数学运算和函数运算
• nsert必须显示指明字段名称, 如: 不能使用insert into table values(); 必须使用insert into addressbook(fname,lname,phone,fax,email) values(‘Rob’,Rabbit,’674 1536’,’382 8364’,‘[e-mail]’);这种方式.
• 避免使用不等于条件, where条件中的不等于不能使用索引.
• 合理使用分页提高分页效率, 避免使用大的偏移量分页, 如select id from user limit 1000,10.
• 统计表中记录使用count(*), 不适用count(primary_key)和count(1).
• 禁止jira提交的任何sql脚本包含drop语句, 如果上线确实需要drop表, 请找dba单独说明.
• 所有生产环境的sql都需要提jira申请, 然后再执行.
• 禁止使用强制索引, 如 select id from user use index(idx_user_id) where user_id = 123;
• 对同一个表的多次alter操作必须合并为一次操作, 如 alter table t add column b varchar(10),add index idx_aa(aa);
• 对于delete 表操作, 如果没有 where 条件, 必须加上 limit n ; (n 建议在５万以下);
• 如果带有 where 条件, 插入、更新及删除的行数超过 5 万条以上的也必须加 limit n ;限制(n 建议在５万以下) , 并加sleep(>=3), 如果确认可以恢复数据的表请联系DBA开通truncate权限.
• 在早上8点至晚上10点之间尽量不要对数据库进行大批量数据(>30W)未加sleep限制DML操作, 如确实需要 , 先知会dba 后执行 .
• 禁止单条sql语句同时更新多个表.
• 重要SQL必须被索引: update、delete的where条件列、order by、group by、distinct字段、多表join字段.
• 禁止使用负向查询, 例如 not in、!=、not like.
• 禁止使用前导查询, 例如 like ‘%abc’, 无法使用索引.

项目规范

项目命名

• 项目名不能包含下划线, 全部中横线
• 项目名与版本库目录名一致, 不能与现有项目名类似
• 项目名称的长度不能超过30位.
• 项目命名规则:开发语言-主业务名-子业务名-应用角色

正确的命名:

nodejs-xinzheng-hr-web,

java-life-search-server,

开发语言:

php, java, python, nodejs, lua, shell, go, scala, utopia, html(纯静态), 如新增需通过运维负责人添加

主业务名:

根据自身公司开展的业务范围来定,举例:

3D / Search / Hr /

子业务名:

自定义, 只能使用字母和数字,代表此项目具体属性和作用

应用角色:

web(业务主站, 需对外解析域名),

api(服务化类应用, 需要域名但不对外解析),

boss(管理后台应用, 需对外解析域名),

dubbo(dubbo服务化类应用, 不需要域名),

service(同时支持内部和外部访问的, 以提供数据服务为主),

server(通用定义为项目的后端, 即服务端),

agent(客户端, 一个插件或探针),

res(前端资源) 其他不属于以上类型的应用角色,

如需新增报运维负责人审核后增加;

• 域名命名方式:

通常情况下, 对外解析的域名最长步超过3级, 域名的第一个字段应与项目名的第三个字段相同或相近, 原则上不允许单字母、有歧义或者与项目无关联的字母组合, 域名新增, 修改, 取消申请需要发jira流程;

boss后台项目建议取名为boss(子业务名).主域名, 例如bosswiki.baidu.com;

API项目域名请使用(主业务名).(子业务名).(开发语言).api.baidu.com
配置规范

• 项目里需要用的参数配置全部接入配置中心, 并确保配置中心的名称和项目名是一致的；
• redis缓存接入cachecloud, 原则上新项目只能使用redis缓存, 老项目可以使用统一的memcached集群缓存.
• 数据库有连接数限制默认10个, 并将连接池配置接入配置中心.
• PHP转Java/NodeJS项目, 不允许在原项目添加多个location做路由, 每个项目必须统一为单一入口.
• 提供基于业务的健康监测接口, URL统一为IP:PORT/healthcheck, 请求方式需要同时支持HEAD+GET. 没有健康检测接口的项目, 由QA推进跟踪协调处理,出现故障由开发负责人承担事故责任.
• 提供接口调用关系拓扑图或者依赖列表.
• web不直连数据库, 数据库访问调用soa等接口(如果是自己项目新建的数据库可以直接访问).
• 所有项目的字符编码必须为 UTF-8, 且必须在程序里指定, 不可以使用系统默认变量
• 遵守业界通用的伪静态URL规范, 禁止直接暴露脚本文件用于业务, 例如admin.php, index.jsp等；

资源控制

• 业务场景单一或与主站无关联, 可放置在第三方云主机.
• 资源分配:

非核心业务

PHP/NODEJS/PYTHON:1C1G;

JAVA:1C2G;

核心业务

根据需求调配,默认2C4G

• 项目重构必须确认老项目下线时间节点.
• 具有相同功能的项目不能重复申请(这种项目多以二期开发或者重构的名义申请).

数据库选型规范

目前集团运维提供且只提供Percona、Hbase、Mongodb、Elasticsearch、Solr五种数据库选型. 如需要其他数据库,请与运维负责人联系沟通
项目日志规范

日志规范组件接入

php组件地址:

java组件地址:

nodejs组件地址:

日志轮转

单个文件大小: 50M

同一文件存在备份文件个数: 10

例如: hr-web-trace.log

当前的日志输出文件为: hr-web-trace.log

当一个文件打满后，将 hr-web-trace.log 重命名为 hr-web-trace.log.bak.01(01-10)

日志输出文件为 hr-web-trace.log 不变

JAVA项目

• 日志级别必须高于info, 不允许在生产环境打印debug信息
• 日志路径统一: jetty读取jvm参数logger.root; tomcat读取jvm参数log4j.file.path
• 项目设计为多节点运行方式(必须单节点运行的项目需要提供入口开关)
• SOA项目注册到dubbo的名称必须和项目名一致
• SOA项目独立配置dubbo缓存目录并将配置项接入配置中心, 不能使用默认路径, 使用路径 /tmp/
• SOA项目端口统一使用20889端口, 容器建议使用jetty
• Jetty监听端口: 8087
• Tomcat监听端口: 8088
• Jar包直接启动监听端口: 7000
• 路径: /data/www/java/work/logs/
• 控制台日志(不允许打印业务日志): gc.log、stderrout.log（jetty）、catalina.out（tomcat）
• 业务日志: -error.log 、-info.log 、*-trace.log
• 日志格式: yyyy-MM-dd HH:mm:ss.SSS [TxId : %{PtxId} , SpanId : %{PspanId}] [loglevel] 日志内容
• NodeJS项目
• 日志路径统一为/var/log/nodejs/
• nodejs运行端口统一为3110
• 使用公司统一的框架, 使用pm2守护, 通过ua.json启动
• 业务日志: -warning.log、-error.log、*-info.log (pm2的日志也按照这种方式执行)
• 日志格式: yyyy-MM-dd HH:mm:ss.SSS [TxId : %{PtxId} , SpanId : %{PspanId}] [loglevel] 日志内容
• Python项目
• 日志路径统一为/var/log/python/
• 监听端口: 5000

PHP项目

路径: /var/log/php/

文件: dberror *-db-error.log phperror *-php-error.log

业务日志: *-app.log （其余调用，如soa等，日志打到app.log中）

日志格式: yyyy-MM-dd HH:mm:ss.SSS [TxId : %{PtxId} , SpanId : %{PspanId}][loglevel] 日志内容