さらばHubot さらばEC2。API GatewayとLambdaで始めるMSPのIT化フェイズ3(その0)【cloudpack 大阪 BLOG】
JAWS-UGの京都が10/21(水)に実施されるようです。
大阪オフィスのメンバーも登壇や運営に参加するようなので
実施時は暖かく見守ってあげてください。
話題は変わり、cloudpackのMSPのIT化で使っているMSPのシステムですが
日時業務や運用スケジュールの通知＆リマインダー機能(ここ重要)や
月次業務の一部自動化などを支えていてメンバーも方からも日常的に使っていただいてもらっており、面倒を見ている私以外のMSPの方々は安定運用しているな〜って
感じで見えていると思います。しかし・・・
な構成で動いていたら良いのですが、最初は予算もなく効果も見えなさそう＆
そもそもそんなにシステム的に負荷はかからないということで
な構成で作っていましたが、あるべき姿にそろそろすべきかなと思いましたが
負荷もそんなにないのに最低の性能のインスタンスで冗長化してもコストは高くなるのと、Hubot使っているのですが、Hubotの機能をほとんど使ってないのと(
文字入力なんていちいちしてれない)、
slackがhubotのリンクを勝手に切る事件が過去数度あり、方針として
して
にしちゃおうと、時間のないなか、休日や帰ってからも含め、
この一週間ほど頑張ってましたが、とりあえずエージングまでは
できそうだったのでBLOG書きました。
フルマネージドなサービスの活用、対障害性を冗長構成のもの以上にするを
モットーにNo メンテナンスなものにしたいのですが、
ここからはいろいろとあると思いますがノウハウとして蓄えればと思います。
実施したことや引っかかった部分はおいおい書いていきますが
今日は絵を描くだけで精一杯なのでここまで汗
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のアウトプットしてください〜
PagerDuty始めました。インシデントの可視化を行うPagerDutyのレポート機能【cloudpack 大阪 BLOG】
cloudpack大阪のメンバーのBLOGが続々と公開されました。
元開発メンバー3名・インフラエンジニアからの異色のチームですが
元開発メンバーはどんどんインフラ力を吸収し(cloudpackでの時間は
通常の三倍以上と言われています)、日々成長していますw
※本音は元開発メンバーでも全員技術&リーダーも出来るので、
※短期的な事を考えると、開発で月30人月ぐらい回すほうがありかなと思ったりもしますw
で、今回はPgaerDutyのReoprts機能です。
PgaerDutyのReoprts機能ですが、導入初期に関してはうーんあまり使わないなーって感じで考えていました・・・が
こんな画面で、System/Team/User/Alerts/Incidentsタブで観点(画面)を変更し、
Report by:でService/Escalation Policyを選択(cloudpackのMSPな使い方だと
Service)、
Day/Week/Month/期間設定で表示範囲を指定、
ViewでNumber of Incidents/Mean Time to Acknowledge/Median Time to Acknowledge/90th Percentile Time to Acknowledge/Mean Time to Resolve/Median Time to Resolve/90th Percentile Time to Resolveを指定します。
ざっくりとインシデントの総数やMTTA(Acknowledge(着手)するまでの平均時間)やMTTR(Resolve(解決)するまでの平均時間)などを見て、
各監視対象に対しての客観的な判断が可能となります。
また詳細に関してはIncidents TABを選択し、
日ごとのリストが出ますのでView Onlineや自動化ならDownload CSVでファイルで
日単位で発生したインシデントを確認する事が可能です。
View Onlineで日単位の情報を取得し、DurationやEscalated?の値を見て、各インシデントが、cloudpackのサービスとして問題なかったかの確認を行います。
今までは感覚的な部分(問題になったものだけがクローズアップされがちで、
日常のパフォーマンスなどが見えにくかった)が多かったですが、
PagerDutyを導入する事により、インシデント管理を定量的に確認し、
インシデントの多いサービスをピックアップする材料を
PagerDutyで作成する事が可能になったので、この情報を巧く活用していきたいと思います。
【cloudpack 大阪 BLOG】Datadog始めました(DatadogでAWSのインスタンスを監視してみる)
cloudpackにもDatadogの波が訪れようとしているようで
BLOGを書いたシンジさんからDatadogすげーんで今からデモ見せるんで
試してみてくださいとデモをしてもらったのですが、
これはスゲーを連発したこのDatadogは、
よくよく考えてみたら2年ぐらい前のAWS re:Inventの時？に確か
ブースでデモを見ていて、
その時もスゲーを連発していたらなんかグッズを貰ってきたのですが、
記憶が封印されてました・・・汗
その時はMSPをするなんて全く認識していなかったので、
インフラの監視がどんだけ大変か？を知る由も
無かったのですがMSPをやるようになり、
自分で監視設定もやったりするようになってから再度シンジさんの
デモを見るとこれは本当にヤバいって感じになりました。
監視対象のインフラの過去から現在の状況をDatadogで収集、
そして現在発生したインシデントをpagerdutyで管理・・・という
バラ色？の未来の為にとりあえず自分のアカウントで試してみます。
ちなみにAWSコンソール上のEC2はこんな感じ(ELBも登録していますが記載しません)
とりあえずはDatadogで使うIAMの作成。
AWSコンソールに入ってIAMを作成します。
IAMで必要なJSONは下記に記載していますので
Datadog Docs - Datadog-AWS Cloudwatch Integration
ここのをぺたっと貼付けます。
そしてDatadogにログインし(5インスタンス以下なら無料ですので
無料アカウントで試してみる事をお勧めします)ログイン後に
integrationsを選択し、
沢山並んでいるDATADOGで使えるサービスの中から
のAvailableをクリックし有効化を行います。有効化したら
となっているので、フォーカスをあてると
とUIが変わりますので、Configureを選択すると
が出てくるので、Access Key IDとSecret Access Keyを入力し
で監視対象を選択し、Update Configurationをクリックすると反映され、少し時間を置くと、
とDatadog上にインスタンスのリストが表示され、
な情報が取得できるようになりました。
本当に運用にのせるには、上記の設定だけではすまないですし、
Datadogの本当の良さにはたどり着きませんが、
とりあえずDatadogを試すのは本当に簡単なので、
一度試してみてはいかがでしょうか？
【cloudpack 大阪 BLOG】pagerduty始めました・・・[イレギュラーな事態が発生した時の対応方法その②]
ちょっと期間が空きましたが、その②です。
今日もメンバーから問い合わせがきて自分で対応したのですが、
そろそろMSPメンバーにpagerdutyの運用の移管も
しなければいけないなーと思っていたので、問い合わせ内容も
BLOGに書いて、cloudpackのWIKIからリンクするようにしておきますw
今回のケースは急なシフトの交代をどうpagerdutyで対応するかを記載します。
ちなみに落とし穴もあるのでそれも書いておきます。
メニューからSchedulesを選択し
変更したいスケジュールを確認。
今回は7/30のシフトを比企からMSP大阪のエース廣山さんに変更なので
7/30の比企のシフトをクリック。
上書き画面が出ます。Personの変更を行います(Time Zoneや開始と終了は変更しないでください(範囲内だとOKですが範囲を超えると・・・BLOGの最後に書きます汗))。
Personを廣山さんに変更しCreate Overrideをクリック
無事に廣山さんに変更できました。以上です。スゴく簡単にできます。
ちなみに想像と違う挙動をしてしまうケースです(操作の結果的にはあっていると思いますが、勘違いしやすいところなので記載します。)
8/1から8/12日の19時までを廣山さんに変更したい時ですが、下記のようにまとめて
行うと・・・
下記のようになります汗。必ず一つ一つ選択してください汗
pagerdutyの時間や期間設定はちょっと大雑把な部分があるので、
うまく操作してくださいw。
