闲话 IT 运维 -- 系统运维和业务运维
IT部门通过IT技术为业务服务，这个服务体现在日常的IT运维过程中。从技术和业务两个维度来区分，IT运维可以分成业务运维和系统运维。系统运维通过技术手段保障系统稳定运行，满足业务需要；业务运维主要协助业务部门处理用户反馈的业务问题，包括业务咨询、投诉处理、业务处理等等。
如果是小型IT部门，服务的内容不是很复杂，运维工作虽然有系统和业务区分，但是业务简单，一般运维工作也不必区分的很清楚，通常运维人员身兼系统和业务运维两个角色，但是当系统比较大，业务复杂的情况下，就有必要进行区分，否则运维人员无法同时顾及系统和业务两个方面，导致系统和业务都不能深入了解，反而对运维工作不利。
服务、业务与系统的关系
服务、业务、系统关系矩阵
业务和系统属于两个层面，两个层面所用的描述语言有差别，系统层面使用的是技术语言，包括很多IT技术术语（开发语言、进程、线程、脚本、SQL、等待时间、队列、......）；业务层面对于不同行业，业务语言都不尽相同，譬如金融行业、通信行业、零售行业，各行业有各行业的专业术语。如果这两个层面的人在一起沟通讨论问题通常会出现困难，有的情况下需要既了解这个行业业务又了解IT技术的专业人士从中做“翻译”才能顺利沟通，这个专业人士通常由IT部门的业务专家充当。
为给用户提供便捷的服务，用户接触到的部分（用户接口）通常非常简单，但是为了实现这个简单的接口功能，后端一般很复杂，通常涉及到多个系统，多个业务逻辑。拿日常我们打电话举例，用户拿出电话、拨号、接通、通话结束挂机，这个使用很简单，但是对于通信系统就涉及到无线网络、有线传输、核心网、CRM系统、BOSS计费系统等等多个系统。
IT部门对外提供服务、服务由一个或者多个业务组成、一个业务涉及多个系统（业务和系统的接点）。譬如上图中的服务B由业务B和业务C组成，业务B和系统1、2、3有关，业务C和系统2有关。其中系统2和业务B和C有关。
系统运维
系统运维通过IT技术手段保障应用系统平稳运行，主要和机器、网络、应用软件打交道，如果系统更庞大复杂，系统运维还可以进一步细分成主机运维、网络运维、数据库运维（DBA）、应用运维。主机、网络、数据库的运维更加底层，支撑上层多种应用的运行。
系统运维工作职责包括：
1）系统级别告警监控（主机资源利用率、网络、队列、数据库......）
2) 系统变更上线
3）系统问题紧急恢复和定位
4）系统业务连续性
5） 数据备份维护
6）性能优化
7）容量评估扩容
8）业务工单、订单监控
对于系统运维需要精通自己负责部分的IT专业技能，另外为更好的支撑业务，也应该对业务知识有所了解。应用系统运维更多的关心怎么让系统转起来，并且要转的好，要有高的健壮性，不要有单点问题，还要考虑系统调优，考虑系统的性能问题以及容量，根据业务发展规划评估系统未来1~2年的扩容需求。
业务运维
业务通常可以作为一项服务的组成单元，譬如手机话费充值服务，这个服务简单点说就是为用户提供缴话费的方式，这个服务涉及到的业务有很多，按充值渠道分有充值卡充值、支付宝充值、微信充值、运营商网上营业厅充值，银行代付费等等，每个渠道对应一项业务，不同的业务走的流程也不同，涉及到不同的系统。业务运维人员要对所负责业务的流程非常熟悉，对这个业务流程经过哪些系统非常了解，和对应系统运维人员要经常有沟通，要了解该业务的业务量情况、成功率情况，对这个业务出现的异常情况要有监控，及时跟踪该业务问题解决情况，另外很大一部分工作是应对该业务的投诉、咨询处理。
系统运维工作职责：
1）业务级别告警监控（对应业务的工单、订单监控、失败率监控）
2) 业务功能上线跟踪
3）业务投诉处理
4）业务数据维护
5）业务发展统计、分析、预估
6）和业务部门对接
业务其实就是通过程序的算法来处理数据，最终体现在数据上，上面举的充值这个例子，就是通过应用程序编好的算法将这个话费记录到数据库中，当然之前会有一系列的身份校验、充值规则校验、对账策略等等。当应用程序出现问题时，为应对业务投诉，业务运维人员有时就要充当应用程序的功能，通过人脑进行核实、计算将这个话费记录写到数据库中，如果数据量少可以直接手工处理，如果数据量大需要临时编写脚步处理，这种“人肉运维”（用人脑代替程序）方式是不得已而为之，但是这种苦逼事情绝对不能多做，做的多说明软件版本太烂，业务维护流程也有问题。所以业务运维人员通常要精通业务规则和流程，熟悉IT技术，精通脚本编写、数据库SQL。
业务运维技能要求：
1）了解IT技术
2）熟练掌握数据库SQL
3）善于和用户沟通
组织架构
系统运维和业务运维一般容易划分，但是如何组织这两者以便高效的解决问题也值得好好考虑，否则沟通时对一些具体问题可能存在扯皮的情况。一种组织架构方法是将业务运维和系统运维分属业务和系统两个行政科室，但是由一个服务经理来牵头领导，这个服务经理对接业务部门。类似于研发部门的产品经理，产品经理管理的开发、测试、方案等人员归属于不同的研发测试部门，但是由产品经理总牵头和管理，服务经理由对系统和业务都比较熟悉，有丰富业务和管理经验的人员担任。
服务、业务、系统组织架构
小结
在复杂系统和业务的环境下，有必要将业务和系统做明确划分，将两者的关系可视化，维护好业务和系统的关系矩阵，上线任何一项服务或者业务都应该及时纳入到这个矩阵中，并且及时补充业务、系统运维的方案、手册、责任关系，避免出现了业务投诉才到处打听这个业务谁负责，包含哪些系统，为什么监控手段没有及时跟上，成天处于救火的状态中。
作者 yanndy
关键字：产品经理, 运维
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
