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

モチベーション

• 「権限を持たない開発者」が私なので、何か出来そうなことがあれば参考にしたい

メモ

1章 DevOpsを構成するもの

• 1日に30回のデプロイは、あなたの組織の最終目標ではないかもしれません。
• 変更の内容を理解できない人がたとえ5人承認したとしても,変更の安全性は高まるはずがない
  • より多くの承認プロセスといった厳しい制限を増やし続けて安全性を手に入れているつもりになりがち
  • このような時に無駄なやり取りこそがDevOpsが解決しようとしているもの
• DevOpsはツールについてではなく、チームがどのように一緒に働くかについて考える
  • ツールによって可能になることに焦点を当てる
• CAMS：cluture（文化）、automation（自動化）、metrics（メトリクス）、sharing（共有）

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

• パターナリスト症候群：ある行動の実行や承認に必要な資格や信頼性を持つのは特定の人物だけである
• 自動化の価値は何度でも実行できるという点にある
• 承認プロセスの本当の目的を分析 →自動化で解消する
  • 作業が発生していることを必要な人に知らせていること
  • 変更を中止する必要があるような、アクションの衝突がないこと
  • 変更のリスクが組織にとって許容できるものであること
    • 標準的な変更：すでに確立された変更管理によって事前に承認。やり方や影響を理解している
  • レビューが行われていること
  • 操作や変更が適切なテストサイクルを経ていること
  • 承認者がプロセスの中で何を確認しているか？
    • 承認依頼を即座に却下する原因となるものはなにか？
    • 承認するすべての依頼が満たしているべき条件は何か？
• タスクを実行できる人を制限することで、リスクを減らすことができているわけではなく、一部の人にプレッシャーを集中させているだけ
• 何かが機能していると確認できることは、単にエラーがないと確認できることよりも価値がある
  • 知識を共有ことは責任を共有するために必要なこと
    • 責任の拡大に対応するためにはシステムの全体像を一定のレベルで理解する必要がある
• 電子メールでの通知、通知先のメールアドレスをアプリケーションで管理しない。既存の配信リストを利用
  • 通知リストの管理は組織のサービスデスクのプロセスで行うことが出来るはず。
• 自動化の継続的な改善に取り組む

3章 盲目状態での運用

• 自分たちが開発したシステムが本番でどのように動作するかをより詳細に理解することが求められている
  • 本番前の環境で完全かつ徹底的にテストするのは実行不可能になりつつある
  • 本番環境で初めてテストされる処理もある
• 運用の可視化
  • メトリクス：システムリソースのある時点での測定値
    • CPU使用率・メモリ使用率など＋アプリケーション用のカスタムメトリクスを開発すること
    • リクエスト数：どのくらいの頻度でこの処理が発生しているか？
    • エラー数：どのくらいの頻度で失敗しているか？
    • レイテンシ：完了するまでにどのくらいの時間がかかるか？
    • 何を測定するか？健全なメトリクスと不健全なメトリクスを分けるものは何か？
  • ログ：システムで発生したイベントを記述した、システムが生成するメッセージ
    • 価値あるものとするために
    • 構造化されたログフォーマットにする（JSONのような）
    • 適切なログレベルで記録する
    • エラーメッセージを読む時に生じる疑問を想定する

4章 情報ではなくデータ

• 利用者が値の良し悪しを知ることができるように、ウィジェットに文脈を与える
• 最も重要な項目が最初に目に入るようにダッシュボードを構成

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

• テストピラミッド
  • ユニットテスト＞統合テスト＞エンドツーエンドテスト
• ユニットテスト
  • テスト対象のユニットに含まれないものは、モックやスタブを使用（統合テストで扱うべき）
• 統合テスト
  • 実際のDB接続してデータの書き込みや読み込みを検証

6章 アラート疲れ

• システムメトリクス（CPU使用率・メモリ使用率など）のアラートを受けても何をしたら良いかわからないことが多い。
  • なぜ、どのようにしてその状態になったのかについて何の文脈も与えてくれない
• アラートには関連するドキュメントが必要
  • アラートを受け取った時に取るべき手順を説明する手順書
  • そもそもなぜそれが通知する必要のあるアラートなのかも記載
  • アラートメッセージに手順書へのリンクを記載
• 5分待てば自然に解除されるかもしれない時ではなく、すぐに調査する必要があると確信したときにアラートをトリガする
• 必ずしも真夜中に誰かを起こす必要はない。発生していることを認知すれば十分なアラートは、メールなどにする

7章 空の道具箱

• システム全体が自動化を念頭に置いて設計されていないと、自動化の欠如が生じる
• 運用とは、プロダクトを構築し維持するために必要なすべてのタスクや活動のこと
  • サーバの監視
  • テストパイプラインの管理
  • ローカル開発環境の構築
    • これらが頻繁に繰り返される場合、標準化することが重要
  • 自動化によって、権限を与え、スピードを上げ、再現性を高める

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

• デプロイのレイヤ
  • 機能デプロイ
  • フリートデプロイ
  • アーティファクトデプロイ
  • データベースデプロイ
• テストを組織の文化の一部にする
  • テストケースのないマージリクエストは不完全なマージリクエストであるという考えを徹底させる
• 自動化ですべてを確認できるわけではありません。しかし、それは手動のテストも同様です。
  • 不確実性を組織が許容できる範囲まで減らすことは可能

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

• 人を直接批判してはならない。行動や振る舞いに焦点を当てる。
• 今となっては明白な事実でも、その場では曖昧だった可能性があることを認識すう
• 人ではなくシステムを責める

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

• 組織全体での情報共有が促進されず、あるトピックに関してキーパーソンにすべてを任せるようになったとき
• 目標は、スタッフが離職しても、組織が活動するために必要な知識を保持すること

11章 命じられた文化

• 「○○を使ったシステムの使用経験が2～3年あること」
  • 実際にはどのような経験が必要なのか？

12章 多すぎる尺度

• 組織の目標を意識すると、自分がこれから取り掛かる予定の仕事が違って見えるようになる

感想

後半は飛ばし飛ばし読んだけど…

• 何を達成したいのか、目的をはっきりさせること

が大事だなってことを改めて感じました。
あとは、エラーメッセージ。「○○処理でエラーが発生しました」…で？どうすればいいの？ の部分を明確化するのも必要ですね。意外とできてない。