インフラストラクチャ内のレガシー サービス

こんにちは！ 私の名前は Pasha Chernyak です。QIWI の主要な開発者です。今日は避けられないことについて話したいと思います。 レガシーについて。

まずは「レガシー サービスとは何ですか?」という質問から始めましょう。 レガシー サービスとは、開発者が XNUMX 週間、XNUMX か月、または XNUMX 年間触っていないサービスですか? それとも、それは経験の浅いプログラマー、たとえばあなたが XNUMX 年前に書いたサービスですか? そして今、あなたはよりクールになり、より経験豊富になりました。 それとも、レガシー サービスは二度とコミットしないと決めていて、それに代わるものを徐々に準備しているサービスなのでしょうか? いずれにせよ、このようなサービスを更新せずに放置することは、後で爆発する可能性のある時限爆弾です。

QIWI がレガシー サービスとどのように連携しているかに進む前に、ウォレット内のサービスにどのように秩序をもたらしたかについて説明します。 私は 11 年間、そのパフォーマンスを担当してきました。 何か問題があれば、彼らはいつも最初に私に電話します。 私は通常、午後 XNUMX 時に他の人に電話する勇気がないので、座ってドメイン上のすべてのサービスを把握する必要がありました。

しかし、私は他の人と同じように夜寝るのが好きなので、「みんな、なぜ私に電話をかけてくるのですか？」という搾取に対処しようとしました。 それに対して、「他に誰がいますか？」という非常に簡潔な答えが返されました。 なぜなら、私はサービスを修理しているのですが、彼らは誰に電話すればよいのかわからないからです。

したがって、ウォレット バックエンド チームの回顧展の XNUMX つで、サービス、マイクロサービス、ウォレット モノリスとそれらの責任者のリストを記載した看板を作成する必要があると判断しました。 標識は一般に、妥当な範囲内で役に立ちます。

誰が何を担当するかに関する情報に加えて、サービスの所有者は誰なのか、サービスの開発、アーキテクチャ、ライフサイクルの責任者は誰なのかという質問に対する答えもありました。 このサービスの責任者は、何かが起こった場合にそれを解決できる人です。 サービスの所有者はコミットに +2 を残す権利を持ち、このサービスが新しいコミットを受け入れる前に責任者もレビューに出席する必要があります。

時間が経つにつれて、Kubernetes への移行、あらゆる種類のチェックスタイル、スポットバグ、ktlint、Kibana でのログの存在、アドレスやその他の便利なものを直接指定する代わりの自動検出サービスなど、新しいプラクティスが適用され始めました。 そして、テーブルのどこにいても、サービスの関連性を維持することができました。 私たちにとって、これは、このサービスでこれができるが、まだできていないという一種のチェックリストです。しかし、サービスに関する情報、監視している情報、サービス ソースの場所が不足していることに気づき、次に進みました。 TeamCity でアセンブリ タスクが起動される場所、その展開方法、end2end テストのソースが保存される場所、アーキテクチャに関するグルーミング セッションの写真、行われた決定について。 理想的には、これらの情報はすべてどこかに保管しておいて、必要なときにすぐに利用できるようにしたいと考えています。 したがって、私たちの看板は情報を探すための出発点となりました。

しかし、QIWI はスタートアップの精神を保っていますが、大企業です。 私たちはすでに 12 年を迎えており、チームは変化しています。人が去り、人が来て、新しいチームが結成されています。 そして、私たちが継承したドメイン上でいくつかのサービスを発見しました。 他のチームの開発者から提供されたものもあれば、ウォレットに何らかの形で間接的に関連したものもありました。そのため、現在ではバランスシートにサービスが載っています。 何がどのように機能するのかを理解する - なぜ? サービスは機能していますが、製品の機能には改善が必要な点があります。

それがどのように起こるのか

しかし、ある時点で、サービスがその機能の実行を停止し、何かが壊れていることがわかります。そのような状況ではどうすればよいでしょうか? サービスは単に動作を停止しました。 まったく。 そして私たちはこのことを第一に偶然、第二に半年後に知りました。 それは起こります。 私たちが知っていた唯一のことは、サービスがどの仮想マシンにデプロイされるか、そのソースがどこにあるか、それだけでした。 git clone を実行して、数年前にこれを書いた人の頭の中を覗いてみると、何が見えてくるでしょうか? 私たちにとって馴染みのある Spring Boot はどれもありません。すべてに慣れていますが、フルスタックなどすべてを持っています。 たぶんそこに Spring Framework があるでしょうか? しかし、そうではありません。

これをすべて書いた人はタフで、すべてを純粋な Java で書きました。 開発者にとって通常のツールは存在しないため、これをすべて書き直す必要があるというアイデアが生まれます。 私たちにはマイクロサービスがあり、どのトースターからも「皆さん、マイクロサービスこそが必要なのです！」というお決まりの声が聞こえてきます。 突然何か問題が起こった場合でも、落ち着いてどの言語でも対応でき、すべてがうまくいきます。

問題は、現在、このサービスを担当する顧客がいないということです。 彼にはどのようなビジネス要件があり、このサービスは何をすべきでしょうか? また、このサービスはビジネス プロセスに緊密に統合されています。

では、ビジネス要件を知らずにサービスを書き直すことがどれほど簡単なのか教えてください。 サービスがどのように記録されるかは不明であり、メトリクスがあるかどうかも不明です。 存在するとしても、それらが何であるかはさらに不明です。 そして同時に、このサービスには理解できないビジネス ロジックのクラスが膨大に含まれています。 ある種のデータベースに何かが含まれていますが、それについてもまだ何もわかっていません。

何を始めると？

最も論理的な点から言えば、テストの利用可能性です。 通常、そこには少なくとも何らかのロジックが書かれており、何が起こっているのかについて結論を引き出すことができます。 今では TDD が流行していますが、5 年前はすべてが現在とほぼ同じだったことがわかります。単体テストはほとんどなく、何も教えてくれません。 まあ、おそらく、ある XML がカスタム証明書でどのように署名されるかという、ある種の検証を除いては。

コードからは何も理解できなかったので、仮想マシンの内容を確認してみました。 サービス ログを開いたところ、http クライアント エラーが見つかりました。アプリケーション リソースに埋め込まれていた自己署名証明書は、恥知らずにも壊れていました。 私たちはアナリストに連絡し、新しい証明書を要求したところ、それが発行され、サービスは再び動作しました。 それだけだと思われるでしょう。 か否か？ 結局のところ、サービスは機能し、ビジネスに必要な機能を実行します。 私たちはアプリケーション開発に関する特定の標準を持っており、おそらくあなたもそれを持っているでしょう。 たとえば、ノード上のログをフォルダーに保存せず、エラスティックなどの何らかのストレージに保存し、Kibana で確認します。 ゴールデンメトリクスを覚えておくこともできます。 つまり、サービスの負荷、サービスへのリクエストの数、彼が生きているかどうか、彼のヘルスチェックの状況です。 少なくとも、これらの指標は、明確な良心を持ってサービスを停止し、悪い夢のように忘れられる時期を知るのに役立ちます。

何をすべきか

したがって、そのような古いサービスをテーブルに追加し、そのサービスを管理して整理してくれるボランティアを開発者の中から探します。彼らは、サービスに関する少なくともいくつかの情報を書き、へのリンクを追加します。 Grafana のダッシュボード、タスクの組み立て、およびアプリケーションのデプロイ方法を理解するには、ftp を使用してファイルを手動でアップロードしないでください。

重要なのは、この有益なボランティア活動にどれくらいの時間がかかるかということです。 たとえば、技術的負債が 20% あるときの、多かれ少なかれ経験豊富な開発者の XNUMX つのスプリント。 特定の国家システムとの通信に根付いたロジックをすべて理解し、それを新しいテクノロジーに導入するのにどれくらい時間がかかりましたか? これについては保証できませんが、チームの作業に XNUMX か月か XNUMX か月かかる可能性があります。 私はこれを、いくつかの新しいサービスとの現在の統合の経験から言います。

同時に、ビジネス価値は解放されません。 まったく。 サポートのためにサービスを雇って、それに少し時間を費やすのが一般的です。 しかし、私たちの標準的なサービスと踊った後、それをテーブルに追加し、それに関する情報を追加し、おそらくいつか書き直すでしょう。 しかし、現在では当社のサービス基準を満たしています。

その結果、レガシーサービスをどうするかという計画を立てたいと思っています。

レガシーをゼロから書き直すのは悪い考えだ
真剣に、それについて考える必要さえありません。 私がそれを望んでいることは明らかですし、いくつかの利点もありますが、通常は、あなた自身を含め、誰もそれを必要としません。

ディレクトリ
アプリケーションのソース コードを掘り出し、何がどこにあり、どのように機能するかを示す参考書を作成し、そこにプロジェクトの説明 (条件付き readme.md) を入力して、ログとメトリクスがどこにあるかをすぐに理解します。 あなたの後にこれに対処する開発者は、ありがとうと言うだけです。

ドメインを理解する
ドメインを所有している場合は、最新情報を常に把握するようにしてください。 確かに些細なことのように思えますが、誰もがサービスが単一のキーにあることを確認しているわけではありません。 しかし、実際には、XNUMX つの標準で作業する方がはるかに簡単です。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

あなたは自分の遺産をどうしますか？

• 視聴者の３８%が一から書き直してます、12のほうが正しいです

• 視聴者の３８%があなたとほぼ同じです20

• 視聴者の３８%が私たちには遺産はありません、私たちは素晴らしいです4

• 視聴者の３８%がコメントに書きます2

38 人のユーザーが投票しました。 20名のユーザーが棄権した。

出所： habr.com