「システム運用アンチパターン」という書籍を翻訳しました
こんにちは、田中裕一です。今回Jeffery Smithさんが書かれた「Operations Anti-Patterns」という書籍の日本語訳を「システム運用アンチパターン」として出版します。
発売日は4/12ですが、一部の書店では既に店頭に並んでいるようですし、オンラインでも買えるようになっています。是非一読いただけると嬉しいです。
どういった本か
本書を一言で言うならDevOpsによる変革を実践する人のための一冊です。ただ、そういった書籍は「Effective DevOps」や「The DevOpsハンドブック」など、これまでもありました。そういった書籍との違いは本書についての紹介に表れています。
本書は、技術チームの運用担当や開発担当のチームリーダーや一般のエンジニアを対象としています。より上位のマネージャーやシニアリーダーも本書から多くの有用なヒントを得ることができるでしょう。しかし、本書で提示する解決策やアプローチは、読者が限られた権限しか持たないと言う前提で書かれています。組織のより上位のリーダーは、本書ではカバーされていない、より広範なツールを利用できるでしょう。
DevOpsというと目指すべき方向性には同意するけど、実際に何から始めたら良いのかわからないとなることもあると思います。組織の上層部がDevOpsによる変革に積極的ではない場合は尚更です。そういった場合に、組織上の権限を持たないエンジニアが取り組めることについてまとめたのが本書です。
そういった取り組みをアンチパターンという形でまとめているのも、本書のもう一つの特徴です。第２章から第１２章までの各章でそれぞれ１つのアンチパターンを紹介し、それに対して具体的な改善策を提示するという形で本書は書かれています。
２章 パターナリスト症候群
この章は組織内の重厚なプロセスについて扱います。「パターナリスト」という言葉は聞き慣れないかもしれませんが、「強い立場にある者が、弱い立場にある者の利益のためだとして、本人の意志は問わずに介入・干渉・支援すること」(Wikipediaより)を意味します。たとえば開発者がデプロイをするために他のチームから承認を得ないといけないといった状態は、これに当てはまる可能性があります。このように組織内の信頼が低いことによって必要以上に重厚なプロセスになってしまっている状況にどう対処するか紹介します。
３章 盲目状態での運用
この章は、運用しているシステムを適切なメトリクスによって可視化することについて扱います。システムの状態を可視化する際に、とりあえず利用可能なメトリクスを監視してみるというのはやってしまいがちですが、それではシステムの正しい姿を見ることはできません。どのようにして適切にシステムの状態を可視化するかについて紹介します。
４章 情報ではなくデータ
この章ではシステムから得られるデータをどのようにして役に立つ形で提示するかについて扱います。システムから得られるメトリクスを単に並べたダッシュボードでは見る人にとって役にたちません。見る人にとって役に立つダッシュボードをどのように作っていくかについて紹介します。
５章 最後の味付けとしての品質
この章ではテストプロセスについて扱います。プロセスの最後に品質保証のステップを設けるのでは品質の高いソフトウェアを生み出すことはできません。いかに継続的にテストするかについて紹介します。これは語られることが多いトピックでもあるので、開発者の方にとっては馴染みのある話かもしれません。
６章 アラート疲れ
この章ではオンコール体験をどう改善するかについて扱います。アラートにノイズが多いとオンコールを担当するエンジニアは疲弊してしまいます。こういった状況を改善し、いかに持続可能なオンコール体験を生み出していくかについて紹介します。
７章 空の道具箱
この章では自動化が必要だとわかっているけどなかなか自動化が根付かない状況をどう打破するかについて扱います。DevOpsの柱の１つでもある自動化はあらゆる変革において必須の取り組みです。しかし、時間が無いといった理由で後回しにされがちな取り組みでもあります。組織の中でいかに自動化の優先順位を上げ、自動化に必要なスキルを蓄積し、自動化を根付かせるかについて紹介します。
８章 業務時間外のデプロイ
この章ではデプロイが恐怖を伴う一大イベントのようになってしまう状況について扱います。デプロイの中身をレイヤ分けすることによって、ロールバックしやすいシステムを作り出し、継続的にデプロイ（ユーザーに変更を継続的に提供するかどうかはまた別の話）することで、デプロイのリスクを低減する方法について紹介します。
９章 せっかくのインシデントを無駄にする
この章ではポストモーテムについて扱います。システムはどんどん複雑化する一方であり、インシデントを未然に完全に防ぐことは現実的ではありません。そのため、インシデントが起きたときに、そこからいかに学びを得るかが大事になってきます。インシデントを学習の機会と捉え、最大の学びを得るための方法を紹介します。
１０章 情報の溜め込み：ブレントだけが知っている
この章では組織内の一部分に情報が溜め込まれてしまうことについて扱います。情報を意図的に溜め込もうとする人がいないわけではありませんが、多くの場合はコミュニケーションやドキュメント共有の仕組みが適切で無いために意図せずに情報が溜め込まれてしまっています。そういった意図しない情報の溜め込みに気づき、それを改善するための方法を紹介します。
2022/04/13追記：ちなみにブレントというのは「The DevOps 逆転だ！」に出てくる人物で、社内システムについて彼だけが知っている事柄が多くあり、それによって彼がボトルネックになっているという状況から章のタイトルにも彼の名前が冠されています。
１１章 命じられた文化
この章では文化について扱います。文化を変えることはDevOpsの変革の中でも大変な要素です。権限を持たないエンジニアであれば尚更です。しかし、文化というのはトップダウンに文書化・命令したからといって変わるものではなく、組織に所属するメンバーがどういった行動・言葉づかいをするかによって決まります。その変化のきっかけをどう作るかを紹介します。
１２章 多すぎる尺度
この章では目標設定と優先順位づけのプロセスを扱います。各チームがバラバラの目標に向かって活動していたのでは、チーム間の壁は壊れませんし、組織全体の成果も上がりません。そうではなく、各チームが組織全体の目標に向かい、予定外に発生した仕事をその目標に照らし合わせてどう優先順位付していくかについて紹介します。
おわりに
もし紹介したパターンの中で少しでも興味を持つものがあれば、本書を手に取ってもらえると嬉しいです。そして、アンチパターンに対して「あるある」と頷きつつも、実際に行動を起こしてみてください。少しでも本書が皆さんの組織やエンジニアライフをより良いものにする役に立てば幸いです。
この記事が気に入ったらサポートをしてみませんか？