アラート監視基準書の作成でお悩みの方へ


# はじめに

はじめまして、mediba　グローバル開発 BrSEの@vuducでございます。
本記事は「mediba Advent Calendar 2022」 24日目の記事です。

記事の内容は自分のチームが運用している方法に基づいての発信であり、
会社を代表する意見や見解ではありません。

数年間、同じフォームとフローで運用していますので、
皆様のご参考になればと、記載させて頂くことにしました。

今回は、以下のような内容について紹介いたします。
1\. 読者想定
2\. 監視基準書を作成できる前提
3\. 監視基準書の構成

# 読者想定

* 以下のような方々へ何かしらの貢献ができる記事になるよう意識しています。
    * New RelicやDatadog等でアラート監視を設定したい方
    * Terraform等でアラート監視のコードを書きたい方
    * アラート設定を可視化して、
        * ITリテラシーをあまり持っておらず、基本を理解したい方
        * アラート設定の前後の管理を容易にしたい方

# 監視基準書を作成できる前提

* サービスSLAを既に確定済。
* 監視基準書を作成したいタイミングを自分で決定。
    * サービスサーバー環境を構築済
        * この場合には、アラートを設定する必要がある対象リストを一回で抽出しやすいので、最も楽な方法です。
    * サービスサーバー環境を構築中
        * この場合には、構築しながら、設定の対象リストを抽出できますが、環境完成までに監視基準書を修正する必要が出てくる場合があります。
    * サービスサーバー構成図を作成済
        * この場合には、環境構築の前に作成するので、環境完成までに監視基準書を繰り返し修正する必要があると想定しています。

# 監視基準書の構成

## ①基本ポリシーの定義

* サービスSLAと会社によって、基本ルールと観点が変わる可能性がありますが、基本的には以下のように運用しております。

| 深刻度 |定義 |障害例|　連絡時間　|　連絡手法　|
|:-----------|:------------|:------------|:------------|:------------|
|致命的(Critical)|サービスに影響があり、直ちに修復が必要なケース（重度アラートが頻発するケースも）|データーベースが全体停止|例：24　h/365 days|自動電話、Backlogに自動起票、Slack（@channelを利用）に自動発報|
|重度(Severe)|サービスには影響が無いが、リリース作業等に影響がでる恐れのあるケース|冗長化しているデータベースの内、1台が停止|例：　月〜金（9:30-17:30)|Backlogに自動起票、Slackに自動発報|
|軽度(Error)|サービスに影響が無いが、何かしらの問題が発生し、対応が必要なケース|　リソース(CPU・メモリ等)の閾値超過|例：　月〜金（9:30-17:30)|Backlogに自動起票|
|警告(Warn)|サービスには影響が無く、場合によって対応が必要なケース|４０４ページが表示|例：　月〜金（9:30-17:30)|Backlogに自動起票|

* 自動電話は**Twilio、AWS Connect**をよく利用しています。

## ②監視設定仕様

* 抽出したAWS対象サービスごとに別の監視設定仕様シートの作成をオススメします。
* AWSサービスの例は、以下の通りです。
    * API、Server、バッチ：ALB、ECS、EC2
    * ElastiCache、S3、Nat Gateway、Lambda、データベース（RDS、DynamoDB）、Cloudfront、ElasticSearch、CloudWatchLogs、など
* 監視設定仕様シートは以下のように作成しておりますので、ご参考にしてください！

|ホスト名（クラスター名)|IPアドレス|監視タイプ|監視項目|　監視エージェント　|　間隔（秒）　|対象　|閾値|アラートメッセージ|備考|深刻度|
|:-----------|:------------|:------------|:------------|:------------|:------------|:------------|:------------|:------------|:------------|:------------|
|例：web01-linux2-prd|(EIP)(Private IP)10.X.Y.Z|リソース監視|Load Ave.|Newrelic Infra Agent|60|5min Average|1分平均値5超過が5分継続|EC2インスタンスで5分平均のロードアベレージ閾値超過を検知しました。|接続が最大数に達したため、拒否された接続数。|軽度(Error)|

* **よく利用しているもの**
    * 監視タイプ：ネットワーク疎通監視、Uptime監視、リソース監視、サービス/プロセス監視、ログ監視、ファイル監視、OS設定監視、ポート監視、URLレスポンス監視、状態監視、など
    * 監視エージェント：Newrelic Infra Agent（オススメ）、CloudWatch logs Agent、Zabbix
    * 深刻度：「基本ポリシーの定義」記載の通り

## ③改訂履歴の定義

* アラート監視基準書の確定版を公開した後に、保守運用する際に、アラート監視仕様を改修する場合があるため、関係者と後任者のために、改訂履歴を定義しております。
* 改訂履歴定義の構成は、以下の通りです。

|No|版数|変更日|区分|　更新箇所　|　変更内容|対象　|担当者|
|:-----------|:------------|:------------|:------------|:------------|:------------|:------------|:------------|
|例：１|1.0|2022/12/08|新規（変更）|web01-linux2-prd||間隔（秒）を120分に変更|Aさん|

## ④自動連絡先の定義

* 頻発する重度アラートもしくは、致命的アラートが発生すれば、サービスの管理者と担当者に自動電話を設定しています。
* TwilioやAWS Connectなど、自動電話ツールに連絡先リストを設定できるために、自動連絡先を定義する必要があります。
* 自動連絡先定義の構成は、以下の通りです。

|No|会社名|優先順位|サービス担当区分|名前|ふりがな|部署名|電話番号|
|:-----------|:------------|:------------|:------------|:------------|:------------|:------------|:------------|
|例：１|株式会社 A|1|開発者|あい　えお|あいえお|テック|+8190-1111-111|
|例：2|株式会社 B|2|PO|かき　けこ|かき　けこ|ビジネス|+8170-2222-222|

* 優先順位に基づき、自動的に電話します。

# さいごに

いかがでしたでしょうか。
アラート監視基準書の完成後、アラート監視の設定と運用が楽になればと思っております。
是非みなさんのお仕事に役立てていただけますと嬉しいです！

現在、medibaの募集求人ページから応募され入社が決定すると、お祝い金として30万円をプレゼントするキャンペーンを実施中です！！
リモート環境を充実するためディスプレイやマイクを買いそろえるも良し。スキル習熟のために自己研鑽に使うも良し。使途は完全自由です。
→　[募集・応募ページ](https://hrmos.co/pages/mediba/jobs/1100000001 "募集・応募ページ")
いきなり応募だとちょっとハードルが高い・・でも興味がある方は、カジュアル面談も行っていますので、まずはお話してみませんか？
→　[カジュアル面談](https://hrmos.co/pages/mediba/jobs/6100000001 "カジュアル面談")
※お祝い金は、試用期間（3か月）を経て、雇用が継続した場合に支給させて頂きます。

以上となります。ありがとうございました！