业务运维工作内容归纳

业务整个生命周期中业务运维的作用概括：

A、立项阶段

和业务方面了解项目的目标用户、服务地区、项目的大致规模等信息，可以提前了解和准备资源的提供商（如IDC机房、CDN厂商），测试网络质量，资源采购（如物理IDC需要相关资源），为项目后期的稳定运行准备好基础环境。

了解业务或产品的运营规划信息：目标人群、覆盖地域、推广方案和计划、预计的流量/压力等运营数据信息

B、准备开发阶段（运维要进行技术宣讲+技术评审）：

1、技术方案选型

合不合理，选择运维熟悉的、统一的组件，比如操作系统的版本，memcache vs redis。

如果一定要用某种技术，运维可以提前准备，熟悉这些技术，比如java，MongoDB，微服务，服务注册发现等

2、可运维性沟通

端口的规划、启停方式的规范、目录结构、退休和灰度机制、是否应该接收什么信号、配置文件管理

3、高可用性、可扩展性、健壮性

用户增长了怎么办、服务和数据是否能完全的分离、防攻击怎么处理、各种预案

4、监控的便利性

日志内容和格式、进程内部数据获取的接口（QPS、在线人数、浏览、请求数）、关键操作处理延迟信息等

C、业务上线前（进行可运维性评审）：

了解业务的真实现状，评估架构的单点、高可用性、可扩展性、容错性等，签订SLA协议。比如，存在某个不可改变的单点服务，那么我们要达成一致，运维对这个单点服务无法保障高可用性。

1、了解项目的物理架构，配置文件管理，部署，变更复杂度，可用性，容量，容错处理，可监控性等等，尽量早一点排除一些问题。

2、根据项目的发展规划，重要级别等，申请相应的基础设施资源。

D、业务上线中：

1、配置和环境标准化/文档化

2、重复劳动自动化/脚本化

3、完善监控和日志

E、业务上线后（项目运营阶段）：

1、时常盯着监控数据，获取基准监控数据

2、跟进业务运营状况，获取真实用户信息（有无异常反馈？推广效果如何？有没有大推计划？）

3、性能/利用率追踪

4、事件管理/故障管理/问题管理

F、项目下线（暂时忽略）

1、代码备份和数据备份

参考资料：

参考链接1：

http://blog.csdn.net/xlh1991/article/details/41632073

附一、一个优秀的运维工程师，应该具备这样一些素质：

1、关心线上业务系统。主要包括监控的全面覆盖和对异常变化的警惕。

2、对于出现的问题能找到解决方案。不管是和供应商一起查找问题，还是用搜索引擎查找解决方案。

3、持续的自我学习。持续学习新的技能点，并且要做到对IT/运维技术的趋势有持续的追踪和了解。

4、容量管理。要思考业务后续的发展需要的资源。

5、性能监控。业务响应慢了，你如何从各种子系统中排查出瓶颈。

6、工程技术上的解决方案。比如如何更好地为业务提供基础设施？怎样优化现有的监控系统。

业务运维是业务和各种支撑资源的纽带，做业务和资源的粘合剂

业务运维不要仅仅做执行单位，而是要做能够帮助业务发展的、能够提高业务运行质量的部门

附二、基础运维/平台运维：

基础运维维护的工具也可以认为是一个个的业务。那自然也需要关心用户的使用情况：

基础运维不光是业务运维，还要充当产品经理、产品运营等角色

• 挖掘用户的真实需求
• 考虑用户体验
• 用户的使用频率和满意度
• 业务的可用性监控和记录
• 业务的性能、效率和成本

IDC data center PUE：

https://www.equinix.nl/company/green/green-data-centers/pue-metrics/

基础运维（平台运维）工作内容归纳

需要做的和能不能做