なぜエンジニアはアプリケーションの監視を気にしないのでしょうか?

みなさん、ハッピーフライデー！ 皆さん、今日もこのコースに特化した一連の出版物を続けます。 「DevOps の実践とツール」、そのコースの新しいグループでの授業が来週末に始まるためです。 それでは、始めましょう!

モニタリングというのは、 ちょうど。 これは周知の事実です。 Nagios を起動し、リモート システム上で NRPE を実行し、NRPE TCP ポート 5666 で Nagios を設定すると、監視が可能になります。

簡単すぎて面白くない。 これで、Nagios と NRPE にデフォルトで提供される、CPU 時間、ディスク サブシステム、RAM の基本的なメトリクスが得られました。 しかし、これは実際には「モニタリング」そのものではありません。 これは始まりにすぎない。

(通常、彼らは PNP4Nagios、RRDtool、Thruk をインストールし、Slack で通知を設定し、nagiosexchange に直接進みますが、それは今は省略しましょう)。

良好なモニタリング 実際には非常に複雑なので、監視しているアプリケーションの内部をよく知る必要があります。

モニタリングは難しいですか？

Linux であれ Windows であれ、サーバーは定義上、何らかの目的を果たします。 Apache、Samba、Tomcat、ファイル ストレージ、LDAP - これらすべてのサービスは、多かれ少なかれ XNUMX つ以上の点で独自です。 それぞれに独自の機能、独自の特性があります。 サーバーに負荷がかかっているときに重要なメトリクス、KPI (主要業績評価指標) を取得するには、さまざまな方法があります。

写真の作者 ルーク・チェッサー на Unsplash

(ダッシュボードがネオンブルーだったらいいのに - 夢見心地でため息 -...うーん...)

サービスを提供するソフトウェアには、メトリクスを収集するメカニズムが必要です。 Apacheにはモジュールがあります mod-status、サーバーステータスページが表示されます。 Nginx には - stub_status。 Tomcat には、主要なメトリクスを表示する JMX またはカスタム Web アプリケーションがあります。 MySQLには「show global status」などのコマンドがあります。
では、なぜ開発者は自分が作成するアプリケーションに同様のメカニズムを構築しないのでしょうか?

これは開発者だけがやっているのでしょうか?

メトリクスの埋め込みに対するある程度の無関心は、開発者に限定されません。 私が働いていた会社では、Tomcat を使用してアプリケーションを開発していましたが、一般的な Tomcat エラー ログを除いて、独自のメトリクスやサービス アクティビティのログは提供されていませんでした。 一部の開発者は、運悪く午前 3 時 15 分にログを読んだシステム管理者にとっては何の意味もない大量のログを生成します。

写真の作者 ティム・グー на Unsplash

このような製品を世に送り出すシステムエンジニアにも責任の一端はあるはずだ。 メトリクスのコンテキストや、アプリケーションのアクティビティを考慮してメトリクスを解釈する能力がなければ、ログから意味のあるメトリクスを抽出しようとする時間や注意力を持つシステム エンジニアはほとんどいません。 「現在何かが間違っている（または間もなく何かが間違っている）」という指標以外に、そこからどのように利益を得られるのかを理解していない人もいます。

メトリクスの必要性についての考え方の変化は、開発者の間だけでなく、システム エンジニアの間でも起こらなければなりません。

重大なイベントに対応するだけでなく、そのイベントが発生しないようにする必要があるシステム エンジニアにとって、通常、メトリクスの欠如がその障害となります。

ただし、システム エンジニアは通常、会社に利益をもたらすためにコードをいじることはしません。 問題の特定やパフォーマンス問題への意識の向上などにおいて、システム エンジニアの責任の重要性を理解している主任開発者が必要です。

これは開発するものです

Devops の考え方は、開発 (dev) 思考と運用 (ops) 思考の相乗効果を表します。 「DevOps を行う」と主張する企業は次のことを行う必要があります。

1. 彼らがおそらく言わないことを言う（プリンセスブライドのミームを参照 - 「それはあなたが思っているような意味だとは思いません！」）
2. 継続的に製品を改善する姿勢を奨励します。

製品が現在どのように機能するかを知らなければ、製品を改善したり、改善されたことを知ることはできません。 そのコンポーネントがどのように機能するか、製品が依存するサービス、主な問題点とボトルネックを理解していなければ、製品がどのように機能するかを知ることはできません。
潜在的なボトルネックに注意しないと、事後分析を作成するときに「XNUMX つのなぜ」テクニックに従うことができなくなります。 すべてを XNUMX つの画面に表示して、製品がどのように機能するかを確認したり、それが「普通で満足」しているものであるかを知ることはできません。

左にシフトして、左、リーと言った—

私にとって、Devops の重要な原則の XNUMX つは「シフトレフト」です。 この文脈での左へのシフトは、可能性をシフトすることを意味します (責任はありません、パフォーマンス メトリクスの作成、ログのより効率的な使用など、システム エンジニアが通常関心を持つことを実行する機能のみ) は、ソフトウェア配信ライフ サイクルの左側にあります。

写真の作者 メーカーによるNESA на Unsplash

ソフトウェア開発者は、あらゆる形式、メトリクス、ロギング、監視インターフェイス、そして最も重要なことに、企業が監視を実行するために使用する監視ツールを使用し、理解できなければなりません。 製品が本番環境でどのように機能するかを観察する。 開発者がメトリクスを確認し、その見た目や次回の説明会で製品所有者が CTO にどのように提示するかなどに影響を与えることができるようになるまで、開発者にモニタリングに労力と時間を投資してもらうことはできません。

まもなく

1. 馬を水辺まで導きます。 開発者に自分たちでどれだけの問題を回避できるかを示し、アプリケーションに適切な KPI と指標を特定できるように支援します。これにより、CTO から怒鳴られるプロダクトオーナーからの怒鳴り声が減ります。 優しく穏やかに、彼らを光の中に導き入れてください。 それがうまくいかない場合は、アプリケーションからこれらのメトリクスをできるだけ早く取得するように実装するように、製品所有者または製品所有者に賄賂を渡し、脅迫し、そそのかして、図を描画します。 これは優先事項とは見なされず、製品ロードマップには多くの収益を生み出すプロジェクトが保留中であるため、これは困難です。 したがって、製品への監視の実装に費やした時間と費用を正当化するビジネス ケースが必要になります。
2. システム エンジニアが快適な睡眠を取れるように支援します。 リリースされる製品に対して「リリースしましょう」チェックリストを使用することが良いことであることを示してください。 また、本番環境のすべてのアプリケーションがメトリクスでカバーされていることを確認すると、開発者がどこで何が問題になっているのかを確認できるため、夜の睡眠の質が向上します。 ただし、開発者、製品所有者、CTO をイライラさせたりイライラさせたりする正しい方法は、粘り強く抵抗することです。 この動作は、再びギリギリまで待つと製品のリリース日に影響を与えるため、再び左にシフトして、できるだけ早くこれらの問題をプロジェクト計画に組み込んでください。 必要に応じて、製品会議に出席してください。 つけヒゲとフェルトか何かをつけておけば、絶対に失敗しません。 懸念事項を伝え、明確な利点を示し、宣伝します。
3. 開発 (dev) と運用 (ops) の両方が、製品メトリクスがレッド ゾーンに移行する意味と結果を理解していることを確認します。 Ops を製品の健全性の唯一の保護者として放置せず、開発者も必ず関与するようにしてください (#productsquads)。
4. ログは素晴らしいものですが、メトリクスも同様です。 それらを組み合わせて、ログが役に立たない巨大な炎の玉のゴミにならないようにしてください。 なぜ他の人が自分たちのログを理解できないのかを開発者に説明し、午前 3 時 15 分に役に立たないログを見ることがどのようなものかを示してください。

写真の作者 マルコ・ホーヴァット на Unsplash

それだけです。 来週には新しい素材がリリースされます。 コースについて詳しく知りたい場合は、こちらをお勧めします オープンデー、月曜日に開催されます。 そして今、我々は伝統的に皆さんからのコメントを待っています。

出所： habr.com