Linux运维经验总结

第一篇：Linux运维经验总结

Linux运维经验总结

一、线上操作规范

1、测试使用

当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了……庆幸当年运气比较好。

第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm-rf,在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份……生产环境数据被删了没备份，大家自己想后果吧，其重要性不言而喻。/ 8

2、Enter前再三确认

关于rm-rf / var 这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大，当你发现执行完之后，你的心至少是凉了半截。

大家可能会说，我按了这么多次都没出过错，不用怕，我只想说当出现一次你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。

3、切忌多人操作

我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码。

通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数……这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢？真的很恼火，切忌多人操作。

4、先备份后操作

养成一个习惯，要修改数据时，先备份，比如.conf的配置文件。另外，修改配置文件时，建议注释原选项，然后再复制，修改 / 8

再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧，所以说丢数据库非一朝一夕，随便备份一个就不用那么惨。

二、涉及数据

1、慎用rm-rf 网上的例子很多，各种rm-rf /，各种删除主数据库，各种运维事故……一点小失误就会造成很大的损失。如果真需要删除，一定要谨慎。

2、备份大于一切

本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇，我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过，我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次，我不多说了，大家自己斟酌吧

3、稳定大于一切

其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性，所以未经测试，不要再服务器使用新的软件，比如nginx+php-fpm，生产环境中php各种挂啊，重启下就好了，或者换apache就好了。

4、保密大于一切

现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密是不行的。/ 8

三、涉及安全

1、ssh 更改默认端口（当然如果专业要黑你，扫描下就出来了），禁止root登录，使用普通用户+key认证+sudo规则+ip地址+用户限制，使用hostdeny类似的防爆里破解软件（超过几次尝试直接拉黑），筛选/etc/passwd中login的用户。

2、防火墙

防火墙生产环境一定要开，并且要遵循最小原则，drop所有，然后放行需要的服务端口。

3、精细权限和控制粒度

能使用普通用户启动的服务坚决不使用root，把各种服务权限控制到最低，控制粒度要精细。

4、入侵检测和日志监控

使用第三方软件，时刻检测系统关键文件以及各种服务配置文件的改动，比如,/etc/passwd,/etc/my.cnf，/etc/httpd/con/httpd.con等；使用集中化的日志监控体系，监控/var/log/secure，/etc/log/message，ftp上传下载文件等报警错误日志；另外针对端口扫描，也可以使用一些第三方软件，发现被扫描就直接拉入host.deny。这些信息对于系统被入侵后排错很有帮助。有人说过，一个公司在安全投入的成本跟他被安全攻击损失的成本成正比，安全是一个很大的话题，也是一个很基础的工作，把基础做好了，就能相当的提高系统安全性，其他的就是安全高手做的了 / 8

四、日常监控

1、系统运行监控

好多人踏入运维都是从监控做起，大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率常见的有，内存，硬盘，cpu，网卡，os包括登录监控，系统关键文件监控定期的监控可以预测出硬件损坏的概率，并且给调优带来很实用的功能

2、服务运行监控

服务监控一般就是各种应用，web，db，lvs等，这一般都是监控一些指标在系统出现性能瓶颈的时候就能很快发现并解决。

3、日志监控

这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，就会很被动了

五、性能调优

1、深入了解运行机制

其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如nginx和apache，大家都说nginx快，那就必须知道nginx为什么快，利用什么原理，处理请求比apache，并且要能跟别人用浅显易懂的话说出/ 8

来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。

2、调优框架以及先后

熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的 适用于所有操作系统，不应该先从他入手。

3、每次只调一个参数

每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。

4、基准测试

判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素，测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能mysql》第三版相当的好，我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用。/ 8

六、运维心态

1、控制心态

很多rm-rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么，有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境越是有压力，越要冷静，不然会损失更多。

大多人都有rm-rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于mysql来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复，当然了大多时候你就只能找数据恢复公司了。

试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。

2、对数据负责

生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。

3、追根究底

很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过php代码报错发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了反复三四次之后，我就去谷歌数/ 8

据库表莫名损坏原因：一是myisam的bug，二是mysqlbug，三是mysql在写入过程中被kill，最后发现是内存不够用，导致OOM kill了mysqld进程并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。

4、测试和生产环境

在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。/ 8

第二篇：linux服务器故障之运维经验总结

服务器故障之运维经验总结

作为一个运维人员，遇到服务器故障是在所难免的，要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档，基本上这过程都会惨痛到让我们留下深刻的记忆。当出现此类问题时，应该如何处理？本文给大家详尽的分析了一下，一起来看看。

我们团队为上一家公司承担运维、优化和扩展工作的时候，我们碰到了各种不同规模的性能很差的系统和基础设备（大型系统居多，比如CNN或者世界银行的系 统）。要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档，基本上这过程都会惨痛到让我们留下深刻的记忆。

遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：

一、尽可能搞清楚问题的前因后果

不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有：

         故障的表现是什么？无响应？报错？ 故障是什么时候发现的？ 故障是否可重现？

有没有出现的规律（比如每小时出现一次）

最后一次对整个平台进行更新的内容是什么（代码、服务器等）？

故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)? 基础架构（物理的、逻辑的）的文档是否能找到?

是否有监控平台可用?（比如Munin、Zabbix、Nagios、New Relic… 什么都可以）

是否有日志可以查看?.（比如Loggly、Airbrake、Graylog…）

最后两个是最方便的信息来源，不过别抱太大希望，基本上它们都不会有。只能再继续摸索了。

二、有谁在? $ w$ last 用这两个命令看看都有谁在线，有哪些用户访问过。这不是什么关键步骤，不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。（ne cook in the kitchen is enough.）

三、之前发生了什么? $ history

查看一下之前服务器上执行过的命令。看一下总是没错的，加上前面看的谁登录过的信息，应该有点用。另外作为admin要注意，不要利用自己的权限去侵犯别人的隐私哦。到这里先提醒一下，等会你可能会需要更新 HISTTIMEFORMAT 环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令，同样会令人抓狂的。

四、现在在运行的进程是啥? $ pstree-a$ ps aux

这都是查看现有进程的。ps aux 的结果比较杂乱，pstree-a 的结果比较简单明了，可以看到正在运行的进程及相关用户。

五、监听的网络服务

$ netstat-ntlp$ netstat-nulp$ netstat-nxlp

我一般都分开运行这三个命令，不想一下子看到列出一大堆所有的服务。netstat-nalp倒也可以。不过我绝不会用 numeric 选项（鄙人一点浅薄的看法：IP 地址看起来更方便）。找到所有正在运行的服务，检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个Java或者Erlang什么的进程在同时运行，能够按PID分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点，必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着，那还是做个记录，回头有空的时候清理一下，重新组织一下服务器。

六、CPU 和内存

$ free-m$ uptime$ top$ htop 注意以下问题:

  还有空余的内存吗? 服务器是否正在内存和硬盘之间进行swap?

还有剩余的CPU吗? 服务器是几核的? 是否有某些CPU核负载过多了?  服务器最大的负载来自什么地方?平均负载是多少?

七、硬件

$ lspci$ dmidecode$ ethtool

有很多服务器还是裸机状态，可以看一下：

  找到RAID 卡(是否带BBU备用电池?)、CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。

网卡是否设置好? 是否正运行在半双工状态? 速度是10MBps? 有没有 TX/RX 报错?

八、IO 性能

$ iostat-kx 2$ vmstat 2 10$ mpstat 2 10$ dstat--top-io--top-bio 这些命令对于调试后端性能非常有用。

    检查磁盘使用量：服务器硬盘是否已满? 是否开启了swap交换模式(si/so)?

CPU被谁占用：系统进程? 用户进程? 虚拟机?

dstat 是我的最爱。用它可以看到谁在进行 IO： 是不是MySQL吃掉了所有的系统资源? 还是你的PHP进程?

九、挂载点 和 文件系统

$ mount$ cat /etc/fstab$ vgs$ pvs$ lvs$ df-h$ lsof +D / /* beware not to kill your box */

      一共挂载了多少文件系统?

有没有某个服务专用的文件系统?(比如MySQL?)

文件系统的挂载选项是什么： noatime? default? 有没有文件系统被重新挂载为只读模式了？

磁盘空间是否还有剩余?

是否有大文件被删除但没有清空?

如果磁盘空间有问题，你是否还有空间来扩展一个分区？

十、内核、中断和网络

$ sysctl-a | grep...$ cat /proc/interrupts$ cat /proc/net/ip_conntrack /* may take some time on busy servers */$ netstat$ ss-s

 你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？ 

   SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好, 不过对于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。

conntrack_max 是否设的足够大，能应付你服务器的流量? 在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？ 如果要显示所有存在的连接，netstat 会比较慢，你可以先用 ss 看一下总体情况。

你还可以看一下 Linux TCP tuning 了解网络性能调优的一些要点。

十一、系统日志和内核消息

$ dmesg$ less /var/log/messages$ less /var/log/secure$ less /var/log/auth

   查看错误和警告消息，比如看看是不是很多关于连接数过多导致？ 看看是否有硬件错误或文件系统错误?

分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。

十二、定时任务

$ ls /etc/cron* + cat$ for user in $(cat /etc/passwd | cut-f1-d:);do crontab-l-u $user;done

   是否有某个定时任务运行过于频繁? 是否有些用户提交了隐藏的定时任务?

在出现故障的时候，是否正好有某个备份任务在执行？

十三、应用系统日志

这里边可分析的东西就多了, 不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里:

     Apache & Nginx;查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。

MySQL;在mysql.log找错误消息，看看有没有结构损坏的表，是否有innodb修复进程在运行，是否有disk/index/query 问题.PHP-FPM;如果设定了 php-slow 日志, 直接找错误信息(php, mysql, memcache, …)，如果没设定，赶紧设定。

Varnish;在varnishlog 和 varnishstat 里, 检查 hit/miss比.看看配置信息里是否遗漏了什么规则，使最终用户可以直接攻击你的后端？

HA-Proxy;后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大小达到最大值了？ 

结论

经过这5分钟之后，你应该对如下情况比较清楚了：

   在服务器上运行的都是些啥？

这个故障看起来是和 IO/硬件/网络 或者 系统配置(有问题的代码、系统内核调优, …)相关。

这个故障是否有你熟悉的一些特征？比如对数据库索引使用不当，或者太多的apache后台进程。

你甚至有可能找到真正的故障源头。就算还没有找到，搞清楚了上面这些情况之后，你现在也具备了深挖下去的条件。当然还可以借助ITIL工具对CMDB资产的关联进行深入分析。继续努力吧！

第三篇：逃离故障的十条运维工作经验总结

逃离故障的十条运维工作经验总结

故障、于 DBA、于 运维人员 都是 心中永远的痛、而避免故障的原则却是殊途同归

现列如下、与君共勉

㈠

佛说：每次创伤、都是一次成熟、这便是运维人员的真实写照从某种意义上讲、运维是一门经验的学科、是一门试错的学科

没有做过的东西、总是会给你不期而遇的痛击

请保护现场、让 变更 有回头的机会

㈡ 对破坏性的操作谨慎小心

什么是破坏性的操作哩？

比如：

对 Oracle 而言：truncate table_name、delete table_name、drop table_name

这些语句执行起来轻松简单也惬意极了、但记住！即便数据可被回滚、代价也是非常大！

对 Linux 而言：rm-r 所有当前及其子目录的所有数据都将被变更要能回滚、先在同样的环境测试过

删除

经历过这种故障的人、大多会给 rm 上个别名

alias rm='rm-i'

同理、cp 和 mv 也可以有同样的选项：

alias cp='cp-i'

alias mv='mv-i'

㈢

在操作之前、先理清你所在的是主库、备库？当前目录？哪个 schema？session？时间？

比如：

对 Oracle 来讲：

[plain] view plaincopyprint?

1.idle> set sqlprompt 'RAC-node1-primary@10g>>'

2.RAC-node1-primary@10g>>

设置好命令提示

当然、你也可以在 glogin.sql 里面设置

对于 Linux 而言、bash 环境的提醒可设置 PS1 来知道当前目录、登陆用户名和主机信息等

对 PS1 更多理解、请见：man PS

1㈣ 备份并验证备份的有效性

人非圣贤、岂能无过？是机器总有计划内或计划外崩溃的一天怎么办？备份！！

备份的学问很大、按照不同的维度可以分：冷备和热备；实时和非实时；物理和逻辑

OLTP 7*24 在线业务、DB 就需要有实时热备

这样就可以了吗？

如果开发人员的一个不带任何条件的 delete 误删所有数据所以、此时你除了实时、还需要有非实时的备份、把 DB 从逻辑错误中恢复出来

备份有了、可以高忱无忧了吗？

不行！尚须验证备份的有效性

一个总有那么几次、备份无法保证 100% 恢复

简单的验证就是找个空库、恢复出来

㈤ 对生产环境永保敬畏之心

会计人员在从业之前、都有个职业操守的训练

同理、这也应该是运维人员进入行业首先需要具备的素养比如：

于 Oracle 而言、你可以跑一个 RDA 巡检 DB 的健康状况于 Linux 而言、是否有 password aging、隔离外网等

㈥ 交接和休假最容易出故障、变更请谨慎

接手别人的工作要一而再，再而三的确认变更方案。请教人并不见得就是能力不行的表现

休假前最好各种可以做好的事情，最好能够准备一份文档，指明在什么情况下怎么做和联系哪些人

在别人放假的时候接手工作，“能拖则拖”，实在需要执行：必须不厌其烦的跟原运维者确认各个操作细节

㈦ 搭建报警、及时获取出错信息；搭建性能监控、预测趋势

运维人员赖于生存的工具就是 报警和监控

报警可以让你及时知道系统出现了什么异常、以便及时跟进、把故障扼杀于摇篮

监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替嘛、早做优化

报警和优化是衣宽带水的好兄弟、相铺相成、互相促进

㈧ 自动却换需谨慎

比如、Oracle 存储级的HA方案：Data Guard

主库提交了一笔订单、结果发生了 switchover、这笔订单没有同步到备库

那么、卖家损失了一个销售单、对客户、对公司都是损失

㈨ 仔细一点，偏执一点，检查，检查，再检查

有这么一个人：

① 他在做一个变更的时候，会先提前一两周发送邮件并电话手机通知相关人

② 在测试机上写好脚本，召集大家 review 操作步骤和脚本③ 测试完成以后拷贝到生产环境

④ 登录对应机器，“打开，关闭，打开，关闭”该脚本

⑤ 跟相关人员再次确认执行的操作，顺序，时间点，可能的影响和回滚是否都准备好了

⑥ 执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本

⑦ 最后才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出

期间姿势端正，呼吸急促而均匀，眼神凝重。操作的人不觉得累，倒是一边学习的人很累

㈩ 简单即是美

这有点禅的意境、和 GNU/Linux 的思想不谋而合我们总是面临各种诱惑：

新的系统架构，新的更智能的命令和工具，最新的硬件平台，功能更全的HA软件...等

你可以在线下安装，测试，怎么搞都行。但是如果想要在生产环境下使用起来、请三思！

能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了

脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做

linux本身自带的字符界面比那些复杂的图形界面要简洁方便............

第四篇：烟草行业运维情况

IT运维：烟草业下一轮信息化的重点

畅享网

在国家局“做大做强”、“两个十多个”战略的指导下，国内烟草大市场、大品牌的格局将越来越明显，竞争亦将越发激烈。在这轮竞争中信息化手段将扮演重要的角色，企业对信息化的依赖起来越强，对IT服务水平的要求将越来越高。在信息系统的生命周期中，一般系统建设的时间大约为一年，而系统使用运维的时间大约四到七年或更长，因此，业界提出了“三分建设，七分管理”的说法。经过大致两轮的信息化建设后，烟草工业企业信息化将逐步趋于成熟，走向稳定，后续信息化工作的重点之一便是做好系统的运维工作，保障系统平稳运行，支撑业务发展。烟草工业企业IT运维工作面临如下主要的问题：

1、IT部门已经发布了运维的制度与流程，但业务部门对运维工作还是不满意。运维管理效率低下，相似问题屡屡发生，IT运维人员疲于奔命。

2、随着信息化硬件、网络建设、应用系统建设的不断完成和交付使用，如何整合运维人员，不同系统如何建立一致的服务流程

3、系统越来越多，技术越来越复杂，但部门人员却增长不多，哪些业务应该外包，哪些业务应该自己做

4、公司想上一套运维软件，市面都有哪些软件，各有什么优劣。

除了本部信息中心外，遍布全国的各生产厂部也有信息部门，系统建设都是由总部统一规划进行了，但在运维方面，是否应该有所不同，各厂部信息科在运维方面承担哪些职责？

一、烟草工业企业信息化发展态势

在2008年中国信息化500强排名中，烟草行业有23家企业入围，18家中烟公司中，除2家未能入选外（分别是湖北中烟、陕西中烟），其余均入围。排名靠前的有上海烟草，红塔、山东中烟、浙江中烟等。说明烟草工业企业整体信息化水平在国内企业界来讲处于较高的水平。

1、烟草工业企业信息建设历程回顾

烟草行业自2003年实施工商分离以来，工业企业方面经历了联合重组、两个“十多个”、工商协同、按订单组织货源、跨省重组等战略举措，逐步形成了18家中烟公司。配合企业变革的进程，烟草工业企业信息化已大致经历了两个阶段。第一个阶段从2003年到2006年，其主要内容是围绕联合重组的要求，为了满足中烟工公司成立，卷烟生产厂兼并重组的初步公司化管理的需要进行，主要工作有：基础设施建设、OA平台建设、统一的财务系统的建设等。此阶段信息化建设的特点是以基础建设为主，应急，缺乏总体规划。

第二阶段从2006年到现在。随着联合重组的逐步完成，如何整合资源，实现中烟公司对下属卷烟厂的管理管控需要，如何落实国家局“四个中心”建设的要求，烟草工业企业开始整体思考信息化建设的方向与路径。此阶段信息化建设的特点是整体规划，分布实施，稳步推进，以求全面支撑企业的发展。代表企业包括山东中烟、广东中烟、江苏中烟、浙江中烟等。

2、烟草工业企业信息化建设现状

现阶段主要工业企业第二波信息化建设接受尾声。多数企业已逐步进行ERP、MES系统的建设或已完成，形成了支撑企业运营的统一的信息化平台，构建了企业信息框架的核心。

接下来第三波信息化建设将逐步向供应链的两端及企业指挥系统的上下两端拓展，向专业化软件的引近过渡。如客户关系管理系统的建设，面向商业会员的工商协同系统的建设，面向供应商的SRM系统的建设，面向企业决策层的BI系统的建设，面向操作层面的自动化识别技术的应用等等。而系统之间的集成整合也将受到企业的重视。

与其同时，IT运维工作被提上烟草工业企业信息化工作的重要议事日程。IT运维与信息化建设相辅相存，信息化建设有赖IT运维的保障。信息化建设为企业业务运营搭建了支撑平台，但这个平台用得好不好，到底能不能产生预期的效果，除了用户的积极使用外，主要依靠IT运维。通过IT运维，一方面保障了信息系统的平稳运行，另一方面可以不断对信息进行优化与提升。

二、几家重点烟草工业企业IT运维现状

1、红塔集团

红塔集团作为烟草工业领头羊，其IT建设走在了行业的前列，早在2001年便实施了SAP ERP系统，并在2007年进行了系统的优化。同时部署了综合统计与经济运行分析系统。因此其较早的面临了大规模的系统化的IT系统运维工作。红塔集团建立了自己的IT服务软件系统，并从网络信息安全角度，从物理环境安全、计算机网络安全、计算机系统安全、网络信息安全制度等方面，建立红塔综合网络信息安全体系。采用先进的安全技术，构建了防火墙系统、防病毒系统、入侵检测系统、内部审计系统，建立起了一套完整的网络监督、控制和记录的系统，从技术上保证了系统的安全性和保密性；同时参照ISO17799标准，制定了《公司国际互联网安全管理规定》、《公司国际互联网保密管理规定》、《公司国际互联网保密管理实施细则》、《公司国际互联网用户守则》、《公司局域网安全及保密管理规定》等一系列规定，从管理上杜绝了滥用网络的情况，既保障员工既开放又规范地使用网络。2009，借助IBM Power Systems纵深拓展ERP平台，提高IT资源管理及服务管理水平。，并选择IBM的ERP业务系统灾备方案，在原有主机热备基础上采用IBM服务器及存储设备，构建全新的远程容灾备份系统。

2、上海烟草

上海烟草很早就开始重视系统运维工作，从2005年开始，信息中心对运行维护现状进行了深入地分析，确定了“产品与自主研发相结合”的策略，并开始着手建设信息系统运维平台。2006年基本完成了运维平台建设。

运维平台主要包括运维服务管理系统、监控管理系统，这两个系统之间相互联系、协调运作。同时，两个系统也可分离，根据企业的需要独立实施某个系统。其中，运维服务管理系统包含服务台、事件管理、变更管理、问题管理、发放管理、配置管理，并且以配置管理数据库及知识数据库为信息支撑；监控平台主要包括硬件平台监控管理模块、软件平台监控管理模块、应用系统监控管理模块和机房环境监控管理模块，系统管理员可以方便地通过这四个平台对企业内部的网络设备、主机、存储、数据库、中间件、业务系统和机房环境进行全面的管理。运维服务平台的建设并投入使用让上海烟草IT运维管理变“被动维护”为“主动维护”；维护服务标准化、产品化；以ITIL为基础实现主动管理。

3、浙江中烟

浙江中烟信息化建设近年来取得了较快发展，随着ERP系统的一期的上线使用及MES、营销相关系统的建设，浙江中烟亟需建立统一的IT运维管理平台。2009年，浙江中烟在ERP建设过程中，开始着手进行运维管理平台的选型，并最终选择了广通信达的Broadview产品，计划分两期进行建设和优化，目前正在进行中。与此同时，浙江中烟还进行信息安全体系规划与建设，选择了启明星辰进行信息系统风险评估、网络改造规划以及整体信息安全管理体系建设，目前已通过验收。

三、烟草工业企业IT运维的三个关注点

通过分析烟草工业企业信息化建设的发展历程及IT运维现状，并观察电信、金融、能源等IT运维发展，可以看到运维组织、制度、流程的建设和完善、统一运维平台的建设、运维外包及服务质量的管理将即下来大部分烟草工业IT运维工作的主要关注点：

1、运维组织、制度、流程制定与完善

伴随着系统的建设和逐渐投入使用，烟草工业企业陆续发布了运维方面的政策、流程，并安排不同人员进行跟进落实，但进入后建设时期存在如下问题： 运维制度、流程往往从单个系统去考虑，存在遗漏，缺乏统一性;运维工作尚处于事件、问题触发型，处于被动地位，缺乏主动运维的制度、流程支撑 随着系统使用的深入，部分运维政策、制度、流程未及时更新，已经不能适应需要，用户抱怨增加

运维政策、流程的落实不力，缺乏对运维质量的有效的监控措施

后建设时期，如何调整信息部门人员分工；信息化建设期间由本部统一规划实施，但在运维方面，本部信息中心与各卷烟厂（部）信息科如何分工，是否涉及运维力量配置的进一步优化空间

烟草工业企业已意识到采用IT治理框架所提供的最佳实践标准来对提升服务管理、信息安全、法规遵从等方面的重要性，如ITIL（ISO20000）、COBIT、CMMI以及ISO/IEC 27001等。部分企业已开始尝试用这些框架。

ITIL（ISO20000）侧重于对IT运维管理实践的指导。在国内目前的IT运维领域，ITIL已经在实践中被广泛采用。2007年，英国商务部（OGC）正式发布了ITILV3版本，提出了服务生命周期的框架，ITIL v3定义了服务生命周期的5个阶段：服务战略(Service Strategies)、服务设计(Service Design)、服务转化(Service Transition)、服务运营(Service Operation)、持续改进(Continual Service Improvement)，它包含了生命周期内管理服务需要的流程

烟草工业企业可参照ITIL的有关内容设计企业后建设时间的IT运维管理的组织、制度、流程。

2、统一的运维平台建设

（1）国内外常见的IT运维软件平台

目前常见的IT运维软件，国外的有CA Unicenter、IBM Tivoli、HP BTO（整合了OpenView、Peregrine、Mercury、Opsware等软件资产）、BMC Remedy、FrontRange等 BMC BMC Remedy ITSM Suite；BMC Magic Service Desk Suite。Remedy解决方案包括事件、问题、变更和资产管理模块。最新版本7.0 优点：底层开发平台的灵活性是其最大优势。流程方面功能强大、灵活；基础定制比较简单。Remedy的数据的报表能力很强，可以基于Crystal报表工具自由定制

缺点：系统在界面上处理得很不好，不够人性化；对配置管理特别是资产管理的成功案例说服力不是很强，相关的配套软件如网络管理软件没有像其ITSM产品一样著名。CA 管理解决方案、桌面管理、作业调度管理解决方案、eTrust 安全管理解决方案、BrightStor存储管理解决方案等，产品非常全面。

ServicePlus Service Desk解决方案可以与Unicenter解决方案集成，共同管理基础设施，也可以独立实施。

优点：技术上有很多优点的；其Service Desk解决方案（ServicePlus Service Desk）可以与其他品牌解决方案集成，共同管理企业的IT基础架构，也可以灵活与第三方厂商的解决方案进行集成；ServiceDesk有着简洁的界面，流程工单的相关关联信息也非常方便查看。

缺点：二次开发相对比较繁琐，自定义的表单和新流程的开发效率相对较低 HP HP BTO（business technology optimization）在战略、应用和运营三个层面惠普共提供了12个被称为“中心”的软件产品和方案。包含下述三个层面: 一是战略层面工具，包括项目和产品组合中心和SOA 中心;二是应用层面工具，包括性能中心、质量中心和应用安全中心;三是运营层面的工具，包括业务可用性中心、运营中心、网络管理中心、服务管理中心、客户端自动化中心、数据中心自动化中心和身份认证中心等。

在运营层面的HP Automated Operations 1.0组合中包括了IT Service Management（ITSM）、Business Service Management(BSM)和Business Service Automation（BSA）等解决方案

其中，业务服务自动化(HP Business Service Automation，HP BSA)软件解决方案，打造了单一平台实现跨应用程序、服务器、网络、存储设备和客户端的所有IT流程以及设备变更的自动化。该解决方案还提供了用于汇报的集中配置管理数据库(CMDB)，并降低了变更带来的成本和风险，确保了全面的审计和合规能力；升级的IT服务管理(IT Service Management，ITSM)软件增加了相关的服务，通过蓝图、培训和评估的形式提供了最佳实践。HP ITSM软件可以帮助企业从开始到终止的整个周期内，定义、交付和管理业务服务 IBM IBM Tivoli包括业务应用管理、存储管理、安全管理、资产管理、服务可用性和性能管理、服务交付和流程自动化、能效管理、SOA管理、虚拟化管理、云计算等类别系列产品和服务，如Tivoli 流程集成、Tivoli变更和配置管理数据库（CCMDB）、Tivoli流程管理软件、Tivoli的技术平台；Tivoli License Manager。优点：Tivoli软件的配置管理数据库领引了ITSM的热点，同时，Tivoli技术平台上针对各个具体领域（比如监控）的软件工具正日益完善。缺点： 国内主要的IT运维软件与服务厂商有广通信达、神州泰岳、游龙科技、摩卡、北塔软件等。

广通信达。广通信达最早从政府行业的运维起步，现在已发展成国内IT运维的主要品牌。其BroadviewIT运维管理平台已在浙江中烟，内蒙古烟草、云南烟草部署；

神州泰岳。神州泰岳立足于方案提供商，有自己的ULTRA系列软件，也是BMC Remedy的全国总代。

游龙科技专精于产品研发，从桌面管理、网络设备管理，到上网行为管理、系统管理和IT服务管理，都是一个集成化的产品，具有很强的可扩展性。其 SiteView软系列件已有江西烟草、河南中烟新郑卷烟厂等案例、摩卡，摩卡来自新加坡，最初为IBM分销商，目前已推出Mocha BSM、Mocha ITAM、Mocha ITOM、Mocha NTA、Mocha E2E等多项产品和服务，在电信、政府、金融、能源、制造等行业拥有众多案例

北塔。北塔早期以电力为主，逐渐向其他行业渗透，目前已推出BTIM、BTNM、BTDM等产品和服务，在多个行业拥有成功案例。烟草行业已有商洛烟草、江苏烟草、红河卷烟厂客户。

（2）IT运维软件平台选型的关注点

烟草工业企业信息化环境具有多平台、多厂商设备、多业务系统、地理布局分散等特点，IT运维管理环境趋向复杂多变，因此对IT运维平台的选择关注： 产品适用性：是否能监控到不同的厂商设备，不同的平台和业务系统等 方案成熟度（成功案例、同行案例）：是否有同行或类似行业的的实施案例、应用效果 定制活性。

其他：价格、实施人员的素质、售后服务等

3、外包的选择和服务质量的管理

据国外知名资讯机构的调查表明，全球90%的公司中至少有一项主要IT业务职能已进行了外包，IT运维外包服务在国外很多国家得到了充分肯定和广泛的应用。2005年，全球运维外包服务市场整体规模已达到726.37亿美元，市场增长率为9.5%。外资企业用户市场需求的不断发展和本土用户行业需求的不断深入，催生了中国运维外包服务市场的进一步发展。据统计，中国运维外包服务市场规模2005年达到38.69亿元，同比增长了20.2%。近两年来，中国IT运维外包服务市场仍将保持快速发展趋势，并极有望在2010年达到百亿元的规模。烟草工业企业受人员编制的限制，很早就开始尝试IT运维外包服务。如某南方中烟公司，其本部IT部门目前合作的运维服务商超过五家，包括桌面支持、网络维护、应用系统维护等，并专门提供几间办公室给外包人员办公。在此过程中，企业不断思考以下问题：哪些运维服务可以外包，哪些不能外包？如何管理外包服务的质量？

第一个问题涉及外包策略问题，需要在企业内部就外包的目的达成共识：是为了节省人力、降低成本、提高服务质量、变革创新，还是希望综合改进。并在此基础上明确梳理IT运维外包服务内容。一般来讲重复性的、事务性的、专业性的工作可以考虑外包，而涉及权限、数据、信息安全等应由企业自行负责维护。在外包供应商的选择上，应慎之又慎，方法之一是建立一套完善的外包服务商的选择标准，全方位考察外包供应商，包括技术能力、资金能力、人力资源、持续发展能力、经营策略、管理思维、企业文化、团队精神。在外包供应商的考核上，烟草工业企业可以通过部署ITIL的服务目录和服务水平协议，企业可以把整个外包内容细致化、量化，明确提出IT外包商该做些什么，并把这些服务项目放进服务合同。在上述外包协议中约定的内容基础上，企业应建立一套日常对外包商的监督检查机制。

企业应保持对外包商的更换能力。同时应注意，工作外包并不意味着责任外包，运维服务最终责任仍然要企业IT部门承担，要避免IT部门员工“外包给你们了，所有的事就应该都由你们来处理”思想的出现。

第五篇：运维工作计划

篇一：2015年运维部工作计划.修改 2015年工作计划

结合公司今年运营发展的思路,我部门今年将重点提升网络服务质量,提高运维人员综合业务素质。

一 运维部基本情况: 运维部主要维护十二师辖区和乌鲁木齐市区两部分,其中十二师辖区内有五大团场片区,共有用户44126(穿线用户)实际使用用户为35525,三网用户2237户，现有维护员13人。市区维护26个小区,共有用户22570, 现有维护员2 人.二 2014年运维部维修故障分析

2013年全年故障发生共10657起,占总用户数的2.5% ,故障率为,主要分为:马赛克，装修改线，公用电停电，用户光纤损坏，拆迁，机顶盒坏等。

1小区共用电停电造成的故障占运维故障的50%,主要原因是:不能及时补电，交纳电费受小区物业的控制.2 用户光纤损坏（人为和自然、工程）占10%,加强日常线路维护。

3老机顶盒损坏5%,主要原因,大部分用户是2009年左右的用户,使用寿命已到,造成故障.4 用户装修改线15%造成线路不通，和用户光纤的损坏造成二次熔接。5 拆迁用户的维修10%.6 其他原因占10%.三 2014年机房维护情况说明 现有机房10个,计划新增机房1个,存在的问题，分机房停电不能及时供电第一时间到现场解决故障，存在很大的安全隐患。四2015年的工作计划

1、重点解快因用电造成的故障,与小区物业部协商取得供电支持,计划在今年年初对辖区内的共用电改造工作。

2、抢修组已做到责任制到片区及时处理光纤故障，做好对用户禁止装修改线的宣传工作。

3、为了提高机房安全运行传输质量，加快建设网路机房监控设施，预计建设现有分机房11个。

4、维护人员的综合业务素质 ,加强培训,年初针对运维网络技术和公司考核管理的培训计划一周一次上半年，下半年两周一次和对新进员工的资质培训,月度考试与工资挂钩,提升运维人员的服务统一标准，5、完善安全生产制度，搞好安全生产工作。(1)每月定期对机房进行寻查、巡检工作。(2)对运维人员不定期抽检技术性工作流程。

6、加强运维人员的市场营销意识,新业务推介与提成.7、今年需建设好主干线的环路（列如：师机房至104团，104团至西山等）和网管系统，做好网络运行质量.。

8、今年运维部计划分5个大片区其中城区26个小区，用户22570户其中现有三网用户1509户，3人一辆车维护，西山、104团三网用户6211户，3个人维护，头屯河农场三网用户7421户2人维护，三平农场三网用户11360户2人维护，五一农场三网用户7090户，2人维护，抢修组4人一辆车负责5个大片区光缆用户光纤、主干光缆的维修维护，9、今年工程部改造老校区的光纤到户的同时改造维修量较大的老有线电视小区。（列如：五一农场诒心园小区一期，楼兰酒厂，光华学校等）。

10、由于公司的网路不只是传输有线电视还传输了数据业务而且用户不断增加，光缆全部是寄挂或借用在别人的管道和木杆抢修查找断点耽误时间，不能及时修复，由其晚上对运行维修带来很大困难，今年计划建设好主干线的环路（列如：师机房至104团，104团至西山等）和网管系统，做好网络运行质量。

11、积极配合工程部做好城郊主干网、本地传输网、及弱点管道和各团场分机房建设，竣工验收工作及维护等其他工作任务。

12、落实运维部的各项管理制度，明确目标管理，理顺工作流程，为了更好地为用户服务，从而提高用户满意度建立良好的天娱传媒口碑。

运维部

2015年11月8日篇二：运维部下半年工作计划 运维部下半年工作计划

为了使运维工作顺利进行，运营部下半年工作计划如下：

1、进一步推进服务器的规划部署、搭建，以及对服务器构架、网络进行优化和调整。

2、利用监控平台nagios实时监控服务器、网络设备及业务系统的运行状态、性能。根据监控和处理结果，及时记录相关信息，定期汇总运营信息。

3、优化公司网络、邮件服务器、语音系统以及解决常见的操作系统、网络和应用故障。

4、负责突发性事件的快速响应和处理，解决服务器和网络故障。

5、与开发人员配合沟通，解决运行过程中的相关问题。

6、对日常运营数据的整理分析，然后对服务器状态监测，游戏出现问题的解决。

7、配合商务及市场部做好相关工作。篇三：2009运维服务能力管理计划 2009运维服务能力管理工作计划

根据公司本的工作计划，运维部结合本部门的工作实际，及相关的it运维服务工作的改进需求，特制定本工作计划，内容共分为四部分，包括：

1、运维管理组织结构

2、运维服务流程

3、应急服务响应措施

4、服务管理制度规范。现具体阐述如下：

一、运维管理组织结构

本运维项目的运维管理结构位三层模式，具体如下图所示。由项目负责人与甲方进行业务范围接洽，并将沟通结果向下传递。项目经理负责项目的整体运维工作，包括各种制度的制定和实施。运维工程师则在项目经理的指导下开展维护工作。1．项目负责人职责：负责项目商务、整体协调事宜。职位描述： 1）、整体负责建设单位运维项目服务计划的制定，领导项目经理并安排项目工作，指导项目经理完成具体维护工作，每周听取项目经理的工作汇报，负责考核项目经理工作完成情况。2）、协助建设单位完成新增项目的调研、方案设计并指导项目经理进行具体实施。2．项目经理

职责：规划、执行、完善信息化项目的运维工作，指导网络、数据库维护工程师开展工作。职位描述：

1）根据公司战略目标，指导下属工程师开展客户服务工作，确保运维工作能够满足客户的实际需要；

2）建立和持续完善运维管理体系，优化运维流程流程，解决运维服务中出现的特殊问题； 3）规划并提升运维工程师专业服务能力，在整体上提高客户满意度； 4）制定和持续完善绩效考核体系；

5）制定整理运维项目的应急预案系统，并指导运维工程师实施；

6）提高自身专业技能，在业务方面给予网络管理员和数据库管理员指导。

3．技术主管职责：应用、数据库管理，oracle性能调优，实现应用负载均衡。职位描述： 1）技术主管非项目常驻人员，根据项目需要进行专业方面 指导；

2）负责数据库性能分析与调优，数据库运行状态监控，及 时发现异常并快速处理。

2）熟练掌握oracle10g的rac技术，能够实现部署及调优。3）掌握was、weblogic、tomcat、websphere等中间件的工 作原理，能够实现部署调优及故障解决。

4）熟练掌握red-flag、redhat等linux操作系统，部署 oracle10g、mysql数据库。熟练掌握dataguard技术，保 证oracle数据库冗灾、数据保护、故障恢复。5）负责应用负载均衡的部署和调试。

6）负责指导数据库工程师管理员开展工作。4．服务台

职责：故障电话受理，文档管理。职位描述

1)负责it业务的救助电话的受理工作；

2)故障处理的发起人，同时进行维护工程师指派，跟踪事件处理状态； 3)进行维护故障统计、用户满意度统计、工作报表输出等工作； 4)协助项目经理，进行文档整理、归类、保存等工作。5．网络管理员

职责：维护建设单位网络系统正常，解决网络相关故障。职位描述： 1)对现有服务器、局域网络及机房、配线间的日常管理维护； 2)对信息安全建设提出相关建议，确保网络的安全； 3)保证外网光纤线路正常，保证局域网运行正常； 4)对网络系统和网络设备的运行状态进行监控；

5)熟练掌握域策略设置、dhcp、dns、ftp服务器、ntfs权限设置等； 6)编写网络部分的应用处理预案并实施。

7)工作认真、细致，积极主动有条理性，具有良好的沟通能力及团队合作精神.6.应用、数据库管理员

职责：维护建设单位业务系统运行正常，解决应用和数据库故障。职位描述： 1)监测业务系统运行状况，应用、数据库性能监视及优化，作必要调整；

2)规划不同数据的生命周期，制订备份、恢复、迁移和灾备策略，根据业务的需要执行数据转换及迁移等操作；

3)保证应用和数据库系统的安全性、完整性和运行效率。4)负责数据库平台的整体架构及解决方案的制定和实施；

5)工作认真、细致，积极主动有条理性，具有良好的沟通能力及团队合作精神.7.终端管理员职责：维护建设单位桌面系统运行正常，解决终端、外设故障。职位描述: 1)各部门电脑、打印机、传真机的维护；

2)对各部门职员进行电脑相关的技术支持及培训工作； 3)精通windows xp及office的使用，能够熟练使用excel2003、excel2007及以上版本，能够制作相应教程对其他部门员工进行培训

二、运维服务流程

it运维服务管理流程涉及服务台、事件管理、问题管理、配置管理、变更管理、发布管理、服务级别管理、财务管理、能力管理、可用性管理、服务持续性管理、知识管理及供应商管理等，随着运维活动的不断深入和持续改进，其他流程可能会逐步独立并规范。

三、应急服务响应措施

运维项目组制定了详尽的应急处理预案，整个流程严谨而有序。但在服务维护过程中，意外情况将难以完全避免。我们将对项目实施的突发风险进行详细分析，并且针对各类突发事件，设计了相应的预防与解决措施，同时提供了完整的应急处理流程。1.应急预案实施基本流程