运维思路

DBA
负责数据库设计、优化，以及类SRE的变更、监控、数据备份和报警处理工作。还负责数据库管理平台、中间件开 发以及数据库安全工作
运维研发
运维平台开发工作，如监控、服务管理等各种运维自动化系统/平台。
运维安全
安全体系加固，入侵检测，安全事件处理，常规安全扫描，渗透测试
运维工作
NSRD ECOMRD PSRD INFRD
当进程退出后自动将应用重启，能够限制重启次数和时间 支持start/stop/status等接口，启停进程，查看状态 能够对进程资源进行限制，比如mem超过500mb则进行重启 提供方面的接口，可以在应用启动、停止等情况是添加自定义行为
监控告警
报警合并 66%
报警分级
告警依然太多，避免重要短信被淹没 梳理告警，划分为5个级别，P0~P4
预算单 产品线 机房 机器列表 型号配置 服务器IP 机架位置
系统版本
到货时间
……
资源管理
机器交付 新采购
资产管理
报废 系统运维 机器故障
服务管理
应用运维
服务管理，以树的形式将硬件资产、应用服务、人和权限等多维度信息关联
产品线->服务->模块 机器<->模块 模块<->进程 服务<->监控模板 机器<->人 产品线<->域名 模块<->状态、路径、版本 …
现状
G4 高科时代
理论
平台
标准
运维体系 Architecture
服务平台
OUTLINE
运维标准 资源管理 监控告警 服务变更 容灾预案 运维安全 运维效率
运维标准
标准化是服务可运维的基础，也是实现自动化的必要条件
基础设施
服务器标准化套餐，均衡型、高IO、高CPU.. 机柜使用标准 布线标准 标签和二维码
例行检查
理解例行检查列表的内容、检查项的含义以及可能引发的问题 按照例行检查表，定期检查系统状态，发现异常立即通报并推进解决 定期检查线上服务模块，排除可疑进程, 发现问题及时通报 理解监控和统计报表的各项含义，每天定时检查报表，发现异常立即通报并推进解决 制定服务例行检查要点和方法，部署执行并不断完善，避免检查的盲点
服务变更
WEB操作 标准
程序启停方式标准化，统一的run.sh接口，支持start、stop、restart、healthcheck…. 服务部署路径的标准化，避免繁琐的配置 变更前备份方式的标准化，路径、命名规则、备份方式…… 服务通过服务树进行管理，可以方便的进行筛选，部署一批同类型的服务 所有机器上都一个负责具体命令执行和反馈的agent
运维职责
什么是运维？
运维职责
互联网运维工作始终以服务为中心，以保证产品的稳定、安全、高效运行为目标
稳定 • 指产品向用户提供服务的可用性、准确性、完整性，访问速 度及用户体验符合产品的设计与预期 安全
• 指产品运行在安全，可控的状态下，包括用户访问安全，抵 御恶意攻击，网络故障，数据安全等抗风险能力符合产品的 服务要求
监控与统计
执行监控配置，并完善监控内容，提高报警准确度 完成服务的各种监控、运维报表开发，并不断完善
故障处理
熟悉服务日常故障处理方法和预案执行要点 对已知线上故障能按流程进行通报并按预案执行 及时处理并回复相关的服务报警信息
能透彻分析报警原因,并推动报警问题解决 能发现服务隐患，总结处理方法和提出预案改进建议
服务变更
编制或审核上线步骤、回滚方案 确认是否可以触发变更及变更效果是否符合预期 紧急情况下控制回滚
服务管理
掌握所负责的服务及服务间关联关系、服务各种资源 能够发现服务上的缺陷，能及时通报并推进解决 理解运维相关文档，及时更新运维相关文档。
机器管理
熟悉服务器资源状况，机房分布情况，不出现机器遗漏或丢失的情况 合理使用服务器资源,根据不同服务的需求，安排不同配置的服务器，不浪费机器资源 保证服务器正常运行，对服务器硬件添加或变更来解决资源不足问题
20
10
2005年
497 11 45
2006年
1158 21 55
2007年
3000 42 1
2008年
4196 82 51
0
运维压力
业务发展得很快，而运维处在产品末端，将全周期 地承受着产品与缺陷带来全部压力
任何产品，需求、设计、测试的周期都是有限的，但是其 运维周期是无限的 在上游引入的任何缺陷，最终都由运维承担；但上游是无 法感受到运维压力的 随着业务增长，产品与缺陷带来了极大的运维压力
IP使用标准
1U 1 1 1 1 1 1 1 2 1 2 1 3 1 3 1 3 1 3 1 1 U U U U U U U U U U U U U U U U U U U U 45 U
TOR
环境
操作系统版本统一 centos/redhat… 系统参数初始化标准 部署路径， /home/work? /opt ? 生产环境账号，root? work? 主机命名规范 jx-cp-se00.jx sd-im-mq01.bj ? agent部署和升级标准
3U8 3U8
3U8 3U8 ILO
应用
日志输出和切分的规范 应用启停接口 ./run.sh start/stop/restart/status 端口使用 依赖标准
OUTLINE
运维标准 资源管理 监控告警 服务变更 容灾预案 运维安全 运维效率
资源管理
资产管理
服务器 IDC 机柜 IP 域名 网络设备 配件 采购时间 所属机房 …
资源管理
资源管理
总体资源使用情况，各个部门、各个产皮线资源使用情况
是否充分使用？ 是否有资源闲置？ 新采购原因和历史？
OUTLINE
运维标准 资源管理 监控告警 服务变更 容灾预案 运维安全 运维效率
监控告警
价值
通过各个层面的报警，快速的定位和发现故障 能够监控的数据展示，反应业务的容量和性能 能够清楚的通过数据来量化业务运行状态
故障处理
域名 管理
安全 扫描
硬件 测试
预案 整理
CDN
ntp
系统 安装
数据 备份
运维工作
运 维 研 发 应用运维 DBA 运 维 安 全
系统运维
系统运维
IDC、网络、CDN和基础设施（lvs，ntp，dns等）建设、资产管理平台和服务器采购、安装、上架和维修
应用运维
日常业务运维工作，参与服务变更、监控、容灾和数据备份，每日服务排查，故障应急处理以及常规运维工具开发 工作
运维工作——应用运维 2
预案管理
确定服务所需的各项监控、系统指标的阀值或境界点，以及出现该情况后处理预案 建立和更新服务预案文档，并跟据日常故障情况不断补充完善，提高预案完备性 能够制定和评审各类预案，安排预案的演练，提高可执行性
数据备份
按线上数据备份规范来进行数据备份工作 保证数据备份可用性和完整性 制定数据备份策略,根据备份要求及时变更 定期完成数据恢复性测试
HOW?
运维压力
依赖人的手工操作是当前运维的主流方式
虽然有工具、系统，但是分散、零乱，无法产生规模 信息关联方式简单，信息挖掘基本靠人，无法进行大信息 量处理与分析，信息孤岛林立 重复性工作较多，效率较低，实时性不高 人工失误率无法消除，几乎成为“系统误差”
HOW?
运维压力
日益增长的业务量带来的运维压力 和 落后的运维生产力之间的矛盾
高效 • 指系统运营的效率、以较小的资源投入带来最大的用户价 值，如单机负载、资源利用率、数据传输效率、更新周期等
运维职责
运维的工作有哪些？
运维职责
压力 测试
hadoop
日志 统计
数 据 库
nginx
工具 开发
监控
机器 采购
网络 管理
cron
服务变更
LVS
访问 质量
故障 管理
资产 管理 IDC 管理 标准 制定
OUTLINE
运维标准 资源管理 监控告警 服务变更 容灾预案 运维安全 运维效率
服务变更
服务变更
adserver | |---bin | |---adserver | |---conf | |---adserver.conf | |---data | |---data1 | |---data2 | |---log | |---adserver.log | |---adserver.log.2012121910 | |---adserver.log.2012121909 | |---script | |---run.sh
adserver.conf
ip_0_0: 10.0.0.1 ip_0_1: 10.0.0.2 ip_1_0: 10.0.0.3 ip_1_1: 10.0.0.4 Data_index: 0/1
服务变更
手工操作 for x in `seq 00 10` do ssh jx-cp-se$x.jx ‘do something’ done 批量操作 lh系列工具 lh jx-cp-se-* 获取列表 lhck jx-cp-se-* ‘do something’ lhscp jx-cp-se-* local_file work@~/xxx/
某公司人机比例
4500 4000 3500 3000 2500 2000 1500 71 服务器数与人数的比值 90 80 70 60
55 45
服务器数增长曲线
51 07年人数的增 幅没赶上服务 器的增幅，这 年大家更累了 人数增长曲线
50 40 30
1000
500 0 服务器数 人数 人均服务器
功能
选择需要部署的服务树节点，提供筛选功能 选择服务本次变更的版本，因为之前已经在服务树上把服务和SVN关系进行了绑定 只能在线上已运行服务的基础上，做增量上线，替换每次需要升级的bin，不影响data、conf 、log 提供一个web化的配置文件编辑器，每次发起部署任务前，先把线上每台机器的配置文件拉 回本地进行批量编辑 因为之前做了服务启停标准，所以只需要配置stop,start，还是restart等命令执行顺序即可 可以设置暂停点，如部署完第一台服务器后暂停，运维人员观察确认后再批量执行 支持与监控系统联动，在部署该服务器时，暂停该服务器上对应的服务监控，部署完成后调 用healthcheck和开启监控，如果发现问题则暂停批量任务。
运维工作——应用运维 3
预算管理
熟悉服务模块的极限压力数据和评估方法 清楚了解服务预算公式和各种考虑因素（如内存、硬盘等） 协调相关RD/PM, 定期修订服务预算公式，并编制产品线硬件预算 参与新型硬件设备的调研、测试及产品线硬件的选型
服务优化
发起或参与针对现有服务性能调优工作，并总结形成优化方法 针对新模块、新服务，能提出优化的部署方案并安排实施 根据业务需要，制定服务调整、迁移方案 不断完善和优化程序和系统的功能、效率，提高运行质量 制定服务稳定性指标及准入标准
外部
降低运维压力
提高运维生产力
内部
控制缺陷
减少人工
运维标准
运维平台
服务体系
思维角度 Thinking G1 原始时代 集合角度 Association 规则角度 Rules
想法
命令
动作
依 赖 人
体 力 密 集 型
G2 农耕时代
概念
工具
流程
G3 工业时代
理念
系统
规范
不 依 赖 人 脑 力 密 集 型
监控分类
机器监控
CPU 内存 磁盘 IO 网卡流量 存活性
网络设备 服务监控
进程 端口 语义
访问质量
监控告警
传统的监控方式
使用zabbix、Cacti、Nagios等.. 使用snmp或agent的方式，采集机器监控和网络设备信息 通过监控应用的端口或进程，监控应用是否正常 可以自己编写插件，通过agent调用，获取应用运行的状态
监控告警
主动监控
程序在运行时，主动反馈自身运行状态的计数器 参考，很简单的方式上报
stathat.ez_post_count( ‘ xxxx@', ‘nginx qps 10.234.5.19', 300)
监控告警
域名监控
从全国多个节点监控域名的可用性 同时提供访问质量监控 前期可以采用监控宝等第三方监控服务
NSQA
ECOMQA
PSQA
INFQA
测试部
NSOP
ECOMOP DBA
PSOP
INFOP
OPED（运维平台研发） OPTC（运维技术委员会）
运维部
网络 安全 CDN 资产管理、采购
IDC 内核 虚拟化
系统部
SYSTC（系统技术委员会）
运维工作——应用运维 1
设计评审
参与RD发起的产品设计评审，从线上部署和运维的角度提出评审意见。
访问质量
JS检测 URL多地域监控 页面优化 采用基调等第三方服务进行监控，阿里测等进行页面分析
监控告警
分布式跟踪系统
Google dapper Twitter zipkin 淘宝 鹰眼
监控告警
进程监管
作用：当被监控的进程退出时将它自动重启，避免由于进程意序，通过supervised监管进程 很多公司使用开源的supervisord， / Monit和supervisord类似 god，http://noops.me/?p=133 有详细介绍