3章 盲目状態での運用

期待通りの処理が行われているかどうかを確認するためのツールがないと、（中略）一般的なパフォーマンスの数値はあったとしても、運用の観点からは事実上、盲目状態なのです。

これめっちゃわかりみがふかい。ゆえにユースケースに関するログって本当に大事なんだよなぁ。

3.1　苦労話

3.2　開発と運用の役割を変える

Knight Capitalの問題ははじめてしった。金融だからわかりやすく大きい数字になっているが、金融じゃなくても問題はいろいろあるよなー。

最近だとパスワードがMD5になっていて、それが漏れたってニュースになっていたな。いまやbcryptですら第一選択肢ではなく、第三選択肢くらいなので、つねに知識をアップデートしていかないといけない。

以下の考えは古い、てことのよう。

運用チームは、インフラレイヤでの正常性を見守っていればよい」

インフラに問題ないのに、アプリがうまく動作しないならプログラムが悪い」

以下が、DevOps的な考え？

「開発と運用はどちらも新たな責任を負うことになります」」

開発チームはインフラを、運用チームはアプリをそれなりに意識して進むべき。

3.3　プロダクトの理解

たとえばクレジットカードを処理するためにサードパーティと連携しているアプリケーションの場合、クレジットカードを処理する速度を測定するメトリクスを取得すると良いでしょう。このメトリクスの値が低下した場合、サードパーティに問題が発生して処理時間が増加している可能性があります。

どの処理に時間がかかっているのかをわかりやすくするためのログ大事だよなー。フロントエンドはGAが勝手にやってくれるようになったけど、バックエンドはあまり自動化されていない印象（X-rayとかdatadogとかあるけど、まだまだ自分たちでやる部分がおおいなーみたいな）

3.4　運用の可視化

スループット、エラー率、レイテンシからはじめよっていうのはわかりやすい

キューイングシステムでの説明はたしかにわかりやすいな。Webサーバーも実際にはそうなわけだし。

FMEAがでてきた

深刻度、発生頻度、検出可能性

FMEAもうちょい理解したい

普段のお客様支援の中では「CPU利用率・メモリ使用率・ディスク使用率」とかだけ設定しがち。(CloudWatch)

「カスタムメトリクスを設計(?)できる」と価値高そう。

じゃあ、どういうアプローチでカスタムメトリクス設計能力を養っていくか？

3.5　ログを価値のあるものにする

「構築VS購入」

「やるべきだができていないこと」があるのでは？

それなら、管理対象のインフラを増やさずにサービスを利用しよう。というメッセージ。

賛同。私がAWSのベンダーに属していることもあるが。

2023年に自分でログ集約ツールをつくるイメージはないな。。。最低でもELKを使いながらなんとかするみたいなイメージ。

2013年とかだと自分達でログパーサーをかいたりツールを作るみたいなのもあった気がするが。。。

ログを読む人のことを考え、エラーメッセージを読むときに生じる疑問を想定してみてください。先のメッセージは「クレジットカードの認証を完了できませんでした。注文は拒否され顧客に通知されます」とすると良いでしょう。これで、何が起こったのか、その結果としてシステムがとったアクションについての全体を把握できます。

こういうログメッセージのあり方みたいな話って大事だけど、意外と抜けがちな気がする。

3.6　本章のまとめ

みんなからのコメント

実践する/伝えるためのハードルはなにか？

NewRelicとかSplunkとかツールをいれるのは簡単なのでできるとおもうけど、「ログやメトリクスを見てどういった行動をとるのか？」の整理ができているつもりで、あまりできていないっていうのがありそうだし、開発中にどういったタイミング？立て付け？で話すといいのかっていうのに悩んでしまって後回しになっているとか？

一緒に使うと良さそうなプラクティスやマインドセットはなにか？

ハードルの乗り越え方はなにか？実践/伝える方法はなにか？

どれくらい効果がありそうか？