以下の内容はhttps://itechblog.hatenablog.com/entry/2024/11/23/151123より取得しました。


【要約】システム運用アンチパターン

オライリーの「システム運用アンチパターン」を読んだので、要点をまとめておきます。

目次

DevOpsについて (1章)

1章では、DevOpsについて紹介されていました。

DevOpsは本書では「ソフトウェア開発の考え方をほかの役割に適用するような開発手法」と紹介されており、「開発のライフサイクルに関わる全チームで責任を共有する」という言い換えもされていました。

ツールの話ではなく、チームがどのように働くか、についての話であり、CAMS (文化、自動化、メトリクス、共有) が柱である、と書かれていました。

承認について (2章)

付加価値の低い承認タスクを取り除いて、リリースにかかる時間を短縮しよう、という話が書かれていました。

例えば、問題が起きて、他の部署によるレビューが必須になる、という例が紹介されていました。

しかしこれは、承認プロセスの形骸化し、結局はデプロイ速度が落ちるだけなので、自動化により解決しよう、ということが書かれていました。

例えば、危険な操作を一部の人しか行えないのではなく、そもそも危険な操作が行えない設計にする、ということが紹介されていました。

また、承認作業に関しても、何を確認しているのかをまずは明確にすること。その上で承認自体も自動化できるのが理想で、実際のコード例も出しつつ解説がされていました。

ログについて (3章)

メトリクス・ログを適切に取りましょう、という話が書かれていました。

1つのログから多くの情報が得られるようにしておく (ほかのinfoログを見なくてよいように) という話は、運用上重要だなと思いました。

可視化について (4章)

データありきで可視化するのではなく

  1. 誰のためのダッシュボードか決める
  2. 何を表示するか決める
  3. ウィジェットに文脈 (閾値の線や、時間により変化するデータなら前日の実測値など) を与える

という流れで可視化しよう、という話が書かれていました。

読み手のための脚注や、ダッシュボードの名前の分かりやすさも大事だなと思いました。

テストについて (5章)

テストピラミッドに関する話がメインでした。

また、CI/CDに関する話もありました。CI(継続的デリバリ)は常にデプロイ可能にしておくことで、CD(継続的デプロイ)は全てのコミットを本番にデプロイするという手法です。

通常、CDは必要ないと書かれていました。

アラートについて (6章)

良いアラートとは、以下のようなものだ、と書かれていました。

  1. 行動可能である (何が問題で、どう解決するかが明確)
  2. イムリーである (待って解決するものではなく、すぐに調査が必要)
  3. 優先順位づけがされている (緊急度により通知手段が異なる)

またアラートの閾値に関しては、複合アラートを使えると良いと書かれていました。

オンコールに関しても書かれており、ある程度の負荷は問題を解決する動機となるため、6人程度が理想と書かれていました。

また、オンコールの補償だけでなく、データの収集 (誰が、どんな時間に、どんな緊急度のアラートを受けているか) の重要性についても触れられていました。

自動化について (7章)

自動化は待ち時間、実行時間と頻度、実行のばらつきを改善できます。

これを踏まえた上で、自動化にかかるコスト、手動で続けた場合のコストを比較しよう、ということが書かれていました。

リリースについて (8章)

業務時間外のリリースは避けられる、という話でした。

具体的な方法としては以下が紹介されていました。

  1. フラグにより、リリースしておいた機能を有効化する
  2. ブルーグリーン・デプロイ

またDBの変更に関しては、以下のような方法が推奨されていました。

  1. 新しいテーブルを追加し、更新形は両方のテーブルに書き込み、参照形は古いテーブルを参照するようにする
  2. 参照系で新しいテーブルを参照するようにする
  3. 古いテーブル、このテーブルへの書き込み処理を削除する

インシデントについて (9章)

この章はインシデントの振り返りに関する内容でした。

この本では振り返りは「ポストモーテム」と呼ばれており、以下が重要だと書かれていました。

  1. 人ではなくシステムを責める
  2. 24時間以内に実施する (それ以上経つと記憶が薄れる、危機感を忘れるから)

具体的には以下の進め方をするよう、具体的な例え話を出して解説されていました。

  1. タイムラインの作成
  2. イベントに文脈を与える (なぜその行動をしたか)
  3. 今後実行することを決める (誰が、いつまでに、も決める)
  4. 期限切れの場合、場合によってはリスクを受け入れる

情報の共有について (10章)

情報は意図せず個人にためこまれる、という話を出した上で、ドキュメントの重要性を説いていました。

それが難しいなら、イベントでの発表などという形を取ると良い、と書かれていました。

また、知識の発見が難しいことにも触れられていました。

その一つの解決法として、部門ではなくトピックによる階層化が挙げられていました。(具体例としてWikipediaが挙げられていました。)

文化について (11章)

文化とは

  1. 文化的価値観 (企業の価値観、いわゆるバリュー)
  2. 文化的習慣 (その会社や、アジャイルなどで行なわれる特定の習慣や行動)
  3. 信念 (仕事のやり方に関して、変えられないと思うもの)

の3要素から成り立つと書かれていました。

この章では、文化は個人が変えられるということ、すなわち、コアバリューを体現する行動を自らがとることで、それが組織にとっての習慣となり、文化的な規範となっていく、ということが主張されていました。

タスクの優先度について (12章)

端的に言えば、緊急度と重要度によって優先度を決めましょう、という話でした。

また、チームの目標を意識することの重要性が説かれていました。タスクの優先度の判断軸となるためです。




以上の内容はhttps://itechblog.hatenablog.com/entry/2024/11/23/151123より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14