光電効果 多くの金属が光を当てると電子を放出するという観察結果です。 物理法則ではありませんが、大規模なアプリケーションは、観察して光にさらしたときに金属のように動作する傾向があります。 しばしば呼ばれる小さな粒子 サービス指向アーキテクチャー（SOA）コンポーネント or マイクロサービスは、観測への応答としてモノリシックソフトウェアから放出されます。
微妙な物理学の比喩で十分です！ テクノロジーの世界は、モノリシックアプリケーションからマイクロサービスへと移行しています。 すべてのように、マイクロサービスアーキテクチャにはいくつかのトレードオフが伴います。 モジュール性の向上、展開の容易さ、およびアプリケーションレベルの堅牢性の向上という利点は、運用の複雑さを犠牲にしてもたらされます。 サービス指向アーキテクチャーに移行するときに答えるのが最も難しい質問のXNUMXつは、「この新しいサービスは適切に機能していますか？」という最も重要なことです。
開発から運用へのハンドオフ中に重要なメトリックが注意深く明示的に伝達されない限り、監視を構成するには、新しいコンポーネントに関する深い知識が必要です。 このハンドオフを処理する機会は数多くあります。そのため、電子（SOAサービス）が適切なエネルギーで寿命を迎えることを確認するために必要な推奨事項をいくつか示します。
1）すべての新しいコンポーネントを監視する必要があります– LogicMonitorの用語では、それらは関連付けられている必要があります データソース。 これらのデータソースには、開発によって構成された重要なメトリックとしきい値が含まれている必要があります。 一般的に言えば、アプリケーション固有のヘルスメトリックを可視化できる唯一のグループは開発です。 彼らは、何かが起こった場合、オンコールチームに適切に通知されることを確認する必要があります。
2）新しいコンポーネントのデータソースはダッシュボード（少なくとも概要ダッシュボード）に表示する必要があります。 これらのダッシュボードは、開発と運用の間の共同作業である必要があります。 アプリケーションの状態の概要を把握することは重要であり、アラートなどの故障修理メンテナンスの代わりに予防メンテナンスに使用できます。 また、NOC画面でも見栄えがします。
3）コンポーネントが異常な状態にあるときに操作で使用できるすべてのアクション（ステップ1から判断できるはずです）を明確に文書化する必要があります。 午前中の未明にアラートが発生した場合、アラートから適切なアクションをリバースエンジニアリングすることはほとんど問題外です。 ただし、散発的な「壁にスパゲッティを投げる」アクション（つまり、「サービスを再起動しましょう。サーバーはどうですか？サーバーが通信しているサービスはどうですか？」）を実行する運用チームは、支援するよりも傷つく可能性が高くなります。 トラブルシューティング手順、推奨されるアクションなどを含む、明確で簡単にアクセスできるドキュメントが必要です。
4）理想的には、アプリケーションを知っていて、その実行方法に責任を持つ人（つまり、開発者）も、アプリケーションのアラートに応答する人になります。 一部の問題はアプリに直接関連していない可能性があるため、運用チームは確かにエスカレーションポイントになる可能性があります。 ここで、DevOps（またはOpsDev）の価値が前面に出てきます。
マイクロサービスを扱う場合、運用の複雑さは避けられません。 リスクはあるものの、SOAの導入を恐れることはありません。メリットが大きく、リスクを管理できるからです。 それらについてどう思いますか？
