笔者在一家软件公司从事传统的数据运维工作，也有十年之久了。十年的数据运维工作，真是一步一个脚印，一步一个坑踩出来的，也没想到这一干就是十年…

关于职场中的工作失误

借个同事的例子，讲讲笔者理解的"失误"。

想必在职场中的朋友，都造成过或大或小的失误。但是在笔者的公司，很少会说失误，一般都会比较直接的说是"错误"，因为数据运维工作不存在失误，只有对错。笔者前两天刚参加了一个项目的5W评审会，会议是针对和笔者从事相似工作的另外一个同事，在工作中的“错误”，险些酿成大错（笔者所在部门指的大错，一般是指把有问题的数据，部署到了云端，客户获取到问题数据，导致投诉或者赔款等等，惊动公司高层）。

先说说这个同事，从事这个工作也有三年了，对所在的项目整体运维工作都是比较了解的。但是人嘛，对自己熟悉的工作，时间久了就会存在一些懈怠。笔者常常提醒这位同事，对于不清晰的需求，一定要确认确认再确认，直到需求清晰，千万不要存在“我以为，误以为”这种想法。工作上面的事，一就是一，二就是二，不存在灰色的区间。

再谈谈发生的这件事，简单的说就是相同类型的配置文件，又搞错了。这位同事在三月份搞错一次，影响较大，部门的PM对这个事写过一次5W报告了，对公司的项目组保证过不会发生类似事件，在流程上也加了规范和要求（实际上这些要求也是存在的，只是没有严苛执行而已）。但是笔者这位同事也真是不争气，没过两个月，又搞出了这个事。公司的项目有点恼怒了，刚刚出的问题，怎么又出了这种事。部门的PM也没办法了，拉着部门内部人员，大会小会开了多少次。这位同事总说"不出事的时候，半年也没事，一出事连着出事，真是屋漏偏逢连夜雨"。这位同事之前造成的“失误”也是不计其数，也没少让PM写报告。但是说实话，笔者所在公司部门内部的PM都是比较和善，认为过去的事就过去了，以后别再犯了，也就翻篇了。

这位同事在私下也和笔者交流过，对这份数据运维工作也是卷了，颇有些当一天和尚敲一天钟，敲到哪天算哪天。笔者也曾苦口婆心的劝导这位同事，既然不喜欢这份工作，现在又扔不下，那在闲暇时间多学点东西，最起码即使换岗或者换工作，也有些底气。这位同事说自己不是这块料，学不进去，他一直想去另外一个组，可能也学不到什么，最起码也能混点相应的工龄，有点身在曹营心在汉的感觉。笔者也只能无奈的摇摇头，部门内的人相互都有一定了解，既然你在这个组待不住，想去别的组，人家组长还能不知道你的为人嘛。

笔者铺垫这么多，其实想说的是，有些失误存在外因，但也一定存在内因。外因可以通过流程或制度避免，但是内因呢？

如何处理失误

如何处理失误，按照常规套路就可以了。无非就是按照5W一直追到问题的具体原因，然后提出改善措施，大家在开个会研究研究这个改善措施，以后按照这个措施执行。

笔者想说如果辩证的看"失误"，失误虽然有些恶劣的影响，但是也会让我们有所收获。

• 如果在某个模块经常出现问题，那我们就需要注意了，如何避免这种问题，采取什么样的措施在类似的模块上避免类似的问题，学会举一反三的多思考。
• 前面也提到了，笔者是一步一个坑的踩过来的，通过这些坑，让笔者更了解这些工具或数据的内部运作流程。如果没有这些坑，笔者可能不会留心在这些地方。
• 出现失误后，在无法短时间解决的情况下，会首先讨论影响，如何让影响最小化。在讨论的过程中，我们又可以了解某个模块的影响是什么。

笔者并不是误导读者有意制造失误，呵呵。

认真的处理失误吧，笔者以前的领导老跟笔者说，这些失误都是公司给你交的学费。

一点感言

• 如果对现在的工作卷了，也请认真对待，任何工作都会为我们积累经验。这些经验即使在表面上对下一份工作没有直接作用，但是在工作中处理问题方式和流程上都会有可以借鉴的东西。
• 对于熟悉的工作内容，一定不要懈怠。自己的一个工作失误，不光影响自己，也会影响别人。笔者向来本着尽量不给别人添麻烦的态度工作和处事，如果真的麻烦到别人了，也需要说声"麻烦了，谢谢"。因为有些事，别人帮你也不是人家的本职工作。
• 不要浪费时间。笔者常常对自己的组员说的一句话就是“不要浪费时间”。即使学一些和本职工作无关的技术，说不定在哪天也会用的到，毕竟学到的东西都是自己的。不要浑浑噩噩的度日，因为时间过得真的很快。