読書メモ。2025年21冊目。
『システム運用アンチパターン』を読んでの感想となります。（2025/3/8記載）
本の概要
上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。
重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。
組織で必要とされる変化を、エンジニアが行動することで実現する本書は、ソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊です。
引用：
動機
- 先月から延長戦となったDevOps強化月間。
- 『The DevOps ハンドブック』『Effective DevOps』と並んで積んでいた一冊。
- これで多角的に捉えることができる気がする！
感想
『The DevOps ハンドブック』、『Effective DevOps』に比べると読みやすく実践にも踏み込んだ印象。
やはり、DevOpsとは、開発と保守のサイロを（もちろんそれ以外のサイロも）壊すという価値観のもと、各領域内で最適とされていた方式を見直そう、というムーブメントなんだと理解しました。
そのうえで、アンチパターンとしてフォーカスすべき領域を示してくれている本書は、やはり前２冊に比べ具体的なアプローチ方法のイメージがつきます。
ただ、それ以上に足を踏み込んで実現していくとなると、保守メンバーという役割は重要になり、結果サイロのしがらみから離れずらく、結果プラットフォームエンジニアリングが重要しされる、ということも理解できました。
これでいったんDevOps関連の書籍はしばらくは良いかなと思いつつ、もっと早くこの思考を学んでおけばよかった、と思いました。
実践で必要になってきたら、もっと具体的な内容の方も追っていきたい。
忘れたくないメモ
■責任の共有
DevOpsはソフトウェア開発のライフサイクルに関わるすべてのチームが責任を共有することを重視。
開発者中心であった業務を運用チームのメンバーが担い、開発チームのメンバーも同様の業務を行うことで、職能の垣根が低くなる。
■DevOpsの優先順位
DevOpsはチームが一緒に働くことについて考える。
DevOpsはまず人、次にプロセス、そしてその次にようやくツールについて考える。
■4つの柱
DevOpsは文化(culture)、自動化(automation)、メトリクス(metrics)、共有(sharing)の4つの柱に支えられている。
■人為的な障壁を取り除く
伝統的な組織では将来の問題を防ぐために承認プロセスを採用する傾向にある。DevOps組織ではこの衝動を全力で抑える。価値を付加するものは残しつつ人為的な障壁を取り除くことに常に気を配る。
■人為的な障壁の弊害
人為的な障壁はチーム間のパワーダイナミクスを生み出し、依頼をする人と承認をする人の間に親子のような関係をもたらす。権力の不均衡を生み出し、チーム間の摩擦につながります。
■チームメンバーにオーナーシップを求めるために
知識を共有することは責任を共有するために必要。そのためには共有を促進するしくみを作る必要がある。責任の分担が増えると情報をため込むインセンティブが失われる。責任の拡大に対応するためにはシステムの全体像を少なくとも一定のレベルで理解する必要がある。チームメンバーの学習ニーズに何らかの形で対応しなければ、チームメンバーにさらなるオーナーシップを求めることはできない。
■効率的で迅速なデリバリのための自動化
DevOps組織では依頼に対するゲートを追加せず、効率的で迅速なデリバリに重点を置く。こうした効率的で迅速なデリバリは、ボトルネックを追加するのではなく自動化するという解決策によって可能になる。
■手動の承認プロセスの弊害
手動の承認プロセスは簡単に迂回できるため、あるデプロイと別のデプロイの間にばらつきが生じる。プロセスを監査したり、プロセスが毎回正確に手順にしたがっていることを確認する際に、ばらつきがあることは非常に苦痛。何の価値も生み出していない承認プロセスを自動化する。
■本番環境でのアプリケーション動作
開発者は自分たちが開発したシステムが本番でどのように動作するかを詳細に理解することが求められている。システムが成長し、ますます複雑になるにつれ、本番前の環境で完全かつ徹底的にテストするのは不可能になりつつある。本番環境で初めてテストされる処理もあるため、開発者は自分のコードが本番環境でどう動作しているかを理解できなければならない。
■プロダクトの正常が何かの理解
プロダクトを理解することはDevOps組織では必須。プロダクトを理解することで、システムが期待通りに機能しているか確認するためのメトリクスをより深く理解できる。運用チームが異常事態に対応するには、正常が何かを理解している必要がある。ツールに関する専門知識と会社のプロダクトやビジネスに関する知識の組み合わせが運用エンジニアの価値であり必要とされている。
■運用の可視化
運用の可視化はメトリクスとログによって可能になる。メトリクスとはシステムリソースのある時点での測定値。ログはシステムで発生したイベントを記述したメッセージ。ログにはイベントについての説明が記載されており、メトリクスよりも細かな詳細を把握できる。
■システム動作を理解する３つのメトリクス
システムの動作を理解するには、スループット・エラー率・レイテンシが役立つ。これらのメトリクスについて考えるということは測定対象について、どのくらいの頻度でこの処理が発生しているか？どれくらいの頻度で失敗しているか？完了するまでにどのくらいの時間がかかるか？質問をすること。
■メトリクスの種類
メトリクスには一般的にゲージとカウンタという2種類がある。ゲージはある特定の瞬間の数値を表し、カウンタはあるイベントが発生した回数を表し増加し続ける値。
■メトリクスへのプロダクトチームの関与
健全なメトリクスのためにプロダクトチームも巻き込む。レスポンスタイムのようなメトリクスでは、プロダクトチームが何が大切かを判断できる。プロダクトチームに健全なメトリクスを定義するプロセスに参加してもらい、理解してもらうことで、許容できるパフォーマンスについて全員の合意を得ることができる。
■故障モード影響分析 (FMEA failure mode and effects analysis)
FMEAの目的は、プロセスを詳細に調査し、プロセスが失敗またはエラーになる可能性のあるすべての領域を特定すること。ここでいうプロセスとは、システムが正常に動作するために相互作用する必要のあるさまざまなものが相当。
エラーが発生する可能性のある箇所を特定し、エラーを3つの軸で1から10の尺度で評価する。
1つ目の軸は深刻度。そのエラーが発生した場合にどれだけひどいことになるかを評価する。各企業におけるビジネスへの影響から深刻度の順位付けをする。
2つ目の軸は発生頻度。エラーがどのくらい発生しやすいかを評価する。
最後は検出可能性。社内の監視システムやメトリクスがエラーを検出する前に、顧客がそのエラーに気付く可能性を評価する。
3つのスコアを掛け合わせて、エラーにリスク優先度番号(RPN-risk priority number) を付与する。
チームは運用・開発・ビジネスユーザー・そのほかのステークホルダーで構成し、問題に関する専門知識を持ったクロスファンクショナルなチームでなければならない。さまざまな視点から見ることで、プロセスの中でうまくいかない可能性のある事柄をより幅広く知ることができる。
RPNがかなり上位に位置する場合、評価した3つの軸のうち、どれかを下げることができるかを検討する。深刻度、発生頼度を下げるにはかなり大がかりな開発が必要になるが、検出可能性はもっと簡単な解決策がある。役立ちそうなメトリクスを監視し障害を検出できるようにすることで、ほかの問題よりRPNが低くなる可能性がある。
■ログ集約が必要になる背景には文化的な理由
DevOpsの中心的な考え方には、チームに権限を与え可能な限り多くの情報を共有し民主化するというものがある。ログ集約がないと、ログへのアクセスは運用サポートスタッフに限定されるか、開発者がアクセスしやすい場所にログをコピーする必要が生じ、どちらのチームにとっても非常に大きな負担となる。
またログ集約は、ログの新しいビジネスユースケースを生み出す。プロセスの各機能やステップがどのように動作しているかをログに記録することで、ビジネスの流れを垣間見ることができる。技術チームだけでなくエンジニアリング以外のビジネスユニットにも価値をもたらす。
チーム全体の情報を民主化することは、システムの責任と所有権をめぐる組織の文化的変化につながる。
■ダッシュボードの対象者
最初のステップでダッシュボードの対象者を特定すべき。見る人によって必要なものは異なり、その人の目的を念頭に置いてダッシュボードを構築すると、対象者ごとにまったく異なるダッシュボードができあがる。どのメトリクスを表示するか、どのメトリクスを強調する必要があるか、どういった粒度でデータを表示するかなど、ダッシュボードで何を対象にするかを決めることができる。
■テストピラミッド
ピラミッドの底辺では迅速なフィードバックが可能。階層が上がるにつれてテストはより時間がかかるようになり、対象が広範囲になる。
■SLOの３つのカテゴリ
アラート通知への応答時間のサービスレーベル目標(SLO)は通常3つのカテゴリ（確認までの時間、開始までの時間、解決までの時間）に分けられる。
■慎重にアラートを作成する
文脈を無視してアラートを作成することは危険。一度作成したアラートは削除してはいけないという考えが人々に植え付けられる。
■良いアラート
良いアラートは、行動可能である、タイムリーである、適切に優先順位が付けられている、という3つの性質を持つ。
■手作業の弊害
手作業に費やす時間が多ければ多いほど、プロダクトに付加価値を与える時間は少なくなる。ツールの開発や自動化を行わないことは、今を最適化するために未来の一瞬一瞬を犠牲にしている。手作業は個別にはわずかな無駄でしかないように見えても、とんどん膨らんでいき、全体では非常に多くの無駄となる。最大の無駄は作業に必要以上に時間がかかることではなく、待ちが発生すること。
■ツールや自動化が重要になる4つの領域
ツールや自動化が重要になってくるのは4つの領域。
1つ目は待ち時間。待ち時間は多くの手動プロセスにおいて、時間を無駄にし悪影響を及ぼす。プロセスで必要な受け渡しの回数を減らすことで、待ち時間を解消または削減できる。
2つめは実行時間。コンピュータは反復的なタスクを速く実行するのに優れている。単に手動で実行するよりもそれを自動化するほうが、はるかに興味深く満足感を得られる。
3つめは実行頻度。繰り返し作業はエンジニアの集中力を低下させる。コンテキストスイッチが必要となり、前に作業していたタスクに再度戻る際に貴重な時間を失うことになる。また、人間に依存する場合、タスクの実行頻度が制限される。自動化によって、必要に応じて自由にはるかに高い頻度でタスクを実行できる。
4つめは実行のばらつき。人間が行うことには必ず多少のばらつきがあえう。さまざまな種類のばらつきが、将来的に何かに影響を与える可能性がある。
■コラボレーション
ほかのグループに協力を求める場合、コラボレーションが最も重要。自分たちの解決策を主張するのではなく、どういった問題を解決しようとしているのかに焦点を当て、協力して解決策を導き出す。
■システム運用
システムのオペレーターが安全にサポートできるようにするというプロセスは、エンドユーザーから要件や期待を聞き出す際に行うことと根本的には変わらない。システムを運用する人は、システムに対して異なる視点を持つとはいえエンドユーザーであることには変わりありません。
■タスクの捉え方
タスクの複雑さは、専門家としての観点からではなく、タスクを実行する人の観点から考えるべき。複雑なタスクであったとしても、失敗してしまったときのリスクが低い場合は、そのタスクを怖がらずに引き受ける。
■継続的な学習
DevOpsの中心にあるのは継続的な改善という考え方。漸進的な変化が勝利をもたらす。継続的な改善の原動力となるのは、継続的な学習。新しいテクノロジ・既存のテクノロジ・チームの運営方法・チームのコミュニション方法に加えて、これらがどう相互に関連して、エンジニアリング部門という人間と技術のシステムを形成しているのかを学ぶ。
■最適な学びの場
学びの場として最適なのは、物事がうまくいかなかったとき。インシデントは、システムに対するあなたの理解が現実と一致しているかどうかを確かめる決定的な機会です。体系的に構造化された方法で、システムやチームメンバーから教訓を引き出す必要がある。
■非難のない文化
懲罰と非難の文化では、従業員が真実をあまり話さなくなる。率直さを欠くと、インシデントから学ぶ能力が妨げられると同時に、インシデントに関する事実をわかりづらくする。非難のない文化(blameless culture)では、従業員は懲罰を受けることなく、コラボレーションと学習をより促進する環境を作ることができる。誰もが責任逃れをしようとせず、インシデントの原因となった問題や知識のギャップを解決することに関心が向けられる。
■24時間ルール
自分たちの環境でインシデントが発生した場合、24時間以内にそのインシデントに関するポストモーテムを行うべき。インシデントが発生してからドキュメント化されるまでの時間が長くなると、記憶が薄れ、状況の詳細が失われる。また、失敗の背景にある感情やエネルギーを確実に活用する。
■情報の共有方法
情報をどのように共有するかによって、チームのコミュニケーション方法や、責任と所有権の境界線の引き方が決まります。DevOpsはサイロを壊すことを目的としている。この壁は組織構造の中に存在するだけでなく、心や言葉の中にも存在している。自分のチームで情報がため込まれているかどうかや、保護されているかについて敏感になることで、共感する力を養うことができる。自分自身を振り返ることで、個人としてより良い選択ができるようになり、その選択をチームの文化的DNAに組み込むことができる。DevOpsのマインドセットの中核を成す。
■文化
文化が仕事の流め方の風潮を決める。文化はある行動を許容し、別の行動を要求する。
文化とは、あるグループの人々をほかのグループから区別する、共有された価値観、習慣、信念の集合体として定義される。
■最も簡単なところから始める
DevOpsの力を発揮させるために必要なことは1つだけではない。チームがより緊密に連携し、共通の問題を解決し、共通の目標に向かって働くためには、いくつかの領域でいくつかの変更が必要になる。
自分自身の努力で最も価値を提供できるところから始める。ツールよりもソフトスキルの方がより重要。ソフトスキルを組織に根付かせることで、テクノロジを選択する際に、それを使用するチームメンバーの要望にオープンで誠実な対話をしながら、難しい質問をできるようになる。
