24365の運用を支える仕組み。PagerDutyを活用する為に【cloudpack大阪BLOG】

最初は自分一人で運用をどう自動化するか？を観点にPgaerDutyの導入から

作業スケジュールのリマインド機能付きslack通知・とあるMSP顧客の各種要望などを
構築/運用業務の傍らにやっていましたが、MSP開発もメンバーが揃いだし、

本格的な開発が可能になってきました。

ただ開発者のエゴな車輪の再発明や、

ターゲットが定まってない状態での自動化などの暴挙は行わず

まず運用の可視化や確実性を高めるサービスの導入をひとまず行っています。

※他の現場の可視化が気になって下記勉強会を開催します。よかったら是非

cloudpackの運用ではslackをメインにコミュニケーションを行っていますが、
slackの通知はすぐに流れる為に24365で確実に担当者に情報を伝える仕組みとして
PagerDutyをインシデント管理以外も含め活用しています。

非常に便利なPagerDutyですがPagerDuty自体の設定を担当者がミスしていたり、PagerDutyがSLA100%を保証していないのでPagerDutyが正常に稼動しているのか？を監視する必要があります。

その方法として、cloudpackではPagerDutyのサービス障害が発生を想定してアラートメールも併用して冗長化していますが、MSP開発ではアラートメールの内容とPagerDutyの状況を突合させて設定漏れやPagerDutyが正常に動作しているか？を SESの受信とLambdaを利用してチェックし、PagerDutyが正しく動作しているのかを別の観点からチェックする事を可能にしました。

MSPはcloudpackのビジネスの根幹です。

お客様に24365のサービスを提供する為にSaaSのサービスを活用するのは必然ですが
利用しているSaaSのサービスが正常に動いていませんでしたって言い訳はお客様にはできないので、MSP開発では日々様々な改善を模索し、開発を行い作成した機能の運用も行っていき、MSPのクオリティを高めていければと思います。

 ※1 除外設定PD登録のLambdaはアラートメールはあるけどPDに登録されてないものを

PDに登録するLambdaです。

このLambdaで登録されたインシデントはPDに登録された瞬間に自動でクローズされ、突合する時の情報の為だけにPDに登録されます。

この機能により、PDのインシデント登録情報=アラートメールの状態となり、

PDのインシデント登録情報≠アラートメールの場合は漏れとして扱われます。