第一篇：游戏运维编年史_可能是目前最详细的游戏运维指南
游戏运维编年史|可能是目前最详细的游戏运维指南
编者按：
一直以来，中国网游在世界上都处于举足轻重的地位。从最早的端游到页游再到手游，不仅市场用户爆发式增长，近15年来网游技术的发展也是无比迅速。和单机游戏不同，网游除了游戏制作本身以外还牵涉到服务器端，再好的游戏如果出现链接、延迟等问题时也会造成巨大损失，这时候游戏运维便发挥了举足轻重的作用。中国网游的发展史，其实也是游戏运维的变革史，今天便由经典武侠手游《大掌门》运维掌门人吴启超来向我们讲述，进入游戏领域10余年来的风风雨雨。
有服务器的地方就有运维
如今我们说到游戏，可能想到的是火爆异常的VR，办公室里一言不合带上眼镜就地开打；亦或是刚刚虐了李世石的AlphaGo，扬言要挑战《星际争霸2》“教主”Flash。然而，除去这些还有一个游戏行业不可避免的潮流正在发生，那便是网络化。
这里说的不止是网游，前不久育碧旗下网游大作《全境封锁》上线时闹出个小笑话：由于很多国内玩家下载之前没注意是网游，下意识的以为育碧的游戏肯定是单机，好不容易下完之后才发现玩不上，进而发生了不少的骚动。这不是第一个发生这种情况的传统游戏厂商，肯定也不是最后一个，很多有名的游戏公司都在做类似的尝试，Popcap的《植物大战僵尸：花园战争》系列，暴雪的《暗黑3》等，甚至那些还有单机成分的大作也早就开始网络化：大名鼎鼎的《GTA5》、FPS风向标《使命召唤》系列和《战地》系列，网络联机部分的比重也在一年一年的增加。
网络联机，意味着玩家需要登录官方服务器，“有人的地方就有江湖”，这句话说的不仅是网游里的恩怨情仇，还包括游戏外的种种：“有服务器的地方就有运维。”这便是今天我们要说的话题——游戏运维。游戏运维编年史
1，石器时代：端游
想要了解如今的游戏运维，不得不从早期的端游运维开始说起。对于08年入行端游，11年经历过页游最后14年全面接触手游的吴启超来说，这几年的游戏运维经历让他深切感受到运维思路的巨大转变。
1.1 端游的运维工种：IDC运维、系统型运维、网络运维、业务型运维、运维值班等。各个工种分工各有侧重。
IDC运维：装机、换配件、扛着2U的服务器全国各个机房来回跑。
系统运维：安装各种软件，调试各种不兼容的软件，在各种版本的Linux、Windows上。网络运维：二层交换、三层交换、四层交换，还要区分华为、思科。业务运维：24点维护，零晨2点维护，零晨5点维护，早上7点维护…… 运维值班：0点盯着屏幕打电话，1点盯着屏幕打电话，2点盯着屏幕打电话…… 运维开发：写着各种的逻辑，因为业务、网络环境、BUG、刚刚帮忙扛完服务器。
1.2 端游运维业务范围：在端游时代，大部分游戏公司都是自主做各种业务环境，做各种游戏业务需要的各种环境。
资产管理：服务器、交换机、各种服务分布位置，端口等。
下载服务器：搭建BT集群，做种子、分发，供玩家下载游戏客户端使用。静态缓存服务器：squid + apache|nginx 邮件服务器：postfix +sasl +ssl收发服务、反垃圾邮件服务。
网络质量监控：somkingping各个机房的交换，各个安放点服务器。配置管理：nginx、apache、lighttpd、MySQL。批量管理：ssh公钥/私钥。
监控管理：nagios、catcai然后是c|perl|python|shell +rrdtool各种业务监控图。1.3 端游游戏服务器架构：一般来讲都是以一组服务器集群为一个区服单位，单机上的进程提供不同的服务。
传统运维，任务道远，正因为有过去那些年的翻译文档，兼顾整合方案，以及大批分享技术的前辈、社区，踩着前辈一步一个坑的走过来，才能有今天的运维的局面。
2，青铜时代：页游
在2011-2013年左右的页游运维，游戏市场处于探索期，其实运维也处于探索期。端游时代每个新服都要经历上架、装系统，装服务的过程，一般一到两周可以上线一个区服，对于端游高粘性低流动的特性来说可能还好，但是当页游出现时，转变给运维带来的冲击无法估量。页游时代1天开100多个新服的概念，是传统端游运维所不能理解的。当时的运维认为页游就是把所有服务器实现自动部署服务，同时搭配运维自动部服工具就可以了。但事实上如果在开服时一组一组的使用物理服务器，开服速度根本跟不上，资源浪费还非常巨大，两周后用户留存率仅剩5%-7%。成本巨大亏空，急需技术转型，这个时间点上出现了两种概念影响了以后的手游以及云的发展。
1.虚拟化技术 在2010年11月份左右，kvm出现在RHEL6中，去掉了RHEL 5.X系列中集成的Xen。正是这一次虚拟化技术的转型，而且当时市场的需要，在2011年-2012年掀起了一场私有云建设的风潮。在实践过程中，优点很多，但暴露的缺点也不少。在端游占主要市场的情况下，实践过程中表现出来的不适尤其明显。
a.虚拟机时钟不准
b.虚拟机网卡，超负荷down、丢包 c.多虚拟机间争抢cpu、内存
d.多虚拟机间的安全访问，虚拟机与物理机间的安全管控 e.对于关系型数据库磁盘读写慢问题突出。f.等等
以上几点随着时间的推移有的已经然后解决，有的换上了代替方案。时至今日，端游在单纯的虚拟云上部署仍是问题，但是随着物理、虚掩混合云出现，这个局面应该可以被打破。
2.社交化的页游
社区化的页游戏，为什么这样说呢，因为当时更多的页游信托社区入口，导入用户流量，当时最火的应该是人人网（校内网）的农场偷菜。然后是DZ论坛一堆农场插件袭卷全国，当然这一切都是为了增加用户粘稠度。但是也影响了页游技术的选型，当时基本上大家不约而的选用了于社区相同的LAMP的技术，从而降低开发成本及接入成本。当然现使用JAVA SSH2架构的页游也有。除技术选型外，同时还带入了另一个概念：联运。联运这个概念在页游时代对于端游运维就像一个恶梦，不同区服要随时跨服站，不同区服要随时可以合区，所有数据不再是以物理服务器为单位，而是要逐条打标签，再也看不到账号，只能拿着一串长长的KEY，四处兑换，然后拿着不知道所谓的表标问第三方…….在这个时期，是运维开发的爆发年，随着虚拟化技术的推广，越来的越多的运维开始接触自动化运维的概念，开始了自动化运维的奋斗之路，开始了以项目管理的角度看待运维脚本开发。
3，黄金时代：手游
随着私有云转为公有云、云时代推动着云计算以及移动互联网的发展，网游行业慢慢进入了手游黄金时代，云时代的变革不仅挑战了整个游戏行业，也挑战了游戏运维。
3.1 手游的运维工种：系统型运维，业务型运维。
3.2 手游运维业务范围：阿里云、亚马逊、UCloud、蓝汛CDN、听云监控。3.3 手游游戏服务器架构：一般来讲都是以一组服务器集群为一个平台单位，不同的集群提供不同的服务。
手游的架构理念是提供一组虚拟服务器，当短连接的时候，每开一组服，将玩家引导到Web集群，随后被分配到不同的MongoDB，数据缓存用在Redis。当第一个服务器玩家请求DB时，会落到Mongo1上；当开第二个服的时候，还是将玩家引导到Mongo1上；以此类推直到运维发现压力累积到一定程度时，便会新开一组MongoDB，Web集群也是如此但只有性能不够时才会添加，一般情况下，每50个新服可能需要添加1个MongoDB。这便实现并解释了当时在页游里希望实现的快速开服方法。
到此为止我们已经回顾了一遍游戏运维从端游到页游再到手游的演变过程，不难看出，手游对于区服的架构概念不同于端游：端游认为一个物理集群是一个服，而手游认为一个Web请求落到相应的数据库上就是一个服。这样的好处是开服合服都简单，如果前五十组服务器需要合并，实现起来很容易，因为同一个DB的数据是互通的，所以只需发一个公告，服务器加标识即可，不需要进行物理操作也不需要数据迁移。游戏运维最强指南
说完了游戏运维的历史，我们要开始今天的重头戏，如何做好游戏运维？这里就用吴启超的一个冷笑话作为开始：运维为什么存在？a，有服务器；b，因为研发忙不过来。不管是笑没笑，运维确实因为上面两个原因才会诞生的。那么回到正题，想成为玩转上千服务器的游戏运维应该怎么样做呢？系统部运维构建大致如下图：
1，构建CMDB
21世纪什么最重要？信息最重要！运维所需信息要涉及：机房、物理服务器、虚拟机、交换机、网络、承载业务、业务配置、承载服务进程、端口等信息。不管是自己采购还是购买云服务，物理服务器和虚拟服务器都做为资产存在，在采购后录入相关的资产管理，给它打上标签，属于哪个游戏，哪个平台，这样不同游戏平台间就不能混用服务器了。然后，是再给不同的服务器标识它承担的业务角色，比如它是MongoDB，我们需要打上的标签会是大掌门-APPSTORE-MongoDB-主库-90000端口-第一组服务。这样一个基础信息录入就完成了。
这样的信息只要是用来将来批量化部署、管理服务器使用，以及当出现故障时，运维可以很方便的查询相当的服务器以及服务信息。但是数据的及时性、准确性、可检查是一个难点。
2，集中批量化管理 CMDB不是TXT文件，而是要变成EXE文件。运维在面临大量服务器的情况下，批量化工具的出现成为必须的结果，在日常的工作当中需要把其流程固化下来，为完成批量化安装、管理打下基础。大掌门喜欢使用sshsshpassparamiko libssh2这些基础的技术做批量管理。原因是不用安装简单、稳定、安全、可控。当然吴启超也表示推荐大家使用在市面上流程行puppet、Ansible、SaltStack等技术，为什么？简单、简单、简单！下图就是在做自动化半自动化运维过程中的模型。
批量管理的难点在于：
a.命令的并发执行，要控制各点的超时时间 b.执行过程中，不同功能的不同权限要求
c.数据通信安全的保证，以及能够正常解析数据指令 d.人员账号权限管理，权限分发及回收
e.物理服务器、云服务器统一化安装及老项目改造
f.网络质量不可靠的情况下，执行不完整的情况下业务功能回滚。
3，性能与业务监控
应用性能监控
1、每天都会对服务器进行上线，升级等操作，每款游戏在一个平台的集群数在几十个到几百个不等（根据平台大小）。因此每天维护和升级服务器压力极大，服务器异常或响应慢等问题的发生会给用户体验带来伤害。这样的隐患在于一旦发生游戏关服之后就必须对玩家进行游戏中货币和元宝的赔偿，平均每个玩家补偿的元宝至少在5元以上，游戏币和各类游戏道具若干，以此类推由于服务器故障造成的损失可想而知。
2、大掌门使用了听云Server，能够对服务器响应慢和不可用进行定位，查看慢应用追踪和Web应用过程功能，能够实时定位消耗资源最大的代码和语句，这样就能帮助实时进行有针对性的调整和优化，并且可以快速定位问题时间，最快能到分钟级别。
3、发生高并发、服务器压力激增的情况时，平时运行正常的服务器异常概率大幅增加，日常可能的性能瓶颈点会被成倍放大，这就需要实时定位和解决性能瓶颈点，和提前进行预防改善。一般来说，传统日志收集方式耗时耗力，效果非常不好，大掌门用了听云Server后，可以进行1分钟级定位能迅速有效发现瓶颈点。同时还结合了听云Network的压测功能，能够在服务器上线前提前发现到高压力下的瓶颈点，提前预防，避免由于高并发出现的服务器瓶颈
4、还有一种性能情况需要提前预防，游戏公司盈利在于玩家的充值，对于官网上从登陆到充值全流程的成功率业务部门极其关注，玩家点击跳转的失败会直接导致充值付费用户的转化率。对此，大掌门通过听云Network的事务流程功能能够实时对事物流程进行警报，帮助业务部门提升用户充值的转化率
业务监控
除了性能和硬件监控之外，对于游戏业务运转是否正常也需要建立一套标准去评判。
对此，大掌门开发了一套适用于全公司所有的游戏的统一登陆、充值、交易平台，解决了前端的SDK接入的问题，一个所有游戏或第三方的API接口统一接入的平台。在做业务型监控时，运维会要求后端开发人员写一个特定账号，在访问现有系统时，会完整的走一遍业务流，这样就可以看到需要的业务数字。
4，数据仓库搭建
上图为大掌门数据仓库的结构图，由于数据仓库搭建的话题比较大，只是简单的从数据集市的角度来聊聊，DM指的是数据集市。由于数据集市需要面对不同的人群，因此在数据仓库中需要建立不同的数据集市以面对各方的查询需求，进而对数据按照业务类型进行分类。
1、财务：关心月度充值数据
2、商务：关心渠道结算数据
3、运营：关心用户登陆量、转化率、留存率、平台充值额
4、产品：关心功能热度、用户体验
5、客服：关心所有数据及玩家属性
对于数据方面，运维的压力来自于需要贯穿及掌握所有的数据，并且为所有部门服务。简单的以下图的ETL为例：
数据对于运维的痛点：
1、日志切割工作谁做？研发还是运维。日志切割按什么规则？大小还是日期？
2、使用什么工具进行日志收集？scribe 还是flume还是 sls？
3、数据的准确性谁来保证？日志内容不对、切割不对、传输丢失、入hadoop过滤
4、数据ETL过程监控，如果出现数据丢失怎么办？
5、数据采集怎么样尽可能的保证并发的采集，缩短时间。
6、数据的出现丢失或错误，整体数据回滚。谁来保证？怎么保证？
7、大量数据下，核对数据丢失情况怎么样核对？用什么方法？
那大掌门又是如何解决这些问题的呢：
1、将数据日志进行切割（按照业务打包日志）并合理命名。比如A登陆日志，B充值日志，C消费日志。分门别类进行打包后，对数据每5分钟切割1次，并生成md5包。
2、按照划分IDC Region。原来从本机向外传输数据会占用大量带宽，对于本身CPU的消耗大的话都会影响游戏的运行。现在按照IDC region做出划分，每个区域中会有1-3个中心存储服务器。将切割下来的数据放到中心存储上，划分成Aip1、Aip2、Aip3等md5压缩包，此处无需做合并（原因见3）。
3、建立下载任务。建立好任务列表后，对每5分钟的压缩包进行下载。考虑到如果上面的步骤做了合并的话就可能会产生在传输的时候丢数据却无法确定的情况，因此2步骤无需对数据进行合并。
4、将下载后的任务加到Hive数据仓库里。将当天的数据放到MySQL中，之前的数据放到Hive里。当运营提出数据需求时便可以到Hive中下载数据。即使数据出现错误，按照上面建立的每5分钟的任务列表也可以重新以规定时间点将数据压缩包重新拉回来。并且该流程可以按照正向、反向双向进行。
采用5分钟压缩包的另外一个原因在于每台服务器每天产生业务日志大概有5-6G的数据，分到5分钟后，切割完每个文件就是20M－30M，压缩后只占用很少的空间。这样就解决了占用大量带宽的问题。
5、数据传输后需将数据放到数据仓库（DW）中，数据下载完毕后会根据文件进行存储，当天的数据按照5分钟1个压缩包进入MySQL，MySQL则进入当天的查询。在数据仓库中，数据包按游戏及平台进行分类，这种格局的安排为了在并发时更好的运行。由于游戏与游戏之间是隔离的，因此按照这种模式是为了保证数据进行顺利并发。
第二篇：游戏运维管理制度--安全管理
1.网络安全
1、所有信息系统内的资源，包括主机操作系统、应用系统、网络设备和安全设备，运维部都应指派专门的运维管理人员，进行日常操作和维护的管理工作，责任到人，保证信息系统的正常运行。
2、服务器实行7×24小时运行。在法定工作日的工作时间应安排具备相应专业技术水平的人员进行值班，遇当月有重大节假日，应根据实际情况提前安排值班表，并通知到值班人员。1.1.操作系统日常操作及维护
1、必须严格管理操作系统账号，定期对操作系统账号和用户权限分配进行检查，运维管理人员至少每月检查一次，并报运维部主管审核，删除长期不用和废弃的系统账号和测试账号。
2、必须加强操作系统口令的选择、保管和更换，系统口令做到：（1）长度要求：8位字符以上；
（2）复杂度要求：使用数字、大小写字母及特殊符号混合； （3）定期更换要求：每90天至少修改一次。
3、订阅计算机紧急响应机构的公告或第三方专业安全机构提供的安全漏洞信息的相关资源，及时提醒运维管理人员任何可能影响系统正常运行的漏洞。
4、运维管理人员需定期进行安全漏洞扫描和病毒查杀工作，平均频率应不低于每周一次，重大安全漏洞发布后，应在3个工作日内进行上述工作。为了防止网络安全扫描以及病毒查杀对网络性能造成影响，应根据业务的实际情况对扫描时间做出规定，需安排在非业务繁忙时段。
5、当运维管理人员监测到以下几种已知的或可疑的信息安全问题、违规行为或紧急安全事件系统时，应立即运维主管，同时采取控制措施，并记录工单： a)系统出现异常进程；
b)CPU利用率，内存占用量异常； c)系统突然不明原因的性能下降； d)系统不明原因的重新启动； e)系统崩溃，不能正常启动； f)系统中出现异常的系统账户； g)系统账户口令突然失控； h)系统账户权限发生不明变化； i)系统出现来源不明的文件； j)系统中文件出现不明原因的改动； k)系统时钟出现不明原因的改变； l)运行的进程突然中断或重启。
流程如图：
1.2网络设备安全
1.2.1 网络、安全设备日常操作基本原则
（1）操作前通报原则。对设备的任何更改都需要事先通知部门主管，在评估的基础上，经批准才能进行操作。
（2）操作前细化步骤。任何修改都需要提前准备操作步骤。对各种更改操作，准备可行的操作步骤，及操作后的验收步骤。对系统的配置和操作要完成相关的操作记录。
（3）对所有的操作，要求操作之前充分考虑并能预计操作之后的结果，每次操作都必须主动作好记录，以便事后审核跟踪。（4）操作后测试原则。操作完成后，立即验证是否影响到相关服务正常运行。
1.2.2 网络及安全设备管理
（1）、对网络和安全设备的管理必须经过严格的身份认证和访问权限的授予，认证机制应综合使用多认证方式，如强密码认证+特定IP地址认证等。
（2）网络和安全设备的用户名和密码必须以加密方式保存在本地和系统配置文件中，禁止使用明文密码保存方式。
（3）网络和服务器的配置文件，必须由负责此设备的运维管理人员加密保存，由专人加密留档保存，必须确保配置文件不被非法获取。
（5）运维管理人员对网络和安全设备的任何修改，都需要进行备案，对设备的重大修改和配置（如路由调整、系统升级等）必须向运维主管提交设备调整方案，由运维主管审核通过后方可实施。设备的配置和修改必须在非业务时间进行，重大调整必须提前准备应急预案和回退方案。
（6）开启网络和安全设备日志记录功能，并将日志同步到集中网管系统上，运维管理人员应定期对日志进行审计分析，至少每月审计一次，重点对登录的用户、登录时间、所做的配置和操作做检查。（7）对网络和安全设备的远程维护，建议使用SSH、HTTPS等加密管理方式，禁止使用Telnet、http等明文管理协议。
（8）所有网络设备（包含路由器、交换机、服务器、集线器等）均由运维部管理，其安装、维护等操作由运维部人员进行，其他
人任何人不得破坏或擅自修改维护。
（9）未经许可，任何部门或个人不得私自连接交换机、路由器等网络设备，不得私自接入网络。
（10）公司局域网的网络配置信息由运维部统一规划管理，其他任何人不得私自更改网络配置。
2.服务器系统安全
2.1应用系统安全日常操作及维护
1、新的应用系统在正式上线运行前应由运维管理人员进行安全检查，检查通过方能正式运行使用。严禁在不检查或检查未通过的情况下将应用部署到正式环境中。检查的内容包括：
a)检查应用系统的软件版本；
b)检查应用系统软件是否存在已知的系统漏洞或者其它安全缺陷；
c)检查应用系统补丁安装是否完整；
d)检查应用系统进程和端口开放情况； e)应用系统安装所在文件夹是否为只读权限；
f)检查是否开启应用系统日志记录功能，并启用日志定期备份策略。
2、应用系统上线运行后，应经过一段时间的试运行，在试运行阶段，应严密监控其运行情况；当发现应用系统运行不稳定或者出现明显可疑情况时，应立即将事件报告运维主管，并采取相应措施。
3、应用系统软件安装之后，应立即进行备份；在后续使用过程中，在应用系统软件的变更以及配置的修改前后，也应立即进行备份工作；确保存储的软件和文档都是最新的，并定期验证备份和恢复策略的有效性。
4、限定远程管理的用户数量，每设备管理用户不能超过5个；限定远程管理的终端IP地址，设置控制口和远程登录口的超时响应时间，让控制口和远程登录口在空闲一定时间后自动断开，超时响应时间最多不能超过3分钟。
5、网络和安全设备运维人员应定期对所负责的设备进行性能和故障检查，监控设备的CPU、内存、硬盘使用率和网络接口状态等使用情况，确保各设备都能正常工作，如发现异常情况，应立即报告信息管理部信息安全管理员，同时采取控制措施。
2.2 系统监控
为保证认证系统7*24的可靠稳定运行，需采用监控工具对整个系统进行全方位的监控，主要包含网络状态、硬件运行状态及系统服务状态等多个方面。
1、网络状态
主要监控网络的运行情况，如网络进出流量，当前线路质量，检测各种安全事件（入侵、探测、攻击）等等。
2、硬件设备状态
用情况进行监控，如硬盘空间、CPU使用率、内存占用情况等等，对网络设备如路由器、交换机、负载均衡设备的运行状态进行监控。
3、系统服务状态
对系统的所有服务进程的状态进行监控，可使用监控工具或脚本工具对服务的端口进行检测，也可通过定时运行模拟业务过程的检测程序对整个系统服务状态进行监测。
4、系统监控流程
系统的监控目前由安全监控室的运维值班完成，在上述监控内容出现异常时会通过监控屏幕及短信进行报警，根据出现的故障级别与故障类型响应处理。值班人员通知上报后依据值班规定完成相关的记录工作。
2.3网络病毒安全策略
1、运维部对防病毒软件的部署应该做到统一规划，统一部署，统一管理。
2、运维部防病毒软件必须统一进行病毒特征库的更新，至少每周进行一次。重大安全漏洞和病毒发布后，应立即进行更新，并在3个工作日内完成所有终端和主机的扫描工作。
3、运维管理人员应及时了解防病毒厂商公布的计算机病毒情报，关注新产生的、传播面广的计算机病毒，并了解它们的发作特征和存在形态，及时发现计算机系统出现的异常是否与新的计算机病毒有关。
4、运维管理人员应至少每次/月统计病毒报告，以分析历史病毒事件，加强安全策略防范。
5、新入网的终端及主机，在安装完操作系统后，要在第一时间内安装信息管理部统一部署的防病毒软件；没有安装统一防病毒软件的Windows系统不得接入公司网络；终端及主机不得私自安装非统一部署的防病毒软件。
6、所有运维管理人员操作系统上都应装有公司指定的杀毒软件，并开启相应功能。不允许在没有安装杀毒软件的电脑上执行相关服务器的操作。
7、服务器上应做相应的安全策略，限制只开启相关服务需要的端口。
3.数据安全
3.1数据安全日常操作及维护
1、公司内部服务端程序及数据属于保密内容，任何个人或部门不得泄露。拥有重要数据的部门应该及时对数据进行备份，防止数据的丢失；涉及数据备份和恢复的部门要指定DBA负责数据备份工作。
2、数据备份应根据不同业务制定不同的备份周期和备份策略，存放备份数据的介质必须具有明确的标识。备份数据应定期测试，以确保备份数据的可恢复性。目前采用的策略如下：
（1）数据库备份分为7天和30天两套备份方案
（2）30天备份方案为每天凌晨4点进行备份，存于本机上和备份机上，对于本机上的数据会自动删除历史数据。（3）30天备份方案为每隔2小时进行备份，存于本机上和备份机上，对于本机上的数据会自动删除历史数据。（4）对于临时需求的备份（临时备份指在特殊情况下，如软件升级，设备更换，感染病毒或更新前的容灾备份等），需由项目组
提交申请准予后，由运维管理人员负责备份。（5）对备份内容需确保业务数据完整、真实、准确地转储到备份介质上，备份介质需表明备份日期以及相关分类，备份数据应由专人保管。
3、备份介质必须归档。备份介质要有业务管理员负责保管工作。
4、数据清理前DBA必须对数据进行备份，在确认备份正确后方可进行清理操作。历次清理前的备份数据要根据备份策略进行定期保存或永久保存，并确保可以随时使用。数据清理的实施应避开业务高峰期，避免对联机业务运行造成影响。
5、数据恢复前，DBA必须对原环境的数据进行备份，防止有用数据的丢失。数据恢复过程中要严格按照数据恢复手册执行。数据恢复后，必须进行验证、确认，确保数据恢复的完整性和可用性。
6、数据的备份、恢复、转出、转入的权限都应严格控制。严禁未经授权将数据备份出系统，转给无关的人员或单位；严禁未经授权进行数据恢复或转入操作。当存储过重要数据的存储介质报废时应由专业技术人员进行物理性销毁。
7、建立双备份制度，对重要资料除在服务器存储外，外应拷贝到其他介质上，以防遭病毒损坏而遗失。
8、涉密文件和资料备份应严加控制。对管理权限应严格控制，未经允许禁止私自复制、转储。
9、对新上线的业务运行时应做好系统的完全备份，根据业务频率
和数据的重要程度做好增量备份
第三篇：运维管理办法
运维管理办法
目录
1.2.3.4.5.6.总则...............................................................................................................................3 系统运维管理办法.....................................................................................................3 数据库运维管理办法................................................................................................3 备份运维管理办法.....................................................................................................4 巡检管理办法.............................................................................................................5 请示报告制度.............................................................................................................5
1.总则
第1条 为了加强运行维护管理保障业务系统稳定可靠地运行，制定本运行维护基本管理办法。
第2条 实行预防性维护为主、故障性维护为辅的运行维护管理原则，预防性维护和故障性维护都应遵循事先设计好的程序进行。
第3条 完善运维管理体系，建立健全运维规范，提高运维管理效率，并不断提高运维质量。
2.系统运维管理办法
1.指定专人作为系统管理员，对系统的运行、管理、维护和安全负责，并按照规定负责系统和数据的备份与恢复。
2.定时对系统进行监控和健康性检查，分析系统运行和资源使用情况，进行必要的优化、调整和修正，及时消除隐患。
3.及时处理系统运行过程中出现的异常问题和软硬件故障，并采取必要措施，最大限度的保护好系统数据。
4.具有系统权限人员调离工作岗位或离职，应立即修改其保管的用户密码，或删除该用户。
3.数据库运维管理办法
1.对数据库的变更必须有记录，并且可以回滚。2.无用表和字段要及时清理 3.数据库进行修改、删除数据时要提前备份
4.设置对数据库的自动备份，以便在发生故障时，能尽快恢复数据，并定期检查备份计划的执行情况。
5.指定专人定期进行备份数据的恢复校验。6.做好数据库操作审计，以便对操作有据可查。
4.备份运维管理办法
4.1.目的
建立有效的数据备份和恢复机制，确保各系统备份工作按照计划正常完成，保证各应用系统的数据安全。
4.2.备份制度
1.正式使用的应用系统、操作系统日志、数据库系统、网络配置等信息必须定期进行有效备份且具有可复原性。
2.备份数据必须定期、完整、真实有效的转储到永久性介质上，并且明显标识。3.定时检查备份文件中是否存在备份失败的记录，如果有失败记录，需要检查故障原因，并进行排除。
4.备份计划设置要满足业务对数据安全性的要求 5.巡检管理办法
5.1.目的
定期了解设备的运转情况，做好系统日常运行的基础数据记录，做到有问题早发现、早解决，避免隐患，确保设备的完好率，保证系统运行质量。
5.2.巡检基本要求
1.对硬件设备进行定期巡检，是确保系统稳定运行的重要措施，巡检工作包括例行巡检、节假日和重要事件前的巡检
2.维护人员应根据工作计划，对维护的设备定期进行预防性巡视检查，巡查过程中应认真负责，及时发现问题，重点注意处在恶劣环境下、存在潜在质量故障的设备，巡查要认真做记录。
3.巡检过程中发现告警应立即进入处理流程，判定为故障的要立即进入故障处理流程
4.所有的巡检都应有详细的记录，包括时间、巡检情况和责任人，并应在巡检纪录卡上签字。
6.请示报告制度
6.1.目的
为加强相关信息处理和反馈管理，有效的控制系统和设备的运行状态，通过规范的请示报告流程，提高运行维护的管理效率。6.2.请示汇报内容
6.2.1.例行性请示报告
1.按照规程和制度规定的周报、月报、季报和年报。2.系统升级、交接和重大数据变更请示报告。3.各类专项请示报告和合理化建议。
6.2.2.紧急性请示报告
1.各种事故、严重设备故障、严重电路故障、系统运行异常等情况。2.各项工作中发现的严重泄密、安全性事故报告 3.业主要求的其他紧急性报告。
第四篇：运维岗位职责
济南科技中心运行维护岗位职责
第一章 部门职责
一、运行科
主要是指按照既定的工作流程和操作手册进行的系统监控、事件记录、日常操作、监控报告等具体工作，运行岗位工作具有程式化、流程化的特点。主要工作内容是负责济南科技中心部署的各类管理系统、操作系统、中间件、数据库的运行、监控和管理，以及各类设备、网络、基础环境的日常监控等工作。运行岗位包括值班长岗、运行操作岗、基础设施监控岗、系统环境监控岗、网络监控岗、自助设备监控岗。具体工作职责如下：
（一）负责制定济南科技中心运行值班管理的相关规章制度，并负责组织实施和考核；
（二）负责济南科技中心机房的安全运行管理，确保机房安全、稳定、高效运行；
（三）负责济南科技中心各管理系统和监控系统的日常运行监控和日常操作，保障各类业务正常开展；
（四）负责做好济南科技中心机房和监控室的出入管理；
（五）负责运行值班相关登记薄的格式制定、更新，并按登记薄格式进行及时登记，并定期存档保管；
（六）负责记录运行事件，并及时将异常情况转相应二线支持人员处理，跟踪事件处理过程；
（七）配合维护人员制定济南科技中心机房详细、可行的应急方案及措施，并定期组织人员进行模拟演练，有效防范各类意外情况和突发事件；
（八）配合做好机房设备和应用系统的安装调试、系统优化、版本升级及问题反馈等技术支持工作；
（九）根据外包管理相关制度，对外包人员进行统一管理考核，并对考核结果及时与外包公司反馈；
（十）每周、月汇总系统运行情况，提交事件统计、批量情况、故障处置、生产变更、报警情况等报表；
（十一）负责做好轮训人员基础培训及岗位安排；
（十二）完成领导交办的其他工作。
二、维护科
主要负责济南科技中心管理系统、操作系统、中间件、数据库的日常维护，基础设施与机房的环境保障，以及主机、网络设备的日常巡检、维护保养和应急处置等工作。主要包括基础环境管理岗、主机环境管理岗、网络环境管理岗、数据库管理岗、备份管理岗、安全管理岗、综合管理岗。具体职责如下：
（一）负责制定济南科技中心运行维护管理的相关规章制度，并负责组织实施和考核；
（二）负责制定各类维护登记薄的格式制定、更新，并按登记薄格式进行及时登记，并定期存档保管；
（三）负责济南科技中心机房主机及附属设备的规划、管理和维护，合理配置硬件资源；
（四）负责济南科技中心数据库的规划、建设和日常管理、维护工作，做好数据的备份、保密等安全管理工作；
（五）负责济南科技中心网络的规划、建设和日常管理、维护工作；
（六）负责济南科技中心机房空调、UPS、发电机、消防、配电等基础设施的日常管理和维护；
（七）负责管理系统、操作系统、中间件、数据库、基础设施、主机存储设备和网络设备的日常巡检，定期联系有关厂商工程师进行健康检查；
（八）负责济南科技中心生产环境设备的统一管理、登记及电子设备的购置、登记、维护、领用等管理工作；
（九）负责制定济南科技中心机房详细、可行的应急方案及措施，并定期定期组织演练，有效防范各类意外情况和突发事件
（十）负责起草整理每月济南科技中心运维工作月报；
（十一）负责进行各应用系统生产版本的提取、归入、变更请求维护等工作；
（十二）负责conflunce协同平台信息的更新和维护；
（十三）负责济南科技中心供应商的评价和管理；
（十四）完成领导交办的其他工作。
第二章 岗位设置
（一）运行科。由五个组构成，共设置七个岗位。五个组为运行一组、运行二组、运行三组、运行四组、运行五组。五组承担的职能和职责是一致的。每组设置值班长岗、运行操作岗、基础设施监控岗、主机存储监控岗、网络监控岗、自助设备监控岗六个岗位。综合管理岗独立于五组之外，并作为运行组的备用人选，以保证在运行组人员请假或其它安排后临时充实到运行组保证运行工作的正常进行。
（二）维护科。共设置9个岗位，包括基础环境管理岗、主机环境管理岗、网络环境管理岗、数据库管理岗、备份管理岗、中间件管理岗、版本管理岗、安全管理岗、综合管理岗。
第三章 运行科岗位职责
（一）综合管理岗
第一条 负责接受上级领导通知要求并按照相关要求告知运维科相关人员。
第二条 负责接受济南科技中心其它部门申请事项并报告运维科负责人后做好配合和反馈工作。
第三条 参与制定济南科技中心运行管理的相关规章制度、操作手册并进行汇总整理。
第四条 参与制定运维科月工作计划和完成情况报告并进行汇总整理。
第五条 负责安排报送运维科值班表，并协调好磁带异地存放工作。
第六条 参与制定计算机技术培训计划并进行汇总整理。第七条 负责运维科宣传材料、汇报材料的整理汇总工作，并对先进事迹宣传。
第八条 定期检查登记薄等需提前打印或印刷文档资料的存量，确定份数后联系综合部门提前准备；月底检查整理当月登记薄登记情况，并进行归档。
第九条 协助运维科负责人组织召开月工作例会，并形成会议纪要；协助运维科负责人完成好运行工作总结及各项工作汇报。
第十条 做好离岗人员的岗位交接工作，并对公司新入职人员进行资格审查。
第十一条 监督事件流转状况，形成事件总结周报。
第十二条 完成领导交办的其他工作。
（二）运行值班长岗
第一条 负责本组值班期间和日常工作期间值班人员的管理工作，维持本组工作纪律。
第二条 监督值班人员严格按照相关规定和制度进行操作和记录，对值班人员涉及生产环境的操作进行复核。
第三条 做好每日值班交接工作和轮班交接工作，及时更改应用系统管理员密码。
第四条 监督复核本组各岗位交接班情况，并对交接班内容进行签字确认；对各个岗位发现的异常进行监督指导。
第五条 监督复核非值班人员进入机房的必要程序，并按照相关规定要求对非值班人员在机房内的动作进行监督和记录。
第六条 熟练掌握济南科技中心应急方案要求和流程，出现应急事件能够按照相应流程快速通知维护人员和上报相关领导，配合维护人员共同分析处理问题，并把问题解决进展情况及时向领导汇报。
第七条 检查落实各登记薄登记信息和需归档资料的完整性和准确性；负责将需归档资料按类别分等级交与综合管理岗。
第八条 负责组织本组值班人员对值班期间工作进行分析总结，并对工作改进提出合理化建议，及时形成运行总结，交综合管理岗。
第九条 协助综合管理岗完成日常统计、汇报、制度编写、项目实施等工作。
第十条 做好本组值班人员思想工作，充分调动本组人员工作的积极性，全力保障运行工作的有序开展。
第十一条 负责本组值班期间值班室环境卫生，按时组织人员进行环境清理。
第十二条 监督复核每日批量运行状况短信发送情况，对运行快报的统计数据进行复核，并及时报送每日运行快报。
第十三条 在办公区域上班期间，负责安排本组人员参与相关项目实施及制度整理等工作。
第十四条 完成领导交办的其他工作。
（三）运行操作岗 第一条 严格按照各管理系统运行监控和操作手册进行监控检查和操作处理，并在相应登记薄上做好记录。
第二条 日常操作主要包括各管理系统日终批量处理、数据库备份、文件检查等。日常监控主要包括管理系统运行监控、网络运行监控、自助设备监控、IT资源监控系统监控等。
第三条 系统运行监控过程中出现的可疑信息和问题，及时汇报值班长并通知维护人员，同时做好认真登记，及时进行事件流转。
第四条 进行每日批量运行统计，认真填写，并以短信形式发送领导。
第五条 按照运行快报格式进行业务量及系统资源使用状况进行统计，并提交值班长复核。
第六条 统计每日管理系统运行日志，并在《系统运行工作日志》进行登记。
第七条 负责接听各办事处科技中心日常业务操作及其他相关事项的咨询，并做好解答和记录，需转发其他部门处理的事项应第一时间进行处理。
第八条 负责对值班长的各种操作进行复核。
第九条 完成值班长安排的其他工作。
（四）基础设施监控岗
第一条 负责监控包括动力环境监控系统、视频监控系统、门禁系统、大屏显示系统、消防系统、广播系统等系统的运转状况。
第二条 协助基础设施维护人员制定应急演练计划，并参与实施基础环境各种应急演练。熟练掌握基础环境的各种应急方案和操作流程。
第三条 在发现系统报警后，立即通知维护人员和值班长，并协同值班长进入现场查看处理，同时要认真填写运行监控工作日志，告警信息和故障处理记录准确完整。
第四条 严格执行监控系统维护管理制度，积极配合维护管理人员做好监控系统的维护工作，确保监控系统始终处于良好的运行工作状态。
第五条 定时查看基础环境各监控系统的运行情况，确保监控系统运转正常。
第六条 做好监控计算机和配套监控设备的日常维护保养，保持监控工作台面监控设备、资料摆放整齐，洁净无尘。
第七条 了解消防监控系统和气体灭火系统的原理，掌握消防系统安全操作规程和消防应急预案，对消防报警信息能够准确判断、及时作出正确合理的操作动作。
第八条 做好监控数据的统计、分析，定期向值班长报告基础环境运行状况。
第九条 协助维护人员进行故障排查，并对排查结果及时向值班长汇报。
第十条 完成值班长安排的其他事项。
（五）主机存储监控岗
第一条 负责监控机房各主机、存储、光纤交换机、加密机、磁带库等硬件设备的运行状况，并做好记录。
第二条 负责监控各主机设备的CPU、内存、换页空间、磁盘IO、网络IO等资源利用情况及分配空间的使用情况，并做好记录。
第三条 负责监控各主机设备的错误日志，并做好相应记录。
第四条 负责监控双机软件的运行状态，包括各节点、心跳线（或锁盘）的状态，并做好记录。
第五条 负责监控并记录带库备份管理系统的数据备份任务执行情况。
第六条 熟练掌握主机系统的应急方案，出现应急事件能够按照相应流程快速通知维护人员和上报相关领导。
第七条 协助值班长和维护人员解决各类主机异常问题。
第八条 完成值班长交办的其他工作。
（六）网络监控岗
第一条 负责监控网络设备、网络链路、安全设备、安全系统、入侵防御系统、网络监控平台的运行情况，保障各类设备正常运行。
第二条 负责网络设备及系统的日常巡检，并做好相应记录。
第三条 负责网络运行信息的收集、整理，并做好相应记录。
第四条 熟练掌握网络系统的应急方案，出现应急事件能够按照相应流程快速通知维护人员和上报相关领导。
第五条 协助值班长和维护人员解决各类网络异常问题。
第六条 完成值班长交办的其他工作。
（七）自助设备监控岗
第一条 负责监控自助设备监控系统的运行情况，并做好相应记录。
第二条 及时响应并处理自助设备监控系统中出现的突发性事件，并做好相应记录。
第三条 负责监视各地市自助设备的运行状况，保障各类自助设备正常运行，督促各地市做好自助设备的维护工作，并做好相应记录。
第四条 统计各地市每日自助设备数量、故障及开机率情况，并做好相应记录。
第五条 熟练掌握自助设备监控系统的应急方案，出现应急事件能够按照相应流程快速通知维护人员和上报相关领导。
第六条 协助值班长和维护人员解决各类自助设备监控系统异常问题。
第七条 完成值班长交办的其他工作
第四章 维护科岗位职责
（一）基础环境管理岗
第一条 机房基础环境管理岗工作范围包括机房精密配电设备、配电室供配电设备、柴油发电机系统、UPS系统、空调系统、消防系统、机房弱电系统（包括大屏幕显示、动力环境监控系统、视频监控系统和门禁系统等）。
第二条 负责检查机房基础环境运行监控情况，并监督基础设施监控岗工作情况。
第三条 负责机房基础设施日常巡检和维护管理工作，了解分析设备运行情况，及时处理解决相关设备故障和技术问题，确保机房基础设施的安全稳定运行。
第四条 负责机房基础设施管理制度、操作规程和应急预案的制定和修改。
第五条 负责机房基础设施相关流程（如事件、问题和变更等）的发起和处理。
第六条 负责机房基础设施应急预案演练和应急处置的具体实施工作。
第七条 负责机房基础设施的安全评估工作，及时发现存在的风险，提出整改措施并加以实施。
第八条 负责机房基础设施运行监控人员的培训工作，定期对机房基础设施新进或轮岗运行监控人员进行培训。
第九条 负责机房基础设施相关项目建设和改造工作，配合完成新系统上线工作。
第十条 负责各监控系统用户权限设置、密码管理和数据管理。
第十一条 负责基础环境运维工作的分析、总结，负责运维报告的报送。
第十二条 负责定期收集整理登记簿、维护记录等需归档资料，并交综合管理岗统一管理。
第十三条 参与制定济南科技中心运行维护管理的相关规章制度并进行汇总整理。
第十四条 配合综合科做好门禁卡录入、销户和权限修改工作。
第十五条 完成领导交办的其他工作。
（二）主机环境管理岗
第一条 负责机房主机设备的日常巡检和维护工作，发现故障及时报告，并详细记录故障发生的现象、时间、原因及处理方法，最终形成应急事件处理报告，并及时更新应急处置手册。
第二条 负责检查主机环境运行监控情况，并监督运行值班主机岗工作情况。
第三条 负责审查和上报主机环境生产变更，审计监督生产变更实施过程，并负责填报各类申请变更单及登记簿。
第四条 负责制定主机环境应急预案，并定期组织相关人员进行应急演练，确保各类设备的安全、稳定运行。
第五条 负责机房主机设备配置项类别、属性、关系的记录和维护（包括配置项的添加、修改、删除等动作），保持生产环境设备配置项的准确性、连续性和与实际使用情况的一致性。
第六条 在重大变更发布之前，对配置项进行基线版本备份保存。
第七条 协助执行机房设备配置项审计。
第八条 负责实施各级使用人员对主机设备的维护请求，并记录事件管理单。
第九条 负责制定生产环境各主机设备维护保养计划，并定期做好落实。
第十条 负责设备硬件和操作系统安全策略和风险防范制度的制定、部署和落实。
第十一条 负责定期对主设备的软、硬件系统进行维护和升级。
第十二条 负责定期对主机进行系统备份，并检查备份数据的有效性。
第十三条 负责每月总结生产环境各设备的硬件运行情况、资源利用情况，并对可能存在的风险向上级领导做出合理化分析和解决措施。
第十四条 负责分段掌管各类主机超级用户密码，并定期更换。
第十五条 审计各类主机和设备安全管理日志。
第十六条 负责接受济南科技中心其它部门申请事项并报告运维科负责人后做好配合和反馈工作。
第十七条 参与制定济南科技中心运行维护管理的相关规章制度并进行汇总整理。第十八条 参与制定维护科月工作计划和完成情况报告并进行汇总整理。
第十九条 负责主机环境维护有关技术资料和需归档资料的收集、登记、归档、保管等工作，定期将系统环境维护需归档资料按类别分等级存放保险柜。
第二十条 做好定期检查登记薄等需提前打印或印刷文档资料的存量，确定份数后联系综合管理岗提前准备。
第二十一条 配合备份管理岗做好数据备份磁带的管理工作。
第二十二条 负责制定主机环境维护人员的培训和技术交流计划，上报并组织实施。
第二十三条 负责与其他部门的沟通协调，保障各项工作的顺畅开展。
第二十四条 完成领导交办的其他工作。
（三）网络环境管理岗
第一条 网络系统包括生产核心网络、广域网和外联网络、呼叫中心网络、省联社网络等生产业务相关的网络环境及开发测试网络、办公网络、互联网络和电话网络环境。
第二条 组织制定和汇总整理济南科技中心网络环境维护管理的有关规章制度，并按照网络维护管理制度对网络系统设备和系统做好日常巡检维护工作。
第三条 负责检查网络环境运行监控情况，并监督网络监控岗工作情况。
第四条 负责机房网络设备及安全设备的维护工作，发现故障及时报告，并详细记录故障发生的现象、时间、原因及处理方法，最终形成应急事件处理报告，并及时更新应急处置手册。
第五条 负责生产、办公、开发网络安全策略的部署。
第六条 定期对生产网络系统运行深入的健康性检查,并出具报告。
第七条 受理生产网络变更的申请,并起草实施方案和风险分析报告,报维护科长审核后进行实施。审计监督生产变更实施过程，并负责填报各类申请变更单及登记簿。
第八条 负责每周、月、季度总结生产网络环境的硬件运行、网络资源利用、告警统计、网络变更等情况，并对可能存在的风险向做出合理化分析,提供解决措施。
第九条 负责接受济南科技中心其它部门申请事项,并报告运维科负责人后做好配合和反馈工作。
第十条 组织制定济南科技中心网络规划实施技术方案，并审计监督生产变更实施过程。
第十一条 负责制定网络环境应急预案，并定期组织相关人员进行应急演练，确保各类设备的安全、稳定运行。
第十二条 在重大变更发布之前，对配置项进行基线版本备份保存。
第十三条 负责实施各级使用人员对网络设备的维护请求，并记录事件管理单。
第十四条 负责制定生产环境各网络设备维护保养计划，并定期做好落实。
第十五条 负责设备硬件和操作系统安全策略和风险防范制度的制定、部署和落实。
第十六条 负责定期对网络设备的软、硬件系统进行维护和升级。
第十七条 负责分段掌管各类主机超级用户密码，并定期更换。
第十八条 审计各类主机和设备安全管理日志。
第十九条 负责受理各类开发测试部门及各类办公网络提起的网络接入需求,需符合安全接入要求。
第二十条 负责日常维护管理各类开发测试网络安全设备及各类办公网络安全设备、电话通讯设备。
第二十一条 负责处理开发测试网络故障及办公、电话、视频通讯网络故障处理。
第二十二条 负责日常办公客户端、电话的工位接入维护管理。
第二十三条 负责制定网络环境维护人员的培训和技术交流计划，上报并组织实施。
第二十四条 负责整理汇总网络环境维护宣传材料、汇报材料并上报。负责定期做好网络环境各类登记簿的修订与打印。第二十五条 做好定期检查登记薄等需提前打印或印刷文档资料的存量，确定份数后联系综合管理岗提前准备。
第二十六条 做好线路等各种费用结算工作。负责与网络安全管理相关的KVM、光纤、跳线、网线、水晶头等相关物品的登记、保管、领用、回收。
第二十七条 参与制定济南科技中心运行维护管理的相关规章制度并进行汇总整理。
第二十八条 制定网络、月度工作计划,并汇总整理完成情况进行报告。
第二十九条 完成领导交办的其他工作。
（四）数据库管理岗
第一条 负责制订管理系统数据库安全管理的有关规章制度。
第二条 负责管理系统数据库的规划、建设以及优化和调整，并做好技术支持工作。
第三条 负责管理系统数据库维护工作，定期检查错误日志，并做好数据存储、备份、清理等日常管理工作。
第四条 参与管理系统数据库的信息处理、信息挖掘和深化应用工作。
第五条 负责制定数据库方面的培训和技术交流计划，并组织实施。
第六条 负责测试环境的数据库的恢复及数据脱敏工作。第七条 完成领导交办的其他工作。
（五）备份管理岗
第一条 负责带库管理系统的维护工作，发现故障及时报告并详细记录故障发生的现象、时间、原因及处理方法，并记录事件管理单。
第二条 负责备份策略的制定和各类数据（包括交易日志、系统日志、数据库、归档日志等）的备份工作。
第三条 负责监督指导运行值班主机监控岗对数据备份的监控执行情况。
第四条 负责涉及磁带的数据维护申请，并做好数据的提取恢复。
第五条 负责磁带库数据备份磁带的管理和异地存放工作。
第六条 定期对备份磁带和数据进行恢复测试，并对周遭环境进行检查，确保磁带安全可用、备份完整有效。
第七条 负责过期和故障返厂磁介质的数据销毁工作，并详细登记相关销毁信息。
第八条 完成领导交办的其他工作。
（六）中间件管理岗
第一条 负责管理系统中间件的环境维护、参数维护工作。
第二条 负责管理系统中间件异常问题的解决，并提供相关技术支持。
第三条 负责制定中间件方面的培训和技术交流计划，并组织实施。
第四条 负责收集并分析中间件运行情况，并提出优化和调整建议，并监督确定后的优化调整建议落实情况。
第五条 完成领导交办的其他工作。
（七）版本管理岗
第一条 负责采用版本管理系统进行各应用系统版本提取、版本归入、变更请求维护等工作。
第二条 负责根据版本的更新情况，为版本制定意义明确的标识。
第三条 负责对版本管理系统的存储库、数据库和配置文件的日常维护工作。
第四条 通过版本管理系统向全省下发各种升级程序，并对各市的版本管理工作进行指导和监督。
第五条 定期对版本环境进行备份，并按类别分等级存放保险柜。
第六条 完成领导交办的其他工作。
（八）安全管理岗
第一条 安全管理岗负责济南科技中心安全管理工作。与其他各岗位人员协商共同制定济南中心整体安全规划，监督安全措施的执行。
第二条 根据领导小组工作部署，对信息安全工作进行具体安排、落实。第三条 负责对所有安全事件、报告的整理并分析工作。
第四条 负责升级或改造扩展时，对相应改造方案提出安全建议。
第五条 负责接受各单位的紧急信息安全事件报告，组织进行事件调查，分析原因、涉及范围，并评估安全事件的严重程度，提出信息安全事件防范措施。对涉及面较广的安全类事件及时上报领导，配合综合科做好宣传工作。
第六条 跟踪先进的信息安全技术。定期组织信息安全知识的培训和宣传工作。
第七条 负责各安全类报告的整理汇总工作。
第八条 负责配合渗透性测试及漏洞扫描工作，并对相关结果进行安全评估工作，对产生的问题计划整改工作。
第九条 负责济南科技中心安全桌面的管理工作。定期出具安全桌面工作报告。
第十条 监督和检查其他岗位人员安全执行情况。
第十一条 负责做好相关安全保障工作。
第十二条 参与制定济南科技中心网络安全策略。
第十三条 负责网络设备安全信息收集分析和安全状态监控。
第十四条 负责网络升级与改造扩展时，对相应改造方案提出安全建议。
第十五条 对网络安全事件应急处置处理并及时和定期上报。
第十六条 负责审计网络和设备安全管理日志,并出具网络安全日志分析报告。
第十七条 负责IPS、SEC Center、NSM等安全系统的维护及风险分析。
第十八条 负责出具济南科技中心网络系统安全运行情况的报告。
第十九条 完成领导交办的其他工作。
（九）生产变更管理岗
第一条 负责每月收集济南科技中心变更计划，向信息科技部报送，对变更发起人提交的变更文档进行初评。
第二条 组织生产变更的评估、审核，必要时提请召开变更委员会对重大变更进行审批，监控变更的实施情况；
第三条 协调解决变更中存在的问题；
第四条 组织变更回顾，编制管理报告，提出改进建议。
（十）供应商管理岗
第一条 负责与相关设备厂商的协调联络，建立并维护设备厂商的档案库。
第二条 负责供应商报告单的电子化扫描。
第三条 负责运维科所有设备及备品备件的登记、保管、维护等工作。
第四条 负责空白磁带、软件介质及相应资料的保管，领用记录。
第二十条 定期组织关人员对超过保管期限的档案登记薄进行审查、鉴定，对确无保存价值的档案登记薄按流程处理。
第二十一条 负责已归档资料保存期间的完成性和可用性。
（十一）综合管理岗
第一条 负责接受上级领导通知要求并按照相关要求告知运维科相关人员。
第二条 负责接受济南科技中心其它部门申请事项并报告运维科负责人后做好配合和反馈工作。
第三条 参与制定济南科技中心运行维护管理的相关规章制度并进行汇总整理。
第四条 协助运维科负责人组织召开运维科月工作例会，并形成会议纪要；协助运维科负责人完成好运行工作总结及各项工作汇报。
第五条 负责起草整理每月济南科技中心运维工作月报；
第六条 负责conflunce协同平台信息的更新和维护；
第七条 负责维护科宣传材料、汇报材料的整理汇总工作。
第八条 负责维护科各类文档资料的收集、整理、分类、保管等工作。负责组织并协调维护科各岗位人员进行文档资料管理等事务性工作。
第九条 负责制定综合管理岗位每月及全年工作计划和完成情况报告。
第十条 负责组织并协调运维科各岗位人员定期检查登记薄等需提前打印或印刷文档资料的存量，确定份数后联系综合部门提前准备。
第十一条 负责制定综合管理计算机技术培训计划，并组织实施。
第二十二条 完成领导交办的其他工作。
第五篇：IT运维现状
伴着IT在企业中的作用日益明显，IT建设和IT运维同时成为了企业效率的加速器。同时，计算机硬件系统和软件系统的运维已成为了各行各业单位，尤其是信息服务部门普遍头痛的事情。本文以下内容总结几个头痛的主要因子，拿出来供大家参考指导，并接下来的系列课题中会对针对这些现状提出改进措施。
现状一：IT运维人员成本偏高
据专业调查，大多数CIO表示最关心的是IT运维成本过高。原因是在过去的5年中,很多企业都实施了很多IT系统,使到IT运行越来越复杂,也越来越难管理。同时，其中有50%的受访CIO认为IT运维成本过高的一个原因是IT运维的自动化做得还不够好,依靠手工流程来管理,不但使到运维效率不高,而且人力成本更是花费惊人。
同时，另一家国际知名调查机构Gartner调查发现,在IT运维成本中,源自技术或产品(包括硬件、软件、网络等)成本其实只占20%,而流程维护成本占40%,运维人员成本占40%。流程维护成本包括日常维护、变更管理、测试成本等;人员成本包括训练、教育、人员流失、招聘成本等。
从图中，我们可以看出，“流程维护”类和“运维人员”两者都与软性方面的成本相关非常紧密。而且三者的关系可以用下图来表示：
备注：C类成本的大小很大程度取决于B和D类。
现状二：处在“救火式”的IT运维控制
目前，国内在IT运维过程中,IT员工大多数只是处在被动低效率手工救火的状态,只有当事件已经发生并已造成业务影响时才能发现和着手处理。这种被动“救火”会导致：①.IT运维人员终日忙碌，IT运维人员日常大部分时间和精力是处理一些简单重复的问题;②IT运维本身质量很难提高;③再加上故障预警机制的不完善,往往是故障发生后或报警后才会进行处理,不但事倍功半而且故障还常常会出现恶性连锁反应;④IT部门和业务部门对IT运维的服务满意度都不高。
现状三：简单的自动化程度起了“反作用”
尽管IT运维管理的技术在不断进步,但实际上很多IT运维人员并没有真正解脱出来，主要原因是目前的自动化不高而导致的。目前的技术虽然能够获取IT设备、服务器、网络流量,甚至数据库的警告信息,但成千上万条警告信息堆积在一起更本没法判断问题的根源在哪里。还有,目前许多企业的更新管理绝大多数工作都是手工操作的。即使一个简单的系统变更或更新往往都需要运维人员逐一登录每台设备进行手工变更,当设备数量达至成百上千时,其工作量之大可想而知。而这样的变更和检查操作在IT运维中往往每天都在进行,占用了大量的运维资源。因此,实现运维管理工作的自动化对企业来说已迫在眉睫。
就如图中一样，所有信息(杂乱)都从各个地方被收集到了这个圆圈(容量不变)里面，信息进去后不能主动流出来。可能会出现的情况：这个圆圈容器装满后会爆破，或者是溢出来;圆圈的运行速度会慢慢降下来，从而导致信息输入的速度也会变慢。
现状四：本是同家兄弟，却不经常来往
这个问题主要是发生在拥有许多子公司的企业，每个子公司的系统都是独立的，下面主要以国内银行业为例。以前国内的银行业没有搞集中建设，每家银行的各个地方分行都单独建设和维护自己的核心业务系统，都各自配备开发人员和维护人员。
同时在运行维护方面，对故障的解决，完全依靠运行维护部门的工程师的上门服务。不管问题大小，工程师都要来回去现场解决。遇到一些技术难度大的问题，如果工程师的水平高，处理起来就快;如果水平低，甚至花上几个小时，可能也解决不了。
虽然现在国内银行业的IT运行维护管理水平，有点接近国外80年代末90年代初银行业的水平，现在银行IT结构上都采用了大集中模式。从硬件设备上来看，国内银行不比别人差，甚至还有些领先，但IT运维管理还没达到国外当时的水平，尤其是呼叫中心、客户服务方面。”
结束语
从上面三个现状来看，主要是有关软性方面的。的确如此，国内借着近十几年高速发展，硬件方面的发展取得了重大进步，某些方面的水平甚至是超过了国外的水平，并且IT硬件的生产厂商也是出现了很多与国外厂商同等秀舞的水平，如华为、中兴等。但是往往是硬件易学，知识技巧难寻。这不仅与国内教育环境有关外，还与知识经验的继承又关。
点击咨询 