你好 我叫Pasha Chernyak，我是QIWI的主要开发人员，今天我想谈谈不可避免的问题。 关于旧版。
让我们从一个问题开始：什么是旧版服务？ 旧版服务是开发人员一周/月/年都未曾使用过的服务吗？ 还是它是由经验不足的程序员（例如，特别是您）一年前编写的服务？ 现在，您变得更酷，也更有经验。 或者，毕竟，旧版服务是您决定不再提交并正在慢慢为其准备替代品的服务吗？ 无论如何，让该服务无人值守并且不进行更新是一个定时炸弹，以后可能会爆炸。
在继续介绍我们如何使用QIWI中的旧版服务之前，我将告诉您我们如何将钱包中的服务与事物保持一致。 两年来，我一直对其性能负责。 如果有任何问题，他们总是先给我打电话。 我通常不敢在晚上11点打电话给其他人，因此我不得不坐下来了解我们网域的所有服务。
但是我和任何人一样，喜欢晚上入睡，所以我尝试处理该手术：“伙计，你为什么给我打电话？” 他收到了一个简明扼要的回答：“还有谁？” 因为我正在维修服务，所以伙计们只是不知道该给谁打电话。
因此，在电子钱包后端团队的回顾中，我们决定需要编译一个板，上面写有我们的服务，微服务和钱包整体以及负责这些服务的列表。 片剂在一定程度上通常是有用的。
除了关于谁负责什么的信息外，还有以下问题的答案：谁是服务的所有者，谁对服务的开发，架构和生命周期负责。 负责此服务的人员是可以在发生某些情况时对其进行维修的人员。 服务的所有者有权在提交中保留+2，在此服务接管新的提交之前，负责人员还必须在审核中出现。
随着时间的流逝，开始采用新的做法，例如，迁移到Kubernetes，各种checkstyle，spotbug，ktlint，kiban中存在日志，自动发现服务，而不是直接指定地址和其他有用的东西。 桌子的每一个角落都使我们能够保持服务的相关性。 对我们来说，这是一个清单，表明该服务知道如何执行此操作，但还没有，但是我们走得更远，意识到我们缺少有关服务的信息，因此我们要跟踪服务源代码的位置，在TeamCity中启动组装任务的位置，部署方式，存储end2end测试的源代码的位置，整理有关架构和决策的照片。 理想情况下，我希望所有这些信息都放在某个地方，并在需要时随时提供。 因此，我们的盘子已经成为寻找信息的出发点。
但是，QIWI在保留创业精神的同时，还是一家大公司。 我们已经12岁了，并且团队正在发生变化：人们正在离开，人们来了，正在组建新的团队。 我们在我们的域中发现了一些我们继承的服务。 其他团队的开发人员带来了一些东西，某种程度上与电子钱包间接相关，因此该服务现在已在我们的资产负债表上。 处理什么以及如何工作-为什么？ 该服务有效，并且我们必须删除产品功能。
碰巧
但是在某个时间点，我们发现该服务停止履行其功能，出现了问题-在这种情况下应该怎么办？ 该服务刚刚停止工作。 绝对是 我们首先是偶然地了解到的，其次是六个月后。 它发生了。 我们唯一了解的是服务部署在哪个虚拟机上，其来源在哪里，仅此而已。 我们制作了git clone，并投入了几年前写这本书的人的想法，但是我们看到了什么呢？ 尽管我们已经习惯了所有内容，但是我们拥有完整的堆栈，因此我们没有熟悉过Spring Boot。 也许有一个Spring框架？ 但是没有
编写所有这些内容的人很苛刻，并且用纯Java编写了所有内容。 对于开发人员来说，没有熟悉的工具，并且产生了想法-有必要重写所有内容。 我们也有微服务，并且从每个烤面包机中我们都听到熟悉的“伙计们，微服务是您所需要的！”。 如果突然出现问题，您将冷静地使用任何语言，一切都会好起来的。
问题是现在我们没有客户负责这项服务。 他的业务要求是什么，该服务通常应做什么？ 并且该服务已紧密集成到您的业务流程中。
现在告诉我，在不知道服务需求的情况下重写服务有多容易？ 该服务不清楚如何记录；是否存在度量标准尚不清楚。 它们的含义（如果有的话）更加未知。 在服务中，有许多类的晦涩的业务逻辑。 某种数据库中包含某些内容，对此我们还一无所知。
从哪里开始？
从最合乎逻辑的-具有测试的可用性。 通常至少在其中编写某种逻辑，并且可以得出关于正在发生的事情的结论。 现在TDD很流行，但是我们看到5年前的一切几乎都和现在一样：几乎没有单元测试，而且它们绝对不会告诉我们任何事情。 好吧，也许除了某种检查用某种自定义证书如何签名某些xml之外。
我们对代码一无所知，我们送去看看那里有什么虚拟机。 我们打开了服务日志，发现其中有一个http-client错误，这是一个自签名证书，被缝到了应用程序的资源中，被人无理地犯规。 我们联系了我们的分析师，他们要求提供新证书，然后将其颁发给我们，然后服务可以再次使用。 似乎就这些了。 还是不行 该服务仍然有效，它执行我们业务所需的某些功能。 我们有一些您最可能拥有的应用程序开发标准。 例如，不要将日志存储在文件夹中的节点上，而是以某种存储方式（例如弹性）存储，然后在kiban中查看它们。 您可以回忆起黄金指标。 也就是说，服务的负载，对服务的请求数（无论他是否还活着），他的HealthCheck进行得如何。 至少，这些度量标准将帮助您找出何时可以将其停用和遗忘，就像一个怀着良心的坏梦一样。
怎么办
因此，我们在平板电脑上添加了这样的旧服务，然后我们从需要照顾该服务的开发人员中寻找志愿者并对其进行整理：他们将至少编写有关该服务的信息，将链接添加到graphan的仪表板，组装任务中，并了解如何部署应用程序，不要用手使用ftp上传文件。
最主要的是，这些有用的志愿服务将花费多少？ 例如，在20％的技术债务期间，为经验丰富的开发人员提供了一次冲刺。 而且，要花多少时间才能了解与某个状态系统进行通信的所有根深蒂固的逻辑，并将其引入新技术？ 我不能保证这个，也许一个月，或者两个团队合作。 我是从当前与一些新服务的集成经验中说的。
同时，业务价值无穷无尽。 绝对是 接受支持服务并花一些时间是正常的。 但是，在我们与服务进行标准的交互之后，我们将其添加到表中，添加了有关该信息的信息，也许有一天我们将对其进行重写。 但是现在它已经达到我们的服务标准。
因此，我想将与旧版服务有关的计划纳入计划。
从头开始重写旧版是一个坏主意认真地说，您甚至不必考虑它。 显然，我们希望这样做，并且可以看到一些优点，但是通常这对于包括您自己在内的任何人都是不必要的。
参考书挖掘应用程序的源代码，创建一个目录，以指示其位置，位置以及工作方式，然后在其中输入项目说明（条件为readme.md）以快速了解日志和度量标准的位置。 在您处理之后将对此进行处理的开发人员只会说谢谢。
了解领域如果您拥有一个域，请尝试保持同步。 听起来很老套，是的，但是并不是每个人都确保服务都在一个键中。 但是按照一种标准工作实际上要容易得多。