システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション | Jeffery D. Smith, 田中 裕一 |本 | 通販 | Amazon
エンジニアがDevOpsで解決する組織・自動化・コミュニケーション。早速お薦めしたく書いています。読書感想文です。
感想5点
良いぞ。周りに薦めたい
- 百聞一見。目次だけでも: https://www.oreilly.co.jp/books/9784873119847/#toc
- 特に自分にとって良かったのは以下
- 9章 せっかくのインシデントを無駄にする
- 10章 情報のため込み：ブレントだけが知っている
- だが、一番スゴイのは11章かもしれない
- 「文化を変えようと思うのであれば、文化がどのように共有されているかを理解すること」
- コロナ以前は
- 議事録
- 会議
- 机横での雑談
- 飲み会
- タバコなどなどあったが
- コロナ以降、リモートワーク。
- 公式には
- 部内全体
- チームの会議
- Wiki
- 非公式には
- 勉強会
- #times
- あとは自由に飲み会とかもされているのだとおもうが、表立ってはよく分からない
- ... となったときにやはり勉強会、#times、あなどれないぞ、と思った。
- 公式には
理想論だけではない
- 「本書は、技術チームの運用担当や開発担当のチームリーダーや一般のエンジニアを対象としています。より上位のマネージャーやシニアリーダーも本書から多くの有用なヒントを得ることができるでしょう。しかし、本書で提示する解決策やアプローチは、読者が限られた権限しか持たないという前提で書かれています」。
ただのアンチパターン集ではない
- アンチパターン集、というだけではただのあるある集。
- ...だと困るなと思ったがちゃんと処方箋が書かれていてうれしい。
- どの章から読んでも使える。
自分の力でどうにかできそうなこともある
- すべてが自分だけでどうにかなる対処法ということはない（一部は、上司や組織でいいねとならないと実践できないものもある）が、自分から始められそうなものもある。それだけでも嬉しい。
- 上司や組織の協力がいりそうなものに関しては、この本を輪読会とかできたらいいのかもしれない。という点でいずれにしても「良いぞ」と思う人が増えたら嬉しいのでこの記事を書いています。
組織の悩みを抱えているひとには刺さる本
- 色々今じぶんが取り組んでいることが当たらずと言えども遠からずだとわかり、良かった。
- 特に言葉の端々が良い。
要点
1章 DevOpsを構成するもの
- DevOpsとは？
- ソフトウェア開発の考え方をほかの役割に適用するようなソフトウェア開発手法のこと。
- ソフトウェア開発のライフサイクルに関わるすべてのチームが責任を共有する。
- 従来は開発者中心であった業務を運用チームのメンバーが担い、開発チームのメンバーも同様の業務を行うことで、職能の垣根が低くなる。
- 本章のまとめ
- DevOpsの真の目的は仕事に対する見方や、異なるチームにまたがるタスクの関係を再定義すること。
- 変化をもたらすためには、組織内の問題を検証し、生産性を低下させる要因に対処する方法が必要。
- 文化を変える必要性がある一方、この本を読んでいる皆さんの多くはエンジニアであり具体的な行動に着目しがち。だが、企業文化がその状況に与えている影響を強調する。
2章 パターナリスト症候群
- パターナリスト症候群
- あるグループがほかのグループに対して親のような関係を築いている
- 仕事の進め方やタイミングをゲートキーパーと呼ばれる、権力を持つ人に委ねる。
- 安全装置ではなく障壁を作ってしまう
- CAMS モデルに沿ってこれらを実現する。CAMS とは culture（文化）、automation（自動化）、metrics（メトリクス）、sharing（共有）の略語。
- 本章のまとめ
- 不要なゲートキーピングがないかプロセスを検証する。
- なぜ承認が必要なのか理解する。
- 承認プロセスが解決しようとしている懸念事項を自動化で解消する。
- 自動処理におけるログ・通知・エラー処理に関する懸念事項をうまく解決できるような設計をする。
- 自動化の継続的な改善をする。
3章 盲目状態での運用
- 運用の可視化
- カスタムメトリクスの作成
- 何を測定するかを決める
- 健全なメトリクスを定義する
- ログを価値のあるものにする
- ログの集約
- 何を記録すべきか？
- 適切なレベルでログを出すかどうかはエンジニア次第。適切なログレベルが設定されていないと何かの情報をログから探すことが困難になる。もしあなたがエラーを探しているのであれば、おそらくステータスが ERRORであるログエントリを解析の対象とするようフィルタリングする。しかし探しているエラーメッセージが実際にはINFOとして記録されていた場合、関係のないメッセージに埋もれる。
- ログメッセージを適切なカテゴリに分類することは、メッセージを記録することと同じくらい重要。
- たとえば「クレジットカードの認証を完了できませんでした」というエラーメッセージは最悪である。これは何を意味しているのか？注文は拒否されたのか？それとも中途半端な状態なのか？ユーザーには通知されるか？このエラーには必要な情報が含まれていないため役に立たない。
- 本章のまとめ
- ログメッセージが真に有益であるためには適切なログレベルで記録される必要がある。
- ログメッセージには、そのメッセージの文脈を常に含める必要がある。
4章 情報ではなくデータ
- データではなく利用者から始める
- うまく可視化されていないメトリクスは役に立たず、大事な情報が山のような数字というノイズに埋もれてしまう。メトリクスの値をまとめたスプレッドシートをMicrosoft Excelで利用者に提示するのは、よほどの変わり者かデータサイエンティストだけである。
- 誰がこのダッシュボードを見るのか？
- このダッシュボードの目的は何か？
- 上記の目的を考慮したうえで、このダッシュボードが伝える必要のある情報のうち上位3～5個の項目は何か？
- 本章のまとめ
- 利用者のことを考えてダッシュボードを設計する。
- 利用者が値の良し悪しを知ることができるように、ウィジェットに文脈を与える。
- 最も重要な項目が最初に目に入るようにする。
- 関連するウィジェットをグループにまとめて互いに閲覧・比較しやすくする。
5章 最後の味付けとしての品質
- テストピラミッド
- テストの構造
- ユニットテスト
- 統合テスト
- エンドツーエンドテスト
- 継続的デプロイと継続的デリバリ
- 本章のまとめ
- 継続的デリバリにより、アプリケーションを常にリリース可能な状態にする。
6章 アラート疲れ
- アラート疲れは、オペレータが頻繁に多くのアラートにさらされることで、アラートに鈍感になってしまう場合に起こる。オペレータが偽のアラートに慣れてしまうと、どんどん鈍感になっていき、アラートへの応答時間が悪化する。これによりアラートシステムの全体的な有効性が低下する。
- ツール
- PagerDuty（https://www.pagerduty.com）
- VictorOps（https://www.victorops.com）
- Opsgenie（https://www.opsgenie.com）
- Oncall（https://oncall.tools/）
- オンコールローテーションの設定
- 確認までの時間
- 開始までの時間
- 解決までの時間
- オンコールローテーションの配置
-
オンコールへの補償
- 金銭的補償
- 休暇
- 在宅勤務の柔軟性の向上
-
チームメンバーはいつアラートを受けているか？
- 火曜日の午後2時にアラートを受け取っても、日曜日の午後2時にアラートを受け取る場合ほどには気にならない。勤務時間外にアラートを受けると、明らかに体験は悪化する。ここでは時間帯を次の3つに分類するだけで十分。
- 就業時間：通常オフィスにいる時間帯。たとえば月曜から金曜の午前8時から午後5時 まで
- 勤務時間外：通常は起きていて仕事をしていない時間帯。一般的には月曜から金曜の午後5時から午後10時まで、土曜と日曜の午前8時から午後10時まで
- 就寝時間：電話がかかってくると睡眠を邪魔してしまう可能性が高い時間帯。
- 火曜日の午後2時にアラートを受け取っても、日曜日の午後2時にアラートを受け取る場合ほどには気にならない。勤務時間外にアラートを受けると、明らかに体験は悪化する。ここでは時間帯を次の3つに分類するだけで十分。
- エンジニアが直面したさまざまなオンコールのシナリオを議論し、ほかの分野の人たちを会話に巻き込むのも良い。これにより、運用スタッフと開発スタッフが、本番環境で運用中に直面している問題について話し合う機会を得ることができる。
- 本章のまとめ
- アラートは、行動可能で、タイムリーで、適切に優先順位付けされている必要がある。
- ノイズの多いアラートはアラート疲れを起こし、アラートを役に立たないものにしてしまう
- オンコール業務はスタッフの負担になる。何らかの形で補償しよう。
- オンコールによってエンジニアの生活をどれだけ乱してしまっているかを理解するために、オンコールの幸福度を追跡しよう。
- エンジニアが根本的な修正を行う時間を確保できるようにオンコールのローテーションを構成しよう。
7章 空の道具箱
- 社内ツールと自動化が重要な理由
- 自動化による改善
- 自動化によるビジネスへの影響
- なぜ組織はもっと自動化しないのか
- 自動化を文化的な優先事項と位置付ける
- 自動化とツール開発のための人員
- スキルセットのギャップを埋める
- 自動化の計画はすばらしいものだが、自動化を優先するというハードルを越えたとしても、一部の組織ではスキルセットにギャップがあるという現実に対処しなければならない。さまざまな理由から、自動化を活用する必要のあるチームが必ずしも自動化を実現するためのスキルを持っているとは限らない。主にうぬぼれやワークフロー全体の最適化ができていないことが原因。
- 技術部門内のチーム間に強固な壁を設けることに価値はあるのか？壁を設ける動機のほとんどは、チームに対するインセンティブの設計に由来する。各チームは、自分たちの目先の目標を達成することに集中するあまり、ほかのチームのパフォーマンス低下が自分たちの目標にどのような影響を与えるかを認識していない。
- 必要なスキルは組織内に存在し、実現する必要があることをそのチームに支援してもらうことは、単に良い考えというだけでなく、DevOpsの理念にとっても非常に重要。
- 新しいスキルセットの構築
- Lunch and Learn
- 本章のまとめ
- スキルセットのギャップを解消するために、組織内のほかの部署を活用しよう。
8章 業務時間外のデプロイ
- 本章のまとめ
- 恐怖心はリリースサイクルを遅くする主な要因。
- リスクが軽減され、正常な状態への復帰が迅速かつ十分に理解されているときには恐怖心は軽減される。
9章 せっかくのインシデントを無駄にする
- 非難のないポストモーテムの実施
- インシデント発生時に人々が持つメンタルモデルへの対応
- システムの改善を促進するアクションアイテムの作成
- 良いポストモーテムの構成要素
- メンタルモデルの作成
- 人々がシステムやプロセスをどのようにとらえているかを理解することは、失敗がどのように起
こるかを理解する伴となる。システムを扱うとき、あるいはシステムの一部であるとき、そのシステムに対してメンタルモデルを作成する。
- 人々がシステムやプロセスをどのようにとらえているかを理解することは、失敗がどのように起
- 24時間ルールの遵守
- ポストモーテムのルール設定
- 人を直接批判してはならない。行動や振る舞いに焦点を当てる。
- 誰もが、その時点で得られた情報の中で、最善の仕事をしたと考える。
- 今となっては明白な事実であっても、その場ではあいまいだった可能性があることを認識する。
- 人ではなくシステムを責める。
- 最終的な目標は、インシデントに関与したすべての要素を理解することである。
- メンタルモデルの作成
- インシデントの発生
-
ポストモーテムの実施
- ポストモーテムに招待する人を選ぶ
- タイムラインの振り返り
- アクションアイテムの定義とフォローアップ
- ポストモーテムのドキュメント化
- ポストモーテムの共有
- 本章のまとめ
- 非難し合うようなポストモーテムは効果的ではない。
- 意思決定をよりよく理解するために、エンジニアのシステムに対するメンタルモデルを理解しよう。
- アクションアイテムでは、誰がいつまでに何をするのかを定義しよう。
- ポストモーテムをドキュメント化し、それぞれの対象者ごとに節を設けよう。
- すべてのポストモーテムを同一の場所で共有しよう。
10章 情報のため込み：ブレントだけが知っている
-
どのように情報がため込まれているかを理解する
- 情報がため込まれていることに気付く
- ライトニングトークを利用して関心を引く
- ランチ＆ラーンを利用する
- コミュニケーションの手段としてのブログや執筆
- 外部のイベントやグループを利用して知識の共有化を図る
-
意図せずに情報をため込んでいる人を認識する
- ドキュメントを大切にしない
- ドキュメントは最終的なゴールではない。最終的なゴールは情報の共有。
- 抽象化vs.難読化
- アクセス制限
- ゲートキーパーの行動を評価する
- 悪意はなくむしろ善意で溜め込んでいるケースが思い当たる。
- 人々が意図せず情報をため込んでしまうケースはある。そういった人々は、どこにでもいるような、良心を持っている場合が多い。持っている情報にアクセスするために必要なゲートキーパーに自分がなっていないかどうか振り返ることで、情報をため込んでしまう可能性を評価しよう。
- ドキュメントを大切にしない
-
コミュニケーションを効果的に構築する
- トピックの定義
- 対象者の定義
- キーポイントの説明
- 行動喚起の提示
-
知識を発見可能にする
- ナレッジストアの構築
- 共通の辞書を使用する。
- 1つのマスタドキュメントにリンクされた、階層構造のドキュメントを作成する。
- 部門ではなく、トピックを中心に文書を構成する。
- 学習の習慣付け
- チャットツールの有効活用
- 会社の作法を確立する
- チャットだけではない
- ナレッジストアの構築
- 本章のまとめ
- SMGのタイプに応じて、さまざまな形式で知識共有することを許容しよう。
- 標準的なドキュメントの代わりに、学習のための習慣をつけよう。
- 情報の検索を容易にするために、ドキュメントの保管場所に構造を作ろう。
- 情報のゲートキーパーは、意図しない情報のため込みの原因となる。
11章 命じられた文化
- 文化を構成する要素の理解
- 文化が行動に与える影響
- 変化を促すための新しい文化的振る舞いの創出
- 企業文化にマッチした人材の採用
- 採用面接の構成
- 文化とは何か？
-
もしあなたが本章のタイトルを見て、「うちの会社にはすでに卓球台とビールタップがあって、 文化には定評がある！」と思っているのなら、本章を2回読んだほうが良いでしょう。文化とは、オフィスパーティでの楽しいアクティビティや、休憩室に用意されているグルテンフリーのスナックの種類の多さではありません。
- ほんとそれ。制度とかじゃないのだわ
- エンロンは、2000年にフォーチュン誌の「アメリカで最も働きがいのある100社」の1つに選ばれ、その要因として、文化とすばらしい従業員が挙げられていた。
- しかし実際の文化は、公言された文化とは根本的に異なった。トップから現場の従業員に至るまで、福利厚生は従業員を大切にするようなものであったかもしれませんが、会社を導く倫理基準は腐っていた。
- 文化的価値観
- 文化的規範とは、根底にある価値観を表現する行動や活動。集団が自分たちの価値観を実現するために作るルールや行動。たとえば、有給の家族休暇という文化的規範は、家族を支援するという文化的価値観を表したもの。
- 文化的習慣
- 信念**
-
もしあなたが本章のタイトルを見て、「うちの会社にはすでに卓球台とビールタップがあって、 文化には定評がある！」と思っているのなら、本章を2回読んだほうが良いでしょう。文化とは、オフィスパーティでの楽しいアクティビティや、休憩室に用意されているグルテンフリーのスナックの種類の多さではありません。
- **文化はどのように行動に影響を与えるか？
- 信念によって、疑問を感じない文化が生み出され、より良い方法は実現可能性が非常に低く、試みることさえも愚かに思えてしまう。
- 文化を変えようと思うのであれば、文化がどのように共有されているかを理解すること。
-
文化を変えるには？
- 文化の共有
- たとえば、「わからない」という言葉がある。このようにシンプルなことを率直に言えることで、チームや組織の多くの文化的価値観や規範を伝えることができる。
- すべてを知らなければならないというプレッシャーを克服して「わからない」と言えることは、仕事の場ではなかなか見かけられない、人の弱さをさらけ出す。この弱さは、ミスや偏見、誤った信念を持つ人間であってもかまわないという意味で、チームメンバーを人間らしくする。自分自身と他人について率直な感覚を植え付けられる。誰かのスキルセットが不足しているという懸念が、その人の地位や肩書きの価値を非難するものではなくなる。
- 言葉・物語・習慣は、文化を伝える3つの重要な方法（良くも悪くも）。
- 個人が文化を変えることができる
- 会社の価値観を調べる
- 習慣を作る
- 習慣と言葉を使って文化的規範を変える
- 文化の共有
- 文化に合った人材
- 古い役割、新しい考え方
- シニアエンジニアへのこだわり
- シニアエンジニアを採用する場合は、何をもってシニアとするかを定義することが重要。
- 候補者との面接
- 「読み取りの多いデータベースのパフォーマンスを向上させるために、あなたなら何をしますか？」
- 候補者の評価
- 何人の候補者と面接をするか？
- 本章のまとめ
- 言葉や習慣を通じて文化を変える。
12章 多すぎる尺度
- チーム目標の設定
- チームが仕事を受け付けるためのシステムの構築
- 予定外の作業への対処
- 何に取り組むかの決定
- 目標の階層
- 組織の目標
- 部門の目標
- チームの目標
- 目標の確認
- どの仕事に取り掛かるかに意識的になる
- 優先度、緊急度、重要度
- アイゼンハワーの意思決定マトリックス
- コミットメントにノーと言う方法
- チームの仕事を整理する
- 作業を細分化する
- イテレーションの作成
- 予定外の作業
- 予定外の作業のコントロール
- 予定外の作業への対応
- 本章のまとめ
- 緊急度と重要度によって仕事を分類
- タスクの優先順位を4つに分けて管理する「アイゼンハワー・マトリクス」とは？ - GIGAZINE
参考記事
まとめ
スライド
訳者さんよりコメント頂けて私も嬉しいです。
また上記太字、語り合いたい箇所多数。最後に印象的なのが
組織の外でDevOpsについて語り合えるコミュニティを見つけることをお勧めします。
とのこと。
『システム運用アンチパターン ――エンジニアがDevOpsで解決する組織・自動化・コミュニケーション』は、誰が読み、実践すべきことが書かれているのか、その「誰」を考えながら読んでほしい1冊だった - Magnolia Tech
ともかく面白かったです。まだ読みます。以上です～