【読書メモ】「システム運用アンチパターン」を読んだまとめ

2022年12月30日

はじめに

システム運用アンチパターンを読みました。
中身はDevOps本です。
DevOpsという用語は知っていたものの、詳しくなかったため読んでみました。
印象に残った項目をメモしています。

1章　DevOpsを構成するもの

• DevOpsとは？
  • ソフトウェア開発の考え方をほかの役割に適用するようなソフトウェア開発手法(p.3)
  • ソフトウェア開発のライフサイクルに関わるすべてのチームが責任を共有する事を重視する
  • 従来は開発者中心であった業務を運用チームのメンバーが担い、開発チームのメンバーも同様の業務を行うことで、
    職能の垣根が低くなる
• DevOpsの柱となるCAMS
  • 文化(p.6)
  • 自動化
  • メトリクス
    • 物事がうまく機能しているかどうか判断するために必要
    • エラーが発生していないことを確認するだけでは不十分
  • 共有

2章　パターナリスト症候群

• 仕事の進め方やタイミングをゲートキーパーと呼ばれる権力者に委ねる(p.9)
  • 最初は賢明な判断に見えるがすぐに生産性の低下を招く
• 承認の目的を把握して、自動化する(p.21)

3章　盲目状態での運用

• 開発と運用の役割を変える(p.35)
• プロダクトの理解(p.36)
• システムの動作を理解する際に役立つメトリクス(p.37)
  • スループット
  • エラー率
  • レイテンシ
• メトリクスの種類(P.38)
  • ゲージ
    • ある特定の瞬間の数値
  • カウンタ
    • あるイベントが発生した回数を表し、増加し続ける値
• 何を測定するか決める(P.39)
  • 何を測定するか決めるのは難しい作業
• 健全なメトリクスを定義する(P.43)
• 何を記録すべきか？(P.51)
  • 何のアクションが実行されたのか？(P.52)
  • そのアクションの期待される結果は何か？
  • そのアクションの実際の結果は何か？
  • 取るべき修復手順は何か？
  • このエラーによって引き起こされる潜在的な結果は何か？
    • 何か起こったのか、その結果としてシステムがとったアクションを把握できるようにする。
      • ×：クレジットカードの認証を完了できませんでした
      • ○：クレジットカードの認証を完了できませんでした。注文は拒否され顧客に通知されます

4章　情報ではなくデータ

• ダッシュボード作成の際にやってしまいがちなのは、すべての人の役に立つ究極のダッシュボードを構築しようとする始め方(P.60)
  • そのようなものは存在しない
  • ほとんどの場合、誰にとっても役に立たないダッシュボードができあがる
• ダッシュボードの対象者を特定する
  • 誰がこのダッシュボードを見るのか？
  • このダッシュボードの目的は何か？
  • 上記の目的を考慮したうえで、このダッシュボードが伝える必要のある情報のうち上位3～5個の項目は何か？
• ウィジェットに文脈を与える(P.65)
  • 利用者が値の良し悪しを知ることができるようにする
• ダッシュボードの命名(P.70)

5章　最後の味付けとしての品質

以前読んだ継続的デリバリーと内容が被っているので割愛
継続的デリバリーの読書メモはこちら

6章　アラート疲れ

• アラートは単にシステムの状態を説明しているだけで、どのようにしてそのような状態になったのかについては分からない(P.104)
• アラート基準(P.110)
  • 行動可能である
    • アラートをトリガーする際、何が問題でどう解決するかについて道筋を示すべき
  • タイムリーである
    • 未来への影響を予測してアラートをトリガーする事は止める（ディスク容量が少なくなってきた等）
    • 検出するまでの期間を延ばす（4回チェックに失敗したらアラートする等）
  • 適切に優先順位付けされている
    • 発生している事が分かれば十分な通知はメール等の優先順位の低い通知方法に変更する
• しきい値
  • 何をもって正常な値が確信をもてない場合は、過去の値から得られる値を観察する
  • 過去の値から正常な範囲を把握したら、この基準値よりも20%高い値をしきい値としてアラートを設定する

7章　空の道具箱

8章　業務時間外のデプロイ

題名だけ見ると、定時後や休日にデプロイする話なのかと思いましたが、
デプロイが不安で大きなイベントなっていることについて書かれています。

• 遅いリリースの悪影響(P.173)
  • リリースの詰め込み
  • 大急ぎの機能
  • 重厚な変更管理プロセス
    • リリースが大きくなるとリスクが大きくなる
    • リスクが大きくなると失敗の影響が大きくなる
    • 失敗の影響が大きくなると承認や変更管理の層を増やしてプロセスが厳しくなる
• デプロイのレイヤ(P.174)
• ステージング環境と本番環境は同じにならない(P.179)
  • ユーザーと並行実効性
• 不完全な測定(P.189)
  • 測定の完璧さにとらわれてはいけない
• データベース変更のルール(P.194)
  • 基本的なルールは、常に追加的な変更を加える

9章　せっかくのインシデントを無駄にする

• ポストトーテムとは、チームがインシデントに至るまでの出来事を評価するプロセス(P.214)
• 責任のなすりつけ合いがうまくいかないのは、問題が人にあると攻撃してしまうから
  • なぜ失敗を引き起こしたのかという核心に触れていない
• ポストモーテムのルール設定(P.218)
  • 人を直接批判してはならない。行動や振る舞いに焦点を当てる。
  • 誰もが、その時点で得られた情報の中で、最善の仕事をしたと考える。
  • 今となっては明白な事実であっても、その場ではあいまいだった可能性があることを認識する。
  • 人ではなくシステムを責める。
  • 最終的な目標は、インシデントに関与したすべての要素を理解することであることを忘れない。

10章　情報のため込み：ブレントだけが知っている

• 情報を公開するだけでは不十分(P.236)
  • 知識共有の現実は、単に情報をwikiに載せるだけでは十分ではない
• ドキュメントは最終的なゴールではなく、最終的なゴールは情報の共有(P.239)
• 抽象化 vs. 難読化(P.240)
• 学習の習慣付け(P.253)
  • ランチ＆ラーン
  • ライトニングトーク
  • 外部イベントのホスト
  • ブログ

11章　命じられた文化

• なぜDevOps組織では文化が重要なのか？(P.264)
  • 文化が仕事の進め方の風潮を決めるから
• 文化とは何か？(P.264)
  • 文化的価値観
  • 文化的習慣
  • 信念
    • 信念によって、疑問を感じない文化が生み出され、より良い方法は実現可能性が非常に低く、
      試みることさえも愚かに思えてしまう
• 文化を変えるには？(P.269)
  • 文化を変えるには、社会集団の中でどのように文化が広がって伝達させるかを理解することが重要
    • 文化の共有
      • 言葉による文化の共有
        • 言葉遣いは、メンバーがグループ内のほかの人の行動をまねることで、
          良い点も悪い点もチーム全体に伝わる
          • 例えば、データベース管理者の悪口ばかり言っていたら、すぐに周りの人もデータベース管理者を否定的に見るようになる
        • 「わからない」という言葉のようにシンプルなことを率直に言えることで、チームや組織の多くの文化的価値観や規範を伝えることができる
          • 誰かがこういう発言をすることによって、自分の仕事について常に何でも知っていなければならないと感じているメンバーの心理的負担を軽減できる
      • 物語による文化の共有
        • 成功譚は企業文化の基盤となり、企業に目的を与え、問題に取り組む姿勢を形成することもある
      • 習慣による文化の共有
  • 言葉・物語・習慣は、文化を伝える3つの重要な方法(良くも悪くも)
  • 個人が文化を変えることができる(P.272)
  • 会社の価値観を調べる(P.274)
    • 言葉から始める
    • 対話するには次のような言葉を使う
      • 確固たる事実と、その事実から導き出された視点や意見を明確に分ける
      • 議論のある余地のある表現を使う
      • 自分の行動の最終目標を明確にする
  • 習慣を作る(P.276)
    • 習慣に取り組む際に自問すること
      • 1. 習慣の目的は何か？
      • 2. どのようなスタイルの習慣を作るのか(社会的習慣か、プロセス的習慣か)？
      • 3. 週刊で期待されるアウトプットは何か？
      • 4. 何が習慣の実行のきっかけとなるか？
  • 習慣と言葉を使って文化的規範を変える(P.278)
    • 文化的規範の多くはテクノロジーで強制できる(P.279)
    • 言葉と習慣の組み合わせは文化的規範への違反を気付かせる健全な方法として機能する
  • 文化にあった人材(P.281)
    • 古い役割、新しい考え方
      • チームが新しい考え方を導入する準備をする際には、ほかのチームメンバーの仕事に興味を持つことをもくひょうにするべき
      • そういった興味は、責任を共有することで生じる場合もあるし、生来の好奇心や過去の経験から生じる場合もある
      • 開発者は運用面に関心を抱いているはずで、運用も同様に開発のハードルに関心を持っているはず
    • 会話を通して問題を共有する(P.282)
      • どのように交流したかは、実際に交流が行われることに比べれば重要ではない
      • チームメンバー間で交流を生み出すことは、共感を生み、他の人の役割に対する好奇心を刺激する(P.283)

12章　多すぎる尺度

• 目標設定と順位付けのプロセスは、DevOpsの文化において非常に重要(P.295)
• 目標の階層(P.296)
  • 組織全体の目標
  • 部門の目標
  • チームの目標
• 優先度、緊急度、重要度(P.301)
  • 1人の人間が持つことのできる優先事項は一度に1つ
  • 緊急度とは、どれだけ早くその仕事をしなければならないか
    • 客観的な期限が必要
  • 重要度とは、その仕事の深刻さや価値に関係している
• 予定外の作業(P.310)
  • 予定外の作業のコントロール(P.311)
    • 同僚からの予定外の作業
    • システムからの予定外の作業
  • 予定外の作業への対応(P.314)
    • その依頼はなぜ重要なのか？
    • その依頼が遅れることで何が影響を受けるか？
    • その依頼のほかの関係者は誰か？(たとえば依頼が遅れることで他に影響を受けるのは誰か？)