- 信頼性を高めていくには、進歩の追跡が必要
- GoogleのSREで使用されているサービス障害の追跡ツールの活用方法を紹介
- Escalator
- Outalator
- 個人ごとのアラート通知の受信確認を追跡するシステム
- 設定された期間内に受信確認がない場合: 次の送信先にアラートメールを送付してエスカレーションする
- 容易に既存のワークフローに組み込むことができる(モニタリングシステムの変更も不要)
- サービス障害追跡ツール
- モニタリングシステムが送信するすべてのアラートを受動的に受け取る
- 機能/特徴:
- アラートデータに対して、アノテーション/グループ化/分析を行える
- アラートの時系列のリストをまとめて確認できる
- インシデントに対するメールの返信を追跡できる
- アノテーションで重要なインシデントを通知できる
- 複数のアラートを1つのインシデントにまとめることができる
- チャットツールと連携させてコミュニケーションやステータスの更新を行うと良い
- 1つのイベントから複数のアラートが引き起こされることがある
- 単純にNW障害などの影響度が大きいもの
- 1つのサービスにしか影響がない小さな問題
- 1つのイベントから生じる複数のアラート数を減らすことは、価値があるが難しい
- この重複するアラートを扱うには、グループ化できる必要がある
- グループ化しない場合の悪い点:
- デバッグ作業の重複
- パニックの招来
- 特にチーム間を跨ぐ場合や長期間にわたる場合に非現実的/非スケーラブル
- 全てのアラートがインシデントではない
- アラートにタグ付けすることでメタデータを与えることで解決する
- タグはチームごとに好みや標準を決めることで有用性が増す
- デフォルトで付与されるタグ
- cause
- action
- チームごとに付与するタグ
- customer:123
- デフォルトで付与されるタグ
- タグは":"で階層化して詳細化し、自動化にも利用できる
- cause:network:switch
- タグはチームがサービスの問題点を把握する上で強力なツール
- 分析はサービス障害の追跡ツールにとって重要な機能
- 時系列データ: インシデントへの対応時に役立つ
- 履歴データ: インシデントレスポンスの際に役立つ
- 分析のレイヤー1:
- 基本的な統計データを収集する
- 週/月/四半期ごとのインシデント数やアラート数といった情報
- 分析のレイヤー2:
- インシデントの最初のパターンやトレンドを特定する
- サービス/チームごとの比較
- 時間の経過に伴う比較
- 重要機能だが提供は容易
- アラートが他のサービスや過去の記録と比べて「通常」なのか判断できる
- 今週3回アラートが起きてただけでは善し悪しが判断できない
- 過去の情報(過去に5回/日なのか5回/月)も考慮することで解釈できる
- インシデントの最初のパターンやトレンドを特定する
- 分析のレイヤー3:
- より広範囲の問題を見つけること
- 単に数を数えるのではなく、何らかの意味的な分析が必要
- インシデントの原因があるインフラのあるコンポーネントだった場合: 該当コンポーネントの安定性やパフォーマンスを向上させることでメリットが得られるか判定する
- レポーティングとコミュニケーション
- サービス障害に対して、タイトル/タグ/アノテーションを使って、次のエンジニアへ状況を受け渡す
- アラートが他のサービス障害と共に生じたものであることが分かる場合には、明らかなメリットが生じる
- 診断が素早く行える
- 実施にインシデントがあることが認識できる
- 他のチームの負荷を下げる
- あるサービス障害が明らかに他チームのコンポーネントである場合、予想外のメリットが生じる
- 手動でそのチームにアラートを発して知らせることができる
- チーム間をまたぐ視界をクリアにすれば、インシデントの解決/緩和において大きく違いが出る
- GoogleではダミーのEscalator/Outalatorを「記録システム」として使っている
- データベースへの自動的なスキーマ変更適用の記録
- 定期的なジョブ実行の記録
- 効率的なサービス障害の追跡 => 効率的なサービス向上
- 障害対応は当然大事だが、障害対応にかける工数を下げることも大事
- アラート/障害対応状況/作業のチームを超えた透明性大事
- 本章相当のことをやってみたいと思った(重くなさそうだし)