如何高效、低风险精简线上无用代码? 一基于SA技术的系统精简实践

Q&A答疑：

老师好，刚提到的服务下线前和下线后，通知到具体负责人？你们是有使用什么工具或者平台吗？

我们需要在公司内部整合发布系统和IM工具，比如使用QT工具。通过该工具，我们将向负责人发送链接以进行人工确认。重要的是，我们不仅仅是在发送消息后就开始提供服务下线，而是需要双向确认。当负责人点击链接确认后，将立即通过我们的平台调用发布系统的能力，将服务下线并立即通知负责人。这样做是为了确保服务的正常终止，同时及时通知负责人，以便他们可以采取后续措施。

原来是通过运行时去分析函数被调用次数。你们有没有遇到一年才运行一次的定时任务吗？这种代码会被误删吧，如果采用你们这种方法。

对于那些不经常执行的方法，例如一年执行一次，存在误删的可能性。为了降低这种误删的概率，可以采取以下措施：首先，尽量延长服务的运行时间，比如以月为维度运行35个月。如果一个方法在这段时间内没有被调用到，就可以认为它没有流量。其次，如果服务有很多这种一年运行一次的定时任务，并且业务非常重要，可以允许跳过服务而删除其他内容。

业务团队没有人力的时候公共支撑团队来支援，那公共支撑团队的工作量怎么管理和控制？

这个问题的关键在于，把工作量的目标给扩大化。比如：当酒店的团队需要承担50%代码量减少的目标，但缺乏人力时，我们需要寻找解决方案。如果自己的团队也很忙，可以考虑将酒店的指标拆分到其他业务团队上，例如主战团队或供应链四级团队。如果这些团队也难以完成指标，我们可以考虑让他们之间的兄弟团队分担一些任务。这可以是一种有效的方式，但具体情况需要根据实际情况来决定。如果公共执政团队有可用的人力资源，我们可以考虑派遣人力来支持，如果没有，我们也可以寻找其他解决方案。

SA技术进行跑数时，会不会存在可能影响线上服务的风险？

在SA进行跑数时，如果服务在线上运行且未进行下线，可能会导致几个问题。首先，存在STW的风险；其次，跑数时可能需要进行几分钟的SPW状态；最后，内存使用可能会飙升。因此，我们需要配合服务下线，将其下线后再进行跑数。这样做可以避免对线上服务造成风险。在跑数完成后，我们还可以采取一些措施，如进行上线前的检查或重新销毁并重新拉起服务，以确保完全零风险的情况。

对于长期跑数，每个月服务跑两个月，这个时间段是怎么确定的，然后在这个过程中怎么来确保数据的完整性和准确性？

每个服务的运行时间不是固定的两个月，而是根据业务特点自行决定。例如，对于不存在一年或一季度运行一次的方法的服务，如果一个月内没有运行记录，则视为废弃。因此，只需运行一个月。有些业务线为了稳定可能会选择多跑一些时间，比如跑五个月。这个时间还是需要根据业务自行控制。

关于如何确定时间段，大部分应用跑两三个月就可以进入删除阶段。至于如何保证数据的完整性和准确性，通过使用SA获取JVM数据的简洁代码，可以在写代码时测试是否存在bug。只要将运行结果原始数据保存到数据库中，后续的计算逻辑即使出现bug也可以基于原始数据进行重新计算，从而确保准确性。

除了无用的代码，相应的数据怎么删？谢谢

目前我们主要关注代码治理，我们认为线上代码消耗了资源，而数据本身是一种资产。在删除服务时，我们会删除服务对应的域名、机器和代码仓库，但数据会保留。默认情况下，数据会被标记为冷备，如果系统负责人确认这些数据没有用处，他们可以自行删除。因此，并非必须删除所有数据。

怎么推动业务接入？让业务敢用呀

因为我们这个项目是由基础架构组提出，我们用线上方法覆盖率、人均维护的app、人均维护的应用个数或代码行数等指标向老板阐述问题的存在，并说明预期的效果和能够带来的效率提升。在前期进行数据评估后，我们将数据和逻辑说服老板，并获得他的支持。一旦老板认同我们的数据和逻辑，他会为我们站台，并组织公司级别的启动会，以便让各个业务线的团队更容易支持我们的工作。这不仅是一种指标或压力，更是一种支持。

要推动业务团队敢于使用这个项目，我们可以先选择与我们技术架构、团队合作良好且频繁的团队作为试点，并逐步推广。一旦我们拿到试点团队的良好效果和无故障的数据，其他团队就会更容易接受。

这种方法不仅适用于瘦身项目，还可以用于推广新的工具。通过这种方式，我们可以逐步让团队敢于使用新工具。

精简中有没有出现过故障的问题，都是哪些情况导致的故障？能不能大概讲下，谢谢！

在过去的六个多月中，虽然故障存在，但影响较小，主要是P3-P4方面。这些故障主要由于代码很久才执行一次，在SA跑数期间，可能是时间段跑短了或者即使跑很长时间也未运行到该代码，导致误删并引发一些问题。然而，这些故障的发现时间可能会稍长，因为它们执行次数较少。另外，这些故障通常影响范围较小，因为它们是很久才执行一次。如果发生故障，业务线将承担责任，因为公共平台组提供的工具是让他们自行评估并选择运行时间。实际上，没有出现过大故障，业务线也未因故障而向我们抱怨。大多数问题都是小问题。