从根因溯源的误区谈起
昨天看到一篇成哥转发的《服务稳定性保障的五大误区》，是一位快猫的朋友写的，读完对于这五个误区还是深有同感的。虽然不同的组织在IT管理的方式方法上差异很大，面对的应用场景也各不相同，不过在很多IT运维人员身上都或多或少地存在一些类似的误区。对稳定性保障要求的错误理解会导致组织采取错误的措施，更可怕的是选择错误的方针，那就会带来灾难性的后果。典型的是大家干得很累，也花了不少钱，但是效果不好。“根因溯源”就是常见的一个存在误区的地方，到底什么是根因，因和果如何区别？有时候就像藤蔓一样，不知道到底是谁先纠缠谁。不过企业的IT主管大多特别喜好根因溯源，不把问题搞清楚，下回再出现类似问题那可怎么办，不把问题搞清楚，我怎么去采取针对性的措施？有时候就会出现根因溯源不可为也必须为的怪事。我7、8年前遇到一个案例，一台IBM小型机每隔两三个月就会出现AIO线程HANG死的问题，必须重启服务器才能恢复生产数据库，而这套系统的IO吞吐量高峰时也不过200M/秒，完全在存储系统和小机能处理的范围内。
客户要求做根因溯源，一定要找到问题的根因，厂家实在找不到问题原因了，只能说太阳黑子导致电磁异常引发了问题。我想找个结论领导也肯定一眼就能看出是纯粹忽悠的，只不过找不到其他原因，那就只能找到一个无法辩驳的论点来解释了。实际上那个领导当时想要做溯源的想法也没有方向性的错误，找出问题原因，解决掉肯定是对的。这个问题后来又出过几次，甚至后来每个月都会引发大问题。太阳黑子不能总有，因此后来只能把责任推到应用的SQL写的太烂上。不过修改应用的效果并不理想，经过几个月优化，系统性能提升了不少，不过AIO线程HANG死系统的事情还是在继续发生。2015年我们参与了分析，当时我提出通过调整一个数据库参数也许可以解决这个问题，当时客户问我是什么理由确认一定是这个原因。我说根据我这二十年的经验，大概率是这个原因，但不是百分百保证就是这个原因，这个参数调整不会对系统产生明显的负面影响，所以建议他们试试。因为我没有给出根因分析的特别有力的证据，因此客户开始坚持不肯修改这个参数。后来问题越发严重，变成每星期都会出一两次故障了。于是只能死马当做活马医，调整了参数，立竿见影就好了。上面的那个例子中，Oracle参数的设置是不是根因真的不好说，谈起根因来，这个问题是AIX系统的AIO和数据库之间存在的不匹配导致的，如果数据库不使用文件系统，直接使用ASM，就不会出现类似问题，终我也是通过启用DIO解决了这个问题。从这个案例我们也可以看出根因溯源不易，因此这个我们DBA常用的词还是改为“问题溯源”比较好。从问题现场往上游追溯，直到能够找到比较好的解决问题的方法就可以了，不一定非要找到根因，因为有时候根因确实也不一定找得到。前阵子我写过一篇文章《从物自身谈起》，里面就提到了根因溯源，也谈到了我十多年前的几个自认为十分成功的优化项目并没有解决根因问题，只是从一个侧面缓解了问题，从而临时性解决了问题。当时有可能还存在更好的解决方案，不过以当时的能力暂时还无法找到。事后诸葛亮是比较好当的，如果我们已经看到了结局，再去分析问题的发展过程，那肯定会头头是道的，通过根因去解决问题，肯定也能解决的更好。只不过由于种种因素存在，这种优解并不一定能够获得。既然根因如此不可获得，那么组织还需要根因分析吗？这个问题在不同的企业里，甚至同一个企业不同的场景下，答案不是固定的。对于任何一个隐患告警都做根源分析肯定没有任何意义，而不具备根因分析的能力会让企业遇到难办的运维问题的时候付出巨大的代价。因此企业不会把根因分析当成日常工作，但是需要具备这个能力，而能力并不一定在现场，很多时候来自于外部专家，维保公司。根因分析有时候取决于成本，有时候取决于能力。我们是否有能力去发现根因，我们是否值得花成本区分析根因，这个问题如果真的叫起真来也容易搞清楚。世界分为“显像”与“物自身”，我们平时看到的只是显像，即事物对我们的显现，而不是物自身。这是我在那篇文章里写的，物自身就是根因，而我们的分析与诊断报告就是显像。显像可以无限接近物自身，但是永远不可能成为物自身。从这个角度上讲，“根因溯源”确实不是政治正确的。我们还是把这个工作叫做“问题溯源”吧，实际上我们日常运维遇到的大多数问题不需要进行“问题溯源”，随着企业数字化转型，信息系统的规模越来越大，对于任何问题都要求“闭环管理”、“问题溯源”是十分高成本的，也是企业IT无法承受的。不做问题闭环管理，可能会遗留下一些隐患，不过从总体成本上的考量，这种风险企业是必须承担的。不过从另外一方面，IT运维监控需要提高风险识别的能力，能够更加准确的识别高风险事件，并加以告警，而对于低风险事件，我们可以放心大胆的进行忽视，哪怕这种忽视中带有一定的风险。实际上大多数高风险事件发生之前是有各种迹象的，哪怕这个风险没有被识别出来，其附加作用也会引发系统的一些其他问题，比如系统变慢，日志告警增多，SQL执行延时不稳定，并发指标变大，关键SQL执行异常，内存/CPU飙升等。根据这些显像，我们还是能够发现问题，并通过“问题溯源”找到和这个未识别风险之间的关联关系的。不管是“根因溯源”还是“问题溯源”，其宗旨都是通过关联分析，发现更上游的问题。根因定位因为成本与能力问题有时候不可得，不过通过其他方法，总还是会通过比较低的代价来发现问题的。在实际运维工作中，高风险事件应该能够被比较精准地识别出来，并及时告警，以便于防患于未然。中低风险事件不一定需要立即闭环管理或者立即处置，不过我们可以在定期审计或者巡检中列出这些风险，并在成本与能力可及的情况下去做做优化。现在的IT运维工作十分繁杂，IT部门可能更为关注的是如何解决日常必须做的工作的便捷化与自动化，对于风险发现，性能优化这些工作，只要不出大问题，那就放在一个比较低的优先级上。我在和很多客户的IT主管推荐D-SMART的时候，他初都会对故障预警，问题自动分析等功能很感兴趣。讨论到后面，他们都会提出一些令我哭笑不得的需求来，比如说你的工具提供不提供批量修改监听端口号的功能？当然这个功能要想加到D-SMART里也并不困难，而且D-SMART也需要接入更多的客户日常需要的功能，让它能够成为一个日常的生产力工具。不过术业有专攻，运维的需求太复杂了，D-SMART只是一个领域性的工具，而不是企业的IT运营平台。不过从这个事情也说明了另外一个事实，实际上大多数IT主管急切要解决的还是活太多干不过来的问题。让系统运行的更好在理论上很重要，但是在实际上有时候排位比较靠后。只有出了一次大的性能问题或者系统故障，领导重视了，这些优化和防患于未然的工作才会变得重要起来。究其原因，主要是性能优化，隐患排查的成本太高，技术要求太高，企业没有能力和成本投入在这方面。专家的能力是十分昂贵的，很多企业根本用不起。如果能够把专家的能力变成自动化的工具，利用自动化的工具，让这些没有能力做或者没有资源去做的事情用更低的成本做起来，那样是不是这些工作也可以变成常态化的工作呢。问题溯源十分困难，也十分高成本，不过如果我们能够借助企业积累的经验，利用工具，把问题溯源的成本降低到一个日常用得起的水平，那么问题溯源是不是还会被认为不是日常工作的必需品呢？
五年前我们开始研发D-SMART的时候，就是希望降低这方面工作的难度，让常态化优化和防患于未然也能以低成本的模式进入企业运维工作中。这方面的需求实际上是十分广泛的，只是因为目前成本太高才会变得似乎不那么重要。通过这些年D-SMART的研发，特别是上个月D-SMART社区版的推出，我们发现，只要通过社区协作的模式，这个能力也会变得低成本。另外一个角度，随着日常我们对监控数据的专业化采集，问题溯源工作与日常运维中快速恢复系统运行的矛盾也不存在了。系统出问题先按照尽快恢复系统的原则该重启重启，该起备机起备机。问题溯源可以事后慢慢来。基于上面的情况，我想能够解决这些问题的这类运维工具的市场前景还是不错的。