朝活として最高の書籍である『システム運用アンチパターン』を読んだので読書感想文

はじめに

SREという信頼性の観点からのプラクティスや運用技術を実施出来るためのプロダクトの開発をしている身からすると『システム運用アンチパターン』はまさに様々な課題がわかりやすく言語化されており素晴らしい書籍で、熟練の運用エンジニアとお話ができるような経験ができました。このエントリーは『システム運用アンチパターン』を読んでみた中での感想文となります。

www.oreilly.co.jp

『システム運用アンチパターン』目次

1章 DevOpsを構成するもの

1.1 DevOpsとは?
1.2 DevOpsの柱となるCAMS
1.3 また別のDevOps本?
1.4 本章のまとめ

2章 パターナリスト症候群

2.1 安全装置ではなく障壁を作ってしまう
2.2 ゲートキーパーの導入
2.3 ゲートキーパーの分析
2.4 自動化によるパターナリスト症候群の解消
2.5 承認の目的を把握する
2.6 自動化のためのコードの構成
2.7 継続的な改善に向けて
2.8 本章のまとめ

3章 盲目状態での運用

3.1 苦労話
3.2 開発と運用の役割を変える
3.3 プロダクトの理解
3.4 運用の可視化
3.5 ログを価値のあるものにする
3.6 本章のまとめ

4章 情報ではなくデータ

4.1 データではなく利用者から始める
4.2 ウィジェット:ダッシュボードの構成要素
4.3 ウィジェットに文脈を与える
4.4 ダッシュボードの構成
4.5 ダッシュボードの命名
4.6 本章のまとめ

5章 最後の味付けとしての品質

5.1 テストピラミッド
5.2 テストの構造
5.3 テストスイートの信頼性
5.4 継続的デプロイと継続的デリバリ
5.5 機能フラグ
5.6 パイプラインの実行
5.7 テストインフラの管理
5.8 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 良いポストモーテムの構成要素
9.2 インシデントの発生
9.3 ポストモーテムの実施
9.4 本章のまとめ

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.1.1 組織の目標
    12.1.2 部門の目標
    12.1.3 チームの目標
    12.1.4 目標の確認
12.2 どの仕事に取り掛かるかに意識的になる
    12.2.1 優先度、緊急度、重要度
    12.2.2 アイゼンハワーの意思決定マトリックス
    12.2.3 コミットメントにノーと言う方法
12.3 チームの仕事を整理する
    12.3.1 作業を細分化する
    12.3.2 イテレーションの作成
12.4 予定外の作業
    12.4.1 予定外の作業のコントロール
    12.4.2 予定外の作業への対応
12.5 本章のまとめ
本書のまとめ
訳者あとがき
索引

特徴と感想

ハードスキルというよりソフトスキルを得るための書籍である

本書のタイトルや目次を見ると、本書はDevOpsの概念やアンチパターンの紹介の書籍かと思われるが CAMS(文化、自動化、メトリクス、共有)についてのソフトスキル(ツールや道具ではなく)を組織や個人で実践するためのHowTo本だという印象を受けました。運用(に関わるソフトウェア)エンジニア版の7つの習慣(語弊あり)。それぞれの章は奥が深く、章で取り上げているものはソフトスキルに絞って知識をバランス良く記載していると感じました。

DevOpsとSREの違い

今からSREのキャリアを目指す方には混乱させてしまうかもしれないのでざっくり、DevOpsとSREの違いについて少し解説していきます。「class SRE implements DevOps」という考えが良い回答かなと思います。 「class SRE implements DevOps」は、「SREはDevOpsというinterfaceの実装である」という意味を表します。「DevOps = 思想」という定義に対し、それを具体化し実装したものがSREであるという考えです。DevOpsにも以下の5点のような考え方がありSREにも似たような考え方がありますよね?

  • 組織のサイロの削減(風通しのよい組織の実現)
  • エラー発生を前提とする(100%を目指さない)
  • 段階的に変更を行う(一気にすべてを変更しない)
  • ツールと自動化を活用する(サービス成長と正比例で運用工数を増やさない)
  • 全てを計測する(モニタリングに基づく数値設定が重要)

ただ、上記はあくまで思想、概念でしかなく、具体的な方法論ではありません。これを具体的にどのように行うかを「トイルの削減・自動化」「SLI/SLOの設定による目標定量化」といった形で、誰でも用いられるように体系化させたものがSREといえます。本書はDevOpsのソフトスキル面を主に扱ってるそのため、ソフトウェアの運用に関わる人であればどのレベルの人が読んでも良いと思います。また、本書はSREを目指す方が読んでも学びになる書籍だと思います。

まとめ

「システム運用アンチパターン」はシステム運用に関わったことがある人があの時、本書を読んでいればなにかが変わったかもしれないと思えるほど学びのある。なぜ、それがイケてないか優しく説明してくれる素晴らしい熟練の先輩との対話のような一冊でした。

特に本書の『DevOps文化は必ずしもA地点からB地点へ進むようなものではないことを覚えておいてください。』という言葉はカンファレンスや技術ブログ記事で紹介されているツールやワークフローにすぐに飛びつきたくなる私のような無知で軽率な若者にはとても響きました。それよりもソフトスキルを組織に根付かせることの重要性を様々な視点から本書は教えてくれました。みなさんも『システム運用アンチパターン』をぜひ手に取ってみてください。

おまけ

Goでの開発やSRE/DevOps について雑談 をしたい方を募集してますー! 雑談する予定しかしないのですが仕事の話でもキャリアの話でも学生の方でも社会人の方でも気軽にお待ちしております。 meety.net

参考