重度の遺伝を伴うアプリケーション。サポートまたは復元？

こんにちは、Habr！ 1月28日に開催された LuxoftTechFestで、LuxoftのシニアチームリーダーであるMikhail Zankovichが、深刻な遺伝を伴うアプリケーションについて話しました。今日、彼はこのレポートの内容に関係する追加の考えを共有し、それはミートアップ中に非常に白熱した議論を引き起こしました。



「私たちはレガシープロジェクトを持っています」というフレーズはあなたにどのような感情や連想を呼び起こしますか？ほとんどの場合-構造の欠如、混乱、大量の文書化されていないコード、ホラー、建築の無秩序、嫌悪感、松葉杖の海、あなたは走らなければなりません！私の感情：「ああ！最後に、何か面白いものがあります。それを機能させましょう！」これは非常に珍しい反応だと思います。

この記事では、レガシーを扱う別のイデオロギーを明らかにしようと思います。それを「ソフトウェア復元」と呼びましょう。レガシーに対するあなたの態度を変えるつもりはありませんが、少なくともレガシーが面白いかもしれないという疑いを植え付けることができれば、私は嬉しく思います。

典型的な遺産

レガシーとは何ですか？私の経験では、レガシー製品のコンプライアンスに関する次のチェックリストを作成できます。

• .
  
  .. , , .

• .
  
  , black-box. . .
• .
  
  , .
• .
  
  . / ..

これらすべてが、新しい機能や新しい要件を作成するのと同じように、リリースごとにそのようなプロジェクトを維持することがますます困難になるという事実につながります。変更は、必須の回帰テストなどを伴うリバースエンジニアリングに変わります。その結果、プロジェクトの維持に費用がかかり、変更を最小限に抑えて現在の形式で「凍結」されます。



しかし、なぜレガシー製品が登場するのでしょうか。



チームが意識的かつ意図的に低品質の製品を作成することはめったにありません。ほとんどの場合、これはプロジェクトの現在の状況によって制限された機会の結果です。



明確な要件はありません。アプリケーションの機能のバランスの取れた設計の可能性はありません。



絶えず変化する要件、不明確な定式化、タイトな実装タイムライン、絶えず増大する技術的負債は、これらの「アジャイル」アプローチに完全に適応できなかったチームのアジャイル開発プロセスの明らかな兆候です。そして、「柔軟」から「ビジネスからの急速に変化する要求」だけが機能します。



これは多くの場合、チーム内のローテーションの増加につながり、品質にプラスの影響を与えません。新しいスペシャリストがチームに加わったと想像してみてください。彼は2、3か月間だけプロセスを掘り下げ、その後1、5、2か月の間、ある種の機能を実装してプロジェクトを離れる準備をします。彼は、高品質の製品、自分の部分の完全な文書化、同僚への知識の移転などには興味がありません。専門知識が曖昧です。



ある時点で、致命的な決定が下されます。同行するよりも交換/電源を切る方が簡単です。そして、プロジェクトは「低メンテナンス」フェーズに入ります。残りのベースでサポートされると、変更を最小限に抑え、新しい要求を迅速に、しかし不十分に実装する追加の「松葉杖」を作成します。なぜ高品質なのですか？商品が変わります。このモードでは、製品は何年も生き残ることができ、「松葉杖」が生い茂り、より巨大になります。



上記のすべてを要約すると、レガシー製品が出現した主な理由は次のとおりです。

• 機能の実装の厳しい締め切り。
• 明確な要件の欠如/集中的に変化する要件;
• チーム内のローテーションの増加。
• ライフサイクルの不適切な計画。

ここに、現時点での専門家の専門能力開発のレベルを追加します。5年または10年前にプロジェクトを開きます。今は別の方法で実装する要素を簡単に見つけることができると確信しています。



したがって、私たちは公理として、「コードは本質的に悪いものとして作成されていない」と考えています。これは、どの製品にも何らかのアイデアがあったことを意味します。そして、コードが本番環境に移行した場合、それは機能し、当時のビジネスのニーズを満たしていました。

エスコートアプローチ

顧客側のタスクは非常に単純です。現在のビジネスプロセス（一部は一般に誰にも知られていません）を中断することなくレガシーを正常に機能させると同時に、予算に応じて新しい要件に従って機能を開発します。おそらく制限されています。



プロジェクトに着手するチームの典型的なアプローチは、ゆっくりと、しかし確実に事態を悪化させ続けることです。あまり触れないで、求められたものだけを変えてください。モジュールは機能するが、ロジックの変更が必要な場合（そのままにして、触れないでください）、必要なロジックを使用して別のモジュールを作成することをお勧めします。カオスが大きくなり、アプリがより複雑になります。

修復家のアプローチ

ソフトウェア復元機能のアプローチは、その前にどのようなメカニズムがあるかを把握することです。その作成者の背後にある主なアイデアは何でしたか。不要なものはすべて切り取り、最善を尽くしてください。既存の構造を変更する場合は、細部に非常に注意して注意を払っています。システムに影響を与える単一の詳細を修復家の視点から隠すべきではありません。導入された変更は、最初にメンテナンスロジックに従って実行され、次に分析が行われて、本格的なソリューションを実装する可能性が判断されます。



これは困難で時間のかかる仕事です。すべての開発者が喜んで、そして最も重要なことに、本当に復元を行うことができるわけではありません。修復家のレベルの要件は、通常の開発者よりも桁違いに高くなっています。実際のプロジェクトでの経験がなければ、システムがどのように開発できるかを理解せず、実際の最良のアプローチと衝突するだけでなく、明らかに失敗した実装とも衝突することなく、復元する意味はありません。

典型的な最初の衝動の代わりに「はい、これらは松葉杖です！ここですべてを書き直す必要があります！」 -真の修復家は、「なぜこのように行われたのですか？どのくらい正確にそれを使用する予定でしたか？」そして、そのようなコードを作成するための明白な前提条件がないことを確認した後でのみ、修復家は次のように叫ぶことができます。「はい、これらは松葉杖です！ここですべてを書き直す必要があります！」そして達成感を持って、彼はソフトウェアの骨化したフレームワークの不必要な成長を本当に打ち破り、復元の対象をより良く、より高品質にすることができます。



しかし、これはめったに起こりませんが、修復家に何とも言えない喜びを与えます。ほとんどの場合、異なるモジュール間の依存関係のもつれを解く必要があります。分解されるコンポーネント（場合によってはシステム）の責任範囲をはるかに超えてスレッドが伸びることは珍しいことではありません。また、復元するときは、モジュール関係のこれらすべての複雑さを考慮に入れる必要があります。







したがって、ソフトウェア修復家は、開発、アーキテクチャ、ビジネス分析、テスト、および医学の交差点で機能します。そして、指定された分野のどのスキルが最優先であるかを言うのは難しいです。修復に従事したいという正直な願望で味付けされた、それらの間には一定のバランスがなければなりません。薬はそれと何の関係がありますか？したがって、復元の主な原則は「primum non nocere」です。まず、害を及ぼさないでください。



実際、このアプローチは特定の例でさらに検討され、システムの以前の技術所有者から継承された典型的なレガシーを徐々に分解して復元します。そして、具体的な例を挙げて、上記のスキルがすべて重要である理由を見てみましょう。

データウェアハウスの復元

システムは何を保存しますか？



新しいプロジェクトに着陸すると、修復家はシステムによって処理されたオブジェクトに注意を払います。特に通常のドキュメントがない場合に、ビジネスフローとソースコードに完全に没頭するには、少なくとも数か月かかります。



復元者の最初のタスクの1つは、ボールトの有効性を評価することです。ビジネスプロセスの理解に頼らずに何かを改善できますか？データウェアハウスの典型的な問題点は、主にこのデータの量に関連しています。ボリュームが大きいほど、システムの所有コストが高くなります。



2番目の問題点は、このボリュームの増加です。これは、そもそもシステムのパフォーマンスに悪影響を及ぼします。ほとんどの場合、システムに情報を保持するためのいくつかのプラクティスがすでにありますが、それらはどの程度効果的ですか？



ここで検討するすべてのプラクティスは、従来のRDBMSにより適していますが、アプローチはSQLなしのソリューションでもそれほど変わりません。



この方向での修復家の主な戦術の1つは、情報ストレージオブジェクトの監視の作成です。従来のDBMSの場合、テーブルの監視。



システムメタデータが2つの些細なパラメータ（データの量と各テーブルの要素の数）に関するデータを定期的に収集できるようにするフレームワークが必要です。周波数は、システムの特性に基づいて手動で選択する必要があります（これについては以下で詳しく説明します）。基本的な分析には、通常の起動時間である24時間で十分です。



データの分析データを



どうするか？何を探すべきですか？最初の瞬間は、最も「重い物体」を特定することです。実際には、標準の20/80ルールが機能します。オブジェクトの20％以下が、スペースの80％以上を使用します。これにより、最初の段階で分析の領域を大幅に絞り込むことができます。



このような統計がより長く、より詳細に蓄積されるほど、システムの動作がより明確に反映されます。経験上、推奨期間は少なくとも2週間です。主なアイデアは、情報のクリーニングとアーカイブのメカニズムが最も頻繁に実装される非稼働日/期間を「フック」することです。



それで、フレームワークが書かれ、修復家は2週間結果を待ちますか？もちろん違います。それは修復家のイデオロギーと戦うものではありません。データの最初のチャンクが手元にあれば、いくつかの基本的な分析を行うことができます。つまり、格納されているオブジェクト（行）の数に対する占有スペースの比率を確認します。この値が大きいほど、BLOBフィールドがここに格納される可能性が高くなります。そして、これらのテーブルとフィールドだけが、修復家の調査と分析の対象になります。



重要な質問：ビジネスプロセスが実際にこれらのオブジェクトにアクセスする頻度はどれくらいですか？システムの所有者である既存のチームは、そのような点に光を当てることができます。そして突然（そして実際には非常に頻繁に）、そのようなフィールドにはビジネスにとって重要ではない情報が格納されていることがわかりました：開発チームによる分析のためのオブジェクト/メッセージのダンプ、注文の作成時にのみ表示されるユーザーコメントなど。



次のステップ：データが頻繁に使用されない場合、または明確なビジネス価値がない場合は、データをアーカイブに移動してみませんか？同時に、モノリシックテーブルをパーツに分割し、blobをより安価で低速なメディアに移動すると同時に、テーブルの元のインターフェイスを維持するという基本的なアプローチ（要点は、すべてに関する信頼できる情報がないことです）この情報にアクセスするプロセスは、変更がそれらに害を及ぼすべきではないことを意味します）-非常に興味深く複雑な技術的問題になる可能性があります。



あまり面白くはありませんが、同様に役立つタスクは、組み込みのデータストレージシステムを使用して特定のフィールドの値をアーカイブすることです。たとえば、Sybase ASEにはASE_Compression機能があり、MongoDBではコレクションの圧縮オプションを設定できます。ほとんどすべてのデータストレージシステムには、「内部」で追加のデータ圧縮のオプションがあります。この機能は外部システムに対して透過的に機能し、大幅な変更は必要ありません。実際には（特にレガシーシステムでは）、このようなデータ圧縮オプションはデフォルトでは使用されません。



もちろん、圧縮を適用する場合、修復家は最初にアプローチがパフォーマンスに与える影響を評価する必要があります。そのためには、システムの主要業績評価指標を検討する必要があります。極端な場合は、回帰テストの要素が存在する必要があります。



一般に、オブジェクトに関する完全な統計が収集されている間、数週間は何かすることがあります。



大きな統計：何を探すべきか



長期間にわたって統計を受け取った修復家は、使用された空間のダイナミクスで何が起こっているのかを理解しようとします。 1つのテーブル/オブジェクトのすべての値は元の値に正規化されます。これにより、データの相対的な増加を正確に推定し、最も集中的に変化するオブジェクトを特定することが可能になります。



生成されたプロファイルは、ほとんどの場合、次のタイプのいずれかに対応し ます。







プロファイル1-定数値。ほとんどの場合、これらは静的ディレクトリであり、それらを操作することはそれほど面白くありません。上記のアーカイブアプローチは、ディレクトリの使用強度に基づいて適用できます。



ボリュームの小さな変動- プロファイル2-データの読み取り/書き込みが集中する参考書と運用表の両方について話すことができます。これらは修復家の観点から最も難しいオブジェクトです。それらの振る舞いを可能な限り詳細に分析する必要があります。これらのオブジェクトの場合、情報収集の頻度を増やすことが理にかなっています。1日1回ではなく、1時間に1回、1分に1回です。主な目標は、プロファイルの変更をより詳細に追跡し、動作の依存関係を理解することです。



プロファイル3と4の方が興味深いです。 プロファイル3（「Saw」）は、このテーブルが定期的にクリアされることを明確に示しています。しかし、増加傾向（洗浄後は毎回、最終的な量が以前よりもわずかに大きくなっています）は、既存の洗浄メカニズムの非効率性を物語っています。それら。特定の期間にわたって、期間の終わりに削除されるよりも多くのデータがシステムに表示されます。これは完全に通常のビジネスプロセスであり、システムの負荷が古典的に増加する可能性があります。



しかし、修復家にとって、これはまず第一に、シグナルです。情報を削除するための条件はありますか？慣例に基づいて、システム内のデータ保持の複雑な条件のために、おそらく一部のエンティティは、ストレージに永久に不当に残ります。復元者の目標は、そのようなエンティティを識別し、それらを定期的なアクティビティに含めることです。

プロファイル3が一定の成長に退化する場合、これはシステムのボトルネックの最初の候補です。第一に、アーカイブプロセスへの明示的なポインタがなく、第二に、データの増加に伴ってパフォーマンスの低下が予想されます。



プロファイル4-定期的なデータ入力を伴うアーカイブテーブルの典型的な例。テーブルの増加は特定の日にのみ発生することに注意してください。3番目のプロファイルのテーブルとの相関が顕著になる可能性は十分にあります。アーカイブテーブルの場合、それらの使用の原則を理解することも重要です-ユーザーからの呼び出しはありますか？それとも分析する話ですか？それとも、レポートシステムのデータですか？これらの質問への回答によっては、アーカイブテーブルを別の回路、別のベース、別のセクションに分割することが決定される可能性があります。したがって、運用スペースを解放します。

実際にはどのように機能しますか？

あるプロジェクトでは、プロジェクトに参加してから最初の1か月半で同様の演習が行われました。ターゲットとなったのはプロファイルNo.3のオブジェクトであり、それらが見つかりました。説明されている方法の適用（クリーニング条件の改善）、システム内で使用されなかったデータの削除など。占有スペースの量を25％以上削減し、ストレージの集中的な増加を阻止することができます。



その結果、プロジェクトに最初の技術的変更を加え、機能を改善するための計画を提出することができました。顧客はチームの結果に満足し、3人から9人の開発者に拡大しました。年間を通じて調査を継続し、機能の向上点を活用してシステムとその特性をサポートしました。



2人のアナリストが追加されたため、チームは独自の開発に取り組み始めました。サポートではなく、新しいビジネス機能の実装です。現在、新しいシステムを開発しています。

これは何のためですか？

ここまで読んだことがあるなら、おそらく「なぜこれがすべてなのか」という質問に対する答えを探しているでしょう。まず第一に、復元は、開発ではなく、サポートではなく、それらを組み合わせた別個のプロセスです。



これは、技術スペシャリストにとっては別の目的です。この製品を作成した人の論理を掘り下げ、その意味を理解し、不要なものから製品を浄化し、以前よりもさらに良くするためです。アプリはクエストのように見え、多くの謎と未知のプロットのねじれがあります。

いいえ、最初から作成しているのではなく、既存の製品を復元していますが、時間の経過とともに破壊されている可能性があります。とりわけ、修復家は、実際の製品をテストベースとして手元に置きながら、6つの方向のいずれかにポンプで送るユニークな機会があります（上の写真を参照）。技術的な完璧主義に陥るのではなく、プロセスの改善という観点からシステムに必要な変更のみを考えて行うために、自制心も高まります。



これらすべてが、レガシーシステムでの作業をエキサイティングで珍しいものにします。しかし、復元または維持するための最終的な選択はあなた次第です。



LuxoftTechFestでのMikhailZankovichのレポートはここで見ることができます。



記事の著者はミハイル・ザンコビッチですミハイルザンコビッチ