[書評] システム運用アンチパターン ~エンジニアがDevOpsで解決する組織・自動化・コミュニケーション
DevOps導入のためのシステム運用改善ガイド
この本は、システム運用でよくある非効率的なアンチパターンを整理し、DevOpsの考え方を取り入れた改善策を提案しています。
例えば、システム変更時の非効率な手順や、運用と開発の隔離によるコミュニケーション不足などのアンチパターンが挙げられています。これらの背景や弊害を分析した上で、継続的デリバリーやインフラストラクチャのコード化といったDevOpsのベストプラクティスを適用する方法が解説されています。
DevOpsの導入にあたっての留意点も具体例とともに紹介されており、組織の改善に役立つ内容となっています。2,816円の投資で、システム運用を改善するための一歩を踏み出せる1冊です。
購入先 : O'Reilly Japan - システム運用アンチパターン
原書: Operations Anti-Patterns, DevOps Solutions
著者名: Jeffery D. Smith 著、田中 裕一 訳
出版日: 2022年4月
価格: Ebook 2,816円
1章 DevOpsを構成するもの
DevOpsの定義とその背景について説明しています。DevOpsは単なるツールではなく、チームのコラボレーションと仕事の進め方を変革するものだとしています。また、DevOpsの4つの柱として、文化、自動化、メトリクス、共有(CAMS)を提示し、これらがDevOpsの成果に不可欠な要素だと述べています。
1.1 DevOpsとは?
DevOpsの簡単な歴史と、DevOpsが何でないか(単なるツールではないこと)を説明しています。DevOpsは人とプロセス、そしてその後にツールに焦点を当てているとしています。
DevOpsは2007年ごろに始まったムーブメントで、ソフトウェア開発とIT運用を統合することを目指している
DevOpsはツールだけではなく、人とプロセスに重点を置いている
ツールありきでDevOpsを導入しようとするのは誤りで、人とプロセスを先に構築する必要がある
1.2 DevOpsの柱となるCAMS
DevOpsの4つの柱として、文化、自動化、メトリクス、共有(CAMS)を説明しています。これらはDevOpsの変革を成功させるために必要な要素だとしています。
CAMSはDevOpsの4つの柱(Culture, Automation, Metrics, Sharing)の頭文字
文化:チームの仕事の進め方の基準を変える
自動化:人的資本を平凡な作業から開放する
メトリクス:システムを評価する方法を強化する
共有:知識を共有して成長を促進する
1.3 また別のDevOps本?
この章がなぜ必要なのかを説明しています。経営層の賛同が得られなくても、個人やチームのレベルでDevOpsへの変革を推し進めることができるとしています。
管理職の賛同が得られないからといって、DevOpsのメリットを得ることはできないわけではない
個人やチームのレベルでも変革を推し進めることが可能
本書は組織の一部でもDevOpsを実践するための具体的なアクションを提示する
1.4 本章のまとめ
DevOpsは単なるツールではなく、チームの連携方法を変えるものである点を強調しています。
DevOpsは人とプロセスとツールの変革である
組織の問題を特定し、生産性を阻害する要因に対処する必要がある
本書ではDevOpsへの変革に役立つ具体的なアクションを提示する
2章 パターナリスト症候群
組織内で信頼が欠如している場合に発生するパターナリスト症候群について説明しています。ゲートキーパーの概念と、ゲートキーパーがプロセスを遅くさせる副作用について述べています。そして、自動化によってゲートキーパーを排除し、プロセスを促進する方法を提示しています。
2.1 安全装置ではなく障壁を作ってしまう
ゲートキーパーがシステムの安全面から導入されるが、結果としてプロセスを阻害する障壁となってしまうパターンについて説明しています。
ゲートキーパーは信頼の欠如から導入されるが、プロセスを遅くさせる
ゲートキーパーは局所的最適を目指すあまり、システム全体の俊敏性を犠牲にする
ゲートキーパーはチーム間の権力の不均衡を生む
2.2 ゲートキーパーの導入
ある出来事をきっかけにゲートキーパーがプロセスに導入され、それがプロセスを複雑化させる例を示しています。
一度のミスを防ぐために厳格なゲートキーパーが導入されるが、すべてのプロセスが遅くなる
ゲートキーパーによってプロセスが重厚化し、本来の目的から外れる
2.3 ゲートキーパーの分析
ゲートキーパーがもたらす新たな問題を分析しています。ゲートキーパーによってプロセスが遅くなり、緊急の変更を迅速に適用することが困難になる点を説明しています。
ゲートキーパーによってプロセスが重くなり、迅速な対応が困難に
プロセスを遵守するインセンティブが低下し、回避を試みる可能性がある
プロセスが不可避的にミスを許容する設計になっている
2.4 自動化によるパターナリスト症候群の解消
ゲートキーパーの自動化によってプロセスを改善できることを説明しています。自動化によってプロセスの再現性と一貫性が向上すると述べています。
自動化によってプロセスの再現性と一貫性を高められる
自動化はプロセスを改善し、ゲートキーパーに代わる
自動化は段階的に導入していける
2.5 承認の目的を把握する
ゲートキーパーが解決しようとしている本来の目的を考える必要があると説明しています。ゲートキーパーが懸念している点を自動化で代替できることを示しています。
ゲートキーパーが解決しようとしている目的を考える必要がある
その目的は自動化できる可能性が高い
自動化によってゲートキーパーに代わることができる
2.6 自動化のためのコードの構成
ゲートキーパーの自動化を段階的に実装する方法を説明しています。承認処理、ロギング、通知、エラー処理といった要素を分離して実装することを推奨しています。
承認処理、ロギング、通知、エラー処理を分離して実装する
段階的に自動化を進めることで徐々に置き換え可能
要件変更に対応できる柔軟な設計が必要
2.7 継続的な改善に向けて
自動化の継続的なメンテナンスと改善の重要性を説明しています。自動化コードもアプリケーションコードと同じくらいメンテナンスが必要であるとしています。
自動化は一回限りの作業ではない
継続的なメンテナンスが必要
改善を積み重ねることで徐々に改善できる
2.8 本章のまとめ
ゲートキーパーの排除と自動化の重要性を強調しています。
ゲートキーパーを特定し、その必要性を検証する
ゲートキーパーの目的は自動化できる可能性が高い
段階的に自動化を進めることで徐々に置き換え可能
3章 盲目状態での運用
運用の可視化の重要性について説明しています。適切なメトリクスとログの設定により、システムの状態を把握できるようになるとしています。
3.1 苦労話
適切な可視化がない場合の運用上の問題を事例で説明しています。
運用チームはシステムの挙動を十分把握できていないとトラブルシューティングが困難
開発チームも本番環境での動作を理解する必要がある
3.2 開発と運用の役割を変える
DevOpsにおける開発と運用の役割の変化について説明しています。運用も製品を理解する必要があるとしています。
DevOpsでは開発と運用の役割が変化する
運用も製品を理解する必要がある
運用が製品を理解しないと、単なるAPIに置き換えられる
3.3 プロダクトの理解
運用対象の製品を理解することの重要性を説明しています。製品がどのように動作するかを把握する必要があるとしています。
運用チームは製品の動作を理解する必要がある
それにより、正常か異常かの判断が可能になる
製品理解は運用の可視化に不可欠
3.4 運用の可視化
カスタムメトリクスの作成により、運用の可視化が可能になると説明しています。スループット、エラー率、レイテンシが有用なメトリクスだとしています。
カスタムメトリクスにより運用の可視化が可能
スループット、エラー率、レイテンシが有用
FMEAにより監視すべきポイントを洗い出せる
3.5 ログを価値のあるものにする
ログの集約と構造化の重要性を説明しています。ログから状況を理解するためには、文脈のある適切なメッセージが必要だとしています。
ログの集約により全体像がつかめるようになる
構造化されたログ形式が解析を容易にする
ログメッセージには文脈が必要
エラーログには失敗の詳細を記載するべき
3.6 本章のまとめ
運用の可視化の重要性を強調しています。
製品理解が可視化とトラブルシューティングに重要
スループット/エラー率/レイテンシなどのメトリクスが有用
ログの集約と構造化が分析に役立つ
4章 情報ではなくデータ
データを利用者にとって意味のある情報として可視化する方法について説明しています。ダッシュボードのデザインと構成のガイドラインを紹介しています。
4.1 データではなく利用者から始める
可視化の重要性と、利用者視点からのダッシュボードデザインの必要性を説明しています。
可視化なしの生データでは利用者にとって意味がない
ダッシュボードは利用者視点でデザインする必要がある
4.2 ウィジェット:ダッシュボードの構成要素
折れ線グラフ、棒グラフ、ゲージなどの各種ウィジェットの特徴と利用方法を説明しています。
ウィジェットはデータの可視化パターン
グラフ、ゲージなど状況に応じて使い分ける
4.3 ウィジェットに文脈を与える
色やしきい値、時系列比較などによってウィジェットに文脈を付与する方法を説明しています。
文脈なしのウィジェットは意味がない
色やしきい値などで文脈を付与する
4.4 ダッシュボードの構成
ダッシュボードの行と列の構成、読み手を導くテクニックについて説明しています。
読みやすさを考慮した行と列の配置
視線の流れで情報を伝える
4.5 ダッシュボードの命名
ダッシュボードの名前付け方についてのガイドラインを説明しています。
ダッシュボード名は簡潔で具体的に
提供する情報を反映する名前が良い
4.6 本章のまとめ
データの可視化とダッシュボードデザインの重要性を強調しています。
データをうまく可視化することが重要
ダッシュボードは利用者中心でデザインする
文脈の付与がダッシュボードを価値ある情報にする
5章 最後の味付けとしての品質
品質保証の考え方と継続的デリバリの関係について説明しています。テスト自動化と継続的インテグレーションの重要性を強調しています。
5.1 テストピラミッド
テストの種類とそのバランスの考え方を説明したテストピラミッドの概念を紹介しています。
テストピラミッドはテストの種類とその割合のバランスを示す
下層ほどテスト数を多くすることが重要
5.2 テストの構造
ユニットテスト、統合テスト、E2Eテストの特徴と目的を説明しています。
テストにはそれぞれ目的があり、組み合わせることが重要
ユニットテストはコードの正当性を保証
E2Eテストは顧客体験を模擬
5.3 テストスイートの信頼性
テスト結果を正しく評価することの重要性を説明しています。度重なるテスト失敗への対処法を提示しています。
テスト失敗を放置すると信頼性が失われる
原因究明と改善を継続的に行う
メトリクスに依存しすぎない
5.4 継続的デプロイと継続的デリバリ
頻繁なデプロイとデリバリの関係を説明し、継続的デリバリの必要性を強調しています。
頻繁なデプロイだけでは意味がない
顧客に届けることが重要(継続的デリバリ)
デリバリまで考える必要がある
5.5 機能フラグ
機能フラグによるリリース管理と、デプロイとデリバリの分離について説明しています。
機能フラグでデプロイとデリバリを分離
リリースのタイミングを細かく制御できる
5.6 パイプラインの実行
継続的インテグレーションパイプラインの必要性と、パイプラインを実行するための戦略を説明しています。
パイプラインは品質保証の中核
実行環境を用意することが重要
テスト失敗時の対応がポイント
5.7 テストインフラの管理
テストインフラの構築と管理の重要性を説明しています。適切なインフラ管理が品質と速度に影響するとしています。
テストインフラは品質と速度に影響
適切に管理することが極めて重要
インフラもコードと同様に扱う
5.8 DevSecOps
DevSecOpsの概念と、セキュリティテストの持つ意味を説明しています。
DevSecOpsは開発から運用までのセキュリティ
セキュリティも品質の一部と考える
セキュリティテストをプロセスに組み込む
5.9 本章のまとめ
品質保証の重要性を強調しています。
テストと品質保証がデリバリに不可欠
テスト自動化と継続的インテグレーションが重要
テストインフラの適切な構築と管理が必要
6章 アラート疲れ
アラートの適切な設定と管理の重要性について説明しています。アラート設定のベストプラクティスと、アラートへの対処プロセスについて説明しています。
6.1 苦労話
アラートの乱用によるオペレータの疲弊感についてのエピソードを紹介しています。
アラートは疲弊感を招く可能性がある
アラートは慎重に設定する必要がある
6.2 オンコールローテーションの目的
オンコールローテーションの目的と意義について説明しています。
オンコールはインシデント対応を明確化する
オンコール担当者は顧客の代理人となる
6.3 オンコールローテーションの設定
オンコールローテーションのための目標時間の設定方法を説明しています。
確認、開始、解決までの時間目標を設定
目標は実績に基づき調整する
6.4 アラート基準
アラートしきい値とノイズの多いアラートの設定方法を説明しています。
しきい値は慎重に設定し、頻繁に見直す
ノイズの多いアラートは除去するべき
6.5 オンコールの配置
オンコール担当者のスキルと配置方法を説明しています。
オンコール担当者のスキルセットを定義する
適切な人材配置が重要
6.6 オンコールへの補償
オンコール担当者への適切な補償について説明しています。
金銭的補償、休暇取得の柔軟性など
適切な補償で動機付けする
6.7 オンコールの幸福度を追跡する
オンコール処理状況を追跡し、担当者の幸福度を測定することの重要性を説明しています。
オンコール処理状況を追跡する
担当者の幸福度も測定する
幸福度が低い原因を追及する
6.8 オンコール担当中のタスク
オンコール中に担当者が行うべきタスクについて説明しています。
オンコールサポートプロジェクトへの参加
パフォーマンスレポートの作成
アラート処理を継続的に改善
6.9 本章のまとめ
アラートの適切な設定と管理の重要性を強調しています。
アラートは慎重に設定し、頻繁に調整する
アラート処理を継続的に改善する
オンコール担当者への適切な補償が重要
7章 空の道具箱
ツールの自動化がもたらすメリットと、自動化を推進するための戦略について説明しています。自動化を阻む文化的障壁の克服方法も提示しています。
7.1 社内ツールと自動化が重要な理由
自動化がもたらす効率化とビジネスインパクトのメリットを事例で説明しています。
自動化により生産性と効率が向上する
ビジネスインパクトも大きい
7.2 なぜ組織はもっと自動化しないのか
自動化を進める際の文化的障壁について説明しています。
自動化を文化的優先事項とする必要がある
専任のリソースが必要
ツールありきのアプローチは失敗する
7.3 自動化に関する文化の問題を解決する
自動化の文化的障壁を克服する方法を提示しています。
手動作業を認めない
自動化への「ノー」を支持する
手動作業のコストを明確化する
7.4 自動化を優先する
自動化を組織的に優先するための方法を説明しています。
自動化を公式方針とする
自動化リソースを保護する
自動化結果を評価指標にする
7.5 自動化の目標を決める
自動化の目標設定と達成の方法を説明しています。
自動化を標準要件とする
自動化対象タスクを特定する
学習時間を確保する
7.6 スキルセットのギャップを埋める
自動化のスキル獲得方法と、所有権放棄の重要性を説明しています。
自動化スキルはオンボーディングで獲得
所有権放棄が共有と改善に重要
7.7 自動化のアプローチ
自動化対象のタスク選定基準と、自動化設計の注意点を説明しています。
安全性と複雑さでタスクを分類する
安全な設計とエラー処理が重要
段階的に進めるのがベスト
7.8 本章のまとめ
自動化の重要性とその促進方法を強調しています。
自動化は生産性と品質に大きく影響
文化的障壁の克服が重要
段階的かつ継続的に進める
8章 業務時間外のデプロイ
デプロイに関する不安感とその原因について分析しています。頻繁なデプロイとロールバック可能なデプロイの重要性を説明しています。
8.1 苦労話
デプロイ時の不安から、デプロイが業務時間外に実施されている例を紹介しています。
デプロイへの不安が業務時間外のデプロイを招く
この慣行は長期的には望ましくない
8.2 デプロイのレイヤ
デプロイプロセスの異なるレイヤ(コード、フリート、データストアなど)を説明しています。
デプロイにはコード、フリート、データストアのレイヤがある
レイヤごとのロールバックが可能なデプロイを目指すべき
8.3 デプロイを日常的に行う
頻繁なデプロイがもたらすメリットと、そのための環境構築の重要性を説明しています。
頻繁なデプロイで習熟度が向上する
本番同等のステージング環境が重要
8.4 頻繁に行うことで恐怖心を減らす
頻繁なデプロイによってデプロイへの不安が軽減されることを説明しています。
頻繁にデプロイを行うことで習熟し、恐怖心が減る
デプロイを日常業務の一部とする
8.5 リスクを減らして恐怖心を減らす
デプロイリスクを軽減する方法を説明しています。
機能フラグでリスクを減らす
ロールバック可能なデプロイを目指す
リスク軽減が業務時間内のデプロイを可能にする
8.6 デプロイプロセスの各レイヤでの失敗への対応
各デプロイレイヤでのロールバックパターンを説明しています。
各レイヤでのロールバックパターンを確立する
ロールバック可能なデプロイを目指す
8.7 デプロイアーティファクトの作成
デプロイパッケージの作成とバージョン管理の重要性を説明しています。
デプロイパッケージをバージョン管理する
再現可能なデプロイを可能にする
8.8 デプロイパイプラインの自動化
デプロイパイプラインの自動化パターンを説明しています。
デプロイ手順を自動化スクリプトとして記述する
手順の漏れを防ぎ安全性を高める
8.9 本章のまとめ
頻繁でロールバック可能なデプロイの重要性を強調しています。
頻繁なデプロイで習熟度が向上する
ロールバック可能なデプロイを目指すべき
デプロイパイプラインの自動化が安全性を高める
9章 せっかくのインシデントを無駄にする
インシデント後の振り返りと学習の重要性について説明しています。インシデントからの教訓を最大限に活用するためのポストモーテムの方法を紹介しています。
9.1 良いポストモーテムの構成要素
効果的なポストモーテムの特徴として、メンタルモデルの作成、24時間ルールの順守、ルール設定の重要性を説明しています。
メンタルモデルの作成が理解を深める
24時間以内の開催が重要
ルール設定で建設的な議論を促す
9.2 インシデントの発生
仮のインシデントシナリオを提示し、その事例を用いてポストモーテムの進め方を説明しています。
インシデントの事例を設定
事例を用いてポストモーテムの進め方を説明
9.3 ポストモーテムの実施
インシデント事例に基づき、ポストモーテムの具体的な進め方を提示しています。参加者の選定、タイムライン作成、アクション項目の設定などについて説明しています。
参加者は関係者を選定する
タイムラインで経緯を整理
アクション項目の設定とフォローが重要
9.4 本章のまとめ
インシデントからの継続的学習の重要性を強調しています。
インシデント後のポストモーテムが重要
24時間以内の開催を心がける
タイムラインとアクション項目で理解を深める
10章 情報のため込み:ブレントだけが知っている
組織内での情報共有の重要性について説明しています。情報が特定の人に限定されることで生じる弊害と、それを防ぐ方法について述べています。
10.1 どのように情報がため込まれているかを理解する
情報がため込まれる原因(ドキュメントの欠如、アクセス制限など)を分析しています。
情報がため込まれることで弊害が生じる
原因を理解することが解決の第一歩
10.2 意図せずに情報をため込んでいる人を認識する
意図せず情報をため込む人の特徴(ドキュメント軽視、用語の煩雑化、アクセス制限など)を説明しています。
情報をため込む人の特徴を知る
ため込みが意図的でないケースもある
10.3 コミュニケーションを効果的に構築する
効果的なコミュニケーションの構成要素(トピック、対象者、キーポイント、行動喚起)を説明しています。
コミュニケーションには構成要素がある
要素を明確化することで効果的に
10.4 知識を発見可能にする
ナレッジベースの構築と、学習の習慣付けの重要性を説明しています。
ナレッジベースで知見を共有化
学習を日常的な習慣とする
10.5 チャットツールの有効活用
チャットツールのメリットと、その活用方法について説明しています。
チャットは情報共有に有効
適切な利用ルールが重要
10.6 本章のまとめ
情報共有の重要性を強調しています。
情報を独占することの弊害がある
情報を発見・共有できるようにする
ナレッジ共有とチャットの活用が有効
11章 命じられた文化
組織文化についての考え方と、文化を
変革する方法について説明しています。文化は上から命じられるものではなく、個人の行動の積み重ねから生まれるとしています。
11.1 文化とは何か?
文化の構成要素(価値観、習慣、信念)を定義し、文化の特性を説明しています。
文化は価値観、習慣、信念からなる
文化は暗黙知として共有される
11.2 文化はどのように行動に影響を与えるか?
文化が個人の行動判断に与える影響のメカニズムを説明しています。
文化は行動のフィルターとなる
文化に合致する行動が好まれる
11.3 文化を変えるには?
文化変革の方法(文化の共有化、習慣化、言語の活用など)を説明しています。
文化は個人の行動の積み重ねで変化する
習慣と言語使用で変革できる
11.4 文化に合った人材
文化変革に合致した人材の採用と、面接での評価方法を説明しています。
文化変革に合った人材採用が重要
面接での適性評価がカギを握る
11.5 本章のまとめ
上からの文化変革は困難である点を強調しています。
文化は上から命じられるものではない
個人の行動変容が文化を変える
適した人材の採用が重要
12章 多すぎる尺度
組織の目標設定と優先順位付けの方法について説明しています。目標の階層化と、適切な作業選択基準の重要性を述べています。
12.1 目標の階層
組織・部門・チームの目標設定と、目標の確認方法を説明しています。
目標には組織・部門・チームの階層がある
目標の関連性を確認することが重要
12.2 どの仕事に取り掛かるかに意識的になる
作業の優先順位付け基準(重要度、緊急度、優先度)と、アイゼンハワーの意思決定マトリックスの考え方を説明しています。
重要度と緊急度で優先順位を付ける
アイゼンハワーのマトリックスが有効
12.3 チームの仕事を整理する
作業の細分化とイテレーション計画の方法を説明しています。
作業を細分化して分割管理する
イテレーションで作業を計画的に進める
12.4 予定外の作業
予定外作業への対応として、作業のコントロールと対応パターンを説明しています。
予定外作業のコントロールが重要
バッファタスクの設定などにより対応
12.5 本章のまとめ
適切な目標設定と優先順位付けの重要性を強調しています。
目標の階層化が重要
優先順位付け基準を設定する
作業を計画的に進める
おわりに
本書のまとめとして、以下の3点を強調したいと思います。
1点目は、DevOpsは単なるツールの話ではなく、人とプロセスの変革であるということです。新しいツールを取り入れる前に、チームの協調性やプロセスの改善に取り組む必要があります。
2点目は、組織の分析と意識的な改善が重要だということです。本書で紹介した各アンチパターンは、多くの組織で見られる一般的な問題です。自分の組織に当てはまるパターンを見つけ、本書の提案を参考に改善を図ることが肝要です。
3点目は、継続的な改善が必要だということです。DevOpsへの変革は一朝一夕には達成できません。小さな改善を積み重ね、徐々に大きな変化を実現していくことが大切です。自動化への投資など継続的な取り組みが成果をもたらします。
参考文献
Jeffery D. Smith 著、田中 裕一 訳 (2022) , O'Reilly Japan - システム運用アンチパターン
yuichielectric (2022) , 「システム運用アンチパターン」という書籍を翻訳しました｜yuichielectric
この記事が気に入ったらサポートをしてみませんか？