你好！ 我叫 Pasha Chernyak，是 QIWI 的一名领先开发人员，今天我想谈谈不可避免的事情。 关于遗产。
让我们从一个问题开始：什么是遗留服务？ 遗留服务是开发人员一周/一个月/一年没有接触过的服务吗？ 或者它是由经验不足的程序员编写的服务，例如由您专门编写，但一年前？ 现在你变得更酷、更有经验了。 或者旧服务是您决定不再提交并正在慢慢准备替代品的服务吗？ 无论如何，让这样的服务无人看管并且不更新是一颗定时炸弹，以后可能会爆炸。
在继续讨论 QIWI 如何使用我们的旧版服务之前，我将告诉您我们如何为电子钱包中的服务带来秩序。 两年来我一直对其性能负责。 如果有任何问题，他们总是先给我打电话。 我通常没有勇气在晚上 11 点给别人打电话，所以我不得不坐下来弄清楚我们域上的所有服务。
但我和任何人一样，喜欢在晚上睡觉，所以我试图应对这种剥削：“伙计们，你们为什么打电话给我？” 我收到了一个相当简洁的回答，比如“还有谁？” 因为我负责维修服务，而这些人根本不知道该给谁打电话。
因此，在钱包后端团队的一次回顾会上，我们决定需要制作一个标志，其中包含我们的服务、微服务和钱包整体以及负责它们的人员的列表。 在合理范围内，标志通常是有用的。
除了有关谁负责什么的信息之外，还提供了以下问题的答案：谁是服务的所有者，谁负责其开发、架构和生命周期。 负责这项服务的人是在发生问题时能够修复它的人。 服务的所有者有权在提交中留下+2，负责人也必须在该服务接受新提交之前参加审核。
随着时间的推移，新的实践开始被应用，例如迁移到 Kubernetes、各种 checkstyle、spotbugs、ktlint、Kibana 中日志的存在、自动发现服务而不是直接指定地址和其他有用的东西。 无论在哪里，我们的餐桌都让我们能够保持服务的相关性。 对我们来说，这是一种清单，表明该服务可以做到这一点，但目前还没有。但我们继续前进，意识到我们缺乏有关我们的服务的信息，我们监控这些信息，服务源位于哪里， TeamCity 中组装任务的启动位置、部署方式、端到端测试源的存储位置、有关架构和决策的整理会议的照片。 理想情况下，我希望所有这些信息都放在某个地方并在需要时触手可及。 于是，我们的标牌就成了寻找信息的起点。
但QIWI虽然保留了初创公司的精神，但却是一家大公司。 我们已经12岁了，团队正在发生变化：有人离开，有人进来，新的团队组建。 我们在我们继承的领域中发现了一些服务。 有些来自其他团队的开发人员，有些只是以某种方式与钱包间接相关，所以我们现在在我们的资产负债表上拥有该服务。 了解它的工作原理和原理 - 为什么？ 服务有效，我们的产品功能肯定需要改进。
它是如何发生的
但在某个时间点，我们发现服务停止执行其功能，有些东西坏了 - 在这种情况下该怎么办？ 该服务只是停止工作了。 完全没有。 我们首先偶然发现了这一点，其次是六个月后。 它发生了。 我们唯一知道的是服务将部署在哪些虚拟机上，其源位于哪里，仅此而已。 我们进行了 git 克隆并深入了解了几年前写这篇文章的人的想法，但我们看到了什么？ Spring Boot 没有一个是我们熟悉的，虽然我们已经习惯了一切，但我们有完整的堆栈等等。 也许那里有一个 Spring 框架？ 但不是。
写这一切的人很坚强，并且用纯 Java 编写了所有内容。 开发人员没有常用的工具，一个想法出现了：我们需要重写这一切。 我们有微服务，每台烤面包机都会发出常见的“伙计们，微服务就是你们所需要的！” 如果突然出了什么问题，你可以平静地接受任何语言，一切都会好起来的。
问题是现在我们没有客户负责这项服务。 他有什么业务需求，这个服务应该做什么？ 该服务紧密集成到您的业务流程中。
现在告诉我，在不了解服务的业务需求的情况下重写服务有多容易？ 目前尚不清楚该服务是如何记录的；是否有指标也未知。 它们到底是什么，如果有的话，更是未知。 同时，该服务包含大量难以理解的业务逻辑类。 有些东西包含在某种数据库中，而我们对此一无所知。
什么开始？
从最合乎逻辑的角度来看——测试的可用性。 通常至少有一些逻辑写在那里，你可以对正在发生的事情得出结论。 现在TDD很流行，但我们看到5年前一切都和现在几乎一样：几乎没有单元测试，它们根本不会告诉我们任何东西。 好吧，也许除了某种验证之外，某些 xml 是如何使用某些自定义证书进行签名的。
我们从代码中看不懂任何东西，所以我们去看看虚拟机里有什么。 我们打开服务日志，发现其中有一个http客户端错误；嵌入在应用程序资源中的自签名证书已经无耻地腐烂了。 我们联系了我们的分析师，他们要求提供新证书，并将其颁发给我们，服务又恢复正常了。 似乎仅此而已。 或不？ 毕竟，该服务可以正常工作，它可以执行我们业务所需的某些功能。 我们有一定的应用程序开发标准，您很可能也有。 例如，不要将节点上的日志存储在文件夹中，而是将它们存储在某种存储中，例如elastic，并在Kibana中查看它们。 您还可以记住黄金指标。 也就是服务的负载，服务的请求数量，他是否还活着，他的HealthCheck进行得怎么样。 至少，这些指标将帮助您知道何时可以问心无愧地停止使用它，并像一场噩梦一样被遗忘。
怎么办
因此，我们将这样一个旧服务添加到表中，然后我们从开发人员中寻找负责该服务的志愿者并将其按顺序排列：他们将至少编写一些有关该服务的信息，添加链接grafana 中的仪表板，能够组装任务，并了解如何部署应用程序，不要使用 ftp 手动上传文件。
最主要的是所有这些有用的志愿者活动需要多长时间？ 例如，在 20% 的技术债务期间，为经验丰富的开发人员进行一次冲刺。 需要多长时间才能理解与某个国家系统通信的所有根深蒂固的逻辑并将其引入更新的技术？ 我不能保证这一点，也许是团队一个月或两个月的工作。 我这样说是根据当前与一些新服务集成的经验。
同时，商业价值也没有释放。 完全没有。 雇用服务来提供支持并花一些时间是很正常的。 但在我们的标准与服务共舞之后，我们将其添加到表中，添加了有关它的信息，也许有一天会重写它。 但现在它符合我们的服务标准。
因此，我想提出一个如何处理遗留服务的计划。
从头开始重写遗产是一个坏主意
说真的，你甚至不必考虑它。 很明显我会喜欢它，而且有一些好处，但通常没有人需要它，包括你自己。
目录
挖掘应用程序的源代码，制作一本参考书，其中将说明其内容和工作方式，在那里输入项目的描述（条件 readme.md）以快速了解日志和指标的位置。 稍后处理此事的开发人员只会说谢谢。
了解域
如果您拥有域名，请尝试随时掌握最新动态。 是的，这听起来微不足道，但并不是每个人都确保服务位于单个密钥中。 但使用一种标准实际上要容易得多。
只有注册用户才能参与调查。 拜托
你如何处理你的遗产？
-
31.5%我从头开始重写，更正确12
-
52.6%和你几乎一样20
-
10.5%我们没有遗产，我们很棒4
-
5.2%我会写在评论里2
38 位用户投票。 20 名用户弃权。
来源： habr.com