雑なA型によるクラウドとモバイルと運営と

大阪でJAWS-UG OSAKAとInnovation EGGを運営している人のBLOGです。時々更新します〜

PagerDuty始めました 導入から二ヶ月実際のところどうなのPD?【cloudpack 大阪 BLOG】

OPS-JAWSがオープンな場所で勉強会を開催しました。

運営の方が初めての事というのでオブザーバーとして協力させて頂きましたが

f:id:unioce:20150901194936j:plain

と、ご紹介して頂いて涙・・・って感じでしたが、JAWS-UG大阪じゃなくなっていて

オペレーションじょうずになっていました汗。

 

多分、第二回早くしろって感じのプレッシャーもあると思いますが、第二回ではなく、

ってのを10末にしますので許してくださいw。

 

で、本編です。

cloudpackでPagerDutyを導入したのが5月で、

6月は業務の傍らがんばって運用可能な状況までセッティングして、

7月から運用を開始し二ヶ月が経過しました。

導入前は

f:id:unioce:20150901201451p:plain

な感じの構成でした。

 

なお導入はUIでポチポチ設定なんてしていたら全然追いつかないので、

APIを駆使し何百のサービス(インスタンス数では無いです。監視サービス数ですw)を

登録の自動化などして他のメンバーが移行に携わらずに出来る状況を作って

移行は一人でやり抜きましたが、移行後の最初はPagerDutyはアラートメールでの

監視のおまけ的なポジションでAckなども気が向いた時にやるって感じでした(涙)・・・が、多拠点運用・複数人による監視などの不特定な状況化で、必要なタイミングで

通知が来て、メールベースだと誰が対応するかslackで名乗りをあげていたのが

ポチッとクリックするだけで、モレや重複して作業をしなくても良いと気づくと

一気にPD最高って話になりました。

よくslackとの連携でアラートをslack上に投げるってのも見ますが、

通知の垂れ流しなので正直使い物になりません。

 

複雑なcloudpackのMSPのシフトスケジュールもgoogle apps spreadに

記載したものをgoogle apps scriptとPDのAPIで流し込めるようにして

複雑なシフトの入力問題は解決させました。

【cloudpack 大阪 BLOG】pagerduty始めました・・・[いきなりの制約回避編 スケジュールとエスカレーションポリシーのハマりどころ] - 雑なA型によるクラウドとモバイルと運営と

 

環境によっては、監視サーバーにpagerdutyのpluginを入れれない場合や、

メール通知のアドレスの分も修正できないケースの監視サーバーなどもありますが、

そこはメールからgoogle apps scriptでPagerDutyにAPIでインシデントを登録するような対応もしています。

 

急なシフト変更やサービスのメンテナンスモードの設定も数クリックで設定でき、

非常に便利です。

 

で、現在はインシデント管理だけではなく

f:id:unioce:20150901202654p:plain

google apps scriptなども駆使して、

backlogの担当者未が設定された通知

EC2•RDS•ダイレクトコネクトのメンテナンス通知

などもMSPの当番の人にエスカレーションされるようになっています。

※赤色の線の部分はリストラ予定ですw。hubotやDBはLambdaとDynamo DBに変更して

 フルマネージドな環境にします(hubot飽きたw)。

 

google apps scriptもたまに謎のエラーが出ますが、これもPagerDutyで管理しており、

google apps scriptのエラーの場合、ここを見てねってのがPagerDutyのDescriptionに

記載しているので、googleの謎のアラートもどんと来いですw

 

とりあえず2ヶ月間が立ちましたが、MSPの運用負荷の削減にもなったので(運用も

一部見直したのもありますが、PDが無ければ出来なかった)

PagerDutyのcloudpackのMSPへの導入は当たりだったと思います。

 

皆様も是非活用して、TIPSのアウトプットしてください〜