勤め先でSRE本の輪読をしている時のメモ。
# サービス障害の追跡
・長期にわたる信頼性の向上は基準点を設定して進捗のトラッキングが可能なことが条件
・Googleではoutlatorというシステムを利用
└アラートを受信 データにラベリング グループ化 分析を提供
・ポストモーテムは個々の障害について詳細な情報を提供
頻繁かつ広範囲な問題を検討するには全体の確認できる必要
└シフトごとに何件コール？ 対処必要だったアラートは？ 何のサービスが最もトイルを生む？
## Escalator
・SREへの通知の全ては、人間が通知を受信したか中央のシステムで管理
・確認応答されない場合は、次の当番にエスカ
## Outlator
・Outlaorは障害チケットを管理するツール
・Outlatorには元の通知のコピーが保存される←情報が一元的に管理される
├通知には"重要"等の注釈を付与できる
└通知はグループ化も可能
・Outlatorのようなシステムはチャットと相性が良い
### 集計
・1つのイベントで複数のアラートが発生することは間々ある
#サーバダウンでサーバとNWと両方ダウン検知
└フォールスポジティブ、フォールスネガティブを考えると通知は減らせない
・対応は複数アラートを1つにグルーピングすること
### タグ付け
・すべてのアラートがインシデントではないので、区別のためにタグ付けをする
└フォールスポジティブやテスト、人による誤送信
・outlatorでは一単語でタグ付けをする、コロンがセパレータになる
└ex. "cuase:network" "cause:network:switch"など
・またタグはリンクにもなる
└"bugs:76543"のように
### 分析
・履歴データはインシデント対応に役立つ
└前回に何を実施したかも重要だが、体系的・周期的・広範な問題を解析するときに障害の追跡は重要
・分析の根底にあるのは、基本的な集計情報(週/月/四半期など)
・次のレイヤはより重要で、チーム/サービスを時間経過で比較しパターン・傾向を分析する
└過去のデータと比較することで、データが正常を示しているのか、異常を示しているのか判断できるようになる
・データ分析の次のステップは、データから意味を解釈すること
└インシデントの原因になっているコンポーネントを特定し、改善出来たら嬉しい
### 予想外のメリット
・アラートが他の障害と同時に発生しているとわかることはメリットがある
├インシデントの発生を認識することで、調査の迅速化と他チームの不可を下げることができる
└システムに障害が発生しているにアラートが飛んでない時は手動で通知する
・ダミーのエスカレーターを使うことで、通知を人間は受信しないが
Outlatorで管理するようにすることもできる。
├特権ユーザの使用履歴を管理する
└冪等でない結果のジョブをトラッキングし、結果に注釈付けする
