IT运维工作心得总结

第一篇：IT运维工作心得总结

运维工作心得总结

运维工作直接关系到应用系统运行的正常稳定，但运维工作纷繁复杂，正规化、系统化相对比较弱，如何改变这种现状？从众多的运维工作者的成功失败中进行经验总结，并提升为运维规则，是提高运维水平，保障应用系统正常稳定运行的有效途径。

笔者通过自己的多年运维经验，总结出以下必须遵守的基本运维规则，可以大大减少缺乏经验的运维人员因为自身失误导致系统出故障的可能性。

一、系统变更、升级应先在同样的环境测试通过，执行前应有经过验证的回退预案

运维是一门经验的学科、是一门试错的学科。没有做过的东西、总是会给你出意想不到的难题，因此变更前，一定要在相同或者相似运行环境下进行测试，通过后才能在正式环境下执行变更。同时应准备好变更失败的回退预案，比如，做好系统备份、数据库备份、配置备份，固化变更前的运行现场，让变更有回头的机会。

二、对破坏性的操作要先确认符合预定方案，然后谨慎执行

什么是破坏性的操作？ 比如：

对MSSQLServer，执行update操作，因为不需要commit，所以特别容易忽视也特别危险，还有delete、drop等操作更不用说。

对 Oracle 而言：truncate table_name、delete table_name、drop table_name，这些语句执行起来轻松简单也惬意极了、但记住！即便数据可被回滚、代价也是非常大！

对 Linux 而言，rm-r 所有当前及其子目录的所有数据都将被删除。经历过这种故障的人、大多会给 rm 上个别名 A liasrm='rm-i' 同理、cp 和 mv 也可以有同样的选项：

aliascp='cp-i' alias mv='mv-i' 对window而言，shift+del文件或者目录 对任何系统而言，无备份直接修改文件等

三、备份并验证备份的有效性

不管是硬件还是软件总有意外崩溃的时候，怎么办？备份！！备份的学问很大、按照不同的维度可以分：冷备和热备、实时和非实时、物理和逻辑、全备增量备。

备份有了、可以高忱无忧了吗？不行！尚须验证备份的有效性。一个总有那么几次、备份无法保证 100% 恢复，简单的验证就是找个空库恢复出来。

四、对生产环境永保敬畏之心

这是避免应用系统发生故障的一条铁规，也是被开发、运维人员容易忽视的地方。要坚决杜绝直接在生产环境做开发、测试和bug修复，这些操作只能在开发和测试环境做，否则一旦出事，将欲哭无泪。

五、交接和休假最容易出故障

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

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

 在别人放假的时候接手工作，“能拖则拖”，实在需要执行：必须不厌其烦的跟原系统管理人员确认各个操作细节。 六、一定要有监控手段和报警措施

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

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

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

报警和监控是衣宽带水的好兄弟、相铺相成、互相促进。

七、使用自动切换技术需谨慎

为了保障数据库安全，往往会使用HA或者RAC之类的技术，但是这类技术能否真正在关键时刻起作用，则是需要经过反复验证和确认的。并不是按照文档要求做好了就够的，很多意外因素或者系统因素会导致自动切换技术并不能如期发挥作用。如果到事后才发现这一点，将悔之晚矣。

八、要有偏执狂的精神，方案要检查，检查，再检查

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

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

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

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

⑥ 执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本 ⑦ 最后才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出

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

九、简单即是美

我们总是面临各种诱惑：新的系统架构，新的更智能的命令和工具，最新的硬件平台，功能更全的HA软件...你可以在线下安装，测试，怎么做都行。但是如果想要在生产环境下使用起来、请三思！

能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了  脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做  Linux本身自带的字符界面比那些复杂的图形界面要简洁方便 

如果能做到坚持这九条铁规，你的应用系统就能长久稳定运行了。

第二篇：IT运维心得分享范文

360公司运维心得分享

在很多“外人”的眼中，运维工程师的工作不过是搬机器、调网络、装软件、处理故障、7×24小时值班，简单而又枯燥至极。但事实并非如此，运维工作涵盖很多技术领域，运维工程师要掌握硬件、软件、操作系统、开发等多方面的知识，核心目标是为亿万用户使用的产品保驾护航。

当今互联网行业的发展日新月异，新技术层出不穷。为了适应发展趋势，运维工程师只有提升技术能力才能更好地完成艰巨的运维任务，必须要对传统运维发出自我挑战。

在360，运维团队由基础运维团队、网络运维团队和应用运维团队三部分组成。我们将运维从技术支持领域升级，进行产品化改进，核心目标是为了降低运维成本、缩短研发周期、让产品试错更廉价。理想很丰满，现实很骨感，从最初服务少量项目、几十台服务器，发展到大量具有数亿用户的项目，我们也在不断摸索，在试错中成长。在这个过程中，我们经历了两次重要的升级。第一次升级：运维工具化

运维工作中有很多琐碎的、重复的事情，初期我们只有两个IDC，服务器数量有限，项目数量也较少，靠纯手工劳作还可以应付。但随着时间的推移，项目暴增，随之IDC和服务器的数量也成倍增长，同时360各项目都是小团队在做，开发风格不同、习惯各异，但极致要求响应速度，如果运维工作按照之前方式进行，很难满足需求。大势所趋，我们必须进行工具化升级，将重复的事情自动化。

在工具化过程中，我们秉着低成本、拿来即用的原则，借鉴业界成型的方案，同时将精力用在对开源软件的研究中，有开源工具就绝不自己凭空创造。初期，我们只围绕开源软件做周边脚本开发，不动核心代码，在实践中总结经验。例如，在最基础的部署软件环境中，我们基于YUM搭建了自己的包管理系统，将常用软件打包，同时根据项目做成模板，这样无论是初始安装还是扩容都能在分分钟完成。配置文件管理利用Puppet完成，服务器批量操控依赖SaltStack。就这样 我们的运维兵器谱在不断地丰富。

另外，运维工作离不开监控报警，这是一件让无数运维人苦不堪言的事情。而会休息才会工作，监控体系必须优化。

我们的监控大概分为系统级、应用级、项目逻辑和用户体验四部分。系统级主要监控硬件和网络等；应用级主要监控常用软件的健康状况；项目逻辑监控主要模拟用户行为探测项目功能点是否运行正常；用户体验监控主要联动博睿和基调等第三方监控一起优化用户体验。我们用过的工具很多，开源工具有Nagios、Cacti、Ganglia、Zabbix等，同时自己也开发了一些针对项目场景的监控工具，但万变不离其宗，都是围绕上述几个维度进行监控，然后再进行分级预警和报警。

为了减少报警骚扰，我们分级处理，将报警分为邮件预警、短信报警和疯狂短信报警。以磁盘空间监控为例：每天下午6点，统计 磁盘使用率超过80%的机器，发出邮件预警，下班前解决；在预警的基础上，超过85%触发短信报警；超过90%就要持续报警，避免事故的发生。此外，随着 服务器数量的增多，硬件故障在所难免，架构设计需要考虑高可用方案，冗余范围内的服务器故障会以邮件预警的方式发出，避免对运维工程师的骚扰。

有了监控工具和分级机制，还需要有好的制度。为了大部分人可以安心休息，我们每天有专人负责处理常规报警，遇到无法解决的问题才要求他人协助。第二天的负责 人要针对第一天的报警找出根本原因，并尽力解决，因为如果无法根治，困扰将持续发生。所谓线上无小事，实际工作中复杂场景引发的问题数不胜数，所以可以宽 容第一次错误，但不能接受同样问题发生第二次，要不断地总结和完善。

工具化是运维的必经之路，是向更高层发展的基础，面对运维这样复杂的学科，这样一个极其磨炼人意志的工种，运维工程师需要用聪明的方式解决复杂的问题，节省时间，去做更有意义的事情。

第二次升级：运维产品化

我刚提出运维产品化时，有朋友开玩笑说，你做后端运维吃苦受罪这么多年，看着产品经理吃香的喝辣的，羡慕嫉妒也想转行做产品吧。也有人说，你是在偷换概念，不就是做自动化运维平台嘛。其实提出这个概念，一方面是源于有了足够的工具化积累；另一方面是想换一种思路做运维，培养产品观，站在用户的角度思考问题，让处于后端的运维工程师主动挖掘需求，围绕运维做更多的探索，提升团队技术能力，解决海量用户带来的问题。有了这个想法，就需要将无形的技术转变为有形的产品形态，同时要赋予它好的寓意。我们的产品取名为HULK——绿巨人，意在让小伙伴们借助巨人的肩膀成长，轻点鼠标，运筹帷幄。

想到做这个平台，源于对实际工作需求的观察。产品经理有了创新点之后，开发工程师就想以最快的速度上线，但又会很痛苦，因为产品就好比宝塔明珠，塔基需要一 层层地盖。而开发工程师是与运维工程师合作最紧密的兄弟，“兄弟有难得拔刀相助”，因此我们明确了开发工程师就是运维平台的用户，运维工程师在平台的建设 中扮演了多重角色，是建设者也是使用者，但目标是为用户解决问题，让我们的用户有极致的用户体验。基于这些想法，我们勾画出了宏伟蓝图，提供一个塔基，第一层提供核心基础服务，如Web、RDB、NoSQL等；第二层提供通用基础服务，构造一个完美的平台，让开发工程师受益。但勾画的平台功 能大而全，需求都是我们替用户假想的，这样做的后果就是进展缓慢，但做出的功能没人用。我们在失败中反思，意识到需求还得从日常工作中去挖掘，平台上每个功能模块都必须解决用户的痛点。互联网精神唯快不破，要围绕“快”找痛点。早期开发和运维的合作中，更多的是邮件、IM及当面沟通，跨团队的沟通成本是第 一个痛点。初期平台建设中，我们从加速流程开始进行摸索，以“需求任务流”为核心，将通用需求规范流程，统一需求提交页面，同时尽量为用户提供选项，而不是随意填写，尽量减少沟通成本，同时为完全自动化打好基础。由于完整的自动化流程开发成本比较高，初期我们还“投机取巧”，用户提交需求以后，只是把格式 化的邮件发送给运维工程师。运维工程师使用半自动化工具干活，完成后再通过平台任务流告知用户结果，手工操作的部分是隐藏在平台后面的，用户不得而知。就 用这种方式，我们的平台积累了不少用户和口碑。之后我们将日常需求分层、分类：主机类包括主机申请、账号授权、软件部署等；Web类包括配置文件管理、域名管理等；DB类包括建库、建表、SQL审核、授权等。再攻克技术难点将一个个需求实现完全自动化，点点鼠标解决问题。

关于需求任务流，还有个小插曲，标准的任务流由提交、审核、驳回/通过组成。但这个流程太死板，例如用户提交的一个需求，在审核的过程中有待商榷，运维工程师会和开发工程师 沟通，最终达成一致意见即可，而如果按标准流程需要驳回再提交。为了让用户少一次操作，我们增加了管理员可编译功能。有些同事反对这样做，觉得不符合常 理。不过有时候常理是需要结合实际场景打破的，就为了让用户使用更简单。

近期为了进一步提升项目试错阶段的速度，我们在平台上推出了一个新功能：“项目孵化器”。以典型的Web业务为例，以往，申请Web Server、账号、数据库实例、负载均衡等是提给运维最基本的需求，每一步都是时间成本。使用“项目孵化器”可以最大限度解决这个痛点，只需在平台上进 行两个步骤：第一步填写业务名称，预估峰值QPS；第二步选用MySQL、MongoDB、Redis等相关数据库资源。两步之后，Web Server、数据库实例等所需资源会瞬间展示在用户面前，同时包管理、配置文件管理、代码发布系统、监控系统等配套辅助功能随之开通。

与之前的模式相比，效率和规范化都有明显提高。说起来很神奇，但实现理念很简单，我们提炼日常项目中的通用方案，构建资源池，在项目发展初期最小量匹配资源。在孵化器的设计阶段，我们听到了很多不同的声音。例如，让用户填信息不够全面，架构太简单不满足全部需求，诸如此类问题，让人头痛欲裂。经过过往项目 分析及用户调研，发现项目尚处于试错阶段，快速试错是首要需求。至于项目发展中衍生出来的需求，可以再用平台扩展功能去解决。当利用孵化器建立一个试错项目之后，用户进入平台想看见什么？展现形式如何？还能做什么？这些问题随之而来。

众所周知，项目中的关联关系是个复杂的问题，解决不好，就像一盘散沙无法联动。为了解决此问题，首先我们确定平台各功能模块以项目名为主键，将项目的域名、负载均衡、Web Server、数据库、通用基础服务等相关联。项目后期各功能模块的扩容可以借助关联关系自动化完成。例如增加一台Web Server，即可自动部署软件环境，完成相关节点授权、上传代码、测试上线。

展现形式上我们借鉴社交网站的实现方案，以“我的项目”为中心，用户进入平台以后默认页展示项目在平台中用到的各功能模块信息，例如域名、主机数量、数据库实例和监控指标等。做到信息清晰可见，操控简单易用。

在平台建设中，我们一直遵循两个准则：第一，把事情由复杂变简单；第二，给用户极致的用户体验。所谓极致，就是要超出用户的预期，但只有挖掘用户潜在的需求，才能做出超出预期的功能。传统的运维模式，大多是开发工程师提需求，运维工程师满足需求，运维工程师主动推进的意识不够。360的文化中有很重要的一点是Ownership，一个项目的成功与失败，运维工程师是有责任的，因此需要在日常工作中时刻提醒自己“这个项目是我的，为了让项目变得更好，我们需要主动思考，为开发工程师提供更多的增值服务”。例如一个项目上线前，会默认部署日志收集模块，收集汇总后进行访问日志自动化分析，以时间维度展示访问量走势，同时辅以IP地址分析模块展示地域及运营商分布。同时基于访问日志状态码做进一步的页面分析，然后以日、周、月维度生成一份体检报告，以及应对方案推送给开发工程师。这些增值服务是超出预期的，拉近了开发工程师和我们的距离，一起去探讨、改进，做出更多有利于项目发展的功能。结束语

运维工作在一家公司中至关重要，但传统的运维模式一定程度上限制了运维工程师的技术发展，更抑制了创新思维，我们需要利用运维“宽泛技术”定位的优势开拓思路。例如运维工作需要和很多开发团队合作，协助架构设计，在这个过程中会接触到很多开发团队的技术积累，可以把各家之所长进行聚合，将一些基础服务进行平台化改造，资源共享。也可以根据项目的需要，主动做技术研究，将基础服务做成一个个小产品，提供给开发团队使用，帮助项目缩短研发周期，稳定发展。在当今技术背景下，运维工程师应该在红海中寻找蓝海的思维模式，培养产品观，由外至内地思考，突破传统运维的壁垒，开拓创新。

第三篇：运维主要工作

运维主要工作：

（1）运维人员每天至少上午，下午现场巡视检查设备运行状态。

（2）每天值班的运维人员负责接听电话，负责每小时抄写各种记录表格一次。

（3）执行俩票三制制度。

（4）配合厂家完成检修任务。

（5）上级领导安排的其他工作。

（6）夜间值班，需要睡在主控室，所有设备报警声必须打开。

（7）配合站长进行应急处理。

（8）清理光伏区组件，避免因遮挡问题而导致发电量损失，表面因产生热斑而导致组件损坏与异常发热。

（9）每月最少一次在负荷最高时用热成像仪检查组件是否有热斑，每周检查一次电气设备是否存在温度异常升高的现场。

（10）恶劣天气后进行特殊巡检。站长的主要职责：

（1）是电站安全运行的第一责任人，对电站的安全运行负责。

（2）负责审查各种报表，负责检查两票。

（3）负责监督运维人员执行各项措施。

（4）负责对运维人员进行考核。

（5）负责对运维人员提供技术培训及技术支持。

（6）负责安排运维人员的工作任务。

（7）完成上级领导安排的其他工作。

（8）负责与电网方面进行联系，业务处理。维持电站与电网之间的关系。

（9）负责担任工作票签发人，工作负责人。

（10）重大操作时担任监护人。需要配置的物品与设备

录音电话一台，并将录音接入电脑，用于同调度联系。OMS电脑一台，用于同接收发送调度邮件。普通办公电脑一台（向电网咨询，如不需安装则不用安装OMS电脑）。灭火器若干，不能放置于开关柜室，干变室，二次继保室中，需单独配置灭火器箱。二次继保室必须使用二氧化碳灭火器。接地电阻测试仪一台。热成像仪一台。蓄电池充放电设备一台。各设备技术协议，图纸需全部配齐，不能缺少。组件配品配件若干，汇流箱内空开备品备件若干，浪涌保护器若干。变压器各种备品备件若干。工具包两个，内配置工具。电笔若干，万能表两个，钳形表两个，10KV验电器两个，并按照相关国家规定定期进行送检。10KV绝缘手套两副，绝缘鞋两双，并根据国家有关规定进行送检。灭火器也需根据国家规定定期进行送检，灌装。工具一套，包括各种型号的扳手，内六角扳手整套，呆扳手整套，梅花扳手整套，螺丝刀一字与十字若干，型号配全。接地线至少两组，并根据国家有关规定进行定期送检。绝缘梯两个。逆变器内各种小开关至少每台配置一个各种逆变器需要用到的型号。A4打印纸，A3打印纸。找厂家专门定制表格一份，用于填写记录表。软毛刷若干，可伸缩杆若干。塑料水桶数个。打印机一台，可打A3与A4纸。安全规程人手一本，县调度规程一本。公车一辆，必须可以拉货。五防钥匙需多要一台备品备件。紧急解锁钥匙三把，可折叠单人床一张或两张，人员要求附加原因解释。每个光伏区进口都需安装铁门，光伏区周围加装安全护栏，如公司感觉无需加装则可以不加装铁门与遮拦。安全标识牌若干，包括“高压危险”标识牌数个，“高压危险，禁止靠近”标识牌数个，“禁止合闸，线路有人工作”数个，“禁止合闸”标识牌数个，工程负责人与我进行交接相关工程图纸等交接。其他物品等商榷以后进行补充。强光可充电式手电数个。其他物品需根据运维实际情况进行补充。人员要求

运维工作的正常开展不算我需要四个人，尽量全是男的，从事过电工工作最好，是否是高压电工都行，普通人员也可，入职前进行体检，确保无传染病，在站内吃饭，最好是住在站内，如条件不允许可以就近安排住处，如附近无住宿条件，夜间值班便需两个人，轮流夜间值班可以睡主控室。是不是当地的都行，最好是有一个工程人员转运维人员。

个人要求

月薪6500，五险一金，可以按照国家最低标准交，但必须有，享受法定节假日三倍工资，每月休班7天，时间自己安排，有年终奖，工资每年调整增加一次，具体金额公司视发电量与电站安全运行情况决定，如不需我同电网进行关系维持则月薪6000，如再提供食宿月薪则5500，单独提供住宿月薪5700。同时公司可安排我外出参加各种相关培训，出差费用公司报销。有本电站运维人员的任免权与考核权。正值工作任务

担任工作负责人，工作许可人，工作班成员，专职监护人，负责填写工作票，并履行相关手续。审查副职填写的操作票并送与站长审查，填写工作票并送与站长审查执行巡视检查制度，监盘并按规定填写各项表格，站长不在时行驶站长权利，接听调度电话，重大操作时担任操作人，非重大操作时担任监护人。打扫全站卫生，上级领导安排的其他工作。副值班员工作任务

担任工作班成员，担任专职监护人，负责填写操作票送与正值审查。监盘并按相关规定进行填写各种表格，执行巡视检查制度，接听调度电话，在站长或正值的监护下进行倒闸操作。

其他事宜根据运维实际情况进行调整。

第四篇：变电站运维工作个人总结

变电站运维工作个人总结

回顾过去的一年，在市县公司工区领导指导下取得的一些成绩，但也有一些不足。现就运行工作总结如下：

一、努力学习新知识，掌握新设备，提高业务技能。

我所工作的单位是一所建设刚2年的变电站，有着配套齐全的办公设施和生活用具，有着慕煞旁人的生活和学习的条件。自从2011年4月进入110kV变电站工作以来，在市县工区领导关怀指导下努力改变以往工作模式与方法。从一个干好自己工作为己任，无关他人的自我态度，通过不断的学习和锻炼，逐步转变为互相帮助，共同完成与提高的协同办公新模式。记得建站投运之始，依然是每天跟班日出而作，日落而栖学习设备的理论和操作方法。终是初步接触110千伏变电站设备，在市工区领导平时工作担心忧郁的语气中，我常感无形的工作压力，正吞噬着我；而这，也正深深的激励着我，更加以自觉学习业务知识。

直到去年的某天，在一派新设备无故障的思想中，几乎把尚存脑海的业务知识遗忘殆尽的时，突然接到地调110kV624线路配合停电检修的操作指令，在市工区领导仍然有些担心的口吻中，我以正确的事故处理方法及操作步骤面对，在默认处理措施后，在长长的电话线那边，似乎看见领导在稍稍放松的神情里，正用赞许的眼光望着我。。

二、立足本岗位，发挥党员模范带头作用。

作为变电站一名基层党员，爱岗敬业、忠贞不渝，在保持党的纯洁性工作和意识形态中，唯有加强变电站平时安全运行意识的养成和既定制度管理的落实，服务好人民群众，促进变电运维工

作的全面发展，才是爱党、爱国家、爱公司应有的体现。我在过去的一年中主动学习党的方针政策，加强党性修养，进一步提高自己的政治觉悟和工作能力，在尽职履责中发挥模范带头作用。在公司基层变电站里营造和谐工作氛围，勇于担当，充分体现党员的优秀价值。

新形势下，多年的基层变电站工作，让我深深的知道迎峰度夏的工作中，公司和电网发展所面临的任务。我从本职岗位挑战出发，时时处处以身作则，用实际行动充分体现党员的执行力和实践力。在过去一年的围绕迎峰度夏保供电工作中，我明确时段、地段、人员和工作要求，落实测温、特巡等工作，包括设备过热、线路弧垂下降等原因引起的跳闸，全面开展变电设备状态巡视和检测工作。切实防止变电设备巡视维护不到位而引发的设备事件发生，通过努力，“迎峰度夏”保供电工作在两级工区领导大力指导下，取得了圆满成绩和效

果。

三、继往开来，把一腔工作热情付诸于无限的为人民服务中去。

作为电力工作者，我们任何时候都应以党和企业的事业为重；任何时候都应践行“诚信、责任、创新、奉献”的核心价值观，高标准履行国家电网人的职责。在今年政治性用电“国庆”、“十八大”保电工作中，严格遵循各项规章制度，严防死守，密切配合电力调度，有力的保障了当地人民群众广播电视的正常收听，收看。我来自于基层变电站一名普通的职工，任何时候都应服从整体利益，恪尽职守，在以后的本岗位上，我也将一如既往扎实干好自身工作，干净干事，发挥党员模范带头作用，努力为当地经济的发展值好班、站好岗，向组织交上一份“组织放心，群众满意”的答卷。

第五篇：运维工作周报

运维工作周报模板

报告人：XXX 时间：2012-X-01 ~ 2012-X-07

一、常规工作

1.2.3.4.5.LVS项目推广；

发布系统网络调整配合； 快答系统上线；

制定Q2的5年服务器替换计划； 系统运维等常规工作跟进；

二、项目跟进

1、IT运维平台

机架资源功能因等待研发的进度，延迟到下周完成；

二期总结除bug；

运维平台的使用推广，并开始完善应用关联关系的资料；

绩效体系积分处理的实现是第三阶段的重点，预计6月30日完成；

2、分布式文件系统测试

完成Mogilefs线上测试，并出具报告；

整理Mogilefs上线所需的资源和计划，下周约开发谈具体部署；

搭建Mogilefs的内部开发环境，配合图片平台的开发工作；

总结：经过4个月的内部和外部测试，Mogilefs的整体测试已经全部完成，从测试的结果看，无论从性能、稳定性、扩展性、容灾性等各方面的指标，Mogilefs都可以符合目前的线上图片存储的需求，经过多资源的统计，仅需很小的投入即可完成改造，并能有效的利旧设备，整个部署预计7月中旬完成。

三、团队管理

部门规划与绩效考核

l 规划与IT运维平台的整合计划，预计6月30日完成；

其他管理工作

l 审核架构的搭建和完善；

l 主备冗余计划，完成第一批的主备交接工作；

四、工作难点、问题与建议

五、下周计划

1.2.3.4.5.6.7.8.9.常规工作继续跟进；

继续跟进IT运维平台的开发和推广工作； 重点跟进分布式文件系统的规划和实施； 重点跟进审核架构的相关工作； 重点跟进设备采购及部署规划工作；

继续跟进整理运维中心的绩效考核体系； 继续跟进相关项目的研究工作； 继续跟进运维相关项目的进度； 继续跟进团队建设相关工作；