「システム運用アンチパターン」を読んだ❗️
サブタイトルに「エンジニアが DevOps で解決する組織・自動化・コミュニケーション」と書いてある通り，迅速に改善を積み重ねつつサービスの価値をユーザーに提供するときに，どういう組織の振る舞いが「悪くて」どういう組織の振る舞いが「良いか」というアプローチを DevOps 視点で学べる良い一冊だった📕
個人的に本書が特に刺さりそうだなーと思った読者層は，比較的レガシーな開発組織にいて「何かうまくいってない」や「何となく今のままではダメそう」とは思うけど，具体的にどう改善したら良いかというアイデアは浮かんでこないような開発責任者や肩書に関係なくもっと良い組織にしたいと感じているエンジニアかなと思う💡
逆に言えば，比較的モダンな（表現は微妙だけど）開発組織にいて，DevOps や SRE という文化が組織に根付いているなら，本書から "新しく" 学べることはあまり多くないと思う．僕自身も本書を読んでいて「へぇそうなんだ！」という新しい発見はあまりなくて「そうそう！そうなの！よくぞ言ってくれましたー！」という感じで "答え合わせ" をしながら読めた✌
目次
本書に出てくるアンチパターンの多くは章タイトルを見るだけでも刺さると思う🔪 ちなみに2章の「パターナリスト症候群」は "組織内で権力を持った人がチームに介入すること" を意味している．
表現として「アンチパターン」と聞くと少しネガティブに聞こえるけど，本書では "こうするべき" という具体的なアプローチまで紹介されているため，学んだことを組織内で実践できるようになっている．
- 1章: DevOps を構成するもの
- 2章: パターナリスト症候群
- 3章: 盲目状態での運用
- 4章: 情報ではなくデータ
- 5章: 最後の味付けとしての品質
- 6章: アラート疲れ
- 7章: 空の道具箱
- 8章: 業務時間外のデプロイ
- 9章: せっかくのインシデントを無駄にする
- 10章: 情報のため込み：ブレントだけが知っている
- 11章: 命じられた文化
- 12章: 多すぎる尺度
読書メモ
どのアンチパターンも良かったけど特に良かった4種類を紹介する💡
僕の今までの経験でも本当に同じようなことが起きている開発組織があったりして，とても他人事には思えなかった (・ω・;)
3章「盲目状態での運用」💬
サービス運用の観点から機能やコンポーネントが今どういう状態なのかを把握できていないことを「盲目状態」と表現していて，実際によくある状況だと思う．本書にも出てくるけど，メトリクスが取得できていなかったり・メトリクスは取得できているけど誰も見ていなかったり・インシデント発生時にログが何も出てなくて原因を特定できなかったり・ログは大量に出ているけどほとんど意味のないノイズだったり．
これは高度なオブザーバビリティを実現するという話ではなく，どちらかと言うと基本的な話として「どういうメトリクスを取得するか」や「どうカスタムメトリクスを活用するか」など，サービス運用における組織の共通認識になるような内容がまとまっていた．本書では "文脈のないログには意味がない" という内容が載っていて，その具体例として トランザクション完了 というメッセージが紹介されていたけど，実際にまったく同じログを見たことがあって笑ってしまった💨
3章に関しては「入門 監視」や「ウェブオペレーション」も併読するとさらに効果があると思う📕
7章「空の道具箱」💬
タスクの自動化に投資できてなく非効率さやヒューマンエラーに課題がある状態を「空の道具箱」と表現していた．しかし自動化したくても時間がなかったり・優先順位が低かったりして，組織で自動化が進まない場合にどうするべきかというアプローチまで紹介されていて良かった👌
僕が7章を読んでいて素晴らしいと感じたのは「スキルセットのギャップ」に関して明確に言及されているところだった．比較的レガシーな開発組織を支援していると，いざ自動化に取り組むことが決まっても技術的なスキルセットのギャップがボトルネックになって，どう自動化すれば良いかというアイデアが出てこなかったり，やってみたけど中途半端な（むしろ劣化した）自動化になってしまったりということがある．だからこそトレーニングを受けたり，他のチームに助けてもらったりすることも重要という話だった．
文化的な側面に関しては「Effective DevOps」も併読するとさらに効果があると思う📕
8章「業務時間外のデプロイ」💬
20時開始など業務時間外にデプロイすることは「ユーザー影響が出にくい」という理由などから正当化されがちだけどアンチパターンだよ🔥と紹介されている．あと普段のデプロイのために組織全体にカレンダーの招待が送られてくるのも「デプロイがリスクのあるイベントになっている証拠」と書かれていて，本当にレガシーな開発組織ほどあるよな〜と思いながら読んでいた．
読み進めていくと「デプロイを日常的に行う理由」や「デプロイ戦略（ブルーグリーン・フィーチャーフラグなども）」が紹介されていたり，ステージング環境は本番環境とまったく同じにはできないという現実の話など，実践的な内容になっていた．8章をまとめると，適切なデプロイ戦略を採用して頻繁にデプロイをすれば，恐怖心も減ってデプロイ自体にリスクを感じなくなるよ❗️という話で良かった．
9章「せっかくのインシデントを無駄にする」💬
インシデント（障害）が発生したときに，ユーザー影響範囲を見定めて，原因を特定して，復旧するけど，その後にポジティブに組織の学びに繋げられていないことが多いのでは？という内容だった．確かに事実を列挙したインシデントレポートはよく見るけど，その後にポストモーテム的なイベントが開催される組織は比較的少ないように思う．また本書では「非難のない文化」を築くことが重要だけどそれは簡単ではなく，責任のなすりつけになってしまって透明性がなくなるとも書いてあった．
本書では「24時間ルール」というアプローチが紹介されていた．インシデントが発生したら24時間以内に必ずポストモーテムを開催するというシンプルな組織運営だけど，発生してしまったインシデントを逆手に取って一歩前に進むための材料としてポジティブに活用しよう❗️というマインドセットを組織に根付かせるために使えそうだった．
ポストモーテム関連の話題は「SRE サイトリライアビリティエンジニアリング」も併読すると良さそうだった📕
またポストモーテムテンプレートもいくつか公開されていて参考になると思う📝
まとめ
「システム運用アンチパターン」を読んだ❗️もちろん本書が銀の弾丸になるわけではないけど，本書に載っているアンチパターンを理解して，自組織の振る舞いと比較しながら一歩一歩改善するアプローチを学べる良い一冊だった📕おすすめでーす ＼( 'ω')／
今は朝活で「システム運用アンチパターン」を読み始めててこれまた良いんだよね〜❗実際に "何かうまくいってない" 開発組織でよく見る光景と打開策がまとまってる感じ📕https://t.co/u6xnnH4RmA
— カック (@kakakakakku) 2023年9月19日
