1.1先停掉坏的osd,以及一个好的osd(因为ceph-objectstore-tool执行时需要停止osd),然后执行导出导入即可
命令例子：其中84是好的osd,85是有问题的osd
ceph-objectstore-tool --op get-osdmap --epoch 145039 --data-path /data1/ceph-osd/ --journal-path /var/log/ceph/ceph-84/journal --type filestore --file osdmap145039
ceph-objectstore-tool --op set-osdmap --epoch 145039 --data-path /data2/ceph-osd/ --journal-path /var/log/ceph/ceph-85/journal --type filestore --file osdmap145039
PS：其中145039为对应的版本号，data-path与journal-path填写自己osd对应的路径
2、找到正确的epoch版本
这个要通过报错的osd日志查看，在启动的时候，osd会加载一个epoch版本A，这个版本是它正在执行的，缺少的epoch版本在它之前。然后在 dump of recent events中发现已经执行的epoch版本B,以及ecoch版本C。将在max(B,C)到A之间的版本都导入一遍（也可以导入一个版本，启动一次观察，就是太麻烦了）。我日志中A=145068,B=145011，C=145012,所以我把145013到145067之间所有的ecoph版本都导入进去了，结果正常启动了。我的日志入下图
1、产生原因 ：
2个osd之间的osdmap版本如果相差过大(相差可能在50左右)，会导致2个osd通讯的时候报wrong node。如果偶尔出现一次wrong node，那么问题不大，因为osd某个操作卡主了，然后恢复获取了最新版本的osdmap。如果osd日志一直在报，说明有osd同步osdmap出现问题，会导致osd down掉，心跳超时（可能），甚至出现osd大量吃内存，导致服务器挂掉。日志如下：
2、查看osd的osdmap版本
通过命令查看：ceph daemon osd.xx status ——xx标记对应的osd编号
命令结果例子：
{
"cluster_fsid": "df181181-2154-4816-a2b7-d6eae79980fb",
"osd_fsid": "d5edacd3-cee7-45eb-90df-e381d8684dfb",
"whoami": 15,
"state": "active",
"oldest_map": 92570,
"newest_map": 158146,
"num_pgs": 2105
}
其中newest_map表示osd的最新版本号
3、查看集群的osdmap版本号
命令：ceph -s
这里：178170时最新版本号
4、确定osd版本是否有问题
多次间隔执行命令ceph daemon osd.xx status 查看osd版本号，正确状态如下：
4.1、查询出来的版本号一直保持跟集群版本号一致
4.2、小于集群版本号，但是在不停增大，最终会达到集群版本号
5、出现osd不更新osdmap解决办法
到目前为止，我没有找到osd不更新osdmap的根本原因，我使用过ceph daemon osd.xx dump_blocked_ops 查看是否有阻塞的操作并解决阻塞，但是依然不行，即使返回没有阻塞，还是不更新。可能可以让osd重新更新的方式：
1、将对应的osd out出集群（osd还是up的），过一阵观察一下版本号（我的就是这样回复的）
2、重启osd
1、问题日志
2、解决方式：
1、检查服务器时间是否一致
2、检查集群中的keyring与本地osd的keyring是否一致:
使用命令：
ceph auth list从mon中获取所有osd的keyring,
cat /var/lib/ceph/osd/ceph-xx/keyring获取本地osd的keyring
3、去掉验证 ，重启所有的mon、osd，修改ceph.conf中的如下参数为
auth_cluster_required = none
auth_service_required = none
auth_client_required = none
1、问题日志
2、解决方式
1、查看服务器时间与服务器网络（我的不是这个问题）
2、一般心跳超时是其他问题引起的，这里可以先调大心跳超时时间（我调大了心跳超时，解决了其他问题之后，就没有心跳超时了），修改配合文件ceph.conf的参数
mon_osd_report_timeout = 1800
filestore_op_thread_suicide_timeout = 1800
filestore_op_thread_timeout = 600
osd_heartbeat_grace = 600
osd_op_thread_suicide_timeout=1800
osd_op_thread_timeout=36000
这个配置可以先放到[global]，等解决了问题，在去掉，也可以根据实际情况，自己调整参数
1.查看日志查看osd卡在哪里
日志调整级别：修改配置文件ceph.conf参数，添加debug_osd=10（15/20），数值越高，打印越多。如果已经启动osd,想更改日志级别，可以通过命令：ceph tell osd.xx injectargs --debug-osd 5
2、根据日志信息解决问题
我是卡在了load_pgs上，因为整个集群状态不对，而pg数量又很多，加载很慢，这时候需要考虑服务器压力，可以一个一个慢慢启动，不要一下子启动完。
1、问题原因
incomplete状态表示：Peering过程中由于无法选出权威日志或者通过choos_acting选出的acting不足以完成数据恢复，（例如针对纠删码，存活的副本数小于k值）等，导致Peering无法正常完成。即pg元数据丢失，无法恢复pg状态
2、解决问题
1、使用ceph-objectstore-tool工具将incomplete状态的pg标记为complete
2、操作步骤：
操作前提：设置集群flag:noout nodown noup noin PS：这里的目的是为了不让pg分布变化，我因为osd都起来了，只设置了noout nodown
第一步：通过命令ceph pg dump_stuck |grepincomplete >incomplete.txt 从集群中导出incomplete状态的所有pg
第二步：通过第一步知道了pg所在的2个osd在哪里，stop这2个osd
第三步：对这2个osd上的pg通过命令做标记，命令如下
ceph-objectstore-tool --data-path /data4/ceph-osd/ --journal-path /var/log/ceph/ceph-15/journal --type filestore --pgid 9.ea8 --op mark-complete
ceph-objectstore-tool --data-path /data8/ceph-osd/ --journal-path /var/log/ceph/ceph-91/journal --type filestore --pgid 9.ea8 --op mark-complete
第四步：启动这2个osd(启动顺序没有关系)
第五步：观察集群中incomplete是否少了
第六步：重复第二步以及之后的操作，直到incomplete没有
3、特别说明
3.1、标记complete的过程，可能给导致集群degraded、misplaced增加，这是正常的
3.2、原因：因为我在标记的过程中，缺少了导入导出pg步骤。我这里没操作导入导出是因为pg数量有点多，而且pg比较大，导入导出会让2个osd停太久了，而且我觉得让集群自己恢复比较好
3.3、导入导出pg命令:
ceph-objectstore-tool --data-path /data3/ceph-osd/ --journal-path /var/log/ceph/ceph-2/journal --type filestore --pgid 4.15d5 --op export --file /data10/55/pg4.15d5
ceph-objectstore-tool --data-path /data8/ceph-osd/ --journal-path /var/log/ceph/ceph-5/journal --type filestore --pgid 4.15d5--op import --file /data10/55/pg4.15d5
选择一个osd为主，另一个为副，将一个导入到另外一个pg，导入导出需要停止osd。以上是将osd.2中的4.15d5导入到osd.5中
1、如果能重启对应pg的osd,那是最好的，问题自然解决
2、如果osd对应的数据盘损毁或者其他原因无法启动这个osd
第一步：将这个osd删除，命令
ceph osd crush reweight osd.xx 0
ceph osd out osd.xx
ceph osd crush remove osd.xx
ceph osd rm osd.xx
ceph auth del osd.xx
第二步：清理当前osd的硬盘或者新加一个硬盘
第三步：新启动一个编号相同的osd
第四部：重复上面的操作，处理掉所有有问题的osd，如果还有down，没事，等集群自己恢复处理（我就是启动了一个新的osd,有pg处理incomlepte+down，我标记完了incomlepte，down就自己消失了）
1、原因
这个状态的PG没有被 ceph-osd 更新，表明存储这个 PG 的所有节点可能都 down 了。拥有 PG 拷贝的 OSD 可能会全部失败，这种情况下，那一部分的对象存储不可用， monitor 也就不会收到那些 PG 的状态更新了，这些pg就被标记为stale
2、解决方法
第一种：osd down了之后能正常起来，那只要启动
第二种：
1.使用命令ceph pg dump |grep stale找出stale的pg
2.使用命令ceph pg force_create_pg $pg_id,这时pg状态变为creating
3.重启集群中所有的osd
3、特殊说明
我当时是第二种情况，然后我按上面的步骤操作了。结果所有的osd启动都卡主了。我猜测可能原因：当时我force_create_pg的数量有3000个，这个数量有点多，所以osd就大量卡住了，很久很久才能启动，可能有几个小时。所以这个操作要慎重，建议如下
1、这个stale的pg最后处理
2、一次不要force_create_pg太多，osd重启时，一个重启成功之后，在重启另一个
这个比较简单,直接执行命令：ceph pg repair $pg_id 修复
说明集群中osd有问题，需要解决osd问题，我就是有3个osd问题，我out了这3个osd，这2个状态就很快消失了
1、问题发现 ：ceph -s 或者mon进程死掉看到日志
2、产生原因
产生了大量的epoch，导致mon的store.db的数据极速膨胀。这个是我集群出现问题之后才出现的。我之前集群正常时没有这个现象。不知道等集群正常之后，会不会自己恢复正常。
3、解决方法
第一种：对数据进行压缩，使用命令 ceph tell mon.ceph163 compact (ceph163是我mon的名称) 。
第二种：使用ceph-mon -i HOST --compact进行压缩启动 ，这里的host我使用的是ceph163，主机名称
说明：不管使用哪一种，都要注意一点：操作压缩时，硬盘都会先扩大然后再缩小的，所以要留足空间。第二种的优势在于可以使修改ceph.conf中的参数mon_data=/data10/ceph153路径生效。我后来的mon数据太大了，我就更新路径到了数据盘：只要把对应的mon数据存数据mv到其他目录即可
第三种：等集群正常了，修改mon的配置参数试试（未验证，参数可以调小一些）
mon_min_osdmap_epochs=500
mon_max_pgmap_epochs=500
mon_max_mdsmap_epochs=500
4、特别注意：
默认当mon所在存储应硬盘剩余5%空闲时，mon进程会自杀。
将对应osd节点设置为out即可(osd进程依然存在)，它会自动移除数据并把对应数据盘的数据删除，等到数据移除完毕，正常关闭删除osd即可
命令：ceph osd out osd.xx
当需要迁移服务器，需要关闭集群时，先设置ceph osd set nodown ceph osd set noup ceph osd set noout ceph osd set nobackfill ceph osd set norecover 保持集群不变，然后关闭各个osd,关闭mon,关闭rgw。
ceph osd set norebalance
——禁止集群pg做从均衡，当出现问题时，可以设置，用于排查问题
ceph osd set nobackfill
——禁止修复数据 backfill，当出现问题时,我们暂时不想修复数据，可以使用，配合nobackfill 一起使用
ceph osd set norecover
——禁止修复数据 recover，当出现问题时,我们暂时不想修复数据，可以使用，配合nobackfill 一起使用
ceph osd set nodown
——当集群出现问题，osd一会儿up，一个down的时候，可以使用这个命令，禁止osd down
ceph osd set noup
——当集群出现问题，osd一会儿up，一个down的时候，可以使用这个命令，禁止osd up
ceph osd set noout
——禁止集群中的osd自动因为长时间down，而out
ceph osd set nodeeep-scrub
——不做深度处理取消使用对应的unset即可，比如ceph osd unset noout
ceph osd out osd.xx 设置单个osd的状态为out
ceph osd in osd.xx 设置单个osd的状态为in
ceph osd down osd.xx 设置单个osd的状态为down
ceph tell osd.xx injectargs --debug-osd 20 实时修改osd.xx的日志级别，不需要重启osd
ceph tell mon.xx injectargs --debug-mon 20 实时修改mon的日志级别，不需要重启mon
ceph tell osd.* injectargs --osd_recovery_sleep 1 单位秒，刚开始设置为1，怕服务器有压力，观察之后可以去掉设置为0
ceph tell osd.* injectargs --osd_max_backfills 1 调整恢复线程数，可以根据实际情况调整
ceph tell osd.* injectargs --osd_recovery_op_priority 60 调整恢复线程的级别
ceph daemon osd.xx status 查看osd.xx的状态，主要看osdmap版本号
ceph pg dump 查看所有的pg信息
ceph pg dump_stuck stale 查看pg状态为stale的数据
ceph pg dump_stuck inactive查看pg状态为inactive的数据
ceph pg dump_stuck unclean查看pg状态为unclean的数据
ceph -s 查看集群情况
ceph osd tree 查看osd状态树
ceph health detail 查看集群健康详情
ceph pg pg_id query 查看某个pg信息
ceph osd getmap -o osdmap.bin查看osdmap图
ceph-dencoder type OSDMap import osdmap_197 decode dump_json 将osdmap导出成json格式
运维工作总结(一)20xx年运维部工作总结
20xx年业已尾声，我部门在公司的正确领导下，认真执行公司制定的各项制度及部门制度，努力改进工作中存在的不足，并取得了一定进步，2011年我部门总体工作特点是：运维任务基本饱和且多个项目同时进行，工作分散、繁琐，现就部门的各项工作进行一下简要总结。
Ⅰ.一年工作概况
1、上半年运维任务相对轻松，根据公司和部门要求集中进行内部优化，以及对以前工作进行总结，各负责人在现有条件基础上，统筹安排，有条不紊的完成公司规定的任务指标，没有因运维任务繁多而出现混乱。
2、下半年各主要项目陆续接手，同时部门内部各人员职责基本清晰，各负其责，整个部门运行基本踏入正轨，方案、合同、资料、服务流程运行良好，同时现场服务人员能认真负责的执行公司及部门的各项规定，掌握、收集、记录现场第一手资料，完成公司交办的各项任务。
3、本年度中部门与部门间、员工与员工间，都在工作中不断的磨合，发现问题、解决问题，各项工作并没有因此而停滞不前，经过一年时间的不断改进，对内公司各项工作渐渐运转自如，对外也赢得了相关客户的认可，一切正朝着令人欣喜的方向前进。
4、本年度人员安排如下：
5、本年度服务数据如下：
6、本年度部门收费回款如下：
7、运维和参与项目实施情况
一.全年部门完成运维任务：
①.解决招行成都分行监控中心大屏和两河公园停车场故障与项目尾款回款两个难题；
②.完成招行密押系统升级更新和其他系统运维任务；
③.完成安县交通卡口及金牛公安分局等其他客户监控系统运维任务；
二.全年部门完成参与项目实施任务：金牛公安分局视频资源管理系统
Ⅱ.但是总结本年度的工作，还有一些问题存在，有些工作亟待改进：
一、 备件管理
1、备件管理在2011年做得并不好，由于项目运维还处于成熟过程中，对运维备件要求未按照实际使用作计划，导致在运维过程中，无法对备件进行有效控制，在今后工作中要着重加强管理调度，坚持每月执行备件计划制度。针对备件需求和备件使用制定相应的领用制度，做到“谁提备件，谁负责”， 坚持限额领用制度。
2、加强备件现场使用的管理力度，对送达现场的备件，及时准确地进行核实，发现问题及时上报，对备件使用量大的、有特殊要求的须经过部门负责人或分管领导审核同意。
二、服务流程管理
1、服务流程是否合理决定服务的效率，在保证质量和安全的前提下，尽可能地提高服务及时性。原则：对同时发生的运维任务，合理调配人力、物力资源，统筹安排，因地制宜，在尽可能短的时间内完成更多的工作，做到人员效应最大化。优化运维方案，通过集体讨论，优先采用能够保证服务质量要求，方案可行而成本支出较小的运维方案，目的是成本控制，同时加强现场管理，合理调配有限资源，减少浪费。
2、现场服务人员和主管负责人、后勤人员要勤于沟通，有变化及时通报，做到信息畅通，避免因沟通不及时而出现重复派工、二次报修等问题。
3、进一步明确人员责任制，人负其责，公平合理，避免互相推诿、调度重复现象，提高人员意识。
4、进一步细化完善部门制度，规范人员工作流程、落实资料单据填写与收集整理、管理。
三、人员培训
1、技能培训：公司目前项目主要分环保、交通卡口和安防系统3大块，而运维部人员对所有项目的都还未做到详细熟悉细致了解和掌握的程度。
2、制度意识培训：运维部人员平时处理故障的情况较为繁重，在一定程度上对制度或资料填写有疏忽的现象，对资料收集整理保存以及查询带来了不便。
3、部门只做到了制度化和形式化，落实与实施的程度还不够。 Ⅲ.对公司制度和管理制度的建议
Ⅲ针对我们在维护过程中遇到的问题，我作出如下几点建议：
1、对公司的产品：现今我司自主产品基本没有，尤其是新项目，产品处于测试阶段，但这些产品已经在客户那里开始使用，所以出现问题较多，工程师都是一边学习一边维护。避免不了在客户面前向公司有关方咨询处理问题的方法，给客户留下了不好的印象；其次，是老产品的更新升级，设备运行也不稳定，造成维护量巨大，处理一个问题又出现新的问题。希望公司12在这方面得到改进。
2、配件管理：公司在配件备货方面存在较大问题，主要为相关配件公司没有配件库存，有的设备还需供应商提供；如：读卡器，摄像机等，这极大影响了服务效率，12此问题应首要解决。
3、服务流程及工作量：服务流程没有什么问题，主要是协调沟通机制还未建立起来，导致工程师不能与客户及时了解情况以及管理人员
不能了解实时状态。造成不必要的催促和二次报修。另外由于有些片区条件特殊，如其他县市区，由于离公司较远一个较为简单的任务需要派人去现场，这样就造成了一定的资源浪费和增大了服务成本，希望公司在新的一年有所考虑和改进。
4、人员培训：公司应加强人员在工作技能和公关技能方面的培训，提高人员意识和安全性、纪律性；部门拟定在12年对部门人员进行1月1次技能或理论培训，实时进行现场实际操作培训；另外部门决定在新年里对部门员工进行职称培训，力争在12年部门有1~2名项目经理，2名以上安防技术专业工程师。
Ⅳ.来年工作计划
1、人员划分：
2、制度流程：
进一步细化规范部门制度和流程，最大程度优化服务结构，监督人员落实和实施，做好资料收集整理、备品备件管理。
3、系统数据
明年公司将上业务支撑管理系统，部门将根据系统数据做详细的
运维工作总结(二)
It运维服务工作总结
至20xx年10月底，0000000000000000000有限公司在0000000000000000公司的运维又届满一年的时间了。在这为期一年的运维工作当中，xxxx的业务飞速发展，设备数量不断增加，人员的技术水平和业务知识有了显著的提升。我们的队伍在技术水平和管理经验上也有了本质的提高。
一、 细致缜密的完成计划中的日常运维工作：
严把质量；服务至上；严格要求；技术领先。
1. 承接运维工作初始信息技术部的各位领导就对我们的运维工作给予厚望，并提出了认真完善服务水平的方针。我们在服务过程中严格按照这一要求，以对保障xxxx的发展，对用户负责的精神，把“严把质量，服务至上”的原则贯穿于日常工作的各个环节之中。使本运维期过程中的客户满意度有了非常显著的提高，多次获得了用户的认可。
2. 对于在工作中信息技术部提出的新要求、新方案，我们及时相应配合，本着“严格要求”的原则，对于提出的要求科学性的分析研究，及时提出完整周密的解决方案，并拟请用户试行或测试后实施。有力的保障了运维工作的及时有效性。
3. 对于提高服务业务技术水平上，按照信息技术部的统一规划，按时完成一系列的既定培训计划。按照“技术领先”的原则，通过技术上的培训提高了业务水平和解决故障的效率；通过制定有效的安全
机制和培训，健全了xxxx信息外包人员安全机制；通过保密制度的培训使运维人员能够树立自觉维护xxxx的`信息安全防范意识；通过客户服务意识的培训提高了客户的满意度。
二、 吸收先进经验，保质保量的完成运维的各项任务：
运维期内主机、服务器、网络和桌面均没有发生严重的生产安全事故，对于一些潜在的威胁也都在得到信息技术部门的批示下，审慎周密的完成了整改工作。运用先进的技术和经验提高劳动效率和运维工作质量：
1.运用先进的运维工具提高劳动效率。通过监控软件随时保持信息的及时性、可控性，一旦发生问题可以迅速定位和修复。
2.经过信息技术部指导，我们在运维工作中大量了采用WEB2.0技术。使我们在高效完成运维工作的情况下，为xxxx节约了大量的费用投入。
3.在工作的过程中注意新技术和新方法的学习和收集，对于有利于运维工作的成功方案及时整理并提交信息技术部。经过5年来的维护工作存储了大量的知识库信息。
三、 适应任务需要，及时解决运维过程中的遇到的问题：
1. 在运维过程中遇到突发问题及时与信息技术部门相关人员进行沟通，对于紧急情况的处理按照《应急预案》进行对应处理。在节假日安排主要人员进行值班和备勤，保障24小时均能及时相应。
2. 在运维工作过程中，积极协助新增设备的各项实施工作，获得了信息技术部的肯定；在到货、验收、集成方案和安装调试过程中提供全程保障；对于数据的迁移、备份，各人按照自己的职责，在制定详尽的计划后、经过信息技术部的批准严格按照方案实施；
3. 在配合一些公司的重大活动、事件时，为应对信息技术部人员不足的情况。我们一方面做好运维工作的情况下，另一方面派出部分或全部人员协助信息技术部的各项工作，以弥补其人力不足的状况；
4. 对于机房的升级改造过程中积极配合，全程派员监理施工过程，及时出具各种施工方案和设计资料。施工完成后及时
运维工作总结 运维工作总结(三)2013年运维工作总结
回顾过去的一年，在市县公司工区领导指导下取得的一些成绩，但也有一些不足。现就运行工作总结如下：
一、努力学习新知识，掌握新设备，提高业务技能。
我所工作的单位是一所建设刚2年的变电站，有着配套齐全的办公设施和生活用具，有着慕煞旁人的生活和学习的条件。自从2011年4月进入110kV变电站工作以来，在市县工区领导关怀指导下努力改变以往工作模式与方法。从一个干好自己工作为己任，无关他人的自我态度，通过不断的学习和锻炼，逐步转变为互相帮助，共同完成与提高的协同办公新模式。记得建站投运之始，依然是每天跟班日出而作，日落而栖学习设备的理论和操作方法。终是初步接触110千伏变电站设备，在市工区领导平时工作担心忧郁的语气中，我常感无形的工作压力，正吞噬着我而这，也正深深的激励着我，更加以自觉学习业务知识。
直到去年的某天，在一派新设备无故障的思想中，几乎把尚存脑海的业务知识遗忘殆尽的时，突然接到地调110kV624线路配合停电检修的操作指令，在市工区领导仍然有些担心的口吻中，我以正确的事故处理方法及操作步骤面对，在默认处理措施后，在长长的电话线那边，似乎看见领导在稍稍放松的神情里，正用赞许的眼光望着我。。。
二、立足本岗位，发挥党员模范带头作用。
作为变电站一名基层党员，爱岗敬业、忠贞不渝，在保持党的纯洁性工作和意识形态中，唯有加强变电站平时安全运行意识的养成和既定制度管理的落实，服务好人民群众，促进变电运维工作的全面发展，才是爱党、爱国家、爱公司应有的体现。我在过去的一年中主动学习党的方针政策，加强党性修养，进一步提高自己的政治觉悟和工作能力，在尽职履责中发挥模范带头作用。在公司基层变电站里营造和谐工作氛围，勇于担当，充分体现党员的优秀价值。
新形势下，多年的基层变电站工作，让我深深的知道迎峰度夏的工作中，公司和电网发展所面临的任务。我从本职岗位挑战出发，时时处处以身作则，用实际行动充分体现党员的执行力和实践力。在过去一年的围绕迎峰度夏保供电工作中，我明确时段、地段、人员和工作要求，落实测温、特巡等工作，包括设备过热、线路弧垂下降等原因引起的跳闸，全面开展变电设备状态巡视和检测工作。切实防止变电设备巡视维护不到位而引发的设备事件发生，通过努力，“迎峰度夏”保供电工作在两级工区领导大力指导下，取得了圆满成绩和效果。
三、继往开来，把一腔工作热情付诸于无限的为人民服务中去。
作为电力工作者，我们任何时候都应以党和企业的事业为重任何时候都应践行“诚信、责任、创新、奉献”的核心价值观，高标准履行国家电网人的职责。在今年政治性用电“国庆”、“十八大”保电工作中，严格遵循各项规章制度，严防死守，密切配合电力调度，有力的保障了当地人民群众广播电视的正常收听，收看。我来自于基层变电站一名普通的职工，任何时候都应服从整体利益，恪尽职守，在以后的本岗位上，我也将一如既往扎实干好自身工作，干净干事，发挥党员模范带头作用，努力为当地经济的发展值好班、站好岗，向组织交上一份“组织放心，群众满意”的答卷。
运维工作总结(四)
**公司系统运维工程师年终个人工作总结及下年工作计划
时间一晃而过，弹指之间，2010年悄然而至，自从2010年3月份刚进入公司，我是第一次接触公司、接触通信行业、接触公司网络管理及维护。虽然跟我的专业和技能都一致，但所有的实际经验都是第一次，让我没有任何准备，同样也打消了任何顾虑，人生就是这样，所有的一切都是要从第一次开始，没有接触过、干过并不可怕，领导给了我机会，让我有了一次尝试、一次展现自己的平台，那么我一定会更加倍的努力做好工作才是最大的回报。并且也是对自己的一次肯定。经过一段时间的工作及陌生环境的磨合，专心钻研业务知识，努力提高理论知识和业务工作水平。遵纪守法，踏实工作认真完成领导交办的各项工作任务，使自己渐渐的融入和适应到新的工作环境中。过去的大半年里在领导和同事们的悉心关怀和支持帮助下,通过自身的不懈努力，在思想、学习和工作等方面取得了新的进步。现总结如下:
一、公司电脑日常维护工作
刚一开始接手工作的时候，发现公司大部分工作电脑都没有安装安全防护软件和升级系统补丁；员工随意安装系统及应用软件，致使公司局域网内病毒隐患严重、工作不稳定和系统崩溃，工作秩序被打乱，员工不严格要求自己，上班时间聊QQ、玩农场、看娱乐网站等；为此公司和个人工作经常受到影响,工作效率降低。针对这种情况，我采取了以下措施：
1、先对公司员工进行一次基本知识培训，让员工了解到计算机的正确使用方法，病毒防范，重要文件的备份等。从而大大提高了员工对电脑使用的熟练程度。
2、先恢复良好的秩序。电脑使用时如发现故障和需更改设置，必须先报告公司运维人员，由专门人员来进行专业及针对化的操作，个人不能私自进行改动，进行这样做的目的避免由于人为的盲目操作使某一台电脑的故障影响整个局域网内的其它工作，使故障扩大化，并延长了解决问题的周期。
3、使员工使用统一的、经过安全测试的系统及应用软件，安装、设置统一的杀毒软件、防火墙等安全防护软件，且经过努力实践，并在每台机器上设定了自动系统补丁升级及定期查杀规则。
4、对于个人的关键性数据资料、邮件进行路径转移备份，使这些数据远离危险故障点，避免意外丢失所带来的严重后果。操作系统进行常规定期备份，便于事后的还
原。
5、对于网络管理进行了监管工作，公司所有电脑安装了行为管理软件后，员工工作效率逐步提高，自觉性得到明显改进，从而净化了公司网络办公环境。
经过一段时间的贯彻和工作，先前的混乱现象得到有效控制，现公司的十余台电脑，工作状态稳定，没有出现大面积的系统崩溃和故障。
二、网络的日常维护
路由器及交换机的维护管理，确保公司网络运行正常，员工正常利用网络资源。加强路由器的规则设置，优化外网接口，内部员工合理地分配带宽流量，使公司的网络能稳定有效地工作。
三、公司网络制度管理和完善
公司经过一段时间的运转，各个部门的规章制度通过大家一起研究、探讨、立会并完善制定了各项规章制度，计算机管理也形成了制度，大家按章办事，使之成为一种工作习惯。同时公司的资产管理及日常的文书表格非常混乱和环节上的缺失。为此特地制作了一批表格、登记申请单及统计表。使得公司资产和资源得到有效的管理和控制，杜绝管理上的失控和资产流失。
四、公司服务器平台管理与维护工作
公司发展逐步扩大，对于公司所有的业务支撑平台-服务器，为重中之重；本年度我司服务器相应出现几次重大故障，分别如下：
1、网络故障七次，重大一次，因服务器遭DDOS攻击，导致我司服务器无法正常工作。事后通过紧急处理后得以恢复正常。其它几次分别为机房断电、网络升级、电信与联通DNS解析故障影响到我司服务器平台网络连接不正常。
2、系统故障三次，其中一次为短信平台服务器系统文件损坏，导致系统崩溃。经过技术部采用紧急预案措施在两小时内得以恢复系统。
3、其它故障共计5次，因联通网关溢出，无法与我司IVR服务器数
运维工作总结 运维工作总结(五)运维服务工作总结
至2014年底，银海科技有限公司在蓝湾科技有限公司的运维又届满一年的时间了。在这为期一年的运维工作当中，运维的业务飞速发展，设备数量不断增加，人员的技术水平和业务知识有了显著的提升。我们的队伍在技术水平上也有了本质的提高。
一、 细致缜密的完成计划中的日常运维工作： 严把质量；服务至上；严格要求；技术领先。
1.各位领导就对我们的运维工作给予厚望，我们提出认真完善服务水平的方针。我们在服务过程中严格按照这一要求，以对保障用户的权益，对用户负责的精神，把“严把质量，服务至上”的原则贯穿于日常工作的各个环节之中。使本运维期过程中的客户满意度有了非常显著的提高，多次获得了用户的认可。
2. 对于在工作中我们树立新要求、新方案，本着“严格要求”的原则，对于提出的要求科学性的分析研究，及时提出完整周密的解决方案。有力的保障了运维工作的及时有效性。
二、 吸收先进经验，保质保量的完成运维的各项任务：
运维期内主机、服务器、网络和桌面均没有发生严重的生产安全事故，对于一些潜在的威胁也都在得到信息技术部门的批示下，审慎周密的完成了整改工作。运用先进的技术和经验提高劳动效率和运维工作质量： 1.运用先进的运维工具提高劳动效率。一旦发生问题可以迅速定位和
修复。
2.在工作的过程中注意新技术和新方法的学习和收集，对于有利于运维工作的成功方案及时整理并提交信息数据部。
三、 认真完成运维工作中的汇报、总结每个故障点率和分析原因： 自2014-5-27，截止2014-12-31根据工作记录汇报共完成1263个报修，平均每天8.2个报修（其中不包括潜在故障点），服务项目有：安装，维修，培训，会议保障，综合布线，巡检等。服务分类有PC硬件，办公软件，网络连接，网络设备，打印机，电话传真，健康巡检等。 以下是图标分析：
1.其中PC硬件服务分类如下
分类 服务数
KVM 8
黑屏 26
蓝屏 13
装机 13
其他 61
2.办公软件服务分类如下：
分类项目 服务数量
office 47 IE 14 金宏 106 系统 101 其他 64
3.打印机服务分类如下：
4.电话传真服务分类如下：
5.网络连接服务分类如下：
6.网络设备服务一共20个！
以上数据均不包括潜在故障
四：总结工作
2014年已经过去，在自己的工作中还有很多的不足，还不能让客户达到百分百满意，对客户的服务也没有完善，对此问题我总结了一下原因，客户投诉最多的是响应时间慢，桌面维护这个工作工作量非常的不稳定，有时候工作量少，很清闲，有时候一天近30个服务，这是不受控制因素。而且还有潜在故障点，导致响应时间慢，从数据上显示2014.05.27到2014.12.31日一共有77个综合布线，平均一周两次工程布线，而布线最起码需要一个人员，而服务人员一共2人，另外一个人就有些力不从心了。每个人总会有些事情，需要请假，这些原因都导致了响应时间慢，还有一些是技术方面的原因，有时候我没
运维工作总结(六)
运维部上半年工作总结
半年来，我部门在公司领导的关心、帮助和大力支持下，扎实有效的开展各项工作，圆满完成了上级下达的各项维护考核指标。
一． 运营维护部全体同志充分发扬不怕苦不怕累，克服困难
连续作战的精神，工作中通力合作有力的保证了杆路、信号的正常传输。
二． 城网日常维护。半年无节假日累计加班72天。值班365
小时值宿180人次。处理用户终端故障4000余件，处理突发性和特大故障20件。其中光缆故障15件。
三． 线路整改。改架干线1000米。更换-5电缆3000米。
更换-9电线2000米。更换光接机7台、供电器5台放大器28台、分支分配器300个。城网光缆改造楼房1个小区。100户。有效地提高了了用户收视指标。共架光缆0.5公里。新增光节点1个。
四． 光缆维护队半年维护光缆故障200余件。共计熔接光纤
2300余芯。统一规划完成光缆改造10余公里。整理乡
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）