【cloudpack 大阪 BLOG】pagerduty始めました・・・[いきなりの制約回避編 スケジュールとエスカレーションポリシーのハマりどころ] | iret.media
いきなりですが、先に制約による課題と解決策を記載しておきます。 ※この課題の数字で導入を諦めるかたもいるので、まず書かさせて頂きます。 前回の記事で、エスカレーションポリシーの階層で設定できるスケジュールは 10個ですってのを記載してます。 通知される担当が最大10人までの場合だと、1スケジュール=1名で設定して、 10スケジュール作成してエスカレーションポリシーにセットする事で対応は可能です・・・が、24時間・365日でかつ数多くのシステムを預かっているcloudpackのような規模だと、そのスケジュール作成のルールでは簡単にオーバーフローしてしまいます汗。 逃げの手としてエスカレーションポリシーの階層で制御する事も可能ですが普通は ①階層目 監視メンバーA・監視メンバーB・監視メンバーC ②階層目 監視メンバーA・監視メンバーB・監視メンバーC＋リーダー層 ③階層目 監視メンバーA・監
![【cloudpack 大阪 BLOG】pagerduty始めました・・・[いきなりの制約回避編 スケジュールとエスカレーションポリシーのハマりどころ] | iret.media](https://cdn-ak-scissors.b.st-hatena.com/image/square/5a04567a8424e2d0f98777676d1ff112166ed9a4/height=288;version=1;width=512/https%3A%2F%2Firet.media%2Fwp-content%2Fuploads%2F2015%2F07%2Feyecatch-pagerduty-2.png)
【cloudpack 大阪 BLOG】pagerduty始めました・・・[説明編] | iret.media
cloudpack大阪は開発を行えるメンバーがインフラエンジニアやっているので ちょこちょこMSPのIT化を進めています。 そいいう活動が徐々に認知されるようになり、 cloudpack 大阪 BLOGでもたまにキーワードが出てきますが pagerdutyをcloudpackで導入するのを比企のほうで担当しました( こんなに大規模で沢山のトラフィックでpagerdutyで導入するのは 事例としてはあまりないような気がします)。 何回にわたるかわかりませんが汗、pagerdutyの説明から導入・運用・課題などを記載出来ればと思います。 pagerdutyとは監視サーバーからくるアラートをインシデントとして pagerdutyで受け付けて、スケジューリングされた監視しているメンバーに インシデントを配信し、 Acknowledged(認め、操作した監視メンバーにアサインする) Resolved
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
