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

https://gyazo.com/1558a36104c009bf1e39559393dab0ce

システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション

30分で分るスライド

発表者は訳者と同じ人

2022/4/12出版

1,6,8,9

devopsって聞いたことあるけどパッとしてなかった

インシデント対応

slackに来るアラート対応

deployを楽にしたい

etc.

翻訳した人の記事

対象読者や、各章の概要など

技術チームの運用担当や開発担当のチームリーダーや一般のエンジニアを対象としています。

目　次

序文

本書について

1.1　DevOpsとは？

1.1.1　DevOpsの簡単な歴史

1.1.2　DevOpsは何でないか

1.2　DevOpsの柱となるCAMS

1.3　また別のDevOps本？

1.4　本章のまとめ

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.1　ダッシュボードの行の構成

4.4.2　読み手を導く

4.5　ダッシュボードの命名

4.6　本章のまとめ

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

5.2　テストの構造

5.2.2　統合テスト

5.2.3　エンドツーエンドテスト

5.3　テストスイートの信頼性

5.3.1　テストスイートの信頼性の回復

5.3.2　虚栄のメトリクスの回避

5.5　機能フラグ

5.6　パイプラインの実行

5.7　テストインフラの管理

5.9　本章のまとめ

6.1　苦労話

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.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.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.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　本章のまとめ

本書のまとめ

訳者あとがき

索引

T