系统运维岗位职责

系统运维岗位职责（精选20篇）

　在现实社会中，各种岗位职责频频出现，岗位职责主要强调的是在工作范围内所应尽的责任。那么什么样的岗位职责才是有效的呢？以下是我收集整理的系统运维岗位职责，希望能够帮助到大家。

系统运维岗位职责 篇1

　1、系统运维、服务监控分析、故障排查，以及紧急情况下的应急处理;

　2、遵循发布、变更流程，负责系统建设和运维工作，保证其高效、稳定工作;

　3、研究服务架构，发现潜在问题，制定系统调整和优化方案，提高系统的健壮性和效率;

　4、参与系统架构设计，建设和管理;

　5、参与公司基础网络安全架构的建设，根据业务需求制定安全解决方案;

　6、解决日常安全问题，在出现网络攻击或安全事件时进行紧急响应、恢复系统及调查取证。

系统运维岗位职责 篇2

　一、系统运维

　1、负责系统发布，部署，编写集成方案和部署方案

　2、负责系统故障、疑难问题排查处理，记录故障详情、解决过程

　3、负责配合开发搭建测试平台，协助开发设计、推行、实施和持续改进

　4、负责日常系统维护及监控，开发搭建系统日常维护、监控、分析、报警平台系统

　5、负责信息系统在客户现场的安装、培训和维护工作，负责收集客户在使用系统过程中的原始需求，优化需求，传递给产品经理

　二、网络运维

　1、负责日常服务器、网络，邮箱，电话系统，视频会议系统的管理和维护

　2、负责日常应用软件，公司桌面办公软件的维护

　3、持续改进日常操作以及优化公司网络，跟踪网络互连技术发展，合理运用新技术

　4、负责对服务器的健康状况，业务进行监控，并处理应急情况日常服务器巡检，备案，安全等

系统运维岗位职责 篇3

　职责：

　1、负责公司IDC业务线监控系统的日常维护与管理;

　2、负责公司官网、OA、云平台等系统的日常维护与管理;

　3、负责研发项目著作权申请文档的编写与申请沟通;

　4、负责研发产品的实施与部署;

　5、根据部门工作要求完成临时性的配合工作;

　任职要求：

　1、熟悉Linux系统的常用操作

　2、熟悉Shell或Python的编程

　3、具有良好的沟通与协调能力

系统运维岗位职责 篇4

　1在阿里云环境部署业务，维护系统运行;

　2开发运维脚本或工具，来提高运维部署的效率;

　3维护集成开发，测试环境;

　4管理内部用户权限和资源;

　5监控系统运行状况，在发生问题是能及时报警并跟进处理。

系统运维岗位职责 篇5

　职责：

　1、负责集团客户应用系统底层环境的搭建和运维(包括线下系统及云平台环境);

　2、对操作系统、数据库以及相关应用系统的维护和优化;

　3、参与客户系统平台升级，负责相关系统环境的搭建和测试;

　4、负责客户数据库的备份、管理及监控，跟踪处理系统异常数据，及时发现潜在问题，保障系统正常运行。

　岗位要求：

　1、本科及以上学历(计算机、通信或相关专业)，五年及以上相关工作经验;

　2、精通windows，Linux系统管理和维护;

　3、熟悉Vmware vSphere和ESXi host的配置和管理;

　4、熟悉Oracle DB，具备OCP认证者优先;

　5、能独立完成oracle/sql server的备份恢复，了解相关的性能调整和故障诊断;

　6、能适应江浙沪范围内的短途出差。

系统运维岗位职责 篇6

　1、负责客户AD或Exchange系统日常维护及监控，提供系统功能方面的服务和支持；

　2、负责客户各应用系统相关故障、疑难问题排查处理，编制汇总故障、问题情况说明；

　3、维护客户关系，提高客户满意度；

　4、负责部分应用系统的升级上线工作；

　5、整理现场需求，做成系统改善提案。

系统运维岗位职责 篇7

　1、负责维护大型企业资源管理软件SAP的维护，确保运用系统和业务运作的稳定高效。

　2、协同其他资源完成对系统、业务流程的增强和优化。

　3、熟悉互联网平台的运营工作，擅长运营问题与需求的整理、归类、派发和反馈;

　4、能够与业务、产品、和技术工程进行有效地沟通，并有一定的持续跟进能力;

　5、诚信、乐观、有创新意识，能承受较大的工作压力并具有团队合作精神。

系统运维岗位职责 篇8

　1负责系统(Windows,Linux)的安全稳定运行和维护保障;

　2负责服务器，操作系统的日常维护及运行质量检查，并对相关性能指标进行监控和评估;

　3负责应用系统日常操作、应用维护，巡检、升级、应急响应、故障处理;

　4负责应用系统的上线部署、版本管理和技术支持;

　5汇报和总结每月发生的问题

系统运维岗位职责 篇9

　职责

　1、负责Linux 服务器的部署和运维;

　2、负责公司业务的可用性和服务质量;

　3、负责响应突发性故障并处理，及时通知故障及处理状态，评估故障风险，给出建议;

　4、负责网站应用大规模集群、高可用性的搭建维护;

　5、负责对Linux系统及应用程序进行性能分析，优化，问题跟踪;

　任职资格

　1、5年以上Linux运维相关经验;主导负责过一个以上大型项目的运维工作优先;

　2、理解Linux操作系统、体系结构，掌握Python/Shell/Perl/C等1至2种语言;

　3、熟悉LAMP,LNMP架构，熟练掌握Linux下相关软件的配置使用;

　4、熟悉zabbix,nagios,cati等至少一款系统监控软件的配置使用;

　5、丰富的系统故障排查和解决经验，突出的分析和解决问题的能力;

　6、具有良好的沟通协调能力、学习能力、团队精神和服务意识;

　7、熟悉kvm技术，有公有云azure、阿里云、腾讯云的使用经验。

系统运维岗位职责 篇10

　职责：

　1 负责系统运维，含Tableau服务器、软硬件维护、配置维护。

　2 协助公司软件系统运维，含虚拟机远程系统运维、共享等运维管理;

　3 负责数据库日常运维，备份、恢复、扩容、数据迁移及安全管理;

　4 各类故障及事务的应急响应、处理，协调，保证系统7x24H业务连续性。

　5 工具的配置与管理。

　6 处理上级安排的其他任务。

　期望：

　1良好的客户服务意识，较强的逻辑分析能力、排查问题和解决问题的能力和团队协作精神;

　2了解数据库运维工作;

　3熟悉 MySQL相关监控、管理工具;

　4熟悉Apache、NginX、Tomcat、MySQL 等常用服务的安装、配置和维护;

　5有电商行业基础者优先考虑。

系统运维岗位职责 篇11

　职责：

　1、负责深圳机房业务系统的日常运维工作；

　2、负责处理业务系统日常问题、故障；

　3、负责处理业务系统变更、升级和测试；

　4、负责制定和规范技术文档；

　5、完成公司和部门安排其他工作。

　岗位要求：

　1、重点本科及以上学历，计算机、软件工程等专业。

　2、拥有金仕达、CTP系统之一5年以上运维经验。

　3、有RHCE、CCNP、OCP等专业证书优先考虑。

　4、有期货从业资格优先考虑。

系统运维岗位职责 篇12

　岗位要求 ：

　1统招本科以上学历，计算机、会计电算化、财务等相关专业；

　2 熟练掌握金蝶或用友等ERP软件的以下模块：财务会计、费用报销模块、银企直连模块、供应链模块、合并报表、多账簿 ，并至少具有2年以上ERP等相关产品的实施或运维经验；

　3熟悉企业管理会计及ERP相关理论。熟练掌握计算机操作系统、网络安全、熟悉SQL、ORACLE数据库操作等技能，有较强的判断问题及解决问题能力具有良好的需求分析、需求挖掘、需求引导及提炼总结能力；

　4熟练EXCEL 办公软件的各种函数的应用，具备良好的客户服务意识，工作勤奋，学习能力上佳，具有强烈的责任心，为人踏实，做事认真仔细。

　岗位职责 ：

　1 费控报销系统运维；

　2EAS系统日常维护；

　3 具备需求分析、需求挖掘、需求引导及提炼总结能力；

　4 部门安排的其他工作。

系统运维岗位职责 篇13

　职责：

　1、负责卡中心开发测试环境的日常管理和维护工作。

　2、负责与开发中心的开发人员沟通资源需求、统计资源状态。

　3、负责KVM虚拟化的的日常运维，包括资源扩容、虚拟机分配、虚拟机性能优化、虚拟机迁移、P2V、镜像制作等操作。

　4、负责IaaS平台，包括问题描述跟进、配合厂商分析问题、测试和解决。

　5、协助对云计算平台进行日常的配置管理、更新、维护，负责系统架构和应用架构与云计算平台整合。包括服务器安装、应用部署、服务监控、故障处理。

　6、负责开发测试虚拟机操作系统和数据库中间件的维护，负责基础软件的安装和配置。

　7、负责总结经验，编写或修改文档，完善操作手册及知识库。

　职位要求：

　1、精通Linux操作系统，熟悉shell或python编程。

　2、精通OpenStack整体架构，具备基于OpenStack实战部署运维经验。

　3、精通KVM虚拟化，熟悉KVM、QEMU、libvirt、VirtIO虚拟化相关管理操作命令。

　4、熟悉MySQL、postgreSQL等数据库维护。

　5、熟悉nginx/redis以及负责均衡、web中间件的维护。

　6、具有丰富的虚拟化故障应急处理能力与经验，动手能力强，分析、归纳水平高，具备精确快速的故障定位和处理能力。

　7、熟悉基础二层网络、路由网络及虚拟化网络相关配置。

系统运维岗位职责 篇14

　1、熟悉阿里云、腾讯云业务开通和维护(服务器，数据库，均衡负载，RDS，OSS等);

　2、熟悉Windows，Linux(Debian，Centos)配置和维护;

　3、域名申请和备案;

　4、有分布式服务器、数据库部署配置经验;

　5、熟悉或了解PostgreSQL数据库;

　6、负责信息系统使用过程中日常咨询答疑、问题处理及跟进;

　7、配合项目经理完成项目实施及软件运维工作(产品部署、升级、安装调试、系统上线前的验证、项目验收等)

　8、项目管理权限的分配管理，编制及登记。

　9、编制系统操作手册(安装手册、调试手册、使用手册、帮助手册等)，培训相关用户使用。

　10、系统资料的定期更新及维护。

系统运维岗位职责 篇15

　1、日常短彩信质量分析工作，协助短彩信业务质量人工测试、协助自有人员以提升用户感知、加强故障监控能力、消灭安全隐患为目标，提供对短彩信系统业务指标、系统运行效能进行主动发现、隐患整改、持续优化的服务。

　2、日常巡检：协助实施系统巡检，协助编写问题报告。

　3、投诉处理：协助投诉与故障现象分析，明确投诉原因，提出投诉处理建议。

　4、作业计划：协助完成作业计划执行以及完成情况反馈。

　5、系统备份与系统资料管理：协助开展系统备份与系统资料整理。

　6、日常故障处理：协助数据提取与分析、系统监控，开展人工测试，提供故障处理建议，协助维保厂商及自有人员完成故障处理。

　7、紧急故障处理：协助数据提取与分析、系统监控，开展人工测试，协助故障处理，提供故障处理建议，协助8、提供故障分析内容，协助维保厂商及自有人员完成故障处理。

　9、话单数据保障：协助进行话单文件的日常维护，协助完成话单缺失的补传工作。

　10、协助数据提取与分析、系统监控，开展业务测试。

　11、协助开展日常安全扫描等工作，内容主要为：系统安全加固、弱口令、漏洞的自查及修复;信息安全风险的自查及整改;管控平台全面接入及绕行控制;防火墙设备策略梳理;定级备案内容提供;更新应急预案，完成应急演练等。

　12、数据配置：进行局数据制作后测试。

　13、报表分析：协助提取分析报表，实施分析工作，编写分析报告。

　14、数据分析、服务汇报：协助完成系统指标数据提取、整理、问题分析;完成各系统专项服务汇报(故障报告、巡检报告等)，以及定期服务总结。

　15、协助买方完成其他临时性、阶段性工作任务。

系统运维岗位职责 篇16

　工作职责 :

　1、财务管理系统,如:费用报销系统、资金管理系统、财务核算系统等产品运维工作;

　2、完成财务管理系统,如:费用报销系统、资金管理系统、财务核算管理系统等运维问题处理、优化需求初步分析。

　3、负责应用产品设置,编写用户培训手册、运维报告等文档;

　4、配合产品经理完成系统推广实施、系统测试、用户培训等工作。

　任职要求 :

　1、1-3年以上财务管理系统,如:费用报销系统、资金管理系统、财务核算管理系统等实施或运维经验;有ERP产品实施或运维经验优先;熟悉ORACLE产品优先;

　2、有知名咨询公司或大型互联网公司经验,熟悉相关业务和财务知识,熟悉财务结算、资金管理、供应链管理等业务流程;

　3、技术或财务背景优先;

　4、良好的自我管理能力、逻辑思维、抽象、沟通协调执行力,学习能力强,愿意接受挑战,能较大压力下保持工作激情;

　5、富有创业激情、简单开放、有良好的团队协作意识;

系统运维岗位职责 篇17

　岗位描述:

　1银行电子渠道应用系统现场运行维护

　2电子渠道业务和技术服务请求响应

　3电子渠道事件响应及处理

　4生产重大故障应急处置

　5应用系统运行情况分析

　6相关技术和运行报告的整理和编写

　7系统监控或者维护脚本编写

　工作要求:

　1计算机及相关专业本科以上学历。

　22年以上银行业务系统开发、运行维护工作经验。

　3熟悉银行业应用系统的业务流程和系统架构,有银行电子渠系统运维工作经验者优先。

　4精通使用AIX、HP-UNIX、LInux等操作系统,熟悉SHELL脚本编程。

　5熟悉了解unix c或java等开发语言。

　6熟悉了解tuxedo、MQ、WebLogic等中间件技术。

　7熟悉了解Oracle、Mysql、DB2等关系数据库,熟悉相关工具和脚本技术。

　8有一定的文档编写、英语文档阅读能力。

　9思维清晰敏捷,逻辑分析能力强,良好的语言和书面表达能力。

系统运维岗位职责 篇18

　职责描述:

　1、负责对核心业务系统等各应用系统的生产运行进行持续监控、日志分析,对系统相关性能指标、故障、问题进行记录、分析、评估及处理,定期总结,提出和推动落实优化建议;

　2、负责制定和落实生产应用系统运维服务流程及标准,建立和健全应急响应机制,持续提升运维自动化水平;

　3、负责用户手册、变更方案、配置及技术文档的编写与管理;

　4、负责应用系统使用相关知识培训;

　5、参与系统设计评审,对开发项目组交付的系统设计、数据库结构、源代码、配置文件等产物进行审核;

　6、 领导交办的其他事项。

　任职要求:

　1、全日制本科及以上学历,计算机科学与技术,计算机软件等相关专业;

　2、三年以上信息技术从业经验,具有信息技术相关证书者优先。

　3、熟悉Linux操作及使用,熟悉Oracle数据库、PL/SQL;具备Oracle优化方面经验,熟悉Java开发优先。

　4、具备良好的问题定位分析能力,有良好的整理问题的习惯,具备系统运维的责任感;

　5、学习能力强,善于思考总结,工作认真、积极主动、责任心强,有较强的沟通、表达能力和团队意识;良好的职业道德素质,正直诚信;

　6、认可公司企业文化及规章制度,服从公司管理,有良好自律能力;

　7、具备保险核心业务系统开发或维护经验优先。

系统运维岗位职责 篇19

　1、运行维护人员应热爱本职工作，并具有强烈的事业心个责任感，掌握全面的专业技术知识和熟练的操作技能。

　2、严格按照国家环保总局和省环保局制定的污染源在线监测系统运行维护技术规范开展运维公司。

　3、运行维护人员应熟悉系统的仪器个设备性能，严格按照仪器操作过程，正确，规范的使用仪器设备，认真执行系统运行维护的各项规定。

　4、每周对运行维护的监测点进行一次例行巡检维护，切实做好维护和预防性检修工作，并认真填好维护情况记录，保证仪器良好的运行环境，及时更换仪器耗品，确保仪器的正常运转，保证系统长期、连续、稳定运行，保证达标的数据完整地上传至各级环保部门的监控平台。

　5、严格按照运行记录表所要求检查的内容，做好定期维护检查工作。 6、认真做好仪器设备的维护保养工作，定期更换各类易损部件。

　7、运维记录采用统一的格式，各个维护单位固定使用一本维护记录本，认真做好仪器设备日常运行的现状巡检记录。

　8、服从管理和调配，接到排除故障任务或发现故障时应及时排除，不能解决的应及时向上级和当地环保部门报告，便于专业维修人员及时进行维修和处理。

　9、所有运行维护的自动监测仪器必须按规定的时间要求进行校正和校验，确保监测数据的准确率能达到各级环保部门所规定的要求。

　10、建立仪器设备档案并按公司要求妥善保管。

系统运维岗位职责 篇20

　1、配合市场部人员做售前技术支持，提供技术方案、设备清单、设计图纸、设备参数、功能讲解等支撑，结合市场项目开发情况，跟工作采购做相应备货情况。

　2、项目筹建工作，对接项目落地方相关责任人，积极推进落地项目建设工作。具体包括要实施前期准备—出具施工方案—开工手续办理—施工队组建—施工管理—施工过程中问题处理—项目调试—组织竣工验收—项目交付—运行。

　3、项目需求对接，对于项目落地前后甲方对于软、硬件产品需求进行沟通—收集—分析—部分反馈—满足需求。

　4、问题处理，项目运行后，就反馈的问题进行处理、分析、解决、存档。

　5、对产品进行实地测试—数据收集—问题分析—反馈—监督解决。

　6、针对软件产品，根据现场使用情况，对于产品在实际应用过程中存在的问题进行收集—分析—反馈—监督落实。

　7、维修工程师工作技能培训等。

;

超融合架构运维的简化效果是非常显著的，这个是显而易见。

超融合的存储网配置很简单，而传统架构则需要划Zone等复杂操作；并且超融合无需规划和划分RAID、RAID初始化，传统架构则至少花一天时间来进行RAID初始化；此外，超融合的部署时间仅需半天，扩容简单快速，硬盘和节点故障可自动恢复；而传统架构则要至少一周时间来进行部署，扩容复杂、手动均衡，还需要及时更换盘或控制器才能恢复硬盘和节点故障。

其中部分优势是分布式架构带来的，比如只维护标准商用服务硬件，而使用超融合后，可以进一步减少硬件的需求量。所以，分布式架构才是超融合的核心。目前的厂商能把分布式架构（尤其是存储）做好的很少，国外的Nutanix、VMware（vSAN），中国的SmartX等都算是主流一线的超融合厂商。如果刚入门超融合领域，建议可以拿他们的方案和客户案例研究一下。

云游戏这个概念非常简单，就是我把游戏放到服务器上去运行，把游戏渲染出来的的音视频画面，通过流的形式传送到终端，终端上不再需要安装游戏，各种终端比如说电视、手机、PC、平板都可以运行。这样我们就不需要关心游戏怎么去适配不同的软硬件平台、终端性能够不够等等这些问题。

什么是云游戏

云游戏这个概念非常简单，就是我把游戏放到服务器上去运行，把游戏渲染出来的的音视频画面，通过流的形式传送到终端，终端上不再需要安装游戏，各种终端比如说电视、手机、PC、平板都可以运行。这样我们就不需要关心游戏怎么去适配不同的软硬件平台、终端性能够不够等等这些问题。这个概念本身是非常好的，在2009年的时候，这个技术就已经出现了，美国有家叫Onlive 的公司第一个推出云游戏服务，但是他最终在商业上还是失败了，技术最后被索尼公司收购，并运用在PS Now上。云游戏的概念虽然非常好，但里面技术挑战性非常高，有非常多的技术问题需要解决，那个时代可能还比较早，软硬件都还不太成熟，所以最后没有能够成功的商业化。到了现在这个时间点上，云游戏技术开始慢慢成熟起来，已经具备了商业化的基础。

下面是对我们产品的介绍。对云游戏来说，用户主要会关心延迟问题，玩一个对抗性很强的游戏，如果中间卡个几百毫秒那肯定受不了，游戏体验就会非常差。所以我们最核心的关注点就是要把延迟降低到最小、并且把画质保持在一个相对可以接受的程度。目前我们产品的整体延迟(从用户按下操作按钮到看到画面变化)可以控制到50毫秒以下，在这样的延迟水平下玩格斗游戏赛车游戏感觉都是非常流畅的，画面可以支持到720P/1080P，网络带宽只要4兆以上就可以了。我们单台服务器可以支持 20-50 路的并发游戏数量，也就是单台服务器可以同时为 50 个玩家提供服务，单个并发用户的整体服务器硬件成本在500元左右，可以说是一个非常有竞争力的成本。当年 OnLive 失败的主要原因是因为他的硬件成本非常高，他的一台服务器仅能服务一个用户，单个并发用户的成本可能就要上万，在这样的成本水平上要实现商业上的成功是非常困难的。目前这个项目已经在小范围的内测，他们主要是 toB 的业务，为宽带运营商提供增值游戏服务。

云游戏的技术挑战

第一个是实时性

游戏的整体延迟包括了游戏逻辑运算时间、音画渲染的时间，加上编码的延时、网路传输的延时、客户端解码的延时、客户端向服务端发送控制信息的延时，云游戏的实时性要达到一个可令玩家接受的程度，这个技术挑战是非常高的，当然也要依靠硬件和网络本身的性能，如果没有足够的带宽也不可能做到。

第二是虚拟化技术

虚拟化在服务端已经非常成熟，我们有虚拟机技术以及各种容器技术，但是在桌面上就不是那么成熟，普通的虚拟桌面不支持 GPU 的虚拟化，而游戏非常依赖 GPU 渲染，若没有 GPU 的虚拟化就没办法实现云游戏了，所以虚拟化是一个很大的技术瓶颈。

第三是经济性

每个并发用户的服务器硬件成本关系到这个模式能否成功商业化，如果成本超出了用户可接受的范围，那就没有办法实现盈利。

最后是运维管理

云游戏的运维管理跟传统的服务器运维管理不一样，因为用到的服务器硬件不一样，同时硬件负载又很高，这对运维管理提出了新的挑战，所以在技术上就要解决这些问题。

平台选择

游戏的运行平台非常多，各种各样，但是比较适合的只有windows平台。Linux 平台虽然开放，但是它没有什么游戏支持，其他的主机游戏平台基本都属于封闭技术，微软和索尼自己都在研发主机上的云游戏，那我们是没有办法去做的。

android平台也是非常适合做云游戏。服务器跑个android游戏再传到android设备上这个概念看上去比较怪异，但实际上IPTV运营商非常喜欢这个概念，因为机顶盒不允许安装第三方的应用，监控比较严，那我们通过云端化来绕过这种限制，这对机顶盒这种产品非常有帮助，所以android平台也是我们要考虑的。但今天主要是介绍 windows 平台游戏的虚拟化，android上是用硬件方案跑的，所以就不介绍了。

windows游戏的虚拟化技术主要是两条路线。一个是虚拟机方案，但主要问题是 GPU 虚拟化技术不成熟，可能需要一些专业级的显卡支持，成本非常高、性能损耗非常大，每一个游戏都跑一个 Guest OS 非常浪费内存，所以这条方案就被我们否掉了。同时windows 上也缺少可用的容器级技术，我们只能采取 API Hook 方式手工实现虚拟化，我们称之为 Sandbox 方案。

Sandbox方案就是把游戏所用到的系统 API 全部hook接管，让游戏认为自己运行在一个正常的 OS 上面，但实际上是我们接管的一个 OS。这样做的好处是性能损耗很小，基本上没有额外的损耗，但是比较痛苦的要针对每个 API 做适配，需要对每个游戏进行适配，而且游戏通常不开源，游戏开发商通常也不会配合你去修改代码，需要一些 hack 技术来针对每个游戏做适配。

技术实现细节

图像和声音的采集

图形API有 DirectX 9,10,11,12还有OpenGL，接管这些API后我们就可以把画面重定向到视频编码器，不不在屏幕上输出了。音频比较简单，只要接管Windows Audio Session API就可以了。

输入操作的虚拟化

手柄比较麻烦，因为手柄支持的API接口比较多样化，比如 DirectInput, XInput, RawInput，还有些游戏直接读 USB 设备，实现这些API的接管工作是比较琐碎的。

存储的虚拟化分

一是游戏的资源部分，比如执行程序、、声音等等。这些资源文件都是只读的，需要一个共享存储来放这些文件，因为这些文件体积比较大，通常一个游戏需要几十个G的容量，如果全部都放在本地节点上的话，对节点的存储容量要求很大，而且以后更新维护起来也比较困难。所以我们用 NAS 来共享这些文件，这么做的网络 I/O 开销会非常大，后面我会介绍如何来优化这一块。第二是用户配置和存档数据等等可变数据，这些数据需要集中化存储，同时可能存在跨机房的访问需求。用户离机房越近延迟越小，所以需要多地、异地部署服务器，让玩家在全球漫游访问你的服务，这需要有跨机房文件共享的能力。

其他需要适配的内容

比如游戏一般都是单实例，我们需要绕过游戏的防多启动机制。还有些游戏无法后台窗口运行，我们需要通过 API Hook 的方式，让游戏认为它处于一个正常的状态。最理想的适配方式是通过 SDK，让 CP 来适配你的云游戏平台，但目前来说还不实际，因为云游戏的商业化还没有完全的落地，需要技术去慢慢的推进。

音视频编码技术

视频流采用的是 H264 编码，主要是 720P/1080P@30fps，1080P@60fps 对网络和硬件的要求过高，暂时还做不到。音频编码使用AAC。因为标准的封装格式不含控制流，不能传输用户的操作数据，所以我们自己定义了一种封装格式，简单的把 H264 和 AAC 的裸流封装起来传送给客户端。

目前用软件编码器基本不可行，一路视频编码就要消耗掉一个CPU核的资源，跑个三四路就把 CPU 资源吃光了，游戏就没办法运行了。幸运的是三大硬件厂商 Intel、AMD 和 NVIDIA 都推出了自己的硬件编码器，Intel的CPU自带硬件编码器，支持20+路的720P实时编码没有问题。NVIDIA 的硬件编码性能更高，可以直接对GPU的 FrameBuffer 做编码并传到 CPU 上，节省了很多内存的拷贝，性能是最好的。

视频编码的参数调优

首先避免使用 B 帧以减小延迟;较大的 GOP 设置来减少 I 帧的比例，保证每一帧消耗的码率都在一个最大可控的范围内;0 延迟设置，保证每输入一帧数据编码器都立刻输出这帧的编码数据，避免编码器缓冲帧数据;bitrate控制，使用固定比特率的算法是不适合的，因为游戏中经常会存在一段时间的静止画面，此时比特率很低，对接下来的变化帧编码器就会分配大量的比特来编码，这就会造成这一帧数据特别巨大，从而带来了额外的网络数据传输延迟。所以我们采用了自适应算法，在保证比特率总体在最大范围内的同时，保证每一帧消耗的码率都在一个最大可控的范围内，确保每帧的数据传输延迟可控。

终端的视频解码优化

H264 的解码是比较头疼的，因为android平台适配起来比较痛苦，尤其是它的硬件解码坑非常多。如果直接使用mediacodec封装的硬件解码器，那个延迟非常高，基本没有办法用。有一些芯片厂商会提供一个后门，让你把缓冲关掉直接输出画面，但是这需要对接具体的芯片厂商，无法做到通用，只适合一些机顶盒类的产品。所以还是需要用软件解码的方式来支持 0 延迟的输出。android设备的性能参差不齐，早期的低端芯片性能不满足实时解码 ，需要利用 GPU 做一些加速。

网络传输的优化

用UDP传输的话，因为H264 本身不支持容错，一旦丢包就会出现花屏，在下一个I帧到来前都无法恢复，通常要持续好几秒，严重影响用户体验，无法接受;而TCP 丢包的话只是出现几百毫秒的卡顿，实测还是可以接受的，所以我们放弃了 UDP 协议传输，利用TCP在网络层做一些调优使延迟降低。实测下来，现在的宽带网络延迟基本没有问题，主要问题反而是在用户侧的 WiFi 上，一旦出现无线信号干扰，网络抖动会比较厉害。

服务器和客户端的同步算法

我们的云游戏把所有环节的缓冲都关掉了，全部是零延迟自出，原来缓冲设计的目的就是为了抵抗颠簸，比如网络的颠簸、或某一个编解码环节出现了抖动，通过缓冲把这个抖动抹平，现在把缓冲都关掉后对同步会造成很大的影响。有很多因素会造成颠簸，比如服务器发送数据过快，客户端来不及消费，造成的结果就是延迟非常大。所以我们自己设计了一套算法来解决这个同步的问题。具体的做法就是让客户端在完成一帧画面的显示后向服务器反馈一个消息，服务端根据客户端反馈的消息就知道客户端消费到了第几帧，跟服务器现在编码的帧数做比较，在一定的阈值内就继续传输下一帧，否则等待客户端的确认消息，直到客户端赶上来。这样做的结果就是当颠簸发生时服务器能及时感知并停止发送数据，等颠簸消除后再继续发送最新的游戏画面，实测下来获得了比较理想的同步效果。

存储的优化。只读资源数据是放在 NAS 上的，几百个游戏共享一个 NAS，加载游戏时的网络 I/O 开销非常大，所以我们做了一个优化来本地缓存这些共享文件，利用dokan实现了一个虚拟磁盘来访问资源文件，再把虚拟磁盘重定向到NAS上，同时利用节点的本地 SSD 硬盘来缓存热点文件，从而降低了网络 I/O 的开销。

更多的云游戏玩法

旁观模式，一个玩家玩的时候其他玩家可以接入这个视频流，看他怎么玩;对战模式，其他玩家可以切到这个游戏流里面两个人在一起对战;还有直播模式，把视频流封装为 HLS，推送到 CDN 上进行直播，这是非常流行的主播模式，云游戏都可以支持。

云游戏运维方面的挑战

云游戏需要维护大量的服务器节点，而且跟普通的服务器管理不一样，需要自己造一些轮子。由于所有的硬件资源都是高负荷运行，我们要最大化的增加硬件利用率，一般的服务器 CPU 占 10% 就很不错了，而云游戏的 CPU 都是在接近 100% 的情况下运行，另外还需要GPU的参与，这导致了硬件的可靠性相对比较低。

软件因为没有隔离性，可靠性也会降低，一旦出现问题怎么维护、怎么恢复，成了比较麻烦的问题，因为没有现成的方案，就我们需要自己设计服务器集群来解决这些问题。另外还有跨机房部署的问题。

硬件方案的选型，我们主要有三套方案，一套是 GRID 显卡方案，这是 NVIDIA 为云游戏专门设计的专业显卡，上面带有编码器可以将游戏画面直接编码输出，但它的缺点是价格比较昂贵，一台服务器的硬件成本大约在 5 万元左右。

还有就是消费级独显方案，去掉了昂贵的专业显卡的同时还能获得更好的GPU性能，所以这套方案的性价比要高很多，每路并发的硬件成本可以降低到 500 元以下。

最后一个方案是 Intel 核显方案。完全不需要用独立显卡，但 Intel 核心显卡的性能偏弱，运行大型的 3D 游戏会比较吃力，运行一些休闲游戏没有问题。这个方案的优点是不需要显卡，1U 的尺寸下可以装入多个节点，集成度提高，而且易于维护，也是一个值得考虑的方案。

下面来解释一下云游戏一下集群的概念。Node(节点)对应一台物理计算机，一个节点可以同时运行多个游戏实例为用户提供服务。多个节点组成一个 Group(节点组)，一个Group内包含了若干节点和NAS，对应于一个机柜， 多个机柜用万兆交换机串连起来，部署在一个机房，称之为 Cluster(集群)，再上面一层是云游戏平台，包括用户的入口管理、登录计费等，可以跨越多个机房。

下图是系统架构图：

User Profile Storage 用来存放用户的存档数据，Log Storage 用来存储日志数据，还有数库等等。

Group 内的各 Node 组成对等网络，可以任意添加或者删除 Node，各个 Node 通过竞争算法选举出来一个 Master，由 Master 与 Manager 建立连接，对整个 Group 进行管理，如果Master出现故障则由剩余的节点重新选举出一个新的Master进行接管，从而保证了任何节点的故障不会影响到其他节点的正常服务。在Node 上仅需要安装好操作系统和 Daemon 服务，无须配置，即插即用。Node daemon对服务器进行管理和监控;游戏文件存放于 NAS 上，由各 Node 共享;内网/外网流量隔离，防止互相影响。

Manager 用于对集群内的所有 Node 进行管理， 配置/更新/上线/负载均衡/监控，游戏数据管理更新，用户数据管理等等。提供 web 后台给运维操作，实现运维的自动化和可视化操作。Manager使用双机热备模式实现高可用，避免单点故障造成整体系统瘫痪。

日志和监控。我们需要有完整的日志来记录和追踪系统行为，保障整个系统的可维护性。同时系统会实时监控每个游戏实例以及 Node 的状态，包括 cpu、gpu、网络io 的使用率，游戏帧率、延迟等等数据，所有数据保存下来，后面可以通过一些数据分析的手段来找到性能的瓶颈，然后再针对性的进行优化，进一步优化我们的系统。

提问：对家用的wifi做一些支持，能详细说说吗

乔捷：首先，要提示用户wifi信号不好会造成延迟，终端检测到网络信号不好时及时的提示用户。其次，对于网络延迟的抖动，我们的同步控制算法能够补偿一部分抖动。最后，可以在服务器上调优一下TCP参数，比如说减小数据重传的超时时间，加快数据包的重传，可以有效缓解抖动。

提问：对用户体验有影响吗

乔捷：目前肯定有，我们是标清的 720P 的画面质量，因为要考虑硬件成本和网络传输成本。但随着成本的逐步降低，未来要支持1080P甚至4K画质也是没有问题的。

提问：对于 CP 的开发模式有哪些影响

乔捷：目前没有影响，我们只是买一个授权，然后由我们进行对接，不需要CP方去改动代码。当然如果 CP 方愿意来对接我们的SDK话那是最好的，可以加入对战、排名、内购等各种功能，利用云游戏的特点为游戏增加更多的玩法。

提问：我们这么多年下来的计算，最早开始所有的计算都是在中心，随着终端计算能力的增强，计算很多功能都到终端上面去，现在你的方案是把所有的终端都放在中心，这对服务器成本要求很高如果能够容纳一些用户同时运行大型游戏，服务器成本是否会非常高

乔捷：对。为什么我们要中心化因为终端的种类太多了，手机、平板、电视、PC，这么多平台，你一个游戏要去移植这么多平台，本身的工作量就非常大，而且用户要去下载安装，推广的成本非常高，网络游戏单个用户的获客成本已经到了几十到上百块钱。所以，服务器成本表面上看是有点高，但是算上开发成本分发成本推广成本，这点服务器成本已经完全可以接受。

这就和视频一样，最早我们看视频是买光盘的，后来有了网络以后是从网络上下载，而现在宽带普及了之后已经没有人下载了，都是直接视频点播，因为它方便，门槛越低越容易被用户接受，现在还会有人买光盘吗基本上已经没有了吧。电视电脑都不是我们的工具了，大家现在用的比较多就是手机。计算资源越来越中心化集中，管理成本不断降低。现在买游戏机、ps3、ps4，每隔 5 年换一个游戏机，以后不需要游戏机更新换代了，更新换代对于厂商来说是一个比较痛苦的过程，有一个漫长的迁移过程。将来根本不用关心什么硬件，比如今年的“吃鸡”游戏非常流行，但是很多玩家的显卡性能不足，跑不起来。将来游戏都是放在服务器上跑，用户根本不用担心跑不跑得动，接上就可以玩。一旦这个服务模式成立，硬件厂商都会向这个方向投入资源，最早2011年的时候我们就预研过云游戏的技术，当时做了以后就放弃，后来看到这个机会以后推出来了grid显卡，一下子拉很高，看这一块商业模式什么时候落地，现在还是在探索的过程当中，将来是大趋势。

提问：除了服务上面成本，要求终端的网络非常好吗对解码要求高么

乔捷：对，因为网络非常普及的情况下，宽带已经无处不在了，所以这个问题基本已经被解决了。现在的主流中低端芯片可以实时软件解码720P的视频流。

提问：我知道游戏有很多种类，目前云游戏技术支持的范围怎么样云游戏的交互目前为止是否还很有限

乔捷：主要是主机游戏，用手柄玩的游戏。看类型，使用键盘鼠标的游戏比如FPS在电脑上比较好操作，在电视上就不太方便了，目前主要还是适配手柄操作的游戏。