说出来不怕华为的同事们笑话，来华为前，我压根不知道世界上还有一种工作叫“维护”。 如果当时面试华为的时候，面试官和我这么介绍： 维护这个这项工作需要你的手机7X24小时开机，紧急情况下深更半夜还得从床上爬起来远程处理故障，甚至节假日还得值班，出去旅游还得带上电脑……那我可能就当场“吓退”了。
李然东，华为公共开发部MAE-CN产品部维护工程师
而如今，我竟然已经在维护的岗位上干了十年，成了一名维护专家。再回首，我觉得维护的工作很苦，能在这个岗位上长期干下来的人，要么忍耐力很强，要么是懂得苦中作乐。我应该是那种会苦中作乐的人，比如我会半夜解决问题的时候会不知不觉唱起歌，可能就是因为这种比较乐观的态度，会让我多想一想维护工作在“苦”之外的另一面——寻找规律性，探索如何让这个很苦的工作变得稍微不那么苦的办法。下面就和大家分享我的一些经验和方法。
大部分做维护的兄弟，都是靠不断处理问题来积累经验的，这是自然而然的方式，无可厚非。但是，这种方式的成本非常高，因为每一个经验点背后都是大量的问题，甚至是十万火急的网上事故。接触维护一段时间后，我发现从问题处理的原始经验到领域知识的提炼是完全被动的，没有领域知识的主动构建，是有很大局限性的，所以我尝试了一些办法去优化。后来才了解到，我的做法有一个专业名称，那就是“知识管理”。 我开始搞维护的时候，网管的硬件主要是SUN服务器，它有多种组网，有一种高可靠的组网形态叫本地双机，本双有一套集群监控的软件，搞得不好问题没解决，业务还切换到对端，把问题搞得更糟糕了。所以我每次处理此类问题，都战战兢兢——经常是一个问题过来，分析半天仍不敢下手，后不得不找到项目组的老员工求教，几条命令执行后，问题就解决了。 当时项目组没有总结的存档，知识都在同事们的脑子里，或是在零星分散的案例里，而且我们维护的这套双机软件不是自研的，没有源代码可以分析，所以每次出现稍微复杂一点的问题，我都要搞很长时间，好往往找同事帮忙。有时候大半夜把项目组的兄弟CALL起来，问一些看似比较简单的问题，搞得别人睡不好觉，自然免不了被埋怨，我自己心里也不好受，老因为自己处理不了问题打扰到别人，我心里非常不安，觉得很愧疚。 所以经过一段时间后，我逐渐意识到，这种一个项目组内不断重复造轮子，人拉肩扛的“手工”做法，对自己、对团队，代价都太大了。尤其对新同事来说，他们不会处理问题或者处理问题花费时间很长，原因就是缺少必要的知识，其实每一个问题都会对应一个或多个知识点，掌握了这些知识点，接到问题，经过一定的逻辑推理，就能运用知识予以解决。 明确了问题的关键后，我就开始收集相关的资料、问题定位手册以及网上的各种案例，还把项目组同事们零零散散总结的一些案例全部汇总起来，想要形成自己的资料库。我花了大约一个月的时间，阅读双机软件的产品文档和一些原理性的文章，走读了相关的资源监控脚本，然后通过历史的网上问题案例来整理双机的故障模式，后我整理出一份本地双机的问题处理文档。文档一共100多页，非常详实，既有机制和原理说明，又有常见故障的定位和解决办法，能覆盖90%以上的本地双机问题，实用性很强。自那以后，我就具备独立解决绝大部分本地双机问题的能力了，半夜也不用时不时把亲爱的同事呼起来，皆大欢喜。有其他同事加入团队，我也会把这份文档分享给他们，使他们免于经历一上来就抓瞎的尴尬。有时听到同事反馈说，这份文档对他们帮助很大，我心里也非常开心。 后来，我把这种知识管理方式扩展到其他的领域，如异地双机、分布式、虚拟化等工程特性维护，每遇到一个新的知识领域，我都会复用这一套方法，主动搜集材料掌握相关的原理，做到心中有数，同时汇总能找到的各种案例，形成一套从原理到案例的层次化、系统化的知识网络。这套知识网络的底层是该领域的原理、架构和各个主要功能模块的介绍，在此之上是故障模式库，然后基于故障模式逐个补齐定位定界和恢复措施。各个故障点的恢复案例，不再是孤立的知识点，而结构化到整个知识网络中了。正因为有这种完整的知识体系，后来每次我接触新的平台的时候，不需要通过半年一年的积累，仅仅两三个月就能掌握维护该平台所需要的知识和技能，屡试不爽。 大家都知道，维护痛苦的阶段就是还不熟悉的时候，如果熟悉了，会好很多。这套知识管理的方法，主要就是缩短“痛苦期”，我个人因此收益很大，避免了许多无谓的通宵，这或许也是我能够在维护岗位上坚持下来的一个重要原因。
当然，个人的知识管理是不够的。毕竟，没有哪一个个人能完成整个产品的维护，大家都需要依靠团队协作。如果团队缺少系统化的知识管理，必然会出现能力参差不齐的情况，技能比较强、经验比较丰富的人不得不去帮助其他人，这样就会非常累，而且可能还会把小问题搞成大问题。所以，大约在2014年的时候，部门要求我们整理快速恢复文档，这就成了整个网管工程维护团队启动知识管理的契机。 由于先前的经验，领导让我来参与快速恢复文档的设计，并且主导开发工作。我当时就觉得这件事对我们意义很大，不能用完成任务的心态来做这项工作，而必须扎扎实实地搞出一份实用而且好用的故障恢复指导书。 针对这份文档，当时有人提议沿用之前的三板斧+案例集的方式整理，这种思路的核心是案例集。但案例集缺点在于，现网出问题后，首先展现出来的问题现象很可能是表层的，需要经过一步步定位才能知道真正的原因。然而由于同样的现象可能对应几十种故障原因，所以我们的案例集整理的逻辑不是按照现象，而是按照具体原因来归类的。这就造成一个问题，我们很难找到适用于该问题的案例来对照参考。就好像医生看病一样，都是腰酸背痛，原因可能很多，医生哪有一上来就能找到原因的呢？所以，正确的思路应该是：以实际的问题现象（如客户端无法登录）作为问题入口（根节点），逐步排查，不断细分问题场景，终找到问题故障原因（叶子节点）。每个叶子节点就对应于案例集中的一个案例，通过这种方式，就把案例集全部串起来了。 按照这个思路，后来我负责产品“30分钟快速恢复”专项任务的时候，一方面基于多年的维护经验和领域知识，梳理了比较完整的故障模式。另一边我又搜集了本项目组和其他部门相关同事撰写的几百篇案例，把案例和故障模式匹配起来。针对故障模式库中没有案例覆盖的故障场景，主动构造故障后定位和修复，整理好相关步骤，合入快速恢复文档中。经过几个月的开发，终整理出一份包含70个故障场景，非常系统和详实的“SUN平台重大问题快速恢复文档”。 相比之前个人整理的那份100页的文档，这份文档有400多页，故障模式覆盖了硬件/OS/DB/APP，覆盖了SUN平台95%以上的业务中断类故障场景，提供了经过测试验证的完整可用的定位和解决步骤。即便项目组新员工使用此文档，也可处理业务中断类重大问题，而这种问题，之前是需要工作几年的员工才敢上手独立去处理的，因此作用还是非常显著的。 后来，此文档推动到GTAC和RTAC，在日常问题处理中用了起来，二线同事的评价非常好。由于SUN平台快速恢复文档搞得很成功，后来又陆续开发了ATAE、虚拟化平台网管的快速恢复文档。几年下来，快速恢复文档已经成了重大问题处理的宝典，使用次数无法统计，经常有同事告诉我，他自己参考快速恢复指导书搞定了一个不熟悉领域的重大网上问题。这些正面的评价和反馈让我相信，自己的工作是有价值的，工作的方向和思路也是正确的。
虽然都是搞软件，软件维护和软件开发是有很大差别的，但不少没有实际从事维护工作的同事可能会觉得两者区别不大。我认为，网上问题的处理，优的是通过现象+日志定位，看代码恰好是不得已而为之的下下策。从某种意义上来说，维护工作的本质就是知识管理和知识应用。维护专家无非是系统化掌握了领域知识的个人，维护文档就是文本化的领域知识，而维护工具不过是把领域知识转化为程序而已。 维护领域的知识管理，按照其自身的规律，只能按照知识积累文档化工具化的路径来进行。维护文档（比如快速恢复文档，快速定位定界文档等）非常适合作为知识管理的步，通过开发维护文档，既能完成领域知识的积累和梳理，还能够输出一份标准的问题处理手册，方便了网上问题的处理。维护文档经过一段时间催熟后，就可以考虑从中选出使用频率比较高或者比较重要的场景进行工具化，进一步减少工作量。 在开始搞快速恢复的时候，其实大家有两个思路。一些人认为不能依靠人，必须开发工具；另一种观点则认为，问题场景很复杂，工具做不到那么全面，终还得依靠人，所以关键是搞文档。我觉得这两种观点并不矛盾，而恰恰是相互补充的。我们的终目标当然是要工具化，只有实现工具化才能真正解放人，实际点来说就包括减少晚上通宵的次数。但是，工具化必须基于领域知识，缺少完整领域知识，开发出来的工具终很难发挥出应有的作用。基于网管产品的特点和维护的实际情况，我认为比较可行的方式是，先整理完整的文档，通过一段时间的催熟和检验，确保文档的可用性，然后基于文档再进行工具化。 网管的工程维护也是遵循这个思路。快速恢复使用一段时间后，我们就会针对其中使用频度比较高的场景进行工具化。比如数据库故障的发生频率就很高，经常出现库损坏或者表、索引损坏的情况。我们就基于文档开发了数据库修复工具，一键式诊断二十多种数据库故障，在操作者授权后，进行自动化修复。这就极大地解放了人力，加速了问题处理过程。举个实际的例子，U国E运营商曾发生磁盘故障数据备份文件和数据库业务表损坏，无法使用备份文件进行业务恢复的业务受损问题。按照快速恢复文档，采用手工执行命令进行数据导出、重建库、数据导入恢复业务，按照历史经验，几百个表和上百G数据的导出导入，耗时很长，而且极其容易出现错漏，问题处理人员也会搞得疲惫不堪。现在通过使用新开发的数据库修复工具，可一键式完成数据导出、重建库、数据导入，整个过程无需频繁手工操作，只需要监控进度即可，维护人员的时间和精力很大程度解放出来了，提升了工作效率。
当前网管对维护团队的定位正在从单纯的现网维护向SRE团队转变。 传统的维护团队对产品可维护性的主要来自负向改进，以及一些维护侧的文档和工具，就比如我这几年一直在做的快速恢复文档和相关的诊断和修复工具等。而SRE团队则不只是运作于产品在生命周期的后期，而是总体负责整个产品的DFx（Design for X），我们在版本启动的初期就要整体考虑产品的自愈能力，快速诊断能力，快速恢复能力。这种角色的转变其实是给了维护人员更大的发挥空间，一个维护工程师转变为SRE工程师，肯定是需要大量学习的，但不可否认的是，维护工作是走向SRE的重要跳板。长期积累的领域知识，比如故障模式库，快速定位和恢复方案等，是我们提升产品可维护性和可靠性能力的基础和起点。在这方面，维护的知识管理大有可为。 李然东，公共开发部MAE-CN产品部维护工程师。2010年入职华为后，除了负责部分开发工作，更多精力投入在网上维护工作中，负责产品的工程与集成模块维护，包括支撑产品安装、升级、扩容等变更操作，硬件、操作系统、数据库、网络等相关网上问题处理。针对维护的知识管理，他有一些心得与经验与大家分享。
http://xinsheng.huawei.com/cn/index.php?app=forum&mod=Detail&act=index&id=5023443
2020年10月22日~24日，由IT168旗下ITPUB企业社区平台主办的第十二届中国系统架构师大会（SACC2020）将在云端进行网络直播。 自2009年以来，SACC架构师大会已成功举办了十一届，云集了国内CTO、研发总监、系统架构师、开发工程师和IT经理等技术人群，与会规模超千人。 过去为期3天的议程，涉及20+专场，近120个主题，完整迁移到线上进行网络直播对会议。整装待发，奋起逆袭的SACC2020，期待您的报名参与，共襄盛举！
喜欢就点个在看再走吧
