最初は自分一人で運用をどう自動化するか？を観点に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のインシデント登録情報≠アラートメールの場合は漏れとして扱われます。
