对IT运维工作中的几件事的思考
学习资料：IT运维管理社区专家讲堂直播300期视频回放1、新员工的工作开展问题：新员工（刚毕业）对企业的人员、流程制度、工作氛围都不太熟悉，加上工作经验不足，工作受认可程度低的困难下，如果用新员工作为项目经理推动工作是否合适？
解决思路：新员工的弱势地位不可避免，但是否可以采用梯队方式，例如经验丰富的员工A，部分经验的员工B，新员工C，按主导地位排序，初期最佳搭配方式可以是A+B+C；锻炼队伍是是B+A+C；如果是C+B+A或者是C+A+B，效果可能都不怎么好，没有起到带新人的作用，反而把新人吓坏了，自信心受到打击。2、知识标准化每个人都有很多知识，现在尽管有了IT运维管理社区、博客、微博、圈子等各种虚拟社区交流，但对实际的工作影响还是有限。特别是工作中的知识共享，企业花大力气进行推动，效果微乎其微，这里边有大家对知识的共享认可态度、员工能力以及相关考核制度等各个方面的原因，但有一个原因不能忽略，那就是知识的标准化，简单来讲，知识的组织结构、知识的存储与传递方式、知识的分类、知识的授权，包括知识的格式，都是一种标准化内容，缺少这些规范，即使产生了大量的知识，它起到的作用也非常有限，因为它没有动起来。最近在协助推广一套帮助系统，看到的内容各式各样，千变万化，这就像你开车的时候迫切需要个路牌来指路，告诉你去那哪条路，结果你好容易看到一个，上面居然是小学生写的字，扭扭歪歪不说，还上下错乱，秒数不清，文不对题，看了估计要抓狂。
3、IT维护人员的发展前途目前行业来看，IT维护人员，算作是高薪行业中的低薪者，大家普遍的想法就是技术含量低，没价值体现。这其实也可以理解，就像一个城市里的清洁工，如果你听说他们的薪水是10K每月，估计你肯定会说没天理了，但如果你一出门满地的狗巴巴和垃圾，一走路，身后有十几个方便袋随你起舞，估计你就会感觉到清洁工的价值了。
IT维护工作也有级别之分，IT维护人员也有发展趋势，简单来讲，有三个方向，我称之为三维发展坐标：业务方向、建设方向、技术方向。业务方向就是深入了解客户的业务，做到业务专家，其实你就可以跳槽到业务部门了，有信息化背景做业务，无疑会能更好的助力业务的发展，不过大家可能技术思维定式惯了，对业务有排斥心理，很少有人做到这方面的发展。第二种就是建设，其实是指IT系统的建设、规划等方面，随着运维经验的富足，深入了解系统架构以及规划、建设、实施等各个方面的要点，就可以发展到建设这一个方向。第三种目前比较普遍，维护人员可以把技术做深，这里也有两条路，一条是横向发展，把技术做宽，IT运维技术也很丰富，硬件、操作系统、中间件、数据库等各种层次上，都可以发展；另一条是做专，抓住几个方面，例如数据库，可以持续深入，对数据库的表现和底层技术深入挖掘，做到这个专业的professional。
4、预防式维护在哪些方面可以预测目前的维护，基本是出了故障就去救火，预防式维护有些搞头，但是还没有精细化的搞，最起码我们实际的工作还有待深入。预防式维护一种是彻底预防故障的发生，这些工作在系统维护阶段只能是通过不断的发现系统的问题，修改系统bug来解决，因为系统框架已经这样，要重建系统可以，问题是钱谁出，原先系统的问题责任由谁负？剩下一种只能是做趋势分析了，很惭愧，数学学的太差，用不了数据模型，靠拍脑袋，一种就是网络预警，在网速、路由信息等方面是可以进行趋势分析的，可以做到阀值预警。另外一个是应用软件平台方面，在请求队列这一点上，也可以进行观察和预测，设置阀值。
5、IT运维人员从事开发工作的考核问题运维人员其实做的好，就是半个开发人员，unix下c开发、shell开发、windows开发，以及跨平台的java、python、cgi开发，都是必不可少，但是作为基本的运维人员，这些开发工作都不能在你工作中体现，因为这些都是改善性的，可能你的工作需要用项目、申告等各种考核，特别是驻现场的人员，这些都是有很高的技术含量和价值体现的内容，可能没有考核来对应，可能你辛苦花了一周时间开发了个实用工具，在实施时可以有效降低手工操作，增加实施可靠性，但你的考核里没有这一条，你的考核里边只有系统连续可用率、故障率、满意度等等。那你怎么办？
6、运维项目中的开发组定位有运维就有开发，这是无法避免，如果在一群维护人员中，把开发经验的人组织起来，进行提升系统稳定性以及预防式维护的开发，对项目来说，这是相当大的好事，可是问题同上一个，你还要肩负N多系统的日常维护，救火就忙不过来，你辛苦的组织大家做了工具，结果根本没人搭理你，年底考核时，你的系统可用性、故障率等考核指标没有根本性变化，试问你如何自处？在目前国内IT运维基本靠人的状况下，IT运维的质量和效率都有很大提升的空间，我感觉开发组的定位应该是为提升运维质量，提升大家工作效率为目的，这些都是对项目和客户有长期价值的事情，运维工作的考核应当适当的鼓励和对这些工作倾斜，而不是仅仅关注客户所关注的，仅仅去救火（尽管很多主观都不认为自己的项目在救火状态）。 说的有道理 公司内部整体推行标准化后，ITIL服务体系才有推行的价值