PagerDuty、または運用部門が夜眠れない理由

システムが複雑になればなるほど、あらゆる種類のアラートが増えすぎます。 そして、これらの同じアラートに対応し、それらを集約して視覚化する必要があります。 これは多くの人にとって緊張するほどよく知られた状況だと思います。

これから説明する解決策はそれほど予想外のものではありませんが、検索してもこのトピックに関する本格的な記事は見つかりません。

したがって、私は FunCorp の経験を共有し、職務プロセスがどのように構成されているか、誰が電話をかけ、なぜ、どのようにすべてを確認できるかについて話すことにしました。

PagerDutyとは何ですか?

そこで、これらすべての問題を解決するために、便利なツールを探し始めました。 いくつか検索した結果、PagerDuty を選択しました。 私たちにとって、PD は、多数の統合と設定を備えた、かなり完全で簡潔なソリューションであるように見えました。 彼女はどんな人ですか？

つまり、PagerDuty は、さまざまな統合を通じて受信したインシデントを処理し、勤務指示を設定し、インシデントのレベル (高レベルでは通話、低レベルでは) に応じて勤務中のエンジニアに警告できるインシデント処理プラットフォームです。アプリケーション/SMS からのプッシュ）。

当番役員は誰ですか?

おそらく、これが PD のセットアップを開始する最初の場所です。

FunCorp には、他の企業と同様に、当番役員という名誉職があります。 10 日に XNUMX 回、エンジニアからエンジニアへと送信されます。 PagerDuty からのアラートに対する応答には、いわゆる XNUMX 行目と XNUMX 行目があります。 優先度の高いアラートが到着し、最初の回線から当直担当者に電話してから XNUMX 分経過しても反応がなかった場合 (つまり、確認または解決ステータスに転送されなかった場合)、通話は XNUMX 番目の回線に進みます。当直エンジニア。 これは、PagerDuty 自体でエスカレーションポリシーを通じて設定されます。

XNUMX 番目の当直担当者が応答しない場合、通知は元に戻ります。 メイン 当番職員に。

したがって、受信した優先度の高いアラートを未処理のままにすることはできません。 

次に、インシデントがどこから発生するかを見てみましょう。

どのような統合を使用しますか?

PD はさまざまなサービスからさまざまなインシデントを受け取ります。 現在、そのようなサービスが約 25 あり、それらを処理するために既製の統合をいくつか使用しています。

• プロメテウス

主要なメトリクス収集システムは Prometheus です。 これについてはすでに Habré で多くのことが書かれていますが、さまざまな環境用にいくつかのメトリクスがあることだけを述べておきます。XNUMX つは仮想マシンと Docker からメトリクスを収集し、もう XNUMX つは Amazon サービスからメトリクスを収集し、XNUMX つ目はハードウェア マシンからメトリクスを収集します。 Telegraf は主にメトリクス エクスポーターとして使用されます。

• メール

ここでも、タイトルからすべてが明らかだと思います。 この統合は、cron によって実行されるいくつかのスクリプトから通知を送信するために使用されます。 PD はあなたに手紙を送るための特定の住所を与えます。 このような統合を使用してサービスを作成する場合は、優先順位、受信インシデントの処理順序、アラートの正確な作成方法 (受信レターごと、受信レター + 特定のルールなど) を設定できます。

• Slack

私の意見では、非常に興味深い統合です。 何かが起こってもインシデントにカバーされない場合もあります。 そこで、Slack からの連携を追加してインシデントを作成しました。 つまり、企業の Slack に書き込むことができます。 /callofduty すべてが遅いのですぐに壊れます PD はそれを処理し、当直エンジニアにインシデントを送信します。

私たちは次のことを行います:

私たちは見る：

• API

HTTPの統合。 実際、ここには特に興味深いものはなく、JSON 形式の本文を持つ POST リクエストがあるだけです。 たとえば、興味深いことです。これを使用して外部モニタリングに使用します。 https://www.statuscake.com/。 このサービスは、世界のさまざまな地域から当社のサイトへのアクセス可能性をチェックします。 受け入れられない応答コード (502 など) を受信した場合、インシデントが作成され、その後、すべてが上記のチェーンに従います。 StatusCake 自体には、内部 URL、SSL 証明書、またはドメインの有効期限を監視する機能があります。

• リブレNMS

これは別の監視システムです。詳細については、Web サイトで読むことができます。 https://www.librenms.org/。 その助けを借りて、サーバーからネットワークインターフェイスとiDRACを監視します。

Datadog、CloudWatch などの統合もありました。 彼らに何が起こったのかを詳しく見ることができます ここで.

可視化

主なインシデント報告システムは Slack です。 PD に届くすべてのインシデントは特別なチャットに書き込まれ、ステータスが変化した場合には、それもチャットに表示されます。

天井から吊り下げられたモニターの画面に有用なデータを表示する機会が来たとき、私たち (devops 部門には) モニターに表示するものが何もないことに突然気づきました。 素晴らしい Grafana がありますが、すべてをカバーしているわけではなく、従業員はグラフではなくアラートに反応します。

PD 用の簡潔で有益な「ボード」を GitHub で徹底的に検索しましたが失敗したため、必要なものだけを使用して独自のボードを作成することにしました。 当初はPDインターフェース自体を表示するというアイデアもありましたが、それはさらに不便に見えました。

これを書き込むために必要なのは、読み取り専用権限を持つ PD からキーを取得することだけです。
そして、これが私たちが得たものです:

画面には、現在未解決のインシデント、選択したスケジュールから現在勤務しているエンジニアの名前、および優先度の高いインシデントが発生していない時間が表示されます (優先度の高いインシデントがあるパネルは赤色で強調表示されます)。

この実装のソースはここを参照してください.

その結果、すべてのインシデントを表示するための便利なダッシュボードを入手しました。 私たちの経験が少しでも役に立てば幸いです。

出所： habr.com