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

開発者の多くが働く最先端でない環境で DevOps の手法を導入する方法を紹介
組織構造を大幅に変更する柔軟性がない場合に、チームに DevOps を導入するための方法を示します。権限を持たない一般のエンジニアを対象に、ソフトウェア開発を良くしていくために必要な DevOps を取り入れる具体的な行動プランを解説します。アンチパターンを具体的なストーリーとして紹介し、そのアンチパターンがなぜ問題なのかを詳述します。

DevOps の本は数多くありますが、その多くは組織を変える権限を持つ立場を前提に書かれています。『システム運用アンチパターン』 (Jeffery D. Smith 著、田中裕一 訳、オライリー・ジャパン発行、オーム社発売、2022 年 4 月刊) は、副題「エンジニアが DevOps で解決する組織・自動化・コミュニケーション」が示すとおり、上層部が DevOps に理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームに DevOps を導入するための現実的な方法を紹介する本です。原書は Operations Anti-Patterns, DevOps Solutions で、版元は開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして取り上げ、管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説する本と位置づけています。

全 12 章の構成、承認プロセスから文化と尺度まで

構成は全 12 章で、序文と本書についてに続き、1 章「DevOps を構成するもの」で DevOps の簡単な歴史、DevOps は何でないか、DevOps の柱となる CAMS を押さえます。2 章以降は 1 章に 1 つのアンチパターンを割り当てる形で、2 章「パターナリスト症候群」 (安全装置ではなく障壁を作ってしまう承認プロセスと、その自動化)、3 章「盲目状態での運用」 (運用の可視化、カスタムメトリクス、故障モード影響分析、ログを価値のあるものにする)、4 章「情報ではなくデータ」 (ダッシュボードのウィジェット、文脈の付与、行の構成、命名)、5 章「最後の味付けとしての品質」 (テストピラミッド、テストスイートの信頼性、継続的デプロイと継続的デリバリ、機能フラグ、DevSecOps) と続きます。後半は 6 章「アラート疲れ」、7 章「空の道具箱」、8 章「業務時間外のデプロイ」、9 章「せっかくのインシデントを無駄にする」、10 章「情報のため込み: ブレントだけが知っている」、11 章「命じられた文化」、12 章「多すぎる尺度」で、本書のまとめと訳者あとがき、索引で締めます。技術寄りの章と組織 / コミュニケーション寄りの章が混在する並びです。

権限のないエンジニアが動かす DevOps という視点

本書の立脚点は、書店向けの紹介文にある「権限を持たない一般のエンジニアを対象に」という一文に集約されています。DevOps を開発と運用の協働の文化として説明する本は多くても、部門を統合する権限も予算もない一人のエンジニアが月曜日から何をすればよいかまで落とし込んだ本は限られます。本書はアンチパターンを具体的なストーリーとして紹介し、そのアンチパターンがなぜ問題なのかを詳述したうえで、2 章では承認の目的を把握し、承認プロセス / ロギング / 通知 / エラー処理をコードとして構成する自動化へ、7 章では組織がもっと自動化しない理由を文化の問題として解き、自動化の目標を決めてスキルセットのギャップを埋める手順へ、と個人の裁量で始められる行動に結びつけていきます。12 章「多すぎる尺度」で組織 / 部門 / チームの目標の階層、優先度 / 緊急度 / 重要度、コミットメントにノーと言う方法、予定外の作業のコントロールを扱うのも、権限がない側が仕事の量を制御するための道具として読める部分です。

アラート疲れ / 時間外デプロイ / 情報のため込みの技術背景

運用の失敗は個別のツール不足ではなく、構造的な繰り返しとして現れます。ノイズだらけのアラートは本当に重要な通知を埋もれさせ、オンコール担当者を消耗させるため、6 章はオンコールローテーションの目的と設定、アラート基準、オンコールへの補償、オンコールの幸福度の追跡まで、人の側の設計を含めて扱います。時間外にまとめて行うデプロイは 1 回あたりの変更量と恐怖心を増やす方向に働くため、8 章はデプロイを日常的に行い、頻繁に行うことで恐怖心を減らし、デプロイアーティファクトの作成とデプロイパイプラインの自動化で失敗への対応をレイヤごとに用意する筋道を示します。3 章の運用の可視化と ログの集約、5 章で扱う 機能フラグ (デプロイした後に機能の有効と無効を切り替える仕組み) は、こうした構造的な失敗への対処を技術で支える側の要素です。9 章の良いポストモーテムの構成要素とポストモーテムの実施は、インシデントから学習しない習慣というアンチパターンへの答えで、インシデント管理 を再発防止までの学習の仕組みとして捉え直す章になっています。10 章の情報のため込みは、意図せずに情報をため込んでいる人を認識し、知識を発見可能にし、チャットツールを有効活用するという、コミュニケーションの設計の問題として扱われます。

ツール手順書を求める人には向かない、組織を変えたい人の一冊

本書は特定のツールや製品の導入手順書ではなく、設定例をコピーして動かす目的には向きません。また、経営層や部門長として組織図から変える立場の人には、権限のない側の行動計画という本書の前提がやや遠回りに映るかもしれません。一方、開発者の多くが働く最先端でない環境で、承認待ちに何日もかかる、アラートが鳴りすぎて誰も見ていない、デプロイが夜間の恐怖イベントになっている、特定の一人しか知らない情報でチームが止まる、といった状況を自分の職場に見つけられる人には、章ごとに該当箇所から読み始めて明日から試せる行動が得られます。DevOps を組織全体の改革としてではなく、自分の裁量の範囲で始められる行動の積み重ねとして捉えたい人にとって、版元がソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊と位置づける本書は、投じた費用と時間の回収が早い選択です。