盲目状態での運用とは
システムがどのように機能しているのか実際のビジネスにどういった影響があるのかを把握できていない→ 運用の観点からは事実上、盲目状態
開発チーム、運用チームは自分の担当範囲を超えて、アプリケーションがどう動くのか理解する必要がある
開発チームは本番でアプリケーションをどう動くか理解する
運用チームはシステムが何を行っているかどう動くかを理解する
1 プロダクトの理解はDevOps組織では必須
ビジネスの観点から理解して価値を付加しなければ、単純なAPIコールに置き換えられて失業する可能性がある...
ツールに関する専門知識と会社のプロダクトやビジネスに関する知識の組み合わせが運用エンジニアの価値であり必要とされているもの
2 運用の可視化
メトリクスとログの2つの情報源によって可能。
現状、多くの組織は役に立つメトリクスやログを効果的に利用できていない。
2.1 メトリクス
システムリソースのある時点での測定値。システムで発生している様々なアクティビティの状態を伝えるのに適している。
2.1.1 カスタムメトリクスの作成
運用の可視化を実現するための最初のステップはアプリケーション用のカスタムメトリクスを開発すること.
システムを理解するのに役立つ３つのメトリクス
・スループット・・・どのぐらいの頻度でこの処理が発生しているのか？（一定期間内システムを流れる仕事の量）
・エラー率・・・どれくらいの頻度で失敗しているか？（リクエストの総数に対してのエラー数）
・レイテンシ・・・完了するまでにどのぐらいの時間がかかるか？（特定のアクションが完了するまでの時間）
一般的にゲージとカウンタの2種類でメトリクスを定義する。
・ゲージ・・・ある特定の瞬間の数値(例えば、利用可能なディスク容量)
・カウンタ・・・あるイベントが発生した回数を表し、増加し続ける値(例えば、WEBページのヒット数)
2.1.3 健全なメトリクスを定義する
メトリクスの値がどうなった場合に調査をするかを定義する
→ サービスのパフォーマンスが大きく変化したことを知り、システムが「健全」かどうかを再評価する
健全なメトリクスを定義するプロセスにプロダクトチームが参加することで許容できるパフォーマンスについて全員の合意を得ることがきる（顧客の声を代弁しどの部分が特に大切なのかを判断できるため）
2.1.4 故障モード影響分析(FMEA)
システムやプロセスに起こりうるエラーを予測し、トラブル未然防止を図る故障モード影響分析(FMEA=failure mode and effects analysis)を利用する。
エラーが発生する可能性がある箇所を洗い出し、以下3つの軸で1〜10の尺度で評価しスコアを掛け合わせる。
・深刻度・・・エラーが発生した場合にどれだけひどいことになるか
・発生頻度・・・エラーがどれぐらいの頻度で発生するか
・検出可能性・・・社内の監視システムやメトリクスがエラーを検出する前に、顧客がそのエラーに気付く可能性
上記のスコアを掛け合わせて、エラーにリスク優先度番号(RPN=risk priority number)を付与することでリスクが高いものの優先順位をつけることが出来る。
定期的に発生する障害をどのようにして防げば良いのか途方に暮れている場合やアプリケーションがどのように動作するか定まっていない部分を表面化させる際に有益となる。
2.1.5 インシデントや失敗から得られるメトリクス
障害が発生した後は必ずその障害を振り返るポストモーテムを行うことで、優れたメトリクスを見つけ出すことが出来る！
「システムとその現状について答えられないような疑問があったか？」と継続的に問いかけることで監視システムに潜在する多くの欠落部が浮き彫りになる。
2.2 ログについて
ログは必ず構造化(JSON形式など)し、ログ集約システムなどでチームに権限を与え可能な限り多くの情報を共有し民主化することが大事（DevOpsの中心的な考え方）
プロセスの各機能やステップがどのように動作しているかという情報を集約することで、ビジネスの流れを垣間見ることもできる。
2.2.1 何を記録すべきか？
最も一般的なログレベルは、DEBUG、INFO、WARN、ERROR、FATAL。
ログメッセージを適切なカテゴリに分類することは、メッセージを記録することと同じくらい重要！
適切なレベルでログを出すかはエンジニア次第だが、適切なログレベルが設定されていないと該当の情報をログから探すことが困難となる。
良いログメッセージとは
文脈が大事。ログを見る人はそのログメッセージしか見ないという前提で書くべき。
ログを読む人のことを考え、エラーメッセージを読むときに生じる疑問を想定する。
・ 何のアクションが実行されたのか？
・ そのアクションの期待される結果は何か？
・ そのアクションの実際の結果は何か？
・ 取るべき修復手順
・ このエラーによって引き起こされる潜在的な結果は何か？(もしあれば)
例：「クレジットカードの認証を完了出来ませんでした」
何を意味しているのか必要な情報がないため、オペレーターが実行すべき後処理が不明となり役に立たない。
2.2.2 ログ集約について
ログ集約の利点は沢山あるが、時間やお金の問題もある。
お金をかけるべきかは、システムが自社の技術ソリューションの中核をなしおらず独自のノウハウもない場合に考える。
ログ集約システムの注意点
・ログの送信制限を超えた場合の影響
・機密情報の取り扱い(SaaSプロバイダに送信する前に取り抜く)
・ログ集約にかかるコストによってログに記録する内容を決めない
本章のまとめ
・プロダクトを理解することは障害発生時の大きな力となる。
・カスタムメトリクスはシステムがどのように動作しているかの詳細をビジネスの文脈で示すことができる。
・故障モード影響分析は何を監視すべきかを把握するための体系的な方法として使用できる。
・ログメッセージが真に有益であるためには適切なログレベルで記録される必要がある。
・ログメッセージには、そのメッセージの文脈を常に含める必要がある。