DevOpsの「フィードバックの技術的実践」について読んだ内容のメモ
問題の可視化と解決のための基礎となる遠隔測定データを作り出す
遠隔測定: モニタリングのために、遠隔地で測定値、その他のデータを収集し、受信装置に転送するための自動的な通信プロセス
- 一元的な遠隔測定インフラストラクチャの作る
- 本番システムの運用を助けるためにアプリケーションにログ作成機能を追加する
- 問題解決の道案内として遠隔測定データを利用する
- 日常業務の一部としてし指標を生み出せるようにする
- 遠隔測定データと情報ラジエーターにセルフサービスでアクセスできるようにする
一元的な遠隔測定インフラストラクチャの作り方
環境からのデータだけではなく、デプロイパイプラインからも重要なイベントが発生したとき、データを取得する。
問題解決の道案内として遠隔測定データを利用する
問題解決の時に考えること
- 障害が実際に発生している証拠はモニタリングのどこにあるのか
- 障害の原因の一部になっている可能性がのあるアプリケーションや環境のイベント、変更はどれか
- 提出された原因と結果の間に結び付きがあることを示すためにどのような仮説を立てることができるか
- これらの仮説の中で正しく、解決のt雨に効果的なものがどれかを証明するために、どのようなことができるか。
遠隔測定データを分析して問題の予測と目標を達成に活かす
- 平均と標準偏差を使って問題となり得るものを検出する
- 望ましくない結果を測定してアラートを送る
- 遠隔測定データが正規分布にしたがっていないときの問題をみる
- 異常値検出テクニック(平滑化など)の使う
フィードバックループを実現して開発と運用が安全にコードをデプロイできるようにする
- 遠隔測定データを使ってデプロイをより安全なものにする
- 開発と運用でオンコールを共有する
- デペロッパーに下流の仕事を観察させる
- 最初の段階では本番サービスをデベロッパーに管理させる
日常業務に仮説駆動開発とA/Bテストを組み込む
A/Bテストというテクニックを活用して、安全で簡単にユーザーを空いてにした実験ができ、創造性とイノベーションを爆発的に活性化することができる！
- 機能テストにA/Bテストを組み込み
- リリースにA/Bテストを組み込む
- 機能のプランニングにA/Bテストを組み込む
レビューと調整プロセスによって現在の仕事の品質を上げる
- 変更承認プロセスの危険性
- 「過度に管理された変更」が秘める危険性
- 変更の調整と日程管理の実現
- ピアレビューの実現
- マニュアルテストを増やして変更の凍結期間を延ばすことの危険性
- 変更の品質を上げるためにペアプログラミングを実現する
- プルリクエストプロセスの有効性の評価方法
- 官僚主義的なプロセスを大胆に取り除く
変更承認プロセスの危険性
変更管理を行う人を信頼せず、命令と服従の文化が浸透している環境では、変更管理やテストといった予防策の改善を試みたところで、問題が最初する確率を上げるだけになることが多い。
「過度に管理された変更」が秘める危険性
手順や承認の数を増やし、バッチサイズを上げ、デプロイリードタイムを延ばし、デプロイプロセスで生じる摩擦を激化することになりがち。
マニュアルテストを増やして変更の凍結期間を延ばすことの危険性
マニュアルテストは、自動テストよりも時間がかかり面倒な上に、「追加テスト」はテストにかかる時間を大幅に増やす結果になりがちなので、デプロイの頻度が下がり、その結果としてデプロイのバッチサイズが大きくなる。
＝デプロイのバッチサイズが大きくなり、変更の成功率が下がり、インシデントの数が増え、MTTRが長くなる