運用はずっとやっていて興味のある分野のひとつなので読んだ。
目次は以下。
1章 DevOpsを構成するもの
2章 パターナリスト症候群
3章 盲目状態での運用
4章 情報ではなくデータ
5章 最後の味付けとしての品質
6章 アラート疲れ
7章 空の道具箱
8章 業務時間外のデプロイ
9章 せっかくのインシデントを無駄にする
10章 情報のため込み：ブレントだけが知っている
11章 命じられた文化
12章 多すぎる尺度
DevOps の話なので文化を変えようという話が多い気がする。まずはDevOps の説明から始まっている。
1章のまとめには「DevOpsの真の目的は仕事に対する見方や、異なるチームにまたがるタスクの関係を再定義すること」や「この本を読んでいる皆さんの多くはエンジニアであり具体的な行動に着目しがちでしょう。本書の前半では、皆さんの組織が直面している可能性の高い問題を例に挙げ、その解決に向けた具体的なアプローチをいくつか紹介します。その際にも企業文化がその状況に与えている影響を強調します」とあるように文化を変える、文化を共有することが必要だと説明されている。
文化を変えようとするとエンジニアだけではできないことが多々あると思う。しかしそれだけではなく本書では現場のエンジニアから始めれることも書かれている。
いくつかを例に上げると
- ログが適切なログレベルででていること、ログには文脈を含める
- データとしてメトリスクスを取るのではなく見る人のことを考えたダッシュボードを作成する
- テストのグループ化、継続的デリバリ
- 運用の自動化は設計プロセスのできるだけ早い段階で検討する
- インシデントが起こったらポストモーテムを実施する
- ポストモーテムをドキュメント化し、それぞれの対象者ごとに節を設けよう
- すべてのポストモーテムを同一の場所で共有する
- 標準的なドキュメントの代わりに、学習のための習慣をつけよう
学習についてやドキュメント作成・管理について、またログの設計やダッシュボードの作成などはエンジニアだけで変更をすることができると思う。ポストモーテムも行って、共有やドキュメントの管理はできるだろう。このあたりのできることからコツコツとやっていきたいなと思う。
エンジニアだけでできないことで人材採用や、承認プロセス、アラート作業への補償など。このあたりはエンジニアだけでどうにもできないので上司とかも交えて話をしていきたいなと思った。
まとめ
- できることからメンバとやってみようと思った
- 文化を形成するために言葉遣いとか今後気をつけよ
- 本を信じるだけではなく経験からの知識も大事にしていこうと思う
