MEGUMI SHIMABUKURO

社内で評判が良かったので気になって読んだ。この本は DevOps の考え方を中心にプロダクトやサービス運用するために必要なトピックや考え方がまとまった一冊だ。アンチパターンを例に出しながら、では実際どうしたらいいのか？を考えさせてくれる構成になっている。運用に慣れてない人であれば、まずこの本を読むと一通りのポイントは抑えられるのではないだろうか。チームで共通認識を揃えるために読んでも良さそうな本だと思う。

この本で特に良かった点は、DevOps の考え方を学べたことだ。DevOps について、開発と運用に関する領域を指してるぐらいのふわっとした認識だったが、読み進めていくうちに、DevOps めっちゃいい考え方じゃん、と思う場面が多く、そういったことを学べたことがよかった。運用の課題をエンジニアリングで解決していけるようもっと頑張りたいと思わされたし、プロダクト作りに関わる人におすすめの一冊。

目次

✅ 1章 DevOpsを構成するもの

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

✅ 3章 盲目状態での運用

✅ 4章 情報ではなくデータ

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

✅ 6章 アラート疲れ

✅ 7章 空の道具箱

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

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

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

✅ 11章 命じられた文化

✅ 12章 多すぎる尺度

システム運用アンチパターン

上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。 重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。 組織で必…

https://www.oreilly.co.jp

ここから下は章ごとのメモ書きと感想です！！！

• DevOpsとは？
  • ソフトウェアの開発手法
  • ソフトウェア開発のライフサイクルに関わるすべてのチームが責任共有することを重視する
  • チームがどのように一緒に働くのかかがえる。職能の垣根を下げる。
  • DevOpsの主眼は、人々とその相互作用
  • DevOpsは、CAMSというモデルによる４つの柱により支えられてる
    • 文化（Culture）
    • 自動化（automation）
    • メトリクス（metrics）
    • 共有（sharing）

DevOps とは何か？と聞かれたときに一言で答えるのは難しそうな印象を受けた。この本では ソフトウェアの開発手法 と定義されてるが、具体的にどんな手法？と聞かれると難しい。「文化、自動化、メトリクス、共有、を中心にチームでシステム運用・開発する手法」といった感じだろうか。

• パターナリスト症候群とは？
  • あるグループがほかのグループに対して親のような関係のこと
  • ある行動の実行や承認に必要な資格や信頼性を持つのは特定の人物やグループだけである
  • ゲートキーピングとは？
    • パターナリスト症候群の中心
    • ゲートキーピングは、あるリソースにアクセスする際に、人やプロセスが人為的な障壁となっている場合に生じます。
  • なぜパターナリスト症候群になってしまうかというと？
    • システムを使いやすくすると知らず知らずのうちに危険な操作ができるようになるリスクがある。そのリスクを減らすために、危険な操作ができる人を限定する。つまり、アクセス制御する。アクセス制御が過度になると、アクセス許可を依頼する人と承認する人といった構図が生み出される。
  • なぜパターナリスト症候群がダメかというと？
    • お互いの信頼関係の欠如やシステム内部の安全性の欠如してる兆候だから
    • 権力の不均衡を生み出し、チーム間の摩擦に繋がる
  • パターナリスト症候群に対してDevOpsが目指すゴールは？
    • チーム間のコラボレーションの強化
    • 不必要なゲートや作業の受け渡しの削減
    • 開発チームがシステムを所有するために必要なツールと権限の提供
    • 再現性のある予測可能なプロセスの構築
    • アプリケーションの本番環境に対する責任の共有
  • パターナリスト症候群を解消するためには？
    • 承認プロセスの自動化
      • 手動の承認ステップは、問題に対して過剰反応の場合があり、小さく自動化を始めるのが良い。
      • 承認プロセスの自動化するためには、承認プロセスの目的を把握する必要がある
        • 承認プロセスの目的は？（承認プロセスによって解消しようとする主な懸念）
          • プロセスのすべての部分が作業を継続するのに適切な状態であること
          • 作業が発生していることを必要な人に知らせていること
          • 変更を中止する必要があるような、アクションの衝突がないこと
          • 変更のリスクが組織にとって許容できるものであること
      • 承認プロセスを自動化するメリットは？
        • 承認プロセスに費やす時間の削減
        • 管理タスクに費やす時間の削減
        • 反復時間の短縮
        • プロセスフローの一貫性の確立
      • 承認プロセスを自動化する方法は？
        • 自動化のプロセスを適切に段落分けすることが重要
          • 承認プロセス
            • 実行を許可するために必要なチェック項目は何か？
          • ロギングプロセス
            • 依頼・承認・実行・結果をどこに記録するか？
              • あらゆる自動タスクを企業で使用しているイシュートラキングツールや作業トラッキングツールのチケットに結びつけるのがおすすめ
          • 通知プロセス
            • 処理が実行されたことを自動ツールがどこで人々に通知するか？（この通知プロセスはロギングプロセスに含めることもできるが、人によってはログを自分から見にいくのではなくメールのようにプッシュされる通知を好むこともある）
          • エラー通知
            • どの程度まで自動復旧を行うか？

パターナリスト症候群という言葉は初めて聞いた。大きい組織だったり、これから組織が大きくなっていくフェーズにありそう。

パターナリスト症候群に対して、DevOps 的なアプローチや承認プロセス自動化による対策は良さそうだった。自動化って、同じ作業を何度もやらないとけない無駄をなくすといった文脈で登場することが多い印象だが、承認フローから生まれるパターナリスト症候群を改善するといった文脈で登場したのが新鮮に感じた。これまであまり考えたことのない自動化の観点だったので勉強になった。

• 盲目状態の運用とは？
  • システムがどのように機能しているのか、実際のビジネスにどういった影響があるのかを把握できていない状態での運用。
  • システムメトリクスだけあっても足りない。システムメトリクスだけあっても、システムがなぜ誤動作したのか、実際のビジネスにどんな影響があるのかわからないため。
• 運用の可視化するためには？
  • メトリクスとログによって可能になる
• メトリクスについて
  • 何を測定するか決める
    • 何を測定するかを決める際、システムの動作を理解するのに役に立つ３つのメトリクスとは？
      • スループット
        • 一定期間内にシステムを流れる仕事の量として定義されます。Webサーバを運用している場合、スループットは一定期間内に処理したリクエストの数になります。
      • エラー率
        • エラー率はリクエストの総数に対するエラー数の割合で表されます。エラー率を計算するには失敗した作業単位の数を計測し、それを作業単位の総数で割ります
      • レイテンシ
        • レイテンシとは特定のアクションが完了するまでの時間を測定したものです。Webリクエストを例にとると、レイテンシはWebリクエストが完了するまでの時間を表します
    • アプリケーションの各部分に着目して、測定する必要のあるものについて考える。
  • メトリクスを定義したら、健全なメトリクスと不健全なメトリクスを分けるものは何かを定義する
    • どのメトリクスがどうなった場合、アラートを出すのか？
  • インシデントや失敗から得れるメトリクスとは？
    • システムとその現状について答えられないような疑問があったか？
      • 監視システムに潜在する多くの欠落部が浮き彫りにすることができる。
• ログについて
  • ログを価値のあるものにするために必要なことは？
    • 構造化
      • 機械的に読み取れるようにするため
    • ログ集約
      • なぜログ集約が必要なのか？
        • ログにアクセスできる人を限定させることを防ぐ
        • これまで可能だとは思っていなかったようなログの新しいビジネスユースケースを生み出します
        • 1つのシステムでの活動だけではアラートを出すかどうか判断できなくても、複数のシステムの活動を組み合わせることでアラートを出す判断が可能になる場合もあります
        • ログを集約することで複数の関心事に関連したアラートや監視が可能になります。
          • たとえば失敗したWebリクエストの数が多いことと、失敗したデータベースログインの数が多いことを関連付けるといったことは、ログを集約することによって初めて可能になります
  • ログには何を記録すべきか？
    • ログレベル
    • 文脈
      • ログを見る人はそのログメッセージしか見ないという前提で、すべてのログメッセージは書かれるべきです。たとえば「トランザクション完了」というメッセージは意味がありません。
      • 目標は、ログを読む人が理解できるようにログメッセージに必要な文脈を詰め込むこと
      • 例. 注文処理で文脈が含まれてる例
        Copy

        {
        	"timestamp": "2024-04-01-23:43:34",
        	"level": "info",
        	"order_id": 2123,
        	"state": "IN_PROGRESS",
        	"message": "Paymentvertified",
        	"subsystem": "payments.proccessors.credit_card"
        }

    • エラーメッセージをログに記録するとき、必要になる情報とは？
      • 何のアクションが実行されたか？
      • そのアクションの期待される結果は何か？
      • そのアクションの実際の結果は何か？
      • 取るべき修復手順は何か？
      • （もしあれば）このエラーによって引き起こされる潜在的な結果は何か？
    • 最悪な例
      • 「クレジットカードの認証を完了できませんでした。」
      • これだけメッセージ出されても何をしたらいいかわからない
        • 先のメッセージは「クレジットカードの認証を完了できませんでした。注文は拒否され顧客に通知されます」とすると良いでしょう。これで、何が起こったのか、その結果としてシステムがとったアクションについての全体を把握できます。
    • メトリクスにはないログの利点は、エラーの詳細を記載できること。
  • ログ集約のハードル
    • コスト
      • ほとんどのログ集約ツールは以下のいずれかによって費用が発生する
        • データボリューム（ログの総容量）
        • データスループット（1時間に送信されるログの数）
        • イベント総数（送信される個別のログエントリの数）
    • ログ集約システムをSaaSプロバイダから購入する際の懸念
      • ログの送信制限を超えた場合にどういった請求が発生するか
      • ログに機密情報が含まれている場合の対応
      • ログ集約にかかるコストによって、何をどのようにログに記録するかを決めないように注意しましょう

メトリクスやログが何のために必要で、何を記録がすべきか具体的に説明されてて、わかりやすかった。特に「ログに記録するのは文脈」の話は印象的だった。この章に書いてあることを実践していきたい。

• 目的に応じた利用しやすいダッシュボードとは？
  • ダッシュボードの利用者を特定する
• 新しいダッシュボードを作成するときに注意することとは？
  • 誰がこのダッシュボードを見るのか？
  • このダッシュボードの目的は何か？
  • 上記の目的を考慮したうえで、このダッシュボードが伝える必要のある情報のうち上位3〜5個の項目は何か？
• ウィジェットとは？
  • ウィジェットはメトリクスを可視化するために使用される小さなグラフィックユニット。ウィジェットにはさまざまな表示タイプがある。ダッシュボードは複数のウィジェットで構成される。
  • メトリクスの表示に使用されるグラフィカルなコンポーネント。ダッシュボードはウィジェットの集合体。ウィジェットではデータを表現するためにさまざまな表示タイプが使用できる。
  • ウィジェットの種類
    • 折れ線グラフ
      • 折れ線グラフは現在の値だけでなく過去の傾向も示す。メトリクスの時系列での変化やばらつきを確認できる。
      • テクノロジの分野では、折れ線グラフを使っておけば間違いなく、迷ったら折れ線グラフを使うと良い。
    • 棒グラフ
      • 非常に頻度の低いデータや欠損値がある場合に最適な選択肢です。
    • ゲージ
      • ある時点での値を表示する場合に最適なメトリクス
• ウィジェットに文脈を与えるとは？
  • ウィジェットで数値、データだけ表示させていても、情報の良し悪しを判断できないため、 色 や しきい値 、 時間比較 などの、文脈を与える必要がある。
    • 色
      • 緑はOK、黄色は警告、赤は危険 など
    • しきい値
      • しきい値線はグラフに表示される静的な線で、そのウィジェットのあるべき値の最大値を示す
    • 時間比較
      • 別の日の同じ時間帯を重ね合わせることで時間比較することが最適
• ノートウィジェットとは？
  • ダッシュボードやウィジェット、ウィジェットグループについて詳しく説明するためのシンプルな自由形式のテキストエリア
    • ノートウィジェットに書く内容の例文
      • このノートはデータベースのパフォーマンスに関して最も重要な事項について説明しています。理想的なシナリオではほとんどのアイテムがバッファキャッシュから提供されるべきです。しかしシステムの調子が悪くなると、ディスクからアイテムが提供されることになります。
• ダッシュボードの命名方法は？
  • 人々が関心のあるダッシュボードを見つけられるような体系的な命名規則を持つべき
  • 以下のような内容がわかると良い
    • 対象者（マーケティング・運用・データサイエンスなど）
    • 対象のシステム（データベース・プラットフォーム・メッセージバスなど）
    • 対象となるシステムのビュー（Webトラフィックレポート・システムヘルスオーバービュー・現在の月間支出額など）
  • 例. マーケティング - プラットフォーム - Webトラフィックレポート

ダッシュボードの作り方の考え方を学べる章だった。これまでの章にも文脈が大事という話題が出てきていたが、ダッシュボードを作る時も同じで、誰向けの何のために必要なダッシュボードなのかといった文脈が重要。ダッシュボードを作るときの考え方は学べたので、次は普段使ってるツールでどうやるか調べてみたい。

• 最後の味付けとしての品質とは？
  • 開発ライフサイクルの最後まで待ってテストを実行すること
• テストプロセスはDevOpsでどのように適用されるのか？
  • 自動化
    • DevOpsにより自動化が進むと、その変更が成功したかどうかを自動で検証することが重要になってくる
      • この検証がテストプロセスによって行われる。
• テストピラミッドとは？
  • アプリケーションに対して行うべきテストの種類を表すメタファで、テストのライフサイクルの中でどこに最も多くのエネルギーを費やすべきかについての考え方
  • テストの種類
    • ユニットテスト
      • ユニットテストとは、ソフトウェアの個々のユニット、またはコンポーネントに対して書かれたテスト
      • ユニットテストの対象の決め方
        • 決め方に万能な方法はない
    • 統合テスト
      • システム間のやりとりや、ほかのシステムへのアプリケーションのレスポンス処理をテストする
      • ユニットテストでは、データベースへの接続にモックやフェイクを使っていましたが、統合テストでは実際のデータベースサーバに接続してデータの書き込みや読み込みをし、動作が正常に行われるかを検証する。
    • エンドツーエンドテスト
      • ブラウザやクライアントサイドのアプリケーションを起動またはシミュレートし、エンドユーザーと同じアクセス方法でテストする
• テストスイートの信頼性を測る方法とは？
  • テストが失敗した場合、変更したコードを確認しなぜ失敗したか調査すべきだが、そうはせず、テストを再実行させてると、信頼性は低いと言える。（変更差分ではなく、テストスイートが疑われてる）
• DevOpsSecとは？
  • DevOpsの考え方を拡張したもので、セキュリティを主要な関心事の1つとして加えるものです
  • セキュリティスキャンやセキュリティテストを開発のライフサイクルの中に組み込む。

DevOps の自動化が進むと、自動化された処理が正常に完了したことをチェックする必要があり、そのチェックする仕組みも自動化が必要なので、DevOps はテストプロセスが重要になるといったことが書かれた章。テストが落ちた時、とりあえず再実行してしまう時があるので、テストスイートの信頼性を高めるように整理していきたい。

• アラート疲れとは？
  • アラートのノイズを無視するようになり、アラートが発生してることが正常だと認識されてしまうこと
• オンコールローテーションとは？
  • あるシステムやプロセスの最初の連絡先としての担当者を定めたスケジュールのこと
• チームのオンコール対応をうまくやるためにどう準備すれば良いか？
  • オンコールの負荷の追跡
  • オンコールのための人員配置
• 良いアラートの条件とは？
  • 行動可能である
    • このアラートによって誰かが実際に調査を開始できるか？
      • 調査可能であれば、システムのどこを見るのがおすすめか？
  • タイムリーである
    • 敏感すぎるアラートでないか？しばらくすると収まる可能性があるか？あるとすればどれぐらいの時間で収まるのか？
  • 適切に優先順位づけされている
    • このアラートのために誰かを起こす必要があるのか？それとも朝まで待って良いのか？

良いアラートの条件を学ぶことができた章だった。行動可能である、タイムリーである、適切に優先順位付けされている、が良いアラートの条件だ。この中でも特に行動可能であることは、重要だと思ったので、整理したい。何か問題が起きたときに、アラートを見るだけで、何が問題で次にどういう行動をとるべきかわかると、対応もスムーズになるし良さそうだと思う。

• 空の道具箱とは？
  • プロダクトを提供する能力をサポートするツールの自動化に投資しないこと
    • 例えば、ツールを使って自動化せず、手動で毎回同じオペレーションをするように状態
• 自動化が重要になる４つの領域とは？
  • 待ち時間
    • あるタスクや行動が誰によって実行されるのを待つ時間のこと（依頼、チケット起票、実行、完了の一連のプロセス全てにかかる時間）
    • 待ち時間が短く慣ればより早く提供できるようになる
  • 実行時間
    • 例えば、1回で2分かかる作業を週5日やると年間で8.5時間かかる
    • 実行時間が短くなれば、他の作業に割り当てる時間が増える
  • 実行頻度
    • 繰り返し行われる作業を頻繁に行うと集中力が低下する
  • 実行のばらつき
    • 自動化されず手動で対応する場合、人に依存して微妙にやり方が変わる場合がある
    • 実行のばらつきがなくなると、タスクを毎回同じように実行できる
• 組織に自動化が浸透しない理由とは？
  • 自動化文化が優先事項だと位置付けられてないから
• どうすれば自動化文化が根付くのか？
  • 自動化文化を根付かせるためには、 自動化の優先度 を上げるしかない
    • 業務の中で自動化を優先する
    • トレーニングと学習のための時間を確保する
    • 自動化にかかる時間を見積もりに含める
    • 自動化のためのスケジュールを確保する
  • 手動での作業を認めない
  • 「NO」という答えを支持する
    • 手動タスクがダメな理由の回答を明確に用意すること
    • 明確に「NO」と言えない場合、手動と自動の妥協点を用意する
      • 「NO」と言えない場合の例
        • 重要度があまりにも高い
        • 自動化の難易度があまりにも高い
      • スコアカードを作る
        • 自動化したいと思ってるタスクを全てリスト化する
        • タスクに手動での手間を度合いの点数を付与する
        • チームで許容できる点数の合計値をきめ、上限を超えたら自動化に取り組む
  • 手始めに、チケットをバックログに入れないようにする。（つまり、すぐやる、優先度をたかくするという意味）
  • トレーニングのための時間を確保する
• 自動化の目標を決める方法は？
  • 自動化が重要になる４つの領域から考えると良い
    • 待ち時間
    • 実行時間
    • 実行のばらつき
    • 実行頻度
• 自動化のアプローチ方法とは？
  • タスクにおける安全性を考慮する
    • なぜ安全性が重要なのか？
      • 自動化によってユーザーがコントロールできる範囲が少なくなるから。
    • 安全のための設計
      • ユーザーが知識を持ってることを前提としない
      • オペレーターの視点を身についける
      • リスクのある行動は必ず確認を取る
      • 予想外の副作用を避ける
  • タスクの複雑さを考慮する
    • 単純
    • 困難
    • 複雑
  • タスクをランクづけする

自動化の文化を作るためには、自動化の優先度を上げるしかない、と至極真っ当なことが書かれてた。なぜ自動化が重要なのか、自動化の目標の決め方、自動化するときのアプローチ方法、自動化文化の作り方など参考になることが多い章だった。手動での作業は認めない、ぐらいのマインドが大事なのかもしれない。

• デプロイに対する恐怖心やリスクを軽減するための方法とは？
  • デプロイの頻度を増やす。デプロイ頻度を増やすと恐怖感やリスクが軽減される。
    • 頻度を増やすと恐怖感やリスクが軽減されるのはなぜか？
      • ある作業を頻繁に行えば行うほど、その作業が上手になるから。
      • 1回のリリースで変更されるコンポーネントの数が少なくなるから。リリースが1つのシステム、そしてそのシステムの特定のコンポーネントに限定されていると知れば、そのリリースに対する恐怖心はかなり小さくなる。そういったリリースは、潜在的な影響がきちんと把握できるほど変更が小さい。
      • リリースの頻度が高ければ高いほど、システムにより親近感を感じる。こうした小さなリリースが成功すると、リリースプロセス自体に自信が持てる。そうすると不安は解消される。
  • 自動化する
    • 自動化を進めれば進めるほど、プロセスの信頼性が高まる。恐怖心がある一定のレベルまで低くなると、デプロイにまつわる障壁が取り除かれる。
  • デプロイに失敗した時に戻すのが簡単
    • 障害が発生したときのリスクや潜在的な影響が非常に低いこと
    • 失敗を検知しロールバックが可能なこと
• デプロイ頻度を上げるための方法とは？
  • 自動テストを取り入れる
  • テストを組織の一部にする
  • リンターを使う
• デプロイにはどんなレイヤーがあるのか？
  • 機能デプロイ
    • アプリケーション全体で新機能を有効にするプロセス
    • 機能のデプロイとコードのデプロイは同じと思われがちだが厳密には違う
  • フリートデプロイ
    • 複数のサーバにアーティファクトをデプロイするプロセス
  • アーティファクトデプロイ
    • 1台のサーバに新しいコードをインストールするプロセス
  • データベースデプロイ
    • 新しいコードのデプロイの一環としてデータベースに必要な変更を行うプロセス
• デプロイをレイヤーに分けて考えることが大事なのはなぜか？
  • 多くの場合デプロイプロセスではこれらが混在しているから
• デプロイプロセスとは？
  • デプロイプロセスとは、コードを顧客が使用できる状態にするために必要な手順を明確にしたもの
• 合成トランザクションとは？（synthetic transactions）
  • ユーザーが通常行うであろう活動をシミュレートするために作成されたスクリプトやツールのこと
  • ユーザーの視点からアプリケーションを監視する方法や、必要な量のユーザートラフィックがないシステムでユーザーの活動をシミュレートする方法としてよく使用される。
• デプロイにはどんな方法があるか？
  • 機能フラグ
  • ブルーグリーンデプロイ
    • 既存のサーバにコードをデプロイするのではなく、新しいコードを実行する新しいサーバを作成するという手法
    • この設計の最初の注意点は、データベーススキーマがアプリケーションのバージョン間で互換性があるかどうかという点
• データベースレベルのロールバック
  • データベースを変更するときのルールとは？
    • データベースを変更する際の基本的なルールは、常に追加的な変更を加える、というものです。すでに存在するものを変更するのは避けましょう。なぜなら、その変更の影響を受ける依存関係がどこかにあるはずだから。

デプロイに対する恐怖心やリスクを軽減するためにはどうすればいいか？そのためにはデプロイする頻度を増やすといったデプロイについて書かれた章。業務時間外のデプロイというアンチパターンから、デプロイに対するさまざまなアプローチが学べて良かった。

• インシデントとは？
  • 予期せぬ、あるいは計画外の出来事が起きてシステムに悪影響を及ぼす場合、その出来事
• ポストモーテムとは？
  • チームがインシデントに至るまでの出来事を評価するプロセス
  • ポストモーテムは通常、関連するステークホルダーやインシデント対応に関わった人全員でのミーティングという形式で行われる。
• なぜポストモーテムをするのか？
  • システム障害から得られる教訓は、必ずしも自然に得られるものではない。多くの場合、体系的に構造化された方法で、システムやチームメンバーから教訓を引き出す必要がある
  • ポストモーテムの結果をドキュメント化して、ポストモーテムをチーム以外の人に伝えるための記録として、また将来同じような問題に遭遇したときの歴史的な記録として役立てるため。
• 24時間ルールとは？
  • 24時間ルールとは、自分たちの環境でインシデントが発生した場合、24時間以内にそのインシデントに関するポストモーテムを行うべきだというルール
  • 24時間ルールが必要な理由は？
    • インシデントが発生してからドキュメント化されるまでの時間が長くなると、状況の詳細が失われる
    • 失敗の背景にある感情やエネルギーを確実に活用するため
• アクションアイテムとは？
  • ポストモーテムが終わって、今後実施すべきこと
  • アクションアイテムは、「誰がいつまでに何をするか」という形式で明確に定義されなければなりません
  • 短期的なアクションと長期的なアクションに分けることができる

継続的な改善や学習を通して、チームや組織を良くしていこうとする DevOps の考え方は、とても良い考え方だとあらためて思わされた章だった。実際、ポストモーテムがドキュメントでまとめられていると、それを読むことでインシデントを体験してないメンバーにも学びになるし、経験が共有されることは、組織全体で学びになるのですごく良さそうだと思う。

• 情報のため込みとは？
  • 意図的なため込み
    • マネージャーや技術者が自分の利益のために、情報をため込むこと
  • 意図しないため込み
    • ドキュメントの作成が後回しにされ、その結果作成されないままのケース
      • コードやアーキテクチャの変更が少なくなくなるまでドキュメント作成は先送りされ、ようやく変更が落ち着いたらチームは別のプロジェクトに移ってしまい、気がついたら当時のチームしか情報を知らない状況。
    • 抽象化したのはいいが、具体的な詳細の情報(実装)を知らないといけなくなったケース
      • 抽象化レイヤを用いることで、通常であれば把握する必要がある複雑な詳細情報の多くを隠すことができるが、詳細が必要になった場合、詳細を管理してるチームしか情報を知らない状況
      • 他のチームが知らなくてもよくするために抽象化してるので、基本的には問題なけど、詳細を知らないといけなくなった時に情報をため込んでる状態になる
• 情報のため込みはどのように起こるのか？
  • 情報が組織内の特定の領域にサイロ化してしまうことで起こる
  • オリジナルの作者がプロダクトのドキュメントを書かないままいなくなってしまうとき
  • 開発者やアーキテクトがシステムの設計を複雑にしてしまうとき
• 情報のため込みとDevOpsの関係は？
  • 情報をどのように共有するか(=情報をどのようにため込まないか)によって、チームのコミュニケーション方法や責任と所有権の境界線の引き方が決まる。DevOpsの目的の一つにサイロ化を防ぐことがあるので、情報共有について関係してくる。
• ドキュメントにはどういうことを書くべきか？
  • ドキュメントに具体的な実装の詳細を書くよりも、動機や背景、戦略について書くことの方がはるかに優れている。（実装の具体的な詳細はコードを読めばいい）
• 情報共有についてのよくある間違いとは？
  • 誰もが知識を効果的に伝える方法を本質的に知ってると思い込んでしまうこと
• 情報共有するためのおすすめのコミュニケーションステップは？
  • トピックを定義する
  • 対象者を定義する
  • キーポイントを説明する
  • 最後に行動を喚起する
• チームで知識共有の量を増やすためのヒントは？
  • ナレッジストアの構築
• 「もっとドキュメント化しなさい」というアプローチがうまくいかない理由は？
  • 構造的な問題がある
    • ドキュメントを作る人は専門の知識を持った側の人
    • 基本的に専門的な知識を持った人に依頼が集約されるので、対応できるのは専門知識を持った人だけ、という状況になる
    • 専門知識を持った人を増やすためには、何らかの形で「知識伝達」をする必要があるが、知識伝達するために、専門的な知識を持った人の時間を奪うことになるので、知識を持った人が忙しい場合、知識伝達が放棄される傾向にある
    • 結果、ドキュメント化しなさいがうまくいかない
  • ドキュメントを作ることの優先度をあげるか、ドキュメントを作る以外で「知識伝達」する方法を考えないといけない
    • ドキュメントを作る以外の方法
      • ランチアンドラーン
      • ライトニングトーク
      • 外部イベントのホスト
      • ブログ

チームでの情報共有について書かれた章。情報共有について悩んだ時に読み返したい。意図せず情報をため込むケースで、後からドキュメントを書くつもりだったけど、結局書けなかったというのはよくありそうな話だった。

抽象化も状況によっては意図しない情報のため込みになると書かれてて、確かになーと思った。

意図せず情報をため込むケースは、気づかないうちにいろいろありそうなので、普段の仕事でも意図せず情報をため込んでないか注意したい。情報共有について、ドキュメントを書く以外の選択肢もいろいろ紹介されてたので参考にしたい。

• 文化と何か？
  • あるグループの人々をほかのグループから区別する、共有された価値観・習慣・信念の集合体
  • 文化を構成する要素は？
    • 価値観
      • 文化的価値観とは、組織を運営し行動する上で不可欠であると組織が考えている原則や基準のこと。
      • 文化的価値観は、企業のミッションステートメントの中で、行動規範の一部として表現されることもある。
      • 文化的規範とは？
        • 根底にある価値観を表現する行動や活動のこと
    • 習慣
      • 文化的習慣とは、組織内で行われる特定の習慣や行動のこと。
      • 習慣は、そのグループの文化的価値観を反映する
    • 信念
      • 組織の能力を最も制限する要因となるもの
• なぜ文化が重要なのか？（文化は社員のパフォーマンスや行動にどのような影響を与えるのか？）
  • 文化はチームや組織を束ねる役割を持つ。
  • 文化は高い水準を強制することもできるし、低い水準を許容することもできる。
  • 文化は、その文化の中で、どういった行動は許されて、どういった行動は許されないか決める。
• 文化を変えるには？
  • まずは会社の 価値観 をしっかりと理解する。
    • 会社の価値観が、あなたの行動の盾になる。
  • 文化を変えるためにはその集団の中で文化を共有する必要があり、言葉、物語、習慣は文化を伝えるための重要な方法。文化を変えていくにはこれらの要素の調整が必要。
    • 言葉（言葉遣い）
      • 対話のスタイル。次のような言葉を使うようにする。
        • 確固たる事実と、その事実から導き出された視点や意見を明確に分ける
        • 議論の余地のある表現を使う
        • 自分の行動の最終目標を明確にする
    • 物語
    • 習慣
      • 習慣には2種類ある
        • 社会的習慣
          • 社会的な雰囲気のな中で行われ、人間関係が主な動機の習慣
        • プロセス的習慣
          • タスクをどう完了にこぎつけるか、大きなタスクをどうサポートするか
      • 新しい習慣に取り組むときの質問リスト
        • 習慣の目的は何か？（最も重要）
        • どのようなスタイルの習慣を作るのか？
        • 習慣で期待されるアウトプットは何か？
        • 何が習慣のきっかけになるのか？
      • 習慣によって失敗を受け入れる
  • 習慣と言葉を変えることで 文化的規範 も新しく変えることができる。
• 文化チーフとは？
  • 会社が推進する文化的価値観を体現する人のこと
  • 一緒に仕事をするのが楽しく、チームを横断した関係を悩ませる些細な論争を乗り越えようとする人
• シニアエンジニアを採用するために必要なことは？
  • 何を持ってシニアエンジニアとするかを定義する
  • なぜそのシニアエンジニアが必要なのかを問いかける
• 面接で質問する重要な領域とは？
  • 組織の価値観と適合性
    • 例. 組織の価値観が「健全な対立」という価値観の場合
      • 質問の例. あなたと同僚が何か重要なことについて意見の相違があり、あなたの解決策が選ばれなかった場合の例を教えてください。どのようにして解決策に至ったか、また他の人の解決策を受け入れた理由はなんですか？
  • チームの価値観と適合性
  • 技術力
• 技術的な質問はどのようなものがいいか？
  • 実際に遭遇する可能性のある実用的なシナリオに焦点を当てた質問
  • エンジニアが自分の中で考えをまとめるのを聞くことで、彼らの経験を知ることができるような質問
  • 決断によって生じるトレードオフを考慮しているかどうかの質問
  • 答えのない問題をどのように解決するかわかる質問（以前に遭遇したことのある問題を解決するのをみるより明らかに重要）
• なぜDevOps組織では文化がそれほど重要なのか？
  • それは、文化が仕事の進め方の風潮を決めるからです

文化と何なのか？がわかる良い章だった。文化は想像以上に自分たちの仕事に影響を与えており、高い水準を強制することも、低い水準を許容したりもする。一度でも低い水準を許容してしまうと、それが伝播して文化が衰退していく話は、確かにそういう場面あるなーと思いながら読んだ。高い水準の文化を作っていけるようにしたい。

後半は採用の話。文化にあった人を採用するためにはどうすればいいか？といった内容。技術的な質問へのアプローチ方法が特に参考になった。

• 多すぎる尺度とは？
  • チームのパフォーマンスを測る方法がチームごとにバラバラになり、それらの手段が全体の目標を損なうような行動にインセンティブを与えること
• 優先順位はどこから来るのか？
  • チーム・部門・組織の目標や目的に基づいて設定した目標や目的から生まれる。
• 組織の目標とは？
  • ハイレベルで戦略的なもの
  • 例
    • 運用コスト15%の削減
    • 加入者数の前年比20%増
    • 既存顧客支出10%増
• 部門の目標とは？
  • マネジメントチームがエンジニアリングの文脈を考慮して作成したもの
• チームの目標とは？
  • 部門内の個々のチームが何に取り組むかに焦点に当てた目標
  • 部門の目標をより具体化したもの
  • 部門の目標を達成するための具体的な方法を提示する
• 緊急度とは
  • どれだけ早くその仕事をしなければならないか
• 重要度とは
  • その仕事の深さや価値に関係する
• アイゼンハワー意思決定マトリックスとは
  • 34代アメリカ大統領ドワイト・アイゼンハワーが使ったツール

  	緊急	緊急でない
  重要	タスクを実行する	タスクを先送りする
  重要でない	タスクを任せる	タスクを断る

• 作業キューシステムとは
  • チームの現在の作業を可視化するためのツール（例. Jira）
• イテレーションとは
  • 個人やチームがあらかじめ決めた作業を提供することをコミットしたタイムボックスの期間
  • スクラムだったらスプリントのこと
• イテレーションを使用する最大のメリットは？
  • 現在取り組んでいないほかの作業項目を無視できること
  • 余計なタスクをできる限り排除し、一部のタスクに集中するための確かな方法
• イテレーションでコミットできる作業数に影響を与える変数は？
  • あなたのチームで作業にあたる人数
  • 作業の複雑さ
  • 予定外の作業の量
• 予定外の作業をコントルールする方法は？
  • 入ってくる仕事を評価する
  • その仕事がどこから来たか記録する
  • その仕事が本当に緊急かどうかを判断する。緊急であれば実行する。そうでないなら後回しにする
  • 集中してる作業が終わったら、後回しにした仕事をさらに詳しく評価し、いつ作業するか決める
    • 予定外の作業の優先順位を決めるための質問
      • その依頼はなぜ重要なのか？それは組織の目標に関連しているか
      • その依頼が遅れることによって何が影響を受けるか
      • その依頼の他の関係者は誰か？（たとえば依頼が遅れることで他に影響を受けるのは誰か）

目標や優先順位について書かれた章。チームごとにさまざまな尺度の目標があると、全体の目標達成からズレちゃうかもしれない？といったアンチパターンについて書かれてる。

組織やチームの目標があり、それを達成するために日々の作業があるので、作業の優先順位に迷った時はチームや組織の目標に立ち返るの良さそう。目標設定は、優先順位を判断するためのものでもあるんだなーとあらためて思った。