PagerDuty始めました 導入から二ヶ月実際のところどうなのPD?【cloudpack 大阪 BLOG】
運営の方が初めての事というのでオブザーバーとして協力させて頂きましたが
と、ご紹介して頂いて涙・・・って感じでしたが、JAWS-UG大阪じゃなくなっていて
オペレーションじょうずになっていました汗。
多分、第二回早くしろって感じのプレッシャーもあると思いますが、第二回ではなく、
ってのを10末にしますので許してくださいw。
で、本編です。
cloudpackでPagerDutyを導入したのが5月で、
６月は業務の傍らがんばって運用可能な状況までセッティングして、
７月から運用を開始し二ヶ月が経過しました。
導入前は
な感じの構成でした。
なお導入は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でインシデントを登録するような対応もしています。
急なシフト変更やサービスのメンテナンスモードの設定も数クリックで設定でき、
非常に便利です。
で、現在はインシデント管理だけではなく
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のアウトプットしてください〜
