朝活で『システム運用アンチパターン』を読んだので読書感想文

はじめに

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

www.oreilly.co.jp

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

1章 DevOpsを構成するもの

    1.1 DevOpsとは?
        1.1.1 DevOpsの簡単な歴史
        1.1.2 DevOpsは何でないか
    1.2 DevOpsの柱となるCAMS
    1.3 また別のDevOps本?
    1.4 本章のまとめ

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

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

3章 盲目状態での運用

    3.1 苦労話
    3.2 開発と運用の役割を変える
    3.3 プロダクトの理解
    3.4 運用の可視化
        3.4.1 カスタムメトリクスの作成
        3.4.2 何を測定するかを決める
        3.4.3 健全なメトリクスを定義する
        3.4.4 故障モード影響分析
    3.5 ログを価値のあるものにする
        3.5.1 ログの集約
        3.5.2 何を記録すべきか?
        3.5.3 ログ集約のハードル
    3.6 本章のまとめ

4章 情報ではなくデータ

    4.1 データではなく利用者から始める
    4.2 ウィジェット:ダッシュボードの構成要素
        4.2.1 折れ線グラフ
        4.2.2 棒グラフ
        4.2.3 ゲージ
    4.3 ウィジェットに文脈を与える
        4.3.1 色による文脈の付与
        4.3.2 しきい値線による文脈の付与
        4.3.3 時間比較による文脈の付与
    4.4 ダッシュボードの構成
        4.4.1 ダッシュボードの行の構成
        4.4.2 読み手を導く
    4.5 ダッシュボードの命名
    4.6 本章のまとめ

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

    5.1 テストピラミッド
    5.2 テストの構造
        5.2.1 ユニットテスト
        5.2.2 統合テスト
        5.2.3 エンドツーエンドテスト
    5.3 テストスイートの信頼性
        5.3.1 テストスイートの信頼性の回復
        5.3.2 虚栄のメトリクスの回避
    5.4 継続的デプロイと継続的デリバリ
    5.5 機能フラグ
    5.6 パイプラインの実行
    5.7 テストインフラの管理
    5.8 DevSecOps
    5.9 本章のまとめ

6章 アラート疲れ

    6.1 苦労話
    6.2 オンコールローテーションの目的
    6.3 オンコールローテーションの設定
        6.3.1 確認までの時間
        6.3.2 開始までの時間
        6.3.3 解決までの時間
    6.4 アラート基準
        6.4.1 しきい値
        6.4.2 ノイズの多いアラート
    6.5 オンコールローテーションの配置
    6.6 オンコールへの補償
        6.6.1 金銭的補償
        6.6.2 休暇
        6.6.3 在宅勤務の柔軟性の向上
    6.7 オンコールの幸福度を追跡する
        6.7.1 誰がアラートを受けているか?
        6.7.2 アラートはどの程度の緊急度か?
        6.7.3 アラートはどのように通知されているか?
        6.7.4 チームメンバーはいつアラートを受けているか?
    6.8 オンコール担当中のタスク
        6.8.1 オンコールサポートプロジェクト
        6.8.2 パフォーマンスレポート
    6.9 本章のまとめ

7章 空の道具箱

    7.1 社内ツールと自動化が重要な理由
        7.1.1 自動化による改善
        7.1.2 自動化によるビジネスへの影響
    7.2 なぜ組織はもっと自動化しないのか
        7.2.1 自動化を文化的な優先事項と位置付ける
        7.2.2 自動化とツール開発のための人員
    7.3 自動化に関する文化の問題を解決する
        7.3.1 手動での作業は認めない
        7.3.2 「ノー」という答えを支持する
        7.3.3 手動作業のコスト
    7.4 自動化を優先する
    7.5 自動化の目標を決める
        7.5.1 すべてのツールの要件としての自動化
        7.5.2 業務の中で自動化を優先する
        7.5.3 自動化をスタッフの優先事項とする
        7.5.4 トレーニングと学習のための時間を確保する
    7.6 スキルセットのギャップを埋める
        7.6.1 自分が関わったものは所有する必要があるという考え
        7.6.2 新しいスキルセットの構築
    7.7 自動化のアプローチ
        7.7.1 タスクにおける安全性
        7.7.2 安全のための設計
        7.7.3 タスクの複雑さ
        7.7.4 タスクをランク付けする方法
        7.7.5 単純なタスクの自動化
        7.7.6 困難なタスクの自動化
        7.7.7 複雑なタスクの自動化
    7.8 本章のまとめ

8章 業務時間外のデプロイ

    8.1 苦労話
    8.2 デプロイのレイヤ
    8.3 デプロイを日常的に行う
        8.3.1 正確な本番前環境
        8.3.2 ステージング環境は本番環境とまったく同じにはならない
    8.4 頻繁に行うことで恐怖心を減らす
    8.5 リスクを減らして恐怖心を減らす
    8.6 デプロイプロセスの各レイヤでの失敗への対応
        8.6.1 機能フラグ
        8.6.2 いつ機能フラグをオフにするか
        8.6.3 フリートのロールバック
        8.6.4 デプロイアーティファクトのロールバック
        8.6.5 データストアレベルのロールバック
    8.7 デプロイアーティファクトの作成
        8.7.1 パッケージ管理ツールの活用
        8.7.2 パッケージ内の設定ファイル
    8.8 デプロイパイプラインの自動化
        8.8.1 新しいアプリケーションを安全にインストールする
    8.9 本章のまとめ

9章 せっかくのインシデントを無駄にする

    9.1 良いポストモーテムの構成要素
        9.1.1 メンタルモデルの作成
        9.1.224 時間ルールの遵守
        9.1.3 ポストモーテムのルール設定
    9.2 インシデントの発生
    9.3 ポストモーテムの実施
        9.3.1 ポストモーテムに招待する人を選ぶ
        9.3.2 タイムラインの振り返り
        9.3.3 アクションアイテムの定義とフォローアップ
        9.3.4 ポストモーテムのドキュメント化
        9.3.5 ポストモーテムの共有
    9.4 本章のまとめ

10章 情報のため込み:ブレントだけが知っている

    10.1 どのように情報がため込まれているかを理解する
    10.2 意図せずに情報をため込んでいる人を認識する
        10.2.1 ドキュメントを大切にしない
        10.2.2 抽象化vs.難読化
        10.2.3 アクセス制限
        10.2.4 ゲートキーパーの行動を評価する
    10.3 コミュニケーションを効果的に構築する
        10.3.1 トピックの定義
        10.3.2 対象者の定義
        10.3.3 キーポイントの説明
        10.3.4 行動喚起の提示
    10.4 知識を発見可能にする
        10.4.1 ナレッジストアの構築
        10.4.2 学習の習慣付け
    10.5 チャットツールの有効活用
        10.5.1 会社の作法を確立する
        10.5.2 チャットだけではない
    10.6 本章のまとめ

11章 命じられた文化

    11.1 文化とは何か?
        11.1.1 文化的価値観
        11.1.2 文化的習慣
        11.1.3 信念
    11.2 文化はどのように行動に影響を与えるか?
    11.3 文化を変えるには?
        11.3.1 文化の共有
        11.3.2 個人が文化を変えることができる
        11.3.3 会社の価値観を調べる
        11.3.4 習慣を作る
        11.3.5 習慣と言葉を使って文化的規範を変える
    11.4 文化に合った人材
        11.4.1 古い役割、新しい考え方
        11.4.2 シニアエンジニアへのこだわり
        11.4.3 候補者との面接
        11.4.4 候補者の評価
        11.4.5 何人の候補者と面接をするか?
    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地点へ進むようなものではないことを覚えておいてください。』という言葉はカンファレンスや技術ブログ記事で紹介されているツールやワークフローにすぐに飛びつきたくなる私のような無知で軽率な若者にはとても響きました。それよりもソフトスキルを組織に根付かせることの重要性を様々な視点から本書は教えてくれました。みなさんも『システム運用アンチパターン』をぜひ手に取ってみてください。

参考